mirrors/bitcoin-bips
1
0
Fork 0
mirror of https://github.com/bitcoin/bips.git synced 2025-01-18 21:35:13 +01:00
Code Issues Projects Releases Wiki Activity

Bulletted rationales and other minor changes.

Browse Source
This commit is contained in:
Eric Lombrozo 2015-12-25 19:41:39 -05:00
parent 0ab3b3eb0c
commit 1f538fd458
1 changed files with 9 additions and 21 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

30
bip-codeshark-segwit-peer-services.mediawiki
View File

@ -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