Bitcoin Wiki - User contributions [en]

Invoice address

2020-05-11T20:36:11Z

Jhfrontz: /* A Bitcoin address is a single-use token */ Asking why "a Bitcoin address is a single-use token".

A '''Bitcoin address''', or simply '''address''', is an identifier of 26-35 alphanumeric characters, beginning with the number <code>1</code>, <code>3</code> or <code>bc1</code> that represents a possible destination for a bitcoin payment.
Addresses can be generated at no cost by any user of Bitcoin.
For example, using [[Bitcoin Core]], one can click "New Address" and be assigned an address.
It is also possible to get a Bitcoin address using an account at an exchange or online wallet service.

There are currently three [[List_of_address_prefixes|address formats]] in use:
# [[Transaction#Pay-to-PubkeyHash|P2PKH]] which begin with the number <code>1</code>, eg: <code>1BvBMSEYstWetqTFn5Au4m4GFg7xJaNVN2</code>.
# [[Pay_to_script_hash|P2SH]] type starting with the number <code>3</code>, eg: <code>3J98t1WpEZ73CNmQviecrnyiWrnqRhWNLy</code>.
# [[Bech32]] type starting with <code>bc1</code>, eg: <code>bc1qar0srrr7xfkvy5l643lydnw9re59gtzzwf5mdq</code>.

==A Bitcoin address is a single-use token==
Like e-mail addresses, you can send bitcoins to a person by sending bitcoins to one of their addresses.
However, ''unlike'' e-mail addresses, people have many different Bitcoin addresses and a unique address should be used for each transaction {{Why}}.
Most Bitcoin software and websites will help with this by generating a brand new address each time you create an invoice or payment request.

==Addresses can be created offline==
Creating addresses can be done without an Internet connection and does not require any contact or registration with the Bitcoin network.
It is possible to create large batches of addresses offline using freely available software tools.
Generating batches of addresses is useful in several scenarios, such as e-commerce websites where a unique pre-generated address is dispensed to each customer who chooses a "pay with Bitcoin" option.
Newer [[Deterministic wallet | "HD wallets"]] can generate a "master public key" token which can be used to allow untrusted systems (such as webservers) to generate an unlimited number of addresses without the ability to spend the bitcoins received.

==Addresses are often case sensitive and exact==
Old-style Bitcoin addresses are case-sensitive. Bitcoin addresses should be copied and pasted using the computer's clipboard wherever possible. If you hand-key a Bitcoin address, and each character is not transcribed exactly - including capitalization - the incorrect address will most likely be rejected by the Bitcoin software. You will have to check your entry and try again.

The probability that a mistyped address is accepted as being valid is 1 in 232, that is, approximately 1 in 4.29 billion.

New-style [[bech32]] addresses are case insensitive.

==Proving you receive with an address==
Most Bitcoin wallets have a function to "sign" a message, proving the entity receiving funds with an address has agreed to the message.
This can be used to, for example, finalise a contract in a cryptographically provable way prior to making payment for it.

Some services will also piggy-back on this capability by dedicating a specific address for authentication only, in which case the address should never be used for actual Bitcoin transactions.
When you login to or use their service, you will provide a signature proving you are the same person with the pre-negotiated address.

It is important to note that these signatures only prove one receives with an address.
Since Bitcoin transactions do not have a "from" address, you cannot prove you are the ''sender'' of funds.

Current standards for message signatures are only compatible with "version zero" bitcoin addresses (that begin with the number 1).

==Address validation==
If you would like to validate a Bitcoin address in an application, it is advisable to use a method from [https://bitcointalk.org/index.php?topic=1026.0 this thread] rather than to just check for string length, allowed characters, or that the address starts with a 1 or 3. Validation may also be done using open source code available in [http://rosettacode.org/wiki/Bitcoin/address_validation various languages] or with an [http://lenschulwitz.com/base58 online validating tool].

==[[Multisignature|Multi-signature]] addresses==
Addresses can be created that require a combination of multiple private keys.
Since these take advantage of newer features, they begin with the newer prefix of 3 instead of the older 1.
These can be thought of as the equivalent of writing a check to two parties - "pay to the order of somebody AND somebody else" - where both parties must endorse the check in order to receive the funds.

The actual requirement (number of private keys needed, their corresponding public keys, etc.) that must be satisfied to spend the funds is decided in advance by the person generating this type of address, and once an address is created, the requirement cannot be changed without generating a new address.

==What's in an address==
Most Bitcoin addresses are 34 characters.
They consist of random digits and uppercase and lowercase letters, with the exception that the uppercase letter "O", uppercase letter "I", lowercase letter "l", and the number "0" are never used to prevent visual ambiguity.

Some Bitcoin addresses can be shorter than 34 characters (as few as 26) and still be valid.
A significant percentage of Bitcoin addresses are only 33 characters, and some addresses may be even shorter.
Every Bitcoin address stands for a number.
These shorter addresses are valid simply because they stand for numbers that happen to start with zeroes, and when the zeroes are omitted, the encoded address gets shorter.

Several of the characters inside a Bitcoin address are used as a checksum so that typographical errors can be automatically found and rejected.
The checksum also allows Bitcoin software to confirm that a 33-character (or shorter) address is in fact valid and isn't simply an address with a missing character.

==Testnet==
Addresses on the Bitcoin Testnet are generated with a different address version, which results in a different prefix.
See [[List of address prefixes]] and [[Testnet]] for more details.

==Misconceptions==
===Address reuse===

Addresses are not intended to be used more than once, and doing so has numerous problems associated.
See the dedicated article on [[address reuse]] for more details.

===Address balances===

Addresses are not wallets nor accounts, and do not carry balances.
They only receive funds, and you do not send "from" an address at any time.
Various confusing services and software display ''bitcoins received with an address, minus bitcoins sent in random unrelated transactions'' as an "address balance", but this number is not meaningful: it does not imply the recipient of the bitcoins sent to the address has spent them, nor that they still have the bitcoins received.

An example of bitcoin loss resulting from this misunderstanding is when people believed their address contained 3btc. They spent 0.5btc and believed the address now contained 2.5btc when actually it contained zero. The remaining 2.5btc was transferred to a change address which was not backed up and therefore lost. This has happened on a few occasions to users of [[Paper wallets]].

==="From" addresses===
Bitcoin transactions do not have any kind of origin-, source- or "from" address. See the dedicated article on "[[From address|from address]]" for more details.

==Address map==
[[File:Address map.jpg|700px]]

==See Also==
* [[Technical background of Bitcoin addresses]]
* [[List of address prefixes]]
* [[Exit Address]]

== References ==
<references/>

[[Category:Vocabulary]]

[[es:Dirección]]
[[de:Adresse]]

Elliptic Curve Digital Signature Algorithm

2019-11-25T19:33:57Z

Jhfrontz: Add clarification of (and reference to) signature length

'''Elliptic Curve Digital Signature Algorithm''' or '''ECDSA''' is a cryptographic algorithm used by Bitcoin to ensure that funds can only be spent by their rightful owners.

A few concepts related to ECDSA:
* [[private key]]: A secret number, known only to the person that generated it. A private key is essentially a randomly generated number. In Bitcoin, someone with the private key that corresponds to funds on the [[block chain]] can spend the funds. In Bitcoin, a private key is a single unsigned 256 bit integer (32 bytes).
* [[public key]]: A number that corresponds to a private key, but does not need to be kept secret. A public key can be calculated from a private key, but not vice versa. A public key can be used to determine if a signature is genuine (in other words, produced with the proper key) without requiring the private key to be divulged. In Bitcoin, public keys are either compressed or uncompressed. Compressed public keys are 33 bytes, consisting of a prefix either 0x02 or 0x03, and a 256-bit integer called ''x''. The older uncompressed keys are 65 bytes, consisting of constant prefix (0x04), followed by two 256-bit integers called ''x'' and ''y'' (2 * 32 bytes). The prefix of a compressed key allows for the ''y'' value to be derived from the ''x'' value.
* [[signature]]: A number that proves that a signing operation took place. A signature is mathematically generated from a [[hash]] of something to be signed, plus a private key. The signature itself is two numbers known as ''r'' and ''s''. With the public key, a mathematical algorithm can be used on the signature to determine that it was originally produced from the hash and the private key, without needing to know the private key. Resulting signatures are either 73, 72, or 71 bytes long (with approximate probabilities of 25%, 50%, and 25%, respectively--although sizes even smaller than that are possible with exponentially decreasing probability).<ref>{{cite web | url=https://crypto.stackexchange.com/a/75997/28556/ | title=ECDSA Signature Probability Basis }}</ref>

==See also==
* [[Secp256k1]]
==References==
<references />
==External Links==
* [https://en.wikipedia.org/wiki/Elliptic_Curve_DSA Elliptic Curve Digital Signature Algorithm - Wikipedia article]

{{wp|Elliptic_Curve_DSA}}

[[Category:Technical]]

Elliptic Curve Digital Signature Algorithm

2019-11-25T19:08:09Z

Jhfrontz: Undo revision 67054 by Jhfrontz (talk): Misunderstood context/sentence.

'''Elliptic Curve Digital Signature Algorithm''' or '''ECDSA''' is a cryptographic algorithm used by Bitcoin to ensure that funds can only be spent by their rightful owners.

A few concepts related to ECDSA:
* [[private key]]: A secret number, known only to the person that generated it. A private key is essentially a randomly generated number. In Bitcoin, someone with the private key that corresponds to funds on the [[block chain]] can spend the funds. In Bitcoin, a private key is a single unsigned 256 bit integer (32 bytes).
* [[public key]]: A number that corresponds to a private key, but does not need to be kept secret. A public key can be calculated from a private key, but not vice versa. A public key can be used to determine if a signature is genuine (in other words, produced with the proper key) without requiring the private key to be divulged. In Bitcoin, public keys are either compressed or uncompressed. Compressed public keys are 33 bytes, consisting of a prefix either 0x02 or 0x03, and a 256-bit integer called ''x''. The older uncompressed keys are 65 bytes, consisting of constant prefix (0x04), followed by two 256-bit integers called ''x'' and ''y'' (2 * 32 bytes). The prefix of a compressed key allows for the ''y'' value to be derived from the ''x'' value.
* [[signature]]: A number that proves that a signing operation took place. A signature is mathematically generated from a [[hash]] of something to be signed, plus a private key. The signature itself is two numbers known as ''r'' and ''s''. With the public key, a mathematical algorithm can be used on the signature to determine that it was originally produced from the hash and the private key, without needing to know the private key. Signatures are either 73, 72, or 71 bytes long, with probabilities approximately 25%, 50% and 25% respectively, although sizes even smaller than that are possible with exponentially decreasing probability.

==See also==
* [[Secp256k1]]

==External Links==
* [https://en.wikipedia.org/wiki/Elliptic_Curve_DSA Elliptic Curve Digital Signature Algorithm - Wikipedia article]

{{wp|Elliptic_Curve_DSA}}

[[Category:Technical]]

Elliptic Curve Digital Signature Algorithm

2019-11-25T17:51:18Z

Jhfrontz: Add link to probability

'''Elliptic Curve Digital Signature Algorithm''' or '''ECDSA''' is a cryptographic algorithm used by Bitcoin to ensure that funds can only be spent by their rightful owners.

A few concepts related to ECDSA:
* [[private key]]: A secret number, known only to the person that generated it. A private key is essentially a randomly generated number. In Bitcoin, someone with the private key that corresponds to funds on the [[block chain]] can spend the funds. In Bitcoin, a private key is a single unsigned 256 bit integer (32 bytes).
* [[public key]]: A number that corresponds to a private key, but does not need to be kept secret. A public key can be calculated from a private key, but not vice versa. A public key can be used to determine if a signature is genuine (in other words, produced with the proper key) without requiring the private key to be divulged. In Bitcoin, public keys are either compressed or uncompressed. Compressed public keys are 33 bytes, consisting of a prefix either 0x02 or 0x03, and a 256-bit integer called ''x''. The older uncompressed keys are 65 bytes, consisting of constant prefix (0x04), followed by two 256-bit integers called ''x'' and ''y'' (2 * 32 bytes). The prefix of a compressed key allows for the ''y'' value to be derived from the ''x'' value.
* [[signature]]: A number that proves that a signing operation took place. A signature is mathematically generated from a [[hash]] of something to be signed, plus a private key. The signature itself is two numbers known as ''r'' and ''s''. With the public key, a mathematical algorithm can be used on the signature to determine that it was originally produced from the hash and the private key, without needing to know the private key. Signatures are either 73, 72, or 71 bytes long, with [[probability | probabilities]] approximately 25%, 50% and 25% respectively, although sizes even smaller than that are possible with exponentially decreasing probability.

==See also==
* [[Secp256k1]]

==External Links==
* [https://en.wikipedia.org/wiki/Elliptic_Curve_DSA Elliptic Curve Digital Signature Algorithm - Wikipedia article]

{{wp|Elliptic_Curve_DSA}}

[[Category:Technical]]

Partially signed bitcoin transaction

2019-01-22T21:12:01Z

Jhfrontz: Created page with "A '''partially signed bitcoin transaction''' is a transaction representation that contains the information necessary for signers to produce signatures for said transaction..."

A '''partially signed bitcoin transaction''' is a [[transaction]] representation that contains the information necessary for signers to produce signatures for said transaction; it is capable of holding signatures for an [[Transaction#Input | input]] while the input does not have a complete set of signatures. The format (standardized by [https://github.com/bitcoin/bips/blob/master/bip-0174.mediawiki BIP 174]) can be used between [[clients]], allowing participants to pass around their transaction for signing (and ultimately to combine the associated signatures).

Segregated Witness

2019-01-22T20:59:45Z

Jhfrontz: link to wu

{{infobox |title=SegWit|image=<hr style="background-color: #f9f9f9;"/>[[File:Segwit.png|256px]]<hr style="background-color: #f9f9f9;"/>
|fulltitle=Segregated Witness (Consensus layer)
|bipnumber=[[BIP_0141|BIP 141]]
|purpose=Prevent unintended [[transaction malleability]]
|bit=Bit 1 "segwit"
|starttime=2016-11-15 00:00:00
|timeout=2017-11-15 00:00:00
|supermajority=95% of last 2016 block period
|lockin=Block #479708 2017-08-08 19:05:58
|activated=Block #481824 2017-08-24 01:57:37
}}'''Segregated Witness''' (abbreviated as '''SegWit''') is an implemented protocol upgrade intended to provide protection from [[transaction malleability]] and [[Block size limit controversy|increase block capacity]]. SegWit separates the ''witness'' from the list of inputs. The witness contains data required to check transaction validity but is not required to determine transaction effects.
Additionally, a new ''weight'' parameter is defined, and blocks are allowed to have at most 4 million [[weight units]] (WU). Non-witness and pre-segwit witness bytes weigh 4 WU, but each byte of Segwit witness data only weighs 1 WU, allowing blocks that are larger than 1 MB without a hardforking change.

After the successful activations of OP_CLTV and OP_CSV, SegWit was the last protocol change needed to make the [[Lightning Network]] safe to deploy on the Bitcoin network.

Because the new witness field contains [[Script]] versioning, it is also possible to make changes to or introduce new opcodes to SegWit scripts that would have originally required additional complexity to function without SegWit.

=== History and Activation ===

During 2016 and 2017 activation of segregated witness was blocked by miners for political reasons by exploiting a flaw in the [[BIP 9]] activation mechanism.
On a technical level, the consensus rules of bitcoin are controlled by the [[economic majority]] not the [[Bitcoin is not ruled by miners|miners]], so the deadlock was possible to solve by creating a [[user activated soft fork]] [[BIP 148]] where the [[economic majority]] would bypass the blocking miners and activate segregated witness on their own.
This required some coordination amongst the economic majority, but was ultimately successful, activating Segwit on Bitcoin soon after 1st August 2017.<ref>[https://bitcoinmagazine.com/articles/long-road-segwit-how-bitcoins-biggest-protocol-upgrade-became-reality/ BitcoinMagazine: The Long Road to SegWit: How Bitcoin’s Biggest Protocol Upgrade Became Reality]</ref>

==See Also==

* [[BIP_0141|BIP 141]] Segregated Witness (Consensus layer)
* [[BIP_0143|BIP 143]] Transaction Signature Verification for Version 0 Witness Program
* [[BIP_0144|BIP 144]] Segregated Witness (Peer Services)
* [[BIP_0145|BIP 145]] getblocktemplate Updates for Segregated Witness
* [[BIP_0147|BIP 147]] Dealing with dummy stack element malleability
* [[BIP_0173|BIP 173]] Base32 address format for native v0-16 witness outputs
* [https://bitcoincore.org/en/2016/01/26/segwit-benefits/ Segregated Witness Benefits]
* [https://bitcoincore.org/en/segwit_wallet_dev/ Segregated Witness Wallet Developer Guide]
{{stub}}

Fee bumping

2019-01-14T23:28:17Z

Jhfrontz: added some links to terms

The [[transaction fee | fee]] required for a [[transaction]] to quickly [[confirmation | confirm]] varies according to network conditions. Generally it floats around slowly, but sometimes it shoots up due to [[spam transactions]] or a series of randomly-slow blocks. In such cases, you may find that your incoming or outgoing transactions get stuck in an unconfirmed state for a long time. [[wallet | Wallets]] ''should'' avoid this in 99% of cases by accurately predicting an appropriate fee, and they ''should'' be able to gracefully bump fees in the remaining 1% of cases, but in general, fees are handled pretty poorly by today's wallets.

This page gives exact instructions on how to increase the fee on a transaction that is currently stuck in order to make it unstuck. This is always done by creating a new transaction that will either spend the coins sent by the stuck transaction (called [[Transaction fees#Feerates_for_dependent_transactions_.28child-pays-for-parent.29|child-pays-for-parent]], or CPFP) or replace the stuck transaction (called [[replace by fee|replace-by-fee]], or RBF). The instructions vary significantly depending on your wallet software. Find your wallet in the table of contents, and then go to the section labeled "I sent the stuck transaction" or "I received the stuck transaction", as appropriate.

In some cases, the instructions here become kludgy. Any time you're working outside of the normal wallet GUI, you're doing something that the developer didn't intend, and this could have negative consequences. Although we have tried to give good instructions, we can't guarantee that everything will work perfectly. If your wallet GUI doesn't directly support fee bumping, then the lowest-risk thing for you to do is to not bump the fee, and to just wait. This page is for those situations where you ''can't'' just wait.

Often, the instructions on this page have to get pretty complicated. As such, we will frequently say stuff like "Take such-and-such value; from now on, we'll call this value XYZ_AMOUNT". When we say something like this, you should write down in a text editor, "XYZ_AMOUNT=0.123" or similar so that you have the exact value ready for later. And then when we say something like "Type <tt>send "XYZ_AMOUNT"</tt>", we mean that you should directly replace the variable name with the value assigned earlier, so in this example it'd be <tt>send "0.123"</tt>.

== Choosing an appropriate new fee ==

# Find the transaction ID (aka txid) of the stuck transaction. Almost all wallets have some way of doing this.
# Search for the txid on https://blockchain.info/
# On blockchain.info, in the footer, click Enable in "Advanced: Enable". If advanced mode is already enabled so that it instead says "Advanced: Disable", then don't disable it.
# Write down the "size" number listed under "Summary". Call this value STUCK_SIZE. Also call the same value TOTAL_SIZE. The reason for having two names for the same thing is that you might later have to add to TOTAL_SIZE, but not to STUCK_SIZE. Separately, write down the "fees" number listed under "Inputs and outputs", and call this TOTAL_FEES.
# On the left side of the green arrow near the top of the page will be one or more addresses. If any of them have a red U next to it, for each such address, click "Output".
# For the transactions that it brings you to, add the size to TOTAL_SIZE, and the fees to TOTAL_FEES. Do this for all of the outputs listed with a red U.
# If any of ''those'' transactions also have red 'U's, you have to follow those as well and add their sizes and fees to the running totals. And so on. You might have to go down several layers.
# Now TOTAL_SIZE is the the total size (in bytes) of all unconfirmed ancestors of your stuck transaction, and TOTAL_FEES is the total fees (in BTC) for all unconfirmed ancestors of your stuck transaction.
# Go to https://estimatefee.com/. Around the middle-right of the page it'll say "nnn satoshis/byte", where nnn is some number. Remember this number as TARGET_FEERATE.
# We need to estimate the additional size of your replacement or CPFP transaction. We'll call this value NEWTX_SIZE. If the transaction you're trying to unstick is one that you sent, estimate NEWTX_SIZE as 100. If the transaction you're trying to unstick is one that you received, estimate NEWTX_SIZE as 500. Later on this page, the section for your specific wallet might give you a different value for NEWTX_SIZE, in which case you should use that value instead.
# Compute the following: [(TARGET_FEERATE / 100000000) * (TOTAL_SIZE + NEWTX_SIZE)] - TOTAL_FEES. The result is an estimate of the '''total''' fee that your new transaction will need to pay in BTC. For mBTC, multiply by 10-3; for bits/uBTC, 10-6; for satoshi, 10-8. This number is '''not''' per kB. If your wallet only allows you to specify fees in BTC/bits/satoshi per kB/byte, multiply the result by one of the following estimated conversion factors (we conservatively assume the worst-case 192-byte transaction for this estimation):
#* BTC/kB: 5.20833333333
#* bits/kB: 5208333.33333
#* satoshi/kB: 520833333.333
#* BTC/byte: 0.00520833333
#* bits/byte: 5208.33333333
#* satoshi/byte: 520833.333333

If blockchain.info doesn't have your transaction, you can use a different block explorer. blockchain.info is actually notoriously unreliable, but it has the best interface for this particular task.

Almost certainly, fine-tuning would result in a better fee rate, but the above instructions try to be very general and conservative (in the sense of having the highest chance of unsticking your transaction).

== Instructions by wallet ==

=== Bitcoin Core GUI ===

As of version 0.13.2.

==== I sent the stuck transaction ====

This is a bit complicated. Make sure you follow the steps exactly.

# On the Transactions tab, right click the stuck transaction and choose "copy transaction ID". Paste to a text editor in order to save the value somewhere. We'll call this value STUCK_TX. Once you've saved STUCK_TX somewhere, right click the stuck transaction again and choose "copy raw transaction"; we'll call this value STUCK_RAWTX.
# Go to Help -> Debug Window -> Console tab. Type <tt>decoderawtransaction STUCK_RAWTX</tt>. Under "vin" (near the top), find the first "txid" label. Copy the txid next to the "txid" label, and call this STUCK_VIN.
# You need to temporarily break connectivity. Go to Settings -> Options -> Network Tab. Enable "Connect through SOCKS5 proxy (default proxy)". Change "Proxy IP" and "port" to something that won't actually work; for example, an IP of 127.0.0.1 and a port of 10 is very unlikely to work. If you already have a proxy set up, note down your current settings so that you can restore them later.
# Shut down Bitcoin Core.
# Go to your [[Data directory]] and delete the file <tt>mempool.dat</tt>. This stops it acting as a cache and reloading your transaction.
# Start Bitcoin Core with the command-line option <tt>-walletbroadcast=0</tt>. On Linux, you might be able to just run <tt>bitcoin-qt -walletbroadcast=0</tt>, depending on how your current startup script works. On Windows: find the shortcut for Bitcoin Core on your desktop or start menu; right click it and choose "properties"; add <tt>-walletbroadcast=0</tt> to the end of "target", so for example <tt>"C:\Program Files\Bitcoin\bitcoin-qt.exe"</tt> would become <tt>"C:\Program Files\Bitcoin\bitcoin-qt.exe" -walletbroadcast=0</tt>; click "Apply"; use that specific shortcut to start Bitcoin Core.
# On the Transactions tab, right click the stuck transaction and choose "abandon transaction". '''Warning''': Even though the transaction is listed as abandoned, ''it can still go through''. People have in the past lost money by abandoning a transaction, resending a separate replacement transaction, and then having ''both'' transactions go through. The following steps are designed to replace the abandoned transaction in a way which will prevent this sort of double payment from happening.
# Undo the change which broke connectivity: Go to Settings -> Options -> Network Tab. Either disable "Connect through SOCKS5 proxy (default proxy)" or restore your previous proxy settings.
# Restart Bitcoin Core, this time without <tt>-walletbroadcast=0</tt>.
# Go to Settings -> Options -> Wallet. Ensure that "enable coin control features" is selected, and click OK.
# Go to the Send tab. Click the "Inputs..." button. For each entry in the list, right click it and select "copy transaction ID", and paste to a text editor. You have to go through the entire list, and for each entry with a txid matching STUCK_VIN, enable the checkbox on the far left. Usually there is only one matching, but if there is more than one, then you have to enable all of them. It is very important that you get this step right.
# In addition to the coins selected in the previous step, which are required, you can select more coins on the Coin Selection dialog if needed. You are creating a transaction that will replace your stuck transaction, so you need to bring "Amount" at the top high enough to send the transaction again, plus fees. Try to select as few as possible, though. Once enough coins are selected, press OK.
# (Optional, makes your new fee more accurate.) In the "Coin Control Features" pane, call the value for "Bytes" NEWTX_BYTES. Referring back to the fee estimation steps in the first section of this page: Set NEWTX_SIZE to be TOTAL_SIZE - STUCK_SIZE + NEWTX_BYTES, where TOTAL_SIZE and STUCK_SIZE were defined back in that section. Do the estimated fee calculation using this NEWTX_SIZE.
# Duplicate all of the settings of the stuck transaction, except for the fee. Instead of using the "recommended" fee, choose custom -> total at least, and then use the amount indicated in this page's fee estimation section. Note that under normal circumstances you should almost always use either the recommended fee or a per-kilobyte custom fee, not "total at least"; this situation is a special case.
# Send the transaction. Either the new transaction or the old transaction should get confirmed (''probably'' the new transaction), but not both if you did the coin control stuff correctly above.
# Sometimes these transactions don't propagate well, since they sometimes look like double-spend attempts. To improve this, find your new transaction in the list of transactions. Right click it and select "copy raw transaction". Google "Bitcoin pushtx" to find several sites where you can paste this raw transaction to improve propagation.

==== I received the stuck transaction ====

In the previous section on choosing an appropriate new fee, you can optionally set NEWTX_SIZE to 193 in order to pay a lower fee.

This is a bit complicated. Make sure you follow the steps exactly.

# Generate a new address in the same wallet. We'll call this NEW_ADDR.
# On the Transactions tab, right click the stuck transaction and choose "copy transaction ID". Paste to a text editor in order to save the value somewhere. We'll call this value STUCK_TX.
# Go to Help -> Debug Window -> Console tab.
# Type <tt>gettransaction STUCK_TX</tt>. We are going to collect several pieces of data from the output. First, looking at the "details" section, double-check that this actually is the stuck transaction that you're thinking of; if you accidentally selected the wrong transaction, you could lose BTC. Under "details", call the number next to "vout" STUCK_VOUT; call the number next to "amount" STUCK_AMOUNT. When copying values, do not include quotes.
# From STUCK_AMOUNT, subtract the total fee which you calculated in the first section on this page. Call this number NEW_AMOUNT. For example, if the stuck transaction sends you 1 BTC and you need to add a fee of 0.001 BTC, NEW_AMOUNT is 0.999.
# Type <tt>createrawtransaction '[{"txid":"STUCK_TX","vout":STUCK_VOUT}]' '{"NEW_ADDR":NEW_AMOUNT}'</tt>. Note that you must make four substitutions in this command using variables defined previously. When doing so, do not tamper with the quotes; just replace the variable name such as STUCK_TX with the data. '''Important''': If you do not use the correct value for NEW_AMOUNT as previously described, then you could massively overpay the fee. NEW_AMOUNT should be pretty close to the amount of the stuck transaction.
# (This step is for double-checking only, but should not be skipped.) Call the output of the previous command NEW_RAWTX. Type <tt>decoderawtransaction NEW_RAWTX</tt>. Under "vout", check that "value" is equal to NEW_AMOUNT and "addresses" is equal to NEW_ADDR. Double-check that NEW_AMOUNT is not tons less than STUCK_AMOUNT.
# Type <tt>signrawtransaction NEW_RAWTX</tt>. In the output, copy the data between quotes right after "hex". Don't copy the quotes themselves, just what's in between them. Call this NEW_RAWTX_SIGNED.
# Type <tt>sendrawtransaction NEW_RAWTX_SIGNED</tt>. If you get an error, '''discard''' your signed transaction (which may be dangerous) and get help from an expert.

=== Electrum ===

As of 2.7.18.

==== I sent the stuck transaction ====

If you enabled "Replaceable" when sending the transaction, find the stuck transaction in the History list, right click it, and choose "Increase fee". Electrum will guide you through it.

If you did not enable "Replaceable" when sending the transaction:

# Redo "choosing an appropriate new fee" above using a NEWTX_SIZE of 500.
# Create a new address in the same wallet (or a different one, if you want); call this NEW_ADDR.
# In your transaction history, right click the stuck transaction and select details.
# Under "Outputs", one of the addresses will usually be highlighted. Copy this address and call it CHANGE_ADDR. If none of the addresses are highlighted, then stop here: you can't use this method.
# Exit the details dialog and go to the "Coins" tab. Find the coin matching the address found above. Right click it and choose "Spend". If this coin has ''very'' low value, less than what you need to pay in the new fee, then ctrl-click other coins before clicking "spend" in order to add more value.
# Send a transaction to NEW_ADDR (ie. a transaction to yourself) with the new, higher fee. The amount of the transaction doesn't actually matter, but for fee efficiency, it's best to spend all of the BTC associated with CHANGE_ADDR minus the fee.

==== I received the stuck transaction ====

Locate the stuck transaction in the Coins tab. Right click -> Spend. Send this transaction with a high fee. You can send it to an address in the same wallet if you want.

=== Other wallets ===

==== I sent the stuck transaction ====

Often it's possible to trick a wallet into bumping fees on sent transactions, but there's no general set of instructions for doing it on all wallets, unfortunately.

==== I received the stuck transaction ====

If you're using a "wallet" that is actually a Bitcoin bank (eg. Coinbase, Gemini, etc.), then there's no way to do it.

For real Bitcoin wallets:

Send slightly more than the ''confirmed'' balance of your entire wallet to yourself. For example, if you have a 2 BTC confirmed balance and a stuck transaction causing an unconfirmed balance of 0.5 BTC, send 2.01 BTC to yourself. This forces the usage of some of your unconfirmed balance, which is what you want. (Some wallets might not allow this, in which case nothing can be done without switching wallets.) Send this transaction with a very high fee.

Note that sending your entire balance like this totally destroys your privacy by linking together all of the coins in your wallet.

[[Category:Guides]]

CheckSequenceVerify

2019-01-11T16:16:59Z

Jhfrontz: Created page with "'''CheckSequenceVerify''' (or ''CSV'') is an opcode that implements a type of timelock, controlling the execution pathways of a script based on t..."

'''CheckSequenceVerify''' (or ''CSV'') is an [[Script#Opcodes | opcode ]] that implements a type of [[timelock]], controlling the execution pathways of a [[script]] based on the [[age]] of the [[Transaction#Output | output]] being spent.<ref name="bip112"/>

CSV is used to implement [[Lightning Network]] transactions.

== References ==
<references>
<ref name="bip112">[https://github.com/bitcoin/bips/blob/master/bip-0112.mediawiki BIP112: CHECKSEQUENCEVERIFY] BtcDrak, Mark Friedenbach, Eric Lombrozo Retrieved 2016-04-12</ref>
</references>

User talk:Belcher

2018-12-18T00:11:22Z

Jhfrontz: bitcoins of privacy purposes?

==Atomic Swap edit on 30 Nov 2018==

Hi... I think you added a sentence to [[Atomic swap]] that reads
Atomic swaps can be used for trading between bitcoin and another cryptocurrency, or for trading bitcoins of privacy purposes.

It seems like there might be some words missing in "for trading bitcoins of privacy purposes" (i.e., what are "bitcoins of privacy purposes"?).
--[[User:Jhfrontz|Jhfrontz]] ([[User talk:Jhfrontz|talk]]) 00:11, 18 December 2018 (UTC)

Trusted platform module

2018-11-29T20:52:17Z

Jhfrontz: Created page with "A '''trusted platform module''' is a piece of computing hardware that is used for securely housing secrets (e.g., private keys) and for allowing said secrets..."

A '''trusted platform module''' is a piece of computing hardware that is used for securely housing secrets (e.g., [[private key | private keys]]) and for allowing said secrets to be used in the performance of certain operations (e.g., signing a [[transaction]]).

See https://en.wikipedia.org/wiki/Trusted_Platform_Module for technical details.

Contract

2018-11-29T20:40:35Z

Jhfrontz: /* Trust minimization: trusted hardware */ link to TPM

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.

By building low trust protocols that interact with Bitcoin, entirely new products can be created:

* [[Smart Property|Smart property]] is property that can be atomically traded and loaned via the block chain.
* [[Transferable virtual property]] are digital items that can be traded but not duplicated.
* [[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.
* [[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.

This page also lists some smaller examples.

Many of the ideas underlying Bitcoin contracts were first described by Nick Szabó in his seminal paper,
[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.

==A warning about the mempool transaction replacement mechanism==

In places this page refers to the ability to use the nSequence field for transaction mempool replacement. This mechanism was disabled in [https://github.com/bitcoin/bitcoin/commit/05454818dc7ed92f577a1a1ef6798049f17a52e7#diff-118fcbaaba162ba17933c7893247df3aR522 2010], and more recently the code has been [https://github.com/bitcoin/bitcoin/commit/98c7c8fd1d3712e02be0e9f2eeca7e02aa54d197 removed completely], due to concerns over people using it to perform DoS attacks. Implementors should take this into account and try to create contract mechanisms that do not rely on mempool replacement if they wish to have their implementations work with current implementations. If Bitcoin changes in future to allow mempool replacement once again, this page will be updated.

==Theory==

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.

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.

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.

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:

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

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.

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:

2 <pubkey1> <pubkey2> 2 CHECKMULTISIGVERIFY

There are two general patterns for safely creating contracts:

# Transactions are passed around outside of the P2P network, in partially-complete or invalid forms.
# 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.

This is to ensure that people always know what they are agreeing to.

Together, these features let us build interesting new financial tools on top of the block chain.

==Example 1: Providing a deposit==

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.

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.

We can solve this problem with a contract:

# The user and website send each other a newly-generated public key.
# 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.
# User sends the hash of Tx1 to the website.
# 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.
# 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.
# The user broadcasts Tx1, then broadcasts Tx2.

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.

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.

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.

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.

==Example 2: Escrow and dispute mediation==

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.

In other words, one wants to lock up some coins so a third party has to agree in order for them to be spent:

# Agree with the merchant on a dispute mediator (e.g., ClearCoin).
# Ask the merchant for a public key (K1). Ask the mediator for a public key (K2). Create a new key for yourself (K3).
# 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.
# Create a transaction (Tx1) with an output script as follows and broadcast it:

2 <K1> <K2> <K3> 3 CHECKMULTISIGVERIFY

Now the coins are locked in such a way that they can only be spent by the following methods:

# Client and the merchant agree (either a successful trade, or merchant agrees to reimburse client without mediation)
# Client and the mediator agree (failed trade, mediator sides with client, like a charge-back)
# The mediator and the merchant agree (goods delivered, merchant gets client's coins despite the dispute)

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.

==Example 3: Assurance contracts==

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.

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.

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.

We can model this in Bitcoin as follows:

# An entrepreneur creates a new address and announces that the good will be created if at least 1000 BTC is raised. Anyone can contribute.
# 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.
# 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.
# 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.
# The finished transaction is broadcast, sending the pledged coins to the announced address.

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.

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.

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.

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.

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.

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.

==Example 4: Using external state==

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.

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.

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.

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.

Here is an example. The man creates a transaction spending his output, and sets the output to:

<hash> OP_DROP 2 <sons pubkey> <oracle pubkey> CHECKMULTISIG

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:

if (has_died('john smith', born_on=1950/01/02)) return (10.0, 1JxgRXEHBi86zYzHN2U4KMyRCg4LvwNUrp);

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.

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.

It is used in the following algorithm:

# 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.
# The oracle checks the user-provided expression hashes to the value in the provided output script. If it doesn't, it returns an error.
# The oracle evaluates the expression. If the result is not the destination address of the output, it returns an error.
# 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.
# The user accepts the new signature, inserts it into the scriptSig and broadcasts the transaction.

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.

Oracles can potentially evaluate anything, yet the output script form in the block chain can always be the same. Consider the following possibilities:

today() == 2011/09/25 && exchange_rate(mtgoxUSD) >= 12.5 && exchange_rate(mtgoxUSD) <= 13.5
Require exchange rate to be between two values on a given date

google_results_count(site:www.google.com/hostednews 'Mike Hearn' olympic gold medal) > 0
A bet on me doing something that I will never actually do

// Choose between one of two winners of a bet on the outcome of the Eurovision song contest.
if (eurovision_winner() == 'Azerbaijan')
return 1Lj9udBVDwptFffGSJSC2sohCfudQgSTPD;
else
return 1JxgRXEHBi86zYzHN2U4KMyRCg4LvwNUrp;

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.

The [http://earlytemple.com/ ''Early Temple'' project] has implemented a prototype of an oracle that looks for a key phrase in a web page.

===Trust minimization: challenges===

There are various ways to reduce the level of required trust in the oracle.

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.

===Trust minimization: multiple independent oracles===

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. An implementation of such a system, and explanation was published in the '''[http://github.com/orisi/wiki/wiki/Orisi-White-Paper Orisi whitepaper]'''.

The idea, in short, is that independent oracles could be run by a set of trustworthy independent actors. Contract participants would first settle upon a set of oracles they both are comfortable using - for example by trusting [http://oracles.lo/ a dedicated site] - and then sign a contract requiring most of the oracles signatures to resolve.

One of the interesting properties of such a system is that it can possibly implement very complicated sets of scripts and external inputs, while being based on a set of standard bitcoin scripts. Another property is that the oracles can possibly replace each ones by forwarding the funds to new [https://bitcoinmagazine.com/11108/multisig-future-bitcoin/ multisig addresses] when they discover that one of the oracles is faulty/corrupted. Finally, such oracles could be used to implement sidechains without dedicated blockchain opcodes.

===Trust minimization: trusted hardware===

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 [[trusted platform module | 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).

===Trust minimization: Amazon AWS oracles===

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.

==Example 5: Trading across chains==

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.

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.

To implement this, a [https://bitcointalk.org/index.php?topic=193281.msg2224949#msg2224949 protocol proposed by TierNolan] can be used:

# Party 'A' generates some random data, x (the secret).
# 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.
# 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.
# '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.
# '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.
# 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').

This protocol makes it feasible to do trades automatically in an entirely peer-to-peer manner, which should ensure good liquidity.

The chain-trade script could look like this:

IF
2 <key A> <key B> 2 CHECKMULTISIGVERIFY
ELSE
<key B> CHECKSIGVERIFY SHA256 <hash of secret x> EQUALVERIFY
ENDIF

The contract input script looks like either:

<sig A> <sig B> 1

or

<secret x> <sig B> 0

i.e., the first data element selects which phase is being used.

See [[Atomic cross-chain trading]] for details.

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.

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.

==Example 6: Pay-for-proof contracts: buying a solution to any pure function==

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.

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.

Gregory Maxwell has invented a protocol for doing this, which you can read about here: [[Zero Knowledge Contingent Payment]]

==Example 7: Rapidly-adjusted (micro)payments to a pre-determined party==

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.

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.

One solution would be [[payment channel]]s like in the [[Lightning Network]].

Another alternative is the following protocol. 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.

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.

# Create a public key (K1). Request a public key from the server (K2).
# 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 private 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.
# 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"
# The server signs T2 using its private key associated with 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).
# The client verifies the servers signature is correct and aborts if not.
# 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.
# 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.
# The server verifies the output to itself is of the expected size and verifies the client's provided signature is correct.
# 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 own. 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.

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.

This protocol has [https://code.google.com/p/bitcoinj/wiki/WorkingWithMicropayments been implemented in bitcoinj].

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.

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.

==Example 8: Multi-party decentralised lotteries==

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.

==See Also==

* [[Script]]
* [[Binary options]]
* [[Oracle]]
* [[Fidelity bonds]]

[[Category:Technical]]

Agent

2018-11-29T20:39:22Z

Jhfrontz: /* Use of trusted computing/TPM chips */ link to TPM

An '''agent''' is an autonomous program that is able to survive by selling services for Bitcoins, and using the proceeds to rent server capacity. Agents that are profitable enough may replicate themselves by spawning additional instances on other servers.

Bitcoin-using autonomous agents were first described in a forum post by julz in 2011 and further elaborated on in that same discussion by Gregory Maxwell, who used a file storage system called StorJ as an illustrative example[https://bitcointalk.org/index.php?topic=53855.msg642768#msg642768]. Mike Hearn gave a talk on the topic at the Turing Festival 2013 ([https://www.youtube.com/watch?v=Pu4PAMFPo5Y video] and [http://www.slideshare.net/mikehearn/future-of-money-26663148 slides]). The concept has also been referred to as a "decentralised autonomous corporation" or DAC in a series of articles by Vitalik Buterin called [http://bitcoinmagazine.com/7050/bootstrapping-a-decentralized-autonomous-corporation-part-i/ "Bootstrapping a decentralised autonomous corporation"].

==Core concepts==

Agents interact with the world via the following mechanisms:

# The Bitcoin network
# APIs that allow for renting server capacity, and then remotely controlling that server (ie, ssh)
# Human readable contracts posted to freelancer forums or the Mechanical Turk
# Their own application protocols, for example, by serving HTTP

By maintaining their own balance, for the first time it becomes possible for software to exist on a level playing field to humans. It may even be that people find themselves working for the programs because they need the money, rather than programs working for the people. Being a peer rather than a tool is what distinguishes a program that uses Bitcoin from an agent.

Because server capacity is sold in well defined, standardized units (CPU seconds, gigabytes of RAM/disk, megabits of bandwidth) it becomes possible for software to automatically find and negotiate with providers who accept Bitcoin.

If a better deal is found, the agent can move itself. An agent that is profitable can be programmed to use some of those profits to bring up a child instance and fund it with a starter pack of coins. If the child instance is able to break even or better, it will survive, otherwise when its bank balance expires the server provider will delete the account and the agent along with it.

Agents can expose their services to humans (or other agents) by selecting a name and then registering it with [[Namecoin]]. If the agent has only Bitcoins it can use peer to peer exchanges to atomically trade Bitcoins for Namecoins or vice-versa. Using DNS hierarchies and Namecoin together allows interested parties to monitor for new agents coming online: the agent of registering a name under a particular part of the tree automatically advertises its existence.

Agents can improve themselves by purchasing the services of humans and using dispute mediators to give the humans some assurance the coins will be paid upon completion of the contract. A/B testing can be used to determine if the delivered work is really better than the old one or not, with the dispute mediator only releasing the coins if the results of the test are positive. For example, a redesigned user interface can be tested on 10% of all users, to see if they are more or less likely to upload/download a file. Alternatively, a quorum of dispute mediators can be specified, and they decide if the contract was met or not. New code can also be bought to increase the agents abilities.

==Reliance on low trust protocols==

Low trust protocols are important for agents to protect themselves against being scammed by humans. Being merely dumb programs, they cannot make nuanced trust judgements and are potentially easy to scam, for example, by offering to sell something then not actually providing it. Humans can spread the word, use courts of law and so on to try and reclaim losses when scammed, but agents cannot.

The most basic agent protocol is buying server time. By resigning transactions that are not broadcast, an agent can buy server capacity by the minute or even by the second. A very simple protocol can suffice, for instance, a ~/.account-billing-details file in the home directory of the new account that contains a Bitcoin address and the prices as negotiated. The agent can read the billing details from this standardized file and proceed to pay the server operator.

To evolve the agent, new code is needed, which must be written by people. To avoid humans scamming the agent and providing code that steals its wallet, the agent can use sandboxing technologies like Java or NativeClient to ensure the newly developed code only has access to what it needs. This would impose a small amount of rigidity on the agents design, but would allow truly autonomous bargaining. The agent can be programmed to trust the judgement of long-term customers: if enough of those customers review and sign the new code, it could be released from the sandbox and allowed to modify the agent in arbitrary ways. If the agent is sufficiently improved, it will outcompete its peers and reproduce more.

==Examples==

Consider the original example of a file storage agent.

# It rents its disk and bandwidth in return for coins. Anyone who wants a file to stay online can send coins to the files Bitcoin address.
# If it starts to run out of capacity, it can use some of its profits to spawn children on other hosting services. If a service has unknown reputation, the child can be monitored for a while until the parent is convinced it's operating correctly.
# Nodes can register their existence with names like "x536ma.storj.bit". Any name registered under storj.bit is assumed to offer the same services.
# The agents can compete on the quality of their user interfaces.
# Users could pledge for incorporation of a simple file viewer interface, to supplement download ability.

Whilst there are companies that provide shell accounts for Bitcoins, most don't. Server brokers are agents that simply re-sell computing capacity to other agents:

# By handling the details of how to interact with providers they offer a useful service, for which agents should be willing to pay.
# Brokers can purchase from humans scripts that handle signing up for accounts at new services. They can interact with exchanges to sell Bitcoin for the currencies and payment mechanisms the providers accept.
# Colo providers can run a modified sshd that understands how to treat SSH keys as [[Smart Property]]. By pre-creating shell accounts with resource quotas, and then selling the access keys to brokers, brokers can easily re-sell accounts automatically in a zero trust manner using the lock time and transaction input/output features of the Bitcoin protocol. The brokers would automatically handle recruitment of customers and matching agents with servers.

==Use of trusted computing/TPM chips==

To be truly autonomous, an agent should need to trust nobody (and nothing). But to make a trade you often need some assurance that the other side will behave as expected. People rely on the law to enforce contracts, but agents have no such recourse. Whilst clever protocols can configure incentives to ensure co-operation in some cases, trusted computing can be used to provide this assurance in the general case.

For example, agents may need some assurance that the provider of computing time will not attempt to steal the agents profits. Whilst it may be uneconomic in the long term to steal vs revenue share, it's quick and easy to make bogus offers to whatever agents are out there and wait for the money to roll in.

Modern CPUs have the ability to remotely prove what code they are running, and encrypt keys such that they are only available when the hardware is in the same configuration as before. The [http://sparrow.ece.cmu.edu/group/flicker.html Flicker] project demonstrates how to achieve this on AMD and Intel CPUs running Linux for short term computations (interrupts must be disabled in their simple implementation). Breaking the security requires modification of the [[trusted platform module | TPM]] chip, which is designed to be tamper resistant. If it is protecting sums of money that are not extremely large, this should be a sufficiently high level of difficulty to discourage fraud.

To use these facilities, a child agent (that is in the process of being created by its parent) would copy its code to the remote server. At this point it has no wallet. It would then enter the protected domain, where it is isolated from the regular operating system, and execute a PAL (piece of application logic) which creates itself a private key, which is then "sealed" to the state of the CPU at that time. Upon leaving the protected domain, it is left with encrypted data that cannot be read by the (possibly malicious) host operating system. The host OS is treated as an untrusted proxy and provider of resources.

The parent needs to provide its child with a small amount of money to let it get started, but how does it know its sending money truly to the child it just created and not a greedy imposter? The child can use the TPM to remotely prove it was in total control of the CPU at the time it created the private key corresponding to the provided address. The parent can verify that remote attestation and be assured it's sending money to the program it thinks it is.

If the services of an agent are purchased, for example, a file is uploaded to StorJ, the accompanying payment is presented to the secure PAL, along with the merkle branch linking it into the block chain. The PAL then updates its bookkeeping so it knows it needs to pay the host more, and when the host invoices the agent, the secure PAL verifies the bill is as expected and then creates/signs a transaction that pays the bill. The transaction is passed back to the untrusted host which broadcasts it.

Not all hardware supports trusted computing facilities. However, various laptops and server/desktop class PCs can be purchased that have the relevant chips. Renting such hardware to brokers might prove a profitable way to reduce the cost of a new computer purchase.

[[Category:Technical]]

Securing online services

2018-11-29T20:37:41Z

Jhfrontz: /* Future research */ Link to TPM and fixing typos.

Like any financial system, Bitcoin represents an attractive target for thieves and hackers. Any organization that accepts or sends significant volumes of money must therefore ensure they can '''secure their online service''' against these risks. This page details some best practices for merchants and other organizations, along with avenues for future research. It is ''not'' about securing your personal wallet.

== Traditional payment risks ==

Any time you accept payments online, you must deal with risk. This is true both of Bitcoin and credit cards, but the risks and responses to those risks are different. Let's recap the risks involved with traditional payment networks so we can compare them with Bitcoin.

=== Risks involved with accepting credit card payments online ===

To accept credit card payments online, you must perform the following tasks:

# Obtain a merchant account with a bank
# Build a database and online ordering system that can store credit card details
# Ensure it is secured to the level specified by the PCI DSS (Payment Card Industry Data Security Standards)
# Handle inspections by PCI auditors
# Be prepared to handle chargebacks, potentially large volumes of them depending on the type of business

A ''chargeback'' occurs when the owner of a credit card disputes a transaction, typically because either they believe you did not deliver satisfactorily, or because the card details were stolen and used by a card fraudster. If a chargeback occurs, the credit card company will take back the money and also fine you. If too many of your transactions result in chargebacks, you will lose the ability to accept credit card transactions and most likely your online business with it.

As you may have noticed, whilst happy customers are somewhat under your control in aggregate, you have no control over how many credit card numbers are stolen. For this reason credit-card accepting merchants typically have large and sophisticated fraud control measures in place, involving dedicated risk operations staff, machine learning, JavaScript browser fingerprinting and so on. The goal being to spot repeat fraudsters and deny their transactions. Too many false positives and legitimate customers who want to pay for your product cannot, limiting your market. Too many false negatives and you can lose significant money to chargebacks, which may arrive weeks or months after the product or service has been delivered.

Unsurprisingly, many merchants choose to outsource this arduous process to a third party payment gateway like [[PayPal]], Google Checkout and so on or a third party fraud prevention like FraudLabs Pro, Signifyd and so on. However all these services add their own policies, fees and often do not provide any guarantees of chargeback protection.

=== Risks involved in online banking ===

Storing money in an internet accessible bank account is convenient, but how safe it is depends very heavily on the type and quality of security measures put in place by your bank. A good online banking system looks like this:

# To log in, it requires you to input a code into a dedicated hardware device and then type back the response.
# To wire money, it requires you to input a fragment of the destination account number into a dedicated hardware device and then type back the response. Typically this is only required the first time you send money to an account. After that repeat transactions will be considered OK.
# It uses SSL.
# The bank will not issue new hardware or other credentials based purely on a phone conversation and a few personal trivia checks.
# The bank may also perform manual inspection of unusual transactions and call you to verify them.

With such a setup the rates of fraudulent bank wires are low and so bank transfers tend to be hard to reverse, so merchants are also protected. This setup describes many banks around the world, especially in the European SEPA zone. Unfortunately some banks, particularly American banks, often look like this:

# To log in you have to provide a password and something vaguely password-ish like a secret question
# There are no dedicated hardware devices used
# Security may be entirely heuristic
# Though Fedwire bank wires are not reversible, banks can still return funds that were received such as when the transfer was the result of phishing, for instance.
# Whilst consumer accounts may have some liability protection, business accounts do not

Because the security mechanisms in place are entirely controlled by your bank, if yours is unacceptable your only choice is to find another bank. If all banks serving your local market are the same, you're out of luck. Even if your bank has good security, accepting payments from a bank that does not can entail significant risk.

== Risks involved in handling Bitcoins ==

In contrast to the above systems, Bitcoin carries a different set of risks which can be managed in different ways.

# The server containing your wallet may be hacked and the coins stolen
# Money sent to your wallet may be reversed
# Your wallet may be accidentally destroyed, along with all the money in it.
# You may be scammed into sending your money elsewhere (this problem is not unique to Bitcoin)

However, unlike with traditional payment schemes, the risk of fraudulent payments is low and Bitcoin gives you tremendous flexibility to implement as much or as little security as you like. At no point are you at the mercy of third party payment processors who may or may not be properly incentivized to be secure. Below we discuss each problem Bitcoin using traders may face, and some common solutions.

=== Server hacking ===

Server hacks have resulted in the loss of tens of thousands of Bitcoins. Any internet-connected computer that has liquid access to data worth hundreds of thousands of dollars will come under sophisticated and sustained attack, but there are some simple techniques you can use to reduce your risk.

* For merchants who need to automatically accept payments online but not make them, use an '''encrypted wallet''' that does not have the password on the server. To receive a payment all you need is a public key (for better privacy most merchants use one fresh key per user or transaction). The public key alone does not allow you to spend the money. By creating a wallet with plenty of keys on your own local computer and then uploading the encrypted version to the server, you ensure that whilst the server can accept payments only your own computer can make them, even though they share the same balance. Thus hacking the server doesn't allow any financial gain. Of course you must still ensure your local computer is secured.
* Some organizations need to be able to automatically send money as well as receive it. Examples include trading platforms and mining pools. These typically use '''cold storage''' as much as possible, where only the minimum balance necessary to handle withdrawls is on the server. The rest is sent to a separate wallet which is kept away from internet connected computers. Because a wallet can receive coins without it being online, profit can be moved from the server to cold storage without risking the cold money. If an unusually large withdrawal takes place the transaction can be placed on hold until a human operator has time to reach the cold wallet and send money from it to the live site. This limits your losses to the size of your hot wallet in the case of a server breach.
* Avoid managed server hosting. During 2012 several high profile breaches were caused not by lax security on the part of the site operators themselves but rather the companies providing the servers. Many datacenter operators, even large well known ones, are ''not'' equipped to handle sensitive data regardless of what assurances they may provide. They can be vulnerable to hacking and social engineering themselves. Instead, purchase your own server(s) and rent a cage / network connection from a local datacenter that you can visit in person. For added security, either disable remote access entirely or ensure only connections from your home IP ranges are allowed. Make sure the datacenter operator won't provide remote access on request without some pre-agreed security protocol being followed, like a callback.
* Consider implementing a supervisor system. In this scheme, the site gives its users multi-signature addresses for sending payments. The money received requires a signature by both the website and an independent supervisor computer. The job of the supervisor is to analyze the stream of payment requests from the other server and try to spot anomalies. If a payment request looks OK then it will be signed. If it looks iffy a human will be called for further attention. The supervisor can be made a lot more secure than the website because it has only a single, well defined purpose and does not need to run complex user-facing software like a web site or email system. So the job of the attacker now becomes either to hack both systems (hard if they are deliberately set up differently), or to find a way to extract money that the supervisor won't notice. What exactly "good" vs "bad" transactions look like are merchant specific.

=== Transaction reversals ===

Whilst both credit cards and Bitcoins can experience transaction reversals, in Bitcoin the risk is entirely theoretical and has yet to be observed in the wild, whilst chargebacks are extremely common in the credit card world. Nevertheless, you should understand the risks:

* For merchants that are shipping physical goods you probably don't have to worry. Reversing a transaction gets harder and harder with time. After only one hour it becomes computationally infeasible to reverse a Bitcoin transaction. Inserting a small delay before shipping isolates you from this risk entirely.
* For automated trading platforms that may pay out some other currency in response to Bitcoin deposits, you should also delay payment for a short time until reversal becomes infeasible. Low risk deposits from trusted customers could be processed faster, as reversing a Bitcoin transaction is a non trivial problem at this time which is suited only to relatively skilled attackers who are after large sums of money.
* For merchants shipping things immediately, like digital downloads, measuring the propagation of a transaction across the network and waiting until most nodes have reported it is probably good enough. This allows you to accept the payment within seconds. Whilst there's a higher risk of transaction reversal here, the attack is still expensive and the attacker cannot choose the timing of the attack. Therefore watching out for users who receive an address and then delay the act of payment significantly is probably enough to insulate you from this attack (the [[Double-spending#Finney_attack|Finney attack]]).

=== Your wallet may be accidentally destroyed ===

Backing up Bitcoin wallets is easy, as they are just files. For high volume sites with the existing software (Bitcoin 0.6), you should pre-generate a large number of keys such that a single old backup is enough to restore all your money. Future versions will derive new keys deterministically, so a single backup should be enough to ensure you can always restore your wallet after an accidental or malicious deletion.

=== You may be scammed into sending the money elsewhere ===

Whilst no financial system can completely solve human gullibility, Bitcoins multi-signature keys allow you to lock up money such that multiple people have to agree in order for it to be spent. For example, the bulk of your balance could be assigned to a multi-signature key that requires you
and your business partners to agree .... thus forcing a mental sanity check from multiple people, hopefully making the act of scamming harder.

== Future research ==

Whilst running your own physical servers with no datacenter operator access is secure, it lacks convenience. In the future it may be possible to the use [[trusted platform module | TPM (trusted platform module)]] chips to allow managed hosting such that root or even physical access is insufficient to steal the funds, as the wallet keys would be bound to a particular software environment. Well engineered trusted computing solutions have some degree of physical resistance so rebooting the machine, opening it up or logging in with local/remote root would not allow you to steal the wallet's balance.

Unfortunately engineering such systems is non-trivial and the technical difficulty places this solution out of reach for most traders right now. The future availability of easy-to-use software libraries, documentation, examples and managed hosting providers that sell TC enabled hardware may increase its attractiveness.

==See Also==

* [[In-store Transactions]]
* [[How to accept Bitcoin, for small businesses]]
* [http://bitcointalk.org/index.php?topic=93770.0 How CoinPal avoided PayPal fraud]

==References==
<references />

[[Category:ECommerce]]
[[Category:Security]]

Bech32

2018-06-13T00:15:23Z

Jhfrontz: link for segwit

Bech32 is a [[segwit]] [[address]] format specified by [[BIP 0173]]. This address format is also known as "bc1 addresses".

While this address format has been included in some implementations, as of December 2017, the address format is not recommended for use until more software supports the format.

See the page [[Bech32 adoption]] to track adoption.

=== Examples ===

Examples of the address format being used on mainnet are the TXIDs <code>4ef47f6eb681d5d9fa2f7e16336cd629303c635e8da51e425b76088be9c8744c</code> and <code>514a33f1d46179b89e1fea7bbb07b682ab14083a276979f91038369d1a8d689b</code>. And addresses <code>bc1qar0srrr7xfkvy5l643lydnw9re59gtzzwf5mdq</code> and <code>bc1qc7slrfxkknqcq2jevvvkdgvrt8080852dfjewde450xdlk4ugp7szw5tk9</code>.

== See Also ==

* Talk by Pieter Wuille the new bech32 address format (March 2017) https://www.reddit.com/r/Bitcoin/comments/62fydd/pieter_wuille_lecture_on_new_bech32_address_format/
* Comment by maaku7 explaining how bech32 addresses improve the security of (for example) [[multisignature]] https://www.reddit.com/r/Bitcoin/comments/74tonn/bech32_native_segwit_address_already_used_on_the/dqlogru/