From 9b9a8c4b71317afb946ef5198836df31914ed6f9 Mon Sep 17 00:00:00 2001 From: Eric Lombrozo Date: Thu, 24 Dec 2015 14:23:27 -0500 Subject: [PATCH 01/11] Segregated Witness Peer Services BIP --- bip-codeshark-segwit-peer-services.mediawiki | 340 +++++++++++++++++++ 1 file changed, 340 insertions(+) create mode 100644 bip-codeshark-segwit-peer-services.mediawiki diff --git a/bip-codeshark-segwit-peer-services.mediawiki b/bip-codeshark-segwit-peer-services.mediawiki new file mode 100644 index 00000000..6f33378c --- /dev/null +++ b/bip-codeshark-segwit-peer-services.mediawiki @@ -0,0 +1,340 @@ +
+  BIP: x
+  Title: Segregated Witness (Peer Services)
+  Authors: Eric Lombrozo , Pieter Wuille 
+  Status: Draft
+  Type: Standards Track
+  Created: 2015-12
+
+ +==Abstract== + +This BIP defines new messages and serialization formats for propagation of transactions and blocks committing to segregated witness structures. + +==Motivation== + +==Specification== + +A new message type called "witnesstx" is added to the peer-to-peer protocol. (http://blockhawk.net/diagrams/witnesstx.png) + +The message has the following structure: + +{| class="wikitable" style="width: auto; text-align: center; font-size: smaller; table-layout: fixed;" +!Field Size +!Name +!Type +!Description +|- +| 4 +| version +| int32_t +| Transaction data format version +|- +| 1 +| marker +| char +| Must be zero +|- +| 1 +| flag +| char +| Must be nonzero +|- +| 1+ +| txin_count +| var_int +| Number of transaction inputs +|- +| 41+ +| txins +| txin[] +| A list of one or more transaction inputs +|- +| 1+ +| txout_count +| var_int +| Number of transaction outputs +|- +| 9+ +| txouts +| txouts[] +| A list of one or more transaction outputs +|- +| +| txin_witness +| txin_witness +| Transaction input witness +|- +| 4 +| lock_time +| uint32_t +| The block number or timestamp until which the transaction is locked +|} + +* CTransaction gets, in addition to vin and vout, a vwit, which +contains a CTxInWitness object for each input. A CTxInWitness contains a CScriptWitness object +and can potentially be extended to contain other kinds of witness data. +A CScriptWitness is a vector of byte vectors (nominally: the input stack to the program, no longer +encoded as a CScript, but just the resulting stack directly). +* A new serialization for CTransaction is defined: http://blockhawk.net/diagrams/witnesstx.png +(int32 nVersion, +0x00 marker, 0x01 flag, vector, vector, +vector, int32 nLockTime) instead of (int32 nVersion, +vector, vector, int32 nLockTime). This will never parse +as a valid transaction (even if parsing succeeds, it means it's +interpreted as a transaction with no inputs and 1 output). If all +witnesses are empty, the old serialization format is used. +- Rationale for not having an independent CWitnessTransaction 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. +- Rationale for not using just a single 0x00 byte as marker: that +would lead to empty transactions (no inputs, no outputs, which are +used in some tests) to be interpreted as new serialized data. +- Rationale for the 0x01 flag byte in between: this will allow us to +easily add more extra non-committed data to transactions (like txouts +being spent, ...). It can be interpreted as a bitvector. + +* A new message 'havewitness' is sent after receiving 'verack' to +indicate that a node can provide witness if requested (similar to +'sendheaders') + +* New inv types MSG_WITNESS_TX and MSG_WITNESS_BLOCK are added, only +for use in getdata. Inv itself still use just MSG_TX and MSG_BLOCK, +similar to MSG_FILTERED_BLOCK. +- Rationale for not advertizing witnessness in invs: we don't always +use invs anymore (with 'sendheaders' BIP 130), plus it's not useful: +implicitly, every transaction and block have a witness, old ones just +have empty ones. + +* Transactions' GetHash is always computed on the old non-witness +serialization. A new CTransaction::GetWitnessHash is added which is +computed from the witness-serialization (this means that transactions +with an empty witness have witness hash equal to normal hash). + + +=== Commitment structure === + +!!!DRAFT ONLY!!! + +A new block rule is added which requires a commitment to the witness hashes in the coinbase (or an OP_RETURN output of a specific transaction, or somewhere else) + +(Hardfork after x year to move the commitment to block header?) + +Witness hash is the double SHA256 of a transaction including witnesses: http://blockhawk.net/diagrams/witnesstx.png. For the coinbase transaction, its witness hash is assumed to be 0x0000....0000. + +A witness root hash is calculated with all those witness hashes as leaves, in a way similar to the hashMerkleRoot in the block header. + +No witness data is allowed in blocks that don't commit to witness data, as this would otherwise leave room from spam. + +==== Proposal 1: balance tree (the current implementation) ==== +The commitment is a push of exactly 41 bytes: +*The first 4 bytes are commitment header: 0xaa21a9ed +*The next 4 bytes describe a nonce +*The next 1 byte is the "levels bytes", describes the number of levels in a Merkle tree (0 to 32) +*The next 32 bytes is a commitment root hash (not the witness root hash) + +Locator of the witness root hash is defined as: + +
SHA256('WitnessV1\x00\x00\x00\x00\x00\x00\x00' || nonce)
+ +The first levels bits of locator, interpreted in little endian, are assumed to be the position in the leaves of the Merkle tree where the witness root hash goes. + +The coinbase's input's witness must consist of a single byte array of 32 * levels bytes, and are assumed to be the Merkle path to connect the witness root hash to the commitment root hash. + +====Proposal 2: imbalance tree==== +The commitment is a push of exactly 40 bytes: +*The first 4 bytes are commitment header: 0xaa21a9ed +*The next 4 bytes describe a nonce +*The next 32 bytes is a commitment root hash (not the witness root hash) + +Locator of the witness root hash is defined as: + +
SHA256('WitnessV1\x00\x00\x00\x00\x00\x00\x00' || nonce)
+ +The first levels bits of locator, interpreted in little endian, are assumed to be the position in the leaves of the Merkle tree where the witness root hash goes. + +The coinbase's input's witness must consist of a single byte array, which the size must be a multiple of 32 bytes but not bigger than 32*32 bytes. These are assumed to be the Merkle path to connect the witness root hash to the commitment root hash. Depth of the commitment is determined by the length of the path. If the depth of the tree is 0, the path should be represented by 0x00, and the witness root hash will be same as the commitment root hash. + +=== Block size limit === +Blocks are currently limited to 1 MB total size. We change this restriction as follows: + +We define a base block size sb consisting of the existing header and transactions, a witness size sw consisting of only the size of the witness data, and a virtual block size sv = sb + sw/4. + +The new rule is sv <= 1 MB. + +=== Witness program === + +* A scriptPubKey (or redeemScript as defined in BIP16/P2SH) that consists of a single push of 2 to 41 bytes gets a new special meaning. The byte vector pushed by it is called the "witness program". +** In case the scriptPubKey pushes a witness program directly, the scriptSig must be exactly empty. +** In case the redeemScript pushes a witness program, the scriptSig must be exactly the single push of the redeemScript. + +* The first byte of a witness program is the "version byte", an unsigned integer. +** If the version byte is 0, the rest of the witness program is the actual script. +*** The script is executed after normal script evaluation but with data from the witness rather than the scriptSig. +*** The program must not fail, and result in exactly a single TRUE on the stack. +** If the version byte is 1, the rest of the witness program must be 32 bytes, as a SHA256 hash of the actual script. +*** The witness must consist of an input stack to feed to the program, followed by the serialized program. +*** The serialized program is popped off the initial witness stack. Hash of the serialized program must match the hash pushed in the witness program. +*** The serialized program is deserialized, and executed after normal script evaluation with the remaining witness stack. +*** The script must not fail, and result in exactly a single TRUE on the stack. +** If the witness version byte is 2 or above, no further interpretation of the witness program or witness happens. + +=== Other consensus critical constraints === + +== Block size analysis == +WORK IN PROGRESS + +Definitions: +
+ Core block size (CBS): The block size as seen by a non-upgrading full node
+ Witness size (WS): The total size of witness data in a block
+ Total block size (TBS): CBS + WS
+ Witness discount (WD): A discount factor for witness data in VBS calculation (1 = no discount)
+ Virtual block size (VBS): CBS + (WS * WD)
+ Witness adoption (WA): Proportion (in size) of new format transactions among all transactions
+ Prunable ratio (PR): Proportion of signature data size in a transaction
+
+ +With some transformation it could be shown that: +
+ TBS = CBS / (1 - WA * PR)
+     = VBS / (1 - WA * PR * (1 - WD))
+
+ +In order to keep the proposal as a soft fork, the CBS must not have a upper limit higher than 1MB. + +The PR heavily depends on the transaction script type and input-output ratio. For example, the PR of 1-in 2-out P2PKH and 1-in 1-out 2-of-2 multisig P2SH are about 47% and 72% respectively. According to the data presented by Pieter Wuille on 7 December 2015, the current average PR on the blockchain is about 60%. + + + +== Examples == + +=== Version 0 witness program === + +The following example is a version 0 witness program, equivalent to the existing Pay-to-Pubkey-Hash (P2PKH) output. + + witness: + scriptSig: (empty) + scriptPubKey: <0x0076A914{20-byte-hash-value}88AC> + +The version byte 0x00 is removed. The rest of the witness program is deserialized and becomes: + + DUP HASH160 <20byte-hash-value> EQUALVERIFY CHECKSIG + +The script is executed with the data from witness + + DUP HASH160 <20byte-hash-value> EQUALVERIFY CHECKSIG + +Comparing with a P2PKH output, the witness program equivalent occupies 2 more bytes in the scriptPubKey, while moving the signature and public key from scriptSig to witness. + +=== Version 1 witness program === + +The following example is an 1-of-2 multi-signature version 1 witness program. + + witness: 0 <0x5121{33-byte-pubkey1}21{33-byte-pubkey2}52AE> + scriptSig: (empty) + scriptPubKey: <0x01{32-byte-hash-value}> + +The last item in the witness is popped off, hashed with SHA256, compared against the 32-byte-hash-value in scriptPubKey, and deserialized: + + 1 <33-byte-pubkey1> <33-byte-pubkey2> 2 CHECKMULTISIG + +The script is executed with the remaining data from witness: + + 0 1 <33-byte-pubkey1> <33-byte-pubkey2> 2 CHECKMULTISIG + +Since the actual program is larger than 40 bytes, it cannot be accommodated in a version 0 witness program. A version 1 witness program allows arbitrarily large script as the 520-byte push limit is bypassed. + +The scriptPubKey occupies 34 bytes, as opposed to 23 bytes of P2SH. The increased size improves security against possible collision attacks, as 2^80 work is not infeasible anymore (By the end of 2015, 2^84 hashes have been calculated in Bitcoin mining since the creation of Bitcoin). The spending script is same as the one for an equivalent P2SH output but is moved to witness. + +=== Witness program nested in Pay-to-Script-Hash === + +The following example is the same 1-of-2 multi-signature version 1 witness program, but nested in a P2SH output. + + witness: 0 <0x5121{33-byte-pubkey1}21{33-byte-pubkey2}52AE> + scriptSig: <0x2101{32-byte-hash-value}> + scriptPubKey: HASH160 <20-byte-hash-value> EQUAL + +The only item in scriptSig is hashed with HASH160, compared against the 20-byte-hash-value in scriptPubKey, and interpreted as a single push of: + + <0x01{32-byte-hash-value}> + +The version 1 witness program is then executed as described in the last example + +Comparing with the last example, the scriptPubKey is 11 bytes smaller (with reduced security) while witness is the same. However, it also requires 35 bytes in scriptSig, which is not prunable in transmission. Although a nested witness program is less efficient in many ways, its payment address is fully transparent and backward compatible for all Bitcoin reference client since version 0.6.0. + +=== Trust-free unconfirmed transaction dependency chain === +Segregated witness fixes the problem of transaction malleability fundamentally, which enables the building of unconfirmed transaction dependency chains in a trust-free manner. + +Two parties, Alice and Bob, may agree to send certain amount of Bitcoin to a 2-of-2 multisig output (the "funding transaction"). Without signing the funding transaction, they may create another transaction, time-locked in the future, spending the 2-of-2 multisig output to third account(s) (the "spending transaction"). Alice and Bob will sign the spending transaction and exchange the signatures. After examining the signatures, they will sign and commit the funding transaction to the blockchain. Without further action, the spending transaction will be confirmed after the lock-time and release the funding according to the original contract. It also retains the flexibility of revoking the original contract before the lock-time, by another spending transaction with shorter lock-time, but only with mutual-agreement of both parties. + +Such setups is not possible with BIP62 as the malleability fix, since the spending transaction could not be created without both parties first signing the funding transaction. If Alice reveals the funding transaction signature before Bob does, Bob is able to lock up the funding indefinitely without ever signing the spending transaction. + +Unconfirmed transaction dependency chain is a fundamental building block of more sophisticated payment networks, such as duplex micropayment channel and the Lightning Network, which have the potential to greatly improve the scalability and efficiency of the Bitcoin system. + +== Future extensions == +=== Compact fraud proof for SPV nodes === +Bitcoin right now only has two real security models. A user either runs a full-node which validates every block with all rules in the system, or a SPV (Simple Payment Verification) client which only validates the headers as a proof of publication of some transactions. The Bitcoin whitepaper suggested that SPV nodes may accept alerts from full nodes when they detect an invalid block, prompting the SPV node to download the questioned blocks and transactions for validation. This approach, however, could become a DoS attack vector as there is virtually no cost to generate a false alarm. An alarm must come with a compact, yet deterministic fraud proof. + +In the current Bitcoin protocol, it is possible to generate compact fraud proof for almost all rules except a few: + +# It is not possible to proof a miner has introduced too many Bitcoins in the coinbase transaction outputs without showing the whole block itself and all input transactions. +# It is not possible to prove the violation of any block specific constraints, such as size and sigop limits, without showing the whole block (and all input transactions in the case of sigop limit) +# It is not possible to prove the spending of a non-existing input without showing all transaction IDs in the blockchain way back to the genesis block. + +It is possible to proof the first 2 types of fraud if a block is committed to a Merkle-sum-tree of the fee, size, and sigop count of each transaction. It is also possible to proof the last type of fraud if a block is committed to a Merkle tree with the originating block height and transaction index of all inputs. These commitments could be included in the extensible witness commitment through a soft fork and will be transparent to nodes that do not understand such new rules. + +=== New script system === +Since all witness programs begin with a version byte, and programs with unknown versions are always considered as anyone-can-spend script, it is possible to introduce any new script system with a soft fork. The witness as a structure is not restricted by any existing script semantics and constraints, the 520-byte push limit in particular, and therefore allows arbitrarily large scripts and signatures. + +Examples of new script system include Schnorr signatures which reduce the size of multisig transactions dramatically, Lamport signature which is quantum computing resistance, and Merklized abstract syntax trees which allow very compact witness for conditional scripts with extreme complexity. + +The 41-byte limitation for witness programme could be easily extended through a soft fork in case a stronger hash function is needed in the future. The version byte is also expandable by introducing a secondary version byte for some specific primary version values. + +=== 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. 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 BIP65 and BIP112). + +== Backward compatibility == +As a soft fork, older software will continue to operate without modification. Non-upgraded nodes, however, will not see nor validate the witness data and will consider all witness programs as anyone-can-spend scripts (except a few edge cases in version 0 witness programs which are provably unspendable with original script semantics). Wallets should always be wary of anyone-can-spend scripts and treat them with suspicion. Non-upgraded nodes are strongly encouraged to upgrade in order to take advantage of the new features. + +=== Version 0 witness programs === +Witness programs are hashed to 256 bit "redeemscripts" which are then hashed to 160 bit P2SH. This format is fully compatible with currently existing wallets that support P2SH. Upgraded wallets will be able to send and receive to and from older wallets without any problems. + +=== Version 1 witness programs === +Witness programs are hashed to a 256 bit output. This format will not be compatible with older wallets but will require less block space and will have better security due to increased collision resistance. + +== Deployment == + +We reuse the double-threshold IsSuperMajority() switchover mechanism used in +BIP65 with the same thresholds, but for nVersion = 5. The new rules are +in effect for every block (at height H) with nVersion = 5 and at least +750 out of 1000 blocks preceding it (with heights H-1000..H-1) also +have nVersion >= 5. Furthermore, when 950 out of the 1000 blocks +preceding a block do have nVersion >= 5, nVersion < 5 blocks become +invalid, and all further blocks enforce the new rules. + +(It should be noted that BIP9 involves permanently setting a high-order bit to +1 which results in nVersion >= all prior IsSuperMajority() soft-forks and thus +no bits in nVersion are permanently lost.) + + +=== SPV Clients === + +While SPV clients are unable to fully validate blocks, +they are able to validate block headers and, thus, can check block version and proof-of-work. +SPV clients should reject nVersion < 5 blocks if 950 out of 1000 preceding blocks have +nVersion >= 5 to prevent false confirmations from the remaining 5% of +non-upgraded miners when the 95% threshold has been reached. + +== Credits == +Special thanks to Gregory Maxwell for originating many of the ideas in this BIP and Luke-Jr for figuring out how to deploy this as a soft fork. + +== Reference Implementation == +https://github.com/sipa/bitcoin/commits/segwit + +== Copyright == +This document is placed in the public domain. From 0112d56051d3406ba035a75a5033fe5de52a6c86 Mon Sep 17 00:00:00 2001 From: Eric Lombrozo Date: Thu, 24 Dec 2015 17:23:02 -0500 Subject: [PATCH 02/11] Embedded diagram --- bip-codeshark-segwit-peer-services.mediawiki | 25 +++++++++--------- .../witnesstx.png | Bin 0 -> 18923 bytes 2 files changed, 13 insertions(+), 12 deletions(-) create mode 100644 bip-codeshark-segwit-peer-services/witnesstx.png diff --git a/bip-codeshark-segwit-peer-services.mediawiki b/bip-codeshark-segwit-peer-services.mediawiki index 6f33378c..c81e1dbb 100644 --- a/bip-codeshark-segwit-peer-services.mediawiki +++ b/bip-codeshark-segwit-peer-services.mediawiki @@ -15,9 +15,9 @@ This BIP defines new messages and serialization formats for propagation of trans ==Specification== -A new message type called "witnesstx" is added to the peer-to-peer protocol. (http://blockhawk.net/diagrams/witnesstx.png) +A new serialization format for tx messages is added to the peer-to-peer protocol. -The message has the following structure: +The serialization has the following structure: {| class="wikitable" style="width: auto; text-align: center; font-size: smaller; table-layout: fixed;" !Field Size @@ -71,16 +71,17 @@ The message has the following structure: | The block number or timestamp until which the transaction is locked |} -* CTransaction gets, in addition to vin and vout, a vwit, which -contains a CTxInWitness object for each input. A CTxInWitness contains a CScriptWitness object -and can potentially be extended to contain other kinds of witness data. -A CScriptWitness is a vector of byte vectors (nominally: the input stack to the program, no longer -encoded as a CScript, but just the resulting stack directly). -* A new serialization for CTransaction is defined: http://blockhawk.net/diagrams/witnesstx.png -(int32 nVersion, -0x00 marker, 0x01 flag, vector, vector, -vector, int32 nLockTime) instead of (int32 nVersion, -vector, vector, int32 nLockTime). This will never parse + + +Parsers supporting this BIP will be able to distinguish between the old serialization format (without the witnesses) and this one. The marker byte is set to zero so that this structure will never parse as a valid transaction in a parser that does not support this BIP. If parsing were to succeeded, such a transaction would contain no inputs and a single output. + +If all witnesses are empty, the old serialization format should be used. + +Witness objects can potentially be extended to contain other kinds of witness data. + +A script witness is a vector of byte vectors (nominally: the input stack to the program, no longer +encoded as a scriptSig, but just the resulting stack directly). + as a valid transaction (even if parsing succeeds, it means it's interpreted as a transaction with no inputs and 1 output). If all witnesses are empty, the old serialization format is used. diff --git a/bip-codeshark-segwit-peer-services/witnesstx.png b/bip-codeshark-segwit-peer-services/witnesstx.png new file mode 100644 index 0000000000000000000000000000000000000000..5fd8afcb01ce0cf08b7de1003c8be0539f226ba6 GIT binary patch literal 18923 zcmeHv2~^T)+c(uXPRry>n^`F{m8rQfWo53kn|o?$xK@hhxRCpTKuyzPSyV2hrc|bm zxu9SYE>P2AipnIpAR^_O0umyqAn^U6nR#ZObKdWLzwbNmIqx~&aE_%NxX zegCdM8OPimzh1Us83+XW+Ue*aFA!+49QfJt)tA6Kh5UCbfPWUndpRBeRd;Th0Dk!* ze81a%5U3WreBrbf@cYtpM`7_G(5eLW&!WLFa0&?Ibl&OE{^Kb@0uHLi432`NDQl0O zNzd?{*%183bNk@^`$sZ2>YPwMI5G)x)^fIYTC;ZVq{Lt*cW~p^aXF8+TF?2cm;C&d z;n_9u#bwoyO`g`&QEHb+V>zE1p*mo6LmnKOJ34Np!>(#96+Eo z&Ma-v`2!}v!jBpMZLrUj31%8U`30Gi#1_1-XOm)yIOT zm0Jub73spdGHR^;c%OR_~^5=_{?9` zLLSnscqe_TpJtflTg%{v^NGcLrfnNFK@Se@DF|5u z=*hGdy~dlyY`%Wv_Ib(J`b%n!58)6!wUq&}t6{qWrwTwdF&g0q*3#S7THQX(9HlM= z@s6;{lCx10JKG#8ty+u$qm(5N-GKTI99nl{^CDiyj%8}|WLR)3LtvDlZN#$;16GSp zaWuj&ZO_e7&sa)Ftp@enAbJRm)Jeom&yzQSUtey-s8_M!@Z#Tss-DpeC*KCD+z6P(Q(8hdme&ma%SxJ6T>Ij8CBqFH(n&Y} zZV*8Dy2t-!x8`EL3(iw|y4m{3Y3nwJ=GBM=%_`O`{as0hbHaR>zSyRbD{Qnr)IoR1Q)BH)dN+Hl0z)g>*JGQNEtJNd!I(`{j(S8FU(ey{uVRVNA`8tzAGE`(O$E{T|Kv~FZrv$ytMWvjZmHS!2^E;MZ@{~>#rVKLxO(U`u z-RsxNPT#YRso%|B70w|)y40rp=5))_mvk}x=(JUpv! zJW}iuyKP+0UfMTVTosX=KE9axWh9o6yi zU}vR#<=JIFnyzN#Wmfs3E~6h1F{h9uI`_=Y#K*x`-p*yJ+>a#9ckuQ^QkR4<)0B53 z3R(~^b)O_3LxIf=7>=AHfn1RNt%~BxeAl=#K;YSlZMI0^3vcK z7aw0~!GT?~hFj+6<1bYNPVSNWcz4~j-@{3MzvR~#JBKk&za(t!Grifv7Z6-s9x<`R zXe<)Z($vdGSd?{M5Dc6dO#HF5yS36+{y|b#cvEmW6-?W)Tjd9N>L!Wm2-z0ImfAI* zN^CLCcKRc+Jm;fQcJra!5d>Cd){ruOA#9I#>b(awgt%t(24J5IO7d)$Qe zWY*?IB8hN2K#c~s;wx4J<~@RkuTOI3fxN%um$g}AT?HKn9MDPVGevLnl(HB5?Cr-2 z7jE6>BY;pGi;7=I?XP@j2dh4E>D)qQ4E63SBH*E&VA_*!F2mSA2&fZSy{eF?cv1`n z?qMsp!}&~b2c}YcBMvHTGHExr#IGGHheK)YOXG2h!{mu)eeTtavoKp^^Mw<~)IRz- z?%SN=^W43uMxC7=?OAPUYZl(lG_)g3ly2Dyb0FE>i}p+H%nN#bXNazR_i_*8q|^(J z37wI>mbN##Z(L_4FYZO9r;0N>-q>LoG@t7+-jPuSy;iwak&5$@`#@fNVJzQR?vmQz zY80PDZ5=DIix?ESB=5N!=BpgU5}X}LRG_Ju?5x5-@t%5ScIfbRn4rwv>2#mf24L(^J2t%)|+>h zQ*KV&yGF=T^uns5>?juZsMr=H5sw=9sx$U@*P4>nhr73*Dgf%>^ZOtU)1`08Y0l*jen+TGE0`WuPu5p9fF_o&_bg3dJdIXH|%k=hlzy=i8JsT$70+O%?sKKvi8$ zpIqqZDpaC>LyY&--Uq7H&T|({iw_rq{^GvZoV*))$C91{t{VFOvX|61WvNb$ z9gyMm4zX}KhgnyCuf{X(O`>si0r%W`>i2SF`gXJ+@!v{c&PU?0SAVaN6Z-JrhD@T) z@74JCDscPo|4)$NP{RsP_E8p4_sx!%(L@S==lnNB>-iHHCO;5#Y#o5ePWp=;Z0Z95 z5%9k@2LQ-~8#cj~fGUfCDs2oPM*!UcSdQMh8Gt4_ph|N%7(h*=RfCm_Kt3M8U;xkk zr{GXP#7tKxOOBpqYoiiP)&8{BBtZqrFUUT(m zYDS2|EGg)6PM>b>1HNwddTapfo7>85Hw6JE-`t*F)sj9H-n_!J7Gidg1u@=XKp}p& zS>d*cP4W6}^Qhs?`2j|np3j-!lb4CX$IjTr!S^4M73{5#FWGmf&1I9Af|u;9d`YcY z0jJ%6nKIJ$)72TP*r;*m3spo^!^Odn;flgClEt@ojHrYHG%xI z;Qu*0EPF6IDK0vxANOW;1#PZnK~Z7^c-qW;KBiuF-3UzF@f(9+K_A3-wTnl3eSO1) z!ac?M!dsJf#SR6{s#6+&eAIMLoX@SCeZfU{FiEp6)_?O(+DaIFQLvQK^Muq<0C?it z>z48z#~^c878I&!EP-$n_F-Q&@8)W?-+KjhdP=pk{^n%7Tkz#`n_+(ufTgG8@5H=` z&SS*D%AuLj~QEv`dZ>5}S$ zT*|O9`ddhqIJ z3y&wQu@PXB3FdfV?P#q0ac`jrIS;3Pz)rUCQx77kqS4Ww!#z7R5hnCoHxiQOD}FN~HNtW%te^b?2MurI9KTYvNIlHqH2wq>CpaCtTBFc9poH)Jc`E>E~$ z*|Hp3f6$eZ9e&2>O-HYthkVI?-0g|%s>7IS*N{tqGAFE_KB z_i3_3T6XD6kAUmYpsBK4#an9Pdyxl0`RSKk(KFwliVvD_)1(2|@Gh-|PnOkf?$|R_ zm=Y|$JegQE9|vAHW-c$@OXBuwG8-)tcE7-N-6xURV8%8ZKjtuShIY6bYTI|xu`+8S zinVe*Pc)Liy&&kQ7T*gbT?f)p<`ZN2FdW%G^LF{*;D`LenkSZSoy`2fe8`t+amT{= zKiqDYxgiJnD{1eO7zOH-c*~*0WZcod+NNwbDxs8mqAwgkoy;&dT+ruDNOX^{ckmz5 zx%UK2Lw%P8UYxBsy;YqZWr6g?oX|!h6l0Xnj~$MH_MW9s#yKz+x1oyUv4<=lYWiKL z-Ny2~{q&}q#MjzUXQ&ew?Kku-Sz;OKsQ>jDv~}XPqV zFRMG=A|Kwx5-*P5`xwRS!Srim-x8C%b~hdc9Q&g$3yi#A6#Q;XS)NDWgP&riV-vGc zEWxhPbkdt~=O!ZbuBHqT$L85q$FCqZAqxzfEJg*yYCb(w6C~Uxm5D6O8Ocw~Bh67f z*4&%S@qsELbazN$Y^!=RigFZE_pTLfxfcqXFFqj!vbe4!i!68`3&(Ktb(b(OX5IXxw*{Fm{sh~#X6o|YYxHO+%Y>kY#(TUdg~T-!a-EVc0saustg z_s(wy9|d9;JqWY?k)NV{$CMXh8&=pZcISxJai;_tywSyoLi?iA$!Oa)<*8L_^l%iq z(*{YqT^`OVSjFwEyJG-exj7YJ>e z_=s&8qncX{enY(}__x`WE#=`passVZHb9Okr>c5X0Sex?*uV-l1~bSF@AY4a)|f(Q zLspDhcNYdz(h?rV4l^3TqMCBD5G_%8aumVP9lcF4!GW}TN^kmY_1;|cks{`YS}JU@ zY;TTeO#C=_;jKvwBHng(!_B`{q)?QYy4(TAnfp1U0u`=;OFGK%4N2s9o*D19#zz}F zJFL>18-|~jy)#-TAS^Ms##MVSck3iD^sn701tFl+(J6_Tz%j z8~+E;Bn~=h$txHRsAvQ|?Q_g=j&3iRczGt92_uJd#-$?yxVmz#oPvCGF8f=>{Rh$g zgW3OeNJ;RL9zF!TLX(M^C2h(HL^>wvlKPE9q4W0^9@8Q|pN$rQ&P)D_l)^9WZAzs= zUa{Qb>HP*ik^UI3oGI%#4g#GrfG&K{skjcIKAn2!8<=>)GBFi6Xpx&n&AU%u(f6^R zr7)^|*MLBGxjDW;F#Xh#+ug+ml3ykjLJa2fSSzaNMtAd6B4P69)$YH}Nja5opvrfB$J6TPI&#KRM^hjl*%qECDS0k}Q$?~$EKv^CmJ7ohh~2?cMMe#=^9^1bGqOdlyY-hXH$0Q&@nYQl{RT-~y9imQOYo z<|yJB_T-@FGv!|ZDloczgPUQ}*(na&Rd6I6u6lUgqCcRuAf};Qvy*o^$I4bJDrmBb z?qsUCFziPw8&f%cVZ_LauEbGiN;I2Cw;sReo&50%;Dm)rA;k$0(;rEwnnH5rJ*Kj$ zWLl$ImTUYhCmDf$+aYQJ2Xj(}Z*-J9N;WF3Oh2 zcwIqvR|K6&=k_KqL>69sgN>WG^sC4acq9*sGoRTG77;^DB2*f+p^Qny`}|OK)}|5DA5pg38;I!Gi8MvRVb_KgN;m`wlUxs8ct|O;EzDJnRFXO$ z`_4JcQar}Fs{yN&r11Q?ehL{umBuMlN3oT6V|OZxrj+q`Yu)E>aOZAJMtC6euU_5s zbJM~ogg}*4A$AKp{eigyyB!^-Z%?uq=p<<^aOKiyE$s`baI~NFObkaa3bK}`L>Q?LpAF`Wo^%z{(e@7Yqx*o4u81LTEvdNn}8%dK!O7uzxcB)fd zJmB_IGOLqQ02BKDJ@Uiy;FFja2W=WvPY9^0JiimTfH)_~d2PG<7ILcf*Y~5^9QHk^ zZkleJ{9Y&ZXrfBarKPdigFYTEDs#EGXtqgqa35e+!IRz|<|5-PqRz2j5EwbT8@%uw z{4V^Hhr|5HWT&mLlB!Y&5$FzfWU#znMsxwS0U348c2uyK7c|?@&@y$`ihU zCpbd%Yz1vna1bmzW@!W}0m$2B(!p6OxnZ_h7^t7rce;CbZ-966xV^BPj*;Oz%TVS< zpwVOMVV5B3r^UEfX5NA>ZSIwX3l`sP;kT*Yef2C2;8vH_14%>1PVssUmGemz#aM?1 zr5p&>ckPSzwPvHv|HJ_Tue-<|Ir$T2D8tAHm=DFH(PZ6(m@&}(P{0x&f@U7-c56X9 zKa~ZfO_X#rgR)&&+QtKb2RFi|w;*SyqNlVzk8}XMHp)ac!A`AioN5>g0y&ogE1ufO zoqL^2#LRuT;%hZ;8&-Q}7a!XR2j4$e-UpSv#SWUu zjqvGliQ*0`t3Ut3he~U)95XpEK@4Ry_m2rI*2;&mP&A2OrV8No_#^(*$BP9W&Gz0y zSI&>)gB8;_TGSt!YQiSdva=5m27T8c?zAmHE;0tn$FZjg>r@f~MgdUU&wc=IJ}&{P zUUpG0SU~0m6($d+CccI8YhFAyt$zBDqJ6##V7r%`Yc<3HW0ySQFIjP(sPltso5M2@ z@Wu=E8~Ymhm@!LyMCsyVHgNDM&_lke2chtJk}Mnq@=6IH|I6>%l;1jT@(hgc*bNj5 zXW*`N#WOju|C7HR)HwnC{Rm5Y{dqcs)|B?~AlT1dDZ&z@LN3=;>wbcICO(@?NE^51 z!ca0MzIy8E@Xg-^|EC=Qz%A*2yak0sl@Ff5{A% zs8e$W=trnf54j8M=3`*IDd3Pb+X0(h6C7cA(4FXRw3&i2IZ$o)&O&C;3SKZ_9NSXD zwx$rd=%_U147~+ZsRQiVs|GW9ZxAwC(uJcY#21O~r3__wFHgxYn!-z;#tMjd1EiD{ z?qO$P7!3yT_OrB4)>_cf*^=XP%sB6Pk8rlysbd^0der;YBFfFmD|k zYVT{e$IXRN&^gsoHxROD?_MA<*GA$L3FU6vUz1je$J&&Y^q4Nl)%Tv&AeqKA6UBv$ZN3XxWr5|!3jFSTi}2$Ytgo?XSPy(=Xw1yur0 zU2}$aOv(ZnU5xh z4?{EN!-1=m`bFnHrCNPyyl?yXMDS9txWlO2lmR{^gkr3|3fv* z1EpNa1BS21e3t4n3DbB>O#_vtLSiO}c>nLeRlg=IY`bAB6%L>7xH9gHnUa?rV`fuZ z7~C|?x#-sPrEa>ydS}hcKAL1$9{N55_2DL?IWROH^G32{BKb^Iva^~sSx5OP!0U`{ zykUxQM(=mNUzYG+_KmmU)wIgUHT()lEp$Y7Va9exy={q_g1H{B-@>G}kh01y`(@-U z(~Dk7XZZ1>9%_yz?v=-7Tpu`2u}@aGo?Ymr=5r2Le}~KN>kL?G;5@YZP0oH3+Z|HM zw2_+dp$r+laN+Av(BCQCGX?G@YI10^?=2VSsPO79bPPosM%wOY7p|8F%x9_DqX1FX z2Se$V0O&2W(d(o#HPaMw+w_g0VZEjAPgm}wd>scr*5;mxs$OUXsHg+gbFH6N$q!b8 zkJ46$GdV8n^DU# zQBy)EN0!AoWeD1H-aptHbTL3Lo47gzZ;DZKMz>7SJDXlAZ}GIdgfIK1veo>OS)3N- z(aWSU=TFC05%yQFaAsxHGIF450_x3Ls9w;Sf6V@m+5ZD?XW)E~8|lX#O+1>F)yck_ zG)S}mG|La^G5rsNz<7r*e)i=JJlmsEIRqBZ;VxB2?ip>8Ql^W!h1J$+y&rr07jJqY9lIvT0D3 zRU*w+ZMuv8Qq_m~jZ1cK|AZ^dT^1Y~_vy&Rd`h+va;b;q)2d8pOkLB=Kvk+$^5wa6 z-|ES4c@mPRhz~_AaDxKkvn0qJ_1XvTjK$@1Q3{;V)W$#`@uNv-y7XE4a5yJk+}>Cj zJ-)FKf>S5xq8u4;o=uD~tmfc-qy-a#5r=OAq|+G79l?bi+^JT@y%hif zR;)X;4~ErEiF#ia&}O-#k20S>9)bDptniEBi^qiR0*uK~dK9;l|6RdFTPb8k@sg0J zmf+Av-J|Lvh-iI<@q*6I458j{kcrrzVI@~9b7XNHua#Sp(mZ9vmAhlp7&V7==_}yv2LiwM=DOMWG<$# zZ2pID#4l$=sV!~F+!h-WG*8Qh9=Zt37z&Jd*tlB}12nZ>JX&9HBeBIM&jKg7Tx;Or zKC9n1$hTpz_UpO<)w}923k+d1OR+(H(wp7v}54`jIfK_8I z`Q7+QM1KT61047(X*5dpj)Zb7Hui4?#E#u{g7DIKWFG@wJ8T+_et%OKFbqJtYyd6h&_`&-CG?P z(=YRozu(~}b+`HK;OHDht!~`(tH>#Q{(PJAg4_t~TPB2Kw0jv?bVkyaVcIEnaio-I zc2Zgvc%6%0sH3O6#)t5T0VJBCn>E*LnzD+(?^Rm5w zcbSQ;TI#fJZz>lQK1dajSG?!zmlq1!lwtXad1gF&3;A`lrTe`c%$cbb=@jnktVRdS zWS*ify2{mzRv4y7U!zn*!y0^q#b^Xtk4*hJoKG}>W3n~wLfeI#-gT+bLg;V7^OWM8 z)Tp#qwF@_~YZN)eUwCO(Ug`K8>_(t3=TSz#(KSdzc--HlyXeQ;kI$e&p{bxShLrbmBC zus0`N9Kl}%JS?6;cGH|D*zJMR;Y^gAj}$LD zMIY92-N@+C`9d%{lG}VzvnFNO@o9XTbGEWpo};kQtf@#ZXUd*&4Pclt@#TyjFN5G$ z)(#l&_eSW52Ylc=&JKuu`+n8GoXN z59!J|Lf^piiwMkbakuj|L%OhvJfB$xTF{it+#Tw*aHwIF5av23Ael*O_$@{+T6M+y z`oUjKi#z+j57D;06#xUX7x6-ik|$Tz&m|#n>f+j2YQojtIXYcf%j1)1#~L}rb%lr{ zf3DyAHRP>R_>d#B-p;{3X(1StKl&;?t5?|=2E}y<+pxkOgd>ZfIacuQEVoc8bJ^jF z4+_WO{xvdyFvido!logjX9glpB}cS#w@>(wap%sRJKg{t z>BSD3idSWIoU9lMQ&Zo){Hd>n)5I7hrduE3z!2z> zF$+1WT$DchFXzCD&X1X>DKpe8w~Fijmm^`1Avj&E@)yXtsyf+Za!eKa)04=G0x)XC zkD~+|QNL>(L;;;uK(6Q=NEBIj+jA8@flr0X=j6x8pj6rZX4LE@Oi>^s(N%+pvmOoJ zmN`y-UygkgG?bJ~_SWfao}vH;$9MZp<>clMs>-Roa@FH08NT;KvH`hFHct=cOEcNf zhN($Duh0Eor|6*6e0t(*7nHOh-NyB=3Y#ERii*c5ND55Ca0L4|k3VdVOtvL={;6i_ zL}UdLEyPq!QAC#~i?Z-A4yvEDa#GOPnYus8zITTvRNU{RIZlGhuRLd7zsh8SRTWOMK=EBlzj1y@q#~bVD~)R@Gr+@UM{0hgh80} z@RAyZnuE6No-J3LKUt(2wW??YdZP)i1k|nSgMD9wm+GkfR>`;IMw&fBy_@fqKTREp zp?=`SK+Yk3{`W_0+Ti%`cvY{!KqKqqw!qo-Wb$BO;XyWkW|?wpdpEaNKhdNZx*nBOIQ1zcaM8zca7=fCpI3z~Q&3yQY zx+$gCwa{YBzR%E~rR_XcrdLzn#hNw#nbf(4Oh-DW4VX>1#urjY2gFxfxWya6q1@PP#S)>c77Mv-J&~Ve7#C{5ilqb09BFZ%RW?+ zB(ZxOEaXml&=BrAar7(%WL=vM$J_xr7|_|MQ&k<}<)qkVbYqlzWBWGLS65TxRDQRd zfAs5o(i_Bf)eGE~UHSxvzjoTyCBg;k#_R|0?TRna(G@*~fsgc`L3Ire)r!|lNW~@4 za0UG+@#BJZ1ZPMx@tEHtEyLW%NGzCL^*EJm!huo^1T7XjgVf*kpxxuwxNmHkuRKjL zGi$75R#Onc1bmh$T99}*H)+ug_#vk#)$}>r31viA{mZzx2tu%b8dXX=SC=J!R`+p% zR2N(Zr=w-hb_o()oOpYx&I1pai)_lE%#h(FV<}-bbe}bNNiRIfZS&2p8qnhy3u6nF zjzH%~$9(+5zLEntrUm-@wTuMYDHkV(F4N1)T4zVF?Af;^mToTa9fjsGx^E*&_Fjw0 zw~F@8hZx#B7!>4MTjUnjLkbJsu}+xRLX%7=_o0~41!rL;&V+-0F&i${1qnoM;t{h3 zw;e$fl%d+|H-Fbc7jBwd@31UjJKSmeCDJw6fR(^3dJQdLky|}7eHH!cqlc^>B`Aws zYCIFs7#~hxPRG$>5J>q8$MwNI55P|&5VrU++KjJVn+U;Y`7$)b!IY1S(P!IU3*{o>pEK_PoGxj7rwz#fe7>LE=TM=q>e@k9E86UKJ+z0n%grt+eNz(Ajh+cu zKwPagb6`!ClqD1KBnRa?vGvC@nRPJ3bB#l~bWRnKTU4ZUFc)na#$uygoe1kHkTSbgh3VlY3qfjFmGGh1gBdhy(T3ho_B0^Eue54> zGrO)GSh%gwZy#i&&1d_$iKOZ#N2g4k#R9r*7^`~j)y~qjEuneSeMLpf#7V7+RX^Tw z`1B|m+iP5+*dH^nj#l9e;a<*8+M&HU6wPOP!DZ`$xhuGbHQ+{H^ulaoXI2Ql3Y`xbU8D#)$Jtr z=1mws7LKhIe8NxUy=s?}<} zb?^sYO6g$<_ZEPiz^m#>>cvGvA{XKc;PenV_4u*)uB0+~KRBpMToN(N%NmPNRUAE; zpcK^gB7wFggYg;2-slKQZHx)yE;+aRkHOK>b8>dfRMo8R|+c&@{{sb9++UNqDY zC<3}bIqr?wNuCBFdbbm7yNU)ax&`ts?ZSjc#Ra1rPSVmKKytzfX_l1yDU;yuN0`GE z0?#o?pQiBV_Ph#-<9(Zrx=&Cm-enO_YJ+uA2e!bA7H=?&>mjz#dScUAVzZEbmDX>$ z%fcFG>a&*dQ{K9<3;fC1yX=$ek+#jAX|Hy-bOmZRbz?SH4&1zqPZ;>x4p8 a_XyRdy1QZ%@C8jEr^D`tst=s{>3;#p)Md^9 literal 0 HcmV?d00001 From 5036ebe02b4c2090386f8c1dc7ebee6d65a26c48 Mon Sep 17 00:00:00 2001 From: Eric Lombrozo Date: Thu, 24 Dec 2015 17:37:28 -0500 Subject: [PATCH 03/11] Removed consensus layer stuff and added new section headers. --- bip-codeshark-segwit-peer-services.mediawiki | 219 +------------------ 1 file changed, 5 insertions(+), 214 deletions(-) diff --git a/bip-codeshark-segwit-peer-services.mediawiki b/bip-codeshark-segwit-peer-services.mediawiki index c81e1dbb..35bd0598 100644 --- a/bip-codeshark-segwit-peer-services.mediawiki +++ b/bip-codeshark-segwit-peer-services.mediawiki @@ -15,6 +15,8 @@ This BIP defines new messages and serialization formats for propagation of trans ==Specification== +=== Serializations === + A new serialization format for tx messages is added to the peer-to-peer protocol. The serialization has the following structure: @@ -113,223 +115,12 @@ have empty ones. serialization. A new CTransaction::GetWitnessHash is added which is computed from the witness-serialization (this means that transactions with an empty witness have witness hash equal to normal hash). - -=== Commitment structure === +== Synchronization == -!!!DRAFT ONLY!!! +=== Initial Blockchain Download === -A new block rule is added which requires a commitment to the witness hashes in the coinbase (or an OP_RETURN output of a specific transaction, or somewhere else) - -(Hardfork after x year to move the commitment to block header?) - -Witness hash is the double SHA256 of a transaction including witnesses: http://blockhawk.net/diagrams/witnesstx.png. For the coinbase transaction, its witness hash is assumed to be 0x0000....0000. - -A witness root hash is calculated with all those witness hashes as leaves, in a way similar to the hashMerkleRoot in the block header. - -No witness data is allowed in blocks that don't commit to witness data, as this would otherwise leave room from spam. - -==== Proposal 1: balance tree (the current implementation) ==== -The commitment is a push of exactly 41 bytes: -*The first 4 bytes are commitment header: 0xaa21a9ed -*The next 4 bytes describe a nonce -*The next 1 byte is the "levels bytes", describes the number of levels in a Merkle tree (0 to 32) -*The next 32 bytes is a commitment root hash (not the witness root hash) - -Locator of the witness root hash is defined as: - -
SHA256('WitnessV1\x00\x00\x00\x00\x00\x00\x00' || nonce)
- -The first levels bits of locator, interpreted in little endian, are assumed to be the position in the leaves of the Merkle tree where the witness root hash goes. - -The coinbase's input's witness must consist of a single byte array of 32 * levels bytes, and are assumed to be the Merkle path to connect the witness root hash to the commitment root hash. - -====Proposal 2: imbalance tree==== -The commitment is a push of exactly 40 bytes: -*The first 4 bytes are commitment header: 0xaa21a9ed -*The next 4 bytes describe a nonce -*The next 32 bytes is a commitment root hash (not the witness root hash) - -Locator of the witness root hash is defined as: - -
SHA256('WitnessV1\x00\x00\x00\x00\x00\x00\x00' || nonce)
- -The first levels bits of locator, interpreted in little endian, are assumed to be the position in the leaves of the Merkle tree where the witness root hash goes. - -The coinbase's input's witness must consist of a single byte array, which the size must be a multiple of 32 bytes but not bigger than 32*32 bytes. These are assumed to be the Merkle path to connect the witness root hash to the commitment root hash. Depth of the commitment is determined by the length of the path. If the depth of the tree is 0, the path should be represented by 0x00, and the witness root hash will be same as the commitment root hash. - -=== Block size limit === -Blocks are currently limited to 1 MB total size. We change this restriction as follows: - -We define a base block size sb consisting of the existing header and transactions, a witness size sw consisting of only the size of the witness data, and a virtual block size sv = sb + sw/4. - -The new rule is sv <= 1 MB. - -=== Witness program === - -* A scriptPubKey (or redeemScript as defined in BIP16/P2SH) that consists of a single push of 2 to 41 bytes gets a new special meaning. The byte vector pushed by it is called the "witness program". -** In case the scriptPubKey pushes a witness program directly, the scriptSig must be exactly empty. -** In case the redeemScript pushes a witness program, the scriptSig must be exactly the single push of the redeemScript. - -* The first byte of a witness program is the "version byte", an unsigned integer. -** If the version byte is 0, the rest of the witness program is the actual script. -*** The script is executed after normal script evaluation but with data from the witness rather than the scriptSig. -*** The program must not fail, and result in exactly a single TRUE on the stack. -** If the version byte is 1, the rest of the witness program must be 32 bytes, as a SHA256 hash of the actual script. -*** The witness must consist of an input stack to feed to the program, followed by the serialized program. -*** The serialized program is popped off the initial witness stack. Hash of the serialized program must match the hash pushed in the witness program. -*** The serialized program is deserialized, and executed after normal script evaluation with the remaining witness stack. -*** The script must not fail, and result in exactly a single TRUE on the stack. -** If the witness version byte is 2 or above, no further interpretation of the witness program or witness happens. - -=== Other consensus critical constraints === - -== Block size analysis == -WORK IN PROGRESS - -Definitions: -
- Core block size (CBS): The block size as seen by a non-upgrading full node
- Witness size (WS): The total size of witness data in a block
- Total block size (TBS): CBS + WS
- Witness discount (WD): A discount factor for witness data in VBS calculation (1 = no discount)
- Virtual block size (VBS): CBS + (WS * WD)
- Witness adoption (WA): Proportion (in size) of new format transactions among all transactions
- Prunable ratio (PR): Proportion of signature data size in a transaction
-
- -With some transformation it could be shown that: -
- TBS = CBS / (1 - WA * PR)
-     = VBS / (1 - WA * PR * (1 - WD))
-
- -In order to keep the proposal as a soft fork, the CBS must not have a upper limit higher than 1MB. - -The PR heavily depends on the transaction script type and input-output ratio. For example, the PR of 1-in 2-out P2PKH and 1-in 1-out 2-of-2 multisig P2SH are about 47% and 72% respectively. According to the data presented by Pieter Wuille on 7 December 2015, the current average PR on the blockchain is about 60%. - - - -== Examples == - -=== Version 0 witness program === - -The following example is a version 0 witness program, equivalent to the existing Pay-to-Pubkey-Hash (P2PKH) output. - - witness: - scriptSig: (empty) - scriptPubKey: <0x0076A914{20-byte-hash-value}88AC> - -The version byte 0x00 is removed. The rest of the witness program is deserialized and becomes: - - DUP HASH160 <20byte-hash-value> EQUALVERIFY CHECKSIG - -The script is executed with the data from witness - - DUP HASH160 <20byte-hash-value> EQUALVERIFY CHECKSIG - -Comparing with a P2PKH output, the witness program equivalent occupies 2 more bytes in the scriptPubKey, while moving the signature and public key from scriptSig to witness. - -=== Version 1 witness program === - -The following example is an 1-of-2 multi-signature version 1 witness program. - - witness: 0 <0x5121{33-byte-pubkey1}21{33-byte-pubkey2}52AE> - scriptSig: (empty) - scriptPubKey: <0x01{32-byte-hash-value}> - -The last item in the witness is popped off, hashed with SHA256, compared against the 32-byte-hash-value in scriptPubKey, and deserialized: - - 1 <33-byte-pubkey1> <33-byte-pubkey2> 2 CHECKMULTISIG - -The script is executed with the remaining data from witness: - - 0 1 <33-byte-pubkey1> <33-byte-pubkey2> 2 CHECKMULTISIG - -Since the actual program is larger than 40 bytes, it cannot be accommodated in a version 0 witness program. A version 1 witness program allows arbitrarily large script as the 520-byte push limit is bypassed. - -The scriptPubKey occupies 34 bytes, as opposed to 23 bytes of P2SH. The increased size improves security against possible collision attacks, as 2^80 work is not infeasible anymore (By the end of 2015, 2^84 hashes have been calculated in Bitcoin mining since the creation of Bitcoin). The spending script is same as the one for an equivalent P2SH output but is moved to witness. - -=== Witness program nested in Pay-to-Script-Hash === - -The following example is the same 1-of-2 multi-signature version 1 witness program, but nested in a P2SH output. - - witness: 0 <0x5121{33-byte-pubkey1}21{33-byte-pubkey2}52AE> - scriptSig: <0x2101{32-byte-hash-value}> - scriptPubKey: HASH160 <20-byte-hash-value> EQUAL - -The only item in scriptSig is hashed with HASH160, compared against the 20-byte-hash-value in scriptPubKey, and interpreted as a single push of: - - <0x01{32-byte-hash-value}> - -The version 1 witness program is then executed as described in the last example - -Comparing with the last example, the scriptPubKey is 11 bytes smaller (with reduced security) while witness is the same. However, it also requires 35 bytes in scriptSig, which is not prunable in transmission. Although a nested witness program is less efficient in many ways, its payment address is fully transparent and backward compatible for all Bitcoin reference client since version 0.6.0. - -=== Trust-free unconfirmed transaction dependency chain === -Segregated witness fixes the problem of transaction malleability fundamentally, which enables the building of unconfirmed transaction dependency chains in a trust-free manner. - -Two parties, Alice and Bob, may agree to send certain amount of Bitcoin to a 2-of-2 multisig output (the "funding transaction"). Without signing the funding transaction, they may create another transaction, time-locked in the future, spending the 2-of-2 multisig output to third account(s) (the "spending transaction"). Alice and Bob will sign the spending transaction and exchange the signatures. After examining the signatures, they will sign and commit the funding transaction to the blockchain. Without further action, the spending transaction will be confirmed after the lock-time and release the funding according to the original contract. It also retains the flexibility of revoking the original contract before the lock-time, by another spending transaction with shorter lock-time, but only with mutual-agreement of both parties. - -Such setups is not possible with BIP62 as the malleability fix, since the spending transaction could not be created without both parties first signing the funding transaction. If Alice reveals the funding transaction signature before Bob does, Bob is able to lock up the funding indefinitely without ever signing the spending transaction. - -Unconfirmed transaction dependency chain is a fundamental building block of more sophisticated payment networks, such as duplex micropayment channel and the Lightning Network, which have the potential to greatly improve the scalability and efficiency of the Bitcoin system. - -== Future extensions == -=== Compact fraud proof for SPV nodes === -Bitcoin right now only has two real security models. A user either runs a full-node which validates every block with all rules in the system, or a SPV (Simple Payment Verification) client which only validates the headers as a proof of publication of some transactions. The Bitcoin whitepaper suggested that SPV nodes may accept alerts from full nodes when they detect an invalid block, prompting the SPV node to download the questioned blocks and transactions for validation. This approach, however, could become a DoS attack vector as there is virtually no cost to generate a false alarm. An alarm must come with a compact, yet deterministic fraud proof. - -In the current Bitcoin protocol, it is possible to generate compact fraud proof for almost all rules except a few: - -# It is not possible to proof a miner has introduced too many Bitcoins in the coinbase transaction outputs without showing the whole block itself and all input transactions. -# It is not possible to prove the violation of any block specific constraints, such as size and sigop limits, without showing the whole block (and all input transactions in the case of sigop limit) -# It is not possible to prove the spending of a non-existing input without showing all transaction IDs in the blockchain way back to the genesis block. - -It is possible to proof the first 2 types of fraud if a block is committed to a Merkle-sum-tree of the fee, size, and sigop count of each transaction. It is also possible to proof the last type of fraud if a block is committed to a Merkle tree with the originating block height and transaction index of all inputs. These commitments could be included in the extensible witness commitment through a soft fork and will be transparent to nodes that do not understand such new rules. - -=== New script system === -Since all witness programs begin with a version byte, and programs with unknown versions are always considered as anyone-can-spend script, it is possible to introduce any new script system with a soft fork. The witness as a structure is not restricted by any existing script semantics and constraints, the 520-byte push limit in particular, and therefore allows arbitrarily large scripts and signatures. - -Examples of new script system include Schnorr signatures which reduce the size of multisig transactions dramatically, Lamport signature which is quantum computing resistance, and Merklized abstract syntax trees which allow very compact witness for conditional scripts with extreme complexity. - -The 41-byte limitation for witness programme could be easily extended through a soft fork in case a stronger hash function is needed in the future. The version byte is also expandable by introducing a secondary version byte for some specific primary version values. - -=== 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. 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 BIP65 and BIP112). - -== Backward compatibility == -As a soft fork, older software will continue to operate without modification. Non-upgraded nodes, however, will not see nor validate the witness data and will consider all witness programs as anyone-can-spend scripts (except a few edge cases in version 0 witness programs which are provably unspendable with original script semantics). Wallets should always be wary of anyone-can-spend scripts and treat them with suspicion. Non-upgraded nodes are strongly encouraged to upgrade in order to take advantage of the new features. - -=== Version 0 witness programs === -Witness programs are hashed to 256 bit "redeemscripts" which are then hashed to 160 bit P2SH. This format is fully compatible with currently existing wallets that support P2SH. Upgraded wallets will be able to send and receive to and from older wallets without any problems. - -=== Version 1 witness programs === -Witness programs are hashed to a 256 bit output. This format will not be compatible with older wallets but will require less block space and will have better security due to increased collision resistance. - -== Deployment == - -We reuse the double-threshold IsSuperMajority() switchover mechanism used in -BIP65 with the same thresholds, but for nVersion = 5. The new rules are -in effect for every block (at height H) with nVersion = 5 and at least -750 out of 1000 blocks preceding it (with heights H-1000..H-1) also -have nVersion >= 5. Furthermore, when 950 out of the 1000 blocks -preceding a block do have nVersion >= 5, nVersion < 5 blocks become -invalid, and all further blocks enforce the new rules. - -(It should be noted that BIP9 involves permanently setting a high-order bit to -1 which results in nVersion >= all prior IsSuperMajority() soft-forks and thus -no bits in nVersion are permanently lost.) - - -=== SPV Clients === - -While SPV clients are unable to fully validate blocks, -they are able to validate block headers and, thus, can check block version and proof-of-work. -SPV clients should reject nVersion < 5 blocks if 950 out of 1000 preceding blocks have -nVersion >= 5 to prevent false confirmations from the remaining 5% of -non-upgraded miners when the 95% threshold has been reached. +=== Message Propagation === == Credits == Special thanks to Gregory Maxwell for originating many of the ideas in this BIP and Luke-Jr for figuring out how to deploy this as a soft fork. From 0d887af4035dc8f5258ad3c54f5a42d2973f6b1d Mon Sep 17 00:00:00 2001 From: Eric Lombrozo Date: Fri, 25 Dec 2015 19:03:02 -0500 Subject: [PATCH 04/11] Separate authors into two lines. --- bip-codeshark-segwit-peer-services.mediawiki | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/bip-codeshark-segwit-peer-services.mediawiki b/bip-codeshark-segwit-peer-services.mediawiki index 35bd0598..121cd5a1 100644 --- a/bip-codeshark-segwit-peer-services.mediawiki +++ b/bip-codeshark-segwit-peer-services.mediawiki @@ -1,7 +1,8 @@ 
   BIP: x
   Title: Segregated Witness (Peer Services)
-  Authors: Eric Lombrozo , Pieter Wuille 
+  Author: Eric Lombrozo 
+          Pieter Wuille 
   Status: Draft
   Type: Standards Track
   Created: 2015-12

From 84dc2f7ddcf0b08adec056532fd9021ee461d1d5 Mon Sep 17 00:00:00 2001
From: Eric Lombrozo 
Date: Fri, 25 Dec 2015 18:57:27 -0500
Subject: [PATCH 05/11] New sections

---
 bip-codeshark-segwit-peer-services.mediawiki | 30 ++++++++------------
 1 file changed, 12 insertions(+), 18 deletions(-)

diff --git a/bip-codeshark-segwit-peer-services.mediawiki b/bip-codeshark-segwit-peer-services.mediawiki
index 121cd5a1..37c5d17d 100644
--- a/bip-codeshark-segwit-peer-services.mediawiki
+++ b/bip-codeshark-segwit-peer-services.mediawiki
@@ -16,8 +16,7 @@ This BIP defines new messages and serialization formats for propagation of trans
 
 ==Specification==
 
-=== Serializations ===
-
+=== Serialization ===
 A new serialization format for tx messages is added to the peer-to-peer protocol.
 
 The serialization has the following structure:
@@ -63,7 +62,7 @@ The serialization has the following structure:
 | txouts[]
 | A list of one or more transaction outputs
 |-
-| 
+| 1+
 | txin_witness
 | txin_witness
 | Transaction input witness
@@ -85,10 +84,7 @@ Witness objects can potentially be extended to contain other kinds of witness da
 A script witness is a vector of byte vectors (nominally: the input stack to the program, no longer
 encoded as a scriptSig, but just the resulting stack directly).
 
-as a valid transaction (even if parsing succeeds, it means it's
-interpreted as a transaction with no inputs and 1 output). If all
-witnesses are empty, the old serialization format is used.
-- Rationale for not having an independent CWitnessTransaction with
+- 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
@@ -100,29 +96,27 @@ used in some tests) to be interpreted as new serialized data.
 easily add more extra non-committed data to transactions (like txouts
 being spent, ...). It can be interpreted as a bitvector.
 
-* A new message 'havewitness' is sent after receiving 'verack' to
+=== Handshake ===
+A new message 'havewitness' is sent after receiving 'verack' to
 indicate that a node can provide witness if requested (similar to
-'sendheaders')
+'sendheaders') (Note: it might be better to signal this with a services bit in the version message)
 
-* New inv types MSG_WITNESS_TX and MSG_WITNESS_BLOCK are added, only
+=== Relay ===
+New inv types MSG_WITNESS_TX and MSG_WITNESS_BLOCK are added, only
 for use in getdata. Inv itself still use just MSG_TX and MSG_BLOCK,
 similar to MSG_FILTERED_BLOCK.
+
 - Rationale for not advertizing witnessness in invs: we don't always
 use invs anymore (with 'sendheaders' BIP 130), plus it's not useful:
 implicitly, every transaction and block have a witness, old ones just
 have empty ones.
 
-* Transactions' GetHash is always computed on the old non-witness
-serialization. A new CTransaction::GetWitnessHash is added which is
+=== Hashes ===
+Transaction hashes used in the transaction merkle tree and txin outpoints is always computed on the old non-witness
+serialization. A new hash including the witness data is added that is
 computed from the witness-serialization (this means that transactions
 with an empty witness have witness hash equal to normal hash).
 
-== Synchronization ==
-
-=== Initial Blockchain Download ===
-
-=== Message Propagation ===
-
 == Credits ==
 Special thanks to Gregory Maxwell for originating many of the ideas in this BIP and Luke-Jr for figuring out how to deploy this as a soft fork.
 

From 0ea5ba232dd33836d9ce0a4b24690dd8a8c0f193 Mon Sep 17 00:00:00 2001
From: Eric Lombrozo 
Date: Fri, 25 Dec 2015 19:14:36 -0500
Subject: [PATCH 06/11] Added motivation section text.

---
 bip-codeshark-segwit-peer-services.mediawiki | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/bip-codeshark-segwit-peer-services.mediawiki b/bip-codeshark-segwit-peer-services.mediawiki
index 37c5d17d..7e94b737 100644
--- a/bip-codeshark-segwit-peer-services.mediawiki
+++ b/bip-codeshark-segwit-peer-services.mediawiki
@@ -9,10 +9,10 @@
==Abstract== - This BIP defines new messages and serialization formats for propagation of transactions and blocks committing to segregated witness structures. ==Motivation== +In addition to defining witness structures and requiring commitments in future blocks (BIPxxxx - Consensus segwit BIP), new mechanisms must be defined to allow peers to advertise support for segregated witness and to relay the witness structures and request them from other peers without breaking compatibility with older nodes. ==Specification== From 0ab3b3eb0c50ea24c9043219d7f968825dc68221 Mon Sep 17 00:00:00 2001 From: Eric Lombrozo Date: Fri, 25 Dec 2015 19:17:00 -0500 Subject: [PATCH 07/11] Moved diagrams to hashes section. --- bip-codeshark-segwit-peer-services.mediawiki | 15 +++++++++------ 1 file changed, 9 insertions(+), 6 deletions(-) diff --git a/bip-codeshark-segwit-peer-services.mediawiki b/bip-codeshark-segwit-peer-services.mediawiki index 7e94b737..c5b205ef 100644 --- a/bip-codeshark-segwit-peer-services.mediawiki +++ b/bip-codeshark-segwit-peer-services.mediawiki @@ -73,8 +73,6 @@ The serialization has the following structure: | The block number or timestamp until which the transaction is locked |} - - Parsers supporting this BIP will be able to distinguish between the old serialization format (without the witnesses) and this one. The marker byte is set to zero so that this structure will never parse as a valid transaction in a parser that does not support this BIP. If parsing were to succeeded, such a transaction would contain no inputs and a single output. If all witnesses are empty, the old serialization format should be used. @@ -112,10 +110,15 @@ implicitly, every transaction and block have a witness, old ones just have empty ones. === Hashes === -Transaction hashes used in the transaction merkle tree and txin outpoints is always computed on the old non-witness -serialization. A new hash including the witness data is added that is -computed from the witness-serialization (this means that transactions -with an empty witness have witness hash equal to normal hash). +Transaction hashes used in the transaction merkle tree and txin outpoints are always computed using the old non-witness +serialization. + +Support for a new hash including the witness data is added that is +computed from the new witness serialization. (Note that transactions +with an empty witness always use the old serialization, +and therefore, they have witness hash equal to normal hash.) + + == Credits == Special thanks to Gregory Maxwell for originating many of the ideas in this BIP and Luke-Jr for figuring out how to deploy this as a soft fork. From 1f538fd4589b18ddede831e0cbfb0401f5ec8472 Mon Sep 17 00:00:00 2001 From: Eric Lombrozo Date: Fri, 25 Dec 2015 19:41:39 -0500 Subject: [PATCH 08/11] Bulletted rationales and other minor changes. --- bip-codeshark-segwit-peer-services.mediawiki | 30 ++++++-------------- 1 file changed, 9 insertions(+), 21 deletions(-) diff --git a/bip-codeshark-segwit-peer-services.mediawiki b/bip-codeshark-segwit-peer-services.mediawiki index c5b205ef..6e0bc6e7 100644 --- a/bip-codeshark-segwit-peer-services.mediawiki +++ b/bip-codeshark-segwit-peer-services.mediawiki @@ -63,9 +63,9 @@ The serialization has the following structure: | A list of one or more transaction outputs |- | 1+ -| txin_witness -| txin_witness -| Transaction input witness +| txin_witnesses +| txin_witnesses[] +| A list of one or more transaction input witnesses (note: the count is just txin_count) |- | 4 | lock_time @@ -77,22 +77,13 @@ Parsers supporting this BIP will be able to distinguish between the old serializ If all witnesses are empty, the old serialization format should be used. -Witness objects can potentially be extended to contain other kinds of witness data. +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 BIPxxxx (Consensus Segwit BIP), and treats it as an arbitrary byte array. -A script witness is a vector of byte vectors (nominally: the input stack to the program, no longer -encoded as a scriptSig, but just the resulting stack directly). +* '''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. -- 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. -- Rationale for not using just a single 0x00 byte as marker: that -would lead to empty transactions (no inputs, no outputs, which are -used in some tests) to be interpreted as new serialized data. -- Rationale for the 0x01 flag byte in between: this will allow us to -easily add more extra non-committed data to transactions (like txouts -being spent, ...). It can be interpreted as a bitvector. +* '''Rationale for not using just a single 0x00 byte as marker''': that would lead to empty transactions (no inputs, no outputs, which are used in some tests) to be interpreted as new serialized data. + +* '''Rationale for the 0x01 flag byte in between''': this will allow us to easily add more extra non-committed data to transactions (like txouts being spent, ...). It can be interpreted as a bitvector. === Handshake === A new message 'havewitness' is sent after receiving 'verack' to @@ -104,10 +95,7 @@ New inv types MSG_WITNESS_TX and MSG_WITNESS_BLOCK are added, only for use in getdata. Inv itself still use just MSG_TX and MSG_BLOCK, similar to MSG_FILTERED_BLOCK. -- Rationale for not advertizing witnessness in invs: we don't always -use invs anymore (with 'sendheaders' BIP 130), plus it's not useful: -implicitly, every transaction and block have a witness, old ones just -have empty ones. +* '''Rationale for not advertizing witnessness in invs''': we don't always use invs anymore (with 'sendheaders' BIP 130), plus it's not useful: implicitly, every transaction and block have a witness, old ones just have empty ones. === Hashes === Transaction hashes used in the transaction merkle tree and txin outpoints are always computed using the old non-witness From 35990e2faa69c326807418a6405a25139e92db6f Mon Sep 17 00:00:00 2001 From: Eric Lombrozo Date: Fri, 25 Dec 2015 19:56:11 -0500 Subject: [PATCH 09/11] Use abstract witness structure --- bip-codeshark-segwit-peer-services.mediawiki | 10 +++++----- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/bip-codeshark-segwit-peer-services.mediawiki b/bip-codeshark-segwit-peer-services.mediawiki index 6e0bc6e7..7501d2b8 100644 --- a/bip-codeshark-segwit-peer-services.mediawiki +++ b/bip-codeshark-segwit-peer-services.mediawiki @@ -63,9 +63,9 @@ The serialization has the following structure: | A list of one or more transaction outputs |- | 1+ -| txin_witnesses -| txin_witnesses[] -| A list of one or more transaction input witnesses (note: the count is just txin_count) +| witness +| witness +| The witness structure as a serialized byte array |- | 4 | lock_time @@ -73,9 +73,9 @@ The serialization has the following structure: | The block number or timestamp until which the transaction is locked |} -Parsers supporting this BIP will be able to distinguish between the old serialization format (without the witnesses) and this one. The marker byte is set to zero so that this structure will never parse as a valid transaction in a parser that does not support this BIP. If parsing were to succeeded, such a transaction would contain no inputs and a single output. +Parsers supporting this BIP will be able to distinguish between the old serialization format (without the witness) and this one. The marker byte is set to zero so that this structure will never parse as a valid transaction in a parser that does not support this BIP. If parsing were to succeeded, such a transaction would contain no inputs and a single output. -If all witnesses are empty, the old serialization format should be used. +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 BIPxxxx (Consensus Segwit BIP), and treats it as an arbitrary byte array. From d0ad38fb692ac919bd116a69f5f60e0c856b9148 Mon Sep 17 00:00:00 2001 From: Eric Lombrozo Date: Sat, 26 Dec 2015 16:41:57 -0500 Subject: [PATCH 10/11] Added to relay section. --- bip-codeshark-segwit-peer-services.mediawiki | 18 +++++++++++------- 1 file changed, 11 insertions(+), 7 deletions(-) diff --git a/bip-codeshark-segwit-peer-services.mediawiki b/bip-codeshark-segwit-peer-services.mediawiki index 7501d2b8..78412c1d 100644 --- a/bip-codeshark-segwit-peer-services.mediawiki +++ b/bip-codeshark-segwit-peer-services.mediawiki @@ -90,13 +90,6 @@ A new message 'havewitness' is sent after receiving 'verack' to indicate that a node can provide witness if requested (similar to 'sendheaders') (Note: it might be better to signal this with a services bit in the version message) -=== Relay === -New inv types MSG_WITNESS_TX and MSG_WITNESS_BLOCK are added, only -for use in getdata. Inv itself still use just MSG_TX and MSG_BLOCK, -similar to MSG_FILTERED_BLOCK. - -* '''Rationale for not advertizing witnessness in invs''': we don't always use invs anymore (with 'sendheaders' BIP 130), plus it's not useful: implicitly, every transaction and block have a witness, old ones just have empty ones. - === Hashes === Transaction hashes used in the transaction merkle tree and txin outpoints are always computed using the old non-witness serialization. @@ -108,6 +101,17 @@ and therefore, they have witness hash equal to normal hash.) +=== Relay === +New inv types MSG_WITNESS_TX and MSG_WITNESS_BLOCK are added, only +for use in getdata. Inventory messages themselves still use just MSG_TX and MSG_BLOCK, +similar to MSG_FILTERED_BLOCK. + +* '''Rationale for not advertizing witnessness in invs''': we don't always use invs anymore (with 'sendheaders' BIP 130), plus it's not useful: implicitly, every transaction and block have a witness, old ones just have empty ones. + +MSG_WITNESS_TX getdata requests should use the non-witness serialized hash. The peer shall respond with a tx message, and if the witness structure is nonempty, the witness serialization shall be used. + +MSG_WITNESS_BLOCK requests will return a block message with transactions that have a witness using witness serialization. + == Credits == Special thanks to Gregory Maxwell for originating many of the ideas in this BIP and Luke-Jr for figuring out how to deploy this as a soft fork. From 8084782fa5d3143555db1e8ac13eda5a4ae82c52 Mon Sep 17 00:00:00 2001 From: Luke Dashjr Date: Fri, 8 Jan 2016 17:59:36 +0000 Subject: [PATCH 11/11] Assign BIP 144 --- README.mediawiki | 6 ++++++ ...it-peer-services.mediawiki => bip-0144.mediawiki | 4 ++-- .../witnesstx.png | Bin 3 files changed, 8 insertions(+), 2 deletions(-) rename bip-codeshark-segwit-peer-services.mediawiki => bip-0144.mediawiki (98%) rename {bip-codeshark-segwit-peer-services => bip-0144}/witnesstx.png (100%) diff --git a/README.mediawiki b/README.mediawiki index b45c17a0..ce44289c 100644 --- a/README.mediawiki +++ b/README.mediawiki @@ -379,6 +379,12 @@ Those proposing changes should consider that ultimately consent may rest with th | Suhas Daftuar | Standard | Draft +|- +| [[bip-0144.mediawiki|144]] +| Segregated Witness (Peer Services) +| Eric Lombrozo, Pieter Wuille +| Standard +| Draft |} diff --git a/bip-codeshark-segwit-peer-services.mediawiki b/bip-0144.mediawiki similarity index 98% rename from bip-codeshark-segwit-peer-services.mediawiki rename to bip-0144.mediawiki index 78412c1d..ed8cf2be 100644 --- a/bip-codeshark-segwit-peer-services.mediawiki +++ b/bip-0144.mediawiki @@ -1,5 +1,5 @@ 
-  BIP: x
+  BIP: 144
   Title: Segregated Witness (Peer Services)
   Author: Eric Lombrozo 
           Pieter Wuille 
@@ -99,7 +99,7 @@ computed from the new witness serialization. (Note that transactions
 with an empty witness always use the old serialization,
 and therefore, they have witness hash equal to normal hash.)
 
-
+
 
 === Relay ===
 New inv types MSG_WITNESS_TX and MSG_WITNESS_BLOCK are added, only
diff --git a/bip-codeshark-segwit-peer-services/witnesstx.png b/bip-0144/witnesstx.png
similarity index 100%
rename from bip-codeshark-segwit-peer-services/witnesstx.png
rename to bip-0144/witnesstx.png