diff options
| author | Matias Alejo Garcia <ematiu@gmail.com> | 2014-01-22 15:25:58 -0300 |
|---|---|---|
| committer | Matias Alejo Garcia <ematiu@gmail.com> | 2014-01-22 15:25:58 -0300 |
| commit | 806495e039114c7a8048250706633f3b20ca4107 (patch) | |
| tree | 3ec011033e11fcffaaafe30a759f5b096c549e76 /bip-0010.mediawiki | |
| parent | 9f223c1edc3534a2a596decea6af2d7bad4f1ff8 (diff) | |
| download | bips-806495e039114c7a8048250706633f3b20ca4107.tar.xz | |
fix typo
Diffstat (limited to 'bip-0010.mediawiki')
| -rw-r--r-- | bip-0010.mediawiki | 2 |
1 files changed, 1 insertions, 1 deletions
diff --git a/bip-0010.mediawiki b/bip-0010.mediawiki index ac4f4a4..76712f5 100644 --- a/bip-0010.mediawiki +++ b/bip-0010.mediawiki @@ -26,7 +26,7 @@ This BIP proposes the following process, with terms in quotes referring to recom # The user creating the TxDP (the preparer) will create the transaction as they would like to see it spent, but with blank TxIn scripts (where the signatures scripts will eventually go). # The proposed transaction will be spending a set of unspent TxOuts available in the blockchain. The full transactions containing these TxOuts will be serialized and included, as well. This so that the values of the TxIns can be verified before signing (the prev-tx-hash is part of the data being signed, but the value is not). By including the full tx, the signing party can verify that the tx matches the OutPoint hash, and then verify input values, all without any access to the blockchain. # The TxDP will have an "DP ID" or "Unsigned ID" which is the hash of the proposed transaction with blanked scripts, in Base58. This is a specific naming convention to make sure it is not confused with the actual the transaction ID that it will have after it is broadcast (the transaction ID cannot be determined until after all signatures are collected). The final Tx ID can be referred to as its "Broadcast ID", in order to distinguish it from the pre-signed ID. -# The TxDP will have an potentially-unordered list of sig-pubkey pairs which represent collected signatures. If you receive a TxDP missing only your signature, you can broadcast it as soon as you sign it. +# The TxDP will have a potentially-unordered list of sig-pubkey pairs which represent collected signatures. If you receive a TxDP missing only your signature, you can broadcast it as soon as you sign it. # Identical TxDP objects with different signatures can be easily combined. This allows one party to send out all the requests for signatures at once, and combine them all when they are received (instead of having to "pass it around". # For cases where the TxDP might be put into a file or sent via email, it should use .txdp or .btcdp suffix |