diff options
| -rw-r--r-- | README.mediawiki | 12 | ||||
| -rw-r--r-- | bip-0080.mediawiki | 75 | ||||
| -rw-r--r-- | bip-0081.mediawiki | 72 | ||||
| -rw-r--r-- | bip-0122.mediawiki | 24 | ||||
| -rw-r--r-- | bip-0141.mediawiki | 42 | ||||
| -rw-r--r-- | bip-0142.mediawiki | 2 | ||||
| -rw-r--r-- | bip-0144.mediawiki | 6 |
7 files changed, 206 insertions, 27 deletions
diff --git a/README.mediawiki b/README.mediawiki index 87e6117..045fd28 100644 --- a/README.mediawiki +++ b/README.mediawiki @@ -302,6 +302,18 @@ Those proposing changes should consider that ultimately consent may rest with th | Standard | Draft |- +| [[bip-0080.mediawiki|80]] +| Hierarchy for Non-Colored Voting Pool Deterministic Multisig Wallets +| Monetas +| Informational +| Draft +|- +| [[bip-0081.mediawiki|81]] +| Hierarchy for Colored Voting Pool Deterministic Multisig Wallets +| Monetas +| Informational +| Draft +|- | [[bip-0083.mediawiki|83]] | Dynamic Hierarchical Deterministic Key Trees | Eric Lombrozo diff --git a/bip-0080.mediawiki b/bip-0080.mediawiki new file mode 100644 index 0000000..f28bb70 --- /dev/null +++ b/bip-0080.mediawiki @@ -0,0 +1,75 @@ +<pre> + BIP: 80 + Title: Hierarchy for Non-Colored Voting Pool Deterministic Multisig Wallets + Authors: Justus Ranvier <justus@monetas.net> + Jimmy Song <jimmy@monetas.net> + Status: Draft + Type: Informational + Created: 2014-08-11 +</pre> + +==Abstract== + +This BIP defines a logical hierarchy for non-colored voting pool deterministic multisig wallets based on an algorithm described in BIP-0032 (BIP32 from now on) and purpose scheme described in BIP-0043 (BIP43 from now on). + +This BIP is a particular application of BIP43 and is based on BIP44. + +==Motivation== + +The hierarchy proposed in this paper allows the handling of multiple coins and multiple series from a single seed. + +==Path levels== + +We define the following 4 levels in BIP32 path: + +<pre> +m / purpose' / coin_type' / series' / address_index +</pre> + +Apostrophe in the path indicates that BIP32 hardened derivation is used. + +Each level has a special meaning, described in the chapters below. + +===Purpose=== + +Purpose is a constant set following the BIP43 recommendation to: the ASCII value of "80" with the most signifigant bit set to indicate hardened derivation (0x80000050). It indicates that the subtree of this node is used according to this specification. + +Hardened derivation is used at this level. + +===Coin type=== + +One master node (seed) can be used for unlimited number of independent cryptocoins such as Bitcoin, Litecoin or Namecoin. However, sharing the same space for various cryptocoins has some disadvantages. + +This level creates a separate subtree for every cryptocoin, avoiding reusing addresses across cryptocoins and improving privacy issues. + +Coin type is a constant, set for each cryptocoin. The list of registered coin type constants should be obtained from BIP44. + +Hardened derivation is used at this level. + +===Series=== + +Series are used by voting pools in order to implement FIFO cold storage. By directing deposits into multiple series, the private keys for most of the deposits can be kept offline, and a limited portion can be brought online to process withdrawals. + +Hardened derivation is used at this level. + +===Index=== + +Public/private keypairs are numbered from index 0 in sequentially increasing manner. This number is used as child index in BIP32 derivation. + +Public keys obtained at this level of the heirarchy are used to construct multisig deposit scripts, using a schema that is shared between the members as an out-of-band contract. + +Public derivation is used at this level. + +==Compatible wallets== + +* [[https://github.com/btcsuite/btcwallet|btcwallet]] is the reference Bitcoin wallet for voting pools. + +==Copyright== + +This document is placed in the public domain. + +==Reference== + +* [[bip-0032.mediawiki|BIP32 - Hierarchical Deterministic Wallets]] +* [[bip-0043.mediawiki|BIP43 - Purpose Field for Deterministic Wallets]] +* [[bip-0044.mediawiki|BIP44 - Multi-Account Hierarchy for Deterministic Wallets]] diff --git a/bip-0081.mediawiki b/bip-0081.mediawiki new file mode 100644 index 0000000..5157c09 --- /dev/null +++ b/bip-0081.mediawiki @@ -0,0 +1,72 @@ +<pre> + BIP: 81 + Title: Hierarchy for Colored Voting Pool Deterministic Multisig Wallets + Authors: Justus Ranvier <justus@monetas.net> + Jimmy Song <jimmy@monetas.net> + Status: Draft + Type: Informational + Created: 2014-08-11 +</pre> + +==Abstract== + +This BIP defines a logical hierarchy for colored coin voting pool deterministic multisig wallets based on an algorithm described in BIP-0032 (BIP32 from now on) and purpose scheme described in BIP-0043 (BIP43 from now on). + +This BIP is a particular application of BIP43 and is based on BIP44. + +==Motivation== + +The hierarchy proposed in this paper allows the handling of multiple color definitions from a single seed. + +==Path levels== + +We define the following 8 levels in BIP32 path: + +<pre> +m / purpose' / series' / (5 color definition levels) / address_index +</pre> + +Apostrophe in the path indicates that BIP32 hardened derivation is used. + +Each level has a special meaning, described in the chapters below. + +===Purpose=== + +Purpose is a constant set following the BIP43 recommendation to: the ASCII value of "81" with the most signifigant bit set to indicate hardened derivation (0x80000051). It indicates that the subtree of this node is used according to this specification. + +Hardened derivation is used at this level. + +===Color Definition=== + +Index values which can be applied to a BIP32 node are limited to 4 bytes (32 bits). + +Since this is not sufficient to identify color definitions without a risk of collision, multiple levels are used. + +Color definitions are first shortened to 20 bytes using the Bitcoin hash160 function. + +The resulting 20 bytes are split into five groups in little endian format, and where each group is used as the seed for the five levels of color definition levels + +Public derivation is used at these levels, even when the index exceeds 2^31. + +===Index=== + +Public/private keypairs are numbered from index 0 in sequentially increasing manner. This number is used as child index in BIP32 derivation. + +Public keys obtained at this level of the heirarchy are used to construct multisig deposit scripts, using a schema that is shared between the members as an out-of-band contract. + +Public derivation is used at this level. + +==Compatible wallets== + +* [[https://github.com/btcsuite/btcwallet|btcwallet]] is the reference Bitcoin wallet for voting pools. + +==Copyright== + +This document is placed in the public domain. + +==Reference== + +* [[bip-0032.mediawiki|BIP32 - Hierarchical Deterministic Wallets]] +* [[bip-0043.mediawiki|BIP43 - Purpose Field for Deterministic Wallets]] +* [[bip-0044.mediawiki|BIP44 - Multi-Account Hierarchy for Deterministic Wallets]] +* [[bip-0080.mediawiki|BIP80 - Hierarchy for Non-Colored Voting Pool Deterministic Multisig Wallets]] diff --git a/bip-0122.mediawiki b/bip-0122.mediawiki index d59e353..17003aa 100644 --- a/bip-0122.mediawiki +++ b/bip-0122.mediawiki @@ -10,13 +10,13 @@ ==Abstract== -This BIP propose an URI scheme for looking up blocks, transactions, addresses on a Blockchain explorer, or in general to make proper Blockchain references +This BIP proposes a URI scheme for looking up blocks, transactions and addresses on a Blockchain explorer, or in general to make proper Blockchain references. ==Motivation== The purpose of this URI scheme is to enable users to handle all the requests for details about blocks, transactions, etc. with their preferred tool (being that a web service or a local application). -Currently a Bitcoin client usually points to an arbitrary blockchain explorer when the user looks for the details of a transaction, or let him choose from a limited list of possible alternatives. -Other times resorting to cut&paste is needed. +Currently a Bitcoin client usually points to an arbitrary blockchain explorer when the user looks for the details of a transaction or allows the user to choose from a set of alternatives. +Resorting to copy + paste into a browser is often required. The same happens with posts and messages that reference some particular txs or blocks, if they provide links at all. ==Specification== @@ -30,7 +30,7 @@ Where: {| class="wikitable" ! style="text-align: center;" | Element ! colspan="2" style="text-align: center;" | Description -! +! Required? |- | chain | colspan="2" | '''chain ID''' (see below) of the desired chain, leading 0s included. If omitted (which would be the usual case), Bitcoin main net is assumed. @@ -39,7 +39,7 @@ Where: | rowspan="3" | type | tx | for transactions. -| rowspan="3" | +| rowspan="3" | required |- | block | for blocks (supports both hash or height). @@ -49,7 +49,7 @@ Where: |- | hash | colspan="2" | the relevant hash to refer to (leading zeros included), or block height. -| +| required |} ====ABNF grammar==== @@ -104,20 +104,20 @@ A transaction on Bitcoin test net: ==Rationale== -From the point of view of a wallet (or other Blockchain related tool) developer that need to show any kind of Blockchain references, using this scheme mean that he can simply make it a blockchain: link and be done with it, without having to worry about any specific Blockchain explorer or provide a means for the user to select one. +From the point of view of a wallet (or other Blockchain related tool) developers which need to reference Blockchain data, using this scheme mean that he can simply make it a `blockchain:` link without having to worry about any specific Blockchain explorer or provide a means for the user to select one. -Blockchain explorers in turn will simply offer to handle the blockchain: URI, the first time the user visit their website, or launch/install the application, or even set themselves if there isn't already one. +Blockchain explorers in turn will simply offer to handle the `blockchain:` URI schema, the first time the user visit their website, or launch/install the application, or even set themselves if there isn't already one. -Users get the convenience of using always their preferred explorer, which can be especially handy on mobile devices, where juggling with cut&paste is far from ideal. +Users can link directly to their preferred block explorer (avoiding copy + paste which can be awkward on mobile devices). == Sample implementation == [https://github.com/MarcoPon/blockchain-exploration Demo Blockchain: URI handler on GitHub] ==Acknowledgements== -Thanks to Btc Drak for suggesting to provide support for different networks. -Thanks to Jorge Timon for the idea of using genesis blocks hashes to identify them. -Thanks to Richard Moore, Matt Whitlock, Andreas Schildbach for suggestions about the structure and hierarchy of the URI scheme. + +Thanks to Btc Drak for suggesting support for different networks and Jorge Timon for the suggestion that we could identify each network by its genesis block hash. +Thanks to Richard Moore, Matt Whitlock, Andreas Schildbach for help with the structure and hierarchy of the URI scheme. ==Copyright== diff --git a/bip-0141.mediawiki b/bip-0141.mediawiki index 1c8abc9..1d06494 100644 --- a/bip-0141.mediawiki +++ b/bip-0141.mediawiki @@ -21,7 +21,7 @@ The entirety of the transaction's effects are determined by output consumption ( By removing this data from the transaction structure committed to the transaction merkle tree, several problems are fixed: -# '''Nonintentional malleability becomes impossible'''. Since signature data is no longer part of the transaction hash, changes to how the transaction was signed are no longer relevant to transaction identification. As a solution of transaction malleability, this is superior to the canonical signature approach ([https://github.com/bitcoin/bips/edit/master/bip-0062.mediawiki BIP62]): +# '''Nonintentional malleability becomes impossible'''. Since signature data is no longer part of the transaction hash, changes to how the transaction was signed are no longer relevant to transaction identification. As a solution of transaction malleability, this is superior to the canonical signature approach ([https://github.com/bitcoin/bips/blob/master/bip-0062.mediawiki BIP62]): #* It prevents involuntary transaction malleability for any type of scripts, as long as all inputs are signed (with at least one CHECKSIG or CHECKMULTISIG operation) #* In the case of an m-of-n CHECKMULTISIG script, a transaction is malleable only with agreement of m private key holders (as opposed to only 1 private key holder with BIP62) #* It prevents involuntary transaction malleability due to unknown ECDSA signature malleability @@ -34,13 +34,35 @@ By removing this data from the transaction structure committed to the transactio ==Specification== +=== Transaction ID === + +A new data structure, <code>witness</code>, is defined. Each transaction will have 2 IDs. + +Definition of <code>txid</code> remains unchanged: the double SHA256 of the traditional serialization format: + + [nVersion][txins][txouts][nLockTime] + +A new <code>wtxid</code> is defined: the double SHA256 of the new serialization with witness data: + + [nVersion][marker][flag][txins][txouts][witness][nLockTime] + +Format of <code>nVersion</code>, <code>txins</code>, <code>txouts</code>, and <code>nLockTime</code> are same as traditional serialization. + +The <code>marker</code> MUST be <code>0x00</code>. + +The <code>flag</code> MUST be a 1-byte non-zero value. Currently, <code>0x01</code> MUST be used. + +The <code>witness</code> is a serialization of all witness data of the transaction. Each txin is associated with a witness field. A witness field starts with a <code>var_int</code> to indicate the number of stack items for the txin. It is followed by stack items, with each item starts with a <code>var_int</code> to indicate the length. Witness data is NOT script and is not restricted by the 520-byte push limit. + +A non-witness program (defined hereinafter) txin MUST be associated with an empty witness field, represented by a <code>0x00</code>. If all txins are not witness program, a transaction's <code>wtxid</code> is equal to its <code>txid</code>. + === Commitment structure === -A new block rule is added which requires a commitment to the witness hashes, the double SHA256 of a transaction including witnesses. The witness hash of coinbase transaction is assumed to be 0x0000....0000. +A new block rule is added which requires a commitment to the <code>wtxid</code>. The <code>wtxid</code> of coinbase transaction is assumed to be <code>0x0000....0000</code>. -A witness root hash is calculated with all those witness hashes as leaves, in a way similar to the hashMerkleRoot in the block header. +A witness root hash is calculated with all those <code>wtxid</code> as leaves, in a way similar to the hashMerkleRoot in the block header. -The commitment is recorded in a scriptPubKey of the coinbase transaction. It must be at least 38 bytes, with the first 6-byte of 0x6a24aa21a9ed, that is: +The commitment is recorded in a scriptPubKey of the coinbase transaction. It must be at least 38 bytes, with the first 6-byte of <code>0x6a24aa21a9ed</code>, that is: 1-byte - OP_RETURN (0x6a) 1-byte - Push the following 36 bytes (0x24) @@ -206,9 +228,9 @@ The 32-byte limitation for witness program could be easily extended through a so === Per-input lock-time and relative-lock-time === -Currently there is only one nLockTime field in a transaction and all inputs must share the same value. [https://github.com/bitcoin/bips/edit/master/bip-0068.mediawiki BIP68] enables per-input relative-lock-time using the nSequence field, however, with a limited lock-time period and resolution. +Currently there is only one nLockTime field in a transaction and all inputs must share the same value. [https://github.com/bitcoin/bips/blob/master/bip-0068.mediawiki BIP68] enables per-input relative-lock-time using the nSequence field, however, with a limited lock-time period and resolution. -With a soft fork, it is possible to introduce a separate witness structure to allow per-input lock-time and relative-lock-time, and a new script system that could sign and manipulate the new data (like [https://github.com/bitcoin/bips/edit/master/bip-0065.mediawiki BIP65] and [https://github.com/bitcoin/bips/edit/master/bip-0112.mediawiki BIP112]). +With a soft fork, it is possible to introduce a separate witness structure to allow per-input lock-time and relative-lock-time, and a new script system that could sign and manipulate the new data (like [https://github.com/bitcoin/bips/blob/master/bip-0065.mediawiki BIP65] and [https://github.com/bitcoin/bips/blob/master/bip-0112.mediawiki BIP112]). == Backward compatibility == @@ -217,14 +239,13 @@ As a soft fork, older software will continue to operate without modification. N '''What a non-upgraded wallet can do''' * Receiving bitcoin from non-upgraded and upgraded wallets -* Sending bitcoin to non-upgraded wallets -* Sending bitcoin to upgraded wallets using a P2SH address (less efficient) -* Sending bitcoin to upgraded wallets using a native witness program (more efficient) through [https://github.com/bitcoin/bips/blob/master/bip-0070.mediawiki BIP70] payment protocol +* Sending bitcoin to non-upgraded and upgraded wallets with traditional P2PKH address (without any benefit of segregated witness) +* Sending bitcoin to upgraded wallets using a P2SH address +* Sending bitcoin to upgraded wallets using a native witness program through [https://github.com/bitcoin/bips/blob/master/bip-0070.mediawiki BIP70] payment protocol '''What a non-upgraded wallet cannot do''' * Validating segregated witness transaction. It assumes such a transaction is always valid -* Sending bitcoin to upgraded wallets using a native witness program if BIP70 is not supported == Deployment == @@ -259,7 +280,6 @@ https://github.com/sipa/bitcoin/commits/segwit == References == *[[bip-0016.mediawiki|BIP16 Pay to Script Hash]] -*[[bip-0142.mediawiki|BIP142 Address Formats for Segregated Witness]] *[[bip-0143.mediawiki|BIP143 Transaction Signature Verification for Version 0 Witness Program]] *[[bip-0144.mediawiki|BIP144 Segregated Witness (Peer Services)]] diff --git a/bip-0142.mediawiki b/bip-0142.mediawiki index 112a472..ff831cb 100644 --- a/bip-0142.mediawiki +++ b/bip-0142.mediawiki @@ -146,7 +146,7 @@ https://github.com/theuni/bitcoin/commit/ede1b57058ac8efdefe61f67395affb48f2c0d8 * [[bip-0013.mediawiki|BIP 13: Address Format for pay-to-script-hash]] * [[bip-0016.mediawiki|BIP 16: Pay to Script Hash]] -* [[bip-0070.mediawiki|BIP 70: Payment Protocal]] +* [[bip-0070.mediawiki|BIP 70: Payment Protocol]] * [[bip-0141.mediawiki|BIP 141: Segregated Witness]] == Copyright == diff --git a/bip-0144.mediawiki b/bip-0144.mediawiki index 233fbc3..9b2422b 100644 --- a/bip-0144.mediawiki +++ b/bip-0144.mediawiki @@ -63,8 +63,8 @@ The serialization has the following structure: | A list of one or more transaction outputs |- | 1+ -| witness -| witness +| script_witnesses +| script_witnesses[] | The witness structure as a serialized byte array |- | 4 @@ -77,7 +77,7 @@ Parsers supporting this BIP will be able to distinguish between the old serializ If the witness is empty, the old serialization format should be used. -Witness objects can be extended to contain other kinds of witness data not yet specified. This BIP is agnostic to the witness data structure, defined in [https://github.com/bitcoin/bips/blob/master/bip-0141.mediawiki BIP141] (Consensus segwit BIP), and treats it as an arbitrary byte array. +Currently, the only witness objects type supported are script witnesses which consist of a stack of byte arrays. It is encoded as a var_int item count followed by each item encoded as a var_int length followed by a string of bytes. Each txin has its own script witness. The number of script witnesses is not explicitly encoded as it is implied by txin_count. Empty script witnesses are encoded as a zero byte. The order of the script witnesses follows the same order as the associated txins. * '''Rationale for not having an independent message type with its own serialization''': this would require separate "tx" and "block" messages, and all RPC calls operating on raw transactions would need to be duplicated, or need inefficinent or nondeterministic guesswork to know which type is to be used. |