Bitcoin Wiki - User contributions [en]

User talk:NotATether

2024-02-28T03:06:35Z

Ysangkok: /* Fixed GPG screenshot */ new section

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

== Comparison of gift card services ==

- Bitrefill

- Coinsbee

== Fixed GPG screenshot ==

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

Electrum

2024-02-28T03:06:07Z

Ysangkok: Fix screenshot of GPG failure

[[Image:Electrum_logo.png|400px]][[Image:Capture-Electrum404.jpg|thumb|500px|Electrum 4.0.4 on Windows 7 with showing zero balance and a connected state]]

[https://electrum.org Electrum] is a lightweight Bitcoin client, based on a client-server protocol.
It was released on 5 November 2011.

== Main features ==
* Encrypted wallet: the file that contains bitcoin [[private keys]] is protected with a password, and never leaves the user's computer.
* Deterministic key generation: If you lose your wallet file, you can recover it from its [[seed phrase|seed]]. You are protected from your own mistakes. (Note that Electrum's seed phrase is not according to the BIP39 standard.)
* Instant on: by default the client does not download the blockchain, it requests that information from a server. No delays, always up-to-date.
* Transactions are signed locally: Your private keys are not shared with the server. You do not have to trust the server with your money.
* [[Cold storage]]: Keeping private keys offline is supported. Has a watch-only mode for online use.
* [[Multi-signature]]: Dividing the power to spend coins between multiple wallets is supported.
* [[Hardware wallet]] integration: Many leading hardware wallets can interface with Electrum, including [[Coldcard]], [[Trezor]] and [[Ledger]].
* Redundancy: You are not tied to a particular server, and the server does not need to know you. One server going down doesn't cause user downtimes.
* No single point of failure: The server code is open source, anyone can run a server. Private keys can be exported and imported into other wallets.
* Firewall friendly: The client does not need to open a port, it simply polls the server for updates.
* Free software: MIT License. Anyone can audit the code.
* Written in Python. The code is short, and easy to review.
* Add-ons: third-party plugins are supported.
* Support for Bitcoin URIs, signed URIs and Bitcoin aliases

__TOC__

== Verifying Electrum Binaries ==

Electrum binaries can be downloaded from https://electrum.org/#download. Next to each download link there is also a signature file which can be downloaded. The signature files are for independently verifying the Electrum files were not tampered with. This step should not be overlooked as users have reported malicious funds-stealing builds of Electeum existing in the wild.

To verify the Electrm binaries using the signatures, you need to have GPG installed. Listed below is the process for each operating system. For all operating systems, you must have Electrum's signing key downloaded to verify the Electrum binaries. This can be downloaded from https://raw.githubusercontent.com/spesmilo/electrum/master/pubkeys/ThomasV.asc.

=== Windows ===

Windows 10 has "Ubuntu on Windows" and allows you ton follow the Linux instructions [[#Linux|below]]

On Windows, you should install GPG4Win from this location: https://gpg4win.org/download.html. Once you run the installer, you will be presented with a "components choosing dialog like this:

[[File:GPG4Win-Install.png]]

Leave the boxes ticked at their defaults and go to the next step of the installer. When the installation is finished, go to the Windows Start Menu and look for a program named "Kleopatra", and launch it. If you see the following window then GPG4Win has been successfully installed.

[[File:GPG4Win-Kleopatra.png]]

Click on the Import button, and navigate to the location you saved the Electrum signing key in (you may have to change the Filter at the bottom right to "All Files" to see the key). Then Kleopatra will give you a message requesting to certify the key:

[[File:GPG4Win-Certify.png]]

Click yes, and then tick all of the email addresses in the next window to finish the process.

[[File:GPG4Win-Email.png]]

After you close the window by clicking the Certify button, click on the Decrypt/Verify button on the main window, and select the signature corresponding to the Electrum binary you have downloaded. If verification is successful, you will get the following window. Otherwise, the signature doesn't match the binary, and you need to download both of them again, and check the URL of the site you are downloading from.

[[File:GPG4Win-Verify.png|none|frame|The Kleopatra message when signature verification succeeds.]]

[[File:GPG4Win-VerifyFail.png|none|frame|The Kleopatra error message when signature verification fails.]]

=== MacOS ===

On MacOS, you should use the GPG tools suite from GPGTools: https://gpgtools.org/. Download the .dmg file, double click on it and drag its contents to the Applications folder that appears to start the installation.

Inside the installer, click on the Customize button, and uncheck the boxes for the Mail clients. They are not necessary to verify signatures, and are trialware.

[[File:GPGTools-Customize.png]][[File:GPGTools-Mail.png]]

After the installer is finished, GPG Keychain should open automatically. If not, then open Finder and navigate to the Applications folder to open it yourself. You will be presented with this dialog:

[[File:GPGTools-NewKey.png]]

GPG Keychain needs to create a keypair to certify other public keys. Choose a name, email address and password that you will remember. Leave the rest of the options at their default and click on Generate Key.

In the main window that appears, click on the Import button to import the Electrum signing key you downloaded.

[[File:GPGTools-MainWindow.png]]

Once it has been imported, double-click on the key to open its properties, and set its trust level to Full.

[[File:GPGTools-Properties.png]]

Then, you can just double click inside Finder on the Electrum signature for the corresponding binary to start GPG Keychain verification which will inform you about the result and whether the signature and binary are good or not.

[[File:GPGTools-Verify.png|none|frame|The GPG Keychain message when signature verification succeeds.]]

[[File:GPGTools-VerifyFail.png|none|frame|The GPG Keychain error message when signature verification fails.]]

=== Linux ===

On Linux, the <code>gpg</code> command line program is preinstalled in most distributions. If for some reason it's not, look for a package called "gnupg", "gpg" or "gpg2" in your package manager.

Once that's done with, you run the following GPG commands to import and trust the key which Electrum binaries are signed with, and the signature files are made from:

<code>gpg --import /<path>/<to>/<file>/<location>/ThomasV.asc</code>

[[File:GPG-Import.png]]

<code>gpg --sign-key 6694D8DE7BE8EE5631BED9502BD5824B7F9470E6</code>

Then you download the Electrum program and its signature to the same folder, and check its authenticity with the following GPG command:

<code>gpg --verify /<path>/<to>/<file>/<location>/<filename>.asc</code>

This is the path to the signature file you downloaded. If verification succeeds, you will get output indicating that the verification was successful.

[[File:GPG-Verify.png|none|frame|The GPG message when signature verification succeeds.]]

[[File:GPG-VerifyFail.png|none|frame|The GPG message when signature verification fails.]]

==Documentation==

Documentation is hosted on http://docs.electrum.org/.

It includes tutorials for the multi-signature, cold storage and hardware wallet features.

==History==

Electrum was announced 5 November 2011.<ref>[http://bitcointalk.org/index.php?topic=50936.0 Electrum - a new thin client]</ref>. It has since gone through many changes in each version.

[[Image:Capture-Electrum.png|thumb|500px|An early version of Electrum with its Qt GUI]]

Version 1.7 added support for third-party plugins.

Version 2.0 introduced support for the [[Trezor]] hardware wallet, TrustedCoin 2FA, [[multisig]] wallets and changed the way the wallet files are stored by using [[BIP_0032|BIP32]] derivation. These wallets are incompatible with older versions.

Version 2.4.3 added support for the [[Hardware_wallet#KeepKey:_Your_Private_Bitcoin_Vault|KeepKey]] hardware wallet.

Version 2.6 introduced the new Kivy GUI for the Android client.

Version 2.7 added a fee slider, [[RBF]] functionality and support for [[Hardware_wallet#Ledger_Nano_S|Ledger Nano S]]. The wallet format has also been changed, making them incompatible with older versions.

Version 3.0 introduced a new server protocol and support for generating [[Segwit]] wallets.

On December 27, 2018, an advisory was published<ref>[https://bitcointalk.org/index.php?topic=5090097.0 Electrum vulnerability allows arbitrary messages, phishing]</ref> about a phishing vulnerability where the server returns a a fake update message after a transaction is broadcasted, with a link to a phishing domain with a malicious Electrum binary. Users who ran the malicious binary reported theft of all bitcoin funds. A mitigation was applied in version 3.2.1 which renders the rich-text message in plain-text, making it less convincing.

Version 4.0.0 introduced support for [[Lightning Network]] wallets.

== Server software ==

The server code is open source, anyone can run a server. There are several implementations.

Public Electrum servers run by strangers can easily spy on Electrum users. For this reason many people run their own server. For maximum [[Full node#Why should you use a full node wallet|trustlessness, privacy and security]]; users should point Electrum to their own servers.

=== bwt ===

'''bwt''' is a lightweight and performant HD wallet indexer backed by a bitcoin full node that [https://github.com/shesek/bwt#electrum-plugin can also be installed as an Electrum plugin].

=== ElectrumX ===

ElectrumX is the latest iteration of general purpose Electrum servers. Written in Python, it tries to be as efficient as possible to keep synchronization times low. ElectrumX is able to serve thousands of clients at once, it is suited to be an always-on server that contributes to bitcoin. Make sure that the version of ElectrumX you download supports Bitcoin. As of May 2020 some versions of ElectrumX only support [[altcoin]]s.

GitHub: https://github.com/spesmilo/electrumx



=== Electrum Personal Server ===

Electrum Personal Server has a different approach to a normal server. It is intended to be used by a single person only. Instead of creating a database of every transaction and address ever used on the bitcoin blockchain, Electrum Personal Server only tracks the user's own wallets. This allows it to be much more efficient with resources, it does not need any extra data files and is compatible with [[Bitcoin Core]]'s pruning feature.

Electrum Personal Server is probably the best way to combine Electrum's feature-richness (hardware wallet integration, multi-signature, [[seed phrase]], etc) with a [[full node]]'s strong security and privacy.

GitHub: https://github.com/chris-belcher/electrum-personal-server

==See also==

* [[Thin Client Security]]
* [[Hardware wallet]]
* [[Seed phrase]]
* [[Multi-signature]]
* [[Cold storage]]

==External Links==

* [http://electrum.org/ Electrum] project website
* [https://github.com/spesmilo/electrum/ Electrum] project source

==References==
<references />

[[Category:Clients]]
[[Category:Open Source]]

People

2021-03-01T22:39:35Z

Ysangkok: /* See Also */ add link to template:developers

A short list of active contributors to Bitcoin, ordered by first name.

[[Andreas Schildbach]] ([https://profiles.google.com/andreas.schildbach Profile]) - original developer of [https://market.android.com/details?id=de.schildbach.wallet Bitcoin Wallet for Android] ([http://code.google.com/p/bitcoin-wallet/ Google Code Project]).

[[Amir Taaki]] ([http://en.wikipedia.org/wiki/Amir_Taaki Wikipedia]) aka genjix- creator of the [[BIP]] process, [[Libbitcoin]] C++ developer toolkit, [[Libbitcoin_Server|Obelisk]] blockchain server (later BS), [[Libbitcoin_Explorer|SX]] bitcoin command line tool (later BX), [https://bitcoinmagazine.com/7892/shedding-light-on-the-dark-wallet Darkwallet], [http://www.wired.com/2014/04/darkmarket Darkmarket] (later [https://openbazaar.org OpenBazaar]), [http://reason.com/blog/2015/02/24/darkleaks-the-decentralized-information Darkleaks], [[Freecoin]] and well as inactive/defunct projects such as the [[Britcoin]] exchange, [[Intersango]] exchange, [[Spesmilo]] RPC client, [[Bitcoin Consultancy]], Bitcoin Media Blog (author), [[Vibanko]] web wallet provider, [[GLBSE]] exchange client, [https://github.com/genjix/kartludox Kartludox] Bitcoin poker client, [[Pastecoin]] and Python bindings for Bitcoin.

[[ArtForz|Art Forz]]- developed the first GPU miner and at one time his GPU mining farm (the ArtFarm) was mining over a third of all blocks.

[[Gary Rowe]] ([https://plus.google.com/u/0/115295932487523951663/about Profile ]) - Contributor to the [[MultiBit]] (http://multibit.org) and [[BitCoinJ]] (http://code.google.com/p/bitcoinj/) projects. Working on various Bitcoin based businesses.

[[User:Gavinandresen|Gavin Andresen]] - ([https://profiles.google.com/u/0/gavinandresen/about Profile ]) Former [[Satoshi client]] maintainer. He previously worked at Silicon Graphics and now runs his own company.

[[Hal Finney]]- one of the creators of [http://en.wikipedia.org/wiki/Pretty_Good_Privacy PGP] and one of the earliest contributors to the Bitcoin project. First to identify a type of double-spending attack that now bears his name -- the [[Double-spending#Finney_attack|Finney attack]].

James McCarthy aka Nefario- creator of the first bitcoin stock exchange [[GLBSE]]

[[Jed McCaleb]], cofounder of Stellar.org and original developer of [[MtGox]]. Previously created [https://en.wikipedia.org/wiki/EDonkey2000 eDonkey2000].

[[Jeff Garzik]]- [[Satoshi client]] core developer, GPU poold software and the founder of [[Bitcoin Watch]]. Works for BitPay.

[[Luke Dashjr]] aka Luke-Jr- [[Eligius]] founder, maintains [[BFGMiner]] and maintainer of [[bitcoind]]/[[Bitcoin-Qt]] stable branches.

[[Mark Karpeles]] ([https://en.wikipedia.org/wiki/Mark_Karpeles Wikipedia]) aka MagicalTux- Former owner of [[MtGox]] and this wiki.

[[Sirius|Martti Malmi]] aka Sirius- Former Bitcoin developer. Operates the domain names bitcoin.org and bitcointalk.org.

[[Matt Corallo]] aka BlueMatt- [[Satoshi client]] and [[Bitcoinj]] developer.

[[Michael Hendrix]] aka mndrix- creator of the now defunct CoinPal and CoinCard services

[[Mike Hearn]] ([https://profiles.google.com/mh.in.england/about Profile]) Google engineer who works on Gmail and developed [[BitCoinJ]] (http://code.google.com/p/bitcoinj/) and [[Lighthouse]].

[[User:Tcatm|Nils Schneider]] aka tcatm - Bitcoin developer, owner of BitcoinWatch, creator and owner of BitcoinCharts, GPU mining software and JS web interface.

[[Patrick McFarland]] aka Diablo-D3 - DiabloMiner author, and former BitcoinTalk forum moderator.

[[Patrick Strateman]] aka phantomcircuit - Bitcoin developer, creator of [[Intersango]], member of [[Bitcoin Consultancy]] and creator of Python Bitcoin implementation.

[[Peter Todd]] - Bitcoin developer. Involved with Bitcoin related startup [[Coinkite]] and [[DarkWallet]].

[[Pieter Wuille]] aka sipa- [[Satoshi client]] developer and maintainer of the network graphs http://bitcoin.sipa.be

[[Stefan Thomas]] aka justmoon- creator of the ([https://www.weusecoins.com We Use Coins]) site/video and WebCoin.

[[Tamas Blummer]] aka grau - author of Bits of Proof, the enterprise-ready implementation of the Bitcoin protocol. http://bitsofproof.com

[[Trace Mayer]] - Host of the ([http://www.bitcoin.kn Bitcoin Knowledge Podcast]) where the top people in Bitcoin are interviewed

[[Vladimir Marchenko]]- ([https://profiles.google.com/u/0/vmartchenko/about?hl=en Profile]), runs [[Marchenko Ltd]] which sells mining contracts, previously developed the figator.org search engine.

[[Wladimir van der Laan]] - [[Satoshi client]] maintainer.

==See Also==
* [[Original client developers]]
* [[Developers]]
* [[:Template:Developers]]
* Wiki list of [[:Special:ListUsers|users]]
* [[Project:Community_portal|Community portal]]
* [[:Category:People]]

Amir Taaki

2021-03-01T22:37:54Z

Ysangkok: /* Active Creations */ add electrum contributions

==Active Creations==
* [[BIP]] process and several proposals
* [[Libbitcoin]] C++ developer toolkit
* [[Obelisk]] blockchain server (later [[Libbitcoin_Server|Bitcoin Server (bs)]])
* [[SubvertX|SubvertX (sx)]] Bitcoin command line application (later [[Libbitcoin_Explorer|Bitcoin Explorer (bx)]])
* [http://www.wired.com/2014/04/darkmarket Darkmarket] (later [https://openbazaar.org OpenBazaar])
* [[Freecoin]]
* [[Pastecoin]]
* Some work on Electrum in 2012[https://github.com/spesmilo/electrum/commits?author=genjix]

==Defunct or Inactive Creations==
* [[Britcoin]] exchange
* [[Intersango]] exchange
* [[Spesmilo]] RPC client
* [[Bitcoin Consultancy]]
* Bitcoin Media Blog author
* [[Vibanko]] web wallet provider
* [[GLBSE]] exchange client
* [https://github.com/genjix/kartludox Kartludox] Bitcoin poker room<ref>[http://forumserver.twoplustwo.com/28/internet-poker/rake-free-open-poker-room-run-poker-community-938389 Rake-Free & Open Poker Room, Run By the Poker Community?]</ref>
* Python bindings for bitcoin 
* [https://bitcoinmagazine.com/7892/shedding-light-on-the-dark-wallet Darkwallet]
* [http://reason.com/blog/2015/02/24/darkleaks-the-decentralized-information Darkleaks]

==See Also==
* [[User:Genjix]]
* [[Developers]]
* [[People]]
* [https://en.wikipedia.org/wiki/Amir_Taaki Wikipedia profile]

==References==
[[Category:People]]

Peter Todd

2021-03-01T22:25:19Z

Ysangkok:

Bitcoin developer. Involved with Bitcoin related startup Coinkite and DarkWallet.

He has also been involved with [[OpenTimestamps]], which features [[Merkle Mountain Range]]s.<ref>https://github.com/opentimestamps/opentimestamps-server/blob/master/doc/merkle-mountain-range.md</ref> This invention is broadly applicable.

He has also been involved with a [[Zcash]] (an altcoin featuring zkSNARKS) key signing ceremony, and some drama regarding its security.<ref>https://twitter.com/peterktodd/status/1062847331949699072</ref>

==References==
<references />

[[Category:People]]

Adam Back

2021-03-01T22:16:15Z

Ysangkok: add some links to segwit2x resistance

{{stub}}

Adam Back is a British cryptographer and crypto-hacker notable as the inventor of [[Hashcash]], the [[proof-of-work]] system used by [[Bitcoin]].

He is currently CEO at [[Blockstream]].<ref>http://adam3.us/about/</ref> Other employees at Blockstream have included [[Pieter Wuille]], [[Gregory Sanders]], [[Matt Corallo]], [[Mark Friedenbach]], [[Jorge Timón]].

Back was an opponent of [[SegWit2x]].<ref>[https://twitter.com/adam3us/status/913495697936277504 Tweet by Adam Back (adam3us) saying ''segwit2x is very likely to degrade into "paypal2.0" permissioned bank. those unaware of history/too stubborn to learn, are doomed to repeat.'']</ref><ref>[https://www.reddit.com/r/Bitcoin/comments/72ryef/it_is_time_to_call_off_nyasegwit2x_and_work/ Adam Back (adam3us) post on Reddit: ''It is time to call off NYA/segwit2x and work together to scale Bitcoin to compete against Fiat. Please.'']</ref>

== See also ==
* https://en.wikipedia.org/wiki/Adam_Back

==References==
<references />

Jeff Garzik

2021-03-01T22:04:10Z

Ysangkok: add some segwit2x details and a quote

{{infobox person|name=Jeff Garzik|image=[[File:Jgarzik.jpg|256px]]
|active=2010–2015
|residence=Atlanta, Georgia
|twitter=jgarzik
|reddit=jgarzik
|bitcoinwiki=Jgarzik
|bitcointalk=541
}}'''Jeff Garzik''', Co-Founder of [http://bloq.com/ Bloq Inc], was a [https://github.com/bitcoin/bitcoin/commits?author=jgarzik contributor to Bitcoin Core] before and including 2015.

Garzik was a participant in the [[SegWit2x]] debacle. At one point, Garzik was against raising the block size.<ref>[https://www.reddit.com/r/btc/comments/htss6k/banned_for_lying_on_rbitcoin_when_a_mod_was/fyl1fer/ ''I am against changing block size, FWIW. I think the market will properly intervene, bitcoin will reach a steady state where all blocks are 1MB, and the best bidding gets block placement." also "IMO I think the current bitcoin's endgame is as a not-high-volume settlement network.'']</ref>

==References==
<references/>

{{developers}}{{stub}}

[[Category:Core committers]]
[[Category:Core developers]]
{{wp|Jeff Garzik}}

Gavin Andresen

2021-03-01T21:50:37Z

Ysangkok: not active after 2016 afaik

{{infobox person|name=Gavin Andresen|image=[[File:Gavin Andresen.jpg|256px]]
|active=2010–2016
|born=1966 (aged 48–49)
|residence=Amherst, Massachusetts
|twitter=gavinandresen
|reddit=gavinandresen
|bitcoinwiki=Gavinandresen
|bitcointalk=224
}}'''Gavin Andresen''' was the Chief Scientist for the [[Bitcoin_Foundation|Bitcoin Foundation]].

Previously a Bitcoin committer, Andresen resigned in 2014.<ref>[https://bitcoinfoundation.org/files/2014/04/bitcoin-core-maintainer-wladimir-van-der-laan/ Bitcoin Core Maintainer: Wladimir van der Laan]</ref> In 2016, Andresen says he believed that [[Craig Steven Wright]] is [[Satoshi Nakamoto]].<ref>[https://www.wired.com/2016/05/craig-wright-privately-proved-hes-bitcoins-creator/ Wired piece from 2016 with input from Andresen]</ref>

The Bitcoin Foundation and its members have been accused of being scammers.<ref>''[https://www.reddit.com/r/btc/comments/lrculy/csws_big_news_to_sv_holders_he_teased_yesterday/goocdwi/ ...scum sucking brethren at the Bitcoin Foundation ...]''</ref>

==References==
<references/>

{{s-start|Bitcoin [[Core maintainer]]|[[Satoshi Nakamoto]]|2011–2014|[[Wladimir van der Laan]]}}
{{developers}}{{stub}}

[[Category:Core committers]]
[[Category:Core developers]]
{{wp|Gavin_Andresen}}

Gavin Andresen

2021-03-01T21:45:52Z

Ysangkok: add some key moments of his life

{{infobox person|name=Gavin Andresen|image=[[File:Gavin Andresen.jpg|256px]]
|active=2010–present
|born=1966 (aged 48–49)
|residence=Amherst, Massachusetts
|twitter=gavinandresen
|reddit=gavinandresen
|bitcoinwiki=Gavinandresen
|bitcointalk=224
}}'''Gavin Andresen''' was the Chief Scientist for the [[Bitcoin_Foundation|Bitcoin Foundation]].

Previously a Bitcoin committer, Andresen resigned in 2014.<ref>[https://bitcoinfoundation.org/files/2014/04/bitcoin-core-maintainer-wladimir-van-der-laan/ Bitcoin Core Maintainer: Wladimir van der Laan]</ref> In 2016, Andresen says he believed that [[Craig Steven Wright]] is [[Satoshi Nakamoto]].<ref>[https://www.wired.com/2016/05/craig-wright-privately-proved-hes-bitcoins-creator/ Wired piece from 2016 with input from Andresen]</ref>

The Bitcoin Foundation and its members have been accused of being scammers.<ref>''[https://www.reddit.com/r/btc/comments/lrculy/csws_big_news_to_sv_holders_he_teased_yesterday/goocdwi/ ...scum sucking brethren at the Bitcoin Foundation ...]''</ref>

==References==
<references/>

{{s-start|Bitcoin [[Core maintainer]]|[[Satoshi Nakamoto]]|2011–2014|[[Wladimir van der Laan]]}}
{{developers}}{{stub}}

[[Category:Core committers]]
[[Category:Core developers]]
{{wp|Gavin_Andresen}}

Template:Developers

2021-03-01T21:30:48Z

Ysangkok: make new category "Committers", add some nicks, add Newbery, add MarcoFalke, add Hennadii Stepanov (hebasto), add practicalswift, add Samuel Dobson (MeshCollider)

<noinclude>This template is for [[Bitcoin Core]] developers.
 If possible, the full names of developers should be used in this template, even if they are better known by an internet alias.
 To be listed as a contributor, the person must have made at least 50 contributions, be actively contributing, or be otherwise notable.
 
 
NOTES:
* GitHub user saracen appears to somehow be misattributed for Satoshi's commits.
* fanquake = Michael Ford
</noinclude>{{Navbox_default
|title=[[Bitcoin Core]] developers
|image=
|header=
|group1=Committers[https://bitcoin.stackexchange.com/a/88649/3347]
|list1=[[Wladimir van der Laan]] • [[MarcoFalke]] • [[Samuel Dobson]] (MeshColllider) • [[Michael Ford]] (fanquake) • [[Jonas Schnelli]] • [[Pieter Wuille]] (sipa)
|group2=Active
|list2=[[Matt Corallo]] • [[Suhas Daftuar]] • [[Luke Dashjr]] • [[Cory Fields]] (theuni) • [[John Newbery]] • [[Hennadii Stepanov]] (hebasto) • [[practicalswift]]
|group3=Retired
|list3=[[Gavin Andresen]] • [[Laszlo Hanyecz]] • [[Martti Malmi]] • [[Satoshi Nakamoto]]
|footer=
}}

Template:Developers

2021-03-01T21:18:46Z

Ysangkok: move Gavin Andresen to retired, remove Tom Harding, Brad Andrews, Pavel Janik, Philip Kaufmann, Daniel Kraft, Cozz Lovan, Ross Nicoll, Casey Rodarmor, Adam Weiss

<noinclude>This template is for [[Bitcoin Core]] developers.
 If possible, the full names of developers should be used in this template, even if they are better known by an internet alias.
 To be listed as a contributor, the person must have made at least 50 contributions, be actively contributing, or be otherwise notable.
 
 
NOTES:
* GitHub user saracen appears to somehow be misattributed for Satoshi's commits.
* fanquake = Michael Ford
</noinclude>{{Navbox_default
|title=[[Bitcoin Core]] developers
|image=
|header=
|group1=Active
|list1=[[Wladimir van der Laan]] ([[Core maintainer|maintainer]]) • [[Matt Corallo]] • [[Suhas Daftuar]] • [[Luke Dashjr]] • [[Cory Fields]] • [[Michael Ford]] • [[Jonas Schnelli]] • [[Pieter Wuille]]
|group2=Retired
|list2=[[Laszlo Hanyecz]] • [[Martti Malmi]] • [[Satoshi Nakamoto]] • [[Gavin Andresen]]
|footer=
}}

Template:Developers

2021-03-01T21:11:17Z

Ysangkok: remove Friedenbach, Garzik, Hearn, Morcos, Maxwell, Timón, Todd, Togami

<noinclude>This template is for [[Bitcoin Core]] developers.
 If possible, the full names of developers should be used in this template, even if they are better known by an internet alias.
 To be listed as a contributor, the person must have made at least 50 contributions, be actively contributing, or be otherwise notable.
 
 
NOTES:
* GitHub user saracen appears to somehow be misattributed for Satoshi's commits.
* fanquake = Michael Ford
</noinclude>{{Navbox_default
|title=[[Bitcoin Core]] developers
|image=
|header=
|group1=Active
|list1=[[Wladimir van der Laan]] ([[Core maintainer|maintainer]]) • [[Gavin Andresen]] • [[Brad Andrews]] • [[Matt Corallo]] • [[Suhas Daftuar]] • [[Luke Dashjr]] • [[Cory Fields]] • [[Michael Ford]] • [[Tom Harding]] • [[Pavel Janik]] • [[Philip Kaufmann]] • [[Daniel Kraft]] • [[Cozz Lovan]] • [[Ross Nicoll]] • [[Casey Rodarmor]] • [[Jonas Schnelli]] • [[Adam Weiss]] • [[Pieter Wuille]]
|group2=Retired
|list2=[[Laszlo Hanyecz]] • [[Martti Malmi]] • [[Satoshi Nakamoto]]
|footer=
}}

Wladimir van der Laan

2021-03-01T21:07:03Z

Ysangkok: add resignment

{{infobox person
|name=Wladimir van der Laan
|names=Wlad, laanwj
|active=2011–present
|residence=Eindhoven, The Netherlands
|knownfor=Contributions to [[Bitcoin Core]]
|notableworks=[[Visucore]]
|twitter=orionwl
}}'''Wladimir J. van der Laan''' is the current [[Core maintainer|maintainer]] of [[Bitcoin Core]].

On April 7, 2014, [[Gavin Andresen]] stepped down from the position of Core maintainer and nominated Laan as his successor.<ref>{{cite web|title=Bitcoin Core Maintainer: Wladimir van der Laan|work=[[Bitcoin Foundation]]|date=7 April 2014|url=https://bitcoinfoundation.org/2014/04/bitcoin-core-maintainer-wladimir-van-der-laan/|author=[[Gavin Andresen|Andresen, Gavin]]|accessdate=19 September 2014}}</ref>

On January 21st, 2021, Wlad announced that he would be delegating his tasks.<ref>[https://laanwj.github.io/2021/01/21/decentralize.html The Widening Gyre on Lannwj's blog]</ref>

==References==
<references/>
{{s-start|Bitcoin [[Core maintainer]]|[[Gavin Andresen]]|2014–present|Incumbent}}
{{developers}}{{stub}}
[[Category:Core committers]]
[[Category:Core developers]]

Signet

2020-11-13T22:54:07Z

Ysangkok: not proposed any more

Signet ([[BIP 0325]]) is a new test network for Bitcoin which adds an additional signature requirement to block validation. Signet is similar in nature to [[testnet]], but more reliable and centrally controlled. There is a default signet network ("Signet Global Test Net VI" as of this writing), but anyone can run their own signet network at their whim.

Run bitcoind with the <code>-signet</code> flag to use the default global signet (or put <code>signet=1</code> in the <code>bitcoin.conf</code> file). If you wish to use a [[#Custom Signet|custom signet]], you need to provide the block challenge (aka the block script) using <code>-signetchallenge=<hex></code>, and preferably also at least one seed node using <code>-signetseednode=<host>[:<port>]</code>.

==Differences==

* Default Bitcoin network protocol listen port is 38333 (instead of 8333)
* Default RPC connection port is 38332 (instead of 8332)
* A different value of ADDRESSVERSION field ensures no signet Bitcoin addresses will work on the production network. (0x6F rather than 0x00)
* The protocol message header bytes are *dynamically generated* based on the block challenge, i.e. every signet is different; the header for the current default signet is <code>0x0A03CF40</code> (that is reversed e.g. in Rust variables) (instead of <code>0xF9BEB4D9</code>), but see [[#Genesis_Block_and_Message_Header]]
* Genesis block has timestamp 1598918400, nonce 52613770, and difficulty 0x1e0377ae.
* Segwit is always enabled
* Additional consensus requirement that the coinbase witness commitment contains an extended signet commitment, which is a script satisfying the block script (usually a k-of-n multisig)

==Why run Signet?==

* You are an Instructor, and want to run a controlled Bitcoin network environment for teaching purposes.
* You are a Software Developer, and want to test your software.
* You want to try out experimental changes that you want to implement in Bitcoin.
* You want to test long-term running software and don't want to deal with tens of thousands of block reorgs, or days of no blocks being mined, as is the case with Testnet.
* You want an easy way to test double spends (signet plans to include support for automated double spends, where you provide two conflicting transactions and they are mined in order, with a reorg happening between them).

==Genesis Block and Message Header==

All signet networks share the same genesis block, but have a different message header. The message header is the 4 first bytes of the sha256d-hash of the block challenge, as a single script push operation. I.e. if the block challenge is 37 bytes, the message start would be sha256d(0x25 || challenge)[0..3].

==Getting Started==

NOTE: signet (IV) was merged into the master branch of Bitcoin Core as of https://github.com/bitcoin/bitcoin/pull/18267

===Fetch and compile signet===

<pre>
$ git clone https://github.com/bitcoin/bitcoin
$ cd bitcoin
$ ./autogen.sh
$ ./configure
$ make -j5
</pre>

===Create bitcoin.conf file and start up the daemon===

<pre>
$ cd src
$ mkdir signet
$ echo "signet=1
daemon=1" > signet/bitcoin.conf
$ ./bitcoind -datadir=signet
</pre>

===Verify that you're connected===

<pre>
$ ./bitcoin-cli -datadir=signet getconnectioncount
***SHOULD BE MORE THAN ZERO***
$ ./bitcoin-cli -datadir=signet getblockcount
***SHOULD BE MORE THAN ZERO***
</pre>

===Get some coins===

There is a command line tool you can use to get coins directly to your instance of Signet, assuming you are on the default network. You can also use the faucet online with an address of yours.

====Using online faucet====

You first need an address

<pre>
$ ./bitcoin-cli -datadir=signet getnewaddress
</pre>

Then go to a faucet, e.g. https://signet.bc-2.jp and enter your address.

====Using the command line tool====

The tool is in <code>contrib/signet</code> and is called <code>getcoins.sh</code>. You can optionally provide a path to <code>bitcoin-cli</code> using <code>--cmd=[path]</code> and a compatible faucet using <code>--faucet=[url]</code> followed by any number of arguments to <code>bitcoin-cli</code>. The script attempts to autodetect these if left out.

<pre>
$ cd ../contrib/signet
$ ./getcoins.sh -datadir=../../src/signet
Payment of 10.00000000 BTC sent with txid c0bfa...
</pre>

===Check that you received the coins===

Check your faucet transaction confirming at e.g. https://explorer.bc-2.jp and then send coins around to people and/or use signet for testing your wallet/etc.

You can immediately see the amount using <code>getunconfirmedbalance</code> i.e.

<pre>
$ cd ../../src # if you were in contrib/signet
$ ./bitcoin-cli -datadir=signet getunconfirmedbalance
</pre>

You can also see info about the transaction that the faucet gave you.

<pre>
$ ./bitcoin-cli -datadir=signet gettransaction THETXID
</pre>

Once it has confirmed, you should see it in <code>getbalance</code>.

<pre>
$ ./bitcoin-cli -datadir=signet getbalance
</pre>

==External links==

* [https://github.com/bitcoin/bitcoin/pull/18267 Pull request #18267 to Bitcoin Core]
* [https://github.com/rust-bitcoin/rust-bitcoin/pull/291 Pull request #291 to Rust-Bitcoin]
* [https://gist.github.com/kallewoof/98b6d8dbe126d2b6f47da0ddccd2aa5a Github gist explaining how to get started]

===Faucets===

* https://signet.bc-2.jp/

Can also ping @kallewoof on IRC (freenode)/Twitter.

Faucet source code, if you want your own:

* https://github.com/kallewoof/bitcoin-faucet.git (node.js and mongodb)
* https://github.com/stepansnigirev/tinyfaucet.git (python)

===Block explorers===

* https://explorer.bc-2.jp/

==Custom Signet==

NOTE: Until it is merged into master branch, you may first need to check-out the code referred in https://github.com/bitcoin/bitcoin/pull/19937 in order to get the script <code>contrib/signet/generate.py</code>.

Creating your own signet involves a couple of steps: generate keys used for signing, define the block script, start up a node running on the new signet, and import the private key in order to sign blocks.

===Generating keys used for signing a block===

The most straightforward way is to simply start up a regtest node and then generating a new key from there.

<pre>
$ cd PATHTOBITCOIN/bitcoin/src
$ ./bitcoind -regtest -daemon -wallet="test"
$ ADDR=$(./bitcoin-cli -regtest getnewaddress)
$ PRIVKEY=$(./bitcoin-cli -regtest dumpprivkey $ADDR)
$ ./bitcoin-cli -regtest getaddressinfo $ADDR | grep pubkey
"pubkey": "THE_REAL_PUBKEY",
</pre>

We need to jot down the privkey (<code>echo $PRIVKEY</code>) and the pubkey (here <code>THE_REAL_PUBKEY</code>).

===Defining the block script===

The block script is just like any old Bitcoin script, but the most common type is a k-of-n multisig. Here we will do a 1-of-1 multisig with our single pubkey above. Our script becomes
* <code>51</code> "1" (signature count)
* <code>21</code> Push 0x21=33 bytes (the length of our pubkey above)
* <code>THE_REAL_PUBKEY</code> (our pubkey)
* <code>51</code> "1" (pubkey count)
* <code>ae</code> <code>OP_CHECKMULTISIG</code> opcode

Put together, our <code>-signetchallenge</code> value becomes <code>5121...51ae</code>. Where <code>...</code> stands for <code>THE_REAL_PUBKEY</code> (see above).

===Start up a node (issuer)===

For the network to be useful, it needs to be generating blocks at decent intervals, so let's start up a node that does that (it may be useful to also use that node as a seed node for other peers).

Note that we are importing <code>$PRIVKEY</code> at the end; any node that needs to issue blocks must import the privkey we generated above, or it will fail to sign blocks.

<pre>
$ ./bitcoin-cli -regtest stop
$ datadir=$HOME/signet-custom
$ mkdir $datadir
$ echo "signet=1
[signet]
daemon=1
signetchallenge=5121...51ae # fill in THE_REAL_PUBKEY" > $datadir/bitcoin.conf
$ ./bitcoind -datadir=$datadir -wallet="test"
$ ./bitcoin-cli -datadir=$datadir importprivkey $PRIVKEY
</pre>

Note: if you run into errors above, you may have a different signet running, which is blocking the ports. Either stop that, or set port and rpcport in the <code>$datadir/bitcoin.conf</code> file under the <code>[signet]</code> section and try again from the <code>bitcoind</code> part above.

===Run issuer===

Lastly, we start an issuer using <code>bitcoin-util</code>:

<pre>
$ ADDR=$(./bitcoin-cli -datadir=$datadir getnewaddress); ../contrib/signet/generate.py --cli="./bitcoin-cli -datadir=$datadir" generate 0 --address $ADDR --grind-cmd='./bitcoin-util grind' --block-time=600
</pre>

This will create an address, and then start mining to that address, aiming for blocks arriving every 10 minutes on average. (Note that you may need to create a wallet first.)

Next is to have your friends/colleagues/etc join the network by setting the <code>signetchallenge</code> to the same as above, and connecting to your node.

===Example Script===

A full example script can be found at https://en.bitcoin.it/wiki/Signet:Custom:Script

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

{{Bitcoin Core documentation}}

Peer-reviewed research

2020-07-01T17:28:47Z

Ysangkok: /* Covenants */ add new paper

Bitcoin has been a research topic since the beginning. Here are some peer-reviewed papers, grouped by subject:

==[[BIP 0032]]: HD Wallets==
Douglas Stebila (January 26, 2015). "[https://books.google.com.mx/books?id=MUYwCgAAQBAJ&pg=PA497 Hierarchical Deterministic Bitcoin wallets that tolerate key leakage]". Financial Cryptography and Data Security (2015).

The paper explains how BIP-32 allows for key leakage if used incorrectly, and proposes an alternate scheme.

==Covenants==
* Möser, Malte; Eyal, Ittay; Gün Sirer, Emin (February 2016). "[https://books.google.com.mx/books?id=MJzvDAAAQBAJ&pg=PA134 Bitcoin Covenants]". Financial Cryptography and Data Security (2016): 126–141.
* Russell O'Connor, Marta Piekarska. "[https://books.google.com.mx/books?id=UFI_DwAAQBAJ&pg=PA191 Enhancing Bitcoin Transactions with Covenants]". Financial Cryptography and Data Security 2017. November 17, 2017.

The authors explain [[covenant]]s, what they are, and what they enable.

The work by O'Connor et al was integrated into [[Elements Alpha]] according to section 1.2 of [https://arxiv.org/pdf/2006.16714.pdf Bitcoin Covenants: Three Ways to Control the Future] by Swambo, Hommel, McElrath, [[Bryan Bishop|Bishop]].

==[[BIP 0156]]: More anonymous transaction propagation (Dandelion)==
Brad Denby, Andrew Miller, Giulia Fanti, Surya Bakshi, Shaileshh Bojja Venkatakrishnan, Pramod Viswanath (June 2017). "[https://dl.acm.org/doi/abs/10.1145/3084459 Dandelion: Redesigning the Bitcoin Network for Anonymity]". Proceedings of the Association for Computing Machinery on Measurement and Analysis of Computing Systems.

Dandelion allows for more anonymous transaction propagation. Unfortunately, it is difficult to implement without enabling DoS attacks, so it hasn't been merged into Bitcoin Core.

==[[BIP 0330]]: Erlay (efficient transaction relay)==
Naumenko, Gleb; Wuille, Pieter (November 2019). "[https://dl.acm.org/doi/10.1145/3319535.3354237 Erlay: Efficient Transaction Relay for Bitcoin]". CCS: Proceedings of the ACM SIGSAC Conference on Computer and Communications Security (2019): 817–831. doi:10.1145/3319535.3354237.

Erlay not only reduces the bandwidth consumption by 40% assuming current connectivity, but also keeps the bandwidth use almost constant as the connectivity increases. In contrast, the existing protocol increases the bandwidth consumption linearly with the number of connections. By allowing more connections at a small cost, Erlay improves the security of the Bitcoin network.

==Atomic cross-chain swaps==
Maurice Herlihy (18 May 2018). "[https://arxiv.org/pdf/1801.09515.pdf Atomic Cross-Chain Swaps]" (PDF). Proceedings of the Twenty-second Annual Symposium on Principles of Distributed Computing 2018.

'Cross-chain' means that the swap happens between two different blockchains, e.g. testnet and mainnet. 'Atomic' means that the swap either happens in full, or no swap happens.

==Formal model of Bitcoin transactions==
Nicola Atzei, Massimo Bartoletti, Stefano Lande, Roberto Zunino (August 29, 2019). "[https://books.google.com.mx/books?id=xSmsDwAAQBAJ&pg=PA541 A formal Model of Bitcoin Transactions]". Financial Cryptography and Data Security 2018.

The paper defines a transaction as a tuple, and time-locks implemented in opcodes are abstracted over. The result is a model that resembles bitcoin but avoids thinking about details like script interpretation. By simplifying the model like this, it can be easier to analyse.

Research

2020-07-01T03:00:24Z

Ysangkok: link peer-reviewed page

Publications including research and analysis of Bitcoin or related areas. There is a separate page for [[peer-reviewed research]].

The list below is now just a subset of a [http://docs.google.com/spreadsheets/d/1VaWhbAj7hWNdiE73P-W-wrl5a0WNgzjofmZXe0Rh5sg/htmlview?usp=sharing&pli=1&sle=true comprehensive list] compiled by [http://twitter.com/@suitpossum Brett Scott].

{| class="wikitable sortable"
! Title
! Author
! width=150 | Type
! width=75 | Date
! Links
|-
| Cyberlaundering: Anonymous Digital Cash and Money Laundering
| R. Mark Bortner
| Research paper
| 1996
| [http://osaka.law.miami.edu/~froomkin/seminar/papers/bortner.htm Download]
|-
| Triple Entry Accounting
| Ian Grigg
| Research paper
| 2005-12-25
| [http://iang.org/papers/triple_entry.html Download]
|-
| [[Bitcoin_whitepaper|Bitcoin: A Peer-to-Peer Electronic Cash System]]
| [[Satoshi Nakamoto]]
| Research paper
| 2008-10-31
| [http://bitcoin.org/bitcoin.pdf Download]
|-
| An Analysis of Anonymity in the Bitcoin System
| Fergal Reid, Martin Harrigan
| Research paper
| 2011-07-22
| [http://arxiv.org/abs/1107.4524 Download], [http://bitcointalk.org/index.php?topic=31539.0 discussion]
|-
| Shadowy Figures: Tracking Illicit Financial Transactions in the Murky World of Digital Currencies, Peer–to–Peer Networks, and Mobile Device Payments
| John Villasenor, Cody Monk, Christopher Bronk
| Research paper
| 2011-08-29
| [http://www.bakerinstitute.org/publications/ITP-pub-FinancialTransactions-082911.pdf Download]
|-
| Bitcoin: An Innovative Alternative Digital Currency
| Reuben Grinberg
| Research paper
| 2011-12-09
| [http://papers.ssrn.com/sol3/papers.cfm?abstract_id=1817857 Download], [http://www.bitcointalk.org/index.php?topic=6247.0 discussion]
|-
| Bitcoin NFC
| David Allen Bronleewe
| Master's report
| 2011-08
| [http://repositories.lib.utexas.edu/bitstream/handle/2152/ETD-UT-2011-08-4150/BRONLEEWE-MASTERS-REPORT.pdf?sequence=1 Download], [http://code.google.com/p/bitcoin-nfc source code]
|-
| Optimal pool abuse strategy
| Raulo
| Research paper
| 2011-02-04
| [http://bitcoin.atspace.com/poolcheating.pdf Download], [http://www.bitcointalk.org/index.php?topic=3165.0 discussion]
|-
| Abusing Bitcoin cooperative mining pools: strategies for egoistical but honest miners
| Nakamoto Ryo
| Research paper
| 2011
| [http://www.bitcoinservice.co.uk/files/111 Download], [http://www.bitcointalk.org/index.php?topic=2941.0 discussion]
|-
| Analysis of Bitcoin Pooled Mining Reward Systems
| Meni Rosenfeld
| Research paper
| 2011-11-07
| [https://bitcoil.co.il/pool_analysis.pdf Download], [http://bitcointalk.org/index.php?topic=32814.0 discussion]
|-
| Bitcoin Exchange system
| Tomáš Jiříček
| Research paper
| 2012
| [https://dip.felk.cvut.cz/browse/pdfcache/jiricto2_2012bach.pdf Download]
|-
| On Bitcoin and Red Balloons
| Moshe Babaioff, Shahar Dobzinski, Sigal Oren, Aviv Zohar
| Publication article
| 2012
| [http://research.microsoft.com/pubs/156072/bitcoin.pdf Download]
|-
| 2011 Observations on the Digital Currency Industry
| Mark Herpel
| Publication article
| 2011
| [http://papers.ssrn.com/sol3/papers.cfm?abstract_id=1721076 Download]
|-
| MAVE, New Lightweight Digital Signature Protocols for Massive Verifications
| Sergio Demian Lerner
| Research paper (preliminary)
| 2012
| [http://bitslog.files.wordpress.com/2012/04/mave1.pdf Download]
|-
| MAVEPAY, a New Lightweight Payment Scheme for Peer to Peer Currency Networks
| Sergio Demian Lerner
| Research paper (preliminary)
| 2012
| [http://bitslog.files.wordpress.com/2012/04/mavepay1.pdf Download]
|-
| Bitcoin: Eine erste Einordnung (an initial classification)
| Christoph Sorge, Artus Krohn-Grimberghe
| Research paper
| 2012
| [http://www.springerlink.com/content/cw1v762571tr4462/ Download], [http://bitcointalk.org/index.php?topic=90233.0 discussion]
|-
| Bitcoin - an introduction to the workings and a preliminary analysis and understanding of potential legal issues
| Jean-Daniel Schmid, Alexander Schmid
| Article
| 2012
| [http://ef-r.ch/images/publications/1338882576_Bitcoin.pdf Download]
|-
| Secure multiparty Bitcoin anonymization
| Edward Z. Yang
| Article
| 2012
| [http://blog.ezyang.com/2012/07/secure-multiparty-bitcoin-anonymization/ Download], [http://www.reddit.com/r/Bitcoin/comments/wvm2w/secure_multiparty_bitcoin_anonymization/ discussion]
|-
| Bitcoin & Gresham's Law - the economic inevitability of Collapse
| Philipp Güring, Ian Grigg
| Article
| 2011
| [http://iang.org/papers/BitcoinBreachesGreshamsLaw.pdf Download]
|-
| Today Techies, Tomorrow the World? Bitcoin.
| Reuben Grinberg
| Article
| 2012
| [http://www.milkeninstitute.org/publications/review/2012_1/22-31MR53.pdf Download]
|-
| Traveling the Silk Road: A measurement analysis of a large anonymous online marketplace
| Nicolas Christin
| Research paper
| 2012
| [http://www.cylab.cmu.edu/files/pdfs/tech_reports/CMUCyLab12018.pdf Download]
|-
| CommitCoin: Carbon Dating Commitments with Bitcoin
| Jeremy Clark and Aleksander Essex
| Research paper
| 2012
| [http://people.scs.carleton.ca/~clark/papers/2012_fc.pdf Download extended abstract] [http://eprint.iacr.org/2011/677.pdf Download technical report]
|-
| Quantitative Analysis of the Full Bitcoin Transaction Graph
| Dorit Ron and Adi Shamir
| Research paper
| 2012
| [http://eprint.iacr.org/2012/584.pdf Download]
|-
| Bitcoin Security
| Robert Pallas
| Master's thesis
| 2012
| [http://robertpallas.github.io/boblog/includes/btc-thesis.pdf Download]
|-
| Design and security analysis of Bitcoin infrastructure using application deployed on Google Apps Engine
| Piotr "ThePiachu" Piasecki
| Master's thesis
| 2012
| [https://dl.dropbox.com/u/3658181/PiotrPiasecki-BitcoinMasterThesis.pdf Download], [https://bitcointalk.org/index.php?topic=88149.0 discussion]
|-
| The Production of Freedom: Value Production in the US- dominated Financial System, and Possible Alternatives
| Jeremy Kirshbaum
| Master's thesis (preliminary)
| 2012
| [https://docs.google.com/document/d/1JIyMWIibqH8x20vGBTMBZ2yqM7Xbp54UpWBh0o2H7WI/edit?pli=1 Download], [https://bitcointalk.org/index.php?topic=87404.0 discussion]
|-
| COIN: a distributed accounting system for peer to peer networks
| Fabio Varesano
| Bachelor's thesis
| 2012
| [http://www.varesano.net/contents/projects/coin%20distributed%20accounting%20system%20peer%20peer%20networks Download]
|-
| BITCOIN CLIENTS
| Rostislav Skudnov
| Bachelor's thesis
| 2012
| [http://publications.theseus.fi/bitstream/handle/10024/47166/Skudnov_Rostislav.pdf?sequence=1 Download]
|-
| Bitter to Better—How to Make Bitcoin a Better Currency
| Simon Barber, Xavier Boyen, Elaine Shi, Ersin Uzun
| Research paper
| 2012
| [http://crypto.stanford.edu/~xb/fc12/bitcoin.pdf Download]
|-
| NooShare: A decentralized ledger of shared computational resources
| Alex Coventry
| Research paper
| 2012
| [http://mit.edu/alex_c/www/nooshare.pdf Download]
|-
| Bits and Bets. Information, Price Volatility, and Demand for Bitcoin
| Martis Buchholz, Jess Delaney, Joseph Warren
| Final project
| 2012
| [http://academic.reed.edu/economics/parker/s12/312/finalproj/Bitcoin.pdf Download], [http://www.reddit.com/r/Bitcoin/comments/x7kop/economic_analysis_of_the_demand_for_bitcoin discussion], [https://bitcointalk.org/index.php?topic=96003.0 discussion]
|-
| Two Bitcoins at the Price of One? Double Spending attacks on Fast Payments in Bitcoin
| Ghassan O. Karame, Elli Androulaki, Srdjan Cap-kun
| Research paper
| 2012
| [http://eprint.iacr.org/2012/248 Download]
|-
| Nerdy Money: Bitcoin, the Private Digital Currency, and the Case Against Its Regulation
| Nikolei M. Kaplanov
| Research paper
| 2012
| [http://papers.ssrn.com/sol3/papers.cfm?abstract_id=2115203 Abstract]
|-
| Analysis of hashrate-based double-spending
| Meni Rosenfeld
| Research paper
| 2012
| [https://bitcoil.co.il/Doublespend.pdf Download]
|-
| Homomorphic Payment Addresses and the Pay-to-Contract Protocol
| Ilja Gerhardt, Timo Hanke
| Research Paper
| 2012
| [http://arxiv.org/pdf/1212.3257v1 Download] ([http://docs.google.com/viewer?url=http%3A%2F%2Farxiv.org%2Fpdf%2F1212.325qq7v1 via web viewer])
|-
| Quasi-Commodity Money (February 6, 2012). "This paper considers reform possibilities posed by a type of base money that has heretofore been overlooked in the literature on monetary economics."
| George Selgin
| Working Papers Series
| 2012
| [http://ssrn.com/abstract=2000118 Download]
|-
| Virtual currency schemes - "This report is a first attempt to provide the basis for a discussion on virtual currency schemes."
| European Central Bank
| Paper
| 2012
| [http://www.ecb.europa.eu/pub/pdf/other/virtualcurrencyschemes201210en.pdf Download]
|-
| Evaluating User Privacy in Bitcoin
| Elli Androulaki, Ghassan Karame, Marc Roeschlin, Tobias Scherer and Srdjan Capkun
| Paper
| 2013
| [http://fc13.ifca.ai/proc/1-3.pdf Download] ([http://fc13.ifca.ai/slide/1-3.pdf Slides])
|-
| Beware the Middleman: Empirical Analysis of Bitcoin-Exchange Risk
| Tyler Moore and Nicolas Christin
| Short Paper
| 2013
| [http://fc13.ifca.ai/proc/1-2.pdf Download] ([http://fc13.ifca.ai/slide/1-2.pdf Slides])
|-
| Bitcoin, Regulating Fraud In The E-Conomy Of Hacker-Cash
| Derek A. Dion
| Paper
| 2013
| [http://illinoisjltp.com/journal/wp-content/uploads/2013/05/Dion.pdf Download]
|-
| The practical materiality of Bitcoin
| Bill Maurera, Taylor C. Nelmsa & Lana Swartz
| Paper
| 2013
| [http://www.tandfonline.com/doi/full/10.1080/10350330.2013.777594#.UbbTVaD_6b4 Download]
|-
| Regulating Digital Currencies: Bringing Bitcoin within the Reach of the IMF
| Nicholas Plassaras
| Paper
| 2013
| [https://papers.ssrn.com/sol3/papers.cfm?abstract_id=2248419 Download]
|-
| Bitcoin is Memory
| William J. Luther, Josiah Olson
| Paper
| 2013
| [http://papers.ssrn.com/sol3/papers.cfm?abstract_id=2275730 Download]
|-
| The Economics of Bitcoin Mining or, Bitcoin in the Presence of Adversaries
| Joshua A. Kroll, Ian C. Davey, and Edward W. Felten
| Paper
| 2013
| [http://www.weis2013.econinfosec.org/papers/KrollDaveyFeltenWEIS2013.pdf Download]
|-
| Bitcoin: A Primer for Policymakers
| Jerry Brito, Andrea Castillo
| Research paper
| 2013
| [http://mercatus.org/publication/bitcoin-primer-policymakers Abstract] [http://mercatus.org/sites/default/files/Brito_BitcoinPrimer.pdf Download]
|-
| Whack-a-Mole: Prosecuting Digital Currency Exchanges
| Catherine Martin Christopher
| Research paper
| 2013
| [http://papers.ssrn.com/sol3/papers.cfm?abstract_id=2312787 Abstract]
[http://papers.ssrn.com/sol3/Delivery.cfm/SSRN_ID2312787_code1372021.pdf?abstractid=2312787&mirid=2 Download]
|-
| Are Cryptocurrencies 'Super' Tax Havens?
| Omri Y. Marian
| Research paper
| 2013
| [http://papers.ssrn.com/sol3/papers.cfm?abstract_id=2305863 Abstract]
[http://papers.ssrn.com/sol3/Delivery.cfm/SSRN_ID2316499_code592645.pdf?abstractid=2305863&mirid=1 Download]
|-
| Collective Emergent Institutional Entrepreneurship Through Bitcoin
| Robin Teigland, Zeynep Yetis and Tomas Olov Larsson
| Research paper
| 2013
| [http://papers.ssrn.com/sol3/papers.cfm?abstract_id=2263707 Abstract]
[http://papers.ssrn.com/sol3/Delivery.cfm/SSRN_ID2263707_code2053543.pdf?abstractid=2263707&mirid=1 Download]
|-
| Anonymity of Bitcoin Transactions
| Malte Möser
| Research paper
| 2013
| [https://www.wi.uni-muenster.de/sites/default/files/public/department/itsecurity/mbc13/mbc13-moeser-paper.pdf Download]
|-
| On the origins of Bitcoin: Stages of monetary evolution
| Konrad S. Graf
| Research paper
| 2013
| [http://konradsgraf.com/blog1/2013/10/23/on-the-origins-of-bitcoin-my-new-work-on-bitcoin-and-monetar.html Abstract]
[http://konradsgraf.com/storage/On%20the%20Origins%20of%20Bitcoin%20Graf%2023.10.13.pdf Download]
|-
| Majority is not Enough: Bitcoin Mining is Vulnerable
| Ittay Eyal and Emin Gun Sirer
| Research paper
| 2013
| [http://arxiv.org/abs/1311.0243 Abstract]
[http://arxiv.org/pdf/1311.0243v1 Download]
|-
| Bitcoin, the end of the Taboo on Money
| Denis Roio aka Jaromil
| Humanities article
| 2013
| [http://www.dyndy.net/2013/04/bitcoin-ends-the-taboo-on-money/ Abstract]
[https://files.dyne.org/readers/Bitcoin_end_of_taboo_on_money.pdf Download]
|-
| Secure Multiparty Computations on BitCoin
| Marcin Andrychowicz, Stefan Dziembowski, Daniel Malinowski and Łukasz Mazurek University of Warsaw
| Research paper
| 2013
| [http://eprint.iacr.org/2013/784 Abstract]
[http://eprint.iacr.org/eprint-bin/cite.pl?entry=2013/784 BibTeX]
[http://eprint.iacr.org/2013/784.pdf Download]
|-
| A Fistful of Bitcoins: Characterizing Payments Among Men with No Names
| Sarah Meiklejohn, Marjori Pomarole, Grant Jordan, Kirill Levchenko, Damon McCoy, Geoffrey M. Voelker, Stefan Savage
| Research paper
| 2013
|
[http://www.cs.gmu.edu/~mccoy/papers/imc13.pdf Download]
|-
| Information Propagation in the Bitcoin Network
| Christian Decker (ETH Zurich, Switzerland), Roger Wattenhofer (Microsoft Research)
| Research paper
| 2013
|
[http://www.tik.ee.ethz.ch/file/49318d3f56c1d525aabf7fda78b23fc0/P2P2013_041.pdf Download]
|-
| Have a Snack, Pay with Bitcoins
| Tobias Bamert, Christian Decker, Lennart Elsen, Roger Wattenhofer, Samuel Welten
| Research paper
| 2013
|
[http://www.tik.ee.ethz.ch/file/848064fa2e80f88a57aef43d7d5956c6/P2P2013_093.pdf Download]
|-
| The Economics of Private Digital Currency
| Gerald P Dwyer
| Research paper
| 2014
| [http://mpra.ub.uni-muenchen.de/55824/ Abstract]
[http://mpra.ub.uni-muenchen.de/55824/1/MPRA_paper_55824.pdf Download]
|-
| The Origin, Classification and Utility of Bitcoin
| Peter Šurda
| Research Paper
| 2014
| [http://papers.ssrn.com/sol3/papers.cfm?abstract_id=2436823 Abstract]
|-
| Deanonymisation of clients in Bitcoin P2P network
| Alex Biryukov, Dmitry Khovratovich and Ivan Pustogarov
| Research Paper
| 2014
| [http://arxiv.org/abs/1405.7418 Abstract] [http://arxiv.org/pdf/1405.7418v2.pdf Download]
|-
| Bitcoin Financial Regulation: Securities, Derivatives, Prediction Markets, & Gambling
| Jerry Brito, Houman B. Shadab, Andrea Castillo
| Research Paper
| 2014
| [http://papers.ssrn.com/sol3/papers.cfm?abstract_id=2423461 Abstract] [http://papers.ssrn.com/sol3/Delivery.cfm/SSRN_ID2426195_code510873.pdf?abstractid=2423461&mirid=1 Download]
|-
| What are the main drivers of the Bitcoin price?
| Ladislav Kristoufek
| Research Paper
| 2014
| [http://arxiv.org/pdf/1406.0268v1.pdf Download]
|-
| The Economics of Bitcoin
| Andre Herman
| Bachelor's thesis
| 2014
| [http://www.scribd.com/doc/231964435/The-Economics-of-Bitcoin Download]
|-
| Near Zero Bitcoin Transaction Fees Cannot Last Forever
| Kerem Kaşkaloğlu
| Research Paper
| 2014
| [http://sdiwc.net/digital-library/near-zero-bitcoin-transaction-fees-cannot-last-forever.html Abstract] [http://sdiwc.net/digital-library/request.php?article=96cd6f6067fcbaf5e3947d071aa688fb Download]
|-
| Is Bitcoin Money?
| Ísak Andri Ólafsson
| Thesis Paper
| 2014
| [http://skemman.is/en/item/view/1946/18234 Abstract] [http://skemman.is/en/stream/get/1946/18234/42843/1/MS_%C3%8Dsak_Andri_%C3%93lafsson.pdf Download]
|-
| The (A)Political Economy of Bitcoin
| Vasilis Kostakis and Chris Giotitsas
| Essay
| 2014
| [http://www.triple-c.at/index.php/tripleC/article/view/606/578 HTML] [http://www.triple-c.at/index.php/tripleC/article/download/606/562 Download]
|-
| When your sensor earns money: exchanging data for cash with Bitcoin
| Dominic Wörner and Thomas von Bomhard
| Research
| 2014
| [http://dl.acm.org/citation.cfm?id=2638786 Abstract] [http://dl.acm.org/ft_gateway.cfm?id=2638786&ftid=1500778&dwn=1&CFID=579517323&CFTOKEN=37552107 Download]
|-
| Bitcoin Transaction Malleability and MtGox
| Christian Decker, Roger Wattenhofer
| Research
| 2014
| [http://www.tik.ee.ethz.ch/file/7e4a7f3f2991784786037285f4876f5c/malleability.pdf Download]
|-
| BlueWallet: The Secure Bitcoin Wallet
| Tobias Bamert, Christian Decker, Roger Wattenhofer and Samuel Welten
| Research
| 2014
| [http://www.tik.ee.ethz.ch/file/0c347a9a3803cb937d360cba511e5019/stm2014_submission_12.pdf Download]
|-
| Bitcoin over Tor isn’t a good idea
| Alex Biryukov and Ivan Pustogarov
| Research
| 2014
| [http://arxiv.org/pdf/1410.6079v1.pdf Download]
|-
| Sidechained Bitcoin Substitutes, A Monetary Commentary
| Konrad S. Graf
| Essay
| 2014
| [http://konradsgraf.squarespace.com/storage/Monetary%20analsyis%20of%20sidecoins%20KG%2024Oct2014.pdf Download]
|-
| Taxation of virtual currency
| Aleksandra Bal
| PhD thesis
| 2014
| [http://hdl.handle.net/1887/29963 Abstract] [https://openaccess.leidenuniv.nl/bitstream/handle/1887/29963/000-5-Bal-14-10-2014.pdf Download]
|-
| A First Look at the Usability of Bitcoin Key Management
| Shayan Eskandari, David Barrera, Elizabeth Stobert, and Jeremy Clark
| Research Paper
| 2015
| [http://www.internetsociety.org/sites/default/files/05_3_3.pdf Download]
|-
| Privacy in Bitcoin through decentralized mixers
| Olivier Coutu
| Master's thesis
| 2015
| [https://papyrus.bib.umontreal.ca/xmlui/handle/1866/11498 Abstract] [https://papyrus.bib.umontreal.ca/xmlui/bitstream/handle/1866/11498/Coutu_Olivier_2014_memoire.pdf Download]
|-
| Value Creation in Cryptocurrency Networks: Towards A Taxonomy of Digital Business Models for Bitcoin Companies
| Erol Kazan, Chee-Wee Tan, Eric T.K. Lim
| Research Paper
| 2015
| [http://aisel.aisnet.org/pacis2015/34/ Abstract] [http://aisel.aisnet.org/cgi/viewcontent.cgi?article=1222&context=pacis2015 Download]
|-
| Authenticated Key Exchange over Bitcoin
| Patrick McCorry, Siamak F. Shahandashti, Dylan Clarke, Feng Hao
| Research Paper
| 2015
| [http://eprint.iacr.org/2015/308.pdf Download]
|-
| Bitcoin and Beyond: A Technical Survey on Decentralized Digital Currencies
| Florian Tschorsch and Björn Scheuermann
| Research Paper
| 2015
| [http://eprint.iacr.org/2015/464.pdf Download]
|-
| Bitcoin Duplex Micropayment Channels
| Christian Decker and Roger Wattenhofer
| Research Paper
| 2015
| [http://www.tik.ee.ethz.ch/file/716b955c130e6c703fac336ea17b1670/duplex-micropayment-channels.pdf Download]
|-
| The Bitcoin Lightning Network: Scalable Off-Chain Instant Payments
| Joseph Poon and Thaddeus Dryja
| Research Paper
| 2015
| [http://lightning.network/lightning-network-paper.pdf Download]
|-
| Bitcoin and the Uniform Commercial Code
| Jeanne L. Schroeder
| Research Paper
| 2015
| [http://papers.ssrn.com/sol3/papers.cfm?abstract_id=2649441 Abstract] [http://papers.ssrn.com/sol3/Delivery.cfm/SSRN_ID2649441_code1717611.pdf?abstractid=2649441&mirid=1 Download]
|-
| Economics beyond Financial Intermediation
| Saifedean Ammous
| Research Paper
| 2015
| [http://journal.apee.org/index.php?title=2015_Journal_of_Private_Enterprise_vol_30_no_3_parte2.pdf Download]
|-
| Bitcoin and the Future of Digital Payments
| William J. Luther
| Research Paper
| 2015
| [http://papers.ssrn.com/sol3/Papers.cfm?abstract_id=2631314 Abstract] [http://papers.ssrn.com/sol3/Delivery.cfm/SSRN_ID2631314_code1352425.pdf?abstractid=2631314&mirid=1 Download]
|
|-
| Profitability from Mining Bitcoins: Should You Still Enter the Bitcoin Mining Competition? Long-Term Simulation Analysis of the Profitability for a Single Miner
| Kärt Viilup
| Master's thesis
| 2015
| [http://dspace.ut.ee/bitstream/handle/10062/47208/viilup_kart.pdf Download]
|-
| Secure Bitcoin Wallet
| Sevil Guler
| Master's thesis
| 2015
| [http://comserv.cs.ut.ee/forms/ati_report/downloader.php?file=BAE4173CEBB722554EB452F64CFE7C9A2D2391D5 Download]
|-
| Development of Universal Cryptocurrency Wallet Services: A Case Study of Bitplexus
| Priidu Neemre
| Master's thesis
| 2016
| [http://nemp.planet.ee/Development_of_Universal_Cryptocurrency_Wallet_Services_-_A_Case_Study_of_Bitplexus.pdf Download]
|-
| Inverse Futures in Bitcoin Economy
| Aleksey Bragin
| SSRN Research Paper
| 2015
| [https://papers.ssrn.com/sol3/papers.cfm?abstract_id=2713755 Download]
|}

==See Also==

* [http://encryptopedia.com/ Encryptopedia - Scientific research and white papers on bitcoin, blockchain technology, cryptography, algorithms and cryptocurrencies]
* [http://suitpossum.blogspot.com/2014/12/academic-bitcoin-research.html Peer-to-Peer Review: The State of Academic Bitcoin Research 2014] by Brett Scott ([http://twitter.com/Suitpossum @Suitpossum]) ([http://docs.google.com/spreadsheets/d/1VaWhbAj7hWNdiE73P-W-wrl5a0WNgzjofmZXe0Rh5sg/htmlview?usp=sharing&pli=1&sle=true Full List])
* [http://www.opencryptocurrencyreview.com/ OpenCryptocurrencyReview - A repository of Bitcoin and related research]
* [http://people.scs.carleton.ca/~clark/biblio.html Jeremy Clark's Bitcoin Bibliography]
* [[:Category:Economics|Economic]]
* [[:Category:Technical|Technical]]
* [[Press]]

[[Category:Research]]

Academia

2020-07-01T02:59:45Z

Ysangkok: Ysangkok moved page Academia to Peer-reviewed research: to distinguish from Research

#REDIRECT [[Peer-reviewed research]]

Peer-reviewed research

2020-07-01T02:59:45Z

Ysangkok: Ysangkok moved page Academia to Peer-reviewed research: to distinguish from Research

Bitcoin has been a research topic since the beginning. Here are some peer-reviewed papers, grouped by subject:

==[[BIP 0032]]: HD Wallets==
Douglas Stebila (January 26, 2015). "[https://books.google.com.mx/books?id=MUYwCgAAQBAJ&pg=PA497 Hierarchical Deterministic Bitcoin wallets that tolerate key leakage]". Financial Cryptography and Data Security (2015).

The paper explains how BIP-32 allows for key leakage if used incorrectly, and proposes an alternate scheme.

==Covenants==
* Möser, Malte; Eyal, Ittay; Gün Sirer, Emin (February 2016). "[https://books.google.com.mx/books?id=MJzvDAAAQBAJ&pg=PA134 Bitcoin Covenants]". Financial Cryptography and Data Security (2016): 126–141.
* "[https://books.google.com.mx/books?id=UFI_DwAAQBAJ&pg=PA191 Enhancing Bitcoin Transactions with Covenants]". Financial Cryptography and Data Security 2017. November 17, 2017.

The authors explain [[covenant]]s, what they are, and what they enable.

==[[BIP 0156]]: More anonymous transaction propagation (Dandelion)==
Brad Denby, Andrew Miller, Giulia Fanti, Surya Bakshi, Shaileshh Bojja Venkatakrishnan, Pramod Viswanath (June 2017). "[https://dl.acm.org/doi/abs/10.1145/3084459 Dandelion: Redesigning the Bitcoin Network for Anonymity]". Proceedings of the Association for Computing Machinery on Measurement and Analysis of Computing Systems.

Dandelion allows for more anonymous transaction propagation. Unfortunately, it is difficult to implement without enabling DoS attacks, so it hasn't been merged into Bitcoin Core.

==[[BIP 0330]]: Erlay (efficient transaction relay)==
Naumenko, Gleb; Wuille, Pieter (November 2019). "[https://dl.acm.org/doi/10.1145/3319535.3354237 Erlay: Efficient Transaction Relay for Bitcoin]". CCS: Proceedings of the ACM SIGSAC Conference on Computer and Communications Security (2019): 817–831. doi:10.1145/3319535.3354237.

Erlay not only reduces the bandwidth consumption by 40% assuming current connectivity, but also keeps the bandwidth use almost constant as the connectivity increases. In contrast, the existing protocol increases the bandwidth consumption linearly with the number of connections. By allowing more connections at a small cost, Erlay improves the security of the Bitcoin network.

==Atomic cross-chain swaps==
Maurice Herlihy (18 May 2018). "[https://arxiv.org/pdf/1801.09515.pdf Atomic Cross-Chain Swaps]" (PDF). Proceedings of the Twenty-second Annual Symposium on Principles of Distributed Computing 2018.

'Cross-chain' means that the swap happens between two different blockchains, e.g. testnet and mainnet. 'Atomic' means that the swap either happens in full, or no swap happens.

==Formal model of Bitcoin transactions==
Nicola Atzei, Massimo Bartoletti, Stefano Lande, Roberto Zunino (August 29, 2019). "[https://books.google.com.mx/books?id=xSmsDwAAQBAJ&pg=PA541 A formal Model of Bitcoin Transactions]". Financial Cryptography and Data Security 2018.

The paper defines a transaction as a tuple, and time-locks implemented in opcodes are abstracted over. The result is a model that resembles bitcoin but avoids thinking about details like script interpretation. By simplifying the model like this, it can be easier to analyse.

Peer-reviewed research

2020-07-01T02:58:37Z

Ysangkok: Created page with "Bitcoin has been a research topic since the beginning. Here are some peer-reviewed papers, grouped by subject: ==BIP 0032: HD Wallets== Douglas Stebila (January 26, 2015)..."

Bitcoin has been a research topic since the beginning. Here are some peer-reviewed papers, grouped by subject:

==[[BIP 0032]]: HD Wallets==
Douglas Stebila (January 26, 2015). "[https://books.google.com.mx/books?id=MUYwCgAAQBAJ&pg=PA497 Hierarchical Deterministic Bitcoin wallets that tolerate key leakage]". Financial Cryptography and Data Security (2015).

The paper explains how BIP-32 allows for key leakage if used incorrectly, and proposes an alternate scheme.

==Covenants==
* Möser, Malte; Eyal, Ittay; Gün Sirer, Emin (February 2016). "[https://books.google.com.mx/books?id=MJzvDAAAQBAJ&pg=PA134 Bitcoin Covenants]". Financial Cryptography and Data Security (2016): 126–141.
* "[https://books.google.com.mx/books?id=UFI_DwAAQBAJ&pg=PA191 Enhancing Bitcoin Transactions with Covenants]". Financial Cryptography and Data Security 2017. November 17, 2017.

The authors explain [[covenant]]s, what they are, and what they enable.

==[[BIP 0156]]: More anonymous transaction propagation (Dandelion)==
Brad Denby, Andrew Miller, Giulia Fanti, Surya Bakshi, Shaileshh Bojja Venkatakrishnan, Pramod Viswanath (June 2017). "[https://dl.acm.org/doi/abs/10.1145/3084459 Dandelion: Redesigning the Bitcoin Network for Anonymity]". Proceedings of the Association for Computing Machinery on Measurement and Analysis of Computing Systems.

Dandelion allows for more anonymous transaction propagation. Unfortunately, it is difficult to implement without enabling DoS attacks, so it hasn't been merged into Bitcoin Core.

==[[BIP 0330]]: Erlay (efficient transaction relay)==
Naumenko, Gleb; Wuille, Pieter (November 2019). "[https://dl.acm.org/doi/10.1145/3319535.3354237 Erlay: Efficient Transaction Relay for Bitcoin]". CCS: Proceedings of the ACM SIGSAC Conference on Computer and Communications Security (2019): 817–831. doi:10.1145/3319535.3354237.

Erlay not only reduces the bandwidth consumption by 40% assuming current connectivity, but also keeps the bandwidth use almost constant as the connectivity increases. In contrast, the existing protocol increases the bandwidth consumption linearly with the number of connections. By allowing more connections at a small cost, Erlay improves the security of the Bitcoin network.

==Atomic cross-chain swaps==
Maurice Herlihy (18 May 2018). "[https://arxiv.org/pdf/1801.09515.pdf Atomic Cross-Chain Swaps]" (PDF). Proceedings of the Twenty-second Annual Symposium on Principles of Distributed Computing 2018.

'Cross-chain' means that the swap happens between two different blockchains, e.g. testnet and mainnet. 'Atomic' means that the swap either happens in full, or no swap happens.

==Formal model of Bitcoin transactions==
Nicola Atzei, Massimo Bartoletti, Stefano Lande, Roberto Zunino (August 29, 2019). "[https://books.google.com.mx/books?id=xSmsDwAAQBAJ&pg=PA541 A formal Model of Bitcoin Transactions]". Financial Cryptography and Data Security 2018.

The paper defines a transaction as a tuple, and time-locks implemented in opcodes are abstracted over. The result is a model that resembles bitcoin but avoids thinking about details like script interpretation. By simplifying the model like this, it can be easier to analyse.

IRC channels

2020-06-30T21:13:29Z

Ysangkok: /* Bitcoin Project */ add lightning-dev history

Most of the following Bitcoin-related IRC channels are available on [http://www.freenode.net Freenode]:

Please read: [[Bitcoin IRC Channel Guidelines]] before joining.

==Bitcoin Project==
{| class="wikitable"
! Channel !! Description
|-
| {{Freenode IRC|bitcoin}} || General Bitcoin-related discussion and support. ([[Bitcoin_IRC_Channel_Guidelines | guidelines]]).
|-
| {{Freenode IRC|bitcoin-builds}} || Discussion of the Bitcoin Core build system.
|-
| {{Freenode IRC|bitcoin-commits}} || Real-time notification of commits to Bitcoin projects.
|-
| {{Freenode IRC|bitcoin-core-dev}} || For development of Bitcoin Core. Log sources; [http://www.erisian.com.au/bitcoin-core-dev/ 1], [http://gnusha.org/bitcoin-core-dev/ 2]
|-
| {{Freenode IRC|bitcoin-core-pr-reviews}} || Weekly PR review club for discussing Bitcoin Core Pull Requests.
|-
| {{Freenode IRC|bitcoin-dev}} || Dead. Formerly for Bitcoin software development. ([http://bitcoinstats.com/irc/bitcoin-dev/logs/ history]. [[Bitcoin-dev | guidelines]])
|-
| {{Freenode IRC|bitcoin-gaming}} || Bitcoin gamers hangout.
|-
| {{Freenode IRC|bitcoin-gentoo}} || Gentoo community.
|-
| {{Freenode IRC|bitcoin-marketing}} || Marketing and promotion of bitcoin
|-
| {{Freenode IRC|bitcoin-news}} || RSS News related to Bitcoin.
|-
| {{Freenode IRC|bitcoin-politics}} || Discuss politics with other Bitcoin users.
|-
| {{Freenode IRC|#bitcoin-pricetalk|text=#bitcoin-pricetalk}} || ALL Discussion Remotely Related to Bitcoin Price or other offtopic goes here
|-
| {{Freenode IRC|bitcoin-watch|text=[[Bitcoin-Watch|#bitcoin-watch]]}} || Streaming Bitcoin transactions, including market data.
|-
| {{Freenode IRC|bitcoin-wiki}} || Bitcoin Wiki support
|-
| {{Freenode IRC|bitcoin-wizards}} || Bitcoin experts and futurists ([http://gnusha.org/bitcoin-wizards/ history])
|-
| {{Freenode IRC|lightning-dev}} || Lightning protocol development ([http://gnusha.org/lightning-dev/ history])
|-
| {{Freenode IRC|lnd}} || Lightning only version of #bitcoin-commits
|-
| {{Freenode IRC|sidechains-dev}} || Sidechains development
|}

===Local communities===

{| class="wikitable"
| {{Freenode IRC|bitcoin-otc-eu}} || European OTC trading marketplace.
|-
| {{Freenode IRC|bitcoin-otc-ru}} || Russian OTC trading marketplace.
|-
| {{Freenode IRC|bitcoin-otc-uk}} ||United kingdom OTC Trading Marketplace.Founder Angus Bates.
|-
| {{Freenode IRC|bitcoin-aus}} || Aussie bitcoin community.
|-
| {{Freenode IRC|AustinBitcoin}} || Austin, TX bitcoin community.
|-
| {{Freenode IRC|bitcoin-bra}} || Brazilian bitcoin community.
|-
| {{Freenode IRC|bitcoin-cad}} || Canadian bitcoin community.
|-
| {{Freenode IRC|bitcoin-cn}} || Chinese bitcoin community.
|-
| {{Freenode IRC|bitcoin-dk}} || Danish bitcoin community.
|-
| {{Freenode IRC|bitcoin-de}} || German bitcoin community.
|-
| {{Freenode IRC|bitcoin-eastcoastusa}} || East Coast USA bitcoin community.
|-
| {{Freenode IRC|bitcoin-il}} || Israeli bitcoin community.
|-
| {{Freenode IRC|bitcoin-nl}} || Dutch bitcoin community.
|-
| {{Freenode IRC|bitcoin-pl}} || Polish bitcoin community.
|-
| {{Freenode IRC|bitcoin-romania}} || Romanian bitcoin community.
|-
| {{Freenode IRC|bitcoin-ve}} || Venezuelan bitcoin community.
|-
| {{Freenode IRC|btc.chat}} || Russian bitcoin community.
|-
| #bitcoins.fi @ IRCNet || Finnish bitcoin community.
|-
| {{Freenode IRC|bitcoin-hr}} || Croatian language bitcoin community.

|}

==Mining Related Communities==

{| class="wikitable"
! Channel !! Description
|-
| {{Freenode IRC|avalon}} || Discussion and support specific to [[Avalon]] mining machine
|-
| {{Freenode IRC|bitcoin-mining}} || Discussion and support related to mining.
|-
| {{Freenode IRC|bitcoin-fpga}} || Discussion and support specific to FPGA mining.
|-
| {{Freenode IRC|btcguild}} || [[BTCGuild]] mining pool community
|-
| {{Freenode IRC|butterflylabs}} || [[Butterfly Labs]] chat
|-
| {{Freenode IRC|cgminer}} || Discussion and support specific to [[CGMiner]].
|-
| {{Freenode IRC|eligius}} || [[Eligius]] mining pool community (also support for [[BFGMiner]] and [[Eloipool]])
|-
| {{Freenode IRC|mining.bitcoin.cz}} || Slush's mining pool community
|-
| {{Freenode IRC|ozcoin}} || [[Ozco.in]] mining pool community
|-
| [irc://irc.foonetic.net/xkcd-bitcoin IRC] [http://irc.lc/foonetic/xkcd-bitcoin/Miner@@@ Web] #xkcd-bitcoin || [https://en.bitcoin.it/wiki/XKCD_Pool XKCD Pool]
|-
| [irc://irc.quakenet.org/bitcoins.lc IRC] [http://irc.lc/quakenet/bitcoins.lc/Miner@@@ Web] #bitcoins.lc @ Quakenet || [http://www.bitcoins.lc Bitcoins.lc Pool]
|-
| {{Freenode IRC|p2pool}} || [[P2Pool]] decentralized mining pool
|-
| {{Freenode IRC|bitminter}} || [[BitMinter]] Mining Pool Community
|-
| {{Freenode IRC|kncminer}} || [[KNCMiner]] ASIC Mining Hardware Vendor Discussion
|}

==Communities for Exchanges and Trading==

{| class="wikitable"
! Channel !! Description
|-
| {{Freenode IRC|bitcoin-assets}} || Discussion of securities and other asset investments. [http://bitcoin-assets.com bitcoin-assets.com].
|-
| {{Freenode IRC|bitcoin-assets-trades}} || Streaming assets market data (only), no chat.
|-
| {{Freenode IRC|bitcoin-auction}} || Live auctions over IRC.
|-
| {{Freenode IRC|bitcoin-market}} || Streaming market data (only), no chat.
|-
| {{Freenode IRC|bitcoin-otc|text=[[bitcoin-otc|#bitcoin-otc]]}} || Over-the-counter trading marketplace and discussion. ([http://bitcoinstats.com/irc/bitcoin-otc/logs/ history])
|-
| {{Freenode IRC|bitcoin-escrow}} || Third party escrow agents.
|-
| {{Freenode IRC|bitcoin-otc-ticker|bitcoin-otc-ticker}} || Streaming market data form the [[#bitcoin-otc]] order book.
|-
| {{Freenode IRC|bitcoin-otc-ratings|bitcoin-otc-ratings}} || Updates to ratings on the [[#bitcoin-otc]] Web of Trust.
|-
| {{Freenode IRC|bitcoin-pit}} || Only over-the-counter trading.
|-
| {{Freenode IRC|bitcoin-wot|bitcoin-wot}} || Distributed Web of Trust (WoT) system for [[#bitcoin-otc]].
|-
| {{Freenode IRC|btc.chat.traders}} || Russian community discussion about trades/exchanges.
|-
| {{Freenode IRC|coinbase}} || [[Coinbase]] chat
|-
| {{Freenode IRC|bitcoin-rt}} || Real-time tape (executed trades).
|-
| {{Freenode IRC|localbitcoins-chat}} || [[LocalBitcoins.com]] exchange support
|-
| {{Freenode IRC|Coinabul}} || [http://Coinabul.com Coinabul]'s customer support and news channel. Selling gold and silver for Bitcoin.
|}

==Related Communities==

{| class="wikitable"
! Channel !! Description
|-
| {{Freenode IRC|opentransactions}} || [[Open Transactions]] project.
|-
| {{Freenode IRC|namecoin}} || [[Namecoin]] and the [[Dot-bit]] project.
|-
| {{Freenode IRC|twister}} || [[Twister]], P2P microblogging discussion.
|-
| {{Freenode IRC|joinmarket}} || [[JoinMarket]], A [[CoinJoin]] implementation
|-
| {{Freenode IRC|darkwallet}} || [[DarkWallet]] and libbitcoin/Obelisk discussion & development channel.
|-
| {{Freenode IRC|electrum}} || [[Electrum]], lightweight bitcoin client.
|-
| {{Freenode IRC|copay}} || [[Copay]], lightweight bitcoin client.
|-
| {{Freenode IRC|bitcoin-stackexchange}} || Discussion complementing [http://bitcoin.stackexchange.com Bitcoin StackExchange].

|}

==See Also==

* [[Bitcoin_Wiki:Community_portal]]

[[fr:Canaux IRC]]
[[pl:Kanały IRC]]
[[ro:Canale]]

Bitcoin XT

2020-06-30T20:48:50Z

Ysangkok: /* Bitcoin Cash support */ fix ref

{{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 [[Mike Hearn]] in 2014. Originally designed to introduce alternative P2P rules, it later gained significant notoriety and support after its adoption of [[BIP 0101|BIP 101]] without community support 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 quoted Bram Cohen <ref>Whiny Ragequitting https://medium.com/@bramcohen/whiny-ragequitting-cab164b1e88</ref> in describing Hearn's move as "whiny rage quitting" <ref>Mike Hearn's move from Bitcoin to Banks - Stacy Herbert, Max Keiser & Simon Dixon discuss https://www.youtube.com/watch?v=ubqjei3Jd-U</ref> 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).

==History==
On June 10, 2014 Mike Hearn published a ''Bitcoin Improvement Proposal'' (BIP 64), calling for the addition of "a small P2P protocol extension that performs [[UTXO]] lookups given a set of outpoints."<ref>{{cite web|url=https://github.com/bitcoin/bips/blob/master/bip-0064.mediawiki|title=bips/bip-0064.mediawiki at master · bitcoin/bips · GitHub|work=GitHub}}</ref> On December 27, 2014 Hearn released version 0.10 of the client, with the BIP 64 changes.<ref>{{cite web|url=https://github.com/bitcoinxt/bitcoinxt/releases/tag/v0.10|title=bitcoinxt/bitcoinxt|website=GitHub}}</ref>

On June 22, 2015, [[Gavin Andresen]] published BIP 101 calling for an increase in the maximum block size. The changes would activate a fork allowing eight MB blocks (doubling in size every two years) once 75% of a stretch of 1,000 mined blocks is achieved after the beginning of 2016.<ref>{{cite web|url=https://github.com/bitcoin/bips/blob/master/bip-0101.mediawiki|title=bips/bip-0101.mediawiki at master · bitcoin/bips · GitHub|work=GitHub}}</ref> The new maximum transaction rate under XT would have been 24 transactions per second.<ref name="edov">{{Cite news |url=http://www.pcworld.com/article/2974339/bitcoin-xt-debate-overshadowing-growth-opportunities.html |title=Bitcoin XT debate overshadowing growth opportunities |author=Tim Hornyak |accessdate=7 January 2017 |date=21 August 2015 |work=PC World |publisher=IDG }}</ref>

On August 6, 2015 Andresen's BIP101 proposal was merged into the XT codebase.<ref>{{cite web|url=https://github.com/bitcoinxt/bitcoinxt/commit/946e3ba8c7806a66c2b834d3817ff0c986c0811b|title=Implement hard fork to allow bigger blocks · bitcoinxt/bitcoinxt@946e3ba|website=GitHub}}</ref><ref>{{cite web|url=https://github.com/bitcoinxt/bitcoinxt/releases/tag/v0.11A|title=bitcoinxt/bitcoinxt|website=GitHub}}</ref> Bip 101 was reverted<ref>{{cite web|url=https://github.com/bitcoinxt/bitcoinxt/pull/117|title=2MB block size bump by dgenr8 · Pull Request #117 · bitcoinxt/bitcoinxt|website=GitHub}}</ref> and the 2-MB block size bump of [[Bitcoin Classic]] was applied instead.

== Reception ==
The August 2015 release of XT received widespread media coverage. ''The Guardian'' wrote that "bitcoin is facing civil war".<ref>{{cite news|url=https://www.theguardian.com/technology/2015/aug/17/bitcoin-xt-alternative-cryptocurrency-chief-scientist|title=Bitcoin's forked: chief scientist launches alternative proposal for the currency|author=Alex Hern|date=17 August 2015|newspaper=the Guardian|accessdate=20 August 2015}}</ref>

''Wired'' wrote that "Bitcoin XT exposes the extremely social — extremely democratic — underpinnings of the open source idea, an approach that makes open source so much more powerful than technology controlled by any one person or organization."<ref>{{cite news|url=https://www.wired.com/2015/08/bitcoin-schism-shows-genius-open-source/|title=The Bitcoin Schism Shows the Genius of Open Source|date=19 August 2015|work=WIRED|author=Cade Metz}}</ref> Hashcash developer [[Adam Back]] was critical of the 75% activation threshold being too low and that some of the changes were insecure.<ref name="bisp">{{Cite news |url=https://www.cnbc.com/2015/08/20/bitcoin-splits-will-it-break-or-be-better-than-ever.html |title=Bitcoin splits: Will it break, or be better than ever? |author=Everett Rosenfeld |accessdate=5 January 2017 |date=20 August 2015 |work=CNBC }}</ref>

==Bitcoin Cash support==

On August 25, 2017, Bitcoin XT published ''Release G'', which was a Bitcoin Cash client by default.<ref>{{cite web|url=https://github.com/bitcoinxt/bitcoinxt/releases|title=Bitcoin XT Releases|accessdate=17 June 2018}}</ref> Subsequently, ''Release H'' was published, which supported the November 2017 Bitcoin Cash protocol upgrade, followed by ''Release I'', which supported the May 2018 Bitcoin Cash protocol upgrade.

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

Bitcoin XT

2020-06-30T20:48:20Z

Ysangkok: add more sections from deleted wikipedia article

{{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 [[Mike Hearn]] in 2014. Originally designed to introduce alternative P2P rules, it later gained significant notoriety and support after its adoption of [[BIP 0101|BIP 101]] without community support 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 quoted Bram Cohen <ref>Whiny Ragequitting https://medium.com/@bramcohen/whiny-ragequitting-cab164b1e88</ref> in describing Hearn's move as "whiny rage quitting" <ref>Mike Hearn's move from Bitcoin to Banks - Stacy Herbert, Max Keiser & Simon Dixon discuss https://www.youtube.com/watch?v=ubqjei3Jd-U</ref> 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).

==History==
On June 10, 2014 Mike Hearn published a ''Bitcoin Improvement Proposal'' (BIP 64), calling for the addition of "a small P2P protocol extension that performs [[UTXO]] lookups given a set of outpoints."<ref>{{cite web|url=https://github.com/bitcoin/bips/blob/master/bip-0064.mediawiki|title=bips/bip-0064.mediawiki at master · bitcoin/bips · GitHub|work=GitHub}}</ref> On December 27, 2014 Hearn released version 0.10 of the client, with the BIP 64 changes.<ref>{{cite web|url=https://github.com/bitcoinxt/bitcoinxt/releases/tag/v0.10|title=bitcoinxt/bitcoinxt|website=GitHub}}</ref>

On June 22, 2015, [[Gavin Andresen]] published BIP 101 calling for an increase in the maximum block size. The changes would activate a fork allowing eight MB blocks (doubling in size every two years) once 75% of a stretch of 1,000 mined blocks is achieved after the beginning of 2016.<ref>{{cite web|url=https://github.com/bitcoin/bips/blob/master/bip-0101.mediawiki|title=bips/bip-0101.mediawiki at master · bitcoin/bips · GitHub|work=GitHub}}</ref> The new maximum transaction rate under XT would have been 24 transactions per second.<ref name="edov">{{Cite news |url=http://www.pcworld.com/article/2974339/bitcoin-xt-debate-overshadowing-growth-opportunities.html |title=Bitcoin XT debate overshadowing growth opportunities |author=Tim Hornyak |accessdate=7 January 2017 |date=21 August 2015 |work=PC World |publisher=IDG }}</ref>

On August 6, 2015 Andresen's BIP101 proposal was merged into the XT codebase.<ref>{{cite web|url=https://github.com/bitcoinxt/bitcoinxt/commit/946e3ba8c7806a66c2b834d3817ff0c986c0811b|title=Implement hard fork to allow bigger blocks · bitcoinxt/bitcoinxt@946e3ba|website=GitHub}}</ref><ref>{{cite web|url=https://github.com/bitcoinxt/bitcoinxt/releases/tag/v0.11A|title=bitcoinxt/bitcoinxt|website=GitHub}}</ref> Bip 101 was reverted<ref>{{cite web|url=https://github.com/bitcoinxt/bitcoinxt/pull/117|title=2MB block size bump by dgenr8 · Pull Request #117 · bitcoinxt/bitcoinxt|website=GitHub}}</ref> and the 2-MB block size bump of [[Bitcoin Classic]] was applied instead.

== Reception ==
The August 2015 release of XT received widespread media coverage. ''The Guardian'' wrote that "bitcoin is facing civil war".<ref>{{cite news|url=https://www.theguardian.com/technology/2015/aug/17/bitcoin-xt-alternative-cryptocurrency-chief-scientist|title=Bitcoin's forked: chief scientist launches alternative proposal for the currency|author=Alex Hern|date=17 August 2015|newspaper=the Guardian|accessdate=20 August 2015}}</ref>

''Wired'' wrote that "Bitcoin XT exposes the extremely social — extremely democratic — underpinnings of the open source idea, an approach that makes open source so much more powerful than technology controlled by any one person or organization."<ref>{{cite news|url=https://www.wired.com/2015/08/bitcoin-schism-shows-genius-open-source/|title=The Bitcoin Schism Shows the Genius of Open Source|date=19 August 2015|work=WIRED|author=Cade Metz}}</ref> Hashcash developer [[Adam Back]] was critical of the 75% activation threshold being too low and that some of the changes were insecure.<ref name="bisp">{{Cite news |url=https://www.cnbc.com/2015/08/20/bitcoin-splits-will-it-break-or-be-better-than-ever.html |title=Bitcoin splits: Will it break, or be better than ever? |author=Everett Rosenfeld |accessdate=5 January 2017 |date=20 August 2015 |work=CNBC }}</ref>

==Bitcoin Cash support==

On August 25, 2017, Bitcoin XT published ''Release G'', which was a Bitcoin Cash client by default.<ref name="releases"/> Subsequently, ''Release H'' was published, which supported the November 2017 Bitcoin Cash protocol upgrade, followed by ''Release I'', which supported the May 2018 Bitcoin Cash protocol upgrade.

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

Bitcoin Core

2020-06-30T17:12:12Z

Ysangkok: /* Features */ remove block size discussion not specific to bitcoin core, move network alert to new bullet point

'''Bitcoin Core''' (formerly '''Bitcoin-Qt''') is the third [[Bitcoin]] [[Clients|client]], developed by [[Wladimir van der Laan]] based on the original reference code by [[Satoshi Nakamoto]].<ref>https://gavintech.blogspot.co.uk/2012/03/full-disclosure-bitcoin-qt-on-windows.html, Full disclosure: Bitcoin-Qt on Windows vulnerability, 21st October 2012</ref><ref>https://nvd.nist.gov/vuln/detail/CVE-2012-4682, Vulnerability Summary for CVE-2012-4682, 21st October 2012</ref> It has been bundled with [[bitcoind]] since version 0.5. Bitcoin-Qt has been rebranded to '''[[Bitcoin Core]]''' since version 0.9.0 <ref name="Rebranding to Bitcoin Core">{{cite web|title=Bitcoin Core version 0.9.0 released|url=https://bitcoin.org/en/release/v0.9.0|publisher=Bitcoin.org|accessdate=19 March 2014}}</ref>.

Bitcoin Core can be used as a desktop client for regular payments or as a server utility for merchants and other payment services.

===Current version===
Source code (and build instructions for supported platforms) can be found on the [https://github.com/bitcoin/bitcoin Bitcoin GitHub page].

==Features==
* Most popular software implementation of a bitcoin [[full node]]. Provides trustless validation that all of bitcoin's consensus rules are being followed.
* Has an RPC interface allowing developers to interface with Core and access the bitcoin currency trustlessly.
* Has a GUI frontend, Bitcoin-Qt, allowing ordinary users to use bitcoin with full validation.
* Compatibility with Linux (both GNOME and KDE), Mac OS X and Windows
* All functionality of the original wxWidgets client
* Asks for confirmation before sending coins
* CSV export of transactions
* Clearer transaction list with status icons and real-time filtering
* Progress bar on initial block download
* Languages: Dutch, English, German, Chinese and many more. Translations are being done by volunteers on [https://www.transifex.com/projects/p/bitcoin/ Transifex].
* Sendmany support in UI (send to multiple recipients in one transaction)
* Multiple [[Units|unit]] support, can show subdivided bitcoins (mBTC, µBTC) for users that like large numbers (only decimal units)
* Splash screen that details progress
* Debug window
* Payment requests (BIP 70)
* Coin control
* Bitcoin Core uses OpenTimestamps.org to timestamp merge commits.<ref>{{cite web|url=https://github.com/bitcoin/bitcoin/blob/ebd786b72a2a15143d7ef4ea2229fef121bd8f12/contrib/devtools/README.md#create-and-verify-timestamps-of-merge-commits|title=Bitcoin Core devtools README - Create and verify timestamps of merge commits|date=|website=GitHub|archive-url=|archive-date=|accessdate=May 5, 2018}}</ref>
* Checkpoints which have been hard coded into the client are used only to prevent Denial of Service attacks against nodes which are initially syncing the chain. For this reason the checkpoints included are only as of several years ago.<ref name="check">{{cite web |url=https://github.com/bitcoin/bitcoin/blob/master/src/checkpoints.cpp |title=checkpoints.cpp |work=Repository source code |publisher=GitHub, Inc. |accessdate=13 November 2016 }}</ref><ref>{{cite web |title=bitcoin/chainparams.cpp |url=https://github.com/bitcoin/bitcoin/blob/master/src/chainparams.cpp |website=GitHub |accessdate=21 October 2018}}</ref>
* A network alert system was included by Satoshi Nakamoto as a way of informing users of important news regarding bitcoin.<ref name="asr">{{cite web |url=https://bitcoin.org/en/alert/2016-11-01-alert-retirement |title=Alert System Retirement |date=1 November 2016 |publisher=Bitcoin Project |accessdate=16 November 2016 }}</ref> In November 2016 it was retired. It had become obsolete as news on bitcoin is now widely disseminated.

== Naming Controversy ==

Some people like Peter Todd, Luke-jr and Greg Maxwell warned against the renaming to Bitcoin Core because it implied a centralization.<ref>https://www.reddit.com/r/Bitcoin/comments/60jmq2/a_proposal_for_and_demo_of_a_new_bitcoin_address/df73k2h/</ref><ref>https://www.reddit.com/r/Bitcoin/comments/60owl3/did_you_know_that_bitcoin_core_opposed_its_own/</ref><ref>https://bitcoinfoundation.org/forum/index.php?/topic/95-new-name-for-bitcoin-qt-bitcoind/&</ref>.

Bitcoin Core right now may be the most popular or "reference" [[full node]] implementation, but that status depends on the [[economic majority]] continuing to use it<ref>https://bitcoinmagazine.com/articles/a-primer-on-bitcoin-governance-or-why-developers-aren-t-in-charge-of-the-protocol-1473270427/</ref>. Should one day come where another implementation overtakes it economically, that implementation would become the reference implementation. In one situation in 2017 significant parts of the economy moved to the BIP148 [[UASF]] implementation<ref>https://bitcoinmagazine.com/articles/long-road-segwit-how-bitcoins-biggest-protocol-upgrade-became-reality/</ref> and then moved back to Core after BIP148 was successful. The point here is that Bitcoin Core does not control bitcoin and the naming "Core" is misleading in that respect.

On the other hand, many people are happy with the name Bitcoin Core and continue to use it. As long as it's emphasized that Bitcoin Core is just one possible software implementation of bitcoin that people are free to use or not use.

==Development==
The original creator of the bitcoin client has described their approach to the software's authorship as it being written first to prove to themselves that the concept of purely peer-to-peer electronic cash was valid and that a paper with solutions could be written. The lead developer is Wladimir J. van der Laan, who took over the role on 8 April 2014.<ref name="hunt"/> [[Gavin Andresen]] was the former lead maintainer for the software client. Andresen left the role of lead developer for bitcoin to work on the strategic development of its technology.<ref name="hunt">Bitcoin: The Hunt of Satoshi Nakamoto, Alex Preukschat, Josep Busquet, 2015, Europe Comics, ISBN 9791032800201, page 87 [https://play.google.com/store/books/details?id=438FCwAAQBAJ]</ref> Bitcoin Core developers have been in charge of bitcoin's development since [[Satoshi Nakamoto]] left the project.<ref name="wtbf">{{Cite news |url=https://www.forbes.com/sites/laurashin/2017/10/23/will-this-battle-for-the-soul-of-bitcoin-destroy-it/#62d19db23d3c |title=Will This Battle For The Soul Of Bitcoin Destroy It? |author=Laura Shin |accessdate=14 April 2018 |date=23 October 2017 |work=Forbes }}</ref> Bitcoin Core in 2015 was central to a dispute with [[Bitcoin XT]], a competing client that sought to increase the blocksize.<ref name="NewYorker">{{Cite news |url=https://www.newyorker.com/business/currency/inside-the-fight-over-bitcoins-future
|title=Inside the Fight Over Bitcoin’s Future |author=Maria Bustillos |accessdate=29 June 2020 |date=25 August 2015 |work=New Yorker}}</ref> Over a dozen different companies and industry groups fund the development of Bitcoin Core.<ref>{{cite web|url=https://blog.bitmex.com/who-funds-bitcoin-development/|title=Who Funds Bitcoin Development?|date=2020-03-28|publisher=BitMex Research|access-date=2020-06-30}}</ref>

[https://www.youtube.com/watch?v=FIt7GLxxIpY Visualization of code changes during 2015]

==Version history==
Bitcoin 0.1 was released on 9 January 2009 by Satoshi Nakamoto with only Windows supported. This was followed by some minor bug fixing versions. On 16 December 2009 Bitcoin 0.2 was released. It included a Linux version for the first time and made use of multi-core processors for mining. In version 0.3.2 Nakamoto included checkpoints as a safeguard. After the release of version 0.3.9, Satoshi Nakamoto left the project and shortly after stopped communicating on online forums.

Between 2011 and 2013 new versions of the software were released at Bitcoin.org.<ref name="abo">{{cite web |url=https://bitcoin.org/en/about-us#sponsorship |title=About bitcoin.org |publisher=Bitcoin Project |accessdate=14 November 2016 }}</ref> Developers wanted to differentiate themselves as creators of software rather than advocates for bitcoin and so now maintain bitcoincore.org for just the software.

Bitcoin-Qt version 0.5.0 was released on 1 November 2011. It introduced a front end that uses the Qt user interface toolkit.<ref name="bqt">{{cite web |url=https://bitcoin.org/en/release/v0.5.0 |title=Bitcoin-Qt version 0.5.0 released |date=1 November 2011 |publisher=Bitcoin Project |accessdate=13 November 2016 }}</ref> The software previously used Berkeley DB for database management. Developers switched to LevelDB in release 0.8 in order to reduce blockchain synchronization time ([[initial block download]], beware, a misnomer). The update to this release resulted in a minor blockchain fork on the 11 March 2013. The fork was resolved shortly afterwards. Seeding nodes through Internet Relay Chat was discontinued in version 0.8.2. From version 0.9.0 the software was renamed to Bitcoin Core. Transaction fees were reduced again by a factor of ten as a means to encourage microtransactions. Although Bitcoin Core does not use OpenSSL for the operation of the network, the software did use OpenSSL for remote procedure calls. Version 0.9.1 was released to remove the network's vulnerability to the Heartbleed bug.

Release 0.10 was made public on 16 February 2015. It introduced a consensus library which gave programmers easy access to the rules governing consensus on the network. In version 0.11.2 developers added a new feature which allowed transactions to be made unspendable until a specific time in the future.<ref name="v0.11.2">{{cite web |url=https://bitcoin.org/en/release/v0.11.2 |title=Bitcoin Core version 0.11.2 released |date=13 November 2015 |publisher=Bitcoin Project |accessdate=14 November 2016 }}</ref> Bitcoin Core 0.12.1 was released on April 15, 2016 and enabled multiple soft forks to occur concurrently.<ref name="0.12.1rel">{{Cite news |url=http://www.nasdaq.com/article/bitcoin-core-0121-released-major-step-forward-for-scalability-cm607209 |title=Bitcoin Core 0.12.1 Released, Major Step Forward for Scalability |author=Kyle Torpey |accessdate=7 November 2016 |date=15 April 2016 |work=Bitcoin Magazine |publisher=NASDAQ.com }}</ref> Around 100 contributors worked on Bitcoin Core 0.13.0 which was released on 23 August 2016.

In July 2016, the CheckSequenceVerify soft fork activated.<ref>Mastering Bitcoin: Programming the Open Blockchain. Quote "BIP-68 and BIP-112 were activated in May 2016 as a soft fork upgrade to the consensus rules."</ref>

In October 2016, Bitcoin Core’s 0.13.1 release featured the "[[Segwit]]" soft fork that included a scaling improvement aiming to optimize the bitcoin blocksize. The patch which was originally finalised in April, and 35 developers were engaged to deploy it. This release featured Segregated Witness ([[SegWit]]) which aimed to place downward pressure on transaction fees as well as increase the maximum transaction capacity of the network.<ref name="rel13.1">{{cite web |url=https://bitcoincore.org/en/releases/0.13.1/ |title=Bitcoin Core 0.13.1 |publisher=Bitcoin Core |accessdate=25 October 2016 }}</ref> The 0.13.1 release endured extensive testing and research leading to some delays in its release date. SegWit prevents various forms of transaction malleability.<ref name="swb">{{cite web|url=https://bitcoincore.org/en/2016/01/26/segwit-benefits/|title=Segregated Witness Benefits|last=|first=|date=January 26, 2016|work=Bitcoin Core|archive-url=|archive-date=|accessdate=October 20, 2018}}</ref>

In September 2018, a Bitcoin Cash developer discovered the vulnerability CVE 2018-17144 in the Bitcoin Core software that could allow an attacker to crash vulnerable Bitcoin Core nodes and exceed the 21 million coin limit.<ref>{{Cite news|url=https://bitcoincore.org/en/2018/09/20/notice/|title=CVE-2018-17144 Full Disclosure|work=Bitcoin Core|access-date=2018-09-23|language=en}}</ref>

==Bitcoin Improvement Proposals==
A [[Bitcoin Improvement Proposal]] (BIP) is a design document, typically describing a new feature for Bitcoin with a concise technical specification of the feature and the rationale for it. Bitcoin Core implements some of these design documents.

==See also==

* [[bitcoind]]
* [[Full node]]
* [[Bitcoin Knots]]
* [[QBitcoin]]

==External Links==

* [https://bitcoin.org/en/download Download link at bitcoin.org]
* [https://bitcoin.org/en/version-history Version history]
* [https://bitcoincore.org/ Bitcoin Core website]
* [https://bitcointalk.org/index.php?topic=15276.0 Forum thread] (includes screenshots)
* [https://github.com/bitcoin/bitcoin Current GitHub repository shared with bitcoind]

== References ==

<references/>

[[es:Bitcoin-Qt]]

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

{{Bitcoin Core documentation}}

Bitcoin Core

2020-06-30T17:10:42Z

Ysangkok: /* Features */ timestamping, checkpoints (from deleted wikipedia article)

'''Bitcoin Core''' (formerly '''Bitcoin-Qt''') is the third [[Bitcoin]] [[Clients|client]], developed by [[Wladimir van der Laan]] based on the original reference code by [[Satoshi Nakamoto]].<ref>https://gavintech.blogspot.co.uk/2012/03/full-disclosure-bitcoin-qt-on-windows.html, Full disclosure: Bitcoin-Qt on Windows vulnerability, 21st October 2012</ref><ref>https://nvd.nist.gov/vuln/detail/CVE-2012-4682, Vulnerability Summary for CVE-2012-4682, 21st October 2012</ref> It has been bundled with [[bitcoind]] since version 0.5. Bitcoin-Qt has been rebranded to '''[[Bitcoin Core]]''' since version 0.9.0 <ref name="Rebranding to Bitcoin Core">{{cite web|title=Bitcoin Core version 0.9.0 released|url=https://bitcoin.org/en/release/v0.9.0|publisher=Bitcoin.org|accessdate=19 March 2014}}</ref>.

Bitcoin Core can be used as a desktop client for regular payments or as a server utility for merchants and other payment services.

===Current version===
Source code (and build instructions for supported platforms) can be found on the [https://github.com/bitcoin/bitcoin Bitcoin GitHub page].

==Features==
* Most popular software implementation of a bitcoin [[full node]]. Provides trustless validation that all of bitcoin's consensus rules are being followed.
* Has an RPC interface allowing developers to interface with Core and access the bitcoin currency trustlessly.
* Has a GUI frontend, Bitcoin-Qt, allowing ordinary users to use bitcoin with full validation.
* Compatibility with Linux (both GNOME and KDE), Mac OS X and Windows
* All functionality of the original wxWidgets client
* Asks for confirmation before sending coins
* CSV export of transactions
* Clearer transaction list with status icons and real-time filtering
* Progress bar on initial block download
* Languages: Dutch, English, German, Chinese and many more. Translations are being done by volunteers on [https://www.transifex.com/projects/p/bitcoin/ Transifex].
* Sendmany support in UI (send to multiple recipients in one transaction)
* Multiple [[Units|unit]] support, can show subdivided bitcoins (mBTC, µBTC) for users that like large numbers (only decimal units)
* Splash screen that details progress
* Debug window
* Payment requests (BIP 70)
* Coin control
* Bitcoin Core uses [[OpenTimestamps]] to timestamp merge commits.<ref>{{cite web|url=https://github.com/bitcoin/bitcoin/blob/ebd786b72a2a15143d7ef4ea2229fef121bd8f12/contrib/devtools/README.md#create-and-verify-timestamps-of-merge-commits|title=Bitcoin Core devtools README - Create and verify timestamps of merge commits|date=|website=GitHub|archive-url=|archive-date=|accessdate=May 5, 2018}}</ref>
* Checkpoints which have been hard coded into the client are used only to prevent Denial of Service attacks against nodes which are initially syncing the chain. For this reason the checkpoints included are only as of several years ago.<ref name="check">{{cite web |url=https://github.com/bitcoin/bitcoin/blob/master/src/checkpoints.cpp |title=checkpoints.cpp |work=Repository source code |publisher=GitHub, Inc. |accessdate=13 November 2016 }}</ref><ref>{{cite web |title=bitcoin/chainparams.cpp |url=https://github.com/bitcoin/bitcoin/blob/master/src/chainparams.cpp |website=GitHub |accessdate=21 October 2018}}</ref>{{failed verification|date=December 2019}} A one megabyte block size limit was added in 2010 by Satoshi Nakamoto. This limited the maximum network capacity to about three transactions per second.<ref name="leadbit">{{Cite news |url=https://www.technologyreview.com/s/537486/leaderless-bitcoin-struggles-to-make-its-most-crucial-decision/ |title=Leaderless Bitcoin Struggles to Make Its Most Crucial Decision |author=Mike Orcutt |accessdate=15 November 2016 |date=19 May 2015 |work=MIT Technology Review }}</ref> Since then, network capacity has been improved incrementally both through block size increases and improved wallet behavior. A network alert system was included by Satoshi Nakamoto as a way of informing users of important news regarding bitcoin.<ref name="asr">{{cite web |url=https://bitcoin.org/en/alert/2016-11-01-alert-retirement |title=Alert System Retirement |date=1 November 2016 |publisher=Bitcoin Project |accessdate=16 November 2016 }}</ref> In November 2016 it was retired. It had become obsolete as news on bitcoin is now widely disseminated.

== Naming Controversy ==

Some people like Peter Todd, Luke-jr and Greg Maxwell warned against the renaming to Bitcoin Core because it implied a centralization.<ref>https://www.reddit.com/r/Bitcoin/comments/60jmq2/a_proposal_for_and_demo_of_a_new_bitcoin_address/df73k2h/</ref><ref>https://www.reddit.com/r/Bitcoin/comments/60owl3/did_you_know_that_bitcoin_core_opposed_its_own/</ref><ref>https://bitcoinfoundation.org/forum/index.php?/topic/95-new-name-for-bitcoin-qt-bitcoind/&</ref>.

Bitcoin Core right now may be the most popular or "reference" [[full node]] implementation, but that status depends on the [[economic majority]] continuing to use it<ref>https://bitcoinmagazine.com/articles/a-primer-on-bitcoin-governance-or-why-developers-aren-t-in-charge-of-the-protocol-1473270427/</ref>. Should one day come where another implementation overtakes it economically, that implementation would become the reference implementation. In one situation in 2017 significant parts of the economy moved to the BIP148 [[UASF]] implementation<ref>https://bitcoinmagazine.com/articles/long-road-segwit-how-bitcoins-biggest-protocol-upgrade-became-reality/</ref> and then moved back to Core after BIP148 was successful. The point here is that Bitcoin Core does not control bitcoin and the naming "Core" is misleading in that respect.

On the other hand, many people are happy with the name Bitcoin Core and continue to use it. As long as it's emphasized that Bitcoin Core is just one possible software implementation of bitcoin that people are free to use or not use.

==Development==
The original creator of the bitcoin client has described their approach to the software's authorship as it being written first to prove to themselves that the concept of purely peer-to-peer electronic cash was valid and that a paper with solutions could be written. The lead developer is Wladimir J. van der Laan, who took over the role on 8 April 2014.<ref name="hunt"/> [[Gavin Andresen]] was the former lead maintainer for the software client. Andresen left the role of lead developer for bitcoin to work on the strategic development of its technology.<ref name="hunt">Bitcoin: The Hunt of Satoshi Nakamoto, Alex Preukschat, Josep Busquet, 2015, Europe Comics, ISBN 9791032800201, page 87 [https://play.google.com/store/books/details?id=438FCwAAQBAJ]</ref> Bitcoin Core developers have been in charge of bitcoin's development since [[Satoshi Nakamoto]] left the project.<ref name="wtbf">{{Cite news |url=https://www.forbes.com/sites/laurashin/2017/10/23/will-this-battle-for-the-soul-of-bitcoin-destroy-it/#62d19db23d3c |title=Will This Battle For The Soul Of Bitcoin Destroy It? |author=Laura Shin |accessdate=14 April 2018 |date=23 October 2017 |work=Forbes }}</ref> Bitcoin Core in 2015 was central to a dispute with [[Bitcoin XT]], a competing client that sought to increase the blocksize.<ref name="NewYorker">{{Cite news |url=https://www.newyorker.com/business/currency/inside-the-fight-over-bitcoins-future
|title=Inside the Fight Over Bitcoin’s Future |author=Maria Bustillos |accessdate=29 June 2020 |date=25 August 2015 |work=New Yorker}}</ref> Over a dozen different companies and industry groups fund the development of Bitcoin Core.<ref>{{cite web|url=https://blog.bitmex.com/who-funds-bitcoin-development/|title=Who Funds Bitcoin Development?|date=2020-03-28|publisher=BitMex Research|access-date=2020-06-30}}</ref>

[https://www.youtube.com/watch?v=FIt7GLxxIpY Visualization of code changes during 2015]

==Version history==
Bitcoin 0.1 was released on 9 January 2009 by Satoshi Nakamoto with only Windows supported. This was followed by some minor bug fixing versions. On 16 December 2009 Bitcoin 0.2 was released. It included a Linux version for the first time and made use of multi-core processors for mining. In version 0.3.2 Nakamoto included checkpoints as a safeguard. After the release of version 0.3.9, Satoshi Nakamoto left the project and shortly after stopped communicating on online forums.

Between 2011 and 2013 new versions of the software were released at Bitcoin.org.<ref name="abo">{{cite web |url=https://bitcoin.org/en/about-us#sponsorship |title=About bitcoin.org |publisher=Bitcoin Project |accessdate=14 November 2016 }}</ref> Developers wanted to differentiate themselves as creators of software rather than advocates for bitcoin and so now maintain bitcoincore.org for just the software.

Bitcoin-Qt version 0.5.0 was released on 1 November 2011. It introduced a front end that uses the Qt user interface toolkit.<ref name="bqt">{{cite web |url=https://bitcoin.org/en/release/v0.5.0 |title=Bitcoin-Qt version 0.5.0 released |date=1 November 2011 |publisher=Bitcoin Project |accessdate=13 November 2016 }}</ref> The software previously used Berkeley DB for database management. Developers switched to LevelDB in release 0.8 in order to reduce blockchain synchronization time ([[initial block download]], beware, a misnomer). The update to this release resulted in a minor blockchain fork on the 11 March 2013. The fork was resolved shortly afterwards. Seeding nodes through Internet Relay Chat was discontinued in version 0.8.2. From version 0.9.0 the software was renamed to Bitcoin Core. Transaction fees were reduced again by a factor of ten as a means to encourage microtransactions. Although Bitcoin Core does not use OpenSSL for the operation of the network, the software did use OpenSSL for remote procedure calls. Version 0.9.1 was released to remove the network's vulnerability to the Heartbleed bug.

Release 0.10 was made public on 16 February 2015. It introduced a consensus library which gave programmers easy access to the rules governing consensus on the network. In version 0.11.2 developers added a new feature which allowed transactions to be made unspendable until a specific time in the future.<ref name="v0.11.2">{{cite web |url=https://bitcoin.org/en/release/v0.11.2 |title=Bitcoin Core version 0.11.2 released |date=13 November 2015 |publisher=Bitcoin Project |accessdate=14 November 2016 }}</ref> Bitcoin Core 0.12.1 was released on April 15, 2016 and enabled multiple soft forks to occur concurrently.<ref name="0.12.1rel">{{Cite news |url=http://www.nasdaq.com/article/bitcoin-core-0121-released-major-step-forward-for-scalability-cm607209 |title=Bitcoin Core 0.12.1 Released, Major Step Forward for Scalability |author=Kyle Torpey |accessdate=7 November 2016 |date=15 April 2016 |work=Bitcoin Magazine |publisher=NASDAQ.com }}</ref> Around 100 contributors worked on Bitcoin Core 0.13.0 which was released on 23 August 2016.

In July 2016, the CheckSequenceVerify soft fork activated.<ref>Mastering Bitcoin: Programming the Open Blockchain. Quote "BIP-68 and BIP-112 were activated in May 2016 as a soft fork upgrade to the consensus rules."</ref>

In October 2016, Bitcoin Core’s 0.13.1 release featured the "[[Segwit]]" soft fork that included a scaling improvement aiming to optimize the bitcoin blocksize. The patch which was originally finalised in April, and 35 developers were engaged to deploy it. This release featured Segregated Witness ([[SegWit]]) which aimed to place downward pressure on transaction fees as well as increase the maximum transaction capacity of the network.<ref name="rel13.1">{{cite web |url=https://bitcoincore.org/en/releases/0.13.1/ |title=Bitcoin Core 0.13.1 |publisher=Bitcoin Core |accessdate=25 October 2016 }}</ref> The 0.13.1 release endured extensive testing and research leading to some delays in its release date. SegWit prevents various forms of transaction malleability.<ref name="swb">{{cite web|url=https://bitcoincore.org/en/2016/01/26/segwit-benefits/|title=Segregated Witness Benefits|last=|first=|date=January 26, 2016|work=Bitcoin Core|archive-url=|archive-date=|accessdate=October 20, 2018}}</ref>

In September 2018, a Bitcoin Cash developer discovered the vulnerability CVE 2018-17144 in the Bitcoin Core software that could allow an attacker to crash vulnerable Bitcoin Core nodes and exceed the 21 million coin limit.<ref>{{Cite news|url=https://bitcoincore.org/en/2018/09/20/notice/|title=CVE-2018-17144 Full Disclosure|work=Bitcoin Core|access-date=2018-09-23|language=en}}</ref>

==Bitcoin Improvement Proposals==
A [[Bitcoin Improvement Proposal]] (BIP) is a design document, typically describing a new feature for Bitcoin with a concise technical specification of the feature and the rationale for it. Bitcoin Core implements some of these design documents.

==See also==

* [[bitcoind]]
* [[Full node]]
* [[Bitcoin Knots]]
* [[QBitcoin]]

==External Links==

* [https://bitcoin.org/en/download Download link at bitcoin.org]
* [https://bitcoin.org/en/version-history Version history]
* [https://bitcoincore.org/ Bitcoin Core website]
* [https://bitcointalk.org/index.php?topic=15276.0 Forum thread] (includes screenshots)
* [https://github.com/bitcoin/bitcoin Current GitHub repository shared with bitcoind]

== References ==

<references/>

[[es:Bitcoin-Qt]]

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

{{Bitcoin Core documentation}}

Bitcoin Core

2020-06-30T17:09:16Z

Ysangkok: add sections "development" and "version history" from deleted wikipedia article

'''Bitcoin Core''' (formerly '''Bitcoin-Qt''') is the third [[Bitcoin]] [[Clients|client]], developed by [[Wladimir van der Laan]] based on the original reference code by [[Satoshi Nakamoto]].<ref>https://gavintech.blogspot.co.uk/2012/03/full-disclosure-bitcoin-qt-on-windows.html, Full disclosure: Bitcoin-Qt on Windows vulnerability, 21st October 2012</ref><ref>https://nvd.nist.gov/vuln/detail/CVE-2012-4682, Vulnerability Summary for CVE-2012-4682, 21st October 2012</ref> It has been bundled with [[bitcoind]] since version 0.5. Bitcoin-Qt has been rebranded to '''[[Bitcoin Core]]''' since version 0.9.0 <ref name="Rebranding to Bitcoin Core">{{cite web|title=Bitcoin Core version 0.9.0 released|url=https://bitcoin.org/en/release/v0.9.0|publisher=Bitcoin.org|accessdate=19 March 2014}}</ref>.

Bitcoin Core can be used as a desktop client for regular payments or as a server utility for merchants and other payment services.

===Current version===
Source code (and build instructions for supported platforms) can be found on the [https://github.com/bitcoin/bitcoin Bitcoin GitHub page].

==Features==
* Most popular software implementation of a bitcoin [[full node]]. Provides trustless validation that all of bitcoin's consensus rules are being followed.
* Has an RPC interface allowing developers to interface with Core and access the bitcoin currency trustlessly.
* Has a GUI frontend, Bitcoin-Qt, allowing ordinary users to use bitcoin with full validation.
* Compatibility with Linux (both GNOME and KDE), Mac OS X and Windows
* All functionality of the original wxWidgets client
* Asks for confirmation before sending coins
* CSV export of transactions
* Clearer transaction list with status icons and real-time filtering
* Progress bar on initial block download
* Languages: Dutch, English, German, Chinese and many more. Translations are being done by volunteers on [https://www.transifex.com/projects/p/bitcoin/ Transifex].
* Sendmany support in UI (send to multiple recipients in one transaction)
* Multiple [[Units|unit]] support, can show subdivided bitcoins (mBTC, µBTC) for users that like large numbers (only decimal units)
* Splash screen that details progress
* Debug window
* Payment requests (BIP 70)
* Coin control

== Naming Controversy ==

Some people like Peter Todd, Luke-jr and Greg Maxwell warned against the renaming to Bitcoin Core because it implied a centralization.<ref>https://www.reddit.com/r/Bitcoin/comments/60jmq2/a_proposal_for_and_demo_of_a_new_bitcoin_address/df73k2h/</ref><ref>https://www.reddit.com/r/Bitcoin/comments/60owl3/did_you_know_that_bitcoin_core_opposed_its_own/</ref><ref>https://bitcoinfoundation.org/forum/index.php?/topic/95-new-name-for-bitcoin-qt-bitcoind/&</ref>.

Bitcoin Core right now may be the most popular or "reference" [[full node]] implementation, but that status depends on the [[economic majority]] continuing to use it<ref>https://bitcoinmagazine.com/articles/a-primer-on-bitcoin-governance-or-why-developers-aren-t-in-charge-of-the-protocol-1473270427/</ref>. Should one day come where another implementation overtakes it economically, that implementation would become the reference implementation. In one situation in 2017 significant parts of the economy moved to the BIP148 [[UASF]] implementation<ref>https://bitcoinmagazine.com/articles/long-road-segwit-how-bitcoins-biggest-protocol-upgrade-became-reality/</ref> and then moved back to Core after BIP148 was successful. The point here is that Bitcoin Core does not control bitcoin and the naming "Core" is misleading in that respect.

On the other hand, many people are happy with the name Bitcoin Core and continue to use it. As long as it's emphasized that Bitcoin Core is just one possible software implementation of bitcoin that people are free to use or not use.

==Development==
The original creator of the bitcoin client has described their approach to the software's authorship as it being written first to prove to themselves that the concept of purely peer-to-peer electronic cash was valid and that a paper with solutions could be written. The lead developer is Wladimir J. van der Laan, who took over the role on 8 April 2014.<ref name="hunt"/> [[Gavin Andresen]] was the former lead maintainer for the software client. Andresen left the role of lead developer for bitcoin to work on the strategic development of its technology.<ref name="hunt">Bitcoin: The Hunt of Satoshi Nakamoto, Alex Preukschat, Josep Busquet, 2015, Europe Comics, ISBN 9791032800201, page 87 [https://play.google.com/store/books/details?id=438FCwAAQBAJ]</ref> Bitcoin Core developers have been in charge of bitcoin's development since [[Satoshi Nakamoto]] left the project.<ref name="wtbf">{{Cite news |url=https://www.forbes.com/sites/laurashin/2017/10/23/will-this-battle-for-the-soul-of-bitcoin-destroy-it/#62d19db23d3c |title=Will This Battle For The Soul Of Bitcoin Destroy It? |author=Laura Shin |accessdate=14 April 2018 |date=23 October 2017 |work=Forbes }}</ref> Bitcoin Core in 2015 was central to a dispute with [[Bitcoin XT]], a competing client that sought to increase the blocksize.<ref name="NewYorker">{{Cite news |url=https://www.newyorker.com/business/currency/inside-the-fight-over-bitcoins-future
|title=Inside the Fight Over Bitcoin’s Future |author=Maria Bustillos |accessdate=29 June 2020 |date=25 August 2015 |work=New Yorker}}</ref> Over a dozen different companies and industry groups fund the development of Bitcoin Core.<ref>{{cite web|url=https://blog.bitmex.com/who-funds-bitcoin-development/|title=Who Funds Bitcoin Development?|date=2020-03-28|publisher=BitMex Research|access-date=2020-06-30}}</ref>

[https://www.youtube.com/watch?v=FIt7GLxxIpY Visualization of code changes during 2015]

==Version history==
Bitcoin 0.1 was released on 9 January 2009 by Satoshi Nakamoto with only Windows supported. This was followed by some minor bug fixing versions. On 16 December 2009 Bitcoin 0.2 was released. It included a Linux version for the first time and made use of multi-core processors for mining. In version 0.3.2 Nakamoto included checkpoints as a safeguard. After the release of version 0.3.9, Satoshi Nakamoto left the project and shortly after stopped communicating on online forums.

Between 2011 and 2013 new versions of the software were released at Bitcoin.org.<ref name="abo">{{cite web |url=https://bitcoin.org/en/about-us#sponsorship |title=About bitcoin.org |publisher=Bitcoin Project |accessdate=14 November 2016 }}</ref> Developers wanted to differentiate themselves as creators of software rather than advocates for bitcoin and so now maintain bitcoincore.org for just the software.

Bitcoin-Qt version 0.5.0 was released on 1 November 2011. It introduced a front end that uses the Qt user interface toolkit.<ref name="bqt">{{cite web |url=https://bitcoin.org/en/release/v0.5.0 |title=Bitcoin-Qt version 0.5.0 released |date=1 November 2011 |publisher=Bitcoin Project |accessdate=13 November 2016 }}</ref> The software previously used Berkeley DB for database management. Developers switched to LevelDB in release 0.8 in order to reduce blockchain synchronization time ([[initial block download]], beware, a misnomer). The update to this release resulted in a minor blockchain fork on the 11 March 2013. The fork was resolved shortly afterwards. Seeding nodes through Internet Relay Chat was discontinued in version 0.8.2. From version 0.9.0 the software was renamed to Bitcoin Core. Transaction fees were reduced again by a factor of ten as a means to encourage microtransactions. Although Bitcoin Core does not use OpenSSL for the operation of the network, the software did use OpenSSL for remote procedure calls. Version 0.9.1 was released to remove the network's vulnerability to the Heartbleed bug.

Release 0.10 was made public on 16 February 2015. It introduced a consensus library which gave programmers easy access to the rules governing consensus on the network. In version 0.11.2 developers added a new feature which allowed transactions to be made unspendable until a specific time in the future.<ref name="v0.11.2">{{cite web |url=https://bitcoin.org/en/release/v0.11.2 |title=Bitcoin Core version 0.11.2 released |date=13 November 2015 |publisher=Bitcoin Project |accessdate=14 November 2016 }}</ref> Bitcoin Core 0.12.1 was released on April 15, 2016 and enabled multiple soft forks to occur concurrently.<ref name="0.12.1rel">{{Cite news |url=http://www.nasdaq.com/article/bitcoin-core-0121-released-major-step-forward-for-scalability-cm607209 |title=Bitcoin Core 0.12.1 Released, Major Step Forward for Scalability |author=Kyle Torpey |accessdate=7 November 2016 |date=15 April 2016 |work=Bitcoin Magazine |publisher=NASDAQ.com }}</ref> Around 100 contributors worked on Bitcoin Core 0.13.0 which was released on 23 August 2016.

In July 2016, the CheckSequenceVerify soft fork activated.<ref>Mastering Bitcoin: Programming the Open Blockchain. Quote "BIP-68 and BIP-112 were activated in May 2016 as a soft fork upgrade to the consensus rules."</ref>

In October 2016, Bitcoin Core’s 0.13.1 release featured the "[[Segwit]]" soft fork that included a scaling improvement aiming to optimize the bitcoin blocksize. The patch which was originally finalised in April, and 35 developers were engaged to deploy it. This release featured Segregated Witness ([[SegWit]]) which aimed to place downward pressure on transaction fees as well as increase the maximum transaction capacity of the network.<ref name="rel13.1">{{cite web |url=https://bitcoincore.org/en/releases/0.13.1/ |title=Bitcoin Core 0.13.1 |publisher=Bitcoin Core |accessdate=25 October 2016 }}</ref> The 0.13.1 release endured extensive testing and research leading to some delays in its release date. SegWit prevents various forms of transaction malleability.<ref name="swb">{{cite web|url=https://bitcoincore.org/en/2016/01/26/segwit-benefits/|title=Segregated Witness Benefits|last=|first=|date=January 26, 2016|work=Bitcoin Core|archive-url=|archive-date=|accessdate=October 20, 2018}}</ref>

In September 2018, a Bitcoin Cash developer discovered the vulnerability CVE 2018-17144 in the Bitcoin Core software that could allow an attacker to crash vulnerable Bitcoin Core nodes and exceed the 21 million coin limit.<ref>{{Cite news|url=https://bitcoincore.org/en/2018/09/20/notice/|title=CVE-2018-17144 Full Disclosure|work=Bitcoin Core|access-date=2018-09-23|language=en}}</ref>

==Bitcoin Improvement Proposals==
A [[Bitcoin Improvement Proposal]] (BIP) is a design document, typically describing a new feature for Bitcoin with a concise technical specification of the feature and the rationale for it. Bitcoin Core implements some of these design documents.

==See also==

* [[bitcoind]]
* [[Full node]]
* [[Bitcoin Knots]]
* [[QBitcoin]]

==External Links==

* [https://bitcoin.org/en/download Download link at bitcoin.org]
* [https://bitcoin.org/en/version-history Version history]
* [https://bitcoincore.org/ Bitcoin Core website]
* [https://bitcointalk.org/index.php?topic=15276.0 Forum thread] (includes screenshots)
* [https://github.com/bitcoin/bitcoin Current GitHub repository shared with bitcoind]

== References ==

<references/>

[[es:Bitcoin-Qt]]

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

{{Bitcoin Core documentation}}

Hardfork

2019-08-19T18:35:29Z

Ysangkok: another hard fork proposed by newbery

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

Bitcoin Core has had two accidental hardforks, and many altcoins have had intended hardforks.

The accidental hardforks are:

* Due to a BerkeleyDB issue, Bitcoin pre-0.8 hardforked, and there was a chain split. This happened in 2013, before the foundation of Bitcoin Core. The post mortem is in [https://github.com/bitcoin/bips/blob/master/bip-0050.mediawiki BIP 0050].
* Bitcoin Core 0.15 accidentally hardforked. See [https://bitcoincore.org/en/2018/09/20/notice/ CVE-2018-17144 full disclosure]. The fix was a softfork deployed in v0.16.3. There was no chain split.

In August 2019, John Newbery proposed another hardfork to bury CSV and segwit activation.[https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2019-August/017268.html]

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

TumbleBit

2019-06-04T22:27:51Z

Ysangkok: a2l

TumbleBit is a anonymous payments protocol from 2016 that is fully compatible with today’s Bitcoin protocol. TumbleBit allows parties to make payments through an untrusted Tumbler. No-one, not even the Tumbler, can tell which payer paid which payee during a TumbleBit epoch. TumbleBit consists of two interleaved fair-exchange protocols that prevent theft of bitcoins by cheating users or a malicious Tumbler. TumbleBit combines fast cryptographic computations (performed off the blockchain) with standard bitcoin scripting functionalities (on the blockchain) that realize smart contracts.

Note that '''A2L''' is faster and uses less bandwidth than TumbleBit.[https://eprint.iacr.org/2019/589.pdf]

==External links==
* https://eprint.iacr.org/2016/575 - The paper
* https://github.com/BUSEC/TumbleBit - Implementation
* https://joinmarket.me/blog/blog/tumblebit-for-the-tumble-curious/
* https://medium.com/@nopara73/tumblebit-vs-coinjoin-15e5a7d58e3
* https://www.youtube.com/watch?v=8BLWUUPfh2Q&t=3787 - Talk at ScalingBitcoin 2016
* https://diyhpl.us/wiki/transcripts/scalingbitcoin/milan/tumblebit/ - Transcript of talk

==References==
<references />

[[Category:Privacy]]

TumbleBit

2019-06-04T21:05:52Z

Ysangkok: replace "new" with "2016"

TumbleBit is a anonymous payments protocol from 2016 that is fully compatible with today’s Bitcoin protocol. TumbleBit allows parties to make payments through an untrusted Tumbler. No-one, not even the Tumbler, can tell which payer paid which payee during a TumbleBit epoch. TumbleBit consists of two interleaved fair-exchange protocols that prevent theft of bitcoins by cheating users or a malicious Tumbler. TumbleBit combines fast cryptographic computations (performed off the blockchain) with standard bitcoin scripting functionalities (on the blockchain) that realize smart contracts.

==External links==
* https://eprint.iacr.org/2016/575 - The paper
* https://github.com/BUSEC/TumbleBit - Implementation
* https://joinmarket.me/blog/blog/tumblebit-for-the-tumble-curious/
* https://medium.com/@nopara73/tumblebit-vs-coinjoin-15e5a7d58e3
* https://www.youtube.com/watch?v=8BLWUUPfh2Q&t=3787 - Talk at ScalingBitcoin 2016
* https://diyhpl.us/wiki/transcripts/scalingbitcoin/milan/tumblebit/ - Transcript of talk

==References==
<references />

[[Category:Privacy]]

IRC channels

2019-02-18T16:39:03Z

Ysangkok: /* Bitcoin Project */ fix link to bitcoin-wizards logs

Most of the following Bitcoin-related IRC channels are available on [http://www.freenode.net Freenode]:

Please read: [[Bitcoin IRC Channel Guidelines]] before joining.

==Bitcoin Project==
{| class="wikitable"
! Channel !! Description
|-
| {{Freenode IRC|bitcoin}} || General Bitcoin-related discussion and support. ([[Bitcoin_IRC_Channel_Guidelines | guidelines]]).
|-
| {{Freenode IRC|bitcoin-dev}} || Dead. Formerly for Bitcoin software development. ([http://bitcoinstats.com/irc/bitcoin-dev/logs/ history]. [[Bitcoin-dev | guidelines]])
|-
| {{Freenode IRC|bitcoin-commits}} || Real-time notification of commits to Bitcoin projects.
|-
| {{Freenode IRC|bitcoin-core-dev}} || For development of Bitcoin Core. Log sources; [http://www.erisian.com.au/bitcoin-core-dev/ 1], [http://gnusha.org/bitcoin-core-dev/ 2]
|-
| {{Freenode IRC|bitcoin-gaming}} || Bitcoin gamers hangout.
|-
| {{Freenode IRC|bitcoin-gentoo}} || Gentoo community.
|-
| {{Freenode IRC|bitcoin-marketing}} || Marketing and promotion of bitcoin
|-
| {{Freenode IRC|bitcoin-news}} || RSS News related to Bitcoin.
|-
| {{Freenode IRC|bitcoin-politics}} || Discuss politics with other Bitcoin users.
|-
| {{Freenode IRC|#bitcoin-pricetalk|text=#bitcoin-pricetalk}} || ALL Discussion Remotely Related to Bitcoin Price or other offtopic goes here
|-
| {{Freenode IRC|bitcoin-watch|text=[[Bitcoin-Watch|#bitcoin-watch]]}} || Streaming Bitcoin transactions, including market data.
|-
| {{Freenode IRC|bitcoin-wiki}} || Bitcoin Wiki support
|-
| {{Freenode IRC|bitcoin-wizards}} || Bitcoin experts and futurists ([http://gnusha.org/bitcoin-wizards/ history])
|-
| {{Freenode IRC|lightning-dev}} || Lightning protocol development
|-
| {{Freenode IRC|lnd}} || Lightning only version of #bitcoin-commits
|-
| {{Freenode IRC|sidechains-dev}} || Sidechains development
|}

===Local communities===

{| class="wikitable"
| {{Freenode IRC|bitcoin-otc-eu}} || European OTC trading marketplace.
|-
| {{Freenode IRC|bitcoin-otc-ru}} || Russian OTC trading marketplace.
|-
| {{Freenode IRC|bitcoin-otc-uk}} ||United kingdom OTC Trading Marketplace.Founder Angus Bates.
|-
| {{Freenode IRC|bitcoin-aus}} || Aussie bitcoin community.
|-
| {{Freenode IRC|AustinBitcoin}} || Austin, TX bitcoin community.
|-
| {{Freenode IRC|bitcoin-bra}} || Brazilian bitcoin community.
|-
| {{Freenode IRC|bitcoin-cad}} || Canadian bitcoin community.
|-
| {{Freenode IRC|bitcoin-cn}} || Chinese bitcoin community.
|-
| {{Freenode IRC|bitcoin-dk}} || Danish bitcoin community.
|-
| {{Freenode IRC|bitcoin-de}} || German bitcoin community.
|-
| {{Freenode IRC|bitcoin-eastcoastusa}} || East Coast USA bitcoin community.
|-
| {{Freenode IRC|bitcoin-il}} || Israeli bitcoin community.
|-
| {{Freenode IRC|bitcoin-nl}} || Dutch bitcoin community.
|-
| {{Freenode IRC|bitcoin-pl}} || Polish bitcoin community.
|-
| {{Freenode IRC|bitcoin-romania}} || Romanian bitcoin community.
|-
| {{Freenode IRC|bitcoin-ve}} || Venezuelan bitcoin community.
|-
| {{Freenode IRC|btc.chat}} || Russian bitcoin community.
|-
| #bitcoins.fi @ IRCNet || Finnish bitcoin community.
|-
| {{Freenode IRC|bitcoin-hr}} || Croatian language bitcoin community.

|}

==Mining Related Communities==

{| class="wikitable"
! Channel !! Description
|-
| {{Freenode IRC|avalon}} || Discussion and support specific to [[Avalon]] mining machine
|-
| {{Freenode IRC|bitcoin-mining}} || Discussion and support related to mining.
|-
| {{Freenode IRC|bitcoin-fpga}} || Discussion and support specific to FPGA mining.
|-
| {{Freenode IRC|btcguild}} || [[BTCGuild]] mining pool community
|-
| {{Freenode IRC|butterflylabs}} || [[Butterfly Labs]] chat
|-
| {{Freenode IRC|cgminer}} || Discussion and support specific to [[CGMiner]].
|-
| {{Freenode IRC|eligius}} || [[Eligius]] mining pool community (also support for [[BFGMiner]] and [[Eloipool]])
|-
| {{Freenode IRC|mining.bitcoin.cz}} || Slush's mining pool community
|-
| {{Freenode IRC|ozcoin}} || [[Ozco.in]] mining pool community
|-
| [irc://irc.foonetic.net/xkcd-bitcoin IRC] [http://irc.lc/foonetic/xkcd-bitcoin/Miner@@@ Web] #xkcd-bitcoin || [https://en.bitcoin.it/wiki/XKCD_Pool XKCD Pool]
|-
| [irc://irc.quakenet.org/bitcoins.lc IRC] [http://irc.lc/quakenet/bitcoins.lc/Miner@@@ Web] #bitcoins.lc @ Quakenet || [http://www.bitcoins.lc Bitcoins.lc Pool]
|-
| {{Freenode IRC|p2pool}} || [[P2Pool]] decentralized mining pool
|-
| {{Freenode IRC|bitminter}} || [[BitMinter]] Mining Pool Community
|-
| {{Freenode IRC|kncminer}} || [[KNCMiner]] ASIC Mining Hardware Vendor Discussion
|}

==Communities for Exchanges and Trading==

{| class="wikitable"
! Channel !! Description
|-
| {{Freenode IRC|bitcoin-assets}} || Discussion of securities and other asset investments. [http://bitcoin-assets.com bitcoin-assets.com].
|-
| {{Freenode IRC|bitcoin-assets-trades}} || Streaming assets market data (only), no chat.
|-
| {{Freenode IRC|bitcoin-auction}} || Live auctions over IRC.
|-
| {{Freenode IRC|bitcoin-market}} || Streaming market data (only), no chat.
|-
| {{Freenode IRC|bitcoin-otc|text=[[bitcoin-otc|#bitcoin-otc]]}} || Over-the-counter trading marketplace and discussion. ([http://bitcoinstats.com/irc/bitcoin-otc/logs/ history])
|-
| {{Freenode IRC|bitcoin-escrow}} || Third party escrow agents.
|-
| {{Freenode IRC|bitcoin-otc-ticker|bitcoin-otc-ticker}} || Streaming market data form the [[#bitcoin-otc]] order book.
|-
| {{Freenode IRC|bitcoin-otc-ratings|bitcoin-otc-ratings}} || Updates to ratings on the [[#bitcoin-otc]] Web of Trust.
|-
| {{Freenode IRC|bitcoin-pit}} || Only over-the-counter trading.
|-
| {{Freenode IRC|bitcoin-wot|bitcoin-wot}} || Distributed Web of Trust (WoT) system for [[#bitcoin-otc]].
|-
| {{Freenode IRC|btc.chat.traders}} || Russian community discussion about trades/exchanges.
|-
| {{Freenode IRC|coinbase}} || [[Coinbase]] chat
|-
| {{Freenode IRC|bitcoin-rt}} || Real-time tape (executed trades).
|-
| {{Freenode IRC|localbitcoins-chat}} || [[LocalBitcoins.com]] exchange support
|-
| {{Freenode IRC|Coinabul}} || [http://Coinabul.com Coinabul]'s customer support and news channel. Selling gold and silver for Bitcoin.
|}

==Related Communities==

{| class="wikitable"
! Channel !! Description
|-
| {{Freenode IRC|opentransactions}} || [[Open Transactions]] project.
|-
| {{Freenode IRC|namecoin}} || [[Namecoin]] and the [[Dot-bit]] project.
|-
| {{Freenode IRC|twister}} || [[Twister]], P2P microblogging discussion.
|-
| {{Freenode IRC|joinmarket}} || [[JoinMarket]], A [[CoinJoin]] implementation
|-
| {{Freenode IRC|darkwallet}} || [[DarkWallet]] and libbitcoin/Obelisk discussion & development channel.
|-
| {{Freenode IRC|electrum}} || [[Electrum]], lightweight bitcoin client.
|-
| {{Freenode IRC|copay}} || [[Copay]], lightweight bitcoin client.
|-
| {{Freenode IRC|bitcoin-stackexchange}} || Discussion complementing [http://bitcoin.stackexchange.com Bitcoin StackExchange].

|}

==See Also==

* [[Bitcoin_Wiki:Community_portal]]

[[fr:Canaux IRC]]
[[pl:Kanały IRC]]
[[ro:Canale]]

Softfork

2018-09-21T14:29:58Z

Ysangkok: mention CVE-2018-17144 fix in 0.16.3 (also softfork)

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.

Softforks can also be used to undo accidental hardforks. This is how [https://bitcoincore.org/en/2018/09/20/notice/ CVE-2018-17144] was fixed in Bitcoin Core 0.16.3.

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

Hardfork

2018-09-21T14:22:11Z

Ysangkok: two accidental hardforks

Payment channel

2017-06-24T14:26:43Z

Ysangkok: Redirected page to Payment channels

#REDIRECT [[Payment channels]]

Contract

2017-06-24T14:25:49Z

Ysangkok: /* Example 7: Rapidly-adjusted (micro)payments to a pre-determined party */ link payment channel and lightning network

A '''distributed contract''' is a method of using Bitcoin to form agreements with people via the block chain. Contracts don't make anything possible that was previously impossible, but rather, they allow you to solve common problems in a way that minimizes trust. Minimal trust often makes things more convenient by allowing human judgements to be taken out of the loop, thus allowing complete automation.

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

* [[Smart Property|Smart property]] is property that can be atomically traded and loaned via the block chain.
* [[Transferable virtual property]] are digital items that can be traded but not duplicated.
* [[Agents]] are autonomous programs that maintain their own wallet, which they use to buy server time. Money is obtained by the agent selling services. If demand exceeds supply the agents can spawn children that either survive or die depending on whether they can get enough business.
* [[Distributed markets]] are a way to implement peer to peer bond and stock trading, allowing Bitcoin to be evolve into a full competitor to the international financial system.

This page also lists some smaller examples.

Many of the ideas underlying Bitcoin contracts were first described by Nick Szabó in his seminal paper,
[http://szabo.best.vwh.net/formalize.html Formalizing and Securing Relationships on Public Networks]. These pages were written by [mailto:mike@plan99.net Mike Hearn]. Contact him if you have an idea for a new type of contract. You can watch '''[https://www.youtube.com/watch?feature=player_embedded&v=mD4L7xDNCmA a video of a talk on contracts]''' that was presented at the Bitcoin 2012 conference in London.

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

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

==Theory==

Every [[transaction]] in Bitcoin has one or more inputs and outputs. Each input/output has a small, pure function associated with it called a [[script]]. Scripts can contain signatures over simplified forms of the transaction itself.

Every transaction can have a lock time associated with it. This allows the transaction to be pending and replaceable until an agreed-upon future time, specified either as a block index or as a timestamp (the same field is used for both, but values less than 500 million are interpreted as a block index). If a transaction's lock time has been reached, we say it is final.

Each transaction input has a sequence number. In a normal transaction that just moves value around, the sequence numbers are all UINT_MAX and the lock time is zero. If the lock time has not yet been reached, but all the sequence numbers are UINT_MAX, the transaction is also considered final. Sequence numbers can be used to issue new versions of a transaction without invalidating other inputs signatures, e.g., in the case where each input on a transaction comes from a different party, each input may start with a sequence number of zero, and those numbers can be incremented independently.

Signature checking is flexible because the form of transaction that is signed can be controlled through the use of SIGHASH flags, which are stuck on the end of a signature. In this way, contracts can be constructed in which each party signs only a part of it, allowing other parts to be changed without their involvement. The SIGHASH flags have two parts, a mode and the ANYONECANPAY modifier:

# SIGHASH_ALL: This is the default. It indicates that everything about the transaction is signed, except for the input scripts. Signing the input scripts as well would obviously make it impossible to construct a transaction, so they are always blanked out. Note, though, that other properties of the input, like the connected output and sequence numbers, ''are'' signed; it's only the scripts that are not. Intuitively, it means "I agree to put my money in, if everyone puts their money in and the outputs are this".
# SIGHASH_NONE: The outputs are not signed and can be anything. Use this to indicate "I agree to put my money in, as long as everyone puts their money in, but I don't care what's done with the output". This mode allows others to update the transaction by changing their inputs sequence numbers.
# SIGHASH_SINGLE: Like SIGHASH_NONE, the inputs are signed, but the sequence numbers are blanked, so others can create new versions of the transaction. However, the only output that is signed is the one at the same position as the input. Use this to indicate "I agree, as long as my output is what I want; I don't care about the others".

The SIGHASH_ANYONECANPAY modifier can be combined with the above three modes. When set, only that input is signed and the other inputs can be anything.

Scripts can contain the CHECKMULTISIG opcode. This opcode provides n-of-m checking: you provide multiple public keys, and specify the number of valid signatures that must be present. The number of signatures can be less than the number of public keys. An output can require two signatures to be spent by setting it to something like this:

2 <pubkey1> <pubkey2> 2 CHECKMULTISIGVERIFY

There are two general patterns for safely creating contracts:

# Transactions are passed around outside of the P2P network, in partially-complete or invalid forms.
# Two transactions are used: one (the contract) is created and signed but not broadcast right away. Instead, the other transaction (the payment) is broadcast after the contract is agreed to lock in the money, and then the contract is broadcast.

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

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

==Example 1: Providing a deposit==

Imagine that you open an account on a website (eg, a forum or wiki) and wish to establish your trustworthiness with the operators, but you don't have any pre-existing reputation to leverage. One solution is to buy trust by paying the website some money. But if at some point you close your account, you'd probably like that money back. You may not trust the site enough to give them a deposit that they are tempted to spend. Another risk is that the site might just disappear one day.

The goal is to prove that you made a sacrifice of some kind so the site knows you're not a spambot, but you don't want them to be able to spend the money. And if the operators disappear, you'd eventually like the coins back without needing anything from them.

We can solve this problem with a contract:

# The user and website send each other a newly-generated public key.
# The user creates transaction Tx1 (the payment) putting 10 BTC into an output that requires both user and website to sign, but does not broadcast it. They use the key from the previous step for the site.
# User sends the hash of Tx1 to the website.
# The website creates a transaction Tx2 (the contract). Tx2 spends Tx1 and pays it back to the user via the address he provided in the first step. Note that Tx1 requires two signatures, so this transaction can't be complete. nLockTime is set to some date in the future (eg, six months). The sequence number on the input is set to zero.
# Finally, the incomplete (half-signed) transaction is sent back to the user. The user checks that the contract is as expected - that the coins will eventually come back to him - but, unless things are changed, only after six months. Because the sequence number is zero, the contract can be amended in future if both parties agree. The script in the input isn't finished though; there are only zeros where the user's signature should be. He fixes that by signing the contract and putting the new signature in the appropriate spot.
# The user broadcasts Tx1, then broadcasts Tx2.

At this stage, the 10 BTC are in a state where neither the user nor the website can spend them independently. After six months, the contract will complete and the user will get the coins back, even if the website disappears.

What if the user wishes to close his account early? The website creates a new version of Tx2 with nLockTime set to zero and the input sequence number set to UINT_MAX, then he re-signs it. The site hands the tx back to the user, who signs it as well. The user then broadcasts the transaction, terminating the contract early and releasing the coins.

What if the six months is nearly up and the user wishes to keep his account? The same thing applies: the contract can be resigned with a newer nLockTime, a sequence number 1 higher than the previous and rebroadcast 2^32 times. No matter what happens, both parties must agree for the contract to change.

Obviously, if the user turns out to be abusive (i.e., a spammer), the website will not allow an early close of the contract. If too much abuse is getting through, the size of the deposit can be raised or the length of the contract can be increased.

==Example 2: Escrow and dispute mediation==

A buyer wants to trade with somebody he doesn't know or trust. In the common case where the transaction goes well, the client doesn't want any third parties involved. If something goes wrong though, he'd like a third party to decide who gets the money - perhaps a professional dispute mediation service. Note that this concept can apply to either buyer or seller. The mediator might request proof of postage from the merchant, for example.

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

# Agree with the merchant on a dispute mediator (e.g., ClearCoin).
# Ask the merchant for a public key (K1). Ask the mediator for a public key (K2). Create a new key for yourself (K3).
# Send the merchant K2. The merchant challenges the mediator with a random nonce. The mediator signs the nonce with the private form of K2, thus proving it really belongs to merchant.
# Create a transaction (Tx1) with an output script as follows and broadcast it:

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

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

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

When signing an input, the contents are set to the connected output. Thus, to redeem this transaction, the client creates a scriptSig containing zeros where the other signature should be, signs it, and then sets one of the slots to his new signature. The partially-complete transaction can then be sent to the merchant or mediator for the second signature.

==Example 3: Assurance contracts==

An [http://en.wikipedia.org/wiki/Assurance_contract assurance contract] is a way of funding the creation of a [http://www.auburn.edu/~johnspm/gloss/public_goods public good], that is, a good that, once created, anyone can benefit from for free. The standard example is a lighthouse: whilst everyone may agree that one should be built, it’s too expensive for an individual sailor to justify building one, given that it will also benefit all his competitors.

One solution is for everyone to pledge money towards the creation of the public good, such that the pledges are only committed if the total value of all pledges is above the cost of creation. If not enough people contribute, nobody has to pay anything.

Examples where Bitcoin is superior to traditional payment methods for assurance contract fundraising include applications where frequent, small pledges need to be made automatically, for instance internet radio station funding and [https://bitcointalk.org/index.php?topic=67255.msg788110#msg788110 web page translation]. Consider a browser extension that you send a bit of money to. It detects the current language of the page and broadcasts a pledge for a translation into your language to be prepared. If enough users with the extension land on the same page at the same time (eg, it was linked to from somewhere high traffic), then enough pledges are broadcast to trigger a payment to a company who prepares a high quality translation. When complete it automatically loads in your browser.

We can model this in Bitcoin as follows:

# An entrepreneur creates a new address and announces that the good will be created if at least 1000 BTC is raised. Anyone can contribute.
# Each party wishing to pledge creates a new transaction spending some of their coins to the announced address, but they do not broadcast it. The transaction is similar to a regular transaction except for three differences: Firstly, there cannot be any change. If you don’t have any outputs of the right size, you must create one first by spending to one of your own addresses. Secondly, the input script signature is signed with SIGHASH_ALL | SIGHASH_ANYONECANPAY. Finally, the output value is set to 1000 BTC. Note that this is not a valid transaction because the output value is larger than the input value.
# The transaction is uploaded to the entrepreneur's server, which saves it to disk and updates its count of how many coins have been pledged.
# Once the server has enough coins, it merges the separate transactions together into a new transaction. The new transaction has a single output that simply spends to the announced address - it is the same as the outputs on each contributed transaction. The inputs to the transaction are collected from the contributed pledges.
# The finished transaction is broadcast, sending the pledged coins to the announced address.

This scheme relies on several aspects of the protocol. The first is the SIGHASH flags used. SIGHASH_ALL is the default and means the entire contents of the transaction are signed, except for the input scripts. SIGHASH_ANYONECANPAY is an additional modifier that means the signature only covers the input it’s found in - the other inputs are not signed and thus can be anything.

By combining these flags together, we are able to create a signature that is valid even when other inputs are added, but breaks if the outputs or other properties of the transaction are changed.

The second aspect we exploit is the fact that a transaction in which the output values are larger than the input values is invalid (for obvious reasons). This means it’s safe to send the entrepreneur a transaction that spends such coins - it’s impossible for him to claim the coins unless he has other inputs that sum to the output value or more.

It's possible to create assurance contracts without using SIGHASH_ANYONECANPAY. Instead, a two step process is used in which pledges are collected without transactions, and once the total value is reached, a transaction with an input for each pledger is created and passed around until all signatures are collected. However, using SIGHASH_ANYONECANPAY and then merging is probably more convenient.

An assurance contract can be prepared for '''[[Funding network security|funding network security]]''' for the next block. In this way, mining can be funded even if block space is not scarce.

An elaboration of this concept is described by Tabarrok in his paper, [http://mason.gmu.edu/~atabarro/PrivateProvision.pdf “The private provision of public goods via dominant assurance contracts”]. In a dominant assurance contract, if a contract fails (not enough pledges within a set time window) the entrepreneur pays a fee to those who pledged so far. This type of contract attempts to arrange incentives such that taking part is always the right strategy. [[Dominant Assurance Contracts|A scheme for dominant assurance contracts]] in Bitcoin has been proposed.

==Example 4: Using external state==

Scripts are, by design, pure functions. They cannot poll external servers or import any state that may change as it would allow an attacker to outrun the block chain. What's more, the scripting language is extremely limited in what it can do. Fortunately, we can make transactions connected to the world in other ways.

Consider the example of an old man who wishes to give an inheritance to his grandson, either on the grandson's 18th birthday or when the man dies, whichever comes first.

To solve this, the man first sends the amount of the inheritance to himself so there is a single output of the right amount. Then he creates a transaction with a lock time of the grandson's 18th birthday that pays the coins to another key owned by the grandson, signs it, and gives it to him - but does not broadcast it. This takes care of the 18th birthday condition. If the date passes, the grandson broadcasts the transaction and claims the coins. He could do it before then, but it doesn't let him get the coins any earlier, and some nodes may choose to drop transactions in the memory pool with lock times far in the future.

The death condition is harder. As Bitcoin nodes cannot measure arbitrary conditions, we must rely on an ''oracle''. An oracle is a server that has a keypair, and signs transactions on request when a user-provided expression evaluates to true.

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

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

This is the oracle script. It has an unusual form - it pushes data to the stack then immediately deletes it again. The pubkey is published on the oracle's website and is well-known. The hash is set to be the hash of the user-provided expression stating that he has died, written in a form the oracle knows how to evaluate. For example, it could be the hash of the string:

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

This little language is hypothetical, it'd be defined by the oracle and could be anything. The return value is an output: an amount of value and an address owned by the grandson.

Once more, the man creates this transaction but gives it directly to his grandson instead of broadcasting it. He also provides the expression that is hashed into the transaction and the name of the oracle that can unlock it.

It is used in the following algorithm:

# The oracle accepts a measurement request. The request contains the user-provided expression, a copy of the output script, and a partially complete transaction provided by the user. Everything in this transaction is finished except for the scriptSig, which contains just one signature (the grandson's) - not enough to unlock the output.
# The oracle checks the user-provided expression hashes to the value in the provided output script. If it doesn't, it returns an error.
# The oracle evaluates the expression. If the result is not the destination address of the output, it returns an error.
# Otherwise the oracle signs the transaction and returns the signature to the user. Note that when signing a Bitcoin transaction, the input script is set to the connected output script. The reason is that when OP_CHECKSIG runs, the script containing the opcode is put in the input being evaluated, _not_ the script containing the signature itself. The oracle has never seen the full output it is being asked to sign, but it doesn't have to. It knows the output script, its own public key, and the hash of the user-provided expression, which is everything it needs to check the output script and finish the transaction.
# The user accepts the new signature, inserts it into the scriptSig and broadcasts the transaction.

If, and only if, the oracle agrees that the man is dead, the grandson can broadcast the two transactions (the contract and the claim) and take the coins.

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

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

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

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

The conditions that control whether the oracle signs can be arbitrarily complex, but the block chain never needs to contain more than a single hash.

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

===Trust minimization: challenges===

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

Going back to our first example, the oracle has not seen the transaction the grandson is trying to unlock, as it was never broadcast, thus, it cannot hold the grandson to ransom because it does not know whether the transaction it's signing for even exists. People can, and should, regularly '''challenge''' the oracle in an automated fashion to ensure it always outputs what is expected. The challenges can be done without spending any coins because the tx to be signed can be invalid (ie, connected to transactions that don't exist). The oracle has no way to know whether a request to be signed is random or real. How to challenge the oracle with conditions that are not yet true is however an open research question.

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

The number of keys in the CHECKMULTISIG can be increased to allow for '''n-of-m''' oracles if need be. Of course, it is vital to check that the oracles really are independent and not in collusion. An implementation of such a system, and explanation was published in the '''[http://github.com/orisi/wiki/wiki/Orisi-White-Paper Orisi whitepaper]'''.

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

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

===Trust minimization: trusted hardware===

Using commodity hardware, you can use '''trusted computing''' in the form of Intel TXT or the AMD equivalent (SKINIT) to set up a sealed hardware environment and then use the TPM chip to attest that fact to a third party. That third party can verify the hardware was in the required state. Defeating this requires someone to be able to interfere with the execution of a program that may run entirely on the CPU, even in extreme cases without any data traversing the memory bus (you can run entirely using on-die cache if the program is small enough).

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

Finally, perhaps the most practical approach currently is to use Amazon Web Services. As of November 2013, the closest we have to a working oracle is [https://bitcointalk.org/index.php?topic=301538.0 this recipe for creating a trusted computing environment using AWS], built in support of [https://bitcointalk.org/index.php?topic=173220.0 this project for doing selective SSL logging and decryption]. The idea is that an oracle, which can be proven trustworthy using the Amazon APIs with Amazon as the root of trust, records encrypted SSL sessions to an online banking interface in such a way that later if there is a dispute about a person-to-person exchange, the logs can be decrypted and the dispute settled.

==Example 5: Trading across chains==

The Bitcoin technology can be adapted to create [[Alternative chain|multiple, independent currencies]]. NameCoin is an example of one such currency that operates under a slightly different set of rules, and can also be used to rent names in a namespace. Currencies that implement the same ideas as Bitcoin can be traded freely against each other with limited trust.

For example, imagine a consortium of companies that issue EURcoins, a crypto-currency that is backed 1:1 by deposits in the consortium's bank accounts. Such a currency would have a different set of tradeoffs to Bitcoin: more centralized, but without FX risk. People might wish to trade Bitcoins for EURcoins back and forth, with the companies only getting involved when cashing in/out of the regular banking system.

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

# Party 'A' generates some random data, x (the secret).
# Party 'A' generates Tx1 (the payment) containing an output with the chain-trade script in it. See below for this script and a discussion of it. It allows coin release either by signing with the two keys (key 'A' and key 'B') or with (secret 'x', key 'B'). This transaction is not broadcast. The chain release script contains hashes, not the actual secrets themselves.
# Party 'A' generates Tx2 (the contract), which spends Tx1 and has an output going back to key 'A'. It has a lock time in the future and the input has a sequence number of zero, so it can be replaced. 'A' signs Tx2 and sends it to 'B', who also signs it and sends it back.
# 'A' broadcasts Tx1 and Tx2. Party 'B' can now see the coins but cannot spend them because it does not have an output going to him, and the tx is not finalized anyway.
# 'B' performs the same scheme in reverse on the alternative chain. The lock time for 'B' should be much larger than the lock time for 'A'. Both sides of the trade are now pending but incomplete.
# Since 'A' knows the secret, 'A' can claim his coins immediately. However, 'A', in the process of claiming his coin, reveals the secret 'x' to 'B', who then uses it to finish the other side of the trade with ('x', key 'B').

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

The chain-trade script could look like this:

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

The contract input script looks like either:

<sig A> <sig B> 1

or

<secret x> <sig B> 0

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

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

Note that whilst EURcoins is a natural idea, there are other ways to implement peer-to-peer currency exchange (Bitcoin to fiat and vice versa), see the [[Ripple currency exchange]] article for more information.

Sergio Demian-Lerner proposed [https://bitcointalk.org/index.php?topic=91843.0 P2PTradeX], a solution requiring the validation rules for one blockchain to be effectively encoded into the validation rules for the other.

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

In example 4, we saw how to make payments conditional on the output of some arbitrary program. Those programs are very powerful and can do anything a regular program can do, like fetching web pages. The downside is that a third party is required (an oracle). Although there are techniques that can help reduce the trust needed in the oracle, none can reduce it to zero.

For a restricted class of programs, pure functions, new cryptographic techniques are starting to become available that can actually reduce the trust needed all the way to zero with no third parties. These programs cannot perform any I/O, but in many cases this restriction turns out to be unimportant or can be worked around in other ways, like by giving the program a signed/timestamped document as an input instead of having the program download it.

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

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

Bitcoin transactions are very cheap relative to traditional payment systems, but still have a cost due to the need for it to be mined and stored. There are some cases in which you want to rapidly and cheaply adjust the amount of money sent to a particular recipient without incurring the cost of a broadcast transaction.

For example, consider an untrusted internet access point, like a WiFi hotspot in a cafe you never visited before. You'd like to pay 0.001 BTC per 10 kilobytes of usage, without opening an account with the cafe. A zero-trust solution means it could be fully automatic, so you could just pre-allocate a budget on your phone's mobile wallet at the start of the month, and then your device automatically negotiates and pays for internet access on demand. The cafe also wants to allow anyone to pay them without the fear of being ripped off.

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

Another alternative is the following protocol. This protocol relies upon a '''different''' behavior of nLockTime to the original design. Starting around 2013 time-locked transactions were made non standard and no longer enter the memory pool, thus cannot be broadcast before the timelock expires. When the behaviour of nLockTime is restored to the original design from Satoshi, a variant of this protocol is required which is discussed below.

We define the client to be the party sending value, and the server to be the party receiving it. This is written from the clients perspective.

# Create a public key (K1). Request a public key from the server (K2).
# Create and sign but do not broadcast a transaction (T1) that sets up a payment of (for example) 10 BTC to an output requiring both the server's private key and one of your own to be used. A good way to do this is use OP_CHECKMULTISIG. The value to be used is chosen as an efficiency tradeoff.
# Create a refund transaction (T2) that is connected to the output of T1 which sends all the money back to yourself. It has a time lock set for some time in the future, for instance a few hours. Don't sign it, and provide the unsigned transaction to the server. By convention, the output script is "2 K1 K2 2 CHECKMULTISIG"
# The server signs T2 using its private key associated with K2 and returns the signature to the client. Note that it has not seen T1 at this point, just the hash (which is in the unsigned T2).
# The client verifies the servers signature is correct and aborts if not.
# The client signs T1 and passes the signature to the server, which now broadcasts the transaction (either party can do this if they both have connectivity). This locks in the money.
# The client then creates a new transaction, T3, which connects to T1 like the refund transaction does and has two outputs. One goes to K1 and the other goes to K2. It starts out with all value allocated to the first output (K1), ie, it does the same thing as the refund transaction but is not time locked. The client signs T3 and provides the transaction and signature to the server.
# The server verifies the output to itself is of the expected size and verifies the client's provided signature is correct.
# When the client wishes to pay the server, it adjusts its copy of T3 to allocate more value to the server's output and less to its own. It then re-signs the new T3 and sends the signature to the server. It does not have to send the whole transaction, just the signature and the amount to increment by is sufficient. The server adjusts its copy of T3 to match the new amounts, verifies the signature and continues.

This continues until the session ends, or the 1-day period is getting close to expiry. The AP then signs and broadcasts the last transaction it saw, allocating the final amount to itself. The refund transaction is needed to handle the case where the server disappears or halts at any point, leaving the allocated value in limbo. If this happens then once the time lock has expired the client can broadcast the refund transaction and get back all the money.

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

The lock time and sequence numbers avoid an attack in which the AP provides connectivity, and then the user [[double-spending|double-spends]] the output back to themselves using the first version of TX2, thus preventing the cafe from claiming the bill. If the user does try this, the TX won't be included right away, giving the access point a window of time in which it can observe the TX broadcast, and then broadcast the last version it saw, overriding the user's attempted double-spend.

The latter protocol that relies on transaction replacement is more flexible because it allows the value allocated to go down as well as up during the lifetime of the channel as long as the client receives signatures from the server, but for many use cases this functionality is not required. Replacement also allows for more complex configurations of channels that involve more than two parties. Elaboration on such use cases is a left as an exercise for the reader.

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

Using some of the techniques from example 6 and some very advanced scripting, it becomes possible to build a multi-party lottery with no operator. The exact protocol used is explained in the paper [http://eprint.iacr.org/2013/784 "Secure multiparty computations on Bitcoin"]. A shorter explanation of how it works may be added to this wiki at some point in the future.

==See Also==

* [[Script]]
* [[Binary options]]
* [[Oracle]]

[[Category:Technical]]

Nanopayments

2017-06-24T11:24:00Z

Ysangkok: link tadge dryja talk

''a.k.a. Micropayments''

Nanopayments are tiny payments for a trivial service. For example, 0.0001 BTC for each of three Tor nodes to relay one megabyte of traffic with premium priority.

It should be easy to see that a series of payments like this would be "spam" to Bitcoin, and infeasible due to transaction fees, and unwelcome to everyone who must download and store the whole block chain.

The idea, in a nutshell, is for Alice to make a 0.0001 BTC nanopayment to Bob by signing a message not worth 0.0001 BTC, but by signing a message that has 1 in 10000 probability of being worth 1 BTC, and sending it to Bob directly. This message would function much like a share in a mining pool. Out of 10000 nanopayments, on average, 9999 will be worthless and 1 will not.

For it to work fairly, Alice must not have any way to know which share is actually redeemable to the recipient.

Of course, due to variance, Alice will sometimes get her services for free, and sometimes she will vastly overpay. However, if she consumes such services regularly, the amount she pays will tend toward the amount she consumes.

=====Technical stuff: How can probabilistic transactions be created?=====

Bob creates a secret transaction that will be used for a "guess my hash" challenge. The value can be the minimum and will be sent back by Alice's transaction. He doesn't broadcast it yet.

Alice will create a multi-input transaction that spends her own coin AND Bob's secret transaction. Here's where the random chance comes in. We're going to randomize the prevout identifying Bob's transaction. Multi-input transactions are not valid unless all their inputs exist, so if Bob's transaction is misidentified, the whole transaction is void.

For the hash identifying the secret transaction, Bob only gives Alice a numeric range that the hash is in. If the hash is H, and we want a 1/N chance of the nanopayment being real, then Bob would take H1=H-rand(N) and tell Alice the hash is between H1 and H1+N.

Alice chooses H2 in the range H1 to H1+N and creates the transaction. Input 1 is her coin, and input 2 uses H2 as the prevout hash that may or may not match Bob's secret transaction. She signs input 1 and gives the transaction to Bob. Note that signing one input locks in the prevouts of all inputs, so Bob can't change H2.

Bob now checks if the H2 she used equals H. If it is, he signs input 2 and broadcasts both his secret transaction and Alice's transaction.

If H2 is not H, then the transaction can never be valid, because there can be no previous transaction that hashes to H2. Since the transaction is invalid, not just unspendable, Bob can't be a jerk and submit it to the network just to waste Alice's coin.

''What if Alice tries to [[double-spending|double spend]] her 1 BTC out from under Bob before he gets his successful transaction into the block chain?''

If Alice tries to double spend on nanopayments, she'll spend more on transaction fees than she saves.

She would need to selectively double spend the real ones, but she doesn't know if the transaction she gave Bob was real. All she can do is wait and watch if Bob broadcasts it, but by then his transaction will already [https://bitcointalk.org/index.php?topic=423.msg3819#msg3819 have a big head start]. If Bob is really paranoid, he could connect directly to the pool miners and broadcast only to them first to get most of the mining power sewed up before Alice would even know.

''What if Alice uses that same 1 BTC to buy services from somebody else, who won't know she is pledging shares of that same coin in more than one place, where somebody would be shortchanged if both services won the same bitcoin at around the same time?''

This may not be a big enough problem to matter for most casual, low value uses.

If need be, this could be solved with hub servers that nanopayment recipients would use to announce coins currently in use to other nanopayment recipients.

When Alice sends her nanopayment transaction to Bob, she would need to use her coin's EC-DSA key to sign a reserve message containing the current time, her coin's hash, and the address she's paying to. Bob sends this message to the hub server to reserve her coin for some predetermined period like 1 minute.

A hub server would be pretty simple, just a single lookup table. A merchant sends it a reserve message. The server checks that the signature matches the coin. If a reserve is already in effect for that coin, it returns an error, otherwise OK. It adds the reservation to its lookup table and purges it when it expires. Merchants could connect to several hub servers to keep them honest and for redundancy. It would be fitting to pay the hub servers with nanopayments.

This article is derived from [https://bitcointalk.org/index.php?topic=62558 Sustainable nanopayment idea: Probabilistic Payments] by casascius.

The [https://github.com/paulkernfeld/bitcoin-nanopayment bitcoin-nanopayment] project is a relatively unproven implementation of this using Node.js.

[[Tadge Dryja]] (of [[Lightning Network]] fame) talked about probabilistic payments in April 2016: [https://www.youtube.com/watch?v=-lgYYz3y_hY&t=13m43s]

Segregated Witness

2017-06-24T10:10:16Z

Ysangkok: /* See Also */ link dev guide

{{stub}}

'''Segregated Witness''' (aka "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 not required to determine transaction effects. In particular, scripts and signatures are moved into this new structure.

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

Mike Hearn

2017-06-24T08:23:47Z

Ysangkok: he quit

'''Mike Hearn''' is a former Google engineer, the original author of [[Bitcoinj]] and a former contributor to [[Bitcoin Core]]. He quit Bitcoin in January 2016. One reason given was rising fees. See [https://blog.plan99.net/the-resolution-of-the-bitcoin-experiment-dabb30201f7#.5jvqjf9lg Mike Hearn's blog: The resolution of the Bitcoin experiment].

== See also ==
* [[User:Mike]] on this wiki
* https://github.com/mikehearn
* https://plus.google.com/+MikeHearn

Miner fees

2016-11-22T15:27:24Z

Ysangkok: /* Fee Plotting Sites */ remove site, make list

'''Transaction fees''' may be included with any transfer of bitcoins from one address to another.

==Background==

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

The transaction fee is processed by and received by the bitcoin miner. When a new bitcoin block is generated with a successful hash, the information for all of the transactions is included with the block and all transaction fees are collected by that user creating the block, who is free to assign those fees to himself.

Transaction fees are voluntary on the part of the person making the bitcoin transaction, as the person attempting to make a transaction can include any fee or none at all in the transaction. On the other hand, nobody mining new bitcoins necessarily needs to accept the transactions and include them in the new block being created. The transaction fee is therefore an incentive on the part of the bitcoin user to make sure that a particular transaction will get included into the next block which is generated.

It is envisioned that over time the cumulative effect of collecting transaction fees will allow somebody creating new blocks to "earn" more bitcoins than will be mined from new bitcoins created by the new block itself. This is also an incentive to keep trying to create new blocks even if the value of the newly created block from the mining activity is zero in the far future.

Traditionally, the sender pays the full Bitcoin network fee; deducting the fee from the amount received by the recipient will often be considered an incomplete payment.

==Reference Implementation==

The following sections describe the behavior of the [[Original Bitcoin client|reference implementation]] as of version 0.12.0. Earlier versions treated fees differently, as do other popular implementations (including possible later versions).

===Sending===

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

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

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

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

Note that a typical transaction is 500 bytes.

===Including in Blocks===

This section describes how the reference implementation selects which transactions to put into new blocks, with default settings. All of the settings may be changed if a miner wants to create larger or smaller blocks containing more or fewer free transactions.

Then transactions that pay a fee of at least 0.00001 BTC/kb are added to the block, highest-fee-per-kilobyte transactions first, until the block is not more than 750,000 bytes big.

The remaining transactions remain in the miner's "memory pool", and may be included in later blocks if their priority or fee is large enough.

For Bitcoin Core 0.12.0 zero bytes<ref>https://github.com/bitcoin/bitcoin/blob/v0.12.0/doc/release-notes.md#relay-and-mining-priority-transactions</ref> in the block are set aside for the highest-[[Transaction_fees#Priority_transactions|priority transactions]]. Transactions are added highest-priority-first to this section of the block.

===Relaying===

The reference implementation's rules for relaying transactions across the peer-to-peer network are very similar to the rules for sending transactions, as a value of 0.00001 BTC is used to determine whether or not a transaction is considered "Free". However, the rule that all outputs must be 0.01 BTC or larger does not apply. To prevent "penny-flooding" denial-of-service attacks on the network, the reference implementation caps the number of free transactions it will relay to other nodes to (by default) 15 thousand bytes per minute.

===Settings===

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

==Fee Plotting Sites==

As of May 2016, the following sites seem to plot the required fee, in satoshi per (kilo)byte, required to get a transaction mined in a certain number of blocks.

* https://bitcoinfees.21.co/
* https://statoshi.info/dashboard/db/fee-estimates
* http://p2sh.info/dashboard/db/fee-estimation
* https://www.bitcoinqueue.com/2d.html

==Priority transactions==

Historically it was not required to include a fee for every transaction. A large portion of miners would mine transactions with no fee given that they had enough "priority". Today, low priority is mostly used as an indicator for spam transactions and almost all miners expect every transaction to include a fee.

Transaction priority is calculated as a value-weighted sum of input age, divided by transaction size in bytes:
priority = sum(input_value_in_base_units * input_age)/size_in_bytes
Transactions need to have a priority above 57,600,000 to avoid the enforced limit (as of client version 0.3.21). This threshold is written in the code as COIN * 144 / 250, suggesting that the threshold represents a one day old, 1 btc coin (144 is the expected number of blocks per day) and a transaction size of 250 bytes.

So, for example, a transaction that has 2 inputs, one of 5 btc with 10 confirmations, and one of 2 btc with 3 confirmations, and has a size of 500bytes, will have a priority of
(500000000 * 10 + 200000000 * 3) / 500 = 11,200,000

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

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

==See Also==

* [[Free transaction relay policy]]
* [http://bitcoinexchangerate.org/fees Unconfirmed transactions fee chart]

==References==
<references />

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

{{Bitcoin Core documentation}}

Block size limit controversy

2016-02-14T12:46:41Z

Ysangkok: /* Entities positions */ fix adam back link

{{current}}{{see also|Scalability FAQ}}
[[Block]]s are limited to 1MB in size. Miners can mine blocks up to the 1MB fixed limit, but any block larger than 1MB is invalid. This limit cannot be modified without a hard fork. 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>.

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

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

Data directory

2015-08-23T03:54:51Z

Ysangkok: /* Files */ fee_estimates.dat

The data directory is the location where Bitcoin's data files are stored, including the [[Wallet|wallet]] data file.

==Default Location==
=== Windows ===

Go to Start -> Run (or press WinKey+R) and run this:

%APPDATA%\Bitcoin

Bitcoin's data folder will open. For most users, this is the following locations:

C:\Documents and Settings\YourUserName\Application data\Bitcoin (XP)

C:\Users\YourUserName\Appdata\Roaming\Bitcoin (Vista and 7)

"AppData" and "Application data" are hidden by default.

You can also store Bitcoin data files in any other drive or folder.

If you have already downloaded the data then you will have to move the data to the new folder.
If you want to store them in D:\BitcoinData then click on "Properties" of a shortcut to bitcoin-qt.exe and
add -datadir=D:\BitcoinData at the end as an example:

"C:\Program Files (x86)\Bitcoin\bitcoin-qt.exe" -datadir=d:\BitcoinData

Start Bitcoin, now you will see all the files are created in the new data directory.

=== Linux ===

By default Bitcoin will put its data here:

~/.bitcoin/

You need to do a "ls -a" to see directories that start with a dot.

If that's not it, you can do a search like this:

find / -name wallet.dat -print 2>/dev/null

=== Mac ===

By default Bitcoin will put its data here:

~/Library/Application Support/Bitcoin/

==Directory Contents==

===Files===
* .lock
**BDB lock file
* bitcoin.conf [optional]
**Contains [[Running_Bitcoin#Bitcoin.conf_Configuration_File|configuration options]].
* blk''xxxx''.dat [Versions prior to v0.8.0]
**Contains concatenated raw blocks. Stored are actual Bitcoin blocks, in network format, dumped to disk raw.
* blkindex.dat [Versions prior to v0.8.0]
**Indexing information used with blk''xxxx''.dat
* __db.''xxx''
**Used by BDB
* db.log
* debug.log
**Bitcoin's verbose log file. Automatically trimmed from time to time.
* wallet.dat
**Storage for keys, transactions, metadata, and options. Please be sure to make backups of this file. It contains the keys necessary for spending your bitcoins.
* addr.dat [Versions prior to v0.7.0]
** Storage for ip addresses to make a reconnect easier
* peers.dat [Versions v0.7.0 and later]
** Storage for peer information to make a reconnect easier. This file uses a bitcoin-specific file format, unrelated to any database system<ref>[http://bitcointalk.org/index.php?topic=119525.msg1287284#msg1287284 Ultraprune merged in mainline]</ref>.
* fee_estimates.dat [Versions v0.10.0 and later]
** Statistics used to estimate fees and priorities. Saved just before program shutdown, and read in at startup.
The data, index and log files are used by Oracle [http://en.wikipedia.org/wiki/Berkeley_DB Berkeley DB], the embedded key/value data store that Bitcoin uses.

===database subdirectory===
Contains BDB journaling files

===testnet3 subdirectory===
Contains testnet versions of these files (if running with -testnet)

===blocks subdirectory===
[v0.8 and above] Contains blockchain data.

* blk*.dat
** Stored are actual Bitcoin blocks, in network format, dumped to disk raw. They are only needed for re-scanning missing transactions in a wallet, reorganizing to a different part of the chain, and serving the block data to other nodes that are synchronizing.

* blocks/index subdirectory
** [v0.8 and above] A LevelDB database that contains metadata about all known blocks, and where to find them on disk. Without this, finding a block would be very slow.

===chainstate subdirectory===
[v0.8 and above] A LevelDB database with a compact representation of all currently unspent transaction outputs and some metadata about the transactions they are from. The data here is necessary for validating new incoming blocks and transactions. It can theoretically be rebuilt from the block data (see the -reindex command line option), but this takes a rather long time. Without it, you could still theoretically do validation indeed, but it would mean a full scan through the blocks (7 GB as of may 2013) for every output being spent.

===locks subdirectory===
[v0.8 and above] Contains "undo" data.

* rev*.dat
You can see blocks as 'patches' to the chain state (they consume some unspent outputs, and produce new ones), and see the undo data as reverse patches. They are necessary for rolling back the chainstate, which is necessary in case of reorganizations.

===Bootstrapping the blockchain from a snapshot distributed through BitTorrent===
There is a [https://bitcoin.org/bin/block-chain/ torrent file that gets updated] every few months that enables a much faster download of the blockchain. Once downloaded, the bootstrap.dat file can be placed in the root of the data directory, and Bitcoin Core 0.7.1 and above will automatically import it. '''NOTE:''' As of Bitcoin Core version 0.10.0 and later, the blockchain bootstrap
torrent is ''slower'' than a direct download using the bitcoin P2P protocol & client.<ref>[https://bitcoin.org/bin/block-chain/README.txt README.txt for bootstrap.dat.torrent]</ref>

===Personally identifiable data [v0.8 and above]===
This section may be of use to you if you wish to send a friend the blockchain, avoiding them a hefty download.

*wallet.dat
**Contains addresses and transactions linked to them. Please be sure to make backups of this file. It contains the keys necessary for spending your bitcoins. You should not transfer this file to any third party or they may be able to access your bitcoins.
*db.log
**May contain information pertaining to your wallet. It may be safely deleted.
*debug.log
**May contain IP addresses and transaction ID's. It may be safely deleted.
*database/ folder
**This should only exist when bitcoin-qt is currently running. It contains information (BDB state) relating to your wallet.
*peers.dat
**Unknown whether this contains personally identifiable data. It may be safely deleted.

Other files and folders (blocks, blocks/index, chainstate) may be safely transferred/archived as they contain information pertaining only to the public blockchain.

==See Also==

* [[Running Bitcoin]]
* [[Securing your wallet]]
* [http://bitcoin.stackexchange.com/a/11108/153 What is the database for?] Question on Bitcoin Stack Exchange

==References==
<references />

[[Category:Technical]]

[[es:Directorio de datos]]

{{Bitcoin Core documentation}}

Block size limit controversy

2015-08-21T18:39:57Z

Ysangkok: /* Arguments in opposition to increasing the blocksize */ insert link to Peter R's A Transaction Fee Market Exists Without a Block Size Limit

{{current}}{{see also|Scalability FAQ}}
[[Block]]s are limited to 1MB in size. Miners can mine blocks up to the 1MB fixed limit, but any block larger than 1MB is invalid. This limit cannot be modified without a hard fork. 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.

== Unclear Arguments ==
* 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

== 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.
* A low blocksize limit encourages higher transactions fees to incentivize miners ("let a fee market develop"). Counter-argument: [https://dl.dropboxusercontent.com/u/43331625/feemarket.pdf A Transaction Fee Market Exists Without a Block Size Limit]

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

== 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
|-
| 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>
|
|-
| 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>
|-
| [[Dr. Adam Back (individual)|Dr. 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>
|
|}
[[Category:2015 events]]