mirror of
https://github.com/bitcoin/bips.git
synced 2025-02-23 15:20:50 +01:00
Updated BIP 0010 after implementing it in Armory
This commit is contained in:
parent
3ef31386b7
commit
6ac9304b6c
1 changed files with 28 additions and 18 deletions
46
bip-0010.md
46
bip-0010.md
|
@ -32,17 +32,24 @@ This BIP proposes the following process, with terms in quotes referring to recom
|
|||
7. For cases where the TxDP might be put into a file to be sent via email, it should use .txdp or .btcdp suffix
|
||||
|
||||
|
||||
Anyone adopting BIP 0010 for multi-sig transactions will use the following format:
|
||||
Anyone adopting BIP 0010 for multi-sig transactions will use the following format (without indentation):
|
||||
|
||||
'-----BEGIN-TRANSACTION-TXDPID-------'
|
||||
("_TXDIST_") (magicBytes) (base58Txid) (varIntTxSize)
|
||||
(preparedTxSerializedHex)
|
||||
("_TX_SIGS_") (#sigsIncludedVarInt)
|
||||
("_SIG_") (BTCAddress8char) (Sig0InputIndex) (varIntScriptSz)
|
||||
(SigPubKeyPairHex)
|
||||
("_SIG_") (BTCAddress8char) (Sig1InputIndex) (varIntScriptSz)
|
||||
(SigPubKeyPairHex)
|
||||
("_SIG_") (BTCAddress8char) (Sig2InputIndex) (varIntScriptSz)
|
||||
(SigPubKeyPairHex)
|
||||
(preparedTxSerializedHexLine0)
|
||||
(preparedTxSerializedHexLine1)
|
||||
(preparedTxSerializedHexLine2)
|
||||
...
|
||||
("_TXINPUT_") (00) (InputValue)
|
||||
("_SIG_") (AddrBase58) (SigBytes) (SigHexPart0)
|
||||
(SigHexRemainingLines)
|
||||
("_SIG_") (AddrBase58) (SigBytes) (SigHexPart0)
|
||||
(SigHexRemainingLines)
|
||||
("_TXINPUT_") (01) (InputValue)
|
||||
("_SIG_") (AddrBase58) (SigBytes) (SigHexPart0)
|
||||
(SigHexRemainingLines)
|
||||
("_TXINPUT_") (02) (InputValue)
|
||||
'-------END-TRANSACTION-TXDPID-------'
|
||||
|
||||
A multi-signature proposal that has 3 signatures on it could be stored in a file "Tx_QrtZ3K42n.txdp" and it would look something like:
|
||||
|
||||
|
@ -56,19 +63,22 @@ A multi-signature proposal that has 3 signatures on it could be stored in a file
|
|||
4f931e8365e15a089c68d6190000000000982051fd1e4ba744bbbe680e1fee14
|
||||
677ba1a3c3540bf7b1cdb606e857233e0e61bc6649ffff001d01e36299010100
|
||||
fe328f9a3920119cbd3f1311f830039832abb3baf284625151f328f9a3920
|
||||
_TXSIGS_03
|
||||
_SIG_1Gffm3Kj3_02_7e
|
||||
fa8d9127149200f568383a089c68d619000000000098205bbbe680e1fee14677
|
||||
44bbbe680e1fee14677ba1a3c3540bf7b1cdb606e857233e0e61bc6649
|
||||
_SIG_1Mr983F2s_00_7e
|
||||
99271840918f81ab18c1144bbbe680e1fee14677ba1a3c3fa8d9127149200f56
|
||||
8383a089c68d619000000000098205bbbe680e1fee146774bbbe680e1f
|
||||
_SIG_1QRTt83p8_00_7f
|
||||
_TXINPUT_00_23.13000000
|
||||
_SIG_1Gffm3Kj3_02_7e_fa8d9127149200f568383a089c68d61900000000009
|
||||
8205bbbe680e1fee1467744bbbe680e1fee14677ba1a3c3540bf7b1cdb606e85
|
||||
7233e0e61bc6649
|
||||
_TXINPUT_01_4.00000000
|
||||
_TXINPUT_02_10.00000000
|
||||
_SIG_1QRTt83p8_007f ffff00db606e857233e0e61bc6649ffff00db60831f9
|
||||
6efa8d9127149200f568383a089c68d619000000000098205bbbe680e1fee1
|
||||
46770e1fee14677ba1a3c35
|
||||
_SIG_1m3Rk38fd_007f
|
||||
ffff00db606e857233e0e61bc6649ffff00db606efa8d9127149200f568383a0
|
||||
89c68d619000000000098205bbbe680e1fee146770e1fee14677ba1a3c35
|
||||
------END-TXDP------
|
||||
|
||||
In this transaction, there are 3 signatures already included, two for input 0, and one for input 2 (implying that that input 0 requires at least two signatures, and input 2 requires at least 1 -- the necessary number of signatures can be inferred from the TxOut scripts included in the TXDIST body). Bear in mind, most multi-signature TxDPs will only have a single input requiring multiple signatures. But there's no reason for this specification to be restricted to that case.
|
||||
In this transaction, there are 3 inputs, providing 23.13, 4.0 and 10.0 BTC, respectively. Input 0 has one signature, input 1 has zero signatures, and input 2 has two signatures.
|
||||
In this transaction, there are 3 signatures already included, two for input 0, and one for input 2 (implying that that input 0 requires at least two signatures, and input 2 requires at least 1. Bear in mind, most multi-signature TxDPs will only have a single input requiring multiple signatures. But there's no reason for this specification to be restricted to that case.
|
||||
|
||||
The style of communication is taken directly from PGP/GPG, which typically uses blocks of ASCII like this to communicate encrypted messages and signatures. This serialization is compact, and will be interpretted the same in all character encodings. It can be copied inline into an email, or saved in a text file. The advantage over the analogous PGP encoding is that there are some human readable elements to it, for users that wish to examine the TxDP packet more closely.
|
||||
|
||||
|
|
Loading…
Add table
Reference in a new issue