- Aug 22, 2015
- 1,558
- 4,693
Bitcoin Unlimited 1.0.0 & 1.0.0.1 Release Notes
The third official BU client release reflects our opinion that Bitcoin full-node software has reached a milestone of functionality, stability and scalability. Hence, completion of the alpha/beta phase throughout 2009-16 can be marked in our release version 1.0.0.
The most important feature of BU's first general release is functionality to restore market dynamics at the discretion of the full-node network. Activation will result in eliminating the full-blocks handicap, restoring a healthy fee-market, allow reliable confirmation times, fair user fees, and re-igniting stalled network effect growth, based on Bitcoin Unlimited’s Emergent Consensus model to let the ecosystem decide the best values of parameters like the maximum block size.
Bitcoin Unlimited open-source version 1.0.0 contains a large number of changes, updates and improvements. Some optimize the Emergent Consensus logic (EC), others improve the system in a more general way, and a number of updates are imported from the open source work of the Bitcoin Core developers who deserve full credit for their continued progress.
Emergent Consensus (EC)
✦ Set Accepted Depth (AD) to 12 as default.
BU has a “sticky gate” (SG) mechanism which supports the functioning of EC.
SG means that if blocks are propagated which are bigger than a specific node's “Excessive Block Size” (EB) and subsequent blocks reach the node's "Acceptance Depth" (AD), then the node accepts, for 144 blocks, every block up to the size of its EB * 16. This mechanism is needed to ensure that nodes maintain consensus during an uptick in the network's record block size seen and written to the blockchain.
In co-operation with Bitcoin XT a potential attack on SG has been identified.
A minority hash-power attacker is probabilistically able to produce AD+1 blocks before the majority produces AD blocks, so it is possible that a sequence of very large blocks can be permanently included in the blockchain.
To make this attack much less likely and more expensive, the standard setting for Acceptance Depth is increased to 12. This value is the result of analysis and simulation. Note that due to variation in node settings only a subset of nodes will be in an SG situation at any one time.
Bitcoin Unlimited recommends miners and commercial node users set their Accepted Depth parameter to the value of 12.
Further information:
Discussion of Sticky Gate / the attack
Table with result of simulation
✦ Flexible Signature Operations (sigops) Limit and an Excessive Transaction Size
When a Bitcoin node validates transactions, it verifies signatures. These operations – Signature Operation, short SigOps – have CPU overhead. This makes it possible to build complex transactions which require significant time to be validated. This has long been a major concern against bigger blocks that tie up node processing and affect the synchronicity of the network, however, a "gossip network" is inherently more robust than other types.
BUIP040 introduces several changes to mitigate these attacks while adhering to the BU philosophy. The pre-existing limit of 20,000 per MB block size is enough to enable a wide scope of transactions, but mitigates against attacks. A block size of 1 MB permits 20,000 SigOps, a max block size of 2 MB permits 40,000 SigOps and so on.
Attention: As this fix is consensus critical, other implementation which allow blocks larger than 1MB should be aware of it. Please refer to BUIP040 for the exact details.
Additionally BU has a configurable "excessive transaction size" parameter. The default maximum size is limited to 1MB. Blocks with a transaction exceeding this size will be simply rejected.
It is possible to configure this value, in case the network has the capacity and business use-cases for allowing transactions >1MB. The command for the bitcoin.conf is net.excessiveTx=1000000. But it is not expected that a change in this setting will be network-wide for many years, if ever.
Attention: It is recommended to use the defaults.
Further information:
Github Repository PR#164
Discussion and Vote on BUIP40
✦ Removal of the 32 MB message limit
Satoshi Nakamoto implemented a 32MB message limit in Bitcoin. To prevent any future controversy about a hard fork to increase this limit, BU has removed it in advance with the expectation that, when it will be reached years ahead, everybody will have already upgraded their software. The maximum message limit varies from node to node as it equals excessive block size * 16.
P2P Network
✦ Wide-spectrum Anti-DoS improvements
Network traffic represents a grey-scale of useful activity. Some helps the network to synchronize, while some is for surveillance and deliberate wastage. Bitcoin Unlimited differentiates useful and less useful data between nodes.
Useful data is primarily valid transactions and blocks, invitations for required data, and handshake messages. Not useful data is typically seen with spam or spy nodes. From version 1.0.0 Bitcoin Unlimited nodes track the quality of data from peers.
1) All traffic is tracked by byte count, per connection, so the "usefulness" of data can be measured for what each node is sending or requesting to/from a BU node. On inbound messages, useful bytes are anything that is NOT: PING, PONG, VERACK, VERSION or ADDR messages. Outbound are the same but include transaction INVs. Furthermore the useful bytes are decayed over time, usually a day.
2) if a peer node does nothing useful within two minutes then the BU node chokes their INV traffic. A lot of spam nodes normally listen to INV traffic, and this is first of all a security concern as it is undesirable to allow anyone to just try and collate INV traffic, but also it's a large waste of bandwidth. So, quickly they are choked off but are still sent block INV's in case they are blocks-only nodes.
3) If rogue nodes try to reacquire a connection aggressively a BU node gives them a 4 hour ban.
There are other types of spam nodes that will do this, so using these three approaches keeps BU connection slots available for useful nodes and also for the bit-nodes crawlers that are determining the node counts.
✦ Request Manager extensions
Bitcoin Unlimited uses a Request Manager that tracks source nodes for blocks and transactions. If a request is filled slowly, it reissues the same request to a different source instead of just waiting and eventually timing out. The Request Manager was introduced to stabilize Xthin block propagation, but is generally helpful to improve the synchronization of the mempool and to manage resources efficiently.
Because synchronized mempools are important for Xpedited (unsolicited Xthin) it is "bad" for them to be non-synchronized when a node loses track of a source. Also, if an Xpedited block comes in, some transactions may be missing so we can look up sources for them in the request manager! We don't want to request from the xpedited source if we can avoid it, because that may be across the GFC. It is always better to get the transactions from a local source.
With this release, the Request Manager’s functionality is extended to the Initial Blockchain Download (IBD). It eliminates slowdowns and hung connections which occasionally happen when the request for blocks receives a slow response.
Further information:
GitHub: PR79
GitHub: PR229
✦ Xthin block propagation optimizations
Based on many months of live traffic observation, Bitcoin Unlimited implemented several general optimizations of the block propagation with Xthin. As tests have shown, this enables some nodes to operate with zero missing transactions in a 24-hour period and thus achieves extremely efficient use of bandwidth resources and minimal latency in block propagation.
continued...
The third official BU client release reflects our opinion that Bitcoin full-node software has reached a milestone of functionality, stability and scalability. Hence, completion of the alpha/beta phase throughout 2009-16 can be marked in our release version 1.0.0.
The most important feature of BU's first general release is functionality to restore market dynamics at the discretion of the full-node network. Activation will result in eliminating the full-blocks handicap, restoring a healthy fee-market, allow reliable confirmation times, fair user fees, and re-igniting stalled network effect growth, based on Bitcoin Unlimited’s Emergent Consensus model to let the ecosystem decide the best values of parameters like the maximum block size.
Bitcoin Unlimited open-source version 1.0.0 contains a large number of changes, updates and improvements. Some optimize the Emergent Consensus logic (EC), others improve the system in a more general way, and a number of updates are imported from the open source work of the Bitcoin Core developers who deserve full credit for their continued progress.
Changes are as follows:
Emergent Consensus (EC)
✦ Set Accepted Depth (AD) to 12 as default.
BU has a “sticky gate” (SG) mechanism which supports the functioning of EC.
SG means that if blocks are propagated which are bigger than a specific node's “Excessive Block Size” (EB) and subsequent blocks reach the node's "Acceptance Depth" (AD), then the node accepts, for 144 blocks, every block up to the size of its EB * 16. This mechanism is needed to ensure that nodes maintain consensus during an uptick in the network's record block size seen and written to the blockchain.
In co-operation with Bitcoin XT a potential attack on SG has been identified.
A minority hash-power attacker is probabilistically able to produce AD+1 blocks before the majority produces AD blocks, so it is possible that a sequence of very large blocks can be permanently included in the blockchain.
To make this attack much less likely and more expensive, the standard setting for Acceptance Depth is increased to 12. This value is the result of analysis and simulation. Note that due to variation in node settings only a subset of nodes will be in an SG situation at any one time.
Bitcoin Unlimited recommends miners and commercial node users set their Accepted Depth parameter to the value of 12.
Further information:
Discussion of Sticky Gate / the attack
Table with result of simulation
✦ Flexible Signature Operations (sigops) Limit and an Excessive Transaction Size
When a Bitcoin node validates transactions, it verifies signatures. These operations – Signature Operation, short SigOps – have CPU overhead. This makes it possible to build complex transactions which require significant time to be validated. This has long been a major concern against bigger blocks that tie up node processing and affect the synchronicity of the network, however, a "gossip network" is inherently more robust than other types.
BUIP040 introduces several changes to mitigate these attacks while adhering to the BU philosophy. The pre-existing limit of 20,000 per MB block size is enough to enable a wide scope of transactions, but mitigates against attacks. A block size of 1 MB permits 20,000 SigOps, a max block size of 2 MB permits 40,000 SigOps and so on.
Attention: As this fix is consensus critical, other implementation which allow blocks larger than 1MB should be aware of it. Please refer to BUIP040 for the exact details.
Additionally BU has a configurable "excessive transaction size" parameter. The default maximum size is limited to 1MB. Blocks with a transaction exceeding this size will be simply rejected.
It is possible to configure this value, in case the network has the capacity and business use-cases for allowing transactions >1MB. The command for the bitcoin.conf is net.excessiveTx=1000000. But it is not expected that a change in this setting will be network-wide for many years, if ever.
Attention: It is recommended to use the defaults.
Further information:
Github Repository PR#164
Discussion and Vote on BUIP40
✦ Removal of the 32 MB message limit
Satoshi Nakamoto implemented a 32MB message limit in Bitcoin. To prevent any future controversy about a hard fork to increase this limit, BU has removed it in advance with the expectation that, when it will be reached years ahead, everybody will have already upgraded their software. The maximum message limit varies from node to node as it equals excessive block size * 16.
P2P Network
✦ Wide-spectrum Anti-DoS improvements
Network traffic represents a grey-scale of useful activity. Some helps the network to synchronize, while some is for surveillance and deliberate wastage. Bitcoin Unlimited differentiates useful and less useful data between nodes.
Useful data is primarily valid transactions and blocks, invitations for required data, and handshake messages. Not useful data is typically seen with spam or spy nodes. From version 1.0.0 Bitcoin Unlimited nodes track the quality of data from peers.
1) All traffic is tracked by byte count, per connection, so the "usefulness" of data can be measured for what each node is sending or requesting to/from a BU node. On inbound messages, useful bytes are anything that is NOT: PING, PONG, VERACK, VERSION or ADDR messages. Outbound are the same but include transaction INVs. Furthermore the useful bytes are decayed over time, usually a day.
2) if a peer node does nothing useful within two minutes then the BU node chokes their INV traffic. A lot of spam nodes normally listen to INV traffic, and this is first of all a security concern as it is undesirable to allow anyone to just try and collate INV traffic, but also it's a large waste of bandwidth. So, quickly they are choked off but are still sent block INV's in case they are blocks-only nodes.
3) If rogue nodes try to reacquire a connection aggressively a BU node gives them a 4 hour ban.
There are other types of spam nodes that will do this, so using these three approaches keeps BU connection slots available for useful nodes and also for the bit-nodes crawlers that are determining the node counts.
✦ Request Manager extensions
Bitcoin Unlimited uses a Request Manager that tracks source nodes for blocks and transactions. If a request is filled slowly, it reissues the same request to a different source instead of just waiting and eventually timing out. The Request Manager was introduced to stabilize Xthin block propagation, but is generally helpful to improve the synchronization of the mempool and to manage resources efficiently.
Because synchronized mempools are important for Xpedited (unsolicited Xthin) it is "bad" for them to be non-synchronized when a node loses track of a source. Also, if an Xpedited block comes in, some transactions may be missing so we can look up sources for them in the request manager! We don't want to request from the xpedited source if we can avoid it, because that may be across the GFC. It is always better to get the transactions from a local source.
With this release, the Request Manager’s functionality is extended to the Initial Blockchain Download (IBD). It eliminates slowdowns and hung connections which occasionally happen when the request for blocks receives a slow response.
Further information:
GitHub: PR79
GitHub: PR229
✦ Xthin block propagation optimizations
Based on many months of live traffic observation, Bitcoin Unlimited implemented several general optimizations of the block propagation with Xthin. As tests have shown, this enables some nodes to operate with zero missing transactions in a 24-hour period and thus achieves extremely efficient use of bandwidth resources and minimal latency in block propagation.
continued...
Last edited:
