https://en.bitcoin.it/w/api.php?action=feedcontributions&user=Harding&feedformat=atomBitcoin Wiki - User contributions [en]2024-03-19T02:56:04ZUser contributionsMediaWiki 1.30.0https://en.bitcoin.it/w/index.php?title=Common_Vulnerabilities_and_Exposures&diff=69956Common Vulnerabilities and Exposures2023-12-12T19:18:12Z<p>Harding: [Move-only] CVE-2023-50428 was placed after "Definitions" and "See Also". Correct that mistake.</p>
<hr />
<div>{| class="wikitable"<br />
!style="width:16ex"| CVE<br />
! Announced !! Affects !! Severity !! Attack is... !! Flaw !! Net<br />
|-<br />
| Pre-BIP protocol changes<br />
| n/a<br />
| All Bitcoin clients<br />
|bgcolor=pink| Netsplit<ref name="Netsplit"/><br />
|bgcolor=pink| Implicit<ref name="hardfork">This is a protocol "hard-fork" that old clients will reject as invalid and must therefore not be used.</ref><br />
| [[Consensus versions|Various hardforks and softforks]]<br />
|bgcolor=lime| 100%<br />
|-<br />
| [[#CVE-2010-5137|CVE-2010-5137]]<br />
| 2010-07-28<br />
| wxBitcoin and bitcoind<br />
|bgcolor=yellow| DoS<ref name="DoS">Attacker can disable some functionality, for example by crashing clients</ref><br />
|bgcolor=pink| Easy<br />
| OP_LSHIFT crash<br />
|bgcolor=lime| 100%<br />
|-<br />
| [[#CVE-2010-5141|CVE-2010-5141]]<br />
| 2010-07-28<br />
| wxBitcoin and bitcoind<br />
|bgcolor=pink| Theft<ref name="Theft">Attacker can take coins outside known network rules</ref><br />
|bgcolor=pink| Easy<br />
| OP_RETURN could be used to spend any output.<br />
|bgcolor=lime| 100%<br />
|-<br />
| [[#CVE-2010-5138|CVE-2010-5138]]<br />
| 2010-07-29<br />
| wxBitcoin and bitcoind<br />
|bgcolor=yellow| DoS<ref name="DoS"/><br />
|bgcolor=pink| Easy<br />
| Unlimited SigOp DoS<br />
|bgcolor=lime| 100%<br />
|-<br />
| '''[[CVE-2010-5139]]'''<br />
| 2010-08-15<br />
| wxBitcoin and bitcoind<br />
|bgcolor=pink| Inflation<ref name="inflation">Attacker can create coins outside known network rules</ref><br />
|bgcolor=pink| Easy<br />
| Combined output overflow<br />
|bgcolor=lime| 100%<br />
|-<br />
| [[#CVE-2010-5140|CVE-2010-5140]]<br />
| 2010-09-29<br />
| wxBitcoin and bitcoind<br />
|bgcolor=yellow| DoS<ref name="DoS"/><br />
|bgcolor=pink| Easy<br />
| Never confirming transactions<br />
|bgcolor=lime| 100%<br />
|-<br />
| [[#CVE-2011-4447|CVE-2011-4447]]<br />
| 2011-11-11<br />
| wxBitcoin and bitcoind<br />
|bgcolor=pink| Exposure<ref name="Exposure">Attacker can access user data outside known acceptable methods</ref><br />
|bgcolor=lime| Hard<br />
| Wallet non-encryption<br />
|bgcolor=lime| [http://luke.dashjr.org/programs/bitcoin/files/charts/CVE-2011-4447.html 100%]<br />
|-<br />
| [[#CVE-2012-1909|CVE-2012-1909]]<br />
| 2012-03-07<br />
| Bitcoin protocol and all clients<br />
|bgcolor=pink| Netsplit<ref name="Netsplit">Attacker can create multiple views of the network, enabling [[double-spending]] with over 1 confirmation</ref><br />
|bgcolor=lime| Very hard<br />
| Transaction overwriting<br />
|bgcolor=lime| [http://luke.dashjr.org/programs/bitcoin/files/charts/CVE-2012-1909.html 100%]<br />
|-<br />
| [[#CVE-2012-1910|CVE-2012-1910]]<br />
| 2012-03-17<br />
| bitcoind & Bitcoin-Qt for Windows<br />
|bgcolor=pink| Unknown<ref name="Unknown">Extent of possible abuse is unknown</ref><br />
|bgcolor=lime| Hard<br />
| Non-thread safe MingW exceptions<br />
|bgcolor=lime| [http://luke.dashjr.org/programs/bitcoin/files/charts/CVE-2012-1910.html 100%]<br />
|-<br />
| [[#BIP-0016|BIP 0016]]<br />
| 2012-04-01<br />
| All Bitcoin clients<br />
|bgcolor=yellow| Fake Conf<ref name="FakeConf">Attacker can double-spend with 1 confirmation</ref><br />
|bgcolor=yellow| Miners<ref name="MinerEasy">Attacking requires mining block(s)</ref><br />
| Softfork: P2SH<br />
|bgcolor=lime| [http://luke.dashjr.org/programs/bitcoin/files/charts/BIP-0016.html 100%]<br />
|-<br />
| [[#CVE-2012-2459|CVE-2012-2459]]<br />
| 2012-05-14<br />
| bitcoind and Bitcoin-Qt<br />
|bgcolor=pink| Netsplit<ref name="Netsplit"/><br />
|bgcolor=pink| Easy<br />
| Block hash collision (via merkle root)<br />
|bgcolor=lime| [http://luke.dashjr.org/programs/bitcoin/files/charts/CVE-2012-2459.html 100%]<br />
<!--<br />
|-<br />
| [[#CVE-2012-3584|CVE-2012-3584]]<br />
| 2012-06-16<br />
| Bitcoin p2p protocol<br />
|bgcolor=yellow| DoS<ref name="DoS"/><br />
|bgcolor=yellow| Miners<ref name="MinerEasy"/><br />
| Poor miner incentives<br />
| (no fix)<br />
--><br />
|-<br />
| '''[[CVE-2012-3789]]'''<br />
| 2012-06-20<br />
| bitcoind and Bitcoin-Qt<br />
|bgcolor=yellow| DoS<ref name="DoS"/><br />
|bgcolor=pink| Easy<br />
| (Lack of) orphan txn resource limits<br />
|bgcolor=lime| [http://luke.dashjr.org/programs/bitcoin/files/charts/security.html?20123789 100%]<br />
|-<br />
| [[#CVE-2012-4682|CVE-2012-4682]]<br />
| <br />
| bitcoind and Bitcoin-Qt<br />
|bgcolor=yellow| DoS<ref name="DoS"/><br />
| <br />
| <br />
|bgcolor=lime| [http://luke.dashjr.org/programs/bitcoin/files/charts/CVE-2012-4682.html 100%]<br />
|-<br />
| '''[[CVE-2012-4683]]'''<br />
| 2012-08-23<br />
| bitcoind and Bitcoin-Qt<br />
| bgcolor=yellow| DoS<ref name="DoS"/><br />
| bgcolor=pink| Easy<br />
| Targeted DoS by CPU exhaustion using alerts<br />
|bgcolor=lime| [http://luke.dashjr.org/programs/bitcoin/files/charts/CVE-2012-4683.html 100%]<br />
|-<br />
| '''[[CVE-2012-4684]]'''<br />
| 2012-08-24<br />
| bitcoind and Bitcoin-Qt<br />
| bgcolor=yellow| DoS<ref name="DoS"/><br />
| bgcolor=pink| Easy<br />
| Network-wide DoS using malleable signatures in alerts<br />
|bgcolor=lime| [http://luke.dashjr.org/programs/bitcoin/files/charts/security.html?20124684 100%]<br />
|-<br />
| [[#CVE-2013-2272|CVE-2013-2272]]<br />
| 2013-01-11<br />
| bitcoind and Bitcoin-Qt<br />
|bgcolor=yellow| Exposure<ref name="Exposure"/><br />
|bgcolor=pink| Easy<br />
| Remote discovery of node's wallet addresses<br />
|bgcolor=lime| [http://luke.dashjr.org/programs/bitcoin/files/charts/security.html?20132272 99.99%]<br />
|-<br />
| [[#CVE-2013-2273|CVE-2013-2273]]<br />
| 2013-01-30<br />
| bitcoind and Bitcoin-Qt<br />
|bgcolor=lime| Exposure<ref name="Exposure"/><br />
|bgcolor=yellow| Easy<br />
| Predictable change output<br />
|bgcolor=lime| [http://luke.dashjr.org/programs/bitcoin/files/charts/security.html?20132273 99.99%]<br />
|-<br />
| [[#CVE-2013-2292|CVE-2013-2292]]<br />
| 2013-01-30<br />
| bitcoind and Bitcoin-Qt<br />
|bgcolor=yellow| DoS<ref name="DoS"/><br />
|bgcolor=lime| Hard<br />
| A transaction that takes at least 3 minutes to verify<br />
|bgcolor=pink| [http://luke.dashjr.org/programs/bitcoin/files/charts/security.html?20132292 0%]<br />
|-<br />
| '''[[CVE-2013-2293]]'''<br />
| 2013-02-14<br />
| bitcoind and Bitcoin-Qt<br />
|bgcolor=yellow| DoS<ref name="DoS"/><br />
|bgcolor=pink| Easy<br />
| Continuous hard disk seek<br />
|bgcolor=lime| [http://luke.dashjr.org/programs/bitcoin/files/charts/security.html?20132293 99.99%]<br />
|-<br />
| [[#CVE-2013-3219|CVE-2013-3219]]<br />
| 2013-03-11<br />
| bitcoind and Bitcoin-Qt 0.8.0<br />
|bgcolor=pink| Fake Conf<ref name="FakeConf"/><br />
|bgcolor=yellow| Miners<ref name="MinerEasy"/><br />
| Unenforced block protocol rule<br />
|bgcolor=lime| [http://luke.dashjr.org/programs/bitcoin/files/charts/security.html?20133219 100%]<br />
|-<br />
| [[#CVE-2013-3220|CVE-2013-3220]]<br />
| 2013-03-11<br />
| bitcoind and Bitcoin-Qt<br />
|bgcolor=pink| Netsplit<ref name="Netsplit"/><br />
|bgcolor=lime| Hard<br />
| Inconsistent BDB lock limit interactions<br />
|bgcolor=lime| [http://luke.dashjr.org/programs/bitcoin/files/charts/security.html?20133220 99.99%]<br />
|-<br />
| [[#BIP-0034|BIP 0034]]<br />
| 2013-03-25<br />
| All Bitcoin clients<br />
|bgcolor=yellow| Fake Conf<ref name="FakeConf"/><br />
|bgcolor=yellow| Miners<ref name="MinerEasy">Attacking requires mining block(s)</ref><br />
| Softfork: Height in coinbase<br />
|bgcolor=lime| [http://luke.dashjr.org/programs/bitcoin/files/charts/BIP-0034.html 100%]<br />
|-<br />
| [[#BIP-0050|BIP 0050]]<br />
| 2013-05-15<br />
| All Bitcoin clients<br />
|bgcolor=pink| Netsplit<ref name="Netsplit"/><br />
|bgcolor=pink| Implicit<ref name="hardfork">This is a protocol "hard-fork" that old clients will reject as invalid and must therefore not be used.</ref><br />
| Hard fork to remove txid limit protocol rule<br />
|bgcolor=lime| [http://luke.dashjr.org/programs/bitcoin/files/charts/security.html?50 99.99%]<br />
|-<br />
| [[#CVE-2013-4627|CVE-2013-4627]]<br />
| 2013-06-??<br />
| bitcoind and Bitcoin-Qt<br />
|bgcolor=yellow| DoS<ref name="DoS"/><br />
|bgcolor=yellow| Easy<br />
| Memory exhaustion with excess tx message data<br />
|bgcolor=lime| [http://luke.dashjr.org/programs/bitcoin/files/charts/security.html?20134627 99%]<br />
|-<br />
| [[#CVE-2013-4165|CVE-2013-4165]]<br />
| 2013-07-20<br />
| bitcoind and Bitcoin-Qt<br />
|bgcolor=pink| Theft<ref name="theft-local-timing">Local attacker could potentially determine the RPC passphrase via a timing sidechannel.</ref><br />
|bgcolor=lime| Local<br />
| Timing leak in RPC authentication<br />
|bgcolor=lime| [http://luke.dashjr.org/programs/bitcoin/files/charts/security.html?20134165 99%]<br />
|-<br />
| [[#CVE-2013-5700|CVE-2013-5700]]<br />
| 2013-09-04<br />
| bitcoind and Bitcoin-Qt 0.8.x<br />
|bgcolor=yellow| DoS<ref name="DoS"/><br />
|bgcolor=pink| Easy<br />
| Remote p2p crash via bloom filters<br />
|bgcolor=lime| [http://luke.dashjr.org/programs/bitcoin/files/charts/security.html?20135700 99%]<br />
|-<br />
| [[#CVE-2014-0160|CVE-2014-0160]]<br />
| 2014-04-07<br />
| Anything using OpenSSL for TLS<br />
|bgcolor=pink| Unknown<ref name="Unknown"/><br />
|bgcolor=pink| Easy<br />
| Remote memory leak via payment protocol<br />
| Unknown<br />
|-<br />
| CVE-2015-3641<br />
| 2014-07-07<br />
| bitcoind and Bitcoin-Qt prior to 0.10.2<br />
|bgcolor=yellow| DoS<ref name="DoS"/><br />
|bgcolor=pink| Easy<br />
| (Yet) Unspecified DoS<br />
|bgcolor=lime| [http://luke.dashjr.org/programs/bitcoin/files/charts/security.html?20135700 99.9%]<br />
|-<br />
| BIP 66<br />
| 2015-02-13<br />
| All Bitcoin clients<br />
|bgcolor=yellow| Fake Conf<ref name="FakeConf">Attacker can double-spend with 1 confirmation</ref><br />
|bgcolor=yellow| Miners<ref name="MinerEasy">Attacking requires mining block(s)</ref><br />
| Softfork: Strict DER signatures<br />
|bgcolor=lime| [http://luke.dashjr.org/programs/bitcoin/files/charts/security.html?66 99%]<br />
|-<br />
| BIP 65<br />
| 2015-11-12<br />
| All Bitcoin clients<br />
|bgcolor=yellow| Fake Conf<ref name="FakeConf">Attacker can double-spend with 1 confirmation</ref><br />
|bgcolor=yellow| Miners<ref name="MinerEasy">Attacking requires mining block(s)</ref><br />
| Softfork: OP_CHECKLOCKTIMEVERIFY<br />
|bgcolor=lime| [http://luke.dashjr.org/programs/bitcoin/files/charts/security.html?65 99%]<br />
|-<br />
| BIPs 68, 112 & 113<br />
| 2016-04-11<br />
| All Bitcoin clients<br />
|bgcolor=yellow| Fake Conf<ref name="FakeConf">Attacker can double-spend with 1 confirmation</ref><br />
|bgcolor=yellow| Miners<ref name="MinerEasy">Attacking requires mining block(s)</ref><br />
| Softforks: Rel locktime, CSV & MTP locktime<br />
|bgcolor=lime| [http://luke.dashjr.org/programs/bitcoin/files/charts/security.html?68 99%]<br />
|-<br />
| BIPs 141, 143 & 147<br />
| 2016-10-27<br />
| All Bitcoin clients<br />
|bgcolor=yellow| Fake Conf<ref name="FakeConf">Attacker can double-spend with 1 confirmation</ref><br />
|bgcolor=yellow| Miners<ref name="MinerEasy">Attacking requires mining block(s)</ref><br />
| Softfork: Segwit<br />
|bgcolor=lime| [http://luke.dashjr.org/programs/bitcoin/files/charts/security.html?141 99%]<br />
|-<br />
| [[#CVE-2016-8889|CVE-2016-8889]]<br />
| 2016-10-27<br />
| Bitcoin Knots GUI 0.11.0 - 0.13.0<br />
|bgcolor=yellow| Exposure<br />
|bgcolor=lime| Hard<br />
| Debug console history storing sensitive info<br />
|bgcolor=lime| 100%<br />
|-<br />
| CVE-2017-9230<br />
| ?<br />
| Bitcoin<br />
| ?<br />
| ?<br />
| ASICBoost<br />
|bgcolor=pink| 0%<br />
|-<br />
| BIP 148<br />
| 2017-03-12<br />
| All Bitcoin clients<br />
|bgcolor=yellow| Fake Conf<ref name="FakeConf">Attacker can double-spend with 1 confirmation</ref><br />
|bgcolor=yellow| Miners<ref name="MinerEasy">Attacking requires mining block(s)</ref><br />
| Softfork: Segwit UASF<br />
| ?<br />
|-<br />
| [[#CVE-2017-12842|CVE-2017-12842]]<br />
| 2018-06-09<br />
|<br />
|<br />
|<br />
| No commitment to block merkle tree depth<br />
|<br />
|-<br />
| [https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2018-July/016189.html CVE-2016-10724]<br />
| 2018-07-02<br />
| bitcoind and Bitcoin-Qt prior to 0.13.0<br />
|bgcolor=yellow| DoS<ref name="DoS"/><br />
|bgcolor=pink| Keyholders<ref name="KeyholderEasy">Attacking requires signing with the publicly-disclosed alert key</ref><br />
| Alert memory exhaustion<br />
|bgcolor=lime| [http://luke.dashjr.org/programs/bitcoin/files/charts/security.html?201610724 99%]<br />
|-<br />
| [https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2018-July/016189.html CVE-2016-10725]<br />
| 2018-07-02<br />
| bitcoind and Bitcoin-Qt prior to 0.13.0<br />
|bgcolor=yellow| DoS<ref name="DoS"/><br />
|bgcolor=pink| Keyholders<ref name="KeyholderEasy">Attacking requires signing with the publicly-disclosed alert key</ref><br />
| Final alert cancellation<br />
|bgcolor=lime| [http://luke.dashjr.org/programs/bitcoin/files/charts/security.html?201610724 99%]<br />
|-<br />
| [[#CVE-2018-17144|CVE-2018-17144]]<br />
| 2018-09-17<br />
| bitcoind and Bitcoin-Qt prior to 0.16.3<br />
|bgcolor=pink| Inflation<ref name="inflation"/><br />
|bgcolor=yellow| Miners<ref name="MinerEasy"/><br />
| Missing check for duplicate inputs<br />
|bgcolor=pink| [http://luke.dashjr.org/programs/bitcoin/files/charts/security.html?201817144 80%]<br />
|-<br />
| [https://medium.com/@lukedashjr/cve-2018-20587-advisory-and-full-disclosure-a3105551e78b CVE-2018-20587]<br />
| 2019-02-08<br />
| Bitcoin Knots prior to 0.17.1, and all current Bitcoin Core releases<br />
|bgcolor=pink| Theft<ref name="theft-local-timing">Local attacker could potentially determine the RPC passphrase via a timing sidechannel.</ref><br />
|bgcolor=lime| Local<br />
| No alert for RPC service binding failure<br />
|bgcolor=pink| [http://luke.dashjr.org/programs/bitcoin/files/charts/security.html?201820587 <1%]<br />
|-<br />
| [[#CVE-2017-18350|CVE-2017-18350]]<br />
| 2019-06-22<br />
| bitcoind and Bitcoin-Qt prior to 0.15.1<br />
|bgcolor=pink| Unknown<br />
|bgcolor=pink| Varies<ref>Depends on software configuration</ref><br />
| Buffer overflow from SOCKS proxy<br />
|bgcolor=yellow| [http://luke.dashjr.org/programs/bitcoin/files/charts/security.html?201718350 94%]<br />
|-<br />
| [[#CVE-2018-20586|CVE-2018-20586]]<br />
| 2019-06-22<br />
| bitcoind and Bitcoin-Qt prior to 0.17.1<br />
|bgcolor=lime| Deception<br />
|bgcolor=lime| RPC access<br />
| Debug log injection via unauthenticated RPC<br />
|bgcolor=pink| [http://luke.dashjr.org/programs/bitcoin/files/charts/security.html?201820586 77%]<br />
|-<br />
| [https://lists.linuxfoundation.org/pipermail/lightning-dev/2019-September/002174.html CVE-2019-12998]<br />
| 2019-08-30<br />
| c-lightning prior to 0.7.1<br />
|bgcolor=pink| Theft<br />
|bgcolor=pink| Easy<br />
| Missing check of channel funding UTXO<br />
|-<br />
| [https://lists.linuxfoundation.org/pipermail/lightning-dev/2019-September/002174.html CVE-2019-12999]<br />
| 2019-08-30<br />
| lnd prior to 0.7<br />
|bgcolor=pink| Theft<br />
|bgcolor=pink| Easy<br />
| Missing check of channel funding UTXO amount<br />
|-<br />
| [https://lists.linuxfoundation.org/pipermail/lightning-dev/2019-September/002174.html CVE-2019-13000]<br />
| 2019-08-30<br />
| eclair prior to 0.3<br />
|bgcolor=pink| Theft<br />
|bgcolor=pink| Easy<br />
| Missing check of channel funding UTXO<br />
|-<br />
| [[#CVE-2020-14199|CVE-2020-14199]]<br />
| 2020-06-03<br />
| Trezor and others<br />
|bgcolor=pink| Theft<br />
|bgcolor=lime| Social<ref>User must be tricked into cooperating (social engineering)</ref><br />
| Double-signing can enable unintended fees<br />
|-<br />
| [https://invdos.net/ CVE-2018-17145]<br />
| 2020-09-09<br />
| Bitcoin Core prior to 0.16.2<br>Bitcoin Knots prior to 0.16.1<br>Bcoin prior to 1.0.2<br>Btcd prior to 0.21.0<br />
|bgcolor=yellow| DoS<ref name="DoS"/><br />
|bgcolor=pink| Easy<br />
| p2p memory blow-up<br />
|bgcolor=pink| [http://luke.dashjr.org/programs/bitcoin/files/charts/security.html?201817145 87%]<br />
|-<br />
| [[#CVE-2020-26895|CVE-2020-26895]]<br />
| 2020-10-08<br />
| lnd prior to 0.10<br />
|bgcolor=pink| Theft<br />
|bgcolor=pink| Easy<br />
| Missing low-S normalization for HTLC signatures<br />
|-<br />
| [[#CVE-2020-26896|CVE-2020-26896]]<br />
| 2020-10-08<br />
| lnd prior to 0.11<br />
|bgcolor=pink| Theft<br />
|bgcolor=yellow | Varies<ref>Depends on node configuration, only affects routable merchants, requires external knowledge of receiver's invoices and/or luck to identify receiver, only works against single-shot HTLCs (legacy or MPP)</ref><br />
| Invoice preimage extraction via forwarded HTLC<br />
|-<br />
| CVE-2020-14198<br />
| <br />
| Bitcoin Core 0.20.0<br />
|bgcolor=yellow| DoS<ref name="DoS"/><br />
|bgcolor=pink| Easy<br />
| Remote DoS<br />
|bgcolor=pink| [http://luke.dashjr.org/programs/bitcoin/files/charts/security.html?202014198 93%]<br />
|-<br />
| [[#CVE-2021-3401|CVE-2021-3401]]<br />
| 2021-02-01<br />
| Bitcoin Core GUI prior to 0.19.0<br>Bitcoin Knots GUI prior to 0.18.1<br />
|bgcolor=pink| Theft<br />
|bgcolor=lime| Hard<br />
| Qt5 remote execution<br />
|bgcolor=pink| [http://luke.dashjr.org/programs/bitcoin/files/charts/security.html?20213401 64%]<br />
|-<br />
| [[#CVE-2021-31876|CVE-2021-31876]]<br />
| 2021-05-06<br />
| Various wallets<br />
|<br />
|<br />
|<br />
|-<br />
| CVE-2021-41591<br />
| 2021-10-04<br />
| Lightning software<br />
|<br />
|<br />
|<br />
|-<br />
| CVE-2021-41592<br />
| 2021-10-04<br />
| Lightning software<br />
|<br />
|<br />
|<br />
|-<br />
| CVE-2021-41593<br />
| 2021-10-04<br />
| Lightning software<br />
|<br />
|<br />
|<br />
|-<br />
| BIPs 341-343<br />
| 2021-11-13<br />
| All Bitcoin nodes<br />
|bgcolor=yellow| Fake Conf<ref name="FakeConf">Attacker can double-spend with 1 confirmation</ref><br />
|bgcolor=yellow| Miners<ref name="MinerEasy">Attacking requires mining block(s)</ref><br />
| Softfork: Taproot<br />
|bgcolor=pink| [http://luke.dashjr.org/programs/bitcoin/files/charts/security.html?343 57%]<br />
|-<br />
| [https://github.com/spesmilo/electrum/security/advisories/GHSA-4fh4-hx35-r355 CVE-2022-31246]<br />
| 2022-06-07<br />
| Electrum 2.1 until before 4.2.2<br />
|bgcolor=pink| Theft<br />
|bgcolor=lime| Social<br />
|<br />
|-<br />
| [[#CVE-2023-50428|CVE-2023-50428]]<br />
| 2023<br />
| All Bitcoin nodes<br />
|bgcolor=yellow| DoS<ref name="DoS"/><br />
|bgcolor=pink| Easy<br />
| Bypass of datacarriersize limit using OP_FALSE,OP_IF<br />
|<br />
|}<br />
<br />
<references/><br />
<br />
__NOTOC__<br />
<br />
== CVE-2010-5137 ==<br />
<br />
<b>Date:</b> 2010-07-28<br />
<b>Summary:</b> OP_LSHIFT crash<br />
<b>Fix Deployment:</b> 100%<br />
{| class='wikitable'<br />
!colspan='2'| Affected !! Fix<br />
|-<br />
| bitcoind<br>wxBitcoin || * - 0.3.4 || 0.3.5<br />
|}<br />
<br />
On July 28 2010, two bugs were discovered and demonstrated on the test network. One caused bitcoin to crash on some machines when processing a transaction containing an OP_LSHIFT. This was never exploited on the main network, and was fixed by Bitcoin version 0.3.5.<br />
<br />
After these bugs were discovered, many currently-unused script words were disabled for safety.<br />
<br />
=== References ===<br />
* [http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2010-5137 US-CERT/NIST]<br />
<br />
<br />
== CVE-2010-5141 ==<br />
<br />
<b>Date:</b> 2010-07-28<br />
<b>Summary:</b> ?<br />
<b>Fix Deployment:</b> 100%<br />
{| class='wikitable'<br />
!colspan='2'| Affected !! Fix<br />
|-<br />
| bitcoind<br>wxBitcoin || * - 0.3.4 || 0.3.5<br />
|}<br />
<br />
On July 28 2010, two bugs were discovered and demonstrated on the test network. One exploited a bug in the transaction handling code and allowed an attacker to spend coins that they did not own. This was never exploited on the main network, and was fixed by Bitcoin version 0.3.5.<br />
<br />
After these bugs were discovered, many currently-unused script words were disabled for safety.<br />
<br />
=== References ===<br />
* [http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2010-5141 US-CERT/NIST]<br />
<br />
<br />
== CVE-2010-5138 ==<br />
<br />
<b>Date:</b> 2010-07-29<br />
<b>Summary:</b> Unlimited SigOp DoS<br />
<b>Fix Deployment:</b> 100%<br />
{| class='wikitable'<br />
!colspan='2'| Affected !! Fix<br />
|-<br />
| bitcoind<br>wxBitcoin || * - 0.3.? || 0.3.?<br />
|}<br />
<br />
On July 29 2010, it was discovered that block [http://blockexplorer.com/block/00000000000997f9fd2fe1ee376293ef8c42ad09193a5d2086dddf8e5c426b56 71036] contained several transactions with a ton of OP_CHECKSIG commands. There should only ever be one such command. This caused every node to do extra unnecessary work, and it could have been used as a denial-of-service attack. A new version of Bitcoin was quickly released. The new version did not cause a fork on the main network, though it did cause one on the test network (where someone had played around with the attack more).<br />
<br />
=== References ===<br />
* [http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2010-5138 US-CERT/NIST]<br />
<br />
<br />
== CVE-2010-5139 ==<br />
{{main|CVE-2010-5139}}<br />
<b>Date:</b> 2010-08-15<br />
<b>Summary:</b> Combined output overflow<br />
<b>Fix Deployment:</b> 100%<br />
{| class='wikitable'<br />
!colspan='2'| Affected !! Fix<br />
|-<br />
| bitcoind<br>wxBitcoin || * - 0.3.10 || 0.3.11<br />
|}<br />
<br />
On August 15 2010, it was [http://bitcointalk.org/index.php?topic=822.0 discovered] that block 74638 contained a transaction that created over 184 billion bitcoins for two different addresses. This was possible because the code used for checking transactions before including them in a block didn't account for the case of outputs so large that they overflowed when summed. A new version was published within a few hours of the discovery. The block chain had to be forked. Although many unpatched nodes continued to build on the "bad" block chain, the "good" block chain overtook it at a block height of 74691. The bad transaction no longer exists for people using the longest chain.<br />
<br />
The block and transaction:<br />
<pre>CBlock(hash=0000000000790ab3, ver=1, hashPrevBlock=0000000000606865, hashMerkleRoot=618eba,<br />
nTime=1281891957, nBits=1c00800e, nNonce=28192719, vtx=2)<br />
CTransaction(hash=012cd8, ver=1, vin.size=1, vout.size=1, nLockTime=0)<br />
CTxIn(COutPoint(000000, -1), coinbase 040e80001c028f00)<br />
CTxOut(nValue=50.51000000, scriptPubKey=0x4F4BA55D1580F8C3A8A2C7)<br />
CTransaction(hash=1d5e51, ver=1, vin.size=1, vout.size=2, nLockTime=0)<br />
CTxIn(COutPoint(237fe8, 0), scriptSig=0xA87C02384E1F184B79C6AC)<br />
CTxOut(nValue=92233720368.54275808, scriptPubKey=OP_DUP OP_HASH160 0xB7A7)<br />
CTxOut(nValue=92233720368.54275808, scriptPubKey=OP_DUP OP_HASH160 0x1512)<br />
vMerkleTree: 012cd8 1d5e51 618eba<br />
<br />
Block hash: 0000000000790ab3f22ec756ad43b6ab569abf0bddeb97c67a6f7b1470a7ec1c<br />
Transaction hash: 1d5e512a9723cbef373b970eb52f1e9598ad67e7408077a82fdac194b65333c9</pre><br />
<br />
=== References ===<br />
* [https://bitcointalk.org/index.php?topic=822.0 Discovery]<br />
* [http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2010-5139 US-CERT/NIST]<br />
<br />
== CVE-2010-5140 ==<br />
<br />
<b>Date:</b> 2010-09-29<br />
<b>Summary:</b> Never confirming transactions<br />
<b>Fix Deployment:</b> 100%<br />
{| class='wikitable'<br />
!colspan='2'| Affected !! Fix<br />
|-<br />
| bitcoind<br>wxBitcoin || * - 0.3.12 || 0.3.13<br />
|}<br />
<br />
Around September 29, 2010, people started [https://bitcointalk.org/index.php?topic=1306.0 reporting] that their sent transactions would not confirm. This happened because people modified Bitcoin to send sub-0.01 transactions without any fees. A 0.01 fee was at that time required by the network for such transactions (essentially prohibiting them), so the transactions remained at 0 confirmations forever. This became a more serious issue because Bitcoin would send transactions using bitcoins gotten from transactions with 0 confirmations, and these resulting transactions would also never confirm. Because Bitcoin tends to prefer sending smaller coins, these invalid transactions quickly multiplied, contaminating the wallets of everyone who received them.<br />
<br />
Bitcoin was changed to only select coins with at least 1 confirmation. The remaining sub-0.01 transactions were cleared by generators who modified their version of Bitcoin to not require the micropayment fee. It took a while for everything to get cleared, though, because many of the intermediate transactions had been forgotten by the network by this point and had to be rebroadcast by the original senders.<br />
<br />
=== References ===<br />
* [https://bitcointalk.org/index.php?topic=1306.0 Initial reports]<br />
* [http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2010-5140 US-CERT/NIST]<br />
<br />
<br />
== CVE-2011-4447 ==<br />
<br />
<b>Date:</b> 2011-11-11<br />
<b>Summary:</b> Wallet non-encryption<br />
<b>Fix Deployment:</b> 100%<br />
{| class='wikitable'<br />
!colspan='2'| Affected !! Fix<br />
|-<br />
| bitcoind<br>wxBitcoin || 0.4.0 - 0.4.1rc6 || 0.4.1<br>0.5.0<br />
|}<br />
<br />
=== References ===<br />
* [https://bitcointalk.org/index.php?topic=51604.0 Announcement]<br />
* [https://bitcointalk.org/index.php?topic=51474.0 Finding]<br />
* [http://bitcoin.org/releases/2011/11/21/v0.5.0.html 0.5.0]<br />
* [http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2011-4447 US-CERT/NIST]<br />
<br />
<br />
== CVE-2012-1909 ==<br />
<br />
<b>Date:</b> 2012-03-07<br />
<b>Summary:</b> Transaction overwriting<br />
<b>Fix Deployment:</b> 100%<br />
{| class='wikitable'<br />
!colspan='2'| Affected !! Fix<br />
|-<br />
| Bitcoin protocol || Before March 15th, 2012 || BIP 30<br />
|-<br />
| Bitcoin-Qt<br>bitcoind || * - 0.4.4rc2<br>0.5.0rc1 - 0.5.0.4rc2<br>0.5.1rc1 - 0.5.3rc2<br>0.6.0rc1 - 0.6.0rc2 || 0.4.4<br>0.5.0.4<br>0.5.3<br>0.6.0rc3<br />
|-<br />
| wxBitcoin || ALL || NONE<br />
|}<br />
<br />
=== References ===<br />
* [https://bitcointalk.org/index.php?topic=67738.0 Announcement]<br />
* [https://en.bitcoin.it/wiki/BIP_0030 Fix]<br />
* [https://bugs.gentoo.org/show_bug.cgi?id=407793 Gentoo bug tracker]<br />
* [http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2012-1909 US-CERT/NIST]<br />
<br />
== CVE-2012-1910 ==<br />
<br />
<b>Date:</b> 2012-03-17<br />
<b>Summary:</b> Non-thread safe MingW exceptions<br />
<b>Fix Deployment:</b> 100%<br />
{| class='wikitable'<br />
!colspan='2'| Affected !! Fix<br />
|-<br />
| bitcoind for Windows<br>Bitcoin-Qt for Windows || 0.5.0rc1 - 0.5.0.4<br>0.5.1rc1 - 0.5.3.0<br>0.6.0rc1 - 0.6.0rc3 || 0.5.0.5<br>0.5.3.1<br>0.5.4<br>0.6.0rc4<br />
|}<br />
<br />
=== References ===<br />
* [https://bitcointalk.org/index.php?topic=69120.0 Announcement]<br />
* [http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2012-1910 US-CERT/NIST]<br />
* [http://gavintech.blogspot.com/2012/03/full-disclosure-bitcoin-qt-on-windows.html Full disclosure]<br />
<br />
== BIP-0016 ==<br />
<br />
<b>Date:</b> 2012-04-01<br />
<b>Summary:</b> Mandatory P2SH protocol update<br />
<b>Deployment:</b> 100%<br />
{| class='wikitable'<br />
!colspan='2'| Affected !! Fix<br />
|-<br />
| Bitcoin-Qt<br>bitcoind || * - 0.4.4<br>0.5.0rc1 - 0.5.0.5<br>0.5.1rc1 - 0.5.3<br>0.6.0rc1 || 0.4.5<br>0.5.0.6<br>0.5.4rc1<br>0.6.0rc2<br />
|-<br />
| wxBitcoin || ALL || NONE<br />
|}<br />
<br />
=== References ===<br />
* [[BIP 0016]]<br />
<br />
== CVE-2012-2459 ==<br />
<br />
<b>Date:</b> 2012-05-14<br />
<b>Summary:</b> Block hash collision (via merkle tree)<br />
<b>Fix Deployment:</b> 100%<br />
{| class='wikitable'<br />
!colspan='2'| Affected !! Fix<br />
|-<br />
| Bitcoin-Qt<br>bitcoind || * - 0.4.6rc1<br>0.5.0rc1 - 0.5.5rc1<br>0.6.0rc1 - 0.6.0.7rc1<br>0.6.1rc1 - 0.6.1rc1 || 0.4.6<br>0.5.5<br>0.6.0.7<br>0.6.1rc2<br />
|}<br />
<br />
Block hash collisions can easily be made by duplicating transactions in the merkle tree.<br />
Such a collision is invalid, but if recorded (as Bitcoin-Qt and bitcoind prior to 0.6.1 did) would prevent acceptance of the legitimate block with the same hash.<br />
This could be used to fork the blockchain, including deep double-spend attacks.<br />
<br />
=== References ===<br />
* [https://bitcointalk.org/?topic=81749 Announcement]<br />
* [https://bugs.gentoo.org/show_bug.cgi?id=415973 Gentoo bug tracker]<br />
* [http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2012-2459 US-CERT/NIST]<br />
* [https://bitcointalk.org/?topic=102395 Full Disclosure]<br />
<br />
== CVE-2012-3789 ==<br />
{{main|CVE-2012-3789}}<br />
<b>Date:</b> 2012-06-20<br />
<b>Summary:</b> (Lack of) orphan txn resource limits<br />
<b>Fix Deployment:</b> 100%<br />
{| class='wikitable'<br />
!colspan='2'| Affected !! Fix<br />
|-<br />
| Bitcoin-Qt<br>bitcoind || * - 0.4.7rc2<br>0.5.0rc1 - 0.5.6rc2<br>0.6.0rc1 - 0.6.0.8rc2<br>0.6.1rc1 - 0.6.2.2 || 0.4.7rc3<br>0.5.6rc3<br>0.6.0.9rc1<br>0.6.3rc1<br />
|}<br />
<br />
=== References ===<br />
* [[CVE-2012-3789]]<br />
* [https://bitcointalk.org/?topic=88734 0.6.3rc1 Announcement]<br />
* [http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2012-3789 US-CERT/NIST]<br />
<br />
== CVE-2012-4682 ==<br />
<br />
<b>Date:</b> <br />
<b>Summary:</b> <br />
<b>Fix Deployment:</b> 100%<br />
{| class='wikitable'<br />
!colspan='2'| Affected !! Fix<br />
|-<br />
| Bitcoin-Qt<br>bitcoind || * - 0.4.7rc2<br>0.5.0rc1 - 0.5.6rc2<br>0.6.0rc1 - 0.6.0.8rc2<br>0.6.1rc1 - 0.6.2.2 || 0.4.7rc3<br>0.5.6rc3<br>0.6.0.9rc1<br>0.6.3rc1<br />
|}<br />
<br />
=== References ===<br />
* [[CVE-2012-4682]]<br />
* [https://bugs.gentoo.org/show_bug.cgi?id=435216 Gentoo bug]<br />
<br />
== CVE-2012-4683 ==<br />
{{main|CVE-2012-4683}}<br />
<b>Date:</b> 2012-08-23<br />
<b>Summary:</b> Targeted DoS by CPU exhaustion using alerts<br />
<b>Fix Deployment:</b> 100%<br />
{| class='wikitable'<br />
!colspan='2'| Affected !! Fix<br />
|-<br />
| Bitcoin-Qt<br>bitcoind || * - 0.4.7rc2<br>0.5.0rc1 - 0.5.6rc2<br>0.6.0rc1 - 0.6.0.8rc2<br>0.6.1rc1 - 0.6.2.2 || 0.7.0 <br />
|}<br />
<br />
=== References ===<br />
* [[CVE-2012-4683]]<br />
* [https://bitcointalk.org/index.php?topic=148038.0 Announcement]<br />
* [https://bugs.gentoo.org/show_bug.cgi?id=435216 Gentoo bug]<br />
<br />
== CVE-2012-4684 ==<br />
{{main|CVE-2012-4684}}<br />
<b>Date:</b> 2012-08-24<br />
<b>Summary:</b> Network-wide DoS using malleable signatures in alerts<br />
<b>Fix Deployment:</b> 100%<br />
{| class='wikitable'<br />
!colspan='2'| Affected !! Fix<br />
|-<br />
| Bitcoin-Qt<br>bitcoind || * - 0.4.7rc2<br>0.5.0rc1 - 0.5.6rc2<br>0.6.0rc1 - 0.6.0.8rc2<br>0.6.1rc1 - 0.6.2.2 - 0.6.3rc1 || 0.7.0 <br />
|}<br />
<br />
=== References ===<br />
* [[CVE-2012-4684]]<br />
* [https://bitcointalk.org/index.php?topic=148109.0 Announcement]<br />
<br />
== CVE-2013-2272 ==<br />
<br />
<b>Date:</b> 2013-01-11<br />
<b>Summary:</b> Remote discovery of node's wallet addresses<br />
<b>Fix Deployment:</b> 99.99%<br />
{| class='wikitable'<br />
!colspan='2'| Affected !! Fix<br />
|-<br />
| Bitcoin-Qt<br>bitcoind || * - 0.4.8rc4<br>0.5.0rc1 - 0.5.7<br>0.6.0rc1 - 0.6.0.10rc4<br>0.6.1rc1 - 0.6.4rc4<br>0.7.0rc1 - 0.7.2 || 0.4.9rc1<br>0.5.8rc1<br>0.6.0.11rc1<br>0.6.5rc1<br>0.7.3rc1<br />
|}<br />
<br />
=== References ===<br />
<br />
* [https://bitcointalk.org/?topic=135856 Announcement]<br />
* [https://bugs.gentoo.org/show_bug.cgi?id=462046 Gentoo bug]<br />
<br />
== CVE-2013-2273 ==<br />
<br />
<b>Date:</b> 2013-01-30<br />
<b>Summary:</b> Predictable change output<br />
<b>Fix Deployment:</b> 99.99%<br />
{| class='wikitable'<br />
!colspan='2'| Affected !! Fix<br />
|-<br />
| Bitcoin-Qt<br>bitcoind || * - 0.4.8rc4<br>0.5.0rc1 - 0.5.7<br>0.6.0rc1 - 0.6.0.10rc4<br>0.6.1rc1 - 0.6.4rc4<br>0.7.0rc1 - 0.7.2 || 0.4.9rc1<br>0.5.8rc1<br>0.6.0.11rc1<br>0.6.5rc1<br>0.7.3rc1<br />
|}<br />
<br />
=== References ===<br />
<br />
* [https://bugs.gentoo.org/show_bug.cgi?id=462046 Gentoo bug]<br />
<br />
== CVE-2013-2292 ==<br />
<br />
<b>Date:</b> 2013-01-30<br />
<b>Summary:</b> A transaction that takes at least 3 minutes to verify<br />
<b>Fix Deployment:</b> 0%<br />
{| class='wikitable'<br />
!colspan='2'| Affected !! Fix<br />
|-<br />
| Bitcoin-Qt<br>bitcoind || All versions || No fix yet<br />
|}<br />
<br />
=== References ===<br />
* [[CVE-2013-2292]]<br />
* [https://bitcointalk.org/?topic=140078 Announcement]<br />
* [https://bugs.gentoo.org/show_bug.cgi?id=462046 Gentoo bug]<br />
<br />
== CVE-2013-2293 ==<br />
{{main|CVE-2013-2293}}<br />
<b>Date:</b> 2013-02-14<br />
<b>Summary:</b> Continuous hard disk seek<br />
<b>Fix Deployment:</b> 99.99%<br />
{| class='wikitable'<br />
!colspan='2'| Affected !! Fix<br />
|-<br />
| Bitcoin-Qt<br>bitcoind || * - 0.7.3rc1 || No fix yet (0.8.0 unaffected)<br />
|}<br />
<br />
=== References ===<br />
<br />
* [[CVE-2013-2293]]<br />
* [https://bitcointalk.org/?topic=144122 Announcement]<br />
* [https://bugs.gentoo.org/show_bug.cgi?id=462046 Gentoo bug]<br />
<br />
== CVE-2013-3219 ==<br />
<br />
<b>Date:</b> 2013-03-11<br />
<b>Summary:</b> Unenforced block protocol rule<br />
<b>Fix Deployment:</b> 100%<br />
{| class='wikitable'<br />
!colspan='2'| Affected !! Fix<br />
|-<br />
| Bitcoin-Qt<br>bitcoind || 0.8.0rc1 - 0.8.0 || 0.8.1<br />
|}<br />
<br />
=== References ===<br />
* [[BIP 0050|BIP 50]]<br />
<br />
== CVE-2013-3220 ==<br />
<br />
<b>Date:</b> 2013-03-11<br />
<b>Summary:</b> Inconsistent BDB lock limit interactions<br />
<b>Fix Deployment:</b> 99.99%<br />
{| class='wikitable'<br />
!colspan='2'| Affected !! Fix<br />
|-<br />
| Bitcoin-Qt<br>bitcoind || * - 0.4.9rc1<br>0.5.0rc1 - 0.5.8rc1<br>0.6.0rc1 - 0.6.5rc1<br>0.7.0rc1 - 0.7.3rc1 || 0.4.9rc2<br>0.5.8rc2<br>0.6.5rc2<br>0.7.3rc2<br />
|-<br />
| wxBitcoin || ALL || NONE<br />
|}<br />
<br />
=== References ===<br />
* [[BIP 0050|BIP 50]]<br />
<br />
== BIP-0034 ==<br />
<br />
<b>Date:</b> 2013-03-25<br />
<b>Summary:</b> Mandatory block protocol update<br />
<b>Deployment:</b> 100%<br />
{| class='wikitable'<br />
!colspan='2'| Affected !! Fix<br />
|-<br />
| Bitcoin-Qt<br>bitcoind || * - 0.4.7<br>0.5.0rc1 - 0.5.7<br>0.6.0rc1 - 0.6.0.9<br>0.6.1rc1 - 0.6.3 || 0.4.8rc1<br>0.5.7rc1<br>0.6.0.10rc1<br>0.6.4rc1<br />
|-<br />
| wxBitcoin || ALL || NONE<br />
|}<br />
<br />
=== References ===<br />
* [[BIP 0034]]<br />
<br />
== BIP-0050 ==<br />
<br />
<b>Date:</b> 2013-05-15<br />
<b>Summary:</b> Hard fork to remove txid limit protocol rule<br />
<b>Deployment:</b> 99.99%<br />
{| class='wikitable'<br />
!colspan='2'| Affected !! Fix<br />
|-<br />
| Bitcoin-Qt<br>bitcoind || * - 0.4.9rc1<br>0.5.0rc1 - 0.5.8rc1<br>0.6.0rc1 - 0.6.5rc1<br>0.7.0rc1 - 0.7.3rc1 || 0.4.9rc2<br>0.5.8rc2<br>0.6.5rc2<br>0.7.3rc2<br />
|-<br />
| wxBitcoin || ALL || NONE<br />
|}<br />
<br />
=== References ===<br />
* [[BIP 0050]]<br />
<br />
== CVE-2013-4627 ==<br />
<br />
<b>Date:</b> 2013-06-??<br />
<b>Summary:</b> Memory exhaustion with excess tx message data<br />
<b>Fix Deployment:</b> 99.9%<br />
{| class='wikitable'<br />
!colspan='2'| Affected !! Fix<br />
|-<br />
| Bitcoin-Qt<br>bitcoind || * - 0.4.9rc3<br>0.5.0rc1 - 0.5.8rc3<br>0.6.0rc1 - 0.6.5rc3<br>0.7.0rc1 - 0.7.3rc3<br>0.8.0rc1 - 0.8.3 || 0.4.9rc4<br>0.5.8rc4<br>0.6.5rc4<br>0.7.3rc4<br>0.8.4<br />
|-<br />
| wxBitcoin || ALL || NONE<br />
|}<br />
<br />
=== References ===<br />
<br />
== CVE-2013-4165 ==<br />
<br />
<b>Date:</b> 2013-07-20<br />
<b>Summary:</b> Timing leak in RPC authentication<br />
<b>Fix Deployment:</b> 99.9%<br />
{| class='wikitable'<br />
!colspan='2'| Affected !! Fix<br />
|-<br />
| Bitcoin-Qt<br>bitcoind || * - 0.4.9rc3<br>0.5.0rc1 - 0.5.8rc3<br>0.6.0rc1 - 0.6.5rc3<br>0.7.0rc1 - 0.7.3rc3<br>0.8.0rc1 - 0.8.3 || 0.4.9rc4<br>0.5.8rc4<br>0.6.5rc4<br>0.7.3rc4<br>0.8.4rc1<br />
|-<br />
| wxBitcoin || ALL || NONE<br />
|}<br />
<br />
=== References ===<br />
* [https://bitcointalk.org/index.php?topic=287351 Bitcoin-Qt 0.8.4 release notes]<br />
* [https://github.com/bitcoin/bitcoin/issues/2838 The initial bug report]<br />
<br />
== CVE-2013-5700 ==<br />
<br />
<b>Date:</b> 2013-09-04<br />
<b>Summary:</b> Remote p2p crash via bloom filters<br />
<b>Fix Deployment:</b> 99.9%<br />
{| class='wikitable'<br />
!colspan='2'| Affected !! Fix<br />
|-<br />
| Bitcoin-Qt<br>bitcoind || 0.8.0rc1 - 0.8.3 || 0.8.4rc1<br />
|}<br />
<br />
=== References ===<br />
* [https://bitcointalk.org/index.php?topic=287351 Bitcoin-Qt 0.8.4 release notes]<br />
* [https://github.com/bitcoin/bitcoin/commit/37c6389c5a0ca63ae3573440ecdfe95d28ad8f07 The fix]<br />
* [https://github.com/bitcoin/bitcoin/pull/18515 An added test]<br />
<br />
== CVE-2016-8889 ==<br />
<br />
<b>Date:</b> 2016-10-27<br />
<b>Summary:</b> Debug console history storing sensitive info<br />
<b>Fix Deployment:</b> 100%<br />
{| class='wikitable'<br />
!colspan='2'| Affected !! Fix<br />
|-<br />
| Bitcoin Knots GUI || 0.11.0 - 0.13.0 || 0.13.1<br />
|}<br />
<br />
=== References ===<br />
* [https://github.com/bitcoinknots/bitcoin/blob/v0.13.1.knots20161027/doc/release-notes.md Bitcoin Knots 0.16.1.knots20161027 release notes]<br />
* [https://nvd.nist.gov/vuln/detail/CVE-2016-8889 US-CERT/NIST]<br />
<br />
== CVE-2017-12842 ==<br />
<br />
<b>Date:</b> 2018-06-09<br />
<b>Summary:</b> No commitment to block merkle tree depth<br />
<br />
=== References ===<br />
* [https://bitslog.wordpress.com/2018/06/09/leaf-node-weakness-in-bitcoin-merkle-tree-design/ Explanation by Sergio Demian Lerner]<br />
* [https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2019-February/016697.html Further elaboration by Suhas Daftuar]<br />
<br />
== CVE-2017-18350 ==<br />
<br />
<b>Date:</b> 2019-06-22<br />
<b>Summary:</b> Buffer overflow from SOCKS proxy<br />
{| class='wikitable'<br />
!colspan='2'| Affected !! Fix<br />
|-<br />
| Bitcoin-Qt<br>bitcoind || 0.7.0rc1 - 0.15.0 || 0.15.1rc1<br />
|}<br />
<br />
=== References ===<br />
* [https://medium.com/@lukedashjr/cve-2017-18350-disclosure-fe6d695f45d5 Disclosure of details]<br />
<br />
== CVE-2018-17144 ==<br />
<br />
<b>Date:</b> 2018-09-17<br />
<b>Summary:</b> Missing check for duplicate inputs<br />
<b>Fix Deployment:</b> 31%<br />
{| class='wikitable'<br />
!colspan='2'| Affected !! Fix<br />
|-<br />
| Bitcoin-Qt<br>bitcoind || 0.14.0rc1 - 0.14.2<br>0.15.0rc1 - 0.15.1<br>0.16.0rc1 - 0.16.2 || 0.14.3<br>0.15.2<br>0.16.3<br />
|}<br />
<br />
=== References ===<br />
* [https://bitcoincore.org/en/2018/09/20/notice/ Full disclosure by Bitcoin Core]<br />
* [https://bitcoincore.org/en/2018/09/18/release-0.16.3/ Bitcoin Core 0.16.3 release notes]<br />
* [https://github.com/bitcoinknots/bitcoin/blob/v0.16.3.knots20180918/doc/release-notes.md Bitcoin Knots 0.16.3.knots20180918 release notes]<br />
* [https://nvd.nist.gov/vuln/detail/CVE-2018-17144 US-CERT/NIST]<br />
* [https://bugs.gentoo.org/show_bug.cgi?id=666669 Gentoo bug]<br />
<br />
== CVE-2018-20586 ==<br />
<br />
<b>Date:</b> 2019-06-22<br />
<b>Summary:</b> Debug log injection via unauthenticated RPC<br />
{| class='wikitable'<br />
!colspan='2'| Affected !! Fix<br />
|-<br />
| Bitcoin-Qt<br>bitcoind || 0.12.0rc1 - 0.17.0 || 0.17.1rc1<br />
|}<br />
<br />
== CVE-2020-14199 ==<br />
<br />
<b>Date:</b> 2020-06-03<br />
<b>Summary:</b> Double-signing can enable unintended fees<br />
{| class='wikitable'<br />
!colspan='2'| Affected !! Fix<br />
|-<br />
| Trezor One || || 1.9.1<br />
|-<br />
| Trezor Model T || || 2.3.1<br />
|-<br />
| ???<br />
|}<br />
<br />
=== References ===<br />
* [https://blog.trezor.io/details-of-firmware-updates-for-trezor-one-version-1-9-1-and-trezor-model-t-version-2-3-1-1eba8f60f2dd Disclosure of details by Trezor team]<br />
<br />
== CVE-2020-26895 ==<br />
<br />
<b>Date:</b> 2020-10-08<br />
<b>Summary:</b> Missing low-S normalization for HTLC signatures.<br />
<br />
{| class='wikitable'<br />
!colspan='2'| Affected !! Fix<br />
|-<br />
| lnd || || 0.10.0<br />
|}<br />
<br />
=== References ===<br />
* [https://lists.linuxfoundation.org/pipermail/lightning-dev/2020-October/002858.html CVE-2020-26895: LND Low-S Tx-Relay Standardness]<br />
* [https://lists.linuxfoundation.org/pipermail/lightning-dev/2020-October/002856.html Full Disclosure: Full Disclosure: CVE-2020-26895 LND "Hodl my Shitsig"]<br />
<br />
== CVE-2020-26896 ==<br />
<br />
<b>Date:</b> 2020-10-08<br />
<b>Summary:</b> Invoice preimage extraction via forwarded HTLC.<br />
<br />
{| class='wikitable'<br />
!colspan='2'| Affected !! Fix<br />
|-<br />
| lnd || || 0.11.0<br />
|}<br />
<br />
=== References ===<br />
* [https://lists.linuxfoundation.org/pipermail/lightning-dev/2020-October/002857.html CVE-2020-26896: LND Invoice Preimage Extraction]<br />
* [https://lists.linuxfoundation.org/pipermail/lightning-dev/2020-October/002855.html Full Disclosure: CVE-2020-26896 LND "The (un)covert channel"]<br />
<br />
== CVE-2021-3401 ==<br />
<br />
<b>Date:</b> 2021-02-01<br />
<b>Summary:</b> Qt5 remote execution<br />
<br />
{| class='wikitable'<br />
!colspan='2'| Affected !! Fix<br />
|-<br />
| Bitcoin Core GUI || || 0.19.0<br />
|-<br />
| Bitcoin Knots GUI || || 0.18.1<br />
|}<br />
<br />
== CVE-2021-31876 ==<br />
<br />
<b>Date:</b> 2021-05-06<br />
<br />
=== References ===<br />
<br />
* [https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-May/018893.html Full Disclosure: CVE-2021-31876 Defect in Bitcoin Core's bip125 logic]<br />
<br />
=== References ===<br />
* [https://achow101.com/2021/02/0.18-uri-vuln URI Argument Injection Vulnerability in Bitcoin Core 0.18 and Earlier]<br />
<br />
== CVE-2023-50428 ==<br />
<br />
<b>Date:</b> 2023<br />
<b>Summary:</b> Bypass of datacarriersize limit using OP_FALSE,OP_IF<br />
<br />
{| class='wikitable'<br />
!colspan='2'| Affected !! Fix<br />
|-<br />
| Bitcoin Core || 0.9 and later || NOT FIXED<br />
|-<br />
| Bitcoin Knots || 0.9 - 23.0 || 25.1.knots20231115<br />
|-<br />
| btcd || ? || NOT FIXED<br />
|-<br />
| libbitcoin || ? || NOT FIXED<br />
|}<br />
<br />
==Definitions==<br />
<br />
A critical vulnerability is one that will have disastrous consequences if it is exploited. A serious vulnerability is one that will have serious consequences if it is exploited<ref>[http://bitcointalk.org/index.php?topic=88892.0 http://bitcointalk.org/index.php?topic=88892.0]</ref>.<br />
<br />
==See Also==<br />
<br />
* [[Changelog]]<br />
* https://blog.bitmex.com/bitcoins-consensus-forks/<br />
<br />
==References==<br />
<references /><br />
<br />
[[Category:Security]]<br />
<br />
{{Bitcoin Core documentation}}</div>Hardinghttps://en.bitcoin.it/w/index.php?title=Script&diff=69733Script2023-06-29T01:52:36Z<p>Harding: /* Crypto */ add OP_CHECKSIGADD from taproot</p>
<hr />
<div>Bitcoin uses a scripting system for [[transactions]]. [[Wikipedia:FORTH|Forth]]-like, '''Script''' is simple, stack-based, and processed from left to right. It is intentionally not Turing-complete, with no loops.<br />
<br />
A script is essentially a list of instructions recorded with each transaction that describe how the next person wanting to spend the Bitcoins being transferred can gain access to them. The script for a typical Bitcoin transfer to destination Bitcoin address D simply encumbers future spending of the bitcoins with two things: the spender must provide<br />
# a public key that, when hashed, yields destination address D embedded in the script, and<br />
# a signature to prove ownership of the private key corresponding to the public key just provided.<br />
<br />
Scripting provides the flexibility to change the parameters of what's needed to spend transferred Bitcoins. For example, the scripting system could be used to require two private keys, or a combination of several keys, or even no keys at all.<br />
<br />
A transaction is valid if nothing in the combined script triggers failure and the top stack item is True (non-zero) when the script exits. The party that originally ''sent'' the Bitcoins now being spent dictates the script operations that will occur ''last'' in order to release them for use in another transaction. The party wanting to spend them must provide the input(s) to the previously recorded script that results in the combined script completing execution with a true value on the top of the stack.<br />
<br />
This document is for information purposes only. De facto, Bitcoin script is defined by the code run by the network to check the validity of blocks.<br />
<br />
The stacks hold byte vectors.<br />
When used as numbers, byte vectors are interpreted as little-endian variable-length integers with the most significant bit determining the sign of the integer.<br />
Thus 0x81 represents -1.<br />
0x80 is another representation of zero (so called negative 0).<br />
Positive 0 is represented by a null-length vector.<br />
Byte vectors are interpreted as Booleans where False is represented by any representation of zero and True is represented by any representation of non-zero.<br />
<br />
Leading zeros in an integer and negative zero are allowed in blocks but get rejected by the stricter requirements which standard full nodes put on transactions before retransmitting them.<br />
Byte vectors on the stack are not allowed to be more than 520 bytes long. Opcodes which take integers and bools off the stack require that they be no more than 4 bytes long, but addition and subtraction can overflow and result in a 5 byte integer being put on the stack.<br />
<br />
== Opcodes ==<br />
This is a list of all Script words, also known as opcodes, commands, or functions.<br />
<br />
There are some words which existed in very early versions of Bitcoin but were removed out of concern that the client might have a bug in their implementation. This fear was motivated by a bug found in OP_LSHIFT that could crash any Bitcoin node if exploited and by other bugs that allowed anyone to spend anyone's bitcoins. The removed opcodes are sometimes said to be "disabled", but this is something of a misnomer because there is ''absolutely no way'' for anyone using Bitcoin to use these opcodes (they simply ''do not exist anymore'' in the protocol), and there are also no solid plans to ever re-enable all of these opcodes. They are listed here for historical interest only.<br />
<br />
New opcodes can be added by means of a carefully designed and executed [[softfork]] using OP_NOP1-OP_NOP10.<br />
<br />
Zero, negative zero (using any number of bytes), and empty array are all treated as false. Anything else is treated as true.<br />
<br />
=== Notation on this page ===<br />
<br />
In the tables below, the inputs and outputs are both described by items as if they were pushed on the stack in that order. So for example, "x1 x2" indicates pushing value x1 on the stack, then x2, such that x1 is at the bottom of the stack, and x2 is at the top. <br />
<br />
=== Constants ===<br />
When talking about scripts, these value-pushing words are usually omitted.<br />
<br />
{| class="wikitable"<br />
|-<br />
!Word<br />
!Opcode<br />
!Hex<br />
!Input<br />
!Output<br />
!Description<br />
|-<br />
|OP_0, OP_FALSE<br />
|0<br />
|0x00<br />
|Nothing.<br />
|(empty value)<br />
|An empty array of bytes is pushed onto the stack. (This is not a no-op: an item is added to the stack.)<br />
|-<br />
|N/A<br />
|1-75<br />
|0x01-0x4b<br />
|(special)<br />
|data<br />
|The next ''opcode'' bytes is data to be pushed onto the stack<br />
|-<br />
|OP_PUSHDATA1<br />
|76<br />
|0x4c<br />
|(special)<br />
|data<br />
|The next byte contains the number of bytes to be pushed onto the stack.<br />
|-<br />
|OP_PUSHDATA2<br />
|77<br />
|0x4d<br />
|(special)<br />
|data<br />
|The next two bytes contain the number of bytes to be pushed onto the stack in little endian order.<br />
|-<br />
|OP_PUSHDATA4<br />
|78<br />
|0x4e<br />
|(special)<br />
|data<br />
|The next four bytes contain the number of bytes to be pushed onto the stack in little endian order.<br />
|-<br />
|OP_1NEGATE<br />
|79<br />
|0x4f<br />
|Nothing.<br />
| -1<br />
|The number -1 is pushed onto the stack.<br />
|-<br />
|OP_1, OP_TRUE<br />
|81<br />
|0x51<br />
|Nothing.<br />
|1<br />
|The number 1 is pushed onto the stack.<br />
|-<br />
|OP_2-OP_16<br />
|82-96<br />
|0x52-0x60<br />
|Nothing.<br />
|2-16<br />
|The number in the word name (2-16) is pushed onto the stack.<br />
|}<br />
<br />
=== Flow control ===<br />
<br />
{| class="wikitable"<br />
|-<br />
!Word<br />
!Opcode<br />
!Hex<br />
!Input<br />
!Output<br />
!Description<br />
|-<br />
|OP_NOP<br />
|97<br />
|0x61<br />
|Nothing<br />
|Nothing<br />
|Does nothing.<br />
|-<br />
|OP_IF<br />
|99<br />
|0x63<br />
| colspan="2"|<expression> if [statements] [else [statements]]* endif<br />
|If the top stack value is not False, the statements are executed. The top stack value is removed.<br />
|-<br />
|OP_NOTIF<br />
|100<br />
|0x64<br />
| colspan="2"|<expression> notif [statements] [else [statements]]* endif<br />
|If the top stack value is False, the statements are executed. The top stack value is removed.<br />
|-<br />
|OP_ELSE<br />
|103<br />
|0x67<br />
| colspan="2"|<expression> if [statements] [else [statements]]* endif<br />
|If the preceding OP_IF or OP_NOTIF or OP_ELSE was not executed then these statements are and if the preceding OP_IF or OP_NOTIF or OP_ELSE was executed then these statements are not. <br />
|-<br />
|OP_ENDIF<br />
|104<br />
|0x68<br />
| colspan="2"|<expression> if [statements] [else [statements]]* endif<br />
|Ends an if/else block. All blocks must end, or the transaction is '''invalid'''. An OP_ENDIF without OP_IF earlier is also '''invalid'''.<br />
|-<br />
|OP_VERIFY<br />
|105<br />
|0x69<br />
|True / false<br />
|Nothing / ''fail''<br />
|'''Marks transaction as invalid''' if top stack value is not true. The top stack value is removed.<br />
|-<br />
|[[OP_RETURN]]<br />
|106<br />
|0x6a<br />
|Nothing<br />
|''fail''<br />
|'''Marks transaction as invalid'''. Since bitcoin 0.9, a standard way of attaching extra data to transactions is to add a zero-value output with a scriptPubKey consisting of OP_RETURN followed by data. Such outputs are provably unspendable and specially discarded from storage in the UTXO set, reducing their cost to the network. Since [https://bitcoin.org/en/release/v0.12.0#relay-any-sequence-of-pushdatas-in-opreturn-outputs-now-allowed 0.12], standard relay rules allow a single output with OP_RETURN, that contains any sequence of push statements (or OP_RESERVED<ref>see code for IsPushOnly [https://github.com/bitcoin/bitcoin/blob/bccb4d29a8080bf1ecda1fc235415a11d903a680/src/script/script.cpp#L232]</ref>) after the OP_RETURN provided the total scriptPubKey length is at most 83 bytes.<br />
|}<br />
<br />
=== Stack ===<br />
<br />
{| class="wikitable" <br />
|-<br />
!Word<br />
!Opcode<br />
!Hex<br />
!Input<br />
!Output<br />
!Description<br />
|-<br />
|OP_TOALTSTACK<br />
|107<br />
|0x6b<br />
|x1<br />
|(alt)x1<br />
|Puts the input onto the top of the alt stack. Removes it from the main stack.<br />
|-<br />
|OP_FROMALTSTACK<br />
|108<br />
|0x6c<br />
|(alt)x1<br />
|x1<br />
|Puts the input onto the top of the main stack. Removes it from the alt stack.<br />
|-<br />
|OP_IFDUP<br />
|115<br />
|0x73<br />
|x<br />
|x / x x<br />
|If the top stack value is not 0, duplicate it.<br />
|-<br />
|OP_DEPTH<br />
|116<br />
|0x74<br />
|Nothing<br />
|<Stack size><br />
|Puts the number of stack items onto the stack.<br />
|-<br />
|OP_DROP<br />
|117<br />
|0x75<br />
|x<br />
|Nothing<br />
|Removes the top stack item.<br />
|-<br />
|OP_DUP<br />
|118<br />
|0x76<br />
|x<br />
|x x<br />
|Duplicates the top stack item.<br />
|-<br />
|OP_NIP<br />
|119<br />
|0x77<br />
|x1 x2<br />
|x2<br />
|Removes the second-to-top stack item.<br />
|-<br />
|OP_OVER<br />
|120<br />
|0x78<br />
|x1 x2<br />
|x1 x2 x1<br />
|Copies the second-to-top stack item to the top.<br />
|-<br />
|OP_PICK<br />
|121<br />
|0x79<br />
|xn ... x2 x1 x0 <n><br />
|xn ... x2 x1 x0 xn<br />
|The item ''n'' back in the stack is copied to the top.<br />
|-<br />
|OP_ROLL<br />
|122<br />
|0x7a<br />
|xn ... x2 x1 x0 <n><br />
|... x2 x1 x0 xn<br />
|The item ''n'' back in the stack is moved to the top.<br />
|-<br />
|OP_ROT<br />
|123<br />
|0x7b<br />
|x1 x2 x3<br />
|x2 x3 x1<br />
|The 3rd item down the stack is moved to the top.<br />
|-<br />
|OP_SWAP<br />
|124<br />
|0x7c<br />
|x1 x2<br />
|x2 x1<br />
|The top two items on the stack are swapped.<br />
|-<br />
|OP_TUCK<br />
|125<br />
|0x7d<br />
|x1 x2<br />
|x2 x1 x2<br />
|The item at the top of the stack is copied and inserted before the second-to-top item.<br />
|-<br />
|OP_2DROP<br />
|109<br />
|0x6d<br />
|x1 x2<br />
|Nothing<br />
|Removes the top two stack items.<br />
|-<br />
|OP_2DUP<br />
|110<br />
|0x6e<br />
|x1 x2<br />
|x1 x2 x1 x2<br />
|Duplicates the top two stack items.<br />
|-<br />
|OP_3DUP<br />
|111<br />
|0x6f<br />
|x1 x2 x3<br />
|x1 x2 x3 x1 x2 x3<br />
|Duplicates the top three stack items.<br />
|-<br />
|OP_2OVER<br />
|112<br />
|0x70<br />
|x1 x2 x3 x4<br />
|x1 x2 x3 x4 x1 x2<br />
|Copies the pair of items two spaces back in the stack to the front.<br />
|-<br />
|OP_2ROT<br />
|113<br />
|0x71<br />
|x1 x2 x3 x4 x5 x6<br />
|x3 x4 x5 x6 x1 x2<br />
|The fifth and sixth items back are moved to the top of the stack.<br />
|-<br />
|OP_2SWAP<br />
|114<br />
|0x72<br />
|x1 x2 x3 x4<br />
|x3 x4 x1 x2<br />
|Swaps the top two pairs of items.<br />
|}<br />
<br />
=== Splice ===<br />
<br />
If any opcode marked as disabled is present in a script, it must abort and fail.<br />
<br />
{| class="wikitable" <br />
|-<br />
!Word<br />
!Opcode<br />
!Hex<br />
!Input<br />
!Output<br />
!Description<br />
|-<br />
|OP_CAT<br />
|126<br />
|0x7e<br />
|x1 x2<br />
|out<br />
|style="background:#D97171;"|Concatenates two strings. ''disabled.''<br />
|-<br />
|OP_SUBSTR<br />
|127<br />
|0x7f<br />
|in begin size<br />
|out<br />
|style="background:#D97171;"|Returns a section of a string. ''disabled.''<br />
|-<br />
|OP_LEFT<br />
|128<br />
|0x80<br />
|in size<br />
|out<br />
|style="background:#D97171;"|Keeps only characters left of the specified point in a string. ''disabled.''<br />
|-<br />
|OP_RIGHT<br />
|129<br />
|0x81<br />
|in size<br />
|out<br />
|style="background:#D97171;"|Keeps only characters right of the specified point in a string. ''disabled.''<br />
|-<br />
|OP_SIZE<br />
|130<br />
|0x82<br />
|in<br />
|in size<br />
|Pushes the string length of the top element of the stack (without popping it).<br />
|}<br />
<br />
=== Bitwise logic ===<br />
<br />
If any opcode marked as disabled is present in a script, it must abort and fail.<br />
<br />
{| class="wikitable" <br />
|-<br />
!Word<br />
!Opcode<br />
!Hex<br />
!Input<br />
!Output<br />
!Description<br />
|-<br />
|OP_INVERT<br />
|131<br />
|0x83<br />
|in<br />
|out<br />
|style="background:#D97171;"|Flips all of the bits in the input. ''disabled.''<br />
|-<br />
|OP_AND<br />
|132<br />
|0x84<br />
|x1 x2<br />
|out<br />
|style="background:#D97171;"|Boolean ''and'' between each bit in the inputs. ''disabled.''<br />
|-<br />
|OP_OR<br />
|133<br />
|0x85<br />
|x1 x2<br />
|out<br />
|style="background:#D97171;"|Boolean ''or'' between each bit in the inputs. ''disabled.''<br />
|-<br />
|OP_XOR<br />
|134<br />
|0x86<br />
|x1 x2<br />
|out<br />
|style="background:#D97171;"|Boolean ''exclusive or'' between each bit in the inputs. ''disabled.''<br />
|-<br />
|OP_EQUAL<br />
|135<br />
|0x87<br />
|x1 x2<br />
|True / false<br />
|Returns 1 if the inputs are exactly equal, 0 otherwise.<br />
|-<br />
|OP_EQUALVERIFY<br />
|136<br />
|0x88<br />
|x1 x2<br />
|Nothing / ''fail''<br />
|Same as OP_EQUAL, but runs OP_VERIFY afterward.<br />
|}<br />
<br />
=== Arithmetic ===<br />
<br />
Note: Arithmetic inputs are limited to signed 32-bit integers, but may overflow their output.<br />
<br />
If any input value for any of these commands is longer than 4 bytes, the script must abort and fail. <br />
If any opcode marked as ''disabled'' is present in a script - it must also abort and fail.<br />
<br />
{| class="wikitable" <br />
|-<br />
!Word<br />
!Opcode<br />
!Hex<br />
!Input<br />
!Output<br />
!Description<br />
|-<br />
|OP_1ADD<br />
|139<br />
|0x8b<br />
|in<br />
|out<br />
|1 is added to the input.<br />
|-<br />
|OP_1SUB<br />
|140<br />
|0x8c<br />
|in<br />
|out<br />
|1 is subtracted from the input.<br />
|-<br />
|OP_2MUL<br />
|141<br />
|0x8d<br />
|in<br />
|out<br />
|style="background:#D97171;"|The input is multiplied by 2. ''disabled.''<br />
|-<br />
|OP_2DIV<br />
|142<br />
|0x8e<br />
|in<br />
|out<br />
|style="background:#D97171;"|The input is divided by 2. ''disabled.''<br />
|-<br />
|OP_NEGATE<br />
|143<br />
|0x8f<br />
|in<br />
|out<br />
|The sign of the input is flipped.<br />
|-<br />
|OP_ABS<br />
|144<br />
|0x90<br />
|in<br />
|out<br />
|The input is made positive.<br />
|-<br />
|OP_NOT<br />
|145<br />
|0x91<br />
|in<br />
|out<br />
|If the input is 0 or 1, it is flipped. Otherwise the output will be 0.<br />
|-<br />
|OP_0NOTEQUAL<br />
|146<br />
|0x92<br />
|in<br />
|out<br />
|Returns 0 if the input is 0. 1 otherwise.<br />
|-<br />
|OP_ADD<br />
|147<br />
|0x93<br />
|a b<br />
|out<br />
|a is added to b.<br />
|-<br />
|OP_SUB<br />
|148<br />
|0x94<br />
|a b<br />
|out<br />
|b is subtracted from a.<br />
|-<br />
|OP_MUL<br />
|149<br />
|0x95<br />
|a b<br />
|out<br />
|style="background:#D97171;"|a is multiplied by b. ''disabled.''<br />
|-<br />
|OP_DIV<br />
|150<br />
|0x96<br />
|a b<br />
|out<br />
|style="background:#D97171;"|a is divided by b. ''disabled.''<br />
|-<br />
|OP_MOD<br />
|151<br />
|0x97<br />
|a b<br />
|out<br />
|style="background:#D97171;"|Returns the remainder after dividing a by b. ''disabled.''<br />
|-<br />
|OP_LSHIFT<br />
|152<br />
|0x98<br />
|a b<br />
|out<br />
|style="background:#D97171;"|Shifts a left b bits, preserving sign. ''disabled.''<br />
|-<br />
|OP_RSHIFT<br />
|153<br />
|0x99<br />
|a b<br />
|out<br />
|style="background:#D97171;"|Shifts a right b bits, preserving sign. ''disabled.''<br />
|-<br />
|OP_BOOLAND<br />
|154<br />
|0x9a<br />
|a b<br />
|out<br />
|If both a and b are not 0, the output is 1. Otherwise 0.<br />
|-<br />
|OP_BOOLOR<br />
|155<br />
|0x9b<br />
|a b<br />
|out<br />
|If a or b is not 0, the output is 1. Otherwise 0.<br />
|-<br />
|OP_NUMEQUAL<br />
|156<br />
|0x9c<br />
|a b<br />
|out<br />
|Returns 1 if the numbers are equal, 0 otherwise.<br />
|-<br />
|OP_NUMEQUALVERIFY<br />
|157<br />
|0x9d<br />
|a b<br />
|Nothing / ''fail''<br />
|Same as OP_NUMEQUAL, but runs OP_VERIFY afterward.<br />
|-<br />
|OP_NUMNOTEQUAL<br />
|158<br />
|0x9e<br />
|a b<br />
|out<br />
|Returns 1 if the numbers are not equal, 0 otherwise.<br />
|-<br />
|OP_LESSTHAN<br />
|159<br />
|0x9f<br />
|a b<br />
|out<br />
|Returns 1 if a is less than b, 0 otherwise.<br />
|-<br />
|OP_GREATERTHAN<br />
|160<br />
|0xa0<br />
|a b<br />
|out<br />
|Returns 1 if a is greater than b, 0 otherwise.<br />
|-<br />
|OP_LESSTHANOREQUAL<br />
|161<br />
|0xa1<br />
|a b<br />
|out<br />
|Returns 1 if a is less than or equal to b, 0 otherwise.<br />
|-<br />
|OP_GREATERTHANOREQUAL<br />
|162<br />
|0xa2<br />
|a b<br />
|out<br />
|Returns 1 if a is greater than or equal to b, 0 otherwise.<br />
|-<br />
|OP_MIN<br />
|163<br />
|0xa3<br />
|a b<br />
|out<br />
|Returns the smaller of a and b.<br />
|-<br />
|OP_MAX<br />
|164<br />
|0xa4<br />
|a b<br />
|out<br />
|Returns the larger of a and b.<br />
|-<br />
|OP_WITHIN<br />
|165<br />
|0xa5<br />
|x min max<br />
|out<br />
|Returns 1 if x is within the specified range (left-inclusive), 0 otherwise.<br />
|}<br />
<br />
=== Crypto ===<br />
<br />
{| class="wikitable" <br />
|-<br />
!Word<br />
!Opcode<br />
!Hex<br />
!Input<br />
!Output<br />
!Description<br />
|-<br />
|OP_RIPEMD160<br />
|166<br />
|0xa6<br />
|in<br />
|hash<br />
|The input is hashed using RIPEMD-160.<br />
|-<br />
|OP_SHA1<br />
|167<br />
|0xa7<br />
|in<br />
|hash<br />
|The input is hashed using SHA-1.<br />
|-<br />
|OP_SHA256<br />
|168<br />
|0xa8<br />
|in<br />
|hash<br />
|The input is hashed using SHA-256.<br />
|-<br />
|OP_HASH160<br />
|169<br />
|0xa9<br />
|in<br />
|hash<br />
|The input is hashed twice: first with SHA-256 and then with RIPEMD-160.<br />
|-<br />
|OP_HASH256<br />
|170<br />
|0xaa<br />
|in<br />
|hash<br />
|The input is hashed two times with SHA-256.<br />
|-<br />
|OP_CODESEPARATOR<br />
|171<br />
|0xab<br />
|Nothing<br />
|Nothing<br />
|All of the signature checking words will only match signatures to the data after the most recently-executed OP_CODESEPARATOR.<br />
|-<br />
|[[OP_CHECKSIG]]<br />
|172<br />
|0xac<br />
|sig pubkey<br />
|True / false<br />
|The entire transaction's outputs, inputs, and script (from the most recently-executed OP_CODESEPARATOR to the end) are hashed. The signature used by OP_CHECKSIG must be a valid signature for this hash and public key. If it is, 1 is returned, 0 otherwise.<br />
|-<br />
|OP_CHECKSIGVERIFY<br />
|173<br />
|0xad<br />
|sig pubkey<br />
|Nothing / ''fail''<br />
|Same as OP_CHECKSIG, but OP_VERIFY is executed afterward.<br />
|-<br />
|OP_CHECKMULTISIG<br />
|174<br />
|0xae<br />
|x sig1 sig2 ... <number of signatures> pub1 pub2 <number of public keys><br />
|True / False<br />
|Compares the first signature against each public key until it finds an ECDSA match. Starting with the subsequent public key, it compares the second signature against each remaining public key until it finds an ECDSA match. The process is repeated until all signatures have been checked or not enough public keys remain to produce a successful result. All signatures need to match a public key. Because public keys are not checked again if they fail any signature comparison, signatures must be placed in the scriptSig using the same order as their corresponding public keys were placed in the scriptPubKey or redeemScript. If all signatures are valid, 1 is returned, 0 otherwise. Due to a bug, one extra unused value is removed from the stack.<br />
|-<br />
|OP_CHECKMULTISIGVERIFY<br />
|175<br />
|0xaf<br />
|x sig1 sig2 ... <number of signatures> pub1 pub2 ... <number of public keys><br />
|Nothing / ''fail''<br />
|Same as OP_CHECKMULTISIG, but OP_VERIFY is executed afterward.<br />
|-<br />
|OP_CHECKSIGADD<br />
|186<br />
|0xba<br />
|sig n pub<br />
|out<br />
|Three values are popped from the stack. The integer n is incremented by one and returned to the stack if the signature is valid for the public key and transaction. The integer n is returned to the stack unchanged if the signature is the empty vector (OP_0). In any other case, the script is invalid. This opcode is only available in tapscript.<ref>[https://github.com/bitcoin/bips/blob/master/bip-0342.mediawiki BIP342]</ref><br />
|}<br />
<br />
=== Locktime ===<br />
{| class="wikitable" <br />
|-<br />
!Word<br />
!Opcode<br />
!Hex<br />
!Input<br />
!Output<br />
!Description<br />
|-<br />
|OP_CHECKLOCKTIMEVERIFY (previously OP_NOP2)<br />
|177<br />
|0xb1<br />
|x<br />
|x / ''fail''<br />
|'''Marks transaction as invalid''' if the top stack item is greater than the transaction's nLockTime field, otherwise script evaluation continues as though an OP_NOP was executed. Transaction is also invalid if 1. the stack is empty; or 2. the top stack item is negative; or 3. the top stack item is greater than or equal to 500000000 while the transaction's nLockTime field is less than 500000000, or vice versa; or 4. the input's nSequence field is equal to 0xffffffff. The precise semantics are described in [https://github.com/bitcoin/bips/blob/master/bip-0065.mediawiki BIP 0065].<br />
|-<br />
|OP_CHECKSEQUENCEVERIFY (previously OP_NOP3)<br />
|178<br />
|0xb2<br />
|x<br />
|x / ''fail''<br />
|'''Marks transaction as invalid''' if the relative lock time of the input (enforced by [https://github.com/bitcoin/bips/blob/master/bip-0068.mediawiki BIP 0068] with nSequence) is not equal to or longer than the value of the top stack item. The precise semantics are described in [https://github.com/bitcoin/bips/blob/master/bip-0112.mediawiki BIP 0112].<br />
|}<br />
<br />
===Pseudo-words===<br />
These words are used internally for assisting with transaction matching. They are invalid if used in actual scripts.<br />
{| class="wikitable" <br />
|-<br />
!Word<br />
!Opcode<br />
!Hex<br />
!Description<br />
|-<br />
|OP_PUBKEYHASH<br />
|253<br />
|0xfd<br />
|Represents a public key hashed with OP_HASH160.<br />
|-<br />
|OP_PUBKEY<br />
|254<br />
|0xfe<br />
|Represents a public key compatible with OP_CHECKSIG.<br />
|-<br />
|OP_INVALIDOPCODE<br />
|255<br />
|0xff<br />
|Matches any opcode that is not yet assigned.<br />
|}<br />
<br />
=== Reserved words ===<br />
Any opcode not assigned is also reserved. Using an unassigned opcode makes the transaction '''invalid'''.<br />
<br />
{| class="wikitable" <br />
|-<br />
!Word<br />
!Opcode<br />
!Hex<br />
!When used...<br />
|-<br />
|OP_RESERVED<br />
|80<br />
|0x50<br />
|'''Transaction is invalid''' unless occuring in an unexecuted OP_IF branch<br />
|-<br />
|OP_VER<br />
|98<br />
|0x62<br />
|'''Transaction is invalid''' unless occuring in an unexecuted OP_IF branch<br />
|-<br />
|OP_VERIF<br />
|101<br />
|0x65<br />
|'''Transaction is invalid even when occuring in an unexecuted OP_IF branch'''<br />
|-<br />
|OP_VERNOTIF<br />
|102<br />
|0x66<br />
|'''Transaction is invalid even when occuring in an unexecuted OP_IF branch'''<br />
|-<br />
|OP_RESERVED1<br />
|137<br />
|0x89<br />
|'''Transaction is invalid''' unless occuring in an unexecuted OP_IF branch<br />
|-<br />
|OP_RESERVED2<br />
|138<br />
|0x8a<br />
|'''Transaction is invalid''' unless occuring in an unexecuted OP_IF branch<br />
|-<br />
|OP_NOP1, OP_NOP4-OP_NOP10<br />
|176, 179-185<br />
|0xb0, 0xb3-0xb9<br />
|The word is ignored. Does not mark transaction as invalid.<br />
|}<br />
<br />
== Script examples ==<br />
The following is a list of interesting scripts.<br />
When notating scripts, data to be pushed to the stack is generally enclosed in angle brackets<br />
and data push commands are omitted.<br />
Non-bracketed words are opcodes.<br />
These examples include the “OP_” prefix, but it is permissible to omit it.<br />
Thus<br />
“<pubkey1> <pubkey2> OP_2 OP_CHECKMULTISIG”<br />
may be abbreviated to<br />
“<pubkey1> <pubkey2> 2 CHECKMULTISIG”.<br />
Note that there is a small number of standard script forms that are relayed from node to node;<br />
non-standard scripts are accepted if they are in a block, but nodes will not relay them.<br />
<br />
=== Standard Transaction to Bitcoin address (pay-to-pubkey-hash) ===<br />
<br />
scriptPubKey: OP_DUP OP_HASH160 <pubKeyHash> OP_EQUALVERIFY OP_CHECKSIG<br />
scriptSig: <sig> <pubKey><br />
<br />
To demonstrate how scripts look on the wire, here is a raw scriptPubKey:<br />
<pre> 76 A9 14<br />
OP_DUP OP_HASH160 Bytes to push<br />
<br />
89 AB CD EF AB BA AB BA AB BA AB BA AB BA AB BA AB BA AB BA 88 AC<br />
Data to push OP_EQUALVERIFY OP_CHECKSIG</pre><br />
<br />
Note: scriptSig is in the input of the spending transaction and scriptPubKey is in the output of the previously unspent i.e. "available" transaction.<br />
<br />
Here is how each word is processed:<br />
{| class="wikitable" <br />
|-<br />
! Stack <br />
! Script <br />
! Description <br />
|-<br />
|Empty.<br />
| <sig> <pubKey> OP_DUP OP_HASH160 <pubKeyHash> OP_EQUALVERIFY OP_CHECKSIG <br />
| scriptSig and scriptPubKey are combined.<br />
|-<br />
|<sig> <pubKey><br />
| OP_DUP OP_HASH160 <pubKeyHash> OP_EQUALVERIFY OP_CHECKSIG <br />
| Constants are added to the stack.<br />
|-<br />
|<sig> <pubKey> <pubKey><br />
| OP_HASH160 <pubKeyHash> OP_EQUALVERIFY OP_CHECKSIG <br />
| Top stack item is duplicated.<br />
|-<br />
|<sig> <pubKey> <pubHashA><br />
|<pubKeyHash> OP_EQUALVERIFY OP_CHECKSIG<br />
| Top stack item is hashed.<br />
|-<br />
|<sig> <pubKey> <pubHashA> <pubKeyHash><br />
|OP_EQUALVERIFY OP_CHECKSIG<br />
| Constant added.<br />
|-<br />
|<sig> <pubKey><br />
|OP_CHECKSIG<br />
| Equality is checked between the top two stack items.<br />
|-<br />
|true<br />
|Empty.<br />
|Signature is checked for top two stack items.<br />
|}<br />
<br />
=== Obsolete pay-to-pubkey transaction ===<br />
<br />
OP_CHECKSIG is used directly without first hashing the public key.<br />
This was used by early versions of Bitcoin where people paid directly to IP addresses, before Bitcoin addresses were introduced.<br />
scriptPubKeys of this transaction form are still recognized as payments to user by Bitcoin Core.<br />
The disadvantage of this transaction form is that the whole public key needs to be known in advance, implying longer payment addresses, and that it provides less protection in the event of a break in the ECDSA signature algorithm.<br />
<br />
scriptPubKey: <pubKey> OP_CHECKSIG<br />
scriptSig: <sig><br />
<br />
Checking process:<br />
{| class="wikitable" <br />
|-<br />
! Stack <br />
! Script <br />
! Description <br />
|-<br />
|Empty.<br />
|<sig> <pubKey> OP_CHECKSIG<br />
|scriptSig and scriptPubKey are combined.<br />
|-<br />
|<sig> <pubKey><br />
| OP_CHECKSIG<br />
|Constants are added to the stack.<br />
|-<br />
|true<br />
|Empty.<br />
|Signature is checked for top two stack items.<br />
|}<br />
<br />
=== Provably Unspendable/Prunable Outputs ===<br />
<br />
The standard way to mark a transaction as provably unspendable is with a scriptPubKey of the following form:<br />
<br />
scriptPubKey: OP_RETURN {zero or more ops}<br />
<br />
OP_RETURN immediately marks the script as invalid, guaranteeing that no scriptSig exists that could possibly spend that output. Thus the output can be immediately pruned from the [[UTXO|UTXO set]] even if it has not been spent. [http://blockexplorer.com/tx/eb31ca1a4cbd97c2770983164d7560d2d03276ae1aee26f12d7c2c6424252f29 eb31ca1a4cbd97c2770983164d7560d2d03276ae1aee26f12d7c2c6424252f29] is an example: it has a single output of zero value, thus giving the full 0.125BTC fee to the miner who mined the transaction without adding an entry to the UTXO set. You can also use OP_RETURN to add data to a transaction without the data ever appearing in the UTXO set, as seen in 1a2e22a717d626fc5db363582007c46924ae6b28319f07cb1b907776bd8293fc; [[P2Pool]] does this with the share chain hash txout in the coinbase of blocks it creates.<br />
<br />
=== Freezing funds until a time in the future ===<br />
<br />
Using OP_CHECKLOCKTIMEVERIFY it is possible to make funds provably unspendable until a certain point in the future.<br />
<br />
scriptPubKey: <expiry time> OP_CHECKLOCKTIMEVERIFY OP_DROP OP_DUP OP_HASH160 <pubKeyHash> OP_EQUALVERIFY OP_CHECKSIG<br />
scriptSig: <sig> <pubKey><br />
<br />
{| class="wikitable" <br />
|-<br />
! Stack <br />
! Script <br />
! Description <br />
|-<br />
|Empty.<br />
| <sig> <pubKey> <expiry time> OP_CHECKLOCKTIMEVERIFY OP_DROP OP_DUP OP_HASH160 <pubKeyHash> OP_EQUALVERIFY OP_CHECKSIG <br />
| scriptSig and scriptPubKey are combined.<br />
|-<br />
|<sig> <pubKey> <expiry time><br />
| OP_CHECKLOCKTIMEVERIFY OP_DROP OP_DUP OP_HASH160 <pubKeyHash> OP_EQUALVERIFY OP_CHECKSIG <br />
| Constants are added to the stack.<br />
|-<br />
|<sig> <pubKey> <expiry time><br />
| OP_DROP OP_DUP OP_HASH160 <pubKeyHash> OP_EQUALVERIFY OP_CHECKSIG <br />
| Top stack item is checked against the current time or block height.<br />
|-<br />
|<sig> <pubKey><br />
| OP_DUP OP_HASH160 <pubKeyHash> OP_EQUALVERIFY OP_CHECKSIG <br />
| Top stack item is removed.<br />
|-<br />
|<sig> <pubKey> <pubKey><br />
| OP_HASH160 <pubKeyHash> OP_EQUALVERIFY OP_CHECKSIG <br />
| Top stack item is duplicated.<br />
|-<br />
|<sig> <pubKey> <pubHashA><br />
|<pubKeyHash> OP_EQUALVERIFY OP_CHECKSIG<br />
| Top stack item is hashed.<br />
|-<br />
|<sig> <pubKey> <pubHashA> <pubKeyHash><br />
|OP_EQUALVERIFY OP_CHECKSIG<br />
| Constant added.<br />
|-<br />
|<sig> <pubKey><br />
|OP_CHECKSIG<br />
| Equality is checked between the top two stack items.<br />
|-<br />
|true<br />
|Empty.<br />
|Signature is checked for top two stack items.<br />
|}<br />
<br />
=== Transaction puzzle ===<br />
<br />
Transaction a4bfa8ab6435ae5f25dae9d89e4eb67dfa94283ca751f393c1ddc5a837bbc31b is an interesting puzzle.<br />
<br />
scriptPubKey: OP_HASH256 6fe28c0ab6f1b372c1a6a246ae63f74f931e8365e15a089c68d6190000000000 OP_EQUAL<br />
scriptSig: <data><br />
<br />
To spend the transaction you need to come up with some data such that hashing the data twice results in the given hash.<br />
<br />
{| class="wikitable" <br />
|-<br />
! Stack <br />
! Script <br />
! Description <br />
|-<br />
|Empty.<br />
|<data> OP_HASH256 <given_hash> OP_EQUAL<br />
|<br />
|-<br />
|<data><br />
|OP_HASH256 <given_hash> OP_EQUAL<br />
|scriptSig added to the stack.<br />
|-<br />
|<data_hash><br />
|<given_hash> OP_EQUAL<br />
|The data is hashed.<br />
|-<br />
|<data_hash> <given_hash><br />
|OP_EQUAL<br />
|The given hash is pushed to the stack.<br />
|-<br />
|true<br />
|Empty.<br />
|The hashes are compared, leaving true on the stack.<br />
|}<br />
<br />
This transaction was successfully spent by 09f691b2263260e71f363d1db51ff3100d285956a40cc0e4f8c8c2c4a80559b1. The required data happened to be the [[Genesis block]], and the given hash in the script was the genesis block header hashed twice with SHA-256. Note that while transactions like this are fun, they are not secure, because they do not contain any signatures and thus any transaction attempting to spend them can be replaced with a different transaction sending the funds somewhere else.<br />
<br />
=== Incentivized finding of hash collisions ===<br />
<br />
In 2013 Peter Todd created scripts that result in true if a hash collision is found. Bitcoin addresses resulting from these scripts can have money sent to them. If someone finds a hash collision they can spend the bitcoins on that address, so this setup acts as an incentive for somebody to do so.<br />
<br />
For example the SHA1 script:<br />
<br />
scriptPubKey: OP_2DUP OP_EQUAL OP_NOT OP_VERIFY OP_SHA1 OP_SWAP OP_SHA1 OP_EQUAL<br />
scriptSig: <preimage1> <preimage2><br />
<br />
See the bitcointalk thread <ref>[https://bitcointalk.org/index.php?topic=293382.0 bitcointalk forum thread on the hash collision bounties]</ref> and reddit thread<ref>https://www.reddit.com/r/Bitcoin/comments/1mavh9/trustless_bitcoin_bounty_for_sha1_sha256_etc/</ref> for more details.<br />
<br />
In February 2017 the SHA1 bounty worth 2.48 bitcoins was claimed.<br />
<br />
==See Also==<br />
<br />
* [[Transactions]]<br />
* [[Contracts]]<br />
<br />
== External Links ==<br />
*[https://bitcoin.sipa.be/miniscript] - Miniscript: a language for writing (a subset of) Bitcoin Scripts in a structured way, enabling analysis, composition, generic signing and more.<br />
*[https://github.com/siminchen/bitcoinIDE Bitcoin IDE] – Bitcoin Script for dummies<br />
*[https://webbtc.com/script Bitcoin Debug Script Execution] – web tool which executes a script opcode-by-opcode<br />
*[http://www.crmarsh.com/script-playground/ Script Playground] — convert Script to JavaScript<br />
*[https://bitauth.com/ide BitAuth IDE] — an Integrated Development Environment for Bitcoin Authentication<br />
<sup>(cf. "[http://bitcoin.stackexchange.com/q/42576/4334 Online Bitcoin Script simulator or debugger?]")</sup><br />
<br />
==References==<br />
<references /><br />
<br />
[[Category:Technical]]<br />
[[Category:Vocabulary]]<br />
<br />
{{Bitcoin Core documentation}}</div>Hardinghttps://en.bitcoin.it/w/index.php?title=IRC_channels&diff=68908IRC channels2021-09-16T19:17:15Z<p>Harding: /* Bitcoin Project */ Add new log for Bitcoin Core Dev, plus an anchor</p>
<hr />
<div>This page lists IRC channels for discussing Bitcoin-related topics. Please read: [[Bitcoin IRC Channel Guidelines]] before joining.<br />
<br />
Most of the channels are either on [https://libera.chat Libera.chat] or on [http://www.freenode.net Freenode] IRC networks.<br />
<br />
==Bitcoin Project==<br />
{| class="wikitable"<br />
! Channel !! Description<br />
|-<br />
| {{Freenode IRC|bitcoin}} (on Freenode) || General Bitcoin-related discussion and support. ([[Bitcoin_IRC_Channel_Guidelines |guidelines]]).<br />
|-<br />
| {{Libera IRC|bitcoin}} (on Libera) || General Bitcoin-related discussion and support. ([[Bitcoin_IRC_Channel_Guidelines |guidelines]]).<br />
|-<br />
| {{Libera IRC|bitcoin-core-builds}} || Discussion of the Bitcoin Core build system.<br />
|-<br />
| {{Freenode IRC|bitcoin-commits}} || Real-time notification of commits to Bitcoin projects.<br />
|-<br />
| <span id="bitcoin-core-dev"></span>{{Libera IRC|bitcoin-core-dev}} || For development of Bitcoin Core. Log sources; [http://www.erisian.com.au/bitcoin-core-dev/ 1], [http://gnusha.org/bitcoin-core-dev/ 2] [https://bitcoin-irc.chaincode.com/bitcoin-core-dev/2021-09-16 3]<br />
|-<br />
| {{Libera IRC|bitcoin-core-gui}} || For development of Bitcoin Core's GUI.<br />
|-<br />
| {{Libera IRC|bitcoin-core-pr-reviews}} || Weekly PR review club for discussing Bitcoin Core Pull Requests.<br />
|-<br />
| {{Freenode IRC|bitcoin-dev}} || For general Bitcoin software development. ([http://bitcoinstats.com/irc/bitcoin-dev/logs/ history]. [[Bitcoin-dev | guidelines]])<br />
|-<br />
| {{Freenode IRC|bitcoin-gaming}} || Bitcoin gamers hangout.<br />
|-<br />
| {{Freenode IRC|bitcoin-gentoo}} || Gentoo community.<br />
|-<br />
| {{Freenode IRC|bitcoin-marketing}} || Marketing and promotion of bitcoin<br />
|-<br />
| {{Libera IRC|bitcoin-news}} || RSS News related to Bitcoin.<br />
|-<br />
| {{Freenode IRC|bitcoin-politics}} || Discuss politics with other Bitcoin users.<br />
|-<br />
| {{Freenode IRC|bitcoin-pricetalk}} (on Freenode) || ALL Discussion Remotely Related to Bitcoin Price or other offtopic goes here<br />
|-<br />
| {{Libera IRC|bitcoin-pricetalk}} (on Libera) || ALL Discussion Remotely Related to Bitcoin Price or other offtopic goes here<br />
|-<br />
| {{Freenode IRC|bitcoin-watch|text=[[Bitcoin-Watch|#bitcoin-watch]]}} || Streaming Bitcoin transactions, including market data.<br />
|-<br />
| {{Freenode IRC|bitcoin-wiki}} || Bitcoin Wiki support<br />
|-<br />
| {{Freenode IRC|bitcoin-wizards}} (on Freenode) || Bitcoin experts and futurists ([http://gnusha.org/bitcoin-wizards/ history])<br />
|-<br />
| {{Libera IRC|bitcoin-wizards}} (on Libera) || Bitcoin experts and futurists ([http://gnusha.org/bitcoin-wizards/ history])<br />
|-<br />
| {{Libera IRC|lightning-dev}} || Lightning protocol development ([http://gnusha.org/lightning-dev/ history])<br />
|-<br />
| {{Freenode IRC|lnd}} || Lightning only version of #bitcoin-commits<br />
|-<br />
| {{Freenode IRC|sidechains-dev}} || Sidechains development<br />
|}<br />
<br />
===Local communities===<br />
<br />
{| class="wikitable"<br />
| {{Freenode IRC|bitcoin-aus}} || Aussie bitcoin community.<br />
|-<br />
| {{Freenode IRC|AustinBitcoin}} || Austin, TX bitcoin community.<br />
|-<br />
| {{Freenode IRC|bitcoin-bra}} || Brazilian bitcoin community.<br />
|-<br />
| {{Freenode IRC|bitcoin-cad}} || Canadian bitcoin community.<br />
|-<br />
| {{Freenode IRC|bitcoin-cn}} || Chinese bitcoin community.<br />
|-<br />
| {{Freenode IRC|bitcoin-dk}} || Danish bitcoin community.<br />
|-<br />
| {{Libera IRC|bitcoin-de}} || German bitcoin community.<br />
|-<br />
| {{Freenode IRC|bitcoin-eastcoastusa}} || East Coast USA bitcoin community.<br />
|-<br />
| {{Freenode IRC|bitcoin-il}} || Israeli bitcoin community.<br />
|-<br />
| {{Freenode IRC|bitcoin-nl}} || Dutch bitcoin community. <br />
|-<br />
| {{Freenode IRC|bitcoin-pl}} || Polish bitcoin community.<br />
|-<br />
| {{Freenode IRC|bitcoin-romania}} || Romanian bitcoin community.<br />
|-<br />
| {{Freenode IRC|bitcoin-ve}} || Venezuelan bitcoin community.<br />
|-<br />
| {{Freenode IRC|btc.chat}} || Russian bitcoin community.<br />
|-<br />
| #bitcoins.fi @ IRCNet || Finnish bitcoin community.<br />
|-<br />
| {{Libera IRC|bitcoin-hr}} || Croatian language bitcoin community.<br />
|-<br />
| {{Libera IRC|bitcoin-fr}} || French language bitcoin community.<br />
<br />
|}<br />
<br />
==Mining Related Communities==<br />
<br />
{| class="wikitable"<br />
! Channel !! Description<br />
|-<br />
| {{Freenode IRC|avalon}} || Discussion and support specific to [[Avalon]] mining machine<br />
|-<br />
| {{Freenode IRC|bitcoin-mining}} || Discussion and support related to mining.<br />
|-<br />
| {{Freenode IRC|bitcoin-fpga}} || Discussion and support specific to FPGA mining.<br />
|-<br />
| {{Freenode IRC|btcguild}} || [[BTCGuild]] mining pool community<br />
|-<br />
| {{Freenode IRC|butterflylabs}} || [[Butterfly Labs]] chat<br />
|-<br />
| {{Freenode IRC|cgminer}} || Discussion and support specific to [[CGMiner]].<br />
|-<br />
| {{Freenode IRC|eligius}} || [[Eligius]] mining pool community (also support for [[BFGMiner]] and [[Eloipool]])<br />
|-<br />
| {{Freenode IRC|mining.bitcoin.cz}} || Slush's mining pool community<br />
|-<br />
| {{Freenode IRC|ozcoin}} || [[Ozco.in]] mining pool community<br />
|-<br />
| <small>[irc://irc.foonetic.net/xkcd-bitcoin IRC] [http://irc.lc/foonetic/xkcd-bitcoin/Miner@@@ Web]</small> #xkcd-bitcoin || [https://en.bitcoin.it/wiki/XKCD_Pool XKCD Pool]<br />
|-<br />
| <small>[irc://irc.quakenet.org/bitcoins.lc IRC] [http://irc.lc/quakenet/bitcoins.lc/Miner@@@ Web]</small> #bitcoins.lc @ Quakenet || [http://www.bitcoins.lc Bitcoins.lc Pool] <br />
|-<br />
| {{Freenode IRC|p2pool}} || [[P2Pool]] decentralized mining pool<br />
|-<br />
| {{Freenode IRC|bitminter}} || [[BitMinter]] Mining Pool Community<br />
|-<br />
| {{Freenode IRC|kncminer}} || [[KNCMiner]] ASIC Mining Hardware Vendor Discussion<br />
|}<br />
<br />
==Communities for Exchanges and Trading==<br />
<br />
{| class="wikitable"<br />
! Channel !! Description<br />
|-<br />
| {{Freenode IRC|bitcoin-assets}} || Discussion of securities and other asset investments. [http://bitcoin-assets.com bitcoin-assets.com].<br />
|-<br />
| {{Freenode IRC|bitcoin-assets-trades}} || Streaming assets market data (only), no chat.<br />
|-<br />
| {{Freenode IRC|bitcoin-auction}} || Live auctions over IRC.<br />
|-<br />
| {{Libera IRC|bitcoin-market}} || Streaming market data (only), no chat.<br />
|-<br />
| {{Libera IRC|bitcoin-otc|text=[[bitcoin-otc|#bitcoin-otc]]}} || Over-the-counter trading marketplace and discussion. ([http://bitcoinstats.com/irc/bitcoin-otc/logs/ history])<br />
|-<br />
| {{Freenode IRC|bitcoin-escrow}} || Third party escrow agents.<br />
|-<br />
| {{Libera IRC|bitcoin-otc-ticker}} || Streaming market data form the [[#bitcoin-otc]] order book.<br />
|-<br />
| {{Libera IRC|bitcoin-otc-ratings|bitcoin-otc-ratings}} || Updates to ratings on the [[#bitcoin-otc]] Web of Trust.<br />
|-<br />
| {{Libera IRC|bitcoin-pit}} || Only over-the-counter trading.<br />
|-<br />
| {{Freenode IRC|btc.chat.traders}} || Russian community discussion about trades/exchanges.<br />
|-<br />
| {{Freenode IRC|coinbase}} || [[Coinbase]] chat<br />
|-<br />
| {{Freenode IRC|bitcoin-rt}} || Real-time tape (executed trades).<br />
|-<br />
| {{Freenode IRC|localbitcoins-chat}} || [[LocalBitcoins.com]] exchange support<br />
|}<br />
<br />
==Related Communities==<br />
<br />
{| class="wikitable"<br />
! Channel !! Description<br />
|-<br />
| {{Freenode IRC|opentransactions}} || [[Open Transactions]] project.<br />
|-<br />
| {{Freenode IRC|namecoin}} || [[Namecoin]] and the [[Dot-bit]] project.<br />
|-<br />
| {{Freenode IRC|twister}} || [[Twister]], P2P microblogging discussion.<br />
|-<br />
| {{Libera IRC|joinmarket}} || [[JoinMarket]], A [[CoinJoin]] implementation<br />
|-<br />
| {{Freenode IRC|darkwallet}} || [[DarkWallet]] and libbitcoin/Obelisk discussion & development channel.<br />
|-<br />
| {{Freenode IRC|electrum}} || [[Electrum]], lightweight bitcoin client.<br />
|-<br />
| {{Freenode IRC|copay}} || [[Copay]], lightweight bitcoin client.<br />
|-<br />
| {{Freenode IRC|bitcoin-stackexchange}} || Discussion complementing [http://bitcoin.stackexchange.com Bitcoin StackExchange].<br />
<br />
|}<br />
<br />
==See Also==<br />
<br />
* [[Bitcoin_Wiki:Community_portal]]<br />
<br />
[[fr:Canaux IRC]]<br />
[[pl:Kanały IRC]]<br />
[[ro:Canale]]</div>Hardinghttps://en.bitcoin.it/w/index.php?title=IRC_channels&diff=68672IRC channels2021-05-27T03:12:05Z<p>Harding: /* Bitcoin Project */ Updated #lightning-dev to Libera per Rusty Russell in that chatroom</p>
<hr />
<div>This page lists IRC channels for discussing Bitcoin-related topics. Please read: [[Bitcoin IRC Channel Guidelines]] before joining.<br />
<br />
Prior to late May 2021, most of these channels were on the [https://freenode.net/ Freenode] network. Due to an [https://gist.github.com/joepie91/df80d8d36cd9d1bde46ba018af497409 Ownership dispute over Freenode], several have moved to [https://libera.chat Libera.chat], with a few others planning to move by early June. If you join a channel at the Freenode address listed below and don't find any activity within a reasonable amount of time, try the same channel on Libera or ask for help in <tt>#bitcoin</tt> on Libera.<br />
<br />
==Bitcoin Project==<br />
{| class="wikitable"<br />
! Channel !! Description<br />
|-<br />
| {{Libera IRC|bitcoin}} || General Bitcoin-related discussion and support. ([[Bitcoin_IRC_Channel_Guidelines | guidelines]]).<br />
|-<br />
| {{Libera IRC|bitcoin-core-builds}} || Discussion of the Bitcoin Core build system.<br />
|-<br />
| {{Freenode IRC|bitcoin-commits}} || Real-time notification of commits to Bitcoin projects.<br />
|-<br />
| {{Libera IRC|bitcoin-core-dev}} || For development of Bitcoin Core. Log sources; [http://www.erisian.com.au/bitcoin-core-dev/ 1], [http://gnusha.org/bitcoin-core-dev/ 2]<br />
|-<br />
| {{Libera IRC|bitcoin-core-gui}} || For development of Bitcoin Core's GUI.<br />
|-<br />
| {{Libera IRC|bitcoin-core-pr-reviews}} || Weekly PR review club for discussing Bitcoin Core Pull Requests.<br />
|-<br />
| {{Freenode IRC|bitcoin-dev}} || Dead. Formerly for Bitcoin software development. ([http://bitcoinstats.com/irc/bitcoin-dev/logs/ history]. [[Bitcoin-dev | guidelines]])<br />
|-<br />
| {{Freenode IRC|bitcoin-gaming}} || Bitcoin gamers hangout.<br />
|-<br />
| {{Freenode IRC|bitcoin-gentoo}} || Gentoo community.<br />
|-<br />
| {{Freenode IRC|bitcoin-marketing}} || Marketing and promotion of bitcoin<br />
|-<br />
| {{Freenode IRC|bitcoin-news}} || RSS News related to Bitcoin.<br />
|-<br />
| {{Freenode IRC|bitcoin-politics}} || Discuss politics with other Bitcoin users.<br />
|-<br />
| {{Freenode IRC|#bitcoin-pricetalk|text=&#35;bitcoin-pricetalk}} || ALL Discussion Remotely Related to Bitcoin Price or other offtopic goes here<br />
|-<br />
| {{Freenode IRC|bitcoin-watch|text=[[Bitcoin-Watch|#bitcoin-watch]]}} || Streaming Bitcoin transactions, including market data.<br />
|-<br />
| {{Libera IRC|bitcoin-wiki}} || Bitcoin Wiki support<br />
|-<br />
| {{Libera IRC|bitcoin-wizards}} || Bitcoin experts and futurists ([http://gnusha.org/bitcoin-wizards/ history])<br />
|-<br />
| {{Libera IRC|lightning-dev}} || Lightning protocol development ([http://gnusha.org/lightning-dev/ history])<br />
|-<br />
| {{Freenode IRC|lnd}} || Lightning only version of #bitcoin-commits<br />
|-<br />
| {{Freenode IRC|sidechains-dev}} || Sidechains development<br />
|}<br />
<br />
===Local communities===<br />
<br />
{| class="wikitable"<br />
| {{Freenode IRC|bitcoin-otc-eu}} || European OTC trading marketplace.<br />
|-<br />
| {{Freenode IRC|bitcoin-otc-ru}} || Russian OTC trading marketplace.<br />
|-<br />
| {{Freenode IRC|bitcoin-otc-uk}} ||United kingdom OTC Trading Marketplace.Founder Angus Bates.<br />
|-<br />
| {{Freenode IRC|bitcoin-aus}} || Aussie bitcoin community.<br />
|-<br />
| {{Freenode IRC|AustinBitcoin}} || Austin, TX bitcoin community.<br />
|-<br />
| {{Freenode IRC|bitcoin-bra}} || Brazilian bitcoin community.<br />
|-<br />
| {{Freenode IRC|bitcoin-cad}} || Canadian bitcoin community.<br />
|-<br />
| {{Freenode IRC|bitcoin-cn}} || Chinese bitcoin community.<br />
|-<br />
| {{Freenode IRC|bitcoin-dk}} || Danish bitcoin community.<br />
|-<br />
| {{Freenode IRC|bitcoin-de}} || German bitcoin community.<br />
|-<br />
| {{Freenode IRC|bitcoin-eastcoastusa}} || East Coast USA bitcoin community.<br />
|-<br />
| {{Freenode IRC|bitcoin-il}} || Israeli bitcoin community.<br />
|-<br />
| {{Freenode IRC|bitcoin-nl}} || Dutch bitcoin community. <br />
|-<br />
| {{Freenode IRC|bitcoin-pl}} || Polish bitcoin community.<br />
|-<br />
| {{Freenode IRC|bitcoin-romania}} || Romanian bitcoin community.<br />
|-<br />
| {{Freenode IRC|bitcoin-ve}} || Venezuelan bitcoin community.<br />
|-<br />
| {{Freenode IRC|btc.chat}} || Russian bitcoin community.<br />
|-<br />
| #bitcoins.fi @ IRCNet || Finnish bitcoin community.<br />
|-<br />
| {{Freenode IRC|bitcoin-hr}} || Croatian language bitcoin community.<br />
<br />
|}<br />
<br />
==Mining Related Communities==<br />
<br />
{| class="wikitable"<br />
! Channel !! Description<br />
|-<br />
| {{Freenode IRC|avalon}} || Discussion and support specific to [[Avalon]] mining machine<br />
|-<br />
| {{Freenode IRC|bitcoin-mining}} || Discussion and support related to mining.<br />
|-<br />
| {{Freenode IRC|bitcoin-fpga}} || Discussion and support specific to FPGA mining.<br />
|-<br />
| {{Freenode IRC|btcguild}} || [[BTCGuild]] mining pool community<br />
|-<br />
| {{Freenode IRC|butterflylabs}} || [[Butterfly Labs]] chat<br />
|-<br />
| {{Freenode IRC|cgminer}} || Discussion and support specific to [[CGMiner]].<br />
|-<br />
| {{Freenode IRC|eligius}} || [[Eligius]] mining pool community (also support for [[BFGMiner]] and [[Eloipool]])<br />
|-<br />
| {{Freenode IRC|mining.bitcoin.cz}} || Slush's mining pool community<br />
|-<br />
| {{Freenode IRC|ozcoin}} || [[Ozco.in]] mining pool community<br />
|-<br />
| <small>[irc://irc.foonetic.net/xkcd-bitcoin IRC] [http://irc.lc/foonetic/xkcd-bitcoin/Miner@@@ Web]</small> #xkcd-bitcoin || [https://en.bitcoin.it/wiki/XKCD_Pool XKCD Pool]<br />
|-<br />
| <small>[irc://irc.quakenet.org/bitcoins.lc IRC] [http://irc.lc/quakenet/bitcoins.lc/Miner@@@ Web]</small> #bitcoins.lc @ Quakenet || [http://www.bitcoins.lc Bitcoins.lc Pool] <br />
|-<br />
| {{Freenode IRC|p2pool}} || [[P2Pool]] decentralized mining pool<br />
|-<br />
| {{Freenode IRC|bitminter}} || [[BitMinter]] Mining Pool Community<br />
|-<br />
| {{Freenode IRC|kncminer}} || [[KNCMiner]] ASIC Mining Hardware Vendor Discussion<br />
|}<br />
<br />
==Communities for Exchanges and Trading==<br />
<br />
{| class="wikitable"<br />
! Channel !! Description<br />
|-<br />
| {{Freenode IRC|bitcoin-assets}} || Discussion of securities and other asset investments. [http://bitcoin-assets.com bitcoin-assets.com].<br />
|-<br />
| {{Freenode IRC|bitcoin-assets-trades}} || Streaming assets market data (only), no chat.<br />
|-<br />
| {{Freenode IRC|bitcoin-auction}} || Live auctions over IRC.<br />
|-<br />
| {{Freenode IRC|bitcoin-market}} || Streaming market data (only), no chat.<br />
|-<br />
| {{Freenode IRC|bitcoin-otc|text=[[bitcoin-otc|#bitcoin-otc]]}} || Over-the-counter trading marketplace and discussion. ([http://bitcoinstats.com/irc/bitcoin-otc/logs/ history])<br />
|-<br />
| {{Freenode IRC|bitcoin-escrow}} || Third party escrow agents.<br />
|-<br />
| {{Freenode IRC|bitcoin-otc-ticker|bitcoin-otc-ticker}} || Streaming market data form the [[#bitcoin-otc]] order book.<br />
|-<br />
| {{Freenode IRC|bitcoin-otc-ratings|bitcoin-otc-ratings}} || Updates to ratings on the [[#bitcoin-otc]] Web of Trust.<br />
|-<br />
| {{Freenode IRC|bitcoin-pit}} || Only over-the-counter trading.<br />
|-<br />
| {{Freenode IRC|bitcoin-wot|bitcoin-wot}} || Distributed Web of Trust (WoT) system for [[#bitcoin-otc]].<br />
|-<br />
| {{Freenode IRC|btc.chat.traders}} || Russian community discussion about trades/exchanges.<br />
|-<br />
| {{Freenode IRC|coinbase}} || [[Coinbase]] chat<br />
|-<br />
| {{Freenode IRC|bitcoin-rt}} || Real-time tape (executed trades).<br />
|-<br />
| {{Freenode IRC|localbitcoins-chat}} || [[LocalBitcoins.com]] exchange support<br />
|-<br />
| {{Freenode IRC|Coinabul}} || [http://Coinabul.com Coinabul]'s customer support and news channel. Selling gold and silver for Bitcoin.<br />
|}<br />
<br />
==Related Communities==<br />
<br />
{| class="wikitable"<br />
! Channel !! Description<br />
|-<br />
| {{Freenode IRC|opentransactions}} || [[Open Transactions]] project.<br />
|-<br />
| {{Freenode IRC|namecoin}} || [[Namecoin]] and the [[Dot-bit]] project.<br />
|-<br />
| {{Freenode IRC|twister}} || [[Twister]], P2P microblogging discussion.<br />
|-<br />
| {{Freenode IRC|joinmarket}} || [[JoinMarket]], A [[CoinJoin]] implementation<br />
|-<br />
| {{Freenode IRC|darkwallet}} || [[DarkWallet]] and libbitcoin/Obelisk discussion & development channel.<br />
|-<br />
| {{Freenode IRC|electrum}} || [[Electrum]], lightweight bitcoin client.<br />
|-<br />
| {{Freenode IRC|copay}} || [[Copay]], lightweight bitcoin client.<br />
|-<br />
| {{Freenode IRC|bitcoin-stackexchange}} || Discussion complementing [http://bitcoin.stackexchange.com Bitcoin StackExchange].<br />
<br />
|}<br />
<br />
==See Also==<br />
<br />
* [[Bitcoin_Wiki:Community_portal]]<br />
<br />
[[fr:Canaux IRC]]<br />
[[pl:Kanały IRC]]<br />
[[ro:Canale]]</div>Hardinghttps://en.bitcoin.it/w/index.php?title=IRC_channels&diff=68671IRC channels2021-05-26T20:26:18Z<p>Harding: /* Bitcoin Project */ Update multiple channels to Libera.chat, updating changed names for s/#bitcoin-builds/#bitcoin-core-builds/, s/##bitcoin-core-gui/#bitcoin-core-gui/</p>
<hr />
<div>This page lists IRC channels for discussing Bitcoin-related topics. Please read: [[Bitcoin IRC Channel Guidelines]] before joining.<br />
<br />
Prior to late May 2021, most of these channels were on the [https://freenode.net/ Freenode] network. Due to an [https://gist.github.com/joepie91/df80d8d36cd9d1bde46ba018af497409 Ownership dispute over Freenode], several have moved to [https://libera.chat Libera.chat], with a few others planning to move by early June. If you join a channel at the Freenode address listed below and don't find any activity within a reasonable amount of time, try the same channel on Libera or ask for help in <tt>#bitcoin</tt> on Libera.<br />
<br />
==Bitcoin Project==<br />
{| class="wikitable"<br />
! Channel !! Description<br />
|-<br />
| {{Libera IRC|bitcoin}} || General Bitcoin-related discussion and support. ([[Bitcoin_IRC_Channel_Guidelines | guidelines]]).<br />
|-<br />
| {{Libera IRC|bitcoin-core-builds}} || Discussion of the Bitcoin Core build system.<br />
|-<br />
| {{Freenode IRC|bitcoin-commits}} || Real-time notification of commits to Bitcoin projects.<br />
|-<br />
| {{Libera IRC|bitcoin-core-dev}} || For development of Bitcoin Core. Log sources; [http://www.erisian.com.au/bitcoin-core-dev/ 1], [http://gnusha.org/bitcoin-core-dev/ 2]<br />
|-<br />
| {{Libera IRC|bitcoin-core-gui}} || For development of Bitcoin Core's GUI.<br />
|-<br />
| {{Libera IRC|bitcoin-core-pr-reviews}} || Weekly PR review club for discussing Bitcoin Core Pull Requests.<br />
|-<br />
| {{Freenode IRC|bitcoin-dev}} || Dead. Formerly for Bitcoin software development. ([http://bitcoinstats.com/irc/bitcoin-dev/logs/ history]. [[Bitcoin-dev | guidelines]])<br />
|-<br />
| {{Freenode IRC|bitcoin-gaming}} || Bitcoin gamers hangout.<br />
|-<br />
| {{Freenode IRC|bitcoin-gentoo}} || Gentoo community.<br />
|-<br />
| {{Freenode IRC|bitcoin-marketing}} || Marketing and promotion of bitcoin<br />
|-<br />
| {{Freenode IRC|bitcoin-news}} || RSS News related to Bitcoin.<br />
|-<br />
| {{Freenode IRC|bitcoin-politics}} || Discuss politics with other Bitcoin users.<br />
|-<br />
| {{Freenode IRC|#bitcoin-pricetalk|text=&#35;bitcoin-pricetalk}} || ALL Discussion Remotely Related to Bitcoin Price or other offtopic goes here<br />
|-<br />
| {{Freenode IRC|bitcoin-watch|text=[[Bitcoin-Watch|#bitcoin-watch]]}} || Streaming Bitcoin transactions, including market data.<br />
|-<br />
| {{Libera IRC|bitcoin-wiki}} || Bitcoin Wiki support<br />
|-<br />
| {{Libera IRC|bitcoin-wizards}} || Bitcoin experts and futurists ([http://gnusha.org/bitcoin-wizards/ history])<br />
|-<br />
| {{Freenode IRC|lightning-dev}} || Lightning protocol development ([http://gnusha.org/lightning-dev/ history])<br />
|-<br />
| {{Freenode IRC|lnd}} || Lightning only version of #bitcoin-commits<br />
|-<br />
| {{Freenode IRC|sidechains-dev}} || Sidechains development<br />
|}<br />
<br />
===Local communities===<br />
<br />
{| class="wikitable"<br />
| {{Freenode IRC|bitcoin-otc-eu}} || European OTC trading marketplace.<br />
|-<br />
| {{Freenode IRC|bitcoin-otc-ru}} || Russian OTC trading marketplace.<br />
|-<br />
| {{Freenode IRC|bitcoin-otc-uk}} ||United kingdom OTC Trading Marketplace.Founder Angus Bates.<br />
|-<br />
| {{Freenode IRC|bitcoin-aus}} || Aussie bitcoin community.<br />
|-<br />
| {{Freenode IRC|AustinBitcoin}} || Austin, TX bitcoin community.<br />
|-<br />
| {{Freenode IRC|bitcoin-bra}} || Brazilian bitcoin community.<br />
|-<br />
| {{Freenode IRC|bitcoin-cad}} || Canadian bitcoin community.<br />
|-<br />
| {{Freenode IRC|bitcoin-cn}} || Chinese bitcoin community.<br />
|-<br />
| {{Freenode IRC|bitcoin-dk}} || Danish bitcoin community.<br />
|-<br />
| {{Freenode IRC|bitcoin-de}} || German bitcoin community.<br />
|-<br />
| {{Freenode IRC|bitcoin-eastcoastusa}} || East Coast USA bitcoin community.<br />
|-<br />
| {{Freenode IRC|bitcoin-il}} || Israeli bitcoin community.<br />
|-<br />
| {{Freenode IRC|bitcoin-nl}} || Dutch bitcoin community. <br />
|-<br />
| {{Freenode IRC|bitcoin-pl}} || Polish bitcoin community.<br />
|-<br />
| {{Freenode IRC|bitcoin-romania}} || Romanian bitcoin community.<br />
|-<br />
| {{Freenode IRC|bitcoin-ve}} || Venezuelan bitcoin community.<br />
|-<br />
| {{Freenode IRC|btc.chat}} || Russian bitcoin community.<br />
|-<br />
| #bitcoins.fi @ IRCNet || Finnish bitcoin community.<br />
|-<br />
| {{Freenode IRC|bitcoin-hr}} || Croatian language bitcoin community.<br />
<br />
|}<br />
<br />
==Mining Related Communities==<br />
<br />
{| class="wikitable"<br />
! Channel !! Description<br />
|-<br />
| {{Freenode IRC|avalon}} || Discussion and support specific to [[Avalon]] mining machine<br />
|-<br />
| {{Freenode IRC|bitcoin-mining}} || Discussion and support related to mining.<br />
|-<br />
| {{Freenode IRC|bitcoin-fpga}} || Discussion and support specific to FPGA mining.<br />
|-<br />
| {{Freenode IRC|btcguild}} || [[BTCGuild]] mining pool community<br />
|-<br />
| {{Freenode IRC|butterflylabs}} || [[Butterfly Labs]] chat<br />
|-<br />
| {{Freenode IRC|cgminer}} || Discussion and support specific to [[CGMiner]].<br />
|-<br />
| {{Freenode IRC|eligius}} || [[Eligius]] mining pool community (also support for [[BFGMiner]] and [[Eloipool]])<br />
|-<br />
| {{Freenode IRC|mining.bitcoin.cz}} || Slush's mining pool community<br />
|-<br />
| {{Freenode IRC|ozcoin}} || [[Ozco.in]] mining pool community<br />
|-<br />
| <small>[irc://irc.foonetic.net/xkcd-bitcoin IRC] [http://irc.lc/foonetic/xkcd-bitcoin/Miner@@@ Web]</small> #xkcd-bitcoin || [https://en.bitcoin.it/wiki/XKCD_Pool XKCD Pool]<br />
|-<br />
| <small>[irc://irc.quakenet.org/bitcoins.lc IRC] [http://irc.lc/quakenet/bitcoins.lc/Miner@@@ Web]</small> #bitcoins.lc @ Quakenet || [http://www.bitcoins.lc Bitcoins.lc Pool] <br />
|-<br />
| {{Freenode IRC|p2pool}} || [[P2Pool]] decentralized mining pool<br />
|-<br />
| {{Freenode IRC|bitminter}} || [[BitMinter]] Mining Pool Community<br />
|-<br />
| {{Freenode IRC|kncminer}} || [[KNCMiner]] ASIC Mining Hardware Vendor Discussion<br />
|}<br />
<br />
==Communities for Exchanges and Trading==<br />
<br />
{| class="wikitable"<br />
! Channel !! Description<br />
|-<br />
| {{Freenode IRC|bitcoin-assets}} || Discussion of securities and other asset investments. [http://bitcoin-assets.com bitcoin-assets.com].<br />
|-<br />
| {{Freenode IRC|bitcoin-assets-trades}} || Streaming assets market data (only), no chat.<br />
|-<br />
| {{Freenode IRC|bitcoin-auction}} || Live auctions over IRC.<br />
|-<br />
| {{Freenode IRC|bitcoin-market}} || Streaming market data (only), no chat.<br />
|-<br />
| {{Freenode IRC|bitcoin-otc|text=[[bitcoin-otc|#bitcoin-otc]]}} || Over-the-counter trading marketplace and discussion. ([http://bitcoinstats.com/irc/bitcoin-otc/logs/ history])<br />
|-<br />
| {{Freenode IRC|bitcoin-escrow}} || Third party escrow agents.<br />
|-<br />
| {{Freenode IRC|bitcoin-otc-ticker|bitcoin-otc-ticker}} || Streaming market data form the [[#bitcoin-otc]] order book.<br />
|-<br />
| {{Freenode IRC|bitcoin-otc-ratings|bitcoin-otc-ratings}} || Updates to ratings on the [[#bitcoin-otc]] Web of Trust.<br />
|-<br />
| {{Freenode IRC|bitcoin-pit}} || Only over-the-counter trading.<br />
|-<br />
| {{Freenode IRC|bitcoin-wot|bitcoin-wot}} || Distributed Web of Trust (WoT) system for [[#bitcoin-otc]].<br />
|-<br />
| {{Freenode IRC|btc.chat.traders}} || Russian community discussion about trades/exchanges.<br />
|-<br />
| {{Freenode IRC|coinbase}} || [[Coinbase]] chat<br />
|-<br />
| {{Freenode IRC|bitcoin-rt}} || Real-time tape (executed trades).<br />
|-<br />
| {{Freenode IRC|localbitcoins-chat}} || [[LocalBitcoins.com]] exchange support<br />
|-<br />
| {{Freenode IRC|Coinabul}} || [http://Coinabul.com Coinabul]'s customer support and news channel. Selling gold and silver for Bitcoin.<br />
|}<br />
<br />
==Related Communities==<br />
<br />
{| class="wikitable"<br />
! Channel !! Description<br />
|-<br />
| {{Freenode IRC|opentransactions}} || [[Open Transactions]] project.<br />
|-<br />
| {{Freenode IRC|namecoin}} || [[Namecoin]] and the [[Dot-bit]] project.<br />
|-<br />
| {{Freenode IRC|twister}} || [[Twister]], P2P microblogging discussion.<br />
|-<br />
| {{Freenode IRC|joinmarket}} || [[JoinMarket]], A [[CoinJoin]] implementation<br />
|-<br />
| {{Freenode IRC|darkwallet}} || [[DarkWallet]] and libbitcoin/Obelisk discussion & development channel.<br />
|-<br />
| {{Freenode IRC|electrum}} || [[Electrum]], lightweight bitcoin client.<br />
|-<br />
| {{Freenode IRC|copay}} || [[Copay]], lightweight bitcoin client.<br />
|-<br />
| {{Freenode IRC|bitcoin-stackexchange}} || Discussion complementing [http://bitcoin.stackexchange.com Bitcoin StackExchange].<br />
<br />
|}<br />
<br />
==See Also==<br />
<br />
* [[Bitcoin_Wiki:Community_portal]]<br />
<br />
[[fr:Canaux IRC]]<br />
[[pl:Kanały IRC]]<br />
[[ro:Canale]]</div>Hardinghttps://en.bitcoin.it/w/index.php?title=IRC_channels&diff=68670IRC channels2021-05-26T20:19:32Z<p>Harding: Updates #bitcoin-core-dev to libera.chat</p>
<hr />
<div>This page lists IRC channels for discussing Bitcoin-related topics. Please read: [[Bitcoin IRC Channel Guidelines]] before joining.<br />
<br />
Prior to late May 2021, most of these channels were on the [https://freenode.net/ Freenode] network. Due to an [https://gist.github.com/joepie91/df80d8d36cd9d1bde46ba018af497409 Ownership dispute over Freenode], several have moved to [https://libera.chat Libera.chat], with a few others planning to move by early June. If you join a channel at the Freenode address listed below and don't find any activity within a reasonable amount of time, try the same channel on Libera or ask for help in <tt>#bitcoin</tt> on Libera.<br />
<br />
==Bitcoin Project==<br />
{| class="wikitable"<br />
! Channel !! Description<br />
|-<br />
| {{Freenode IRC|bitcoin}} || General Bitcoin-related discussion and support. ([[Bitcoin_IRC_Channel_Guidelines | guidelines]]).<br />
|-<br />
| {{Freenode IRC|bitcoin-builds}} || Discussion of the Bitcoin Core build system.<br />
|-<br />
| {{Freenode IRC|bitcoin-commits}} || Real-time notification of commits to Bitcoin projects.<br />
|-<br />
| {{Libera IRC|bitcoin-core-dev}} || For development of Bitcoin Core. Log sources; [http://www.erisian.com.au/bitcoin-core-dev/ 1], [http://gnusha.org/bitcoin-core-dev/ 2]<br />
|-<br />
| {{Freenode IRC|#bitcoin-core-gui}} || For development of Bitcoin Core's GUI.<br />
|-<br />
| {{Freenode IRC|bitcoin-core-pr-reviews}} || Weekly PR review club for discussing Bitcoin Core Pull Requests.<br />
|-<br />
| {{Freenode IRC|bitcoin-dev}} || Dead. Formerly for Bitcoin software development. ([http://bitcoinstats.com/irc/bitcoin-dev/logs/ history]. [[Bitcoin-dev | guidelines]])<br />
|-<br />
| {{Freenode IRC|bitcoin-gaming}} || Bitcoin gamers hangout.<br />
|-<br />
| {{Freenode IRC|bitcoin-gentoo}} || Gentoo community.<br />
|-<br />
| {{Freenode IRC|bitcoin-marketing}} || Marketing and promotion of bitcoin<br />
|-<br />
| {{Freenode IRC|bitcoin-news}} || RSS News related to Bitcoin.<br />
|-<br />
| {{Freenode IRC|bitcoin-politics}} || Discuss politics with other Bitcoin users.<br />
|-<br />
| {{Freenode IRC|#bitcoin-pricetalk|text=&#35;bitcoin-pricetalk}} || ALL Discussion Remotely Related to Bitcoin Price or other offtopic goes here<br />
|-<br />
| {{Freenode IRC|bitcoin-watch|text=[[Bitcoin-Watch|#bitcoin-watch]]}} || Streaming Bitcoin transactions, including market data.<br />
|-<br />
| {{Freenode IRC|bitcoin-wiki}} || Bitcoin Wiki support<br />
|-<br />
| {{Freenode IRC|bitcoin-wizards}} || Bitcoin experts and futurists ([http://gnusha.org/bitcoin-wizards/ history])<br />
|-<br />
| {{Freenode IRC|lightning-dev}} || Lightning protocol development ([http://gnusha.org/lightning-dev/ history])<br />
|-<br />
| {{Freenode IRC|lnd}} || Lightning only version of #bitcoin-commits<br />
|-<br />
| {{Freenode IRC|sidechains-dev}} || Sidechains development<br />
|}<br />
<br />
===Local communities===<br />
<br />
{| class="wikitable"<br />
| {{Freenode IRC|bitcoin-otc-eu}} || European OTC trading marketplace.<br />
|-<br />
| {{Freenode IRC|bitcoin-otc-ru}} || Russian OTC trading marketplace.<br />
|-<br />
| {{Freenode IRC|bitcoin-otc-uk}} ||United kingdom OTC Trading Marketplace.Founder Angus Bates.<br />
|-<br />
| {{Freenode IRC|bitcoin-aus}} || Aussie bitcoin community.<br />
|-<br />
| {{Freenode IRC|AustinBitcoin}} || Austin, TX bitcoin community.<br />
|-<br />
| {{Freenode IRC|bitcoin-bra}} || Brazilian bitcoin community.<br />
|-<br />
| {{Freenode IRC|bitcoin-cad}} || Canadian bitcoin community.<br />
|-<br />
| {{Freenode IRC|bitcoin-cn}} || Chinese bitcoin community.<br />
|-<br />
| {{Freenode IRC|bitcoin-dk}} || Danish bitcoin community.<br />
|-<br />
| {{Freenode IRC|bitcoin-de}} || German bitcoin community.<br />
|-<br />
| {{Freenode IRC|bitcoin-eastcoastusa}} || East Coast USA bitcoin community.<br />
|-<br />
| {{Freenode IRC|bitcoin-il}} || Israeli bitcoin community.<br />
|-<br />
| {{Freenode IRC|bitcoin-nl}} || Dutch bitcoin community. <br />
|-<br />
| {{Freenode IRC|bitcoin-pl}} || Polish bitcoin community.<br />
|-<br />
| {{Freenode IRC|bitcoin-romania}} || Romanian bitcoin community.<br />
|-<br />
| {{Freenode IRC|bitcoin-ve}} || Venezuelan bitcoin community.<br />
|-<br />
| {{Freenode IRC|btc.chat}} || Russian bitcoin community.<br />
|-<br />
| #bitcoins.fi @ IRCNet || Finnish bitcoin community.<br />
|-<br />
| {{Freenode IRC|bitcoin-hr}} || Croatian language bitcoin community.<br />
<br />
|}<br />
<br />
==Mining Related Communities==<br />
<br />
{| class="wikitable"<br />
! Channel !! Description<br />
|-<br />
| {{Freenode IRC|avalon}} || Discussion and support specific to [[Avalon]] mining machine<br />
|-<br />
| {{Freenode IRC|bitcoin-mining}} || Discussion and support related to mining.<br />
|-<br />
| {{Freenode IRC|bitcoin-fpga}} || Discussion and support specific to FPGA mining.<br />
|-<br />
| {{Freenode IRC|btcguild}} || [[BTCGuild]] mining pool community<br />
|-<br />
| {{Freenode IRC|butterflylabs}} || [[Butterfly Labs]] chat<br />
|-<br />
| {{Freenode IRC|cgminer}} || Discussion and support specific to [[CGMiner]].<br />
|-<br />
| {{Freenode IRC|eligius}} || [[Eligius]] mining pool community (also support for [[BFGMiner]] and [[Eloipool]])<br />
|-<br />
| {{Freenode IRC|mining.bitcoin.cz}} || Slush's mining pool community<br />
|-<br />
| {{Freenode IRC|ozcoin}} || [[Ozco.in]] mining pool community<br />
|-<br />
| <small>[irc://irc.foonetic.net/xkcd-bitcoin IRC] [http://irc.lc/foonetic/xkcd-bitcoin/Miner@@@ Web]</small> #xkcd-bitcoin || [https://en.bitcoin.it/wiki/XKCD_Pool XKCD Pool]<br />
|-<br />
| <small>[irc://irc.quakenet.org/bitcoins.lc IRC] [http://irc.lc/quakenet/bitcoins.lc/Miner@@@ Web]</small> #bitcoins.lc @ Quakenet || [http://www.bitcoins.lc Bitcoins.lc Pool] <br />
|-<br />
| {{Freenode IRC|p2pool}} || [[P2Pool]] decentralized mining pool<br />
|-<br />
| {{Freenode IRC|bitminter}} || [[BitMinter]] Mining Pool Community<br />
|-<br />
| {{Freenode IRC|kncminer}} || [[KNCMiner]] ASIC Mining Hardware Vendor Discussion<br />
|}<br />
<br />
==Communities for Exchanges and Trading==<br />
<br />
{| class="wikitable"<br />
! Channel !! Description<br />
|-<br />
| {{Freenode IRC|bitcoin-assets}} || Discussion of securities and other asset investments. [http://bitcoin-assets.com bitcoin-assets.com].<br />
|-<br />
| {{Freenode IRC|bitcoin-assets-trades}} || Streaming assets market data (only), no chat.<br />
|-<br />
| {{Freenode IRC|bitcoin-auction}} || Live auctions over IRC.<br />
|-<br />
| {{Freenode IRC|bitcoin-market}} || Streaming market data (only), no chat.<br />
|-<br />
| {{Freenode IRC|bitcoin-otc|text=[[bitcoin-otc|#bitcoin-otc]]}} || Over-the-counter trading marketplace and discussion. ([http://bitcoinstats.com/irc/bitcoin-otc/logs/ history])<br />
|-<br />
| {{Freenode IRC|bitcoin-escrow}} || Third party escrow agents.<br />
|-<br />
| {{Freenode IRC|bitcoin-otc-ticker|bitcoin-otc-ticker}} || Streaming market data form the [[#bitcoin-otc]] order book.<br />
|-<br />
| {{Freenode IRC|bitcoin-otc-ratings|bitcoin-otc-ratings}} || Updates to ratings on the [[#bitcoin-otc]] Web of Trust.<br />
|-<br />
| {{Freenode IRC|bitcoin-pit}} || Only over-the-counter trading.<br />
|-<br />
| {{Freenode IRC|bitcoin-wot|bitcoin-wot}} || Distributed Web of Trust (WoT) system for [[#bitcoin-otc]].<br />
|-<br />
| {{Freenode IRC|btc.chat.traders}} || Russian community discussion about trades/exchanges.<br />
|-<br />
| {{Freenode IRC|coinbase}} || [[Coinbase]] chat<br />
|-<br />
| {{Freenode IRC|bitcoin-rt}} || Real-time tape (executed trades).<br />
|-<br />
| {{Freenode IRC|localbitcoins-chat}} || [[LocalBitcoins.com]] exchange support<br />
|-<br />
| {{Freenode IRC|Coinabul}} || [http://Coinabul.com Coinabul]'s customer support and news channel. Selling gold and silver for Bitcoin.<br />
|}<br />
<br />
==Related Communities==<br />
<br />
{| class="wikitable"<br />
! Channel !! Description<br />
|-<br />
| {{Freenode IRC|opentransactions}} || [[Open Transactions]] project.<br />
|-<br />
| {{Freenode IRC|namecoin}} || [[Namecoin]] and the [[Dot-bit]] project.<br />
|-<br />
| {{Freenode IRC|twister}} || [[Twister]], P2P microblogging discussion.<br />
|-<br />
| {{Freenode IRC|joinmarket}} || [[JoinMarket]], A [[CoinJoin]] implementation<br />
|-<br />
| {{Freenode IRC|darkwallet}} || [[DarkWallet]] and libbitcoin/Obelisk discussion & development channel.<br />
|-<br />
| {{Freenode IRC|electrum}} || [[Electrum]], lightweight bitcoin client.<br />
|-<br />
| {{Freenode IRC|copay}} || [[Copay]], lightweight bitcoin client.<br />
|-<br />
| {{Freenode IRC|bitcoin-stackexchange}} || Discussion complementing [http://bitcoin.stackexchange.com Bitcoin StackExchange].<br />
<br />
|}<br />
<br />
==See Also==<br />
<br />
* [[Bitcoin_Wiki:Community_portal]]<br />
<br />
[[fr:Canaux IRC]]<br />
[[pl:Kanały IRC]]<br />
[[ro:Canale]]</div>Hardinghttps://en.bitcoin.it/w/index.php?title=Template:Libera_IRC&diff=68669Template:Libera IRC2021-05-26T20:17:02Z<p>Harding: s/irc/ircs/ for SSL secured by default</p>
<hr />
<div><small>[ircs://irc.libera.chat:6697/{{{1}}} IRC] [https://kiwiirc.com/nextclient/#irc://irc.libera.chat/#{{{1}}} Web]</small> {{#if: {{{text|}}} | {{{text}}} | <nowiki>#</nowiki>{{{1}}}}}</div>Hardinghttps://en.bitcoin.it/w/index.php?title=Template:Libera_IRC&diff=68668Template:Libera IRC2021-05-26T20:12:05Z<p>Harding: Template for the Libera.chat IRC network</p>
<hr />
<div><small>[irc://irc.libera.chat:6697/{{{1}}} IRC] [https://kiwiirc.com/nextclient/#irc://irc.libera.chat/#{{{1}}} Web]</small> {{#if: {{{text|}}} | {{{text}}} | <nowiki>#</nowiki>{{{1}}}}}</div>Hardinghttps://en.bitcoin.it/w/index.php?title=IRC_channels&diff=68666IRC channels2021-05-21T22:25:12Z<p>Harding: Mention Libera. Doesn't change any links yet, but it hopefully provides enough information that people can sort things out if they end up in an abandoned Freenode room</p>
<hr />
<div>This page lists IRC channels for discussing Bitcoin-related topics. Please read: [[Bitcoin IRC Channel Guidelines]] before joining.<br />
<br />
Prior to late May 2021, most of these channels were on the [https://freenode.net/ Freenode] network. Due to an [https://gist.github.com/joepie91/df80d8d36cd9d1bde46ba018af497409 Ownership dispute over Freenode], several have moved to [https://libera.chat Libera.chat], with a few others planning to move by early June. If you join a channel at the Freenode address listed below and don't find any activity within a reasonable amount of time, try the same channel on Libera or ask for help in <tt>#bitcoin</tt> on Libera.<br />
<br />
==Bitcoin Project==<br />
{| class="wikitable"<br />
! Channel !! Description<br />
|-<br />
| {{Freenode IRC|bitcoin}} || General Bitcoin-related discussion and support. ([[Bitcoin_IRC_Channel_Guidelines | guidelines]]).<br />
|-<br />
| {{Freenode IRC|bitcoin-builds}} || Discussion of the Bitcoin Core build system.<br />
|-<br />
| {{Freenode IRC|bitcoin-commits}} || Real-time notification of commits to Bitcoin projects.<br />
|-<br />
| {{Freenode IRC|bitcoin-core-dev}} || For development of Bitcoin Core. Log sources; [http://www.erisian.com.au/bitcoin-core-dev/ 1], [http://gnusha.org/bitcoin-core-dev/ 2]<br />
|-<br />
| {{Freenode IRC|#bitcoin-core-gui}} || For development of Bitcoin Core's GUI.<br />
|-<br />
| {{Freenode IRC|bitcoin-core-pr-reviews}} || Weekly PR review club for discussing Bitcoin Core Pull Requests.<br />
|-<br />
| {{Freenode IRC|bitcoin-dev}} || Dead. Formerly for Bitcoin software development. ([http://bitcoinstats.com/irc/bitcoin-dev/logs/ history]. [[Bitcoin-dev | guidelines]])<br />
|-<br />
| {{Freenode IRC|bitcoin-gaming}} || Bitcoin gamers hangout.<br />
|-<br />
| {{Freenode IRC|bitcoin-gentoo}} || Gentoo community.<br />
|-<br />
| {{Freenode IRC|bitcoin-marketing}} || Marketing and promotion of bitcoin<br />
|-<br />
| {{Freenode IRC|bitcoin-news}} || RSS News related to Bitcoin.<br />
|-<br />
| {{Freenode IRC|bitcoin-politics}} || Discuss politics with other Bitcoin users.<br />
|-<br />
| {{Freenode IRC|#bitcoin-pricetalk|text=&#35;bitcoin-pricetalk}} || ALL Discussion Remotely Related to Bitcoin Price or other offtopic goes here<br />
|-<br />
| {{Freenode IRC|bitcoin-watch|text=[[Bitcoin-Watch|#bitcoin-watch]]}} || Streaming Bitcoin transactions, including market data.<br />
|-<br />
| {{Freenode IRC|bitcoin-wiki}} || Bitcoin Wiki support<br />
|-<br />
| {{Freenode IRC|bitcoin-wizards}} || Bitcoin experts and futurists ([http://gnusha.org/bitcoin-wizards/ history])<br />
|-<br />
| {{Freenode IRC|lightning-dev}} || Lightning protocol development ([http://gnusha.org/lightning-dev/ history])<br />
|-<br />
| {{Freenode IRC|lnd}} || Lightning only version of #bitcoin-commits<br />
|-<br />
| {{Freenode IRC|sidechains-dev}} || Sidechains development<br />
|}<br />
<br />
===Local communities===<br />
<br />
{| class="wikitable"<br />
| {{Freenode IRC|bitcoin-otc-eu}} || European OTC trading marketplace.<br />
|-<br />
| {{Freenode IRC|bitcoin-otc-ru}} || Russian OTC trading marketplace.<br />
|-<br />
| {{Freenode IRC|bitcoin-otc-uk}} ||United kingdom OTC Trading Marketplace.Founder Angus Bates.<br />
|-<br />
| {{Freenode IRC|bitcoin-aus}} || Aussie bitcoin community.<br />
|-<br />
| {{Freenode IRC|AustinBitcoin}} || Austin, TX bitcoin community.<br />
|-<br />
| {{Freenode IRC|bitcoin-bra}} || Brazilian bitcoin community.<br />
|-<br />
| {{Freenode IRC|bitcoin-cad}} || Canadian bitcoin community.<br />
|-<br />
| {{Freenode IRC|bitcoin-cn}} || Chinese bitcoin community.<br />
|-<br />
| {{Freenode IRC|bitcoin-dk}} || Danish bitcoin community.<br />
|-<br />
| {{Freenode IRC|bitcoin-de}} || German bitcoin community.<br />
|-<br />
| {{Freenode IRC|bitcoin-eastcoastusa}} || East Coast USA bitcoin community.<br />
|-<br />
| {{Freenode IRC|bitcoin-il}} || Israeli bitcoin community.<br />
|-<br />
| {{Freenode IRC|bitcoin-nl}} || Dutch bitcoin community. <br />
|-<br />
| {{Freenode IRC|bitcoin-pl}} || Polish bitcoin community.<br />
|-<br />
| {{Freenode IRC|bitcoin-romania}} || Romanian bitcoin community.<br />
|-<br />
| {{Freenode IRC|bitcoin-ve}} || Venezuelan bitcoin community.<br />
|-<br />
| {{Freenode IRC|btc.chat}} || Russian bitcoin community.<br />
|-<br />
| #bitcoins.fi @ IRCNet || Finnish bitcoin community.<br />
|-<br />
| {{Freenode IRC|bitcoin-hr}} || Croatian language bitcoin community.<br />
<br />
|}<br />
<br />
==Mining Related Communities==<br />
<br />
{| class="wikitable"<br />
! Channel !! Description<br />
|-<br />
| {{Freenode IRC|avalon}} || Discussion and support specific to [[Avalon]] mining machine<br />
|-<br />
| {{Freenode IRC|bitcoin-mining}} || Discussion and support related to mining.<br />
|-<br />
| {{Freenode IRC|bitcoin-fpga}} || Discussion and support specific to FPGA mining.<br />
|-<br />
| {{Freenode IRC|btcguild}} || [[BTCGuild]] mining pool community<br />
|-<br />
| {{Freenode IRC|butterflylabs}} || [[Butterfly Labs]] chat<br />
|-<br />
| {{Freenode IRC|cgminer}} || Discussion and support specific to [[CGMiner]].<br />
|-<br />
| {{Freenode IRC|eligius}} || [[Eligius]] mining pool community (also support for [[BFGMiner]] and [[Eloipool]])<br />
|-<br />
| {{Freenode IRC|mining.bitcoin.cz}} || Slush's mining pool community<br />
|-<br />
| {{Freenode IRC|ozcoin}} || [[Ozco.in]] mining pool community<br />
|-<br />
| <small>[irc://irc.foonetic.net/xkcd-bitcoin IRC] [http://irc.lc/foonetic/xkcd-bitcoin/Miner@@@ Web]</small> #xkcd-bitcoin || [https://en.bitcoin.it/wiki/XKCD_Pool XKCD Pool]<br />
|-<br />
| <small>[irc://irc.quakenet.org/bitcoins.lc IRC] [http://irc.lc/quakenet/bitcoins.lc/Miner@@@ Web]</small> #bitcoins.lc @ Quakenet || [http://www.bitcoins.lc Bitcoins.lc Pool] <br />
|-<br />
| {{Freenode IRC|p2pool}} || [[P2Pool]] decentralized mining pool<br />
|-<br />
| {{Freenode IRC|bitminter}} || [[BitMinter]] Mining Pool Community<br />
|-<br />
| {{Freenode IRC|kncminer}} || [[KNCMiner]] ASIC Mining Hardware Vendor Discussion<br />
|}<br />
<br />
==Communities for Exchanges and Trading==<br />
<br />
{| class="wikitable"<br />
! Channel !! Description<br />
|-<br />
| {{Freenode IRC|bitcoin-assets}} || Discussion of securities and other asset investments. [http://bitcoin-assets.com bitcoin-assets.com].<br />
|-<br />
| {{Freenode IRC|bitcoin-assets-trades}} || Streaming assets market data (only), no chat.<br />
|-<br />
| {{Freenode IRC|bitcoin-auction}} || Live auctions over IRC.<br />
|-<br />
| {{Freenode IRC|bitcoin-market}} || Streaming market data (only), no chat.<br />
|-<br />
| {{Freenode IRC|bitcoin-otc|text=[[bitcoin-otc|#bitcoin-otc]]}} || Over-the-counter trading marketplace and discussion. ([http://bitcoinstats.com/irc/bitcoin-otc/logs/ history])<br />
|-<br />
| {{Freenode IRC|bitcoin-escrow}} || Third party escrow agents.<br />
|-<br />
| {{Freenode IRC|bitcoin-otc-ticker|bitcoin-otc-ticker}} || Streaming market data form the [[#bitcoin-otc]] order book.<br />
|-<br />
| {{Freenode IRC|bitcoin-otc-ratings|bitcoin-otc-ratings}} || Updates to ratings on the [[#bitcoin-otc]] Web of Trust.<br />
|-<br />
| {{Freenode IRC|bitcoin-pit}} || Only over-the-counter trading.<br />
|-<br />
| {{Freenode IRC|bitcoin-wot|bitcoin-wot}} || Distributed Web of Trust (WoT) system for [[#bitcoin-otc]].<br />
|-<br />
| {{Freenode IRC|btc.chat.traders}} || Russian community discussion about trades/exchanges.<br />
|-<br />
| {{Freenode IRC|coinbase}} || [[Coinbase]] chat<br />
|-<br />
| {{Freenode IRC|bitcoin-rt}} || Real-time tape (executed trades).<br />
|-<br />
| {{Freenode IRC|localbitcoins-chat}} || [[LocalBitcoins.com]] exchange support<br />
|-<br />
| {{Freenode IRC|Coinabul}} || [http://Coinabul.com Coinabul]'s customer support and news channel. Selling gold and silver for Bitcoin.<br />
|}<br />
<br />
==Related Communities==<br />
<br />
{| class="wikitable"<br />
! Channel !! Description<br />
|-<br />
| {{Freenode IRC|opentransactions}} || [[Open Transactions]] project.<br />
|-<br />
| {{Freenode IRC|namecoin}} || [[Namecoin]] and the [[Dot-bit]] project.<br />
|-<br />
| {{Freenode IRC|twister}} || [[Twister]], P2P microblogging discussion.<br />
|-<br />
| {{Freenode IRC|joinmarket}} || [[JoinMarket]], A [[CoinJoin]] implementation<br />
|-<br />
| {{Freenode IRC|darkwallet}} || [[DarkWallet]] and libbitcoin/Obelisk discussion & development channel.<br />
|-<br />
| {{Freenode IRC|electrum}} || [[Electrum]], lightweight bitcoin client.<br />
|-<br />
| {{Freenode IRC|copay}} || [[Copay]], lightweight bitcoin client.<br />
|-<br />
| {{Freenode IRC|bitcoin-stackexchange}} || Discussion complementing [http://bitcoin.stackexchange.com Bitcoin StackExchange].<br />
<br />
|}<br />
<br />
==See Also==<br />
<br />
* [[Bitcoin_Wiki:Community_portal]]<br />
<br />
[[fr:Canaux IRC]]<br />
[[pl:Kanały IRC]]<br />
[[ro:Canale]]</div>Hardinghttps://en.bitcoin.it/w/index.php?title=Taproot_activation_proposals&diff=68228Taproot activation proposals2020-10-17T10:52:15Z<p>Harding: Add note about forced activation proposals being a reaction to segwit activation rather than an expectation that miners will necessarily be a problem for taproot activation</p>
<hr />
<div>This page summarizes several technical proposals for activating the taproot soft fork defined by BIPs 340, 341, and 342. The goal is to succinctly reference the tradeoffs inherent in each class of proposals so that the development community can choose and implement an activation method that users will find acceptable.<br />
<br />
Note that a common theme in many of the proposals is dealing with the case where an insufficient percentage of hashrate signals readiness to enforce taproot. This is a reaction to the difficulty activating segwit. However, there is currently no indication that there will be difficulty activating taproot---miners may offer it the same support that they offered other non-controversial soft forks such as BIP34 height in coinbase, BIP66 strict DER, BIP65 <code>OP_CHECKLOCKTIMEVERIFY</code>, and BIPs 68/112/113 relative locktimes.<br />
<br />
== Notes on BIP8 ==<br />
<br />
At the time this document is being written, [https://github.com/bitcoin/bips/blob/master/bip-0008.mediawiki BIP8] ''version bits with lock-in by height'' was recently [https://github.com/bitcoin/bips//pull/550 updated] for the first time in several years. One notable change is that forced activation is now based on block height rather than median time past; a second notable change is that forced activation is a boolean parameter chosen when a soft fork’s activation parameters are set either for the initial deployment or updated in a later deployment.<br />
<br />
BIP8 without forced activation is very similar to [https://github.com/bitcoin/bips/blob/master/bip-0009.mediawiki BIP9] ''version bits with timeout and delay'', with the only significant difference being BIP8’s use of block heights compared to BIP9’s use of median time past. This setting allows the attempt to fail (but it can be retried later).<br />
<br />
BIP8 with forced activation concludes with a mandatory signaling period where all blocks produced in compliance with its rules must signal readiness for the soft fork in a way that will trigger activation in an earlier deployment of the same soft fork with non-mandatory activation. In other words, if node version x is released without forced activation and, later, version y is released that successfully forces miners to begin signaling readiness within the same time period, both versions will begin enforcing the new consensus rules at the same time.<br />
<br />
This flexibility of the revised BIP8 proposal makes it possible to express some other ideas in terms of what they would look like using BIP8. This provides a common factor to use for categorizing many different proposals.<br />
<br />
== Proposal overview ==<br />
<br />
Nomenclature: <code>BIP8(lockinontimeout, timeout)</code>. The <code>lockinontimeout</code> parameter is a bool specifying whether the attempt will conclude with a flag day activation (true) or a failure to activate (false). The <code>timeout</code> parameter specifies how many months (m) or years (y) until either the attempt fails or in mandatory activated. Columns with empty stages appear when no action is specified in advance (but any action with broad user support is still possible).<br />
<br />
Precise time parameters are still under discussion, with some people advocating moderately longer durations and some advocating moderately shorter durations. The entries below are examples meant to reflect the general idea behind a class of proposals.<br />
<br />
<!-- please sort table by the step in the first period; false before<br />
true (alphabetically), then shorter duration before longer duration --><br />
{|<br />
!| Short name<br />
!| Variation<br />
!| First stage<br />
!| Second stage<br />
!| Third stage<br />
|-<br />
| Let’s see what happens<br />
| Default<br />
| BIP8(false, 3m)<br />
|<br />
<br />
|<br />
<br />
|-<br />
| BIP9 equivalent<br />
| Default<br />
| BIP8(false, 1y)<br />
|<br />
<br />
|<br />
<br />
|-<br />
| Modern Soft Fork Activation<br />
| No issues<br />
| BIP8(false, 1y)<br />
| ''No action, 6m''<br />
| BIP8(true, 2y)<br />
|-<br />
|<br />
<br />
| Issue discovered<br />
| BIP8(false, 1y)<br />
| ''Abandon attempt''<br />
|<br />
<br />
|-<br />
| Decreasing Threshold Soft Fork Activation<br />
| No issues<br />
| BIP8(false, 1y)<br />
| ''No action, 6m''<br />
| BIP8(true, 2.5y), decreasing threshold<br />
|-<br />
|<br />
<br />
| Issue discovered<br />
| BIP8(false, 1y)<br />
| ''Abandon attempt''<br />
|<br />
<br />
|-<br />
| Start now, improve later<br />
| No additional action<br />
| BIP8(false, 2y)<br />
|<br />
<br />
|<br />
<br />
|-<br />
|<br />
<br />
| Commit to activation<br />
| <s>BIP8(false, 2y)</s><br />
| BIP8(true, 2y)<br />
|<br />
<br />
|-<br />
|<br />
<br />
| Commit to accelerated activation<br />
| <s>BIP8(false, 2y)</s><br />
| BIP8(true, 1y)<br />
|<br />
<br />
|-<br />
| Gently discourage apathy<br />
| Default<br />
| BIP8(true, 2y)<br />
| N/A<br />
| N/A<br />
|-<br />
|<br />
<br />
| Accelerate activation<br />
| <s>BIP8(true, 2y)</s><br />
| BIP8(true, 1y)<br />
| N/A<br />
|}<br />
<br />
The same proposals as above graphed over time:<br />
<br />
[[File:Activation-timeline.png|frame|none|alt=|Activation timeline]]<br />
<br />
== Proposals ==<br />
<br />
=== Let’s see what happens, BIP8(false, 3m) ===<br />
<br />
Proposed as a low-risk way to see if miners are willing to activate taproot as quickly as they activated BIP65 CLTV (two months) and BIP68 consensus-enforced sequence numbers (one month).<br />
<br />
Pros:<br />
<br />
* '''Non-committal:''' if a problem is discovered with taproot before miner activation, or there’s a lack of user support for the proposal, the attempt can safely fail without further intervention.<br />
* '''Short duration:''' if it fails unnecessarily, we’ll only have lost three months plus deployment time.<br />
* '''Useful data:''' if it works, it will add evidence to the theory that segwit activation was an aberration and users, developers, and miners can continue working together to upgrade the consensus protocol with minimal fuss.<br />
<br />
Cons:<br />
<br />
* '''Unnecessary failure risk (3 months):''' if it fails for no good reason, we’ll have wasted three months, plus its deployment time, plus the time to choose and deploy another activation method.<br />
* '''Single-shot:''' if it fails, anyone who ran the 3-month release must upgrade in order to enforce any subsequent attempts. Compare to the ''start now, improve later'' proposal where early releases can be triggered to activate by later releases.<br />
<br />
<br><br><br />
=== BIP9 equivalent, BIP8(false, 1y) ===<br />
<br />
Some people think that the lack of miner readiness signaling during the first several months of segwit availability was an aberration specific to the political context of the block size debate, segwit’s interference with covert ASICBoost, or some other factor. These people may wish to try BIP9 again. BIP8(false, 1y) is essentially BIP9 but using block heights rather than median time past to guarantee a specified number of signaling periods.<br />
<br />
Pros:<br />
<br />
* '''Non-committal:''' if a problem is discovered with taproot before miner activation, or there’s a lack of user support for the proposal, the attempt can safely fail without further intervention.<br />
* '''Useful data:''' if it works, it will add evidence to the theory that segwit activation was an aberration and users, developers, and miners can continue working together to upgrade the consensus protocol with minimal fuss.<br />
<br />
Cons:<br />
<br />
* '''Unnecessary failure risk (1 year):''' if it fails for no good reason, we’ll have wasted an entire year, plus its deployment time, plus the time to choose and deploy another activation method.<br />
<br />
<br><br><br />
=== Modern Soft Fork Activation, BIP8(false, 1y)+quiet(6m)+BIP8(true, 2y) ===<br />
<br />
Proposed in a [https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2020-January/017547.html mailing list post], the goals of this idea are to ensure users truly want a soft fork and that it’s activated in a way that minimizes the risk of disruption.<br />
<br />
Pros:<br />
<br />
* '''Non-committal (initial deployment):''' if a problem is discovered with taproot during the first two stages, or there’s a lack of user support for the proposal, the attempt can safely fail without further intervention.<br />
* '''Useful data:''' if it activates quickly, it will add evidence to the theory that segwit activation was an aberration and users, developers, and miners can continue working together to upgrade the consensus protocol with minimal fuss.<br />
* '''Far-off flag day:''' if mandatory activation is needed, there’s a long time (2 years) for users to upgrade to mandatory enforcement nodes. This minimizes the chance that only a small number of users will enact mandatory enforcement and then be tricked into accepting bitcoins that most other users won’t consider valid.<br />
<br />
Cons:<br />
<br />
* '''Committal (subsequent deployment):''' if a problem is discovered with taproot during the final stage, users and developers may need to intervene to prevent the problem from being exploited.<br />
* '''Unnecessary delay:''' without miner cooperation, it will take almost three years to get the taproot features, which may delay other useful Bitcoin work or cause developers to spend time implementing unnecessary intermediate solutions (e.g. 2pECDSA rather than MuSig).<br />
<br />
<br><br><br />
=== Decreasing Threshold Soft-Fork Activation, BIP8(false, 6m)+NoAction(1y)+BIP8(true, 2.5y) ===<br />
<br />
A [slight variation][bip-dectresh] on the Modern Soft Fork Activation method, the final period in this proposal steadily decreases the percentage of hashrate that needs to signal readiness for the soft fork before it activates. For example, normally 95% of blocks in a difficulty period need to signal for a BIP8 soft fork in order to activate it; however, near the end of the final signaling period, it might only require 60% of hash rate to signal readiness. This lower threshold is reasonable because it’s expected that most users will be ready to enforce the proposal at that time. Even if miners still aren’t signaling in sufficient numbers, the proposal can mandatory activate at the end of its final stage.<br />
<br />
Pros:<br />
<br />
* '''Non-committal (initial deployment):''' if a problem is discovered with taproot during the first two stages, the attempt can safely fail without further intervention.<br />
* '''Useful data:''' if it activates quickly, it will add evidence to the theory that segwit activation was an aberration and users, developers, and miners can continue working together to upgrade the consensus protocol with minimal fuss.<br />
* '''Far-off flag day:''' if mandatory activation is needed, there’s a long time (months or years) for users to upgrade to nodes that accept reduced threshold signaling or mandatory activation. This minimizes the chance that only a small number of users will enact mandatory enforcement and then be tricked into accepting bitcoins that most other users won’t consider valid.<br />
<br />
Cons:<br />
<br />
* '''Committal (subsequent deployment):''' if a problem is discovered with taproot during the final stage, users and developers may need to intervene to prevent the problem from being exploited.<br />
* '''Unnecessary delay:''' without miner cooperation, it will take almost four years to get the taproot features, which may delay other useful Bitcoin work or cause developers to spend time implementing unnecessary intermediate solutions (e.g. 2pECDSA rather than MuSig).<br />
* '''No reference implementation:''' no implementation of this proposal yet exists, although it is not believed that creating one would be particularly difficult.<br />
<br />
<br><br><br />
=== Start now, improve later, BIP8(false, 2y) ===<br />
<br />
Proposed as an option that maximizes flexibility, this allows miners to signal readiness to enforce taproot quickly but also makes it easy for users to force taproot activation later. For example, after several months of miners not activating taproot for no good reason, an updated node could be published that used the same BIP8 parameters except <code>lockinontimeout=true</code>, requiring activation at the end of the two years. Or <code>true</code> could be set and the timeout deadline could be shortened, allowing activation within 6 or 12 more months.<br />
<br />
Pros:<br />
<br />
* '''Non-committal:''' if a problem is discovered with taproot before miner activation, or there’s a lack of user support for the proposal, the attempt can safely fail without further intervention.<br />
* '''Useful data:''' if it activates quickly, it will add evidence to the theory that segwit activation was an aberration and users, developers, and miners can continue working together to upgrade the consensus protocol with minimal fuss.<br />
* '''Enough time for second deployment:''' the two year duration probably gives users and developers enough time to deploy an alternative that sets <code>lockintimeout=true</code>, allowing all nodes compatible with either deployment to activate simultaneously.<br />
<br />
Cons:<br />
<br />
* '''Unnecessary failure risk (2 years):''' if it fails for no good reason, we’ll have wasted two years, plus its deployment time, plus the time to choose and deploy another activation method.<br />
* '''Chaos risk:''' if some users later decide to <code>lockinontimeout=true</code> with a date before the original two-year end, they all need to choose the same date or users choosing a date with insufficient support could be tricked into accepting non-spendable bitcoins. It may be possible to mitigate this by building support for an acceleration target date even before the initial <code>lockinontimeout=false</code> version is released.<br />
<br />
<br><br><br />
=== Gently discourage apathy, BIP8(true, 2y) ===<br />
<br />
Proposed as a way to ensure miners eventually need to signal, so they don’t defer doing so out of apathy, this method requires activation after a long delay.<br />
<br />
Pros:<br />
<br />
* '''Useful data:''' if it activates quickly, it will add evidence to the theory that segwit activation was an aberration and users, developers, and miners can continue working together to upgrade the consensus protocol with minimal fuss.<br />
* '''Far-off flag day:''' if mandatory activation is needed, there’s a long time (months or years) for users to upgrade to nodes that accept reduced threshold signaling or mandatory activation. This minimizes the chance that only a small number of users will enact mandatory enforcement and then be tricked into accepting bitcoins that most other users won’t consider valid.<br />
* '''Enough time for second deployment:''' the two year duration may gives users and developers enough time to deploy additional soft fork rules that fix any problems in the initial proposal.<br />
<br />
Cons:<br />
<br />
* '''Committal:''' if a problem is discovered with taproot before activation, users and developers may need to intervene to prevent the problem from being exploited.<br />
* '''Unnecessary delay:''' without miner cooperation, it will take two years to get the taproot features, which may delay other useful Bitcoin work or cause developers to spend time implementing unnecessary intermediate solutions (e.g. 2pECDSA rather than MuSig).<br />
* '''Chaos risk:''' if some users later decide to <code>lockinontimeout=true</code> with a date before the original two-year end, they all need to choose the same date or users choosing a date with insufficient support could be tricked into accepting non-spendable bitcoins. It may be possible to mitigate this by building support for an acceleration target date even before the initial version is released.</div>Hardinghttps://en.bitcoin.it/w/index.php?title=Consensus_versions&diff=68202Consensus versions2020-09-21T12:02:20Z<p>Harding: Add nLockTime fork</p>
<hr />
<div>{| class="wikitable"<br />
! TENTATIVE semantic version number || Software release || Change type || BIP(s)<br />
|-<br />
| 0.1.0 || wxBitcoin 0.1.0 || original<br />
|-<br />
| ??? || wxBitcoin 0.1.6 || softfork || added nLockTime enforcement<ref>[https://bitcoin.stackexchange.com/a/99104/21052 Was the addition of nLockTime timelocks a hard fork?]<br>Bitcoin StackExchange<br>Retrieved 2020-09-21</ref><br />
|-<br />
| 0.1.1 || wxBitcoin 0.3.1 || softfork || mostly-redundant 1 MB block size limit<br />
|-<br />
| 0.1.2 || wxBitcoin 0.3.5 || softfork || fixes CVE-2010-5141<br />
|-<br />
| 0.1.3 || wxBitcoin 0.3.6 || softfork || OP_NOPs made explicit<br />
|-<br />
| 0.2.0 || wxBitcoin 0.3.7 || hardfork || scriptSig + scriptPubKey evaluations separated<br />
|-<br />
| 0.2.1 || wxBitcoin 0.3.10 || softfork || fixes CVE-2010-5137 and CVE-2010-5139<br />
|-<br />
| 0.2.2 || wxBitcoin 0.3.12 || softfork || fixes CVE-2010-5138<br />
|-<br />
| 1.0.0 || Bitcoin Core 0.6.0 || softfork || fixes CVE-2012-1909<br />
|-<br />
| 1.1.0 || Bitcoin Core 0.6.0 || softfork || BIP16<br />
|-<br />
| 1.1.1 || Bitcoin Core 0.7.0 || softfork || BIP34<br />
|-<br />
| 1.1.2 || Bitcoin Core 0.8.1 || softfork || fixes CVE-2013-3220 by adding txid change limit<br />
|-<br />
| 2.0.0 || Bitcoin Core 0.8.1 || hardfork || removed BDB lock limit & txid change limit<br />
|-<br />
| 2.0.1 || Bitcoin Core 0.9.2 || softfork || BIP42<br />
|-<br />
| 2.1.0 || Bitcoin Core 0.10.0 || softfork || BIP66<br />
|-<br />
| 2.2.0 || Bitcoin Core 0.10.4 || softfork || BIP65<br />
|-<br />
| 2.3.0 || Bitcoin Core 0.12.1 || softfork || BIP68, BIP112, BIP113<br />
|-<br />
| 2.4.0 || Bitcoin Core 0.13.1 || softfork || BIP141, BIP143, BIP147<br />
|-<br />
| 2.4.1 || Bitcoin Core UASF 0.14.0 || softfork || BIP148<br />
|-<br />
| 2.4.2 || Bitcoin Core 0.16.3 || softfork || fixes CVE-2018-17144<br />
|}</div>Hardinghttps://en.bitcoin.it/w/index.php?title=Scalability_FAQ&diff=68168Scalability FAQ2020-08-26T17:56:34Z<p>Harding: /* What is the short history of the block size limit? */ Correction: there originally was a specific block size limit (reported via reddit)</p>
<hr />
<div>Answers to commonly-asked questions and concerns about scaling Bitcoin, including “level 1” solutions such as increasing the block size and “level 2” solutions such as the proposed Lightning network.<br />
<br />
== Background ==<br />
<br />
Questions about how Bitcoin currently works (related to scaling) as well as questions about the technical terminology related to the scaling discussion.<br />
<br />
=== What is the short history of the block size limit? ===<br />
<br />
''Note: the software now called Bitcoin Core was previously simply called “Bitcoin”.<ref>[https://bitcoin.org/en/release/v0.9.0#rebranding-to-bitcoin-core Bitcoin Core 0.9.0 release notes], Bitcoin.org, 19 March 2014</ref> To avoid confusion with the Bitcoin system, we’ll use the Bitcoin Core name.''<br />
<br />
Bitcoin Core was initially released with a 32 MiB block size limit.<ref>[https://bitcointalk.org/index.php?topic=68121 Earliest known Bitcoin code], [https://github.com/trottier/original-bitcoin/blob/92ee8d9a994391d148733da77e2bbc2f4acc43cd/src/main.h#L17 src/main.h:17] and [https://github.com/trottier/original-bitcoin/blob/92ee8d9a994391d148733da77e2bbc2f4acc43cd/src/main.cpp#L1160 src/main.cpp:1160]</ref><br />
<br />
Around 15 July 2010, Satoshi Nakamoto changed Bitcoin Core’s mining code so that it wouldn’t create any blocks larger than 990,000 bytes.<ref>[https://github.com/bitcoin/bitcoin/commit/a30b56ebe76ffff9f9cc8a6667186179413c6349 Bitcoin Core commit a30b56e], Satoshi Nakamoto, 15 July 2010</ref><br />
<br />
Two months later on 7 September 2010, Nakamoto changed Bitcoin Core’s consensus rules to reject blocks larger than 1,000,000 bytes (1 megabyte) if their block height was higher than 79,400.<ref>[https://github.com/bitcoin/bitcoin/commit/8c9479c6bbbc38b897dc97de9d04e4d5a5a36730 Bitcoin Core commit 8c9479c], Satoshi Nakamoto, 7 September 2010</ref> (Block 79,400 was later produced on 12 September 2010.<ref>[https://www.biteasy.com/blockchain/blocks/000000000021d821ec06be7173f413690bc5c4bc648dfa70b3b6763236f055b7 Block height 79400], dated 12 September 2010</ref>)<br />
<br />
Neither the July nor the September commit message explains the reason for the limit, although the careful attempt to prevent a fork may indicate Nakamoto didn’t consider it an emergency.<br />
<br />
Nakamoto’s subsequent statements supported raising the block size at a later time<ref>[https://bitcointalk.org/index.php?topic=1347.msg15139#msg15139 Increasing the block size when needed], Satoshi Nakamoto, 3 October 2010</ref>, but he never publicly specified a date or set of conditions for the raise.<br />
<br />
Statements by Nakamoto in the summer of 2010 indicate he believed Bitcoin could scale to block sizes far larger than 1 megabyte. For example, on 5 August 2010, he wrote that "[W]hatever size micropayments you need will eventually be practical. I think in 5 or 10 years, the bandwidth and storage will seem trivial" and "[microtransactions on the blockchain] can become more practical ... if I implement client-only mode and the number of network nodes consolidates into a smaller number of professional server farms" <ref>[https://bitcointalk.org/index.php?topic=532.msg6306#msg6306 the number of network nodes consolidates into a smaller number of professional server farms]</ref>. <br />
<br />
These statements suggest that the intended purpose of the 1 megabyte limit was not to keep bandwidth and storage requirements for running a Bitcoin node low enough to be practical for personal computers and consumer-grade internet connections, and that the limit was intended to be lifted to accommodate greater demand for transactional capacity.<br />
<br />
Yet in one of Nakamoto's final public messages, he wrote that "Bitcoin users might get increasingly tyrannical about limiting the size of the chain so it's easy for lots of users and small devices."<ref>[https://bitcointalk.org/index.php?topic=1790.msg28917#msg28917 BitDNS and Generalizing Bitcoin], Satoshi Nakamoto, 10 December 2010</ref> This statement suggests that Nakamoto was aware of the value of limiting the block size and that he correctly predicted it was an issue that Bitcoin users would need to consider in the future---a future Nakamoto may have known would not include him.<br />
<br />
=== What is this Transactions Per Second (TPS) limit? ===<br />
<br />
The current block size limit is 1,000,000 bytes (1 megabyte)<ref>[https://github.com/bitcoin/bitcoin/blob/41076aad0cbdfa4c4cf376e345114a5c29086f81/src/consensus/consensus.h#L10 <code>MAX_BLOCK_SIZE</code>], retrieved 2 July 2015</ref>, although a small amount of that space (such as the block header) is not available to store transactions.<ref>[https://bitcoin.org/en/developer-reference#serialized-blocks Block serialization description], Bitcoin.org Developer Reference</ref><br />
<br />
Bitcoin transactions vary in size depending on multiple factors, such as whether they’re spending single-signature inputs or a multiple signature inputs, and how many inputs and outputs they have.<br />
<br />
The simple way to calculate the number of Transactions Per Second (TPS) Bitcoin can handle is to divide the block size limit by the expected average size of transactions, divided by the average number of seconds between blocks (600). For example, if you assume average transactions are 250 bytes,<br />
<br />
<pre>6.6 TPS = 1,000,000 / 250 / 600</pre><br />
<br />
There seems to be general agreement that Bitcoin in 2015 can handle about 3 TPS with the current average size of transactions.<ref>[http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-May/007986.html Max TPS based on current average transaction size], Mike Hearn, 8 May 2015</ref><ref name="maxwell_not_proposing">[https://www.reddit.com/r/Bitcoin/comments/39yaod/bitcoinorg_position_on_hard_forks/cs7qz5c "No one proposing 3 TPS forever"], Gregory Maxwell, 15 June 2015</ref><br />
<br />
Both old estimates<ref>[[Scalability]], Bitcoin Wiki, retrieved 7 July<br />
2015</ref> and new estimates<ref name="garzik_bip" /> place the<br />
theoretical maximum at 7 TPS with current Bitcoin consensus rules<br />
(including the 1MB block size limit).<br />
<br />
=== What do devs mean by the scaling expressions O(1), O(n), O(n<sup>2</sup>), etc…? ===<br />
<br />
[https://en.wikipedia.org/wiki/Big_O_notation Big O notation] is a shorthand used by computer scientists to describe how well a system scales. Such descriptions are rough approximations meant to help predict potential problems and evaluate potential solutions; they are not usually expected to fully capture all variables.<br />
<br />
* '''O(1)''' means a system has roughly the same properties no matter how big it gets.<br />
* '''O(n)''' means that a system scales linearly: doubling the number of things (users, transactions, etc.) doubles the amount of work.<br />
* '''O(n<sup>2</sup>)''' means that a system scales quadratically : doubling (2x) the number of things quadruples (4x) the amount of work. Often written O(n^2) is places without convenient superscripts.<br />
* Additional examples may be found in the [https://en.wikipedia.org/wiki/Big_O_notation#Orders_of_common_functions Wikipedia article]<br />
<br />
The following subsections show cases where big O notation has been applied to the scaling Bitcoin transaction volume.<br />
<br />
==== O(1) block propagation ====<br />
<br />
Bitcoin Core currently relays unconfirmed transactions and then later relays blocks containing many of the same transactions. This redundant relay can be eliminated to allow miners to propagate large blocks very quickly to active network nodes, and would also significantly reduce miner need for peak bandwidth. Currently most miners use a network<ref name="block_relay_net">[http://bitcoinrelaynetwork.org/ Matt Corallo's block relay network]</ref> that is about 25x more efficient than stock Bitcoin Core<ref>[https://gist.github.com/gavinandresen/e20c3b5a1d4b97f79ac2#i-know-that-you-know IBLT design document], Gavin Andresen, 11 August 2014</ref> and almost equally as effective as O(1) block propagation for current block sizes.<br />
<br />
<br />
==== O(n<sup>2</sup>) network total validation resource requirements with decentralization level held constant ====<br />
<br />
[[File:On2_scaling_illustrated.png|thumb|right|visualization of O(n<sup>2</sup>) scaling]]<br />
<br />
While the validation effort required per full node simply grows in O(n), the combined validation effort of all nodes grows by O(n<sup>2</sup>) with decentralization being held constant. For a single node, it takes twice as many resources to process the transactions of twice as many users, while for all nodes it takes a combined four times as many resources to process the transactions of twice as many users assuming the number of full nodes increases in proportion to the number of users.<br />
<br />
Each on-chain Bitcoin transaction needs to be processed by each full node. If we assume that a certain percentage of users run full nodes (''n'') and that each user creates a certain number of transactions on average (''n'' again), then the network’s total resource requirements are <code>n<sup>2</sup> = n * n</code>. In short, this means that the aggregate cost of keeping all transactions on-chain quadruples each time the number of users doubles.<ref>[http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-June/009199.html Total system cost], Dr. Adam Back, 28 June 2015</ref> For example,<br />
<br />
* Imagine a network starts with 100 users and 2 total nodes (a 2% ratio).<br />
<br />
* The network doubles in users to 200. The number of nodes also doubles to 4 (maintaining a 2% ratio of decentralized low-trust security). However, double the number of users means double the number of transactions, and each node needs to process ''every'' transaction---so each node now does double work with its bandwidth and its CPU. With double the number of nodes and double the amount of work per node, total work increases by four times.<br />
<br />
* The network doubles again: 400 users, 8 nodes (still 2% of total), and 4 times the original workload per node for a total of 16 times as much aggregate work as the original.<br />
<br />
* Another doubling: 800 users, 16 nodes (still 2%), and 8 times the original workload per node for a total of 64 times aggregate work as the original.<br />
<br />
* Another doubling: 1,600 users—sixteen times the original---with 32 nodes (still 2%), and 16 times the original workload per node. The aggregate total work done by nodes is 256 times higher than it was originally.<br />
<br />
===== Criticisms =====<br />
<br />
Emphasis on the total validation resource requirements is suggested by some individuals to be misleading, as they claim it obfuscates the growth of the supporting base of full nodes that the total validation resource effort is split amongst. The validation resource effort made by each individual full node increases at O(n), and critics say this is the only pertinent fact with respect to scaling. Some critics also point out that the O(n<sup>2</sup>) network total validation resource requirements claim is assuming decentralization must be held constant as the network scales, and that this is not a founding principle of Bitcoin.<br />
<br />
=== What’s the difference between on-chain and off-chain transactions? ===<br />
<br />
On-chain Bitcoin transactions are those that appear in the Bitcoin block chain. Off-chain transactions are those that transfer ownership of bitcoins without putting a transaction on the block chain.<br />
<br />
Common and proposed off-chain transactions include:<br />
<br />
* '''Exchange transactions:''' when you buy or sell bitcoins, the exchange tracks ownership in a database without putting data in the block chain. Only when you deposit or withdraw bitcoins does the transaction appear on the block chain.<br />
* '''Web wallet internal payments:''' many web wallets allow users of the service to pay other users of the same service using off-chain payments. For example, when one Coinbase user pays another Coinbase user.<br />
* '''Tipping services:''' most tipping services today, such as ChangeTip, use off-chain transactions for everything except deposits and withdrawals.<ref>[https://www.changetip.com/fees ChangeTip fees], retrieved 3 July 2015</ref><br />
* '''Payment channels:''' channels are started using one on-chain transaction and ended using a second on-chain transaction.<ref>[https://bitcoin.org/en/developer-guide#micropayment-channel Micropayment channels], Bitcoin.org Developer Guide</ref> In between can be an essentially unlimited number of off-chain transactions as small as a single satoshi (1/100,000,000th of a bitcoin). Payment channels include those that [https://bitcoinj.github.io/working-with-micropayments exist today] as well as proposed hub-and-spoke channels and the more advanced [http://lightning.network/ Lightning network].<br />
<br />
Approximately 90% to 99% of all bitcoin-denominated payments today are made off-chain.<ref>[http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-June/008844.html Pure off-chain is a weak form of layer 2], Dr. Adam Back, 19 June 2015</ref><br />
<br />
=== What is a fee market? ===<br />
<br />
When you create a Bitcoin transaction, you have the option to pay a [[transaction fee]]. If your software is flexible, you can pay anything from zero fees (a free transaction) to 100% of the value of the transaction (spend-to-fees). This fee is comparable to a tip. The higher it is, the bigger the incentive of the miners to incorporate your transaction into the next block.<br />
<br />
When miners assemble a block, they are free to include whatever transactions they wish. They usually include as many as possible up to the maximum block size and then prioritize the transactions that pay the most fees per kilobyte of data.<ref name="fee_pri">[https://bitcointalk.org/index.php?topic=95837.0 Fee prioritization patch], Gavin Andresen, 26 July 2012</ref> This confirms higher-fee transactions before lower-fee transactions. If blocks become full on a regular basis, users who pay a fee that's too small will have to wait a longer and longer time for their transactions to confirm. At this point, a demand-driven fee market may arise where transactions that pay higher fees get confirmed significantly faster than transactions that pay low fees.<ref name="todd_coinwallet">[https://gist.github.com/petertodd/8e87c782bdf342ef18fb Comments on the CoinWallet.eu tx-flood stress-test], Peter Todd, 22 June 2015</ref><ref name="garzik_bip" /><br />
<br />
In a competitive market, prices are driven by supply and demand and the emerging equilibrium price asymptotically approaches marginal costs over time. However, the current version of Bitcoin limits the supply to 1 MB per block, only allowing demand to adjust. To establish a free market, one would need to come up with a mechanism that allows the number of included transactions per block to adjust dynamically as well. The design of such a mechanism, however, is not trivial. Simply allowing individual miners to include as many transactions as they want is problematic due to the externalities<ref name="exernality">[https://en.wikipedia.org/wiki/Externality Definition of externality], Wikipedia, 26 January 2016</ref> of including additional blocks and explained further in section [[#Should miners be allowed to decide the block size?|'should miners be allowed to decide the block size?']] .<br />
<br />
=== What is the most efficient way to scale Bitcoin? ===<br />
<br />
Remove its decentralization properties, specifically decentralized mining and decentralized full nodes. Mining wastes enormous amounts of electricity to provide a decentralized ledger and full nodes waste an enormous amount of bandwidth and CPU time keeping miners honest.<br />
<br />
If users instead decided to hand authority over to someone they trusted, mining and keeping miners honest wouldn’t be needed. This is how Visa, MasterCard, PayPal, and the rest of the centralized payment systems works—users trust them, and they have no special difficulty scaling to [[scalability|millions of transactions an hour]]. It’s very efficient; it isn’t decentralized.<br />
<br />
=== What is a hard fork, and how does it differ from other types of forks? ===<br />
<br />
The word fork is badly overloaded in Bitcoin development.<br />
<br />
* '''[[hardfork|Hard fork]]:''' a change to the system which is not backwards compatible. Everyone needs to upgrade or things can go wrong.<br />
* '''[[softfork|Soft fork]]:''' a change to the system which is backwards compatible as long as a majority of miners enforce it. Full nodes that don’t upgrade have their security reduced.<br />
* '''Chain fork:''' when there are two are more blocks at the same height on a block chain. This typically happens a few times a week by accident, but it can also indicate more severe problems.<br />
* '''[https://en.wikipedia.org/wiki/Fork_%28software_development%29 Software fork]:''' using the code from an open source project to create a different project.<br />
* '''[https://help.github.com/articles/fork-a-repo/ Git/GitHub fork]:''' a way for developers to write and test new features before contributing them to a project.<br />
<br />
(There are other types of software-related forks, but they don’t tend to cause as much confusion.)<br />
<br />
=== What are the block size soft limits? ===<br />
<br />
Bitcoin Core has historically come pre-configured to limit blocks it mines to certain sizes.<ref name="fee_pri" /> These “limits” aren’t restrictions placed on miners by other miners or nodes, but rather configuration options that help miners produce reasonably-sized blocks.<br />
<br />
Miners can change their soft limit size (up to 1 MB) using <code>-blockmaxsize=&lt;size&gt;</code><br />
<br />
Default soft limits at various times:<br />
<br />
* '''July 2012:''' <code>-blockmaxsize</code> option created and set to default 250 KB soft limit<ref>[https://github.com/bitcoin/bitcoin/commit/c555400ca134991e39d5e3a565fcd2215abe56f6 Bitcoin Core commit c555400], Gavin Andresen, 12 July 2012</ref><br />
* '''November 2013:''' Raised to 750KB<ref>[https://github.com/bitcoin/bitcoin/commit/ad898b40aaf06c1cc7ac12e953805720fc9217c0 Bitcoin Core commit ad898b40], Gavin Andresen, 27 November 2013</ref><br />
* '''June 2015:''' Raise to 1 MB suggested<ref>[https://github.com/bitcoin/bitcoin/pull/6231 Bitcoin Core pull #6231], Chris Wheeler, 4 June 2015</ref><br />
<br />
== General Block Size Increase Theory ==<br />
<br />
Questions about increasing the block size in general, not related to any<br />
specific proposal.<br />
<br />
==== Why are some people in favor of keeping the block size at 1 MB forever? ====<br />
<br />
It is commonly claimed<ref name="garzik_bip" /><ref>[https://epicenterbitcoin.com/podcast/082/ Epicenter Bitcoin podcast #82], Mike Hearn (interviewed), 8 June 2015</ref> that there are people opposed to ever raising the maximum block size limit, but no Bitcoin developers have suggested keeping the maximum block size at one megabyte forever.<ref name="maxwell_not_proposing" /><br />
<br />
All developers support raising the maximum size at some point<ref>[https://www.reddit.com/r/Bitcoin/comments/39kqzs/how_about_a_softfork_optin_blocksize_increase/cs5hj8l Nothing magic about 1MB], Dr. Adam Back, 13 June 2015</ref><ref>[http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-May/008328.html Regarding size-independent new block propagation], Pieter Wuille, 28 May 2015</ref>—they just disagree about whether now is the correct time.<br />
<br />
==== Should miners be allowed to decide the block size? ====<br />
<br />
A block may include as little as a single transaction, so miners can always restrict block size. Letting miners choose the maximum block size is more problematic for several reasons:<br />
<br />
# '''Miners profit, others pay the cost:''' bigger blocks earn miners more fees, but miners don’t need to store those blocks for more than a few days.<ref>[https://github.com/bitcoin/bitcoin/pull/5863 Bitcoin Core pull #5863 adding pruning functionality], Suhas Daftuar et al., 6 March 2015</ref> Other users who want full validation security, or who provide services to lightweight wallets, pay the costs of downloading and storing those larger blocks.<br />
# '''Bigger miners can afford more bandwidth:''' each miner needs to download every transaction that will be included in block,<ref name="maxwell_correcting_assumptions" /> which means that they all need to pay for high-speed connections. However, a miner with 8.3% of total hash rate can take that cost out of the about 300 BTC they make a day, while a miner with only 0.7% of total hash rate has to take that cost out of only 25 BTC a day. This means bigger miners may logically choose to make bigger blocks even though it may further centralize mining.<br />
# '''Centralized hardware production:''' only a few companies in the world produce efficient mining equipment, and many of them have chosen to stop selling to the public.<ref>[http://blogs.wsj.com/venturecapital/2014/09/05/for-kncminer-time-to-forget-selling-bitcoin-machines-to-at-home-miners/ KnCMiner to stop selling to home miners], Wall Street Journal, Yuliya Chernova, 5 September 2014</ref> This prevents ordinary Bitcoin users from participating in the process even if they were willing to pay for mining equipment.<br />
# '''Voting by hash rate favors larger miners:''' voting based on hash rate allows the current hash rate majority (or super-majority) to enforce conditions on the minority. This is similar to a lobby of large businesses being able to get laws passed that may hurt smaller businesses.<ref>[https://www.reddit.com/r/Bitcoin/comments/39kzyt/draft_bip_100_soft_fork_block_size_increase/cs5gvak Miners choosing the block size limit is ill-advised], Meni Rosenfeld, 13 June 2015</ref><br />
# '''Miners may not care about users:''' this was demonstrated during the [[July 2015 Forks]] where even after miners lost over $50,000 USD in income from mining invalid chains, and even after they were told that long forks harm users, they continued to mine improperly.<ref>[https://bitcointalk.org/index.php?topic=700411.msg11790734#msg11790734 Intention to continue SPV mining], Wang Chun, 4 July 2015</ref><br />
<br />
However, there are also possible justifications for letting miners choose the block size:<br />
<br />
# '''Authenticated participants:''' miners are active participants in Bitcoin, and they can prove it by adding data to the blocks they create.<ref>[https://bitcoin.org/en/developer-reference#term-coinbase-field Coinbase field], Bitcoin.org Developer Reference</ref> It is much harder to prove people on Reddit, BitcoinTalk, and elsewhere are real people with an active stake in Bitcoin.<br />
# '''Bigger blocks may cost miners:''' small miners and poorly-connected miners are at a disadvantage if larger blocks are produced<ref name="wuille_centralization" />, and even large and well-connected miners may find that large blocks reduce their profit percentage if the cost of bandwidth rises too high or their stale rate increases.<ref>[http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-May/008355.html F2Pool block size concerns], Chun Wang, 29 May 2015</ref><br />
<br />
==== How could a block size increase affect user security? ====<br />
<br />
Bitcoin’s security is highly dependent on the number of active users who protect their bitcoins with a full node like Bitcoin Core. The more active users of full nodes, the harder it is for miners to trick users into accepting fake bitcoins or other frauds.<ref>[https://medium.com/@lopp/bitcoin-nodes-how-many-is-enough-9b8e8f6fd2cf Bitcoin nodes: how many is enough?], Jameson Lopp, 7 June 2015</ref><br />
<br />
Full nodes need to download and verify every block, and most nodes also store blocks plus relay transactions, full blocks, and filtered blocks to other users on the network. The bigger blocks become, the more difficult it becomes to do all this, so it is expected that bigger blocks will both reduce the number of users who currently run full nodes and suppress the number of users who decide to start running a full node later.<ref>[https://www.reddit.com/r/Bitcoin/comments/3bae2d/amir_taaki_on_raising_the_block_size_a_lot_of/cslcgmw Block size increases-only will create problems], Dr. Adam Back, 28 June 2015</ref><br />
<br />
In addition, full blocks may increase mining centralization<ref name="wuille_centralization" /> at a time when mining is already so centralized that it makes it easy to reverse transactions which have been confirmed multiple times.<ref>[http://bitcoin.stackexchange.com/questions/32562/when-to-worry-about-1-confirmation-payments/32564#32564 When to worry about one-confirmation payments], David A. Harding, 17 November 2014</ref><br />
<br />
==== How could larger blocks affect proof-of-work (POW) security? ====<br />
<br />
Proof of work security is dependent on how much money miners spend on mining equipment. However, to effectively mine blocks, miners also need to spend money on bandwidth to receive new transactions and blocks created by other miners; CPUs to validate received transactions and blocks; and bandwidth to upload new blocks. These additional costs don’t directly contribute to POW security.<ref name="maxwell_correcting_assumptions">[https://www.reddit.com/r/Bitcoin/comments/39tgno/letting_miners_vote_on_the_maximum_block_size_is/cs6rek5 Correcting wrong assumptions about mining], Gregory Maxwell, 15 June 2015</ref><br />
<br />
As block sizes increase, the amount of bandwidth and CPU required also increases. If block sizes increase faster than the costs of bandwidth and CPU decrease, miners will have less money for POW security relative to the gross income they earn.<br />
<br />
In addition, larger blocks have a higher risk of becoming stale (orphaned)<ref name="rusty_dsl" />, which directly correlates to lost POW security. For example, if the network average stale rate is 10%, then 10% of POW performed isn't protecting transactions on the block chain.<br />
<br />
Conversely, larger blocks that result in a lower per transaction fee can increase the demand for on-chain transactions, and result in total transaction fees earned by miners increasing despite a lower average transaction fee. This would increase network security by increasing the revenue that supports Proof of Work generation. <br />
<br />
Without an increase in the block size from 1 megabyte, Bitcoin needs $1.50 worth of BTC paid in fees per transaction once block subsidies disappear to maintain current mining revenue and economic expenditure on network security. The required fee per transaction for maintaining current economic expenditure levels once the subsidy disappears decreases as the block size, and with it the maximum on-chain transaction throughput, increases. <br />
<br />
As a result of the sensitivity of demand to price increases, growth in the Bitcoin economy, and thus growth in the fees paid to secure the Bitcoin network, could be stunted if the block size is not allowed to increase sufficiently.<br />
<br />
=== What happens if blocks aren't big enough to include all pending transactions? ===<br />
<br />
This is already the case more often than not<ref>[http://statoshi.info/dashboard/db/transactions?from=1433297061121&to=1435889061123 Statoshi.info mempool queue June to July 2015]</ref>, so we know that miners will simply queue transactions. The transactions eligible for block inclusion that pay the highest fee per kilobyte will be confirmed earlier than transactions that pay comparatively lower fees.<ref name="fee_pri" /><br />
<br />
Basic economic theory tells us that increases in price reduce economic demand, ceteris paribus. Assuming that larger blocks would not cause a loss of demand for on-chain transaction processing due to a perceived loss of the network's decentralization and censorship resistance, blocks that are too small to include all pending transactions will result in demand for on-chain transaction processing being less than it would be if blocks were large enough include all pending transactions.<br />
<br />
What happens from there is debated:<br />
<br />
* BitcoinJ lead developer Mike Hearn believes there would be “crashing nodes, a swelling transaction backlog, a sudden spike in double spending, [and] skyrocketing fees.”<ref>[https://medium.com/@octskyward/crash-landing-f5cc19908e32 Crash Landing], Mike Hearn, 7 May 2015</ref><br />
* Bitcoin Foundation chief scientist Gavin Andresen believes that the “average transaction fee paid will rise, people or applications unwilling or unable to pay the rising fees will stop submitting transactions, [and] people and businesses will shelve plans to use Bitcoin, stunting growth and adoption.” <ref>[https://github.com/bitcoin/bitcoin/pull/6341 Bitcoin Core pull #6341], Gavin Andresen, 26 June 2015</ref><br />
* Bitcoin Core developer Pieter Wuille replies to Andresen’s comment above: “Is it fair to summarize this as ‘Some use cases won’t fit any more, people will decide to no longer use the blockchain for these purposes, and the fees will adapt.’? I think that is already happening […] I don’t think we should be afraid of this change or try to stop it.” <ref>[http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-June/009098.html The need for larger blocks], Pieter Wuille, 26 June 2015</ref><br />
* Bitcoin Core developer Jeff Garzik writes, "as blocks get full and the bidding war ensues, the bitcoin user experience rapidly degrades to poor. In part due to bitcoin wallet software’s relative immaturity, and in part due to bitcoin’s settlement based design, the end user experience of their transaction competing for block size results in erratic, and unpredictably extended validation times."<ref name="garzik_bip" /><br />
<br />
== Specific Scaling Proposals ==<br />
<br />
=== Andresen-Hearn Block Size Increase Proposals ===<br />
<br />
Questions about the series of related proposals by Gavin Andresen and Mike Hearn to use a hard fork to raise the maximum block size, thereby allowing miners to include more on-chain transactions. As of July 2015, the current focus is [https://github.com/bitcoin/bips/pull/163 BIP101].<br />
<br />
==== What is the major advantage of this proposal? ====<br />
<br />
''Bitcoin can support many more users.'' Assuming earliest possible adoption, 250 bytes per on-chain transaction, 144 blocks per day, and 2 transaction a day per user, Bitcoin can support about,<br />
<br />
* 288,000 users in 2015<br />
* 2,304,000 users in 2016 (800% increase)<br />
* 4,608,000 in 2018 (1,600%)<br />
* 9,216,000 in 2020 (3,200%)<br />
* 18,432,000 in 2022 (6,400%)<br />
* 36,864,000 in 2024 (12,800%)<br />
* 73,728,000 in 2026 (25,600%)<br />
* 147,456,000 in 2028 (51,200%)<br />
* 294,912,000 in 2030 (102,400%)<br />
* 589,824,000 in 2032 (204,800%)<br />
* 1,179,648,000 in 2034 (409,600%<br />
* 2,359,296,000 in 2036 (819,200%)<br />
<br />
==== What is the major disadvantage of this proposal? ====<br />
<br />
''The total cost of remaining decentralized will be high.'' Assuming earliest possible adoption and that the ratio of total users to full node operators remains the same as today, the total estimated amount of work necessary to maintain the decentralized system under the [[#O.28n2.29_network_total_validation_resource_requirements|O(<sup>2</sup>) scaling model]] will be,<br />
<br />
* 100% of today’s work in 2015<br />
* 6,400% in 2016<br />
* 25,600% in 2018<br />
* 102,400% in 2020<br />
* 409,600% in 2022<br />
* 1,638,400% in 2024<br />
* 6,553,600% in 2026<br />
* 26,214,400% in 2028<br />
* 104,857,600% in 2030<br />
* 419,430,400% in 2032<br />
* 1,677,721,600% in 2034<br />
* 6,710,886,400% in 2036<br />
<br />
For example, if the total amount spent on running full nodes today (not counting mining) is $100 thousand per year, the estimated cost for the same level of decentralization in 2036 will be $6.7 trillion per year if validation costs stay the same. (They'll certainly go down, but algorithmic and hardware improvements probably won't eliminate an approximate 6,710,886,400% cost increase.)<br />
<br />
==== What are the dangers of the proposed hard fork? ====<br />
<br />
Under the current proposal, 75% of miners must indicate that they agree to accept blocks up to 8 MB in size.<ref name="bip101">[https://github.com/bitcoin/bips/pull/163 BIP101], Gavin Andresen, 24 June 2016</ref> After the change goes into effect, if any miner creates a block larger than 1 MB, all nodes which have not upgraded yet will reject the block.<ref>[https://bitcoin.org/en/developer-guide#consensus-rule-changes Consensus rule changes], Bitcoin.org Developer Guide</ref><br />
<br />
If all full nodes have upgraded, or very close to all nodes, there should be no practical effect. If a significant number of full nodes have not upgraded, they will continue using a different block chain than the upgraded users, with the following consequences:<br />
<br />
* Bitcoins received from before the fork can be spent twice, once on both sides of the fork. This creates a high double spend risk.<br />
* Bitcoins received after the fork are only guaranteed to be spendable on the side of the fork they were received on. This means some users will have to lose money to restore Bitcoin to a single chain.<br />
<br />
Users of hosted wallets (Coinbase, BlockChain.info, etc.) will use whatever block chain their host chooses. Users of lightweight P2P SPV wallets will use the [[Thin Client Security|longest chain they know of]], which may not be the actual longest chain if they only connect to nodes on the shorter chain. Users of non-P2P SPV wallets, like Electrum, will use whatever chain is used by the server they connect to.<br />
<br />
If a bad hard fork like this happens, it will likely cause large-scale confusion and make Bitcoin very hard to use until the situation is resolved.<br />
<br />
==== What is the deployment schedule for BIP 101? ====<br />
<br />
* The patch needs to be accepted into Bitcoin Core, Bitcoin XT, or both.<br />
* If accepted into Bitcoin Core, miners using that software will need to upgrade (this probably requires a new released version of Bitcoin Core). If accepted only into Bitcoin XT, miners will need to switch to using XT.<br />
* After 75% of miners have upgraded, 8MB blocks will become allowed at the the latest of (1) 11 January 2016 or (2) two weeks after the 75% upgrade threshold.<ref name="bip101" /><br />
* After the effective date has passed, any miner may create a block larger than 8MB. When a miner does this, upgraded full nodes will accept that block and non-upgraded full nodes will reject it, forking the network.<ref name="bip101" /> See [[#What_are_the_dangers_of_the_proposed_hard_fork.3F|hard fork dangers]] for what his might mean.<br />
<br />
==== Will miners go straight from 1 MB blocks to 8 MB blocks? ====<br />
<br />
That would be highly unlikely. Uploading an 8 MB block currently takes significantly more time than uploading a 1 MB block<ref name="rusty_dsl">[http://rusty.ozlabs.org/?p=509 Mining on a home DSL connection test results], Rusty Russell, 19 June 2015</ref>, even with the roughly 25x reduction in size available from use of Matt Corallo’s block relay network.<ref name="block_relay_net" /><br />
<br />
The longer it takes to upload a block, the higher the risk it will become a stale block—meaning the miner who created it will not receive the block subsidy or transaction fees (currently about 25 BTC per block).<br />
<br />
However, if technology like Invertible Bloom Lookup Tables (IBLTs) is deployed and found to work as expected<ref name="iblt">[https://gist.github.com/gavinandresen/e20c3b5a1d4b97f79ac2 O(1) block propagation], Gavin Andresen, 8 August 2014</ref>, or if mining [[#What_is_the_most_efficient_way_to_scale_Bitcoin.3F|centralizes further]], adding additional transactions may not have a significant enough cost to discourage miners from creating full blocks. In that case, blocks will be filled as soon as there are enough people wanting to make transactions paying the default relay fee<ref>[https://github.com/bitcoin/bitcoin/pull/3305 Bitcoin Core pull #3305 dropping default fees], Mike Hearn, 22 November 2013</ref> of 0.00001000 BTC/kilobyte.<br />
<br />
==== What tests have been performed related to this proposal? ====<br />
<br />
* '''20MB block processing''' (Gavin Andresen) “if we increased the maximum block size to 20 megabytes tomorrow, and every single miner decided to start creating 20MB blocks and there was a sudden increase in the number of transactions on the network to fill up those blocks… the 0.10.0 version of [Bitcoin Core] would run just fine.”<ref>[http://gavintech.blogspot.com/2015/01/twenty-megabytes-testing-results.html Twenty megabyte block testing], Gavin Andresen, 20 January 2015</ref> (ellipses in original)<br />
* '''Mining &amp; relay simulation''' (Gavin Andresen) “if blocks take 20 seconds to propagate, a network with a miner that has 30% of the hashing power will get 30.3% of the blocks.”<ref>[http://gavinandresen.ninja/are-bigger-blocks-better-for-bigger-miners Are bigger blocks better for bigger miners?], Gavin Andresen, 22 May 2015</ref><br />
* '''Mining on a home DSL connection''' (Rusty Russell) “Using the rough formula of 1-exp(-t/600), I would expect orphan rates of 10.5% generating 1MB blocks, and 56.6% with 8MB blocks; that’s a huge cut in expected profits.”<ref name="rusty_dsl" /><br />
* '''Mining centralization pressure''' (Pieter Wuille) “[This] does very clearly show the effects of larger blocks on centralization pressure of the system.”<ref name="wuille_centralization">[http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-June/008581.html Mining centralization pressure from non-uniform propagation speed], Pieter Wuille, 12 June 2015</ref><br />
<br />
<br />
=== Garzik Miner Block Size Voting Proposal (AKA BIP100) ===<br />
<br />
''Note, BIP 100 is the marketing name for this proposal. No BIP number<br />
has yet been publicly requested, and the number assigned is unlikely to<br />
be 100.<ref>[http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2014-May/005756.html<br />
Prenumbered BIP naming], Gregory Maxwell, 12 May 2014</ref>''<br />
<br />
Questions related to Jeff Garzik's proposal<ref name="garzik_bip">[http://gtf.org/garzik/bitcoin/BIP100-blocksizechangeproposal.pdf Draft BIP: decentralized economic policy], Jeff Garzik, 12 June 2015 (revised 15 June 2015)</ref> to allow miners to vote on raising and lowering the maximum block size.<br />
<br />
==== What does this proposal do? ====<br />
<br />
# It creates a one-time hard fork that does not automatically change the maximum block size.<br />
<br />
# It allows miners to vote to increase or decrease the maximum block size within the range of 1MB to 32MB. These changes are neither hard forks nor soft forks, but simply rules that all nodes should know about after the initial hard fork.<br />
<br />
==== Does it reduce the risk of a hard fork? ====<br />
<br />
Hard forks are most dangerous when they're done without strong<br />
consensus.<ref name="garzik_bip" /><ref>[http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-June/008779.html Consensus changes are not about making a change to the software],<br />
Pieter Wuille, 18 June 2015</ref><br />
<br />
If Garzik's proposal gains strong consensus, it will be as safe as possible<br />
for a hard fork and it will allow increasing the block size up to 32 MB<br />
without any additional risk of a fork.<br />
<br />
==== Why is it limited to 32 megabytes? ====<br />
<br />
According to the draft BIP, "the 32 MB hard fork is largely coincidental -- a whole network upgrade at 32 MB was likely needed anyway."<br />
<br />
=== Lightning Network ===<br />
<br />
Questions related to using the proposed [http://lightning.network/ Lightning network] as a way to scale the number of users Bitcoin can support.<br />
<br />
==== How does transaction security differ from that of Bitcoin? ====<br />
<br />
Transactions on the proposed Lightning network use Bitcoin transactions exclusively to transfer bitcoins<ref name="russell_lightning1">[http://rusty.ozlabs.org/?p=450 Lightning Networks: Part I], Rusty Russell, 30 March 2015</ref>, and so the same security as regular Bitcoin transactions is provided when both a Lightning hub and client are cooperating.<br />
<br />
When a Lightning hub or client refuses to cooperate with the other (maybe because they accidentally went offline), the other party can still receive their full 100% bitcoin balance by closing the payment channel—but they must first wait for a defined amount of time mutually chosen by both the hub and client.<ref>[http://rusty.ozlabs.org/?p=462 Lightning Networks: Part II], Rusty Russell, 1 April 2015</ref><br />
<br />
If one party waits too long to close the payment channel, the other party may be able to steal bitcoins. However, it is possible to delegate the task of closing the channel in an emergency to an unlimited number of hubs around the Internet, so closing the channel on time should be easy.<ref name="russell_lightning4">[http://rusty.ozlabs.org/?p=477 Lightning Networks: Part IV], Rusty Russell, 8 April 2015</ref><br />
<br />
In summary, provided that payment channels are closed on time, the worst that can happen to users is that they may have to wait a few weeks for a channel to fully close before spending the bitcoins they received from it. Their security is otherwise the same as with regular Bitcoin.<br />
<br />
For Lightning hubs, security is slightly worse in the sense that they need to keep a potentially-large amount of funds in a hot wallet<ref name="lightning_paper">[http://lightning.network/lightning-network-paper-DRAFT-0.5.pdf Lightning Network (Draft 0.5)], Section 6.3: Coin Theft via Hacking, Joseph Poon and Thaddeus Dryja</ref>, so they can’t take advantage of the anti-hacking protection offered by cold wallets. Otherwise, Lightning hubs have the same security as clients.<br />
<br />
==== When will Lightning be ready for use? ====<br />
<br />
Lightning requires a basic test implementation (work underway<ref>[https://lists.blockstream.com/pipermail/lightning-dev/2015-June/000018.html Lightning first steps], Rusty Russell, 13 June 2015</ref>), several soft-fork changes to the Bitcoin protocol (work underway<ref>[https://github.com/bitcoin/bips/blob/master/bip-0065.mediawiki BIP65: CheckLockTimeVerify], Peter Todd, 1 October 2014</ref><ref>[https://github.com/bitcoin/bips/blob/master/bip-0068.mediawiki BIP68: Consensus-enforced transaction replacement], Mark Friedenbach, 28 May 2015</ref>, and wallets need to be updated to support the Lightning network protocol.<ref name="russell_lightning4" /><br />
<br />
Dr. Adam Back has said, "I expect we can get something running inside a year."<ref>[http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-June/009242.html Reply to Andresen regarding Lightning], Dr. Adam Back, 28 June 2015</ref><br />
<br />
==== Doesn’t Lightning require bigger blocks anyway? ====<br />
<br />
Lightning is block-size neutral. It requires one on-chain transaction to open a channel between a hub and a client, and one on-chain transaction to close a channel.<ref name="russell_lightning1" /> In between it can support an unlimited number of transactions between anyone on the Lightning network.<ref name="lightning_paper" /><br />
<br />
Using the numbers from the Lightning presentation<ref name="lightning_slides">[http://lightning.network/lightning-network.pdf Lightning presentation], Joseph Poon, 23 February 2015</ref>, if people open and close a plausible two channels a year, Lightning can support about 52 million users with the current one-megabyte limit—and each user can make an unlimited number of transactions. Currently, assuming people make an average of only two Bitcoin transactions a day, basic Bitcoin can support only 288,000 users.<br />
<br />
Under these assumptions, Lightning is 180 times (17,900%) more efficient than basic Bitcoin.<br />
<br />
Presumably, if around 30 million people are using Bitcoin via Lightning so that capacity is called into question, it will not be difficult to find consensus to double the block size to two megabytes and bring user capacity up to 105 million. The same goes for later increases to 200 million (4MB), 400 million (8MB), 800 million (16MB), 1.6 billion (32 MB), 3.2 billion (64MB), and all 7 billion living humans (133MB). In each case, all Lightning network participants get unlimited transactions to the other participants.<br />
<br />
For basic Bitcoin to scale to just 2 transactions a day for 7 billion people would require 24-gigabyte blocks.<ref name="lightning_slides" /><br />
<br />
=== Sidechains ===<br />
<br />
==== Real quick, what are sidechains? ====<br />
<br />
Block chains that are separate from Bitcoin’s block chain, but which allow you to receive and spend bitcoins using a two-way peg (2WP).<ref name="sidechains_paper">[https://www.blockstream.com/sidechains.pdf Sidechains paper], Adam Back et al., 22 October 2014</ref> (Although a sidechain can never be more secure than the Bitcoin block chain.<ref>[https://www.reddit.com/r/Bitcoin/comments/39r85g/sidechain_hate/cs5spbg Security limitations of pegged chains], Gregory Maxwell, 14 June 2015</ref>)<br />
<br />
==== Are sidechains a scaling option? ====<br />
<br />
No. Sidechains have the same fundamental scaling problems as Bitcoin does. Moving some transactions to sidechains simply moves some problems elsewhere on the network—the total difficulty of the problem remains the same.<ref>[http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-June/008617.html Sidechains not a direct means for solving any of the scaling problems Bitcoin has], Pieter Wuille, 13 June 2015</ref><br />
<br />
==== But couldn’t I create a sidechain that had 100 GB blocks? ====<br />
<br />
Certainly, sidechain code is open source<ref>[https://github.com/ElementsProject/elements Elements Project]</ref>—so you can create your own sidechain. But you’d still have the difficulty of finding people who are willing to validate 100 GB blocks with their own full nodes.<br />
<br />
==== Do sidechains require a hard fork? ====<br />
<br />
No. Federated sidechains, such as have already been implemented<ref>[https://github.com/ElementsProject/elements/tree/alpha Elements Alpha]</ref>, don’t require any changes to the Bitcoin consensus rules. Merged-mined sidechains, which have not been implemented yet, do require a backwards-compatible soft fork in order to transfer funds between Bitcoin and the sidechain.<ref name="sidechains_paper" /><br />
<br />
== References ==<br />
<references /></div>Hardinghttps://en.bitcoin.it/w/index.php?title=Taproot_activation_proposals&diff=68064Taproot activation proposals2020-07-21T13:38:38Z<p>Harding: Add "Chaos risk" to "Gently discourage apathy" for "Accelerate activation" variation</p>
<hr />
<div>This page summarizes several technical proposals for activating the taproot soft fork defined by BIPs 340, 341, and 342. The goal is to succinctly reference the tradeoffs inherent in each class of proposals so that the development community can choose and implement an activation method that users will find acceptable.<br />
<br />
== Notes on BIP8 ==<br />
<br />
At the time this document is being written, [https://github.com/bitcoin/bips/blob/master/bip-0008.mediawiki BIP8] ''version bits with lock-in by height'' was recently [https://github.com/bitcoin/bips//pull/550 updated] for the first time in several years. One notable change is that forced activation is now based on block height rather than median time past; a second notable change is that forced activation is a boolean parameter chosen when a soft fork’s activation parameters are set either for the initial deployment or updated in a later deployment.<br />
<br />
BIP8 without forced activation is very similar to [https://github.com/bitcoin/bips/blob/master/bip-0009.mediawiki BIP9] ''version bits with timeout and delay'', with the only significant difference being BIP8’s use of block heights compared to BIP9’s use of median time past. This setting allows the attempt to fail (but it can be retried later).<br />
<br />
BIP8 with forced activation concludes with a mandatory signaling period where all blocks produced in compliance with its rules must signal readiness for the soft fork in a way that will trigger activation in an earlier deployment of the same soft fork with non-mandatory activation. In other words, if node version x is released without forced activation and, later, version y is released that successfully forces miners to begin signaling readiness within the same time period, both versions will begin enforcing the new consensus rules at the same time.<br />
<br />
This flexibility of the revised BIP8 proposal makes it possible to express some other ideas in terms of what they would look like using BIP8. This provides a common factor to use for categorizing many different proposals.<br />
<br />
== Proposal overview ==<br />
<br />
Nomenclature: <code>BIP8(lockinontimeout, timeout)</code>. The <code>lockinontimeout</code> parameter is a bool specifying whether the attempt will conclude with a flag day activation (true) or a failure to activate (false). The <code>timeout</code> parameter specifies how many months (m) or years (y) until either the attempt fails or in mandatory activated. Columns with empty stages appear when no action is specified in advance (but any action with broad user support is still possible).<br />
<br />
Precise time parameters are still under discussion, with some people advocating moderately longer durations and some advocating moderately shorter durations. The entries below are examples meant to reflect the general idea behind a class of proposals.<br />
<br />
<!-- please sort table by the step in the first period; false before<br />
true (alphabetically), then shorter duration before longer duration --><br />
{|<br />
!| Short name<br />
!| Variation<br />
!| First stage<br />
!| Second stage<br />
!| Third stage<br />
|-<br />
| Let’s see what happens<br />
| Default<br />
| BIP8(false, 3m)<br />
|<br />
<br />
|<br />
<br />
|-<br />
| BIP9 equivalent<br />
| Default<br />
| BIP8(false, 1y)<br />
|<br />
<br />
|<br />
<br />
|-<br />
| Modern Soft Fork Activation<br />
| No issues<br />
| BIP8(false, 1y)<br />
| ''No action, 6m''<br />
| BIP8(true, 2y)<br />
|-<br />
|<br />
<br />
| Issue discovered<br />
| BIP8(false, 1y)<br />
| ''Abandon attempt''<br />
|<br />
<br />
|-<br />
| Decreasing Threshold Soft Fork Activation<br />
| No issues<br />
| BIP8(false, 1y)<br />
| ''No action, 6m''<br />
| BIP8(true, 2.5y), decreasing threshold<br />
|-<br />
|<br />
<br />
| Issue discovered<br />
| BIP8(false, 1y)<br />
| ''Abandon attempt''<br />
|<br />
<br />
|-<br />
| Start now, improve later<br />
| No additional action<br />
| BIP8(false, 2y)<br />
|<br />
<br />
|<br />
<br />
|-<br />
|<br />
<br />
| Commit to activation<br />
| <s>BIP8(false, 2y)</s><br />
| BIP8(true, 2y)<br />
|<br />
<br />
|-<br />
|<br />
<br />
| Commit to accelerated activation<br />
| <s>BIP8(false, 2y)</s><br />
| BIP8(true, 1y)<br />
|<br />
<br />
|-<br />
| Gently discourage apathy<br />
| Default<br />
| BIP8(true, 2y)<br />
| N/A<br />
| N/A<br />
|-<br />
|<br />
<br />
| Accelerate activation<br />
| <s>BIP8(true, 2y)</s><br />
| BIP8(true, 1y)<br />
| N/A<br />
|}<br />
<br />
The same proposals as above graphed over time:<br />
<br />
[[File:Activation-timeline.png|frame|none|alt=|Activation timeline]]<br />
<br />
== Proposals ==<br />
<br />
=== Let’s see what happens, BIP8(false, 3m) ===<br />
<br />
Proposed as a low-risk way to see if miners are willing to activate taproot as quickly as they activated BIP65 CLTV (two months) and BIP68 consensus-enforced sequence numbers (one month).<br />
<br />
Pros:<br />
<br />
* '''Non-committal:''' if a problem is discovered with taproot before miner activation, or there’s a lack of user support for the proposal, the attempt can safely fail without further intervention.<br />
* '''Short duration:''' if it fails unnecessarily, we’ll only have lost three months plus deployment time.<br />
* '''Useful data:''' if it works, it will add evidence to the theory that segwit activation was an aberration and users, developers, and miners can continue working together to upgrade the consensus protocol with minimal fuss.<br />
<br />
Cons:<br />
<br />
* '''Unnecessary failure risk (3 months):''' if it fails for no good reason, we’ll have wasted three months, plus its deployment time, plus the time to choose and deploy another activation method.<br />
* '''Single-shot:''' if it fails, anyone who ran the 3-month release must upgrade in order to enforce any subsequent attempts. Compare to the ''start now, improve later'' proposal where early releases can be triggered to activate by later releases.<br />
<br />
<br><br><br />
=== BIP9 equivalent, BIP8(false, 1y) ===<br />
<br />
Some people think that the lack of miner readiness signaling during the first several months of segwit availability was an aberration specific to the political context of the block size debate, segwit’s interference with covert ASICBoost, or some other factor. These people may wish to try BIP9 again. BIP8(false, 1y) is essentially BIP9 but using block heights rather than median time past to guarantee a specified number of signaling periods.<br />
<br />
Pros:<br />
<br />
* '''Non-committal:''' if a problem is discovered with taproot before miner activation, or there’s a lack of user support for the proposal, the attempt can safely fail without further intervention.<br />
* '''Useful data:''' if it works, it will add evidence to the theory that segwit activation was an aberration and users, developers, and miners can continue working together to upgrade the consensus protocol with minimal fuss.<br />
<br />
Cons:<br />
<br />
* '''Unnecessary failure risk (1 year):''' if it fails for no good reason, we’ll have wasted an entire year, plus its deployment time, plus the time to choose and deploy another activation method.<br />
<br />
<br><br><br />
=== Modern Soft Fork Activation, BIP8(false, 1y)+quiet(6m)+BIP8(true, 2y) ===<br />
<br />
Proposed in a [https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2020-January/017547.html mailing list post], the goals of this idea are to ensure users truly want a soft fork and that it’s activated in a way that minimizes the risk of disruption.<br />
<br />
Pros:<br />
<br />
* '''Non-committal (initial deployment):''' if a problem is discovered with taproot during the first two stages, or there’s a lack of user support for the proposal, the attempt can safely fail without further intervention.<br />
* '''Useful data:''' if it activates quickly, it will add evidence to the theory that segwit activation was an aberration and users, developers, and miners can continue working together to upgrade the consensus protocol with minimal fuss.<br />
* '''Far-off flag day:''' if mandatory activation is needed, there’s a long time (2 years) for users to upgrade to mandatory enforcement nodes. This minimizes the chance that only a small number of users will enact mandatory enforcement and then be tricked into accepting bitcoins that most other users won’t consider valid.<br />
<br />
Cons:<br />
<br />
* '''Committal (subsequent deployment):''' if a problem is discovered with taproot during the final stage, users and developers may need to intervene to prevent the problem from being exploited.<br />
* '''Unnecessary delay:''' without miner cooperation, it will take almost three years to get the taproot features, which may delay other useful Bitcoin work or cause developers to spend time implementing unnecessary intermediate solutions (e.g. 2pECDSA rather than MuSig).<br />
<br />
<br><br><br />
=== Decreasing Threshold Soft-Fork Activation, BIP8(false, 6m)+NoAction(1y)+BIP8(true, 2.5y) ===<br />
<br />
A [slight variation][bip-dectresh] on the Modern Soft Fork Activation method, the final period in this proposal steadily decreases the percentage of hashrate that needs to signal readiness for the soft fork before it activates. For example, normally 95% of blocks in a difficulty period need to signal for a BIP8 soft fork in order to activate it; however, near the end of the final signaling period, it might only require 60% of hash rate to signal readiness. This lower threshold is reasonable because it’s expected that most users will be ready to enforce the proposal at that time. Even if miners still aren’t signaling in sufficient numbers, the proposal can mandatory activate at the end of its final stage.<br />
<br />
Pros:<br />
<br />
* '''Non-committal (initial deployment):''' if a problem is discovered with taproot during the first two stages, the attempt can safely fail without further intervention.<br />
* '''Useful data:''' if it activates quickly, it will add evidence to the theory that segwit activation was an aberration and users, developers, and miners can continue working together to upgrade the consensus protocol with minimal fuss.<br />
* '''Far-off flag day:''' if mandatory activation is needed, there’s a long time (months or years) for users to upgrade to nodes that accept reduced threshold signaling or mandatory activation. This minimizes the chance that only a small number of users will enact mandatory enforcement and then be tricked into accepting bitcoins that most other users won’t consider valid.<br />
<br />
Cons:<br />
<br />
* '''Committal (subsequent deployment):''' if a problem is discovered with taproot during the final stage, users and developers may need to intervene to prevent the problem from being exploited.<br />
* '''Unnecessary delay:''' without miner cooperation, it will take almost four years to get the taproot features, which may delay other useful Bitcoin work or cause developers to spend time implementing unnecessary intermediate solutions (e.g. 2pECDSA rather than MuSig).<br />
* '''No reference implementation:''' no implementation of this proposal yet exists, although it is not believed that creating one would be particularly difficult.<br />
<br />
<br><br><br />
=== Start now, improve later, BIP8(false, 2y) ===<br />
<br />
Proposed as an option that maximizes flexibility, this allows miners to signal readiness to enforce taproot quickly but also makes it easy for users to force taproot activation later. For example, after several months of miners not activating taproot for no good reason, an updated node could be published that used the same BIP8 parameters except <code>lockinontimeout=true</code>, requiring activation at the end of the two years. Or <code>true</code> could be set and the timeout deadline could be shortened, allowing activation within 6 or 12 more months.<br />
<br />
Pros:<br />
<br />
* '''Non-committal:''' if a problem is discovered with taproot before miner activation, or there’s a lack of user support for the proposal, the attempt can safely fail without further intervention.<br />
* '''Useful data:''' if it activates quickly, it will add evidence to the theory that segwit activation was an aberration and users, developers, and miners can continue working together to upgrade the consensus protocol with minimal fuss.<br />
* '''Enough time for second deployment:''' the two year duration probably gives users and developers enough time to deploy an alternative that sets <code>lockintimeout=true</code>, allowing all nodes compatible with either deployment to activate simultaneously.<br />
<br />
Cons:<br />
<br />
* '''Unnecessary failure risk (2 years):''' if it fails for no good reason, we’ll have wasted two years, plus its deployment time, plus the time to choose and deploy another activation method.<br />
* '''Chaos risk:''' if some users later decide to <code>lockinontimeout=true</code> with a date before the original two-year end, they all need to choose the same date or users choosing a date with insufficient support could be tricked into accepting non-spendable bitcoins. It may be possible to mitigate this by building support for an acceleration target date even before the initial <code>lockinontimeout=false</code> version is released.<br />
<br />
<br><br><br />
=== Gently discourage apathy, BIP8(true, 2y) ===<br />
<br />
Proposed as a way to ensure miners eventually need to signal, so they don’t defer doing so out of apathy, this method requires activation after a long delay.<br />
<br />
Pros:<br />
<br />
* '''Useful data:''' if it activates quickly, it will add evidence to the theory that segwit activation was an aberration and users, developers, and miners can continue working together to upgrade the consensus protocol with minimal fuss.<br />
* '''Far-off flag day:''' if mandatory activation is needed, there’s a long time (months or years) for users to upgrade to nodes that accept reduced threshold signaling or mandatory activation. This minimizes the chance that only a small number of users will enact mandatory enforcement and then be tricked into accepting bitcoins that most other users won’t consider valid.<br />
* '''Enough time for second deployment:''' the two year duration may gives users and developers enough time to deploy additional soft fork rules that fix any problems in the initial proposal.<br />
<br />
Cons:<br />
<br />
* '''Committal:''' if a problem is discovered with taproot before activation, users and developers may need to intervene to prevent the problem from being exploited.<br />
* '''Unnecessary delay:''' without miner cooperation, it will take two years to get the taproot features, which may delay other useful Bitcoin work or cause developers to spend time implementing unnecessary intermediate solutions (e.g. 2pECDSA rather than MuSig).<br />
* '''Chaos risk:''' if some users later decide to <code>lockinontimeout=true</code> with a date before the original two-year end, they all need to choose the same date or users choosing a date with insufficient support could be tricked into accepting non-spendable bitcoins. It may be possible to mitigate this by building support for an acceleration target date even before the initial version is released.</div>Hardinghttps://en.bitcoin.it/w/index.php?title=Taproot_activation_proposals&diff=68063Taproot activation proposals2020-07-21T13:26:18Z<p>Harding: s/Type/Variation/ for clarity</p>
<hr />
<div>This page summarizes several technical proposals for activating the taproot soft fork defined by BIPs 340, 341, and 342. The goal is to succinctly reference the tradeoffs inherent in each class of proposals so that the development community can choose and implement an activation method that users will find acceptable.<br />
<br />
== Notes on BIP8 ==<br />
<br />
At the time this document is being written, [https://github.com/bitcoin/bips/blob/master/bip-0008.mediawiki BIP8] ''version bits with lock-in by height'' was recently [https://github.com/bitcoin/bips//pull/550 updated] for the first time in several years. One notable change is that forced activation is now based on block height rather than median time past; a second notable change is that forced activation is a boolean parameter chosen when a soft fork’s activation parameters are set either for the initial deployment or updated in a later deployment.<br />
<br />
BIP8 without forced activation is very similar to [https://github.com/bitcoin/bips/blob/master/bip-0009.mediawiki BIP9] ''version bits with timeout and delay'', with the only significant difference being BIP8’s use of block heights compared to BIP9’s use of median time past. This setting allows the attempt to fail (but it can be retried later).<br />
<br />
BIP8 with forced activation concludes with a mandatory signaling period where all blocks produced in compliance with its rules must signal readiness for the soft fork in a way that will trigger activation in an earlier deployment of the same soft fork with non-mandatory activation. In other words, if node version x is released without forced activation and, later, version y is released that successfully forces miners to begin signaling readiness within the same time period, both versions will begin enforcing the new consensus rules at the same time.<br />
<br />
This flexibility of the revised BIP8 proposal makes it possible to express some other ideas in terms of what they would look like using BIP8. This provides a common factor to use for categorizing many different proposals.<br />
<br />
== Proposal overview ==<br />
<br />
Nomenclature: <code>BIP8(lockinontimeout, timeout)</code>. The <code>lockinontimeout</code> parameter is a bool specifying whether the attempt will conclude with a flag day activation (true) or a failure to activate (false). The <code>timeout</code> parameter specifies how many months (m) or years (y) until either the attempt fails or in mandatory activated. Columns with empty stages appear when no action is specified in advance (but any action with broad user support is still possible).<br />
<br />
Precise time parameters are still under discussion, with some people advocating moderately longer durations and some advocating moderately shorter durations. The entries below are examples meant to reflect the general idea behind a class of proposals.<br />
<br />
<!-- please sort table by the step in the first period; false before<br />
true (alphabetically), then shorter duration before longer duration --><br />
{|<br />
!| Short name<br />
!| Variation<br />
!| First stage<br />
!| Second stage<br />
!| Third stage<br />
|-<br />
| Let’s see what happens<br />
| Default<br />
| BIP8(false, 3m)<br />
|<br />
<br />
|<br />
<br />
|-<br />
| BIP9 equivalent<br />
| Default<br />
| BIP8(false, 1y)<br />
|<br />
<br />
|<br />
<br />
|-<br />
| Modern Soft Fork Activation<br />
| No issues<br />
| BIP8(false, 1y)<br />
| ''No action, 6m''<br />
| BIP8(true, 2y)<br />
|-<br />
|<br />
<br />
| Issue discovered<br />
| BIP8(false, 1y)<br />
| ''Abandon attempt''<br />
|<br />
<br />
|-<br />
| Decreasing Threshold Soft Fork Activation<br />
| No issues<br />
| BIP8(false, 1y)<br />
| ''No action, 6m''<br />
| BIP8(true, 2.5y), decreasing threshold<br />
|-<br />
|<br />
<br />
| Issue discovered<br />
| BIP8(false, 1y)<br />
| ''Abandon attempt''<br />
|<br />
<br />
|-<br />
| Start now, improve later<br />
| No additional action<br />
| BIP8(false, 2y)<br />
|<br />
<br />
|<br />
<br />
|-<br />
|<br />
<br />
| Commit to activation<br />
| <s>BIP8(false, 2y)</s><br />
| BIP8(true, 2y)<br />
|<br />
<br />
|-<br />
|<br />
<br />
| Commit to accelerated activation<br />
| <s>BIP8(false, 2y)</s><br />
| BIP8(true, 1y)<br />
|<br />
<br />
|-<br />
| Gently discourage apathy<br />
| Default<br />
| BIP8(true, 2y)<br />
| N/A<br />
| N/A<br />
|-<br />
|<br />
<br />
| Accelerate activation<br />
| <s>BIP8(true, 2y)</s><br />
| BIP8(true, 1y)<br />
| N/A<br />
|}<br />
<br />
The same proposals as above graphed over time:<br />
<br />
[[File:Activation-timeline.png|frame|none|alt=|Activation timeline]]<br />
<br />
== Proposals ==<br />
<br />
=== Let’s see what happens, BIP8(false, 3m) ===<br />
<br />
Proposed as a low-risk way to see if miners are willing to activate taproot as quickly as they activated BIP65 CLTV (two months) and BIP68 consensus-enforced sequence numbers (one month).<br />
<br />
Pros:<br />
<br />
* '''Non-committal:''' if a problem is discovered with taproot before miner activation, or there’s a lack of user support for the proposal, the attempt can safely fail without further intervention.<br />
* '''Short duration:''' if it fails unnecessarily, we’ll only have lost three months plus deployment time.<br />
* '''Useful data:''' if it works, it will add evidence to the theory that segwit activation was an aberration and users, developers, and miners can continue working together to upgrade the consensus protocol with minimal fuss.<br />
<br />
Cons:<br />
<br />
* '''Unnecessary failure risk (3 months):''' if it fails for no good reason, we’ll have wasted three months, plus its deployment time, plus the time to choose and deploy another activation method.<br />
* '''Single-shot:''' if it fails, anyone who ran the 3-month release must upgrade in order to enforce any subsequent attempts. Compare to the ''start now, improve later'' proposal where early releases can be triggered to activate by later releases.<br />
<br />
<br><br><br />
=== BIP9 equivalent, BIP8(false, 1y) ===<br />
<br />
Some people think that the lack of miner readiness signaling during the first several months of segwit availability was an aberration specific to the political context of the block size debate, segwit’s interference with covert ASICBoost, or some other factor. These people may wish to try BIP9 again. BIP8(false, 1y) is essentially BIP9 but using block heights rather than median time past to guarantee a specified number of signaling periods.<br />
<br />
Pros:<br />
<br />
* '''Non-committal:''' if a problem is discovered with taproot before miner activation, or there’s a lack of user support for the proposal, the attempt can safely fail without further intervention.<br />
* '''Useful data:''' if it works, it will add evidence to the theory that segwit activation was an aberration and users, developers, and miners can continue working together to upgrade the consensus protocol with minimal fuss.<br />
<br />
Cons:<br />
<br />
* '''Unnecessary failure risk (1 year):''' if it fails for no good reason, we’ll have wasted an entire year, plus its deployment time, plus the time to choose and deploy another activation method.<br />
<br />
<br><br><br />
=== Modern Soft Fork Activation, BIP8(false, 1y)+quiet(6m)+BIP8(true, 2y) ===<br />
<br />
Proposed in a [https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2020-January/017547.html mailing list post], the goals of this idea are to ensure users truly want a soft fork and that it’s activated in a way that minimizes the risk of disruption.<br />
<br />
Pros:<br />
<br />
* '''Non-committal (initial deployment):''' if a problem is discovered with taproot during the first two stages, or there’s a lack of user support for the proposal, the attempt can safely fail without further intervention.<br />
* '''Useful data:''' if it activates quickly, it will add evidence to the theory that segwit activation was an aberration and users, developers, and miners can continue working together to upgrade the consensus protocol with minimal fuss.<br />
* '''Far-off flag day:''' if mandatory activation is needed, there’s a long time (2 years) for users to upgrade to mandatory enforcement nodes. This minimizes the chance that only a small number of users will enact mandatory enforcement and then be tricked into accepting bitcoins that most other users won’t consider valid.<br />
<br />
Cons:<br />
<br />
* '''Committal (subsequent deployment):''' if a problem is discovered with taproot during the final stage, users and developers may need to intervene to prevent the problem from being exploited.<br />
* '''Unnecessary delay:''' without miner cooperation, it will take almost three years to get the taproot features, which may delay other useful Bitcoin work or cause developers to spend time implementing unnecessary intermediate solutions (e.g. 2pECDSA rather than MuSig).<br />
<br />
<br><br><br />
=== Decreasing Threshold Soft-Fork Activation, BIP8(false, 6m)+NoAction(1y)+BIP8(true, 2.5y) ===<br />
<br />
A [slight variation][bip-dectresh] on the Modern Soft Fork Activation method, the final period in this proposal steadily decreases the percentage of hashrate that needs to signal readiness for the soft fork before it activates. For example, normally 95% of blocks in a difficulty period need to signal for a BIP8 soft fork in order to activate it; however, near the end of the final signaling period, it might only require 60% of hash rate to signal readiness. This lower threshold is reasonable because it’s expected that most users will be ready to enforce the proposal at that time. Even if miners still aren’t signaling in sufficient numbers, the proposal can mandatory activate at the end of its final stage.<br />
<br />
Pros:<br />
<br />
* '''Non-committal (initial deployment):''' if a problem is discovered with taproot during the first two stages, the attempt can safely fail without further intervention.<br />
* '''Useful data:''' if it activates quickly, it will add evidence to the theory that segwit activation was an aberration and users, developers, and miners can continue working together to upgrade the consensus protocol with minimal fuss.<br />
* '''Far-off flag day:''' if mandatory activation is needed, there’s a long time (months or years) for users to upgrade to nodes that accept reduced threshold signaling or mandatory activation. This minimizes the chance that only a small number of users will enact mandatory enforcement and then be tricked into accepting bitcoins that most other users won’t consider valid.<br />
<br />
Cons:<br />
<br />
* '''Committal (subsequent deployment):''' if a problem is discovered with taproot during the final stage, users and developers may need to intervene to prevent the problem from being exploited.<br />
* '''Unnecessary delay:''' without miner cooperation, it will take almost four years to get the taproot features, which may delay other useful Bitcoin work or cause developers to spend time implementing unnecessary intermediate solutions (e.g. 2pECDSA rather than MuSig).<br />
* '''No reference implementation:''' no implementation of this proposal yet exists, although it is not believed that creating one would be particularly difficult.<br />
<br />
<br><br><br />
=== Start now, improve later, BIP8(false, 2y) ===<br />
<br />
Proposed as an option that maximizes flexibility, this allows miners to signal readiness to enforce taproot quickly but also makes it easy for users to force taproot activation later. For example, after several months of miners not activating taproot for no good reason, an updated node could be published that used the same BIP8 parameters except <code>lockinontimeout=true</code>, requiring activation at the end of the two years. Or <code>true</code> could be set and the timeout deadline could be shortened, allowing activation within 6 or 12 more months.<br />
<br />
Pros:<br />
<br />
* '''Non-committal:''' if a problem is discovered with taproot before miner activation, or there’s a lack of user support for the proposal, the attempt can safely fail without further intervention.<br />
* '''Useful data:''' if it activates quickly, it will add evidence to the theory that segwit activation was an aberration and users, developers, and miners can continue working together to upgrade the consensus protocol with minimal fuss.<br />
* '''Enough time for second deployment:''' the two year duration probably gives users and developers enough time to deploy an alternative that sets <code>lockintimeout=true</code>, allowing all nodes compatible with either deployment to activate simultaneously.<br />
<br />
Cons:<br />
<br />
* '''Unnecessary failure risk (2 years):''' if it fails for no good reason, we’ll have wasted two years, plus its deployment time, plus the time to choose and deploy another activation method.<br />
* '''Chaos risk:''' if some users later decide to <code>lockinontimeout=true</code> with a date before the original two-year end, they all need to choose the same date or users choosing a date with insufficient support could be tricked into accepting non-spendable bitcoins. It may be possible to mitigate this by building support for an acceleration target date even before the initial <code>lockinontimeout=false</code> version is released.<br />
<br />
<br><br><br />
=== Gently discourage apathy, BIP8(true, 2y) ===<br />
<br />
Proposed as a way to ensure miners eventually need to signal, so they don’t defer doing so out of apathy, this method requires activation after a long delay.<br />
<br />
Pros:<br />
<br />
* '''Useful data:''' if it activates quickly, it will add evidence to the theory that segwit activation was an aberration and users, developers, and miners can continue working together to upgrade the consensus protocol with minimal fuss.<br />
* '''Far-off flag day:''' if mandatory activation is needed, there’s a long time (months or years) for users to upgrade to nodes that accept reduced threshold signaling or mandatory activation. This minimizes the chance that only a small number of users will enact mandatory enforcement and then be tricked into accepting bitcoins that most other users won’t consider valid.<br />
* '''Enough time for second deployment:''' the two year duration may gives users and developers enough time to deploy additional soft fork rules that fix any problems in the initial proposal.<br />
<br />
Cons:<br />
<br />
* '''Committal:''' if a problem is discovered with taproot before activation, users and developers may need to intervene to prevent the problem from being exploited.<br />
* '''Unnecessary delay:''' without miner cooperation, it will take two years to get the taproot features, which may delay other useful Bitcoin work or cause developers to spend time implementing unnecessary intermediate solutions (e.g. 2pECDSA rather than MuSig).</div>Hardinghttps://en.bitcoin.it/w/index.php?title=Taproot_activation_proposals&diff=68062Taproot activation proposals2020-07-21T13:21:17Z<p>Harding: Initial content adapted from discussion gist at https://gist.github.com/harding/dda66f5fd00611c0890bdfa70e28152d</p>
<hr />
<div>This page summarizes several technical proposals for activating the taproot soft fork defined by BIPs 340, 341, and 342. The goal is to succinctly reference the tradeoffs inherent in each class of proposals so that the development community can choose and implement an activation method that users will find acceptable.<br />
<br />
== Notes on BIP8 ==<br />
<br />
At the time this document is being written, [https://github.com/bitcoin/bips/blob/master/bip-0008.mediawiki BIP8] ''version bits with lock-in by height'' was recently [https://github.com/bitcoin/bips//pull/550 updated] for the first time in several years. One notable change is that forced activation is now based on block height rather than median time past; a second notable change is that forced activation is a boolean parameter chosen when a soft fork’s activation parameters are set either for the initial deployment or updated in a later deployment.<br />
<br />
BIP8 without forced activation is very similar to [https://github.com/bitcoin/bips/blob/master/bip-0009.mediawiki BIP9] ''version bits with timeout and delay'', with the only significant difference being BIP8’s use of block heights compared to BIP9’s use of median time past. This setting allows the attempt to fail (but it can be retried later).<br />
<br />
BIP8 with forced activation concludes with a mandatory signaling period where all blocks produced in compliance with its rules must signal readiness for the soft fork in a way that will trigger activation in an earlier deployment of the same soft fork with non-mandatory activation. In other words, if node version x is released without forced activation and, later, version y is released that successfully forces miners to begin signaling readiness within the same time period, both versions will begin enforcing the new consensus rules at the same time.<br />
<br />
This flexibility of the revised BIP8 proposal makes it possible to express some other ideas in terms of what they would look like using BIP8. This provides a common factor to use for categorizing many different proposals.<br />
<br />
== Proposal overview ==<br />
<br />
Nomenclature: <code>BIP8(lockinontimeout, timeout)</code>. The <code>lockinontimeout</code> parameter is a bool specifying whether the attempt will conclude with a flag day activation (true) or a failure to activate (false). The <code>timeout</code> parameter specifies how many months (m) or years (y) until either the attempt fails or in mandatory activated. Columns with empty stages appear when no action is specified in advance (but any action with broad user support is still possible).<br />
<br />
Precise time parameters are still under discussion, with some people advocating moderately longer durations and some advocating moderately shorter durations. The entries below are examples meant to reflect the general idea behind a class of proposals.<br />
<br />
<!-- please sort table by the step in the first period; false before<br />
true (alphabetically), then shorter duration before longer duration --><br />
{|<br />
!| Short name<br />
!| Type<br />
!| First stage<br />
!| Second stage<br />
!| Third stage<br />
|-<br />
| Let’s see what happens<br />
| Default<br />
| BIP8(false, 3m)<br />
|<br />
<br />
|<br />
<br />
|-<br />
| BIP9 equivalent<br />
| Default<br />
| BIP8(false, 1y)<br />
|<br />
<br />
|<br />
<br />
|-<br />
| Modern Soft Fork Activation<br />
| No issues<br />
| BIP8(false, 1y)<br />
| ''No action, 6m''<br />
| BIP8(true, 2y)<br />
|-<br />
|<br />
<br />
| Issue discovered<br />
| BIP8(false, 1y)<br />
| ''Abandon attempt''<br />
|<br />
<br />
|-<br />
| Decreasing Threshold Soft Fork Activation<br />
| No issues<br />
| BIP8(false, 1y)<br />
| ''No action, 6m''<br />
| BIP8(true, 2.5y), decreasing threshold<br />
|-<br />
|<br />
<br />
| Issue discovered<br />
| BIP8(false, 1y)<br />
| ''Abandon attempt''<br />
|<br />
<br />
|-<br />
| Start now, improve later<br />
| No additional action<br />
| BIP8(false, 2y)<br />
|<br />
<br />
|<br />
<br />
|-<br />
|<br />
<br />
| Commit to activation<br />
| <s>BIP8(false, 2y)</s><br />
| BIP8(true, 2y)<br />
|<br />
<br />
|-<br />
|<br />
<br />
| Commit to accelerated activation<br />
| <s>BIP8(false, 2y)</s><br />
| BIP8(true, 1y)<br />
|<br />
<br />
|-<br />
| Gently discourage apathy<br />
| Default<br />
| BIP8(true, 2y)<br />
| N/A<br />
| N/A<br />
|-<br />
|<br />
<br />
| Accelerate activation<br />
| <s>BIP8(true, 2y)</s><br />
| BIP8(true, 1y)<br />
| N/A<br />
|}<br />
<br />
The same proposals as above graphed over time:<br />
<br />
[[File:Activation-timeline.png|frame|none|alt=|Activation timeline]]<br />
<br />
== Proposals ==<br />
<br />
=== Let’s see what happens, BIP8(false, 3m) ===<br />
<br />
Proposed as a low-risk way to see if miners are willing to activate taproot as quickly as they activated BIP65 CLTV (two months) and BIP68 consensus-enforced sequence numbers (one month).<br />
<br />
Pros:<br />
<br />
* '''Non-committal:''' if a problem is discovered with taproot before miner activation, or there’s a lack of user support for the proposal, the attempt can safely fail without further intervention.<br />
* '''Short duration:''' if it fails unnecessarily, we’ll only have lost three months plus deployment time.<br />
* '''Useful data:''' if it works, it will add evidence to the theory that segwit activation was an aberration and users, developers, and miners can continue working together to upgrade the consensus protocol with minimal fuss.<br />
<br />
Cons:<br />
<br />
* '''Unnecessary failure risk (3 months):''' if it fails for no good reason, we’ll have wasted three months, plus its deployment time, plus the time to choose and deploy another activation method.<br />
* '''Single-shot:''' if it fails, anyone who ran the 3-month release must upgrade in order to enforce any subsequent attempts. Compare to the ''start now, improve later'' proposal where early releases can be triggered to activate by later releases.<br />
<br />
<br><br><br />
=== BIP9 equivalent, BIP8(false, 1y) ===<br />
<br />
Some people think that the lack of miner readiness signaling during the first several months of segwit availability was an aberration specific to the political context of the block size debate, segwit’s interference with covert ASICBoost, or some other factor. These people may wish to try BIP9 again. BIP8(false, 1y) is essentially BIP9 but using block heights rather than median time past to guarantee a specified number of signaling periods.<br />
<br />
Pros:<br />
<br />
* '''Non-committal:''' if a problem is discovered with taproot before miner activation, or there’s a lack of user support for the proposal, the attempt can safely fail without further intervention.<br />
* '''Useful data:''' if it works, it will add evidence to the theory that segwit activation was an aberration and users, developers, and miners can continue working together to upgrade the consensus protocol with minimal fuss.<br />
<br />
Cons:<br />
<br />
* '''Unnecessary failure risk (1 year):''' if it fails for no good reason, we’ll have wasted an entire year, plus its deployment time, plus the time to choose and deploy another activation method.<br />
<br />
<br><br><br />
=== Modern Soft Fork Activation, BIP8(false, 1y)+quiet(6m)+BIP8(true, 2y) ===<br />
<br />
Proposed in a [https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2020-January/017547.html mailing list post], the goals of this idea are to ensure users truly want a soft fork and that it’s activated in a way that minimizes the risk of disruption.<br />
<br />
Pros:<br />
<br />
* '''Non-committal (initial deployment):''' if a problem is discovered with taproot during the first two stages, or there’s a lack of user support for the proposal, the attempt can safely fail without further intervention.<br />
* '''Useful data:''' if it activates quickly, it will add evidence to the theory that segwit activation was an aberration and users, developers, and miners can continue working together to upgrade the consensus protocol with minimal fuss.<br />
* '''Far-off flag day:''' if mandatory activation is needed, there’s a long time (2 years) for users to upgrade to mandatory enforcement nodes. This minimizes the chance that only a small number of users will enact mandatory enforcement and then be tricked into accepting bitcoins that most other users won’t consider valid.<br />
<br />
Cons:<br />
<br />
* '''Committal (subsequent deployment):''' if a problem is discovered with taproot during the final stage, users and developers may need to intervene to prevent the problem from being exploited.<br />
* '''Unnecessary delay:''' without miner cooperation, it will take almost three years to get the taproot features, which may delay other useful Bitcoin work or cause developers to spend time implementing unnecessary intermediate solutions (e.g. 2pECDSA rather than MuSig).<br />
<br />
<br><br><br />
=== Decreasing Threshold Soft-Fork Activation, BIP8(false, 6m)+NoAction(1y)+BIP8(true, 2.5y) ===<br />
<br />
A [slight variation][bip-dectresh] on the Modern Soft Fork Activation method, the final period in this proposal steadily decreases the percentage of hashrate that needs to signal readiness for the soft fork before it activates. For example, normally 95% of blocks in a difficulty period need to signal for a BIP8 soft fork in order to activate it; however, near the end of the final signaling period, it might only require 60% of hash rate to signal readiness. This lower threshold is reasonable because it’s expected that most users will be ready to enforce the proposal at that time. Even if miners still aren’t signaling in sufficient numbers, the proposal can mandatory activate at the end of its final stage.<br />
<br />
Pros:<br />
<br />
* '''Non-committal (initial deployment):''' if a problem is discovered with taproot during the first two stages, the attempt can safely fail without further intervention.<br />
* '''Useful data:''' if it activates quickly, it will add evidence to the theory that segwit activation was an aberration and users, developers, and miners can continue working together to upgrade the consensus protocol with minimal fuss.<br />
* '''Far-off flag day:''' if mandatory activation is needed, there’s a long time (months or years) for users to upgrade to nodes that accept reduced threshold signaling or mandatory activation. This minimizes the chance that only a small number of users will enact mandatory enforcement and then be tricked into accepting bitcoins that most other users won’t consider valid.<br />
<br />
Cons:<br />
<br />
* '''Committal (subsequent deployment):''' if a problem is discovered with taproot during the final stage, users and developers may need to intervene to prevent the problem from being exploited.<br />
* '''Unnecessary delay:''' without miner cooperation, it will take almost four years to get the taproot features, which may delay other useful Bitcoin work or cause developers to spend time implementing unnecessary intermediate solutions (e.g. 2pECDSA rather than MuSig).<br />
* '''No reference implementation:''' no implementation of this proposal yet exists, although it is not believed that creating one would be particularly difficult.<br />
<br />
<br><br><br />
=== Start now, improve later, BIP8(false, 2y) ===<br />
<br />
Proposed as an option that maximizes flexibility, this allows miners to signal readiness to enforce taproot quickly but also makes it easy for users to force taproot activation later. For example, after several months of miners not activating taproot for no good reason, an updated node could be published that used the same BIP8 parameters except <code>lockinontimeout=true</code>, requiring activation at the end of the two years. Or <code>true</code> could be set and the timeout deadline could be shortened, allowing activation within 6 or 12 more months.<br />
<br />
Pros:<br />
<br />
* '''Non-committal:''' if a problem is discovered with taproot before miner activation, or there’s a lack of user support for the proposal, the attempt can safely fail without further intervention.<br />
* '''Useful data:''' if it activates quickly, it will add evidence to the theory that segwit activation was an aberration and users, developers, and miners can continue working together to upgrade the consensus protocol with minimal fuss.<br />
* '''Enough time for second deployment:''' the two year duration probably gives users and developers enough time to deploy an alternative that sets <code>lockintimeout=true</code>, allowing all nodes compatible with either deployment to activate simultaneously.<br />
<br />
Cons:<br />
<br />
* '''Unnecessary failure risk (2 years):''' if it fails for no good reason, we’ll have wasted two years, plus its deployment time, plus the time to choose and deploy another activation method.<br />
* '''Chaos risk:''' if some users later decide to <code>lockinontimeout=true</code> with a date before the original two-year end, they all need to choose the same date or users choosing a date with insufficient support could be tricked into accepting non-spendable bitcoins. It may be possible to mitigate this by building support for an acceleration target date even before the initial <code>lockinontimeout=false</code> version is released.<br />
<br />
<br><br><br />
=== Gently discourage apathy, BIP8(true, 2y) ===<br />
<br />
Proposed as a way to ensure miners eventually need to signal, so they don’t defer doing so out of apathy, this method requires activation after a long delay.<br />
<br />
Pros:<br />
<br />
* '''Useful data:''' if it activates quickly, it will add evidence to the theory that segwit activation was an aberration and users, developers, and miners can continue working together to upgrade the consensus protocol with minimal fuss.<br />
* '''Far-off flag day:''' if mandatory activation is needed, there’s a long time (months or years) for users to upgrade to nodes that accept reduced threshold signaling or mandatory activation. This minimizes the chance that only a small number of users will enact mandatory enforcement and then be tricked into accepting bitcoins that most other users won’t consider valid.<br />
* '''Enough time for second deployment:''' the two year duration may gives users and developers enough time to deploy additional soft fork rules that fix any problems in the initial proposal.<br />
<br />
Cons:<br />
<br />
* '''Committal:''' if a problem is discovered with taproot before activation, users and developers may need to intervene to prevent the problem from being exploited.<br />
* '''Unnecessary delay:''' without miner cooperation, it will take two years to get the taproot features, which may delay other useful Bitcoin work or cause developers to spend time implementing unnecessary intermediate solutions (e.g. 2pECDSA rather than MuSig).</div>Hardinghttps://en.bitcoin.it/w/index.php?title=File:Activation-timeline.png&diff=68061File:Activation-timeline.png2020-07-21T13:18:09Z<p>Harding: Rough timeline graph of various proposals for activating taproot.</p>
<hr />
<div>== Summary ==<br />
Rough timeline graph of various proposals for activating taproot.<br />
== Licensing ==<br />
{{self|Cc-zero}}</div>Hardinghttps://en.bitcoin.it/w/index.php?title=Techniques_to_reduce_transaction_fees&diff=65933Techniques to reduce transaction fees2018-11-27T19:48:48Z<p>Harding: /* Patient spending */ Remove fee estimation site that's already listed on linked page</p>
<hr />
<div>This page provides a list of currently-available techniques that may allow spenders to reduce the amount of [[transaction fee]] they pay. Not all techniques will apply to all situations, and some techniques require trading off other benefits for lower fees.<br />
<br />
When you reduce the fee you pay, you almost always reduce the fees other users have to pay also. For high-frequency spenders, this effect can be large and can provide significant additional second order savings. For example, If an organization is creating 10% of all transactions and begins making transactions 50% more efficiently, an additional 5% of block space is freed up for all users of Bitcoin. This would be expected to lower fees by some amount (likely more than 5%), providing a second order of savings on top of the first-order savings of 50%.<br />
<br />
''Note, this page only describes techniques that apply to payment-oriented transactions. Data carrier transactions (e.g. [[OP_RETURN]] or [[OpenTimestamps]]), [[colored coin]] protocols, and other proposed uses of Bitcoin transactions may benefit from some of the following techniques, but the recommendations are not aimed at those use cases.''<br />
<br />
== Efficiency improvements ==<br />
<br />
Creating transactions that are smaller in size ([[Weight units|weight]]), or which accomplish more for a given size, provide a more efficient way of using scarce block space and so pay less total fee to achieve a [[Transaction fees#feerates|feerate]] that is equivalent to less efficient payments. This section describes several techniques for producing more efficient transactions.<br />
<br />
Technically ''offchain payments'' such as those made in [[payment channels]] are a type of extremely efficient payment and so belong to this category, but they've been given a separate category because of the distinctive way they achieve their high efficiency.<br />
<br />
=== Compressed public keys ===<br />
<br />
''Universally useful but already widely deployed''<br />
<br />
The original Bitcoin software released in 2009 used 65-byte uncompressed public keys to identify the owner of a set of bitcoins. In 2012, Bitcoin protocol developer Pieter Wuille implemented a change to the program now known as Bitcoin Core that allowed it to use 33-byte compressed public keys instead.<ref>[https://bitcoin.org/en/release/v0.6.0#new-features-since-bitcoin-version-05 Bitcoin Core 0.6.0 release notes], Bitcoin.org, 2012-03-20, retrieved 2018-01-27</ref> As Bitcoin Core users adopted this feature and other wallets upgraded to use it as well, this reduced the size of a typical transaction on the network (with one input and two outputs) from about 258 bytes to about 226 bytes, a 14% savings.<br />
<br />
[[File:Uncompressed-pubkey-percentage.png|center|800px|thumb|The percentage of transaction inputs per block using the old uncompressed pubkey format in their scriptSigs. Note: early Bitcoin transactions often placed pubkeys in their scriptPubKeys rather than their scriptSigs.]]<br />
<br />
The change was fully backwards compatible and did not change security in any way, but it did require users wanting to access the space savings to generate new Bitcoin addresses.<br />
<br />
Since 2012, many wallets have adopted compressed public keys—but still some wallets continue to use the less efficient uncompressed public keys. These wallets could achieve a significant savings in transaction fees for the same priority by switching to compressed public keys. If all wallets adopted it, this would effectively lead to a small increase in the available block space:<br />
<br />
[[File:Uncompressed-pubkey-savings.png|center|800px|thumb|The percentage of the maximum available block space consumed by the extra bytes in uncompressed pubkeys]]<br />
<br />
See also:<br />
<br />
* [https://bitcoin.org/en/developer-guide#public-key-formats Compressed public keys] — Bitcoin.org Developer Guide<br />
* [https://bitcoin.org/en/release/v0.6.0#new-features-since-bitcoin-version-05 Bitcoin Core 0.6.0 release notes]<br />
* [https://github.com/bitcoin/bips/blob/master/bip-0143.mediawiki#Restrictions_on_public_key_type BIP143] - Requires all pubkeys in [[segregated witness]] witnesses be compressed pubkeys<br />
<br />
=== Payment batching ===<br />
<br />
''Very useful for high-frequency spenders (e.g. organizations); moderately useful for lower-frequency spenders (e.g. individuals)''<br />
<br />
Every Bitcoin transaction must reference the funds being spent and provide proof that the transaction was authorized by the owner of those funds. To spend a single collection of funds takes a minimum of 79 vbytes under normal circumstances. This same amount of block space is used no matter how many recipients are paid in that transaction. For example, consider the following two scenarios:<br />
<br />
* Alice pays Bob in one transaction and then pays Charlie in a second transaction. Each transaction contains a minimum of 79 vbytes related to the funds being spent—a total of 158 vbytes.<br />
* Alice uses a single transaction to pay both Bob and Charlie. The single transaction only needs one set of 79 vbytes related to the funds being spent—a savings of 50% for this field.<br />
<br />
This type of savings increases as more payments are added to a single transaction until the cost per payment is just barely more than the cost of adding the vbytes directly related to that payment in the transaction. The plot below shows the cost per payment for a native segwit [[P2WPKH]] transaction paying other P2WPKH outputs:<br />
<br />
[[File:Batching.png|center]]<br />
<br />
We see the cost drop by more than 50% after five payments are added, with the savings increasing up to about 70% for segwit transactions. Not shown is that the savings increase up to about 80% for legacy transactions because these transactions start off less efficient than segwit transactions. That's a major benefit and one that's easily obtainable by high-frequency spenders, such as organizations.<br />
<br />
Many wallets support batching payments. In graphical wallets, there's often a button that allows you add additional recipients to a transaction (see image below). In command-line and RPC wallets, there's often a call such as <code>sendmany</code> that lets you pay multiple recipients.<br />
<br />
[[File:Bitcoin-core-add-recipient.png|thumb|200px|right|Add Recipient button in Bitcoin Core 0.15.0]]<br />
<br />
Note that there are other parts of a transaction that stay a constant size (or nearly so) when payments are added, so the benefits stack up faster than a fixed cost of just 79 vbytes might suggest. The section below about ''change avoidance'' addresses how one of these cases can itself be eliminated as a cost.<br />
<br />
See also:<br />
<br />
* [https://bitcointechtalk.com/saving-up-to-80-on-bitcoin-transaction-fees-by-batching-payments-4147ab7009fb Saving up to 80% on Bitcoin transaction fees by batching payments]<br />
* [https://bitcoin.org/en/developer-reference#sendmany SendMany RPC] - Bitcoin.org Developer Reference<br />
<br />
=== P2SH-wrapped segwit ===<br />
<br />
''Universally useful''<br />
<br />
Transactions that spend bitcoins secured by [[segregated witness]] (segwit) use less space in a block than equivalent non-segwit (legacy) transactions, allowing segwit transactions to pay less total fee to achieve the same [[Transaction fees#feerates|feerate]] as legacy transactions. The amount of savings varies depending on the details of your transaction, but here are a few common transaction types an an example:<br />
<br />
{|<br />
! Type<br />
! Legacy vbytes<br />
! P2SH-wrapped<br>segwit vbytes<br />
! Savings<br />
|-<br />
| Single signature<br />
| 226<br />
| 167<br />
| 26%<br />
|-<br />
| 2-of-2 multisig<br />
| 335<br />
| 197<br />
| 41%<br />
|-<br />
| 2-of-3 multisig<br />
| 369<br />
| 206<br />
| 44%<br />
|}<br />
<br />
Note that the multisig examples above use the same security as the equivalent legacy P2SH multisig. Segwit optionally allows access to a multisig form that is more secure on one dimension but it requires an extra 12 vbytes per output, which would reduce efficiency somewhat.<br />
<br />
To access these savings, you must use a wallet that supports generating P2SH-wrapped segwit addresses (addresses that start with a "3", although not all addresses that start with a 3 are segwit-enabled). When you spend bitcoins received to these P2SH-wrapped segwit addresses, your transactions will automatically consume less block space, allowing your wallet to pay proportionally less fee.<br />
<br />
See also:<br />
<br />
* [[Segregated Witness]]<br />
* [https://bitcoincore.org/en/segwit_wallet_dev/ Segregated Witness Wallet Development Guide] - BitcoinCore.org<br />
* [https://bitcoincore.org/en/segwit_adoption/ List of wallets, libraries, and services that support segwit] - BitcoinCore.org<br />
<br />
=== Native segwit ===<br />
<br />
''Universally useful. Complete usage requires native segwit adoption by the people sending you bitcoins, but you may be able to use it for your [[change outputs]] immediately''<br />
<br />
The P2SH-wrapped segwit described above is backwards compatible with the P2SH address format supported by older wallets, but a new and non-backwards compatible format is available that saves additional space. The following examples and savings are compared to the size of the P2SH-wrapped examples above:<br />
<br />
{|<br />
! Type<br />
! P2SH-wrapped<br>segwit vbytes<br />
! Native segwit<br>vbytes<br />
! Additional<br>savings<br />
|-<br />
| Single signature<br />
| 167<br />
| 141<br />
| 16%<br />
|-<br />
| 2-of-2 multisig<br />
| 197<br />
| 169<br />
| 14%<br />
|-<br />
| 2-of-3 multisig<br />
| 206<br />
| 178<br />
| 14%<br />
|}<br />
<br />
To access these savings, you must use a wallet that supports generating native segwit addresses, called [[bech32]] addresses (addresses that start with a "bc1"). When you spend bitcoins received to these native segwit addresses, your transactions will automatically consume less block space than even P2SH-wrapped segwit addresses, allowing your wallet to pay proportionally less fee.<br />
<br />
Once a wallet supports native segwit, it can begin using it immediately for any [[Change|change outputs]] it generates back to itself without waiting for anyone else to begin using native segwit. In early 2018, when native segwit adoption is low, this may make it easier to identify which output is change and so reduce your privacy. However, once native segwit adoption increases just slightly, this is not expected to adversely affect privacy.<br />
<br />
See also:<br />
<br />
* [[Bech32 adoption]]<br />
* [https://github.com/bitcoin/bips/blob/master/bip-0173.mediawiki BIP173] — Bech32 addresses<br />
<br />
=== Change avoidance ===<br />
<br />
''Useful for high-frequency recipients (e.g. organizations), especially those who already effectively use transaction batching''<br />
<br />
When a Bitcoin transaction references the funds it wants to spend, it's required to spend all of those funds. For example, if you received 5 BTC in a previous transaction and now you want to spend 2 BTC, Bitcoin requires that you spend all 5 BTC. For this reason, almost all Bitcoin transactions currently pay some bitcoins back to the spender. For example, you'd return the remaining 3 BTC from the previous example back to yourself. This return of money to yourself is called ''change'' by analogy to the change a store clerk hands you when you (for example) buy a $2 item with a $5 bill.<br />
<br />
A typical change output adds about 32 vbytes to the size of a transaction. If the spender can pay with exact change—that is, doesn't need to refund any change to them self—they can eliminate the change output and generate transactions that are up to 23% smaller. In addition, a change output will later be spent at a typical cost of 69 vbytes or more, but when paying with exact change, this future cost is also avoided.<br />
<br />
To use change avoidance requires having previously received a payment or set of payments that's close to the size of the amount being spent (including the transaction fee). This can be rare in the case of individual user wallets that don't receive many payments to choose from and can't significantly vary the amount of their spending transactions, but for organization wallets that receive many payments and already use payment batching to combine multiple outgoing payments, change avoidance can be an easily-obtainable efficiency improvement.<br />
<br />
The spender doesn't need to match the inputs and outputs of their transaction exactly to Bitcoin's full 10 nanobitcoin precision, but can instead overpay or underpay fees slightly by including inputs that are (respectively) slightly more or slightly less than the desired amount. Even when paying slightly more fees than desired, this can result in savings if the slight increase in fees is still less than would normally be paid for the extra 32 vbytes (or so) for a change output and the typical mininum of 69 vbytes for later spending that output.<ref>[https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2018-January/015606.html Transaction Merging (bip125 relaxation)], Rhavar, bitcoin-dev mailing list, 2018-01-22</ref> When paying slightly lower fees, confirmation of the transaction may be delayed, but current-generation (2018) fee estimates are still inaccurate enough that small differences in feerates may not strongly correlate to delays.<br />
<br />
See also:<br />
<br />
* [http://murch.one/wp-content/uploads/2016/11/erhardt2016coinselection.pdf An Evaluation of Coin Selection Strategies] - Mark Erhardt<br />
* [https://github.com/bitcoin/bitcoin/pull/10637 Bitcoin Core pull request #10,637] - A proposed implementation of Erhardt's "branch and bound" strategy<br />
* [https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2018-January/015606.html Bitcoin-Dev mailing list post] - With good coin selection, I am able to avoid change about ~75% of the time in my simulations..."<br />
<br />
=== Consolidation ===<br />
<br />
''Useful for all wallets but may require users sacrifice some privacy''<br />
<br />
The amount of fee a transaction pays is proportional to its size in [[vbytes]], and one the main contributors to size is the number of [[inputs]] the transaction spends. Each input is a reference to the funds the transaction wants to spend, and when a wallet contains only low-value inputs, it can't create a comparatively higher output paying a recipient without adding many of those inputs to the transaction. Each input adds a minimum of 41 vbytes to the transaction and almost always 69 or more vbytes, so any strategy that reduces the number of inputs is worth considering.<br />
<br />
Given that [[Transaction_fees#The_market_for_block_space|fees vary over time]], one method that can reduce overall fees is input consolidation—combining a set of smaller inputs into a single larger input by spending them from yourself to yourself during a period of time when fees are lower than normal. For example, if your usual target feerate during normal-priced fee periods is 100 nanobitcoins per vbyte and the current feerate is 10 nanobitcoins per vbyte, you could save up to almost 90% on fees by consolidating now before you next need to spend some of those inputs.<br />
<br />
[[File:Consolidation-savings.png|center]]<br />
<br />
Consolidation does come with the overhead of creating the consolidation transaction, which is equal to the cost of spending one input to one output, which is about 110 vbytes for P2WPKH inputs/outputs. Also, if you combine inputs that were originally sent to addresses unconnected to each other, you may reduce your privacy in some cases by making that connection in your consolidation transaction (although it's believed that few people currently manage to spend their inputs in a manner that preserves this element of privacy).<br />
<br />
See also:<br />
<br />
* [[How to cheaply consolidate coins to reduce miner fees]]<br />
<br />
== Intelligent fee selection ==<br />
<br />
When it comes to fees, sending a Bitcoin transaction is similar to mailing a package: you can pay a high fee for fast high-priority service or a lower fee for slower low-priority service. This section describes several techniques for taking advantage of the more affordable low-priority service.<br />
<br />
=== Dynamic fee estimation ===<br />
<br />
''Universally useful. Already widely deployed but still being improved as research and development continues''<br />
<br />
Early Bitcoin wallets often defaulted to paying a fixed fee on every transaction—enough to incentivize a miner to include it but not enough to compete against other transactions seeking confirmation in the [[Transaction_fees#The_market_for_block_space|block space market]]. As blocks have filled, this has changed, and as of early 2018 all widely-used wallets use dynamic fee estimation to select a fee based on the condition of the current fee market.<br />
<br />
[[File:Bitcoin-core-fee-selector.png|thumb|200px|right|Fee selector in Bitcoin Core 0.15.0]]<br />
<br />
However, some fee estimation tools may be better than others, achieving confirmation by the desired time even when paying lower fees. Although data from multiple wallets and fee estimation services can be compared<ref>[https://www.p2sh.info/dashboard/db/fee-estimation Fee Estimation], P2SH.info, retrieved 2018-01-23</ref> and there have been some attempts to compare fee estimation between different wallets,<ref>[https://blog.bitgo.com/the-challenges-of-bitcoin-transaction-fee-estimation-e47a64a61c72 The Challenges of Bitcoin Transaction Fee Estimation], Jameson Lopp, BitGo block, 2017-05-10, retrieved 2018-01-23</ref> there is no known survey of fee estimation quality across a large number of popular wallets as of early 2018.<br />
<br />
In addition, also as of early 2018, some techniques have recently been described that could significantly improve fee estimation, such as factoring current [[mempool]] data into confirmation-based fee estimates.<ref name="mempool-fee-est-slides">[https://scalingbitcoin.org/stanford2017/Day2/Scaling-2017-Optimizing-fee-estimation-via-the-mempool-state.pdf Optimizing fee estimation via the mempool state (slides, PDF)], Karl-Johan Alm, Scaling Bitcoin 2017 (Stanford), 2017-11-05, retrieved 2018-01-23</ref><ref name="mempool-fee-est-video">[https://www.youtube.com/watch?v=QkYXPJMqBNk&feature=youtu.be&t=2033 Optimizing fee estimation via the mempool state (presentation video)], Karl-Johan Alm, Scaling Bitcoin 2017 (Stanford), 2017-11-05, retrieved 2018-01-23</ref><br />
<br />
See also<br />
<br />
* [[Transaction fees]]<br />
* [https://blog.bitgo.com/the-challenges-of-bitcoin-transaction-fee-estimation-e47a64a61c72 The Challenges of Bitcoin Transaction Fee Estimation] - Jameson Lopp<br />
* [https://gist.github.com/morcos/d3637f015bc4e607e1fd10d8351e9f41 High level description Bitcoin Core's fee estimation algorithm] - Alex Morcos<br />
<br />
=== Patient spending ===<br />
<br />
''Very useful for non-urgent transactions. Not useful for urgent transactions''<br />
<br />
Spenders who can patiently wait for their transactions to confirm can take advantage of variations in the [[Transaction fees#feerates|feerate]] necessary to achive confirmation. For example, sometimes several Bitcoin blocks are produced in quick succession, raising the effective supply of block space by several multiples; other times, demand drops off, such as fees on Sunday being on average 20% lower than fees on Friday in Q4 2017<ref>[[Transaction_fees#The_market_for_block_space]], Bitcoin Wiki, retrieved 2018-01-27</ref>. Looking at data from the widely-used fee estimator included in Bitcoin Core, we can see fee savings of 90% or more possible, with around 50% being easily obtainable by many patient spenders.<br />
<br />
[[File:Feerate-estimates.png|center]]<br />
<br />
In the data plotted above, the Bitcoin Core fee estimator suggests that for this sample period the following savings are available:<br />
<br />
{|<br />
! Wait<br />
! Conservative savings<br />
! Economical savings*<br />
|-<br />
| 2 hours<br />
| 5% <br />
| 5%<br />
|-<br />
| 6 hours<br />
| 18%<br />
| 55%<br />
|-<br />
| 12 hours <br />
| 39%<br />
| 55%<br />
|-<br />
| 24 hours (1 day)<br />
| 39% <br />
| 55%<br />
|-<br />
| 48 hours (2 days) <br />
| 47% <br />
| 55%<br />
|-<br />
| 72 hours (3 days) <br />
| 52% <br />
| 55%<br />
|-<br />
| 96 hours (4 days) <br />
| 92% <br />
| 92%<br />
|}<br />
<br />
''* Economical savings have a lower probability of being achieved and are recommended for use with the transaction replacability described in a later section.''<br />
<br />
Although waiting up to four days is impractical for many use cases, there are also many cases where it can be practical. A few examples: moving funds between one's own wallets, [[#Consolidation|consolidating]] many smaller inputs into one larger input that can be more efficiently spent, or payments or remittances to friends or family who trust the spender and so don't need fast confirmation.<br />
<br />
See also:<br />
<br />
* [https://p2sh.info/dashboard/db/fee-estimation P2SH.info] - Fee estimates from multiple sources<br />
* [[Transaction_fees#Fee_Plotting_Sites|Other fee plotting sites]]<br />
<br />
=== Opt-in transaction replacement ===<br />
<br />
''Universally useful, but may cause UI issues in recipient wallets''<br />
<br />
Although not strictly a method for reducing fees by itself, opt-in transaction replacement allows a wallet to update previously-sent transactions with new versions that pay higher fees and, possibly, make other changes to the transaction. The method is also called opt-in Replace-By-Fee (RBF). This technique allows wallets to initially pay lower fees in case there's a sudden increase in the supply of block space, a sudden decrease in demand for that space, or another situation that increases the chance of low-fee transactions being confirmed. If none of those things happens, the spender can then increase ("bump") the transaction's fee to increase its probability of confirming.<br />
<br />
This often allows wallets that support transaction replacement to pay lower fees than wallets that don't support replacement.<br />
<br />
Transaction replacement can appear odd in some recipient wallets. Wallets such as Bitcoin Core (pictured below) show each replacement as a separate payment in the list of transactions. When one version of the replacements is confirmed, it is shown as a normal transaction; the other versions are then shown with an X icon to indicate that they are [[conflicted]] (cannot occur together in the same valid block chain). This helps communicate the status of all affected payments to the recipient, but it may not be entirely clear what's happening to users who aren't familar with replacements. Other wallets may not show transactions opting in to replacement at all until one version of the transaction has been confirmed. There's no clear community consensus on the correct way to handle this situation using user interfaces, documentation, or both.<br />
<br />
[[File:Fee-bump-ux.png|thumb|right|200px|List of transaction replacements in Bitcoin Core 0.15.0]]<br />
<br />
Transaction replacement can be advantageously combined with ''payment batching'' (described previously). Instead of waiting, for example, 30 minutes to batch all outgoing payments, the spender can batch the first 10 minutes of payments with a low feerate. If that doesn't get confirmed within 10 minutes, the spender can replace that transaction with a slightly higher feerate transaction that also includes then next 10 minutes of payments. If that again doesn't confirm, another update can also include the third 10 minutes of transactions at the original intended feerate. This allows the recipients of the first 10 minutes of payments to receive a notification that the payment has been sent up to 20 minutes earlier than with normal batching, and it also gives those early payments a chance to confirm at a lower-than-expected feerate. Updating a batched transaction with more payments can be done as many times as necessary up to a [[relay limit]] on transaction size of 100 kilobytes.<br />
<br />
Currently, transaction replacement does have one significant downside: it tends to reduce privacy. When the fee on a transaction is increased, either additional inputs must be added or the value of the [[change output]] must be decreased. In either case, this makes the change output easier to identify among the different outputs being paid by a transaction. Value-blinding techniques such as [[confidential transactions]] could improve this situation, but there are no near-term plans to add such a feature to Bitcoin as of early 2018. If transaction replacement is always combined with [[#change_avoidance|change avoidance]], it could avoid this privacy issue.<br />
<br />
See also:<br />
<br />
* [[Transaction replacement]]<br />
* [https://bitcoincore.org/en/faq/optin_rbf/ Opt-in Replace-By-Fee (RBF) FAQ] - BitcoinCore.org<br />
* [https://github.com/bitcoin/bips/blob/master/bip-0125.mediawiki BIP125] - Opt-in Full Replace-by-Fee Signaling<br />
<br />
==== Pre-computed fee bumping ====<br />
<br />
Pre-computed fee bumping is an idea to create and sign multiple replacements for a transaction at the time the initial transaction is created. The initial transaction version could be broadcast immediately, and each of the replacements would pay successively higher fees. This idea could be combined with Bitcoin's existing [[nLockTime]] feature to allow the replacement versions to forbid being included in a block earlier than a specified time or [[block height]], which would allow the replacements to be trustlessly transmitted to third parties (even miners themselves). <br />
<br />
For example, Alice would tell her wallet that she wanted to pay Bob within the next 10 blocks and also indicate what is the highest fee she’s willing to pay. Alice's wallet would then use its existing fee estimation feature to create an initial version of the transaction to Bob that paid the lowest expected fee for a transaction to confirm within 10 blocks. At the same time, Alice's wallet would also create possibly 9 other versions of the transaction, the first one using nLockTime to ensure it can’t be added until two blocks from now; the second timelocked until three blocks from now; etc…<br />
<br />
Each of these subsequent transactions would pay a slightly higher fee than the original transaction (up to Alice’s indicated max fee) to increase the incentive for miners to mine that transaction.<br />
<br />
Because all versions of the transaction would be signed at the time Alice sent the initial transaction, she would only need to unlock her wallet once. Also, because all subsequent versions of the transaction would use nLockTime, Alice could trustlessly distribute copies of these transactions to other people for later broadcast in case she went offline.<br />
<br />
In short, the software would automatically offer Alice’s maximum fee if it had to, but it’d pay a lower fee if it could get away with it—ensuring Alice got close to the best price possible without any extra effort on her part.<br />
<br />
See also:<br />
<br />
* [https://bitcoincore.org/en/meetings/2017/03/02/#big-features-for-0150 Bitcoin Core IRC meeting summary for 2017-03-02] - See "Precomputed fee bumping" bullet point<br />
<br />
== Offchain payments ==<br />
<br />
Not every Bitcoin payment needs to be added to the Bitcoin block chain. For example, imagine Alice pays 1 BTC to Bob, and then Bob pays 1 BTC to Charlie. Instead of adding both of these payments to the block chain, we could more efficiently just add a 1 BTC payment from Alice to Charlie.<br />
<br />
An early description using this specific optimization called it ''transaction cut-through,''<ref>[https://bitcointalk.org/index.php?topic=281848.0 Transaction cut-through], Gregory Maxwell, 2013-08-23, retrieved 2018-01-25</ref> but the concept of not every payment being recorded on the block chain is more widely known today as ''off-chain payments.''<br />
<br />
Up to 99% of all Bitcoin payments are estimated to be offchain payments<ref>[http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-June/008844.html Pure off-chain is a weak form of layer 2], Adam Back, 19 June 2015</ref>, with most of them likely being buy and sell orders on Bitcoin exchanges. Other third-parties may also help facilitate offchain payments for their users, for example tipping services. These services can be extraordinarily efficient because they don't carry Bitcoin's burden of maintaining consensus among a large set of users—but this efficiency comes at a cost of generally requiring that users trust the service operators not to steal funds. These are ''unenforceable offchain payments.''<br />
<br />
However, there also exist ''enforceable offchain payments'' where no trust in a specific third-party is required—only trust in Bitcoin continuing to operate without transaction censorship.<br />
<br />
This section currently focuses on enforceable offchain payments, but it may later be expanded to cover concepts for unenforcable offchain payments that use cryptography and other security solutions to provide more secure and more private solutions than simple trusted third parties.<br />
<br />
=== Payment channels ===<br />
<br />
''Very useful for small-size and moderate-size payments, but not yet widely deployed as of early 2018''<br />
<br />
[[Payment channels]] are a type of ''enforceable offchain payment'' where bitcoins are deposited into a [[smart contract]] between two or more parties, allowing the involved peers to make trustless payments to each other. Combined with [[hashlock]]s, payments can be securely routed across a network of peers, as in the [[Lightning Network]], allowing Alice to pay Charlie by routing a payment through their mutual peer Bob.<br />
<br />
Opening a payment channel requires a confirmed transaction, incurring the cost of the fees for that transaction, although those fees are identical to sending a regular transaction. Closing a channel also requires a confirmed transaction, adding that transaction's fees to the cost of the payment channel, although those fees too are similar to the costs of the recipient of the funds re-spending them to a new recipient. This means a payment channel's fee cost is very similar to making onchain payments.<br />
<br />
Outside of the channel open and channel close transactions, a payment channel can support an unlimited number of payments without paying any further transaction fees. This can make them extraordinarily efficient—for example, imagine making a million in-channel payments for the cost of just two transaction fees. Note: your channel peers and other channel nodes you route payments through may require their own fee for using their services; these are not related to the transaction fees that are the topic of this article.<br />
<br />
As of early 2018, no payment channel implementation is widely used, but several cooperating implementations of a first version of [[Lightning Network]] are available.<br />
<br />
See also:<br />
<br />
* [[Payment channels]]<br />
* [[Lightning Network]]<br />
<br />
== Potential future improvements ==<br />
<br />
Some of the following improvements and proposed improvements may become available to Bitcoin users. Users who adopt the improvements may be able to further lower their fees.<br />
<br />
* Efficiency improvements<br />
** '''Public key and signature aggregation:''' the ability to combine multiple public keys and signatures into a single public key and signature, allowing multisig transactions to be as efficient to spend as single-signature transactions are today. It may also be possible to combine signatures from multiple inputs in a transaction. It is hopped that this will be possible with variant of [[Schnorr signatures]]. Requires a [[soft fork]].<br />
** '''Merkelized Abstract Syntax Trees (MAST):''' a method for committing to spending scripts that allows the partial omission of unused conditions, allowing complex scripts to be much more efficient,<ref>[https://bitcointechtalk.com/what-is-a-bitcoin-merklized-abstract-syntax-tree-mast-33fdf2da5e2f What is a Bitcoin Merkelized Abstract Syntax Tree?], David A. Harding, BitcoinTechTalk.com, 2017-10-12, retrieved 2018-01-27</ref> even more so if used with [[taproot]]<ref>[https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2018-January/015614.html Taproot: Privacy preserving switchable scripting], Gregory Maxwell, Bitcoin-Dev mailing list, 2018-01-23</ref>. Combines well with signature aggregation (described above) in certain use cases. Requires a [[soft fork]].<br />
** '''CoinJoin with signature aggregation:''' [[CoinJoin]] is a technology for Bitcoin that enhances privacy without reducing security. A group of patient spenders can enter a coinjoin together and obfuscate which of them paid which recipient and which change outputs (if any) they received back. Combined with signature aggregation (described in a previous bullet point), this enhanced privacy mode would be cheaper than each spender making a separate less-private transaction—and it would still be just as secure.<ref>[https://diyhpl.us/wiki/transcripts/scalingbitcoin/milan/schnorr-signatures/ Elliptic curve Schnorr-based signatures in Bitcoin], Pieter Wuille, Scaling Bitcoin 2016 (Milan), 2016-10-09, retrieved 2018-01-27</ref> Requires the signature aggregation soft fork described previously.<br />
<br />
* Intelligent fee selection<br />
** '''Mempool-using fee estimation:''' a potential improvement in fee estimation that considers not just which transactions have been recently confirmed but also the queue of currently unconfirmed transactions.<ref name="mempool-fee-est-slides"/><ref name="mempool-fee-est-video"/> Does not require any protocol changes.<br />
<br />
* Offchain payments<br />
** '''Channel factories:''' (enforceable offchain payments) a potentially more efficient way to open payment channels such as those used by Lightning Network. Combined with signature aggregation (described above) this could reduce the cost of opening a payment channel by up to 96%.<ref>[https://www.tik.ee.ethz.ch/file/a20a865ce40d40c8f942cf206a7cba96/Scalable_Funding_Of_Blockchain_Micropayment_Networks%20(1).pdf Scalable Funding of Bitcoin Micropayment Channel Networks]; Conrad Burchert, Christian Decker, and Roger Wattenhofer; retrieved 2018-01-27</ref> Does not require any [[consensus]] changes.<br />
** '''Chaumian banks:''' (unenforceable offchain payments) a trusted third party who controls bitcoins for a pool of Bitcoin users ([[custodial wallet]], AKA "Bitcoin bank") but who can't know which users own which bitcoins. This is accomplished using [[Chaum blinded signatures]].<ref>[https://medium.com/@nopara73/chaumian-e-cash-for-custodial-bitcoin-wallets-and-services-to-scale-bitcoin-8977d9a03064 Chaumian E-Cash For Custodial Bitcoin Wallets And Services To Scale Bitcoin], nopara73, Medium.com, 2017-12-22, retrieved 2018-01-27</ref> Combined with [[hardware security modules]], it could be made extremely difficult for banks to steal depositor funds.<ref>[https://bitcointalk.org/index.php?topic=146307.0 Fidelity-bonded banks: decentralized, auditable, private, off-chain payments], Peter Todd, 2013-02-23, retrieved 2018-01-27</ref> Does not require any protocol changes.<br />
** '''Strong federations (sidechains)''' (unenforceable offchain payments) a set of trusted third parties controls bitcoins for a pool of Bitcoin users, but uses multisig to prevent an individual or small number of those trusted third parties from stealing depositor funds. Uses a public block chain (but not Bitcoin's block chain) to allow any user to audit all transfers into, out of, or within the system. Hardware security modules (HSMs) are used to further reduce trust in the third parties.<ref>[https://blockstream.com/strong-federations.pdf Strong Federations: An Interoperable Blockchain Solution to Centralized Third Party Risks]; Johnny Dilley, Andrew Poelstra, Jonathan Wilkins, Marta Piekarska, Ben Gorlick, and Mark Friedenbach; retrieved 2018-01-28</ref> Although a block chain is used, this qualifies as an offchain payment solution from the perspective of Bitcoin. As of early 2018, free software federated [[sidechain]] software provides support for [[confidential transactions]]<ref>[https://elementsproject.org/elements/confidential-transactions/ Confidential Transactions], ElementsProject.org, retrieved 2018-01-28</ref> that give them many of the same benefits of the Chaumian banks described in a previous bullet point, but federated sidechain software can (and does) support many other features also.<ref>[https://elementsproject.org/elements/ Elements (features)], ElementsProject.org, retrieved 2018-01-28</ref><br />
<br />
== References ==<br />
<br />
<references /><br />
<br />
[[Category:Instructional]]</div>Hardinghttps://en.bitcoin.it/w/index.php?title=IRC_channels&diff=65573IRC channels2018-07-16T11:42:49Z<p>Harding: Mention that #bitcoin-dev is dead, update #bitcoin-core-dev description, and link to multiple log sources for #bitcoin-core-dev</p>
<hr />
<div>Most of the following Bitcoin-related IRC channels are available on [http://www.freenode.net Freenode]:<br />
<br />
Please read: [[Bitcoin IRC Channel Guidelines]] before joining.<br />
<br />
==Bitcoin Project==<br />
{| class="wikitable"<br />
! Channel !! Description<br />
|-<br />
| {{Freenode IRC|bitcoin}} || General Bitcoin-related discussion and support. ([[Bitcoin_IRC_Channel_Guidelines | guidelines]]).<br />
|-<br />
| {{Freenode IRC|bitcoin-dev}} || Dead. Formerly for Bitcoin software development. ([http://bitcoinstats.com/irc/bitcoin-dev/logs/ history]. [[Bitcoin-dev | guidelines]])<br />
|-<br />
| {{Freenode IRC|bitcoin-commits}} || Real-time notification of commits to Bitcoin projects.<br />
|-<br />
| {{Freenode IRC|bitcoin-core-dev}} || For development of Bitcoin Core. Log sources; [https://botbot.me/freenode/bitcoin-core-dev/ 1], [http://www.erisian.com.au/bitcoin-core-dev/ 2], [http://gnusha.org/bitcoin-core-dev/ 3]<br />
|-<br />
| {{Freenode IRC|bitcoin-gaming}} || Bitcoin gamers hangout.<br />
|-<br />
| {{Freenode IRC|bitcoin-gentoo}} || Gentoo community.<br />
|-<br />
| {{Freenode IRC|bitcoin-marketing}} || Marketing and promotion of bitcoin<br />
|-<br />
| {{Freenode IRC|bitcoin-news}} || RSS News related to Bitcoin.<br />
|-<br />
| {{Freenode IRC|bitcoin-politics}} || Discuss politics with other Bitcoin users.<br />
|-<br />
| {{Freenode IRC|#bitcoin-pricetalk|text=&#35;bitcoin-pricetalk}} || ALL Discussion Remotely Related to Bitcoin Price or other offtopic goes here<br />
|-<br />
| {{Freenode IRC|bitcoin-watch|text=[[Bitcoin-Watch|#bitcoin-watch]]}} || Streaming Bitcoin transactions, including market data.<br />
|-<br />
| {{Freenode IRC|bitcoin-wiki}} || Bitcoin Wiki support<br />
|-<br />
| {{Freenode IRC|bitcoin-wizards}} || Bitcoin experts and futurists ([http://botbot.me/freenode/bitcoin-wizards history])<br />
|-<br />
| {{Freenode IRC|lightning-dev}} || Lightning protocol development<br />
|-<br />
| {{Freenode IRC|lnd}} || Lightning only version of #bitcoin-commits<br />
|-<br />
| {{Freenode IRC|sidechains-dev}} || Sidechains development<br />
|}<br />
<br />
===Local communities===<br />
<br />
{| class="wikitable"<br />
| {{Freenode IRC|bitcoin-otc-eu}} || European OTC trading marketplace.<br />
|-<br />
| {{Freenode IRC|bitcoin-otc-ru}} || Russian OTC trading marketplace.<br />
|-<br />
| {{Freenode IRC|bitcoin-otc-uk}} ||United kingdom OTC Trading Marketplace.Founder Angus Bates.<br />
|-<br />
| {{Freenode IRC|bitcoin-aus}} || Aussie bitcoin community.<br />
|-<br />
| {{Freenode IRC|AustinBitcoin}} || Austin, TX bitcoin community.<br />
|-<br />
| {{Freenode IRC|bitcoin-bra}} || Brazilian bitcoin community.<br />
|-<br />
| {{Freenode IRC|bitcoin-cad}} || Canadian bitcoin community.<br />
|-<br />
| {{Freenode IRC|bitcoin-cn}} || Chinese bitcoin community.<br />
|-<br />
| {{Freenode IRC|bitcoin-dk}} || Danish bitcoin community.<br />
|-<br />
| {{Freenode IRC|bitcoin-de}} || German bitcoin community.<br />
|-<br />
| {{Freenode IRC|bitcoin-eastcoastusa}} || East Coast USA bitcoin community.<br />
|-<br />
| {{Freenode IRC|bitcoin-il}} || Israeli bitcoin community.<br />
|-<br />
| {{Freenode IRC|bitcoin-nl}} || Dutch bitcoin community. <br />
|-<br />
| {{Freenode IRC|bitcoin-pl}} || Polish bitcoin community.<br />
|-<br />
| {{Freenode IRC|bitcoin-romania}} || Romanian bitcoin community.<br />
|-<br />
| {{Freenode IRC|bitcoin-ve}} || Venezuelan bitcoin community.<br />
|-<br />
| {{Freenode IRC|btc.chat}} || Russian bitcoin community.<br />
|-<br />
| #bitcoins.fi @ IRCNet || Finnish bitcoin community.<br />
|-<br />
| {{Freenode IRC|bitcoin-hr}} || Croatian language bitcoin community.<br />
<br />
|}<br />
<br />
==Mining Related Communities==<br />
<br />
{| class="wikitable"<br />
! Channel !! Description<br />
|-<br />
| {{Freenode IRC|avalon}} || Discussion and support specific to [[Avalon]] mining machine<br />
|-<br />
| {{Freenode IRC|bitcoin-mining}} || Discussion and support related to mining.<br />
|-<br />
| {{Freenode IRC|bitcoin-fpga}} || Discussion and support specific to FPGA mining.<br />
|-<br />
| {{Freenode IRC|btcguild}} || [[BTCGuild]] mining pool community<br />
|-<br />
| {{Freenode IRC|butterflylabs}} || [[Butterfly Labs]] chat<br />
|-<br />
| {{Freenode IRC|cgminer}} || Discussion and support specific to [[CGMiner]].<br />
|-<br />
| {{Freenode IRC|eligius}} || [[Eligius]] mining pool community (also support for [[BFGMiner]] and [[Eloipool]])<br />
|-<br />
| {{Freenode IRC|mining.bitcoin.cz}} || Slush's mining pool community<br />
|-<br />
| {{Freenode IRC|ozcoin}} || [[Ozco.in]] mining pool community<br />
|-<br />
| <small>[irc://irc.foonetic.net/xkcd-bitcoin IRC] [http://irc.lc/foonetic/xkcd-bitcoin/Miner@@@ Web]</small> #xkcd-bitcoin || [https://en.bitcoin.it/wiki/XKCD_Pool XKCD Pool]<br />
|-<br />
| <small>[irc://irc.quakenet.org/bitcoins.lc IRC] [http://irc.lc/quakenet/bitcoins.lc/Miner@@@ Web]</small> #bitcoins.lc @ Quakenet || [http://www.bitcoins.lc Bitcoins.lc Pool] <br />
|-<br />
| {{Freenode IRC|p2pool}} || [[P2Pool]] decentralized mining pool<br />
|-<br />
| {{Freenode IRC|bitminter}} || [[BitMinter]] Mining Pool Community<br />
|-<br />
| {{Freenode IRC|kncminer}} || [[KNCMiner]] ASIC Mining Hardware Vendor Discussion<br />
|-<br />
| {{Freenode IRC|triplemining}} || [[TripleMining]] mining pool community<br />
|}<br />
<br />
==Communities for Exchanges and Trading==<br />
<br />
{| class="wikitable"<br />
! Channel !! Description<br />
|-<br />
| {{Freenode IRC|bitcoin-assets}} || Discussion of securities and other asset investments. [http://bitcoin-assets.com bitcoin-assets.com].<br />
|-<br />
| {{Freenode IRC|bitcoin-assets-trades}} || Streaming assets market data (only), no chat.<br />
|-<br />
| {{Freenode IRC|bitcoin-auction}} || Live auctions over IRC.<br />
|-<br />
| {{Freenode IRC|bitcoin-market}} || Streaming market data (only), no chat.<br />
|-<br />
| {{Freenode IRC|bitcoin-otc|text=[[bitcoin-otc|#bitcoin-otc]]}} || Over-the-counter trading marketplace and discussion. ([http://bitcoinstats.com/irc/bitcoin-otc/logs/ history])<br />
|-<br />
| {{Freenode IRC|bitcoin-escrow}} || Third party escrow agents.<br />
|-<br />
| {{Freenode IRC|bitcoin-otc-ticker|bitcoin-otc-ticker}} || Streaming market data form the [[#bitcoin-otc]] order book.<br />
|-<br />
| {{Freenode IRC|bitcoin-otc-ratings|bitcoin-otc-ratings}} || Updates to ratings on the [[#bitcoin-otc]] Web of Trust.<br />
|-<br />
| {{Freenode IRC|bitcoin-pit}} || Only over-the-counter trading.<br />
|-<br />
| {{Freenode IRC|bitcoin-wot|bitcoin-wot}} || Distributed Web of Trust (WoT) system for [[#bitcoin-otc]].<br />
|-<br />
| {{Freenode IRC|btc.chat.traders}} || Russian community discussion about trades/exchanges.<br />
|-<br />
| {{Freenode IRC|coinbase}} || [[Coinbase]] chat<br />
|-<br />
| {{Freenode IRC|bitcoin-rt}} || Real-time tape (executed trades).<br />
|-<br />
| {{Freenode IRC|localbitcoins-chat}} || [[LocalBitcoins.com]] exchange support<br />
|-<br />
| {{Freenode IRC|Coinabul}} || [http://Coinabul.com Coinabul]'s customer support and news channel. Selling gold and silver for Bitcoin.<br />
|}<br />
<br />
==Related Communities==<br />
<br />
{| class="wikitable"<br />
! Channel !! Description<br />
|-<br />
| {{Freenode IRC|opentransactions}} || [[Open Transactions]] project.<br />
|-<br />
| {{Freenode IRC|namecoin}} || [[Namecoin]] and the [[Dot-bit]] project.<br />
|-<br />
| {{Freenode IRC|twister}} || [[Twister]], P2P microblogging discussion.<br />
|-<br />
| {{Freenode IRC|joinmarket}} || [[JoinMarket]], A [[CoinJoin]] implementation<br />
|-<br />
| {{Freenode IRC|darkwallet}} || [[DarkWallet]] and libbitcoin/Obelisk discussion & development channel.<br />
|-<br />
| {{Freenode IRC|electrum}} || [[Electrum]], lightweight bitcoin client.<br />
|-<br />
| {{Freenode IRC|copay}} || [[Copay]], lightweight bitcoin client.<br />
|-<br />
| {{Freenode IRC|bitcoin-stackexchange}} || Discussion complementing [http://bitcoin.stackexchange.com Bitcoin StackExchange].<br />
<br />
|}<br />
<br />
==See Also==<br />
<br />
* [[Bitcoin_Wiki:Community_portal]]<br />
<br />
[[fr:Canaux IRC]]<br />
[[pl:Kanały IRC]]<br />
[[ro:Canale]]</div>Hardinghttps://en.bitcoin.it/w/index.php?title=Pooled_mining&diff=65512Pooled mining2018-06-25T21:49:58Z<p>Harding: Undo revision 65499 by RunCPA (talk)</p>
<hr />
<div>'''Pooled mining''' is a [[Mining|mining]] approach where multiple generating clients contribute to the generation of a block, and then split the block reward according the contributed processing power. Pooled mining effectively reduces the granularity of the block generation reward, spreading it out more smoothly over time.<br />
<br />
==Introduction==<br />
<br />
With increasing generation difficulty, mining with lower-performance devices can take a very long time before block generation, on average. For example, with a mining speed of 1000 Khps, at a difficulty of 14484 (which was in effect at the end of December, 2010), the average time to generate a block is almost 2 years. <br />
<br />
To provide a more smooth incentive to lower-performance miners, several pooled miners, using different approaches, have been created. With a mining pool, a lot of different people contribute to generating a block, and the reward is then split among them according to their processing contribution. This way, instead of waiting for years to generate 50btc{{Citation needed}} in a block, a smaller miner may get a fraction of a Bitcoin on a more regular basis.<br />
<br />
A '''share''' is awarded by the mining pool to the clients who present a valid [[proof of work]] of the same type as the proof of work that is used for creating [[block|blocks]], but of lesser difficulty, so that it requires less time on average to generate.<br />
<br />
==Pooled mining approaches==<br />
<br />
The problem with pooled mining is that steps must be taken to prevent cheating by the clients and the server. Currently there are several different approaches used.<br />
<br />
===The slush approach===<br />
<br />
[[Bitcoin Pooled Mining]] (BPM), sometimes referred to as "slush's pool", follows a score-based method. Older shares (from beginning of the round) have lower weight than more recent shares, which reduces the motivation to cheat by switching between pools within a round.<br />
<br />
===The Pay-per-Share approach===<br />
<br />
The Pay-per-Share (PPS) approach, first described by [[BitPenny]], is to offer an instant flat payout for each share that is solved. The payout is offered from the pool's existing balance and can therefore be withdrawn immediately, without waiting for a block to be solved or confirmed. The possibility of cheating the miners by the pool operator and by timing attacks is thus completely eliminated. <br />
<br />
This method results in the least possible variance for miners while transferring all risk to the pool operator. The resulting possibility of loss for the server is offset by setting a payout lower than the full expected value.<br />
<br />
===The Full Pay-per-Share approach===<br />
<br />
The Full Pay-per-Share (FPPS) approach, created by [[BTC.com]] team, aims to benefit miners from the high transaction fee. It will calculate a standard transaction fee within a certain period,add it into the block rewards (12.5 BTC every block for now) and then distribute the whole to miners according to PPS mode. <br />
<br />
This method keeps advantages of PPS and pay more to miners by sharing some of the transaction fees.<br />
<br />
===Luke-Jr's approach ("[[Eligius]]")===<br />
[[User:Luke-Jr|Luke]] came up with a third approach borrowing strengths from the earlier two.<br />
Like slush's approach, miners submit proofs-of-work to earn shares.<br />
Like puddinpop's approach, the pool pays out immediately via block generation.<br />
When distributing block rewards, it is divided equally among all shares since the last valid block.<br />
Unlike any preexisting pool approach, this means that the shares contributed toward stale blocks are recycled into the next block's shares.<br />
In order to spare participating miners from transaction fees, rewards are only paid out if a miner has earned at least 0.67108864 BTC (400 [[Tonal Bitcoin|TBC]]). If the amount owed is less, it will be added to the earnings of a later block (which may then total over the threshold amount).<br />
If a miner does not submit a share for over a week, the pool sends any balance remaining, regardless of its size.<br />
<br />
===P2Pool approach===<br />
<br />
[[P2Pool]] mining nodes work on a chain of shares similar to Bitcoin’s blockchain. When a block is found, the reward is divided among the most recent shares in this share-blockchain. Like the puddinpop and Luke-Jr approaches, p2pool pays via generation.<br />
<br />
===Comparison===<br />
<br />
The cooperative mining approach (slush and Luke-Jr) uses a lot less resources on the pool server, since rather than continuously checking metahashes, all that has to be checked is the validity of submitted shares. The number of shares sent can be adjusted by adjusting the artificial difficulty level.<br />
<br />
Further, the cooperative mining approach allows the clients to use existing miners without any modification, while the puddinpop approach requires the custom pool miner, which are as of now not as efficient on GPU mining as the existing GPU miners.<br />
[[File:Smallgeneration.png|thumb|Puddinpop miners receive coins directly.]]<br />
<br />
Additionally, the puddinpop and Luke-Jr approaches of distributing the earnings by way of including precise sub-cent amounts in the generation transaction for the participants, results in the presence of sub-cent bitcoin amounts in your wallet, which are liable to disappear (as unnecessary fees) later due to a bug in old (before 0.3.21) bitcoin nodes. (E.g., if you have a transaction with 0.052 in your wallet, and you later send .05 to someone, your .002 will disappear.).<br />
<br />
Puddinpop and Luke-Jr miners receive coins directly, which eliminates the delay in receiving earnings that is required on slush-based mining servers. However, using some [[eWallet]] services for generated coin will cause those coins to be lost.<br />
<br />
==See Also==<br />
<br />
* [[:Category:Miners|Miners]]<br />
* [[Poolservers]]<br />
* [[Comparison of mining pools]]<br />
* [[:Category:Pool Operators|Pool Operators]]<br />
* [[Why a GPU mines faster than a CPU]]<br />
* [[Why pooled mining]]<br />
* [[Mining pool reward FAQ]]<br />
<br />
==External links==<br />
<br />
* [https://bitcointalk.org/index.php?topic=1458.0 puddinpop's mining pool thread]<br />
* [http://blockexplorer.com/block/00000000000233334b157d901714baf59e5b9236227b2878844e52244da4195e example puddinpop block]<br />
* [https://www.bitpal.co.uk/bitcoin-mining-pool/ What is a Bitcoin Mining Pool?]<br />
<br />
==References==<br />
<references /><br />
<br />
* [https://www.zpool.ca/ Bitcoin Multipool]<br />
* [https://www.bitcoinmining.com/ Bitcoin Mining]<br />
* [https://www.youtube.com/watch?v=GmOzih6I1zs Video: What is Bitcoin Mining]<br />
* [http://bitcoinminer.com Bitcoin Miner]<br />
<br />
[[ru:майнинг в пулах]]<br />
[[Category:Mining]]<br />
{{Pools}}</div>Hardinghttps://en.bitcoin.it/w/index.php?title=Help:FAQ&diff=65511Help:FAQ2018-06-25T21:49:44Z<p>Harding: Undo revision 65498 by RunCPA (talk)</p>
<hr />
<div>Here you will find answers to the most commonly asked questions.<br />
<br />
== General ==<br />
=== What is Bitcoin? ===<br />
Bitcoin is a distributed peer-to-peer digital currency that can be transferred instantly and securely between any two people in the world. It's like electronic cash that you can use to pay friends or merchants.<br />
<br />
=== What are bitcoins? ===<br />
Bitcoins are the unit of currency of the Bitcoin system. A commonly used shorthand for this is “BTC” to refer to a price or amount (e.g. “100 BTC”).<br />
There are such things as [[physical bitcoins]], but ultimately, a bitcoin is just a number associated with a [[Address|Bitcoin Address]]. A physical bitcoin is simply an object, such as a coin, with the number carefully embedded inside. See also an [[Introduction|easy intro]] to Bitcoin.<br />
<br />
=== How can I get bitcoins? ===<br />
<br />
There are a variety of ways to acquire bitcoins:<br />
* Accept bitcoins as payment for goods or services.<br />
* You can buy bitcoins from [https://www.bitit.gift/ Bitit] [https://www.coinbase.com/buy-bitcoin Coinbase], [https://paybis.com/ PayBis], [http://cubits.com/ Cubits], [https://www.coincorner.com CoinCorner], [[File:BIPS.gif|20px|link=https://bipsmarket.com]] [https://bipsmarket.com BIPS Market], [https://circle.com Circle], or [http://gocelery.com/ Celery].<br />
* The most common way to buy bitcoins are the [[Buying bitcoins|Bitcoin Exchanges]]<br />
* There are several services where you can [[Buying_Bitcoins_(the_noob_version)|trade them]] for traditional currency.<br />
* You can also buy bitcoins using [http://nationalbitcoinatm.com Bitcoin ATMs] that are locally in your area.<br />
* Find someone to trade cash for bitcoins in-person through a [https://en.bitcoin.it/wiki/Category:Directories local directory].<br />
* Participate in a [[Pooled mining|mining pool]].<br />
* If you have a lot of mining hardware, you can solo mine and attempt to create a new [[block]] (currently yields 12.5 bitcoins plus transaction fees).<br />
* Visit sites that provide [[Trade#Free_Samples_and_Offers|free samples and offers]].<br />
<br />
===Does Bitcoin guarantee an influx of free money?===<br />
<br />
Since Bitcoin is a new technology, what it is and how it works may be initially unclear. Bitcoin is sometimes presented as being one of three things:<br />
<ol style="list-style-type: upper-alpha;"><br />
<li>Some sort of online 'get-rich-quick' scam.</li><br />
<li>A loophole in the market economy, the installation of which guarantees a steady influx of cash.</li><br />
<li>A sure investment that will almost certainly yield a profit.</li><br />
</ol><br />
In fact, none of the above are true. Let's look at them independently.<br />
<br />
;Is Bitcoin a 'get-rich-quick' scheme?<br />
:If you've spent much time on the Internet, you've probably seen ads for many 'get-rich-quick' schemes. These ads usually promise huge profits for a small amounts of easy work. Such schemes are usually pyramid/matrix-style schemes that make money from their own employees and offer nothing of any real value. Most convince one to buy packages that will make them earn hundreds a day, which in fact have the buyer distribute more such ads, and make minute profits.<br />
<br />
:Bitcoin is in no way similar to these schemes. Bitcoin doesn't promise windfall profits. There is no way for the developers to make money from your involvement or to take money from you. That bitcoins are nearly impossible to acquire without the owner's consent represents one of its greatest strengths. Bitcoin is an experimental, virtual currency that may succeed or may fail. None of its developers expect to get rich off of it. <br />
<br />
:A more detailed answer to this question can be found [http://bitcointalk.org/?topic=7815.0 here].<br />
<br />
;Will I make money by installing the client?<br />
:Most people who use Bitcoin don't earn anything by doing so, and the default client has no built-in way to earn Bitcoins. A small minority of people with dedicated, high-performance hardware do earn some Bitcoins by "''mining''" (generating new bitcoins, see [[#What is mining?|What is mining?]]) with special software, but joining Bitcoin shouldn't be construed as being the road to riches. Most Bitcoin users get involved because they find the project conceptually interesting and don't earn anything by doing so. This is also why you won't find much speculation about the political or economic repercussions of Bitcoin anywhere on this site: Bitcoin developers owe their dedication to the project's intellectual yieldings more than to those of a monetary nature. Bitcoin is still taking its first baby steps; it may go on to do great things but right now it only has something to offer those chasing conceptually interesting projects or bleeding edge technology.<br />
<br />
;As an investment, is Bitcoin a sure thing?<br />
:Bitcoin is a new and interesting electronic currency, the value of which is not backed by any single government or organization. Like other currencies, it is worth something partly because people are willing to trade it for goods and services. Its exchange rate fluctuates continuously, and sometimes wildly. It lacks wide acceptance and is vulnerable to manipulation by parties with modest funding. Security incidents such as website and account compromise may trigger major sell-offs. Other fluctuations can build into positive feedback loops and cause much larger exchange rate fluctuations. Anyone who puts money into Bitcoin should understand the risk they are taking and consider it a high-risk currency. Later, as Bitcoin becomes better known and more widely accepted, it may stabilize, but for the time being it is unpredictable. Any investment in Bitcoin should be done carefully and with a clear plan to manage the risk.<br />
<br />
=== Can I buy bitcoins with Paypal? ===<br />
<br />
It is possible to buy [[physical bitcoins]] with PayPal but it is otherwise difficult and/or expensive to do so for non-physical bitcoins, because of significant risk to the seller. <br />
<br />
While it is possible to find an individual who wishes to sell Bitcoin to you via Paypal, (perhaps via [http://www.bitcoin-otc.com/ #bitcoin-otc] ) most exchanges do not allow funding through PayPal. This is due to repeated cases where someone pays for bitcoins with Paypal, receives their bitcoins, and then fraudulently complains to Paypal that they never received their purchase. PayPal often sides with the fraudulent buyer in this case, which means any seller needs to cover that risk with higher fees or refuse to accept PayPal altogether.<br />
<br />
Buying Bitcoins from individuals this way is still possible, but requires the seller to have some trust that the buyer will not file a claim with PayPal to reverse the payment.<br />
<br />
Also [https://bitbuy.in/ bitbuy.in] and [https://paybis.com/ PayBis], allows you to buy Bitcoins with PayPal.<br />
<br />
=== Where can I find a forum to discuss Bitcoin? ===<br />
<br />
Please visit the [[Bitcoin Wiki:Community_portal#Bitcoin_Community_Forums_on_various_platforms|Community Portal]] for links to Bitcoin-related forums.<br />
<br />
=== How are new bitcoins created? ===<br />
<br />
New bitcoins are generated by the network through the process of "[[#What is mining?|''mining'']]". In a process that is similar to a continuous raffle draw, mining nodes on the network are awarded bitcoins each time they find the solution to a certain mathematical problem (and thereby create a new [[block]]). Creating a block is a [[proof of work]] with a difficulty that varies with the overall strength of the network. The reward for solving a block is [[Controlled Currency Supply|automatically adjusted]] so that, ideally, every four years of operation of the Bitcoin network, half the amount of bitcoins created in the prior 4 years are created. A maximum of {{formatnum:10499889.80231183}} bitcoins were created in the first 4 (approx.) years from January 2009 to November 2012. Every four years thereafter this amount halves, so it should be {{formatnum:5250000}} over years 4-8, {{formatnum:2625000}} over years 8-12, and so on. Thus the total number of bitcoins in existence can never exceed {{formatnum:20999839.77085749}} and counting. See [[Controlled Currency Supply]].<br />
<br />
Blocks are [[Mining|mined]] every 10 minutes, on average and for the first four years ({{formatnum:210000}} blocks) each block included 50 new bitcoins. As the amount of processing power directed at mining changes, the difficulty of creating new bitcoins changes. This difficulty factor is calculated every 2016 blocks and is based upon the time taken to generate the previous 2016 blocks. See [[Mining]].<br />
<br />
=== What's the current total number of bitcoins in existence? ===<br />
<br />
[http://blockexplorer.com/q/totalbc Current count]. Also see [https://blockchain.info/charts/total-bitcoins Total bitcoins in circulation chart]<br />
<br />
The number of blocks times the coin value of a block is the number of coins in existence. The coin value of a block is 50 BTC for each of the first {{formatnum:210000}} blocks, 25 BTC for the next {{formatnum:210000}} blocks, then 12.5 BTC, 6.25 BTC and so on.<br />
<br />
=== How divisible are bitcoins? ===<br />
<br />
A bitcoin can be divided down to 8 decimal places. Therefore, 0.00000001 BTC is the smallest amount that can be handled in a transaction. If necessary, the protocol and related software can be modified to handle even smaller amounts.<br />
<br />
=== What do I call the various denominations of bitcoin? ===<br />
<br />
Unlike most currencies, Bitcoin amounts are highly divisible. This has led to a desire to create names for smaller denominations of bitcoin amounts, especially since transactions involving whole bitcoins are no longer quite so common. Bitcoin is decentralized, so there is no organization that can set official names for units. Therefore, there are many different units with varying degrees of popularity. As of 2014, the most common units are bitcoins, bits, and satoshi: 1 bitcoin = 1 000 000.00 bits = 100 000 000 satoshi.<br />
<br />
The '''bitcoin''' (abbreviated '''BTC''' or '''XBT''') is the unit that was used in the original Bitcoin wallet software created by [[Satoshi Nakamoto]]. There is nothing particularly special about this unit, but it is by far the most common unit due to tradition.<br />
<br />
The smallest value that the Bitcoin network supports sending is the '''[[satoshi (unit)|satoshi]]''' (sometimes abbreviated '''sat'''), one hundred-millionth (0.000 000 01) of a bitcoin. In other words, the network does not support sending fractions of a satoshi. Since it is a hard limit, it seems natural to use it as a unit, though it currently has very little value. The unit was named in honor of Bitcoin's creator after he left -- he was not so vain as to name a unit after himself. The plural of satoshi is satoshi: "Send me 100 satoshi".<br />
<br />
Another common unit is the '''[[bit (unit)|bit]]''', one millionth (0.000 001) of a bitcoin. This unit is the same as a microbitcoin (μBTC). Bits are seen by some as especially logical because they have two-decimal precision like most fiat currencies. You can send 1.23 bits, but not 1.234 bits due to the network's limited precision.<br />
<br />
It is also fairly common to use SI prefixes:<br />
<br />
* 0.01 BTC = 1 cBTC = 1 centibitcoin (also referred to as bitcent)<br />
* 0.001 BTC = 1 mBTC = 1 millibitcoin (also referred to as mbit (pronounced em-bit) or millibit or even bitmill)<br />
* 0.000 001 BTC = 1 μBTC = 1 microbitcoin (also referred to as ubit (pronounced yu-bit) or microbit)<br />
<br />
For an overview of all proposed units of Bitcoin (including less common and niche units), see [[Units]].<br />
<br />
Further discussion on this topic can be found on the forums here:<br />
<br />
* [https://bitcointalk.org/index.php?topic=14438.msg195287#msg195287 We need names]<br />
* [https://bitcointalk.org/index.php?topic=8282.0 What to call 0.001 BTC]<br />
<br />
=== How does the halving work when the number gets really small? ===<br />
<br />
Eventually the reward will go from 0.00000001 BTC to zero and no more bitcoins will be created. <br />
<br />
The block reward calculation is done as a right bitwise shift of a 64-bit signed integer, which means it is divided by two and rounded down. The integer is equal to the value in BTC * 100,000,000 since internally in the reference client software, all Bitcoin balances and values are stored as unsigned integers.<br />
<br />
With an initial block reward of 50 BTC, it will take many 4-year periods for the block reward to reach zero.<br />
<br />
=== How long will it take to generate all the coins? ===<br />
<br />
The last block that will generate coins will be block #6,929,999 which should be generated at or near the year 2140. The total number of coins in circulation will then remain static at 20,999,999.9769 BTC.<br />
<br />
Even if the allowed precision is expanded from the current 8 decimals, the total BTC in circulation will always be slightly below 21 million (assuming everything else stays the same). For example, with 16 decimals of precision, the end total would be 20,999,999.999999999496 BTC.<br />
<br />
=== If no more coins are going to be generated, will more blocks be created? ===<br />
<br />
Absolutely! Even before the creation of coins ends, the use of [[transaction fee|transaction fees]] will likely make creating new blocks more valuable from the fees than the new coins being created. When coin generation ends, these fees will sustain the ability to use bitcoins and the Bitcoin network. There is no practical limit on the number of blocks that will be mined in the future.<br />
<br />
=== But if no more coins are generated, what happens when Bitcoins are lost? Won't that be a problem? ===<br />
<br />
Because of the law of supply and demand, when fewer bitcoins are available the ones that are left will be in higher demand, and therefore will have a higher value. So, as Bitcoins are lost, the remaining bitcoins will eventually increase in value to compensate. As the value of a bitcoin increases, the number of bitcoins required to purchase an item '''de'''creases. This is a [[Deflationary spiral|deflationary economic model]]. As the average transaction size reduces, transactions will probably be denominated in sub-units of a bitcoin such as millibitcoins ("Millies") or microbitcoins ("Mikes").<br />
<br />
The Bitcoin protocol uses a base unit of one hundred-millionth of a Bitcoin ("a Satoshi"), but unused bits are available in the protocol fields that could be used to denote even smaller subdivisions.<br />
<br />
=== If every transaction is broadcast via the network, does Bitcoin scale? ===<br />
<br />
The blockchain base layer is not very scalable but layer-2 technologies can be used to greatly increase bitcoin's scale. [[Lightning Network]] is one example which uses [[Contracts|smart contracts]] to build a network where payments are routed along a path instead of flooded to every peer. These payments can be nearly as secure and irreversible as blockchain transactions but have much better scalability (as well support instant payments which are much more private). Other possible layer-2 scalability technologies are sidechains or a bitcoin ecash chaumian bank.<br />
<br />
See also:<br />
* [https://www.reddit.com/r/Bitcoin/comments/438hx0/a_trip_to_the_moon_requires_a_rocket_with/ A trip to the moon requires a rocket with multiple stages]<br />
* [https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-December/011865.html Capacity increases for the Bitcoin system]<br />
* [[Scalability]].<br />
<br />
==Economy==<br />
=== Where does the value of Bitcoin stem from? What backs up Bitcoin? ===<br />
Bitcoins have value because they are useful and because they are [[Controlled Currency Supply|scarce]]. As they are accepted by more merchants, their value will [http://en.wikipedia.org/wiki/Sticky_%28economics%29 stabilize]. See the [[Trade|list of Bitcoin-accepting sites]].<br />
<br />
When we say that a currency is backed up by gold, we mean that there's a promise in place that you can exchange the currency for gold. Bitcoins, like dollars and euros, are not backed up by anything except the variety of merchants that accept them.<br />
<br />
It's a common misconception that Bitcoins gain their value from the cost of electricity required to generate them. Cost doesn't equal value – hiring 1,000 men to shovel a big hole in the ground may be costly, but not valuable. Also, even though scarcity is a critical requirement for a useful currency, it alone doesn't make anything valuable. For example, your fingerprints are scarce, but that doesn't mean they have any exchange value.<br />
<br />
Alternatively it needs to be added that while the law of supply and demand applies it does not guarantee value of Bitcoins in the future. If confidence in Bitcoins is lost then it will not matter that the supply can no longer be increased, the demand will fall off with all holders trying to get rid of their coins. An example of this can be seen in cases of state currencies, in cases when the state in question dissolves and so no new supply of the currency is available (the central authority managing the supply is gone), however the demand for the currency falls sharply because confidence in its purchasing power disappears. Of-course Bitcoins do not have such central authority managing the supply of the coins, but it does not prevent confidence from eroding due to other situations that are not necessarily predictable.<br />
<br />
=== Is Bitcoin a bubble? ===<br />
Yes, in the same way as the euro and dollar are. They only have value in exchange and have no inherent value. If everyone suddenly stopped accepting your dollars, euros or bitcoins, the "bubble" would burst and their value would drop to zero. But that is unlikely to happen: even in Somalia, where the government collapsed 20 years ago, [http://en.wikipedia.org/wiki/Somali_shilling Somali shillings] are still accepted as payment.<br />
<br />
=== Is Bitcoin a Ponzi scheme? ===<br />
In a Ponzi Scheme, the founders persuade investors that they’ll profit. Bitcoin does not make such a guarantee. There is no central entity, just individuals building an economy.<br />
<br />
A ponzi scheme is a zero sum game. Early adopters can only profit at the expense of late adopters. Bitcoin has possible win-win outcomes. Early adopters profit from the rise in value. Late adopters, and indeed, society as a whole, benefit from the usefulness of a stable, fast, inexpensive, and widely accepted p2p currency.<br />
<br />
The fact that early adopters benefit more doesn't alone make anything a Ponzi scheme. All good investments in successful companies have this quality.<br />
<br />
=== Doesn't Bitcoin unfairly benefit early adopters? ===<br />
Early adopters in Bitcoin are taking a risk and invested resources in an unproven technology. By so doing, they help Bitcoin become what it is now and what it will be in the future (hopefully, a ubiquitous decentralized digital currency). It is only fair they will reap the benefits of their successful investment.<br />
<br />
In any case, any bitcoin generated will probably change hands dozens of time as a medium of exchange, so the profit made from the initial distribution will be insignificant compared to the total commerce enabled by Bitcoin. Many of the earliest users of Bitcoin have traded their coins at valuations below $1 US, or other amounts which are small compared to contemporary prices.<br />
<br />
===Won't loss of wallets and the finite amount of Bitcoins create excessive deflation, destroying Bitcoin? ===<br />
Worries about Bitcoin being destroyed by deflation are not entirely unfounded. Unlike most currencies, which experience inflation as their founding institutions create more and more units, Bitcoin will likely experience gradual deflation with the passage of time. Bitcoin is unique in that only a small amount of units will ever be produced (twenty-one million to be exact), this number has been known since the project's inception, and the units are created at a predictable rate.<br />
<br />
Also, Bitcoin users are faced with a danger that doesn't threaten users of any other currency: if a Bitcoin user loses his wallet, his money is gone forever, unless he finds it again. And not just to him; it's gone completely out of circulation, rendered utterly inaccessible to anyone. As people will lose their wallets, the total number of Bitcoins will slowly decrease.<br />
<br />
Therefore, Bitcoin seems to be faced with a unique problem. Whereas most currencies inflate over time, Bitcoin will mostly likely do just the opposite. Time will see the irretrievable loss of an ever-increasing number of Bitcoins. An already small number will be permanently whittled down further and further. And as there become fewer and fewer Bitcoins, the laws of supply and demand suggest that their value will probably continually rise.<br />
<br />
Thus Bitcoin is bound to once again stray into mysterious territory, because no one exactly knows what happens to a currency that grows continually more valuable. Many economists claim that a low level of inflation is a good thing for a currency, but nobody is quite sure about what might happens to one that continually deflates. Although deflation could hardly be called a rare phenomenon, steady, constant deflation is unheard of. There may be a lot of speculation, but no one has any hard data to back up their claims.<br />
<br />
That being said, there is a mechanism in place to combat the obvious consequences. Extreme deflation would render most currencies highly impractical: if a single Canadian dollar could suddenly buy the holder a car, how would one go about buying bread or candy? Even pennies would fetch more than a person could carry. Bitcoin, however, offers a simple and stylish solution: infinite divisibility. Bitcoins can be divided up and trade into as small of pieces as one wants, so no matter how valuable Bitcoins become, one can trade them in practical quantities. <br />
<br />
In fact, infinite divisibility should allow Bitcoins to function in cases of extreme wallet loss. Even if, in the far future, so many people have lost their wallets that only a single Bitcoin, or a fraction of one, remains, Bitcoin should continue to function just fine. No one can claim to be sure what is going to happen, but deflation may prove to present a smaller threat than many expect.<br />
<br />
For more information, see the [[Deflationary spiral]] page.<br />
<br />
=== What if someone bought up all the existing Bitcoins? ===<br />
Bitcoin markets are competitive -- meaning the price of a bitcoin will rise or fall depending on supply and demand at certain price levels. Only a fraction of bitcoins issued to date are found on the exchange markets for sale. So even though technically, a buyer with lots of money could buy all the bitcoins offered for sale, unless those holding the rest of the bitcoins offer them for sale as well, even the wealthiest, most determined buyer can't get at them.<br />
<br />
Additionally, new currency continues to be issued daily and will continue to do so for decades; though over time the rate at which they are issued declines to insignificant levels. Those who are mining aren't obligated to sell their bitcoins so not all bitcoins will make it to the markets even.<br />
<br />
This situation doesn't suggest, however, that the markets aren't vulnerable to price manipulation. It doesn't take significant amounts of money to move the market price up or down, and thus Bitcoin remains a volatile asset.<br />
<br />
===What if someone creates a new block chain, or a new digital currency that renders Bitcoin obsolete?===<br />
<br />
That the block chain cannot be easily forked represents one of the central security mechanisms of Bitcoin. Given the choice between two block chains, a Bitcoin miner always chooses the longer one - that is to say, the one with the more complex hash. Thusly, it ensures that each user can only spend their bitcoins once, and that no user gets ripped off.<br />
<br />
As a consequence of the block chain structure, there may at any time be many different sub-branches, and the possibility always exists of a transaction being over-written by the longest branch, if it has been recorded in a shorter one. The older a transaction is though, the lower its chances of being over-written, and the higher of becoming permanent. Although the block chain prevents one from spending more Bitcoins than one has, it means that transactions can be accidentally nullified. <br />
<br />
A new block chain would leave the network vulnerable to [[double-spending|double-spend]] attacks. However, the creation of a viable new chain presents considerable difficulty, and the possibility does not present much of a risk.<br />
<br />
Bitcoin will always choose the longer Block Chain and determines the relative length of two branches by the complexities of their hashes. Since the hash of each new block is made from that of the block preceding it, to create a block with a more complex hash, one must be prepared to do more computation than has been done by the entire Bitcoin network from the fork point up to the newest of the blocks one is trying to supersede. Needless to say, such an undertaking would require a very large amount of processing power and since Bitcoin is continually growing and expanding, it will likely only require more with the passage of time.<br />
<br />
A much more distinct and real threat to the Bitcoin use is the development of other, superior virtual currencies, which could supplant Bitcoin and render it obsolete and valueless.<br />
<br />
A great deal of careful thought and ingenuity has gone into the development of Bitcoin, but it is the first of its breed, a prototype, and vulnerable to more highly-evolved competitors. At present, any threatening rivals have yet to rear their heads; Bitcoin remains the first and foremost private virtual currency, but we can offer no guarantees that it will retain that position. It would certainly be in keeping with internet history for a similar system built from the same principles to supersede and cast Bitcoin into obsolescence, after time had revealed its major shortcomings. Friendster and Myspace suffered similar fates at the hand of Facebook, Napster was ousted by Limeware, Bearshare and torrent applications, and Skype has all but crushed the last few disciples of the Microsoft Messenger army. <br />
<br />
This may sound rather foreboding, so bear in mind that the introduction of new and possibly better virtual currencies will not necessarily herald Bitcoin's demise. If Bitcoin establishes itself sufficiently firmly before the inception of the next generation of private, online currencies so as to gain widespread acceptance and general stability, future currencies may pose little threat even if they can claim superior design. This is known as the network effect.<br />
<br />
=== Is Bitcoin open to value manipulation? ===<br />
<br />
The current low market cap of Bitcoin means that any investor with deep enough pockets can significantly change/manipulate the rate. Is this a problem?<br />
<br />
This is only a problem if you are investing in Bitcoin for short period of time. A manipulator can't change the fundamentals, and over a period of 5-10 years, the fundamentals will win over any short term manipulations.<br />
<br />
==Sending and Receiving Payments==<br />
<br />
=== Why do I have to wait 10 minutes before I can spend money I received? ===<br />
<br />
10 minutes is the average time taken to find a block. It can be significantly more or less time than that depending on luck; 10 minutes is simply the average case. <br />
<br />
[[Blocks]] (shown as "[[Confirmation|confirmations]]" in the GUI) are how the Bitcoin achieves consensus on who owns what. Once a block is found everyone agrees that you now own those coins, so you can spend them again. Until then it's possible that some network nodes believe otherwise, if somebody is attempting to defraud the system by reversing a transaction. The more confirmations a transaction has, the less risk there is of a reversal. Only 6 blocks or 1 hour is enough to make reversal computationally impractical. This is dramatically better than credit cards which can see chargebacks occur up to three months after the original transaction!<br />
<br />
Ten minutes was specifically chosen by [[Satoshi]] as a tradeoff between first confirmation time and the amount of work wasted due to chain splits. After a block is mined, it takes time for other miners to find out about it, and until then they are actually competing against the new block instead of adding to it. If someone mines another new block based on the old block chain, the network can only accept one of the two, and all the work that went into the other block gets wasted. For example, if it takes miners 1 minute on average to learn about new blocks, and new blocks come every 10 minutes, then the overall network is wasting about 10% of its work. Lengthening the time between blocks reduces this waste.<br />
<br />
As a thought experiment, what if the Bitcoin network grew to include Mars? From the farthest points in their orbits, it takes about 20 minutes for a signal to travel from Earth to Mars. With only 10 minutes between new blocks, miners on Mars would always be 2 blocks behind the miners on Earth. It would be almost impossible for them to contribute to the block chain. If we wanted collaborate with those kinds of delays, we would need at least a few hours between new blocks. <br />
<br />
[[File:TransactionConfirmationTimesExample.PNG]]<br />
<br />
=== Do you have to wait until my transactions are confirmed in order to buy or sell things with Bitcoin? ===<br />
<br />
YES, you do, IF the transaction is non-recourse. The Bitcoin reference software does not display transactions as confirmed until six blocks have passed (confirmations). As transactions are buried in the chain they become increasingly non-reversible but are very reversible before the first confirmation. Two to six confirmations are recommended for non-recourse situations depending on the value of the transactions involved.<br />
<br />
When people ask this question they are usually thinking about applications like supermarkets. This generally is a recourse situation: if somebody tries to double-spend on a face-to-face transaction it might work a few times, but probabalistically speaking eventually one of the double-spends will get noticed, and the penalty for shoplifting charges in most localities is calibrated to be several times worse than the proceeds of a single shoplifting event.<br />
<br />
Double-spends might be a concern for something like a snack machine in a low-traffic area with no nearby security cameras. Such a machine shouldn't honor zero-confirmation payments, and should instead use some other mechanism of clearing Bitcoin or validating transactions against reversal, see the wiki article [[Myths#Point_of_sale_with_bitcoins_isn.27t_possible_because_of_the_10_minute_wait_for_confirmation|here]] for alternatives.<br />
<br />
Applications that require immediate payment processing, like supermarkets or snack machines, need to manage the risks. Here is one way to reverse an unconfirmed payment:<br />
<br />
A [[Double-spending#Finney_attack|Finney attack]] is where an attacker mines a block containing a movement of some coins back to themselves. Once they find a block solution, they quickly go to a merchant and make a purchase, then broadcast the block, thus taking back the coins. This attack is a risk primarily for goods that are dispatched immediately, like song downloads or currency trades. Because the attacker can't choose the time of the attack, it isn't a risk for merchants such as supermarkets where you can't choose exactly when to pay (due to queues, etc). The attack can fail if somebody else finds a block containing the purchasing transaction before you release your own block, therefore, merchants can reduce but not eliminate the risk by making purchasers wait some length of time that's less than a confirm.<br />
<br />
Because pulling off this attack is not trivial, merchants who need to sell things automatically and instantly are most likely to adjust the price to include the cost of reversal fraud, or elect to use special insurance.<br />
<br />
=== I was sent some bitcoins and they haven't arrived yet! Where are they? ===<br />
<br />
Don't panic! There are a number of reasons why your bitcoins might not show up yet, and a number of ways to diagnose them. <br />
<br />
The latest version of the Bitcoin-Qt client tells you how far it has yet to go in downloading the blockchain. Hover over the icon in the bottom right corner of the client to learn your client's status.<br />
<br />
If it has not caught up then it's possible that your transaction hasn't been included in a block yet. <br />
<br />
You can check pending transactions in the network by going [https://www.biteasy.com here] or [http://blockchain.info here] and then searching for your address. If the transaction is listed here then it's a matter of waiting until it gets included in a block before it will show in your client. <br />
<br />
If the transaction is based on a coin that was in a recent transaction then it could be considered a low priority transaction. Transfers can take longer if the transaction fee paid was not high enough. If there is no fee at all the transfer can get a very low priority and take hours or even days to be included in a block.<br />
<br />
<br />
=== I sent too small of a transaction fee, is my bitcoin lost forever? ===<br />
<br />
<br />
If the transaction never gets confirmed into a block - the mempool expiry of all nodes will drop it eventually and you will be able to spend your funds again - [https://hackernoon.com/holy-cow-i-sent-a-bitcoin-transaction-with-too-low-fees-are-my-coins-lost-forever-7a865e2e45ba typically] it takes about 3 days or so for this to happen. If using an [[https://en.bitcoin.it/w/index.php?title=Scalability#Simplified_payment_verification SPV]] wallet such as [[ Electrum]] or [[Multibit]], if after three days the wallet does not see the coin to spend, you need to reindex your wallet's block headers. After reindexing, your wallet will see that the coin was never confirmed and thus the balance will be spendable again. <br />
<br />
'''NOTE''': From Bitcoin 0.14 “transaction reappearance” happens after 2 [https://www.reddit.com/r/Bitcoin/comments/69jywp/a_practical_guide_to_accidental_low_fee/dhjfthf/ weeks].<br />
<br />
=== Why does my Bitcoin address keep changing? ===<br />
{{seealso|Address reuse}}<br />
Unlike postal and email addresses, Bitcoin addresses are designed to be used exactly once only, for a single transaction.<br />
Originally, wallets would display only a single address at a time, and change it when a transaction was received, but an increasing number of wallet implementations now generate an address when you explicitly want to receive a payment.<br />
<br />
While it is technically possible to use an address for an arbitrary number of payments, this works by accident and harms both yourself ''and other unrelated third parties'', so it is considered a bad practice.<br />
The most important concerns with such misuse involve loss of privacy and security:<br />
both can be put into jeopardy when addresses are used for more than a single transaction only.<br />
<br />
===How much will the transaction fee be? / Why is the fee so high?===<br />
<br />
Bitcoin transactions almost always require a [[transaction fee]] for them to get confirmed. The transaction fee is received by the first bitcoin miner who mines a [[block]] containing the transaction; this action is also what gives the transaction its first confirmation. The appropriate fee varies depending on how large (in bytes) your transaction is, how fast you want the transaction to be confirmed, and also on current network conditions. As such, paying a fixed fee, or even a fixed fee per kB, is a very bad idea; all good Bitcoin wallets will use several pieces of data to estimate an appropriate fee for you, though some are better at fee estimation than others.<br />
<br />
The fee most strongly depends on the transaction's data size. Fees do '''not''' depend on the BTC amount of the transaction -- it's entirely possible for a 0.01 BTC transaction to require a higher fee than a 1000 BTC transaction.<br />
<br />
Basic intro to how Bitcoin [[transactions]] work: If you receive BTC in three separate transactions of (say) 1, 5, and 10 BTC, then you can think of your wallet as containing three gold coins with sizes 1, 5, and 10 BTC. If you then want to send 6 BTC, you can melt the 1 & 5 BTC coins together and recast them as a 6 BTC coin, or melt the 10 BTC coin and recast a 6 BTC coin for the recipient and a 4 BTC coin as change for yourself. In Bitcoin's technical vocabulary, these objects are literally called input and output coins. (In the rest of this section, when we say "coin" we mean these objects, not the amount of BTC value.)<br />
<br />
Transaction data sizes, and therefore fees, are proportional to the '''number''' (not value) of input and output coins in a transaction. Input coins are about 5x larger / more expensive than output coins.<br />
<br />
If your wallet estimates a very high fee, it is most likely because your wallet is full of a whole bunch of tiny coins, so your transaction will need to take very many coins as inputs, increasing the cost. On the bright side, fees will go down once you make a few transactions, since you will end up "melting down" these many small coins into a few larger ones. Sometimes you can significantly reduce the fee by sending less BTC: if you have like 1000 tiny faucet payments totaling 0.5 BTC and then 16.5 BTC from other sources, then you'll find that sending ~16.5 BTC will be massively cheaper than sending a slightly higher value since it avoids including all of those faucet coins.<br />
<br />
Fees also fluctuate depending on network conditions. All unconfirmed transactions compete with each other to be picked up by miners. If there are a lot of high-fee transactions being sent right now, then you will need to pay higher fees to out-bid them. On the other hand, if speed is less important to you, you can pay a somewhat smaller fee, and your transaction will float around until there is a period of reduced network usage. Sometimes even transactions with zero fee will be confirmed after a very long period of time, though this requires a perfect set of conditions, beyond what is explained here (ie. it probably won't work if you try it).<br />
<br />
Oftentimes wallets will have an "express" fee configuration, but note that confirmation times are naturally random and unreliable. At any given point in time, the probability that ''no'' transactions will be confirmed in the next hour is about 0.25% (ie. it happens more than once per week on average). Bitcoin users should avoid getting into situations where their transactions ''absolutely must'' get 1 confirmation in the next couple of hours, even if high-fee transactions usually take less than 10 minutes to get 1 confirmation.<br />
<br />
=== What happens when someone sends me a bitcoin but my computer is powered off? ===<br />
<br />
Bitcoins are not actually "sent" to your wallet; the software only uses that term so that we can use the currency without having to learn new concepts. Your wallet is only needed when you wish to spend coins that you've received.<br />
<br />
If you are sent coins when your wallet client program is not running, and you later launch the wallet client program, the coins will eventually appear as if they were just received in the wallet. That is to say, when the client program is started it must download blocks and catch up with any transactions it did not already know about.<br />
<br />
=== How long does "synchronizing" take when the Bitcoin client is first installed? What's it doing? ===<br />
<br />
The popular Bitcoin client software from bitcoin.org implements a "full" Bitcoin node: It can carry out all the duties of the Bitcoin P2P system, it isn't simply a "client". One of the principles behind the operation of full Bitcoin nodes is that they don't assume that the other participants have followed the rules of the Bitcoin system. During synchronization, the software is processing historical Bitcoin transactions and making sure for itself that all of the rules of the system have been correctly followed.<br />
<br />
In normal operation, after synchronizing, the software should use a hardly noticeable amount of your computer's resources.<br />
<br />
When the wallet client program is first installed, its initial validation requires a lot of work from your computer's hard disk, so the amount of time to synchronize depends on your disk speed and, to a lesser extent, your CPU speed. It can take anywhere from a few hours to a day or so. On a slow computer it could take more than 40 hours of continuous synchronization, so check your computer's power-saving settings to ensure that it does not turn its hard disk off when unattended for a few hours. You can use the Bitcoin software during synchronization, but you may not see recent payments to you until the client program has caught up to the point where those transactions happened.<br />
<br />
If you feel that this process takes too long, you can download a pre-synchronized blockchain from [http://eu2.bitcoincharts.com/blockchain/ http://eu2.bitcoincharts.com/blockchain/]. Alternatively, you can try an alternative "lite" client such as Multibit or a super-light client like electrum, though these clients have somewhat weaker security, are less mature, and don't contribute to the health of the P2P network.<br />
<br />
==Networking==<br />
=== Do I need to configure my firewall to run Bitcoin? ===<br />
<br />
Bitcoin will connect to other nodes, usually on TCP port 8333. You will need to allow outgoing TCP connections to port 8333 if you want to allow your Bitcoin client to connect to many nodes. [[Testnet]] uses TCP port 18333 instead of 8333.<br />
<br />
If you want to restrict your firewall rules to a few IPs, you can find stable nodes in the [[Fallback Nodes|fallback nodes list]].<br />
<br />
=== How does the peer finding mechanism work? ===<br />
<br />
Bitcoin finds peers primarily by forwarding peer announcements within its own network and each node saves a database of peers that it's aware of, for future use. In order to bootstrap this process Bitcoin needs a list of initial peers, these can be provided manually but normally it obtains them by querying a set of DNS domain names which have automatically updated lists, if that doesn't work it falls back to a built-in list which is updated from time to time in new versions of the software. In the reference software initial peers can also be specified manually by adding an addr.txt to the data directory or via the addnode parameter.<br />
<br />
==Mining==<br />
===What is mining?===<br />
[[Mining]] is the process of spending computation power to secure Bitcoin transactions against reversal and introducing new Bitcoins to the system<ref>[https://www.bitcoinmining.com Bitcoin Mining]</ref>.<br />
<br />
Technically speaking, mining is the calculation of a [[hash]] of the a block header, which includes among other things a reference to the previous block, a hash of a set of transactions and a [[nonce]]. If the hash value is found to be less than the current [[target]] (which is inversely proportional to the [[difficulty]]), a new block is formed and the miner gets the newly generated Bitcoins (25 per block at current levels). If the hash is not less than the current target, a new nonce is tried, and a new hash is calculated. This is done millions of times per second by each miner.<br />
<br />
===Is mining used for some useful computation?===<br />
The computations done when mining are internal to Bitcoin and not related to any other distributed computing projects. They serve the purpose of securing the Bitcoin network, which is useful.<br />
<br />
===Is it not a waste of energy?===<br />
Spending energy on creating and securing a free monetary system is hardly a waste. Also, services necessary for the operation of currently widespread monetary systems, such as banks and credit card companies, also spend energy, arguably more than Bitcoin would.<br />
<br />
===Why don't we use calculations that are also useful for some other purpose?===<br />
To provide security for the Bitcoin network, the calculations involved need to have some [http://bitcoin.stackexchange.com/questions/5617/why-are-bitcoin-calculation-useless/5618#5618 very specific features]. These features are incompatible with leveraging the computation for other purposes.<br />
<br />
===How can we stop miners from creating zero transaction blocks?===<br />
The incentive for miners to include transactions is in the fees that come along with them. If we were to implement some minimum number of transactions per block it would be trivial for a miner to create and include transactions merely to surpass that threshold. As the network matures, the block reward drops, and miners become more dependent on transactions fees to pay their costs, the problem of zero transaction blocks should diminish over time.<br />
<br />
===How does the proof-of-work system help secure Bitcoin?===<br />
Bitcoin uses the [[Hashcash]] [[proof of work]] with a minor adaption. To give a general idea of the mining process, imagine this setup:<br />
<br />
payload = <some data related to things happening on the Bitcoin network><br />
nonce = 1<br />
hash = [http://en.wikipedia.org/wiki/SHA2 SHA2]( [http://en.wikipedia.org/wiki/SHA2 SHA2]( payload + nonce ) )<br />
<br />
The work performed by a miner consists of repeatedly increasing "nonce" until<br />
the hash function yields a value, that has the rare property of being below a certain<br />
target threshold. (In other words: The hash "starts with a certain number of zeroes",<br />
if you display it in the fixed-length representation, that is typically used.)<br />
<br />
As can be seen, the mining process doesn't compute anything special. It merely<br />
tries to find a number (also referred to as nonce) which - in combination with the payload -<br />
results in a hash with special properties.<br />
<br />
The advantage of using such a mechanism consists of the fact, that it is very easy to check a result: Given the payload and a specific nonce, only a single call of the hashing function is needed to verify that the hash has the required properties. Since there is no known way to find these hashes other than brute force, this can be used as a "[[proof of work]]" that someone invested a lot of computing power to find the correct nonce for this payload.<br />
<br />
This feature is then used in the Bitcoin network to allow the network to come to a consensus on the history of transactions. An attacker that wants to rewrite history will need to do the required proof of work before it will be accepted. And as long as honest miners have more computing power, they can always outpace an attacker.<br />
<br />
Also see [http://en.wikipedia.org/wiki/Hashcash Hashcash] and [http://en.wikipedia.org/wiki/Proof-of-work_system Proof-of-work system] and [http://en.wikipedia.org/wiki/SHA2 SHA2] and on Wikipedia.<br />
<br />
===Why was the "Generate coin" option of the client software removed?===<br />
<br />
The option wasn't removed, but it is now only accessible via the command-line or the configuration file. The reason for this is that many users were complaining after they turned on and expecting to receive coins. Without specialized mining hardware a user is exceptionally unlikely generate a block on their own at the network's current [[difficulty|security level]].<br />
<br />
==Security==<br />
<br />
===Could miners collude to give themselves money or to fundamentally change the nature of Bitcoin?===<br />
<br />
There are two questions in here. Let's look at them separately.<br />
<br />
;Could miners gang up and give themselves money?<br />
<br />
Mining itself is the process of creating new blocks in the block chain. Each block contains a list of all the transactions that have taken place across the entire Bitcoin network since the last block was created, as well as a hash of the previous block. New blocks are 'mined', or rather, generated, by Bitcoin clients correctly guessing sequences of characters in codes called 'hashes,' which are created using information from previous blocks. Bitcoin users may download specialized 'mining' software, which allows them to dedicate some amount of their processing power – however large or small – to guessing at strings within the hash of the previous block. Whoever makes the right guess first, thus creating a new block, receives a reward in Bitcoins.<br />
<br />
The block chain is one of the two structures that makes Bitcoin secure, the other being the public-key encryption system on which Bitcoin trade is based. The block chain assures that not only is every single transaction that ever takes place recorded, but that every single transaction is recorded on the computer of anyone who chooses to store the relevant information. Many, many users have complete records of every transaction in Bitcoins history readily available to them at any point, and anyone who wants in the information can obtain it with ease. These things make Bitcoin very hard to fool.<br />
<br />
The Bitcoin network takes considerable processing power to run, and since those with the most processing power can make the most guesses, those who put the most power toward to sustaining the network earn the most currency. Each correct guess yields, at present, twenty-five Bitcoins, and as Bitcoins are presently worth something (although the value still fluctuates) every miner who earns any number of Bitcoins makes money. Some miners pull in Bitcoins on their own; and some also join or form pools wherein all who contribute earn a share of the profits. <br />
<br />
Therefore, first answer is a vehement “yes” – not only can miners collude to get more money, Bitcoin is designed to encourage them to do so. Bitcoin pools are communal affairs, and there is nothing dishonest or underhanded about them.<br />
<br />
Of course, the real question is:<br />
<br />
;Can they do so in ways not sanctioned by Bitcoin network? Is there any way to rip off the network and make loads of money dishonestly?<br />
<br />
Bitcoin isn't infallible. It can be cheated, but doing so is extremely difficult. Bitcoin was designed to evade some of the central problems with modern currencies – namely, that their trustworthiness hinges upon that of people who might not have users' best interests in mind. Every currency in the world (other than Bitcoin) is controlled by large institutions who keep track of what's done with it, and who can manipulate its value. And every other currency has value because people trust the institutions that control them.<br />
<br />
Bitcoin doesn't ask that its users trust any institution. Its security is based on the cryptography that is an integral part of its structure, and that is readily available for any and all to see. Instead of one entity keeping track of transactions, the entire network does, so Bitcoins are astoundingly difficult to steal, or double-spend. Bitcoins are created in a regular and predictable fashion, and by many different users, so no one can decide to make a whole lot more and lessen their value. In short, Bitcoin is designed to be inflation-proof, double-spend-proof and completely distributed.<br />
<br />
Nonetheless, there are a few ways that one can acquire Bitcoins dishonestly. Firstly, one can steal private keys. Key theft isn't something that Bitcoin security has been designed to prevent: it's up to users to keep their keys safe. But the cryptography is designed so that it is completely impossible to deduce someone's private key from their public one. As long as you keep your private key to yourself, you don't have much to worry about. Furthermore, one could theoretically create a new block chain, but due to the way in which the block chain is constructed, this would be extremely difficult and require massive amounts of processing power. A full explanation of the difficulties involved can be found in the [[block chain]] article.<br />
<br />
Bitcoin can be ripped off – but doing so would be extremely hard and require considerable expertise and a staggering amount of processing power. And it's only going to get harder with time. Bitcoin isn't impenetrable, but it's close enough to put any real worries in the peripherals.<br />
<br />
;Could miners fundamentally change the nature of Bitcoin?<br />
<br />
Once again, almost certainly not.<br />
<br />
Bitcoin is a distributed network, so any changes implemented to the system must be accepted by all users. Someone trying to change the way Bitcoins are generated would have to convince every user to download and use their software – so the only changes that would go through are those that would be equally benefit all users. <br />
<br />
And thus, it is more or less impossible for anyone to change the function of Bitcoin to their advantage. If users don't like the changes, they won't adopt them, whereas if users do like them, then these will help everyone equally. Of course, one can conceive of a situation where someone manages to get a change pushed through that provides them with an advantage that no one notices, but given that Bitcoin is structurally relatively simple, it is unlikely that any major changes will go through without someone noticing first.<br />
<br />
The fact that such changes are so difficult to make testifies to the fully distributed nature of Bitcoin. Any centrally controlled currency can be modified by its central agency without the consent of its adherents. Bitcoin has no central authority, so it changes only at the behest of the whole community. Bitcoins development represents a kind of collective evolution; the first of its kind among currencies.<br />
<br />
==Help==<br />
===I'd like to learn more. Where can I get help?===<br />
<br />
* Read the [[Introduction|introduction to bitcoin]] <br />
* See the videos, podcasts, and blog posts from the [[Press]]<br />
* Read and post on the [[:Bitcoin Wiki:Community_portal#Bitcoin_Community_Forums|forums]]<br />
* Chat on one of the [[:Bitcoin Wiki:Community_portal#IRC_Chat|Bitcoin IRC]] channels<br />
* Listen to [http://omegataupodcast.net/2011/03/59-bitcoin-a-digital-decentralized-currency/ this podcast], which goes into the details of how bitcoin works<br />
* Ask questions on the [http://bitcoin.stackexchange.com Bitcoin Stack Exchange]<br />
* Use [http://bitcoinx.io BitcoinX.io] to help beginners learn about reputable Bitcoin exchanges and Bitcoin wallets<br />
<br />
==See Also==<br />
<br />
* [[Man page]]<br />
* [[Introduction]]<br />
* [[Prohibited changes]]<br />
<br />
==References==<br />
<references><br />
<references/><br />
{{Reflist|2}}<br />
<br />
[[de:FAQ]]<br />
[[zh-cn:FAQ]]<br />
[[fr:FAQ]]<br />
[[ru:FAQ]]<br />
<br />
[[Category:Technical]]<br />
[[Category:Vocabulary]]</div>Hardinghttps://en.bitcoin.it/w/index.php?title=Help:FAQ&diff=65510Help:FAQ2018-06-25T21:49:18Z<p>Harding: Undo revision 65502 by RunCPA (talk)</p>
<hr />
<div>Here you will find answers to the most commonly asked questions.<br />
<br />
== General ==<br />
=== What is Bitcoin? ===<br />
Bitcoin is a distributed peer-to-peer digital currency that can be transferred instantly and securely between any two people in the world. It's like electronic cash that you can use to pay friends or merchants.<br />
<br />
=== What are bitcoins? ===<br />
Bitcoins are the unit of currency of the Bitcoin system. A commonly used shorthand for this is “BTC” to refer to a price or amount (e.g. “100 BTC”).<br />
There are such things as [[physical bitcoins]], but ultimately, a bitcoin is just a number associated with a [[Address|Bitcoin Address]]. A physical bitcoin is simply an object, such as a coin, with the number carefully embedded inside. See also an [[Introduction|easy intro]] to Bitcoin.<br />
<br />
=== How can I get bitcoins? ===<br />
<br />
There are a variety of ways to acquire bitcoins:<br />
* Accept bitcoins as payment for goods or services.<br />
* You can buy bitcoins from [https://www.bitit.gift/ Bitit] [https://www.coinbase.com/buy-bitcoin Coinbase], [https://paybis.com/ PayBis], [http://cubits.com/ Cubits], [https://www.coincorner.com CoinCorner], [[File:BIPS.gif|20px|link=https://bipsmarket.com]] [https://bipsmarket.com BIPS Market], [https://circle.com Circle], or [http://gocelery.com/ Celery].<br />
* The most common way to buy bitcoins are the [[Buying bitcoins|Bitcoin Exchanges]]<br />
* There are several services where you can [[Buying_Bitcoins_(the_noob_version)|trade them]] for traditional currency.<br />
* You can also buy bitcoins using [http://nationalbitcoinatm.com Bitcoin ATMs] that are locally in your area.<br />
* Find someone to trade cash for bitcoins in-person through a [https://en.bitcoin.it/wiki/Category:Directories local directory].<br />
* Participate in a [[Pooled mining|mining pool]].<br />
* If you have a lot of [https://cryptocomes.com/cryptocurrency-cloud-mining-vs-hardware-mining-which-is-more-profitable mining hardware], you can solo mine and attempt to create a new [[block]] (currently yields 12.5 bitcoins plus transaction fees).<br />
* Visit sites that provide [[Trade#Free_Samples_and_Offers|free samples and offers]].<br />
<br />
===Does Bitcoin guarantee an influx of free money?===<br />
<br />
Since Bitcoin is a new technology, what it is and how it works may be initially unclear. Bitcoin is sometimes presented as being one of three things:<br />
<ol style="list-style-type: upper-alpha;"><br />
<li>Some sort of online 'get-rich-quick' scam.</li><br />
<li>A loophole in the market economy, the installation of which guarantees a steady influx of cash.</li><br />
<li>A sure investment that will almost certainly yield a profit.</li><br />
</ol><br />
In fact, none of the above are true. Let's look at them independently.<br />
<br />
;Is Bitcoin a 'get-rich-quick' scheme?<br />
:If you've spent much time on the Internet, you've probably seen ads for many 'get-rich-quick' schemes. These ads usually promise huge profits for a small amounts of easy work. Such schemes are usually pyramid/matrix-style schemes that make money from their own employees and offer nothing of any real value. Most convince one to buy packages that will make them earn hundreds a day, which in fact have the buyer distribute more such ads, and make minute profits.<br />
<br />
:Bitcoin is in no way similar to these schemes. Bitcoin doesn't promise windfall profits. There is no way for the developers to make money from your involvement or to take money from you. That bitcoins are nearly impossible to acquire without the owner's consent represents one of its greatest strengths. Bitcoin is an experimental, virtual currency that may succeed or may fail. None of its developers expect to get rich off of it. <br />
<br />
:A more detailed answer to this question can be found [http://bitcointalk.org/?topic=7815.0 here].<br />
<br />
;Will I make money by installing the client?<br />
:Most people who use Bitcoin don't earn anything by doing so, and the default client has no built-in way to earn Bitcoins. A small minority of people with dedicated, high-performance hardware do earn some Bitcoins by "''mining''" (generating new bitcoins, see [[#What is mining?|What is mining?]]) with special software, but joining Bitcoin shouldn't be construed as being the road to riches. Most Bitcoin users get involved because they find the project conceptually interesting and don't earn anything by doing so. This is also why you won't find much speculation about the political or economic repercussions of Bitcoin anywhere on this site: Bitcoin developers owe their dedication to the project's intellectual yieldings more than to those of a monetary nature. Bitcoin is still taking its first baby steps; it may go on to do great things but right now it only has something to offer those chasing conceptually interesting projects or bleeding edge technology.<br />
<br />
;As an investment, is Bitcoin a sure thing?<br />
:Bitcoin is a new and interesting electronic currency, the value of which is not backed by any single government or organization. Like other currencies, it is worth something partly because people are willing to trade it for goods and services. Its exchange rate fluctuates continuously, and sometimes wildly. It lacks wide acceptance and is vulnerable to manipulation by parties with modest funding. Security incidents such as website and account compromise may trigger major sell-offs. Other fluctuations can build into positive feedback loops and cause much larger exchange rate fluctuations. Anyone who puts money into Bitcoin should understand the risk they are taking and consider it a high-risk currency. Later, as Bitcoin becomes better known and more widely accepted, it may stabilize, but for the time being it is unpredictable. Any investment in Bitcoin should be done carefully and with a clear plan to manage the risk.<br />
<br />
=== Can I buy bitcoins with Paypal? ===<br />
<br />
It is possible to buy [[physical bitcoins]] with PayPal but it is otherwise difficult and/or expensive to do so for non-physical bitcoins, because of significant risk to the seller. <br />
<br />
While it is possible to find an individual who wishes to sell Bitcoin to you via Paypal, (perhaps via [http://www.bitcoin-otc.com/ #bitcoin-otc] ) most exchanges do not allow funding through PayPal. This is due to repeated cases where someone pays for bitcoins with Paypal, receives their bitcoins, and then fraudulently complains to Paypal that they never received their purchase. PayPal often sides with the fraudulent buyer in this case, which means any seller needs to cover that risk with higher fees or refuse to accept PayPal altogether.<br />
<br />
Buying Bitcoins from individuals this way is still possible, but requires the seller to have some trust that the buyer will not file a claim with PayPal to reverse the payment.<br />
<br />
Also [https://bitbuy.in/ bitbuy.in] and [https://paybis.com/ PayBis], allows you to buy Bitcoins with PayPal.<br />
<br />
=== Where can I find a forum to discuss Bitcoin? ===<br />
<br />
Please visit the [[Bitcoin Wiki:Community_portal#Bitcoin_Community_Forums_on_various_platforms|Community Portal]] for links to Bitcoin-related forums.<br />
<br />
=== How are new bitcoins created? ===<br />
<br />
New bitcoins are generated by the network through the process of "[[#What is mining?|''mining'']]". In a process that is similar to a continuous raffle draw, mining nodes on the network are awarded bitcoins each time they find the solution to a certain mathematical problem (and thereby create a new [[block]]). Creating a block is a [[proof of work]] with a difficulty that varies with the overall strength of the network. The reward for solving a block is [[Controlled Currency Supply|automatically adjusted]] so that, ideally, every four years of operation of the Bitcoin network, half the amount of bitcoins created in the prior 4 years are created. A maximum of {{formatnum:10499889.80231183}} bitcoins were created in the first 4 (approx.) years from January 2009 to November 2012. Every four years thereafter this amount halves, so it should be {{formatnum:5250000}} over years 4-8, {{formatnum:2625000}} over years 8-12, and so on. Thus the total number of bitcoins in existence can never exceed {{formatnum:20999839.77085749}} and counting. See [[Controlled Currency Supply]].<br />
<br />
Blocks are [[Mining|mined]] every 10 minutes, on average and for the first four years ({{formatnum:210000}} blocks) each block included 50 new bitcoins. As the amount of processing power directed at mining changes, the difficulty of creating new bitcoins changes. This difficulty factor is calculated every 2016 blocks and is based upon the time taken to generate the previous 2016 blocks. See [[Mining]].<br />
<br />
=== What's the current total number of bitcoins in existence? ===<br />
<br />
[http://blockexplorer.com/q/totalbc Current count]. Also see [https://blockchain.info/charts/total-bitcoins Total bitcoins in circulation chart]<br />
<br />
The number of blocks times the coin value of a block is the number of coins in existence. The coin value of a block is 50 BTC for each of the first {{formatnum:210000}} blocks, 25 BTC for the next {{formatnum:210000}} blocks, then 12.5 BTC, 6.25 BTC and so on.<br />
<br />
=== How divisible are bitcoins? ===<br />
<br />
A bitcoin can be divided down to 8 decimal places. Therefore, 0.00000001 BTC is the smallest amount that can be handled in a transaction. If necessary, the protocol and related software can be modified to handle even smaller amounts.<br />
<br />
=== What do I call the various denominations of bitcoin? ===<br />
<br />
Unlike most currencies, Bitcoin amounts are highly divisible. This has led to a desire to create names for smaller denominations of bitcoin amounts, especially since transactions involving whole bitcoins are no longer quite so common. Bitcoin is decentralized, so there is no organization that can set official names for units. Therefore, there are many different units with varying degrees of popularity. As of 2014, the most common units are bitcoins, bits, and satoshi: 1 bitcoin = 1 000 000.00 bits = 100 000 000 satoshi.<br />
<br />
The '''bitcoin''' (abbreviated '''BTC''' or '''XBT''') is the unit that was used in the original Bitcoin wallet software created by [[Satoshi Nakamoto]]. There is nothing particularly special about this unit, but it is by far the most common unit due to tradition.<br />
<br />
The smallest value that the Bitcoin network supports sending is the '''[[satoshi (unit)|satoshi]]''' (sometimes abbreviated '''sat'''), one hundred-millionth (0.000 000 01) of a bitcoin. In other words, the network does not support sending fractions of a satoshi. Since it is a hard limit, it seems natural to use it as a unit, though it currently has very little value. The unit was named in honor of Bitcoin's creator after he left -- he was not so vain as to name a unit after himself. The plural of satoshi is satoshi: "Send me 100 satoshi".<br />
<br />
Another common unit is the '''[[bit (unit)|bit]]''', one millionth (0.000 001) of a bitcoin. This unit is the same as a microbitcoin (μBTC). Bits are seen by some as especially logical because they have two-decimal precision like most fiat currencies. You can send 1.23 bits, but not 1.234 bits due to the network's limited precision.<br />
<br />
It is also fairly common to use SI prefixes:<br />
<br />
* 0.01 BTC = 1 cBTC = 1 centibitcoin (also referred to as bitcent)<br />
* 0.001 BTC = 1 mBTC = 1 millibitcoin (also referred to as mbit (pronounced em-bit) or millibit or even bitmill)<br />
* 0.000 001 BTC = 1 μBTC = 1 microbitcoin (also referred to as ubit (pronounced yu-bit) or microbit)<br />
<br />
For an overview of all proposed units of Bitcoin (including less common and niche units), see [[Units]].<br />
<br />
Further discussion on this topic can be found on the forums here:<br />
<br />
* [https://bitcointalk.org/index.php?topic=14438.msg195287#msg195287 We need names]<br />
* [https://bitcointalk.org/index.php?topic=8282.0 What to call 0.001 BTC]<br />
<br />
=== How does the halving work when the number gets really small? ===<br />
<br />
Eventually the reward will go from 0.00000001 BTC to zero and no more bitcoins will be created. <br />
<br />
The block reward calculation is done as a right bitwise shift of a 64-bit signed integer, which means it is divided by two and rounded down. The integer is equal to the value in BTC * 100,000,000 since internally in the reference client software, all Bitcoin balances and values are stored as unsigned integers.<br />
<br />
With an initial block reward of 50 BTC, it will take many 4-year periods for the block reward to reach zero.<br />
<br />
=== How long will it take to generate all the coins? ===<br />
<br />
The last block that will generate coins will be block #6,929,999 which should be generated at or near the year 2140. The total number of coins in circulation will then remain static at 20,999,999.9769 BTC.<br />
<br />
Even if the allowed precision is expanded from the current 8 decimals, the total BTC in circulation will always be slightly below 21 million (assuming everything else stays the same). For example, with 16 decimals of precision, the end total would be 20,999,999.999999999496 BTC.<br />
<br />
=== If no more coins are going to be generated, will more blocks be created? ===<br />
<br />
Absolutely! Even before the creation of coins ends, the use of [[transaction fee|transaction fees]] will likely make creating new blocks more valuable from the fees than the new coins being created. When coin generation ends, these fees will sustain the ability to use bitcoins and the Bitcoin network. There is no practical limit on the number of blocks that will be mined in the future.<br />
<br />
=== But if no more coins are generated, what happens when Bitcoins are lost? Won't that be a problem? ===<br />
<br />
Because of the law of supply and demand, when fewer bitcoins are available the ones that are left will be in higher demand, and therefore will have a higher value. So, as Bitcoins are lost, the remaining bitcoins will eventually increase in value to compensate. As the value of a bitcoin increases, the number of bitcoins required to purchase an item '''de'''creases. This is a [[Deflationary spiral|deflationary economic model]]. As the average transaction size reduces, transactions will probably be denominated in sub-units of a bitcoin such as millibitcoins ("Millies") or microbitcoins ("Mikes").<br />
<br />
The Bitcoin protocol uses a base unit of one hundred-millionth of a Bitcoin ("a Satoshi"), but unused bits are available in the protocol fields that could be used to denote even smaller subdivisions.<br />
<br />
=== If every transaction is broadcast via the network, does Bitcoin scale? ===<br />
<br />
The blockchain base layer is not very scalable but layer-2 technologies can be used to greatly increase bitcoin's scale. [[Lightning Network]] is one example which uses [[Contracts|smart contracts]] to build a network where payments are routed along a path instead of flooded to every peer. These payments can be nearly as secure and irreversible as blockchain transactions but have much better scalability (as well support instant payments which are much more private). Other possible layer-2 scalability technologies are sidechains or a bitcoin ecash chaumian bank.<br />
<br />
See also:<br />
* [https://www.reddit.com/r/Bitcoin/comments/438hx0/a_trip_to_the_moon_requires_a_rocket_with/ A trip to the moon requires a rocket with multiple stages]<br />
* [https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-December/011865.html Capacity increases for the Bitcoin system]<br />
* [[Scalability]].<br />
<br />
==Economy==<br />
=== Where does the value of Bitcoin stem from? What backs up Bitcoin? ===<br />
Bitcoins have value because they are useful and because they are [[Controlled Currency Supply|scarce]]. As they are accepted by more merchants, their value will [http://en.wikipedia.org/wiki/Sticky_%28economics%29 stabilize]. See the [[Trade|list of Bitcoin-accepting sites]].<br />
<br />
When we say that a currency is backed up by gold, we mean that there's a promise in place that you can exchange the currency for gold. Bitcoins, like dollars and euros, are not backed up by anything except the variety of merchants that accept them.<br />
<br />
It's a common misconception that Bitcoins gain their value from the cost of electricity required to generate them. Cost doesn't equal value – hiring 1,000 men to shovel a big hole in the ground may be costly, but not valuable. Also, even though scarcity is a critical requirement for a useful currency, it alone doesn't make anything valuable. For example, your fingerprints are scarce, but that doesn't mean they have any exchange value.<br />
<br />
Alternatively it needs to be added that while the law of supply and demand applies it does not guarantee value of Bitcoins in the future. If confidence in Bitcoins is lost then it will not matter that the supply can no longer be increased, the demand will fall off with all holders trying to get rid of their coins. An example of this can be seen in cases of state currencies, in cases when the state in question dissolves and so no new supply of the currency is available (the central authority managing the supply is gone), however the demand for the currency falls sharply because confidence in its purchasing power disappears. Of-course Bitcoins do not have such central authority managing the supply of the coins, but it does not prevent confidence from eroding due to other situations that are not necessarily predictable.<br />
<br />
=== Is Bitcoin a bubble? ===<br />
Yes, in the same way as the euro and dollar are. They only have value in exchange and have no inherent value. If everyone suddenly stopped accepting your dollars, euros or bitcoins, the "bubble" would burst and their value would drop to zero. But that is unlikely to happen: even in Somalia, where the government collapsed 20 years ago, [http://en.wikipedia.org/wiki/Somali_shilling Somali shillings] are still accepted as payment.<br />
<br />
=== Is Bitcoin a Ponzi scheme? ===<br />
In a Ponzi Scheme, the founders persuade investors that they’ll profit. Bitcoin does not make such a guarantee. There is no central entity, just individuals building an economy.<br />
<br />
A ponzi scheme is a zero sum game. Early adopters can only profit at the expense of late adopters. Bitcoin has possible win-win outcomes. Early adopters profit from the rise in value. Late adopters, and indeed, society as a whole, benefit from the usefulness of a stable, fast, inexpensive, and widely accepted p2p currency.<br />
<br />
The fact that early adopters benefit more doesn't alone make anything a Ponzi scheme. All good investments in successful companies have this quality.<br />
<br />
=== Doesn't Bitcoin unfairly benefit early adopters? ===<br />
Early adopters in Bitcoin are taking a risk and invested resources in an unproven technology. By so doing, they help Bitcoin become what it is now and what it will be in the future (hopefully, a ubiquitous decentralized digital currency). It is only fair they will reap the benefits of their successful investment.<br />
<br />
In any case, any bitcoin generated will probably change hands dozens of time as a medium of exchange, so the profit made from the initial distribution will be insignificant compared to the total commerce enabled by Bitcoin. Many of the earliest users of Bitcoin have traded their coins at valuations below $1 US, or other amounts which are small compared to contemporary prices.<br />
<br />
===Won't loss of wallets and the finite amount of Bitcoins create excessive deflation, destroying Bitcoin? ===<br />
Worries about Bitcoin being destroyed by deflation are not entirely unfounded. Unlike most currencies, which experience inflation as their founding institutions create more and more units, Bitcoin will likely experience gradual deflation with the passage of time. Bitcoin is unique in that only a small amount of units will ever be produced (twenty-one million to be exact), this number has been known since the project's inception, and the units are created at a predictable rate.<br />
<br />
Also, Bitcoin users are faced with a danger that doesn't threaten users of any other currency: if a Bitcoin user loses his wallet, his money is gone forever, unless he finds it again. And not just to him; it's gone completely out of circulation, rendered utterly inaccessible to anyone. As people will lose their wallets, the total number of Bitcoins will slowly decrease.<br />
<br />
Therefore, Bitcoin seems to be faced with a unique problem. Whereas most currencies inflate over time, Bitcoin will mostly likely do just the opposite. Time will see the irretrievable loss of an ever-increasing number of Bitcoins. An already small number will be permanently whittled down further and further. And as there become fewer and fewer Bitcoins, the laws of supply and demand suggest that their value will probably continually rise.<br />
<br />
Thus Bitcoin is bound to once again stray into mysterious territory, because no one exactly knows what happens to a currency that grows continually more valuable. Many economists claim that a low level of inflation is a good thing for a currency, but nobody is quite sure about what might happens to one that continually deflates. Although deflation could hardly be called a rare phenomenon, steady, constant deflation is unheard of. There may be a lot of speculation, but no one has any hard data to back up their claims.<br />
<br />
That being said, there is a mechanism in place to combat the obvious consequences. Extreme deflation would render most currencies highly impractical: if a single Canadian dollar could suddenly buy the holder a car, how would one go about buying bread or candy? Even pennies would fetch more than a person could carry. Bitcoin, however, offers a simple and stylish solution: infinite divisibility. Bitcoins can be divided up and trade into as small of pieces as one wants, so no matter how valuable Bitcoins become, one can trade them in practical quantities. <br />
<br />
In fact, infinite divisibility should allow Bitcoins to function in cases of extreme wallet loss. Even if, in the far future, so many people have lost their wallets that only a single Bitcoin, or a fraction of one, remains, Bitcoin should continue to function just fine. No one can claim to be sure what is going to happen, but deflation may prove to present a smaller threat than many expect.<br />
<br />
For more information, see the [[Deflationary spiral]] page.<br />
<br />
=== What if someone bought up all the existing Bitcoins? ===<br />
Bitcoin markets are competitive -- meaning the price of a bitcoin will rise or fall depending on supply and demand at certain price levels. Only a fraction of bitcoins issued to date are found on the exchange markets for sale. So even though technically, a buyer with lots of money could buy all the bitcoins offered for sale, unless those holding the rest of the bitcoins offer them for sale as well, even the wealthiest, most determined buyer can't get at them.<br />
<br />
Additionally, new currency continues to be issued daily and will continue to do so for decades; though over time the rate at which they are issued declines to insignificant levels. Those who are mining aren't obligated to sell their bitcoins so not all bitcoins will make it to the markets even.<br />
<br />
This situation doesn't suggest, however, that the markets aren't vulnerable to price manipulation. It doesn't take significant amounts of money to move the market price up or down, and thus Bitcoin remains a volatile asset.<br />
<br />
===What if someone creates a new block chain, or a new digital currency that renders Bitcoin obsolete?===<br />
<br />
That the block chain cannot be easily forked represents one of the central security mechanisms of Bitcoin. Given the choice between two block chains, a Bitcoin miner always chooses the longer one - that is to say, the one with the more complex hash. Thusly, it ensures that each user can only spend their bitcoins once, and that no user gets ripped off.<br />
<br />
As a consequence of the block chain structure, there may at any time be many different sub-branches, and the possibility always exists of a transaction being over-written by the longest branch, if it has been recorded in a shorter one. The older a transaction is though, the lower its chances of being over-written, and the higher of becoming permanent. Although the block chain prevents one from spending more Bitcoins than one has, it means that transactions can be accidentally nullified. <br />
<br />
A new block chain would leave the network vulnerable to [[double-spending|double-spend]] attacks. However, the creation of a viable new chain presents considerable difficulty, and the possibility does not present much of a risk.<br />
<br />
Bitcoin will always choose the longer Block Chain and determines the relative length of two branches by the complexities of their hashes. Since the hash of each new block is made from that of the block preceding it, to create a block with a more complex hash, one must be prepared to do more computation than has been done by the entire Bitcoin network from the fork point up to the newest of the blocks one is trying to supersede. Needless to say, such an undertaking would require a very large amount of processing power and since Bitcoin is continually growing and expanding, it will likely only require more with the passage of time.<br />
<br />
A much more distinct and real threat to the Bitcoin use is the development of other, superior virtual currencies, which could supplant Bitcoin and render it obsolete and valueless.<br />
<br />
A great deal of careful thought and ingenuity has gone into the development of Bitcoin, but it is the first of its breed, a prototype, and vulnerable to more highly-evolved competitors. At present, any threatening rivals have yet to rear their heads; Bitcoin remains the first and foremost private virtual currency, but we can offer no guarantees that it will retain that position. It would certainly be in keeping with internet history for a similar system built from the same principles to supersede and cast Bitcoin into obsolescence, after time had revealed its major shortcomings. Friendster and Myspace suffered similar fates at the hand of Facebook, Napster was ousted by Limeware, Bearshare and torrent applications, and Skype has all but crushed the last few disciples of the Microsoft Messenger army. <br />
<br />
This may sound rather foreboding, so bear in mind that the introduction of new and possibly better virtual currencies will not necessarily herald Bitcoin's demise. If Bitcoin establishes itself sufficiently firmly before the inception of the next generation of private, online currencies so as to gain widespread acceptance and general stability, future currencies may pose little threat even if they can claim superior design. This is known as the network effect.<br />
<br />
=== Is Bitcoin open to value manipulation? ===<br />
<br />
The current low market cap of Bitcoin means that any investor with deep enough pockets can significantly change/manipulate the rate. Is this a problem?<br />
<br />
This is only a problem if you are investing in Bitcoin for short period of time. A manipulator can't change the fundamentals, and over a period of 5-10 years, the fundamentals will win over any short term manipulations.<br />
<br />
==Sending and Receiving Payments==<br />
<br />
=== Why do I have to wait 10 minutes before I can spend money I received? ===<br />
<br />
10 minutes is the average time taken to find a block. It can be significantly more or less time than that depending on luck; 10 minutes is simply the average case. <br />
<br />
[[Blocks]] (shown as "[[Confirmation|confirmations]]" in the GUI) are how the Bitcoin achieves consensus on who owns what. Once a block is found everyone agrees that you now own those coins, so you can spend them again. Until then it's possible that some network nodes believe otherwise, if somebody is attempting to defraud the system by reversing a transaction. The more confirmations a transaction has, the less risk there is of a reversal. Only 6 blocks or 1 hour is enough to make reversal computationally impractical. This is dramatically better than credit cards which can see chargebacks occur up to three months after the original transaction!<br />
<br />
Ten minutes was specifically chosen by [[Satoshi]] as a tradeoff between first confirmation time and the amount of work wasted due to chain splits. After a block is mined, it takes time for other miners to find out about it, and until then they are actually competing against the new block instead of adding to it. If someone mines another new block based on the old block chain, the network can only accept one of the two, and all the work that went into the other block gets wasted. For example, if it takes miners 1 minute on average to learn about new blocks, and new blocks come every 10 minutes, then the overall network is wasting about 10% of its work. Lengthening the time between blocks reduces this waste.<br />
<br />
As a thought experiment, what if the Bitcoin network grew to include Mars? From the farthest points in their orbits, it takes about 20 minutes for a signal to travel from Earth to Mars. With only 10 minutes between new blocks, miners on Mars would always be 2 blocks behind the miners on Earth. It would be almost impossible for them to contribute to the block chain. If we wanted collaborate with those kinds of delays, we would need at least a few hours between new blocks. <br />
<br />
[[File:TransactionConfirmationTimesExample.PNG]]<br />
<br />
=== Do you have to wait until my transactions are confirmed in order to buy or sell things with Bitcoin? ===<br />
<br />
YES, you do, IF the transaction is non-recourse. The Bitcoin reference software does not display transactions as confirmed until six blocks have passed (confirmations). As transactions are buried in the chain they become increasingly non-reversible but are very reversible before the first confirmation. Two to six confirmations are recommended for non-recourse situations depending on the value of the transactions involved.<br />
<br />
When people ask this question they are usually thinking about applications like supermarkets. This generally is a recourse situation: if somebody tries to double-spend on a face-to-face transaction it might work a few times, but probabalistically speaking eventually one of the double-spends will get noticed, and the penalty for shoplifting charges in most localities is calibrated to be several times worse than the proceeds of a single shoplifting event.<br />
<br />
Double-spends might be a concern for something like a snack machine in a low-traffic area with no nearby security cameras. Such a machine shouldn't honor zero-confirmation payments, and should instead use some other mechanism of clearing Bitcoin or validating transactions against reversal, see the wiki article [[Myths#Point_of_sale_with_bitcoins_isn.27t_possible_because_of_the_10_minute_wait_for_confirmation|here]] for alternatives.<br />
<br />
Applications that require immediate payment processing, like supermarkets or snack machines, need to manage the risks. Here is one way to reverse an unconfirmed payment:<br />
<br />
A [[Double-spending#Finney_attack|Finney attack]] is where an attacker mines a block containing a movement of some coins back to themselves. Once they find a block solution, they quickly go to a merchant and make a purchase, then broadcast the block, thus taking back the coins. This attack is a risk primarily for goods that are dispatched immediately, like song downloads or currency trades. Because the attacker can't choose the time of the attack, it isn't a risk for merchants such as supermarkets where you can't choose exactly when to pay (due to queues, etc). The attack can fail if somebody else finds a block containing the purchasing transaction before you release your own block, therefore, merchants can reduce but not eliminate the risk by making purchasers wait some length of time that's less than a confirm.<br />
<br />
Because pulling off this attack is not trivial, merchants who need to sell things automatically and instantly are most likely to adjust the price to include the cost of reversal fraud, or elect to use special insurance.<br />
<br />
=== I was sent some bitcoins and they haven't arrived yet! Where are they? ===<br />
<br />
Don't panic! There are a number of reasons why your bitcoins might not show up yet, and a number of ways to diagnose them. <br />
<br />
The latest version of the Bitcoin-Qt client tells you how far it has yet to go in downloading the blockchain. Hover over the icon in the bottom right corner of the client to learn your client's status.<br />
<br />
If it has not caught up then it's possible that your transaction hasn't been included in a block yet. <br />
<br />
You can check pending transactions in the network by going [https://www.biteasy.com here] or [http://blockchain.info here] and then searching for your address. If the transaction is listed here then it's a matter of waiting until it gets included in a block before it will show in your client. <br />
<br />
If the transaction is based on a coin that was in a recent transaction then it could be considered a low priority transaction. Transfers can take longer if the transaction fee paid was not high enough. If there is no fee at all the transfer can get a very low priority and take hours or even days to be included in a block.<br />
<br />
<br />
=== I sent too small of a transaction fee, is my bitcoin lost forever? ===<br />
<br />
<br />
If the transaction never gets confirmed into a block - the mempool expiry of all nodes will drop it eventually and you will be able to spend your funds again - [https://hackernoon.com/holy-cow-i-sent-a-bitcoin-transaction-with-too-low-fees-are-my-coins-lost-forever-7a865e2e45ba typically] it takes about 3 days or so for this to happen. If using an [[https://en.bitcoin.it/w/index.php?title=Scalability#Simplified_payment_verification SPV]] wallet such as [[ Electrum]] or [[Multibit]], if after three days the wallet does not see the coin to spend, you need to reindex your wallet's block headers. After reindexing, your wallet will see that the coin was never confirmed and thus the balance will be spendable again. <br />
<br />
'''NOTE''': From Bitcoin 0.14 “transaction reappearance” happens after 2 [https://www.reddit.com/r/Bitcoin/comments/69jywp/a_practical_guide_to_accidental_low_fee/dhjfthf/ weeks].<br />
<br />
=== Why does my Bitcoin address keep changing? ===<br />
{{seealso|Address reuse}}<br />
Unlike postal and email addresses, Bitcoin addresses are designed to be used exactly once only, for a single transaction.<br />
Originally, wallets would display only a single address at a time, and change it when a transaction was received, but an increasing number of wallet implementations now generate an address when you explicitly want to receive a payment.<br />
<br />
While it is technically possible to use an address for an arbitrary number of payments, this works by accident and harms both yourself ''and other unrelated third parties'', so it is considered a bad practice.<br />
The most important concerns with such misuse involve loss of privacy and security:<br />
both can be put into jeopardy when addresses are used for more than a single transaction only.<br />
<br />
===How much will the transaction fee be? / Why is the fee so high?===<br />
<br />
Bitcoin transactions almost always require a [[transaction fee]] for them to get confirmed. The transaction fee is received by the first bitcoin miner who mines a [[block]] containing the transaction; this action is also what gives the transaction its first confirmation. The appropriate fee varies depending on how large (in bytes) your transaction is, how fast you want the transaction to be confirmed, and also on current network conditions. As such, paying a fixed fee, or even a fixed fee per kB, is a very bad idea; all good Bitcoin wallets will use several pieces of data to estimate an appropriate fee for you, though some are better at fee estimation than others.<br />
<br />
The fee most strongly depends on the transaction's data size. Fees do '''not''' depend on the BTC amount of the transaction -- it's entirely possible for a 0.01 BTC transaction to require a higher fee than a 1000 BTC transaction.<br />
<br />
Basic intro to how Bitcoin [[transactions]] work: If you receive BTC in three separate transactions of (say) 1, 5, and 10 BTC, then you can think of your wallet as containing three gold coins with sizes 1, 5, and 10 BTC. If you then want to send 6 BTC, you can melt the 1 & 5 BTC coins together and recast them as a 6 BTC coin, or melt the 10 BTC coin and recast a 6 BTC coin for the recipient and a 4 BTC coin as change for yourself. In Bitcoin's technical vocabulary, these objects are literally called input and output coins. (In the rest of this section, when we say "coin" we mean these objects, not the amount of BTC value.)<br />
<br />
Transaction data sizes, and therefore fees, are proportional to the '''number''' (not value) of input and output coins in a transaction. Input coins are about 5x larger / more expensive than output coins.<br />
<br />
If your wallet estimates a very high fee, it is most likely because your wallet is full of a whole bunch of tiny coins, so your transaction will need to take very many coins as inputs, increasing the cost. On the bright side, fees will go down once you make a few transactions, since you will end up "melting down" these many small coins into a few larger ones. Sometimes you can significantly reduce the fee by sending less BTC: if you have like 1000 tiny faucet payments totaling 0.5 BTC and then 16.5 BTC from other sources, then you'll find that sending ~16.5 BTC will be massively cheaper than sending a slightly higher value since it avoids including all of those faucet coins.<br />
<br />
Fees also fluctuate depending on network conditions. All unconfirmed transactions compete with each other to be picked up by miners. If there are a lot of high-fee transactions being sent right now, then you will need to pay higher fees to out-bid them. On the other hand, if speed is less important to you, you can pay a somewhat smaller fee, and your transaction will float around until there is a period of reduced network usage. Sometimes even transactions with zero fee will be confirmed after a very long period of time, though this requires a perfect set of conditions, beyond what is explained here (ie. it probably won't work if you try it).<br />
<br />
Oftentimes wallets will have an "express" fee configuration, but note that confirmation times are naturally random and unreliable. At any given point in time, the probability that ''no'' transactions will be confirmed in the next hour is about 0.25% (ie. it happens more than once per week on average). Bitcoin users should avoid getting into situations where their transactions ''absolutely must'' get 1 confirmation in the next couple of hours, even if high-fee transactions usually take less than 10 minutes to get 1 confirmation.<br />
<br />
=== What happens when someone sends me a bitcoin but my computer is powered off? ===<br />
<br />
Bitcoins are not actually "sent" to your wallet; the software only uses that term so that we can use the currency without having to learn new concepts. Your wallet is only needed when you wish to spend coins that you've received.<br />
<br />
If you are sent coins when your wallet client program is not running, and you later launch the wallet client program, the coins will eventually appear as if they were just received in the wallet. That is to say, when the client program is started it must download blocks and catch up with any transactions it did not already know about.<br />
<br />
=== How long does "synchronizing" take when the Bitcoin client is first installed? What's it doing? ===<br />
<br />
The popular Bitcoin client software from bitcoin.org implements a "full" Bitcoin node: It can carry out all the duties of the Bitcoin P2P system, it isn't simply a "client". One of the principles behind the operation of full Bitcoin nodes is that they don't assume that the other participants have followed the rules of the Bitcoin system. During synchronization, the software is processing historical Bitcoin transactions and making sure for itself that all of the rules of the system have been correctly followed.<br />
<br />
In normal operation, after synchronizing, the software should use a hardly noticeable amount of your computer's resources.<br />
<br />
When the wallet client program is first installed, its initial validation requires a lot of work from your computer's hard disk, so the amount of time to synchronize depends on your disk speed and, to a lesser extent, your CPU speed. It can take anywhere from a few hours to a day or so. On a slow computer it could take more than 40 hours of continuous synchronization, so check your computer's power-saving settings to ensure that it does not turn its hard disk off when unattended for a few hours. You can use the Bitcoin software during synchronization, but you may not see recent payments to you until the client program has caught up to the point where those transactions happened.<br />
<br />
If you feel that this process takes too long, you can download a pre-synchronized blockchain from [http://eu2.bitcoincharts.com/blockchain/ http://eu2.bitcoincharts.com/blockchain/]. Alternatively, you can try an alternative "lite" client such as Multibit or a super-light client like electrum, though these clients have somewhat weaker security, are less mature, and don't contribute to the health of the P2P network.<br />
<br />
==Networking==<br />
=== Do I need to configure my firewall to run Bitcoin? ===<br />
<br />
Bitcoin will connect to other nodes, usually on TCP port 8333. You will need to allow outgoing TCP connections to port 8333 if you want to allow your Bitcoin client to connect to many nodes. [[Testnet]] uses TCP port 18333 instead of 8333.<br />
<br />
If you want to restrict your firewall rules to a few IPs, you can find stable nodes in the [[Fallback Nodes|fallback nodes list]].<br />
<br />
=== How does the peer finding mechanism work? ===<br />
<br />
Bitcoin finds peers primarily by forwarding peer announcements within its own network and each node saves a database of peers that it's aware of, for future use. In order to bootstrap this process Bitcoin needs a list of initial peers, these can be provided manually but normally it obtains them by querying a set of DNS domain names which have automatically updated lists, if that doesn't work it falls back to a built-in list which is updated from time to time in new versions of the software. In the reference software initial peers can also be specified manually by adding an addr.txt to the data directory or via the addnode parameter.<br />
<br />
==Mining==<br />
===What is mining?===<br />
[[Mining]] is the process of spending computation power to secure Bitcoin transactions against reversal and introducing new Bitcoins to the system<ref>[https://www.bitcoinmining.com Bitcoin Mining]</ref>.<br />
<br />
Technically speaking, mining is the calculation of a [[hash]] of the a block header, which includes among other things a reference to the previous block, a hash of a set of transactions and a [[nonce]]. If the hash value is found to be less than the current [[target]] (which is inversely proportional to the [[difficulty]]), a new block is formed and the miner gets the newly generated Bitcoins (25 per block at current levels). If the hash is not less than the current target, a new nonce is tried, and a new hash is calculated. This is done millions of times per second by each miner.<br />
<br />
===Is mining used for some useful computation?===<br />
The computations done when mining are internal to Bitcoin and not related to any other distributed computing projects. They serve the purpose of securing the Bitcoin network, which is useful.<br />
<br />
===Is it not a waste of energy?===<br />
Spending energy on creating and securing a free monetary system is hardly a waste. Also, services necessary for the operation of currently widespread monetary systems, such as banks and credit card companies, also spend energy, arguably more than Bitcoin would.<br />
<br />
===Why don't we use calculations that are also useful for some other purpose?===<br />
To provide security for the Bitcoin network, the calculations involved need to have some [http://bitcoin.stackexchange.com/questions/5617/why-are-bitcoin-calculation-useless/5618#5618 very specific features]. These features are incompatible with leveraging the computation for other purposes.<br />
<br />
===How can we stop miners from creating zero transaction blocks?===<br />
The incentive for miners to include transactions is in the fees that come along with them. If we were to implement some minimum number of transactions per block it would be trivial for a miner to create and include transactions merely to surpass that threshold. As the network matures, the block reward drops, and miners become more dependent on transactions fees to pay their costs, the problem of zero transaction blocks should diminish over time.<br />
<br />
===How does the proof-of-work system help secure Bitcoin?===<br />
Bitcoin uses the [[Hashcash]] [[proof of work]] with a minor adaption. To give a general idea of the mining process, imagine this setup:<br />
<br />
payload = <some data related to things happening on the Bitcoin network><br />
nonce = 1<br />
hash = [http://en.wikipedia.org/wiki/SHA2 SHA2]( [http://en.wikipedia.org/wiki/SHA2 SHA2]( payload + nonce ) )<br />
<br />
The work performed by a miner consists of repeatedly increasing "nonce" until<br />
the hash function yields a value, that has the rare property of being below a certain<br />
target threshold. (In other words: The hash "starts with a certain number of zeroes",<br />
if you display it in the fixed-length representation, that is typically used.)<br />
<br />
As can be seen, the mining process doesn't compute anything special. It merely<br />
tries to find a number (also referred to as nonce) which - in combination with the payload -<br />
results in a hash with special properties.<br />
<br />
The advantage of using such a mechanism consists of the fact, that it is very easy to check a result: Given the payload and a specific nonce, only a single call of the hashing function is needed to verify that the hash has the required properties. Since there is no known way to find these hashes other than brute force, this can be used as a "[[proof of work]]" that someone invested a lot of computing power to find the correct nonce for this payload.<br />
<br />
This feature is then used in the Bitcoin network to allow the network to come to a consensus on the history of transactions. An attacker that wants to rewrite history will need to do the required proof of work before it will be accepted. And as long as honest miners have more computing power, they can always outpace an attacker.<br />
<br />
Also see [http://en.wikipedia.org/wiki/Hashcash Hashcash] and [http://en.wikipedia.org/wiki/Proof-of-work_system Proof-of-work system] and [http://en.wikipedia.org/wiki/SHA2 SHA2] and on Wikipedia.<br />
<br />
===Why was the "Generate coin" option of the client software removed?===<br />
<br />
The option wasn't removed, but it is now only accessible via the command-line or the configuration file. The reason for this is that many users were complaining after they turned on and expecting to receive coins. Without specialized mining hardware a user is exceptionally unlikely generate a block on their own at the network's current [[difficulty|security level]].<br />
<br />
==Security==<br />
<br />
===Could miners collude to give themselves money or to fundamentally change the nature of Bitcoin?===<br />
<br />
There are two questions in here. Let's look at them separately.<br />
<br />
;Could miners gang up and give themselves money?<br />
<br />
Mining itself is the process of creating new blocks in the block chain. Each block contains a list of all the transactions that have taken place across the entire Bitcoin network since the last block was created, as well as a hash of the previous block. New blocks are 'mined', or rather, generated, by Bitcoin clients correctly guessing sequences of characters in codes called 'hashes,' which are created using information from previous blocks. Bitcoin users may download specialized 'mining' software, which allows them to dedicate some amount of their processing power – however large or small – to guessing at strings within the hash of the previous block. Whoever makes the right guess first, thus creating a new block, receives a reward in Bitcoins.<br />
<br />
The block chain is one of the two structures that makes Bitcoin secure, the other being the public-key encryption system on which Bitcoin trade is based. The block chain assures that not only is every single transaction that ever takes place recorded, but that every single transaction is recorded on the computer of anyone who chooses to store the relevant information. Many, many users have complete records of every transaction in Bitcoins history readily available to them at any point, and anyone who wants in the information can obtain it with ease. These things make Bitcoin very hard to fool.<br />
<br />
The Bitcoin network takes considerable processing power to run, and since those with the most processing power can make the most guesses, those who put the most power toward to sustaining the network earn the most currency. Each correct guess yields, at present, twenty-five Bitcoins, and as Bitcoins are presently worth something (although the value still fluctuates) every miner who earns any number of Bitcoins makes money. Some miners pull in Bitcoins on their own; and some also join or form pools wherein all who contribute earn a share of the profits. <br />
<br />
Therefore, first answer is a vehement “yes” – not only can miners collude to get more money, Bitcoin is designed to encourage them to do so. Bitcoin pools are communal affairs, and there is nothing dishonest or underhanded about them.<br />
<br />
Of course, the real question is:<br />
<br />
;Can they do so in ways not sanctioned by Bitcoin network? Is there any way to rip off the network and make loads of money dishonestly?<br />
<br />
Bitcoin isn't infallible. It can be cheated, but doing so is extremely difficult. Bitcoin was designed to evade some of the central problems with modern currencies – namely, that their trustworthiness hinges upon that of people who might not have users' best interests in mind. Every currency in the world (other than Bitcoin) is controlled by large institutions who keep track of what's done with it, and who can manipulate its value. And every other currency has value because people trust the institutions that control them.<br />
<br />
Bitcoin doesn't ask that its users trust any institution. Its security is based on the cryptography that is an integral part of its structure, and that is readily available for any and all to see. Instead of one entity keeping track of transactions, the entire network does, so Bitcoins are astoundingly difficult to steal, or double-spend. Bitcoins are created in a regular and predictable fashion, and by many different users, so no one can decide to make a whole lot more and lessen their value. In short, Bitcoin is designed to be inflation-proof, double-spend-proof and completely distributed.<br />
<br />
Nonetheless, there are a few ways that one can acquire Bitcoins dishonestly. Firstly, one can steal private keys. Key theft isn't something that Bitcoin security has been designed to prevent: it's up to users to keep their keys safe. But the cryptography is designed so that it is completely impossible to deduce someone's private key from their public one. As long as you keep your private key to yourself, you don't have much to worry about. Furthermore, one could theoretically create a new block chain, but due to the way in which the block chain is constructed, this would be extremely difficult and require massive amounts of processing power. A full explanation of the difficulties involved can be found in the [[block chain]] article.<br />
<br />
Bitcoin can be ripped off – but doing so would be extremely hard and require considerable expertise and a staggering amount of processing power. And it's only going to get harder with time. Bitcoin isn't impenetrable, but it's close enough to put any real worries in the peripherals.<br />
<br />
;Could miners fundamentally change the nature of Bitcoin?<br />
<br />
Once again, almost certainly not.<br />
<br />
Bitcoin is a distributed network, so any changes implemented to the system must be accepted by all users. Someone trying to change the way Bitcoins are generated would have to convince every user to download and use their software – so the only changes that would go through are those that would be equally benefit all users. <br />
<br />
And thus, it is more or less impossible for anyone to change the function of Bitcoin to their advantage. If users don't like the changes, they won't adopt them, whereas if users do like them, then these will help everyone equally. Of course, one can conceive of a situation where someone manages to get a change pushed through that provides them with an advantage that no one notices, but given that Bitcoin is structurally relatively simple, it is unlikely that any major changes will go through without someone noticing first.<br />
<br />
The fact that such changes are so difficult to make testifies to the fully distributed nature of Bitcoin. Any centrally controlled currency can be modified by its central agency without the consent of its adherents. Bitcoin has no central authority, so it changes only at the behest of the whole community. Bitcoins development represents a kind of collective evolution; the first of its kind among currencies.<br />
<br />
==Help==<br />
===I'd like to learn more. Where can I get help?===<br />
<br />
* Read the [[Introduction|introduction to bitcoin]] <br />
* See the videos, podcasts, and blog posts from the [[Press]]<br />
* Read and post on the [[:Bitcoin Wiki:Community_portal#Bitcoin_Community_Forums|forums]]<br />
* Chat on one of the [[:Bitcoin Wiki:Community_portal#IRC_Chat|Bitcoin IRC]] channels<br />
* Listen to [http://omegataupodcast.net/2011/03/59-bitcoin-a-digital-decentralized-currency/ this podcast], which goes into the details of how bitcoin works<br />
* Ask questions on the [http://bitcoin.stackexchange.com Bitcoin Stack Exchange]<br />
* Use [http://bitcoinx.io BitcoinX.io] to help beginners learn about reputable Bitcoin exchanges and Bitcoin wallets<br />
<br />
==See Also==<br />
<br />
* [[Man page]]<br />
* [[Introduction]]<br />
* [[Prohibited changes]]<br />
<br />
==References==<br />
<references><br />
<references/><br />
{{Reflist|2}}<br />
<br />
[[de:FAQ]]<br />
[[zh-cn:FAQ]]<br />
[[fr:FAQ]]<br />
[[ru:FAQ]]<br />
<br />
[[Category:Technical]]<br />
[[Category:Vocabulary]]</div>Hardinghttps://en.bitcoin.it/w/index.php?title=Help:FAQ&diff=65509Help:FAQ2018-06-25T21:49:07Z<p>Harding: Undo revision 65503 by RunCPA (talk)</p>
<hr />
<div>Here you will find answers to the most commonly asked questions.<br />
<br />
== General ==<br />
=== What is Bitcoin? ===<br />
Bitcoin is a distributed peer-to-peer digital currency that can be transferred instantly and securely between any two people in the world. It's like electronic cash that you can use to pay friends or merchants.<br />
<br />
=== What are bitcoins? ===<br />
Bitcoins are the unit of currency of the Bitcoin system. A commonly used shorthand for this is “BTC” to refer to a price or amount (e.g. “100 BTC”).<br />
There are such things as [[physical bitcoins]], but ultimately, a bitcoin is just a number associated with a [[Address|Bitcoin Address]]. A physical bitcoin is simply an object, such as a coin, with the number carefully embedded inside. See also an [[Introduction|easy intro]] to Bitcoin.<br />
<br />
=== How can I get bitcoins? ===<br />
<br />
There are a variety of ways to acquire bitcoins:<br />
* Accept bitcoins as payment for goods or services.<br />
* You can buy bitcoins from [https://www.bitit.gift/ Bitit] [https://www.coinbase.com/buy-bitcoin Coinbase], [https://paybis.com/ PayBis], [http://cubits.com/ Cubits], [https://www.coincorner.com CoinCorner], [[File:BIPS.gif|20px|link=https://bipsmarket.com]] [https://bipsmarket.com BIPS Market], [https://circle.com Circle], or [http://gocelery.com/ Celery].<br />
* The most common way to buy bitcoins are the [[Buying bitcoins|Bitcoin Exchanges]]<br />
* There are several services where you can [[Buying_Bitcoins_(the_noob_version)|trade them]] for traditional currency.<br />
* You can also buy bitcoins using [http://nationalbitcoinatm.com Bitcoin ATMs] that are locally in your area.<br />
* Find someone to trade cash for bitcoins in-person through a [https://en.bitcoin.it/wiki/Category:Directories local directory].<br />
* Participate in a [[Pooled mining|mining pool]].<br />
* If you have a lot of [https://cryptocomes.com/cryptocurrency-cloud-mining-vs-hardware-mining-which-is-more-profitable mining hardware], you can solo mine and attempt to create a new [[block]] (currently yields 12.5 bitcoins plus transaction fees).<br />
* Visit sites that provide [[Trade#Free_Samples_and_Offers|free samples and offers]].<br />
<br />
===Does Bitcoin guarantee an influx of free money?===<br />
<br />
Since Bitcoin is a new technology, what it is and how it works may be initially unclear. Bitcoin is sometimes presented as being one of three things:<br />
<ol style="list-style-type: upper-alpha;"><br />
<li>Some sort of online 'get-rich-quick' scam.</li><br />
<li>A loophole in the market economy, the installation of which guarantees a steady influx of cash.</li><br />
<li>A sure investment that will almost certainly yield a profit.</li><br />
</ol><br />
In fact, none of the above are true. Let's look at them independently.<br />
<br />
;Is Bitcoin a 'get-rich-quick' scheme?<br />
:If you've spent much time on the Internet, you've probably seen ads for many 'get-rich-quick' schemes. These ads usually promise huge profits for a small amounts of easy work. Such schemes are usually pyramid/matrix-style schemes that make money from their own employees and offer nothing of any real value. Most convince one to buy packages that will make them earn hundreds a day, which in fact have the buyer distribute more such ads, and make minute profits.<br />
<br />
:Bitcoin is in no way similar to these schemes. Bitcoin doesn't promise windfall profits. There is no way for the developers to make money from your involvement or to take money from you. That bitcoins are nearly impossible to acquire without the owner's consent represents one of its greatest strengths. Bitcoin is an experimental, virtual currency that may succeed or may fail. None of its developers expect to get rich off of it. <br />
<br />
:A more detailed answer to this question can be found [http://bitcointalk.org/?topic=7815.0 here].<br />
<br />
;Will I make money by installing the client?<br />
:Most people who use Bitcoin don't earn anything by doing so, and the default client has no built-in way to earn Bitcoins. A small minority of people with dedicated, high-performance hardware do earn some Bitcoins by "''mining''" (generating new bitcoins, see [[#What is mining?|What is mining?]]) with special software, but joining Bitcoin shouldn't be construed as being the road to riches. Most Bitcoin users get involved because they find the project conceptually interesting and don't earn anything by doing so. This is also why you won't find much speculation about the political or economic repercussions of Bitcoin anywhere on this site: Bitcoin developers owe their dedication to the project's intellectual yieldings more than to those of a monetary nature. Bitcoin is still taking its first baby steps; it may go on to do great things but right now it only has something to offer those chasing conceptually interesting projects or bleeding edge technology.<br />
<br />
;As an investment, is Bitcoin a sure thing?<br />
:Bitcoin is a new and interesting electronic currency, the value of which is not backed by any single government or organization. Like other currencies, it is worth something partly because people are willing to trade it for goods and services. Its exchange rate fluctuates continuously, and sometimes wildly. It lacks wide acceptance and is vulnerable to manipulation by parties with modest funding. Security incidents such as website and account compromise may trigger major sell-offs. Other fluctuations can build into positive feedback loops and cause much larger exchange rate fluctuations. Anyone who puts money into Bitcoin should understand the risk they are taking and consider it a high-risk currency. Later, as Bitcoin becomes better known and more widely accepted, it may stabilize, but for the time being it is unpredictable. Any investment in Bitcoin should be done carefully and with a clear plan to manage the risk.<br />
<br />
=== Can I buy bitcoins with Paypal? ===<br />
<br />
It is possible to buy [[physical bitcoins]] with PayPal but it is otherwise difficult and/or expensive to do so for non-physical bitcoins, because of significant risk to the seller. <br />
<br />
While it is possible to find an individual who wishes to sell Bitcoin to you via Paypal, (perhaps via [http://www.bitcoin-otc.com/ #bitcoin-otc] ) most exchanges do not allow funding through PayPal. This is due to repeated cases where someone pays for bitcoins with Paypal, receives their bitcoins, and then fraudulently complains to Paypal that they never received their purchase. PayPal often sides with the fraudulent buyer in this case, which means any seller needs to cover that risk with higher fees or refuse to accept PayPal altogether.<br />
<br />
Buying Bitcoins from individuals this way is still possible, but requires the seller to have some trust that the buyer will not file a claim with PayPal to reverse the payment.<br />
<br />
Also [https://bitbuy.in/ bitbuy.in] and [https://paybis.com/ PayBis], allows you to buy Bitcoins with PayPal.<br />
<br />
=== Where can I find a forum to discuss Bitcoin? ===<br />
<br />
Please visit the [[Bitcoin Wiki:Community_portal#Bitcoin_Community_Forums_on_various_platforms|Community Portal]] for links to Bitcoin-related forums.<br />
<br />
=== How are new bitcoins created? ===<br />
<br />
New bitcoins are generated by the network through the process of "[[#What is mining?|''mining'']]". In a process that is similar to a continuous raffle draw, mining nodes on the network are awarded bitcoins each time they find the solution to a certain mathematical problem (and thereby create a new [[block]]). Creating a block is a [[proof of work]] with a difficulty that varies with the overall strength of the network. The reward for solving a block is [[Controlled Currency Supply|automatically adjusted]] so that, ideally, every four years of operation of the Bitcoin network, half the amount of bitcoins created in the prior 4 years are created. A maximum of {{formatnum:10499889.80231183}} bitcoins were created in the first 4 (approx.) years from January 2009 to November 2012. Every four years thereafter this amount halves, so it should be {{formatnum:5250000}} over years 4-8, {{formatnum:2625000}} over years 8-12, and so on. Thus the total number of bitcoins in existence can never exceed {{formatnum:20999839.77085749}} and counting. See [[Controlled Currency Supply]].<br />
<br />
Blocks are [[Mining|mined]] every 10 minutes, on average and for the first four years ({{formatnum:210000}} blocks) each block included 50 new bitcoins. As the amount of processing power directed at mining changes, the difficulty of creating new bitcoins changes. This difficulty factor is calculated every 2016 blocks and is based upon the time taken to generate the previous 2016 blocks. See [[Mining]].<br />
<br />
=== What's the current total number of bitcoins in existence? ===<br />
<br />
[http://blockexplorer.com/q/totalbc Current count]. Also see [https://blockchain.info/charts/total-bitcoins Total bitcoins in circulation chart]<br />
<br />
The number of blocks times the coin value of a block is the number of coins in existence. The coin value of a block is 50 BTC for each of the first {{formatnum:210000}} blocks, 25 BTC for the next {{formatnum:210000}} blocks, then 12.5 BTC, 6.25 BTC and so on.<br />
<br />
=== How divisible are bitcoins? ===<br />
<br />
A bitcoin can be divided down to 8 decimal places. Therefore, 0.00000001 BTC is the smallest amount that can be handled in a transaction. If necessary, the protocol and related software can be modified to handle even smaller amounts.<br />
<br />
=== What do I call the various denominations of bitcoin? ===<br />
<br />
Unlike most currencies, Bitcoin amounts are highly divisible. This has led to a desire to create names for smaller denominations of bitcoin amounts, especially since transactions involving whole bitcoins are no longer quite so common. Bitcoin is decentralized, so there is no organization that can set official names for units. Therefore, there are many different units with varying degrees of popularity. As of 2014, the most common units are bitcoins, bits, and satoshi: 1 bitcoin = 1 000 000.00 bits = 100 000 000 satoshi.<br />
<br />
The '''bitcoin''' (abbreviated '''BTC''' or '''XBT''') is the unit that was used in the original Bitcoin wallet software created by [[Satoshi Nakamoto]]. There is nothing particularly special about this unit, but it is by far the most common unit due to tradition.<br />
<br />
The smallest value that the Bitcoin network supports sending is the '''[[satoshi (unit)|satoshi]]''' (sometimes abbreviated '''sat'''), one hundred-millionth (0.000 000 01) of a bitcoin. In other words, the network does not support sending fractions of a satoshi. Since it is a hard limit, it seems natural to use it as a unit, though it currently has very little value. The unit was named in honor of Bitcoin's creator after he left -- he was not so vain as to name a unit after himself. The plural of satoshi is satoshi: "Send me 100 satoshi".<br />
<br />
Another common unit is the '''[[bit (unit)|bit]]''', one millionth (0.000 001) of a bitcoin. This unit is the same as a microbitcoin (μBTC). Bits are seen by some as especially logical because they have two-decimal precision like most fiat currencies. You can send 1.23 bits, but not 1.234 bits due to the network's limited precision.<br />
<br />
It is also fairly common to use SI prefixes:<br />
<br />
* 0.01 BTC = 1 cBTC = 1 centibitcoin (also referred to as bitcent)<br />
* 0.001 BTC = 1 mBTC = 1 millibitcoin (also referred to as mbit (pronounced em-bit) or millibit or even bitmill)<br />
* 0.000 001 BTC = 1 μBTC = 1 microbitcoin (also referred to as ubit (pronounced yu-bit) or microbit)<br />
<br />
For an overview of all proposed units of Bitcoin (including less common and niche units), see [[Units]].<br />
<br />
Further discussion on this topic can be found on the forums here:<br />
<br />
* [https://bitcointalk.org/index.php?topic=14438.msg195287#msg195287 We need names]<br />
* [https://bitcointalk.org/index.php?topic=8282.0 What to call 0.001 BTC]<br />
<br />
=== How does the halving work when the number gets really small? ===<br />
<br />
Eventually the reward will go from 0.00000001 BTC to zero and no more bitcoins will be created. <br />
<br />
The block reward calculation is done as a right bitwise shift of a 64-bit signed integer, which means it is divided by two and rounded down. The integer is equal to the value in BTC * 100,000,000 since internally in the reference client software, all Bitcoin balances and values are stored as unsigned integers.<br />
<br />
With an initial block reward of 50 BTC, it will take many 4-year periods for the block reward to reach zero.<br />
<br />
=== How long will it take to generate all the coins? ===<br />
<br />
The last block that will generate coins will be block #6,929,999 which should be generated at or near the year 2140. The total number of coins in circulation will then remain static at 20,999,999.9769 BTC.<br />
<br />
Even if the allowed precision is expanded from the current 8 decimals, the total BTC in circulation will always be slightly below 21 million (assuming everything else stays the same). For example, with 16 decimals of precision, the end total would be 20,999,999.999999999496 BTC.<br />
<br />
=== If no more coins are going to be generated, will more blocks be created? ===<br />
<br />
Absolutely! Even before the creation of coins ends, the use of [[transaction fee|transaction fees]] will likely make creating new blocks more valuable from the fees than the new coins being created. When coin generation ends, these fees will sustain the ability to use bitcoins and the Bitcoin network. There is no practical limit on the number of blocks that will be mined in the future.<br />
<br />
=== But if no more coins are generated, what happens when Bitcoins are lost? Won't that be a problem? ===<br />
<br />
Because of the law of supply and demand, when fewer bitcoins are available the ones that are left will be in higher demand, and therefore will have a higher value. So, as Bitcoins are lost, the remaining bitcoins will eventually increase in value to compensate. As the value of a bitcoin increases, the number of bitcoins required to purchase an item '''de'''creases. This is a [[Deflationary spiral|deflationary economic model]]. As the average transaction size reduces, transactions will probably be denominated in sub-units of a bitcoin such as millibitcoins ("Millies") or microbitcoins ("Mikes").<br />
<br />
The Bitcoin protocol uses a base unit of one hundred-millionth of a Bitcoin ("a Satoshi"), but unused bits are available in the protocol fields that could be used to denote even smaller subdivisions.<br />
<br />
=== If every transaction is broadcast via the network, does Bitcoin scale? ===<br />
<br />
The blockchain base layer is not very scalable but layer-2 technologies can be used to greatly increase bitcoin's scale. [[Lightning Network]] is one example which uses [[Contracts|smart contracts]] to build a network where payments are routed along a path instead of flooded to every peer. These payments can be nearly as secure and irreversible as blockchain transactions but have much better scalability (as well support instant payments which are much more private). Other possible layer-2 scalability technologies are sidechains or a bitcoin ecash chaumian bank.<br />
<br />
See also:<br />
* [https://www.reddit.com/r/Bitcoin/comments/438hx0/a_trip_to_the_moon_requires_a_rocket_with/ A trip to the moon requires a rocket with multiple stages]<br />
* [https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-December/011865.html Capacity increases for the Bitcoin system]<br />
* [[Scalability]].<br />
<br />
==Economy==<br />
=== Where does the value of Bitcoin stem from? What backs up Bitcoin? ===<br />
Bitcoins have value because they are useful and because they are [[Controlled Currency Supply|scarce]]. As they are accepted by more merchants, their value will [http://en.wikipedia.org/wiki/Sticky_%28economics%29 stabilize]. See the [[Trade|list of Bitcoin-accepting sites]].<br />
<br />
When we say that a currency is backed up by gold, we mean that there's a promise in place that you can exchange the currency for gold. Bitcoins, like dollars and euros, are not backed up by anything except the variety of merchants that accept them.<br />
<br />
It's a common misconception that Bitcoins gain their value from the cost of electricity required to generate them. Cost doesn't equal value – hiring 1,000 men to shovel a big hole in the ground may be costly, but not valuable. Also, even though scarcity is a critical requirement for a useful currency, it alone doesn't make anything valuable. For example, your fingerprints are scarce, but that doesn't mean they have any exchange value.<br />
<br />
Alternatively it needs to be added that while the law of supply and demand applies it does not guarantee value of Bitcoins in the future. If confidence in Bitcoins is lost then it will not matter that the supply can no longer be increased, the demand will fall off with all holders trying to get rid of their coins. An example of this can be seen in cases of state currencies, in cases when the state in question dissolves and so no new supply of the currency is available (the central authority managing the supply is gone), however the demand for the currency falls sharply because confidence in its purchasing power disappears. Of-course Bitcoins do not have such central authority managing the supply of the coins, but it does not prevent confidence from eroding due to other situations that are not necessarily predictable.<br />
<br />
=== Is Bitcoin a bubble? ===<br />
Yes, in the same way as the euro and dollar are. They only have value in exchange and have no inherent value. If everyone suddenly stopped accepting your dollars, euros or bitcoins, the "bubble" would burst and their value would drop to zero. But that is unlikely to happen: even in Somalia, where the government collapsed 20 years ago, [http://en.wikipedia.org/wiki/Somali_shilling Somali shillings] are still accepted as payment.<br />
<br />
=== Is Bitcoin a Ponzi scheme? ===<br />
In a Ponzi Scheme, the founders persuade investors that they’ll profit. Bitcoin does not make such a guarantee. There is no central entity, just individuals building an economy.<br />
<br />
A ponzi scheme is a zero sum game. Early adopters can only profit at the expense of late adopters. Bitcoin has possible win-win outcomes. Early adopters profit from the rise in value. Late adopters, and indeed, society as a whole, benefit from the usefulness of a stable, fast, inexpensive, and widely accepted p2p currency.<br />
<br />
The fact that early adopters benefit more doesn't alone make anything a Ponzi scheme. All good investments in successful companies have this quality.<br />
<br />
=== Doesn't Bitcoin unfairly benefit early adopters? ===<br />
Early adopters in Bitcoin are taking a risk and invested resources in an unproven technology. By so doing, they help Bitcoin become what it is now and what it will be in the future (hopefully, a ubiquitous decentralized digital currency). It is only fair they will reap the benefits of their successful investment.<br />
<br />
In any case, any bitcoin generated will probably change hands dozens of time as a medium of exchange, so the profit made from the initial distribution will be insignificant compared to the total commerce enabled by Bitcoin. Many of the earliest users of Bitcoin have traded their coins at valuations below $1 US, or other amounts which are small compared to contemporary prices.<br />
<br />
===Won't loss of wallets and the finite amount of Bitcoins create excessive deflation, destroying Bitcoin? ===<br />
Worries about Bitcoin being destroyed by deflation are not entirely unfounded. Unlike most currencies, which experience inflation as their founding institutions create more and more units, Bitcoin will likely experience gradual deflation with the passage of time. Bitcoin is unique in that only a small amount of units will ever be produced (twenty-one million to be exact), this number has been known since the project's inception, and the units are created at a predictable rate.<br />
<br />
Also, Bitcoin users are faced with a danger that doesn't threaten users of any other currency: if a Bitcoin user loses his wallet, his money is gone forever, unless he finds it again. And not just to him; it's gone completely out of circulation, rendered utterly inaccessible to anyone. As people will lose their wallets, the total number of Bitcoins will slowly decrease.<br />
<br />
Therefore, Bitcoin seems to be faced with a unique problem. Whereas most currencies inflate over time, Bitcoin will mostly likely do just the opposite. Time will see the irretrievable loss of an ever-increasing number of Bitcoins. An already small number will be permanently whittled down further and further. And as there become fewer and fewer Bitcoins, the laws of supply and demand suggest that their value will probably continually rise.<br />
<br />
Thus Bitcoin is bound to once again stray into mysterious territory, because no one exactly knows what happens to a currency that grows continually more valuable. Many economists claim that a low level of [http://cryptodetail.com/how-does-cryptocurrency-market-prices-value-increase inflation] is a good thing for a currency, but nobody is quite sure about what might happens to one that continually deflates. Although deflation could hardly be called a rare phenomenon, steady, constant deflation is unheard of. There may be a lot of speculation, but no one has any hard data to back up their claims.<br />
<br />
That being said, there is a mechanism in place to combat the obvious consequences. Extreme deflation would render most currencies highly impractical: if a single Canadian dollar could suddenly buy the holder a car, how would one go about buying bread or candy? Even pennies would fetch more than a person could carry. Bitcoin, however, offers a simple and stylish solution: infinite divisibility. Bitcoins can be divided up and trade into as small of pieces as one wants, so no matter how valuable Bitcoins become, one can trade them in practical quantities. <br />
<br />
In fact, infinite divisibility should allow Bitcoins to function in cases of extreme wallet loss. Even if, in the far future, so many people have lost their wallets that only a single Bitcoin, or a fraction of one, remains, Bitcoin should continue to function just fine. No one can claim to be sure what is going to happen, but deflation may prove to present a smaller threat than many expect.<br />
<br />
For more information, see the [[Deflationary spiral]] page.<br />
<br />
=== What if someone bought up all the existing Bitcoins? ===<br />
Bitcoin markets are competitive -- meaning the price of a bitcoin will rise or fall depending on supply and demand at certain price levels. Only a fraction of bitcoins issued to date are found on the exchange markets for sale. So even though technically, a buyer with lots of money could buy all the bitcoins offered for sale, unless those holding the rest of the bitcoins offer them for sale as well, even the wealthiest, most determined buyer can't get at them.<br />
<br />
Additionally, new currency continues to be issued daily and will continue to do so for decades; though over time the rate at which they are issued declines to insignificant levels. Those who are mining aren't obligated to sell their bitcoins so not all bitcoins will make it to the markets even.<br />
<br />
This situation doesn't suggest, however, that the markets aren't vulnerable to price manipulation. It doesn't take significant amounts of money to move the market price up or down, and thus Bitcoin remains a volatile asset.<br />
<br />
===What if someone creates a new block chain, or a new digital currency that renders Bitcoin obsolete?===<br />
<br />
That the block chain cannot be easily forked represents one of the central security mechanisms of Bitcoin. Given the choice between two block chains, a Bitcoin miner always chooses the longer one - that is to say, the one with the more complex hash. Thusly, it ensures that each user can only spend their bitcoins once, and that no user gets ripped off.<br />
<br />
As a consequence of the block chain structure, there may at any time be many different sub-branches, and the possibility always exists of a transaction being over-written by the longest branch, if it has been recorded in a shorter one. The older a transaction is though, the lower its chances of being over-written, and the higher of becoming permanent. Although the block chain prevents one from spending more Bitcoins than one has, it means that transactions can be accidentally nullified. <br />
<br />
A new block chain would leave the network vulnerable to [[double-spending|double-spend]] attacks. However, the creation of a viable new chain presents considerable difficulty, and the possibility does not present much of a risk.<br />
<br />
Bitcoin will always choose the longer Block Chain and determines the relative length of two branches by the complexities of their hashes. Since the hash of each new block is made from that of the block preceding it, to create a block with a more complex hash, one must be prepared to do more computation than has been done by the entire Bitcoin network from the fork point up to the newest of the blocks one is trying to supersede. Needless to say, such an undertaking would require a very large amount of processing power and since Bitcoin is continually growing and expanding, it will likely only require more with the passage of time.<br />
<br />
A much more distinct and real threat to the Bitcoin use is the development of other, superior virtual currencies, which could supplant Bitcoin and render it obsolete and valueless.<br />
<br />
A great deal of careful thought and ingenuity has gone into the development of Bitcoin, but it is the first of its breed, a prototype, and vulnerable to more highly-evolved competitors. At present, any threatening rivals have yet to rear their heads; Bitcoin remains the first and foremost private virtual currency, but we can offer no guarantees that it will retain that position. It would certainly be in keeping with internet history for a similar system built from the same principles to supersede and cast Bitcoin into obsolescence, after time had revealed its major shortcomings. Friendster and Myspace suffered similar fates at the hand of Facebook, Napster was ousted by Limeware, Bearshare and torrent applications, and Skype has all but crushed the last few disciples of the Microsoft Messenger army. <br />
<br />
This may sound rather foreboding, so bear in mind that the introduction of new and possibly better virtual currencies will not necessarily herald Bitcoin's demise. If Bitcoin establishes itself sufficiently firmly before the inception of the next generation of private, online currencies so as to gain widespread acceptance and general stability, future currencies may pose little threat even if they can claim superior design. This is known as the network effect.<br />
<br />
=== Is Bitcoin open to value manipulation? ===<br />
<br />
The current low market cap of Bitcoin means that any investor with deep enough pockets can significantly change/manipulate the rate. Is this a problem?<br />
<br />
This is only a problem if you are investing in Bitcoin for short period of time. A manipulator can't change the fundamentals, and over a period of 5-10 years, the fundamentals will win over any short term manipulations.<br />
<br />
==Sending and Receiving Payments==<br />
<br />
=== Why do I have to wait 10 minutes before I can spend money I received? ===<br />
<br />
10 minutes is the average time taken to find a block. It can be significantly more or less time than that depending on luck; 10 minutes is simply the average case. <br />
<br />
[[Blocks]] (shown as "[[Confirmation|confirmations]]" in the GUI) are how the Bitcoin achieves consensus on who owns what. Once a block is found everyone agrees that you now own those coins, so you can spend them again. Until then it's possible that some network nodes believe otherwise, if somebody is attempting to defraud the system by reversing a transaction. The more confirmations a transaction has, the less risk there is of a reversal. Only 6 blocks or 1 hour is enough to make reversal computationally impractical. This is dramatically better than credit cards which can see chargebacks occur up to three months after the original transaction!<br />
<br />
Ten minutes was specifically chosen by [[Satoshi]] as a tradeoff between first confirmation time and the amount of work wasted due to chain splits. After a block is mined, it takes time for other miners to find out about it, and until then they are actually competing against the new block instead of adding to it. If someone mines another new block based on the old block chain, the network can only accept one of the two, and all the work that went into the other block gets wasted. For example, if it takes miners 1 minute on average to learn about new blocks, and new blocks come every 10 minutes, then the overall network is wasting about 10% of its work. Lengthening the time between blocks reduces this waste.<br />
<br />
As a thought experiment, what if the Bitcoin network grew to include Mars? From the farthest points in their orbits, it takes about 20 minutes for a signal to travel from Earth to Mars. With only 10 minutes between new blocks, miners on Mars would always be 2 blocks behind the miners on Earth. It would be almost impossible for them to contribute to the block chain. If we wanted collaborate with those kinds of delays, we would need at least a few hours between new blocks. <br />
<br />
[[File:TransactionConfirmationTimesExample.PNG]]<br />
<br />
=== Do you have to wait until my transactions are confirmed in order to buy or sell things with Bitcoin? ===<br />
<br />
YES, you do, IF the transaction is non-recourse. The Bitcoin reference software does not display transactions as confirmed until six blocks have passed (confirmations). As transactions are buried in the chain they become increasingly non-reversible but are very reversible before the first confirmation. Two to six confirmations are recommended for non-recourse situations depending on the value of the transactions involved.<br />
<br />
When people ask this question they are usually thinking about applications like supermarkets. This generally is a recourse situation: if somebody tries to double-spend on a face-to-face transaction it might work a few times, but probabalistically speaking eventually one of the double-spends will get noticed, and the penalty for shoplifting charges in most localities is calibrated to be several times worse than the proceeds of a single shoplifting event.<br />
<br />
Double-spends might be a concern for something like a snack machine in a low-traffic area with no nearby security cameras. Such a machine shouldn't honor zero-confirmation payments, and should instead use some other mechanism of clearing Bitcoin or validating transactions against reversal, see the wiki article [[Myths#Point_of_sale_with_bitcoins_isn.27t_possible_because_of_the_10_minute_wait_for_confirmation|here]] for alternatives.<br />
<br />
Applications that require immediate payment processing, like supermarkets or snack machines, need to manage the risks. Here is one way to reverse an unconfirmed payment:<br />
<br />
A [[Double-spending#Finney_attack|Finney attack]] is where an attacker mines a block containing a movement of some coins back to themselves. Once they find a block solution, they quickly go to a merchant and make a purchase, then broadcast the block, thus taking back the coins. This attack is a risk primarily for goods that are dispatched immediately, like song downloads or currency trades. Because the attacker can't choose the time of the attack, it isn't a risk for merchants such as supermarkets where you can't choose exactly when to pay (due to queues, etc). The attack can fail if somebody else finds a block containing the purchasing transaction before you release your own block, therefore, merchants can reduce but not eliminate the risk by making purchasers wait some length of time that's less than a confirm.<br />
<br />
Because pulling off this attack is not trivial, merchants who need to sell things automatically and instantly are most likely to adjust the price to include the cost of reversal fraud, or elect to use special insurance.<br />
<br />
=== I was sent some bitcoins and they haven't arrived yet! Where are they? ===<br />
<br />
Don't panic! There are a number of reasons why your bitcoins might not show up yet, and a number of ways to diagnose them. <br />
<br />
The latest version of the Bitcoin-Qt client tells you how far it has yet to go in downloading the blockchain. Hover over the icon in the bottom right corner of the client to learn your client's status.<br />
<br />
If it has not caught up then it's possible that your transaction hasn't been included in a block yet. <br />
<br />
You can check pending transactions in the network by going [https://www.biteasy.com here] or [http://blockchain.info here] and then searching for your address. If the transaction is listed here then it's a matter of waiting until it gets included in a block before it will show in your client. <br />
<br />
If the transaction is based on a coin that was in a recent transaction then it could be considered a low priority transaction. Transfers can take longer if the transaction fee paid was not high enough. If there is no fee at all the transfer can get a very low priority and take hours or even days to be included in a block.<br />
<br />
<br />
=== I sent too small of a transaction fee, is my bitcoin lost forever? ===<br />
<br />
<br />
If the transaction never gets confirmed into a block - the mempool expiry of all nodes will drop it eventually and you will be able to spend your funds again - [https://hackernoon.com/holy-cow-i-sent-a-bitcoin-transaction-with-too-low-fees-are-my-coins-lost-forever-7a865e2e45ba typically] it takes about 3 days or so for this to happen. If using an [[https://en.bitcoin.it/w/index.php?title=Scalability#Simplified_payment_verification SPV]] wallet such as [[ Electrum]] or [[Multibit]], if after three days the wallet does not see the coin to spend, you need to reindex your wallet's block headers. After reindexing, your wallet will see that the coin was never confirmed and thus the balance will be spendable again. <br />
<br />
'''NOTE''': From Bitcoin 0.14 “transaction reappearance” happens after 2 [https://www.reddit.com/r/Bitcoin/comments/69jywp/a_practical_guide_to_accidental_low_fee/dhjfthf/ weeks].<br />
<br />
=== Why does my Bitcoin address keep changing? ===<br />
{{seealso|Address reuse}}<br />
Unlike postal and email addresses, Bitcoin addresses are designed to be used exactly once only, for a single transaction.<br />
Originally, wallets would display only a single address at a time, and change it when a transaction was received, but an increasing number of wallet implementations now generate an address when you explicitly want to receive a payment.<br />
<br />
While it is technically possible to use an address for an arbitrary number of payments, this works by accident and harms both yourself ''and other unrelated third parties'', so it is considered a bad practice.<br />
The most important concerns with such misuse involve loss of privacy and security:<br />
both can be put into jeopardy when addresses are used for more than a single transaction only.<br />
<br />
===How much will the transaction fee be? / Why is the fee so high?===<br />
<br />
Bitcoin transactions almost always require a [[transaction fee]] for them to get confirmed. The transaction fee is received by the first bitcoin miner who mines a [[block]] containing the transaction; this action is also what gives the transaction its first confirmation. The appropriate fee varies depending on how large (in bytes) your transaction is, how fast you want the transaction to be confirmed, and also on current network conditions. As such, paying a fixed fee, or even a fixed fee per kB, is a very bad idea; all good Bitcoin wallets will use several pieces of data to estimate an appropriate fee for you, though some are better at fee estimation than others.<br />
<br />
The fee most strongly depends on the transaction's data size. Fees do '''not''' depend on the BTC amount of the transaction -- it's entirely possible for a 0.01 BTC transaction to require a higher fee than a 1000 BTC transaction.<br />
<br />
Basic intro to how Bitcoin [[transactions]] work: If you receive BTC in three separate transactions of (say) 1, 5, and 10 BTC, then you can think of your wallet as containing three gold coins with sizes 1, 5, and 10 BTC. If you then want to send 6 BTC, you can melt the 1 & 5 BTC coins together and recast them as a 6 BTC coin, or melt the 10 BTC coin and recast a 6 BTC coin for the recipient and a 4 BTC coin as change for yourself. In Bitcoin's technical vocabulary, these objects are literally called input and output coins. (In the rest of this section, when we say "coin" we mean these objects, not the amount of BTC value.)<br />
<br />
Transaction data sizes, and therefore fees, are proportional to the '''number''' (not value) of input and output coins in a transaction. Input coins are about 5x larger / more expensive than output coins.<br />
<br />
If your wallet estimates a very high fee, it is most likely because your wallet is full of a whole bunch of tiny coins, so your transaction will need to take very many coins as inputs, increasing the cost. On the bright side, fees will go down once you make a few transactions, since you will end up "melting down" these many small coins into a few larger ones. Sometimes you can significantly reduce the fee by sending less BTC: if you have like 1000 tiny faucet payments totaling 0.5 BTC and then 16.5 BTC from other sources, then you'll find that sending ~16.5 BTC will be massively cheaper than sending a slightly higher value since it avoids including all of those faucet coins.<br />
<br />
Fees also fluctuate depending on network conditions. All unconfirmed transactions compete with each other to be picked up by miners. If there are a lot of high-fee transactions being sent right now, then you will need to pay higher fees to out-bid them. On the other hand, if speed is less important to you, you can pay a somewhat smaller fee, and your transaction will float around until there is a period of reduced network usage. Sometimes even transactions with zero fee will be confirmed after a very long period of time, though this requires a perfect set of conditions, beyond what is explained here (ie. it probably won't work if you try it).<br />
<br />
Oftentimes wallets will have an "express" fee configuration, but note that confirmation times are naturally random and unreliable. At any given point in time, the probability that ''no'' transactions will be confirmed in the next hour is about 0.25% (ie. it happens more than once per week on average). Bitcoin users should avoid getting into situations where their transactions ''absolutely must'' get 1 confirmation in the next couple of hours, even if high-fee transactions usually take less than 10 minutes to get 1 confirmation.<br />
<br />
=== What happens when someone sends me a bitcoin but my computer is powered off? ===<br />
<br />
Bitcoins are not actually "sent" to your wallet; the software only uses that term so that we can use the currency without having to learn new concepts. Your wallet is only needed when you wish to spend coins that you've received.<br />
<br />
If you are sent coins when your wallet client program is not running, and you later launch the wallet client program, the coins will eventually appear as if they were just received in the wallet. That is to say, when the client program is started it must download blocks and catch up with any transactions it did not already know about.<br />
<br />
=== How long does "synchronizing" take when the Bitcoin client is first installed? What's it doing? ===<br />
<br />
The popular Bitcoin client software from bitcoin.org implements a "full" Bitcoin node: It can carry out all the duties of the Bitcoin P2P system, it isn't simply a "client". One of the principles behind the operation of full Bitcoin nodes is that they don't assume that the other participants have followed the rules of the Bitcoin system. During synchronization, the software is processing historical Bitcoin transactions and making sure for itself that all of the rules of the system have been correctly followed.<br />
<br />
In normal operation, after synchronizing, the software should use a hardly noticeable amount of your computer's resources.<br />
<br />
When the wallet client program is first installed, its initial validation requires a lot of work from your computer's hard disk, so the amount of time to synchronize depends on your disk speed and, to a lesser extent, your CPU speed. It can take anywhere from a few hours to a day or so. On a slow computer it could take more than 40 hours of continuous synchronization, so check your computer's power-saving settings to ensure that it does not turn its hard disk off when unattended for a few hours. You can use the Bitcoin software during synchronization, but you may not see recent payments to you until the client program has caught up to the point where those transactions happened.<br />
<br />
If you feel that this process takes too long, you can download a pre-synchronized blockchain from [http://eu2.bitcoincharts.com/blockchain/ http://eu2.bitcoincharts.com/blockchain/]. Alternatively, you can try an alternative "lite" client such as Multibit or a super-light client like electrum, though these clients have somewhat weaker security, are less mature, and don't contribute to the health of the P2P network.<br />
<br />
==Networking==<br />
=== Do I need to configure my firewall to run Bitcoin? ===<br />
<br />
Bitcoin will connect to other nodes, usually on TCP port 8333. You will need to allow outgoing TCP connections to port 8333 if you want to allow your Bitcoin client to connect to many nodes. [[Testnet]] uses TCP port 18333 instead of 8333.<br />
<br />
If you want to restrict your firewall rules to a few IPs, you can find stable nodes in the [[Fallback Nodes|fallback nodes list]].<br />
<br />
=== How does the peer finding mechanism work? ===<br />
<br />
Bitcoin finds peers primarily by forwarding peer announcements within its own network and each node saves a database of peers that it's aware of, for future use. In order to bootstrap this process Bitcoin needs a list of initial peers, these can be provided manually but normally it obtains them by querying a set of DNS domain names which have automatically updated lists, if that doesn't work it falls back to a built-in list which is updated from time to time in new versions of the software. In the reference software initial peers can also be specified manually by adding an addr.txt to the data directory or via the addnode parameter.<br />
<br />
==Mining==<br />
===What is mining?===<br />
[[Mining]] is the process of spending computation power to secure Bitcoin transactions against reversal and introducing new Bitcoins to the system<ref>[https://www.bitcoinmining.com Bitcoin Mining]</ref>.<br />
<br />
Technically speaking, mining is the calculation of a [[hash]] of the a block header, which includes among other things a reference to the previous block, a hash of a set of transactions and a [[nonce]]. If the hash value is found to be less than the current [[target]] (which is inversely proportional to the [[difficulty]]), a new block is formed and the miner gets the newly generated Bitcoins (25 per block at current levels). If the hash is not less than the current target, a new nonce is tried, and a new hash is calculated. This is done millions of times per second by each miner.<br />
<br />
===Is mining used for some useful computation?===<br />
The computations done when mining are internal to Bitcoin and not related to any other distributed computing projects. They serve the purpose of securing the Bitcoin network, which is useful.<br />
<br />
===Is it not a waste of energy?===<br />
Spending energy on creating and securing a free monetary system is hardly a waste. Also, services necessary for the operation of currently widespread monetary systems, such as banks and credit card companies, also spend energy, arguably more than Bitcoin would.<br />
<br />
===Why don't we use calculations that are also useful for some other purpose?===<br />
To provide security for the Bitcoin network, the calculations involved need to have some [http://bitcoin.stackexchange.com/questions/5617/why-are-bitcoin-calculation-useless/5618#5618 very specific features]. These features are incompatible with leveraging the computation for other purposes.<br />
<br />
===How can we stop miners from creating zero transaction blocks?===<br />
The incentive for miners to include transactions is in the fees that come along with them. If we were to implement some minimum number of transactions per block it would be trivial for a miner to create and include transactions merely to surpass that threshold. As the network matures, the block reward drops, and miners become more dependent on transactions fees to pay their costs, the problem of zero transaction blocks should diminish over time.<br />
<br />
===How does the proof-of-work system help secure Bitcoin?===<br />
Bitcoin uses the [[Hashcash]] [[proof of work]] with a minor adaption. To give a general idea of the mining process, imagine this setup:<br />
<br />
payload = <some data related to things happening on the Bitcoin network><br />
nonce = 1<br />
hash = [http://en.wikipedia.org/wiki/SHA2 SHA2]( [http://en.wikipedia.org/wiki/SHA2 SHA2]( payload + nonce ) )<br />
<br />
The work performed by a miner consists of repeatedly increasing "nonce" until<br />
the hash function yields a value, that has the rare property of being below a certain<br />
target threshold. (In other words: The hash "starts with a certain number of zeroes",<br />
if you display it in the fixed-length representation, that is typically used.)<br />
<br />
As can be seen, the mining process doesn't compute anything special. It merely<br />
tries to find a number (also referred to as nonce) which - in combination with the payload -<br />
results in a hash with special properties.<br />
<br />
The advantage of using such a mechanism consists of the fact, that it is very easy to check a result: Given the payload and a specific nonce, only a single call of the hashing function is needed to verify that the hash has the required properties. Since there is no known way to find these hashes other than brute force, this can be used as a "[[proof of work]]" that someone invested a lot of computing power to find the correct nonce for this payload.<br />
<br />
This feature is then used in the Bitcoin network to allow the network to come to a consensus on the history of transactions. An attacker that wants to rewrite history will need to do the required proof of work before it will be accepted. And as long as honest miners have more computing power, they can always outpace an attacker.<br />
<br />
Also see [http://en.wikipedia.org/wiki/Hashcash Hashcash] and [http://en.wikipedia.org/wiki/Proof-of-work_system Proof-of-work system] and [http://en.wikipedia.org/wiki/SHA2 SHA2] and on Wikipedia.<br />
<br />
===Why was the "Generate coin" option of the client software removed?===<br />
<br />
The option wasn't removed, but it is now only accessible via the command-line or the configuration file. The reason for this is that many users were complaining after they turned on and expecting to receive coins. Without specialized mining hardware a user is exceptionally unlikely generate a block on their own at the network's current [[difficulty|security level]].<br />
<br />
==Security==<br />
<br />
===Could miners collude to give themselves money or to fundamentally change the nature of Bitcoin?===<br />
<br />
There are two questions in here. Let's look at them separately.<br />
<br />
;Could miners gang up and give themselves money?<br />
<br />
Mining itself is the process of creating new blocks in the block chain. Each block contains a list of all the transactions that have taken place across the entire Bitcoin network since the last block was created, as well as a hash of the previous block. New blocks are 'mined', or rather, generated, by Bitcoin clients correctly guessing sequences of characters in codes called 'hashes,' which are created using information from previous blocks. Bitcoin users may download specialized 'mining' software, which allows them to dedicate some amount of their processing power – however large or small – to guessing at strings within the hash of the previous block. Whoever makes the right guess first, thus creating a new block, receives a reward in Bitcoins.<br />
<br />
The block chain is one of the two structures that makes Bitcoin secure, the other being the public-key encryption system on which Bitcoin trade is based. The block chain assures that not only is every single transaction that ever takes place recorded, but that every single transaction is recorded on the computer of anyone who chooses to store the relevant information. Many, many users have complete records of every transaction in Bitcoins history readily available to them at any point, and anyone who wants in the information can obtain it with ease. These things make Bitcoin very hard to fool.<br />
<br />
The Bitcoin network takes considerable processing power to run, and since those with the most processing power can make the most guesses, those who put the most power toward to sustaining the network earn the most currency. Each correct guess yields, at present, twenty-five Bitcoins, and as Bitcoins are presently worth something (although the value still fluctuates) every miner who earns any number of Bitcoins makes money. Some miners pull in Bitcoins on their own; and some also join or form pools wherein all who contribute earn a share of the profits. <br />
<br />
Therefore, first answer is a vehement “yes” – not only can miners collude to get more money, Bitcoin is designed to encourage them to do so. Bitcoin pools are communal affairs, and there is nothing dishonest or underhanded about them.<br />
<br />
Of course, the real question is:<br />
<br />
;Can they do so in ways not sanctioned by Bitcoin network? Is there any way to rip off the network and make loads of money dishonestly?<br />
<br />
Bitcoin isn't infallible. It can be cheated, but doing so is extremely difficult. Bitcoin was designed to evade some of the central problems with modern currencies – namely, that their trustworthiness hinges upon that of people who might not have users' best interests in mind. Every currency in the world (other than Bitcoin) is controlled by large institutions who keep track of what's done with it, and who can manipulate its value. And every other currency has value because people trust the institutions that control them.<br />
<br />
Bitcoin doesn't ask that its users trust any institution. Its security is based on the cryptography that is an integral part of its structure, and that is readily available for any and all to see. Instead of one entity keeping track of transactions, the entire network does, so Bitcoins are astoundingly difficult to steal, or double-spend. Bitcoins are created in a regular and predictable fashion, and by many different users, so no one can decide to make a whole lot more and lessen their value. In short, Bitcoin is designed to be inflation-proof, double-spend-proof and completely distributed.<br />
<br />
Nonetheless, there are a few ways that one can acquire Bitcoins dishonestly. Firstly, one can steal private keys. Key theft isn't something that Bitcoin security has been designed to prevent: it's up to users to keep their keys safe. But the cryptography is designed so that it is completely impossible to deduce someone's private key from their public one. As long as you keep your private key to yourself, you don't have much to worry about. Furthermore, one could theoretically create a new block chain, but due to the way in which the block chain is constructed, this would be extremely difficult and require massive amounts of processing power. A full explanation of the difficulties involved can be found in the [[block chain]] article.<br />
<br />
Bitcoin can be ripped off – but doing so would be extremely hard and require considerable expertise and a staggering amount of processing power. And it's only going to get harder with time. Bitcoin isn't impenetrable, but it's close enough to put any real worries in the peripherals.<br />
<br />
;Could miners fundamentally change the nature of Bitcoin?<br />
<br />
Once again, almost certainly not.<br />
<br />
Bitcoin is a distributed network, so any changes implemented to the system must be accepted by all users. Someone trying to change the way Bitcoins are generated would have to convince every user to download and use their software – so the only changes that would go through are those that would be equally benefit all users. <br />
<br />
And thus, it is more or less impossible for anyone to change the function of Bitcoin to their advantage. If users don't like the changes, they won't adopt them, whereas if users do like them, then these will help everyone equally. Of course, one can conceive of a situation where someone manages to get a change pushed through that provides them with an advantage that no one notices, but given that Bitcoin is structurally relatively simple, it is unlikely that any major changes will go through without someone noticing first.<br />
<br />
The fact that such changes are so difficult to make testifies to the fully distributed nature of Bitcoin. Any centrally controlled currency can be modified by its central agency without the consent of its adherents. Bitcoin has no central authority, so it changes only at the behest of the whole community. Bitcoins development represents a kind of collective evolution; the first of its kind among currencies.<br />
<br />
==Help==<br />
===I'd like to learn more. Where can I get help?===<br />
<br />
* Read the [[Introduction|introduction to bitcoin]] <br />
* See the videos, podcasts, and blog posts from the [[Press]]<br />
* Read and post on the [[:Bitcoin Wiki:Community_portal#Bitcoin_Community_Forums|forums]]<br />
* Chat on one of the [[:Bitcoin Wiki:Community_portal#IRC_Chat|Bitcoin IRC]] channels<br />
* Listen to [http://omegataupodcast.net/2011/03/59-bitcoin-a-digital-decentralized-currency/ this podcast], which goes into the details of how bitcoin works<br />
* Ask questions on the [http://bitcoin.stackexchange.com Bitcoin Stack Exchange]<br />
* Use [http://bitcoinx.io BitcoinX.io] to help beginners learn about reputable Bitcoin exchanges and Bitcoin wallets<br />
<br />
==See Also==<br />
<br />
* [[Man page]]<br />
* [[Introduction]]<br />
* [[Prohibited changes]]<br />
<br />
==References==<br />
<references><br />
<references/><br />
{{Reflist|2}}<br />
<br />
[[de:FAQ]]<br />
[[zh-cn:FAQ]]<br />
[[fr:FAQ]]<br />
[[ru:FAQ]]<br />
<br />
[[Category:Technical]]<br />
[[Category:Vocabulary]]</div>Hardinghttps://en.bitcoin.it/w/index.php?title=Mining&diff=65508Mining2018-06-25T21:48:55Z<p>Harding: Undo revision 65504 by RunCPA (talk)</p>
<hr />
<div><!-- This page is designed to be short and simple! It should provide only a very brief explanation of things that have their own page and should link to other pages whenever possible. This page should serve as an entry point and a place to organize most of our mining articles. Thank You! (-Atheros) --><br />
[[File:Quick-and-dirty-4x5970-cooling.jpg|thumb|right|A home-made "[[Mining rig|mining rig]]"]]<br />
== Introduction ==<br />
'''Mining''' is the process of adding transaction records to Bitcoin's public ledger of past transactions (and a "[[Mining rig|mining rig]]" is a colloquial metaphor for a single computer system that performs the necessary computations for "mining".<br />
This ledger of past transactions is called the [[block chain]] as it is a chain of [[block|blocks]].<br />
The blockchain serves to [[Confirmation|confirm]] transactions to the rest of the network as having taken place.<br />
Bitcoin nodes use the blockchain to distinguish legitimate Bitcoin transactions from attempts to re-spend coins that have already been spent elsewhere.<br />
<br />
Mining is intentionally designed to be resource-intensive and difficult so that the number of blocks found each day by miners remains steady. Individual [[blocks]] must contain a [[proof of work|proof of work]] to be considered valid. This proof of work is verified by other Bitcoin nodes each time they receive a block. Bitcoin uses the [[hashcash]] proof-of-work function.<br />
<br />
The primary purpose of mining is to set the history of [[transactions]] in a way that is [[Irreversible Transactions|computationally impractical to modify by any one entity]]. By downloading and verifying the blockchain, bitcoin [[full node|nodes]] are able to reach consensus about the ordering of events in bitcoin.<br />
<br />
Mining is also the mechanism used to [[Controlled supply|introduce Bitcoins]] into the system:<br />
Miners are paid any [[transaction fees]] as well as a "subsidy" of newly created coins.<br />
This both serves the purpose of disseminating new coins in a decentralized manner as well as motivating people to provide security for the system.<br />
<br />
Bitcoin mining is so called because it resembles the mining of other commodities:<br />
it requires exertion and it slowly makes new units available to anybody who wishes to take part. An important difference is that the [[Controlled supply|supply]] does not depend on the amount of mining. In general changing total miner hashpower does not change how many bitcoins are created over the long term.<br />
<br />
== Difficulty ==<br />
=== The Computationally-Difficult Problem ===<br />
Mining a block is difficult because the SHA-256 hash of a block's header must be lower than or equal to the [[Target|target]] in order for the block to be accepted by the network. This problem can be simplified for explanation purposes: The hash of a block must start with a certain number of zeros. The probability of calculating a hash that starts with many zeros is very low, therefore many attempts must be made. In order to generate a new hash each round, a [[Nonce|nonce]] is incremented. See [[Proof of work]] for more information.<br />
<br />
=== The Difficulty Metric ===<br />
The [[Difficulty|difficulty]] is the measure of how difficult it is to find a new block compared to the easiest it can ever be. The rate is recalculated every 2,016 blocks to a value such that the previous 2,016 blocks would have been generated in exactly one fortnight (two weeks) had everyone been mining at this difficulty. This is expected yield, on average, one block every ten minutes.<br />
<br />
As more miners join, the rate of block creation increases. As the rate of block generation increases, the difficulty rises to compensate, which has a balancing of effect due to reducing the rate of block-creation. Any blocks released by malicious miners that do not meet the required [[Target|difficulty target]] will simply be rejected by the other participants in the network.<br />
<br />
=== Reward ===<br />
When a block is discovered, the discoverer may award themselves a certain number of bitcoins, which is agreed-upon by everyone in the network. Currently this bounty is 12.5 bitcoins; this value will halve every 210,000 blocks. See [[Controlled Currency Supply]].<br />
<br />
Additionally, the miner is awarded the fees paid by users sending transactions. The fee is an incentive for the miner to include the transaction in their block. In the future, as the number of new bitcoins miners are allowed to create in each block dwindles, the fees will make up a much more important percentage of mining income.<br />
<br />
== The mining ecosystem ==<br />
<br />
=== Hardware ===<br />
[[File:Usb-fpga module 1.15x-hs-800.jpg|thumb|right|FPGA Module]]<br />
Users have used various types of hardware over time to mine blocks. Hardware specifications and performance statistics are detailed on the [[Mining Hardware Comparison]] page.<br />
==== CPU Mining ==== <br />
Early Bitcoin client versions allowed users to use their CPUs to mine. The advent of GPU mining made CPU mining financially unwise as the hashrate of the network grew to such a degree that the amount of bitcoins produced by CPU mining became lower than the cost of power to operate a CPU. The option was therefore removed from the core Bitcoin client's user interface.<br />
<br />
==== GPU Mining ====<br />
GPU Mining is drastically faster and more efficient than CPU mining. See the main article: [[Why a GPU mines faster than a CPU]]. A variety of popular [[Mining rig|mining rigs]] have been documented.<br />
==== FPGA Mining ====<br />
FPGA mining is a very efficient and fast way to mine, comparable to GPU mining and drastically outperforming CPU mining. FPGAs typically consume very small amounts of power with relatively high hash ratings, making them more viable and efficient than GPU mining. See [[Mining Hardware Comparison]] for FPGA hardware specifications and statistics.<br />
==== ASIC Mining ====<br />
An application-specific integrated circuit, or ''ASIC'', is a microchip designed and manufactured for a very specific purpose. ASICs designed for Bitcoin mining were first released in 2013. For the amount of power they consume, they are vastly faster than all previous technologies and already have made GPU mining financially.<br />
<br />
==== Mining services (Cloud mining) ====<br />
[[:Category:Mining_contractors|Mining contractors]] provide mining services with performance specified by contract, often referred to as a "Mining Contract." They may, for example, rent out a specific level of mining capacity for a set price at a specific duration.<br />
<br />
=== Pools ===<br />
As more and more miners competed for the limited supply of blocks, individuals found that they were working for months without finding a block and receiving any reward for their mining efforts. This made mining something of a gamble. To address the variance in their income miners started organizing themselves into [[Pooled mining|pools]] so that they could share rewards more evenly. See [[Pooled mining]] and [[Comparison of mining pools]].<br />
<br />
=== History ===<br />
Bitcoin's public ledger (the "block chain") was started on January 3rd, 2009 at 18:15 UTC presumably by [[Satoshi Nakamoto]]. The first block is known as the [[genesis block]]. The first transaction recorded in the first block was a single transaction paying the reward of 50 new bitcoins to its creator.<br />
<br />
==See Also==<br />
<br />
* [https://99bitcoins.com/beginners-guide-to-mining/ Beginner's Guide to Bitcoin Mining]<br />
* [https://www.zpool.ca Bitcoin Multipool]<br />
* [https://www.bitcoinmining.com Bitcoin Mining]<br />
* [http://codinginmysleep.com/bitcoin-mining-in-plain-english Bitcoin Mining in Plain English] by David Perry<br />
* [https://www.weusecoins.com/en/mining-guide/ Getting Started With Bitcoin Mining]<br />
* [[Automatically mine when computer is locked|Tutorial to automatically start mining when you lock your computer]]. (Windows 7)<br />
* [http://bitcoinminer.com Bitcoin Miner]<br />
* [http://www.bitcongress.org/bitcoin/best-bitcoin-mining-hardware/ Bitcoin Mining Hardware Comparison]<br />
* [http://www.reddit.com/r/Bitcoin/comments/18q2jx/eli5_bitcoin_mining_xpost_in_eli5/ Simplified Explanation of Bitcoin Mining] by reddit user [http://www.reddit.com/user/azotic azotic]<br />
* [https://bitcoinchain.com/pools Bitcoin Mining Pools Comparison]<br />
* [http://www.bitcoinmining.com/best-bitcoin-cloud-mining-contract-reviews/ Research, Review and Compare Cloud Mining Contracts]<br />
* [https://www.youtube.com/watch?v=GmOzih6I1zs Video: What is Bitcoin Mining?] <br />
* [http://yogh.io/#mine:last Mining Simulator] ([https://github.com/JornC/bitcoin-transaction-explorer GitHub source])<br />
* [http://bitcoindaily.org/bitcoin-guides/what-is-bitcoin-mining/ Bitcoin Mining Explained]<br />
[[ru:Mining]]<br />
[[Category:Mining]][[Category:Vocabulary]]</div>Hardinghttps://en.bitcoin.it/w/index.php?title=Lightning_Network&diff=65507Lightning Network2018-06-25T21:47:44Z<p>Harding: Undo revision 65501 by RunCPA (talk)</p>
<hr />
<div>'''Lightning Network''' is a proposed implementation of [[Hashed Timelock Contracts]] (HTLCs) with bi-directional [[payment channels]] which allows payments to be securely routed across multiple peer-to-peer payment channels.<ref name="ln_pdf">[https://lightning.network/lightning-network-paper.pdf Lightning Network paper, v0.5.9.1]<br>Joseph Poon & Thaddeus Dryja<br>''Retrieved 2016-04-10''</ref> This allows the formation of a network where any peer on the network can pay any other peer even if they don't directly have a channel open between each other.<br />
<br />
== Key features == <br />
Key features of the Lightning Network proposal include,<br />
<br />
* '''Rapid payments:''' payments within an established channel can be made almost as fast as data can travel over the Internet between the two peers.<br />
* '''No third-party trust:''' the two peers in a channel pay each other directly using regular Bitcoin transactions (of which only one is broadcast) so at no point does any third party control their funds.<br />
* '''Reduced blockchain load:''' only channel open transactions, channel close transactions, and (hopefully infrequent) anti-fraud respends need to be committed to the blockchain, allowing all other payments within Lightning Network channels to remain uncommitted. This allows Lightning Network users to make frequent payments secured by Bitcoin without placing excessive load on full nodes which must process every transaction on the blockchain.<br />
* '''Channels can stay open indefinitely:''' as long as the two parties in the channel continue to cooperate with each other, the channel can stay open indefinitely -- there is no mandatory timeout period. This can further reduce the load on the blockchain as well as allow the fees for opening and closing the channel to be amortized over a longer period of time.<br />
* '''Rapid cooperative closes:''' if both parties cooperate, a channel can be closed immediately (with the parties likely wanting to wait for one or more confirmations to ensure the channel closed in the correct state). Non-cooperative closes (such as when one party disappears) are also possible but they take longer.<br />
* '''Outsourcable enforcement:''' if one party closes a channel in an old state in an attempt to steal money, the other party has to act within a defined period of time to block the attempted theft. This function can be outsourced to a third-party without giving them control over any funds, allowing wallets to safely go offline for periods longer than the defined period.<br />
* '''Onion-style routing:''' payment routing information can be encrypted in a nested fashion so that intermediary nodes only know who they received a routable payment from and who to send it to next, preventing those intermediary nodes from knowing who the originator or destination is (provided the intermediaries didn't compare records).<br />
* '''Multisignature capable:''' each party can require that their payments into the channel be signed by multiple keys<ref name="poon_multisig">[https://lists.linuxfoundation.org/pipermail/lightning-dev/2016-January/000403.html 2-of-3 Instant Escrow, or How to Do "2-of-3 Multisig Contract" Equivilant on Lightning]<br>Joseph Poon<br>''Retrieved 2016-04-11''</ref>, giving them access to additional security techniques.<br />
* '''Securely cross blockchains:''' payments can be routed across more than one blockchain (including altcoins and sidechains) as long as all the chains support the same hash function to use for the hash lock, as well as the ability the ability to create time locks.<br />
* '''Sub-satoshi payments:''' payments can be made conditional upon the outcome of a random event, allowing probabilistic payments.<ref name="dryja_directed_graph"/> For example, Alice can pay Bob 0.1 satoshi by creating a 1-satoshi payment with 10-to-1 odds so that 90% of the time she does this she pays him 0 satoshis and 10% of the time she pays him 1 satoshi for an average payment of 0.1 satoshis.<br />
* '''Single-funded channels:''' when Alice needs to send a payment to Bob and doesn't currently have a way to pay him through the Lightning Network (whether because she can't reach him or because she doesn't have enough money in an existing channel), she can make a regular on-chain payment that establishes a channel without Bob needing to add any of his funds to the channel. Alice only uses 12 bytes more than she would for a non-Lightning direct payment and Bob would only need about 25 more [[segwit]] virtual bytes to close the channel than he would had he received a non-Lightning direct payment.<ref name="dryja_directed_graph"/><br />
<br />
== Glossary ==<br />
<br />
<br />
This section attempts to document the most frequently used terms found in Lightning Network literature that may not be familiar to a general technical audience, including both the new terms created by Lightning Network designers as well as pre-existing terms that may not be well known from Bitcoin, cryptography, network routing, and other fields.<br />
<br />
The list below should be in alphabetical order. Any commonly-used synonyms or analogs for a term are placed in parenthesis after the term.<br />
<br />
* '''Bi-directional payment channel:'''<ref name="ln_pdf"/> a payment channel where payments can flow both directions, from Alice to Bob and back to Alice. This is contrasted with Spillman-style and CLTV-style payment channels where payments can only go one direction and once Alice has paid Bob all of the bitcoins she deposited in the channel funding transaction, the channel is no longer useful and so will be closed.<br />
* '''Breach Remedy Transaction:'''<ref name="ln_pdf"/> the transaction Alice creates when Mallory attempts to steal her money by having an old version of the channel state committed to the blockchain. Alice's breach remedy transaction spends all the money that Mallory received but which Mallory can't spend yet because his unilateral spend is still locked by a relative locktime using <code>OP_CSV</code>. This is the third of the maximum of three on-chain transactions needed to maintain a Lightning channel; it only needs to be used in the case of attempted fraud (contract breach).<br />
* '''Channel''' (Lightning channel<ref name="ln_pdf"/>, payment channel<ref name="spillman_channel">[https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2013-April/002433.html Anti DoS for tx replacement]<br>Jeremy Spillman<br>Retrieved 2016-04-17</ref>) a communication channel that allows two parties to make many secure payments between each other in exchange for making only a few transactions on the blockchain.<br />
* '''Commitment Transaction:'''<ref name="ln_pdf"/> a transaction created collaboratively by Alice and Bob each time they update the state of the channel; it records their current balances within the channel. The '''Initial Commitment Transaction'''<ref name="ln_pdf"/> is the first of these transactions; it records the inital balances within the channel. This is the second of the maximum of three on-chain transactions needed to maintain a Lightning channel; it can be combined with a ''funding transaction'' for a new channel under the cooperative conditions necessary to create an ''exercise settlement transaction''.<br />
* '''Contract:'''<ref name="szabo_smart_contracts">[http://szabo.best.vwh.net/smart_contracts_idea.html The Idea of Smart Contracts]<br>Nick Szabo<br>Retrieved 2016-04-17</ref> an agreement between two or more entities to use Bitcoin transactions in a certain way, usually a way that allows Bitcoin's automated consensus to enforce some or all terms in the contract. Often called a ''smart contract''.<br />
* '''CSV:''' (<code>OP_CheckSequenceVerify</code>, <code>OP_CSV</code>)<ref name="bip68"/> a opcode that allows an output to conditionally specify how long it must be part of the blockchain before an input spending it may be added to the blockchain. See ''relative locktime.''<br />
* '''Delivery Transaction:'''<ref name="ln_pdf"/> not really a transaction but rather the name for the outputs in the ''commitment transaction'' which Alice and Bob receive if one of them closes the channel unilaterally in the correct (current) state. If the channel is closed in an old state (indicating possible fraud), a ''breach remedy transaction'' will be generated from the output that would have paid the party closing the channel. If the channel is closed cooperatively, they'll create an ''exercise settlement transaction'' instead.<br />
* '''Dispute period:''' (dispute resolution period<ref name="poon_time_bitcoin_ln">[https://lightning.network/lightning-network-presentation-time-2015-07-06.pdf Time, Bitcoin, and the Lightning Network]<br>Joseph Poon<br>Retrieved 2016-04-17</ref>) the period of time that Alice has to get her ''breach remedy transaction'' added to the blockchain after Mallory has an old ''commitment transaction'' added to the blockchain. If the dispute period ends without a breach remedy transaction being added to the blockchain, Mallory can spend the funds he received from the old commitment transaction.<br />
* '''Dual-funded channel:'''<ref name="dryja_directed_graph">[https://docs.google.com/presentation/d/1G4xchDGcO37DJ2lPC_XYyZIUkJc2khnLrCaZXgvDN0U/edit?pref=2&pli=1#slide=id.g85f425098_0_2 LN as a Directed Graph: Single-Funded Channel Topology]<br>Thaddeus Dryja<br>Retrieved 2016-04-17</ref> a channel opened by a ''funding transaction'' containing inputs from both Alice and Bob. Compare to a ''single-funded channel'' where only Alice's inputs contribute to the balance of the channel.<br />
* '''Encumbrance:'''<ref>[http://chimera.labs.oreilly.com/books/1234000001802/ch02.html Mastering Bitcoin, Chapter 2: How Bitcoin Works]<br>Andreas Antonopoulos<br>Retrieved 2016-04-17</ref> a generic name for any conditions that must be satisfied before a bitcoin output may be spent. Early Bitcoin transactions placed all their conditions in the scriptPubKey; later the introduction of P2SH allowed conditions to be added in a redeemScript which the scriptPubKey committed to; the introduction of soft fork [[segwit]] will add a similar mechanism for detached conditions that the scriptPubKey commits to; in addition, there are even more novel ways to add conditions to outputs that are discussed but rarely used. The term &quot;encumbrance&quot; allows specifying what the conditions do without fussing over exactly where the conditions appear in a serialized transaction.<br />
* '''Exercise Settlement Transaction:'''<ref name="ln_pdf"/> a form of the ''commitment transaction'' created cooperatively by Alice and Bob when they want to close their channel together. Unlike a regular commitment transaction, none of the outputs on an exercise settlement transaction are time locked, allowing them to be immediately respent.<br />
* '''Exhausted:'''<ref name="dryja_directed_graph"/> (exhausted channel) a payment channel where no additional payments can be made in one direction (such as from Alice to Bob). The person controlling the exhausted side of a Lightning channel loses nothing from fraudulently trying to commit an old channel state, so allowing a channel to become exhausted (or too near to being exhausted) is unpreferable. (Exception: channels can be securely started in an exhausted state, such as a ''single-funded channel.''<br />
* '''Full push:'''<ref name="dryja_directed_graph"/> when Alice pays the full amount of the channel to Bob in the ''initial commitment transaction'', which ''exhausts'' the channel without incentivizing fraud because Alice doesn't have a previous ''commitment transaction'' that she can broadcast. This term is used in the context of a ''single-funded transaction'' and stands in contrast to an ''overpayment'' where Alice deposits more than she pays Bob in that initial payment so that she can continue to use the channel without needing to ''rebalance''.<br />
* '''Funding Transaction:'''<ref name="ln_pdf"/> (deposit transaction) a transaction created collaboratively by Alice and Bob to open a Lightning channel. In a single-funded channel, Alice provides all the funding;<ref name="dryja_directed_graph"/> in a dual-funded channel, Alice and Bob both provide some funding. This is the first of the maximum of three on-chain transactions needed to maintain a Lightning channel; it can be combined with a commitment transaction from a previous channel being closed under cooperative conditions.<br />
* '''Half-signed:'''<ref name="ln_pdf"/> a transaction input which requires two signatures to be added to the blockchain but which only has one signature attached. (More generally, this could be any input that has fewer signatures attached than it needs to be added to the blockchain.)<br />
* '''Hash lock:'''<ref>[https://www.mail-archive.com/bitcoin-development@lists.sourceforge.net/msg05135.html BIP - Hash Locked Transaction]<br>Tier Nolan<br>Retrieved 2016-04-17</ref> an encumbrance to a transaction output that requires the pre-image used to generate a particular hash be provided in order to spend the output. In Lightning, this is used to allow payments to be routable without needing to trust the intermediaries.<br />
* '''HTLC:''' (Hashed Timelocked Contract<ref name="russell_deployable_lightning">[https://github.com/ElementsProject/lightning/raw/master/doc/deployable-lightning.pdf Reaching the Ground with Lightning]<br>Rusty Russell<br>Retrieved 2016-04-17</ref>) a contract such as that used in a Lightning Channel where both a ''hash lock'' and a ''time lock'' are used, the hash lock being used to allow Alice to route payments to Bob even through a Mallory that neither of them trust, and the time lock being used to prevent Mallory from stealing back any payments he made to Alice within the channel (provided Alice enforces the contract).<br />
* '''Intermediary:'''<ref name="ln_pdf"/> When Bob has one channel open with Alice and another channel open with Charlie, Bob can serve as an intermediary for transferring payments between Alice and Charlie. With Lightning payments being secured with a ''hash lock,'' Bob can't steal the payment from Alice to Charlie when it travels through Bob's node. Lightning payments can securely travel through a theoretically unlimited number of intermediaries.<br />
* '''Limbo channel:'''<ref name="dryja_directed_graph"/> an optional special state for a Lightning channel where it cannot be immediately closed by one or both of the parties unilaterally (it can still be immediately closed cooperatively). This is used in particular for ''PLIPPs.''<br />
* '''Multisig:'''<ref name="bitcoin_0_1_code"/> (multisignature, m-of-n multisig) a transaction output that requires signatures from at least one of a set of two or more different private keys. Used in Lightning to give both Alice and Bob control over their individual funds within a channel by requiring both of them sign ''commitment transactions''.<br />
* '''Node:''' (Lightning node<ref name="ln_pdf"/>) a wallet with one or more open Lightning channels. This should not be confused with a Bitcoin [[full node]] that validates Bitcoin blocks, although a full node's wallet may also be simultaneously used as a Lightning node to the advantage of the Lightning network user.<br />
* '''Overfunding:'''<ref name="dryja_directed_graph"/> in a ''single-funded channel,'' Alice deposits more bitcoins into the channel than she pays Bob in the initial payment, allowing her to make additional payments through the Lightning network. This stands in contrast to a ''full push'' where Alice only deposits enough to pay Bob in the initial payment.<br />
* '''PILPP:''' (Pre-Image Length Probabilistic Payments<ref name="dryja_directed_graph"/>) a specific type of ''probabilistic payment'' within a payment channel where Alice creates string with a random length and Bob guesses the length; if he guesses correctly, Alice has to pay him; if he guesses incorrectly, Alice gets to keep her money.<br />
* '''Pre-image:'''<ref>[https://en.wikipedia.org/wiki/Image_%28mathematics%29#Inverse_image Image (mathematics)]<br>English Wikipedia contributors<br>Retrieved 2016-04-17</ref> (R<ref name="ln_pdf"/>) data input into a hash function, which produces a hash of the pre-image. Inputting the same pre-image into the same hash function will always produce the same hash; Lightning uses this feature to create ''hash locks''.<br />
* '''Probabilistic Payment:'''<ref>[[Nanopayments]]<br>Bitcoin Wiki contributors<br>Retrieved 2016-04-17</ref> a payment where Alice only pays Bob if some event outside of Alice's and Bob's control occurs in Bob's favor. Probabilistic payments are usually proposed for scenarios where payments can't conveniently be made small enough for technical reasons (such as not being able to pay less than 1 satoshi) or economic reasons (such as having to pay a transaction fee for every on-chain payment, making small payments uneconomical). See ''PLIPP'' for a specific type of probabilistic payment possible within a Lightning channel.<br />
* '''R:''' the variable commonly used<ref name="ln_pdf"/> in formulas to represent a ''pre-image''.<br />
* '''Rebalance:'''<ref>[https://blockstream.com/2015/09/01/lightning-network/ The Lightning Network: What Is It and What's Happening?]<br>Rusty Russell<br>Retrieved 2016-04-17</ref> a cooperative process between Alice and Bob when they adjust their balances within the channel. This happens with every payment in a Lightning channel and is only noteworthy because single-directional channels (such as Spillman-style and CLTV-style channels) are unable to rebalance and so must close as soon as Alices has paid Bob all the bitcoins she deposited into the channel. See ''bi-directional payment channels.''<br />
* '''Relative locktime:'''<ref name="bip68"/> the ability to specify when a transaction output may be spent relative to the block that included that transaction output. Enabled by BIP68 and made scriptable by BIP112. Lightning uses relative locktime to ensure ''breach remedy transactions'' may be broadcast within a time period starting from when an old ''commitment transaction'' is added to the blockchain; by making this a relative locktime (instead of an absolute date or block height), Lightning channels don't have a hard deadline for when they need to close and so can stay open indefinitely as long as the participants continue to cooperate.<br />
* '''Revocable Sequence Maturity Contract (RSMC):'''<ref name="ln_pdf"/> a ''contract'' used in Lightning to revoke the previous ''commitment transaction''. This is allowed through mutual consent in Lightning by both parties signing a new commitment transaction and releasing the data necessary to create ''breach remedy transactions'' for the previous commitment transaction. This property allows Lightning to support ''bi-directional payment channels'', recover from failed ''HTLC'' routing attempts without needing to commit to the blockchain, as well as provide advanced features such as ''PILPPs.''<br />
* '''Single-funded channel:'''<ref name="dryja_directed_graph"/> a channel opened by a ''funding transaction'' containing only inputs from Alice. Compare to a ''dual-funded channel'' where Alice and Bob both contribute inputs to the initial balance of the channel.<br />
* '''Timelock:'''<ref>[http://rusty.ozlabs.org/?p=450 Lightning Networks Part I: Revocable Transactions]<br>Rusty Russell<br>2016-04-17</ref> either an encumbrance to a transaction that prevents that transaction from being added to the blockchain before a particular time or block height (as is the case with [[nLockTime]], or an encumbrance that prevents a spend from a transaction output from being added to the blockchain before a particular time or block height (as is the case of OP_CLTV, consensus enforced sequence number relative locktime, and OP_CSV). In Lightning, this is used to prevent malicious intermediaries from holding other users' funds hostages as well as to allow victims of attempted theft to submit breach remedy transactions before the thief can respend the funds he stole.<br />
* '''TTL:''' (Time To Live<ref>[http://lists.linuxfoundation.org/pipermail/lightning-dev/2015-July/000019.html Re: Routing on the Lightning Network?]<br>Rusty Russell<br>Retrieved 2016-04-17</ref>) when Alice pays Bob with a ''hash locked'' in-channel payment that's ultimately intended for Charlie, she specifies how long Bob has to deliver the payment (its time to live) before the payment becomes invalid. When Bob pays Charlie with his own in-channel payment that has the same hash lock, Bob specifies a slightly shorter amount of time that Charlie has to reveal the pre-image that unlocks the hash lock before Bob's payment becomes invalid. This ensures that either Bob receives the data necessary to remove the hash lock from the payment he received from Alice or the payment he made to Charlie is invalidated; Alice gets the same guarantee that either the payment she made to Bob ultimate goes through to Charlie or her payment to Bob is invalidated.<br />
* '''Unilateral:'''<ref name="ln_pdf"/> any action performed by only one of the participants in a channel without requesting or needing permission from the other participant. Lightning allows channels to be closed unilaterally (so Alice can close the channel by herself if Bob becomes unresponsive) and attempted fraud can be penalized unilaterally (so Alice can take any bitcoins Mallory tried to steal when he broadcast an old ''commitment transaction'').<br />
* '''UTXO:'''<ref>[https://bitcoin.org/en/glossary/unspent-transaction-output Unspent Transaction Output (UTXO)]<br>Bitcoin.org Developer Glossary<br>Retrieved 2016-04-17</ref> (Unspent Transaction Output) spendable bitcoins. A transaction output lists a bitcoin amount and the conditions (called an ''encumbrance'') that need to be fulfilled in order to spend those bitcoins. Once those bitcoins have been spent on the blockchain, no other transaction in the same blockchain can spend the same bitcoins, so an Uspent Transaction Output (UTXO) is bitcoins that can be spent.<br />
<br />
== See Also ==<br />
<br />
* [[Payment channels]]<br />
* [[Hashed Timelock Contracts]]<br />
* [[Off-Chain Transactions]]<br />
* [http://dev.lightning.community/resources/index.html Lightning Lab's list of resources]<br />
<br />
== References ==<br />
<references><br />
<ref name="bitcoin_0_1_code">[http://satoshi.nakamotoinstitute.org/code/ Bitcoin 0.1 code]<br>Satoshi Nakamoto<br>Retrieved 2016-04-11</ref><br />
<ref name="bip68">[https://github.com/bitcoin/bips/blob/master/bip-0068.mediawiki BIP68: Relative lock-time using consensus-enforced sequence numbers]<br>Mark Friedenbach, BtcDrak, Nicolas Dorier, and kinoshitajona<br>Retrieved 2016-04-12</ref><br />
<references/><br />
<br />
[[Category:Technical]]</div>Hardinghttps://en.bitcoin.it/w/index.php?title=Satoshi_Nakamoto&diff=65506Satoshi Nakamoto2018-06-25T21:47:00Z<p>Harding: Undo revision 65500 by RunCPA (talk)</p>
<hr />
<div>:''For the unit, see [[satoshi (unit)]].''<br />
'''Satoshi Nakamoto''' is the founder of [[Bitcoin]] and initial creator of the [[Original Bitcoin client]]. He has said in a P2P foundation profile<ref name="p2p_f_profile">[http://p2pfoundation.ning.com/profile/SatoshiNakamoto Satoshi Nakamoto profile on P2P Foundation]</ref> that he is from Japan. Beyond that, not much else is known about him and his identity. He has been working on the Bitcoin project since 2007.<ref>[https://bitcointalk.org/index.php?topic=13.msg46#msg46 Re: Questions about Bitcoin]</ref><br />
<br />
His involvement in the Bitcoin project had tapered and by late 2010 it has ended. The most recent messages reportedly indicate that Satoshi is "gone for good"<ref>[http://bitcoinstats.com/irc/bitcoin-dev/logs/2011/04/26#l1303826036.0 Transcript of #bitcoin-dev for 2011/04/26]</ref>.<br />
<br />
==Possible Motives==<br />
He left some clues about why he is doing this project with the inclusion of the following text in the [[Genesis block]], "The Times 03/Jan/2009 Chancellor on brink of second bailout for banks".<br />
<br />
Some interesting quotes:<br />
<blockquote><p>Yes, [we will not find a solution to political problems in cryptography,] but we can win a major battle in the arms race and gain a new territory of <br />
freedom for several years.</p><br />
<br />
<p>Governments are good at cutting off the heads of a centrally controlled <br />
networks like Napster, but pure P2P networks like Gnutella and Tor seem to be <br />
holding their own.<ref>[http://www.mail-archive.com/cryptography@metzdowd.com/msg09971.html Re: Bitcoin P2P e-cash paper Fri, 07 Nov 2008 09:30:36 -0800]</ref></p></blockquote><br />
<br />
<blockquote>It's very attractive to the libertarian viewpoint if we can explain it <br />
properly. I'm better with code than with words though. <ref>[http://www.mail-archive.com/cryptography@metzdowd.com/msg10001.html Re: Bitcoin P2P e-cash paper Fri, 14 Nov 2008 14:29:22]</ref></blockquote><br />
<br />
==Possible identity==<br />
His identity and nationality are unknown.<br />
<br />
He is entirely unknown outside of Bitcoin as far as anyone can tell, and his (never used) PGP key was created just months prior to the date of the genesis block. He seems to be very familiar with the cryptography mailing list, but there are no non-Bitcoin posts from him on it. He has used an email address from an anonymous mail hosting service (vistomail) as well as one from a free webmail account (gmx.com) and sends mail when connected via Tor. Some have speculated that his entire identity was created in advance in order to protect himself or the network. Perhaps he chose the name Satoshi because it can mean "wisdom" or "reason" and Nakamoto can mean "Central source".<br />
<br />
Ultimately the design of Bitcoin and its use of cryptographic proof and fully open implementation is one that makes its creator, in a sense, irrelevant and only of interest for historical reasons.<br />
<br />
==External links==<br />
* [http://bitcointalk.org/Satoshi_Nakamoto.asc Satoshi's PGP public key]<br />
* [http://www.bitcoin.org/bitcoin.pdf Bitcoin: A Peer-to-Peer Electronic Cash System] Paper<br />
* [http://sourceforge.net/users/s_nakamoto SourceForge page]<br />
* [http://nakamotoinstitute.org Satoshi Nakamoto Institute]<br />
<br />
==References==<br />
<references/><br />
<br />
[[de:Satoshi Nakamoto]]<br />
[[es:Satoshi Nakamoto]]<br />
<br />
[[Category:Individuals]]</div>Hardinghttps://en.bitcoin.it/w/index.php?title=File:Consolidation-savings.png&diff=65364File:Consolidation-savings.png2018-05-12T08:26:43Z<p>Harding: Harding uploaded a new version of File:Consolidation-savings.png</p>
<hr />
<div>== Licensing ==<br />
{{self|Cc-zero}}</div>Hardinghttps://en.bitcoin.it/w/index.php?title=CoinJoin&diff=65334CoinJoin2018-04-27T10:44:22Z<p>Harding: Changed opening paragraph to drop mention of "compression", "unnecessary information", and "same value" which aren't necessary for CoinJoin, aren't currently possible, or both.</p>
<hr />
<div>'''CoinJoin''' is a trustless method for combining multiple Bitcoin payments from multiple spenders into a single transaction to make it more difficult for outside parties to determine which spender paid which recipient or recipients. Unlike many other privacy solutions, coinjoin transactions do not require a modification to the bitcoin protocol.<br />
<br />
This type of transaction was first described in posts<ref>[https://bitcointalk.org/?topic=139581 I taint rich! (Raw txn fun and disrupting 'taint' analysis; >51kBTC linked!)]</ref><ref>[https://bitcointalk.org/?topic=279249 CoinJoin: Bitcoin privacy for the real world]</ref> by gmaxwell.<br />
<br />
==Motivation==<br />
<br />
Bitcoin is often promoted as a tool for privacy but the only privacy that exists in Bitcoin comes from pseudonymous addresses which are fragile and easily compromised through reuse, "taint" analysis, tracking payments, IP address monitoring nodes, web-spidering, and many other mechanisms. Once broken this privacy is difficult and sometimes costly to recover.<br />
<br />
Traditional banking provides a fair amount of privacy by default. Your inlaws don't see that you're buying birth control that deprives them of grand children, your employer doesn't learn about the non-profits you support with money from your paycheck, and thieves don't see your latest purchases or how wealthy you are to help them target and scam you. Poor privacy in Bitcoin can be a major practical disadvantage for both individuals and businesses.<br />
<br />
Even when a user ends address reuse by switching to [http://bitcoinism.blogspot.com/2013/07/reclaiming-financial-privacy-with-hd.html BIP 32 address chains], they still have privacy loss from their old coins and the joining of past payments when they make larger transactions.<br />
<br />
Privacy errors can also create externalized costs: You might have good practices but when you trade with people who don't (say ones using "green addresses") you and everyone you trade with loses some privacy. A loss of privacy also presents a grave systemic risk for Bitcoin: If degraded privacy allows people to assemble centralized lists of good and bad coins you may find Bitcoin's fungibility destroyed when your honestly accepted coin is later not honored by others, and its decentralization along with it when people feel forced to enforce popular blacklists on their own coin.<br />
<br />
==Concept==<br />
<br />
The idea is very simple, first some quick background:<br />
<br />
[[Image:Twotx.png|class=fullwidth]]<br />
<br />
A Bitcoin transaction consumes one or more inputs and creates one or more outputs with specified values.<br />
<br />
Each input is an output from a past transaction. For each input there is a distinct signature (scriptsig) which is created in accordance with the rules specified in the past-output that it is consuming (scriptpubkey).<br />
<br />
The Bitcoin system is charged with making sure the signatures are correct, that the inputs exist and are spendable, and that the sum of the output values is less than or equal to the sum of the input values (any excess becomes fees paid to miners for including the transaction).<br />
<br />
It is normal for a transaction to spend many inputs in order to get enough value to pay its intended payment, often also creating an additional 'change' output to receive the unspent (and non-fee) excess.<br />
<br />
There is no requirement that the scriptpubkeys of the inputs used be the same; i.e., no requirement that they be payments to the same address. And, in fact, when Bitcoin is correctly used with one address per payment, none of them will be the same.<br />
<br />
When considering the history of Bitcoin ownership one could look at transactions which spend from multiple distinct scriptpubkeys as co-joining their ownership and make an assumption: How else could the transaction spend from multiple addresses unless a common party controlled those addresses?<br />
<br />
In the illustration 'transaction 2' spends coins which were assigned to 1A1 and 1C3. So 1A1 and 1C3 are necessarily the same party?<br />
<br />
This assumption is incorrect. Usage in a single transaction does not prove common control (though it's currently pretty suggestive), and this is what makes '''CoinJoin''' possible:<br />
<br />
The signatures, one per input, inside a transaction are '''completely''' independent of each other. This means that it's possible for Bitcoin users to agree on a set of inputs to spend, and a set of outputs to pay to, and then to individually and separately sign a transaction and later merge their signatures. The transaction is not valid and won't be accepted by the network until all signatures are provided, and no one will sign a transaction which is not to their liking.<br />
<br />
To use this to increase privacy, the N users would agree on a uniform output size and provide inputs amounting to at least that size. The transaction would have N outputs of that size and potentially N more change outputs if some of the users provided input in excess of the target. All would sign the transaction, and then the transaction could be transmitted. No risk of theft at any point.<br />
<br />
In the illustration 'transaction 2' has inputs from 1A1 and 1C3. Say we beliece 1A1 is an address used for Alice and 1C3 is an address used for Charlie. Which of Alice and Charlie owns which of the 1D and 1E outputs?<br />
<br />
The idea can also be used more casually. When you want to make a payment, find someone else who also wants to make a payment and make a joint payment together. Doing so doesn't increase privacy much, but it actually makes your transaction smaller and thus easier on the network (and lower in fees); the extra privacy is a perk.<br />
<br />
Such a transaction is externally indistinguishable from a transaction created through conventional use. Because of this, if these transactions become widespread they improve the privacy even of people who do not use them, because no longer will input co-joining be strong evidence of common control.<br />
<br />
There are many variations of this idea possible, and all can coexist because the idea requires no changes to the Bitcoin system. Let a thousand flowers bloom: we can have diversity in ways of accomplishing this and learn the best.<br />
<br />
==Example==<br />
<br />
An example 2-party coinjoin transaction. https://chain.localbitcoins.com/tx/c38aac9910f327700e0f199972eed8ea7c6b1920e965f9cb48a92973e7325046<br />
The outputs to addresses 1MUzngtNnrQRXRqqRTeDmpULW8X1aaGWeR and 1Fufjpf9RM2aQsGedhSpbSCGRHrmLMJ7yY are coinjoined because they are both of value 0.01btc.<br />
<br />
Another example is this 3-party coinjoin. https://chain.localbitcoins.com/tx/92a78def188053081187b847b267f0bfabf28368e9a7a642780ce46a78f551ba<br />
<br />
==FAQ==<br />
<br />
===Don't you need tor or something to prevent everyone from learning everyone's IP?===<br />
<br />
Any transaction privacy system that hopes to hide user's addresses should start with some kind of anonymity network. This is no different. Fortunately networks like Tor, I2P, Bitmessage, and Freenet all already exist and could all be used for this. (Freenet would result in rather slow transactions, however)<br />
<br />
However, gumming up "taint analysis" and reducing transaction sizes doesn't even require that the users be private from each other. So even without things like tor this would be no worse than regular transactions.<br />
<br />
===Don't the users learn which inputs match up to which outputs?===<br />
<br />
In the simplest possible implementation where users meet up on IRC over tor or the like, yes they do. The next simplest implementation is where the users send their input and output information to some meeting point server, and the server creates the transaction and asks people to sign it. The server learns the mapping, but no one else does, and the server still can't steal the coins.<br />
<br />
More complicated implementations are possible where even the server doesn't learn the mapping.<br />
<br />
E.g. Using chaum blind signatures: The users connect and provide inputs (and change addresses) and a cryptographically-blinded version of the address they want their private coins to go to; the server signs the tokens and returns them. The users anonymously reconnect, unblind their output addresses, and return them to the server. The server can see that all the outputs were signed by it and so all the outputs had to come from valid participants. Later people reconnect and sign.<br />
<br />
Similar things can be accomplished with various zero-knowledge proof systems.<br />
<br />
===Does the totally private version need to have a server at all? What if it gets shut down?===<br />
<br />
No. The same privacy can be achieved in a decentralized manner where all users act as blind-signing servers. This ends up needing n^2 signatures, and distributed systems are generally a lot harder to create. I don't know if there is, or ever would be, a reason to bother with a fully distributed version with full privacy, but it's certainly possible.<br />
<br />
===What about DOS attacks? Can't someone refuse to sign even if the transaction is valid?===<br />
<br />
Yes, this can be DOS attacked in two different ways: someone can refuse to sign a valid joint transaction, or someone can spend their input out from under the joint transaction before it completes.<br />
<br />
However, if all the signatures don't come in within some time limit, or a conflicting transaction is created, you can simply leave the bad parties and try again. With an automated process any retries would be invisible to the user. So the only real risk is a persistent DOS attacker.<br />
<br />
In the non-decentralized (or decentralized but non-private to participants) case, gaining some immunity to DOS attackers is easy: if someone fails to sign for an input, you blacklist that input from further rounds. They are then naturally rate-limited by their ability to create more confirmed Bitcoin transactions.<br />
<br />
Gaining DOS immunity in a decentralized system is considerably harder, because it's hard to tell which user actually broke the rules. One solution is to have users perform their activity under a zero-knowledge proof system, so you could be confident which user is the cheater and then agree to ignore them.<br />
<br />
In all cases you could supplement anti-DOS mechanisms with proof of work, a fidelity bond, or other scarce resource usage. But I suspect that it's better to adapt to actual attacks as they arise, as we don't have to commit to a single security mechanism in advance and for all users. I also believe that bad input exclusion provides enough protection to get started.<br />
<br />
===Isn't the anonymity set size limited by how many parties you can get in a single transaction?===<br />
<br />
Not quite. The anonymity set size of a single transaction is limited by the number of parties in it, obviously. And transaction size limits as well as failure (retry) risk mean that really huge joint transactions would not be wise. But because these transactions are cheap, there is no limit to the number of transactions you can cascade.<br />
<br />
In particular, if you have can build transactions with m participants per transaction you can create a sequence of m*3 transactions which form a three-stage [http://en.wikipedia.org/wiki/Clos_network switching network] that permits any of m^2 final outputs to have come from any of m^2 original inputs (e.g. using three stages of 32 transactions with 32 inputs each 1024 users can be joined with a total of 96 transactions). This allows the anonymity set to be any size, limited only by participation.<br />
<br />
In practice I expect most users only want to prevent nosy friends (and thieves) from prying into their financial lives, and to recover some of the privacy they lost due to bad practices like address reuse. These users will likely be happy with only a single pass; other people will just operate opportunistically, while others may work to achieve many passes and big anonymity sets. All can coexist.<br />
<br />
===How does this compare to [http://zerocoin.org/ zerocoin]?===<br />
<br />
As a crypto and computer science geek I'm super excited by Zerocoin: the technology behind it is fascinating and important. But as a Bitcoin user and developer the promotion of it as the solution to improved privacy disappoints me.<br />
<br />
Zerocoin has a number of serious limitations: <br />
* It uses cutting-edge cryptography which may turn out to be insecure, and which is understood by relatively few people (compared to ECDSA, for example).<br />
* It produces large (20kbyte) signatures that would bloat the blockchain (or create risk if stuffed in external storage).<br />
* It requires a trusted party to initiate its accumulator. If that party cheats, they can steal coin. (Perhaps fixable with more cutting-edge crypto.)<br />
* Validation is very slow (can process about 2tx per second on a fast CPU), which is a major barrier to deployment in Bitcoin as each full node must validate every transaction.<br />
* The large transactions and slow validation also means costly transactions, which will reduce the anonymity set size and potentially make ZC usage unavailable to random members of the public who are merely casually concerned about their privacy.<br />
* Uses an accumulator which grows forever and has no pruning. In practice this means we'd need to switch accumulators periodically to reduce the working set size, reducing the anonymity set size. And potentially creating big UTXO bloat problems if the horizon on an accumulator isn't set in advance.<br />
<br />
Some of these things may improve significantly with better math and software engineering over time.<br />
<br />
But above all: '''Zerocoin requires a soft-forking change to the Bitcoin protocol''', which all full nodes must adopt, which would commit Bitcoin to a particular version of the Zerocoin protocol. This cannot happen fast—probably not within years, especially considering that there is so much potential for further refinement to the algorithm to lower costs. It would be politically contentious, as some developers and Bitcoin businesses are very concerned about being overly associated with "anonymity". Network-wide rule changes are something of a suicide pact: we shouldn't, and don't, take them lightly.<br />
<br />
'''CoinJoin transactions work today''', and they've worked since the first day of Bitcoin. They are indistinguishable from normal transactions and thus cannot be blocked or inhibited except to the extent that any other Bitcoin transaction could be blocked.<br />
<br />
(As an aside: ZC could potentially be used externally to Bitcoin in a decentralized CoinJoin as a method of mutually blinding the users in a DOS attack resistant way. This would allow ZC to mature under live fire without taking its costs or committing to a specific protocol network-wide.)<br />
<br />
The primary argument I can make for ZC over CoinJoin, beyond it stoking my crypto-geek desires, is that it may potentially offer a larger anonymity set. But with the performance and scaling limits of ZC, and the possibility to construct sorting network transactions with CJ, or just the ability to use hundreds of CJ transactions with the storage and processing required for one ZC transactions, I don't know which would actually produce bigger anonymity sets in practice. E.g. To join 1024 users, just the ZC redemptions would involve 20k * 1024 bytes of data compared to less than 3% of that for a complete three-stage cascade of 32 32-way joint transactions. Though the ZC anonymity set could more easily cross larger spans of time.<br />
<br />
The anonymity sets of CoinJoin transactions could easily be big enough for common users to regain some of their casual privacy and that's what I think is most interesting.<br />
<br />
===How does this compare to [https://bitcointalk.org/index.php?topic=277389.0 CoinWitness]?===<br />
<br />
CoinWitness is even rocket-sciency than Zerocoin, it also shares many of the weaknesses as a privacy-improver: Novel crypto, computational cost, and the huge point of requiring a soft fork and not being available today. It may have some scaling advantages if it is used as more than just a privacy tool. But it really is overkill for this problem, and won't be available anytime real soon.<br />
<br />
===Sounds great! Where is it?===<br />
<br />
Theres the rub: There exist no ready made, easy-to-use software for doing this. You can make the transactions by hand using bitcoin-qt and the raw transactions API, as we did in that "taint rich" thread, but to make this into a practical reality we need easy-to-use automated tools.<br />
<br />
Luke has written up some [https://gist.github.com/luke-jr/5409899 sketches a protocol] which would enable establishing joint transactions over the regular Bitcoin network.<br />
<br />
The Bitcoin-qt RPC system provides everything someone needs to write a side-car applet (including the ability to lock txouts to prevent them from being spent out from from under it) that participants in such a system. But the fact that so many users use centralized webwallets today which can spy on them will ultimately limit the userbase for these tools.<br />
<br />
Personally, most of my coding brain capacity is spent on other things which are even more important to me. And what I could spare on Bitcoin is spent on more core and security things— if I work on anything wallet related anytime soon it will likely be improving the privacy behavior of coin selection... But moreover:<br />
<br />
Anyone who builds this is going to be accused of enabling criminal activity, it doesn't matter if any actual criminals use this or not: Criminal activity sells headlines. Being a Bitcoin core developer already fills my quota for accusations of this kind, especially my quota for risk that I'm not even paid for. :)<br />
<br />
In reality, real criminals don't need CoinJoin if they have even the slightest clue: They can afford to buy privacy in a way that regular users cannot, it's just a cost of their (often lucrative) business.<br />
<br />
Joe-criminal can go out and buy 120% PPS mining to get brand new coins, or run his money through a series of semi-sham high cashflow gambling businesses for a 50% cut, they can afford the cost of seeking out and interfacing with these seedy services... Joe and Jane doe? Their names are up in neon on blockchain.info. It might not seem great to them, but if there a high cost of fixing it they simply won't, because the cost of fixing it is very concrete and the cost or privacy loss is speculative and distant. They might just need to give up bitcoin and switch to something almost totally private: cash... Regular users need efficient and inexpensive privacy if it is to help them at all.<br />
<br />
I know that making such a tool doesn't fit into the get-rich-quick mold of many Bitcoin businesses, but the importance is self-apparent and the simplest versions of this don't require very deep technical wizardry. I think the "political" risk of improving people's privacy is a real one that you should carefully consider, but around these parts I see people sticking their names on some rather outrageously risky stuff. I'd hoped the "taint rich" thread would be enough to inspire some community action, but perhaps this will be.<br />
<br />
==See Also==<br />
* [[User:Gmaxwell/state_of_coinjoin]]<br />
<br />
==References==<br />
<references><br />
</references></div>Hardinghttps://en.bitcoin.it/w/index.php?title=IP_transaction&diff=65123IP transaction2018-03-26T17:08:34Z<p>Harding: Change incorrect information about addresses to refer to public keys; also make clear what humans are doing and what software is doing</p>
<hr />
<div>Sending bitcoins to an IP address was a convenient way of sending bitcoins to a Bitcoin address along with additional information.<br />
<br />
* Your client contacts the IP address to find out if they're actually running Bitcoin and accepting IP transactions. If not, no transaction occurs.<br />
* Your additional information ("from", "message", etc.) is exchanged with the server.<br />
* The server generates a brand new Bitcoin public key and sends it to your client.<br />
* Your client sends coins to this public key.<br />
<br />
Unfortunately, the implementation provided no authentication, so any "man in the middle" could have intercepted your bitcoins during the transaction. When they see that you're sending a Bitcoin payment by IP address, they pretend to be the actual destination and send back ''their'' Bitcoin address. You end up sending bitcoins to the wrong person. It's therefore no longer a good idea to send bitcoins in this way, ''especially'' if you're using a proxy.<br />
<br />
==Status==<br />
This feature has been removed from Bitcoin Core as-of v0.8.0<ref>[http://bitcointalk.org/index.php?topic=9334.0 Remove send to IP address and IP transactions support]</ref><br />
<br />
==References==<br />
<references /><br />
<br />
[[Category:Technical]]</div>Hardinghttps://en.bitcoin.it/w/index.php?title=Block_size_limit_controversy&diff=65095Block size limit controversy2018-03-19T12:34:07Z<p>Harding: Formatting fix: remove unused '[' and ']' from around external links</p>
<hr />
<div>{{see also|Scalability FAQ}}<br />
In 2010, a block size limit of 1 MB was introduced into Bitcoin by [[Satoshi Nakamoto]]. He added it hidden in two commits<ref>https://www.reddit.com/r/Bitcoin/comments/63859l/github_commit_where_satoshi_added_the_block_size/</ref><ref>[https://github.com/bitcoin/bitcoin/commit/a30b56eb "fix openssl linkage problems"], Sneaky soft-forking UASF commit for MAX_BLOCK_SIZE No. 1.</ref><ref>[https://github.com/bitcoin/bitcoin/commit/a790fa46f40 "don't count or spend payments until they have 1 confirmation"], Sneaky soft-forking UASF commit for MAX_BLOCK_SIZE No. 2.</ref> in secret. The original limit was equivalent to a soft-fork, since prior version of the software would accept the smaller blocks without issue—they were all forward-compatible with this change.<br />
<br />
The limit was not changed again before Nakamoto disappeared and right now is part of bitcoin's consensus rules requiring a very invasive hard fork to change. As transaction volume increased with widespread Bitcoin adoption, increasing the limit became subject to heavy debate in 2015. To prevent Bitcoin from temporarily or permanently splitting into separate payment networks ("altcoins"), hard forks require adoption by nearly all [[Full node#Economic_strength|economically active]] full nodes.<br />
<br />
According to a second-party (theymos,) Satoshi told people who discovered the new 1MB limit to "keep quiet" about it until the change was complete, in order to reduce controversy during the transition.<ref>[https://www.reddit.com/r/Bitcoin/comments/3giend/citation_needed_satoshis_reason_for_blocksize/ctygzmi/ theymos explaining his experience with Satoshi keeping the 1MB change quiet]</ref> The only evidence which asserts that the blocksize limit was an anti-DoS measure was a post from user Cryddit (Ray Dillinger) in 2015 which asserted that he was involved in the discussion itself and that the limit was there at launch..<ref>[https://bitcointalk.org/index.php?topic=946236.msg10388435#msg10388435 Cryddit in 2015 stating he went over the first cut with Satoshi, and that the 1MB limit was there by the time Bitcoin launched.]</ref> As per the secret commits, though, the limit was not added until July 14, 2010, which was a full 1.5 years ''after'' its launch.<br />
<br />
== Arguments in favor of increasing the blocksize ==<br />
* More transactions per second<br />
* Off-chain solutions are not yet ready to take off the load from the main blockchain.<br />
<br />
== Contentions ==<br />
* Increased blocksize will leave space for extensions like Mastercoin, Counterparty, etc.<br />
** Neutral: Bitcoin competitors will have lower fees<br />
** Negative: Bitcoin full nodes are forced to use more resources that don't support Bitcoin<br />
* Small blocks eventually will require higher fees for fast confirmations.<br />
** Positive: It will no longer be cheap to spam transactions such as Satoshi Dice bets<br />
** Positive: Fees will not be zero. This is eventually a necessity in order to incentivize miners and secure the mining ecosystem<br />
** Negative: Bitcoin may look unattractive to new users with high fees<br />
** Negative: High fees may stop or reverse global adoption, investment, development, support and centralization{{clarification needed}}<br />
** Negative: Bitcoin users pay higher fees<br />
* A low blocksize limit encourages higher transactions fees to incentivize miners ("let a fee market develop"). <br />
** A fee market naturally develops due to miner latency regardless<ref>https://dl.dropboxusercontent.com/u/43331625/feemarket.pdf A Transaction Fee Market Exists Without a Block Size Limit</ref><br />
*** The relay network can be optimized so that miners don't have a stale rate increasing with latency. This should cause the fee market to once again require a block size limit to exist.<br />
<br />
== Arguments in opposition to increasing the blocksize ==<br />
* A hard fork requires waiting for sufficient consensus.<br />
* Risk of catastrophic consensus failure<ref>https://www.mail-archive.com/bitcoin-development@lists.sourceforge.net/msg08276.html</ref>{{clarification needed}}<br />
* An emergency hard fork that can achieve consensus can be deployed on a short time period if needed.<ref>[https://www.reddit.com/r/Bitcoin/comments/392m43/mike_hearn_blocksize_debate_at_the_breaking_point/cs00wdd How to raise block size in a short time], Peter Todd, Reddit /r/Bitcoin, 9 June 2015</ref><br />
* Orphan rate amplification, more reorgs and double-spends due to slower propagation speeds.<br />
* European/American pools at more of a disadvantage compared to the Chinese pools{{why}}<br />
* "Congestion" concerns can be solved with mempool improvements including transaction eviction.<br />
* No amount of max block size would support all the world's future transactions on the main blockchain (various types of off-chain transactions are the only long-term solution)<br />
* Fast block propagation is either not clearly viable, or (eg, IBLT) creates centralised controls.<br />
<br />
=== Damage to decentralization ===<br />
* Larger blocks make full nodes more expensive to operate.<br />
* Therefore, larger blocks lead to less hashers running full nodes, which leads to centralized entities having more power, which makes Bitcoin require more trust, which weakens Bitcoins value proposition.<br />
* Bitcoin is only useful if it is decentralized because centralization requires trust. Bitcoins value proposition is trustlessness.<br />
* The larger the hash-rate a single miner controls, the more centralized Bitcoin becomes and the more trust using Bitcoin requires.<br />
* Running your own full node while mining rather than giving another entity the right to your hash-power decreases the hash-rate of large miners. Those who have hash-power are able to control their own hash power if and only if they run a full node.<br />
* Less individuals who control hash-power will run full nodes if running one becomes more expensive<ref>https://www.weusecoins.com/why-blocksize-limit-keeps-bitcoin-free-decentralized/</ref>.<br />
<br />
==History==<br />
On October 3, 2010, [[Jeff Garzik]] published a patch that immediately increases the block size to 7MB.<ref>{{cite btct|id=1347|title=(PATCH) increase block size limit|date=2010-10-03}}</ref> The patch had no users, but it was the earliest attempt at increasing the block size through a hardfork. Satoshi and theymos immediately said not to implement it, as it would make the user's node incompatible with the network.<ref name="dontuse">[https://bitcointalk.org/index.php?topic=1347.msg15139#msg15139 "+1 theymos. Don't use this patch"] Satoshi explains here that ''if'' a change is necessary, a hard fork ''could'' be implemented with a countdown.</ref> This is the oft-cited post which many people claim proves Satoshi intended for the blocksize to increase. English, however, does not work that way. Satoshi spoke conditionally, not intentionally.<ref name="dontuse" /><br />
===BIP 100===<br />
Change block size limit based on miner votes, but don't leave the range (1MB, 32MB) without a softfork or hardfork respectively.<br />
===Bitcoin XT===<br />
[[File:xt.png|thumb|128px|Bitcoin XT logo]]{{main|Bitcoin XT}}<br />
Bitcoin XT was an alternative client that became notorious when it adopted BIP 101, which would direct an increase to 8 MB after both January 11, 2016 has passed and 75% of miners are in support, followed by doubling of the limit every two years with the size increasing linearly within those two year intervals.<br />
<br />
XT failed to gain enough support to activate the hardfork, leading to Mike Hearn's resignation.<br />
===BIP 102===<br />
Increase to 2 MB on November 11, 2015.<br />
===BIP 103===<br />
Increase by 17.7% annually until 2063.<br />
===Bitcoin Classic===<br />
{{main|Bitcoin Classic}}<br />
Adopt BIP 109 and hardfork to 2 MB in 2016. Dynamic max_block_size in 2017.<br />
===Segregated Witness===<br />
[[File:segwit.png|thumb|128px|SegWit logo]]{{main|Segregated Witness}}<br />
Move signature data out of the 1 MB block and into a separate witness structure via a softfork, effectively raising the block capacity to 1.4 MB of transactions.<br />
<br />
== Entities positions ==<br />
Positions below are based on a suggested fixed block size increase to 20MiB. Positions against these larger blocks do not necessarily imply that they are against an increase in general, and may instead support a smaller and/or gradual increase.<br />
{| class="wikitable sortable"<br />
! Entity<br />
! Supports Larger Blocks<br />
! Supports Hard Fork<br />
|-<br />
| [[Magnr]]<br />
| {{Yes|Yes: "We believe an immediate 2mb blocksize increase is important and urgently required to enable Bitcoin to flourish and deliver more utilitarian use to more people all across the world."}}<ref>https://github.com/bitcoinclassic/website/issues/3#issuecomment-172678154</ref><br />
| {{Yes|Yes: "We support the Bitcoin Classic proposal<ref>https://bitcoinclassic.com</ref>."}} - Magnr<ref>https://twitter.com/magnr/status/689227046120222721</ref><br />
|-<br />
| Bitcoinpaygate<br />
| {{No|No: "We do NOT support the blocksize increase"}}<ref>http://www.reddit.com/r/Bitcoin/comments/37y8wm/list_of_bitcoin_services_that_supportoppose/crqsnqp</ref><br />
|<br />
|-<br />
| Bitrated<br />
| {{No}}<br />"At this time, I oppose increasing the block size limit as per Gavin's proposal" - Nadav Ivgi (founder)<ref>https://twitter.com/shesek/status/605005384026177537</ref><br />
|<br />
|-<br />
| [[GreenAddress]]<br />
| {{No|No: "In our mind increasing the block size like this is just pushing the problem a little further at potentially unfixable costs."}}<ref>http://www.reddit.com/r/Bitcoin/comments/35anax/list_of_bitcoin_services_that_support_increasing/cr2mq84</ref><br />
|<br />
|-<br />
| [[MPEx]]<br />
| {{No}}<ref>http://log.bitcoin-assets.com//?date=07-01-2015#967332</ref><br />
|<br />
|-<br />
| [[Paymium]]<br />
| {{No|No: "<nowiki>[allow]</nowiki> a sane transaction fee market to emerge, by letting the blocks actually fill-up."}} - CTO David Francois<ref>http://fr.anco.is/2015/gavineries/</ref><br />
| <br />
|-<br />
| Ethereum<br /><br />
| {{Neutral|Neutral: "If <nowiki>[the niche of digital gold]</nowiki> is what Bitcoin users want, then they should keep the limit, and perhaps even decrease it. But if Bitcoin users want to be a payment system, then up it must go."}} - Vitalik Buterin (founder)<ref>http://www.reddit.com/r/ethereum/comments/380q61/i_know_this_may_not_directly_be_ethereum_related/crrofl6</ref><br />
|<br />
|-<br />
| [[F2Pool]]<br />
| {{Neutral|Neutral: "We do support bigger blocks and sooner rather than later. But we cannot handle 20 MB blocks right now. ... I think we can accept 5MB block at most."}}<ref>http://sourceforge.net/p/bitcoin/mailman/message/34157036/],[http://sourceforge.net/p/bitcoin/mailman/message/34158911/</ref><br />
|<br />
|-<br />
| [[Armory]]<br />
| {{Yes}}<br />"This *is* urgent and needs to be handled right now, and I believe Gavin<br />
has the best approach to this." - CEO Alan Reiner<ref>http://sourceforge.net/p/bitcoin/mailman/message/34093337/</ref><br />
|<br />
|-<br />
| BitcoinReminder<br />
| {{Yes|Yes: "BitcoinReminder.com also supports 20MB blocks (or even more?"}}<ref>http://www.reddit.com/r/Bitcoin/comments/37y8wm/list_of_bitcoin_services_that_supportoppose/crs9ytd</ref><br />
|<br />
|-<br />
| BitHours<br />
| {{Yes|Yes: "We support @gavinandresen and his proposal for 20mb blocks"}}<ref>https://twitter.com/bithours/status/605131647747358721</ref><br />
|<br />
|-<br />
| [[BitPay]]<br />
| {{Yes}}<br />"Agreed (but optimistic this will be the last and only time block size needs to increase)" - CEO Stephen Pair<ref>https://twitter.com/spair/status/595341090317799424</ref><br />
| {{Yes|Yes: "In summary, we believe BIP 101 will safeguard Bitcoin’s decentralized nature while providing a reliable, immediate path toward greater network throughput, and we would like to express our support for merging BIP 101 into Bitcoin Core."}} - Stephen Pair<ref>https://medium.com/@spair/increasing-the-block-size-limit-85ff236fc516</ref><br />
|-<br />
| Bittiraha.fi<br />
| {{Yes|Yes: "We are supporting increasing #Bitcoin max block size to 20MB."}}<ref>https://twitter.com/Bittirahafi/status/596682373028311040</ref><br />"I'm strongly in favor of the block size cap increase to 20MB." - CEO Henry Brade<ref>https://twitter.com/Technom4ge/status/596334370803326978</ref><br />
| {{Yes}}<br />"And I'm in favor of releasing a version with this change even with opposition." - CEO Henry Brade<ref>https://twitter.com/Technom4ge/status/596334370803326978</ref><br />
|-<br />
| [[Blockchain.info]]<br />
|{{Yes}}<br />"It is time to increase the block size. Agree with @gavinandresen" - CEO Peter Smith<ref>https://twitter.com/OneMorePeter/status/595676380320407553</ref><br />"Scaling #bitcoin is a big deal. Increase the block size." - Nic Cary<ref>https://twitter.com/niccary/status/595707211994763264</ref><br />
|<br />
|-<br />
| [[Blocktrail]]<br />
|{{Yes}}<br />"We'd love to see BIP101 with 4mb start, alternatively BIP100 with something to deal with the 21% attack could be good too."<ref>https://blog.blocktrail.com/2015/08/miners-block-size-vote-explained/</ref><br /><br />
|<br />
|-<br />
| Breadwallet<br />
| {{Yes}}<br />"[...] in support of the Gavin's 20Mb block proposal." - CEO Aaron Voisine<ref>http://sourceforge.net/p/bitcoin/mailman/message/34096857/</ref><br />
|<br />
|-<br />
| [[BTC Guild]]<br />
<br />
| {{Yes}}<br />"Needs to happen, but needs future expansion built in at a reasonable rate." - Eleuthria<ref>https://www.reddit.com/r/Bitcoin/comments/370rko/21_inc_engineer_everyone_assumes_humans_will_be/crjfnpg?context=3</ref><br />
|<br />
|-<br />
| BX.in.th<br />
| {{Yes|Yes: "<nowiki>http://BX.in.th</nowiki> will support the 20MB block size"}}<ref>https://twitter.com/BitcoinThai/status/605022509101023232</ref><br />
| <br />
|- <br />
| [[Coinbase (business)|CoinBase]]<br />
| {{Yes|Yes: "Coinbase supports increasing the maximum block size"}}<ref>https://twitter.com/coinbase/status/595741967759335426</ref><br />"Why we should increase the block size" - CEO Brian Armstrong<ref>https://twitter.com/brian_armstrong/status/595453245884997634</ref><br />
| {{Yes|Yes: "5/ hard forks probably shouldn't happen frequently, but periodically they are an elegant solution that helps bitcoin keep growing"}} - CEO Brian Armstrong<ref>https://twitter.com/brian_armstrong/status/633309671994998784</ref><br />
|- <br />
| [[Coinify]]<br />
| {{Yes}}<br />"We see Bitcoin XT as the best solution for ensuring the future scalability of the Bitcoin network." - CTO Hamed Sattari<ref>https://news.coinify.com/coinify-supports-bitcoin-xt-scalability-bitcoin-payments/</ref><br />
|<br />
|-<br />
| [[Adam Back]]<br />
| {{Yes|Yes: "For the record I am not aware of a single person who has said they do not agree with scaling Bitcoin. Changing a constant is not the hard-part. The hard part is validating a plan and the other factors that go into it. It's not a free choice it is a security/scalability tradeoff. No one will thank us if we "scale" bitcoin but break it in hard to recover ways at the same time."}} <ref>https://www.mail-archive.com/bitcoin-development@lists.sourceforge.net/msg08276.html</ref><br />
| {{No}}<br />"I strongly urge that we return to the existing collaborative constructive review process that has been used for the last 4 years which is a consensus by design to prevent one rogue person from inserting a backdoor, or lobbying for a favoured change on behalf of a special interest group, or working for bad actor" - Dr. Adam Back<ref>https://www.mail-archive.com/bitcoin-development@lists.sourceforge.net/msg08276.html</ref><br />
|<br />
|-<br />
| Kryptoradio<br />
| {{Yes}}<br />"#Kryptoradio dev @zouppen supports 20MB block size in #bitcoin." - Joel Lehtonen<ref>https://twitter.com/koodilehto/status/596675967667568641</ref><br />
|<br />
|- <br />
| [[OKCoin]]<br />
| {{Yes|Yes: "OKCoin's tech team believes it's the right decision"}}<ref>https://twitter.com/okcoinbtc/status/598412795240009728</ref><br />
|<br />
|-<br />
| [[Third Key Solutions]]<br />
| {{Yes}}<br />"Gavin is right. The time to increase the block size limit is before transaction processing shows congestion problems." - CTO Andreas Antonopoulos<ref>https://twitter.com/aantonop/status/595601619581964289</ref><br />
|<br />
|-<br />
| [[Xapo]]<br />
| {{Yes|Yes: "One meg is not enough: Xapo supports increasing the maximum block size"}} - CEO Wences Casares<ref>https://twitter.com/wences/status/595768917907402752</ref><br />
|<br />
|}<br />
<br />
==References==<br />
<references/><br />
[[Category:2015 events]]</div>Hardinghttps://en.bitcoin.it/w/index.php?title=Techniques_to_reduce_transaction_fees&diff=64947Techniques to reduce transaction fees2018-01-29T18:54:13Z<p>Harding: Fixed change percentage; previously did y/x-1; should've done 1-x/y. Thanks instagibbs for reporting</p>
<hr />
<div>This page provides a list of currently-available techniques that may allow spenders to reduce the amount of [[transaction fee]] they pay. Not all techniques will apply to all situations, and some techniques require trading off other benefits for lower fees.<br />
<br />
When you reduce the fee you pay, you almost always reduce the fees other users have to pay also. For high-frequency spenders, this effect can be large and can provide significant additional second order savings. For example, If an organization is creating 10% of all transactions and begins making transactions 50% more efficiently, an additional 5% of block space is freed up for all users of Bitcoin. This would be expected to lower fees by some amount (likely more than 5%), providing a second order of savings on top of the first-order savings of 50%.<br />
<br />
''Note, this page only describes techniques that apply to payment-oriented transactions. Data carrier transactions (e.g. [[OP_RETURN]] or [[OpenTimestamps]]), [[colored coin]] protocols, and other proposed uses of Bitcoin transactions may benefit from some of the following techniques, but the recommendations are not aimed at those use cases.''<br />
<br />
== Efficiency improvements ==<br />
<br />
Creating transactions that are smaller in size ([[Weight units|weight]]), or which accomplish more for a given size, provide a more efficient way of using scarce block space and so pay less total fee to achieve a [[Transaction fees#feerates|feerate]] that is equivalent to less efficient payments. This section describes several techniques for producing more efficient transactions.<br />
<br />
Technically ''offchain payments'' such as those made in [[payment channels]] are a type of extremely efficient payment and so belong to this category, but they've been given a separate category because of the distinctive way they achieve their high efficiency.<br />
<br />
=== Compressed public keys ===<br />
<br />
''Universally useful but already widely deployed''<br />
<br />
The original Bitcoin software released in 2009 used 65-byte uncompressed public keys to identify the owner of a set of bitcoins. In 2012, Bitcoin protocol developer Pieter Wuille implemented a change to the program now known as Bitcoin Core that allowed it to use 33-byte compressed public keys instead.<ref>[https://bitcoin.org/en/release/v0.6.0#new-features-since-bitcoin-version-05 Bitcoin Core 0.6.0 release notes], Bitcoin.org, 2012-03-20, retrieved 2018-01-27</ref> As Bitcoin Core users adopted this feature and other wallets upgraded to use it as well, this reduced the size of a typical transaction on the network (with one input and two outputs) from about 258 bytes to about 226 bytes, a 14% savings.<br />
<br />
[[File:Uncompressed-pubkey-percentage.png|center|800px|thumb|The percentage of transaction inputs per block using the old uncompressed pubkey format in their scriptSigs. Note: early Bitcoin transactions often placed pubkeys in their scriptPubKeys rather than their scriptSigs.]]<br />
<br />
The change was fully backwards compatible and did not change security in any way, but it did require users wanting to access the space savings to generate new Bitcoin addresses.<br />
<br />
Since 2012, many wallets have adopted compressed public keys—but still some wallets continue to use the less efficient uncompressed public keys. These wallets could achieve a significant savings in transaction fees for the same priority by switching to compressed public keys. If all wallets adopted it, this would effectively lead to a small increase in the available block space:<br />
<br />
[[File:Uncompressed-pubkey-savings.png|center|800px|thumb|The percentage of the maximum available block space consumed by the extra bytes in uncompressed pubkeys]]<br />
<br />
See also:<br />
<br />
* [https://bitcoin.org/en/developer-guide#public-key-formats Compressed public keys] — Bitcoin.org Developer Guide<br />
* [https://bitcoin.org/en/release/v0.6.0#new-features-since-bitcoin-version-05 Bitcoin Core 0.6.0 release notes]<br />
* [https://github.com/bitcoin/bips/blob/master/bip-0143.mediawiki#Restrictions_on_public_key_type BIP143] - Requires all pubkeys in [[segregated witness]] witnesses be compressed pubkeys<br />
<br />
=== Payment batching ===<br />
<br />
''Very useful for high-frequency spenders (e.g. organizations); moderately useful for lower-frequency spenders (e.g. individuals)''<br />
<br />
Every Bitcoin transaction must reference the funds being spent and provide proof that the transaction was authorized by the owner of those funds. To spend a single collection of funds takes a minimum of 79 vbytes under normal circumstances. This same amount of block space is used no matter how many recipients are paid in that transaction. For example, consider the following two scenarios:<br />
<br />
* Alice pays Bob in one transaction and then pays Charlie in a second transaction. Each transaction contains a minimum of 79 vbytes related to the funds being spent—a total of 158 vbytes.<br />
* Alice uses a single transaction to pay both Bob and Charlie. The single transaction only needs one set of 79 vbytes related to the funds being spent—a savings of 50% for this field.<br />
<br />
This type of savings increases as more payments are added to a single transaction until the cost per payment is just barely more than the cost of adding the vbytes directly related to that payment in the transaction. The plot below shows the cost per payment for a native segwit [[P2WPKH]] transaction paying other P2WPKH outputs:<br />
<br />
[[File:Batching.png|center]]<br />
<br />
We see the cost drop by more than 50% after five payments are added, with the savings increasing up to about 70% for segwit transactions. Not shown is that the savings increase up to about 80% for legacy transactions because these transactions start off less efficient than segwit transactions. That's a major benefit and one that's easily obtainable by high-frequency spenders, such as organizations.<br />
<br />
Many wallets support batching payments. In graphical wallets, there's often a button that allows you add additional recipients to a transaction (see image below). In command-line and RPC wallets, there's often a call such as <code>sendmany</code> that lets you pay multiple recipients.<br />
<br />
[[File:Bitcoin-core-add-recipient.png|thumb|200px|right|Add Recipient button in Bitcoin Core 0.15.0]]<br />
<br />
Note that there are other parts of a transaction that stay a constant size (or nearly so) when payments are added, so the benefits stack up faster than a fixed cost of just 79 vbytes might suggest. The section below about ''change avoidance'' addresses how one of these cases can itself be eliminated as a cost.<br />
<br />
See also:<br />
<br />
* [https://bitcointechtalk.com/saving-up-to-80-on-bitcoin-transaction-fees-by-batching-payments-4147ab7009fb Saving up to 80% on Bitcoin transaction fees by batching payments]<br />
* [https://bitcoin.org/en/developer-reference#sendmany SendMany RPC] - Bitcoin.org Developer Reference<br />
<br />
=== P2SH-wrapped segwit ===<br />
<br />
''Universally useful''<br />
<br />
Transactions that spend bitcoins secured by [[segregated witness]] (segwit) use less space in a block than equivalent non-segwit (legacy) transactions, allowing segwit transactions to pay less total fee to achieve the same [[Transaction fees#feerates|feerate]] as legacy transactions. The amount of savings varies depending on the details of your transaction, but here are a few common transaction types an an example:<br />
<br />
{|<br />
! Type<br />
! Legacy vbytes<br />
! P2SH-wrapped<br>segwit vbytes<br />
! Savings<br />
|-<br />
| Single signature<br />
| 226<br />
| 167<br />
| 26%<br />
|-<br />
| 2-of-2 multisig<br />
| 335<br />
| 197<br />
| 41%<br />
|-<br />
| 2-of-3 multisig<br />
| 369<br />
| 206<br />
| 44%<br />
|}<br />
<br />
Note that the multisig examples above use the same security as the equivalent legacy P2SH multisig. Segwit optionally allows access to a multisig form that is more secure on one dimension but it requires an extra 12 vbytes per output, which would reduce efficiency somewhat.<br />
<br />
To access these savings, you must use a wallet that supports generating P2SH-wrapped segwit addresses (addresses that start with a "3", although not all addresses that start with a 3 are segwit-enabled). When you spend bitcoins received to these P2SH-wrapped segwit addresses, your transactions will automatically consume less block space, allowing your wallet to pay proportionally less fee.<br />
<br />
See also:<br />
<br />
* [[Segregated Witness]]<br />
* [https://bitcoincore.org/en/segwit_wallet_dev/ Segregated Witness Wallet Development Guide] - BitcoinCore.org<br />
* [https://bitcoincore.org/en/segwit_adoption/ List of wallets, libraries, and services that support segwit] - BitcoinCore.org<br />
<br />
=== Native segwit ===<br />
<br />
''Universally useful. Complete usage requires native segwit adoption by the people sending you bitcoins, but you may be able to use it for your [[change outputs]] immediately''<br />
<br />
The P2SH-wrapped segwit described above is backwards compatible with the P2SH address format supported by older wallets, but a new and non-backwards compatible format is available that saves additional space. The following examples and savings are compared to the size of the P2SH-wrapped examples above:<br />
<br />
{|<br />
! Type<br />
! P2SH-wrapped<br>segwit vbytes<br />
! Native segwit<br>vbytes<br />
! Additional<br>savings<br />
|-<br />
| Single signature<br />
| 167<br />
| 141<br />
| 16%<br />
|-<br />
| 2-of-2 multisig<br />
| 197<br />
| 169<br />
| 14%<br />
|-<br />
| 2-of-3 multisig<br />
| 206<br />
| 178<br />
| 14%<br />
|}<br />
<br />
To access these savings, you must use a wallet that supports generating native segwit addresses, called [[bech32]] addresses (addresses that start with a "bc1"). When you spend bitcoins received to these native segwit addresses, your transactions will automatically consume less block space than even P2SH-wrapped segwit addresses, allowing your wallet to pay proportionally less fee.<br />
<br />
Once a wallet supports native segwit, it can begin using it immediately for any [[change outputs]] it generates back to itself without waiting for anyone else to begin using native segwit. In early 2018, when native segwit adoption is low, this may make it easier to identify which output is change and so reduce your privacy. However, once native segwit adoption increases just slightly, this is not expected to adversely affect privacy.<br />
<br />
See also:<br />
<br />
* [[Bech32 adoption]]<br />
* [https://github.com/bitcoin/bips/blob/master/bip-0173.mediawiki BIP173] — Bech32 addresses<br />
<br />
=== Change avoidance ===<br />
<br />
''Useful for high-frequency recipients (e.g. organizations), especially those who already effectively use transaction batching''<br />
<br />
When a Bitcoin transaction references the funds it wants to spend, it's required to spend all of those funds. For example, if you received 5 BTC in a previous transaction and now you want to spend 2 BTC, Bitcoin requires that you spend all 5 BTC. For this reason, almost all Bitcoin transactions currently pay some bitcoins back to the spender. For example, you'd return the remaining 3 BTC from the previous example back to yourself. This return of money to yourself is called ''change'' by analogy to the change a store clerk hands you when you (for example) buy a $2 item with a $5 bill.<br />
<br />
A typical change output adds about 32 vbytes to the size of a transaction. If the spender can pay with exact change—that is, doesn't need to refund any change to them self—they can eliminate the change output and generate transactions that are up to 23% smaller. In addition, a change output will later be spent at a typical cost of 69 vbytes or more, but when paying with exact change, this future cost is also avoided.<br />
<br />
To use change avoidance requires having previously received a payment or set of payments that's close to the size of the amount being spent (including the transaction fee). This can be rare in the case of individual user wallets that don't receive many payments to choose from and can't significantly vary the amount of their spending transactions, but for organization wallets that receive many payments and already use payment batching to combine multiple outgoing payments, change avoidance can be an easily-obtainable efficiency improvement.<br />
<br />
The spender doesn't need to match the inputs and outputs of their transaction exactly to Bitcoin's full 10 nanobitcoin precision, but can instead overpay or underpay fees slightly by including inputs that are (respectively) slightly more or slightly less than the desired amount. Even when paying slightly more fees than desired, this can result in savings if the slight increase in fees is still less than would normally be paid for the extra 32 vbytes (or so) for a change output and the typical mininum of 69 vbytes for later spending that output.<ref>[https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2018-January/015606.html Transaction Merging (bip125 relaxation)], Rhavar, bitcoin-dev mailing list, 2018-01-22</ref> When paying slightly lower fees, confirmation of the transaction may be delayed, but current-generation (2018) fee estimates are still inaccurate enough that small differences in feerates may not strongly correlate to delays.<br />
<br />
See also:<br />
<br />
* [http://murch.one/wp-content/uploads/2016/11/erhardt2016coinselection.pdf An Evaluation of Coin Selection Strategies] - Mark Erhardt<br />
* [https://github.com/bitcoin/bitcoin/pull/10637 Bitcoin Core pull request #10,637] - A proposed implementation of Erhardt's "branch and bound" strategy<br />
* [https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2018-January/015606.html Bitcoin-Dev mailing list post] - With good coin selection, I am able to avoid change about ~75% of the time in my simulations..."<br />
<br />
=== Consolidation ===<br />
<br />
''Useful for all wallets but may require users sacrifice some privacy''<br />
<br />
The amount of fee a transaction pays is proportional to its size in [[vbytes]], and one the main contributors to size is the number of [[inputs]] the transaction spends. Each input is a reference to the funds the transaction wants to spend, and when a wallet contains only low-value inputs, it can't create a comparatively higher output paying a recipient without adding many of those inputs to the transaction. Each input adds a minimum of 41 vbytes to the transaction and almost always 69 or more vbytes, so any strategy that reduces the number of inputs is worth considering.<br />
<br />
Given that [[Transaction_fees#The_market_for_block_space|fees vary over time]], one method that can reduce overall fees is input consolidation—combining a set of smaller inputs into a single larger input by spending them from yourself to yourself during a period of time when fees are lower than normal. For example, if your usual target feerate during normal-priced fee periods is 100 nanobitcoins per vbyte and the current feerate is 10 nanobitcoins per vbyte, you could save up to almost 90% on fees by consolidating now before you next need to spend some of those inputs.<br />
<br />
[[File:Consolidation-savings.png|center]]<br />
<br />
Consolidation does come with the overhead of creating the consolidation transaction, which is equal to the cost of spending one input to one output, which is about 110 vbytes for P2WPKH inputs/outputs. Also, if you combine inputs that were originally sent to addresses unconnected to each other, you may reduce your privacy in some cases by making that connection in your consolidation transaction (although it's believed that few people currently manage to spend their inputs in a manner that preserves this element of privacy).<br />
<br />
See also:<br />
<br />
* [[How to cheaply consolidate coins to reduce miner fees]]<br />
<br />
== Intelligent fee selection ==<br />
<br />
When it comes to fees, sending a Bitcoin transaction is similar to mailing a package: you can pay a high fee for fast high-priority service or a lower fee for slower low-priority service. This section describes several techniques for taking advantage of the more affordable low-priority service.<br />
<br />
=== Dynamic fee estimation ===<br />
<br />
''Universally useful. Already widely deployed but still being improved as research and development continues''<br />
<br />
Early Bitcoin wallets often defaulted to paying a fixed fee on every transaction—enough to incentivize a miner to include it but not enough to compete against other transactions seeking confirmation in a [[fee market]]. As blocks have filled, this has changed, and as of early 2018 all widely-used wallets use dynamic fee estimation to select a fee based on the condition of the current fee market.<br />
<br />
[[File:Bitcoin-core-fee-selector.png|thumb|200px|right|Fee selector in Bitcoin Core 0.15.0]]<br />
<br />
However, some fee estimation tools may be better than others, achieving confirmation by the desired time even when paying lower fees. Although data from multiple wallets and fee estimation services can be compared<ref>[https://www.p2sh.info/dashboard/db/fee-estimation Fee Estimation], P2SH.info, retrieved 2018-01-23</ref> and there have been some attempts to compare fee estimation between different wallets,<ref>[https://blog.bitgo.com/the-challenges-of-bitcoin-transaction-fee-estimation-e47a64a61c72 The Challenges of Bitcoin Transaction Fee Estimation], Jameson Lopp, BitGo block, 2017-05-10, retrieved 2018-01-23</ref> there is no known survey of fee estimation quality across a large number of popular wallets as of early 2018.<br />
<br />
In addition, also as of early 2018, some techniques have recently been described that could significantly improve fee estimation, such as factoring current [[mempool]] data into confirmation-based fee estimates.<ref name="mempool-fee-est-slides">[https://scalingbitcoin.org/stanford2017/Day2/Scaling-2017-Optimizing-fee-estimation-via-the-mempool-state.pdf Optimizing fee estimation via the mempool state (slides, PDF)], Karl-Johan Alm, Scaling Bitcoin 2017 (Stanford), 2017-11-05, retrieved 2018-01-23</ref><ref name="mempool-fee-est-video">[https://www.youtube.com/watch?v=QkYXPJMqBNk&feature=youtu.be&t=2033 Optimizing fee estimation via the mempool state (presentation video)], Karl-Johan Alm, Scaling Bitcoin 2017 (Stanford), 2017-11-05, retrieved 2018-01-23</ref><br />
<br />
See also<br />
<br />
* [[Transaction fees]]<br />
* [https://blog.bitgo.com/the-challenges-of-bitcoin-transaction-fee-estimation-e47a64a61c72 The Challenges of Bitcoin Transaction Fee Estimation] - Jameson Lopp<br />
* [https://gist.github.com/morcos/d3637f015bc4e607e1fd10d8351e9f41 High level description Bitcoin Core's fee estimation algorithm] - Alex Morcos<br />
<br />
=== Patient spending ===<br />
<br />
''Very useful for non-urgent transactions. Not useful for urgent transactions''<br />
<br />
Spenders who can patiently wait for their transactions to confirm can take advantage of variations in the [[Transaction fees#feerates|feerate]] necessary to achive confirmation. For example, sometimes several Bitcoin blocks are produced in quick succession, raising the effective supply of block space by several multiples; other times, demand drops off, such as fees on Sunday being on average 20% lower than fees on Friday in Q4 2017<ref>[[Transaction_fees#The_market_for_block_space]], Bitcoin Wiki, retrieved 2018-01-27</ref>. Looking at data from the widely-used fee estimator included in Bitcoin Core, we can see fee savings of 90% or more possible, with around 50% being easily obtainable by many patient spenders.<br />
<br />
[[File:Feerate-estimates.png|center]]<br />
<br />
In the data plotted above, the Bitcoin Core fee estimator suggests that for this sample period the following savings are available:<br />
<br />
{|<br />
! Wait<br />
! Conservative savings<br />
! Economical savings*<br />
|-<br />
| 2 hours<br />
| 5% <br />
| 5%<br />
|-<br />
| 6 hours<br />
| 18%<br />
| 55%<br />
|-<br />
| 12 hours <br />
| 39%<br />
| 55%<br />
|-<br />
| 24 hours (1 day)<br />
| 39% <br />
| 55%<br />
|-<br />
| 48 hours (2 days) <br />
| 47% <br />
| 55%<br />
|-<br />
| 72 hours (3 days) <br />
| 52% <br />
| 55%<br />
|-<br />
| 96 hours (4 days) <br />
| 92% <br />
| 92%<br />
|}<br />
<br />
''* Economical savings have a lower probability of being achieved and are recommended for use with the transaction replacability described in a later section.''<br />
<br />
Although waiting up to four days is impractical for many use cases, there are also many cases where it can be practical. A few examples: moving funds between one's own wallets, [[#Consolidation|consolidating]] many smaller inputs into one larger input that can be more efficiently spent, or payments or remittances to friends or family who trust the spender and so don't need fast confirmation.<br />
<br />
See also:<br />
<br />
* [https://p2sh.info/dashboard/db/fee-estimation P2SH.info] - Fee estimates from multiple sources<br />
* [[Transaction_fees#Fee_Plotting_Sites|Other fee plotting sites]]<br />
<br />
=== Opt-in transaction replacement ===<br />
<br />
''Universally useful, but may cause UI issues in recipient wallets''<br />
<br />
Although not strictly a method for reducing fees by itself, opt-in transaction replacement allows a wallet to update previously-sent transactions with new versions that pay higher fees and, possibly, make other changes to the transaction. The method is also called opt-in Replace-By-Fee (RBF). This technique allows wallets to initially pay lower fees in case there's a sudden increase in the supply of block space, a sudden decrease in demand for that space, or another situation that increases the chance of low-fee transactions being confirmed. If none of those things happens, the spender can then increase ("bump") the transaction's fee to increase its probability of confirming.<br />
<br />
This often allows wallets that support transaction replacement to pay lower fees than wallets that don't support replacement.<br />
<br />
Transaction replacement can appear odd in some recipient wallets. Wallets such as Bitcoin Core (pictured below) show each replacement as a separate payment in the list of transactions. When one version of the replacements is confirmed, it is shown as a normal transaction; the other versions are then shown with an X icon to indicate that they are [[conflicted]] (cannot occur together in the same valid block chain). This helps communicate the status of all affected payments to the recipient, but it may not be entirely clear what's happening to users who aren't familar with replacements. Other wallets may not show transactions opting in to replacement at all until one version of the transaction has been confirmed. There's no clear community consensus on the correct way to handle this situation using user interfaces, documentation, or both.<br />
<br />
[[File:Fee-bump-ux.png|thumb|right|200px|List of transaction replacements in Bitcoin Core 0.15.0]]<br />
<br />
Transaction replacement can be advantageously combined with ''payment batching'' (described previously). Instead of waiting, for example, 30 minutes to batch all outgoing payments, the spender can batch the first 10 minutes of payments with a low feerate. If that doesn't get confirmed within 10 minutes, the spender can replace that transaction with a slightly higher feerate transaction that also includes then next 10 minutes of payments. If that again doesn't confirm, another update can also include the third 10 minutes of transactions at the original intended feerate. This allows the recipients of the first 10 minutes of payments to receive a notification that the payment has been sent up to 20 minutes earlier than with normal batching, and it also gives those early payments a chance to confirm at a lower-than-expected feerate. Updating a batched transaction with more payments can be done as many times as necessary up to a [[relay limit]] on transaction size of 100 kilobytes.<br />
<br />
Currently, transaction replacement does have one significant downside: it tends to reduce privacy. When the fee on a transaction is increased, either additional inputs must be added or the value of the [[change output]] must be decreased. In either case, this makes the change output easier to identify among the different outputs being paid by a transaction. Value-blinding techniques such as [[confidential transactions]] could improve this situation, but there are no near-term plans to add such a feature to Bitcoin as of early 2018. If transaction replacement is always combined with [[#change_avoidance|change avoidance]], it could avoid this privacy issue.<br />
<br />
See also:<br />
<br />
* [[Transaction replacement]]<br />
* [https://bitcoincore.org/en/faq/optin_rbf/ Opt-in Replace-By-Fee (RBF) FAQ] - BitcoinCore.org<br />
* [https://github.com/bitcoin/bips/blob/master/bip-0125.mediawiki BIP125] - Opt-in Full Replace-by-Fee Signaling<br />
<br />
==== Pre-computed fee bumping ====<br />
<br />
Pre-computed fee bumping is an idea to create and sign multiple replacements for a transaction at the time the initial transaction is created. The initial transaction version could be broadcast immediately, and each of the replacements would pay successively higher fees. This idea could be combined with Bitcoin's existing [[nLockTime]] feature to allow the replacement versions to forbid being included in a block earlier than a specified time or [[block height]], which would allow the replacements to be trustlessly transmitted to third parties (even miners themselves). <br />
<br />
For example, Alice would tell her wallet that she wanted to pay Bob within the next 10 blocks and also indicate what is the highest fee she’s willing to pay. Alice's wallet would then use its existing fee estimation feature to create an initial version of the transaction to Bob that paid the lowest expected fee for a transaction to confirm within 10 blocks. At the same time, Alice's wallet would also create possibly 9 other versions of the transaction, the first one using nLockTime to ensure it can’t be added until two blocks from now; the second timelocked until three blocks from now; etc…<br />
<br />
Each of these subsequent transactions would pay a slightly higher fee than the original transaction (up to Alice’s indicated max fee) to increase the incentive for miners to mine that transaction.<br />
<br />
Because all versions of the transaction would be signed at the time Alice sent the initial transaction, she would only need to unlock her wallet once. Also, because all subsequent versions of the transaction would use nLockTime, Alice could trustlessly distribute copies of these transactions to other people for later broadcast in case she went offline.<br />
<br />
In short, the software would automatically offer Alice’s maximum fee if it had to, but it’d pay a lower fee if it could get away with it—ensuring Alice got close to the best price possible without any extra effort on her part.<br />
<br />
See also:<br />
<br />
* [https://bitcoincore.org/en/meetings/2017/03/02/#big-features-for-0150 Bitcoin Core IRC meeting summary for 2017-03-02] - See "Precomputed fee bumping" bullet point<br />
<br />
== Offchain payments ==<br />
<br />
Not every Bitcoin payment needs to be added to the Bitcoin block chain. For example, imagine Alice pays 1 BTC to Bob, and then Bob pays 1 BTC to Charlie. Instead of adding both of these payments to the block chain, we could more efficiently just add a 1 BTC payment from Alice to Charlie.<br />
<br />
An early description using this specific optimization called it ''transaction cut-through,''<ref>[https://bitcointalk.org/index.php?topic=281848.0 Transaction cut-through], Gregory Maxwell, 2013-08-23, retrieved 2018-01-25</ref> but the concept of not every payment being recorded on the block chain is more widely known today as ''off-chain payments.''<br />
<br />
Up to 99% of all Bitcoin payments are estimated to be offchain payments<ref>[http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-June/008844.html Pure off-chain is a weak form of layer 2], Adam Back, 19 June 2015</ref>, with most of them likely being buy and sell orders on Bitcoin exchanges. Other third-parties may also help facilitate offchain payments for their users, for example tipping services. These services can be extraordinarily efficient because they don't carry Bitcoin's burden of maintaining consensus among a large set of users—but this efficiency comes at a cost of generally requiring that users trust the service operators not to steal funds. These are ''unenforceable offchain payments.''<br />
<br />
However, there also exist ''enforceable offchain payments'' where no trust in a specific third-party is required—only trust in Bitcoin continuing to operate without transaction censorship.<br />
<br />
This section currently focuses on enforceable offchain payments, but it may later be expanded to cover concepts for unenforcable offchain payments that use cryptography and other security solutions to provide more secure and more private solutions than simple trusted third parties.<br />
<br />
=== Payment channels ===<br />
<br />
''Very useful for small-size and moderate-size payments, but not yet widely deployed as of early 2018''<br />
<br />
[[Payment channels]] are a type of ''enforceable offchain payment'' where bitcoins are deposited into a [[smart contract]] between two or more parties, allowing the involved peers to make trustless payments to each other. Combined with [[hashlock]]s, payments can be securely routed across a network of peers, as in the [[Lightning Network]], allowing Alice to pay Charlie by routing a payment through their mutual peer Bob.<br />
<br />
Opening a payment channel requires a confirmed transaction, incurring the cost of the fees for that transaction, although those fees are identical to sending a regular transaction. Closing a channel also requires a confirmed transaction, adding that transaction's fees to the cost of the payment channel, although those fees too are similar to the costs of the recipient of the funds re-spending them to a new recipient. This means a payment channel's fee cost is very similar to making onchain payments.<br />
<br />
Outside of the channel open and channel close transactions, a payment channel can support an unlimited number of payments without paying any further transaction fees. This can make them extraordinarily efficient—for example, imagine making a million in-channel payments for the cost of just two transaction fees. Note: your channel peers and other channel nodes you route payments through may require their own fee for using their services; these are not related to the transaction fees that are the topic of this article.<br />
<br />
As of early 2018, no payment channel implementation is widely used, but several cooperating implementations of a first version of [[Lightning Network]] are available.<br />
<br />
See also:<br />
<br />
* [[Payment channels]]<br />
* [[Lightning Network]]<br />
<br />
== Potential future improvements ==<br />
<br />
Some of the following improvements and proposed improvements may become available to Bitcoin users. Users who adopt the improvements may be able to further lower their fees.<br />
<br />
* Efficiency improvements<br />
** '''Public key and signature aggregation:''' the ability to combine multiple public keys and signatures into a single public key and signature, allowing multisig transactions to be as efficient to spend as single-signature transactions are today. It may also be possible to combine signatures from multiple inputs in a transaction. It is hopped that this will be possible with variant of [[Schnorr signatures]]. Requires a [[soft fork]].<br />
** '''Merkelized Abstract Syntax Trees (MAST):''' a method for committing to spending scripts that allows the partial omission of unused conditions, allowing complex scripts to be much more efficient,<ref>[https://bitcointechtalk.com/what-is-a-bitcoin-merklized-abstract-syntax-tree-mast-33fdf2da5e2f What is a Bitcoin Merkelized Abstract Syntax Tree?], David A. Harding, BitcoinTechTalk.com, 2017-10-12, retrieved 2018-01-27</ref> even more so if used with [[taproot]]<ref>[https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2018-January/015614.html Taproot: Privacy preserving switchable scripting], Gregory Maxwell, Bitcoin-Dev mailing list, 2018-01-23</ref>. Combines well with signature aggregation (described above) in certain use cases. Requires a [[soft fork]].<br />
** '''CoinJoin with signature aggregation:''' [[CoinJoin]] is a technology for Bitcoin that enhances privacy without reducing security. A group of patient spenders can enter a coinjoin together and obfuscate which of them paid which recipient and which change outputs (if any) they received back. Combined with signature aggregation (described in a previous bullet point), this enhanced privacy mode would be cheaper than each spender making a separate less-private transaction—and it would still be just as secure.<ref>[https://diyhpl.us/wiki/transcripts/scalingbitcoin/milan/schnorr-signatures/ Elliptic curve Schnorr-based signatures in Bitcoin], Pieter Wuille, Scaling Bitcoin 2016 (Milan), 2016-10-09, retrieved 2018-01-27</ref> Requires the signature aggregation soft fork described previously.<br />
<br />
* Intelligent fee selection<br />
** '''Mempool-using fee estimation:''' a potential improvement in fee estimation that considers not just which transactions have been recently confirmed but also the queue of currently unconfirmed transactions.<ref name="mempool-fee-est-slides"/><ref name="mempool-fee-est-video"/> Does not require any protocol changes.<br />
<br />
* Offchain payments<br />
** '''Channel factories:''' (enforceable offchain payments) a potentially more efficient way to open payment channels such as those used by Lightning Network. Combined with signature aggregation (described above) this could reduce the cost of opening a payment channel by up to 96%.<ref>[https://www.tik.ee.ethz.ch/file/a20a865ce40d40c8f942cf206a7cba96/Scalable_Funding_Of_Blockchain_Micropayment_Networks%20(1).pdf Scalable Funding of Bitcoin Micropayment Channel Networks]; Conrad Burchert, Christian Decker, and Roger Wattenhofer; retrieved 2018-01-27</ref> Does not require any [[consensus]] changes.<br />
** '''Chaumian banks:''' (unenforceable offchain payments) a trusted third party who controls bitcoins for a pool of Bitcoin users ([[custodial wallet]], AKA "Bitcoin bank") but who can't know which users own which bitcoins. This is accomplished using [[Chaum blinded signatures]].<ref>[https://medium.com/@nopara73/chaumian-e-cash-for-custodial-bitcoin-wallets-and-services-to-scale-bitcoin-8977d9a03064 Chaumian E-Cash For Custodial Bitcoin Wallets And Services To Scale Bitcoin], nopara73, Medium.com, 2017-12-22, retrieved 2018-01-27</ref> Combined with [[hardware security modules]], it could be made extremely difficult for banks to steal depositor funds.<ref>[https://bitcointalk.org/index.php?topic=146307.0 Fidelity-bonded banks: decentralized, auditable, private, off-chain payments], Peter Todd, 2013-02-23, retrieved 2018-01-27</ref> Does not require any protocol changes.<br />
** '''Strong federations (sidechains)''' (unenforceable offchain payments) a set of trusted third parties controls bitcoins for a pool of Bitcoin users, but uses multisig to prevent an individual or small number of those trusted third parties from stealing depositor funds. Uses a public block chain (but not Bitcoin's block chain) to allow any user to audit all transfers into, out of, or within the system. Hardware security modules (HSMs) are used to further reduce trust in the third parties.<ref>[https://blockstream.com/strong-federations.pdf Strong Federations: An Interoperable Blockchain Solution to Centralized Third Party Risks]; Johnny Dilley, Andrew Poelstra, Jonathan Wilkins, Marta Piekarska, Ben Gorlick, and Mark Friedenbach; retrieved 2018-01-28</ref> Although a block chain is used, this qualifies as an offchain payment solution from the perspective of Bitcoin. As of early 2018, free software federated [[sidechain]] software provides support for [[confidential transactions]]<ref>[https://elementsproject.org/elements/confidential-transactions/ Confidential Transactions], ElementsProject.org, retrieved 2018-01-28</ref> that give them many of the same benefits of the Chaumian banks described in a previous bullet point, but federated sidechain software can (and does) support many other features also.<ref>[https://elementsproject.org/elements/ Elements (features)], ElementsProject.org, retrieved 2018-01-28</ref><br />
<br />
== References ==<br />
<br />
<references /></div>Hardinghttps://en.bitcoin.it/w/index.php?title=Techniques_to_reduce_transaction_fees&diff=64946Techniques to reduce transaction fees2018-01-29T18:31:22Z<p>Harding: add missing characters</p>
<hr />
<div>This page provides a list of currently-available techniques that may allow spenders to reduce the amount of [[transaction fee]] they pay. Not all techniques will apply to all situations, and some techniques require trading off other benefits for lower fees.<br />
<br />
When you reduce the fee you pay, you almost always reduce the fees other users have to pay also. For high-frequency spenders, this effect can be large and can provide significant additional second order savings. For example, If an organization is creating 10% of all transactions and begins making transactions 50% more efficiently, an additional 5% of block space is freed up for all users of Bitcoin. This would be expected to lower fees by some amount (likely more than 5%), providing a second order of savings on top of the first-order savings of 50%.<br />
<br />
''Note, this page only describes techniques that apply to payment-oriented transactions. Data carrier transactions (e.g. [[OP_RETURN]] or [[OpenTimestamps]]), [[colored coin]] protocols, and other proposed uses of Bitcoin transactions may benefit from some of the following techniques, but the recommendations are not aimed at those use cases.''<br />
<br />
== Efficiency improvements ==<br />
<br />
Creating transactions that are smaller in size ([[Weight units|weight]]), or which accomplish more for a given size, provide a more efficient way of using scarce block space and so pay less total fee to achieve a [[Transaction fees#feerates|feerate]] that is equivalent to less efficient payments. This section describes several techniques for producing more efficient transactions.<br />
<br />
Technically ''offchain payments'' such as those made in [[payment channels]] are a type of extremely efficient payment and so belong to this category, but they've been given a separate category because of the distinctive way they achieve their high efficiency.<br />
<br />
=== Compressed public keys ===<br />
<br />
''Universally useful but already widely deployed''<br />
<br />
The original Bitcoin software released in 2009 used 65-byte uncompressed public keys to identify the owner of a set of bitcoins. In 2012, Bitcoin protocol developer Pieter Wuille implemented a change to the program now known as Bitcoin Core that allowed it to use 33-byte compressed public keys instead.<ref>[https://bitcoin.org/en/release/v0.6.0#new-features-since-bitcoin-version-05 Bitcoin Core 0.6.0 release notes], Bitcoin.org, 2012-03-20, retrieved 2018-01-27</ref> As Bitcoin Core users adopted this feature and other wallets upgraded to use it as well, this reduced the size of a typical transaction on the network (with one input and two outputs) from about 258 bytes to about 226 bytes, a 14% savings.<br />
<br />
[[File:Uncompressed-pubkey-percentage.png|center|800px|thumb|The percentage of transaction inputs per block using the old uncompressed pubkey format in their scriptSigs. Note: early Bitcoin transactions often placed pubkeys in their scriptPubKeys rather than their scriptSigs.]]<br />
<br />
The change was fully backwards compatible and did not change security in any way, but it did require users wanting to access the space savings to generate new Bitcoin addresses.<br />
<br />
Since 2012, many wallets have adopted compressed public keys—but still some wallets continue to use the less efficient uncompressed public keys. These wallets could achieve a significant savings in transaction fees for the same priority by switching to compressed public keys. If all wallets adopted it, this would effectively lead to a small increase in the available block space:<br />
<br />
[[File:Uncompressed-pubkey-savings.png|center|800px|thumb|The percentage of the maximum available block space consumed by the extra bytes in uncompressed pubkeys]]<br />
<br />
See also:<br />
<br />
* [https://bitcoin.org/en/developer-guide#public-key-formats Compressed public keys] — Bitcoin.org Developer Guide<br />
* [https://bitcoin.org/en/release/v0.6.0#new-features-since-bitcoin-version-05 Bitcoin Core 0.6.0 release notes]<br />
* [https://github.com/bitcoin/bips/blob/master/bip-0143.mediawiki#Restrictions_on_public_key_type BIP143] - Requires all pubkeys in [[segregated witness]] witnesses be compressed pubkeys<br />
<br />
=== Payment batching ===<br />
<br />
''Very useful for high-frequency spenders (e.g. organizations); moderately useful for lower-frequency spenders (e.g. individuals)''<br />
<br />
Every Bitcoin transaction must reference the funds being spent and provide proof that the transaction was authorized by the owner of those funds. To spend a single collection of funds takes a minimum of 79 vbytes under normal circumstances. This same amount of block space is used no matter how many recipients are paid in that transaction. For example, consider the following two scenarios:<br />
<br />
* Alice pays Bob in one transaction and then pays Charlie in a second transaction. Each transaction contains a minimum of 79 vbytes related to the funds being spent—a total of 158 vbytes.<br />
* Alice uses a single transaction to pay both Bob and Charlie. The single transaction only needs one set of 79 vbytes related to the funds being spent—a savings of 50% for this field.<br />
<br />
This type of savings increases as more payments are added to a single transaction until the cost per payment is just barely more than the cost of adding the vbytes directly related to that payment in the transaction. The plot below shows the cost per payment for a native segwit [[P2WPKH]] transaction paying other P2WPKH outputs:<br />
<br />
[[File:Batching.png|center]]<br />
<br />
We see the cost drop by more than 50% after five payments are added, with the savings increasing up to about 70% for segwit transactions. Not shown is that the savings increase up to about 80% for legacy transactions because these transactions start off less efficient than segwit transactions. That's a major benefit and one that's easily obtainable by high-frequency spenders, such as organizations.<br />
<br />
Many wallets support batching payments. In graphical wallets, there's often a button that allows you add additional recipients to a transaction (see image below). In command-line and RPC wallets, there's often a call such as <code>sendmany</code> that lets you pay multiple recipients.<br />
<br />
[[File:Bitcoin-core-add-recipient.png|thumb|200px|right|Add Recipient button in Bitcoin Core 0.15.0]]<br />
<br />
Note that there are other parts of a transaction that stay a constant size (or nearly so) when payments are added, so the benefits stack up faster than a fixed cost of just 79 vbytes might suggest. The section below about ''change avoidance'' addresses how one of these cases can itself be eliminated as a cost.<br />
<br />
See also:<br />
<br />
* [https://bitcointechtalk.com/saving-up-to-80-on-bitcoin-transaction-fees-by-batching-payments-4147ab7009fb Saving up to 80% on Bitcoin transaction fees by batching payments]<br />
* [https://bitcoin.org/en/developer-reference#sendmany SendMany RPC] - Bitcoin.org Developer Reference<br />
<br />
=== P2SH-wrapped segwit ===<br />
<br />
''Universally useful''<br />
<br />
Transactions that spend bitcoins secured by [[segregated witness]] (segwit) use less space in a block than equivalent non-segwit (legacy) transactions, allowing segwit transactions to pay less total fee to achieve the same [[Transaction fees#feerates|feerate]] as legacy transactions. The amount of savings varies depending on the details of your transaction, but here are a few common transaction types an an example:<br />
<br />
{|<br />
! Type<br />
! Legacy vbytes<br />
! P2SH-wrapped<br>segwit vbytes<br />
! Savings<br />
|-<br />
| Single signature<br />
| 226<br />
| 167<br />
| 36%<br />
|-<br />
| 2-of-2 multisig<br />
| 335<br />
| 197<br />
| 70%<br />
|-<br />
| 2-of-3 multisig<br />
| 369<br />
| 206<br />
| 80%<br />
|}<br />
<br />
Note that the multisig examples above use the same security as the equivalent legacy P2SH multisig. Segwit optionally allows access to a multisig form that is more secure on one dimension but it requires an extra 12 vbytes per output, which would reduce efficiency somewhat.<br />
<br />
To access these savings, you must use a wallet that supports generating P2SH-wrapped segwit addresses (addresses that start with a "3", although not all addresses that start with a 3 are segwit-enabled). When you spend bitcoins received to these P2SH-wrapped segwit addresses, your transactions will automatically consume less block space, allowing your wallet to pay proportionally less fee.<br />
<br />
See also:<br />
<br />
* [[Segregated Witness]]<br />
* [https://bitcoincore.org/en/segwit_wallet_dev/ Segregated Witness Wallet Development Guide] - BitcoinCore.org<br />
* [https://bitcoincore.org/en/segwit_adoption/ List of wallets, libraries, and services that support segwit] - BitcoinCore.org<br />
<br />
=== Native segwit ===<br />
<br />
''Universally useful. Complete usage requires native segwit adoption by the people sending you bitcoins, but you may be able to use it for your [[change outputs]] immediately''<br />
<br />
The P2SH-wrapped segwit described above is backwards compatible with the P2SH address format supported by older wallets, but a new and non-backwards compatible format is available that saves additional space. The following examples and savings are compared to the size of the P2SH-wrapped examples above:<br />
<br />
{|<br />
! Type<br />
! P2SH-wrapped<br>segwit vbytes<br />
! Native segwit<br>vbytes<br />
! Additional<br>savings<br />
|-<br />
| Single signature<br />
| 167<br />
| 141<br />
| 19%<br />
|-<br />
| 2-of-2 multisig<br />
| 197<br />
| 169<br />
| 17%<br />
|-<br />
| 2-of-3 multisig<br />
| 206<br />
| 178<br />
| 16%<br />
|}<br />
<br />
To access these savings, you must use a wallet that supports generating native segwit addresses, called [[bech32]] addresses (addresses that start with a "bc1"). When you spend bitcoins received to these native segwit addresses, your transactions will automatically consume less block space than even P2SH-wrapped segwit addresses, allowing your wallet to pay proportionally less fee.<br />
<br />
Once a wallet supports native segwit, it can begin using it immediately for any [[change outputs]] it generates back to itself without waiting for anyone else to begin using native segwit. In early 2018, when native segwit adoption is low, this may make it easier to identify which output is change and so reduce your privacy. However, once native segwit adoption increases just slightly, this is not expected to adversely affect privacy.<br />
<br />
See also:<br />
<br />
* [[Bech32 adoption]]<br />
* [https://github.com/bitcoin/bips/blob/master/bip-0173.mediawiki BIP173] — Bech32 addresses<br />
<br />
=== Change avoidance ===<br />
<br />
''Useful for high-frequency recipients (e.g. organizations), especially those who already effectively use transaction batching''<br />
<br />
When a Bitcoin transaction references the funds it wants to spend, it's required to spend all of those funds. For example, if you received 5 BTC in a previous transaction and now you want to spend 2 BTC, Bitcoin requires that you spend all 5 BTC. For this reason, almost all Bitcoin transactions currently pay some bitcoins back to the spender. For example, you'd return the remaining 3 BTC from the previous example back to yourself. This return of money to yourself is called ''change'' by analogy to the change a store clerk hands you when you (for example) buy a $2 item with a $5 bill.<br />
<br />
A typical change output adds about 32 vbytes to the size of a transaction. If the spender can pay with exact change—that is, doesn't need to refund any change to them self—they can eliminate the change output and generate transactions that are up to 23% smaller. In addition, a change output will later be spent at a typical cost of 69 vbytes or more, but when paying with exact change, this future cost is also avoided.<br />
<br />
To use change avoidance requires having previously received a payment or set of payments that's close to the size of the amount being spent (including the transaction fee). This can be rare in the case of individual user wallets that don't receive many payments to choose from and can't significantly vary the amount of their spending transactions, but for organization wallets that receive many payments and already use payment batching to combine multiple outgoing payments, change avoidance can be an easily-obtainable efficiency improvement.<br />
<br />
The spender doesn't need to match the inputs and outputs of their transaction exactly to Bitcoin's full 10 nanobitcoin precision, but can instead overpay or underpay fees slightly by including inputs that are (respectively) slightly more or slightly less than the desired amount. Even when paying slightly more fees than desired, this can result in savings if the slight increase in fees is still less than would normally be paid for the extra 32 vbytes (or so) for a change output and the typical mininum of 69 vbytes for later spending that output.<ref>[https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2018-January/015606.html Transaction Merging (bip125 relaxation)], Rhavar, bitcoin-dev mailing list, 2018-01-22</ref> When paying slightly lower fees, confirmation of the transaction may be delayed, but current-generation (2018) fee estimates are still inaccurate enough that small differences in feerates may not strongly correlate to delays.<br />
<br />
See also:<br />
<br />
* [http://murch.one/wp-content/uploads/2016/11/erhardt2016coinselection.pdf An Evaluation of Coin Selection Strategies] - Mark Erhardt<br />
* [https://github.com/bitcoin/bitcoin/pull/10637 Bitcoin Core pull request #10,637] - A proposed implementation of Erhardt's "branch and bound" strategy<br />
* [https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2018-January/015606.html Bitcoin-Dev mailing list post] - With good coin selection, I am able to avoid change about ~75% of the time in my simulations..."<br />
<br />
=== Consolidation ===<br />
<br />
''Useful for all wallets but may require users sacrifice some privacy''<br />
<br />
The amount of fee a transaction pays is proportional to its size in [[vbytes]], and one the main contributors to size is the number of [[inputs]] the transaction spends. Each input is a reference to the funds the transaction wants to spend, and when a wallet contains only low-value inputs, it can't create a comparatively higher output paying a recipient without adding many of those inputs to the transaction. Each input adds a minimum of 41 vbytes to the transaction and almost always 69 or more vbytes, so any strategy that reduces the number of inputs is worth considering.<br />
<br />
Given that [[Transaction_fees#The_market_for_block_space|fees vary over time]], one method that can reduce overall fees is input consolidation—combining a set of smaller inputs into a single larger input by spending them from yourself to yourself during a period of time when fees are lower than normal. For example, if your usual target feerate during normal-priced fee periods is 100 nanobitcoins per vbyte and the current feerate is 10 nanobitcoins per vbyte, you could save up to almost 90% on fees by consolidating now before you next need to spend some of those inputs.<br />
<br />
[[File:Consolidation-savings.png|center]]<br />
<br />
Consolidation does come with the overhead of creating the consolidation transaction, which is equal to the cost of spending one input to one output, which is about 110 vbytes for P2WPKH inputs/outputs. Also, if you combine inputs that were originally sent to addresses unconnected to each other, you may reduce your privacy in some cases by making that connection in your consolidation transaction (although it's believed that few people currently manage to spend their inputs in a manner that preserves this element of privacy).<br />
<br />
See also:<br />
<br />
* [[How to cheaply consolidate coins to reduce miner fees]]<br />
<br />
== Intelligent fee selection ==<br />
<br />
When it comes to fees, sending a Bitcoin transaction is similar to mailing a package: you can pay a high fee for fast high-priority service or a lower fee for slower low-priority service. This section describes several techniques for taking advantage of the more affordable low-priority service.<br />
<br />
=== Dynamic fee estimation ===<br />
<br />
''Universally useful. Already widely deployed but still being improved as research and development continues''<br />
<br />
Early Bitcoin wallets often defaulted to paying a fixed fee on every transaction—enough to incentivize a miner to include it but not enough to compete against other transactions seeking confirmation in a [[fee market]]. As blocks have filled, this has changed, and as of early 2018 all widely-used wallets use dynamic fee estimation to select a fee based on the condition of the current fee market.<br />
<br />
[[File:Bitcoin-core-fee-selector.png|thumb|200px|right|Fee selector in Bitcoin Core 0.15.0]]<br />
<br />
However, some fee estimation tools may be better than others, achieving confirmation by the desired time even when paying lower fees. Although data from multiple wallets and fee estimation services can be compared<ref>[https://www.p2sh.info/dashboard/db/fee-estimation Fee Estimation], P2SH.info, retrieved 2018-01-23</ref> and there have been some attempts to compare fee estimation between different wallets,<ref>[https://blog.bitgo.com/the-challenges-of-bitcoin-transaction-fee-estimation-e47a64a61c72 The Challenges of Bitcoin Transaction Fee Estimation], Jameson Lopp, BitGo block, 2017-05-10, retrieved 2018-01-23</ref> there is no known survey of fee estimation quality across a large number of popular wallets as of early 2018.<br />
<br />
In addition, also as of early 2018, some techniques have recently been described that could significantly improve fee estimation, such as factoring current [[mempool]] data into confirmation-based fee estimates.<ref name="mempool-fee-est-slides">[https://scalingbitcoin.org/stanford2017/Day2/Scaling-2017-Optimizing-fee-estimation-via-the-mempool-state.pdf Optimizing fee estimation via the mempool state (slides, PDF)], Karl-Johan Alm, Scaling Bitcoin 2017 (Stanford), 2017-11-05, retrieved 2018-01-23</ref><ref name="mempool-fee-est-video">[https://www.youtube.com/watch?v=QkYXPJMqBNk&feature=youtu.be&t=2033 Optimizing fee estimation via the mempool state (presentation video)], Karl-Johan Alm, Scaling Bitcoin 2017 (Stanford), 2017-11-05, retrieved 2018-01-23</ref><br />
<br />
See also<br />
<br />
* [[Transaction fees]]<br />
* [https://blog.bitgo.com/the-challenges-of-bitcoin-transaction-fee-estimation-e47a64a61c72 The Challenges of Bitcoin Transaction Fee Estimation] - Jameson Lopp<br />
* [https://gist.github.com/morcos/d3637f015bc4e607e1fd10d8351e9f41 High level description Bitcoin Core's fee estimation algorithm] - Alex Morcos<br />
<br />
=== Patient spending ===<br />
<br />
''Very useful for non-urgent transactions. Not useful for urgent transactions''<br />
<br />
Spenders who can patiently wait for their transactions to confirm can take advantage of variations in the [[Transaction fees#feerates|feerate]] necessary to achive confirmation. For example, sometimes several Bitcoin blocks are produced in quick succession, raising the effective supply of block space by several multiples; other times, demand drops off, such as fees on Sunday being on average 20% lower than fees on Friday in Q4 2017<ref>[[Transaction_fees#The_market_for_block_space]], Bitcoin Wiki, retrieved 2018-01-27</ref>. Looking at data from the widely-used fee estimator included in Bitcoin Core, we can see fee savings of 90% or more possible, with around 50% being easily obtainable by many patient spenders.<br />
<br />
[[File:Feerate-estimates.png|center]]<br />
<br />
In the data plotted above, the Bitcoin Core fee estimator suggests that for this sample period the following savings are available:<br />
<br />
{|<br />
! Wait<br />
! Conservative savings<br />
! Economical savings*<br />
|-<br />
| 2 hours<br />
| 5% <br />
| 5%<br />
|-<br />
| 6 hours<br />
| 18%<br />
| 55%<br />
|-<br />
| 12 hours <br />
| 39%<br />
| 55%<br />
|-<br />
| 24 hours (1 day)<br />
| 39% <br />
| 55%<br />
|-<br />
| 48 hours (2 days) <br />
| 47% <br />
| 55%<br />
|-<br />
| 72 hours (3 days) <br />
| 52% <br />
| 55%<br />
|-<br />
| 96 hours (4 days) <br />
| 92% <br />
| 92%<br />
|}<br />
<br />
''* Economical savings have a lower probability of being achieved and are recommended for use with the transaction replacability described in a later section.''<br />
<br />
Although waiting up to four days is impractical for many use cases, there are also many cases where it can be practical. A few examples: moving funds between one's own wallets, [[#Consolidation|consolidating]] many smaller inputs into one larger input that can be more efficiently spent, or payments or remittances to friends or family who trust the spender and so don't need fast confirmation.<br />
<br />
See also:<br />
<br />
* [https://p2sh.info/dashboard/db/fee-estimation P2SH.info] - Fee estimates from multiple sources<br />
* [[Transaction_fees#Fee_Plotting_Sites|Other fee plotting sites]]<br />
<br />
=== Opt-in transaction replacement ===<br />
<br />
''Universally useful, but may cause UI issues in recipient wallets''<br />
<br />
Although not strictly a method for reducing fees by itself, opt-in transaction replacement allows a wallet to update previously-sent transactions with new versions that pay higher fees and, possibly, make other changes to the transaction. The method is also called opt-in Replace-By-Fee (RBF). This technique allows wallets to initially pay lower fees in case there's a sudden increase in the supply of block space, a sudden decrease in demand for that space, or another situation that increases the chance of low-fee transactions being confirmed. If none of those things happens, the spender can then increase ("bump") the transaction's fee to increase its probability of confirming.<br />
<br />
This often allows wallets that support transaction replacement to pay lower fees than wallets that don't support replacement.<br />
<br />
Transaction replacement can appear odd in some recipient wallets. Wallets such as Bitcoin Core (pictured below) show each replacement as a separate payment in the list of transactions. When one version of the replacements is confirmed, it is shown as a normal transaction; the other versions are then shown with an X icon to indicate that they are [[conflicted]] (cannot occur together in the same valid block chain). This helps communicate the status of all affected payments to the recipient, but it may not be entirely clear what's happening to users who aren't familar with replacements. Other wallets may not show transactions opting in to replacement at all until one version of the transaction has been confirmed. There's no clear community consensus on the correct way to handle this situation using user interfaces, documentation, or both.<br />
<br />
[[File:Fee-bump-ux.png|thumb|right|200px|List of transaction replacements in Bitcoin Core 0.15.0]]<br />
<br />
Transaction replacement can be advantageously combined with ''payment batching'' (described previously). Instead of waiting, for example, 30 minutes to batch all outgoing payments, the spender can batch the first 10 minutes of payments with a low feerate. If that doesn't get confirmed within 10 minutes, the spender can replace that transaction with a slightly higher feerate transaction that also includes then next 10 minutes of payments. If that again doesn't confirm, another update can also include the third 10 minutes of transactions at the original intended feerate. This allows the recipients of the first 10 minutes of payments to receive a notification that the payment has been sent up to 20 minutes earlier than with normal batching, and it also gives those early payments a chance to confirm at a lower-than-expected feerate. Updating a batched transaction with more payments can be done as many times as necessary up to a [[relay limit]] on transaction size of 100 kilobytes.<br />
<br />
Currently, transaction replacement does have one significant downside: it tends to reduce privacy. When the fee on a transaction is increased, either additional inputs must be added or the value of the [[change output]] must be decreased. In either case, this makes the change output easier to identify among the different outputs being paid by a transaction. Value-blinding techniques such as [[confidential transactions]] could improve this situation, but there are no near-term plans to add such a feature to Bitcoin as of early 2018. If transaction replacement is always combined with [[#change_avoidance|change avoidance]], it could avoid this privacy issue.<br />
<br />
See also:<br />
<br />
* [[Transaction replacement]]<br />
* [https://bitcoincore.org/en/faq/optin_rbf/ Opt-in Replace-By-Fee (RBF) FAQ] - BitcoinCore.org<br />
* [https://github.com/bitcoin/bips/blob/master/bip-0125.mediawiki BIP125] - Opt-in Full Replace-by-Fee Signaling<br />
<br />
==== Pre-computed fee bumping ====<br />
<br />
Pre-computed fee bumping is an idea to create and sign multiple replacements for a transaction at the time the initial transaction is created. The initial transaction version could be broadcast immediately, and each of the replacements would pay successively higher fees. This idea could be combined with Bitcoin's existing [[nLockTime]] feature to allow the replacement versions to forbid being included in a block earlier than a specified time or [[block height]], which would allow the replacements to be trustlessly transmitted to third parties (even miners themselves). <br />
<br />
For example, Alice would tell her wallet that she wanted to pay Bob within the next 10 blocks and also indicate what is the highest fee she’s willing to pay. Alice's wallet would then use its existing fee estimation feature to create an initial version of the transaction to Bob that paid the lowest expected fee for a transaction to confirm within 10 blocks. At the same time, Alice's wallet would also create possibly 9 other versions of the transaction, the first one using nLockTime to ensure it can’t be added until two blocks from now; the second timelocked until three blocks from now; etc…<br />
<br />
Each of these subsequent transactions would pay a slightly higher fee than the original transaction (up to Alice’s indicated max fee) to increase the incentive for miners to mine that transaction.<br />
<br />
Because all versions of the transaction would be signed at the time Alice sent the initial transaction, she would only need to unlock her wallet once. Also, because all subsequent versions of the transaction would use nLockTime, Alice could trustlessly distribute copies of these transactions to other people for later broadcast in case she went offline.<br />
<br />
In short, the software would automatically offer Alice’s maximum fee if it had to, but it’d pay a lower fee if it could get away with it—ensuring Alice got close to the best price possible without any extra effort on her part.<br />
<br />
See also:<br />
<br />
* [https://bitcoincore.org/en/meetings/2017/03/02/#big-features-for-0150 Bitcoin Core IRC meeting summary for 2017-03-02] - See "Precomputed fee bumping" bullet point<br />
<br />
== Offchain payments ==<br />
<br />
Not every Bitcoin payment needs to be added to the Bitcoin block chain. For example, imagine Alice pays 1 BTC to Bob, and then Bob pays 1 BTC to Charlie. Instead of adding both of these payments to the block chain, we could more efficiently just add a 1 BTC payment from Alice to Charlie.<br />
<br />
An early description using this specific optimization called it ''transaction cut-through,''<ref>[https://bitcointalk.org/index.php?topic=281848.0 Transaction cut-through], Gregory Maxwell, 2013-08-23, retrieved 2018-01-25</ref> but the concept of not every payment being recorded on the block chain is more widely known today as ''off-chain payments.''<br />
<br />
Up to 99% of all Bitcoin payments are estimated to be offchain payments<ref>[http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-June/008844.html Pure off-chain is a weak form of layer 2], Adam Back, 19 June 2015</ref>, with most of them likely being buy and sell orders on Bitcoin exchanges. Other third-parties may also help facilitate offchain payments for their users, for example tipping services. These services can be extraordinarily efficient because they don't carry Bitcoin's burden of maintaining consensus among a large set of users—but this efficiency comes at a cost of generally requiring that users trust the service operators not to steal funds. These are ''unenforceable offchain payments.''<br />
<br />
However, there also exist ''enforceable offchain payments'' where no trust in a specific third-party is required—only trust in Bitcoin continuing to operate without transaction censorship.<br />
<br />
This section currently focuses on enforceable offchain payments, but it may later be expanded to cover concepts for unenforcable offchain payments that use cryptography and other security solutions to provide more secure and more private solutions than simple trusted third parties.<br />
<br />
=== Payment channels ===<br />
<br />
''Very useful for small-size and moderate-size payments, but not yet widely deployed as of early 2018''<br />
<br />
[[Payment channels]] are a type of ''enforceable offchain payment'' where bitcoins are deposited into a [[smart contract]] between two or more parties, allowing the involved peers to make trustless payments to each other. Combined with [[hashlock]]s, payments can be securely routed across a network of peers, as in the [[Lightning Network]], allowing Alice to pay Charlie by routing a payment through their mutual peer Bob.<br />
<br />
Opening a payment channel requires a confirmed transaction, incurring the cost of the fees for that transaction, although those fees are identical to sending a regular transaction. Closing a channel also requires a confirmed transaction, adding that transaction's fees to the cost of the payment channel, although those fees too are similar to the costs of the recipient of the funds re-spending them to a new recipient. This means a payment channel's fee cost is very similar to making onchain payments.<br />
<br />
Outside of the channel open and channel close transactions, a payment channel can support an unlimited number of payments without paying any further transaction fees. This can make them extraordinarily efficient—for example, imagine making a million in-channel payments for the cost of just two transaction fees. Note: your channel peers and other channel nodes you route payments through may require their own fee for using their services; these are not related to the transaction fees that are the topic of this article.<br />
<br />
As of early 2018, no payment channel implementation is widely used, but several cooperating implementations of a first version of [[Lightning Network]] are available.<br />
<br />
See also:<br />
<br />
* [[Payment channels]]<br />
* [[Lightning Network]]<br />
<br />
== Potential future improvements ==<br />
<br />
Some of the following improvements and proposed improvements may become available to Bitcoin users. Users who adopt the improvements may be able to further lower their fees.<br />
<br />
* Efficiency improvements<br />
** '''Public key and signature aggregation:''' the ability to combine multiple public keys and signatures into a single public key and signature, allowing multisig transactions to be as efficient to spend as single-signature transactions are today. It may also be possible to combine signatures from multiple inputs in a transaction. It is hopped that this will be possible with variant of [[Schnorr signatures]]. Requires a [[soft fork]].<br />
** '''Merkelized Abstract Syntax Trees (MAST):''' a method for committing to spending scripts that allows the partial omission of unused conditions, allowing complex scripts to be much more efficient,<ref>[https://bitcointechtalk.com/what-is-a-bitcoin-merklized-abstract-syntax-tree-mast-33fdf2da5e2f What is a Bitcoin Merkelized Abstract Syntax Tree?], David A. Harding, BitcoinTechTalk.com, 2017-10-12, retrieved 2018-01-27</ref> even more so if used with [[taproot]]<ref>[https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2018-January/015614.html Taproot: Privacy preserving switchable scripting], Gregory Maxwell, Bitcoin-Dev mailing list, 2018-01-23</ref>. Combines well with signature aggregation (described above) in certain use cases. Requires a [[soft fork]].<br />
** '''CoinJoin with signature aggregation:''' [[CoinJoin]] is a technology for Bitcoin that enhances privacy without reducing security. A group of patient spenders can enter a coinjoin together and obfuscate which of them paid which recipient and which change outputs (if any) they received back. Combined with signature aggregation (described in a previous bullet point), this enhanced privacy mode would be cheaper than each spender making a separate less-private transaction—and it would still be just as secure.<ref>[https://diyhpl.us/wiki/transcripts/scalingbitcoin/milan/schnorr-signatures/ Elliptic curve Schnorr-based signatures in Bitcoin], Pieter Wuille, Scaling Bitcoin 2016 (Milan), 2016-10-09, retrieved 2018-01-27</ref> Requires the signature aggregation soft fork described previously.<br />
<br />
* Intelligent fee selection<br />
** '''Mempool-using fee estimation:''' a potential improvement in fee estimation that considers not just which transactions have been recently confirmed but also the queue of currently unconfirmed transactions.<ref name="mempool-fee-est-slides"/><ref name="mempool-fee-est-video"/> Does not require any protocol changes.<br />
<br />
* Offchain payments<br />
** '''Channel factories:''' (enforceable offchain payments) a potentially more efficient way to open payment channels such as those used by Lightning Network. Combined with signature aggregation (described above) this could reduce the cost of opening a payment channel by up to 96%.<ref>[https://www.tik.ee.ethz.ch/file/a20a865ce40d40c8f942cf206a7cba96/Scalable_Funding_Of_Blockchain_Micropayment_Networks%20(1).pdf Scalable Funding of Bitcoin Micropayment Channel Networks]; Conrad Burchert, Christian Decker, and Roger Wattenhofer; retrieved 2018-01-27</ref> Does not require any [[consensus]] changes.<br />
** '''Chaumian banks:''' (unenforceable offchain payments) a trusted third party who controls bitcoins for a pool of Bitcoin users ([[custodial wallet]], AKA "Bitcoin bank") but who can't know which users own which bitcoins. This is accomplished using [[Chaum blinded signatures]].<ref>[https://medium.com/@nopara73/chaumian-e-cash-for-custodial-bitcoin-wallets-and-services-to-scale-bitcoin-8977d9a03064 Chaumian E-Cash For Custodial Bitcoin Wallets And Services To Scale Bitcoin], nopara73, Medium.com, 2017-12-22, retrieved 2018-01-27</ref> Combined with [[hardware security modules]], it could be made extremely difficult for banks to steal depositor funds.<ref>[https://bitcointalk.org/index.php?topic=146307.0 Fidelity-bonded banks: decentralized, auditable, private, off-chain payments], Peter Todd, 2013-02-23, retrieved 2018-01-27</ref> Does not require any protocol changes.<br />
** '''Strong federations (sidechains)''' (unenforceable offchain payments) a set of trusted third parties controls bitcoins for a pool of Bitcoin users, but uses multisig to prevent an individual or small number of those trusted third parties from stealing depositor funds. Uses a public block chain (but not Bitcoin's block chain) to allow any user to audit all transfers into, out of, or within the system. Hardware security modules (HSMs) are used to further reduce trust in the third parties.<ref>[https://blockstream.com/strong-federations.pdf Strong Federations: An Interoperable Blockchain Solution to Centralized Third Party Risks]; Johnny Dilley, Andrew Poelstra, Jonathan Wilkins, Marta Piekarska, Ben Gorlick, and Mark Friedenbach; retrieved 2018-01-28</ref> Although a block chain is used, this qualifies as an offchain payment solution from the perspective of Bitcoin. As of early 2018, free software federated [[sidechain]] software provides support for [[confidential transactions]]<ref>[https://elementsproject.org/elements/confidential-transactions/ Confidential Transactions], ElementsProject.org, retrieved 2018-01-28</ref> that give them many of the same benefits of the Chaumian banks described in a previous bullet point, but federated sidechain software can (and does) support many other features also.<ref>[https://elementsproject.org/elements/ Elements (features)], ElementsProject.org, retrieved 2018-01-28</ref><br />
<br />
== References ==<br />
<br />
<references /></div>Hardinghttps://en.bitcoin.it/w/index.php?title=Techniques_to_reduce_transaction_fees&diff=64945Techniques to reduce transaction fees2018-01-29T18:19:32Z<p>Harding: /* Opening */ Mention that you reducing the fee you need to pay almost always means others can reduce their fees also, and that for high-frequency spenders this can provide signficiant second-order savings</p>
<hr />
<div>This page provides a list of currently-available techniques that may allow spenders to reduce the amount of [[transaction fee]] they pay. Not all techniques will apply to all situations, and some techniques require trading off other benefits for lower fees.<br />
<br />
When you reduce the fee you pay, you almost always reduce the fees other users have to pay also. For high-frequency spenders, this effect can be large and can provide significant additional second order savings. For example, If an organization is creating 10% of all transactions and begins making transaction 50% more efficiently, an additional 5% of block space is freed up for all users of Bitcoin. This would be expected to lower fees by some amount (likely more than 5%), providing a second order savings on top of the first-order savings of 50%.<br />
<br />
''Note, this page only describes techniques that apply to payment-oriented transactions. Data carrier transactions (e.g. [[OP_RETURN]] or [[OpenTimestamps]]), [[colored coin]] protocols, and other proposed uses of Bitcoin transactions may benefit from some of the following techniques, but the recommendations are not aimed at those use cases.''<br />
<br />
== Efficiency improvements ==<br />
<br />
Creating transactions that are smaller in size ([[Weight units|weight]]), or which accomplish more for a given size, provide a more efficient way of using scarce block space and so pay less total fee to achieve a [[Transaction fees#feerates|feerate]] that is equivalent to less efficient payments. This section describes several techniques for producing more efficient transactions.<br />
<br />
Technically ''offchain payments'' such as those made in [[payment channels]] are a type of extremely efficient payment and so belong to this category, but they've been given a separate category because of the distinctive way they achieve their high efficiency.<br />
<br />
=== Compressed public keys ===<br />
<br />
''Universally useful but already widely deployed''<br />
<br />
The original Bitcoin software released in 2009 used 65-byte uncompressed public keys to identify the owner of a set of bitcoins. In 2012, Bitcoin protocol developer Pieter Wuille implemented a change to the program now known as Bitcoin Core that allowed it to use 33-byte compressed public keys instead.<ref>[https://bitcoin.org/en/release/v0.6.0#new-features-since-bitcoin-version-05 Bitcoin Core 0.6.0 release notes], Bitcoin.org, 2012-03-20, retrieved 2018-01-27</ref> As Bitcoin Core users adopted this feature and other wallets upgraded to use it as well, this reduced the size of a typical transaction on the network (with one input and two outputs) from about 258 bytes to about 226 bytes, a 14% savings.<br />
<br />
[[File:Uncompressed-pubkey-percentage.png|center|800px|thumb|The percentage of transaction inputs per block using the old uncompressed pubkey format in their scriptSigs. Note: early Bitcoin transactions often placed pubkeys in their scriptPubKeys rather than their scriptSigs.]]<br />
<br />
The change was fully backwards compatible and did not change security in any way, but it did require users wanting to access the space savings to generate new Bitcoin addresses.<br />
<br />
Since 2012, many wallets have adopted compressed public keys—but still some wallets continue to use the less efficient uncompressed public keys. These wallets could achieve a significant savings in transaction fees for the same priority by switching to compressed public keys. If all wallets adopted it, this would effectively lead to a small increase in the available block space:<br />
<br />
[[File:Uncompressed-pubkey-savings.png|center|800px|thumb|The percentage of the maximum available block space consumed by the extra bytes in uncompressed pubkeys]]<br />
<br />
See also:<br />
<br />
* [https://bitcoin.org/en/developer-guide#public-key-formats Compressed public keys] — Bitcoin.org Developer Guide<br />
* [https://bitcoin.org/en/release/v0.6.0#new-features-since-bitcoin-version-05 Bitcoin Core 0.6.0 release notes]<br />
* [https://github.com/bitcoin/bips/blob/master/bip-0143.mediawiki#Restrictions_on_public_key_type BIP143] - Requires all pubkeys in [[segregated witness]] witnesses be compressed pubkeys<br />
<br />
=== Payment batching ===<br />
<br />
''Very useful for high-frequency spenders (e.g. organizations); moderately useful for lower-frequency spenders (e.g. individuals)''<br />
<br />
Every Bitcoin transaction must reference the funds being spent and provide proof that the transaction was authorized by the owner of those funds. To spend a single collection of funds takes a minimum of 79 vbytes under normal circumstances. This same amount of block space is used no matter how many recipients are paid in that transaction. For example, consider the following two scenarios:<br />
<br />
* Alice pays Bob in one transaction and then pays Charlie in a second transaction. Each transaction contains a minimum of 79 vbytes related to the funds being spent—a total of 158 vbytes.<br />
* Alice uses a single transaction to pay both Bob and Charlie. The single transaction only needs one set of 79 vbytes related to the funds being spent—a savings of 50% for this field.<br />
<br />
This type of savings increases as more payments are added to a single transaction until the cost per payment is just barely more than the cost of adding the vbytes directly related to that payment in the transaction. The plot below shows the cost per payment for a native segwit [[P2WPKH]] transaction paying other P2WPKH outputs:<br />
<br />
[[File:Batching.png|center]]<br />
<br />
We see the cost drop by more than 50% after five payments are added, with the savings increasing up to about 70% for segwit transactions. Not shown is that the savings increase up to about 80% for legacy transactions because these transactions start off less efficient than segwit transactions. That's a major benefit and one that's easily obtainable by high-frequency spenders, such as organizations.<br />
<br />
Many wallets support batching payments. In graphical wallets, there's often a button that allows you add additional recipients to a transaction (see image below). In command-line and RPC wallets, there's often a call such as <code>sendmany</code> that lets you pay multiple recipients.<br />
<br />
[[File:Bitcoin-core-add-recipient.png|thumb|200px|right|Add Recipient button in Bitcoin Core 0.15.0]]<br />
<br />
Note that there are other parts of a transaction that stay a constant size (or nearly so) when payments are added, so the benefits stack up faster than a fixed cost of just 79 vbytes might suggest. The section below about ''change avoidance'' addresses how one of these cases can itself be eliminated as a cost.<br />
<br />
See also:<br />
<br />
* [https://bitcointechtalk.com/saving-up-to-80-on-bitcoin-transaction-fees-by-batching-payments-4147ab7009fb Saving up to 80% on Bitcoin transaction fees by batching payments]<br />
* [https://bitcoin.org/en/developer-reference#sendmany SendMany RPC] - Bitcoin.org Developer Reference<br />
<br />
=== P2SH-wrapped segwit ===<br />
<br />
''Universally useful''<br />
<br />
Transactions that spend bitcoins secured by [[segregated witness]] (segwit) use less space in a block than equivalent non-segwit (legacy) transactions, allowing segwit transactions to pay less total fee to achieve the same [[Transaction fees#feerates|feerate]] as legacy transactions. The amount of savings varies depending on the details of your transaction, but here are a few common transaction types an an example:<br />
<br />
{|<br />
! Type<br />
! Legacy vbytes<br />
! P2SH-wrapped<br>segwit vbytes<br />
! Savings<br />
|-<br />
| Single signature<br />
| 226<br />
| 167<br />
| 36%<br />
|-<br />
| 2-of-2 multisig<br />
| 335<br />
| 197<br />
| 70%<br />
|-<br />
| 2-of-3 multisig<br />
| 369<br />
| 206<br />
| 80%<br />
|}<br />
<br />
Note that the multisig examples above use the same security as the equivalent legacy P2SH multisig. Segwit optionally allows access to a multisig form that is more secure on one dimension but it requires an extra 12 vbytes per output, which would reduce efficiency somewhat.<br />
<br />
To access these savings, you must use a wallet that supports generating P2SH-wrapped segwit addresses (addresses that start with a "3", although not all addresses that start with a 3 are segwit-enabled). When you spend bitcoins received to these P2SH-wrapped segwit addresses, your transactions will automatically consume less block space, allowing your wallet to pay proportionally less fee.<br />
<br />
See also:<br />
<br />
* [[Segregated Witness]]<br />
* [https://bitcoincore.org/en/segwit_wallet_dev/ Segregated Witness Wallet Development Guide] - BitcoinCore.org<br />
* [https://bitcoincore.org/en/segwit_adoption/ List of wallets, libraries, and services that support segwit] - BitcoinCore.org<br />
<br />
=== Native segwit ===<br />
<br />
''Universally useful. Complete usage requires native segwit adoption by the people sending you bitcoins, but you may be able to use it for your [[change outputs]] immediately''<br />
<br />
The P2SH-wrapped segwit described above is backwards compatible with the P2SH address format supported by older wallets, but a new and non-backwards compatible format is available that saves additional space. The following examples and savings are compared to the size of the P2SH-wrapped examples above:<br />
<br />
{|<br />
! Type<br />
! P2SH-wrapped<br>segwit vbytes<br />
! Native segwit<br>vbytes<br />
! Additional<br>savings<br />
|-<br />
| Single signature<br />
| 167<br />
| 141<br />
| 19%<br />
|-<br />
| 2-of-2 multisig<br />
| 197<br />
| 169<br />
| 17%<br />
|-<br />
| 2-of-3 multisig<br />
| 206<br />
| 178<br />
| 16%<br />
|}<br />
<br />
To access these savings, you must use a wallet that supports generating native segwit addresses, called [[bech32]] addresses (addresses that start with a "bc1"). When you spend bitcoins received to these native segwit addresses, your transactions will automatically consume less block space than even P2SH-wrapped segwit addresses, allowing your wallet to pay proportionally less fee.<br />
<br />
Once a wallet supports native segwit, it can begin using it immediately for any [[change outputs]] it generates back to itself without waiting for anyone else to begin using native segwit. In early 2018, when native segwit adoption is low, this may make it easier to identify which output is change and so reduce your privacy. However, once native segwit adoption increases just slightly, this is not expected to adversely affect privacy.<br />
<br />
See also:<br />
<br />
* [[Bech32 adoption]]<br />
* [https://github.com/bitcoin/bips/blob/master/bip-0173.mediawiki BIP173] — Bech32 addresses<br />
<br />
=== Change avoidance ===<br />
<br />
''Useful for high-frequency recipients (e.g. organizations), especially those who already effectively use transaction batching''<br />
<br />
When a Bitcoin transaction references the funds it wants to spend, it's required to spend all of those funds. For example, if you received 5 BTC in a previous transaction and now you want to spend 2 BTC, Bitcoin requires that you spend all 5 BTC. For this reason, almost all Bitcoin transactions currently pay some bitcoins back to the spender. For example, you'd return the remaining 3 BTC from the previous example back to yourself. This return of money to yourself is called ''change'' by analogy to the change a store clerk hands you when you (for example) buy a $2 item with a $5 bill.<br />
<br />
A typical change output adds about 32 vbytes to the size of a transaction. If the spender can pay with exact change—that is, doesn't need to refund any change to them self—they can eliminate the change output and generate transactions that are up to 23% smaller. In addition, a change output will later be spent at a typical cost of 69 vbytes or more, but when paying with exact change, this future cost is also avoided.<br />
<br />
To use change avoidance requires having previously received a payment or set of payments that's close to the size of the amount being spent (including the transaction fee). This can be rare in the case of individual user wallets that don't receive many payments to choose from and can't significantly vary the amount of their spending transactions, but for organization wallets that receive many payments and already use payment batching to combine multiple outgoing payments, change avoidance can be an easily-obtainable efficiency improvement.<br />
<br />
The spender doesn't need to match the inputs and outputs of their transaction exactly to Bitcoin's full 10 nanobitcoin precision, but can instead overpay or underpay fees slightly by including inputs that are (respectively) slightly more or slightly less than the desired amount. Even when paying slightly more fees than desired, this can result in savings if the slight increase in fees is still less than would normally be paid for the extra 32 vbytes (or so) for a change output and the typical mininum of 69 vbytes for later spending that output.<ref>[https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2018-January/015606.html Transaction Merging (bip125 relaxation)], Rhavar, bitcoin-dev mailing list, 2018-01-22</ref> When paying slightly lower fees, confirmation of the transaction may be delayed, but current-generation (2018) fee estimates are still inaccurate enough that small differences in feerates may not strongly correlate to delays.<br />
<br />
See also:<br />
<br />
* [http://murch.one/wp-content/uploads/2016/11/erhardt2016coinselection.pdf An Evaluation of Coin Selection Strategies] - Mark Erhardt<br />
* [https://github.com/bitcoin/bitcoin/pull/10637 Bitcoin Core pull request #10,637] - A proposed implementation of Erhardt's "branch and bound" strategy<br />
* [https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2018-January/015606.html Bitcoin-Dev mailing list post] - With good coin selection, I am able to avoid change about ~75% of the time in my simulations..."<br />
<br />
=== Consolidation ===<br />
<br />
''Useful for all wallets but may require users sacrifice some privacy''<br />
<br />
The amount of fee a transaction pays is proportional to its size in [[vbytes]], and one the main contributors to size is the number of [[inputs]] the transaction spends. Each input is a reference to the funds the transaction wants to spend, and when a wallet contains only low-value inputs, it can't create a comparatively higher output paying a recipient without adding many of those inputs to the transaction. Each input adds a minimum of 41 vbytes to the transaction and almost always 69 or more vbytes, so any strategy that reduces the number of inputs is worth considering.<br />
<br />
Given that [[Transaction_fees#The_market_for_block_space|fees vary over time]], one method that can reduce overall fees is input consolidation—combining a set of smaller inputs into a single larger input by spending them from yourself to yourself during a period of time when fees are lower than normal. For example, if your usual target feerate during normal-priced fee periods is 100 nanobitcoins per vbyte and the current feerate is 10 nanobitcoins per vbyte, you could save up to almost 90% on fees by consolidating now before you next need to spend some of those inputs.<br />
<br />
[[File:Consolidation-savings.png|center]]<br />
<br />
Consolidation does come with the overhead of creating the consolidation transaction, which is equal to the cost of spending one input to one output, which is about 110 vbytes for P2WPKH inputs/outputs. Also, if you combine inputs that were originally sent to addresses unconnected to each other, you may reduce your privacy in some cases by making that connection in your consolidation transaction (although it's believed that few people currently manage to spend their inputs in a manner that preserves this element of privacy).<br />
<br />
See also:<br />
<br />
* [[How to cheaply consolidate coins to reduce miner fees]]<br />
<br />
== Intelligent fee selection ==<br />
<br />
When it comes to fees, sending a Bitcoin transaction is similar to mailing a package: you can pay a high fee for fast high-priority service or a lower fee for slower low-priority service. This section describes several techniques for taking advantage of the more affordable low-priority service.<br />
<br />
=== Dynamic fee estimation ===<br />
<br />
''Universally useful. Already widely deployed but still being improved as research and development continues''<br />
<br />
Early Bitcoin wallets often defaulted to paying a fixed fee on every transaction—enough to incentivize a miner to include it but not enough to compete against other transactions seeking confirmation in a [[fee market]]. As blocks have filled, this has changed, and as of early 2018 all widely-used wallets use dynamic fee estimation to select a fee based on the condition of the current fee market.<br />
<br />
[[File:Bitcoin-core-fee-selector.png|thumb|200px|right|Fee selector in Bitcoin Core 0.15.0]]<br />
<br />
However, some fee estimation tools may be better than others, achieving confirmation by the desired time even when paying lower fees. Although data from multiple wallets and fee estimation services can be compared<ref>[https://www.p2sh.info/dashboard/db/fee-estimation Fee Estimation], P2SH.info, retrieved 2018-01-23</ref> and there have been some attempts to compare fee estimation between different wallets,<ref>[https://blog.bitgo.com/the-challenges-of-bitcoin-transaction-fee-estimation-e47a64a61c72 The Challenges of Bitcoin Transaction Fee Estimation], Jameson Lopp, BitGo block, 2017-05-10, retrieved 2018-01-23</ref> there is no known survey of fee estimation quality across a large number of popular wallets as of early 2018.<br />
<br />
In addition, also as of early 2018, some techniques have recently been described that could significantly improve fee estimation, such as factoring current [[mempool]] data into confirmation-based fee estimates.<ref name="mempool-fee-est-slides">[https://scalingbitcoin.org/stanford2017/Day2/Scaling-2017-Optimizing-fee-estimation-via-the-mempool-state.pdf Optimizing fee estimation via the mempool state (slides, PDF)], Karl-Johan Alm, Scaling Bitcoin 2017 (Stanford), 2017-11-05, retrieved 2018-01-23</ref><ref name="mempool-fee-est-video">[https://www.youtube.com/watch?v=QkYXPJMqBNk&feature=youtu.be&t=2033 Optimizing fee estimation via the mempool state (presentation video)], Karl-Johan Alm, Scaling Bitcoin 2017 (Stanford), 2017-11-05, retrieved 2018-01-23</ref><br />
<br />
See also<br />
<br />
* [[Transaction fees]]<br />
* [https://blog.bitgo.com/the-challenges-of-bitcoin-transaction-fee-estimation-e47a64a61c72 The Challenges of Bitcoin Transaction Fee Estimation] - Jameson Lopp<br />
* [https://gist.github.com/morcos/d3637f015bc4e607e1fd10d8351e9f41 High level description Bitcoin Core's fee estimation algorithm] - Alex Morcos<br />
<br />
=== Patient spending ===<br />
<br />
''Very useful for non-urgent transactions. Not useful for urgent transactions''<br />
<br />
Spenders who can patiently wait for their transactions to confirm can take advantage of variations in the [[Transaction fees#feerates|feerate]] necessary to achive confirmation. For example, sometimes several Bitcoin blocks are produced in quick succession, raising the effective supply of block space by several multiples; other times, demand drops off, such as fees on Sunday being on average 20% lower than fees on Friday in Q4 2017<ref>[[Transaction_fees#The_market_for_block_space]], Bitcoin Wiki, retrieved 2018-01-27</ref>. Looking at data from the widely-used fee estimator included in Bitcoin Core, we can see fee savings of 90% or more possible, with around 50% being easily obtainable by many patient spenders.<br />
<br />
[[File:Feerate-estimates.png|center]]<br />
<br />
In the data plotted above, the Bitcoin Core fee estimator suggests that for this sample period the following savings are available:<br />
<br />
{|<br />
! Wait<br />
! Conservative savings<br />
! Economical savings*<br />
|-<br />
| 2 hours<br />
| 5% <br />
| 5%<br />
|-<br />
| 6 hours<br />
| 18%<br />
| 55%<br />
|-<br />
| 12 hours <br />
| 39%<br />
| 55%<br />
|-<br />
| 24 hours (1 day)<br />
| 39% <br />
| 55%<br />
|-<br />
| 48 hours (2 days) <br />
| 47% <br />
| 55%<br />
|-<br />
| 72 hours (3 days) <br />
| 52% <br />
| 55%<br />
|-<br />
| 96 hours (4 days) <br />
| 92% <br />
| 92%<br />
|}<br />
<br />
''* Economical savings have a lower probability of being achieved and are recommended for use with the transaction replacability described in a later section.''<br />
<br />
Although waiting up to four days is impractical for many use cases, there are also many cases where it can be practical. A few examples: moving funds between one's own wallets, [[#Consolidation|consolidating]] many smaller inputs into one larger input that can be more efficiently spent, or payments or remittances to friends or family who trust the spender and so don't need fast confirmation.<br />
<br />
See also:<br />
<br />
* [https://p2sh.info/dashboard/db/fee-estimation P2SH.info] - Fee estimates from multiple sources<br />
* [[Transaction_fees#Fee_Plotting_Sites|Other fee plotting sites]]<br />
<br />
=== Opt-in transaction replacement ===<br />
<br />
''Universally useful, but may cause UI issues in recipient wallets''<br />
<br />
Although not strictly a method for reducing fees by itself, opt-in transaction replacement allows a wallet to update previously-sent transactions with new versions that pay higher fees and, possibly, make other changes to the transaction. The method is also called opt-in Replace-By-Fee (RBF). This technique allows wallets to initially pay lower fees in case there's a sudden increase in the supply of block space, a sudden decrease in demand for that space, or another situation that increases the chance of low-fee transactions being confirmed. If none of those things happens, the spender can then increase ("bump") the transaction's fee to increase its probability of confirming.<br />
<br />
This often allows wallets that support transaction replacement to pay lower fees than wallets that don't support replacement.<br />
<br />
Transaction replacement can appear odd in some recipient wallets. Wallets such as Bitcoin Core (pictured below) show each replacement as a separate payment in the list of transactions. When one version of the replacements is confirmed, it is shown as a normal transaction; the other versions are then shown with an X icon to indicate that they are [[conflicted]] (cannot occur together in the same valid block chain). This helps communicate the status of all affected payments to the recipient, but it may not be entirely clear what's happening to users who aren't familar with replacements. Other wallets may not show transactions opting in to replacement at all until one version of the transaction has been confirmed. There's no clear community consensus on the correct way to handle this situation using user interfaces, documentation, or both.<br />
<br />
[[File:Fee-bump-ux.png|thumb|right|200px|List of transaction replacements in Bitcoin Core 0.15.0]]<br />
<br />
Transaction replacement can be advantageously combined with ''payment batching'' (described previously). Instead of waiting, for example, 30 minutes to batch all outgoing payments, the spender can batch the first 10 minutes of payments with a low feerate. If that doesn't get confirmed within 10 minutes, the spender can replace that transaction with a slightly higher feerate transaction that also includes then next 10 minutes of payments. If that again doesn't confirm, another update can also include the third 10 minutes of transactions at the original intended feerate. This allows the recipients of the first 10 minutes of payments to receive a notification that the payment has been sent up to 20 minutes earlier than with normal batching, and it also gives those early payments a chance to confirm at a lower-than-expected feerate. Updating a batched transaction with more payments can be done as many times as necessary up to a [[relay limit]] on transaction size of 100 kilobytes.<br />
<br />
Currently, transaction replacement does have one significant downside: it tends to reduce privacy. When the fee on a transaction is increased, either additional inputs must be added or the value of the [[change output]] must be decreased. In either case, this makes the change output easier to identify among the different outputs being paid by a transaction. Value-blinding techniques such as [[confidential transactions]] could improve this situation, but there are no near-term plans to add such a feature to Bitcoin as of early 2018. If transaction replacement is always combined with [[#change_avoidance|change avoidance]], it could avoid this privacy issue.<br />
<br />
See also:<br />
<br />
* [[Transaction replacement]]<br />
* [https://bitcoincore.org/en/faq/optin_rbf/ Opt-in Replace-By-Fee (RBF) FAQ] - BitcoinCore.org<br />
* [https://github.com/bitcoin/bips/blob/master/bip-0125.mediawiki BIP125] - Opt-in Full Replace-by-Fee Signaling<br />
<br />
==== Pre-computed fee bumping ====<br />
<br />
Pre-computed fee bumping is an idea to create and sign multiple replacements for a transaction at the time the initial transaction is created. The initial transaction version could be broadcast immediately, and each of the replacements would pay successively higher fees. This idea could be combined with Bitcoin's existing [[nLockTime]] feature to allow the replacement versions to forbid being included in a block earlier than a specified time or [[block height]], which would allow the replacements to be trustlessly transmitted to third parties (even miners themselves). <br />
<br />
For example, Alice would tell her wallet that she wanted to pay Bob within the next 10 blocks and also indicate what is the highest fee she’s willing to pay. Alice's wallet would then use its existing fee estimation feature to create an initial version of the transaction to Bob that paid the lowest expected fee for a transaction to confirm within 10 blocks. At the same time, Alice's wallet would also create possibly 9 other versions of the transaction, the first one using nLockTime to ensure it can’t be added until two blocks from now; the second timelocked until three blocks from now; etc…<br />
<br />
Each of these subsequent transactions would pay a slightly higher fee than the original transaction (up to Alice’s indicated max fee) to increase the incentive for miners to mine that transaction.<br />
<br />
Because all versions of the transaction would be signed at the time Alice sent the initial transaction, she would only need to unlock her wallet once. Also, because all subsequent versions of the transaction would use nLockTime, Alice could trustlessly distribute copies of these transactions to other people for later broadcast in case she went offline.<br />
<br />
In short, the software would automatically offer Alice’s maximum fee if it had to, but it’d pay a lower fee if it could get away with it—ensuring Alice got close to the best price possible without any extra effort on her part.<br />
<br />
See also:<br />
<br />
* [https://bitcoincore.org/en/meetings/2017/03/02/#big-features-for-0150 Bitcoin Core IRC meeting summary for 2017-03-02] - See "Precomputed fee bumping" bullet point<br />
<br />
== Offchain payments ==<br />
<br />
Not every Bitcoin payment needs to be added to the Bitcoin block chain. For example, imagine Alice pays 1 BTC to Bob, and then Bob pays 1 BTC to Charlie. Instead of adding both of these payments to the block chain, we could more efficiently just add a 1 BTC payment from Alice to Charlie.<br />
<br />
An early description using this specific optimization called it ''transaction cut-through,''<ref>[https://bitcointalk.org/index.php?topic=281848.0 Transaction cut-through], Gregory Maxwell, 2013-08-23, retrieved 2018-01-25</ref> but the concept of not every payment being recorded on the block chain is more widely known today as ''off-chain payments.''<br />
<br />
Up to 99% of all Bitcoin payments are estimated to be offchain payments<ref>[http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-June/008844.html Pure off-chain is a weak form of layer 2], Adam Back, 19 June 2015</ref>, with most of them likely being buy and sell orders on Bitcoin exchanges. Other third-parties may also help facilitate offchain payments for their users, for example tipping services. These services can be extraordinarily efficient because they don't carry Bitcoin's burden of maintaining consensus among a large set of users—but this efficiency comes at a cost of generally requiring that users trust the service operators not to steal funds. These are ''unenforceable offchain payments.''<br />
<br />
However, there also exist ''enforceable offchain payments'' where no trust in a specific third-party is required—only trust in Bitcoin continuing to operate without transaction censorship.<br />
<br />
This section currently focuses on enforceable offchain payments, but it may later be expanded to cover concepts for unenforcable offchain payments that use cryptography and other security solutions to provide more secure and more private solutions than simple trusted third parties.<br />
<br />
=== Payment channels ===<br />
<br />
''Very useful for small-size and moderate-size payments, but not yet widely deployed as of early 2018''<br />
<br />
[[Payment channels]] are a type of ''enforceable offchain payment'' where bitcoins are deposited into a [[smart contract]] between two or more parties, allowing the involved peers to make trustless payments to each other. Combined with [[hashlock]]s, payments can be securely routed across a network of peers, as in the [[Lightning Network]], allowing Alice to pay Charlie by routing a payment through their mutual peer Bob.<br />
<br />
Opening a payment channel requires a confirmed transaction, incurring the cost of the fees for that transaction, although those fees are identical to sending a regular transaction. Closing a channel also requires a confirmed transaction, adding that transaction's fees to the cost of the payment channel, although those fees too are similar to the costs of the recipient of the funds re-spending them to a new recipient. This means a payment channel's fee cost is very similar to making onchain payments.<br />
<br />
Outside of the channel open and channel close transactions, a payment channel can support an unlimited number of payments without paying any further transaction fees. This can make them extraordinarily efficient—for example, imagine making a million in-channel payments for the cost of just two transaction fees. Note: your channel peers and other channel nodes you route payments through may require their own fee for using their services; these are not related to the transaction fees that are the topic of this article.<br />
<br />
As of early 2018, no payment channel implementation is widely used, but several cooperating implementations of a first version of [[Lightning Network]] are available.<br />
<br />
See also:<br />
<br />
* [[Payment channels]]<br />
* [[Lightning Network]]<br />
<br />
== Potential future improvements ==<br />
<br />
Some of the following improvements and proposed improvements may become available to Bitcoin users. Users who adopt the improvements may be able to further lower their fees.<br />
<br />
* Efficiency improvements<br />
** '''Public key and signature aggregation:''' the ability to combine multiple public keys and signatures into a single public key and signature, allowing multisig transactions to be as efficient to spend as single-signature transactions are today. It may also be possible to combine signatures from multiple inputs in a transaction. It is hopped that this will be possible with variant of [[Schnorr signatures]]. Requires a [[soft fork]].<br />
** '''Merkelized Abstract Syntax Trees (MAST):''' a method for committing to spending scripts that allows the partial omission of unused conditions, allowing complex scripts to be much more efficient,<ref>[https://bitcointechtalk.com/what-is-a-bitcoin-merklized-abstract-syntax-tree-mast-33fdf2da5e2f What is a Bitcoin Merkelized Abstract Syntax Tree?], David A. Harding, BitcoinTechTalk.com, 2017-10-12, retrieved 2018-01-27</ref> even more so if used with [[taproot]]<ref>[https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2018-January/015614.html Taproot: Privacy preserving switchable scripting], Gregory Maxwell, Bitcoin-Dev mailing list, 2018-01-23</ref>. Combines well with signature aggregation (described above) in certain use cases. Requires a [[soft fork]].<br />
** '''CoinJoin with signature aggregation:''' [[CoinJoin]] is a technology for Bitcoin that enhances privacy without reducing security. A group of patient spenders can enter a coinjoin together and obfuscate which of them paid which recipient and which change outputs (if any) they received back. Combined with signature aggregation (described in a previous bullet point), this enhanced privacy mode would be cheaper than each spender making a separate less-private transaction—and it would still be just as secure.<ref>[https://diyhpl.us/wiki/transcripts/scalingbitcoin/milan/schnorr-signatures/ Elliptic curve Schnorr-based signatures in Bitcoin], Pieter Wuille, Scaling Bitcoin 2016 (Milan), 2016-10-09, retrieved 2018-01-27</ref> Requires the signature aggregation soft fork described previously.<br />
<br />
* Intelligent fee selection<br />
** '''Mempool-using fee estimation:''' a potential improvement in fee estimation that considers not just which transactions have been recently confirmed but also the queue of currently unconfirmed transactions.<ref name="mempool-fee-est-slides"/><ref name="mempool-fee-est-video"/> Does not require any protocol changes.<br />
<br />
* Offchain payments<br />
** '''Channel factories:''' (enforceable offchain payments) a potentially more efficient way to open payment channels such as those used by Lightning Network. Combined with signature aggregation (described above) this could reduce the cost of opening a payment channel by up to 96%.<ref>[https://www.tik.ee.ethz.ch/file/a20a865ce40d40c8f942cf206a7cba96/Scalable_Funding_Of_Blockchain_Micropayment_Networks%20(1).pdf Scalable Funding of Bitcoin Micropayment Channel Networks]; Conrad Burchert, Christian Decker, and Roger Wattenhofer; retrieved 2018-01-27</ref> Does not require any [[consensus]] changes.<br />
** '''Chaumian banks:''' (unenforceable offchain payments) a trusted third party who controls bitcoins for a pool of Bitcoin users ([[custodial wallet]], AKA "Bitcoin bank") but who can't know which users own which bitcoins. This is accomplished using [[Chaum blinded signatures]].<ref>[https://medium.com/@nopara73/chaumian-e-cash-for-custodial-bitcoin-wallets-and-services-to-scale-bitcoin-8977d9a03064 Chaumian E-Cash For Custodial Bitcoin Wallets And Services To Scale Bitcoin], nopara73, Medium.com, 2017-12-22, retrieved 2018-01-27</ref> Combined with [[hardware security modules]], it could be made extremely difficult for banks to steal depositor funds.<ref>[https://bitcointalk.org/index.php?topic=146307.0 Fidelity-bonded banks: decentralized, auditable, private, off-chain payments], Peter Todd, 2013-02-23, retrieved 2018-01-27</ref> Does not require any protocol changes.<br />
** '''Strong federations (sidechains)''' (unenforceable offchain payments) a set of trusted third parties controls bitcoins for a pool of Bitcoin users, but uses multisig to prevent an individual or small number of those trusted third parties from stealing depositor funds. Uses a public block chain (but not Bitcoin's block chain) to allow any user to audit all transfers into, out of, or within the system. Hardware security modules (HSMs) are used to further reduce trust in the third parties.<ref>[https://blockstream.com/strong-federations.pdf Strong Federations: An Interoperable Blockchain Solution to Centralized Third Party Risks]; Johnny Dilley, Andrew Poelstra, Jonathan Wilkins, Marta Piekarska, Ben Gorlick, and Mark Friedenbach; retrieved 2018-01-28</ref> Although a block chain is used, this qualifies as an offchain payment solution from the perspective of Bitcoin. As of early 2018, free software federated [[sidechain]] software provides support for [[confidential transactions]]<ref>[https://elementsproject.org/elements/confidential-transactions/ Confidential Transactions], ElementsProject.org, retrieved 2018-01-28</ref> that give them many of the same benefits of the Chaumian banks described in a previous bullet point, but federated sidechain software can (and does) support many other features also.<ref>[https://elementsproject.org/elements/ Elements (features)], ElementsProject.org, retrieved 2018-01-28</ref><br />
<br />
== References ==<br />
<br />
<references /></div>Hardinghttps://en.bitcoin.it/w/index.php?title=Techniques_to_reduce_transaction_fees&diff=64944Techniques to reduce transaction fees2018-01-29T18:09:23Z<p>Harding: /* Native segwit */ mention using for change outputs (suggestion from IRC, thanks!)</p>
<hr />
<div>This page provides a list of currently-available techniques that may allow spenders to reduce the amount of [[transaction fee]] they pay. Not all techniques will apply to all situations, and some techniques require trading off other benefits for lower fees.<br />
<br />
Note, this page only describes techniques that apply to payment-oriented transactions. Data carrier transactions (e.g. [[OP_RETURN]] or [[OpenTimestamps]]), [[colored coin]] protocols, and other proposed uses of Bitcoin transactions may benefit from some of the following techniques, but the recommendations are not aimed at those use cases.<br />
<br />
== Efficiency improvements ==<br />
<br />
Creating transactions that are smaller in size ([[Weight units|weight]]), or which accomplish more for a given size, provide a more efficient way of using scarce block space and so pay less total fee to achieve a [[Transaction fees#feerates|feerate]] that is equivalent to less efficient payments. This section describes several techniques for producing more efficient transactions.<br />
<br />
Technically ''offchain payments'' such as those made in [[payment channels]] are a type of extremely efficient payment and so belong to this category, but they've been given a separate category because of the distinctive way they achieve their high efficiency.<br />
<br />
=== Compressed public keys ===<br />
<br />
''Universally useful but already widely deployed''<br />
<br />
The original Bitcoin software released in 2009 used 65-byte uncompressed public keys to identify the owner of a set of bitcoins. In 2012, Bitcoin protocol developer Pieter Wuille implemented a change to the program now known as Bitcoin Core that allowed it to use 33-byte compressed public keys instead.<ref>[https://bitcoin.org/en/release/v0.6.0#new-features-since-bitcoin-version-05 Bitcoin Core 0.6.0 release notes], Bitcoin.org, 2012-03-20, retrieved 2018-01-27</ref> As Bitcoin Core users adopted this feature and other wallets upgraded to use it as well, this reduced the size of a typical transaction on the network (with one input and two outputs) from about 258 bytes to about 226 bytes, a 14% savings.<br />
<br />
[[File:Uncompressed-pubkey-percentage.png|center|800px|thumb|The percentage of transaction inputs per block using the old uncompressed pubkey format in their scriptSigs. Note: early Bitcoin transactions often placed pubkeys in their scriptPubKeys rather than their scriptSigs.]]<br />
<br />
The change was fully backwards compatible and did not change security in any way, but it did require users wanting to access the space savings to generate new Bitcoin addresses.<br />
<br />
Since 2012, many wallets have adopted compressed public keys—but still some wallets continue to use the less efficient uncompressed public keys. These wallets could achieve a significant savings in transaction fees for the same priority by switching to compressed public keys. If all wallets adopted it, this would effectively lead to a small increase in the available block space:<br />
<br />
[[File:Uncompressed-pubkey-savings.png|center|800px|thumb|The percentage of the maximum available block space consumed by the extra bytes in uncompressed pubkeys]]<br />
<br />
See also:<br />
<br />
* [https://bitcoin.org/en/developer-guide#public-key-formats Compressed public keys] — Bitcoin.org Developer Guide<br />
* [https://bitcoin.org/en/release/v0.6.0#new-features-since-bitcoin-version-05 Bitcoin Core 0.6.0 release notes]<br />
* [https://github.com/bitcoin/bips/blob/master/bip-0143.mediawiki#Restrictions_on_public_key_type BIP143] - Requires all pubkeys in [[segregated witness]] witnesses be compressed pubkeys<br />
<br />
=== Payment batching ===<br />
<br />
''Very useful for high-frequency spenders (e.g. organizations); moderately useful for lower-frequency spenders (e.g. individuals)''<br />
<br />
Every Bitcoin transaction must reference the funds being spent and provide proof that the transaction was authorized by the owner of those funds. To spend a single collection of funds takes a minimum of 79 vbytes under normal circumstances. This same amount of block space is used no matter how many recipients are paid in that transaction. For example, consider the following two scenarios:<br />
<br />
* Alice pays Bob in one transaction and then pays Charlie in a second transaction. Each transaction contains a minimum of 79 vbytes related to the funds being spent—a total of 158 vbytes.<br />
* Alice uses a single transaction to pay both Bob and Charlie. The single transaction only needs one set of 79 vbytes related to the funds being spent—a savings of 50% for this field.<br />
<br />
This type of savings increases as more payments are added to a single transaction until the cost per payment is just barely more than the cost of adding the vbytes directly related to that payment in the transaction. The plot below shows the cost per payment for a native segwit [[P2WPKH]] transaction paying other P2WPKH outputs:<br />
<br />
[[File:Batching.png|center]]<br />
<br />
We see the cost drop by more than 50% after five payments are added, with the savings increasing up to about 70% for segwit transactions. Not shown is that the savings increase up to about 80% for legacy transactions because these transactions start off less efficient than segwit transactions. That's a major benefit and one that's easily obtainable by high-frequency spenders, such as organizations.<br />
<br />
Many wallets support batching payments. In graphical wallets, there's often a button that allows you add additional recipients to a transaction (see image below). In command-line and RPC wallets, there's often a call such as <code>sendmany</code> that lets you pay multiple recipients.<br />
<br />
[[File:Bitcoin-core-add-recipient.png|thumb|200px|right|Add Recipient button in Bitcoin Core 0.15.0]]<br />
<br />
Note that there are other parts of a transaction that stay a constant size (or nearly so) when payments are added, so the benefits stack up faster than a fixed cost of just 79 vbytes might suggest. The section below about ''change avoidance'' addresses how one of these cases can itself be eliminated as a cost.<br />
<br />
See also:<br />
<br />
* [https://bitcointechtalk.com/saving-up-to-80-on-bitcoin-transaction-fees-by-batching-payments-4147ab7009fb Saving up to 80% on Bitcoin transaction fees by batching payments]<br />
* [https://bitcoin.org/en/developer-reference#sendmany SendMany RPC] - Bitcoin.org Developer Reference<br />
<br />
=== P2SH-wrapped segwit ===<br />
<br />
''Universally useful''<br />
<br />
Transactions that spend bitcoins secured by [[segregated witness]] (segwit) use less space in a block than equivalent non-segwit (legacy) transactions, allowing segwit transactions to pay less total fee to achieve the same [[Transaction fees#feerates|feerate]] as legacy transactions. The amount of savings varies depending on the details of your transaction, but here are a few common transaction types an an example:<br />
<br />
{|<br />
! Type<br />
! Legacy vbytes<br />
! P2SH-wrapped<br>segwit vbytes<br />
! Savings<br />
|-<br />
| Single signature<br />
| 226<br />
| 167<br />
| 36%<br />
|-<br />
| 2-of-2 multisig<br />
| 335<br />
| 197<br />
| 70%<br />
|-<br />
| 2-of-3 multisig<br />
| 369<br />
| 206<br />
| 80%<br />
|}<br />
<br />
Note that the multisig examples above use the same security as the equivalent legacy P2SH multisig. Segwit optionally allows access to a multisig form that is more secure on one dimension but it requires an extra 12 vbytes per output, which would reduce efficiency somewhat.<br />
<br />
To access these savings, you must use a wallet that supports generating P2SH-wrapped segwit addresses (addresses that start with a "3", although not all addresses that start with a 3 are segwit-enabled). When you spend bitcoins received to these P2SH-wrapped segwit addresses, your transactions will automatically consume less block space, allowing your wallet to pay proportionally less fee.<br />
<br />
See also:<br />
<br />
* [[Segregated Witness]]<br />
* [https://bitcoincore.org/en/segwit_wallet_dev/ Segregated Witness Wallet Development Guide] - BitcoinCore.org<br />
* [https://bitcoincore.org/en/segwit_adoption/ List of wallets, libraries, and services that support segwit] - BitcoinCore.org<br />
<br />
=== Native segwit ===<br />
<br />
''Universally useful. Complete usage requires native segwit adoption by the people sending you bitcoins, but you may be able to use it for your [[change outputs]] immediately''<br />
<br />
The P2SH-wrapped segwit described above is backwards compatible with the P2SH address format supported by older wallets, but a new and non-backwards compatible format is available that saves additional space. The following examples and savings are compared to the size of the P2SH-wrapped examples above:<br />
<br />
{|<br />
! Type<br />
! P2SH-wrapped<br>segwit vbytes<br />
! Native segwit<br>vbytes<br />
! Additional<br>savings<br />
|-<br />
| Single signature<br />
| 167<br />
| 141<br />
| 19%<br />
|-<br />
| 2-of-2 multisig<br />
| 197<br />
| 169<br />
| 17%<br />
|-<br />
| 2-of-3 multisig<br />
| 206<br />
| 178<br />
| 16%<br />
|}<br />
<br />
To access these savings, you must use a wallet that supports generating native segwit addresses, called [[bech32]] addresses (addresses that start with a "bc1"). When you spend bitcoins received to these native segwit addresses, your transactions will automatically consume less block space than even P2SH-wrapped segwit addresses, allowing your wallet to pay proportionally less fee.<br />
<br />
Once a wallet supports native segwit, it can begin using it immediately for any [[change outputs]] it generates back to itself without waiting for anyone else to begin using native segwit. In early 2018, when native segwit adoption is low, this may make it easier to identify which output is change and so reduce your privacy. However, once native segwit adoption increases just slightly, this is not expected to adversely affect privacy.<br />
<br />
See also:<br />
<br />
* [[Bech32 adoption]]<br />
* [https://github.com/bitcoin/bips/blob/master/bip-0173.mediawiki BIP173] — Bech32 addresses<br />
<br />
=== Change avoidance ===<br />
<br />
''Useful for high-frequency recipients (e.g. organizations), especially those who already effectively use transaction batching''<br />
<br />
When a Bitcoin transaction references the funds it wants to spend, it's required to spend all of those funds. For example, if you received 5 BTC in a previous transaction and now you want to spend 2 BTC, Bitcoin requires that you spend all 5 BTC. For this reason, almost all Bitcoin transactions currently pay some bitcoins back to the spender. For example, you'd return the remaining 3 BTC from the previous example back to yourself. This return of money to yourself is called ''change'' by analogy to the change a store clerk hands you when you (for example) buy a $2 item with a $5 bill.<br />
<br />
A typical change output adds about 32 vbytes to the size of a transaction. If the spender can pay with exact change—that is, doesn't need to refund any change to them self—they can eliminate the change output and generate transactions that are up to 23% smaller. In addition, a change output will later be spent at a typical cost of 69 vbytes or more, but when paying with exact change, this future cost is also avoided.<br />
<br />
To use change avoidance requires having previously received a payment or set of payments that's close to the size of the amount being spent (including the transaction fee). This can be rare in the case of individual user wallets that don't receive many payments to choose from and can't significantly vary the amount of their spending transactions, but for organization wallets that receive many payments and already use payment batching to combine multiple outgoing payments, change avoidance can be an easily-obtainable efficiency improvement.<br />
<br />
The spender doesn't need to match the inputs and outputs of their transaction exactly to Bitcoin's full 10 nanobitcoin precision, but can instead overpay or underpay fees slightly by including inputs that are (respectively) slightly more or slightly less than the desired amount. Even when paying slightly more fees than desired, this can result in savings if the slight increase in fees is still less than would normally be paid for the extra 32 vbytes (or so) for a change output and the typical mininum of 69 vbytes for later spending that output.<ref>[https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2018-January/015606.html Transaction Merging (bip125 relaxation)], Rhavar, bitcoin-dev mailing list, 2018-01-22</ref> When paying slightly lower fees, confirmation of the transaction may be delayed, but current-generation (2018) fee estimates are still inaccurate enough that small differences in feerates may not strongly correlate to delays.<br />
<br />
See also:<br />
<br />
* [http://murch.one/wp-content/uploads/2016/11/erhardt2016coinselection.pdf An Evaluation of Coin Selection Strategies] - Mark Erhardt<br />
* [https://github.com/bitcoin/bitcoin/pull/10637 Bitcoin Core pull request #10,637] - A proposed implementation of Erhardt's "branch and bound" strategy<br />
* [https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2018-January/015606.html Bitcoin-Dev mailing list post] - With good coin selection, I am able to avoid change about ~75% of the time in my simulations..."<br />
<br />
=== Consolidation ===<br />
<br />
''Useful for all wallets but may require users sacrifice some privacy''<br />
<br />
The amount of fee a transaction pays is proportional to its size in [[vbytes]], and one the main contributors to size is the number of [[inputs]] the transaction spends. Each input is a reference to the funds the transaction wants to spend, and when a wallet contains only low-value inputs, it can't create a comparatively higher output paying a recipient without adding many of those inputs to the transaction. Each input adds a minimum of 41 vbytes to the transaction and almost always 69 or more vbytes, so any strategy that reduces the number of inputs is worth considering.<br />
<br />
Given that [[Transaction_fees#The_market_for_block_space|fees vary over time]], one method that can reduce overall fees is input consolidation—combining a set of smaller inputs into a single larger input by spending them from yourself to yourself during a period of time when fees are lower than normal. For example, if your usual target feerate during normal-priced fee periods is 100 nanobitcoins per vbyte and the current feerate is 10 nanobitcoins per vbyte, you could save up to almost 90% on fees by consolidating now before you next need to spend some of those inputs.<br />
<br />
[[File:Consolidation-savings.png|center]]<br />
<br />
Consolidation does come with the overhead of creating the consolidation transaction, which is equal to the cost of spending one input to one output, which is about 110 vbytes for P2WPKH inputs/outputs. Also, if you combine inputs that were originally sent to addresses unconnected to each other, you may reduce your privacy in some cases by making that connection in your consolidation transaction (although it's believed that few people currently manage to spend their inputs in a manner that preserves this element of privacy).<br />
<br />
See also:<br />
<br />
* [[How to cheaply consolidate coins to reduce miner fees]]<br />
<br />
== Intelligent fee selection ==<br />
<br />
When it comes to fees, sending a Bitcoin transaction is similar to mailing a package: you can pay a high fee for fast high-priority service or a lower fee for slower low-priority service. This section describes several techniques for taking advantage of the more affordable low-priority service.<br />
<br />
=== Dynamic fee estimation ===<br />
<br />
''Universally useful. Already widely deployed but still being improved as research and development continues''<br />
<br />
Early Bitcoin wallets often defaulted to paying a fixed fee on every transaction—enough to incentivize a miner to include it but not enough to compete against other transactions seeking confirmation in a [[fee market]]. As blocks have filled, this has changed, and as of early 2018 all widely-used wallets use dynamic fee estimation to select a fee based on the condition of the current fee market.<br />
<br />
[[File:Bitcoin-core-fee-selector.png|thumb|200px|right|Fee selector in Bitcoin Core 0.15.0]]<br />
<br />
However, some fee estimation tools may be better than others, achieving confirmation by the desired time even when paying lower fees. Although data from multiple wallets and fee estimation services can be compared<ref>[https://www.p2sh.info/dashboard/db/fee-estimation Fee Estimation], P2SH.info, retrieved 2018-01-23</ref> and there have been some attempts to compare fee estimation between different wallets,<ref>[https://blog.bitgo.com/the-challenges-of-bitcoin-transaction-fee-estimation-e47a64a61c72 The Challenges of Bitcoin Transaction Fee Estimation], Jameson Lopp, BitGo block, 2017-05-10, retrieved 2018-01-23</ref> there is no known survey of fee estimation quality across a large number of popular wallets as of early 2018.<br />
<br />
In addition, also as of early 2018, some techniques have recently been described that could significantly improve fee estimation, such as factoring current [[mempool]] data into confirmation-based fee estimates.<ref name="mempool-fee-est-slides">[https://scalingbitcoin.org/stanford2017/Day2/Scaling-2017-Optimizing-fee-estimation-via-the-mempool-state.pdf Optimizing fee estimation via the mempool state (slides, PDF)], Karl-Johan Alm, Scaling Bitcoin 2017 (Stanford), 2017-11-05, retrieved 2018-01-23</ref><ref name="mempool-fee-est-video">[https://www.youtube.com/watch?v=QkYXPJMqBNk&feature=youtu.be&t=2033 Optimizing fee estimation via the mempool state (presentation video)], Karl-Johan Alm, Scaling Bitcoin 2017 (Stanford), 2017-11-05, retrieved 2018-01-23</ref><br />
<br />
See also<br />
<br />
* [[Transaction fees]]<br />
* [https://blog.bitgo.com/the-challenges-of-bitcoin-transaction-fee-estimation-e47a64a61c72 The Challenges of Bitcoin Transaction Fee Estimation] - Jameson Lopp<br />
* [https://gist.github.com/morcos/d3637f015bc4e607e1fd10d8351e9f41 High level description Bitcoin Core's fee estimation algorithm] - Alex Morcos<br />
<br />
=== Patient spending ===<br />
<br />
''Very useful for non-urgent transactions. Not useful for urgent transactions''<br />
<br />
Spenders who can patiently wait for their transactions to confirm can take advantage of variations in the [[Transaction fees#feerates|feerate]] necessary to achive confirmation. For example, sometimes several Bitcoin blocks are produced in quick succession, raising the effective supply of block space by several multiples; other times, demand drops off, such as fees on Sunday being on average 20% lower than fees on Friday in Q4 2017<ref>[[Transaction_fees#The_market_for_block_space]], Bitcoin Wiki, retrieved 2018-01-27</ref>. Looking at data from the widely-used fee estimator included in Bitcoin Core, we can see fee savings of 90% or more possible, with around 50% being easily obtainable by many patient spenders.<br />
<br />
[[File:Feerate-estimates.png|center]]<br />
<br />
In the data plotted above, the Bitcoin Core fee estimator suggests that for this sample period the following savings are available:<br />
<br />
{|<br />
! Wait<br />
! Conservative savings<br />
! Economical savings*<br />
|-<br />
| 2 hours<br />
| 5% <br />
| 5%<br />
|-<br />
| 6 hours<br />
| 18%<br />
| 55%<br />
|-<br />
| 12 hours <br />
| 39%<br />
| 55%<br />
|-<br />
| 24 hours (1 day)<br />
| 39% <br />
| 55%<br />
|-<br />
| 48 hours (2 days) <br />
| 47% <br />
| 55%<br />
|-<br />
| 72 hours (3 days) <br />
| 52% <br />
| 55%<br />
|-<br />
| 96 hours (4 days) <br />
| 92% <br />
| 92%<br />
|}<br />
<br />
''* Economical savings have a lower probability of being achieved and are recommended for use with the transaction replacability described in a later section.''<br />
<br />
Although waiting up to four days is impractical for many use cases, there are also many cases where it can be practical. A few examples: moving funds between one's own wallets, [[#Consolidation|consolidating]] many smaller inputs into one larger input that can be more efficiently spent, or payments or remittances to friends or family who trust the spender and so don't need fast confirmation.<br />
<br />
See also:<br />
<br />
* [https://p2sh.info/dashboard/db/fee-estimation P2SH.info] - Fee estimates from multiple sources<br />
* [[Transaction_fees#Fee_Plotting_Sites|Other fee plotting sites]]<br />
<br />
=== Opt-in transaction replacement ===<br />
<br />
''Universally useful, but may cause UI issues in recipient wallets''<br />
<br />
Although not strictly a method for reducing fees by itself, opt-in transaction replacement allows a wallet to update previously-sent transactions with new versions that pay higher fees and, possibly, make other changes to the transaction. The method is also called opt-in Replace-By-Fee (RBF). This technique allows wallets to initially pay lower fees in case there's a sudden increase in the supply of block space, a sudden decrease in demand for that space, or another situation that increases the chance of low-fee transactions being confirmed. If none of those things happens, the spender can then increase ("bump") the transaction's fee to increase its probability of confirming.<br />
<br />
This often allows wallets that support transaction replacement to pay lower fees than wallets that don't support replacement.<br />
<br />
Transaction replacement can appear odd in some recipient wallets. Wallets such as Bitcoin Core (pictured below) show each replacement as a separate payment in the list of transactions. When one version of the replacements is confirmed, it is shown as a normal transaction; the other versions are then shown with an X icon to indicate that they are [[conflicted]] (cannot occur together in the same valid block chain). This helps communicate the status of all affected payments to the recipient, but it may not be entirely clear what's happening to users who aren't familar with replacements. Other wallets may not show transactions opting in to replacement at all until one version of the transaction has been confirmed. There's no clear community consensus on the correct way to handle this situation using user interfaces, documentation, or both.<br />
<br />
[[File:Fee-bump-ux.png|thumb|right|200px|List of transaction replacements in Bitcoin Core 0.15.0]]<br />
<br />
Transaction replacement can be advantageously combined with ''payment batching'' (described previously). Instead of waiting, for example, 30 minutes to batch all outgoing payments, the spender can batch the first 10 minutes of payments with a low feerate. If that doesn't get confirmed within 10 minutes, the spender can replace that transaction with a slightly higher feerate transaction that also includes then next 10 minutes of payments. If that again doesn't confirm, another update can also include the third 10 minutes of transactions at the original intended feerate. This allows the recipients of the first 10 minutes of payments to receive a notification that the payment has been sent up to 20 minutes earlier than with normal batching, and it also gives those early payments a chance to confirm at a lower-than-expected feerate. Updating a batched transaction with more payments can be done as many times as necessary up to a [[relay limit]] on transaction size of 100 kilobytes.<br />
<br />
Currently, transaction replacement does have one significant downside: it tends to reduce privacy. When the fee on a transaction is increased, either additional inputs must be added or the value of the [[change output]] must be decreased. In either case, this makes the change output easier to identify among the different outputs being paid by a transaction. Value-blinding techniques such as [[confidential transactions]] could improve this situation, but there are no near-term plans to add such a feature to Bitcoin as of early 2018. If transaction replacement is always combined with [[#change_avoidance|change avoidance]], it could avoid this privacy issue.<br />
<br />
See also:<br />
<br />
* [[Transaction replacement]]<br />
* [https://bitcoincore.org/en/faq/optin_rbf/ Opt-in Replace-By-Fee (RBF) FAQ] - BitcoinCore.org<br />
* [https://github.com/bitcoin/bips/blob/master/bip-0125.mediawiki BIP125] - Opt-in Full Replace-by-Fee Signaling<br />
<br />
==== Pre-computed fee bumping ====<br />
<br />
Pre-computed fee bumping is an idea to create and sign multiple replacements for a transaction at the time the initial transaction is created. The initial transaction version could be broadcast immediately, and each of the replacements would pay successively higher fees. This idea could be combined with Bitcoin's existing [[nLockTime]] feature to allow the replacement versions to forbid being included in a block earlier than a specified time or [[block height]], which would allow the replacements to be trustlessly transmitted to third parties (even miners themselves). <br />
<br />
For example, Alice would tell her wallet that she wanted to pay Bob within the next 10 blocks and also indicate what is the highest fee she’s willing to pay. Alice's wallet would then use its existing fee estimation feature to create an initial version of the transaction to Bob that paid the lowest expected fee for a transaction to confirm within 10 blocks. At the same time, Alice's wallet would also create possibly 9 other versions of the transaction, the first one using nLockTime to ensure it can’t be added until two blocks from now; the second timelocked until three blocks from now; etc…<br />
<br />
Each of these subsequent transactions would pay a slightly higher fee than the original transaction (up to Alice’s indicated max fee) to increase the incentive for miners to mine that transaction.<br />
<br />
Because all versions of the transaction would be signed at the time Alice sent the initial transaction, she would only need to unlock her wallet once. Also, because all subsequent versions of the transaction would use nLockTime, Alice could trustlessly distribute copies of these transactions to other people for later broadcast in case she went offline.<br />
<br />
In short, the software would automatically offer Alice’s maximum fee if it had to, but it’d pay a lower fee if it could get away with it—ensuring Alice got close to the best price possible without any extra effort on her part.<br />
<br />
See also:<br />
<br />
* [https://bitcoincore.org/en/meetings/2017/03/02/#big-features-for-0150 Bitcoin Core IRC meeting summary for 2017-03-02] - See "Precomputed fee bumping" bullet point<br />
<br />
== Offchain payments ==<br />
<br />
Not every Bitcoin payment needs to be added to the Bitcoin block chain. For example, imagine Alice pays 1 BTC to Bob, and then Bob pays 1 BTC to Charlie. Instead of adding both of these payments to the block chain, we could more efficiently just add a 1 BTC payment from Alice to Charlie.<br />
<br />
An early description using this specific optimization called it ''transaction cut-through,''<ref>[https://bitcointalk.org/index.php?topic=281848.0 Transaction cut-through], Gregory Maxwell, 2013-08-23, retrieved 2018-01-25</ref> but the concept of not every payment being recorded on the block chain is more widely known today as ''off-chain payments.''<br />
<br />
Up to 99% of all Bitcoin payments are estimated to be offchain payments<ref>[http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-June/008844.html Pure off-chain is a weak form of layer 2], Adam Back, 19 June 2015</ref>, with most of them likely being buy and sell orders on Bitcoin exchanges. Other third-parties may also help facilitate offchain payments for their users, for example tipping services. These services can be extraordinarily efficient because they don't carry Bitcoin's burden of maintaining consensus among a large set of users—but this efficiency comes at a cost of generally requiring that users trust the service operators not to steal funds. These are ''unenforceable offchain payments.''<br />
<br />
However, there also exist ''enforceable offchain payments'' where no trust in a specific third-party is required—only trust in Bitcoin continuing to operate without transaction censorship.<br />
<br />
This section currently focuses on enforceable offchain payments, but it may later be expanded to cover concepts for unenforcable offchain payments that use cryptography and other security solutions to provide more secure and more private solutions than simple trusted third parties.<br />
<br />
=== Payment channels ===<br />
<br />
''Very useful for small-size and moderate-size payments, but not yet widely deployed as of early 2018''<br />
<br />
[[Payment channels]] are a type of ''enforceable offchain payment'' where bitcoins are deposited into a [[smart contract]] between two or more parties, allowing the involved peers to make trustless payments to each other. Combined with [[hashlock]]s, payments can be securely routed across a network of peers, as in the [[Lightning Network]], allowing Alice to pay Charlie by routing a payment through their mutual peer Bob.<br />
<br />
Opening a payment channel requires a confirmed transaction, incurring the cost of the fees for that transaction, although those fees are identical to sending a regular transaction. Closing a channel also requires a confirmed transaction, adding that transaction's fees to the cost of the payment channel, although those fees too are similar to the costs of the recipient of the funds re-spending them to a new recipient. This means a payment channel's fee cost is very similar to making onchain payments.<br />
<br />
Outside of the channel open and channel close transactions, a payment channel can support an unlimited number of payments without paying any further transaction fees. This can make them extraordinarily efficient—for example, imagine making a million in-channel payments for the cost of just two transaction fees. Note: your channel peers and other channel nodes you route payments through may require their own fee for using their services; these are not related to the transaction fees that are the topic of this article.<br />
<br />
As of early 2018, no payment channel implementation is widely used, but several cooperating implementations of a first version of [[Lightning Network]] are available.<br />
<br />
See also:<br />
<br />
* [[Payment channels]]<br />
* [[Lightning Network]]<br />
<br />
== Potential future improvements ==<br />
<br />
Some of the following improvements and proposed improvements may become available to Bitcoin users. Users who adopt the improvements may be able to further lower their fees.<br />
<br />
* Efficiency improvements<br />
** '''Public key and signature aggregation:''' the ability to combine multiple public keys and signatures into a single public key and signature, allowing multisig transactions to be as efficient to spend as single-signature transactions are today. It may also be possible to combine signatures from multiple inputs in a transaction. It is hopped that this will be possible with variant of [[Schnorr signatures]]. Requires a [[soft fork]].<br />
** '''Merkelized Abstract Syntax Trees (MAST):''' a method for committing to spending scripts that allows the partial omission of unused conditions, allowing complex scripts to be much more efficient,<ref>[https://bitcointechtalk.com/what-is-a-bitcoin-merklized-abstract-syntax-tree-mast-33fdf2da5e2f What is a Bitcoin Merkelized Abstract Syntax Tree?], David A. Harding, BitcoinTechTalk.com, 2017-10-12, retrieved 2018-01-27</ref> even more so if used with [[taproot]]<ref>[https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2018-January/015614.html Taproot: Privacy preserving switchable scripting], Gregory Maxwell, Bitcoin-Dev mailing list, 2018-01-23</ref>. Combines well with signature aggregation (described above) in certain use cases. Requires a [[soft fork]].<br />
** '''CoinJoin with signature aggregation:''' [[CoinJoin]] is a technology for Bitcoin that enhances privacy without reducing security. A group of patient spenders can enter a coinjoin together and obfuscate which of them paid which recipient and which change outputs (if any) they received back. Combined with signature aggregation (described in a previous bullet point), this enhanced privacy mode would be cheaper than each spender making a separate less-private transaction—and it would still be just as secure.<ref>[https://diyhpl.us/wiki/transcripts/scalingbitcoin/milan/schnorr-signatures/ Elliptic curve Schnorr-based signatures in Bitcoin], Pieter Wuille, Scaling Bitcoin 2016 (Milan), 2016-10-09, retrieved 2018-01-27</ref> Requires the signature aggregation soft fork described previously.<br />
<br />
* Intelligent fee selection<br />
** '''Mempool-using fee estimation:''' a potential improvement in fee estimation that considers not just which transactions have been recently confirmed but also the queue of currently unconfirmed transactions.<ref name="mempool-fee-est-slides"/><ref name="mempool-fee-est-video"/> Does not require any protocol changes.<br />
<br />
* Offchain payments<br />
** '''Channel factories:''' (enforceable offchain payments) a potentially more efficient way to open payment channels such as those used by Lightning Network. Combined with signature aggregation (described above) this could reduce the cost of opening a payment channel by up to 96%.<ref>[https://www.tik.ee.ethz.ch/file/a20a865ce40d40c8f942cf206a7cba96/Scalable_Funding_Of_Blockchain_Micropayment_Networks%20(1).pdf Scalable Funding of Bitcoin Micropayment Channel Networks]; Conrad Burchert, Christian Decker, and Roger Wattenhofer; retrieved 2018-01-27</ref> Does not require any [[consensus]] changes.<br />
** '''Chaumian banks:''' (unenforceable offchain payments) a trusted third party who controls bitcoins for a pool of Bitcoin users ([[custodial wallet]], AKA "Bitcoin bank") but who can't know which users own which bitcoins. This is accomplished using [[Chaum blinded signatures]].<ref>[https://medium.com/@nopara73/chaumian-e-cash-for-custodial-bitcoin-wallets-and-services-to-scale-bitcoin-8977d9a03064 Chaumian E-Cash For Custodial Bitcoin Wallets And Services To Scale Bitcoin], nopara73, Medium.com, 2017-12-22, retrieved 2018-01-27</ref> Combined with [[hardware security modules]], it could be made extremely difficult for banks to steal depositor funds.<ref>[https://bitcointalk.org/index.php?topic=146307.0 Fidelity-bonded banks: decentralized, auditable, private, off-chain payments], Peter Todd, 2013-02-23, retrieved 2018-01-27</ref> Does not require any protocol changes.<br />
** '''Strong federations (sidechains)''' (unenforceable offchain payments) a set of trusted third parties controls bitcoins for a pool of Bitcoin users, but uses multisig to prevent an individual or small number of those trusted third parties from stealing depositor funds. Uses a public block chain (but not Bitcoin's block chain) to allow any user to audit all transfers into, out of, or within the system. Hardware security modules (HSMs) are used to further reduce trust in the third parties.<ref>[https://blockstream.com/strong-federations.pdf Strong Federations: An Interoperable Blockchain Solution to Centralized Third Party Risks]; Johnny Dilley, Andrew Poelstra, Jonathan Wilkins, Marta Piekarska, Ben Gorlick, and Mark Friedenbach; retrieved 2018-01-28</ref> Although a block chain is used, this qualifies as an offchain payment solution from the perspective of Bitcoin. As of early 2018, free software federated [[sidechain]] software provides support for [[confidential transactions]]<ref>[https://elementsproject.org/elements/confidential-transactions/ Confidential Transactions], ElementsProject.org, retrieved 2018-01-28</ref> that give them many of the same benefits of the Chaumian banks described in a previous bullet point, but federated sidechain software can (and does) support many other features also.<ref>[https://elementsproject.org/elements/ Elements (features)], ElementsProject.org, retrieved 2018-01-28</ref><br />
<br />
== References ==<br />
<br />
<references /></div>Hardinghttps://en.bitcoin.it/w/index.php?title=Techniques_to_reduce_transaction_fees&diff=64943Techniques to reduce transaction fees2018-01-29T17:29:22Z<p>Harding: Describe some techniques to help people (mainly organizations and wallet devs) reduce transaction fees</p>
<hr />
<div>This page provides a list of currently-available techniques that may allow spenders to reduce the amount of [[transaction fee]] they pay. Not all techniques will apply to all situations, and some techniques require trading off other benefits for lower fees.<br />
<br />
Note, this page only describes techniques that apply to payment-oriented transactions. Data carrier transactions (e.g. [[OP_RETURN]] or [[OpenTimestamps]]), [[colored coin]] protocols, and other proposed uses of Bitcoin transactions may benefit from some of the following techniques, but the recommendations are not aimed at those use cases.<br />
<br />
== Efficiency improvements ==<br />
<br />
Creating transactions that are smaller in size ([[Weight units|weight]]), or which accomplish more for a given size, provide a more efficient way of using scarce block space and so pay less total fee to achieve a [[Transaction fees#feerates|feerate]] that is equivalent to less efficient payments. This section describes several techniques for producing more efficient transactions.<br />
<br />
Technically ''offchain payments'' such as those made in [[payment channels]] are a type of extremely efficient payment and so belong to this category, but they've been given a separate category because of the distinctive way they achieve their high efficiency.<br />
<br />
=== Compressed public keys ===<br />
<br />
''Universally useful but already widely deployed''<br />
<br />
The original Bitcoin software released in 2009 used 65-byte uncompressed public keys to identify the owner of a set of bitcoins. In 2012, Bitcoin protocol developer Pieter Wuille implemented a change to the program now known as Bitcoin Core that allowed it to use 33-byte compressed public keys instead.<ref>[https://bitcoin.org/en/release/v0.6.0#new-features-since-bitcoin-version-05 Bitcoin Core 0.6.0 release notes], Bitcoin.org, 2012-03-20, retrieved 2018-01-27</ref> As Bitcoin Core users adopted this feature and other wallets upgraded to use it as well, this reduced the size of a typical transaction on the network (with one input and two outputs) from about 258 bytes to about 226 bytes, a 14% savings.<br />
<br />
[[File:Uncompressed-pubkey-percentage.png|center|800px|thumb|The percentage of transaction inputs per block using the old uncompressed pubkey format in their scriptSigs. Note: early Bitcoin transactions often placed pubkeys in their scriptPubKeys rather than their scriptSigs.]]<br />
<br />
The change was fully backwards compatible and did not change security in any way, but it did require users wanting to access the space savings to generate new Bitcoin addresses.<br />
<br />
Since 2012, many wallets have adopted compressed public keys—but still some wallets continue to use the less efficient uncompressed public keys. These wallets could achieve a significant savings in transaction fees for the same priority by switching to compressed public keys. If all wallets adopted it, this would effectively lead to a small increase in the available block space:<br />
<br />
[[File:Uncompressed-pubkey-savings.png|center|800px|thumb|The percentage of the maximum available block space consumed by the extra bytes in uncompressed pubkeys]]<br />
<br />
See also:<br />
<br />
* [https://bitcoin.org/en/developer-guide#public-key-formats Compressed public keys] — Bitcoin.org Developer Guide<br />
* [https://bitcoin.org/en/release/v0.6.0#new-features-since-bitcoin-version-05 Bitcoin Core 0.6.0 release notes]<br />
* [https://github.com/bitcoin/bips/blob/master/bip-0143.mediawiki#Restrictions_on_public_key_type BIP143] - Requires all pubkeys in [[segregated witness]] witnesses be compressed pubkeys<br />
<br />
=== Payment batching ===<br />
<br />
''Very useful for high-frequency spenders (e.g. organizations); moderately useful for lower-frequency spenders (e.g. individuals)''<br />
<br />
Every Bitcoin transaction must reference the funds being spent and provide proof that the transaction was authorized by the owner of those funds. To spend a single collection of funds takes a minimum of 79 vbytes under normal circumstances. This same amount of block space is used no matter how many recipients are paid in that transaction. For example, consider the following two scenarios:<br />
<br />
* Alice pays Bob in one transaction and then pays Charlie in a second transaction. Each transaction contains a minimum of 79 vbytes related to the funds being spent—a total of 158 vbytes.<br />
* Alice uses a single transaction to pay both Bob and Charlie. The single transaction only needs one set of 79 vbytes related to the funds being spent—a savings of 50% for this field.<br />
<br />
This type of savings increases as more payments are added to a single transaction until the cost per payment is just barely more than the cost of adding the vbytes directly related to that payment in the transaction. The plot below shows the cost per payment for a native segwit [[P2WPKH]] transaction paying other P2WPKH outputs:<br />
<br />
[[File:Batching.png|center]]<br />
<br />
We see the cost drop by more than 50% after five payments are added, with the savings increasing up to about 70% for segwit transactions. Not shown is that the savings increase up to about 80% for legacy transactions because these transactions start off less efficient than segwit transactions. That's a major benefit and one that's easily obtainable by high-frequency spenders, such as organizations.<br />
<br />
Many wallets support batching payments. In graphical wallets, there's often a button that allows you add additional recipients to a transaction (see image below). In command-line and RPC wallets, there's often a call such as <code>sendmany</code> that lets you pay multiple recipients.<br />
<br />
[[File:Bitcoin-core-add-recipient.png|thumb|200px|right|Add Recipient button in Bitcoin Core 0.15.0]]<br />
<br />
Note that there are other parts of a transaction that stay a constant size (or nearly so) when payments are added, so the benefits stack up faster than a fixed cost of just 79 vbytes might suggest. The section below about ''change avoidance'' addresses how one of these cases can itself be eliminated as a cost.<br />
<br />
See also:<br />
<br />
* [https://bitcointechtalk.com/saving-up-to-80-on-bitcoin-transaction-fees-by-batching-payments-4147ab7009fb Saving up to 80% on Bitcoin transaction fees by batching payments]<br />
* [https://bitcoin.org/en/developer-reference#sendmany SendMany RPC] - Bitcoin.org Developer Reference<br />
<br />
=== P2SH-wrapped segwit ===<br />
<br />
''Universally useful''<br />
<br />
Transactions that spend bitcoins secured by [[segregated witness]] (segwit) use less space in a block than equivalent non-segwit (legacy) transactions, allowing segwit transactions to pay less total fee to achieve the same [[Transaction fees#feerates|feerate]] as legacy transactions. The amount of savings varies depending on the details of your transaction, but here are a few common transaction types an an example:<br />
<br />
{|<br />
! Type<br />
! Legacy vbytes<br />
! P2SH-wrapped<br>segwit vbytes<br />
! Savings<br />
|-<br />
| Single signature<br />
| 226<br />
| 167<br />
| 36%<br />
|-<br />
| 2-of-2 multisig<br />
| 335<br />
| 197<br />
| 70%<br />
|-<br />
| 2-of-3 multisig<br />
| 369<br />
| 206<br />
| 80%<br />
|}<br />
<br />
Note that the multisig examples above use the same security as the equivalent legacy P2SH multisig. Segwit optionally allows access to a multisig form that is more secure on one dimension but it requires an extra 12 vbytes per output, which would reduce efficiency somewhat.<br />
<br />
To access these savings, you must use a wallet that supports generating P2SH-wrapped segwit addresses (addresses that start with a "3", although not all addresses that start with a 3 are segwit-enabled). When you spend bitcoins received to these P2SH-wrapped segwit addresses, your transactions will automatically consume less block space, allowing your wallet to pay proportionally less fee.<br />
<br />
See also:<br />
<br />
* [[Segregated Witness]]<br />
* [https://bitcoincore.org/en/segwit_wallet_dev/ Segregated Witness Wallet Development Guide] - BitcoinCore.org<br />
* [https://bitcoincore.org/en/segwit_adoption/ List of wallets, libraries, and services that support segwit] - BitcoinCore.org<br />
<br />
=== Native segwit ===<br />
<br />
''Universally useful but requires native segwit adoption by the people sending you bitcoins''<br />
<br />
The P2SH-wrapped segwit described above is backwards compatible with the P2SH address format supported by older wallets, but a new and non-backwards compatible format is available that saves additional space. The following examples and savings are compared to the size of the P2SH-wrapped examples above:<br />
<br />
{|<br />
! Type<br />
! P2SH-wrapped<br>segwit vbytes<br />
! Native segwit<br>vbytes<br />
! Additional<br>savings<br />
|-<br />
| Single signature<br />
| 167<br />
| 141<br />
| 19%<br />
|-<br />
| 2-of-2 multisig<br />
| 197<br />
| 169<br />
| 17%<br />
|-<br />
| 2-of-3 multisig<br />
| 206<br />
| 178<br />
| 16%<br />
|}<br />
<br />
To access these savings, you must use a wallet that supports generating native segwit addresses, called [[bech32]] addresses (addresses that start with a "bc1"). When you spend bitcoins received to these native segwit addresses, your transactions will automatically consume less block space than even P2SH-wrapped segwit addresses, allowing your wallet to pay proportionally less fee.<br />
<br />
See also:<br />
<br />
* [[Bech32 adoption]]<br />
* [https://github.com/bitcoin/bips/blob/master/bip-0173.mediawiki BIP173] — Bech32 addresses<br />
<br />
=== Change avoidance ===<br />
<br />
''Useful for high-frequency recipients (e.g. organizations), especially those who already effectively use transaction batching''<br />
<br />
When a Bitcoin transaction references the funds it wants to spend, it's required to spend all of those funds. For example, if you received 5 BTC in a previous transaction and now you want to spend 2 BTC, Bitcoin requires that you spend all 5 BTC. For this reason, almost all Bitcoin transactions currently pay some bitcoins back to the spender. For example, you'd return the remaining 3 BTC from the previous example back to yourself. This return of money to yourself is called ''change'' by analogy to the change a store clerk hands you when you (for example) buy a $2 item with a $5 bill.<br />
<br />
A typical change output adds about 32 vbytes to the size of a transaction. If the spender can pay with exact change—that is, doesn't need to refund any change to them self—they can eliminate the change output and generate transactions that are up to 23% smaller. In addition, a change output will later be spent at a typical cost of 69 vbytes or more, but when paying with exact change, this future cost is also avoided.<br />
<br />
To use change avoidance requires having previously received a payment or set of payments that's close to the size of the amount being spent (including the transaction fee). This can be rare in the case of individual user wallets that don't receive many payments to choose from and can't significantly vary the amount of their spending transactions, but for organization wallets that receive many payments and already use payment batching to combine multiple outgoing payments, change avoidance can be an easily-obtainable efficiency improvement.<br />
<br />
The spender doesn't need to match the inputs and outputs of their transaction exactly to Bitcoin's full 10 nanobitcoin precision, but can instead overpay or underpay fees slightly by including inputs that are (respectively) slightly more or slightly less than the desired amount. Even when paying slightly more fees than desired, this can result in savings if the slight increase in fees is still less than would normally be paid for the extra 32 vbytes (or so) for a change output and the typical mininum of 69 vbytes for later spending that output.<ref>[https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2018-January/015606.html Transaction Merging (bip125 relaxation)], Rhavar, bitcoin-dev mailing list, 2018-01-22</ref> When paying slightly lower fees, confirmation of the transaction may be delayed, but current-generation (2018) fee estimates are still inaccurate enough that small differences in feerates may not strongly correlate to delays.<br />
<br />
See also:<br />
<br />
* [http://murch.one/wp-content/uploads/2016/11/erhardt2016coinselection.pdf An Evaluation of Coin Selection Strategies] - Mark Erhardt<br />
* [https://github.com/bitcoin/bitcoin/pull/10637 Bitcoin Core pull request #10,637] - A proposed implementation of Erhardt's "branch and bound" strategy<br />
* [https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2018-January/015606.html Bitcoin-Dev mailing list post] - With good coin selection, I am able to avoid change about ~75% of the time in my simulations..."<br />
<br />
=== Consolidation ===<br />
<br />
''Useful for all wallets but may require users sacrifice some privacy''<br />
<br />
The amount of fee a transaction pays is proportional to its size in [[vbytes]], and one the main contributors to size is the number of [[inputs]] the transaction spends. Each input is a reference to the funds the transaction wants to spend, and when a wallet contains only low-value inputs, it can't create a comparatively higher output paying a recipient without adding many of those inputs to the transaction. Each input adds a minimum of 41 vbytes to the transaction and almost always 69 or more vbytes, so any strategy that reduces the number of inputs is worth considering.<br />
<br />
Given that [[Transaction_fees#The_market_for_block_space|fees vary over time]], one method that can reduce overall fees is input consolidation—combining a set of smaller inputs into a single larger input by spending them from yourself to yourself during a period of time when fees are lower than normal. For example, if your usual target feerate during normal-priced fee periods is 100 nanobitcoins per vbyte and the current feerate is 10 nanobitcoins per vbyte, you could save up to almost 90% on fees by consolidating now before you next need to spend some of those inputs.<br />
<br />
[[File:Consolidation-savings.png|center]]<br />
<br />
Consolidation does come with the overhead of creating the consolidation transaction, which is equal to the cost of spending one input to one output, which is about 110 vbytes for P2WPKH inputs/outputs. Also, if you combine inputs that were originally sent to addresses unconnected to each other, you may reduce your privacy in some cases by making that connection in your consolidation transaction (although it's believed that few people currently manage to spend their inputs in a manner that preserves this element of privacy).<br />
<br />
See also:<br />
<br />
* [[How to cheaply consolidate coins to reduce miner fees]]<br />
<br />
== Intelligent fee selection ==<br />
<br />
When it comes to fees, sending a Bitcoin transaction is similar to mailing a package: you can pay a high fee for fast high-priority service or a lower fee for slower low-priority service. This section describes several techniques for taking advantage of the more affordable low-priority service.<br />
<br />
=== Dynamic fee estimation ===<br />
<br />
''Universally useful. Already widely deployed but still being improved as research and development continues''<br />
<br />
Early Bitcoin wallets often defaulted to paying a fixed fee on every transaction—enough to incentivize a miner to include it but not enough to compete against other transactions seeking confirmation in a [[fee market]]. As blocks have filled, this has changed, and as of early 2018 all widely-used wallets use dynamic fee estimation to select a fee based on the condition of the current fee market.<br />
<br />
[[File:Bitcoin-core-fee-selector.png|thumb|200px|right|Fee selector in Bitcoin Core 0.15.0]]<br />
<br />
However, some fee estimation tools may be better than others, achieving confirmation by the desired time even when paying lower fees. Although data from multiple wallets and fee estimation services can be compared<ref>[https://www.p2sh.info/dashboard/db/fee-estimation Fee Estimation], P2SH.info, retrieved 2018-01-23</ref> and there have been some attempts to compare fee estimation between different wallets,<ref>[https://blog.bitgo.com/the-challenges-of-bitcoin-transaction-fee-estimation-e47a64a61c72 The Challenges of Bitcoin Transaction Fee Estimation], Jameson Lopp, BitGo block, 2017-05-10, retrieved 2018-01-23</ref> there is no known survey of fee estimation quality across a large number of popular wallets as of early 2018.<br />
<br />
In addition, also as of early 2018, some techniques have recently been described that could significantly improve fee estimation, such as factoring current [[mempool]] data into confirmation-based fee estimates.<ref name="mempool-fee-est-slides">[https://scalingbitcoin.org/stanford2017/Day2/Scaling-2017-Optimizing-fee-estimation-via-the-mempool-state.pdf Optimizing fee estimation via the mempool state (slides, PDF)], Karl-Johan Alm, Scaling Bitcoin 2017 (Stanford), 2017-11-05, retrieved 2018-01-23</ref><ref name="mempool-fee-est-video">[https://www.youtube.com/watch?v=QkYXPJMqBNk&feature=youtu.be&t=2033 Optimizing fee estimation via the mempool state (presentation video)], Karl-Johan Alm, Scaling Bitcoin 2017 (Stanford), 2017-11-05, retrieved 2018-01-23</ref><br />
<br />
See also<br />
<br />
* [[Transaction fees]]<br />
* [https://blog.bitgo.com/the-challenges-of-bitcoin-transaction-fee-estimation-e47a64a61c72 The Challenges of Bitcoin Transaction Fee Estimation] - Jameson Lopp<br />
* [https://gist.github.com/morcos/d3637f015bc4e607e1fd10d8351e9f41 High level description Bitcoin Core's fee estimation algorithm] - Alex Morcos<br />
<br />
=== Patient spending ===<br />
<br />
''Very useful for non-urgent transactions. Not useful for urgent transactions''<br />
<br />
Spenders who can patiently wait for their transactions to confirm can take advantage of variations in the [[Transaction fees#feerates|feerate]] necessary to achive confirmation. For example, sometimes several Bitcoin blocks are produced in quick succession, raising the effective supply of block space by several multiples; other times, demand drops off, such as fees on Sunday being on average 20% lower than fees on Friday in Q4 2017<ref>[[Transaction_fees#The_market_for_block_space]], Bitcoin Wiki, retrieved 2018-01-27</ref>. Looking at data from the widely-used fee estimator included in Bitcoin Core, we can see fee savings of 90% or more possible, with around 50% being easily obtainable by many patient spenders.<br />
<br />
[[File:Feerate-estimates.png|center]]<br />
<br />
In the data plotted above, the Bitcoin Core fee estimator suggests that for this sample period the following savings are available:<br />
<br />
{|<br />
! Wait<br />
! Conservative savings<br />
! Economical savings*<br />
|-<br />
| 2 hours<br />
| 5% <br />
| 5%<br />
|-<br />
| 6 hours<br />
| 18%<br />
| 55%<br />
|-<br />
| 12 hours <br />
| 39%<br />
| 55%<br />
|-<br />
| 24 hours (1 day)<br />
| 39% <br />
| 55%<br />
|-<br />
| 48 hours (2 days) <br />
| 47% <br />
| 55%<br />
|-<br />
| 72 hours (3 days) <br />
| 52% <br />
| 55%<br />
|-<br />
| 96 hours (4 days) <br />
| 92% <br />
| 92%<br />
|}<br />
<br />
''* Economical savings have a lower probability of being achieved and are recommended for use with the transaction replacability described in a later section.''<br />
<br />
Although waiting up to four days is impractical for many use cases, there are also many cases where it can be practical. A few examples: moving funds between one's own wallets, [[#Consolidation|consolidating]] many smaller inputs into one larger input that can be more efficiently spent, or payments or remittances to friends or family who trust the spender and so don't need fast confirmation.<br />
<br />
See also:<br />
<br />
* [https://p2sh.info/dashboard/db/fee-estimation P2SH.info] - Fee estimates from multiple sources<br />
* [[Transaction_fees#Fee_Plotting_Sites|Other fee plotting sites]]<br />
<br />
=== Opt-in transaction replacement ===<br />
<br />
''Universally useful, but may cause UI issues in recipient wallets''<br />
<br />
Although not strictly a method for reducing fees by itself, opt-in transaction replacement allows a wallet to update previously-sent transactions with new versions that pay higher fees and, possibly, make other changes to the transaction. The method is also called opt-in Replace-By-Fee (RBF). This technique allows wallets to initially pay lower fees in case there's a sudden increase in the supply of block space, a sudden decrease in demand for that space, or another situation that increases the chance of low-fee transactions being confirmed. If none of those things happens, the spender can then increase ("bump") the transaction's fee to increase its probability of confirming.<br />
<br />
This often allows wallets that support transaction replacement to pay lower fees than wallets that don't support replacement.<br />
<br />
Transaction replacement can appear odd in some recipient wallets. Wallets such as Bitcoin Core (pictured below) show each replacement as a separate payment in the list of transactions. When one version of the replacements is confirmed, it is shown as a normal transaction; the other versions are then shown with an X icon to indicate that they are [[conflicted]] (cannot occur together in the same valid block chain). This helps communicate the status of all affected payments to the recipient, but it may not be entirely clear what's happening to users who aren't familar with replacements. Other wallets may not show transactions opting in to replacement at all until one version of the transaction has been confirmed. There's no clear community consensus on the correct way to handle this situation using user interfaces, documentation, or both.<br />
<br />
[[File:Fee-bump-ux.png|thumb|right|200px|List of transaction replacements in Bitcoin Core 0.15.0]]<br />
<br />
Transaction replacement can be advantageously combined with ''payment batching'' (described previously). Instead of waiting, for example, 30 minutes to batch all outgoing payments, the spender can batch the first 10 minutes of payments with a low feerate. If that doesn't get confirmed within 10 minutes, the spender can replace that transaction with a slightly higher feerate transaction that also includes then next 10 minutes of payments. If that again doesn't confirm, another update can also include the third 10 minutes of transactions at the original intended feerate. This allows the recipients of the first 10 minutes of payments to receive a notification that the payment has been sent up to 20 minutes earlier than with normal batching, and it also gives those early payments a chance to confirm at a lower-than-expected feerate. Updating a batched transaction with more payments can be done as many times as necessary up to a [[relay limit]] on transaction size of 100 kilobytes.<br />
<br />
Currently, transaction replacement does have one significant downside: it tends to reduce privacy. When the fee on a transaction is increased, either additional inputs must be added or the value of the [[change output]] must be decreased. In either case, this makes the change output easier to identify among the different outputs being paid by a transaction. Value-blinding techniques such as [[confidential transactions]] could improve this situation, but there are no near-term plans to add such a feature to Bitcoin as of early 2018. If transaction replacement is always combined with [[#change_avoidance|change avoidance]], it could avoid this privacy issue.<br />
<br />
See also:<br />
<br />
* [[Transaction replacement]]<br />
* [https://bitcoincore.org/en/faq/optin_rbf/ Opt-in Replace-By-Fee (RBF) FAQ] - BitcoinCore.org<br />
* [https://github.com/bitcoin/bips/blob/master/bip-0125.mediawiki BIP125] - Opt-in Full Replace-by-Fee Signaling<br />
<br />
==== Pre-computed fee bumping ====<br />
<br />
Pre-computed fee bumping is an idea to create and sign multiple replacements for a transaction at the time the initial transaction is created. The initial transaction version could be broadcast immediately, and each of the replacements would pay successively higher fees. This idea could be combined with Bitcoin's existing [[nLockTime]] feature to allow the replacement versions to forbid being included in a block earlier than a specified time or [[block height]], which would allow the replacements to be trustlessly transmitted to third parties (even miners themselves). <br />
<br />
For example, Alice would tell her wallet that she wanted to pay Bob within the next 10 blocks and also indicate what is the highest fee she’s willing to pay. Alice's wallet would then use its existing fee estimation feature to create an initial version of the transaction to Bob that paid the lowest expected fee for a transaction to confirm within 10 blocks. At the same time, Alice's wallet would also create possibly 9 other versions of the transaction, the first one using nLockTime to ensure it can’t be added until two blocks from now; the second timelocked until three blocks from now; etc…<br />
<br />
Each of these subsequent transactions would pay a slightly higher fee than the original transaction (up to Alice’s indicated max fee) to increase the incentive for miners to mine that transaction.<br />
<br />
Because all versions of the transaction would be signed at the time Alice sent the initial transaction, she would only need to unlock her wallet once. Also, because all subsequent versions of the transaction would use nLockTime, Alice could trustlessly distribute copies of these transactions to other people for later broadcast in case she went offline.<br />
<br />
In short, the software would automatically offer Alice’s maximum fee if it had to, but it’d pay a lower fee if it could get away with it—ensuring Alice got close to the best price possible without any extra effort on her part.<br />
<br />
See also:<br />
<br />
* [https://bitcoincore.org/en/meetings/2017/03/02/#big-features-for-0150 Bitcoin Core IRC meeting summary for 2017-03-02] - See "Precomputed fee bumping" bullet point<br />
<br />
== Offchain payments ==<br />
<br />
Not every Bitcoin payment needs to be added to the Bitcoin block chain. For example, imagine Alice pays 1 BTC to Bob, and then Bob pays 1 BTC to Charlie. Instead of adding both of these payments to the block chain, we could more efficiently just add a 1 BTC payment from Alice to Charlie.<br />
<br />
An early description using this specific optimization called it ''transaction cut-through,''<ref>[https://bitcointalk.org/index.php?topic=281848.0 Transaction cut-through], Gregory Maxwell, 2013-08-23, retrieved 2018-01-25</ref> but the concept of not every payment being recorded on the block chain is more widely known today as ''off-chain payments.''<br />
<br />
Up to 99% of all Bitcoin payments are estimated to be offchain payments<ref>[http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-June/008844.html Pure off-chain is a weak form of layer 2], Adam Back, 19 June 2015</ref>, with most of them likely being buy and sell orders on Bitcoin exchanges. Other third-parties may also help facilitate offchain payments for their users, for example tipping services. These services can be extraordinarily efficient because they don't carry Bitcoin's burden of maintaining consensus among a large set of users—but this efficiency comes at a cost of generally requiring that users trust the service operators not to steal funds. These are ''unenforceable offchain payments.''<br />
<br />
However, there also exist ''enforceable offchain payments'' where no trust in a specific third-party is required—only trust in Bitcoin continuing to operate without transaction censorship.<br />
<br />
This section currently focuses on enforceable offchain payments, but it may later be expanded to cover concepts for unenforcable offchain payments that use cryptography and other security solutions to provide more secure and more private solutions than simple trusted third parties.<br />
<br />
=== Payment channels ===<br />
<br />
''Very useful for small-size and moderate-size payments, but not yet widely deployed as of early 2018''<br />
<br />
[[Payment channels]] are a type of ''enforceable offchain payment'' where bitcoins are deposited into a [[smart contract]] between two or more parties, allowing the involved peers to make trustless payments to each other. Combined with [[hashlock]]s, payments can be securely routed across a network of peers, as in the [[Lightning Network]], allowing Alice to pay Charlie by routing a payment through their mutual peer Bob.<br />
<br />
Opening a payment channel requires a confirmed transaction, incurring the cost of the fees for that transaction, although those fees are identical to sending a regular transaction. Closing a channel also requires a confirmed transaction, adding that transaction's fees to the cost of the payment channel, although those fees too are similar to the costs of the recipient of the funds re-spending them to a new recipient. This means a payment channel's fee cost is very similar to making onchain payments.<br />
<br />
Outside of the channel open and channel close transactions, a payment channel can support an unlimited number of payments without paying any further transaction fees. This can make them extraordinarily efficient—for example, imagine making a million in-channel payments for the cost of just two transaction fees. Note: your channel peers and other channel nodes you route payments through may require their own fee for using their services; these are not related to the transaction fees that are the topic of this article.<br />
<br />
As of early 2018, no payment channel implementation is widely used, but several cooperating implementations of a first version of [[Lightning Network]] are available.<br />
<br />
See also:<br />
<br />
* [[Payment channels]]<br />
* [[Lightning Network]]<br />
<br />
== Potential future improvements ==<br />
<br />
Some of the following improvements and proposed improvements may become available to Bitcoin users. Users who adopt the improvements may be able to further lower their fees.<br />
<br />
* Efficiency improvements<br />
** '''Public key and signature aggregation:''' the ability to combine multiple public keys and signatures into a single public key and signature, allowing multisig transactions to be as efficient to spend as single-signature transactions are today. It may also be possible to combine signatures from multiple inputs in a transaction. It is hopped that this will be possible with variant of [[Schnorr signatures]]. Requires a [[soft fork]].<br />
** '''Merkelized Abstract Syntax Trees (MAST):''' a method for committing to spending scripts that allows the partial omission of unused conditions, allowing complex scripts to be much more efficient,<ref>[https://bitcointechtalk.com/what-is-a-bitcoin-merklized-abstract-syntax-tree-mast-33fdf2da5e2f What is a Bitcoin Merkelized Abstract Syntax Tree?], David A. Harding, BitcoinTechTalk.com, 2017-10-12, retrieved 2018-01-27</ref> even more so if used with [[taproot]]<ref>[https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2018-January/015614.html Taproot: Privacy preserving switchable scripting], Gregory Maxwell, Bitcoin-Dev mailing list, 2018-01-23</ref>. Combines well with signature aggregation (described above) in certain use cases. Requires a [[soft fork]].<br />
** '''CoinJoin with signature aggregation:''' [[CoinJoin]] is a technology for Bitcoin that enhances privacy without reducing security. A group of patient spenders can enter a coinjoin together and obfuscate which of them paid which recipient and which change outputs (if any) they received back. Combined with signature aggregation (described in a previous bullet point), this enhanced privacy mode would be cheaper than each spender making a separate less-private transaction—and it would still be just as secure.<ref>[https://diyhpl.us/wiki/transcripts/scalingbitcoin/milan/schnorr-signatures/ Elliptic curve Schnorr-based signatures in Bitcoin], Pieter Wuille, Scaling Bitcoin 2016 (Milan), 2016-10-09, retrieved 2018-01-27</ref> Requires the signature aggregation soft fork described previously.<br />
<br />
* Intelligent fee selection<br />
** '''Mempool-using fee estimation:''' a potential improvement in fee estimation that considers not just which transactions have been recently confirmed but also the queue of currently unconfirmed transactions.<ref name="mempool-fee-est-slides"/><ref name="mempool-fee-est-video"/> Does not require any protocol changes.<br />
<br />
* Offchain payments<br />
** '''Channel factories:''' (enforceable offchain payments) a potentially more efficient way to open payment channels such as those used by Lightning Network. Combined with signature aggregation (described above) this could reduce the cost of opening a payment channel by up to 96%.<ref>[https://www.tik.ee.ethz.ch/file/a20a865ce40d40c8f942cf206a7cba96/Scalable_Funding_Of_Blockchain_Micropayment_Networks%20(1).pdf Scalable Funding of Bitcoin Micropayment Channel Networks]; Conrad Burchert, Christian Decker, and Roger Wattenhofer; retrieved 2018-01-27</ref> Does not require any [[consensus]] changes.<br />
** '''Chaumian banks:''' (unenforceable offchain payments) a trusted third party who controls bitcoins for a pool of Bitcoin users ([[custodial wallet]], AKA "Bitcoin bank") but who can't know which users own which bitcoins. This is accomplished using [[Chaum blinded signatures]].<ref>[https://medium.com/@nopara73/chaumian-e-cash-for-custodial-bitcoin-wallets-and-services-to-scale-bitcoin-8977d9a03064 Chaumian E-Cash For Custodial Bitcoin Wallets And Services To Scale Bitcoin], nopara73, Medium.com, 2017-12-22, retrieved 2018-01-27</ref> Combined with [[hardware security modules]], it could be made extremely difficult for banks to steal depositor funds.<ref>[https://bitcointalk.org/index.php?topic=146307.0 Fidelity-bonded banks: decentralized, auditable, private, off-chain payments], Peter Todd, 2013-02-23, retrieved 2018-01-27</ref> Does not require any protocol changes.<br />
** '''Strong federations (sidechains)''' (unenforceable offchain payments) a set of trusted third parties controls bitcoins for a pool of Bitcoin users, but uses multisig to prevent an individual or small number of those trusted third parties from stealing depositor funds. Uses a public block chain (but not Bitcoin's block chain) to allow any user to audit all transfers into, out of, or within the system. Hardware security modules (HSMs) are used to further reduce trust in the third parties.<ref>[https://blockstream.com/strong-federations.pdf Strong Federations: An Interoperable Blockchain Solution to Centralized Third Party Risks]; Johnny Dilley, Andrew Poelstra, Jonathan Wilkins, Marta Piekarska, Ben Gorlick, and Mark Friedenbach; retrieved 2018-01-28</ref> Although a block chain is used, this qualifies as an offchain payment solution from the perspective of Bitcoin. As of early 2018, free software federated [[sidechain]] software provides support for [[confidential transactions]]<ref>[https://elementsproject.org/elements/confidential-transactions/ Confidential Transactions], ElementsProject.org, retrieved 2018-01-28</ref> that give them many of the same benefits of the Chaumian banks described in a previous bullet point, but federated sidechain software can (and does) support many other features also.<ref>[https://elementsproject.org/elements/ Elements (features)], ElementsProject.org, retrieved 2018-01-28</ref><br />
<br />
== References ==<br />
<br />
<references /></div>Hardinghttps://en.bitcoin.it/w/index.php?title=Segregated_witness&diff=64941Segregated witness2018-01-29T16:48:17Z<p>Harding: Redirected page to Segregated Witness</p>
<hr />
<div>#REDIRECT [[Segregated Witness]]</div>Hardinghttps://en.bitcoin.it/w/index.php?title=File:Fee-bump-ux.png&diff=64940File:Fee-bump-ux.png2018-01-29T16:34:36Z<p>Harding: </p>
<hr />
<div>== Licensing ==<br />
{{self|Cc-zero}}</div>Hardinghttps://en.bitcoin.it/w/index.php?title=File:Feerate-estimates.png&diff=64939File:Feerate-estimates.png2018-01-29T16:33:56Z<p>Harding: </p>
<hr />
<div>== Licensing ==<br />
{{self|Cc-zero}}</div>Hardinghttps://en.bitcoin.it/w/index.php?title=File:Bitcoin-core-fee-selector.png&diff=64938File:Bitcoin-core-fee-selector.png2018-01-29T16:32:25Z<p>Harding: </p>
<hr />
<div>== Licensing ==<br />
{{self|Cc-zero}}</div>Hardinghttps://en.bitcoin.it/w/index.php?title=File:Consolidation-savings.png&diff=64937File:Consolidation-savings.png2018-01-29T16:31:43Z<p>Harding: </p>
<hr />
<div>== Licensing ==<br />
{{self|Cc-zero}}</div>Hardinghttps://en.bitcoin.it/w/index.php?title=File:Bitcoin-core-add-recipient.png&diff=64936File:Bitcoin-core-add-recipient.png2018-01-29T16:31:00Z<p>Harding: </p>
<hr />
<div>== Licensing ==<br />
{{self|Cc-zero}}</div>Hardinghttps://en.bitcoin.it/w/index.php?title=File:Batching.png&diff=64935File:Batching.png2018-01-29T16:30:09Z<p>Harding: </p>
<hr />
<div>== Licensing ==<br />
{{self|Cc-zero}}</div>Hardinghttps://en.bitcoin.it/w/index.php?title=File:Uncompressed-pubkey-savings.png&diff=64934File:Uncompressed-pubkey-savings.png2018-01-29T16:29:37Z<p>Harding: </p>
<hr />
<div>== Licensing ==<br />
{{self|Cc-zero}}</div>Hardinghttps://en.bitcoin.it/w/index.php?title=File:Uncompressed-pubkey-percentage.png&diff=64933File:Uncompressed-pubkey-percentage.png2018-01-29T16:28:44Z<p>Harding: </p>
<hr />
<div>== Licensing ==<br />
{{self|Cc-zero}}</div>Hardinghttps://en.bitcoin.it/w/index.php?title=Miner_fees&diff=64860Miner fees2018-01-22T11:41:18Z<p>Harding: /* The market for block space */ Rewrite beginning of section and provide illustrated examples of variable supply and demand.</p>
<hr />
<div>'''Transaction fees''' are a fee that spenders may include in any Bitcoin transaction. The fee may be collected by the miner who includes the transaction in a block.<br />
<br />
== Overview ==<br />
<br />
Every Bitcoin transaction spends zero or more bitcoins to zero or more recipients. The difference between the amount being spent and the amount being received is the transaction fee (which must be zero or more).<br />
<br />
Bitcoin's design makes it easy and efficient for the spender to specify how much fee to pay, whereas it would be harder and less efficient for the recipient to specify the fee, so by custom the spender is almost always solely responsible for paying all necessary Bitcoin transaction fees.<br />
<br />
When a miner creates a [[block proposal]], the miner is entitled to specify where all the fees paid by the transactions in that block proposal should be sent. If the proposal results in a valid block that becomes a part of the [[best block chain]], the fee income will be sent to the specified recipient. If a valid block does not collect all available fees, the amount not collected are permanently destroyed; this has happened on more than 1,000 occasions from 2011 to 2017,<ref>[https://medium.com/@alcio/how-to-destroy-bitcoins-255bb6f2142e How to Destroy Bitcoins] by Antoine Le Calvez, Medium.com, retrieved 2018-01-03</ref><ref>[https://twitter.com/random_walker/status/948590112576868354 "Looks like back in 2012, when tx fees started becoming common, some miners were claiming the standard 50 BTC and leaving all tx fees unclaimed."], Arvind Narayanan, Twitter.com, posted 2018-01-03, retrieved 2018-01-03</ref> with decreasing frequency over time. <br />
<br />
<br />
==The market for block space==<br />
<br />
[[File:fee.png|thumb|Receiving the fees from hundreds of transactions (0.44 BTC)]]<br />
<br />
The minimum fee necessary for a transaction to confirm varies over time and arises from the intersection of supply and demand in Bitcoin's free market for block space.<ref>[https://medium.com/@bramcohen/how-wallets-can-handle-transaction-fees-ff5d020d14fb Bram Cohen blog post with helpful background to the market for block space]</ref> On the supply size, Bitcoin has a [[maximum block size]] (currently one million vbytes) that limits the maximum amount of transaction data that can be added to a block.<br />
<br />
However, Bitcoin blocks are not produced on a fixed schedule—the system targets an average of one block every 10 minutes over long periods of time but, over short periods of time, a new block can arrive in less than a second or more than an hour after the previous block. As the number of blocks received in a period of time varies, so does the effective maximum block size. For example, in the illustration below we see the average time between blocks based on the time they were received by a node during a one day period (left axis) and the corresponding effective maximum block size implied by that block production rate (right axis, in million [[vbytes]]):<br />
<br />
[[File:Time-between-blocks.png|center]]<br />
<br />
During periods of higher effective maximum block sizes, this natural and unpredictable variability means that transactions with lower fees have a higher than normal chance of getting confirmed—and during periods of lower effective maximum block sizes, low-fee transactions have a lower than normal chance of getting confirmed.<br />
<br />
On the demand side of Bitcoin's free market for block space, each spender is under unique constraints when it comes to spending their bitcoins. Some are willing to pay high fees; some are not. Some desire fast confirmation; some are content with waiting a while. Some use wallets with excellent dynamic fee estimation; some do not. In addition, demand varies according to certain patterns, with perhaps the most recognizable being the weekly cycle where fees increase during weekdays and decrease on the weekend:<br />
<br />
[[File:Block-fees-dow.png|center]]<br />
<br />
Another less recognizable cycle is the intra-day cycle where fees wax and wane during the day:<br />
<br />
[[File:Block-fees-hod.png|center]]<br />
<br />
These variations in supply and demand create a market for block space that allows users to make a trade-off between confirmation time and cost. Users with high time requirements may pay a higher than average transaction fee to be confirmed quickly, while users under less time pressure can save money by being prepared to wait longer for either a natural (but unpredictable) increase in supply or a (somewhat predictable) decrease in demand.<br />
<br />
It is envisioned that over time the cumulative effect of collecting transaction fees will allow those creating new blocks to "earn" more bitcoins than will be mined from new bitcoins created by the new block itself. This is also an incentive to keep trying to create new blocks as the creation of new bitcoins from the mining activity goes towards [[Controlled supply|zero in the future]].<ref>[https://bitcoincore.org/bitcoin.pdf Bitcoin: A Peer-to-Peer Electronic Cash], section 6: Incentive, Satoshi Nakamoto, 2008-11-01, retrieved 2018-01-22</ref><br />
<br />
== Feerates ==<br />
<br />
Perhaps the most important factor affecting how fast a transaction gets confirmed is its fee rate (often spelled feerate). This section describes why feerates are important and how to calculate a transaction's feerate.<br />
<br />
Bitcoin transaction vary in size for a variety of reasons. We can easily visualize that by drawing four transactions side-by-side based on their size (length) with each of<br />
our examples larger than the previous one:<br />
<br />
[[File:Feerate1.png|400px|center]]<br />
<br />
This method of illustrating length maxes it easy to also visualize an example maximum block size limit that constrains how much transaction data a miner can add to an individual block:<br />
<br />
[[File:Feerate2.png|400px|center]]<br />
<br />
Since Bitcoin only allows whole transactions to be added to a particular block, at least one of the transactions in the example above can't be added to the next block. So how does a miner select which transactions to include? There's no required selection method (called ''policy'') and no known way to make any particular policy required, but one strategy popular among miners is for each individual miner to attempt to maximize the amount of fee income they can collect from the transactions they include in their blocks.<br />
<br />
We can add a visualization of available fees to our previous illustration by keeping the length of each transaction the same but making the area of the transaction equal to its fee. This makes the height of each transaction equal to the fee divided by the size, which is called the ''feerate:''<br />
<br />
[[File:Feerate3.png|400px|center]]<br />
<br />
Although long (wide) transactions may contain more total fee, the high-feerate (tall) transactions are the most profitable to mine because their area is greatest compared to the amount of space (length) they take up in a block. For example, compare transaction B to transaction D in the illustration above. This means that miners attempting to maximize fee income can get good results by simply sorting by feerate and including as many transactions as possible in a block:<br />
<br />
[[File:Feerate4.png|400px|center]]<br />
<br />
Because only complete transactions can be added to a block, sometimes (as in the example above) the inability to include the incomplete transaction near the end of the block frees up space for one or more smaller and lower-feerate transactions, so when a block gets near full, a profit-maximizing miner will often ignore all remaining transactions that are too large to fit and include the smaller transactions that do fit (still in highest-feerate order):<br />
<br />
[[File:Feerate5.png|400px|center]]<br />
<br />
Excluding some rare and rarely-significant edge cases, the feerate sorting described above maximizes miner revenue for any given block size as long as none of the transactions depend on any of the other transactions being included in the same block (see the next section, ''feerates for dependent transactions,'' for more information about that).<br />
<br />
To calculate the feerate for your transaction, take the fee the transaction pays and divide that by the size of the transaction (currently based on [[weight units]] or [[vbytes]] but no longer based on [[bytes]]). For example, if a transaction pays a fee of 2,250 nanobitcoins and is 225 vbytes in size, its feerate is 2,250 divided by 225, which is 10 nanobitcoins per vbyte (this happens to be the minimum fee [[Bitcoin Core]] Wallet will pay by default).<br />
<br />
When comparing to the feerate between several transactions, ensure that the units used for all of the measurements are the same. For example, some tools calculate size in weight units and others use vbytes; some tools also display fees in a variety of [[Units|denominations]].<br />
<br />
== Feerates for dependent transactions (child-pays-for-parent) ==<br />
<br />
Bitcoin transactions can depend on the inclusion of other transactions in the same block, which complicates the feerate-based transaction selection described above. This section describes the rules of that dependency system, how miners can maximize revenue while managing those dependencies, and how bitcoin spenders can use the dependency system to effectively increase the feerate of unconfirmed transactions.<br />
<br />
Each transaction in a block has a sequential order, one transaction after another. Each block in the block chain also has a sequential order, one block after another. This means that there's a single sequential order to every transaction in the [[best block chain]].<br />
<br />
[[File:Ancestor-feerate1.png|center]]<br />
<br />
One of Bitcoin's [[consensus rules]] is that the transaction where you receive bitcoins must appear earlier in this sequence than the transaction where you spend those bitcoins. For example, if Alice pays Bob in transaction A and Bob uses those same bitcoins to pay Charlie in transaction B, transaction A must appear earlier in the sequence of transactions than transaction B. Often this is easy to accomplish because transaction A appears in an earlier block than transaction B:<br />
<br />
[[File:Ancestor-feerate2.png|center]]<br />
<br />
But if transaction A and B both appear in the same block, the rule still applies: transaction A must appear earlier in the block than transaction B.<br />
<br />
This complicates the task of maximizing fee revenue for miners. Normally, miners would prefer to simply sort transactions by feerate as described in the ''feerate'' section above. But if both transaction A and B are unconfirmed, the miner cannot include B earlier in the block than A even if B pays a higher feerate. This can make sorting by feerate alone less profitable than expected, so a more complex algorithm is needed. Happily, it's only slightly more complex.<br />
<br />
For example, consider the following four transactions that are similar to those analyzed in the preceding ''feerate'' section:<br />
<br />
[[File:Ancestor-feerate3.png|center]]<br />
<br />
To maximize revenue, miners need a way to compare groups of related transactions to each other as well as to individual transactions that have no unconfirmed dependencies. To do that, every transaction available for inclusion in the next block has its feerate calculated for it and all of its unconfirmed ancestors. In the example, this means that transaction B is now considered as a combination of transaction B plus transaction A:<br />
<br />
[[File:Ancestor-feerate4.png|center]]<br />
<br />
Note that this means that unconfirmed ancestor transactions will be considered twice or more, as in the case of transaction A in our example which is considered once as part of the transaction B+A group and once on its own. We'll deal with this complication in a moment.<br />
<br />
These transaction groups are then sorted in feerate order as described in the previous ''feerate'' section:<br />
<br />
[[File:Ancestor-feerate5.png|center]]<br />
<br />
Any individual transaction that appears twice or more in the sorted list has its redundant copies removed. In the example case, we remove the standalone version of transaction A since it's already part of the<br />
transaction B+A group:<br />
<br />
[[File:Ancestor-feerate6.png|center]]<br />
<br />
Finally, we see if we can squeeze in some smaller transactions into the end of the block to avoid wasting space as described in the previous ''feerate'' section. In this case, we can't, so no changes are made.<br />
<br />
Except for some edge cases that are rare and rarely have a significant impact on revenue, this simple and efficient transaction sorting algorithm maximizes miner feerate revenue after factoring in transaction dependencies.<br />
<br />
Note: to ensure the algorithm runs quickly, implementations such as Bitcoin Core limit the maximum number of related transactions that will be collected together for consideration as one group. As of Bitcoin Core 0.15.0 (released late 2017), this is a maximum of 25 transactions, although there have been proposals to increase this amount somewhat.<br />
<br />
For spenders, miner use of transaction grouping means that if you're waiting for an unconfirmed transaction that pays too low a feerate (e.g. transaction A), you can create a child transaction spending an output of that transaction and which pays a much higher feerate (e.g. transaction B) to encourage miners to confirm both transactions in the same block. Wallets that explicitly support this feature often call it ''child pays for parent (CPFP)'' because the child transaction B helps pay for the parent transaction A.<br />
<br />
To calculate the feerate for a transaction group, sum the fees paid by all the the group's unconfirmed transactions and divide that by the sum of the sizes for all those same transactions (in [[weight units]] or [[vbytes]]). For example, if transaction A has a fee of 1,000 nanobitcoins and a size of 250 vbytes and transaction B has a fee of 3,000 nanobitcoins and a size of 150 vbytes, the combined feerate is (1,000 + 3,000)/(250 + 150), which is 10 nanobitcoins per vbyte.<br />
<br />
The idea behind ancestor feerate grouping goes back to at least 2013 and saw several different proposals to add it to Bitcoin Core, with it finally becoming available for production with the August 2016 release of Bitcoin Core 0.13.0.<ref>[https://bitcoincore.org/en/2016/08/23/release-0.13.0/#more-intelligent-transaction-selection-for-mining More intelligent transaction selection for mining], Bitcoin Core 0.13.0 release notes, BitcoinCore.org, 2016-08-23, retrieved 2017-01-14</ref><br />
<br />
==Reference Implementation==<br />
<br />
The following sections describe the behavior of the [[Original Bitcoin client|reference implementation]] as of version 0.12.0. Earlier versions treated fees differently, as do other popular implementations (including possible later versions).<br />
<br />
===Sending===<br />
<br />
Users can decide to pay a predefined fee rate by setting `-paytxfee=<n>`<br />
(or `settxfee <n>` rpc during runtime). A value of `n=0` signals Bitcoin<br />
Core to use floating fees. By default, Bitcoin Core will use floating<br />
fees.<br />
<br />
Based on past transaction data, floating fees approximate the fees<br />
required to get into the `m`th block from now. This is configurable<br />
with `-txconfirmtarget=<m>` (default: `2`).<br />
<br />
Sometimes, it is not possible to give good estimates, or an estimate<br />
at all. Therefore, a fallback value can be set with `-fallbackfee=<f>`<br />
(default: `0.0002` BTC/kB).<br />
<br />
At all times, Bitcoin Core will cap fees at `-maxtxfee=<x>` (default:<br />
0.10) BTC.<br />
Furthermore, Bitcoin Core will never create transactions smaller than<br />
the current minimum relay fee.<br />
Finally, a user can set the minimum fee rate for all transactions with<br />
`-mintxfee=<<nowiki>i</nowiki>>`, which defaults to 1000 satoshis per kB.<br />
<br />
<br />
Note that a typical transaction is 500 bytes.<br />
<br />
===Including in Blocks===<br />
<br />
This section describes how the reference implementation selects which transactions to put into new blocks, with default settings. All of the settings may be changed if a miner wants to create larger or smaller blocks containing more or fewer free transactions.<br />
<br />
Then transactions that pay a fee of at least 0.00001 BTC/kb are added to the block, highest-fee-per-kilobyte transactions first, until the block is not more than 750,000 bytes big.<br />
<br />
The remaining transactions remain in the miner's "memory pool", and may be included in later blocks if their priority or fee is large enough.<br />
<br />
For Bitcoin Core 0.12.0 zero bytes<ref>https://github.com/bitcoin/bitcoin/blob/v0.12.0/doc/release-notes.md#relay-and-mining-priority-transactions</ref> in the block are set aside for the highest-[[Transaction_fees#Priority_transactions|priority transactions]]. Transactions are added highest-priority-first to this section of the block.<br />
<br />
===Relaying===<br />
<br />
The reference implementation's rules for relaying transactions across the peer-to-peer network are very similar to the rules for sending transactions, as a value of 0.00001 BTC is used to determine whether or not a transaction is considered "Free". However, the rule that all outputs must be 0.01 BTC or larger does not apply. To prevent "penny-flooding" denial-of-service attacks on the network, the reference implementation caps the number of free transactions it will relay to other nodes to (by default) 15 thousand bytes per minute.<br />
<br />
===Settings===<br />
<br />
{| class="wikitable"<br />
|-<br />
! Setting !! Default Value (units)<br />
|-<br />
| txconfirmtarget || 2 (blocks)<br />
|-<br />
| paytxfee || 0 (BTC/kB)<br />
|-<br />
| mintxfee || 0.00001 (BTC/kB)<br />
|-<br />
| limitfreerelay || 15 (thousand bytes per minute)<br />
|-<br />
| minrelaytxfee || 0.00001 (BTC/kB)<br />
|-<br />
| blockmaxsize || 750000 (bytes)<br />
|-<br />
| blockminsize || 0 (bytes)<br />
|-<br />
| blockprioritysize || 0 (bytes)<br />
|}<br />
<br />
==Fee Plotting Sites==<br />
<br />
As of May 2016, the following sites seem to plot the required fee, in satoshi per (kilo)byte, required to get a transaction mined in a certain number of blocks. Note that all these algorithms work in terms of probabilities.<br />
<br />
* https://bitcoinfees.21.co/<br />
* https://bitcoinfees.github.io/<br />
* https://statoshi.info/dashboard/db/fee-estimates<br />
* http://p2sh.info/dashboard/db/fee-estimation<br />
* https://www.bitcoinqueue.com/2d.html<br />
<br />
=== Other Useful Sites ===<br />
<br />
* https://anduck.net/bitcoin/fees/ - Shows what kind of fees filled up recent blocks<br />
* https://btc.com/stats/unconfirmed-tx - the state of the website's mempool broken down by fee rate<br />
* https://jochen-hoenicke.de/queue/#1w - another mempool broken down by fee rate site<br />
* https://esotericnonsense.com/ - yet another mempool site, also very good<br />
* http://mempool.us.to/tx.html - Tells you where a unconfirmed txid is in the queue based on its fee rate (Note that not all miners use the same algorithm)<br />
* https://estimatefee.com/ - You can click any of the transactions in that graph to get more info (like its "effective fee rate" which uses recursive ancestors/descendants for CPFP) and an estimated amount of blocks it'll take to confirm. It works with any transaction in the top 100MB of the bitcoin mempool. And you can enter in any transaction txid for info when you'er wondering why it doesn't confirm.<br />
<br />
==Priority transactions==<br />
<br />
Historically it was not required to include a fee for every transaction. A large portion of miners would mine transactions with no fee given that they had enough "priority". Today, low priority is mostly used as an indicator for spam transactions and almost all miners expect every transaction to include a fee. Today miners choose which transactions to mine only based on fee-rate.<br />
<br />
Transaction priority was calculated as a value-weighted sum of input age, divided by transaction size in bytes:<br />
priority = sum(input_value_in_base_units * input_age)/size_in_bytes<br />
Transactions needed to have a priority above 57,600,000 to avoid the enforced limit (as of client version 0.3.21). This threshold was written in the code as COIN * 144 / 250, suggesting that the threshold represents a one day old, 1 btc coin (144 is the expected number of blocks per day) and a transaction size of 250 bytes.<br />
<br />
So, for example, a transaction that has 2 inputs, one of 5 btc with 10 confirmations, and one of 2 btc with 3 confirmations, and has a size of 500bytes, will have a priority of<br />
(500000000 * 10 + 200000000 * 3) / 500 = 11,200,000<br />
<br />
===Historic rules for free transactions===<br />
A transaction was safe to send without fees if these conditions were met:<br />
<br />
* It is smaller than 1,000 bytes.<br />
* All outputs are 0.01 BTC or larger.<br />
* Its priority is large enough (see above)<br />
<br />
==See Also==<br />
<br />
* [[Free transaction relay policy]]<br />
* [[Fee bumping]]<br />
* [http://bitcoinexchangerate.org/fees Unconfirmed transactions fee chart]<br />
* [https://jochen-hoenicke.de/queue/ historic fees and mempools]<br />
<br />
==References==<br />
<references /><br />
<br />
[[Category:Technical]]<br />
[[Category:Vocabulary]]<br />
[[Category:Mining]]<br />
[[de:Transaktionsgebühren]]<br />
<br />
{{Bitcoin Core documentation}}</div>Hardinghttps://en.bitcoin.it/w/index.php?title=File:Block-fees-hod.png&diff=64856File:Block-fees-hod.png2018-01-22T11:34:24Z<p>Harding: </p>
<hr />
<div>== Licensing ==<br />
{{self|Cc-zero}}</div>Hardinghttps://en.bitcoin.it/w/index.php?title=File:Block-fees-dow.png&diff=64855File:Block-fees-dow.png2018-01-22T11:33:34Z<p>Harding: </p>
<hr />
<div>== Licensing ==<br />
{{self|Cc-zero}}</div>Hardinghttps://en.bitcoin.it/w/index.php?title=File:Time-between-blocks.png&diff=64854File:Time-between-blocks.png2018-01-22T11:32:45Z<p>Harding: </p>
<hr />
<div>== Licensing ==<br />
{{self|Cc-zero}}</div>Hardinghttps://en.bitcoin.it/w/index.php?title=Vbytes&diff=64835Vbytes2018-01-17T19:29:51Z<p>Harding: Create page with redirect to Weight units</p>
<hr />
<div>#REDIRECT [[Weight units]]</div>Hardinghttps://en.bitcoin.it/w/index.php?title=Vsize&diff=64834Vsize2018-01-17T19:28:07Z<p>Harding: Create redirect to Weight units</p>
<hr />
<div>#REDIRECT [[Weight units]]</div>Hardinghttps://en.bitcoin.it/w/index.php?title=Block_weight&diff=64833Block weight2018-01-17T19:25:58Z<p>Harding: Redirect to Weight units, to which most of the content has been moved with a more detailed introduction. Some content moved to Segregated Witness instead. Only intro sentence was not moved somewhere.</p>
<hr />
<div>#REDIRECT [[Weight units]]</div>Harding