https://en.bitcoin.it/w/api.php?action=feedcontributions&feedformat=atom&user=PetertoddBitcoin Wiki - User contributions [en]2026-05-25T18:56:48ZUser contributionsMediaWiki 1.43.8https://en.bitcoin.it/w/index.php?title=User:Petertodd&diff=63593User:Petertodd2017-07-08T00:47:30Z<p>Petertodd: </p>
<hr />
<div> <nowiki>-----BEGIN PGP SIGNED MESSAGE-----<br />
Hash: SHA256<br />
<br />
As of July 7th 2017, the following user accounts are controlled by myself:<br />
<br />
https://en.bitcoin.it/wiki/User:Petertodd<br />
https://github.com/petertodd<br />
https://news.ycombinator.com/user?id=petertodd<br />
https://twitter.com/petertoddbtc<br />
https://www.reddit.com/user/petertodd<br />
<br />
-----BEGIN PGP SIGNATURE-----<br />
<br />
iQEcBAEBCAAGBQJZYCtUAAoJECSBQD2l8JH7a38H/RVdhqlurrt4TdgtIRB4izA3<br />
HbfWkzLEmN//FoKX0G4hVtqpjOqNB1L8oC0vKDW7JnRCfrGqHlAE2nMnlnbMMykg<br />
EzH5rT+ctx4Yd3mBEP3C4PxVahVcw+ACk0vO6/2gPcVGCvNWZugF5hsOqgf+fGyj<br />
itUrSAeArLtm8cK7ZpqSg8AyyClo/vguU5o1rPme4W7sAxKfeRSPSqmcQYE663Jf<br />
79vj5YqBFHi6V5Ze4P1N83IhDqaixCoh9KrjEf83MGLIaEQpGSarh8TDXsr+w0BN<br />
ZAIzyW1kg/mlXJ+BLlrka3rxZ/R5PuNX+xz/LT7rrCxBRBcMXb0RrWL8sHdwRw4=<br />
=ZSyX<br />
-----END PGP SIGNATURE-----<br />
</nowiki></div>Petertoddhttps://en.bitcoin.it/w/index.php?title=Segwit_support&diff=63592Segwit support2017-07-08T00:40:26Z<p>Petertodd: Update my preferences and affiliation</p>
<hr />
<div><big><big>'''PLEASE NOTE:''' This list is not yet complete.</big></big><br />
<br />
'''Developers/businesses: Please add a row for yourself in the applicable table to reflect your positions. If for some reason you don't already have a wiki account that can edit the page, make an account and ask luke-jr for help if you get caught in the anti-spam.'''<br />
<br />
{| class="wikitable"<br />
| {{No}} || doesn't support (but might or might not go along with it with sufficient community support)<br />
|-<br />
| {{Deficient}} || okay with the idea, but considers it to have insufficient community support<br />
|-<br />
| {{Evaluating}} || still evaluating the idea<br />
|-<br />
| {{AccJuly}} || it is a workable solution, provided it is activated before August 1 (and therefore BIP148-compatible)<br />
|-<br />
| {{Wanting}} || positively likes the idea, but considers it to have insufficient community support<br />
|-<br />
| {{Weak}} || better than nothing at all<br />
|-<br />
| {{Acceptable}} || it is a workable solution<br />
|-<br />
| {{Prefer}} || it is what he would choose if it was only up to him and no outside influences<br />
|}<br />
<br />
__TOC__<br />
<br />
==Developers==<br />
<br />
<!-- README: please keep alphabetically ordered by surname! --><br />
<br />
''Note that support for a given proposal does not mean developers support merging it into Core or any other specific codebase.''<br />
<br />
{| class="wikitable sortable"<br />
! rowspan=2 | Developer<br />
! rowspan=2 | Aff* <!-- Using one year before the the creation date of this page as the benchmark. Do not list yourself as affiliated with a project that you haven't made meaningful contributions to since then. --><br />
! Segwit itself<br />
! colspan=3 | Deployment methods<br />
! colspan=2 | Hardfork bundles (Silbert agreement)<br />
|-<br />
! [https://github.com/bitcoin/bips/blob/master/bip-0141.mediawiki BIP 141] !! [https://github.com/bitcoin/bips/blob/master/bip-0148.mediawiki BIP 148] !! [https://github.com/bitcoin/bips/blob/master/bip-0149.mediawiki BIP 149] !! [https://github.com/bitcoin/bips/blob/master/bip-0091.mediawiki BIP 91] || Segwit2x || [https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-May/014445.html COOP]<br />
|-<br />
| Karl-Johan Alm || Core || {{Prefer}} || {{Prefer}} || {{Acceptable}} || {{Acceptable}} || {{No}} || {{No}}<br />
|-<br />
| Bryan Bishop || || {{Prefer}} || {{Wanting}} || {{Acceptable}} || {{Weak}} || {{No}} || {{No}}<br />
|-<br />
| ฿tcDrak || Core || {{Prefer}} || {{Acceptable}} || {{Acceptable}} || {{No}} || {{No}} || {{No}}<br />
|-<br />
| Andrew Chow || Core || {{Prefer}} || {{Prefer}} || {{Acceptable}} || {{Weak}} || {{No}} || {{No}}<br />
|-<br />
| Wang Chun || [[F2Pool]] || {{Prefer}} || {{Acceptable}} || {{Acceptable}} || {{Acceptable}} || {{AccJuly}} ||<br />
|-<br />
| Matt Corallo || Core || {{Prefer}} || {{No}} || || {{Acceptable}} || {{No|LOL}} ||<br />
|-<br />
| Johnathan Corgan || Core || {{Prefer}} || {{Prefer}} || {{Acceptable}} || {{No}} || {{No}} || {{No}}<br />
|-<br />
| Luke Dashjr || Core || {{Prefer}} || {{Prefer}} || {{No}} || {{AccJuly}} || {{No}} || {{Deficient}}<br />
|-<br />
| Christian Decker || c-lightning || {{Prefer}} || {{Acceptable}} || || || || <br />
|-<br />
| Nicolas Dorier || Core || {{Prefer}} || {{Deficient}} || {{Acceptable}} || {{AccJuly}} || ||<br />
|-<br />
| Thaddeus Dryja || lit || {{Prefer}} || {{No}} || {{Acceptable}} || {{Acceptable}} || {{No}} || {{No}}<br />
|-<br />
| Marco Falke || Core || {{Prefer}} || {{Deficient}} || {{Prefer}} || {{Deficient}} || ||<br />
|-<br />
| Mark Friedenbach || BIP 68/112 || {{Prefer}} || {{Prefer}} || {{No}} || {{AccJuly}} || {{No|LOL}} || {{No|Nope}}<br />
|-<br />
| Pavel Janik || Core || {{Prefer}} || {{No}} || {{Acceptable}} || {{No}} || {{No}} || {{No}}<br />
|-<br />
| Thomas Kerin || Core || {{Prefer}} || {{Wanting}} || {{Prefer}} || {{Weak}} || {{No}} || {{No}}<br />
|-<br />
| Johnson Lau || Core || {{Prefer}} || {{Wanting}} || {{Acceptable}} || {{Acceptable}} || ||<br />
|-<br />
| Eric Lombrozo || || {{Prefer}} || {{Acceptable}} || {{Weak}} || {{AccJuly}} || {{No}} || {{No}}<br />
|-<br />
| Greg Maxwell || Core || {{Prefer}} || {{Deficient}} || {{Acceptable}} || {{Weak}} || {{No}} || {{No}}<br />
|-<br />
| Alex Morcos || Core || {{Prefer}} || {{Deficient}} || {{Acceptable}} || {{Weak}} || {{No}} ||<br />
|-<br />
| nopara73 || TumbleBit || {{Weak}} || {{Wanting}} || {{Prefer}} || || ||<br />
|-<br />
| Laolu "roasbeef" Osuntokun || lnd || {{Prefer}} || || || || {{No}} ||<br />
|-<br />
| Jeremy Rubin || Core || {{Prefer}} || {{Deficient}} || {{No}} || {{AccJuly}} || {{No}} || {{No}}<br />
|-<br />
| Pavol "stick" Rusnak || [[TREZOR]] || {{Prefer}} || {{Wanting}} || {{Acceptable}} || {{AccJuly}} || {{No}} || {{No}}<br />
|-<br />
| Rusty Russell || c-lightning || {{Prefer}} || {{Prefer}} || || || ||<br />
|-<br />
| Gregory Sanders || Core || {{Prefer}} || {{Wanting}} || {{Acceptable}} || {{Weak}} || {{No}} ||<br />
|-<br />
| Jonas Schnelli || Core || {{Prefer}} || {{Wanting}} || {{Acceptable}} || {{Acceptable}} || {{No}} || {{No}}<br />
|-<br />
| Patrick Strateman || Core || {{Prefer}} || || || || {{No}} || {{No}}<br />
|-<br />
| Paul Sztorc || || {{Prefer}} || {{Deficient}} || {{Wanting}} || {{AccJuly}} || {{Evaluating}} || {{No}}<br />
|-<br />
| Amir Taaki || libbtc || {{Acceptable}} || {{Prefer}} || || || {{No}} || {{No}} <br />
|-<br />
| Jorge Timon || Core || {{Prefer}} || {{No}} || {{Prefer}} || {{Deficient}} || {{No}} || {{No}}<br />
|-<br />
| Peter Todd || || {{Prefer}} || {{Deficient}} || {{Wanting}} || {{AccJuly}} || {{No|LOL}} ||<br />
|-<br />
| Warren Togami || Elements || {{Prefer}} || {{Prefer}} || {{Acceptable}} || || ||<br />
|-<br />
| Wladimir van der Laan || Core || {{Prefer}} || {{Prefer}} || {{Acceptable}} || {{Acceptable}} || {{No}} || {{No}}<br />
|-<br />
| Thomas Voegtlin || Electrum || {{Prefer}} || {{Prefer}} || {{Acceptable}} || {{Acceptable}} || {{No}} || {{No}}<br />
|-<br />
| Leo Wandersleb || Mycelium || {{Prefer}} || {{Prefer}} || {{Acceptable}} || {{Weak}} || {{AccJuly}} || {{No}}<br />
|-<br />
| Pieter Wuille || Core || {{Prefer}} || || || || {{No}} ||<br />
|}<br />
<br />
* "affiliation" is an optional field for the company or project the individual is associated with, that most qualifies the person to comment on the matter and is not meant as a company or project endorsement of the individual's position.<br />
<br />
==Businesses==<br />
<br />
'''When adding companies below, sources for each position MUST be provided.'''<br />
<br />
{| class="wikitable sortable"<br />
! rowspan=2 | Company <br />
! rowspan=2 | Service<br />
! Segwit itself<br />
! colspan=3 | Deployment methods<br />
! colspan=2 | Hardfork bundles (Silbert agreement)<br />
|-<br />
! [https://github.com/bitcoin/bips/blob/master/bip-0141.mediawiki BIP 141] !! [https://github.com/bitcoin/bips/blob/master/bip-0148.mediawiki BIP 148] !! [https://github.com/bitcoin/bips/blob/master/bip-0149.mediawiki BIP 149] !! [https://github.com/bitcoin/bips/blob/master/bip-0091.mediawiki BIP 91] || Segwit2x || [https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-May/014445.html COOP]<br />
|-<br />
| Abra || wallet || {{Prefer}}<ref name="coindance" /> || {{Prefer}}<ref name="coindance" /> || || {{AccJuly}} || {{AccJuly}}<ref name="silbert" /> ||<br />
|-<br />
| Bitcoin India || exchange/miner || {{Prefer}}<ref name="coindance" /> || {{Prefer}}<ref name="coindance" /> || || || ||<br />
|-<br />
| BitcoinReminder.com || service || {{Prefer}}<ref name="bitcoinreminder_com">[https://bitcoinreminder.com/informations/poli BitcoinReminder.com's position on scaling proposals]</ref> || {{Prefer}}<ref name="bitcoinreminder_com"/> || {{Acceptable}}<ref name="bitcoinreminder_com"/> || {{Weak}}<ref name="bitcoinreminder_com"/> || {{No|LOL}}<ref name="bitcoinreminder_com"/> || {{No}}<ref name="bitcoinreminder_com"/><br />
|-<br />
| Bitfinex || exchange || {{Acceptable}}<ref name="coindance" /> || {{Acceptable}} || || || ||<br />
|-<br />
| Bitfury || miner || {{Prefer}}<ref name="coindance" /> || {{Acceptable}} || || {{AccJuly}} || {{AccJuly}}<ref name="silbert" /> ||<br />
|-<br />
| Bitmain || miner || {{AccJuly}}<ref name="bitmain">[https://blog.bitmain.com/en/uahf-contingency-plan-uasf-bip148/ Bitmain's plot against BIP148]</ref> || {{No}} || || {{AccJuly}} || {{AccJuly}}<ref name="bitmain" /> ||<br />
|-<br />
| Bitonic/BL3P.eu || exchange || {{Prefer}}<ref name="bitonic">[https://bitonic.nl/en/news/138/our-position-on-scaling-proposals Bitonic's position on scaling proposals]</ref> || {{Prefer}}<ref name="bitonic"/> || {{Acceptable}}<ref name="bitonic"/> || {{Weak}}<ref name="bitonic"/> || {{No|LOL}}<ref name="bitonic"/> || {{No}}<br />
|-<br />
| Bitpay || wallet || {{Prefer}}<ref name="bccore_swadoption"/> || {{No}} || || {{Prefer}} || {{Prefer}}<ref name="silbert" /> ||<br />
|-<br />
| Bitrated || reputation || {{Acceptable}}<ref name="bitrated">[https://twitter.com/bitrated/status/876805892003553281]</ref> || {{Acceptable}}<ref name="bitrated" /> || {{Prefer}}<ref name="bitrated" /> || {{AccJuly}}<ref name="bitrated" /> || {{No}}<ref name="bitrated" /><ref>[https://medium.com/@shesek/why-i-dont-support-the-compromise-efforts-9d73a8cce6be Why I don’t support horse-trading compromises for Bitcoin protocol development]</ref> ||<br />
|-<br />
| Bitrefill || merchant || {{Prefer}}<ref name="coindance" /> || {{Prefer}}<ref name="coindance" /> || || || ||<br />
|-<br />
| Bitsquare || exchange || {{Prefer}} || {{Prefer}}<ref name="bitsquare">[https://forum.bitsquare.io/t/bitsquare-will-support-uasf-bitcoin-not-bitmaincoin/2265 Bitsquare will support UASF Bitcoin not BitMainCoin]</ref> || {{Acceptable}}<ref name="bitsquare"/> || || ||<br />
|-<br />
| Bitstamp || exchange || || || || || ||<br />
|-<br />
| Bittylicious || exchange || {{Prefer}}<ref name="coindance" /> || {{Prefer}}<ref>[https://twitter.com/Bittylicious_/status/867305106668224513 Bittylicious answer on Twitter]</ref> || || || ||<br />
|-<br />
| Blockchain.info || wallet || {{Acceptable}}<ref name="bccore_swadoption"/> || || || {{AccJuly}} || {{AccJuly}}<ref name="silbert" /> || <br />
|-<br />
| blockonomics || || {{Prefer}} || {{Prefer}}<ref>[https://twitter.com/blockonomics_co/status/851738251509497856 blockonomics announcement on Twitter]</ref> || || || ||<br />
|-<br />
| Bustabit|| gambling || {{Prefer}}<ref name="bustabit">[https://www.bustabit.com/statement-on-forks Bustabit Statement on Bitcoin Forks]</ref> || {{Acceptable}}<ref name="bustabit"/> || || || {{AccJuly}}<ref name="bustabit"/> ||<br />
|-<br />
| Bylls || payments / exchange || {{Prefer}}<ref name="bylls">[https://twitter.com/myBylls/status/877959773794316288 Bylls supports Segwit softfork but no current HF plan]</ref> || {{Prefer}}<ref name="bylls">[https://twitter.com/myBylls/status/877959773794316288 Bylls supports Segwit softfork but no current HF plan]</ref> || {{Acceptable}}<ref name="bylls">[https://twitter.com/myBylls/status/877965277316730880 Bylls twitter statement]</ref> || {{AccJuly}}<ref name="bylls">[https://twitter.com/myBylls/status/877965277316730880 Bylls twitter statement]</ref> || {{No}}<ref name="bylls">[https://twitter.com/myBylls/status/877965277316730880 Bylls twitter statement]</ref> || {{No}}<ref name="bylls">[https://twitter.com/myBylls/status/877965277316730880 Bylls twitter statement]</ref><br />
|-<br />
| Ciphrex || wallet / dev stack || {{Prefer}}<ref name="coindance" /> || {{Acceptable}}<ref name="coindance" /> || || || ||<br />
|-<br />
| Coinbase || wallet || {{Acceptable}}<ref name="bccore_swadoption"/> || || || {{AccJuly}} || {{AccJuly}}<ref name="silbert" /> || <br />
|-<br />
| CoinGate || exchange || {{Prefer}}<ref name="coindance" /> || {{Prefer}}<ref name="coindance" /> || || || ||<br />
|-<br />
| CoinJar || wallet || || {{Evaluating}}<ref>[https://twitter.com/GetCoinJar/status/875581525730787329 CoinJar answer on Twitter]</ref> || || || ||<br />
|-<br />
| Coinkite || || {{Prefer}}<ref name="coindance" /> || {{Prefer}}<ref name="coindance" /> || || || ||<br />
|-<br />
| coinomi || wallet || {{Prefer}}<ref name="coindance" /> || {{Prefer}}<ref name="coindance" /> || || || ||<br />
|-<br />
| DigitalBitbox || wallet(hardware) || {{Prefer}} || {{Acceptable}} || {{Prefer}}|| || ||<br />
|-<br />
| Échange de Montréal || exchange || {{Prefer}}<ref name="echangedemontreal" /> || {{Prefer}}<ref name="echangedemontreal" /> || || ||<br />
|-<br />
| Jaxx || || {{Prefer}}<ref name="jaxx">[https://twitter.com/Jaxx_Support/status/882607648457334785 Jaxx tweet]</ref> || {{Acceptable}}<ref name="jaxx"/> || || {{AccJuly}}<ref name="jaxx"/> || {{AccJuly}}<ref name="jaxx"/> ||<br />
|-<br />
| Kraken || exchange || || || || || ||<br />
|-<br />
| LightningASIC || miner || {{Prefer}}<ref name="coindance" /> || {{Prefer}}<ref name="coindance" /> || || || ||<br />
|-<br />
| OneHash || betting || {{Prefer}}<ref>[https://blog.onehash.com/sick-of-presidential-election-3f1a2defbbbf OneHash, "Sick of presidential election ?!"]</ref> || || || {{AccJuly}} || {{AccJuly}}<ref name="silbert" /> ||<br />
|-<br />
| Poloniex || exchange || || || || || ||<br />
|-<br />
|QUOINE || exchange, trading, financial services || {{Evaluating}}<ref name="coindance" /> || {{Evaluating}}<ref name="coindance" /> || {{Evaluating}}<ref name="coindance" /> || {{Evaluating}}<ref name="coindance" /> || {{Evaluating}}<ref name="coindance" /> || {{Evaluating}}<ref name="coindance" /> <br />
|-<br />
| Slushpool || miner || {{Prefer}}<ref name="coindance" /> || {{Acceptable}}<ref name="coindance" /> || || || ||<br />
|-<br />
| TheRockTrading || exchange || || {{Evaluating}}<ref>[https://twitter.com/TheRockTrading/status/872464394034315269 @TheRockTrading message on Twitter]</ref> || || || ||<br />
|-<br />
| Vaultoro || exchange || {{Prefer}}<ref name="coindance" /> || {{Acceptable}}<ref name="coindance" /> || || {{AccJuly}} || {{AccJuly}}<ref name="silbert" /> ||<br />
|-<br />
| Walltime || exchange || {{Prefer}}<ref name="coindance" /> || {{Prefer}}<ref name="coindance" /> || || || ||<br />
|-<br />
| Xapo || wallet || {{Prefer}}<ref name="coindance" /> || || || {{AccJuly}}<ref name="xapo">[https://twitter.com/tedmrogers/status/883061218545614848 Xapo tweet]</ref> || {{AccJuly}}<ref name="xapo"/> || <br />
|-<br />
|}<br />
<br />
<br />
<references><br />
<ref name="bccore_swadoption">[https://bitcoincore.org/en/segwit_adoption/ Bitcoin Core's Segwit adoption list]</ref><br />
<ref name="coindance">[https://coin.dance/poli Coin Dance, "Global Bitcoin Political Support & Public Opinion"]</ref><br />
<ref name="silbert">[https://medium.com/@DCGco/bitcoin-scaling-agreement-at-consensus-2017-133521fe9a77 Digital Currency Group, "Bitcoin Scaling Agreement at Consensus 2017"]</ref><br />
<ref name="echangedemontreal">[https://twitter.com/echangedemtl/status/875781093261271040 Échange de Montréal on twitter]</ref><br />
</references></div>Petertoddhttps://en.bitcoin.it/w/index.php?title=OP_CHECKSIG&diff=44233OP CHECKSIG2014-02-04T04:15:04Z<p>Petertodd: /* Procedure for Hashtype SIGHASH_SINGLE */ typo</p>
<hr />
<div>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. <br />
<br />
The standard scriptPubKey checks that the public key (actually a hash of) is a particular value, and that OP_CHECKSIG passes.<br />
<br />
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. <br />
<br />
== Parameters ==<br />
<br />
In addition to the script code itself and the stack parameters, to operate OP_CHECKSIG needs to know the current transaction and the index of current transaction input.<br />
<br />
== How it works ==<br />
Firstly always this (the default) procedure is applied:<br />
[[File:Bitcoin_OpCheckSig_InDetail.png|thumb|right|Signature verification process of the default procedure]]<br />
# the public key and the signature are popped from the stack, in that order. If the hash-type value is 0, then it is replaced by the last_byte of the signature. Then the last byte of the signature is always deleted.<br />
# 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)<br />
# The sig is deleted from subScript.<br />
# All OP_CODESEPARATORS are removed from subScript<br />
# The hashtype is removed from the last byte of the sig and stored<br />
# A copy is made of the current transaction (hereby referred to txCopy)<br />
# The scripts for all transaction inputs in txCopy are set to empty scripts (exactly 1 byte 0x00)<br />
# The script for the current transaction input in txCopy is set to subScript (lead in by its length as a var-integer encoded!)<br />
<br />
Now depending on the hashtype various things can happen to txCopy, these will be discussed individually.<br />
<br />
'''Hashtype Values (from script.h):'''<br />
{|class="wikitable"<br />
! Name !! Value<br />
|-<br />
| SIGHASH_ALL || 0x00000001<br />
|-<br />
| SIGHASH_NONE || 0x00000002<br />
|-<br />
| SIGHASH_SINGLE || 0x00000003<br />
|-<br />
| SIGHASH_ANYONECANPAY || 0x00000080<br />
|}<br />
<br />
<ol><br />
<li> If (hashtype&31) = SIGHASH_NONE then apply the SIGHASH_NONE-procedure<br />
<li> If (hashtype&31) = SIGHASH_SINGLE then apply the SIGHASH_SINGLE-procedure<br />
<li> If hashtype & SIGHASH_ANYONECANPAY then apply the SIGHASH_ANYONECANPAY-procedure<br />
</ol><br />
Hence, hashtype SIGHASH_ANYONECANPAY may be applied also after any other hashtype-procedure<ref>[http://sourceforge.net/projects/bitcoin/files/Bitcoin/bitcoin-0.7.1/bitcoin-0.7.1-linux.tar.gz file src/src/script.cpp in bitcoin-0.7.1]</ref>. Besides the four listed hashtypes only a hashtype of value 0 appears a few types in the (main) block chain (and is handled like SIGHASH_ALL).<br />
<br />
=== Hashtype SIGHASH_ALL (default) ===<br />
<br />
No special further handling occurs in the default case. Think of this as "sign '''all''' of the outputs." Which is already done by the default procedure.<br />
<br />
=== Procedure for Hashtype SIGHASH_NONE ===<br />
<br />
# The output of txCopy is set to a vector of zero size.<br />
# All other inputs aside from the current input in txCopy have their nSequence index set to zero<br />
<br />
Think of this as "sign '''none''' of the outputs-- I don't care where the bitcoins go."<br />
<br />
=== Procedure for Hashtype SIGHASH_SINGLE ===<br />
<br />
# The output of txCopy is resized to the size of the current input index+1.<br />
# 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.<br />
# All other txCopy inputs aside from the current input are set to have an nSequence index of zero.<br />
<br />
Think of this as "sign '''one''' of the outputs-- I don't care where the other outputs go".<br />
<br />
Note: The transaction that uses SIGHASH_SINGLE type of signature should not have more inputs than outputs.<br />
However if it does (because of the pre-existing implementation), it shall not be rejected, but instead for every "illegal" input (meaning: an input that has an index bigger than the maximum output index) the node should still verify it, though assuming the hash of 0000000000000000000000000000000000000000000000000000000000000001 [https://bitcointalk.org/index.php?topic=260595.0]<br />
<br />
=== Procedure for Hashtype SIGHASH_ANYONECANPAY ===<br />
<br />
# The txCopy input vector is resized to a length of one.<br />
# The subScript (lead in by its length as a var-integer encoded!) is set as the first and only member of this vector.<br />
<br />
Think of this as "Let other people add inputs to this transaction, I don't care where the rest of the bitcoins come from."<br />
<br />
===Final signature check===<br />
<br />
An array of bytes is constructed from the serialized txCopy appended by four bytes for the hash type. This array is sha256 hashed twice, then the public key is used to check the supplied signature against the hash.<br />
The secp256k1 elliptic curve is used for the verification with the given public key.<br />
<br />
== Return values ==<br />
<br />
OP_CHECKSIG will push true to the stack if the check passed, false otherwise.<br />
OP_CHECKSIG_VERIFY leaves nothing on the stack but will cause the script eval to fail immediately if the check does not pass.<br />
<br />
== Code samples and raw dumps ==<br />
<br />
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:<br />
<br />
* http://blockexplorer.com/block/00000000d1145790a8694403d4063f323d499e655c83426834d4ce2f8dd4a2ee<br />
* http://blockexplorer.com/tx/f4184fc596403b9d638783cf57adfe4c75c605f6356fbc91338530e9831e9e16<br />
<br />
See also [https://gitorious.org/libbitcoin/libbitcoin libbitcoin] for code samples.<br />
<br />
<pre><br />
01 00 00 00 version<br />
01 number of inputs (var_uint)<br />
<br />
input 0:<br />
c9 97 a5 e5 6e 10 41 02 input address hash<br />
fa 20 9c 6a 85 2d d9 06 <br />
60 a2 0b 2d 9c 35 24 23 <br />
ed ce 25 85 7f cd 37 04<br />
00 00 00 00 input index<br />
<br />
48 size of script (var_uint)<br />
47 push 71 bytes to stack<br />
30 44 02 20 4e 45 e1 69<br />
32 b8 af 51 49 61 a1 d3<br />
a1 a2 5f df 3f 4f 77 32<br />
e9 d6 24 c6 c6 15 48 ab<br />
5f b8 cd 41 02 20 18 15<br />
22 ec 8e ca 07 de 48 60<br />
a4 ac dd 12 90 9d 83 1c<br />
c5 6c bb ac 46 22 08 22<br />
21 a8 76 8d 1d 09 01<br />
ff ff ff ff sequence<br />
<br />
02 number of outputs (var_uint)<br />
<br />
output 0:<br />
00 ca 9a 3b 00 00 00 00 amount = 10.00000000<br />
43 size of script (var_uint)<br />
script for output 0:<br />
41 push 65 bytes to stack<br />
04 ae 1a 62 fe 09 c5 f5 <br />
1b 13 90 5f 07 f0 6b 99 <br />
a2 f7 15 9b 22 25 f3 74 <br />
cd 37 8d 71 30 2f a2 84 <br />
14 e7 aa b3 73 97 f5 54 <br />
a7 df 5f 14 2c 21 c1 b7 <br />
30 3b 8a 06 26 f1 ba de <br />
d5 c7 2a 70 4f 7e 6c d8 <br />
4c <br />
ac OP_CHECKSIG<br />
<br />
output 1:<br />
00 28 6b ee 00 00 00 00 amount = 40.00000000<br />
43 size of script (var_uint)<br />
script for output 1:<br />
41 push 65 bytes to stack<br />
04 11 db 93 e1 dc db 8a <br />
01 6b 49 84 0f 8c 53 bc <br />
1e b6 8a 38 2e 97 b1 48 <br />
2e ca d7 b1 48 a6 90 9a<br />
5c b2 e0 ea dd fb 84 cc <br />
f9 74 44 64 f8 2e 16 0b <br />
fa 9b 8b 64 f9 d4 c0 3f <br />
99 9b 86 43 f6 56 b4 12 <br />
a3 <br />
ac OP_CHECKSIG<br />
<br />
00 00 00 00 locktime<br />
01 00 00 00 hash_code_type (added on)<br />
<br />
result =<br />
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 <br />
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 <br />
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 <br />
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 <br />
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 <br />
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 <br />
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 <br />
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 <br />
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 <br />
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 <br />
01 00 00 00 <br />
</pre><br />
<br />
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],<br />
<br />
[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<br />
<br />
<source lang="cpp"><br />
#include <iostream><br />
#include <iomanip><br />
#include <bitcoin/util/serializer.hpp><br />
#include <bitcoin/util/elliptic_curve_key.hpp><br />
#include <bitcoin/util/sha256.hpp><br />
#include <bitcoin/util/assert.hpp><br />
#include <bitcoin/util/logger.hpp><br />
#include <bitcoin/types.hpp><br />
#include <openssl/ecdsa.h><br />
#include <openssl/obj_mac.h><br />
using libbitcoin::elliptic_curve_key;<br />
using libbitcoin::serializer;<br />
using libbitcoin::hash_digest;<br />
using libbitcoin::data_chunk;<br />
using libbitcoin::log_info;<br />
using libbitcoin::log_fatal;<br />
<br />
int main()<br />
{<br />
serializer ss;<br />
// blk number 170, tx 1, input 0<br />
// version = 1<br />
ss.write_4_bytes(1);<br />
// 1 inputs<br />
ss.write_var_uint(1);<br />
<br />
// input 0<br />
// prevout hash<br />
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});<br />
// prevout index <br />
ss.write_4_bytes(0);<br />
<br />
// input script after running OP_CHECKSIG for this tx is a single<br />
// OP_CHECKSIG opcode<br />
data_chunk raw_data;<br />
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};<br />
data_chunk raw_script;<br />
raw_script = data_chunk();<br />
raw_script.push_back(raw_data.size());<br />
libbitcoin::extend_data(raw_script, raw_data);<br />
raw_script.push_back(172);<br />
ss.write_var_uint(raw_script.size());<br />
ss.write_data(raw_script);<br />
// sequence<br />
ss.write_4_bytes(0xffffffff);<br />
<br />
// 2 outputs for this tx<br />
ss.write_var_uint(2);<br />
<br />
// output 0<br />
ss.write_8_bytes(1000000000);<br />
// script for output 0<br />
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};<br />
// when data < 75, we can just write it's length as a single byte ('special'<br />
// opcodes)<br />
raw_script = data_chunk();<br />
raw_script.push_back(raw_data.size());<br />
libbitcoin::extend_data(raw_script, raw_data);<br />
// OP_CHECKSIG<br />
raw_script.push_back(172);<br />
// now actually write the script<br />
ss.write_var_uint(raw_script.size());<br />
ss.write_data(raw_script);<br />
<br />
// output 1<br />
ss.write_8_bytes(4000000000);<br />
// script for output 0<br />
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};<br />
// when data < 75, we can just write it's length as a single byte ('special'<br />
raw_script.push_back(raw_data.size());<br />
libbitcoin::extend_data(raw_script, raw_data);<br />
// OP_CHECKSIG<br />
raw_script.push_back(172);<br />
// now actually write the script<br />
ss.write_var_uint(raw_script.size());<br />
ss.write_data(raw_script);<br />
<br />
// End of 2 outputs<br />
<br />
// locktime<br />
ss.write_4_bytes(0);<br />
<br />
// write hash_type_code<br />
ss.write_4_bytes(1);<br />
<br />
// Dump hex to screen<br />
log_info() << "hashing:";<br />
{<br />
auto log_obj = log_info();<br />
log_obj << std::hex;<br />
for (int val: ss.get_data())<br />
log_obj << std::setfill('0') << std::setw(2) << val << ' ';<br />
}<br />
log_info();<br />
<br />
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};<br />
BITCOIN_ASSERT(raw_tx == ss.get_data());<br />
<br />
hash_digest tx_hash = libbitcoin::generate_sha256_hash(ss.get_data());<br />
<br />
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};<br />
// Leave out last byte since that's the hash_type_code (SIGHASH_ALL in this<br />
// case)<br />
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};<br />
BITCOIN_ASSERT(signature.size() == 70);<br />
<br />
elliptic_curve_key key;<br />
if (!key.set_public_key(pubkey))<br />
{<br />
log_fatal() << "unable to set EC public key";<br />
return -1;<br />
}<br />
<br />
log_info() << "checksig returns: " << (key.verify(tx_hash, signature) ? "true" : "false");<br />
return 0;<br />
}<br />
<br />
</source><br />
<br />
==References==<br />
<references/><br />
<br />
[[Category:Technical]]<br />
[[Category:Developer]]</div>Petertoddhttps://en.bitcoin.it/w/index.php?title=Contract&diff=43732Contract2014-01-14T10:23:16Z<p>Petertodd: add warning about tx replacement</p>
<hr />
<div>A '''distributed contract''' is a method of using Bitcoin to form agreements with people via the block chain. Contracts don't make anything possible that was previously impossible, but rather, they allow you to solve common problems in a way that minimizes trust. Minimal trust often makes things more convenient by allowing human judgements to be taken out of the loop, thus allowing complete automation.<br />
<br />
By building low trust protocols that interact with Bitcoin, entirely new products can be created:<br />
<br />
* [[Smart Property|Smart property]] is property that can be atomically traded and loaned via the block chain.<br />
* [[Transferable virtual property]] are digital items that can be traded but not duplicated.<br />
* [[Agents]] are autonomous programs that maintain their own wallet, which they use to buy server time. Money is obtained by the agent selling services. If demand exceeds supply the agents can spawn children that either survive or die depending on whether they can get enough business.<br />
* [[Distributed markets]] are a way to implement peer to peer bond and stock trading, allowing Bitcoin to be evolve into a full competitor to the international financial system.<br />
* The [[Ripple currency exchange]] is a way to implement a distributed currency exchange based on social networks.<br />
<br />
This page also lists some smaller examples.<br />
<br />
Many of the ideas underlying Bitcoin contracts were first described by Nick Szabó in his seminal paper, <br />
[http://szabo.best.vwh.net/formalize.html Formalizing and Securing Relationships on Public Networks]. These pages were written by [mailto:mike@plan99.net Mike Hearn]. Contact him if you have an idea for a new type of contract. You can watch '''[https://www.youtube.com/watch?feature=player_embedded&v=mD4L7xDNCmA a video of a talk on contracts]''' that was presented at the Bitcoin 2012 conference in London.<br />
<br />
<br />
==A warning about the mempool transaction replacement mechanism==<br />
<br />
This page repeatedly refers to the obsolete and insecure nSequence-based transaction mempool replacement mechanism. This mechanism existed in very early versions of the Bitcoin sourcecode, but was not tested and did not work. It was disabled in [https://github.com/bitcoin/bitcoin/commit/401926283a200994ecd7df8eae8ced8e0b067c46 2010], and more recently the code has been [https://github.com/bitcoin/bitcoin/commit/98c7c8fd1d3712e02be0e9f2eeca7e02aa54d197 removed completely]. Mempool transaction replacement is a form of zero-conf transaction and is vulnerable to double-spending like any other zero-conf transaction is. The replacement mechanism is also trivially vulnerable to DoS attacks. Mike Hearn's views that replacement is a viable mechanism are not shared by other Bitcoin developers. Implementors should take this into account and create contract mechanisms that do not rely on mempool replacement if they wish to have their implementations work in the forseeable future. Finally, note that the nLockTime mechanism ''is'' supported in Bitcoin, and nLockTime-using transactions are accepted into the mempool and mined when the lock expires and then become final, and sequence numbers are still signed as described below by signatures, and nLockTime is disabled if all sequence numbers are equal to UINT_MAX.<br />
<br />
==Theory==<br />
<br />
Every [[transaction]] in Bitcoin has one or more inputs and outputs. Each input/output has a small, pure function associated with it called a [[script]]. Scripts can contain signatures over simplified forms of the transaction itself.<br />
<br />
Every transaction can have a lock time associated with it. This allows the transaction to be pending and replaceable until an agreed-upon future time, specified either as a block index or as a timestamp (the same field is used for both, but values less than 500 million are interpreted as a block index). If a transaction's lock time has been reached, we say it is final.<br />
<br />
Each transaction input has a sequence number. In a normal transaction that just moves value around, the sequence numbers are all UINT_MAX and the lock time is zero. If the lock time has not yet been reached, but all the sequence numbers are UINT_MAX, the transaction is also considered final. Sequence numbers can be used to issue new versions of a transaction without invalidating other inputs signatures, e.g., in the case where each input on a transaction comes from a different party, each input may start with a sequence number of zero, and those numbers can be incremented independently.<br />
<br />
Signature checking is flexible because the form of transaction that is signed can be controlled through the use of SIGHASH flags, which are stuck on the end of a signature. In this way, contracts can be constructed in which each party signs only a part of it, allowing other parts to be changed without their involvement. The SIGHASH flags have two parts, a mode and the ANYONECANPAY modifier:<br />
<br />
# SIGHASH_ALL: This is the default. It indicates that everything about the transaction is signed, except for the input scripts. Signing the input scripts as well would obviously make it impossible to construct a transaction, so they are always blanked out. Note, though, that other properties of the input, like the connected output and sequence numbers, ''are'' signed; it's only the scripts that are not. Intuitively, it means "I agree to put my money in, if everyone puts their money in and the outputs are this".<br />
# SIGHASH_NONE: The outputs are not signed and can be anything. Use this to indicate "I agree to put my money in, as long as everyone puts their money in, but I don't care what's done with the output". This mode allows others to update the transaction by changing their inputs sequence numbers.<br />
# SIGHASH_SINGLE: Like SIGHASH_NONE, the inputs are signed, but the sequence numbers are blanked, so others can create new versions of the transaction. However, the only output that is signed is the one at the same position as the input. Use this to indicate "I agree, as long as my output is what I want; I don't care about the others".<br />
<br />
The SIGHASH_ANYONECANPAY modifier can be combined with the above three modes. When set, only that input is signed and the other inputs can be anything.<br />
<br />
Scripts can contain the CHECKMULTISIG opcode. This opcode provides n-of-m checking: you provide multiple public keys, and specify the number of valid signatures that must be present. The number of signatures can be less than the number of public keys. An output can require two signatures to be spent by setting it to something like this:<br />
<br />
2 <pubkey1> <pubkey2> 2 CHECKMULTISIGVERIFY<br />
<br />
There are two general patterns for safely creating contracts:<br />
<br />
# Transactions are passed around outside of the P2P network, in partially-complete or invalid forms.<br />
# Two transactions are used: one (the contract) is created and signed but not broadcast right away. Instead, the other transaction (the payment) is broadcast after the contract is agreed to lock in the money, and then the contract is broadcast.<br />
<br />
This is to ensure that people always know what they are agreeing to.<br />
<br />
Together, these features let us build interesting new financial tools on top of the block chain.<br />
<br />
==Example 1: Providing a deposit==<br />
<br />
Imagine that you open an account on a website (eg, a forum or wiki) and wish to establish your trustworthiness with the operators, but you don't have any pre-existing reputation to leverage. One solution is to buy trust by paying the website some money. But if at some point you close your account, you'd probably like that money back. You may not trust the site enough to give them a deposit that they are tempted to spend. Another risk is that the site might just disappear one day. <br />
<br />
The goal is to prove that you made a sacrifice of some kind so the site knows you're not a spambot, but you don't want them to be able to spend the money. And if the operators disappear, you'd eventually like the coins back without needing anything from them.<br />
<br />
We can solve this problem with a contract:<br />
<br />
# The user and website send each other a newly-generated public key.<br />
# The user creates transaction Tx1 (the payment) putting 10 BTC into an output that requires both user and website to sign, but does not broadcast it. They use the key from the previous step for the site.<br />
# User sends the hash of Tx1 to the website.<br />
# The website creates a transaction Tx2 (the contract). Tx2 spends Tx1 and pays it back to the user via the address he provided in the first step. Note that Tx1 requires two signatures, so this transaction can't be complete. nLockTime is set to some date in the future (eg, six months). The sequence number on the input is set to zero.<br />
# Finally, the incomplete (half-signed) transaction is sent back to the user. The user checks that the contract is as expected - that the coins will eventually come back to him - but, unless things are changed, only after six months. Because the sequence number is zero, the contract can be amended in future if both parties agree. The script in the input isn't finished though; there are only zeros where the user's signature should be. He fixes that by signing the contract and putting the new signature in the appropriate spot.<br />
# The user broadcasts Tx1, then broadcasts Tx2.<br />
<br />
At this stage, the 10 BTC are in a state where neither the user nor the website can spend them independently. After six months, the contract will complete and the user will get the coins back, even if the website disappears.<br />
<br />
What if the user wishes to close his account early? The website creates a new version of Tx2 with nLockTime set to zero and the input sequence number set to UINT_MAX, then he re-signs it. The site hands the tx back to the user, who signs it as well. The user then broadcasts the transaction, terminating the contract early and releasing the coins.<br />
<br />
What if the six months is nearly up and the user wishes to keep his account? The same thing applies: the contract can be resigned with a newer nLockTime, a sequence number 1 higher than the previous and rebroadcast 2^32 times. No matter what happens, both parties must agree for the contract to change.<br />
<br />
Obviously, if the user turns out to be abusive (i.e., a spammer), the website will not allow an early close of the contract. If too much abuse is getting through, the size of the deposit can be raised or the length of the contract can be increased.<br />
<br />
==Example 2: Escrow and dispute mediation==<br />
<br />
A buyer wants to trade with somebody he doesn't know or trust. In the common case where the transaction goes well, the client doesn't want any third parties involved. If something goes wrong though, he'd like a third party to decide who gets the money - perhaps a professional dispute mediation service. Note that this concept can apply to either buyer or seller. The mediator might request proof of postage from the merchant, for example.<br />
<br />
In other words, one wants to lock up some coins so a third party has to agree in order for them to be spent:<br />
<br />
# Agree with the merchant on a dispute mediator (e.g., ClearCoin).<br />
# Ask the merchant for a public key (K1). Ask the mediator for a public key (K2). Create a new key for yourself (K3).<br />
# Send the merchant K2. The merchant challenges the mediator with a random nonce. The mediator signs the nonce with the private form of K2, thus proving it really belongs to merchant.<br />
# Create a transaction (Tx1) with an output script as follows and broadcast it:<br />
<br />
2 <K1> <K2> <K3> 3 CHECKMULTISIGVERIFY<br />
<br />
Now the coins are locked in such a way that they can only be spent by the following methods:<br />
<br />
# Client and the merchant agree (either a successful trade, or merchant agrees to reimburse client without mediation)<br />
# Client and the mediator agree (failed trade, mediator sides with client, like a charge-back)<br />
# The mediator and the merchant agree (goods delivered, merchant gets client's coins despite the dispute)<br />
<br />
When signing an input, the contents are set to the connected output. Thus, to redeem this transaction, the client creates a scriptSig containing zeros where the other signature should be, signs it, and then sets one of the slots to his new signature. The partially-complete transaction can then be sent to the merchant or mediator for the second signature.<br />
<br />
==Example 3: Assurance contracts==<br />
<br />
An [http://en.wikipedia.org/wiki/Assurance_contract assurance contract] is a way of funding the creation of a [http://www.auburn.edu/~johnspm/gloss/public_goods public good], that is, a good that, once created, anyone can benefit from for free. The standard example is a lighthouse: whilst everyone may agree that one should be built, it’s too expensive for an individual sailor to justify building one, given that it will also benefit all his competitors. <br />
<br />
One solution is for everyone to pledge money towards the creation of the public good, such that the pledges are only committed if the total value of all pledges is above the cost of creation. If not enough people contribute, nobody has to pay anything.<br />
<br />
Examples where Bitcoin is superior to traditional payment methods for assurance contract fundraising include applications where frequent, small pledges need to be made automatically, for instance internet radio station funding and [https://bitcointalk.org/index.php?topic=67255.msg788110#msg788110 web page translation]. Consider a browser extension that you send a bit of money to. It detects the current language of the page and broadcasts a pledge for a translation into your language to be prepared. If enough users with the extension land on the same page at the same time (eg, it was linked to from somewhere high traffic), then enough pledges are broadcast to trigger a payment to a company who prepares a high quality translation. When complete it automatically loads in your browser.<br />
<br />
We can model this in Bitcoin as follows:<br />
<br />
# An entrepreneur creates a new address and announces that the good will be created if at least 1000 BTC is raised. Anyone can contribute.<br />
# Each party wishing to pledge creates a new transaction spending some of their coins to the announced address, but they do not broadcast it. The transaction is similar to a regular transaction except for three differences: Firstly, there cannot be any change. If you don’t have any outputs of the right size, you must create one first by spending to one of your own addresses. Secondly, the input script signature is signed with SIGHASH_ALL | SIGHASH_ANYONECANPAY. Finally, the output value is set to 1000 BTC. Note that this is not a valid transaction because the output value is larger than the input value.<br />
# The transaction is uploaded to the entrepreneur's server, which saves it to disk and updates its count of how many coins have been pledged.<br />
# Once the server has enough coins, it merges the separate transactions together into a new transaction. The new transaction has a single output that simply spends to the announced address - it is the same as the outputs on each contributed transaction. The inputs to the transaction are collected from the contributed pledges.<br />
# The finished transaction is broadcast, sending the pledged coins to the announced address.<br />
<br />
This scheme relies on several aspects of the protocol. The first is the SIGHASH flags used. SIGHASH_ALL is the default and means the entire contents of the transaction are signed, except for the input scripts. SIGHASH_ANYONECANPAY is an additional modifier that means the signature only covers the input it’s found in - the other inputs are not signed and thus can be anything.<br />
<br />
By combining these flags together, we are able to create a signature that is valid even when other inputs are added, but breaks if the outputs or other properties of the transaction are changed.<br />
<br />
The second aspect we exploit is the fact that a transaction in which the output values are larger than the input values is invalid (for obvious reasons). This means it’s safe to send the entrepreneur a transaction that spends such coins - it’s impossible for him to claim the coins unless he has other inputs that sum to the output value or more.<br />
<br />
It's possible to create assurance contracts without using SIGHASH_ANYONECANPAY. Instead, a two step process is used in which pledges are collected without transactions, and once the total value is reached, a transaction with an input for each pledger is created and passed around until all signatures are collected. However, using SIGHASH_ANYONECANPAY and then merging is probably more convenient.<br />
<br />
An assurance contract can be prepared for '''[[Funding network security|funding network security]]''' for the next block. In this way, mining can be funded even if block space is not scarce.<br />
<br />
An elaboration of this concept is described by Tabarrok in his paper, [http://mason.gmu.edu/~atabarro/PrivateProvision.pdf “The private provision of public goods via dominant assurance contracts”]. In a dominant assurance contract, if a contract fails (not enough pledges within a set time window) the entrepreneur pays a fee to those who pledged so far. This type of contract attempts to arrange incentives such that taking part is always the right strategy. [[Dominant Assurance Contracts|A scheme for dominant assurance contracts]] in Bitcoin has been proposed.<br />
<br />
==Example 4: Using external state==<br />
<br />
Scripts are, by design, pure functions. They cannot poll external servers or import any state that may change as it would allow an attacker to outrun the block chain. What's more, the scripting language is extremely limited in what it can do. Fortunately, we can make transactions connected to the world in other ways.<br />
<br />
Consider the example of an old man who wishes to give an inheritance to his grandson, either on the grandson's 18th birthday or when the man dies, whichever comes first. <br />
<br />
To solve this, the man first sends the amount of the inheritance to himself so there is a single output of the right amount. Then he creates a transaction with a lock time of the grandson's 18th birthday that pays the coins to another key owned by the grandson, signs it, and gives it to him - but does not broadcast it. This takes care of the 18th birthday condition. If the date passes, the grandson broadcasts the transaction and claims the coins. He could do it before then, but it doesn't let him get the coins any earlier, and some nodes may choose to drop transactions in the memory pool with lock times far in the future.<br />
<br />
The death condition is harder. As Bitcoin nodes cannot measure arbitrary conditions, we must rely on an ''oracle''. An oracle is a server that has a keypair, and signs transactions on request when a user-provided expression evaluates to true.<br />
<br />
Here is an example. The man creates a transaction spending his output, and sets the output to:<br />
<br />
<hash> OP_DROP 2 <sons pubkey> <oracle pubkey> CHECKMULTISIG<br />
<br />
This is the oracle script. It has an unusual form - it pushes data to the stack then immediately deletes it again. The pubkey is published on the oracle's website and is well-known. The hash is set to be the hash of the user-provided expression stating that he has died, written in a form the oracle knows how to evaluate. For example, it could be the hash of the string:<br />
<br />
if (has_died('john smith', born_on=1950/01/02)) return (10.0, 1JxgRXEHBi86zYzHN2U4KMyRCg4LvwNUrp);<br />
<br />
This little language is hypothetical, it'd be defined by the oracle and could be anything. The return value is an output: an amount of value and an address owned by the grandson.<br />
<br />
Once more, the man creates this transaction but gives it directly to his grandson instead of broadcasting it. He also provides the expression that is hashed into the transaction and the name of the oracle that can unlock it.<br />
<br />
It is used in the following algorithm:<br />
<br />
# The oracle accepts a measurement request. The request contains the user-provided expression, a copy of the output script, and a partially complete transaction provided by the user. Everything in this transaction is finished except for the scriptSig, which contains just one signature (the grandson's) - not enough to unlock the output.<br />
# The oracle checks the user-provided expression hashes to the value in the provided output script. If it doesn't, it returns an error.<br />
# The oracle evaluates the expression. If the result is not the destination address of the output, it returns an error.<br />
# Otherwise the oracle signs the transaction and returns the signature to the user. Note that when signing a Bitcoin transaction, the input script is set to the connected output script. The reason is that when OP_CHECKSIG runs, the script containing the opcode is put in the input being evaluated, _not_ the script containing the signature itself. The oracle has never seen the full output it is being asked to sign, but it doesn't have to. It knows the output script, its own public key, and the hash of the user-provided expression, which is everything it needs to check the output script and finish the transaction.<br />
# The user accepts the new signature, inserts it into the scriptSig and broadcasts the transaction.<br />
<br />
If, and only if, the oracle agrees that the man is dead, the grandson can broadcast the two transactions (the contract and the claim) and take the coins.<br />
<br />
Oracles can potentially evaluate anything, yet the output script form in the block chain can always be the same. Consider the following possibilities:<br />
<br />
today() == 2011/09/25 && exchange_rate(mtgoxUSD) >= 12.5 && exchange_rate(mtgoxUSD) <= 13.5<br />
Require exchange rate to be between two values on a given date<br />
<br />
google_results_count(site:www.google.com/hostednews 'Mike Hearn' olympic gold medal) > 0<br />
A bet on me doing something that I will never actually do<br />
<br />
// Choose between one of two winners of a bet on the outcome of the Eurovision song contest.<br />
if (eurovision_winner() == 'Azerbaijan') <br />
return 1Lj9udBVDwptFffGSJSC2sohCfudQgSTPD; <br />
else <br />
return 1JxgRXEHBi86zYzHN2U4KMyRCg4LvwNUrp;<br />
<br />
The conditions that control whether the oracle signs can be arbitrarily complex, but the block chain never needs to contain more than a single hash.<br />
<br />
===Trust minimization: challenges===<br />
<br />
There are various ways to reduce the level of required trust in the oracle.<br />
<br />
Going back to our first example, the oracle has not seen the transaction the grandson is trying to unlock, as it was never broadcast, thus, it cannot hold the grandson to ransom because it does not know whether the transaction it's signing for even exists. People can, and should, regularly '''challenge''' the oracle in an automated fashion to ensure it always outputs what is expected. The challenges can be done without spending any coins because the tx to be signed can be invalid (ie, connected to transactions that don't exist). The oracle has no way to know whether a request to be signed is random or real. How to challenge the oracle with conditions that are not yet true is however an open research question. <br />
<br />
===Trust minimization: multiple independent oracles===<br />
<br />
The number of keys in the CHECKMULTISIG can be increased to allow for '''n-of-m''' oracles if need be. Of course, it is vital to check that the oracles really are independent and not in collusion.<br />
<br />
===Trust minimization: trusted hardware===<br />
<br />
Using commodity hardware, you can use '''trusted computing''' in the form of Intel TXT or the AMD equivalent (SKINIT) to set up a sealed hardware environment and then use the TPM chip to attest that fact to a third party. That third party can verify the hardware was in the required state. Defeating this requires someone to be able to interfere with the execution of a program that may run entirely on the CPU, even in extreme cases without any data traversing the memory bus (you can run entirely using on-die cache if the program is small enough).<br />
<br />
===Trust minimization: Amazon AWS oracles===<br />
<br />
Finally, perhaps the most practical approach currently is to use Amazon Web Services. As of November 2013, the closest we have to a working oracle is [https://bitcointalk.org/index.php?topic=301538.0 this recipe for creating a trusted computing environment using AWS], built in support of [https://bitcointalk.org/index.php?topic=173220.0 this project for doing selective SSL logging and decryption]. The idea is that an oracle, which can be proven trustworthy using the Amazon APIs with Amazon as the root of trust, records encrypted SSL sessions to an online banking interface in such a way that later if there is a dispute about a person-to-person exchange, the logs can be decrypted and the dispute settled.<br />
<br />
<br />
==Example 5: Trading across chains==<br />
<br />
The Bitcoin technology can be adapted to create [[Alternative chain|multiple, independent currencies]]. NameCoin is an example of one such currency that operates under a slightly different set of rules, and can also be used to rent names in a namespace. Currencies that implement the same ideas as Bitcoin can be traded freely against each other with limited trust. <br />
<br />
For example, imagine a consortium of companies that issue EURcoins, a crypto-currency that is backed 1:1 by deposits in the consortium's bank accounts. Such a currency would have a different set of tradeoffs to Bitcoin: more centralized, but without FX risk. People might wish to trade Bitcoins for EURcoins back and forth, with the companies only getting involved when cashing in/out of the regular banking system.<br />
<br />
To implement this, a [https://bitcointalk.org/index.php?topic=193281.msg2224949#msg2224949 protocol proposed by TierNolan] can be used:<br />
<br />
# Party 'A' generates some random data, x (the secret).<br />
# Party 'A' generates Tx1 (the payment) containing an output with the chain-trade script in it. See below for this script and a discussion of it. It allows coin release either by signing with the two keys (key 'A' and key 'B') or with (secret 'x', key 'B'). This transaction is not broadcast. The chain release script contains hashes, not the actual secrets themselves.<br />
# Party 'A' generates Tx2 (the contract), which spends Tx1 and has an output going back to key 'A'. It has a lock time in the future and the input has a sequence number of zero, so it can be replaced. 'A' signs Tx2 and sends it to 'B', who also signs it and sends it back.<br />
# 'A' broadcasts Tx1 and Tx2. Party 'B' can now see the coins but cannot spend them because it does not have an output going to him, and the tx is not finalized anyway.<br />
# 'B' performs the same scheme in reverse on the alternative chain. The lock time for 'B' should be much larger than the lock time for 'A'. Both sides of the trade are now pending but incomplete.<br />
# Since 'A' knows the secret, 'A' can claim his coins immediately. However, 'A', in the process of claiming his coin, reveals the secret 'x' to 'B', who then uses it to finish the other side of the trade with ('x', key 'B').<br />
<br />
This protocol makes it feasible to do trades automatically in an entirely peer-to-peer manner, which should ensure good liquidity.<br />
<br />
The chain-trade script could look like this:<br />
<br />
IF <br />
2 <key A> <key B> 2 CHECKMULTISIGVERIFY<br />
ELSE<br />
<key B> CHECKSIGVERIFY SHA256 <hash of secret x> EQUALVERIFY<br />
ENDIF<br />
<br />
The contract input script looks like either:<br />
<br />
<sig A> <sig B> 1<br />
<br />
or<br />
<br />
<secret x> <sig B> 0<br />
<br />
i.e., the first data element selects which phase is being used.<br />
<br />
See [[Atomic cross-chain trading]] for details.<br />
<br />
Note that whilst EURcoins is a natural idea, there are other ways to implement peer-to-peer currency exchange (Bitcoin to fiat and vice versa), see the [[Ripple currency exchange]] article for more information.<br />
<br />
Sergio Demian-Lerner proposed [https://bitcointalk.org/index.php?topic=91843.0 P2PTradeX], a solution requiring the validation rules for one blockchain to be effectively encoded into the validation rules for the other.<br />
<br />
==Example 6: Pay-for-proof contracts: buying a solution to any pure function==<br />
<br />
In example 4, we saw how to make payments conditional on the output of some arbitrary program. Those programs are very powerful and can do anything a regular program can do, like fetching web pages. The downside is that a third party is required (an oracle). Although there are techniques that can help reduce the trust needed in the oracle, none can reduce it to zero.<br />
<br />
For a restricted class of programs, pure functions, new cryptographic techniques are starting to become available that can actually reduce the trust needed all the way to zero with no third parties. These programs cannot perform any I/O, but in many cases this restriction turns out to be unimportant or can be worked around in other ways, like by giving the program a signed/timestamped document as an input instead of having the program download it.<br />
<br />
Read an explanation of the protocol here: [[User:Gmaxwell/why_hash_locked]]<br />
<br />
==Example 7: Rapidly-adjusted (micro)payments to a pre-determined party==<br />
<br />
Bitcoin transactions are very cheap relative to traditional payment systems, but still have a cost due to the need for it to be mined and stored. There are some cases in which you want to rapidly and cheaply adjust the amount of money sent to a particular recipient without incurring the cost of a broadcast transaction.<br />
<br />
For example, consider an untrusted internet access point, like a WiFi hotspot in a cafe you never visited before. You'd like to pay 0.001 BTC per 10 kilobytes of usage, without opening an account with the cafe. A zero-trust solution means it could be fully automatic, so you could just pre-allocate a budget on your phone's mobile wallet at the start of the month, and then your device automatically negotiates and pays for internet access on demand. The cafe also wants to allow anyone to pay them without the fear of being ripped off.<br />
<br />
To do this, the following protocol can be used. This protocol relies upon a '''different''' behavior of nLockTime to the original design. Starting around 2013 time-locked transactions were made non standard and no longer enter the memory pool, thus cannot be broadcast before the timelock expires. When the behaviour of nLockTime is restored to the original design from Satoshi, a variant of this protocol is required which is discussed below.<br />
<br />
We define the client to be the party sending value, and the server to be the party receiving it. This is written from the clients perspective.<br />
<br />
# Create a public key (K1). Request a public key from the server (K2). <br />
# Create and sign but do not broadcast a transaction (T1) that sets up a payment of (for example) 10 BTC to an output requiring both the server's public key and one of your own to be used. A good way to do this is use OP_CHECKMULTISIG. The value to be used is chosen as an efficiency tradeoff.<br />
# Create a refund transaction (T2) that is connected to the output of T1 which sends all the money back to yourself. It has a time lock set for some time in the future, for instance a few hours. Don't sign it, and provide the unsigned transaction to the server. By convention, the output script is "2 K1 K2 2 CHECKMULTISIG"<br />
# The server signs T2 using its public key K2 and returns the signature to the client. Note that it has not seen T1 at this point, just the hash (which is in the unsigned T2).<br />
# The client verifies the servers signature is correct and aborts if not.<br />
# The client signs T1 and passes the signature to the server, which now broadcasts the transaction (either party can do this if they both have connectivity). This locks in the money.<br />
# The client then creates a new transaction, T3, which connects to T1 like the refund transaction does and has two outputs. One goes to K1 and the other goes to K2. It starts out with all value allocated to the first output (K1), ie, it does the same thing as the refund transaction but is not time locked. The client signs T3 and provides the transaction and signature to the server.<br />
# The server verifies the output to itself is of the expected size and verifies the client's provided signature is correct.<br />
# When the client wishes to pay the server, it adjusts its copy of T3 to allocate more value to the server's output and less to its ow. It then re-signs the new T3 and sends the signature to the server. It does not have to send the whole transaction, just the signature and the amount to increment by is sufficient. The server adjusts its copy of T3 to match the new amounts, verifies the signature and continues.<br />
<br />
This continues until the session ends, or the 1-day period is getting close to expiry. The AP then signs and broadcasts the last transaction it saw, allocating the final amount to itself. The refund transaction is needed to handle the case where the server disappears or halts at any point, leaving the allocated value in limbo. If this happens then once the time lock has expired the client can broadcast the refund transaction and get back all the money.<br />
<br />
This protocol has [https://code.google.com/p/bitcoinj/wiki/WorkingWithMicropayments been implemented in bitcoinj].<br />
<br />
When nLockTime'd transactions are able to enter the memory pool (once more) and transaction replacement has been re-enabled, a variant on the protocol must be used. In this case, no refund transaction is used. Instead each T3 has a sequence number one higher than the previous and all T3's have a time lock set to the same period as above. Each time a payment is made the sequence number is incremented, ensuring that the last version will take precedence. If the channel protocol is not closed cleanly, this means the value transfer won't commit until the time lock expires. To avoid this both parties can cooperate by signing a T3 that has a sequence number of 0xFFFFFFFF resulting in immediate confirmation regardless of the value of nLockTime.<br />
<br />
The lock time and sequence numbers avoid an attack in which the AP provides connectivity, and then the user [[double-spending|double-spends]] the output back to themselves using the first version of TX2, thus preventing the cafe from claiming the bill. If the user does try this, the TX won't be included right away, giving the access point a window of time in which it can observe the TX broadcast, and then broadcast the last version it saw, overriding the user's attempted double-spend.<br />
<br />
The latter protocol that relies on transaction replacement is more flexible because it allows the value allocated to go down as well as up during the lifetime of the channel as long as the client receives signatures from the server, but for many use cases this functionality is not required. Replacement also allows for more complex configurations of channels that involve more than two parties. Elaboration on such use cases is a left as an exercise for the reader.<br />
<br />
==Example 8: Multi-party decentralised lotteries==<br />
<br />
Using some of the techniques from example 6 and some very advanced scripting, it becomes possible to build a multi-party lottery with no operator. The exact protocol used is explained in the paper [http://eprint.iacr.org/2013/784 "Secure multiparty computations on Bitcoin"]. A shorter explanation of how it works may be added to this wiki at some point in the future.<br />
<br />
<br />
==See Also==<br />
<br />
* [[Script]]<br />
<br />
[[Category:Technical]]</div>Petertoddhttps://en.bitcoin.it/w/index.php?title=Fidelity_bonds&diff=39785Fidelity bonds2013-07-25T18:05:02Z<p>Petertodd: /* Financial Services */ history</p>
<hr />
<div>A fidelity bond is a proposed mechanism where Bitcoins are deliberately sacrificed to make a cryptographic identity expensive to obtain. The sacrifice is done in a way that can be proven to a third party. By making the identity expensive it can be trusted not to commit unwanted acts, such as spamming message boards, or committing fraud, because upon detection of the unwanted acts the identity becomes useless, requiring the owner of the identity to purchase another one.<br />
<br />
== Mechanism ==<br />
<br />
The core of the fidelity bond is the sacrifice - the mechanism by which Bitcoins are provably taken from their original owner. The Bitcoins may be given to someone else or destroyed, but regardless it must not be possible for their original owner to regain control of them.<br />
<br />
An effective form of sacrifice is to simply create a transaction assigning the coins to an unspendable output, either an address known to not have a corresponding secret key, or to a scriptPubKey that is [[Script#Provably_Unspendable.2FPrunable_Outputs|provably unspendable]]. The Bitcoins are removed from circulation forever, a criticism of this mechanism.<br />
<br />
The Bitcoins can also be donated to a third party, such as a charity, however such donations can be controversial, allow the charity itself (or anyone with access to their funds) to purchase bonds at little or no cost, pose the problem of verifying the bonds validity in the future should the chosen charity(s) change, and finally, pose the problem of coming to a consensus on the charities themselves.<br />
<br />
In the context of Bitcoin, miners have been proposed as a third party whom any Bitcoin user can agree should receive funds, as miners act to secure the network from attack for everyone. The value is sacrificed to miners in the form of transaction fees.<br />
<br />
=== Single/Consecutive Block Sacrifices ===<br />
<br />
The sacrifice can be done with transactions that pay abnormally high fees, either single such transactions, or groups of multiple ones in a row, latter intended to prevent miners themselves from creating the sacrifices and mining them in their own blocks. Problems with consecutive transaction sacrifices include the potential for gaps, as well as the large size of the proofs of the sacrifices.<ref>[https://bitcointalk.org/index.php?topic=140711.msg1498806#msg1498806]</ref><br />
<br />
=== Announce/Commit Sacrifices ===<br />
<br />
To ensure that the miner collecting the sacrificed Bitcoin is picked at random the announce/commit sacrifice was proposed.<ref>[https://bitcointalk.org/index.php?topic=134827.0 Purchasing fidelity bonds by provably throwing away bitcoins]</ref> First a sacrifice transaction is prepared that either sacrifices value to transaction fees, or spends coins to an [[Script#Anyone-Can-Spend_Outputs|Anyone-Can-Spend Output]]. With [[nLockTime]] the transaction is made invalid until some time in the future.<br />
<br />
The second step is the announcement. The transaction is enclosed in another transaction as data, for instance by using a [[Script#Provably_Unspendable.2FPrunable_Outputs|prunable output]]. The announcement is then broadcast and is included in the blockchain, proving that anyone could have seen the inner transaction prior to it becoming valid.<br />
<br />
Finally the inner transaction becomes valid when the [[nLockTime]] is reached. Because mining is a random process, any miner can collect the value sacrified, and the purchaser of the fidelity bond has no control over where that value goes.<br />
<br />
The proof of the sacrifice is then two transactions: the proof the announcement transaction exists in the chain, and the proof that the inner sacrifice exists in the chain. (possibly with proof of the inner sacrifice inputs to prove what fees were actually paid)<br />
<br />
=== Coinbase TxOut Sacrifices ===<br />
<br />
Coinbase transactions are unique in that they can't be spent for 100 blocks, thus solving the problem of proving a transaction output was made public prior to it being possible to spend that output in a single transaction. In addition coinbase transactions can be created anonymously without linking the transaction to any other transaction provided that the creator has the ability to mine anonymously. (or have someone else do so on their behalf)<br />
<br />
A proof for a coinbase txout is particularly short if the txout is the last txout and the script is meant to be unspendable. SHA256 midstate compression can then be used to prove the committed digest, and that the last opcode was OP_RETURN; it is not possible for a script to return true unless without the last opcode being executed. Fortunately the anyone-can-spend version can-not be proven so easily - consider the following txout fragment:<br />
<br />
<SHA256 midstate> <scriptPubKey length> <digest> <nLockTime><br />
<br />
The problem is the fragment could actually be part of this scriptPubkey:<br />
<br />
<pubkey> OP_CHECKSIGVERIFY OP_PUSHDATA (<scriptPubKey length> <digest>)<br />
<br />
In reality this isn't a true sacrifice. The only way around this problem is if the proven data is greater than the maximum pushdata length allowed, 520 bytes, which undesirably depends on a constant whose value may be changed in a future hard-fork.<br />
<br />
== Passports ==<br />
<br />
This wiki combats spam, while still allowing for users to sign up anonymously, by requiring users to pay a small amount of Bitcoins to the wiki before editing privileges are granted. Creating large numbers of "sock-puppets" to add spam content to articles is thus made expensive. The fee approach can be generalized with the concept of a Passport, first proposed by Mike Hearn,<ref>[https://bitcointalk.org/index.php?topic=140711.0 Creating Bitcoin passports using sacrifices]</ref> tied to the users identity. Wikis, forums, webmail and other services can then create blacklists of users who violate the rules of the services, with those blacklists tied to passports.<br />
<br />
The advantage of fidelity bonds in that application over simply charging fees is re-usability of an identity across multiple services, as well as the neutrality: if the value required to create the passport provably does not go to the person adding the passport to a blacklist, there is no incentive to do so to collect new sign-up fees.<br />
<br />
== Financial Services ==<br />
<br />
Fidelity bonds can be used to make financial fraud unprofitable. For instance the original fidelity bond proposal<ref>[http://sourceforge.net/mailarchive/message.php?msg_id=29185108 Trusted identities]</ref> - called "Trusted identities" at that time - included the idea of using fidelity bonds to create decentralized [[Green address|green addresses]]. Someone wishing for their transactions to be accepted without confirmations would first purchase a fidelity bond of some value tied to their identity. Someone determining if they should accept a payment without confirmations can check that the bond was sufficiently expensive to make it unprofitable for the sender to commit fraud. If the sender does commit fraud by double-spending the payment, the recipient can prove that fraud to the world by providing both transactions spending the same inputs. This proof is added to some sort of blacklist, centralized or decentralized, which later recipients can consult to determine if the fidelity bond is now invalidated.<br />
<br />
== References ==<br />
<br />
<references/></div>Petertoddhttps://en.bitcoin.it/w/index.php?title=Fidelity_bonds&diff=39784Fidelity bonds2013-07-25T18:03:02Z<p>Petertodd: /* Financial Services */ spelling</p>
<hr />
<div>A fidelity bond is a proposed mechanism where Bitcoins are deliberately sacrificed to make a cryptographic identity expensive to obtain. The sacrifice is done in a way that can be proven to a third party. By making the identity expensive it can be trusted not to commit unwanted acts, such as spamming message boards, or committing fraud, because upon detection of the unwanted acts the identity becomes useless, requiring the owner of the identity to purchase another one.<br />
<br />
== Mechanism ==<br />
<br />
The core of the fidelity bond is the sacrifice - the mechanism by which Bitcoins are provably taken from their original owner. The Bitcoins may be given to someone else or destroyed, but regardless it must not be possible for their original owner to regain control of them.<br />
<br />
An effective form of sacrifice is to simply create a transaction assigning the coins to an unspendable output, either an address known to not have a corresponding secret key, or to a scriptPubKey that is [[Script#Provably_Unspendable.2FPrunable_Outputs|provably unspendable]]. The Bitcoins are removed from circulation forever, a criticism of this mechanism.<br />
<br />
The Bitcoins can also be donated to a third party, such as a charity, however such donations can be controversial, allow the charity itself (or anyone with access to their funds) to purchase bonds at little or no cost, pose the problem of verifying the bonds validity in the future should the chosen charity(s) change, and finally, pose the problem of coming to a consensus on the charities themselves.<br />
<br />
In the context of Bitcoin, miners have been proposed as a third party whom any Bitcoin user can agree should receive funds, as miners act to secure the network from attack for everyone. The value is sacrificed to miners in the form of transaction fees.<br />
<br />
=== Single/Consecutive Block Sacrifices ===<br />
<br />
The sacrifice can be done with transactions that pay abnormally high fees, either single such transactions, or groups of multiple ones in a row, latter intended to prevent miners themselves from creating the sacrifices and mining them in their own blocks. Problems with consecutive transaction sacrifices include the potential for gaps, as well as the large size of the proofs of the sacrifices.<ref>[https://bitcointalk.org/index.php?topic=140711.msg1498806#msg1498806]</ref><br />
<br />
=== Announce/Commit Sacrifices ===<br />
<br />
To ensure that the miner collecting the sacrificed Bitcoin is picked at random the announce/commit sacrifice was proposed.<ref>[https://bitcointalk.org/index.php?topic=134827.0 Purchasing fidelity bonds by provably throwing away bitcoins]</ref> First a sacrifice transaction is prepared that either sacrifices value to transaction fees, or spends coins to an [[Script#Anyone-Can-Spend_Outputs|Anyone-Can-Spend Output]]. With [[nLockTime]] the transaction is made invalid until some time in the future.<br />
<br />
The second step is the announcement. The transaction is enclosed in another transaction as data, for instance by using a [[Script#Provably_Unspendable.2FPrunable_Outputs|prunable output]]. The announcement is then broadcast and is included in the blockchain, proving that anyone could have seen the inner transaction prior to it becoming valid.<br />
<br />
Finally the inner transaction becomes valid when the [[nLockTime]] is reached. Because mining is a random process, any miner can collect the value sacrified, and the purchaser of the fidelity bond has no control over where that value goes.<br />
<br />
The proof of the sacrifice is then two transactions: the proof the announcement transaction exists in the chain, and the proof that the inner sacrifice exists in the chain. (possibly with proof of the inner sacrifice inputs to prove what fees were actually paid)<br />
<br />
=== Coinbase TxOut Sacrifices ===<br />
<br />
Coinbase transactions are unique in that they can't be spent for 100 blocks, thus solving the problem of proving a transaction output was made public prior to it being possible to spend that output in a single transaction. In addition coinbase transactions can be created anonymously without linking the transaction to any other transaction provided that the creator has the ability to mine anonymously. (or have someone else do so on their behalf)<br />
<br />
A proof for a coinbase txout is particularly short if the txout is the last txout and the script is meant to be unspendable. SHA256 midstate compression can then be used to prove the committed digest, and that the last opcode was OP_RETURN; it is not possible for a script to return true unless without the last opcode being executed. Fortunately the anyone-can-spend version can-not be proven so easily - consider the following txout fragment:<br />
<br />
<SHA256 midstate> <scriptPubKey length> <digest> <nLockTime><br />
<br />
The problem is the fragment could actually be part of this scriptPubkey:<br />
<br />
<pubkey> OP_CHECKSIGVERIFY OP_PUSHDATA (<scriptPubKey length> <digest>)<br />
<br />
In reality this isn't a true sacrifice. The only way around this problem is if the proven data is greater than the maximum pushdata length allowed, 520 bytes, which undesirably depends on a constant whose value may be changed in a future hard-fork.<br />
<br />
== Passports ==<br />
<br />
This wiki combats spam, while still allowing for users to sign up anonymously, by requiring users to pay a small amount of Bitcoins to the wiki before editing privileges are granted. Creating large numbers of "sock-puppets" to add spam content to articles is thus made expensive. The fee approach can be generalized with the concept of a Passport, first proposed by Mike Hearn,<ref>[https://bitcointalk.org/index.php?topic=140711.0 Creating Bitcoin passports using sacrifices]</ref> tied to the users identity. Wikis, forums, webmail and other services can then create blacklists of users who violate the rules of the services, with those blacklists tied to passports.<br />
<br />
The advantage of fidelity bonds in that application over simply charging fees is re-usability of an identity across multiple services, as well as the neutrality: if the value required to create the passport provably does not go to the person adding the passport to a blacklist, there is no incentive to do so to collect new sign-up fees.<br />
<br />
== Financial Services ==<br />
<br />
Fidelity bonds can be used to make financial fraud unprofitable. For instance one early proposal<ref>[http://sourceforge.net/mailarchive/message.php?msg_id=29185108 Trusted identities]</ref> was to use fidelity bonds - called "Trusted identities" by the proposal's author - to create decentralized [[Green address|green addresses]]. Someone wishing for their transactions to be accepted without confirmations would first purchase a fidelity bond of some value tied to their identity. Someone determining if they should accept a payment without confirmations can check that the bond was sufficiently expensive to make it unprofitable for the sender to commit fraud. If the sender does commit fraud by double-spending the payment, the recipient can prove that fraud to the world by providing both transactions spending the same inputs. This proof is added to some sort of blacklist, centralized or decentralized, which later recipients can consult to determine if the fidelity bond is now invalidated.<br />
<br />
== References ==<br />
<br />
<references/></div>Petertoddhttps://en.bitcoin.it/w/index.php?title=Fidelity_bonds&diff=39783Fidelity bonds2013-07-25T17:46:10Z<p>Petertodd: /* Coinbase TxOut Sacrifices */ note problems with midstate compression</p>
<hr />
<div>A fidelity bond is a proposed mechanism where Bitcoins are deliberately sacrificed to make a cryptographic identity expensive to obtain. The sacrifice is done in a way that can be proven to a third party. By making the identity expensive it can be trusted not to commit unwanted acts, such as spamming message boards, or committing fraud, because upon detection of the unwanted acts the identity becomes useless, requiring the owner of the identity to purchase another one.<br />
<br />
== Mechanism ==<br />
<br />
The core of the fidelity bond is the sacrifice - the mechanism by which Bitcoins are provably taken from their original owner. The Bitcoins may be given to someone else or destroyed, but regardless it must not be possible for their original owner to regain control of them.<br />
<br />
An effective form of sacrifice is to simply create a transaction assigning the coins to an unspendable output, either an address known to not have a corresponding secret key, or to a scriptPubKey that is [[Script#Provably_Unspendable.2FPrunable_Outputs|provably unspendable]]. The Bitcoins are removed from circulation forever, a criticism of this mechanism.<br />
<br />
The Bitcoins can also be donated to a third party, such as a charity, however such donations can be controversial, allow the charity itself (or anyone with access to their funds) to purchase bonds at little or no cost, pose the problem of verifying the bonds validity in the future should the chosen charity(s) change, and finally, pose the problem of coming to a consensus on the charities themselves.<br />
<br />
In the context of Bitcoin, miners have been proposed as a third party whom any Bitcoin user can agree should receive funds, as miners act to secure the network from attack for everyone. The value is sacrificed to miners in the form of transaction fees.<br />
<br />
=== Single/Consecutive Block Sacrifices ===<br />
<br />
The sacrifice can be done with transactions that pay abnormally high fees, either single such transactions, or groups of multiple ones in a row, latter intended to prevent miners themselves from creating the sacrifices and mining them in their own blocks. Problems with consecutive transaction sacrifices include the potential for gaps, as well as the large size of the proofs of the sacrifices.<ref>[https://bitcointalk.org/index.php?topic=140711.msg1498806#msg1498806]</ref><br />
<br />
=== Announce/Commit Sacrifices ===<br />
<br />
To ensure that the miner collecting the sacrificed Bitcoin is picked at random the announce/commit sacrifice was proposed.<ref>[https://bitcointalk.org/index.php?topic=134827.0 Purchasing fidelity bonds by provably throwing away bitcoins]</ref> First a sacrifice transaction is prepared that either sacrifices value to transaction fees, or spends coins to an [[Script#Anyone-Can-Spend_Outputs|Anyone-Can-Spend Output]]. With [[nLockTime]] the transaction is made invalid until some time in the future.<br />
<br />
The second step is the announcement. The transaction is enclosed in another transaction as data, for instance by using a [[Script#Provably_Unspendable.2FPrunable_Outputs|prunable output]]. The announcement is then broadcast and is included in the blockchain, proving that anyone could have seen the inner transaction prior to it becoming valid.<br />
<br />
Finally the inner transaction becomes valid when the [[nLockTime]] is reached. Because mining is a random process, any miner can collect the value sacrified, and the purchaser of the fidelity bond has no control over where that value goes.<br />
<br />
The proof of the sacrifice is then two transactions: the proof the announcement transaction exists in the chain, and the proof that the inner sacrifice exists in the chain. (possibly with proof of the inner sacrifice inputs to prove what fees were actually paid)<br />
<br />
=== Coinbase TxOut Sacrifices ===<br />
<br />
Coinbase transactions are unique in that they can't be spent for 100 blocks, thus solving the problem of proving a transaction output was made public prior to it being possible to spend that output in a single transaction. In addition coinbase transactions can be created anonymously without linking the transaction to any other transaction provided that the creator has the ability to mine anonymously. (or have someone else do so on their behalf)<br />
<br />
A proof for a coinbase txout is particularly short if the txout is the last txout and the script is meant to be unspendable. SHA256 midstate compression can then be used to prove the committed digest, and that the last opcode was OP_RETURN; it is not possible for a script to return true unless without the last opcode being executed. Fortunately the anyone-can-spend version can-not be proven so easily - consider the following txout fragment:<br />
<br />
<SHA256 midstate> <scriptPubKey length> <digest> <nLockTime><br />
<br />
The problem is the fragment could actually be part of this scriptPubkey:<br />
<br />
<pubkey> OP_CHECKSIGVERIFY OP_PUSHDATA (<scriptPubKey length> <digest>)<br />
<br />
In reality this isn't a true sacrifice. The only way around this problem is if the proven data is greater than the maximum pushdata length allowed, 520 bytes, which undesirably depends on a constant whose value may be changed in a future hard-fork.<br />
<br />
== Passports ==<br />
<br />
This wiki combats spam, while still allowing for users to sign up anonymously, by requiring users to pay a small amount of Bitcoins to the wiki before editing privileges are granted. Creating large numbers of "sock-puppets" to add spam content to articles is thus made expensive. The fee approach can be generalized with the concept of a Passport, first proposed by Mike Hearn,<ref>[https://bitcointalk.org/index.php?topic=140711.0 Creating Bitcoin passports using sacrifices]</ref> tied to the users identity. Wikis, forums, webmail and other services can then create blacklists of users who violate the rules of the services, with those blacklists tied to passports.<br />
<br />
The advantage of fidelity bonds in that application over simply charging fees is re-usability of an identity across multiple services, as well as the neutrality: if the value required to create the passport provably does not go to the person adding the passport to a blacklist, there is no incentive to do so to collect new sign-up fees.<br />
<br />
== Financial Services ==<br />
<br />
Fidelity bonds can be used to make financial fraud unprofitable. For instance one early proposal<ref>[http://sourceforge.net/mailarchive/message.php?msg_id=29185108 Trusted identities]</ref> was to use fidelity bonds - called "Trusted identities" by the proposal's author - to create decentralized [[Green address|green addresses]]. Someone wishing for their transactions to be accepted without confirmations would first purchase a fidelity bond of some value tied to their identity. Someone determining if they should accept a payment without confirmations can check that the bond was sufficiently expensive to make it unprofitable for the sender to commit fraud. If the sender does commit fraud by double-spending the payment, the recipient can prove that fraud to the world by providing both transactions spending the same inputs. This proof is added to some sort of blacklisted, centralized or decentralized, which later recipients can consult to determine if the fidelity bond is now invalidated.<br />
<br />
== References ==<br />
<br />
<references/></div>Petertoddhttps://en.bitcoin.it/w/index.php?title=Fidelity_bonds&diff=39781Fidelity bonds2013-07-25T17:11:06Z<p>Petertodd: Add Coinbase TxOut Sacrifice</p>
<hr />
<div>A fidelity bond is a proposed mechanism where Bitcoins are deliberately sacrificed to make a cryptographic identity expensive to obtain. The sacrifice is done in a way that can be proven to a third party. By making the identity expensive it can be trusted not to commit unwanted acts, such as spamming message boards, or committing fraud, because upon detection of the unwanted acts the identity becomes useless, requiring the owner of the identity to purchase another one.<br />
<br />
== Mechanism ==<br />
<br />
The core of the fidelity bond is the sacrifice - the mechanism by which Bitcoins are provably taken from their original owner. The Bitcoins may be given to someone else or destroyed, but regardless it must not be possible for their original owner to regain control of them.<br />
<br />
An effective form of sacrifice is to simply create a transaction assigning the coins to an unspendable output, either an address known to not have a corresponding secret key, or to a scriptPubKey that is [[Script#Provably_Unspendable.2FPrunable_Outputs|provably unspendable]]. The Bitcoins are removed from circulation forever, a criticism of this mechanism.<br />
<br />
The Bitcoins can also be donated to a third party, such as a charity, however such donations can be controversial, allow the charity itself (or anyone with access to their funds) to purchase bonds at little or no cost, pose the problem of verifying the bonds validity in the future should the chosen charity(s) change, and finally, pose the problem of coming to a consensus on the charities themselves.<br />
<br />
In the context of Bitcoin, miners have been proposed as a third party whom any Bitcoin user can agree should receive funds, as miners act to secure the network from attack for everyone. The value is sacrificed to miners in the form of transaction fees.<br />
<br />
=== Single/Consecutive Block Sacrifices ===<br />
<br />
The sacrifice can be done with transactions that pay abnormally high fees, either single such transactions, or groups of multiple ones in a row, latter intended to prevent miners themselves from creating the sacrifices and mining them in their own blocks. Problems with consecutive transaction sacrifices include the potential for gaps, as well as the large size of the proofs of the sacrifices.<ref>[https://bitcointalk.org/index.php?topic=140711.msg1498806#msg1498806]</ref><br />
<br />
=== Announce/Commit Sacrifices ===<br />
<br />
To ensure that the miner collecting the sacrificed Bitcoin is picked at random the announce/commit sacrifice was proposed.<ref>[https://bitcointalk.org/index.php?topic=134827.0 Purchasing fidelity bonds by provably throwing away bitcoins]</ref> First a sacrifice transaction is prepared that either sacrifices value to transaction fees, or spends coins to an [[Script#Anyone-Can-Spend_Outputs|Anyone-Can-Spend Output]]. With [[nLockTime]] the transaction is made invalid until some time in the future.<br />
<br />
The second step is the announcement. The transaction is enclosed in another transaction as data, for instance by using a [[Script#Provably_Unspendable.2FPrunable_Outputs|prunable output]]. The announcement is then broadcast and is included in the blockchain, proving that anyone could have seen the inner transaction prior to it becoming valid.<br />
<br />
Finally the inner transaction becomes valid when the [[nLockTime]] is reached. Because mining is a random process, any miner can collect the value sacrified, and the purchaser of the fidelity bond has no control over where that value goes.<br />
<br />
The proof of the sacrifice is then two transactions: the proof the announcement transaction exists in the chain, and the proof that the inner sacrifice exists in the chain. (possibly with proof of the inner sacrifice inputs to prove what fees were actually paid)<br />
<br />
=== Coinbase TxOut Sacrifices ===<br />
<br />
Coinbase transactions are unique in that they can't be spent for 100 blocks, thus solving the problem of proving a transaction output was made public prior to it being possible to spend that output in a single transaction. In addition coinbase transactions can be created anonymously without linking the transaction to any other transaction provided that the creator has the ability to mine anonymously. (or have someone else do so on their behalf)<br />
<br />
== Passports ==<br />
<br />
This wiki combats spam, while still allowing for users to sign up anonymously, by requiring users to pay a small amount of Bitcoins to the wiki before editing privileges are granted. Creating large numbers of "sock-puppets" to add spam content to articles is thus made expensive. The fee approach can be generalized with the concept of a Passport, first proposed by Mike Hearn,<ref>[https://bitcointalk.org/index.php?topic=140711.0 Creating Bitcoin passports using sacrifices]</ref> tied to the users identity. Wikis, forums, webmail and other services can then create blacklists of users who violate the rules of the services, with those blacklists tied to passports.<br />
<br />
The advantage of fidelity bonds in that application over simply charging fees is re-usability of an identity across multiple services, as well as the neutrality: if the value required to create the passport provably does not go to the person adding the passport to a blacklist, there is no incentive to do so to collect new sign-up fees.<br />
<br />
== Financial Services ==<br />
<br />
Fidelity bonds can be used to make financial fraud unprofitable. For instance one early proposal<ref>[http://sourceforge.net/mailarchive/message.php?msg_id=29185108 Trusted identities]</ref> was to use fidelity bonds - called "Trusted identities" by the proposal's author - to create decentralized [[Green address|green addresses]]. Someone wishing for their transactions to be accepted without confirmations would first purchase a fidelity bond of some value tied to their identity. Someone determining if they should accept a payment without confirmations can check that the bond was sufficiently expensive to make it unprofitable for the sender to commit fraud. If the sender does commit fraud by double-spending the payment, the recipient can prove that fraud to the world by providing both transactions spending the same inputs. This proof is added to some sort of blacklisted, centralized or decentralized, which later recipients can consult to determine if the fidelity bond is now invalidated.<br />
<br />
== References ==<br />
<br />
<references/></div>Petertoddhttps://en.bitcoin.it/w/index.php?title=Talk:Script&diff=39735Talk:Script2013-07-23T02:51:13Z<p>Petertodd: /* Provably Unspendable/Prunable Outputs */</p>
<hr />
<div>xOP_IFDUP 115 0x73 x x / x x If the input is true or false, duplicate it.<br />
<br />
Shouldn't it be: "If the input is true, duplicate it."?<br />
--[[User:ThePiachu|ThePiachu]] 11:37, 20 December 2011 (GMT)<br />
<br />
The byte vectors in the stack are specified as being signed integers of variable-length. Then there's an explanation that these integers are considered false if they are either zero or negative zero, which is 0x80. For this to be the case, the elements should be represented in an old binary format called sign-magnitude, which is important to state explicitly, since today virtually all computers use two's complement as representation, and there's no such thing as a negative zero. There's even another representation, one's complement, where negative zero looks like 0xff.<br />
<br />
Reading the source code of the application, I see that arithmetic operations expect unsigned integers, for example, operations OP_2MUL and OP_2DIV are implemented as byte-shifting, which wouldn't work with signed representations.<br />
<br />
It seems to me that, at best, variable-length sign-magnitued integer format is only used for testing for truth, although I haven't read all the code yet.<br />
<br />
--[[User:Jpierre|Jean-Pierre Rupp]] 10:43, 4 March 2012 (GMT)<br />
<br />
== Provably Unspendable/Prunable Outputs ==<br />
<br />
If im not mistaken this kind of transaction would not result in donating the output to the miner. It would instead make the output unusable by anyone forever. In my opinion the best and easiest way to donate to miner is just transfer BTC between your own addresses and set a high fee. [[User:Norill|Norill]] ([[User talk:Norill|talk]]) 22:32, 14 April 2013 (GMT)<br />
<br />
normill: Fixed wording for OP_RETURN; it is mining fee in the example because the output value is zero, not 0.125BTC as I think you thought. Sorry about that.<br />
[[User:Petertodd|Peter Todd]] ([[User talk:Petertodd|talk]]) 02:51, 23 July 2013 (GMT)</div>Petertoddhttps://en.bitcoin.it/w/index.php?title=Talk:Script&diff=39734Talk:Script2013-07-23T02:50:36Z<p>Petertodd: </p>
<hr />
<div>xOP_IFDUP 115 0x73 x x / x x If the input is true or false, duplicate it.<br />
<br />
Shouldn't it be: "If the input is true, duplicate it."?<br />
--[[User:ThePiachu|ThePiachu]] 11:37, 20 December 2011 (GMT)<br />
<br />
The byte vectors in the stack are specified as being signed integers of variable-length. Then there's an explanation that these integers are considered false if they are either zero or negative zero, which is 0x80. For this to be the case, the elements should be represented in an old binary format called sign-magnitude, which is important to state explicitly, since today virtually all computers use two's complement as representation, and there's no such thing as a negative zero. There's even another representation, one's complement, where negative zero looks like 0xff.<br />
<br />
Reading the source code of the application, I see that arithmetic operations expect unsigned integers, for example, operations OP_2MUL and OP_2DIV are implemented as byte-shifting, which wouldn't work with signed representations.<br />
<br />
It seems to me that, at best, variable-length sign-magnitued integer format is only used for testing for truth, although I haven't read all the code yet.<br />
<br />
--[[User:Jpierre|Jean-Pierre Rupp]] 10:43, 4 March 2012 (GMT)<br />
<br />
== Provably Unspendable/Prunable Outputs ==<br />
<br />
If im not mistaken this kind of transaction would not result in donating the output to the miner. It would instead make the output unusable by anyone forever. In my opinion the best and easiest way to donate to miner is just transfer BTC between your own addresses and set a high fee. [[User:Norill|Norill]] ([[User talk:Norill|talk]]) 22:32, 14 April 2013 (GMT)<br />
<br />
normill: Fixed wording for OP_RETURN; it is mining fee in the example because the output value is zero, not 0.125BTC as I think you thought. Sorry about that.</div>Petertoddhttps://en.bitcoin.it/w/index.php?title=Script&diff=39733Script2013-07-23T02:41:28Z<p>Petertodd: /* Provably Unspendable/Prunable Outputs */ wording changes</p>
<hr />
<div>Bitcoin uses a scripting system for [[transactions]]. [[Wikipedia:FORTH|Forth]]-like, Script is simple, stack-based, and processed from left to right. It is purposefully not Turing-complete, with no loops.<br />
<br />
A script is essentially a list of instructions recorded with each transaction that describe how the next person wanting to spend the Bitcoins being transferred can gain access to them. The script for a typical Bitcoin transfer to destination Bitcoin address D simply encumbers future spending of the bitcoins with two things: the spender must provide<br />
# a public key that, when hashed, yields destination address D embedded in the script, and<br />
# a signature to show evidence of the private key corresponding to the public key just provided.<br />
<br />
Scripting provides the flexibility to change the parameters of what's needed to spend transferred Bitcoins. For example, the scripting system could be used to require two private keys, or a combination of several, or even no keys at all.<br />
<br />
A transaction is valid if nothing in the combined script triggers failure and the top stack item is true (non-zero). The party who originally ''sent'' the Bitcoins now being spent, dictates the script operations that will occur ''last'' in order to release them for use in another transaction. The party wanting to spend them must provide the input(s) to the previously recorded script that results in those operations occurring last leaving behind true (non-zero).<br />
<br />
Scripts are big-endian.<br />
<br />
The stacks hold byte vectors. Byte vectors are interpreted as little-endian variable-length integers with the most significant bit determining the sign of the integer. Thus 0x81 represents -1. 0x80 is another representation of zero (so called negative 0). Byte vectors are interpreted as Booleans where False is represented by any representation of zero, and True is represented by any representation of non-zero.<br />
<br />
== Words ==<br />
This is a list of all Script words (commands/functions). Some of the more complicated opcodes are disabled out of concern that the client might have a bug in their implementation; if a transaction using such an opcode were to be included in the chain any fix would risk forking the chain. <br />
<br />
True=1 and False=0.<br />
<br />
=== Constants ===<br />
When talking about scripts, these value-pushing words are usually omitted.<br />
<br />
{| class="wikitable"<br />
|-<br />
!Word<br />
!Opcode<br />
!Hex<br />
!Input<br />
!Output<br />
!Description<br />
|-<br />
|OP_0, OP_FALSE<br />
|0<br />
|0x00<br />
|Nothing.<br />
|(empty value)<br />
|An empty array of bytes is pushed onto the stack. (This is not a no-op: an item is added to the stack.)<br />
|-<br />
|N/A<br />
|1-75<br />
|0x01-0x4b<br />
|(special)<br />
|data<br />
|The next ''opcode'' bytes is data to be pushed onto the stack<br />
|-<br />
|OP_PUSHDATA1<br />
|76<br />
|0x4c<br />
|(special)<br />
|data<br />
|The next byte contains the number of bytes to be pushed onto the stack.<br />
|-<br />
|OP_PUSHDATA2<br />
|77<br />
|0x4d<br />
|(special)<br />
|data<br />
|The next two bytes contain the number of bytes to be pushed onto the stack.<br />
|-<br />
|OP_PUSHDATA4<br />
|78<br />
|0x4e<br />
|(special)<br />
|data<br />
|The next four bytes contain the number of bytes to be pushed onto the stack.<br />
|-<br />
|OP_1NEGATE<br />
|79<br />
|0x4f<br />
|Nothing.<br />
| -1<br />
|The number -1 is pushed onto the stack.<br />
|-<br />
|OP_1, OP_TRUE<br />
|81<br />
|0x51<br />
|Nothing.<br />
|1<br />
|The number 1 is pushed onto the stack.<br />
|-<br />
|OP_2-OP_16<br />
|82-96<br />
|0x52-0x60<br />
|Nothing.<br />
|2-16<br />
|The number in the word name (2-16) is pushed onto the stack.<br />
|}<br />
<br />
=== Flow control ===<br />
<br />
{| class="wikitable"<br />
|-<br />
!Word<br />
!Opcode<br />
!Hex<br />
!Input<br />
!Output<br />
!Description<br />
|-<br />
|OP_NOP<br />
|97<br />
|0x61<br />
|Nothing<br />
|Nothing<br />
|Does nothing.<br />
|-<br />
|OP_IF<br />
|99<br />
|0x63<br />
| colspan="2"|<expression> if [statements] [else [statements]]* endif<br />
|If the top stack value is not 0, the statements are executed. The top stack value is removed.<br />
|-<br />
|OP_NOTIF<br />
|100<br />
|0x64<br />
| colspan="2"|<expression> if [statements] [else [statements]]* endif<br />
|If the top stack value is 0, the statements are executed. The top stack value is removed.<br />
|-<br />
|OP_ELSE<br />
|103<br />
|0x67<br />
| colspan="2"|<expression> if [statements] [else [statements]]* endif<br />
|If the preceding OP_IF or OP_NOTIF or OP_ELSE was not executed then these statements are and if the preceding OP_IF or OP_NOTIF or OP_ELSE was executed then these statements are not. <br />
|-<br />
|OP_ENDIF<br />
|104<br />
|0x68<br />
| colspan="2"|<expression> if [statements] [else [statements]]* endif<br />
|Ends an if/else block.<br />
|-<br />
|OP_VERIFY<br />
|105<br />
|0x69<br />
|True / false<br />
|Nothing / False<br />
|'''Marks transaction as invalid''' if top stack value is not true. True is removed, but false is not.<br />
|-<br />
|OP_RETURN<br />
|106<br />
|0x6a<br />
|Nothing<br />
|Nothing<br />
|'''Marks transaction as invalid'''. <br />
|}<br />
<br />
=== Stack ===<br />
<br />
{| class="wikitable" <br />
|-<br />
!Word<br />
!Opcode<br />
!Hex<br />
!Input<br />
!Output<br />
!Description<br />
|-<br />
|OP_TOALTSTACK<br />
|107<br />
|0x6b<br />
|x1<br />
|(alt)x1<br />
|Puts the input onto the top of the alt stack. Removes it from the main stack.<br />
|-<br />
|OP_FROMALTSTACK<br />
|108<br />
|0x6c<br />
|(alt)x1<br />
|x1<br />
|Puts the input onto the top of the main stack. Removes it from the alt stack.<br />
|-<br />
|OP_IFDUP<br />
|115<br />
|0x73<br />
|x<br />
|x / x x<br />
|If the top stack value is not 0, duplicate it.<br />
|-<br />
|OP_DEPTH<br />
|116<br />
|0x74<br />
|Nothing<br />
|<Stack size><br />
|Puts the number of stack items onto the stack.<br />
|-<br />
|OP_DROP<br />
|117<br />
|0x75<br />
|x<br />
|Nothing<br />
|Removes the top stack item.<br />
|-<br />
|OP_DUP<br />
|118<br />
|0x76<br />
|x<br />
|x x<br />
|Duplicates the top stack item.<br />
|-<br />
|OP_NIP<br />
|119<br />
|0x77<br />
|x1 x2<br />
|x2<br />
|Removes the second-to-top stack item.<br />
|-<br />
|OP_OVER<br />
|120<br />
|0x78<br />
|x1 x2<br />
|x1 x2 x1<br />
|Copies the second-to-top stack item to the top.<br />
|-<br />
|OP_PICK<br />
|121<br />
|0x79<br />
|xn ... x2 x1 x0 <n><br />
|xn ... x2 x1 x0 xn<br />
|The item ''n'' back in the stack is copied to the top.<br />
|-<br />
|OP_ROLL<br />
|122<br />
|0x7a<br />
|xn ... x2 x1 x0 <n><br />
|... x2 x1 x0 xn<br />
|The item ''n'' back in the stack is moved to the top.<br />
|-<br />
|OP_ROT<br />
|123<br />
|0x7b<br />
|x1 x2 x3<br />
|x2 x3 x1<br />
|The top three items on the stack are rotated to the left.<br />
|-<br />
|OP_SWAP<br />
|124<br />
|0x7c<br />
|x1 x2<br />
|x2 x1<br />
|The top two items on the stack are swapped.<br />
|-<br />
|OP_TUCK<br />
|125<br />
|0x7d<br />
|x1 x2<br />
|x2 x1 x2<br />
|The item at the top of the stack is copied and inserted before the second-to-top item.<br />
|-<br />
|OP_2DROP<br />
|109<br />
|0x6d<br />
|x1 x2<br />
|Nothing<br />
|Removes the top two stack items.<br />
|-<br />
|OP_2DUP<br />
|110<br />
|0x6e<br />
|x1 x2<br />
|x1 x2 x1 x2<br />
|Duplicates the top two stack items.<br />
|-<br />
|OP_3DUP<br />
|111<br />
|0x6f<br />
|x1 x2 x3<br />
|x1 x2 x3 x1 x2 x3<br />
|Duplicates the top three stack items.<br />
|-<br />
|OP_2OVER<br />
|112<br />
|0x70<br />
|x1 x2 x3 x4<br />
|x1 x2 x3 x4 x1 x2<br />
|Copies the pair of items two spaces back in the stack to the front.<br />
|-<br />
|OP_2ROT<br />
|113<br />
|0x71<br />
|x1 x2 x3 x4 x5 x6<br />
|x3 x4 x5 x6 x1 x2<br />
|The fifth and sixth items back are moved to the top of the stack.<br />
|-<br />
|OP_2SWAP<br />
|114<br />
|0x72<br />
|x1 x2 x3 x4<br />
|x3 x4 x1 x2<br />
|Swaps the top two pairs of items.<br />
|}<br />
<br />
=== Splice ===<br />
<br />
If any opcode marked as Currently disabled is present in a script, it should abort and fail.<br />
<br />
{| class="wikitable" <br />
|-<br />
!Word<br />
!Opcode<br />
!Hex<br />
!Input<br />
!Output<br />
!Description<br />
|-<br />
|OP_CAT<br />
|126<br />
|0x7e<br />
|x1 x2<br />
|out<br />
|style="background:#D97171;"|Concatenates two strings. ''Currently disabled.''<br />
|-<br />
|OP_SUBSTR<br />
|127<br />
|0x7f<br />
|in begin size<br />
|out<br />
|style="background:#D97171;"|Returns a section of a string. ''Currently disabled.''<br />
|-<br />
|OP_LEFT<br />
|128<br />
|0x80<br />
|in size<br />
|out<br />
|style="background:#D97171;"|Keeps only characters left of the specified point in a string. ''Currently disabled.''<br />
|-<br />
|OP_RIGHT<br />
|129<br />
|0x81<br />
|in size<br />
|out<br />
|style="background:#D97171;"|Keeps only characters right of the specified point in a string. ''Currently disabled.''<br />
|-<br />
|OP_SIZE<br />
|130<br />
|0x82<br />
|in<br />
|in size<br />
|Returns the length of the input string.<br />
|}<br />
<br />
=== Bitwise logic ===<br />
<br />
If any opcode marked as Currently disabled is present in a script, it should abort and fail.<br />
<br />
{| class="wikitable" <br />
|-<br />
!Word<br />
!Opcode<br />
!Hex<br />
!Input<br />
!Output<br />
!Description<br />
|-<br />
|OP_INVERT<br />
|131<br />
|0x83<br />
|in<br />
|out<br />
|style="background:#D97171;"|Flips all of the bits in the input. ''Currently disabled.''<br />
|-<br />
|OP_AND<br />
|132<br />
|0x84<br />
|x1 x2<br />
|out<br />
|style="background:#D97171;"|Boolean ''and'' between each bit in the inputs. ''Currently disabled.''<br />
|-<br />
|OP_OR<br />
|133<br />
|0x85<br />
|x1 x2<br />
|out<br />
|style="background:#D97171;"|Boolean ''or'' between each bit in the inputs. ''Currently disabled.''<br />
|-<br />
|OP_XOR<br />
|134<br />
|0x86<br />
|x1 x2<br />
|out<br />
|style="background:#D97171;"|Boolean ''exclusive or'' between each bit in the inputs. ''Currently disabled.''<br />
|-<br />
|OP_EQUAL<br />
|135<br />
|0x87<br />
|x1 x2<br />
|True / false<br />
|Returns 1 if the inputs are exactly equal, 0 otherwise.<br />
|-<br />
|OP_EQUALVERIFY<br />
|136<br />
|0x88<br />
|x1 x2<br />
|True / false<br />
|Same as OP_EQUAL, but runs OP_VERIFY afterward.<br />
|}<br />
<br />
=== Arithmetic ===<br />
<br />
Note: Arithmetic inputs are limited to signed 32-bit integers, but may overflow their output.<br />
<br />
If any input value for any of these commands is longer than 4 bytes, the script should abort and fail. <br />
If any opcode marked as ''Currently disabled'' is present in a script - it should also abort and fail.<br />
<br />
{| class="wikitable" <br />
|-<br />
!Word<br />
!Opcode<br />
!Hex<br />
!Input<br />
!Output<br />
!Description<br />
|-<br />
|OP_1ADD<br />
|139<br />
|0x8b<br />
|in<br />
|out<br />
|1 is added to the input.<br />
|-<br />
|OP_1SUB<br />
|140<br />
|0x8c<br />
|in<br />
|out<br />
|1 is subtracted from the input.<br />
|-<br />
|OP_2MUL<br />
|141<br />
|0x8d<br />
|in<br />
|out<br />
|style="background:#D97171;"|The input is multiplied by 2. ''Currently disabled.''<br />
|-<br />
|OP_2DIV<br />
|142<br />
|0x8e<br />
|in<br />
|out<br />
|style="background:#D97171;"|The input is divided by 2. ''Currently disabled.''<br />
|-<br />
|OP_NEGATE<br />
|143<br />
|0x8f<br />
|in<br />
|out<br />
|The sign of the input is flipped.<br />
|-<br />
|OP_ABS<br />
|144<br />
|0x90<br />
|in<br />
|out<br />
|The input is made positive.<br />
|-<br />
|OP_NOT<br />
|145<br />
|0x91<br />
|in<br />
|out<br />
|If the input is 0 or 1, it is flipped. Otherwise the output will be 0.<br />
|-<br />
|OP_0NOTEQUAL<br />
|146<br />
|0x92<br />
|in<br />
|out<br />
|Returns 0 if the input is 0. 1 otherwise.<br />
|-<br />
|OP_ADD<br />
|147<br />
|0x93<br />
|a b<br />
|out<br />
|a is added to b.<br />
|-<br />
|OP_SUB<br />
|148<br />
|0x94<br />
|a b<br />
|out<br />
|b is subtracted from a.<br />
|-<br />
|OP_MUL<br />
|149<br />
|0x95<br />
|a b<br />
|out<br />
|style="background:#D97171;"|a is multiplied by b. ''Currently disabled.''<br />
|-<br />
|OP_DIV<br />
|150<br />
|0x96<br />
|a b<br />
|out<br />
|style="background:#D97171;"|a is divided by b. ''Currently disabled.''<br />
|-<br />
|OP_MOD<br />
|151<br />
|0x97<br />
|a b<br />
|out<br />
|style="background:#D97171;"|Returns the remainder after dividing a by b. ''Currently disabled.''<br />
|-<br />
|OP_LSHIFT<br />
|152<br />
|0x98<br />
|a b<br />
|out<br />
|style="background:#D97171;"|Shifts a left b bits, preserving sign. ''Currently disabled.''<br />
|-<br />
|OP_RSHIFT<br />
|153<br />
|0x99<br />
|a b<br />
|out<br />
|style="background:#D97171;"|Shifts a right b bits, preserving sign. ''Currently disabled.''<br />
|-<br />
|OP_BOOLAND<br />
|154<br />
|0x9a<br />
|a b<br />
|out<br />
|If both a and b are not 0, the output is 1. Otherwise 0.<br />
|-<br />
|OP_BOOLOR<br />
|155<br />
|0x9b<br />
|a b<br />
|out<br />
|If a or b is not 0, the output is 1. Otherwise 0.<br />
|-<br />
|OP_NUMEQUAL<br />
|156<br />
|0x9c<br />
|a b<br />
|out<br />
|Returns 1 if the numbers are equal, 0 otherwise.<br />
|-<br />
|OP_NUMEQUALVERIFY<br />
|157<br />
|0x9d<br />
|a b<br />
|out<br />
|Same as OP_NUMEQUAL, but runs OP_VERIFY afterward.<br />
|-<br />
|OP_NUMNOTEQUAL<br />
|158<br />
|0x9e<br />
|a b<br />
|out<br />
|Returns 1 if the numbers are not equal, 0 otherwise.<br />
|-<br />
|OP_LESSTHAN<br />
|159<br />
|0x9f<br />
|a b<br />
|out<br />
|Returns 1 if a is less than b, 0 otherwise.<br />
|-<br />
|OP_GREATERTHAN<br />
|160<br />
|0xa0<br />
|a b<br />
|out<br />
|Returns 1 if a is greater than b, 0 otherwise.<br />
|-<br />
|OP_LESSTHANOREQUAL<br />
|161<br />
|0xa1<br />
|a b<br />
|out<br />
|Returns 1 if a is less than or equal to b, 0 otherwise.<br />
|-<br />
|OP_GREATERTHANOREQUAL<br />
|162<br />
|0xa2<br />
|a b<br />
|out<br />
|Returns 1 if a is greater than or equal to b, 0 otherwise.<br />
|-<br />
|OP_MIN<br />
|163<br />
|0xa3<br />
|a b<br />
|out<br />
|Returns the smaller of a and b.<br />
|-<br />
|OP_MAX<br />
|164<br />
|0xa4<br />
|a b<br />
|out<br />
|Returns the larger of a and b.<br />
|-<br />
|OP_WITHIN<br />
|165<br />
|0xa5<br />
|x min max<br />
|out<br />
|Returns 1 if x is within the specified range (left-inclusive), 0 otherwise.<br />
|}<br />
<br />
=== Crypto ===<br />
<br />
{| class="wikitable" <br />
|-<br />
!Word<br />
!Opcode<br />
!Hex<br />
!Input<br />
!Output<br />
!Description<br />
|-<br />
|OP_RIPEMD160<br />
|166<br />
|0xa6<br />
|in<br />
|hash<br />
|The input is hashed using RIPEMD-160.<br />
|-<br />
|OP_SHA1<br />
|167<br />
|0xa7<br />
|in<br />
|hash<br />
|The input is hashed using SHA-1.<br />
|-<br />
|OP_SHA256<br />
|168<br />
|0xa8<br />
|in<br />
|hash<br />
|The input is hashed using SHA-256.<br />
|-<br />
|OP_HASH160<br />
|169<br />
|0xa9<br />
|in<br />
|hash<br />
|The input is hashed twice: first with SHA-256 and then with RIPEMD-160.<br />
|-<br />
|OP_HASH256<br />
|170<br />
|0xaa<br />
|in<br />
|hash<br />
|The input is hashed two times with SHA-256.<br />
|-<br />
|OP_CODESEPARATOR<br />
|171<br />
|0xab<br />
|Nothing<br />
|Nothing<br />
|All of the signature checking words will only match signatures to the data after the most recently-executed OP_CODESEPARATOR.<br />
|-<br />
|[[OP_CHECKSIG]]<br />
|172<br />
|0xac<br />
|sig pubkey<br />
|True / false<br />
|The entire transaction's outputs, inputs, and script (from the most recently-executed OP_CODESEPARATOR to the end) are hashed. The signature used by OP_CHECKSIG must be a valid signature for this hash and public key. If it is, 1 is returned, 0 otherwise.<br />
|-<br />
|OP_CHECKSIGVERIFY<br />
|173<br />
|0xad<br />
|sig pubkey<br />
|True / false<br />
|Same as OP_CHECKSIG, but OP_VERIFY is executed afterward.<br />
|-<br />
|OP_CHECKMULTISIG<br />
|174<br />
|0xae<br />
|x sig1 sig2 ... <number of signatures> pub1 pub2 <number of public keys><br />
|True / False<br />
|For each signature and public key pair, OP_CHECKSIG is executed. If more public keys than signatures are listed, some key/sig pairs can fail. All signatures need to match a public key. If all signatures are valid, 1 is returned, 0 otherwise. Due to a bug, one extra unused value is removed from the stack.<br />
|-<br />
|OP_CHECKMULTISIGVERIFY<br />
|175<br />
|0xaf<br />
|x sig1 sig2 ... <number of signatures> pub1 pub2 ... <number of public keys><br />
|True / False<br />
|Same as OP_CHECKMULTISIG, but OP_VERIFY is executed afterward.<br />
|}<br />
<br />
===Pseudo-words===<br />
These words are used internally for assisting with transaction matching. They are invalid if used in actual scripts.<br />
{| class="wikitable" <br />
|-<br />
!Word<br />
!Opcode<br />
!Hex<br />
!Description<br />
|-<br />
|OP_PUBKEYHASH<br />
|253<br />
|0xfd<br />
|Represents a public key hashed with OP_HASH160.<br />
|-<br />
|OP_PUBKEY<br />
|254<br />
|0xfe<br />
|Represents a public key compatible with OP_CHECKSIG.<br />
|-<br />
|OP_INVALIDOPCODE<br />
|255<br />
|0xff<br />
|Matches any opcode that is not yet assigned.<br />
|}<br />
<br />
=== Reserved words ===<br />
Any opcode not assigned is also reserved. Using an unassigned opcode makes the transaction invalid.<br />
<br />
{| class="wikitable" <br />
|-<br />
!Word<br />
!Opcode<br />
!Hex<br />
!When used...<br />
|-<br />
|OP_RESERVED<br />
|80<br />
|0x50<br />
|Transaction is invalid unless occuring in an unexecuted OP_IF branch<br />
|-<br />
|OP_VER<br />
|98<br />
|0x62<br />
|Transaction is invalid unless occuring in an unexecuted OP_IF branch<br />
|-<br />
|OP_VERIF<br />
|101<br />
|0x65<br />
|Transaction is invalid even when occuring in an unexecuted OP_IF branch<br />
|-<br />
|OP_VERNOTIF<br />
|102<br />
|0x66<br />
|Transaction is invalid even when occuring in an unexecuted OP_IF branch<br />
|-<br />
|OP_RESERVED1<br />
|137<br />
|0x89<br />
|Transaction is invalid unless occuring in an unexecuted OP_IF branch<br />
|-<br />
|OP_RESERVED2<br />
|138<br />
|0x8a<br />
|Transaction is invalid unless occuring in an unexecuted OP_IF branch<br />
|-<br />
|OP_NOP1-OP_NOP10<br />
|176-185<br />
|0xb0-0xb9<br />
|The word is ignored.<br />
|}<br />
<br />
== Scripts ==<br />
This is a list of interesting scripts. Keep in mind that all constants actually use the data-pushing commands above. Note that there is a small number of standard script forms that are relayed from node to node; non-standard scripts are accepted if they are in a block, but nodes will not relay them.<br />
<br />
=== Standard Transaction to Bitcoin address (pay-to-script-hash) ===<br />
<br />
scriptPubKey: OP_DUP OP_HASH160 <pubKeyHash> OP_EQUALVERIFY OP_CHECKSIG<br />
scriptSig: <sig> <pubKey><br />
<br />
To demonstrate how scripts look on the wire, here is a raw scriptPubKey:<br />
<pre> 76 A9 14<br />
OP_DUP OP_HASH160 Bytes to push<br />
<br />
89 AB CD EF AB BA AB BA AB BA AB BA AB BA AB BA AB BA AB BA 88 AC<br />
Data to push OP_EQUALVERIFY OP_CHECKSIG</pre><br />
<br />
Note: scriptSig is in the input of the spending transaction and scriptPubKey is in the output of the previously unspent i.e. "available" transaction.<br />
<br />
Here is how each word is processed:<br />
{| class="wikitable" <br />
|-<br />
! Stack <br />
! Script <br />
! Description <br />
|-<br />
|Empty.<br />
| <sig> <pubKey> OP_DUP OP_HASH160 <pubKeyHash> OP_EQUALVERIFY OP_CHECKSIG <br />
| scriptSig and scriptPubKey are combined.<br />
|-<br />
|<sig> <pubKey><br />
| OP_DUP OP_HASH160 <pubKeyHash> OP_EQUALVERIFY OP_CHECKSIG <br />
| Constants are added to the stack.<br />
|-<br />
|<sig> <pubKey> <pubKey><br />
| OP_HASH160 <pubKeyHash> OP_EQUALVERIFY OP_CHECKSIG <br />
| Top stack item is duplicated.<br />
|-<br />
|<sig> <pubKey> <pubHashA><br />
|<pubKeyHash> OP_EQUALVERIFY OP_CHECKSIG<br />
| Top stack item is hashed.<br />
|-<br />
|<sig> <pubKey> <pubHashA> <pubKeyHash><br />
|OP_EQUALVERIFY OP_CHECKSIG<br />
| Constant added.<br />
|-<br />
|<sig> <pubKey><br />
|OP_CHECKSIG<br />
| Equality is checked between the top two stack items.<br />
|-<br />
|true<br />
|Empty.<br />
|Signature is checked for top two stack items.<br />
|}<br />
<br />
=== Standard Generation Transaction (pay-to-pubkey) ===<br />
<br />
OP_CHECKSIG is used directly without first hashing the public key. By default the reference implementation uses this form for coinbase payment, and scriptPubKeys of this transaction form are recognized as payments to user. The disadvantage of this transaction form is that the whole public key needs to be known in advance, implying longer payment addresses, and that it provides less protection in the event of a break in the ECDSA signature algorithm.<br />
<br />
scriptPubKey: <pubKey> OP_CHECKSIG<br />
scriptSig: <sig><br />
<br />
Checking process:<br />
{| class="wikitable" <br />
|-<br />
! Stack <br />
! Script <br />
! Description <br />
|-<br />
|Empty.<br />
|<sig> <pubKey> OP_CHECKSIG<br />
|scriptSig and scriptPubKey are combined.<br />
|-<br />
|<sig> <pubKey><br />
| OP_CHECKSIG<br />
|Constants are added to the stack.<br />
|-<br />
|true<br />
|Empty.<br />
|Signature is checked for top two stack items.<br />
|}<br />
<br />
=== Provably Unspendable/Prunable Outputs ===<br />
<br />
The standard way to mark a transaction as provably unspendable is with a scriptPubKey of the following form:<br />
<br />
scriptPubKey: OP_RETURN {zero or more ops}<br />
<br />
OP_RETURN immediately marks the script as invalid, guaranteeing that no scriptSig exists that could possibly spend that output. Thus the output can be immediately pruned from the UTXO set even if it has not been spent. eb31ca1a4cbd97c2770983164d7560d2d03276ae1aee26f12d7c2c6424252f29 is an example: it has a single output of zero value, thus giving the full 0.125BTC fee to the miner who mined the transaction without adding an entry to the UTXO set. You can also use OP_RETURN to add data to a transaction without the data ever appearing in the UTXO set, as seen in 1a2e22a717d626fc5db363582007c46924ae6b28319f07cb1b907776bd8293fc; [[P2Pool]] does this with the share chain hash txout in the coinbase of blocks it creates.<br />
<br />
Note that this mechanism is not yet a standard transaction type, and thus will not be relayed by nodes on mainnet.<br />
<br />
=== Anyone-Can-Spend Outputs ===<br />
<br />
Conversely a transaction can be made spendable by anyone at all:<br />
<br />
scriptPubKey: (empty)<br />
scriptSig: OP_TRUE<br />
<br />
With some software changes such transactions can be used as a way to donate funds to miners in addition to transaction fees: any miner who mines such a transaction can also include an additional one after it sending the funds to an address they control. This mechanism may be used in the future for [[fidelity bonds]] to sacrifice funds in a provable way.<br />
<br />
Anyone-Can-Spend outputs are currently considered non-standard, and are not relayed on the P2P network.<br />
<br />
=== Transaction puzzle ===<br />
<br />
Transaction a4bfa8ab6435ae5f25dae9d89e4eb67dfa94283ca751f393c1ddc5a837bbc31b is an interesting puzzle.<br />
<br />
scriptPubKey: OP_HASH256 6fe28c0ab6f1b372c1a6a246ae63f74f931e8365e15a089c68d6190000000000 OP_EQUAL<br />
scriptSig: <data><br />
<br />
To spend the transaction you need to come up with some data such that hashing the data twice results in the given hash.<br />
<br />
{| class="wikitable" <br />
|-<br />
! Stack <br />
! Script <br />
! Description <br />
|-<br />
|Empty.<br />
|<data> OP_HASH256 <given_hash> OP_EQUAL<br />
|<br />
|-<br />
|<data><br />
|OP_HASH256 <given_hash> OP_EQUAL<br />
|scriptSig added to the stack.<br />
|-<br />
|<data_hash><br />
|<given_hash> OP_EQUAL<br />
|The data is hashed.<br />
|-<br />
|<data_hash> <given_hash><br />
|OP_EQUAL<br />
|The given hash is pushed to the stack.<br />
|-<br />
|true<br />
|Empty.<br />
|The hashes are compared, leaving true on the stack.<br />
|}<br />
<br />
This transaction was successfully spent by 09f691b2263260e71f363d1db51ff3100d285956a40cc0e4f8c8c2c4a80559b1. The required data happened to be the [[Genesis block]], and the given hash was the genesis block hash. Note that while transactions like this are fun, they are not secure, because they do not contain any signatures and thus any transaction attempting to spend them can be replaced with a different transaction sending the funds somewhere else.<br />
<br />
==See Also==<br />
<br />
* [[Transactions]]<br />
* [[Contracts]]<br />
<br />
<br />
[[Category:Technical]]<br />
[[Category:Vocabulary]]</div>Petertoddhttps://en.bitcoin.it/w/index.php?title=Script&diff=39732Script2013-07-23T02:39:48Z<p>Petertodd: /* Provably Unspendable/Prunable Outputs */ make OP_RETURN functionality in the example more clear</p>
<hr />
<div>Bitcoin uses a scripting system for [[transactions]]. [[Wikipedia:FORTH|Forth]]-like, Script is simple, stack-based, and processed from left to right. It is purposefully not Turing-complete, with no loops.<br />
<br />
A script is essentially a list of instructions recorded with each transaction that describe how the next person wanting to spend the Bitcoins being transferred can gain access to them. The script for a typical Bitcoin transfer to destination Bitcoin address D simply encumbers future spending of the bitcoins with two things: the spender must provide<br />
# a public key that, when hashed, yields destination address D embedded in the script, and<br />
# a signature to show evidence of the private key corresponding to the public key just provided.<br />
<br />
Scripting provides the flexibility to change the parameters of what's needed to spend transferred Bitcoins. For example, the scripting system could be used to require two private keys, or a combination of several, or even no keys at all.<br />
<br />
A transaction is valid if nothing in the combined script triggers failure and the top stack item is true (non-zero). The party who originally ''sent'' the Bitcoins now being spent, dictates the script operations that will occur ''last'' in order to release them for use in another transaction. The party wanting to spend them must provide the input(s) to the previously recorded script that results in those operations occurring last leaving behind true (non-zero).<br />
<br />
Scripts are big-endian.<br />
<br />
The stacks hold byte vectors. Byte vectors are interpreted as little-endian variable-length integers with the most significant bit determining the sign of the integer. Thus 0x81 represents -1. 0x80 is another representation of zero (so called negative 0). Byte vectors are interpreted as Booleans where False is represented by any representation of zero, and True is represented by any representation of non-zero.<br />
<br />
== Words ==<br />
This is a list of all Script words (commands/functions). Some of the more complicated opcodes are disabled out of concern that the client might have a bug in their implementation; if a transaction using such an opcode were to be included in the chain any fix would risk forking the chain. <br />
<br />
True=1 and False=0.<br />
<br />
=== Constants ===<br />
When talking about scripts, these value-pushing words are usually omitted.<br />
<br />
{| class="wikitable"<br />
|-<br />
!Word<br />
!Opcode<br />
!Hex<br />
!Input<br />
!Output<br />
!Description<br />
|-<br />
|OP_0, OP_FALSE<br />
|0<br />
|0x00<br />
|Nothing.<br />
|(empty value)<br />
|An empty array of bytes is pushed onto the stack. (This is not a no-op: an item is added to the stack.)<br />
|-<br />
|N/A<br />
|1-75<br />
|0x01-0x4b<br />
|(special)<br />
|data<br />
|The next ''opcode'' bytes is data to be pushed onto the stack<br />
|-<br />
|OP_PUSHDATA1<br />
|76<br />
|0x4c<br />
|(special)<br />
|data<br />
|The next byte contains the number of bytes to be pushed onto the stack.<br />
|-<br />
|OP_PUSHDATA2<br />
|77<br />
|0x4d<br />
|(special)<br />
|data<br />
|The next two bytes contain the number of bytes to be pushed onto the stack.<br />
|-<br />
|OP_PUSHDATA4<br />
|78<br />
|0x4e<br />
|(special)<br />
|data<br />
|The next four bytes contain the number of bytes to be pushed onto the stack.<br />
|-<br />
|OP_1NEGATE<br />
|79<br />
|0x4f<br />
|Nothing.<br />
| -1<br />
|The number -1 is pushed onto the stack.<br />
|-<br />
|OP_1, OP_TRUE<br />
|81<br />
|0x51<br />
|Nothing.<br />
|1<br />
|The number 1 is pushed onto the stack.<br />
|-<br />
|OP_2-OP_16<br />
|82-96<br />
|0x52-0x60<br />
|Nothing.<br />
|2-16<br />
|The number in the word name (2-16) is pushed onto the stack.<br />
|}<br />
<br />
=== Flow control ===<br />
<br />
{| class="wikitable"<br />
|-<br />
!Word<br />
!Opcode<br />
!Hex<br />
!Input<br />
!Output<br />
!Description<br />
|-<br />
|OP_NOP<br />
|97<br />
|0x61<br />
|Nothing<br />
|Nothing<br />
|Does nothing.<br />
|-<br />
|OP_IF<br />
|99<br />
|0x63<br />
| colspan="2"|<expression> if [statements] [else [statements]]* endif<br />
|If the top stack value is not 0, the statements are executed. The top stack value is removed.<br />
|-<br />
|OP_NOTIF<br />
|100<br />
|0x64<br />
| colspan="2"|<expression> if [statements] [else [statements]]* endif<br />
|If the top stack value is 0, the statements are executed. The top stack value is removed.<br />
|-<br />
|OP_ELSE<br />
|103<br />
|0x67<br />
| colspan="2"|<expression> if [statements] [else [statements]]* endif<br />
|If the preceding OP_IF or OP_NOTIF or OP_ELSE was not executed then these statements are and if the preceding OP_IF or OP_NOTIF or OP_ELSE was executed then these statements are not. <br />
|-<br />
|OP_ENDIF<br />
|104<br />
|0x68<br />
| colspan="2"|<expression> if [statements] [else [statements]]* endif<br />
|Ends an if/else block.<br />
|-<br />
|OP_VERIFY<br />
|105<br />
|0x69<br />
|True / false<br />
|Nothing / False<br />
|'''Marks transaction as invalid''' if top stack value is not true. True is removed, but false is not.<br />
|-<br />
|OP_RETURN<br />
|106<br />
|0x6a<br />
|Nothing<br />
|Nothing<br />
|'''Marks transaction as invalid'''. <br />
|}<br />
<br />
=== Stack ===<br />
<br />
{| class="wikitable" <br />
|-<br />
!Word<br />
!Opcode<br />
!Hex<br />
!Input<br />
!Output<br />
!Description<br />
|-<br />
|OP_TOALTSTACK<br />
|107<br />
|0x6b<br />
|x1<br />
|(alt)x1<br />
|Puts the input onto the top of the alt stack. Removes it from the main stack.<br />
|-<br />
|OP_FROMALTSTACK<br />
|108<br />
|0x6c<br />
|(alt)x1<br />
|x1<br />
|Puts the input onto the top of the main stack. Removes it from the alt stack.<br />
|-<br />
|OP_IFDUP<br />
|115<br />
|0x73<br />
|x<br />
|x / x x<br />
|If the top stack value is not 0, duplicate it.<br />
|-<br />
|OP_DEPTH<br />
|116<br />
|0x74<br />
|Nothing<br />
|<Stack size><br />
|Puts the number of stack items onto the stack.<br />
|-<br />
|OP_DROP<br />
|117<br />
|0x75<br />
|x<br />
|Nothing<br />
|Removes the top stack item.<br />
|-<br />
|OP_DUP<br />
|118<br />
|0x76<br />
|x<br />
|x x<br />
|Duplicates the top stack item.<br />
|-<br />
|OP_NIP<br />
|119<br />
|0x77<br />
|x1 x2<br />
|x2<br />
|Removes the second-to-top stack item.<br />
|-<br />
|OP_OVER<br />
|120<br />
|0x78<br />
|x1 x2<br />
|x1 x2 x1<br />
|Copies the second-to-top stack item to the top.<br />
|-<br />
|OP_PICK<br />
|121<br />
|0x79<br />
|xn ... x2 x1 x0 <n><br />
|xn ... x2 x1 x0 xn<br />
|The item ''n'' back in the stack is copied to the top.<br />
|-<br />
|OP_ROLL<br />
|122<br />
|0x7a<br />
|xn ... x2 x1 x0 <n><br />
|... x2 x1 x0 xn<br />
|The item ''n'' back in the stack is moved to the top.<br />
|-<br />
|OP_ROT<br />
|123<br />
|0x7b<br />
|x1 x2 x3<br />
|x2 x3 x1<br />
|The top three items on the stack are rotated to the left.<br />
|-<br />
|OP_SWAP<br />
|124<br />
|0x7c<br />
|x1 x2<br />
|x2 x1<br />
|The top two items on the stack are swapped.<br />
|-<br />
|OP_TUCK<br />
|125<br />
|0x7d<br />
|x1 x2<br />
|x2 x1 x2<br />
|The item at the top of the stack is copied and inserted before the second-to-top item.<br />
|-<br />
|OP_2DROP<br />
|109<br />
|0x6d<br />
|x1 x2<br />
|Nothing<br />
|Removes the top two stack items.<br />
|-<br />
|OP_2DUP<br />
|110<br />
|0x6e<br />
|x1 x2<br />
|x1 x2 x1 x2<br />
|Duplicates the top two stack items.<br />
|-<br />
|OP_3DUP<br />
|111<br />
|0x6f<br />
|x1 x2 x3<br />
|x1 x2 x3 x1 x2 x3<br />
|Duplicates the top three stack items.<br />
|-<br />
|OP_2OVER<br />
|112<br />
|0x70<br />
|x1 x2 x3 x4<br />
|x1 x2 x3 x4 x1 x2<br />
|Copies the pair of items two spaces back in the stack to the front.<br />
|-<br />
|OP_2ROT<br />
|113<br />
|0x71<br />
|x1 x2 x3 x4 x5 x6<br />
|x3 x4 x5 x6 x1 x2<br />
|The fifth and sixth items back are moved to the top of the stack.<br />
|-<br />
|OP_2SWAP<br />
|114<br />
|0x72<br />
|x1 x2 x3 x4<br />
|x3 x4 x1 x2<br />
|Swaps the top two pairs of items.<br />
|}<br />
<br />
=== Splice ===<br />
<br />
If any opcode marked as Currently disabled is present in a script, it should abort and fail.<br />
<br />
{| class="wikitable" <br />
|-<br />
!Word<br />
!Opcode<br />
!Hex<br />
!Input<br />
!Output<br />
!Description<br />
|-<br />
|OP_CAT<br />
|126<br />
|0x7e<br />
|x1 x2<br />
|out<br />
|style="background:#D97171;"|Concatenates two strings. ''Currently disabled.''<br />
|-<br />
|OP_SUBSTR<br />
|127<br />
|0x7f<br />
|in begin size<br />
|out<br />
|style="background:#D97171;"|Returns a section of a string. ''Currently disabled.''<br />
|-<br />
|OP_LEFT<br />
|128<br />
|0x80<br />
|in size<br />
|out<br />
|style="background:#D97171;"|Keeps only characters left of the specified point in a string. ''Currently disabled.''<br />
|-<br />
|OP_RIGHT<br />
|129<br />
|0x81<br />
|in size<br />
|out<br />
|style="background:#D97171;"|Keeps only characters right of the specified point in a string. ''Currently disabled.''<br />
|-<br />
|OP_SIZE<br />
|130<br />
|0x82<br />
|in<br />
|in size<br />
|Returns the length of the input string.<br />
|}<br />
<br />
=== Bitwise logic ===<br />
<br />
If any opcode marked as Currently disabled is present in a script, it should abort and fail.<br />
<br />
{| class="wikitable" <br />
|-<br />
!Word<br />
!Opcode<br />
!Hex<br />
!Input<br />
!Output<br />
!Description<br />
|-<br />
|OP_INVERT<br />
|131<br />
|0x83<br />
|in<br />
|out<br />
|style="background:#D97171;"|Flips all of the bits in the input. ''Currently disabled.''<br />
|-<br />
|OP_AND<br />
|132<br />
|0x84<br />
|x1 x2<br />
|out<br />
|style="background:#D97171;"|Boolean ''and'' between each bit in the inputs. ''Currently disabled.''<br />
|-<br />
|OP_OR<br />
|133<br />
|0x85<br />
|x1 x2<br />
|out<br />
|style="background:#D97171;"|Boolean ''or'' between each bit in the inputs. ''Currently disabled.''<br />
|-<br />
|OP_XOR<br />
|134<br />
|0x86<br />
|x1 x2<br />
|out<br />
|style="background:#D97171;"|Boolean ''exclusive or'' between each bit in the inputs. ''Currently disabled.''<br />
|-<br />
|OP_EQUAL<br />
|135<br />
|0x87<br />
|x1 x2<br />
|True / false<br />
|Returns 1 if the inputs are exactly equal, 0 otherwise.<br />
|-<br />
|OP_EQUALVERIFY<br />
|136<br />
|0x88<br />
|x1 x2<br />
|True / false<br />
|Same as OP_EQUAL, but runs OP_VERIFY afterward.<br />
|}<br />
<br />
=== Arithmetic ===<br />
<br />
Note: Arithmetic inputs are limited to signed 32-bit integers, but may overflow their output.<br />
<br />
If any input value for any of these commands is longer than 4 bytes, the script should abort and fail. <br />
If any opcode marked as ''Currently disabled'' is present in a script - it should also abort and fail.<br />
<br />
{| class="wikitable" <br />
|-<br />
!Word<br />
!Opcode<br />
!Hex<br />
!Input<br />
!Output<br />
!Description<br />
|-<br />
|OP_1ADD<br />
|139<br />
|0x8b<br />
|in<br />
|out<br />
|1 is added to the input.<br />
|-<br />
|OP_1SUB<br />
|140<br />
|0x8c<br />
|in<br />
|out<br />
|1 is subtracted from the input.<br />
|-<br />
|OP_2MUL<br />
|141<br />
|0x8d<br />
|in<br />
|out<br />
|style="background:#D97171;"|The input is multiplied by 2. ''Currently disabled.''<br />
|-<br />
|OP_2DIV<br />
|142<br />
|0x8e<br />
|in<br />
|out<br />
|style="background:#D97171;"|The input is divided by 2. ''Currently disabled.''<br />
|-<br />
|OP_NEGATE<br />
|143<br />
|0x8f<br />
|in<br />
|out<br />
|The sign of the input is flipped.<br />
|-<br />
|OP_ABS<br />
|144<br />
|0x90<br />
|in<br />
|out<br />
|The input is made positive.<br />
|-<br />
|OP_NOT<br />
|145<br />
|0x91<br />
|in<br />
|out<br />
|If the input is 0 or 1, it is flipped. Otherwise the output will be 0.<br />
|-<br />
|OP_0NOTEQUAL<br />
|146<br />
|0x92<br />
|in<br />
|out<br />
|Returns 0 if the input is 0. 1 otherwise.<br />
|-<br />
|OP_ADD<br />
|147<br />
|0x93<br />
|a b<br />
|out<br />
|a is added to b.<br />
|-<br />
|OP_SUB<br />
|148<br />
|0x94<br />
|a b<br />
|out<br />
|b is subtracted from a.<br />
|-<br />
|OP_MUL<br />
|149<br />
|0x95<br />
|a b<br />
|out<br />
|style="background:#D97171;"|a is multiplied by b. ''Currently disabled.''<br />
|-<br />
|OP_DIV<br />
|150<br />
|0x96<br />
|a b<br />
|out<br />
|style="background:#D97171;"|a is divided by b. ''Currently disabled.''<br />
|-<br />
|OP_MOD<br />
|151<br />
|0x97<br />
|a b<br />
|out<br />
|style="background:#D97171;"|Returns the remainder after dividing a by b. ''Currently disabled.''<br />
|-<br />
|OP_LSHIFT<br />
|152<br />
|0x98<br />
|a b<br />
|out<br />
|style="background:#D97171;"|Shifts a left b bits, preserving sign. ''Currently disabled.''<br />
|-<br />
|OP_RSHIFT<br />
|153<br />
|0x99<br />
|a b<br />
|out<br />
|style="background:#D97171;"|Shifts a right b bits, preserving sign. ''Currently disabled.''<br />
|-<br />
|OP_BOOLAND<br />
|154<br />
|0x9a<br />
|a b<br />
|out<br />
|If both a and b are not 0, the output is 1. Otherwise 0.<br />
|-<br />
|OP_BOOLOR<br />
|155<br />
|0x9b<br />
|a b<br />
|out<br />
|If a or b is not 0, the output is 1. Otherwise 0.<br />
|-<br />
|OP_NUMEQUAL<br />
|156<br />
|0x9c<br />
|a b<br />
|out<br />
|Returns 1 if the numbers are equal, 0 otherwise.<br />
|-<br />
|OP_NUMEQUALVERIFY<br />
|157<br />
|0x9d<br />
|a b<br />
|out<br />
|Same as OP_NUMEQUAL, but runs OP_VERIFY afterward.<br />
|-<br />
|OP_NUMNOTEQUAL<br />
|158<br />
|0x9e<br />
|a b<br />
|out<br />
|Returns 1 if the numbers are not equal, 0 otherwise.<br />
|-<br />
|OP_LESSTHAN<br />
|159<br />
|0x9f<br />
|a b<br />
|out<br />
|Returns 1 if a is less than b, 0 otherwise.<br />
|-<br />
|OP_GREATERTHAN<br />
|160<br />
|0xa0<br />
|a b<br />
|out<br />
|Returns 1 if a is greater than b, 0 otherwise.<br />
|-<br />
|OP_LESSTHANOREQUAL<br />
|161<br />
|0xa1<br />
|a b<br />
|out<br />
|Returns 1 if a is less than or equal to b, 0 otherwise.<br />
|-<br />
|OP_GREATERTHANOREQUAL<br />
|162<br />
|0xa2<br />
|a b<br />
|out<br />
|Returns 1 if a is greater than or equal to b, 0 otherwise.<br />
|-<br />
|OP_MIN<br />
|163<br />
|0xa3<br />
|a b<br />
|out<br />
|Returns the smaller of a and b.<br />
|-<br />
|OP_MAX<br />
|164<br />
|0xa4<br />
|a b<br />
|out<br />
|Returns the larger of a and b.<br />
|-<br />
|OP_WITHIN<br />
|165<br />
|0xa5<br />
|x min max<br />
|out<br />
|Returns 1 if x is within the specified range (left-inclusive), 0 otherwise.<br />
|}<br />
<br />
=== Crypto ===<br />
<br />
{| class="wikitable" <br />
|-<br />
!Word<br />
!Opcode<br />
!Hex<br />
!Input<br />
!Output<br />
!Description<br />
|-<br />
|OP_RIPEMD160<br />
|166<br />
|0xa6<br />
|in<br />
|hash<br />
|The input is hashed using RIPEMD-160.<br />
|-<br />
|OP_SHA1<br />
|167<br />
|0xa7<br />
|in<br />
|hash<br />
|The input is hashed using SHA-1.<br />
|-<br />
|OP_SHA256<br />
|168<br />
|0xa8<br />
|in<br />
|hash<br />
|The input is hashed using SHA-256.<br />
|-<br />
|OP_HASH160<br />
|169<br />
|0xa9<br />
|in<br />
|hash<br />
|The input is hashed twice: first with SHA-256 and then with RIPEMD-160.<br />
|-<br />
|OP_HASH256<br />
|170<br />
|0xaa<br />
|in<br />
|hash<br />
|The input is hashed two times with SHA-256.<br />
|-<br />
|OP_CODESEPARATOR<br />
|171<br />
|0xab<br />
|Nothing<br />
|Nothing<br />
|All of the signature checking words will only match signatures to the data after the most recently-executed OP_CODESEPARATOR.<br />
|-<br />
|[[OP_CHECKSIG]]<br />
|172<br />
|0xac<br />
|sig pubkey<br />
|True / false<br />
|The entire transaction's outputs, inputs, and script (from the most recently-executed OP_CODESEPARATOR to the end) are hashed. The signature used by OP_CHECKSIG must be a valid signature for this hash and public key. If it is, 1 is returned, 0 otherwise.<br />
|-<br />
|OP_CHECKSIGVERIFY<br />
|173<br />
|0xad<br />
|sig pubkey<br />
|True / false<br />
|Same as OP_CHECKSIG, but OP_VERIFY is executed afterward.<br />
|-<br />
|OP_CHECKMULTISIG<br />
|174<br />
|0xae<br />
|x sig1 sig2 ... <number of signatures> pub1 pub2 <number of public keys><br />
|True / False<br />
|For each signature and public key pair, OP_CHECKSIG is executed. If more public keys than signatures are listed, some key/sig pairs can fail. All signatures need to match a public key. If all signatures are valid, 1 is returned, 0 otherwise. Due to a bug, one extra unused value is removed from the stack.<br />
|-<br />
|OP_CHECKMULTISIGVERIFY<br />
|175<br />
|0xaf<br />
|x sig1 sig2 ... <number of signatures> pub1 pub2 ... <number of public keys><br />
|True / False<br />
|Same as OP_CHECKMULTISIG, but OP_VERIFY is executed afterward.<br />
|}<br />
<br />
===Pseudo-words===<br />
These words are used internally for assisting with transaction matching. They are invalid if used in actual scripts.<br />
{| class="wikitable" <br />
|-<br />
!Word<br />
!Opcode<br />
!Hex<br />
!Description<br />
|-<br />
|OP_PUBKEYHASH<br />
|253<br />
|0xfd<br />
|Represents a public key hashed with OP_HASH160.<br />
|-<br />
|OP_PUBKEY<br />
|254<br />
|0xfe<br />
|Represents a public key compatible with OP_CHECKSIG.<br />
|-<br />
|OP_INVALIDOPCODE<br />
|255<br />
|0xff<br />
|Matches any opcode that is not yet assigned.<br />
|}<br />
<br />
=== Reserved words ===<br />
Any opcode not assigned is also reserved. Using an unassigned opcode makes the transaction invalid.<br />
<br />
{| class="wikitable" <br />
|-<br />
!Word<br />
!Opcode<br />
!Hex<br />
!When used...<br />
|-<br />
|OP_RESERVED<br />
|80<br />
|0x50<br />
|Transaction is invalid unless occuring in an unexecuted OP_IF branch<br />
|-<br />
|OP_VER<br />
|98<br />
|0x62<br />
|Transaction is invalid unless occuring in an unexecuted OP_IF branch<br />
|-<br />
|OP_VERIF<br />
|101<br />
|0x65<br />
|Transaction is invalid even when occuring in an unexecuted OP_IF branch<br />
|-<br />
|OP_VERNOTIF<br />
|102<br />
|0x66<br />
|Transaction is invalid even when occuring in an unexecuted OP_IF branch<br />
|-<br />
|OP_RESERVED1<br />
|137<br />
|0x89<br />
|Transaction is invalid unless occuring in an unexecuted OP_IF branch<br />
|-<br />
|OP_RESERVED2<br />
|138<br />
|0x8a<br />
|Transaction is invalid unless occuring in an unexecuted OP_IF branch<br />
|-<br />
|OP_NOP1-OP_NOP10<br />
|176-185<br />
|0xb0-0xb9<br />
|The word is ignored.<br />
|}<br />
<br />
== Scripts ==<br />
This is a list of interesting scripts. Keep in mind that all constants actually use the data-pushing commands above. Note that there is a small number of standard script forms that are relayed from node to node; non-standard scripts are accepted if they are in a block, but nodes will not relay them.<br />
<br />
=== Standard Transaction to Bitcoin address (pay-to-script-hash) ===<br />
<br />
scriptPubKey: OP_DUP OP_HASH160 <pubKeyHash> OP_EQUALVERIFY OP_CHECKSIG<br />
scriptSig: <sig> <pubKey><br />
<br />
To demonstrate how scripts look on the wire, here is a raw scriptPubKey:<br />
<pre> 76 A9 14<br />
OP_DUP OP_HASH160 Bytes to push<br />
<br />
89 AB CD EF AB BA AB BA AB BA AB BA AB BA AB BA AB BA AB BA 88 AC<br />
Data to push OP_EQUALVERIFY OP_CHECKSIG</pre><br />
<br />
Note: scriptSig is in the input of the spending transaction and scriptPubKey is in the output of the previously unspent i.e. "available" transaction.<br />
<br />
Here is how each word is processed:<br />
{| class="wikitable" <br />
|-<br />
! Stack <br />
! Script <br />
! Description <br />
|-<br />
|Empty.<br />
| <sig> <pubKey> OP_DUP OP_HASH160 <pubKeyHash> OP_EQUALVERIFY OP_CHECKSIG <br />
| scriptSig and scriptPubKey are combined.<br />
|-<br />
|<sig> <pubKey><br />
| OP_DUP OP_HASH160 <pubKeyHash> OP_EQUALVERIFY OP_CHECKSIG <br />
| Constants are added to the stack.<br />
|-<br />
|<sig> <pubKey> <pubKey><br />
| OP_HASH160 <pubKeyHash> OP_EQUALVERIFY OP_CHECKSIG <br />
| Top stack item is duplicated.<br />
|-<br />
|<sig> <pubKey> <pubHashA><br />
|<pubKeyHash> OP_EQUALVERIFY OP_CHECKSIG<br />
| Top stack item is hashed.<br />
|-<br />
|<sig> <pubKey> <pubHashA> <pubKeyHash><br />
|OP_EQUALVERIFY OP_CHECKSIG<br />
| Constant added.<br />
|-<br />
|<sig> <pubKey><br />
|OP_CHECKSIG<br />
| Equality is checked between the top two stack items.<br />
|-<br />
|true<br />
|Empty.<br />
|Signature is checked for top two stack items.<br />
|}<br />
<br />
=== Standard Generation Transaction (pay-to-pubkey) ===<br />
<br />
OP_CHECKSIG is used directly without first hashing the public key. By default the reference implementation uses this form for coinbase payment, and scriptPubKeys of this transaction form are recognized as payments to user. The disadvantage of this transaction form is that the whole public key needs to be known in advance, implying longer payment addresses, and that it provides less protection in the event of a break in the ECDSA signature algorithm.<br />
<br />
scriptPubKey: <pubKey> OP_CHECKSIG<br />
scriptSig: <sig><br />
<br />
Checking process:<br />
{| class="wikitable" <br />
|-<br />
! Stack <br />
! Script <br />
! Description <br />
|-<br />
|Empty.<br />
|<sig> <pubKey> OP_CHECKSIG<br />
|scriptSig and scriptPubKey are combined.<br />
|-<br />
|<sig> <pubKey><br />
| OP_CHECKSIG<br />
|Constants are added to the stack.<br />
|-<br />
|true<br />
|Empty.<br />
|Signature is checked for top two stack items.<br />
|}<br />
<br />
=== Provably Unspendable/Prunable Outputs ===<br />
<br />
The standard way to mark a transaction as provably unspendable is with a scriptPubKey of the following form:<br />
<br />
scriptPubKey: OP_RETURN {zero or more ops}<br />
<br />
OP_RETURN immediately marks the script as invalid, guaranteeing that no scriptSig exists that could possibly spend that output. Thus the output can be immediately pruned from the UTXO set even if it has not been spent. eb31ca1a4cbd97c2770983164d7560d2d03276ae1aee26f12d7c2c6424252f29 is an example: it has a single output of zero value, thus giving the full 0.125BTC fee to the miner who mined the transaction without adding an entry to the UTXO set. Another use is to add data to a transaction, as seen in 1a2e22a717d626fc5db363582007c46924ae6b28319f07cb1b907776bd8293fc. [[P2Pool]] uses OP_RETURN so that their share chain hash txout in the coinbase of blocks it creates does not clutter the UTXO space.<br />
<br />
Note that this mechanism is not yet a standard transaction type, and thus will not be relayed by nodes on mainnet.<br />
<br />
=== Anyone-Can-Spend Outputs ===<br />
<br />
Conversely a transaction can be made spendable by anyone at all:<br />
<br />
scriptPubKey: (empty)<br />
scriptSig: OP_TRUE<br />
<br />
With some software changes such transactions can be used as a way to donate funds to miners in addition to transaction fees: any miner who mines such a transaction can also include an additional one after it sending the funds to an address they control. This mechanism may be used in the future for [[fidelity bonds]] to sacrifice funds in a provable way.<br />
<br />
Anyone-Can-Spend outputs are currently considered non-standard, and are not relayed on the P2P network.<br />
<br />
=== Transaction puzzle ===<br />
<br />
Transaction a4bfa8ab6435ae5f25dae9d89e4eb67dfa94283ca751f393c1ddc5a837bbc31b is an interesting puzzle.<br />
<br />
scriptPubKey: OP_HASH256 6fe28c0ab6f1b372c1a6a246ae63f74f931e8365e15a089c68d6190000000000 OP_EQUAL<br />
scriptSig: <data><br />
<br />
To spend the transaction you need to come up with some data such that hashing the data twice results in the given hash.<br />
<br />
{| class="wikitable" <br />
|-<br />
! Stack <br />
! Script <br />
! Description <br />
|-<br />
|Empty.<br />
|<data> OP_HASH256 <given_hash> OP_EQUAL<br />
|<br />
|-<br />
|<data><br />
|OP_HASH256 <given_hash> OP_EQUAL<br />
|scriptSig added to the stack.<br />
|-<br />
|<data_hash><br />
|<given_hash> OP_EQUAL<br />
|The data is hashed.<br />
|-<br />
|<data_hash> <given_hash><br />
|OP_EQUAL<br />
|The given hash is pushed to the stack.<br />
|-<br />
|true<br />
|Empty.<br />
|The hashes are compared, leaving true on the stack.<br />
|}<br />
<br />
This transaction was successfully spent by 09f691b2263260e71f363d1db51ff3100d285956a40cc0e4f8c8c2c4a80559b1. The required data happened to be the [[Genesis block]], and the given hash was the genesis block hash. Note that while transactions like this are fun, they are not secure, because they do not contain any signatures and thus any transaction attempting to spend them can be replaced with a different transaction sending the funds somewhere else.<br />
<br />
==See Also==<br />
<br />
* [[Transactions]]<br />
* [[Contracts]]<br />
<br />
<br />
[[Category:Technical]]<br />
[[Category:Vocabulary]]</div>Petertoddhttps://en.bitcoin.it/w/index.php?title=Script&diff=39731Script2013-07-23T02:38:35Z<p>Petertodd: Undo revision 39730 by Norill (talk)</p>
<hr />
<div>Bitcoin uses a scripting system for [[transactions]]. [[Wikipedia:FORTH|Forth]]-like, Script is simple, stack-based, and processed from left to right. It is purposefully not Turing-complete, with no loops.<br />
<br />
A script is essentially a list of instructions recorded with each transaction that describe how the next person wanting to spend the Bitcoins being transferred can gain access to them. The script for a typical Bitcoin transfer to destination Bitcoin address D simply encumbers future spending of the bitcoins with two things: the spender must provide<br />
# a public key that, when hashed, yields destination address D embedded in the script, and<br />
# a signature to show evidence of the private key corresponding to the public key just provided.<br />
<br />
Scripting provides the flexibility to change the parameters of what's needed to spend transferred Bitcoins. For example, the scripting system could be used to require two private keys, or a combination of several, or even no keys at all.<br />
<br />
A transaction is valid if nothing in the combined script triggers failure and the top stack item is true (non-zero). The party who originally ''sent'' the Bitcoins now being spent, dictates the script operations that will occur ''last'' in order to release them for use in another transaction. The party wanting to spend them must provide the input(s) to the previously recorded script that results in those operations occurring last leaving behind true (non-zero).<br />
<br />
Scripts are big-endian.<br />
<br />
The stacks hold byte vectors. Byte vectors are interpreted as little-endian variable-length integers with the most significant bit determining the sign of the integer. Thus 0x81 represents -1. 0x80 is another representation of zero (so called negative 0). Byte vectors are interpreted as Booleans where False is represented by any representation of zero, and True is represented by any representation of non-zero.<br />
<br />
== Words ==<br />
This is a list of all Script words (commands/functions). Some of the more complicated opcodes are disabled out of concern that the client might have a bug in their implementation; if a transaction using such an opcode were to be included in the chain any fix would risk forking the chain. <br />
<br />
True=1 and False=0.<br />
<br />
=== Constants ===<br />
When talking about scripts, these value-pushing words are usually omitted.<br />
<br />
{| class="wikitable"<br />
|-<br />
!Word<br />
!Opcode<br />
!Hex<br />
!Input<br />
!Output<br />
!Description<br />
|-<br />
|OP_0, OP_FALSE<br />
|0<br />
|0x00<br />
|Nothing.<br />
|(empty value)<br />
|An empty array of bytes is pushed onto the stack. (This is not a no-op: an item is added to the stack.)<br />
|-<br />
|N/A<br />
|1-75<br />
|0x01-0x4b<br />
|(special)<br />
|data<br />
|The next ''opcode'' bytes is data to be pushed onto the stack<br />
|-<br />
|OP_PUSHDATA1<br />
|76<br />
|0x4c<br />
|(special)<br />
|data<br />
|The next byte contains the number of bytes to be pushed onto the stack.<br />
|-<br />
|OP_PUSHDATA2<br />
|77<br />
|0x4d<br />
|(special)<br />
|data<br />
|The next two bytes contain the number of bytes to be pushed onto the stack.<br />
|-<br />
|OP_PUSHDATA4<br />
|78<br />
|0x4e<br />
|(special)<br />
|data<br />
|The next four bytes contain the number of bytes to be pushed onto the stack.<br />
|-<br />
|OP_1NEGATE<br />
|79<br />
|0x4f<br />
|Nothing.<br />
| -1<br />
|The number -1 is pushed onto the stack.<br />
|-<br />
|OP_1, OP_TRUE<br />
|81<br />
|0x51<br />
|Nothing.<br />
|1<br />
|The number 1 is pushed onto the stack.<br />
|-<br />
|OP_2-OP_16<br />
|82-96<br />
|0x52-0x60<br />
|Nothing.<br />
|2-16<br />
|The number in the word name (2-16) is pushed onto the stack.<br />
|}<br />
<br />
=== Flow control ===<br />
<br />
{| class="wikitable"<br />
|-<br />
!Word<br />
!Opcode<br />
!Hex<br />
!Input<br />
!Output<br />
!Description<br />
|-<br />
|OP_NOP<br />
|97<br />
|0x61<br />
|Nothing<br />
|Nothing<br />
|Does nothing.<br />
|-<br />
|OP_IF<br />
|99<br />
|0x63<br />
| colspan="2"|<expression> if [statements] [else [statements]]* endif<br />
|If the top stack value is not 0, the statements are executed. The top stack value is removed.<br />
|-<br />
|OP_NOTIF<br />
|100<br />
|0x64<br />
| colspan="2"|<expression> if [statements] [else [statements]]* endif<br />
|If the top stack value is 0, the statements are executed. The top stack value is removed.<br />
|-<br />
|OP_ELSE<br />
|103<br />
|0x67<br />
| colspan="2"|<expression> if [statements] [else [statements]]* endif<br />
|If the preceding OP_IF or OP_NOTIF or OP_ELSE was not executed then these statements are and if the preceding OP_IF or OP_NOTIF or OP_ELSE was executed then these statements are not. <br />
|-<br />
|OP_ENDIF<br />
|104<br />
|0x68<br />
| colspan="2"|<expression> if [statements] [else [statements]]* endif<br />
|Ends an if/else block.<br />
|-<br />
|OP_VERIFY<br />
|105<br />
|0x69<br />
|True / false<br />
|Nothing / False<br />
|'''Marks transaction as invalid''' if top stack value is not true. True is removed, but false is not.<br />
|-<br />
|OP_RETURN<br />
|106<br />
|0x6a<br />
|Nothing<br />
|Nothing<br />
|'''Marks transaction as invalid'''. <br />
|}<br />
<br />
=== Stack ===<br />
<br />
{| class="wikitable" <br />
|-<br />
!Word<br />
!Opcode<br />
!Hex<br />
!Input<br />
!Output<br />
!Description<br />
|-<br />
|OP_TOALTSTACK<br />
|107<br />
|0x6b<br />
|x1<br />
|(alt)x1<br />
|Puts the input onto the top of the alt stack. Removes it from the main stack.<br />
|-<br />
|OP_FROMALTSTACK<br />
|108<br />
|0x6c<br />
|(alt)x1<br />
|x1<br />
|Puts the input onto the top of the main stack. Removes it from the alt stack.<br />
|-<br />
|OP_IFDUP<br />
|115<br />
|0x73<br />
|x<br />
|x / x x<br />
|If the top stack value is not 0, duplicate it.<br />
|-<br />
|OP_DEPTH<br />
|116<br />
|0x74<br />
|Nothing<br />
|<Stack size><br />
|Puts the number of stack items onto the stack.<br />
|-<br />
|OP_DROP<br />
|117<br />
|0x75<br />
|x<br />
|Nothing<br />
|Removes the top stack item.<br />
|-<br />
|OP_DUP<br />
|118<br />
|0x76<br />
|x<br />
|x x<br />
|Duplicates the top stack item.<br />
|-<br />
|OP_NIP<br />
|119<br />
|0x77<br />
|x1 x2<br />
|x2<br />
|Removes the second-to-top stack item.<br />
|-<br />
|OP_OVER<br />
|120<br />
|0x78<br />
|x1 x2<br />
|x1 x2 x1<br />
|Copies the second-to-top stack item to the top.<br />
|-<br />
|OP_PICK<br />
|121<br />
|0x79<br />
|xn ... x2 x1 x0 <n><br />
|xn ... x2 x1 x0 xn<br />
|The item ''n'' back in the stack is copied to the top.<br />
|-<br />
|OP_ROLL<br />
|122<br />
|0x7a<br />
|xn ... x2 x1 x0 <n><br />
|... x2 x1 x0 xn<br />
|The item ''n'' back in the stack is moved to the top.<br />
|-<br />
|OP_ROT<br />
|123<br />
|0x7b<br />
|x1 x2 x3<br />
|x2 x3 x1<br />
|The top three items on the stack are rotated to the left.<br />
|-<br />
|OP_SWAP<br />
|124<br />
|0x7c<br />
|x1 x2<br />
|x2 x1<br />
|The top two items on the stack are swapped.<br />
|-<br />
|OP_TUCK<br />
|125<br />
|0x7d<br />
|x1 x2<br />
|x2 x1 x2<br />
|The item at the top of the stack is copied and inserted before the second-to-top item.<br />
|-<br />
|OP_2DROP<br />
|109<br />
|0x6d<br />
|x1 x2<br />
|Nothing<br />
|Removes the top two stack items.<br />
|-<br />
|OP_2DUP<br />
|110<br />
|0x6e<br />
|x1 x2<br />
|x1 x2 x1 x2<br />
|Duplicates the top two stack items.<br />
|-<br />
|OP_3DUP<br />
|111<br />
|0x6f<br />
|x1 x2 x3<br />
|x1 x2 x3 x1 x2 x3<br />
|Duplicates the top three stack items.<br />
|-<br />
|OP_2OVER<br />
|112<br />
|0x70<br />
|x1 x2 x3 x4<br />
|x1 x2 x3 x4 x1 x2<br />
|Copies the pair of items two spaces back in the stack to the front.<br />
|-<br />
|OP_2ROT<br />
|113<br />
|0x71<br />
|x1 x2 x3 x4 x5 x6<br />
|x3 x4 x5 x6 x1 x2<br />
|The fifth and sixth items back are moved to the top of the stack.<br />
|-<br />
|OP_2SWAP<br />
|114<br />
|0x72<br />
|x1 x2 x3 x4<br />
|x3 x4 x1 x2<br />
|Swaps the top two pairs of items.<br />
|}<br />
<br />
=== Splice ===<br />
<br />
If any opcode marked as Currently disabled is present in a script, it should abort and fail.<br />
<br />
{| class="wikitable" <br />
|-<br />
!Word<br />
!Opcode<br />
!Hex<br />
!Input<br />
!Output<br />
!Description<br />
|-<br />
|OP_CAT<br />
|126<br />
|0x7e<br />
|x1 x2<br />
|out<br />
|style="background:#D97171;"|Concatenates two strings. ''Currently disabled.''<br />
|-<br />
|OP_SUBSTR<br />
|127<br />
|0x7f<br />
|in begin size<br />
|out<br />
|style="background:#D97171;"|Returns a section of a string. ''Currently disabled.''<br />
|-<br />
|OP_LEFT<br />
|128<br />
|0x80<br />
|in size<br />
|out<br />
|style="background:#D97171;"|Keeps only characters left of the specified point in a string. ''Currently disabled.''<br />
|-<br />
|OP_RIGHT<br />
|129<br />
|0x81<br />
|in size<br />
|out<br />
|style="background:#D97171;"|Keeps only characters right of the specified point in a string. ''Currently disabled.''<br />
|-<br />
|OP_SIZE<br />
|130<br />
|0x82<br />
|in<br />
|in size<br />
|Returns the length of the input string.<br />
|}<br />
<br />
=== Bitwise logic ===<br />
<br />
If any opcode marked as Currently disabled is present in a script, it should abort and fail.<br />
<br />
{| class="wikitable" <br />
|-<br />
!Word<br />
!Opcode<br />
!Hex<br />
!Input<br />
!Output<br />
!Description<br />
|-<br />
|OP_INVERT<br />
|131<br />
|0x83<br />
|in<br />
|out<br />
|style="background:#D97171;"|Flips all of the bits in the input. ''Currently disabled.''<br />
|-<br />
|OP_AND<br />
|132<br />
|0x84<br />
|x1 x2<br />
|out<br />
|style="background:#D97171;"|Boolean ''and'' between each bit in the inputs. ''Currently disabled.''<br />
|-<br />
|OP_OR<br />
|133<br />
|0x85<br />
|x1 x2<br />
|out<br />
|style="background:#D97171;"|Boolean ''or'' between each bit in the inputs. ''Currently disabled.''<br />
|-<br />
|OP_XOR<br />
|134<br />
|0x86<br />
|x1 x2<br />
|out<br />
|style="background:#D97171;"|Boolean ''exclusive or'' between each bit in the inputs. ''Currently disabled.''<br />
|-<br />
|OP_EQUAL<br />
|135<br />
|0x87<br />
|x1 x2<br />
|True / false<br />
|Returns 1 if the inputs are exactly equal, 0 otherwise.<br />
|-<br />
|OP_EQUALVERIFY<br />
|136<br />
|0x88<br />
|x1 x2<br />
|True / false<br />
|Same as OP_EQUAL, but runs OP_VERIFY afterward.<br />
|}<br />
<br />
=== Arithmetic ===<br />
<br />
Note: Arithmetic inputs are limited to signed 32-bit integers, but may overflow their output.<br />
<br />
If any input value for any of these commands is longer than 4 bytes, the script should abort and fail. <br />
If any opcode marked as ''Currently disabled'' is present in a script - it should also abort and fail.<br />
<br />
{| class="wikitable" <br />
|-<br />
!Word<br />
!Opcode<br />
!Hex<br />
!Input<br />
!Output<br />
!Description<br />
|-<br />
|OP_1ADD<br />
|139<br />
|0x8b<br />
|in<br />
|out<br />
|1 is added to the input.<br />
|-<br />
|OP_1SUB<br />
|140<br />
|0x8c<br />
|in<br />
|out<br />
|1 is subtracted from the input.<br />
|-<br />
|OP_2MUL<br />
|141<br />
|0x8d<br />
|in<br />
|out<br />
|style="background:#D97171;"|The input is multiplied by 2. ''Currently disabled.''<br />
|-<br />
|OP_2DIV<br />
|142<br />
|0x8e<br />
|in<br />
|out<br />
|style="background:#D97171;"|The input is divided by 2. ''Currently disabled.''<br />
|-<br />
|OP_NEGATE<br />
|143<br />
|0x8f<br />
|in<br />
|out<br />
|The sign of the input is flipped.<br />
|-<br />
|OP_ABS<br />
|144<br />
|0x90<br />
|in<br />
|out<br />
|The input is made positive.<br />
|-<br />
|OP_NOT<br />
|145<br />
|0x91<br />
|in<br />
|out<br />
|If the input is 0 or 1, it is flipped. Otherwise the output will be 0.<br />
|-<br />
|OP_0NOTEQUAL<br />
|146<br />
|0x92<br />
|in<br />
|out<br />
|Returns 0 if the input is 0. 1 otherwise.<br />
|-<br />
|OP_ADD<br />
|147<br />
|0x93<br />
|a b<br />
|out<br />
|a is added to b.<br />
|-<br />
|OP_SUB<br />
|148<br />
|0x94<br />
|a b<br />
|out<br />
|b is subtracted from a.<br />
|-<br />
|OP_MUL<br />
|149<br />
|0x95<br />
|a b<br />
|out<br />
|style="background:#D97171;"|a is multiplied by b. ''Currently disabled.''<br />
|-<br />
|OP_DIV<br />
|150<br />
|0x96<br />
|a b<br />
|out<br />
|style="background:#D97171;"|a is divided by b. ''Currently disabled.''<br />
|-<br />
|OP_MOD<br />
|151<br />
|0x97<br />
|a b<br />
|out<br />
|style="background:#D97171;"|Returns the remainder after dividing a by b. ''Currently disabled.''<br />
|-<br />
|OP_LSHIFT<br />
|152<br />
|0x98<br />
|a b<br />
|out<br />
|style="background:#D97171;"|Shifts a left b bits, preserving sign. ''Currently disabled.''<br />
|-<br />
|OP_RSHIFT<br />
|153<br />
|0x99<br />
|a b<br />
|out<br />
|style="background:#D97171;"|Shifts a right b bits, preserving sign. ''Currently disabled.''<br />
|-<br />
|OP_BOOLAND<br />
|154<br />
|0x9a<br />
|a b<br />
|out<br />
|If both a and b are not 0, the output is 1. Otherwise 0.<br />
|-<br />
|OP_BOOLOR<br />
|155<br />
|0x9b<br />
|a b<br />
|out<br />
|If a or b is not 0, the output is 1. Otherwise 0.<br />
|-<br />
|OP_NUMEQUAL<br />
|156<br />
|0x9c<br />
|a b<br />
|out<br />
|Returns 1 if the numbers are equal, 0 otherwise.<br />
|-<br />
|OP_NUMEQUALVERIFY<br />
|157<br />
|0x9d<br />
|a b<br />
|out<br />
|Same as OP_NUMEQUAL, but runs OP_VERIFY afterward.<br />
|-<br />
|OP_NUMNOTEQUAL<br />
|158<br />
|0x9e<br />
|a b<br />
|out<br />
|Returns 1 if the numbers are not equal, 0 otherwise.<br />
|-<br />
|OP_LESSTHAN<br />
|159<br />
|0x9f<br />
|a b<br />
|out<br />
|Returns 1 if a is less than b, 0 otherwise.<br />
|-<br />
|OP_GREATERTHAN<br />
|160<br />
|0xa0<br />
|a b<br />
|out<br />
|Returns 1 if a is greater than b, 0 otherwise.<br />
|-<br />
|OP_LESSTHANOREQUAL<br />
|161<br />
|0xa1<br />
|a b<br />
|out<br />
|Returns 1 if a is less than or equal to b, 0 otherwise.<br />
|-<br />
|OP_GREATERTHANOREQUAL<br />
|162<br />
|0xa2<br />
|a b<br />
|out<br />
|Returns 1 if a is greater than or equal to b, 0 otherwise.<br />
|-<br />
|OP_MIN<br />
|163<br />
|0xa3<br />
|a b<br />
|out<br />
|Returns the smaller of a and b.<br />
|-<br />
|OP_MAX<br />
|164<br />
|0xa4<br />
|a b<br />
|out<br />
|Returns the larger of a and b.<br />
|-<br />
|OP_WITHIN<br />
|165<br />
|0xa5<br />
|x min max<br />
|out<br />
|Returns 1 if x is within the specified range (left-inclusive), 0 otherwise.<br />
|}<br />
<br />
=== Crypto ===<br />
<br />
{| class="wikitable" <br />
|-<br />
!Word<br />
!Opcode<br />
!Hex<br />
!Input<br />
!Output<br />
!Description<br />
|-<br />
|OP_RIPEMD160<br />
|166<br />
|0xa6<br />
|in<br />
|hash<br />
|The input is hashed using RIPEMD-160.<br />
|-<br />
|OP_SHA1<br />
|167<br />
|0xa7<br />
|in<br />
|hash<br />
|The input is hashed using SHA-1.<br />
|-<br />
|OP_SHA256<br />
|168<br />
|0xa8<br />
|in<br />
|hash<br />
|The input is hashed using SHA-256.<br />
|-<br />
|OP_HASH160<br />
|169<br />
|0xa9<br />
|in<br />
|hash<br />
|The input is hashed twice: first with SHA-256 and then with RIPEMD-160.<br />
|-<br />
|OP_HASH256<br />
|170<br />
|0xaa<br />
|in<br />
|hash<br />
|The input is hashed two times with SHA-256.<br />
|-<br />
|OP_CODESEPARATOR<br />
|171<br />
|0xab<br />
|Nothing<br />
|Nothing<br />
|All of the signature checking words will only match signatures to the data after the most recently-executed OP_CODESEPARATOR.<br />
|-<br />
|[[OP_CHECKSIG]]<br />
|172<br />
|0xac<br />
|sig pubkey<br />
|True / false<br />
|The entire transaction's outputs, inputs, and script (from the most recently-executed OP_CODESEPARATOR to the end) are hashed. The signature used by OP_CHECKSIG must be a valid signature for this hash and public key. If it is, 1 is returned, 0 otherwise.<br />
|-<br />
|OP_CHECKSIGVERIFY<br />
|173<br />
|0xad<br />
|sig pubkey<br />
|True / false<br />
|Same as OP_CHECKSIG, but OP_VERIFY is executed afterward.<br />
|-<br />
|OP_CHECKMULTISIG<br />
|174<br />
|0xae<br />
|x sig1 sig2 ... <number of signatures> pub1 pub2 <number of public keys><br />
|True / False<br />
|For each signature and public key pair, OP_CHECKSIG is executed. If more public keys than signatures are listed, some key/sig pairs can fail. All signatures need to match a public key. If all signatures are valid, 1 is returned, 0 otherwise. Due to a bug, one extra unused value is removed from the stack.<br />
|-<br />
|OP_CHECKMULTISIGVERIFY<br />
|175<br />
|0xaf<br />
|x sig1 sig2 ... <number of signatures> pub1 pub2 ... <number of public keys><br />
|True / False<br />
|Same as OP_CHECKMULTISIG, but OP_VERIFY is executed afterward.<br />
|}<br />
<br />
===Pseudo-words===<br />
These words are used internally for assisting with transaction matching. They are invalid if used in actual scripts.<br />
{| class="wikitable" <br />
|-<br />
!Word<br />
!Opcode<br />
!Hex<br />
!Description<br />
|-<br />
|OP_PUBKEYHASH<br />
|253<br />
|0xfd<br />
|Represents a public key hashed with OP_HASH160.<br />
|-<br />
|OP_PUBKEY<br />
|254<br />
|0xfe<br />
|Represents a public key compatible with OP_CHECKSIG.<br />
|-<br />
|OP_INVALIDOPCODE<br />
|255<br />
|0xff<br />
|Matches any opcode that is not yet assigned.<br />
|}<br />
<br />
=== Reserved words ===<br />
Any opcode not assigned is also reserved. Using an unassigned opcode makes the transaction invalid.<br />
<br />
{| class="wikitable" <br />
|-<br />
!Word<br />
!Opcode<br />
!Hex<br />
!When used...<br />
|-<br />
|OP_RESERVED<br />
|80<br />
|0x50<br />
|Transaction is invalid unless occuring in an unexecuted OP_IF branch<br />
|-<br />
|OP_VER<br />
|98<br />
|0x62<br />
|Transaction is invalid unless occuring in an unexecuted OP_IF branch<br />
|-<br />
|OP_VERIF<br />
|101<br />
|0x65<br />
|Transaction is invalid even when occuring in an unexecuted OP_IF branch<br />
|-<br />
|OP_VERNOTIF<br />
|102<br />
|0x66<br />
|Transaction is invalid even when occuring in an unexecuted OP_IF branch<br />
|-<br />
|OP_RESERVED1<br />
|137<br />
|0x89<br />
|Transaction is invalid unless occuring in an unexecuted OP_IF branch<br />
|-<br />
|OP_RESERVED2<br />
|138<br />
|0x8a<br />
|Transaction is invalid unless occuring in an unexecuted OP_IF branch<br />
|-<br />
|OP_NOP1-OP_NOP10<br />
|176-185<br />
|0xb0-0xb9<br />
|The word is ignored.<br />
|}<br />
<br />
== Scripts ==<br />
This is a list of interesting scripts. Keep in mind that all constants actually use the data-pushing commands above. Note that there is a small number of standard script forms that are relayed from node to node; non-standard scripts are accepted if they are in a block, but nodes will not relay them.<br />
<br />
=== Standard Transaction to Bitcoin address (pay-to-script-hash) ===<br />
<br />
scriptPubKey: OP_DUP OP_HASH160 <pubKeyHash> OP_EQUALVERIFY OP_CHECKSIG<br />
scriptSig: <sig> <pubKey><br />
<br />
To demonstrate how scripts look on the wire, here is a raw scriptPubKey:<br />
<pre> 76 A9 14<br />
OP_DUP OP_HASH160 Bytes to push<br />
<br />
89 AB CD EF AB BA AB BA AB BA AB BA AB BA AB BA AB BA AB BA 88 AC<br />
Data to push OP_EQUALVERIFY OP_CHECKSIG</pre><br />
<br />
Note: scriptSig is in the input of the spending transaction and scriptPubKey is in the output of the previously unspent i.e. "available" transaction.<br />
<br />
Here is how each word is processed:<br />
{| class="wikitable" <br />
|-<br />
! Stack <br />
! Script <br />
! Description <br />
|-<br />
|Empty.<br />
| <sig> <pubKey> OP_DUP OP_HASH160 <pubKeyHash> OP_EQUALVERIFY OP_CHECKSIG <br />
| scriptSig and scriptPubKey are combined.<br />
|-<br />
|<sig> <pubKey><br />
| OP_DUP OP_HASH160 <pubKeyHash> OP_EQUALVERIFY OP_CHECKSIG <br />
| Constants are added to the stack.<br />
|-<br />
|<sig> <pubKey> <pubKey><br />
| OP_HASH160 <pubKeyHash> OP_EQUALVERIFY OP_CHECKSIG <br />
| Top stack item is duplicated.<br />
|-<br />
|<sig> <pubKey> <pubHashA><br />
|<pubKeyHash> OP_EQUALVERIFY OP_CHECKSIG<br />
| Top stack item is hashed.<br />
|-<br />
|<sig> <pubKey> <pubHashA> <pubKeyHash><br />
|OP_EQUALVERIFY OP_CHECKSIG<br />
| Constant added.<br />
|-<br />
|<sig> <pubKey><br />
|OP_CHECKSIG<br />
| Equality is checked between the top two stack items.<br />
|-<br />
|true<br />
|Empty.<br />
|Signature is checked for top two stack items.<br />
|}<br />
<br />
=== Standard Generation Transaction (pay-to-pubkey) ===<br />
<br />
OP_CHECKSIG is used directly without first hashing the public key. By default the reference implementation uses this form for coinbase payment, and scriptPubKeys of this transaction form are recognized as payments to user. The disadvantage of this transaction form is that the whole public key needs to be known in advance, implying longer payment addresses, and that it provides less protection in the event of a break in the ECDSA signature algorithm.<br />
<br />
scriptPubKey: <pubKey> OP_CHECKSIG<br />
scriptSig: <sig><br />
<br />
Checking process:<br />
{| class="wikitable" <br />
|-<br />
! Stack <br />
! Script <br />
! Description <br />
|-<br />
|Empty.<br />
|<sig> <pubKey> OP_CHECKSIG<br />
|scriptSig and scriptPubKey are combined.<br />
|-<br />
|<sig> <pubKey><br />
| OP_CHECKSIG<br />
|Constants are added to the stack.<br />
|-<br />
|true<br />
|Empty.<br />
|Signature is checked for top two stack items.<br />
|}<br />
<br />
=== Provably Unspendable/Prunable Outputs ===<br />
<br />
The standard way to mark a transaction as provably unspendable is with a scriptPubKey of the following form:<br />
<br />
scriptPubKey: OP_RETURN {zero or more ops}<br />
<br />
OP_RETURN immediately marks the script as invalid, guaranteeing that no scriptSig exists that could possibly spend that output. Thus the output can be immediately pruned from the UTXO set even if it has not been spent. eb31ca1a4cbd97c2770983164d7560d2d03276ae1aee26f12d7c2c6424252f29 is an example, and acts to donate 0.125BTC to the miner who mined the transaction. Another use is to add data to a transaction, as seen in 1a2e22a717d626fc5db363582007c46924ae6b28319f07cb1b907776bd8293fc. [[P2Pool]] uses OP_RETURN so that their share chain hash txout in the coinbase of blocks it creates does not clutter the UTXO space.<br />
<br />
Note that this mechanism is not yet a standard transaction type, and thus will not be relayed by nodes on mainnet.<br />
<br />
=== Anyone-Can-Spend Outputs ===<br />
<br />
Conversely a transaction can be made spendable by anyone at all:<br />
<br />
scriptPubKey: (empty)<br />
scriptSig: OP_TRUE<br />
<br />
With some software changes such transactions can be used as a way to donate funds to miners in addition to transaction fees: any miner who mines such a transaction can also include an additional one after it sending the funds to an address they control. This mechanism may be used in the future for [[fidelity bonds]] to sacrifice funds in a provable way.<br />
<br />
Anyone-Can-Spend outputs are currently considered non-standard, and are not relayed on the P2P network.<br />
<br />
=== Transaction puzzle ===<br />
<br />
Transaction a4bfa8ab6435ae5f25dae9d89e4eb67dfa94283ca751f393c1ddc5a837bbc31b is an interesting puzzle.<br />
<br />
scriptPubKey: OP_HASH256 6fe28c0ab6f1b372c1a6a246ae63f74f931e8365e15a089c68d6190000000000 OP_EQUAL<br />
scriptSig: <data><br />
<br />
To spend the transaction you need to come up with some data such that hashing the data twice results in the given hash.<br />
<br />
{| class="wikitable" <br />
|-<br />
! Stack <br />
! Script <br />
! Description <br />
|-<br />
|Empty.<br />
|<data> OP_HASH256 <given_hash> OP_EQUAL<br />
|<br />
|-<br />
|<data><br />
|OP_HASH256 <given_hash> OP_EQUAL<br />
|scriptSig added to the stack.<br />
|-<br />
|<data_hash><br />
|<given_hash> OP_EQUAL<br />
|The data is hashed.<br />
|-<br />
|<data_hash> <given_hash><br />
|OP_EQUAL<br />
|The given hash is pushed to the stack.<br />
|-<br />
|true<br />
|Empty.<br />
|The hashes are compared, leaving true on the stack.<br />
|}<br />
<br />
This transaction was successfully spent by 09f691b2263260e71f363d1db51ff3100d285956a40cc0e4f8c8c2c4a80559b1. The required data happened to be the [[Genesis block]], and the given hash was the genesis block hash. Note that while transactions like this are fun, they are not secure, because they do not contain any signatures and thus any transaction attempting to spend them can be replaced with a different transaction sending the funds somewhere else.<br />
<br />
==See Also==<br />
<br />
* [[Transactions]]<br />
* [[Contracts]]<br />
<br />
<br />
[[Category:Technical]]<br />
[[Category:Vocabulary]]</div>Petertoddhttps://en.bitcoin.it/w/index.php?title=Script&diff=39692Script2013-07-20T06:38:51Z<p>Petertodd: /* Standard Generation Transaction */</p>
<hr />
<div>Bitcoin uses a scripting system for [[transactions]]. [[Wikipedia:FORTH|Forth]]-like, Script is simple, stack-based, and processed from left to right. It is purposefully not Turing-complete, with no loops.<br />
<br />
A script is essentially a list of instructions recorded with each transaction that describe how the next person wanting to spend the Bitcoins being transferred can gain access to them. The script for a typical Bitcoin transfer to destination Bitcoin address D simply encumbers future spending of the bitcoins with two things: the spender must provide<br />
# a public key that, when hashed, yields destination address D embedded in the script, and<br />
# a signature to show evidence of the private key corresponding to the public key just provided.<br />
<br />
Scripting provides the flexibility to change the parameters of what's needed to spend transferred Bitcoins. For example, the scripting system could be used to require two private keys, or a combination of several, or even no keys at all.<br />
<br />
A transaction is valid if nothing in the combined script triggers failure and the top stack item is true (non-zero). The party who originally ''sent'' the Bitcoins now being spent, dictates the script operations that will occur ''last'' in order to release them for use in another transaction. The party wanting to spend them must provide the input(s) to the previously recorded script that results in those operations occurring last leaving behind true (non-zero).<br />
<br />
Scripts are big-endian.<br />
<br />
The stacks hold byte vectors. Byte vectors are interpreted as little-endian variable-length integers with the most significant bit determining the sign of the integer. Thus 0x81 represents -1. 0x80 is another representation of zero (so called negative 0). Byte vectors are interpreted as Booleans where False is represented by any representation of zero, and True is represented by any representation of non-zero.<br />
<br />
== Words ==<br />
This is a list of all Script words (commands/functions). Some of the more complicated opcodes are disabled out of concern that the client might have a bug in their implementation; if a transaction using such an opcode were to be included in the chain any fix would risk forking the chain. <br />
<br />
True=1 and False=0.<br />
<br />
=== Constants ===<br />
When talking about scripts, these value-pushing words are usually omitted.<br />
<br />
{| class="wikitable"<br />
|-<br />
!Word<br />
!Opcode<br />
!Hex<br />
!Input<br />
!Output<br />
!Description<br />
|-<br />
|OP_0, OP_FALSE<br />
|0<br />
|0x00<br />
|Nothing.<br />
|(empty value)<br />
|An empty array of bytes is pushed onto the stack. (This is not a no-op: an item is added to the stack.)<br />
|-<br />
|N/A<br />
|1-75<br />
|0x01-0x4b<br />
|(special)<br />
|data<br />
|The next ''opcode'' bytes is data to be pushed onto the stack<br />
|-<br />
|OP_PUSHDATA1<br />
|76<br />
|0x4c<br />
|(special)<br />
|data<br />
|The next byte contains the number of bytes to be pushed onto the stack.<br />
|-<br />
|OP_PUSHDATA2<br />
|77<br />
|0x4d<br />
|(special)<br />
|data<br />
|The next two bytes contain the number of bytes to be pushed onto the stack.<br />
|-<br />
|OP_PUSHDATA4<br />
|78<br />
|0x4e<br />
|(special)<br />
|data<br />
|The next four bytes contain the number of bytes to be pushed onto the stack.<br />
|-<br />
|OP_1NEGATE<br />
|79<br />
|0x4f<br />
|Nothing.<br />
| -1<br />
|The number -1 is pushed onto the stack.<br />
|-<br />
|OP_1, OP_TRUE<br />
|81<br />
|0x51<br />
|Nothing.<br />
|1<br />
|The number 1 is pushed onto the stack.<br />
|-<br />
|OP_2-OP_16<br />
|82-96<br />
|0x52-0x60<br />
|Nothing.<br />
|2-16<br />
|The number in the word name (2-16) is pushed onto the stack.<br />
|}<br />
<br />
=== Flow control ===<br />
<br />
{| class="wikitable"<br />
|-<br />
!Word<br />
!Opcode<br />
!Hex<br />
!Input<br />
!Output<br />
!Description<br />
|-<br />
|OP_NOP<br />
|97<br />
|0x61<br />
|Nothing<br />
|Nothing<br />
|Does nothing.<br />
|-<br />
|OP_IF<br />
|99<br />
|0x63<br />
| colspan="2"|<expression> if [statements] [else [statements]]* endif<br />
|If the top stack value is not 0, the statements are executed. The top stack value is removed.<br />
|-<br />
|OP_NOTIF<br />
|100<br />
|0x64<br />
| colspan="2"|<expression> if [statements] [else [statements]]* endif<br />
|If the top stack value is 0, the statements are executed. The top stack value is removed.<br />
|-<br />
|OP_ELSE<br />
|103<br />
|0x67<br />
| colspan="2"|<expression> if [statements] [else [statements]]* endif<br />
|If the preceding OP_IF or OP_NOTIF or OP_ELSE was not executed then these statements are and if the preceding OP_IF or OP_NOTIF or OP_ELSE was executed then these statements are not. <br />
|-<br />
|OP_ENDIF<br />
|104<br />
|0x68<br />
| colspan="2"|<expression> if [statements] [else [statements]]* endif<br />
|Ends an if/else block.<br />
|-<br />
|OP_VERIFY<br />
|105<br />
|0x69<br />
|True / false<br />
|Nothing / False<br />
|'''Marks transaction as invalid''' if top stack value is not true. True is removed, but false is not.<br />
|-<br />
|OP_RETURN<br />
|106<br />
|0x6a<br />
|Nothing<br />
|Nothing<br />
|'''Marks transaction as invalid'''. <br />
|}<br />
<br />
=== Stack ===<br />
<br />
{| class="wikitable" <br />
|-<br />
!Word<br />
!Opcode<br />
!Hex<br />
!Input<br />
!Output<br />
!Description<br />
|-<br />
|OP_TOALTSTACK<br />
|107<br />
|0x6b<br />
|x1<br />
|(alt)x1<br />
|Puts the input onto the top of the alt stack. Removes it from the main stack.<br />
|-<br />
|OP_FROMALTSTACK<br />
|108<br />
|0x6c<br />
|(alt)x1<br />
|x1<br />
|Puts the input onto the top of the main stack. Removes it from the alt stack.<br />
|-<br />
|OP_IFDUP<br />
|115<br />
|0x73<br />
|x<br />
|x / x x<br />
|If the top stack value is not 0, duplicate it.<br />
|-<br />
|OP_DEPTH<br />
|116<br />
|0x74<br />
|Nothing<br />
|<Stack size><br />
|Puts the number of stack items onto the stack.<br />
|-<br />
|OP_DROP<br />
|117<br />
|0x75<br />
|x<br />
|Nothing<br />
|Removes the top stack item.<br />
|-<br />
|OP_DUP<br />
|118<br />
|0x76<br />
|x<br />
|x x<br />
|Duplicates the top stack item.<br />
|-<br />
|OP_NIP<br />
|119<br />
|0x77<br />
|x1 x2<br />
|x2<br />
|Removes the second-to-top stack item.<br />
|-<br />
|OP_OVER<br />
|120<br />
|0x78<br />
|x1 x2<br />
|x1 x2 x1<br />
|Copies the second-to-top stack item to the top.<br />
|-<br />
|OP_PICK<br />
|121<br />
|0x79<br />
|xn ... x2 x1 x0 <n><br />
|xn ... x2 x1 x0 xn<br />
|The item ''n'' back in the stack is copied to the top.<br />
|-<br />
|OP_ROLL<br />
|122<br />
|0x7a<br />
|xn ... x2 x1 x0 <n><br />
|... x2 x1 x0 xn<br />
|The item ''n'' back in the stack is moved to the top.<br />
|-<br />
|OP_ROT<br />
|123<br />
|0x7b<br />
|x1 x2 x3<br />
|x2 x3 x1<br />
|The top three items on the stack are rotated to the left.<br />
|-<br />
|OP_SWAP<br />
|124<br />
|0x7c<br />
|x1 x2<br />
|x2 x1<br />
|The top two items on the stack are swapped.<br />
|-<br />
|OP_TUCK<br />
|125<br />
|0x7d<br />
|x1 x2<br />
|x2 x1 x2<br />
|The item at the top of the stack is copied and inserted before the second-to-top item.<br />
|-<br />
|OP_2DROP<br />
|109<br />
|0x6d<br />
|x1 x2<br />
|Nothing<br />
|Removes the top two stack items.<br />
|-<br />
|OP_2DUP<br />
|110<br />
|0x6e<br />
|x1 x2<br />
|x1 x2 x1 x2<br />
|Duplicates the top two stack items.<br />
|-<br />
|OP_3DUP<br />
|111<br />
|0x6f<br />
|x1 x2 x3<br />
|x1 x2 x3 x1 x2 x3<br />
|Duplicates the top three stack items.<br />
|-<br />
|OP_2OVER<br />
|112<br />
|0x70<br />
|x1 x2 x3 x4<br />
|x1 x2 x3 x4 x1 x2<br />
|Copies the pair of items two spaces back in the stack to the front.<br />
|-<br />
|OP_2ROT<br />
|113<br />
|0x71<br />
|x1 x2 x3 x4 x5 x6<br />
|x3 x4 x5 x6 x1 x2<br />
|The fifth and sixth items back are moved to the top of the stack.<br />
|-<br />
|OP_2SWAP<br />
|114<br />
|0x72<br />
|x1 x2 x3 x4<br />
|x3 x4 x1 x2<br />
|Swaps the top two pairs of items.<br />
|}<br />
<br />
=== Splice ===<br />
<br />
If any opcode marked as Currently disabled is present in a script, it should abort and fail.<br />
<br />
{| class="wikitable" <br />
|-<br />
!Word<br />
!Opcode<br />
!Hex<br />
!Input<br />
!Output<br />
!Description<br />
|-<br />
|OP_CAT<br />
|126<br />
|0x7e<br />
|x1 x2<br />
|out<br />
|style="background:#D97171;"|Concatenates two strings. ''Currently disabled.''<br />
|-<br />
|OP_SUBSTR<br />
|127<br />
|0x7f<br />
|in begin size<br />
|out<br />
|style="background:#D97171;"|Returns a section of a string. ''Currently disabled.''<br />
|-<br />
|OP_LEFT<br />
|128<br />
|0x80<br />
|in size<br />
|out<br />
|style="background:#D97171;"|Keeps only characters left of the specified point in a string. ''Currently disabled.''<br />
|-<br />
|OP_RIGHT<br />
|129<br />
|0x81<br />
|in size<br />
|out<br />
|style="background:#D97171;"|Keeps only characters right of the specified point in a string. ''Currently disabled.''<br />
|-<br />
|OP_SIZE<br />
|130<br />
|0x82<br />
|in<br />
|in size<br />
|Returns the length of the input string.<br />
|}<br />
<br />
=== Bitwise logic ===<br />
<br />
If any opcode marked as Currently disabled is present in a script, it should abort and fail.<br />
<br />
{| class="wikitable" <br />
|-<br />
!Word<br />
!Opcode<br />
!Hex<br />
!Input<br />
!Output<br />
!Description<br />
|-<br />
|OP_INVERT<br />
|131<br />
|0x83<br />
|in<br />
|out<br />
|style="background:#D97171;"|Flips all of the bits in the input. ''Currently disabled.''<br />
|-<br />
|OP_AND<br />
|132<br />
|0x84<br />
|x1 x2<br />
|out<br />
|style="background:#D97171;"|Boolean ''and'' between each bit in the inputs. ''Currently disabled.''<br />
|-<br />
|OP_OR<br />
|133<br />
|0x85<br />
|x1 x2<br />
|out<br />
|style="background:#D97171;"|Boolean ''or'' between each bit in the inputs. ''Currently disabled.''<br />
|-<br />
|OP_XOR<br />
|134<br />
|0x86<br />
|x1 x2<br />
|out<br />
|style="background:#D97171;"|Boolean ''exclusive or'' between each bit in the inputs. ''Currently disabled.''<br />
|-<br />
|OP_EQUAL<br />
|135<br />
|0x87<br />
|x1 x2<br />
|True / false<br />
|Returns 1 if the inputs are exactly equal, 0 otherwise.<br />
|-<br />
|OP_EQUALVERIFY<br />
|136<br />
|0x88<br />
|x1 x2<br />
|True / false<br />
|Same as OP_EQUAL, but runs OP_VERIFY afterward.<br />
|}<br />
<br />
=== Arithmetic ===<br />
<br />
Note: Arithmetic inputs are limited to signed 32-bit integers, but may overflow their output.<br />
<br />
If any input value for any of these commands is longer than 4 bytes, the script should abort and fail. <br />
If any opcode marked as ''Currently disabled'' is present in a script - it should also abort and fail.<br />
<br />
{| class="wikitable" <br />
|-<br />
!Word<br />
!Opcode<br />
!Hex<br />
!Input<br />
!Output<br />
!Description<br />
|-<br />
|OP_1ADD<br />
|139<br />
|0x8b<br />
|in<br />
|out<br />
|1 is added to the input.<br />
|-<br />
|OP_1SUB<br />
|140<br />
|0x8c<br />
|in<br />
|out<br />
|1 is subtracted from the input.<br />
|-<br />
|OP_2MUL<br />
|141<br />
|0x8d<br />
|in<br />
|out<br />
|style="background:#D97171;"|The input is multiplied by 2. ''Currently disabled.''<br />
|-<br />
|OP_2DIV<br />
|142<br />
|0x8e<br />
|in<br />
|out<br />
|style="background:#D97171;"|The input is divided by 2. ''Currently disabled.''<br />
|-<br />
|OP_NEGATE<br />
|143<br />
|0x8f<br />
|in<br />
|out<br />
|The sign of the input is flipped.<br />
|-<br />
|OP_ABS<br />
|144<br />
|0x90<br />
|in<br />
|out<br />
|The input is made positive.<br />
|-<br />
|OP_NOT<br />
|145<br />
|0x91<br />
|in<br />
|out<br />
|If the input is 0 or 1, it is flipped. Otherwise the output will be 0.<br />
|-<br />
|OP_0NOTEQUAL<br />
|146<br />
|0x92<br />
|in<br />
|out<br />
|Returns 0 if the input is 0. 1 otherwise.<br />
|-<br />
|OP_ADD<br />
|147<br />
|0x93<br />
|a b<br />
|out<br />
|a is added to b.<br />
|-<br />
|OP_SUB<br />
|148<br />
|0x94<br />
|a b<br />
|out<br />
|b is subtracted from a.<br />
|-<br />
|OP_MUL<br />
|149<br />
|0x95<br />
|a b<br />
|out<br />
|style="background:#D97171;"|a is multiplied by b. ''Currently disabled.''<br />
|-<br />
|OP_DIV<br />
|150<br />
|0x96<br />
|a b<br />
|out<br />
|style="background:#D97171;"|a is divided by b. ''Currently disabled.''<br />
|-<br />
|OP_MOD<br />
|151<br />
|0x97<br />
|a b<br />
|out<br />
|style="background:#D97171;"|Returns the remainder after dividing a by b. ''Currently disabled.''<br />
|-<br />
|OP_LSHIFT<br />
|152<br />
|0x98<br />
|a b<br />
|out<br />
|style="background:#D97171;"|Shifts a left b bits, preserving sign. ''Currently disabled.''<br />
|-<br />
|OP_RSHIFT<br />
|153<br />
|0x99<br />
|a b<br />
|out<br />
|style="background:#D97171;"|Shifts a right b bits, preserving sign. ''Currently disabled.''<br />
|-<br />
|OP_BOOLAND<br />
|154<br />
|0x9a<br />
|a b<br />
|out<br />
|If both a and b are not 0, the output is 1. Otherwise 0.<br />
|-<br />
|OP_BOOLOR<br />
|155<br />
|0x9b<br />
|a b<br />
|out<br />
|If a or b is not 0, the output is 1. Otherwise 0.<br />
|-<br />
|OP_NUMEQUAL<br />
|156<br />
|0x9c<br />
|a b<br />
|out<br />
|Returns 1 if the numbers are equal, 0 otherwise.<br />
|-<br />
|OP_NUMEQUALVERIFY<br />
|157<br />
|0x9d<br />
|a b<br />
|out<br />
|Same as OP_NUMEQUAL, but runs OP_VERIFY afterward.<br />
|-<br />
|OP_NUMNOTEQUAL<br />
|158<br />
|0x9e<br />
|a b<br />
|out<br />
|Returns 1 if the numbers are not equal, 0 otherwise.<br />
|-<br />
|OP_LESSTHAN<br />
|159<br />
|0x9f<br />
|a b<br />
|out<br />
|Returns 1 if a is less than b, 0 otherwise.<br />
|-<br />
|OP_GREATERTHAN<br />
|160<br />
|0xa0<br />
|a b<br />
|out<br />
|Returns 1 if a is greater than b, 0 otherwise.<br />
|-<br />
|OP_LESSTHANOREQUAL<br />
|161<br />
|0xa1<br />
|a b<br />
|out<br />
|Returns 1 if a is less than or equal to b, 0 otherwise.<br />
|-<br />
|OP_GREATERTHANOREQUAL<br />
|162<br />
|0xa2<br />
|a b<br />
|out<br />
|Returns 1 if a is greater than or equal to b, 0 otherwise.<br />
|-<br />
|OP_MIN<br />
|163<br />
|0xa3<br />
|a b<br />
|out<br />
|Returns the smaller of a and b.<br />
|-<br />
|OP_MAX<br />
|164<br />
|0xa4<br />
|a b<br />
|out<br />
|Returns the larger of a and b.<br />
|-<br />
|OP_WITHIN<br />
|165<br />
|0xa5<br />
|x min max<br />
|out<br />
|Returns 1 if x is within the specified range (left-inclusive), 0 otherwise.<br />
|}<br />
<br />
=== Crypto ===<br />
<br />
{| class="wikitable" <br />
|-<br />
!Word<br />
!Opcode<br />
!Hex<br />
!Input<br />
!Output<br />
!Description<br />
|-<br />
|OP_RIPEMD160<br />
|166<br />
|0xa6<br />
|in<br />
|hash<br />
|The input is hashed using RIPEMD-160.<br />
|-<br />
|OP_SHA1<br />
|167<br />
|0xa7<br />
|in<br />
|hash<br />
|The input is hashed using SHA-1.<br />
|-<br />
|OP_SHA256<br />
|168<br />
|0xa8<br />
|in<br />
|hash<br />
|The input is hashed using SHA-256.<br />
|-<br />
|OP_HASH160<br />
|169<br />
|0xa9<br />
|in<br />
|hash<br />
|The input is hashed twice: first with SHA-256 and then with RIPEMD-160.<br />
|-<br />
|OP_HASH256<br />
|170<br />
|0xaa<br />
|in<br />
|hash<br />
|The input is hashed two times with SHA-256.<br />
|-<br />
|OP_CODESEPARATOR<br />
|171<br />
|0xab<br />
|Nothing<br />
|Nothing<br />
|All of the signature checking words will only match signatures to the data after the most recently-executed OP_CODESEPARATOR.<br />
|-<br />
|[[OP_CHECKSIG]]<br />
|172<br />
|0xac<br />
|sig pubkey<br />
|True / false<br />
|The entire transaction's outputs, inputs, and script (from the most recently-executed OP_CODESEPARATOR to the end) are hashed. The signature used by OP_CHECKSIG must be a valid signature for this hash and public key. If it is, 1 is returned, 0 otherwise.<br />
|-<br />
|OP_CHECKSIGVERIFY<br />
|173<br />
|0xad<br />
|sig pubkey<br />
|True / false<br />
|Same as OP_CHECKSIG, but OP_VERIFY is executed afterward.<br />
|-<br />
|OP_CHECKMULTISIG<br />
|174<br />
|0xae<br />
|x sig1 sig2 ... <number of signatures> pub1 pub2 <number of public keys><br />
|True / False<br />
|For each signature and public key pair, OP_CHECKSIG is executed. If more public keys than signatures are listed, some key/sig pairs can fail. All signatures need to match a public key. If all signatures are valid, 1 is returned, 0 otherwise. Due to a bug, one extra unused value is removed from the stack.<br />
|-<br />
|OP_CHECKMULTISIGVERIFY<br />
|175<br />
|0xaf<br />
|x sig1 sig2 ... <number of signatures> pub1 pub2 ... <number of public keys><br />
|True / False<br />
|Same as OP_CHECKMULTISIG, but OP_VERIFY is executed afterward.<br />
|}<br />
<br />
===Pseudo-words===<br />
These words are used internally for assisting with transaction matching. They are invalid if used in actual scripts.<br />
{| class="wikitable" <br />
|-<br />
!Word<br />
!Opcode<br />
!Hex<br />
!Description<br />
|-<br />
|OP_PUBKEYHASH<br />
|253<br />
|0xfd<br />
|Represents a public key hashed with OP_HASH160.<br />
|-<br />
|OP_PUBKEY<br />
|254<br />
|0xfe<br />
|Represents a public key compatible with OP_CHECKSIG.<br />
|-<br />
|OP_INVALIDOPCODE<br />
|255<br />
|0xff<br />
|Matches any opcode that is not yet assigned.<br />
|}<br />
<br />
=== Reserved words ===<br />
Any opcode not assigned is also reserved. Using an unassigned opcode makes the transaction invalid.<br />
<br />
{| class="wikitable" <br />
|-<br />
!Word<br />
!Opcode<br />
!Hex<br />
!When used...<br />
|-<br />
|OP_RESERVED<br />
|80<br />
|0x50<br />
|Transaction is invalid unless occuring in an unexecuted OP_IF branch<br />
|-<br />
|OP_VER<br />
|98<br />
|0x62<br />
|Transaction is invalid unless occuring in an unexecuted OP_IF branch<br />
|-<br />
|OP_VERIF<br />
|101<br />
|0x65<br />
|Transaction is invalid even when occuring in an unexecuted OP_IF branch<br />
|-<br />
|OP_VERNOTIF<br />
|102<br />
|0x66<br />
|Transaction is invalid even when occuring in an unexecuted OP_IF branch<br />
|-<br />
|OP_RESERVED1<br />
|137<br />
|0x89<br />
|Transaction is invalid unless occuring in an unexecuted OP_IF branch<br />
|-<br />
|OP_RESERVED2<br />
|138<br />
|0x8a<br />
|Transaction is invalid unless occuring in an unexecuted OP_IF branch<br />
|-<br />
|OP_NOP1-OP_NOP10<br />
|176-185<br />
|0xb0-0xb9<br />
|The word is ignored.<br />
|}<br />
<br />
== Scripts ==<br />
This is a list of interesting scripts. Keep in mind that all constants actually use the data-pushing commands above. Note that there is a small number of standard script forms that are relayed from node to node; non-standard scripts are accepted if they are in a block, but nodes will not relay them.<br />
<br />
=== Standard Transaction to Bitcoin address (pay-to-script-hash) ===<br />
<br />
scriptPubKey: OP_DUP OP_HASH160 <pubKeyHash> OP_EQUALVERIFY OP_CHECKSIG<br />
scriptSig: <sig> <pubKey><br />
<br />
To demonstrate how scripts look on the wire, here is a raw scriptPubKey:<br />
<pre> 76 A9 14<br />
OP_DUP OP_HASH160 Bytes to push<br />
<br />
89 AB CD EF AB BA AB BA AB BA AB BA AB BA AB BA AB BA AB BA 88 AC<br />
Data to push OP_EQUALVERIFY OP_CHECKSIG</pre><br />
<br />
Note: scriptSig is in the input of the spending transaction and scriptPubKey is in the output of the previously unspent i.e. "available" transaction.<br />
<br />
Here is how each word is processed:<br />
{| class="wikitable" <br />
|-<br />
! Stack <br />
! Script <br />
! Description <br />
|-<br />
|Empty.<br />
| <sig> <pubKey> OP_DUP OP_HASH160 <pubKeyHash> OP_EQUALVERIFY OP_CHECKSIG <br />
| scriptSig and scriptPubKey are combined.<br />
|-<br />
|<sig> <pubKey><br />
| OP_DUP OP_HASH160 <pubKeyHash> OP_EQUALVERIFY OP_CHECKSIG <br />
| Constants are added to the stack.<br />
|-<br />
|<sig> <pubKey> <pubKey><br />
| OP_HASH160 <pubKeyHash> OP_EQUALVERIFY OP_CHECKSIG <br />
| Top stack item is duplicated.<br />
|-<br />
|<sig> <pubKey> <pubHashA><br />
|<pubKeyHash> OP_EQUALVERIFY OP_CHECKSIG<br />
| Top stack item is hashed.<br />
|-<br />
|<sig> <pubKey> <pubHashA> <pubKeyHash><br />
|OP_EQUALVERIFY OP_CHECKSIG<br />
| Constant added.<br />
|-<br />
|<sig> <pubKey><br />
|OP_CHECKSIG<br />
| Equality is checked between the top two stack items.<br />
|-<br />
|true<br />
|Empty.<br />
|Signature is checked for top two stack items.<br />
|}<br />
<br />
=== Standard Generation Transaction (pay-to-pubkey) ===<br />
<br />
OP_CHECKSIG is used directly without first hashing the public key. By default the reference implementation uses this form for coinbase payment, and scriptPubKeys of this transaction form are recognized as payments to user. The disadvantage of this transaction form is that the whole public key needs to be known in advance, implying longer payment addresses, and that it provides less protection in the event of a break in the ECDSA signature algorithm.<br />
<br />
scriptPubKey: <pubKey> OP_CHECKSIG<br />
scriptSig: <sig><br />
<br />
Checking process:<br />
{| class="wikitable" <br />
|-<br />
! Stack <br />
! Script <br />
! Description <br />
|-<br />
|Empty.<br />
|<sig> <pubKey> OP_CHECKSIG<br />
|scriptSig and scriptPubKey are combined.<br />
|-<br />
|<sig> <pubKey><br />
| OP_CHECKSIG<br />
|Constants are added to the stack.<br />
|-<br />
|true<br />
|Empty.<br />
|Signature is checked for top two stack items.<br />
|}<br />
<br />
=== Provably Unspendable/Prunable Outputs ===<br />
<br />
The standard way to mark a transaction as provably unspendable is with a scriptPubKey of the following form:<br />
<br />
scriptPubKey: OP_RETURN {zero or more ops}<br />
<br />
OP_RETURN immediately marks the script as invalid, guaranteeing that no scriptSig exists that could possibly spend that output. Thus the output can be immediately pruned from the UTXO set even if it has not been spent. eb31ca1a4cbd97c2770983164d7560d2d03276ae1aee26f12d7c2c6424252f29 is an example, and acts to donate 0.125BTC to the miner who mined the transaction. Another use is to add data to a transaction, as seen in 1a2e22a717d626fc5db363582007c46924ae6b28319f07cb1b907776bd8293fc. [[P2Pool]] uses OP_RETURN so that their share chain hash txout in the coinbase of blocks it creates does not clutter the UTXO space.<br />
<br />
Note that this mechanism is not yet a standard transaction type, and thus will not be relayed by nodes on mainnet.<br />
<br />
=== Anyone-Can-Spend Outputs ===<br />
<br />
Conversely a transaction can be made spendable by anyone at all:<br />
<br />
scriptPubKey: (empty)<br />
scriptSig: OP_TRUE<br />
<br />
With some software changes such transactions can be used as a way to donate funds to miners in addition to transaction fees: any miner who mines such a transaction can also include an additional one after it sending the funds to an address they control. This mechanism may be used in the future for [[fidelity bonds]] to sacrifice funds in a provable way.<br />
<br />
Anyone-Can-Spend outputs are currently considered non-standard, and are not relayed on the P2P network.<br />
<br />
=== Transaction puzzle ===<br />
<br />
Transaction a4bfa8ab6435ae5f25dae9d89e4eb67dfa94283ca751f393c1ddc5a837bbc31b is an interesting puzzle.<br />
<br />
scriptPubKey: OP_HASH256 6fe28c0ab6f1b372c1a6a246ae63f74f931e8365e15a089c68d6190000000000 OP_EQUAL<br />
scriptSig: <data><br />
<br />
To spend the transaction you need to come up with some data such that hashing the data twice results in the given hash.<br />
<br />
{| class="wikitable" <br />
|-<br />
! Stack <br />
! Script <br />
! Description <br />
|-<br />
|Empty.<br />
|<data> OP_HASH256 <given_hash> OP_EQUAL<br />
|<br />
|-<br />
|<data><br />
|OP_HASH256 <given_hash> OP_EQUAL<br />
|scriptSig added to the stack.<br />
|-<br />
|<data_hash><br />
|<given_hash> OP_EQUAL<br />
|The data is hashed.<br />
|-<br />
|<data_hash> <given_hash><br />
|OP_EQUAL<br />
|The given hash is pushed to the stack.<br />
|-<br />
|true<br />
|Empty.<br />
|The hashes are compared, leaving true on the stack.<br />
|}<br />
<br />
This transaction was successfully spent by 09f691b2263260e71f363d1db51ff3100d285956a40cc0e4f8c8c2c4a80559b1. The required data happened to be the [[Genesis block]], and the given hash was the genesis block hash. Note that while transactions like this are fun, they are not secure, because they do not contain any signatures and thus any transaction attempting to spend them can be replaced with a different transaction sending the funds somewhere else.<br />
<br />
==See Also==<br />
<br />
* [[Transactions]]<br />
* [[Contracts]]<br />
<br />
<br />
[[Category:Technical]]<br />
[[Category:Vocabulary]]</div>Petertoddhttps://en.bitcoin.it/w/index.php?title=Script&diff=39691Script2013-07-20T06:38:41Z<p>Petertodd: /* Standard Transaction to Bitcoin address */</p>
<hr />
<div>Bitcoin uses a scripting system for [[transactions]]. [[Wikipedia:FORTH|Forth]]-like, Script is simple, stack-based, and processed from left to right. It is purposefully not Turing-complete, with no loops.<br />
<br />
A script is essentially a list of instructions recorded with each transaction that describe how the next person wanting to spend the Bitcoins being transferred can gain access to them. The script for a typical Bitcoin transfer to destination Bitcoin address D simply encumbers future spending of the bitcoins with two things: the spender must provide<br />
# a public key that, when hashed, yields destination address D embedded in the script, and<br />
# a signature to show evidence of the private key corresponding to the public key just provided.<br />
<br />
Scripting provides the flexibility to change the parameters of what's needed to spend transferred Bitcoins. For example, the scripting system could be used to require two private keys, or a combination of several, or even no keys at all.<br />
<br />
A transaction is valid if nothing in the combined script triggers failure and the top stack item is true (non-zero). The party who originally ''sent'' the Bitcoins now being spent, dictates the script operations that will occur ''last'' in order to release them for use in another transaction. The party wanting to spend them must provide the input(s) to the previously recorded script that results in those operations occurring last leaving behind true (non-zero).<br />
<br />
Scripts are big-endian.<br />
<br />
The stacks hold byte vectors. Byte vectors are interpreted as little-endian variable-length integers with the most significant bit determining the sign of the integer. Thus 0x81 represents -1. 0x80 is another representation of zero (so called negative 0). Byte vectors are interpreted as Booleans where False is represented by any representation of zero, and True is represented by any representation of non-zero.<br />
<br />
== Words ==<br />
This is a list of all Script words (commands/functions). Some of the more complicated opcodes are disabled out of concern that the client might have a bug in their implementation; if a transaction using such an opcode were to be included in the chain any fix would risk forking the chain. <br />
<br />
True=1 and False=0.<br />
<br />
=== Constants ===<br />
When talking about scripts, these value-pushing words are usually omitted.<br />
<br />
{| class="wikitable"<br />
|-<br />
!Word<br />
!Opcode<br />
!Hex<br />
!Input<br />
!Output<br />
!Description<br />
|-<br />
|OP_0, OP_FALSE<br />
|0<br />
|0x00<br />
|Nothing.<br />
|(empty value)<br />
|An empty array of bytes is pushed onto the stack. (This is not a no-op: an item is added to the stack.)<br />
|-<br />
|N/A<br />
|1-75<br />
|0x01-0x4b<br />
|(special)<br />
|data<br />
|The next ''opcode'' bytes is data to be pushed onto the stack<br />
|-<br />
|OP_PUSHDATA1<br />
|76<br />
|0x4c<br />
|(special)<br />
|data<br />
|The next byte contains the number of bytes to be pushed onto the stack.<br />
|-<br />
|OP_PUSHDATA2<br />
|77<br />
|0x4d<br />
|(special)<br />
|data<br />
|The next two bytes contain the number of bytes to be pushed onto the stack.<br />
|-<br />
|OP_PUSHDATA4<br />
|78<br />
|0x4e<br />
|(special)<br />
|data<br />
|The next four bytes contain the number of bytes to be pushed onto the stack.<br />
|-<br />
|OP_1NEGATE<br />
|79<br />
|0x4f<br />
|Nothing.<br />
| -1<br />
|The number -1 is pushed onto the stack.<br />
|-<br />
|OP_1, OP_TRUE<br />
|81<br />
|0x51<br />
|Nothing.<br />
|1<br />
|The number 1 is pushed onto the stack.<br />
|-<br />
|OP_2-OP_16<br />
|82-96<br />
|0x52-0x60<br />
|Nothing.<br />
|2-16<br />
|The number in the word name (2-16) is pushed onto the stack.<br />
|}<br />
<br />
=== Flow control ===<br />
<br />
{| class="wikitable"<br />
|-<br />
!Word<br />
!Opcode<br />
!Hex<br />
!Input<br />
!Output<br />
!Description<br />
|-<br />
|OP_NOP<br />
|97<br />
|0x61<br />
|Nothing<br />
|Nothing<br />
|Does nothing.<br />
|-<br />
|OP_IF<br />
|99<br />
|0x63<br />
| colspan="2"|<expression> if [statements] [else [statements]]* endif<br />
|If the top stack value is not 0, the statements are executed. The top stack value is removed.<br />
|-<br />
|OP_NOTIF<br />
|100<br />
|0x64<br />
| colspan="2"|<expression> if [statements] [else [statements]]* endif<br />
|If the top stack value is 0, the statements are executed. The top stack value is removed.<br />
|-<br />
|OP_ELSE<br />
|103<br />
|0x67<br />
| colspan="2"|<expression> if [statements] [else [statements]]* endif<br />
|If the preceding OP_IF or OP_NOTIF or OP_ELSE was not executed then these statements are and if the preceding OP_IF or OP_NOTIF or OP_ELSE was executed then these statements are not. <br />
|-<br />
|OP_ENDIF<br />
|104<br />
|0x68<br />
| colspan="2"|<expression> if [statements] [else [statements]]* endif<br />
|Ends an if/else block.<br />
|-<br />
|OP_VERIFY<br />
|105<br />
|0x69<br />
|True / false<br />
|Nothing / False<br />
|'''Marks transaction as invalid''' if top stack value is not true. True is removed, but false is not.<br />
|-<br />
|OP_RETURN<br />
|106<br />
|0x6a<br />
|Nothing<br />
|Nothing<br />
|'''Marks transaction as invalid'''. <br />
|}<br />
<br />
=== Stack ===<br />
<br />
{| class="wikitable" <br />
|-<br />
!Word<br />
!Opcode<br />
!Hex<br />
!Input<br />
!Output<br />
!Description<br />
|-<br />
|OP_TOALTSTACK<br />
|107<br />
|0x6b<br />
|x1<br />
|(alt)x1<br />
|Puts the input onto the top of the alt stack. Removes it from the main stack.<br />
|-<br />
|OP_FROMALTSTACK<br />
|108<br />
|0x6c<br />
|(alt)x1<br />
|x1<br />
|Puts the input onto the top of the main stack. Removes it from the alt stack.<br />
|-<br />
|OP_IFDUP<br />
|115<br />
|0x73<br />
|x<br />
|x / x x<br />
|If the top stack value is not 0, duplicate it.<br />
|-<br />
|OP_DEPTH<br />
|116<br />
|0x74<br />
|Nothing<br />
|<Stack size><br />
|Puts the number of stack items onto the stack.<br />
|-<br />
|OP_DROP<br />
|117<br />
|0x75<br />
|x<br />
|Nothing<br />
|Removes the top stack item.<br />
|-<br />
|OP_DUP<br />
|118<br />
|0x76<br />
|x<br />
|x x<br />
|Duplicates the top stack item.<br />
|-<br />
|OP_NIP<br />
|119<br />
|0x77<br />
|x1 x2<br />
|x2<br />
|Removes the second-to-top stack item.<br />
|-<br />
|OP_OVER<br />
|120<br />
|0x78<br />
|x1 x2<br />
|x1 x2 x1<br />
|Copies the second-to-top stack item to the top.<br />
|-<br />
|OP_PICK<br />
|121<br />
|0x79<br />
|xn ... x2 x1 x0 <n><br />
|xn ... x2 x1 x0 xn<br />
|The item ''n'' back in the stack is copied to the top.<br />
|-<br />
|OP_ROLL<br />
|122<br />
|0x7a<br />
|xn ... x2 x1 x0 <n><br />
|... x2 x1 x0 xn<br />
|The item ''n'' back in the stack is moved to the top.<br />
|-<br />
|OP_ROT<br />
|123<br />
|0x7b<br />
|x1 x2 x3<br />
|x2 x3 x1<br />
|The top three items on the stack are rotated to the left.<br />
|-<br />
|OP_SWAP<br />
|124<br />
|0x7c<br />
|x1 x2<br />
|x2 x1<br />
|The top two items on the stack are swapped.<br />
|-<br />
|OP_TUCK<br />
|125<br />
|0x7d<br />
|x1 x2<br />
|x2 x1 x2<br />
|The item at the top of the stack is copied and inserted before the second-to-top item.<br />
|-<br />
|OP_2DROP<br />
|109<br />
|0x6d<br />
|x1 x2<br />
|Nothing<br />
|Removes the top two stack items.<br />
|-<br />
|OP_2DUP<br />
|110<br />
|0x6e<br />
|x1 x2<br />
|x1 x2 x1 x2<br />
|Duplicates the top two stack items.<br />
|-<br />
|OP_3DUP<br />
|111<br />
|0x6f<br />
|x1 x2 x3<br />
|x1 x2 x3 x1 x2 x3<br />
|Duplicates the top three stack items.<br />
|-<br />
|OP_2OVER<br />
|112<br />
|0x70<br />
|x1 x2 x3 x4<br />
|x1 x2 x3 x4 x1 x2<br />
|Copies the pair of items two spaces back in the stack to the front.<br />
|-<br />
|OP_2ROT<br />
|113<br />
|0x71<br />
|x1 x2 x3 x4 x5 x6<br />
|x3 x4 x5 x6 x1 x2<br />
|The fifth and sixth items back are moved to the top of the stack.<br />
|-<br />
|OP_2SWAP<br />
|114<br />
|0x72<br />
|x1 x2 x3 x4<br />
|x3 x4 x1 x2<br />
|Swaps the top two pairs of items.<br />
|}<br />
<br />
=== Splice ===<br />
<br />
If any opcode marked as Currently disabled is present in a script, it should abort and fail.<br />
<br />
{| class="wikitable" <br />
|-<br />
!Word<br />
!Opcode<br />
!Hex<br />
!Input<br />
!Output<br />
!Description<br />
|-<br />
|OP_CAT<br />
|126<br />
|0x7e<br />
|x1 x2<br />
|out<br />
|style="background:#D97171;"|Concatenates two strings. ''Currently disabled.''<br />
|-<br />
|OP_SUBSTR<br />
|127<br />
|0x7f<br />
|in begin size<br />
|out<br />
|style="background:#D97171;"|Returns a section of a string. ''Currently disabled.''<br />
|-<br />
|OP_LEFT<br />
|128<br />
|0x80<br />
|in size<br />
|out<br />
|style="background:#D97171;"|Keeps only characters left of the specified point in a string. ''Currently disabled.''<br />
|-<br />
|OP_RIGHT<br />
|129<br />
|0x81<br />
|in size<br />
|out<br />
|style="background:#D97171;"|Keeps only characters right of the specified point in a string. ''Currently disabled.''<br />
|-<br />
|OP_SIZE<br />
|130<br />
|0x82<br />
|in<br />
|in size<br />
|Returns the length of the input string.<br />
|}<br />
<br />
=== Bitwise logic ===<br />
<br />
If any opcode marked as Currently disabled is present in a script, it should abort and fail.<br />
<br />
{| class="wikitable" <br />
|-<br />
!Word<br />
!Opcode<br />
!Hex<br />
!Input<br />
!Output<br />
!Description<br />
|-<br />
|OP_INVERT<br />
|131<br />
|0x83<br />
|in<br />
|out<br />
|style="background:#D97171;"|Flips all of the bits in the input. ''Currently disabled.''<br />
|-<br />
|OP_AND<br />
|132<br />
|0x84<br />
|x1 x2<br />
|out<br />
|style="background:#D97171;"|Boolean ''and'' between each bit in the inputs. ''Currently disabled.''<br />
|-<br />
|OP_OR<br />
|133<br />
|0x85<br />
|x1 x2<br />
|out<br />
|style="background:#D97171;"|Boolean ''or'' between each bit in the inputs. ''Currently disabled.''<br />
|-<br />
|OP_XOR<br />
|134<br />
|0x86<br />
|x1 x2<br />
|out<br />
|style="background:#D97171;"|Boolean ''exclusive or'' between each bit in the inputs. ''Currently disabled.''<br />
|-<br />
|OP_EQUAL<br />
|135<br />
|0x87<br />
|x1 x2<br />
|True / false<br />
|Returns 1 if the inputs are exactly equal, 0 otherwise.<br />
|-<br />
|OP_EQUALVERIFY<br />
|136<br />
|0x88<br />
|x1 x2<br />
|True / false<br />
|Same as OP_EQUAL, but runs OP_VERIFY afterward.<br />
|}<br />
<br />
=== Arithmetic ===<br />
<br />
Note: Arithmetic inputs are limited to signed 32-bit integers, but may overflow their output.<br />
<br />
If any input value for any of these commands is longer than 4 bytes, the script should abort and fail. <br />
If any opcode marked as ''Currently disabled'' is present in a script - it should also abort and fail.<br />
<br />
{| class="wikitable" <br />
|-<br />
!Word<br />
!Opcode<br />
!Hex<br />
!Input<br />
!Output<br />
!Description<br />
|-<br />
|OP_1ADD<br />
|139<br />
|0x8b<br />
|in<br />
|out<br />
|1 is added to the input.<br />
|-<br />
|OP_1SUB<br />
|140<br />
|0x8c<br />
|in<br />
|out<br />
|1 is subtracted from the input.<br />
|-<br />
|OP_2MUL<br />
|141<br />
|0x8d<br />
|in<br />
|out<br />
|style="background:#D97171;"|The input is multiplied by 2. ''Currently disabled.''<br />
|-<br />
|OP_2DIV<br />
|142<br />
|0x8e<br />
|in<br />
|out<br />
|style="background:#D97171;"|The input is divided by 2. ''Currently disabled.''<br />
|-<br />
|OP_NEGATE<br />
|143<br />
|0x8f<br />
|in<br />
|out<br />
|The sign of the input is flipped.<br />
|-<br />
|OP_ABS<br />
|144<br />
|0x90<br />
|in<br />
|out<br />
|The input is made positive.<br />
|-<br />
|OP_NOT<br />
|145<br />
|0x91<br />
|in<br />
|out<br />
|If the input is 0 or 1, it is flipped. Otherwise the output will be 0.<br />
|-<br />
|OP_0NOTEQUAL<br />
|146<br />
|0x92<br />
|in<br />
|out<br />
|Returns 0 if the input is 0. 1 otherwise.<br />
|-<br />
|OP_ADD<br />
|147<br />
|0x93<br />
|a b<br />
|out<br />
|a is added to b.<br />
|-<br />
|OP_SUB<br />
|148<br />
|0x94<br />
|a b<br />
|out<br />
|b is subtracted from a.<br />
|-<br />
|OP_MUL<br />
|149<br />
|0x95<br />
|a b<br />
|out<br />
|style="background:#D97171;"|a is multiplied by b. ''Currently disabled.''<br />
|-<br />
|OP_DIV<br />
|150<br />
|0x96<br />
|a b<br />
|out<br />
|style="background:#D97171;"|a is divided by b. ''Currently disabled.''<br />
|-<br />
|OP_MOD<br />
|151<br />
|0x97<br />
|a b<br />
|out<br />
|style="background:#D97171;"|Returns the remainder after dividing a by b. ''Currently disabled.''<br />
|-<br />
|OP_LSHIFT<br />
|152<br />
|0x98<br />
|a b<br />
|out<br />
|style="background:#D97171;"|Shifts a left b bits, preserving sign. ''Currently disabled.''<br />
|-<br />
|OP_RSHIFT<br />
|153<br />
|0x99<br />
|a b<br />
|out<br />
|style="background:#D97171;"|Shifts a right b bits, preserving sign. ''Currently disabled.''<br />
|-<br />
|OP_BOOLAND<br />
|154<br />
|0x9a<br />
|a b<br />
|out<br />
|If both a and b are not 0, the output is 1. Otherwise 0.<br />
|-<br />
|OP_BOOLOR<br />
|155<br />
|0x9b<br />
|a b<br />
|out<br />
|If a or b is not 0, the output is 1. Otherwise 0.<br />
|-<br />
|OP_NUMEQUAL<br />
|156<br />
|0x9c<br />
|a b<br />
|out<br />
|Returns 1 if the numbers are equal, 0 otherwise.<br />
|-<br />
|OP_NUMEQUALVERIFY<br />
|157<br />
|0x9d<br />
|a b<br />
|out<br />
|Same as OP_NUMEQUAL, but runs OP_VERIFY afterward.<br />
|-<br />
|OP_NUMNOTEQUAL<br />
|158<br />
|0x9e<br />
|a b<br />
|out<br />
|Returns 1 if the numbers are not equal, 0 otherwise.<br />
|-<br />
|OP_LESSTHAN<br />
|159<br />
|0x9f<br />
|a b<br />
|out<br />
|Returns 1 if a is less than b, 0 otherwise.<br />
|-<br />
|OP_GREATERTHAN<br />
|160<br />
|0xa0<br />
|a b<br />
|out<br />
|Returns 1 if a is greater than b, 0 otherwise.<br />
|-<br />
|OP_LESSTHANOREQUAL<br />
|161<br />
|0xa1<br />
|a b<br />
|out<br />
|Returns 1 if a is less than or equal to b, 0 otherwise.<br />
|-<br />
|OP_GREATERTHANOREQUAL<br />
|162<br />
|0xa2<br />
|a b<br />
|out<br />
|Returns 1 if a is greater than or equal to b, 0 otherwise.<br />
|-<br />
|OP_MIN<br />
|163<br />
|0xa3<br />
|a b<br />
|out<br />
|Returns the smaller of a and b.<br />
|-<br />
|OP_MAX<br />
|164<br />
|0xa4<br />
|a b<br />
|out<br />
|Returns the larger of a and b.<br />
|-<br />
|OP_WITHIN<br />
|165<br />
|0xa5<br />
|x min max<br />
|out<br />
|Returns 1 if x is within the specified range (left-inclusive), 0 otherwise.<br />
|}<br />
<br />
=== Crypto ===<br />
<br />
{| class="wikitable" <br />
|-<br />
!Word<br />
!Opcode<br />
!Hex<br />
!Input<br />
!Output<br />
!Description<br />
|-<br />
|OP_RIPEMD160<br />
|166<br />
|0xa6<br />
|in<br />
|hash<br />
|The input is hashed using RIPEMD-160.<br />
|-<br />
|OP_SHA1<br />
|167<br />
|0xa7<br />
|in<br />
|hash<br />
|The input is hashed using SHA-1.<br />
|-<br />
|OP_SHA256<br />
|168<br />
|0xa8<br />
|in<br />
|hash<br />
|The input is hashed using SHA-256.<br />
|-<br />
|OP_HASH160<br />
|169<br />
|0xa9<br />
|in<br />
|hash<br />
|The input is hashed twice: first with SHA-256 and then with RIPEMD-160.<br />
|-<br />
|OP_HASH256<br />
|170<br />
|0xaa<br />
|in<br />
|hash<br />
|The input is hashed two times with SHA-256.<br />
|-<br />
|OP_CODESEPARATOR<br />
|171<br />
|0xab<br />
|Nothing<br />
|Nothing<br />
|All of the signature checking words will only match signatures to the data after the most recently-executed OP_CODESEPARATOR.<br />
|-<br />
|[[OP_CHECKSIG]]<br />
|172<br />
|0xac<br />
|sig pubkey<br />
|True / false<br />
|The entire transaction's outputs, inputs, and script (from the most recently-executed OP_CODESEPARATOR to the end) are hashed. The signature used by OP_CHECKSIG must be a valid signature for this hash and public key. If it is, 1 is returned, 0 otherwise.<br />
|-<br />
|OP_CHECKSIGVERIFY<br />
|173<br />
|0xad<br />
|sig pubkey<br />
|True / false<br />
|Same as OP_CHECKSIG, but OP_VERIFY is executed afterward.<br />
|-<br />
|OP_CHECKMULTISIG<br />
|174<br />
|0xae<br />
|x sig1 sig2 ... <number of signatures> pub1 pub2 <number of public keys><br />
|True / False<br />
|For each signature and public key pair, OP_CHECKSIG is executed. If more public keys than signatures are listed, some key/sig pairs can fail. All signatures need to match a public key. If all signatures are valid, 1 is returned, 0 otherwise. Due to a bug, one extra unused value is removed from the stack.<br />
|-<br />
|OP_CHECKMULTISIGVERIFY<br />
|175<br />
|0xaf<br />
|x sig1 sig2 ... <number of signatures> pub1 pub2 ... <number of public keys><br />
|True / False<br />
|Same as OP_CHECKMULTISIG, but OP_VERIFY is executed afterward.<br />
|}<br />
<br />
===Pseudo-words===<br />
These words are used internally for assisting with transaction matching. They are invalid if used in actual scripts.<br />
{| class="wikitable" <br />
|-<br />
!Word<br />
!Opcode<br />
!Hex<br />
!Description<br />
|-<br />
|OP_PUBKEYHASH<br />
|253<br />
|0xfd<br />
|Represents a public key hashed with OP_HASH160.<br />
|-<br />
|OP_PUBKEY<br />
|254<br />
|0xfe<br />
|Represents a public key compatible with OP_CHECKSIG.<br />
|-<br />
|OP_INVALIDOPCODE<br />
|255<br />
|0xff<br />
|Matches any opcode that is not yet assigned.<br />
|}<br />
<br />
=== Reserved words ===<br />
Any opcode not assigned is also reserved. Using an unassigned opcode makes the transaction invalid.<br />
<br />
{| class="wikitable" <br />
|-<br />
!Word<br />
!Opcode<br />
!Hex<br />
!When used...<br />
|-<br />
|OP_RESERVED<br />
|80<br />
|0x50<br />
|Transaction is invalid unless occuring in an unexecuted OP_IF branch<br />
|-<br />
|OP_VER<br />
|98<br />
|0x62<br />
|Transaction is invalid unless occuring in an unexecuted OP_IF branch<br />
|-<br />
|OP_VERIF<br />
|101<br />
|0x65<br />
|Transaction is invalid even when occuring in an unexecuted OP_IF branch<br />
|-<br />
|OP_VERNOTIF<br />
|102<br />
|0x66<br />
|Transaction is invalid even when occuring in an unexecuted OP_IF branch<br />
|-<br />
|OP_RESERVED1<br />
|137<br />
|0x89<br />
|Transaction is invalid unless occuring in an unexecuted OP_IF branch<br />
|-<br />
|OP_RESERVED2<br />
|138<br />
|0x8a<br />
|Transaction is invalid unless occuring in an unexecuted OP_IF branch<br />
|-<br />
|OP_NOP1-OP_NOP10<br />
|176-185<br />
|0xb0-0xb9<br />
|The word is ignored.<br />
|}<br />
<br />
== Scripts ==<br />
This is a list of interesting scripts. Keep in mind that all constants actually use the data-pushing commands above. Note that there is a small number of standard script forms that are relayed from node to node; non-standard scripts are accepted if they are in a block, but nodes will not relay them.<br />
<br />
=== Standard Transaction to Bitcoin address (pay-to-script-hash) ===<br />
<br />
scriptPubKey: OP_DUP OP_HASH160 <pubKeyHash> OP_EQUALVERIFY OP_CHECKSIG<br />
scriptSig: <sig> <pubKey><br />
<br />
To demonstrate how scripts look on the wire, here is a raw scriptPubKey:<br />
<pre> 76 A9 14<br />
OP_DUP OP_HASH160 Bytes to push<br />
<br />
89 AB CD EF AB BA AB BA AB BA AB BA AB BA AB BA AB BA AB BA 88 AC<br />
Data to push OP_EQUALVERIFY OP_CHECKSIG</pre><br />
<br />
Note: scriptSig is in the input of the spending transaction and scriptPubKey is in the output of the previously unspent i.e. "available" transaction.<br />
<br />
Here is how each word is processed:<br />
{| class="wikitable" <br />
|-<br />
! Stack <br />
! Script <br />
! Description <br />
|-<br />
|Empty.<br />
| <sig> <pubKey> OP_DUP OP_HASH160 <pubKeyHash> OP_EQUALVERIFY OP_CHECKSIG <br />
| scriptSig and scriptPubKey are combined.<br />
|-<br />
|<sig> <pubKey><br />
| OP_DUP OP_HASH160 <pubKeyHash> OP_EQUALVERIFY OP_CHECKSIG <br />
| Constants are added to the stack.<br />
|-<br />
|<sig> <pubKey> <pubKey><br />
| OP_HASH160 <pubKeyHash> OP_EQUALVERIFY OP_CHECKSIG <br />
| Top stack item is duplicated.<br />
|-<br />
|<sig> <pubKey> <pubHashA><br />
|<pubKeyHash> OP_EQUALVERIFY OP_CHECKSIG<br />
| Top stack item is hashed.<br />
|-<br />
|<sig> <pubKey> <pubHashA> <pubKeyHash><br />
|OP_EQUALVERIFY OP_CHECKSIG<br />
| Constant added.<br />
|-<br />
|<sig> <pubKey><br />
|OP_CHECKSIG<br />
| Equality is checked between the top two stack items.<br />
|-<br />
|true<br />
|Empty.<br />
|Signature is checked for top two stack items.<br />
|}<br />
<br />
=== Standard Generation Transaction ===<br />
<br />
OP_CHECKSIG is used directly without first hashing the public key. By default the reference implementation uses this form for coinbase payment, and scriptPubKeys of this transaction form are recognized as payments to user. The disadvantage of this transaction form is that the whole public key needs to be known in advance, implying longer payment addresses, and that it provides less protection in the event of a break in the ECDSA signature algorithm.<br />
<br />
scriptPubKey: <pubKey> OP_CHECKSIG<br />
scriptSig: <sig><br />
<br />
Checking process:<br />
{| class="wikitable" <br />
|-<br />
! Stack <br />
! Script <br />
! Description <br />
|-<br />
|Empty.<br />
|<sig> <pubKey> OP_CHECKSIG<br />
|scriptSig and scriptPubKey are combined.<br />
|-<br />
|<sig> <pubKey><br />
| OP_CHECKSIG<br />
|Constants are added to the stack.<br />
|-<br />
|true<br />
|Empty.<br />
|Signature is checked for top two stack items.<br />
|}<br />
<br />
=== Provably Unspendable/Prunable Outputs ===<br />
<br />
The standard way to mark a transaction as provably unspendable is with a scriptPubKey of the following form:<br />
<br />
scriptPubKey: OP_RETURN {zero or more ops}<br />
<br />
OP_RETURN immediately marks the script as invalid, guaranteeing that no scriptSig exists that could possibly spend that output. Thus the output can be immediately pruned from the UTXO set even if it has not been spent. eb31ca1a4cbd97c2770983164d7560d2d03276ae1aee26f12d7c2c6424252f29 is an example, and acts to donate 0.125BTC to the miner who mined the transaction. Another use is to add data to a transaction, as seen in 1a2e22a717d626fc5db363582007c46924ae6b28319f07cb1b907776bd8293fc. [[P2Pool]] uses OP_RETURN so that their share chain hash txout in the coinbase of blocks it creates does not clutter the UTXO space.<br />
<br />
Note that this mechanism is not yet a standard transaction type, and thus will not be relayed by nodes on mainnet.<br />
<br />
=== Anyone-Can-Spend Outputs ===<br />
<br />
Conversely a transaction can be made spendable by anyone at all:<br />
<br />
scriptPubKey: (empty)<br />
scriptSig: OP_TRUE<br />
<br />
With some software changes such transactions can be used as a way to donate funds to miners in addition to transaction fees: any miner who mines such a transaction can also include an additional one after it sending the funds to an address they control. This mechanism may be used in the future for [[fidelity bonds]] to sacrifice funds in a provable way.<br />
<br />
Anyone-Can-Spend outputs are currently considered non-standard, and are not relayed on the P2P network.<br />
<br />
=== Transaction puzzle ===<br />
<br />
Transaction a4bfa8ab6435ae5f25dae9d89e4eb67dfa94283ca751f393c1ddc5a837bbc31b is an interesting puzzle.<br />
<br />
scriptPubKey: OP_HASH256 6fe28c0ab6f1b372c1a6a246ae63f74f931e8365e15a089c68d6190000000000 OP_EQUAL<br />
scriptSig: <data><br />
<br />
To spend the transaction you need to come up with some data such that hashing the data twice results in the given hash.<br />
<br />
{| class="wikitable" <br />
|-<br />
! Stack <br />
! Script <br />
! Description <br />
|-<br />
|Empty.<br />
|<data> OP_HASH256 <given_hash> OP_EQUAL<br />
|<br />
|-<br />
|<data><br />
|OP_HASH256 <given_hash> OP_EQUAL<br />
|scriptSig added to the stack.<br />
|-<br />
|<data_hash><br />
|<given_hash> OP_EQUAL<br />
|The data is hashed.<br />
|-<br />
|<data_hash> <given_hash><br />
|OP_EQUAL<br />
|The given hash is pushed to the stack.<br />
|-<br />
|true<br />
|Empty.<br />
|The hashes are compared, leaving true on the stack.<br />
|}<br />
<br />
This transaction was successfully spent by 09f691b2263260e71f363d1db51ff3100d285956a40cc0e4f8c8c2c4a80559b1. The required data happened to be the [[Genesis block]], and the given hash was the genesis block hash. Note that while transactions like this are fun, they are not secure, because they do not contain any signatures and thus any transaction attempting to spend them can be replaced with a different transaction sending the funds somewhere else.<br />
<br />
==See Also==<br />
<br />
* [[Transactions]]<br />
* [[Contracts]]<br />
<br />
<br />
[[Category:Technical]]<br />
[[Category:Vocabulary]]</div>Petertoddhttps://en.bitcoin.it/w/index.php?title=Script&diff=39690Script2013-07-20T06:37:36Z<p>Petertodd: /* Provably Unspendable/Prunable Outputs */</p>
<hr />
<div>Bitcoin uses a scripting system for [[transactions]]. [[Wikipedia:FORTH|Forth]]-like, Script is simple, stack-based, and processed from left to right. It is purposefully not Turing-complete, with no loops.<br />
<br />
A script is essentially a list of instructions recorded with each transaction that describe how the next person wanting to spend the Bitcoins being transferred can gain access to them. The script for a typical Bitcoin transfer to destination Bitcoin address D simply encumbers future spending of the bitcoins with two things: the spender must provide<br />
# a public key that, when hashed, yields destination address D embedded in the script, and<br />
# a signature to show evidence of the private key corresponding to the public key just provided.<br />
<br />
Scripting provides the flexibility to change the parameters of what's needed to spend transferred Bitcoins. For example, the scripting system could be used to require two private keys, or a combination of several, or even no keys at all.<br />
<br />
A transaction is valid if nothing in the combined script triggers failure and the top stack item is true (non-zero). The party who originally ''sent'' the Bitcoins now being spent, dictates the script operations that will occur ''last'' in order to release them for use in another transaction. The party wanting to spend them must provide the input(s) to the previously recorded script that results in those operations occurring last leaving behind true (non-zero).<br />
<br />
Scripts are big-endian.<br />
<br />
The stacks hold byte vectors. Byte vectors are interpreted as little-endian variable-length integers with the most significant bit determining the sign of the integer. Thus 0x81 represents -1. 0x80 is another representation of zero (so called negative 0). Byte vectors are interpreted as Booleans where False is represented by any representation of zero, and True is represented by any representation of non-zero.<br />
<br />
== Words ==<br />
This is a list of all Script words (commands/functions). Some of the more complicated opcodes are disabled out of concern that the client might have a bug in their implementation; if a transaction using such an opcode were to be included in the chain any fix would risk forking the chain. <br />
<br />
True=1 and False=0.<br />
<br />
=== Constants ===<br />
When talking about scripts, these value-pushing words are usually omitted.<br />
<br />
{| class="wikitable"<br />
|-<br />
!Word<br />
!Opcode<br />
!Hex<br />
!Input<br />
!Output<br />
!Description<br />
|-<br />
|OP_0, OP_FALSE<br />
|0<br />
|0x00<br />
|Nothing.<br />
|(empty value)<br />
|An empty array of bytes is pushed onto the stack. (This is not a no-op: an item is added to the stack.)<br />
|-<br />
|N/A<br />
|1-75<br />
|0x01-0x4b<br />
|(special)<br />
|data<br />
|The next ''opcode'' bytes is data to be pushed onto the stack<br />
|-<br />
|OP_PUSHDATA1<br />
|76<br />
|0x4c<br />
|(special)<br />
|data<br />
|The next byte contains the number of bytes to be pushed onto the stack.<br />
|-<br />
|OP_PUSHDATA2<br />
|77<br />
|0x4d<br />
|(special)<br />
|data<br />
|The next two bytes contain the number of bytes to be pushed onto the stack.<br />
|-<br />
|OP_PUSHDATA4<br />
|78<br />
|0x4e<br />
|(special)<br />
|data<br />
|The next four bytes contain the number of bytes to be pushed onto the stack.<br />
|-<br />
|OP_1NEGATE<br />
|79<br />
|0x4f<br />
|Nothing.<br />
| -1<br />
|The number -1 is pushed onto the stack.<br />
|-<br />
|OP_1, OP_TRUE<br />
|81<br />
|0x51<br />
|Nothing.<br />
|1<br />
|The number 1 is pushed onto the stack.<br />
|-<br />
|OP_2-OP_16<br />
|82-96<br />
|0x52-0x60<br />
|Nothing.<br />
|2-16<br />
|The number in the word name (2-16) is pushed onto the stack.<br />
|}<br />
<br />
=== Flow control ===<br />
<br />
{| class="wikitable"<br />
|-<br />
!Word<br />
!Opcode<br />
!Hex<br />
!Input<br />
!Output<br />
!Description<br />
|-<br />
|OP_NOP<br />
|97<br />
|0x61<br />
|Nothing<br />
|Nothing<br />
|Does nothing.<br />
|-<br />
|OP_IF<br />
|99<br />
|0x63<br />
| colspan="2"|<expression> if [statements] [else [statements]]* endif<br />
|If the top stack value is not 0, the statements are executed. The top stack value is removed.<br />
|-<br />
|OP_NOTIF<br />
|100<br />
|0x64<br />
| colspan="2"|<expression> if [statements] [else [statements]]* endif<br />
|If the top stack value is 0, the statements are executed. The top stack value is removed.<br />
|-<br />
|OP_ELSE<br />
|103<br />
|0x67<br />
| colspan="2"|<expression> if [statements] [else [statements]]* endif<br />
|If the preceding OP_IF or OP_NOTIF or OP_ELSE was not executed then these statements are and if the preceding OP_IF or OP_NOTIF or OP_ELSE was executed then these statements are not. <br />
|-<br />
|OP_ENDIF<br />
|104<br />
|0x68<br />
| colspan="2"|<expression> if [statements] [else [statements]]* endif<br />
|Ends an if/else block.<br />
|-<br />
|OP_VERIFY<br />
|105<br />
|0x69<br />
|True / false<br />
|Nothing / False<br />
|'''Marks transaction as invalid''' if top stack value is not true. True is removed, but false is not.<br />
|-<br />
|OP_RETURN<br />
|106<br />
|0x6a<br />
|Nothing<br />
|Nothing<br />
|'''Marks transaction as invalid'''. <br />
|}<br />
<br />
=== Stack ===<br />
<br />
{| class="wikitable" <br />
|-<br />
!Word<br />
!Opcode<br />
!Hex<br />
!Input<br />
!Output<br />
!Description<br />
|-<br />
|OP_TOALTSTACK<br />
|107<br />
|0x6b<br />
|x1<br />
|(alt)x1<br />
|Puts the input onto the top of the alt stack. Removes it from the main stack.<br />
|-<br />
|OP_FROMALTSTACK<br />
|108<br />
|0x6c<br />
|(alt)x1<br />
|x1<br />
|Puts the input onto the top of the main stack. Removes it from the alt stack.<br />
|-<br />
|OP_IFDUP<br />
|115<br />
|0x73<br />
|x<br />
|x / x x<br />
|If the top stack value is not 0, duplicate it.<br />
|-<br />
|OP_DEPTH<br />
|116<br />
|0x74<br />
|Nothing<br />
|<Stack size><br />
|Puts the number of stack items onto the stack.<br />
|-<br />
|OP_DROP<br />
|117<br />
|0x75<br />
|x<br />
|Nothing<br />
|Removes the top stack item.<br />
|-<br />
|OP_DUP<br />
|118<br />
|0x76<br />
|x<br />
|x x<br />
|Duplicates the top stack item.<br />
|-<br />
|OP_NIP<br />
|119<br />
|0x77<br />
|x1 x2<br />
|x2<br />
|Removes the second-to-top stack item.<br />
|-<br />
|OP_OVER<br />
|120<br />
|0x78<br />
|x1 x2<br />
|x1 x2 x1<br />
|Copies the second-to-top stack item to the top.<br />
|-<br />
|OP_PICK<br />
|121<br />
|0x79<br />
|xn ... x2 x1 x0 <n><br />
|xn ... x2 x1 x0 xn<br />
|The item ''n'' back in the stack is copied to the top.<br />
|-<br />
|OP_ROLL<br />
|122<br />
|0x7a<br />
|xn ... x2 x1 x0 <n><br />
|... x2 x1 x0 xn<br />
|The item ''n'' back in the stack is moved to the top.<br />
|-<br />
|OP_ROT<br />
|123<br />
|0x7b<br />
|x1 x2 x3<br />
|x2 x3 x1<br />
|The top three items on the stack are rotated to the left.<br />
|-<br />
|OP_SWAP<br />
|124<br />
|0x7c<br />
|x1 x2<br />
|x2 x1<br />
|The top two items on the stack are swapped.<br />
|-<br />
|OP_TUCK<br />
|125<br />
|0x7d<br />
|x1 x2<br />
|x2 x1 x2<br />
|The item at the top of the stack is copied and inserted before the second-to-top item.<br />
|-<br />
|OP_2DROP<br />
|109<br />
|0x6d<br />
|x1 x2<br />
|Nothing<br />
|Removes the top two stack items.<br />
|-<br />
|OP_2DUP<br />
|110<br />
|0x6e<br />
|x1 x2<br />
|x1 x2 x1 x2<br />
|Duplicates the top two stack items.<br />
|-<br />
|OP_3DUP<br />
|111<br />
|0x6f<br />
|x1 x2 x3<br />
|x1 x2 x3 x1 x2 x3<br />
|Duplicates the top three stack items.<br />
|-<br />
|OP_2OVER<br />
|112<br />
|0x70<br />
|x1 x2 x3 x4<br />
|x1 x2 x3 x4 x1 x2<br />
|Copies the pair of items two spaces back in the stack to the front.<br />
|-<br />
|OP_2ROT<br />
|113<br />
|0x71<br />
|x1 x2 x3 x4 x5 x6<br />
|x3 x4 x5 x6 x1 x2<br />
|The fifth and sixth items back are moved to the top of the stack.<br />
|-<br />
|OP_2SWAP<br />
|114<br />
|0x72<br />
|x1 x2 x3 x4<br />
|x3 x4 x1 x2<br />
|Swaps the top two pairs of items.<br />
|}<br />
<br />
=== Splice ===<br />
<br />
If any opcode marked as Currently disabled is present in a script, it should abort and fail.<br />
<br />
{| class="wikitable" <br />
|-<br />
!Word<br />
!Opcode<br />
!Hex<br />
!Input<br />
!Output<br />
!Description<br />
|-<br />
|OP_CAT<br />
|126<br />
|0x7e<br />
|x1 x2<br />
|out<br />
|style="background:#D97171;"|Concatenates two strings. ''Currently disabled.''<br />
|-<br />
|OP_SUBSTR<br />
|127<br />
|0x7f<br />
|in begin size<br />
|out<br />
|style="background:#D97171;"|Returns a section of a string. ''Currently disabled.''<br />
|-<br />
|OP_LEFT<br />
|128<br />
|0x80<br />
|in size<br />
|out<br />
|style="background:#D97171;"|Keeps only characters left of the specified point in a string. ''Currently disabled.''<br />
|-<br />
|OP_RIGHT<br />
|129<br />
|0x81<br />
|in size<br />
|out<br />
|style="background:#D97171;"|Keeps only characters right of the specified point in a string. ''Currently disabled.''<br />
|-<br />
|OP_SIZE<br />
|130<br />
|0x82<br />
|in<br />
|in size<br />
|Returns the length of the input string.<br />
|}<br />
<br />
=== Bitwise logic ===<br />
<br />
If any opcode marked as Currently disabled is present in a script, it should abort and fail.<br />
<br />
{| class="wikitable" <br />
|-<br />
!Word<br />
!Opcode<br />
!Hex<br />
!Input<br />
!Output<br />
!Description<br />
|-<br />
|OP_INVERT<br />
|131<br />
|0x83<br />
|in<br />
|out<br />
|style="background:#D97171;"|Flips all of the bits in the input. ''Currently disabled.''<br />
|-<br />
|OP_AND<br />
|132<br />
|0x84<br />
|x1 x2<br />
|out<br />
|style="background:#D97171;"|Boolean ''and'' between each bit in the inputs. ''Currently disabled.''<br />
|-<br />
|OP_OR<br />
|133<br />
|0x85<br />
|x1 x2<br />
|out<br />
|style="background:#D97171;"|Boolean ''or'' between each bit in the inputs. ''Currently disabled.''<br />
|-<br />
|OP_XOR<br />
|134<br />
|0x86<br />
|x1 x2<br />
|out<br />
|style="background:#D97171;"|Boolean ''exclusive or'' between each bit in the inputs. ''Currently disabled.''<br />
|-<br />
|OP_EQUAL<br />
|135<br />
|0x87<br />
|x1 x2<br />
|True / false<br />
|Returns 1 if the inputs are exactly equal, 0 otherwise.<br />
|-<br />
|OP_EQUALVERIFY<br />
|136<br />
|0x88<br />
|x1 x2<br />
|True / false<br />
|Same as OP_EQUAL, but runs OP_VERIFY afterward.<br />
|}<br />
<br />
=== Arithmetic ===<br />
<br />
Note: Arithmetic inputs are limited to signed 32-bit integers, but may overflow their output.<br />
<br />
If any input value for any of these commands is longer than 4 bytes, the script should abort and fail. <br />
If any opcode marked as ''Currently disabled'' is present in a script - it should also abort and fail.<br />
<br />
{| class="wikitable" <br />
|-<br />
!Word<br />
!Opcode<br />
!Hex<br />
!Input<br />
!Output<br />
!Description<br />
|-<br />
|OP_1ADD<br />
|139<br />
|0x8b<br />
|in<br />
|out<br />
|1 is added to the input.<br />
|-<br />
|OP_1SUB<br />
|140<br />
|0x8c<br />
|in<br />
|out<br />
|1 is subtracted from the input.<br />
|-<br />
|OP_2MUL<br />
|141<br />
|0x8d<br />
|in<br />
|out<br />
|style="background:#D97171;"|The input is multiplied by 2. ''Currently disabled.''<br />
|-<br />
|OP_2DIV<br />
|142<br />
|0x8e<br />
|in<br />
|out<br />
|style="background:#D97171;"|The input is divided by 2. ''Currently disabled.''<br />
|-<br />
|OP_NEGATE<br />
|143<br />
|0x8f<br />
|in<br />
|out<br />
|The sign of the input is flipped.<br />
|-<br />
|OP_ABS<br />
|144<br />
|0x90<br />
|in<br />
|out<br />
|The input is made positive.<br />
|-<br />
|OP_NOT<br />
|145<br />
|0x91<br />
|in<br />
|out<br />
|If the input is 0 or 1, it is flipped. Otherwise the output will be 0.<br />
|-<br />
|OP_0NOTEQUAL<br />
|146<br />
|0x92<br />
|in<br />
|out<br />
|Returns 0 if the input is 0. 1 otherwise.<br />
|-<br />
|OP_ADD<br />
|147<br />
|0x93<br />
|a b<br />
|out<br />
|a is added to b.<br />
|-<br />
|OP_SUB<br />
|148<br />
|0x94<br />
|a b<br />
|out<br />
|b is subtracted from a.<br />
|-<br />
|OP_MUL<br />
|149<br />
|0x95<br />
|a b<br />
|out<br />
|style="background:#D97171;"|a is multiplied by b. ''Currently disabled.''<br />
|-<br />
|OP_DIV<br />
|150<br />
|0x96<br />
|a b<br />
|out<br />
|style="background:#D97171;"|a is divided by b. ''Currently disabled.''<br />
|-<br />
|OP_MOD<br />
|151<br />
|0x97<br />
|a b<br />
|out<br />
|style="background:#D97171;"|Returns the remainder after dividing a by b. ''Currently disabled.''<br />
|-<br />
|OP_LSHIFT<br />
|152<br />
|0x98<br />
|a b<br />
|out<br />
|style="background:#D97171;"|Shifts a left b bits, preserving sign. ''Currently disabled.''<br />
|-<br />
|OP_RSHIFT<br />
|153<br />
|0x99<br />
|a b<br />
|out<br />
|style="background:#D97171;"|Shifts a right b bits, preserving sign. ''Currently disabled.''<br />
|-<br />
|OP_BOOLAND<br />
|154<br />
|0x9a<br />
|a b<br />
|out<br />
|If both a and b are not 0, the output is 1. Otherwise 0.<br />
|-<br />
|OP_BOOLOR<br />
|155<br />
|0x9b<br />
|a b<br />
|out<br />
|If a or b is not 0, the output is 1. Otherwise 0.<br />
|-<br />
|OP_NUMEQUAL<br />
|156<br />
|0x9c<br />
|a b<br />
|out<br />
|Returns 1 if the numbers are equal, 0 otherwise.<br />
|-<br />
|OP_NUMEQUALVERIFY<br />
|157<br />
|0x9d<br />
|a b<br />
|out<br />
|Same as OP_NUMEQUAL, but runs OP_VERIFY afterward.<br />
|-<br />
|OP_NUMNOTEQUAL<br />
|158<br />
|0x9e<br />
|a b<br />
|out<br />
|Returns 1 if the numbers are not equal, 0 otherwise.<br />
|-<br />
|OP_LESSTHAN<br />
|159<br />
|0x9f<br />
|a b<br />
|out<br />
|Returns 1 if a is less than b, 0 otherwise.<br />
|-<br />
|OP_GREATERTHAN<br />
|160<br />
|0xa0<br />
|a b<br />
|out<br />
|Returns 1 if a is greater than b, 0 otherwise.<br />
|-<br />
|OP_LESSTHANOREQUAL<br />
|161<br />
|0xa1<br />
|a b<br />
|out<br />
|Returns 1 if a is less than or equal to b, 0 otherwise.<br />
|-<br />
|OP_GREATERTHANOREQUAL<br />
|162<br />
|0xa2<br />
|a b<br />
|out<br />
|Returns 1 if a is greater than or equal to b, 0 otherwise.<br />
|-<br />
|OP_MIN<br />
|163<br />
|0xa3<br />
|a b<br />
|out<br />
|Returns the smaller of a and b.<br />
|-<br />
|OP_MAX<br />
|164<br />
|0xa4<br />
|a b<br />
|out<br />
|Returns the larger of a and b.<br />
|-<br />
|OP_WITHIN<br />
|165<br />
|0xa5<br />
|x min max<br />
|out<br />
|Returns 1 if x is within the specified range (left-inclusive), 0 otherwise.<br />
|}<br />
<br />
=== Crypto ===<br />
<br />
{| class="wikitable" <br />
|-<br />
!Word<br />
!Opcode<br />
!Hex<br />
!Input<br />
!Output<br />
!Description<br />
|-<br />
|OP_RIPEMD160<br />
|166<br />
|0xa6<br />
|in<br />
|hash<br />
|The input is hashed using RIPEMD-160.<br />
|-<br />
|OP_SHA1<br />
|167<br />
|0xa7<br />
|in<br />
|hash<br />
|The input is hashed using SHA-1.<br />
|-<br />
|OP_SHA256<br />
|168<br />
|0xa8<br />
|in<br />
|hash<br />
|The input is hashed using SHA-256.<br />
|-<br />
|OP_HASH160<br />
|169<br />
|0xa9<br />
|in<br />
|hash<br />
|The input is hashed twice: first with SHA-256 and then with RIPEMD-160.<br />
|-<br />
|OP_HASH256<br />
|170<br />
|0xaa<br />
|in<br />
|hash<br />
|The input is hashed two times with SHA-256.<br />
|-<br />
|OP_CODESEPARATOR<br />
|171<br />
|0xab<br />
|Nothing<br />
|Nothing<br />
|All of the signature checking words will only match signatures to the data after the most recently-executed OP_CODESEPARATOR.<br />
|-<br />
|[[OP_CHECKSIG]]<br />
|172<br />
|0xac<br />
|sig pubkey<br />
|True / false<br />
|The entire transaction's outputs, inputs, and script (from the most recently-executed OP_CODESEPARATOR to the end) are hashed. The signature used by OP_CHECKSIG must be a valid signature for this hash and public key. If it is, 1 is returned, 0 otherwise.<br />
|-<br />
|OP_CHECKSIGVERIFY<br />
|173<br />
|0xad<br />
|sig pubkey<br />
|True / false<br />
|Same as OP_CHECKSIG, but OP_VERIFY is executed afterward.<br />
|-<br />
|OP_CHECKMULTISIG<br />
|174<br />
|0xae<br />
|x sig1 sig2 ... <number of signatures> pub1 pub2 <number of public keys><br />
|True / False<br />
|For each signature and public key pair, OP_CHECKSIG is executed. If more public keys than signatures are listed, some key/sig pairs can fail. All signatures need to match a public key. If all signatures are valid, 1 is returned, 0 otherwise. Due to a bug, one extra unused value is removed from the stack.<br />
|-<br />
|OP_CHECKMULTISIGVERIFY<br />
|175<br />
|0xaf<br />
|x sig1 sig2 ... <number of signatures> pub1 pub2 ... <number of public keys><br />
|True / False<br />
|Same as OP_CHECKMULTISIG, but OP_VERIFY is executed afterward.<br />
|}<br />
<br />
===Pseudo-words===<br />
These words are used internally for assisting with transaction matching. They are invalid if used in actual scripts.<br />
{| class="wikitable" <br />
|-<br />
!Word<br />
!Opcode<br />
!Hex<br />
!Description<br />
|-<br />
|OP_PUBKEYHASH<br />
|253<br />
|0xfd<br />
|Represents a public key hashed with OP_HASH160.<br />
|-<br />
|OP_PUBKEY<br />
|254<br />
|0xfe<br />
|Represents a public key compatible with OP_CHECKSIG.<br />
|-<br />
|OP_INVALIDOPCODE<br />
|255<br />
|0xff<br />
|Matches any opcode that is not yet assigned.<br />
|}<br />
<br />
=== Reserved words ===<br />
Any opcode not assigned is also reserved. Using an unassigned opcode makes the transaction invalid.<br />
<br />
{| class="wikitable" <br />
|-<br />
!Word<br />
!Opcode<br />
!Hex<br />
!When used...<br />
|-<br />
|OP_RESERVED<br />
|80<br />
|0x50<br />
|Transaction is invalid unless occuring in an unexecuted OP_IF branch<br />
|-<br />
|OP_VER<br />
|98<br />
|0x62<br />
|Transaction is invalid unless occuring in an unexecuted OP_IF branch<br />
|-<br />
|OP_VERIF<br />
|101<br />
|0x65<br />
|Transaction is invalid even when occuring in an unexecuted OP_IF branch<br />
|-<br />
|OP_VERNOTIF<br />
|102<br />
|0x66<br />
|Transaction is invalid even when occuring in an unexecuted OP_IF branch<br />
|-<br />
|OP_RESERVED1<br />
|137<br />
|0x89<br />
|Transaction is invalid unless occuring in an unexecuted OP_IF branch<br />
|-<br />
|OP_RESERVED2<br />
|138<br />
|0x8a<br />
|Transaction is invalid unless occuring in an unexecuted OP_IF branch<br />
|-<br />
|OP_NOP1-OP_NOP10<br />
|176-185<br />
|0xb0-0xb9<br />
|The word is ignored.<br />
|}<br />
<br />
== Scripts ==<br />
This is a list of interesting scripts. Keep in mind that all constants actually use the data-pushing commands above. Note that there is a small number of standard script forms that are relayed from node to node; non-standard scripts are accepted if they are in a block, but nodes will not relay them.<br />
<br />
=== Standard Transaction to Bitcoin address ===<br />
<br />
scriptPubKey: OP_DUP OP_HASH160 <pubKeyHash> OP_EQUALVERIFY OP_CHECKSIG<br />
scriptSig: <sig> <pubKey><br />
<br />
To demonstrate how scripts look on the wire, here is a raw scriptPubKey:<br />
<pre> 76 A9 14<br />
OP_DUP OP_HASH160 Bytes to push<br />
<br />
89 AB CD EF AB BA AB BA AB BA AB BA AB BA AB BA AB BA AB BA 88 AC<br />
Data to push OP_EQUALVERIFY OP_CHECKSIG</pre><br />
<br />
Note: scriptSig is in the input of the spending transaction and scriptPubKey is in the output of the previously unspent i.e. "available" transaction.<br />
<br />
Here is how each word is processed:<br />
{| class="wikitable" <br />
|-<br />
! Stack <br />
! Script <br />
! Description <br />
|-<br />
|Empty.<br />
| <sig> <pubKey> OP_DUP OP_HASH160 <pubKeyHash> OP_EQUALVERIFY OP_CHECKSIG <br />
| scriptSig and scriptPubKey are combined.<br />
|-<br />
|<sig> <pubKey><br />
| OP_DUP OP_HASH160 <pubKeyHash> OP_EQUALVERIFY OP_CHECKSIG <br />
| Constants are added to the stack.<br />
|-<br />
|<sig> <pubKey> <pubKey><br />
| OP_HASH160 <pubKeyHash> OP_EQUALVERIFY OP_CHECKSIG <br />
| Top stack item is duplicated.<br />
|-<br />
|<sig> <pubKey> <pubHashA><br />
|<pubKeyHash> OP_EQUALVERIFY OP_CHECKSIG<br />
| Top stack item is hashed.<br />
|-<br />
|<sig> <pubKey> <pubHashA> <pubKeyHash><br />
|OP_EQUALVERIFY OP_CHECKSIG<br />
| Constant added.<br />
|-<br />
|<sig> <pubKey><br />
|OP_CHECKSIG<br />
| Equality is checked between the top two stack items.<br />
|-<br />
|true<br />
|Empty.<br />
|Signature is checked for top two stack items.<br />
|}<br />
<br />
=== Standard Generation Transaction ===<br />
<br />
OP_CHECKSIG is used directly without first hashing the public key. By default the reference implementation uses this form for coinbase payment, and scriptPubKeys of this transaction form are recognized as payments to user. The disadvantage of this transaction form is that the whole public key needs to be known in advance, implying longer payment addresses, and that it provides less protection in the event of a break in the ECDSA signature algorithm.<br />
<br />
scriptPubKey: <pubKey> OP_CHECKSIG<br />
scriptSig: <sig><br />
<br />
Checking process:<br />
{| class="wikitable" <br />
|-<br />
! Stack <br />
! Script <br />
! Description <br />
|-<br />
|Empty.<br />
|<sig> <pubKey> OP_CHECKSIG<br />
|scriptSig and scriptPubKey are combined.<br />
|-<br />
|<sig> <pubKey><br />
| OP_CHECKSIG<br />
|Constants are added to the stack.<br />
|-<br />
|true<br />
|Empty.<br />
|Signature is checked for top two stack items.<br />
|}<br />
<br />
=== Provably Unspendable/Prunable Outputs ===<br />
<br />
The standard way to mark a transaction as provably unspendable is with a scriptPubKey of the following form:<br />
<br />
scriptPubKey: OP_RETURN {zero or more ops}<br />
<br />
OP_RETURN immediately marks the script as invalid, guaranteeing that no scriptSig exists that could possibly spend that output. Thus the output can be immediately pruned from the UTXO set even if it has not been spent. eb31ca1a4cbd97c2770983164d7560d2d03276ae1aee26f12d7c2c6424252f29 is an example, and acts to donate 0.125BTC to the miner who mined the transaction. Another use is to add data to a transaction, as seen in 1a2e22a717d626fc5db363582007c46924ae6b28319f07cb1b907776bd8293fc. [[P2Pool]] uses OP_RETURN so that their share chain hash txout in the coinbase of blocks it creates does not clutter the UTXO space.<br />
<br />
Note that this mechanism is not yet a standard transaction type, and thus will not be relayed by nodes on mainnet.<br />
<br />
=== Anyone-Can-Spend Outputs ===<br />
<br />
Conversely a transaction can be made spendable by anyone at all:<br />
<br />
scriptPubKey: (empty)<br />
scriptSig: OP_TRUE<br />
<br />
With some software changes such transactions can be used as a way to donate funds to miners in addition to transaction fees: any miner who mines such a transaction can also include an additional one after it sending the funds to an address they control. This mechanism may be used in the future for [[fidelity bonds]] to sacrifice funds in a provable way.<br />
<br />
Anyone-Can-Spend outputs are currently considered non-standard, and are not relayed on the P2P network.<br />
<br />
=== Transaction puzzle ===<br />
<br />
Transaction a4bfa8ab6435ae5f25dae9d89e4eb67dfa94283ca751f393c1ddc5a837bbc31b is an interesting puzzle.<br />
<br />
scriptPubKey: OP_HASH256 6fe28c0ab6f1b372c1a6a246ae63f74f931e8365e15a089c68d6190000000000 OP_EQUAL<br />
scriptSig: <data><br />
<br />
To spend the transaction you need to come up with some data such that hashing the data twice results in the given hash.<br />
<br />
{| class="wikitable" <br />
|-<br />
! Stack <br />
! Script <br />
! Description <br />
|-<br />
|Empty.<br />
|<data> OP_HASH256 <given_hash> OP_EQUAL<br />
|<br />
|-<br />
|<data><br />
|OP_HASH256 <given_hash> OP_EQUAL<br />
|scriptSig added to the stack.<br />
|-<br />
|<data_hash><br />
|<given_hash> OP_EQUAL<br />
|The data is hashed.<br />
|-<br />
|<data_hash> <given_hash><br />
|OP_EQUAL<br />
|The given hash is pushed to the stack.<br />
|-<br />
|true<br />
|Empty.<br />
|The hashes are compared, leaving true on the stack.<br />
|}<br />
<br />
This transaction was successfully spent by 09f691b2263260e71f363d1db51ff3100d285956a40cc0e4f8c8c2c4a80559b1. The required data happened to be the [[Genesis block]], and the given hash was the genesis block hash. Note that while transactions like this are fun, they are not secure, because they do not contain any signatures and thus any transaction attempting to spend them can be replaced with a different transaction sending the funds somewhere else.<br />
<br />
==See Also==<br />
<br />
* [[Transactions]]<br />
* [[Contracts]]<br />
<br />
<br />
[[Category:Technical]]<br />
[[Category:Vocabulary]]</div>Petertoddhttps://en.bitcoin.it/w/index.php?title=Script&diff=39689Script2013-07-20T06:35:34Z<p>Petertodd: /* Transaction with a message */ Transaction with a message gives people the wrong impression</p>
<hr />
<div>Bitcoin uses a scripting system for [[transactions]]. [[Wikipedia:FORTH|Forth]]-like, Script is simple, stack-based, and processed from left to right. It is purposefully not Turing-complete, with no loops.<br />
<br />
A script is essentially a list of instructions recorded with each transaction that describe how the next person wanting to spend the Bitcoins being transferred can gain access to them. The script for a typical Bitcoin transfer to destination Bitcoin address D simply encumbers future spending of the bitcoins with two things: the spender must provide<br />
# a public key that, when hashed, yields destination address D embedded in the script, and<br />
# a signature to show evidence of the private key corresponding to the public key just provided.<br />
<br />
Scripting provides the flexibility to change the parameters of what's needed to spend transferred Bitcoins. For example, the scripting system could be used to require two private keys, or a combination of several, or even no keys at all.<br />
<br />
A transaction is valid if nothing in the combined script triggers failure and the top stack item is true (non-zero). The party who originally ''sent'' the Bitcoins now being spent, dictates the script operations that will occur ''last'' in order to release them for use in another transaction. The party wanting to spend them must provide the input(s) to the previously recorded script that results in those operations occurring last leaving behind true (non-zero).<br />
<br />
Scripts are big-endian.<br />
<br />
The stacks hold byte vectors. Byte vectors are interpreted as little-endian variable-length integers with the most significant bit determining the sign of the integer. Thus 0x81 represents -1. 0x80 is another representation of zero (so called negative 0). Byte vectors are interpreted as Booleans where False is represented by any representation of zero, and True is represented by any representation of non-zero.<br />
<br />
== Words ==<br />
This is a list of all Script words (commands/functions). Some of the more complicated opcodes are disabled out of concern that the client might have a bug in their implementation; if a transaction using such an opcode were to be included in the chain any fix would risk forking the chain. <br />
<br />
True=1 and False=0.<br />
<br />
=== Constants ===<br />
When talking about scripts, these value-pushing words are usually omitted.<br />
<br />
{| class="wikitable"<br />
|-<br />
!Word<br />
!Opcode<br />
!Hex<br />
!Input<br />
!Output<br />
!Description<br />
|-<br />
|OP_0, OP_FALSE<br />
|0<br />
|0x00<br />
|Nothing.<br />
|(empty value)<br />
|An empty array of bytes is pushed onto the stack. (This is not a no-op: an item is added to the stack.)<br />
|-<br />
|N/A<br />
|1-75<br />
|0x01-0x4b<br />
|(special)<br />
|data<br />
|The next ''opcode'' bytes is data to be pushed onto the stack<br />
|-<br />
|OP_PUSHDATA1<br />
|76<br />
|0x4c<br />
|(special)<br />
|data<br />
|The next byte contains the number of bytes to be pushed onto the stack.<br />
|-<br />
|OP_PUSHDATA2<br />
|77<br />
|0x4d<br />
|(special)<br />
|data<br />
|The next two bytes contain the number of bytes to be pushed onto the stack.<br />
|-<br />
|OP_PUSHDATA4<br />
|78<br />
|0x4e<br />
|(special)<br />
|data<br />
|The next four bytes contain the number of bytes to be pushed onto the stack.<br />
|-<br />
|OP_1NEGATE<br />
|79<br />
|0x4f<br />
|Nothing.<br />
| -1<br />
|The number -1 is pushed onto the stack.<br />
|-<br />
|OP_1, OP_TRUE<br />
|81<br />
|0x51<br />
|Nothing.<br />
|1<br />
|The number 1 is pushed onto the stack.<br />
|-<br />
|OP_2-OP_16<br />
|82-96<br />
|0x52-0x60<br />
|Nothing.<br />
|2-16<br />
|The number in the word name (2-16) is pushed onto the stack.<br />
|}<br />
<br />
=== Flow control ===<br />
<br />
{| class="wikitable"<br />
|-<br />
!Word<br />
!Opcode<br />
!Hex<br />
!Input<br />
!Output<br />
!Description<br />
|-<br />
|OP_NOP<br />
|97<br />
|0x61<br />
|Nothing<br />
|Nothing<br />
|Does nothing.<br />
|-<br />
|OP_IF<br />
|99<br />
|0x63<br />
| colspan="2"|<expression> if [statements] [else [statements]]* endif<br />
|If the top stack value is not 0, the statements are executed. The top stack value is removed.<br />
|-<br />
|OP_NOTIF<br />
|100<br />
|0x64<br />
| colspan="2"|<expression> if [statements] [else [statements]]* endif<br />
|If the top stack value is 0, the statements are executed. The top stack value is removed.<br />
|-<br />
|OP_ELSE<br />
|103<br />
|0x67<br />
| colspan="2"|<expression> if [statements] [else [statements]]* endif<br />
|If the preceding OP_IF or OP_NOTIF or OP_ELSE was not executed then these statements are and if the preceding OP_IF or OP_NOTIF or OP_ELSE was executed then these statements are not. <br />
|-<br />
|OP_ENDIF<br />
|104<br />
|0x68<br />
| colspan="2"|<expression> if [statements] [else [statements]]* endif<br />
|Ends an if/else block.<br />
|-<br />
|OP_VERIFY<br />
|105<br />
|0x69<br />
|True / false<br />
|Nothing / False<br />
|'''Marks transaction as invalid''' if top stack value is not true. True is removed, but false is not.<br />
|-<br />
|OP_RETURN<br />
|106<br />
|0x6a<br />
|Nothing<br />
|Nothing<br />
|'''Marks transaction as invalid'''. <br />
|}<br />
<br />
=== Stack ===<br />
<br />
{| class="wikitable" <br />
|-<br />
!Word<br />
!Opcode<br />
!Hex<br />
!Input<br />
!Output<br />
!Description<br />
|-<br />
|OP_TOALTSTACK<br />
|107<br />
|0x6b<br />
|x1<br />
|(alt)x1<br />
|Puts the input onto the top of the alt stack. Removes it from the main stack.<br />
|-<br />
|OP_FROMALTSTACK<br />
|108<br />
|0x6c<br />
|(alt)x1<br />
|x1<br />
|Puts the input onto the top of the main stack. Removes it from the alt stack.<br />
|-<br />
|OP_IFDUP<br />
|115<br />
|0x73<br />
|x<br />
|x / x x<br />
|If the top stack value is not 0, duplicate it.<br />
|-<br />
|OP_DEPTH<br />
|116<br />
|0x74<br />
|Nothing<br />
|<Stack size><br />
|Puts the number of stack items onto the stack.<br />
|-<br />
|OP_DROP<br />
|117<br />
|0x75<br />
|x<br />
|Nothing<br />
|Removes the top stack item.<br />
|-<br />
|OP_DUP<br />
|118<br />
|0x76<br />
|x<br />
|x x<br />
|Duplicates the top stack item.<br />
|-<br />
|OP_NIP<br />
|119<br />
|0x77<br />
|x1 x2<br />
|x2<br />
|Removes the second-to-top stack item.<br />
|-<br />
|OP_OVER<br />
|120<br />
|0x78<br />
|x1 x2<br />
|x1 x2 x1<br />
|Copies the second-to-top stack item to the top.<br />
|-<br />
|OP_PICK<br />
|121<br />
|0x79<br />
|xn ... x2 x1 x0 <n><br />
|xn ... x2 x1 x0 xn<br />
|The item ''n'' back in the stack is copied to the top.<br />
|-<br />
|OP_ROLL<br />
|122<br />
|0x7a<br />
|xn ... x2 x1 x0 <n><br />
|... x2 x1 x0 xn<br />
|The item ''n'' back in the stack is moved to the top.<br />
|-<br />
|OP_ROT<br />
|123<br />
|0x7b<br />
|x1 x2 x3<br />
|x2 x3 x1<br />
|The top three items on the stack are rotated to the left.<br />
|-<br />
|OP_SWAP<br />
|124<br />
|0x7c<br />
|x1 x2<br />
|x2 x1<br />
|The top two items on the stack are swapped.<br />
|-<br />
|OP_TUCK<br />
|125<br />
|0x7d<br />
|x1 x2<br />
|x2 x1 x2<br />
|The item at the top of the stack is copied and inserted before the second-to-top item.<br />
|-<br />
|OP_2DROP<br />
|109<br />
|0x6d<br />
|x1 x2<br />
|Nothing<br />
|Removes the top two stack items.<br />
|-<br />
|OP_2DUP<br />
|110<br />
|0x6e<br />
|x1 x2<br />
|x1 x2 x1 x2<br />
|Duplicates the top two stack items.<br />
|-<br />
|OP_3DUP<br />
|111<br />
|0x6f<br />
|x1 x2 x3<br />
|x1 x2 x3 x1 x2 x3<br />
|Duplicates the top three stack items.<br />
|-<br />
|OP_2OVER<br />
|112<br />
|0x70<br />
|x1 x2 x3 x4<br />
|x1 x2 x3 x4 x1 x2<br />
|Copies the pair of items two spaces back in the stack to the front.<br />
|-<br />
|OP_2ROT<br />
|113<br />
|0x71<br />
|x1 x2 x3 x4 x5 x6<br />
|x3 x4 x5 x6 x1 x2<br />
|The fifth and sixth items back are moved to the top of the stack.<br />
|-<br />
|OP_2SWAP<br />
|114<br />
|0x72<br />
|x1 x2 x3 x4<br />
|x3 x4 x1 x2<br />
|Swaps the top two pairs of items.<br />
|}<br />
<br />
=== Splice ===<br />
<br />
If any opcode marked as Currently disabled is present in a script, it should abort and fail.<br />
<br />
{| class="wikitable" <br />
|-<br />
!Word<br />
!Opcode<br />
!Hex<br />
!Input<br />
!Output<br />
!Description<br />
|-<br />
|OP_CAT<br />
|126<br />
|0x7e<br />
|x1 x2<br />
|out<br />
|style="background:#D97171;"|Concatenates two strings. ''Currently disabled.''<br />
|-<br />
|OP_SUBSTR<br />
|127<br />
|0x7f<br />
|in begin size<br />
|out<br />
|style="background:#D97171;"|Returns a section of a string. ''Currently disabled.''<br />
|-<br />
|OP_LEFT<br />
|128<br />
|0x80<br />
|in size<br />
|out<br />
|style="background:#D97171;"|Keeps only characters left of the specified point in a string. ''Currently disabled.''<br />
|-<br />
|OP_RIGHT<br />
|129<br />
|0x81<br />
|in size<br />
|out<br />
|style="background:#D97171;"|Keeps only characters right of the specified point in a string. ''Currently disabled.''<br />
|-<br />
|OP_SIZE<br />
|130<br />
|0x82<br />
|in<br />
|in size<br />
|Returns the length of the input string.<br />
|}<br />
<br />
=== Bitwise logic ===<br />
<br />
If any opcode marked as Currently disabled is present in a script, it should abort and fail.<br />
<br />
{| class="wikitable" <br />
|-<br />
!Word<br />
!Opcode<br />
!Hex<br />
!Input<br />
!Output<br />
!Description<br />
|-<br />
|OP_INVERT<br />
|131<br />
|0x83<br />
|in<br />
|out<br />
|style="background:#D97171;"|Flips all of the bits in the input. ''Currently disabled.''<br />
|-<br />
|OP_AND<br />
|132<br />
|0x84<br />
|x1 x2<br />
|out<br />
|style="background:#D97171;"|Boolean ''and'' between each bit in the inputs. ''Currently disabled.''<br />
|-<br />
|OP_OR<br />
|133<br />
|0x85<br />
|x1 x2<br />
|out<br />
|style="background:#D97171;"|Boolean ''or'' between each bit in the inputs. ''Currently disabled.''<br />
|-<br />
|OP_XOR<br />
|134<br />
|0x86<br />
|x1 x2<br />
|out<br />
|style="background:#D97171;"|Boolean ''exclusive or'' between each bit in the inputs. ''Currently disabled.''<br />
|-<br />
|OP_EQUAL<br />
|135<br />
|0x87<br />
|x1 x2<br />
|True / false<br />
|Returns 1 if the inputs are exactly equal, 0 otherwise.<br />
|-<br />
|OP_EQUALVERIFY<br />
|136<br />
|0x88<br />
|x1 x2<br />
|True / false<br />
|Same as OP_EQUAL, but runs OP_VERIFY afterward.<br />
|}<br />
<br />
=== Arithmetic ===<br />
<br />
Note: Arithmetic inputs are limited to signed 32-bit integers, but may overflow their output.<br />
<br />
If any input value for any of these commands is longer than 4 bytes, the script should abort and fail. <br />
If any opcode marked as ''Currently disabled'' is present in a script - it should also abort and fail.<br />
<br />
{| class="wikitable" <br />
|-<br />
!Word<br />
!Opcode<br />
!Hex<br />
!Input<br />
!Output<br />
!Description<br />
|-<br />
|OP_1ADD<br />
|139<br />
|0x8b<br />
|in<br />
|out<br />
|1 is added to the input.<br />
|-<br />
|OP_1SUB<br />
|140<br />
|0x8c<br />
|in<br />
|out<br />
|1 is subtracted from the input.<br />
|-<br />
|OP_2MUL<br />
|141<br />
|0x8d<br />
|in<br />
|out<br />
|style="background:#D97171;"|The input is multiplied by 2. ''Currently disabled.''<br />
|-<br />
|OP_2DIV<br />
|142<br />
|0x8e<br />
|in<br />
|out<br />
|style="background:#D97171;"|The input is divided by 2. ''Currently disabled.''<br />
|-<br />
|OP_NEGATE<br />
|143<br />
|0x8f<br />
|in<br />
|out<br />
|The sign of the input is flipped.<br />
|-<br />
|OP_ABS<br />
|144<br />
|0x90<br />
|in<br />
|out<br />
|The input is made positive.<br />
|-<br />
|OP_NOT<br />
|145<br />
|0x91<br />
|in<br />
|out<br />
|If the input is 0 or 1, it is flipped. Otherwise the output will be 0.<br />
|-<br />
|OP_0NOTEQUAL<br />
|146<br />
|0x92<br />
|in<br />
|out<br />
|Returns 0 if the input is 0. 1 otherwise.<br />
|-<br />
|OP_ADD<br />
|147<br />
|0x93<br />
|a b<br />
|out<br />
|a is added to b.<br />
|-<br />
|OP_SUB<br />
|148<br />
|0x94<br />
|a b<br />
|out<br />
|b is subtracted from a.<br />
|-<br />
|OP_MUL<br />
|149<br />
|0x95<br />
|a b<br />
|out<br />
|style="background:#D97171;"|a is multiplied by b. ''Currently disabled.''<br />
|-<br />
|OP_DIV<br />
|150<br />
|0x96<br />
|a b<br />
|out<br />
|style="background:#D97171;"|a is divided by b. ''Currently disabled.''<br />
|-<br />
|OP_MOD<br />
|151<br />
|0x97<br />
|a b<br />
|out<br />
|style="background:#D97171;"|Returns the remainder after dividing a by b. ''Currently disabled.''<br />
|-<br />
|OP_LSHIFT<br />
|152<br />
|0x98<br />
|a b<br />
|out<br />
|style="background:#D97171;"|Shifts a left b bits, preserving sign. ''Currently disabled.''<br />
|-<br />
|OP_RSHIFT<br />
|153<br />
|0x99<br />
|a b<br />
|out<br />
|style="background:#D97171;"|Shifts a right b bits, preserving sign. ''Currently disabled.''<br />
|-<br />
|OP_BOOLAND<br />
|154<br />
|0x9a<br />
|a b<br />
|out<br />
|If both a and b are not 0, the output is 1. Otherwise 0.<br />
|-<br />
|OP_BOOLOR<br />
|155<br />
|0x9b<br />
|a b<br />
|out<br />
|If a or b is not 0, the output is 1. Otherwise 0.<br />
|-<br />
|OP_NUMEQUAL<br />
|156<br />
|0x9c<br />
|a b<br />
|out<br />
|Returns 1 if the numbers are equal, 0 otherwise.<br />
|-<br />
|OP_NUMEQUALVERIFY<br />
|157<br />
|0x9d<br />
|a b<br />
|out<br />
|Same as OP_NUMEQUAL, but runs OP_VERIFY afterward.<br />
|-<br />
|OP_NUMNOTEQUAL<br />
|158<br />
|0x9e<br />
|a b<br />
|out<br />
|Returns 1 if the numbers are not equal, 0 otherwise.<br />
|-<br />
|OP_LESSTHAN<br />
|159<br />
|0x9f<br />
|a b<br />
|out<br />
|Returns 1 if a is less than b, 0 otherwise.<br />
|-<br />
|OP_GREATERTHAN<br />
|160<br />
|0xa0<br />
|a b<br />
|out<br />
|Returns 1 if a is greater than b, 0 otherwise.<br />
|-<br />
|OP_LESSTHANOREQUAL<br />
|161<br />
|0xa1<br />
|a b<br />
|out<br />
|Returns 1 if a is less than or equal to b, 0 otherwise.<br />
|-<br />
|OP_GREATERTHANOREQUAL<br />
|162<br />
|0xa2<br />
|a b<br />
|out<br />
|Returns 1 if a is greater than or equal to b, 0 otherwise.<br />
|-<br />
|OP_MIN<br />
|163<br />
|0xa3<br />
|a b<br />
|out<br />
|Returns the smaller of a and b.<br />
|-<br />
|OP_MAX<br />
|164<br />
|0xa4<br />
|a b<br />
|out<br />
|Returns the larger of a and b.<br />
|-<br />
|OP_WITHIN<br />
|165<br />
|0xa5<br />
|x min max<br />
|out<br />
|Returns 1 if x is within the specified range (left-inclusive), 0 otherwise.<br />
|}<br />
<br />
=== Crypto ===<br />
<br />
{| class="wikitable" <br />
|-<br />
!Word<br />
!Opcode<br />
!Hex<br />
!Input<br />
!Output<br />
!Description<br />
|-<br />
|OP_RIPEMD160<br />
|166<br />
|0xa6<br />
|in<br />
|hash<br />
|The input is hashed using RIPEMD-160.<br />
|-<br />
|OP_SHA1<br />
|167<br />
|0xa7<br />
|in<br />
|hash<br />
|The input is hashed using SHA-1.<br />
|-<br />
|OP_SHA256<br />
|168<br />
|0xa8<br />
|in<br />
|hash<br />
|The input is hashed using SHA-256.<br />
|-<br />
|OP_HASH160<br />
|169<br />
|0xa9<br />
|in<br />
|hash<br />
|The input is hashed twice: first with SHA-256 and then with RIPEMD-160.<br />
|-<br />
|OP_HASH256<br />
|170<br />
|0xaa<br />
|in<br />
|hash<br />
|The input is hashed two times with SHA-256.<br />
|-<br />
|OP_CODESEPARATOR<br />
|171<br />
|0xab<br />
|Nothing<br />
|Nothing<br />
|All of the signature checking words will only match signatures to the data after the most recently-executed OP_CODESEPARATOR.<br />
|-<br />
|[[OP_CHECKSIG]]<br />
|172<br />
|0xac<br />
|sig pubkey<br />
|True / false<br />
|The entire transaction's outputs, inputs, and script (from the most recently-executed OP_CODESEPARATOR to the end) are hashed. The signature used by OP_CHECKSIG must be a valid signature for this hash and public key. If it is, 1 is returned, 0 otherwise.<br />
|-<br />
|OP_CHECKSIGVERIFY<br />
|173<br />
|0xad<br />
|sig pubkey<br />
|True / false<br />
|Same as OP_CHECKSIG, but OP_VERIFY is executed afterward.<br />
|-<br />
|OP_CHECKMULTISIG<br />
|174<br />
|0xae<br />
|x sig1 sig2 ... <number of signatures> pub1 pub2 <number of public keys><br />
|True / False<br />
|For each signature and public key pair, OP_CHECKSIG is executed. If more public keys than signatures are listed, some key/sig pairs can fail. All signatures need to match a public key. If all signatures are valid, 1 is returned, 0 otherwise. Due to a bug, one extra unused value is removed from the stack.<br />
|-<br />
|OP_CHECKMULTISIGVERIFY<br />
|175<br />
|0xaf<br />
|x sig1 sig2 ... <number of signatures> pub1 pub2 ... <number of public keys><br />
|True / False<br />
|Same as OP_CHECKMULTISIG, but OP_VERIFY is executed afterward.<br />
|}<br />
<br />
===Pseudo-words===<br />
These words are used internally for assisting with transaction matching. They are invalid if used in actual scripts.<br />
{| class="wikitable" <br />
|-<br />
!Word<br />
!Opcode<br />
!Hex<br />
!Description<br />
|-<br />
|OP_PUBKEYHASH<br />
|253<br />
|0xfd<br />
|Represents a public key hashed with OP_HASH160.<br />
|-<br />
|OP_PUBKEY<br />
|254<br />
|0xfe<br />
|Represents a public key compatible with OP_CHECKSIG.<br />
|-<br />
|OP_INVALIDOPCODE<br />
|255<br />
|0xff<br />
|Matches any opcode that is not yet assigned.<br />
|}<br />
<br />
=== Reserved words ===<br />
Any opcode not assigned is also reserved. Using an unassigned opcode makes the transaction invalid.<br />
<br />
{| class="wikitable" <br />
|-<br />
!Word<br />
!Opcode<br />
!Hex<br />
!When used...<br />
|-<br />
|OP_RESERVED<br />
|80<br />
|0x50<br />
|Transaction is invalid unless occuring in an unexecuted OP_IF branch<br />
|-<br />
|OP_VER<br />
|98<br />
|0x62<br />
|Transaction is invalid unless occuring in an unexecuted OP_IF branch<br />
|-<br />
|OP_VERIF<br />
|101<br />
|0x65<br />
|Transaction is invalid even when occuring in an unexecuted OP_IF branch<br />
|-<br />
|OP_VERNOTIF<br />
|102<br />
|0x66<br />
|Transaction is invalid even when occuring in an unexecuted OP_IF branch<br />
|-<br />
|OP_RESERVED1<br />
|137<br />
|0x89<br />
|Transaction is invalid unless occuring in an unexecuted OP_IF branch<br />
|-<br />
|OP_RESERVED2<br />
|138<br />
|0x8a<br />
|Transaction is invalid unless occuring in an unexecuted OP_IF branch<br />
|-<br />
|OP_NOP1-OP_NOP10<br />
|176-185<br />
|0xb0-0xb9<br />
|The word is ignored.<br />
|}<br />
<br />
== Scripts ==<br />
This is a list of interesting scripts. Keep in mind that all constants actually use the data-pushing commands above. Note that there is a small number of standard script forms that are relayed from node to node; non-standard scripts are accepted if they are in a block, but nodes will not relay them.<br />
<br />
=== Standard Transaction to Bitcoin address ===<br />
<br />
scriptPubKey: OP_DUP OP_HASH160 <pubKeyHash> OP_EQUALVERIFY OP_CHECKSIG<br />
scriptSig: <sig> <pubKey><br />
<br />
To demonstrate how scripts look on the wire, here is a raw scriptPubKey:<br />
<pre> 76 A9 14<br />
OP_DUP OP_HASH160 Bytes to push<br />
<br />
89 AB CD EF AB BA AB BA AB BA AB BA AB BA AB BA AB BA AB BA 88 AC<br />
Data to push OP_EQUALVERIFY OP_CHECKSIG</pre><br />
<br />
Note: scriptSig is in the input of the spending transaction and scriptPubKey is in the output of the previously unspent i.e. "available" transaction.<br />
<br />
Here is how each word is processed:<br />
{| class="wikitable" <br />
|-<br />
! Stack <br />
! Script <br />
! Description <br />
|-<br />
|Empty.<br />
| <sig> <pubKey> OP_DUP OP_HASH160 <pubKeyHash> OP_EQUALVERIFY OP_CHECKSIG <br />
| scriptSig and scriptPubKey are combined.<br />
|-<br />
|<sig> <pubKey><br />
| OP_DUP OP_HASH160 <pubKeyHash> OP_EQUALVERIFY OP_CHECKSIG <br />
| Constants are added to the stack.<br />
|-<br />
|<sig> <pubKey> <pubKey><br />
| OP_HASH160 <pubKeyHash> OP_EQUALVERIFY OP_CHECKSIG <br />
| Top stack item is duplicated.<br />
|-<br />
|<sig> <pubKey> <pubHashA><br />
|<pubKeyHash> OP_EQUALVERIFY OP_CHECKSIG<br />
| Top stack item is hashed.<br />
|-<br />
|<sig> <pubKey> <pubHashA> <pubKeyHash><br />
|OP_EQUALVERIFY OP_CHECKSIG<br />
| Constant added.<br />
|-<br />
|<sig> <pubKey><br />
|OP_CHECKSIG<br />
| Equality is checked between the top two stack items.<br />
|-<br />
|true<br />
|Empty.<br />
|Signature is checked for top two stack items.<br />
|}<br />
<br />
=== Standard Generation Transaction ===<br />
<br />
OP_CHECKSIG is used directly without first hashing the public key. By default the reference implementation uses this form for coinbase payment, and scriptPubKeys of this transaction form are recognized as payments to user. The disadvantage of this transaction form is that the whole public key needs to be known in advance, implying longer payment addresses, and that it provides less protection in the event of a break in the ECDSA signature algorithm.<br />
<br />
scriptPubKey: <pubKey> OP_CHECKSIG<br />
scriptSig: <sig><br />
<br />
Checking process:<br />
{| class="wikitable" <br />
|-<br />
! Stack <br />
! Script <br />
! Description <br />
|-<br />
|Empty.<br />
|<sig> <pubKey> OP_CHECKSIG<br />
|scriptSig and scriptPubKey are combined.<br />
|-<br />
|<sig> <pubKey><br />
| OP_CHECKSIG<br />
|Constants are added to the stack.<br />
|-<br />
|true<br />
|Empty.<br />
|Signature is checked for top two stack items.<br />
|}<br />
<br />
=== Provably Unspendable/Prunable Outputs ===<br />
<br />
The standard way to mark a transaction as provably unspendable is with a scriptPubKey of the following form:<br />
<br />
scriptPubKey: OP_RETURN {zero or more ops}<br />
<br />
OP_RETURN immediately marks the script as invalid, guaranteeing that no scriptSig exists that could possibly spend that output. Thus the output can be immediately pruned from the UTXO set even if it has not been spent. eb31ca1a4cbd97c2770983164d7560d2d03276ae1aee26f12d7c2c6424252f29 is an example, and acts to donate 0.125BTC to the miner who mined the transaction. Another use is to add data to a transaction, as seen in 1a2e22a717d626fc5db363582007c46924ae6b28319f07cb1b907776bd8293fc<br />
<br />
Note that this mechanism is not yet a standard transaction type, and thus will not be relayed by nodes on mainnet.<br />
<br />
=== Anyone-Can-Spend Outputs ===<br />
<br />
Conversely a transaction can be made spendable by anyone at all:<br />
<br />
scriptPubKey: (empty)<br />
scriptSig: OP_TRUE<br />
<br />
With some software changes such transactions can be used as a way to donate funds to miners in addition to transaction fees: any miner who mines such a transaction can also include an additional one after it sending the funds to an address they control. This mechanism may be used in the future for [[fidelity bonds]] to sacrifice funds in a provable way.<br />
<br />
Anyone-Can-Spend outputs are currently considered non-standard, and are not relayed on the P2P network.<br />
<br />
=== Transaction puzzle ===<br />
<br />
Transaction a4bfa8ab6435ae5f25dae9d89e4eb67dfa94283ca751f393c1ddc5a837bbc31b is an interesting puzzle.<br />
<br />
scriptPubKey: OP_HASH256 6fe28c0ab6f1b372c1a6a246ae63f74f931e8365e15a089c68d6190000000000 OP_EQUAL<br />
scriptSig: <data><br />
<br />
To spend the transaction you need to come up with some data such that hashing the data twice results in the given hash.<br />
<br />
{| class="wikitable" <br />
|-<br />
! Stack <br />
! Script <br />
! Description <br />
|-<br />
|Empty.<br />
|<data> OP_HASH256 <given_hash> OP_EQUAL<br />
|<br />
|-<br />
|<data><br />
|OP_HASH256 <given_hash> OP_EQUAL<br />
|scriptSig added to the stack.<br />
|-<br />
|<data_hash><br />
|<given_hash> OP_EQUAL<br />
|The data is hashed.<br />
|-<br />
|<data_hash> <given_hash><br />
|OP_EQUAL<br />
|The given hash is pushed to the stack.<br />
|-<br />
|true<br />
|Empty.<br />
|The hashes are compared, leaving true on the stack.<br />
|}<br />
<br />
This transaction was successfully spent by 09f691b2263260e71f363d1db51ff3100d285956a40cc0e4f8c8c2c4a80559b1. The required data happened to be the [[Genesis block]], and the given hash was the genesis block hash. Note that while transactions like this are fun, they are not secure, because they do not contain any signatures and thus any transaction attempting to spend them can be replaced with a different transaction sending the funds somewhere else.<br />
<br />
==See Also==<br />
<br />
* [[Transactions]]<br />
* [[Contracts]]<br />
<br />
<br />
[[Category:Technical]]<br />
[[Category:Vocabulary]]</div>Petertoddhttps://en.bitcoin.it/w/index.php?title=Identity_protocol_v1&diff=39015Identity protocol v12013-06-29T23:08:14Z<p>Petertodd: /* Creating a SIN */ testnet is just "testnet" - reboot version shouldn't be specified</p>
<hr />
<div><br />
<br />
==Design goals==<br />
<br />
Fully decentralized, anonymous, secure identity.<br />
<br />
A SIN ("System Identification Number") is the unique record identifier by which this identity will be known.<br />
<br />
Attributes:<br />
* Has some creation cost, deterring spam.<br />
* Sacrifice may be digitally proven, bootstrapping root of trust from blockchain data<br />
* Start as anonymous; opt out of anonymity by attaching identifying key-value pairs (real.name = "John Smith", gov.us.ssn = "123-45-6789").<br />
* Third parties may offer digital attestions: Identity Verification, Inc. digitally signs a SIN as passing their Not A Criminal/Level-1 check.<br />
* All key-value pair updates digitally signed by SIN owner (key holder)<br />
<br />
==Creating sacrifice transactions==<br />
<br />
Creation cost is attached to decentralized identity by means of sacrificing a small amount of value.<br />
<br />
An implementation of [https://en.bitcoin.it/wiki/Fidelity_bonds#Announce.2FCommit_Sacrifices Announce/Commit Sacrifices]. That author's feedback on this protocol was very helpful.<br />
<br />
# MPK = master public key<br />
# BH = current block height<br />
# Create and sign transaction T2. Broadcast if desired.<br />
## must include Hash160(MPK) OP_TRUE anyone-can-spend output with value >= 0.001BTC<br />
## nlocktime = BH + 144 blocks<br />
## no more than 1000 bytes in size<br />
# Create, sign and broadcast transaction T1<br />
## must include OP_RETURN serialized(T2) output as last txout<br />
<br />
==Creating a SIN==<br />
<br />
# Prefix = 0x18 (mainnet) or 0x19 (testnet)<br />
# SIN_Version = 0x01, similar to how a [http://en.wikipedia.org/wiki/Universally_unique_identifier UUID's] form is dictated by a UUID's self-identified version<br />
# MD = Hash160(MPK)<br />
# SIN = base58_encode_check( Prefix + SIN_Version + MD )<br />
# Hyphenate SIN for easier human reading<br />
<br />
==Validating the root identity information==<br />
<br />
# B1 = block w/ T1<br />
# B2 = block w/ T2<br />
# Verify B2 height - 144 >= B1 height.<br />
# Verify announced T2 is valid<br />
# Verify mined T2 spends same inputs as announced T2 (not equal to account for [[Transaction Malleability]])<br />
# Fail and waste sacrifice if not.<br />
<br />
<br />
Thus a minimal root record is MPK and is provably<br />
* linked to the sacrifices<br />
* MPK starts a new chain of digital signature trust, for further record updates<br />
<br />
==Future work==<br />
<br />
After creation, the root identity and key-value pairs must be stored $somewhere.<br />
<br />
After that root identity is created, additional key-value pairs may be associated with the root record via updates verified by MPK, stored in an alt-blockchain or DHT somewhere. That is outside the scope of this minimal document, at this time.<br />
<br />
Key attributes of this system, like price and transaction size, are hardcoded. It is presumed that version 2+ will improve upon this, once field experience is gained and lessons are learned.</div>Petertoddhttps://en.bitcoin.it/w/index.php?title=Identity_protocol_v1&diff=39004Identity protocol v12013-06-28T08:40:57Z<p>Petertodd: /* Creating a SIN */ remove "space" option for SIN to ensure double-click selection works</p>
<hr />
<div><br />
<br />
==Design goals==<br />
<br />
Decentralized identity.<br />
<br />
A SIN ("System Identification Number") is the unique record identifier by which this identity will be known.<br />
<br />
Attributes:<br />
* Has some creation cost, deterring spam.<br />
* Sacrifice may be digitally proven, bootstrapping root of trust from blockchain data<br />
* Start as anonymous; opt out of anonymity by attaching identifying key-value pairs (real.name = "John Smith", gov.us.ssn = "123-45-6789").<br />
* Third parties may offer digital attestions: Identity Verification, Inc. digitally signs a SIN as passing their Not A Criminal/Level-1 check.<br />
* All key-value pair updates digitally signed by SIN owner (key holder)<br />
<br />
==Creating sacrifice transactions==<br />
<br />
Creation cost is attached to decentralized identity by means of sacrificing a small amount of value.<br />
<br />
An implementation of [https://en.bitcoin.it/wiki/Fidelity_bonds#Announce.2FCommit_Sacrifices Announce/Commit Sacrifices]. That author's feedback on this protocol was very helpful.<br />
<br />
# MPK = master public key<br />
# BH = current block height<br />
# Create and sign transaction T2. Broadcast if desired.<br />
## must include Hash160(MPK) OP_TRUE anyone-can-spend output with value >= 0.001BTC<br />
## nlocktime = BH + 144 blocks<br />
## no more than 1000 bytes in size<br />
# Create, sign and broadcast transaction T1<br />
## must include OP_RETURN serialized(T2) output as last txout<br />
<br />
==Creating a SIN==<br />
<br />
# Prefix = 0x18<br />
# SIN_Version = 0x01, similar to how a [http://en.wikipedia.org/wiki/Universally_unique_identifier UUID's] form is dictated by a UUID's self-identified version<br />
# MD = Hash160(MPK)<br />
# SIN = base58_encode_check( Prefix + SIN_Version + MD )<br />
# Hyphenate SIN for easier human reading<br />
<br />
==Validating the root identity information==<br />
<br />
# B1 = block w/ T1<br />
# B2 = block w/ T2<br />
# Verify B2 height - 144 >= B1 height.<br />
# Verify announced T2 is valid<br />
# Verify mined T2 spends same inputs as announced T2 (not equal to account for [[Transaction Malleability]])<br />
# Fail and waste sacrifice if not.<br />
<br />
<br />
Thus a minimal root record is MPK and is provably<br />
* linked to the sacrifices<br />
* MPK starts a new chain of digital signature trust, for further record updates<br />
<br />
==Future work==<br />
<br />
After creation, the root identity and key-value pairs must be stored $somewhere.<br />
<br />
After that root identity is created, additional key-value pairs may be associated with the root record via updates verified by MPK, stored in an alt-blockchain or DHT somewhere. That is outside the scope of this minimal document, at this time.<br />
<br />
Key attributes of this system, like price and transaction size, are hardcoded. It is presumed that version 2+ will improve upon this, once field experience is gained and lessons are learned.</div>Petertoddhttps://en.bitcoin.it/w/index.php?title=Identity_protocol_v1&diff=38985Identity protocol v12013-06-28T05:21:28Z<p>Petertodd: /* Creating sacrifice transactions */ change to anyone-can-spend</p>
<hr />
<div><br />
<br />
==Design goals==<br />
<br />
Decentralized identity.<br />
* Has some creation cost<br />
* Sacrifice may be digitally proven, bootstrapping root of trust from blockchain data<br />
* Start as anonymous; opt out of anonymity by attaching identifying key-value pairs (real.name = "John Smith").<br />
<br />
<br />
==Creating sacrifice transactions==<br />
<br />
An implementation of [https://en.bitcoin.it/wiki/Fidelity_bonds#Announce.2FCommit_Sacrifices Announce/Commit Sacrifices]. That author's feedback on this protocol was very helpful.<br />
<br />
# MPK = master public key<br />
# TM = current block height<br />
# Create and sign transaction T2. Broadcast if desired.<br />
## must include Hash160(MPK) OP_TRUE output with value >= 0.001BTC<br />
## nlocktime = TM + 144 blocks<br />
## no more than 1000 bytes in size<br />
# Create, sign and broadcast transaction T1<br />
## must include OP_RETURN serialized(T2) output as last txout<br />
<br />
==Creating a SIN==<br />
<br />
A SIN ("System Identification Number") is the unique record identifier by which this identity will be known.<br />
<br />
# Prefix = 0x18<br />
# SIN_Version = 0x01<br />
# MD = Hash160(MPK)<br />
# SIN = base58_encode_check( Prefix + SIN_Version + MD )<br />
# Hyphenate or space SIN for easier human reading<br />
<br />
==Validating the root identity information==<br />
<br />
# B1 = block w/ T1, B2 = block w/ T2<br />
# Verify B2 height - 144 >= B1 height.<br />
# Verify announced T2 is valid<br />
# Verify mined T2 spends same inputs as announced T2 (not equal to account for [[Transaction Malleability]])<br />
# Fail and waste sacrifice if not.<br />
<br />
<br />
Thus a minimal root record is MPK and is provably<br />
* linked to the sacrifices<br />
* MPK starts a new chain of digital signature trust, for further record updates<br />
<br />
After that, additional key-value pairs may be associated with the root record via updates verified by PPK, stored in an alt-blockchain or DHT somewhere. That is outside the scope of this minimal document.</div>Petertoddhttps://en.bitcoin.it/w/index.php?title=Identity_protocol_v1&diff=38984Identity protocol v12013-06-28T05:18:00Z<p>Petertodd: /* Validating the root identity information */</p>
<hr />
<div><br />
<br />
==Design goals==<br />
<br />
Decentralized identity.<br />
* Has some creation cost<br />
* Sacrifice may be digitally proven, bootstrapping root of trust from blockchain data<br />
* Start as anonymous; opt out of anonymity by attaching identifying key-value pairs (real.name = "John Smith").<br />
<br />
<br />
==Creating sacrifice transactions==<br />
<br />
An implementation of [https://en.bitcoin.it/wiki/Fidelity_bonds#Announce.2FCommit_Sacrifices Announce/Commit Sacrifices]. That author's feedback on this protocol was very helpful.<br />
<br />
# MPK = master public key<br />
# TM = current block height<br />
# Create and sign transaction T2. Broadcast if desired.<br />
## must include OP_RETURN Hash160(MPK) output with value >= 0.001BTC<br />
## nlocktime = TM + 144 blocks<br />
## no more than 1000 bytes in size<br />
# Create, sign and broadcast transaction T1<br />
## must include OP_RETURN serialized(T2) output as last txout<br />
<br />
==Creating a SIN==<br />
<br />
A SIN ("System Identification Number") is the unique record identifier by which this identity will be known.<br />
<br />
# Prefix = 0x18<br />
# SIN_Version = 0x01<br />
# MD = Hash160(MPK)<br />
# SIN = base58_encode_check( Prefix + SIN_Version + MD )<br />
# Hyphenate or space SIN for easier human reading<br />
<br />
==Validating the root identity information==<br />
<br />
# B1 = block w/ T1, B2 = block w/ T2<br />
# Verify B2 height - 144 >= B1 height.<br />
# Verify announced T2 is valid<br />
# Verify mined T2 spends same inputs as announced T2 (not equal to account for [[Transaction Malleability]])<br />
# Fail and waste sacrifice if not.<br />
<br />
<br />
Thus a minimal root record is MPK and is provably<br />
* linked to the sacrifices<br />
* MPK starts a new chain of digital signature trust, for further record updates<br />
<br />
After that, additional key-value pairs may be associated with the root record via updates verified by PPK, stored in an alt-blockchain or DHT somewhere. That is outside the scope of this minimal document.</div>Petertoddhttps://en.bitcoin.it/w/index.php?title=Identity_protocol_v1&diff=38983Identity protocol v12013-06-28T05:14:08Z<p>Petertodd: /* Creating sacrifice transactions */</p>
<hr />
<div><br />
<br />
==Design goals==<br />
<br />
Decentralized identity.<br />
* Has some creation cost<br />
* Sacrifice may be digitally proven, bootstrapping root of trust from blockchain data<br />
* Start as anonymous; opt out of anonymity by attaching identifying key-value pairs (real.name = "John Smith").<br />
<br />
<br />
==Creating sacrifice transactions==<br />
<br />
An implementation of [https://en.bitcoin.it/wiki/Fidelity_bonds#Announce.2FCommit_Sacrifices Announce/Commit Sacrifices]. That author's feedback on this protocol was very helpful.<br />
<br />
# MPK = master public key<br />
# TM = current block height<br />
# Create and sign transaction T2. Broadcast if desired.<br />
## must include OP_RETURN Hash160(MPK) output with value >= 0.001BTC<br />
## nlocktime = TM + 144 blocks<br />
## no more than 1000 bytes in size<br />
# Create, sign and broadcast transaction T1<br />
## must include OP_RETURN serialized(T2) output as last txout<br />
<br />
==Creating a SIN==<br />
<br />
A SIN ("System Identification Number") is the unique record identifier by which this identity will be known.<br />
<br />
# Prefix = 0x18<br />
# SIN_Version = 0x01<br />
# MD = Hash160(MPK)<br />
# SIN = base58_encode_check( Prefix + SIN_Version + MD )<br />
# Hyphenate or space SIN for easier human reading<br />
<br />
==Validating the root identity information==<br />
<br />
# B1 = block w/ T1, B2 = block w/ T2<br />
# Verify B2 height - 144 >= B1 height.<br />
# Verify mined T2 == announced T2<br />
# Fail and waste sacrifice if not.<br />
<br />
<br />
Thus a minimal root record is MPK and is provably<br />
* linked to the sacrifices<br />
* MPK starts a new chain of digital signature trust, for further record updates<br />
<br />
After that, additional key-value pairs may be associated with the root record via updates verified by PPK, stored in an alt-blockchain or DHT somewhere. That is outside the scope of this minimal document.</div>Petertoddhttps://en.bitcoin.it/w/index.php?title=Identity_protocol_v1&diff=38982Identity protocol v12013-06-28T05:12:49Z<p>Petertodd: Specify the usual Bitcoin Hash160(d)</p>
<hr />
<div><br />
<br />
==Design goals==<br />
<br />
Decentralized identity.<br />
* Has some creation cost<br />
* Sacrifice may be digitally proven, bootstrapping root of trust from blockchain data<br />
* Start as anonymous; opt out of anonymity by attaching identifying key-value pairs (real.name = "John Smith").<br />
<br />
<br />
==Creating sacrifice transactions==<br />
<br />
An implementation of [https://en.bitcoin.it/wiki/Fidelity_bonds#Announce.2FCommit_Sacrifices Announce/Commit Sacrifices]. That author's feedback on this protocol was very helpful.<br />
<br />
# MPK = master public key<br />
# TM = current block height<br />
# Create and sign transaction T2. Broadcast if desired.<br />
## must include OP_RETURN Hash160(MPK) output<br />
## nlocktime = TM + 144 blocks<br />
## no more than 1000 bytes in size<br />
## must include >= 0.001 BTC fee<br />
# Create, sign and broadcast transaction T1<br />
## must include OP_RETURN serialized(T2) output<br />
<br />
==Creating a SIN==<br />
<br />
A SIN ("System Identification Number") is the unique record identifier by which this identity will be known.<br />
<br />
# Prefix = 0x18<br />
# SIN_Version = 0x01<br />
# MD = Hash160(MPK)<br />
# SIN = base58_encode_check( Prefix + SIN_Version + MD )<br />
# Hyphenate or space SIN for easier human reading<br />
<br />
==Validating the root identity information==<br />
<br />
# B1 = block w/ T1, B2 = block w/ T2<br />
# Verify B2 height - 144 >= B1 height.<br />
# Verify mined T2 == announced T2<br />
# Fail and waste sacrifice if not.<br />
<br />
<br />
Thus a minimal root record is MPK and is provably<br />
* linked to the sacrifices<br />
* MPK starts a new chain of digital signature trust, for further record updates<br />
<br />
After that, additional key-value pairs may be associated with the root record via updates verified by PPK, stored in an alt-blockchain or DHT somewhere. That is outside the scope of this minimal document.</div>Petertoddhttps://en.bitcoin.it/w/index.php?title=Talk:Forums&diff=37065Talk:Forums2013-04-15T22:03:02Z<p>Petertodd: Revert spam</p>
<hr />
<div></div>Petertoddhttps://en.bitcoin.it/w/index.php?title=Funding_network_security&diff=37063Funding network security2013-04-15T13:50:41Z<p>Petertodd: make "what is security" section</p>
<hr />
<div>If you have followed a link to this page from reddit or elsewhere discussing Mike Hearn's assurance contracts proposal to fund network security, please see [https://bitcointalk.org/index.php?topic=157141.msg1665332#msg1665332 the discussion on bitcointalk] for the original document. Below is a general discussion of how network security is funded now and could be in the future, including Mike's proposal.<br />
<br />
<hr/><br />
<br />
What Bitcoin provides is a means to determine what is the consensus version<br />
of the transaction history, with the consensus determined by what a majority of<br />
hashing power applied to the proof of work problem by miners accepts as the<br />
true history. Since those who own Bitcoins, and who have access to hashing<br />
power, are not necessarily the same group there needs to be a mechanism for the<br />
former to fund the latter. The risk is that mechanism failing, and the majority<br />
of hashing power acting in a way that is against the wishes of the majority of<br />
economic interests.<br />
<br />
An attacker with a majority of hashing power can either publish blocks they<br />
mine as they mine them, or withhold them. The former simply makes it impossible<br />
to get transactions confirmed that the attacker does not wish to be confirmed.<br />
The latter however can be used to rewrite the blockchain after the fact,<br />
causing transactions that appeared to be confirmed to become unconfirmed and<br />
vulnerable to reversal. In addition the attacker can exploit [[Transaction Malleability]] to make it impossible for those transactions to ever be included<br />
in the blockchain again.<br />
<br />
== What is security? ==<br />
<br />
The hashing power majority does not need to constitute a single individual or<br />
coherent group. For instance the economic majority may see [[fungibility]] as<br />
important, and thus want to ensure transaction outputs can not be blacklisted<ref>[https://bitcointalk.org/index.php?topic=157130.0 Decentralised crime fighting using private set intersection protocols]</ref> to prevent transactions spending them from being confirmed,<br />
even if those outputs are known to be involved with illegal activity such as theft or fraud.<br />
However the actions of mining pools are usually public knowledge; which blocks<br />
they mine is usually published on the pool website. If mining a transaction<br />
output known to be involved in illegal activity is made illegal, mining pools<br />
may independently seek out sources of information on transaction outputs known<br />
to be involved in illegal activity, and prohibit transactions spending those<br />
outputs from the blocks they mine, as well as delibrately trying to mine blocks<br />
that would [[Orphan Block|orphan blocks]] with such transactions.<br />
<br />
Similarly it could be made illegal to mine a transaction if the identity of the<br />
person making the transaction is not known, in conjunction with ways for<br />
transactions to make that identity public. Again, even if the economic majority<br />
would prefer to be able to make anonymous transactions, the hashing power<br />
majority may not want to take that risk.<br />
<br />
Conversely the opposite may be true in either example - what "security" is may not always be obvious or easily agreed upon.<br />
<br />
== Inflation Subsidy ==<br />
<br />
Currently each block [[Controlled_Currency_Supply|creates 25 BTC]] as the block<br />
reward; as of April 2013 that inflates the currency supply by about 11% per<br />
year, in effect transferring 11% of the value of all the Bitcoins in existence<br />
to miners to pay for the security they provide. However, every four years the<br />
block reward is decreased by half, thus halving the overall inflation subsidy<br />
that pays miners.<br />
<br />
The inflation subsidy pays miners directly from Bitcoin as a whole; in effect<br />
everyone holding Bitcoins is paying for security directly. However at some<br />
point it will become small enough that Bitcoin could be attacked by someone<br />
with very little resources. In addition a miner can still collect the inflation<br />
subsidy without including any transactions at all in the blocks they mine, an activity that can be seen as an attack.<ref>[https://bitcointalk.org/index.php?topic=69423.0 Miners that refuse to include transactions are becoming a problem]</ref><br />
<br />
It is predicted that the inflation subsidy will reach less than 1% of the<br />
Bitcoin nominal market cap sometime in 2033. However that figure is subject to<br />
the amount of [[lost coins]] from the early days of Bitcoin; it is unknown what<br />
the market cap of coins with owners able to spend them actually is or will be.<br />
<br />
== Transaction Fees ==<br />
<br />
Transactions may include [[transaction_fees|fees]] which are given to the miner<br />
who included the transaction in a block. These fees can range from 0% to 100%<br />
of the transaction inputs technically speaking, although what is economically<br />
practical is a subset of that.<br />
<br />
Fees can align the economic interests of Bitcoin users with the interests of<br />
miners. For instance in the above example of anonymous transactions fees can<br />
encourage miners to mine anonymous transactions regardless of the legal risk,<br />
or to take (possibly expensive) measures to reduce that risk.<br />
<br />
=== The Blocksize Limit ===<br />
<br />
Currently blocks are limited to 1MB in size, and further limited by "gentlemans<br />
agreement" in the form of a 500KB default maximum. While miners can choose to<br />
mine blocks exceeding the 500KB limit, the 1MB limit is fixed and any block<br />
larger than it is invalid; block space is a scarce resource. Provided that the<br />
demand for transactions is greater than about [[Maximum transaction rate|seven<br />
per second]] we can expect transaction fees to be greater than the marginal<br />
costs required to accept a transaction, thus creating a profit that can be used<br />
to fund the operation of hashing power.<br />
<br />
=== Off-chain Transactions ===<br />
<br />
If making a transaction becomes too expensive it can become worthwhile to use an [[Off-Chain Transactions|off-chain payment system]] to move the funds instead, either one denominated in Bitcoins, or in a different currency entirely. The availability of off-chain transactions limits the maximum fees that miners can charge, in turn limiting the value of transactions as a way to fund security.<br />
<br />
== Alternatives ==<br />
<br />
If transaction fees and the inflation subsidy do not pay for adequate security<br />
alternatives exist. In particular users who own Bitcoins, yet do not perform<br />
transactions, possibly because they are holding onto their Bitcoins as an<br />
investment and/or use off-chain transactions, only pay for security through the<br />
inflation subsidy.<br />
<br />
In addition one approach to the [[scalability|scalability problem]] posed by<br />
the current 1MB blocksize limit is to remove or increase that limit. Without<br />
the blocksize limit it is expected that transaction fees will fall to the<br />
[[marginal costs of a transaction]], which means that fees will not pay for any<br />
security at all.<br />
<br />
=== Individual ===<br />
<br />
As individuals Bitcoin owners can fund network security in a variety of ways,<br />
including artifical fee-paying transactions, paying abnormally high fees,<br />
donating directly to known miners, and operating their own mining equipment.<br />
The latter two methods have the advantage that the donator has control over the<br />
policy followed by the miner being funded.<br />
<br />
However mining is a public good: any individual can also simply hope that<br />
others will fund security for them, also known as the<br />
[http://en.wikipedia.org/wiki/Free_rider_problem free rider problem].<br />
<br />
=== Assurance Contracts ===<br />
<br />
An assurance contract, also known as a provision point mechanism, is a game<br />
theoretic mechanism and a financial technology that facilitates the voluntary<br />
creation of public goods and club goods in the face of the free rider<br />
problem.<ref>http://en.wikipedia.org/wiki/Assurance_contract</ref><br />
<br />
The free rider problem is that there may be actions that would benefit a large<br />
group of people, but once the action is taken, there is no way to exclude those<br />
who did not pay for the action from the benefits. In Bitcoin the problem is<br />
that mining is costly and benefits everyone who owns Bitcoins and/or performs<br />
transactions. A mining assurance contract needs to be constructed in such a way<br />
that participants agree that if some large amount of funds are commited, those<br />
funds will go to mining in some way, with the amount set to be large enough for<br />
a sufficiently high percentage of the economic activity of Bitcoin must have<br />
participated to avoid the free rider problem.<br />
<br />
Bitcoin already supports assurance contracts as a transaction<br />
type<ref>[[Contracts#Example_3:_Assurance_contracts]]</ref> - for a<br />
mining assurance contract the transaction output would be set to either an<br />
[[Script#Anyone-Can-Spend_Outputs|anyone can spend]] output, or an address owned<br />
by a specific miner. However as-is they have a serious problem: a miner can<br />
always collect the funds pledged to date by simply adding a sufficient amount<br />
of their own funds to the outstanding contract, and mining that transaction<br />
themselves, thus turning the contract into a simple<br />
donation.<ref>[https://bitcointalk.org/index.php?topic=157141.msg1821770#msg1821770]</ref><br />
(modulo the small chance of the block being orphaned; if the chance is large, the assurance contract is not encouraging orderly mining) The problem can be mitigated somewhat by forcing donators to reveal their identity in a provable way, but then high participation is difficult to achieve.<br />
<br />
With [[nLockTime]] a transaction can be created where the miner who will<br />
actually collect it is unknown in advance. As the deadline approaches, if the<br />
contract is not fully funded, participants double-spend their pledged<br />
transaction outputs to invalidate the contract. However this mechanism has the<br />
problem that anyone can make the contract fail, even if it is fully funded.<br />
That problem can be solved if Bitcoin's scripting language is extended to allow<br />
for transaction outputs that can only be spent by transactions following<br />
certain forms - the outputs would be locked to the contract until some time<br />
after the contract<br />
expires.<ref>[https://bitcointalk.org/index.php?topic=157141.msg1822138#msg1822138]</ref><br />
<br />
== References ==<br />
<references/><br />
* [https://bitcointalk.org/index.php?topic=157141.0 Bitcointalk thread]<br />
[[Category:Technical]]</div>Petertoddhttps://en.bitcoin.it/w/index.php?title=Funding_network_security&diff=37062Funding network security2013-04-15T13:49:27Z<p>Petertodd: grammar</p>
<hr />
<div>If you have followed a link to this page from reddit or elsewhere discussing Mike Hearn's assurance contracts proposal to fund network security, please see [https://bitcointalk.org/index.php?topic=157141.msg1665332#msg1665332 the discussion on bitcointalk] for the original document. Below is a general discussion of how network security is funded now and could be in the future, including Mike's proposal.<br />
<br />
<hr/><br />
<br />
What Bitcoin provides is a means to determine what is the consensus version<br />
of the transaction history, with the consensus determined by what a majority of<br />
hashing power applied to the proof of work problem by miners accepts as the<br />
true history. Since those who own Bitcoins, and who have access to hashing<br />
power, are not necessarily the same group there needs to be a mechanism for the<br />
former to fund the latter. The risk is that mechanism failing, and the majority<br />
of hashing power acting in a way that is against the wishes of the majority of<br />
economic interests.<br />
<br />
An attacker with a majority of hashing power can either publish blocks they<br />
mine as they mine them, or withhold them. The former simply makes it impossible<br />
to get transactions confirmed that the attacker does not wish to be confirmed.<br />
The latter however can be used to rewrite the blockchain after the fact,<br />
causing transactions that appeared to be confirmed to become unconfirmed and<br />
vulnerable to reversal. In addition the attacker can exploit [[Transaction Malleability]] to make it impossible for those transactions to ever be included<br />
in the blockchain again.<br />
<br />
The hashing power majority does not need to constitute a single individual or<br />
coherent group. For instance the economic majority may see [[fungibility]] as<br />
important, and thus want to ensure transaction outputs can not be blacklisted<ref>[https://bitcointalk.org/index.php?topic=157130.0 Decentralised crime fighting using private set intersection protocols]</ref> to prevent transactions spending them from being confirmed,<br />
even if those outputs are known to be involved with illegal activity such as theft or fraud.<br />
However the actions of mining pools are usually public knowledge; which blocks<br />
they mine is usually published on the pool website. If mining a transaction<br />
output known to be involved in illegal activity is made illegal, mining pools<br />
may independently seek out sources of information on transaction outputs known<br />
to be involved in illegal activity, and prohibit transactions spending those<br />
outputs from the blocks they mine, as well as delibrately trying to mine blocks<br />
that would [[Orphan Block|orphan blocks]] with such transactions.<br />
<br />
Similarly it could be made illegal to mine a transaction if the identity of the<br />
person making the transaction is not known, in conjunction with ways for<br />
transactions to make that identity public. Again, even if the economic majority<br />
would prefer to be able to make anonymous transactions, the hashing power<br />
majority may not want to take that risk.<br />
<br />
Conversely the opposite may be true in either example - what "security" is may not always be obvious or easily agreed upon.<br />
<br />
== Inflation Subsidy ==<br />
<br />
Currently each block [[Controlled_Currency_Supply|creates 25 BTC]] as the block<br />
reward; as of April 2013 that inflates the currency supply by about 11% per<br />
year, in effect transferring 11% of the value of all the Bitcoins in existence<br />
to miners to pay for the security they provide. However, every four years the<br />
block reward is decreased by half, thus halving the overall inflation subsidy<br />
that pays miners.<br />
<br />
The inflation subsidy pays miners directly from Bitcoin as a whole; in effect<br />
everyone holding Bitcoins is paying for security directly. However at some<br />
point it will become small enough that Bitcoin could be attacked by someone<br />
with very little resources. In addition a miner can still collect the inflation<br />
subsidy without including any transactions at all in the blocks they mine, an activity that can be seen as an attack.<ref>[https://bitcointalk.org/index.php?topic=69423.0 Miners that refuse to include transactions are becoming a problem]</ref><br />
<br />
It is predicted that the inflation subsidy will reach less than 1% of the<br />
Bitcoin nominal market cap sometime in 2033. However that figure is subject to<br />
the amount of [[lost coins]] from the early days of Bitcoin; it is unknown what<br />
the market cap of coins with owners able to spend them actually is or will be.<br />
<br />
== Transaction Fees ==<br />
<br />
Transactions may include [[transaction_fees|fees]] which are given to the miner<br />
who included the transaction in a block. These fees can range from 0% to 100%<br />
of the transaction inputs technically speaking, although what is economically<br />
practical is a subset of that.<br />
<br />
Fees can align the economic interests of Bitcoin users with the interests of<br />
miners. For instance in the above example of anonymous transactions fees can<br />
encourage miners to mine anonymous transactions regardless of the legal risk,<br />
or to take (possibly expensive) measures to reduce that risk.<br />
<br />
=== The Blocksize Limit ===<br />
<br />
Currently blocks are limited to 1MB in size, and further limited by "gentlemans<br />
agreement" in the form of a 500KB default maximum. While miners can choose to<br />
mine blocks exceeding the 500KB limit, the 1MB limit is fixed and any block<br />
larger than it is invalid; block space is a scarce resource. Provided that the<br />
demand for transactions is greater than about [[Maximum transaction rate|seven<br />
per second]] we can expect transaction fees to be greater than the marginal<br />
costs required to accept a transaction, thus creating a profit that can be used<br />
to fund the operation of hashing power.<br />
<br />
=== Off-chain Transactions ===<br />
<br />
If making a transaction becomes too expensive it can become worthwhile to use an [[Off-Chain Transactions|off-chain payment system]] to move the funds instead, either one denominated in Bitcoins, or in a different currency entirely. The availability of off-chain transactions limits the maximum fees that miners can charge, in turn limiting the value of transactions as a way to fund security.<br />
<br />
== Alternatives ==<br />
<br />
If transaction fees and the inflation subsidy do not pay for adequate security<br />
alternatives exist. In particular users who own Bitcoins, yet do not perform<br />
transactions, possibly because they are holding onto their Bitcoins as an<br />
investment and/or use off-chain transactions, only pay for security through the<br />
inflation subsidy.<br />
<br />
In addition one approach to the [[scalability|scalability problem]] posed by<br />
the current 1MB blocksize limit is to remove or increase that limit. Without<br />
the blocksize limit it is expected that transaction fees will fall to the<br />
[[marginal costs of a transaction]], which means that fees will not pay for any<br />
security at all.<br />
<br />
=== Individual ===<br />
<br />
As individuals Bitcoin owners can fund network security in a variety of ways,<br />
including artifical fee-paying transactions, paying abnormally high fees,<br />
donating directly to known miners, and operating their own mining equipment.<br />
The latter two methods have the advantage that the donator has control over the<br />
policy followed by the miner being funded.<br />
<br />
However mining is a public good: any individual can also simply hope that<br />
others will fund security for them, also known as the<br />
[http://en.wikipedia.org/wiki/Free_rider_problem free rider problem].<br />
<br />
=== Assurance Contracts ===<br />
<br />
An assurance contract, also known as a provision point mechanism, is a game<br />
theoretic mechanism and a financial technology that facilitates the voluntary<br />
creation of public goods and club goods in the face of the free rider<br />
problem.<ref>http://en.wikipedia.org/wiki/Assurance_contract</ref><br />
<br />
The free rider problem is that there may be actions that would benefit a large<br />
group of people, but once the action is taken, there is no way to exclude those<br />
who did not pay for the action from the benefits. In Bitcoin the problem is<br />
that mining is costly and benefits everyone who owns Bitcoins and/or performs<br />
transactions. A mining assurance contract needs to be constructed in such a way<br />
that participants agree that if some large amount of funds are commited, those<br />
funds will go to mining in some way, with the amount set to be large enough for<br />
a sufficiently high percentage of the economic activity of Bitcoin must have<br />
participated to avoid the free rider problem.<br />
<br />
Bitcoin already supports assurance contracts as a transaction<br />
type<ref>[[Contracts#Example_3:_Assurance_contracts]]</ref> - for a<br />
mining assurance contract the transaction output would be set to either an<br />
[[Script#Anyone-Can-Spend_Outputs|anyone can spend]] output, or an address owned<br />
by a specific miner. However as-is they have a serious problem: a miner can<br />
always collect the funds pledged to date by simply adding a sufficient amount<br />
of their own funds to the outstanding contract, and mining that transaction<br />
themselves, thus turning the contract into a simple<br />
donation.<ref>[https://bitcointalk.org/index.php?topic=157141.msg1821770#msg1821770]</ref><br />
(modulo the small chance of the block being orphaned; if the chance is large, the assurance contract is not encouraging orderly mining) The problem can be mitigated somewhat by forcing donators to reveal their identity in a provable way, but then high participation is difficult to achieve.<br />
<br />
With [[nLockTime]] a transaction can be created where the miner who will<br />
actually collect it is unknown in advance. As the deadline approaches, if the<br />
contract is not fully funded, participants double-spend their pledged<br />
transaction outputs to invalidate the contract. However this mechanism has the<br />
problem that anyone can make the contract fail, even if it is fully funded.<br />
That problem can be solved if Bitcoin's scripting language is extended to allow<br />
for transaction outputs that can only be spent by transactions following<br />
certain forms - the outputs would be locked to the contract until some time<br />
after the contract<br />
expires.<ref>[https://bitcointalk.org/index.php?topic=157141.msg1822138#msg1822138]</ref><br />
<br />
== References ==<br />
<references/><br />
* [https://bitcointalk.org/index.php?topic=157141.0 Bitcointalk thread]<br />
[[Category:Technical]]</div>Petertoddhttps://en.bitcoin.it/w/index.php?title=Funding_network_security&diff=37061Funding network security2013-04-15T13:48:38Z<p>Petertodd: fix link</p>
<hr />
<div>If you have followed a link to this page from reddit or elsewhere discussing Mike Hearn's assurance contracts proposal to fund network security, please see [https://bitcointalk.org/index.php?topic=157141.msg1665332#msg1665332 the discussion on bitcointalk] for the original document. Below is a general discussion of how network security is funded now and could be in the future, including Mike's proposal.<br />
<br />
<hr/><br />
<br />
What Bitcoin provides is a means to determine what is the consensus version<br />
of the transaction history, with the consensus determined by what a majority of<br />
hashing power applied to the proof of work problem by miners accepts as the<br />
true history. Since those who own Bitcoins, and who have access to hashing<br />
power, are not necessarily the same group there needs to be a mechanism for the<br />
former to fund the latter. The risk is that mechanism failing, and the majority<br />
of hashing power acting in a way that is against the wishes of the majority of<br />
economic interests.<br />
<br />
An attacker with a majority of hashing power can either publish blocks they<br />
mine as they mine them, or withhold them. The former simply makes it impossible<br />
to get transactions confirmed that the attacker does not wish to be confirmed.<br />
The latter however can be used to rewrite the blockchain after the fact,<br />
causing transactions that appeared to be confirmed to become unconfirmed and<br />
vulnerable to reversal. In addition the attacker can exploit [[Transaction Malleability]] to make it impossible for those transactions to ever be included<br />
in the blockchain again.<br />
<br />
The hashing power majority does not need to constitute a single individual or<br />
coherent group. For instance the economic majority may see [[fungibility]] as<br />
important, and thus want to ensure transaction outputs can not be blacklisted<ref>[https://bitcointalk.org/index.php?topic=157130.0 Decentralised crime fighting using private set intersection protocols]</ref> to prevent transactions spending them from being confirmed,<br />
even if those outputs are known to be involved with illegal activity such as theft or fraud.<br />
However the actions of mining pools are usually public knowledge; which blocks<br />
they mine is usually published on the pool website. If mining a transaction<br />
output known to be involved in illegal activity is made illegal, mining pools<br />
may independently seek out sources of information on transaction outputs known<br />
to be involved in illegal activity, and prohibit transactions spending those<br />
outputs from the blocks they mine, as well as delibrately trying to mine blocks<br />
that would [[Orphan Block|orphan blocks]] with such transactions.<br />
<br />
Similarly it could be made illegal to mine a transaction if the identity of the<br />
person making the transaction is not known, in conjunction with ways for<br />
transactions to make that identity public. Again, even if the economic majority<br />
would prefer to be able to make anonymous transactions, the hashing power<br />
majority may not want to take that risk.<br />
<br />
Conversely the opposite may be true in either example; what "security" is may not always be obvious or easily agreed upon.<br />
<br />
== Inflation Subsidy ==<br />
<br />
Currently each block [[Controlled_Currency_Supply|creates 25 BTC]] as the block<br />
reward; as of April 2013 that inflates the currency supply by about 11% per<br />
year, in effect transferring 11% of the value of all the Bitcoins in existence<br />
to miners to pay for the security they provide. However, every four years the<br />
block reward is decreased by half, thus halving the overall inflation subsidy<br />
that pays miners.<br />
<br />
The inflation subsidy pays miners directly from Bitcoin as a whole; in effect<br />
everyone holding Bitcoins is paying for security directly. However at some<br />
point it will become small enough that Bitcoin could be attacked by someone<br />
with very little resources. In addition a miner can still collect the inflation<br />
subsidy without including any transactions at all in the blocks they mine, an activity that can be seen as an attack.<ref>[https://bitcointalk.org/index.php?topic=69423.0 Miners that refuse to include transactions are becoming a problem]</ref><br />
<br />
It is predicted that the inflation subsidy will reach less than 1% of the<br />
Bitcoin nominal market cap sometime in 2033. However that figure is subject to<br />
the amount of [[lost coins]] from the early days of Bitcoin; it is unknown what<br />
the market cap of coins with owners able to spend them actually is or will be.<br />
<br />
== Transaction Fees ==<br />
<br />
Transactions may include [[transaction_fees|fees]] which are given to the miner<br />
who included the transaction in a block. These fees can range from 0% to 100%<br />
of the transaction inputs technically speaking, although what is economically<br />
practical is a subset of that.<br />
<br />
Fees can align the economic interests of Bitcoin users with the interests of<br />
miners. For instance in the above example of anonymous transactions fees can<br />
encourage miners to mine anonymous transactions regardless of the legal risk,<br />
or to take (possibly expensive) measures to reduce that risk.<br />
<br />
=== The Blocksize Limit ===<br />
<br />
Currently blocks are limited to 1MB in size, and further limited by "gentlemans<br />
agreement" in the form of a 500KB default maximum. While miners can choose to<br />
mine blocks exceeding the 500KB limit, the 1MB limit is fixed and any block<br />
larger than it is invalid; block space is a scarce resource. Provided that the<br />
demand for transactions is greater than about [[Maximum transaction rate|seven<br />
per second]] we can expect transaction fees to be greater than the marginal<br />
costs required to accept a transaction, thus creating a profit that can be used<br />
to fund the operation of hashing power.<br />
<br />
=== Off-chain Transactions ===<br />
<br />
If making a transaction becomes too expensive it can become worthwhile to use an [[Off-Chain Transactions|off-chain payment system]] to move the funds instead, either one denominated in Bitcoins, or in a different currency entirely. The availability of off-chain transactions limits the maximum fees that miners can charge, in turn limiting the value of transactions as a way to fund security.<br />
<br />
== Alternatives ==<br />
<br />
If transaction fees and the inflation subsidy do not pay for adequate security<br />
alternatives exist. In particular users who own Bitcoins, yet do not perform<br />
transactions, possibly because they are holding onto their Bitcoins as an<br />
investment and/or use off-chain transactions, only pay for security through the<br />
inflation subsidy.<br />
<br />
In addition one approach to the [[scalability|scalability problem]] posed by<br />
the current 1MB blocksize limit is to remove or increase that limit. Without<br />
the blocksize limit it is expected that transaction fees will fall to the<br />
[[marginal costs of a transaction]], which means that fees will not pay for any<br />
security at all.<br />
<br />
=== Individual ===<br />
<br />
As individuals Bitcoin owners can fund network security in a variety of ways,<br />
including artifical fee-paying transactions, paying abnormally high fees,<br />
donating directly to known miners, and operating their own mining equipment.<br />
The latter two methods have the advantage that the donator has control over the<br />
policy followed by the miner being funded.<br />
<br />
However mining is a public good: any individual can also simply hope that<br />
others will fund security for them, also known as the<br />
[http://en.wikipedia.org/wiki/Free_rider_problem free rider problem].<br />
<br />
=== Assurance Contracts ===<br />
<br />
An assurance contract, also known as a provision point mechanism, is a game<br />
theoretic mechanism and a financial technology that facilitates the voluntary<br />
creation of public goods and club goods in the face of the free rider<br />
problem.<ref>http://en.wikipedia.org/wiki/Assurance_contract</ref><br />
<br />
The free rider problem is that there may be actions that would benefit a large<br />
group of people, but once the action is taken, there is no way to exclude those<br />
who did not pay for the action from the benefits. In Bitcoin the problem is<br />
that mining is costly and benefits everyone who owns Bitcoins and/or performs<br />
transactions. A mining assurance contract needs to be constructed in such a way<br />
that participants agree that if some large amount of funds are commited, those<br />
funds will go to mining in some way, with the amount set to be large enough for<br />
a sufficiently high percentage of the economic activity of Bitcoin must have<br />
participated to avoid the free rider problem.<br />
<br />
Bitcoin already supports assurance contracts as a transaction<br />
type<ref>[[Contracts#Example_3:_Assurance_contracts]]</ref> - for a<br />
mining assurance contract the transaction output would be set to either an<br />
[[Script#Anyone-Can-Spend_Outputs|anyone can spend]] output, or an address owned<br />
by a specific miner. However as-is they have a serious problem: a miner can<br />
always collect the funds pledged to date by simply adding a sufficient amount<br />
of their own funds to the outstanding contract, and mining that transaction<br />
themselves, thus turning the contract into a simple<br />
donation.<ref>[https://bitcointalk.org/index.php?topic=157141.msg1821770#msg1821770]</ref><br />
(modulo the small chance of the block being orphaned; if the chance is large, the assurance contract is not encouraging orderly mining) The problem can be mitigated somewhat by forcing donators to reveal their identity in a provable way, but then high participation is difficult to achieve.<br />
<br />
With [[nLockTime]] a transaction can be created where the miner who will<br />
actually collect it is unknown in advance. As the deadline approaches, if the<br />
contract is not fully funded, participants double-spend their pledged<br />
transaction outputs to invalidate the contract. However this mechanism has the<br />
problem that anyone can make the contract fail, even if it is fully funded.<br />
That problem can be solved if Bitcoin's scripting language is extended to allow<br />
for transaction outputs that can only be spent by transactions following<br />
certain forms - the outputs would be locked to the contract until some time<br />
after the contract<br />
expires.<ref>[https://bitcointalk.org/index.php?topic=157141.msg1822138#msg1822138]</ref><br />
<br />
== References ==<br />
<references/><br />
* [https://bitcointalk.org/index.php?topic=157141.0 Bitcointalk thread]<br />
[[Category:Technical]]</div>Petertoddhttps://en.bitcoin.it/w/index.php?title=Off-chain_transactions&diff=37060Off-chain transactions2013-04-15T13:00:19Z<p>Petertodd: /* Proving Fraud */ grammar</p>
<hr />
<div>An off-chain transaction is the movement of value outside of the [[block chain]]. While an [[Transactions|on-chain transaction]] - usually referred to as simply 'a transaction' - modifies the blockchain and depends on the blockchain to determine its validity an off-chain transaction relies on other methods to record and validate the transaction. Like on-chain transactions all parties must agree to accept the particular method by which the transaction occurs, the question then being, how can those parties be convinced that the movement of value has actually happened, will not be reversed, and can be exchanged in the future for something of value?<br />
<br />
With an on-chain transaction those questions are answered by the parties faith in the Bitcoin system as a whole. For instance a transaction (after some number of [[Confirmation|confirmations]]) can only be reversed if a majority of hashing power agrees to reverse the transaction. The parties to the transaction are trusting that the majority of hashing power in existence is controlled by "honest" parties who will not attempt to reverse the transaction.<br />
<br />
== Rational ==<br />
<br />
On-chain transactions have disadvantages that make them unsuitable for some applications:<br />
<br />
=== Speed ===<br />
<br />
On-chain transactions take some time to accumulate enough [[Confirmation|confirmations]] to ensure that they can-not be reversed; accepting a transaction [[Zero-Conf Transactions|without any confirmations]] is potentially risky. Confirmations take time and the time they take to accumulate is random. Off-chain transaction systems can record that a transaction has happened immediately, and, subject to the guarantees of the system itself, immediately guarantee it won't be reversed.<br />
<br />
=== Privacy/Anonymity ===<br />
<br />
All on-chain transactions are recorded publicly on the block chain; Bitcoin transactions are not inherently [[Anonymity|anonymous]]. It may be possible for a third-party to use the block chain transaction data to determine the source and/or destination of a transaction if they can gather enough information linking addresses to identities. Because off-chain transactions do not happen on the block chain they need not be public. Using cryptographic techniques such as [http://en.wikipedia.org/wiki/Blind_signature chaum tokens] it can be made impossible for even the operators of the system itself to determine who participated in a transaction.<br />
<br />
=== Cost/Scalability ===<br />
<br />
Miners usually charge [[Transaction fees|fees]] to confirm a transaction. While currently the demand for transactions is sufficiently low that fees are relatively small, and transactions can often be confirmed for free, for many applications even paying a few cents per transaction is unaffordable.<ref>[https://bitcointalk.org/index.php?topic=156334.0 How to send BitCoins with LOW TX FEE (Not No TX Fee)]</ref> In addition Bitcoin currently has a limit of 7 transactions per second, the [[blocksize limit]]. This limit is related to the [[Scalability|scalability]] of the system as a whole, and one option to achieve higher transaction volumes is to keep the blocksize limit as is and use off-chain transactions for lower-value transactions; with higher volumes fees for transactions done on-chain will rise due to supply and demand.<br />
<br />
== Methods ==<br />
<br />
The most simple example of an off-chain transaction is perhaps two friends who agree on a debt between them. The "transaction" happens by the act of agreeing that the debt exists, and the validity of it is based solely on the trust that one friend has in the other. Further transactions can be agreed upon, possibly in exchange for something of value such one friend buying the other a meal. Multiple mutually trusting parties can participate, creating a network of value owed from one to the other. As an example the [http://en.wikipedia.org/wiki/Ripple_monetary_system Ripple monetary system] takes this concept, and adds to it an automated ledger to record all the mutual debts between participating parties. However actually acting upon those debts is still a matter of trust between the parties; the system only records debts and can-not by itself cause Bitcoins or some other object of value to change hands.<br />
<br />
=== Trusted Third Parties ===<br />
<br />
If the sender and recipient do not trust each other, or would simply prefer someone else record and guarantee the transaction, they can use a [http://en.wikipedia.org/wiki/Trusted_third_party trusted third party] to record and guarantee the transaction. The vast majority of conventional banking and electronic payment systems work this way. For instance in the PayPal system, PayPal is trusted to keep an accurate record of all transactions, including within the PayPal system, as well as transactions that move funds to and from PayPal. Within Bitcoin [[Redeemable_code|redeemable code]] systems exist where a third party, such as Mt. Gox, records codes issued and promise to redeem them for either new codes, balances within the system, or Bitcoins via on-chain transactions. In addition [[E-Wallet]] services such as [[Easywallet.org]] often allow users to transfer funds between addresses within the system without creating an on-chain transaction.<br />
<br />
The difficulty with third-parties is achieving that trust. Outside of Bitcoin PayPal has been criticized<ref>[http://en.wikipedia.org/wiki/PayPal#Criticism PayPal - Criticism]</ref> for arbitrarily freezing accounts. Within Bitcoin multiple E-Wallet services such as [[MyBitcoin]] and [[Instawallet]] have failed due to hacks as well as technical mistakes resulting in the loss of some or all funds held on behalf of their customers.<br />
<br />
=== Auditing ===<br />
<br />
In addition to hacks, currently no trusted third party payment systems in Bitcoin provide any way for users to determine if the services actually hold the Bitcoins they claim to hold. Conventionally banks and payment processors are [http://en.wikipedia.org/wiki/Financial_audit audited] regularly by third-parties - because Bitcoin is based on cryptography auditing can be done in a cryptographically provable way.<br />
<br />
Gregory Maxwell has proposed<ref>private communication on IRC (gmaxwell: do you have a writeup somewhere?)</ref> to use [[merkle-sum trees]] of accounts to audit funds held by third parties. Each account with the service is assigned a number, such as a SHA256 digest, and those digests are formed into a merkle tree. Additionally for every node in the tree the sum of the account balances on both leaves is computed, and that sum becomes part of the data hashed by the parent node. The tip of the tree is then the sum of all balances for all accounts.<br />
<br />
The service proves they control the Bitcoins they claim to by signing statements with the private keys capable of spending transaction outputs present on the blockchain, and in addition regularly sign statements attesting what is the current tip of the account merkle-sum tree.<br />
<br />
Clients check that their account is included in that tree by regularly demanding proof, in the form of a merkle path, that their account leads to the claimed tip. Any discrepancy is evidence of fraud on by the service, or at least poor record-keeping.<br />
<br />
=== Proving Fraud ===<br />
<br />
If the communication protocol between client and service is designed correctly fraud by the service can be proven to others. For instance if the service cryptographically signs all communications an inconsistency between the claimed merkle-tip of the accounts held by the service and the merkle-path from a particular account to that tip can be proven by providing the signed tip, and the signed merkle-path. This fraud proof can be self-authenticating, and thus anyone who comes in possession of such a proof can broadcast it to their peers. With appropriate software all participating clients of the service can be informed of any fraud immediately taking "advantage of the nature of information being easy to spread but hard to stifle" - a core concept underlying the security of Bitcoin itself.<ref>[http://sourceforge.net/mailarchive/message.php?msg_id=30482839 Satoshi]</ref><br />
<br />
== References ==<br />
<br />
<references/></div>Petertoddhttps://en.bitcoin.it/w/index.php?title=Off-chain_transactions&diff=37059Off-chain transactions2013-04-15T12:59:44Z<p>Petertodd: /* Methods */ grammar</p>
<hr />
<div>An off-chain transaction is the movement of value outside of the [[block chain]]. While an [[Transactions|on-chain transaction]] - usually referred to as simply 'a transaction' - modifies the blockchain and depends on the blockchain to determine its validity an off-chain transaction relies on other methods to record and validate the transaction. Like on-chain transactions all parties must agree to accept the particular method by which the transaction occurs, the question then being, how can those parties be convinced that the movement of value has actually happened, will not be reversed, and can be exchanged in the future for something of value?<br />
<br />
With an on-chain transaction those questions are answered by the parties faith in the Bitcoin system as a whole. For instance a transaction (after some number of [[Confirmation|confirmations]]) can only be reversed if a majority of hashing power agrees to reverse the transaction. The parties to the transaction are trusting that the majority of hashing power in existence is controlled by "honest" parties who will not attempt to reverse the transaction.<br />
<br />
== Rational ==<br />
<br />
On-chain transactions have disadvantages that make them unsuitable for some applications:<br />
<br />
=== Speed ===<br />
<br />
On-chain transactions take some time to accumulate enough [[Confirmation|confirmations]] to ensure that they can-not be reversed; accepting a transaction [[Zero-Conf Transactions|without any confirmations]] is potentially risky. Confirmations take time and the time they take to accumulate is random. Off-chain transaction systems can record that a transaction has happened immediately, and, subject to the guarantees of the system itself, immediately guarantee it won't be reversed.<br />
<br />
=== Privacy/Anonymity ===<br />
<br />
All on-chain transactions are recorded publicly on the block chain; Bitcoin transactions are not inherently [[Anonymity|anonymous]]. It may be possible for a third-party to use the block chain transaction data to determine the source and/or destination of a transaction if they can gather enough information linking addresses to identities. Because off-chain transactions do not happen on the block chain they need not be public. Using cryptographic techniques such as [http://en.wikipedia.org/wiki/Blind_signature chaum tokens] it can be made impossible for even the operators of the system itself to determine who participated in a transaction.<br />
<br />
=== Cost/Scalability ===<br />
<br />
Miners usually charge [[Transaction fees|fees]] to confirm a transaction. While currently the demand for transactions is sufficiently low that fees are relatively small, and transactions can often be confirmed for free, for many applications even paying a few cents per transaction is unaffordable.<ref>[https://bitcointalk.org/index.php?topic=156334.0 How to send BitCoins with LOW TX FEE (Not No TX Fee)]</ref> In addition Bitcoin currently has a limit of 7 transactions per second, the [[blocksize limit]]. This limit is related to the [[Scalability|scalability]] of the system as a whole, and one option to achieve higher transaction volumes is to keep the blocksize limit as is and use off-chain transactions for lower-value transactions; with higher volumes fees for transactions done on-chain will rise due to supply and demand.<br />
<br />
== Methods ==<br />
<br />
The most simple example of an off-chain transaction is perhaps two friends who agree on a debt between them. The "transaction" happens by the act of agreeing that the debt exists, and the validity of it is based solely on the trust that one friend has in the other. Further transactions can be agreed upon, possibly in exchange for something of value such one friend buying the other a meal. Multiple mutually trusting parties can participate, creating a network of value owed from one to the other. As an example the [http://en.wikipedia.org/wiki/Ripple_monetary_system Ripple monetary system] takes this concept, and adds to it an automated ledger to record all the mutual debts between participating parties. However actually acting upon those debts is still a matter of trust between the parties; the system only records debts and can-not by itself cause Bitcoins or some other object of value to change hands.<br />
<br />
=== Trusted Third Parties ===<br />
<br />
If the sender and recipient do not trust each other, or would simply prefer someone else record and guarantee the transaction, they can use a [http://en.wikipedia.org/wiki/Trusted_third_party trusted third party] to record and guarantee the transaction. The vast majority of conventional banking and electronic payment systems work this way. For instance in the PayPal system, PayPal is trusted to keep an accurate record of all transactions, including within the PayPal system, as well as transactions that move funds to and from PayPal. Within Bitcoin [[Redeemable_code|redeemable code]] systems exist where a third party, such as Mt. Gox, records codes issued and promise to redeem them for either new codes, balances within the system, or Bitcoins via on-chain transactions. In addition [[E-Wallet]] services such as [[Easywallet.org]] often allow users to transfer funds between addresses within the system without creating an on-chain transaction.<br />
<br />
The difficulty with third-parties is achieving that trust. Outside of Bitcoin PayPal has been criticized<ref>[http://en.wikipedia.org/wiki/PayPal#Criticism PayPal - Criticism]</ref> for arbitrarily freezing accounts. Within Bitcoin multiple E-Wallet services such as [[MyBitcoin]] and [[Instawallet]] have failed due to hacks as well as technical mistakes resulting in the loss of some or all funds held on behalf of their customers.<br />
<br />
=== Auditing ===<br />
<br />
In addition to hacks, currently no trusted third party payment systems in Bitcoin provide any way for users to determine if the services actually hold the Bitcoins they claim to hold. Conventionally banks and payment processors are [http://en.wikipedia.org/wiki/Financial_audit audited] regularly by third-parties - because Bitcoin is based on cryptography auditing can be done in a cryptographically provable way.<br />
<br />
Gregory Maxwell has proposed<ref>private communication on IRC (gmaxwell: do you have a writeup somewhere?)</ref> to use [[merkle-sum trees]] of accounts to audit funds held by third parties. Each account with the service is assigned a number, such as a SHA256 digest, and those digests are formed into a merkle tree. Additionally for every node in the tree the sum of the account balances on both leaves is computed, and that sum becomes part of the data hashed by the parent node. The tip of the tree is then the sum of all balances for all accounts.<br />
<br />
The service proves they control the Bitcoins they claim to by signing statements with the private keys capable of spending transaction outputs present on the blockchain, and in addition regularly sign statements attesting what is the current tip of the account merkle-sum tree.<br />
<br />
Clients check that their account is included in that tree by regularly demanding proof, in the form of a merkle path, that their account leads to the claimed tip. Any discrepancy is evidence of fraud on by the service, or at least poor record-keeping.<br />
<br />
=== Proving Fraud ===<br />
<br />
If the communication protocol between client and service is designed correctly fraud by the service can be proven to others. For instance if the service cryptographically signs all communications an inconsistency between the claimed merkle-tip of the accounts held by the service and the merkle-path from a particular account to that tip can be proven by providing the signed tip, and the signed merkle-path. This fraud proof can be self-authenticating, and thus anyone who comes in possession of such a proof can broadcast it to their peers. With appropriate software all participating clients of the service can be informed of any fraud immediately taking "advantage of the nature of information being easy to spread but hard to stifle", a core concept underlying the security of Bitcoin itself.<ref>[http://sourceforge.net/mailarchive/message.php?msg_id=30482839 Satoshi]</ref><br />
<br />
== References ==<br />
<br />
<references/></div>Petertoddhttps://en.bitcoin.it/w/index.php?title=Off-chain_transactions&diff=37058Off-chain transactions2013-04-15T12:57:16Z<p>Petertodd: link</p>
<hr />
<div>An off-chain transaction is the movement of value outside of the [[block chain]]. While an [[Transactions|on-chain transaction]] - usually referred to as simply 'a transaction' - modifies the blockchain and depends on the blockchain to determine its validity an off-chain transaction relies on other methods to record and validate the transaction. Like on-chain transactions all parties must agree to accept the particular method by which the transaction occurs, the question then being, how can those parties be convinced that the movement of value has actually happened, will not be reversed, and can be exchanged in the future for something of value?<br />
<br />
With an on-chain transaction those questions are answered by the parties faith in the Bitcoin system as a whole. For instance a transaction (after some number of [[Confirmation|confirmations]]) can only be reversed if a majority of hashing power agrees to reverse the transaction. The parties to the transaction are trusting that the majority of hashing power in existence is controlled by "honest" parties who will not attempt to reverse the transaction.<br />
<br />
== Rational ==<br />
<br />
On-chain transactions have disadvantages that make them unsuitable for some applications:<br />
<br />
=== Speed ===<br />
<br />
On-chain transactions take some time to accumulate enough [[Confirmation|confirmations]] to ensure that they can-not be reversed; accepting a transaction [[Zero-Conf Transactions|without any confirmations]] is potentially risky. Confirmations take time and the time they take to accumulate is random. Off-chain transaction systems can record that a transaction has happened immediately, and, subject to the guarantees of the system itself, immediately guarantee it won't be reversed.<br />
<br />
=== Privacy/Anonymity ===<br />
<br />
All on-chain transactions are recorded publicly on the block chain; Bitcoin transactions are not inherently [[Anonymity|anonymous]]. It may be possible for a third-party to use the block chain transaction data to determine the source and/or destination of a transaction if they can gather enough information linking addresses to identities. Because off-chain transactions do not happen on the block chain they need not be public. Using cryptographic techniques such as [http://en.wikipedia.org/wiki/Blind_signature chaum tokens] it can be made impossible for even the operators of the system itself to determine who participated in a transaction.<br />
<br />
=== Cost/Scalability ===<br />
<br />
Miners usually charge [[Transaction fees|fees]] to confirm a transaction. While currently the demand for transactions is sufficiently low that fees are relatively small, and transactions can often be confirmed for free, for many applications even paying a few cents per transaction is unaffordable.<ref>[https://bitcointalk.org/index.php?topic=156334.0 How to send BitCoins with LOW TX FEE (Not No TX Fee)]</ref> In addition Bitcoin currently has a limit of 7 transactions per second, the [[blocksize limit]]. This limit is related to the [[Scalability|scalability]] of the system as a whole, and one option to achieve higher transaction volumes is to keep the blocksize limit as is and use off-chain transactions for lower-value transactions; with higher volumes fees for transactions done on-chain will rise due to supply and demand.<br />
<br />
== Methods ==<br />
<br />
The most simple example of an off-chain transaction is perhaps two friends who agree on a debt between them. The "transaction" happens by the act of agreeing that the debt exists, and the validity of it is based solely on the trust that one friend has in the other. Further transactions can be agreed upon, possibly in exchange for something of value such one friend buying the other a meal. Multiple mutually trusting parties can participate, creating a network of value owed from one to the other. As an example the [http://en.wikipedia.org/wiki/Ripple_monetary_system Ripple monetary system] takes this concept, and adds to it an automated ledger to record all the mutual debts between participating parties. However actually acting upon those debts is still a matter of trust between the parties, the system only records and can-not by itself cause Bitcoins or some other object of value to change hands.<br />
<br />
=== Trusted Third Parties ===<br />
<br />
If the sender and recipient do not trust each other, or would simply prefer someone else record and guarantee the transaction, they can use a [http://en.wikipedia.org/wiki/Trusted_third_party trusted third party] to record and guarantee the transaction. The vast majority of conventional banking and electronic payment systems work this way. For instance in the PayPal system, PayPal is trusted to keep an accurate record of all transactions, including within the PayPal system, as well as transactions that move funds to and from PayPal. Within Bitcoin [[Redeemable_code|redeemable code]] systems exist where a third party, such as Mt. Gox, records codes issued and promise to redeem them for either new codes, balances within the system, or Bitcoins via on-chain transactions. In addition [[E-Wallet]] services such as [[Easywallet.org]] often allow users to transfer funds between addresses within the system without creating an on-chain transaction.<br />
<br />
The difficulty with third-parties is achieving that trust. Outside of Bitcoin PayPal has been criticized<ref>[http://en.wikipedia.org/wiki/PayPal#Criticism PayPal - Criticism]</ref> for arbitrarily freezing accounts. Within Bitcoin multiple E-Wallet services such as [[MyBitcoin]] and [[Instawallet]] have failed due to hacks as well as technical mistakes resulting in the loss of some or all funds held on behalf of their customers.<br />
<br />
=== Auditing ===<br />
<br />
In addition to hacks, currently no trusted third party payment systems in Bitcoin provide any way for users to determine if the services actually hold the Bitcoins they claim to hold. Conventionally banks and payment processors are [http://en.wikipedia.org/wiki/Financial_audit audited] regularly by third-parties - because Bitcoin is based on cryptography auditing can be done in a cryptographically provable way.<br />
<br />
Gregory Maxwell has proposed<ref>private communication on IRC (gmaxwell: do you have a writeup somewhere?)</ref> to use [[merkle-sum trees]] of accounts to audit funds held by third parties. Each account with the service is assigned a number, such as a SHA256 digest, and those digests are formed into a merkle tree. Additionally for every node in the tree the sum of the account balances on both leaves is computed, and that sum becomes part of the data hashed by the parent node. The tip of the tree is then the sum of all balances for all accounts.<br />
<br />
The service proves they control the Bitcoins they claim to by signing statements with the private keys capable of spending transaction outputs present on the blockchain, and in addition regularly sign statements attesting what is the current tip of the account merkle-sum tree.<br />
<br />
Clients check that their account is included in that tree by regularly demanding proof, in the form of a merkle path, that their account leads to the claimed tip. Any discrepancy is evidence of fraud on by the service, or at least poor record-keeping.<br />
<br />
=== Proving Fraud ===<br />
<br />
If the communication protocol between client and service is designed correctly fraud by the service can be proven to others. For instance if the service cryptographically signs all communications an inconsistency between the claimed merkle-tip of the accounts held by the service and the merkle-path from a particular account to that tip can be proven by providing the signed tip, and the signed merkle-path. This fraud proof can be self-authenticating, and thus anyone who comes in possession of such a proof can broadcast it to their peers. With appropriate software all participating clients of the service can be informed of any fraud immediately taking "advantage of the nature of information being easy to spread but hard to stifle", a core concept underlying the security of Bitcoin itself.<ref>[http://sourceforge.net/mailarchive/message.php?msg_id=30482839 Satoshi]</ref><br />
<br />
== References ==<br />
<br />
<references/></div>Petertoddhttps://en.bitcoin.it/w/index.php?title=Off-chain_transactions&diff=37057Off-chain transactions2013-04-15T12:54:53Z<p>Petertodd: /* Proving Fraud */ expand</p>
<hr />
<div>An off-chain transaction is the movement of value outside of the [[block chain]]. While an [[Transactions|on-chain transaction]] - usually referred to as simply 'a transaction' - modifies the blockchain and depends on the blockchain to determine its validity an off-chain transaction relies on other methods to record and validate the transaction. Like on-chain transactions all parties must agree to accept the particular method by which the transaction occurs, the question then being, how can those parties be convinced that the movement of value has actually happened, will not be reversed, and can be exchanged in the future for something of value?<br />
<br />
With an on-chain transaction those questions are answered by the parties faith in the Bitcoin system as a whole. For instance a transaction (after some number of confirmations) can only be reversed if a majority of hashing power agrees to reverse the transaction. The parties to the transaction are trusting that the majority of hashing power in existence is controlled by "honest" parties who will not attempt to reverse the transaction.<br />
<br />
== Rational ==<br />
<br />
On-chain transactions have disadvantages that make them unsuitable for some applications:<br />
<br />
=== Speed ===<br />
<br />
On-chain transactions take some time to accumulate enough [[Confirmation|confirmations]] to ensure that they can-not be reversed; accepting a transaction [[Zero-Conf Transactions|without any confirmations]] is potentially risky. Confirmations take time and the time they take to accumulate is random. Off-chain transaction systems can record that a transaction has happened immediately, and, subject to the guarantees of the system itself, immediately guarantee it won't be reversed.<br />
<br />
=== Privacy/Anonymity ===<br />
<br />
All on-chain transactions are recorded publicly on the block chain; Bitcoin transactions are not inherently [[Anonymity|anonymous]]. It may be possible for a third-party to use the block chain transaction data to determine the source and/or destination of a transaction if they can gather enough information linking addresses to identities. Because off-chain transactions do not happen on the block chain they need not be public. Using cryptographic techniques such as [http://en.wikipedia.org/wiki/Blind_signature chaum tokens] it can be made impossible for even the operators of the system itself to determine who participated in a transaction.<br />
<br />
=== Cost/Scalability ===<br />
<br />
Miners usually charge [[Transaction fees|fees]] to confirm a transaction. While currently the demand for transactions is sufficiently low that fees are relatively small, and transactions can often be confirmed for free, for many applications even paying a few cents per transaction is unaffordable.<ref>[https://bitcointalk.org/index.php?topic=156334.0 How to send BitCoins with LOW TX FEE (Not No TX Fee)]</ref> In addition Bitcoin currently has a limit of 7 transactions per second, the [[blocksize limit]]. This limit is related to the [[Scalability|scalability]] of the system as a whole, and one option to achieve higher transaction volumes is to keep the blocksize limit as is and use off-chain transactions for lower-value transactions; with higher volumes fees for transactions done on-chain will rise due to supply and demand.<br />
<br />
== Methods ==<br />
<br />
The most simple example of an off-chain transaction is perhaps two friends who agree on a debt between them. The "transaction" happens by the act of agreeing that the debt exists, and the validity of it is based solely on the trust that one friend has in the other. Further transactions can be agreed upon, possibly in exchange for something of value such one friend buying the other a meal. Multiple mutually trusting parties can participate, creating a network of value owed from one to the other. As an example the [http://en.wikipedia.org/wiki/Ripple_monetary_system Ripple monetary system] takes this concept, and adds to it an automated ledger to record all the mutual debts between participating parties. However actually acting upon those debts is still a matter of trust between the parties, the system only records and can-not by itself cause Bitcoins or some other object of value to change hands.<br />
<br />
=== Trusted Third Parties ===<br />
<br />
If the sender and recipient do not trust each other, or would simply prefer someone else record and guarantee the transaction, they can use a [http://en.wikipedia.org/wiki/Trusted_third_party trusted third party] to record and guarantee the transaction. The vast majority of conventional banking and electronic payment systems work this way. For instance in the PayPal system, PayPal is trusted to keep an accurate record of all transactions, including within the PayPal system, as well as transactions that move funds to and from PayPal. Within Bitcoin [[Redeemable_code|redeemable code]] systems exist where a third party, such as Mt. Gox, records codes issued and promise to redeem them for either new codes, balances within the system, or Bitcoins via on-chain transactions. In addition [[E-Wallet]] services such as [[Easywallet.org]] often allow users to transfer funds between addresses within the system without creating an on-chain transaction.<br />
<br />
The difficulty with third-parties is achieving that trust. Outside of Bitcoin PayPal has been criticized<ref>[http://en.wikipedia.org/wiki/PayPal#Criticism PayPal - Criticism]</ref> for arbitrarily freezing accounts. Within Bitcoin multiple E-Wallet services such as [[MyBitcoin]] and [[Instawallet]] have failed due to hacks as well as technical mistakes resulting in the loss of some or all funds held on behalf of their customers.<br />
<br />
=== Auditing ===<br />
<br />
In addition to hacks, currently no trusted third party payment systems in Bitcoin provide any way for users to determine if the services actually hold the Bitcoins they claim to hold. Conventionally banks and payment processors are [http://en.wikipedia.org/wiki/Financial_audit audited] regularly by third-parties - because Bitcoin is based on cryptography auditing can be done in a cryptographically provable way.<br />
<br />
Gregory Maxwell has proposed<ref>private communication on IRC (gmaxwell: do you have a writeup somewhere?)</ref> to use [[merkle-sum trees]] of accounts to audit funds held by third parties. Each account with the service is assigned a number, such as a SHA256 digest, and those digests are formed into a merkle tree. Additionally for every node in the tree the sum of the account balances on both leaves is computed, and that sum becomes part of the data hashed by the parent node. The tip of the tree is then the sum of all balances for all accounts.<br />
<br />
The service proves they control the Bitcoins they claim to by signing statements with the private keys capable of spending transaction outputs present on the blockchain, and in addition regularly sign statements attesting what is the current tip of the account merkle-sum tree.<br />
<br />
Clients check that their account is included in that tree by regularly demanding proof, in the form of a merkle path, that their account leads to the claimed tip. Any discrepancy is evidence of fraud on by the service, or at least poor record-keeping.<br />
<br />
=== Proving Fraud ===<br />
<br />
If the communication protocol between client and service is designed correctly fraud by the service can be proven to others. For instance if the service cryptographically signs all communications an inconsistency between the claimed merkle-tip of the accounts held by the service and the merkle-path from a particular account to that tip can be proven by providing the signed tip, and the signed merkle-path. This fraud proof can be self-authenticating, and thus anyone who comes in possession of such a proof can broadcast it to their peers. With appropriate software all participating clients of the service can be informed of any fraud immediately taking "advantage of the nature of information being easy to spread but hard to stifle", a core concept underlying the security of Bitcoin itself.<ref>[http://sourceforge.net/mailarchive/message.php?msg_id=30482839 Satoshi]</ref><br />
<br />
== References ==<br />
<br />
<references/></div>Petertoddhttps://en.bitcoin.it/w/index.php?title=Off-chain_transactions&diff=37056Off-chain transactions2013-04-15T12:54:01Z<p>Petertodd: /* Auditing Third Parties */ proving fraud</p>
<hr />
<div>An off-chain transaction is the movement of value outside of the [[block chain]]. While an [[Transactions|on-chain transaction]] - usually referred to as simply 'a transaction' - modifies the blockchain and depends on the blockchain to determine its validity an off-chain transaction relies on other methods to record and validate the transaction. Like on-chain transactions all parties must agree to accept the particular method by which the transaction occurs, the question then being, how can those parties be convinced that the movement of value has actually happened, will not be reversed, and can be exchanged in the future for something of value?<br />
<br />
With an on-chain transaction those questions are answered by the parties faith in the Bitcoin system as a whole. For instance a transaction (after some number of confirmations) can only be reversed if a majority of hashing power agrees to reverse the transaction. The parties to the transaction are trusting that the majority of hashing power in existence is controlled by "honest" parties who will not attempt to reverse the transaction.<br />
<br />
== Rational ==<br />
<br />
On-chain transactions have disadvantages that make them unsuitable for some applications:<br />
<br />
=== Speed ===<br />
<br />
On-chain transactions take some time to accumulate enough [[Confirmation|confirmations]] to ensure that they can-not be reversed; accepting a transaction [[Zero-Conf Transactions|without any confirmations]] is potentially risky. Confirmations take time and the time they take to accumulate is random. Off-chain transaction systems can record that a transaction has happened immediately, and, subject to the guarantees of the system itself, immediately guarantee it won't be reversed.<br />
<br />
=== Privacy/Anonymity ===<br />
<br />
All on-chain transactions are recorded publicly on the block chain; Bitcoin transactions are not inherently [[Anonymity|anonymous]]. It may be possible for a third-party to use the block chain transaction data to determine the source and/or destination of a transaction if they can gather enough information linking addresses to identities. Because off-chain transactions do not happen on the block chain they need not be public. Using cryptographic techniques such as [http://en.wikipedia.org/wiki/Blind_signature chaum tokens] it can be made impossible for even the operators of the system itself to determine who participated in a transaction.<br />
<br />
=== Cost/Scalability ===<br />
<br />
Miners usually charge [[Transaction fees|fees]] to confirm a transaction. While currently the demand for transactions is sufficiently low that fees are relatively small, and transactions can often be confirmed for free, for many applications even paying a few cents per transaction is unaffordable.<ref>[https://bitcointalk.org/index.php?topic=156334.0 How to send BitCoins with LOW TX FEE (Not No TX Fee)]</ref> In addition Bitcoin currently has a limit of 7 transactions per second, the [[blocksize limit]]. This limit is related to the [[Scalability|scalability]] of the system as a whole, and one option to achieve higher transaction volumes is to keep the blocksize limit as is and use off-chain transactions for lower-value transactions; with higher volumes fees for transactions done on-chain will rise due to supply and demand.<br />
<br />
== Methods ==<br />
<br />
The most simple example of an off-chain transaction is perhaps two friends who agree on a debt between them. The "transaction" happens by the act of agreeing that the debt exists, and the validity of it is based solely on the trust that one friend has in the other. Further transactions can be agreed upon, possibly in exchange for something of value such one friend buying the other a meal. Multiple mutually trusting parties can participate, creating a network of value owed from one to the other. As an example the [http://en.wikipedia.org/wiki/Ripple_monetary_system Ripple monetary system] takes this concept, and adds to it an automated ledger to record all the mutual debts between participating parties. However actually acting upon those debts is still a matter of trust between the parties, the system only records and can-not by itself cause Bitcoins or some other object of value to change hands.<br />
<br />
=== Trusted Third Parties ===<br />
<br />
If the sender and recipient do not trust each other, or would simply prefer someone else record and guarantee the transaction, they can use a [http://en.wikipedia.org/wiki/Trusted_third_party trusted third party] to record and guarantee the transaction. The vast majority of conventional banking and electronic payment systems work this way. For instance in the PayPal system, PayPal is trusted to keep an accurate record of all transactions, including within the PayPal system, as well as transactions that move funds to and from PayPal. Within Bitcoin [[Redeemable_code|redeemable code]] systems exist where a third party, such as Mt. Gox, records codes issued and promise to redeem them for either new codes, balances within the system, or Bitcoins via on-chain transactions. In addition [[E-Wallet]] services such as [[Easywallet.org]] often allow users to transfer funds between addresses within the system without creating an on-chain transaction.<br />
<br />
The difficulty with third-parties is achieving that trust. Outside of Bitcoin PayPal has been criticized<ref>[http://en.wikipedia.org/wiki/PayPal#Criticism PayPal - Criticism]</ref> for arbitrarily freezing accounts. Within Bitcoin multiple E-Wallet services such as [[MyBitcoin]] and [[Instawallet]] have failed due to hacks as well as technical mistakes resulting in the loss of some or all funds held on behalf of their customers.<br />
<br />
=== Auditing ===<br />
<br />
In addition to hacks, currently no trusted third party payment systems in Bitcoin provide any way for users to determine if the services actually hold the Bitcoins they claim to hold. Conventionally banks and payment processors are [http://en.wikipedia.org/wiki/Financial_audit audited] regularly by third-parties - because Bitcoin is based on cryptography auditing can be done in a cryptographically provable way.<br />
<br />
Gregory Maxwell has proposed<ref>private communication on IRC (gmaxwell: do you have a writeup somewhere?)</ref> to use [[merkle-sum trees]] of accounts to audit funds held by third parties. Each account with the service is assigned a number, such as a SHA256 digest, and those digests are formed into a merkle tree. Additionally for every node in the tree the sum of the account balances on both leaves is computed, and that sum becomes part of the data hashed by the parent node. The tip of the tree is then the sum of all balances for all accounts.<br />
<br />
The service proves they control the Bitcoins they claim to by signing statements with the private keys capable of spending transaction outputs present on the blockchain, and in addition regularly sign statements attesting what is the current tip of the account merkle-sum tree.<br />
<br />
Clients check that their account is included in that tree by regularly demanding proof, in the form of a merkle path, that their account leads to the claimed tip. Any discrepancy is evidence of fraud on by the service, or at least poor record-keeping.<br />
<br />
=== Proving Fraud ===<br />
<br />
If the communication protocol between client and service is designed correctly fraud by the service can be proven to others. For instance if the service cryptographically signs all communications an inconsistency between the claimed merkle-tip of the accounts held by the service and the merkle-path from a particular account to that tip can be proven by providing the signed tip, and the signed merkle-path. This fraud proof can be self-authenticating, and thus anyone who comes in possession of such a proof can broadcast it to their peers. With appropriate software all participating clients of the service can be informed of any fraud immediately, taking "advantage of the nature of information being easy to spread but hard to stifle."<ref>[http://sourceforge.net/mailarchive/message.php?msg_id=30482839 Satoshi]</ref><br />
<br />
== References ==<br />
<br />
<references/></div>Petertoddhttps://en.bitcoin.it/w/index.php?title=Off-chain_transactions&diff=37055Off-chain transactions2013-04-15T12:39:16Z<p>Petertodd: /* Rational */</p>
<hr />
<div>An off-chain transaction is the movement of value outside of the [[block chain]]. While an [[Transactions|on-chain transaction]] - usually referred to as simply 'a transaction' - modifies the blockchain and depends on the blockchain to determine its validity an off-chain transaction relies on other methods to record and validate the transaction. Like on-chain transactions all parties must agree to accept the particular method by which the transaction occurs, the question then being, how can those parties be convinced that the movement of value has actually happened, will not be reversed, and can be exchanged in the future for something of value?<br />
<br />
With an on-chain transaction those questions are answered by the parties faith in the Bitcoin system as a whole. For instance a transaction (after some number of confirmations) can only be reversed if a majority of hashing power agrees to reverse the transaction. The parties to the transaction are trusting that the majority of hashing power in existence is controlled by "honest" parties who will not attempt to reverse the transaction.<br />
<br />
== Rational ==<br />
<br />
On-chain transactions have disadvantages that make them unsuitable for some applications:<br />
<br />
=== Speed ===<br />
<br />
On-chain transactions take some time to accumulate enough [[Confirmation|confirmations]] to ensure that they can-not be reversed; accepting a transaction [[Zero-Conf Transactions|without any confirmations]] is potentially risky. Confirmations take time and the time they take to accumulate is random. Off-chain transaction systems can record that a transaction has happened immediately, and, subject to the guarantees of the system itself, immediately guarantee it won't be reversed.<br />
<br />
=== Privacy/Anonymity ===<br />
<br />
All on-chain transactions are recorded publicly on the block chain; Bitcoin transactions are not inherently [[Anonymity|anonymous]]. It may be possible for a third-party to use the block chain transaction data to determine the source and/or destination of a transaction if they can gather enough information linking addresses to identities. Because off-chain transactions do not happen on the block chain they need not be public. Using cryptographic techniques such as [http://en.wikipedia.org/wiki/Blind_signature chaum tokens] it can be made impossible for even the operators of the system itself to determine who participated in a transaction.<br />
<br />
=== Cost/Scalability ===<br />
<br />
Miners usually charge [[Transaction fees|fees]] to confirm a transaction. While currently the demand for transactions is sufficiently low that fees are relatively small, and transactions can often be confirmed for free, for many applications even paying a few cents per transaction is unaffordable.<ref>[https://bitcointalk.org/index.php?topic=156334.0 How to send BitCoins with LOW TX FEE (Not No TX Fee)]</ref> In addition Bitcoin currently has a limit of 7 transactions per second, the [[blocksize limit]]. This limit is related to the [[Scalability|scalability]] of the system as a whole, and one option to achieve higher transaction volumes is to keep the blocksize limit as is and use off-chain transactions for lower-value transactions; with higher volumes fees for transactions done on-chain will rise due to supply and demand.<br />
<br />
== Methods ==<br />
<br />
The most simple example of an off-chain transaction is perhaps two friends who agree on a debt between them. The "transaction" happens by the act of agreeing that the debt exists, and the validity of it is based solely on the trust that one friend has in the other. Further transactions can be agreed upon, possibly in exchange for something of value such one friend buying the other a meal. Multiple mutually trusting parties can participate, creating a network of value owed from one to the other. As an example the [http://en.wikipedia.org/wiki/Ripple_monetary_system Ripple monetary system] takes this concept, and adds to it an automated ledger to record all the mutual debts between participating parties. However actually acting upon those debts is still a matter of trust between the parties, the system only records and can-not by itself cause Bitcoins or some other object of value to change hands.<br />
<br />
=== Trusted Third Parties ===<br />
<br />
If the sender and recipient do not trust each other, or would simply prefer someone else record and guarantee the transaction, they can use a [http://en.wikipedia.org/wiki/Trusted_third_party trusted third party] to record and guarantee the transaction. The vast majority of conventional banking and electronic payment systems work this way. For instance in the PayPal system, PayPal is trusted to keep an accurate record of all transactions, including within the PayPal system, as well as transactions that move funds to and from PayPal. Within Bitcoin [[Redeemable_code|redeemable code]] systems exist where a third party, such as Mt. Gox, records codes issued and promise to redeem them for either new codes, balances within the system, or Bitcoins via on-chain transactions. In addition [[E-Wallet]] services such as [[Easywallet.org]] often allow users to transfer funds between addresses within the system without creating an on-chain transaction.<br />
<br />
The difficulty with third-parties is achieving that trust. Outside of Bitcoin PayPal has been criticized<ref>[http://en.wikipedia.org/wiki/PayPal#Criticism PayPal - Criticism]</ref> for arbitrarily freezing accounts. Within Bitcoin multiple E-Wallet services such as [[MyBitcoin]] and [[Instawallet]] have failed due to hacks as well as technical mistakes resulting in the loss of some or all funds held on behalf of their customers.<br />
<br />
=== Auditing Third Parties ===<br />
<br />
In addition to hacks, currently no trusted third party payment systems in Bitcoin provide any way for users to determine if the services actually hold the Bitcoins they claim to hold. Conventionally banks and payment processors are [http://en.wikipedia.org/wiki/Financial_audit audited] regularly by third-parties - because Bitcoin is based on cryptography auditing can be done in a cryptographically provable way.<br />
<br />
Gregory Maxwell has proposed<ref>private communication on IRC (gmaxwell: do you have a writeup somewhere?)</ref> to use [[merkle-sum trees]] of accounts to audit funds held by third parties. Each account with the service is assigned a number, such as a SHA256 digest, and those digests are formed into a merkle tree. Additionally for every node in the tree the sum of the account balances on both leaves is computed, and that sum becomes part of the data hashed by the parent node. The tip of the tree is then the sum of all balances for all accounts.<br />
<br />
The service proves they control the Bitcoins they claim to by signing statements with the private keys capable of spending transaction outputs present on the blockchain, and in addition regularly sign statements attesting what is the current tip of the account merkle-sum tree.<br />
<br />
Clients check that their account is included in that tree by regularly demanding proof, in the form of a merkle path, that their account leads to the claimed tip. Any discrepancy is evidence of fraud on by the service, or at least poor record-keeping.<br />
<br />
== References ==<br />
<br />
<references/></div>Petertoddhttps://en.bitcoin.it/w/index.php?title=Off-chain_transactions&diff=37054Off-chain transactions2013-04-15T11:55:00Z<p>Petertodd: grammar</p>
<hr />
<div>An off-chain transaction is the movement of value outside of the [[block chain]]. While an [[Transactions|on-chain transaction]] - usually referred to as simply 'a transaction' - modifies the blockchain and depends on the blockchain to determine its validity an off-chain transaction relies on other methods to record and validate the transaction. Like on-chain transactions all parties must agree to accept the particular method by which the transaction occurs, the question then being, how can those parties be convinced that the movement of value has actually happened, will not be reversed, and can be exchanged in the future for something of value?<br />
<br />
With an on-chain transaction those questions are answered by the parties faith in the Bitcoin system as a whole. For instance a transaction (after some number of confirmations) can only be reversed if a majority of hashing power agrees to reverse the transaction. The parties to the transaction are trusting that the majority of hashing power in existence is controlled by "honest" parties who will not attempt to reverse the transaction.<br />
<br />
== Rational ==<br />
<br />
On-chain transactions have disadvantages that make them unsuitable for some applications:<br />
<br />
=== Speed ===<br />
<br />
On-chain transactions take some time to accumulate enough [[Confirmation|confirmations]] to ensure that they can-not be reversed; accepting a transaction [[Zero-Conf Transactions|without any confirmations]] is potentially risky. Confirmations take time and the time they take to accumulate is random. Off-chain transaction systems can record that a transaction has happened immediately, and, subject to the guarantees of the system itself, immediately guarantee it won't be reversed.<br />
<br />
=== Privacy/Anonymity ===<br />
<br />
All on-chain transactions are recorded publicly on the block chain; Bitcoin transactions are not inherently [[Anonymity|anonymous]]. It may be possible for a third-party to use the block chain transaction data to determine the source and/or destination of a transaction if they can gather enough information linking addresses to identities. Because off-chain transactions do not happen on the block chain they need not be public. Using cryptographic techniques such as [http://en.wikipedia.org/wiki/Blind_signature chaum tokens] it can be made impossible for even the operators of the system itself to determine who participated in a transaction.<br />
<br />
=== Cost/Scalability ===<br />
<br />
Miners usually charge [[Transaction fees|fees]] to confirm a transaction. While currently the demand for transactions is sufficiently low that fees are relatively small, and transactions can often be confirmed for free, for many applications even paying a few cents per transaction is unaffordable.<ref>[https://bitcointalk.org/index.php?topic=156334.0 How to send BitCoins with LOW TX FEE (Not No TX Fee)]</ref> In addition Bitcoin currently has a limit of 7 transactions per second, the [[blocksize limit]]. This limit is related to the [[Scalability|scalability]] of the system as a whole, and one option to achieve higher transaction volumes is to keep the blocksize limit as is and use off-chain transactions for lower-value transactions; with higher volumes fees for transactions done on-chain will rise due to supply and demand.<br />
<br />
== References ==<br />
<br />
<references/></div>Petertoddhttps://en.bitcoin.it/w/index.php?title=Off-chain_transactions&diff=37053Off-chain transactions2013-04-15T11:54:21Z<p>Petertodd: First version</p>
<hr />
<div>An off-chain transaction is the movement of value outside of the [[block chain]]. While an [[Transactions|on-chain transaction]] - usually referred to as simply 'a transaction' - modifies the blockchain and depends on the blockchain to determine its validity an off-chain transaction relies on other methods to record and validate the transaction. Like on-chain transactions all parties must agree to accept the particular method by which the transaction occurs, the question then being, how can those parties be convinced that the movement of value has actually happened, will not be reversed, and can be exchanged in the future for something of value?<br />
<br />
With an on-chain transaction those question are answered by the parties faith in the Bitcoin system as a whole. For instance a transaction (after some number of confirmations) can only be reversed if a majority of hashing power agrees to reverse the transaction. The parties to the transaction are trusting that the majority of hashing power in existence is controlled by "honest" parties who will not attempt to reverse the transaction.<br />
<br />
== Rational ==<br />
<br />
On-chain transactions have disadvantages that make them unsuitable for some applications:<br />
<br />
=== Speed ===<br />
<br />
On-chain transactions take some time to accumulate enough [[Confirmation|confirmations]] to ensure that they can-not be reversed; accepting a transaction [[Zero-Conf Transactions|without any confirmations]] is potentially risky. Confirmations take time and the time they take to accumulate is random. Off-chain transaction systems can record that a transaction has happened immediately, and, subject to the guarantees of the system itself, immediately guarantee it won't be reversed.<br />
<br />
=== Privacy/Anonymity ===<br />
<br />
All on-chain transactions are recorded publicly on the block chain; Bitcoin transactions are not inherently [[Anonymity|anonymous]]. It may be possible for a third-party to use the block chain transaction data to determine the source and/or destination of a transaction if they can gather enough information linking addresses to identities. Because off-chain transactions do not happen on the block chain they need not be public. Using cryptographic techniques such as [http://en.wikipedia.org/wiki/Blind_signature chaum tokens] it can be made impossible for even the operators of the system itself to determine who participated in a transaction.<br />
<br />
=== Cost/Scalability ===<br />
<br />
Miners usually charge [[Transaction fees|fees]] to confirm a transaction. While currently the demand for transactions is sufficiently low that fees are relatively small, and transactions can often be confirmed for free, for many applications even paying a few cents per transaction is unaffordable.<ref>[https://bitcointalk.org/index.php?topic=156334.0 How to send BitCoins with LOW TX FEE (Not No TX Fee)]</ref> In addition Bitcoin currently has a limit of 7 transactions per second, the [[blocksize limit]]. This limit is related to the [[Scalability|scalability]] of the system as a whole, and one option to achieve higher transaction volumes is to keep the blocksize limit as is and use off-chain transactions for lower-value transactions; with higher volumes fees for transactions done on-chain will rise due to supply and demand.<br />
<br />
== References ==<br />
<br />
<references/></div>Petertoddhttps://en.bitcoin.it/w/index.php?title=Funding_network_security&diff=37052Funding network security2013-04-15T11:06:22Z<p>Petertodd: /* Off-chain Transactions */ grammerz</p>
<hr />
<div>If you have followed a link to this page from reddit or elsewhere discussing Mike Hearn's assurance contracts proposal to fund network security, please see [https://bitcointalk.org/index.php?topic=157141.msg1665332#msg1665332|the discussion on bitcointalk] for the original document. Below is a general discussion of how network security is funded now and could be in the future, including Mike's proposal.<br />
<br />
<hr/><br />
<br />
What Bitcoin provides is a means to determine what is the consensus version<br />
of the transaction history, with the consensus determined by what a majority of<br />
hashing power applied to the proof of work problem by miners accepts as the<br />
true history. Since those who own Bitcoins, and who have access to hashing<br />
power, are not necessarily the same group there needs to be a mechanism for the<br />
former to fund the latter. The risk is that mechanism failing, and the majority<br />
of hashing power acting in a way that is against the wishes of the majority of<br />
economic interests.<br />
<br />
An attacker with a majority of hashing power can either publish blocks they<br />
mine as they mine them, or withhold them. The former simply makes it impossible<br />
to get transactions confirmed that the attacker does not wish to be confirmed.<br />
The latter however can be used to rewrite the blockchain after the fact,<br />
causing transactions that appeared to be confirmed to become unconfirmed and<br />
vulnerable to reversal. In addition the attacker can exploit [[Transaction Malleability]] to make it impossible for those transactions to ever be included<br />
in the blockchain again.<br />
<br />
The hashing power majority does not need to constitute a single individual or<br />
coherent group. For instance the economic majority may see [[fungibility]] as<br />
important, and thus want to ensure transaction outputs can not be blacklisted<ref>[https://bitcointalk.org/index.php?topic=157130.0 Decentralised crime fighting using private set intersection protocols]</ref> to prevent transactions spending them from being confirmed,<br />
even if those outputs are known to be involved with illegal activity such as theft or fraud.<br />
However the actions of mining pools are usually public knowledge; which blocks<br />
they mine is usually published on the pool website. If mining a transaction<br />
output known to be involved in illegal activity is made illegal, mining pools<br />
may independently seek out sources of information on transaction outputs known<br />
to be involved in illegal activity, and prohibit transactions spending those<br />
outputs from the blocks they mine, as well as delibrately trying to mine blocks<br />
that would [[Orphan Block|orphan blocks]] with such transactions.<br />
<br />
Similarly it could be made illegal to mine a transaction if the identity of the<br />
person making the transaction is not known, in conjunction with ways for<br />
transactions to make that identity public. Again, even if the economic majority<br />
would prefer to be able to make anonymous transactions, the hashing power<br />
majority may not want to take that risk.<br />
<br />
Conversely the opposite may be true in either example; what "security" is may not always be obvious or easily agreed upon.<br />
<br />
== Inflation Subsidy ==<br />
<br />
Currently each block [[Controlled_Currency_Supply|creates 25 BTC]] as the block<br />
reward; as of April 2013 that inflates the currency supply by about 11% per<br />
year, in effect transferring 11% of the value of all the Bitcoins in existence<br />
to miners to pay for the security they provide. However, every four years the<br />
block reward is decreased by half, thus halving the overall inflation subsidy<br />
that pays miners.<br />
<br />
The inflation subsidy pays miners directly from Bitcoin as a whole; in effect<br />
everyone holding Bitcoins is paying for security directly. However at some<br />
point it will become small enough that Bitcoin could be attacked by someone<br />
with very little resources. In addition a miner can still collect the inflation<br />
subsidy without including any transactions at all in the blocks they mine, an activity that can be seen as an attack.<ref>[https://bitcointalk.org/index.php?topic=69423.0 Miners that refuse to include transactions are becoming a problem]</ref><br />
<br />
It is predicted that the inflation subsidy will reach less than 1% of the<br />
Bitcoin nominal market cap sometime in 2033. However that figure is subject to<br />
the amount of [[lost coins]] from the early days of Bitcoin; it is unknown what<br />
the market cap of coins with owners able to spend them actually is or will be.<br />
<br />
== Transaction Fees ==<br />
<br />
Transactions may include [[transaction_fees|fees]] which are given to the miner<br />
who included the transaction in a block. These fees can range from 0% to 100%<br />
of the transaction inputs technically speaking, although what is economically<br />
practical is a subset of that.<br />
<br />
Fees can align the economic interests of Bitcoin users with the interests of<br />
miners. For instance in the above example of anonymous transactions fees can<br />
encourage miners to mine anonymous transactions regardless of the legal risk,<br />
or to take (possibly expensive) measures to reduce that risk.<br />
<br />
=== The Blocksize Limit ===<br />
<br />
Currently blocks are limited to 1MB in size, and further limited by "gentlemans<br />
agreement" in the form of a 500KB default maximum. While miners can choose to<br />
mine blocks exceeding the 500KB limit, the 1MB limit is fixed and any block<br />
larger than it is invalid; block space is a scarce resource. Provided that the<br />
demand for transactions is greater than about [[Maximum transaction rate|seven<br />
per second]] we can expect transaction fees to be greater than the marginal<br />
costs required to accept a transaction, thus creating a profit that can be used<br />
to fund the operation of hashing power.<br />
<br />
=== Off-chain Transactions ===<br />
<br />
If making a transaction becomes too expensive it can become worthwhile to use an [[Off-Chain Transactions|off-chain payment system]] to move the funds instead, either one denominated in Bitcoins, or in a different currency entirely. The availability of off-chain transactions limits the maximum fees that miners can charge, in turn limiting the value of transactions as a way to fund security.<br />
<br />
== Alternatives ==<br />
<br />
If transaction fees and the inflation subsidy do not pay for adequate security<br />
alternatives exist. In particular users who own Bitcoins, yet do not perform<br />
transactions, possibly because they are holding onto their Bitcoins as an<br />
investment and/or use off-chain transactions, only pay for security through the<br />
inflation subsidy.<br />
<br />
In addition one approach to the [[scalability|scalability problem]] posed by<br />
the current 1MB blocksize limit is to remove or increase that limit. Without<br />
the blocksize limit it is expected that transaction fees will fall to the<br />
[[marginal costs of a transaction]], which means that fees will not pay for any<br />
security at all.<br />
<br />
=== Individual ===<br />
<br />
As individuals Bitcoin owners can fund network security in a variety of ways,<br />
including artifical fee-paying transactions, paying abnormally high fees,<br />
donating directly to known miners, and operating their own mining equipment.<br />
The latter two methods have the advantage that the donator has control over the<br />
policy followed by the miner being funded.<br />
<br />
However mining is a public good: any individual can also simply hope that<br />
others will fund security for them, also known as the<br />
[http://en.wikipedia.org/wiki/Free_rider_problem free rider problem].<br />
<br />
=== Assurance Contracts ===<br />
<br />
An assurance contract, also known as a provision point mechanism, is a game<br />
theoretic mechanism and a financial technology that facilitates the voluntary<br />
creation of public goods and club goods in the face of the free rider<br />
problem.<ref>http://en.wikipedia.org/wiki/Assurance_contract</ref><br />
<br />
The free rider problem is that there may be actions that would benefit a large<br />
group of people, but once the action is taken, there is no way to exclude those<br />
who did not pay for the action from the benefits. In Bitcoin the problem is<br />
that mining is costly and benefits everyone who owns Bitcoins and/or performs<br />
transactions. A mining assurance contract needs to be constructed in such a way<br />
that participants agree that if some large amount of funds are commited, those<br />
funds will go to mining in some way, with the amount set to be large enough for<br />
a sufficiently high percentage of the economic activity of Bitcoin must have<br />
participated to avoid the free rider problem.<br />
<br />
Bitcoin already supports assurance contracts as a transaction<br />
type<ref>[[Contracts#Example_3:_Assurance_contracts]]</ref> - for a<br />
mining assurance contract the transaction output would be set to either an<br />
[[Script#Anyone-Can-Spend_Outputs|anyone can spend]] output, or an address owned<br />
by a specific miner. However as-is they have a serious problem: a miner can<br />
always collect the funds pledged to date by simply adding a sufficient amount<br />
of their own funds to the outstanding contract, and mining that transaction<br />
themselves, thus turning the contract into a simple<br />
donation.<ref>[https://bitcointalk.org/index.php?topic=157141.msg1821770#msg1821770]</ref><br />
(modulo the small chance of the block being orphaned; if the chance is large, the assurance contract is not encouraging orderly mining) The problem can be mitigated somewhat by forcing donators to reveal their identity in a provable way, but then high participation is difficult to achieve.<br />
<br />
With [[nLockTime]] a transaction can be created where the miner who will<br />
actually collect it is unknown in advance. As the deadline approaches, if the<br />
contract is not fully funded, participants double-spend their pledged<br />
transaction outputs to invalidate the contract. However this mechanism has the<br />
problem that anyone can make the contract fail, even if it is fully funded.<br />
That problem can be solved if Bitcoin's scripting language is extended to allow<br />
for transaction outputs that can only be spent by transactions following<br />
certain forms - the outputs would be locked to the contract until some time<br />
after the contract<br />
expires.<ref>[https://bitcointalk.org/index.php?topic=157141.msg1822138#msg1822138]</ref><br />
<br />
== References ==<br />
<references/><br />
* [https://bitcointalk.org/index.php?topic=157141.0 Bitcointalk thread]<br />
[[Category:Technical]]</div>Petertoddhttps://en.bitcoin.it/w/index.php?title=Funding_network_security&diff=37051Funding network security2013-04-15T11:06:01Z<p>Petertodd: /* Off-chain Transactions */ add link</p>
<hr />
<div>If you have followed a link to this page from reddit or elsewhere discussing Mike Hearn's assurance contracts proposal to fund network security, please see [https://bitcointalk.org/index.php?topic=157141.msg1665332#msg1665332|the discussion on bitcointalk] for the original document. Below is a general discussion of how network security is funded now and could be in the future, including Mike's proposal.<br />
<br />
<hr/><br />
<br />
What Bitcoin provides is a means to determine what is the consensus version<br />
of the transaction history, with the consensus determined by what a majority of<br />
hashing power applied to the proof of work problem by miners accepts as the<br />
true history. Since those who own Bitcoins, and who have access to hashing<br />
power, are not necessarily the same group there needs to be a mechanism for the<br />
former to fund the latter. The risk is that mechanism failing, and the majority<br />
of hashing power acting in a way that is against the wishes of the majority of<br />
economic interests.<br />
<br />
An attacker with a majority of hashing power can either publish blocks they<br />
mine as they mine them, or withhold them. The former simply makes it impossible<br />
to get transactions confirmed that the attacker does not wish to be confirmed.<br />
The latter however can be used to rewrite the blockchain after the fact,<br />
causing transactions that appeared to be confirmed to become unconfirmed and<br />
vulnerable to reversal. In addition the attacker can exploit [[Transaction Malleability]] to make it impossible for those transactions to ever be included<br />
in the blockchain again.<br />
<br />
The hashing power majority does not need to constitute a single individual or<br />
coherent group. For instance the economic majority may see [[fungibility]] as<br />
important, and thus want to ensure transaction outputs can not be blacklisted<ref>[https://bitcointalk.org/index.php?topic=157130.0 Decentralised crime fighting using private set intersection protocols]</ref> to prevent transactions spending them from being confirmed,<br />
even if those outputs are known to be involved with illegal activity such as theft or fraud.<br />
However the actions of mining pools are usually public knowledge; which blocks<br />
they mine is usually published on the pool website. If mining a transaction<br />
output known to be involved in illegal activity is made illegal, mining pools<br />
may independently seek out sources of information on transaction outputs known<br />
to be involved in illegal activity, and prohibit transactions spending those<br />
outputs from the blocks they mine, as well as delibrately trying to mine blocks<br />
that would [[Orphan Block|orphan blocks]] with such transactions.<br />
<br />
Similarly it could be made illegal to mine a transaction if the identity of the<br />
person making the transaction is not known, in conjunction with ways for<br />
transactions to make that identity public. Again, even if the economic majority<br />
would prefer to be able to make anonymous transactions, the hashing power<br />
majority may not want to take that risk.<br />
<br />
Conversely the opposite may be true in either example; what "security" is may not always be obvious or easily agreed upon.<br />
<br />
== Inflation Subsidy ==<br />
<br />
Currently each block [[Controlled_Currency_Supply|creates 25 BTC]] as the block<br />
reward; as of April 2013 that inflates the currency supply by about 11% per<br />
year, in effect transferring 11% of the value of all the Bitcoins in existence<br />
to miners to pay for the security they provide. However, every four years the<br />
block reward is decreased by half, thus halving the overall inflation subsidy<br />
that pays miners.<br />
<br />
The inflation subsidy pays miners directly from Bitcoin as a whole; in effect<br />
everyone holding Bitcoins is paying for security directly. However at some<br />
point it will become small enough that Bitcoin could be attacked by someone<br />
with very little resources. In addition a miner can still collect the inflation<br />
subsidy without including any transactions at all in the blocks they mine, an activity that can be seen as an attack.<ref>[https://bitcointalk.org/index.php?topic=69423.0 Miners that refuse to include transactions are becoming a problem]</ref><br />
<br />
It is predicted that the inflation subsidy will reach less than 1% of the<br />
Bitcoin nominal market cap sometime in 2033. However that figure is subject to<br />
the amount of [[lost coins]] from the early days of Bitcoin; it is unknown what<br />
the market cap of coins with owners able to spend them actually is or will be.<br />
<br />
== Transaction Fees ==<br />
<br />
Transactions may include [[transaction_fees|fees]] which are given to the miner<br />
who included the transaction in a block. These fees can range from 0% to 100%<br />
of the transaction inputs technically speaking, although what is economically<br />
practical is a subset of that.<br />
<br />
Fees can align the economic interests of Bitcoin users with the interests of<br />
miners. For instance in the above example of anonymous transactions fees can<br />
encourage miners to mine anonymous transactions regardless of the legal risk,<br />
or to take (possibly expensive) measures to reduce that risk.<br />
<br />
=== The Blocksize Limit ===<br />
<br />
Currently blocks are limited to 1MB in size, and further limited by "gentlemans<br />
agreement" in the form of a 500KB default maximum. While miners can choose to<br />
mine blocks exceeding the 500KB limit, the 1MB limit is fixed and any block<br />
larger than it is invalid; block space is a scarce resource. Provided that the<br />
demand for transactions is greater than about [[Maximum transaction rate|seven<br />
per second]] we can expect transaction fees to be greater than the marginal<br />
costs required to accept a transaction, thus creating a profit that can be used<br />
to fund the operation of hashing power.<br />
<br />
=== Off-chain Transactions ===<br />
<br />
If making a transaction becomes too expensive it can become worthwhile to use an [[Off-Chain Transactions|off-chain payment system]] to move the funds instead, either one denominated in Bitcoins, or in a different currency entirely; the availability of off-chain transactions limits the maximum fees that miners can charge, in turn limiting the value of transactions as a way to fund security.<br />
<br />
== Alternatives ==<br />
<br />
If transaction fees and the inflation subsidy do not pay for adequate security<br />
alternatives exist. In particular users who own Bitcoins, yet do not perform<br />
transactions, possibly because they are holding onto their Bitcoins as an<br />
investment and/or use off-chain transactions, only pay for security through the<br />
inflation subsidy.<br />
<br />
In addition one approach to the [[scalability|scalability problem]] posed by<br />
the current 1MB blocksize limit is to remove or increase that limit. Without<br />
the blocksize limit it is expected that transaction fees will fall to the<br />
[[marginal costs of a transaction]], which means that fees will not pay for any<br />
security at all.<br />
<br />
=== Individual ===<br />
<br />
As individuals Bitcoin owners can fund network security in a variety of ways,<br />
including artifical fee-paying transactions, paying abnormally high fees,<br />
donating directly to known miners, and operating their own mining equipment.<br />
The latter two methods have the advantage that the donator has control over the<br />
policy followed by the miner being funded.<br />
<br />
However mining is a public good: any individual can also simply hope that<br />
others will fund security for them, also known as the<br />
[http://en.wikipedia.org/wiki/Free_rider_problem free rider problem].<br />
<br />
=== Assurance Contracts ===<br />
<br />
An assurance contract, also known as a provision point mechanism, is a game<br />
theoretic mechanism and a financial technology that facilitates the voluntary<br />
creation of public goods and club goods in the face of the free rider<br />
problem.<ref>http://en.wikipedia.org/wiki/Assurance_contract</ref><br />
<br />
The free rider problem is that there may be actions that would benefit a large<br />
group of people, but once the action is taken, there is no way to exclude those<br />
who did not pay for the action from the benefits. In Bitcoin the problem is<br />
that mining is costly and benefits everyone who owns Bitcoins and/or performs<br />
transactions. A mining assurance contract needs to be constructed in such a way<br />
that participants agree that if some large amount of funds are commited, those<br />
funds will go to mining in some way, with the amount set to be large enough for<br />
a sufficiently high percentage of the economic activity of Bitcoin must have<br />
participated to avoid the free rider problem.<br />
<br />
Bitcoin already supports assurance contracts as a transaction<br />
type<ref>[[Contracts#Example_3:_Assurance_contracts]]</ref> - for a<br />
mining assurance contract the transaction output would be set to either an<br />
[[Script#Anyone-Can-Spend_Outputs|anyone can spend]] output, or an address owned<br />
by a specific miner. However as-is they have a serious problem: a miner can<br />
always collect the funds pledged to date by simply adding a sufficient amount<br />
of their own funds to the outstanding contract, and mining that transaction<br />
themselves, thus turning the contract into a simple<br />
donation.<ref>[https://bitcointalk.org/index.php?topic=157141.msg1821770#msg1821770]</ref><br />
(modulo the small chance of the block being orphaned; if the chance is large, the assurance contract is not encouraging orderly mining) The problem can be mitigated somewhat by forcing donators to reveal their identity in a provable way, but then high participation is difficult to achieve.<br />
<br />
With [[nLockTime]] a transaction can be created where the miner who will<br />
actually collect it is unknown in advance. As the deadline approaches, if the<br />
contract is not fully funded, participants double-spend their pledged<br />
transaction outputs to invalidate the contract. However this mechanism has the<br />
problem that anyone can make the contract fail, even if it is fully funded.<br />
That problem can be solved if Bitcoin's scripting language is extended to allow<br />
for transaction outputs that can only be spent by transactions following<br />
certain forms - the outputs would be locked to the contract until some time<br />
after the contract<br />
expires.<ref>[https://bitcointalk.org/index.php?topic=157141.msg1822138#msg1822138]</ref><br />
<br />
== References ==<br />
<references/><br />
* [https://bitcointalk.org/index.php?topic=157141.0 Bitcointalk thread]<br />
[[Category:Technical]]</div>Petertoddhttps://en.bitcoin.it/w/index.php?title=Fidelity_bonds&diff=37050Fidelity bonds2013-04-15T11:03:46Z<p>Petertodd: /* Financial Services */ grammerz</p>
<hr />
<div>A fidelity bond is a proposed mechanism where Bitcoins are deliberately sacrificed to make a cryptographic identity expensive to obtain. The sacrifice is done in a way that can be proven to a third party. By making the identity expensive it can be trusted not to commit unwanted acts, such as spamming message boards, or committing fraud, because upon detection of the unwanted acts the identity becomes useless, requiring the owner of the identity to purchase another one.<br />
<br />
== Mechanism ==<br />
<br />
The core of the fidelity bond is the sacrifice - the mechanism by which Bitcoins are provably taken from their original owner. The Bitcoins may be given to someone else or destroyed, but regardless it must not be possible for their original owner to regain control of them.<br />
<br />
An effective form of sacrifice is to simply create a transaction assigning the coins to an unspendable output, either an address known to not have a corresponding secret key, or to a scriptPubKey that is [[Script#Provably_Unspendable.2FPrunable_Outputs|provably unspendable]]. The Bitcoins are removed from circulation forever, a criticism of this mechanism.<br />
<br />
The Bitcoins can also be donated to a third party, such as a charity, however such donations can be controversial, allow the charity itself (or anyone with access to their funds) to purchase bonds at little or no cost, pose the problem of verifying the bonds validity in the future should the chosen charity(s) change, and finally, pose the problem of coming to a consensus on the charities themselves.<br />
<br />
In the context of Bitcoin, miners have been proposed as a third party whom any Bitcoin user can agree should receive funds, as miners act to secure the network from attack for everyone. The value is sacrificed to miners in the form of transaction fees.<br />
<br />
=== Single/Consecutive Block Sacrifices ===<br />
<br />
The sacrifice can be done with transactions that pay abnormally high fees, either single such transactions, or groups of multiple ones in a row, latter intended to prevent miners themselves from creating the sacrifices and mining them in their own blocks. Problems with consecutive transaction sacrifices include the potential for gaps, as well as the large size of the proofs of the sacrifices.<ref>[https://bitcointalk.org/index.php?topic=140711.msg1498806#msg1498806]</ref><br />
<br />
=== Announce/Commit Sacrifices ===<br />
<br />
To ensure that the miner collecting the sacrificed Bitcoin is picked at random the announce/commit sacrifice was proposed.<ref>[https://bitcointalk.org/index.php?topic=134827.0 Purchasing fidelity bonds by provably throwing away bitcoins]</ref> First a sacrifice transaction is prepared that either sacrifices value to transaction fees, or spends coins to an [[Script#Anyone-Can-Spend_Outputs|Anyone-Can-Spend Output]]. With [[nLockTime]] the transaction is made invalid until some time in the future.<br />
<br />
The second step is the announcement. The transaction is enclosed in another transaction as data, for instance by using a [[Script#Provably_Unspendable.2FPrunable_Outputs|prunable output]]. The announcement is then broadcast and is included in the blockchain, proving that anyone could have seen the inner transaction prior to it becoming valid.<br />
<br />
Finally the inner transaction becomes valid when the [[nLockTime]] is reached. Because mining is a random process, any miner can collect the value sacrified, and the purchaser of the fidelity bond has no control over where that value goes.<br />
<br />
The proof of the sacrifice is then two transactions: the proof the announcement transaction exists in the chain, and the proof that the inner sacrifice exists in the chain. (possibly with proof of the inner sacrifice inputs to prove what fees were actually paid)<br />
<br />
== Passports ==<br />
<br />
This wiki combats spam, while still allowing for users to sign up anonymously, by requiring users to pay a small amount of Bitcoins to the wiki before editing privileges are granted. Creating large numbers of "sock-puppets" to add spam content to articles is thus made expensive. The fee approach can be generalized with the concept of a Passport, first proposed by Mike Hearn,<ref>[https://bitcointalk.org/index.php?topic=140711.0 Creating Bitcoin passports using sacrifices]</ref> tied to the users identity. Wikis, forums, webmail and other services can then create blacklists of users who violate the rules of the services, with those blacklists tied to passports.<br />
<br />
The advantage of fidelity bonds in that application over simply charging fees is re-usability of an identity across multiple services, as well as the neutrality: if the value required to create the passport provably does not go to the person adding the passport to a blacklist, there is no incentive to do so to collect new sign-up fees.<br />
<br />
== Financial Services ==<br />
<br />
Fidelity bonds can be used to make financial fraud unprofitable. For instance one early proposal<ref>[http://sourceforge.net/mailarchive/message.php?msg_id=29185108 Trusted identities]</ref> was to use fidelity bonds - called "Trusted identities" by the proposal's author - to create decentralized [[Green address|green addresses]]. Someone wishing for their transactions to be accepted without confirmations would first purchase a fidelity bond of some value tied to their identity. Someone determining if they should accept a payment without confirmations can check that the bond was sufficiently expensive to make it unprofitable for the sender to commit fraud. If the sender does commit fraud by double-spending the payment, the recipient can prove that fraud to the world by providing both transactions spending the same inputs. This proof is added to some sort of blacklisted, centralized or decentralized, which later recipients can consult to determine if the fidelity bond is now invalidated.<br />
<br />
== References ==<br />
<br />
<references/></div>Petertoddhttps://en.bitcoin.it/w/index.php?title=Fidelity_bonds&diff=37049Fidelity bonds2013-04-15T11:03:11Z<p>Petertodd: First version</p>
<hr />
<div>A fidelity bond is a proposed mechanism where Bitcoins are deliberately sacrificed to make a cryptographic identity expensive to obtain. The sacrifice is done in a way that can be proven to a third party. By making the identity expensive it can be trusted not to commit unwanted acts, such as spamming message boards, or committing fraud, because upon detection of the unwanted acts the identity becomes useless, requiring the owner of the identity to purchase another one.<br />
<br />
== Mechanism ==<br />
<br />
The core of the fidelity bond is the sacrifice - the mechanism by which Bitcoins are provably taken from their original owner. The Bitcoins may be given to someone else or destroyed, but regardless it must not be possible for their original owner to regain control of them.<br />
<br />
An effective form of sacrifice is to simply create a transaction assigning the coins to an unspendable output, either an address known to not have a corresponding secret key, or to a scriptPubKey that is [[Script#Provably_Unspendable.2FPrunable_Outputs|provably unspendable]]. The Bitcoins are removed from circulation forever, a criticism of this mechanism.<br />
<br />
The Bitcoins can also be donated to a third party, such as a charity, however such donations can be controversial, allow the charity itself (or anyone with access to their funds) to purchase bonds at little or no cost, pose the problem of verifying the bonds validity in the future should the chosen charity(s) change, and finally, pose the problem of coming to a consensus on the charities themselves.<br />
<br />
In the context of Bitcoin, miners have been proposed as a third party whom any Bitcoin user can agree should receive funds, as miners act to secure the network from attack for everyone. The value is sacrificed to miners in the form of transaction fees.<br />
<br />
=== Single/Consecutive Block Sacrifices ===<br />
<br />
The sacrifice can be done with transactions that pay abnormally high fees, either single such transactions, or groups of multiple ones in a row, latter intended to prevent miners themselves from creating the sacrifices and mining them in their own blocks. Problems with consecutive transaction sacrifices include the potential for gaps, as well as the large size of the proofs of the sacrifices.<ref>[https://bitcointalk.org/index.php?topic=140711.msg1498806#msg1498806]</ref><br />
<br />
=== Announce/Commit Sacrifices ===<br />
<br />
To ensure that the miner collecting the sacrificed Bitcoin is picked at random the announce/commit sacrifice was proposed.<ref>[https://bitcointalk.org/index.php?topic=134827.0 Purchasing fidelity bonds by provably throwing away bitcoins]</ref> First a sacrifice transaction is prepared that either sacrifices value to transaction fees, or spends coins to an [[Script#Anyone-Can-Spend_Outputs|Anyone-Can-Spend Output]]. With [[nLockTime]] the transaction is made invalid until some time in the future.<br />
<br />
The second step is the announcement. The transaction is enclosed in another transaction as data, for instance by using a [[Script#Provably_Unspendable.2FPrunable_Outputs|prunable output]]. The announcement is then broadcast and is included in the blockchain, proving that anyone could have seen the inner transaction prior to it becoming valid.<br />
<br />
Finally the inner transaction becomes valid when the [[nLockTime]] is reached. Because mining is a random process, any miner can collect the value sacrified, and the purchaser of the fidelity bond has no control over where that value goes.<br />
<br />
The proof of the sacrifice is then two transactions: the proof the announcement transaction exists in the chain, and the proof that the inner sacrifice exists in the chain. (possibly with proof of the inner sacrifice inputs to prove what fees were actually paid)<br />
<br />
== Passports ==<br />
<br />
This wiki combats spam, while still allowing for users to sign up anonymously, by requiring users to pay a small amount of Bitcoins to the wiki before editing privileges are granted. Creating large numbers of "sock-puppets" to add spam content to articles is thus made expensive. The fee approach can be generalized with the concept of a Passport, first proposed by Mike Hearn,<ref>[https://bitcointalk.org/index.php?topic=140711.0 Creating Bitcoin passports using sacrifices]</ref> tied to the users identity. Wikis, forums, webmail and other services can then create blacklists of users who violate the rules of the services, with those blacklists tied to passports.<br />
<br />
The advantage of fidelity bonds in that application over simply charging fees is re-usability of an identity across multiple services, as well as the neutrality: if the value required to create the passport provably does not go to the person adding the passport to a blacklist, there is no incentive to do so to collect new sign-up fees.<br />
<br />
== Financial Services ==<br />
<br />
Fidelity bonds can be used to make financial fraud unprofitable. For instance one early proposal<ref>[http://sourceforge.net/mailarchive/message.php?msg_id=29185108 Trusted identities]</ref> was to use fidelity bonds - called "Trusted identities" by the proposals author - to create decentralized [[Green address|green addresses]]. Someone wishing for their transactions to be accepted without confirmations would first purchase a fidelity bond of some value tied to their identity. Someone determining if they should accept a payment without confirmations can check that the bond was sufficiently expensive to make it unprofitable for the sender to commit fraud. If the sender does commit fraud by double-spending the payment, the recipient can prove that fraud to the world by providing both transactions spending the same inputs. This proof is added to some sort of blacklisted, centralized or decentralized, which later recipients can consult to determine if the fidelity bond is now invalidated.<br />
<br />
== References ==<br />
<br />
<references/></div>Petertoddhttps://en.bitcoin.it/w/index.php?title=Script&diff=37047Script2013-04-15T10:08:28Z<p>Petertodd: /* Anyone-Can-Spend Outputs */ add detail</p>
<hr />
<div>Bitcoin uses a scripting system for [[transactions]]. [[Wikipedia:FORTH|Forth]]-like, Script is simple, stack-based, and processed from left to right. It is purposefully not Turing-complete, with no loops.<br />
<br />
A script is essentially a list of instructions recorded with each transaction that describe how the next person wanting to spend the Bitcoins being transferred can gain access to them. The script for a typical Bitcoin transfer to destination Bitcoin address D simply encumbers future spending of the bitcoins with two things: the spender must provide<br />
# a public key that, when hashed, yields destination address D embedded in the script, and<br />
# a signature to show evidence of the private key corresponding to the public key just provided.<br />
<br />
Scripting provides the flexibility to change the parameters of what's needed to spend transferred Bitcoins. For example, the scripting system could be used to require two private keys, or a combination of several, or even no keys at all.<br />
<br />
A transaction is valid if nothing in the combined script triggers failure and the top stack item is true (non-zero). The party who originally ''sent'' the Bitcoins now being spent, dictates the script operations that will occur ''last'' in order to release them for use in another transaction. The party wanting to spend them must provide the input(s) to the previously recorded script that results in those operations occurring last leaving behind true (non-zero).<br />
<br />
Scripts are big-endian.<br />
<br />
The stacks hold byte vectors. Byte vectors are interpreted as little-endian variable-length integers with the most significant bit determining the sign of the integer. Thus 0x81 represents -1. 0x80 is another representation of zero (so called negative 0). Byte vectors are interpreted as Booleans where False is represented by any representation of zero, and True is represented by any representation of non-zero.<br />
<br />
== Words ==<br />
This is a list of all Script words (commands/functions). Some of the more complicated opcodes are disabled out of concern that the client might have a bug in their implementation; if a transaction using such an opcode were to be included in the chain any fix would risk forking the chain. <br />
<br />
True=1 and False=0.<br />
<br />
=== Constants ===<br />
When talking about scripts, these value-pushing words are usually omitted.<br />
<br />
{| class="wikitable"<br />
|-<br />
!Word<br />
!Opcode<br />
!Hex<br />
!Input<br />
!Output<br />
!Description<br />
|-<br />
|OP_0, OP_FALSE<br />
|0<br />
|0x00<br />
|Nothing.<br />
|(empty value)<br />
|An empty array of bytes is pushed onto the stack. (This is not a no-op: an item is added to the stack.)<br />
|-<br />
|N/A<br />
|1-75<br />
|0x01-0x4b<br />
|(special)<br />
|data<br />
|The next ''opcode'' bytes is data to be pushed onto the stack<br />
|-<br />
|OP_PUSHDATA1<br />
|76<br />
|0x4c<br />
|(special)<br />
|data<br />
|The next byte contains the number of bytes to be pushed onto the stack.<br />
|-<br />
|OP_PUSHDATA2<br />
|77<br />
|0x4d<br />
|(special)<br />
|data<br />
|The next two bytes contain the number of bytes to be pushed onto the stack.<br />
|-<br />
|OP_PUSHDATA4<br />
|78<br />
|0x4e<br />
|(special)<br />
|data<br />
|The next four bytes contain the number of bytes to be pushed onto the stack.<br />
|-<br />
|OP_1NEGATE<br />
|79<br />
|0x4f<br />
|Nothing.<br />
| -1<br />
|The number -1 is pushed onto the stack.<br />
|-<br />
|OP_1, OP_TRUE<br />
|81<br />
|0x51<br />
|Nothing.<br />
|1<br />
|The number 1 is pushed onto the stack.<br />
|-<br />
|OP_2-OP_16<br />
|82-96<br />
|0x52-0x60<br />
|Nothing.<br />
|2-16<br />
|The number in the word name (2-16) is pushed onto the stack.<br />
|}<br />
<br />
=== Flow control ===<br />
<br />
{| class="wikitable"<br />
|-<br />
!Word<br />
!Opcode<br />
!Hex<br />
!Input<br />
!Output<br />
!Description<br />
|-<br />
|OP_NOP<br />
|97<br />
|0x61<br />
|Nothing<br />
|Nothing<br />
|Does nothing.<br />
|-<br />
|OP_IF<br />
|99<br />
|0x63<br />
| colspan="2"|<expression> if [statements] [else [statements]]* endif<br />
|If the top stack value is not 0, the statements are executed. The top stack value is removed.<br />
|-<br />
|OP_NOTIF<br />
|100<br />
|0x64<br />
| colspan="2"|<expression> if [statements] [else [statements]]* endif<br />
|If the top stack value is 0, the statements are executed. The top stack value is removed.<br />
|-<br />
|OP_ELSE<br />
|103<br />
|0x67<br />
| colspan="2"|<expression> if [statements] [else [statements]]* endif<br />
|If the preceding OP_IF or OP_NOTIF or OP_ELSE was not executed then these statements are and if the preceding OP_IF or OP_NOTIF or OP_ELSE was executed then these statements are not. <br />
|-<br />
|OP_ENDIF<br />
|104<br />
|0x68<br />
| colspan="2"|<expression> if [statements] [else [statements]]* endif<br />
|Ends an if/else block.<br />
|-<br />
|OP_VERIFY<br />
|105<br />
|0x69<br />
|True / false<br />
|Nothing / False<br />
|'''Marks transaction as invalid''' if top stack value is not true. True is removed, but false is not.<br />
|-<br />
|OP_RETURN<br />
|106<br />
|0x6a<br />
|Nothing<br />
|Nothing<br />
|'''Marks transaction as invalid'''. <br />
|}<br />
<br />
=== Stack ===<br />
<br />
{| class="wikitable" <br />
|-<br />
!Word<br />
!Opcode<br />
!Hex<br />
!Input<br />
!Output<br />
!Description<br />
|-<br />
|OP_TOALTSTACK<br />
|107<br />
|0x6b<br />
|x1<br />
|(alt)x1<br />
|Puts the input onto the top of the alt stack. Removes it from the main stack.<br />
|-<br />
|OP_FROMALTSTACK<br />
|108<br />
|0x6c<br />
|(alt)x1<br />
|x1<br />
|Puts the input onto the top of the main stack. Removes it from the alt stack.<br />
|-<br />
|OP_IFDUP<br />
|115<br />
|0x73<br />
|x<br />
|x / x x<br />
|If the top stack value is not 0, duplicate it.<br />
|-<br />
|OP_DEPTH<br />
|116<br />
|0x74<br />
|Nothing<br />
|<Stack size><br />
|Puts the number of stack items onto the stack.<br />
|-<br />
|OP_DROP<br />
|117<br />
|0x75<br />
|x<br />
|Nothing<br />
|Removes the top stack item.<br />
|-<br />
|OP_DUP<br />
|118<br />
|0x76<br />
|x<br />
|x x<br />
|Duplicates the top stack item.<br />
|-<br />
|OP_NIP<br />
|119<br />
|0x77<br />
|x1 x2<br />
|x2<br />
|Removes the second-to-top stack item.<br />
|-<br />
|OP_OVER<br />
|120<br />
|0x78<br />
|x1 x2<br />
|x1 x2 x1<br />
|Copies the second-to-top stack item to the top.<br />
|-<br />
|OP_PICK<br />
|121<br />
|0x79<br />
|xn ... x2 x1 x0 <n><br />
|xn ... x2 x1 x0 xn<br />
|The item ''n'' back in the stack is copied to the top.<br />
|-<br />
|OP_ROLL<br />
|122<br />
|0x7a<br />
|xn ... x2 x1 x0 <n><br />
|... x2 x1 x0 xn<br />
|The item ''n'' back in the stack is moved to the top.<br />
|-<br />
|OP_ROT<br />
|123<br />
|0x7b<br />
|x1 x2 x3<br />
|x2 x3 x1<br />
|The top three items on the stack are rotated to the left.<br />
|-<br />
|OP_SWAP<br />
|124<br />
|0x7c<br />
|x1 x2<br />
|x2 x1<br />
|The top two items on the stack are swapped.<br />
|-<br />
|OP_TUCK<br />
|125<br />
|0x7d<br />
|x1 x2<br />
|x2 x1 x2<br />
|The item at the top of the stack is copied and inserted before the second-to-top item.<br />
|-<br />
|OP_2DROP<br />
|109<br />
|0x6d<br />
|x1 x2<br />
|Nothing<br />
|Removes the top two stack items.<br />
|-<br />
|OP_2DUP<br />
|110<br />
|0x6e<br />
|x1 x2<br />
|x1 x2 x1 x2<br />
|Duplicates the top two stack items.<br />
|-<br />
|OP_3DUP<br />
|111<br />
|0x6f<br />
|x1 x2 x3<br />
|x1 x2 x3 x1 x2 x3<br />
|Duplicates the top three stack items.<br />
|-<br />
|OP_2OVER<br />
|112<br />
|0x70<br />
|x1 x2 x3 x4<br />
|x1 x2 x3 x4 x1 x2<br />
|Copies the pair of items two spaces back in the stack to the front.<br />
|-<br />
|OP_2ROT<br />
|113<br />
|0x71<br />
|x1 x2 x3 x4 x5 x6<br />
|x3 x4 x5 x6 x1 x2<br />
|The fifth and sixth items back are moved to the top of the stack.<br />
|-<br />
|OP_2SWAP<br />
|114<br />
|0x72<br />
|x1 x2 x3 x4<br />
|x3 x4 x1 x2<br />
|Swaps the top two pairs of items.<br />
|}<br />
<br />
=== Splice ===<br />
<br />
{| class="wikitable" <br />
|-<br />
!Word<br />
!Opcode<br />
!Hex<br />
!Input<br />
!Output<br />
!Description<br />
|-<br />
|OP_CAT<br />
|126<br />
|0x7e<br />
|x1 x2<br />
|out<br />
|style="background:#D97171;"|Concatenates two strings. ''Currently disabled.''<br />
|-<br />
|OP_SUBSTR<br />
|127<br />
|0x7f<br />
|in begin size<br />
|out<br />
|style="background:#D97171;"|Returns a section of a string. ''Currently disabled.''<br />
|-<br />
|OP_LEFT<br />
|128<br />
|0x80<br />
|in size<br />
|out<br />
|style="background:#D97171;"|Keeps only characters left of the specified point in a string. ''Currently disabled.''<br />
|-<br />
|OP_RIGHT<br />
|129<br />
|0x81<br />
|in size<br />
|out<br />
|style="background:#D97171;"|Keeps only characters right of the specified point in a string. ''Currently disabled.''<br />
|-<br />
|OP_SIZE<br />
|130<br />
|0x82<br />
|in<br />
|in size<br />
|Returns the length of the input string.<br />
|}<br />
<br />
=== Bitwise logic ===<br />
<br />
{| class="wikitable" <br />
|-<br />
!Word<br />
!Opcode<br />
!Hex<br />
!Input<br />
!Output<br />
!Description<br />
|-<br />
|OP_INVERT<br />
|131<br />
|0x83<br />
|in<br />
|out<br />
|style="background:#D97171;"|Flips all of the bits in the input. ''Currently disabled.''<br />
|-<br />
|OP_AND<br />
|132<br />
|0x84<br />
|x1 x2<br />
|out<br />
|style="background:#D97171;"|Boolean ''and'' between each bit in the inputs. ''Currently disabled.''<br />
|-<br />
|OP_OR<br />
|133<br />
|0x85<br />
|x1 x2<br />
|out<br />
|style="background:#D97171;"|Boolean ''or'' between each bit in the inputs. ''Currently disabled.''<br />
|-<br />
|OP_XOR<br />
|134<br />
|0x86<br />
|x1 x2<br />
|out<br />
|style="background:#D97171;"|Boolean ''exclusive or'' between each bit in the inputs. ''Currently disabled.''<br />
|-<br />
|OP_EQUAL<br />
|135<br />
|0x87<br />
|x1 x2<br />
|True / false<br />
|Returns 1 if the inputs are exactly equal, 0 otherwise.<br />
|-<br />
|OP_EQUALVERIFY<br />
|136<br />
|0x88<br />
|x1 x2<br />
|True / false<br />
|Same as OP_EQUAL, but runs OP_VERIFY afterward.<br />
|}<br />
<br />
=== Arithmetic ===<br />
<br />
Note: Arithmetic inputs are limited to signed 32-bit integers, but may overflow their output.<br />
<br />
{| class="wikitable" <br />
|-<br />
!Word<br />
!Opcode<br />
!Hex<br />
!Input<br />
!Output<br />
!Description<br />
|-<br />
|OP_1ADD<br />
|139<br />
|0x8b<br />
|in<br />
|out<br />
|1 is added to the input.<br />
|-<br />
|OP_1SUB<br />
|140<br />
|0x8c<br />
|in<br />
|out<br />
|1 is subtracted from the input.<br />
|-<br />
|OP_2MUL<br />
|141<br />
|0x8d<br />
|in<br />
|out<br />
|style="background:#D97171;"|The input is multiplied by 2. ''Currently disabled.''<br />
|-<br />
|OP_2DIV<br />
|142<br />
|0x8e<br />
|in<br />
|out<br />
|style="background:#D97171;"|The input is divided by 2. ''Currently disabled.''<br />
|-<br />
|OP_NEGATE<br />
|143<br />
|0x8f<br />
|in<br />
|out<br />
|The sign of the input is flipped.<br />
|-<br />
|OP_ABS<br />
|144<br />
|0x90<br />
|in<br />
|out<br />
|The input is made positive.<br />
|-<br />
|OP_NOT<br />
|145<br />
|0x91<br />
|in<br />
|out<br />
|If the input is 0 or 1, it is flipped. Otherwise the output will be 0.<br />
|-<br />
|OP_0NOTEQUAL<br />
|146<br />
|0x92<br />
|in<br />
|out<br />
|Returns 0 if the input is 0. 1 otherwise.<br />
|-<br />
|OP_ADD<br />
|147<br />
|0x93<br />
|a b<br />
|out<br />
|a is added to b.<br />
|-<br />
|OP_SUB<br />
|148<br />
|0x94<br />
|a b<br />
|out<br />
|b is subtracted from a.<br />
|-<br />
|OP_MUL<br />
|149<br />
|0x95<br />
|a b<br />
|out<br />
|style="background:#D97171;"|a is multiplied by b. ''Currently disabled.''<br />
|-<br />
|OP_DIV<br />
|150<br />
|0x96<br />
|a b<br />
|out<br />
|style="background:#D97171;"|a is divided by b. ''Currently disabled.''<br />
|-<br />
|OP_MOD<br />
|151<br />
|0x97<br />
|a b<br />
|out<br />
|style="background:#D97171;"|Returns the remainder after dividing a by b. ''Currently disabled.''<br />
|-<br />
|OP_LSHIFT<br />
|152<br />
|0x98<br />
|a b<br />
|out<br />
|style="background:#D97171;"|Shifts a left b bits, preserving sign. ''Currently disabled.''<br />
|-<br />
|OP_RSHIFT<br />
|153<br />
|0x99<br />
|a b<br />
|out<br />
|style="background:#D97171;"|Shifts a right b bits, preserving sign. ''Currently disabled.''<br />
|-<br />
|OP_BOOLAND<br />
|154<br />
|0x9a<br />
|a b<br />
|out<br />
|If both a and b are not 0, the output is 1. Otherwise 0.<br />
|-<br />
|OP_BOOLOR<br />
|155<br />
|0x9b<br />
|a b<br />
|out<br />
|If a or b is not 0, the output is 1. Otherwise 0.<br />
|-<br />
|OP_NUMEQUAL<br />
|156<br />
|0x9c<br />
|a b<br />
|out<br />
|Returns 1 if the numbers are equal, 0 otherwise.<br />
|-<br />
|OP_NUMEQUALVERIFY<br />
|157<br />
|0x9d<br />
|a b<br />
|out<br />
|Same as OP_NUMEQUAL, but runs OP_VERIFY afterward.<br />
|-<br />
|OP_NUMNOTEQUAL<br />
|158<br />
|0x9e<br />
|a b<br />
|out<br />
|Returns 1 if the numbers are not equal, 0 otherwise.<br />
|-<br />
|OP_LESSTHAN<br />
|159<br />
|0x9f<br />
|a b<br />
|out<br />
|Returns 1 if a is less than b, 0 otherwise.<br />
|-<br />
|OP_GREATERTHAN<br />
|160<br />
|0xa0<br />
|a b<br />
|out<br />
|Returns 1 if a is greater than b, 0 otherwise.<br />
|-<br />
|OP_LESSTHANOREQUAL<br />
|161<br />
|0xa1<br />
|a b<br />
|out<br />
|Returns 1 if a is less than or equal to b, 0 otherwise.<br />
|-<br />
|OP_GREATERTHANOREQUAL<br />
|162<br />
|0xa2<br />
|a b<br />
|out<br />
|Returns 1 if a is greater than or equal to b, 0 otherwise.<br />
|-<br />
|OP_MIN<br />
|163<br />
|0xa3<br />
|a b<br />
|out<br />
|Returns the smaller of a and b.<br />
|-<br />
|OP_MAX<br />
|164<br />
|0xa4<br />
|a b<br />
|out<br />
|Returns the larger of a and b.<br />
|-<br />
|OP_WITHIN<br />
|165<br />
|0xa5<br />
|x min max<br />
|out<br />
|Returns 1 if x is within the specified range (left-inclusive), 0 otherwise.<br />
|}<br />
<br />
=== Crypto ===<br />
<br />
{| class="wikitable" <br />
|-<br />
!Word<br />
!Opcode<br />
!Hex<br />
!Input<br />
!Output<br />
!Description<br />
|-<br />
|OP_RIPEMD160<br />
|166<br />
|0xa6<br />
|in<br />
|hash<br />
|The input is hashed using RIPEMD-160.<br />
|-<br />
|OP_SHA1<br />
|167<br />
|0xa7<br />
|in<br />
|hash<br />
|The input is hashed using SHA-1.<br />
|-<br />
|OP_SHA256<br />
|168<br />
|0xa8<br />
|in<br />
|hash<br />
|The input is hashed using SHA-256.<br />
|-<br />
|OP_HASH160<br />
|169<br />
|0xa9<br />
|in<br />
|hash<br />
|The input is hashed twice: first with SHA-256 and then with RIPEMD-160.<br />
|-<br />
|OP_HASH256<br />
|170<br />
|0xaa<br />
|in<br />
|hash<br />
|The input is hashed two times with SHA-256.<br />
|-<br />
|OP_CODESEPARATOR<br />
|171<br />
|0xab<br />
|Nothing<br />
|Nothing<br />
|All of the signature checking words will only match signatures to the data after the most recently-executed OP_CODESEPARATOR.<br />
|-<br />
|[[OP_CHECKSIG]]<br />
|172<br />
|0xac<br />
|sig pubkey<br />
|True / false<br />
|The entire transaction's outputs, inputs, and script (from the most recently-executed OP_CODESEPARATOR to the end) are hashed. The signature used by OP_CHECKSIG must be a valid signature for this hash and public key. If it is, 1 is returned, 0 otherwise.<br />
|-<br />
|OP_CHECKSIGVERIFY<br />
|173<br />
|0xad<br />
|sig pubkey<br />
|True / false<br />
|Same as OP_CHECKSIG, but OP_VERIFY is executed afterward.<br />
|-<br />
|OP_CHECKMULTISIG<br />
|174<br />
|0xae<br />
|x sig1 sig2 ... <number of signatures> pub1 pub2 <number of public keys><br />
|True / False<br />
|For each signature and public key pair, OP_CHECKSIG is executed. If more public keys than signatures are listed, some key/sig pairs can fail. All signatures need to match a public key. If all signatures are valid, 1 is returned, 0 otherwise. Due to a bug, one extra unused value is removed from the stack.<br />
|-<br />
|OP_CHECKMULTISIGVERIFY<br />
|175<br />
|0xaf<br />
|x sig1 sig2 ... <number of signatures> pub1 pub2 ... <number of public keys><br />
|True / False<br />
|Same as OP_CHECKMULTISIG, but OP_VERIFY is executed afterward.<br />
|}<br />
<br />
===Pseudo-words===<br />
These words are used internally for assisting with transaction matching. They are invalid if used in actual scripts.<br />
{| class="wikitable" <br />
|-<br />
!Word<br />
!Opcode<br />
!Hex<br />
!Description<br />
|-<br />
|OP_PUBKEYHASH<br />
|253<br />
|0xfd<br />
|Represents a public key hashed with OP_HASH160.<br />
|-<br />
|OP_PUBKEY<br />
|254<br />
|0xfe<br />
|Represents a public key compatible with OP_CHECKSIG.<br />
|-<br />
|OP_INVALIDOPCODE<br />
|255<br />
|0xff<br />
|Matches any opcode that is not yet assigned.<br />
|}<br />
<br />
=== Reserved words ===<br />
Any opcode not assigned is also reserved. Using an unassigned opcode makes the transaction invalid.<br />
<br />
{| class="wikitable" <br />
|-<br />
!Word<br />
!Opcode<br />
!Hex<br />
!When used...<br />
|-<br />
|OP_RESERVED<br />
|80<br />
|0x50<br />
|Transaction is invalid unless occuring in an unexecuted OP_IF branch<br />
|-<br />
|OP_VER<br />
|98<br />
|0x62<br />
|Transaction is invalid unless occuring in an unexecuted OP_IF branch<br />
|-<br />
|OP_VERIF<br />
|101<br />
|0x65<br />
|Transaction is invalid even when occuring in an unexecuted OP_IF branch<br />
|-<br />
|OP_VERNOTIF<br />
|102<br />
|0x66<br />
|Transaction is invalid even when occuring in an unexecuted OP_IF branch<br />
|-<br />
|OP_RESERVED1<br />
|137<br />
|0x89<br />
|Transaction is invalid unless occuring in an unexecuted OP_IF branch<br />
|-<br />
|OP_RESERVED2<br />
|138<br />
|0x8a<br />
|Transaction is invalid unless occuring in an unexecuted OP_IF branch<br />
|-<br />
|OP_NOP1-OP_NOP10<br />
|176-185<br />
|0xb0-0xb9<br />
|The word is ignored.<br />
|}<br />
<br />
== Scripts ==<br />
This is a list of interesting scripts. Keep in mind that all constants actually use the data-pushing commands above. Note that there is a small number of standard script forms that are relayed from node to node; non-standard scripts are accepted if they are in a block, but nodes will not relay them.<br />
<br />
=== Standard Transaction to Bitcoin address ===<br />
<br />
scriptPubKey: OP_DUP OP_HASH160 <pubKeyHash> OP_EQUALVERIFY OP_CHECKSIG<br />
scriptSig: <sig> <pubKey><br />
<br />
To demonstrate how scripts look on the wire, here is a raw scriptPubKey:<br />
<pre> 76 A9 14<br />
OP_DUP OP_HASH160 Bytes to push<br />
<br />
89 AB CD EF AB BA AB BA AB BA AB BA AB BA AB BA AB BA AB BA 88 AC<br />
Data to push OP_EQUALVERIFY OP_CHECKSIG</pre><br />
<br />
Note: scriptSig is in the input of the spending transaction and scriptPubKey is in the output of the previously unspent i.e. "available" transaction.<br />
<br />
Here is how each word is processed:<br />
{| class="wikitable" <br />
|-<br />
! Stack <br />
! Script <br />
! Description <br />
|-<br />
|Empty.<br />
| <sig> <pubKey> OP_DUP OP_HASH160 <pubKeyHash> OP_EQUALVERIFY OP_CHECKSIG <br />
| scriptSig and scriptPubKey are combined.<br />
|-<br />
|<sig> <pubKey><br />
| OP_DUP OP_HASH160 <pubKeyHash> OP_EQUALVERIFY OP_CHECKSIG <br />
| Constants are added to the stack.<br />
|-<br />
|<sig> <pubKey> <pubKey><br />
| OP_HASH160 <pubKeyHash> OP_EQUALVERIFY OP_CHECKSIG <br />
| Top stack item is duplicated.<br />
|-<br />
|<sig> <pubKey> <pubHashA><br />
|<pubKeyHash> OP_EQUALVERIFY OP_CHECKSIG<br />
| Top stack item is hashed.<br />
|-<br />
|<sig> <pubKey> <pubHashA> <pubKeyHash><br />
|OP_EQUALVERIFY OP_CHECKSIG<br />
| Constant added.<br />
|-<br />
|<sig> <pubKey><br />
|OP_CHECKSIG<br />
| Equality is checked between the top two stack items.<br />
|-<br />
|true<br />
|Empty.<br />
|Signature is checked for top two stack items.<br />
|}<br />
<br />
=== Standard Generation Transaction ===<br />
<br />
OP_CHECKSIG is used directly without first hashing the public key. By default the reference implementation uses this form for coinbase payment, and scriptPubKeys of this transaction form are recognized as payments to user. The disadvantage of this transaction form is that the whole public key needs to be known in advance, implying longer payment addresses, and that it provides less protection in the event of a break in the ECDSA signature algorithm.<br />
<br />
scriptPubKey: <pubKey> OP_CHECKSIG<br />
scriptSig: <sig><br />
<br />
Checking process:<br />
{| class="wikitable" <br />
|-<br />
! Stack <br />
! Script <br />
! Description <br />
|-<br />
|Empty.<br />
|<sig> <pubKey> OP_CHECKSIG<br />
|scriptSig and scriptPubKey are combined.<br />
|-<br />
|<sig> <pubKey><br />
| OP_CHECKSIG<br />
|Constants are added to the stack.<br />
|-<br />
|true<br />
|Empty.<br />
|Signature is checked for top two stack items.<br />
|}<br />
<br />
=== Provably Unspendable/Prunable Outputs ===<br />
<br />
The standard way to mark a transaction as provably unspendable is with a scriptPubKey of the following form:<br />
<br />
scriptPubKey: OP_RETURN {zero or more ops}<br />
<br />
OP_RETURN immediately marks the script as invalid, guaranteeing that no scriptSig exists that could possibly spend that output. Thus the output can be immediately pruned from the UTXO set even if it has not been spent. eb31ca1a4cbd97c2770983164d7560d2d03276ae1aee26f12d7c2c6424252f29 is an example, and acts to donate 0.125BTC to the miner who mined the transaction. Another use is to add data to a transaction, as seen in 1a2e22a717d626fc5db363582007c46924ae6b28319f07cb1b907776bd8293fc<br />
<br />
Note that this mechanism is not yet a standard transaction type, and thus will not be relayed by nodes on mainnet.<br />
<br />
=== Anyone-Can-Spend Outputs ===<br />
<br />
Conversely a transaction can be made spendable by anyone at all:<br />
<br />
scriptPubKey: (empty)<br />
scriptSig: OP_TRUE<br />
<br />
With some software changes such transactions can be used as a way to donate funds to miners in addition to transaction fees: any miner who mines such a transaction can also include an additional one after it sending the funds to an address they control. This mechanism may be used in the future for [[fidelity bonds]] to sacrifice funds in a provable way.<br />
<br />
Anyone-Can-Spend outputs are currently considered non-standard, and are not relayed on the P2P network.<br />
<br />
=== Transaction with a message ===<br />
<br />
It's possible to add arbitrary data to any transaction by just adding some data along with OP_DROP. Scripts are limited to 10,000 bytes and 201 instructions, and each individual instruction/value is limited to 520 bytes.<br />
<br />
scriptPubKey: <message> OP_DROP <pubKey> OP_CHECKSIG<br />
scriptSig: <sig><br />
<br />
{| class="wikitable" <br />
|-<br />
! Stack <br />
! Script <br />
! Description <br />
|-<br />
|Empty.<br />
|<sig> <message> OP_DROP <pubKey> OP_CHECKSIG<br />
|<br />
|-<br />
|<sig><br />
|<message> OP_DROP <pubKey> OP_CHECKSIG<br />
|scriptSig added to the stack.<br />
|-<br />
|<sig> <message><br />
|OP_DROP <pubKey> OP_CHECKSIG<br />
|The message has been put.<br />
|-<br />
|<sig><br />
|<pubKey> OP_CHECKSIG<br />
|Top stack item has been removed.<br />
|-<br />
|<sig> <pubKey><br />
|OP_CHECKSIG<br />
|Checking signature against the public key.<br />
|-<br />
|true<br />
|Empty.<br />
|Stack holds the value of signature check now.<br />
|}<br />
<br />
=== Transaction puzzle ===<br />
<br />
Transaction a4bfa8ab6435ae5f25dae9d89e4eb67dfa94283ca751f393c1ddc5a837bbc31b is an interesting puzzle.<br />
<br />
scriptPubKey: OP_HASH256 6fe28c0ab6f1b372c1a6a246ae63f74f931e8365e15a089c68d6190000000000 OP_EQUAL<br />
scriptSig: <data><br />
<br />
To spend the transaction you need to come up with some data such that hashing the data twice results in the given hash.<br />
<br />
{| class="wikitable" <br />
|-<br />
! Stack <br />
! Script <br />
! Description <br />
|-<br />
|Empty.<br />
|<data> OP_HASH256 <given_hash> OP_EQUAL<br />
|<br />
|-<br />
|<data><br />
|OP_HASH256 <given_hash> OP_EQUAL<br />
|scriptSig added to the stack.<br />
|-<br />
|<data_hash><br />
|<given_hash> OP_EQUAL<br />
|The data is hashed.<br />
|-<br />
|<data_hash> <given_hash><br />
|OP_EQUAL<br />
|The given hash is pushed to the stack.<br />
|-<br />
|true<br />
|Empty.<br />
|The hashes are compared, leaving true on the stack.<br />
|}<br />
<br />
This transaction was successfully spent by 09f691b2263260e71f363d1db51ff3100d285956a40cc0e4f8c8c2c4a80559b1. The required data happened to be the [[Genesis block]], and the given hash was the genesis block hash. Note that while transactions like this are fun, they are not secure, because they do not contain any signatures and thus any transaction attempting to spend them can be replaced with a different transaction sending the funds somewhere else.<br />
<br />
==See Also==<br />
<br />
* [[Transactions]]<br />
* [[Contracts]]<br />
<br />
<br />
[[Category:Technical]]<br />
[[Category:Vocabulary]]</div>Petertoddhttps://en.bitcoin.it/w/index.php?title=User:Petertodd&diff=37044User:Petertodd2013-04-15T08:36:25Z<p>Petertodd: Formatting</p>
<hr />
<div> <nowiki>-----BEGIN PGP SIGNED MESSAGE-----<br />
Hash: SHA1<br />
<br />
https://en.bitcoin.it/wiki/User:Petertodd is the bitcoin.it wiki page of<br />
Peter Todd, AKA retep on bitcointalk<br />
<br />
https://github.com/petertodd<br />
-----BEGIN PGP SIGNATURE-----<br />
Version: GnuPG v1.4.11 (GNU/Linux)<br />
<br />
iQEcBAEBAgAGBQJRa7vzAAoJEH+rEUJn5PoExOIIAJgkrxVkMwTAl1pEbRmSwIJt<br />
PAoafHdVUaKieM/L/LhRIA1Uw+87oJXNVwuNsCUSpiY0x4GfQyZdbIz7Yd8nViU8<br />
KVyI/tswBwtq+hPtiS5LROwqeeiLtcZJrr8sOXTkucDA/mFLB+D+efEPaW10uEJJ<br />
PP0C0/cwS/s01msXjLOqYUVLK3bknkWCKnEgs8+QssRwZqWHjKSwhr23+ywv1jjM<br />
q9IL74F3fS2NvY7oV0c3y0GH3xMVBXYWEllYfHs6IZNWIX65HX8YKTyEgpDdmi0O<br />
cN3P6RLgTa1kk97/3+S+CaaeE1eOaDq8UVHKEFOtvCKzn94itlG3qrZPhbaG+4s=<br />
=K/Lo<br />
-----END PGP SIGNATURE-----<br />
</nowiki></div>Petertoddhttps://en.bitcoin.it/w/index.php?title=User:Petertodd&diff=37043User:Petertodd2013-04-15T08:35:35Z<p>Petertodd: Update with actual URL to prevent copying</p>
<hr />
<div> <nowiki>-----BEGIN PGP SIGNED MESSAGE-----<br />
Hash: SHA1<br />
<br />
https://en.bitcoin.it/wiki/User:Petertodd is the bitcoin.it wiki page of Peter Todd, AKA retep on bitcointalk<br />
<br />
https://github.com/petertodd<br />
-----BEGIN PGP SIGNATURE-----<br />
Version: GnuPG v1.4.11 (GNU/Linux)<br />
<br />
iQEcBAEBAgAGBQJRa7usAAoJEH+rEUJn5PoE8pUH/jug1qtKIa5uacU2DbgQlrtE<br />
xG1uONAIHrAA2bnMh9b7M19YlFoB1RsdoOQjm9ptg9EfBtNG27gACyNSHqlP9TTu<br />
a7eqk6+55xpuXAbhEUbEWeGfzZ7nRDNN2vzdmKwwSR7e44j1zv20CdMOWlDzGHjP<br />
ETNBUEjiVtqiXBZZQtVI5ViBG5atiQVuiaWQ+4qecH64hrTgi6e9lkT8TgvIPUwL<br />
6SGp9fmygdynAO0TABxR4uYQxDupqbGCiex726AFbhDMpHtszTovnFyvndE7wRtB<br />
yuTY47FaaO6U274CxLMO3J+S2am013TOreiFWs/k9/k9UtoFw9xFLMriSX6afYk=<br />
=qC0E<br />
-----END PGP SIGNATURE-----<br />
</nowiki></div>Petertoddhttps://en.bitcoin.it/w/index.php?title=Funding_network_security&diff=37005Funding network security2013-04-14T21:53:43Z<p>Petertodd: Merge content with 'original proposal' link</p>
<hr />
<div>If you have followed a link to this page from reddit or elsewhere discussing Mike Hearn's assurance contracts proposal to fund network security, please see [https://bitcointalk.org/index.php?topic=157141.msg1665332#msg1665332|the discussion on bitcointalk] for the original document. Below is a general discussion of how network security is funded now and could be in the future, including Mike's proposal.<br />
<br />
<hr/><br />
<br />
What Bitcoin provides is a means to determine what is the consensus version<br />
of the transaction history, with the consensus determined by what a majority of<br />
hashing power applied to the proof of work problem by miners accepts as the<br />
true history. Since those who own Bitcoins, and who have access to hashing<br />
power, are not necessarily the same group there needs to be a mechanism for the<br />
former to fund the latter. The risk is that mechanism failing, and the majority<br />
of hashing power acting in a way that is against the wishes of the majority of<br />
economic interests.<br />
<br />
An attacker with a majority of hashing power can either publish blocks they<br />
mine as they mine them, or withhold them. The former simply makes it impossible<br />
to get transactions confirmed that the attacker does not wish to be confirmed.<br />
The latter however can be used to rewrite the blockchain after the fact,<br />
causing transactions that appeared to be confirmed to become unconfirmed and<br />
vulnerable to reversal. In addition the attacker can exploit [[Transaction Malleability]] to make it impossible for those transactions to ever be included<br />
in the blockchain again.<br />
<br />
The hashing power majority does not need to constitute a single individual or<br />
coherent group. For instance the economic majority may see [[fungibility]] as<br />
important, and thus want to ensure transaction outputs can not be blacklisted<ref>[https://bitcointalk.org/index.php?topic=157130.0 Decentralised crime fighting using private set intersection protocols]</ref> to prevent transactions spending them from being confirmed,<br />
even if those outputs are known to be involved with illegal activity such as theft or fraud.<br />
However the actions of mining pools are usually public knowledge; which blocks<br />
they mine is usually published on the pool website. If mining a transaction<br />
output known to be involved in illegal activity is made illegal, mining pools<br />
may independently seek out sources of information on transaction outputs known<br />
to be involved in illegal activity, and prohibit transactions spending those<br />
outputs from the blocks they mine, as well as delibrately trying to mine blocks<br />
that would [[Orphan Block|orphan blocks]] with such transactions.<br />
<br />
Similarly it could be made illegal to mine a transaction if the identity of the<br />
person making the transaction is not known, in conjunction with ways for<br />
transactions to make that identity public. Again, even if the economic majority<br />
would prefer to be able to make anonymous transactions, the hashing power<br />
majority may not want to take that risk.<br />
<br />
Conversely the opposite may be true in either example; what "security" is may not always be obvious or easily agreed upon.<br />
<br />
== Inflation Subsidy ==<br />
<br />
Currently each block [[Controlled_Currency_Supply|creates 25 BTC]] as the block<br />
reward; as of April 2013 that inflates the currency supply by about 11% per<br />
year, in effect transferring 11% of the value of all the Bitcoins in existence<br />
to miners to pay for the security they provide. However, every four years the<br />
block reward is decreased by half, thus halving the overall inflation subsidy<br />
that pays miners.<br />
<br />
The inflation subsidy pays miners directly from Bitcoin as a whole; in effect<br />
everyone holding Bitcoins is paying for security directly. However at some<br />
point it will become small enough that Bitcoin could be attacked by someone<br />
with very little resources. In addition a miner can still collect the inflation<br />
subsidy without including any transactions at all in the blocks they mine, an activity that can be seen as an attack.<ref>[https://bitcointalk.org/index.php?topic=69423.0 Miners that refuse to include transactions are becoming a problem]</ref><br />
<br />
It is predicted that the inflation subsidy will reach less than 1% of the<br />
Bitcoin nominal market cap sometime in 2033. However that figure is subject to<br />
the amount of [[lost coins]] from the early days of Bitcoin; it is unknown what<br />
the market cap of coins with owners able to spend them actually is or will be.<br />
<br />
== Transaction Fees ==<br />
<br />
Transactions may include [[transaction_fees|fees]] which are given to the miner<br />
who included the transaction in a block. These fees can range from 0% to 100%<br />
of the transaction inputs technically speaking, although what is economically<br />
practical is a subset of that.<br />
<br />
Fees can align the economic interests of Bitcoin users with the interests of<br />
miners. For instance in the above example of anonymous transactions fees can<br />
encourage miners to mine anonymous transactions regardless of the legal risk,<br />
or to take (possibly expensive) measures to reduce that risk.<br />
<br />
=== The Blocksize Limit ===<br />
<br />
Currently blocks are limited to 1MB in size, and further limited by "gentlemans<br />
agreement" in the form of a 500KB default maximum. While miners can choose to<br />
mine blocks exceeding the 500KB limit, the 1MB limit is fixed and any block<br />
larger than it is invalid; block space is a scarce resource. Provided that the<br />
demand for transactions is greater than about [[Maximum transaction rate|seven<br />
per second]] we can expect transaction fees to be greater than the marginal<br />
costs required to accept a transaction, thus creating a profit that can be used<br />
to fund the operation of hashing power.<br />
<br />
=== Off-chain Transactions ===<br />
<br />
If making a transaction becomes too expensive it can become worthwhile to use<br />
an off-chain payment system to move the funds instead, either one denominated<br />
in Bitcoins, or in a different currency entirely; the availability of off-chain<br />
transactions limits the maximum fees that miners can charge, in turn limiting the value of transactions as a way to fund security.<br />
<br />
== Alternatives ==<br />
<br />
If transaction fees and the inflation subsidy do not pay for adequate security<br />
alternatives exist. In particular users who own Bitcoins, yet do not perform<br />
transactions, possibly because they are holding onto their Bitcoins as an<br />
investment and/or use off-chain transactions, only pay for security through the<br />
inflation subsidy.<br />
<br />
In addition one approach to the [[scalability|scalability problem]] posed by<br />
the current 1MB blocksize limit is to remove or increase that limit. Without<br />
the blocksize limit it is expected that transaction fees will fall to the<br />
[[marginal costs of a transaction]], which means that fees will not pay for any<br />
security at all.<br />
<br />
=== Individual ===<br />
<br />
As individuals Bitcoin owners can fund network security in a variety of ways,<br />
including artifical fee-paying transactions, paying abnormally high fees,<br />
donating directly to known miners, and operating their own mining equipment.<br />
The latter two methods have the advantage that the donator has control over the<br />
policy followed by the miner being funded.<br />
<br />
However mining is a public good: any individual can also simply hope that<br />
others will fund security for them, also known as the<br />
[http://en.wikipedia.org/wiki/Free_rider_problem free rider problem].<br />
<br />
=== Assurance Contracts ===<br />
<br />
An assurance contract, also known as a provision point mechanism, is a game<br />
theoretic mechanism and a financial technology that facilitates the voluntary<br />
creation of public goods and club goods in the face of the free rider<br />
problem.<ref>http://en.wikipedia.org/wiki/Assurance_contract</ref><br />
<br />
The free rider problem is that there may be actions that would benefit a large<br />
group of people, but once the action is taken, there is no way to exclude those<br />
who did not pay for the action from the benefits. In Bitcoin the problem is<br />
that mining is costly and benefits everyone who owns Bitcoins and/or performs<br />
transactions. A mining assurance contract needs to be constructed in such a way<br />
that participants agree that if some large amount of funds are commited, those<br />
funds will go to mining in some way, with the amount set to be large enough for<br />
a sufficiently high percentage of the economic activity of Bitcoin must have<br />
participated to avoid the free rider problem.<br />
<br />
Bitcoin already supports assurance contracts as a transaction<br />
type<ref>[[Contracts#Example_3:_Assurance_contracts]]</ref> - for a<br />
mining assurance contract the transaction output would be set to either an<br />
[[Script#Anyone-Can-Spend_Outputs|anyone can spend]] output, or an address owned<br />
by a specific miner. However as-is they have a serious problem: a miner can<br />
always collect the funds pledged to date by simply adding a sufficient amount<br />
of their own funds to the outstanding contract, and mining that transaction<br />
themselves, thus turning the contract into a simple<br />
donation.<ref>[https://bitcointalk.org/index.php?topic=157141.msg1821770#msg1821770]</ref><br />
(modulo the small chance of the block being orphaned; if the chance is large, the assurance contract is not encouraging orderly mining) The problem can be mitigated somewhat by forcing donators to reveal their identity in a provable way, but then high participation is difficult to achieve.<br />
<br />
With [[nLockTime]] a transaction can be created where the miner who will<br />
actually collect it is unknown in advance. As the deadline approaches, if the<br />
contract is not fully funded, participants double-spend their pledged<br />
transaction outputs to invalidate the contract. However this mechanism has the<br />
problem that anyone can make the contract fail, even if it is fully funded.<br />
That problem can be solved if Bitcoin's scripting language is extended to allow<br />
for transaction outputs that can only be spent by transactions following<br />
certain forms - the outputs would be locked to the contract until some time<br />
after the contract<br />
expires.<ref>[https://bitcointalk.org/index.php?topic=157141.msg1822138#msg1822138]</ref><br />
<br />
== References ==<br />
<references/><br />
* [https://bitcointalk.org/index.php?topic=157141.0 Bitcointalk thread]<br />
[[Category:Technical]]</div>Petertoddhttps://en.bitcoin.it/w/index.php?title=Funding_network_security&diff=36986Funding network security2013-04-14T12:09:38Z<p>Petertodd: /* Inflation Subsidy */ wording</p>
<hr />
<div>What Bitcoin provides is a means to determine what is the consensus version<br />
of the transaction history, with the consensus determined by what a majority of<br />
hashing power applied to the proof of work problem by miners accepts as the<br />
true history. Since those who own Bitcoins, and who have access to hashing<br />
power, are not necessarily the same group there needs to be a mechanism for the<br />
former to fund the latter. The risk is that mechanism failing, and the majority<br />
of hashing power acting in a way that is against the wishes of the majority of<br />
economic interests.<br />
<br />
An attacker with a majority of hashing power can either publish blocks they<br />
mine as they mine them, or withhold them. The former simply makes it impossible<br />
to get transactions confirmed that the attacker does not wish to be confirmed.<br />
The latter however can be used to rewrite the blockchain after the fact,<br />
causing transactions that appeared to be confirmed to become unconfirmed and<br />
vulnerable to reversal. In addition the attacker can exploit [[Transaction Malleability]] to make it impossible for those transactions to ever be included<br />
in the blockchain again.<br />
<br />
The hashing power majority does not need to constitute a single individual or<br />
coherent group. For instance the economic majority may see [[fungibility]] as<br />
important, and thus want to ensure transaction outputs can not be blacklisted<ref>[https://bitcointalk.org/index.php?topic=157130.0 Decentralised crime fighting using private set intersection protocols]</ref> to prevent transactions spending them from being confirmed,<br />
even if those outputs are known to be involved with illegal activity such as theft or fraud.<br />
However the actions of mining pools are usually public knowledge; which blocks<br />
they mine is usually published on the pool website. If mining a transaction<br />
output known to be involved in illegal activity is made illegal, mining pools<br />
may independently seek out sources of information on transaction outputs known<br />
to be involved in illegal activity, and prohibit transactions spending those<br />
outputs from the blocks they mine, as well as delibrately trying to mine blocks<br />
that would [[Orphan Block|orphan blocks]] with such transactions.<br />
<br />
Similarly it could be made illegal to mine a transaction if the identity of the<br />
person making the transaction is not known, in conjunction with ways for<br />
transactions to make that identity public. Again, even if the economic majority<br />
would prefer to be able to make anonymous transactions, the hashing power<br />
majority may not want to take that risk.<br />
<br />
Conversely the opposite may be true in either example; what "security" is may not always be obvious or easily agreed upon.<br />
<br />
== Inflation Subsidy ==<br />
<br />
Currently each block [[Controlled_Currency_Supply|creates 25 BTC]] as the block<br />
reward; as of April 2013 that inflates the currency supply by about 11% per<br />
year, in effect transferring 11% of the value of all the Bitcoins in existence<br />
to miners to pay for the security they provide. However, every four years the<br />
block reward is decreased by half, thus halving the overall inflation subsidy<br />
that pays miners.<br />
<br />
The inflation subsidy pays miners directly from Bitcoin as a whole; in effect<br />
everyone holding Bitcoins is paying for security directly. However at some<br />
point it will become small enough that Bitcoin could be attacked by someone<br />
with very little resources. In addition a miner can still collect the inflation<br />
subsidy without including any transactions at all in the blocks they mine, an activity that can be seen as an attack.<ref>[https://bitcointalk.org/index.php?topic=69423.0 Miners that refuse to include transactions are becoming a problem]</ref><br />
<br />
It is predicted that the inflation subsidy will reach less than 1% of the<br />
Bitcoin nominal market cap sometime in 2033. However that figure is subject to<br />
the amount of [[lost coins]] from the early days of Bitcoin; it is unknown what<br />
the market cap of coins with owners able to spend them actually is or will be.<br />
<br />
== Transaction Fees ==<br />
<br />
Transactions may include [[transaction_fees|fees]] which are given to the miner<br />
who included the transaction in a block. These fees can range from 0% to 100%<br />
of the transaction inputs technically speaking, although what is economically<br />
practical is a subset of that.<br />
<br />
Fees can align the economic interests of Bitcoin users with the interests of<br />
miners. For instance in the above example of anonymous transactions fees can<br />
encourage miners to mine anonymous transactions regardless of the legal risk,<br />
or to take (possibly expensive) measures to reduce that risk.<br />
<br />
=== The Blocksize Limit ===<br />
<br />
Currently blocks are limited to 1MB in size, and further limited by "gentlemans<br />
agreement" in the form of a 500KB default maximum. While miners can choose to<br />
mine blocks exceeding the 500KB limit, the 1MB limit is fixed and any block<br />
larger than it is invalid; block space is a scarce resource. Provided that the<br />
demand for transactions is greater than about [[Maximum transaction rate|seven<br />
per second]] we can expect transaction fees to be greater than the marginal<br />
costs required to accept a transaction, thus creating a profit that can be used<br />
to fund the operation of hashing power.<br />
<br />
=== Off-chain Transactions ===<br />
<br />
If making a transaction becomes too expensive it can become worthwhile to use<br />
an off-chain payment system to move the funds instead, either one denominated<br />
in Bitcoins, or in a different currency entirely; the availability of off-chain<br />
transactions limits the maximum fees that miners can charge, in turn limiting the value of transactions as a way to fund security.<br />
<br />
== Alternatives ==<br />
<br />
If transaction fees and the inflation subsidy do not pay for adequate security<br />
alternatives exist. In particular users who own Bitcoins, yet do not perform<br />
transactions, possibly because they are holding onto their Bitcoins as an<br />
investment and/or use off-chain transactions, only pay for security through the<br />
inflation subsidy.<br />
<br />
In addition one approach to the [[scalability|scalability problem]] posed by<br />
the current 1MB blocksize limit is to remove or increase that limit. Without<br />
the blocksize limit it is expected that transaction fees will fall to the<br />
[[marginal costs of a transaction]], which means that fees will not pay for any<br />
security at all.<br />
<br />
=== Individual ===<br />
<br />
As individuals Bitcoin owners can fund network security in a variety of ways,<br />
including artifical fee-paying transactions, paying abnormally high fees,<br />
donating directly to known miners, and operating their own mining equipment.<br />
The latter two methods have the advantage that the donator has control over the<br />
policy followed by the miner being funded.<br />
<br />
However mining is a public good: any individual can also simply hope that<br />
others will fund security for them, also known as the<br />
[http://en.wikipedia.org/wiki/Free_rider_problem free rider problem].<br />
<br />
=== Assurance Contracts ===<br />
<br />
An assurance contract, also known as a provision point mechanism, is a game<br />
theoretic mechanism and a financial technology that facilitates the voluntary<br />
creation of public goods and club goods in the face of the free rider<br />
problem.<ref>http://en.wikipedia.org/wiki/Assurance_contract</ref><br />
<br />
The free rider problem is that there may be actions that would benefit a large<br />
group of people, but once the action is taken, there is no way to exclude those<br />
who did not pay for the action from the benefits. In Bitcoin the problem is<br />
that mining is costly and benefits everyone who owns Bitcoins and/or performs<br />
transactions. A mining assurance contract needs to be constructed in such a way<br />
that participants agree that if some large amount of funds are commited, those<br />
funds will go to mining in some way, with the amount set to be large enough for<br />
a sufficiently high percentage of the economic activity of Bitcoin must have<br />
participated to avoid the free rider problem.<br />
<br />
Bitcoin already supports assurance contracts as a transaction<br />
type<ref>[[Contracts#Example_3:_Assurance_contracts]]</ref> - for a<br />
mining assurance contract the transaction output would be set to either an<br />
[[Script#Anyone-Can-Spend_Outputs|anyone can spend]] output, or an address owned<br />
by a specific miner. However as-is they have a serious problem: a miner can<br />
always collect the funds pledged to date by simply adding a sufficient amount<br />
of their own funds to the outstanding contract, and mining that transaction<br />
themselves, thus turning the contract into a simple<br />
donation.<ref>[https://bitcointalk.org/index.php?topic=157141.msg1821770#msg1821770]</ref><br />
(modulo the small chance of the block being orphaned; if the chance is large, the assurance contract is not encouraging orderly mining) The problem can be mitigated somewhat by forcing donators to reveal their identity in a provable way, but then high participation is difficult to achieve.<br />
<br />
With [[nLockTime]] a transaction can be created where the miner who will<br />
actually collect it is unknown in advance. As the deadline approaches, if the<br />
contract is not fully funded, participants double-spend their pledged<br />
transaction outputs to invalidate the contract. However this mechanism has the<br />
problem that anyone can make the contract fail, even if it is fully funded.<br />
That problem can be solved if Bitcoin's scripting language is extended to allow<br />
for transaction outputs that can only be spent by transactions following<br />
certain forms - the outputs would be locked to the contract until some time<br />
after the contract<br />
expires.<ref>[https://bitcointalk.org/index.php?topic=157141.msg1822138#msg1822138]</ref><br />
<br />
== References ==<br />
<references/><br />
* [https://bitcointalk.org/index.php?topic=157141.0 Bitcointalk thread]<br />
[[Category:Technical]]</div>Petertoddhttps://en.bitcoin.it/w/index.php?title=Funding_network_security&diff=36985Funding network security2013-04-14T12:02:39Z<p>Petertodd: Mike: The wiki needs a general page on funding network security; create a specific page for your specific assurance contract stuff if you want. Mike (talk)</p>
<hr />
<div>What Bitcoin provides is a means to determine what is the consensus version<br />
of the transaction history, with the consensus determined by what a majority of<br />
hashing power applied to the proof of work problem by miners accepts as the<br />
true history. Since those who own Bitcoins, and who have access to hashing<br />
power, are not necessarily the same group there needs to be a mechanism for the<br />
former to fund the latter. The risk is that mechanism failing, and the majority<br />
of hashing power acting in a way that is against the wishes of the majority of<br />
economic interests.<br />
<br />
An attacker with a majority of hashing power can either publish blocks they<br />
mine as they mine them, or withhold them. The former simply makes it impossible<br />
to get transactions confirmed that the attacker does not wish to be confirmed.<br />
The latter however can be used to rewrite the blockchain after the fact,<br />
causing transactions that appeared to be confirmed to become unconfirmed and<br />
vulnerable to reversal. In addition the attacker can exploit [[Transaction Malleability]] to make it impossible for those transactions to ever be included<br />
in the blockchain again.<br />
<br />
The hashing power majority does not need to constitute a single individual or<br />
coherent group. For instance the economic majority may see [[fungibility]] as<br />
important, and thus want to ensure transaction outputs can not be blacklisted<ref>[https://bitcointalk.org/index.php?topic=157130.0 Decentralised crime fighting using private set intersection protocols]</ref> to prevent transactions spending them from being confirmed,<br />
even if those outputs are known to be involved with illegal activity such as theft or fraud.<br />
However the actions of mining pools are usually public knowledge; which blocks<br />
they mine is usually published on the pool website. If mining a transaction<br />
output known to be involved in illegal activity is made illegal, mining pools<br />
may independently seek out sources of information on transaction outputs known<br />
to be involved in illegal activity, and prohibit transactions spending those<br />
outputs from the blocks they mine, as well as delibrately trying to mine blocks<br />
that would [[Orphan Block|orphan blocks]] with such transactions.<br />
<br />
Similarly it could be made illegal to mine a transaction if the identity of the<br />
person making the transaction is not known, in conjunction with ways for<br />
transactions to make that identity public. Again, even if the economic majority<br />
would prefer to be able to make anonymous transactions, the hashing power<br />
majority may not want to take that risk.<br />
<br />
Conversely the opposite may be true in either example; what "security" is may not always be obvious or easily agreed upon.<br />
<br />
== Inflation Subsidy ==<br />
<br />
Currently each block [[Controlled_Currency_Supply|creates 25 BTC]] as the block<br />
reward; as of April 2013 that inflates the currency supply by about 11% per<br />
year, in effect transferring 11% of the value of all the Bitcoins in existence<br />
to miners to pay for the security they provide. However, every four years the<br />
block reward is decreased by half, thus halving the overall inflation subsidy<br />
that pays miners.<br />
<br />
The inflation subsidy pays miners directly from Bitcoin as a whole; in effect<br />
everyone holding Bitcoins is paying for security directly. However at some<br />
point it will become small enough that Bitcoin could be attacked by someone<br />
with very little resources. In addition a miner can still collect the inflation<br />
subsidy without including any transactions at all in the blocks they mine, an activity that can be seen as an attack.<ref>[https://bitcointalk.org/index.php?topic=69423.0 Miners that refuse to include transactions are becoming a problem]</ref><br />
<br />
It is predicted that the inflation subsidy will reach less than 1% of the<br />
Bitcoin nominal market cap sometime in 2033. However that figure is subject to<br />
the amount of [[lost coins]] from the early days of Bitcoin; it is unknown what<br />
the market cap of coins with owners able to spend them actually is.<br />
<br />
== Transaction Fees ==<br />
<br />
Transactions may include [[transaction_fees|fees]] which are given to the miner<br />
who included the transaction in a block. These fees can range from 0% to 100%<br />
of the transaction inputs technically speaking, although what is economically<br />
practical is a subset of that.<br />
<br />
Fees can align the economic interests of Bitcoin users with the interests of<br />
miners. For instance in the above example of anonymous transactions fees can<br />
encourage miners to mine anonymous transactions regardless of the legal risk,<br />
or to take (possibly expensive) measures to reduce that risk.<br />
<br />
=== The Blocksize Limit ===<br />
<br />
Currently blocks are limited to 1MB in size, and further limited by "gentlemans<br />
agreement" in the form of a 500KB default maximum. While miners can choose to<br />
mine blocks exceeding the 500KB limit, the 1MB limit is fixed and any block<br />
larger than it is invalid; block space is a scarce resource. Provided that the<br />
demand for transactions is greater than about [[Maximum transaction rate|seven<br />
per second]] we can expect transaction fees to be greater than the marginal<br />
costs required to accept a transaction, thus creating a profit that can be used<br />
to fund the operation of hashing power.<br />
<br />
=== Off-chain Transactions ===<br />
<br />
If making a transaction becomes too expensive it can become worthwhile to use<br />
an off-chain payment system to move the funds instead, either one denominated<br />
in Bitcoins, or in a different currency entirely; the availability of off-chain<br />
transactions limits the maximum fees that miners can charge, in turn limiting the value of transactions as a way to fund security.<br />
<br />
== Alternatives ==<br />
<br />
If transaction fees and the inflation subsidy do not pay for adequate security<br />
alternatives exist. In particular users who own Bitcoins, yet do not perform<br />
transactions, possibly because they are holding onto their Bitcoins as an<br />
investment and/or use off-chain transactions, only pay for security through the<br />
inflation subsidy.<br />
<br />
In addition one approach to the [[scalability|scalability problem]] posed by<br />
the current 1MB blocksize limit is to remove or increase that limit. Without<br />
the blocksize limit it is expected that transaction fees will fall to the<br />
[[marginal costs of a transaction]], which means that fees will not pay for any<br />
security at all.<br />
<br />
=== Individual ===<br />
<br />
As individuals Bitcoin owners can fund network security in a variety of ways,<br />
including artifical fee-paying transactions, paying abnormally high fees,<br />
donating directly to known miners, and operating their own mining equipment.<br />
The latter two methods have the advantage that the donator has control over the<br />
policy followed by the miner being funded.<br />
<br />
However mining is a public good: any individual can also simply hope that<br />
others will fund security for them, also known as the<br />
[http://en.wikipedia.org/wiki/Free_rider_problem free rider problem].<br />
<br />
=== Assurance Contracts ===<br />
<br />
An assurance contract, also known as a provision point mechanism, is a game<br />
theoretic mechanism and a financial technology that facilitates the voluntary<br />
creation of public goods and club goods in the face of the free rider<br />
problem.<ref>http://en.wikipedia.org/wiki/Assurance_contract</ref><br />
<br />
The free rider problem is that there may be actions that would benefit a large<br />
group of people, but once the action is taken, there is no way to exclude those<br />
who did not pay for the action from the benefits. In Bitcoin the problem is<br />
that mining is costly and benefits everyone who owns Bitcoins and/or performs<br />
transactions. A mining assurance contract needs to be constructed in such a way<br />
that participants agree that if some large amount of funds are commited, those<br />
funds will go to mining in some way, with the amount set to be large enough for<br />
a sufficiently high percentage of the economic activity of Bitcoin must have<br />
participated to avoid the free rider problem.<br />
<br />
Bitcoin already supports assurance contracts as a transaction<br />
type<ref>[[Contracts#Example_3:_Assurance_contracts]]</ref> - for a<br />
mining assurance contract the transaction output would be set to either an<br />
[[Script#Anyone-Can-Spend_Outputs|anyone can spend]] output, or an address owned<br />
by a specific miner. However as-is they have a serious problem: a miner can<br />
always collect the funds pledged to date by simply adding a sufficient amount<br />
of their own funds to the outstanding contract, and mining that transaction<br />
themselves, thus turning the contract into a simple<br />
donation.<ref>[https://bitcointalk.org/index.php?topic=157141.msg1821770#msg1821770]</ref><br />
(modulo the small chance of the block being orphaned; if the chance is large, the assurance contract is not encouraging orderly mining) The problem can be mitigated somewhat by forcing donators to reveal their identity in a provable way, but then high participation is difficult to achieve.<br />
<br />
With [[nLockTime]] a transaction can be created where the miner who will<br />
actually collect it is unknown in advance. As the deadline approaches, if the<br />
contract is not fully funded, participants double-spend their pledged<br />
transaction outputs to invalidate the contract. However this mechanism has the<br />
problem that anyone can make the contract fail, even if it is fully funded.<br />
That problem can be solved if Bitcoin's scripting language is extended to allow<br />
for transaction outputs that can only be spent by transactions following<br />
certain forms - the outputs would be locked to the contract until some time<br />
after the contract<br />
expires.<ref>[https://bitcointalk.org/index.php?topic=157141.msg1822138#msg1822138]</ref><br />
<br />
== References ==<br />
<references/><br />
* [https://bitcointalk.org/index.php?topic=157141.0 Bitcointalk thread]<br />
[[Category:Technical]]</div>Petertoddhttps://en.bitcoin.it/w/index.php?title=Maximum_transaction_rate&diff=36983Maximum transaction rate2013-04-14T11:13:16Z<p>Petertodd: /* Trust-free Combining */</p>
<hr />
<div>The maximum transaction rate is the block size limit divided by the average transaction size. The block size limit is well known, 1MB, however the average transaction size isn't. Here we'll look at what influences that size.<br />
<br />
The minimum sized transaction type<ref name="mintxsize">Even smaller transactions can be made by using empty scriptPubKeys, however such transactions are not secure because anyone can spend them.</ref> is the [[Script#Standard_Generation_Transaction|OP_CHECKSIG transaction]]:<br />
<br />
scriptPubKey: <33 byte compressed pubKey> OP_CHECKSIG<br />
scriptSig: <72 byte signature><br />
<br />
Each transaction input requires at least 41 bytes for the previous transaction reference and other headers and each transaction output requires an additional 9 bytes of headers. Finally every transaction has a header at least 10 bytes long. Added up we get 166 bytes for the minimum-sized Bitcoin transaction. For 1MB (1,000,000 byte) blocks this implies a theoretical maximum rate of 10tx/s.<br />
<br />
However [[Change|change]] complicates the situation. It isn't always possible for a client to find a transaction input of the size required. Thus client software will included additional outputs to themselves for the change, and similarly they will include additional inputs to collect change outputs together when no one output is large enough.<br />
<br />
Users with large wallets, in particular [[eWallets]] such as Instawallet or large exchanges like Mt. Gox are most likely to be able to find transaction outputs of a suitable size for any given payment. It's conceivable that if transaction fees are high enough in the future users who trust each other may get together to use each others wallets to make payments as a way to avoid transaction fees, with the balances settled periodically by some other means.<br />
<br />
== Trust-free Combining ==<br />
<br />
Users can also combine their transactions to make them slightly smaller, and possibly improve privacy. A transaction is invalid until every transaction input is signed for, thus multiple users can create a joint transaction with no risk of their funds being stolen. This reduces average transaction size by 10 bytes, the size of the per-transaction header. Using this technique aggressively results in 156 byte average transactions, or 10.7tx/s.<br />
<br />
== Lower-bound transaction rate ==<br />
<br />
A reasonable, conservative, assumption is to assume that every transaction requires two outputs, including change, and two inputs, consuming change. Assuming that trust-free combining is not used gives us 322 byte transactions, or 5.2tx/s.<br />
<br />
Actual real-world rates will likely be somewhere between those numbers, although equally rates may be less as well if multi-signature transactions are become popular; the figure 7tx/s is commonly quoted as a 'ball-park' approximation in discussions of the [[Scalability|blocksize limit]].<br />
<br />
== Footnotes ==<br />
<references/></div>Petertoddhttps://en.bitcoin.it/w/index.php?title=Maximum_transaction_rate&diff=36982Maximum transaction rate2013-04-14T11:12:52Z<p>Petertodd: /* Lower-bound transaction rate */</p>
<hr />
<div>The maximum transaction rate is the block size limit divided by the average transaction size. The block size limit is well known, 1MB, however the average transaction size isn't. Here we'll look at what influences that size.<br />
<br />
The minimum sized transaction type<ref name="mintxsize">Even smaller transactions can be made by using empty scriptPubKeys, however such transactions are not secure because anyone can spend them.</ref> is the [[Script#Standard_Generation_Transaction|OP_CHECKSIG transaction]]:<br />
<br />
scriptPubKey: <33 byte compressed pubKey> OP_CHECKSIG<br />
scriptSig: <72 byte signature><br />
<br />
Each transaction input requires at least 41 bytes for the previous transaction reference and other headers and each transaction output requires an additional 9 bytes of headers. Finally every transaction has a header at least 10 bytes long. Added up we get 166 bytes for the minimum-sized Bitcoin transaction. For 1MB (1,000,000 byte) blocks this implies a theoretical maximum rate of 10tx/s.<br />
<br />
However [[Change|change]] complicates the situation. It isn't always possible for a client to find a transaction input of the size required. Thus client software will included additional outputs to themselves for the change, and similarly they will include additional inputs to collect change outputs together when no one output is large enough.<br />
<br />
Users with large wallets, in particular [[eWallets]] such as Instawallet or large exchanges like Mt. Gox are most likely to be able to find transaction outputs of a suitable size for any given payment. It's conceivable that if transaction fees are high enough in the future users who trust each other may get together to use each others wallets to make payments as a way to avoid transaction fees, with the balances settled periodically by some other means.<br />
<br />
== Trust-free Combining ==<br />
<br />
Users can also combine their transactions to make them slightly smaller, and possibly improve privacy. A transaction is invalid until every transaction input is signed for, thus multiple users can create a joint transaction with no risk of their funds being stolen. This reduces average transaction size by 10 bytes; the size of the per-transaction header. Using this technique aggressively results in 156 byte average transactions, or 10.7tx/s.<br />
<br />
== Lower-bound transaction rate ==<br />
<br />
A reasonable, conservative, assumption is to assume that every transaction requires two outputs, including change, and two inputs, consuming change. Assuming that trust-free combining is not used gives us 322 byte transactions, or 5.2tx/s.<br />
<br />
Actual real-world rates will likely be somewhere between those numbers, although equally rates may be less as well if multi-signature transactions are become popular; the figure 7tx/s is commonly quoted as a 'ball-park' approximation in discussions of the [[Scalability|blocksize limit]].<br />
<br />
== Footnotes ==<br />
<references/></div>Petertoddhttps://en.bitcoin.it/w/index.php?title=Maximum_transaction_rate&diff=36981Maximum transaction rate2013-04-14T11:11:55Z<p>Petertodd: Add ball-park figure</p>
<hr />
<div>The maximum transaction rate is the block size limit divided by the average transaction size. The block size limit is well known, 1MB, however the average transaction size isn't. Here we'll look at what influences that size.<br />
<br />
The minimum sized transaction type<ref name="mintxsize">Even smaller transactions can be made by using empty scriptPubKeys, however such transactions are not secure because anyone can spend them.</ref> is the [[Script#Standard_Generation_Transaction|OP_CHECKSIG transaction]]:<br />
<br />
scriptPubKey: <33 byte compressed pubKey> OP_CHECKSIG<br />
scriptSig: <72 byte signature><br />
<br />
Each transaction input requires at least 41 bytes for the previous transaction reference and other headers and each transaction output requires an additional 9 bytes of headers. Finally every transaction has a header at least 10 bytes long. Added up we get 166 bytes for the minimum-sized Bitcoin transaction. For 1MB (1,000,000 byte) blocks this implies a theoretical maximum rate of 10tx/s.<br />
<br />
However [[Change|change]] complicates the situation. It isn't always possible for a client to find a transaction input of the size required. Thus client software will included additional outputs to themselves for the change, and similarly they will include additional inputs to collect change outputs together when no one output is large enough.<br />
<br />
Users with large wallets, in particular [[eWallets]] such as Instawallet or large exchanges like Mt. Gox are most likely to be able to find transaction outputs of a suitable size for any given payment. It's conceivable that if transaction fees are high enough in the future users who trust each other may get together to use each others wallets to make payments as a way to avoid transaction fees, with the balances settled periodically by some other means.<br />
<br />
== Trust-free Combining ==<br />
<br />
Users can also combine their transactions to make them slightly smaller, and possibly improve privacy. A transaction is invalid until every transaction input is signed for, thus multiple users can create a joint transaction with no risk of their funds being stolen. This reduces average transaction size by 10 bytes; the size of the per-transaction header. Using this technique aggressively results in 156 byte average transactions, or 10.7tx/s.<br />
<br />
== Lower-bound transaction rate ==<br />
<br />
A reasonable, conservative, assumption is to assume that every transaction requires two outputs, including change, and two inputs, consuming change. Assuming that trust-free combining is not used gives us 322 byte transactions, or 5.2tx/s.<br />
<br />
Actual real-world rates will likely be somewhere between those numbers, although equally rates may be less as well if multi-signature transactions are become popular; the figure 7tx/s is commonly quoted as a 'ball-park' approximation in discussions of the [[blocksize limit]].<br />
<br />
== Footnotes ==<br />
<references/></div>Petertoddhttps://en.bitcoin.it/w/index.php?title=Funding_network_security&diff=36980Funding network security2013-04-14T10:59:28Z<p>Petertodd: /* Inflation Subsidy */ Add ref</p>
<hr />
<div>What Bitcoin provides is a means to determine what is the consensus version<br />
of the transaction history, with the consensus determined by what a majority of<br />
hashing power applied to the proof of work problem by miners accepts as the<br />
true history. Since those who own Bitcoins, and who have access to hashing<br />
power, are not necessarily the same group there needs to be a mechanism for the<br />
former to fund the latter. The risk is that mechanism failing, and the majority<br />
of hashing power acting in a way that is against the wishes of the majority of<br />
economic interests.<br />
<br />
An attacker with a majority of hashing power can either publish blocks they<br />
mine as they mine them, or withhold them. The former simply makes it impossible<br />
to get transactions confirmed that the attacker does not wish to be confirmed.<br />
The latter however can be used to rewrite the blockchain after the fact,<br />
causing transactions that appeared to be confirmed to become unconfirmed and<br />
vulnerable to reversal. In addition the attacker can exploit [[Transaction Malleability]] to make it impossible for those transactions to ever be included<br />
in the blockchain again.<br />
<br />
The hashing power majority does not need to constitute a single individual or<br />
coherent group. For instance the economic majority may see [[fungibility]] as<br />
important, and thus want to ensure transaction outputs can not be blacklisted<ref>[https://bitcointalk.org/index.php?topic=157130.0 Decentralised crime fighting using private set intersection protocols]</ref> to prevent transactions spending them from being confirmed,<br />
even if those outputs are known to be involved with illegal activity such as theft or fraud.<br />
However the actions of mining pools are usually public knowledge; which blocks<br />
they mine is usually published on the pool website. If mining a transaction<br />
output known to be involved in illegal activity is made illegal, mining pools<br />
may independently seek out sources of information on transaction outputs known<br />
to be involved in illegal activity, and prohibit transactions spending those<br />
outputs from the blocks they mine, as well as delibrately trying to mine blocks<br />
that would [[Orphan Block|orphan blocks]] with such transactions.<br />
<br />
Similarly it could be made illegal to mine a transaction if the identity of the<br />
person making the transaction is not known, in conjunction with ways for<br />
transactions to make that identity public. Again, even if the economic majority<br />
would prefer to be able to make anonymous transactions, the hashing power<br />
majority may not want to take that risk.<br />
<br />
Conversely the opposite may be true in either example; what "security" is may not always be obvious or easily agreed upon.<br />
<br />
== Inflation Subsidy ==<br />
<br />
Currently each block [[Controlled_Currency_Supply|creates 25 BTC]] as the block<br />
reward; as of April 2013 that inflates the currency supply by about 11% per<br />
year, in effect transferring 11% of the value of all the Bitcoins in existence<br />
to miners to pay for the security they provide. However, every four years the<br />
block reward is decreased by half, thus halving the overall inflation subsidy<br />
that pays miners.<br />
<br />
The inflation subsidy pays miners directly from Bitcoin as a whole; in effect<br />
everyone holding Bitcoins is paying for security directly. However at some<br />
point it will become small enough that Bitcoin could be attacked by someone<br />
with very little resources. In addition a miner can still collect the inflation<br />
subsidy without including any transactions at all in the blocks they mine, an activity that can be seen as an attack.<ref>[https://bitcointalk.org/index.php?topic=69423.0 Miners that refuse to include transactions are becoming a problem]</ref><br />
<br />
It is predicted that the inflation subsidy will reach less than 1% of the<br />
Bitcoin nominal market cap sometime in 2033. However that figure is subject to<br />
the amount of [[lost coins]] from the early days of Bitcoin; it is unknown what<br />
the market cap of coins with owners able to spend them actually is.<br />
<br />
== Transaction Fees ==<br />
<br />
Transactions may include [[transaction_fees|fees]] which are given to the miner<br />
who included the transaction in a block. These fees can range from 0% to 100%<br />
of the transaction inputs technically speaking, although what is economically<br />
practical is a subset of that.<br />
<br />
Fees can align the economic interests of Bitcoin users with the interests of<br />
miners. For instance in the above example of anonymous transactions fees can<br />
encourage miners to mine anonymous transactions regardless of the legal risk,<br />
or to take (possibly expensive) measures to reduce that risk.<br />
<br />
=== The Blocksize Limit ===<br />
<br />
Currently blocks are limited to 1MB in size, and further limited by "gentlemans<br />
agreement" in the form of a 500KB default maximum. While miners can choose to<br />
mine blocks exceeding the 500KB limit, the 1MB limit is fixed and any block<br />
larger than it is invalid; block space is a scarce resource. Provided that the<br />
demand for transactions is greater than about [[Maximum transaction rate|seven<br />
per second]] we can expect transaction fees to be greater than the marginal<br />
costs required to accept a transaction, thus creating a profit that can be used<br />
to fund the operation of hashing power.<br />
<br />
=== Off-chain Transactions ===<br />
<br />
If making a transaction becomes too expensive it can become worthwhile to use<br />
an off-chain payment system to move the funds instead, either one denominated<br />
in Bitcoins, or in a different currency entirely; the availability of off-chain<br />
transactions limits the maximum fees that miners can charge, in turn limiting the value of transactions as a way to fund security.<br />
<br />
== Alternatives ==<br />
<br />
If transaction fees and the inflation subsidy do not pay for adequate security<br />
alternatives exist. In particular users who own Bitcoins, yet do not perform<br />
transactions, possibly because they are holding onto their Bitcoins as an<br />
investment and/or use off-chain transactions, only pay for security through the<br />
inflation subsidy.<br />
<br />
In addition one approach to the [[scalability|scalability problem]] posed by<br />
the current 1MB blocksize limit is to remove or increase that limit. Without<br />
the blocksize limit it is expected that transaction fees will fall to the<br />
[[marginal costs of a transaction]], which means that fees will not pay for any<br />
security at all.<br />
<br />
=== Individual ===<br />
<br />
As individuals Bitcoin owners can fund network security in a variety of ways,<br />
including artifical fee-paying transactions, paying abnormally high fees,<br />
donating directly to known miners, and operating their own mining equipment.<br />
The latter two methods have the advantage that the donator has control over the<br />
policy followed by the miner being funded.<br />
<br />
However mining is a public good: any individual can also simply hope that<br />
others will fund security for them, also known as the<br />
[http://en.wikipedia.org/wiki/Free_rider_problem free rider problem].<br />
<br />
=== Assurance Contracts ===<br />
<br />
An assurance contract, also known as a provision point mechanism, is a game<br />
theoretic mechanism and a financial technology that facilitates the voluntary<br />
creation of public goods and club goods in the face of the free rider<br />
problem.<ref>http://en.wikipedia.org/wiki/Assurance_contract</ref><br />
<br />
The free rider problem is that there may be actions that would benefit a large<br />
group of people, but once the action is taken, there is no way to exclude those<br />
who did not pay for the action from the benefits. In Bitcoin the problem is<br />
that mining is costly and benefits everyone who owns Bitcoins and/or performs<br />
transactions. A mining assurance contract needs to be constructed in such a way<br />
that participants agree that if some large amount of funds are commited, those<br />
funds will go to mining in some way, with the amount set to be large enough for<br />
a sufficiently high percentage of the economic activity of Bitcoin must have<br />
participated to avoid the free rider problem.<br />
<br />
Bitcoin already supports assurance contracts as a transaction<br />
type<ref>[[Contracts#Example_3:_Assurance_contracts]]</ref> - for a<br />
mining assurance contract the transaction output would be set to either an<br />
[[Script#Anyone-Can-Spend_Outputs|anyone can spend]] output, or an address owned<br />
by a specific miner. However as-is they have a serious problem: a miner can<br />
always collect the funds pledged to date by simply adding a sufficient amount<br />
of their own funds to the outstanding contract, and mining that transaction<br />
themselves, thus turning the contract into a simple<br />
donation.<ref>[https://bitcointalk.org/index.php?topic=157141.msg1821770#msg1821770]</ref><br />
(modulo the small chance of the block being orphaned; if the chance is large, the assurance contract is not encouraging orderly mining) The problem can be mitigated somewhat by forcing donators to reveal their identity in a provable way, but then high participation is difficult to achieve.<br />
<br />
With [[nLockTime]] a transaction can be created where the miner who will<br />
actually collect it is unknown in advance. As the deadline approaches, if the<br />
contract is not fully funded, participants double-spend their pledged<br />
transaction outputs to invalidate the contract. However this mechanism has the<br />
problem that anyone can make the contract fail, even if it is fully funded.<br />
That problem can be solved if Bitcoin's scripting language is extended to allow<br />
for transaction outputs that can only be spent by transactions following<br />
certain forms - the outputs would be locked to the contract until some time<br />
after the contract<br />
expires.<ref>[https://bitcointalk.org/index.php?topic=157141.msg1822138#msg1822138]</ref><br />
<br />
== References ==<br />
<references/><br />
* [https://bitcointalk.org/index.php?topic=157141.0 Bitcointalk thread]<br />
[[Category:Technical]]</div>Petertoddhttps://en.bitcoin.it/w/index.php?title=Funding_network_security&diff=36979Funding network security2013-04-14T10:58:00Z<p>Petertodd: Wording</p>
<hr />
<div>What Bitcoin provides is a means to determine what is the consensus version<br />
of the transaction history, with the consensus determined by what a majority of<br />
hashing power applied to the proof of work problem by miners accepts as the<br />
true history. Since those who own Bitcoins, and who have access to hashing<br />
power, are not necessarily the same group there needs to be a mechanism for the<br />
former to fund the latter. The risk is that mechanism failing, and the majority<br />
of hashing power acting in a way that is against the wishes of the majority of<br />
economic interests.<br />
<br />
An attacker with a majority of hashing power can either publish blocks they<br />
mine as they mine them, or withhold them. The former simply makes it impossible<br />
to get transactions confirmed that the attacker does not wish to be confirmed.<br />
The latter however can be used to rewrite the blockchain after the fact,<br />
causing transactions that appeared to be confirmed to become unconfirmed and<br />
vulnerable to reversal. In addition the attacker can exploit [[Transaction Malleability]] to make it impossible for those transactions to ever be included<br />
in the blockchain again.<br />
<br />
The hashing power majority does not need to constitute a single individual or<br />
coherent group. For instance the economic majority may see [[fungibility]] as<br />
important, and thus want to ensure transaction outputs can not be blacklisted<ref>[https://bitcointalk.org/index.php?topic=157130.0 Decentralised crime fighting using private set intersection protocols]</ref> to prevent transactions spending them from being confirmed,<br />
even if those outputs are known to be involved with illegal activity such as theft or fraud.<br />
However the actions of mining pools are usually public knowledge; which blocks<br />
they mine is usually published on the pool website. If mining a transaction<br />
output known to be involved in illegal activity is made illegal, mining pools<br />
may independently seek out sources of information on transaction outputs known<br />
to be involved in illegal activity, and prohibit transactions spending those<br />
outputs from the blocks they mine, as well as delibrately trying to mine blocks<br />
that would [[Orphan Block|orphan blocks]] with such transactions.<br />
<br />
Similarly it could be made illegal to mine a transaction if the identity of the<br />
person making the transaction is not known, in conjunction with ways for<br />
transactions to make that identity public. Again, even if the economic majority<br />
would prefer to be able to make anonymous transactions, the hashing power<br />
majority may not want to take that risk.<br />
<br />
Conversely the opposite may be true in either example; what "security" is may not always be obvious or easily agreed upon.<br />
<br />
== Inflation Subsidy ==<br />
<br />
Currently each block [[Controlled_Currency_Supply|creates 25 BTC]] as the block<br />
reward; as of April 2013 that inflates the currency supply by about 11% per<br />
year, in effect transferring 11% of the value of all the Bitcoins in existence<br />
to miners to pay for the security they provide. However, every four years the<br />
block reward is decreased by half, thus halving the overall inflation subsidy<br />
that pays miners.<br />
<br />
The inflation subsidy pays miners directly from Bitcoin as a whole; in effect<br />
everyone holding Bitcoins is paying for security directly. However at some<br />
point it will become small enough that Bitcoin could be attacked by someone<br />
with very little resources. In addition a miner can still collect the inflation<br />
subsidy without including any transactions at all in the blocks they mine.<br />
<br />
It is predicted that the inflation subsidy will reach less than 1% of the<br />
Bitcoin nominal market cap sometime in 2033. However that figure is subject to<br />
the amount of [[lost coins]] from the early days of Bitcoin; it is unknown what<br />
the market cap of coins with owners able to spend them actually is.<br />
<br />
== Transaction Fees ==<br />
<br />
Transactions may include [[transaction_fees|fees]] which are given to the miner<br />
who included the transaction in a block. These fees can range from 0% to 100%<br />
of the transaction inputs technically speaking, although what is economically<br />
practical is a subset of that.<br />
<br />
Fees can align the economic interests of Bitcoin users with the interests of<br />
miners. For instance in the above example of anonymous transactions fees can<br />
encourage miners to mine anonymous transactions regardless of the legal risk,<br />
or to take (possibly expensive) measures to reduce that risk.<br />
<br />
=== The Blocksize Limit ===<br />
<br />
Currently blocks are limited to 1MB in size, and further limited by "gentlemans<br />
agreement" in the form of a 500KB default maximum. While miners can choose to<br />
mine blocks exceeding the 500KB limit, the 1MB limit is fixed and any block<br />
larger than it is invalid; block space is a scarce resource. Provided that the<br />
demand for transactions is greater than about [[Maximum transaction rate|seven<br />
per second]] we can expect transaction fees to be greater than the marginal<br />
costs required to accept a transaction, thus creating a profit that can be used<br />
to fund the operation of hashing power.<br />
<br />
=== Off-chain Transactions ===<br />
<br />
If making a transaction becomes too expensive it can become worthwhile to use<br />
an off-chain payment system to move the funds instead, either one denominated<br />
in Bitcoins, or in a different currency entirely; the availability of off-chain<br />
transactions limits the maximum fees that miners can charge, in turn limiting the value of transactions as a way to fund security.<br />
<br />
== Alternatives ==<br />
<br />
If transaction fees and the inflation subsidy do not pay for adequate security<br />
alternatives exist. In particular users who own Bitcoins, yet do not perform<br />
transactions, possibly because they are holding onto their Bitcoins as an<br />
investment and/or use off-chain transactions, only pay for security through the<br />
inflation subsidy.<br />
<br />
In addition one approach to the [[scalability|scalability problem]] posed by<br />
the current 1MB blocksize limit is to remove or increase that limit. Without<br />
the blocksize limit it is expected that transaction fees will fall to the<br />
[[marginal costs of a transaction]], which means that fees will not pay for any<br />
security at all.<br />
<br />
=== Individual ===<br />
<br />
As individuals Bitcoin owners can fund network security in a variety of ways,<br />
including artifical fee-paying transactions, paying abnormally high fees,<br />
donating directly to known miners, and operating their own mining equipment.<br />
The latter two methods have the advantage that the donator has control over the<br />
policy followed by the miner being funded.<br />
<br />
However mining is a public good: any individual can also simply hope that<br />
others will fund security for them, also known as the<br />
[http://en.wikipedia.org/wiki/Free_rider_problem free rider problem].<br />
<br />
=== Assurance Contracts ===<br />
<br />
An assurance contract, also known as a provision point mechanism, is a game<br />
theoretic mechanism and a financial technology that facilitates the voluntary<br />
creation of public goods and club goods in the face of the free rider<br />
problem.<ref>http://en.wikipedia.org/wiki/Assurance_contract</ref><br />
<br />
The free rider problem is that there may be actions that would benefit a large<br />
group of people, but once the action is taken, there is no way to exclude those<br />
who did not pay for the action from the benefits. In Bitcoin the problem is<br />
that mining is costly and benefits everyone who owns Bitcoins and/or performs<br />
transactions. A mining assurance contract needs to be constructed in such a way<br />
that participants agree that if some large amount of funds are commited, those<br />
funds will go to mining in some way, with the amount set to be large enough for<br />
a sufficiently high percentage of the economic activity of Bitcoin must have<br />
participated to avoid the free rider problem.<br />
<br />
Bitcoin already supports assurance contracts as a transaction<br />
type<ref>[[Contracts#Example_3:_Assurance_contracts]]</ref> - for a<br />
mining assurance contract the transaction output would be set to either an<br />
[[Script#Anyone-Can-Spend_Outputs|anyone can spend]] output, or an address owned<br />
by a specific miner. However as-is they have a serious problem: a miner can<br />
always collect the funds pledged to date by simply adding a sufficient amount<br />
of their own funds to the outstanding contract, and mining that transaction<br />
themselves, thus turning the contract into a simple<br />
donation.<ref>[https://bitcointalk.org/index.php?topic=157141.msg1821770#msg1821770]</ref><br />
(modulo the small chance of the block being orphaned; if the chance is large, the assurance contract is not encouraging orderly mining) The problem can be mitigated somewhat by forcing donators to reveal their identity in a provable way, but then high participation is difficult to achieve.<br />
<br />
With [[nLockTime]] a transaction can be created where the miner who will<br />
actually collect it is unknown in advance. As the deadline approaches, if the<br />
contract is not fully funded, participants double-spend their pledged<br />
transaction outputs to invalidate the contract. However this mechanism has the<br />
problem that anyone can make the contract fail, even if it is fully funded.<br />
That problem can be solved if Bitcoin's scripting language is extended to allow<br />
for transaction outputs that can only be spent by transactions following<br />
certain forms - the outputs would be locked to the contract until some time<br />
after the contract<br />
expires.<ref>[https://bitcointalk.org/index.php?topic=157141.msg1822138#msg1822138]</ref><br />
<br />
== References ==<br />
<references/><br />
* [https://bitcointalk.org/index.php?topic=157141.0 Bitcointalk thread]<br />
[[Category:Technical]]</div>Petertodd