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

Updated formatting

Browse Source
This commit is contained in:
etotheipi 2011-12-31 16:38:41 -05:00
parent b83fd76df5
commit e89a0b4c4b
1 changed files with 9 additions and 9 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

18
bip-0010.md
View File

@ -26,7 +26,7 @@ The enabling of multi-signature transactions in Bitcoin will introduce a great d
This BIP proposes the following process, with terms in quotes referring to recommended terminology that should be encouraged across all implementations.
# One party will initiate this process by creating a "Distribution Proposal", which could be abbreviated DP, or TxDP
# Transaction preparation -- the user creating the TxDP will create the transaction as they would like to see it spent (obviously without the signatures). Then they will go through each input and replace its script with the script of the txout that the input is spending. The reason for is so that '''receiving parties can sign with their private key without needing access to the blockchain.'''
# Transaction preparation -- the user creating the TxDP will create the transaction as they would like to see it spent (obviously without the signatures). Then they will go through each input and replace its script with the script of the txout that the input is spending. The reason for is so that ''receiving parties can sign with their private key without needing access to the blockchain.''
# This TxDP will be serialized (see below), which will include a tag identifying the TxDP in the serialization, as well as in the filename, if it is saved to file.
# The TxDP will have an "DP ID" which is the hash of the TxDP in Base58 -- the reason for the specific naming convention is 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 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.
@ -87,19 +87,19 @@ A party receiving this TxDP can simply add their signature to the appropriate _T
=== Reference Implementation ===
This proposal has been implemented and tested in the ''Armory'' Bitcoin software for use in offline-wallet transaction signing, and is prepared to be used for supporting multi-signature transactions in a future release. As such, the ''Armory'' source code contains a working implementation of BIP 0010 for single-party transactions (for offline wallets), and the logic is implemented (but untested) for multi-signature transactions.
The source code can be found at: https://github.com/etotheipi/BitcoinArmory/blob/qtdev/armoryengine.py with the PyTxDistProposal class starting at line 4520. A few direct links:
This proposal has been implemented and tested in the ''Armory'' Bitcoin software for use in offline-wallet transaction signing (as a 1-of-1 transaction). Armory does not have Multi-signature transaction support yet, but all the code is implemented, just untested. The source code for this implementation be found in the [https://github.com/etotheipi/BitcoinArmory/blob/qtdev/armoryengine.py Armory Github project]. The PyTxDistProposal class implements all features of BIP 0010:
'''TxDP from list of unspent TxOuts:''' https://github.com/etotheipi/BitcoinArmory/blob/qtdev/armoryengine.py#L4616
[https://github.com/etotheipi/BitcoinArmory/blob/qtdev/armoryengine.py#L4616 Create TxDP from list of unspent TxOuts]
'''Serialization of TxDP:''' https://github.com/etotheipi/BitcoinArmory/blob/qtdev/armoryengine.py#L4840
[https://github.com/etotheipi/BitcoinArmory/blob/qtdev/armoryengine.py#L4840 Serialization of TxDP]
'''Unserialize a TxDP:''' https://github.com/etotheipi/BitcoinArmory/blob/qtdev/armoryengine.py#L4879
[https://github.com/etotheipi/BitcoinArmory/blob/qtdev/armoryengine.py#L4879 Unserialize a TxDP]
'''Finished TxDP to broadcast-Tx:''' https://github.com/etotheipi/BitcoinArmory/blob/qtdev/armoryengine.py#L4795
[https://github.com/etotheipi/BitcoinArmory/blob/qtdev/armoryengine.py#L4795 Convert Completed TxDP to Broadcast-Tx]
===Known Issues===
One of the reasons TxDPs are versatile, is the ability for a device to "understand" and sign a transaction '''without''' access to the blockchain. However, this means that any information included in the TxDP that is not part of the final broadcast transaction (such as input values), cannot be verified by the device. i.e. I can create a TxDP and lie about the values of each input, to mislead the dumb client into thinking that less money is coming from its own funds than actually are (unless the client has the blockchain and/or has been tracking each transaction). This works, because the input values are not included in the final transaction, only the output values are actually signed by the device. This is not a show-stopper issue for BIP 0010, as developers who are concerned about such "attacks" can choose to ignore such fields, or always receive TxDPs through a computer that does have access to the blockchain and can verify the non-signature-related information in it.
One of the reasons TxDPs are versatile, is the ability for a device to "understand" and sign a transaction '''without''' access to the blockchain. However, this means that any information included in the TxDP that is not part of the final broadcast transaction (such as input values), cannot be verified by the device. i.e. Someone could create a TxDP and lie about the values of each input, knowing that the signing device will not be able to verify those values. Since the final, serialized transaction does not include input values, the subsequent signature will be valid no matter what inputs values were provided.
This is only a minor issue, since developers who are concerned about such "attacks" can choose to ignore non-signed fields in the TxDP. Or, they can guarantee that all TxDPs will pass through a trusted system that ''does'' have access to the blockchain and can verify such information.