(closed, passed) BUIP001: "Unlimited" inspired extensions to the Bitcoin Client

[jonny1000]

But then if the rest of the network begins accepting a bigger block and building on that chain you will forever be stuck on the wrong chain. This is the only purpose of the N depth limit, to ensure you can stay on the right chain if the network moves on past your defined limit.

Set the default value of N=1 then, and you will always follow the longest chain. Having a public policy of waiting for 4 confirmations just lets everyone know they can fool your client for 4 blocks and then you will switch.

 

[Zangelbert Bingledack]

@jonny1000

It's nice in BU that people can "agree to disagree" and still run the same implementation. For some miners in some conditions, N=4 might be good, whereas for others it might make no sense. You don't have to agree with the BU devs. That's the beauty of this approach.

 

[Aquent]

Exactly. You can set N to 0 I suppose so that there is no N depth if you wish. It would however be pretty stupid to not switch to the longest chain when that chain has 4 confirmation more than your own chain.

I always saw it as a failsafe mechanism in case your soft original limit is misjudged for whatever reason, still leaving you with the N depth hard limit. However, one should expect everyone to communicate their soft limit in their blocks so the N depth should never really come into play except for highly exceptional circumstances.

 

[Peter Tschipper]

I know this has long been voted on but had I voted I too would have suggested taking out the rate limiting. The problem with having rate limiting available right now is that I believe we are getting to the point where, in order for Bitcoin to scale in the real world (not on testnet or in a lab), we need to have a multi-threaded network layer. Having rate limiting in place makes it much more difficult to put that multi-threading in place. It would be better if rate limiting were taken out, multi-threading put in, and then an attempt made to re-introduce rate limiting after. IMO the challenge of building and testing a multi-threaded network layer will be difficult enough without being hampered by the need to accommodate rate-limiting.