Bitcoin Wiki - User contributions [en]

Coinb.in

2018-06-01T16:35:52Z

OutCast3k: /* Features */

'''Coinb.in''' is a free and ''open source project'' released under the MIT license, originally by [https://bitcointalk.org/index.php?action=profile;u=34834 OutCast3k] in 2013.

Github: https://github.com/OutCast3k/coinbin/

TOR: 4zpinp6gdkjfplhk.onion

==Features==

* Offline Compressed & uncompressed [[Address]] creation.
* Offline [[Address#Multi-signature_addresses|Multisignature Address]] creation.
* [[Deterministic_wallet|HD]] ([[BIP 0032|BIP-32]]) support
* "In browser" Key (re)generation.
* Send and receive payments.
* Ability to decode transactions, redeem scripts and more offline.
* Build custom transactions offline.
* Sign transactions offline.
* Signatures are deterministic as per RFC 6979 (https://tools.ietf.org/html/rfc6979#section-3.2)
* Broadcast transactions.
* nLockTime support.
* Add custom data to transactions with the use of OP_RETURN.
* Support current [[DarkWallet]] Stealth Address structure (as of version Alpha 7) for outputs.
* [[Brainwallet|Brain wallet]] support.
* Compatible with bitcoin-qt
* An offical <code>.onion</code> address for tor users.
* Offline qrcode creator and scanning tool
* Fee calculator
* Segwit and Bech32 support

==Privacy==
Coinb.in believes strongly in privacy, not only does it support the use of TOR, the site also does not collect and store IP or transaction data via their servers.

==External links==
* [https://www.coinb.in Coinb.in website]
* [https://bitcoinmagazine.com/11108/multisig-future-bitcoin/ How To Create A Bitcoin Multisig Wallet]

[[Category:eWallets]]
[[Category:Wallets]]
[[Category:Services]]
[[Category:Shopping_Cart_Interfaces]]

Bech32 adoption

2018-05-27T19:18:12Z

OutCast3k: /* Web Wallets */

[[Bech32]] is a new bitcoin [[address]] format specified by [[BIP 0173]]. The BIP status was moved from <code>draft</code> to <code>proposed</code> on 3rd January 2018<ref>https://github.com/bitcoin/bips/commit/97a55878e61fd19b8e9eb68759a8dc902a1831a6</ref>. This page tracks the adoption of [[Bech32]].

Ideally wallets would first support ''sending to'' bech32 addresses. After almost every wallet can send then people may be willing to adopt bech32 widely for receiving.

The amount of bech32 addresses is tracked on this website: https://p2sh.info/dashboard/db/bech32-statistics?orgId=1

{| class="wikitable"
|-
| {{No}} ||
|-
| {{Evaluating|??}} || Maybe / Haven't checked / placeholder
|-
| {{Planned}} || The developers said they plan to
|-
| {{Acceptable|PR Merged}} || In the case of software, code has been written and merged, and it will be in next release.
|-
| {{Yes}} || Feature has been released
|}

=== Software Wallets ===
{| class="wikitable sortable"
|-
! Name !! Send to !! Create/receive !! Notes
|-
| Bitcoin Core || {{Yes}} || {{Yes}} ||
|-
| Bitcoin Knots || {{Yes}} || {{Yes}} ||
|-
| Electrum || {{Yes}} || {{Yes}} ||
|-
| Armory || {{Evaluating|??}} || {{No}} ||
|-
| JoinMarket || {{Yes}} || {{No}} ||
|-
| GreenAddress || {{Evaluating|??}} || {{No}} ||
|-
| Breadwallet || {{Yes}} || {{No}} || https://twitter.com/udiWertheimer/status/975810157941796864
|-
| Samourai Wallet || {{Yes}} || {{Yes}} ||
|-
| Coinomi || {{Yes}} || {{Yes}} || [https://www.reddit.com/r/Bitcoin/comments/865qn1/coinomi_wallet_beta_has_segwit_support/ reddit source]
|}

=== Hardware Wallets ===

Hardware wallet manufacturers typically publish a web wallet or browser add-on wallet for use with their hardware. Users can also sometimes connect their hardware wallet to a software wallet like [[Electrum]].

{| class="wikitable sortable"
|-
! Name !! Send to !! Create/receive !! Notes
|-
| Trezor web wallet || {{Acceptable|PR Merged}} || {{No}} ||
|-
| Ledger chrome app || {{No}} || {{No}} ||
|-
| KeepKey chrome app || {{No}} || {{No}} ||
|-
| Digital Bitbox Qt app || {{No}} || {{No}} ||
|-
| Trezor + Electrum || {{Yes}} || {{Yes}} ||
|-
| Ledger + Electrum || {{Yes}} || {{Yes}} ||
|-
| Digital Bitbox + Electrum || {{Yes}} || {{Yes}} ||
|-
| KeepKey + Electrum || {{No}} || {{No}} ||
|}

=== Web Wallets ===

{| class="wikitable sortable"
|-
! Name !! Send to !! Create/receive !! Notes
|-
| Coinapult || {{Evaluating|??}} || {{No}} ||
|-
| Coin.Space || {{Evaluating|??}} || {{No}} ||
|-
| BitGo || {{Evaluating|??}} || {{No}} ||
|-
| blockchain.info web wallet || {{Evaluating|??}} || {{No}} ||
|-
| HolyTransaction || {{Yes}} || {{No}} ||
|-
| [https://coinb.in Coinb.in] || {{Yes}} || {{Yes}} || open source JavaScript implementation
|}

=== Exchanges ===



{| class="wikitable sortable"
|-
! Name !! Send to !! Create/receive !! Notes
|-
| 1Fox || {{Yes}} || {{No}} || https://1fox.com/?c=en/content/blog&id=12
|-
| Anycoin Direct || {{Yes}} || {{No}} || https://anycoindirect.eu/en/news/details/segwit-activated
|-
| BitBargain.co.uk || {{Yes}} || {{No}} ||
|-
| Bitcoin.de || {{Evaluating|??}} || {{No}} ||
|-
| Bitfinex || {{No}} || {{No}} ||
|-
| BitMEX || {{Evaluating|??}} || {{No}} ||
|-
| Bittylicious || {{Yes}} || {{No}} || https://twitter.com/Bittylicious_/status/998881327347888128
|-
| Bitstamp || {{No}} || {{No}} ||
|-
| Bitwage || {{Evaluating|??}} || {{No}} ||
|-
| Bisq || {{Evaluating|??}} || {{No}} || https://github.com/bisq-network/bisq-desktop/issues/1139
|-
| Coinbase.com || {{Yes}} || {{No}} || https://twitter.com/diogorsergio/status/983052769262292992
|-
| Coinfloor || {{Evaluating|??}} || {{No}} ||
|-
| Flyp.me || {{Yes}} || {{No}} ||
|-
| GDax || {{Yes}} || {{No}} || https://www.reddit.com/r/Bitcoin/comments/8c738k/coinbase_gdax_already_allows_sending_to_bc1/
|-
| Genesis || {{Evaluating|??}} || {{No}} ||
|-
| Hodl Hodl || {{Yes}} || {{No}} || https://medium.com/@hodlhodl/hodl-hodl-segwit-compatible-exchange-a2231968ac56
|-
| Itbit || {{Evaluating|??}} || {{No}} ||
|-
| Kraken || {{Evaluating|??}} || {{No}} ||
|-
| Liberalcoins || {{Yes}} || {{Yes}} || https://liberalcoins.com
|-
| Localbitcoins.com || {{No}} || {{No}} ||
|}

==== Bitcoin ATM Models ====

Hopefully when a model updates then all its ATMs everywhere will gain that feature. See https://coinatmradar.com/shop/buy-bitcoin-atm/

{| class="wikitable sortable"
|-
! Name !! Send to !! Create/receive !! Notes
|-
| GenesisCoin || {{No}} || {{No}} ||
|-
| General Bytes || {{No}} || {{No}} ||
|-
| Lamassu Douro || {{No}} || {{No}} ||
|}

=== Blockchain Explorers ===

For trying these out you can use mainnet TXIDs <code>4ef47f6eb681d5d9fa2f7e16336cd629303c635e8da51e425b76088be9c8744c</code> and <code>514a33f1d46179b89e1fea7bbb07b682ab14083a276979f91038369d1a8d689b</code>. And addresses <code>bc1qar0srrr7xfkvy5l643lydnw9re59gtzzwf5mdq</code> and <code>bc1qc7slrfxkknqcq2jevvvkdgvrt8080852dfjewde450xdlk4ugp7szw5tk9</code>.

Some blockchain explorers can only parse the bech32 address and display it, they don't build an index so users cannot search for bech32 addresses.

See also: https://en.bitcoin.it/wiki/Category:Block_chain_browsers

{| class="wikitable sortable"
|-
! Name !! Display !! Index !! Notes
|-
| Blockchair || {{Yes}} || {{Yes}} || https://blockchair.com/
|-
| Blockonomics || {{Yes}} || {{Yes}} || https://www.blockonomics.co
|-
| Bitflyer || {{Yes}} || {{Yes}} || https://chainflyer.bitflyer.jp/
|-
| OXT || {{Yes}} || {{Yes}} || https://oxt.me/
|-
| blockchain.info || {{Yes}} || {{No}} ||
|-
| Insight || {{No}} || {{No}} || Open source explorer, instances are https://insight.bitpay.com/ and https://chain.localbitcoins.com/
|-
| Blockcypher || {{No}} || {{No}} || https://live.blockcypher.com/btc
|-
| Tradeblock || {{No}} || {{No}} || https://tradeblock.com/bitcoin
|}

=== Other Services ===

Casinos, marketplaces, etc that let users withdraw money

{| class="wikitable sortable"
|-
! Name !! Withdrawals !! Notes
|-
| 1Broker || {{Yes}} ||
|-
| Crypto-Games.net || {{Yes}} || [https://bitcointalk.org/index.php?topic=750760.msg31421151#msg31421151 bitcointalk source]
|-
| YOLOdice || {{Yes}} || A popular dice site https://yolodice.com
|}

=== References ===

[[Category:Software]]

Bech32 adoption

2018-05-27T14:40:23Z

OutCast3k: /* Web Wallets */

[[Bech32]] is a new bitcoin [[address]] format specified by [[BIP 0173]]. The BIP status was moved from <code>draft</code> to <code>proposed</code> on 3rd January 2018<ref>https://github.com/bitcoin/bips/commit/97a55878e61fd19b8e9eb68759a8dc902a1831a6</ref>. This page tracks the adoption of [[Bech32]].

Ideally wallets would first support ''sending to'' bech32 addresses. After almost every wallet can send then people may be willing to adopt bech32 widely for receiving.

The amount of bech32 addresses is tracked on this website: https://p2sh.info/dashboard/db/bech32-statistics?orgId=1

{| class="wikitable"
|-
| {{No}} ||
|-
| {{Evaluating|??}} || Maybe / Haven't checked / placeholder
|-
| {{Planned}} || The developers said they plan to
|-
| {{Acceptable|PR Merged}} || In the case of software, code has been written and merged, and it will be in next release.
|-
| {{Yes}} || Feature has been released
|}

=== Software Wallets ===
{| class="wikitable sortable"
|-
! Name !! Send to !! Create/receive !! Notes
|-
| Bitcoin Core || {{Yes}} || {{Yes}} ||
|-
| Bitcoin Knots || {{Yes}} || {{Yes}} ||
|-
| Electrum || {{Yes}} || {{Yes}} ||
|-
| Armory || {{Evaluating|??}} || {{No}} ||
|-
| JoinMarket || {{Yes}} || {{No}} ||
|-
| GreenAddress || {{Evaluating|??}} || {{No}} ||
|-
| Breadwallet || {{Yes}} || {{No}} || https://twitter.com/udiWertheimer/status/975810157941796864
|-
| Samourai Wallet || {{Yes}} || {{Yes}} ||
|-
| Coinomi || {{Yes}} || {{Yes}} || [https://www.reddit.com/r/Bitcoin/comments/865qn1/coinomi_wallet_beta_has_segwit_support/ reddit source]
|}

=== Hardware Wallets ===

Hardware wallet manufacturers typically publish a web wallet or browser add-on wallet for use with their hardware. Users can also sometimes connect their hardware wallet to a software wallet like [[Electrum]].

{| class="wikitable sortable"
|-
! Name !! Send to !! Create/receive !! Notes
|-
| Trezor web wallet || {{Acceptable|PR Merged}} || {{No}} ||
|-
| Ledger chrome app || {{No}} || {{No}} ||
|-
| KeepKey chrome app || {{No}} || {{No}} ||
|-
| Digital Bitbox Qt app || {{No}} || {{No}} ||
|-
| Trezor + Electrum || {{Yes}} || {{Yes}} ||
|-
| Ledger + Electrum || {{Yes}} || {{Yes}} ||
|-
| Digital Bitbox + Electrum || {{Yes}} || {{Yes}} ||
|-
| KeepKey + Electrum || {{No}} || {{No}} ||
|}

=== Web Wallets ===

{| class="wikitable sortable"
|-
! Name !! Send to !! Create/receive !! Notes
|-
| Coinapult || {{Evaluating|??}} || {{No}} ||
|-
| Coin.Space || {{Evaluating|??}} || {{No}} ||
|-
| BitGo || {{Evaluating|??}} || {{No}} ||
|-
| blockchain.info web wallet || {{Evaluating|??}} || {{No}} ||
|-
| HolyTransaction || {{Yes}} || {{No}} ||
|-
| [https://coinb.in Coinb.in] || {{Yes}} || {{Yes}} ||
|}

=== Exchanges ===



{| class="wikitable sortable"
|-
! Name !! Send to !! Create/receive !! Notes
|-
| 1Fox || {{Yes}} || {{No}} || https://1fox.com/?c=en/content/blog&id=12
|-
| Anycoin Direct || {{Yes}} || {{No}} || https://anycoindirect.eu/en/news/details/segwit-activated
|-
| BitBargain.co.uk || {{Yes}} || {{No}} ||
|-
| Bitcoin.de || {{Evaluating|??}} || {{No}} ||
|-
| Bitfinex || {{No}} || {{No}} ||
|-
| BitMEX || {{Evaluating|??}} || {{No}} ||
|-
| Bittylicious || {{Yes}} || {{No}} || https://twitter.com/Bittylicious_/status/998881327347888128
|-
| Bitstamp || {{No}} || {{No}} ||
|-
| Bitwage || {{Evaluating|??}} || {{No}} ||
|-
| Bisq || {{Evaluating|??}} || {{No}} || https://github.com/bisq-network/bisq-desktop/issues/1139
|-
| Coinbase.com || {{Yes}} || {{No}} || https://twitter.com/diogorsergio/status/983052769262292992
|-
| Coinfloor || {{Evaluating|??}} || {{No}} ||
|-
| Flyp.me || {{Yes}} || {{No}} ||
|-
| GDax || {{Yes}} || {{No}} || https://www.reddit.com/r/Bitcoin/comments/8c738k/coinbase_gdax_already_allows_sending_to_bc1/
|-
| Genesis || {{Evaluating|??}} || {{No}} ||
|-
| Hodl Hodl || {{Yes}} || {{No}} || https://medium.com/@hodlhodl/hodl-hodl-segwit-compatible-exchange-a2231968ac56
|-
| Itbit || {{Evaluating|??}} || {{No}} ||
|-
| Kraken || {{Evaluating|??}} || {{No}} ||
|-
| Liberalcoins || {{Yes}} || {{Yes}} || https://liberalcoins.com
|-
| Localbitcoins.com || {{No}} || {{No}} ||
|}

==== Bitcoin ATM Models ====

Hopefully when a model updates then all its ATMs everywhere will gain that feature. See https://coinatmradar.com/shop/buy-bitcoin-atm/

{| class="wikitable sortable"
|-
! Name !! Send to !! Create/receive !! Notes
|-
| GenesisCoin || {{No}} || {{No}} ||
|-
| General Bytes || {{No}} || {{No}} ||
|-
| Lamassu Douro || {{No}} || {{No}} ||
|}

=== Blockchain Explorers ===

For trying these out you can use mainnet TXIDs <code>4ef47f6eb681d5d9fa2f7e16336cd629303c635e8da51e425b76088be9c8744c</code> and <code>514a33f1d46179b89e1fea7bbb07b682ab14083a276979f91038369d1a8d689b</code>. And addresses <code>bc1qar0srrr7xfkvy5l643lydnw9re59gtzzwf5mdq</code> and <code>bc1qc7slrfxkknqcq2jevvvkdgvrt8080852dfjewde450xdlk4ugp7szw5tk9</code>.

Some blockchain explorers can only parse the bech32 address and display it, they don't build an index so users cannot search for bech32 addresses.

See also: https://en.bitcoin.it/wiki/Category:Block_chain_browsers

{| class="wikitable sortable"
|-
! Name !! Display !! Index !! Notes
|-
| Blockchair || {{Yes}} || {{Yes}} || https://blockchair.com/
|-
| Blockonomics || {{Yes}} || {{Yes}} || https://www.blockonomics.co
|-
| Bitflyer || {{Yes}} || {{Yes}} || https://chainflyer.bitflyer.jp/
|-
| OXT || {{Yes}} || {{Yes}} || https://oxt.me/
|-
| blockchain.info || {{Yes}} || {{No}} ||
|-
| Insight || {{No}} || {{No}} || Open source explorer, instances are https://insight.bitpay.com/ and https://chain.localbitcoins.com/
|-
| Blockcypher || {{No}} || {{No}} || https://live.blockcypher.com/btc
|-
| Tradeblock || {{No}} || {{No}} || https://tradeblock.com/bitcoin
|}

=== Other Services ===

Casinos, marketplaces, etc that let users withdraw money

{| class="wikitable sortable"
|-
! Name !! Withdrawals !! Notes
|-
| 1Broker || {{Yes}} ||
|-
| Crypto-Games.net || {{Yes}} || [https://bitcointalk.org/index.php?topic=750760.msg31421151#msg31421151 bitcointalk source]
|-
| YOLOdice || {{Yes}} || A popular dice site https://yolodice.com
|}

=== References ===

[[Category:Software]]

BTC Sender

2015-05-28T23:22:36Z

OutCast3k:

Allows a raw transaction in hex (i.e. characters 0-9, a-f) to be checked and if valid the transaction will be transmitted over the network.

Because bitcoin transactions are non-reversible, caution is advised when submitting hand-crafted transactions.

==History==

This service was first made available on November 7, 2011<ref>[http://bitcointalk.org/index.php?topic=50282.msg609962#msg609962 Webpage to paste raw tx for broadcast?]</ref>.

This service no longer works, you can use a similar service at [http://blockchain.info/pushtx blockchain.info] and [https://coinb.in/#broadcast coinb.in].

==External Links==

* [http://bitsend.rowit.co.uk BTC Sender] web site

==References==
<references />

[[Category:Services]]
[[Category:Technical]]

Transaction

2015-05-28T23:18:37Z

OutCast3k: /* See Also */

[[File:TxBinaryMap.png|thumb|right|Byte-map of Transaction with each type of TxIn and TxOut]]
A '''transaction''' is a transfer of Bitcoin value that is broadcast to the [[network]] and collected into [[block|blocks]]. A transaction typically references previous transaction outputs as new transaction inputs and dedicates all input Bitcoin values to new outputs. Transactions are not encrypted, so it is possible to browse and view every transaction ever collected into a block.

Standard transaction outputs nominate [[address|addresses]], and the redemption of any future inputs requires a relevant signature.

All transactions are visible in the [[block chain]], and can be viewed with a hex editor. A [[block chain browser]] is a site where every transaction included within the block chain can be viewed in human-readable terms. This is useful for seeing the technical details of transactions in action and for verifying payments.

=== general format of a Bitcoin transaction (inside a block) ===
{| class="wikitable"
|-
! Field
! Description
! Size
|-
|Version no
|currently 1
|4 bytes
|-
|In-counter
| positive integer [[ Protocol_specification#Variable_length_integer|VI = VarInt]]
| 1 - 9 bytes
|-
|list of inputs
|[[Transaction#general_format_.28inside_a_block.29_of_each_input_of_a_transaction_-_Txin|the first input of the first transaction is also called "coinbase" (its content was ignored in earlier versions)]]
|<in-counter>-many inputs
|-
|Out-counter
| positive integer [[ Protocol_specification#Variable_length_integer|VI = VarInt]]
| 1 - 9 bytes
|-
|list of outputs
|[[Transaction#general_format_.28inside_a_block.29_of_each_output_of_a_transaction_-_Txout|the outputs of the first transaction spend the mined bitcoins for the block]]
|<out-counter>-many outputs
|-
|lock_time
|if non-zero and sequence numbers are < 0xFFFFFFFF: block height or timestamp when transaction is final
|4 bytes
|}

=== Principle example of a Bitcoin transaction with 1 input and 1 output only ===

==== 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 from a previous transaction. Multiple inputs are often listed in a transaction. All of the new transaction's input values (that is, the total coin value of the previous outputs referenced by the new transaction's inputs) are added up, and the total (less any transaction fee) is completely used by the outputs of the new 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 must match the hash given in the script of the redeemed output. The public key is used to verify the redeemers signature, which is the second component. More precisely, the second 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 each output from one transaction can only ever be referenced once by an input of a subsequent transaction, 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 creates two 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]].

==== Pay-to-PubkeyHash ====

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

==== Pay-to-Script-Hash ====

scriptPubKey: OP_HASH160 <scriptHash> OP_EQUAL
scriptSig: ..signatures... <serialized script>

m-of-n multi-signature transaction:
scriptSig: 0 <sig1> ... <script>
script: OP_m <pubKey1> ... OP_n OP_CHECKMULTISIG

P2SH addresses were created with the motivation of moving "the responsibility for supplying the conditions to redeem a transaction from the sender of the funds to the redeemer. They allow the sender to fund an arbitrary transaction, no matter how complicated, using a 20-byte hash"[https://github.com/bitcoin/bips/blob/master/bip-0016.mediawiki#motivation 1]. Pay-to-Pubkey-hash addresses are similarly a 20-byte hash of the public key.

Pay-to-script-hash provides a means for complicated transactions, unlike the Pay-to-pubkey-hash, which has a specific definition for scriptPubKey, and scriptSig. The specification places no limitations on the script, and hence absolutely any contract can be funded using these addresses.

The scriptPubKey in the funding transaction is script which ensures that the script supplied in the redeeming transaction hashes to the script used to create the address.

In the scriptSig above, 'signatures' refers to any script which is sufficient to satisfy the following serialized script.

Checking process:
{| class="wikitable"
|-
! Stack
! Script
! Description
|-
|Empty.
| 0 <sig1> <sig2> OP_2 <pubKey1> <pubKey2> <pubKey3> OP_3 OP_CHECKMULTISIG
| Only the scriptSig is used.
|-
| 0 <sig1> <sig2> OP_2 <pubKey1> <pubKey2> <pubKey3> OP_3
| OP_CHECKMULTISIG
| Constants are added to the stack.
|-
| true
| Empty
| Signatures validated in the order of the keys in the script.
|}

See also [[BIP 0016]]

==== Generation ====

Generations have a single input, and this input has a "[[Coinbase |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.
The extranonce contributes to enlarge the domain for the proof of work function. Miners can easily modify nonce (4byte), timestamp and extranonce (2 to 100bytes).

=== general format (inside a block) of each input of a transaction - Txin ===
{| class="wikitable"
|-
! Field
! Description
! Size
|-
|Previous Transaction hash
| doubled [[Wikipedia:SHA-256|SHA256]]-[[hash|hashed]] of a (previous) to-be-used transaction
|32 bytes
|-
|Previous Txout-index
| non negative integer indexing an output of the to-be-used transaction
|4 bytes
|-
|Txin-script length
|non negative integer [[ Protocol_specification#Variable_length_integer|VI = VarInt]]
|1 - 9 bytes
|-
|Txin-script / scriptSig
|[[Script]]
|<in-script length>-many bytes
|-
|sequence_no
|normally 0xFFFFFFFF; irrelevant unless transaction's lock_time is > 0
|4 bytes
|}

The input sufficiently describes where and how to get the bitcoin amout to be redeemed.
If it is the (only) input of the first transaction of a block, it is called the generation transaction input and its content completely ignored. (Historically the Previous Transaction hash is 0 and the Previous Txout-index is -1.)

=== general format (inside a block) of each output of a transaction - Txout ===
{| class="wikitable"
|-
! Field
! Description
! Size
|-
|value
|non negative integer giving the number of [[FAQ#What_do_I_call_the_various_denominations_of_bitcoins.3F|Satoshis(BTC/10^8)]] to be transfered
|8 bytes
|-
|Txout-script length
|non negative integer
|1 - 9 bytes [[ Protocol_specification#Variable_length_integer|VI = VarInt]]
|-
|Txout-script / scriptPubKey
|[[Script]]
|<out-script length>-many bytes
|}
The output sets the conditions to release this bitcoin amount later. The sum of the output values of the first transaction is the value of the mined bitcoins for the block plus possible transactions fees of the other transactions in the block.

==See Also==

* [[Script]]
* [https://coinb.in/#newTransaction coinb.in's] raw transaction tool
* [[BTC Sender]] Transmit raw, hand-crafted transactions
* [[Raw Transactions]]
* [[Transaction Malleability]]

[[Category:Technical]]
[[Category:Vocabulary]]
[[de:Transaktion]]
[[es:Transacción]]
[[pl:Transakcje]]

Transaction

2015-05-28T23:17:54Z

OutCast3k: /* See Also */

[[File:TxBinaryMap.png|thumb|right|Byte-map of Transaction with each type of TxIn and TxOut]]
A '''transaction''' is a transfer of Bitcoin value that is broadcast to the [[network]] and collected into [[block|blocks]]. A transaction typically references previous transaction outputs as new transaction inputs and dedicates all input Bitcoin values to new outputs. Transactions are not encrypted, so it is possible to browse and view every transaction ever collected into a block.

Standard transaction outputs nominate [[address|addresses]], and the redemption of any future inputs requires a relevant signature.

All transactions are visible in the [[block chain]], and can be viewed with a hex editor. A [[block chain browser]] is a site where every transaction included within the block chain can be viewed in human-readable terms. This is useful for seeing the technical details of transactions in action and for verifying payments.

=== general format of a Bitcoin transaction (inside a block) ===
{| class="wikitable"
|-
! Field
! Description
! Size
|-
|Version no
|currently 1
|4 bytes
|-
|In-counter
| positive integer [[ Protocol_specification#Variable_length_integer|VI = VarInt]]
| 1 - 9 bytes
|-
|list of inputs
|[[Transaction#general_format_.28inside_a_block.29_of_each_input_of_a_transaction_-_Txin|the first input of the first transaction is also called "coinbase" (its content was ignored in earlier versions)]]
|<in-counter>-many inputs
|-
|Out-counter
| positive integer [[ Protocol_specification#Variable_length_integer|VI = VarInt]]
| 1 - 9 bytes
|-
|list of outputs
|[[Transaction#general_format_.28inside_a_block.29_of_each_output_of_a_transaction_-_Txout|the outputs of the first transaction spend the mined bitcoins for the block]]
|<out-counter>-many outputs
|-
|lock_time
|if non-zero and sequence numbers are < 0xFFFFFFFF: block height or timestamp when transaction is final
|4 bytes
|}

=== Principle example of a Bitcoin transaction with 1 input and 1 output only ===

==== 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 from a previous transaction. Multiple inputs are often listed in a transaction. All of the new transaction's input values (that is, the total coin value of the previous outputs referenced by the new transaction's inputs) are added up, and the total (less any transaction fee) is completely used by the outputs of the new 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 must match the hash given in the script of the redeemed output. The public key is used to verify the redeemers signature, which is the second component. More precisely, the second 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 each output from one transaction can only ever be referenced once by an input of a subsequent transaction, 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 creates two 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]].

==== Pay-to-PubkeyHash ====

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

==== Pay-to-Script-Hash ====

scriptPubKey: OP_HASH160 <scriptHash> OP_EQUAL
scriptSig: ..signatures... <serialized script>

m-of-n multi-signature transaction:
scriptSig: 0 <sig1> ... <script>
script: OP_m <pubKey1> ... OP_n OP_CHECKMULTISIG

P2SH addresses were created with the motivation of moving "the responsibility for supplying the conditions to redeem a transaction from the sender of the funds to the redeemer. They allow the sender to fund an arbitrary transaction, no matter how complicated, using a 20-byte hash"[https://github.com/bitcoin/bips/blob/master/bip-0016.mediawiki#motivation 1]. Pay-to-Pubkey-hash addresses are similarly a 20-byte hash of the public key.

Pay-to-script-hash provides a means for complicated transactions, unlike the Pay-to-pubkey-hash, which has a specific definition for scriptPubKey, and scriptSig. The specification places no limitations on the script, and hence absolutely any contract can be funded using these addresses.

The scriptPubKey in the funding transaction is script which ensures that the script supplied in the redeeming transaction hashes to the script used to create the address.

In the scriptSig above, 'signatures' refers to any script which is sufficient to satisfy the following serialized script.

Checking process:
{| class="wikitable"
|-
! Stack
! Script
! Description
|-
|Empty.
| 0 <sig1> <sig2> OP_2 <pubKey1> <pubKey2> <pubKey3> OP_3 OP_CHECKMULTISIG
| Only the scriptSig is used.
|-
| 0 <sig1> <sig2> OP_2 <pubKey1> <pubKey2> <pubKey3> OP_3
| OP_CHECKMULTISIG
| Constants are added to the stack.
|-
| true
| Empty
| Signatures validated in the order of the keys in the script.
|}

See also [[BIP 0016]]

==== Generation ====

Generations have a single input, and this input has a "[[Coinbase |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.
The extranonce contributes to enlarge the domain for the proof of work function. Miners can easily modify nonce (4byte), timestamp and extranonce (2 to 100bytes).

=== general format (inside a block) of each input of a transaction - Txin ===
{| class="wikitable"
|-
! Field
! Description
! Size
|-
|Previous Transaction hash
| doubled [[Wikipedia:SHA-256|SHA256]]-[[hash|hashed]] of a (previous) to-be-used transaction
|32 bytes
|-
|Previous Txout-index
| non negative integer indexing an output of the to-be-used transaction
|4 bytes
|-
|Txin-script length
|non negative integer [[ Protocol_specification#Variable_length_integer|VI = VarInt]]
|1 - 9 bytes
|-
|Txin-script / scriptSig
|[[Script]]
|<in-script length>-many bytes
|-
|sequence_no
|normally 0xFFFFFFFF; irrelevant unless transaction's lock_time is > 0
|4 bytes
|}

The input sufficiently describes where and how to get the bitcoin amout to be redeemed.
If it is the (only) input of the first transaction of a block, it is called the generation transaction input and its content completely ignored. (Historically the Previous Transaction hash is 0 and the Previous Txout-index is -1.)

=== general format (inside a block) of each output of a transaction - Txout ===
{| class="wikitable"
|-
! Field
! Description
! Size
|-
|value
|non negative integer giving the number of [[FAQ#What_do_I_call_the_various_denominations_of_bitcoins.3F|Satoshis(BTC/10^8)]] to be transfered
|8 bytes
|-
|Txout-script length
|non negative integer
|1 - 9 bytes [[ Protocol_specification#Variable_length_integer|VI = VarInt]]
|-
|Txout-script / scriptPubKey
|[[Script]]
|<out-script length>-many bytes
|}
The output sets the conditions to release this bitcoin amount later. The sum of the output values of the first transaction is the value of the mined bitcoins for the block plus possible transactions fees of the other transactions in the block.

==See Also==

* [[Script]]
* [https://coinb.in/#newTransaction coinb.ins] raw transaction tool
* [[BTC Sender]] Transmit raw, hand-crafted transactions
* [[Raw Transactions]]
* [[Transaction Malleability]]

[[Category:Technical]]
[[Category:Vocabulary]]
[[de:Transaktion]]
[[es:Transacción]]
[[pl:Transakcje]]

Transaction

2015-05-28T23:17:38Z

OutCast3k: /* See Also */

[[File:TxBinaryMap.png|thumb|right|Byte-map of Transaction with each type of TxIn and TxOut]]
A '''transaction''' is a transfer of Bitcoin value that is broadcast to the [[network]] and collected into [[block|blocks]]. A transaction typically references previous transaction outputs as new transaction inputs and dedicates all input Bitcoin values to new outputs. Transactions are not encrypted, so it is possible to browse and view every transaction ever collected into a block.

Standard transaction outputs nominate [[address|addresses]], and the redemption of any future inputs requires a relevant signature.

All transactions are visible in the [[block chain]], and can be viewed with a hex editor. A [[block chain browser]] is a site where every transaction included within the block chain can be viewed in human-readable terms. This is useful for seeing the technical details of transactions in action and for verifying payments.

=== general format of a Bitcoin transaction (inside a block) ===
{| class="wikitable"
|-
! Field
! Description
! Size
|-
|Version no
|currently 1
|4 bytes
|-
|In-counter
| positive integer [[ Protocol_specification#Variable_length_integer|VI = VarInt]]
| 1 - 9 bytes
|-
|list of inputs
|[[Transaction#general_format_.28inside_a_block.29_of_each_input_of_a_transaction_-_Txin|the first input of the first transaction is also called "coinbase" (its content was ignored in earlier versions)]]
|<in-counter>-many inputs
|-
|Out-counter
| positive integer [[ Protocol_specification#Variable_length_integer|VI = VarInt]]
| 1 - 9 bytes
|-
|list of outputs
|[[Transaction#general_format_.28inside_a_block.29_of_each_output_of_a_transaction_-_Txout|the outputs of the first transaction spend the mined bitcoins for the block]]
|<out-counter>-many outputs
|-
|lock_time
|if non-zero and sequence numbers are < 0xFFFFFFFF: block height or timestamp when transaction is final
|4 bytes
|}

=== Principle example of a Bitcoin transaction with 1 input and 1 output only ===

==== 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 from a previous transaction. Multiple inputs are often listed in a transaction. All of the new transaction's input values (that is, the total coin value of the previous outputs referenced by the new transaction's inputs) are added up, and the total (less any transaction fee) is completely used by the outputs of the new 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 must match the hash given in the script of the redeemed output. The public key is used to verify the redeemers signature, which is the second component. More precisely, the second 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 each output from one transaction can only ever be referenced once by an input of a subsequent transaction, 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 creates two 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]].

==== Pay-to-PubkeyHash ====

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

==== Pay-to-Script-Hash ====

scriptPubKey: OP_HASH160 <scriptHash> OP_EQUAL
scriptSig: ..signatures... <serialized script>

m-of-n multi-signature transaction:
scriptSig: 0 <sig1> ... <script>
script: OP_m <pubKey1> ... OP_n OP_CHECKMULTISIG

P2SH addresses were created with the motivation of moving "the responsibility for supplying the conditions to redeem a transaction from the sender of the funds to the redeemer. They allow the sender to fund an arbitrary transaction, no matter how complicated, using a 20-byte hash"[https://github.com/bitcoin/bips/blob/master/bip-0016.mediawiki#motivation 1]. Pay-to-Pubkey-hash addresses are similarly a 20-byte hash of the public key.

Pay-to-script-hash provides a means for complicated transactions, unlike the Pay-to-pubkey-hash, which has a specific definition for scriptPubKey, and scriptSig. The specification places no limitations on the script, and hence absolutely any contract can be funded using these addresses.

The scriptPubKey in the funding transaction is script which ensures that the script supplied in the redeeming transaction hashes to the script used to create the address.

In the scriptSig above, 'signatures' refers to any script which is sufficient to satisfy the following serialized script.

Checking process:
{| class="wikitable"
|-
! Stack
! Script
! Description
|-
|Empty.
| 0 <sig1> <sig2> OP_2 <pubKey1> <pubKey2> <pubKey3> OP_3 OP_CHECKMULTISIG
| Only the scriptSig is used.
|-
| 0 <sig1> <sig2> OP_2 <pubKey1> <pubKey2> <pubKey3> OP_3
| OP_CHECKMULTISIG
| Constants are added to the stack.
|-
| true
| Empty
| Signatures validated in the order of the keys in the script.
|}

See also [[BIP 0016]]

==== Generation ====

Generations have a single input, and this input has a "[[Coinbase |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.
The extranonce contributes to enlarge the domain for the proof of work function. Miners can easily modify nonce (4byte), timestamp and extranonce (2 to 100bytes).

=== general format (inside a block) of each input of a transaction - Txin ===
{| class="wikitable"
|-
! Field
! Description
! Size
|-
|Previous Transaction hash
| doubled [[Wikipedia:SHA-256|SHA256]]-[[hash|hashed]] of a (previous) to-be-used transaction
|32 bytes
|-
|Previous Txout-index
| non negative integer indexing an output of the to-be-used transaction
|4 bytes
|-
|Txin-script length
|non negative integer [[ Protocol_specification#Variable_length_integer|VI = VarInt]]
|1 - 9 bytes
|-
|Txin-script / scriptSig
|[[Script]]
|<in-script length>-many bytes
|-
|sequence_no
|normally 0xFFFFFFFF; irrelevant unless transaction's lock_time is > 0
|4 bytes
|}

The input sufficiently describes where and how to get the bitcoin amout to be redeemed.
If it is the (only) input of the first transaction of a block, it is called the generation transaction input and its content completely ignored. (Historically the Previous Transaction hash is 0 and the Previous Txout-index is -1.)

=== general format (inside a block) of each output of a transaction - Txout ===
{| class="wikitable"
|-
! Field
! Description
! Size
|-
|value
|non negative integer giving the number of [[FAQ#What_do_I_call_the_various_denominations_of_bitcoins.3F|Satoshis(BTC/10^8)]] to be transfered
|8 bytes
|-
|Txout-script length
|non negative integer
|1 - 9 bytes [[ Protocol_specification#Variable_length_integer|VI = VarInt]]
|-
|Txout-script / scriptPubKey
|[[Script]]
|<out-script length>-many bytes
|}
The output sets the conditions to release this bitcoin amount later. The sum of the output values of the first transaction is the value of the mined bitcoins for the block plus possible transactions fees of the other transactions in the block.

==See Also==

* [[Script]]
+ [https://coinb.in/#newTransaction coinb.ins] raw transaction tool
* [[BTC Sender]] Transmit raw, hand-crafted transactions
* [[Raw Transactions]]
* [[Transaction Malleability]]

[[Category:Technical]]
[[Category:Vocabulary]]
[[de:Transaktion]]
[[es:Transacción]]
[[pl:Transakcje]]

Coinb.in

2015-05-20T21:20:21Z

OutCast3k:

===Coinb.in===

'''Coinb.in''' is a free and ''open source project'' released under the MIT license, originally by [https://bitcointalk.org/index.php?action=profile;u=34834 OutCast3k] in 2013.

'''Github''': https://github.com/OutCast3k/coinbin/

'''TOR''': 4zpinp6gdkjfplhk.onion

===Features===

* Offline Compressed & uncompressed Address creation.
* Offline [[Address#Multi-signature_addresses|Multisignature Address]] creation.
* [[Deterministic_wallet|HD]] (bip32) support
* "In browser" Key (re)generation.
* Send and receive payments.
* Ability to decode transactions, redeem scripts and more offline.
* Build custom transactions offline.
* Sign transactions offline.
* Signatures are deterministic as per RFC 6979 (https://tools.ietf.org/html/rfc6979#section-3.2)
* Broadcast transactions.
* nLockTime support.
* Add custom data to transactions with the use of OP_RETURN.
* Support current Dark Wallet Stealth Address structure (as of version Alpha 7) for outputs.
* [[Brainwallet|Brain wallet]] support.
* Compatible with bitcoin-qt
* An offical .onion address for tor users.
* Offline qrcode creator and scanning tool

===Privacy===
Coinb.in beleives strongly in privacy, not only do does it support the use of TOR, the site does not collect and store IP or transaction data via their servers.

==External links==
* [https://www.coinb.in Coinb.in website]

[[Category:eWallets]]
[[Category:Wallets]]
[[Category:HD Wallet]]
[[Category:Multisig]]
[[Category:Services]]
[[Category:Shopping_Cart_Interfaces]]

Coinb.in

2015-05-20T21:16:46Z

OutCast3k:

===Coinb.in===

'''Coinb.in''' is a free and ''open source project'' released under the MIT license, originally by [https://bitcointalk.org/index.php?action=profile;u=34834 OutCast3k] in 2013.

'''Github''': https://github.com/OutCast3k/coinbin/

'''TOR''': 4zpinp6gdkjfplhk.onion

===Features===

* Offline Compressed & uncompressed Address creation.
* Offline [[Address#Multi-signature_addresses|Multisignature Address]] creation.
* [[Deterministic_wallet|HD]] (bip32) support
* "In browser" Key (re)generation.
* Send and receive payments.
* Ability to decode transactions, redeem scripts and more offline.
* Build custom transactions offline.
* Sign transactions offline.
* Signatures are deterministic as per RFC 6979 (https://tools.ietf.org/html/rfc6979#section-3.2)
* Broadcast transactions.
* nLockTime support.
* Add custom data to transactions with the use of OP_RETURN.
* Support current Dark Wallet Stealth Address structure (as of version Alpha 7) for outputs.
* [[Brainwallet|Brain wallet]] support.
* Compatible with bitcoin-qt
* An offical .onion address for tor users.
* Offline qrcode creator and scanning tool

===Privacy===
Coinb.in beleives strongly in privacy, not only do does it support the use of TOR, the site does not collect and store IP or transaction data via their servers.

==External links==
* [https://www.coinb.in Coinb.in website]

[[Category:eWallets]]
[[Category:Wallet]]
[[Category:HD Wallet]]
[[Category:Multisig]]
[[Category:Services]]
[[Category:Shopping_Cart_Interfaces]]

Deterministic wallet

2015-05-20T20:56:42Z

OutCast3k: /* Benefits */

A deterministic wallet is a system of deriving keys from a single starting point known as a seed. The seed allows a user to easily back up and restore a wallet without needing any other information and can in some cases allow the creation of public addresses without the knowledge of the private key.

== Benefits ==

Early clients such as the [[Satoshi client]] generate a buffer of fresh random private keys to be used as receiving and [[change|change addresses]] in the future. This has the effect of invalidating backups after a short period when the keypool buffer (typically 100 addresses) is exhausted. Deterministic wallets can generate an unlimited number of addresses on the fly and as such don't suffer from this issue. As the addresses are generated in a known fashion rather than randomly some clients can be used on multiple devices without the risk of losing funds. Users can conveniently create a single backup of the seed in a human readable format that will last the life of the wallet, without the worry of this backup becoming stale.

Certain types of deterministic wallet (BIP0032, Armory, [[Coinkite]] and [https://coinb.in/#newHDaddress Coinb.in] ) additionally allow for the complete separation of private and public key creation for greater security and convenience. In this model a server can be set up to only know the Master Public Key of a particular deterministic wallet. This allows the server to create as many public keys as is necessary for receiving funds, but a compromise of the MPK will not allow an attacker to spend from the wallet. They can alternatively be used in [[Electrum]] and [[Armory]] to enable completely offline storage and spending, where an offline computer knows the private key and an online one knows only the MPK. Transactions spending coins are ferried between the two computers via USB storage which avoids exposing the offline computer to a network-based attack.

Deterministic wallets implemented by hardware wallets ([[TREZOR]]) keep the generated private keys offline and do not expose them to the computer even when spending coins.

==Types==

===Type 1 deterministic wallet===
A type 1 deterministic wallet is a simple method of generating addresses from a known starting string, as such it does not allow advanced features such as a Master Public Key. To generate a private key take SHA256(string + n), where n is an ASCII-coded number that starts from 1 and increments as additional keys are needed.

This type of wallet can be created by Casascius Bitcoin Address Utility.

===Type 2 hierarchical deterministic wallet===
This wallet type is described in [[BIP 0032]] and is fully implemented in [[TREZOR]], [[Electrum]] and [[CarbonWallet]]. The seed is a random 128 bit value presented to the user as a 12 word mnemonic using common English words. The seed is used after 100,000 rounds of SHA256 to slow down attacks against weak user-chosen strings. [https://bitcointalk.org/index.php?topic=330672.msg3547258#msg3547258].

The initial description and workings of this wallet type is credited to Gregory Maxwell. [https://bitcointalk.org/index.php?topic=19137.msg239768#msg239768]

===Armory deterministic wallet===
[[Armory]] has its own Type-2 deterministic wallet format based on a "root key" and a "chain code." 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. This older format is intended to be phased out in favor of the standard BIP0032 format. [https://bitcointalk.org/index.php?topic=351099.msg3770818#msg3770818]

Wallet

2014-12-02T12:16:08Z

OutCast3k: Added coinb.in to wallet list

A Bitcoin '''wallet''' is a file that contains a collection of private keys.

=== Bitcoin Qt ===

The original Bitcoin [[Clients|client]] wallet file is named '''wallet.dat''' and contains<ref>[https://bitcointalk.org/index.php?topic=4448.0 Wallet import/export: bitkeys format]</ref>:

* keypairs for each of your [[address|addresses]]
* transactions done from/to your addresses
* user preferences
* default key
* reserve keys
* [[Accounts_explained|accounts]]
* a version number
* [[Key pool]]
* Since 0.3.21: information about the current best chain, to be able to rescan automatically when restoring from a backup.

The data file for the wallet is wallet.dat and is located in the [[data directory|Bitcoin data directory]].

It is intended that a wallet be used on only one installation of Bitcoin at a time. Attempting to clone a wallet for use on multiple computers will result in "weird behavior"<ref>[http://forum.bitcoin.org/index.php?topic=5324.msg77896#msg77896 Multiple instance of bitcoin with the same wallet]</ref>.

The format of this file is Berkeley DB. Tools that can manipulate wallet files include [[pywallet]].

=== [[Anonimcoin]] ===

[http://anonimcoin.com Anonimcoin.com] is online wallet with free bitcoin mixing service. Service has its own reserve of premixed coins, this method makes mixing instant. Recommend using with a socks, proxy or TOR to maximize anonymity.

=== [[Armory]] ===

The [[Armory]] client uses a custom [http://bitcoinarmory.com/developers/armory-wallet-files/ binary wallet format].

=== [[Bitcoin Wallet]] ===

[[File:bitcoin_wallet.png|192px]] Bitcoin Wallet uses the bitcoinj [http://code.google.com/p/protobuf/ protobuf] format for its wallet file. However, due to Android isolation of applications, it is impossible to access the wallet file as a non-root user.

=== Blockchain.info ===

Blockchain.info use a plain text JSON wallet format documented [https://blockchain.info/wallet/wallet-format here]. Private keys Keys are stored in base58.

=== [[Coinb.in]] ===

[http://coinb.in Coinb.in] is a javascript based bitcoin wallet with mutlisig functionality and other advanced features.

=== [[Coinkite]] ===

[[File:Coinkite.gif|20px|link=https://coinkite.com]] [https://coinkite.com/promo/wiki Coinkite] is a web wallet using [https://en.bitcoin.it/wiki/BIP_0032 "HD Wallet (BIP32)"] technology, which can be shared partially or entirely with different systems, each with or without the ability to spend coins [https://coinkite.com/faq here]. Private keys Keys are sent to you encrypted with AES-256-CBC.

=== [[Coinprism]] ===

[[File:Coinprism_Favicon.png|16px|link=https://www.coinprism.com]] [https://www.coinprism.com Coinprism] is the first [[Colored Coins]] web wallet. Coinprism is similar to other web wallets, except you can store, issue, send and receive colored coins and not only normal Bitcoins. Note that the site is currently in invite-only beta.

=== Email Tip Bot ===

[http://emailtipbot.com Email Tip Bot] is a wallet that works entirely through email. This makes it the only native solution to sending bitcoins on iOS devices, like the iPhone and iPad. It is secure against email spoofing, but can be compromised by anyone who has read access to your email.

=== [[Hive]] ===

[https://www.hivewallet.com Hive] is a lightweight "thin client" Bitcoin wallet for Mac OS X and soon in iOS, Web and Android. It is primarily based on bitcoinj focusing on ease-of-use that offers multi-currency support and many others.

=== [[HolyTransaction]] ===

[https://www.holytransaction.com HolyTransaction] is your universal multi-currency wallet with instant exchange. You can send payments in one digital currency, and receive in another. It's designed for nontechnical users. Mobile wallet client available on any device with HTML5 support.

=== Multibit ===

Multibit uses the bitcoinj [http://code.google.com/p/protobuf/ protobuf] wallet file.

==See Also==

* [[Securing your wallet]]
* [[EWallet]]
* [[Deterministic Wallet]]
* [http://bitcoinx.io/wallets Finding a Wallet]
* Third party [http://www.expresscoin.com/wallets Bitcoin Wallets] on [[expresscoin]]

==References==
<references />

BTC Sender

2014-12-02T00:38:03Z

OutCast3k:

Allows a raw transaction in hex (i.e. characters 0-9, a-f) to be checked and if valid the transaction will be transmitted over the network.

Because bitcoin transactions are non-reversible, caution is advised when submitting hand-crafted transactions.

==History==

This service was first made available on November 7, 2011<ref>[http://bitcointalk.org/index.php?topic=50282.msg609962#msg609962 Webpage to paste raw tx for broadcast?]</ref>.

This service no longer works, you can use a similar service at [http://blockchain.info/pushtx blockchain.info] and [http://coinb.in coinb.in].

==External Links==

* [http://bitsend.rowit.co.uk BTC Sender] web site

==References==
<references />

[[Category:Services]]
[[Category:Technical]]

Coinb.in

2011-08-24T22:57:15Z

OutCast3k:

Coinb.in (https://coinb.in) is an [[eWallet]] and bitcoin payment gateway that was launched in July 2011. It was designed for developers who had been looking to easily accept bitcoins via an unbranded interface at no fee.

==Features==
Coinb.in has a number of different features, some of which include;

* Automated registration and password reset.
* Automated withdrawals upon payment.
* Account transaction history.
* An easily accessible API that can output the results in various formats including; JSON, XML and a serialized PHP array.
* Supports the use of QRCodes.

==API==
Coinb.ins API includes several features, including:

* Lookup account balance.
* Lookup exchange rate.
* Send bitcoins.
* Transaction history.
* URL Callback feature.
* Address validation.
* Address generation.

==External links==
* [https://www.coinb.in Coinb.in website].
* [https://www.coinb.in/documentation.html Coinbin documentation].

[[Category:eWallets]]

Coinb.in

2011-08-24T18:01:01Z

OutCast3k: Created page with "Coinb.in (https://coinb.in) is an eWallet and bitcoin payment gateway that was launched in July 2011. It was designed for developers who had been looking to easily accept ..."