[Bitcoin-development] Segmented Block Relaying BIP draft.

Matthew Mitchell matthewmitchell at godofgod.co.uk
Thu Sep 13 14:05:29 UTC 2012


On 13 Sep 2012, at 09:42, Mike Hearn <mike at 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 moment relative to other things, so something even more
> complex than that seems like a non-starter. Bloom filtering is a lot
> more important.

Sure other things may be done before this, I was seeing this as a change somewhere down the line but not urgent.

@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 have. My proposal is simply better than others because it takes full advantage of the merkle tree structure with minor additions that are simple to implement. How hard is it to get the hashes at a particular level of a merkle tree? Not hard at all. How hard is it to place a selection of transactions from a block into a message Not hard at all. Implementation of the protocol requirements would be a piece of cake. The harder bit would be to create an algorithm to determine the best level of segmentation but this is not required to comply with the protocol.

> Because there is no motivation not to set them to zero, if you don't
> someone else will

The motivation to incentivise miners and maintain stronger security? The difficulty only has to be high enough to prevent a cartel of malicious miners taking control of the network, something that is potentially a problem today with the large mining pools. Remember that the more transactions there are the more fees there can be for miners to collect. The more people that are using bitcoin, the greater bitcoins will be worth. A bigger network should be good for miners when relying on fees.

> And yes, of course, you schedule the change
> for the future, but as you note that it doesn't solve the problem of
> people opposing it.

If it's so controversial that it creates a split making two separated currencies then I'd see it turning out like the format wars (VHS vs Betamax and Blu-ray vs HD-DVD). Eventually people will move towards one or the other since it's better for people to have universalised agreement on a system.



More information about the bitcoin-dev mailing list