On 13 Sep 2012, at 19:59, Pieter Wuille 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 start 8 parallel threa
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 th
On 13 Sep 2012, at 16:51, Gregory Maxwell 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 transferring
> more, e.
On 13 Sep 2012, at 16:16, Gregory Maxwell 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 allows you to v
On Thu, Sep 13, 2012 at 10:05 AM, Matthew Mitchell
wrote:
> @Gregory
>
>> But you only need to request the transactions you don't have. Most of
>> time you should already have almost all of the transactions.
>
> Yes, my proposal allows you to do this. You skip out transactions your
> already hav
On 13 Sep 2012, at 09:42, Mike Hearn 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 moment relativ
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 moment relative to other things, so something even more
complex than tha
On Tue, Sep 11, 2012 at 5:48 PM, Matthew Mitchell
wrote:
> You wouldn't need to pipeline the requests, just place more than one
> inventory vector in get data, right? Well my messages would save the space of
> those inventory vectors. Instead of needing 36 byte inventory vectors for
> each tran
On 11 Sep 2012, at 20:42, Gregory Maxwell 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, right? Well my mes
On Tue, Sep 11, 2012 at 3:07 PM, Matthew Mitchell
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 download the transactions s
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 the
On Mon, Sep 10, 2012 at 3:53 PM, Matt Corallo wrote:
> 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
As you know there is a h
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 inste
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 the
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.
>
> https://en.bitcoin.i
I actually implemented parts of the header+ v stuff in a branch with
my bloom filter stuff, you can see it here:
https://github.com/TheBlueMatt/bitcoin/commits/bloom%2Brelayblock
Its pretty stupid and would be pretty easy to DoS/get it stuck/etc, but
in theory it works. I don't see much reason why
On Mon, Sep 10, 2012 at 11:07 AM, 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.
>
> https://en.bitcoin.it/wiki/
17 matches
Mail list logo
