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

jonny1000

Active Member
Nov 11, 2015
380
101
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

Well-Known Member
Aug 29, 2015
1,485
5,585
@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

Active Member
Aug 19, 2015
252
667
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.
 
  • Like
Reactions: Peter R

Peter Tschipper

Active Member
Jan 8, 2016
254
357
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.