bitcoin/bips
1
0
Fork 0
mirror of https://github.com/bitcoin/bips.git synced 2025-05-12 12:03:29 +00:00
Code Issues Releases Wiki Activity

Update bip-segwit.mediawiki

Browse Source
This commit is contained in:
Johnson Lau 2015-12-22 22:54:40 +08:00 committed by Eric Lombrozo
parent f026c28da5
commit 26a7293e67
1 changed files with 2 additions and 8 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

10
bip-codeshark-jl2012-segwit.mediawiki
View File

@ -123,12 +123,8 @@ The first levels bits of locator, interpreted in little endian, are assumed to b
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 ===
A seperate BIP?
<pre>
2-4-8?
Discount for witness data?
Start at softfork, moving to hardfork?
</pre>
Virtual block size limit?
=== Witness program ===
@ -265,9 +261,7 @@ Currently there is only one nLockTime field in a transaction and all inputs must
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 ==
Without lifting the core block size limit of 1MB at the beginning, this proposal is a soft fork which all existing full nodes and SPV nodes are compatible. Non-upgrading 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). Non-upgrading nodes are also unable to generate or sign for scriptPubKey templates (payment address). Nonetheless, they may still pay to a witness program if it is nested in a P2SH address, which has been defined since 2012.
When the core block size limit is increased to over 1MB as scheduled, this proposal becomes a hard fork. Anybody running code that fully validates blocks must upgrade before the activation time or they will reject a chain containing blocks with core block size above 1MB. SPV software is not affected, unless it makes assumptions about the maximum depth of the Merkle tree based on the minimum size of a transaction and the maximum block size.
Without lifting the core block size limit of 1MB, this proposal is a soft fork which all existing full nodes and SPV nodes are compatible. Non-upgrading 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). Non-upgrading nodes are also unable to generate or sign for scriptPubKey templates (payment address). Nonetheless, they may still pay to a witness program if it is nested in a P2SH address, which has been defined since 2012.
== Deployment ==