diff options
| -rw-r--r-- | README.mediawiki | 6 | ||||
| -rw-r--r-- | bip-0062.mediawiki | 2 | ||||
| -rw-r--r-- | bip-0066.mediawiki | 2 | ||||
| -rw-r--r-- | bip-0067.mediawiki | 4 | ||||
| -rw-r--r-- | bip-0101.mediawiki | 2 | ||||
| -rw-r--r-- | bip-0105.mediawiki | 100 | ||||
| -rw-r--r-- | bip-0111.mediawiki | 85 |
7 files changed, 196 insertions, 5 deletions
diff --git a/README.mediawiki b/README.mediawiki index 61ad381..0a5588a 100644 --- a/README.mediawiki +++ b/README.mediawiki @@ -290,6 +290,12 @@ Those proposing changes should consider that ultimately consent may rest with th | Standard | Draft |- +| [[bip-0111.mediawiki|111]] +| NODE_BLOOM service bit +| Matt Corallo and Peter Todd +| Standard +| Draft +|- | [[bip-0120.mediawiki|120]] | Proof of Payment | Kalle Rosenbaum diff --git a/bip-0062.mediawiki b/bip-0062.mediawiki index 7bd88a6..feb4d58 100644 --- a/bip-0062.mediawiki +++ b/bip-0062.mediawiki @@ -38,7 +38,7 @@ The first six and part of the seventh can be fixed by extra consensus rules, but ===New rules=== Seven extra rules are introduced, to combat exactly the seven first sources of malleability listed above: -# '''Canonically encoded ECDSA signatures''' An ECDSA signature passed to OP_CHECKSIG, OP_CHECKSIGVERIFY, OP_CHECKMULTISIG or OP_CHECKMULTISIGVERIFY must be encoded using strict DER encoding. To provide a compact way to deliberately create an invalid signature for with OP_CHECKSIG and OP_CHECKMULTISIG the empty byte array (the result of OP_0) is also allowed. Doing a verification with a non-DER signature makes the entire script evaluate to False (not just the signature verification). See reference: [[#der-encoding|DER encoding]]. +# '''Canonically encoded ECDSA signatures''' An ECDSA signature passed to OP_CHECKSIG, OP_CHECKSIGVERIFY, OP_CHECKMULTISIG or OP_CHECKMULTISIGVERIFY must be encoded using strict DER encoding. To provide a compact way to deliberately create an invalid signature for OP_CHECKSIG and OP_CHECKMULTISIG, an empty byte array (i.e., the result of OP_0) is also allowed. Doing a verification with a non-DER signature makes the entire script evaluate to False (not just the signature verification). See reference: [[#der-encoding|DER encoding]]. # '''Non-push operations in scriptSig''' Only data pushes are allowed in scriptSig. Evaluating any other operation makes the script evaluate to false. See reference: [[#push-operators|Push operators]]. # '''Push operations in scriptSig of non-standard size type''' The smallest possible push operation must be used when possible. Pushing data using an operation that could be encoded in a shorter way makes the script evaluate to false. See reference: [[#push-operators|Push operators]]. # '''Zero-padded number pushes''' Any time a script opcode consumes a stack value that is interpreted as a number, it must be encoded in its shortest possible form. 'Negative zero' is not allowed. See reference: [[#numbers|Numbers]]. diff --git a/bip-0066.mediawiki b/bip-0066.mediawiki index 41cbd8f..1235afd 100644 --- a/bip-0066.mediawiki +++ b/bip-0066.mediawiki @@ -2,7 +2,7 @@ BIP: 66 Title: Strict DER signatures Author: Pieter Wuille <pieter.wuille@gmail.com> - Status: Draft + Status: Final Type: Standards Track Created: 2015-01-10 </pre> diff --git a/bip-0067.mediawiki b/bip-0067.mediawiki index 9c4f3de..8be5c9b 100644 --- a/bip-0067.mediawiki +++ b/bip-0067.mediawiki @@ -4,8 +4,8 @@ Title: Deterministic Pay-to-script-hash multi-signature addresses through public key sorting Author: Thomas Kerin, Jean-Pierre Rupp, Ruben de Vries Status: Draft - Type: Standard - Created: 8 February 2015 + Type: Standards Track + Created: 2015-02-08 </pre> ==Abstract== diff --git a/bip-0101.mediawiki b/bip-0101.mediawiki index 9a78255..a76db0f 100644 --- a/bip-0101.mediawiki +++ b/bip-0101.mediawiki @@ -44,7 +44,7 @@ Expressed in pseudo-code, using integer math, assuming that block_timestamp is a Deployment shall be controlled by hash-power supermajority vote (similar to the technique used in BIP34), but the earliest possible activation time is 2016-01-11 00:00:00 UTC. -Activation is achieved when 750 of 1,000 consecutive blocks in the best chain have a version number with bits 1,2,3 and 14 set (0x20000007 in hex). The activation time will be the timestamp of the 750'th block plus a two week (1,209,600 second) grace period to give any remaining miners or services time to upgrade to support larger blocks. If a supermajority is achieved more than two weeks before 2016-01-11 00:00:00 UTC, the activation time will be 2016-01-11 00:00:00 UTC. +Activation is achieved when 750 of 1,000 consecutive blocks in the best chain have a version number with the first, second, third, and thirtieth bits set (0x20000007 in hex). The activation time will be the timestamp of the 750'th block plus a two week (1,209,600 second) grace period to give any remaining miners or services time to upgrade to support larger blocks. If a supermajority is achieved more than two weeks before 2016-01-11 00:00:00 UTC, the activation time will be 2016-01-11 00:00:00 UTC. Block version numbers are used only for activation; once activation is achieved, the maximum block size shall be as described in the specification section, regardless of the version number of the block. diff --git a/bip-0105.mediawiki b/bip-0105.mediawiki new file mode 100644 index 0000000..7aaef04 --- /dev/null +++ b/bip-0105.mediawiki @@ -0,0 +1,100 @@ +<pre> + BIP: 105 + Title: Consensus based block size retargeting algorithm + Author: BtcDrak <btcdrak@gmail.com> + Status: Draft + Type: Standards Track + Created: 2015-08-21 +</pre> + +==Abstract== + +A method of altering the maximum allowed block size of the Bitcoin protocol +using a consensus based approach. + +==Motivation== + +There is a belief that Bitcoin cannot easily respond to raising the +blocksize limit if popularity was to suddenly increase due to a mass adoption +curve, because co-ordinating a hard fork takes considerable time, and being +unable to respond in a timely manner would irreparably harm the credibility of +bitcoin. + +Additionally, predetermined block size increases are problematic because they +attempt to predict the future, and if too large could have unintended +consequences like damaging the possibility for a fee market to develop +as block subsidy decreases substantially over the next 9 years; introducing +or exacerbating mining attack vectors; or somehow affect the network in unknown +or unpredicted ways. Since fixed changes are hard to deploy, the damage could be +extensive. + +Dynamic block size adjustments also suffer from the potential to be gamed by the +larger hash power. + +Free voting as suggested by BIP100 allows miners to sell their votes out of band +at no risk, and enable the sponsor the ability to manipulate the blocksize. +It also provides a cost free method or the larger pools to vote in ways to +manipulate the blocksize such to disadvantage or attack smaller pools. + + +==Rationale== + +By introducing a cost to increase the block size ensures the mining community +will collude to increase it only when there is a clear necessity, and reduce it +when it is unnecessary. Larger miners cannot force their wishes so easily +because not only will they have to pay extra a difficulty target, then can be +downvoted at no cost by the objecting hash power. + +Using difficulty as a penalty is better than a fixed cost in bitcoins because it +is less predictable. + +In order to prevent miners having complete control over blocksize, an upper +limit is required at protocol level. This feature ensures full nodes retain +control over consensus, remembering full nodes are the mechanism to keep miners +honest. + + +==Specification== + +The initial block size limit shall be 1MB. + +Each time a miner creates a block, they may vote to increase or decrease the +blocksize by a maximum of 10% of the current block size limit. These votes will +be used to recalculate the new block size limit every 2016 blocks. + +Votes are cast using the block's coinbase field. + +The first 4 bytes of the coinbase field shall be repurposed for voting as an +unsigned long integer which will be the block size in bytes. + +If a miner votes for an increase, the block hash must meet a difficulty target +which is proportionally larger than the standard difficulty target based on the +percentage increase they voted for. + +Votes proposing decreasing the block size limit do not need to meet a higher +difficulty target. + +Miners can vote for no change by voting for the current block size. + +For blocks to be valid the blockhash must meet the required difficulty target +for the vote otherwise the block is invalid and will be rejected. + +Every 2016 blocks, the block size limit will be recalculated by the median of +all votes in the last 2016 blocks. This will redefine the block size limit for +the next 2016 blocks. + +Blocks that are larger than the calculated base block size limit are invalid and +will be rejected. + +The base block size limit may not reduce below 1MB or increase above 8MB. + + +==Acknowledgements== + +This proposal is based on ideas and concepts derived from the writings of +Meni Rosenfeld and Gregory Maxwell. + + +==Copyright== + +This work is placed in the public domain. diff --git a/bip-0111.mediawiki b/bip-0111.mediawiki new file mode 100644 index 0000000..d3bd630 --- /dev/null +++ b/bip-0111.mediawiki @@ -0,0 +1,85 @@ +<pre> + BIP: 111 + Title: NODE_BLOOM service bit + Author: Matt Corallo <bip@bluematt.me>, Peter Todd <pete@petertodd.org> + Status: Draft + Type: Standards Track + Created: 2015-08-20 +</pre> + +== Abstract == + +This BIP extends BIP 37, Connection Bloom filtering, by defining a +service bit to allow peers to advertise that they support bloom filters +explicitly. It also bumps the protocol version to allow peers to +identify old nodes which allow bloom filtering of the connection despite +lacking the new service bit. + + +== Motivation == + +BIP 37 did not specify a service bit for the bloom filter service, thus +implicitly assuming that all nodes that serve peers data support it. +However, the connection filtering algorithm proposed in BIP 37, and +implemented in several clients today, has been shown to provide little +to no privacy<ref>http://eprint.iacr.org/2014/763</ref>, as well as being a large DoS risk on some nodes<ref>[http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2013-July/003044.html] is one example where the issues were found, though others independently discovered issues as well. Sample DoS exploit code available at https://github.com/petertodd/bloom-io-attack.</ref>. +Thus, allowing node operators to disable connection bloom filtering is a +much-needed feature. + + +== Specification == + +The following protocol bit is added: + +<pre> + NODE_BLOOM = (1 << 2) +</pre> + +Nodes which support bloom filters should set that protocol bit. +Otherwise it should remain unset. In addition the protocol version is +increased from 70002 to 70011 in the reference implementation. It is +often the case that nodes which have a protocol version smaller than +70011, but larger than 70000 support bloom filtered connections without +the NODE_BLOOM bit set, however clients which require bloom filtered +connections should avoid making this assumption. + +NODE_BLOOM is distinct from NODE_NETWORK, and it is legal to advertise +NODE_BLOOM but not NODE_NETWORK (though there is little reason to do +so now, some proposals may make this more useful in the future) + +If a node does not support bloom filters but receives a "filterload", +"filteradd", or "filterclear" message from a peer the node should +disconnect that peer immediately. For backwards compatibility, in +initial implementations, nodes may choose to only disconnect nodes which +have the new protocol version set and attempt to send a filter command. + +While outside the scope of this BIP it is suggested that DNS seeds and +other peer discovery mechanisms support the ability to specify the +services required; current implementations simply check only that +NODE_NETWORK is set. + + +== Design rational == + +A service bit was chosen as applying a bloom filter is a service. + +The increase in protocol version is for backwards compatibility. In +initial implementations, old nodes which are not yet aware of NODE_BLOOM +and use a protocol version < 70011 may still send filter messages to a +node without NODE_BLOOM. This feature may be removed after there are +sufficient NODE_BLOOM nodes available and SPV clients have upgraded, +allowing node operators to fully close the bloom-related DoS vectors. + + +== Reference Implementation == + +https://github.com/bitcoin/bitcoin/pull/6579 + + +== Copyright == + +This document is placed in the public domain. + + +== References == +<references> |