Bitcoin Wiki - User contributions [en]

Template:BTC

2019-06-08T09:48:51Z

Taras: Undo revision 62013 by 934 (talk) - it looks like this template has broken

₿

SegWit2x

2018-01-02T10:31:28Z

Taras:

:''Not to be confused with [[Segregated Witness|SegWit]].'' 
'''SegWit2x''', (abbreviated '''B2X''' or '''S2X''', and originally called '''SegWit2Mb'''), was a failed contentious hardfork outlined in the [[New York Agreement]] that intended to double the block size limit. The hardfork has been denounced as an attempt made by CEOs and owners of large Bitcoin businesses to introduce changes to the currency's protocol and development cycle with ulterior motives.<ref>{{cite web|url=https://www.forbes.com/sites/ktorpey/2017/10/31/is-bitcoin-facing-a-corporate-takeover-via-the-2x-fork-a-developer-and-a-business-leader-debate/#11a821363bff|title=Is Bitcoin Facing A Corporate Takeover Via The '2x' Fork? A Developer And A Business Leader Debate|work=Forbes|author=Torpey, Kyle|date=October 31, 2017|accessdate=November 29, 2017}}</ref>

Though over 80% of miners signaled intention for SegWit2x and the New York Agreement, it failed to gain any consensus among the community and Core developers. As it became clear that the execution of the fork would lead to a currency split, the address format was deliberately kept identical and no replay protection was implemented, which would have caused many BTC users to inadvertently use B2X. Additionally, code changes were made that allowed B2X nodes to pretend to be BTC nodes in order to connect and use P2P peers from the bitcoin network when synchronizing. Due to these qualities, many users considered B2X to be an outright attack on the bitcoin network, but its designers continued marketing it as an upgrade.

== Cancellation and aftermath ==
The SegWit2x hardfork was declared cancelled in a joint statement by six individuals.<ref>{{cite web|url=https://lists.linuxfoundation.org/pipermail/bitcoin-segwit2x/2017-November/000685.html|title=Segwit2x Final Steps|author=Belsche, Mike et al.|date=November 8, 2017}}</ref> In the following hours, the price of B2X futures (called BT2 on [[Bitfinex]]) dropped to 1% of the price of [[Bitcoin]] (BTC, called BT1 as a Bitfinex future).

Despite the cancellation, some parties intended to proceed with the hard fork.<ref>{{cite web|url=https://www.cryptocoinsnews.com/mysterious-group-bitpico-threatens-to-execute-segwit2x-hard-fork/|title=Mysterious Group BitPico Threatens to Execute the Bitcoin Hard Fork|work=Cryptocoins News|author=Wilmoth, Josiah|date=November 11, 2017|accessdate=November 29, 2017}}</ref> However, when the SegWit2x nodes split from the rest of the network on November 17, it was found that they had done so one block earlier than anticipated, at block 494782.<ref name="cd">{{cite web|url=https://www.coindesk.com/no-fork-no-fire-segwit2x-nodes-stall-running-abandoned-bitcoin-code/|title=No Fork, No Fire: Segwit2x Nodes Stall Running Abandoned Bitcoin Code|work=[[CoinDesk]]|author=Higgins, Stan|date=November 17, 2017|accessdate=November 29, 2017}}</ref> This was due to an [[wikipedia:off-by-one error|off-by-one error]] as a result of counting up from the [[genesis block]] instead of from block 1. After splitting off, SegWit2x nodes were then waiting for the first block of >1MB to begin the chain fork. But the protocol rules say that the block size increase does not occur until block 494784, so because block 494783 is both required to be at most 1 MB by the original rules and greater than 1 MB by the new rules,{{citation needed}} SegWit2x had come to a permanent standstill.<ref name="cd"/>

== References ==
<references/>

[[Category:Block size limit controversy]]
[[Category:Direct code forks of Bitcoin Core]]
[[Category:Failed hardforks]]
[[Category:Contentious hardforks]]

Talk:List of Bitcoin splits

2017-12-31T21:22:45Z

Taras:

__FORCETOC__

== Titling this page ==

In reply to the edit log on creation: “Temporary title used - anyone have a better idea?”

The word “splits” may confuse users who are familiar with the stock markets. It is a neutral, or even positive word; moreover, this makes it sound as if Bitcoin itself has split, with each holder of Bitcoin receiving a multiplier of bitcoins upon their previous balance. In the event of a stock split, the value held does not change; and the split stocks are fully equal and interchangeable with each other. Of course, these concepts are all wholly incorrect in application to these Bitcoin forks. Holders of Bitcoin ''may'' receive fork coins commensurate to their bitcoin balances.

”List of Bitcoin clones” might be better. Or “contentious hardforks”. Or “scams”, though that’s too general for a page title. “Fork” seeks to be the word in most common use, thus most likely the title which would be found by those seeking information; though this word is also overloaded, and has its own problems.

I think it is most important that the title must convey that the split/cloned/forked coins ''are not Bitcoin'', and not interchangeable with bitcoins. (Try sending Bitcoin to a BCH address for proof.)

[[User:Nullius|Nullius]] ([[User talk:Nullius|talk]]) 19:43, 30 December 2017 (UTC)

: Since everyone seems to be calling them forks right now, leading to confusion with code forks, chain forks, soft forks, hard forks, and dinner forks, what if we just make something up and hope it catches on? Like, branch-offs, or disbursements, or something. I do think that these "splits" should be classified separately from hard forks/chain forks, given both them and the original chain have, since the split, created spendable coinbases. [[User:Taras|Taras]] ([[User talk:Taras|talk]]) 21:22, 31 December 2017 (UTC)

For the name I suggest "list of bitcoin airdrops". "Splits" implies that bitcoin itself was somehow harmed.
[[User:Belcher|Belcher]] ([[User talk:Belcher|talk]]) 01:34, 9 December 2017 (UTC)

:Bitcoin itself [https://medium.com/@lukeparker/the-trust-attack-a6241a08a9cd ''is'' harmed] by these “splits”. Whereas “airdrop” is a positive, promotional word, which plays to people’s greed for free money. That’s probably the second-worst possible way to present the matter—other than outright fraudulently implying that Bitcoin Plutonium XT With Ponies be somehow The New Bitcoin. — [[User:Nullius|Nullius]] ([[User talk:Nullius|talk]]) 19:54, 30 December 2017 (UTC)

== History of contentious hardforks ==

If there is to be such a page, it needs a reasonably complete history of all significant forks and attempted forks since ''circa'' 2015: XT, Unlimited, Classic, etc. Those new to Bitcoin usually have no knowledge of the history here. Whereas even a modicum thereof inevitably produces a sense of ''déjà vu'', for example when reading: [https://spectrum.ieee.org/tech-talk/computing/networks/the-bitcoin-for-is-a-coup “Adam Back Says the Bitcoin Fork Is a Coup”], Morgan Peck, IEEE ''Spectrum'', 19 August '''2015'''. Or any other myriad news articles, blog entries, or ml/forum flamewars from so recently as 2–3 years ago.

I may work on this sometime; but at present, it would be low on my priorities list. — [[User:Nullius|Nullius]] ([[User_talk:Nullius|talk]] | [[Special:Contributions/Nullius|contribs]]) 20:07, 30 December 2017 (UTC)

File:Intersango.png

2017-12-08T23:04:13Z

Taras:

Intersango

2017-12-08T23:00:05Z

Taras:

'''Intersango''' was an [[currency exchange|exchange]] offering multiple trading markets for trading bitcoins against multiple currencies.

The service was launched on July 6, 2011<ref>[http://forum.bitcoin.org/index.php?topic=26543.0 Intersango.com EUR exchange is now live]</ref>. The Intersango [[:Category:Open Source|open source]] software that the exchange runs on was announced on March 17, 2011<ref>[https://bitcointalk.org/index.php?topic=4579.0 Free Bitcoin exchange software- Intersango]</ref>. In September, 2011 the exchange began using a new version of the Intersango open source exchange project with two currency markets (BTC/EUR, BTC/USD) live under the Intersango brand and plans made for the third (BTC/GBP) when [[Britcoin]] accounts are migrated at a future date.

On October 9, 2012, the exchange announced imminent plans to shutter its BTC/USD market. On December 19, 2012, the exchange closed its BTC/GBP market after being unable to re-establish a UK banking relationship<ref>[http://bitcointalk.org/index.php?topic=63877.msg1409989#msg1409989 Intersango Exchange (Closed BTC/GBP)]</ref>.

==See Also==

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

==External Links==

* [https://intersango.com Intersango] EUR exchange website
* [http://gitorious.org/intersango Intersango] exchange project on Gitorious

==References==
<references/>

[[Category:Defunct exchanges]]
[[Category:eWallets]]
[[Category:Offline]]

List of Bitcoin splits

2017-12-07T08:08:08Z

Taras: Temporary title used - anyone have a better idea?

This page exists as a reference for [[altcoin]]s that have branched off from Bitcoin's network either through a controlled release or a contentious hardfork. The altcoins in this list are available to be claimed and sold by Bitcoin holders who had BTC at the time of the split, which can be sold as a sort of "dividend".

This list is intended to inform bitcoin holders of the existence of currency splits and makes no guarantees about the intentions of altcoin developers. Do not trust unaudited wallet software with your private keys.

{| class="wikitable sortable"
|-
! Ticker
! Currency
! Split height*
! Split date
! Ratio
! Replay protection
! New address format
|-
| CLAM
| Clams
| 300377
| 2014-05-12
| †
| {{Yes|New chain}}
| {{Yes}}
|-
| BCH
| Bitcoin Cash
| 478558
| 2017-08-01
| 1:1
| {{Yes|Sighash}}
| {{No}}
|-
| BTG
| Bitcoin Gold
| 491406
| 2017-10-24
| 1:1
| {{Yes|Sighash<ref>{{cite web|author=Edward Kelso, C.|title=Bitcoin Gold Issues Daily Updates, Adds Replay Protection|work=Bitcoin.com News|date=November 2, 2017|accessdate=December 7, 2017|url=https://news.bitcoin.com/bitcoin-gold-issues-daily-updates-adds-replay-protection/}}</ref>}}
| {{Yes}}
|-
| BCD
| Bitcoin Diamond
| 495865
| 2017-11-24
| 10:1
| {{Yes}}
| {{Partial|Unknown}}
|-
| BTP
| Bitcoin Platinum
| 498533
| 2017-12-12
| 1:1
| {{Yes}}
| {{No|No<ref>[https://github.com/BitcoinPlatinum/BitcoinPlatinum/commit/cdc810dda420d2f9b4b62b5b62c85c72a0874802 Use address same with Bitcoin]</ref>}}
|-
| SBTC
| Super Bitcoin
| 498888
| 2017-12-17
| 1:1‡
| {{Yes|Sighash<ref>[https://github.com/bitcoin/bitcoin/commit/33c79d10b6a7d0b48b82826d5d3192df741bdd91 1.replay-protected]</ref>}}
| {{Partial|Unknown}}
|}

<nowiki>*</nowiki> The last block on the Bitcoin chain for which like outputs appear on both chains.

† Every address receipt to non-dust unspent outputs was credited with ~4.7 CLAM.

‡ In addition to the initial distribution, the total supply of the currency was increased through premining

==References==
<references/>

Segregated Witness

2017-12-05T06:51:27Z

Taras:

{{infobox miner activated fork|title=SegWit|image=<hr style="background-color: #f9f9f9;"/>[[File:Segwit.png|256px]]<hr style="background-color: #f9f9f9;"/>
|fulltitle=Segregated Witness (Consensus layer)
|bipnumber=[[BIP_0141|BIP 141]]
|purpose=Prevent unintended [[transaction malleability]]
|bit=Bit 1 "segwit"
|starttime=2016-11-15 00:00:00
|timeout=2017-11-15 00:00:00
|supermajority=95% of last 2016 block period
|lockin=Block #479708 2017-08-08 19:05:58
|activated=Block #481824 2017-08-24 01:57:37
}}'''Segregated Witness''' (abbreviated as '''SegWit''') is an implemented protocol upgrade intended to provide protection from [[transaction malleability]] and [[Block size limit controversy|increase block capacity]]. SegWit defines a new structure called a ''witness'' that is committed to blocks separately from the transaction merkle tree. This structure contains data required to check transaction validity but is not required to determine transaction effects. In particular, signatures and redeem scripts are moved into this new structure, which does not count towards the traditional [[Block size limit controversy|1 MB block size limit]]. Instead, a new ''weight'' parameter is defined, and blocks are allowed to have at most 4 million weight units (WU). A byte in the original 1 MB zone of the block weighs 4 WU, but a byte in a witness structure only weighs 1 WU, allowing blocks that are technically larger than 1 MB without a hardforking change.

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

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

==See Also==

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

Bitcoin XT

2017-12-04T23:17:34Z

Taras:

{{infobox software|logo=[[File:xt.png|256px]]|image=[[File:bitcoinxt.png|256px]]|caption=The identifying marks of an XT client
|bg=orange
|author=[[Gavin Andresen]] [[Mike Hearn]]
|website=[https://bitcoinxt.software bitcoinxt.software]
}}'''Bitcoin XT''' was a fork of [[Bitcoin Core]] created by [[Gavin Andresen]] in 2012. Originally designed to introduce alternative P2P rules,{{citation needed}} it later gained significant notoriety and support after its early adoption of [[BIP 0101|BIP 101]] in 2015, giving it importance in the [[block size limit controversy]].<ref name="ooc">{{cite web|work=[[The Neighbourhood Pool Watch]]|author=[[organofcorti]]|title=BIP101 implementation flaws|date=27 August 2015|accessdate=27 August 2015|url=http://organofcorti.blogspot.com/2015/08/bip101-implementation-flaws.html}}</ref> After Andresen's resignation from the position of [[Bitcoin Core]] maintainer, he and [[Mike Hearn]] organized Bitcoin XT to address several controversial ideas lacking the consensus required to be implemented in Bitcoin Core.<ref>{{cite web|work=Medium|title=An XT FAQ|author=[[Mike Hearn|Hearn, Mike]]|date=27 August 2015|accessdate=27 August 2015|url=https://medium.com/@octskyward/an-xt-faq-38e78aa32ff0}}</ref>

BIP 101 was implemented in Bitcoin XT on August 6, 2015<ref>[https://github.com/bitcoinxt/bitcoinxt/commit/946e3ba8c7806a66c2b834d3817ff0c986c0811b]</ref> and released on August 15.<ref>{{cite web|url=https://medium.com/@octskyward/why-is-bitcoin-forking-d647312d22c1|title=Why is Bitcoin forking? — Faith and future|author=Mike Hearn|work=Medium}}</ref> If 75% of the last 1000 blocks were observed to have particular version bits set, it would have ceased enforcing the 1 MB block size limit and also have added a few new rules. However, this threshold was never achieved and no new XT blocks are being created today.{{citation needed}}

In January 2016, BIP 101 was removed from Bitcoin XT and replaced with the one-time block size increase to 2 MB present in [[Bitcoin Classic]].<ref>https://github.com/bitcoinxt/bitcoinxt/pull/117</ref> In the year following this change, adoption of Bitcoin XT decreased dramatically, with fewer than 30 nodes remaining by January 2017.<ref name="cdns">{{cite web |url=https://coin.dance/nodes/xt |title=Bitcoin XT Nodes Summary |work=coin.dance |accessdate=7 January 2017 }}</ref> Later attempts by other codebases to increase the block size to 2 MB including Bitcoin Classic and [[SegWit2x]] have also failed.<ref name="cd">{{cite web|url=https://www.coindesk.com/no-fork-no-fire-segwit2x-nodes-stall-running-abandoned-bitcoin-code/|title=No Fork, No Fire: Segwit2x Nodes Stall Running Abandoned Bitcoin Code|work=[[CoinDesk]]|author=Higgins, Stan|date=November 17, 2017|accessdate=November 29, 2017}}</ref>

==Miners==
Miners that side with Bitcoin XT will produce blocks with a new version number.<ref name="avc">{{cite web|title=The Bitcoin XT Fork|work=AVC|author=Wilson, Fred|date=17 August 2015|accessdate=28 August 2015|url=http://avc.com/2015/08/the-bitcoin-xt-fork/}}</ref> This indicates to the rest of the network that they support XT.<ref name="avc"/> When 75% of the last 1000 blocks are new-version blocks, these miners will automatically abandon Bitcoin and begin mining on a new Bitcoin XT blockchain.<ref name="avc"/> This will begin after a waiting period of two weeks in hopes the economy in this time may force anyone who hasn't switched yet to do so.<ref name="avc"/>

Users and miners running full Bitcoin nodes will reject the XT blockchain starting with the first block that is larger than one megabyte in size, and thus be unaffected provided it fails to achieve economic consensus.

==Users and merchants==
If insufficient mining hash power runs XT to reach supermajority then nothing will happen. If enough does, XT users will follow a new blockchain and cease to be using and trading bitcoins.

==Controversy==

Later in January 2016, frustrated of his proposal being massively outvoted, Mike Hearn made a media stunt declaring on various US national and international press agencies that "Bitcoin has failed". Max Keiser defined this episode a "whining ragequit" (beginning of E855 on RT) and other members of the community pointed to an extensive account of manipulations http://gettopical.com/bitcoin/e289a9a5189008d994e80666e9038089 (unfortunately today many twitter screenshots are broken).

==See Also==
* [[BIP 0101]]
* [[Scalability FAQ]]

==References==
<references/>

[[Category:Block size limit controversy]]
[[Category:Direct code forks of Bitcoin Core]]
[[Category:Failed hardforks]]
[[Category:Contentious hardforks]]

[[Category:User Interfaces]]
[[Category:Frontends]]
[[Category:Free Software]]
[[Category:Open Source]]

Block size limit controversy

2017-12-04T22:49:50Z

Taras:

{{see also|Scalability FAQ}}
In 2010, a block size limit of 1 MB was introduced into Bitcoin by [[Satoshi Nakamoto]]. He added it as a safety measure to prevent miners from creating large spam blocks. However, the limit was not changed again before Nakamoto disappeared. As transaction volume increased with widespread Bitcoin adoption, increasing the limit became subject to heavy debate in 2015. However, most proposals involved hard forking changes. To prevent Bitcoin from temporarily or permanently splitting into separate payment networks ("altcoins"), hard forks require adoption by nearly all [[Full node#Economic_strength|economically active]] full nodes.

== Arguments in favor of increasing the blocksize ==
* More transactions per second
* Off-chain solutions are not yet ready to take off the load from the main blockchain.

== Contentions ==
* Increased blocksize will leave space for extensions like Mastercoin, Counterparty, etc.
** Neutral: Bitcoin competitors will have lower fees
** Negative: Bitcoin full nodes are forced to use more resources that don't support Bitcoin
* Small blocks eventually will require higher fees for fast confirmations.
** Positive: It will no longer be cheap to spam transactions such as Satoshi Dice bets
** Positive: Fees will not be zero. This is eventually a necessity in order to incentivize miners and secure the mining ecosystem
** Negative: Bitcoin may look unattractive to new users with high fees
** Negative: High fees may stop or reverse global adoption, investment, development, support and centralization{{clarification needed}}
** Negative: Bitcoin users pay higher fees
* A low blocksize limit encourages higher transactions fees to incentivize miners ("let a fee market develop").
** A fee market naturally develops due to miner latency regardless<ref>https://dl.dropboxusercontent.com/u/43331625/feemarket.pdf A Transaction Fee Market Exists Without a Block Size Limit</ref>
*** The relay network can be optimized so that miners don't have a stale rate increasing with latency. This should cause the fee market to once again require a block size limit to exist.

== Arguments in opposition to increasing the blocksize ==
* A hard fork requires waiting for sufficient consensus.
* Risk of catastrophic consensus failure<ref>https://www.mail-archive.com/bitcoin-development@lists.sourceforge.net/msg08276.html</ref>{{clarification needed}}
* An emergency hard fork that can achieve consensus can be deployed on a short time period if needed.<ref>[https://www.reddit.com/r/Bitcoin/comments/392m43/mike_hearn_blocksize_debate_at_the_breaking_point/cs00wdd How to raise block size in a short time], Peter Todd, Reddit /r/Bitcoin, 9 June 2015</ref>
* Orphan rate amplification, more reorgs and double-spends due to slower propagation speeds.
* European/American pools at more of a disadvantage compared to the Chinese pools{{why}}
* "Congestion" concerns can be solved with mempool improvements including transaction eviction.
* No amount of max block size would support all the world's future transactions on the main blockchain (various types of off-chain transactions are the only long-term solution)
* Fast block propagation is either not clearly viable, or (eg, IBLT) creates centralised controls.

=== Damage to decentralization ===
* Larger blocks make full nodes more expensive to operate.
* Therefore, larger blocks lead to less hashers running full nodes, which leads to centralized entities having more power, which makes Bitcoin require more trust, which weakens Bitcoins value proposition.
* Bitcoin is only useful if it is decentralized because centralization requires trust. Bitcoins value proposition is trustlessness.
* The larger the hash-rate a single miner controls, the more centralized Bitcoin becomes and the more trust using Bitcoin requires.
* Running your own full node while mining rather than giving another entity the right to your hash-power decreases the hash-rate of large miners. Those who have hash-power are able to control their own hash power if and only if they run a full node.
* Less individuals who control hash-power will run full nodes if running one becomes more expensive<ref>https://www.weusecoins.com/why-blocksize-limit-keeps-bitcoin-free-decentralized/</ref>.

==History==
On October 3, 2010, [[Jeff Garzik]] published a patch that immediately increases the block size to 7MB.<ref>{{cite btct|id=1347|title=(PATCH) increase block size limit|date=2010-10-03}}</ref> The patch had no users, but it was the earliest attempt at increasing the block size through a hardfork.
===BIP 100===
Change block size limit based on miner votes, but don't leave the range (1MB, 32MB) without a softfork or hardfork respectively.
===Bitcoin XT===
[[File:xt.png|thumb|128px|Bitcoin XT logo]]{{main|Bitcoin XT}}
Bitcoin XT was an alternative client that became notorious when it adopted BIP 101, which would direct an increase to 8 MB after both January 11, 2016 has passed and 75% of miners are in support, followed by doubling of the limit every two years with the size increasing linearly within those two year intervals.

XT failed to gain enough support to activate the hardfork, leading to Mike Hearn's resignation.
===BIP 102===
Increase to 2 MB on November 11, 2015.
===BIP 103===
Increase by 17.7% annually until 2063.
===Bitcoin Classic===
{{main|Bitcoin Classic}}
Adopt BIP 109 and hardfork to 2 MB in 2016. Dynamic max_block_size in 2017.
===Segregated Witness===
[[File:segwit.png|thumb|128px|SegWit logo]]{{main|Segregated Witness}}
Move signature data out of the 1 MB block and into a separate witness structure via a softfork, effectively raising the block capacity to 1.4 MB of transactions.

== Entities positions ==
Positions below are based on a suggested fixed block size increase to 20MiB. Positions against these larger blocks do not necessarily imply that they are against an increase in general, and may instead support a smaller and/or gradual increase.
{| class="wikitable sortable"
! Entity
! Supports Larger Blocks
! Supports Hard Fork
|-
| [[Magnr]]
| {{Yes|Yes: "We believe an immediate 2mb blocksize increase is important and urgently required to enable Bitcoin to flourish and deliver more utilitarian use to more people all across the world."}}<ref>https://github.com/bitcoinclassic/website/issues/3#issuecomment-172678154</ref>
| {{Yes|Yes: "We support the Bitcoin Classic proposal<ref>https://bitcoinclassic.com</ref>."}} - Magnr<ref>https://twitter.com/magnr/status/689227046120222721</ref>
|-
| Bitcoinpaygate
| {{No|No: "We do NOT support the blocksize increase"}}<ref>http://www.reddit.com/r/Bitcoin/comments/37y8wm/list_of_bitcoin_services_that_supportoppose/crqsnqp</ref>
|
|-
| Bitrated
| {{No}} "At this time, I oppose increasing the block size limit as per Gavin's proposal" - Nadav Ivgi (founder)<ref>https://twitter.com/shesek/status/605005384026177537</ref>
|
|-
| [[GreenAddress]]
| {{No|No: "In our mind increasing the block size like this is just pushing the problem a little further at potentially unfixable costs."}}<ref>http://www.reddit.com/r/Bitcoin/comments/35anax/list_of_bitcoin_services_that_support_increasing/cr2mq84</ref>
|
|-
| [[MPEx]]
| {{No}}<ref>http://log.bitcoin-assets.com//?date=07-01-2015#967332</ref>
|
|-
| [[Paymium]]
| {{No|No: "<nowiki>[allow]</nowiki> a sane transaction fee market to emerge, by letting the blocks actually fill-up."}} - CTO David Francois<ref>http://fr.anco.is/2015/gavineries/</ref>
|
|-
| Ethereum 
| {{Neutral|Neutral: "If <nowiki>[the niche of digital gold]</nowiki> is what Bitcoin users want, then they should keep the limit, and perhaps even decrease it. But if Bitcoin users want to be a payment system, then up it must go."}} - Vitalik Buterin (founder)<ref>http://www.reddit.com/r/ethereum/comments/380q61/i_know_this_may_not_directly_be_ethereum_related/crrofl6</ref>
|
|-
| [[F2Pool]]
| {{Neutral|Neutral: "We do support bigger blocks and sooner rather than later. But we cannot handle 20 MB blocks right now. ... I think we can accept 5MB block at most."}}<ref>http://sourceforge.net/p/bitcoin/mailman/message/34157036/],[http://sourceforge.net/p/bitcoin/mailman/message/34158911/</ref>
|
|-
| [[Armory]]
| {{Yes}} "This *is* urgent and needs to be handled right now, and I believe Gavin
has the best approach to this." - CEO Alan Reiner<ref>http://sourceforge.net/p/bitcoin/mailman/message/34093337/</ref>
|
|-
| BitcoinReminder
| {{Yes|Yes: "BitcoinReminder.com also supports 20MB blocks (or even more?"}}<ref>http://www.reddit.com/r/Bitcoin/comments/37y8wm/list_of_bitcoin_services_that_supportoppose/crs9ytd</ref>
|
|-
| BitHours
| {{Yes|Yes: "We support @gavinandresen and his proposal for 20mb blocks"}}<ref>https://twitter.com/bithours/status/605131647747358721</ref>
|
|-
| [[BitPay]]
| {{Yes}} "Agreed (but optimistic this will be the last and only time block size needs to increase)" - CEO Stephen Pair<ref>https://twitter.com/spair/status/595341090317799424</ref>
| {{Yes|Yes: "In summary, we believe BIP 101 will safeguard Bitcoin’s decentralized nature while providing a reliable, immediate path toward greater network throughput, and we would like to express our support for merging BIP 101 into Bitcoin Core."}} - Stephen Pair<ref>https://medium.com/@spair/increasing-the-block-size-limit-85ff236fc516</ref>
|-
| Bittiraha.fi
| {{Yes|Yes: "We are supporting increasing #Bitcoin max block size to 20MB."}}<ref>https://twitter.com/Bittirahafi/status/596682373028311040</ref> "I'm strongly in favor of the block size cap increase to 20MB." - CEO Henry Brade<ref>https://twitter.com/Technom4ge/status/596334370803326978</ref>
| {{Yes}} "And I'm in favor of releasing a version with this change even with opposition." - CEO Henry Brade<ref>https://twitter.com/Technom4ge/status/596334370803326978</ref>
|-
| [[Blockchain.info]]
|{{Yes}} "It is time to increase the block size. Agree with @gavinandresen" - CEO Peter Smith<ref>https://twitter.com/OneMorePeter/status/595676380320407553</ref> "Scaling #bitcoin is a big deal. Increase the block size." - Nic Cary<ref>https://twitter.com/niccary/status/595707211994763264</ref>
|
|-
| [[Blocktrail]]
|{{Yes}} "We'd love to see BIP101 with 4mb start, alternatively BIP100 with something to deal with the 21% attack could be good too."<ref>https://blog.blocktrail.com/2015/08/miners-block-size-vote-explained/</ref> 
|
|-
| Breadwallet
| {{Yes}} "[...] in support of the Gavin's 20Mb block proposal." - CEO Aaron Voisine<ref>http://sourceforge.net/p/bitcoin/mailman/message/34096857/</ref>
|
|-
| [[BTC Guild]]

| {{Yes}} "Needs to happen, but needs future expansion built in at a reasonable rate." - Eleuthria<ref>https://www.reddit.com/r/Bitcoin/comments/370rko/21_inc_engineer_everyone_assumes_humans_will_be/crjfnpg?context=3</ref>
|
|-
| BX.in.th
| {{Yes|Yes: "<nowiki>http://BX.in.th</nowiki> will support the 20MB block size"}}<ref>https://twitter.com/BitcoinThai/status/605022509101023232</ref>
|
|-
| [[Coinbase (business)|CoinBase]]
| {{Yes|Yes: "Coinbase supports increasing the maximum block size"}}<ref>https://twitter.com/coinbase/status/595741967759335426</ref> "Why we should increase the block size" - CEO Brian Armstrong<ref>https://twitter.com/brian_armstrong/status/595453245884997634</ref>
| {{Yes|Yes: "5/ hard forks probably shouldn't happen frequently, but periodically they are an elegant solution that helps bitcoin keep growing"}} - CEO Brian Armstrong<ref>https://twitter.com/brian_armstrong/status/633309671994998784</ref>
|-
| [[Coinify]]
| {{Yes}} "We see Bitcoin XT as the best solution for ensuring the future scalability of the Bitcoin network." - CTO Hamed Sattari<ref>https://news.coinify.com/coinify-supports-bitcoin-xt-scalability-bitcoin-payments/</ref>
|
|-
| [[Adam Back]]
| {{Yes|Yes: "For the record I am not aware of a single person who has said they do not agree with scaling Bitcoin. Changing a constant is not the hard-part. The hard part is validating a plan and the other factors that go into it. It's not a free choice it is a security/scalability tradeoff. No one will thank us if we "scale" bitcoin but break it in hard to recover ways at the same time."}} <ref>https://www.mail-archive.com/bitcoin-development@lists.sourceforge.net/msg08276.html</ref>
| {{No}} "I strongly urge that we return to the existing collaborative constructive review process that has been used for the last 4 years which is a consensus by design to prevent one rogue person from inserting a backdoor, or lobbying for a favoured change on behalf of a special interest group, or working for bad actor" - Dr. Adam Back<ref>https://www.mail-archive.com/bitcoin-development@lists.sourceforge.net/msg08276.html</ref>
|
|-
| Kryptoradio
| {{Yes}} "#Kryptoradio dev @zouppen supports 20MB block size in #bitcoin." - Joel Lehtonen<ref>https://twitter.com/koodilehto/status/596675967667568641</ref>
|
|-
| [[OKCoin]]
| {{Yes|Yes: "OKCoin's tech team believes it's the right decision"}}<ref>https://twitter.com/okcoinbtc/status/598412795240009728</ref>
|
|-
| [[Third Key Solutions]]
| {{Yes}} "Gavin is right. The time to increase the block size limit is before transaction processing shows congestion problems." - CTO Andreas Antonopoulos<ref>https://twitter.com/aantonop/status/595601619581964289</ref>
|
|-
| [[Xapo]]
| {{Yes|Yes: "One meg is not enough: Xapo supports increasing the maximum block size"}} - CEO Wences Casares<ref>https://twitter.com/wences/status/595768917907402752</ref>
|
|}

==References==
<references/>
[[Category:2015 events]]

Block size limit controversy

2017-12-04T22:30:58Z

Taras:

{{see also|Scalability FAQ}}
In 2010, a block size limit of 1 MB was introduced into Bitcoin by [[Satoshi Nakamoto]]. He added it as a safety measure to prevent miners from creating large spam blocks. However, the limit was not changed again before Nakamoto disappeared. As transaction volume increased with widespread Bitcoin adoption, increasing the limit became subject to heavy debate in 2015. However, most proposals involved hard forking changes. To prevent Bitcoin from temporarily or permanently splitting into separate payment networks ("altcoins"), hard forks require adoption by nearly all [[Full node#Economic_strength|economically active]] full nodes.

== Arguments in favor of increasing the blocksize ==
* More transactions per second
* Off-chain solutions are not yet ready to take off the load from the main blockchain.

== Contentions ==
* Increased blocksize will leave space for extensions like Mastercoin, Counterparty, etc.
** Neutral: Bitcoin competitors will have lower fees
** Negative: Bitcoin full nodes are forced to use more resources that don't support Bitcoin
* Small blocks eventually will require higher fees for fast confirmations.
** Positive: It will no longer be cheap to spam transactions such as Satoshi Dice bets
** Positive: Fees will not be zero. This is eventually a necessity in order to incentivize miners and secure the mining ecosystem
** Negative: Bitcoin may look unattractive to new users with high fees
** Negative: High fees may stop or reverse global adoption, investment, development, support and centralization{{clarification needed}}
** Negative: Bitcoin users pay higher fees
* A low blocksize limit encourages higher transactions fees to incentivize miners ("let a fee market develop").
** A fee market naturally develops due to miner latency regardless<ref>https://dl.dropboxusercontent.com/u/43331625/feemarket.pdf A Transaction Fee Market Exists Without a Block Size Limit</ref>
*** The relay network can be optimized so that miners don't have a stale rate increasing with latency. This should cause the fee market to once again require a block size limit to exist.

== Arguments in opposition to increasing the blocksize ==
* A hard fork requires waiting for sufficient consensus.
* Risk of catastrophic consensus failure<ref>https://www.mail-archive.com/bitcoin-development@lists.sourceforge.net/msg08276.html</ref>{{clarification needed}}
* An emergency hard fork that can achieve consensus can be deployed on a short time period if needed.<ref>[https://www.reddit.com/r/Bitcoin/comments/392m43/mike_hearn_blocksize_debate_at_the_breaking_point/cs00wdd How to raise block size in a short time], Peter Todd, Reddit /r/Bitcoin, 9 June 2015</ref>
* Orphan rate amplification, more reorgs and double-spends due to slower propagation speeds.
* European/American pools at more of a disadvantage compared to the Chinese pools{{why}}
* "Congestion" concerns can be solved with mempool improvements including transaction eviction.
* No amount of max block size would support all the world's future transactions on the main blockchain (various types of off-chain transactions are the only long-term solution)
* Fast block propagation is either not clearly viable, or (eg, IBLT) creates centralised controls.

=== Damage to decentralization ===
* Larger blocks make full nodes more expensive to operate.
* Therefore, larger blocks lead to less hashers running full nodes, which leads to centralized entities having more power, which makes Bitcoin require more trust, which weakens Bitcoins value proposition.
* Bitcoin is only useful if it is decentralized because centralization requires trust. Bitcoins value proposition is trustlessness.
* The larger the hash-rate a single miner controls, the more centralized Bitcoin becomes and the more trust using Bitcoin requires.
* Running your own full node while mining rather than giving another entity the right to your hash-power decreases the hash-rate of large miners. Those who have hash-power are able to control their own hash power if and only if they run a full node.
* Less individuals who control hash-power will run full nodes if running one becomes more expensive<ref>https://www.weusecoins.com/why-blocksize-limit-keeps-bitcoin-free-decentralized/</ref>.

==History==
On October 3, 2010, [[Jeff Garzik]] published a patch that immediately increases the block size to 7MB.<ref>{{cite btct|id=1347|title=(PATCH) increase block size limit|date=2010-10-03}}</ref> The patch had no users, but it was the earliest attempt at increasing the block size through a hardfork.
===BIP 100===
Change block size limit based on miner votes, but don't leave the range (1MB, 32MB) without a softfork or hardfork respectively.
===BIP 101===
{{seealso|Bitcoin XT}}
Increase to 8 MB after both January 11, 2016 has passed and 75% of miners are supporting. Double the limit every two years with the size increasing linearly within those two year intervals.
===BIP 102===
Increase to 2 MB on November 11, 2015.
===BIP 103===
Increase by 17.7% annually until 2063.
===BIP 109===
{{seealso|Bitcoin Classic}}
Hard Fork to 2MB in 2016. Dynamic max_block_size in 2017.
===BIP 141===
{{seealso|Segregated Witness}}
Move signature data out of the 1 MB block and into a separate witness structure via a softfork, effectively raising the block capacity to 1.4 MB of transactions.

== Entities positions ==
Positions below are based on a suggested fixed block size increase to 20MiB. Positions against these larger blocks do not necessarily imply that they are against an increase in general, and may instead support a smaller and/or gradual increase.
{| class="wikitable sortable"
! Entity
! Supports Larger Blocks
! Supports Hard Fork
|-
| [[Magnr]]
| {{Yes|Yes: "We believe an immediate 2mb blocksize increase is important and urgently required to enable Bitcoin to flourish and deliver more utilitarian use to more people all across the world."}}<ref>https://github.com/bitcoinclassic/website/issues/3#issuecomment-172678154</ref>
| {{Yes|Yes: "We support the Bitcoin Classic proposal<ref>https://bitcoinclassic.com</ref>."}} - Magnr<ref>https://twitter.com/magnr/status/689227046120222721</ref>
|-
| Bitcoinpaygate
| {{No|No: "We do NOT support the blocksize increase"}}<ref>http://www.reddit.com/r/Bitcoin/comments/37y8wm/list_of_bitcoin_services_that_supportoppose/crqsnqp</ref>
|
|-
| Bitrated
| {{No}} "At this time, I oppose increasing the block size limit as per Gavin's proposal" - Nadav Ivgi (founder)<ref>https://twitter.com/shesek/status/605005384026177537</ref>
|
|-
| [[GreenAddress]]
| {{No|No: "In our mind increasing the block size like this is just pushing the problem a little further at potentially unfixable costs."}}<ref>http://www.reddit.com/r/Bitcoin/comments/35anax/list_of_bitcoin_services_that_support_increasing/cr2mq84</ref>
|
|-
| [[MPEx]]
| {{No}}<ref>http://log.bitcoin-assets.com//?date=07-01-2015#967332</ref>
|
|-
| [[Paymium]]
| {{No|No: "<nowiki>[allow]</nowiki> a sane transaction fee market to emerge, by letting the blocks actually fill-up."}} - CTO David Francois<ref>http://fr.anco.is/2015/gavineries/</ref>
|
|-
| Ethereum 
| {{Neutral|Neutral: "If <nowiki>[the niche of digital gold]</nowiki> is what Bitcoin users want, then they should keep the limit, and perhaps even decrease it. But if Bitcoin users want to be a payment system, then up it must go."}} - Vitalik Buterin (founder)<ref>http://www.reddit.com/r/ethereum/comments/380q61/i_know_this_may_not_directly_be_ethereum_related/crrofl6</ref>
|
|-
| [[F2Pool]]
| {{Neutral|Neutral: "We do support bigger blocks and sooner rather than later. But we cannot handle 20 MB blocks right now. ... I think we can accept 5MB block at most."}}<ref>http://sourceforge.net/p/bitcoin/mailman/message/34157036/],[http://sourceforge.net/p/bitcoin/mailman/message/34158911/</ref>
|
|-
| [[Armory]]
| {{Yes}} "This *is* urgent and needs to be handled right now, and I believe Gavin
has the best approach to this." - CEO Alan Reiner<ref>http://sourceforge.net/p/bitcoin/mailman/message/34093337/</ref>
|
|-
| BitcoinReminder
| {{Yes|Yes: "BitcoinReminder.com also supports 20MB blocks (or even more?"}}<ref>http://www.reddit.com/r/Bitcoin/comments/37y8wm/list_of_bitcoin_services_that_supportoppose/crs9ytd</ref>
|
|-
| BitHours
| {{Yes|Yes: "We support @gavinandresen and his proposal for 20mb blocks"}}<ref>https://twitter.com/bithours/status/605131647747358721</ref>
|
|-
| [[BitPay]]
| {{Yes}} "Agreed (but optimistic this will be the last and only time block size needs to increase)" - CEO Stephen Pair<ref>https://twitter.com/spair/status/595341090317799424</ref>
| {{Yes|Yes: "In summary, we believe BIP 101 will safeguard Bitcoin’s decentralized nature while providing a reliable, immediate path toward greater network throughput, and we would like to express our support for merging BIP 101 into Bitcoin Core."}} - Stephen Pair<ref>https://medium.com/@spair/increasing-the-block-size-limit-85ff236fc516</ref>
|-
| Bittiraha.fi
| {{Yes|Yes: "We are supporting increasing #Bitcoin max block size to 20MB."}}<ref>https://twitter.com/Bittirahafi/status/596682373028311040</ref> "I'm strongly in favor of the block size cap increase to 20MB." - CEO Henry Brade<ref>https://twitter.com/Technom4ge/status/596334370803326978</ref>
| {{Yes}} "And I'm in favor of releasing a version with this change even with opposition." - CEO Henry Brade<ref>https://twitter.com/Technom4ge/status/596334370803326978</ref>
|-
| [[Blockchain.info]]
|{{Yes}} "It is time to increase the block size. Agree with @gavinandresen" - CEO Peter Smith<ref>https://twitter.com/OneMorePeter/status/595676380320407553</ref> "Scaling #bitcoin is a big deal. Increase the block size." - Nic Cary<ref>https://twitter.com/niccary/status/595707211994763264</ref>
|
|-
| [[Blocktrail]]
|{{Yes}} "We'd love to see BIP101 with 4mb start, alternatively BIP100 with something to deal with the 21% attack could be good too."<ref>https://blog.blocktrail.com/2015/08/miners-block-size-vote-explained/</ref> 
|
|-
| Breadwallet
| {{Yes}} "[...] in support of the Gavin's 20Mb block proposal." - CEO Aaron Voisine<ref>http://sourceforge.net/p/bitcoin/mailman/message/34096857/</ref>
|
|-
| [[BTC Guild]]

| {{Yes}} "Needs to happen, but needs future expansion built in at a reasonable rate." - Eleuthria<ref>https://www.reddit.com/r/Bitcoin/comments/370rko/21_inc_engineer_everyone_assumes_humans_will_be/crjfnpg?context=3</ref>
|
|-
| BX.in.th
| {{Yes|Yes: "<nowiki>http://BX.in.th</nowiki> will support the 20MB block size"}}<ref>https://twitter.com/BitcoinThai/status/605022509101023232</ref>
|
|-
| [[Coinbase (business)|CoinBase]]
| {{Yes|Yes: "Coinbase supports increasing the maximum block size"}}<ref>https://twitter.com/coinbase/status/595741967759335426</ref> "Why we should increase the block size" - CEO Brian Armstrong<ref>https://twitter.com/brian_armstrong/status/595453245884997634</ref>
| {{Yes|Yes: "5/ hard forks probably shouldn't happen frequently, but periodically they are an elegant solution that helps bitcoin keep growing"}} - CEO Brian Armstrong<ref>https://twitter.com/brian_armstrong/status/633309671994998784</ref>
|-
| [[Coinify]]
| {{Yes}} "We see Bitcoin XT as the best solution for ensuring the future scalability of the Bitcoin network." - CTO Hamed Sattari<ref>https://news.coinify.com/coinify-supports-bitcoin-xt-scalability-bitcoin-payments/</ref>
|
|-
| [[Adam Back]]
| {{Yes|Yes: "For the record I am not aware of a single person who has said they do not agree with scaling Bitcoin. Changing a constant is not the hard-part. The hard part is validating a plan and the other factors that go into it. It's not a free choice it is a security/scalability tradeoff. No one will thank us if we "scale" bitcoin but break it in hard to recover ways at the same time."}} <ref>https://www.mail-archive.com/bitcoin-development@lists.sourceforge.net/msg08276.html</ref>
| {{No}} "I strongly urge that we return to the existing collaborative constructive review process that has been used for the last 4 years which is a consensus by design to prevent one rogue person from inserting a backdoor, or lobbying for a favoured change on behalf of a special interest group, or working for bad actor" - Dr. Adam Back<ref>https://www.mail-archive.com/bitcoin-development@lists.sourceforge.net/msg08276.html</ref>
|
|-
| Kryptoradio
| {{Yes}} "#Kryptoradio dev @zouppen supports 20MB block size in #bitcoin." - Joel Lehtonen<ref>https://twitter.com/koodilehto/status/596675967667568641</ref>
|
|-
| [[OKCoin]]
| {{Yes|Yes: "OKCoin's tech team believes it's the right decision"}}<ref>https://twitter.com/okcoinbtc/status/598412795240009728</ref>
|
|-
| [[Third Key Solutions]]
| {{Yes}} "Gavin is right. The time to increase the block size limit is before transaction processing shows congestion problems." - CTO Andreas Antonopoulos<ref>https://twitter.com/aantonop/status/595601619581964289</ref>
|
|-
| [[Xapo]]
| {{Yes|Yes: "One meg is not enough: Xapo supports increasing the maximum block size"}} - CEO Wences Casares<ref>https://twitter.com/wences/status/595768917907402752</ref>
|
|}

==References==
<references/>
[[Category:2015 events]]

Mining Team Reddit

2017-12-04T20:02:56Z

Taras:

'''Mining Team Reddit''', shortened to '''MtRed''' or '''Mt. Red''', was a [[Pooled mining|mining pool]] for [[/r/Bitcoin]] users. This pool paid out using a proportional share reward system (your shares / total shares for the round) = % share of the rewards.

The pool was opened in May 2011<ref>[http://forum.bitcoin.org/index.php?topic=9911.0 Eu.MtRed.com - Beta Testing my Hacks on PushPool]</ref> and was later reorganized into a [[BTC Guild]] team as mining became more competitive.

==See Also==

* [[Comparison of mining pools]]
* [[Pooled Mining]]

==Exernal Links==

* [http://mtred.com/index.php?r=site/page&view=about Mining Team Reddit] pool

==References==
<references />
{{Pools}}
[[Category:Pool Operators]]

MediaWiki:Spam-blacklist

2017-12-04T05:28:44Z

Taras:

# <pre>
# External URLs matching this list will be blocked when added to a page.
# This list affects only this wiki; refer also to the global blacklist.
# For documentation see https://www.mediawiki.org/wiki/Extension:SpamBlacklist
# Syntax is as follows:
# * Everything from a "#" character to the end of the line is a comment
# * Every non-blank line is a regex fragment which will only match hosts inside URLs
# Pages under categories should be sorted alphabetically from the top-level domain down.
##################
# FRAUDULENT SITES
\bbitin\.cc\b
\bbitin\.co\b
\bbadycoin\.com\b
\bbit-mix\.com\b
\bbitcoin-fog\.com\b
\bbithashminer\.com\b
\bbitodex\.com\b
\bbitpide\.com\b
\bchain\.com\b
\bcryptovi\.com\b
\bhelix-light\.com\b
\bblockschain\.eu\b
\bcleanco\.in\b
\bbiockchan\.info\b
\bbitcoinshuffle\.info\b
\bblockchian\.info\b
\bblockckchain\.info\b
\bbloclkohain\.info\b
\bblokchains\.info\b
\bbtc-spot\.info\b
\bbtockchan\.info\b
\bbtockchain\.info\b
\bbitcoin-mixing-services\.net\b
\bblockchaim\.net\b
\bwashbit\.org\b
\bbitmixegkuerln7q\.onion\b
\bblenderi54mbtyhz\.onion\b
\bblockchatntqnf7o\.onion\b
\bbrav3bnkjnlpqicn\.onion\b
\bbraveb6iyacflzc2\.onion\b
\bbravebulzwzs5i62\.onion\b
\bbtcwashzcpqktkwt\.onion\b
\bcleancondgqja34b\.onion\b
\bfogcorevmbk2jfqv\.onion\b
\bgrams7eo7mkagczs\.onion\b
\blaundryzlzgnni4n\.onion\b
\bm2cylfgzmxwauyqz\.onion\b
\bsqxamnigeby5u37b\.onion\b
\bwashbitcom2qv6wa\.onion\b
##################
# AFFILIATE SYNTAX
\bcoinbase\.com\/\?r\=\b
\bbitvegas\.net\/\?id\=\b
##################
# ILLEGAL SERVICES
\bbraveb6xgkctts5l\.onion\b
\bsilkroad6ownowfk\.onion\b
##################
# SPAM SITES
\bsnowafter\.com\b
\bcloudroll\.io\b
\b1-888-639-4788\b
##################
# TEST
\bspamblacklisttestword\b
#</pre>

Bitdns

2017-12-03T21:48:23Z

Taras: Taras moved page Bitdns to BitDNS

#REDIRECT [[BitDNS]]

BitDNS

2017-12-03T21:48:23Z

Taras: Taras moved page Bitdns to BitDNS

Bitdns was project with the goal to extend Bitcoin's technology to a domain name service, expanding the software to support transactions for registering, updating, and transferring domains.
The project eventually became an altchain with its own altcoin, known as [http://namecoin.info/ Namecoin].

==See Also==

* [[Comparison of cryptocurrencies]]

==External Links==
* [http://bit.namecoin.info New .bit homepage]
* [http://dot-bit.org Dot-bit.org] old project website
* [https://github.com/namecoin/namecoin Namecoin on GitHub]

==References==
* [https://bitcointalk.org/?topic=6017 Namecoin - a distributed naming system based on Bitcoin]

Digital currency

2017-12-03T21:46:41Z

Taras:

A '''digital currency''' refers to money or [[wikipedia:scrip|scrip]] which is only exchanged electronically.

When money transfers occur as a bank wire transfer or ACH payment, or even transfers of money using services such as [[PayPal]], the funds are sent electronically but the currency transmitted is representative money and what transfers is an underlying fiat currency.

[[Bitcoin]] has been described as the first decentralized digital currency.

==See Also==
* [[BTConvert]]
* [[List of alternative cryptocurrencies]]
* [[:Category:Money transmitters|Money transmitters]]
* [[Redeemable code]]

==External Links==
* [http://en.wikipedia.org/wiki/Electronic_money Electronic Money] article on Wikipedia

Script

2017-11-30T04:14:42Z

Taras: Added CLTV example

Bitcoin uses a scripting system for [[transactions]]. [[Wikipedia:FORTH|Forth]]-like, '''Script''' is simple, stack-based, and processed from left to right. It is purposefully not Turing-complete, with no loops.

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 show evidence 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, 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). The party who originally ''sent'' the Bitcoins now being spent, dictates the script operations that will occur ''last'' in order to release them for use in another transaction. The party wanting to spend them must provide the input(s) to the previously recorded script that results in those operations occurring last leaving behind true (non-zero).

This document is for information purposes only. Officially Bitcoin script is defined by [https://github.com/bitcoin/bitcoin/blob/master/src/script/interpreter.cpp its reference implementation].

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.

== 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 a concern that the client might have a bug in their implementation. This fear was motivated by a bug found in OP_LSHIFT which could crash any Bitcoin node if exploited, and by other bugs in how Script worked which allowed anyone to spend anyone's bitcoins. The removed opcodes are sometimes said to be "disabled" opcodes, 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 only for historical interest.

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

False is zero or negative zero (using any number of bytes) or an empty array, and True is anything else.

=== 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.
|-
|OP_PUSHDATA4
|78
|0x4e
|(special)
|data
|The next four bytes contain the number of bytes to be pushed onto the stack.
|-
|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.
|-
|[[OP_RETURN]]
|106
|0x6a
|Nothing
|''fail''
|'''Marks transaction as invalid'''. 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 exactly one pushdata op. Such outputs are provably unspendable, reducing their cost to the network. Currently it is usually considered non-standard (though valid) for a transaction to have more than one OP_RETURN output or an OP_RETURN output with more than one pushdata op.
|}

=== 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 top three items on the stack are rotated to the left.
|-
|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.
|}

=== 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 [[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 [[BIP 0068]] with nSequence) is not equal to or longer than the value of the top stack item. The precise semantics are described in [[BIP 0112]].
|}

===Pseudo-words===
These words are used internally for assisting with transaction matching. They are invalid if used in actual scripts.
{| class="wikitable"
|-
!Word
!Opcode
!Hex
!Description
|-
|OP_PUBKEYHASH
|253
|0xfd
|Represents a public key hashed with OP_HASH160.
|-
|OP_PUBKEY
|254
|0xfe
|Represents a public key compatible with OP_CHECKSIG.
|-
|OP_INVALIDOPCODE
|255
|0xff
|Matches any opcode that is not yet assigned.
|}

=== 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 ==
This is a list of interesting scripts. Keep in mind that all constants actually use the data-pushing commands above. Note that there is a small number of standard script forms that are relayed from node to node; non-standard scripts are accepted if they are in a block, but nodes will not relay them.

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

=== Anyone-Can-Spend Outputs ===

Conversely a transaction can be made spendable by anyone at all:

scriptPubKey: (empty)
scriptSig: OP_TRUE

With some software changes such transactions can be used as a way to donate funds to miners in addition to transaction fees: any miner who mines such a transaction can also include an additional one after it sending the funds to an address they control. This mechanism may be used in the future for [[fidelity bonds]] to sacrifice funds in a provable way.

Anyone-Can-Spend outputs are currently considered non-standard, and are not relayed on the P2P network.

=== 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 was the genesis block hash. Note that while transactions like this are fun, they are not secure, because they do not contain any signatures and thus any transaction attempting to spend them can be replaced with a different transaction sending the funds somewhere else.

==See Also==

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

== External Links ==
*[https://github.com/siminchen/bitcoinIDE Bitcoin IDE]: Bitcoin Script for dummies
*[https://webbtc.com/script Bitcoin Debug Script Execution]
*[http://www.crmarsh.com/script-playground/ Script Playground] — convert Script to JavaScript
(cf. "[http://bitcoin.stackexchange.com/q/42576/4334 Online Bitcoin Script simulator or debugger?]")

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

{{Bitcoin Core documentation}}

Hardfork

2017-11-30T01:23:00Z

Taras:

A '''hardfork''' is a change to the bitcoin protocol that makes previously invalid blocks/transactions valid, and therefore requires all users to upgrade.

Any alteration to bitcoin which changes the block structure (including block hash), difficulty rules, or increases the set of valid transactions is a hardfork.
However, some of these changes can be implemented by having the new transaction appear to older clients as a pay-to-anybody transaction (of a special form), and getting the miners to agree to reject blocks including the pay-to-anybody transaction unless the transaction validates under the new rules.
This is known as a [[softfork]].

To date, Bitcoin has never deployed a hardfork, but some altcoins have.

==See Also==
* [[Softfork]]

Softfork

2017-11-30T01:13:13Z

Taras:

A '''softfork''' is a change to the bitcoin protocol wherein only previously valid blocks/transactions are made invalid.
Since old nodes will recognize the new blocks as valid, a softfork is backward-compatible.
When a majority of miners upgrade to enforce new rules, it is called a '''miner-activated softfork''' (MASF). When full nodes coordinate to enforce new rules, without support from miners, it is called a '''user-activated softfork''' (UASF).

New transaction types can often be added as softforks, requiring only that the participants (sender and receiver) and miners understand the new transaction type.
This is done by having the new transaction appear to older clients as a "pay-to-anybody" transaction (of a special form), and getting the miners to agree to reject blocks including these transaction unless the transaction validates under the new rules.
This is how [[pay to script hash]] and [[Segregated Witness]] were added to Bitcoin.

==Mechanism==

Given a set of valid blocks, you can take any subset of those blocks and that subset will also, of course, all be valid. A softfork changes the rules such that only a subset of blocks that were previously valid remain so. Often softforks make certain transactions invalid, for example a softfork could make any transaction that is more than 1KB invalid (not that that would necessarily be desirable).

Generally softforks accomplish something more useful, for example Pay-to-Script-Hash ([[P2SH]]) was a softfork. Originally the script <code>OP_HASH160 [20-byte-hash-value] OP_EQUAL</code> could be redeemed by simply pushing the preimage of the hashed value onto the stack. Now the value you push must be a script that evaluates to true. All new transactions with the script <code>OP_HASH160 [20-byte-hash-value] OP_EQUAL</code> weren't valid if they merely had a preimage of the hash pushed onto the stack, the preimage had to be a valid script. The requirement for the preimage being a valid script shrunk the set of valid transactions and added a feature at the same time.

In the P2SH example, two opcodes were redefined so they had a new function. You can also add new opcodes that originally didn't do anything. Because the new rules must cause the set of valid blocks to be a proper subset of the valid blocks with the old rules, you must ensure that adding this new opcode doesn't cause transactions that were once invalid to be valid. In [[BIP_0012|BIP12]] <code>OP_EVAL</code> was proposed. To softfork this new opcode in, the proposal stated an opcode that previously didn't have any effect would be replaced. The script would be evaluated twice, once with the opcode having the new <code>OP_EVAL</code> behavior and once with its old behavior of doing nothing. The script being run with the old behavior of doing nothing would ensure that the transaction was valid to old clients.

==Security==

In order for a softfork to work, a majority of the mining power needs to be running a client recognizing the fork. The more miners that accept the new rules, the more secure the network is post-fork. If you have 3/4 of miners recognizing the fork, 1/4 blocks created aren't guaranteed to follow the new rules. These 1/4 blocks will be valid to old nodes that aren't aware of the new rules, but they will be ignored by new nodes. This allows a "fake confirmation" vulnerability, an attacker could create a transaction paying to their victim, but have it end up in a block not following new rules, they might bribe a miner to make the block incompatible with new rules or make the transaction itself incompatible. Because 3/4 the hashrate won't mine on top of the block, the block and the transaction paying to you will eventually not be in the "mainchain" allowing the attacker to attempt to [[Double-spending|doublespend]].

These attacks can be avoided by upgrading your client, however if the vast majority of miners (>95%) accept the new rules, the odds of an attacker being able to create many fake confirmations is low. Because miners want to make money, and without upgrading their blocks may be reorged out, there is an incentive for miners to upgrade and 100% acceptance of a fork should be achieved by miners quickly.

===2015 BIP66 Blockchain Fork===

After the deployment of the BIP66 softfork in 2015 95% of hash power stated that they accepted BIP66 by setting their block version to 3. In theory setting your block version to 3 is an agreement with the network to consider version 2 blocks invalid and only mine on valid forks. Being part of the 5% that hadn't updated and weren't creating version 3 blocks, BTCNuggets created a version 2 block which was invalid to all new clients (>=0.9.5) but valid to old clients. Antminer and F2Pool, comprising ~40% of the network at the time, were creating version 3 blocks, however neither miner validated previous blocks. This caused both Antminer and F2Pool to mine on top of BTCNuggets version 2 block and create an invalid fork. Over 40% of the hashpower was mining on this version 2 fork despite 95% having "agreed" to not do so. This led to a 6 block fork that was resolved after contacting the F2Pool and Antminer pool owners.

Any SPV clients or out of date clients were vulnerable to these fake confirmations and in theory there could have been a reversed 6 confirmation transaction. Fortunately there were zero doublespent confirmed transactions and the only money lost was mining revenue that these pools lost. F2Pool has continued mining without validating beforehand and SPV client as well as outdated full node clients are at an even higher risk as long as they do so.

==Implications==

Softforks don't require any nodes to upgrade to maintain consensus since all blocks with the new softforked in rules also follow the old rules, therefore old clients accept them. Softforks cannot be reversed without a hardfork since a softfork by definition only allows the set of valid blocks to be a proper subset of what was valid pre-fork.

If users upgrade to a post-softfork client and for some reason a majority of miners switch back to the pre-softfork client, the post-softfork client users would break consensus as soon as a block came along that didn't follow their clients' new rules.

==See Also==
* [[Hardfork]]

Pay to script hash

2017-11-29T22:59:05Z

Taras:

{{infobox miner activated fork|title=Pay to Script Hash
|bipnumber=[[BIP_0013|BIP 13]]
|purpose=Allow the recipient of a transaction to specify the redeem script instead of the sender
|coinbase=/P2SH/
|starttime=2012-01-25 00:00:00
|timeout=2012-02-01 00:00:00
|supermajority=55%
|activated=Block #105571 2012-02-15 00:00:00 
}}'''Pay to script hash''' (P2SH) transactions were standardised in [[BIP 0016|BIP 16]]. They allow transactions to be sent to a script hash ([[address]] starting with 3) instead of a public key hash (addresses starting with 1). To spend bitcoins sent via P2SH, the recipient must provide a [[script]] matching the script hash and data which makes the script evaluate to true.

Using P2SH, you can send bitcoins to an address that is secured in various unusual ways without knowing anything about the details of how the security is set up. You just send bitcoins to the ~34-character P2SH address. The recipient might need the signatures of several people to spend these bitcoins, or a password might be required, or the requirements could be completely unique.

== Addresses ==

[[BIP 0013|BIP 13]] specifies the address format. Bitcoin P2SH addresses always start with <code>3</code>.

== Example ==

Transaction 40eee3ae1760e3a8532263678cdf64569e6ad06abc133af64f735e52562bccc8 paid to P2SH address 3P14159f73E4gFr7JterCCQh9QjiTjiZrG. You can see the redeem script in transaction 7edb32d4ffd7a385b763c7a8e56b6358bcd729e747290624e18acdbe6209fc45 which spends that output, using <code>OP_FALSE <sig> { OP_1 <pubkey> OP_1 OP_CHECKMULTISIG }</code>.

== History ==

342ftSRCvFHfCeFFBuz4xwbeqnDw6BGUey is a Bitcoin [[address]] notable for being the first [[P2SH]]-compatible address receiving bitcoins on the production network.
Its payment was mined in [[block]] 160720; note that it was spent prior to the enforcement of [[BIP 0016|BIP 16]], so it's not a good example to understand P2SH.

Segregated Witness

2017-11-29T22:40:22Z

Taras:

{{infobox miner activated fork|title=SegWit|image=[[File:Segwit.png|256px]]
|fulltitle=Segregated Witness (Consensus layer)
|bipnumber=[[BIP_0141|BIP 141]]
|purpose=Prevent unintended [[transaction malleability]]
|bit=Bit 1 "segwit"
|starttime=2016-11-15 00:00:00
|timeout=2017-11-15 00:00:00
|supermajority=95% of last 2016 block period
|lockin=Block #479708 2017-08-08 19:05:58
|activated=Block #481824 2017-08-24 01:57:37
}}'''Segregated Witness''' (abbreviated as '''SegWit''') is an implemented protocol upgrade intended to provide protection from [[transaction malleability]] and [[Block size limit controversy|increase block capacity]]. SegWit defines a new structure called a ''witness'' that is committed to blocks separately from the transaction merkle tree. This structure contains data required to check transaction validity but is not required to determine transaction effects. In particular, signatures and redeem scripts are moved into this new structure, which does not count towards the traditional [[Block size limit controversy|1 MB block size limit]]. Instead, a new ''weight'' parameter is defined, and blocks are allowed to have at most 4 million weight units (WU). A byte in the original 1 MB zone of the block weighs 4 WU, but a byte in a witness structure only weighs 1 WU, allowing blocks that are technically larger than 1 MB without a hardforking change.

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

==See Also==

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

Template:Infobox miner activated fork

2017-11-29T22:29:57Z

Taras:

{{Infobox|title={{{name|{{{title|{{PAGENAME}}}}}}}}|image={{{logo|}}}{{#if:{{{image|}}}|{{#if:{{{logo|}}}| }}{{{image|}}}}}|caption1={{{caption|}}}
|title_bg={{{bg|black}}}
|content1=Full title|data1={{{fulltitle<includeonly>|</includeonly>}}}
|content2=BIP number|data2={{{bipnumber<includeonly>|</includeonly>}}}
|content3=Type|data3=Miner-activated {{{type|softfork}}}
|content4=Purpose|data4={{{purpose<includeonly>|</includeonly>}}}
|header5=Deployment
|content5=[[Coinbase|CB signature]]|data5={{{coinbase<includeonly>|</includeonly>}}}
|content6=[[BIP 0009|Signalling bit]]|data6={{{bit<includeonly>|</includeonly>}}}
|content7=Starttime|data7={{{starttime<includeonly>|</includeonly>}}}
|content8=Timeout|data8={{{timeout<includeonly>|</includeonly>}}}
|content9=Supermajority|data9={{{supermajority<includeonly>|</includeonly>}}}
|content10=Lock-in|data10={{{lockin<includeonly>|</includeonly>}}}
|content11=Activated|data11={{{activated<includeonly>|</includeonly>}}}
|foot={{{bottom|}}}
}}<includeonly>[[Category:Miner-activated {{{type|softfork}}}s]]</includeonly>

Template:Infobox miner activated fork

2017-11-29T22:22:23Z

Taras:

Template:Infobox miner activated fork

2017-11-29T22:10:49Z

Taras: Created page with "{{Infobox|title={{{name|{{{title|{{PAGENAME}}}}}}}}|image={{{logo|}}}{{#if:{{{image|}}}|{{#if:{{{logo|}}}| }}{{{image|}}}}}|caption1={{{..."

{{Infobox|title={{{name|{{{title|{{PAGENAME}}}}}}}}|image={{{logo|}}}{{#if:{{{image|}}}|{{#if:{{{logo|}}}| }}{{{image|}}}}}|caption1={{{caption|}}}
|title_bg={{{bg|black}}}
|content1=Full title|data1={{{fulltitle<includeonly>|</includeonly>}}}
|content2=BIP number|data2={{{bipnumber<includeonly>|</includeonly>}}}
|content3=Type|data3=Miner-activated {{{type|softfork}}}
|content4=Purpose|data4={{{purpose<includeonly>|</includeonly>}}}
|content5=[[Coinbase|CB signature]]|data5={{{coinbase<includeonly>|</includeonly>}}}
|content6=[[BIP 0009|Signalling bit]]|data6={{{bit<includeonly>|</includeonly>}}}
|content7=Majority needed|data7={{{majorityneeded<includeonly>|</includeonly>}}}
|content8=Activation period(s)|data8={{{activationperiod<includeonly>|</includeonly>}}}
|content9=Lock-in|data9={{{lockin<includeonly>|</includeonly>}}}
|content10=Activated|data10={{{activated<includeonly>|</includeonly>}}}
|content11=Expired|data11={{{expired<includeonly>|</includeonly>}}}
|foot={{{bottom|}}}
}}<includeonly>[[Category:Miner-activated {{{type|softfork}}}s</includeonly>

File:Segwit.png

2017-11-29T21:38:29Z

Taras:

SegWit2x

2017-11-29T21:19:35Z

Taras:

:''Not to be confused with [[Segregated Witness]], which is commonly abbreviated as SegWit.'' 
'''SegWit2x''', (abbreviated '''B2X''' or '''S2X''', and originally called '''SegWit2Mb'''), was a failed contentious hardfork outlined in the [[New York Agreement]] that intended to double the block size limit. The hardfork has been denounced as an attempt made by CEOs and owners of large Bitcoin businesses to introduce changes to the currency's protocol and development cycle with ulterior motives.<ref>{{cite web|url=https://www.forbes.com/sites/ktorpey/2017/10/31/is-bitcoin-facing-a-corporate-takeover-via-the-2x-fork-a-developer-and-a-business-leader-debate/#11a821363bff|title=Is Bitcoin Facing A Corporate Takeover Via The '2x' Fork? A Developer And A Business Leader Debate|work=Forbes|author=Torpey, Kyle|date=October 31, 2017|accessdate=November 29, 2017}}</ref>

Though over 80% of miners signaled intention for SegWit2x and the New York Agreement, it failed to gain any consensus among the community and Core developers. As it became clear that the execution of the fork would lead to a currency split, the address format was deliberately kept identical and no replay protection was implemented, which would have caused many BTC users to inadvertently use B2X. Additionally, code changes were made that allowed B2X nodes to pretend to be BTC nodes in order to connect and use P2P peers from the bitcoin network when synchronizing. Due to these qualities, many users considered B2X to be an outright attack on the bitcoin network, but its designers continued marketing it as an upgrade.

== Cancellation and aftermath ==
The SegWit2x hardfork was declared cancelled in a joint statement by six individuals.<ref>{{cite web|url=https://lists.linuxfoundation.org/pipermail/bitcoin-segwit2x/2017-November/000685.html|title=Segwit2x Final Steps|author=Belsche, Mike et al.|date=November 8, 2017}}</ref> In the following hours, the price of B2X futures (called BT2 on [[Bitfinex]]) dropped to 1% of the price of [[Bitcoin]] (BTC, called BT1 as a Bitfinex future).

Despite the cancellation, some parties intended to proceed with the hard fork.<ref>{{cite web|url=https://www.cryptocoinsnews.com/mysterious-group-bitpico-threatens-to-execute-segwit2x-hard-fork/|title=Mysterious Group BitPico Threatens to Execute the Bitcoin Hard Fork|work=Cryptocoins News|author=Wilmoth, Josiah|date=November 11, 2017|accessdate=November 29, 2017}}</ref> However, when the SegWit2x nodes split from the rest of the network on November 17, it was found that they had done so one block earlier than anticipated, at block 494782.<ref name="cd">{{cite web|url=https://www.coindesk.com/no-fork-no-fire-segwit2x-nodes-stall-running-abandoned-bitcoin-code/|title=No Fork, No Fire: Segwit2x Nodes Stall Running Abandoned Bitcoin Code|work=[[CoinDesk]]|author=Higgins, Stan|date=November 17, 2017|accessdate=November 29, 2017}}</ref> This was due to an [[wikipedia:off-by-one error|off-by-one error]] as a result of counting up from the [[genesis block]] instead of from block 1. After splitting off, SegWit2x nodes were then waiting for the first block of >1MB to begin the chain fork. But the protocol rules say that the block size increase does not occur until block 494784, so because block 494783 is both required to be at most 1 MB by the original rules and greater than 1 MB by the new rules,{{citation needed}} SegWit2x had come to a permanent standstill.<ref name="cd"/>

== References ==
<references/>

New York Agreement

2017-11-29T21:16:24Z

Taras: Created page with "The opening text of the New York AgreementThe '''Bitcoin Scaling Agreement at Consensus 2017''', better known as the '''New York Agreement''..."

[[File:NYA-main-points.png|thumb|The opening text of the New York Agreement]]The '''Bitcoin Scaling Agreement at Consensus 2017''', better known as the '''New York Agreement''' (abbreviated '''NYA'''), was a scaling proposal made jointly by over 50 companies. The agreement intended to put an end to Bitcoin’s [[Block size limit controversy|long-lasting scaling debate]] by increasing the block capacity through activating [[Segregated Witness]] and then [[SegWit2x|doubling the block size]].
{{stub}}

File:NYA-main-points.png

2017-11-29T21:08:14Z

Taras:

SegWit2x

2017-11-29T20:57:34Z

Taras:

:''Not to be confused with [[Segregated Witness]], which is commonly abbreviated as SegWit.'' 
'''SegWit2x''', (also called '''B2X''' or '''S2X'''), was a failed contentious hardfork that intended to double the block size limit. The hardfork has been denounced as an attempt made by CEOs and owners of large Bitcoin businesses to introduce changes to the currency's protocol and development cycle with ulterior motives.<ref>{{cite web|url=https://www.forbes.com/sites/ktorpey/2017/10/31/is-bitcoin-facing-a-corporate-takeover-via-the-2x-fork-a-developer-and-a-business-leader-debate/#11a821363bff|title=Is Bitcoin Facing A Corporate Takeover Via The '2x' Fork? A Developer And A Business Leader Debate|work=Forbes|author=Torpey, Kyle|date=October 31, 2017|accessdate=November 29, 2017}}</ref>

== Support rate ==

Though over 80% of miners signaled intention for SegWit2x, it failed to gain any consensus among the community and the Core developers. As it became clear that the execution of the fork would lead to a currency split, the address format was deliberately kept identical and no replay protection was implemented, which would have caused many BTC users to inadvertently use B2X. Additionally, code changes were made that allowed B2X nodes to pretend to be BTC nodes in order to connect and use P2P peers from the bitcoin network when synchronizing. Due to these qualities, many users considered B2X to be an outright attack on the bitcoin network, but its designers continued marketing it as an upgrade.

== Cancellation ==
The SegWit2x hardfork was declared cancelled in a joint statement by six individuals.<ref>{{cite web|url=https://lists.linuxfoundation.org/pipermail/bitcoin-segwit2x/2017-November/000685.html|title=Segwit2x Final Steps|author=Belsche, Mike et al.|date=November 8, 2017}}</ref> In the following hours, the price of B2X futures (called BT2 on [[Bitfinex]]) dropped to 1% of the price of [[Bitcoin]] (BTC, called BT1 as a Bitfinex future).

Despite the cancellation, some parties intended to proceed with the hard fork.<ref>{{cite web|url=https://www.cryptocoinsnews.com/mysterious-group-bitpico-threatens-to-execute-segwit2x-hard-fork/|title=Mysterious Group BitPico Threatens to Execute the Bitcoin Hard Fork|work=Cryptocoins News|author=Wilmoth, Josiah|date=November 11, 2017|accessdate=November 29, 2017}}</ref> However, when the SegWit2x nodes split from the rest of the network on November 17, it was found that they had done so one block earlier than anticipated, at block 494782.<ref>{{cite web|url=https://www.coindesk.com/no-fork-no-fire-segwit2x-nodes-stall-running-abandoned-bitcoin-code/|title=No Fork, No Fire: Segwit2x Nodes Stall Running Abandoned Bitcoin Code|work=[[CoinDesk]]|author=Higgins, Stan|date=November 17, 2017|accessdate=November 29, 2017}}</ref> This was due to an [[wikipedia:off-by-one error|off-by-one error]] as a result of counting up from the [[genesis block]] instead of from block 1. After splitting off, SegWit2x nodes were then waiting for the first block of >1MB to begin the chain fork. But the protocol rules say that the block size increase does not occur until block 494784, so because block 494783 is both required to be at most 1 MB by the original rules and greater than 1 MB by the new rules, SegWit2x had come to a permanent standstill.

== References ==
<references/>

SegWit2x

2017-11-29T20:27:52Z

Taras:

:''Not to be confused with [[Segregated Witness]], which is commonly abbreviated as SegWit.'' 
'''SegWit2x''', (also called '''B2X''' or '''S2X'''), was a failed contentious hardfork that intended to double the block size limit. The attempt has been denounced as an attempt made by CEOs and owners of several Bitcoin businesses to introduce a change in Bitcoin with ulterior motives, including the replacement of the Bitcoin developers with [[Jeff Garzik]].

== Support rate ==

It failed to gain consensus among community:

* over 80% of miners by hashare (though they were just signaling, and this has no cryptographic or economical meaning or repercussions)
* just below 20% of users by economy ([https://www.bitfinex.com/order_book/bt2btc BitFinex futures market as BT2 token]) (representing actual trades that were executed for money)
* around 0% of Bitcoin developers (Bitcoin Core)

== Attack or upgrade ==

It was created in a way that would trick users into unknowingly switching to B2X from BTC, due to:

* no replay protection
* simple SPV wallets without special tools to detect the problem would accept B2X blocks as BTC blocks
* same address formats
* code changes that allowed B2X nodes to pretend to be BTC nodes in order to connect and use P2P peers from BTC network

due to this qualities, many users considered B2X and attack on BTC network.

B2X was marketed by it's creators as an "upgrade".

== Cancellation ==
The SegWit2x hardfork was declared cancelled in a joint statement by six individuals.<ref>{{cite web|url=https://lists.linuxfoundation.org/pipermail/bitcoin-segwit2x/2017-November/000685.html|title=Segwit2x Final Steps|author=Belsche, Mike et al.|date=November 8, 2017}}</ref> In the following hours, the price of B2X futures (called BT2 on [[Bitfinex]]) dropped to 1% of the price of [[Bitcoin]] (BTC, called BT1 as a Bitfinex future).

Despite the cancellation, some parties intended to proceed with the hard fork.<ref>{{cite web|url=https://www.cryptocoinsnews.com/mysterious-group-bitpico-threatens-to-execute-segwit2x-hard-fork/|title=Mysterious Group BitPico Threatens to Execute the Bitcoin Hard Fork|work=Cryptocoins News|author=Wilmoth, Josiah|date=November 11, 2017|accessdate=November 29, 2017}}</ref> However, when the flag day arrived, it was found that an off-by-one error in the SegWit2x protocol made it impossible to solve the first required >1MB block, freezing the currency entirely.

== References ==
<references/>

Segregated Witness

2017-11-29T20:02:37Z

Taras:

'''Segregated Witness''' (abbreviated as '''SegWit''') is an implemented protocol upgrade intended to provide protection from [[transaction malleability]] and [[Block size limit controversy|increase block capacity]]. SegWit defines a new structure called a ''witness'' that is committed to blocks separately from the transaction merkle tree. This structure contains data required to check transaction validity but is not required to determine transaction effects. In particular, signatures and redeem scripts are moved into this new structure, which does not count towards the traditional [[Block size limit controversy|1 MB block size limit]].

==See Also==

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

Transaction Malleability

2017-11-29T19:54:35Z

Taras: Taras moved page Transaction Malleability to Transaction malleability

#REDIRECT [[Transaction malleability]]

Transaction malleability

2017-11-29T19:54:35Z

Taras: Taras moved page Transaction Malleability to Transaction malleability

While [[transaction]]s are signed, the signature does not currently cover all the data in a transaction that is hashed to create the transaction hash. Thus, while uncommon, it is possible for a node on the network to change a transaction you send in such a way that the hash is invalidated. Note that this just changes the hash; the output of the transaction remains the same and the bitcoins will go to their intended recipient. However this does mean that, for instance, it is not safe to accept a chain of unconfirmed transactions under any circumstance because the later transactions will depend on the hashes of the previous transactions, and those hashes can be changed until they are confirmed in a block (and potentially even after a confirmation if the block chain is reorganized). In addition, clients must always actively scan for transactions to them; assuming a txout exists because the client created it previously is unsafe.

== Signature Malleability ==

The first form of malleability is in the signatures themselves. Each signature has exactly one DER-encoded ASN.1 octet representation, but OpenSSL does not enforce this, and as long as a signature isn't horribly malformed, it will be accepted.<ref>https://bitcointalk.org/index.php?topic=8392.msg122410#msg122410</ref> In addition for every ECDSA signature (r,s), the signature (r, -s (mod N)) is a valid signature of the same message.<ref>https://bitcointalk.org/index.php?topic=8392.msg1245898#msg1245898</ref>

As of block 363724<ref>[http://bitcoin.stackexchange.com/a/38438/21052 When did BIP66 switch from activation to enforcement?], answer by StephenM347, 6 July 2015, Bitcoin.StackExchange</ref>, the [https://github.com/bitcoin/bips/blob/master/bip-0066.mediawiki BIP66 soft fork] has made it mandatory for all new transactions in the block chain to strictly follow the DER-encoded ASN.1 standard.
Further efforts are still under way to close other possible malleability within DER signatures.

Signatures can still be changed by anyone who has access to the corresponding private keys.

== scriptSig Malleability ==

The [[OP_CHECKSIG|signature algorithm]] used in Bitcoin does not sign any of the scriptSig to create the signature. While signing the whole scriptSig would be impossible - the signature would be signing itself - this does mean that additional data can be added such that it will be pushed on the stack prior to the required signatures and public keys. Similarly OP_DROP can be added to leave the stack exactly as before prior to scriptPubKey execution.

Preventing scriptSig malleability is being considered as well. Currently transactions with anything other than data push operations in their scriptSig are considered non-standard and are not relayed, and eventually this rule may extend to enforcing that the stack have exactly one item after execution. However doing that may interfere with later extensions to Bitcoin.

==References==
<references/>

[[Category:Technical]]
[[Category:Developer]]

{{Bitcoin Core documentation}}

Satoshi per byte

2017-10-23T17:25:40Z

Taras: Created page with "'''Satoshi per byte''' is a unit for measuring transaction priority, defined by the transaction's fee in satoshi divided by the size of..."

'''Satoshi per byte''' is a unit for measuring transaction priority, defined by the [[transaction fees|transaction's fee]] in [[satoshi (unit)|satoshi]] divided by the size of the transaction in bytes.

{{stub}}

Satoshi Nakamoto

2017-10-23T17:24:28Z

Taras:

:'''''Satoshi''' redirects here. For the unit, see [[satoshi (unit)]].''
'''Satoshi Nakamoto''' is the founder of [[Bitcoin]] and initial creator of the [[Original Bitcoin client]]. He has said in a P2P foundation profile<ref name="p2p_f_profile">[http://p2pfoundation.ning.com/profile/SatoshiNakamoto Satoshi Nakamoto profile on P2P Foundation]</ref> that he is from Japan. Beyond that, not much else is known about him and his identity. He has been working on the Bitcoin project since 2007.<ref>[https://bitcointalk.org/index.php?topic=13.msg46#msg46 Re: Questions about Bitcoin]</ref>

His involvement in the Bitcoin project had tapered and by late 2010 it has ended. The most recent messages reportedly indicate that Satoshi is "gone for good"<ref>[http://bitcoinstats.com/irc/bitcoin-dev/logs/2011/04/26#l1303826036.0 Transcript of #bitcoin-dev for 2011/04/26]</ref>.

==Possible Motives==
He left some clues about why he is doing this project with the inclusion of the following text in the [[Genesis block]], "The Times 03/Jan/2009 Chancellor on brink of second bailout for banks".

Some interesting quotes:
<blockquote>Yes, [we will not find a solution to political problems in cryptography,] but we can win a major battle in the arms race and gain a new territory of
freedom for several years.

Governments are good at cutting off the heads of a centrally controlled
networks like Napster, but pure P2P networks like Gnutella and Tor seem to be
holding their own.<ref>[http://www.mail-archive.com/cryptography@metzdowd.com/msg09971.html Re: Bitcoin P2P e-cash paper Fri, 07 Nov 2008 09:30:36 -0800]</ref></blockquote>

<blockquote>It's very attractive to the libertarian viewpoint if we can explain it
properly. I'm better with code than with words though. <ref>[http://www.mail-archive.com/cryptography@metzdowd.com/msg10001.html Re: Bitcoin P2P e-cash paper Fri, 14 Nov 2008 14:29:22]</ref></blockquote>

==Possible identity==
His identity and nationality are unknown.

He is entirely unknown outside of Bitcoin as far as anyone can tell, and his (never used) PGP key was created just months prior to the date of the genesis block. He seems to be very familiar with the cryptography mailing list, but there are no non-Bitcoin posts from him on it. He has used an email address from an anonymous mail hosting service (vistomail) as well as one from a free webmail account (gmx.com) and sends mail when connected via Tor. Some have speculated that his entire identity was created in advance in order to protect himself or the network. Perhaps he chose the name Satoshi because it can mean "wisdom" or "reason" and Nakamoto can mean "Central source".

Ultimately the design of Bitcoin and its use of cryptographic proof and fully open implementation is one that makes its creator, in a sense, irrelevant and only of interest for historical reasons.

==External links==
* [http://bitcointalk.org/Satoshi_Nakamoto.asc Satoshi's PGP public key]
* [http://www.bitcoin.org/bitcoin.pdf Bitcoin: A Peer-to-Peer Electronic Cash System] Paper
* [http://sourceforge.net/users/s_nakamoto SourceForge page]

==References==
<references/>

[[de:Satoshi Nakamoto]]
[[es:Satoshi Nakamoto]]

[[Category:Individuals]]

Satoshi (unit)

2017-10-23T17:21:14Z

Taras:

[[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 name="why">{{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, such as when calculating [[satoshi per byte|fee per byte]] or a [[Bitcoin faucet|faucet]] reward, the amount is displayed in satoshi for readability.<ref>{{cite web|title=How do I calculate my transaction fee?|work=[[21]] Support|author=Binns, Will|date=|accessdate=23 October 2017|url=https://support.21.co/bitcoin/transactions-and-fees/how-do-i-calculate-my-transaction-fee}}</ref><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>

Although the satoshi is the finest amount that can be recorded in the block chain,<ref name="why"/> [[payment channels]] may need to make very granular payments and so are sometimes denominated in ''millisatoshi'', which are one hundred billionths of a single bitcoin.<ref>[https://github.com/ElementsProject/lightning/blob/master/README.md#receiving-and-receiving-payments Receiving and receiving payments]</ref>

As of October 2017, 1 US cent is worth approximately 171 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 and equally correct. If the plural form were to follow the rules of Japanese grammar, it may be pronounced as ''satoshisa'',<ref name="jj73">{{cite btct|id=289475|post=3112861|date=9 September 2013|title=satoshii}}</ref> or simply ''satoshi''.<ref name="jj73"/>

===Symbol===
Satoshi is often abbreviated to ''sat'' or ''s'', although no currency 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]]

User:Taras

2017-08-26T18:17:21Z

Taras:

I will sign important messages with this address: 1TarasQyKwPJRuod6qwh7n8BjMHC49ZNY

File:Redeemed BitBill.jpg

2017-08-20T11:59:38Z

Taras:

Template:Physical bitcoin manufacturers

2017-08-20T11:53:37Z

Taras: Created page with "{{Navbox_default |title=Physical bitcoin manufacturers |image=180px |header=List • [..."

{{Navbox_default
|title=[[Physical bitcoin]] manufacturers
|image=[[File:Casascius_25btc_size_compare.jpg|180px]]
|header=[[List of physical bitcoin manufacturers|List]] • [[Mini private key format]]
|group1=Coins
|list1=[[Casascius physical bitcoins|Casascius]] (2011-2014) • '''[[Denarium physical bitcoins|Denarium]]''' (2015-) • [[Lealana]] (2013-2014)
|group2=Cards
|list2=[[Bitbills|BitBills]] (2011) • [[PrintCoins]] (2011-2012)
|footer='''Bold:''' still producing physical bitcoins
}}

Casascius physical bitcoins

2017-08-20T11:34:53Z

Taras:

[[Image:Casascius 25btc size compare.jpg|thumb|right|300px|Various views of Casascius coins]]
[[File:Physbitcoinkey.jpg|thumb|right|Redeemed Casascius coin]]
'''Casascius physical bitcoins''', also called '''Casascius coins''', are physical metal coins created by Bitcoin user [[User:Casascius|Casascius]] (Mike Caldwell, Sandy, Utah, USA) and sold until Nov 26, 2013<ref name="suspension">[https://www.casascius.com/ casascius.com], viewed 2016-09-12: ''"As of Nov 27, 2013, I suspended sales of items that contain digital bitcoins. Current items for sale do not contain bitcoins."''</ref>, that contain an embedded piece of paper with digital Bitcoin value, covered by a tamper-resistant hologram. Casascius coins are available in 1, 10, 25, 100, and 1000 BTC increments. They can be purchased at Casascius's website, https://www.casascius.com (only Bitcoin accepted), or at http://www.MemoryDealers.com (PayPal and credit cards accepted).

The coins are designed such that they could be circulated in face-to-face transactions. The first person to redeem its [[private key]] gets the value on the coin, and afterwards, the coin no longer has any Bitcoin value. It is difficult or impossible to read the private key on the coin without damaging or destroying the hologram, which exposes a honeycomb-like tamper-evidence pattern when peeled.

The piece of paper inside each coin has a private key which forms the backing for the Bitcoin value represented by the coin. Redeeming the private key back into digital Bitcoins is currently available with a patched reference client and many of the alternative clients.

Casascius coins are similar to [[Bitbills]] in that they are an object that contains a redemption code that serves as a bearer item for digital bitcoins.

There are 2 independent websites that track the status of all Casascius coins in circulation, based on information from the block chain:
* [[Casascius Bitcoin Analyzer]] (http://casascius.uberbills.com/)
* Casascius Physical Bitcoins Database (http://casascius.appspot.com/)

==History==
Originally, Mike Caldwell imagined placing a private key on a piece of paper inside a washer with a tamper-evident hologram on each side. However, he found it was more economical to have a real coin minted with a hologram on one side than to have two different hologram designs, and so the first Casascius coins were customized brass coins ordered from a mint that makes car wash tokens.<ref>{{cite btct|id=131088|title=Coming soon from Casascius: free high-density physical bitcoin key generator|date=2012-12-16|post=2866885}}</ref>

===Suspension of sale===

As of Nov 27, 2013, Mike Caldwell suspended sales of items that contain digital bitcoins.<ref name="suspension" /> The Financial Crimes Enforcement Network (FinCEN), a branch of the Treasury Department, informed him before, that minting physical bitcoins qualifies him as a money transmitter business, which means he needs to register at the federal level and probably get state licenses too.<ref>[http://www.theverge.com/2013/12/13/5207256/casascius-maker-of-shiny-physical-bitcoins-shut-down-by-treasury ''The Verge'' internet site article ''"Casascius, maker of shiny physical bitcoins, shut down by Treasury Department"'' from 2013-12-13, viewed 2016-09-12]</ref>

==Releases of Casascius coins==

===Original series 1 BTC coin===
* 1.125 inches in diameter
* Solid brass
* Year printed on coins: 2011
* Approximately 0.24 ounces
* Eight-digit "[[firstbits]]" inkjetted onto surface of hologram sticker
* First appeared in September 2011<ref>[http://bitcointalk.org/index.php?topic=41892.0 CASASCIUS PHYSICAL BITCOIN - In Stock Now!]</ref>.
* Private key: 22 character string inside the coin, the 256-bit private key is SHA256(string)
* Approximate number produced: {{formatnum:3500}} as of November 2011
* A spelling error can be found in the small lettering of the hologram: "CASACIUS" instead of "CASASCIUS"
* Casascius has stated that no more than {{formatnum:11000}} may be produced
* All {{formatnum:11000}} Bitcoin addresses pre-generated for the series have been published as a signed text file

===Second series 1 BTC coin===
[[Image:Casascius-series-2.jpg|thumb|right|200px|Second series 1 BTC Casascius coin]]
The hologram and the private key is different, the metal part of the coin is the same as the first series.
* 1.125 inches in diameter
* Solid brass
* Year printed on coins: 2011
* Approximately 0.24 ounces
* Denomination ("ONE BTC") appears on the hologram
* Eight-digit "firstbits" visible through a small transparent window that allows limited visibility of one side of the private key paper
* Private key: 30 character string inside the coin, the 256-private key is SHA256(string)
* First appeared in November 2011
* No spelling error in hologram

===10 BTC silver round===
* First available on Dec 1, 2011
* 39mm diameter
* 1 troy ounce .999 Fine Silver
* Uses second series holograms marked TEN BTC
* Comes in a clear plastic capsule
* Zeroes and ones on the back encode the message "Bitcoin: an idea too big to fail"

===25 BTC coin===
[[Image:Casascius 25btc.jpg|thumb|right|Casascius 25BTC coin]]
* 1.75 inches in diameter, about 3mm thick
* Gold-plated alloy
* Approximately 1.2 ounces
* Printed year: 2011
* Uses same holograms and private key scheme as original series 1 BTC coin
* First appeared in October 2011
* Zeroes and ones on the back encode the message "You asked for change, we gave you coins"

===100 BTC gold plated bar===
* Weight: 4.2oz
* Dimensions: 8cm x 4cm x 0.6cm
* Printed year: none
* Indented features: "100 BTC", Bitcoin logo, "gold plated bearer bar"
* Hologram: V1 or V2

===1000 BTC gold plated bar===
* Weight: 4.2oz
* Dimensions: 8cm x 4cm x 0.6cm
* Hologram: V1
* Printed year: none
* Lasered overprinting on the hologram to indicate the denomination
* This is a non-denominated bar that has been engraved with a 1000 BTC denomination. It is indented with the Bitcoin logo and the words "gold plated bearer bar" like the 100 BTC bar, but is not indented with a denomination. The denomination is applied via laser engraving.
* This item is presently listed for sale only through MemoryDealers.com

===1000 BTC 1 troy ounce gold coin===
* Available as of Dec 16, 2011
* Printed year: 2012
* Diameter: 30mm
* Special order item, 3 business day lead time
* Hologram: V1 with Bitcoin address lasered at top instead of inkjetted across middle
* Availability: Purchase from MemoryDealers.com, or directly from Casascius with BTC, or USD bank wire

== See also ==
* [[Mini private key format]]

== References ==
<references />

[[Category:Physical bitcoins]]

Genesis block

2017-08-20T09:16:54Z

Taras:

A '''genesis block''' is the first block of a [[block chain]]. Modern versions of Bitcoin number it as '''block 0''', though very early versions counted it as block 1. The genesis block is almost always hardcoded into the software of the applications that utilize its block chain. It is a special case in that it does not reference a previous block, and for [[Bitcoin]] and almost all of its derivatives, it produces an unspendable subsidy.

== Main network genesis block ==
Here is a representation of the genesis block<ref name="block">{{cite block|hash=000000000019d6689c085ae165831e934ff763ae46a2a6c172b3f1b60a8ce26f|0|year=2009|month=01|day=03}}</ref> as it appeared in a comment in an old version of Bitcoin ([http://sourceforge.net/p/bitcoin/code/133/tree/trunk/main.cpp#l1613 line 1613]). The first section defines exactly all of the variables necessary to recreate the block. The second section is the block in standard printblock format, which contains shortened versions of the data in the first section.

GetHash() = 0x000000000019d6689c085ae165831e934ff763ae46a2a6c172b3f1b60a8ce26f
hashMerkleRoot = 0x4a5e1e4baab89f3a32518a88c31bc87f618f76673e2cc77ab2127b7afdeda33b
txNew.vin[0].scriptSig = 486604799 4 0x736B6E616220726F662074756F6C69616220646E6F63657320666F206B6E697262206E6F20726F6C6C65636E61684320393030322F6E614A2F33302073656D695420656854
txNew.vout[0].nValue = 5000000000
txNew.vout[0].scriptPubKey = 0x5F1DF16B2B704C8A578D0BBAF74D385CDE12C11EE50455F3C438EF4C3FBCF649B6DE611FEAE06279A60939E028A8D65C10B73071A6F16719274855FEB0FD8A6704 OP_CHECKSIG
block.nVersion = 1
block.nTime = 1231006505
block.nBits = 0x1d00ffff
block.nNonce = 2083236893

CBlock(hash=000000000019d6, ver=1, hashPrevBlock=00000000000000, hashMerkleRoot=4a5e1e, nTime=1231006505, nBits=1d00ffff, nNonce=2083236893, vtx=1)
CTransaction(hash=4a5e1e, ver=1, vin.size=1, vout.size=1, nLockTime=0)
CTxIn(COutPoint(000000, -1), coinbase 04ffff001d0104455468652054696d65732030332f4a616e2f32303039204368616e63656c6c6f72206f6e206272696e6b206f66207365636f6e64206261696c6f757420666f722062616e6b73)
CTxOut(nValue=50.00000000, scriptPubKey=0x5F1DF16B2B704C8A578D0B)
vMerkleTree: 4a5e1e
===Hash===
The hash of the genesis block, '''000000000019d6689c085ae165831e934ff763ae46a2a6c172b3f1b60a8ce26f''',<ref name="block"/> has two more leading hex zeroes than were required for an early block.

===Coinbase===
[[File:jonny1000thetimes.png|thumb|256px|The Times 03/Jan/2009]]
The [[coinbase]] parameter (seen above in hex) contains, along with the normal data, the following text:<ref>[http://web.archive.org/web/20140309004338/http://uk.reuters.com/article/2009/01/03/idUKPTIP32510920090103 Reuters' reference on The Financial Times article (archive.org cached copy)]</ref>

<blockquote>The Times 03/Jan/2009 Chancellor on brink of second bailout for banks<ref name="block"/></blockquote>

This was probably intended as proof that the block was created on or after January 3, 2009, as well as a comment on the instability caused by fractional-reserve banking. Additionally, it suggests that [[Satoshi Nakamoto]] may have lived in the United Kingdom.<ref>{{cite web|author=Davis, J.|year=2011|title=The Crypto-Currency|publisher=''The New Yorker''|url=http://www.newyorker.com/magazine/2011/10/10/the-crypto-currency}}</ref>

===Block reward===
The first 50 BTC block reward went to [[address]] ''1A1zP1eP5QGefi2DMPTfTL5SLmv7DivfNa'',<ref name="block"/> though this reward can't be spent due to a quirk in the way that the genesis block is expressed in the code. It is not known if this was done intentionally or accidentally.<ref>http://bitcoin.stackexchange.com/questions/10009/why-can-t-the-genesis-block-coinbase-be-spent</ref><ref>https://www.reddit.com/r/Bitcoin/comments/1nc13r/the_first_50btc_block_reward_cant_be_spend_why/</ref><ref>https://github.com/bitcoin/bitcoin/blob/9546a977d354b2ec6cd8455538e68fe4ba343a44/src/main.cpp#L1668 - Genesis block transaction treated as a special case in the reference code</ref> It is believed that other outputs sent to this address are spendable, but it is unknown if Satoshi Nakamoto has the private key for this particular address, if one existed at all.

===Timestamp===
Although the average time between Bitcoin blocks is 10 minutes, the timestamp of the next block is a full 6 days after the genesis block. One interpretation is that Satoshi was working on bitcoin for some time beforehand and the ''The Times'' front page prompted him to release it to the public. He then mined the genesis block with a timestamp in the past to match the headline. It is also possible that, since the block's hash is so low, he may have spent 6 days mining it with the same timestamp before proceeding to block 1. The [[prenet hypothesis]] suggests that the genesis block was solved on January 3, but the software was tested by Satoshi Nakamoto using that genesis block until January 9, when all the test blocks were deleted and the genesis block was reused for the main network.

===Raw block data===

The [https://bitcointalk.org/index.php?topic=52706 raw hex version] of the Genesis block looks like:
00000000 01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00000010 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00000020 00 00 00 00 3B A3 ED FD 7A 7B 12 B2 7A C7 2C 3E ....;£íýz{.²zÇ,>
00000030 67 76 8F 61 7F C8 1B C3 88 8A 51 32 3A 9F B8 AA gv.a.È.ÃˆŠQ2:Ÿ¸ª
00000040 4B 1E 5E 4A 29 AB 5F 49 FF FF 00 1D 1D AC 2B 7C K.^J)«_Iÿÿ...¬+|
00000050 01 01 00 00 00 01 00 00 00 00 00 00 00 00 00 00 ................
00000060 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00000070 00 00 00 00 00 00 FF FF FF FF 4D 04 FF FF 00 1D ......ÿÿÿÿM.ÿÿ..
00000080 01 04 45 54 68 65 20 54 69 6D 65 73 20 30 33 2F ..EThe Times 03/
00000090 4A 61 6E 2F 32 30 30 39 20 43 68 61 6E 63 65 6C Jan/2009 Chancel
000000A0 6C 6F 72 20 6F 6E 20 62 72 69 6E 6B 20 6F 66 20 lor on brink of
000000B0 73 65 63 6F 6E 64 20 62 61 69 6C 6F 75 74 20 66 second bailout f
000000C0 6F 72 20 62 61 6E 6B 73 FF FF FF FF 01 00 F2 05 or banksÿÿÿÿ..ò.
000000D0 2A 01 00 00 00 43 41 04 67 8A FD B0 FE 55 48 27 *....CA.gŠý°þUH'
000000E0 19 67 F1 A6 71 30 B7 10 5C D6 A8 28 E0 39 09 A6 .gñ¦q0·.\Ö¨(à9.¦
000000F0 79 62 E0 EA 1F 61 DE B6 49 F6 BC 3F 4C EF 38 C4 ybàê.aÞ¶Iö¼?Lï8Ä
00000100 F3 55 04 E5 1E C1 12 DE 5C 38 4D F7 BA 0B 8D 57 óU.å.Á.Þ\8M÷º..W
00000110 8A 4C 70 2B 6B F1 1D 5F AC 00 00 00 00 ŠLp+kñ._¬....

Broken down it looks like this:

01000000 - version
0000000000000000000000000000000000000000000000000000000000000000 - prev block
3BA3EDFD7A7B12B27AC72C3E67768F617FC81BC3888A51323A9FB8AA4B1E5E4A - merkle root
29AB5F49 - timestamp
FFFF001D - bits
1DAC2B7C - nonce
01 - number of transactions
01000000 - version
01 - input
0000000000000000000000000000000000000000000000000000000000000000FFFFFFFF - prev output
4D - script length
04FFFF001D0104455468652054696D65732030332F4A616E2F32303039204368616E63656C6C6F72206F6E206272696E6B206F66207365636F6E64206261696C6F757420666F722062616E6B73 - scriptsig
FFFFFFFF - sequence
01 - outputs
00F2052A01000000 - 50 BTC
43 - pk_script length
4104678AFDB0FE5548271967F1A67130B7105CD6A828E03909A67962E0EA1F61DEB649F6BC3F4CEF38C4F35504E51EC112DE5C384DF7BA0B8D578A4C702B6BF11D5FAC - pk_script
00000000 - lock time
==References==
<references/>

[[zh-cn:创世block]]
[[es:Bloque Génesis]]
__NOTOC__

Help:How to import private keys in Bitcoin Core 0.7+

2017-08-13T02:53:34Z

Taras:

{{sample}}
Before reading this page, users should note that messing with ECDSA private keys is very dangerous and can result in losing bitcoins, even long after the import.
It is recommended that outside of self-generated vanity addresses, users should ''never'' import (or export) private keys.<ref>[https://bitcoin.stackexchange.com/questions/29948/why-doc-says-importing-private-keys-is-so-dangerous Bitcoin StackExchange - Why doc says importing private keys is so dangerous?]</ref><ref>[https://bitcoin.stackexchange.com/questions/18619/why-so-many-warnings-about-importing-private-keys Bitcoin StackExchange - Why so many warnings about importing private keys?]</ref>

==Backup Your Wallet==
Although this process is well tested and used you should always take another backup
of your wallet.dat file before starting.

==Open Debug Window==
Then go to menu:
/Help/Debug Window

[[File:Screen1.PNG|px200]]

and click on the tab - Console.

==Unlock your wallet==

If your wallet is encrypted (I hope it is!) you must unlock it. If not just skip this step.

To do this just type into the box at the bottom:
<pre>
walletpassphrase "YourLongPassphrase" 600
</pre>
You need the quotes if there is a space in your phrase else there is no need for them.
The 600 means your wallet is unlocked for 10 minutes (600 seconds).

[[File:Unlock.PNG|px200]]

==Run Import Command in Debug Window==
In the console at the very bottom is a text entry box. In here enter:
<pre>
importprivkey yourPrivateKeyInWalletImportFormat "TheLabelThatIWant"
</pre>
The quotes are only needed if you want a space in the label.

[[File:Import1.PNG]]

You now have to be patient. On a fast PC it takes 2 minutes to import, and
during this time it looks like you application has hung. After waiting a few minutes
you will see:

[[File:Import2.PNG]]

If you want import multiple private keys add false at the end like so:
importprivkey L1SLw5C14f8KBZCfUow3h5acE{{taggant private key}}fC8ZLMiLo3fgoDWxHjCTuzyGPcd "" false

Do not forget to add the blank label.

for all keys but the last, and then remove the false to allow the rescan. <ref name="multiple keys">[https://www.reddit.com/r/Bitcoin/comments/2bh4tv/for_importprivkey_0921_just_got_a_whole_lot_more/], Reddit /r/bitcoin thread</ref>

You are now done. But always best to check it worked.

==Check Key Imported OK==

Once Imported you can check that you have the address by closing the Debug window and going back to your address book.

You should see the address here:

[[File:InAddressBook.PNG]]

And you can even send a transaction to check e.g.

[[File:ReceivedTrans.PNG]]

==Backup Wallet==
Your backup of your wallet will not have this key in obviously. So before you do anything else backup the wallet.dat file as normal.

==References==
<references />

{{Bitcoin Core documentation}}

Help:How to import private keys in Bitcoin Core 0.7+

2017-08-13T02:52:42Z

Taras:

{{sample}}
Before reading this page, users should note that messing with ECDSA private keys is very dangerous and can result in losing bitcoins, even long after the import.
It is recommended that outside of self-generated vanity addresses, users should ''never'' import (or export) private keys.<ref>[https://bitcoin.stackexchange.com/questions/29948/why-doc-says-importing-private-keys-is-so-dangerous Bitcoin StackExchange - Why doc says importing private keys is so dangerous?]</ref><ref>[https://bitcoin.stackexchange.com/questions/18619/why-so-many-warnings-about-importing-private-keys Bitcoin StackExchange - Why so many warnings about importing private keys?]</ref>

==Backup Your Wallet==
Although this process is well tested and used you should always take another backup
of your wallet.dat file before starting.

==Open Debug Window==
Then go to menu:
/Help/Debug Window

[[File:Screen1.PNG|px200]]

and click on the tab - Console.

==Unlock your wallet==

If your wallet is encrypted (I hope it is!) you must unlock it. If not just skip this step.

To do this just type into the box at the bottom:
<pre>
walletpassphrase "YourLongPassphrase" 600
</pre>
You need the quotes if there is a space in your phrase else there is no need for them.
The 600 means your wallet is unlocked for 10 minutes (600 seconds).

[[File:Unlock.PNG|px200]]

==Run Import Command in Debug Window==
In the console at the very bottom is a text entry box. In here enter:
<pre>
importprivkey yourPrivateKeyInWalletImportFormat "TheLabelThatIWant"
</pre>
The quotes are only needed if you want a space in the label.
[[File:Import1.PNG]]

You now have to be patient. On a fast PC it takes 2 minutes to import, and
during this time it looks like you application has hung. After waiting a few minutes
you will see:

[[File:Import2.PNG]]

If you want import multiple private keys add false at the end like so:
<pre>
importprivkey L1SLw5C14f8KBZCfUow3h5acE{{taggant private key}}fC8ZLMiLo3fgoDWxHjCTuzyGPcd "" false
</pre>

Do not forget to add the blank label.

for all keys but the last, and then remove the false to allow the rescan. <ref name="multiple keys">[https://www.reddit.com/r/Bitcoin/comments/2bh4tv/for_importprivkey_0921_just_got_a_whole_lot_more/], Reddit /r/bitcoin thread</ref>

You are now done. But always best to check it worked.

==Check Key Imported OK==

Once Imported you can check that you have the address by closing the Debug window and going back to your address book.

You should see the address here:

[[File:InAddressBook.PNG]]

And you can even send a transaction to check e.g.

[[File:ReceivedTrans.PNG]]

==Backup Wallet==
Your backup of your wallet will not have this key in obviously. So before you do anything else backup the wallet.dat file as normal.

==References==
<references />

{{Bitcoin Core documentation}}

Coinbase (podcast)

2017-08-13T02:41:20Z

Taras: Created page with "'''''Coinbase''''' was a podcast that ran for 6 episodes from 2011 to 2012 by Hiro White and TheRealPlato. {{DISPLAYTITLE:Coinbase (podcast)}} {{s..."

'''''Coinbase''''' was a podcast that ran for 6 episodes from 2011 to 2012 by Hiro White and [[Bitcoin Road Trip|TheRealPlato]].
{{DISPLAYTITLE:Coinbase (podcast)}}
{{stub}}

Units

2017-08-13T02:31:24Z

Taras:

Most commonly, units of bitcoin are expressed in decimal exponents such as BTC ("bitcoins"), mBTC ("millibitcoins") and μBTC ("bits").

==Decimal metric units==

The BTC unit was chosen to represent a value of 108 so as to give sub-unit precision rather than large whole numbers.
Mirroring the standard ''Le Système International d'Unités'', this allows for divisions of 1/10th (deci-bitcoins, dBTC), 1/100th (centi-bitcoins, cBTC), 1/1 000th (milli-bitcoins, mBTC), and 1/1 000 000 (micro-bitcoins, μBTC).

===Bits===

Many have adopted the practice of referring to the micro-bitcoin metric sub-unit as "bits".


==Table of all units==

This table is intended to include all well-defined units of bitcoin value, including less common and niche units.

{| class="wikitable sortable" style="text-align:right;font-family:Console, fixed, monospace"
|-
! Unit !! Abbreviation !! Decimal (BTC) !! Alternate names !! Info
|-
| Algorithmic maximum || || 20,999,999.9769     || || [http://www.wolframalpha.com/input/?i=%28sum%28210000*floor%285000000000%2F2^i%29%29%2C+i%3D0+to+32%29%2F10000000 Calculation]
|- style="background-color:#ddffdd"
| tam-bitcoin || || 2,814,749.76710656 || || 1,0000,0000 tonal
|- style="background-color:#ddddff"
| mega-bitcoin || MBTC || 1,000,000          || || Rare in context
|- style="background-color:#ddddff"
| kilo-bitcoin || kBTC || 1,000          || || Rare in context
|- style="background-color:#ddddff"
| hecto-bitcoin || hBTC || 100          || || Rare
|-
| Initial block subsidy || || 50          || || Until [[Halving day 2012|block 210000]]<ref>{{cite block|209999|year=2012|month=11|day=28|hash=00000000000000f3819164645360294b5dee7f2e846001ac9f41a70b7a9a3de1}}</ref>
|- style="background-color:#ddffdd"
| bong-bitcoin || ᵇTBC || 42.94967296 || || 1,0000 tonal
|-
| Current block subsidy || || 12.5        || block || As of [[Halving day 2016|block 420000]]
|- style="background-color:#ddddff"
| deca-bitcoin || daBTC || 10          || || Rare
|- style="background-color:#ddffdd"
| mill-bitcoin || ᵐTBC || 2.68435456 || || 1000 tonal
|- style="background-color:#ddddff"
| bitcoin || BTC || 1          || coin || SI base unit
|- style="background-color:#ddffdd"
| san-bitcoin || ˢTBC || 0.16777216 || || 100 tonal
|- style="background-color:#ddddff"
| deci-bitcoin || dBTC || 0.1        || || Rare
|- style="background-color:#ddffdd"
| ton-bitcoin || ᵗTBC || 0.01048576 || || 10 tonal
|- style="background-color:#ddddff"
| centi-bitcoin || cBTC || 0.01       || bitcent || Formerly frequent<ref>Bitcents were frequent until the [[November 2013 bubble]]</ref>
|- style="background-color:#ddddff"
| [[millibit|milli-bitcoin]] || mBTC || 0.001      || [[millibit]], millie || Occasional
|- style="background-color:#ddffdd"
| bitcoin || TBC || 0.00065536 || || Tonal base unit
|- style="background-color:#ddffdd"
| bitcoin-ton || TBCᵗ || 0.00004096 || || 0.1 tonal
|- style="background-color:#ddffdd"
| bitcoin-san || TBCˢ || 0.00000256 || || 0.01 tonal
|- style="background-color:#ddddff"
| [[bit (unit)|micro-bitcoin]] || μBTC || 0.000001   || [[bit (unit)|bit]] || Frequent
|- style="background-color:#ddffdd"
| bitcoin-mill || TBCᵐ || 0.00000016 || || 0.001 tonal
|-
| || || 0.0000001  || finney<ref>[http://www.reddit.com/r/Bitcoin/comments/2ewp3z/i_propose_we_rename_00000001_btc_as_the_finney/ After Hal Finney, Bitcoin Pioneer]</ref> ||
|- style="background-color:#ddffdd"
| bitcoin-bong || TBCᵇ || 0.00000001 || || 0.0001 tonal
|-
| || sat || 0.00000001 || [[Satoshi (unit)|satoshi]] || Blockchain value
|-
| || msat || 0.00000000001 || millisatoshi<ref>[https://github.com/ElementsProject/lightning/blob/master/README.md#receiving-and-receiving-payments Receiving and receiving payments]</ref> || [[Lightning Network|Payment channel value]]
|}

==See also==
*[[Tonal Bitcoin]]
*[[Satoshi (unit)]]

==References==
<references />

[[de:Einheiten]]

Units

2017-08-13T02:19:39Z

Taras:

Most commonly, units of bitcoin are expressed in decimal exponents such as BTC ("bitcoins"), mBTC ("millibitcoins") and μBTC ("bits").

==Decimal metric units==

The BTC unit was chosen to represent a value of 108 so as to give sub-unit precision rather than large whole numbers.
Mirroring the standard ''Le Système International d'Unités'', this allows for divisions of 1/10th (deci-bitcoins, dBTC), 1/100th (centi-bitcoins, cBTC), 1/1 000th (milli-bitcoins, mBTC), and 1/1 000 000 (micro-bitcoins, μBTC).

===Bits===

Many have adopted the practice of referring to the micro-bitcoin metric sub-unit as "bits".


==Table of all units==

This table is intended to include all well-defined units of bitcoin value, including less common and niche units.

{| class="wikitable sortable" style="text-align:right;font-family:Console, fixed, monospace"
|-
! Unit !! Abbreviation !! Decimal (BTC) !! Alternate names !! Info
|-
| Algorithmic maximum || || 20,999,999.9769     || || [http://www.wolframalpha.com/input/?i=%28sum%28210000*floor%285000000000%2F2^i%29%29%2C+i%3D0+to+32%29%2F10000000 Calculation]
|- style="background-color:#ddffdd"
| tam-bitcoin || || 2,814,749.76710656 || || 1,0000,0000 tonal
|- style="background-color:#ddddff"
| mega-bitcoin || MBTC || 1,000,000          || || Rare in context
|- style="background-color:#ddddff"
| kilo-bitcoin || kBTC || 1,000          || || Rare in context
|- style="background-color:#ddddff"
| hecto-bitcoin || hBTC || 100          || || Rare
|-
| Initial block subsidy || || 50          || || Until [[Halving day 2012|block 210000]]<ref>{{cite block|209999|year=2012|month=11|day=28|hash=00000000000000f3819164645360294b5dee7f2e846001ac9f41a70b7a9a3de1}}</ref>
|- style="background-color:#ddffdd"
| bong-bitcoin || ᵇTBC || 42.94967296 || || 1,0000 tonal
|-
| Current block subsidy || || 12.5        || block || As of [[Halving day 2016|block 420000]]
|- style="background-color:#ddddff"
| deca-bitcoin || daBTC || 10          || || Rare
|- style="background-color:#ddffdd"
| mill-bitcoin || ᵐTBC || 2.68435456 || || 1000 tonal
|- style="background-color:#ddddff"
| bitcoin || BTC || 1          || coin || SI base unit
|- style="background-color:#ddffdd"
| san-bitcoin || ˢTBC || 0.16777216 || || 100 tonal
|- style="background-color:#ddddff"
| deci-bitcoin || dBTC || 0.1        || || Rare
|- style="background-color:#ddffdd"
| ton-bitcoin || ᵗTBC || 0.01048576 || || 10 tonal
|- style="background-color:#ddddff"
| centi-bitcoin || cBTC || 0.01       || bitcent || Formerly frequent<ref>Bitcents were frequent until the [[November 2013 bubble]]</ref>
|- style="background-color:#ddddff"
| [[millibit|milli-bitcoin]] || mBTC || 0.001      || millibit, millie || Occasional
|- style="background-color:#ddffdd"
| bitcoin || TBC || 0.00065536 || || Tonal base unit
|- style="background-color:#ddffdd"
| bitcoin-ton || TBCᵗ || 0.00004096 || || 0.1 tonal
|- style="background-color:#ddffdd"
| bitcoin-san || TBCˢ || 0.00000256 || || 0.01 tonal
|- style="background-color:#ddddff"
| [[bit (unit)|micro-bitcoin]] || μBTC || 0.000001   || bit || Frequent
|- style="background-color:#ddffdd"
| bitcoin-mill || TBCᵐ || 0.00000016 || || 0.001 tonal
|-
| || || 0.0000001  || finney<ref>[http://www.reddit.com/r/Bitcoin/comments/2ewp3z/i_propose_we_rename_00000001_btc_as_the_finney/ After Hal Finney, Bitcoin Pioneer]</ref> ||
|- style="background-color:#ddffdd"
| bitcoin-bong || TBCᵇ || 0.00000001 || || 0.0001 tonal
|-
| || sat. || 0.00000001 || [[Satoshi (unit)|satoshi]] || Blockchain value
|- style="background-color:#ddddff"
| || || 0.00000000001 || millisatoshi<ref>[https://github.com/ElementsProject/lightning/blob/master/README.md#receiving-and-receiving-payments Receiving and receiving payments]</ref> || [[Lightning Network|Payment channel value]]
|}

==See also==
*[[Tonal Bitcoin]]
*[[Satoshi (unit)]]

==References==
<references />

[[de:Einheiten]]

Majority attack

2017-08-10T09:13:57Z

Taras:

A '''majority attack''' (usually labeled '''51% attack''' or '''>50% attack''') is an attack on the network. This attack has a chance to work even if the merchant waits for some confirmations, but requires extremely high relative hashrate.

The attacker submits to the merchant/network a transaction which pays the merchant, while privately mining a blockchain fork in which a [[double-spending|double-spending transaction]] is included instead. After waiting for ''n'' confirmations, the merchant sends the product. If the attacker happened to find more than ''n'' blocks at this point, he releases his fork and regains his coins; otherwise, he can try to continue extending his fork with the hope of being able to catch up with the network. If he never manages to do this, the attack fails and the payment to the merchant will go through. The work done mining will also go to waste, as any new bitcoins would be overwritten by the longest chain.

The probability of success is a function of the attacker's hashrate (as a proportion of the total network hashrate) and the number of confirmations the merchant waits for. For example, if the attacker controls 10% of the network hashrate but the merchant waits for 6 confirmations, the success probability is on the order of 0.1%. If the attacker controls more than half of the network hashrate, this has a probability of 100% to succeed. Since the attacker can generate blocks faster than the rest of the network, he can simply persevere with his private fork until it becomes longer than the branch built by the honest network, from whatever disadvantage.

No amount of confirmations can prevent this attack; however, waiting for confirmations does increase the aggregate resource cost of performing the attack, which could make it unprofitable or delay it long enough for the circumstances to change or slower-acting synchronization methods to kick in. A majority attack was more feasible in the past when most transactions were worth significantly more than the block reward and when the network hashrate was much lower and prone to reorganization with the advent of new mining technologies.

A majority attack has never been successfully executed on the Bitcoin network, but it has been demonstrated to work on some small altcoins.

See also: [[Weaknesses#Attacker_has_a_lot_of_computing_power]]

==See Also==

* [https://people.xiph.org/~greg/attack_success.html Attack success probability calculator]
* [[Irreversible_Transactions]]

[[Category:Technical]]
[[Category:Attack vectors]]

July 2015 flood attack

2017-08-10T09:10:50Z

Taras:

The '''July 2015 [[flood attack]]''' was a large "stress test" of the Bitcoin network. The possibly distributed attack has provoked hundreds of thousands of [[transaction]]s, leaving over 80,000 in the [[mempool]] at one time.<ref>{{cite reddit|r=Bitcoin|id=3ck5z9|title=80,000 Unconfirmed Transactions right now|date=8 July 2015}}</ref><ref>{{cite btct|id=1113292|title=28 000 unconfirmed TXs|date=7 July 2015|post=11823370}}</ref> The attack is subsequent to stress tests executed in June.

Some charities and organizations, including WikiLeaks and Voat, have received thousands of dust outputs.<ref>{{cite web|last=Pearson|first=Jordan|date=9 July 2015|url=http://motherboard.vice.com/read/wikileaks-is-now-a-target-in-the-massive-spam-attack-on-bitcoin|title=WikiLeaks Is Now a Target In the Massive Spam Attack on Bitcoin|accessdate=10 July 2015|journal=Motherboard|publisher=Vice Media LLC}}</ref><ref name="ok">{{cite reddit|r=technology|id=3cs0ln|title=Voat.co and Wikileaks under attack from Bitcoin spammers|post=https://www.reddit.com/r/technology/comments/3cs0ln/voatco_and_wikileaks_under_attack_from_bitcoin/csyhbzt|date=10 July 2015}}</ref> Additionally, some single-word [[brainwallet]]s ("password", "cat"<ref>{{cite reddit|r=Bitcoin|id=3cgft7|title=Largest transaction ever mined, 999.657 KB. Consumes an entire block.|date=7 July 2015|post=https://www.reddit.com/r/Bitcoin/comments/3cgft7/largest_transaction_ever_mined_999657_kb_consumes/csvbnv4}}</ref>, etc.) have been the recipients of thousands of transactions, leaving 0.00001 BTC outputs. [[F2Pool]] has been concatenating these outputs in huge 1MB transactions.<ref>{{cite tx|bb41a757f405890fb0f5856228e23b715702d714d59bf2b1feb70d8b2b4e3e08}}</ref><ref>{{cite tx|5d8875ed1707cfee2221741b3144e575aec4e0d6412eeffe1e0fa07335f61311}}</ref><ref>{{cite btct|id=1112943|title=New achivement. The biggest tx|date=7 July 2015}}</ref><ref>{{cite reddit|r=Bitcoin|id=3cgft7|title=Largest transaction ever mined, 999.657 KB. Consumes an entire block.|date=7 July 2015}}</ref> These transactions fill up an entire block on their own, and are far too large to be relayed by nodes; they have only been confirmed because F2Pool dedicated blocks to them.<ref>{{cite reddit|r=Bitcoin|id=3cgft7|title=Largest transaction ever mined, 999.657 KB. Consumes an entire block.|date=7 July 2015|post=https://www.reddit.com/r/Bitcoin/comments/3cgft7/largest_transaction_ever_mined_999657_kb_consumes/csvasnz}}</ref><ref name="mb">{{cite web|last=Pearson|first=Jordan|date=9 July 2015|url=http://motherboard.vice.com/read/the-mystery-behind-the-biggest-bitcoin-transaction-ever-made|title=The Mystery Behind the Biggest Bitcoin Transaction Ever Made|accessdate=9 July 2015|journal=Motherboard|publisher=Vice Media LLC}}</ref> Some nodes reported having spent over 20 seconds verifying one of these transactions,<ref>{{cite reddit|r=Bitcoin|id=3cgft7|title=Largest transaction ever mined, 999.657 KB. Consumes an entire block.|date=7 July 2015|post=https://www.reddit.com/r/Bitcoin/comments/3cgft7/largest_transaction_ever_mined_999657_kb_consumes/csva1ei}}</ref> explaining momentary but extreme latency and downtime on block chain explorers.<ref>{{cite reddit|r=Bitcoin|id=3ckhcj|title=Blockchain.info is 10 blocks behind the network|date=8 July 2015}}</ref><ref>{{cite btct|id=1112943|title=New achivement. The biggest tx|date=7 July 2015|post=11823487}}</ref>

[[Gregory Maxwell]] later contacted F2Pool, advising them to use the same signature for each input in the large transactions.<ref>{{cite reddit|r=Bitcoin|id=3cvw52|title=Is this a self-interested or altruistically constructed block?|date=11 July 2015|post=https://www.reddit.com/r/Bitcoin/comments/3cvw52/is_this_a_selfinterested_or_altruistically/cszhxqa}}</ref><ref>{{cite tx|id=9fdbcf0ef9d8d00f66e47917f67cc5d78aec1ac786e2abb8d2facb4e4790aad6}}</ref> This made the transactions highly compressible and far easier to verify.<ref>{{cite reddit|r=Bitcoin|id=3cvw52|title=Is this a self-interested or altruistically constructed block?|date=11 July 2015|post=https://www.reddit.com/r/Bitcoin/comments/3cvw52/is_this_a_selfinterested_or_altruistically/cszic86}}</ref>

As a result of this attack, most mining pools updated their software to produce 1 MB blocks, as originally most capped their blocks at sizes such as 250 kB or 750 kB. The attack seems to have concluded by July 15.<ref>{{cite reddit|r=Bitcoin|title=Transaction mempool back down to normal range: 7k tx.|date=15 July 2015|id=3dbu73}}</ref>

==Motivation==
The attackers may have had an agenda related to the [[blocksize debate]], attempting to demonstrate the infeasibility of 1MB blocks including transactions of hundreds of thousands of users.<ref name="mb"/> Specifically, the Chinese [[mining pool]]s ([[AntPool]], [[BW Mining]], [[F2Pool]], [[BTC China]], & [[Huobi]]) have expressed distaste towards [[Gavin Andresen]]'s proposals to increase the blocksize limit, citing concerns of relatively low bandwidth compared to that available in the United States and Europe.<ref name="mb"/><ref>{{cite web|last=Pearson|first=Jordan|date=16 June 2015|url=http://motherboard.vice.com/read/chinas-powerful-bitcoin-miners-say-their-bandwidth-sucks|title=China's Powerful Bitcoin Miners Say Their Bandwidth Sucks|accessdate=9 July 2015|journal=Motherboard|publisher=Vice Media LLC}}</ref> The flood attack may have been attempting to discredit the pools, and subsequently force them off the network after the raised blocksize limit is in effect.<ref name="mb"/><ref>{{cite btct|id=1089283|title=Hearn's Worst Case Scenario: Checkpoints in XT to "ignore the longest chain"|date=13 June 2015}}</ref>

It is unlikely that the attack was used in an attempt to damage or shut down Bitcoin, as it appears to have been controlled and benevolent.<ref name="mb"/><ref>{{cite reddit|r=Bitcoin|id=3ci9av|title=Could the recent attack on bitcoin be the product of a core developer?|date=8 July 2015|post=https://www.reddit.com/r/Bitcoin/comments/3ci9av/could_the_recent_attack_on_bitcoin_be_the_product/csvtpxk}}</ref> It has also resulted in the donation of over 30 BTC to various sites.<ref name="ok"/>

==Suspects==
[[Coinwallet.eu]], who had executed the previous stress tests, may have something to do with this attack as one of their bitcoin addresses had been used in both efforts.<ref name="mb"/> However, Coinwallet.eu did not announce involvement in this attack, as they had in the stress tests.<ref name="mb"/><ref>{{cite btct|id=1094865|title=Ultimate Bitcoin Stress Test - Monday June 22nd - 13:00 GMT|date=20 June 2015}}</ref>

[[Peter Todd]] had previously offered to execute a stress test for $7,000<ref>{{cite reddit|r=Buttcoin|id=3bk12f|title=Why doesnt buttcoin start its own "stress test"?|date=29 June 2015|post=https://www.reddit.com/r/Buttcoin/comments/3bk12f/why_doesnt_buttcoin_start_its_own_stress_test/csn4nbz}}</ref> but he denies involvement in this attack.<ref>{{cite reddit|r=Bitcoin|id=3ci9av|title=Could the recent attack on bitcoin be the product of a core developer?|date=8 July 2015|post=https://www.reddit.com/r/Bitcoin/comments/3ci9av/could_the_recent_attack_on_bitcoin_be_the_product/csw1e50?context=1}}</ref>

A redditor has published the private keys to hundreds of addresses which have been recipients of dust outputs in 2013, perhaps in an attempt to incite additional spam as redditors try to claim the funds.<ref>{{cite reddit|r=Bitcoin|id=3cf6qg|title=Need help moving coins to new address|post=https://www.reddit.com/r/Bitcoin/comments/3cf6qg/need_help_moving_coins_to_new_address/csuyyi3|date=7 July 2015}}</ref><ref>{{cite reddit|r=Bitcoin|id=3chere|title=Stress Test Giveaway|date=7 July 2015}}</ref>

[[Satoshi Nakamoto]] has been (perhaps jokingly) labeled a suspect,<ref name="mb"/><ref>{{cite reddit|r=Bitcoin|id=3ci9av|title=Could the recent attack on bitcoin be the product of a core developer?|date=8 July 2015|post=https://www.reddit.com/r/Bitcoin/comments/3ci9av/could_the_recent_attack_on_bitcoin_be_the_product/csw750p}}</ref> as he had mentioned that the block size should be increased when it is needed<ref>{{cite btct|id=1347|title=(PATCH) increase block size limit|date=3 October 2010|post=15139}}</ref> and may be campaigning for this change without revealing his involvement.
==References==
<references/>
[[Category:2015 events]]

Private key

2017-08-10T07:12:56Z

Taras:

{{sample}}
A '''private key''' in the context of Bitcoin is a secret number that allows bitcoins to be spent.
Every Bitcoin wallet contains one or more private keys, which are saved in the wallet file.
The private keys are mathematically related to all Bitcoin addresses generated for the wallet.

Because the private key is the "ticket" that allows someone to spend bitcoins, it is important that these are kept secure.
Private keys can be kept on computer files, but in some cases are also short enough that they can be printed on paper.

Some wallets allow private keys to be imported without generating any transactions while other wallets or services require that the private key be swept.
When a private key is swept, a transaction is broadcast that sends the balance controlled by the private key to a new address in the wallet.
Just as with any other transaction, there is risk of swept transactions to be double-spending.

In contrast, bitcoind provides a facility to import a private key without creating a sweep transaction.
This is considered very dangerous, and not intended to be used even by power users or experts except in very specific cases.
Bitcoins can be easily stolen at any time, from a wallet which has imported an untrusted or otherwise insecure private key - this can include private keys generated offline and never seen by someone else<ref>[https://bitcoin.stackexchange.com/questions/29948/why-doc-says-importing-private-keys-is-so-dangerous Bitcoin StackExchange - Why doc says importing private keys is so dangerous?]</ref><ref>[https://bitcoin.stackexchange.com/questions/18619/why-so-many-warnings-about-importing-private-keys Bitcoin StackExchange - Why so many warnings about importing private keys?]</ref>.

==An example private key==
In Bitcoin, a private key is usually a 256-bit number (some newer wallets may use between 128 and 512 bits), which can be represented one of several ways.
Here is a private key in hexadecimal - 256 bits in hexadecimal is 32 bytes, or 64 characters in the range 0-9 or A-F.

E9873D79C6D87DC0FB6A5778633389{{taggant private key}}F4453213303DA61F20BD67FC233AA33262

==Range of valid ECDSA private keys==
Nearly every 256-bit number is a valid [[ECDSA]] private key. Specifically, any 256-bit number from 0x1 to 0xFFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFE BAAE DCE6 AF48 A03B BFD2 5E8C D036 4140 is a valid private key.

The range of valid private keys is governed by the [[secp256k1]] ECDSA standard used by Bitcoin.

Newer wallets may use [[BIP 0032|BIP 32]] seeds for their private keys, which can be as long as 512 bits.

==Base58 Wallet Import format==
{{main|Wallet import format}}
When importing or sweeping ECDSA private keys, a shorter format known as [[wallet import format]] is often used, which offers a few advantages.
The wallet import format is shorter, and includes built-in error checking codes so that typos can be automatically detected and/or corrected (which is impossible in hex format) and type bits indicating how it is intended to be used.
Wallet import format is the most common way to represent private keys in Bitcoin.
For private keys associated with uncompressed public keys, they are 51 characters and always start with the number 5 on mainnet (9 on testnet). Private keys associated with compressed public keys are 52 characters and start with a capital L or K on mainnet (c on testnet). This is the same private key in (mainnet) wallet import format:

5Kb8kLf9zgWQnogidDA76Mz{{taggant private key}}PL6TsZZY36hWXMssSzNydYXYB9KF

When a WIF private key is imported, it always corresponds to exactly one [[Address|Bitcoin address]].
Any utility which performs the conversion can display the matching Bitcoin address.
The mathematical conversion is somewhat complex and best left to a computer, but it's notable that the WIF guarantees it will always correspond to the same address no matter which program is used to convert it.

The Bitcoin address implemented using the sample above is: 1CC3X2gu58d6wXUW{{taggant address}}MffpuzN9JAfTUWu4Kj

==Mini private key format==
{{main|Mini private key format}}
Some applications use the [[mini private key format]]. Not every private key or Bitcoin address has a corresponding mini private key - they have to be generated a certain way in order to ensure a mini private key exists for an address. The mini private key is used for applications where space is critical, such as in QR codes and in [[physical bitcoins]]. The above example has a mini key, which is:

SzavMBLoXU6{{taggant private key}}kDrqtUVmffv

==Summary==
Any Bitcoins sent to the address 1CC3X2gu58d6wXUW{{taggant address}}MffpuzN9JAfTUWu4Kj can be spent by anybody who knows the private key implementing it in ''any'' of the three formats, regardless of when the bitcoins were sent, unless the wallet receiving them has since made use of the coins generated.
The private key is only needed to spend the bitcoins, not necessarily to see the value of them.

If a private key controlling unspent bitcoins is compromised or stolen, the value can only be protected if it is immediately spent to a different output which is secure.
Because bitcoins can only be spent once, when they are spent using a private key, the private key becomes worthless.
It is often possible, but inadvisable and insecure, to use the address implemented by the private key again, in which case the same private key would be [[Address reuse|reused]].

==See Also==

* [[Paper wallet]]
* [[How to import private keys]]
* [[How to import private keys v7+]]

==References==
<references />

[[es:Clave privada]]

Wallet import format

2017-08-10T07:01:59Z

Taras: Some more taggants just in case

{{sample}}
Wallet Import Format (WIF, also known as Wallet Export Format) is a way of encoding a private ECDSA key so as to make it easier to copy.

A testing suite is available for encoding and decoding of WIF at:

http://gobittest.appspot.com/PrivateKey

==Private key to WIF==
1 - Take a private key
0C28FCA386C7A227600B2FE50B7CAE{{taggant private key}}11EC86D3BF1FBE471BE89827E19D72AA1D
2 - Add a 0x80 byte in front of it for mainnet addresses or 0xef for testnet addresses. Also add a 0x01 byte at the end if the private key will correspond to a compressed public key
800C28FCA386C7A227600B2FE50B7C{{taggant private key}}AE11EC86D3BF1FBE471BE89827E19D72AA1D
3 - Perform SHA-256 hash on the extended key
8147786C4D15106333BF278D71DADAF1079EF2D2440A4DDE37D747DED5403592
4 - Perform SHA-256 hash on result of SHA-256 hash
507A5B8DFED0FC6FE8801743720CEDEC06AA5C6FCA72B07C49964492FB98A714
5 - Take the first 4 bytes of the second SHA-256 hash, this is the checksum
507A5B8D
6 - Add the 4 checksum bytes from point 5 at the end of the extended key from point 2
800C28FCA386C7A227600B2FE50B7CAE11EC8{{taggant private key}}6D3BF1FBE471BE89827E19D72AA1D507A5B8D
7 - Convert the result from a byte string into a base58 string using [[Base58Check encoding]]. This is the Wallet Import Format
5HueCGU8rMjxEXxiPuD5BDk{{taggant private key}}u4MkFqeZyd4dZ1jvhTVqvbTLvyTJ

==WIF to private key==
1 - Take a Wallet Import Format string
5HueCGU8rMjxEXxiPuD5BDk{{taggant private key}}u4MkFqeZyd4dZ1jvhTVqvbTLvyTJ
2 - Convert it to a byte string using [[Base58Check encoding]]
800C28FCA386C7A227600B2FE50B7CAE11EC{{taggant private key}}86D3BF1FBE471BE89827E19D72AA1D507A5B8D
3 - Drop the last 4 checksum bytes from the byte string
800C28FCA386C7A227600B2FE50B7CAE11EC86D3BF1FBE471BE89827E19D72AA1D
4 - Drop the first byte (it should be 0x80). If the private key corresponded to a compressed public key, also drop the last byte (it should be 0x01). If it corresponded to a compressed public key, the WIF string will have started with K or L instead of 5 (or c instead of 9 on testnet). This is the private key.
0C28FCA386C7A227600B2FE50B7CAE1{{taggant private key}}1EC86D3BF1FBE471BE89827E19D72AA1D
==WIF checksum checking==
1 - Take the Wallet Import Format string
5HueCGU8rMjxEXxiPuD5BD{{taggant private key}}ku4MkFqeZyd4dZ1jvhTVqvbTLvyTJ
2 - Convert it to a byte string using [[Base58Check encoding]]
800C28FCA386C7A227600B2FE50B7CAE11E{{taggant private key}}C86D3BF1FBE471BE89827E19D72AA1D507A5B8D
3 - Drop the last 4 checksum bytes from the byte string
800C28FCA386C7A227600B2FE50B7CAE11EC86D3BF1FBE471BE89827E19D72AA1D
3 - Perform SHA-256 hash on the shortened string
8147786C4D15106333BF278D71DADAF1079EF2D2440A4DDE37D747DED5403592
4 - Perform SHA-256 hash on result of SHA-256 hash
507A5B8DFED0FC6FE8801743720CEDEC06AA5C6FCA72B07C49964492FB98A714
5 - Take the first 4 bytes of the second SHA-256 hash, this is the checksum
507A5B8D
6 - Make sure it is the same, as the last 4 bytes from point 2
507A5B8D
7 - If they are, and the byte string from point 2 starts with 0x80 (0xef for testnet addresses), then there is no error.

{{Stub}}
{{Bitcoin Core documentation}}

Wallet import format

2017-08-10T06:56:38Z

Taras: Added taggants to the sample private keys, a user accidentally sent 1 BTC to one believing it was their own after having imported it as a test a while earlier

{{sample}}
Wallet Import Format (WIF, also known as Wallet Export Format) is a way of encoding a private ECDSA key so as to make it easier to copy.

A testing suite is available for encoding and decoding of WIF at:

http://gobittest.appspot.com/PrivateKey

==Private key to WIF==
1 - Take a private key
0C28FCA386C7A227600B2FE50B7CAE11EC86D3BF1FBE471BE89827E19D72AA1D
2 - Add a 0x80 byte in front of it for mainnet addresses or 0xef for testnet addresses. Also add a 0x01 byte at the end if the private key will correspond to a compressed public key
800C28FCA386C7A227600B2FE50B7CAE11EC86D3BF1FBE471BE89827E19D72AA1D
3 - Perform SHA-256 hash on the extended key
8147786C4D15106333BF278D71DADAF1079EF2D2440A4DDE37D747DED5403592
4 - Perform SHA-256 hash on result of SHA-256 hash
507A5B8DFED0FC6FE8801743720CEDEC06AA5C6FCA72B07C49964492FB98A714
5 - Take the first 4 bytes of the second SHA-256 hash, this is the checksum
507A5B8D
6 - Add the 4 checksum bytes from point 5 at the end of the extended key from point 2
800C28FCA386C7A227600B2FE50B7CAE11EC86D3BF1FBE471BE89827E19D72AA1D507A5B8D
7 - Convert the result from a byte string into a base58 string using [[Base58Check encoding]]. This is the Wallet Import Format
5HueCGU8rMjxEXxiPuD5BDk{{taggant private key}}u4MkFqeZyd4dZ1jvhTVqvbTLvyTJ

==WIF to private key==
1 - Take a Wallet Import Format string
5HueCGU8rMjxEXxiPuD5BDk{{taggant private key}}u4MkFqeZyd4dZ1jvhTVqvbTLvyTJ
2 - Convert it to a byte string using [[Base58Check encoding]]
800C28FCA386C7A227600B2FE50B7CAE11EC86D3BF1FBE471BE89827E19D72AA1D507A5B8D
3 - Drop the last 4 checksum bytes from the byte string
800C28FCA386C7A227600B2FE50B7CAE11EC86D3BF1FBE471BE89827E19D72AA1D
4 - Drop the first byte (it should be 0x80). If the private key corresponded to a compressed public key, also drop the last byte (it should be 0x01). If it corresponded to a compressed public key, the WIF string will have started with K or L instead of 5 (or c instead of 9 on testnet). This is the private key.
0C28FCA386C7A227600B2FE50B7CAE11EC86D3BF1FBE471BE89827E19D72AA1D
==WIF checksum checking==
1 - Take the Wallet Import Format string
5HueCGU8rMjxEXxiPuD5BD{{taggant private key}}ku4MkFqeZyd4dZ1jvhTVqvbTLvyTJ
2 - Convert it to a byte string using [[Base58Check encoding]]
800C28FCA386C7A227600B2FE50B7CAE11EC86D3BF1FBE471BE89827E19D72AA1D507A5B8D
3 - Drop the last 4 checksum bytes from the byte string
800C28FCA386C7A227600B2FE50B7CAE11EC86D3BF1FBE471BE89827E19D72AA1D
3 - Perform SHA-256 hash on the shortened string
8147786C4D15106333BF278D71DADAF1079EF2D2440A4DDE37D747DED5403592
4 - Perform SHA-256 hash on result of SHA-256 hash
507A5B8DFED0FC6FE8801743720CEDEC06AA5C6FCA72B07C49964492FB98A714
5 - Take the first 4 bytes of the second SHA-256 hash, this is the checksum
507A5B8D
6 - Make sure it is the same, as the last 4 bytes from point 2
507A5B8D
7 - If they are, and the byte string from point 2 starts with 0x80 (0xef for testnet addresses), then there is no error.

{{Stub}}
{{Bitcoin Core documentation}}