https://en.bitcoin.it/w/api.php?action=feedcontributions&user=Sgornick&feedformat=atomBitcoin Wiki - User contributions [en]2019-05-25T13:43:07ZUser contributionsMediaWiki 1.30.0https://en.bitcoin.it/w/index.php?title=Clients&diff=66474Clients2019-05-21T00:46:40Z<p>Sgornick: /* See Also */ Remove Bitcoin Ladder entry as no such article exists, entry added by user flix in Jan, 2013.</p>
<hr />
<div>==Overview==<br />
A bitcoin client is the end-user software that facilitates [[private key]] generation and security, payment sending on behalf of a private key, and optionally provides:<br />
* Useful information about the state of the network and transactions.<br />
* Information related to the private keys under its management.<br />
* Syndication of network events to other peer clients.<br />
<br />
This table compares the features of the different clients. All of the listed clients are open-source.<br />
<br />
===Feature key===<br />
<br />
; Wallet Security : How well the client protects your [[private key]]s from people with access to the machine the wallet is stored on. The private keys can be encrypted, for example. The private keys can also be either stored on your device or on a remote server.<br />
; Network Security : Clients which more fully implement the Bitcoin network protocol are safer -- they can't be as easily tricked by powerful attackers. A client which ''fully'' implements the protocol will always use the correct [[block chain]] and will never allow [[double-spending|double-spends]] or invalid transactions to exist in the block chain under any circumstances. Clients which only ''partially'' implement the protocol typically trust that 50% or more of the network's mining power is honest. Some clients trust one or more ''remote servers'' to protect them from double-spends and other network attacks.<br />
; Setup Time : Some clients require that you download and verify a large amount of data before you can send or receive BTC.<br />
; Maturity : When the project was started.<br />
<br />
===Table===<br />
<br />
&lt;!-- please keep this alphabetic --&gt;<br />
{| class='wikitable' style='text-align: center'<br />
! Client !! Get Started !! Audience !! Wallet Security !! Network Security !! Backups !! Setup Time !! Disk Space !! Maturity !! Multi-user !! Available for<br />
|-<br />
! [[Airbitz]]<br />
|| [https://airbitz.co/app Download] || {{CLBest|Everyone}} || {{CLGood|Encrypted, on-device. Server backup}} || Partial || {{CLGood|Automatic}} || {{CLBest|Instant}} || {{CLGood|20 MB}} || Oct 2014 || {{CLBest|Multi-wallet}} || {{CLAndroid}}{{CLiOS}}<br />
|-<br />
! [[Armory]]<br />
|| [https://bitcoinarmory.com/download Download] || Power users || {{CLGood|Encrypted, on-device}} || Addon || {{CLBest|One-time}} || {{CLBad|Hours}} || {{CLBad|150+ GB}} || {{CLGood|Jul 2011}} || {{CLBest|Multi-wallet}} || {{CLLinux}}{{CLMac}}{{CLWin}}<br />
|-<br />
! [[Bitcoin Core]]<br />
|| [https://bitcoin.org/en/download Download] || {{CLGood|End-users}} || {{CLGood|Encrypted, on-device}} || {{CLBest|Full}} || Manual || {{CLBad|Hours}} || {{CLBad|120+ GB}} || {{CLGood|May 2011}} || {{CLBad|No}} || {{CLLinux}}{{CLMac}}{{CLWin}}<br />
|-<br />
! [[Bitcoin Knots]]<br />
|| [http://bitcoinknots.org/ Download] || {{CLGood|End-users}} || {{CLGood|Encrypted, on-device}} || {{CLBest|Full}} || Manual || {{CLBad|Hours}} || {{CLYellow|5 GB}} || {{CLGood|Dec 2011}} || {{CLBest|Multi-wallet}} || {{CLLinux}}{{CLMac}}{{CLWin}}<br />
|-<br />
! [[bitcoind]]<br />
|| [https://bitcoin.org/en/download Download] || Programmers || {{CLGood|Encrypted, on-device}} || {{CLBest|Full}} || Manual || {{CLBad|Hours}} || {{CLBad|120+ GB}} || {{CLBest|Aug 2009}} || {{CLBad|No}} || {{CLLinux}}{{CLWin}}<br />
|-<br />
! [[Bitcoin_Explorer|Bitcoin Explorer]]<br />
|| [https://github.com/libbitcoin/libbitcoin-explorer/wiki/Download-BX Download] || Power Users || {{CLBest|Ephemeral, Multisig Optional}} || {{CLBest|Full w/local node}} || {{CLBest|BIP39}} || {{CLBest|Instant}} || {{CLBest|3 MB}} || {{CLGood|May 2011}} || {{CLBest|Multi-wallet}} || {{CLLinux}}{{CLMac}}{{CLWin}}<br />
|-<br />
! [[Libbitcoin_Explorer|libbitcoin-explorer]]<br />
|| [https://github.com/libbitcoin/libbitcoin-explorer/wiki/Build-BX Build It Yourself] || Programmers || {{CLBest|Ephemeral, Multisig Optional}} || {{CLBest|Full w/local node}} || {{CLBest|BIP39}}|| {{CLBest|Instant}} || {{CLBest|3 MB}} || {{CLGood|May 2011}} || {{CLBest|Multi-wallet}} || {{CLAndroid}}{{CLLinux}}{{CLMac}}{{CLWin}}<br />
|-<br />
! [[Bitcoin Wallet]]<br />
|| [https://play.google.com/store/apps/details?id=de.schildbach.wallet Google Play] [https://appworld.blackberry.com/webstore/content/23952882/ BlackBerry World] || {{CLGood|End-users}} || {{CLGood|Isolated, on-device}} || Partial || Manual || {{CLBest|Instant}} || {{CLGood|15 MB}} || {{CLGood|Mar 2011}} || on JB tablets || {{CLAndroid}} [[file:ico-blackberry.png]]<br />
|-<br />
! [[Blocktrail]]<br />
|| [https://www.blocktrail.com/ Download] || {{CLBest|Everyone}} || {{CLBest|Encrypted, on-device, Multisig, HD, Backup server}} || Remote || {{CLBest|One-time}} || {{CLBest|Instant}} || {{CLBest|7.5 MB}} || Sep 2015 || {{CLBad|No}} || {{CLAndroid}}{{CLiOS}}<br />
|-<br />
! [[Electrum]]<br />
|| [https://electrum.org/download.html Download] || Power users || {{CLGood|Encrypted, on-device}} || Minimal || {{CLBest|Memorized}} || {{CLGood|Minutes}} || {{CLGood|5 MB}} || {{CLGood|Nov 2011}} || {{CLBad|No}} || {{CLAndroid}}{{CLLinux}}{{CLMac}}{{CLWin}}<br />
|-<br />
! [[Gocoin]]<br />
|| [https://github.com/piotrnar/gocoin Build It Yourself] || Power users || Designated offline PC || {{CLBest|Full}} || {{CLBest|Memorized}} || {{CLBad|Hours}} || {{CLBad|120+GB}} || May 2013 || {{CLBest|Multi-wallet}} || {{CLLinux}}{{CLMac}}{{CLWin}}{{CLFreeBSD}}<br />
|-<br />
! [[GreenAddress]]<br />
|| [https://greenaddress.it Web] [https://chrome.google.com/webstore/detail/greenaddressit/dgbimgjoijjemhdamicmljbncacfndmp ChromeApp] [https://play.google.com/store/apps/details?id=it.greenaddress.cordova&amp;hl=en Google Play] || {{CLBest|Everyone}} || {{CLGood|Encrypted, on-device}} || {{CLBad|Remote}} || Memorized/Manual || {{CLBest|Instant}} || {{CLBest|None}} || Apr 2013 || {{CLBest|Yes}} || {{CLAndroid}}{{CLLinux}}{{CLMac}}{{CLWin}}<br />
|-<br />
! [[MultiBit]]<br />
|| [https://multibit.org/releases.html Download] || {{CLGood|End-users}} || {{CLGood|Encrypted, on-device}} || Partial || {{CLGood|Automatic (local)}} || {{CLBest|Seconds}} || 50 MB || {{CLGood|Jul 2011}} || {{CLBest|Multi-wallet}} || {{CLLinux}}{{CLMac}}{{CLWin}}<br />
|-<br />
! [[Mycelium]]<br />
|| [https://mycelium.com/download Download] [https://play.google.com/store/apps/details?id=com.mycelium.wallet Google Play]|| {{CLBest|Everyone}} || {{CLGood|Isolated, on-device}} || Partial || Manual, encrypted || {{CLBest|Instant}} || {{CLGood|10 MB}} || Sep 2013 || {{CLBad|No}} || {{CLAndroid}}{{CLiOS}}<br />
|-<br />
! [[BlockChain.info#Wallet|My Wallet]]<br />
|| [https://blockchain.info/wallet/new Web-based] || {{CLBest|Everyone}} || {{CLBad|Encrypted, on-server}} || {{CLBad|Remote}} || {{CLGood|Automatic}} || {{CLGood|Minutes}} || {{CLBest|None}} || {{CLGood|Dec 2011}} || {{CLBest|Yes}} || {{CLAndroid}}{{CLiOS}}{{CLLinux}}{{CLMac}}{{CLWin}}<br />
|}<br />
<br />
&lt;!-- For Wallet Security: CLBest is reserved for multisig-based, if signatures can be managed independently. --&gt;<br />
<br />
==For developers==<br />
<br />
This table shows additional information about various Bitcoin clients that may be relevant to developers.<br />
<br />
{| class='wikitable' style='text-align: center'<br />
! Client !! Website !! Source Code !! License !! Discussion !! Architecture<br />
|-<br />
! Armory<br />
|| [http://bitcoinarmory.com/ Link] ||[https://github.com/etotheipi/BitcoinArmory/ Github] || AGPLv3 || [https://bitcointalk.org/index.php?board=97.0 Bitcointalk] || Integrated with [[Thin_Client_Security#Full_Node_Clients|Full Node]]<br />
|-<br />
! Bitcoin Core (Satoshi)<br />
|| [https://bitcoincore.org Link] || [https://github.com/bitcoin/bitcoin Github] || MIT || [https://lists.sourceforge.net/lists/listinfo/bitcoin-development Sourceforge] || Integrated with [[Thin_Client_Security#Full_Node_Clients|Full Node]]<br />
|-<br />
! libbitcoin-explorer<br />
|| [https://github.com/libbitcoin/libbitcoin-explorer/wiki Link] || [https://github.com/libbitcoin/libbitcoin-explorer Github] || AGPLv3 || [https://lists.dyne.org/lurker/list/libbitcoin.en.html Listserv], [https://bitcointalk.org/index.php?topic=30646.0 Bitcointalk] || [[Thin Client Security#Server-Trusting Clients|Server-Client]] or Integrated with [[Thin_Client_Security#Full_Node_Clients|Full Node]]<br />
|-<br />
! Bitcoin Wallet<br />
|| [http://wallet.schildbach.de Link] || [https://github.com/bitcoin-wallet/bitcoin-wallet Github] || GPLv3 || [https://plus.google.com/b/101256420499771441772/communities/105515929887248493912 Google+], [https://bitcointalk.org/index.php?board=100.0 Bitcointalk] || [[Thin Client Security#Simplified Payment Verification (SPV)|SPV]]<br />
|-<br />
! Electrum<br />
|| [https://electrum.org/ Link] || [https://github.com/spesmilo/electrum Github] || MIT || [https://electrum.org/#community Community] || [[Thin Client Security#Simplified Payment Verification (SPV)|SPV]]<br />
|-<br />
! Gocoin<br />
|| [http://www.assets-otc.com/gocoin Link] || [https://github.com/piotrnar/gocoin Github] || proprietary || [https://bitcointalk.org/index.php?topic=199306.0 Bitcointalk] || Integrated with [[Thin_Client_Security#Full_Node_Clients|Full Node]]<br />
|- <br />
! GreenAddress<br />
|| [https://greenaddress.it/ Link] || [https://github.com/greenaddress/ Github] || LGPLv3 || [https://bitcointalk.org/index.php?topic=521988.0 Bitcointalk] || [[Thin Client Security#Server-Trusting Clients|Server-Client]]<br />
|-<br />
! MultiBit<br />
|| [http://multibit.org/ Link] || [https://github.com/jim618/multibit Github] || MIT || [https://groups.google.com/forum/?fromgroups#!forum/bitcoin-multibit Google Groups] || [[Thin Client Security#Simplified Payment Verification (SPV)|SPV]]<br />
|-<br />
! My Wallet<br />
|| [https://blockchain.info/wallet/ Link] || [https://github.com/blockchain/My-Wallet/ Github] || BSD* || None || [[Thin Client Security#Server-Trusting Clients|Server-Client]]<br />
|-<br />
! bits of proof<br />
|| [http://bitsofproof.com Link] || [https://github.com/bitsofproof/supernode Github] || Apache 2.0 || [https://bitcointalk.org/index.php?topic=122013.0 Bitcointalk] || [[Thin Client Security#Server-Trusting Clients|Server-Client]]<br />
|-<br />
! btcd<br />
|| [https://github.com/btcsuite/btcd Link] || [https://github.com/btcsuite/btcd Github] || ISC || [https://github.com/btcsuite/btcd#irc IRC] || [[Thin Client Security#Server-Trusting Clients|Server-Client]]<br />
|}<br />
<br />
==See Also==<br />
* [[Software#Bitcoin_clients|List of clients]]<br />
<br />
&lt;references/&gt;<br />
<br />
[[Category:Software]]</div>Sgornickhttps://en.bitcoin.it/w/index.php?title=Seed_phrase&diff=66473Seed phrase2019-05-18T17:45:22Z<p>Sgornick: /* See Also */ Add entry for external FAQ regarding bitcoin seeds</p>
<hr />
<div>A '''seed phrase''', '''seed recovery phrase''' or '''backup seed phrase''' is a list of words which [[Storing bitcoins|store]] all the information needed to recover a Bitcoin wallet. Wallet software will typically generate a seed phrase and instruct the user to write it down on paper. If the user's computer breaks or their hard drive becomes corrupted, they can download the same wallet software again and use the paper backup to get their bitcoins back.<br />
<br />
Anybody else who discovers the phrase can steal the bitcoins, so it must be kept safe like jewels or cash. For example, it must not be typed into any website.<br />
<br />
Seed phrases are an excellent way of backing up and [[storing bitcoins]] and so they are used by almost all well-regarded wallets.&lt;ref&gt;[https://bitcoin.org/en/choose-your-wallet Bitcoin.org: Choose your wallet]&lt;/ref&gt;<br />
<br />
== Example ==<br />
<br />
An example of a seed phrase is:<br />
<br />
witch collapse practice feed shame open despair creek road again ice least<br />
<br />
The word order is important.<br />
<br />
[[File:Mnemonic-seed-still-life.jpg|300px|thumb|none|alt=An example seed phrase written on paper|Example seed phrase on paper.]]<br />
<br />
== Explanation ==<br />
<br />
A simplified explanation of how seed phrases work is that the wallet software has a list of words taken from a dictionary, with each word assigned to a number. The seed phrase can be converted to a number which is used as the seed integer to a [[Deterministic wallet|deterministic wallet]] that generates all the [[Private key|key pairs]] used in the wallet.<br />
<br />
The English-language wordlist for the BIP39 standard has 2048 words, so if the phrase contained only 12 random words, the number of possible combinations would be 2048^12 = 2^132 and the phrase would have 132 bits of security. However, some of the data in a BIP39 phrase is not random,&lt;ref&gt;[https://github.com/bitcoin/bips/blob/master/bip-0039.mediawiki#Generating_the_mnemonic BIP39: Generating the mnemonic]&lt;/ref&gt; so the actual security of a 12-word BIP39 seed phrase is only 128 bits. This is approximately the same strength as all Bitcoin private keys, so most experts consider it to be sufficiently secure.&lt;ref&gt;[https://github.com/bitcoin/bips/blob/master/bip-0032.mediawiki#Security BIP32: Security]&lt;/ref&gt;<br />
<br />
It is not safe to invent your own seed phrase because humans are bad at generating randomness. The best way is to allow the wallet software to generate a phrase which you write down.<br />
<br />
== Two-Factor Seed Phrases ==<br />
<br />
Seed phrases, like all backups, can store any amount of bitcoins. It's a concerning idea to possibly have enough money to purchase the entire building just sitting on a sheet of paper without any protection. For this reason many wallets make it possible to encrypt a seed phrase with a password.<br />
<br />
The password can be used to create a two-factor seed phrase where both ''&quot;something you have&quot;'' plus ''&quot;something you know&quot;'' is required to unlock the bitcoins.<br />
<br />
This works by the wallet creating a seed phrase and asking the user for a password. Then both the seed phrase and extra word are required to recover the wallet. Electrum and some other wallets call the passphrase a '''&quot;seed extension&quot;''', '''&quot;extension word&quot;''' or '''&quot;13th/25th word&quot;'''. The BIP39 standard defines a way of passphrase-protecting a seed phrase. A similar scheme is also used in the Electrum standard. If a passphrase is not present, an empty string &quot;&quot; is used instead.<br />
<br />
'''Warning''': Forgetting this password will result in the bitcoin wallet and any contained money being lost. Do not overestimate your ability to remember passphrases especially when you may not use it very often.<br />
<br />
'''Warning''': The seed phrase password should not be confused with the password used to encrypt the wallet file on disk. This is probably why many wallets call it an extension word instead of a password.<br />
<br />
== Storing Seed Phrases for the Long Term == <br />
<br />
Most people write down phrases on paper but they can be stored in many other ways such as [[Brainwallet|memorizing]], engraving on metal, writing in the margins of a book, chiseling into a stone tablet or any other creative and inventive way.<br />
<br />
For storing on paper writing with pencil is much better than pen&lt;ref&gt;[https://www.quora.com/How-do-I-maintain-a-paper-notebook-that-can-remain-for-years How do I maintain a paper notebook that can remain for years?]&lt;/ref&gt;. Paper should be acid-free or archival paper, and stored in the dark avoiding extremes of heat and moisture&lt;ref&gt;[https://www.loc.gov/preservation/care/deterioratebrochure.html Essential facts about preservation of Paper]&lt;/ref&gt;&lt;ref&gt;[https://www.quora.com/If-I-write-with-a-pencil-on-my-notebook-will-the-writing-last-for-a-long-time-say-50-years-or-will-it-just-fade-away-gradually Writing in a notebook with pencil]&lt;/ref&gt;&lt;ref&gt;[http://copar.org/bulletin14.htm CoPAR: Creating records that will last]&lt;/ref&gt;.<br />
<br />
Some people get the idea to split up their phrases. Storing 6 words in one location and the other 6 words in another location. This is a bad idea and should not be done, because if one set of 6 words is discovered then it becomes easier to bruteforce the rest of the phrase. Storing bitcoins in multiple locations like this should be done via [[multisignature]] wallets instead.<br />
<br />
Another bad idea is to add random decoy words that are somehow meaningful to you, and later remove them to be left only with the 12 word phrase. The phrase words come from a known dictionary (see next section), so anybody can use that dictionary to weed out the decoy words.<br />
<br />
It could be a good idea to write some words of explanation on the same paper as the seed phrase. If storing for the long term you may forget what a phrase is how it should be treated. A sample explanation that can be adapted is:<br />
<br />
&lt;blockquote&gt;These twelve words have control over BITCOINS. Keep this paper safe and secret, like cash or jewelry. The bitcoin information on this paper is encrypted with a passphrase. It is part of a multisignature wallet and was made by Electrum bitcoin wallet software on 1/1/2012.&lt;/blockquote&gt;<br />
<br />
== Word Lists ==<br />
<br />
Generally a seed phrase only works with the same wallet software that created it. If storing for a long period of time it's a good idea to write the name of the wallet too.<br />
<br />
The BIP39 English word list has each word being uniquely identified by the first four letters, which can be useful when space to write them is scarce.<br />
<br />
* [https://github.com/bitcoin/bips/blob/master/bip-0039/bip-0039-wordlists.md BIP39 wordlists]<br />
* [https://github.com/spesmilo/electrum/blob/1.9.8/lib/mnemonic.py Electrum old-style wordlist]<br />
* [https://github.com/spesmilo/electrum/blob/master/electrum/wordlist/english.txt Electrum new-style wordlist]<br />
<br />
== Alternative name &quot;Mnemonic Phrase&quot; ==<br />
<br />
Seed phrases are sometimes called &quot;mnemonic phrases&quot; especially in older literature. This is a bad name because the word mnemonic implies that the phrase should be memorized. It is less misleading to call them seed phrases.<br />
<br />
== The power of backups ==<br />
<br />
An especially interesting aspect in the power of paper backups is allowing your money to be two places at once. At the London Inside Bitcoin conference the keynote speaker showed 25 paper backups they were carrying -- all password-protected. With that one can carry $100,000 which can instantly be moved to a phone or transferred yet with total security. If it's stolen then there is no risk because it is backed up elsewhere. That is powerful.&lt;ref&gt;https://www.reddit.com/r/Bitcoin/comments/2hmnru/poll_do_you_use_paper_wallets_why_why_not_what/&lt;/ref&gt;<br />
<br />
== See Also ==<br />
<br />
* [https://github.com/bitcoin/bips/blob/master/bip-0039.mediawiki BIP39 mnemonic phrase standard]<br />
* [[Deterministic wallet]]<br />
* [[Storing bitcoins]]<br />
* [[Brainwallet]]<br />
* [https://github.com/6102bitcoin/FAQ/blob/master/seed.md FAQ regarding bitcoin seeds]<br />
<br />
==References==<br />
&lt;references /&gt;<br />
<br />
<br />
[[Category:Technical]]</div>Sgornickhttps://en.bitcoin.it/w/index.php?title=Transaction_accelerator&diff=66472Transaction accelerator2019-05-17T11:50:48Z<p>Sgornick: /* Third Party Accelerators */ Bold to dissuade use.</p>
<hr />
<div>=What to Do if Your Bitcoin Transaction Gets &quot;Stuck&quot;=<br />
<br />
The number of transactions on the Bitcoin network has steadily increased over the years. This means more blocks are filling up. And as not all transactions can be included in the blockchain straight away, backlogs form in miners’ “mempools” (a sort of “transaction queue.”)<br />
<br />
Miners typically pick the transactions that pay the most fees and include these in their blocks first. Transactions that include lower fees are “outbid” on the so called “fee market,” and remain in miners’ mempools until a new block is found. If the transaction is outbid again, it has to wait until the next block.<br />
<br />
This can lead to a suboptimal user experience. Transactions with too low a fee can take hours or even days to confirm, and sometimes never confirm at all.<br />
<br />
==Fee Bumping==<br />
<br />
The recommended approach to &quot;accelerating&quot; a transaction is to perform a [[fee bumping]] methods, either [[replace by fee|replace-by-fee]] (RBF), or [[Transaction fees#Feerates_for_dependent_transactions_.28child-pays-for-parent.29|child-pays-for-parent]] (CPFP), which are available to:<br />
<br />
* Sender of the Bitcoin transaction: Replace-by-fee (RBF), and Child-pays-for-parent (CPFP) <br />
* Recipient of the Bitcoin transaction: Child-pays-for-parent (CPFP)<br />
<br />
==Bitcoin transaction accelerators==<br />
<br />
===Mining Pool Accelerators===<br />
<br />
A mining pool may offer a premium service in which they will prioritize a transaction, usually for a fee. The ability for that pool to get a transaction confirmed is limited to their ability to get a block confirmed -- and most pools have a tiny [https://www.blockchain.com/pools fraction of the hashrate]. For example, if a pool has 10% of the hashrate, they mine about a block every 100 minutes (1 hour and 40 minutes), on average. If a pool has 5% of the hashrate, then they mine one block about every 200 minutes (3 hours and 20 minutes), on average. <br />
<br />
* https://pushtx.btc.com: This service is provided by BTC.com in cooperation with several main mining pools. The fee was around 70 USD on December 20, 2017 and the transaction was confirmed within 3 hours. You can pay by BCH or country-specific methods and they estimate the fee based on the transaction size. They promise a chance of 75% for including transactions in the next block within one hour. Within 4 hours the chance is claimed to be at 98%. They guarantee that if the transaction isn’t confirmed in 12 hours, the fees will be fully refunded to your card within 10 ~ 15 days. This policy is not applicable to the transactions which are removed or double-spent during the acceleration process.<br />
<br />
* [https://pool.viabtc.com/tools/txaccelerator/ ViaBTC] - overloaded as of December 20, 2017. ViaBTC implemented this service to protest against the prior 1MB limitation of the Bitcoin network. ViaBTC gives priority to user-submitted transactions for the next mined blocks by the ViaBTC pool. The only requirement is the transaction must include a minimum fee of 0.0001BTC/KB.The free-to-use nature of the service may have made it widely popular as every hour, the number of transaction requested reaches its limit and it is common to be presented with the message “Submissions are beyond limit. Please try later.” on the top middle of the page. This means one must wait for the next block to try a new submission. After submitting a transaction, there is a wait for the next block to be mined by ViaBTC Pool.<br />
<br />
===Third Party Accelerators===<br />
There are additional services claiming to be able to &quot;accelerate&quot; a transaction. Their ability to get a transaction confirmed faster is limited to re-broadcasting your transaction, to help in the situation where that mining pool has dropped your transaction already. The Bitcoin Core client already does re-broadcast a &quot;stuck&quot; transaction periodically to peer nodes, though these services possibly may broadcast a transaction directly to known mining pool nodes. These services could also pay a mining pool to include your transaction, just as you could do that yourself.<br />
<br />
It is likely these &quot;transaction accelerators&quot; that are not the mining pools themselves '''are not actually helping to get a transaction confirmed faster'''.<br />
<br />
* http://www.hooli1.net/: The service offer free and paid service. relatively new site. you can read more about it here before make a deceision: https://bitcointalk.org/index.php?topic=2717898.0 .&quot;<br />
<br />
* https://Confirmtx.com: The service asks for payment but there's no button to pay. Old note: &quot;Warning This website turned into a big scam.&quot;<br />
<br />
* https://bitaccelerate.com/ Free Bitcoin transaction accelerator. The service actually rebroadcasts your transaction via different nodes.</div>Sgornickhttps://en.bitcoin.it/w/index.php?title=Transaction_accelerator&diff=66471Transaction accelerator2019-05-17T11:49:07Z<p>Sgornick: /* Bitcoin transaction accelerators */ Move text to appropriate subsections.</p>
<hr />
<div>=What to Do if Your Bitcoin Transaction Gets &quot;Stuck&quot;=<br />
<br />
The number of transactions on the Bitcoin network has steadily increased over the years. This means more blocks are filling up. And as not all transactions can be included in the blockchain straight away, backlogs form in miners’ “mempools” (a sort of “transaction queue.”)<br />
<br />
Miners typically pick the transactions that pay the most fees and include these in their blocks first. Transactions that include lower fees are “outbid” on the so called “fee market,” and remain in miners’ mempools until a new block is found. If the transaction is outbid again, it has to wait until the next block.<br />
<br />
This can lead to a suboptimal user experience. Transactions with too low a fee can take hours or even days to confirm, and sometimes never confirm at all.<br />
<br />
==Fee Bumping==<br />
<br />
The recommended approach to &quot;accelerating&quot; a transaction is to perform a [[fee bumping]] methods, either [[replace by fee|replace-by-fee]] (RBF), or [[Transaction fees#Feerates_for_dependent_transactions_.28child-pays-for-parent.29|child-pays-for-parent]] (CPFP), which are available to:<br />
<br />
* Sender of the Bitcoin transaction: Replace-by-fee (RBF), and Child-pays-for-parent (CPFP) <br />
* Recipient of the Bitcoin transaction: Child-pays-for-parent (CPFP)<br />
<br />
==Bitcoin transaction accelerators==<br />
<br />
===Mining Pool Accelerators===<br />
<br />
A mining pool may offer a premium service in which they will prioritize a transaction, usually for a fee. The ability for that pool to get a transaction confirmed is limited to their ability to get a block confirmed -- and most pools have a tiny [https://www.blockchain.com/pools fraction of the hashrate]. For example, if a pool has 10% of the hashrate, they mine about a block every 100 minutes (1 hour and 40 minutes), on average. If a pool has 5% of the hashrate, then they mine one block about every 200 minutes (3 hours and 20 minutes), on average. <br />
<br />
* https://pushtx.btc.com: This service is provided by BTC.com in cooperation with several main mining pools. The fee was around 70 USD on December 20, 2017 and the transaction was confirmed within 3 hours. You can pay by BCH or country-specific methods and they estimate the fee based on the transaction size. They promise a chance of 75% for including transactions in the next block within one hour. Within 4 hours the chance is claimed to be at 98%. They guarantee that if the transaction isn’t confirmed in 12 hours, the fees will be fully refunded to your card within 10 ~ 15 days. This policy is not applicable to the transactions which are removed or double-spent during the acceleration process.<br />
<br />
* [https://pool.viabtc.com/tools/txaccelerator/ ViaBTC] - overloaded as of December 20, 2017. ViaBTC implemented this service to protest against the prior 1MB limitation of the Bitcoin network. ViaBTC gives priority to user-submitted transactions for the next mined blocks by the ViaBTC pool. The only requirement is the transaction must include a minimum fee of 0.0001BTC/KB.The free-to-use nature of the service may have made it widely popular as every hour, the number of transaction requested reaches its limit and it is common to be presented with the message “Submissions are beyond limit. Please try later.” on the top middle of the page. This means one must wait for the next block to try a new submission. After submitting a transaction, there is a wait for the next block to be mined by ViaBTC Pool.<br />
<br />
===Third Party Accelerators===<br />
There are additional services claiming to be able to &quot;accelerate&quot; a transaction. Their ability to get a transaction confirmed faster is limited to re-broadcasting your transaction, to help in the situation where that mining pool has dropped your transaction already. The Bitcoin Core client already does re-broadcast a &quot;stuck&quot; transaction periodically to peer nodes, though these services possibly may broadcast a transaction directly to known mining pool nodes. These services could also pay a mining pool to include your transaction, just as you could do that yourself.<br />
<br />
It is likely these &quot;transaction accelerators&quot; that are not the mining pools themselves are not actually helping to get a transaction confirmed faster.<br />
<br />
* http://www.hooli1.net/: The service offer free and paid service. relatively new site. you can read more about it here before make a deceision: https://bitcointalk.org/index.php?topic=2717898.0 .&quot;<br />
<br />
* https://Confirmtx.com: The service asks for payment but there's no button to pay. Old note: &quot;Warning This website turned into a big scam.&quot;<br />
<br />
* https://bitaccelerate.com/ Free Bitcoin transaction accelerator. The service actually rebroadcasts your transaction via different nodes.</div>Sgornickhttps://en.bitcoin.it/w/index.php?title=User:Sgornick&diff=66470User:Sgornick2019-05-17T11:47:15Z<p>Sgornick: Remove extraneous, no longer needed.</p>
<hr />
<div>Stephen Gornick<br />
* Los Angeles area, Southern California, USA<br />
* Programmer (Python, Google App Engine)<br />
* Entrepreneur<br />
<br />
==Contact==<br />
* Phone: +1.310.356.9912<br />
* email: sgornick@digicoast.com<br />
* Twitter: [http://twitter.com/sgornick @sgornick]<br />
<br />
[[Category:Freelancers]]</div>Sgornickhttps://en.bitcoin.it/w/index.php?title=Transaction_accelerator&diff=66469Transaction accelerator2019-05-17T10:54:29Z<p>Sgornick: /* Fee Bumping */ Provide bulleted list explaining who has what fee bumping methods available.</p>
<hr />
<div>=What to Do if Your Bitcoin Transaction Gets &quot;Stuck&quot;=<br />
<br />
The number of transactions on the Bitcoin network has steadily increased over the years. This means more blocks are filling up. And as not all transactions can be included in the blockchain straight away, backlogs form in miners’ “mempools” (a sort of “transaction queue.”)<br />
<br />
Miners typically pick the transactions that pay the most fees and include these in their blocks first. Transactions that include lower fees are “outbid” on the so called “fee market,” and remain in miners’ mempools until a new block is found. If the transaction is outbid again, it has to wait until the next block.<br />
<br />
This can lead to a suboptimal user experience. Transactions with too low a fee can take hours or even days to confirm, and sometimes never confirm at all.<br />
<br />
==Fee Bumping==<br />
<br />
The recommended approach to &quot;accelerating&quot; a transaction is to perform a [[fee bumping]] methods, either [[replace by fee|replace-by-fee]] (RBF), or [[Transaction fees#Feerates_for_dependent_transactions_.28child-pays-for-parent.29|child-pays-for-parent]] (CPFP), which are available to:<br />
<br />
* Sender of the Bitcoin transaction: Replace-by-fee (RBF), and Child-pays-for-parent (CPFP) <br />
* Recipient of the Bitcoin transaction: Child-pays-for-parent (CPFP)<br />
<br />
==Bitcoin transaction accelerators==<br />
<br />
A mining pool may offer a premium service in which they will prioritize a transaction, usually for a fee. The ability for that pool to get a transaction confirmed is limited to their ability to get a block confirmed -- and most pools have a tiny [https://www.blockchain.com/pools fraction of the hashrate]. For example, if a pool has 10% of the hashrate, they mine about a block every 100 minutes (1 hour and 40 minutes), on average. If a pool has 5% of the hashrate, then they mine one block about every 200 minutes (3 hours and 20 minutes), on average. <br />
<br />
There are additional services claiming to be able to &quot;accelerate&quot; a transaction. Their ability to get a transaction confirmed faster is limited to re-broadcasting your transaction, to help in the situation where that mining pool has dropped your transaction already. The Bitcoin Core client already does re-broadcast a &quot;stuck&quot; transaction periodically to peer nodes, though these services possibly may broadcast a transaction directly to known mining pool nodes. These services could also pay a mining pool to include your transaction, just as you could do that yourself.<br />
<br />
It is likely these &quot;transaction accelerators&quot; that are not the mining pools themselves are not actually helping to get a transaction confirmed faster.<br />
<br />
===Mining Pool Accelerators===<br />
<br />
* https://pushtx.btc.com: This service is provided by BTC.com in cooperation with several main mining pools. The fee was around 70 USD on December 20, 2017 and the transaction was confirmed within 3 hours. You can pay by BCH or country-specific methods and they estimate the fee based on the transaction size. They promise a chance of 75% for including transactions in the next block within one hour. Within 4 hours the chance is claimed to be at 98%. They guarantee that if the transaction isn’t confirmed in 12 hours, the fees will be fully refunded to your card within 10 ~ 15 days. This policy is not applicable to the transactions which are removed or double-spent during the acceleration process.<br />
<br />
* [https://pool.viabtc.com/tools/txaccelerator/ ViaBTC] - overloaded as of December 20, 2017. ViaBTC implemented this service to protest against the prior 1MB limitation of the Bitcoin network. ViaBTC gives priority to user-submitted transactions for the next mined blocks by the ViaBTC pool. The only requirement is the transaction must include a minimum fee of 0.0001BTC/KB.The free-to-use nature of the service may have made it widely popular as every hour, the number of transaction requested reaches its limit and it is common to be presented with the message “Submissions are beyond limit. Please try later.” on the top middle of the page. This means one must wait for the next block to try a new submission. After submitting a transaction, there is a wait for the next block to be mined by ViaBTC Pool.<br />
<br />
===Third Party Accelerators===<br />
* http://www.hooli1.net/: The service offer free and paid service. relatively new site. you can read more about it here before make a deceision: https://bitcointalk.org/index.php?topic=2717898.0 .&quot;<br />
<br />
* https://Confirmtx.com: The service asks for payment but there's no button to pay. Old note: &quot;Warning This website turned into a big scam.&quot;<br />
<br />
* https://bitaccelerate.com/ Free Bitcoin transaction accelerator. The service actually rebroadcasts your transaction via different nodes.</div>Sgornickhttps://en.bitcoin.it/w/index.php?title=Transaction_accelerator&diff=66468Transaction accelerator2019-05-17T10:45:39Z<p>Sgornick: Add Fee Bumping as a second level subsection. Remove See Also as that would now be duplication.</p>
<hr />
<div>=What to Do if Your Bitcoin Transaction Gets &quot;Stuck&quot;=<br />
<br />
The number of transactions on the Bitcoin network has steadily increased over the years. This means more blocks are filling up. And as not all transactions can be included in the blockchain straight away, backlogs form in miners’ “mempools” (a sort of “transaction queue.”)<br />
<br />
Miners typically pick the transactions that pay the most fees and include these in their blocks first. Transactions that include lower fees are “outbid” on the so called “fee market,” and remain in miners’ mempools until a new block is found. If the transaction is outbid again, it has to wait until the next block.<br />
<br />
This can lead to a suboptimal user experience. Transactions with too low a fee can take hours or even days to confirm, and sometimes never confirm at all.<br />
<br />
==Fee Bumping==<br />
<br />
The recommended approach to &quot;accelerating&quot; a transaction is to perform a [[fee bumping]] method which is available to either the sender and/or the recipient of a Bitcoin transaction.<br />
<br />
==Bitcoin transaction accelerators==<br />
<br />
A mining pool may offer a premium service in which they will prioritize a transaction, usually for a fee. The ability for that pool to get a transaction confirmed is limited to their ability to get a block confirmed -- and most pools have a tiny [https://www.blockchain.com/pools fraction of the hashrate]. For example, if a pool has 10% of the hashrate, they mine about a block every 100 minutes (1 hour and 40 minutes), on average. If a pool has 5% of the hashrate, then they mine one block about every 200 minutes (3 hours and 20 minutes), on average. <br />
<br />
There are additional services claiming to be able to &quot;accelerate&quot; a transaction. Their ability to get a transaction confirmed faster is limited to re-broadcasting your transaction, to help in the situation where that mining pool has dropped your transaction already. The Bitcoin Core client already does re-broadcast a &quot;stuck&quot; transaction periodically to peer nodes, though these services possibly may broadcast a transaction directly to known mining pool nodes. These services could also pay a mining pool to include your transaction, just as you could do that yourself.<br />
<br />
It is likely these &quot;transaction accelerators&quot; that are not the mining pools themselves are not actually helping to get a transaction confirmed faster.<br />
<br />
===Mining Pool Accelerators===<br />
<br />
* https://pushtx.btc.com: This service is provided by BTC.com in cooperation with several main mining pools. The fee was around 70 USD on December 20, 2017 and the transaction was confirmed within 3 hours. You can pay by BCH or country-specific methods and they estimate the fee based on the transaction size. They promise a chance of 75% for including transactions in the next block within one hour. Within 4 hours the chance is claimed to be at 98%. They guarantee that if the transaction isn’t confirmed in 12 hours, the fees will be fully refunded to your card within 10 ~ 15 days. This policy is not applicable to the transactions which are removed or double-spent during the acceleration process.<br />
<br />
* [https://pool.viabtc.com/tools/txaccelerator/ ViaBTC] - overloaded as of December 20, 2017. ViaBTC implemented this service to protest against the prior 1MB limitation of the Bitcoin network. ViaBTC gives priority to user-submitted transactions for the next mined blocks by the ViaBTC pool. The only requirement is the transaction must include a minimum fee of 0.0001BTC/KB.The free-to-use nature of the service may have made it widely popular as every hour, the number of transaction requested reaches its limit and it is common to be presented with the message “Submissions are beyond limit. Please try later.” on the top middle of the page. This means one must wait for the next block to try a new submission. After submitting a transaction, there is a wait for the next block to be mined by ViaBTC Pool.<br />
<br />
===Third Party Accelerators===<br />
* http://www.hooli1.net/: The service offer free and paid service. relatively new site. you can read more about it here before make a deceision: https://bitcointalk.org/index.php?topic=2717898.0 .&quot;<br />
<br />
* https://Confirmtx.com: The service asks for payment but there's no button to pay. Old note: &quot;Warning This website turned into a big scam.&quot;<br />
<br />
* https://bitaccelerate.com/ Free Bitcoin transaction accelerator. The service actually rebroadcasts your transaction via different nodes.</div>Sgornickhttps://en.bitcoin.it/w/index.php?title=Transaction_accelerator&diff=66467Transaction accelerator2019-05-17T10:41:08Z<p>Sgornick: Move See Also to First Level, from Second Level.</p>
<hr />
<div>=What to Do if Your Bitcoin Transaction Gets &quot;Stuck&quot;=<br />
<br />
The number of transactions on the Bitcoin network has steadily increased over the years. This means more blocks are filling up. And as not all transactions can be included in the blockchain straight away, backlogs form in miners’ “mempools” (a sort of “transaction queue.”)<br />
<br />
Miners typically pick the transactions that pay the most fees and include these in their blocks first. Transactions that include lower fees are “outbid” on the so called “fee market,” and remain in miners’ mempools until a new block is found. If the transaction is outbid again, it has to wait until the next block.<br />
<br />
This can lead to a suboptimal user experience. Transactions with too low a fee can take hours or even days to confirm, and sometimes never confirm at all.<br />
<br />
A mining pool may offer a premium service in which they will prioritize a transaction, usually for a fee. The ability for that pool to get a transaction confirmed is limited to their ability to get a block confirmed -- and most pools have a tiny [https://www.blockchain.com/pools fraction of the hashrate]. For example, if a pool has 10% of the hashrate, they mine about a block every 100 minutes (1 hour and 40 minutes), on average. If a pool has 5% of the hashrate, then they mine one block about every 200 minutes (3 hours and 20 minutes), on average. <br />
<br />
There are additional services claiming to be able to &quot;accelerate&quot; a transaction. Their ability to get a transaction confirmed faster is limited to re-broadcasting your transaction, to help in the situation where that mining pool has dropped your transaction already. The Bitcoin Core client already does re-broadcast a &quot;stuck&quot; transaction periodically to peer nodes, though these services possibly may broadcast a transaction directly to known mining pool nodes. These services could also pay a mining pool to include your transaction, just as you could do that yourself.<br />
<br />
It is likely these &quot;transaction accelerators&quot; that are not the mining pools themselves are not actually helping to get a transaction confirmed faster.<br />
<br />
The recommended approach to &quot;accelerating&quot; a transaction is to perform a [[fee bumping]] method which is available to either the sender and/or the recipient of a Bitcoin transaction.<br />
<br />
==Bitcoin transaction accelerators==<br />
<br />
===Mining Pool Accelerators===<br />
<br />
* https://pushtx.btc.com: This service is provided by BTC.com in cooperation with several main mining pools. The fee was around 70 USD on December 20, 2017 and the transaction was confirmed within 3 hours. You can pay by BCH or country-specific methods and they estimate the fee based on the transaction size. They promise a chance of 75% for including transactions in the next block within one hour. Within 4 hours the chance is claimed to be at 98%. They guarantee that if the transaction isn’t confirmed in 12 hours, the fees will be fully refunded to your card within 10 ~ 15 days. This policy is not applicable to the transactions which are removed or double-spent during the acceleration process.<br />
<br />
* [https://pool.viabtc.com/tools/txaccelerator/ ViaBTC] - overloaded as of December 20, 2017. ViaBTC implemented this service to protest against the prior 1MB limitation of the Bitcoin network. ViaBTC gives priority to user-submitted transactions for the next mined blocks by the ViaBTC pool. The only requirement is the transaction must include a minimum fee of 0.0001BTC/KB.The free-to-use nature of the service may have made it widely popular as every hour, the number of transaction requested reaches its limit and it is common to be presented with the message “Submissions are beyond limit. Please try later.” on the top middle of the page. This means one must wait for the next block to try a new submission. After submitting a transaction, there is a wait for the next block to be mined by ViaBTC Pool.<br />
<br />
===Third Party Accelerators===<br />
* http://www.hooli1.net/: The service offer free and paid service. relatively new site. you can read more about it here before make a deceision: https://bitcointalk.org/index.php?topic=2717898.0 .&quot;<br />
<br />
* https://Confirmtx.com: The service asks for payment but there's no button to pay. Old note: &quot;Warning This website turned into a big scam.&quot;<br />
<br />
* https://bitaccelerate.com/ Free Bitcoin transaction accelerator. The service actually rebroadcasts your transaction via different nodes.<br />
<br />
=See Also=<br />
<br />
* [[Fee bumping]]</div>Sgornickhttps://en.bitcoin.it/w/index.php?title=Transaction_accelerator&diff=66466Transaction accelerator2019-05-17T10:40:11Z<p>Sgornick: Add See Also subsection with an entry for Fee bumping article.</p>
<hr />
<div>=What to Do if Your Bitcoin Transaction Gets &quot;Stuck&quot;=<br />
<br />
The number of transactions on the Bitcoin network has steadily increased over the years. This means more blocks are filling up. And as not all transactions can be included in the blockchain straight away, backlogs form in miners’ “mempools” (a sort of “transaction queue.”)<br />
<br />
Miners typically pick the transactions that pay the most fees and include these in their blocks first. Transactions that include lower fees are “outbid” on the so called “fee market,” and remain in miners’ mempools until a new block is found. If the transaction is outbid again, it has to wait until the next block.<br />
<br />
This can lead to a suboptimal user experience. Transactions with too low a fee can take hours or even days to confirm, and sometimes never confirm at all.<br />
<br />
A mining pool may offer a premium service in which they will prioritize a transaction, usually for a fee. The ability for that pool to get a transaction confirmed is limited to their ability to get a block confirmed -- and most pools have a tiny [https://www.blockchain.com/pools fraction of the hashrate]. For example, if a pool has 10% of the hashrate, they mine about a block every 100 minutes (1 hour and 40 minutes), on average. If a pool has 5% of the hashrate, then they mine one block about every 200 minutes (3 hours and 20 minutes), on average. <br />
<br />
There are additional services claiming to be able to &quot;accelerate&quot; a transaction. Their ability to get a transaction confirmed faster is limited to re-broadcasting your transaction, to help in the situation where that mining pool has dropped your transaction already. The Bitcoin Core client already does re-broadcast a &quot;stuck&quot; transaction periodically to peer nodes, though these services possibly may broadcast a transaction directly to known mining pool nodes. These services could also pay a mining pool to include your transaction, just as you could do that yourself.<br />
<br />
It is likely these &quot;transaction accelerators&quot; that are not the mining pools themselves are not actually helping to get a transaction confirmed faster.<br />
<br />
The recommended approach to &quot;accelerating&quot; a transaction is to perform a [[fee bumping]] method which is available to either the sender and/or the recipient of a Bitcoin transaction.<br />
<br />
==Bitcoin transaction accelerators==<br />
<br />
===Mining Pool Accelerators===<br />
<br />
* https://pushtx.btc.com: This service is provided by BTC.com in cooperation with several main mining pools. The fee was around 70 USD on December 20, 2017 and the transaction was confirmed within 3 hours. You can pay by BCH or country-specific methods and they estimate the fee based on the transaction size. They promise a chance of 75% for including transactions in the next block within one hour. Within 4 hours the chance is claimed to be at 98%. They guarantee that if the transaction isn’t confirmed in 12 hours, the fees will be fully refunded to your card within 10 ~ 15 days. This policy is not applicable to the transactions which are removed or double-spent during the acceleration process.<br />
<br />
* [https://pool.viabtc.com/tools/txaccelerator/ ViaBTC] - overloaded as of December 20, 2017. ViaBTC implemented this service to protest against the prior 1MB limitation of the Bitcoin network. ViaBTC gives priority to user-submitted transactions for the next mined blocks by the ViaBTC pool. The only requirement is the transaction must include a minimum fee of 0.0001BTC/KB.The free-to-use nature of the service may have made it widely popular as every hour, the number of transaction requested reaches its limit and it is common to be presented with the message “Submissions are beyond limit. Please try later.” on the top middle of the page. This means one must wait for the next block to try a new submission. After submitting a transaction, there is a wait for the next block to be mined by ViaBTC Pool.<br />
<br />
===Third Party Accelerators===<br />
* http://www.hooli1.net/: The service offer free and paid service. relatively new site. you can read more about it here before make a deceision: https://bitcointalk.org/index.php?topic=2717898.0 .&quot;<br />
<br />
* https://Confirmtx.com: The service asks for payment but there's no button to pay. Old note: &quot;Warning This website turned into a big scam.&quot;<br />
<br />
* https://bitaccelerate.com/ Free Bitcoin transaction accelerator. The service actually rebroadcasts your transaction via different nodes.<br />
<br />
==See Also==<br />
<br />
* [[Fee bumping]]</div>Sgornickhttps://en.bitcoin.it/w/index.php?title=Transaction_accelerator&diff=66465Transaction accelerator2019-05-17T10:34:37Z<p>Sgornick: /* What to Do if Your Bitcoin Transaction Gets &quot;Stuck&quot; */ Clarify limits as to what a transaction accelerator might be able to do</p>
<hr />
<div>=What to Do if Your Bitcoin Transaction Gets &quot;Stuck&quot;=<br />
<br />
The number of transactions on the Bitcoin network has steadily increased over the years. This means more blocks are filling up. And as not all transactions can be included in the blockchain straight away, backlogs form in miners’ “mempools” (a sort of “transaction queue.”)<br />
<br />
Miners typically pick the transactions that pay the most fees and include these in their blocks first. Transactions that include lower fees are “outbid” on the so called “fee market,” and remain in miners’ mempools until a new block is found. If the transaction is outbid again, it has to wait until the next block.<br />
<br />
This can lead to a suboptimal user experience. Transactions with too low a fee can take hours or even days to confirm, and sometimes never confirm at all.<br />
<br />
A mining pool may offer a premium service in which they will prioritize a transaction, usually for a fee. The ability for that pool to get a transaction confirmed is limited to their ability to get a block confirmed -- and most pools have a tiny [https://www.blockchain.com/pools fraction of the hashrate]. For example, if a pool has 10% of the hashrate, they mine about a block every 100 minutes (1 hour and 40 minutes), on average. If a pool has 5% of the hashrate, then they mine one block about every 200 minutes (3 hours and 20 minutes), on average. <br />
<br />
There are additional services claiming to be able to &quot;accelerate&quot; a transaction. Their ability to get a transaction confirmed faster is limited to re-broadcasting your transaction, to help in the situation where that mining pool has dropped your transaction already. The Bitcoin Core client already does re-broadcast a &quot;stuck&quot; transaction periodically to peer nodes, though these services possibly may broadcast a transaction directly to known mining pool nodes. These services could also pay a mining pool to include your transaction, just as you could do that yourself.<br />
<br />
It is likely these &quot;transaction accelerators&quot; that are not the mining pools themselves are not actually helping to get a transaction confirmed faster.<br />
<br />
The recommended approach to &quot;accelerating&quot; a transaction is to perform a [[fee bumping]] method which is available to either the sender and/or the recipient of a Bitcoin transaction.<br />
<br />
==Bitcoin transaction accelerators==<br />
<br />
===Mining Pool Accelerators===<br />
<br />
* https://pushtx.btc.com: This service is provided by BTC.com in cooperation with several main mining pools. The fee was around 70 USD on December 20, 2017 and the transaction was confirmed within 3 hours. You can pay by BCH or country-specific methods and they estimate the fee based on the transaction size. They promise a chance of 75% for including transactions in the next block within one hour. Within 4 hours the chance is claimed to be at 98%. They guarantee that if the transaction isn’t confirmed in 12 hours, the fees will be fully refunded to your card within 10 ~ 15 days. This policy is not applicable to the transactions which are removed or double-spent during the acceleration process.<br />
<br />
* [https://pool.viabtc.com/tools/txaccelerator/ ViaBTC] - overloaded as of December 20, 2017. ViaBTC implemented this service to protest against the prior 1MB limitation of the Bitcoin network. ViaBTC gives priority to user-submitted transactions for the next mined blocks by the ViaBTC pool. The only requirement is the transaction must include a minimum fee of 0.0001BTC/KB.The free-to-use nature of the service may have made it widely popular as every hour, the number of transaction requested reaches its limit and it is common to be presented with the message “Submissions are beyond limit. Please try later.” on the top middle of the page. This means one must wait for the next block to try a new submission. After submitting a transaction, there is a wait for the next block to be mined by ViaBTC Pool.<br />
<br />
===Third Party Accelerators===<br />
* http://www.hooli1.net/: The service offer free and paid service. relatively new site. you can read more about it here before make a deceision: https://bitcointalk.org/index.php?topic=2717898.0 .&quot;<br />
<br />
* https://Confirmtx.com: The service asks for payment but there's no button to pay. Old note: &quot;Warning This website turned into a big scam.&quot;<br />
<br />
* https://bitaccelerate.com/ Free Bitcoin transaction accelerator. The service actually rebroadcasts your transaction via different nodes.</div>Sgornickhttps://en.bitcoin.it/w/index.php?title=Transaction_accelerator&diff=66464Transaction accelerator2019-05-17T10:34:02Z<p>Sgornick: Undo revision 66463 by Sgornick (talk) Didn't mean to replace subsection.</p>
<hr />
<div>=What to Do if Your Bitcoin Transaction Gets &quot;Stuck&quot;=<br />
<br />
The number of transactions on the Bitcoin network has steadily increased over the years. This means more blocks are filling up. And as not all transactions can be included in the blockchain straight away, backlogs form in miners’ “mempools” (a sort of “transaction queue.”)<br />
<br />
Miners typically pick the transactions that pay the most fees and include these in their blocks first. Transactions that include lower fees are “outbid” on the so called “fee market,” and remain in miners’ mempools until a new block is found. If the transaction is outbid again, it has to wait until the next block.<br />
<br />
This can lead to a suboptimal user experience. Transactions with too low a fee can take hours or even days to confirm, and sometimes never confirm at all.<br />
<br />
But there are PAID and Free bitcoin transaction acceleration services available now which you can use to keep your own transaction from getting stuck.<br />
<br />
==Bitcoin transaction accelerators==<br />
<br />
===Mining Pool Accelerators===<br />
<br />
* https://pushtx.btc.com: This service is provided by BTC.com in cooperation with several main mining pools. The fee was around 70 USD on December 20, 2017 and the transaction was confirmed within 3 hours. You can pay by BCH or country-specific methods and they estimate the fee based on the transaction size. They promise a chance of 75% for including transactions in the next block within one hour. Within 4 hours the chance is claimed to be at 98%. They guarantee that if the transaction isn’t confirmed in 12 hours, the fees will be fully refunded to your card within 10 ~ 15 days. This policy is not applicable to the transactions which are removed or double-spent during the acceleration process.<br />
<br />
* [https://pool.viabtc.com/tools/txaccelerator/ ViaBTC] - overloaded as of December 20, 2017. ViaBTC implemented this service to protest against the prior 1MB limitation of the Bitcoin network. ViaBTC gives priority to user-submitted transactions for the next mined blocks by the ViaBTC pool. The only requirement is the transaction must include a minimum fee of 0.0001BTC/KB.The free-to-use nature of the service may have made it widely popular as every hour, the number of transaction requested reaches its limit and it is common to be presented with the message “Submissions are beyond limit. Please try later.” on the top middle of the page. This means one must wait for the next block to try a new submission. After submitting a transaction, there is a wait for the next block to be mined by ViaBTC Pool.<br />
<br />
===Third Party Accelerators===<br />
* http://www.hooli1.net/: The service offer free and paid service. relatively new site. you can read more about it here before make a deceision: https://bitcointalk.org/index.php?topic=2717898.0 .&quot;<br />
<br />
* https://Confirmtx.com: The service asks for payment but there's no button to pay. Old note: &quot;Warning This website turned into a big scam.&quot;<br />
<br />
* https://bitaccelerate.com/ Free Bitcoin transaction accelerator. The service actually rebroadcasts your transaction via different nodes.</div>Sgornickhttps://en.bitcoin.it/w/index.php?title=Transaction_accelerator&diff=66463Transaction accelerator2019-05-17T10:32:11Z<p>Sgornick: /* What to Do if Your Bitcoin Transaction Gets &quot;Stuck&quot; */ Clarify limits as to what a transaction accelerator might be able to do</p>
<hr />
<div>=What to Do if Your Bitcoin Transaction Gets &quot;Stuck&quot;=<br />
<br />
The number of transactions on the Bitcoin network has steadily increased over the years. This means more blocks are filling up. And as not all transactions can be included in the blockchain straight away, backlogs form in miners’ “mempools” (a sort of “transaction queue.”)<br />
<br />
Miners typically pick the transactions that pay the most fees and include these in their blocks first. Transactions that include lower fees are “outbid” on the so called “fee market,” and remain in miners’ mempools until a new block is found. If the transaction is outbid again, it has to wait until the next block.<br />
<br />
This can lead to a suboptimal user experience. Transactions with too low a fee can take hours or even days to confirm, and sometimes never confirm at all.<br />
<br />
A mining pool may offer a premium service in which they will prioritize a transaction, usually for a fee. The ability for that pool to get a transaction confirmed is limited to their ability to get a block confirmed -- and most pools have a tiny [https://www.blockchain.com/pools fraction of the hashrate]. For example, if a pool has 10% of the hashrate, they mine about a block every 100 minutes (1 hour and 40 minutes), on average. If a pool has 5% of the hashrate, then they mine one block about every 200 minutes (3 hours and 20 minutes), on average. <br />
<br />
There are additional services claiming to be able to &quot;accelerate&quot; a transaction. Their ability to get a transaction confirmed faster is limited to re-broadcasting your transaction, to help in the situation where that mining pool has dropped your transaction already. The Bitcoin Core client already does re-broadcast a &quot;stuck&quot; transaction periodically to peer nodes, though these services possibly may broadcast a transaction directly to known mining pool nodes. These services could also pay a mining pool to include your transaction, just as you could do that yourself.<br />
<br />
It is likely these &quot;transaction accelerators&quot; that are not the mining pools themselves are not actually helping to get a transaction confirmed faster.<br />
<br />
The recommended approach to &quot;accelerating&quot; a transaction is to perform a [[fee bumping]] method which is available to either the sender and/or the recipient of a Bitcoin transaction.</div>Sgornickhttps://en.bitcoin.it/w/index.php?title=Transaction_accelerator&diff=66462Transaction accelerator2019-05-17T10:27:54Z<p>Sgornick: /* Bitcoin transaction accelerators */ Add subsections, to differentiate mining pool trx accelerators versus third party accelerators.</p>
<hr />
<div>=What to Do if Your Bitcoin Transaction Gets &quot;Stuck&quot;=<br />
<br />
The number of transactions on the Bitcoin network has steadily increased over the years. This means more blocks are filling up. And as not all transactions can be included in the blockchain straight away, backlogs form in miners’ “mempools” (a sort of “transaction queue.”)<br />
<br />
Miners typically pick the transactions that pay the most fees and include these in their blocks first. Transactions that include lower fees are “outbid” on the so called “fee market,” and remain in miners’ mempools until a new block is found. If the transaction is outbid again, it has to wait until the next block.<br />
<br />
This can lead to a suboptimal user experience. Transactions with too low a fee can take hours or even days to confirm, and sometimes never confirm at all.<br />
<br />
But there are PAID and Free bitcoin transaction acceleration services available now which you can use to keep your own transaction from getting stuck.<br />
<br />
==Bitcoin transaction accelerators==<br />
<br />
===Mining Pool Accelerators===<br />
<br />
* https://pushtx.btc.com: This service is provided by BTC.com in cooperation with several main mining pools. The fee was around 70 USD on December 20, 2017 and the transaction was confirmed within 3 hours. You can pay by BCH or country-specific methods and they estimate the fee based on the transaction size. They promise a chance of 75% for including transactions in the next block within one hour. Within 4 hours the chance is claimed to be at 98%. They guarantee that if the transaction isn’t confirmed in 12 hours, the fees will be fully refunded to your card within 10 ~ 15 days. This policy is not applicable to the transactions which are removed or double-spent during the acceleration process.<br />
<br />
* [https://pool.viabtc.com/tools/txaccelerator/ ViaBTC] - overloaded as of December 20, 2017. ViaBTC implemented this service to protest against the prior 1MB limitation of the Bitcoin network. ViaBTC gives priority to user-submitted transactions for the next mined blocks by the ViaBTC pool. The only requirement is the transaction must include a minimum fee of 0.0001BTC/KB.The free-to-use nature of the service may have made it widely popular as every hour, the number of transaction requested reaches its limit and it is common to be presented with the message “Submissions are beyond limit. Please try later.” on the top middle of the page. This means one must wait for the next block to try a new submission. After submitting a transaction, there is a wait for the next block to be mined by ViaBTC Pool.<br />
<br />
===Third Party Accelerators===<br />
* http://www.hooli1.net/: The service offer free and paid service. relatively new site. you can read more about it here before make a deceision: https://bitcointalk.org/index.php?topic=2717898.0 .&quot;<br />
<br />
* https://Confirmtx.com: The service asks for payment but there's no button to pay. Old note: &quot;Warning This website turned into a big scam.&quot;<br />
<br />
* https://bitaccelerate.com/ Free Bitcoin transaction accelerator. The service actually rebroadcasts your transaction via different nodes.</div>Sgornickhttps://en.bitcoin.it/w/index.php?title=User:Sgornick&diff=65487User:Sgornick2018-06-19T21:53:33Z<p>Sgornick: Remove a Twitter feed, leaving only personal Twitter feed.</p>
<hr />
<div>Stephen Gornick<br />
* Los Angeles area, Southern California, USA<br />
* Programmer (Python, Google App Engine)<br />
* Entrepreneur<br />
<br />
==Contact==<br />
* Phone: +1.310.356.9912<br />
* email: sgornick@digicoast.com<br />
* Twitter: [http://twitter.com/sgornick @sgornick]<br />
<br />
Contributors Award participant: 16EdR3VRkz1D2PHDyT5iXhub4CJRyDmo6x<br />
<br />
[[Category:Freelancers]]</div>Sgornickhttps://en.bitcoin.it/w/index.php?title=User:Sgornick&diff=65486User:Sgornick2018-06-19T21:51:55Z<p>Sgornick: Change Twitter account that I use for curating.</p>
<hr />
<div>Stephen Gornick<br />
* Los Angeles area, Southern California, USA<br />
* Programmer (Python, Google App Engine)<br />
* Entrepreneur<br />
<br />
I curate Bitcoin news on the [http://Twitter.com/Cryptocoin @Cryptocoin] Twitter account.<br />
<br />
==Contact==<br />
* Phone: +1.310.356.9912<br />
* email: sgornick@digicoast.com<br />
* Twitter: [http://twitter.com/sgornick @sgornick]<br />
<br />
Contributors Award participant: 16EdR3VRkz1D2PHDyT5iXhub4CJRyDmo6x<br />
<br />
[[Category:Freelancers]]</div>Sgornickhttps://en.bitcoin.it/w/index.php?title=Fee_bumping&diff=65018Fee bumping2018-03-06T00:04:09Z<p>Sgornick: Fix link for Child-pays-for-parent.</p>
<hr />
<div>The fee required for a transaction to quickly confirm varies according to network conditions. Generally it floats around slowly, but sometimes it shoots up due to spam transactions or a series of randomly-slow blocks. In such cases, you may find that your incoming or outgoing transactions get stuck in 0-conf status for a long time. Wallets ''should'' avoid this in 99% of cases by accurately predicting an appropriate fee, and they ''should'' be able to gracefully bump fees in the remaining 1% of cases, but in general, fees are handled pretty poorly by today's wallets.<br />
<br />
This page gives exact instructions on how to increase the fee on a transaction that is currently stuck in order to make it unstuck. This is always done by creating a new transaction that will either spend the coins sent by the stuck transaction (called [[Transaction fees#Feerates_for_dependent_transactions_.28child-pays-for-parent.29|child-pays-for-parent]], or CPFP) or replace the stuck transaction (called [[replace by fee|replace-by-fee]], or RBF). The instructions vary significantly depending on your wallet software. Find your wallet in the table of contents, and then go to the section labeled &quot;I sent the stuck transaction&quot; or &quot;I received the stuck transaction&quot;, as appropriate.<br />
<br />
In some cases, the instructions here become kludgy. Any time you're working outside of the normal wallet GUI, you're doing something that the developer didn't intend, and this could have negative consequences. Although we have tried to give good instructions, we can't guarantee that everything will work perfectly. If your wallet GUI doesn't directly support fee bumping, then the lowest-risk thing for you to do is to not bump the fee, and to just wait. This page is for those situations where you ''can't'' just wait.<br />
<br />
Often, the instructions on this page have to get pretty complicated. As such, we will frequently say stuff like &quot;Take such-and-such value; from now on, we'll call this value XYZ_AMOUNT&quot;. When we say something like this, you should write down in a text editor, &quot;XYZ_AMOUNT=0.123&quot; or similar so that you have the exact value ready for later. And then when we say something like &quot;Type &lt;tt&gt;send &quot;XYZ_AMOUNT&quot;&lt;/tt&gt;&quot;, we mean that you should directly replace the variable name with the value assigned earlier, so in this example it'd be &lt;tt&gt;send &quot;0.123&quot;&lt;/tt&gt;.<br />
<br />
== Choosing an appropriate new fee ==<br />
<br />
# Find the transaction ID (aka txid) of the stuck transaction. Almost all wallets have some way of doing this.<br />
# Search for the txid on https://blockchain.info/<br />
# On blockchain.info, in the footer, click Enable in &quot;Advanced: Enable&quot;. If advanced mode is already enabled so that it instead says &quot;Advanced: Disable&quot;, then don't disable it.<br />
# Write down the &quot;size&quot; number listed under &quot;Summary&quot;. Call this value STUCK_SIZE. Also call the same value TOTAL_SIZE. The reason for having two names for the same thing is that you might later have to add to TOTAL_SIZE, but not to STUCK_SIZE. Separately, write down the &quot;fees&quot; number listed under &quot;Inputs and outputs&quot;, and call this TOTAL_FEES.<br />
# On the left side of the green arrow near the top of the page will be one or more addresses. If any of them have a red U next to it, for each such address, click &quot;Output&quot;.<br />
# For the transactions that it brings you to, add the size to TOTAL_SIZE, and the fees to TOTAL_FEES. Do this for all of the outputs listed with a red U.<br />
# If any of ''those'' transactions also have red 'U's, you have to follow those as well and add their sizes and fees to the running totals. And so on. You might have to go down several layers.<br />
# Now TOTAL_SIZE is the the total size (in bytes) of all unconfirmed ancestors of your stuck transaction, and TOTAL_FEES is the total fees (in BTC) for all unconfirmed ancestors of your stuck transaction.<br />
# Go to https://estimatefee.com/. Around the middle-right of the page it'll say &quot;nnn satoshis/byte&quot;, where nnn is some number. Remember this number as TARGET_FEERATE.<br />
# We need to estimate the additional size of your replacement or CPFP transaction. We'll call this value NEWTX_SIZE. If the transaction you're trying to unstick is one that you sent, estimate NEWTX_SIZE as 100. If the transaction you're trying to unstick is one that you received, estimate NEWTX_SIZE as 500. Later on this page, the section for your specific wallet might give you a different value for NEWTX_SIZE, in which case you should use that value instead.<br />
# Compute the following: [(TARGET_FEERATE / 100000000) * (TOTAL_SIZE + NEWTX_SIZE)] - TOTAL_FEES. The result is an estimate of the '''total''' fee that your new transaction will need to pay in BTC. For mBTC, multiply by 10&lt;sup&gt;-3&lt;/sup&gt;; for bits/uBTC, 10&lt;sup&gt;-6&lt;/sup&gt;; for satoshi, 10&lt;sup&gt;-8&lt;/sup&gt;. This number is '''not''' per kB. If your wallet only allows you to specify fees in BTC/bits/satoshi per kB/byte, multiply the result by one of the following estimated conversion factors (we conservatively assume the worst-case 192-byte transaction for this estimation):<br />
#* BTC/kB: 5.20833333333<br />
#* bits/kB: 5208333.33333<br />
#* satoshi/kB: 520833333.333<br />
#* BTC/byte: 0.00520833333<br />
#* bits/byte: 5208.33333333<br />
#* satoshi/byte: 520833.333333<br />
<br />
If blockchain.info doesn't have your transaction, you can use a different block explorer. blockchain.info is actually notoriously unreliable, but it has the best interface for this particular task. <br />
<br />
Almost certainly, fine-tuning would result in a better fee rate, but the above instructions try to be very general and conservative (in the sense of having the highest chance of unsticking your transaction).<br />
<br />
== Instructions by wallet ==<br />
<br />
=== Bitcoin Core GUI ===<br />
<br />
As of version 0.13.2.<br />
<br />
==== I sent the stuck transaction ====<br />
<br />
This is a bit complicated. Make sure you follow the steps exactly.<br />
<br />
# On the Transactions tab, right click the stuck transaction and choose &quot;copy transaction ID&quot;. Paste to a text editor in order to save the value somewhere. We'll call this value STUCK_TX. Once you've saved STUCK_TX somewhere, right click the stuck transaction again and choose &quot;copy raw transaction&quot;; we'll call this value STUCK_RAWTX.<br />
# Go to Help -&gt; Debug Window -&gt; Console tab. Type &lt;tt&gt;decoderawtransaction STUCK_RAWTX&lt;/tt&gt;. Under &quot;vin&quot; (near the top), find the first &quot;txid&quot; label. Copy the txid next to the &quot;txid&quot; label, and call this STUCK_VIN.<br />
# You need to temporarily break connectivity. Go to Settings -&gt; Options -&gt; Network Tab. Enable &quot;Connect through SOCKS5 proxy (default proxy)&quot;. Change &quot;Proxy IP&quot; and &quot;port&quot; to something that won't actually work; for example, an IP of 127.0.0.1 and a port of 10 is very unlikely to work. If you already have a proxy set up, note down your current settings so that you can restore them later.<br />
# Shut down Bitcoin Core.<br />
# Go to your [[Data directory]] and delete the file &lt;tt&gt;mempool.dat&lt;/tt&gt;. This stops it acting as a cache and reloading your transaction.<br />
# Start Bitcoin Core with the command-line option &lt;tt&gt;-walletbroadcast=0&lt;/tt&gt;. On Linux, you might be able to just run &lt;tt&gt;bitcoin-qt -walletbroadcast=0&lt;/tt&gt;, depending on how your current startup script works. On Windows: find the shortcut for Bitcoin Core on your desktop or start menu; right click it and choose &quot;properties&quot;; add &lt;tt&gt;-walletbroadcast=0&lt;/tt&gt; to the end of &quot;target&quot;, so for example &lt;tt&gt;&quot;C:\Program Files\Bitcoin\bitcoin-qt.exe&quot;&lt;/tt&gt; would become &lt;tt&gt;&quot;C:\Program Files\Bitcoin\bitcoin-qt.exe&quot; -walletbroadcast=0&lt;/tt&gt;; click &quot;Apply&quot;; use that specific shortcut to start Bitcoin Core.<br />
# On the Transactions tab, right click the stuck transaction and choose &quot;abandon transaction&quot;. '''Warning''': Even though the transaction is listed as abandoned, ''it can still go through''. People have in the past lost money by abandoning a transaction, resending a separate replacement transaction, and then having ''both'' transactions go through. The following steps are designed to replace the abandoned transaction in a way which will prevent this sort of double payment from happening.<br />
# Undo the change which broke connectivity: Go to Settings -&gt; Options -&gt; Network Tab. Either disable &quot;Connect through SOCKS5 proxy (default proxy)&quot; or restore your previous proxy settings.<br />
# Restart Bitcoin Core, this time without &lt;tt&gt;-walletbroadcast=0&lt;/tt&gt;.<br />
# Go to Settings -&gt; Options -&gt; Wallet. Ensure that &quot;enable coin control features&quot; is selected, and click OK.<br />
# Go to the Send tab. Click the &quot;Inputs...&quot; button. For each entry in the list, right click it and select &quot;copy transaction ID&quot;, and paste to a text editor. You have to go through the entire list, and for each entry with a txid matching STUCK_VIN, enable the checkbox on the far left. Usually there is only one matching, but if there is more than one, then you have to enable all of them. It is very important that you get this step right.<br />
# In addition to the coins selected in the previous step, which are required, you can select more coins on the Coin Selection dialog if needed. You are creating a transaction that will replace your stuck transaction, so you need to bring &quot;Amount&quot; at the top high enough to send the transaction again, plus fees. Try to select as few as possible, though. Once enough coins are selected, press OK.<br />
# (Optional, makes your new fee more accurate.) In the &quot;Coin Control Features&quot; pane, call the value for &quot;Bytes&quot; NEWTX_BYTES. Referring back to the fee estimation steps in the first section of this page: Set NEWTX_SIZE to be TOTAL_SIZE - STUCK_SIZE + NEWTX_BYTES, where TOTAL_SIZE and STUCK_SIZE were defined back in that section. Do the estimated fee calculation using this NEWTX_SIZE.<br />
# Duplicate all of the settings of the stuck transaction, except for the fee. Instead of using the &quot;recommended&quot; fee, choose custom -&gt; total at least, and then use the amount indicated in this page's fee estimation section. Note that under normal circumstances you should almost always use either the recommended fee or a per-kilobyte custom fee, not &quot;total at least&quot;; this situation is a special case.<br />
# Send the transaction. Either the new transaction or the old transaction should get confirmed (''probably'' the new transaction), but not both if you did the coin control stuff correctly above.<br />
# Sometimes these transactions don't propagate well, since they sometimes look like double-spend attempts. To improve this, find your new transaction in the list of transactions. Right click it and select &quot;copy raw transaction&quot;. Google &quot;Bitcoin pushtx&quot; to find several sites where you can paste this raw transaction to improve propagation.<br />
<br />
==== I received the stuck transaction ====<br />
<br />
In the previous section on choosing an appropriate new fee, you can optionally set NEWTX_SIZE to 193 in order to pay a lower fee.<br />
<br />
This is a bit complicated. Make sure you follow the steps exactly.<br />
<br />
# Generate a new address in the same wallet. We'll call this NEW_ADDR.<br />
# On the Transactions tab, right click the stuck transaction and choose &quot;copy transaction ID&quot;. Paste to a text editor in order to save the value somewhere. We'll call this value STUCK_TX.<br />
# Go to Help -&gt; Debug Window -&gt; Console tab.<br />
# Type &lt;tt&gt;gettransaction STUCK_TX&lt;/tt&gt;. We are going to collect several pieces of data from the output. First, looking at the &quot;details&quot; section, double-check that this actually is the stuck transaction that you're thinking of; if you accidentally selected the wrong transaction, you could lose BTC. Under &quot;details&quot;, call the number next to &quot;vout&quot; STUCK_VOUT; call the number next to &quot;amount&quot; STUCK_AMOUNT. When copying values, do not include quotes.<br />
# From STUCK_AMOUNT, subtract the total fee which you calculated in the first section on this page. Call this number NEW_AMOUNT. For example, if the stuck transaction sends you 1 BTC and you need to add a fee of 0.001 BTC, NEW_AMOUNT is 0.999.<br />
# Type &lt;tt&gt;createrawtransaction '[{&quot;txid&quot;:&quot;STUCK_TX&quot;,&quot;vout&quot;:STUCK_VOUT}]' '{&quot;NEW_ADDR&quot;:NEW_AMOUNT}'&lt;/tt&gt;. Note that you must make four substitutions in this command using variables defined previously. When doing so, do not tamper with the quotes; just replace the variable name such as STUCK_TX with the data. '''Important''': If you do not use the correct value for NEW_AMOUNT as previously described, then you could massively overpay the fee. NEW_AMOUNT should be pretty close to the amount of the stuck transaction.<br />
# (This step is for double-checking only, but should not be skipped.) Call the output of the previous command NEW_RAWTX. Type &lt;tt&gt;decoderawtransaction NEW_RAWTX&lt;/tt&gt;. Under &quot;vout&quot;, check that &quot;value&quot; is equal to NEW_AMOUNT and &quot;addresses&quot; is equal to NEW_ADDR. Double-check that NEW_AMOUNT is not tons less than STUCK_AMOUNT.<br />
# Type &lt;tt&gt;signrawtransaction NEW_RAWTX&lt;/tt&gt;. In the output, copy the data between quotes right after &quot;hex&quot;. Don't copy the quotes themselves, just what's in between them. Call this NEW_RAWTX_SIGNED.<br />
# Type &lt;tt&gt;sendrawtransaction NEW_RAWTX_SIGNED&lt;/tt&gt;. If you get an error, '''discard''' your signed transaction (which may be dangerous) and get help from an expert.<br />
<br />
=== Electrum ===<br />
<br />
As of 2.7.18.<br />
<br />
==== I sent the stuck transaction ====<br />
<br />
If you enabled &quot;Replaceable&quot; when sending the transaction, find the stuck transaction in the History list, right click it, and choose &quot;Increase fee&quot;. Electrum will guide you through it.<br />
<br />
If you did not enable &quot;Replaceable&quot; when sending the transaction:<br />
<br />
# Redo &quot;choosing an appropriate new fee&quot; above using a NEWTX_SIZE of 500.<br />
# Create a new address in the same wallet (or a different one, if you want); call this NEW_ADDR.<br />
# In your transaction history, right click the stuck transaction and select details.<br />
# Under &quot;Outputs&quot;, one of the addresses will usually be highlighted. Copy this address and call it CHANGE_ADDR. If none of the addresses are highlighted, then stop here: you can't use this method.<br />
# Exit the details dialog and go to the &quot;Coins&quot; tab. Find the coin matching the address found above. Right click it and choose &quot;Spend&quot;. If this coin has ''very'' low value, less than what you need to pay in the new fee, then ctrl-click other coins before clicking &quot;spend&quot; in order to add more value.<br />
# Send a transaction to NEW_ADDR (ie. a transaction to yourself) with the new, higher fee. The amount of the transaction doesn't actually matter, but for fee efficiency, it's best to spend all of the BTC associated with CHANGE_ADDR minus the fee.<br />
<br />
==== I received the stuck transaction ====<br />
<br />
Locate the stuck transaction in the Coins tab. Right click -&gt; Spend. Send this transaction with a high fee. You can send it to an address in the same wallet if you want.<br />
<br />
=== Other wallets ===<br />
<br />
==== I sent the stuck transaction ====<br />
<br />
Often it's possible to trick a wallet into bumping fees on sent transactions, but there's no general set of instructions for doing it on all wallets, unfortunately.<br />
<br />
==== I received the stuck transaction ====<br />
<br />
If you're using a &quot;wallet&quot; that is actually a Bitcoin bank (eg. Coinbase, Gemini, etc.), then there's no way to do it.<br />
<br />
For real Bitcoin wallets:<br />
<br />
Send slightly more than the ''confirmed'' balance of your entire wallet to yourself. For example, if you have a 2 BTC confirmed balance and a stuck transaction causing an unconfirmed balance of 0.5 BTC, send 2.01 BTC to yourself. This forces the usage of some of your unconfirmed balance, which is what you want. (Some wallets might not allow this, in which case nothing can be done without switching wallets.) Send this transaction with a very high fee.<br />
<br />
Note that sending your entire balance like this totally destroys your privacy by linking together all of the coins in your wallet.<br />
<br />
[[Category:Guides]]</div>Sgornickhttps://en.bitcoin.it/w/index.php?title=Fee_bumping&diff=65017Fee bumping2018-03-06T00:01:25Z<p>Sgornick: Add link to Child-pays-for-parent subsection of Transaction fees article on first use of that term in this article.</p>
<hr />
<div>The fee required for a transaction to quickly confirm varies according to network conditions. Generally it floats around slowly, but sometimes it shoots up due to spam transactions or a series of randomly-slow blocks. In such cases, you may find that your incoming or outgoing transactions get stuck in 0-conf status for a long time. Wallets ''should'' avoid this in 99% of cases by accurately predicting an appropriate fee, and they ''should'' be able to gracefully bump fees in the remaining 1% of cases, but in general, fees are handled pretty poorly by today's wallets.<br />
<br />
This page gives exact instructions on how to increase the fee on a transaction that is currently stuck in order to make it unstuck. This is always done by creating a new transaction that will either spend the coins sent by the stuck transaction (called [[https://en.bitcoin.it/wiki/Transaction_fees#Feerates_for_dependent_transactions_.28child-pays-for-parent.29|child-pays-for-parent]], or CPFP) or replace the stuck transaction (called [[replace by fee|replace-by-fee]], or RBF). The instructions vary significantly depending on your wallet software. Find your wallet in the table of contents, and then go to the section labeled &quot;I sent the stuck transaction&quot; or &quot;I received the stuck transaction&quot;, as appropriate.<br />
<br />
In some cases, the instructions here become kludgy. Any time you're working outside of the normal wallet GUI, you're doing something that the developer didn't intend, and this could have negative consequences. Although we have tried to give good instructions, we can't guarantee that everything will work perfectly. If your wallet GUI doesn't directly support fee bumping, then the lowest-risk thing for you to do is to not bump the fee, and to just wait. This page is for those situations where you ''can't'' just wait.<br />
<br />
Often, the instructions on this page have to get pretty complicated. As such, we will frequently say stuff like &quot;Take such-and-such value; from now on, we'll call this value XYZ_AMOUNT&quot;. When we say something like this, you should write down in a text editor, &quot;XYZ_AMOUNT=0.123&quot; or similar so that you have the exact value ready for later. And then when we say something like &quot;Type &lt;tt&gt;send &quot;XYZ_AMOUNT&quot;&lt;/tt&gt;&quot;, we mean that you should directly replace the variable name with the value assigned earlier, so in this example it'd be &lt;tt&gt;send &quot;0.123&quot;&lt;/tt&gt;.<br />
<br />
== Choosing an appropriate new fee ==<br />
<br />
# Find the transaction ID (aka txid) of the stuck transaction. Almost all wallets have some way of doing this.<br />
# Search for the txid on https://blockchain.info/<br />
# On blockchain.info, in the footer, click Enable in &quot;Advanced: Enable&quot;. If advanced mode is already enabled so that it instead says &quot;Advanced: Disable&quot;, then don't disable it.<br />
# Write down the &quot;size&quot; number listed under &quot;Summary&quot;. Call this value STUCK_SIZE. Also call the same value TOTAL_SIZE. The reason for having two names for the same thing is that you might later have to add to TOTAL_SIZE, but not to STUCK_SIZE. Separately, write down the &quot;fees&quot; number listed under &quot;Inputs and outputs&quot;, and call this TOTAL_FEES.<br />
# On the left side of the green arrow near the top of the page will be one or more addresses. If any of them have a red U next to it, for each such address, click &quot;Output&quot;.<br />
# For the transactions that it brings you to, add the size to TOTAL_SIZE, and the fees to TOTAL_FEES. Do this for all of the outputs listed with a red U.<br />
# If any of ''those'' transactions also have red 'U's, you have to follow those as well and add their sizes and fees to the running totals. And so on. You might have to go down several layers.<br />
# Now TOTAL_SIZE is the the total size (in bytes) of all unconfirmed ancestors of your stuck transaction, and TOTAL_FEES is the total fees (in BTC) for all unconfirmed ancestors of your stuck transaction.<br />
# Go to https://estimatefee.com/. Around the middle-right of the page it'll say &quot;nnn satoshis/byte&quot;, where nnn is some number. Remember this number as TARGET_FEERATE.<br />
# We need to estimate the additional size of your replacement or CPFP transaction. We'll call this value NEWTX_SIZE. If the transaction you're trying to unstick is one that you sent, estimate NEWTX_SIZE as 100. If the transaction you're trying to unstick is one that you received, estimate NEWTX_SIZE as 500. Later on this page, the section for your specific wallet might give you a different value for NEWTX_SIZE, in which case you should use that value instead.<br />
# Compute the following: [(TARGET_FEERATE / 100000000) * (TOTAL_SIZE + NEWTX_SIZE)] - TOTAL_FEES. The result is an estimate of the '''total''' fee that your new transaction will need to pay in BTC. For mBTC, multiply by 10&lt;sup&gt;-3&lt;/sup&gt;; for bits/uBTC, 10&lt;sup&gt;-6&lt;/sup&gt;; for satoshi, 10&lt;sup&gt;-8&lt;/sup&gt;. This number is '''not''' per kB. If your wallet only allows you to specify fees in BTC/bits/satoshi per kB/byte, multiply the result by one of the following estimated conversion factors (we conservatively assume the worst-case 192-byte transaction for this estimation):<br />
#* BTC/kB: 5.20833333333<br />
#* bits/kB: 5208333.33333<br />
#* satoshi/kB: 520833333.333<br />
#* BTC/byte: 0.00520833333<br />
#* bits/byte: 5208.33333333<br />
#* satoshi/byte: 520833.333333<br />
<br />
If blockchain.info doesn't have your transaction, you can use a different block explorer. blockchain.info is actually notoriously unreliable, but it has the best interface for this particular task. <br />
<br />
Almost certainly, fine-tuning would result in a better fee rate, but the above instructions try to be very general and conservative (in the sense of having the highest chance of unsticking your transaction).<br />
<br />
== Instructions by wallet ==<br />
<br />
=== Bitcoin Core GUI ===<br />
<br />
As of version 0.13.2.<br />
<br />
==== I sent the stuck transaction ====<br />
<br />
This is a bit complicated. Make sure you follow the steps exactly.<br />
<br />
# On the Transactions tab, right click the stuck transaction and choose &quot;copy transaction ID&quot;. Paste to a text editor in order to save the value somewhere. We'll call this value STUCK_TX. Once you've saved STUCK_TX somewhere, right click the stuck transaction again and choose &quot;copy raw transaction&quot;; we'll call this value STUCK_RAWTX.<br />
# Go to Help -&gt; Debug Window -&gt; Console tab. Type &lt;tt&gt;decoderawtransaction STUCK_RAWTX&lt;/tt&gt;. Under &quot;vin&quot; (near the top), find the first &quot;txid&quot; label. Copy the txid next to the &quot;txid&quot; label, and call this STUCK_VIN.<br />
# You need to temporarily break connectivity. Go to Settings -&gt; Options -&gt; Network Tab. Enable &quot;Connect through SOCKS5 proxy (default proxy)&quot;. Change &quot;Proxy IP&quot; and &quot;port&quot; to something that won't actually work; for example, an IP of 127.0.0.1 and a port of 10 is very unlikely to work. If you already have a proxy set up, note down your current settings so that you can restore them later.<br />
# Shut down Bitcoin Core.<br />
# Go to your [[Data directory]] and delete the file &lt;tt&gt;mempool.dat&lt;/tt&gt;. This stops it acting as a cache and reloading your transaction.<br />
# Start Bitcoin Core with the command-line option &lt;tt&gt;-walletbroadcast=0&lt;/tt&gt;. On Linux, you might be able to just run &lt;tt&gt;bitcoin-qt -walletbroadcast=0&lt;/tt&gt;, depending on how your current startup script works. On Windows: find the shortcut for Bitcoin Core on your desktop or start menu; right click it and choose &quot;properties&quot;; add &lt;tt&gt;-walletbroadcast=0&lt;/tt&gt; to the end of &quot;target&quot;, so for example &lt;tt&gt;&quot;C:\Program Files\Bitcoin\bitcoin-qt.exe&quot;&lt;/tt&gt; would become &lt;tt&gt;&quot;C:\Program Files\Bitcoin\bitcoin-qt.exe&quot; -walletbroadcast=0&lt;/tt&gt;; click &quot;Apply&quot;; use that specific shortcut to start Bitcoin Core.<br />
# On the Transactions tab, right click the stuck transaction and choose &quot;abandon transaction&quot;. '''Warning''': Even though the transaction is listed as abandoned, ''it can still go through''. People have in the past lost money by abandoning a transaction, resending a separate replacement transaction, and then having ''both'' transactions go through. The following steps are designed to replace the abandoned transaction in a way which will prevent this sort of double payment from happening.<br />
# Undo the change which broke connectivity: Go to Settings -&gt; Options -&gt; Network Tab. Either disable &quot;Connect through SOCKS5 proxy (default proxy)&quot; or restore your previous proxy settings.<br />
# Restart Bitcoin Core, this time without &lt;tt&gt;-walletbroadcast=0&lt;/tt&gt;.<br />
# Go to Settings -&gt; Options -&gt; Wallet. Ensure that &quot;enable coin control features&quot; is selected, and click OK.<br />
# Go to the Send tab. Click the &quot;Inputs...&quot; button. For each entry in the list, right click it and select &quot;copy transaction ID&quot;, and paste to a text editor. You have to go through the entire list, and for each entry with a txid matching STUCK_VIN, enable the checkbox on the far left. Usually there is only one matching, but if there is more than one, then you have to enable all of them. It is very important that you get this step right.<br />
# In addition to the coins selected in the previous step, which are required, you can select more coins on the Coin Selection dialog if needed. You are creating a transaction that will replace your stuck transaction, so you need to bring &quot;Amount&quot; at the top high enough to send the transaction again, plus fees. Try to select as few as possible, though. Once enough coins are selected, press OK.<br />
# (Optional, makes your new fee more accurate.) In the &quot;Coin Control Features&quot; pane, call the value for &quot;Bytes&quot; NEWTX_BYTES. Referring back to the fee estimation steps in the first section of this page: Set NEWTX_SIZE to be TOTAL_SIZE - STUCK_SIZE + NEWTX_BYTES, where TOTAL_SIZE and STUCK_SIZE were defined back in that section. Do the estimated fee calculation using this NEWTX_SIZE.<br />
# Duplicate all of the settings of the stuck transaction, except for the fee. Instead of using the &quot;recommended&quot; fee, choose custom -&gt; total at least, and then use the amount indicated in this page's fee estimation section. Note that under normal circumstances you should almost always use either the recommended fee or a per-kilobyte custom fee, not &quot;total at least&quot;; this situation is a special case.<br />
# Send the transaction. Either the new transaction or the old transaction should get confirmed (''probably'' the new transaction), but not both if you did the coin control stuff correctly above.<br />
# Sometimes these transactions don't propagate well, since they sometimes look like double-spend attempts. To improve this, find your new transaction in the list of transactions. Right click it and select &quot;copy raw transaction&quot;. Google &quot;Bitcoin pushtx&quot; to find several sites where you can paste this raw transaction to improve propagation.<br />
<br />
==== I received the stuck transaction ====<br />
<br />
In the previous section on choosing an appropriate new fee, you can optionally set NEWTX_SIZE to 193 in order to pay a lower fee.<br />
<br />
This is a bit complicated. Make sure you follow the steps exactly.<br />
<br />
# Generate a new address in the same wallet. We'll call this NEW_ADDR.<br />
# On the Transactions tab, right click the stuck transaction and choose &quot;copy transaction ID&quot;. Paste to a text editor in order to save the value somewhere. We'll call this value STUCK_TX.<br />
# Go to Help -&gt; Debug Window -&gt; Console tab.<br />
# Type &lt;tt&gt;gettransaction STUCK_TX&lt;/tt&gt;. We are going to collect several pieces of data from the output. First, looking at the &quot;details&quot; section, double-check that this actually is the stuck transaction that you're thinking of; if you accidentally selected the wrong transaction, you could lose BTC. Under &quot;details&quot;, call the number next to &quot;vout&quot; STUCK_VOUT; call the number next to &quot;amount&quot; STUCK_AMOUNT. When copying values, do not include quotes.<br />
# From STUCK_AMOUNT, subtract the total fee which you calculated in the first section on this page. Call this number NEW_AMOUNT. For example, if the stuck transaction sends you 1 BTC and you need to add a fee of 0.001 BTC, NEW_AMOUNT is 0.999.<br />
# Type &lt;tt&gt;createrawtransaction '[{&quot;txid&quot;:&quot;STUCK_TX&quot;,&quot;vout&quot;:STUCK_VOUT}]' '{&quot;NEW_ADDR&quot;:NEW_AMOUNT}'&lt;/tt&gt;. Note that you must make four substitutions in this command using variables defined previously. When doing so, do not tamper with the quotes; just replace the variable name such as STUCK_TX with the data. '''Important''': If you do not use the correct value for NEW_AMOUNT as previously described, then you could massively overpay the fee. NEW_AMOUNT should be pretty close to the amount of the stuck transaction.<br />
# (This step is for double-checking only, but should not be skipped.) Call the output of the previous command NEW_RAWTX. Type &lt;tt&gt;decoderawtransaction NEW_RAWTX&lt;/tt&gt;. Under &quot;vout&quot;, check that &quot;value&quot; is equal to NEW_AMOUNT and &quot;addresses&quot; is equal to NEW_ADDR. Double-check that NEW_AMOUNT is not tons less than STUCK_AMOUNT.<br />
# Type &lt;tt&gt;signrawtransaction NEW_RAWTX&lt;/tt&gt;. In the output, copy the data between quotes right after &quot;hex&quot;. Don't copy the quotes themselves, just what's in between them. Call this NEW_RAWTX_SIGNED.<br />
# Type &lt;tt&gt;sendrawtransaction NEW_RAWTX_SIGNED&lt;/tt&gt;. If you get an error, '''discard''' your signed transaction (which may be dangerous) and get help from an expert.<br />
<br />
=== Electrum ===<br />
<br />
As of 2.7.18.<br />
<br />
==== I sent the stuck transaction ====<br />
<br />
If you enabled &quot;Replaceable&quot; when sending the transaction, find the stuck transaction in the History list, right click it, and choose &quot;Increase fee&quot;. Electrum will guide you through it.<br />
<br />
If you did not enable &quot;Replaceable&quot; when sending the transaction:<br />
<br />
# Redo &quot;choosing an appropriate new fee&quot; above using a NEWTX_SIZE of 500.<br />
# Create a new address in the same wallet (or a different one, if you want); call this NEW_ADDR.<br />
# In your transaction history, right click the stuck transaction and select details.<br />
# Under &quot;Outputs&quot;, one of the addresses will usually be highlighted. Copy this address and call it CHANGE_ADDR. If none of the addresses are highlighted, then stop here: you can't use this method.<br />
# Exit the details dialog and go to the &quot;Coins&quot; tab. Find the coin matching the address found above. Right click it and choose &quot;Spend&quot;. If this coin has ''very'' low value, less than what you need to pay in the new fee, then ctrl-click other coins before clicking &quot;spend&quot; in order to add more value.<br />
# Send a transaction to NEW_ADDR (ie. a transaction to yourself) with the new, higher fee. The amount of the transaction doesn't actually matter, but for fee efficiency, it's best to spend all of the BTC associated with CHANGE_ADDR minus the fee.<br />
<br />
==== I received the stuck transaction ====<br />
<br />
Locate the stuck transaction in the Coins tab. Right click -&gt; Spend. Send this transaction with a high fee. You can send it to an address in the same wallet if you want.<br />
<br />
=== Other wallets ===<br />
<br />
==== I sent the stuck transaction ====<br />
<br />
Often it's possible to trick a wallet into bumping fees on sent transactions, but there's no general set of instructions for doing it on all wallets, unfortunately.<br />
<br />
==== I received the stuck transaction ====<br />
<br />
If you're using a &quot;wallet&quot; that is actually a Bitcoin bank (eg. Coinbase, Gemini, etc.), then there's no way to do it.<br />
<br />
For real Bitcoin wallets:<br />
<br />
Send slightly more than the ''confirmed'' balance of your entire wallet to yourself. For example, if you have a 2 BTC confirmed balance and a stuck transaction causing an unconfirmed balance of 0.5 BTC, send 2.01 BTC to yourself. This forces the usage of some of your unconfirmed balance, which is what you want. (Some wallets might not allow this, in which case nothing can be done without switching wallets.) Send this transaction with a very high fee.<br />
<br />
Note that sending your entire balance like this totally destroys your privacy by linking together all of the coins in your wallet.<br />
<br />
[[Category:Guides]]</div>Sgornickhttps://en.bitcoin.it/w/index.php?title=Miner_fees&diff=65016Miner fees2018-03-05T23:59:16Z<p>Sgornick: /* See Also */ Add entry for Replace by fee article.</p>
<hr />
<div>'''Transaction fees''' are a fee that spenders may include in any Bitcoin [[transaction]]. The fee may be collected by the miner who includes the [[transaction]] in a [[block]].<br />
<br />
== Overview ==<br />
<br />
Every Bitcoin transaction spends zero or more bitcoins to zero or more recipients. The difference between the amount being spent and the amount being received is the transaction fee (which must be zero or more).<br />
<br />
Bitcoin's design makes it easy and efficient for the spender to specify how much fee to pay, whereas it would be harder and less efficient for the recipient to specify the fee, so by custom the spender is almost always solely responsible for paying all necessary Bitcoin transaction fees.<br />
<br />
When a miner creates a [[block proposal]], the miner is entitled to specify where all the fees paid by the transactions in that block proposal should be sent. If the proposal results in a valid block that becomes a part of the [[best block chain]], the fee income will be sent to the specified recipient. If a valid block does not collect all available fees, the amount not collected are permanently destroyed; this has happened on more than 1,000 occasions from 2011 to 2017,&lt;ref&gt;[https://medium.com/@alcio/how-to-destroy-bitcoins-255bb6f2142e How to Destroy Bitcoins] by Antoine Le Calvez, Medium.com, retrieved 2018-01-03&lt;/ref&gt;&lt;ref&gt;[https://twitter.com/random_walker/status/948590112576868354 &quot;Looks like back in 2012, when tx fees started becoming common, some miners were claiming the standard 50 BTC and leaving all tx fees unclaimed.&quot;], Arvind Narayanan, Twitter.com, posted 2018-01-03, retrieved 2018-01-03&lt;/ref&gt; with decreasing frequency over time. <br />
<br />
<br />
==The market for block space==<br />
<br />
[[File:fee.png|thumb|Receiving the fees from hundreds of transactions (0.44 BTC)]]<br />
<br />
The minimum fee necessary for a transaction to confirm varies over time and arises from the intersection of supply and demand in Bitcoin's free market for block space.&lt;ref&gt;[https://medium.com/@bramcohen/how-wallets-can-handle-transaction-fees-ff5d020d14fb Bram Cohen blog post with helpful background to the market for block space]&lt;/ref&gt; On the supply size, Bitcoin has a [[maximum block size]] (currently one million vbytes) that limits the maximum amount of transaction data that can be added to a block.<br />
<br />
However, Bitcoin blocks are not produced on a fixed schedule—the system targets an average of one block every 10 minutes over long periods of time but, over short periods of time, a new block can arrive in less than a second or more than an hour after the previous block. As the number of blocks received in a period of time varies, so does the effective maximum block size. For example, in the illustration below we see the average time between blocks based on the time they were received by a node during a one day period (left axis) and the corresponding effective maximum block size implied by that block production rate (right axis, in million [[vbytes]]):<br />
<br />
[[File:Time-between-blocks.png|center]]<br />
<br />
During periods of higher effective maximum block sizes, this natural and unpredictable variability means that transactions with lower fees have a higher than normal chance of getting confirmed—and during periods of lower effective maximum block sizes, low-fee transactions have a lower than normal chance of getting confirmed.<br />
<br />
On the demand side of Bitcoin's free market for block space, each spender is under unique constraints when it comes to spending their bitcoins. Some are willing to pay high fees; some are not. Some desire fast confirmation; some are content with waiting a while. Some use wallets with excellent dynamic fee estimation; some do not. In addition, demand varies according to certain patterns, with perhaps the most recognizable being the weekly cycle where fees increase during weekdays and decrease on the weekend:<br />
<br />
[[File:Block-fees-dow.png|center]]<br />
<br />
Another less recognizable cycle is the intra-day cycle where fees wax and wane during the day:<br />
<br />
[[File:Block-fees-hod.png|center]]<br />
<br />
These variations in supply and demand create a market for block space that allows users to make a trade-off between confirmation time and cost. Users with high time requirements may pay a higher than average transaction fee to be confirmed quickly, while users under less time pressure can save money by being prepared to wait longer for either a natural (but unpredictable) increase in supply or a (somewhat predictable) decrease in demand.<br />
<br />
It is envisioned that over time the cumulative effect of collecting transaction fees will allow those creating new blocks to &quot;earn&quot; more bitcoins than will be mined from new bitcoins created by the new block itself. This is also an incentive to keep trying to create new blocks as the creation of new bitcoins from the mining activity goes towards [[Controlled supply|zero in the future]].&lt;ref&gt;[https://bitcoincore.org/bitcoin.pdf Bitcoin: A Peer-to-Peer Electronic Cash], section 6: Incentive, Satoshi Nakamoto, 2008-11-01, retrieved 2018-01-22&lt;/ref&gt;<br />
<br />
== Feerates ==<br />
<br />
Perhaps the most important factor affecting how fast a transaction gets confirmed is its fee rate (often spelled feerate). This section describes why feerates are important and how to calculate a transaction's feerate.<br />
<br />
Bitcoin transaction vary in size for a variety of reasons. We can easily visualize that by drawing four transactions side-by-side based on their size (length) with each of<br />
our examples larger than the previous one:<br />
<br />
[[File:Feerate1.png|400px|center]]<br />
<br />
This method of illustrating length maxes it easy to also visualize an example maximum block size limit that constrains how much transaction data a miner can add to an individual block:<br />
<br />
[[File:Feerate2.png|400px|center]]<br />
<br />
Since Bitcoin only allows whole transactions to be added to a particular block, at least one of the transactions in the example above can't be added to the next block. So how does a miner select which transactions to include? There's no required selection method (called ''policy'') and no known way to make any particular policy required, but one strategy popular among miners is for each individual miner to attempt to maximize the amount of fee income they can collect from the transactions they include in their blocks.<br />
<br />
We can add a visualization of available fees to our previous illustration by keeping the length of each transaction the same but making the area of the transaction equal to its fee. This makes the height of each transaction equal to the fee divided by the size, which is called the ''feerate:''<br />
<br />
[[File:Feerate3.png|400px|center]]<br />
<br />
Although long (wide) transactions may contain more total fee, the high-feerate (tall) transactions are the most profitable to mine because their area is greatest compared to the amount of space (length) they take up in a block. For example, compare transaction B to transaction D in the illustration above. This means that miners attempting to maximize fee income can get good results by simply sorting by feerate and including as many transactions as possible in a block:<br />
<br />
[[File:Feerate4.png|400px|center]]<br />
<br />
Because only complete transactions can be added to a block, sometimes (as in the example above) the inability to include the incomplete transaction near the end of the block frees up space for one or more smaller and lower-feerate transactions, so when a block gets near full, a profit-maximizing miner will often ignore all remaining transactions that are too large to fit and include the smaller transactions that do fit (still in highest-feerate order):<br />
<br />
[[File:Feerate5.png|400px|center]]<br />
<br />
Excluding some rare and rarely-significant edge cases, the feerate sorting described above maximizes miner revenue for any given block size as long as none of the transactions depend on any of the other transactions being included in the same block (see the next section, ''feerates for dependent transactions,'' for more information about that).<br />
<br />
To calculate the feerate for your transaction, take the fee the transaction pays and divide that by the size of the transaction (currently based on [[weight units]] or [[vbytes]] but no longer based on [[bytes]]). For example, if a transaction pays a fee of 2,250 nanobitcoins and is 225 vbytes in size, its feerate is 2,250 divided by 225, which is 10 nanobitcoins per vbyte (this happens to be the minimum fee [[Bitcoin Core]] Wallet will pay by default).<br />
<br />
When comparing to the feerate between several transactions, ensure that the units used for all of the measurements are the same. For example, some tools calculate size in weight units and others use vbytes; some tools also display fees in a variety of [[Units|denominations]].<br />
<br />
== Feerates for dependent transactions (child-pays-for-parent) ==<br />
<br />
Bitcoin transactions can depend on the inclusion of other transactions in the same block, which complicates the feerate-based transaction selection described above. This section describes the rules of that dependency system, how miners can maximize revenue while managing those dependencies, and how bitcoin spenders can use the dependency system to effectively increase the feerate of unconfirmed transactions.<br />
<br />
Each transaction in a block has a sequential order, one transaction after another. Each block in the block chain also has a sequential order, one block after another. This means that there's a single sequential order to every transaction in the [[best block chain]].<br />
<br />
[[File:Ancestor-feerate1.png|center]]<br />
<br />
One of Bitcoin's [[consensus rules]] is that the transaction where you receive bitcoins must appear earlier in this sequence than the transaction where you spend those bitcoins. For example, if Alice pays Bob in transaction A and Bob uses those same bitcoins to pay Charlie in transaction B, transaction A must appear earlier in the sequence of transactions than transaction B. Often this is easy to accomplish because transaction A appears in an earlier block than transaction B:<br />
<br />
[[File:Ancestor-feerate2.png|center]]<br />
<br />
But if transaction A and B both appear in the same block, the rule still applies: transaction A must appear earlier in the block than transaction B.<br />
<br />
This complicates the task of maximizing fee revenue for miners. Normally, miners would prefer to simply sort transactions by feerate as described in the ''feerate'' section above. But if both transaction A and B are unconfirmed, the miner cannot include B earlier in the block than A even if B pays a higher feerate. This can make sorting by feerate alone less profitable than expected, so a more complex algorithm is needed. Happily, it's only slightly more complex.<br />
<br />
For example, consider the following four transactions that are similar to those analyzed in the preceding ''feerate'' section:<br />
<br />
[[File:Ancestor-feerate3.png|center]]<br />
<br />
To maximize revenue, miners need a way to compare groups of related transactions to each other as well as to individual transactions that have no unconfirmed dependencies. To do that, every transaction available for inclusion in the next block has its feerate calculated for it and all of its unconfirmed ancestors. In the example, this means that transaction B is now considered as a combination of transaction B plus transaction A:<br />
<br />
[[File:Ancestor-feerate4.png|center]]<br />
<br />
Note that this means that unconfirmed ancestor transactions will be considered twice or more, as in the case of transaction A in our example which is considered once as part of the transaction B+A group and once on its own. We'll deal with this complication in a moment.<br />
<br />
These transaction groups are then sorted in feerate order as described in the previous ''feerate'' section:<br />
<br />
[[File:Ancestor-feerate5.png|center]]<br />
<br />
Any individual transaction that appears twice or more in the sorted list has its redundant copies removed. In the example case, we remove the standalone version of transaction A since it's already part of the<br />
transaction B+A group:<br />
<br />
[[File:Ancestor-feerate6.png|center]]<br />
<br />
Finally, we see if we can squeeze in some smaller transactions into the end of the block to avoid wasting space as described in the previous ''feerate'' section. In this case, we can't, so no changes are made.<br />
<br />
Except for some edge cases that are rare and rarely have a significant impact on revenue, this simple and efficient transaction sorting algorithm maximizes miner feerate revenue after factoring in transaction dependencies.<br />
<br />
Note: to ensure the algorithm runs quickly, implementations such as Bitcoin Core limit the maximum number of related transactions that will be collected together for consideration as one group. As of Bitcoin Core 0.15.0 (released late 2017), this is a maximum of 25 transactions, although there have been proposals to increase this amount somewhat.<br />
<br />
For spenders, miner use of transaction grouping means that if you're waiting for an unconfirmed transaction that pays too low a feerate (e.g. transaction A), you can create a child transaction spending an output of that transaction and which pays a much higher feerate (e.g. transaction B) to encourage miners to confirm both transactions in the same block. Wallets that explicitly support this feature often call it ''child pays for parent (CPFP)'' because the child transaction B helps pay for the parent transaction A.<br />
<br />
To calculate the feerate for a transaction group, sum the fees paid by all the the group's unconfirmed transactions and divide that by the sum of the sizes for all those same transactions (in [[weight units]] or [[vbytes]]). For example, if transaction A has a fee of 1,000 nanobitcoins and a size of 250 vbytes and transaction B has a fee of 3,000 nanobitcoins and a size of 150 vbytes, the combined feerate is (1,000 + 3,000)/(250 + 150), which is 10 nanobitcoins per vbyte.<br />
<br />
The idea behind ancestor feerate grouping goes back to at least 2013 and saw several different proposals to add it to Bitcoin Core, with it finally becoming available for production with the August 2016 release of Bitcoin Core 0.13.0.&lt;ref&gt;[https://bitcoincore.org/en/2016/08/23/release-0.13.0/#more-intelligent-transaction-selection-for-mining More intelligent transaction selection for mining], Bitcoin Core 0.13.0 release notes, BitcoinCore.org, 2016-08-23, retrieved 2017-01-14&lt;/ref&gt;<br />
<br />
==Reference Implementation==<br />
<br />
The following sections describe the behavior of the [[Original Bitcoin client|reference implementation]] as of version 0.12.0. Earlier versions treated fees differently, as do other popular implementations (including possible later versions).<br />
<br />
===Sending===<br />
<br />
Users can decide to pay a predefined fee rate by setting `-paytxfee=&lt;n&gt;`<br />
(or `settxfee &lt;n&gt;` rpc during runtime). A value of `n=0` signals Bitcoin<br />
Core to use floating fees. By default, Bitcoin Core will use floating<br />
fees.<br />
<br />
Based on past transaction data, floating fees approximate the fees<br />
required to get into the `m`th block from now. This is configurable<br />
with `-txconfirmtarget=&lt;m&gt;` (default: `2`).<br />
<br />
Sometimes, it is not possible to give good estimates, or an estimate<br />
at all. Therefore, a fallback value can be set with `-fallbackfee=&lt;f&gt;`<br />
(default: `0.0002` BTC/kB).<br />
<br />
At all times, Bitcoin Core will cap fees at `-maxtxfee=&lt;x&gt;` (default:<br />
0.10) BTC.<br />
Furthermore, Bitcoin Core will never create transactions smaller than<br />
the current minimum relay fee.<br />
Finally, a user can set the minimum fee rate for all transactions with<br />
`-mintxfee=&lt;&lt;nowiki&gt;i&lt;/nowiki&gt;&gt;`, which defaults to 1000 satoshis per kB.<br />
<br />
<br />
Note that a typical transaction is 500 bytes.<br />
<br />
===Including in Blocks===<br />
<br />
This section describes how the reference implementation selects which transactions to put into new blocks, with default settings. All of the settings may be changed if a miner wants to create larger or smaller blocks containing more or fewer free transactions.<br />
<br />
Then transactions that pay a fee of at least 0.00001 BTC/kb are added to the block, highest-fee-per-kilobyte transactions first, until the block is not more than 750,000 bytes big.<br />
<br />
The remaining transactions remain in the miner's &quot;memory pool&quot;, and may be included in later blocks if their priority or fee is large enough.<br />
<br />
For Bitcoin Core 0.12.0 zero bytes&lt;ref&gt;https://github.com/bitcoin/bitcoin/blob/v0.12.0/doc/release-notes.md#relay-and-mining-priority-transactions&lt;/ref&gt; in the block are set aside for the highest-[[Transaction_fees#Priority_transactions|priority transactions]]. Transactions are added highest-priority-first to this section of the block.<br />
<br />
===Relaying===<br />
<br />
The reference implementation's rules for relaying transactions across the peer-to-peer network are very similar to the rules for sending transactions, as a value of 0.00001 BTC is used to determine whether or not a transaction is considered &quot;Free&quot;. However, the rule that all outputs must be 0.01 BTC or larger does not apply. To prevent &quot;penny-flooding&quot; denial-of-service attacks on the network, the reference implementation caps the number of free transactions it will relay to other nodes to (by default) 15 thousand bytes per minute.<br />
<br />
===Settings===<br />
<br />
{| class=&quot;wikitable&quot;<br />
|-<br />
! Setting !! Default Value (units)<br />
|-<br />
| txconfirmtarget || 2 (blocks)<br />
|-<br />
| paytxfee || 0 (BTC/kB)<br />
|-<br />
| mintxfee || 0.00001 (BTC/kB)<br />
|-<br />
| limitfreerelay || 15 (thousand bytes per minute)<br />
|-<br />
| minrelaytxfee || 0.00001 (BTC/kB)<br />
|-<br />
| blockmaxsize || 750000 (bytes)<br />
|-<br />
| blockminsize || 0 (bytes)<br />
|-<br />
| blockprioritysize || 0 (bytes)<br />
|}<br />
<br />
==Fee Plotting Sites==<br />
<br />
As of May 2016, the following sites seem to plot the required fee, in satoshi per (kilo)byte, required to get a transaction mined in a certain number of blocks. Note that all these algorithms work in terms of probabilities.<br />
<br />
* https://bitcoinfees.21.co/<br />
* https://bitcoinfees.github.io/<br />
* https://statoshi.info/dashboard/db/fee-estimates<br />
* http://p2sh.info/dashboard/db/fee-estimation<br />
* https://www.bitcoinqueue.com/2d.html<br />
<br />
=== Other Useful Sites ===<br />
<br />
* https://anduck.net/bitcoin/fees/ - Shows what kind of fees filled up recent blocks<br />
* https://btc.com/stats/unconfirmed-tx - the state of the website's mempool broken down by fee rate<br />
* https://jochen-hoenicke.de/queue/#1w - another mempool broken down by fee rate site<br />
* https://esotericnonsense.com/ - yet another mempool site, also very good<br />
* http://mempool.us.to/tx.html - Tells you where a unconfirmed txid is in the queue based on its fee rate (Note that not all miners use the same algorithm)<br />
* https://estimatefee.com/ - You can click any of the transactions in that graph to get more info (like its &quot;effective fee rate&quot; which uses recursive ancestors/descendants for CPFP) and an estimated amount of blocks it'll take to confirm. It works with any transaction in the top 100MB of the bitcoin mempool. And you can enter in any transaction txid for info when you'er wondering why it doesn't confirm.<br />
<br />
==Priority transactions==<br />
<br />
Historically it was not required to include a fee for every transaction. A large portion of miners would mine transactions with no fee given that they had enough &quot;priority&quot;. Today, low priority is mostly used as an indicator for spam transactions and almost all miners expect every transaction to include a fee. Today miners choose which transactions to mine only based on fee-rate.<br />
<br />
Transaction priority was calculated as a value-weighted sum of input age, divided by transaction size in bytes:<br />
priority = sum(input_value_in_base_units * input_age)/size_in_bytes<br />
Transactions needed to have a priority above 57,600,000 to avoid the enforced limit (as of client version 0.3.21). This threshold was written in the code as COIN * 144 / 250, suggesting that the threshold represents a one day old, 1 btc coin (144 is the expected number of blocks per day) and a transaction size of 250 bytes.<br />
<br />
So, for example, a transaction that has 2 inputs, one of 5 btc with 10 confirmations, and one of 2 btc with 3 confirmations, and has a size of 500bytes, will have a priority of<br />
(500000000 * 10 + 200000000 * 3) / 500 = 11,200,000<br />
<br />
===Historic rules for free transactions===<br />
A transaction was safe to send without fees if these conditions were met:<br />
<br />
* It is smaller than 1,000 bytes.<br />
* All outputs are 0.01 BTC or larger.<br />
* Its priority is large enough (see above)<br />
<br />
==See Also==<br />
<br />
* [[Free transaction relay policy]]<br />
* [[Fee bumping]]<br />
* [[Replace by fee]]<br />
* [http://bitcoinexchangerate.org/fees Unconfirmed transactions fee chart]<br />
* [https://jochen-hoenicke.de/queue/ historic fees and mempools]<br />
<br />
==References==<br />
&lt;references /&gt;<br />
<br />
[[Category:Technical]]<br />
[[Category:Vocabulary]]<br />
[[Category:Mining]]<br />
[[de:Transaktionsgebühren]]<br />
<br />
{{Bitcoin Core documentation}}</div>Sgornickhttps://en.bitcoin.it/w/index.php?title=Fee_bumping&diff=65015Fee bumping2018-03-05T23:57:28Z<p>Sgornick: Add link to Replace by fee article on first use of that term.</p>
<hr />
<div>The fee required for a transaction to quickly confirm varies according to network conditions. Generally it floats around slowly, but sometimes it shoots up due to spam transactions or a series of randomly-slow blocks. In such cases, you may find that your incoming or outgoing transactions get stuck in 0-conf status for a long time. Wallets ''should'' avoid this in 99% of cases by accurately predicting an appropriate fee, and they ''should'' be able to gracefully bump fees in the remaining 1% of cases, but in general, fees are handled pretty poorly by today's wallets.<br />
<br />
This page gives exact instructions on how to increase the fee on a transaction that is currently stuck in order to make it unstuck. This is always done by creating a new transaction that will either spend the coins sent by the stuck transaction (called CPFP) or replace the stuck transaction (called [[replace by fee|replace-by-fee]] or RBF). The instructions vary significantly depending on your wallet software. Find your wallet in the table of contents, and then go to the section labeled &quot;I sent the stuck transaction&quot; or &quot;I received the stuck transaction&quot;, as appropriate.<br />
<br />
In some cases, the instructions here become kludgy. Any time you're working outside of the normal wallet GUI, you're doing something that the developer didn't intend, and this could have negative consequences. Although we have tried to give good instructions, we can't guarantee that everything will work perfectly. If your wallet GUI doesn't directly support fee bumping, then the lowest-risk thing for you to do is to not bump the fee, and to just wait. This page is for those situations where you ''can't'' just wait.<br />
<br />
Often, the instructions on this page have to get pretty complicated. As such, we will frequently say stuff like &quot;Take such-and-such value; from now on, we'll call this value XYZ_AMOUNT&quot;. When we say something like this, you should write down in a text editor, &quot;XYZ_AMOUNT=0.123&quot; or similar so that you have the exact value ready for later. And then when we say something like &quot;Type &lt;tt&gt;send &quot;XYZ_AMOUNT&quot;&lt;/tt&gt;&quot;, we mean that you should directly replace the variable name with the value assigned earlier, so in this example it'd be &lt;tt&gt;send &quot;0.123&quot;&lt;/tt&gt;.<br />
<br />
== Choosing an appropriate new fee ==<br />
<br />
# Find the transaction ID (aka txid) of the stuck transaction. Almost all wallets have some way of doing this.<br />
# Search for the txid on https://blockchain.info/<br />
# On blockchain.info, in the footer, click Enable in &quot;Advanced: Enable&quot;. If advanced mode is already enabled so that it instead says &quot;Advanced: Disable&quot;, then don't disable it.<br />
# Write down the &quot;size&quot; number listed under &quot;Summary&quot;. Call this value STUCK_SIZE. Also call the same value TOTAL_SIZE. The reason for having two names for the same thing is that you might later have to add to TOTAL_SIZE, but not to STUCK_SIZE. Separately, write down the &quot;fees&quot; number listed under &quot;Inputs and outputs&quot;, and call this TOTAL_FEES.<br />
# On the left side of the green arrow near the top of the page will be one or more addresses. If any of them have a red U next to it, for each such address, click &quot;Output&quot;.<br />
# For the transactions that it brings you to, add the size to TOTAL_SIZE, and the fees to TOTAL_FEES. Do this for all of the outputs listed with a red U.<br />
# If any of ''those'' transactions also have red 'U's, you have to follow those as well and add their sizes and fees to the running totals. And so on. You might have to go down several layers.<br />
# Now TOTAL_SIZE is the the total size (in bytes) of all unconfirmed ancestors of your stuck transaction, and TOTAL_FEES is the total fees (in BTC) for all unconfirmed ancestors of your stuck transaction.<br />
# Go to https://estimatefee.com/. Around the middle-right of the page it'll say &quot;nnn satoshis/byte&quot;, where nnn is some number. Remember this number as TARGET_FEERATE.<br />
# We need to estimate the additional size of your replacement or CPFP transaction. We'll call this value NEWTX_SIZE. If the transaction you're trying to unstick is one that you sent, estimate NEWTX_SIZE as 100. If the transaction you're trying to unstick is one that you received, estimate NEWTX_SIZE as 500. Later on this page, the section for your specific wallet might give you a different value for NEWTX_SIZE, in which case you should use that value instead.<br />
# Compute the following: [(TARGET_FEERATE / 100000000) * (TOTAL_SIZE + NEWTX_SIZE)] - TOTAL_FEES. The result is an estimate of the '''total''' fee that your new transaction will need to pay in BTC. For mBTC, multiply by 10&lt;sup&gt;-3&lt;/sup&gt;; for bits/uBTC, 10&lt;sup&gt;-6&lt;/sup&gt;; for satoshi, 10&lt;sup&gt;-8&lt;/sup&gt;. This number is '''not''' per kB. If your wallet only allows you to specify fees in BTC/bits/satoshi per kB/byte, multiply the result by one of the following estimated conversion factors (we conservatively assume the worst-case 192-byte transaction for this estimation):<br />
#* BTC/kB: 5.20833333333<br />
#* bits/kB: 5208333.33333<br />
#* satoshi/kB: 520833333.333<br />
#* BTC/byte: 0.00520833333<br />
#* bits/byte: 5208.33333333<br />
#* satoshi/byte: 520833.333333<br />
<br />
If blockchain.info doesn't have your transaction, you can use a different block explorer. blockchain.info is actually notoriously unreliable, but it has the best interface for this particular task. <br />
<br />
Almost certainly, fine-tuning would result in a better fee rate, but the above instructions try to be very general and conservative (in the sense of having the highest chance of unsticking your transaction).<br />
<br />
== Instructions by wallet ==<br />
<br />
=== Bitcoin Core GUI ===<br />
<br />
As of version 0.13.2.<br />
<br />
==== I sent the stuck transaction ====<br />
<br />
This is a bit complicated. Make sure you follow the steps exactly.<br />
<br />
# On the Transactions tab, right click the stuck transaction and choose &quot;copy transaction ID&quot;. Paste to a text editor in order to save the value somewhere. We'll call this value STUCK_TX. Once you've saved STUCK_TX somewhere, right click the stuck transaction again and choose &quot;copy raw transaction&quot;; we'll call this value STUCK_RAWTX.<br />
# Go to Help -&gt; Debug Window -&gt; Console tab. Type &lt;tt&gt;decoderawtransaction STUCK_RAWTX&lt;/tt&gt;. Under &quot;vin&quot; (near the top), find the first &quot;txid&quot; label. Copy the txid next to the &quot;txid&quot; label, and call this STUCK_VIN.<br />
# You need to temporarily break connectivity. Go to Settings -&gt; Options -&gt; Network Tab. Enable &quot;Connect through SOCKS5 proxy (default proxy)&quot;. Change &quot;Proxy IP&quot; and &quot;port&quot; to something that won't actually work; for example, an IP of 127.0.0.1 and a port of 10 is very unlikely to work. If you already have a proxy set up, note down your current settings so that you can restore them later.<br />
# Shut down Bitcoin Core.<br />
# Go to your [[Data directory]] and delete the file &lt;tt&gt;mempool.dat&lt;/tt&gt;. This stops it acting as a cache and reloading your transaction.<br />
# Start Bitcoin Core with the command-line option &lt;tt&gt;-walletbroadcast=0&lt;/tt&gt;. On Linux, you might be able to just run &lt;tt&gt;bitcoin-qt -walletbroadcast=0&lt;/tt&gt;, depending on how your current startup script works. On Windows: find the shortcut for Bitcoin Core on your desktop or start menu; right click it and choose &quot;properties&quot;; add &lt;tt&gt;-walletbroadcast=0&lt;/tt&gt; to the end of &quot;target&quot;, so for example &lt;tt&gt;&quot;C:\Program Files\Bitcoin\bitcoin-qt.exe&quot;&lt;/tt&gt; would become &lt;tt&gt;&quot;C:\Program Files\Bitcoin\bitcoin-qt.exe&quot; -walletbroadcast=0&lt;/tt&gt;; click &quot;Apply&quot;; use that specific shortcut to start Bitcoin Core.<br />
# On the Transactions tab, right click the stuck transaction and choose &quot;abandon transaction&quot;. '''Warning''': Even though the transaction is listed as abandoned, ''it can still go through''. People have in the past lost money by abandoning a transaction, resending a separate replacement transaction, and then having ''both'' transactions go through. The following steps are designed to replace the abandoned transaction in a way which will prevent this sort of double payment from happening.<br />
# Undo the change which broke connectivity: Go to Settings -&gt; Options -&gt; Network Tab. Either disable &quot;Connect through SOCKS5 proxy (default proxy)&quot; or restore your previous proxy settings.<br />
# Restart Bitcoin Core, this time without &lt;tt&gt;-walletbroadcast=0&lt;/tt&gt;.<br />
# Go to Settings -&gt; Options -&gt; Wallet. Ensure that &quot;enable coin control features&quot; is selected, and click OK.<br />
# Go to the Send tab. Click the &quot;Inputs...&quot; button. For each entry in the list, right click it and select &quot;copy transaction ID&quot;, and paste to a text editor. You have to go through the entire list, and for each entry with a txid matching STUCK_VIN, enable the checkbox on the far left. Usually there is only one matching, but if there is more than one, then you have to enable all of them. It is very important that you get this step right.<br />
# In addition to the coins selected in the previous step, which are required, you can select more coins on the Coin Selection dialog if needed. You are creating a transaction that will replace your stuck transaction, so you need to bring &quot;Amount&quot; at the top high enough to send the transaction again, plus fees. Try to select as few as possible, though. Once enough coins are selected, press OK.<br />
# (Optional, makes your new fee more accurate.) In the &quot;Coin Control Features&quot; pane, call the value for &quot;Bytes&quot; NEWTX_BYTES. Referring back to the fee estimation steps in the first section of this page: Set NEWTX_SIZE to be TOTAL_SIZE - STUCK_SIZE + NEWTX_BYTES, where TOTAL_SIZE and STUCK_SIZE were defined back in that section. Do the estimated fee calculation using this NEWTX_SIZE.<br />
# Duplicate all of the settings of the stuck transaction, except for the fee. Instead of using the &quot;recommended&quot; fee, choose custom -&gt; total at least, and then use the amount indicated in this page's fee estimation section. Note that under normal circumstances you should almost always use either the recommended fee or a per-kilobyte custom fee, not &quot;total at least&quot;; this situation is a special case.<br />
# Send the transaction. Either the new transaction or the old transaction should get confirmed (''probably'' the new transaction), but not both if you did the coin control stuff correctly above.<br />
# Sometimes these transactions don't propagate well, since they sometimes look like double-spend attempts. To improve this, find your new transaction in the list of transactions. Right click it and select &quot;copy raw transaction&quot;. Google &quot;Bitcoin pushtx&quot; to find several sites where you can paste this raw transaction to improve propagation.<br />
<br />
==== I received the stuck transaction ====<br />
<br />
In the previous section on choosing an appropriate new fee, you can optionally set NEWTX_SIZE to 193 in order to pay a lower fee.<br />
<br />
This is a bit complicated. Make sure you follow the steps exactly.<br />
<br />
# Generate a new address in the same wallet. We'll call this NEW_ADDR.<br />
# On the Transactions tab, right click the stuck transaction and choose &quot;copy transaction ID&quot;. Paste to a text editor in order to save the value somewhere. We'll call this value STUCK_TX.<br />
# Go to Help -&gt; Debug Window -&gt; Console tab.<br />
# Type &lt;tt&gt;gettransaction STUCK_TX&lt;/tt&gt;. We are going to collect several pieces of data from the output. First, looking at the &quot;details&quot; section, double-check that this actually is the stuck transaction that you're thinking of; if you accidentally selected the wrong transaction, you could lose BTC. Under &quot;details&quot;, call the number next to &quot;vout&quot; STUCK_VOUT; call the number next to &quot;amount&quot; STUCK_AMOUNT. When copying values, do not include quotes.<br />
# From STUCK_AMOUNT, subtract the total fee which you calculated in the first section on this page. Call this number NEW_AMOUNT. For example, if the stuck transaction sends you 1 BTC and you need to add a fee of 0.001 BTC, NEW_AMOUNT is 0.999.<br />
# Type &lt;tt&gt;createrawtransaction '[{&quot;txid&quot;:&quot;STUCK_TX&quot;,&quot;vout&quot;:STUCK_VOUT}]' '{&quot;NEW_ADDR&quot;:NEW_AMOUNT}'&lt;/tt&gt;. Note that you must make four substitutions in this command using variables defined previously. When doing so, do not tamper with the quotes; just replace the variable name such as STUCK_TX with the data. '''Important''': If you do not use the correct value for NEW_AMOUNT as previously described, then you could massively overpay the fee. NEW_AMOUNT should be pretty close to the amount of the stuck transaction.<br />
# (This step is for double-checking only, but should not be skipped.) Call the output of the previous command NEW_RAWTX. Type &lt;tt&gt;decoderawtransaction NEW_RAWTX&lt;/tt&gt;. Under &quot;vout&quot;, check that &quot;value&quot; is equal to NEW_AMOUNT and &quot;addresses&quot; is equal to NEW_ADDR. Double-check that NEW_AMOUNT is not tons less than STUCK_AMOUNT.<br />
# Type &lt;tt&gt;signrawtransaction NEW_RAWTX&lt;/tt&gt;. In the output, copy the data between quotes right after &quot;hex&quot;. Don't copy the quotes themselves, just what's in between them. Call this NEW_RAWTX_SIGNED.<br />
# Type &lt;tt&gt;sendrawtransaction NEW_RAWTX_SIGNED&lt;/tt&gt;. If you get an error, '''discard''' your signed transaction (which may be dangerous) and get help from an expert.<br />
<br />
=== Electrum ===<br />
<br />
As of 2.7.18.<br />
<br />
==== I sent the stuck transaction ====<br />
<br />
If you enabled &quot;Replaceable&quot; when sending the transaction, find the stuck transaction in the History list, right click it, and choose &quot;Increase fee&quot;. Electrum will guide you through it.<br />
<br />
If you did not enable &quot;Replaceable&quot; when sending the transaction:<br />
<br />
# Redo &quot;choosing an appropriate new fee&quot; above using a NEWTX_SIZE of 500.<br />
# Create a new address in the same wallet (or a different one, if you want); call this NEW_ADDR.<br />
# In your transaction history, right click the stuck transaction and select details.<br />
# Under &quot;Outputs&quot;, one of the addresses will usually be highlighted. Copy this address and call it CHANGE_ADDR. If none of the addresses are highlighted, then stop here: you can't use this method.<br />
# Exit the details dialog and go to the &quot;Coins&quot; tab. Find the coin matching the address found above. Right click it and choose &quot;Spend&quot;. If this coin has ''very'' low value, less than what you need to pay in the new fee, then ctrl-click other coins before clicking &quot;spend&quot; in order to add more value.<br />
# Send a transaction to NEW_ADDR (ie. a transaction to yourself) with the new, higher fee. The amount of the transaction doesn't actually matter, but for fee efficiency, it's best to spend all of the BTC associated with CHANGE_ADDR minus the fee.<br />
<br />
==== I received the stuck transaction ====<br />
<br />
Locate the stuck transaction in the Coins tab. Right click -&gt; Spend. Send this transaction with a high fee. You can send it to an address in the same wallet if you want.<br />
<br />
=== Other wallets ===<br />
<br />
==== I sent the stuck transaction ====<br />
<br />
Often it's possible to trick a wallet into bumping fees on sent transactions, but there's no general set of instructions for doing it on all wallets, unfortunately.<br />
<br />
==== I received the stuck transaction ====<br />
<br />
If you're using a &quot;wallet&quot; that is actually a Bitcoin bank (eg. Coinbase, Gemini, etc.), then there's no way to do it.<br />
<br />
For real Bitcoin wallets:<br />
<br />
Send slightly more than the ''confirmed'' balance of your entire wallet to yourself. For example, if you have a 2 BTC confirmed balance and a stuck transaction causing an unconfirmed balance of 0.5 BTC, send 2.01 BTC to yourself. This forces the usage of some of your unconfirmed balance, which is what you want. (Some wallets might not allow this, in which case nothing can be done without switching wallets.) Send this transaction with a very high fee.<br />
<br />
Note that sending your entire balance like this totally destroys your privacy by linking together all of the coins in your wallet.<br />
<br />
[[Category:Guides]]</div>Sgornickhttps://en.bitcoin.it/w/index.php?title=Transaction_replacement&diff=65014Transaction replacement2018-03-05T23:55:07Z<p>Sgornick: /* See Also */ Add entry for Fee bumping, which is not related to RBF but is an alternative to RBF that might be considered.</p>
<hr />
<div>'''Transaction replaceability''' occurs when a full node allows one or<br />
more of the transactions in its memory pool (mempool) to be replaced<br />
with a different transaction that spends some or all of the same inputs.<br />
Transaction replaceability was enabled in the first version of<br />
Bitcoin&lt;ref&gt;[https://github.com/trottier/original-bitcoin/blob/master/src/main.cpp#L434 Replacement in original Bitcoin source code], Satoshi Nakamoto, GitHub, ''Retrieved 2015-12-08''&lt;/ref&gt; but was disabled in the 0.3.12 release with the comment,<br />
&quot;Disable replacement feature for now&quot;.&lt;ref&gt;[https://github.com/bitcoin/bitcoin/commit/05454818dc7ed92f577a1a1ef6798049f17a52e7#diff-118fcbaaba162ba17933c7893247df3aR522 Commit disabling replacement &quot;for now&quot;], Satoshi Nakamoto, GitHub, ''Retrieved 2015-12-08''&lt;/ref&gt; Since then, there have been various attempts to make<br />
transaction replaceability widely available again.&lt;ref&gt;[https://bitcointalk.org/index.php?topic=199947.0 Initial replace-by-fee implementation available for testnet], BitcoinTalk forum, posted 2013-05-09, ''retrieved 2015-12-09''&lt;/ref&gt;<br />
<br />
Beginning with Bitcoin Core 0.12.0 (eta Feb 1 2016), it is expected<br />
that one type of transaction replaceability, [[Replace by fee|replace-by-fee]] (RBF), will become widely available. This page<br />
attempts to document the current state of transaction replaceability for<br />
wallet authors who want to use that feature.<br />
<br />
== Node policies ==<br />
<br />
Transaction replacement is optional (it is not, and cannot be,<br />
a consensus rule), but widespread adherence to the same basic policy<br />
among nodes will help maintain a consistent network-wide mempool policy<br />
with the following expected benefits:<br />
<br />
* Consistent policy makes it easy for wallet authors to write code that uses transaction replacement to provide usability-enhancing features.<br />
<br />
* Consistent policy helps ensure long-running mempools contain mostly the same transactions (mempool consistency), which makes it easier for wallets and nodes to make guesses about how long it will take a transaction to confirm.<br />
<br />
* Consistent mempools may help nodes more quickly validate newly-received blocks as well as reduce the bandwidth used to announce new blocks in the future.<br />
<br />
=== Bitcoin Core 0.3.12 to 0.11.x ===<br />
<br />
Transaction replaceability is disallowed in a running node.<br />
<br />
=== Bitcoin Core 0.12.0 ===<br />
<br />
''Bitcoin Core 0.12.0 has been released in Feb 2016.''<br />
<br />
Bitcoin Core 0.12.0 uses the initial implementation of opt-in full-RBF<br />
described in [https://github.com/bitcoin/bips/blob/master/bip-0125.mediawiki BIP 125].<br />
<br />
The initial implementation of opt-in full-RBF may be seen in <br />
[https://github.com/bitcoin/bitcoin/pull/6871 Bitcoin Core PR#6871]<br />
and specifically the master branch commits from<br />
5891f870d68d90408aa5ce5b597fb574f2d2cbca to<br />
16a2f93629f75d182871f288f0396afe6cdc8504 (inclusive).<br />
<br />
=== Peter Todd's full-RBF patchset ===<br />
<br />
Peter Todd has historically maintained patchsets against Bitcoin Core<br />
0.8.x and later that implement full-RBF for all transactions in the<br />
mempool. (Later versions also provide an option to enable RBF First-Seen-Safe (RBF-FSS) only.)<br />
A rebased version of the most recent patch is also available for<br />
contemporary [http://luke.dashjr.org/programs/bitcoin-ljr/ Bitcoin LJR] releases.<br />
<br />
Notably, the patchset also implements preferential peering that allows<br />
nodes implementing full-RBF to connect to each other so that replacements <br />
can circulate even if full-RBF nodes represent a small minority of the<br />
network.<br />
<br />
As of 2015-12-08, there are no known large miners or mining pools that<br />
implement full-RBF.<br />
<br />
* [https://github.com/petertodd/bitcoin/branches/all?utf8=%E2%9C%93&amp;query=replace-by-fee-v0.10 Replace by fee patches for Bitcoin Core 0.10.x]<br />
* [https://github.com/petertodd/bitcoin/branches/all?utf8=%E2%9C%93&amp;query=replace-by-fee-v0.11 Replace by fee patches for Bitcoin Core 0.11.x]<br />
<br />
Policy&lt;ref&gt;[https://github.com/bitcoin/bitcoin/compare/0.11...petertodd:replace-by-fee-v0.11.0 RBF patchset for 0.11.2], Peter Todd, GitHub, ''Retrieved 2015-12-08''&lt;/ref&gt;: one or more transactions currently in the mempool (original<br />
transactions) will be replaced by a new transaction (replacement<br />
transaction) that spends one or more of the same inputs if,<br />
<br />
# The replacement transaction pays an absolute higher fee than the original transactions.<br />
# The replacement transaction must pay for its own bandwidth in addition to the amount paid by the original transactions at least by the rate set by the node's minimum relay fee setting. For example, if the minimum relay fee is 1 satoshi/byte and the replacement transaction is 500 bytes total, then the replacement must pay a fee at least 500 satoshis higher than the originals.<br />
# No more than 100 original transactions are replaced by the replacement transaction<br />
<br />
== See Also ==<br />
<br />
* [[Fee bumping]]<br />
* [https://github.com/bitcoin/bips/blob/master/bip-0125.mediawiki BIP 125]<br />
* [https://www.reddit.com/r/Bitcoin/comments/3urm8o/optin_rbf_is_misunderstood_ask_questions_about_it/ Reddit: Questions about opt-in RBF]<br />
<br />
== References ==<br />
<br />
&lt;references /&gt;</div>Sgornickhttps://en.bitcoin.it/w/index.php?title=Replace_by_fee&diff=65013Replace by fee2018-03-05T23:51:57Z<p>Sgornick: Add reference to Transaction replacement article on first use of term in this article.</p>
<hr />
<div>Since Bitcoin's original inception, it has supported the concept that an unconfirmed transaction may be modified and re-issued.<br />
This concept is known as &quot;[[transaction replacement]]&quot;, because the new transaction replaces the old one.<br />
However, since transaction replacement eliminates the cost to all previous transactions being replaced, it created a DoS risk:<br />
attackers could produce as many transactions as they wanted, while only paying the fee for the one variant that was eventually mined.<br />
<br />
To solve this problem, the concept of replace-by-fee was developed:<br />
by requiring replacements to pay for not only its own cost, but also the fee of the transactions being replaced, the DoS risk was strictly less than the risk of flooding with separate transactions.<br />
<br />
==Variants==<br />
<br />
Replace-by-fee is a node policy that comes in multiple variants:<br />
<br />
===Full RBF===<br />
<br />
So-called &quot;full RBF&quot; unconditionally allows a transaction to replace older ones so long as it pays a sufficient fee.<br />
<br />
===First-seen-safe RBF===<br />
<br />
The &quot;first-seen-safe&quot; variant only allows the replacement if an additional criteria is met:<br />
the replacement transaction must pay all the same outputs as the transactions being replaced.<br />
<br />
This variant was created to counter the [[#Criticism|accusation that RBF enabled double spend attacks]], by preventing such attacks from making use of RBF.<br />
<br />
One downside of this variant, is that the [[change]] output is necessarily treated as a payment, and cannot be reduced.<br />
This results in larger transaction sizes (as additional inputs must be added) and therefore fees.<br />
<br />
===Opt-in RBF===<br />
<br />
The &quot;opt-in&quot; variant only allows the replacement when the transactions being replaced have explicitly signalled they allow replacement.<br />
This signalling is done via the &quot;sequence&quot; field, and defined by [https://github.com/bitcoin/bips/blob/master/bip-0125.mediawiki BIP 125].<br />
<br />
One downside of this variant is that users must know in advance when they may wish to replace a transaction.<br />
As a result, opt-in RBF is often used as a default even when it might otherwise not be needed.<br />
<br />
===Delayed RBF===<br />
<br />
Delayed RBF is a variant which allows transactions to be replaced unconditionally, but only after a given number of blocks have been mined since the replaced transactions were first seen by the node.<br />
<br />
==Criticism==<br />
<br />
Some people believe transaction replacement harms Bitcoin by enabling double spend attacks, where an attacker sends bitcoins, but then replaces that transaction with one taking them back.<br />
<br />
However, this criticism does not hold up: double spend attacks are entirely possible without RBF.</div>Sgornickhttps://en.bitcoin.it/w/index.php?title=Transaction_replacement&diff=65012Transaction replacement2018-03-05T23:50:36Z<p>Sgornick: Add phrase Replace by fee as a form of transaction replacement, and link to that wiki article.</p>
<hr />
<div>'''Transaction replaceability''' occurs when a full node allows one or<br />
more of the transactions in its memory pool (mempool) to be replaced<br />
with a different transaction that spends some or all of the same inputs.<br />
Transaction replaceability was enabled in the first version of<br />
Bitcoin&lt;ref&gt;[https://github.com/trottier/original-bitcoin/blob/master/src/main.cpp#L434 Replacement in original Bitcoin source code], Satoshi Nakamoto, GitHub, ''Retrieved 2015-12-08''&lt;/ref&gt; but was disabled in the 0.3.12 release with the comment,<br />
&quot;Disable replacement feature for now&quot;.&lt;ref&gt;[https://github.com/bitcoin/bitcoin/commit/05454818dc7ed92f577a1a1ef6798049f17a52e7#diff-118fcbaaba162ba17933c7893247df3aR522 Commit disabling replacement &quot;for now&quot;], Satoshi Nakamoto, GitHub, ''Retrieved 2015-12-08''&lt;/ref&gt; Since then, there have been various attempts to make<br />
transaction replaceability widely available again.&lt;ref&gt;[https://bitcointalk.org/index.php?topic=199947.0 Initial replace-by-fee implementation available for testnet], BitcoinTalk forum, posted 2013-05-09, ''retrieved 2015-12-09''&lt;/ref&gt;<br />
<br />
Beginning with Bitcoin Core 0.12.0 (eta Feb 1 2016), it is expected<br />
that one type of transaction replaceability, [[Replace by fee|replace-by-fee]] (RBF), will become widely available. This page<br />
attempts to document the current state of transaction replaceability for<br />
wallet authors who want to use that feature.<br />
<br />
== Node policies ==<br />
<br />
Transaction replacement is optional (it is not, and cannot be,<br />
a consensus rule), but widespread adherence to the same basic policy<br />
among nodes will help maintain a consistent network-wide mempool policy<br />
with the following expected benefits:<br />
<br />
* Consistent policy makes it easy for wallet authors to write code that uses transaction replacement to provide usability-enhancing features.<br />
<br />
* Consistent policy helps ensure long-running mempools contain mostly the same transactions (mempool consistency), which makes it easier for wallets and nodes to make guesses about how long it will take a transaction to confirm.<br />
<br />
* Consistent mempools may help nodes more quickly validate newly-received blocks as well as reduce the bandwidth used to announce new blocks in the future.<br />
<br />
=== Bitcoin Core 0.3.12 to 0.11.x ===<br />
<br />
Transaction replaceability is disallowed in a running node.<br />
<br />
=== Bitcoin Core 0.12.0 ===<br />
<br />
''Bitcoin Core 0.12.0 has been released in Feb 2016.''<br />
<br />
Bitcoin Core 0.12.0 uses the initial implementation of opt-in full-RBF<br />
described in [https://github.com/bitcoin/bips/blob/master/bip-0125.mediawiki BIP 125].<br />
<br />
The initial implementation of opt-in full-RBF may be seen in <br />
[https://github.com/bitcoin/bitcoin/pull/6871 Bitcoin Core PR#6871]<br />
and specifically the master branch commits from<br />
5891f870d68d90408aa5ce5b597fb574f2d2cbca to<br />
16a2f93629f75d182871f288f0396afe6cdc8504 (inclusive).<br />
<br />
=== Peter Todd's full-RBF patchset ===<br />
<br />
Peter Todd has historically maintained patchsets against Bitcoin Core<br />
0.8.x and later that implement full-RBF for all transactions in the<br />
mempool. (Later versions also provide an option to enable RBF First-Seen-Safe (RBF-FSS) only.)<br />
A rebased version of the most recent patch is also available for<br />
contemporary [http://luke.dashjr.org/programs/bitcoin-ljr/ Bitcoin LJR] releases.<br />
<br />
Notably, the patchset also implements preferential peering that allows<br />
nodes implementing full-RBF to connect to each other so that replacements <br />
can circulate even if full-RBF nodes represent a small minority of the<br />
network.<br />
<br />
As of 2015-12-08, there are no known large miners or mining pools that<br />
implement full-RBF.<br />
<br />
* [https://github.com/petertodd/bitcoin/branches/all?utf8=%E2%9C%93&amp;query=replace-by-fee-v0.10 Replace by fee patches for Bitcoin Core 0.10.x]<br />
* [https://github.com/petertodd/bitcoin/branches/all?utf8=%E2%9C%93&amp;query=replace-by-fee-v0.11 Replace by fee patches for Bitcoin Core 0.11.x]<br />
<br />
Policy&lt;ref&gt;[https://github.com/bitcoin/bitcoin/compare/0.11...petertodd:replace-by-fee-v0.11.0 RBF patchset for 0.11.2], Peter Todd, GitHub, ''Retrieved 2015-12-08''&lt;/ref&gt;: one or more transactions currently in the mempool (original<br />
transactions) will be replaced by a new transaction (replacement<br />
transaction) that spends one or more of the same inputs if,<br />
<br />
# The replacement transaction pays an absolute higher fee than the original transactions.<br />
# The replacement transaction must pay for its own bandwidth in addition to the amount paid by the original transactions at least by the rate set by the node's minimum relay fee setting. For example, if the minimum relay fee is 1 satoshi/byte and the replacement transaction is 500 bytes total, then the replacement must pay a fee at least 500 satoshis higher than the originals.<br />
# No more than 100 original transactions are replaced by the replacement transaction<br />
<br />
== See Also ==<br />
<br />
* [https://github.com/bitcoin/bips/blob/master/bip-0125.mediawiki BIP 125]<br />
* [https://www.reddit.com/r/Bitcoin/comments/3urm8o/optin_rbf_is_misunderstood_ask_questions_about_it/ Reddit: Questions about opt-in RBF]<br />
<br />
== References ==<br />
<br />
&lt;references /&gt;</div>Sgornickhttps://en.bitcoin.it/w/index.php?title=Buying_Bitcoins_(the_newbie_version)&diff=62034Buying Bitcoins (the newbie version)2017-01-11T07:06:06Z<p>Sgornick: Remove references to defunct exchange BitBrothersLLC.</p>
<hr />
<div><br />
This page aims to be the best resource for new users to understand how to buy Bitcoins. The existing [[Buying bitcoins]] page is too complex.<br />
<br />
Read [https://en.bitcoin.it/wiki/How_To_Buy_Bitcoins_With_Your_Credit_Card How To Buy Bitcoins With Your Credit Card], for information about buying Bitcoins with a credit card.<br />
<br />
{{Counterparty-warning}}<br />
<br />
===PayPal===<br />
<br />
[http://bitcoin.stackexchange.com/questions/2293/how-can-i-buy-bitcoin-via-a-credit-card-or-paypal You can't directly buy Bitcoins using PayPal], because it is risky for the seller, and therefore few sellers will offer this. There are basically 3 reasons for that:<br />
<br />
* The buyer of bitcoins can always perform a chargeback and there is no way for the seller to contest that<br />
<br />
* There are many hacked accounts and when PayPal realizes that such an account has been fraudulently used, they will also perform a chargeback<br />
<br />
* PayPal doesn't like bitcoin, as the bitcoin network is in direct competition to it. They will ban accounts that have anything to do with Bitcoins, and freeze their balance.<br />
<br />
Having said that there is a [http://99bitcoins.com/buying-bitcoins-with-paypal-a-practical-guide/ workaround] that can be done in order to use Paypal to buy Bitcoins but it holds within it higher transaction fees. Using the [http://VirrWox.com Virtual World Exchange] you can buy Second Life Lindens (SLL) with Paypal and then convert your SLL to Bitcoins. This process will charge you transaction fees of around 6% but will let you purchase Bitcoins pretty quickly as opposed to a wire transfer. The reason this method works is because you do not buy Bitcoins with Paypal directly, you only buy SLL with Paypal (which is acceptable by Paypal's TOS) and then exchange your SLL to Bitcoin.<br />
<br />
'''Note''': If you only want to take advantage of Bitcoin's price volatility You can trade CFDs on Bitcoin via Paypal on sites like [http://www.avatrade.com/lp/bitcoin-trading AvaTrade] or [http://99bitcoins.com/plus500 Plus500]. When trading online your capital may be at risk. Trading CFDs is suitable for more experienced traders.<br />
<br />
===Credit Card===<br />
<br />
[https://cubits.com Cubits] - Cubits is an all-inclusive platform to buy, sell and accept Bitcoin. Our easy-to-use interface allows users to buy and sell Bitcoin instantly with 17 supported currencies. Visa and Mastercard accepted.<br />
<br />
[https://www.virwox.com VirWox] - The Virtual World Exchange accepts all major credit cards (via Paypal or Skrill) and allows you to buy SLL which you can then trade to Bitcoin. Using [http://99bitcoins.com/how-to-buy-bitcoin-with-a-credit-card/ this method] is faster then most options but has larger transaction fees involved.<br />
<br />
[http://coin-mama.com/ CoinMama] uses Western Union to allow you to purchase Bitcoins through your credit card. This service is not available in the US.<br />
<br />
===Bank Transfer ===<br />
<br />
'''US Only!!''' [https://coinbase.com/ Coinbase] allows you to buy and sell bitcoin instantly by connecting any U.S. based bank account. You need an account number and routing number, which can be found on a check. A credit card can be optionally linked to your account as well. Coinbase also acts as a bitcoin wallet which can store the bitcoin once it is purchased. Ideal for beginners first getting involved in bitcoin.<br />
<br />
[[File:20px-expresscoin.png|20px|link=http://www.expresscoin.com]] [http://www.expresscoin.com expresscoin.com] ([https://en.bitcoin.it/wiki/Expresscoin info)] allows customers to buy Bitcoin with a bank wire transfer. Specific instructions of all payment methods are referenced in the [http://www.expresscoin.com/how How To Buy] page.<br />
<br />
[https://bittylicious.com Bittylicious] allows customers to purchase Bitcoins using an extremely simple interface. All customers need to do is to enter their Bitcoin address and email address and choose how many coins they want. If customers want to purchase more than the default (usually around £50/EUR 55/$80) then they just need to sign up and do some sort of verification. UK bank transfers, Euroean SEPAs, iDEAL and Mister Cash are all accepted.<br />
<br />
[https://kraken.com Kraken] allows verified users to buy and sell bitcoin using USD and EUR by depositing via wire transfer. Other national currencies can be converted to USD or EUR at transfer. Kraken is an exchange and the market is determined by orders.<br />
<br />
[[File:BitQuickco.png|20px|link=https://www.bitquick.co]] [https://www.bitquick.co BitQuick.co] ([https://en.bitcoin.it/wiki/BitQuick.co info)] allows sellers to connect to buyers via cash deposit or SEPA transfer. You can buy bitcoin instantly by providing only your email address and bitcoin address. As soon as the deposit is received, the bitcoin are sent.<br />
<br />
[[File:favicon_b4c.jpg|20px|link=https://bit4coin.net]] [https://bit4coin.net bit4coin.net] ([[bit4coin|info]]) Buy bitcoins with bit4coin gift vouchers. Easy to use online shop experience, and the vouchers will be delivered to your doorstep. [https://bit4coin.net bit4coin.net] guides you through the entire process of redeeming the voucher and getting your first bitcoins - and the voucher doubles up as a great gift, too!<br />
<br />
[http://www.belgacoin.com Belgacoin] allows you to buy bitcoins via SEPA transfer. It is fast, secure and cheap. No registration needed. We do not charge anything for this service, for the time being.<br />
<br />
[https://bitalo.com Bitalo] enables you to buy Bitcoins directly from another person. If that person is online and you share the same bank, you can get your Bitcoins in a matter of minutes. The transaction is secured by Bitcoin multi-signature addresses, and Bitalo acts as an escrow. You can store bought Bitcoins on your own address, or using a safe multi-signature Bitcoin wallet on Bitalo, for free.<br />
<br />
[[File:ANXIcon.png|20px|link=https://www.anxpro.com]] [https://www.anxpro.com Asia Nexgen (ANX)] ([https://en.bitcoin.it/wiki/Asia_Nexgen_Bitcoin_Exchange info)] allow their customers to buy Bitcoin by sending a wire transfer. They are legally registered and based in Hong Kong and hold a Money Services Operator license issued by the Hong Kong Customs and Excise Department. They support most popular cryto-currencies and all major fiat currencies (including USD, EUR, HKD, AUD, CAD, CHF, GBP, JPY, NZD and SGD). They are currently running a zero transaction fee promotion.<br />
<br />
'''UK Only!!''' [http://www.bitcoinmagnet.co.uk/ http://www.bitcoinmagnet.co.uk/] allows customers to buy &amp; sell Bitcoin automatically using their UK bank account. All you need to provide is an email address and either your bitcoin wallet address (if buying) or your bank account details (if selling). For buying, they give you a unique reference code to include with your bank transfer. All future transfers that include this code will be automatically converted to Bitcoin and sent to you. You can therefore set up a regular standing order if desired. For selling, they give you a unique Bitcoin deposit address to send coins to. All future payments to this address will be automatically converted to GBP and sent to your UK bank account. They use the latest Bitstamp market price and aim to complete orders within 10 minutes. The fee is currently 5%.<br />
<br />
===Cash===<br />
[http://localbitcoins.com Local Bitcoins] allows sellers and buyers who are located nearby to meet and exchange Bitcoins through various methods including cash, wire transfer, Money Bookers, Skrill and more. Local Bitcoins offers a [https://en.bitcoin.it/wiki/Bitcoin_Escrow_Service Bitcoin escrow] service that holds the funds until the transaction is complete, therefore reducing fraud.<br />
<br />
[[File:BitQuickco.png|20px|link=https://www.bitquick.co]] [https://www.bitquick.co BitQuick.co] ([https://en.bitcoin.it/wiki/BitQuick.co info)] allows sellers to connect to buyers via cash deposit or SEPA transfer. You can buy bitcoin instantly by providing only your email address and bitcoin address. As soon as the deposit is received, the bitcoin are sent.<br />
<br />
[[File:ANXIcon.png|20px|link=https://www.anxpro.com]] [https://www.anxpro.com Asia Nexgen (ANX)] ([https://en.bitcoin.it/wiki/Asia_Nexgen_Bitcoin_Exchange info)] allow their customers to buy Bitcoin by depositing directly into their Australian bank account. They are legally registered and based in Hong Kong and hold a Money Services Operator license issued by the Hong Kong Customs and Excise Department. They support most popular cryto-currencies and all major fiat currencies (including USD, EUR, HKD, AUD, CAD, CHF, GBP, JPY, NZD and SGD). They are currently running a zero transaction fee promotion. <br />
<br />
The company prepared to open Hong Kong's first physical bitcoin shop, in Sai Ying Pun in February 2014. Customers, who must supply an identity card and proof of address for anti-money laundering regulatory compliance, will be able to purchase bitcoins for cash.<br />
<br />
The company brought the first Bitcoin ATM to Hong Kong. Customers must be verified to use this ATM and will need to use their Bitcoin wallet QR code to make a cash deposit.<br />
<br />
[[File:BXlogoSM.jpeg|link=http://bitXoin.com]] [http://bitXoin.com bitXoin] ([[bitXoin|info]]) Buy bitcoin via online ordering and bank deposit, cash over the counter at most banks throughout Australia. Fast processing, low reference rate, low commissions. <br />
<br />
[https://www.getbitcoin.com.au Bitcoin (Australia)] - pay by cash over the counter at local bank branches.<br />
<br />
[[File:20px-expresscoin.png|20px|link=http://www.expresscoin.com]] [http://www.expresscoin.com expresscoin.com] ([https://en.bitcoin.it/wiki/Expresscoin info)] allows customers to pay with cash at Credit Unions that support shared branching.<br />
<br />
=== Personal Checks ===<br />
<br />
[[File:20px-expresscoin.png|20px|link=http://www.expresscoin.com]] [http://www.expresscoin.com expresscoin.com] ([https://en.bitcoin.it/wiki/Expresscoin info)] allows customers to buy Bitcoin with a personal check. Create a purchase request and mail in a personal check to the listed address and match amount. Specific instructions of all payment methods are referenced in the [http://www.expresscoin.com/how How To Buy] page.<br />
<br />
===Gift Card (US)===<br />
[https://giftcarddrainer.com GiftCardDrainer.com] allows you to buy bitcoin with Visa, MasterCard, American Express or Discover gift cards. Uses the exchange rate provided by coinbase.com at the time that the customer's gift card is processed within 24 hours of card submission. Most cards are processed within a few hours of submission, however it can take up to 24 hours. Customer must provide a bank account number for identity verification.<br />
<br />
=== Money Orders ===<br />
<br />
[[File:20px-expresscoin.png|20px|link=http://www.expresscoin.com]] [http://www.expresscoin.com expresscoin.com] ([https://en.bitcoin.it/wiki/Expresscoin info)] allows customers to buy Bitcoin with a personal check. Create a purchase request and mail in a USPS Money Order to the listed address and match amount. Specific instructions of all payment methods are referenced in the [http://www.expresscoin.com/how How To Buy] page.<br />
<br />
===Via IDeal (NL)===<br />
[https://bitonic.nl Bitonic] allows you to buy bitcoins with IDEAL.<br />
<br />
[http://www.happycoins.nl HappyCoins] allows you to buy Bitcoins with iDEAL and SEPA bank transfer.<br />
<br />
[https://btcdirect.nl BTCDirect] allows you to buy and sell bitcoins with iDEAL.<br />
<br />
[https://clevercoin.com CleverCoin] allows you to buy and sell bitcoins directly on an exchange with iDEAL and SEPA bank transfer.<br />
<br />
[https://josien.net Josien] allows you to buy bitcoins and litecoins with iDEAL and SEPA bank transfer.<br />
<br />
===Via MoneyGram===<br />
<br />
You can buy Bitcoins with a Western Union or MoneyGram money transfer via [http://www.coinmama.com/ coinmama.com].<br />
<br />
===Finding a direct seller online===<br />
<br />
If you can find another person that is willing to sell them to you, you can transfer him money via any payment method (including PayPal), and he'll send you the Bitcoins. The following websites can be used to find direct sellers online [[Bitcoin OTC]], [http://localbitcoins.com Local Bitcoins] or the [https://bitcointalk.org/index.php?board=53.0 Currency Exchange Forum Section]. Be extremely cautious of scammers when dealing over the counter. Ask an admin, moderator or a trusted person if you think someone is suspicious. <br />
<br />
===Physical Trading===<br />
You might be able to find an individual with whom you can [https://localbitcoins.com Buy bitcoins locally].<br />
Always choose somebody with many reviews.<br />
<br />
Starting in October of 2013, physical Bitcoin ATMs have been installed in Canada, Finland, Slovakia, Australia, Germany, and the UK. Use a [http://bitcoinatmexplorer.com/ Bitcoin ATM Locator] to find a machine near you.<br />
<br />
===Price Comparison===<br />
[http://bittybot.co.uk BittyBot] - allows users to compare different bitcoin sellers and prices in UK.<br />
<br />
===Anonymity===<br />
There is a huge demand for buying Bitcoins off the grid due to ever-increasing government regulations and private agency intrusions and discrimination against alternative currencies. <br />
Due to the possibility of facial recognition cameras at banks and the paper trail involved with credit cards, there are very few options to have high levels of anonymity when buying Bitcoins those ways. DNA, Fingerprints, phone and internet records, audio and video records will not be discussed, but they all are possible tools which attackers could use to uncloak even the stealthiest Bitcoin buyer.<br />
There are a couple known ways, depending on your location, to buy Bitcoins outside of the standard banking system with relatively high anonymity.<br />
Buying locally with cash using a burner or payphone allows a high level of anonymity with the exchange being the weakest link.<br />
Many sellers online will also trade Bitcoins for [[MoneyPak]] codes or other cash-like gift codes which can be bought at a local store with cash.<br />
Another way to buy Bitcoins with a high level of anonymity is by sending cash in the mail.<br />
<br />
===Exchanges===<br />
<br />
For a list of other major exchanges, see [[Buying bitcoins#Market Exchanges|Market Exchanges]]<br />
<br />
==Avoiding Scams==<br />
Before using any service, it is a good idea to look for reviews and feedback from previous customers. This can be done by performing a Google search of the name of the website or company. The [https://bitcointalk.org Bitcoin forum] is also a good place to find discussions and reviews about services. <br />
<br />
==Links==<br />
* [[Buying bitcoins]]<br />
* [https://www.weusecoins.com/en/how-buy-bitcoins-online-best-bitcoin-exchange-rate-bitcoin-price/ How-To Buy guide from WeUseCoins.com]<br />
* [http://howtobuybitcoins.info/ HowToBuyBitcoins.info]<br />
* http://bitcoin.stackexchange.com/questions/91/how-do-you-obtain-bitcoins<br />
* http://bitcoin.stackexchange.com/questions/4194/whats-the-best-way-to-buy-bitcoin-noob-friendly<br />
* https://en.bitcoin.it/wiki/How_To_Buy_Bitcoins_With_Your_Credit_Card<br />
<br />
[[Category:Introduction]]<br />
{{p-full}}</div>Sgornickhttps://en.bitcoin.it/w/index.php?title=Buying_Bitcoins_(the_newbie_version)&diff=62032Buying Bitcoins (the newbie version)2017-01-11T06:59:47Z<p>Sgornick: /* Links */ Remove entry for article of defunct exchange BitcoinByCC.</p>
<hr />
<div><br />
This page aims to be the best resource for new users to understand how to buy Bitcoins. The existing [[Buying bitcoins]] page is too complex.<br />
<br />
Read [https://en.bitcoin.it/wiki/How_To_Buy_Bitcoins_With_Your_Credit_Card How To Buy Bitcoins With Your Credit Card], for information about buying Bitcoins with a credit card.<br />
<br />
{{Counterparty-warning}}<br />
<br />
===PayPal===<br />
<br />
[http://bitcoin.stackexchange.com/questions/2293/how-can-i-buy-bitcoin-via-a-credit-card-or-paypal You can't directly buy Bitcoins using PayPal], because it is risky for the seller, and therefore few sellers will offer this. There are basically 3 reasons for that:<br />
<br />
* The buyer of bitcoins can always perform a chargeback and there is no way for the seller to contest that<br />
<br />
* There are many hacked accounts and when PayPal realizes that such an account has been fraudulently used, they will also perform a chargeback<br />
<br />
* PayPal doesn't like bitcoin, as the bitcoin network is in direct competition to it. They will ban accounts that have anything to do with Bitcoins, and freeze their balance.<br />
<br />
Having said that there is a [http://99bitcoins.com/buying-bitcoins-with-paypal-a-practical-guide/ workaround] that can be done in order to use Paypal to buy Bitcoins but it holds within it higher transaction fees. Using the [http://VirrWox.com Virtual World Exchange] you can buy Second Life Lindens (SLL) with Paypal and then convert your SLL to Bitcoins. This process will charge you transaction fees of around 6% but will let you purchase Bitcoins pretty quickly as opposed to a wire transfer. The reason this method works is because you do not buy Bitcoins with Paypal directly, you only buy SLL with Paypal (which is acceptable by Paypal's TOS) and then exchange your SLL to Bitcoin.<br />
<br />
'''Note''': If you only want to take advantage of Bitcoin's price volatility You can trade CFDs on Bitcoin via Paypal on sites like [http://www.avatrade.com/lp/bitcoin-trading AvaTrade] or [http://99bitcoins.com/plus500 Plus500]. When trading online your capital may be at risk. Trading CFDs is suitable for more experienced traders.<br />
<br />
===Credit Card===<br />
<br />
[https://cubits.com Cubits] - Cubits is an all-inclusive platform to buy, sell and accept Bitcoin. Our easy-to-use interface allows users to buy and sell Bitcoin instantly with 17 supported currencies. Visa and Mastercard accepted.<br />
<br />
[https://www.virwox.com VirWox] - The Virtual World Exchange accepts all major credit cards (via Paypal or Skrill) and allows you to buy SLL which you can then trade to Bitcoin. Using [http://99bitcoins.com/how-to-buy-bitcoin-with-a-credit-card/ this method] is faster then most options but has larger transaction fees involved.<br />
<br />
[http://coin-mama.com/ CoinMama] uses Western Union to allow you to purchase Bitcoins through your credit card. This service is not available in the US.<br />
<br />
===Bank Transfer ===<br />
<br />
'''US Only!!''' [https://coinbase.com/ Coinbase] allows you to buy and sell bitcoin instantly by connecting any U.S. based bank account. You need an account number and routing number, which can be found on a check. A credit card can be optionally linked to your account as well. Coinbase also acts as a bitcoin wallet which can store the bitcoin once it is purchased. Ideal for beginners first getting involved in bitcoin.<br />
<br />
[[File:20px-expresscoin.png|20px|link=http://www.expresscoin.com]] [http://www.expresscoin.com expresscoin.com] ([https://en.bitcoin.it/wiki/Expresscoin info)] allows customers to buy Bitcoin with a bank wire transfer. Specific instructions of all payment methods are referenced in the [http://www.expresscoin.com/how How To Buy] page.<br />
<br />
[https://bittylicious.com Bittylicious] allows customers to purchase Bitcoins using an extremely simple interface. All customers need to do is to enter their Bitcoin address and email address and choose how many coins they want. If customers want to purchase more than the default (usually around £50/EUR 55/$80) then they just need to sign up and do some sort of verification. UK bank transfers, Euroean SEPAs, iDEAL and Mister Cash are all accepted.<br />
<br />
[https://www.bitbrothersllc.com BitBrothers LLC] allows customers and bitcoiners to purchase bitcoins by either sending in cash, money orders, cashiers checks, or MONEYGRAM to a designated location. Bitcoiners can also deposit money directly into one of the corporate business accounts increasing the transaction time to less than an hour. These methods of payments are available to ensure anonymity and protect the ideals bitcoins were founded on. For customers who wish to preform BANK TRANSFERS, the option will be available shortly. BitBrothers LLC guarantees that all customers will be satisfied with their exquisite customer service and overall experience that they are even offering discounts to select customers!<br />
<br />
[https://kraken.com Kraken] allows verified users to buy and sell bitcoin using USD and EUR by depositing via wire transfer. Other national currencies can be converted to USD or EUR at transfer. Kraken is an exchange and the market is determined by orders.<br />
<br />
[[File:BitQuickco.png|20px|link=https://www.bitquick.co]] [https://www.bitquick.co BitQuick.co] ([https://en.bitcoin.it/wiki/BitQuick.co info)] allows sellers to connect to buyers via cash deposit or SEPA transfer. You can buy bitcoin instantly by providing only your email address and bitcoin address. As soon as the deposit is received, the bitcoin are sent.<br />
<br />
[[File:favicon_b4c.jpg|20px|link=https://bit4coin.net]] [https://bit4coin.net bit4coin.net] ([[bit4coin|info]]) Buy bitcoins with bit4coin gift vouchers. Easy to use online shop experience, and the vouchers will be delivered to your doorstep. [https://bit4coin.net bit4coin.net] guides you through the entire process of redeeming the voucher and getting your first bitcoins - and the voucher doubles up as a great gift, too!<br />
<br />
[http://www.belgacoin.com Belgacoin] allows you to buy bitcoins via SEPA transfer. It is fast, secure and cheap. No registration needed. We do not charge anything for this service, for the time being.<br />
<br />
[https://bitalo.com Bitalo] enables you to buy Bitcoins directly from another person. If that person is online and you share the same bank, you can get your Bitcoins in a matter of minutes. The transaction is secured by Bitcoin multi-signature addresses, and Bitalo acts as an escrow. You can store bought Bitcoins on your own address, or using a safe multi-signature Bitcoin wallet on Bitalo, for free.<br />
<br />
[[File:ANXIcon.png|20px|link=https://www.anxpro.com]] [https://www.anxpro.com Asia Nexgen (ANX)] ([https://en.bitcoin.it/wiki/Asia_Nexgen_Bitcoin_Exchange info)] allow their customers to buy Bitcoin by sending a wire transfer. They are legally registered and based in Hong Kong and hold a Money Services Operator license issued by the Hong Kong Customs and Excise Department. They support most popular cryto-currencies and all major fiat currencies (including USD, EUR, HKD, AUD, CAD, CHF, GBP, JPY, NZD and SGD). They are currently running a zero transaction fee promotion.<br />
<br />
'''UK Only!!''' [http://www.bitcoinmagnet.co.uk/ http://www.bitcoinmagnet.co.uk/] allows customers to buy &amp; sell Bitcoin automatically using their UK bank account. All you need to provide is an email address and either your bitcoin wallet address (if buying) or your bank account details (if selling). For buying, they give you a unique reference code to include with your bank transfer. All future transfers that include this code will be automatically converted to Bitcoin and sent to you. You can therefore set up a regular standing order if desired. For selling, they give you a unique Bitcoin deposit address to send coins to. All future payments to this address will be automatically converted to GBP and sent to your UK bank account. They use the latest Bitstamp market price and aim to complete orders within 10 minutes. The fee is currently 5%.<br />
<br />
===Cash===<br />
[http://localbitcoins.com Local Bitcoins] allows sellers and buyers who are located nearby to meet and exchange Bitcoins through various methods including cash, wire transfer, Money Bookers, Skrill and more. Local Bitcoins offers a [https://en.bitcoin.it/wiki/Bitcoin_Escrow_Service Bitcoin escrow] service that holds the funds until the transaction is complete, therefore reducing fraud.<br />
<br />
[[File:BitQuickco.png|20px|link=https://www.bitquick.co]] [https://www.bitquick.co BitQuick.co] ([https://en.bitcoin.it/wiki/BitQuick.co info)] allows sellers to connect to buyers via cash deposit or SEPA transfer. You can buy bitcoin instantly by providing only your email address and bitcoin address. As soon as the deposit is received, the bitcoin are sent.<br />
<br />
[https://www.bitbrothersllc.com BitBothers LLC] allows customers and bitcoiners to purchase bitcoins by either sending in cash, money orders, cashiers checks, or MONEYGRAM to a designated location. Bitcoiners can also deposit money directly into one of the corporate business accounts increasing the transaction time to less than an hour. These methods of payments are avaliable to ensure anonymity and protect the ideals bitcoins were founded on. For customers who wish to preform bank transfers, the option will be avaliable shortly. BitBrothers LLC gurantees that all customers will be satisfied with their exquisite customer service and overall experience that they are even offering discounts to select customers!<br />
<br />
[[File:ANXIcon.png|20px|link=https://www.anxpro.com]] [https://www.anxpro.com Asia Nexgen (ANX)] ([https://en.bitcoin.it/wiki/Asia_Nexgen_Bitcoin_Exchange info)] allow their customers to buy Bitcoin by depositing directly into their Australian bank account. They are legally registered and based in Hong Kong and hold a Money Services Operator license issued by the Hong Kong Customs and Excise Department. They support most popular cryto-currencies and all major fiat currencies (including USD, EUR, HKD, AUD, CAD, CHF, GBP, JPY, NZD and SGD). They are currently running a zero transaction fee promotion. <br />
<br />
The company prepared to open Hong Kong's first physical bitcoin shop, in Sai Ying Pun in February 2014. Customers, who must supply an identity card and proof of address for anti-money laundering regulatory compliance, will be able to purchase bitcoins for cash.<br />
<br />
The company brought the first Bitcoin ATM to Hong Kong. Customers must be verified to use this ATM and will need to use their Bitcoin wallet QR code to make a cash deposit.<br />
<br />
[[File:BXlogoSM.jpeg|link=http://bitXoin.com]] [http://bitXoin.com bitXoin] ([[bitXoin|info]]) Buy bitcoin via online ordering and bank deposit, cash over the counter at most banks throughout Australia. Fast processing, low reference rate, low commissions. <br />
<br />
[https://www.getbitcoin.com.au Bitcoin (Australia)] - pay by cash over the counter at local bank branches.<br />
<br />
[[File:20px-expresscoin.png|20px|link=http://www.expresscoin.com]] [http://www.expresscoin.com expresscoin.com] ([https://en.bitcoin.it/wiki/Expresscoin info)] allows customers to pay with cash at Credit Unions that support shared branching.<br />
<br />
=== Personal Checks ===<br />
<br />
[[File:20px-expresscoin.png|20px|link=http://www.expresscoin.com]] [http://www.expresscoin.com expresscoin.com] ([https://en.bitcoin.it/wiki/Expresscoin info)] allows customers to buy Bitcoin with a personal check. Create a purchase request and mail in a personal check to the listed address and match amount. Specific instructions of all payment methods are referenced in the [http://www.expresscoin.com/how How To Buy] page.<br />
<br />
===Gift Card (US)===<br />
[https://giftcarddrainer.com GiftCardDrainer.com] allows you to buy bitcoin with Visa, MasterCard, American Express or Discover gift cards. Uses the exchange rate provided by coinbase.com at the time that the customer's gift card is processed within 24 hours of card submission. Most cards are processed within a few hours of submission, however it can take up to 24 hours. Customer must provide a bank account number for identity verification.<br />
<br />
=== Money Orders ===<br />
<br />
[[File:20px-expresscoin.png|20px|link=http://www.expresscoin.com]] [http://www.expresscoin.com expresscoin.com] ([https://en.bitcoin.it/wiki/Expresscoin info)] allows customers to buy Bitcoin with a personal check. Create a purchase request and mail in a USPS Money Order to the listed address and match amount. Specific instructions of all payment methods are referenced in the [http://www.expresscoin.com/how How To Buy] page.<br />
<br />
===Via IDeal (NL)===<br />
[https://bitonic.nl Bitonic] allows you to buy bitcoins with IDEAL.<br />
<br />
[http://www.happycoins.nl HappyCoins] allows you to buy Bitcoins with iDEAL and SEPA bank transfer.<br />
<br />
[https://btcdirect.nl BTCDirect] allows you to buy and sell bitcoins with iDEAL.<br />
<br />
[https://clevercoin.com CleverCoin] allows you to buy and sell bitcoins directly on an exchange with iDEAL and SEPA bank transfer.<br />
<br />
[https://josien.net Josien] allows you to buy bitcoins and litecoins with iDEAL and SEPA bank transfer.<br />
<br />
===Via MoneyGram===<br />
<br />
[https://www.bitbrothersllc.com BitBrothersLLC] Buy bitcoins with MoneyGram anywhere in the U.S.<br />
<br />
You can buy Bitcoins with a Western Union or MoneyGram money transfer via [http://www.coinmama.com/ coinmama.com].<br />
<br />
===Finding a direct seller online===<br />
<br />
If you can find another person that is willing to sell them to you, you can transfer him money via any payment method (including PayPal), and he'll send you the Bitcoins. The following websites can be used to find direct sellers online [[Bitcoin OTC]], [http://localbitcoins.com Local Bitcoins] or the [https://bitcointalk.org/index.php?board=53.0 Currency Exchange Forum Section]. Be extremely cautious of scammers when dealing over the counter. Ask an admin, moderator or a trusted person if you think someone is suspicious. <br />
<br />
===Physical Trading===<br />
[https://www.bitbrothersllc.com BitBothers LLC] LOCAL PURCHASES IN COLORADO. We also accept MONEYGRAM<br />
<br />
You might be able to find an individual with whom you can [https://localbitcoins.com Buy bitcoins locally].<br />
Always choose somebody with many reviews.<br />
<br />
Starting in October of 2013, physical Bitcoin ATMs have been installed in Canada, Finland, Slovakia, Australia, Germany, and the UK. Use a [http://bitcoinatmexplorer.com/ Bitcoin ATM Locator] to find a machine near you.<br />
<br />
===Price Comparison===<br />
[http://bittybot.co.uk BittyBot] - allows users to compare different bitcoin sellers and prices in UK.<br />
<br />
===Anonymity===<br />
There is a huge demand for buying Bitcoins off the grid due to ever-increasing government regulations and private agency intrusions and discrimination against alternative currencies. <br />
Due to the possibility of facial recognition cameras at banks and the paper trail involved with credit cards, there are very few options to have high levels of anonymity when buying Bitcoins those ways. DNA, Fingerprints, phone and internet records, audio and video records will not be discussed, but they all are possible tools which attackers could use to uncloak even the stealthiest Bitcoin buyer.<br />
There are a couple known ways, depending on your location, to buy Bitcoins outside of the standard banking system with relatively high anonymity.<br />
Buying locally with cash using a burner or payphone allows a high level of anonymity with the exchange being the weakest link.<br />
Many sellers online will also trade Bitcoins for [[MoneyPak]] codes or other cash-like gift codes which can be bought at a local store with cash.<br />
Another way to buy Bitcoins with a high level of anonymity is by sending cash in the mail.<br />
<br />
===Exchanges===<br />
<br />
For a list of other major exchanges, see [[Buying bitcoins#Market Exchanges|Market Exchanges]]<br />
<br />
==Avoiding Scams==<br />
Before using any service, it is a good idea to look for reviews and feedback from previous customers. This can be done by performing a Google search of the name of the website or company. The [https://bitcointalk.org Bitcoin forum] is also a good place to find discussions and reviews about services. <br />
<br />
==Links==<br />
* [[Buying bitcoins]]<br />
* [https://www.weusecoins.com/en/how-buy-bitcoins-online-best-bitcoin-exchange-rate-bitcoin-price/ How-To Buy guide from WeUseCoins.com]<br />
* [http://howtobuybitcoins.info/ HowToBuyBitcoins.info]<br />
* http://bitcoin.stackexchange.com/questions/91/how-do-you-obtain-bitcoins<br />
* http://bitcoin.stackexchange.com/questions/4194/whats-the-best-way-to-buy-bitcoin-noob-friendly<br />
* https://en.bitcoin.it/wiki/How_To_Buy_Bitcoins_With_Your_Credit_Card<br />
<br />
[[Category:Introduction]]<br />
{{p-full}}</div>Sgornickhttps://en.bitcoin.it/w/index.php?title=BitcoinByCC&diff=62031BitcoinByCC2017-01-11T06:57:58Z<p>Sgornick: Defunct.</p>
<hr />
<div>BBCC (previously known as bitcoinbycc.com) was a service allowed you to buy bitcoins using a credit card.<br />
<br />
It is now defunct.<br />
<br />
== Links ==<br />
* [[Buying bitcoins]]<br />
* https://en.bitcoin.it/wiki/Buying_Bitcoins_(the_newbie_version)<br />
* https://en.bitcoin.it/wiki/Buying_bitcoins<br />
* https://en.bitcoin.it/wiki/How_To_Buy_Bitcoins_With_Your_Credit_Card<br />
<br />
[[Category:Introduction]]</div>Sgornickhttps://en.bitcoin.it/w/index.php?title=Buying_Bitcoins_(the_newbie_version)&diff=62030Buying Bitcoins (the newbie version)2017-01-11T06:54:49Z<p>Sgornick: /* Links */ Add entry for How-To Buy guide from WeUseCoins.com.</p>
<hr />
<div><br />
This page aims to be the best resource for new users to understand how to buy Bitcoins. The existing [[Buying bitcoins]] page is too complex.<br />
<br />
Read [https://en.bitcoin.it/wiki/How_To_Buy_Bitcoins_With_Your_Credit_Card How To Buy Bitcoins With Your Credit Card], for information about buying Bitcoins with a credit card.<br />
<br />
{{Counterparty-warning}}<br />
<br />
===PayPal===<br />
<br />
[http://bitcoin.stackexchange.com/questions/2293/how-can-i-buy-bitcoin-via-a-credit-card-or-paypal You can't directly buy Bitcoins using PayPal], because it is risky for the seller, and therefore few sellers will offer this. There are basically 3 reasons for that:<br />
<br />
* The buyer of bitcoins can always perform a chargeback and there is no way for the seller to contest that<br />
<br />
* There are many hacked accounts and when PayPal realizes that such an account has been fraudulently used, they will also perform a chargeback<br />
<br />
* PayPal doesn't like bitcoin, as the bitcoin network is in direct competition to it. They will ban accounts that have anything to do with Bitcoins, and freeze their balance.<br />
<br />
Having said that there is a [http://99bitcoins.com/buying-bitcoins-with-paypal-a-practical-guide/ workaround] that can be done in order to use Paypal to buy Bitcoins but it holds within it higher transaction fees. Using the [http://VirrWox.com Virtual World Exchange] you can buy Second Life Lindens (SLL) with Paypal and then convert your SLL to Bitcoins. This process will charge you transaction fees of around 6% but will let you purchase Bitcoins pretty quickly as opposed to a wire transfer. The reason this method works is because you do not buy Bitcoins with Paypal directly, you only buy SLL with Paypal (which is acceptable by Paypal's TOS) and then exchange your SLL to Bitcoin.<br />
<br />
'''Note''': If you only want to take advantage of Bitcoin's price volatility You can trade CFDs on Bitcoin via Paypal on sites like [http://www.avatrade.com/lp/bitcoin-trading AvaTrade] or [http://99bitcoins.com/plus500 Plus500]. When trading online your capital may be at risk. Trading CFDs is suitable for more experienced traders.<br />
<br />
===Credit Card===<br />
<br />
[https://cubits.com Cubits] - Cubits is an all-inclusive platform to buy, sell and accept Bitcoin. Our easy-to-use interface allows users to buy and sell Bitcoin instantly with 17 supported currencies. Visa and Mastercard accepted.<br />
<br />
[https://www.virwox.com VirWox] - The Virtual World Exchange accepts all major credit cards (via Paypal or Skrill) and allows you to buy SLL which you can then trade to Bitcoin. Using [http://99bitcoins.com/how-to-buy-bitcoin-with-a-credit-card/ this method] is faster then most options but has larger transaction fees involved.<br />
<br />
[http://coin-mama.com/ CoinMama] uses Western Union to allow you to purchase Bitcoins through your credit card. This service is not available in the US.<br />
<br />
===Bank Transfer ===<br />
<br />
'''US Only!!''' [https://coinbase.com/ Coinbase] allows you to buy and sell bitcoin instantly by connecting any U.S. based bank account. You need an account number and routing number, which can be found on a check. A credit card can be optionally linked to your account as well. Coinbase also acts as a bitcoin wallet which can store the bitcoin once it is purchased. Ideal for beginners first getting involved in bitcoin.<br />
<br />
[[File:20px-expresscoin.png|20px|link=http://www.expresscoin.com]] [http://www.expresscoin.com expresscoin.com] ([https://en.bitcoin.it/wiki/Expresscoin info)] allows customers to buy Bitcoin with a bank wire transfer. Specific instructions of all payment methods are referenced in the [http://www.expresscoin.com/how How To Buy] page.<br />
<br />
[https://bittylicious.com Bittylicious] allows customers to purchase Bitcoins using an extremely simple interface. All customers need to do is to enter their Bitcoin address and email address and choose how many coins they want. If customers want to purchase more than the default (usually around £50/EUR 55/$80) then they just need to sign up and do some sort of verification. UK bank transfers, Euroean SEPAs, iDEAL and Mister Cash are all accepted.<br />
<br />
[https://www.bitbrothersllc.com BitBrothers LLC] allows customers and bitcoiners to purchase bitcoins by either sending in cash, money orders, cashiers checks, or MONEYGRAM to a designated location. Bitcoiners can also deposit money directly into one of the corporate business accounts increasing the transaction time to less than an hour. These methods of payments are available to ensure anonymity and protect the ideals bitcoins were founded on. For customers who wish to preform BANK TRANSFERS, the option will be available shortly. BitBrothers LLC guarantees that all customers will be satisfied with their exquisite customer service and overall experience that they are even offering discounts to select customers!<br />
<br />
[https://kraken.com Kraken] allows verified users to buy and sell bitcoin using USD and EUR by depositing via wire transfer. Other national currencies can be converted to USD or EUR at transfer. Kraken is an exchange and the market is determined by orders.<br />
<br />
[[File:BitQuickco.png|20px|link=https://www.bitquick.co]] [https://www.bitquick.co BitQuick.co] ([https://en.bitcoin.it/wiki/BitQuick.co info)] allows sellers to connect to buyers via cash deposit or SEPA transfer. You can buy bitcoin instantly by providing only your email address and bitcoin address. As soon as the deposit is received, the bitcoin are sent.<br />
<br />
[[File:favicon_b4c.jpg|20px|link=https://bit4coin.net]] [https://bit4coin.net bit4coin.net] ([[bit4coin|info]]) Buy bitcoins with bit4coin gift vouchers. Easy to use online shop experience, and the vouchers will be delivered to your doorstep. [https://bit4coin.net bit4coin.net] guides you through the entire process of redeeming the voucher and getting your first bitcoins - and the voucher doubles up as a great gift, too!<br />
<br />
[http://www.belgacoin.com Belgacoin] allows you to buy bitcoins via SEPA transfer. It is fast, secure and cheap. No registration needed. We do not charge anything for this service, for the time being.<br />
<br />
[https://bitalo.com Bitalo] enables you to buy Bitcoins directly from another person. If that person is online and you share the same bank, you can get your Bitcoins in a matter of minutes. The transaction is secured by Bitcoin multi-signature addresses, and Bitalo acts as an escrow. You can store bought Bitcoins on your own address, or using a safe multi-signature Bitcoin wallet on Bitalo, for free.<br />
<br />
[[File:ANXIcon.png|20px|link=https://www.anxpro.com]] [https://www.anxpro.com Asia Nexgen (ANX)] ([https://en.bitcoin.it/wiki/Asia_Nexgen_Bitcoin_Exchange info)] allow their customers to buy Bitcoin by sending a wire transfer. They are legally registered and based in Hong Kong and hold a Money Services Operator license issued by the Hong Kong Customs and Excise Department. They support most popular cryto-currencies and all major fiat currencies (including USD, EUR, HKD, AUD, CAD, CHF, GBP, JPY, NZD and SGD). They are currently running a zero transaction fee promotion.<br />
<br />
'''UK Only!!''' [http://www.bitcoinmagnet.co.uk/ http://www.bitcoinmagnet.co.uk/] allows customers to buy &amp; sell Bitcoin automatically using their UK bank account. All you need to provide is an email address and either your bitcoin wallet address (if buying) or your bank account details (if selling). For buying, they give you a unique reference code to include with your bank transfer. All future transfers that include this code will be automatically converted to Bitcoin and sent to you. You can therefore set up a regular standing order if desired. For selling, they give you a unique Bitcoin deposit address to send coins to. All future payments to this address will be automatically converted to GBP and sent to your UK bank account. They use the latest Bitstamp market price and aim to complete orders within 10 minutes. The fee is currently 5%.<br />
<br />
===Cash===<br />
[http://localbitcoins.com Local Bitcoins] allows sellers and buyers who are located nearby to meet and exchange Bitcoins through various methods including cash, wire transfer, Money Bookers, Skrill and more. Local Bitcoins offers a [https://en.bitcoin.it/wiki/Bitcoin_Escrow_Service Bitcoin escrow] service that holds the funds until the transaction is complete, therefore reducing fraud.<br />
<br />
[[File:BitQuickco.png|20px|link=https://www.bitquick.co]] [https://www.bitquick.co BitQuick.co] ([https://en.bitcoin.it/wiki/BitQuick.co info)] allows sellers to connect to buyers via cash deposit or SEPA transfer. You can buy bitcoin instantly by providing only your email address and bitcoin address. As soon as the deposit is received, the bitcoin are sent.<br />
<br />
[https://www.bitbrothersllc.com BitBothers LLC] allows customers and bitcoiners to purchase bitcoins by either sending in cash, money orders, cashiers checks, or MONEYGRAM to a designated location. Bitcoiners can also deposit money directly into one of the corporate business accounts increasing the transaction time to less than an hour. These methods of payments are avaliable to ensure anonymity and protect the ideals bitcoins were founded on. For customers who wish to preform bank transfers, the option will be avaliable shortly. BitBrothers LLC gurantees that all customers will be satisfied with their exquisite customer service and overall experience that they are even offering discounts to select customers!<br />
<br />
[[File:ANXIcon.png|20px|link=https://www.anxpro.com]] [https://www.anxpro.com Asia Nexgen (ANX)] ([https://en.bitcoin.it/wiki/Asia_Nexgen_Bitcoin_Exchange info)] allow their customers to buy Bitcoin by depositing directly into their Australian bank account. They are legally registered and based in Hong Kong and hold a Money Services Operator license issued by the Hong Kong Customs and Excise Department. They support most popular cryto-currencies and all major fiat currencies (including USD, EUR, HKD, AUD, CAD, CHF, GBP, JPY, NZD and SGD). They are currently running a zero transaction fee promotion. <br />
<br />
The company prepared to open Hong Kong's first physical bitcoin shop, in Sai Ying Pun in February 2014. Customers, who must supply an identity card and proof of address for anti-money laundering regulatory compliance, will be able to purchase bitcoins for cash.<br />
<br />
The company brought the first Bitcoin ATM to Hong Kong. Customers must be verified to use this ATM and will need to use their Bitcoin wallet QR code to make a cash deposit.<br />
<br />
[[File:BXlogoSM.jpeg|link=http://bitXoin.com]] [http://bitXoin.com bitXoin] ([[bitXoin|info]]) Buy bitcoin via online ordering and bank deposit, cash over the counter at most banks throughout Australia. Fast processing, low reference rate, low commissions. <br />
<br />
[https://www.getbitcoin.com.au Bitcoin (Australia)] - pay by cash over the counter at local bank branches.<br />
<br />
[[File:20px-expresscoin.png|20px|link=http://www.expresscoin.com]] [http://www.expresscoin.com expresscoin.com] ([https://en.bitcoin.it/wiki/Expresscoin info)] allows customers to pay with cash at Credit Unions that support shared branching.<br />
<br />
=== Personal Checks ===<br />
<br />
[[File:20px-expresscoin.png|20px|link=http://www.expresscoin.com]] [http://www.expresscoin.com expresscoin.com] ([https://en.bitcoin.it/wiki/Expresscoin info)] allows customers to buy Bitcoin with a personal check. Create a purchase request and mail in a personal check to the listed address and match amount. Specific instructions of all payment methods are referenced in the [http://www.expresscoin.com/how How To Buy] page.<br />
<br />
===Gift Card (US)===<br />
[https://giftcarddrainer.com GiftCardDrainer.com] allows you to buy bitcoin with Visa, MasterCard, American Express or Discover gift cards. Uses the exchange rate provided by coinbase.com at the time that the customer's gift card is processed within 24 hours of card submission. Most cards are processed within a few hours of submission, however it can take up to 24 hours. Customer must provide a bank account number for identity verification.<br />
<br />
=== Money Orders ===<br />
<br />
[[File:20px-expresscoin.png|20px|link=http://www.expresscoin.com]] [http://www.expresscoin.com expresscoin.com] ([https://en.bitcoin.it/wiki/Expresscoin info)] allows customers to buy Bitcoin with a personal check. Create a purchase request and mail in a USPS Money Order to the listed address and match amount. Specific instructions of all payment methods are referenced in the [http://www.expresscoin.com/how How To Buy] page.<br />
<br />
===Via IDeal (NL)===<br />
[https://bitonic.nl Bitonic] allows you to buy bitcoins with IDEAL.<br />
<br />
[http://www.happycoins.nl HappyCoins] allows you to buy Bitcoins with iDEAL and SEPA bank transfer.<br />
<br />
[https://btcdirect.nl BTCDirect] allows you to buy and sell bitcoins with iDEAL.<br />
<br />
[https://clevercoin.com CleverCoin] allows you to buy and sell bitcoins directly on an exchange with iDEAL and SEPA bank transfer.<br />
<br />
[https://josien.net Josien] allows you to buy bitcoins and litecoins with iDEAL and SEPA bank transfer.<br />
<br />
===Via MoneyGram===<br />
<br />
[https://www.bitbrothersllc.com BitBrothersLLC] Buy bitcoins with MoneyGram anywhere in the U.S.<br />
<br />
You can buy Bitcoins with a Western Union or MoneyGram money transfer via [http://www.coinmama.com/ coinmama.com].<br />
<br />
===Finding a direct seller online===<br />
<br />
If you can find another person that is willing to sell them to you, you can transfer him money via any payment method (including PayPal), and he'll send you the Bitcoins. The following websites can be used to find direct sellers online [[Bitcoin OTC]], [http://localbitcoins.com Local Bitcoins] or the [https://bitcointalk.org/index.php?board=53.0 Currency Exchange Forum Section]. Be extremely cautious of scammers when dealing over the counter. Ask an admin, moderator or a trusted person if you think someone is suspicious. <br />
<br />
===Physical Trading===<br />
[https://www.bitbrothersllc.com BitBothers LLC] LOCAL PURCHASES IN COLORADO. We also accept MONEYGRAM<br />
<br />
You might be able to find an individual with whom you can [https://localbitcoins.com Buy bitcoins locally].<br />
Always choose somebody with many reviews.<br />
<br />
Starting in October of 2013, physical Bitcoin ATMs have been installed in Canada, Finland, Slovakia, Australia, Germany, and the UK. Use a [http://bitcoinatmexplorer.com/ Bitcoin ATM Locator] to find a machine near you.<br />
<br />
===Price Comparison===<br />
[http://bittybot.co.uk BittyBot] - allows users to compare different bitcoin sellers and prices in UK.<br />
<br />
===Anonymity===<br />
There is a huge demand for buying Bitcoins off the grid due to ever-increasing government regulations and private agency intrusions and discrimination against alternative currencies. <br />
Due to the possibility of facial recognition cameras at banks and the paper trail involved with credit cards, there are very few options to have high levels of anonymity when buying Bitcoins those ways. DNA, Fingerprints, phone and internet records, audio and video records will not be discussed, but they all are possible tools which attackers could use to uncloak even the stealthiest Bitcoin buyer.<br />
There are a couple known ways, depending on your location, to buy Bitcoins outside of the standard banking system with relatively high anonymity.<br />
Buying locally with cash using a burner or payphone allows a high level of anonymity with the exchange being the weakest link.<br />
Many sellers online will also trade Bitcoins for [[MoneyPak]] codes or other cash-like gift codes which can be bought at a local store with cash.<br />
Another way to buy Bitcoins with a high level of anonymity is by sending cash in the mail.<br />
<br />
===Exchanges===<br />
<br />
For a list of other major exchanges, see [[Buying bitcoins#Market Exchanges|Market Exchanges]]<br />
<br />
==Avoiding Scams==<br />
Before using any service, it is a good idea to look for reviews and feedback from previous customers. This can be done by performing a Google search of the name of the website or company. The [https://bitcointalk.org Bitcoin forum] is also a good place to find discussions and reviews about services. <br />
<br />
==Links==<br />
* [[Buying bitcoins]]<br />
* [https://www.weusecoins.com/en/how-buy-bitcoins-online-best-bitcoin-exchange-rate-bitcoin-price/ How-To Buy guide from WeUseCoins.com]<br />
* [http://howtobuybitcoins.info/ HowToBuyBitcoins.info]<br />
* http://bitcoin.stackexchange.com/questions/91/how-do-you-obtain-bitcoins<br />
* http://bitcoin.stackexchange.com/questions/4194/whats-the-best-way-to-buy-bitcoin-noob-friendly<br />
* https://en.bitcoin.it/wiki/BitcoinByCC<br />
* https://en.bitcoin.it/wiki/How_To_Buy_Bitcoins_With_Your_Credit_Card<br />
<br />
[[Category:Introduction]]<br />
{{p-full}}</div>Sgornickhttps://en.bitcoin.it/w/index.php?title=Category:Block_chain_browsers&diff=61872Category:Block chain browsers2016-11-30T16:48:33Z<p>Sgornick: /* List of online block chain browsers */ Add entry for BlockhainHub.</p>
<hr />
<div>A [[block chain browser]] is an application, typically web-based, that allow users to search and navigate a [[block chain]].<br />
<br />
== List of online block chain browsers ==<br />
* [https://bitaps.com Bitaps.com]<br />
* [https://bitinfocharts.com/bitcoin/explorer/ BitInfoCharts]<br />
* [https://blockexplorer.com/ Bitcoin Block Explorer]<br />
* [https://bitcoinchain.com/block_explorer/ BitcoinChain]<br />
* [https://btc.blockchainhub.co.jp BlockhainHub]<br />
* [https://www.biteasy.com/blockchain/blocks bitEasy]<br />
* [https://blockchain.info/ Blockchain.info]<br />
* [https://live.blockcypher.com/ BlockCypher]<br />
* [https://www.blockonomics.co/ Blockonomics]<br />
* [https://btc.blockr.io/ blockr]<br />
* [https://www.blocktrail.com/BTC BlockTrail]<br />
* [https://chain.btc.com/ BTC Chain]<br />
* [http://chainflyer.bitflyer.jp/ chainFlyer]<br />
* [http://coinbelly.io/ Coinbelly]<br />
* [https://explorer.coinpayments.net/ CoinPayments]<br />
* [https://www.coinprism.info/ Coinprism]<br />
* [http://learnmeabitcoin.com/explorer/ learnmeabitcoin]<br />
* [https://chain.localbitcoins.com/ LocalBitcoins]<br />
* [https://smartbit.com.au Smartbit]<br />
* [https://chain.so/btc SoChain]<br />
* [https://tradeblock.com/blockchain/ TradeBlock]<br />
* [https://www.walletexplorer.com/ WalletExplorer]<br />
* [http://webbtc.com/ webBTC]<br />
<br />
== List of online block chain browsers (testnet3) ==<br />
* [https://tbtc.blockr.io/ blockr]<br />
* [https://tchain.btc.com/ BTC Chain]<br />
* [https://sandbox.smartbit.com.au/ Smartbit]</div>Sgornickhttps://en.bitcoin.it/w/index.php?title=Research&diff=59971Research2016-01-13T13:28:19Z<p>Sgornick: Since this list is not updated well, add mention at the top about Brett Scott's comprehensive list.</p>
<hr />
<div>Publications including research and analysis of Bitcoin or related areas.<br />
<br />
The list below is now just a subset of a [http://docs.google.com/spreadsheets/d/1VaWhbAj7hWNdiE73P-W-wrl5a0WNgzjofmZXe0Rh5sg/htmlview?usp=sharing&amp;pli=1&amp;sle=true comprehensive list] compiled by [http://twitter.com/@suitpossum Brett Scott].<br />
<br />
{| class=&quot;wikitable sortable&quot;<br />
! Title<br />
! Author<br />
! width=150 | Type<br />
! width=75 | Date<br />
! Links<br />
|-<br />
| Cyberlaundering: Anonymous Digital Cash and Money Laundering<br />
| R. Mark Bortner<br />
| Research paper<br />
| 1996<br />
| [http://osaka.law.miami.edu/~froomkin/seminar/papers/bortner.htm Download]<br />
|-<br />
| Triple Entry Accounting<br />
| Ian Grigg<br />
| Research paper<br />
| 2005-12-25<br />
| [http://iang.org/papers/triple_entry.html Download]<br />
|-<br />
| [[Bitcoin_whitepaper|Bitcoin: A Peer-to-Peer Electronic Cash System]]<br />
| [[Satoshi Nakamoto]]<br />
| Research paper<br />
| 2008-10-31<br />
| [http://bitcoin.org/bitcoin.pdf Download]<br />
|-<br />
| An Analysis of Anonymity in the Bitcoin System<br />
| Fergal Reid, Martin Harrigan<br />
| Research paper<br />
| 2011-07-22<br />
| [http://arxiv.org/abs/1107.4524 Download], [http://bitcointalk.org/index.php?topic=31539.0 discussion]<br />
|-<br />
| Shadowy Figures: Tracking Illicit Financial Transactions in the Murky World of Digital Currencies, Peer–to–Peer Networks, and Mobile Device Payments<br />
| John Villasenor, Cody Monk, Christopher Bronk<br />
| Research paper<br />
| 2011-08-29<br />
| [http://www.bakerinstitute.org/publications/ITP-pub-FinancialTransactions-082911.pdf Download]<br />
|-<br />
| Bitcoin: An Innovative Alternative Digital Currency<br />
| Reuben Grinberg<br />
| Research paper<br />
| 2011-12-09<br />
| [http://papers.ssrn.com/sol3/papers.cfm?abstract_id=1817857 Download], [http://www.bitcointalk.org/index.php?topic=6247.0 discussion]<br />
|-<br />
| Bitcoin NFC<br />
| David Allen Bronleewe<br />
| Master's report<br />
| 2011-08<br />
| [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]<br />
|-<br />
| Optimal pool abuse strategy<br />
| Raulo<br />
| Research paper<br />
| 2011-02-04<br />
| [http://bitcoin.atspace.com/poolcheating.pdf Download], [http://www.bitcointalk.org/index.php?topic=3165.0 discussion]<br />
|-<br />
| Abusing Bitcoin cooperative mining pools: strategies for egoistical but honest miners<br />
| Nakamoto Ryo<br />
| Research paper<br />
| 2011<br />
| [http://www.bitcoinservice.co.uk/files/111 Download], [http://www.bitcointalk.org/index.php?topic=2941.0 discussion]<br />
|-<br />
| Analysis of Bitcoin Pooled Mining Reward Systems<br />
| Meni Rosenfeld<br />
| Research paper<br />
| 2011-11-07<br />
| [https://bitcoil.co.il/pool_analysis.pdf Download], [http://bitcointalk.org/index.php?topic=32814.0 discussion]<br />
|-<br />
| Bitcoin Exchange system<br />
| Tomáš Jiříček<br />
| Research paper<br />
| 2012<br />
| [https://dip.felk.cvut.cz/browse/pdfcache/jiricto2_2012bach.pdf Download]<br />
|-<br />
| On Bitcoin and Red Balloons<br />
| Moshe Babaioff, Shahar Dobzinski, Sigal Oren, Aviv Zohar<br />
| Publication article<br />
| 2012<br />
| [http://research.microsoft.com/pubs/156072/bitcoin.pdf Download]<br />
|-<br />
| 2011 Observations on the Digital Currency Industry<br />
| Mark Herpel<br />
| Publication article<br />
| 2011<br />
| [http://papers.ssrn.com/sol3/papers.cfm?abstract_id=1721076 Download]<br />
|-<br />
| MAVE, New Lightweight Digital Signature Protocols for Massive Verifications<br />
| Sergio Demian Lerner<br />
| Research paper (preliminary)<br />
| 2012<br />
| [http://bitslog.files.wordpress.com/2012/04/mave1.pdf Download]<br />
|-<br />
| MAVEPAY, a New Lightweight Payment Scheme for Peer to Peer Currency Networks<br />
| Sergio Demian Lerner<br />
| Research paper (preliminary)<br />
| 2012<br />
| [http://bitslog.files.wordpress.com/2012/04/mavepay1.pdf Download]<br />
|-<br />
| Bitcoin: Eine erste Einordnung (an initial classification)<br />
| Christoph Sorge, Artus Krohn-Grimberghe<br />
| Research paper<br />
| 2012<br />
| [http://www.springerlink.com/content/cw1v762571tr4462/ Download], [http://bitcointalk.org/index.php?topic=90233.0 discussion]<br />
|-<br />
| Bitcoin - an introduction to the workings and a preliminary analysis and understanding of potential legal issues<br />
| Jean-Daniel Schmid, Alexander Schmid<br />
| Article<br />
| 2012<br />
| [http://ef-r.ch/images/publications/1338882576_Bitcoin.pdf Download]<br />
|-<br />
| Secure multiparty Bitcoin anonymization<br />
| Edward Z. Yang<br />
| Article<br />
| 2012<br />
| [http://blog.ezyang.com/2012/07/secure-multiparty-bitcoin-anonymization/ Download], [http://www.reddit.com/r/Bitcoin/comments/wvm2w/secure_multiparty_bitcoin_anonymization/ discussion]<br />
|-<br />
| Bitcoin &amp; Gresham's Law - the economic inevitability of Collapse<br />
| Philipp Güring, Ian Grigg<br />
| Article<br />
| 2011<br />
| [http://iang.org/papers/BitcoinBreachesGreshamsLaw.pdf Download]<br />
|-<br />
| Today Techies, Tomorrow the World? Bitcoin.<br />
| Reuben Grinberg<br />
| Article<br />
| 2012<br />
| [http://www.milkeninstitute.org/publications/review/2012_1/22-31MR53.pdf Download]<br />
|-<br />
| Traveling the Silk Road: A measurement analysis of a large anonymous online marketplace<br />
| Nicolas Christin<br />
| Research paper<br />
| 2012<br />
| [http://www.cylab.cmu.edu/files/pdfs/tech_reports/CMUCyLab12018.pdf Download]<br />
|-<br />
| CommitCoin: Carbon Dating Commitments with Bitcoin<br />
| Jeremy Clark and Aleksander Essex<br />
| Research paper<br />
| 2012<br />
| [http://people.scs.carleton.ca/~clark/papers/2012_fc.pdf Download extended abstract]&lt;br /&gt;[http://eprint.iacr.org/2011/677.pdf Download technical report]<br />
|-<br />
| Quantitative Analysis of the Full Bitcoin Transaction Graph<br />
| Dorit Ron and Adi Shamir<br />
| Research paper<br />
| 2012<br />
| [http://eprint.iacr.org/2012/584.pdf Download]<br />
|-<br />
| Bitcoin Security<br />
| Robert Pallas<br />
| Master's thesis<br />
| 2012<br />
| [http://robertpallas.github.io/boblog/includes/btc-thesis.pdf Download]<br />
|-<br />
| Design and security analysis of Bitcoin infrastructure using application deployed on Google Apps Engine<br />
| Piotr &quot;ThePiachu&quot; Piasecki<br />
| Master's thesis<br />
| 2012<br />
| [https://dl.dropbox.com/u/3658181/PiotrPiasecki-BitcoinMasterThesis.pdf Download], [https://bitcointalk.org/index.php?topic=88149.0 discussion]<br />
|-<br />
| The Production of Freedom: Value Production in the US- dominated Financial System, and Possible Alternatives<br />
| Jeremy Kirshbaum<br />
| Master's thesis (preliminary)<br />
| 2012<br />
| [https://docs.google.com/document/d/1JIyMWIibqH8x20vGBTMBZ2yqM7Xbp54UpWBh0o2H7WI/edit?pli=1 Download], [https://bitcointalk.org/index.php?topic=87404.0 discussion]<br />
|-<br />
| COIN: a distributed accounting system for peer to peer networks<br />
| Fabio Varesano<br />
| Bachelor's thesis<br />
| 2012<br />
| [http://www.varesano.net/contents/projects/coin%20distributed%20accounting%20system%20peer%20peer%20networks Download]<br />
|-<br />
| BITCOIN CLIENTS<br />
| Rostislav Skudnov<br />
| Bachelor's thesis<br />
| 2012<br />
| [http://publications.theseus.fi/bitstream/handle/10024/47166/Skudnov_Rostislav.pdf?sequence=1 Download]<br />
|-<br />
| Bitter to Better—How to Make Bitcoin a Better Currency<br />
| Simon Barber, Xavier Boyen, Elaine Shi, Ersin Uzun<br />
| Research paper<br />
| 2012<br />
| [http://crypto.stanford.edu/~xb/fc12/bitcoin.pdf Download]<br />
|-<br />
| NooShare: A decentralized ledger of shared computational resources<br />
| Alex Coventry<br />
| Research paper<br />
| 2012<br />
| [http://mit.edu/alex_c/www/nooshare.pdf Download]<br />
|-<br />
| Bits and Bets. Information, Price Volatility, and Demand for Bitcoin<br />
| Martis Buchholz, Jess Delaney, Joseph Warren<br />
| Final project<br />
| 2012<br />
| [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]<br />
|-<br />
| Two Bitcoins at the Price of One? Double Spending attacks on Fast Payments in Bitcoin<br />
| Ghassan O. Karame, Elli Androulaki, Srdjan Cap-kun <br />
| Research paper<br />
| 2012<br />
| [http://eprint.iacr.org/2012/248 Download]<br />
|-<br />
| Nerdy Money: Bitcoin, the Private Digital Currency, and the Case Against Its Regulation<br />
| Nikolei M. Kaplanov<br />
| Research paper<br />
| 2012<br />
| [http://papers.ssrn.com/sol3/papers.cfm?abstract_id=2115203 Abstract]<br />
|-<br />
| Analysis of hashrate-based double-spending<br />
| Meni Rosenfeld<br />
| Research paper<br />
| 2012<br />
| [https://bitcoil.co.il/Doublespend.pdf Download]<br />
|-<br />
| Homomorphic Payment Addresses and the Pay-to-Contract Protocol<br />
| Ilja Gerhardt, Timo Hanke<br />
| Research Paper<br />
| 2012<br />
| [http://arxiv.org/pdf/1212.3257v1 Download] ([http://docs.google.com/viewer?url=http%3A%2F%2Farxiv.org%2Fpdf%2F1212.325qq7v1 via web viewer])<br />
|-<br />
| Quasi-Commodity Money (February 6, 2012). &quot;This paper considers reform possibilities posed by a type of base money that has heretofore been overlooked in the literature on monetary economics.&quot;<br />
| George Selgin<br />
| Working Papers Series<br />
| 2012<br />
| [http://ssrn.com/abstract=2000118 Download]<br />
|-<br />
| Virtual currency schemes - &quot;This report is a first attempt to provide the basis for a discussion on virtual currency schemes.&quot;<br />
| European Central Bank<br />
| Paper<br />
| 2012<br />
| [http://www.ecb.europa.eu/pub/pdf/other/virtualcurrencyschemes201210en.pdf Download]<br />
|-<br />
| Evaluating User Privacy in Bitcoin<br />
| Elli Androulaki, Ghassan Karame, Marc Roeschlin, Tobias Scherer and Srdjan Capkun <br />
| Paper<br />
| 2013<br />
| [http://fc13.ifca.ai/proc/1-3.pdf Download] ([http://fc13.ifca.ai/slide/1-3.pdf Slides]) <br />
|-<br />
| Beware the Middleman: Empirical Analysis of Bitcoin-Exchange Risk<br />
| Tyler Moore and Nicolas Christin <br />
| Short Paper<br />
| 2013<br />
| [http://fc13.ifca.ai/proc/1-2.pdf Download] ([http://fc13.ifca.ai/slide/1-2.pdf Slides]) <br />
|-<br />
| Bitcoin, Regulating Fraud In The E-Conomy Of Hacker-Cash<br />
| Derek A. Dion<br />
| Paper<br />
| 2013<br />
| [http://illinoisjltp.com/journal/wp-content/uploads/2013/05/Dion.pdf Download]<br />
|-<br />
| The practical materiality of Bitcoin<br />
| Bill Maurera, Taylor C. Nelmsa &amp; Lana Swartz <br />
| Paper<br />
| 2013<br />
| [http://www.tandfonline.com/doi/full/10.1080/10350330.2013.777594#.UbbTVaD_6b4 Download]<br />
|-<br />
| Regulating Digital Currencies: Bringing Bitcoin within the Reach of the IMF<br />
| Nicholas Plassaras <br />
| Paper<br />
| 2013<br />
| [https://papers.ssrn.com/sol3/papers.cfm?abstract_id=2248419 Download]<br />
|-<br />
| Bitcoin is Memory<br />
| William J. Luther, Josiah Olson <br />
| Paper<br />
| 2013<br />
| [http://papers.ssrn.com/sol3/papers.cfm?abstract_id=2275730 Download]<br />
|-<br />
| The Economics of Bitcoin Mining or, Bitcoin in the Presence of Adversaries<br />
| Joshua A. Kroll, Ian C. Davey, and Edward W. Felten <br />
| Paper<br />
| 2013<br />
| [http://www.weis2013.econinfosec.org/papers/KrollDaveyFeltenWEIS2013.pdf Download]<br />
|-<br />
| Bitcoin: A Primer for Policymakers<br />
| Jerry Brito, Andrea Castillo<br />
| Research paper<br />
| 2013<br />
| [http://mercatus.org/publication/bitcoin-primer-policymakers Abstract] [http://mercatus.org/sites/default/files/Brito_BitcoinPrimer.pdf Download]<br />
|-<br />
| Whack-a-Mole: Prosecuting Digital Currency Exchanges<br />
| Catherine Martin Christopher <br />
| Research paper<br />
| 2013<br />
| [http://papers.ssrn.com/sol3/papers.cfm?abstract_id=2312787 Abstract]<br />
[http://papers.ssrn.com/sol3/Delivery.cfm/SSRN_ID2312787_code1372021.pdf?abstractid=2312787&amp;mirid=2 Download]<br />
|-<br />
| Are Cryptocurrencies 'Super' Tax Havens?<br />
| Omri Y. Marian<br />
| Research paper<br />
| 2013<br />
| [http://papers.ssrn.com/sol3/papers.cfm?abstract_id=2305863 Abstract]<br />
[http://papers.ssrn.com/sol3/Delivery.cfm/SSRN_ID2316499_code592645.pdf?abstractid=2305863&amp;mirid=1 Download]<br />
|-<br />
| Collective Emergent Institutional Entrepreneurship Through Bitcoin<br />
| Robin Teigland, Zeynep Yetis and Tomas Olov Larsson <br />
| Research paper<br />
| 2013<br />
| [http://papers.ssrn.com/sol3/papers.cfm?abstract_id=2263707 Abstract]<br />
[http://papers.ssrn.com/sol3/Delivery.cfm/SSRN_ID2263707_code2053543.pdf?abstractid=2263707&amp;mirid=1 Download]<br />
|-<br />
| Anonymity of Bitcoin Transactions<br />
| Malte Möser<br />
| Research paper<br />
| 2013<br />
| [https://www.wi.uni-muenster.de/sites/default/files/public/department/itsecurity/mbc13/mbc13-moeser-paper.pdf Download]<br />
|-<br />
| On the origins of Bitcoin: Stages of monetary evolution<br />
| Konrad S. Graf <br />
| Research paper<br />
| 2013<br />
| [http://konradsgraf.com/blog1/2013/10/23/on-the-origins-of-bitcoin-my-new-work-on-bitcoin-and-monetar.html Abstract]<br />
[http://konradsgraf.com/storage/On%20the%20Origins%20of%20Bitcoin%20Graf%2023.10.13.pdf Download]<br />
|-<br />
| Majority is not Enough: Bitcoin Mining is Vulnerable<br />
| Ittay Eyal and Emin Gun Sirer<br />
| Research paper<br />
| 2013<br />
| [http://arxiv.org/abs/1311.0243 Abstract]<br />
[http://arxiv.org/pdf/1311.0243v1 Download]<br />
|-<br />
| Bitcoin, the end of the Taboo on Money<br />
| Denis Roio aka Jaromil<br />
| Humanities article<br />
| 2013<br />
| [http://www.dyndy.net/2013/04/bitcoin-ends-the-taboo-on-money/ Abstract]<br />
[https://files.dyne.org/readers/Bitcoin_end_of_taboo_on_money.pdf Download]<br />
|-<br />
| Secure Multiparty Computations on BitCoin<br />
| Marcin Andrychowicz, Stefan Dziembowski, Daniel Malinowski and Łukasz Mazurek University of Warsaw <br />
| Research paper<br />
| 2013<br />
| [http://eprint.iacr.org/2013/784 Abstract]<br />
[http://eprint.iacr.org/eprint-bin/cite.pl?entry=2013/784 BibTeX]<br />
[http://eprint.iacr.org/2013/784.pdf Download]<br />
|-<br />
| A Fistful of Bitcoins: Characterizing Payments Among Men with No Names<br />
| Sarah Meiklejohn, Marjori Pomarole, Grant Jordan, Kirill Levchenko, Damon McCoy, Geoffrey M. Voelker, Stefan Savage<br />
| Research paper<br />
| 2013<br />
| <br />
[http://www.cs.gmu.edu/~mccoy/papers/imc13.pdf Download]<br />
|-<br />
| Information Propagation in the Bitcoin Network<br />
| Christian Decker (ETH Zurich, Switzerland), Roger Wattenhofer (Microsoft Research)<br />
| Research paper<br />
| 2013<br />
| <br />
[http://www.tik.ee.ethz.ch/file/49318d3f56c1d525aabf7fda78b23fc0/P2P2013_041.pdf Download]<br />
|-<br />
| Have a Snack, Pay with Bitcoins<br />
| Tobias Bamert, Christian Decker, Lennart Elsen, Roger Wattenhofer, Samuel Welten<br />
| Research paper<br />
| 2013<br />
| <br />
[http://www.tik.ee.ethz.ch/file/848064fa2e80f88a57aef43d7d5956c6/P2P2013_093.pdf Download]<br />
|-<br />
| The Economics of Private Digital Currency<br />
| Gerald P Dwyer<br />
| Research paper<br />
| 2014<br />
| [http://mpra.ub.uni-muenchen.de/55824/ Abstract]<br />
[http://mpra.ub.uni-muenchen.de/55824/1/MPRA_paper_55824.pdf Download]<br />
|-<br />
| The Origin, Classification and Utility of Bitcoin<br />
| Peter Šurda <br />
| Research Paper<br />
| 2014<br />
| [http://papers.ssrn.com/sol3/papers.cfm?abstract_id=2436823 Abstract]<br />
|-<br />
| Deanonymisation of clients in Bitcoin P2P network<br />
| Alex Biryukov, Dmitry Khovratovich and Ivan Pustogarov<br />
| Research Paper<br />
| 2014<br />
| [http://arxiv.org/abs/1405.7418 Abstract] [http://arxiv.org/pdf/1405.7418v2.pdf Download]<br />
|-<br />
| Bitcoin Financial Regulation: Securities, Derivatives, Prediction Markets, &amp; Gambling<br />
| Jerry Brito, Houman B. Shadab, Andrea Castillo<br />
| Research Paper<br />
| 2014<br />
| [http://papers.ssrn.com/sol3/papers.cfm?abstract_id=2423461 Abstract] [http://papers.ssrn.com/sol3/Delivery.cfm/SSRN_ID2426195_code510873.pdf?abstractid=2423461&amp;mirid=1 Download]<br />
|-<br />
| What are the main drivers of the Bitcoin price?<br />
| Ladislav Kristoufek<br />
| Research Paper<br />
| 2014<br />
| [http://arxiv.org/pdf/1406.0268v1.pdf Download]<br />
|-<br />
| The Economics of Bitcoin<br />
| Andre Herman<br />
| Bachelor's thesis<br />
| 2014<br />
| [http://www.scribd.com/doc/231964435/The-Economics-of-Bitcoin Download]<br />
|-<br />
| Near Zero Bitcoin Transaction Fees Cannot Last Forever<br />
| Kerem Kaşkaloğlu<br />
| Research Paper<br />
| 2014<br />
| [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]<br />
|-<br />
| Is Bitcoin Money?<br />
| Ísak Andri Ólafsson<br />
| Thesis Paper<br />
| 2014<br />
| [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]<br />
|-<br />
| The (A)Political Economy of Bitcoin<br />
| Vasilis Kostakis and Chris Giotitsas<br />
| Essay<br />
| 2014<br />
| [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]<br />
|-<br />
| When your sensor earns money: exchanging data for cash with Bitcoin<br />
| Dominic Wörner and Thomas von Bomhard<br />
| Research<br />
| 2014<br />
| [http://dl.acm.org/citation.cfm?id=2638786 Abstract] [http://dl.acm.org/ft_gateway.cfm?id=2638786&amp;ftid=1500778&amp;dwn=1&amp;CFID=579517323&amp;CFTOKEN=37552107 Download]<br />
|-<br />
| Bitcoin Transaction Malleability and MtGox <br />
| Christian Decker, Roger Wattenhofer<br />
| Research<br />
| 2014<br />
| [http://www.tik.ee.ethz.ch/file/7e4a7f3f2991784786037285f4876f5c/malleability.pdf Download]<br />
|-<br />
| BlueWallet: The Secure Bitcoin Wallet<br />
| Tobias Bamert, Christian Decker, Roger Wattenhofer and Samuel Welten<br />
| Research<br />
| 2014<br />
| [http://www.tik.ee.ethz.ch/file/0c347a9a3803cb937d360cba511e5019/stm2014_submission_12.pdf Download]<br />
|-<br />
| Bitcoin over Tor isn’t a good idea<br />
| Alex Biryukov and Ivan Pustogarov<br />
| Research<br />
| 2014<br />
| [http://arxiv.org/pdf/1410.6079v1.pdf Download]<br />
|-<br />
| Sidechained Bitcoin Substitutes, A Monetary Commentary<br />
| Konrad S. Graf<br />
| Essay<br />
| 2014<br />
| [http://konradsgraf.squarespace.com/storage/Monetary%20analsyis%20of%20sidecoins%20KG%2024Oct2014.pdf Download]<br />
|-<br />
| Taxation of virtual currency<br />
| Aleksandra Bal<br />
| PhD thesis<br />
| 2014<br />
| [http://hdl.handle.net/1887/29963 Abstract] [https://openaccess.leidenuniv.nl/bitstream/handle/1887/29963/000-5-Bal-14-10-2014.pdf Download]<br />
|-<br />
| A First Look at the Usability of Bitcoin Key Management<br />
| Shayan Eskandari, David Barrera, Elizabeth Stobert, and Jeremy Clark<br />
| Research Paper<br />
| 2015<br />
| [http://www.internetsociety.org/sites/default/files/05_3_3.pdf Download]<br />
|-<br />
| Privacy in Bitcoin through decentralized mixers<br />
| Olivier Coutu<br />
| Master's thesis<br />
| 2015<br />
| [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]<br />
|-<br />
| Value Creation in Cryptocurrency Networks: Towards A Taxonomy of Digital Business Models for Bitcoin Companies<br />
| Erol Kazan, Chee-Wee Tan, Eric T.K. Lim<br />
| Research Paper<br />
| 2015<br />
| [http://aisel.aisnet.org/pacis2015/34/ Abstract] [http://aisel.aisnet.org/cgi/viewcontent.cgi?article=1222&amp;context=pacis2015 Download]<br />
|-<br />
| Authenticated Key Exchange over Bitcoin<br />
| Patrick McCorry, Siamak F. Shahandashti, Dylan Clarke, Feng Hao<br />
| Research Paper<br />
| 2015<br />
| [http://eprint.iacr.org/2015/308.pdf Download]<br />
|-<br />
| Bitcoin and Beyond: A Technical Survey on Decentralized Digital Currencies<br />
| Florian Tschorsch and Björn Scheuermann<br />
| Research Paper<br />
| 2015<br />
| [http://eprint.iacr.org/2015/464.pdf Download]<br />
|-<br />
| Bitcoin Duplex Micropayment Channels<br />
| Christian Decker and Roger Wattenhofer<br />
| Research Paper<br />
| 2015<br />
| [http://www.tik.ee.ethz.ch/file/716b955c130e6c703fac336ea17b1670/duplex-micropayment-channels.pdf Download]<br />
|-<br />
| The Bitcoin Lightning Network: Scalable Off-Chain Instant Payments<br />
| Joseph Poon and Thaddeus Dryja<br />
| Research Paper<br />
| 2015<br />
| [http://lightning.network/lightning-network-paper.pdf Download]<br />
|-<br />
| Bitcoin and the Uniform Commercial Code<br />
| Jeanne L. Schroeder<br />
| Research Paper<br />
| 2015<br />
| [http://papers.ssrn.com/sol3/papers.cfm?abstract_id=2649441 Abstract] [http://papers.ssrn.com/sol3/Delivery.cfm/SSRN_ID2649441_code1717611.pdf?abstractid=2649441&amp;mirid=1 Download]<br />
|-<br />
| Economics beyond Financial Intermediation<br />
| Saifedean Ammous<br />
| Research Paper<br />
| 2015<br />
| [http://journal.apee.org/index.php?title=2015_Journal_of_Private_Enterprise_vol_30_no_3_parte2.pdf Download]<br />
|-<br />
| Bitcoin and the Future of Digital Payments<br />
| William J. Luther<br />
| Research Paper<br />
| 2015<br />
| [http://papers.ssrn.com/sol3/Papers.cfm?abstract_id=2631314 Abstract] [http://papers.ssrn.com/sol3/Delivery.cfm/SSRN_ID2631314_code1352425.pdf?abstractid=2631314&amp;mirid=1 Download]<br />
|<br />
|-<br />
| Profitability from Mining Bitcoins: Should You Still Enter the Bitcoin Mining Competition? Long-Term Simulation Analysis of the Profitability for a Single Miner<br />
| Kärt Viilup<br />
| Master's thesis<br />
| 2015<br />
| [http://dspace.ut.ee/bitstream/handle/10062/47208/viilup_kart.pdf Download]<br />
|-<br />
| Secure Bitcoin Wallet<br />
| Sevil Guler<br />
| Master's thesis<br />
| 2015<br />
| [http://comserv.cs.ut.ee/forms/ati_report/downloader.php?file=BAE4173CEBB722554EB452F64CFE7C9A2D2391D5 Download]<br />
|-<br />
| Development of Universal Cryptocurrency Wallet Services: A Case Study of Bitplexus<br />
| Priidu Neemre<br />
| Master's thesis<br />
| 2016<br />
| [http://nemp.planet.ee/Development_of_Universal_Cryptocurrency_Wallet_Services_-_A_Case_Study_of_Bitplexus.pdf Download]<br />
|}<br />
<br />
==See Also==<br />
<br />
* [http://encryptopedia.com/ Encryptopedia - Scientific research and white papers on bitcoin, blockchain technology, cryptography, algorithms and cryptocurrencies]<br />
* [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&amp;pli=1&amp;sle=true Full List])<br />
* [http://www.opencryptocurrencyreview.com/ OpenCryptocurrencyReview - A repository of Bitcoin and related research]<br />
* [http://people.scs.carleton.ca/~clark/biblio.html Jeremy Clark's Bitcoin Bibliography]<br />
* [[:Category:Economics|Economic]]<br />
* [[:Category:Technical|Technical]]<br />
* [[Press]]<br />
<br />
[[Category:Research]]</div>Sgornickhttps://en.bitcoin.it/w/index.php?title=Hardfork&diff=59970Hardfork2016-01-13T13:23:04Z<p>Sgornick: Add See Also subsection and move Softfork as an entry into it.</p>
<hr />
<div>A hardfork is a change to the bitcoin protocol that makes previously invalid blocks/transactions valid, and therefore requires all users to upgrade.<br />
<br />
Any alteration to bitcoin which changes the block structure (including block hash), difficulty rules, or increases the set of valid transactions is a hardfork.<br />
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.<br />
This is known as a [[softfork]], and how [[P2SH]] was added to Bitcoin.<br />
<br />
==See Also==<br />
* [[Softfork]]</div>Sgornickhttps://en.bitcoin.it/w/index.php?title=Softfork&diff=59969Softfork2016-01-13T13:21:33Z<p>Sgornick: Add See Also section and move Hardfork reference as an entry into it.</p>
<hr />
<div>A softfork is a change to the bitcoin protocol wherein only previously valid blocks/transactions are made invalid.<br />
Since old nodes will recognise the new blocks as valid, a softfork is backward-compatible.<br />
This kind of fork requires only a majority of the miners upgrading to enforce the new rules.<br />
<br />
New transaction types can often be added as softforks, requiring only that the participants (sender and receiver) and miners understand the new transaction type.<br />
This is done by having the new transaction appear to older clients as a &quot;pay-to-anybody&quot; 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.<br />
This is how [[P2SH]] was added to Bitcoin.<br />
<br />
==Mechanism==<br />
<br />
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).<br />
<br />
Generally softforks accomplish something more useful, for example Pay-to-Script-Hash ([[P2SH]]) was a softfork. Originally the script &quot;OP_HASH160 [20-byte-hash-value] OP_EQUAL&quot; 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 &quot;OP_HASH160 [20-byte-hash-value] OP_EQUAL&quot; 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.<br />
<br />
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 [[BIP12]] OP_EVAL is 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 OP_EVAL behavior and once with it's 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.<br />
<br />
==Security==<br />
<br />
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 &quot;fake confirmation&quot; 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 &quot;mainchain&quot; allowing the attacker to attempt to [[Double-spending|doublespend]].<br />
<br />
These attacks can be avoided by upgrading your client, however if the vast majority of miners (&gt;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.<br />
<br />
===2015 BIP66 Blockchain Fork===<br />
<br />
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 (&gt;=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 &quot;agreed&quot; to not do so. This led to a 6 block fork that was resolved after contacting the F2Pool and Antminer pool owners.<br />
<br />
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.<br />
<br />
==Implications==<br />
<br />
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.<br />
<br />
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.<br />
<br />
==See Also==<br />
* [[Hardfork]]</div>Sgornickhttps://en.bitcoin.it/w/index.php?title=Research&diff=59783Research2015-12-30T13:52:18Z<p>Sgornick: Add Bitcoin and the Future of Digital Payments by William J. Luther.</p>
<hr />
<div>Publications including research and analysis of Bitcoin or related areas.<br />
<br />
{| class=&quot;wikitable sortable&quot;<br />
! Title<br />
! Author<br />
! width=150 | Type<br />
! width=75 | Date<br />
! Links<br />
|-<br />
| Cyberlaundering: Anonymous Digital Cash and Money Laundering<br />
| R. Mark Bortner<br />
| Research paper<br />
| 1996<br />
| [http://osaka.law.miami.edu/~froomkin/seminar/papers/bortner.htm Download]<br />
|-<br />
| Triple Entry Accounting<br />
| Ian Grigg<br />
| Research paper<br />
| 2005-12-25<br />
| [http://iang.org/papers/triple_entry.html Download]<br />
|-<br />
| [[Bitcoin_whitepaper|Bitcoin: A Peer-to-Peer Electronic Cash System]]<br />
| [[Satoshi Nakamoto]]<br />
| Research paper<br />
| 2008-10-31<br />
| [http://bitcoin.org/bitcoin.pdf Download]<br />
|-<br />
| An Analysis of Anonymity in the Bitcoin System<br />
| Fergal Reid, Martin Harrigan<br />
| Research paper<br />
| 2011-07-22<br />
| [http://arxiv.org/abs/1107.4524 Download], [http://bitcointalk.org/index.php?topic=31539.0 discussion]<br />
|-<br />
| Shadowy Figures: Tracking Illicit Financial Transactions in the Murky World of Digital Currencies, Peer–to–Peer Networks, and Mobile Device Payments<br />
| John Villasenor, Cody Monk, Christopher Bronk<br />
| Research paper<br />
| 2011-08-29<br />
| [http://www.bakerinstitute.org/publications/ITP-pub-FinancialTransactions-082911.pdf Download]<br />
|-<br />
| Bitcoin: An Innovative Alternative Digital Currency<br />
| Reuben Grinberg<br />
| Research paper<br />
| 2011-12-09<br />
| [http://papers.ssrn.com/sol3/papers.cfm?abstract_id=1817857 Download], [http://www.bitcointalk.org/index.php?topic=6247.0 discussion]<br />
|-<br />
| Bitcoin NFC<br />
| David Allen Bronleewe<br />
| Master's report<br />
| 2011-08<br />
| [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]<br />
|-<br />
| Optimal pool abuse strategy<br />
| Raulo<br />
| Research paper<br />
| 2011-02-04<br />
| [http://bitcoin.atspace.com/poolcheating.pdf Download], [http://www.bitcointalk.org/index.php?topic=3165.0 discussion]<br />
|-<br />
| Abusing Bitcoin cooperative mining pools: strategies for egoistical but honest miners<br />
| Nakamoto Ryo<br />
| Research paper<br />
| 2011<br />
| [http://www.bitcoinservice.co.uk/files/111 Download], [http://www.bitcointalk.org/index.php?topic=2941.0 discussion]<br />
|-<br />
| Analysis of Bitcoin Pooled Mining Reward Systems<br />
| Meni Rosenfeld<br />
| Research paper<br />
| 2011-11-07<br />
| [https://bitcoil.co.il/pool_analysis.pdf Download], [http://bitcointalk.org/index.php?topic=32814.0 discussion]<br />
|-<br />
| Bitcoin Exchange system<br />
| Tomáš Jiříček<br />
| Research paper<br />
| 2012<br />
| [https://dip.felk.cvut.cz/browse/pdfcache/jiricto2_2012bach.pdf Download]<br />
|-<br />
| On Bitcoin and Red Balloons<br />
| Moshe Babaioff, Shahar Dobzinski, Sigal Oren, Aviv Zohar<br />
| Publication article<br />
| 2012<br />
| [http://research.microsoft.com/pubs/156072/bitcoin.pdf Download]<br />
|-<br />
| 2011 Observations on the Digital Currency Industry<br />
| Mark Herpel<br />
| Publication article<br />
| 2011<br />
| [http://papers.ssrn.com/sol3/papers.cfm?abstract_id=1721076 Download]<br />
|-<br />
| MAVE, New Lightweight Digital Signature Protocols for Massive Verifications<br />
| Sergio Demian Lerner<br />
| Research paper (preliminary)<br />
| 2012<br />
| [http://bitslog.files.wordpress.com/2012/04/mave1.pdf Download]<br />
|-<br />
| MAVEPAY, a New Lightweight Payment Scheme for Peer to Peer Currency Networks<br />
| Sergio Demian Lerner<br />
| Research paper (preliminary)<br />
| 2012<br />
| [http://bitslog.files.wordpress.com/2012/04/mavepay1.pdf Download]<br />
|-<br />
| Bitcoin: Eine erste Einordnung (an initial classification)<br />
| Christoph Sorge, Artus Krohn-Grimberghe<br />
| Research paper<br />
| 2012<br />
| [http://www.springerlink.com/content/cw1v762571tr4462/ Download], [http://bitcointalk.org/index.php?topic=90233.0 discussion]<br />
|-<br />
| Bitcoin - an introduction to the workings and a preliminary analysis and understanding of potential legal issues<br />
| Jean-Daniel Schmid, Alexander Schmid<br />
| Article<br />
| 2012<br />
| [http://ef-r.ch/images/publications/1338882576_Bitcoin.pdf Download]<br />
|-<br />
| Secure multiparty Bitcoin anonymization<br />
| Edward Z. Yang<br />
| Article<br />
| 2012<br />
| [http://blog.ezyang.com/2012/07/secure-multiparty-bitcoin-anonymization/ Download], [http://www.reddit.com/r/Bitcoin/comments/wvm2w/secure_multiparty_bitcoin_anonymization/ discussion]<br />
|-<br />
| Bitcoin &amp; Gresham's Law - the economic inevitability of Collapse<br />
| Philipp Güring, Ian Grigg<br />
| Article<br />
| 2011<br />
| [http://iang.org/papers/BitcoinBreachesGreshamsLaw.pdf Download]<br />
|-<br />
| Today Techies, Tomorrow the World? Bitcoin.<br />
| Reuben Grinberg<br />
| Article<br />
| 2012<br />
| [http://www.milkeninstitute.org/publications/review/2012_1/22-31MR53.pdf Download]<br />
|-<br />
| Traveling the Silk Road: A measurement analysis of a large anonymous online marketplace<br />
| Nicolas Christin<br />
| Research paper<br />
| 2012<br />
| [http://www.cylab.cmu.edu/files/pdfs/tech_reports/CMUCyLab12018.pdf Download]<br />
|-<br />
| CommitCoin: Carbon Dating Commitments with Bitcoin<br />
| Jeremy Clark and Aleksander Essex<br />
| Research paper<br />
| 2012<br />
| [http://people.scs.carleton.ca/~clark/papers/2012_fc.pdf Download extended abstract]&lt;br /&gt;[http://eprint.iacr.org/2011/677.pdf Download technical report]<br />
|-<br />
| Quantitative Analysis of the Full Bitcoin Transaction Graph<br />
| Dorit Ron and Adi Shamir<br />
| Research paper<br />
| 2012<br />
| [http://eprint.iacr.org/2012/584.pdf Download]<br />
|-<br />
| Design and security analysis of Bitcoin infrastructure using application deployed on Google Apps Engine<br />
| Piotr &quot;ThePiachu&quot; Piasecki<br />
| Master's thesis<br />
| 2012<br />
| [https://dl.dropbox.com/u/3658181/PiotrPiasecki-BitcoinMasterThesis.pdf Download], [https://bitcointalk.org/index.php?topic=88149.0 discussion]<br />
|-<br />
| The Production of Freedom: Value Production in the US- dominated Financial System, and Possible Alternatives<br />
| Jeremy Kirshbaum<br />
| Master's thesis (preliminary)<br />
| 2012<br />
| [https://docs.google.com/document/d/1JIyMWIibqH8x20vGBTMBZ2yqM7Xbp54UpWBh0o2H7WI/edit?pli=1 Download], [https://bitcointalk.org/index.php?topic=87404.0 discussion]<br />
|-<br />
| COIN: a distributed accounting system for peer to peer networks<br />
| Fabio Varesano<br />
| Bachelor's thesis<br />
| 2012<br />
| [http://www.varesano.net/contents/projects/coin%20distributed%20accounting%20system%20peer%20peer%20networks Download]<br />
|-<br />
| BITCOIN CLIENTS<br />
| Rostislav Skudnov<br />
| Bachelor's thesis<br />
| 2012<br />
| [http://publications.theseus.fi/bitstream/handle/10024/47166/Skudnov_Rostislav.pdf?sequence=1 Download]<br />
|-<br />
| Bitter to Better—How to Make Bitcoin a Better Currency<br />
| Simon Barber, Xavier Boyen, Elaine Shi, Ersin Uzun<br />
| Research paper<br />
| 2012<br />
| [http://crypto.stanford.edu/~xb/fc12/bitcoin.pdf Download]<br />
|-<br />
| NooShare: A decentralized ledger of shared computational resources<br />
| Alex Coventry<br />
| Research paper<br />
| 2012<br />
| [http://mit.edu/alex_c/www/nooshare.pdf Download]<br />
|-<br />
| Bits and Bets. Information, Price Volatility, and Demand for Bitcoin<br />
| Martis Buchholz, Jess Delaney, Joseph Warren<br />
| Final project<br />
| 2012<br />
| [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]<br />
|-<br />
| Two Bitcoins at the Price of One? Double Spending attacks on Fast Payments in Bitcoin<br />
| Ghassan O. Karame, Elli Androulaki, Srdjan Cap-kun <br />
| Research paper<br />
| 2012<br />
| [http://eprint.iacr.org/2012/248 Download]<br />
|-<br />
| Nerdy Money: Bitcoin, the Private Digital Currency, and the Case Against Its Regulation<br />
| Nikolei M. Kaplanov<br />
| Research paper<br />
| 2012<br />
| [http://papers.ssrn.com/sol3/papers.cfm?abstract_id=2115203 Abstract]<br />
|-<br />
| Analysis of hashrate-based double-spending<br />
| Meni Rosenfeld<br />
| Research paper<br />
| 2012<br />
| [https://bitcoil.co.il/Doublespend.pdf Download]<br />
|-<br />
| Homomorphic Payment Addresses and the Pay-to-Contract Protocol<br />
| Ilja Gerhardt, Timo Hanke<br />
| Research Paper<br />
| 2012<br />
| [http://arxiv.org/pdf/1212.3257v1 Download] ([http://docs.google.com/viewer?url=http%3A%2F%2Farxiv.org%2Fpdf%2F1212.325qq7v1 via web viewer])<br />
|-<br />
| Quasi-Commodity Money (February 6, 2012). &quot;This paper considers reform possibilities posed by a type of base money that has heretofore been overlooked in the literature on monetary economics.&quot;<br />
| George Selgin<br />
| Working Papers Series<br />
| 2012<br />
| [http://ssrn.com/abstract=2000118 Download]<br />
|-<br />
| Virtual currency schemes - &quot;This report is a first attempt to provide the basis for a discussion on virtual currency schemes.&quot;<br />
| European Central Bank<br />
| Paper<br />
| 2012<br />
| [http://www.ecb.europa.eu/pub/pdf/other/virtualcurrencyschemes201210en.pdf Download]<br />
|-<br />
| Evaluating User Privacy in Bitcoin<br />
| Elli Androulaki, Ghassan Karame, Marc Roeschlin, Tobias Scherer and Srdjan Capkun <br />
| Paper<br />
| 2013<br />
| [http://fc13.ifca.ai/proc/1-3.pdf Download] ([http://fc13.ifca.ai/slide/1-3.pdf Slides]) <br />
|-<br />
| Beware the Middleman: Empirical Analysis of Bitcoin-Exchange Risk<br />
| Tyler Moore and Nicolas Christin <br />
| Short Paper<br />
| 2013<br />
| [http://fc13.ifca.ai/proc/1-2.pdf Download] ([http://fc13.ifca.ai/slide/1-2.pdf Slides]) <br />
|-<br />
| Bitcoin, Regulating Fraud In The E-Conomy Of Hacker-Cash<br />
| Derek A. Dion<br />
| Paper<br />
| 2013<br />
| [http://illinoisjltp.com/journal/wp-content/uploads/2013/05/Dion.pdf Download]<br />
|-<br />
| The practical materiality of Bitcoin<br />
| Bill Maurera, Taylor C. Nelmsa &amp; Lana Swartz <br />
| Paper<br />
| 2013<br />
| [http://www.tandfonline.com/doi/full/10.1080/10350330.2013.777594#.UbbTVaD_6b4 Download]<br />
|-<br />
| Regulating Digital Currencies: Bringing Bitcoin within the Reach of the IMF<br />
| Nicholas Plassaras <br />
| Paper<br />
| 2013<br />
| [https://papers.ssrn.com/sol3/papers.cfm?abstract_id=2248419 Download]<br />
|-<br />
| Bitcoin is Memory<br />
| William J. Luther, Josiah Olson <br />
| Paper<br />
| 2013<br />
| [http://papers.ssrn.com/sol3/papers.cfm?abstract_id=2275730 Download]<br />
|-<br />
| The Economics of Bitcoin Mining or, Bitcoin in the Presence of Adversaries<br />
| Joshua A. Kroll, Ian C. Davey, and Edward W. Felten <br />
| Paper<br />
| 2013<br />
| [http://www.weis2013.econinfosec.org/papers/KrollDaveyFeltenWEIS2013.pdf Download]<br />
|-<br />
| Bitcoin: A Primer for Policymakers<br />
| Jerry Brito, Andrea Castillo<br />
| Research paper<br />
| 2013<br />
| [http://mercatus.org/publication/bitcoin-primer-policymakers Abstract] [http://mercatus.org/sites/default/files/Brito_BitcoinPrimer.pdf Download]<br />
|-<br />
| Whack-a-Mole: Prosecuting Digital Currency Exchanges<br />
| Catherine Martin Christopher <br />
| Research paper<br />
| 2013<br />
| [http://papers.ssrn.com/sol3/papers.cfm?abstract_id=2312787 Abstract]<br />
[http://papers.ssrn.com/sol3/Delivery.cfm/SSRN_ID2312787_code1372021.pdf?abstractid=2312787&amp;mirid=2 Download]<br />
|-<br />
| Are Cryptocurrencies 'Super' Tax Havens?<br />
| Omri Y. Marian<br />
| Research paper<br />
| 2013<br />
| [http://papers.ssrn.com/sol3/papers.cfm?abstract_id=2305863 Abstract]<br />
[http://papers.ssrn.com/sol3/Delivery.cfm/SSRN_ID2316499_code592645.pdf?abstractid=2305863&amp;mirid=1 Download]<br />
|-<br />
| Collective Emergent Institutional Entrepreneurship Through Bitcoin<br />
| Robin Teigland, Zeynep Yetis and Tomas Olov Larsson <br />
| Research paper<br />
| 2013<br />
| [http://papers.ssrn.com/sol3/papers.cfm?abstract_id=2263707 Abstract]<br />
[http://papers.ssrn.com/sol3/Delivery.cfm/SSRN_ID2263707_code2053543.pdf?abstractid=2263707&amp;mirid=1 Download]<br />
|-<br />
| Anonymity of Bitcoin Transactions<br />
| Malte Möser<br />
| Research paper<br />
| 2013<br />
| [https://www.wi.uni-muenster.de/sites/default/files/public/department/itsecurity/mbc13/mbc13-moeser-paper.pdf Download]<br />
|-<br />
| On the origins of Bitcoin: Stages of monetary evolution<br />
| Konrad S. Graf <br />
| Research paper<br />
| 2013<br />
| [http://konradsgraf.com/blog1/2013/10/23/on-the-origins-of-bitcoin-my-new-work-on-bitcoin-and-monetar.html Abstract]<br />
[http://konradsgraf.com/storage/On%20the%20Origins%20of%20Bitcoin%20Graf%2023.10.13.pdf Download]<br />
|-<br />
| Majority is not Enough: Bitcoin Mining is Vulnerable<br />
| Ittay Eyal and Emin Gun Sirer<br />
| Research paper<br />
| 2013<br />
| [http://arxiv.org/abs/1311.0243 Abstract]<br />
[http://arxiv.org/pdf/1311.0243v1 Download]<br />
|-<br />
| Bitcoin, the end of the Taboo on Money<br />
| Denis Roio aka Jaromil<br />
| Humanities article<br />
| 2013<br />
| [http://www.dyndy.net/2013/04/bitcoin-ends-the-taboo-on-money/ Abstract]<br />
[https://files.dyne.org/readers/Bitcoin_end_of_taboo_on_money.pdf Download]<br />
|-<br />
| Secure Multiparty Computations on BitCoin<br />
| Marcin Andrychowicz, Stefan Dziembowski, Daniel Malinowski and Łukasz Mazurek University of Warsaw <br />
| Research paper<br />
| 2013<br />
| [http://eprint.iacr.org/2013/784 Abstract]<br />
[http://eprint.iacr.org/eprint-bin/cite.pl?entry=2013/784 BibTeX]<br />
[http://eprint.iacr.org/2013/784.pdf Download]<br />
|-<br />
| A Fistful of Bitcoins: Characterizing Payments Among Men with No Names<br />
| Sarah Meiklejohn, Marjori Pomarole, Grant Jordan, Kirill Levchenko, Damon McCoy, Geoffrey M. Voelker, Stefan Savage<br />
| Research paper<br />
| 2013<br />
| <br />
[http://www.cs.gmu.edu/~mccoy/papers/imc13.pdf Download]<br />
|-<br />
| Information Propagation in the Bitcoin Network<br />
| Christian Decker (ETH Zurich, Switzerland), Roger Wattenhofer (Microsoft Research)<br />
| Research paper<br />
| 2013<br />
| <br />
[http://www.tik.ee.ethz.ch/file/49318d3f56c1d525aabf7fda78b23fc0/P2P2013_041.pdf Download]<br />
|-<br />
| Have a Snack, Pay with Bitcoins<br />
| Tobias Bamert, Christian Decker, Lennart Elsen, Roger Wattenhofer, Samuel Welten<br />
| Research paper<br />
| 2013<br />
| <br />
[http://www.tik.ee.ethz.ch/file/848064fa2e80f88a57aef43d7d5956c6/P2P2013_093.pdf Download]<br />
|-<br />
| The Economics of Private Digital Currency<br />
| Gerald P Dwyer<br />
| Research paper<br />
| 2014<br />
| [http://mpra.ub.uni-muenchen.de/55824/ Abstract]<br />
[http://mpra.ub.uni-muenchen.de/55824/1/MPRA_paper_55824.pdf Download]<br />
|-<br />
| The Origin, Classification and Utility of Bitcoin<br />
| Peter Šurda <br />
| Research Paper<br />
| 2014<br />
| [http://papers.ssrn.com/sol3/papers.cfm?abstract_id=2436823 Abstract]<br />
|-<br />
| Deanonymisation of clients in Bitcoin P2P network<br />
| Alex Biryukov, Dmitry Khovratovich and Ivan Pustogarov<br />
| Research Paper<br />
| 2014<br />
| [http://arxiv.org/abs/1405.7418 Abstract] [http://arxiv.org/pdf/1405.7418v2.pdf Download]<br />
|-<br />
| Bitcoin Financial Regulation: Securities, Derivatives, Prediction Markets, &amp; Gambling<br />
| Jerry Brito, Houman B. Shadab, Andrea Castillo<br />
| Research Paper<br />
| 2014<br />
| [http://papers.ssrn.com/sol3/papers.cfm?abstract_id=2423461 Abstract] [http://papers.ssrn.com/sol3/Delivery.cfm/SSRN_ID2426195_code510873.pdf?abstractid=2423461&amp;mirid=1 Download]<br />
|-<br />
| What are the main drivers of the Bitcoin price?<br />
| Ladislav Kristoufek<br />
| Research Paper<br />
| 2014<br />
| [http://arxiv.org/pdf/1406.0268v1.pdf Download]<br />
|-<br />
| The Economics of Bitcoin<br />
| Andre Herman<br />
| Bachelor's thesis<br />
| 2014<br />
| [http://www.scribd.com/doc/231964435/The-Economics-of-Bitcoin Download]<br />
|-<br />
| Near Zero Bitcoin Transaction Fees Cannot Last Forever<br />
| Kerem Kaşkaloğlu<br />
| Research Paper<br />
| 2014<br />
| [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]<br />
|-<br />
| Is Bitcoin Money?<br />
| Ísak Andri Ólafsson<br />
| Thesis Paper<br />
| 2014<br />
| [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]<br />
|-<br />
| The (A)Political Economy of Bitcoin<br />
| Vasilis Kostakis and Chris Giotitsas<br />
| Essay<br />
| 2014<br />
| [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]<br />
|-<br />
| When your sensor earns money: exchanging data for cash with Bitcoin<br />
| Dominic Wörner and Thomas von Bomhard<br />
| Research<br />
| 2014<br />
| [http://dl.acm.org/citation.cfm?id=2638786 Abstract] [http://dl.acm.org/ft_gateway.cfm?id=2638786&amp;ftid=1500778&amp;dwn=1&amp;CFID=579517323&amp;CFTOKEN=37552107 Download]<br />
|-<br />
| Bitcoin Transaction Malleability and MtGox <br />
| Christian Decker, Roger Wattenhofer<br />
| Research<br />
| 2014<br />
| [http://www.tik.ee.ethz.ch/file/7e4a7f3f2991784786037285f4876f5c/malleability.pdf Download]<br />
|-<br />
| BlueWallet: The Secure Bitcoin Wallet<br />
| Tobias Bamert, Christian Decker, Roger Wattenhofer and Samuel Welten<br />
| Research<br />
| 2014<br />
| [http://www.tik.ee.ethz.ch/file/0c347a9a3803cb937d360cba511e5019/stm2014_submission_12.pdf Download]<br />
|-<br />
| Bitcoin over Tor isn’t a good idea<br />
| Alex Biryukov and Ivan Pustogarov<br />
| Research<br />
| 2014<br />
| [http://arxiv.org/pdf/1410.6079v1.pdf Download]<br />
|-<br />
| Sidechained Bitcoin Substitutes, A Monetary Commentary<br />
| Konrad S. Graf<br />
| Essay<br />
| 2014<br />
| [http://konradsgraf.squarespace.com/storage/Monetary%20analsyis%20of%20sidecoins%20KG%2024Oct2014.pdf Download]<br />
|-<br />
| Taxation of virtual currency<br />
| Aleksandra Bal<br />
| PhD thesis<br />
| 2014<br />
| [http://hdl.handle.net/1887/29963 Abstract] [https://openaccess.leidenuniv.nl/bitstream/handle/1887/29963/000-5-Bal-14-10-2014.pdf Download]<br />
|-<br />
| A First Look at the Usability of Bitcoin Key Management<br />
| Shayan Eskandari, David Barrera, Elizabeth Stobert, and Jeremy Clark<br />
| Research Paper<br />
| 2015<br />
| [http://www.internetsociety.org/sites/default/files/05_3_3.pdf Download]<br />
|-<br />
| Privacy in Bitcoin through decentralized mixers<br />
| Olivier Coutu<br />
| Master's thesis<br />
| 2015<br />
| [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]<br />
|-<br />
| Value Creation in Cryptocurrency Networks: Towards A Taxonomy of Digital Business Models for Bitcoin Companies<br />
| Erol Kazan, Chee-Wee Tan, Eric T.K. Lim<br />
| Research Paper<br />
| 2015<br />
| [http://aisel.aisnet.org/pacis2015/34/ Abstract] [http://aisel.aisnet.org/cgi/viewcontent.cgi?article=1222&amp;context=pacis2015 Download]<br />
|-<br />
| Authenticated Key Exchange over Bitcoin<br />
| Patrick McCorry, Siamak F. Shahandashti, Dylan Clarke, Feng Hao<br />
| Research Paper<br />
| 2015<br />
| [http://eprint.iacr.org/2015/308.pdf Download]<br />
|-<br />
| Bitcoin and Beyond: A Technical Survey on Decentralized Digital Currencies<br />
| Florian Tschorsch and Björn Scheuermann<br />
| Research Paper<br />
| 2015<br />
| [http://eprint.iacr.org/2015/464.pdf Download]<br />
|-<br />
| Bitcoin Duplex Micropayment Channels<br />
| Christian Decker and Roger Wattenhofer<br />
| Research Paper<br />
| 2015<br />
| [http://www.tik.ee.ethz.ch/file/716b955c130e6c703fac336ea17b1670/duplex-micropayment-channels.pdf Download]<br />
|-<br />
| The Bitcoin Lightning Network: Scalable Off-Chain Instant Payments<br />
| Joseph Poon and Thaddeus Dryja<br />
| Research Paper<br />
| 2015<br />
| [http://lightning.network/lightning-network-paper.pdf Download]<br />
|-<br />
| Bitcoin and the Uniform Commercial Code<br />
| Jeanne L. Schroeder<br />
| Research Paper<br />
| 2015<br />
| [http://papers.ssrn.com/sol3/papers.cfm?abstract_id=2649441 Abstract] [http://papers.ssrn.com/sol3/Delivery.cfm/SSRN_ID2649441_code1717611.pdf?abstractid=2649441&amp;mirid=1 Download]<br />
|-<br />
| Economics beyond Financial Intermediation<br />
| Saifedean Ammous<br />
| Research Paper<br />
| 2015<br />
| [http://journal.apee.org/index.php?title=2015_Journal_of_Private_Enterprise_vol_30_no_3_parte2.pdf Download]<br />
|-<br />
| Bitcoin and the Future of Digital Payments<br />
| William J. Luther<br />
| Research Paper<br />
| 2015<br />
| [http://papers.ssrn.com/sol3/Papers.cfm?abstract_id=2631314 Abstract] [http://papers.ssrn.com/sol3/Delivery.cfm/SSRN_ID2631314_code1352425.pdf?abstractid=2631314&amp;mirid=1 Download]<br />
|}<br />
<br />
==See Also==<br />
<br />
* [http://encryptopedia.com/ Encryptopedia - Scientific research and white papers on bitcoin, blockchain technology, cryptography, algorithms and cryptocurrencies]<br />
* [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&amp;pli=1&amp;sle=true Full List])<br />
* [http://www.opencryptocurrencyreview.com/ OpenCryptocurrencyReview - A repository of Bitcoin and related research]<br />
* [http://people.scs.carleton.ca/~clark/biblio.html Jeremy Clark's Bitcoin Bibliography]<br />
* [[:Category:Economics|Economic]]<br />
* [[:Category:Technical|Technical]]<br />
* [[Press]]<br />
<br />
[[Category:Research]]</div>Sgornickhttps://en.bitcoin.it/w/index.php?title=Bitcoin_Money&diff=59369Bitcoin Money2015-11-18T14:30:13Z<p>Sgornick: Update links to current URLs.</p>
<hr />
<div>'''Bitcoin Money''' is a blog relating to various financial aspects of Bitcoin.<br />
<br />
The blog's most popular post, [http://bitcoin.tumblr.com/post/2560941112/rebooting-of-money The Rebooting of Money] is an audio podcast that provides an introduction to Bitcoin.<br />
<br />
==External Links==<br />
<br />
* [http://www.bitcoin.tumblr.com BitcoinMoney.com]<br />
* Twitter: [http://twitter.com/bitcoinmoney @BitcoinMoney]<br />
<br />
[[Category:Blogs]]<br />
[[Category:Investing]]<br />
[[Category:Financial]]</div>Sgornickhttps://en.bitcoin.it/w/index.php?title=Redeemable_code&diff=59368Redeemable code2015-11-18T14:29:11Z<p>Sgornick: /* See Also */ Update link with current URL for article.</p>
<hr />
<div>A financial instrument whose value is accessible by redeeming the code.<br />
<br />
Redeemable codes are generally considered &quot;bearer&quot; instruments such that whichever party is first to redeem the code becomes the owner of those funds.<br />
<br />
Some bitcoin exchanges offer redeemable codes as a method that allows funds to be transferred from one user to another. These codes might be denominated in bitcoins (BTCs) or they may be denominated in a government currency, such as USDs.<br />
<br />
The term Redeemable code was first introduced to the bitcoin community by [[MtGox]] but the concept had been in use previously under a variety of terms. [[MoneyPak]], for instance, refers to the code underneath a scratch-off protective layer as the &quot;MoneyPak Number&quot;. Other terms that may refer to the same concept are recharge codes, scratch codes, single-use vouchers, etc.<br />
<br />
The vendor of a redeemable code will have terms for how the code is used. Funds redeemed using MoneyPaks, for instance, might not be available instantly or are subject to being clawed back if the vendor feels the party that redeemed the code had violated their terms of use. <br />
<br />
Asking for a copy of the receipt when accepting MP may help protect yourself from the above mentioned risk<br />
<br />
The code only has value if the vendor will grant funds to the party that redeems it. The code could be considered to be a [[digital currency]] as it is issued by a vendor and can be used to transfer value electronically.<br />
<br />
Following guidance provided by FinCEN, a department of the U.S. Treasury, nearly all Bitcoin-related redeemable code issuers (i.e., Mt. Gox, BITSTAMP, BTC-E, AurumXChange) stopped issuance.<br />
<br />
==Issuers==<br />
<br />
Bitcoin-related redeemable code issuers and denominations:<br />
* ChangeTip [http://blog.changetip.com/introducing-the-one-time-tip-link/ One Time Tip] link.<br />
* [[Easywallet.org]] - Redeemable code (referred to as &quot;coupons&quot;) issued in BTC denomination only.<br />
<br />
===External===<br />
<br />
There are redeemable codes from financial and retail issuers. These include gift card eCodes and other stored value instruments.<br />
<br />
* [[UKash]] vouchers, available in Central and South America, the Middle East, China, Pakistan, Europe and elsewhere.<br />
* [[CashU]] coupons, available in the Middle East, Northern Africa and elsewhere.<br />
* [https://squareup.com/help/en-us/article/5065-gift-cards-for-merchants Square gift cards] to any Square merchant<br />
* Amazon gift codes<br />
* Prepaid Mobile phone reload codes<br />
<br />
==Redeem==<br />
<br />
Some exchanges, exchange partners and merchants will accept funds via a redeemable code from other issuers.<br />
<br />
* [[Bitcoin Nordic]] - Accepts redeemable code from [[CashU]] cards through that service, which also accepts [[UKash]] vouchers.<br />
<br />
==Risks==<br />
<br />
A redeemable code can be redeemed by any party that knows the code. As a result, the use of this delivery method carries risks. When a trader is sending the code to a trading counterparty, only secure communication methods should be employed. E-mail, for instance, sends data in the clear and thus the code sent in an e-mail would have been visible to dozens of computing devices (routers, mail servers and relays, etc.) before reaching the intended recipient. Standard IRC private messages even are not secure though there are methods for improved communication (SSL). For consumer-level transactions some parties are willing to transact using non-secure methods as the risks of the communication being intercepted and fraud being the result have not yet materialized.<br />
<br />
Aside from using encryption, the risk of exchanging a redeemable code can be casually mitigated somewhat by using a &quot;poor man's&quot; multi-factor authentication method such as sending half of the secret code through one channel (e.g. e-mail), and sending the other half through an independent channel (e.g. over a phone call).<br />
<br />
==See Also==<br />
<br />
* [[Digital currency]]<br />
* [[A2A Transfer Methods]]<br />
* [http://bitcoin.tumblr.com/post/18506669111 Redeemable Codes Bypass International Banking System] post on [[Bitcoin Money]]<br />
<br />
==References==<br />
&lt;references /&gt;<br />
<br />
[[Category:Financial]]<br />
[[Category:Digital currencies]]</div>Sgornickhttps://en.bitcoin.it/w/index.php?title=Proof_of_Stake&diff=59073Proof of Stake2015-10-10T12:33:47Z<p>Sgornick: Add link for Doublespend.</p>
<hr />
<div>Proof of Stake is a proposed alternative to [[Proof of Work]]. Like proof of work, proof of stake attempts to provide consensus and [[Double-spending|doublespend]] prevention (see [https://bitcointalk.org/index.php?topic=68213.0 &quot;main&quot; bitcointalk thread], and a [https://bitcointalk.org/index.php?topic=96854.0 Bounty Thread]). Because creating forks is costless when you aren't burning an external resource Proof of Stake alone is considered to an unworkable consensus mechanism.&lt;ref&gt;https://download.wpsoftware.net/bitcoin/pos.pdf&lt;/ref&gt;<br />
<br />
It was probably first proposed [https://bitcointalk.org/index.php?topic=27787.0 here] by Quantum Mechanic. With Proof of Work, the probability of mining a block depends on the work done by the miner (e.g. CPU/GPU cycles spent checking hashes). With Proof of Stake, the resource that's compared is the amount of Bitcoin a miner holds - someone holding 1% of the Bitcoin can mine 1% of the &quot;Proof of Stake blocks&quot;.<br />
<br />
Some argue that methods based on Proof of Work alone might lead to a low network security in a cryptocurrency with block incentives that decline over time (like bitcoin) due to [[Tragedy of the Commons]], and Proof of Stake is one way of changing the miner's incentives in favor of higher network security.<br />
<br />
= Motivation For Proof of Stake =<br />
<br />
* A proof-of-stake system might provide increased protection from a malicious attack on the network. Additional protection comes from two sources:<br />
1) Executing an attack would be much more expensive. <br />
2) Reduced incentives for attack. The attacker would need to own a near majority of all bitcoin. Therefore, the attacker suffer severely from his own attack. <br />
<br />
* When block rewards are produced through txn fees, a proof of stake system would result in lower equilibrium txn fees. Lower long-run fees would increase the competitiveness of bitcoin relative to alternative payments systems. Intuitively reduced fees are due to vast reductions in the scale of wastage of resources. <br />
== The Monopoly Problem ==<br />
<br />
If a single entity (hereafter a monopolist) took control of the majority of txn verification resources, he could use these resources to impose conditions on the rest of the network. Potentially, the monopolist could choose to do this in malicious ways, such as double spending or denying service. If the monopolist chose a malicious strategy and maintained his control for a long period, confidence in bitcoin would be undermined and bitcoin purchasing power would collapse. Alternatively, the monopolist could choose to act benevolently. A benevolent monopolist would exclude all other txn verifiers from fee collection and currency generation, but would not try to exploit currency holders in any way. In order to maintain a good reputation, he would refrain from double spends and maintain service provision. In this case, confidence in Bitcoin could be maintained under monopoly since all of its basic functionality would not be affected.<br />
<br />
Both benevolent and malevolent monopoly are potentially profitable, so there are reasons to suspect that an entrepreneurial miner might attempt to become a monopolist at some point. Due to the [[Tragedy of the Commons]] effect, attempts at monopoly become increasingly likely over time.<br />
<br />
== How Proof of Stake Addresses Monopoly Problems ==<br />
<br />
Monopoly is still possible under proof-of-stake. However, proof-of-stake would be more secure against malicious attacks for two reasons. <br />
<br />
Firstly, proof-of-stake makes establishing a verification monopoly more difficult. At the time of writing, an entrepreneur could achieve monopoly over proof-of-work by investing at most 10 million USD in computing hardware. The actual investment necessary might be less than this because other miners will exit as difficulty increases, but it is difficult to predict exactly how much exit will occur. If price remained constant in the face of extremely large purchases (unlikely), such an entrepreneur would need to invest at least 20 million USD to obtain monopoly under proof-of-stake. Since such a large purchase would dramatically increase bitcoin price, the entrepreneur would likely need to invest several times this amount. Thus, even now proof-of-stake monopoly would be several-fold more costly to achieve than proof-of-work monopoly. Over time the comparison of monopoly costs will become more and more dramatic. The ratio of bitcoin's mining rewards to market value is programmed to decline exponentially. As this happens, proof-of-work monopoly will become easier and easier to obtain, whereas obtaining proof-of-stake monopoly will become progressively more difficult as more of the total money supply is released into circulation.<br />
<br />
Secondly, and perhaps more importantly, a proof-of-stake monopolist is more likely to behave benevolently exactly because of his stake in Bitcoin. In a benevolent monopoly, the currency txn continue as usual, but the monopolist earns all txn fees and coin generations. Other txn verifiers are shut out of the system, however. Since mining is not source of demand for bitcoin, bitcoin might retain most of its value in the event of a benevolent attack. Earnings from a benevolent attack are similar regardless of whether the attack occurs under proof-of-stake or proof-of-work. In a malicious attack, the attacker has some outside opportunity which allows profit from bitcoin's destruction (simple double-spends are not a plausible motivation; ownership of a competing payment platform is). At the same time, the attacker faces costs related to losses on bitcoin-specific investments which are necessary for the attack. It can be assumed that a malicious attack causes the purchasing power of bitcoin to fall to zero. Under such an attack, the proof-of-stake monopolist will lose his entire investment. By contrast, a malicious proof-of-work monopolist will be able to recover much of their hardware investment through resale. Recall also, that the necessary proof-of-work investment is much smaller than the proof-of-stake investment. Thus, the costs of a malicious attack are several-fold lower under proof-of-work. The low costs associated with malicious attack make a malicious attack more likely to occur.<br />
<br />
== Why Proof of Stake Would Likely Decrease Long-run Txn Fees Considerably ==<br />
In a competitive market equilibrium, the total volume of txn fees must be equal to opportunity cost of all resources used to verify txns. Under proof-of-work mining, opportunity cost can be calculated as the total sum spent on mining electricity, mining equipment depreciation, mining labor, and a market rate of return on mining capital. Electricity costs, returns on mining equipment, and equipment depreciation costs are likely to dominate here. If these costs are not substantial, then it will be exceptionally easy to monopolize the mining network. The fees necessary to prevent monopolization will be onerous, possibly in excess of the 3% fee currently charged for credit card purchases. Under pure proof-of-stake, opportunity cost can be calculated as the total sum spent on mining labor and the market interest rate for risk-free bitcoin lending (hardware-related costs will be negligible). Since bitcoins are designed to appreciate over time due to hard-coded supply limitations, interest rates on risk-free bitcoin-denominated loans are likely to be negligible. Therefore, the total volume of txn fees under pure proof-of-stake will just need to be just sufficient to compensate labor involved in maintaining bandwidth and storage space. The associated txn fees will be exceptionally low. Despite these exceptionally low fees, a proof-of-stake network will be many times more costly to exploit than the proof-of-work network. Approximately, a proof-of-work network can be exploited using expenditure equal to about one years worth of currency generation and txn fees. By contrast, exploitation of a proof-of-stake network requires purchase of a majority or near majority of all extant coins.<br />
<br />
= Implementation =<br />
There are currently a few distinct proposals on how to implement PoS<br />
<br />
== Cunicula's Implementation of Mixed Proof-of-Work and Proof-of-Stake ==<br />
<br />
This suggestion is of a mixed Proof-of-Work / Proof-of-Stake system.<br />
<br />
=== Cunicula's Note ===<br />
Check the page history for the older implementation. I am replacing my description with a new system which I believe to be much more secure. The new system is a greatly improved version of Coblee's Proof of Activity [https://bitcointalk.org/index.php?topic=102355.0 proposal]. It provides extremely strong protection against PoW attacks, both double-spends and denials of service. It is not vulnerable even if PoW attackers also have substantial (but non majority) stake. It provides strong incentives to maintain full nodes. The system is supported through taxes on coin owners who fail to maintain full nodes. Tax revenue is redistributed to coin owners who maintain full nodes. The maintenance of full nodes is the key element providing security in the system.<br />
<br />
The discussion focuses on long-term maintenance of the system. Initial distribution of coins could occur through PoW mining, an IPO mechanism, or a more complex scheme that allows initial coins to be distributed to both PoW miners and businesses voted for by coin owners. The issue of initial distribution is separate from long-term maintenance and it is confusing to discuss the two together.<br />
<br />
=== Glossary ===<br />
Voluntary Signatures - Voluntary signatures result from a random auditing processes. As blocks are mined, keys are selected for auditing based on random selection. The signatures provide public evidence that a public key owner is running a full node. Passing the audit allows a private key to remain active.<br />
<br />
Active Keys - By default, public keys that appear in the blockchain are active if they have a balance of at least one full coin. Public keys that provide voluntary signatures when randomly audited remain active. Active public keys are eligible to participate in lotteries to sign PoW blocks and mine PoS blocks. This is remunerative. Public keys that fail to provide signatures become dead private keys. <br />
<br />
Dead Keys - Keys that have failed to provide signatures lose lottery eligibility. Keys that have balances of less than 1 coin are considered dead by default. Dead keys can no longer mine PoS blocks. However, these dead keys can still be used to generate txns. Network maintenance is supported primarily through mandatory fees levied on coins sent by dead keys. After coins are sent using a dead key, the key becomes active provided that it retains a balance of at least 1 coin.<br />
<br />
Mandatory Signature Sequence - In order for a PoW block to be valid and enter the blockchain, it must be signed by a sequence of 5 randomly selected active keys. The fifth signatory in the sequence mines a PoS block. <br />
<br />
PoS block - The fifth signatory of a PoW block must mint his own block without any PoW submission at all. This block is called a PoS block.<br />
<br />
Coin-age - Coin age refers to the age of txn inputs. Coin age is equal to the number of coins sent times the average age on these coins. Age is measured in blocks. Age is reset to 1 block whenever a coin is sent AND whenever a coin provides a signature (both mandatory and voluntary signatures count). Coin-age is used to calculate mandatory fees.<br />
<br />
Demurrage Fee - Chain Security is supported primarily through a demurrage tax on sent inputs. This tax proportional to average input age as measured in coin-years. I suggest 5% per coin-year as a reasonable fee. Active keys can avoid demurrage fees simply by remaining active. Thus the actual fee generation will be much lower than 5% per year. Dead keys must pay demurrage. The opportunity to evade demurrage motivates activity.<br />
<br />
Optional Fee - Fees are used to ration block space. Blocks select prioritize txns with high fees. If demurrage fees alone are insufficient to motivate txn inclusion, the user can add an optional fee to his txn.<br />
<br />
Fee Fund - Both optional fees and demurrage fees enter a fund, rather than being distributed directly to miners. Fees are added to the fund immediately, so there is a weak incentive to include high fee txns in blocks. The PoW miner receives a distribution equal to 0.01% of the accumulated fund. The first four mandatory signatories also receive 0.1% each. The PoS block miner receives 0.1% as well, but his takings will differ slightly because the fund is updated based on txns included in his block. Use of a fund reduces volatility in mining reward.<br />
<br />
Root Private Key - The root private key has full spending and signing authority. When significant balances are held, this key should be kept as an offline backup to guard against theft. <br />
<br />
Stake Signing Key - Private Key can delegate signing and sending authority to one other private key. The delegated key can sign blocks and has limited authority to send coins. Authority to send coins is determined by two positive constants, t and k. The following txn rule limits the stake signing keys' spending authority:<br />
<br />
Change Returned to Public Key &gt;= all coins sent to other addresses * {max(k,k*(t/coin-years on public key)}<br />
k=9 and t=1/12 are suggested as possible parameters. These parameters allows the stake signing key to spend up to 10% of the total key balance per month. The max value at risk in event of theft of <br />
this key is 10%. Holders of large balances 'zero-out' their coin-age frequently via mining and face less theft risk. If this occurs once per week, for example, the large balance holder will only<br />
risk be able to spend up to 2.3% of their balance per week and will only lose 2.3% in the event of theft. Once theft is detected, all remaining coins can be moved to a secure computer using the<br />
root private key.<br />
<br />
=== Mining Process ===<br />
<br />
1) Block meeting work difficulty target is mined. Difficulty target periodically adjusted so that 1 PoW block arrives every 10 minutes.<br />
<br />
2) Work submission is hashed 10 times consecutively. Each consecutive hash maps to an individual unspent output in the blockchain. This is essentially a lottery drawing two sets of five winners. The first five hashes map to mandatory signatures, the final five hashses map to voluntary signatures.<br />
<br />
3) If the mandatory signatures map to active public keys [see glossary], the block can potentially be valid. Otherwise, the block is invalid and must be discarded.<br />
<br />
4) If PoW miner finds a potentially valid block, he transmits the following hash to the network: {work submission;hash(his block, the previous valid block)}<br />
<br />
5) If the work submission meets the difficulty target and maps to active signatories, then the block is relayed through the network. Otherwise, the message is dropped as spam.<br />
<br />
5) The first five selected signatories sequentially sign this hash and transmit it onwards as {work submission; hash; sig 1; sig 2; sig 3; sig 4; sig 5}<br />
<br />
6) After the mandatory signature sequence is complete, the final signatory publishes the PoW block and also his own PoS block. <br />
<br />
7) The final five hashes map to voluntary signatures. These voluntary signatures can be inserted into any block within the next 6 blocks as special txns. These txns do not require fees. <br />
<br />
9) Go to step 1<br />
<br />
Note: This process is simultaneous so that multiple block hashes can circulate in the network attempting to collect five signatures and generate PoW/PoS block pairs. Block pairs that lose this race<br />
are orphaned.<br />
<br />
=== Infeasability of standard attack vectors ===<br />
<br />
Unless attackers own a large share of stake, all types of PoW attacks are computationally infeasible. I think there are two types of known attacks: 1) Double-Spend 2) Denial of Service<br />
I consider approximations below. The numbers are so favorable that consideration of exact statistics is not particularly interesting.<br />
<br />
1) Double Spend.<br />
<br />
Double spends rely on secrecy. In order to mine blocks in secret a PoW miner must select his 5 of his own public keys in the lottery. If the PoW miner owns a share 0&lt;s&lt;1 of all coins, <br />
the probability of doing that a block meeting the difficulty target will select the miner's coins is (1/s)^5. For s=0.01, 1 out of 10 billion blocks will satisfy this criteria. <br />
Even for extremely small hash aggregate rates, it is not practical to privately mine at a rate 10 billion times faster than all other miners combined. For s=0.1, 1 out of 100,000 blocks will <br />
satisfy this criteria. (i.e. the attack still requires approximately 99.999% of all hashing power). For s=0.5, the attacker will succeed if he controls 51% of the aggregate hash rate.<br />
<br />
2) Denial of Service<br />
<br />
An attacker who mines publicly could simply produce empty PoW blocks. However, this would fail to deny service. 50% of all blocks are randomly mined via PoS. The attacker cannot<br />
force the PoS miners to produce empty blocks. Therefore he cannot deny service regardless of how much hash rate he controls.<br />
<br />
=== Long-term Chain Evaluation ===<br />
1) Comparison of two long chains is based on a simple sum of block difficulty, just as in bitcoin.<br />
<br />
2) A criticism of PoS is that there is no reason not to sign attack chains. However, in a long secret chain, many stakeholders will have dead signatures. These dead stakeholders will not be able to sign the main chain, but not the attack chain. They will have a strong incentive to make sure the main chain wins because the attack chain will impose demurrage fees on them.<br />
<br />
=== Incentives to maintain full nodes ===<br />
<br />
This system introduces powerful incentives to maintain full nodes. Many people argue that the lack of an incentive to maintain a full node is a problem in the bitcoin system.<br />
<br />
1) a steady flow of txns will generate some fees even if all public keys remain active. Active keys must be maintaining full nodes. Otherwise they could not provide the voluntary signatures which prove their activity. Even very weak incentives are sufficient in this case. If almost all keys are associated with active nodes, then it is not necessary to motivate additional participation.<br />
<br />
2) Some public keys may decide to become inactive. This is costly for them. They will suffer a loss of 5% of their balance per year for as long as they remain inactive.<br />
<br />
3) The active public keys constantly capture revenue from inactive public keys. This means that the incentives to remain increase dramatically as participation falls. Suppose that 50% of public keys maintain full nodes, then this 50% will capture 2.5% of coins per annum. This is equal to an annual of return of 2.0%. The alternative, inactivity, yields an annual return of -5.0% as discussed in point 2. I consider this a reasonable incentive level and participation rate. Suppose that I am wrong, and only 10% of public keys maintain full nodes. Then these 10% will capture 4.5% of all extant coins per annum. This implies an annual return on participation equal to 45% per annum. This is a very strong incentive and is almost certain to be sufficient, even if nodes are quite costly to maintain. If only 1% of coins participate, then 4.95% of all extant coins will be distributed to this 1% each year. This implies a weekly return on participation of 3%, a pirate ponzi scheme level return. If these incentive are inadequate to support a healthy network of full nodes (which seems unlikely to me), then the levy on dead coins could be increased to exceed 5% per annum.<br />
<br />
4) Many people will not have enough coins to justify running their own node. Such individuals will likely use an online banking service which could store their limited spend key. The service could return interest to users in exchange for managing their keys.<br />
<br />
5) Other individuals may prefer the privacy associated with dropping out of participation. These individuals are still welcome to use the network, but must face a wealth tax of 5% per annum to compensate for the security risk created by their behavior.<br />
<br />
=== Storage of Blockchain Metadata ===<br />
To facilitate the system, data should be extracted from the block chain in a readily accessible database that is updated with each block. The database only needs to incorporate<br />
public keys which control at least 1 coin. Keys with balances less than 1 coin are considered dead by default. These low-value public keys<br />
are not allowed to create limited stake public keys. If a public key balance drops below 1 coin, the limited stake public key associated with the root key is invalidated. <br />
<br />
The database would look like this:<br />
<br />
{| class=&quot;wikitable&quot;<br />
|-<br />
! Public Key (ordered list) !! Linked Stake Public key (if any) !! Balance !! Cumulative Balance !! Active? !! Coin-age (in years)<br />
|-<br />
| A || As || 1 || 1 || 1 || 0.03<br />
|-<br />
| B || Bs || 2.5 || 3.5 || 0 || 0.1 <br />
|-<br />
| C || Cs || 3 || 6.5 || 1 || 0.2 <br />
|-<br />
| ... || ... || ... || ... || ... || ... <br />
|}<br />
The block chain must maintain records of links between public keys and delegated limited stake public keys. These should be put in a simple database for easy access.<br />
<br />
Cumulative balance can be used to determine the winners of the lottery. (i.e. the lottery is a uniform draw on the support [0,total issued coins]) This indicates a unique lottery winner,<br />
whose chance of winning is proportional to his ownership share.<br />
<br />
Coin-age is updated as follows.<br />
If no send, Coin-age_t = Coin-age_t-1 + 1. <br />
If send, Coin_age_t = 1. <br />
If send and receipt of coins, Coin_age_t = 1. <br />
If receipt of coins but no send, Coin_age_t = [Coin_age_(t-1)*balance_(t-1)+received coins]/balance(t)<br />
<br />
Coin-age is necessary to determine mandatory demurrage fees and to calculate spending limits for limited stake public keys.<br />
<br />
Active is 1 by default and becomes 0 if a key fails to provide a requested voluntary signature. 0 is an absorbing state.<br />
<br />
=== Beneficiaries and Lossers from Txn Fees ===<br />
The total amount of demurrage fees collected annually varies between 0% and 5% of the total money supply. <br />
<br />
The most burdensome fee in the system is the fee paid to PoW miners. This fee imposes a demurrage tax of between 0% and 0.1% per annum on all users of the system. In addition to the demurrage tax, PoW miners receive a 2% share of any optional fees paid to access scarce block space. All coin owners are net losers as a result of PoW mining fees. To minimize costs to coin owners, PoW fee payments are kept as low as possible. Since large hash rates play only a tiny role in security, larger fees for PoW miners are unnecessary.<br />
<br />
Other demurrage fees are transfers of revenue from one private key to another. Some keys are net beneficiaries of these transfers, while other keys are net losers. Collectively, these fees do not make coin owners better or worse off. Their effects are neutral. However, individually, the fees do create winners and losers. ''Active'' users that spend infrequently gain from the system. An ''active'' user with average spend frequency is likely to gain from the system as well, but only by a small amount. An ''active'' user that spends very frequently will probably lose from the system. ''Dead'' users will certainly lose from the system. This loss serves as a punishment for failure to maintain an ''active'' node.<br />
<br />
== Meni's implementation ==<br />
This proposal is for a proof-of-work (PoW) skeleton on which occasional checkpoints set by stakeholders are placed. In one variant, double-spending is prevented by waiting for a transaction to be included in a checkpoint; the variant described here uses cementing to prevent double-spending, and checkpoints to resolve cementing conflicts.<br />
<br />
=== Proof of work ===<br />
Miners use their hashrate to find blocks and build the blockchain exactly as with the pure PoW system. They receive any new generated coins from the block; there will be two kinds of transaction fees, one of which is a mining fee given to the miner who finds the block, just like the PoW transaction fees.<br />
<br />
=== Signatures ===<br />
One block every 100 blocks (a different number can be used instead) is a signature block. When a signature block is found and confirmed with several subsequent blocks, stakeholders (people who have bitcoins) are expected to sign it by using a private key associated with their address which contains coins to sign the block hash. If there are several blocks of the same height, an address should not sign more than one of them. The signatures are broadcast on the network and included in a future block. For every candidate block, the total weight of all signatures is tallied (the weight of an address is determined mostly by the number of coins in it, as of the last signature block). Stakeholders will be able to collect signature fees when providing a signature, proportionally to their weight.<br />
<br />
At the basic level, there are no rules to choosing which of several conflicting blocks to sign, stakeholders should just choose one.<br />
<br />
=== Cementing ===<br />
Cementing is a node's reluctance to do a blockchain reorganization. A node will reject any new block found if it contradicts a 6-block deep branch it is already aware of and currently considers valid. That is, once a node receives 6 confirmations for a block, it will not accept a competing block even if it is part of a longer branch.<br />
<br />
In a pure PoW system this is problematic to do because a node could be stuck on &quot;the wrong version&quot; - if an attacker isolates the node and feeds him bogus data, it will not embrace the true, longer chain when he learns of it. However, using PoS to have the final say in such situations makes this possible.<br />
<br />
=== Branch selection ===<br />
When a node needs to select which of several branches is valid, it chooses one based on the following criteria in increasing importance (each one is overridden by the next):<br />
<br />
#Branch length (total difficulty of all blocks), as in a PoW system.<br />
#Cementing - an already cemented block will not be replaced by a longer branch.<br />
#Signatures - even a cemented block will be overridden by a signature block with signature weight more than half the total possible weight by some margin.<br />
<br />
If the conflict is so long that it contains more than one spot for a signature block, the conflicting signature blocks will be traversed earliest to latest, each time choosing the branch with the majority vote. After the newest uncontested signature block it proceeds to use cementing and branch length.<br />
<br />
A signature block with no clear majority will be considered tied, and will not override the other criteria. Signature fees will not be given out but instead carried over to the next signature spot, to encourage stakeholders to participate then.<br />
<br />
=== [[Double-spending]] prevention ===<br />
A good level of security can be achieved by waiting for a block to be cemented. By that time it is safe to assume that the network recognizes this block and will not easily switch to a different block, even if a longer branch is presented.<br />
<br />
A more authoritative confirmation is enabled by waiting for a signature block. Once a block achieves a majority (and some more time is allowed for this majority to spread in the network), it is extremely unlikely that the network will ever switch away from this block.<br />
<br />
=== Weights ===<br />
The weight of every address starts at 0. When an address provides a signature, its weight increases so that after several signatures, the weight approaches the number of coins in the address as of the last signature block. For example,<br />
New weight = 0.9 * Old weight + 0.1 * Balance<br />
If a signature is not provided by the address in a signature block, its weight decreases:<br />
New weight = 0.9 * Old weight<br />
This way, addresses whose owners do not wish to participate in signing do not hamper the ability to reach a majority.<br />
<br />
If an address signs two conflicting blocks, its weight is reset to 0. This is to limit the power of malicious stakeholders.<br />
<br />
If coins move to a new address, weight is proportionally taken away from the addressed, but is not transferred to the new address. The new stakeholder will have to build up his weight.<br />
<br />
=== Malicious stakeholders ===<br />
The system is resilient against stakeholders who misuse their signature power, even if they have a majority of the bitcoins. Since their only obligation is to not sign conflicting blocks, the only way they could double-spend is if they first sign one block so it achieves a majority, then sign a different one so that it achieves a bigger majority. Generally this will not work. A short while after a majority is achieved, most of the network will be aware of the relevant signatures. If a different signature is broadcast, the conflict will be detected and both signatures will be ignored. This will cause the current majority block to become tied, but the network is already cemented on it and will vote for this branch in the next signature block. The weight of the attacker will by then reduce to 0 so he will be unable to create more disruption.<br />
<br />
Another attack is refusing to sign blocks to keep them tied. Since this causes a decay of the weight, they can only stand in the way of a majority for a short time.<br />
<br />
=== Denial of service ===<br />
The method as described does not solve a denial of service scenario. A majority miner could create only blocks with no transactions (or with many transactions missing) and reject all other blocks.<br />
<br />
This may be solvable by adding some measure of the transaction in a block to the selection criteria, such as Bitcoin days destroyed.<br />
<br />
Also, proposals to replace the block chain with a directed acyclic graph have been made, and could be used to make it easier to include transactions.<br />
<br />
== Key difference between the two proposals ==<br />
In Cunicula's system, voting power is determined by combining (multiplicatively) your hashrate and stake. This would be problematic if small players could not compete effectively with large players. Though we are waiting on a formal mathematical proof, evidence to date suggests that small and large players would have an equal competitive footing. Simulations described in this thread [https://bitcointalk.org/index.php?topic=68213.msg801253#msg801253] indicate that small players are competitive with large players because the multiplicative combination of hashrate and stake exhibits constant returns. Evidence in the thread suggests that these simulation results are accepted by both Cunicula and Meni.) <br />
<br />
In Meni's, there's a skeleton based purely on hashrate, and superimposed on it are occasional checkpoints set by stakeholders. You can contribute PoW without having stake, and you can contribute PoS without having work, and in both cases your voting power and reward is linearly proportional to the resources you have.<br />
<br />
== See also ==<br />
*[[Proof_of_work|Proof of work]]<br />
*[[Proof_of_burn|Proof of burn]]<br />
*[http://www.reddit.com/r/reddCoin/comments/249dnl/major_announcement_reddcoin_to_implement_new/ Proof of Stake Velocity by Reddcoin]<br />
<br />
[[category:mining]]<br />
[[category:Proof-of-x]]</div>Sgornickhttps://en.bitcoin.it/w/index.php?title=Softfork&diff=59072Softfork2015-10-10T12:32:52Z<p>Sgornick: /* Security */ Fix link.</p>
<hr />
<div>A softfork is a change to the bitcoin protocol wherein only previously valid blocks/transactions are made invalid.<br />
Since old nodes will recognise the new blocks as valid, a softfork is backward-compatible.<br />
This kind of fork requires only a majority of the miners upgrading to enforce the new rules.<br />
<br />
New transaction types can often be added as softforks, requiring only that the participants (sender and receiver) and miners understand the new transaction type.<br />
This is done by having the new transaction appear to older clients as a &quot;pay-to-anybody&quot; 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.<br />
This is how [[P2SH]] was added to Bitcoin.<br />
<br />
==Mechanism==<br />
<br />
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).<br />
<br />
Generally softforks accomplish something more useful, for example Pay-to-Script-Hash ([[P2SH]]) was a softfork. Originally the script &quot;OP_HASH160 [20-byte-hash-value] OP_EQUAL&quot; 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 &quot;OP_HASH160 [20-byte-hash-value] OP_EQUAL&quot; 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.<br />
<br />
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 [[BIP12]] OP_EVAL is 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 OP_EVAL behavior and once with it's 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.<br />
<br />
==Security==<br />
<br />
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 you have, the more secure secure the network is postfork. 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 &quot;fake confirmation&quot; 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 &quot;mainchain&quot; allowing the attacker to attempt to [[Double-spending|doublespend]].<br />
<br />
These attacks can be avoided by upgrading your client, however if the vast majority of miners (&gt;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.<br />
<br />
===2015 BIP66 Blockchain Fork===<br />
<br />
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 (&gt;=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 &quot;agreed&quot; to not do so. This led to a 6 block fork that was resolved after contacting the F2Pool and Antminer pool owners.<br />
<br />
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.<br />
<br />
==Implications==<br />
<br />
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.<br />
<br />
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.<br />
<br />
See also: [[Hardfork]]</div>Sgornickhttps://en.bitcoin.it/w/index.php?title=Softfork&diff=59071Softfork2015-10-10T12:32:18Z<p>Sgornick: Add reference to Doublespend.</p>
<hr />
<div>A softfork is a change to the bitcoin protocol wherein only previously valid blocks/transactions are made invalid.<br />
Since old nodes will recognise the new blocks as valid, a softfork is backward-compatible.<br />
This kind of fork requires only a majority of the miners upgrading to enforce the new rules.<br />
<br />
New transaction types can often be added as softforks, requiring only that the participants (sender and receiver) and miners understand the new transaction type.<br />
This is done by having the new transaction appear to older clients as a &quot;pay-to-anybody&quot; 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.<br />
This is how [[P2SH]] was added to Bitcoin.<br />
<br />
==Mechanism==<br />
<br />
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).<br />
<br />
Generally softforks accomplish something more useful, for example Pay-to-Script-Hash ([[P2SH]]) was a softfork. Originally the script &quot;OP_HASH160 [20-byte-hash-value] OP_EQUAL&quot; 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 &quot;OP_HASH160 [20-byte-hash-value] OP_EQUAL&quot; 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.<br />
<br />
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 [[BIP12]] OP_EVAL is 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 OP_EVAL behavior and once with it's 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.<br />
<br />
==Security==<br />
<br />
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 you have, the more secure secure the network is postfork. 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 &quot;fake confirmation&quot; 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 &quot;mainchain&quot; allowing the attacker to attempt to [[Double-spending doublespend]].<br />
<br />
These attacks can be avoided by upgrading your client, however if the vast majority of miners (&gt;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.<br />
<br />
===2015 BIP66 Blockchain Fork===<br />
<br />
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 (&gt;=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 &quot;agreed&quot; to not do so. This led to a 6 block fork that was resolved after contacting the F2Pool and Antminer pool owners.<br />
<br />
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.<br />
<br />
==Implications==<br />
<br />
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.<br />
<br />
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.<br />
<br />
See also: [[Hardfork]]</div>Sgornickhttps://en.bitcoin.it/w/index.php?title=Release_process&diff=58941Release process2015-09-27T13:30:27Z<p>Sgornick: /* External Links */ Add entry for Bitcoin Core Release Process on Github.</p>
<hr />
<div>== Bitcoin Core Open Source Release Process ==<br />
<br />
Releases to the [[Original_Bitcoin_client|Bitcoin Core]] client and project are built and released using this process:<br />
<br />
* Labeled in github<br />
* Binaries are created for the platforms affected (usually all, Windows, Mac and Linux).<br />
* Binary file checksum(s) is(are) calculated and a message with those are signed by a core developer.<br />
** sha256 checksum<br />
* Files used to build are checksummed and submitted to the Gitian.sigs project on github.<br />
* Uploaded to distribution (Bitcoin.org/bin, and Launchpad.net for the Ubuntu PPA)<br />
* Blog post on Bitcoin.org<br />
* Forum post (sticky) on BitcoinTalk.org<br />
<br />
==Verifying The Download==<br />
<br />
To verify the checksum for a binary download, first ensure the checksum file is secure by decrypting the SHA256SUMS.asc file:<br />
$ gpg --decrypt SHA256SUMS.asc<br />
<br />
Then verify the file checksum:<br />
$ openssl dgst -sha256 [binary release archive]<br />
<br />
Verify that the checksum matches the one in SHA256SUMS.asc<br />
<br />
A [https://github.com/bitcoin/bitcoin/pull/1935 script to verify the binaries] was contributed to the Bitcoin.org project.<br />
<br />
==External Links==<br />
<br />
* [https://github.com/bitcoin/bitcoin/blob/master/doc/release-process.md Bitcoin Core Release Process] on Github<br />
* [https://github.com/bitcoin/bitcoin Bitcoin Core project source] on Github<br />
* [https://github.com/bitcoin/gitian.sigs Gitain.sigs] Trusted build process signatures on Github<br />
* [http://bitcoin.org Bitcoin.org] website with releases<br />
<br />
==See Also==<br />
<br />
* [[Development process]]<br />
* [[Original Bitcoin client]]<br />
* [[:Category:Open_Source|Open source]]<br />
<br />
[[es:Proceso de publicación de versiones]]<br />
<br />
[[Category:Developer]]</div>Sgornickhttps://en.bitcoin.it/w/index.php?title=Release_process&diff=58940Release process2015-09-27T13:28:27Z<p>Sgornick: /* Bitcoin Core Open Source Release Process */ Clarify that the BitcoinTalk forum post is a sticky.</p>
<hr />
<div>== Bitcoin Core Open Source Release Process ==<br />
<br />
Releases to the [[Original_Bitcoin_client|Bitcoin Core]] client and project are built and released using this process:<br />
<br />
* Labeled in github<br />
* Binaries are created for the platforms affected (usually all, Windows, Mac and Linux).<br />
* Binary file checksum(s) is(are) calculated and a message with those are signed by a core developer.<br />
** sha256 checksum<br />
* Files used to build are checksummed and submitted to the Gitian.sigs project on github.<br />
* Uploaded to distribution (Bitcoin.org/bin, and Launchpad.net for the Ubuntu PPA)<br />
* Blog post on Bitcoin.org<br />
* Forum post (sticky) on BitcoinTalk.org<br />
<br />
==Verifying The Download==<br />
<br />
To verify the checksum for a binary download, first ensure the checksum file is secure by decrypting the SHA256SUMS.asc file:<br />
$ gpg --decrypt SHA256SUMS.asc<br />
<br />
Then verify the file checksum:<br />
$ openssl dgst -sha256 [binary release archive]<br />
<br />
Verify that the checksum matches the one in SHA256SUMS.asc<br />
<br />
A [https://github.com/bitcoin/bitcoin/pull/1935 script to verify the binaries] was contributed to the Bitcoin.org project.<br />
<br />
==External Links==<br />
<br />
* [https://github.com/bitcoin/bitcoin Bitcoin.org client source] project on Github<br />
* [https://github.com/bitcoin/gitian.sigs Gitain.sigs] Trusted build process signatures on Github<br />
* [http://bitcoin.org Bitcoin.org] website with releases<br />
<br />
==See Also==<br />
<br />
* [[Development process]]<br />
* [[Original Bitcoin client]]<br />
* [[:Category:Open_Source|Open source]]<br />
<br />
[[es:Proceso de publicación de versiones]]<br />
<br />
[[Category:Developer]]</div>Sgornickhttps://en.bitcoin.it/w/index.php?title=Release_process&diff=58939Release process2015-09-27T13:22:54Z<p>Sgornick: /* Bitcoin Core Open Source Release Process */ Change binary distribution as Sourceforge is no longer used.</p>
<hr />
<div>== Bitcoin Core Open Source Release Process ==<br />
<br />
Releases to the [[Original_Bitcoin_client|Bitcoin Core]] client and project are built and released using this process:<br />
<br />
* Labeled in github<br />
* Binaries are created for the platforms affected (usually all, Windows, Mac and Linux).<br />
* Binary file checksum(s) is(are) calculated and a message with those are signed by a core developer.<br />
** sha256 checksum<br />
* Files used to build are checksummed and submitted to the Gitian.sigs project on github.<br />
* Uploaded to distribution (Bitcoin.org/bin, and Launchpad.net for the Ubuntu PPA)<br />
* Blog post on Bitcoin.org<br />
* Forum post on BitcoinTalk.org<br />
<br />
==Verifying The Download==<br />
<br />
To verify the checksum for a binary download, first ensure the checksum file is secure by decrypting the SHA256SUMS.asc file:<br />
$ gpg --decrypt SHA256SUMS.asc<br />
<br />
Then verify the file checksum:<br />
$ openssl dgst -sha256 [binary release archive]<br />
<br />
Verify that the checksum matches the one in SHA256SUMS.asc<br />
<br />
A [https://github.com/bitcoin/bitcoin/pull/1935 script to verify the binaries] was contributed to the Bitcoin.org project.<br />
<br />
==External Links==<br />
<br />
* [https://github.com/bitcoin/bitcoin Bitcoin.org client source] project on Github<br />
* [https://github.com/bitcoin/gitian.sigs Gitain.sigs] Trusted build process signatures on Github<br />
* [http://bitcoin.org Bitcoin.org] website with releases<br />
<br />
==See Also==<br />
<br />
* [[Development process]]<br />
* [[Original Bitcoin client]]<br />
* [[:Category:Open_Source|Open source]]<br />
<br />
[[es:Proceso de publicación de versiones]]<br />
<br />
[[Category:Developer]]</div>Sgornickhttps://en.bitcoin.it/w/index.php?title=Development_process&diff=58938Development process2015-09-27T13:19:30Z<p>Sgornick: /* Bitcoin Core Open Source Development Process */ Update the link for the coding style doc to now be the Bitcoin Core Coding Standards doc.</p>
<hr />
<div>== Bitcoin Core Open Source Development Process ==<br />
<br />
The [[Original_Bitcoin_client|Bitcoin Core]] project operates an open contributor model where anyone is welcome to [https://github.com/bitcoin/bitcoin/blob/master/CONTRIBUTING.md contribute] towards development in the form of peer review, testing and patches.<br />
<br />
Bitcoin Core has transitioned from what was essentially a one-person software endeavor, with Satoshi functioning as the primary developer and gatekeeper for all changes, to a more distributed, free software model of development with hundreds of [http://github.com/bitcoin/bitcoin/graphs/contributors contributors]. The Linux Kernel development process is being used as the model for how changes flow into the original Bitcoin application:<br />
# Developers work in their own source code trees, sharing and testing patches with each other. Git, using github, is the preferred source control system for development.<br />
# When a developer thinks a patch is ready, they submit a pull request for the [https://github.com/bitcoin/bitcoin bitcoin github repository] and post a message on the [https://bitcointalk.org/index.php?board=6.0 Development and Technical Forum].<br />
# Pull requests are discussed on the forums and if there is consensus they're safe, tested, useful, well written, match coding style, etc. then they're merged into the 'master' branch.<br />
# The master github branch is regularly built and tested, and periodically given a &quot;release candidate&quot; tag followed by a version tag which is then an official, stable Bitcoin Core release.<br />
# After being accepted into the mainline master branch, bugfixes are merged or backported into the current stable branch, which periodically releases stable older versions.<br />
<br />
Please read and follow the [http://github.com/bitcoin/bitcoin/blob/master/doc/developer-notes.md Bitcoin Core Coding Standards document].<br />
<br />
==See Also==<br />
<br />
* [[Release process]]<br />
* [[Original Bitcoin client]]<br />
* [[:Category:Open_Source|Open source]]<br />
<br />
[[es:Proceso de desarrollo]]<br />
<br />
[[Category:Developer]]</div>Sgornickhttps://en.bitcoin.it/w/index.php?title=Development_process&diff=58937Development process2015-09-27T13:17:14Z<p>Sgornick: /* Bitcoin Core Open Source Development Process */ Update since Sourceforge is no longer part of the process.</p>
<hr />
<div>== Bitcoin Core Open Source Development Process ==<br />
<br />
The [[Original_Bitcoin_client|Bitcoin Core]] project operates an open contributor model where anyone is welcome to [https://github.com/bitcoin/bitcoin/blob/master/CONTRIBUTING.md contribute] towards development in the form of peer review, testing and patches.<br />
<br />
Bitcoin Core has transitioned from what was essentially a one-person software endeavor, with Satoshi functioning as the primary developer and gatekeeper for all changes, to a more distributed, free software model of development with hundreds of [http://github.com/bitcoin/bitcoin/graphs/contributors contributors]. The Linux Kernel development process is being used as the model for how changes flow into the original Bitcoin application:<br />
# Developers work in their own source code trees, sharing and testing patches with each other. Git, using github, is the preferred source control system for development.<br />
# When a developer thinks a patch is ready, they submit a pull request for the [https://github.com/bitcoin/bitcoin bitcoin github repository] and post a message on the [https://bitcointalk.org/index.php?board=6.0 Development and Technical Forum].<br />
# Pull requests are discussed on the forums and if there is consensus they're safe, tested, useful, well written, match coding style, etc. then they're merged into the 'master' branch.<br />
# The master github branch is regularly built and tested, and periodically given a &quot;release candidate&quot; tag followed by a version tag which is then an official, stable Bitcoin Core release.<br />
# After being accepted into the mainline master branch, bugfixes are merged or backported into the current stable branch, which periodically releases stable older versions.<br />
<br />
Please read and follow [https://raw.github.com/gavinandresen/bitcoin-git/master/doc/coding.txt coding.txt] for a description of the bitcoin coding style.<br />
<br />
==See Also==<br />
<br />
* [[Release process]]<br />
* [[Original Bitcoin client]]<br />
* [[:Category:Open_Source|Open source]]<br />
<br />
[[es:Proceso de desarrollo]]<br />
<br />
[[Category:Developer]]</div>Sgornickhttps://en.bitcoin.it/w/index.php?title=Development_process&diff=58935Development process2015-09-27T13:06:29Z<p>Sgornick: /* Bitcoin Core Open Source Development Process */ Add paragraph from Bitcoin project repo about contributing.</p>
<hr />
<div>== Bitcoin Core Open Source Development Process ==<br />
<br />
The [[Original_Bitcoin_client|Bitcoin Core]] project operates an open contributor model where anyone is welcome to [https://github.com/bitcoin/bitcoin/blob/master/CONTRIBUTING.md contribute] towards development in the form of peer review, testing and patches.<br />
<br />
Bitcoin Core has transitioned from what was essentially a one-person software endeavor, with Satoshi functioning as the primary developer and gatekeeper for all changes, to a more distributed, free software model of development with hundreds of [http://github.com/bitcoin/bitcoin/graphs/contributors contributors]. The Linux Kernel development process is being used as the model for how changes flow into the original Bitcoin application:<br />
# Developers work in their own source code trees, sharing and testing patches with each other. Git, using github, is the preferred source control system for development.<br />
# When a developer thinks a patch is ready, they submit a pull request for the [https://github.com/bitcoin/bitcoin bitcoin github repository] and post a message on the [https://bitcointalk.org/index.php?board=6.0 Development and Technical Forum].<br />
# Pull requests are discussed on the forums and if there is consensus they're safe, tested, useful, well written, match coding style, etc. then they're merged into the 'master' branch.<br />
# The master github branch is regularly built and tested, and periodically pushed to the [http://sourceforge.net/projects/bitcoin/develop subversion repository] to become a &quot;release candidate&quot; and then the official, stable, released bitcoin.<br />
# After being accepted into the mainline master branch, bugfixes are merged or backported into the current stable branch, which periodically releases stable older versions.<br />
<br />
Please read and follow [https://raw.github.com/gavinandresen/bitcoin-git/master/doc/coding.txt coding.txt] for a description of the bitcoin coding style.<br />
<br />
==See Also==<br />
<br />
* [[Release process]]<br />
* [[Original Bitcoin client]]<br />
* [[:Category:Open_Source|Open source]]<br />
<br />
[[es:Proceso de desarrollo]]<br />
<br />
[[Category:Developer]]</div>Sgornickhttps://en.bitcoin.it/w/index.php?title=Development_process&diff=58934Development process2015-09-27T13:04:17Z<p>Sgornick: /* Bitcoin Open Source Development Process */ Reference this is for Bitcoin Core specifically.</p>
<hr />
<div>== Bitcoin Core Open Source Development Process ==<br />
<br />
The [[Original_Bitcoin_client|Bitcoin Core]] client and project has transitioned from what was essentially a one-person software endeavor, with Satoshi functioning as the primary developer and gatekeeper for all changes, to a more distributed, free software model of development with hundreds of [http://github.com/bitcoin/bitcoin/graphs/contributors contributors]. The Linux Kernel development process is being used as the model for how changes flow into the original Bitcoin application:<br />
# Developers work in their own source code trees, sharing and testing patches with each other. Git, using github, is the preferred source control system for development.<br />
# When a developer thinks a patch is ready, they submit a pull request for the [https://github.com/bitcoin/bitcoin bitcoin github repository] and post a message on the [https://bitcointalk.org/index.php?board=6.0 Development and Technical Forum].<br />
# Pull requests are discussed on the forums and if there is consensus they're safe, tested, useful, well written, match coding style, etc. then they're merged into the 'master' branch.<br />
# The master github branch is regularly built and tested, and periodically pushed to the [http://sourceforge.net/projects/bitcoin/develop subversion repository] to become a &quot;release candidate&quot; and then the official, stable, released bitcoin.<br />
# After being accepted into the mainline master branch, bugfixes are merged or backported into the current stable branch, which periodically releases stable older versions.<br />
<br />
Please read and follow [https://raw.github.com/gavinandresen/bitcoin-git/master/doc/coding.txt coding.txt] for a description of the bitcoin coding style.<br />
<br />
==See Also==<br />
<br />
* [[Release process]]<br />
* [[Original Bitcoin client]]<br />
* [[:Category:Open_Source|Open source]]<br />
<br />
[[es:Proceso de desarrollo]]<br />
<br />
[[Category:Developer]]</div>Sgornickhttps://en.bitcoin.it/w/index.php?title=User:Sgornick&diff=58931User:Sgornick2015-09-27T10:06:53Z<p>Sgornick: Remove projects.</p>
<hr />
<div>Stephen Gornick<br />
* Los Angeles area, Southern California, USA<br />
* Programmer (Python, Google App Engine)<br />
* Entrepreneur<br />
<br />
I curate Bitcoin news on the [http://Twitter.com/TopNewsBitcoin @TopNewsBitcoin] Twitter account.<br />
<br />
==Contact==<br />
* Phone: +1.310.356.9912<br />
* email: sgornick@digicoast.com<br />
* Twitter: [http://twitter.com/sgornick @sgornick]<br />
<br />
Contributors Award participant: 16EdR3VRkz1D2PHDyT5iXhub4CJRyDmo6x<br />
<br />
[[Category:Freelancers]]</div>Sgornickhttps://en.bitcoin.it/w/index.php?title=Release_process&diff=58930Release process2015-09-27T10:00:23Z<p>Sgornick: /* Bitcoin Open Source Release Process */ Reference this is for Bitcoin Core specifically.</p>
<hr />
<div>== Bitcoin Core Open Source Release Process ==<br />
<br />
Releases to the [[Original_Bitcoin_client|Bitcoin Core]] client and project are built and released using this process:<br />
<br />
* Labeled in github<br />
* Binaries are created for the platforms affected (usually all, Windows, Mac and Linux).<br />
* Binary file checksum(s) is(are) calculated and a message with those are signed by a core developer.<br />
** sha256 checksum<br />
* Files used to build are checksummed and submitted to the Gitian.sigs project on github.<br />
* Uploaded to sourceforge<br />
* Blog post on Bitcoin.org<br />
* Forum post on BitcoinTalk.org<br />
<br />
==Verifying The Download==<br />
<br />
To verify the checksum for a binary download, first ensure the checksum file is secure by decrypting the SHA256SUMS.asc file:<br />
$ gpg --decrypt SHA256SUMS.asc<br />
<br />
Then verify the file checksum:<br />
$ openssl dgst -sha256 [binary release archive]<br />
<br />
Verify that the checksum matches the one in SHA256SUMS.asc<br />
<br />
A [https://github.com/bitcoin/bitcoin/pull/1935 script to verify the binaries] was contributed to the Bitcoin.org project.<br />
<br />
==External Links==<br />
<br />
* [https://github.com/bitcoin/bitcoin Bitcoin.org client source] project on Github<br />
* [https://github.com/bitcoin/gitian.sigs Gitain.sigs] Trusted build process signatures on Github<br />
* [http://bitcoin.org Bitcoin.org] website with releases<br />
<br />
==See Also==<br />
<br />
* [[Development process]]<br />
* [[Original Bitcoin client]]<br />
* [[:Category:Open_Source|Open source]]<br />
<br />
[[es:Proceso de publicación de versiones]]<br />
<br />
[[Category:Developer]]</div>Sgornickhttps://en.bitcoin.it/w/index.php?title=Development_process&diff=58929Development process2015-09-27T09:55:35Z<p>Sgornick: /* Bitcoin Open Source Development Process */ Add reference to contributors.</p>
<hr />
<div>== Bitcoin Open Source Development Process ==<br />
<br />
The [[Original_Bitcoin_client|Bitcoin client]] project has transitioned from what was essentially a one-person software endeavor, with Satoshi functioning as the primary developer and gatekeeper for all changes, to a more distributed, free software model of development with hundreds of [http://github.com/bitcoin/bitcoin/graphs/contributors contributors]. The Linux Kernel development process is being used as the model for how changes flow into the original Bitcoin application:<br />
# Developers work in their own source code trees, sharing and testing patches with each other. Git, using github, is the preferred source control system for development.<br />
# When a developer thinks a patch is ready, they submit a pull request for the [https://github.com/bitcoin/bitcoin bitcoin github repository] and post a message on the [https://bitcointalk.org/index.php?board=6.0 Development and Technical Forum].<br />
# Pull requests are discussed on the forums and if there is consensus they're safe, tested, useful, well written, match coding style, etc. then they're merged into the 'master' branch.<br />
# The master github branch is regularly built and tested, and periodically pushed to the [http://sourceforge.net/projects/bitcoin/develop subversion repository] to become a &quot;release candidate&quot; and then the official, stable, released bitcoin.<br />
# After being accepted into the mainline master branch, bugfixes are merged or backported into the current stable branch, which periodically releases stable older versions.<br />
<br />
Please read and follow [https://raw.github.com/gavinandresen/bitcoin-git/master/doc/coding.txt coding.txt] for a description of the bitcoin coding style.<br />
<br />
==See Also==<br />
<br />
* [[Release process]]<br />
* [[Original Bitcoin client]]<br />
* [[:Category:Open_Source|Open source]]<br />
<br />
[[es:Proceso de desarrollo]]<br />
<br />
[[Category:Developer]]</div>Sgornickhttps://en.bitcoin.it/w/index.php?title=Research&diff=58826Research2015-09-17T01:25:58Z<p>Sgornick: Formatting.</p>
<hr />
<div>Publications including research and analysis of Bitcoin or related areas.<br />
<br />
{| class=&quot;wikitable sortable&quot;<br />
! Title<br />
! Author<br />
! width=150 | Type<br />
! width=75 | Date<br />
! Links<br />
|-<br />
| Cyberlaundering: Anonymous Digital Cash and Money Laundering<br />
| R. Mark Bortner<br />
| Research paper<br />
| 1996<br />
| [http://osaka.law.miami.edu/~froomkin/seminar/papers/bortner.htm Download]<br />
|-<br />
| Triple Entry Accounting<br />
| Ian Grigg<br />
| Research paper<br />
| 2005-12-25<br />
| [http://iang.org/papers/triple_entry.html Download]<br />
|-<br />
| [[Bitcoin_whitepaper|Bitcoin: A Peer-to-Peer Electronic Cash System]]<br />
| [[Satoshi Nakamoto]]<br />
| Research paper<br />
| 2008-10-31<br />
| [http://bitcoin.org/bitcoin.pdf Download]<br />
|-<br />
| An Analysis of Anonymity in the Bitcoin System<br />
| Fergal Reid, Martin Harrigan<br />
| Research paper<br />
| 2011-07-22<br />
| [http://arxiv.org/abs/1107.4524 Download], [http://bitcointalk.org/index.php?topic=31539.0 discussion]<br />
|-<br />
| Shadowy Figures: Tracking Illicit Financial Transactions in the Murky World of Digital Currencies, Peer–to–Peer Networks, and Mobile Device Payments<br />
| John Villasenor, Cody Monk, Christopher Bronk<br />
| Research paper<br />
| 2011-08-29<br />
| [http://www.bakerinstitute.org/publications/ITP-pub-FinancialTransactions-082911.pdf Download]<br />
|-<br />
| Bitcoin: An Innovative Alternative Digital Currency<br />
| Reuben Grinberg<br />
| Research paper<br />
| 2011-12-09<br />
| [http://papers.ssrn.com/sol3/papers.cfm?abstract_id=1817857 Download], [http://www.bitcointalk.org/index.php?topic=6247.0 discussion]<br />
|-<br />
| Bitcoin NFC<br />
| David Allen Bronleewe<br />
| Master's report<br />
| 2011-08<br />
| [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]<br />
|-<br />
| Optimal pool abuse strategy<br />
| Raulo<br />
| Research paper<br />
| 2011-02-04<br />
| [http://bitcoin.atspace.com/poolcheating.pdf Download], [http://www.bitcointalk.org/index.php?topic=3165.0 discussion]<br />
|-<br />
| Abusing Bitcoin cooperative mining pools: strategies for egoistical but honest miners<br />
| Nakamoto Ryo<br />
| Research paper<br />
| 2011<br />
| [http://www.bitcoinservice.co.uk/files/111 Download], [http://www.bitcointalk.org/index.php?topic=2941.0 discussion]<br />
|-<br />
| Analysis of Bitcoin Pooled Mining Reward Systems<br />
| Meni Rosenfeld<br />
| Research paper<br />
| 2011-11-07<br />
| [https://bitcoil.co.il/pool_analysis.pdf Download], [http://bitcointalk.org/index.php?topic=32814.0 discussion]<br />
|-<br />
| Bitcoin Exchange system<br />
| Tomáš Jiříček<br />
| Research paper<br />
| 2012<br />
| [https://dip.felk.cvut.cz/browse/pdfcache/jiricto2_2012bach.pdf Download]<br />
|-<br />
| On Bitcoin and Red Balloons<br />
| Moshe Babaioff, Shahar Dobzinski, Sigal Oren, Aviv Zohar<br />
| Publication article<br />
| 2012<br />
| [http://research.microsoft.com/pubs/156072/bitcoin.pdf Download]<br />
|-<br />
| 2011 Observations on the Digital Currency Industry<br />
| Mark Herpel<br />
| Publication article<br />
| 2011<br />
| [http://papers.ssrn.com/sol3/papers.cfm?abstract_id=1721076 Download]<br />
|-<br />
| MAVE, New Lightweight Digital Signature Protocols for Massive Verifications<br />
| Sergio Demian Lerner<br />
| Research paper (preliminary)<br />
| 2012<br />
| [http://bitslog.files.wordpress.com/2012/04/mave1.pdf Download]<br />
|-<br />
| MAVEPAY, a New Lightweight Payment Scheme for Peer to Peer Currency Networks<br />
| Sergio Demian Lerner<br />
| Research paper (preliminary)<br />
| 2012<br />
| [http://bitslog.files.wordpress.com/2012/04/mavepay1.pdf Download]<br />
|-<br />
| Bitcoin: Eine erste Einordnung (an initial classification)<br />
| Christoph Sorge, Artus Krohn-Grimberghe<br />
| Research paper<br />
| 2012<br />
| [http://www.springerlink.com/content/cw1v762571tr4462/ Download], [http://bitcointalk.org/index.php?topic=90233.0 discussion]<br />
|-<br />
| Bitcoin - an introduction to the workings and a preliminary analysis and understanding of potential legal issues<br />
| Jean-Daniel Schmid, Alexander Schmid<br />
| Article<br />
| 2012<br />
| [http://ef-r.ch/images/publications/1338882576_Bitcoin.pdf Download]<br />
|-<br />
| Secure multiparty Bitcoin anonymization<br />
| Edward Z. Yang<br />
| Article<br />
| 2012<br />
| [http://blog.ezyang.com/2012/07/secure-multiparty-bitcoin-anonymization/ Download], [http://www.reddit.com/r/Bitcoin/comments/wvm2w/secure_multiparty_bitcoin_anonymization/ discussion]<br />
|-<br />
| Bitcoin &amp; Gresham's Law - the economic inevitability of Collapse<br />
| Philipp Güring, Ian Grigg<br />
| Article<br />
| 2011<br />
| [http://iang.org/papers/BitcoinBreachesGreshamsLaw.pdf Download]<br />
|-<br />
| Today Techies, Tomorrow the World? Bitcoin.<br />
| Reuben Grinberg<br />
| Article<br />
| 2012<br />
| [http://www.milkeninstitute.org/publications/review/2012_1/22-31MR53.pdf Download]<br />
|-<br />
| Traveling the Silk Road: A measurement analysis of a large anonymous online marketplace<br />
| Nicolas Christin<br />
| Research paper<br />
| 2012<br />
| [http://www.cylab.cmu.edu/files/pdfs/tech_reports/CMUCyLab12018.pdf Download]<br />
|-<br />
| CommitCoin: Carbon Dating Commitments with Bitcoin<br />
| Jeremy Clark and Aleksander Essex<br />
| Research paper<br />
| 2012<br />
| [http://people.scs.carleton.ca/~clark/papers/2012_fc.pdf Download extended abstract]&lt;br /&gt;[http://eprint.iacr.org/2011/677.pdf Download technical report]<br />
|-<br />
| Quantitative Analysis of the Full Bitcoin Transaction Graph<br />
| Dorit Ron and Adi Shamir<br />
| Research paper<br />
| 2012<br />
| [http://eprint.iacr.org/2012/584.pdf Download]<br />
|-<br />
| Design and security analysis of Bitcoin infrastructure using application deployed on Google Apps Engine<br />
| Piotr &quot;ThePiachu&quot; Piasecki<br />
| Master's thesis<br />
| 2012<br />
| [https://dl.dropbox.com/u/3658181/PiotrPiasecki-BitcoinMasterThesis.pdf Download], [https://bitcointalk.org/index.php?topic=88149.0 discussion]<br />
|-<br />
| The Production of Freedom: Value Production in the US- dominated Financial System, and Possible Alternatives<br />
| Jeremy Kirshbaum<br />
| Master's thesis (preliminary)<br />
| 2012<br />
| [https://docs.google.com/document/d/1JIyMWIibqH8x20vGBTMBZ2yqM7Xbp54UpWBh0o2H7WI/edit?pli=1 Download], [https://bitcointalk.org/index.php?topic=87404.0 discussion]<br />
|-<br />
| COIN: a distributed accounting system for peer to peer networks<br />
| Fabio Varesano<br />
| Bachelor's thesis<br />
| 2012<br />
| [http://www.varesano.net/contents/projects/coin%20distributed%20accounting%20system%20peer%20peer%20networks Download]<br />
|-<br />
| BITCOIN CLIENTS<br />
| Rostislav Skudnov<br />
| Bachelor's thesis<br />
| 2012<br />
| [http://publications.theseus.fi/bitstream/handle/10024/47166/Skudnov_Rostislav.pdf?sequence=1 Download]<br />
|-<br />
| Bitter to Better—How to Make Bitcoin a Better Currency<br />
| Simon Barber, Xavier Boyen, Elaine Shi, Ersin Uzun<br />
| Research paper<br />
| 2012<br />
| [http://crypto.stanford.edu/~xb/fc12/bitcoin.pdf Download]<br />
|-<br />
| NooShare: A decentralized ledger of shared computational resources<br />
| Alex Coventry<br />
| Research paper<br />
| 2012<br />
| [http://mit.edu/alex_c/www/nooshare.pdf Download]<br />
|-<br />
| Bits and Bets. Information, Price Volatility, and Demand for Bitcoin<br />
| Martis Buchholz, Jess Delaney, Joseph Warren<br />
| Final project<br />
| 2012<br />
| [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]<br />
|-<br />
| Two Bitcoins at the Price of One? Double Spending attacks on Fast Payments in Bitcoin<br />
| Ghassan O. Karame, Elli Androulaki, Srdjan Cap-kun <br />
| Research paper<br />
| 2012<br />
| [http://eprint.iacr.org/2012/248 Download]<br />
|-<br />
| Nerdy Money: Bitcoin, the Private Digital Currency, and the Case Against Its Regulation<br />
| Nikolei M. Kaplanov<br />
| Research paper<br />
| 2012<br />
| [http://papers.ssrn.com/sol3/papers.cfm?abstract_id=2115203 Abstract]<br />
|-<br />
| Analysis of hashrate-based double-spending<br />
| Meni Rosenfeld<br />
| Research paper<br />
| 2012<br />
| [https://bitcoil.co.il/Doublespend.pdf Download]<br />
|-<br />
| Homomorphic Payment Addresses and the Pay-to-Contract Protocol<br />
| Ilja Gerhardt, Timo Hanke<br />
| Research Paper<br />
| 2012<br />
| [http://arxiv.org/pdf/1212.3257v1 Download] ([http://docs.google.com/viewer?url=http%3A%2F%2Farxiv.org%2Fpdf%2F1212.325qq7v1 via web viewer])<br />
|-<br />
| Quasi-Commodity Money (February 6, 2012). &quot;This paper considers reform possibilities posed by a type of base money that has heretofore been overlooked in the literature on monetary economics.&quot;<br />
| George Selgin<br />
| Working Papers Series<br />
| 2012<br />
| [http://ssrn.com/abstract=2000118 Download]<br />
|-<br />
| Virtual currency schemes - &quot;This report is a first attempt to provide the basis for a discussion on virtual currency schemes.&quot;<br />
| European Central Bank<br />
| Paper<br />
| 2012<br />
| [http://www.ecb.europa.eu/pub/pdf/other/virtualcurrencyschemes201210en.pdf Download]<br />
|-<br />
| Evaluating User Privacy in Bitcoin<br />
| Elli Androulaki, Ghassan Karame, Marc Roeschlin, Tobias Scherer and Srdjan Capkun <br />
| Paper<br />
| 2013<br />
| [http://fc13.ifca.ai/proc/1-3.pdf Download] ([http://fc13.ifca.ai/slide/1-3.pdf Slides]) <br />
|-<br />
| Beware the Middleman: Empirical Analysis of Bitcoin-Exchange Risk<br />
| Tyler Moore and Nicolas Christin <br />
| Short Paper<br />
| 2013<br />
| [http://fc13.ifca.ai/proc/1-2.pdf Download] ([http://fc13.ifca.ai/slide/1-2.pdf Slides]) <br />
|-<br />
| Bitcoin, Regulating Fraud In The E-Conomy Of Hacker-Cash<br />
| Derek A. Dion<br />
| Paper<br />
| 2013<br />
| [http://illinoisjltp.com/journal/wp-content/uploads/2013/05/Dion.pdf Download]<br />
|-<br />
| The practical materiality of Bitcoin<br />
| Bill Maurera, Taylor C. Nelmsa &amp; Lana Swartz <br />
| Paper<br />
| 2013<br />
| [http://www.tandfonline.com/doi/full/10.1080/10350330.2013.777594#.UbbTVaD_6b4 Download]<br />
|-<br />
| Regulating Digital Currencies: Bringing Bitcoin within the Reach of the IMF<br />
| Nicholas Plassaras <br />
| Paper<br />
| 2013<br />
| [https://papers.ssrn.com/sol3/papers.cfm?abstract_id=2248419 Download]<br />
|-<br />
| Bitcoin is Memory<br />
| William J. Luther, Josiah Olson <br />
| Paper<br />
| 2013<br />
| [http://papers.ssrn.com/sol3/papers.cfm?abstract_id=2275730 Download]<br />
|-<br />
| The Economics of Bitcoin Mining or, Bitcoin in the Presence of Adversaries<br />
| Joshua A. Kroll, Ian C. Davey, and Edward W. Felten <br />
| Paper<br />
| 2013<br />
| [http://www.weis2013.econinfosec.org/papers/KrollDaveyFeltenWEIS2013.pdf Download]<br />
|-<br />
| Bitcoin: A Primer for Policymakers<br />
| Jerry Brito, Andrea Castillo<br />
| Research paper<br />
| 2013<br />
| [http://mercatus.org/publication/bitcoin-primer-policymakers Abstract] [http://mercatus.org/sites/default/files/Brito_BitcoinPrimer.pdf Download]<br />
|-<br />
| Whack-a-Mole: Prosecuting Digital Currency Exchanges<br />
| Catherine Martin Christopher <br />
| Research paper<br />
| 2013<br />
| [http://papers.ssrn.com/sol3/papers.cfm?abstract_id=2312787 Abstract]<br />
[http://papers.ssrn.com/sol3/Delivery.cfm/SSRN_ID2312787_code1372021.pdf?abstractid=2312787&amp;mirid=2 Download]<br />
|-<br />
| Are Cryptocurrencies 'Super' Tax Havens?<br />
| Omri Y. Marian<br />
| Research paper<br />
| 2013<br />
| [http://papers.ssrn.com/sol3/papers.cfm?abstract_id=2305863 Abstract]<br />
[http://papers.ssrn.com/sol3/Delivery.cfm/SSRN_ID2316499_code592645.pdf?abstractid=2305863&amp;mirid=1 Download]<br />
|-<br />
| Collective Emergent Institutional Entrepreneurship Through Bitcoin<br />
| Robin Teigland, Zeynep Yetis and Tomas Olov Larsson <br />
| Research paper<br />
| 2013<br />
| [http://papers.ssrn.com/sol3/papers.cfm?abstract_id=2263707 Abstract]<br />
[http://papers.ssrn.com/sol3/Delivery.cfm/SSRN_ID2263707_code2053543.pdf?abstractid=2263707&amp;mirid=1 Download]<br />
|-<br />
| Anonymity of Bitcoin Transactions<br />
| Malte Möser<br />
| Research paper<br />
| 2013<br />
| [https://www.wi.uni-muenster.de/sites/default/files/public/department/itsecurity/mbc13/mbc13-moeser-paper.pdf Download]<br />
|-<br />
| On the origins of Bitcoin: Stages of monetary evolution<br />
| Konrad S. Graf <br />
| Research paper<br />
| 2013<br />
| [http://konradsgraf.com/blog1/2013/10/23/on-the-origins-of-bitcoin-my-new-work-on-bitcoin-and-monetar.html Abstract]<br />
[http://konradsgraf.com/storage/On%20the%20Origins%20of%20Bitcoin%20Graf%2023.10.13.pdf Download]<br />
|-<br />
| Majority is not Enough: Bitcoin Mining is Vulnerable<br />
| Ittay Eyal and Emin Gun Sirer<br />
| Research paper<br />
| 2013<br />
| [http://arxiv.org/abs/1311.0243 Abstract]<br />
[http://arxiv.org/pdf/1311.0243v1 Download]<br />
|-<br />
| Bitcoin, the end of the Taboo on Money<br />
| Denis Roio aka Jaromil<br />
| Humanities article<br />
| 2013<br />
| [http://www.dyndy.net/2013/04/bitcoin-ends-the-taboo-on-money/ Abstract]<br />
[https://files.dyne.org/readers/Bitcoin_end_of_taboo_on_money.pdf Download]<br />
|-<br />
| Secure Multiparty Computations on BitCoin<br />
| Marcin Andrychowicz, Stefan Dziembowski, Daniel Malinowski and Łukasz Mazurek University of Warsaw <br />
| Research paper<br />
| 2013<br />
| [http://eprint.iacr.org/2013/784 Abstract]<br />
[http://eprint.iacr.org/eprint-bin/cite.pl?entry=2013/784 BibTeX]<br />
[http://eprint.iacr.org/2013/784.pdf Download]<br />
|-<br />
| A Fistful of Bitcoins: Characterizing Payments Among Men with No Names<br />
| Sarah Meiklejohn, Marjori Pomarole, Grant Jordan, Kirill Levchenko, Damon McCoy, Geoffrey M. Voelker, Stefan Savage<br />
| Research paper<br />
| 2013<br />
| <br />
[http://www.cs.gmu.edu/~mccoy/papers/imc13.pdf Download]<br />
|-<br />
| Information Propagation in the Bitcoin Network<br />
| Christian Decker (ETH Zurich, Switzerland), Roger Wattenhofer (Microsoft Research)<br />
| Research paper<br />
| 2013<br />
| <br />
[http://www.tik.ee.ethz.ch/file/49318d3f56c1d525aabf7fda78b23fc0/P2P2013_041.pdf Download]<br />
|-<br />
| Have a Snack, Pay with Bitcoins<br />
| Tobias Bamert, Christian Decker, Lennart Elsen, Roger Wattenhofer, Samuel Welten<br />
| Research paper<br />
| 2013<br />
| <br />
[http://www.tik.ee.ethz.ch/file/848064fa2e80f88a57aef43d7d5956c6/P2P2013_093.pdf Download]<br />
|-<br />
| The Economics of Private Digital Currency<br />
| Gerald P Dwyer<br />
| Research paper<br />
| 2014<br />
| [http://mpra.ub.uni-muenchen.de/55824/ Abstract]<br />
[http://mpra.ub.uni-muenchen.de/55824/1/MPRA_paper_55824.pdf Download]<br />
|-<br />
| The Origin, Classification and Utility of Bitcoin<br />
| Peter Šurda <br />
| Research Paper<br />
| 2014<br />
| [http://papers.ssrn.com/sol3/papers.cfm?abstract_id=2436823 Abstract]<br />
|-<br />
| Deanonymisation of clients in Bitcoin P2P network<br />
| Alex Biryukov, Dmitry Khovratovich and Ivan Pustogarov<br />
| Research Paper<br />
| 2014<br />
| [http://arxiv.org/abs/1405.7418 Abstract] [http://arxiv.org/pdf/1405.7418v2.pdf Download]<br />
|-<br />
| Bitcoin Financial Regulation: Securities, Derivatives, Prediction Markets, &amp; Gambling<br />
| Jerry Brito, Houman B. Shadab, Andrea Castillo<br />
| Research Paper<br />
| 2014<br />
| [http://papers.ssrn.com/sol3/papers.cfm?abstract_id=2423461 Abstract] [http://papers.ssrn.com/sol3/Delivery.cfm/SSRN_ID2426195_code510873.pdf?abstractid=2423461&amp;mirid=1 Download]<br />
|-<br />
| What are the main drivers of the Bitcoin price?<br />
| Ladislav Kristoufek<br />
| Research Paper<br />
| 2014<br />
| [http://arxiv.org/pdf/1406.0268v1.pdf Download]<br />
|-<br />
| The Economics of Bitcoin<br />
| Andre Herman<br />
| Bachelor's thesis<br />
| 2014<br />
| [http://www.scribd.com/doc/231964435/The-Economics-of-Bitcoin Download]<br />
|-<br />
| Near Zero Bitcoin Transaction Fees Cannot Last Forever<br />
| Kerem Kaşkaloğlu<br />
| Research Paper<br />
| 2014<br />
| [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]<br />
|-<br />
| Is Bitcoin Money?<br />
| Ísak Andri Ólafsson<br />
| Thesis Paper<br />
| 2014<br />
| [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]<br />
|-<br />
| The (A)Political Economy of Bitcoin<br />
| Vasilis Kostakis and Chris Giotitsas<br />
| Essay<br />
| 2014<br />
| [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]<br />
|-<br />
| When your sensor earns money: exchanging data for cash with Bitcoin<br />
| Dominic Wörner and Thomas von Bomhard<br />
| Research<br />
| 2014<br />
| [http://dl.acm.org/citation.cfm?id=2638786 Abstract] [http://dl.acm.org/ft_gateway.cfm?id=2638786&amp;ftid=1500778&amp;dwn=1&amp;CFID=579517323&amp;CFTOKEN=37552107 Download]<br />
|-<br />
| Bitcoin Transaction Malleability and MtGox <br />
| Christian Decker, Roger Wattenhofer<br />
| Research<br />
| 2014<br />
| [http://www.tik.ee.ethz.ch/file/7e4a7f3f2991784786037285f4876f5c/malleability.pdf Download]<br />
|-<br />
| BlueWallet: The Secure Bitcoin Wallet<br />
| Tobias Bamert, Christian Decker, Roger Wattenhofer and Samuel Welten<br />
| Research<br />
| 2014<br />
| [http://www.tik.ee.ethz.ch/file/0c347a9a3803cb937d360cba511e5019/stm2014_submission_12.pdf Download]<br />
|-<br />
| Bitcoin over Tor isn’t a good idea<br />
| Alex Biryukov and Ivan Pustogarov<br />
| Research<br />
| 2014<br />
| [http://arxiv.org/pdf/1410.6079v1.pdf Download]<br />
|-<br />
| Sidechained Bitcoin Substitutes, A Monetary Commentary<br />
| Konrad S. Graf<br />
| Essay<br />
| 2014<br />
| [http://konradsgraf.squarespace.com/storage/Monetary%20analsyis%20of%20sidecoins%20KG%2024Oct2014.pdf Download]<br />
|-<br />
| Taxation of virtual currency<br />
| Aleksandra Bal<br />
| PhD thesis<br />
| 2014<br />
| [http://hdl.handle.net/1887/29963 Abstract] [https://openaccess.leidenuniv.nl/bitstream/handle/1887/29963/000-5-Bal-14-10-2014.pdf Download]<br />
|-<br />
| A First Look at the Usability of Bitcoin Key Management<br />
| Shayan Eskandari, David Barrera, Elizabeth Stobert, and Jeremy Clark<br />
| Research Paper<br />
| 2015<br />
| [http://www.internetsociety.org/sites/default/files/05_3_3.pdf Download]<br />
|-<br />
| Value Creation in Cryptocurrency Networks: Towards A Taxonomy of Digital Business Models for Bitcoin Companies<br />
| Erol Kazan, Chee-Wee Tan, Eric T.K. Lim<br />
| Research Paper<br />
| 2015<br />
| [http://aisel.aisnet.org/pacis2015/34/ Abstract] [http://aisel.aisnet.org/cgi/viewcontent.cgi?article=1222&amp;context=pacis2015 Download]<br />
|-<br />
| Authenticated Key Exchange over Bitcoin<br />
| Patrick McCorry, Siamak F. Shahandashti, Dylan Clarke, Feng Hao<br />
| Research Paper<br />
| 2015<br />
| [http://eprint.iacr.org/2015/308.pdf Download]<br />
|-<br />
| Bitcoin and Beyond: A Technical Survey on Decentralized Digital Currencies<br />
| Florian Tschorsch and Björn Scheuermann<br />
| Research Paper<br />
| 2015<br />
| [http://eprint.iacr.org/2015/464.pdf Download]<br />
|-<br />
| Bitcoin Duplex Micropayment Channels<br />
| Christian Decker and Roger Wattenhofer<br />
| Research Paper<br />
| 2015<br />
| [http://www.tik.ee.ethz.ch/file/716b955c130e6c703fac336ea17b1670/duplex-micropayment-channels.pdf Download]<br />
|-<br />
| The Bitcoin Lightning Network: Scalable Off-Chain Instant Payments<br />
| Joseph Poon and Thaddeus Dryja<br />
| Research Paper<br />
| 2015<br />
| [http://lightning.network/lightning-network-paper.pdf Download]<br />
|-<br />
| Bitcoin and the Uniform Commercial Code<br />
| Jeanne L. Schroeder<br />
| Research Paper<br />
| 2015<br />
| [http://papers.ssrn.com/sol3/papers.cfm?abstract_id=2649441 Abstract] [http://papers.ssrn.com/sol3/Delivery.cfm/SSRN_ID2649441_code1717611.pdf?abstractid=2649441&amp;mirid=1 Download]<br />
|}<br />
<br />
==See Also==<br />
<br />
* [http://encryptopedia.com/ Encryptopedia - Scientific research and white papers on bitcoin, blockchain technology, cryptography, algorithms and cryptocurrencies]<br />
* [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&amp;pli=1&amp;sle=true Full List])<br />
* [http://www.opencryptocurrencyreview.com/ OpenCryptocurrencyReview - A repository of Bitcoin and related research]<br />
* [http://people.scs.carleton.ca/~clark/biblio.html Jeremy Clark's Bitcoin Bibliography]<br />
* [[:Category:Economics|Economic]]<br />
* [[:Category:Technical|Technical]]<br />
* [[Press]]<br />
<br />
[[Category:Research]]</div>Sgornickhttps://en.bitcoin.it/w/index.php?title=Research&diff=58825Research2015-09-17T01:24:18Z<p>Sgornick: Add entry for Bitcoin and the Uniform Commercial Code by Jeanne L. Schroeder.</p>
<hr />
<div>Publications including research and analysis of Bitcoin or related areas.<br />
<br />
{| class=&quot;wikitable sortable&quot;<br />
! Title<br />
! Author<br />
! width=150 | Type<br />
! width=75 | Date<br />
! Links<br />
|-<br />
| Cyberlaundering: Anonymous Digital Cash and Money Laundering<br />
| R. Mark Bortner<br />
| Research paper<br />
| 1996<br />
| [http://osaka.law.miami.edu/~froomkin/seminar/papers/bortner.htm Download]<br />
|-<br />
| Triple Entry Accounting<br />
| Ian Grigg<br />
| Research paper<br />
| 2005-12-25<br />
| [http://iang.org/papers/triple_entry.html Download]<br />
|-<br />
| [[Bitcoin_whitepaper|Bitcoin: A Peer-to-Peer Electronic Cash System]]<br />
| [[Satoshi Nakamoto]]<br />
| Research paper<br />
| 2008-10-31<br />
| [http://bitcoin.org/bitcoin.pdf Download]<br />
|-<br />
| An Analysis of Anonymity in the Bitcoin System<br />
| Fergal Reid, Martin Harrigan<br />
| Research paper<br />
| 2011-07-22<br />
| [http://arxiv.org/abs/1107.4524 Download], [http://bitcointalk.org/index.php?topic=31539.0 discussion]<br />
|-<br />
| Shadowy Figures: Tracking Illicit Financial Transactions in the Murky World of Digital Currencies, Peer–to–Peer Networks, and Mobile Device Payments<br />
| John Villasenor, Cody Monk, Christopher Bronk<br />
| Research paper<br />
| 2011-08-29<br />
| [http://www.bakerinstitute.org/publications/ITP-pub-FinancialTransactions-082911.pdf Download]<br />
|-<br />
| Bitcoin: An Innovative Alternative Digital Currency<br />
| Reuben Grinberg<br />
| Research paper<br />
| 2011-12-09<br />
| [http://papers.ssrn.com/sol3/papers.cfm?abstract_id=1817857 Download], [http://www.bitcointalk.org/index.php?topic=6247.0 discussion]<br />
|-<br />
| Bitcoin NFC<br />
| David Allen Bronleewe<br />
| Master's report<br />
| 2011-08<br />
| [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]<br />
|-<br />
| Optimal pool abuse strategy<br />
| Raulo<br />
| Research paper<br />
| 2011-02-04<br />
| [http://bitcoin.atspace.com/poolcheating.pdf Download], [http://www.bitcointalk.org/index.php?topic=3165.0 discussion]<br />
|-<br />
| Abusing Bitcoin cooperative mining pools: strategies for egoistical but honest miners<br />
| Nakamoto Ryo<br />
| Research paper<br />
| 2011<br />
| [http://www.bitcoinservice.co.uk/files/111 Download], [http://www.bitcointalk.org/index.php?topic=2941.0 discussion]<br />
|-<br />
| Analysis of Bitcoin Pooled Mining Reward Systems<br />
| Meni Rosenfeld<br />
| Research paper<br />
| 2011-11-07<br />
| [https://bitcoil.co.il/pool_analysis.pdf Download], [http://bitcointalk.org/index.php?topic=32814.0 discussion]<br />
|-<br />
| Bitcoin Exchange system<br />
| Tomáš Jiříček<br />
| Research paper<br />
| 2012<br />
| [https://dip.felk.cvut.cz/browse/pdfcache/jiricto2_2012bach.pdf Download]<br />
|-<br />
| On Bitcoin and Red Balloons<br />
| Moshe Babaioff, Shahar Dobzinski, Sigal Oren, Aviv Zohar<br />
| Publication article<br />
| 2012<br />
| [http://research.microsoft.com/pubs/156072/bitcoin.pdf Download]<br />
|-<br />
| 2011 Observations on the Digital Currency Industry<br />
| Mark Herpel<br />
| Publication article<br />
| 2011<br />
| [http://papers.ssrn.com/sol3/papers.cfm?abstract_id=1721076 Download]<br />
|-<br />
| MAVE, New Lightweight Digital Signature Protocols for Massive Verifications<br />
| Sergio Demian Lerner<br />
| Research paper (preliminary)<br />
| 2012<br />
| [http://bitslog.files.wordpress.com/2012/04/mave1.pdf Download]<br />
|-<br />
| MAVEPAY, a New Lightweight Payment Scheme for Peer to Peer Currency Networks<br />
| Sergio Demian Lerner<br />
| Research paper (preliminary)<br />
| 2012<br />
| [http://bitslog.files.wordpress.com/2012/04/mavepay1.pdf Download]<br />
|-<br />
| Bitcoin: Eine erste Einordnung (an initial classification)<br />
| Christoph Sorge, Artus Krohn-Grimberghe<br />
| Research paper<br />
| 2012<br />
| [http://www.springerlink.com/content/cw1v762571tr4462/ Download], [http://bitcointalk.org/index.php?topic=90233.0 discussion]<br />
|-<br />
| Bitcoin - an introduction to the workings and a preliminary analysis and understanding of potential legal issues<br />
| Jean-Daniel Schmid, Alexander Schmid<br />
| Article<br />
| 2012<br />
| [http://ef-r.ch/images/publications/1338882576_Bitcoin.pdf Download]<br />
|-<br />
| Secure multiparty Bitcoin anonymization<br />
| Edward Z. Yang<br />
| Article<br />
| 2012<br />
| [http://blog.ezyang.com/2012/07/secure-multiparty-bitcoin-anonymization/ Download], [http://www.reddit.com/r/Bitcoin/comments/wvm2w/secure_multiparty_bitcoin_anonymization/ discussion]<br />
|-<br />
| Bitcoin &amp; Gresham's Law - the economic inevitability of Collapse<br />
| Philipp Güring, Ian Grigg<br />
| Article<br />
| 2011<br />
| [http://iang.org/papers/BitcoinBreachesGreshamsLaw.pdf Download]<br />
|-<br />
| Today Techies, Tomorrow the World? Bitcoin.<br />
| Reuben Grinberg<br />
| Article<br />
| 2012<br />
| [http://www.milkeninstitute.org/publications/review/2012_1/22-31MR53.pdf Download]<br />
|-<br />
| Traveling the Silk Road: A measurement analysis of a large anonymous online marketplace<br />
| Nicolas Christin<br />
| Research paper<br />
| 2012<br />
| [http://www.cylab.cmu.edu/files/pdfs/tech_reports/CMUCyLab12018.pdf Download]<br />
|-<br />
| CommitCoin: Carbon Dating Commitments with Bitcoin<br />
| Jeremy Clark and Aleksander Essex<br />
| Research paper<br />
| 2012<br />
| [http://people.scs.carleton.ca/~clark/papers/2012_fc.pdf Download extended abstract]&lt;br /&gt;[http://eprint.iacr.org/2011/677.pdf Download technical report]<br />
|-<br />
| Quantitative Analysis of the Full Bitcoin Transaction Graph<br />
| Dorit Ron and Adi Shamir<br />
| Research paper<br />
| 2012<br />
| [http://eprint.iacr.org/2012/584.pdf Download]<br />
|-<br />
| Design and security analysis of Bitcoin infrastructure using application deployed on Google Apps Engine<br />
| Piotr &quot;ThePiachu&quot; Piasecki<br />
| Master's thesis<br />
| 2012<br />
| [https://dl.dropbox.com/u/3658181/PiotrPiasecki-BitcoinMasterThesis.pdf Download], [https://bitcointalk.org/index.php?topic=88149.0 discussion]<br />
|-<br />
| The Production of Freedom: Value Production in the US- dominated Financial System, and Possible Alternatives<br />
| Jeremy Kirshbaum<br />
| Master's thesis (preliminary)<br />
| 2012<br />
| [https://docs.google.com/document/d/1JIyMWIibqH8x20vGBTMBZ2yqM7Xbp54UpWBh0o2H7WI/edit?pli=1 Download], [https://bitcointalk.org/index.php?topic=87404.0 discussion]<br />
|-<br />
| COIN: a distributed accounting system for peer to peer networks<br />
| Fabio Varesano<br />
| Bachelor's thesis<br />
| 2012<br />
| [http://www.varesano.net/contents/projects/coin%20distributed%20accounting%20system%20peer%20peer%20networks Download]<br />
|-<br />
| BITCOIN CLIENTS<br />
| Rostislav Skudnov<br />
| Bachelor's thesis<br />
| 2012<br />
| [http://publications.theseus.fi/bitstream/handle/10024/47166/Skudnov_Rostislav.pdf?sequence=1 Download]<br />
|-<br />
| Bitter to Better—How to Make Bitcoin a Better Currency<br />
| Simon Barber, Xavier Boyen, Elaine Shi, Ersin Uzun<br />
| Research paper<br />
| 2012<br />
| [http://crypto.stanford.edu/~xb/fc12/bitcoin.pdf Download]<br />
|-<br />
| NooShare: A decentralized ledger of shared computational resources<br />
| Alex Coventry<br />
| Research paper<br />
| 2012<br />
| [http://mit.edu/alex_c/www/nooshare.pdf Download]<br />
|-<br />
| Bits and Bets. Information, Price Volatility, and Demand for Bitcoin<br />
| Martis Buchholz, Jess Delaney, Joseph Warren<br />
| Final project<br />
| 2012<br />
| [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]<br />
|-<br />
| Two Bitcoins at the Price of One? Double Spending attacks on Fast Payments in Bitcoin<br />
| Ghassan O. Karame, Elli Androulaki, Srdjan Cap-kun <br />
| Research paper<br />
| 2012<br />
| [http://eprint.iacr.org/2012/248 Download]<br />
|-<br />
| Nerdy Money: Bitcoin, the Private Digital Currency, and the Case Against Its Regulation<br />
| Nikolei M. Kaplanov<br />
| Research paper<br />
| 2012<br />
| [http://papers.ssrn.com/sol3/papers.cfm?abstract_id=2115203 Abstract]<br />
|-<br />
| Analysis of hashrate-based double-spending<br />
| Meni Rosenfeld<br />
| Research paper<br />
| 2012<br />
| [https://bitcoil.co.il/Doublespend.pdf Download]<br />
|-<br />
| Homomorphic Payment Addresses and the Pay-to-Contract Protocol<br />
| Ilja Gerhardt, Timo Hanke<br />
| Research Paper<br />
| 2012<br />
| [http://arxiv.org/pdf/1212.3257v1 Download] ([http://docs.google.com/viewer?url=http%3A%2F%2Farxiv.org%2Fpdf%2F1212.325qq7v1 via web viewer])<br />
|-<br />
| Quasi-Commodity Money (February 6, 2012). &quot;This paper considers reform possibilities posed by a type of base money that has heretofore been overlooked in the literature on monetary economics.&quot;<br />
| George Selgin<br />
| Working Papers Series<br />
| 2012<br />
| [http://ssrn.com/abstract=2000118 Download]<br />
|-<br />
| Virtual currency schemes - &quot;This report is a first attempt to provide the basis for a discussion on virtual currency schemes.&quot;<br />
| European Central Bank<br />
| Paper<br />
| 2012<br />
| [http://www.ecb.europa.eu/pub/pdf/other/virtualcurrencyschemes201210en.pdf Download]<br />
|-<br />
| Evaluating User Privacy in Bitcoin<br />
| Elli Androulaki, Ghassan Karame, Marc Roeschlin, Tobias Scherer and Srdjan Capkun <br />
| Paper<br />
| 2013<br />
| [http://fc13.ifca.ai/proc/1-3.pdf Download] ([http://fc13.ifca.ai/slide/1-3.pdf Slides]) <br />
|-<br />
| Beware the Middleman: Empirical Analysis of Bitcoin-Exchange Risk<br />
| Tyler Moore and Nicolas Christin <br />
| Short Paper<br />
| 2013<br />
| [http://fc13.ifca.ai/proc/1-2.pdf Download] ([http://fc13.ifca.ai/slide/1-2.pdf Slides]) <br />
|-<br />
| Bitcoin, Regulating Fraud In The E-Conomy Of Hacker-Cash<br />
| Derek A. Dion<br />
| Paper<br />
| 2013<br />
| [http://illinoisjltp.com/journal/wp-content/uploads/2013/05/Dion.pdf Download]<br />
|-<br />
| The practical materiality of Bitcoin<br />
| Bill Maurera, Taylor C. Nelmsa &amp; Lana Swartz <br />
| Paper<br />
| 2013<br />
| [http://www.tandfonline.com/doi/full/10.1080/10350330.2013.777594#.UbbTVaD_6b4 Download]<br />
|-<br />
| Regulating Digital Currencies: Bringing Bitcoin within the Reach of the IMF<br />
| Nicholas Plassaras <br />
| Paper<br />
| 2013<br />
| [https://papers.ssrn.com/sol3/papers.cfm?abstract_id=2248419 Download]<br />
|-<br />
| Bitcoin is Memory<br />
| William J. Luther, Josiah Olson <br />
| Paper<br />
| 2013<br />
| [http://papers.ssrn.com/sol3/papers.cfm?abstract_id=2275730 Download]<br />
|-<br />
| The Economics of Bitcoin Mining or, Bitcoin in the Presence of Adversaries<br />
| Joshua A. Kroll, Ian C. Davey, and Edward W. Felten <br />
| Paper<br />
| 2013<br />
| [http://www.weis2013.econinfosec.org/papers/KrollDaveyFeltenWEIS2013.pdf Download]<br />
|-<br />
| Bitcoin: A Primer for Policymakers<br />
| Jerry Brito, Andrea Castillo<br />
| Research paper<br />
| 2013<br />
| [http://mercatus.org/publication/bitcoin-primer-policymakers Abstract] [http://mercatus.org/sites/default/files/Brito_BitcoinPrimer.pdf Download]<br />
|-<br />
| Whack-a-Mole: Prosecuting Digital Currency Exchanges<br />
| Catherine Martin Christopher <br />
| Research paper<br />
| 2013<br />
| [http://papers.ssrn.com/sol3/papers.cfm?abstract_id=2312787 Abstract]<br />
[http://papers.ssrn.com/sol3/Delivery.cfm/SSRN_ID2312787_code1372021.pdf?abstractid=2312787&amp;mirid=2 Download]<br />
|-<br />
| Are Cryptocurrencies 'Super' Tax Havens?<br />
| Omri Y. Marian<br />
| Research paper<br />
| 2013<br />
| [http://papers.ssrn.com/sol3/papers.cfm?abstract_id=2305863 Abstract]<br />
[http://papers.ssrn.com/sol3/Delivery.cfm/SSRN_ID2316499_code592645.pdf?abstractid=2305863&amp;mirid=1 Download]<br />
|-<br />
| Collective Emergent Institutional Entrepreneurship Through Bitcoin<br />
| Robin Teigland, Zeynep Yetis and Tomas Olov Larsson <br />
| Research paper<br />
| 2013<br />
| [http://papers.ssrn.com/sol3/papers.cfm?abstract_id=2263707 Abstract]<br />
[http://papers.ssrn.com/sol3/Delivery.cfm/SSRN_ID2263707_code2053543.pdf?abstractid=2263707&amp;mirid=1 Download]<br />
|-<br />
| Anonymity of Bitcoin Transactions<br />
| Malte Möser<br />
| Research paper<br />
| 2013<br />
| [https://www.wi.uni-muenster.de/sites/default/files/public/department/itsecurity/mbc13/mbc13-moeser-paper.pdf Download]<br />
|-<br />
| On the origins of Bitcoin: Stages of monetary evolution<br />
| Konrad S. Graf <br />
| Research paper<br />
| 2013<br />
| [http://konradsgraf.com/blog1/2013/10/23/on-the-origins-of-bitcoin-my-new-work-on-bitcoin-and-monetar.html Abstract]<br />
[http://konradsgraf.com/storage/On%20the%20Origins%20of%20Bitcoin%20Graf%2023.10.13.pdf Download]<br />
|-<br />
| Majority is not Enough: Bitcoin Mining is Vulnerable<br />
| Ittay Eyal and Emin Gun Sirer<br />
| Research paper<br />
| 2013<br />
| [http://arxiv.org/abs/1311.0243 Abstract]<br />
[http://arxiv.org/pdf/1311.0243v1 Download]<br />
|-<br />
| Bitcoin, the end of the Taboo on Money<br />
| Denis Roio aka Jaromil<br />
| Humanities article<br />
| 2013<br />
| [http://www.dyndy.net/2013/04/bitcoin-ends-the-taboo-on-money/ Abstract]<br />
[https://files.dyne.org/readers/Bitcoin_end_of_taboo_on_money.pdf Download]<br />
|-<br />
| Secure Multiparty Computations on BitCoin<br />
| Marcin Andrychowicz, Stefan Dziembowski, Daniel Malinowski and Łukasz Mazurek University of Warsaw <br />
| Research paper<br />
| 2013<br />
| [http://eprint.iacr.org/2013/784 Abstract]<br />
[http://eprint.iacr.org/eprint-bin/cite.pl?entry=2013/784 BibTeX]<br />
[http://eprint.iacr.org/2013/784.pdf Download]<br />
|-<br />
| A Fistful of Bitcoins: Characterizing Payments Among Men with No Names<br />
| Sarah Meiklejohn, Marjori Pomarole, Grant Jordan, Kirill Levchenko, Damon McCoy, Geoffrey M. Voelker, Stefan Savage<br />
| Research paper<br />
| 2013<br />
| <br />
[http://www.cs.gmu.edu/~mccoy/papers/imc13.pdf Download]<br />
|-<br />
| Information Propagation in the Bitcoin Network<br />
| Christian Decker (ETH Zurich, Switzerland), Roger Wattenhofer (Microsoft Research)<br />
| Research paper<br />
| 2013<br />
| <br />
[http://www.tik.ee.ethz.ch/file/49318d3f56c1d525aabf7fda78b23fc0/P2P2013_041.pdf Download]<br />
|-<br />
| Have a Snack, Pay with Bitcoins<br />
| Tobias Bamert, Christian Decker, Lennart Elsen, Roger Wattenhofer, Samuel Welten<br />
| Research paper<br />
| 2013<br />
| <br />
[http://www.tik.ee.ethz.ch/file/848064fa2e80f88a57aef43d7d5956c6/P2P2013_093.pdf Download]<br />
|-<br />
| The Economics of Private Digital Currency<br />
| Gerald P Dwyer<br />
| Research paper<br />
| 2014<br />
| [http://mpra.ub.uni-muenchen.de/55824/ Abstract]<br />
[http://mpra.ub.uni-muenchen.de/55824/1/MPRA_paper_55824.pdf Download]<br />
|-<br />
| The Origin, Classification and Utility of Bitcoin<br />
| Peter Šurda <br />
| Research Paper<br />
| 2014<br />
| [http://papers.ssrn.com/sol3/papers.cfm?abstract_id=2436823 Abstract]<br />
|-<br />
| Deanonymisation of clients in Bitcoin P2P network<br />
| Alex Biryukov, Dmitry Khovratovich and Ivan Pustogarov<br />
| Research Paper<br />
| 2014<br />
| [http://arxiv.org/abs/1405.7418 Abstract] [http://arxiv.org/pdf/1405.7418v2.pdf Download]<br />
|-<br />
| Bitcoin Financial Regulation: Securities, Derivatives, Prediction Markets, &amp; Gambling<br />
| Jerry Brito, Houman B. Shadab, Andrea Castillo<br />
| Research Paper<br />
| 2014<br />
| [http://papers.ssrn.com/sol3/papers.cfm?abstract_id=2423461 Abstract] [http://papers.ssrn.com/sol3/Delivery.cfm/SSRN_ID2426195_code510873.pdf?abstractid=2423461&amp;mirid=1 Download]<br />
|-<br />
| What are the main drivers of the Bitcoin price?<br />
| Ladislav Kristoufek<br />
| Research Paper<br />
| 2014<br />
| [http://arxiv.org/pdf/1406.0268v1.pdf Download]<br />
|-<br />
| The Economics of Bitcoin<br />
| Andre Herman<br />
| Bachelor's thesis<br />
| 2014<br />
| [http://www.scribd.com/doc/231964435/The-Economics-of-Bitcoin Download]<br />
|-<br />
| Near Zero Bitcoin Transaction Fees Cannot Last Forever<br />
| Kerem Kaşkaloğlu<br />
| Research Paper<br />
| 2014<br />
| [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]<br />
|-<br />
| Is Bitcoin Money?<br />
| Ísak Andri Ólafsson<br />
| Thesis Paper<br />
| 2014<br />
| [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]<br />
|-<br />
| The (A)Political Economy of Bitcoin<br />
| Vasilis Kostakis and Chris Giotitsas<br />
| Essay<br />
| 2014<br />
| [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]<br />
|-<br />
| When your sensor earns money: exchanging data for cash with Bitcoin<br />
| Dominic Wörner and Thomas von Bomhard<br />
| Research<br />
| 2014<br />
| [http://dl.acm.org/citation.cfm?id=2638786 Abstract] [http://dl.acm.org/ft_gateway.cfm?id=2638786&amp;ftid=1500778&amp;dwn=1&amp;CFID=579517323&amp;CFTOKEN=37552107 Download]<br />
|-<br />
| Bitcoin Transaction Malleability and MtGox <br />
| Christian Decker, Roger Wattenhofer<br />
| Research<br />
| 2014<br />
| [http://www.tik.ee.ethz.ch/file/7e4a7f3f2991784786037285f4876f5c/malleability.pdf Download]<br />
|-<br />
| BlueWallet: The Secure Bitcoin Wallet<br />
| Tobias Bamert, Christian Decker, Roger Wattenhofer and Samuel Welten<br />
| Research<br />
| 2014<br />
| [http://www.tik.ee.ethz.ch/file/0c347a9a3803cb937d360cba511e5019/stm2014_submission_12.pdf Download]<br />
|-<br />
| Bitcoin over Tor isn’t a good idea<br />
| Alex Biryukov and Ivan Pustogarov<br />
| Research<br />
| 2014<br />
| [http://arxiv.org/pdf/1410.6079v1.pdf Download]<br />
|-<br />
| Sidechained Bitcoin Substitutes, A Monetary Commentary<br />
| Konrad S. Graf<br />
| Essay<br />
| 2014<br />
| [http://konradsgraf.squarespace.com/storage/Monetary%20analsyis%20of%20sidecoins%20KG%2024Oct2014.pdf Download]<br />
|-<br />
| Taxation of virtual currency<br />
| Aleksandra Bal<br />
| PhD thesis<br />
| 2014<br />
| [http://hdl.handle.net/1887/29963 Abstract] [https://openaccess.leidenuniv.nl/bitstream/handle/1887/29963/000-5-Bal-14-10-2014.pdf Download]<br />
|-<br />
| A First Look at the Usability of Bitcoin Key Management<br />
| Shayan Eskandari, David Barrera, Elizabeth Stobert, and Jeremy Clark<br />
| Research Paper<br />
| 2015<br />
| [http://www.internetsociety.org/sites/default/files/05_3_3.pdf Download]<br />
|-<br />
| Value Creation in Cryptocurrency Networks: Towards A Taxonomy of Digital Business Models for Bitcoin Companies<br />
| Erol Kazan, Chee-Wee Tan, Eric T.K. Lim<br />
| Research Paper<br />
| 2015<br />
| [http://aisel.aisnet.org/pacis2015/34/ Abstract] [http://aisel.aisnet.org/cgi/viewcontent.cgi?article=1222&amp;context=pacis2015 Download]<br />
|-<br />
| Authenticated Key Exchange over Bitcoin<br />
| Patrick McCorry, Siamak F. Shahandashti, Dylan Clarke, Feng Hao<br />
| Research Paper<br />
| 2015<br />
| [http://eprint.iacr.org/2015/308.pdf Download]<br />
|-<br />
| Bitcoin and Beyond: A Technical Survey on Decentralized Digital Currencies<br />
| Florian Tschorsch and Björn Scheuermann<br />
| Research Paper<br />
| 2015<br />
| [http://eprint.iacr.org/2015/464.pdf Download]<br />
|-<br />
| Bitcoin Duplex Micropayment Channels<br />
| Christian Decker and Roger Wattenhofer<br />
| Research Paper<br />
| 2015<br />
| [http://www.tik.ee.ethz.ch/file/716b955c130e6c703fac336ea17b1670/duplex-micropayment-channels.pdf Download]<br />
|-<br />
| The Bitcoin Lightning Network: Scalable Off-Chain Instant Payments<br />
| Joseph Poon and Thaddeus Dryja<br />
| Research Paper<br />
| 2015<br />
| [http://lightning.network/lightning-network-paper.pdf Download]<br />
|-<br />
| Bitcoin and the Uniform Commercial Code<br />
| Jeanne L. Schroeder<br />
| Research Paper<br />
| 2015<br />
| [http://papers.ssrn.com/sol3/papers.cfm?abstract_id=2649441 Abstract][http://papers.ssrn.com/sol3/Delivery.cfm/SSRN_ID2649441_code1717611.pdf?abstractid=2649441&amp;mirid=1 Download]<br />
|}<br />
<br />
==See Also==<br />
<br />
* [http://encryptopedia.com/ Encryptopedia - Scientific research and white papers on bitcoin, blockchain technology, cryptography, algorithms and cryptocurrencies]<br />
* [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&amp;pli=1&amp;sle=true Full List])<br />
* [http://www.opencryptocurrencyreview.com/ OpenCryptocurrencyReview - A repository of Bitcoin and related research]<br />
* [http://people.scs.carleton.ca/~clark/biblio.html Jeremy Clark's Bitcoin Bibliography]<br />
* [[:Category:Economics|Economic]]<br />
* [[:Category:Technical|Technical]]<br />
* [[Press]]<br />
<br />
[[Category:Research]]</div>Sgornickhttps://en.bitcoin.it/w/index.php?title=Research&diff=58806Research2015-09-15T03:17:25Z<p>Sgornick: Add entry for The Bitcoin Lightning Network by Joseph Poon and Thaddeus Dryja.</p>
<hr />
<div>Publications including research and analysis of Bitcoin or related areas.<br />
<br />
{| class=&quot;wikitable sortable&quot;<br />
! Title<br />
! Author<br />
! width=150 | Type<br />
! width=75 | Date<br />
! Links<br />
|-<br />
| Cyberlaundering: Anonymous Digital Cash and Money Laundering<br />
| R. Mark Bortner<br />
| Research paper<br />
| 1996<br />
| [http://osaka.law.miami.edu/~froomkin/seminar/papers/bortner.htm Download]<br />
|-<br />
| Triple Entry Accounting<br />
| Ian Grigg<br />
| Research paper<br />
| 2005-12-25<br />
| [http://iang.org/papers/triple_entry.html Download]<br />
|-<br />
| [[Bitcoin_whitepaper|Bitcoin: A Peer-to-Peer Electronic Cash System]]<br />
| [[Satoshi Nakamoto]]<br />
| Research paper<br />
| 2008-10-31<br />
| [http://bitcoin.org/bitcoin.pdf Download]<br />
|-<br />
| An Analysis of Anonymity in the Bitcoin System<br />
| Fergal Reid, Martin Harrigan<br />
| Research paper<br />
| 2011-07-22<br />
| [http://arxiv.org/abs/1107.4524 Download], [http://bitcointalk.org/index.php?topic=31539.0 discussion]<br />
|-<br />
| Shadowy Figures: Tracking Illicit Financial Transactions in the Murky World of Digital Currencies, Peer–to–Peer Networks, and Mobile Device Payments<br />
| John Villasenor, Cody Monk, Christopher Bronk<br />
| Research paper<br />
| 2011-08-29<br />
| [http://www.bakerinstitute.org/publications/ITP-pub-FinancialTransactions-082911.pdf Download]<br />
|-<br />
| Bitcoin: An Innovative Alternative Digital Currency<br />
| Reuben Grinberg<br />
| Research paper<br />
| 2011-12-09<br />
| [http://papers.ssrn.com/sol3/papers.cfm?abstract_id=1817857 Download], [http://www.bitcointalk.org/index.php?topic=6247.0 discussion]<br />
|-<br />
| Bitcoin NFC<br />
| David Allen Bronleewe<br />
| Master's report<br />
| 2011-08<br />
| [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]<br />
|-<br />
| Optimal pool abuse strategy<br />
| Raulo<br />
| Research paper<br />
| 2011-02-04<br />
| [http://bitcoin.atspace.com/poolcheating.pdf Download], [http://www.bitcointalk.org/index.php?topic=3165.0 discussion]<br />
|-<br />
| Abusing Bitcoin cooperative mining pools: strategies for egoistical but honest miners<br />
| Nakamoto Ryo<br />
| Research paper<br />
| 2011<br />
| [http://www.bitcoinservice.co.uk/files/111 Download], [http://www.bitcointalk.org/index.php?topic=2941.0 discussion]<br />
|-<br />
| Analysis of Bitcoin Pooled Mining Reward Systems<br />
| Meni Rosenfeld<br />
| Research paper<br />
| 2011-11-07<br />
| [https://bitcoil.co.il/pool_analysis.pdf Download], [http://bitcointalk.org/index.php?topic=32814.0 discussion]<br />
|-<br />
| Bitcoin Exchange system<br />
| Tomáš Jiříček<br />
| Research paper<br />
| 2012<br />
| [https://dip.felk.cvut.cz/browse/pdfcache/jiricto2_2012bach.pdf Download]<br />
|-<br />
| On Bitcoin and Red Balloons<br />
| Moshe Babaioff, Shahar Dobzinski, Sigal Oren, Aviv Zohar<br />
| Publication article<br />
| 2012<br />
| [http://research.microsoft.com/pubs/156072/bitcoin.pdf Download]<br />
|-<br />
| 2011 Observations on the Digital Currency Industry<br />
| Mark Herpel<br />
| Publication article<br />
| 2011<br />
| [http://papers.ssrn.com/sol3/papers.cfm?abstract_id=1721076 Download]<br />
|-<br />
| MAVE, New Lightweight Digital Signature Protocols for Massive Verifications<br />
| Sergio Demian Lerner<br />
| Research paper (preliminary)<br />
| 2012<br />
| [http://bitslog.files.wordpress.com/2012/04/mave1.pdf Download]<br />
|-<br />
| MAVEPAY, a New Lightweight Payment Scheme for Peer to Peer Currency Networks<br />
| Sergio Demian Lerner<br />
| Research paper (preliminary)<br />
| 2012<br />
| [http://bitslog.files.wordpress.com/2012/04/mavepay1.pdf Download]<br />
|-<br />
| Bitcoin: Eine erste Einordnung (an initial classification)<br />
| Christoph Sorge, Artus Krohn-Grimberghe<br />
| Research paper<br />
| 2012<br />
| [http://www.springerlink.com/content/cw1v762571tr4462/ Download], [http://bitcointalk.org/index.php?topic=90233.0 discussion]<br />
|-<br />
| Bitcoin - an introduction to the workings and a preliminary analysis and understanding of potential legal issues<br />
| Jean-Daniel Schmid, Alexander Schmid<br />
| Article<br />
| 2012<br />
| [http://ef-r.ch/images/publications/1338882576_Bitcoin.pdf Download]<br />
|-<br />
| Secure multiparty Bitcoin anonymization<br />
| Edward Z. Yang<br />
| Article<br />
| 2012<br />
| [http://blog.ezyang.com/2012/07/secure-multiparty-bitcoin-anonymization/ Download], [http://www.reddit.com/r/Bitcoin/comments/wvm2w/secure_multiparty_bitcoin_anonymization/ discussion]<br />
|-<br />
| Bitcoin &amp; Gresham's Law - the economic inevitability of Collapse<br />
| Philipp Güring, Ian Grigg<br />
| Article<br />
| 2011<br />
| [http://iang.org/papers/BitcoinBreachesGreshamsLaw.pdf Download]<br />
|-<br />
| Today Techies, Tomorrow the World? Bitcoin.<br />
| Reuben Grinberg<br />
| Article<br />
| 2012<br />
| [http://www.milkeninstitute.org/publications/review/2012_1/22-31MR53.pdf Download]<br />
|-<br />
| Traveling the Silk Road: A measurement analysis of a large anonymous online marketplace<br />
| Nicolas Christin<br />
| Research paper<br />
| 2012<br />
| [http://www.cylab.cmu.edu/files/pdfs/tech_reports/CMUCyLab12018.pdf Download]<br />
|-<br />
| CommitCoin: Carbon Dating Commitments with Bitcoin<br />
| Jeremy Clark and Aleksander Essex<br />
| Research paper<br />
| 2012<br />
| [http://people.scs.carleton.ca/~clark/papers/2012_fc.pdf Download extended abstract]&lt;br /&gt;[http://eprint.iacr.org/2011/677.pdf Download technical report]<br />
|-<br />
| Quantitative Analysis of the Full Bitcoin Transaction Graph<br />
| Dorit Ron and Adi Shamir<br />
| Research paper<br />
| 2012<br />
| [http://eprint.iacr.org/2012/584.pdf Download]<br />
|-<br />
| Design and security analysis of Bitcoin infrastructure using application deployed on Google Apps Engine<br />
| Piotr &quot;ThePiachu&quot; Piasecki<br />
| Master's thesis<br />
| 2012<br />
| [https://dl.dropbox.com/u/3658181/PiotrPiasecki-BitcoinMasterThesis.pdf Download], [https://bitcointalk.org/index.php?topic=88149.0 discussion]<br />
|-<br />
| The Production of Freedom: Value Production in the US- dominated Financial System, and Possible Alternatives<br />
| Jeremy Kirshbaum<br />
| Master's thesis (preliminary)<br />
| 2012<br />
| [https://docs.google.com/document/d/1JIyMWIibqH8x20vGBTMBZ2yqM7Xbp54UpWBh0o2H7WI/edit?pli=1 Download], [https://bitcointalk.org/index.php?topic=87404.0 discussion]<br />
|-<br />
| COIN: a distributed accounting system for peer to peer networks<br />
| Fabio Varesano<br />
| Bachelor's thesis<br />
| 2012<br />
| [http://www.varesano.net/contents/projects/coin%20distributed%20accounting%20system%20peer%20peer%20networks Download]<br />
|-<br />
| BITCOIN CLIENTS<br />
| Rostislav Skudnov<br />
| Bachelor's thesis<br />
| 2012<br />
| [http://publications.theseus.fi/bitstream/handle/10024/47166/Skudnov_Rostislav.pdf?sequence=1 Download]<br />
|-<br />
| Bitter to Better—How to Make Bitcoin a Better Currency<br />
| Simon Barber, Xavier Boyen, Elaine Shi, Ersin Uzun<br />
| Research paper<br />
| 2012<br />
| [http://crypto.stanford.edu/~xb/fc12/bitcoin.pdf Download]<br />
|-<br />
| NooShare: A decentralized ledger of shared computational resources<br />
| Alex Coventry<br />
| Research paper<br />
| 2012<br />
| [http://mit.edu/alex_c/www/nooshare.pdf Download]<br />
|-<br />
| Bits and Bets. Information, Price Volatility, and Demand for Bitcoin<br />
| Martis Buchholz, Jess Delaney, Joseph Warren<br />
| Final project<br />
| 2012<br />
| [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]<br />
|-<br />
| Two Bitcoins at the Price of One? Double Spending attacks on Fast Payments in Bitcoin<br />
| Ghassan O. Karame, Elli Androulaki, Srdjan Cap-kun <br />
| Research paper<br />
| 2012<br />
| [http://eprint.iacr.org/2012/248 Download]<br />
|-<br />
| Nerdy Money: Bitcoin, the Private Digital Currency, and the Case Against Its Regulation<br />
| Nikolei M. Kaplanov<br />
| Research paper<br />
| 2012<br />
| [http://papers.ssrn.com/sol3/papers.cfm?abstract_id=2115203 Abstract]<br />
|-<br />
| Analysis of hashrate-based double-spending<br />
| Meni Rosenfeld<br />
| Research paper<br />
| 2012<br />
| [https://bitcoil.co.il/Doublespend.pdf Download]<br />
|-<br />
| Homomorphic Payment Addresses and the Pay-to-Contract Protocol<br />
| Ilja Gerhardt, Timo Hanke<br />
| Research Paper<br />
| 2012<br />
| [http://arxiv.org/pdf/1212.3257v1 Download] ([http://docs.google.com/viewer?url=http%3A%2F%2Farxiv.org%2Fpdf%2F1212.325qq7v1 via web viewer])<br />
|-<br />
| Quasi-Commodity Money (February 6, 2012). &quot;This paper considers reform possibilities posed by a type of base money that has heretofore been overlooked in the literature on monetary economics.&quot;<br />
| George Selgin<br />
| Working Papers Series<br />
| 2012<br />
| [http://ssrn.com/abstract=2000118 Download]<br />
|-<br />
| Virtual currency schemes - &quot;This report is a first attempt to provide the basis for a discussion on virtual currency schemes.&quot;<br />
| European Central Bank<br />
| Paper<br />
| 2012<br />
| [http://www.ecb.europa.eu/pub/pdf/other/virtualcurrencyschemes201210en.pdf Download]<br />
|-<br />
| Evaluating User Privacy in Bitcoin<br />
| Elli Androulaki, Ghassan Karame, Marc Roeschlin, Tobias Scherer and Srdjan Capkun <br />
| Paper<br />
| 2013<br />
| [http://fc13.ifca.ai/proc/1-3.pdf Download] ([http://fc13.ifca.ai/slide/1-3.pdf Slides]) <br />
|-<br />
| Beware the Middleman: Empirical Analysis of Bitcoin-Exchange Risk<br />
| Tyler Moore and Nicolas Christin <br />
| Short Paper<br />
| 2013<br />
| [http://fc13.ifca.ai/proc/1-2.pdf Download] ([http://fc13.ifca.ai/slide/1-2.pdf Slides]) <br />
|-<br />
| Bitcoin, Regulating Fraud In The E-Conomy Of Hacker-Cash<br />
| Derek A. Dion<br />
| Paper<br />
| 2013<br />
| [http://illinoisjltp.com/journal/wp-content/uploads/2013/05/Dion.pdf Download]<br />
|-<br />
| The practical materiality of Bitcoin<br />
| Bill Maurera, Taylor C. Nelmsa &amp; Lana Swartz <br />
| Paper<br />
| 2013<br />
| [http://www.tandfonline.com/doi/full/10.1080/10350330.2013.777594#.UbbTVaD_6b4 Download]<br />
|-<br />
| Regulating Digital Currencies: Bringing Bitcoin within the Reach of the IMF<br />
| Nicholas Plassaras <br />
| Paper<br />
| 2013<br />
| [https://papers.ssrn.com/sol3/papers.cfm?abstract_id=2248419 Download]<br />
|-<br />
| Bitcoin is Memory<br />
| William J. Luther, Josiah Olson <br />
| Paper<br />
| 2013<br />
| [http://papers.ssrn.com/sol3/papers.cfm?abstract_id=2275730 Download]<br />
|-<br />
| The Economics of Bitcoin Mining or, Bitcoin in the Presence of Adversaries<br />
| Joshua A. Kroll, Ian C. Davey, and Edward W. Felten <br />
| Paper<br />
| 2013<br />
| [http://www.weis2013.econinfosec.org/papers/KrollDaveyFeltenWEIS2013.pdf Download]<br />
|-<br />
| Bitcoin: A Primer for Policymakers<br />
| Jerry Brito, Andrea Castillo<br />
| Research paper<br />
| 2013<br />
| [http://mercatus.org/publication/bitcoin-primer-policymakers Abstract] [http://mercatus.org/sites/default/files/Brito_BitcoinPrimer.pdf Download]<br />
|-<br />
| Whack-a-Mole: Prosecuting Digital Currency Exchanges<br />
| Catherine Martin Christopher <br />
| Research paper<br />
| 2013<br />
| [http://papers.ssrn.com/sol3/papers.cfm?abstract_id=2312787 Abstract]<br />
[http://papers.ssrn.com/sol3/Delivery.cfm/SSRN_ID2312787_code1372021.pdf?abstractid=2312787&amp;mirid=2 Download]<br />
|-<br />
| Are Cryptocurrencies 'Super' Tax Havens?<br />
| Omri Y. Marian<br />
| Research paper<br />
| 2013<br />
| [http://papers.ssrn.com/sol3/papers.cfm?abstract_id=2305863 Abstract]<br />
[http://papers.ssrn.com/sol3/Delivery.cfm/SSRN_ID2316499_code592645.pdf?abstractid=2305863&amp;mirid=1 Download]<br />
|-<br />
| Collective Emergent Institutional Entrepreneurship Through Bitcoin<br />
| Robin Teigland, Zeynep Yetis and Tomas Olov Larsson <br />
| Research paper<br />
| 2013<br />
| [http://papers.ssrn.com/sol3/papers.cfm?abstract_id=2263707 Abstract]<br />
[http://papers.ssrn.com/sol3/Delivery.cfm/SSRN_ID2263707_code2053543.pdf?abstractid=2263707&amp;mirid=1 Download]<br />
|-<br />
| Anonymity of Bitcoin Transactions<br />
| Malte Möser<br />
| Research paper<br />
| 2013<br />
| [https://www.wi.uni-muenster.de/sites/default/files/public/department/itsecurity/mbc13/mbc13-moeser-paper.pdf Download]<br />
|-<br />
| On the origins of Bitcoin: Stages of monetary evolution<br />
| Konrad S. Graf <br />
| Research paper<br />
| 2013<br />
| [http://konradsgraf.com/blog1/2013/10/23/on-the-origins-of-bitcoin-my-new-work-on-bitcoin-and-monetar.html Abstract]<br />
[http://konradsgraf.com/storage/On%20the%20Origins%20of%20Bitcoin%20Graf%2023.10.13.pdf Download]<br />
|-<br />
| Majority is not Enough: Bitcoin Mining is Vulnerable<br />
| Ittay Eyal and Emin Gun Sirer<br />
| Research paper<br />
| 2013<br />
| [http://arxiv.org/abs/1311.0243 Abstract]<br />
[http://arxiv.org/pdf/1311.0243v1 Download]<br />
|-<br />
| Bitcoin, the end of the Taboo on Money<br />
| Denis Roio aka Jaromil<br />
| Humanities article<br />
| 2013<br />
| [http://www.dyndy.net/2013/04/bitcoin-ends-the-taboo-on-money/ Abstract]<br />
[https://files.dyne.org/readers/Bitcoin_end_of_taboo_on_money.pdf Download]<br />
|-<br />
| Secure Multiparty Computations on BitCoin<br />
| Marcin Andrychowicz, Stefan Dziembowski, Daniel Malinowski and Łukasz Mazurek University of Warsaw <br />
| Research paper<br />
| 2013<br />
| [http://eprint.iacr.org/2013/784 Abstract]<br />
[http://eprint.iacr.org/eprint-bin/cite.pl?entry=2013/784 BibTeX]<br />
[http://eprint.iacr.org/2013/784.pdf Download]<br />
|-<br />
| A Fistful of Bitcoins: Characterizing Payments Among Men with No Names<br />
| Sarah Meiklejohn, Marjori Pomarole, Grant Jordan, Kirill Levchenko, Damon McCoy, Geoffrey M. Voelker, Stefan Savage<br />
| Research paper<br />
| 2013<br />
| <br />
[http://www.cs.gmu.edu/~mccoy/papers/imc13.pdf Download]<br />
|-<br />
| Information Propagation in the Bitcoin Network<br />
| Christian Decker (ETH Zurich, Switzerland), Roger Wattenhofer (Microsoft Research)<br />
| Research paper<br />
| 2013<br />
| <br />
[http://www.tik.ee.ethz.ch/file/49318d3f56c1d525aabf7fda78b23fc0/P2P2013_041.pdf Download]<br />
|-<br />
| Have a Snack, Pay with Bitcoins<br />
| Tobias Bamert, Christian Decker, Lennart Elsen, Roger Wattenhofer, Samuel Welten<br />
| Research paper<br />
| 2013<br />
| <br />
[http://www.tik.ee.ethz.ch/file/848064fa2e80f88a57aef43d7d5956c6/P2P2013_093.pdf Download]<br />
|-<br />
| The Economics of Private Digital Currency<br />
| Gerald P Dwyer<br />
| Research paper<br />
| 2014<br />
| [http://mpra.ub.uni-muenchen.de/55824/ Abstract]<br />
[http://mpra.ub.uni-muenchen.de/55824/1/MPRA_paper_55824.pdf Download]<br />
|-<br />
| The Origin, Classification and Utility of Bitcoin<br />
| Peter Šurda <br />
| Research Paper<br />
| 2014<br />
| [http://papers.ssrn.com/sol3/papers.cfm?abstract_id=2436823 Abstract]<br />
|-<br />
| Deanonymisation of clients in Bitcoin P2P network<br />
| Alex Biryukov, Dmitry Khovratovich and Ivan Pustogarov<br />
| Research Paper<br />
| 2014<br />
| [http://arxiv.org/abs/1405.7418 Abstract] [http://arxiv.org/pdf/1405.7418v2.pdf Download]<br />
|-<br />
| Bitcoin Financial Regulation: Securities, Derivatives, Prediction Markets, &amp; Gambling<br />
| Jerry Brito, Houman B. Shadab, Andrea Castillo<br />
| Research Paper<br />
| 2014<br />
| [http://papers.ssrn.com/sol3/papers.cfm?abstract_id=2423461 Abstract] [http://papers.ssrn.com/sol3/Delivery.cfm/SSRN_ID2426195_code510873.pdf?abstractid=2423461&amp;mirid=1 Download]<br />
|-<br />
| What are the main drivers of the Bitcoin price?<br />
| Ladislav Kristoufek<br />
| Research Paper<br />
| 2014<br />
| [http://arxiv.org/pdf/1406.0268v1.pdf Download]<br />
|-<br />
| The Economics of Bitcoin<br />
| Andre Herman<br />
| Bachelor's thesis<br />
| 2014<br />
| [http://www.scribd.com/doc/231964435/The-Economics-of-Bitcoin Download]<br />
|-<br />
| Near Zero Bitcoin Transaction Fees Cannot Last Forever<br />
| Kerem Kaşkaloğlu<br />
| Research Paper<br />
| 2014<br />
| [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]<br />
|-<br />
| Is Bitcoin Money?<br />
| Ísak Andri Ólafsson<br />
| Thesis Paper<br />
| 2014<br />
| [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]<br />
|-<br />
| The (A)Political Economy of Bitcoin<br />
| Vasilis Kostakis and Chris Giotitsas<br />
| Essay<br />
| 2014<br />
| [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]<br />
|-<br />
| When your sensor earns money: exchanging data for cash with Bitcoin<br />
| Dominic Wörner and Thomas von Bomhard<br />
| Research<br />
| 2014<br />
| [http://dl.acm.org/citation.cfm?id=2638786 Abstract] [http://dl.acm.org/ft_gateway.cfm?id=2638786&amp;ftid=1500778&amp;dwn=1&amp;CFID=579517323&amp;CFTOKEN=37552107 Download]<br />
|-<br />
| Bitcoin Transaction Malleability and MtGox <br />
| Christian Decker, Roger Wattenhofer<br />
| Research<br />
| 2014<br />
| [http://www.tik.ee.ethz.ch/file/7e4a7f3f2991784786037285f4876f5c/malleability.pdf Download]<br />
|-<br />
| BlueWallet: The Secure Bitcoin Wallet<br />
| Tobias Bamert, Christian Decker, Roger Wattenhofer and Samuel Welten<br />
| Research<br />
| 2014<br />
| [http://www.tik.ee.ethz.ch/file/0c347a9a3803cb937d360cba511e5019/stm2014_submission_12.pdf Download]<br />
|-<br />
| Bitcoin over Tor isn’t a good idea<br />
| Alex Biryukov and Ivan Pustogarov<br />
| Research<br />
| 2014<br />
| [http://arxiv.org/pdf/1410.6079v1.pdf Download]<br />
|-<br />
| Sidechained Bitcoin Substitutes, A Monetary Commentary<br />
| Konrad S. Graf<br />
| Essay<br />
| 2014<br />
| [http://konradsgraf.squarespace.com/storage/Monetary%20analsyis%20of%20sidecoins%20KG%2024Oct2014.pdf Download]<br />
|-<br />
| Taxation of virtual currency<br />
| Aleksandra Bal<br />
| PhD thesis<br />
| 2014<br />
| [http://hdl.handle.net/1887/29963 Abstract] [https://openaccess.leidenuniv.nl/bitstream/handle/1887/29963/000-5-Bal-14-10-2014.pdf Download]<br />
|-<br />
| A First Look at the Usability of Bitcoin Key Management<br />
| Shayan Eskandari, David Barrera, Elizabeth Stobert, and Jeremy Clark<br />
| Research Paper<br />
| 2015<br />
| [http://www.internetsociety.org/sites/default/files/05_3_3.pdf Download]<br />
|-<br />
| Value Creation in Cryptocurrency Networks: Towards A Taxonomy of Digital Business Models for Bitcoin Companies<br />
| Erol Kazan, Chee-Wee Tan, Eric T.K. Lim<br />
| Research Paper<br />
| 2015<br />
| [http://aisel.aisnet.org/pacis2015/34/ Abstract] [http://aisel.aisnet.org/cgi/viewcontent.cgi?article=1222&amp;context=pacis2015 Download]<br />
|-<br />
| Authenticated Key Exchange over Bitcoin<br />
| Patrick McCorry, Siamak F. Shahandashti, Dylan Clarke, Feng Hao<br />
| Research Paper<br />
| 2015<br />
| [http://eprint.iacr.org/2015/308.pdf Download]<br />
|-<br />
| Bitcoin and Beyond: A Technical Survey on Decentralized Digital Currencies<br />
| Florian Tschorsch and Björn Scheuermann<br />
| Research Paper<br />
| 2015<br />
| [http://eprint.iacr.org/2015/464.pdf Download]<br />
|-<br />
| Bitcoin Duplex Micropayment Channels<br />
| Christian Decker and Roger Wattenhofer<br />
| Research Paper<br />
| 2015<br />
| [http://www.tik.ee.ethz.ch/file/716b955c130e6c703fac336ea17b1670/duplex-micropayment-channels.pdf Download]<br />
|-<br />
| The Bitcoin Lightning Network: Scalable Off-Chain Instant Payments<br />
| Joseph Poon and Thaddeus Dryja<br />
| Research Paper<br />
| 2015<br />
| [http://lightning.network/lightning-network-paper.pdf Download]<br />
|}<br />
<br />
==See Also==<br />
<br />
* [http://encryptopedia.com/ Encryptopedia - Scientific research and white papers on bitcoin, blockchain technology, cryptography, algorithms and cryptocurrencies]<br />
* [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&amp;pli=1&amp;sle=true Full List])<br />
* [http://www.opencryptocurrencyreview.com/ OpenCryptocurrencyReview - A repository of Bitcoin and related research]<br />
* [http://people.scs.carleton.ca/~clark/biblio.html Jeremy Clark's Bitcoin Bibliography]<br />
* [[:Category:Economics|Economic]]<br />
* [[:Category:Technical|Technical]]<br />
* [[Press]]<br />
<br />
[[Category:Research]]</div>Sgornickhttps://en.bitcoin.it/w/index.php?title=Research&diff=58805Research2015-09-15T03:15:43Z<p>Sgornick: Add entry for Bitcoin Duplex Micropayment Channels by Christian Decker and Roger Wattenhofer</p>
<hr />
<div>Publications including research and analysis of Bitcoin or related areas.<br />
<br />
{| class=&quot;wikitable sortable&quot;<br />
! Title<br />
! Author<br />
! width=150 | Type<br />
! width=75 | Date<br />
! Links<br />
|-<br />
| Cyberlaundering: Anonymous Digital Cash and Money Laundering<br />
| R. Mark Bortner<br />
| Research paper<br />
| 1996<br />
| [http://osaka.law.miami.edu/~froomkin/seminar/papers/bortner.htm Download]<br />
|-<br />
| Triple Entry Accounting<br />
| Ian Grigg<br />
| Research paper<br />
| 2005-12-25<br />
| [http://iang.org/papers/triple_entry.html Download]<br />
|-<br />
| [[Bitcoin_whitepaper|Bitcoin: A Peer-to-Peer Electronic Cash System]]<br />
| [[Satoshi Nakamoto]]<br />
| Research paper<br />
| 2008-10-31<br />
| [http://bitcoin.org/bitcoin.pdf Download]<br />
|-<br />
| An Analysis of Anonymity in the Bitcoin System<br />
| Fergal Reid, Martin Harrigan<br />
| Research paper<br />
| 2011-07-22<br />
| [http://arxiv.org/abs/1107.4524 Download], [http://bitcointalk.org/index.php?topic=31539.0 discussion]<br />
|-<br />
| Shadowy Figures: Tracking Illicit Financial Transactions in the Murky World of Digital Currencies, Peer–to–Peer Networks, and Mobile Device Payments<br />
| John Villasenor, Cody Monk, Christopher Bronk<br />
| Research paper<br />
| 2011-08-29<br />
| [http://www.bakerinstitute.org/publications/ITP-pub-FinancialTransactions-082911.pdf Download]<br />
|-<br />
| Bitcoin: An Innovative Alternative Digital Currency<br />
| Reuben Grinberg<br />
| Research paper<br />
| 2011-12-09<br />
| [http://papers.ssrn.com/sol3/papers.cfm?abstract_id=1817857 Download], [http://www.bitcointalk.org/index.php?topic=6247.0 discussion]<br />
|-<br />
| Bitcoin NFC<br />
| David Allen Bronleewe<br />
| Master's report<br />
| 2011-08<br />
| [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]<br />
|-<br />
| Optimal pool abuse strategy<br />
| Raulo<br />
| Research paper<br />
| 2011-02-04<br />
| [http://bitcoin.atspace.com/poolcheating.pdf Download], [http://www.bitcointalk.org/index.php?topic=3165.0 discussion]<br />
|-<br />
| Abusing Bitcoin cooperative mining pools: strategies for egoistical but honest miners<br />
| Nakamoto Ryo<br />
| Research paper<br />
| 2011<br />
| [http://www.bitcoinservice.co.uk/files/111 Download], [http://www.bitcointalk.org/index.php?topic=2941.0 discussion]<br />
|-<br />
| Analysis of Bitcoin Pooled Mining Reward Systems<br />
| Meni Rosenfeld<br />
| Research paper<br />
| 2011-11-07<br />
| [https://bitcoil.co.il/pool_analysis.pdf Download], [http://bitcointalk.org/index.php?topic=32814.0 discussion]<br />
|-<br />
| Bitcoin Exchange system<br />
| Tomáš Jiříček<br />
| Research paper<br />
| 2012<br />
| [https://dip.felk.cvut.cz/browse/pdfcache/jiricto2_2012bach.pdf Download]<br />
|-<br />
| On Bitcoin and Red Balloons<br />
| Moshe Babaioff, Shahar Dobzinski, Sigal Oren, Aviv Zohar<br />
| Publication article<br />
| 2012<br />
| [http://research.microsoft.com/pubs/156072/bitcoin.pdf Download]<br />
|-<br />
| 2011 Observations on the Digital Currency Industry<br />
| Mark Herpel<br />
| Publication article<br />
| 2011<br />
| [http://papers.ssrn.com/sol3/papers.cfm?abstract_id=1721076 Download]<br />
|-<br />
| MAVE, New Lightweight Digital Signature Protocols for Massive Verifications<br />
| Sergio Demian Lerner<br />
| Research paper (preliminary)<br />
| 2012<br />
| [http://bitslog.files.wordpress.com/2012/04/mave1.pdf Download]<br />
|-<br />
| MAVEPAY, a New Lightweight Payment Scheme for Peer to Peer Currency Networks<br />
| Sergio Demian Lerner<br />
| Research paper (preliminary)<br />
| 2012<br />
| [http://bitslog.files.wordpress.com/2012/04/mavepay1.pdf Download]<br />
|-<br />
| Bitcoin: Eine erste Einordnung (an initial classification)<br />
| Christoph Sorge, Artus Krohn-Grimberghe<br />
| Research paper<br />
| 2012<br />
| [http://www.springerlink.com/content/cw1v762571tr4462/ Download], [http://bitcointalk.org/index.php?topic=90233.0 discussion]<br />
|-<br />
| Bitcoin - an introduction to the workings and a preliminary analysis and understanding of potential legal issues<br />
| Jean-Daniel Schmid, Alexander Schmid<br />
| Article<br />
| 2012<br />
| [http://ef-r.ch/images/publications/1338882576_Bitcoin.pdf Download]<br />
|-<br />
| Secure multiparty Bitcoin anonymization<br />
| Edward Z. Yang<br />
| Article<br />
| 2012<br />
| [http://blog.ezyang.com/2012/07/secure-multiparty-bitcoin-anonymization/ Download], [http://www.reddit.com/r/Bitcoin/comments/wvm2w/secure_multiparty_bitcoin_anonymization/ discussion]<br />
|-<br />
| Bitcoin &amp; Gresham's Law - the economic inevitability of Collapse<br />
| Philipp Güring, Ian Grigg<br />
| Article<br />
| 2011<br />
| [http://iang.org/papers/BitcoinBreachesGreshamsLaw.pdf Download]<br />
|-<br />
| Today Techies, Tomorrow the World? Bitcoin.<br />
| Reuben Grinberg<br />
| Article<br />
| 2012<br />
| [http://www.milkeninstitute.org/publications/review/2012_1/22-31MR53.pdf Download]<br />
|-<br />
| Traveling the Silk Road: A measurement analysis of a large anonymous online marketplace<br />
| Nicolas Christin<br />
| Research paper<br />
| 2012<br />
| [http://www.cylab.cmu.edu/files/pdfs/tech_reports/CMUCyLab12018.pdf Download]<br />
|-<br />
| CommitCoin: Carbon Dating Commitments with Bitcoin<br />
| Jeremy Clark and Aleksander Essex<br />
| Research paper<br />
| 2012<br />
| [http://people.scs.carleton.ca/~clark/papers/2012_fc.pdf Download extended abstract]&lt;br /&gt;[http://eprint.iacr.org/2011/677.pdf Download technical report]<br />
|-<br />
| Quantitative Analysis of the Full Bitcoin Transaction Graph<br />
| Dorit Ron and Adi Shamir<br />
| Research paper<br />
| 2012<br />
| [http://eprint.iacr.org/2012/584.pdf Download]<br />
|-<br />
| Design and security analysis of Bitcoin infrastructure using application deployed on Google Apps Engine<br />
| Piotr &quot;ThePiachu&quot; Piasecki<br />
| Master's thesis<br />
| 2012<br />
| [https://dl.dropbox.com/u/3658181/PiotrPiasecki-BitcoinMasterThesis.pdf Download], [https://bitcointalk.org/index.php?topic=88149.0 discussion]<br />
|-<br />
| The Production of Freedom: Value Production in the US- dominated Financial System, and Possible Alternatives<br />
| Jeremy Kirshbaum<br />
| Master's thesis (preliminary)<br />
| 2012<br />
| [https://docs.google.com/document/d/1JIyMWIibqH8x20vGBTMBZ2yqM7Xbp54UpWBh0o2H7WI/edit?pli=1 Download], [https://bitcointalk.org/index.php?topic=87404.0 discussion]<br />
|-<br />
| COIN: a distributed accounting system for peer to peer networks<br />
| Fabio Varesano<br />
| Bachelor's thesis<br />
| 2012<br />
| [http://www.varesano.net/contents/projects/coin%20distributed%20accounting%20system%20peer%20peer%20networks Download]<br />
|-<br />
| BITCOIN CLIENTS<br />
| Rostislav Skudnov<br />
| Bachelor's thesis<br />
| 2012<br />
| [http://publications.theseus.fi/bitstream/handle/10024/47166/Skudnov_Rostislav.pdf?sequence=1 Download]<br />
|-<br />
| Bitter to Better—How to Make Bitcoin a Better Currency<br />
| Simon Barber, Xavier Boyen, Elaine Shi, Ersin Uzun<br />
| Research paper<br />
| 2012<br />
| [http://crypto.stanford.edu/~xb/fc12/bitcoin.pdf Download]<br />
|-<br />
| NooShare: A decentralized ledger of shared computational resources<br />
| Alex Coventry<br />
| Research paper<br />
| 2012<br />
| [http://mit.edu/alex_c/www/nooshare.pdf Download]<br />
|-<br />
| Bits and Bets. Information, Price Volatility, and Demand for Bitcoin<br />
| Martis Buchholz, Jess Delaney, Joseph Warren<br />
| Final project<br />
| 2012<br />
| [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]<br />
|-<br />
| Two Bitcoins at the Price of One? Double Spending attacks on Fast Payments in Bitcoin<br />
| Ghassan O. Karame, Elli Androulaki, Srdjan Cap-kun <br />
| Research paper<br />
| 2012<br />
| [http://eprint.iacr.org/2012/248 Download]<br />
|-<br />
| Nerdy Money: Bitcoin, the Private Digital Currency, and the Case Against Its Regulation<br />
| Nikolei M. Kaplanov<br />
| Research paper<br />
| 2012<br />
| [http://papers.ssrn.com/sol3/papers.cfm?abstract_id=2115203 Abstract]<br />
|-<br />
| Analysis of hashrate-based double-spending<br />
| Meni Rosenfeld<br />
| Research paper<br />
| 2012<br />
| [https://bitcoil.co.il/Doublespend.pdf Download]<br />
|-<br />
| Homomorphic Payment Addresses and the Pay-to-Contract Protocol<br />
| Ilja Gerhardt, Timo Hanke<br />
| Research Paper<br />
| 2012<br />
| [http://arxiv.org/pdf/1212.3257v1 Download] ([http://docs.google.com/viewer?url=http%3A%2F%2Farxiv.org%2Fpdf%2F1212.325qq7v1 via web viewer])<br />
|-<br />
| Quasi-Commodity Money (February 6, 2012). &quot;This paper considers reform possibilities posed by a type of base money that has heretofore been overlooked in the literature on monetary economics.&quot;<br />
| George Selgin<br />
| Working Papers Series<br />
| 2012<br />
| [http://ssrn.com/abstract=2000118 Download]<br />
|-<br />
| Virtual currency schemes - &quot;This report is a first attempt to provide the basis for a discussion on virtual currency schemes.&quot;<br />
| European Central Bank<br />
| Paper<br />
| 2012<br />
| [http://www.ecb.europa.eu/pub/pdf/other/virtualcurrencyschemes201210en.pdf Download]<br />
|-<br />
| Evaluating User Privacy in Bitcoin<br />
| Elli Androulaki, Ghassan Karame, Marc Roeschlin, Tobias Scherer and Srdjan Capkun <br />
| Paper<br />
| 2013<br />
| [http://fc13.ifca.ai/proc/1-3.pdf Download] ([http://fc13.ifca.ai/slide/1-3.pdf Slides]) <br />
|-<br />
| Beware the Middleman: Empirical Analysis of Bitcoin-Exchange Risk<br />
| Tyler Moore and Nicolas Christin <br />
| Short Paper<br />
| 2013<br />
| [http://fc13.ifca.ai/proc/1-2.pdf Download] ([http://fc13.ifca.ai/slide/1-2.pdf Slides]) <br />
|-<br />
| Bitcoin, Regulating Fraud In The E-Conomy Of Hacker-Cash<br />
| Derek A. Dion<br />
| Paper<br />
| 2013<br />
| [http://illinoisjltp.com/journal/wp-content/uploads/2013/05/Dion.pdf Download]<br />
|-<br />
| The practical materiality of Bitcoin<br />
| Bill Maurera, Taylor C. Nelmsa &amp; Lana Swartz <br />
| Paper<br />
| 2013<br />
| [http://www.tandfonline.com/doi/full/10.1080/10350330.2013.777594#.UbbTVaD_6b4 Download]<br />
|-<br />
| Regulating Digital Currencies: Bringing Bitcoin within the Reach of the IMF<br />
| Nicholas Plassaras <br />
| Paper<br />
| 2013<br />
| [https://papers.ssrn.com/sol3/papers.cfm?abstract_id=2248419 Download]<br />
|-<br />
| Bitcoin is Memory<br />
| William J. Luther, Josiah Olson <br />
| Paper<br />
| 2013<br />
| [http://papers.ssrn.com/sol3/papers.cfm?abstract_id=2275730 Download]<br />
|-<br />
| The Economics of Bitcoin Mining or, Bitcoin in the Presence of Adversaries<br />
| Joshua A. Kroll, Ian C. Davey, and Edward W. Felten <br />
| Paper<br />
| 2013<br />
| [http://www.weis2013.econinfosec.org/papers/KrollDaveyFeltenWEIS2013.pdf Download]<br />
|-<br />
| Bitcoin: A Primer for Policymakers<br />
| Jerry Brito, Andrea Castillo<br />
| Research paper<br />
| 2013<br />
| [http://mercatus.org/publication/bitcoin-primer-policymakers Abstract] [http://mercatus.org/sites/default/files/Brito_BitcoinPrimer.pdf Download]<br />
|-<br />
| Whack-a-Mole: Prosecuting Digital Currency Exchanges<br />
| Catherine Martin Christopher <br />
| Research paper<br />
| 2013<br />
| [http://papers.ssrn.com/sol3/papers.cfm?abstract_id=2312787 Abstract]<br />
[http://papers.ssrn.com/sol3/Delivery.cfm/SSRN_ID2312787_code1372021.pdf?abstractid=2312787&amp;mirid=2 Download]<br />
|-<br />
| Are Cryptocurrencies 'Super' Tax Havens?<br />
| Omri Y. Marian<br />
| Research paper<br />
| 2013<br />
| [http://papers.ssrn.com/sol3/papers.cfm?abstract_id=2305863 Abstract]<br />
[http://papers.ssrn.com/sol3/Delivery.cfm/SSRN_ID2316499_code592645.pdf?abstractid=2305863&amp;mirid=1 Download]<br />
|-<br />
| Collective Emergent Institutional Entrepreneurship Through Bitcoin<br />
| Robin Teigland, Zeynep Yetis and Tomas Olov Larsson <br />
| Research paper<br />
| 2013<br />
| [http://papers.ssrn.com/sol3/papers.cfm?abstract_id=2263707 Abstract]<br />
[http://papers.ssrn.com/sol3/Delivery.cfm/SSRN_ID2263707_code2053543.pdf?abstractid=2263707&amp;mirid=1 Download]<br />
|-<br />
| Anonymity of Bitcoin Transactions<br />
| Malte Möser<br />
| Research paper<br />
| 2013<br />
| [https://www.wi.uni-muenster.de/sites/default/files/public/department/itsecurity/mbc13/mbc13-moeser-paper.pdf Download]<br />
|-<br />
| On the origins of Bitcoin: Stages of monetary evolution<br />
| Konrad S. Graf <br />
| Research paper<br />
| 2013<br />
| [http://konradsgraf.com/blog1/2013/10/23/on-the-origins-of-bitcoin-my-new-work-on-bitcoin-and-monetar.html Abstract]<br />
[http://konradsgraf.com/storage/On%20the%20Origins%20of%20Bitcoin%20Graf%2023.10.13.pdf Download]<br />
|-<br />
| Majority is not Enough: Bitcoin Mining is Vulnerable<br />
| Ittay Eyal and Emin Gun Sirer<br />
| Research paper<br />
| 2013<br />
| [http://arxiv.org/abs/1311.0243 Abstract]<br />
[http://arxiv.org/pdf/1311.0243v1 Download]<br />
|-<br />
| Bitcoin, the end of the Taboo on Money<br />
| Denis Roio aka Jaromil<br />
| Humanities article<br />
| 2013<br />
| [http://www.dyndy.net/2013/04/bitcoin-ends-the-taboo-on-money/ Abstract]<br />
[https://files.dyne.org/readers/Bitcoin_end_of_taboo_on_money.pdf Download]<br />
|-<br />
| Secure Multiparty Computations on BitCoin<br />
| Marcin Andrychowicz, Stefan Dziembowski, Daniel Malinowski and Łukasz Mazurek University of Warsaw <br />
| Research paper<br />
| 2013<br />
| [http://eprint.iacr.org/2013/784 Abstract]<br />
[http://eprint.iacr.org/eprint-bin/cite.pl?entry=2013/784 BibTeX]<br />
[http://eprint.iacr.org/2013/784.pdf Download]<br />
|-<br />
| A Fistful of Bitcoins: Characterizing Payments Among Men with No Names<br />
| Sarah Meiklejohn, Marjori Pomarole, Grant Jordan, Kirill Levchenko, Damon McCoy, Geoffrey M. Voelker, Stefan Savage<br />
| Research paper<br />
| 2013<br />
| <br />
[http://www.cs.gmu.edu/~mccoy/papers/imc13.pdf Download]<br />
|-<br />
| Information Propagation in the Bitcoin Network<br />
| Christian Decker (ETH Zurich, Switzerland), Roger Wattenhofer (Microsoft Research)<br />
| Research paper<br />
| 2013<br />
| <br />
[http://www.tik.ee.ethz.ch/file/49318d3f56c1d525aabf7fda78b23fc0/P2P2013_041.pdf Download]<br />
|-<br />
| Have a Snack, Pay with Bitcoins<br />
| Tobias Bamert, Christian Decker, Lennart Elsen, Roger Wattenhofer, Samuel Welten<br />
| Research paper<br />
| 2013<br />
| <br />
[http://www.tik.ee.ethz.ch/file/848064fa2e80f88a57aef43d7d5956c6/P2P2013_093.pdf Download]<br />
|-<br />
| The Economics of Private Digital Currency<br />
| Gerald P Dwyer<br />
| Research paper<br />
| 2014<br />
| [http://mpra.ub.uni-muenchen.de/55824/ Abstract]<br />
[http://mpra.ub.uni-muenchen.de/55824/1/MPRA_paper_55824.pdf Download]<br />
|-<br />
| The Origin, Classification and Utility of Bitcoin<br />
| Peter Šurda <br />
| Research Paper<br />
| 2014<br />
| [http://papers.ssrn.com/sol3/papers.cfm?abstract_id=2436823 Abstract]<br />
|-<br />
| Deanonymisation of clients in Bitcoin P2P network<br />
| Alex Biryukov, Dmitry Khovratovich and Ivan Pustogarov<br />
| Research Paper<br />
| 2014<br />
| [http://arxiv.org/abs/1405.7418 Abstract] [http://arxiv.org/pdf/1405.7418v2.pdf Download]<br />
|-<br />
| Bitcoin Financial Regulation: Securities, Derivatives, Prediction Markets, &amp; Gambling<br />
| Jerry Brito, Houman B. Shadab, Andrea Castillo<br />
| Research Paper<br />
| 2014<br />
| [http://papers.ssrn.com/sol3/papers.cfm?abstract_id=2423461 Abstract] [http://papers.ssrn.com/sol3/Delivery.cfm/SSRN_ID2426195_code510873.pdf?abstractid=2423461&amp;mirid=1 Download]<br />
|-<br />
| What are the main drivers of the Bitcoin price?<br />
| Ladislav Kristoufek<br />
| Research Paper<br />
| 2014<br />
| [http://arxiv.org/pdf/1406.0268v1.pdf Download]<br />
|-<br />
| The Economics of Bitcoin<br />
| Andre Herman<br />
| Bachelor's thesis<br />
| 2014<br />
| [http://www.scribd.com/doc/231964435/The-Economics-of-Bitcoin Download]<br />
|-<br />
| Near Zero Bitcoin Transaction Fees Cannot Last Forever<br />
| Kerem Kaşkaloğlu<br />
| Research Paper<br />
| 2014<br />
| [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]<br />
|-<br />
| Is Bitcoin Money?<br />
| Ísak Andri Ólafsson<br />
| Thesis Paper<br />
| 2014<br />
| [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]<br />
|-<br />
| The (A)Political Economy of Bitcoin<br />
| Vasilis Kostakis and Chris Giotitsas<br />
| Essay<br />
| 2014<br />
| [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]<br />
|-<br />
| When your sensor earns money: exchanging data for cash with Bitcoin<br />
| Dominic Wörner and Thomas von Bomhard<br />
| Research<br />
| 2014<br />
| [http://dl.acm.org/citation.cfm?id=2638786 Abstract] [http://dl.acm.org/ft_gateway.cfm?id=2638786&amp;ftid=1500778&amp;dwn=1&amp;CFID=579517323&amp;CFTOKEN=37552107 Download]<br />
|-<br />
| Bitcoin Transaction Malleability and MtGox <br />
| Christian Decker, Roger Wattenhofer<br />
| Research<br />
| 2014<br />
| [http://www.tik.ee.ethz.ch/file/7e4a7f3f2991784786037285f4876f5c/malleability.pdf Download]<br />
|-<br />
| BlueWallet: The Secure Bitcoin Wallet<br />
| Tobias Bamert, Christian Decker, Roger Wattenhofer and Samuel Welten<br />
| Research<br />
| 2014<br />
| [http://www.tik.ee.ethz.ch/file/0c347a9a3803cb937d360cba511e5019/stm2014_submission_12.pdf Download]<br />
|-<br />
| Bitcoin over Tor isn’t a good idea<br />
| Alex Biryukov and Ivan Pustogarov<br />
| Research<br />
| 2014<br />
| [http://arxiv.org/pdf/1410.6079v1.pdf Download]<br />
|-<br />
| Sidechained Bitcoin Substitutes, A Monetary Commentary<br />
| Konrad S. Graf<br />
| Essay<br />
| 2014<br />
| [http://konradsgraf.squarespace.com/storage/Monetary%20analsyis%20of%20sidecoins%20KG%2024Oct2014.pdf Download]<br />
|-<br />
| Taxation of virtual currency<br />
| Aleksandra Bal<br />
| PhD thesis<br />
| 2014<br />
| [http://hdl.handle.net/1887/29963 Abstract] [https://openaccess.leidenuniv.nl/bitstream/handle/1887/29963/000-5-Bal-14-10-2014.pdf Download]<br />
|-<br />
| A First Look at the Usability of Bitcoin Key Management<br />
| Shayan Eskandari, David Barrera, Elizabeth Stobert, and Jeremy Clark<br />
| Research Paper<br />
| 2015<br />
| [http://www.internetsociety.org/sites/default/files/05_3_3.pdf Download]<br />
|-<br />
| Value Creation in Cryptocurrency Networks: Towards A Taxonomy of Digital Business Models for Bitcoin Companies<br />
| Erol Kazan, Chee-Wee Tan, Eric T.K. Lim<br />
| Research Paper<br />
| 2015<br />
| [http://aisel.aisnet.org/pacis2015/34/ Abstract] [http://aisel.aisnet.org/cgi/viewcontent.cgi?article=1222&amp;context=pacis2015 Download]<br />
|-<br />
| Authenticated Key Exchange over Bitcoin<br />
| Patrick McCorry, Siamak F. Shahandashti, Dylan Clarke, Feng Hao<br />
| Research Paper<br />
| 2015<br />
| [http://eprint.iacr.org/2015/308.pdf Download]<br />
|-<br />
| Bitcoin and Beyond: A Technical Survey on Decentralized Digital Currencies<br />
| Florian Tschorsch and Björn Scheuermann<br />
| Research Paper<br />
| 2015<br />
| [http://eprint.iacr.org/2015/464.pdf Download]<br />
|-<br />
| Bitcoin Duplex Micropayment Channels<br />
| Christian Decker and Roger Wattenhofer<br />
| Research Paper<br />
| 2015<br />
| [http://www.tik.ee.ethz.ch/file/716b955c130e6c703fac336ea17b1670/duplex-micropayment-channels.pdf Download]<br />
|}<br />
<br />
==See Also==<br />
<br />
* [http://encryptopedia.com/ Encryptopedia - Scientific research and white papers on bitcoin, blockchain technology, cryptography, algorithms and cryptocurrencies]<br />
* [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&amp;pli=1&amp;sle=true Full List])<br />
* [http://www.opencryptocurrencyreview.com/ OpenCryptocurrencyReview - A repository of Bitcoin and related research]<br />
* [http://people.scs.carleton.ca/~clark/biblio.html Jeremy Clark's Bitcoin Bibliography]<br />
* [[:Category:Economics|Economic]]<br />
* [[:Category:Technical|Technical]]<br />
* [[Press]]<br />
<br />
[[Category:Research]]</div>Sgornick