Merge branch 'master' of github.com:bitcoin/bips

README.mediawiki

@@ -374,6 +374,12 @@ Those proposing changes should consider that ultimately consent may rest with th
 | Standard
 | Draft
 |-
+| [[bip-0109.mediawiki|109]]
+| Two million byte size limit with sigop and sighash limits
+| Gavin Andresen
+| Standard
+| Draft
+|-
 | [[bip-0111.mediawiki|111]]
 | NODE_BLOOM service bit
 | Matt Corallo, Peter Todd

bip-0050.mediawiki

@@ -8,27 +8,29 @@
 </pre>
 
 ==What went wrong==
-A block that had a larger number of total transaction inputs than previously seen was mined and broadcasted. Bitcoin 0.8 nodes were able to handle this, but some pre-0.8 Bitcoin nodes rejected it, causing an unexpected hard fork of the chain. The pre-0.8 incompatible chain at that point had around 60% of the hash power ensuring the split did not automatically resolve.
+A block that had a larger number of total transaction inputs than previously seen was mined and broadcasted. Bitcoin 0.8 nodes were able to handle this, but some pre-0.8 Bitcoin nodes rejected it, causing an unexpected fork of the blockchain. The pre-0.8-incompatible chain (from here on, the 0.8 chain) at that point had around 60% of the mining hash power ensuring the split did not automatically resolve (as would have occurred if the pre-0.8 chain outpaced the 0.8 chain in total work, forcing 0.8 nodes to reorganise to the pre-0.8 chain).
 
-In order to restore a canonical chain as soon as possible, BTCGuild and Slush downgraded their Bitcoin 0.8 nodes to 0.7 so their pools would also reject the larger block. This placed majority hashpower on the chain without the larger block.
+In order to restore a canonical chain as soon as possible, BTCGuild and Slush downgraded their Bitcoin 0.8 nodes to 0.7 so their pools would also reject the larger block. This placed majority hashpower on the chain without the larger block, thus eventually causing the 0.8 nodes to reorganise to the pre-0.8 chain.
 
 During this time there was at least [https://bitcointalk.org/index.php?topic=152348.0 one large double spend].  However, it was done by someone experimenting to see if it was possible and was not intended to be malicious.
 
 ==What went right==
 * The split was detected very quickly.
-* The right people were online and available in IRC or could be raised via Skype.
-* Marek Palatinus and Michael Marsee quickly downgraded their nodes to restore a pre-0.8 chain as canonical, despite the fact that this caused them to sacrifice significant amounts of money and they were the ones running the bug-free version.
+* The right people were online and available in IRC or could be contacted directly.
+* Marek Palatinus (Slush) and Michael Marsee (Eleuthria of BTCGuild) quickly downgraded their nodes to restore a pre-0.8 chain as canonical, despite the fact that this caused them to sacrifice significant amounts of money.
 * Deposits to the major exchanges and payments via BitPay were also suspended (and then un-suspended) very quickly.
-* Fortunately, the only attack on a merchant was done by someone who was not intending to actually steal money
+* Fortunately, the only attack on a merchant was done by someone who was not intending to actually steal money.
 
 ==Root cause==
-Bitcoin versions prior to 0.8 configure an insufficient number of Berkeley DB locks to process large but technically valid blocks. Berkeley DB locks have to be manually configured by API users depending on anticipated load. The manual says this:
+Bitcoin versions prior to 0.8 configure an insufficient number of Berkeley DB locks to process large but otherwise valid blocks. Berkeley DB locks have to be manually configured by API users depending on anticipated load. The manual says this:
 
 :The recommended algorithm for selecting the maximum number of locks, lockers, and lock objects is to run the application under stressful conditions and then review the lock system's statistics to determine the maximum number of locks, lockers, and lock objects that were used. Then, double these values for safety.
 
+With the insufficiently high BDB lock configuration, it implicitly had become a network consensus rule determining block validity (albeit an inconsistent and unsafe rule, since the lock usage could vary from node to node).
+
 Because max-sized blocks had been successfully processed on the testnet, it did not occur to anyone that there could be blocks that were smaller but require more locks than were available. Prior to 0.7 unmodified mining nodes self-imposed a maximum block size of 500,000 bytes, which further prevented this case from being triggered. 0.7 made the target size configurable and miners had been encouraged to increase this target in the week prior to the incident.
 
-Bitcoin 0.8 does not use Berkeley DB. It uses LevelDB instead, which does not require this kind of pre-configuration. Therefore it was able to process the forking block successfully.
+Bitcoin Core 0.8 did not use Berkeley DB. It switched to LevelDB instead, which did not implement the same locking limits as BDB. Therefore it was able to process the forking block successfully.
 
 Note that BDB locks are also required during processing of re-organizations. Versions prior to 0.8 may be unable to process some valid re-orgs.
 
@@ -39,10 +41,10 @@ This would be an issue even if the entire network was running version 0.7.2. It
 ===Immediately===
 
 '''Done''': Release a version 0.8.1, forked directly from 0.8.0, that, for the next two months has the following new rules:
-# Reject blocks that could cause more than 10,000 locks to be taken.
+# Reject blocks that would probably could cause more than 10,000 locks to be taken.
 # Limit the maximum block-size created to 500,000 bytes
-# Release a patch for older versions that implements the same rules, but also increases the maximum number of locks to 120,000
-# Create a web page on bitcoin.org that will urge users to upgrade to 0.8.1, but will tell them how to set DB_CONFIG to 120,000 locks if they absolutely cannot.
+# Release a patch for older versions that implements the same rules, but also increases the maximum number of locks to 537,000
+# Create a web page on bitcoin.org that will urge users to upgrade to 0.8.1, but will tell them how to set DB_CONFIG to 537,000 locks if they absolutely cannot.
 # Over the next 2 months, send a series of alerts to users of older versions, pointing to the web page.
 
 ===Alert system===
@@ -70,3 +72,7 @@ A double spend attack was successful, despite that both sides of the chain heard
 ===Resolution===
 
 On 16 August, 2013 block 252,451 (0x0000000000000024b58eeb1134432f00497a6a860412996e7a260f47126eed07) was accepted by the main network, forking unpatched nodes off the network.
+
+==Copyright==
+
+This document is placed in the public domain.

bip-0068.mediawiki

@@ -64,21 +64,21 @@ enum {
 /* Setting nSequence to this value for every input in a transaction
  * disables nLockTime. */
 static const uint32_t SEQUENCE_FINAL = 0xffffffff;
-    
+
+/* Below flags apply in the context of BIP 68*/
 /* If this flag set, CTxIn::nSequence is NOT interpreted as a
- * relative lock-time. Setting the most significant bit of a
- * sequence number disabled relative lock-time. */
+ * relative lock-time. */
 static const uint32_t SEQUENCE_LOCKTIME_DISABLE_FLAG = (1 << 31);
-    
+
 /* If CTxIn::nSequence encodes a relative lock-time and this flag
  * is set, the relative lock-time has units of 512 seconds,
  * otherwise it specifies blocks with a granularity of 1. */
 static const uint32_t SEQUENCE_LOCKTIME_TYPE_FLAG = (1 << 22);
-    
+
 /* If CTxIn::nSequence encodes a relative lock-time, this mask is
  * applied to extract that lock-time from the sequence field. */
 static const uint32_t SEQUENCE_LOCKTIME_MASK = 0x0000ffff;
-    
+
 /* In order to use the same number of bits to encode roughly the
  * same wall-clock duration, and because blocks are naturally
  * limited to occur every 600s on average, the minimum granularity
@@ -87,7 +87,7 @@ static const uint32_t SEQUENCE_LOCKTIME_MASK = 0x0000ffff;
  * multiplying by 512 = 2^9, or equivalently shifting up by
  * 9 bits. */
 static const int SEQUENCE_LOCKTIME_GRANULARITY = 9;
-    
+
 /**
  * Calculates the block height and previous block's median time past at
  * which the transaction will be considered final in the context of BIP 68.
@@ -174,16 +174,17 @@ bool SequenceLocks(const CTransaction &tx, int flags, std::vector<int>* prevHeig
 bool CheckSequenceLocks(const CTransaction &tx, int flags)
 {
     AssertLockHeld(cs_main);
+    AssertLockHeld(mempool.cs);
 
     CBlockIndex* tip = chainActive.Tip();
     CBlockIndex index;
     index.pprev = tip;
     // CheckSequenceLocks() uses chainActive.Height()+1 to evaluate
     // height based locks because when SequenceLocks() is called within
-    // CBlock::AcceptBlock(), the height of the block *being*
-    // evaluated is what is used. Thus if we want to know if a
-    // transaction can be part of the *next* block, we need to call
-    // SequenceLocks() with one more than chainActive.Height().
+    // ConnectBlock(), the height of the block *being*
+    // evaluated is what is used.
+    // Thus if we want to know if a transaction can be part of the
+    // *next* block, we need to use one more than chainActive.Height()
     index.nHeight = tip->nHeight + 1;
 
     // pcoinsTip contains the UTXO set for chainActive.Tip()

bip-0109.mediawiki

@@ -0,0 +1,82 @@
+<pre>
+  BIP: 109
+  Title: Two million byte size limit with sigop and sighash limits
+  Author: Gavin Andresen <gavinandresen@gmail.com>
+  Status: Draft
+  Type: Standards Track
+  Created: 2016-01-28
+</pre>
+
+==Abstract==
+
+One-time increase in total amount of transaction data permitted in a block from 1MB to 2MB, with limits on signature operations and hashing.
+
+==Motivation==
+
+# Continue current economic policy.
+# Exercise hard fork network upgrade.
+# Mitigate potential CPU exhaustion attacks
+
+==Specification==
+
+=== MAX_BLOCK_SIZE increased to 2,000,000 bytes ===
+
+The maximum number of bytes in a canonically serialized block shall be increased from
+1,000,000 bytes to 2,000,000 bytes.
+
+=== Switch to accurately-counted sigop limit of 20,000 per block ===
+
+The existing MAX_SIGOPS limit of 20,000 signature operations per block shall be retained,
+but only ECDSA verifications actually performed to validate the block shall be counted.
+
+In particular:
+
+* The coinbase scriptSig is not counted
+* Signature operations in un-executed branches of a Script are not counted
+* OP_CHECKMULTISIG evaluations are counted accurately; if the signature for a 1-of-20 OP_CHECKMULTISIG is satisified by the public key nearest the top of the execution stack, it is counted as one signature operation. If it is satisfied by the public key nearest the bottom of the execution stack, it is counted as twenty signature operations.
+* Signature operations involving invalidly encoded signatures or public keys are not counted towards the limit
+
+=== Add a new limit of 1,300,000,000 bytes hashed to compute transaction signatures per block ===
+
+The amount of data hashed to compute signature hashes is limited to 1,300,000,000 bytes per block. The same rules for counting are used as for counting signature operations.
+
+=== Activation: 75% hashpower support trigger, followed by 28-day 'grace period' ===
+
+Solo miners or mining pool operators express their support for this BIP by setting the fourth-highest-bit in the block's 32-bit version number (0x10000000 in hex). The first block with that bit set, a timestamp less than or equal to the expiration time, and with at least 750 out of 1000 blocks preceding it (with heights H-1000..H-1) with that bit set, shall define the beginning of a grace period. Blocks with timestamps greater than or equal to the triggering block's timestamp plus 28 days (60*60*24*28 seconds) shall be subject to the new limits.
+
+As always, miners are expected to use their best judgement for what is best for the entire Bitcoin ecosystem when making decisions about what consensus-level changes to support.
+
+=== Expiration: 1-Jan-2018 ===
+
+If this BIP is not triggered before 1-Jan-2018 00:00:00 GMT it should be considered withdrawn.
+
+Miners that support this BIP should set bit 0x10000000 in the block version until 1-Jan-2018. After that date, that bit can be safely re-used for future consensus rule upgrades.
+
+==Backward compatibility==
+
+Fully validating older clients are not compatible with this change.
+The first block exceeding the old limits on block size or inaccurately counted signature operations will partition older clients off the new network.
+
+SPV (simple payment validation) wallets are compatible with this change.
+
+==Rationale==
+
+In the short term, an increase is needed to handle increasing transaction volume. 
+
+The limits on signature operations and amount of signature hashing done prevent possible CPU exhaustion attacks by "rogue miners" producing very expensive-to-validate two megabyte blocks. The signature hashing limit is chosen to be impossible to reach with any non-attack transaction or block, to minimize the impact on existing mining or wallet software.
+
+The choices of constants for the deployment scheme were motivated by prior experience with upgrades to the Bitcoin consensus rules:
+
+* 0x10000000 was chosen to be compatible with the BIP 9 proposal for parallel deployment of soft forks
+* 75% was chosen instead of 95% to minimize the opportunity for a single large mining pool or miner to be able to veto an increase, either because of ideological opposition or threat of violence or extortion.
+* A four-week grace period after the voting period was chosen as a balance between giving people sufficient time to upgrade and keeping people's attention on the urgent need to upgrade.
+
+==Implementation==
+
+https://github.com/gavinandresen/bitcoin-git/tree/two_mb_bump
+
+See also http://gavinandresen.ninja/a-guided-tour-of-the-2mb-fork
+
+==Copyright==
+
+This work is placed in the public domain.