diff options
| -rw-r--r-- | README.mediawiki | 14 | ||||
| -rw-r--r-- | bip-0009.mediawiki | 2 | ||||
| -rw-r--r-- | bip-0039.mediawiki | 2 | ||||
| -rw-r--r-- | bip-0114.mediawiki | 2 | ||||
| -rw-r--r-- | bip-0124.mediawiki | 2 | ||||
| -rw-r--r-- | bip-0135.mediawiki | 2 | ||||
| -rw-r--r-- | bip-0155.mediawiki | 40 | ||||
| -rw-r--r-- | bip-0174.mediawiki | 34 | ||||
| -rw-r--r-- | bip-0325.mediawiki | 3 |
9 files changed, 61 insertions, 40 deletions
diff --git a/README.mediawiki b/README.mediawiki index ca28339..720d4f5 100644 --- a/README.mediawiki +++ b/README.mediawiki @@ -398,7 +398,7 @@ Those proposing changes should consider that ultimately consent may rest with th | Bustapay :: a practical coinjoin protocol | Ryan Havar | Informational -| Proposed +| Replaced |- | [[bip-0080.mediawiki|80]] | @@ -546,13 +546,13 @@ Those proposing changes should consider that ultimately consent may rest with th | Thomas Kerin, Mark Friedenbach | Standard | Final -|- +|- style="background-color: #ffcfcf" | [[bip-0114.mediawiki|114]] | Consensus (soft fork) | Merkelized Abstract Syntax Tree | Johnson Lau | Standard -| Draft +| Rejected |- style="background-color: #ffcfcf" | [[bip-0115.mediawiki|115]] | Consensus (soft fork) @@ -616,13 +616,13 @@ Those proposing changes should consider that ultimately consent may rest with th | Eric Lombrozo | Process | Active -|- +|- style="background-color: #ffcfcf" | [[bip-0124.mediawiki|124]] | Applications | Hierarchical Deterministic Script Templates | Eric Lombrozo, William Swanson | Informational -| Draft +| Rejected |- style="background-color: #ffffcf" | [[bip-0125.mediawiki|125]] | Applications @@ -679,13 +679,13 @@ Those proposing changes should consider that ultimately consent may rest with th | Tom Zander | Standard | Rejected -|- +|- style="background-color: #ffcfcf" | [[bip-0135.mediawiki|135]] | | Generalized version bits voting | Sancho Panza | Informational -| Draft +| Rejected |- | [[bip-0136.mediawiki|136]] | Applications diff --git a/bip-0009.mediawiki b/bip-0009.mediawiki index a68bb80..f90919a 100644 --- a/bip-0009.mediawiki +++ b/bip-0009.mediawiki @@ -217,7 +217,7 @@ Soft forks right now are typically treated as booleans: they go from an inactive The failure timeout allows eventual reuse of bits even if a soft fork was never activated, so it's clear that the new use of the bit refers to a -new BIP. It's deliberately very course grained, to take into account +new BIP. It's deliberately very coarse-grained, to take into account reasonable development and deployment delays. There are unlikely to be enough failed proposals to cause a bit shortage. diff --git a/bip-0039.mediawiki b/bip-0039.mediawiki index 2b95c51..9d7fdda 100644 --- a/bip-0039.mediawiki +++ b/bip-0039.mediawiki @@ -168,7 +168,9 @@ Rust: Swift: * https://github.com/CikeQiu/CKMnemonic * https://github.com/yuzushioh/WalletKit +* https://github.com/pengpengliu/BIP39 * https://github.com/matter-labs/web3swift/blob/develop/Sources/web3swift/KeystoreManager/BIP39.swift +* https://github.com/zcash-hackworks/MnemonicSwift C++: * https://github.com/libbitcoin/libbitcoin-system/blob/master/include/bitcoin/system/wallet/mnemonic.hpp diff --git a/bip-0114.mediawiki b/bip-0114.mediawiki index 21d0b6c..410e84c 100644 --- a/bip-0114.mediawiki +++ b/bip-0114.mediawiki @@ -5,7 +5,7 @@ Author: Johnson Lau <jl2012@xbt.hk> Comments-Summary: No comments yet. Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0114 - Status: Draft + Status: Rejected Type: Standards Track Created: 2016-04-02 License: PD diff --git a/bip-0124.mediawiki b/bip-0124.mediawiki index a5929ac..69cb134 100644 --- a/bip-0124.mediawiki +++ b/bip-0124.mediawiki @@ -6,7 +6,7 @@ William Swanson <swansontec@gmail.com> Comments-Summary: No comments yet. Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0124 - Status: Draft + Status: Rejected Type: Informational Created: 2015-11-20 License: PD diff --git a/bip-0135.mediawiki b/bip-0135.mediawiki index 89d3077..1324746 100644 --- a/bip-0135.mediawiki +++ b/bip-0135.mediawiki @@ -5,7 +5,7 @@ Comments-Summary: No comments yet. Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0135 https://bitco.in/forum/threads/bip9-generalized-version-bits-voting-bip-genvbvoting.1968/ - Status: Draft + Status: Rejected Type: Informational Created: 2017-03-29 License: CC0-1.0 diff --git a/bip-0155.mediawiki b/bip-0155.mediawiki index 5914241..f437043 100644 --- a/bip-0155.mediawiki +++ b/bip-0155.mediawiki @@ -46,7 +46,7 @@ The <code>addrv2</code> message is defined as a message where <code>pchCommand = It is serialized in the standard encoding for P2P messages. Its format is similar to the current <code>addr</code> message format <ref>[https://bitcoin.org/en/developer-reference#addr Bitcoin Developer Reference: addr message]</ref>, with the difference that the -fixed 16-byte IP address is replaced by a network ID and a variable-length address, and the time and services format has been changed to VARINT. +fixed 16-byte IP address is replaced by a network ID and a variable-length address, and the services format has been changed to [https://en.bitcoin.it/wiki/Protocol_documentation#Variable_length_integer CompactSize]. This means that the message contains a serialized <code>std::vector</code> of the following structure: @@ -55,13 +55,13 @@ This means that the message contains a serialized <code>std::vector</code> of th !Name !Description |- -| <code>VARINT</code> (unsigned) +| <code>uint32_t</code> | <code>time</code> -| Time that this node was last seen as connected to the network. A time in Unix epoch time format, up to 64 bits wide. +| Time that this node was last seen as connected to the network. A time in Unix epoch time format. |- -| <code>VARINT</code> (unsigned) +| <code>CompactSize</code> | <code>services</code> -| Service bits. A 64-wide bit field. +| Service bits. A bit field that is 64 bits wide, encoded in [https://en.bitcoin.it/wiki/Protocol_documentation#Variable_length_integer CompactSize]. |- | <code>uint8_t</code> | <code>networkID</code> @@ -78,8 +78,8 @@ This means that the message contains a serialized <code>std::vector</code> of th One message can contain up to 1,000 addresses. Clients SHOULD reject messages with more addresses. -Field <code>addr</code> has a variable length, with a maximum of 32 bytes (256 bits). Clients SHOULD reject -longer addresses. +Field <code>addr</code> has a variable length, with a maximum of 512 bytes (4096 bits). +Clients SHOULD reject messages with longer addresses, irrespective of the network ID. The list of reserved network IDs is as follows: @@ -120,21 +120,23 @@ The list of reserved network IDs is as follows: | Cjdns overlay network address |} -To allow for future extensibility, clients MUST ignore address types that they do not know about. -Client MAY store and gossip address formats that they do not know about. Further network ID numbers MUST be reserved in a new BIP document. +Clients are RECOMMENDED to gossip addresses from all known networks even if they are currently not connected to some of them. That could help multi-homed nodes and make it more difficult for an observer to tell which networks a node is connected to. -Clients SHOULD reject addresses that have a different length than specified in this table for a specific address ID, as these are meaningless. +Clients SHOULD NOT gossip addresses from unknown networks because they have no means to validate those addresses and so can be tricked to gossip invalid addresses. + +Further network ID numbers MUST be reserved in a new BIP document. + +Clients SHOULD reject messages that contain addresses that have a different length than specified in this table for a specific network ID, as these are meaningless. See the appendices for the address encodings to be used for the various networks. -==Compatibility== +==Signaling support and compatibility== + +Introduce a new message type <code>sendaddrv2</code>. Sending such a message indicates that a node can understand and prefers to receive <code>addrv2</code> messages instead of <code>addr</code> messages. I.e. "Send me addrv2". -Send <code>addrv2</code> messages only, and exclusively, when the peer has a certain protocol version (or higher): -<source lang="c++"> -//! gossiping using `addrv2` messages starts with this version -static const int GOSSIP_ADDRV2_VERSION = 70016; -</source> -For older peers keep sending the legacy <code>addr</code> message, ignoring addresses with the newly introduced address types. +<code>sendaddrv2</code> SHOULD be sent after receiving the <code>verack</code> message from the peer. + +For older peers, that did not emit <code>sendaddrv2</code>, keep sending the legacy <code>addr</code> message, ignoring addresses with the newly introduced address types. ==Reference implementation== @@ -142,9 +144,7 @@ The reference implementation is available at (to be done) ==Acknowledgements== -- Jonas Schnelli: change <code>services</code> field to VARINT, to make the message more compact in the likely case instead of always using 8 bytes. - -- Luke-Jr: change <code>time</code> field to VARINT, for post-2038 compatibility. +- Jonas Schnelli: change <code>services</code> field to [https://en.bitcoin.it/wiki/Protocol_documentation#Variable_length_integer CompactSize], to make the message more compact in the likely case instead of always using 8 bytes. - Gregory Maxwell: various suggestions regarding extensibility diff --git a/bip-0174.mediawiki b/bip-0174.mediawiki index 65fa9a9..c424c5d 100644 --- a/bip-0174.mediawiki +++ b/bip-0174.mediawiki @@ -200,25 +200,25 @@ The currently defined per-input types are defined as follows: ** Value: The UTF-8 encoded commitment message string for the proof-of-reserves. See [[bip-0127.mediawiki|BIP 127]] for more information. *** <tt>{porCommitment}</tt> -* Type: RIPEMD160 preimage <tt>PSBT_RIPEMD160 = 0x0a</tt> +* Type: RIPEMD160 preimage <tt>PSBT_IN_RIPEMD160 = 0x0a</tt> ** Key: The resulting hash of the preimage *** <tt>{0x0a}|{20-byte hash}</tt> ** Value: The hash preimage, encoded as a byte vector, which must equal the key when run through the `RIPEMD160` algorithm *** <tt>{preimage}</tt> -* Type: SHA256 preimage <tt>PSBT_SHA256 = 0x0b</tt> +* Type: SHA256 preimage <tt>PSBT_IN_SHA256 = 0x0b</tt> ** Key: The resulting hash of the preimage *** <tt>{0x0b}|{32-byte hash}</tt> ** Value: The hash preimage, encoded as a byte vector, which must equal the key when run through the `SHA256` algorithm *** <tt>{preimage}</tt> -* Type: HASH160 preimage <tt>PSBT_HASH160 = 0x0c</tt> +* Type: HASH160 preimage <tt>PSBT_IN_HASH160 = 0x0c</tt> ** Key: The resulting hash of the preimage *** <tt>{0x0c}|{20-byte hash}</tt> ** Value: The hash preimage, encoded as a byte vector, which must equal the key when run through the `SHA256` algorithm followed by the `RIPEMD160` algorithm *** <tt>{preimage}</tt> -* Type: HASH256 preimage <tt>PSBT_HASH256 = 0x0d</tt> +* Type: HASH256 preimage <tt>PSBT_IN_HASH256 = 0x0d</tt> ** Key: The resulting hash of the preimage *** <tt>{0x0d}|{32-byte hash}</tt> ** Value: The hash preimage, encoded as a byte vector, which must equal the key when run through the `SHA256` algorithm twice @@ -350,9 +350,9 @@ It is useful when there are additional data that they need attached to a PSBT bu The proprietary use type is not to be used by any public specification and there is no expectation that any publicly available software be able to understand any specific meanings of it and the subtypes. This type must be used for internal processes only. -==Responsibilities== +==Roles== -Using the transaction format involves many different responsibilities. Multiple responsibilities can be handled by a single entity, but each responsibility is specialized in what it should be capable of doing. +Using the transaction format involves many different roles. Multiple roles can be handled by a single entity, but each role is specialized in what it should be capable of doing. ===Creator=== @@ -373,7 +373,7 @@ The Signer must only accept a PSBT. The Signer must only use the UTXOs provided in the PSBT to produce signatures for inputs. Before signing a non-witness input, the Signer must verify that the TXID of the non-witness UTXO matches the TXID specified in the unsigned transaction. Before signing a witness input, the Signer must verify that the witnessScript (if provided) matches the hash specified in the UTXO or the redeemScript, and the redeemScript (if provided) matches the hash in the UTXO. -The Signer may choose to fail to sign a segwit input if a non-witness UTXO is not provided. <ref>'''Why would non-witness UTXOs be provided for segwit inputs?''' The sighash algorithm for Segwit specified in BIP 173 is known to have an issue where an attacker could trick a user to sending Bitcoin to fees if they are able to convince the user to sign a malicious transaction multiple times. This is possible because the amounts in <tt>PSBT_IN_WITNESS_UTXO<tt> of other segwit inputs can be modified without effecting the signature for a particular input. In order to prevent this kind of attack, many wallets are requiring that the full previous transaction (i.e. <tt>PSBT_IN_NON_WITNESS_UTXO</tt>) be provided to ensure that the amounts of other inputs are not being tampered with.</ref> +The Signer may choose to fail to sign a segwit input if a non-witness UTXO is not provided. <ref>'''Why would non-witness UTXOs be provided for segwit inputs?''' The sighash algorithm for Segwit specified in BIP 173 is known to have an issue where an attacker could trick a user to sending Bitcoin to fees if they are able to convince the user to sign a malicious transaction multiple times. This is possible because the amounts in <tt>PSBT_IN_WITNESS_UTXO</tt> of other segwit inputs can be modified without effecting the signature for a particular input. In order to prevent this kind of attack, many wallets are requiring that the full previous transaction (i.e. <tt>PSBT_IN_NON_WITNESS_UTXO</tt>) be provided to ensure that the amounts of other inputs are not being tampered with.</ref> The Signer should not need any additional data sources, as all necessary information is provided in the PSBT format. The Signer must only add data to a PSBT. Any signatures created by the Signer must be added as a "Partial Signature" key-value pair for the respective input it relates to. @@ -839,6 +839,26 @@ Any data types, their associated scope and BIP number must be defined here | [[bip-0127.mediawiki|BIP 127]] |- | Input +| 10 +| PSBT_IN_RIPEMD160 +| BIP 174 +|- +| Input +| 11 +| PSBT_IN_SHA256 +| BIP 174 +|- +| Input +| 12 +| PSBT_IN_HASH160 +| BIP 174 +|- +| Input +| 13 +| PSBT_IN_HASH256 +| BIP 174 +|- +| Input | 252 | PSBT_IN_PROPRIETARY | BIP 174 diff --git a/bip-0325.mediawiki b/bip-0325.mediawiki index f25b87b..b5b25e1 100644 --- a/bip-0325.mediawiki +++ b/bip-0325.mediawiki @@ -21,7 +21,6 @@ Testnet is a great place to try out new things without risking real money, but i A new type of test network would be more suitable for integration testing by organizations such as exchanges, or testing of next generation Layer-2 protocols like Eltoo or sidechain pegs. The goal is not to be perfectly reliable but rather to have a predictable amount of unreliability. You want a test network to behave like mainnet (i.e. no thousands of block reorgs) while also making it easier to trigger expected but rare events like a 6-block reorg. Regtest is not suitable for longer-term scenarios involving multiple independent parties because creating blocks costs nothing, so any party can completely control the test network. - == Specification == A new type of network ("signet"), which takes an additional consensus parameter called the challenge (scriptPubKey). The challenge can be a simple pubkey (P2PKH style), or a k-of-n multisig, or any other script you would want. @@ -33,7 +32,7 @@ The witness commitment of the coinbase transaction is extended to include a seco x bytes - scriptSig y bytes - scriptWitness -The scriptSig is serialized by first encoding its length as CompactSize. If the scriptWitness is empty, it is encoded as 0 bytes, otherwise it is encoded in the usual way (see BIP 141 "witness" encoding). +The scriptSig is serialized by first encoding its length as CompactSize. The scriptWitness stack is serialized as described in BIP 141. Any push operations that do not start with the 4 byte Signet header are ignored. Multiple push operations with the 4 byte Signet header are ignored except for the first instance of the header. |