Received: from sog-mx-4.v43.ch3.sourceforge.com ([172.29.43.194] helo=mx.sourceforge.net) by sfs-ml-1.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1TB9kW-00071a-9R for bitcoin-development@lists.sourceforge.net; Mon, 10 Sep 2012 19:34:24 +0000 Received-SPF: pass (sog-mx-4.v43.ch3.sourceforge.com: domain of eigbox.net designates 66.96.189.3 as permitted sender) client-ip=66.96.189.3; envelope-from=SRS0=lbq4E4=HJ=godofgod.co.uk=matthewmitchell@eigbox.net; helo=bosmailout03.eigbox.net; Received: from bosmailout03.eigbox.net ([66.96.189.3]) by sog-mx-4.v43.ch3.sourceforge.com with esmtp (Exim 4.76) id 1TB9kV-0008PO-49 for bitcoin-development@lists.sourceforge.net; Mon, 10 Sep 2012 19:34:24 +0000 Received: from bosmailscan02.eigbox.net ([10.20.15.2]) by bosmailout03.eigbox.net with esmtp (Exim) id 1TB9kP-00082Q-ID for bitcoin-development@lists.sourceforge.net; Mon, 10 Sep 2012 15:34:17 -0400 Received: from bosimpout01.eigbox.net ([10.20.55.1]) by bosmailscan02.eigbox.net with esmtp (Exim) id 1TB9kO-0004Na-Ih; Mon, 10 Sep 2012 15:34:16 -0400 Received: from bosauthsmtp09.eigbox.net ([10.20.18.9]) by bosimpout01.eigbox.net with NO UCE id xXaH1j0030BkY8i01XaHJp; Mon, 10 Sep 2012 15:34:17 -0400 X-Authority-Analysis: v=2.0 cv=aPZHX8Bm c=1 sm=1 a=EdgcOKDBJpMkesC5stW6Qg==:17 a=Goz4v7xpImgA:10 a=JhU9KSwl1l8A:10 a=RmqW3wxksLsA:10 a=eGitJVp2AAAA:8 a=-aUnnjAAwhoA:10 a=r7esRitPAAAA:8 a=mLYL7Y0PAAAA:8 a=uEaaO3vx7Ru_3I5q34oA:9 a=CjuIK1q_8ugA:10 a=29nVbMLIeY0A:10 a=tnEpsa5-Z5JzT0F1:21 a=PIdmGQ6WNGtAWcEa:21 a=VH2qAgixP-mNbH_KltEA:9 a=_W_S_7VecoQA:10 a=+tcVrJynzLVJ9yqDAOBWjQ==:117 X-EN-OrigOutIP: 10.20.18.9 X-EN-IMPSID: xXaH1j0030BkY8i01XaHJp Received: from 5adb753d.bb.sky.com ([90.219.117.61] helo=[192.168.0.7]) by bosauthsmtp09.eigbox.net with esmtpsa (TLSv1:AES128-SHA:128) (Exim) id 1TB9kO-0005yq-DF; Mon, 10 Sep 2012 15:34:16 -0400 From: Matthew Mitchell Content-Type: multipart/alternative; boundary="Apple-Mail=_FB67F502-316A-4C55-BE79-EDFEDAD36E88" Message-Id: <239CFE18-302F-47F1-8686-67297FDDFB3C@godofgod.co.uk> Mime-Version: 1.0 (Mac OS X Mail 6.0 \(1486\)) Date: Mon, 10 Sep 2012 20:34:10 +0100 References: <201209101859.05009.luke@dashjr.org> To: Luke-Jr , "bitcoin-development@lists.sourceforge.net" In-Reply-To: <201209101859.05009.luke@dashjr.org> X-Mailer: Apple Mail (2.1486) X-EN-UserInfo: c68a83c59c94ef03b40bb4bc312c51e4:dffc0a9b4c8a0435ad832ff5852cab82 X-EN-AuthUser: godofgod@godofgod.co.uk Sender: Matthew Mitchell X-EN-OrigIP: 90.219.117.61 X-EN-OrigHost: 5adb753d.bb.sky.com X-Spam-Score: -0.9 (/) X-Spam-Report: Spam Filtering performed by mx.sourceforge.net. See http://spamassassin.org/tag/ for more details. -1.5 SPF_CHECK_PASS SPF reports sender host as permitted sender for sender-domain -0.0 SPF_PASS SPF: sender matches SPF record -0.4 RP_MATCHES_RCVD Envelope sender domain matches handover relay domain 1.0 HTML_MESSAGE BODY: HTML included in message X-Headers-End: 1TB9kV-0008PO-49 Subject: Re: [Bitcoin-development] Segmented Block Relaying BIP draft. X-BeenThere: bitcoin-development@lists.sourceforge.net X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Sep 2012 19:34:24 -0000 --Apple-Mail=_FB67F502-316A-4C55-BE79-EDFEDAD36E88 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Do you mean getdata? Here is the reason for the 6 new messages: getseginv,seginv - These are for learning about what segments of a block = a node has. Else you could remove these messages and simply have nodes = advertise blocks via inventory messages. In this case nodes would have = to wait until they had fully received a block before relaying anything. = No longer is there a benefit with nodes being able to relay segments of = blocks before they have received the entire block. gettreelevel,treelevel - These are to received a level of the merle = tree. Instead you might use get data but gettreelevel is more compact = than get data and is clearly differentiates itself as part of the new = protocol. Perhaps these messages could include the block headers = alongside the hashes and you could request many at once like with the = getheaders message? If you skip these messages, then you could verify = the transactions at the end but there would be problems when peers give = bad segments where data would need to be downloaded again. getsegment,segment - These are clearly important to request and receive = segments for the blocks. These allows for nodes to download arbitrary = segments of blocks. The optimum number of segments could be calculated = by node software using measurements of download speeds and latency = times, the number of connections and how likely redundancy is to occur. = If a node is up-to-date and likely has many of the transactions in = blocks, it can start asking for the deepest merle level (tx hashes) and = ask nodes for segments, avoiding transactions it already has. I'll get around to doing measurements myself sometime to estimate the = benefit of this proposal. It will certainly be beneficial when block = sizes reach some size but not much is really known except what can be = assumed/guessed. I should also mention the bitcointalk topic here: = https://bitcointalk.org/index.php?topic=3D103295.0 On 10 Sep 2012, at 19:59, "Luke-Jr" wrote: >=20 > Most of the problem with block propagation lies in implementation, not=20= > protocol... Distributing missing transaction on an as-needed basis is = a=20 > possible improvement at the protocol level, but there hasn't (AFAIK) = been any=20 > research into whether the little benefit outweighs the cost yet. In = any case,=20 > I don't see why 6 new messages are needed instead of simply adding a = single=20 > new type to getinv? --Apple-Mail=_FB67F502-316A-4C55-BE79-EDFEDAD36E88 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii getseginv,seginv - = These are for learning about what segments of a block a node has. Else = you could remove these messages and simply have nodes advertise blocks = via inventory messages. In this case nodes would have to wait until they = had fully received a block before relaying anything. No longer is there = a benefit with nodes being able to relay segments of blocks before they have received the = entire block.

gettreelevel,treelevel - These are to received a level of = the merle tree. Instead you might = use get = data but gettreelevel is more compact = than get = data and is clearly differentiates itself as part of the new protocol. = Perhaps these messages could include the block headers alongside the = hashes and you could request many at once like with the getheaders = message? If you skip these messages, then you could verify the = transactions at the end but there would be problems when peers give bad = segments where data would need to be downloaded = again.

segment - These are clearly important to request = and receive segments for the blocks. These allows for nodes = to download arbitrary segments of blocks. The = optimum number of segments could be calculated by node software = using measurements of download speeds and latency times, the = number of connections and how likely redundancy is to occur. If a node = is up-to-date and likely has many of the transactions in blocks, it can = start asking for the deepest merle level (tx hashes) and ask nodes for segments, avoiding = transactions it already has.

I'll get around to doing measurements myself = sometime to estimate the benefit of this proposal. It will certainly be = beneficial when block sizes reach some size but not much is really known = except what can be assumed/guessed.

I should also mention the bitcointalk topic = here: https://bitcoi= ntalk.org/index.php?topic=3D103295.0

On 10 Sep = 2012, at 19:59, "Luke-Jr" <luke@dashjr.org> = wrote:

Most of the problem with block = propagation lies in implementation, not
protocol... Distributing = missing transaction on an as-needed basis is a
possible improvement = at the protocol level, but there hasn't (AFAIK) been any
research = into whether the little benefit outweighs the cost yet. In any case, =
I don't see why 6 new messages are needed instead of simply adding a = single
new type to getinv?

= --Apple-Mail=_FB67F502-316A-4C55-BE79-EDFEDAD36E88--