highperfocused/bips
1
0
Fork 0
mirror of https://github.com/bitcoin/bips.git synced 2025-03-17 21:32:50 +01:00
Code Issues Packages Projects Releases Wiki Activity

Removed peer services specification.

Browse Source
This commit is contained in:
Eric Lombrozo 2015-12-23 09:57:37 -05:00
parent 181280bed7
commit 8fd3a42a95
1 changed files with 0 additions and 44 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

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

@ -34,50 +34,6 @@ By removing this data from the transaction structure committed to the transactio
#* Sum trees for transaction inputs and outputs can be committed making it possible to construct short proofs that no new coins are created in any noncoinbase transaction and that the miner does not add excessive fees to the coinbase transaction.
==Specification==
Maybe a seperate BIP
<pre>
* 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<CTxIn>, vector<CTxOut>,
vector<CTxInWitness>, int32 nLockTime) instead of (int32 nVersion,
vector<CTxIn>, vector<CTxOut>, 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).
</pre>
=== Commitment structure ===