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

[theZerg]

BUIP 001: Extensions to the Bitcoin Client
Proposer: Andrew Stone

Submitted on: 11/26/2015


The following extensions are proposed for the Bitcoin client:

1. GUI: Creation of a “Bitcoin Unlimited” menu option and dialog box to access BU specific features. This menu option will appear just below the “options” option.

2. Addition of an Unlimited Dialog / command line option to change the maximum size of a generated (mined) block. This will allow miners to use BU to generate large blocks. The default value will be 1000000 bytes (compatible with today's consensus).

3. Addition of an Unlimited Dialog / command line option to change the default block “accept” size. Blocks larger than this (excessive blocks) will only be accepted if they are N deep in the blockchain. This will be 16MB by default. The largest message is limited to 10 times this size, to that creates an effective block size limit. This limitation was not removed entirely to stop people from DOSing BU by sending a fake infinitely sized block.

4. Addition of an Unlimited Dialog / command line option to set the excessive block accept depth. This is the N parameter in the description of #3. The default value will be 4.

5. Addition of traffic shaping. Traffic shaping, similar to what is merged into Bitcoin XT is added to the Unlimited menu and command line options. As blocks grow bigger, it is important that users can easily configure how much bandwidth should be used for Bitcoin. This allows the Bitcoin client to run unobtrusively in a home network. Although bandwidth-limited clients in theory increase the time it takes for a block to propagate through the network, this will only happen if their removal would partition the network – i.e. they are a critical node in the network topology. Additionally, they are valuable as another copy of the blockchain and to serve data to clients who do not need fast block propagation (essentially everyone but miners). And in practice, Matt Corollo's Bitcoin Relay Network is used for fast block propagation...

6. Fix in the GUI's transaction notification – if lots of notifications are coming in, some will be skipped. This fixes the problem where if you end up receiving 1000+ transactions the visual notifications keep coming for a half hour after the actual notification.

7. Client identifier changed to BitcoinUnlimited

8. Block version changed to 0x40000007. This version would reflect BIP101 and OP_CHECKLOCKTIMEVERIFY support.

9. Minimal branding changes -- replacing Unlimited with Core in key locations and adding new artwork. We want to rebrand, but do not want rebasing the code to be a headache. So a minimal approach was taken WRT branding.


A release will be made containing the above changes based off the Bitcoin Core 0.11 (.2) branch. Subsequent Bitcoin Unlimited releases will also include the above changes.

These changes are functionally complete on the 0.11cfg_stats, and have been running on mainnet and testnet for several days. However, this branch will still get a final code review, hopefully by a different developer before release (you are NOT voting to include this branch "AS IS").

It is important that we make an initial, simple Bitcoin Unlimited release to get things going. Please do not bikeshed this proposal with small modifications and new features (for example, having a button that automatically tracks BIP101 block expansion). We can make things better in subsequent releases.

 

[Zangelbert Bingledack]

To see if I understand correctly, the only changes here that aren't strictly user-interface changes are [1] the addition of oversize block tolerance (with default N=4) and [2] the block version (flagging support for BIP101 and OP_CHECKLOCKTIME)?

In other words, these are the only changes that a user who doesn't touch the settings will be subjected to vs. Core?

 

[sickpig]

only minor nitpicks:

in point 8 we are speaking of BIP 65 support right? if yes than:

s/OP_CHECKTIMELOCK/OP_CHECKLOCKTIMEVERIFY/

lastly point 10 should be 9.

keep up the good work!

 

[theZerg]

ok fixed those comments. Thanks I was writing this up very quickly.

@Zangelbert Bingledack From the user's perspective, yes, those are the only changes. I also added one fix that helps switch from one chain to another. Basically, if you have to unwind and replay 1000+ blocks (let's say XT and Core blockchains fork) it is very slow. I discovered that a lot of CPU was being used to re-verify these transactions so I removed the signature and script verification step if the transaction is coming from an already-accepted block because these transactions have already been verified. I also fixed a couple of memory leaks in the GUI.

I'm hoping to get someone who has worked with the code for longer than I have to review this change (and while he's at it, why not all of them?)... anyone know who would be willing?

However, there are no changes whatsoever in the wallet code, for example.


From the perspective of voting on the BUIP, its not a member's to verify that the patch does what the BUIP says it does -- due to the fact that people are busy, and many are not engineers, we will need to leave that to the Developer and any other interested engineer. What members should discuss and vote on is whether they want Bitcoin Unlimited to have the changes as described in the BUIP.

 

[Zangelbert Bingledack]

My only thought is about the tactical ramifications of perhaps having a version where nothing at all is changed from Core if you don't go into the Bitcoin Unlimited settings menu. Every setting would have to be turned on to get the BU benefits. This may be a tradeoff because it moves still further from encouraging unlimited blocksize by default, but it presents a nice tactical angle of, "Look, there's no difference at all except that BU gives you some user-friendly ways to adjust some things. It's just an easily configurable Core. In fact it IS Core unless you change your mind. This way you don't have to download a new version if something unexpected happens with blocksize or consensus."

 

[solex]

@Zangelbert Bingledack
Unfortunately, that won't work as far too many people just want the path of least resistance for software setup, particularly something sophisticated like a Bitcoin full node where they will prefer to trust the defaults from developers rather than monkey with settings.
If BU does not default to big-blocks then it will probably do little to disrupt the Core status quo (edit: in the short-term).

I think that the actual strength of BU in removing the universal block limit from the protocol layer is something that would be slowly realised over months and years as more versions are released and more people do start to change the block settings for their own personal circumstances.

 

[Zangelbert Bingledack]

Perhaps there could be a dialog on startup basically saying that the default is as with Core but the recommended setting is as @theZerg specified in the BUIP above. Maybe even check a box at launch to start with Core defaults or BU recommended defaults. Force the user to notice, recommend changing the settings, have a recommended BU setup, but leave the default if they just click "Next" be Core settings. Maybe even include a warning if they click onward, saying something like, "Really use 1MB blocksize limit with no fork depth tolerance? WARNING: Client may not track longest chain consensus as blocks increase in size." Nag quite a bit, but make it so that it's still very easy for people to choose Core defaults if that's what they truly want. That way BU can be marketed as a strictly superior product with no complications. Just spitballing here though, not sure what all the considerations are.
[doublepost=1448599851,1448598950][/doublepost]So I see at least 5 levels of encouraging large blocksize caps through BU, in order of increasing insistence:

1. Configurable, with Core defaults and no nag or recommendations.

2. Configurable, with Core defaults, but with nag/recommendations toward BU settings

3. Configurable, with BU defaults but user only need check a box at launch to set it with Core defaults

4. Configurable, with BU defaults and no explanation about Core settings nor any one-click way to make Core settings the default (they'd have to go in and adjust each setting manually in the BU menu; still very easy to do)

5. Blocksize set at unlimited (or extremely high) and not user-configurable.

I can see arguments for all these levels.

 

[solex]

Perhaps there could be a dialog on startup basically saying that the default is as with Core but the recommended setting is as @theZerg specified in the BUIP above. Maybe even check a box at launch to start with Core defaults or BU recommended defaults.

This is a nice idea. A check-box which needs manual action to use Core defaults.

 

[awemany]

@theZerg: Looks good!

@solex, @Zangelbert Bingledack: We should always be aware that BU will probably be used -at least initially - by those that want a bigger maximum blocksize anyways. I have no further opinion here except that I support @theZerg in trying to avoid bikeshedding this too much.

 

[Zangelbert Bingledack]

Yeah I don't want to bikeshed this point as far as this BUIP. It could probably be decided/modified later anyway, as the tactical considerations become clearer. It's more something to keep in mind in general, i.e., that there's not just a black and white "default vs. non-default".

 

[theZerg]

Just to be clear, when you run BU you can't configure it to behave exactly the same as Blockstream Core ;-). Ok, I suppose you can set your "excessive" level to 1MB, and your excessive acceptance to 1000000000. That will keep your active chain aligned with Blockstream until1000000000 blocks beyond the first 1MB+ block.

But if a 1.1MB block comes in, instead of rejecting the block and dropping the connection your client will track this fork and keep the connection. So its a subtle difference.


I am definitely in favor of creating simple profiles and asking the user questions on startup to pick a profile. Like "do you think this node should be a high bandwidth, central node, or is this more of a home-hosted edge node". Like "do you want to track BIP101 increases?".

But let's do this later. I want to get what I have now out next week. And formally vote on this BUIP on Dec 10th.

 

[steffen]

It looks good.

 

[Zangelbert Bingledack]

Reposted from the "Gold Collapsing..." thread:

On traffic shaping, while I agree with others that KISS is the right approach for dealing with FUD, it seems that if the traffic shaping is completely optional and off by default, there should be no problem.

It could be marketed as "Core+No cap+Optional traffic shaping."

 

[theZerg]

Voting on this starts tomorrow 0:00 UTC until 23:00 UTC. Let's just use open call. Just reply to this thread with yes or no. We will be signing cryptographically when things get more under way.

 

[Inca]

Operating tomorrow so: yes

 

[Zangelbert Bingledack]

Yes, but one day seems a short voting period since many here don't even log in every day.

 

[theZerg]

I vote yes; I'm not going to be a stickler about the times... but just following the Articles; maybe I should have written in a longer time but too late to change that now.

 

[sickpig]

Yes.

 

[Zarathustra]

Yes

 

[awemany]

yes!