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-0141.mediawiki | 42 | ||||
| -rw-r--r-- | bip-0142.mediawiki | 2 | ||||
| -rw-r--r-- | bip-0144.mediawiki | 6 |
6 files changed, 194 insertions, 15 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-0141.mediawiki b/bip-0141.mediawiki index 7266e9d..b62d54d 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. |