Re: [Bitcoin-development] Segmented Block Relaying BIP draft.

2012-09-13 Thread Matthew Mitchell
On 13 Sep 2012, at 09:42, Mike Hearn m...@plan99.net wrote: For what it's worth I disagree with Gregory on nearly all these points, so don't take it as some kind of consensus from the Bitcoin community ;) Matts change is reasonable but I think we all agree it has minimal impact at the

Re: [Bitcoin-development] Segmented Block Relaying BIP draft.

2012-09-13 Thread Matthew Mitchell
On 13 Sep 2012, at 16:16, Gregory Maxwell gmaxw...@gmail.com wrote: Sorry, I'm still not seeing what the value is. How is the tree level useful to anyone? If you did want to get only parts of the transaction list, why not just ranges from the lowest level? Obtaining a particular tree level

Re: [Bitcoin-development] Segmented Block Relaying BIP draft.

2012-09-13 Thread Matthew Mitchell
On 13 Sep 2012, at 16:51, Gregory Maxwell gmaxw...@gmail.com wrote: I thoroughly understand the value of tree hashes. That wasn't what I was asking about. If you're validating a block you need all the transactions, once you have them or their hashes you can build the tree without

Re: [Bitcoin-development] Segmented Block Relaying BIP draft.

2012-09-13 Thread Pieter Wuille
On Thu, Sep 13, 2012 at 06:49:49PM +0100, Matthew Mitchell wrote: A merkle tree root is found by hashing the two children together and those children are found the same way until you get to the greatest level down the tree. This means you can validate children as being correct as long as they

Re: [Bitcoin-development] Segmented Block Relaying BIP draft.

2012-09-13 Thread Matthew Mitchell
On 13 Sep 2012, at 19:59, Pieter Wuille pieter.wui...@gmail.com wrote: You want to parallellize block downloads, while at the same time preventing re-download of transactions that are already known. To do so, a requesting node would first request (for example) the 8 level-3 hashes, then

Re: [Bitcoin-development] Segmented Block Relaying BIP draft.

2012-09-11 Thread Matthew Mitchell
For some reason sourceforge is not sending me updates anymore but I can see the replies online… There could be a slightly more simple protocol which gives all the transactions hashes and nodes can then download the transactions separately. However there are two problems: 1. Downloading all

Re: [Bitcoin-development] Segmented Block Relaying BIP draft.

2012-09-11 Thread Gregory Maxwell
On Tue, Sep 11, 2012 at 3:07 PM, Matthew Mitchell matthewmitch...@godofgod.co.uk wrote: For some reason sourceforge is not sending me updates anymore but I can see the replies online… There could be a slightly more simple protocol which gives all the transactions hashes and nodes can then

Re: [Bitcoin-development] Segmented Block Relaying BIP draft.

2012-09-11 Thread Matthew Mitchell
On 11 Sep 2012, at 20:42, Gregory Maxwell gmaxw...@gmail.com wrote: Someone can do that just by pipelining the one at a time requests. How much bandwidth do you think you could save over that? You wouldn't need to pipeline the requests, just place more than one inventory vector in get data,

Re: [Bitcoin-development] Segmented Block Relaying BIP draft.

2012-09-10 Thread Gregory Maxwell
On Mon, Sep 10, 2012 at 11:07 AM, Matthew Mitchell matthewmitch...@godofgod.co.uk wrote: Here is a BIP draft for improving the block relaying and validation so that it can be done in parallel and so that redundancy can be removed. This becomes more beneficial the larger the block sizes are.

Re: [Bitcoin-development] Segmented Block Relaying BIP draft.

2012-09-10 Thread Luke-Jr
On Monday, September 10, 2012 3:07:52 PM Matthew Mitchell wrote: Here is a BIP draft for improving the block relaying and validation so that it can be done in parallel and so that redundancy can be removed. This becomes more beneficial the larger the block sizes are.

Re: [Bitcoin-development] Segmented Block Relaying BIP draft.

2012-09-10 Thread Matt Corallo
It seems to me the whole idea of segmenting blocks would add very little (to nothing) with any sane block size. Sure, if a block were to be 10GB, it may make sense. However, even in that case, it would be easier to relay a list of tx hashes (which may be a bit expensive) and txes separately