Bitcoin Wiki - User contributions [en]

Deterministic wallet

2013-05-15T20:03:43Z

Etotheipi: Updating details on the Electrum and Armory wallets

A deterministic wallet is a wallet where private and public keys are all derived from a starting seed value. This could be a long passcode/password, or be a random series of letters and numbers.

== Benefits ==

A typical wallet creates private and public keys on demand for the user. This means that the wallet needs to be backed up frequently, otherwise coins may be lost. Also, having multiple machines with wallets on them means it is difficult to manage all of your coins together.

A deterministic wallet can be backed up by simply copying the starting seed value to a secure location, and this only needs to be done once. If the wallet ever gets lost, all private and public keys can be regenerated from the initial seed.

Also, multiple devices could host the same wallet based off of the same seed and automatically stay in sync with eachother. Non-critical information such as address books would need to be stored and copied between wallets.

==Drawbacks==

If the initial seed value was either guessed or taken, the attacker could take all of the coins from the wallet. Also, they could retain that seed value, and wait until some future date to take all of the coins.

==Passwords vs Random Strings==

The passcode/password has the benefit of being memorizable by the user, but at the expense of being either forgotten, or weak enough that the password could be guessed or brute forced. If a user used a password such as abc123, and an attacker might simply go through a list of common passwords, create wallets for them, and see if the public addresses match anything currently in the blockchain.

A long string of letters and numbers would be a way to prevent a brute force attack. This has the drawback of having to be actually stored somewhere. If this code was ever lost, the wallet would be lost forever.

==Types of deterministic wallet in use==
Each implementer of deterministic wallets should make sure that this article leads to a publicly available reference describing how to reconstitute the deterministic wallet from its seed.

===Type 1 deterministic wallet===
A Type 1 deterministic wallet is created from a string. Simply take SHA256(string + n), where n is an ASCII-coded number that starts from 1 and increments as additional keys are needed. This simple type of wallet can be created by Casascius Bitcoin Address Utility.

===Type 2 deterministic wallet===
Not sure on the details, but mention was made of a "type-2 deterministic wallet" in [[BIP 0032]] and credited to Gregory Maxwell, so this is a placeholder to describe that implementation. The relevant form topic is [https://bitcointalk.org/index.php?topic=19137.0 here].

===BIP 0032 deterministic wallet===
Described in [[BIP 0032]] (currently a draft) and described as a ''hierarchical deterministic'' (HD) wallet, a BIP 0032 deterministic wallet allows sharing smaller deterministic wallets that are subportions of a larger one.

===Electrum deterministic wallet===
[[Electrum]] implements a Type-2 deterministic wallet format based on a 128-bit seed. It uses a word list and converts the seed to a series of words as an aid to help the user record the seed.

===Armory deterministic wallet===
[[Armory]] has its own Type-2 deterministic wallet format based on a "root key" and a "chain code." The Armory client has a "Paper Backup" screen that allows the user to print these data or copy it down by hand. Earlier versions of Armory required backing up both the "root key" and "chaincode," while newer versions start deriving the chaincode from the private key in a non-reversible way. These newer Armory wallets (0.89+) only require the single, 256-bit root key.

File:Bitcoin OpCheckSig InDetail.png

2013-01-13T03:52:07Z

Etotheipi: Etotheipi uploaded a new version of "File:Bitcoin OpCheckSig InDetail.png"

== Summary ==
A full breakdown of the process to verify the Bitcoin ECDSA signature of a pair of transactions.
Sadly, there are '''2 decisive errors''' in the picture: In step 7: "empty string" is "byte 0" and in step 8: the Subscript copied into TxIn script must be lead-in by its length coded as a var-int.

== Licensing ==
{{self|Cc-zero}}

File:Bitcoin OpCheckSig InDetail.png

2013-01-13T03:44:27Z

Etotheipi: Etotheipi uploaded a new version of "File:Bitcoin OpCheckSig InDetail.png"

Hardfork Wishlist

2012-12-09T16:39:14Z

Etotheipi:

This page is to record changes to Bitcoin that might be desirable, but that will require a "hard" block-chain split (everybody must upgrade, old software will not accept blocks/transactions created with the new [[Protocol rules|rules]], considering them to be [[Invalid block|invalid blocks]]).

This page is *not* for changes that can be accomplished in way that is compatible with old software (for example, by making transactions [[Nonstandard block|nonstandard]] or by [[Discouraged block|discouraging blocks]]).

====Changes to hard-coded limits====
* Replace hard-coded maximum block size (1,000,000 bytes) and maximum number of signature operations per block (20,000) with ???.

====Major structural changes====
* "Flip the chain", instead of committing to new transactions, commit to the summaries of open transactions: [https://bitcointalk.org/index.php?topic=505.0] [https://bitcointalk.org/index.php?topic=21995.0] [https://en.bitcoin.it/wiki/User:DiThi/MTUT#PROPOSAL:_Merkle_tree_of_unspent_transactions_.28MTUT.29.2C_for_serverless_thin_clients_and_self-verifiable_prunned_blockchain.] [https://bitcointalk.org/index.php?topic=88208.0]
* Increased efficiency for merged mining: restructure the primary header to make the bitcoin specific data non-mandatory. (e.g. the block chain specific stuff would go into second header connected by a header tree), making the primary headers pure timestamps and nonces.
* Switch to block hashing algorithm secure against block withholding attacks.

====Transaction behavior changes====
* Improved signature types to allow for partial malleability of outputs. (e.g. make it easier to add a fee onto someone elses transaction, or to take fees from a transaction without outputs set aside for that putpose)
* Elimination of output scripts: all transactions pay-to-scripthash, probably with a single byte indicating the scripthash type. Other than reducing effective output script secrecy (which is not possible without OP_EVAL anyways) this is believed to be costless, and the secrecy can be recovered with recursive OP_EVAL. The motivation here is that data in outputs is far more expensive than inputs because some outputs may be never prunable, and pay-to-scripthash minimizes output size without harming total size.
* Allow soft-spending of generation outputs without confirmations (outputs of these transactions might also appear as generation themselves)
* Allow additional inputs to generation transactions
* Add new signature hashtype to include value of TxOut being spent, in the hash to be signed. Doing this would remove the requirement that offline signing devices be sent all supporting transactions with the transaction-to-be-signed, just to confirm the transaction fee.

====Cryptographic changes====
* Pervasive ECC public key-recovery to reduce transaction sizes (can be done partially without breaking compatibility completely)
* [http://ed25519.cr.yp.to/ Ed25519] (variant*) for much faster validation operations. (variant because the normal way Ed25519 is specified is not key recovery compatible)
* Support for a post-quantum signature scheme. [http://en.wikipedia.org/wiki/Lamport_signature Lamport signatures] have nice intuitive security properties, but it and all other similar schemes have extreme space requirements that would require structural changes to the blockchain to accommodate, (e.g. flip-chain+paytoscripthash+extensive pruning). Additional signature types could be kludged into the existing system with script extensions but would be better supported natively.

====Currency changes====
''Please don't list anything here which would significantly change the committed overall economics of the system, it's safe to assume anything with significant economic impact will _never_ be changed in Bitcoin<ref>[http://bitcointalk.org/index.php?topic=45468.msg542375#msg542375 Suggested MAJOR change to Bitcoin]</ref>, because such changes would undermine the trust people have in the system, though they may form the basis of an interesting [[alternative chain]].
* Increase currency divisibility.

====Navel gazing / Protocol housekeeping====
* Byte order consistency (big endian)
* Eliminate redundancies in the variable length integer encodings, possibly switch to a standard.
* Avoiding hashes covering malleable fields

====Bug fixes====
* CHECKMULTISIG popping one-too-many items off the stack
* Difficulty adjustment periods should overlap (prevent potential 'timejacking')
* Difficulty adjustment should adapt to sudden hashrate loss. Note: all altchains which have attempted this have created significant security vulnerabilities in the process. Also interested parties could encourage mining by including high fee transactions in every block so avoiding need for this change.
* Scripts should be fully enabled after a careful audit.
* Miners/relays should not be able to inject extra arbitrary data into transactions?
* Use the previous block hash as an explicit or implicit prev_in in coinbases when hashing them to make it ~impossible to get a duplicate coinbase, thus removing the need for a pruning node to remember coinbase hashes to prevent duplicates consistently with the rest of the network
* coinbases must be parseable.
This changes would involve converting old blocks:
* uint64_t for timestamp field in blocks.

==References==
<references />

[[Category:Technical]]
[[Category:Developer]]

BIP 0010

2012-01-31T01:25:58Z

Etotheipi:

<pre>
BIP: 10
Title: Multi-Sig Transaction Distribution
Author: Alan Reiner
Status: Draft
Type: Informational
Created: 28-10-2011
</pre>

A multi-signature transaction is one where a certain number of Bitcoins are "encumbered" with more than one recipient address. The subsequent transaction that spends these coins will require each party involved (or some subset, depending on the script), to see the proposed transaction and sign it with their private key. This necessarily requires collaboration between all parties -- to propose a distribution of encumbered funds, collect signatures from all necessary participants, and then broadcast the completed transaction.

This BIP describes a way standardize the encoding of proposal transactions, to assist with signature collection and broadcast (which includes regular, 1-of-1 transactions requiring signatures from an offline computer). The goal is to encourage a standard that guarantees interoperability of all programs that implement it.

==Motivation==

The enabling of multi-signature transactions in Bitcoin will introduce a great deal of extra functionality to the users of the network, but also a great deal of extra complexity. Executing a multi-signature tx will be a multi-step process, and will potentially get worse with multiple clients, each implementing this process differently. By providing an efficient, standardized technique, we can improve the chance that developers will adopt compatible protocols and not bifurcate the user-base based on client selection.

In addition to providing a general encoding scheme for transaction signing/collection, it does not require the signing device to hold any blockchain information (all information needed for verification and signing is part of the encoding). This enables the existence of very lightweight devices that can be used for signing since they do not need the blockchain -- only a minimal set of Bitcoin tools and an ECDSA module. Therefore, BIP 0010 has benefit beyond just multi-signature transactions.

==Specification==

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
# 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.
# 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

Anyone adopting BIP 0010 for multi-sig transactions will use the following format (without indentation):

'-----BEGIN-TRANSACTION-TXDPID-------'
("_TXDIST_") (magicBytes) (base58Txid) (varIntTxSize)
(serializedTxListInHex_Line1)
(serializedTxListInHex_Line2)
(serializedTxListInHex_Line3)
...
("_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-------'

The following is an example TxDP from Armory, produced while running on the test network. Its DPID is 3fX59xPj:

-----BEGIN-TRANSACTION-3fX59xPj-------------------------------------------------
_TXDIST_fabfb5da_3fX59xPj_00a0
010000000292807c8e70a28c687daea2998d6273d074e56fa8a55a0b10556974cf2b526e61000000
0000ffffffffe3c1ee0711611b01af3dee55b1484f0d6b65d17dce4eff0e6e06242e6cf457e10000
000000ffffffff02b0feea0b000000001976a91457996661391fa4e95bed27d7e8fe47f47cb8e428
88ac00a0acb9030000001976a914dc504e07b1107110f601fb679dd3f56cee9ff71e88ac00000000
0100000001eb626e4f73d88f415a8e8cb32b8d73eed47aa1039d0ed2f013abdc741ce6828c010000
008c493046022100b0da540e4924518f8989a9da798ca2d9e761b69a173b8cc41a3e3e3c6d77cd50
022100ecfa61730e58005338420516744ef680428dcfc05022dec70a851365c8575b190141042dc5
be3afa5887aee4a377032ed014361b0b9b61eb3ea6b8a8821bfe13ee4b65cd25d9630e4f227a53e8
bf637f85452c9981bcbd64ef77e22ce97b0f547c783effffffff0200d6117e030000001976a914cf
f580fd243f64f0ad7bf69faf41c0bf42d86d8988ac00205fa0120000001976a9148d573ef6984fd9
f8847d420001f7ac49b222a24988ac000000000100000001f2782db40ae147398a31cff9c7cc3423
014a073a92e463741244330cc304168f000000008c493046022100c9311b9eef0cc69219cb96838f
dd621530a80c46269a00dccc66498bc03ccf7a0221003742ee652a0a76fd28ad81aa73bb7f7a0a6a
81850af58f62d9a184d10e5eec30014104f815e8ef4cad584e04974889d7636e8933803d2e72991d
b5288c9e953c2465533905f98b7b688898c7c1f0708f2e49f0dd0abc06859ffed5144e8a1018a4e8
63ffffffff02008c8647000000001976a914d4e211215967f8e3744693bf85f47eb4ee9567fc88ac
603d4e95010000001976a914e9a6b50901c1969d2b0fd43a3ccfa3fef3291efe88ac00000000
_TXINPUT_00_150.00000000
_SIG_mzUYGfqGpyXmppYpmWJ31Y4zTxR4ZCod22_00_008c
4930460221007699967c3ec09d072599558d2e7082fae0820206b63aa66afea124634ed11a080221
0003346f7e963e645ecae2855026dc7332eb7237012539b34cd441c3cef97fbd4d01410497d5e1a0
0e1db90e893d1f2e547e2ee83b5d6bf4ddaa3d514e6dc2d94b6bcb5a72be1fcec766b8c382502caa
9ec09fe478bad07d3f38ff47b2eb42e681c384cc
_TXINPUT_01_12.00000000
_SIG_mzvaN8JUhHLz3Gdec1zBRxs5rNaYLQnbD1_01_008c
49304602210081554f8b08a1ad8caa69e34f4794d54952dac7c5efcf2afe080985d6bd5b00770221
00dea20ca3dbae1d15ec61bec57b4b8062e7d7c47614aba032c5a32f651f471cfd014104c30936d2
456298a566aa76fefeab8a7cb7a91e8a936a11757c911b4c669f0434d12ab0936fc13986b156156f
9b389ed244bbb580112be07dbe23949a4764dffb
-------END-TRANSACTION-3fX59xPj-------------------------------------------------

In this transaction, there are two inputs, one of 150 BTC and the other of 12 BTC. This transaction combines 162 BTC to create two outputs, one of 160 BTC, one 1.9995 BTC, and a tx fee of 0.0005. In this TxDP, both inputs have been signed, and thus could broadcast immediately.

The style of communication is taken directly from PGP/GPG, which 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 manually, instead of requiring a program to parse the core elements of the TxDP.

A party receiving this TxDP can simply add their signature to the appropriate _TXINPUT_ line. If that is the last signature required, they can broadcast it themselves. Any software that implements this standard should be able to combine multiple TxDPs into a single TxDP. However, even without the programmatic support, a user could manually combine them by copying the appropriate _TXSIGS_ lines between serializations, though it is not the recommended method for combining TxDPs.

== Reference Implementation ==

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), and will eventually use it for multi-signature transcations. The source code for this implementation be found in the [https://github.com/etotheipi/BitcoinArmory/blob/qtdev/armoryengine.py Armory Github project]. Specifically, the [https://github.com/etotheipi/BitcoinArmory/blob/qtdev/armoryengine.py#L4704 PyTxDistProposal class] implements all features of BIP 0010. It contains reference code for both
[https://github.com/etotheipi/BitcoinArmory/blob/qtdev/armoryengine.py#L5095 serializing a TxDP] and [https://github.com/etotheipi/BitcoinArmory/blob/qtdev/armoryengine.py#L5143 unserializing a TxDP].

[[Category:BIP|D]]

BIP 0010

2012-01-31T01:23:25Z

Etotheipi:

BIP 0010

2011-12-31T21:40:31Z

Etotheipi:

<pre>
BIP: 10
Title: Multi-Sig Transaction Distribution
Author: Alan Reiner
Status: Draft
Type: Informational
Created: 28-10-2011
</pre>

A multi-signature transaction is one where a certain number of Bitcoins are "encumbered" with more than one recipient address. The subsequent transaction that spends these coins will require each party involved (or some subset, depending on the script), to see the final, proposed transaction, and sign it with their private key. This necessarily requires collaboration between all parties -- to propose a distribution of encumbered funds, collect signatures from all necessary participants, and then broadcast the completed transaction.

This BIP describes a protocol to standardize the representation of proposal transactions and the subsequent collection of signatures to execute multi-signature transactions. The goal is to encourage a standard that guarantees interoperability of all programs that implement it.

==Motivation==

The enabling of multi-signature transactions in Bitcoin will introduce a great deal of extra functionality to the users of the network, but also a great deal of extra complexity. Executing a multi-signature tx will be a multi-step process, and will potentially get worse with multiple clients, each implementing this process differently. By providing an efficient, standardized technique, we can improve the chance that developers will adopt compatible protocols and not bifurcate the user-base based on client selection.

==Specification==

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.''
# 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.
# Identical TxDP objects with different signatures can be easily combined
# 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 (without indentation):

'-----BEGIN-TRANSACTION-TXDPID-------'
("_TXDIST_") (magicBytes) (base58Txid) (varIntTxSize)
(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:

'''-----BEGIN-TXDP-----'''
'''_TXDIST_f9beb4d9_QrtZ3K42n_fda5'''
204368616e63656c6c6f72206f6e206272696e6b206f66207365636f6e642062
61696c6f757420666f722062616e6b73ffffffff0100f2052a01000000434104
678afdb0fe5548271967f1a67130b7105cd6a828e03909a67962e0ea1f61deb6
49f6bc3f4cef38c4f35504e51ec112de5c384df7ba0b8d578a4c702b6bf11d5f
ac00000000f9beb4d9d7000000010000006fe28c0ab6f1b372c1a6a246ae63f7
4f931e8365e15a089c68d6190000000000982051fd1e4ba744bbbe680e1fee14
677ba1a3c3540bf7b1cdb606e857233e0e61bc6649ffff001d01e36299010100
fe328f9a3920119cbd3f1311f830039832abb3baf284625151f328f9a3920
'''_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 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.

The style of communication is taken directly from PGP/GPG, which 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 manually, instead of requiring a program/parser to simply determine the core elements of the TxDP.

A party receiving this TxDP can simply add their signature to the appropriate _TXINPUT_ line. If that is the last signature required, they can broadcast it themselves. Any software that implements this standard should be able to combine multiple TxDPs into a single TxDP. However, even without the programmatic support, a user could manually combine them by copying the appropriate _TXSIGS_ lines between serializations, though it should not be the recommended method for combining TxDPs.

== Reference Implementation ==

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:

[https://github.com/etotheipi/BitcoinArmory/blob/qtdev/armoryengine.py#L4616 Create TxDP from list of unspent TxOuts]

[https://github.com/etotheipi/BitcoinArmory/blob/qtdev/armoryengine.py#L4840 Serialization of TxDP]

[https://github.com/etotheipi/BitcoinArmory/blob/qtdev/armoryengine.py#L4879 Unserialize a TxDP]

[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. 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.

BIP 0010

2011-12-30T23:21:29Z

Etotheipi:

===BIP 0010 - Proposal for Standardized, Multi-Signature Transaction Execution===

<pre>
BIP: 10
Title: Distribution Proposals for Multi-Sig Transactions
Author: Alan Reiner
Status: Draft
Type: Standards Track
Created: 2011-10-28
</pre>

===Abstract===

A multi-signature transaction is one where a certain number of Bitcoins are "encumbered" with more than one recipient address. The subsequent transaction that spends these coins will require each party involved (or some subset, depending on the script), to see the final, proposed transaction, and sign it with their private key. This necessarily requires collaboration between all parties -- to propose a distribution of encumbered funds, collect signatures from all necessary participants, and then broadcast the completed transaction.

This BIP describes a protocol to standardize the representation of proposal transactions and the subsequent collection of signatures to execute multi-signature transactions. The goal is to encourage a standard that guarantees interoperability of all programs that implement it.

===Motivation===

The enabling of multi-signature transactions in Bitcoin will introduce a great deal of extra functionality to the users of the network, but also a great deal of extra complexity. Executing a multi-signature tx will be a multi-step process, and will potentially get worse with multiple clients, each implementing this process differently. By providing an efficient, standardized technique, we can improve the chance that developers will adopt compatible protocols and not bifurcate the user-base based on client selection.

===Specification===

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.'''
# 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.
# Identical TxDP objects with different signatures can be easily combined
# 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 (without indentation):

'-----BEGIN-TRANSACTION-TXDPID-------'
("_TXDIST_") (magicBytes) (base58Txid) (varIntTxSize)
(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:

'''-----BEGIN-TXDP-----'''
'''_TXDIST_f9beb4d9_QrtZ3K42n_fda5'''
204368616e63656c6c6f72206f6e206272696e6b206f66207365636f6e642062
61696c6f757420666f722062616e6b73ffffffff0100f2052a01000000434104
678afdb0fe5548271967f1a67130b7105cd6a828e03909a67962e0ea1f61deb6
49f6bc3f4cef38c4f35504e51ec112de5c384df7ba0b8d578a4c702b6bf11d5f
ac00000000f9beb4d9d7000000010000006fe28c0ab6f1b372c1a6a246ae63f7
4f931e8365e15a089c68d6190000000000982051fd1e4ba744bbbe680e1fee14
677ba1a3c3540bf7b1cdb606e857233e0e61bc6649ffff001d01e36299010100
fe328f9a3920119cbd3f1311f830039832abb3baf284625151f328f9a3920
'''_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 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.

The style of communication is taken directly from PGP/GPG, which 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 manually, instead of requiring a program/parser to simply determine the core elements of the TxDP.

A party receiving this TxDP can simply add their signature to the appropriate _TXINPUT_ line. If that is the last signature required, they can broadcast it themselves. Any software that implements this standard should be able to combine multiple TxDPs into a single TxDP. However, even without the programmatic support, a user could manually combine them by copying the appropriate _TXSIGS_ lines between serializations, though it should not be the recommended method for combining TxDPs.

=== 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 (as a 1-of-1 transaction), 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:

'''TxDP from list of unspent TxOuts:''' https://github.com/etotheipi/BitcoinArmory/blob/qtdev/armoryengine.py#L4616

'''Serialization of TxDP:''' https://github.com/etotheipi/BitcoinArmory/blob/qtdev/armoryengine.py#L4840

'''Unserialize a TxDP:''' https://github.com/etotheipi/BitcoinArmory/blob/qtdev/armoryengine.py#L4879

'''Finished TxDP to broadcast-Tx:''' https://github.com/etotheipi/BitcoinArmory/blob/qtdev/armoryengine.py#L4795

===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.

BIP 0010

2011-12-30T23:16:28Z

Etotheipi:

===BIP 0010 - Proposal for Standardized, Multi-Signature Transaction Execution===

<pre>
BIP: 10
Author: Alan Reiner
Status: Draft Proposal
Orig Date: 28 Oct, 2011
Contact: etotheipi@gmail.com
Updated: 20 Dec, 2011
</pre>

===Abstract===

A multi-signature transaction is one where a certain number of Bitcoins are "encumbered" with more than one recipient address. The subsequent transaction that spends these coins will require each party involved (or some subset, depending on the script), to see the final, proposed transaction, and sign it with their private key. This necessarily requires collaboration between all parties -- to propose a distribution of encumbered funds, collect signatures from all necessary participants, and then broadcast the completed transaction.

This BIP describes a protocol to standardize the representation of proposal transactions and the subsequent collection of signatures to execute multi-signature transactions. The goal is to encourage a standard that guarantees interoperability of all programs that implement it.

===Motivation===

The enabling of multi-signature transactions in Bitcoin will introduce a great deal of extra functionality to the users of the network, but also a great deal of extra complexity. Executing a multi-signature tx will be a multi-step process, and will potentially get worse with multiple clients, each implementing this process differently. By providing an efficient, standardized technique, we can improve the chance that developers will adopt compatible protocols and not bifurcate the user-base based on client selection.

===Specification===

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.'''
# 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.
# Identical TxDP objects with different signatures can be easily combined
# 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 (without indentation):

'-----BEGIN-TRANSACTION-TXDPID-------'
("_TXDIST_") (magicBytes) (base58Txid) (varIntTxSize)
(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:

'''-----BEGIN-TXDP-----'''
'''_TXDIST_f9beb4d9_QrtZ3K42n_fda5'''
204368616e63656c6c6f72206f6e206272696e6b206f66207365636f6e642062
61696c6f757420666f722062616e6b73ffffffff0100f2052a01000000434104
678afdb0fe5548271967f1a67130b7105cd6a828e03909a67962e0ea1f61deb6
49f6bc3f4cef38c4f35504e51ec112de5c384df7ba0b8d578a4c702b6bf11d5f
ac00000000f9beb4d9d7000000010000006fe28c0ab6f1b372c1a6a246ae63f7
4f931e8365e15a089c68d6190000000000982051fd1e4ba744bbbe680e1fee14
677ba1a3c3540bf7b1cdb606e857233e0e61bc6649ffff001d01e36299010100
fe328f9a3920119cbd3f1311f830039832abb3baf284625151f328f9a3920
'''_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 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.

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 manually, instead of requiring a program/parser to simply determine the core elements of the TxDP.

A party receiving this TxDP can simply add their signature to the appropriate _TXINPUT_ line. If that is the last signature required, they can broadcast it themselves. Any software that implements this standard should be able to combine multiple TxDPs into a single TxDP. However, even without the programmatic support, a user could manually combine them by copying the appropriate _TXSIGS_ lines between serializations, though it should not be the recommended method for combining TxDPs.

=== 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:

'''TxDP from list of unspent TxOuts:''' https://github.com/etotheipi/BitcoinArmory/blob/qtdev/armoryengine.py#L4616

'''Serialization of TxDP:''' https://github.com/etotheipi/BitcoinArmory/blob/qtdev/armoryengine.py#L4840

'''Unserialize a TxDP:''' https://github.com/etotheipi/BitcoinArmory/blob/qtdev/armoryengine.py#L4879

'''Finished TxDP to broadcast-Tx:''' https://github.com/etotheipi/BitcoinArmory/blob/qtdev/armoryengine.py#L4795

===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.

BIP 0010

2011-12-22T13:50:04Z

Etotheipi:

BIP 0010

2011-12-22T13:31:52Z

Etotheipi:

===BIP 0010 - Proposal for Standardized, Multi-Signature Transaction Execution===

<pre>
BIP: 10
Author: Alan Reiner
Status: Draft Proposal
Orig Date: 28 Oct, 2011
Contact: etotheipi@gmail.com
Updated: 20 Dec, 2011
</pre>

===Abstract===

A multi-signature transaction is one where a certain number of Bitcoins are "encumbered" with more than one recipient address. The subsequent transaction that spends these coins will require each party involved (or some subset, depending on the script), to see the final, proposed transaction, and sign it with their private key. This necessarily requires collaboration between all parties -- to propose a distribution of encumbered funds, collect signatures from all necessary participants, and then broadcast the completed transaction.

This BIP describes a protocol to standardize the representation of proposal transactions and the subsequent collection of signatures to execute multi-signature transactions. The goal is to encourage a standard that guarantees interoperability of all programs that implement it.

===Motivation===

The enabling of multi-signature transactions in Bitcoin will introduce a great deal of extra functionality to the users of the network, but also a great deal of extra complexity. Executing a multi-signature tx will be a multi-step process, and will potentially get worse with multiple clients, each implementing this process differently. By providing an efficient, standardized technique, we can improve the chance that developers will adopt compatible protocols and not bifurcate the user-base based on client selection.

===Specification===

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.
# 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 this 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.
# Identical TxDP objects with different signatures can be easily combined
# 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 (without indentation):

'-----BEGIN-TRANSACTION-TXDPID-------'
("_TXDIST_") (magicBytes) (base58Txid) (varIntTxSize)
(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:

'''-----BEGIN-TXDP-----'''
'''_TXDIST_f9beb4d9_QrtZ3K42n_fda5'''
204368616e63656c6c6f72206f6e206272696e6b206f66207365636f6e642062
61696c6f757420666f722062616e6b73ffffffff0100f2052a01000000434104
678afdb0fe5548271967f1a67130b7105cd6a828e03909a67962e0ea1f61deb6
49f6bc3f4cef38c4f35504e51ec112de5c384df7ba0b8d578a4c702b6bf11d5f
ac00000000f9beb4d9d7000000010000006fe28c0ab6f1b372c1a6a246ae63f7
4f931e8365e15a089c68d6190000000000982051fd1e4ba744bbbe680e1fee14
677ba1a3c3540bf7b1cdb606e857233e0e61bc6649ffff001d01e36299010100
fe328f9a3920119cbd3f1311f830039832abb3baf284625151f328f9a3920
'''_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 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 is 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.

A party receiving this TxDP can simply add their signature to the end of the list, and incremenet the 0003 to 0004 on the _TXSIGS_ line. If that is the last signature required, they can broadcast it themselves. Any software that implements this standard should be able to combine multiple TxDPs into a single TxDP. However, even without the programmatic support, a user could manually combine them by copying the appropriate _TXSIGS_ lines between serializations, though it should not be the recommended method for combining TxDPs.

===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.

===Reference implementation===

The following python pseudo-code provides an example of how this serialization can be performed, and how to sign it

# Requires the multi-sig tx to be spent, and a list of recipients and values
def createTxDistProposal(multiSigTxOut, RecipientList, ValueList):

# Do some sanity checks on the input data
assert(len(RecipientList) === len(ValueList))

totalDist = sum(valueList)
txFee = multiSigTxOut.value - totalDist
assert(txFee < 0)
if(txFee < minRecFee)
warn('Tx fee (%f) is lower than recommended (%f)' % (txFee,minRecFee))

# Create empty tx
txdp = PyTx()
txdp.version = 1
txdp.lockTime = 0

# Create empty tx, create only one input
txdp = PyTx()
txdp.inputs = [ PyTxOut() ]
txdp.inputs[0].prevTxOutHash = multiSigTxOut.parentHash
txdp.inputs[0].prevTxOutIndex = multiSigTxOut.parentIndex
txdp.inputs[0].binaryScript = multiSigTxOut.script
txdp.inputs[0].sequence = 0xffffffff

# Create standard outputs
txdp.outputs = []
for addr,val in zip(RecipientList, ValueList):
newTxOut = createStdTxOut(addr, val)
txdp.outputs.append(newTxOut)

# Serialize the transaction and create a DPID
txdpBinary = txdp.serialize()
txdpSize = len(txdpBinary)
dpidHash = sha256(sha256(txdpBinary))
dpidID = binary_to_base58(dpidHash)[:8]

# Start creating the ASCII message
txdpStr = '-----BEGIN-TXDP-----'
txdpStr += '_TXDIST_%s_%s_%s' % (magicBytes, dpidID, txdpSize) + '\n'
txdpHex = binary_to_hex(txdpBinary)
for byte in range(0,txdpSize,80):
txdpStr += txdpHex[byte:byte+80] + '\n'
txdpStr = '_TXSIGS_00' + '\n'
txdpStr = '-----END-TXDP-----'

return txdpStr

Then a TxDP can be signed by

# To sign a txDP, we zero out all the inputs that aren't ours, add hashcode, then sign
def signTxDistProposal(txdpStr, inputToSign, myAddr):

txdpLines = txdpStr.split('\n')
readDp = False
txHex = ''
output = ''

# We copy the TxDP exactly as we read it, except for the TXSIGS line that
# will require incremeting. We stop just before the END-TXDP line so we
# can append our signature to the end of the TXSIGS list
for line in txdpLines:
if 'END-TXDP' in line:
break

if readDp:
txHex += line.strip()

# Read TXDP, starting next line
if line.startswith('_TXDIST_'):
readDp = True

# Copy the line exactly as it's read, unless it's TXSIGS line
if line.startswith('_TXSIGS_'):
readDp = False
nSigs = readVarInt(line.split('_')[-1].strip())
output += '_TXSIGS_' + writeVarIntHex(nSigs+1) + '\n'
else:
output += line

# All inputs have the appropriate TxOut script already included
# For signing (SIGHASH_ALL) we need to blank out the ones not being signed
txToSign = PyTx().unserialize(hex_to_binary(txHex))
for i in range(len(txToSign.inputs)):
if not i===inputToSign:
txToSign[i] = ''

SIGHASH_ALL = 1
hashcode = int_to_binary(SIGHASH_ALL, widthBytes=4, endOut=LITTLEENDIAN)
binaryToSign = sha256(sha256(txToSign.serialize() + hashcode))
binaryToSign = switchEndian(binaryToSign) # hash needs to be BigEndian
sig = myAddr.privKey.generateDERSignature(binaryToSign)

txinScript = createStdTxInScript(sig, myAddr.pubKey)
txinScriptHex = binary_to_hex(txinScript)
inputNum = binary_to_hex(writeVarInt(inputToSign))
scriptSz = binary_to_hex(writeVarInt(len(txinScript))
output += '_SIG_%s_%s_%s\n' % (myAddr.base58str()[:8], inputNum, scriptSz)
for byte in range(0,len(txinScriptHex), 80):
output += txinScriptHex[byte:byte+80] + '\n'
output += '-----END-TXDP-----'
return output

BIP 0010

2011-12-21T02:39:15Z

Etotheipi: Created page with "===BIP 0010 - Proposal for Standardized, Multi-Signature Transaction Execution=== <pre> BIP: 10 Author: Alan Reiner Status: Draft Proposal Orig Date: ..."

===BIP 0010 - Proposal for Standardized, Multi-Signature Transaction Execution===

<pre>
BIP: 10
Author: Alan Reiner
Status: Draft Proposal
Orig Date: 28 Oct, 2011
Contact: etotheipi@gmail.com
Updated: 20 Dec, 2011
</pre>

===Abstract===

A multi-signature transaction is one where a certain number of Bitcoins are "encumbered" with more than one recipient address. The subsequent transaction that spends these coins will require each party involved (or some subset, depending on the script), to see the final, proposed transaction, and sign it with their private key. This necessarily requires collaboration between all parties -- to propose a distribution of encumbered funds, collect signatures from all necessary participants, and then broadcast the completed transaction.

This BIP describes a protocol to standardize the representation of proposal transactions and the subsequent collection of signatures to execute multi-signature transactions. The goal is to encourage a standard that guarantees interoperability of all programs that implement it.

===Motivation===

The enabling of multi-signature transactions in Bitcoin will introduce a great deal of extra functionality to the users of the network, but also a great deal of extra complexity. Executing a multi-signature tx will be a multi-step process, and will potentially get worse with multiple clients, each implementing this process differently. By providing an efficient, standardized technique, we can improve the chance that developers will adopt compatible protocols and not bifurcate the user-base based on client selection.

===Specification===

This BIP proposes the following process, with terms in quotes referring to recommended terminology that should be encouraged across all implementations.

# 1. One party will initiate this process by creating a "Distribution Proposal", which could be abbreviated DP, or TxDP
# 2. 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.
# 3. 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.
# 4. The TxDP will have an "DP ID" which is the hash of the TxDP in Base58 -- the reason for this 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.
# 5. 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.
# 6. Identical TxDP objects with different signatures can be easily combined
# 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 (without indentation):

'-----BEGIN-TRANSACTION-TXDPID-------'
("_TXDIST_") (magicBytes) (base58Txid) (varIntTxSize)
(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:

'''-----BEGIN-TXDP-----'''
'''_TXDIST_f9beb4d9_QrtZ3K42n_fda5'''
204368616e63656c6c6f72206f6e206272696e6b206f66207365636f6e642062
61696c6f757420666f722062616e6b73ffffffff0100f2052a01000000434104
678afdb0fe5548271967f1a67130b7105cd6a828e03909a67962e0ea1f61deb6
49f6bc3f4cef38c4f35504e51ec112de5c384df7ba0b8d578a4c702b6bf11d5f
ac00000000f9beb4d9d7000000010000006fe28c0ab6f1b372c1a6a246ae63f7
4f931e8365e15a089c68d6190000000000982051fd1e4ba744bbbe680e1fee14
677ba1a3c3540bf7b1cdb606e857233e0e61bc6649ffff001d01e36299010100
fe328f9a3920119cbd3f1311f830039832abb3baf284625151f328f9a3920
'''_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 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 is 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.

A party receiving this TxDP can simply add their signature to the end of the list, and incremenet the 0003 to 0004 on the _TXSIGS_ line. If that is the last signature required, they can broadcast it themselves. Any software that implements this standard should be able to combine multiple TxDPs into a single TxDP. However, even without the programmatic support, a user could manually combine them by copying the appropriate _TXSIGS_ lines between serializations, though it should not be the recommended method for combining TxDPs.

===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.

===Reference implementation===

The following python pseudo-code provides an example of how this serialization can be performed, and how to sign it

# Requires the multi-sig tx to be spent, and a list of recipients and values
def createTxDistProposal(multiSigTxOut, RecipientList, ValueList):

# Do some sanity checks on the input data
assert(len(RecipientList) === len(ValueList))

totalDist = sum(valueList)
txFee = multiSigTxOut.value - totalDist
assert(txFee < 0)
if(txFee < minRecFee)
warn('Tx fee (%f) is lower than recommended (%f)' % (txFee,minRecFee))

# Create empty tx
txdp = PyTx()
txdp.version = 1
txdp.lockTime = 0

# Create empty tx, create only one input
txdp = PyTx()
txdp.inputs = [ PyTxOut() ]
txdp.inputs[0].prevTxOutHash = multiSigTxOut.parentHash
txdp.inputs[0].prevTxOutIndex = multiSigTxOut.parentIndex
txdp.inputs[0].binaryScript = multiSigTxOut.script
txdp.inputs[0].sequence = 0xffffffff

# Create standard outputs
txdp.outputs = []
for addr,val in zip(RecipientList, ValueList):
newTxOut = createStdTxOut(addr, val)
txdp.outputs.append(newTxOut)

# Serialize the transaction and create a DPID
txdpBinary = txdp.serialize()
txdpSize = len(txdpBinary)
dpidHash = sha256(sha256(txdpBinary))
dpidID = binary_to_base58(dpidHash)[:8]

# Start creating the ASCII message
txdpStr = '-----BEGIN-TXDP-----'
txdpStr += '_TXDIST_%s_%s_%s' % (magicBytes, dpidID, txdpSize) + '\n'
txdpHex = binary_to_hex(txdpBinary)
for byte in range(0,txdpSize,80):
txdpStr += txdpHex[byte:byte+80] + '\n'
txdpStr = '_TXSIGS_00' + '\n'
txdpStr = '-----END-TXDP-----'

return txdpStr

Then a TxDP can be signed by

# To sign a txDP, we zero out all the inputs that aren't ours, add hashcode, then sign
def signTxDistProposal(txdpStr, inputToSign, myAddr):

txdpLines = txdpStr.split('\n')
readDp = False
txHex = ''
output = ''

# We copy the TxDP exactly as we read it, except for the TXSIGS line that
# will require incremeting. We stop just before the END-TXDP line so we
# can append our signature to the end of the TXSIGS list
for line in txdpLines:
if 'END-TXDP' in line:
break

if readDp:
txHex += line.strip()

# Read TXDP, starting next line
if line.startswith('_TXDIST_'):
readDp = True

# Copy the line exactly as it's read, unless it's TXSIGS line
if line.startswith('_TXSIGS_'):
readDp = False
nSigs = readVarInt(line.split('_')[-1].strip())
output += '_TXSIGS_' + writeVarIntHex(nSigs+1) + '\n'
else:
output += line

# All inputs have the appropriate TxOut script already included
# For signing (SIGHASH_ALL) we need to blank out the ones not being signed
txToSign = PyTx().unserialize(hex_to_binary(txHex))
for i in range(len(txToSign.inputs)):
if not i===inputToSign:
txToSign[i] = ''

SIGHASH_ALL = 1
hashcode = int_to_binary(SIGHASH_ALL, widthBytes=4, endOut=LITTLEENDIAN)
binaryToSign = sha256(sha256(txToSign.serialize() + hashcode))
binaryToSign = switchEndian(binaryToSign) # hash needs to be BigEndian
sig = myAddr.privKey.generateDERSignature(binaryToSign)

txinScript = createStdTxInScript(sig, myAddr.pubKey)
txinScriptHex = binary_to_hex(txinScript)
inputNum = binary_to_hex(writeVarInt(inputToSign))
scriptSz = binary_to_hex(writeVarInt(len(txinScript))
output += '_SIG_%s_%s_%s\n' % (myAddr.base58str()[:8], inputNum, scriptSz)
for byte in range(0,len(txinScriptHex), 80):
output += txinScriptHex[byte:byte+80] + '\n'
output += '-----END-TXDP-----'
return output

File:TxBinaryMap.png

2011-08-23T02:52:17Z

Etotheipi: uploaded a new version of "File:TxBinaryMap.png": Byte-map of a transaction with one of each type of TxIn and TxOut

== Summary ==
Byte-map of a transaction with each type of TxIn and TxOut serialization.
== Licensing ==
{{self|Cc-zero}}

File:TxBinaryMap.png

2011-08-23T02:50:46Z

Etotheipi: uploaded a new version of "File:TxBinaryMap.png": Byte-map of Transaction with each type of TxIn and TxOut

== Summary ==
Byte-map of a transaction with each type of TxIn and TxOut serialization.
== Licensing ==
{{self|Cc-zero}}

File:TxBinaryMap.png

2011-08-23T02:37:46Z

Etotheipi: uploaded a new version of "File:TxBinaryMap.png": Byte-map of a transaction with one of each type of TxIn and TxOut

== Summary ==
Byte-map of a transaction with each type of TxIn and TxOut serialization.
== Licensing ==
{{self|Cc-zero}}

File:TxBinaryMap.png

2011-08-23T02:35:29Z

Etotheipi: uploaded a new version of "File:TxBinaryMap.png": Byte-map of a transaction with one of each type of TxIn and TxOut

== Summary ==
Byte-map of a transaction with each type of TxIn and TxOut serialization.
== Licensing ==
{{self|Cc-zero}}

File:TxBinaryMap.png

2011-08-23T01:45:01Z

Etotheipi: uploaded a new version of "File:TxBinaryMap.png": Byte-map of a transaction with one of each type of TxIn and TxOut

== Summary ==
Byte-map of a transaction with each type of TxIn and TxOut serialization.
== Licensing ==
{{self|Cc-zero}}

Transaction

2011-08-23T01:28:52Z

Etotheipi:

[[File:TxBinaryMap.png|thumb|right|Byte-map of Transaction with each type of TxIn and TxOut]]
A transaction is a signed section of data that is broadcast to the [[network]] and collected into [[block|blocks]]. They reference a previous transaction and dedicate a certain number of bitcoins from it to a new public key (Bitcoin address). They are not encrypted (nothing in Bitcoin is encrypted).

A [[block chain browser]] is a site where every transaction included within the block chain can be viewed. This is useful for seeing the technical details of transaction in action, and for payment verification purposes.

=== Example Bitcoin Transaction ===

==== Data ====

<pre>Input:
Previous tx: f5d8ee39a430901c91a5917b9f2dc19d6d1a0e9cea205b009ca73dd04470b9a6
Index: 0
scriptSig: 304502206e21798a42fae0e854281abd38bacd1aeed3ee3738d9e1446618c4571d10
90db022100e2ac980643b0b82c0e88ffdfec6b64e3e6ba35e7ba5fdd7d5d6cc8d25c6b241501

Output:
Value: 5000000000
scriptPubKey: OP_DUP OP_HASH160 404371705fa9bd789a2fcd52d2c580b65d35549d
OP_EQUALVERIFY OP_CHECKSIG</pre>

==== Explanation ====

The input in this transaction imports 50 BTC from output #0 in transaction f5d8... Then the output sends 50 BTC to a Bitcoin address (expressed here in hexadecimal 4043... instead of the normal base58). When the recipient wants to spend this money, he will reference output #0 of this transaction in an input of his own transaction.

===== Input =====

An '''input''' is a reference to an output in a different transaction. Multiple inputs are often listed in a transaction. The values of the referenced outputs are added up, and the total is usable in the outputs of this transaction. '''Previous tx''' is a [[hash]] of a previous transaction. '''Index''' is the specific output in the referenced transaction. '''ScriptSig''' is the first half of a [[script]] (discussed in more detail later).

The script contains two components, a signature and a public key. The public key belongs to the redeemer of the output transaction and proves the creator is allowed to redeem the outputs value. The other component is an ECDSA signature over a hash of a simplified version of the transaction. It, combined with the public key, proves the transaction was created by the real owner of the address in question. Various flags define how the transaction is simplified and can be used to create different types of payment.

===== Output =====

An '''output''' contains instructions for sending bitcoins. '''Value''' is the number of Satoshi (1 BTC = 100,000,000 Satoshi) that this output will be worth when claimed. '''ScriptPubKey''' is the second half of a script (discussed later). There can be more than one output, and they share the combined value of the inputs. Because an output can only ever be referenced by a single input, the entire combined input value needs to be sent in an output if you don't want to lose it. If the input is worth 50 BTC but you only want to send 25 BTC, Bitcoin will create two outputs worth 25 BTC: one to the destination, and one back to you (known as "change", though you send it to yourself). Any input bitcoins not redeemed in an output is considered a [[transaction fee]]; whoever generates the block will get it.
[[File:transaction.png|thumb|A sends 100 BTC to C and C generates 50 BTC. C sends 101 BTC to D, and he needs to send himself some change. D sends the 101 BTC to someone else, but they haven't redeemed it yet. Only D's output and C's change are capable of being spent in the current state.]]

===== Verification =====

To verify that inputs are authorized to collect the values of referenced outputs, Bitcoin uses a custom Forth-like [[script|scripting]] system. The input's scriptSig and the ''referenced'' output's scriptPubKey are evaluated (in that order), with scriptPubKey using the values left on the stack by scriptSig. The input is authorized if scriptPubKey returns true. Through the scripting system, the sender can create very complex conditions that people have to meet in order to claim the output's value. For example, it's possible to create an output that can be claimed by anyone without any authorization. It's also possible to require that an input be signed by ten different keys, or be redeemable with a password instead of a key.

=== Types of Transaction ===
Bitcoin currently only creates three different scriptSig/scriptPubKey pairs. These are described below.

It is possible to design more complex types of transactions, and link them together into cryptographically enforced agreements. These are known as [[Contracts]].

==== Transfer to IP address ====

scriptPubKey: <pubKey> OP_CHECKSIG
scriptSig: <sig>
The sender gets the public key when talking to the recipient over IP. When redeeming coins that have been sent to an IP address, the recipient provides only a signature. The signature is checked against the public key in scriptPubKey.

Checking process:
{| class="wikitable"
|-
! Stack
! Script
! Description
|-
|Empty.
|<sig> <pubKey> OP_CHECKSIG
|scriptSig and scriptPubKey are combined.
|-
|<sig> <pubKey>
| OP_CHECKSIG
|Constants are added to the stack.
|-
|true
|Empty.
|Signature is checked for top two stack items.
|}

==== Transfer to Bitcoin address ====

scriptPubKey: OP_DUP OP_HASH160 <pubKeyHash> OP_EQUALVERIFY OP_CHECKSIG
scriptSig: <sig> <pubKey>
A Bitcoin [[address]] is only a hash, so the sender can't provide a full public key in scriptPubKey. When redeeming coins that have been sent to a Bitcoin address, the recipient provides both the signature and the public key. The script verifies that the provided public key does hash to the hash in scriptPubKey, and then it also checks the signature against the public key.

Checking process:
{| class="wikitable"
|-
! Stack
! Script
! Description
|-
|Empty.
| <sig> <pubKey> OP_DUP OP_HASH160 <pubKeyHash> OP_EQUALVERIFY OP_CHECKSIG
| scriptSig and scriptPubKey are combined.
|-
|<sig> <pubKey>
| OP_DUP OP_HASH160 <pubKeyHash> OP_EQUALVERIFY OP_CHECKSIG
| Constants are added to the stack.
|-
|<sig> <pubKey> <pubKey>
| OP_HASH160 <pubKeyHash> OP_EQUALVERIFY OP_CHECKSIG
| Top stack item is duplicated.
|-
|<sig> <pubKey> <pubHashA>
|<pubKeyHash> OP_EQUALVERIFY OP_CHECKSIG
| Top stack item is hashed.
|-
|<sig> <pubKey> <pubHashA> <pubKeyHash>
|OP_EQUALVERIFY OP_CHECKSIG
| Constant added.
|-
|<sig> <pubKey>
|OP_CHECKSIG
| Equality is checked between the top two stack items.
|-
|true
|Empty.
|Signature is checked for top two stack items.
|}

==== Generation ====

Generations have a single input, and this input has a "coinbase" parameter instead of a scriptSig. The data in "coinbase" can be anything; it isn't used. Bitcoin puts the current compact-format [[target]] and the arbitrary-precision "extraNonce" number there, which increments every time the Nonce field in the [[block_hashing_algorithm|block header]] overflows. Outputs can be anything, but Bitcoin creates one exactly like an IP address transaction.

[[Category:Technical]]
[[Category:Vocabulary]]
[[de:Transaktion]]
[[pl:Transakcje]]

File:TxBinaryMap.png

2011-08-23T01:26:43Z

Etotheipi: Byte-map of a transaction with each type of TxIn and TxOut serialization.

== Summary ==
Byte-map of a transaction with each type of TxIn and TxOut serialization.
== Licensing ==
{{self|Cc-zero}}

File:PubKeyToAddr.png

2011-08-21T02:02:06Z

Etotheipi: uploaded a new version of "File:PubKeyToAddr.png": Conversion from ECDSA public key to Bitcoin address

== Summary ==
Conversion from ECDSA public key to Bitcoin address.
== Licensing ==
{{self|Cc-zero}}

File:PubKeyToAddr.png

2011-08-21T02:00:51Z

Etotheipi: uploaded a new version of "File:PubKeyToAddr.png": Constructing a Bitcoin address from an ECDSA public key

== Summary ==
Conversion from ECDSA public key to Bitcoin address.
== Licensing ==
{{self|Cc-zero}}

Invoice address

2011-08-21T01:56:24Z

Etotheipi: Added illustration of how the BTC address is created from a public key

[[File:PubKeyToAddr.png|thumb|right|Conversion from ECDSA public key to Bitcoin Address]]
A '''Bitcoin Address''' is a 160-bit hash of the public portion of a public/private [[Wikipedia:Elliptic_Curve_DSA|ECDSA]] keypair. Using some mathemagic, you can "sign" data with your private key and anyone who knows your public key can verify that the signature is valid. See the [[Wikipedia:Public-key_cryptography|Wikipedia article]] for more information about how this works. See [[Protocol_specification#Addresses|protocol specification]] for details on how a bitcoin address is formed.

A new keypair is generated for each receiving address. Bitcoin addresses (the public keys) and their associated private keys are stored in the [[wallet]] data file. This is the only file you need to [[backup|back up]]. A "send" transaction to a specific Bitcoin address requires that the corresponding private key exist in the recipient's wallet. This has the implication that if you create a receiving address and receive coins to that address, then restore the wallet from an earlier backup, before the address was generated, then the coins associated with that address are lost. Addresses are added to an address [[key pool]] prior to being used for receiving coins. If you lose your wallet entirely, all of your coins are lost and can never be recovered.

"Generate" transactions happen in the same way as a send transaction: each batch of 50 generated coins is "sent" to a unique address that you generate just for that purpose. These addresses are also stored in your wallet, but they are not shown in the "your receiving addresses" section.

Bitcoin allows you to create as many addresses as you want, and each one is completely separate. There is no "master address": the "Your Bitcoin address" area in the Bitcoin UI has no special importance. It's only there for your convenience, and it will change automatically from time to time to enhance your anonymity. All of your other addresses will continue to work forever. They're listed in the "your receiving addresses" section. Each address takes up only about 500 bytes, so having a large number of addresses in your wallet is generally not a problem.

Bitcoin addresses contain a built-in check code, so it's generally not possible to send Bitcoins to a mistyped address. However, if the address is well-formed but no one owns it (or the owner lost their wallet.dat), any coins sent to that address will be lost forever.

Addresses can contain all alphanumeric characters except 0, O, I, and l. Normal addresses currently always start with 1, though this might change in a future version. Testnet addresses usually start with ''m'' or ''n''. Mainline addresses can be 25-34 characters in length, and testnet addresses can be 26-34 characters in length. Most addresses are 33 or 34 characters long, though.

It is also possible to send Bitcoins directly to an [[IP address]].

Since Bitcoin addresses are basically random numbers, it is possible, although extremely unlikely, for two people to independently generate the same address. This is called a [[Wikipedia:Collision_(computer_science)|collision]]. If this happens, then both the original owner of the address and the colliding owner could spend money sent to that address. It would not be possible for the colliding person to spend the original owner's entire wallet (or vice versa). If you were to intentionally try to make a collision, it would currently take 2^126 times longer to generate a colliding Bitcoin address than to generate a block. As long as the signing and hashing algorithms remain cryptographically strong, it will likely always be more profitable to collect generations and [[transaction fee|transaction fees]] than to try to create collisions.

[[Category:Technical]]
[[Category:Vocabulary]]

OP CHECKSIG

2011-08-21T01:54:33Z

Etotheipi:

OP_CHECKSIG is [[Script|script]] opcode used to verify that the signature for a tx input is valid. OP_CHECKSIG expects two values to be on the stack, these are, in order of stack depth, the public key and the signature of the script. These two values are normally obtained by running the scriptSig script of the transaction input we are attempting to validate. After the scriptSig script is run the script is deleted but the stack is left as is, and then then scriptPubKey script from the previous transaction output that is now being spent is run, generally concluding in an OP_CHECKSIG.

The standard scriptPubKey checks that the public key (actually a hash of) is a particular value, and that OP_CHECKSIG passes.

For normal transaction inputs if the creator of the current transaction can successfully create a ScriptSig signature that uses the right public key for the ScriptPubKey of the transaction output they are attempting to spend, that transaction input is considered valid.

== Parameters ==

In addition to the script code itself and the stack parameters, to operate OP_CHECKSIG needs to know the current transaction, the current transaction input, and the current hashtype (discussed later)

== How it works ==
[[File:Bitcoin_OpCheckSig_InDetail.png|thumb|right|Signature verification process using SIGHASH_ALL]]
# the public key and the signature are popped from the stack, in that order.
# A new subscript is created from the instruction from the most recently parsed OP_CODESEPARATOR (last one in script) to the end of the script. If there is no OP_CODESEPARATOR the entire script becomes the subscript (hereby referred to as subScript)
# The sig is deleted from subScript (it's not standard to have signature in the subScript).
# All OP_CODESEPARATORS are removed from subScript
# The hashtype is removed from the last byte of the sig and stored
# A deep copy is made of the current transaction (hereby referred to txCopy)
# The scripts for all transaction inputs in txCopy are set to empty scripts
# The script for the current transaction input in txCopy is set to subScript

Now depending on the hashtype various things can happen to txCopy, these will be discussed individually

'''Hashtype Values (from script.h):'''
{|class="wikitable"
! Name !! Value
|-
| SIGHASH_ALL || 0x00000001
|-
| SIGHASH_NONE || 0x00000002
|-
| SIGHASH_SINGLE || 0x00000003
|-
| SIGHASH_ANYONECANPAY || 0x00000080
|}

=== Hashtype SIGHASH_ALL (default) ===

No special handling occurs in the default case

=== Hashtype SIGHASH_NONE ===

# The output of txCopy is set to a vector of zero size.
# All other inputs aside from the current input in txCopy have their nSequence index set to zero

=== Hashtype SIGHASH_SINGLE ===

# The output of txCopy is resized to the size of the current input index+1
# All other txCopy outputs aside from the output that is the same as the current input index are set to a blank script and a value of (long) -1;
# All other txCopy inputs aside from the current input are set to have an nSequence index of zero

=== Hashtype SIGHASH_ANYONECANPAY ===

# The txCopy input vector is resized to a length of one
# The current input is set as the first and only member of this vector

== Final signature ==

An array of bytes is constructed from the serialized txCopy + four bytes for the hash type. This array is sha256 hashed twice, then the public key is used to to check the supplied signature against the hash.

== Return values ==

OP_CHECKSIG will push true to the stack if the check passed, false otherwise.
OP_CHECKSIG_VERIFY leaves nothing on the stack but will cause the script eval to fail immediately if the check does not pass.

== Code samples and raw dumps ==

Taking the first transaction in Bitcoin which is in block number 170, we would get after serialising the transaction but before we hash+sign (or verify) it:

* http://blockexplorer.com/block/00000000d1145790a8694403d4063f323d499e655c83426834d4ce2f8dd4a2ee
* http://blockexplorer.com/tx/f4184fc596403b9d638783cf57adfe4c75c605f6356fbc91338530e9831e9e16

See also [https://gitorious.org/libbitcoin/libbitcoin libbitcoin] for code samples.

<pre>
01 00 00 00 version
01 number of inputs (var_uint)

input 0:
c9 97 a5 e5 6e 10 41 02 input address hash
fa 20 9c 6a 85 2d d9 06
60 a2 0b 2d 9c 35 24 23
ed ce 25 85 7f cd 37 04
00 00 00 00 input index

43 size of script (var_uint)
41 push 65 bytes to stack
04 11 db 93 e1 dc db 8a
01 6b 49 84 0f 8c 53 bc
1e b6 8a 38 2e 97 b1 48
2e ca d7 b1 48 a6 90 9a
5c b2 e0 ea dd fb 84 cc
f9 74 44 64 f8 2e 16 0b
fa 9b 8b 64 f9 d4 c0 3f
99 9b 86 43 f6 56 b4 12
a3
ac OP_CHECKSIG
ff ff ff ff sequence

02 number of outputs (var_uint)

output 0:
00 ca 9a 3b 00 00 00 00 amount = 10.00000000
43 size of script (var_uint)
script for output 0:
41 push 65 bytes to stack
04 ae 1a 62 fe 09 c5 f5
1b 13 90 5f 07 f0 6b 99
a2 f7 15 9b 22 25 f3 74
cd 37 8d 71 30 2f a2 84
14 e7 aa b3 73 97 f5 54
a7 df 5f 14 2c 21 c1 b7
30 3b 8a 06 26 f1 ba de
d5 c7 2a 70 4f 7e 6c d8
4c
ac OP_CHECKSIG

output 1:
00 28 6b ee 00 00 00 00 amount = 40.00000000
43 size of script (var_uint)
script for output 1:
41 push 65 bytes to stack
04 11 db 93 e1 dc db 8a
01 6b 49 84 0f 8c 53 bc
1e b6 8a 38 2e 97 b1 48
2e ca d7 b1 48 a6 90 9a
5c b2 e0 ea dd fb 84 cc
f9 74 44 64 f8 2e 16 0b
fa 9b 8b 64 f9 d4 c0 3f
99 9b 86 43 f6 56 b4 12
a3
ac OP_CHECKSIG

00 00 00 00 locktime
01 00 00 00 hash_code_type (added on)

result =
01 00 00 00 01 c9 97 a5 e5 6e 10 41 02 fa 20 9c 6a 85 2d d9 06 60 a2 0b 2d 9c 35
24 23 ed ce 25 85 7f cd 37 04 00 00 00 00 43 41 04 11 db 93 e1 dc db 8a 01 6b 49
84 0f 8c 53 bc 1e b6 8a 38 2e 97 b1 48 2e ca d7 b1 48 a6 90 9a 5c b2 e0 ea dd fb
84 cc f9 74 44 64 f8 2e 16 0b fa 9b 8b 64 f9 d4 c0 3f 99 9b 86 43 f6 56 b4 12 a3
ac ff ff ff ff 02 00 ca 9a 3b 00 00 00 00 43 41 04 ae 1a 62 fe 09 c5 f5 1b 13 90
5f 07 f0 6b 99 a2 f7 15 9b 22 25 f3 74 cd 37 8d 71 30 2f a2 84 14 e7 aa b3 73 97
f5 54 a7 df 5f 14 2c 21 c1 b7 30 3b 8a 06 26 f1 ba de d5 c7 2a 70 4f 7e 6c d8 4c
ac 00 28 6b ee 00 00 00 00 43 41 04 11 db 93 e1 dc db 8a 01 6b 49 84 0f 8c 53 bc
1e b6 8a 38 2e 97 b1 48 2e ca d7 b1 48 a6 90 9a 5c b2 e0 ea dd fb 84 cc f9 74 44
64 f8 2e 16 0b fa 9b 8b 64 f9 d4 c0 3f 99 9b 86 43 f6 56 b4 12 a3 ac 00 00 00 00
01 00 00 00
</pre>

To understand where that raw dump has come from, it may be useful to examine tests/ec-key.cpp in [https://gitorious.org/libbitcoin/libbitcoin libbitcoin],

[https://gitorious.org/libbitcoin/libbitcoin libbitcoin] has a unit test under tests/ec-key.cpp (make ec-key && ./bin/tests/ec-key). There is also a working OP_CHECKSIG implementation in src/script.cpp under script::op_checksig(). See also the unit test: tests/script-test.cpp

<source lang="cpp">
#include <iostream>
#include <iomanip>
#include <bitcoin/util/serializer.hpp>
#include <bitcoin/util/elliptic_curve_key.hpp>
#include <bitcoin/util/sha256.hpp>
#include <bitcoin/util/assert.hpp>
#include <bitcoin/util/logger.hpp>
#include <bitcoin/types.hpp>
#include <openssl/ecdsa.h>
#include <openssl/obj_mac.h>
using libbitcoin::elliptic_curve_key;
using libbitcoin::serializer;
using libbitcoin::hash_digest;
using libbitcoin::data_chunk;
using libbitcoin::log_info;
using libbitcoin::log_fatal;

int main()
{
serializer ss;
// blk number 170, tx 1, input 0
// version = 1
ss.write_4_bytes(1);
// 1 inputs
ss.write_var_uint(1);

// input 0
// prevout hash
ss.write_hash(hash_digest{0x04, 0x37, 0xcd, 0x7f, 0x85, 0x25, 0xce, 0xed, 0x23, 0x24, 0x35, 0x9c, 0x2d, 0x0b, 0xa2, 0x60, 0x06, 0xd9, 0x2d, 0x85, 0x6a, 0x9c, 0x20, 0xfa, 0x02, 0x41, 0x10, 0x6e, 0xe5, 0xa5, 0x97, 0xc9});
// prevout index
ss.write_4_bytes(0);

// input script after running OP_CHECKSIG for this tx is a single
// OP_CHECKSIG opcode
data_chunk raw_data;
raw_data = {0x04, 0x11, 0xdb, 0x93, 0xe1, 0xdc, 0xdb, 0x8a, 0x01, 0x6b, 0x49, 0x84, 0x0f, 0x8c, 0x53, 0xbc, 0x1e, 0xb6, 0x8a, 0x38, 0x2e, 0x97, 0xb1, 0x48, 0x2e, 0xca, 0xd7, 0xb1, 0x48, 0xa6, 0x90, 0x9a, 0x5c, 0xb2, 0xe0, 0xea, 0xdd, 0xfb, 0x84, 0xcc, 0xf9, 0x74, 0x44, 0x64, 0xf8, 0x2e, 0x16, 0x0b, 0xfa, 0x9b, 0x8b, 0x64, 0xf9, 0xd4, 0xc0, 0x3f, 0x99, 0x9b, 0x86, 0x43, 0xf6, 0x56, 0xb4, 0x12, 0xa3};
data_chunk raw_script;
raw_script = data_chunk();
raw_script.push_back(raw_data.size());
libbitcoin::extend_data(raw_script, raw_data);
raw_script.push_back(172);
ss.write_var_uint(raw_script.size());
ss.write_data(raw_script);
// sequence
ss.write_4_bytes(0xffffffff);

// 2 outputs for this tx
ss.write_var_uint(2);

// output 0
ss.write_8_bytes(1000000000);
// script for output 0
raw_data = {0x04, 0xae, 0x1a, 0x62, 0xfe, 0x09, 0xc5, 0xf5, 0x1b, 0x13, 0x90, 0x5f, 0x07, 0xf0, 0x6b, 0x99, 0xa2, 0xf7, 0x15, 0x9b, 0x22, 0x25, 0xf3, 0x74, 0xcd, 0x37, 0x8d, 0x71, 0x30, 0x2f, 0xa2, 0x84, 0x14, 0xe7, 0xaa, 0xb3, 0x73, 0x97, 0xf5, 0x54, 0xa7, 0xdf, 0x5f, 0x14, 0x2c, 0x21, 0xc1, 0xb7, 0x30, 0x3b, 0x8a, 0x06, 0x26, 0xf1, 0xba, 0xde, 0xd5, 0xc7, 0x2a, 0x70, 0x4f, 0x7e, 0x6c, 0xd8, 0x4c};
// when data < 75, we can just write it's length as a single byte ('special'
// opcodes)
raw_script = data_chunk();
raw_script.push_back(raw_data.size());
libbitcoin::extend_data(raw_script, raw_data);
// OP_CHECKSIG
raw_script.push_back(172);
// now actually write the script
ss.write_var_uint(raw_script.size());
ss.write_data(raw_script);

// output 0
ss.write_8_bytes(4000000000);
// script for output 0
raw_data = {0x04, 0x11, 0xdb, 0x93, 0xe1, 0xdc, 0xdb, 0x8a, 0x01, 0x6b, 0x49, 0x84, 0x0f, 0x8c, 0x53, 0xbc, 0x1e, 0xb6, 0x8a, 0x38, 0x2e, 0x97, 0xb1, 0x48, 0x2e, 0xca, 0xd7, 0xb1, 0x48, 0xa6, 0x90, 0x9a, 0x5c, 0xb2, 0xe0, 0xea, 0xdd, 0xfb, 0x84, 0xcc, 0xf9, 0x74, 0x44, 0x64, 0xf8, 0x2e, 0x16, 0x0b, 0xfa, 0x9b, 0x8b, 0x64, 0xf9, 0xd4, 0xc0, 0x3f, 0x99, 0x9b, 0x86, 0x43, 0xf6, 0x56, 0xb4, 0x12, 0xa3};
// when data < 75, we can just write it's length as a single byte ('special'
raw_script.push_back(raw_data.size());
libbitcoin::extend_data(raw_script, raw_data);
// OP_CHECKSIG
raw_script.push_back(172);
// now actually write the script
ss.write_var_uint(raw_script.size());
ss.write_data(raw_script);

// End of 2 outputs

// locktime
ss.write_4_bytes(0);

// write hash_type_code
ss.write_4_bytes(1);

// Dump hex to screen
log_info() << "hashing:";
{
auto log_obj = log_info();
log_obj << std::hex;
for (int val: ss.get_data())
log_obj << std::setfill('0') << std::setw(2) << val << ' ';
}
log_info();

data_chunk raw_tx = {0x01, 0x00, 0x00, 0x00, 0x01, 0xc9, 0x97, 0xa5, 0xe5, 0x6e, 0x10, 0x41, 0x02, 0xfa, 0x20, 0x9c, 0x6a, 0x85, 0x2d, 0xd9, 0x06, 0x60, 0xa2, 0x0b, 0x2d, 0x9c, 0x35, 0x24, 0x23, 0xed, 0xce, 0x25, 0x85, 0x7f, 0xcd, 0x37, 0x04, 0x00, 0x00, 0x00, 0x00, 0x43, 0x41, 0x04, 0x11, 0xdb, 0x93, 0xe1, 0xdc, 0xdb, 0x8a, 0x01, 0x6b, 0x49, 0x84, 0x0f, 0x8c, 0x53, 0xbc, 0x1e, 0xb6, 0x8a, 0x38, 0x2e, 0x97, 0xb1, 0x48, 0x2e, 0xca, 0xd7, 0xb1, 0x48, 0xa6, 0x90, 0x9a, 0x5c, 0xb2, 0xe0, 0xea, 0xdd, 0xfb, 0x84, 0xcc, 0xf9, 0x74, 0x44, 0x64, 0xf8, 0x2e, 0x16, 0x0b, 0xfa, 0x9b, 0x8b, 0x64, 0xf9, 0xd4, 0xc0, 0x3f, 0x99, 0x9b, 0x86, 0x43, 0xf6, 0x56, 0xb4, 0x12, 0xa3, 0xac, 0xff, 0xff, 0xff, 0xff, 0x02, 0x00, 0xca, 0x9a, 0x3b, 0x00, 0x00, 0x00, 0x00, 0x43, 0x41, 0x04, 0xae, 0x1a, 0x62, 0xfe, 0x09, 0xc5, 0xf5, 0x1b, 0x13, 0x90, 0x5f, 0x07, 0xf0, 0x6b, 0x99, 0xa2, 0xf7, 0x15, 0x9b, 0x22, 0x25, 0xf3, 0x74, 0xcd, 0x37, 0x8d, 0x71, 0x30, 0x2f, 0xa2, 0x84, 0x14, 0xe7, 0xaa, 0xb3, 0x73, 0x97, 0xf5, 0x54, 0xa7, 0xdf, 0x5f, 0x14, 0x2c, 0x21, 0xc1, 0xb7, 0x30, 0x3b, 0x8a, 0x06, 0x26, 0xf1, 0xba, 0xde, 0xd5, 0xc7, 0x2a, 0x70, 0x4f, 0x7e, 0x6c, 0xd8, 0x4c, 0xac, 0x00, 0x28, 0x6b, 0xee, 0x00, 0x00, 0x00, 0x00, 0x43, 0x41, 0x04, 0x11, 0xdb, 0x93, 0xe1, 0xdc, 0xdb, 0x8a, 0x01, 0x6b, 0x49, 0x84, 0x0f, 0x8c, 0x53, 0xbc, 0x1e, 0xb6, 0x8a, 0x38, 0x2e, 0x97, 0xb1, 0x48, 0x2e, 0xca, 0xd7, 0xb1, 0x48, 0xa6, 0x90, 0x9a, 0x5c, 0xb2, 0xe0, 0xea, 0xdd, 0xfb, 0x84, 0xcc, 0xf9, 0x74, 0x44, 0x64, 0xf8, 0x2e, 0x16, 0x0b, 0xfa, 0x9b, 0x8b, 0x64, 0xf9, 0xd4, 0xc0, 0x3f, 0x99, 0x9b, 0x86, 0x43, 0xf6, 0x56, 0xb4, 0x12, 0xa3, 0xac, 0x00, 0x00, 0x00, 0x00, 0x01, 0x00, 0x00, 0x00};
BITCOIN_ASSERT(raw_tx == ss.get_data());

hash_digest tx_hash = libbitcoin::generate_sha256_hash(ss.get_data());

data_chunk pubkey{0x04, 0x11, 0xdb, 0x93, 0xe1, 0xdc, 0xdb, 0x8a, 0x01, 0x6b, 0x49, 0x84, 0x0f, 0x8c, 0x53, 0xbc, 0x1e, 0xb6, 0x8a, 0x38, 0x2e, 0x97, 0xb1, 0x48, 0x2e, 0xca, 0xd7, 0xb1, 0x48, 0xa6, 0x90, 0x9a, 0x5c, 0xb2, 0xe0, 0xea, 0xdd, 0xfb, 0x84, 0xcc, 0xf9, 0x74, 0x44, 0x64, 0xf8, 0x2e, 0x16, 0x0b, 0xfa, 0x9b, 0x8b, 0x64, 0xf9, 0xd4, 0xc0, 0x3f, 0x99, 0x9b, 0x86, 0x43, 0xf6, 0x56, 0xb4, 0x12, 0xa3};
// Leave out last byte since that's the hash_type_code (SIGHASH_ALL in this
// case)
data_chunk signature{0x30, 0x44, 0x02, 0x20, 0x4e, 0x45, 0xe1, 0x69, 0x32, 0xb8, 0xaf, 0x51, 0x49, 0x61, 0xa1, 0xd3, 0xa1, 0xa2, 0x5f, 0xdf, 0x3f, 0x4f, 0x77, 0x32, 0xe9, 0xd6, 0x24, 0xc6, 0xc6, 0x15, 0x48, 0xab, 0x5f, 0xb8, 0xcd, 0x41, 0x02, 0x20, 0x18, 0x15, 0x22, 0xec, 0x8e, 0xca, 0x07, 0xde, 0x48, 0x60, 0xa4, 0xac, 0xdd, 0x12, 0x90, 0x9d, 0x83, 0x1c, 0xc5, 0x6c, 0xbb, 0xac, 0x46, 0x22, 0x08, 0x22, 0x21, 0xa8, 0x76, 0x8d, 0x1d, 0x09};
BITCOIN_ASSERT(signature.size() == 70);

elliptic_curve_key key;
if (!key.set_public_key(pubkey))
{
log_fatal() << "unable to set EC public key";
return -1;
}

log_info() << "checksig returns: " << (key.verify(tx_hash, signature) ? "true" : "false");
return 0;
}

</source>

[[Category:Technical]]
[[Category:Developer]]

File:PubKeyToAddr.png

2011-08-21T01:52:48Z

Etotheipi: Conversion from ECDSA public key to Bitcoin address.

== Summary ==
Conversion from ECDSA public key to Bitcoin address.
== Licensing ==
{{self|Cc-zero}}

OP CHECKSIG

2011-08-14T13:22:22Z

Etotheipi: Adding my OP_CHECKSIG diagram to the page

OP_CHECKSIG is [[Script|script]] opcode used to verify that the signature for a tx input is valid. OP_CHECKSIG expects two values to be on the stack, these are, in order of stack depth, the public key and the signature of the script. These two values are normally obtained by running the scriptSig script of the transaction input we are attempting to validate. After the scriptSig script is run the script is deleted but the stack is left as is, and then then scriptPubKey script from the previous transaction output that is now being spent is run, generally concluding in an OP_CHECKSIG.

The standard scriptPubKey checks that the public key (actually a hash of) is a particular value, and that OP_CHECKSIG passes.

For normal transaction inputs if the creator of the current transaction can successfully create a ScriptSig signature that uses the right public key for the ScriptPubKey of the transaction output they are attempting to spend, that transaction input is considered valid.

== Parameters ==

In addition to the script code itself and the stack parameters, to operate OP_CHECKSIG needs to know the current transaction, the current transaction input, and the current hashtype (discussed later)

== How it works ==
[[File:Bitcoin_OpCheckSig_InDetail.png|thumb|right|Illustration of the signature verification process using SIGHASH_ALL]]
# the public key and the signature are popped from the stack, in that order.
# A new subscript is created from the instruction from the most recently parsed OP_CODESEPARATOR (last one in script) to the end of the script. If there is no OP_CODESEPARATOR the entire script becomes the subscript (hereby referred to as subScript)
# The sig is deleted from subScript (it's not standard to have signature in the subScript).
# All OP_CODESEPARATORS are removed from subScript
# The hashtype is removed from the last byte of the sig and stored
# A deep copy is made of the current transaction (hereby referred to txCopy)
# The scripts for all transaction inputs in txCopy are set to empty scripts
# The script for the current transaction input in txCopy is set to subScript

Now depending on the hashtype various things can happen to txCopy, these will be discussed individually

'''Hashtype Values (from script.h):'''
{|class="wikitable"
! Name !! Value
|-
| SIGHASH_ALL || 0x00000001
|-
| SIGHASH_NONE || 0x00000002
|-
| SIGHASH_SINGLE || 0x00000003
|-
| SIGHASH_ANYONECANPAY || 0x00000080
|}

=== Hashtype SIGHASH_ALL (default) ===

No special handling occurs in the default case

=== Hashtype SIGHASH_NONE ===

# The output of txCopy is set to a vector of zero size.
# All other inputs aside from the current input in txCopy have their nSequence index set to zero

=== Hashtype SIGHASH_SINGLE ===

# The output of txCopy is resized to the size of the current input index+1
# All other txCopy outputs aside from the output that is the same as the current input index are set to a blank script and a value of (long) -1;
# All other txCopy inputs aside from the current input are set to have an nSequence index of zero

=== Hashtype SIGHASH_ANYONECANPAY ===

# The txCopy input vector is resized to a length of one
# The current input is set as the first and only member of this vector

== Final signature ==

An array of bytes is constructed from the serialized txCopy + four bytes for the hash type. This array is sha256 hashed twice, then the public key is used to to check the supplied signature against the hash.

== Return values ==

OP_CHECKSIG will push true to the stack if the check passed, false otherwise.
OP_CHECKSIG_VERIFY leaves nothing on the stack but will cause the script eval to fail immediately if the check does not pass.

== Code samples and raw dumps ==

Taking the first transaction in Bitcoin which is in block number 170, we would get after serialising the transaction but before we hash+sign (or verify) it:

* http://blockexplorer.com/block/00000000d1145790a8694403d4063f323d499e655c83426834d4ce2f8dd4a2ee
* http://blockexplorer.com/tx/f4184fc596403b9d638783cf57adfe4c75c605f6356fbc91338530e9831e9e16

See also [https://gitorious.org/libbitcoin/libbitcoin libbitcoin] for code samples.

<pre>
01 00 00 00 version
01 number of inputs (var_uint)

input 0:
c9 97 a5 e5 6e 10 41 02 input address hash
fa 20 9c 6a 85 2d d9 06
60 a2 0b 2d 9c 35 24 23
ed ce 25 85 7f cd 37 04
00 00 00 00 input index

43 size of script (var_uint)
41 push 65 bytes to stack
04 11 db 93 e1 dc db 8a
01 6b 49 84 0f 8c 53 bc
1e b6 8a 38 2e 97 b1 48
2e ca d7 b1 48 a6 90 9a
5c b2 e0 ea dd fb 84 cc
f9 74 44 64 f8 2e 16 0b
fa 9b 8b 64 f9 d4 c0 3f
99 9b 86 43 f6 56 b4 12
a3
ac OP_CHECKSIG
ff ff ff ff sequence

02 number of outputs (var_uint)

output 0:
00 ca 9a 3b 00 00 00 00 amount = 10.00000000
43 size of script (var_uint)
script for output 0:
41 push 65 bytes to stack
04 ae 1a 62 fe 09 c5 f5
1b 13 90 5f 07 f0 6b 99
a2 f7 15 9b 22 25 f3 74
cd 37 8d 71 30 2f a2 84
14 e7 aa b3 73 97 f5 54
a7 df 5f 14 2c 21 c1 b7
30 3b 8a 06 26 f1 ba de
d5 c7 2a 70 4f 7e 6c d8
4c
ac OP_CHECKSIG

output 1:
00 28 6b ee 00 00 00 00 amount = 40.00000000
43 size of script (var_uint)
script for output 1:
41 push 65 bytes to stack
04 11 db 93 e1 dc db 8a
01 6b 49 84 0f 8c 53 bc
1e b6 8a 38 2e 97 b1 48
2e ca d7 b1 48 a6 90 9a
5c b2 e0 ea dd fb 84 cc
f9 74 44 64 f8 2e 16 0b
fa 9b 8b 64 f9 d4 c0 3f
99 9b 86 43 f6 56 b4 12
a3
ac OP_CHECKSIG

00 00 00 00 locktime
01 00 00 00 hash_code_type (added on)

result =
01 00 00 00 01 c9 97 a5 e5 6e 10 41 02 fa 20 9c 6a 85 2d d9 06 60 a2 0b 2d 9c 35
24 23 ed ce 25 85 7f cd 37 04 00 00 00 00 43 41 04 11 db 93 e1 dc db 8a 01 6b 49
84 0f 8c 53 bc 1e b6 8a 38 2e 97 b1 48 2e ca d7 b1 48 a6 90 9a 5c b2 e0 ea dd fb
84 cc f9 74 44 64 f8 2e 16 0b fa 9b 8b 64 f9 d4 c0 3f 99 9b 86 43 f6 56 b4 12 a3
ac ff ff ff ff 02 00 ca 9a 3b 00 00 00 00 43 41 04 ae 1a 62 fe 09 c5 f5 1b 13 90
5f 07 f0 6b 99 a2 f7 15 9b 22 25 f3 74 cd 37 8d 71 30 2f a2 84 14 e7 aa b3 73 97
f5 54 a7 df 5f 14 2c 21 c1 b7 30 3b 8a 06 26 f1 ba de d5 c7 2a 70 4f 7e 6c d8 4c
ac 00 28 6b ee 00 00 00 00 43 41 04 11 db 93 e1 dc db 8a 01 6b 49 84 0f 8c 53 bc
1e b6 8a 38 2e 97 b1 48 2e ca d7 b1 48 a6 90 9a 5c b2 e0 ea dd fb 84 cc f9 74 44
64 f8 2e 16 0b fa 9b 8b 64 f9 d4 c0 3f 99 9b 86 43 f6 56 b4 12 a3 ac 00 00 00 00
01 00 00 00
</pre>

To understand where that raw dump has come from, it may be useful to examine tests/ec-key.cpp in [https://gitorious.org/libbitcoin/libbitcoin libbitcoin],

[https://gitorious.org/libbitcoin/libbitcoin libbitcoin] has a unit test under tests/ec-key.cpp (make ec-key && ./bin/tests/ec-key). There is also a working OP_CHECKSIG implementation in src/script.cpp under script::op_checksig(). See also the unit test: tests/script-test.cpp

<source lang="cpp">
#include <iostream>
#include <iomanip>
#include <bitcoin/util/serializer.hpp>
#include <bitcoin/util/elliptic_curve_key.hpp>
#include <bitcoin/util/sha256.hpp>
#include <bitcoin/util/assert.hpp>
#include <bitcoin/util/logger.hpp>
#include <bitcoin/types.hpp>
#include <openssl/ecdsa.h>
#include <openssl/obj_mac.h>
using libbitcoin::elliptic_curve_key;
using libbitcoin::serializer;
using libbitcoin::hash_digest;
using libbitcoin::data_chunk;
using libbitcoin::log_info;
using libbitcoin::log_fatal;

int main()
{
serializer ss;
// blk number 170, tx 1, input 0
// version = 1
ss.write_4_bytes(1);
// 1 inputs
ss.write_var_uint(1);

// input 0
// prevout hash
ss.write_hash(hash_digest{0x04, 0x37, 0xcd, 0x7f, 0x85, 0x25, 0xce, 0xed, 0x23, 0x24, 0x35, 0x9c, 0x2d, 0x0b, 0xa2, 0x60, 0x06, 0xd9, 0x2d, 0x85, 0x6a, 0x9c, 0x20, 0xfa, 0x02, 0x41, 0x10, 0x6e, 0xe5, 0xa5, 0x97, 0xc9});
// prevout index
ss.write_4_bytes(0);

// input script after running OP_CHECKSIG for this tx is a single
// OP_CHECKSIG opcode
data_chunk raw_data;
raw_data = {0x04, 0x11, 0xdb, 0x93, 0xe1, 0xdc, 0xdb, 0x8a, 0x01, 0x6b, 0x49, 0x84, 0x0f, 0x8c, 0x53, 0xbc, 0x1e, 0xb6, 0x8a, 0x38, 0x2e, 0x97, 0xb1, 0x48, 0x2e, 0xca, 0xd7, 0xb1, 0x48, 0xa6, 0x90, 0x9a, 0x5c, 0xb2, 0xe0, 0xea, 0xdd, 0xfb, 0x84, 0xcc, 0xf9, 0x74, 0x44, 0x64, 0xf8, 0x2e, 0x16, 0x0b, 0xfa, 0x9b, 0x8b, 0x64, 0xf9, 0xd4, 0xc0, 0x3f, 0x99, 0x9b, 0x86, 0x43, 0xf6, 0x56, 0xb4, 0x12, 0xa3};
data_chunk raw_script;
raw_script = data_chunk();
raw_script.push_back(raw_data.size());
libbitcoin::extend_data(raw_script, raw_data);
raw_script.push_back(172);
ss.write_var_uint(raw_script.size());
ss.write_data(raw_script);
// sequence
ss.write_4_bytes(0xffffffff);

// 2 outputs for this tx
ss.write_var_uint(2);

// output 0
ss.write_8_bytes(1000000000);
// script for output 0
raw_data = {0x04, 0xae, 0x1a, 0x62, 0xfe, 0x09, 0xc5, 0xf5, 0x1b, 0x13, 0x90, 0x5f, 0x07, 0xf0, 0x6b, 0x99, 0xa2, 0xf7, 0x15, 0x9b, 0x22, 0x25, 0xf3, 0x74, 0xcd, 0x37, 0x8d, 0x71, 0x30, 0x2f, 0xa2, 0x84, 0x14, 0xe7, 0xaa, 0xb3, 0x73, 0x97, 0xf5, 0x54, 0xa7, 0xdf, 0x5f, 0x14, 0x2c, 0x21, 0xc1, 0xb7, 0x30, 0x3b, 0x8a, 0x06, 0x26, 0xf1, 0xba, 0xde, 0xd5, 0xc7, 0x2a, 0x70, 0x4f, 0x7e, 0x6c, 0xd8, 0x4c};
// when data < 75, we can just write it's length as a single byte ('special'
// opcodes)
raw_script = data_chunk();
raw_script.push_back(raw_data.size());
libbitcoin::extend_data(raw_script, raw_data);
// OP_CHECKSIG
raw_script.push_back(172);
// now actually write the script
ss.write_var_uint(raw_script.size());
ss.write_data(raw_script);

// output 0
ss.write_8_bytes(4000000000);
// script for output 0
raw_data = {0x04, 0x11, 0xdb, 0x93, 0xe1, 0xdc, 0xdb, 0x8a, 0x01, 0x6b, 0x49, 0x84, 0x0f, 0x8c, 0x53, 0xbc, 0x1e, 0xb6, 0x8a, 0x38, 0x2e, 0x97, 0xb1, 0x48, 0x2e, 0xca, 0xd7, 0xb1, 0x48, 0xa6, 0x90, 0x9a, 0x5c, 0xb2, 0xe0, 0xea, 0xdd, 0xfb, 0x84, 0xcc, 0xf9, 0x74, 0x44, 0x64, 0xf8, 0x2e, 0x16, 0x0b, 0xfa, 0x9b, 0x8b, 0x64, 0xf9, 0xd4, 0xc0, 0x3f, 0x99, 0x9b, 0x86, 0x43, 0xf6, 0x56, 0xb4, 0x12, 0xa3};
// when data < 75, we can just write it's length as a single byte ('special'
raw_script.push_back(raw_data.size());
libbitcoin::extend_data(raw_script, raw_data);
// OP_CHECKSIG
raw_script.push_back(172);
// now actually write the script
ss.write_var_uint(raw_script.size());
ss.write_data(raw_script);

// End of 2 outputs

// locktime
ss.write_4_bytes(0);

// write hash_type_code
ss.write_4_bytes(1);

// Dump hex to screen
log_info() << "hashing:";
{
auto log_obj = log_info();
log_obj << std::hex;
for (int val: ss.get_data())
log_obj << std::setfill('0') << std::setw(2) << val << ' ';
}
log_info();

data_chunk raw_tx = {0x01, 0x00, 0x00, 0x00, 0x01, 0xc9, 0x97, 0xa5, 0xe5, 0x6e, 0x10, 0x41, 0x02, 0xfa, 0x20, 0x9c, 0x6a, 0x85, 0x2d, 0xd9, 0x06, 0x60, 0xa2, 0x0b, 0x2d, 0x9c, 0x35, 0x24, 0x23, 0xed, 0xce, 0x25, 0x85, 0x7f, 0xcd, 0x37, 0x04, 0x00, 0x00, 0x00, 0x00, 0x43, 0x41, 0x04, 0x11, 0xdb, 0x93, 0xe1, 0xdc, 0xdb, 0x8a, 0x01, 0x6b, 0x49, 0x84, 0x0f, 0x8c, 0x53, 0xbc, 0x1e, 0xb6, 0x8a, 0x38, 0x2e, 0x97, 0xb1, 0x48, 0x2e, 0xca, 0xd7, 0xb1, 0x48, 0xa6, 0x90, 0x9a, 0x5c, 0xb2, 0xe0, 0xea, 0xdd, 0xfb, 0x84, 0xcc, 0xf9, 0x74, 0x44, 0x64, 0xf8, 0x2e, 0x16, 0x0b, 0xfa, 0x9b, 0x8b, 0x64, 0xf9, 0xd4, 0xc0, 0x3f, 0x99, 0x9b, 0x86, 0x43, 0xf6, 0x56, 0xb4, 0x12, 0xa3, 0xac, 0xff, 0xff, 0xff, 0xff, 0x02, 0x00, 0xca, 0x9a, 0x3b, 0x00, 0x00, 0x00, 0x00, 0x43, 0x41, 0x04, 0xae, 0x1a, 0x62, 0xfe, 0x09, 0xc5, 0xf5, 0x1b, 0x13, 0x90, 0x5f, 0x07, 0xf0, 0x6b, 0x99, 0xa2, 0xf7, 0x15, 0x9b, 0x22, 0x25, 0xf3, 0x74, 0xcd, 0x37, 0x8d, 0x71, 0x30, 0x2f, 0xa2, 0x84, 0x14, 0xe7, 0xaa, 0xb3, 0x73, 0x97, 0xf5, 0x54, 0xa7, 0xdf, 0x5f, 0x14, 0x2c, 0x21, 0xc1, 0xb7, 0x30, 0x3b, 0x8a, 0x06, 0x26, 0xf1, 0xba, 0xde, 0xd5, 0xc7, 0x2a, 0x70, 0x4f, 0x7e, 0x6c, 0xd8, 0x4c, 0xac, 0x00, 0x28, 0x6b, 0xee, 0x00, 0x00, 0x00, 0x00, 0x43, 0x41, 0x04, 0x11, 0xdb, 0x93, 0xe1, 0xdc, 0xdb, 0x8a, 0x01, 0x6b, 0x49, 0x84, 0x0f, 0x8c, 0x53, 0xbc, 0x1e, 0xb6, 0x8a, 0x38, 0x2e, 0x97, 0xb1, 0x48, 0x2e, 0xca, 0xd7, 0xb1, 0x48, 0xa6, 0x90, 0x9a, 0x5c, 0xb2, 0xe0, 0xea, 0xdd, 0xfb, 0x84, 0xcc, 0xf9, 0x74, 0x44, 0x64, 0xf8, 0x2e, 0x16, 0x0b, 0xfa, 0x9b, 0x8b, 0x64, 0xf9, 0xd4, 0xc0, 0x3f, 0x99, 0x9b, 0x86, 0x43, 0xf6, 0x56, 0xb4, 0x12, 0xa3, 0xac, 0x00, 0x00, 0x00, 0x00, 0x01, 0x00, 0x00, 0x00};
BITCOIN_ASSERT(raw_tx == ss.get_data());

hash_digest tx_hash = libbitcoin::generate_sha256_hash(ss.get_data());

data_chunk pubkey{0x04, 0x11, 0xdb, 0x93, 0xe1, 0xdc, 0xdb, 0x8a, 0x01, 0x6b, 0x49, 0x84, 0x0f, 0x8c, 0x53, 0xbc, 0x1e, 0xb6, 0x8a, 0x38, 0x2e, 0x97, 0xb1, 0x48, 0x2e, 0xca, 0xd7, 0xb1, 0x48, 0xa6, 0x90, 0x9a, 0x5c, 0xb2, 0xe0, 0xea, 0xdd, 0xfb, 0x84, 0xcc, 0xf9, 0x74, 0x44, 0x64, 0xf8, 0x2e, 0x16, 0x0b, 0xfa, 0x9b, 0x8b, 0x64, 0xf9, 0xd4, 0xc0, 0x3f, 0x99, 0x9b, 0x86, 0x43, 0xf6, 0x56, 0xb4, 0x12, 0xa3};
// Leave out last byte since that's the hash_type_code (SIGHASH_ALL in this
// case)
data_chunk signature{0x30, 0x44, 0x02, 0x20, 0x4e, 0x45, 0xe1, 0x69, 0x32, 0xb8, 0xaf, 0x51, 0x49, 0x61, 0xa1, 0xd3, 0xa1, 0xa2, 0x5f, 0xdf, 0x3f, 0x4f, 0x77, 0x32, 0xe9, 0xd6, 0x24, 0xc6, 0xc6, 0x15, 0x48, 0xab, 0x5f, 0xb8, 0xcd, 0x41, 0x02, 0x20, 0x18, 0x15, 0x22, 0xec, 0x8e, 0xca, 0x07, 0xde, 0x48, 0x60, 0xa4, 0xac, 0xdd, 0x12, 0x90, 0x9d, 0x83, 0x1c, 0xc5, 0x6c, 0xbb, 0xac, 0x46, 0x22, 0x08, 0x22, 0x21, 0xa8, 0x76, 0x8d, 0x1d, 0x09};
BITCOIN_ASSERT(signature.size() == 70);

elliptic_curve_key key;
if (!key.set_public_key(pubkey))
{
log_fatal() << "unable to set EC public key";
return -1;
}

log_info() << "checksig returns: " << (key.verify(tx_hash, signature) ? "true" : "false");
return 0;
}

</source>

[[Category:Technical]]
[[Category:Developer]]

File:Bitcoin OpCheckSig InDetail.png

2011-08-14T13:13:35Z

Etotheipi: A full breakdown of the process to verify the Bitcoin ECDSA signature of a pair of transactions.

== Summary ==
A full breakdown of the process to verify the Bitcoin ECDSA signature of a pair of transactions.
== Licensing ==
{{self|Cc-zero}}

Mining hardware comparison

2011-04-06T05:00:00Z

Etotheipi: /* AMD */

Below are some statistics about the mining performance of various hardware used in a [[mining rig]].

The table shows stock clock numbers. 10-20% performance improvement can be achieved via overclocking.

==Graphics cards==

===AMD===
To get the maximum performance use the 2.1 or 2.2 release of the ATI Stream SDK. 2.3 performance drops by 5-10%.

{| class="wikitable sortable"
|-
! Model !! Mhash/s !! Mhash/W !! W !! Clock !! SP !! SDK !! Slot !! Miner !! Notes
|-
| 3XXX || || || || || || || || OpenCL Not Supported
|-
| 42XX || || || || || || || PCI-E 2.0 x16 || || OpenCL Not Supported (intergrated/mobile GPU)
|-
| 4350 || 6.93 || 0.346 || 20 || 575 || 80 || || PCI-E 2.0 x16 || poclbm || -w 32, don't use vectors
|-
| 4550 || 7.23 || 0.289 || 25 || 600 || 80 || || PCI-E 2.0 x16 || poclbm || -w 32, don't use vectors
|-
| 4650 || 31.33 || 0.653 || 48 || 650 || 320 || || PCI-E 2.0 x16 || poclbm || -w 32, don't use vectors
|-
| 4670 || 36.14 || 0.613 || 59 || 750 || 320 || || PCI-E 2.0 x16 || poclbm || -w 32, don't use vectors
|-
| 4730 || 72.29 || 0.657 || 110 || 750 || 640 || || PCI-E 2.0 x16 || ||
|-
| 4770 || 72.29 || 0.904 || 80 || 750 || 640 || || PCI-E 2.0 x16 || ||
|-
| 4830 || 55.42 || 0.583 || 95 || 575 || 640 || || PCI-E 2.0 x16 || ||
|-
| 4850 || 75.30 || 0.685 || 110 || 625 || 800 || || PCI-E 2.0 x16 || ||
|-
| 4860 || 67.47 || 0.519 || 130 || 700 || 640 || || PCI-E 2.0 x16 || ||
|-
| 4870 || 90.36 || 0.602 || 150 || 750 || 800 || 2.1 || PCI-E 2.0 x16 || clmine ||
|-
| 4870 || 78 || || || || || || PCI-E 2.0 x16 || m0mchil's OpenCL/Vista 64bit || [http://www.bitcoin.org/smf/index.php?topic=1628.msg25069#msg25069 source]
|-
| 4890 || 102.41 || 0.539 || 190 || 850 || 800 || || PCI-E 2.0 x16 || ||
|-
| 4850X2 || 150.60 || 0.602 || 250 || 625 || 1600 || || PCI-E 2.0 x16 || ||
|-
| 4870X2 || 180.72 || 0.632 || 286 || 750 || 1600 || || PCI-E 2.0 x16 || ||
|-
| 5450 || 11.99 || 0.631 || 19 || 650 || 80 || || PCI-E 2.1 x16 || ||
|-
| 5550 || 40.59 || 1.041 || 39 || 550 || 320 || || PCI-E 2.1 x16 || ||
|-
|style="background:#FFFFEF;"| 5570 || 59.96 || 1.538 || 39 || 650 || 400 || || PCI-E 2.1 x16 || ||
|-
|style="background:#FFFFEF;"| 5570 || 64 || 1.641 || 39 || 650 || || || PCI-E 2.1 x16 || m0mchil's OpenCL/WinXP || [http://www.bitcoin.org/smf/index.php?topic=1628.msg24699#msg24699 source]
|-
| 5650 || 48 || 2.5-3.2 ? || 15-19 ? || || || || PCI-E 2.1 x16 || m0mchil's OpenCL/Win7-64 || [http://www.bitcoin.org/smf/index.php?topic=1628.msg26292#msg26292 source] [http://www.notebookcheck.net/ATI-Mobility-Radeon-HD-5650.23697.0.html source]
|-
| 5670 || 71.49 || 1.117 || 64 || 775 || 400 || || PCI-E 2.1 x16 || ||
|-
|style="background:#EEFFEE;"| 5670 || 72 || 1.64 || 44 || 850 || || || PCI-E 2.0 x16 || poclbm-mod (Win7-64) || Sapphire 100287VGAL card is low power
|-
| 5670 || 85 || || || 900 || 400 || || PCI-E 2.1 x16 || poclbm || -v -f 0 -w 128
|-

| 5750 || 116.24 || 1.352 || 86 || 700 || 720 || || PCI-E 2.1 x16 || ||
|-
| 5770 || 156.83 || 1.452 || 108 || 850 || 800 || 2.1 || PCI-E 2.1 x16 || clmine ||
|-
|style="background:#FFFFFF;"| 5830 || 206.64 || 1.181 || 175 || 800 || 1120 || || PCI-E 2.1 x16 || ||
|-
|style="background:#FFFFFF;"| 5830 || 241 || 1.377 || 175 || 1006 || || 2.3 || PCI-E 2.1 x16 || poclbm 2011-03-11 / Win7 64 ||
|-
|style="background:#EFEFFF;"| 5850 || 240.77 || 1.595 || 151 || 725 || 1440 || || PCI-E 2.1 x16 || ||
|-
|style="background:#EFEFFF;"| 5850 || 252 || 1.669 || 151 || 765 || || 2.3 || PCI-E 2.1 x16 || poclbm 2011-01-25 ||
|-
|style="background:#EFEFFF;"| 5850 || 255.3 || 1.690 || 151 || 765 || || 2.2 || PCI-E 2.1 x16 || poclbm 2011-01-25 ||
|-
|style="background:#EFEFFF;"| 5850 || 300 || 1.987 || 151 || 925 (OC) || || || PCI-E 2.1 x16 || m0mchil's OpenCL || [http://www.bitcoin.org/smf/index.php?topic=1628.msg24699#msg24699 source]
|-
|style="background:#EFEFFF;"| 5850 || 250.26 || 1.657 || 151 || || || || PCI-E 2.1 x16 || opencl client || [http://www.bitcoin.org/smf/index.php?topic=1628.msg29471#msg29471 source]
|-
|style="background:#EFFFEF;"| 5870 || 313.65 || 1.668 || 188 || 850 || 1600 || 2.1 || PCI-E 2.1 x16 || clmine ||
|-
|style="background:#EFFFEF;"| 5870 || 313 || 1.665 || 188 || 900? || 1600 || 2.3 || PCI-E 2.1 x16 || Diablo/Linux ||
|-
|style="background:#EFFFEF;"| 5870 || 343 || 1.824 || 188 || 900? || 1600 || 2.1 || PCI-E 2.1 x16 || Diablo/Linux ||
|-
|style="background:#EFFFEF;"| 5870 || 355 || 1.888 || 188 || 900? || 1600 || 2.1 || PCI-E 2.1 x16 || poclbm/Linux ||
|-
|style="background:#EFFFEF;"| 5870 || 340 || 1.809 || 188 || 850 || 1600 || || PCI-E 2.1 x16 || m0mchil's OpenCL || [http://www.bitcoin.org/smf/index.php?topic=1628.msg26363#msg26363 source]
|-
|style="background:#FFEFEF;"| 5970 || 535.06 || 1.820 || 294 || 725 || 3200 || 2.1 || PCI-E 2.1 x16 || clmine ||
|-
|style="background:#FFEFEF;"| 5970 || 560 || 1.905 || 294 || 725 || || || PCI-E 2.1 x16 || Diablo ||
|-
|style="background:#FFEFEF;"| 5970 || 565 || 1.922 || 294 || || || 2.1 || PCI-E 2.1 x16 || clmine2 ||
|-
|style="background:#FFEFEF;"| 5970 || 604 || 2.054 || 294 || || || 2.1 || PCI-E 2.1 x16 || clmine ||
|-
|style="background:#FFEFEF;"| 5970 || 645 || || || 850 || 3200 || 2.1 || PCI-E 2.1 x16 || m0mchil/poclbm 03-07-11 || -f1, Debian 6, fglrx-driver 10.9.3
|-
| 6850 || 171.59 || 1.351 || 127 || 775 || 960 || 2.1 || PCI-E 2.1 x16 || clmine ||
|-
| 6850 || 196 || || || 850 || 960 || || PCI-E 2.1 x16 || poclbm || -v -w 128 -f 0
|-
| 6870 || 232.47 || 1.540 || 151 || 900 || 1120 || || PCI-E 2.1 x16 || ||
|-
| 6870 || 260.1 || 1.611 || 175 || 1001 || 1150 || 2.2 || PCI-E 2.1 x16 || poclbm-gui windows7x86 cat 11.3 || -v -w 128 -f 1
|-
| 6870 || 282.23 || 1.611 || 175 || 1047 || 1120 || 2.2 || PCI-E 2.1 x16 || poclbm windows cat 11.2 || -v -w 128 -f 0 mem clock 300
|-
| 6950 || 295 || || 160 (?) || 810 || 1536 || 2.4.595.0 || PCI-E 2.1 x16 || m0mchil/poclbm 03-07-11 || unlocked shaders, default mem 1250
|-
| 6950 || 325 || || 200 (?) || 885 || 1536 || 2.4.595.0 || PCI-E 2.1 x16 || m0mchil/poclbm 03-07-11 || unlocked shaders, default mem 1250
|-
| 6950 || 360 || || 200 (?) || 970 || 1536 || 2.4.595.0 || PCI-E 2.1 x16 || m0mchil/poclbm 03-07-11 || unlocked shaders, default mem 1250
|-
| 6970 || 323 || 1.468 || 220 || 880 || 1536 || 2.3 || PCI-E 2.1 x16 || poclbm || -w 64, SDK 2.1 not supported on 69xx.
|-
| 6990 || || || || || || 2.3 || PCI-E 2.1 x16 || || SDK 2.1 not supported on 69xx.
|-
|FirePro V8700 || 84.8 || || || 750 || 800 || || || poclbm-mod.03.24.2011 ||
|-
|}

===Nvidia===

{| class="wikitable sortable"
|-
! Model !! Mhash/s !! Mhash/W !! W !! Clock !! SP !! Comment
|-
| 8200 mGPU || 1.2 || || || 1200 || 16 || 128 MB shared memory, "poclbm -w 128 -f 0"
|-
| 8600M GT || 4.93 || || || || 32 ||
|-
| 8600GT || 5.66 || || || 1188 || 32 ||
|-
| 8600GT OC || 7.3 || || || 1602 || 32 || [http://www.bitcoin.org/smf/index.php?topic=1334.0 poclbm] -w 128 [http://www.bitcoin.org/smf/index.php?topic=4967.msg72833#msg72833 source]
|-
| 8800GT || 25 || 0.24 || 105 || 1300 || ||
|-
| 8800GT || 24.5 || 0.23 || 105 || 1300 || || [http://www.bitcoin.org/smf/index.php?topic=1628.msg37592#msg37592 source]
|-
| 8800GTS || 16.8 || 0.109 || 154 || || || [http://www.bitcoin.org/smf/index.php?topic=1628.msg25069#msg25069 source] [http://www.techspot.com/review/79-geforce-8800-gts-512/page11.html source]
|-
| 8800 GTS || 18.7 || 0.124 || 150 || 1200 || || poclbm -w 64 no vectors
|-
| 9300GE || 1.57 || || || 1300 || 8 ||
|-
| 9300GS || 1.69 || || || 1400 || 8 ||
|-
| 9400GT || 3.37 || 0.067 || 50 || 1400 || 16 ||
|-
| 9500GT || 6.75 || 0.135 || 50 || 1400 || 32 ||
|-
| 9600GSO || 19.88 || 0.237 || 84 || 1375 || 96 ||
|-
| 9600GSO512 || 11.75 || 0.131 || 90 || 1625 || 48 ||
|-
| 9600GT || 15.66 || 0.165 || 95 || 1625 || 64 ||
|-
| 9600GT OC || 18.8 || <0.198 || >95 || 1981 || 64 || [http://www.bitcoin.org/smf/index.php?topic=1334.0 poclbm] -w 128 -f 10 [http://www.bitcoin.org/smf/index.php?topic=4967.msg74610#msg74610 source] [http://www.bitcoin.org/smf/index.php?topic=4967.msg73353#msg73353 source]
|-
| 9800GT || 30.36 || 0.289 || 105 || 1800 || 112 ||
|-
| 9800GTX || 32.54 || 0.232 || 140 || 1688 || 128 ||
|-
| 9800GTX+ || 35.39 || 0.251 || 141 || 1836 || 128 ||
|-
|style="background-color:#FFEFEF"| 9800GX2 || 57.83 || 0.294 || 197 || || 2x128 ||
|-
|style="background-color:#FFEFEF"| 9800GX2 || 28 || 0.142 || 197 || || 2x128 || [http://www.bitcoin.org/smf/index.php?topic=1628.msg37620#msg37620 source]
|-
| G210 || 3.38 || 0.111 || 30.5 || 1402 || 16 ||
|-
| GT220 || 9.83 || 0.170 || 58 || 1360 || 48 ||
|-
| GT240 || 19.37 || 0.281 || 69 || 1340 || 96 ||
|-
| GT240 || 21.24 || || || || 96 || [http://www.bitcoin.org/smf/index.php?topic=4291.0 poclbm-mod] -f 0 -v [http://www.bitcoin.org/smf/index.php?topic=4967.msg73383#msg73383 source]
|-
| GTS250 || 35.39 || 0.244 || 145 || 1836 || 128 ||
|-
| GTX260 || 35.91 || 0.178 || 202 || 1242 || 192 ||
|-
| GTX260 || 44 || 0.242 || 182 || 1242 || 216 || [http://www.bitcoin.org/smf/index.php?topic=1628.msg24699#msg24699 source]
|-
| GTX260c216 || 40.40 || 0.236 || 171 || 1242 || 216 ||
|-
| GTX260c216 OC || 52.0 || || || 1461 || 216 || "poclbm -w 256 -f 1"
|-
| GTX275 || 50.75 || 0.232 || 219 || 1404 || 240 ||
|-
| GTX275 || 58 || || || 729/1458 || 240 || poclbm -f 0 -w 256
|-
| GTX280 || 46.84 || 0.198 || 236 || 1296 || 240 ||
|-
| GTX285 || 53.35 || 0.262 || 204 || 1476 || 240 ||
|-
| GTX295 || 89.78 || 0.311 || 289 || 1242 || 480 ||
|-
| GT 320M (MacBook Air) || 6.12 || || || 1212 || 48 ||
|-
| GT 330M (Sony Vaio Z) || 7.8 || 0.71 ( 0.3 total) || 11 (26w total) || 1045 || 48 ||
|-
| GT430 || 20.24 || 0.413 || 49 || 1400 || 96 ||
|-
| GTS450 || 45.28 || 0.427 || 106 || 1566 || 192 ||
|-
| GTX460SE || 56.39 || 0.376 || 150 || 1300 || 288 ||
|-
| GTX460 || 68.31 || 0.427 || 160 || 1350 || 336 ||
|-
| GTX460 (2 cards) || 102 || 0.319? || 320? || 1350 || || [http://www.bitcoin.org/smf/index.php?topic=1628.msg26363#msg26363 source]
|-
| GTX460 (2 cards) OC || 127 || 0.374 || 340 || 1620 || 2x 336 || [http://www.bitcoin.org/smf/index.php?topic=2444.0 rpcminer-cuda] -gpugrid=128 -gputhreads=128 ver.20110227
|-
| GTX465 || 64.41 || 0.322 || 200 || 1215 || 352 ||
|-
| GTX470 || 81.98 || 0.381 || 215 || 1215 || 448 ||
|-
| GTX470 || 94.7 || || || 1414 || ||
|-
| GTX480 || 101.28 || 0.405 || 250 || 1401 || 480 ||
|-
| GTX560 Ti || 67.7 || 0.39 || 170 || 1700 || 384 || standard EVGA 560, no overclock
|-
| GTX560 OC || 86.7 || <0.51 || >170 || 1800 || 384 || [http://www.bitcoin.org/smf/index.php?topic=2444.0 rpcminer-cuda] [http://www.bitcoin.org/smf/index.php?topic=4967.msg72816#msg72816 source]
|-
| GTX570 || 105.83 || 0.483 || 219 || 1464 || 480 ||
|-
| GTX580 || 119.06 || 0.488 || 244 || 1544 || 512 ||
|-
| Quadro FX 580 || 5.7 || 0.14 || 40 || 1125 || 4 ||
|-
| Quadro FX 1600M || 6 || 0.12 || 50 || 625 || 32 ||rpcminer-cuda, Win
|-
| Quadro NVS 135M || 1.05 || 0.1 || 10 || 800 || 1 ||
|-
| Quadro NVS 3100M || 3.6 || 0.257 || 14 || 600 || 16 || rpcminer-cuda, Win, CUDA 3.1.1
|-
|}

==CPUs==

A lot of nice data can be pulled from [http://www.bitcoin.org/smf/index.php?topic=1628.0 this thread] to seed this section. Also from [https://www.bitcoin.org/wiki/doku.php?id=bitcoin_miners this page on the old wiki].

===AMD===
{| class="wikitable sortable"
|-
! Model !! nprocs !! Mhash/s !! Mhash/W !! ACP [W] !! Clock !! Version !! Comment
|-
| 2x Opteron 6128 || 16 || 32.4 || 0.203 || 160W || 2 GHz || 0.3.19 || -4way
|-
| Athlon X2 3800+ || 2 || 1.73 || 0.03 || 65 W || 2.00 GHz || cpuminer (v0.8.1-1-g69529c3) || -algo=4way
|-
| Athlon X2 4000+ || 2 || 1.9 || 0.02 || 65W || 2.1 GHz || rpc-miner ||
|-
| Athlon X2 4400+ || || 2.09 || 0.32 || 65W || 2.3GHz || 0.3.19/Win x64 || [http://www.bitcoin.org/smf/index.php?topic=1628.msg37592#msg37592 source]
|-
| Athlon X2 6000+ || 2 || 2.81 || 0.02 || 125W || 3 GHz || || [http://www.bitcoin.org/smf/index.php?topic=1628.msg22881#msg22881 source]
|-
| Athlon X2 6400+ Black Edition || 2 || 2.9 || 0.023 || 125W || 3.2 GHz || 0.3.20.2 BETA/Win 7 x64 || -4way
|-
| Athlon XP 2000+ || 2 || 0.62 || 0.009 || 70W || 1.67 GHz || 0.3.18/Ubuntu || [http://www.bitcoin.org/smf/index.php?topic=1628.msg37592#msg37592 source] [http://www.pcstats.com/articleview.cfm?articleid=914&page=4 source]
|-
| Athlon II X2 240e || 2 || 2.71 || 0.06 || 45W || 2.81 GHz || bitcoind || [http://www.bitcoin.org/smf/index.php?topic=1628.msg19426#msg19426 source]
|-
| Athlon II X4 630 || 4 || 10.7 || 0.11 || 95W || 2.8 GHz || bitcoin-miner 0.4 ||
|-
| Phenom II X6 1055T || 6 || 15.84 || 0.13 || 125W || 2.82 GHz || bitcoind || [http://www.bitcoin.org/smf/index.php?topic=1628.msg19426#msg19426 source]
|-
| Phenom II X6 1100T || 6 || 22 || 0.176 || 125W || 3.82 GHz || bitcoin-miner || Aciid#bitcoin-dev
|-
| Phenom II X3 720 || 3 || 3.8 || 0.04 || 95W || 2.8 GHz || 0.3.1x/WinXP || [http://www.bitcoin.org/smf/index.php?topic=1628.msg24699#msg24699 source]
|-
| Phenom II X3 720 || 3 || 7.2 || 0.08 || 95W || 2.8 GHz || cpu-miner 0.2.1/WinXP || [http://www.bitcoin.org/smf/index.php?topic=1628.msg24699#msg24699 source]
|-
| Phenom II x4 955 || 4 || 11 || 0.09 || 125W || 3.2 GHz || rpcminer-4way ||
|}

===ARM===
{| class="wikitable sortable"
|-
! Model !! p/t !! Mhash/s !! Mhash/W !! ACP [W] !! Clock !! Version !! Comment
|-
| Cortex A8 || 1 || 0.125 || || || 0.6 GHz || cpuminer git (2011-03-26) || Nokia N900: 'cryptopp'
|-
| Cortex A8 || 1 || 0.2 || || || 0.6 GHz || cpuminer git (2011-03-26) || Nokia N900: 'c' algo
|}

===Intel===
{| class="wikitable sortable"
|-
! Model !! p/t !! Mhash/s !! Mhash/W !! ACP [W] !! Clock !! Version !! Comment
|-
| Pentium III mobile ? || 1 || 0.3 || 0.014 || 21W || 1.07 GHz || 0.3.1x/Win2K || [http://www.bitcoin.org/smf/index.php?topic=1628.msg24699#msg24699 source] [http://ark.intel.com/Product.aspx?id=27380 source]
|-
| Old Xeon 512k (Dual) || 2x1/2 || 2.0 || ? || ? || 3.06GHz || cpuminer (v0.8.1-1-g69529c3) || HT disabled, algo=4way (twice as fast as the 2nd best algo)
|-
| Pentium 4 2.0A || 1 || 0.85 || || || 2.0 GHz || [http://www.bitcoin.org/smf/index.php?topic=3486.0 ufasoft-0.4]/WinXP || -g no -t 2
|-
| Pentium Dual-Core E5400 || 2/2 || 2.27 || 0.03 || 65W || 2.7 GHz || bitcoind || [http://www.bitcoin.org/smf/index.php?topic=1628.msg19426#msg19426 source]
|-
| Celeron E330 || 2/2 || 2.2 || 0.03 || 65W || 2.5 GHz || 0.3.19/Ubuntu10.04 || [http://www.bitcoin.org/smf/index.php?topic=1628.msg37620#msg37620 source]
|-
| Core i3 M350 || 2/4 || 1.48 || 0.04 || 35W || 2.27 GHz || bitcoind || [http://www.bitcoin.org/smf/index.php?topic=1628.msg19426#msg19426 source]
|-
| Core i5 M450 || 2/4 || 1.8 || 0.05 || 35W || 1.2 GHz || 0.3.17/Win7-54 || [http://www.bitcoin.org/smf/index.php?topic=1628.msg26292#msg26292 source]
|-
| Core i5-650 || 2/4 || 5.1 || 0.04 ? || || 3.2 GHz || cpuminer-0.7 || -4way
|-
| Core i5 ? || 4/? || 6.5 || || || || client from svn || [http://www.bitcoin.org/smf/index.php?topic=1628.msg37621#msg37621 source]
|-
| Core i5-2400 || 4/4 || 4.5 || 0.05 || 95W || 3.1 GHz || cpuminer git (2011-01-22) || cryptopp_asm32
|-
| Core i5-2400 || 4/4 || 14 || 0.15 || 95W || 3.1 GHz || cpuminer git (2011-03-26) || sse2_64
|-
| Core i7 920 || 4/8 || 19.2 || 0.10 || 195 || 4.0 GHz (x21) || [http://www.bitcoin.org/smf/index.php?topic=3486.0 ufasoft] || -a 5
|-
| Core i7 950 || 4/8 || 5.88 || 0.039 || 150W || 3.83 GHz (x23) || bitcoin-0.3.20.2 Win7-64 ||
|-
| Core i7 950 || 4/8 || 18.9 || 0.126 || 150W || 3.83 GHz (x23) || [http://www.bitcoin.org/smf/index.php?topic=3486.0 ufasoft] v0.4 ||
|-
| Core i7 980x || 6/12 || 19.2 || 0.15 || 130 || 4.4 GHz (x33) || cpuminer/Win7-64 ||
|-
| Core i7 980x || 6/12 || 8.7 || || || 3.9 GHz (x27) || 0.3.17/Win7-64 ||
|-
| Core i7 620M || 2/4 || 6.3 || 0.18 || 35 || 2.66 GHz || [http://www.bitcoin.org/smf/index.php?topic=3486.0 ufasoft] v0.4 ||
|-
| Core 2 Duo E6550 || 1/2 || 2.45 || ? || ? || 2.33 GHz || cpuminer 0.7.1 (Linux) || --algo=sse2_64
|-
| Core 2 Duo E6850 || 2/2 || 6.75 || 0.10 || 65W || 3.0 Ghz || ufasoft-0.3 ||
|-
| Core 2 Duo E7300 || 2/2 || 7.76 || 0.11 || 70W || 3.33 GHz (o/c?) || ufasoft-0.3 || miner optimized for Intel Core
|-
| Core 2 Duo E7300 || 2/2 || 2.52 || 0.04 || 65W || 2.66 GHz || bitcoind || [http://www.bitcoin.org/smf/index.php?topic=1628.msg19426#msg19426 source]
|-
| Xeon X5355 (dual) || 2x4/4 || 10.13 || 0.16 || 120W || 2.66GHz || bitcoind || Roughly the same speed as the "c" algo in cpuminer
|-
| Xeon X5355 (dual) || 2x4/4 || 22.76 || 0.09 || 120W || 2.66GHz || cpuminer (v0.8.1-1-g69529c3) || -O2 -march=core2, algo=sse2_64
|-
| Xeon E5440 || 4/8 || 7.3 || ? || 80W || 2.66 GHz|| Kiv's poclbm-gui || FIXME: Either wrong model # or wrong threads/speed info
|-
| Xeon E5520 || 4/8 || 6.5 || 0.08 || 80W || 2.27 GHz || bitcoind || [http://www.bitcoin.org/smf/index.php?topic=1628.msg19426#msg19426 source]
|-
| Xeon E5530 || 4/8 || 7.14 || 0.09 || 80W || 2.4 GHz || bitcoind || [http://www.bitcoin.org/smf/index.php?topic=1628.msg19426#msg19426 source]
|-
| Xeon E5630 (dual) || 2x4/8 || 8 || 0.1 || 80W || 2.53 GHz || 0.3.17/Win7-64 || [http://www.bitcoin.org/smf/index.php?topic=1628.msg29471#msg29471 source]
|-
| Atom N270 || 1 || 0.42 || '''0.17''' || 2.5W || 1.6 GHz || 0.3.1x/WinXP || [http://www.bitcoin.org/smf/index.php?topic=1628.msg24699#msg24699 source]
|}

==See Also==

* [[Mining rig]]
* [[OpenCL miner]]
* [http://www.pcper.com/article.php?aid=745 ATI Stream vs. NVIDIA CUDA - GPGPU computing battle royale]

[[Category:Mining]]

Mining hardware comparison

2011-04-06T04:58:00Z

Etotheipi: /* AMD */

Below are some statistics about the mining performance of various hardware used in a [[mining rig]].

The table shows stock clock numbers. 10-20% performance improvement can be achieved via overclocking.

==Graphics cards==

===AMD===
To get the maximum performance use the 2.1 or 2.2 release of the ATI Stream SDK. 2.3 performance drops by 5-10%.

{| class="wikitable sortable"
|-
! Model !! Mhash/s !! Mhash/W !! W !! Clock !! SP !! SDK !! Slot !! Miner !! Notes
|-
| 3XXX || || || || || || || || OpenCL Not Supported
|-
| 42XX || || || || || || || PCI-E 2.0 x16 || || OpenCL Not Supported (intergrated/mobile GPU)
|-
| 4350 || 6.93 || 0.346 || 20 || 575 || 80 || || PCI-E 2.0 x16 || poclbm || -w 32, don't use vectors
|-
| 4550 || 7.23 || 0.289 || 25 || 600 || 80 || || PCI-E 2.0 x16 || poclbm || -w 32, don't use vectors
|-
| 4650 || 31.33 || 0.653 || 48 || 650 || 320 || || PCI-E 2.0 x16 || poclbm || -w 32, don't use vectors
|-
| 4670 || 36.14 || 0.613 || 59 || 750 || 320 || || PCI-E 2.0 x16 || poclbm || -w 32, don't use vectors
|-
| 4730 || 72.29 || 0.657 || 110 || 750 || 640 || || PCI-E 2.0 x16 || ||
|-
| 4770 || 72.29 || 0.904 || 80 || 750 || 640 || || PCI-E 2.0 x16 || ||
|-
| 4830 || 55.42 || 0.583 || 95 || 575 || 640 || || PCI-E 2.0 x16 || ||
|-
| 4850 || 75.30 || 0.685 || 110 || 625 || 800 || || PCI-E 2.0 x16 || ||
|-
| 4860 || 67.47 || 0.519 || 130 || 700 || 640 || || PCI-E 2.0 x16 || ||
|-
| 4870 || 90.36 || 0.602 || 150 || 750 || 800 || 2.1 || PCI-E 2.0 x16 || clmine ||
|-
| 4870 || 78 || || || || || || PCI-E 2.0 x16 || m0mchil's OpenCL/Vista 64bit || [http://www.bitcoin.org/smf/index.php?topic=1628.msg25069#msg25069 source]
|-
| 4890 || 102.41 || 0.539 || 190 || 850 || 800 || || PCI-E 2.0 x16 || ||
|-
| 4850X2 || 150.60 || 0.602 || 250 || 625 || 1600 || || PCI-E 2.0 x16 || ||
|-
| 4870X2 || 180.72 || 0.632 || 286 || 750 || 1600 || || PCI-E 2.0 x16 || ||
|-
| 5450 || 11.99 || 0.631 || 19 || 650 || 80 || || PCI-E 2.1 x16 || ||
|-
| 5550 || 40.59 || 1.041 || 39 || 550 || 320 || || PCI-E 2.1 x16 || ||
|-
|style="background:#FFFFEF;"| 5570 || 59.96 || 1.538 || 39 || 650 || 400 || || PCI-E 2.1 x16 || ||
|-
|style="background:#FFFFEF;"| 5570 || 64 || 1.641 || 39 || 650 || || || PCI-E 2.1 x16 || m0mchil's OpenCL/WinXP || [http://www.bitcoin.org/smf/index.php?topic=1628.msg24699#msg24699 source]
|-
| 5650 || 48 || 2.5-3.2 ? || 15-19 ? || || || || PCI-E 2.1 x16 || m0mchil's OpenCL/Win7-64 || [http://www.bitcoin.org/smf/index.php?topic=1628.msg26292#msg26292 source] [http://www.notebookcheck.net/ATI-Mobility-Radeon-HD-5650.23697.0.html source]
|-
| 5670 || 71.49 || 1.117 || 64 || 775 || 400 || || PCI-E 2.1 x16 || ||
|-
| 5670 || 72 || 1.64 || 44 || 850 || || || PCI-E 2.0 x16 || poclbm-mod (Win7-64) || Sapphire 100287VGAL card is low power
|-
| 5670 || 85 || || || 900 || 400 || || PCI-E 2.1 x16 || poclbm || -v -f 0 -w 128
|-

| 5750 || 116.24 || 1.352 || 86 || 700 || 720 || || PCI-E 2.1 x16 || ||
|-
| 5770 || 156.83 || 1.452 || 108 || 850 || 800 || 2.1 || PCI-E 2.1 x16 || clmine ||
|-
|style="background:#FFFFFF;"| 5830 || 206.64 || 1.181 || 175 || 800 || 1120 || || PCI-E 2.1 x16 || ||
|-
|style="background:#FFFFFF;"| 5830 || 241 || 1.377 || 175 || 1006 || || 2.3 || PCI-E 2.1 x16 || poclbm 2011-03-11 / Win7 64 ||
|-
|style="background:#EFEFFF;"| 5850 || 240.77 || 1.595 || 151 || 725 || 1440 || || PCI-E 2.1 x16 || ||
|-
|style="background:#EFEFFF;"| 5850 || 252 || 1.669 || 151 || 765 || || 2.3 || PCI-E 2.1 x16 || poclbm 2011-01-25 ||
|-
|style="background:#EFEFFF;"| 5850 || 255.3 || 1.690 || 151 || 765 || || 2.2 || PCI-E 2.1 x16 || poclbm 2011-01-25 ||
|-
|style="background:#EFEFFF;"| 5850 || 300 || 1.987 || 151 || 925 (OC) || || || PCI-E 2.1 x16 || m0mchil's OpenCL || [http://www.bitcoin.org/smf/index.php?topic=1628.msg24699#msg24699 source]
|-
|style="background:#EFEFFF;"| 5850 || 250.26 || 1.657 || 151 || || || || PCI-E 2.1 x16 || opencl client || [http://www.bitcoin.org/smf/index.php?topic=1628.msg29471#msg29471 source]
|-
|style="background:#EFFFEF;"| 5870 || 313.65 || 1.668 || 188 || 850 || 1600 || 2.1 || PCI-E 2.1 x16 || clmine ||
|-
|style="background:#EFFFEF;"| 5870 || 313 || 1.665 || 188 || 900? || 1600 || 2.3 || PCI-E 2.1 x16 || Diablo/Linux ||
|-
|style="background:#EFFFEF;"| 5870 || 343 || 1.824 || 188 || 900? || 1600 || 2.1 || PCI-E 2.1 x16 || Diablo/Linux ||
|-
|style="background:#EFFFEF;"| 5870 || 355 || 1.888 || 188 || 900? || 1600 || 2.1 || PCI-E 2.1 x16 || poclbm/Linux ||
|-
|style="background:#EFFFEF;"| 5870 || 340 || 1.809 || 188 || 850 || 1600 || || PCI-E 2.1 x16 || m0mchil's OpenCL || [http://www.bitcoin.org/smf/index.php?topic=1628.msg26363#msg26363 source]
|-
|style="background:#FFEFEF;"| 5970 || 535.06 || 1.820 || 294 || 725 || 3200 || 2.1 || PCI-E 2.1 x16 || clmine ||
|-
|style="background:#FFEFEF;"| 5970 || 560 || 1.905 || 294 || 725 || || || PCI-E 2.1 x16 || Diablo ||
|-
|style="background:#FFEFEF;"| 5970 || 565 || 1.922 || 294 || || || 2.1 || PCI-E 2.1 x16 || clmine2 ||
|-
|style="background:#FFEFEF;"| 5970 || 604 || 2.054 || 294 || || || 2.1 || PCI-E 2.1 x16 || clmine ||
|-
|style="background:#FFEFEF;"| 5970 || 645 || || || 850 || 3200 || 2.1 || PCI-E 2.1 x16 || m0mchil/poclbm 03-07-11 || -f1, Debian 6, fglrx-driver 10.9.3
|-
| 6850 || 171.59 || 1.351 || 127 || 775 || 960 || 2.1 || PCI-E 2.1 x16 || clmine ||
|-
| 6850 || 196 || || || 850 || 960 || || PCI-E 2.1 x16 || poclbm || -v -w 128 -f 0
|-
| 6870 || 232.47 || 1.540 || 151 || 900 || 1120 || || PCI-E 2.1 x16 || ||
|-
| 6870 || 260.1 || 1.611 || 175 || 1001 || 1150 || 2.2 || PCI-E 2.1 x16 || poclbm-gui windows7x86 cat 11.3 || -v -w 128 -f 1
|-
| 6870 || 282.23 || 1.611 || 175 || 1047 || 1120 || 2.2 || PCI-E 2.1 x16 || poclbm windows cat 11.2 || -v -w 128 -f 0 mem clock 300
|-
| 6950 || 295 || || 160 (?) || 810 || 1536 || 2.4.595.0 || PCI-E 2.1 x16 || m0mchil/poclbm 03-07-11 || unlocked shaders, default mem 1250
|-
| 6950 || 325 || || 200 (?) || 885 || 1536 || 2.4.595.0 || PCI-E 2.1 x16 || m0mchil/poclbm 03-07-11 || unlocked shaders, default mem 1250
|-
| 6950 || 360 || || 200 (?) || 970 || 1536 || 2.4.595.0 || PCI-E 2.1 x16 || m0mchil/poclbm 03-07-11 || unlocked shaders, default mem 1250
|-
| 6970 || 323 || 1.468 || 220 || 880 || 1536 || 2.3 || PCI-E 2.1 x16 || poclbm || -w 64, SDK 2.1 not supported on 69xx.
|-
| 6990 || || || || || || 2.3 || PCI-E 2.1 x16 || || SDK 2.1 not supported on 69xx.
|-
|FirePro V8700 || 84.8 || || || 750 || 800 || || || poclbm-mod.03.24.2011 ||
|-
|}

===Nvidia===

{| class="wikitable sortable"
|-
! Model !! Mhash/s !! Mhash/W !! W !! Clock !! SP !! Comment
|-
| 8200 mGPU || 1.2 || || || 1200 || 16 || 128 MB shared memory, "poclbm -w 128 -f 0"
|-
| 8600M GT || 4.93 || || || || 32 ||
|-
| 8600GT || 5.66 || || || 1188 || 32 ||
|-
| 8600GT OC || 7.3 || || || 1602 || 32 || [http://www.bitcoin.org/smf/index.php?topic=1334.0 poclbm] -w 128 [http://www.bitcoin.org/smf/index.php?topic=4967.msg72833#msg72833 source]
|-
| 8800GT || 25 || 0.24 || 105 || 1300 || ||
|-
| 8800GT || 24.5 || 0.23 || 105 || 1300 || || [http://www.bitcoin.org/smf/index.php?topic=1628.msg37592#msg37592 source]
|-
| 8800GTS || 16.8 || 0.109 || 154 || || || [http://www.bitcoin.org/smf/index.php?topic=1628.msg25069#msg25069 source] [http://www.techspot.com/review/79-geforce-8800-gts-512/page11.html source]
|-
| 8800 GTS || 18.7 || 0.124 || 150 || 1200 || || poclbm -w 64 no vectors
|-
| 9300GE || 1.57 || || || 1300 || 8 ||
|-
| 9300GS || 1.69 || || || 1400 || 8 ||
|-
| 9400GT || 3.37 || 0.067 || 50 || 1400 || 16 ||
|-
| 9500GT || 6.75 || 0.135 || 50 || 1400 || 32 ||
|-
| 9600GSO || 19.88 || 0.237 || 84 || 1375 || 96 ||
|-
| 9600GSO512 || 11.75 || 0.131 || 90 || 1625 || 48 ||
|-
| 9600GT || 15.66 || 0.165 || 95 || 1625 || 64 ||
|-
| 9600GT OC || 18.8 || <0.198 || >95 || 1981 || 64 || [http://www.bitcoin.org/smf/index.php?topic=1334.0 poclbm] -w 128 -f 10 [http://www.bitcoin.org/smf/index.php?topic=4967.msg74610#msg74610 source] [http://www.bitcoin.org/smf/index.php?topic=4967.msg73353#msg73353 source]
|-
| 9800GT || 30.36 || 0.289 || 105 || 1800 || 112 ||
|-
| 9800GTX || 32.54 || 0.232 || 140 || 1688 || 128 ||
|-
| 9800GTX+ || 35.39 || 0.251 || 141 || 1836 || 128 ||
|-
|style="background-color:#FFEFEF"| 9800GX2 || 57.83 || 0.294 || 197 || || 2x128 ||
|-
|style="background-color:#FFEFEF"| 9800GX2 || 28 || 0.142 || 197 || || 2x128 || [http://www.bitcoin.org/smf/index.php?topic=1628.msg37620#msg37620 source]
|-
| G210 || 3.38 || 0.111 || 30.5 || 1402 || 16 ||
|-
| GT220 || 9.83 || 0.170 || 58 || 1360 || 48 ||
|-
| GT240 || 19.37 || 0.281 || 69 || 1340 || 96 ||
|-
| GT240 || 21.24 || || || || 96 || [http://www.bitcoin.org/smf/index.php?topic=4291.0 poclbm-mod] -f 0 -v [http://www.bitcoin.org/smf/index.php?topic=4967.msg73383#msg73383 source]
|-
| GTS250 || 35.39 || 0.244 || 145 || 1836 || 128 ||
|-
| GTX260 || 35.91 || 0.178 || 202 || 1242 || 192 ||
|-
| GTX260 || 44 || 0.242 || 182 || 1242 || 216 || [http://www.bitcoin.org/smf/index.php?topic=1628.msg24699#msg24699 source]
|-
| GTX260c216 || 40.40 || 0.236 || 171 || 1242 || 216 ||
|-
| GTX260c216 OC || 52.0 || || || 1461 || 216 || "poclbm -w 256 -f 1"
|-
| GTX275 || 50.75 || 0.232 || 219 || 1404 || 240 ||
|-
| GTX275 || 58 || || || 729/1458 || 240 || poclbm -f 0 -w 256
|-
| GTX280 || 46.84 || 0.198 || 236 || 1296 || 240 ||
|-
| GTX285 || 53.35 || 0.262 || 204 || 1476 || 240 ||
|-
| GTX295 || 89.78 || 0.311 || 289 || 1242 || 480 ||
|-
| GT 320M (MacBook Air) || 6.12 || || || 1212 || 48 ||
|-
| GT 330M (Sony Vaio Z) || 7.8 || 0.71 ( 0.3 total) || 11 (26w total) || 1045 || 48 ||
|-
| GT430 || 20.24 || 0.413 || 49 || 1400 || 96 ||
|-
| GTS450 || 45.28 || 0.427 || 106 || 1566 || 192 ||
|-
| GTX460SE || 56.39 || 0.376 || 150 || 1300 || 288 ||
|-
| GTX460 || 68.31 || 0.427 || 160 || 1350 || 336 ||
|-
| GTX460 (2 cards) || 102 || 0.319? || 320? || 1350 || || [http://www.bitcoin.org/smf/index.php?topic=1628.msg26363#msg26363 source]
|-
| GTX460 (2 cards) OC || 127 || 0.374 || 340 || 1620 || 2x 336 || [http://www.bitcoin.org/smf/index.php?topic=2444.0 rpcminer-cuda] -gpugrid=128 -gputhreads=128 ver.20110227
|-
| GTX465 || 64.41 || 0.322 || 200 || 1215 || 352 ||
|-
| GTX470 || 81.98 || 0.381 || 215 || 1215 || 448 ||
|-
| GTX470 || 94.7 || || || 1414 || ||
|-
| GTX480 || 101.28 || 0.405 || 250 || 1401 || 480 ||
|-
| GTX560 Ti || 67.7 || 0.39 || 170 || 1700 || 384 || standard EVGA 560, no overclock
|-
| GTX560 OC || 86.7 || <0.51 || >170 || 1800 || 384 || [http://www.bitcoin.org/smf/index.php?topic=2444.0 rpcminer-cuda] [http://www.bitcoin.org/smf/index.php?topic=4967.msg72816#msg72816 source]
|-
| GTX570 || 105.83 || 0.483 || 219 || 1464 || 480 ||
|-
| GTX580 || 119.06 || 0.488 || 244 || 1544 || 512 ||
|-
| Quadro FX 580 || 5.7 || 0.14 || 40 || 1125 || 4 ||
|-
| Quadro FX 1600M || 6 || 0.12 || 50 || 625 || 32 ||rpcminer-cuda, Win
|-
| Quadro NVS 135M || 1.05 || 0.1 || 10 || 800 || 1 ||
|-
| Quadro NVS 3100M || 3.6 || 0.257 || 14 || 600 || 16 || rpcminer-cuda, Win, CUDA 3.1.1
|-
|}

==CPUs==

A lot of nice data can be pulled from [http://www.bitcoin.org/smf/index.php?topic=1628.0 this thread] to seed this section. Also from [https://www.bitcoin.org/wiki/doku.php?id=bitcoin_miners this page on the old wiki].

===AMD===
{| class="wikitable sortable"
|-
! Model !! nprocs !! Mhash/s !! Mhash/W !! ACP [W] !! Clock !! Version !! Comment
|-
| 2x Opteron 6128 || 16 || 32.4 || 0.203 || 160W || 2 GHz || 0.3.19 || -4way
|-
| Athlon X2 3800+ || 2 || 1.73 || 0.03 || 65 W || 2.00 GHz || cpuminer (v0.8.1-1-g69529c3) || -algo=4way
|-
| Athlon X2 4000+ || 2 || 1.9 || 0.02 || 65W || 2.1 GHz || rpc-miner ||
|-
| Athlon X2 4400+ || || 2.09 || 0.32 || 65W || 2.3GHz || 0.3.19/Win x64 || [http://www.bitcoin.org/smf/index.php?topic=1628.msg37592#msg37592 source]
|-
| Athlon X2 6000+ || 2 || 2.81 || 0.02 || 125W || 3 GHz || || [http://www.bitcoin.org/smf/index.php?topic=1628.msg22881#msg22881 source]
|-
| Athlon X2 6400+ Black Edition || 2 || 2.9 || 0.023 || 125W || 3.2 GHz || 0.3.20.2 BETA/Win 7 x64 || -4way
|-
| Athlon XP 2000+ || 2 || 0.62 || 0.009 || 70W || 1.67 GHz || 0.3.18/Ubuntu || [http://www.bitcoin.org/smf/index.php?topic=1628.msg37592#msg37592 source] [http://www.pcstats.com/articleview.cfm?articleid=914&page=4 source]
|-
| Athlon II X2 240e || 2 || 2.71 || 0.06 || 45W || 2.81 GHz || bitcoind || [http://www.bitcoin.org/smf/index.php?topic=1628.msg19426#msg19426 source]
|-
| Athlon II X4 630 || 4 || 10.7 || 0.11 || 95W || 2.8 GHz || bitcoin-miner 0.4 ||
|-
| Phenom II X6 1055T || 6 || 15.84 || 0.13 || 125W || 2.82 GHz || bitcoind || [http://www.bitcoin.org/smf/index.php?topic=1628.msg19426#msg19426 source]
|-
| Phenom II X6 1100T || 6 || 22 || 0.176 || 125W || 3.82 GHz || bitcoin-miner || Aciid#bitcoin-dev
|-
| Phenom II X3 720 || 3 || 3.8 || 0.04 || 95W || 2.8 GHz || 0.3.1x/WinXP || [http://www.bitcoin.org/smf/index.php?topic=1628.msg24699#msg24699 source]
|-
| Phenom II X3 720 || 3 || 7.2 || 0.08 || 95W || 2.8 GHz || cpu-miner 0.2.1/WinXP || [http://www.bitcoin.org/smf/index.php?topic=1628.msg24699#msg24699 source]
|-
| Phenom II x4 955 || 4 || 11 || 0.09 || 125W || 3.2 GHz || rpcminer-4way ||
|}

===ARM===
{| class="wikitable sortable"
|-
! Model !! p/t !! Mhash/s !! Mhash/W !! ACP [W] !! Clock !! Version !! Comment
|-
| Cortex A8 || 1 || 0.125 || || || 0.6 GHz || cpuminer git (2011-03-26) || Nokia N900: 'cryptopp'
|-
| Cortex A8 || 1 || 0.2 || || || 0.6 GHz || cpuminer git (2011-03-26) || Nokia N900: 'c' algo
|}

===Intel===
{| class="wikitable sortable"
|-
! Model !! p/t !! Mhash/s !! Mhash/W !! ACP [W] !! Clock !! Version !! Comment
|-
| Pentium III mobile ? || 1 || 0.3 || 0.014 || 21W || 1.07 GHz || 0.3.1x/Win2K || [http://www.bitcoin.org/smf/index.php?topic=1628.msg24699#msg24699 source] [http://ark.intel.com/Product.aspx?id=27380 source]
|-
| Old Xeon 512k (Dual) || 2x1/2 || 2.0 || ? || ? || 3.06GHz || cpuminer (v0.8.1-1-g69529c3) || HT disabled, algo=4way (twice as fast as the 2nd best algo)
|-
| Pentium 4 2.0A || 1 || 0.85 || || || 2.0 GHz || [http://www.bitcoin.org/smf/index.php?topic=3486.0 ufasoft-0.4]/WinXP || -g no -t 2
|-
| Pentium Dual-Core E5400 || 2/2 || 2.27 || 0.03 || 65W || 2.7 GHz || bitcoind || [http://www.bitcoin.org/smf/index.php?topic=1628.msg19426#msg19426 source]
|-
| Celeron E330 || 2/2 || 2.2 || 0.03 || 65W || 2.5 GHz || 0.3.19/Ubuntu10.04 || [http://www.bitcoin.org/smf/index.php?topic=1628.msg37620#msg37620 source]
|-
| Core i3 M350 || 2/4 || 1.48 || 0.04 || 35W || 2.27 GHz || bitcoind || [http://www.bitcoin.org/smf/index.php?topic=1628.msg19426#msg19426 source]
|-
| Core i5 M450 || 2/4 || 1.8 || 0.05 || 35W || 1.2 GHz || 0.3.17/Win7-54 || [http://www.bitcoin.org/smf/index.php?topic=1628.msg26292#msg26292 source]
|-
| Core i5-650 || 2/4 || 5.1 || 0.04 ? || || 3.2 GHz || cpuminer-0.7 || -4way
|-
| Core i5 ? || 4/? || 6.5 || || || || client from svn || [http://www.bitcoin.org/smf/index.php?topic=1628.msg37621#msg37621 source]
|-
| Core i5-2400 || 4/4 || 4.5 || 0.05 || 95W || 3.1 GHz || cpuminer git (2011-01-22) || cryptopp_asm32
|-
| Core i5-2400 || 4/4 || 14 || 0.15 || 95W || 3.1 GHz || cpuminer git (2011-03-26) || sse2_64
|-
| Core i7 920 || 4/8 || 19.2 || 0.10 || 195 || 4.0 GHz (x21) || [http://www.bitcoin.org/smf/index.php?topic=3486.0 ufasoft] || -a 5
|-
| Core i7 950 || 4/8 || 5.88 || 0.039 || 150W || 3.83 GHz (x23) || bitcoin-0.3.20.2 Win7-64 ||
|-
| Core i7 950 || 4/8 || 18.9 || 0.126 || 150W || 3.83 GHz (x23) || [http://www.bitcoin.org/smf/index.php?topic=3486.0 ufasoft] v0.4 ||
|-
| Core i7 980x || 6/12 || 19.2 || 0.15 || 130 || 4.4 GHz (x33) || cpuminer/Win7-64 ||
|-
| Core i7 980x || 6/12 || 8.7 || || || 3.9 GHz (x27) || 0.3.17/Win7-64 ||
|-
| Core i7 620M || 2/4 || 6.3 || 0.18 || 35 || 2.66 GHz || [http://www.bitcoin.org/smf/index.php?topic=3486.0 ufasoft] v0.4 ||
|-
| Core 2 Duo E6550 || 1/2 || 2.45 || ? || ? || 2.33 GHz || cpuminer 0.7.1 (Linux) || --algo=sse2_64
|-
| Core 2 Duo E6850 || 2/2 || 6.75 || 0.10 || 65W || 3.0 Ghz || ufasoft-0.3 ||
|-
| Core 2 Duo E7300 || 2/2 || 7.76 || 0.11 || 70W || 3.33 GHz (o/c?) || ufasoft-0.3 || miner optimized for Intel Core
|-
| Core 2 Duo E7300 || 2/2 || 2.52 || 0.04 || 65W || 2.66 GHz || bitcoind || [http://www.bitcoin.org/smf/index.php?topic=1628.msg19426#msg19426 source]
|-
| Xeon X5355 (dual) || 2x4/4 || 10.13 || 0.16 || 120W || 2.66GHz || bitcoind || Roughly the same speed as the "c" algo in cpuminer
|-
| Xeon X5355 (dual) || 2x4/4 || 22.76 || 0.09 || 120W || 2.66GHz || cpuminer (v0.8.1-1-g69529c3) || -O2 -march=core2, algo=sse2_64
|-
| Xeon E5440 || 4/8 || 7.3 || ? || 80W || 2.66 GHz|| Kiv's poclbm-gui || FIXME: Either wrong model # or wrong threads/speed info
|-
| Xeon E5520 || 4/8 || 6.5 || 0.08 || 80W || 2.27 GHz || bitcoind || [http://www.bitcoin.org/smf/index.php?topic=1628.msg19426#msg19426 source]
|-
| Xeon E5530 || 4/8 || 7.14 || 0.09 || 80W || 2.4 GHz || bitcoind || [http://www.bitcoin.org/smf/index.php?topic=1628.msg19426#msg19426 source]
|-
| Xeon E5630 (dual) || 2x4/8 || 8 || 0.1 || 80W || 2.53 GHz || 0.3.17/Win7-64 || [http://www.bitcoin.org/smf/index.php?topic=1628.msg29471#msg29471 source]
|-
| Atom N270 || 1 || 0.42 || '''0.17''' || 2.5W || 1.6 GHz || 0.3.1x/WinXP || [http://www.bitcoin.org/smf/index.php?topic=1628.msg24699#msg24699 source]
|}

==See Also==

* [[Mining rig]]
* [[OpenCL miner]]
* [http://www.pcper.com/article.php?aid=745 ATI Stream vs. NVIDIA CUDA - GPGPU computing battle royale]

[[Category:Mining]]