Bitcoin Wiki - User contributions [en]

Vault of Satoshi

2025-05-17T16:52:07Z

Theymos: In context, this is not the same thing as the linked article

Vault of Satoshi is a [[currency exchange|exchange]] that allows you to trade fiat currency to bitcoins with other members of the Exchange.

==Deposits==

* Interac Online Deposits
* On-site Interac debit
* Vault of Satoshi codes (created and redeemed from Vault of Satoshi)
* Bank Wire
* PAD (Pre-Authorized Debit)
* Online Bill Payment
* InstaBT

==Withdrawals==

* Vault of Satoshi MasterCards
* Vault of Satoshi Interac Debit Cards
* Paypal
* EFT Bank Transfers

==History==
The exchange was opened for public penetration testing in April 2013, and after extensive testing publicly on October 7th, 2013.

* Vault of Satoshi is the [http://www.coindesk.com/vault-satoshi-announces-proof-solvency-service/ first exchange] in the world to use a 100% transparent audit using the open source software found [https://github.com/olalonde/proof-of-solvency here].

==See Also==

* [[Buying bitcoins]]
* [[Selling bitcoins]]

==External Links==

* [https://vaultofsatoshi.com Vault of Satoshi] exchange website

==References==
<references/>

[[Category:Defunct exchanges]]
[[Category:EWallets]]

Miner fees

2025-02-22T18:37:28Z

Theymos: remove fujn spam

'''Miner fees''' are a fee that spenders may include in any Bitcoin on-chain [[transaction]]. The fee may be collected by the miner who includes the [[transaction]] in a [[block]].

== Overview ==

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

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.

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

==The market for block space==

[[File:fee.png|thumb|Receiving the fees from hundreds of transactions (0.44 BTC)]]

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.

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]]):

[[File:Time-between-blocks.png|center]]

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.

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:

[[File:Block-fees-dow.png|center]]

Another less recognizable cycle is the intra-day cycle where fees wax and wane during the day:

[[File:Block-fees-hod.png|center]]

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.

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>

== Feerates ==

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.

Bitcoin transactions 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
our examples larger than the previous one:

[[File:Feerate1.png|400px|center]]

This method of illustrating length makes 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:

[[File:Feerate2.png|400px|center]]

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.

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

[[File:Feerate3.png|400px|center]]

Although long (wide) transactions may contain more total fees, 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 fee rate and including as many transactions as possible in a block:

[[File:Feerate4.png|400px|center]]

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

[[File:Feerate5.png|400px|center]]

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

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

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

== Feerates for dependent transactions (child-pays-for-parent) ==

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.

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

[[File:Ancestor-feerate1.png|center]]

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:

[[File:Ancestor-feerate2.png|center]]

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.

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.

For example, consider the following four transactions that are similar to those analyzed in the preceding ''feerate'' section:

[[File:Ancestor-feerate3.png|center]]

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:

[[File:Ancestor-feerate4.png|center]]

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.

These transaction groups are then sorted in feerate order as described in the previous ''feerate'' section:

[[File:Ancestor-feerate5.png|center]]

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
transaction B+A group:

[[File:Ancestor-feerate6.png|center]]

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.

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.

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.

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 child transaction B helps pay for parent transaction A.

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.

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>

==Reference Implementation==

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

===Sending===

Users can decide to pay a predefined fee rate by setting `-paytxfee=<n>`
(or `settxfee <n>` rpc during runtime). A value of `n=0` signals Bitcoin
Core to use floating fees. By default, Bitcoin Core will use floating
fees.

Based on past transaction data, floating fees approximate the fees
required to get into the `m`th block from now. This is configurable
with `-txconfirmtarget=<m>` (default: `2`).

Sometimes, it is not possible to give good estimates, or an estimate
at all. Therefore, a fallback value can be set with `-fallbackfee=<f>`
(default: `0.0002` BTC/kB).

At all times, Bitcoin Core will cap fees at `-maxtxfee=<x>` (default:
0.10) BTC.
Furthermore, Bitcoin Core will never create transactions smaller than
the current minimum relay fee.
Finally, a user can set the minimum fee rate for all transactions with
`-mintxfee=<<nowiki>i</nowiki>>`, which defaults to 1000 satoshis per kB.

Note that a typical transaction is 500 bytes.

===Including in Blocks===

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.

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.

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.

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.

===Relaying===

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.

===Settings===

{| class="wikitable"
|-
! Setting !! Default Value (units)
|-
| txconfirmtarget || 2 (blocks)
|-
| paytxfee || 0 (BTC/kB)
|-
| mintxfee || 0.00001 (BTC/kB)
|-
| limitfreerelay || 15 (thousand bytes per minute)
|-
| minrelaytxfee || 0.00001 (BTC/kB)
|-
| blockmaxsize || 750000 (bytes)
|-
| blockminsize || 0 (bytes)
|-
| blockprioritysize || 0 (bytes)
|}

==Fee Plotting Sites==

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.

* https://bitcoinfees.net/

=== Other Useful Sites ===

* https://anduck.net/bitcoin/fees/ - Shows what kind of fees filled up recent blocks
* https://jochen-hoenicke.de/queue/#1w - another mempool broken down by fee rate site
* https://esotericnonsense.com/ - yet another mempool site, also very good
* 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're wondering why it doesn't confirm.
* https://mempool.space/ - Shows how the next few blocks are shaping up and the range of fees per block. Helps estimate the low-end fee to use to get into the next block.
* https://whatthefee.io/ - Shows the probability of a particular fee rate being confirmed within a particular timeframe.

==Priority transactions==

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.

Transaction priority was calculated as a value-weighted sum of input age, divided by transaction size in bytes:
priority = sum(input_value_in_base_units * input_age)/size_in_bytes
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.

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
(500000000 * 10 + 200000000 * 3) / 500 = 11,200,000

===Historic rules for free transactions===
A transaction was safe to send without fees if these conditions were met:

* It is smaller than 1,000 bytes.
* All outputs are 0.01 BTC or larger.
* Its priority is large enough (see above)

==See Also==

* [[Techniques to reduce transaction fees]]
* [[Free transaction relay policy]]
* [[Fee bumping]]
* [[Replace by fee]]
* [https://bitcoinexchangerate.org/fees Unconfirmed transactions fee chart]
* [https://jochen-hoenicke.de/queue/ historic fees and mempools]

==References==
<references />

[[Category:Technical]]
[[Category:Vocabulary]]
[[Category:Mining]]
[[de:Transaktionsgebühren]]

{{Bitcoin Core documentation}}

Alpaca

2025-02-22T18:36:01Z

Theymos: fix typo

One of the unofficial mascots for Bitcoin<ref>The others might include the Honey Badger.</ref>.

The connection between Bitcoin and the Alpaca likely originated from the February 10, 2011 post on Slashdot which described various goods and services could be purchased with bitcoins<ref>[https://slashdot.org/story/11/02/10/189246/Online-Only-Currency-BitCoin-Reaches-Dollar-Parity Online-Only Currency BitCoin Reaches Dollar Parity]</ref>. Because the slashdot crowd has a tendency to be critical (they summarized Apple's 2001 iPod announcement as "lame", for instance<ref>[https://slashdot.org/story/01/10/23/1816257/Apple-releases-iPod Apple releases iPod]</ref>) or humorous ("Do alpacas really wear socks?"<ref>[https://slashdot.org/comments.pl?sid=1989992&cid=35165074 Obvious question]</ref>) the meme involving the Alpaca was born.

The mention in Slashdot included a link to the page for a merchant, Grass Hill Alpacas, that sold Alpaca products for bitcoin. He used that transaction in a subsequent article comparing using Bitcoin as a medium of exchange versus the coincidence of wants that a barter exchange suffers. Shortly after receiving the media mentions, most of the merchant's product offerings had sold out for the remainder of the season.

Bitcoin's former lead developer [[User:Gavinandresen|Gavin Andresen]] tweeted that he had purchased wool socks with bitcoins.

In March, 2011 the [[What is Bitcoin]]? video described Alpaca socks as one of the products Bitcoins could buy.

The reference to Alpaca socks has since been mentioned in quite a number of blog posts, news reports and videos occurring in the months since<ref>[http://www.forbes.com/forbes/2011/0509/technology-psilocybin-bitcoins-gavin-andresen-crypto-currency.html Crypto Currency]</ref>, <ref>[https://www.slate.com/id/2294980 My Money Is Cooler Than Yours]</ref>, <ref>[https://www.technologyreview.com/s/424091/what-bitcoin-is-and-why-it-matters/ What Bitcoin Is, and Why It Matters]</ref>, <ref>[https://www.npr.org/2011/05/24/136620231/what-are-bitcoins What Are Bitcoins?]</ref>.

The Bitcoin community has generally identified with the Alpaca and the Alpaca-Bitcoin meme. An example comes in a response on IRC following the conviction of Bernard Von NotHaus in which the U.S. DOJ labeled him a domestic terrorist for issuing a private currency<ref>[https://web.archive.org/web/20181116042550/https://www.silverbearcafe.com/private/03.11/thoughts.html Thoughts On The Liberty Dollar Debacle]</ref>. The quote "We are 'alpaca-sock-wearing crypto-terrorists'" resonated with Bitcoiners, and the meme persists<ref>[https://bitcointalk.org/index.php?topic=8416.msg123020#msg123020 We are "alpaca-sock-wearing crypto-terrorists"]</ref>.

==References==
<references />

[[Category:Introduction]]

Confirmation

2025-02-22T18:34:13Z

Theymos: /* How Many Confirmations Is Enough */ Remove fujn spam

After a transaction is broadcast to the Bitcoin network, it may be included in a block that is published to the network.
When that happens it is said that the transaction has been mined at a depth of 1 block.
With each subsequent block that is found, the number of blocks deep is increased by one.
To be secure against [[double spending]], a transaction should not be considered as '''confirmed''' until it is a certain number of blocks deep.

Note that unconfirmed transactions do not [[Transaction expiration|expire]].

=Number of Confirmations=

The classic bitcoin client will show a transaction as "n/unconfirmed" until the transaction is 6 blocks deep.
Merchants and exchanges who accept [[trade|bitcoins as payment]] can and should set their own threshold as to how many blocks are required until funds are considered confirmed.
When potential loss due to double spending as nominal, as with very inexpensive or non-fungible items, people may choose not to wait for a transaction to be confirmed, and complete the exchange as soon as it is seen on the network.
Most [[:Category:Exchanges|exchanges]] and other merchants who bear the risk from double spending require 6 or more blocks.

There is nothing special about the default, often-cited figure of 6 blocks. It was chosen based on the assumption that an attacker is unlikely to amass more than 10% of the hashrate, and that a negligible risk of less than 0.1% is acceptable.
Both these figures are arbitrary, however;
6 blocks are overkill for casual attackers, and at the same time powerless against more dedicated attackers with much more than 10% hashrate.

Freshly-mined coins cannot be spent for 100 blocks.
It is advisable to wait some additional time for a better chance that the transaction will be propagated by all nodes.
Some older bitcoin clients won't show generated coins as confirmed until they are 120 blocks deep.

==How Many Confirmations Is Enough==

Transactions with 0/unconfirmed can be reversed with not too much cost via [[Irreversible_Transactions#Attack_vectors|Finney attack and race attack]], but in some cases may still be acceptable especially for low-value goods and services, or ones which can be clawed back.

For transactions with confirmations, the website (https://people.xiph.org/~greg/attack_success.html) can be used to calculate the probability of a successful doublespend given a hashrate proportion and number of confirmations. Note that in the reality of bitcoin mining today, more than 6 confirmations are required. (60 confirmations to have <1% odds of succeeding against an entity with 40% hash power). See Section 11 of the (https://bitcoin.org/bitcoin.pdf bitcoin whitepaper) for the AttackerSuccessProbability formula.

Some mining enterprises may hide their hash power across several mining pools. Also mining [[Mining#ASIC_Mining|ASICs]] can be temporarily overclocked to increase their hash power. This is less power-efficient but could be used for a brief burst of hashrate. For maximum safety, it is recommended that for the irreversible sale of items with value comparable to the block reward, a large number of confirmations (144 blocks = 1 day) is required before completing the exchange.

See also: [[Irreversible Transactions]]

=Confirmation Times=

Each additional confirmation is a new [[block]] being found and added to the end of the [[blockchain]].

Miners create blocks by solving the [[proof of work]] for their proposed block. The block interval has an average of 10 minutes but not every block interval is exactly 10 minutes. It follows a statistical process known as a [https://en.wikipedia.org/wiki/Poisson_point_process poisson process], where random events happen with the same probability in each time interval. Another way of expressing this is that the mining process has no memory, at every second a block has the same chance of being found. Poisson processes are well-understood but can be unintuative.

[[File:Block-interval.png|600px|center|alt text]]

There are lots of block intervals with a time less than 10 minutes but then a few block intervals much longer which bump up the average to 10 minutes. So the bitcoin network can get unlucky and a block won't be found for a whole hour.

[[File:Block-cumulative-interval.png|600px|center|alt text]]

In a 10 minute interval, the probability of a block being found is about 63% (or 1 - e^(-1)). So approximately two-thirds of the time a block will be found in 10 minutes or less. In 30 minutes a block has a 95% chance of being found, which rises to 99.7% if the time interval is 60 minutes.

=See Also=

* [[Blocks]]
* [[Transaction]]

=References=
<references />

[[Category:Technical]]

Block chain

2025-02-22T18:32:40Z

Theymos:

[[File:blockchain.png|thumb|Blocks in the main chain (black) are the longest series of blocks that go from the genesis block (green) to the current block. Purple blocks are blocks that are not in the longest chain and therefore not used.]]

A '''block chain''' is a transaction database shared by all [[Node|nodes]] participating in a system based on the Bitcoin protocol. A full copy of a currency's block chain contains every [[transaction]] ever executed in the currency. With this information, one can find out how much value belonged to each [[address]] at any point in history.

Every [[Blocks|block]] contains a [[hash]] of the previous block. This has the effect of creating a chain of blocks from the [[genesis block]] to the current block. Each block is guaranteed to come after the previous block chronologically because the previous block's hash would otherwise not be known. Each block is also computationally impractical to modify once it has been in the chain for a while because every block after it would also have to be regenerated. These properties are what make bitcoins transactions [[Irreversible Transactions|irreversible]]. The block chain is the main innovation of Bitcoin.

Honest generators only build onto a block (by referencing it in blocks they create) if it is the latest block in the longest valid chain. "Length" is calculated as total combined difficulty of that chain, not number of blocks, though this distinction is only important in the context of a few potential attacks. A chain is valid if all of the blocks and transactions within it are valid, and only if it starts with the genesis block.

For any block on the chain, there is only one path to the genesis block. Coming from the genesis block, however, there can be forks. One-block forks are created from time to time when two blocks are created just a few seconds apart. When that happens, generating nodes build onto whichever one of the blocks they received first. Whichever block ends up being included in the next block becomes part of the main chain because that chain is longer. More serious forks have occurred after fixing bugs that required backward-incompatible changes.

Blocks in shorter chains (or invalid chains) are not used for anything. When the bitcoin client switches to another, longer chain, all valid transactions of the blocks inside the shorter chain are re-added to the pool of queued transactions and will be included in another block. The reward for the blocks on the shorter chain will not be present in the longest chain, so they will be practically lost, which is why a network-enforced 100-block maturation time for generations exists.

These blocks on the shorter chains are often called "orphan" blocks. This is because the generation transactions do not have a parent block in the longest chain, so these generation transactions show up as orphan in the listtransactions RPC call. Several pools have misinterpreted these messages and started calling their blocks "orphans". In reality, these blocks have a parent block, and might even have children.

Because a block can only reference one previous block, it is impossible for two forked chains to merge.

It's possible to use the block chain algorithm for non-financial purposes: see [[Alternative chain]].

The block chain is broadcast to all nodes on the networking using a flood protocol: see [[Block chain download]].

== Blockchain nonsense ==

Blockchain is touted as a magical fairy dust solution that you can sprinkle over a problem and end up with an amazing solution. ICOs have perfected this art (often combining it with other buzz words like IoT and AI) and raised billions of dollars to deliver virtually nothing. If someone comes to you talking about a blockchain project: run if you don't know them. If they're a friend or family, explain to them that it's nonsense to use a blockchain without strong [[proof of work]] and an adequately decentralized network of nodes. 

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

==See Also==

* [[BlockChain.info]] - Utility site and [[EWallet]] provider of similar name
* [https://tokenview.io Tokenview] - A Web based Blockchain Explorer
* [[BlockTrail.com]] - Advanced API and Block Explorer for Bitcoin
* [[Coinprism.info]] - Web based blockchain explorer for bitcoin and colored coin

[[ru:цепочка блоков]]

Help:Getting started

2025-02-22T18:14:17Z

Theymos: Removed protection from "Help:Getting started": Temporarily unprotect for WikiR

{{mbox|title=This wiki and the links it contains can be edited by anyone.|content=Always verify that the URL to the site you are visiting is correct. Before trusting or sending your bitcoins to any website you should always search on additional [[:Bitcoin:Community_portal|community resources]] to see what other users are saying about the service.}}

* Get started buying bitcoins at [[Coinbase_(business)|Coinbase]], [[Bitstamp]] or [[Cubits]].
* Start by watching [http://weusecoins.com/ this 2 minute introduction video].
* Learn why it [http://bitcoin.stackexchange.com/questions/2834/what-are-the-perceived-advantages-of-bitcoin-as-a-store-of-value could be a good investment], or an objectively [http://bitcoin.stackexchange.com/questions/305/what-are-the-perceived-advantages-of-bitcoin-as-a-means-of-exchange better means of exchange].
* Get a [[Clients|client]] and try it out yourself.
* Ask a question at [http://bitcoin.stackexchange.com/ StackExchange] or [http://bitcointalk.org BitcoinTalk].
* [http://bitcoin.stackexchange.com/questions/118/how-much-bitcoin-will-i-mine-right-now-with-hardware-x Can I generate Free Money on my computer?] (No, that's no longer possible.)
* Browse the [[FAQ]].
* [[Buying Bitcoins (the noob version)|Where can I buy bitcoins?]] (Hint: [http://bitcoin.stackexchange.com/questions/2293/how-can-i-buy-bitcoin-via-a-credit-card-or-paypal You can't buy them with Paypal or credit cards])

If you're looking for how to get started with Bitcoin-Qt, [[Getting started installing bitcoin-qt|this is the article you're looking for]].

==See Also==

* [[Introduction|Bitcoin Introduction]]
* [[Trade|Bitcoin Businesses]]
* [[Trading bitcoins]]
{{p-full}}

Transaction broadcasting

2025-02-14T12:02:32Z

Theymos: remove spammy link insertion

{{seealso|Satoshi Client Transaction Exchange}}

==See Also==

* [[Transaction accelerator]]

Third party sites to (re-)submit a raw, signed transaction to the network; sometimes referred to as "pushtx":

* https://bitaps.com/broadcast
* https://btc.network/broadcast
* https://blockchair.com/broadcast
* https://live.blockcypher.com/btc/pushtx/
* https://www.viabtc.com/tools/broadcast
* https://www.blockchain.com/explorer/assets/btc/broadcast-transaction
* https://blockstream.info/tx/push
* https://coinb.in/#broadcast

==Footnotes==
[[Category:Developer]]

Covenants support

2024-12-10T19:57:40Z

Theymos: Merge edit by Summraznboi

<big><big>This list is incomplete and under construction. Evaluation without a rationale will be ignored.</big></big>

{| class="wikitable"
| {{Evaluating}} || Not sure and still evaluating the idea
|-
| {{No}} || Doesn't support
|-
| {{Deficient}} || Okay with the idea, but considers it to have insufficient community support
|-
| {{Weak}} || Better than nothing at all
|-
| {{Wanting}} || Positively likes the idea, but considers it to have insufficient community support
|-
| {{Acceptable}} || It is a workable solution
|-
| {{Prefer}} || The best option all things considered
|}

__TOC__

==Developers==

{| class="wikitable sortable"
! Developer
! Affiliation
! colspan="4" | LNHANCE
! [https://github.com/bitcoin/bips/blob/master/bip-0347.mediawiki OP_CAT]
! [https://merkle.fun/ OP_CCV]
! [https://github.com/bitcoin/bips/blob/master/bip-0345.mediawiki OP_VAULT]
! [https://github.com/bitcoin/bips/blob/2258ebe48cd387ff2f05e1881f54640815b4ab07/bip-txhash.md OP_TXHASH]
! [https://github.com/bitcoin/bips/blob/master/bip-0118.mediawiki SIGHASH_APO]
! Rationale
|-
!
!
! [https://github.com/bitcoin/bips/blob/master/bip-0119.mediawiki OP_CTV]
! [https://github.com/bitcoin/bips/blob/master/bip-0348.md OP_CSFS]
! [https://github.com/bitcoin/bips/blob/018d28c967b3f2b747ecb4e5a85d0b5f9f4ec79a/bip-PC.md OP_PAIRCOMMIT]
! [https://github.com/bitcoin/bips/blob/master/bip-0349.md OP_INTERNALKEY]
!
!
!
!
!
!
|-
| 1440000bytes || joinstr || {{Prefer}} || {{Acceptable}} || {{No}} || {{Acceptable}} || {{Deficient}} || {{Evaluating}} || {{Acceptable}} || {{No}} || {{No}} || [https://gitlab.com/-/snippets/4777553 📌]
|-
| arbedout || Sigbash || {{Acceptable}} || {{Wanting}} || {{Evaluating}} || {{Wanting}} || {{Acceptable}} || {{Evaluating}} || {{Wanting}} || {{Wanting}} || {{Weak}} || [https://gist.github.com/arbedout/94a7350d2a521e42a70ddf9c3f2ce469 📌]
|-
| ArminSabouri || OP_CAT || {{Acceptable}} || {{Prefer}} || {{Evaluating}} || {{Prefer}} || {{Prefer}} || {{Evaluating}} || {{No}} || {{Prefer}} || {{Weak}} ||
|-
| benthecarman || Taproot Wizards || {{Prefer}} || {{Prefer}} || {{Acceptable}} || {{Prefer}} || {{Prefer}} || {{Wanting}} || {{Wanting}} || {{Wanting}} || {{Weak}} ||
|-
| Ben Zhu || Discoco Labs || {{Prefer}} || {{Acceptable}} || {{No}} || {{No}} || {{Prefer}} || {{Evaluating}} || {{Acceptable}} || {{Wanting}} || {{No}} ||
|-
| chrisguida || Lightning || {{Prefer}} || {{Evaluating}} || {{Evaluating}} || {{Acceptable}} || {{No}} || {{Evaluating}} || {{Evaluating}} || {{Evaluating}} || {{Prefer}} ||
|-
| cryptoquick || Surmount Systems || {{Acceptable}} || {{Prefer}} || {{Evaluating}} || {{Prefer}} || {{Acceptable}} || {{Evaluating}} || {{Acceptable}} || {{Prefer}} || {{No}} ||
|-
| Eli Ben-Sasson || StarkWare || {{Evaluating}} || {{Evaluating}} || {{Evaluating}} || {{Evaluating}} || {{Prefer}} || {{Evaluating}} || {{Evaluating}} || {{Evaluating}} || {{Evaluating}} ||
|-
| Ethan Heilman || OP_CAT || {{Prefer}} || {{Prefer}} || {{Evaluating}} || {{Evaluating}} || {{Prefer}} || {{Evaluating}} || {{Prefer}} || {{Prefer}} || {{Evaluating}} ||
|-
| Evan Kaloudis || ZEUS || {{Prefer}} || {{Wanting}} || {{Weak}} || {{Acceptable}} || {{No}} || {{Acceptable}} || {{Prefer}} || {{Deficient}} || {{Prefer}} ||
|-
| everythingsats || African Bitcoiners || {{Prefer}} || {{Prefer}} || {{Acceptable}} || {{Prefer}} || {{Acceptable}} || {{Wanting}} || {{Prefer}} || {{Acceptable}} || {{Acceptable}} ||
|-
| instagibbs || Spiral || {{Weak}} || {{Wanting}} || {{No}} || {{Wanting}} || {{Wanting}} || {{Evaluating}} || {{Wanting}} || {{Wanting}} || {{Weak}} || [https://gist.github.com/instagibbs/eeb9d8013270387b4318b5585e858b9c 📌]
|-
| jamesob || ??? || {{Prefer}} || {{Prefer}} || {{Weak}} || {{Prefer}} || {{Acceptable}} || {{Wanting}} || {{Acceptable}} || {{Deficient}} || {{Weak}} ||
|-
| jaybny || Sidepit || {{Prefer}} || {{Prefer}} || {{Acceptable}} || {{Prefer}} || {{Deficient}} || {{Acceptable}} || {{Wanting}} || {{No}} || {{Acceptable}} ||
|-
| Jon Atack || Bitcoin Core || {{Acceptable}} || {{Evaluating}} || {{Evaluating}} || {{Evaluating}} || {{Evaluating}} || {{Evaluating}} || {{Evaluating}} || {{Evaluating}} || {{Evaluating}} ||
|-
| knocte || geewallet || {{No}} || {{Evaluating}} || {{Evaluating}} || {{Evaluating}} || {{No}} || {{Evaluating}} || {{No}} || {{Evaluating}} || {{Evaluating}} ||
|-
| LucidLuckylee || ZeroSync || {{No}} || {{Acceptable}} || {{No}} || {{No}} || {{Weak}} || {{Evaluating}} || {{Weak}} || {{Prefer}} || {{Weak}} ||
|-
| Luke Dashjr || Bitcoin Knots || {{Acceptable}} || {{Wanting}} || {{Evaluating}} || {{No}} || {{Deficient}} || {{Evaluating}} || {{Evaluating}} || {{Evaluating}} || {{Acceptable}} ||
|-
| matthewjablack || Atomic Finance || {{Prefer}} || {{Acceptable}} || {{Weak}} || {{Acceptable}} || {{Wanting}} || {{Evaluating}} || {{Acceptable}} || {{Wanting}} || {{Weak}} ||
|-
| moonsettler || LNhance || {{Prefer}} || {{Prefer}} || {{Prefer}} || {{Prefer}} || {{Wanting}} || {{Wanting}}<ref name="reardenvault"/> || {{Wanting}}<ref name="reardenvault"/> || {{Wanting}} || {{Weak}} || [https://gist.github.com/moonsettler/76654ca714fac03d9e08da3e47e98b98 📌]
|-
| Nick Hansen || Luxor || {{Prefer}} || {{Prefer}} || {{Evaluating}} || {{Evaluating}} || {{Prefer}} || {{Evaluating}} || {{Acceptable}} || {{Wanting}} || {{Weak}} ||
|-
| Orkun Kılıç || Citrea || {{Acceptable}} || {{Wanting}} || {{No}} || {{No}} || {{Prefer}} || {{Evaluating}} || {{Deficient}} || {{Prefer}} || {{Weak}} ||
|-
| Psifour || Taproot Wizards || {{Prefer}} || {{Prefer}} || {{Weak}} || {{Acceptable}} || {{Prefer}} || {{Deficient}} || {{Deficient}} || {{Weak}} || {{Weak}} || [https://gist.github.com/Psifour/6cba4b6f0fe0ca6dd8d1aa84c878f9ff 📌]
|-
| Paul Sztorc || Drivechain || {{Acceptable}} || {{Wanting}} || {{Weak}} || {{Wanting}} || {{Acceptable}} || {{Evaluating}} || {{Prefer}} || {{Deficient}} || {{Weak}} ||
|-
| reardencode || LNHANCE || {{Prefer}} || {{Prefer}} || {{Acceptable}} || {{Prefer}} || {{Wanting}} || {{Wanting}}<ref name="reardenvault">Only one of CCV and VAULT should be implemented, as they enable nearly identical constructions</ref> || {{Wanting}}<ref name="reardenvault"/> || {{Deficient}} || {{No}} ||
|-
| Rob Hamilton || AnchorWatch || {{Prefer}} || {{Prefer}} || {{Wanting}} || {{Prefer}} || {{Wanting}} || {{Evaluating}} || {{Acceptable}} || {{Wanting}} || {{Weak}} ||
|-
| RobinLinus || Stanford / BitVM || {{No}} || {{Acceptable}} || {{Evaluating}} || {{Evaluating}} || {{No}} || {{Evaluating}} || {{Evaluating}} || {{Prefer}} || {{Weak}} ||
|-
| roujiamo || bitdollar || {{Weak}} || {{Acceptable}} || {{Evaluating}} || {{Wanting}} || {{Prefer}} || {{Weak}} || {{Deficient}} || {{Acceptable}} || {{Deficient}} ||
|-
| Steven Roose || Second (Ark) || {{Prefer}} || {{Prefer}} || {{Evaluating}} || {{Deficient}} || {{Prefer}} || {{Acceptable}} || {{No}} || {{Prefer}} || {{Acceptable}} ||
|-
| xhliu || sCrypt || {{Weak}} || {{Acceptable}} || {{Evaluating}} || {{Wanting}} || {{Prefer}} || {{Weak}} || {{Deficient}} || {{Acceptable}} || {{Deficient}} ||
|-
| ZmnSCPxj || C= || {{Wanting}} || {{Weak}} || {{Wanting}} || {{Wanting}} || {{Deficient}} || {{Evaluating}} || {{Deficient}} || {{Wanting}} || {{Wanting}} ||
|}
<references/>

Talk:Electrum

2024-12-10T15:53:56Z

Theymos: /* Malicious link slipped through */

== List of Commands outdated ==

In version 1.7.2 some of the commands are different:
dumpprivkeys, help, restore, unprioritize, freeze, signmessage, getaddresshistory, getconfig, verifymessage, signrawtransaction, dumpprivkey, setlabel, getseed, contacts, create, setconfig, importprivkey, validateaddress, payto, createmultisig, deseed, getbalance, sendrawtransaction, eval, password, listaddresses, mktx, unfreeze, listunspent, createrawtransaction, prioritize, decoderawtransaction, history {{unsigned|FrankMain|12:24, 27 March 2013‎}}

== Malicious link slipped through ==

The current link to the Electrum website is incorrect and when I click it, uBlock Origin flags it in its "Badware risks" list.

The link was inserted in May, so it's been live for about half a year. This article is in the first page of search results for "Electrum". It's actually one source I checked to make sure I got the legit site.

This seems to be an elaborate scam, as most of the edit actually seems to have added useful info and improved the article. The [[User:Lindsey_Graham|user]]'s only edits are that and creating a friendly, human user page. Note: I just created this account to fix this issue, so I also don't have any history! Please do scrutinize me as well! As long as someone checks out this issue!

I submitted a revert but it went into the moderation queue, assumedly b/c my account is new.

- [[User:Qwerty0|Qwerty0]] ([[User talk:Qwerty0|talk]])
:Nice catch, thanks! [[User:Theymos|theymos]] ([[User talk:Theymos|talk]]) 15:53, 10 December 2024 (UTC)

Bitcoin Wiki:Editing privileges

2024-12-07T22:19:45Z

Theymos: Update in light of Moderation being added

On the Bitcoin Wiki, new users' edits are '''held for review''' by moderators. New users are also subject to additional rules.

== Rules ==

Carefully read and follow these rules:

# '''If your first edits are you adding an external link or creating a page for some service, you're probably going to be banned.''' Do not even add an external link to your own user page. If you think that an external link would really be helpful, suggest it on the page's talk page.
# No self-promotion, and avoid listing sites or services which make their own income (e.g. exchanges, marketplaces, hardware wallet manufacturers, etc). You can talk about the idea of certain products (e.g. hardware wallets exist and are useful in XYZ circumstances), but not list specific brands.
# Generally, the Bitcoin Wiki is a space for Bitcoin, not altcoins.
# Articles here will likely be edited by other people. Try not to take it personally.
# Do not engage in edit wars: use the talk page to find consensus.

== What if my edits are not being approved? ==
After you make your edits, they are automatically added to a queue, and a Permittor should approve or reject them within a few days. Give it some time. Do not complain until at least five days have passed.

If your edits are rejected, first consider that you might have broken the above rules. If not, here are some ways to get in contact with us:
* Post on the [https://bitcointalk.org/index.php?board=168.0 wiki board on bitcointalk.org].
* Join {{Freenode IRC|bitcoin-wiki}} on Freenode - there is also a {{Libera IRC|bitcoin-wiki}} channel on Libera if you prefer that network.
* Contact a [https://en.bitcoin.it/w/index.php?title=Special:ListUsers&group=truster Permittor]. Go to their talk page, and click the "new topic" link at the top. If even your edits to talk pages are being rejected, one of our Permittors is also willing to be contacted [https://spamty.eu/show/v7/237/45773e1f08/ via email].

{{p-full}}
{{DISPLAYTITLE:Bitcoin Wiki:Editing privileges}}

Bitcoin Wiki:Guide for Permittors

2024-12-07T21:47:49Z

Theymos: Created page with "On the Bitcoin Wiki, users' edits are held for review unless said users are designated as Editors. Permittors approve/reject edits held for review, and they also make people into Editors. === Reviewing edits === You review edits on the :Special:Moderation page. * For obvious spam, you should "mark as spammer" and "reject all". * You should only "mark as spammer" if you are '''100%''' sure that the person is an ''irredeemable'' spammer. If you're only 99% sure, reje..."

On the Bitcoin Wiki, users' edits are held for review unless said users are designated as Editors. Permittors approve/reject edits held for review, and they also make people into Editors.

=== Reviewing edits ===

You review edits on the [[:Special:Moderation]] page.
* For obvious spam, you should "mark as spammer" and "reject all".
* You should only "mark as spammer" if you are '''100%''' sure that the person is an ''irredeemable'' spammer. If you're only 99% sure, reject just that one edit, and observe their actions further.
* If an edit is definitely bad, but the user is not an irredeemable spammer, it's best to '''approve''' the edit, revert it, and then leave a comment on their talk page telling them why you reverted it. This is the healthiest thing to do for the community, since it's the best way to turn a bad editor into a good editor. If you reject the edit without comment, then it's a sort of "shadowban" which is likely to make the editor annoyed or frustrated, and they also won't learn what they did wrong.
* You should ''definitely'' not reject an edit when reasonable people could argue that it was a good edit. Approve it and then revert it with your reasoning, so that people can argue about it if they want.

===== Edit conflicts =====

When approving an edit, there can sometimes be edit conflicts, which means that the software can't figure out how to automatically merge the edit. After you get the edit conflict error, you should click the red edit-conflict link to do the manual merge. The current page will be in the top text box, and the user's (now-outdated) version of the page will be in the text box at the bottom of the page. It's also helpful to refer to just the "diff" of the edit, linked back at the main moderation page.

It may be easier to reject the edit and then make the changes to the page yourself, but you should '''not''' do this if at all possible, since then the user won't be properly credited.

=== Promoting Editors ===

After a user has made a couple of good contributions, or if you have other good reasons for thinking that they're a good user, you can add them to the "editor" group at [[:Special:UserRights]].

User talk:NotATether

2024-12-07T19:45:06Z

Theymos: /* "Covenants support" edits */ new section

This page will be used by myself (NotATether) as a staging ground for new topics and revisions.

== Comparison of gift card services ==

- Bitrefill

- Coinsbee

== Fixed GPG screenshot ==

I fixed your screenshot in [https://en.bitcoin.it/w/index.php?title=Electrum&type=revision&diff=70064&oldid=69340]. Cheers. --[[User:Ysangkok|Ysangkok]] ([[User talk:Ysangkok|talk]]) 03:06, 28 February 2024 (UTC)

== "Covenants support" edits ==

The Bitcoin developers would like to limit additions to the [[Covenants support]] page to only credible developers, so please leave edits on that page in the moderation queue for developers 1440000bytes and ReardenCode to approve or reject.

Also, I apologize for not properly explaining/announcing the Moderation feature to you or anyone yet. It was just added a month or two ago, and I plan to write some proper guidelines etc. on it as soon as I get a chance. I see you figured it out on your own and have been rejecting/approving edits: thank you! [[User:Theymos|theymos]] ([[User talk:Theymos|talk]]) 19:45, 7 December 2024 (UTC)

User talk:1440000bytes

2024-12-05T18:21:09Z

Theymos: /* Permittor */ new section

== Permittor ==

If new Bitcoin Wiki users are not in the Editors group, then their edits are held back for review by a Permittor. A number of new users have joined so that they can edit [[Covenants support]]. These edits require review, and since you created the page, I made you a Permittor. I will consider you to have primary responsibility for approving/rejecting edits on that page.

Edits held for review are listed at [[:Special:Moderation]]. If edits conflict, then you will have to manually merge the edits into the page. You can also make people an Editor (exempting them from future need for review) at [[:Special:UserRights]].

Thanks! [[User:Theymos|theymos]] ([[User talk:Theymos|talk]]) 18:21, 5 December 2024 (UTC)

Covenants support

2024-12-05T18:20:31Z

Theymos: alphabetize

<big><big>This list is incomplete and under construction.</big></big>

{| class="wikitable"
| {{Evaluating}} || Not sure. Still evaluating the idea
|-
| {{No}} || Doesn't support (but might or might not go along with it with sufficient community support)
|-
| {{Deficient}} || Okay with the idea, but considers it to have insufficient community support
|-
| {{Weak}} || Better than nothing at all
|-
| {{Wanting}} || Positively likes the idea, but considers it to have insufficient community support
|-
| {{Acceptable}} || It is a workable solution
|-
| {{Prefer}} || The best option all things considered
|}

__TOC__

==Developers==

{| class="wikitable sortable"
! Developer
! Affiliation
! colspan="4" | LNHANCE
! OP_CAT
! OP_CCV
! OP_VAULT
! OP_TXHASH
! SIGHASH_APO
|-
!
!
! OP_CTV
! OP_CSFS
! OP_PAIRCOMMIT
! OP_INTERNALKEY
!
!
!
!
!
|-
| 1440000bytes || joinstr || {{Prefer}} || {{Acceptable}} || {{No}} || {{Acceptable}} || {{Deficient}} || {{Evaluating}}|| {{Acceptable}} || {{No}} || {{No}}
|-
| ArminSabouri || OP_CAT || {{Acceptable}} || {{Prefer}} || {{Evaluating}} || {{Prefer}} || {{Prefer}} || {{Evaluating}} || {{No}} || {{Prefer}} || {{Weak}}
|-
| benthecarman || Taproot Wizards || {{Prefer}} || {{Prefer}} || {{Acceptable}} || {{Prefer}} || {{Prefer}} || {{Wanting}} || {{Wanting}} || {{Wanting}} || {{Weak}}
|-
| chrisguida || Lightning || {{Prefer}} || {{Evaluating}} || {{Evaluating}} || {{Acceptable}} || {{No}} || {{Evaluating}} || {{Evaluating}} || {{Evaluating}} || {{Prefer}}
|-
| cryptoquick || Surmount Systems || {{Acceptable}} || {{Prefer}} || {{Evaluating}} || {{Prefer}} || {{Acceptable}} || {{Evaluating}} || {{Acceptable}} || {{Prefer}} || {{No}}
|-
| Evan Kaloudis || ZEUS || {{Prefer}} || {{Wanting}} || {{Weak}} || {{Acceptable}} || {{No}} || {{Acceptable}} || {{Prefer}} || {{Deficient}} || {{Prefer}}
|-
| instagibbs || Spiral || {{Weak}} || {{Wanting}} || {{No}} || {{Wanting}} || {{Wanting}} || {{Evaluating}} || {{Wanting}} || {{Wanting}} || {{Weak}}
|-
| jamesob || ??? || {{Prefer}} || {{Prefer}} || {{Weak}} || {{Prefer}} || {{Acceptable}} || {{Wanting}} || {{Acceptable}} || {{Deficient}} || {{Weak}}
|-
| jaybny || Sidepit|| {{Prefer}} || {{Evaluating}} || {{Evaluating}} || {{Evaluating}} || {{Weak}} || {{Evaluating}} || {{Evaluating}} || {{Evaluating}} || {{Acceptable}}
|-
| Jon Atack || Bitcoin Core || {{Acceptable}} || {{Evaluating}} || {{Evaluating}} || {{Evaluating}} || {{Evaluating}} || {{Evaluating}} || {{Evaluating}} || {{Evaluating}} || {{Evaluating}}
|-
| Luke Dashjr || Bitcoin Knots || {{Acceptable}} || {{Wanting}} || {{Evaluating}} || {{No}} || {{Deficient}} || {{Evaluating}} || {{Evaluating}} || {{Evaluating}} || {{Acceptable}}
|-
| matthewjablack || Atomic Finance || {{Prefer}} || {{Acceptable}} || {{Weak}} || {{Acceptable}} || {{Wanting}} || {{Evaluating}} || {{Acceptable}} || {{Wanting}} || {{Weak}}
|-
| moonsettler || LNhance || {{Prefer}} || {{Prefer}} || {{Prefer}} || {{Prefer}} || {{Wanting}} || {{Wanting}} || {{Wanting}} || {{Wanting}} || {{Weak}}
|-
| Orkun Kılıç || Citrea || {{Acceptable}} || {{Wanting}} || {{No}} || {{No}} || {{Prefer}} || {{Evaluating}} || {{Deficient}} || {{Prefer}} || {{Weak}}
|-
| reardencode || LNHANCE || {{Prefer}} || {{Prefer}} || {{Acceptable}} || {{Prefer}} || {{Wanting}} || {{Wanting}}<ref name="reardenvault">Only one of CCV and VAULT should be implemented, as they enable nearly identical constructions</ref> || {{Wanting}}<ref name="reardenvault"/> || {{Deficient}} || {{No}}
|-
| RobinLinus || BitVM || {{No}} || {{Acceptable}} || {{Evaluating}} || {{No}} || {{Deficient}} || {{Evaluating}} || {{Evaluating}} || {{Prefer}} || {{Weak}}

|}
<references/>

Covenants support

2024-12-05T18:08:27Z

Theymos: Merge edit by Orkunkilic

<big><big>This list is incomplete and under construction.</big></big>

{| class="wikitable"
| {{Evaluating}} || Not sure. Still evaluating the idea
|-
| {{No}} || Doesn't support (but might or might not go along with it with sufficient community support)
|-
| {{Deficient}} || Okay with the idea, but considers it to have insufficient community support
|-
| {{Weak}} || Better than nothing at all
|-
| {{Wanting}} || Positively likes the idea, but considers it to have insufficient community support
|-
| {{Acceptable}} || It is a workable solution
|-
| {{Prefer}} || The best option all things considered
|}

__TOC__

==Developers==

{| class="wikitable sortable"
! Developer
! Affiliation
! colspan="4" | LNHANCE
! OP_CAT
! OP_CCV
! OP_VAULT
! OP_TXHASH
! SIGHASH_APO
|-
!
!
! OP_CTV
! OP_CSFS
! OP_PAIRCOMMIT
! OP_INTERNALKEY
!
!
!
!
!
|-
| 1440000bytes || joinstr || {{Prefer}} || {{Acceptable}} || {{No}} || {{Acceptable}} || {{Deficient}} || {{Evaluating}}|| {{Acceptable}} || {{No}} || {{No}}
|-
| benthecarman || Taproot Wizards || {{Prefer}} || {{Prefer}} || {{Acceptable}} || {{Prefer}} || {{Prefer}} || {{Wanting}} || {{Wanting}} || {{Wanting}} || {{Weak}}
|-
| chrisguida || Lightning || {{Prefer}} || {{Evaluating}} || {{Evaluating}} || {{Acceptable}} || {{No}} || {{Evaluating}} || {{Evaluating}} || {{Evaluating}} || {{Prefer}}
|-
| cryptoquick || Surmount Systems || {{Acceptable}} || {{Prefer}} || {{Evaluating}} || {{Prefer}} || {{Acceptable}} || {{Evaluating}} || {{Acceptable}} || {{Prefer}} || {{No}}
|-
| Evan Kaloudis || ZEUS || {{Prefer}} || {{Wanting}} || {{Weak}} || {{Acceptable}} || {{No}} || {{Acceptable}} || {{Prefer}} || {{Deficient}} || {{Prefer}}
|-
| instagibbs || Spiral || {{Weak}} || {{Wanting}} || {{No}} || {{Wanting}} || {{Wanting}} || {{Evaluating}} || {{Wanting}} || {{Wanting}} || {{Weak}}
|-
| jamesob || ??? || {{Prefer}} || {{Prefer}} || {{Weak}} || {{Prefer}} || {{Acceptable}} || {{Wanting}} || {{Acceptable}} || {{Deficient}} || {{Weak}}
|-
| jaybny || Sidepit|| {{Prefer}} || {{Evaluating}} || {{Evaluating}} || {{Evaluating}} || {{Weak}} || {{Evaluating}} || {{Evaluating}} || {{Evaluating}} || {{Acceptable}}
|-
| Jon Atack || Bitcoin Core || {{Acceptable}} || {{Evaluating}} || {{Evaluating}} || {{Evaluating}} || {{Evaluating}} || {{Evaluating}} || {{Evaluating}} || {{Evaluating}} || {{Evaluating}}
|-
| Luke Dashjr || Bitcoin Knots || {{Acceptable}} || {{Wanting}} || {{Evaluating}} || {{No}} || {{Deficient}} || {{Evaluating}} || {{Evaluating}} || {{Evaluating}} || {{Acceptable}}
|-
| matthewjablack || Atomic Finance || {{Prefer}} || {{Acceptable}} || {{Weak}} || {{Acceptable}} || {{Wanting}} || {{Evaluating}} || {{Acceptable}} || {{Wanting}} || {{Weak}}
|-
| moonsettler || LNhance || {{Prefer}} || {{Prefer}} || {{Prefer}} || {{Prefer}} || {{Wanting}} || {{Wanting}} || {{Wanting}} || {{Wanting}} || {{Weak}}
|-
| reardencode || LNHANCE || {{Prefer}} || {{Prefer}} || {{Acceptable}} || {{Prefer}} || {{Wanting}} || {{Wanting}}<ref name="reardenvault">Only one of CCV and VAULT should be implemented, as they enable nearly identical constructions</ref> || {{Wanting}}<ref name="reardenvault"/> || {{Deficient}} || {{No}}
|-
| RobinLinus || BitVM || {{No}} || {{Acceptable}} || {{Evaluating}} || {{No}} || {{Deficient}} || {{Evaluating}} || {{Evaluating}} || {{Prefer}} || {{Weak}}
|-
| ArminSabouri || OP_CAT || {{Acceptable}} || {{Prefer}} || {{Evaluating}} || {{Prefer}} || {{Prefer}} || {{Evaluating}} || {{No}} || {{Prefer}} || {{Weak}}
|-
| Orkun Kılıç || Citrea || {{Acceptable}} || {{Wanting}} || {{No}} || {{No}} || {{Prefer}} || {{Evaluating}} || {{Deficient}} || {{Prefer}} || {{Weak}}
|}
<references/>

Covenants support

2024-12-05T18:08:03Z

Theymos: Merge edit by Arminsdev

<big><big>This list is incomplete and under construction.</big></big>

{| class="wikitable"
| {{Evaluating}} || Not sure. Still evaluating the idea
|-
| {{No}} || Doesn't support (but might or might not go along with it with sufficient community support)
|-
| {{Deficient}} || Okay with the idea, but considers it to have insufficient community support
|-
| {{Weak}} || Better than nothing at all
|-
| {{Wanting}} || Positively likes the idea, but considers it to have insufficient community support
|-
| {{Acceptable}} || It is a workable solution
|-
| {{Prefer}} || The best option all things considered
|}

__TOC__

==Developers==

{| class="wikitable sortable"
! Developer
! Affiliation
! colspan="4" | LNHANCE
! OP_CAT
! OP_CCV
! OP_VAULT
! OP_TXHASH
! SIGHASH_APO
|-
!
!
! OP_CTV
! OP_CSFS
! OP_PAIRCOMMIT
! OP_INTERNALKEY
!
!
!
!
!
|-
| 1440000bytes || joinstr || {{Prefer}} || {{Acceptable}} || {{No}} || {{Acceptable}} || {{Deficient}} || {{Evaluating}}|| {{Acceptable}} || {{No}} || {{No}}
|-
| benthecarman || Taproot Wizards || {{Prefer}} || {{Prefer}} || {{Acceptable}} || {{Prefer}} || {{Prefer}} || {{Wanting}} || {{Wanting}} || {{Wanting}} || {{Weak}}
|-
| chrisguida || Lightning || {{Prefer}} || {{Evaluating}} || {{Evaluating}} || {{Acceptable}} || {{No}} || {{Evaluating}} || {{Evaluating}} || {{Evaluating}} || {{Prefer}}
|-
| cryptoquick || Surmount Systems || {{Acceptable}} || {{Prefer}} || {{Evaluating}} || {{Prefer}} || {{Acceptable}} || {{Evaluating}} || {{Acceptable}} || {{Prefer}} || {{No}}
|-
| Evan Kaloudis || ZEUS || {{Prefer}} || {{Wanting}} || {{Weak}} || {{Acceptable}} || {{No}} || {{Acceptable}} || {{Prefer}} || {{Deficient}} || {{Prefer}}
|-
| instagibbs || Spiral || {{Weak}} || {{Wanting}} || {{No}} || {{Wanting}} || {{Wanting}} || {{Evaluating}} || {{Wanting}} || {{Wanting}} || {{Weak}}
|-
| jamesob || ??? || {{Prefer}} || {{Prefer}} || {{Weak}} || {{Prefer}} || {{Acceptable}} || {{Wanting}} || {{Acceptable}} || {{Deficient}} || {{Weak}}
|-
| jaybny || Sidepit|| {{Prefer}} || {{Evaluating}} || {{Evaluating}} || {{Evaluating}} || {{Weak}} || {{Evaluating}} || {{Evaluating}} || {{Evaluating}} || {{Acceptable}}
|-
| Jon Atack || Bitcoin Core || {{Acceptable}} || {{Evaluating}} || {{Evaluating}} || {{Evaluating}} || {{Evaluating}} || {{Evaluating}} || {{Evaluating}} || {{Evaluating}} || {{Evaluating}}
|-
| Luke Dashjr || Bitcoin Knots || {{Acceptable}} || {{Wanting}} || {{Evaluating}} || {{No}} || {{Deficient}} || {{Evaluating}} || {{Evaluating}} || {{Evaluating}} || {{Acceptable}}
|-
| matthewjablack || Atomic Finance || {{Prefer}} || {{Acceptable}} || {{Weak}} || {{Acceptable}} || {{Wanting}} || {{Evaluating}} || {{Acceptable}} || {{Wanting}} || {{Weak}}
|-
| moonsettler || LNhance || {{Prefer}} || {{Prefer}} || {{Prefer}} || {{Prefer}} || {{Wanting}} || {{Wanting}} || {{Wanting}} || {{Wanting}} || {{Weak}}
|-
| reardencode || LNHANCE || {{Prefer}} || {{Prefer}} || {{Acceptable}} || {{Prefer}} || {{Wanting}} || {{Wanting}}<ref name="reardenvault">Only one of CCV and VAULT should be implemented, as they enable nearly identical constructions</ref> || {{Wanting}}<ref name="reardenvault"/> || {{Deficient}} || {{No}}
|-
| RobinLinus || BitVM || {{No}} || {{Acceptable}} || {{Evaluating}} || {{No}} || {{Deficient}} || {{Evaluating}} || {{Evaluating}} || {{Prefer}} || {{Weak}}
|-
| ArminSabouri || OP_CAT || {{Acceptable}} || {{Prefer}} || {{Evaluating}} || {{Prefer}} || {{Prefer}} || {{Evaluating}} || {{No}} || {{Prefer}} || {{Weak}}
|}
<references/>

Covenants support

2024-12-05T11:50:11Z

Theymos: Merge edit by ReardenCode

<big><big>This list is incomplete and under construction.</big></big>

{| class="wikitable"
| {{Evaluating}} || Not sure. Still evaluating the idea
|-
| {{No}} || Doesn't support (but might or might not go along with it with sufficient community support)
|-
| {{Deficient}} || Okay with the idea, but considers it to have insufficient community support
|-
| {{Weak}} || Better than nothing at all
|-
| {{Wanting}} || Positively likes the idea, but considers it to have insufficient community support
|-
| {{Acceptable}} || It is a workable solution
|-
| {{Prefer}} || The best option all things considered
|}

__TOC__

==Developers==

{| class="wikitable sortable"
! Developer
! Affiliation
! colspan="4" | LNHANCE
! OP_CAT
! OP_CCV
! OP_VAULT
! OP_TXHASH
! SIGHASH_APO
|-
!
!
! OP_CTV
! OP_CSFS
! OP_PAIRCOMMIT
! OP_INTERNALKEY
!
!
!
!
!
|-
| 1440000bytes || joinstr || {{Prefer}} || {{Acceptable}} || {{No}} || {{Acceptable}} || {{Deficient}} || {{Evaluating}}|| {{Acceptable}} || {{No}} || {{No}}
|-
| Jon Atack || Bitcoin Core || {{Acceptable}} || {{Evaluating}} || {{Evaluating}} || {{Evaluating}} || {{Evaluating}} || {{Evaluating}} || {{Evaluating}} || {{Evaluating}} || {{Evaluating}}
|-
| Luke Dashjr || Bitcoin Knots || {{Acceptable}} || {{Wanting}} || {{Evaluating}} || {{No}} || {{Deficient}} || {{Evaluating}} || {{Evaluating}} || {{Evaluating}} || {{Acceptable}}
|-
| moonsettler || LNhance || {{Prefer}} || {{Prefer}} || {{Prefer}} || {{Prefer}} || {{Wanting}} || {{Wanting}} || {{Wanting}} || {{Wanting}} || {{Weak}}
|-
| matthewjablack || Atomic Finance || {{Prefer}} || {{Acceptable}} || {{Weak}} || {{Acceptable}} || {{Wanting}} || {{Evaluating}} || {{Acceptable}} || {{Wanting}} || {{Weak}}
|-
| reardencode || LNHANCE || {{Prefer}} || {{Prefer}} || {{Acceptable}} || {{Prefer}} || {{Wanting}} || {{Wanting}}<ref name="reardenvault">Only one of CCV and VAULT should be implemented, as they enable nearly identical constructions</ref> || {{Wanting}}<ref name="reardenvault"/> || {{Deficient}} || {{No}}
|-
| benthecarman || Taproot Wizards || {{Prefer}} || {{Prefer}} || {{Acceptable}} || {{Prefer}} || {{Prefer}} || {{Wanting}} || {{Wanting}} || {{Wanting}} || {{Weak}}
|-
| instagibbs || Spiral || {{Weak}} || {{Wanting}} || {{No}} || {{Wanting}} || {{Wanting}} || {{Evaluating}} || {{Wanting}} || {{Wanting}} || {{Weak}}
|-
| anon nonane dev || Bitcoin/LN || {{No}} || {{Evaluating}} || {{Evaluating}} || {{No}} || {{No}} || {{Evaluating}} || {{Evaluating}} || {{Evaluating}} || {{Evaluating}}
|-
| jaybny || Sidepit|| {{Prefer}} || {{Evaluating}} || {{Evaluating}} || {{Evaluating}} || {{Weak}} || {{Evaluating}} || {{Evaluating}} || {{Evaluating}} || {{Acceptable}}
|-
| cryptoquick || Surmount Systems || {{Acceptable}} || {{Prefer}} || {{Evaluating}} || {{Prefer}} || {{Acceptable}} || {{Evaluating}} || {{Acceptable}} || {{Prefer}} || {{No}}
|-
| RobinLinus || BitVM || {{No}} || {{Acceptable}} || {{Evaluating}} || {{No}} || {{Deficient}} || {{Evaluating}} || {{Evaluating}} || {{Prefer}} || {{Weak}}
|-
| jamesob || ??? || {{Prefer}} || {{Prefer}} || {{Weak}} || {{Prefer}} || {{Acceptable}} || {{Wanting}} || {{Acceptable}} || {{Deficient}} || {{Weak}}
|-
| Evan Kaloudis || ZEUS || {{Prefer}} || {{Wanting}} || {{Weak}} || {{Acceptable}} || {{No}} || {{Acceptable}} || {{Prefer}} || {{Deficient}} || {{Prefer}}
|}
<references/>

Covenants support

2024-12-05T11:48:14Z

Theymos: Merge edit by Kaloudis

<big><big>This list is incomplete and under construction.</big></big>

{| class="wikitable"
| {{Evaluating}} || Not sure. Still evaluating the idea
|-
| {{No}} || Doesn't support (but might or might not go along with it with sufficient community support)
|-
| {{Deficient}} || Okay with the idea, but considers it to have insufficient community support
|-
| {{Weak}} || Better than nothing at all
|-
| {{Wanting}} || Positively likes the idea, but considers it to have insufficient community support
|-
| {{Acceptable}} || It is a workable solution
|-
| {{Prefer}} || The best option all things considered
|}

__TOC__

==Developers==

{| class="wikitable sortable"
! Developer
! Affiliation
! colspan="4" | LNHANCE
! OP_CAT
! OP_CCV
! OP_VAULT
! OP_TXHASH
! SIGHASH_APO
|-
!
!
! OP_CTV
! OP_CSFS
! OP_PAIRCOMMIT
! OP_INTERNALKEY
!
!
!
!
!
|-
| 1440000bytes || joinstr || {{Prefer}} || {{Acceptable}} || {{No}} || {{Acceptable}} || {{Deficient}} || {{Evaluating}}|| {{Acceptable}} || {{No}} || {{No}}
|-
| Jon Atack || Bitcoin Core || {{Acceptable}} || {{Evaluating}} || {{Evaluating}} || {{Evaluating}} || {{Evaluating}} || {{Evaluating}} || {{Evaluating}} || {{Evaluating}} || {{Evaluating}}
|-
| Luke Dashjr || Bitcoin Knots || {{Acceptable}} || {{Wanting}} || {{Evaluating}} || {{No}} || {{Deficient}} || {{Evaluating}} || {{Evaluating}} || {{Evaluating}} || {{Acceptable}}
|-
| moonsettler || LNhance || {{Prefer}} || {{Prefer}} || {{Prefer}} || {{Prefer}} || {{Wanting}} || {{Wanting}} || {{Wanting}} || {{Wanting}} || {{Weak}}
|-
| matthewjablack || Atomic Finance || {{Prefer}} || {{Acceptable}} || {{Weak}} || {{Acceptable}} || {{Wanting}} || {{Evaluating}} || {{Acceptable}} || {{Wanting}} || {{Weak}}
|-
| reardencode || LNHANCE || {{Prefer}} || {{Prefer}} || {{Acceptable}} || {{Prefer}} || {{Wanting}} || {{Wanting}} || {{Wanting}} || {{Deficient}} || {{No}}
|-
| benthecarman || Taproot Wizards || {{Prefer}} || {{Prefer}} || {{Acceptable}} || {{Prefer}} || {{Prefer}} || {{Wanting}} || {{Wanting}} || {{Wanting}} || {{Weak}}
|-
| instagibbs || Spiral || {{Weak}} || {{Wanting}} || {{No}} || {{Wanting}} || {{Wanting}} || {{Evaluating}} || {{Wanting}} || {{Wanting}} || {{Weak}}
|-
| anon nonane dev || Bitcoin/LN || {{No}} || {{Evaluating}} || {{Evaluating}} || {{No}} || {{No}} || {{Evaluating}} || {{Evaluating}} || {{Evaluating}} || {{Evaluating}}
|-
| jaybny || Sidepit|| {{Prefer}} || {{Evaluating}} || {{Evaluating}} || {{Evaluating}} || {{Weak}} || {{Evaluating}} || {{Evaluating}} || {{Evaluating}} || {{Acceptable}}
|-
| cryptoquick || Surmount Systems || {{Acceptable}} || {{Prefer}} || {{Evaluating}} || {{Prefer}} || {{Acceptable}} || {{Evaluating}} || {{Acceptable}} || {{Prefer}} || {{No}}
|-
| RobinLinus || BitVM || {{No}} || {{Acceptable}} || {{Evaluating}} || {{No}} || {{Deficient}} || {{Evaluating}} || {{Evaluating}} || {{Prefer}} || {{Weak}}
|-
| jamesob || ??? || {{Prefer}} || {{Prefer}} || {{Weak}} || {{Prefer}} || {{Acceptable}} || {{Wanting}} || {{Acceptable}} || {{Deficient}} || {{Weak}}
|-
| Evan Kaloudis || ZEUS || {{Prefer}} || {{Wanting}} || {{Weak}} || {{Acceptable}} || {{No}} || {{Acceptable}} || {{Prefer}} || {{Deficient}} || {{Prefer}}
|}

Covenants support

2024-12-05T11:47:44Z

Theymos: Merge edit by Jamesob

<big><big>This list is incomplete and under construction.</big></big>

{| class="wikitable"
| {{Evaluating}} || Not sure. Still evaluating the idea
|-
| {{No}} || Doesn't support (but might or might not go along with it with sufficient community support)
|-
| {{Deficient}} || Okay with the idea, but considers it to have insufficient community support
|-
| {{Weak}} || Better than nothing at all
|-
| {{Wanting}} || Positively likes the idea, but considers it to have insufficient community support
|-
| {{Acceptable}} || It is a workable solution
|-
| {{Prefer}} || The best option all things considered
|}

__TOC__

==Developers==

{| class="wikitable sortable"
! Developer
! Affiliation
! colspan="4" | LNHANCE
! OP_CAT
! OP_CCV
! OP_VAULT
! OP_TXHASH
! SIGHASH_APO
|-
!
!
! OP_CTV
! OP_CSFS
! OP_PAIRCOMMIT
! OP_INTERNALKEY
!
!
!
!
!
|-
| 1440000bytes || joinstr || {{Prefer}} || {{Acceptable}} || {{No}} || {{Acceptable}} || {{Deficient}} || {{Evaluating}}|| {{Acceptable}} || {{No}} || {{No}}
|-
| Jon Atack || Bitcoin Core || {{Acceptable}} || {{Evaluating}} || {{Evaluating}} || {{Evaluating}} || {{Evaluating}} || {{Evaluating}} || {{Evaluating}} || {{Evaluating}} || {{Evaluating}}
|-
| Luke Dashjr || Bitcoin Knots || {{Acceptable}} || {{Wanting}} || {{Evaluating}} || {{No}} || {{Deficient}} || {{Evaluating}} || {{Evaluating}} || {{Evaluating}} || {{Acceptable}}
|-
| moonsettler || LNhance || {{Prefer}} || {{Prefer}} || {{Prefer}} || {{Prefer}} || {{Wanting}} || {{Wanting}} || {{Wanting}} || {{Wanting}} || {{Weak}}
|-
| matthewjablack || Atomic Finance || {{Prefer}} || {{Acceptable}} || {{Weak}} || {{Acceptable}} || {{Wanting}} || {{Evaluating}} || {{Acceptable}} || {{Wanting}} || {{Weak}}
|-
| reardencode || LNHANCE || {{Prefer}} || {{Prefer}} || {{Acceptable}} || {{Prefer}} || {{Wanting}} || {{Wanting}} || {{Wanting}} || {{Deficient}} || {{No}}
|-
| benthecarman || Taproot Wizards || {{Prefer}} || {{Prefer}} || {{Acceptable}} || {{Prefer}} || {{Prefer}} || {{Wanting}} || {{Wanting}} || {{Wanting}} || {{Weak}}
|-
| instagibbs || Spiral || {{Weak}} || {{Wanting}} || {{No}} || {{Wanting}} || {{Wanting}} || {{Evaluating}} || {{Wanting}} || {{Wanting}} || {{Weak}}
|-
| anon nonane dev || Bitcoin/LN || {{No}} || {{Evaluating}} || {{Evaluating}} || {{No}} || {{No}} || {{Evaluating}} || {{Evaluating}} || {{Evaluating}} || {{Evaluating}}
|-
| jaybny || Sidepit|| {{Prefer}} || {{Evaluating}} || {{Evaluating}} || {{Evaluating}} || {{Weak}} || {{Evaluating}} || {{Evaluating}} || {{Evaluating}} || {{Acceptable}}
|-
| cryptoquick || Surmount Systems || {{Acceptable}} || {{Prefer}} || {{Evaluating}} || {{Prefer}} || {{Acceptable}} || {{Evaluating}} || {{Acceptable}} || {{Prefer}} || {{No}}
|-
| RobinLinus || BitVM || {{No}} || {{Acceptable}} || {{Evaluating}} || {{No}} || {{Deficient}} || {{Evaluating}} || {{Evaluating}} || {{Prefer}} || {{Weak}}
|-
| jamesob || ??? || {{Prefer}} || {{Prefer}} || {{Weak}} || {{Prefer}} || {{Acceptable}} || {{Wanting}} || {{Acceptable}} || {{Deficient}} || {{Weak}}
|}

Covenants support

2024-12-05T11:47:21Z

Theymos: Merge edit by RobinLinus

<big><big>This list is incomplete and under construction.</big></big>

{| class="wikitable"
| {{Evaluating}} || Not sure. Still evaluating the idea
|-
| {{No}} || Doesn't support (but might or might not go along with it with sufficient community support)
|-
| {{Deficient}} || Okay with the idea, but considers it to have insufficient community support
|-
| {{Weak}} || Better than nothing at all
|-
| {{Wanting}} || Positively likes the idea, but considers it to have insufficient community support
|-
| {{Acceptable}} || It is a workable solution
|-
| {{Prefer}} || The best option all things considered
|}

__TOC__

==Developers==

{| class="wikitable sortable"
! Developer
! Affiliation
! colspan="4" | LNHANCE
! OP_CAT
! OP_CCV
! OP_VAULT
! OP_TXHASH
! SIGHASH_APO
|-
!
!
! OP_CTV
! OP_CSFS
! OP_PAIRCOMMIT
! OP_INTERNALKEY
!
!
!
!
!
|-
| 1440000bytes || joinstr || {{Prefer}} || {{Acceptable}} || {{No}} || {{Acceptable}} || {{Deficient}} || {{Evaluating}}|| {{Acceptable}} || {{No}} || {{No}}
|-
| Jon Atack || Bitcoin Core || {{Acceptable}} || {{Evaluating}} || {{Evaluating}} || {{Evaluating}} || {{Evaluating}} || {{Evaluating}} || {{Evaluating}} || {{Evaluating}} || {{Evaluating}}
|-
| Luke Dashjr || Bitcoin Knots || {{Acceptable}} || {{Wanting}} || {{Evaluating}} || {{No}} || {{Deficient}} || {{Evaluating}} || {{Evaluating}} || {{Evaluating}} || {{Acceptable}}
|-
| moonsettler || LNhance || {{Prefer}} || {{Prefer}} || {{Prefer}} || {{Prefer}} || {{Wanting}} || {{Wanting}} || {{Wanting}} || {{Wanting}} || {{Weak}}
|-
| matthewjablack || Atomic Finance || {{Prefer}} || {{Acceptable}} || {{Weak}} || {{Acceptable}} || {{Wanting}} || {{Evaluating}} || {{Acceptable}} || {{Wanting}} || {{Weak}}
|-
| reardencode || LNHANCE || {{Prefer}} || {{Prefer}} || {{Acceptable}} || {{Prefer}} || {{Wanting}} || {{Wanting}} || {{Wanting}} || {{Deficient}} || {{No}}
|-
| benthecarman || Taproot Wizards || {{Prefer}} || {{Prefer}} || {{Acceptable}} || {{Prefer}} || {{Prefer}} || {{Wanting}} || {{Wanting}} || {{Wanting}} || {{Weak}}
|-
| instagibbs || Spiral || {{Weak}} || {{Wanting}} || {{No}} || {{Wanting}} || {{Wanting}} || {{Evaluating}} || {{Wanting}} || {{Wanting}} || {{Weak}}
|-
| anon nonane dev || Bitcoin/LN || {{No}} || {{Evaluating}} || {{Evaluating}} || {{No}} || {{No}} || {{Evaluating}} || {{Evaluating}} || {{Evaluating}} || {{Evaluating}}
|-
| jaybny || Sidepit|| {{Prefer}} || {{Evaluating}} || {{Evaluating}} || {{Evaluating}} || {{Weak}} || {{Evaluating}} || {{Evaluating}} || {{Evaluating}} || {{Acceptable}}
|-
| cryptoquick || Surmount Systems || {{Acceptable}} || {{Prefer}} || {{Evaluating}} || {{Prefer}} || {{Acceptable}} || {{Evaluating}} || {{Acceptable}} || {{Prefer}} || {{No}}
|-
| RobinLinus || BitVM || {{No}} || {{Acceptable}} || {{Evaluating}} || {{No}} || {{Deficient}} || {{Evaluating}} || {{Evaluating}} || {{Prefer}} || {{Weak}}
|}

Covenants support

2024-12-05T11:46:16Z

Theymos: Merge edit by Matthewjablack

<big><big>This list is incomplete and under construction.</big></big>

{| class="wikitable"
| {{Evaluating}} || Not sure. Still evaluating the idea
|-
| {{No}} || Doesn't support (but might or might not go along with it with sufficient community support)
|-
| {{Deficient}} || Okay with the idea, but considers it to have insufficient community support
|-
| {{Weak}} || Better than nothing at all
|-
| {{Wanting}} || Positively likes the idea, but considers it to have insufficient community support
|-
| {{Acceptable}} || It is a workable solution
|-
| {{Prefer}} || The best option all things considered
|}

__TOC__

==Developers==

{| class="wikitable sortable"
! Developer
! Affiliation
! colspan="4" | LNHANCE
! OP_CAT
! OP_CCV
! OP_VAULT
! OP_TXHASH
! SIGHASH_APO
|-
!
!
! OP_CTV
! OP_CSFS
! OP_PAIRCOMMIT
! OP_INTERNALKEY
!
!
!
!
!
|-
| 1440000bytes || joinstr || {{Prefer}} || {{Acceptable}} || {{No}} || {{Acceptable}} || {{Deficient}} || {{Evaluating}}|| {{Acceptable}} || {{No}} || {{No}}
|-
| Jon Atack || Bitcoin Core || {{Acceptable}} || {{Evaluating}} || {{Evaluating}} || {{Evaluating}} || {{Evaluating}} || {{Evaluating}} || {{Evaluating}} || {{Evaluating}} || {{Evaluating}}
|-
| Luke Dashjr || Bitcoin Knots || {{Acceptable}} || {{Wanting}} || {{Evaluating}} || {{No}} || {{Deficient}} || {{Evaluating}} || {{Evaluating}} || {{Evaluating}} || {{Acceptable}}
|-
| moonsettler || LNhance || {{Prefer}} || {{Prefer}} || {{Prefer}} || {{Prefer}} || {{Wanting}} || {{Wanting}} || {{Wanting}} || {{Wanting}} || {{Weak}}
|-
| matthewjablack || Atomic Finance || {{Prefer}} || {{Acceptable}} || {{Weak}} || {{Acceptable}} || {{Wanting}} || {{Evaluating}} || {{Acceptable}} || {{Wanting}} || {{Weak}}
|-
| reardencode || LNHANCE || {{Prefer}} || {{Prefer}} || {{Acceptable}} || {{Prefer}} || {{Wanting}} || {{Wanting}} || {{Wanting}} || {{Deficient}} || {{No}}
|-
| benthecarman || Taproot Wizards || {{Prefer}} || {{Prefer}} || {{Acceptable}} || {{Prefer}} || {{Prefer}} || {{Wanting}} || {{Wanting}} || {{Wanting}} || {{Weak}}
|-
| instagibbs || Spiral || {{Weak}} || {{Wanting}} || {{No}} || {{Wanting}} || {{Wanting}} || {{Evaluating}} || {{Wanting}} || {{Wanting}} || {{Weak}}
|-
| anon nonane dev || Bitcoin/LN || {{No}} || {{Evaluating}} || {{Evaluating}} || {{No}} || {{No}} || {{Evaluating}} || {{Evaluating}} || {{Evaluating}} || {{Evaluating}}
|-
| jaybny || Sidepit|| {{Prefer}} || {{Evaluating}} || {{Evaluating}} || {{Evaluating}} || {{Weak}} || {{Evaluating}} || {{Evaluating}} || {{Evaluating}} || {{Acceptable}}
|-
| cryptoquick || Surmount Systems || {{Acceptable}} || {{Prefer}} || {{Evaluating}} || {{Prefer}} || {{Acceptable}} || {{Evaluating}} || {{Acceptable}} || {{Prefer}} || {{No}}
|}

Covenants support

2024-12-05T11:45:41Z

Theymos: Merge edit by CryptoQuick

<big><big>This list is incomplete and under construction.</big></big>

{| class="wikitable"
| {{Evaluating}} || Not sure. Still evaluating the idea
|-
| {{No}} || Doesn't support (but might or might not go along with it with sufficient community support)
|-
| {{Deficient}} || Okay with the idea, but considers it to have insufficient community support
|-
| {{Weak}} || Better than nothing at all
|-
| {{Wanting}} || Positively likes the idea, but considers it to have insufficient community support
|-
| {{Acceptable}} || It is a workable solution
|-
| {{Prefer}} || The best option all things considered
|}

__TOC__

==Developers==

{| class="wikitable sortable"
! Developer
! Affiliation
! colspan="4" | LNHANCE
! OP_CAT
! OP_CCV
! OP_VAULT
! OP_TXHASH
! SIGHASH_APO
|-
!
!
! OP_CTV
! OP_CSFS
! OP_PAIRCOMMIT
! OP_INTERNALKEY
!
!
!
!
!
|-
| 1440000bytes || joinstr || {{Prefer}} || {{Acceptable}} || {{No}} || {{Acceptable}} || {{Deficient}} || {{Evaluating}}|| {{Acceptable}} || {{No}} || {{No}}
|-
| Jon Atack || Bitcoin Core || {{Acceptable}} || {{Evaluating}} || {{Evaluating}} || {{Evaluating}} || {{Evaluating}} || {{Evaluating}} || {{Evaluating}} || {{Evaluating}} || {{Evaluating}}
|-
| Luke Dashjr || Bitcoin Knots || {{Acceptable}} || {{Wanting}} || {{Evaluating}} || {{No}} || {{Deficient}} || {{Evaluating}} || {{Evaluating}} || {{Evaluating}} || {{Acceptable}}
|-
| moonsettler || LNhance || {{Prefer}} || {{Prefer}} || {{Prefer}} || {{Prefer}} || {{Wanting}} || {{Wanting}} || {{Wanting}} || {{Wanting}} || {{Weak}}
|-
| matthewjablack || Atomic Finance || {{Prefer}} || {{Acceptable}} || {{Weak}} || {{Acceptable}} || {{Wanting}} || {{Evaluating}} || {{Acceptable}} || {{Weak}} || {{Weak}}
|-
| reardencode || LNHANCE || {{Prefer}} || {{Prefer}} || {{Acceptable}} || {{Prefer}} || {{Wanting}} || {{Wanting}} || {{Wanting}} || {{Deficient}} || {{No}}
|-
| benthecarman || Taproot Wizards || {{Prefer}} || {{Prefer}} || {{Acceptable}} || {{Prefer}} || {{Prefer}} || {{Wanting}} || {{Wanting}} || {{Wanting}} || {{Weak}}
|-
| instagibbs || Spiral || {{Weak}} || {{Wanting}} || {{No}} || {{Wanting}} || {{Wanting}} || {{Evaluating}} || {{Wanting}} || {{Wanting}} || {{Weak}}
|-
| anon nonane dev || Bitcoin/LN || {{No}} || {{Evaluating}} || {{Evaluating}} || {{No}} || {{No}} || {{Evaluating}} || {{Evaluating}} || {{Evaluating}} || {{Evaluating}}
|-
| jaybny || Sidepit|| {{Prefer}} || {{Evaluating}} || {{Evaluating}} || {{Evaluating}} || {{Weak}} || {{Evaluating}} || {{Evaluating}} || {{Evaluating}} || {{Acceptable}}
|-
| cryptoquick || Surmount Systems || {{Acceptable}} || {{Prefer}} || {{Evaluating}} || {{Prefer}} || {{Acceptable}} || {{Evaluating}} || {{Acceptable}} || {{Prefer}} || {{No}}
|}

Covenants support

2024-12-05T11:44:27Z

Theymos: Merge edit by Jaybny

Script

2024-11-30T19:05:43Z

Theymos: Good catch, but the error was in the other direction

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.

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
# a public key that, when hashed, yields destination address D embedded in the script, and
# a signature to prove ownership of the private key corresponding to the public key just provided.

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.

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.

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.

The stacks hold byte vectors.
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.
Thus 0x81 represents -1.
0x80 is another representation of zero (so called negative 0).
Positive 0 is represented by a null-length vector.
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.

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

== Opcodes ==
This is a list of all Script words, also known as opcodes, commands, or functions.

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.

New opcodes can be added by means of a carefully designed and executed [[softfork]] using OP_NOP1-OP_NOP10.

Zero, negative zero (using any number of bytes), and empty array are all treated as false. Anything else is treated as true.

=== Notation on this page ===

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. When writing scripts as human-readable opcodes, the push opcodes and the associated data are usually written as <code><data></code>. For example, a P2SH script would be written as <code>OP_HASH160 <data> OP_EQUAL</code>, where <code><data></code> in this context means the byte <code>0x14</code> followed by the 20 bytes of the data itself. You should also ensure that you use the appropriate push instruction if your data is very large. See the table below for details.

=== Constants ===
When talking about scripts, these value-pushing words are usually omitted.

{| class="wikitable"
|-
!Word
!Opcode
!Hex
!Input
!Output
!Description
|-
|OP_0, OP_FALSE
|0
|0x00
|Nothing.
|(empty value)
|An empty array of bytes is pushed onto the stack. (This is not a no-op: an item is added to the stack.)
|-
|N/A
|1-75
|0x01-0x4b
|(special)
|data
|The next ''opcode'' bytes is data to be pushed onto the stack
|-
|OP_PUSHDATA1
|76
|0x4c
|(special)
|data
|The next byte contains the number of bytes to be pushed onto the stack.
|-
|OP_PUSHDATA2
|77
|0x4d
|(special)
|data
|The next two bytes contain the number of bytes to be pushed onto the stack in little endian order.
|-
|OP_PUSHDATA4
|78
|0x4e
|(special)
|data
|The next four bytes contain the number of bytes to be pushed onto the stack in little endian order.
|-
|OP_1NEGATE
|79
|0x4f
|Nothing.
| -1
|The number -1 is pushed onto the stack.
|-
|OP_1, OP_TRUE
|81
|0x51
|Nothing.
|1
|The number 1 is pushed onto the stack.
|-
|OP_2-OP_16
|82-96
|0x52-0x60
|Nothing.
|2-16
|The number in the word name (2-16) is pushed onto the stack.
|}

=== Flow control ===

{| class="wikitable"
|-
!Word
!Opcode
!Hex
!Input
!Output
!Description
|-
|OP_NOP
|97
|0x61
|Nothing
|Nothing
|Does nothing.
|-
|OP_IF
|99
|0x63
| colspan="2"|<expression> if [statements] [else [statements]]* endif
|If the top stack value is not False, the statements are executed. The top stack value is removed.
|-
|OP_NOTIF
|100
|0x64
| colspan="2"|<expression> notif [statements] [else [statements]]* endif
|If the top stack value is False, the statements are executed. The top stack value is removed.
|-
|OP_ELSE
|103
|0x67
| colspan="2"|<expression> if [statements] [else [statements]]* endif
|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.
|-
|OP_ENDIF
|104
|0x68
| colspan="2"|<expression> if [statements] [else [statements]]* endif
|Ends an if/else block. All blocks must end, or the transaction is '''invalid'''. An OP_ENDIF without OP_IF earlier is also '''invalid'''.
|-
|OP_VERIFY
|105
|0x69
|True / false
|Nothing / ''fail''
|'''Marks transaction as invalid''' if top stack value is not true. The top stack value is removed.
|-
|[[OP_RETURN]]
|106
|0x6a
|Nothing
|''fail''
|'''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.
|}

=== Stack ===

{| class="wikitable"
|-
!Word
!Opcode
!Hex
!Input
!Output
!Description
|-
|OP_TOALTSTACK
|107
|0x6b
|x1
|(alt)x1
|Puts the input onto the top of the alt stack. Removes it from the main stack.
|-
|OP_FROMALTSTACK
|108
|0x6c
|(alt)x1
|x1
|Puts the input onto the top of the main stack. Removes it from the alt stack.
|-
|OP_IFDUP
|115
|0x73
|x
|x / x x
|If the top stack value is not 0, duplicate it.
|-
|OP_DEPTH
|116
|0x74
|Nothing
|<Stack size>
|Puts the number of stack items onto the stack.
|-
|OP_DROP
|117
|0x75
|x
|Nothing
|Removes the top stack item.
|-
|OP_DUP
|118
|0x76
|x
|x x
|Duplicates the top stack item.
|-
|OP_NIP
|119
|0x77
|x1 x2
|x2
|Removes the second-to-top stack item.
|-
|OP_OVER
|120
|0x78
|x1 x2
|x1 x2 x1
|Copies the second-to-top stack item to the top.
|-
|OP_PICK
|121
|0x79
|xn ... x2 x1 x0 <n>
|xn ... x2 x1 x0 xn
|The item ''n'' back in the stack is copied to the top.
|-
|OP_ROLL
|122
|0x7a
|xn ... x2 x1 x0 <n>
|... x2 x1 x0 xn
|The item ''n'' back in the stack is moved to the top.
|-
|OP_ROT
|123
|0x7b
|x1 x2 x3
|x2 x3 x1
|The 3rd item down the stack is moved to the top.
|-
|OP_SWAP
|124
|0x7c
|x1 x2
|x2 x1
|The top two items on the stack are swapped.
|-
|OP_TUCK
|125
|0x7d
|x1 x2
|x2 x1 x2
|The item at the top of the stack is copied and inserted before the second-to-top item.
|-
|OP_2DROP
|109
|0x6d
|x1 x2
|Nothing
|Removes the top two stack items.
|-
|OP_2DUP
|110
|0x6e
|x1 x2
|x1 x2 x1 x2
|Duplicates the top two stack items.
|-
|OP_3DUP
|111
|0x6f
|x1 x2 x3
|x1 x2 x3 x1 x2 x3
|Duplicates the top three stack items.
|-
|OP_2OVER
|112
|0x70
|x1 x2 x3 x4
|x1 x2 x3 x4 x1 x2
|Copies the pair of items two spaces back in the stack to the front.
|-
|OP_2ROT
|113
|0x71
|x1 x2 x3 x4 x5 x6
|x3 x4 x5 x6 x1 x2
|The fifth and sixth items back are moved to the top of the stack.
|-
|OP_2SWAP
|114
|0x72
|x1 x2 x3 x4
|x3 x4 x1 x2
|Swaps the top two pairs of items.
|}

=== Splice ===

If any opcode marked as disabled is present in a script, it must abort and fail.

{| class="wikitable"
|-
!Word
!Opcode
!Hex
!Input
!Output
!Description
|-
|OP_CAT
|126
|0x7e
|x1 x2
|out
|style="background:#D97171;"|Concatenates two strings. ''disabled.''
|-
|OP_SUBSTR
|127
|0x7f
|in begin size
|out
|style="background:#D97171;"|Returns a section of a string. ''disabled.''
|-
|OP_LEFT
|128
|0x80
|in size
|out
|style="background:#D97171;"|Keeps only characters left of the specified point in a string. ''disabled.''
|-
|OP_RIGHT
|129
|0x81
|in size
|out
|style="background:#D97171;"|Keeps only characters right of the specified point in a string. ''disabled.''
|-
|OP_SIZE
|130
|0x82
|in
|in size
|Pushes the string length of the top element of the stack (without popping it).
|}

=== Bitwise logic ===

If any opcode marked as disabled is present in a script, it must abort and fail.

{| class="wikitable"
|-
!Word
!Opcode
!Hex
!Input
!Output
!Description
|-
|OP_INVERT
|131
|0x83
|in
|out
|style="background:#D97171;"|Flips all of the bits in the input. ''disabled.''
|-
|OP_AND
|132
|0x84
|x1 x2
|out
|style="background:#D97171;"|Boolean ''and'' between each bit in the inputs. ''disabled.''
|-
|OP_OR
|133
|0x85
|x1 x2
|out
|style="background:#D97171;"|Boolean ''or'' between each bit in the inputs. ''disabled.''
|-
|OP_XOR
|134
|0x86
|x1 x2
|out
|style="background:#D97171;"|Boolean ''exclusive or'' between each bit in the inputs. ''disabled.''
|-
|OP_EQUAL
|135
|0x87
|x1 x2
|True / false
|Returns 1 if the inputs are exactly equal, 0 otherwise.
|-
|OP_EQUALVERIFY
|136
|0x88
|x1 x2
|Nothing / ''fail''
|Same as OP_EQUAL, but runs OP_VERIFY afterward.
|}

=== Arithmetic ===

Note: Arithmetic inputs are limited to signed 32-bit integers, but may overflow their output.

If any input value for any of these commands is longer than 4 bytes, the script must abort and fail.
If any opcode marked as ''disabled'' is present in a script - it must also abort and fail.

{| class="wikitable"
|-
!Word
!Opcode
!Hex
!Input
!Output
!Description
|-
|OP_1ADD
|139
|0x8b
|in
|out
|1 is added to the input.
|-
|OP_1SUB
|140
|0x8c
|in
|out
|1 is subtracted from the input.
|-
|OP_2MUL
|141
|0x8d
|in
|out
|style="background:#D97171;"|The input is multiplied by 2. ''disabled.''
|-
|OP_2DIV
|142
|0x8e
|in
|out
|style="background:#D97171;"|The input is divided by 2. ''disabled.''
|-
|OP_NEGATE
|143
|0x8f
|in
|out
|The sign of the input is flipped.
|-
|OP_ABS
|144
|0x90
|in
|out
|The input is made positive.
|-
|OP_NOT
|145
|0x91
|in
|out
|If the input is 0 or 1, it is flipped. Otherwise the output will be 0.
|-
|OP_0NOTEQUAL
|146
|0x92
|in
|out
|Returns 0 if the input is 0. 1 otherwise.
|-
|OP_ADD
|147
|0x93
|a b
|out
|a is added to b.
|-
|OP_SUB
|148
|0x94
|a b
|out
|b is subtracted from a.
|-
|OP_MUL
|149
|0x95
|a b
|out
|style="background:#D97171;"|a is multiplied by b. ''disabled.''
|-
|OP_DIV
|150
|0x96
|a b
|out
|style="background:#D97171;"|a is divided by b. ''disabled.''
|-
|OP_MOD
|151
|0x97
|a b
|out
|style="background:#D97171;"|Returns the remainder after dividing a by b. ''disabled.''
|-
|OP_LSHIFT
|152
|0x98
|a b
|out
|style="background:#D97171;"|Shifts a left b bits, preserving sign. ''disabled.''
|-
|OP_RSHIFT
|153
|0x99
|a b
|out
|style="background:#D97171;"|Shifts a right b bits, preserving sign. ''disabled.''
|-
|OP_BOOLAND
|154
|0x9a
|a b
|out
|If both a and b are not 0, the output is 1. Otherwise 0.
|-
|OP_BOOLOR
|155
|0x9b
|a b
|out
|If a or b is not 0, the output is 1. Otherwise 0.
|-
|OP_NUMEQUAL
|156
|0x9c
|a b
|out
|Returns 1 if the numbers are equal, 0 otherwise.
|-
|OP_NUMEQUALVERIFY
|157
|0x9d
|a b
|Nothing / ''fail''
|Same as OP_NUMEQUAL, but runs OP_VERIFY afterward.
|-
|OP_NUMNOTEQUAL
|158
|0x9e
|a b
|out
|Returns 1 if the numbers are not equal, 0 otherwise.
|-
|OP_LESSTHAN
|159
|0x9f
|a b
|out
|Returns 1 if a is less than b, 0 otherwise.
|-
|OP_GREATERTHAN
|160
|0xa0
|a b
|out
|Returns 1 if a is greater than b, 0 otherwise.
|-
|OP_LESSTHANOREQUAL
|161
|0xa1
|a b
|out
|Returns 1 if a is less than or equal to b, 0 otherwise.
|-
|OP_GREATERTHANOREQUAL
|162
|0xa2
|a b
|out
|Returns 1 if a is greater than or equal to b, 0 otherwise.
|-
|OP_MIN
|163
|0xa3
|a b
|out
|Returns the smaller of a and b.
|-
|OP_MAX
|164
|0xa4
|a b
|out
|Returns the larger of a and b.
|-
|OP_WITHIN
|165
|0xa5
|x min max
|out
|Returns 1 if x is within the specified range (left-inclusive), 0 otherwise.
|}

=== Crypto ===

{| class="wikitable"
|-
!Word
!Opcode
!Hex
!Input
!Output
!Description
|-
|OP_RIPEMD160
|166
|0xa6
|in
|hash
|The input is hashed using RIPEMD-160.
|-
|OP_SHA1
|167
|0xa7
|in
|hash
|The input is hashed using SHA-1.
|-
|OP_SHA256
|168
|0xa8
|in
|hash
|The input is hashed using SHA-256.
|-
|OP_HASH160
|169
|0xa9
|in
|hash
|The input is hashed twice: first with SHA-256 and then with RIPEMD-160.
|-
|OP_HASH256
|170
|0xaa
|in
|hash
|The input is hashed two times with SHA-256.
|-
|OP_CODESEPARATOR
|171
|0xab
|Nothing
|Nothing
|All of the signature checking words will only match signatures to the data after the most recently-executed OP_CODESEPARATOR.
|-
|[[OP_CHECKSIG]]
|172
|0xac
|sig pubkey
|True / false
|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.
|-
|OP_CHECKSIGVERIFY
|173
|0xad
|sig pubkey
|Nothing / ''fail''
|Same as OP_CHECKSIG, but OP_VERIFY is executed afterward.
|-
|OP_CHECKMULTISIG
|174
|0xae
|x sig1 sig2 ... <number of signatures> pub1 pub2 <number of public keys>
|True / False
|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.
|-
|OP_CHECKMULTISIGVERIFY
|175
|0xaf
|x sig1 sig2 ... <number of signatures> pub1 pub2 ... <number of public keys>
|Nothing / ''fail''
|Same as OP_CHECKMULTISIG, but OP_VERIFY is executed afterward.
|-
|OP_CHECKSIGADD
|186
|0xba
|sig n pub
|out
|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>
|}

=== Locktime ===
{| class="wikitable"
|-
!Word
!Opcode
!Hex
!Input
!Output
!Description
|-
|OP_CHECKLOCKTIMEVERIFY (previously OP_NOP2)
|177
|0xb1
|x
|x / ''fail''
|'''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].
|-
|OP_CHECKSEQUENCEVERIFY (previously OP_NOP3)
|178
|0xb2
|x
|x / ''fail''
|'''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].
|}

=== Reserved words ===
Any opcode not assigned is also reserved. Using an unassigned opcode makes the transaction '''invalid'''.

{| class="wikitable"
|-
!Word
!Opcode
!Hex
!When used...
|-
|OP_RESERVED
|80
|0x50
|'''Transaction is invalid''' unless occuring in an unexecuted OP_IF branch
|-
|OP_VER
|98
|0x62
|'''Transaction is invalid''' unless occuring in an unexecuted OP_IF branch
|-
|OP_VERIF
|101
|0x65
|'''Transaction is invalid even when occuring in an unexecuted OP_IF branch'''
|-
|OP_VERNOTIF
|102
|0x66
|'''Transaction is invalid even when occuring in an unexecuted OP_IF branch'''
|-
|OP_RESERVED1
|137
|0x89
|'''Transaction is invalid''' unless occuring in an unexecuted OP_IF branch
|-
|OP_RESERVED2
|138
|0x8a
|'''Transaction is invalid''' unless occuring in an unexecuted OP_IF branch
|-
|OP_NOP1, OP_NOP4-OP_NOP10
|176, 179-185
|0xb0, 0xb3-0xb9
|The word is ignored. Does not mark transaction as invalid.
|}

== Script examples ==
The following is a list of interesting scripts.
When notating scripts, data to be pushed to the stack is generally enclosed in angle brackets
and data push commands are omitted.
Non-bracketed words are opcodes.
These examples include the “OP_” prefix, but it is permissible to omit it.
Thus
“<pubkey1> <pubkey2> OP_2 OP_CHECKMULTISIG”
may be abbreviated to
“<pubkey1> <pubkey2> 2 CHECKMULTISIG”.
Note that there is a small number of standard script forms that are relayed from node to node;
non-standard scripts are accepted if they are in a block, but nodes will not relay them.

=== Standard Transaction to Bitcoin address (pay-to-pubkey-hash) ===

scriptPubKey: OP_DUP OP_HASH160 <pubKeyHash> OP_EQUALVERIFY OP_CHECKSIG
scriptSig: <sig> <pubKey>

To demonstrate how scripts look on the wire, here is a raw scriptPubKey:
<pre> 76 A9 14
OP_DUP OP_HASH160 Bytes to push

89 AB CD EF AB BA AB BA AB BA AB BA AB BA AB BA AB BA AB BA 88 AC
Data to push OP_EQUALVERIFY OP_CHECKSIG</pre>

Note: scriptSig is in the input of the spending transaction and scriptPubKey is in the output of the previously unspent i.e. "available" transaction.

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

=== Obsolete pay-to-pubkey transaction ===

OP_CHECKSIG is used directly without first hashing the public key.
This was used by early versions of Bitcoin where people paid directly to IP addresses, before Bitcoin addresses were introduced.
scriptPubKeys of this transaction form are still recognized as payments to user by Bitcoin Core.
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.

scriptPubKey: <pubKey> OP_CHECKSIG
scriptSig: <sig>

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

=== Provably Unspendable/Prunable Outputs ===

The standard way to mark a transaction as provably unspendable is with a scriptPubKey of the following form:

scriptPubKey: OP_RETURN {zero or more ops}

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.

=== Freezing funds until a time in the future ===

Using OP_CHECKLOCKTIMEVERIFY it is possible to make funds provably unspendable until a certain point in the future.

scriptPubKey: <expiry time> OP_CHECKLOCKTIMEVERIFY OP_DROP OP_DUP OP_HASH160 <pubKeyHash> OP_EQUALVERIFY OP_CHECKSIG
scriptSig: <sig> <pubKey>

{| class="wikitable"
|-
! Stack
! Script
! Description
|-
|Empty.
| <sig> <pubKey> <expiry time> OP_CHECKLOCKTIMEVERIFY OP_DROP OP_DUP OP_HASH160 <pubKeyHash> OP_EQUALVERIFY OP_CHECKSIG
| scriptSig and scriptPubKey are combined.
|-
|<sig> <pubKey> <expiry time>
| OP_CHECKLOCKTIMEVERIFY OP_DROP OP_DUP OP_HASH160 <pubKeyHash> OP_EQUALVERIFY OP_CHECKSIG
| Constants are added to the stack.
|-
|<sig> <pubKey> <expiry time>
| OP_DROP OP_DUP OP_HASH160 <pubKeyHash> OP_EQUALVERIFY OP_CHECKSIG
| Top stack item is checked against the current time or block height.
|-
|<sig> <pubKey>
| OP_DUP OP_HASH160 <pubKeyHash> OP_EQUALVERIFY OP_CHECKSIG
| Top stack item is removed.
|-
|<sig> <pubKey> <pubKey>
| OP_HASH160 <pubKeyHash> OP_EQUALVERIFY OP_CHECKSIG
| Top stack item is duplicated.
|-
|<sig> <pubKey> <pubHashA>
|<pubKeyHash> OP_EQUALVERIFY OP_CHECKSIG
| Top stack item is hashed.
|-
|<sig> <pubKey> <pubHashA> <pubKeyHash>
|OP_EQUALVERIFY OP_CHECKSIG
| Constant added.
|-
|<sig> <pubKey>
|OP_CHECKSIG
| Equality is checked between the top two stack items.
|-
|true
|Empty.
|Signature is checked for top two stack items.
|}

=== Transaction puzzle ===

Transaction a4bfa8ab6435ae5f25dae9d89e4eb67dfa94283ca751f393c1ddc5a837bbc31b is an interesting puzzle.

scriptPubKey: OP_HASH256 6fe28c0ab6f1b372c1a6a246ae63f74f931e8365e15a089c68d6190000000000 OP_EQUAL
scriptSig: <data>

To spend the transaction you need to come up with some data such that hashing the data twice results in the given hash.

{| class="wikitable"
|-
! Stack
! Script
! Description
|-
|Empty.
|<data> OP_HASH256 <given_hash> OP_EQUAL
|
|-
|<data>
|OP_HASH256 <given_hash> OP_EQUAL
|scriptSig added to the stack.
|-
|<data_hash>
|<given_hash> OP_EQUAL
|The data is hashed.
|-
|<data_hash> <given_hash>
|OP_EQUAL
|The given hash is pushed to the stack.
|-
|true
|Empty.
|The hashes are compared, leaving true on the stack.
|}

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.

=== Incentivized finding of hash collisions ===

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.

For example the SHA1 script:

scriptPubKey: OP_2DUP OP_EQUAL OP_NOT OP_VERIFY OP_SHA1 OP_SWAP OP_SHA1 OP_EQUAL
scriptSig: <preimage1> <preimage2>

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.

In February 2017 the SHA1 bounty worth 2.48 bitcoins was claimed.

==See Also==

* [[Transactions]]
* [[Contracts]]

== External Links ==
*[https://bitide.qedprotocol.com/ BitIDE] - BitIDE: A web based Bitcoin Script IDE with built in debugger, meta-scripting, virtual op-codes, and local testnet.
*[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.
*[https://github.com/siminchen/bitcoinIDE Bitcoin IDE] – Bitcoin Script for dummies
*[http://www.crmarsh.com/script-playground/ Script Playground] — convert Script to JavaScript
*[https://bitauth.com/ide BitAuth IDE] — an Integrated Development Environment for Bitcoin Authentication
(cf. "[http://bitcoin.stackexchange.com/q/42576/4334 Online Bitcoin Script simulator or debugger?]")

==References==
<references />

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

{{Bitcoin Core documentation}}

User talk:Flix

2024-10-10T17:30:57Z

Theymos: /* Chart */ new section

Not complaining about your [[Bitcoin Ladder]] idea, but I'm not sure it should be linked from every listed service's article... Is there a reason behind that? --[[User:Luke-jr|Luke-jr]] ([[User talk:Luke-jr|talk]]) 22:43, 17 January 2013 (GMT)

I agree, linking to it from /every single service page/ is a bit much. --[[User:Nanotube|Nanotube]] ([[User talk:Nanotube|talk]]) 22:57, 17 January 2013 (GMT)

Ok. Agree. 18 links maybe too many. I'll remove some. --[[User:Flix|Flix]] ([[User talk:Flix|talk]]) 23:29, 17 January 2013 (GMT)

: Sounds good. I might suggest to link it from other listings-style pages (like 'trade', 'businesses and organizations', and such), rather than from individual service provider pages. That'd be quite sensible. --[[User:Nanotube|Nanotube]] ([[User talk:Nanotube|talk]]) 02:05, 18 January 2013 (GMT)

Done. Removed half the links. --[[User:Flix|Flix]] ([[User talk:Flix|talk]]) 09:26, 18 January 2013 (GMT)

== Chart ==

The chart you uploaded is highly speculative. It's the sort of thing that a scamcoin-pumper would post, and it's not appropriate for this wiki, which is supposed to be fairly neutral and professional. [[User:Theymos|theymos]] ([[User talk:Theymos|talk]]) 17:30, 10 October 2024 (UTC)

Category:History

2024-10-10T17:29:54Z

Theymos: Reverted edit by Flix (talk) to last revision by NotATether

{{outdated}}
Two fantastic compilations of Bitcoin history are available at the [http://historyofbitcoin.org HistoryOfBitcoin.org] and [http://igotbitcoin.com/milestones igotbitcoin.com/milestones] sites.

== Some historical events related to digital currencies predating the Bitcoin project ==
=== 1913 ===
{| style="text-align: left"
|-
! width="8em" | December 23
|| The Federal Reserve Act<ref>The [https://en.wikipedia.org/wiki/Federal_Reserve_Act Federal Reserve Act]</ref>
|}
=== 1933 ===
{| style="text-align: left"
|-
! width="8em" | April 5
|| Executive Order 6102<ref>[https://en.wikipedia.org/wiki/Executive_Order_6102 Executive Order 6102]</ref>, "Confiscation of gold", signed. Later, the United States went off the gold standard. Reversed in 1974.
|}
=== 1936 ===
{| style="text-align: left"
|-
! width="8em" | Feburary
|| Keynesian economic theory<ref>[https://en.wikipedia.org/wiki/The_General_Theory_of_Employment,_Interest_and_Money The General Theory] is a book written by Kaynes that was a milestone in [https://en.wikipedia.org/wiki/Keynesian_economics macroeconomic theory.]</ref> developed
|}
=== 1976 ===
{| style="text-align: left"
|-
! width="8em" |
|| Diffie and Hellman discover asymmetric public key cryptography<ref>[https://en.wikipedia.org/wiki/Diffie%E2%80%93Hellman_key_exchange Diffie-Hellman key exchange]</ref>.
|}
=== 1983 ===
{| style="text-align: left"
|-
! width="8em" |
|| David Chaum develops idea of e-cash<ref>[http://blog.koehntopp.de/uploads/chaum_fiat_naor_ecash.pdf Untraceable electronic cash]</ref>.
|}
=== 1992 ===
{| style="text-align: left"
|-
! width="8em" |
|| Cypherpunk movement and mailing list<ref>[https://mailing-list-archive.cryptoanarchy.wiki/ Cypherpunk mailing list archives]</ref> started.
|}
=== 1993 ===
{| style="text-align: left"
|-
! width="8em" | January 17
|| Hal Finney predicts NFTs<ref>[https://mailing-list-archive.cryptoanarchy.wiki/archive/1993/01/ee44616c1d030cb0722be6e3e5ff9c16e6535f48514cbb881f09b27884275c14/ 1993-01-17 - Crypto trading cards.]</ref>.
|}
=== 1995 ===
{| style="text-align: left"
|-
! width="8em" |
|| David Chaum implements Digicash<ref>[https://www.forbes.com/forbes/1999/1101/6411390a.html Requiem for a Bright Idea
]</ref>.
|}
=== 1996 ===
{| style="text-align: left"
|-
! width="8em" | June 18
|| NSA publishes "Anonymous Electronic Cash"<ref>[https://groups.csail.mit.edu/mac/classes/6.805/articles/money/nsamint/nsamint.htm HOW TO MAKE A MINT: THE CRYPTOGRAPHY OF ANONYMOUS ELECTRONIC CASH]</ref>.
|}
=== 1997 ===
{| style="text-align: left"
|-
! width="8em" |
|| Tim May proposes crypto based on remailers<ref>[http://osaka.law.miami.edu/~froomkin/articles/tcmay.htm Untraceable Digital Cash, Information Markets, and BlackNet]</ref>.
|-
! width="8em" | May
|| Adam Back proposes HashCash<ref>[http://www.hashcash.org/papers/hashcash.pdf Hashcash - A Denial of Service Counter-Measure]</ref>. implemented in 2001.

|}
=== 1998 ===
{| style="text-align: left"
|-
! width="8em" | May
|| Wei Dei starts b-money<ref>http://www.weidai.com/bmoney.txt</ref>.
|}
=== 1999 ===
{| style="text-align: left"
|-
! width="8em" |
|| Liberty dollar starts<ref>[https://libertydollar.net/the-history-of-the-liberty-dollar/ The History of the Liberty Dollar]</ref>. Its office was raided in 2007[https://web.archive.org/web/20071118023934/https://reason.com/blog/show/123553.html Your Liberty Dollar Raid Update] and it shut down soon after.
|-
! width="8em" |
|| Milton Friedman predicts e-currencies<ref>[https://cointelegraph.com/news/nobel-laureate-milton-friedman-predicted-bitcoin-era-17-years-ago Nobel Laureate Milton Friedman Predicted Bitcoin Era 17 Years Ago - CoinTelegraph]</ref>.
|}
=== 2000 ===
{| style="text-align: left"
|-
! width="8em" | May
|| Paypal as we know it today is founded<ref>[https://en.wikipedia.org/wiki/Timeline_of_PayPal Timeline of PayPal - Wikipedia]</ref>.
|}
=== 2001 ===
{| style="text-align: left"
|-
! width="8em" |
|| Pecunix, an Panamaian e-currency based on gold reserves, is created<ref>[https://www.cato.org/sites/cato.org/files/serials/files/cato-journal/2014/5/cato-journal-v34n2-5.pdf The Troubling Suppression of Competition from Alternative Monies: The Cases of the Liberty Dollar and E-gold]</ref>.
|}
=== 2002 ===
{| style="text-align: left"
|-
! width="8em" |
|| John Nash publishes the paper "Ideal Money"<ref>https://www.jstor.org/stable/1061553</ref>.
|-
! width="8em" | Feburary 10
|| First mention of "The Digital Monetary Trust"<ref>[https://web.archive.org/web/20020210143425/http://orlingrabbe.com/dmt_guide.htm A Guide To the DMT System]</ref>.
|-
! width="8em" | December 9
|| "X" publishes on digital peer to peer currency in UK finance group<ref>[[X|"X"]] - Bitcoin Wiki</ref>.
|}

== Important milestones of the Bitcoin project ==
=== 2008 ===
{| style="text-align: left"
|-
! width="8em" | August 18
|| Domain name "bitcoin.org" registered<ref>[https://bitcointalk.org/index.php?topic=103369.msg1135218#msg1135218 According to theymos], Satoshi registered bitcoin.org via https://www.anonymousspeech.com/ which allows to anonymously register domains.</ref>.
|-
! October 31
|| [https://notatether.com/bitcoin.pdf Bitcoin whitepaper] published
|-
! November 09
|| Bitcoin project registered at SourceForge.net
|}

=== 2009 ===
{| style="text-align: left"
|-
! width="8em" | January 3
|| [http://www.BlockExplorer.com/b/0 Genesis block] established at 18:15:05 GMT
|-
! January 9
|| Bitcoin v0.1 released and announced on the [http://www.mail-archive.com/cryptography@metzdowd.com/msg10152.html cryptography mailing list]. Hal Finney tweets "Running bitcoin" the following day.<ref>[https://twitter.com/halfin/status/1110302988?lang=en]</ref>
|-
! January 12
|| First Bitcoin transaction, [http://www.BlockExplorer.com/b/170 in block 170] - from [[Satoshi]] to Hal Finney<ref>[http://bitcointalk.org/index.php?topic=91806.msg1012234#msg1012234 Earliest Block With A Spend]</ref>.
|-
! March 8
|| Bitcoin Wikipedia page created<ref>[https://en.wikipedia.org/w/index.php?title=Bitcoin&oldid=275832581]</ref>
|-
! May 8
|| Announcement of Bitcoin on Reddit<ref>[https://np.reddit.com/r/business/comments/8itlf/bitcoin_a_peertopeer_network_based_anonymous/ Bitcoin: A peer-to-peer network based anonymous digital currency. r/business]</ref>
|-
! October 5
|| Exchange rates [http://newlibertystandard.wikifoundry.com/page/2009+Exchange+Rate published] by New Liberty Standard. $1 = 1,309.03 BTC (and [[User:theymos|theymos]] thought NLS was overcharging<ref>[http://bitcointalk.org/index.php?topic=104287.msg1143955#msg1143955 Historical Price Data for 2009]</ref>)
|-
! October 9
|| #bitcoin-dev channel registered on freenode IRC.
|-
! December 16
|| Bitcoin v0.2 released
|-
! December 30
|| First difficulty increase at 06:11:04 GMT
|}

=== 2010 ===
{| style="text-align: left"
|-
! width="8em" | February 6
|| [[Bitcoin Market]] established
|-
! May 22
|| laszlo first to buy pizza with Bitcoins agreeing upon paying 10,000 BTC for ~$25 worth of pizza courtesy of jercos<ref>[https://bitcointalk.org/index.php?topic=137.msg1195#msg1195 bitcointalk post] where laszlo confirmed having bought pizza</ref>
|-
! July 7
|| Bitcoin v0.3 released
|-
! July 11
|| Bitcoin v0.3 release mentioned on slashdot<ref>[http://news.slashdot.org/story/10/07/11/1747245/Bitcoin-Releases-Version-03 slashdot] metiones Bitcoin</ref>, bringing a large influx of new bitcoin users.
|-
! July 12
|| Beginning of a 10x increase in exchange value over a 5 day period, from about $0.008/BTC to $0.08/BTC
|-
! July 17
|| [[MtGox]] established
|-
! July 18
|| ArtForz generated his first block after establishing his personal OpenCL GPU hash farm
|-
! August 15
|| Bug in the bitcoin code allows a bad transaction into block 74638. Users quickly adopt fixed code and the "good" block chain overtook the bad one at a block height of 74691, 53 blocks later ([[Incidents#Value_overflow]]).
|-
! September 14
|| jgarzik [https://bitcointalk.org/index.php?topic=133.msg12921#msg12921 offered] 10,000 BTC (valued at ~$600-650) to puddinpop to open source their windows-based CUDA client
|-
! September 14
|| Block [http://blockexplorer.com/b/79764 79,764] is first to be mined using split allocation of the generation reward.
|-
! September 18
|| puddinpop [https://bitcointalk.org/index.php?topic=133.msg13135#msg13135 released] source to their windows-based CUDA client under MIT license
|-
! September 29
|| kermit [https://bitcointalk.org/index.php?topic=1306.0 discovered] a microtransactions exploit which precipitated the Bitcoin v0.3.13 release
|-
! October 01
|| [https://bitcointalk.org/?topic=1334.0 First public OpenCL miner] released
|-
! October 04
|| Original Bitcoin History wiki page (this page) established (ooh so meta) on Bitcoin.org's wiki.
|-
! October 07
|| Exchange rate started climbing up from $0.06/BTC after several flat months.
|-
! October 16
|| First recorded escrowed bitcoin trade conducted, between nanotube and Diablo-D3, escrowed by theymos.
|-
! October 17
|| [[Bitcoin_OTC|#bitcoin-otc]] trading channel established on freenode IRC.
|-
! October 28
|| First bitcoin short sale transaction initiated, with a loan of 100 BTC by nanotube to [[User:Kiba|kiba]], facilitated by the [[Bitcoin-otc|#bitcoin-otc]] market.
|-
! November 6
|| The [https://bitcointalk.org/index.php?topic=1672 Bitcoin economy passed US $1 million]. The MtGox price touched USD $0.50/BTC.
|-
! December 7
|| Bitcoind was compiled for the Nokia N900 mobile computer by doublec. The following day, ribuck sent him 0.42 BTC in the first portable-to-portable Bitcoin transaction.
|-
! December 9
|| The generation difficulty passed 10,000.
|-
|
|| First bitcoin call option contract sold, from nanotube to [[User:Sgornick|sgornick]], via the [[Bitcoin-otc|#bitcoin-otc]] market.
|-
! December 16
|| [http://mining.bitcoin.cz/ Bitcoin Pooled Mining], operated by slush, found its first block
|}

=== 2011 ===
{| style="text-align: left"
|-
! width="8em" | January 2
|| [[Tonal Bitcoin]] units standardized.
|-
! January 8
|| [[History of Bitcoin]] page (this page) created after replicating from original Bitcoin History page on Bitcoin.org.
|-
|
|| Bitcoin Pooled Mining reached a total of 10,000 Mhash/s
|-
! January 27
|| Largest numeric value ever traded for bitcoins thus far occurred on this date. Three currency bills from Zimbabwe, known as Zimdollars, were traded on [[Bitcoin-otc|#bitcoin-otc]] at the rate of 4 BTC for each of the one-hundred trillion dollar ($100,000,000,000,000) Zimbabwe notes<ref>Serial numbers for Zimdollars sold: AA1669317, AA1669318 and AA1669319</ref>
|-
! January 28
|| Block 105000 was generated. This means that 5.25 million bitcoins have been generated, which is just over one-quarter of the eventual total of nearly 21 million.
|-
! February 9
|| Bitcoin reached parity with the US dollar, touching $1 per BTC at [[MtGox]].
|-
! February 10
|| Bitcoin.org website struggles to handle [https://bitcointalk.org/index.php?topic=3444.0 traffic] resulting from mentions on Slashdot<ref>[http://news.slashdot.org/story/11/02/10/189246/Online-Only-Currency-BitCoin-Reaches-Dollar-Parity Online-Only Currency BitCoin Reaches Dollar Parity]</ref>, Hacker News and Twitter following the news that parity had been reached.
|-
! February 14
|| A vehicle was, for the first time, offered in exchange for a certain number of bitcoins<ref>[https://bitcointalk.org/index.php?topic=3485.0 Car for Sale - Australia]</ref>.
|-
! March 1
|| [[MagicalTux]] buys mtgox.com from its founder [[Jed McCaleb]]
|-
! March 6
|| Total Bitcoin network computation speed for a short time reached a new high of almost 900Ghash/sec, dropping to 500Ghash/sec soon after. Some speculate that this was due to some supercomputer or bot-net that joined the network ([http://bitcoin.atspace.com/mysteryminer.html mystery miner]).
|-
! March 18
|| BTC/USD exchange rate reaches a 6-week low point at almost $0.70/BTC, after what appeared to be a short burst of, possibly automated, BTC sales at progressively lower prices. BTC price had been declining since the February 9 high.
|-
! March 22
|| [https://www.weusecoins.com/ WeUseCoins] releases the viral video [https://www.youtube.com/watch?v=Um63OQz3bjo What Is Bitcoin?] which has had more than 6.4 million views.
|-
! March 25
|| Difficulty decreased nearly 10%. A decrease has only occurred once before, and this decrease of nearly 10% was the largest.
|-
! March 27
|| The first market for exchanging bitcoins to and from the British Pound Sterling BTC/GBP, [[Britcoin]], opens.
|-
! March 31
|| The first market for exchanging bitcoins to and from Brazilian Reals, [[Bitcoin Brazil]], opens.
|-
! April 5
|| The first market for exchanging bitcoins to and from the Polish złoty, [[BitMarket.eu]], opens.
|-
! April 12
|| First bitcoin put option contract sold via the [[Bitcoin-otc|#bitcoin-otc]] market.
|-
! April 16
|| TIME does [http://techland.time.com/2011/04/16/online-cash-bitcoin-could-challenge-governments/ an article on Bitcoin].
|-
! April 23
|| BTC/USD exchange rate reaches and passes parity with the Euro (EUR) on [[MtGox]] exchange.
|-
|
|| BTC/USD exchange rate reaches and passes parity with the British Sterling Pound (GBP) on [[MtGox]] exchange.
|-
|
|| Value of the Bitcoin money stock at current exchange rate passes $10 million USD threshold.
|-
! April 27
|| [[VirWoX]] opens first market to trade bitcoins against a virtual currency on BTC/SL (Second Life Lindens) exchange.
|-
! April 30
|| The generation difficulty passed 100,000.
|-
! June 2
|| The exchange rate at [[MtGox]] touched 10 USD per BTC.
|-
! June 3
|| [[Tonal Bitcoin]] reached parity with the US cent, touching 1¢ per TBC at [[Bitcoin Market]].
|-
! June 8
|| The [[MtGox]] exchange rate peaked at 31.91 USD, at a "market capitalization" of about $206 M [http://bitcoin.stackexchange.com/questions/2047/market-capitalization-over-time].
|-
! June 12
|| The [[MtGox]] exchange rate briefly dropped to near 10 USD four days after the peak, in its largest percentage price retreat to date.
|-
! June 13
|| Forum user allinvain claimed to have had [http://forum.bitcoin.org/index.php?topic=16457.0 25,000 BTC stolen] from his Bitcoin wallet (approx. USD equivalent $375,000).
|-
! June 19
|| The MtGox database was compromised and the user table was leaked, containing details of 60,000 usernames, email addresses and password hashes, some of which were overly simple to brute force passwords.
|-
! June 19
|| Someone was able to access an admin account at MtGox and issue sell orders for hundreds of thousands of fake bitcoins, forcing the MtGox price down from $17.51 per bitcoin to $0.01. MtGox announced that these trades would be reversed. Trading was halted at MtGox for 7 days (and also briefly at TradeHill and Britcoin while their security was reviewed).
|-
! June 19
|| Some of the users on the leaked MtGox database had used the same username at MyBitcoin and had their passwords hacked. About 600 of them had their balance [http://forum.bitcoin.org/index.php?topic=22221.msg279396#msg279396 stolen from their MyBitcoin accounts]. One user lost over 2000 BTC.
|-
! June 20
|| The EFF announced that it was no longer accepting Bitcoin donations due to legal uncertainties.
|-
! June 24
|| The generation difficulty passed 1,000,000 with Block [http://blockexplorer.com/b/133056 133056].
|-
! July 19
|| "Let it go on record that at 4:05pm CET [19 July 2011], my manager Tadek was the first person in the world to receive [testnet] Bitcoins via NFC ;)" - Mike Hearn
|-
! July 22
|| [[BitCoins Mobile]], the first Bitcoin application for iPad was released by [http://www.intervex.net Intervex Digital].
|-
! July 26
|| [http://www.room77.de/ Room77] [https://bitcointalk.org/index.php?topic=32162.0 becomes] the first brick-and-mortar business (bar) to accept Bitcoin as a means of payment.
|-
! July 30
|| [http://pastebin.com/raw.php?i=BUB3dygQ Tribute to Len Sassaman] included in the blockchain<ref>[http://bitcointalk.org/index.php?topic=33618.msg420597#msg420597 A Tribute to Len "rabbi" Sassama]</ref>.
|-
! August 20
|| First Bitcoin Conference and World Expo held, in NYC.<ref>[http://bitcoinme.com/index.php/conference/ New York Conference 2011]</ref>
|-
! August 23
|| [[P2Pool]], the first P2P decentralized pool, mines its first Bitcoin mainnet block (Block [http://blockexplorer.com/b/142312 142,312]).
|-
! August 30
|| Difficulty adjustment at block [http://blockexplorer.com/b/143136 143,136] marks the first back-to-back drop.
|-
! November 15
|| First CVE (CVE-2011-4447) assigned to a Bitcoin client exploit.
|-
! November 25
|| First European Bitcoin Conference in Prague, Czech Rep.<ref>[http://bitgroups.org/ Prague Conference 2011]</ref>
|-
! December 12
|| Largest amount of fees, to-date, in a single transaction, and most fees in a single block. A [http://blockexplorer.com/tx/1d7749c65c90c32f5e2c036217a2574f3f4403da39174626b246eefa620b58d9 transaction] paid 171 BTC in fees in [http://blockexplorer.com/b/157235 block 157235]<ref>[http://bitcointalk.org/index.php?topic=88423.msg973509#msg973509 Largest fee ever?]</ref>.
|}

=== 2012 ===
{| style="text-align: left"
|-
! width="8em" | March 1
|| Largest theft of bitcoins to-date occurred (near 50K BTC) after security breach at web host Linode.
|-
! width="8em" | April 1
|| Pay-to-script-hash ([[P2SH]]) as defined through [[BIP 0016]] goes live.
|-
! May 08
|| A single service, [[Satoshi Dice]] becomes responsible for over half the transaction volume on the Bitcoin blockchain.
|-
! June 3
|| Largest block (most transactions), to-date (June 3), is [http://BlockExplorer.com/b/181919 block 181919] with 1322 transactions<ref>[http://bitcointalk.org/index.php?topic=85353.msg939859#msg939859 Largest block to date]</ref>.
|-
! July 22
|| One millionth topic reply was posted on the unofficial [[Bitcoin Forum]] <ref>[https://bitcointalk.org/index.php?topic=94608.0 Topic about one millionth forum post]</ref>.
|-
! September 15-16
|| Bitcoin Conference in London <ref>[http://bitcoin2012.com/ London Conference 2012]</ref>.
|-
! September 27
|| Formation of the [[Bitcoin Foundation]].
|-
! November 28
|| Halving day. [http://blockexplorer.com/b/210000 Block 210,000] is the first with a block reward subsidy of only 25 BTC.
|-
! December 6
|| First Bitcoin exchange [https://bitcointalk.org/index.php?topic=129461.0 licensed "as a bank" in europe] (actually a PSP which is like a bank, without debt-money issuing).
|}

=== 2013 ===
{| style="text-align: left"
|-
! width="8em" | February 19
|| Bitcoin Client v0.8 released featuring improved download speed and [https://en.wikipedia.org/wiki/Bloom_filter Bloom Filtering]
|-
! February 28
|| The [[MtGox]] exchange rate broke the June 8 2011 peak of 31.91 USD. The first all time high since 601 days
|-
! March 12
|| A previously undiscovered protocol rule results in a [http://bitcoin.org/chainfork.html hard fork of the 0.8.0 reference client].
|-
! March 18
|| The United States federal agency charged with enforcing laws against money laundering (FinCEN) declares that Bitcoin users are subject to regulation only at the point of USD-BTC exchange.<ref>[http://arstechnica.com/tech-policy/2013/03/us-regulator-bitcoin-exchanges-must-comply-with-money-laundering-laws/ US regulator: Bitcoin exchanges must comply with money-laundering laws]</ref>
|-
! March 28
|| Total Bitcoin market cap passes $1 billion. <ref>http://spectrum.ieee.org/computing/networks/bitcoin-hits-1billion</ref>
|-
! April 1
|| Bitcoin price breaks 100 USD on [[MtGox]] and other major exchanges.
|-
|}

=== 2014 ===
=== 2015 ===
=== 2016 ===

=== 2017 ===
{| style="text-align: left"
|-
! May 3
|| [[Tonal Bitcoin]] reached parity with the US dollar, touching $1 per TBC for the first time.
|-
|}

==See Also==

* [[Bitcoin Firsts]]
* [[Press]]
* [https://bitcoinhelp.net/know/more/price-chart-history Bitcoin Price Chart with Historic Events]

==References==
<references />

Bitcoin Wiki:Editing privileges

2024-09-24T20:43:00Z

Theymos: add NotATether's email

Before you can edit, your account has to be manually approved.

== Rules ==
First, note these rules:

# Avoid listing sites or services which make their own income (e.g. exchanges, marketplaces, hardware wallet manufacturers, etc). You can talk about the idea of certain products (e.g. hardware wallets exist and are useful in XYZ circumstances), but not list specific brands.
#* '''If your first edits are you adding an external link or creating a page for some service, you're probably going to be banned.'''
# Articles here will likely be edited by other people. Try not to take it personally.
# Avoid altcoins and especially scamcoins when possible, or confine discussion of these to their own pages (e.g. comparison of altcoins). The Bitcoin Wiki is a space for Bitcoin.
# Do not engage in edit wars: use the talk page to find consensus.

== Getting the attention of a Permittor ==
Get a Permittor to whitelist you in one of these ways:
* Post the edits you want to make on the [https://bitcointalk.org/index.php?board=168.0 wiki board on bitcointalk.org]. Don't just ask to be whitelisted without saying what you want to do.
* Join {{Freenode IRC|bitcoin-wiki}} on Freenode - there is also a {{Libera IRC|bitcoin-wiki}} channel on Libera if you prefer that network. Here, you will also be expected to explain what you want to do.
* One of our Permittors accepts whitelisting requests via email. Send a summary of your proposed edits and your wiki username [https://spamty.eu/show/v7/237/45773e1f08/ here]. Since this is only one Permittor, this method may be slower.

{{p-full}}
{{DISPLAYTITLE:Bitcoin Wiki:Editing privileges}}

Bitcoin Wiki:Editing privileges

2024-09-22T19:52:54Z

Theymos:

Before you can edit, your account has to be manually approved.

== Rules ==
First, note these rules:

# Avoid listing sites or services which make their own income (e.g. exchanges, marketplaces, hardware wallet manufacturers, etc). You can talk about the idea of certain products (e.g. hardware wallets exist and are useful in XYZ circumstances), but not list specific brands.
#* '''If your first edits are you adding an external link or creating a page for some service, you're probably going to be banned.'''
# Articles here will likely be edited by other people. Try not to take it personally.
# Avoid altcoins and especially scamcoins when possible, or confine discussion of these to their own pages (e.g. comparison of altcoins). The Bitcoin Wiki is a space for Bitcoin.
# Do not engage in edit wars: use the talk page to find consensus.

== Getting the attention of a Permittor ==
Get a Permittor to whitelist you in one of these ways:
* Post the edits you want to make on the [https://bitcointalk.org/index.php?board=168.0 wiki board on bitcointalk.org]. Don't just ask to be whitelisted without saying what you want to do.
* Join {{Freenode IRC|bitcoin-wiki}} on Freenode - there is also a {{Libera IRC|bitcoin-wiki}} channel on Libera if you prefer that network. Here, you will also be expected to explain what you want to do.

{{p-full}}
{{DISPLAYTITLE:Bitcoin Wiki:Editing privileges}}

User:Theymos

2024-08-15T20:45:59Z

Theymos:

I can be reached via [https://spamty.eu/show/v7/230/5aac06658f/ email] or forum PM. I am not reliably available elsewhere: I don't use IRC, Telegram, or Discord.

Bitcoin mixer

2024-08-15T19:42:42Z

Theymos: Reverted edit by Fearano (talk) to last revision by NotATether

'''Bitcoin mixer''' is software (or a service like [[CoinJoin]]) that accepts Bitcoin from multiple users, mixes them so you can’t identify who sent how much, and then sends out different bitcoins to their destinations.

If you were to view such a transaction on an explorer, you’d find the address of the mixer as the recipient (in the case of an outgoing transaction from your wallet) instead of a Bitcoin address. Similarly, if you typed in a transaction recipient’s address, and looked to see where the coins came from, all you’d find would be the tumbler’s address.

It’s called a “mixer” because it mixes your coins with other holders' coins to the point that none of them can be connected back to their original wallet addresses. Hence, when you use this solution, you can send Bitcoin or receive it while remaining completely anonymous.

Most Bitcoin tumblers require you to pay service fees for mixing your coins, which are subtracted from your deposit.

== Origins ==

Using bitcoins is a flawed way to stay [[Anonymity|anonymous]] while making your purchases, donations, and P2P payments. But Bitcoin transactions are never truly anonymous. Bitcoin activities are recorded and available publicly via the blockchain — a comprehensive database which keeps a record of bitcoin transactions. And when you finally use Bitcoin to pay for goods and services, you will of course need to provide your name and address to the seller for delivery purposes. You may also have to complete KYC verification in before you can purchase something. It means that a third party can trace your transactions and find ID information. To avoid this, mixers provide the ability to exchange your bitcoins for different ones which cannot be associated with the original owner.

Prior to the advent of trustless alternatives, '''mixing services''' (also called '''mixers''' or '''tumblers''') were used to mix one's funds with other people's money, intending to confuse the trail back to the funds' original source. In traditional financial systems, the equivalent would be moving funds through [[Wikipedia:Offshore bank|banks located in countries with strict bank-secrecy laws]], such as the Cayman Islands, the Bahamas and Panama.

== Comparison to CoinJoins ==

A CoinJoin collects the inputs of many users, and broadcasts them into many outputs in a single transaction, whereas a mixer sends your bitcoins through a series of transactions with a variable number of inputs and outputs, before it is sent back to you in another address, or imported into a wallet as a private key.

A mixer additionally uses a wide variety of techniques to enhance authenticity and privacy, including onion links, PGP signatures, and letters of guarantee.

While a single CoinJoin transaction does not provide as much anonymity as a mixer, a wallet coordinator which relays funds through a series of CoinJoins may have a comparable level of anonymity as a mixer.

== Anonimity ==

While the underlying cryptography and algorithms used by mixers are usually robust, they can be undermined if a mixer records logs of its user activity. This can be used to de-anonymize users in the event that this data is stolen during a hack or collected by law enforcement during a site take-down.

A mixer's privacy may also be undermined by its hosting provider, its domain name service (DNS) provider, telemetry data sent to analytics services, and any DDoS protection services used by the website, such as Cloudflare.

== Controversy ==

Because of the level of anonymity provided by mixers and the nature of how these services operate, they are frequently used by criminals for money laundering. While Bitcoin mixers are not necessarily created with the intent of laundering money, hackers have used them to anonymize large sums of crypto (in some cases worth hundreds of millions of dollars) that have been stolen from exchanges, bridges, and DeFi services during hacks. This has led to an increased scrutiny of bitcoin mixers by various governments, and have in some cases resulted in bitcoin mixers getting seized.

In particular, bitcoin mixers are often abused by state-sponsored cybercrime groups such as [https://en.wikipedia.org/wiki/Lazarus_Group Lazarus Group], which in at least two occasions caused the United States to place the used mixers on the OFAC sanctions list. This is despite the fact that many bitcoin mixers forbidding their use for crime in their terms of services.

Critics of bitcoin mixers say that the addresses belonging to mixers can easily be identified, that exchanges are more likely to withhold a user's funds if they deposit or withdraw to a mixer, that there are a large number of counterfeit websites impersonating mixers, and that users could lose their bitcoins if a mixer is seized by law enforcement before the mixing process is complete.

Occasionally, mixers advertise their services on other platforms, mainly on [[BitcoinTalk|Bitcointalk]]. This has led to some controversy when a mixer's service is seized by governments. In order to deal with this, Bitcointalk banned mixers from operating on the site, and also forbade forum users from advertising mixers.<ref>https://bitcointalk.org/index.php?topic=5476162.0 - ''Mixers to be banned''</ref>

Some mixers use a [https://en.wikipedia.org/wiki/Content_delivery_network content delivery network] (CDN) in order to mitigate DDoS attacks. The most common ones are Cloudflare and DDoS-Guard. The disadvantage in using a CDN is that it can read all of the information sent by users to the website, including bitcoin addresses, as well as metadata about the user's browser such as the IP address, user-agent, and device details. This could potentially lead to de-anonymization of users if this information is given to another entity such as a government<ref>[https://bitcointalk.org/index.php?topic=5247838.msg54414843 Mixers using Cloudflare's SSL certificates | Bitcointalk]</ref>. This can be mitigated by accessing the mixer through its onion link on the Tor Browser.

Mixers are also targets for phishing. Scammers can register a domain name that looks similar to a real mixer's name, clone the website's design but instead of running a mixer, simply steal any bitcoins that are sent for mixing. Because users often mix bitcoins in large quantities, this has posed a serious problems for them.

== Alternatives to Mixers ==

Several [[Privacy|blockchain-based methods]] have been proposed or developed in order to solve the flaws related to mixers. Some of these are listed below.

* '''Taproot addresses''' contain a mechanism for adding additional spend conditions to an address, enabling the hiding of payment information inside them without revealing them publicly.

* '''Silent payments''' utilize externally-defined addresses to create a list random Bitcoin addresses which can be used to send single-use transactions between two or more parties on the blockchain.

* '''Coinjoins''' use decentralized or centralized software that coordinates transactions made by multiple parties by placing them all in a series of combined transactions. When implemented properly, it becomes impossible for blockchain analysis to trace the source of funds. To use coinjoins, you need to use a wallet that supports this feature. One such wallet is [[Wasabi Wallet|Wasabi]] wallet.

==See Also==

* [[Anonymity]]
* [[:Category:Mixing Services]]
* [https://bitmixlist.org A list of Bitcoin mixers]
* [https://bitlist.co Another list of Bitcoin mixers]

== References ==

{{wp|Cryptocurrency_tumbler}}

[[Category:Financial]]
[[Category:Anonymity]]
[[Category:Privacy]]

Quantum computing and Bitcoin

2018-12-26T03:22:35Z

Theymos: some updates

Quantum computers are computers which exploit quantum mechanics to do certain computations far more quickly than traditional computers. A sufficiently large quantum computer would cause some trouble for Bitcoin, though it would certainly not be insurmountable.

''Note that the abbreviation ''QC'' can stand for either ''quantum computer(s)'' or ''quantum cryptography''.''

== QC attacks ==

The most dangerous attack by quantum computers is against public-key cryptography. On traditional computers, it takes on the order of 2128 basic operations to get the Bitcoin private key associated with a Bitcoin public key. This number is so massively large that any attack using traditional computers is completely impractical. However, it is known for sure that it would take a sufficiently large quantum computer on the order of only 1283 basic quantum operations to be able to break a Bitcoin key using Shor's Algorithm. This might take some time, especially since the first quantum computers are likely to be extremely slow, but it is still very practical.

For symmetric cryptography, quantum attacks exist, but are less dangerous. Using Grover's Algorithm, the number of operations required to attack a symmetric algorithm is square-rooted. For example, finding some data which hashes to a specific SHA-256 hash requires 2256 basic operations on a traditional computer, but 2128 basic quantum operations. Both of these are impractically large. Also, since quantum computers will be massively slower and more expensive than traditional computers for decades after they are invented, quantum attacks against symmetric crypto seem unlikely to be especially common. If quantum computers grow in speed and shrink in price over time, then their inherent per-operation advantage in mining might allow them to out-compete classical computers in Bitcoin mining at some point, probably far in the future; this is comparable to the historic move from CPUs to GPUs to ASICs in Bitcoin's past, and would not be an issue.

=== Timeline / plausibility ===

Creating a quantum computer is a ''massive'' scientific and engineering challenge. As of 2019, the largest general-purpose quantum computers have fewer than 100 qubits, have impractically-high error rates, and can operate only in lab conditions at temperatures near absolute zero. Attacking Bitcoin keys would require around 1500 qubits. Humanity currently does not have the technology necessary to create a quantum computer large enough to attack Bitcoin keys. It is not known how quickly this technology will advance; however, cryptography standards such as ECRYPT II tend to say that Bitcoin's 256-bit ECDSA keys are secure until at least 2030-2040.

There is a company called D-Wave which claims to produce quantum computers with over 2000 qubits. However, this claim has not been universally accepted, and even if it is true, this is a ''special-purpose'' "annealing quantum processor" incapable of attacking crypto.

== Mitigations ==

Bitcoin already has some built-in quantum resistance. If you only use Bitcoin addresses one time, which has always been the recommended practice, then your ECDSA public key is only ever revealed at the one time that you spend bitcoins sent to each address. A quantum computer would need to be able to break your key in the short time between when your transaction is first sent and when it gets into a block. It will likely be decades after a quantum computer first breaks a Bitcoin key before quantum computers become this fast.

All of the commonly-used public-key algorithms are broken by QC. This includes RSA, DSA, DH, and all forms of elliptic-curve cryptography. Public-key crypto that is secure against QC does exist, however. Currently, Bitcoin experts tend to favor a cryptosystem based on [https://en.wikipedia.org/wiki/Lamport_signature Lamport signatures]. Lamport signatures are very fast to compute, but they have two major downsides:

* The signature would be quite large, at least several kB (40-170 times larger than now). This would be very bad for Bitcoin's overall scalability, since bandwidth is one of the main limiting factors to Bitcoin's scaling. Advances in scalability such as Segregated Witness (the signature is part of the witness) and Lightning will be helpful.
* At the time that you create each keypair, you would need to set some finite maximum number of times that you can sign with this key. Signing more than this number of times would be insecure. Increasing the signing limit increases the size of each signature even more. Since you are only really supposed to use addresses once, this may not be a huge problem for Bitcoin.

There is also some ongoing academic research on creating quantum-safe public-key algorithms with many of the same properties as today's public-key algorithms, but this is very experimental. It is not known whether it will end up being possible.

A new public-key algorithm can be added to Bitcoin as a [[softfork]]. From the end-user perspective, this would appear as the creation of a new address type, and everyone would need to send their bitcoins to this new address type to achieve quantum security.

== See Also ==

* [http://diyhpl.us/~bryan/papers2/bitcoin/On%20Bitcoin%20security%20in%20the%20presence%20of%20broken%20crypto%20primitives%20-%202016.pdf On Bitcoin Security in the Presence of Broken Crypto Primitives - February 19, 2016]

[[Category:Technical]]

Decoding BitPay payment requests

2018-11-27T16:08:01Z

Theymos: note that bip70 is deprecated

[[BitPay]] annoyingly forces users to pay via a non-standard version of the [https://github.com/bitcoin/bips/blob/master/bip-0070.mediawiki BIP70] payment protocol. BIP70 was created in 2013, and is [https://github.com/bitcoin/bitcoin/pull/14451 deprecated] due to its complexity, reliance on the insecure & centralized certificate authority architecture, privacy issues, and lack of compelling reasons to use it. Therefore, it is not widely supported by wallets, and it probably never will be. This page shows you how to pay to these requests without wallet support.

==Easy Way==

Paste the request URI into https://alexk111.github.io/DeBitpay/, and it will give you the address. This is slightly insecure, since that page could be suddenly changed to give you an incorrect address instead of the real one.

==Doing it yourself==

BitPay supports a non-standard extension to BIP70 which uses JSON instead of a binary format. Therefore, you can use curl or similar to get the payment info. Use a command like:
<pre>curl -H 'Accept: application/payment-request' https://bitpay.com/i/...</pre>

curl supports Tor and proxies. For Tor, you'd add <tt>--socks5-hostname localhost:9050</tt> before <tt>-H</tt>. Replace 9050 with 9150 for Tor Browser.

In the response, <tt>address</tt> is the address you pay to, <tt>amount</tt> is the exact number of [[Satoshi (unit)|satoshi]] you are expected to send (divide by 100000000 for BTC), and <tt>requiredFeeRate</tt> is the minimum satoshi/byte fee rate that you must pay. '''Warning:''' if you don't pay at least the fee rate specified, then BitPay might not register your payment. Round your fees up if necessary.

It should be possible to use built-in tools such as PowerShell to do the same thing on Windows. Edit this page if you know how.

[[Category:Guides]]

Craig Wright

2018-11-19T20:50:51Z

Theymos: grammar

Craig Wright is a fraudster who claims to be the creator of Bitcoin, [[Satoshi Nakamoto]]. There has been no concrete evidence presented in favour of Wright's claim. There is overwhelming evidence against his claim, yet Wright was able to get lots of media coverage by sympathetic journalists with a limited understanding of technology after Wright tricked or bribed a couple of Bitcoin figureheads such as Gavin Andresen to back his claims without themselves having access to any supporting evidence. The Bitcoin community has a duty to explain our technology - we can't expect everyone to understand cryptographic proof -, hence this page can be a useful list of resources.

=== Evidence against Craig Wright being Satoshi ===

* Wright's claimed PGP key was provably backdated. <ref>[https://medium.com/@tbrice/wrights-appeal-to-authority-paper-disproved-its-own-thesis-8f2d45e5df24 Prove of backdated PGP key]</ref><ref>https://bitcointalk.org/index.php?topic=1282144.msg13196947#msg13196947</ref>
* He was paid millions of dollars by nTrust to 'reveal' himself as Satoshi (this is for those who think he lacked motive)<ref>[http://archive.is/kjuLi#selection-729.989-732.0 Paid a million dollars by nTrust to 'reveal' himself as Satoshi]</ref>
* Claimed signature proving him to be Satoshi was worthless. <ref>https://www.reddit.com/r/Bitcoin/comments/4hflr3/craig_wrights_signature_is_worthless/</ref>
* Second claimed "signature" was also an obvious forgery. <ref>https://bitcoin.stackexchange.com/questions/81115/if-someone-wanted-to-pretend-to-be-satoshi-by-posting-a-fake-signature-to-defrau</ref>
* Faked blog posts showing his early involvement in bitcoin. <ref>[https://np.reddit.com/r/btc/comments/6xkn24/bcc_bch_are_bitcoin_they_follow_the_whitepaper/dmjcyou/?context=3 Faked early blog posts]</ref>
* Craig Wright is apparently using his fame to run an advance-fee scam.<ref>https://www.reddit.com/r/Bitcoin/comments/4cdsna/craig_wright_nigerian_prince_and_other_unlikely/</ref>
* Incorrectly calling it "Bit Coin" several times in 2011. <ref>https://www.reddit.com/r/btc/comments/4ieye8/craig_wright_posting_on_a_lulzsec_site_in_2011/</ref>
* Gross technical incompetence. <ref>http://archive.is/6C3C9</ref><ref>https://np.reddit.com/r/btc/comments/799xlz/csw_many_wonder_why_secp256k1_was_used_in/dp0azeb/</ref><ref>https://i.imgur.com/fOn1BI9.png</ref>
* No evidence of any C++ proficiency.
* Plagiarizism<ref>https://twitter.com/PeterRizun/status/983752297363660800 https://archive.is/9ymSC</ref>
* If Craig Wright really was the creator of Bitcoin, the proof would be trivial. We see an example by Charlie Lee the creator of Litecoin<ref>https://twitter.com/satoshilite/status/727157971428331520</ref>

Wright sometimes explains away his apparent technical incompetence by suggesting that the actual development of Bitcoin was performed by a deceased acquaintance, David Kleinman. Kleinman worked as a systems administrator and IT security consultant for law enforcement and does not appear to have any particular programming expertise, similar to Wright. Wright's unsubstantiated claims are the only known source suggesting Kleinman has any connection to the creation of Bitcoin. As a result, arguments that Wright was in some way "involved" with the creation of Bitcoin due to his relationship with Kleinman are circular.

==See Also ==
* [https://en.wikipedia.org/wiki/Craig_Steven_Wright Craig Steven Wright on Wikipedia]
* [https://www.reddit.com/r/Bitcoin/comments/89cbsc/vitalik_buterin_calls_out_craig_wright_for_what/dwq8d1m/ Other list of evidence]

==References==
<references />

Alert system

2018-09-13T07:05:55Z

Theymos: Mention that it was published

[[File:Prefinal alert.png|thumb|300px|The prefinal alert message in the status bar of the GUI client]]Bitcoin versions 0.3.10 introduced an '''alert system''' which allowed messages about critical network problems to be broadcast to all clients.

The alert system has been completely retired.<ref name="org">https://bitcoin.org/en/alert/2016-11-01-alert-retirement</ref> The code was removed since 0.13.0 and since 0.14.0 any old nodes will receive a static hard-coded "Alert Key Compromised" message.

When an alert was in effect, the message it contains would appear in the status bar of all clients and in the "errors" field of RPC ''getinfo''. Any script registered with the <code>-alertnotify</code> command-line option will be notified.

===Alert message===
Alerts are broadcast using the same [[network|TCP relay system]] as ''block'' and ''tx'' messages. They are not encoded in a special transaction. Unlike block and tx relaying, alerts are sent at the start of every new connection for as long as the alert is in effect. This ensures that everyone receives the alert.

Alerts contain this information:
* How long to relay the alert.
* How long to consider the alert valid.
* An alert ID number.
* A list of alerts that should be canceled upon receipt of this alert.
* Exactly which versions of Bitcoin are affected by the alert. Unaffected versions still relay the alert for the benefit of older versions.
* Alert priority.
* The alert text.

Only alerts that are signed by a specific ECDSA public key are considered valid. Some known private key holders were [[Satoshi Nakamoto]], [[User:gavinandresen|Gavin Andresen]] and [[User:Theymos|theymos]], but the private key was made public after the alert system was retired, so there is no longer any special group of alert-key-holders.

===Safe mode===
Until version 0.3.20, Bitcoin went into safe mode when a valid alert was received. In safe mode, all RPC commands that send BTC or get info about received BTC return an error. Current Bitcoin versions no longer go into safe mode in response to alerts, though Bitcoin ''will'' still go into safe mode when it detects on its own that something is seriously wrong with the network.

Even though Bitcoin no longer automatically disables RPC when an alert is live, it is wise for Bitcoin sites to shut down when an alert has been issued. To detect an active alert, poll the "errors" field of ''getinfo''.

To test safe mode, run Bitcoin with the -testsafemode switch. To override a real safe mode event, run Bitcoin with the -disablesafemode switch.

==History==
{{multiple image|align=vertical|width=300
|image1=alert.png
|image2=bitcoin-alert-cli.png
|footer=An alert appearing on bitcoin clients
}}

The alert system was hastily implemented by [[Satoshi Nakamoto]] after the [[value overflow incident]] on August 15, 2010. Satoshi never actually used this system; it remained dormant until the [[February 20, 2012 protocol change]], for which an alert was issued on February 18.<ref>[https://bitcoin.org/en/alert/2012-02-18-protocol-change February 20, 2012 Protocol Changes] at bitcoin.org</ref>

In 2016, the alert system was retired<ref name="org"/> because of the possibility of privileged users sending political alert messages,  and because of the possibility of the alert key having been taken from [[Mark Karpelès]] by the Japanese police in 2014.<ref>https://github.com/bitcoin/bitcoin/pull/7692</ref>

The alert key was scheduled to be released to the public in May 2017, but this was postponed.<ref name="org"/> It was eventually published in July 2018.

===Past alerts===
{| class="wikitable" border="1"
|-
! ID
! Sent date
! Expires (UTC)
! Versions
! Priority
! Message
|-
| 1010
| Feb 18, 2012
| Feb 21 02:47:15
| All
| 100
| See bitcoin.org/feb20 if you have trouble connecting after 20 February
|-
| 1011
| Mar 16, 2012
| cancelled May 15, 2012
| 0.5 - 0.5.3
| 5000
| URGENT: security fix for Bitcoin-Qt on Windows: http://bitcoin.org/critfix
|-
| 1012
| Mar 16, 2012
| cancelled May 15, 2012
| 6.0
| 5000
| URGENT: security fix for Bitcoin-Qt on Windows: http://bitcoin.org/critfix
|-
| 1013
| Mar 16, 2012
| cancelled May 15, 2012
| 5.99
| 5000
| URGENT: security fix for Bitcoin-Qt on Windows: http://bitcoin.org/critfix
|-
| 1015
| May 15, 2012
| May 16, 2013
| 0.1 - 0.4.5
| 5000
| URGENT: upgrade required, see http://bitcoin.org/dos for details
|-
| 1016
| May 15, 2012
| May 16, 2013
| 0.4.99 - 0.5.4
| 5000
| URGENT: upgrade required, see http://bitcoin.org/dos for details
|-
| 1020
| May 15, 2012
| May 16, 2013
| 0.6.0
| 5000
| URGENT: upgrade required, see http://bitcoin.org/dos for details
|-
| 1032
| March 12, 2013
| March 13, 2013
| 0.8.0
| 5000
| URGENT: chain fork, stop mining on version 0.8
|-
| 1033
| March 19, 2013
| March 20, 2013
| 0.1 - 0.7.2
| 10
| See http://bitcoin.org/may15.html for an important message
|-
| 1034
| May 9, 2013
| June 8, 2013
| 0.1 - 0.7.2
| 10
| Action required: see http://bitcoin.org/may15.html for more information
|-
| 1040
| April 11, 2014
| cancelled
| 0.9.0
| 5000
| URGENT: Upgrade required: see https://www.bitcoin.org/heartbleed/
|-
| 1041
| April 11, 2014
| April 11, 2015
| 0.9.0
| 5000
| URGENT: Upgrade required: see https://www.bitcoin.org/heartbleed
|}

==See Also==

* https://github.com/bitcoin/bitcoin/pull/7692 - The pull request where removing the alert system from [[Bitcoin Core]] was discussed

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

==References==
<references/>

==External links==
https://bitcoin.org/en/alerts

{{Bitcoin Core documentation}}

Decoding BitPay payment requests

2018-09-03T22:45:57Z

Theymos: Created page with "BitPay annoyingly forces users to pay via the [https://github.com/bitcoin/bips/blob/master/bip-0070.mediawiki BIP70] payment protocol. BIP70 was created in 2013, and befor..."

[[BitPay]] annoyingly forces users to pay via the [https://github.com/bitcoin/bips/blob/master/bip-0070.mediawiki BIP70] payment protocol. BIP70 was created in 2013, and before BitPay did this, it had become more-or-less deprecated due to its complexity, reliance on the insecure & centralized certificate authority architecture, privacy issues, and lack of compelling reasons to use it. Therefore, it is not widely supported by wallets, and it may never be. This page shows you how to pay to these requests without wallet support.

==Easy Way==

Paste the request URI into https://alexk111.github.io/DeBitpay/, and it will give you the address. This is slightly insecure, since that page could be suddenly changed to give you an incorrect address instead of the real one.

==Doing it yourself==

BitPay supports a non-standard extension to BIP70 which uses JSON instead of a binary format. Therefore, you can use curl or similar to get the payment info. Use a command like:
<pre>curl -H 'Accept: application/payment-request' https://bitpay.com/i/...</pre>

curl supports Tor and proxies. For Tor, you'd add <tt>--socks5-hostname localhost:9050</tt> before <tt>-H</tt>. Replace 9050 with 9150 for Tor Browser.

In the response, <tt>address</tt> is the address you pay to, <tt>amount</tt> is the exact number of [[Satoshi (unit)|satoshi]] you are expected to send (divide by 100000000 for BTC), and <tt>requiredFeeRate</tt> is the minimum satoshi/byte fee rate that you must pay. '''Warning:''' if you don't pay at least the fee rate specified, then BitPay might not register your payment. Round your fees up if necessary.

It should be possible to use built-in tools such as PowerShell to do the same thing on Windows. Edit this page if you know how.

[[Category:Guides]]

Setting up a Tor hidden service

2018-08-26T21:16:33Z

Theymos: note that onion v3 is not supported

If you use a Bitcoin [[full node]] over Tor, then usually it will only be able to make outgoing connections. Therefore, you will only get a maximum of 8 total connections. This is fine, and is not something you usually need to worry about, but if your computer is often online and you want to be a big help to the network, you can run a Tor hidden service in order to accept incoming connections over Tor.

Note that there is no need to forward port 8333 when using a Tor hidden service. The hidden service will cause most firewalls and NAT setups to be bypassed. For this reason, running a Tor hidden service is also a good idea if you want incoming connections but are for some reason unable to forward port 8333.

=== Prerequisites ===

These instructions are for Linux. It is possible to do on Windows, but the instructions would be rather different. (If you've done it on Windows, consider adding the instructions to this page.)

You need Tor (at least version 0.2.7.1). Figure out where your <tt>torrc</tt> file is (<tt>/etc/tor/torrc</tt> is one possibility). This guide assumes default Tor settings. This guide assumes that Tor is running under the user and group <tt>tor</tt>, which will usually be the case if you install Tor using your distro's package manager. Note that Bitcoin '''does not''' support hidden service version 3 (ie. long onion addresses).

You need Bitcoin Core (or similar). For method 1, you need at least version 0.12.0. Find <tt>bitcoin.conf</tt> in your [[data directory]].

=== Method 1 (recommended) ===

This sets up an ephemeral hidden service. The hidden service address (xxxx.onion) will change every time Bitcoin Core is restarted.

Add these lines to your <tt>torrc</tt>:

<pre>ControlPort 9051
CookieAuthentication 1
CookieAuthFileGroupReadable 1</pre>

You need to figure out what user bitcoind or bitcoin-qt is running as. Run the following command while Bitcoin is running:
<pre>ps -eo user,group,comm |egrep 'bitcoind|bitcoin-qt' |awk '{print "Bitcoin user: " $1}'</pre>
Write down the reported user.

Run the following command as root, which adds your Bitcoin user to the tor group. Replace BITCOIN_USER with the actual user name found above:
<pre>usermod -a -G tor BITCOIN_USER</pre>

If you don't modify any other settings, Bitcoin Core will usually connect over the regular Internet, but will also allow connections to and from the hidden service. If you want Bitcoin Core to only connect via Tor (for anonymity), add these lines to bitcoin.conf:

<pre>proxy=127.0.0.1:9050
listen=1
bind=127.0.0.1</pre>

If you additionally want Bitcoin Core to only connect out to Tor ''hidden services'', also add this line (not particularly recommended):
<pre>onlynet=onion</pre>

If you're only interested in running a hidden service in order to help the network, then there's no need to modify any bitcoin.conf settings at all. Bitcoin Core will automatically detect Tor and create the hidden service.

Now restart Tor, and then Bitcoin Core. You should eventually get incoming connections via the hidden service.

=== Method 2 ===

This sets up a static hidden service. The hidden service address (xxxx.onion) will never change. This is probably even more helpful for the network, and you will probably get more incoming connections than method 1, but ''maybe'' it would be helpful to someone trying to track your transactions.

Add these lines to your <tt>torrc</tt>:
<pre>HiddenServiceDir /var/lib/tor/bitcoin-service/
HiddenServicePort 8333 127.0.0.1:8333</pre>

Restart Tor. As root, run <tt>cat /var/lib/tor/bitcoin-service/hostname</tt>. Your onion address will be reported. If it didn't work, then probably your distro's version of Tor doesn't actually use <tt>/var/lib/tor</tt> for this purpose. You should try to figure out the correct HiddenServiceDir location.

In the following steps, replace ONION_ADDR with the onion address reported above.

If you don't care about anonymity and are only looking to help the network, add the following lines to bitcoin.conf:
<pre>onion=127.0.0.1:9050
listen=1
externalip=ONION_ADDR
discover=1</pre>
This will allow you to accept connections both via your onion address and your IP address (if you have port 8333 forwarded), and Tor will only be used for connections to and from Tor hidden services.

If you care about anonymity, '''instead''' of the above, add the following lines to bitcoin.conf to use Tor for everything:
<pre>proxy=127.0.0.1:9050
listen=1
bind=127.0.0.1
externalip=ONION_ADDR</pre>

If you additionally want Bitcoin Core to only connect out to Tor ''hidden services'', also add this line (not particularly recommended):
<pre>onlynet=onion</pre>

Now restart Bitcoin Core. You should eventually get incoming connections via your hidden service.

[[Category:Guides]]

Orphan Block

2018-07-28T22:37:15Z

Theymos: Clarify that people usually mean stale block when they say this

Usually when people say "orphan block", they mean a [[Vocabulary#Stale_Block|Stale Block]], which is a well-formed block which is no longer part of the difficultywise-longest and well-formed blockchain. The [[Block Reward]] in a stale block is no longer spendable on the difficultywise-longest and well-formed blockchain; therefore whoever mined that block does not actually get the reward (or the [[transaction fees]]). This phenomenon must be taken into account by mining pools that use any payout strategy other than "proportional".

Conceptually, calling the above type of block an orphan block doesn't make any sense, since it ''does'' have a parent. Indeed, in the Bitcoin source code and in more technical discussions, orphan blocks and stale blocks are two separate things: both are not part of the longest valid chain, but in an orphan block it is because the parent is ''unknown'', whereas in a stale block it is because that part of the chain is known to no longer be longest. However, in general discussions people almost always mean "stale block" but say "orphan block".

Schnorr

2018-07-19T23:42:16Z

Theymos: Add summary

Bitcoin currently uses the [[ECDSA]] algorithm to generate cryptographic signatures for a given message and [[secp256k1]] keypair. Schnorr is an alternative algorithm with several advantages. The main reason that Bitcoin did not originally use Schnorr signatures is that Schnorr was not standardized, and was not available in common crypto libraries.

==Technical details==

Schnorr signatures are a proposed future extension that give a new way to generate signatures r, s on a hash h.

Given a hash value h, hash function f(), private key x, group generator G, and public key P=xG, we can generate a Schnorr signature on h as follows:

Choose a random nonce k. Let R=Gk, and let s = k - f(h . R . P)x. The Schnorr signature is the pair (R, s). Note that R is a public key, so would require 33 bytes to represent (32 bytes + 1 bit indicating "even" vs "odd").

To check the validity of a signature (R, s) against a public key P, do the following:

Note that sG = (k- f(h . R . P))G = kG - f(h . R . P)xG = R - f(h . R . P)P. So we simply compare sG + f(h . R . P)P to R to check the signature.

An advantage of this method is that, if parties cooperate, we can generate a single signature that validates two or more separate transactions.

Choose h1, h2, x1, x2, G, P1=Gx1, P2=Gx2. Each party chooses a nonce yielding k1 and k2, and publicly shares R1=Gk1, R2=Gk2.

Let R = R1+R2. Each signer generates an s, s1 = k1 - f(h . R . P)x1, s2 = k2 - f(h . R . P)x2. The signature (R, s) where s = s1 + s2 proves both transactions are signed.

Note that sG = (s1 + s2)G = s1G + s2G = (k1 - f(h . R . P)x1)G + (k2 - f(h . R . P)x2)G = k1G - f(h . R . P)x1G + k2G - f(h . R . P)x2G = R1 + R2 - f(h . R . P)(P1 + P2) = R - f(h . R . P)(P1 + P2)

To verify, check that sG +f(h . R . P)(P1+P2) is R.

This can be easily generalized from 2 to N.

==See also==
[https://github.com/sipa/bips/blob/bip-schnorr/bip-schnorr.mediawiki Draft Schnorr specification for future use in Bitcoin]

[[Category:Technical]]

Secp256k1

2018-07-19T23:33:32Z

Theymos: Clarify that secp256k1 is independent of ECDSA

[[File:Secp256k1.png|thumb |This is a graph of secp256k1's elliptic curve ''y2 = x3 + 7'' over the real numbers. Note that because secp256k1 is actually defined over the field Zp, its graph will in reality look like random scattered points, not anything like this.]]

'''secp256k1''' refers to the parameters of the elliptic curve used in Bitcoin's public-key cryptography, and is defined in ''Standards for Efficient Cryptography (SEC)'' (Certicom Research, http://www.secg.org/sec2-v2.pdf). Currently Bitcoin uses secp256k1 with the [[ECDSA]] algorithm, though the same curve with the same public/private keys can be used in some other algorithms such as [[Schnorr]].

secp256k1 was almost never used before Bitcoin became popular, but it is now gaining in popularity due to its several nice properties. Most commonly-used curves have a random structure, but secp256k1 was constructed in a special non-random way which allows for especially efficient computation. As a result, it is often more than 30% faster than other curves if the implementation is sufficiently optimized. Also, unlike the popular NIST curves, secp256k1's constants were selected in a predictable way, which significantly reduces the possibility that the curve's creator inserted any sort of backdoor into the curve.

=== Technical details ===

As excerpted from ''Standards'':

The elliptic curve domain parameters over F''p'' associated with a Koblitz curve secp256k1 are specified
by the sextuple T = (''p,a,b,G,n,h'') where the finite field F''p'' is defined by:
* ''p'' = FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFE FFFFFC2F
* = 2256 - 232 - 29 - 28 - 27 - 26 - 24 - 1

The curve ''E'': ''y2 = x3+ax+b'' over F''p'' is defined by:
* ''a'' = 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
* ''b'' = 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000007

The base point G in compressed form is:
* ''G'' = 02 79BE667E F9DCBBAC 55A06295 CE870B07 029BFCDB 2DCE28D9 59F2815B 16F81798
and in uncompressed form is:
* ''G'' = 04 79BE667E F9DCBBAC 55A06295 CE870B07 029BFCDB 2DCE28D9 59F2815B 16F81798 483ADA77 26A3C465 5DA4FBFC 0E1108A8 FD17B448 A6855419 9C47D08F FB10D4B8
Finally the order ''n'' of ''G'' and the cofactor are:
* ''n'' = FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFE BAAEDCE6 AF48A03B BFD25E8C D0364141
* ''h'' = 01

=== Properties ===

* secp256k1 has characteristic ''p'', it is defined over the prime field ℤ''p''. Some other curves in common use have characteristic ''2'', and are defined over a binary Galois field ''GF(2n)'', but secp256k1 is not one of them.
* As the ''a'' constant is zero, the ''ax'' term in the curve equation is always zero, hence the curve equation becomes ''y2 = x3 + 7''.

=== Cryptocurrencies ===
This list is incomplete. You can help by expanding it.

* Bitcoin
* Ethereum
* EOS
* Litecoin
* Dash
* Dogecoin
* Zcash

== See also ==

* [https://bitcoin.stackexchange.com/questions/21907/what-does-the-curve-used-in-bitcoin-secp256k1-look-like What does secp256k1 look like] (Bitcoin stack exchange answer by Pieter Wuille)

[[es:Secp256k1]]

[[Category:Technical]]

Vocabulary

2018-06-24T00:39:41Z

Theymos: add Policy

{| align="right"
| __TOC__
|}

=====Bitcoin=====
The name of a decentralized p2p crypto-currency network.

=====[[Bitcoins]]=====
Digital currency units generated and used within the Bitcoin system. Common abbreviations include BTC, XBT or lowercase ''bitcoin'' when referring to units of the currency.

=====[[Block]]=====
Blocks are links in a chain of transaction verifications. Outstanding transactions get bundled into a block and are verified roughly every ten minutes on average. Each subsequent block strengthens the verification of previous blocks. Each block contains one or more transactions.

=====[[Block Chain]]=====
Each block includes the difficult-to-produce verification hash of the previous block. This allows each subsequent block to be linked to all previous blocks. These blocks which are linked together for the purpose of verifying transactions within blocks is called the block chain.

=====[[Mining#Reward|Block Reward]]=====
When a Bitcoin miner finds a block, it receives newly minted bitcoins known as the "Block Reward." The reward (a.k.a., subsidy) is halved every four years and is responsible for bitcoin's [[controlled supply]].

=====Branching Point=====
The block at which the block chain diverges into multiple chain branches.

=====BTC=====
The common decimal [[Units|unit]] of a single bitcoin. Equal to 100,000,000 satoshis, or 1.00000000 bitcoin.

=====[[Checkpoint Lockin]]=====
Every once in a while, an old block hash is hardcoded into Bitcoin software. Different implementations choose different checkpoint locations. Checkpoints prevent various DOS attacks from nodes flooding unusable chains and attacks involving isolating nodes and giving them fake chains. Satoshi announced the feature [https://bitcointalk.org/index.php?topic=437 here] and it was discussed to death [https://bitcointalk.org/index.php?topic=1647 here].

=====Coinbase=====
"Coinbase" is another name for a generation transaction. The input of such a transaction contains some arbitrary data where the scriptSig would go in normal transactions -- this data is sometimes called the "coinbase", as well.

=====[[Confirmation]]=====
To protect against double spending, a transaction should not be considered as "confirmed" until a certain number of blocks in the block chain confirm, or verify that the transaction. The classic bitcoin client will show a transaction as "n/unconfirmed" until 6 blocks confirm the transaction.

=====[[Difficulty]]=====
Every 2016 blocks, Bitcoin adjusts the difficulty of verifying blocks based on the time it took to verify the previous 2016 blocks. The difficulty is adjusted so that given the average estimated computing power of the whole bitcoin network, only one block will verified on average every ten minutes for the next 2016 blocks. The difficulty is usually expressed as a number, optionally accurate to many decimal places (eg. in [http://blockexplorer.com/b/100000 block 100,000] it was 14,484.162361. The difficulty is inversely proportional to the hash target, which is expressed as a hex number with around 50 digits, and is the number under which a block's generated hash must be to qualify as an officially verified block. The hash target is equal to ((65535 << 208) / difficulty). Difficulty is also often called block difficulty, hash difficulty, verification difficulty or the difficulty of generating bitcoins.

=====[[Double-spending|Double-Spending]]=====
Attempting to spend coins that have already been spent in another transaction

=====Generate Bitcoins=====
An old term for [[Mining]]. The word "Mining" was not coined until years after Bitcoin was created, after [[Satoshi Nakamoto|Satoshi]] left.

=====[[Hash]]=====
The output of a cryptographic [[#Hash_function|hash function]].

=====Hash function=====
A computer algorithm which takes an arbitrary amount of input data and deterministically produces fixed length output, known as the data's "hash", that can be used to easily verify that data has not been altered. If you change any single bit of the original data and run the hash algorithm, the hash will completely change. Because the hash is seemingly random, it is prohibitively difficult to try to produce a specific hash by changing the data which is being hashed.

=====Low Priority=====
See Priority.

=====Main Chain=====
The longest valid [[Block Chain]].

=====Memory pool=====
Nodes store [[transactions]] waiting to get into a block in their memory pool (or '''mempool''') after receiving them. In other words, a node's memory pool contains all 0-confirmation transactions across the entire network that that particular node knows about (with caveats). When [[Mining|miner]]s construct new blocks, they fill their candidate blocks with transactions taken from their local node's mempool. It is a common misconception that "the mempool" is one single network-wide thing, when in reality it is a different (though probably similar) set of transactions for every node. Indeed, if it could be guaranteed that every node had exactly the same mempool, then there would be no need for mining or a [[block chain]].

Exactly which transactions enter a node's mempool, and how long it stays there, is policy which varies per node. The mempool behavior of [[Bitcoin Core]] 0.16 is complex, with many user-configurable variables, but some highlights of the '''defaults''' are:

* Transactions only enter the mempool if they are valid and have a fee above 1 satoshi/byte. Transactions excluded from the mempool have their hash saved in memory so that they aren't downloaded over and over again.
* The mempool is saved across node restarts. In old versions, the mempool was saved only in memory and would be wiped if the node restarted, which is how it got the name ''memory'' pool.
* The mempool will only grow to a maximum size of 300 MB. If it would get larger than that, then the lowest-fee-per-byte transactions already in it are evicted instead.
* Transactions that have been in the mempool for 336 hours without getting into a block are evicted.
* Transactions within the mempool can be replaced by higher-fee versions if the old versions signalled replace-by-fee (RBF, BIP125) and the new version increases the fee by at least 1 satoshi/byte.

=====Merkle root=====
Every [[transactions|transaction]] has a [[hash]] associated with it. In a [[block]], all of the transaction hashes in the block are themselves hashed (sometimes several times -- the exact process is complex), and the result is the Merkle root. In other words, the Merkle root is the hash of all the hashes of all the transactions in the block. The Merkle root is included in the [[block hashing algorithm|block header]]. With this scheme, it is possible to securely verify that a transaction has been accepted by the network (and get the number of confirmations) by downloading just the tiny block headers and [[Wikipedia:Merkle tree|Merkle tree]] -- downloading the entire block chain is unnecessary. This feature is currently not used in Bitcoin, but it will be in the future.

===== Miner=====
Computer software which is designed to repeatedly calculate hashes with the intention to create a successful block and earn coins from transaction fees and new coins created with the block itself. The term references an analogy of gold miners who dig gold out of the ground and thus "discover" new gold that can be used to create new coins with a similar kind of discovery occurring with a successful hash to create new Bitcoins.

=====Node=====
Each piece of software connected to the main Bitcoin [[network]] is called a node. Some nodes are [[full node]]s.

=====Nonce=====
A nonce is an otherwise meaningless number which is used to alter the outcome of a hash. Each time Bitcoin hashes a block, it increments a nonce within the block which it is trying verify. If the numeric value of the effectively random hash is below a certain amount determined by the block generation difficulty, then the block is accepted by other clients and gets added to the chain.

=====[[Orphan Block]]=====
An orphan block is a block which has no known parent in the currently-longest [[block chain]]. Not to be confused with a [[#Stale_Block|Stale Block]] (which has a known parent, but is no longer part of the longest chain).

=====Orphan root=====
The root (first) block in an [[Orphan Block|orphan]] block chain.

=====Policy=====

Any rule which a node can change freely at will is called policy. For example, whether or not you have your node relay transactions is policy, since diverging from the default behavior is OK. This is distinguished from ''consensus'' rules, where everyone needs to have the same behavior or else you end up splitting the currency. Also see: [[Full node]], [[Consensus]], [[Bitcoin is not ruled by miners]].

=====Priority=====
A scoring mechanism to help ensure that expensive data storage isn't consumed by lower quality and spam. A miner taking priority into account will not include low-priority transactions into his blocks if the limited space is already filled by higher-priority transactions. A [[Transaction Fee|transaction fee]] will affect priority.

Priority (other than the transaction fee) was removed from [[Bitcoin Core]] in 2017, though some miners may still choose to use it by using modified software.

=====[[Proof of work]]=====
A result that can only be obtained through the use of computational resources. Changing the data in the proof of work requires redoing the work.

=====Reorganize=====
A block chain reorganize (or '''reorg''') happens when one chain becomes longer than the one you are currently working on. All of the blocks in the old chain that are not in the new one become orphan blocks, and their generations are invalidated. Transactions that use the newly-invalid generated coins also become invalid, though this is only possible in large chain splits because generations can't be spent for 100 blocks. The number of confirmations for transactions may change after a reorg, and transactions that are not in the new chain will become "0/unconfirmed" again. If a transaction in the old chain conflicts with one in the new chain (as a result of double-spending), the old one becomes invalid.

=====Satoshi=====
The base unit of Bitcoin (0.00000001 BTC) is sometimes called a satoshi, after Bitcoin's creator [[Satoshi Nakamoto]].

=====Seed Nodes=====
Nodes whose IP addresses are included in the [[Original Bitcoin client|Bitcoin client]] for use during a new installation when the normal bootstrapping process through IRC wasn't possible.

=====Stale Block=====
A well-formed block which is no longer part of the difficultywise-longest and well-formed blockchain. Not to be confused with an [[#Orphan_Block|Orphan Block]] (which has no known parent in the longest [[block chain]]).

=====Subsidy=====
See "[[#Block_Reward|Block Reward]]" above.

=====Super Nodes=====
A participant in a p2p network which connects to as many other nodes as possible.

=====[[Tonal Bitcoin]]=====
Adaptation of Bitcoin to the [http://en.wikipedia.org/wiki/John_W._Nystrom#Tonal_System_.28Hexadecimal.29 Tonal System]. 1 TBC is defined as 1,0000 (65,536 decimal) base bitcoin units. Not widely used.

=====[[Transaction Fee]]=====
A voluntary fee which can be added to a transaction which is used as an incentive to add the bitcoin transaction to a block. The fee determines the likelihood of inclusion in any given block, where a high fee included with a transaction has a priority over transactions with a lower fee included or no fee at all.

=====Virgin bitcoin=====
The reward for generating a [[Block|block]] that has not yet been spent, a state which might increase the ability to transact [[anonymity|anonymously]].

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

{{Bitcoin Core documentation}}

Vocabulary

2018-06-24T00:26:11Z

Theymos: Various minor fixups

{| align="right"
| __TOC__
|}

=====Bitcoin=====
The name of a decentralized p2p crypto-currency network.

=====[[Bitcoins]]=====
Digital currency units generated and used within the Bitcoin system. Common abbreviations include BTC, XBT or lowercase ''bitcoin'' when referring to units of the currency.

=====[[Block]]=====
Blocks are links in a chain of transaction verifications. Outstanding transactions get bundled into a block and are verified roughly every ten minutes on average. Each subsequent block strengthens the verification of previous blocks. Each block contains one or more transactions.

=====[[Block Chain]]=====
Each block includes the difficult-to-produce verification hash of the previous block. This allows each subsequent block to be linked to all previous blocks. These blocks which are linked together for the purpose of verifying transactions within blocks is called the block chain.

=====[[Mining#Reward|Block Reward]]=====
When a Bitcoin miner finds a block, it receives newly minted bitcoins known as the "Block Reward." The reward (a.k.a., subsidy) is halved every four years and is responsible for bitcoin's [[controlled supply]].

=====Branching Point=====
The block at which the block chain diverges into multiple chain branches.

=====BTC=====
The common decimal [[Units|unit]] of a single bitcoin. Equal to 100,000,000 satoshis, or 1.00000000 bitcoin.

=====[[Checkpoint Lockin]]=====
Every once in a while, an old block hash is hardcoded into Bitcoin software. Different implementations choose different checkpoint locations. Checkpoints prevent various DOS attacks from nodes flooding unusable chains and attacks involving isolating nodes and giving them fake chains. Satoshi announced the feature [https://bitcointalk.org/index.php?topic=437 here] and it was discussed to death [https://bitcointalk.org/index.php?topic=1647 here].

=====Coinbase=====
"Coinbase" is another name for a generation transaction. The input of such a transaction contains some arbitrary data where the scriptSig would go in normal transactions -- this data is sometimes called the "coinbase", as well.

=====[[Confirmation]]=====
To protect against double spending, a transaction should not be considered as "confirmed" until a certain number of blocks in the block chain confirm, or verify that the transaction. The classic bitcoin client will show a transaction as "n/unconfirmed" until 6 blocks confirm the transaction.

=====[[Difficulty]]=====
Every 2016 blocks, Bitcoin adjusts the difficulty of verifying blocks based on the time it took to verify the previous 2016 blocks. The difficulty is adjusted so that given the average estimated computing power of the whole bitcoin network, only one block will verified on average every ten minutes for the next 2016 blocks. The difficulty is usually expressed as a number, optionally accurate to many decimal places (eg. in [http://blockexplorer.com/b/100000 block 100,000] it was 14,484.162361. The difficulty is inversely proportional to the hash target, which is expressed as a hex number with around 50 digits, and is the number under which a block's generated hash must be to qualify as an officially verified block. The hash target is equal to ((65535 << 208) / difficulty). Difficulty is also often called block difficulty, hash difficulty, verification difficulty or the difficulty of generating bitcoins.

=====[[Double-spending|Double-Spending]]=====
Attempting to spend coins that have already been spent in another transaction

=====Generate Bitcoins=====
An old term for [[Mining]]. The word "Mining" was not coined until years after Bitcoin was created, after [[Satoshi Nakamoto|Satoshi]] left.

=====[[Hash]]=====
The output of a cryptographic [[#Hash_function|hash function]].

=====Hash function=====
A computer algorithm which takes an arbitrary amount of input data and deterministically produces fixed length output, known as the data's "hash", that can be used to easily verify that data has not been altered. If you change any single bit of the original data and run the hash algorithm, the hash will completely change. Because the hash is seemingly random, it is prohibitively difficult to try to produce a specific hash by changing the data which is being hashed.

=====Low Priority=====
See Priority.

=====Main Chain=====
The longest valid [[Block Chain]].

=====Memory pool=====
Nodes store [[transactions]] waiting to get into a block in their memory pool (or '''mempool''') after receiving them. In other words, a node's memory pool contains all 0-confirmation transactions across the entire network that that particular node knows about (with caveats). When [[Mining|miner]]s construct new blocks, they fill their candidate blocks with transactions taken from their local node's mempool. It is a common misconception that "the mempool" is one single network-wide thing, when in reality it is a different (though probably similar) set of transactions for every node. Indeed, if it could be guaranteed that every node had exactly the same mempool, then there would be no need for mining or a [[block chain]].

Exactly which transactions enter a node's mempool, and how long it stays there, is [[policy]] which varies per node. The mempool behavior of [[Bitcoin Core]] 0.16 is complex, with many user-configurable variables, but some highlights of the '''defaults''' are:

* Transactions only enter the mempool if they are valid and have a fee above 1 satoshi/byte. Transactions excluded from the mempool have their hash saved in memory so that they aren't downloaded over and over again.
* The mempool is saved across node restarts. In old versions, the mempool was saved only in memory and would be wiped if the node restarted, which is how it got the name ''memory'' pool.
* The mempool will only grow to a maximum size of 300 MB. If it would get larger than that, then the lowest-fee-per-byte transactions already in it are evicted instead.
* Transactions that have been in the mempool for 336 hours without getting into a block are evicted.
* Transactions within the mempool can be replaced by higher-fee versions if the old versions signalled replace-by-fee (RBF, BIP125) and the new version increases the fee by at least 1 satoshi/byte.

=====Merkle root=====
Every [[transactions|transaction]] has a [[hash]] associated with it. In a [[block]], all of the transaction hashes in the block are themselves hashed (sometimes several times -- the exact process is complex), and the result is the Merkle root. In other words, the Merkle root is the hash of all the hashes of all the transactions in the block. The Merkle root is included in the [[block hashing algorithm|block header]]. With this scheme, it is possible to securely verify that a transaction has been accepted by the network (and get the number of confirmations) by downloading just the tiny block headers and [[Wikipedia:Merkle tree|Merkle tree]] -- downloading the entire block chain is unnecessary. This feature is currently not used in Bitcoin, but it will be in the future.

===== Miner=====
Computer software which is designed to repeatedly calculate hashes with the intention to create a successful block and earn coins from transaction fees and new coins created with the block itself. The term references an analogy of gold miners who dig gold out of the ground and thus "discover" new gold that can be used to create new coins with a similar kind of discovery occurring with a successful hash to create new Bitcoins.

=====Node=====
Each piece of software connected to the main Bitcoin [[network]] is called a node. Some nodes are [[full node]]s.

=====Nonce=====
A nonce is an otherwise meaningless number which is used to alter the outcome of a hash. Each time Bitcoin hashes a block, it increments a nonce within the block which it is trying verify. If the numeric value of the effectively random hash is below a certain amount determined by the block generation difficulty, then the block is accepted by other clients and gets added to the chain.

=====[[Orphan Block]]=====
An orphan block is a block which has no known parent in the currently-longest [[block chain]]. Not to be confused with a [[#Stale_Block|Stale Block]] (which has a known parent, but is no longer part of the longest chain).

=====Orphan root=====
The root (first) block in an [[Orphan Block|orphan]] block chain.

=====Priority=====
A scoring mechanism to help ensure that expensive data storage isn't consumed by lower quality and spam. A miner taking priority into account will not include low-priority transactions into his blocks if the limited space is already filled by higher-priority transactions. A [[Transaction Fee|transaction fee]] will affect priority.

Priority (other than the transaction fee) was removed from [[Bitcoin Core]] in 2017, though some miners may still choose to use it by using modified software.

=====[[Proof of work]]=====
A result that can only be obtained through the use of computational resources. Changing the data in the proof of work requires redoing the work.

=====Reorganize=====
A block chain reorganize (or '''reorg''') happens when one chain becomes longer than the one you are currently working on. All of the blocks in the old chain that are not in the new one become orphan blocks, and their generations are invalidated. Transactions that use the newly-invalid generated coins also become invalid, though this is only possible in large chain splits because generations can't be spent for 100 blocks. The number of confirmations for transactions may change after a reorg, and transactions that are not in the new chain will become "0/unconfirmed" again. If a transaction in the old chain conflicts with one in the new chain (as a result of double-spending), the old one becomes invalid.

=====Satoshi=====
The base unit of Bitcoin (0.00000001 BTC) is sometimes called a satoshi, after Bitcoin's creator [[Satoshi Nakamoto]].

=====Seed Nodes=====
Nodes whose IP addresses are included in the [[Original Bitcoin client|Bitcoin client]] for use during a new installation when the normal bootstrapping process through IRC wasn't possible.

=====Stale Block=====
A well-formed block which is no longer part of the difficultywise-longest and well-formed blockchain. Not to be confused with an [[#Orphan_Block|Orphan Block]] (which has no known parent in the longest [[block chain]]).

=====Subsidy=====
See "[[#Block_Reward|Block Reward]]" above.

=====Super Nodes=====
A participant in a p2p network which connects to as many other nodes as possible.

=====[[Tonal Bitcoin]]=====
Adaptation of Bitcoin to the [http://en.wikipedia.org/wiki/John_W._Nystrom#Tonal_System_.28Hexadecimal.29 Tonal System]. 1 TBC is defined as 1,0000 (65,536 decimal) base bitcoin units. Not widely used.

=====[[Transaction Fee]]=====
A voluntary fee which can be added to a transaction which is used as an incentive to add the bitcoin transaction to a block. The fee determines the likelihood of inclusion in any given block, where a high fee included with a transaction has a priority over transactions with a lower fee included or no fee at all.

=====Virgin bitcoin=====
The reward for generating a [[Block|block]] that has not yet been spent, a state which might increase the ability to transact [[anonymity|anonymously]].

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

{{Bitcoin Core documentation}}

Vocabulary

2018-06-24T00:15:43Z

Theymos: Update mempool info

{| align="right"
| __TOC__
|}

=====Bitcoin=====
The name of a decentralized p2p crypto-currency network.

=====[[Bitcoins]]=====
Digital currency units generated and used within the Bitcoin system. Common abbreviations include BTC, XBT or lowercase ''bitcoin'' when referring to units of the currency.

=====[[Block]]=====
Blocks are links in a chain of transaction verifications. Outstanding transactions get bundled into a block and are verified roughly every ten minutes on average. Each subsequent block strengthens the verification of previous blocks. Each block contains one or more transactions.

=====[[Block Chain]]=====
Each block includes the difficult-to-produce verification hash of the previous block. This allows each subsequent block to be linked to all previous blocks. These blocks which are linked together for the purpose of verifying transactions within blocks is called the block chain.

=====[[Mining#Reward|Block Reward]]=====
When a Bitcoin miner finds a block, it receives newly minted bitcoins known as the "Block Reward." The reward (a.k.a., subsidy) is halved every four years and is responsible for bitcoin's [[controlled supply]].

=====Branching Point=====
The block at which the block chain diverges into multiple chain branches.

=====BTC=====
The common decimal [[Units|unit]] of a single bitcoin. Equal to 100,000,000 satoshis, or 1.00000000 bitcoin.

=====[[Checkpoint Lockin]]=====
Every once in a while, an old block hash is hardcoded into Bitcoin software. Different implementations choose different checkpoint locations. Checkpoints prevent various DOS attacks from nodes flooding unusable chains and attacks involving isolating nodes and giving them fake chains. Satoshi announced the feature [https://bitcointalk.org/index.php?topic=437 here] and it was discussed to death [https://bitcointalk.org/index.php?topic=1647 here].

=====Coinbase=====
"Coinbase" is another name for a generation transaction. The input of such a transaction contains some arbitrary data where the scriptSig would go in normal transactions -- this data is sometimes called the "coinbase", as well.

=====[[Confirmation]]=====
To protect against double spending, a transaction should not be considered as "confirmed" until a certain number of blocks in the block chain confirm, or verify that the transaction. The classic bitcoin client will show a transaction as "n/unconfirmed" until 6 blocks confirm the transaction.

=====[[Difficulty]]=====
Every 2016 blocks, Bitcoin adjusts the difficulty of verifying blocks based on the time it took to verify the previous 2016 blocks. The difficulty is adjusted so that given the average estimated computing power of the whole bitcoin network, only one block will verified on average every ten minutes for the next 2016 blocks. The difficulty is usually expressed as a number, optionally accurate to many decimal places (eg. in [http://blockexplorer.com/b/100000 block 100,000] it was 14,484.162361. The difficulty is inversely proportional to the hash target, which is expressed as a hex number with around 50 digits, and is the number under which a block's generated hash must be to qualify as an officially verified block. The hash target is equal to ((65535 << 208) / difficulty). Difficulty is also often called block difficulty, hash difficulty, verification difficulty or the difficulty of generating bitcoins.

=====[[Double-spending|Double-Spending]]=====
Attempting to spend coins that have already been spent in another transaction

=====Generate Bitcoins=====
The process by which new bitcoins (a.k.a., the "Block Reward") are distributed via [[Mining]].

=====[[Hash]]=====
The output of a cryptographic [[#Hash_function|hash function]].

=====Hash function=====
A computer algorithm which takes an arbitrary amount of input data and deterministically produces fixed length output, known as the data's "hash", that can be used to easily verify that data has not been altered. If you change any single bit of the original data and run the hash algorithm, the hash will completely change. Because the hash is seemingly random, it is prohibitively difficult to try to produce a specific hash by changing the data which is being hashed.

=====Low Priority=====
See Priority.

=====Main Chain=====
The longest [[Block Chain]].

=====Memory pool=====
Nodes store [[transactions]] waiting to get into a block in their memory pool (or '''mempool''') after receiving them. In other words, a node's memory pool contains all 0-confirmation transactions across the entire network that that particular node knows about (with caveats). When [[Mining|miner]]s construct new blocks, they fill their candidate blocks with transactions taken from their local node's mempool. It is a common misconception that "the mempool" is one single network-wide thing, when in reality it is a different (though probably similar) set of transactions for every node. Indeed, if it could be guaranteed that every node had exactly the same mempool, then there would be no need for mining or a [[block chain]].

Exactly which transactions enter a node's mempool, and how long it stays there, is [[policy]] which varies per node. The mempool behavior of [[Bitcoin Core]] 0.16 is complex, with many user-configurable variables, but some highlights of the '''defaults''' are:

* Transactions only enter the mempool if they are valid and have a fee above 1 satoshi/byte. Transactions excluded from the mempool have their hash saved in memory so that they aren't downloaded over and over again.
* The mempool is saved across node restarts. In old versions, the mempool was saved only in memory and would be wiped if the node restarted, which is how it got the name ''memory'' pool.
* The mempool will only grow to a maximum size of 300 MB. If it would get larger than that, then the lowest-fee-per-byte transactions already in it are evicted instead.
* Transactions that have been in the mempool for 336 hours without getting into a block are evicted.
* Transactions within the mempool can be replaced by higher-fee versions if the old versions signalled replace-by-fee (RBF, BIP125) and the new version increases the fee by at least 1 satoshi/byte.

=====Merkle root=====
Every [[transactions|transaction]] has a [[hash]] associated with it. In a [[block]], all of the transaction hashes in the block are themselves hashed (sometimes several times -- the exact process is complex), and the result is the Merkle root. In other words, the Merkle root is the hash of all the hashes of all the transactions in the block. The Merkle root is included in the [[block hashing algorithm|block header]]. With this scheme, it is possible to securely verify that a transaction has been accepted by the network (and get the number of confirmations) by downloading just the tiny block headers and [[Wikipedia:Merkle tree|Merkle tree]] -- downloading the entire block chain is unnecessary. This feature is currently not used in Bitcoin, but it will be in the future.

===== Miner=====
Computer software which is designed to repeatedly calculate hashes with the intention to create a successful block and earn coins from transaction fees and new coins created with the block itself. The term references an analogy of gold miners who dig gold out of the ground and thus "discover" new gold that can be used to create new coins with a similar kind of discovery occurring with a successful hash to create new Bitcoins.

=====Node=====
Each Bitcoin client currently running within the network is referred to as a Node of the system.

=====Nonce=====
A nonce is an otherwise meaningless number which is used to alter the outcome of a hash. Each time Bitcoin hashes a block, it increments a nonce within the block which it is trying verify. If the numeric value of the effectively random hash is below a certain amount determined by the block generation difficulty, then the block is accepted by other clients and gets added to the chain.

=====[[Orphan Block]]=====
An orphan block is a block which has no known parent in the currently-longest [[block chain]]. Not to be confused with a [[#Stale_Block|Stale Block]] (which has a known parent, but is no longer part of the longest chain).

=====Orphan root=====
The root (first) block in an [[Orphan Block|orphan]] block chain.

=====Priority=====
A scoring mechanism to help ensure that expensive data storage isn't consumed by lower quality and spam. Low priority transactions will not get included by a miner if the limited space is already filled by higher priority transactions. A [[Transaction Fee|transaction fee]] will affect priority.

=====[[Proof of work]]=====
A result that can only be obtained through the use of computational resources. Changing the data in the proof of work requires redoing the work.

=====Reorganize=====
A block chain reorganize (or '''reorg''') happens when one chain becomes longer than the one you are currently working on. All of the blocks in the old chain that are not in the new one become orphan blocks, and their generations are invalidated. Transactions that use the newly-invalid generated coins also become invalid, though this is only possible in large chain splits because generations can't be spent for 100 blocks. The number of confirmations for transactions may change after a reorg, and transactions that are not in the new chain will become "0/unconfirmed" again. If a transaction in the old chain conflicts with one in the new chain (as a result of double-spending), the old one becomes invalid.

=====Satoshi=====
The base unit of Bitcoin (0.00000001 BTC) is sometimes called a Satoshi, after Bitcoin's creator [[Satoshi Nakamoto]].

=====Seed Nodes=====
Nodes whose IP addresses are included in the [[Original Bitcoin client|Bitcoin client]] for use during a new installation when the normal bootstrapping process through IRC wasn't possible.

=====Stale Block=====
A well-formed block which is no longer part of the difficultywise-longest and well-formed blockchain. Not to be confused with an [[#Orphan_Block|Orphan Block]] (which has no known parent in the longest [[block chain]]).

=====Subsidy=====
See "[[#Block_Reward|Block Reward]]" above.

=====Super Nodes=====
A participant in a p2p network which connects to as many other nodes as possible.

=====[[Tonal Bitcoin]]=====
Adaptation of Bitcoin to the [http://en.wikipedia.org/wiki/John_W._Nystrom#Tonal_System_.28Hexadecimal.29 Tonal System]. 1 TBC is defined as 1,0000 (65,536 decimal) base bitcoin units. Not widely used.

=====[[Transaction Fee]]=====
A voluntary fee which can be added to a transaction which is used as an incentive to add the bitcoin transaction to a block. The fee determines the likelihood of inclusion in any given block, where a high fee included with a transaction has a priority over transactions with a lower fee included or no fee at all.

=====Virgin bitcoin=====
The reward for generating a [[Block|block]] that has not yet been spent, a state which might increase the ability to transact [[anonymity|anonymously]].

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

{{Bitcoin Core documentation}}

Nuclear war and Bitcoin

2018-04-14T04:25:24Z

Theymos:

A nuclear war would be problematic for Bitcoin in several ways, though maybe it would not be the end of the world.__NOTOC__

===Attack scope===

It is first necessary to consider the scope of a nuclear attack. Some possibilities are:

* Usage of tactical nuclear weapons, which are mainly just large bombs
* A targeted attack on a few cities, which will destroy those cities, but might not have much ''direct'' wider impact.
* An EMP-focused attack, in which a small number of nuclear weapons are detonated at high altitude in order to destroy a very large amount of electronic equipment.
* All-out war, in which the belligerent countries empty their reserves of nuclear weapons, and most primary and secondary targets within non-neutral countries are destroyed

A lot of people think that everyone is just going to quickly die in a nuclear war, and so it's no use planning for post-war scenarios. This is wrong; in most of the scenarios listed above, the vast majority of people would not be directly harmed at all by the war. Even in the worst-case all-out-war scenario, probably at least half of the affected populations would survive the blast and immediate radiation, and could potentially live long lives if they take the correct actions in the aftermath to avoid excessive fallout exposure.

===Bitcoin's reliance on the Internet===

For Bitcoin to function:

# All miners have to be connected in such a way that there is low latency between them. Miners that can't connect to the majority of mining power over a low-latency connection cannot mine.
# Anyone wishing to transact must be able to connect to the same Internet that the majority of miners are using ''at some point''. There are no latency requirements for sending or receiving transactions.

Many nuclear scenarios could damage cables and backbone routers, segmenting parts of the Internet. In this case, it would be necessary for people wishing to transact to find some way of communicating with the single segment containing the most mining power, such as by using satellite communication, dial-up connections, or even by writing transactions down on paper and moving them physically. This would make Bitcoin more cumbersome to use -- perhaps too cumbersome to be realistic during or immediately after a nuclear war --, but still usable.

A likely scenario is that Bitcoin would become frozen and practically unusable - but not destroyed - until the Internet was restored to roughly its former capabilities.

===Destruction of mining hardware===

If a large amount of mining hardware is destroyed either directly by a nuclear blast or by an EMP, [[difficulty]] could get stuck at a too-high level for an extended period of time. The correct response to this is to [[hardfork]] to a lower difficulty.

===Effects of EMPs===

When detonated, nuclear bombs release electromagnetic pulses (EMPs), which are harmful to electronic equipment. A nuclear bomb meant to destroy a ground target will only affect nearby areas with an EMP, but a mere handful of nuclear bombs detonated in the air at strategic points could cause an entire continent to be affected by EMPs.

EMPs are not dangerous to humans, but they have the following effects on electronics:

* Anything connected to the power grid will be affected as if struck by lightning, but surge protectors will probably not provide protection.
* All semiconductors are likely to be destroyed. This includes CPUs and SSDs. Small semiconductors that are not connected to anything at the time of the EMP (eg. disconnected USB flash drives) ''may'' survive. The larger the item and connected wires/metal, the more it acts as an antenna for the EMP.
* Magnetic hard drives should preserve their data, though their controller chips are semiconductors which will probably be destroyed by the EMP. So they will probably require manual repairs before being operational post-EMP
* CDs/DVDs/BDs will be unaffected, as will paper.

An EMP strike could conceivably destroy almost all of a country's, continent's, or the entire world's computers. Bitcoin requires computers to function, so a widespread EMP strike would prevent Bitcoin from functioning in the affected areas until the destroyed computers could be replaced. Even if the entire world was affected, Bitcoin would be frozen with its pre-EMP ledger, not destroyed.

An EMP strike could also destroy private keys. You should have backups of your private keys (or mnemonic) on paper or CD/DVD/BD, which are immune to EMPs.

The Bitcoin block chain is so widely distributed that someone will undoubtedly have a safe copy of it somewhere.

[[Category:Technical]]

Nuclear war and Bitcoin

2018-04-14T04:15:47Z

Theymos:

A nuclear war would be problematic for Bitcoin in several ways, though maybe it would not be the end of the world.

===Attack scope===

It is first necessary to consider the scope of a nuclear attack. Some possibilities are:

* Usage of tactical nuclear weapons, which are mainly just large bombs
* A targeted attack on a few cities, which will destroy those cities, but might not have much ''direct'' wider impact.
* An EMP-focused attack, in which a small number of nuclear weapons are detonated at high altitude in order to destroy a very large amount of electronic equipment.
* All-out war, in which the belligerent countries empty their reserves of nuclear weapons, and most primary and secondary targets within non-neutral countries are destroyed

A lot of people think that everyone is just going to quickly die in a nuclear war, and so it's no use planning for post-war scenarios. This is wrong; in most of the scenarios listed above, the vast majority of people would not be directly harmed at all by the war. Even in the worst-case all-out-war scenario, probably at least half of the affected populations would survive the blast and immediate radiation, and could potentially live long lives if they take the correct actions in the aftermath to avoid excessive fallout exposure.

===Bitcoin's reliance on the Internet===

For Bitcoin to function:

# All miners have to be connected in such a way that there is low latency between them. Miners that can't connect to the majority of mining power over a low-latency connection cannot mine.
# Anyone wishing to transact must be able to connect to the same Internet that the majority of miners are using ''at some point''. There are no latency requirements for sending or receiving transactions.

Many nuclear scenarios could damage cables and backbone routers, segmenting parts of the Internet. In this case, it would be necessary for people wishing to transact to find some way of communicating with the single segment containing the most mining power, such as by using satellite communication, dial-up connections, or even by writing transactions down on paper and moving them physically. This would make Bitcoin more cumbersome to use -- perhaps too cumbersome to be realistic during or immediately after a nuclear war --, but still usable.

A likely scenario is that Bitcoin would become frozen and practically unusable - but not destroyed - until the Internet was restored to roughly its former capabilities.

===Destruction of mining hardware===

If a large amount of mining hardware is destroyed either directly by a nuclear blast or by an EMP, [[difficulty]] could get stuck at a too-high level for an extended period of time. The correct response to this is to [[hardfork]] to a lower difficulty.

===Effects of EMPs===

When detonated, nuclear bombs release electromagnetic pulses (EMPs), which are harmful to electronic equipment. A nuclear bomb meant to destroy a ground target will only affect nearby areas with an EMP, but a mere handful of nuclear bombs detonated in the air at strategic points could cause an entire continent to be affected by EMPs.

EMPs are not dangerous to humans, but they have the following effects on electronics:

* Anything connected to the power grid will be affected as if struck by lightning, but surge protectors will probably not provide protection.
* All semiconductors are likely to be destroyed. This includes CPUs and SSDs. Small semiconductors that are not connected to anything at the time of the EMP (eg. disconnected USB flash drives) ''may'' survive. The larger the item and connected wires/metal, the more it acts as an antenna for the EMP.
* Magnetic hard drives should preserve their data, though their controller chips are semiconductors which will probably be destroyed by the EMP. So they will probably require manual repairs before being operational post-EMP
* CDs/DVDs/BDs will be unaffected, as will paper.

An EMP strike could conceivably destroy almost all of a country's, continent's, or the entire world's computers. Bitcoin requires computers to function, so a widespread EMP strike would prevent Bitcoin from functioning in the affected areas until the destroyed computers could be replaced. Even if the entire world was affected, Bitcoin would be frozen with its pre-EMP ledger, not destroyed.

An EMP strike could also destroy private keys. You should have backups of your private keys (or mnemonic) on paper or CD/DVD/BD, which are immune to EMPs.

The Bitcoin block chain is so widely distributed that someone will undoubtedly have a safe copy of it somewhere.

[[Category:Technical]]

Nuclear war and Bitcoin

2018-04-14T04:15:12Z

Theymos:

A nuclear war would be problematic for Bitcoin in several ways, though maybe it would not be the end of the world.

===Attack scope===

It is first necessary to consider the scope of a nuclear attack. Some possibilities are:

* Usage of tactical nuclear weapons, which are mainly just large bombs
* A targeted attack on a few cities, which will destroy those cities, but might not much ''direct'' wider impact.
* An EMP-focused attack, in which a small number of nuclear weapons are detonated at high altitude in order to destroy a very large amount of electronic equipment.
* All-out war, in which the belligerent countries empty their reserves of nuclear weapons, and most primary and secondary targets within non-neutral countries are destroyed

A lot of people think that everyone is just going to quickly die in a nuclear war, and so it's no use planning for post-war scenarios. This is wrong; in most of the scenarios listed above, the vast majority of people would not be directly harmed at all by the war. Even in the worst-case all-out-war scenario, probably at least half of the affected populations would survive the blast and immediate radiation, and could potentially live long lives if they take the correct actions in the aftermath to avoid excessive fallout exposure.

===Bitcoin's reliance on the Internet===

For Bitcoin to function:

# All miners have to be connected in such a way that there is low latency between them. Miners that can't connect to the majority of mining power over a low-latency connection cannot mine.
# Anyone wishing to transact must be able to connect to the same Internet that the majority of miners are using ''at some point''. There are no latency requirements for sending or receiving transactions.

Many nuclear scenarios could damage cables and backbone routers, segmenting parts of the Internet. In this case, it would be necessary for people wishing to transact to find some way of communicating with the single segment containing the most mining power, such as by using satellite communication, dial-up connections, or even by writing transactions down on paper and moving them physically. This would make Bitcoin more cumbersome to use -- perhaps too cumbersome to be realistic during or immediately after a nuclear war --, but still usable.

A likely scenario is that Bitcoin would become frozen and practically unusable - but not destroyed - until the Internet was restored to roughly its former capabilities.

===Destruction of mining hardware===

If a large amount of mining hardware is destroyed either directly by a nuclear blast or by an EMP, [[difficulty]] could get stuck at a too-high level for an extended period of time. The correct response to this is to [[hardfork]] to a lower difficulty.

===Effects of EMPs===

When detonated, nuclear bombs release electromagnetic pulses (EMPs), which are harmful to electronic equipment. A nuclear bomb meant to destroy a ground target will only affect nearby areas with an EMP, but a mere handful of nuclear bombs detonated in the air at strategic points could cause an entire continent to be affected by EMPs.

EMPs are not dangerous to humans, but they have the following effects on electronics:

* Anything connected to the power grid will be affected as if struck by lightning, but surge protectors will probably not provide protection.
* All semiconductors are likely to be destroyed. This includes CPUs and SSDs. Small semiconductors that are not connected to anything at the time of the EMP (eg. disconnected USB flash drives) ''may'' survive. The larger the item and connected wires/metal, the more it acts as an antenna for the EMP.
* Magnetic hard drives should preserve their data, though their controller chips are semiconductors which will probably be destroyed by the EMP. So they will probably require manual repairs before being operational post-EMP
* CDs/DVDs/BDs will be unaffected, as will paper.

An EMP strike could conceivably destroy almost all of a country's, continent's, or the entire world's computers. Bitcoin requires computers to function, so a widespread EMP strike would prevent Bitcoin from functioning in the affected areas until the destroyed computers could be replaced. Even if the entire world was affected, Bitcoin would be frozen with its pre-EMP ledger, not destroyed.

An EMP strike could also destroy private keys. You should have backups of your private keys (or mnemonic) on paper or CD/DVD/BD, which are immune to EMPs.

The Bitcoin block chain is so widely distributed that someone will undoubtedly have a safe copy of it somewhere.

[[Category:Technical]]

Nuclear war and Bitcoin

2018-04-14T04:14:24Z

Theymos: Created page with "A nuclear war would be problematic in several ways for Bitcoin, though maybe not the end of the world. ===Attack scope=== It is first necessary to consider the scope of a nu..."

A nuclear war would be problematic in several ways for Bitcoin, though maybe not the end of the world.

===Attack scope===

It is first necessary to consider the scope of a nuclear attack. Some possibilities are:

* Usage of tactical nuclear weapons, which are mainly just large bombs
* A targeted attack on a few cities, which will destroy those cities, but might not much ''direct'' wider impact.
* An EMP-focused attack, in which a small number of nuclear weapons are detonated at high altitude in order to destroy a very large amount of electronic equipment.
* All-out war, in which the belligerent countries empty their reserves of nuclear weapons, and most primary and secondary targets within non-neutral countries are destroyed

A lot of people think that everyone is just going to quickly die in a nuclear war, and so it's no use planning for post-war scenarios. This is wrong; in most of the scenarios listed above, the vast majority of people would not be directly harmed at all by the war. Even in the worst-case all-out-war scenario, probably at least half of the affected populations would survive the blast and immediate radiation, and could potentially live long lives if they take the correct actions in the aftermath to avoid excessive fallout exposure.

===Bitcoin's reliance on the Internet===

For Bitcoin to function:

# All miners have to be connected in such a way that there is low latency between them. Miners that can't connect to the majority of mining power over a low-latency connection cannot mine.
# Anyone wishing to transact must be able to connect to the same Internet that the majority of miners are using ''at some point''. There are no latency requirements for sending or receiving transactions.

Many nuclear scenarios could damage cables and backbone routers, segmenting parts of the Internet. In this case, it would be necessary for people wishing to transact to find some way of communicating with the single segment containing the most mining power, such as by using satellite communication, dial-up connections, or even by writing transactions down on paper and moving them physically. This would make Bitcoin more cumbersome to use -- perhaps too cumbersome to be realistic during or immediately after a nuclear war --, but still usable.

A likely scenario is that Bitcoin would become frozen and practically unusable - but not destroyed - until the Internet was restored to roughly its former capabilities.

===Destruction of mining hardware===

If a large amount of mining hardware is destroyed either directly by a nuclear blast or by an EMP, [[difficulty]] could get stuck at a too-high level for an extended period of time. The correct response to this is to [[hardfork]] to a lower difficulty.

===Effects of EMPs===

When detonated, nuclear bombs release electromagnetic pulses (EMPs), which are harmful to electronic equipment. A nuclear bomb meant to destroy a ground target will only affect nearby areas with an EMP, but a mere handful of nuclear bombs detonated in the air at strategic points could cause an entire continent to be affected by EMPs.

EMPs are not dangerous to humans, but they have the following effects on electronics:

* Anything connected to the power grid will be affected as if struck by lightning, but surge protectors will probably not provide protection.
* All semiconductors are likely to be destroyed. This includes CPUs and SSDs. Small semiconductors that are not connected to anything at the time of the EMP (eg. disconnected USB flash drives) ''may'' survive. The larger the item and connected wires/metal, the more it acts as an antenna for the EMP.
* Magnetic hard drives should preserve their data, though their controller chips are semiconductors which will probably be destroyed by the EMP. So they will probably require manual repairs before being operational post-EMP
* CDs/DVDs/BDs will be unaffected, as will paper.

An EMP strike could conceivably destroy almost all of a country's, continent's, or the entire world's computers. Bitcoin requires computers to function, so a widespread EMP strike would prevent Bitcoin from functioning in the affected areas until the destroyed computers could be replaced. Even if the entire world was affected, Bitcoin would be frozen with its pre-EMP ledger, not destroyed.

An EMP strike could also destroy private keys. You should have backups of your private keys (or mnemonic) on paper or CD/DVD/BD, which are immune to EMPs.

The Bitcoin block chain is so widely distributed that someone will undoubtedly have a safe copy of it somewhere.

[[Category:Technical]]

Satoshi (unit)

2017-09-14T00:00:22Z

Theymos: /* Symbol */ Added my proposed symbol and organized it into a table

[[File:SatoshiUsage.png|thumb|The term "satoshi" in use on a message board]]The '''satoshi''' is currently the smallest unit of the bitcoin currency recorded on the [[block chain]].<ref name="se">[http://bitcoin.stackexchange.com/questions/114/what-is-a-satoshi What is a 'Satoshi'? - Bitcoin Stack Exchange]</ref> It is a one hundred millionth of a single bitcoin (0.00000001 BTC).<ref name="se"/> The unit has been named in collective homage to the original creator of Bitcoin, [[Satoshi Nakamoto]].<ref name="ribuck"/>

All amounts in the block chain are denominated in satoshi before being converted for display.<ref>{{cite btct|title=Why 1BTC should equal 10^8 satoshi ?|date=11 October 2014|id=819656}}</ref> The source code also uses satoshi when specifying an amount of bitcoin.<ref name="nov08"/> When displaying an extremely fine fraction of a bitcoin, as in a contemporary faucet, the amount is displayed in satoshi for readability.<ref>{{cite web|title=Do These "Free Bitcoin" Sites Work?|work=[[CryptoCoinsNews]]|author=Barnes, Samuel|date=9 April 2014|accessdate=19 August 2015|url=https://www.cryptocoinsnews.com/do-free-bitcoin-sites-work/}}</ref>

As of July 2017, 1 US cent is worth approximately 430 satoshi.

==History==
The value of a bitcoin in satoshi was decided by Satoshi Nakamoto to be 100 million no later than November 2008.<ref name="nov08">{{cite btct|id=382374|date=23 December 2013|title=Bitcoin source from November 2008.}}</ref>

On November 15, 2010, ribuck proposed that the one hundredth of a bitcoin (0.01 BTC) be called a ''Satoshi''.<ref>{{cite btct|id=369|post=22160|date=14 July 2010|title=Official Bitcoin Unicode Character?}}</ref> Four months later he instead suggested that the one hundred millionth unit be called an ''austrian'' or a ''satoshi''.<ref>{{cite btct|id=3311|post=46648|date=10 February 2011|title=More divisibility required - move the decimal point}}</ref> The name ''satoshi'' caught on, and was widely adopted thereafter.<ref name="ribuck">{{cite btct|id=407442|post=4415850|date=9 January 2014|title=How did “satoshi” become the name of the base unit?}}</ref>

==Usage==
===Plural===
Traditionally, the plural form has been simply ''satoshi'',<ref>[https://en.bitcoin.it/w/index.php?title=Help:FAQ&diff=53369&oldid=53362 Bitcoin Wiki revision by theymos]</ref> but the term ''satoshis'' is also popular. If the plural form were to follow the rules of Japanese grammar, it may be pronounced as ''satoshi'',<ref name="jj73">{{cite btct|id=289475|post=3112861|date=9 September 2013|title=satoshii}}</ref> or ''satoshisa''.<ref name="jj73"/>

===Symbol===
Satoshi is sometimes abbreviated to ''sat'' or ''s'', although no symbol has been widely adopted.

There are various proposed symbols:

{| class="wikitable"
|-
! Symbol
! Explanation
|-
| 里
| In Japanese names, this character can (rarely) be read "satoshi". It is an uncommon Chinese/Japanese character on its own, and an infrequent radical (kangxi #166). It can be seen as a radical in the common kanji 理 and 量, used in meaningful words like: 理想 (ideals), 理論 (theory), 理性 (reason), 理科 (science), and 量 (quantity). "Satoshi" is a rare reading; more commonly it is read as "ri" or "sato".
|-
| シ
| A Japanese katakana representing the syllable "shi". Note that this character is extremely common in Japanese, so it could cause confusion. Also, it can mean "death" in Japanese and Chinese.
|-
| ㋛
| As above, but circled to distinguish it from the katakana.
|-
| し
| As above, but this is the hiragana instead of the katakana. This is even more common than シ in Japanese writing, however.
|-
| サ
| A Japanese katakana representing the syllable "sa". Maybe it looks more reminiscent of a currency symbol than others. Note that this character is extremely common in Japanese, so it could cause confusion.
|}

==References==
<references/>
__NOTOC__
{{article}}
[[Category:Denominations]]
[[Category:Terms and properties named after Satoshi Nakamoto]]

Block weight

2017-08-23T05:31:20Z

Theymos:

Prior to [[SegWit]], there was a max block size of 1MB. After SegWit, the concept of max block size was removed and replaced with ''max block weight''. The current max block weight is 4MB.

===Summary: "How do I get cheaper transactions?"===

To get cheaper transactions, you have to:

# Install a SegWit-supporting wallet.
# Receive money on new SegWit addresses, which start with 3. You must generate new addresses; your old addresses will never be SegWit addresses. Note that not all addresses starting with 3 are SegWit addresses, and it is impossible to tell just from looking at an address whether it is a SegWit address.
# Whenever you ''spend BTC which you have received via SegWit addresses'', you will receive the SegWit discount. If you send a transaction spending some BTC received via non-SegWit addresses and some BTC received via SegWit addresses, you will receive a partial discount. The destination address doesn't matter.

There are no compatibility issues: non-SegWit wallets can send BTC to SegWit addresses, and SegWit wallets can send BTC to non-SegWit addresses.

===Definition of block weight===

Normally, each byte in a transaction counts as 4 bytes of block weight. However, if a byte is part of the SegWit witness area, then it receives a ''discount'', and only counts as 1 byte of block weight.

For example, let's say that you've previously received some BTC to SegWit address A, and some BTC to legacy address B. Now consider a transaction sending both of these amounts to some address C. The data unrelated to the transaction inputs are always non-witness data counted as 4 bytes/byte. In particular, address C doesn't matter, and can be SegWit, non-SegWit, or anything. The witness data related to address A will go in the SegWit witness area, and will be be counted as 1 byte/byte. The witness data related to address B is non-SegWit, and so will be counted as 4 bytes/byte.

"Witness data" is more-or-less the data that would go in a legacy transaction's [[Transactions|scriptSig]].

===Conversion to real sizes===

It is a common misconception that SegWit somehow makes transactions smaller, but this is incorrect. A 300-byte transaction is 300 bytes on-disk and on-wire. SegWit just ''counts'' those bytes differently toward the 4MB weight limit.

The maximum size of a block is nearly equal to the max block weight, so currently 4MB. This is not somehow "made-up" size; the maximum block is '''really''' 4MB on-disk and on-wire. However, this maximum can only be reached if the block is full of very weird transactions, so it should not usually be seen.

The ''typical'' size of a block depends on the make-up of transactions in that block. As of 2017, the average transaction make-up would lead to about 2.3MB typical blocks if all transactions were SegWit transactions.

===Detailed example===

Consider this transaction:

<pre>0100000000010115e180dc28a2327e687facc33f10f2a20da717e5548406f7ae8b4c8
11072f85603000000171600141d7cd6c75c2e86f4cbf98eaed221b30bd9a0b928ffff
ffff019caef505000000001976a9141d7cd6c75c2e86f4cbf98eaed221b30bd9a0b92
888ac02483045022100f764287d3e99b1474da9bec7f7ed236d6c81e793b20c4b5aa1
f3051b9a7daa63022016a198031d5554dbb855bdbe8534776a4be6958bd8d530dc001
c32b828f6f0ab0121038262a6c6cec93c2d3ecd6c6072efea86d02ff8e3328bbd0242
b20af3425990ac00000000</pre>

{|
|-
! Data
! Description
! Raw byte count
! Type (multiplier)
! Section total weight
! Running total weight
|-
| <tt>01000000</tt>
| Version 1
| 4
| Non-witness (4x)
| 16
| 16
|-
| <tt>00</tt>
| SegWit marker
| 1
| Witness (1x)
| 1
| 17
|-
| <tt>01</tt>
| SegWit flag
| 1
| Witness (1x)
| 1
| 18
|-
| <tt>01</tt>
| Number of inputs (1)
| 1
| Non-witness (4x)
| 4
| 22
|-
| <tt>15..56</tt>
| Previous output hash
| 32
| Non-witness (4x)
| 128
| 150
|-
| <tt>03000000</tt>
| Previous output index (3)
| 4
| Non-witness (4x)
| 16
| 166
|-
|<tt>17</tt>
| Script length (23 bytes)
| 1
| Non-witness (4x)
| 4
| 170
|-
|<tt>16..28</tt>
| Script: P2SH-enclosed P2WPKH witness program
| 23
| Non-witness (4x)
| 92
| 262
|-
|<tt>ffffffff</tt>
| Sequence
| 4
| Non-witness (4x)
| 16
| 278
|-
|<tt>01</tt>
| Output count (1)
| 1
| Non-witness (4x)
| 4
| 282
|-
|<tt>9caef50500000000</tt>
| Output value (0.99987100 BTC)
| 8
| Non-witness (4x)
| 32
| 314
|-
|<tt>19</tt>
| Output script size (25)
| 1
| Non-witness (4x)
| 4
| 318
|-
|<tt>76..ac</tt>
| Script: DUP HASH160 0x1d7c... EQUALVERIFY CHECKSIG
| 25
| Non-witness (4x)
| 100
| 418
|-
|<tt>02</tt>
| Number of stack items for input 0 (2)
| 1
| Witness (1x)
| 1
| 419
|-
|<tt>48</tt>
| Size of stack item 0 (72)
| 1
| Witness (1x)
| 1
| 420
|-
|<tt>304...ab01</tt>
| Stack item 0, signature
| 72
| Witness (1x)
| 72
| 492
|-
|<tt>21</tt>
| Size of stack item 1 (33)
| 1
| Witness (1x)
| 1
| 493
|-
|<tt>03..ac</tt>
| Stack item 1, pubkey
| 33
| Witness (1x)
| 33
| 526
|-
|<tt>00000000</tt>
| Locktime (0)
| 4
| Non-witness (4x)
| 16
| 542
|}

The transaction's '''real size on disk and over the network''' is 218 bytes, the size in bytes of the whole transaction expressed above in hexadecimal. The weight is always greater than the real size, in this case 542 bytes.

It is not possible to create exactly-equivalent legacy transactions for SegWit transactions. If BTC is sent to a SegWit address, then it must be spent in a SegWit input. However, for comparison, a similar 1-input, 1-output legacy transaction would be about 191 bytes. The legacy transaction would consume 0.0191% of a 1MB legacy block, while this transaction consumes 0.0136% of a SegWit block, a reduction of 34%. Different transaction types can have much greater reductions.

You may notice that the transaction size has increased a little -- 218 bytes vs 191 bytes -- but most/all of the overhead is redundant data which could be removed. For example, if you have the witness, then you can compute the 23-byte P2SH script. If necessary, this data could be removed before transmitting the transactions: this would be a change to the P2P protocol which wouldn't even require a softfork.

[[Category:Technical]]

Block weight

2017-08-23T05:11:24Z

Theymos: /* Detailed example */

Prior to [[SegWit]], there was a max block size of 1MB. After SegWit, the concept of max block size was removed and replaced with ''max block weight''. The current max block weight is 4MB.

===Definition of block weight===

Normally, each byte in a transaction counts as 4 bytes of block weight. However, if a byte is part of the SegWit witness area, then it receives a ''discount'', and only counts as 1 byte of block weight.

For example, let's say that you've previously received 0.5 BTC to SegWit address A, and 0.5 BTC to legacy address B. Now consider a transaction sending both of these amounts to some address C. The data unrelated to the transaction inputs are always non-witness data counted as 4 bytes/byte. In particular, address C doesn't matter, and can be SegWit, non-SegWit, or anything. The input data related to address A will, except for a constant amount of overhead, be witness data counted as 1 byte/byte. The input data related to address B is non-SegWit, and so will be counted as 4 bytes/byte. When we say "input data", we primarily mean the signatures and public keys in the [[Transactions|scriptSig]].

===Conversion to real sizes===

It is a common misconception that SegWit somehow makes transactions smaller, but this is incorrect. A 300-byte transaction is 300 bytes on-disk and on-wire. SegWit just ''counts'' those bytes differently toward the 4MB weight limit.

The maximum size of a block is nearly equal to the max block weight, so currently 4MB. This is not somehow "made-up" size; the maximum block is '''really''' 4MB on-disk and on-wire. However, this maximum should not usually be reached.

The ''typical'' size of a block depends on the make-up of transactions in that block. As of 2017, the average transaction make-up would lead to about 2.3MB typical blocks if all transactions were SegWit transactions.

===Detailed example===

Consider this transaction:

<pre>0100000000010115e180dc28a2327e687facc33f10f2a20da717e5548406f7ae8b4c8
11072f85603000000171600141d7cd6c75c2e86f4cbf98eaed221b30bd9a0b928ffff
ffff019caef505000000001976a9141d7cd6c75c2e86f4cbf98eaed221b30bd9a0b92
888ac02483045022100f764287d3e99b1474da9bec7f7ed236d6c81e793b20c4b5aa1
f3051b9a7daa63022016a198031d5554dbb855bdbe8534776a4be6958bd8d530dc001
c32b828f6f0ab0121038262a6c6cec93c2d3ecd6c6072efea86d02ff8e3328bbd0242
b20af3425990ac00000000</pre>

{|
|-
! Data
! Description
! Raw byte count
! Type (multiplier)
! Section total weight
! Running total weight
|-
| <tt>01000000</tt>
| Version 1
| 4
| Non-witness (4x)
| 16
| 16
|-
| <tt>00</tt>
| SegWit marker
| 1
| Witness (1x)
| 1
| 17
|-
| <tt>01</tt>
| SegWit flag
| 1
| Witness (1x)
| 1
| 18
|-
| <tt>01</tt>
| Number of inputs (1)
| 1
| Non-witness (4x)
| 4
| 22
|-
| <tt>15..56</tt>
| Previous output hash
| 32
| Non-witness (4x)
| 128
| 150
|-
| <tt>03000000</tt>
| Previous output index (3)
| 4
| Non-witness (4x)
| 16
| 166
|-
|<tt>17</tt>
| Script length (23 bytes)
| 1
| Non-witness (4x)
| 4
| 170
|-
|<tt>16..28</tt>
| Script: P2SH-enclosed P2WPKH witness program
| 23
| Non-witness (4x)
| 92
| 262
|-
|<tt>ffffffff</tt>
| Sequence
| 4
| Non-witness (4x)
| 16
| 278
|-
|<tt>01</tt>
| Output count (1)
| 1
| Non-witness (4x)
| 4
| 282
|-
|<tt>9caef50500000000</tt>
| Output value (0.99987100 BTC)
| 8
| Non-witness (4x)
| 32
| 314
|-
|<tt>19</tt>
| Output script size (25)
| 1
| Non-witness (4x)
| 4
| 318
|-
|<tt>76..ac</tt>
| Script: DUP HASH160 0x1d7c... EQUALVERIFY CHECKSIG
| 25
| Non-witness (4x)
| 100
| 418
|-
|<tt>02</tt>
| Number of stack items for input 0 (2)
| 1
| Witness (1x)
| 1
| 419
|-
|<tt>48</tt>
| Size of stack item 0 (72)
| 1
| Witness (1x)
| 1
| 420
|-
|<tt>304...ab01</tt>
| Stack item 0, signature
| 72
| Witness (1x)
| 72
| 492
|-
|<tt>21</tt>
| Size of stack item 1 (33)
| 1
| Witness (1x)
| 1
| 493
|-
|<tt>03..ac</tt>
| Stack item 1, pubkey
| 33
| Witness (1x)
| 33
| 526
|-
|<tt>00000000</tt>
| Locktime (0)
| 4
| Non-witness (4x)
| 16
| 542
|}

The transaction's '''real size on disk and over the network''' is 218 bytes, the size in bytes of the whole transaction expressed above in hexadecimal. The weight is always greater than the real size, in this case 542 bytes.

It is not possible to create exactly-equivalent legacy transactions for SegWit transactions. If BTC is sent to a SegWit address, then it must be spent in a SegWit input. However, for comparison, a similar 1-input, 1-output legacy transaction would be about 191 bytes. The legacy transaction would consume 0.0191% of a 1MB legacy block, while this transaction consumes 0.0136% of a SegWit block, a reduction of 34%. Different transaction types can have much greater reductions.

You may notice that the transaction size has increased a little -- 218 bytes vs 191 bytes -- but most/all of the overhead is redundant data which could be removed. For example, if you have the witness, then you can compute the 23-byte P2SH script. If necessary, this data could be removed before transmitting the transactions: this would be a change to the P2P protocol which wouldn't even require a softfork.

[[Category:Technical]]

Block weight

2017-08-23T04:58:43Z

Theymos: Created page with "Prior to SegWit, there was a max block size of 1MB. After SegWit, the concept of max block size was removed and replaced with ''max block weight''. The current max block w..."

Prior to [[SegWit]], there was a max block size of 1MB. After SegWit, the concept of max block size was removed and replaced with ''max block weight''. The current max block weight is 4MB.

===Definition of block weight===

Normally, each byte in a transaction counts as 4 bytes of block weight. However, if a byte is part of the SegWit witness area, then it receives a ''discount'', and only counts as 1 byte of block weight.

For example, let's say that you've previously received 0.5 BTC to SegWit address A, and 0.5 BTC to legacy address B. Now consider a transaction sending both of these amounts to some address C. The data unrelated to the transaction inputs are always non-witness data counted as 4 bytes/byte. In particular, address C doesn't matter, and can be SegWit, non-SegWit, or anything. The input data related to address A will, except for a constant amount of overhead, be witness data counted as 1 byte/byte. The input data related to address B is non-SegWit, and so will be counted as 4 bytes/byte. When we say "input data", we primarily mean the signatures and public keys in the [[Transactions|scriptSig]].

===Conversion to real sizes===

It is a common misconception that SegWit somehow makes transactions smaller, but this is incorrect. A 300-byte transaction is 300 bytes on-disk and on-wire. SegWit just ''counts'' those bytes differently toward the 4MB weight limit.

The maximum size of a block is nearly equal to the max block weight, so currently 4MB. This is not somehow "made-up" size; the maximum block is '''really''' 4MB on-disk and on-wire. However, this maximum should not usually be reached.

The ''typical'' size of a block depends on the make-up of transactions in that block. As of 2017, the average transaction make-up would lead to about 2.3MB typical blocks if all transactions were SegWit transactions.

===Detailed example===

Consider this transaction:

<pre>0100000000010115e180dc28a2327e687facc33f10f2a20da717e5548406f7ae8b4c8
11072f85603000000171600141d7cd6c75c2e86f4cbf98eaed221b30bd9a0b928ffff
ffff019caef505000000001976a9141d7cd6c75c2e86f4cbf98eaed221b30bd9a0b92
888ac02483045022100f764287d3e99b1474da9bec7f7ed236d6c81e793b20c4b5aa1
f3051b9a7daa63022016a198031d5554dbb855bdbe8534776a4be6958bd8d530dc001
c32b828f6f0ab0121038262a6c6cec93c2d3ecd6c6072efea86d02ff8e3328bbd0242
b20af3425990ac00000000</pre>

{|
|-
! Data
! Description
! Raw byte count
! Type (multiplier)
! Section total weight
! Running total weight
|-
| <tt>01000000</tt>
| Version 1
| 4
| Non-witness (4x)
| 16
| 16
|-
| <tt>00</tt>
| SegWit marker
| 1
| Witness (1x)
| 1
| 17
|-
| <tt>01</tt>
| SegWit flag
| 1
| Witness (1x)
| 1
| 18
|-
| <tt>01</tt>
| Number of inputs (1)
| 1
| Non-witness (4x)
| 4
| 22
|-
| <tt>15..56</tt>
| Previous output hash
| 32
| Non-witness (4x)
| 128
| 150
|-
| <tt>03000000</tt>
| Previous output index (3)
| 4
| Non-witness (4x)
| 16
| 166
|-
|<tt>17</tt>
| Script length (23 bytes)
| 1
| Non-witness (4x)
| 4
| 170
|-
|<tt>16..28</tt>
| Script: P2SH-enclosed P2WPKH witness program
| 23
| Non-witness (4x)
| 92
| 262
|-
|<tt>ffffffff</tt>
| Sequence
| 4
| Non-witness (4x)
| 16
| 278
|-
|<tt>01</tt>
| Output count (1)
| 1
| Non-witness (4x)
| 4
| 282
|-
|<tt>9caef50500000000</tt>
| Output value (0.99987100 BTC)
| 8
| Non-witness (4x)
| 32
| 314
|-
|<tt>19</tt>
| Output script size (25)
| 1
| Non-witness (4x)
| 4
| 318
|-
|<tt>76..ac</tt>
| Script: DUP HASH160 0x1d7c... EQUALVERIFY CHECKSIG
| 25
| Non-witness (4x)
| 100
| 418
|-
|<tt>02</tt>
| Number of stack items for input 0 (2)
| 1
| Witness (1x)
| 1
| 419
|-
|<tt>48</tt>
| Size of stack item 0 (72)
| 1
| Witness (1x)
| 1
| 420
|-
|<tt>304...ab01</tt>
| Stack item 0, signature
| 72
| Witness (1x)
| 72
| 492
|-
|<tt>21</tt>
| Size of stack item 1 (33)
| 1
| Witness (1x)
| 1
| 493
|-
|<tt>03..ac</tt>
| Stack item 1, pubkey
| 33
| Witness (1x)
| 33
| 526
|-
|<tt>00000000</tt>
| Locktime (0)
| 4
| Non-witness (4x)
| 16
| 542
|}

The transaction's '''real size on disk and over the network''' is 218 bytes, the size in bytes of the whole transaction expressed above in hexadecimal. The weight is always greater than the real size, in this case 542 bytes.

It is not possible to create exactly-equivalent legacy transactions for SegWit transactions. If BTC is sent to a SegWit address, then it must be spent in a SegWit input. However, for comparison, a similar 1-input, 1-output legacy transaction would be about 191 bytes. The legacy transaction would consume 0.0191% of a 1MB legacy block, while this transaction consumes 0.0136% of a SegWit block, a reduction of 34%.

You may notice that the transaction size has increased a little -- 218 bytes vs 191 bytes -- but most/all of the overhead is redundant data which could be removed. For example, if you have the witness, then you can compute the 23-byte P2SH script. If necessary, this data could be removed before transmitting the transactions: this would be a change to the P2P protocol which wouldn't even require a softfork.

[[Category:Technical]]