https://en.bitcoin.it/w/api.php?action=feedcontributions&feedformat=atom&user=Ripper234Bitcoin Wiki - User contributions [en]2026-04-27T04:36:43ZUser contributionsMediaWiki 1.43.8https://en.bitcoin.it/w/index.php?title=Ron_Gross&diff=67107Ron Gross2019-12-15T12:31:18Z<p>Ripper234: Replaced content with "This page has moved: http://bio.ripper234.com/ Category:People"</p>
<hr />
<div>This page has moved: http://bio.ripper234.com/<br />
<br />
[[Category:People]]</div>Ripper234https://en.bitcoin.it/w/index.php?title=Ron_Gross&diff=65090Ron Gross2018-03-16T21:48:38Z<p>Ripper234: </p>
<hr />
<div>[[image:Ron Gross.jpg]]<br />
<br />
Ron has graduated from the Technion with an M. Sc in Computer Science.<br />
He has worked at several companies, ranging from small startups to Google,<br />
and has an extensive experience in web architecture, security, and algorithms.<br />
<br />
Ron has been continuously involved with Bitcoin since March 2011,<br />
spreading the word, knowledge, and love of Bitcoin. He is a firm advocate of <br />
open source, transparency and decentralization of power and technology.<br />
Ron co-founded the Israeli Bitcoin Association and was the Executive Director of the [[Mastercoin Foundation]] (the world's first ICO).<br />
<br />
You can reach Ron at:<br />
* ron@bitcoin.org<br />
* skype - ripper234<br />
<br />
See also read [http://ripper234.com/#about the about page on his blog].<br />
<br />
[[Category:People]]</div>Ripper234https://en.bitcoin.it/w/index.php?title=Satoshi_Nakamoto&diff=64571Satoshi Nakamoto2017-12-11T05:58:45Z<p>Ripper234: Satoshi is not longer a redirect, it's a disambiguation page</p>
<hr />
<div>:''For the unit, see [[satoshi (unit)]].''<br />
'''Satoshi Nakamoto''' is the founder of [[Bitcoin]] and initial creator of the [[Original Bitcoin client]]. He has said in a P2P foundation profile<ref name="p2p_f_profile">[http://p2pfoundation.ning.com/profile/SatoshiNakamoto Satoshi Nakamoto profile on P2P Foundation]</ref> that he is from Japan. Beyond that, not much else is known about him and his identity. He has been working on the Bitcoin project since 2007.<ref>[https://bitcointalk.org/index.php?topic=13.msg46#msg46 Re: Questions about Bitcoin]</ref><br />
<br />
His involvement in the Bitcoin project had tapered and by late 2010 it has ended. The most recent messages reportedly indicate that Satoshi is "gone for good"<ref>[http://bitcoinstats.com/irc/bitcoin-dev/logs/2011/04/26#l1303826036.0 Transcript of #bitcoin-dev for 2011/04/26]</ref>.<br />
<br />
==Possible Motives==<br />
He left some clues about why he is doing this project with the inclusion of the following text in the [[Genesis block]], "The Times 03/Jan/2009 Chancellor on brink of second bailout for banks".<br />
<br />
Some interesting quotes:<br />
<blockquote><p>Yes, [we will not find a solution to political problems in cryptography,] but we can win a major battle in the arms race and gain a new territory of <br />
freedom for several years.</p><br />
<br />
<p>Governments are good at cutting off the heads of a centrally controlled <br />
networks like Napster, but pure P2P networks like Gnutella and Tor seem to be <br />
holding their own.<ref>[http://www.mail-archive.com/cryptography@metzdowd.com/msg09971.html Re: Bitcoin P2P e-cash paper Fri, 07 Nov 2008 09:30:36 -0800]</ref></p></blockquote><br />
<br />
<blockquote>It's very attractive to the libertarian viewpoint if we can explain it <br />
properly. I'm better with code than with words though. <ref>[http://www.mail-archive.com/cryptography@metzdowd.com/msg10001.html Re: Bitcoin P2P e-cash paper Fri, 14 Nov 2008 14:29:22]</ref></blockquote><br />
<br />
==Possible identity==<br />
His identity and nationality are unknown.<br />
<br />
He is entirely unknown outside of Bitcoin as far as anyone can tell, and his (never used) PGP key was created just months prior to the date of the genesis block. He seems to be very familiar with the cryptography mailing list, but there are no non-Bitcoin posts from him on it. He has used an email address from an anonymous mail hosting service (vistomail) as well as one from a free webmail account (gmx.com) and sends mail when connected via Tor. Some have speculated that his entire identity was created in advance in order to protect himself or the network. Perhaps he chose the name Satoshi because it can mean "wisdom" or "reason" and Nakamoto can mean "Central source".<br />
<br />
Ultimately the design of Bitcoin and its use of cryptographic proof and fully open implementation is one that makes its creator, in a sense, irrelevant and only of interest for historical reasons.<br />
<br />
==External links==<br />
* [http://bitcointalk.org/Satoshi_Nakamoto.asc Satoshi's PGP public key]<br />
* [http://www.bitcoin.org/bitcoin.pdf Bitcoin: A Peer-to-Peer Electronic Cash System] Paper<br />
* [http://sourceforge.net/users/s_nakamoto SourceForge page]<br />
<br />
==References==<br />
<references/><br />
<br />
[[de:Satoshi Nakamoto]]<br />
[[es:Satoshi Nakamoto]]<br />
<br />
[[Category:Individuals]]</div>Ripper234https://en.bitcoin.it/w/index.php?title=Satoshi&diff=64570Satoshi2017-12-11T05:58:11Z<p>Ripper234: Create disambiguation page instead of redirect</p>
<hr />
<div>Can mean either<br />
<br />
* [[Satoshi Nakamoto]], creator of Bitcoin<br />
* [[Satoshi (unit)]], the smallest possible amount of bitcoin</div>Ripper234https://en.bitcoin.it/w/index.php?title=Ron_Gross&diff=63591Ron Gross2017-07-07T17:03:44Z<p>Ripper234: Update bio</p>
<hr />
<div>[[image:Ron Gross.jpg]]<br />
<br />
Ron has graduated from the Technion with an M. Sc in Computer Science.<br />
He has worked at several companies, ranging from small startups to Google,<br />
and has an extensive experience in web architecture, security, and algorithms.<br />
<br />
Ron has been continuously involved with Bitcoin since March 2011,<br />
spreading the word, knowledge, and love of Bitcoin. He is a firm advocate of <br />
open source, transparency and decentralization of power and technology.<br />
Ron co-founded the Israeli Bitcoin community and Foundation and was the Executive Director of the [[Mastercoin Foundation]] (the world's first ICO).<br />
<br />
You can reach Ron at:<br />
* ron@bitcoin.org<br />
* skype - ripper234<br />
<br />
See also read [http://ripper234.com/#about the about page on his blog].<br />
<br />
[[Category:People]]</div>Ripper234https://en.bitcoin.it/w/index.php?title=Ron_Gross&diff=63355Ron Gross2017-06-14T03:39:01Z<p>Ripper234: Fix broken link</p>
<hr />
<div>[[image:Ron Gross.jpg]]<br />
<br />
Ron has graduated from the Technion with an M. Sc in Computer Science.<br />
He has worked at several companies, ranging from small startups to Google,<br />
and has an extensive experience in web architecture, security, and algorithms.<br />
<br />
Ron has been continuously involved with Bitcoin since March 2011,<br />
spreading the word, knowledge, and love of Bitcoin. He is a firm advocate of <br />
open source, transparency and decentralization of power and technology.<br />
Ron co-founded the Israeli Bitcoin community and foundation and is a board member of the [[Mastercoin Foundation]].<br />
<br />
He was a partner in [[Bitcoil]], the first Israeli exchange.<br />
<br />
He briefly worked on [[Bitblu]] in the summer of 2013.<br />
<br />
As of June 2014 Ron is the Co-Founder and Executive Director of the Mastercoin project.<br />
<br />
You can reach Ron at:<br />
* ron@bitcoin.org<br />
* skype - ripper234<br />
<br />
See also read [http://ripper234.com/#about the about page on his blog].<br />
<br />
[[Category:People]]</div>Ripper234https://en.bitcoin.it/w/index.php?title=Ron_Gross&diff=56112Ron Gross2015-04-14T01:50:00Z<p>Ripper234: Update contact info</p>
<hr />
<div>[[image:Ron Gross.jpg]]<br />
<br />
Ron has graduated from the Technion with an M. Sc in Computer Science.<br />
He has worked at several companies, ranging from small startups to Google,<br />
and has an extensive experience in web architecture, security, and algorithms.<br />
<br />
Ron has been continuously involved with Bitcoin since March 2011,<br />
spreading the word, knowledge, and love of Bitcoin. He is a firm advocate of <br />
open source, transparency and decentralization of power and technology.<br />
Ron co-founded the Israeli Bitcoin community and foundation and is a board member of the [[Mastercoin Foundation]].<br />
<br />
He was a partner in [[Bitcoil]], the first Israeli exchange.<br />
<br />
He briefly worked on [[Bitblu]] in the summer of 2013.<br />
<br />
As of June 2014 Ron is the Co-Founder and Executive Director of the Mastercoin project.<br />
<br />
You can reach Ron at:<br />
* ron@bitcoin.org<br />
* skype - ripper234<br />
<br />
See also read [http://ripper234.com/about the about page on his blog].<br />
<br />
[[Category:People]]</div>Ripper234https://en.bitcoin.it/w/index.php?title=The_Hoarding_Problem&diff=50857The Hoarding Problem2014-09-05T17:07:29Z<p>Ripper234: Created page with "{{stub}} The concept that people hoarding Bitcoin is a problem for Bitcoin adoption. See: * [http://themisescircle.org/blog/2014/02/12/im-hoarding-bitcoins-and-no-you-cant-..."</p>
<hr />
<div>{{stub}}<br />
<br />
The concept that people hoarding Bitcoin is a problem for Bitcoin adoption.<br />
<br />
See:<br />
<br />
* [http://themisescircle.org/blog/2014/02/12/im-hoarding-bitcoins-and-no-you-cant-have-any/ I’m Hoarding Bitcoins, and No You Can’t Have Any]<br />
* [http://www.coindesk.com/investor-fred-wilson-security-hoarding-holding-back-bitcoin/ Investor Fred Wilson: Security and Hoarding Are Holding Back Bitcoin]<br />
* [http://www.forbes.com/sites/timothylee/2013/04/11/bitcoin-doesnt-have-a-deflation-problem/ Bitcoin Doesn't Have a Deflation Problem]<br />
* [[Deflationary spiral]]</div>Ripper234https://en.bitcoin.it/w/index.php?title=List_of_Bitcoin_non-profits_around_the_world&diff=50844List of Bitcoin non-profits around the world2014-09-05T02:31:07Z<p>Ripper234: /* Canada: The Bitcoin Embassy */</p>
<hr />
<div>This page will list all the known Bitcoin and crypto-currency non-profits around the world. The criterias for being on this list are:<br />
<br />
# A focus on Bitcoin or crypto-currency (merely accepting Bitcoin donations is not enough)<br />
# Being a non-profit<br />
# The organization needs to be either a registered non-profit or in the process of active registration.<br />
<br />
= List of organizations (by country of residence)=<br />
<br />
== Argentina: Fundación Bitcoin Argentina ==<br />
* [http://www.bitcoinargentina.org/ Website]<br />
<br />
== Australia: The Bitcoin Association of Australia ==<br />
* Board members:<br />
** [[Martin Bajalan]]<br />
** [[Max Kaye]] Treasurer<br />
** [[Adam Poulton]] Secretary<br />
** [[Pantelis Roussakis]] Vice-President<br />
** [[Bret Treasure]]<br />
** [[Jason Williams]] President<br />
** [[Tristan Winters]]<br />
<br />
== Austria: Bitcoin Austria ==<br />
* [http://bitcoin-austria.at/ Website]<br />
<br />
== Belgium: Belgian Bitcoin Association ==<br />
[http://www.bitcoinassociation.be website]<br />
<br />
* Directors:<br />
** [[Arne Brutschy]]<br />
** [[Chris D'Costa]]<br />
** [[Jérémie Dubois-Lacoste]]<br />
** [[Filip Roose]]<br />
** [[Thomas Spaas]] <br />
** [[Jean Wallemacq]]<br />
<br />
== Canada: The Bitcoin Embassy ==<br />
* [http://bitcoinembassy.ca website]<br />
A non-profit organization seeking to promote the adoption of Bitcoin and related crypto-technologies, as well as facilitating networking throughout the Bitcoin community in Canada and worldwide.<br />
<br />
== Canada: Bitcoin Alliance of Canada ==<br />
* [http://www.bitcoinalliance.ca/ website]<br />
<br />
== Denmark: The Bitcoin Association of Denmark ==<br />
* [http://www.danskbitcoinforening.dk/ Website]<br />
<br />
== Germany: Bundesverband Bitcoin e.V. ==<br />
* [http://www.bundesverband-bitcoin.de/ Website]<br />
* Board members:<br />
** [[Radoslav Albrecht]]<br />
** [[Dennis Daiber]]<br />
** [[Oliver Flaskämper]]<br />
** [[JF Gallas]] Chairman<br />
** [[Timo Hanke]]<br />
** [[Jörg von Minckwitz]]<br />
** [[Jörg Platzer]] Vice Chairman<br />
<br />
== India: Bitcoin Alliance of India ==<br />
* [http://www.bitcoinalliance.in/ Website]<br />
<br />
== Ireland: Bitcoin Foundation of Ireland. ==<br />
* [http://www.bitcoinirl.ie Website]<br />
* Board members:<br />
** [[Alan Donohoe]]<br />
** [[Vincent O Donoghue]]<br />
** [[Roger Ver]]<br />
<br />
<br />
== Israel: איגוד הביטקוין הישראלי ==<br />
See [[The Israeli Bitcoin Association]].<br />
<br />
== Italy: Bitcoin Foundation Italia ==<br />
* [https://www.bitcoin-italia.org/ Website]<br />
* Board members:<br />
** [[Andrea Medri]]<br />
** [[Davide Barbieri]]<br />
** [[Franco Cimatti]]<br />
<br />
== Netherlands: Stichting Bitcoin Nederland ==<br />
* [http://stichtingbitcoin.nl/ Website]<br />
* [http://stichtingbitcoin.nl/index.php/de-stichting/het-bestuur/ Board members]:<br />
** [[Mark van Cuijk]]<br />
** [[Jouke Hofman]]<br />
** [[Richard Kohl]]<br />
** [[Carl Kuntze]]<br />
** [[Sicco Steenhuisen]] Chairman<br />
<br />
== Poland: Polish Bitcoin Association ==<br />
* [http://bitcoin.org.pl/ Website]<br />
* Board members:<br />
** [[Filip Pawczyński]] - Chairman<br />
** [[Sebastian Schmidt]] - Secretary<br />
** [[Irwin Przeperski]] - Treasurer<br />
<br />
== Russia: Crypto Currencies Foundation Russia ==<br />
* [http://ccfr.info/ Website]<br />
* Board members:<br />
** [[Igor Chepkasov]] - Chairman<br />
** [[Irma Nyenskans]] - Secretary<br />
** [[Serguey Dobryshkin]] - IT & Security officer<br />
<br />
== Sweden: The Bitcoin Association of Sweden ==<br />
* [http://www.bitcoinforeningen.se/ Website]<br />
* Board members:<br />
** [[Mats Henricson]] - Chairman<br />
** [[Andreas de Blanche]] - Secretary<br />
** [[Richard Birgersson]] - Treasurer<br />
** [[Robert Högberg]]<br />
** [[Ludvig Öberg]]<br />
<br />
== Switzerland: Bitcoin Association Switzerland ==<br />
* [http://www.bitcoinassociation.ch/ Website]<br />
* Board members:<br />
** [[Johann Gevers]] - Treasurer<br />
** [[Stefan Greiner]] - Secretary<br />
** [[Luzius Meisser]] - President<br />
<br />
== United Kingdom: UK Bitcoin Foundation ==<br />
* [[Adam Cleary]]<br />
* [[Paul Gordon]]<br />
* [[Eitan Jankelewitz]]<br />
* [[Tom Robinson]]<br />
* [[James Smith]]<br />
* [[Lee Welham]]<br />
<br />
== United States / International: Bitcoin Foundation ==<br />
* [http://bitcoinfoundation.org/ website]<br />
* [https://bitcoinfoundation.org/about/board Board members (alphabetically)]:<br />
** [[Gavin Andresen]] - Chief Scientist<br />
** [[Micky Malka]] - Board Member<br />
** [[Jon Matonis]] - Executive Director and Board Member<br />
** [[Patrick Murck]] - General Counsel<br />
** [[Elizabeth T. Ploshay]] - Board Member<br />
** [[Peter Vessenes]] - Chairman of the Board<br />
<br />
= Other =<br />
== Bitcoin100 ==<br />
[http://bitcoin100.org/ Bitcoin100] is a charity organization that exists specifically to convince new charities to start accepting bitcoin donations.<br />
<br />
== The Mastercoin Foundation ==<br />
See [http://wiki.mastercoin.org/index.php/The_Mastercoin_Foundation the Mastercoin wiki].<br />
<br />
== PikaPay Foundation ==<br />
<br />
The [https://PikaPay.com PikaPay Foundation] is a nonprofit dedicated to innovation in today’s financial systems and is focussed on developing the Bitcoin ecosystem.<br />
<br />
PikaPay's Mission: To explore trends in science, technology, community and culture; To overcome limitations of traditional financial services; To improve lives, empower groups and individuals; and To make greater social contributions to the world.<br />
<br />
= See Also =<br />
# [https://bitcointalk.org/index.php?topic=288677.0 bitcointalk thread]<br />
# [https://docs.google.com/document/d/1TnTCcT7fiNr5nt-oApr_7DwXAypFoJpZ6lk_w_ykwcc/edit google doc].<br />
# [[:Category:nonprofit]]</div>Ripper234https://en.bitcoin.it/w/index.php?title=Category:History&diff=50657Category:History2014-09-01T08:29:17Z<p>Ripper234: /* 2011 */ Add Room77</p>
<hr />
<div>Two fantastic compilations of Bitcoin history are available at the [http://historyofbitcoin.org HistoryOfBitcoin.org] and [http://igotbitcoin.com/milestones igotbitcoin.com/milestones] sites.<br />
<br />
== Important milestones of the Bitcoin project ==<br />
=== 2008 ===<br />
{| style="text-align: left"<br />
|-<br />
! width="8em" | August 18<br />
|| Domain name "bitcoin.org" registered<ref>[https://bitcointalk.org/index.php?topic=103369.msg1135218#msg1135218 According to theymos], Satoshi registered bitcoin.org via https://www.anonymousspeech.com/ which allows to anonymously register domains.</ref>.<br />
|-<br />
! October 31<br />
|| [http://article.gmane.org/gmane.comp.encryption.general/12588/ Bitcoin design paper] published<br />
|-<br />
! November 09<br />
|| Bitcoin project registered at SourceForge.net<br />
|}<br />
<br />
=== 2009 ===<br />
{| style="text-align: left"<br />
|-<br />
! width="8em" | January 3<br />
|| [http://www.BlockExplorer.com/b/0 Genesis block] established at 18:15:05 GMT<br />
|-<br />
! January 9<br />
|| Bitcoin v0.1 released and announced on the [http://www.mail-archive.com/cryptography@metzdowd.com/msg10152.html cryptography mailing list]<br />
|-<br />
! January 12<br />
|| First Bitcoin transaction, [http://www.BlockExplorer.com/b/170 in block 170] - from [[Satoshi]] to Hal Finney<ref>[http://bitcointalk.org/index.php?topic=91806.msg1012234#msg1012234 Earliest Block With A Spend]</ref>.<br />
|-<br />
! October 5<br />
|| Exchange rates [http://newlibertystandard.wetpaint.com/page/2009+Exchange+Rate published] by New Liberty Standard. $1 = 1,309.03 BTC (and [[User:theymos|theymos]] thought NLS was overcharging<ref>[http://bitcointalk.org/index.php?topic=104287.msg1143955#msg1143955 Historical Price Data for 2009]</ref>)<br />
|-<br />
! October 9<br />
|| #bitcoin-dev channel registered on freenode IRC.<br />
|-<br />
! December 16<br />
|| Bitcoin v0.2 released<br />
|-<br />
! December 30<br />
|| First difficulty increase at 06:11:04 GMT<br />
|}<br />
<br />
=== 2010 ===<br />
{| style="text-align: left"<br />
|-<br />
! width="8em" | February 6<br />
|| [[Bitcoin Market]] established<br />
|-<br />
! May 22<br />
|| laszlo first to buy pizza with Bitcoins agreeing upon paying 10,000 BTC for ~$25 worth of pizza courtesy of jercos<ref>[https://bitcointalk.org/index.php?topic=137.msg1195#msg1195 bitcointalk post] where laszlo confirmed having bought pizza</ref><br />
|-<br />
! July 7<br />
|| Bitcoin v0.3 released<br />
|-<br />
! July 11<br />
|| Bitcoin v0.3 release mentioned on slashdot<ref>[http://news.slashdot.org/story/10/07/11/1747245/Bitcoin-Releases-Version-03 slashdot] metiones Bitcoin</ref>, bringing a large influx of new bitcoin users.<br />
|-<br />
! July 12<br />
|| Beginning of a 10x increase in exchange value over a 5 day period, from about $0.008/BTC to $0.08/BTC<br />
|-<br />
! July 17<br />
|| [[MtGox]] established<br />
|-<br />
! July 18<br />
|| ArtForz generated his first block after establishing his personal OpenCL GPU hash farm<br />
|-<br />
! August 15<br />
|| Bug in the bitcoin code allows a bad transaction into block 74638. Users quickly adopt fixed code and the "good" block chain overtook the bad one at a block height of 74691, 53 blocks later ([[Incidents#Value_overflow]]).<br />
|-<br />
! September 14<br />
|| jgarzik [https://bitcointalk.org/index.php?topic=133.msg12921#msg12921 offered] 10,000 BTC (valued at ~$600-650) to puddinpop to open source their windows-based CUDA client<br />
|-<br />
! September 14<br />
|| Block [http://blockexplorer.com/b/79764 79,764] is first to be mined using split allocation of the generation reward.<br />
|-<br />
! September 18<br />
|| puddinpop [https://bitcointalk.org/index.php?topic=133.msg13135#msg13135 released] source to their windows-based CUDA client under MIT license<br />
|-<br />
! September 29<br />
|| kermit [https://bitcointalk.org/index.php?topic=1306.0 discovered] a microtransactions exploit which precipitated the Bitcoin v0.3.13 release<br />
|-<br />
! October 01<br />
|| [https://bitcointalk.org/?topic=1334.0 First public OpenCL miner] released<br />
|-<br />
! October 04<br />
|| Original Bitcoin History wiki page (this page) established (ooh so meta) on Bitcoin.org's wiki.<br />
|-<br />
! October 07<br />
|| Exchange rate started climbing up from $0.06/BTC after several flat months.<br />
|-<br />
! October 16<br />
|| First recorded escrowed bitcoin trade conducted, between nanotube and Diablo-D3, escrowed by theymos.<br />
|-<br />
! October 17<br />
|| [[Bitcoin_OTC|#bitcoin-otc]] trading channel established on freenode IRC.<br />
|-<br />
! October 28<br />
|| First bitcoin short sale transaction initiated, with a loan of 100 BTC by nanotube to [[User:Kiba|kiba]], facilitated by the [[Bitcoin-otc|#bitcoin-otc]] market.<br />
|-<br />
! November 6<br />
|| The [https://bitcointalk.org/index.php?topic=1672 Bitcoin economy passed US $1 million]. The MtGox price touched USD $0.50/BTC.<br />
|-<br />
! December 7<br />
|| Bitcoind was compiled for the Nokia N900 mobile computer by doublec. The following day, ribuck sent him 0.42 BTC in the first portable-to-portable Bitcoin transaction.<br />
|-<br />
! December 9<br />
|| The generation difficulty passed 10,000.<br />
|-<br />
|<br />
|| First bitcoin call option contract sold, from nanotube to [[User:Sgornick|sgornick]], via the [[Bitcoin-otc|#bitcoin-otc]] market.<br />
|-<br />
! December 16<br />
|| [http://mining.bitcoin.cz/ Bitcoin Pooled Mining], operated by slush, found its first block<br />
|}<br />
<br />
=== 2011 ===<br />
{| style="text-align: left"<br />
|-<br />
! width="8em" | January 2<br />
|| [[Tonal Bitcoin]] units standardized.<br />
|-<br />
! January 8<br />
|| [[History of Bitcoin]] page (this page) created after replicating from original Bitcoin History page on Bitcoin.org.<br />
|-<br />
|<br />
|| Bitcoin Pooled Mining reached a total of 10,000 Mhash/s<br />
|-<br />
! January 27<br />
|| Largest numeric value ever traded for bitcoins thus far occurred on this date. Three currency bills from Zimbabwe, known as Zimdollars, were traded on [[Bitcoin-otc|#bitcoin-otc]] at the rate of 4 BTC for each of the one-hundred trillion dollar ($100,000,000,000,000) Zimbabwe notes<ref>Serial numbers for Zimdollars sold: AA1669317, AA1669318 and AA1669319</ref><br />
|-<br />
! January 28<br />
|| Block 105000 was generated. This means that 5.25 million bitcoins have been generated, which is just over one-quarter of the eventual total of nearly 21 million.<br />
|-<br />
! February 9<br />
|| Bitcoin reached parity with the US dollar, touching $1 per BTC at [[MtGox]].<br />
|-<br />
! February 10<br />
|| Bitcoin.org website struggles to handle [https://bitcointalk.org/index.php?topic=3444.0 traffic] resulting from mentions on Slashdot<ref>[http://news.slashdot.org/story/11/02/10/189246/Online-Only-Currency-BitCoin-Reaches-Dollar-Parity Online-Only Currency BitCoin Reaches Dollar Parity]</ref>, Hacker News and Twitter following the news that parity had been reached.<br />
|-<br />
! February 14<br />
|| A vehicle was, for the first time, offered in exchange for a certain number of bitcoins<ref>[https://bitcointalk.org/index.php?topic=3485.0 Car for Sale - Australia]</ref>.<br />
|-<br />
! March 1<br />
|| [[MagicalTux]] buys mtgox.com from its founder [[Jed McCaleb]]<br />
|-<br />
! March 6<br />
|| Total Bitcoin network computation speed for a short time reached a new high of almost 900Ghash/sec, dropping to 500Ghash/sec soon after. Some speculate that this was due to some supercomputer or bot-net that joined the network ([http://bitcoin.atspace.com/mysteryminer.html mystery miner]).<br />
|-<br />
! March 18<br />
|| BTC/USD exchange rate reaches a 6-week low point at almost $0.70/BTC, after what appeared to be a short burst of, possibly automated, BTC sales at progressively lower prices. BTC price had been declining since the February 9 high.<br />
|-<br />
! March 25<br />
|| Difficulty decreased nearly 10%. A decrease has only occurred once before, and this decrease of nearly 10% was the largest.<br />
|-<br />
! March 27<br />
|| The first market for exchanging bitcoins to and from the British Pound Sterling BTC/GBP, [[Britcoin]], opens.<br />
|-<br />
! March 31<br />
|| The first market for exchanging bitcoins to and from Brazilian Reals, [[Bitcoin Brazil]], opens.<br />
|-<br />
! April 5<br />
|| The first market for exchanging bitcoins to and from the Polish złoty, [[BitMarket.eu]], opens.<br />
|-<br />
! April 12<br />
|| First bitcoin put option contract sold via the [[Bitcoin-otc|#bitcoin-otc]] market.<br />
|-<br />
! April 16<br />
|| TIME does [http://techland.time.com/2011/04/16/online-cash-bitcoin-could-challenge-governments/ an article on Bitcoin].<br />
|-<br />
! April 23<br />
|| BTC/USD exchange rate reaches and passes parity with the Euro (EUR) on [[MtGox]] exchange.<br />
|-<br />
|<br />
|| BTC/USD exchange rate reaches and passes parity with the British Sterling Pound (GBP) on [[MtGox]] exchange.<br />
|-<br />
|<br />
|| Value of the Bitcoin money stock at current exchange rate passes $10 million USD threshold.<br />
|-<br />
! April 27<br />
|| [[VirWoX]] opens first market to trade bitcoins against a virtual currency on BTC/SL (Second Life Lindens) exchange.<br />
|-<br />
! April 30<br />
|| The generation difficulty passed 100,000.<br />
|-<br />
! June 2<br />
|| The exchange rate at [[MtGox]] touched 10 USD per BTC.<br />
|-<br />
! June 3<br />
|| [[Tonal Bitcoin]] reached parity with the US cent, touching 1¢ per TBC at [[Bitcoin Market]].<br />
|-<br />
! June 8<br />
|| The [[MtGox]] exchange rate peaked at 31.91 USD, at a "market capitalization" of about $206 M [http://bitcoin.stackexchange.com/questions/2047/market-capitalization-over-time].<br />
|-<br />
! June 12<br />
|| The [[MtGox]] exchange rate briefly dropped to near 10 USD four days after the peak, in its largest percentage price retreat to date.<br />
|-<br />
! June 13<br />
|| Forum user allinvain claimed to have had [http://forum.bitcoin.org/index.php?topic=16457.0 25,000 BTC stolen] from his Bitcoin wallet (approx. USD equivalent $375,000).<br />
|-<br />
! June 19<br />
|| The MtGox database was compromised and the user table was leaked, containing details of 60,000 usernames, email addresses and password hashes, some of which were overly simple to brute force passwords.<br />
|-<br />
! June 19<br />
|| Someone was able to access an admin account at MtGox and issue sell orders for hundreds of thousands of fake bitcoins, forcing the MtGox price down from $17.51 per bitcoin to $0.01. MtGox announced that these trades would be reversed. Trading was halted at MtGox for 7 days (and also briefly at TradeHill and Britcoin while their security was reviewed).<br />
|-<br />
! June 19<br />
|| Some of the users on the leaked MtGox database had used the same username at MyBitcoin and had their passwords hacked. About 600 of them had their balance [http://forum.bitcoin.org/index.php?topic=22221.msg279396#msg279396 stolen from their MyBitcoin accounts]. One user lost over 2000 BTC.<br />
|-<br />
! June 20<br />
|| The EFF announced that it was no longer accepting Bitcoin donations due to legal uncertainties.<br />
|-<br />
! June 24<br />
|| The generation difficulty passed 1,000,000 with Block [http://blockexplorer.com/b/133056 133056].<br />
|-<br />
! July 19<br />
|| "Let it go on record that at 4:05pm CET [19 July 2011], my manager Tadek was the first person in the world to receive [testnet] Bitcoins via NFC ;)" - Mike Hearn<br />
|-<br />
! July 22<br />
|| [[BitCoins Mobile]], the first Bitcoin application for iPad was released by [http://www.intervex.net Intervex Digital].<br />
|-<br />
! July 26<br />
|| [http://www.room77.de/ Room77] [https://bitcointalk.org/index.php?topic=32162.0 becomes] the first brick-and-mortar business (bar) to accept Bitcoin as a means of payment.<br />
|-<br />
! July 30<br />
|| [http://pastebin.com/raw.php?i=BUB3dygQ Tribute to Len Sassaman] included in the blockchain<ref>[http://bitcointalk.org/index.php?topic=33618.msg420597#msg420597 A Tribute to Len "rabbi" Sassama]</ref>. <br />
|-<br />
! August 20<br />
|| First Bitcoin Conference and World Expo held, in NYC.<ref>[http://bitcoinme.com/index.php/conference/ New York Conference 2011]</ref><br />
|-<br />
! August 23<br />
|| [[P2Pool]], the first P2P decentralized pool, mines its first Bitcoin mainnet block (Block [http://blockexplorer.com/b/142312 142,312]).<br />
|-<br />
! August 30<br />
|| Difficulty adjustment at block [http://blockexplorer.com/b/143136 143,136] marks the first back-to-back drop.<br />
|-<br />
! November 15<br />
|| First CVE (CVE-2011-4447) assigned to a Bitcoin client exploit.<br />
|-<br />
! November 25<br />
|| First European Bitcoin Conference in Prague, Czech Rep.<ref>[http://bitgroups.org/ Prague Conference 2011]</ref><br />
|-<br />
! December 12<br />
|| Largest amount of fees, to-date, in a single transaction, and most fees in a single block. A [http://blockexplorer.com/tx/1d7749c65c90c32f5e2c036217a2574f3f4403da39174626b246eefa620b58d9 transaction] paid 171 BTC in fees in [http://blockexplorer.com/b/157235 block 157235]<ref>[http://bitcointalk.org/index.php?topic=88423.msg973509#msg973509 Largest fee ever?]</ref>.<br />
|}<br />
<br />
=== 2012 ===<br />
{| style="text-align: left"<br />
|-<br />
! width="8em" | March 1<br />
|| Largest theft of bitcoins to-date occurred (near 50K BTC) after security breach at web host Linode.<br />
|-<br />
! width="8em" | April 1<br />
|| Pay-to-script-hash ([[P2SH]]) as defined through [[BIP 0016]] goes live.<br />
|-<br />
! May 08<br />
|| A single service, [[SatoshiDICE]] becomes responsible for over half the transaction volume on the Bitcoin blockchain.<br />
|-<br />
! June 3<br />
|| Largest block (most transactions), to-date (June 3), is [http://BlockExplorer.com/b/181919 block 181919] with 1322 transactions<ref>[http://bitcointalk.org/index.php?topic=85353.msg939859#msg939859 Largest block to date]</ref>.<br />
|-<br />
! July 22<br />
|| One millionth topic reply was posted on the unofficial [[Bitcoin Forum]] <ref>[https://bitcointalk.org/index.php?topic=94608.0 Topic about one millionth forum post]</ref>.<br />
|-<br />
! September 15-16<br />
|| Bitcoin Conference in London <ref>[http://bitcoin2012.com/ London Conference 2012]</ref>.<br />
|-<br />
! September 27<br />
|| Formation of the [[Bitcoin Foundation]].<br />
|-<br />
! November 28<br />
|| Halving day. [http://blockexplorer.com/b/210000 Block 210,000] is the first with a block reward subsidy of only 25 BTC.<br />
|-<br />
! December 6<br />
|| First Bitcoin exchange [https://bitcointalk.org/index.php?topic=129461.0 licensed "as a bank" in europe] (actually a PSP which is like a bank, without debt-money issuing).<br />
|}<br />
<br />
=== 2013 ===<br />
{| style="text-align: left"<br />
|-<br />
! width="8em" | February 19<br />
|| Bitcoin Client v0.8 released featuring improved download speed and [https://en.wikipedia.org/wiki/Bloom_filter Bloom Filtering]<br />
|-<br />
! February 28<br />
|| The [[MtGox]] exchange rate broke the June 8 2011 peak of 31.91 USD. The first all time high since 601 days<br />
|-<br />
! March 12<br />
|| A previously undiscovered protocol rule results in a [http://bitcoin.org/chainfork.html hard fork of the 0.8.0 reference client].<br />
|-<br />
! March 18<br />
|| The United States federal agency charged with enforcing laws against money laundering (FinCEN) declares that Bitcoin users are subject to regulation only at the point of USD-BTC exchange.<ref>[http://arstechnica.com/tech-policy/2013/03/us-regulator-bitcoin-exchanges-must-comply-with-money-laundering-laws/ US regulator: Bitcoin exchanges must comply with money-laundering laws]</ref><br />
|-<br />
! March 28<br />
|| Total Bitcoin market cap passes $1 billion. <ref>http://spectrum.ieee.org/computing/networks/bitcoin-hits-1billion</ref><br />
|-<br />
! April 1<br />
|| Bitcoin price breaks 100 USD on [[MtGox]] and other major exchanges.<br />
|-<br />
|}<br />
<br />
==See Also==<br />
<br />
* [[Bitcoin Firsts]]<br />
* [[Press]]<br />
* [https://bitcoinhelp.net/know/more/price-chart-history Bitcoin Price Chart with Historic Events]<br />
<br />
==References==<br />
<references /></div>Ripper234https://en.bitcoin.it/w/index.php?title=Jed_McCaleb&diff=50656Jed McCaleb2014-09-01T08:15:55Z<p>Ripper234: Created page with "Original founder of Mt. Gox before Mark Karpelès. Since then he founded Ripple, and left it in 2014 to found Stellar. Category:people"</p>
<hr />
<div>Original founder of [[Mt. Gox]] before [[Mark Karpelès]].<br />
Since then he founded [[Ripple]], and left it in 2014 to found [[Stellar]].<br />
<br />
[[Category:people]]</div>Ripper234https://en.bitcoin.it/w/index.php?title=Mark_Karpel%C3%A8s&diff=50655Mark Karpelès2014-09-01T08:14:40Z<p>Ripper234: </p>
<hr />
<div>{{stub}}<br />
<br />
[http://en.wikipedia.org/wiki/Mark_Karpel%C3%A8s Mark Karpelès], former CEO of [[Mt. Gox]] until it shut down, and long-time super-admin of the Bitcoin wiki. His user page is [[User:MagicalTux]].<br />
<br />
[[Category:people]]</div>Ripper234https://en.bitcoin.it/w/index.php?title=Mark_Karpel%C3%A8s&diff=50654Mark Karpelès2014-09-01T08:14:20Z<p>Ripper234: </p>
<hr />
<div>{{stub}}<br />
<br />
[http://en.wikipedia.org/wiki/Mark_Karpel%C3%A8s Mark Karpelès], CEO of [[Mt. Gox]], and long-time super-admin of the Bitcoin wiki. His user page is [[User:MagicalTux]].<br />
<br />
[[Category:people]]</div>Ripper234https://en.bitcoin.it/w/index.php?title=Mark_Karpeles&diff=50653Mark Karpeles2014-09-01T08:13:44Z<p>Ripper234: Prefer Wikipedia's spelling</p>
<hr />
<div>#redirect [[Mark Karpelès]]</div>Ripper234https://en.bitcoin.it/w/index.php?title=MagicalTux&diff=50652MagicalTux2014-09-01T08:11:17Z<p>Ripper234: Ripper234 moved page MagicalTux to Mark Karpelès: Prefer real name</p>
<hr />
<div>#REDIRECT [[Mark Karpelès]]</div>Ripper234https://en.bitcoin.it/w/index.php?title=Mark_Karpel%C3%A8s&diff=50651Mark Karpelès2014-09-01T08:11:17Z<p>Ripper234: Ripper234 moved page MagicalTux to Mark Karpelès: Prefer real name</p>
<hr />
<div>[http://en.wikipedia.org/wiki/Mark_Karpel%C3%A8s Mark Karpelès], CEO of [[Mt. Gox]].<br />
<br />
[[Category:people]]</div>Ripper234https://en.bitcoin.it/w/index.php?title=Mark_Karpel%C3%A8s&diff=50650Mark Karpelès2014-09-01T08:09:57Z<p>Ripper234: </p>
<hr />
<div>[http://en.wikipedia.org/wiki/Mark_Karpel%C3%A8s Mark Karpelès], CEO of [[Mt. Gox]].<br />
<br />
[[Category:people]]</div>Ripper234https://en.bitcoin.it/w/index.php?title=Mark_Karpel%C3%A8s&diff=50649Mark Karpelès2014-09-01T08:09:48Z<p>Ripper234: Created page with "[http://en.wikipedia.org/wiki/Mark_Karpel%C3%A8s Mark Karpelès], CEO of Mt. Gox. Category:people"</p>
<hr />
<div>[http://en.wikipedia.org/wiki/Mark_Karpel%C3%A8s Mark Karpelès], CEO of Mt. Gox.<br />
<br />
[[Category:people]]</div>Ripper234https://en.bitcoin.it/w/index.php?title=Proof_of_Publication&diff=48135Proof of Publication2014-06-12T12:51:00Z<p>Ripper234: </p>
<hr />
<div>{{stub}}<br />
<br />
A method that uses Bitcoin or Bitcoin-like technologies to authenticate that a certain information was published at a certain date, or was known at a certain date.<br />
<br />
The technique entails encoding the secure hash of a certain publication (plaintext) inside the Bitcoin blockchain. It was probablly first described in the paper from 2012 titled "CommitCoin: Carbon Dating Commitments with Bitcoin" ([http://people.scs.carleton.ca/~clark/papers/2012_fc.pdf extended abstract] and [http://eprint.iacr.org/2011/677.pdf technical report]).<br />
<br />
== References ==<br />
* [http://proofofexistence.com/ proofofexistence.com] - Store hashes of data in the blockchain.<br />
* [http://coinsecrets.org/ coinsecrets.org] - list of metadata recently embedded in the bitcoin blockchain using OP_RETURN outputs.<br />
* [https://github.com/mastercoin-MSC/spec#appendix-a--storing-mastercoin-data-in-the-blockchain Encoding Master Protocol transactions]<br />
* [https://github.com/mastercoin-MSC/spec/issues/198 OP_RETURN in the Master Protocol]<br />
<br />
[[Category:Proof-of-x]]</div>Ripper234https://en.bitcoin.it/w/index.php?title=Proof_of_Publication&diff=48134Proof of Publication2014-06-12T12:50:01Z<p>Ripper234: </p>
<hr />
<div>{{stub}}<br />
<br />
A method that uses Bitcoin or Bitcoin-like technologies to authenticate that a certain information was published at a certain date, or was known at a certain date.<br />
<br />
The technique entails encoding the secure hash of a certain publication (plaintext) inside the Bitcoin blockchain. It was probablly first described in the paper from 2012 titled "CommitCoin: Carbon Dating Commitments with Bitcoin" ([http://people.scs.carleton.ca/~clark/papers/2012_fc.pdf extended abstract] and [http://eprint.iacr.org/2011/677.pdf technical report]).<br />
<br />
== References ==<br />
* [http://proofofexistence.com/ proofofexistence.com] - Store hashes of data in the blockchain.<br />
* [http://coinsecrets.org/ coinsecrets.org] - list of metadata recently embedded in the bitcoin blockchain using OP_RETURN outputs.<br />
* [https://github.com/mastercoin-MSC/spec/issues/198 OP_RETURN in the Master Protocol]<br />
<br />
[[Category:Proof-of-x]]</div>Ripper234https://en.bitcoin.it/w/index.php?title=Securing_your_wallet&diff=48104Securing your wallet2014-06-11T21:24:44Z<p>Ripper234: /* See Also */ Add link to the guide (in process is being written)</p>
<hr />
<div>==Introduction==<br />
<br />
Wallet security can be broken down into two independent goals:<br />
# Protecting your wallet against loss.<br />
# Protecting your wallet against theft.<br />
<br />
In the case that your current wallet hasn't been protected adequately (e.g. put online with a weaker password):<br />
# Making a new secure wallet, using appropriate long-term protection.<br />
<br />
''For a brief overview see also: [[Wallet Security Dos and Don'ts|Wallet Security Dos and Don'ts]]''<br />
<br />
==Paper Wallets==<br />
[[Paper wallet]]s can be used to store bitcoins offline in non-digital format. Using securely generated paper wallets significantly decreases the chances of your bitcoins being stolen by hackers or computer viruses.<br />
<br />
Fundamentally, a paper wallet is merely a physical record of a [[private key]] (most commonly written as a sequence of fifty-one alphanumeric characters beginning with a '5') and its corresponding [[public key]]. The private key is used to prove your right to spend the bitcoins transferred to the paper wallet, and as such should be kept hidden and secret. If the private key on a paper wallet is exposed (for example in a photograph) then the wallet may be "swept" by anyone who sees the key. To guard against accidental revelation, the private key displayed on the paper wallet may be encrypted using a password ("BIP38") or split into several different parts ("Shamir's secret sharing scheme"). At the very least, the private key should be well hidden e.g. by folding the wallet in half and sealing it shut.<br />
<br />
You can send bitcoins to the public address on your paper wallet as often as you like, and they will be inaccessible until the private key is imported into a "live" wallet. You can use a service such as blockchain.info to verify the balance of your paper wallet, which is a matter of public record. As of version 0.6.0, the bitcoin QT software has a command line feature called "importprivkey" that can load private keys. Online exchanges and wallets such as [[MtGox]], CoinBase and Blockchain.info have features for importing (or "sweeping") paper wallet private keys as well.<br />
<br />
=== Software for generating paper wallets ===<br />
<br />
Some [[Paper wallet|paper wallet generators]] have been written entirely in HTML/JavaScript to make it fairly easy to generate paper wallets on virtually any operating system. Although these generators use a web browser, they are generally capable of running offline since address generation happens entirely within the web browser. It's advisable to use those services from [https://en.wikipedia.org/wiki/Live_CD live disc], to ensure that private keys are not compromised by spyware. <br />
<br />
To generate a safer paper wallet, first save the paper wallet generating code to a newly-formatted USB stick and verify the integrity (SHA1 hash or PGP signature) of the code. Then "clean-boot" your computer with a bootable CD (such as a Linux Live CD) while disconnected from the Internet. Insert the USB stick and open the wallet generator's HTML file using a web browser. Print your paper wallets or store them on external media (do not save them on the computer), and then shut down the computer. You may need to load an appropriate printer driver in order to print while booted from the live CD.<br />
<br />
=== Tips for making paper wallets ===<br />
<br />
* Disconnecting from the Internet guarantees that that the paper wallet generator is truly self-contained and isn't transmitting your keys online. <br />
<br />
* Verifying the integrity of the code (and the trustworthiness of the author) is important to make sure a hacker hasn't modified the HTML so that it generates predictable addresses instead of truly random keys.<br />
<br />
* Using a very basic printer is advisable since high-end office printers may have WiFi or internal storage that keeps a cache of printed documents.<br />
<br />
* Remember, spyware and viruses often attempt to monitor your computer activities so that their authors can steal from you. They are interested in passwords to online accounts, and anything of value. Bitcoin wallets and private keys are something of value that have already been targeted by malware. If your computer is infected with spyware or viruses - even if there are no symptoms, or your antivirus isn't reporting anything - then anything you type, view, or save on your computer, could potentially be stolen by someone remotely controlling your computer. Your private key can then be intercepted while you enter it, so only enter a Bitcoin private key into your computer when your intent is to redeem its value ''immediately''.<br />
<br />
== Hardware wallets ==<br />
[[Hardware wallet]]s are a major effort to provide a good combination of enhanced security and usability.<br />
<br />
So far only [http://www.pi-wallet.com/ Pi Wallet] is operational.<br />
<br />
==Importance of security updates==<br />
<br />
No software is perfect, and from time to time there may be security vulnerabilities found in your Bitcoin client as well.<br />
Be sure you keep your client updated with the latest bug fixes, especially when a new vulnerability is discovered.<br />
We maintain a [[CVEs|list a known vulnerabilities]] on this wiki - you can watch that page to get updates.<br />
Note that you ''don't'' need to be running the latest major client version: some clients, including the popular Bitcoin-Qt, have older versions available with bugfix-only updates.<br />
<br />
==Securing the Bitcoin-QT or bitcoind wallet==<br />
<br />
Bitcoin transactions send Bitcoins to a specific public key. A Bitcoin address is an encoded hash of a public key. In order to use received Bitcoins, you need to have the private key matching the public key you received with. This is sort of like a super long password associated with an account (the account is the public key). Your Bitcoin wallet contains all of the private keys necessary for spending your received transactions. If you delete your wallet without a backup, then you no longer have the authorization information necessary to claim your coins, and the coins associated with those keys are lost forever.<br />
<br />
The wallet contains a pool of queued keys. By default there are 100 keys in the [[key pool]]. The size of the pool is configurable using the "-keypool" command line argument. When you need an address for whatever reason (send, “new address”, generation, etc.), the key is not actually generated freshly, but taken from this pool. A brand new address is generated to fill the pool back to 100. So when a backup is first created, it has all of your old keys plus 100 unused keys. After sending a transaction, it has 99 unused keys. After a total of 100 new-key actions, you will start using keys that are not in your backup. Since the backup does not have the private keys necessary for authorizing spends of these coins, restoring from the old backup will cause you to lose Bitcoins.<br />
<br />
Creating a new address generates a new pair of public and private keys, which are added to your wallet. Each keypair is mostly random numbers, so they cannot be known prior to generation. If you backup your wallet and then create more than 100 new addresses, the keypair associated with the newest addresses will not be in the old wallet because the new keypairs are only known after creating them. Any coins received at these addresses will be lost if you restore from the backup.<br />
<br />
The situation is made somewhat more confusing because the receiving addresses shown in the UI are not the only keys in your wallet. Each Bitcoin generation is given a new public key, and, more importantly, each sent transaction also sends some number of Bitcoins back to yourself at a new key. When sending Bitcoins to anyone, you generate a new keypair for yourself and simultaneously send Bitcoins to your new public key and the actual recipient's public key. This is an anonymity feature – it makes tracking Bitcoin transactions much more difficult.<br />
<br />
So if you create a backup, do more than 100 things that cause a new key to be used, and then restore from the backup, some Bitcoins will be lost. Bitcoin has not deleted any keys (keys are never deleted) – it has created a new key that is not in your old backup and then sent Bitcoins to it.<br />
<br />
== Making a new wallet ==<br />
<br />
If a wallet or an encrypted wallet's password has been compromised, it is wise to create a new wallet and transfer the full balance of bitcoins to addresses contained only in the newly created wallet. Examples of ways a wallet may be compromised are through password re-use, minimal strength passwords, computer hack or virus attack.<br />
<br />
There are a number of ways to create a new wallet with Bitcoin-QT or bitcoind but this is a process that has been tested with bitcoind 0.6.3. We use the copy command to minimize the chance of any data loss but you are warned to make backups of any wallet.dat that holds a balance for you.<br />
<br />
:1. Shut down the Bitcoin program.<br />
:2. Find and make a backup of the "compromised" wallet.dat file and rename it, perhaps adding a short description:<br />
:::wallet.dat -> wallet-compromised.dat<br />
:Depending on your OS, the wallet file will be located at:<br />
:::Windows: %APPDATA%\Bitcoin\<br />
:::Linux: ~/.bitcoin/<br />
:::Mac: ~/Library/Application Support/Bitcoin/<br />
:3. Start the Bitcoin program and it will create a new wallet.dat. You may then encrypt the wallet as desired and make a new backup.<br />
:4. Once you've made a new wallet, you can obtain one or more addresses and copy them into a text editor. After obtaining the new address(es), shut down the Bitcoin program, make a backup of the new wallet.dat file and copy it to a new file named wallet-new.dat.<br />
:5. Copy the wallet-compromised.dat file back to wallet.dat, start the Bitcoin program and transfer your balance to the new address(es) you put in your text editor. Once the balance is back to 0 for your compromised wallet, you may want to wait a couple minutes or for a confirmation or check block explorer to be sure the transactions have been broadcasted. Then you may shut down the Bitcoin program.<br />
:6. Rename wallet.dat to wallet-compromised.dat. <br />
:7. Rename wallet-new.dat to wallet.dat.<br />
<br />
You should now have a new wallet with all the bitcoins from the old wallet.<br />
<br />
==Making a secure workspace==<br />
<br />
If you are using your computer to handle bitcoins, a wallet, Bitcoin-related passwords, or Bitcoin private keys, you must take care that the system is free of malware, viruses, keyloggers, remote access tools, and other tools that may be used to make remote copies of any of the above. In the case that your computer is compromised, the precautions taken below may provide additional protection.<br />
<br />
===Debian-based Linux===<br />
<br />
==== Store all into an encrypted folder (Tomb) ====<br />
<br />
Tomb is a simple tool to manage encrypted storage on GNU/Linux. Among its features are bind-hooks to set up a tomb's contents in the place where other programs expect them, for example in our case mount -o bind the .bitcoin directory in a user's home.<br />
<br />
First install tomb from https://files.dyne.org/tomb (homepage is on http://www.dyne.org/software/tomb)<br />
<br />
Among the requirements: zsh, cryptsetup, pinentry-curses, gnupg, sudo.<br />
<br />
Recommended: wipe, dcfldd, steghide, qrencode.<br />
<br />
Then create a tomb (we name it bitcoin) with three commands:<br />
<br />
<code>tomb dig -s 100 bitcoin.tomb</code><br />
<br />
<code>tomb forge bitcoin.tomb.key</code><br />
<br />
<code>tomb lock bitcoin.tomb -k bitcoin.tomb.key</code><br />
<br />
Then open it<br />
<br />
<code>tomb open bitcoin.tomb</code><br />
<br />
This will require you to input again the password you selected.<br />
<br />
Once open the tomb contents are in /media/bitcoin.tomb<br />
<br />
Move there your bitcoin wallet:<br />
<br />
<code>mv ~/.bitcoin /media/bitcoin.tomb/my-safe-wallet</code><br />
<br />
Then create a file "/media/bitcoin.tomb/bind-hooks" and put a single line:<br />
<br />
<code>my-safe-wallet .bitcoin</code><br />
<br />
Which means that every time the tomb is open, the directory my-safe-wallet needs to be bound to ~/.bitcoin. Just make sure an empty ~/.bitcoin directory exists in your home.<br />
<br />
Now close the tomb and store its keys safely, make sure you memorize the password. Have a look at Tomb's documentation, there is a number of things you can do like steganography or printing out keys on a paper to hide and such.<br />
<br />
That's it. Every time you like to access your wallet open the tomb and the .bitcoin will be in place. One can also store the bitcoin binary inside the tomb and even start the bitcoin client using the exec-hooks. Tomb's manual page "man tomb" explains the possibilities.<br />
<br />
The advantage of this approach over an encrypted home is that it becomes extremely portable across computers and even online shells: a Tomb is just a file and its key can be stored far away, on different shells, usb sticks or mobile phones.<br />
<br />
<br />
<br />
<br />
==== Secure the whole user home directory ====<br />
The first step is to make a [http://www.howtogeek.com/howto/ubuntu/add-a-user-on-ubuntu-server/ new user]. In order for that new user to have an encrypted home directory, you'll first need the encryption utility. Run:<br />
<br />
<code>sudo apt-get install ecryptfs-utils</code><br />
<br />
Now you're ready to create a new user<br />
<br />
<code>sudo adduser --encrypt-home new_user_name</code><br />
<br />
You'll need to come up with a [[#Choosing_A_Strong_Password|secure]] new password for that user.<br />
<br />
When you get to the prompt 'Enter the new value, or press ENTER for the default', just keep hitting ENTER.<br />
<br />
Then switch user to the new user. To get to the new user you can use the switch user icon for your system, which on Ubuntu is in the 'System/Quit' screen, or if there is no switch icon on your system you can log out and log back in as the new user.<br />
<br />
Since the home folder of this user is encrypted, if you're not logged in as that user, data that is saved there can't be browsed, even by a root user. If something goes wrong with your system, and you need to decrypt the new user's files, you'll need its decryption key.<br />
<br />
<code>ecryptfs-unwrap-passphrase</code><br />
<br />
It will ask you for your user's password and give you the decryption key. '''WRITE DOWN OR SAVE THE CODE IT RETURNS''' because you will need it if you ever have to pull your data off while the OS is not working. (You can run it again later if you need to, but run it now so that you can get your data if your Linux install gets botched.)<br />
<br />
The encrypted folder data is not encrypted while it's in memory, and so if it's ever sent to the swap partition it can be stolen from there unless that too is encrypted - be aware that this will mean you cannot use Hibernate anymore, as the bootloader won't be able to restore the hibernation data.<br />
<br />
<code>ecryptfs-setup-swap</code><br />
<br />
Then click on a folder in the new user to display the file browser, then keep going up folders until you see the new user home directory, then right click to bring up the Properties dialog, then click on the Permissions tab, then in the Others section, set the folder access to None.<br />
<br />
For secure browsing, open Firefox, and then go into the Edit menu and click Preferences. Starting from the left, click on the General tab, and in the 'Startup/When Firefox starts' pop up menu, choose 'Show a Blank Page'. Then click on the Content tab, and deselect 'Load images automatically' and deselect 'Enable JavaScript'. Then click on the Privacy tab, and in the 'History/Firefox will' pop up menu, choose 'Never remember history'. Then click on the Security tab, and in the Passwords section, deselect 'Remember passwords for sites' and deselect 'Use a master password'. Then click on the Advanced tab, then click on the Update tab, and then in the 'Automatically check for updates to' section, deselect 'Add-ons' and 'Search Engines'.<br />
<br />
When JavaScript is disabled, the [http://sourceforge.net/projects/bitcoin/files/Bitcoin/bitcoin-0.3.23/bitcoin-0.3.23-linux.tar.gz/download Linux download page] will not download automatically, so you'll have to click on the 'direct link' part of the "Problems with the download? Please use this 'direct link' or try another mirror." line.<br />
<br />
===Mac===<br />
This solution '''does not scale'''; the amount of needed space can grow beyond the image size.<br />
<br />
===Windows===<br />
<br />
Due to the frequency with which Windows computers are compromised, it is advised to encrypt your wallet or to keep your wallet on an encrypted disk image created by third-party software, such as [http://www.truecrypt.org/ TrueCrypt] (open source) or [http://www.jetico.com/encryption-bestcrypt/ Jetico BestCrypt] (commercial). This also applies to the storage of passwords, private keys and other data that can be used to access any of your Bitcoin balances.<br />
<br />
Assuming that you have installed the Windows Bitcoin client and run it at least once, the process is described below.<br />
<br />
<p><b>To mount the Bitcoin data directory on an encrypted drive</b></p><br />
<ol start=1 type=1><br />
<li>Use the third-party disk image encryption program of your choice to create and mount an encrypted disk image of at least 5GB in size. This procedure stores the entire block chain database with the wallet.dat file so the required size of the encrypted disk image required may grow in the future.</li><br />
<li>Locate the Bitcoin data directory, and copy the directory with all contents to the encrypted drive.<br />
<p>For help finding this directory, see <b>[[Securing_your_wallet#Locating_Bitcoin_s_data_directory|Locating Bitcoin's Data Directory]]</b>.</p></li><br />
<li>Create a Windows shortcut that starts Bitcoin with the <code>-datadir</code> parameter and specifies the encrypted drive and directory.<br />
<p>For example, if you installed Bitcoin in the default directory, mounted your Bitcoin encrypted drive as <code>E:\</code>, and stored your Bitcoin data directory on it as <code>Bitcoin</code>, you would type the following command as the shortcut Target:</p><br />
<blockquote><code>C:\Program Files\Bitcoin\bitcoin.exe -datadir=E:\Bitcoin</code></blockquote></li><br />
<li>Open Bitcoin's settings and configure it <b>NOT</b> to start automatically when you start Windows.<br />
<p>This is to allow you to mount the Bitcoin encrypted disk image before starting Bitcoin.</p></li><br />
<li>Shut down Bitcoin, and then restart it from the new shortcut.</li><br />
</ol><br />
<br />
After doing this, any time you want to use Bitcoin, you must first mount the Bitcoin encrypted disk image using the same drive designation, and then run Bitcoin from the shortcut that you created, so that it can find its data and your wallet.<br />
<br />
<br />
=== General Solutions ===<br />
<br />
Your wallet.dat file is not encrypted by the Bitcoin program by default but the most current release of the Bitcoin client provides a method to encrypt with a passphrase the private keys stored in the wallet. Anyone who can access an unencrypted wallet can easily steal all of your coins. Use one of these encryption programs if there is any chance someone might gain access to your wallet.<br />
* [http://www.7-zip.org/ 7-zip] - Supports strongly-encrypted archives.<br />
* [http://www.axantum.com/axcrypt/ AxCrypt by Axantum]<br />
* [http://lrzip.kolivas.org lrzip] - Compression software for Linux and OSX that supports very high grade password protected encryption<br />
* [http://www.truecrypt.org/ TrueCrypt] - Volume-based on-the-fly encryption (for advanced users)<br />
<br />
There is also a list of [[OpenSourceEncryptionSoftware|open source encryption software.]]<br />
<br />
Decrypting and encrypting the wallet.dat every time you start or quit the Bitcoin client can be ''tedious'' (and outright error-prone). If you want to keep your wallet encrypted (except while you're actually running the Bitcoin client), it's better to relegate the automation to a [http://lorelei.kaverit.org/bitcoin.sh small shell script] that handles the en/decryption and starting up Bitcoin client for you (Linux and OSX). <br />
<br />
There is also a method to print out and encrypt your wallet.dat as a special, scannable code. See details here: [[WalletPaperbackup]]<br />
<br />
==== Password Strength ====<br />
Brute-force password cracking has come a long way. A password including capitals, numbers, and special characters with a length of 8 characters can be trivially solved now (using appropriate hardware). The recommended length is '''at least''' 12 characters long. You can also use a multi-word password and there are techniques to increase the strength of your passwords without sacrificing usability. [http://www.baekdal.com/tips/password-security-usability The Usability of Passwords] <br />
<br />
However, simply using dictionary words is also insecure as it opens you up to a dictionary attack. If you use dictionary words, be sure to include random symbols and numbers in the mix as well.<br />
<br />
If you use keyfiles in addition to a password, it is unlikely that your encrypted file can ever be cracked using brute-force methods, even when even a 12 character password might be too short.<br />
<br />
Assume that any encrypted files you store online (eg. Gmail, Dropbox) will be stored somewhere forever and can never be erased.<br />
<br />
===== Choosing A Strong Password =====<br />
Make sure you pick at least one character in each group:<br /><br />
<br />
Lowercase: abcdefghijklmnopqrstuvwxyz<br />
Uppercase: ABCDEFGHIJKLMNOPQRSTUVWXYZ<br />
Number: 1234567890<br />
Symbol: `~!@#$%^&*()-_=+\|[{]};:'",<.>/? (space)<br />
<br />
<9 char = unsuitable for use<br />
09 char = insecure<br />
10 char = low security<br />
11 char = medium security<br />
12 char = good security (good enough for your wallet)<br />
13 char = very good, enough for anything.<br />
<br />
You might want to read [http://security.stackexchange.com/questions/662/what-is-your-way-to-create-good-passwords-that-can-actually-be-remembered What is your way to create good passwords that can actually be remembered?] and [http://security.stackexchange.com/questions/6095/xkcd-936-short-complex-password-or-long-dictionary-passphrase XKCD #936: Short complex password, or long dictionary passphrase?]<br />
<br />
== Backing up your wallet ==<br />
See [[Backingup_your_wallet|Backing up your wallet]].<br />
<br />
==Erasing Plain-text Wallets==<br />
<br />
In most operating systems, including Windows, Linux, and Mac OS X, simply deleting a wallet.dat file will ''not'' generally destroy it. It is likely that advanced tools can still be used to recover the wallet.dat file, even after it has been deleted.<br />
<br />
The Linux '''shred''' command can be used to overwrite the wallet file with random data prior to deleting; this particular copy of the file will then be practically impossible to recover. Using shred (and similar tools on Windows) however does not guarantee that still other copies don't exist somewhere hidden on your HD. That will depend on your system configuration and what packages you have installed. Some system restore and backup tools, for instance, create periodic snapshots of your filesystem, duplicating your wallet.dat.<br />
<br />
In Mac OS, the equivalent of '''shred''' is '''srm''' (introduced in Leopard). Using the Finder to remove files, clicking "Secure Empty Trash" in the Finder menu will shred the contents of the trash can. As with any OS this doesn't guarantee that there are not other copies elsewhere on your system.<br />
<br />
For Windows, the built-in command ''cipher /W'' will shred all previously-deleted files. [http://www.cylog.org/utilities/cybershredder.jsp CyberShredder] can securely deleted individual files.<br />
<br />
==Online and Mobile Wallets==<br />
<br />
Thus far, this article has been discussing the security of a wallet file for Bitcoin-QT or bitcoind that is under your sole control. Additional wallets applications and services have become available that offer other features and more convenience but not without introducing additional risk. When storing bitcoins with an [[eWallet]] such as Instawallet or Easywallet, you are essentially storing your private keys or wallet with that provider. <br />
<br />
Online wallets have a number of pros and cons to consider. For example, you can access your wallet on any computer in the world, but depending on the service, your bitcoins may be lost if the service is compromised. <br />
<br />
Mobile wallet applications are available for Android devices that allow you to send bitcoins by QR code or NFC, but this opens up the possibility of loss if mobile device is compromised. It may be possible to encrypt and backup the wallet or private keys on a mobile device but it is not advisable to store a large amount of bitcoins there without doing your own research and testing.<br />
<br />
==See Also==<br />
<br />
* [[Data directory]]<br />
* [[How to import private keys]]<br />
* [http://bitcoinx.io/wallets/ Where to get a Bitcoin wallet]<br />
* [http://startbitcoin.com/how-to-create-a-secure-bitcoin-wallet/ Secure Bitcoin Wallet Tutorial]<br />
* [[How to set up a secure offline savings wallet]]<br />
* [http://arimaa.com/bitcoin/ Bitcoin Gateway - A Peer-to-peer Bitcoin Vault and Payment Network]<br />
* [http://blog.cyplo.net/2012/04/01/bitcoin-wallet-recovery-photorec/ Find lost wallet eg. after disk format, using Photorec]<br />
* [https://docs.google.com/document/d/1dNZ7N_lQXHQp0jWkeN7dW4bWNMpcTBRM4iEoSuQwLho/edit# The Ultimate Guide to Web Wallet Security]<br />
<br />
[[Category:Security]]<br />
<br />
[[de:Sichere deine Geldbörse]]<br />
[[ru:Bitcoin и безопасность]]<br />
[[es:Cómo asegurar su monedero]]<br />
[[zh-cn:保护你的钱包]]</div>Ripper234https://en.bitcoin.it/w/index.php?title=Ron_Gross&diff=48103Ron Gross2014-06-11T20:59:21Z<p>Ripper234: </p>
<hr />
<div>[[image:Ron Gross.jpg]]<br />
<br />
Ron has graduated from the Technion with an M. Sc in Computer Science.<br />
He has worked at several companies, ranging from small startups to Google,<br />
and has an extensive experience in web architecture, security, and algorithms.<br />
<br />
Ron has been continuously involved with Bitcoin since March 2011,<br />
spreading the word, knowledge, and love of Bitcoin. He is a firm advocate of <br />
open source, transparency and decentralization of power and technology.<br />
Ron co-founded the Israeli Bitcoin community and foundation and is a board member of the [[Mastercoin Foundation]].<br />
<br />
He was a partner in [[Bitcoil]], the first Israeli exchange.<br />
<br />
He briefly worked on [[Bitblu]] in the summer of 2013.<br />
<br />
As of June 2014 Ron is the Co-Founder and Executive Director of the [[Mastercoin]] project.<br />
<br />
You can reach Ron at:<br />
* ron@mastercoin.org<br />
* skype - ripper234<br />
* [https://www.sococo.com/web/join/bg0gjoqu5xv0tvq62pud1mz21 Sococo]<br />
<br />
See also read [http://ripper234.com/about the about page on his blog].<br />
<br />
[[Category:People]]</div>Ripper234https://en.bitcoin.it/w/index.php?title=Conferences&diff=48042Conferences2014-06-10T08:52:26Z<p>Ripper234: /* Israel July 2014 */</p>
<hr />
<div>Please announce new conferences on [https://bitcointalk.org/index.php?topic=238093 bitcointalk].<br />
Also you can [https://github.com/bitcoin/bitcoin.org/tree/master/_events submit a pull request on bitcoin.org] ([https://github.com/bitcoin/bitcoin.org#events see doc])<br />
<br />
== Forthcoming Conferences ==<br />
<br />
=== Miami Jan 25-26 2014 ===<br />
January 25 & 26, 2014 Miami Beach Convention Center in South Beach<br />
http://btcmiami.com<br />
https://bitcointalk.org/index.php?topic=330061<br />
<br />
=== Berlin Feb 12-13 2014 ===<br />
[http://insidebitcoins.de/en/?c=bcoinberlpage Inside Bitcoins Berlin]<br />
<br />
=== Austin March 6 2014 ===<br />
[http://texasbitcoinconference.com/ Texas Bitcoin Conference]<br />
<br />
=== New York March 12 2014 ===<br />
[http://www.themankoffcompany.com/CryptocurrenciesNYMarch2014 The Mankoff Company New York]<br />
<br />
=== San Francisco March 20 2014 ===<br />
[http://www.themankoffcompany.com/CryptocurrenciesSanFranMarch2014<br />
The Mankoff Company San Francisco]<br />
<br />
=== London, April 3, 2014 ===<br />
[http://www.themankoffcompany.com/CryptocurrenciesLondonApril2014 The Mankoff Company London]<br />
<br />
=== New York April 7-8 2014 ===<br />
[http://www.mediabistro.com/insidebitcoins/new-york/ Inside Bitcoins New York]<br />
<br />
=== Toronto April 11th-13th 2014 ===<br />
[http://www.bitcoinexpo.ca/ Bitcoin Expo 2014]<br />
<br />
=== Holland May 15-17 2014 ===<br />
[https://bitcointalk.org/index.php?topic=343065 Bitcoin 2014], organized by the Bitcoin Foundation<br />
<br />
=== Washington June 20-22 2014 ===<br />
[http://www.bitcoinbeltway.com/ Beltway]<br />
<br />
=== Hong Kong June 24-25, 2014 ===<br />
TBD<br />
<br />
=== Israel July 2014 ===<br />
[Inside Bitcoins, July 28-29](http://bitcointlv.com/en/)<br />
<br />
=== Black Rock City,Nevada - August 25th - September 1st 2014 ===<br />
[http://campbitcoin.hivewallet.com/ Camp Bitcoin]<br />
<br />
=== London September 10, 2014 ===<br />
TBD<br />
<br />
=== Las Vegas October 6-7, 2014 ===<br />
TBD<br />
<br />
=== Israel 3-4 November 2014 ===<br />
TBD<br />
<br />
== Past Conferences ==<br />
* [http://www.bitgroups.org Bitcoin & Future Technology], European Conference, Prague, November 25 - 27, 2011<br />
* [http://bitcoin.uni-rostock.de Bitcoin Tutorial and Workshop], Annual Meeting of the German Computer Science association GI, Braunschweig, September 20, 2012.<br />
* [http://bitcoin2012.com Bitcoin Conference], London, 2012.<br />
<br />
==See Also==<br />
<br />
* [http://bitcoin.org/en/events Events] on Bitcoin.org website<br />
* [https://bitcointalk.org/index.php?topic=238093 List of conferences thread on bitcointalk]</div>Ripper234https://en.bitcoin.it/w/index.php?title=Bitcoin_Wiki:Issue_Tracker&diff=48002Bitcoin Wiki:Issue Tracker2014-06-08T06:10:37Z<p>Ripper234: </p>
<hr />
<div>This page serves as the Wiki issue tracker. <br />
<br />
To file a new issue, add a second-level heading (==), and describe your issue in detail.<br />
<br />
Issue discussion should happen on the Talk page.<br />
<br />
Do not delete resolved issues unless you are a wiki administrator, or the creator of the issue.<br />
<br />
== Presented with SSL cert from another site ==<br />
<br />
A few times on 2014-03-27, non-deterministically across a few pages, I got the typical "wrong SSL cert" warning from Firefox, saying I'd been delivered the cert for '''kitchensurfing.com''', issued the same day.<br />
<br />
== Backup site broken ==<br />
<br />
dump.bitcoin.it just goes to the Main Page<br />
<br />
== Bitc<b></b>oin:* namespace interwiki links broken ==<br />
<br />
Links to [[Bit<b></b>coin:Community portal]] (for example) get turned into broken bitcoin: URI links.<br />
<br />
== Make the anti-spam payment system more discoverable ==<br />
I understand that [[Cryptopay]] is [being replaced](http://www.reddit.com/r/Bitcoin/comments/27lofu/dear_bitcoin_foundation_please_take_ownership_of/ci20i6t). Can you give us more details on that? The new system should be more discoverable by new users - I suggest a notification for every new user on how to edit. (people still ask me how to edit the damn thing).<br />
<br />
== Require a fee for new user registration ==<br />
There is still a big spam problem in the [https://en.bitcoin.it/w/index.php?title=Special:RecentChanges&limit=500 Recent Changes page].<br />
<br />
== Use a proper issue tracker ==<br />
I know you like wikis ... but can't we use something like Zendesk to track issue?<br />
Wikis weren't designed to be issue trackers...</div>Ripper234https://en.bitcoin.it/w/index.php?title=Proof_of_Publication&diff=47904Proof of Publication2014-06-05T03:46:36Z<p>Ripper234: </p>
<hr />
<div>{{stub}}<br />
<br />
A method that uses Bitcoin or Bitcoin-like technologies to authenticate that a certain information was published at a certain date, or was known at a certain date.<br />
<br />
The technique entails encoding the secure hash of a certain publication (plaintext) inside the Bitcoin blockchain. It was probablly first described in the paper from 2012 titled "CommitCoin: Carbon Dating Commitments with Bitcoin" ([http://people.scs.carleton.ca/~clark/papers/2012_fc.pdf extended abstract] and [http://eprint.iacr.org/2011/677.pdf technical report]).<br />
<br />
== Relevant website ==<br />
* [http://proofofexistence.com/ proofofexistence.com] - Store hashes of data in the blockchain.<br />
* [http://coinsecrets.org/ coinsecrets.org] - list of metadata recently embedded in the bitcoin blockchain using OP_RETURN outputs.<br />
<br />
[[Category:Proof-of-x]]</div>Ripper234https://en.bitcoin.it/w/index.php?title=List_of_companies_that_pay_employees_in_Bitcoin&diff=47875List of companies that pay employees in Bitcoin2014-06-04T08:37:00Z<p>Ripper234: </p>
<hr />
<div>{{stub}}<br />
<br />
A partial list of companies that either give the option to employees to get paid in Bitcoin, or just don't give a fiat option.<br />
<br />
Please add your company here<br />
<br />
* [https://blockchain.info/ blockchain.info] ([http://www.entrepreneur.com/article/234463 proof])<br />
* [http://mastercoin.org/ Mastercoin Foundation] ([https://docs.google.com/spreadsheet/ccc?key=0AtCyUJvk_IyNdGpVcnpBN2tOczFmbVRnck5TWjZuRFE&usp=sharing#gid=0 public ledger])<br />
* [http://bitshares.org/ BitShares] ([http://www.reddit.com/r/CryptoCurrency/comments/277ddr/blockchaininfo_ceo_we_pay_employees_in_bitcoin/chy7e88 proof])<br />
<br />
[[Category:lists]]</div>Ripper234https://en.bitcoin.it/w/index.php?title=List_of_companies_that_pay_employees_in_Bitcoin&diff=47874List of companies that pay employees in Bitcoin2014-06-04T08:36:44Z<p>Ripper234: Created page with "{{stub}} A partial list of companies that either give the option to employees to get paid in Bitcoin, or just don't give a fiat option. Please add your company here * [http..."</p>
<hr />
<div>{{stub}}<br />
<br />
A partial list of companies that either give the option to employees to get paid in Bitcoin, or just don't give a fiat option.<br />
<br />
Please add your company here<br />
<br />
* [https://blockchain.info/ blockchain.info] ([http://www.entrepreneur.com/article/234463 proof])<br />
* [http://mastercoin.org/ Mastercoin Foundation] ([https://docs.google.com/spreadsheet/ccc?key=0AtCyUJvk_IyNdGpVcnpBN2tOczFmbVRnck5TWjZuRFE&usp=sharing#gid=0 public ledger])<br />
* [http://bitshares.org/ BitShares] (http://www.reddit.com/r/CryptoCurrency/comments/277ddr/blockchaininfo_ceo_we_pay_employees_in_bitcoin/chy7e88 proof)<br />
<br />
[[Category:lists]]</div>Ripper234https://en.bitcoin.it/w/index.php?title=Proof_of_burn&diff=47850Proof of burn2014-06-02T20:36:27Z<p>Ripper234: </p>
<hr />
<div>'''Proof of burn''' is method for bootstrapping one cryptocurrency off of another. The idea is that miners should show proof that they ''burned'' some coins - that is, sent them to a verifiably unspendable address. This is expensive from their individual point of view, just like proof of work; but it consumes no resources other than the burned underlying asset. To date, all proof of burn cryptocurrencies work by burning proof-of-work-mined cryptocurrencies, so the ultimate source of scarcity remains the proof-of-work-mined "fuel".<br />
<br />
There are likely many possible variants of proof of burn. This page currently describes [[User:Ids|Iain Stewart]]'s version. Other people can add variant versions that still belong to the broad proof of burn idea.<br />
<br />
== Iain Stewart's version of proof of burn ==<br />
<br />
=== Introduction and motivation ===<br />
<br />
The key idea of proof-of-burn (this would also apply to proof-of-stake, by the way) is that when choosing the thing which is to qualify as a "difficulty", i.e. to require miners to exhibit proof that they've "done something that's tough to do", all that matters is that ''an individual miner'' finds the task expensive. (Well... it also matters that everyone else should find it cheap to verify that it has been done.) It doesn't need to be the case that real resources are consumed in the real economy.<br />
<br />
With proof-of-work, it so happens that real resources are indeed consumed - mining rigs are produced, with human labour and materials as input, electricity is used, and all these things have to be bid away from their real-economy best alternative uses. (Or, if they're produced ''in addition'' to what would have been produced, the total of leisure time is less than it could have been. Something real is grabbed as input.) And while a cryptocurrency is being set up (i.e. [the fast early phase of] its initial distribution) - or, more precisely, while ''the first'' cryptocurrency is being set up; more on this distinction later! - no good alternative has been proposed. (And I'm not proposing one.) But once a cryptocurrency is up and running, with its initial distribution close to completed, new possibilities arise, for tasks to "feel expensive" to a miner but not actually "be expensive" from a god-like whole-economy perspective.<br />
<br />
Proof-of-stake (of the "Cunicula variety", I mean) is in fact arguably already an example of such a task. It feels awfully expensive, to a miner, to save up a lot of bitcoins and become a big stakeholder; but from a whole-economy viewpoint, this is a swapping of assets' ownership labels around, it's not a burning of electricity or the like. However, I thought it would be interesting to invent a task that is absolutely, nakedly, unambiguously an example of the contrast between the two viewpoints. And yes, there is one: burning the currency!<br />
<br />
By "burning" a tranche of bitcoins I just mean sending them to an address which is unspendable. The precise technical details of this will vary from cryptocurrency to cryptocurrency. With Bitcoin, any address which is [the RIPEMD160/SHA256 hash of] a script that evaluates to false will do. So, the script should do a "deliberately silly" thing - instead of things like "check such-and-such signature, and put the validity result on the stack", it should do something like "add 2 and 2, and now check if what's on top of the stack is equal to 5". (Or just "push 4, and check if it's equal to 5". Anything of that sort.) There are thus an unbounded number of such scripts, with entropy saturating RIPEMD160 since you can choose big numbers to taste. So, bitcoins sent to such a txout can never be redeemed on a future txin. (Barring the cracking of RIPEMD160 and the finding of an alternative matching script, that is. If ''that'' happens, the cryptocurrency is in big trouble anyway!)<br />
<br />
With this definition of burning, it's not obvious to blockchain-watchers that some bitcoins ''have'' been burnt, at the time of burning. They've been sent to an address which doesn't stand out from any other. It's only later, when a miner who burned them earlier now wants to exhibit proof that "yes, these coins are burnt", that blockchain-watchers get their proof. (Which basically consists of exhibiting the script that manifestly always evaluates to false, and hashes to the address.) If it's thought desirable that the act of burning should be obvious right away, rather than later, then this can be achieved: burning merely needs to be defined as sending to some ''fixed'' unspendable address, with no variation - e.g. we could settle on the hash of "push 4, and check if it's equal to 5".<br />
<br />
So, miners are creating candidate winning blocks by saying to the listening world, not "Look! I've done this many trillion hashes! [or struck lucky with fewer: you, the listening world, wouldn't know the difference... but this doesn't matter...]", but rather "Look! Two months ago I burned this many bitcoins!". In both cases, "this many" means an adjustable difficulty parameter, which the network adjusts from time to time (fortnightly, in today's Bitcoin) to squeeze out marginal miners (and keep more-efficient-than-marginal ones in profit) to just the extent needed to regulate block creation to a preferred pace (one per 10 minutes, in today's Bitcoin).<br />
<br />
Why that phrase "Two months ago"? The broad principle is as follows. A miner mustn't be able to just burn some bitcoins ''right now'' and say "OK, I've burned them! Now let me have all those latest juicy transaction fees that have arrived in the past few minutes! Thanks!" That extremely recent act of burning could be undone in a block chain reorganisation; and then the same miner would be able to "re-burn" those same coins in an attempt to grab a block afresh, post-reorganisation. That would constitute a breakdown in the analogy of burning with proof-of-work hashing. A trillion proof-of-work hashes on a pre-reorg block are of no value on the post-reorg chain. A proof-of-work miner must simply shrug and say "Oh well, that's those expenses [electricity, mining rig rental / imputed rental,...] lost and gone... time to try again!" And that's the way things should be, for security - it '''should not''' be as cheap to extend the height of two or more competing chains as it is to focus on one. (And having decided to focus on one, a miner ''should'' incur a risk of lost expense if their choice turns out to be "the wrong one" in network consensus terms.)<br />
<br />
The above point makes it clear why the act of burning should be a decent interval earlier than the act of exhibiting proof. Two months may be overdoing it, but the protocol should require it to be sufficiently far back that there's no practical possibility of it being undone. There are in fact some further issues, to do with making sure it's not cheap for a miner to ''re-exhibit'' their proof (of having performed a suitably substantial burn a suitably long time ago) on multiple competing chains. Details to follow.<br />
<br />
Now then! How much burning will actually happen, under this protocol? The answer is straightforward enough, though its implications are quite broad and in some ways surprising. Miners will burn bitcoins at an average rate '''very close to''' the average rate that ordinary users are sending them fees (and any coin-minting still going on too of course), minus the miners' true real-resource costs (i.e. the hardware and electricity and the like for handling transactions and blocks and burn proofs - these costs will be far lower than the hashing costs incurred under proof-of-work, but of course still non-zero). This follows by the same sort of "approach to equilibrium" reasoning that tells us that miners will ''expend real resources on proof-of-work'' to roughly that extent - if they didn't, mining would be supra-normally profitable, and new entrants would be attracted into the trade. If burning coins, rather than buying a lot of kit from a mining rig supplier, is the expense incurred by a miner to compete for the revenue stream, the same economic principles apply.<br />
<br />
=== Technical sketch of proof of burn: "Burnt coins are mining rigs!" ===<br />
<br />
''Iain Stewart writes:'' In this subsection I give a provisional technical sketch of the operational details of the proof-of-burn protocol I've currently settled on. It can be summed up in the following pithy slogan:<br />
<br />
'''''"Burnt coins are mining rigs!"'''''<br />
<br />
What that slogan means will become clear as I go on. Basically, proof-of-work is so elegant, in so many different ways, excepting its high real-resource cost, that I decided my attempt at an alternative to it, avoiding its real-resource cost, should mimic it as faithfully as possible in every other aspect. Well, only readers can judge whether I've succeeded!<br />
<br />
The key is to use a '''stream of true randomness''' - see below for where ''that'' comes from! - to simulate the generating of random hashes that a real proof-of-work mining rig would produce. Now, obviously we don't want to "simulate" every actual hash! A "simulation" of proof-of-work at ''that'' level of detail would just ''be'' proof-of-work! Rather, we want to mimic the statistical properties of a mining rig's stream of hashes, to just the level of detail required to give the same sort of pattern of meeting / not meeting a moving difficulty target, and all the rest of it, that we get with the real thing.<br />
<br />
So: first of all, what exactly is my "stream of true randomness"? Chop up time into units considerably shorter than the intended inter-block time, but with no need to go much finer than general network latency. (Seconds will do, I think.) For each second, t, we need a uniform random number between 0 and 1 assigned to it, RAND(t). This sounds as if we need some awful dependency on a fragile central source - some high-powered laser at NASA pouring out quantum noise every second, or something - with all the trust and failure issues that would imply. Fortunately, for simulating mining rigs, we don't need anything like that. All that matters is that, to someone "buying a simulated mining rig" (burning some bitcoins, that is!) at time t, they can't predict the value of RAND(any t' 2 months or more to the future of t). [Where "2 months" means the dead time a burnt coin must wait before it becomes a simulated active mining rig. See introductory motivating section above. It's basically just a generous waiting period to make sure a burnt coin is truly definitely burnt, and won't have any chance of being "unburnt" in a chain reorg, by the time it comes into use in mining.] We do '''not''' need fresh statistical independence of RAND(t) w.r.t. all of RAND(t-1), RAND(t-2), RAND(t-3), etc. (And we don't mind if the stream is known a "short" time into the future - e.g. a week or two; at any rate a small portion of the waiting period.)<br />
<br />
Such a lesser goal can, I believe, be achieved with just a few tens of bits of true randomness per week. Quality is what matters, not quantity! I suggest tapping into the world's most highly-audited source of low-bit-rate true randomness: lotteries. These (the big reputable ones anyway) are already subject to elaborate inspection of the machinery that tosses the balls around and draws some of them out. And the results are publicised so widely, in so many newspapers, TV channels, websites etc, as to make it impossible for anyone to lie about them.<br />
<br />
Roughly weekly, a config-file (lottery-results.dat or whatever) should get "the latest lottery results" appended to it. There is no hurry about this, it doesn't need to be exactly every week, or even the same lottery every time, it just needs several tens of bits of fresh lottery data added roughly weekly. I believe there would be no trouble propagating this to all nodes, by out-of-band means if necessary. The format should be utterly simple and transparent, a 1-line plain text description of the results and the timestamp (t in RAND(t)) from which they are to be paid attention to, onwards. Like this:<br />
<br />
.<br />
.<br />
.<br />
for use from 2013-06-24 00:00:00 onwards: UK national lottery 2013-06-12: 4 9 20 22 37 42, bonus ball 19<br />
for use from 2013-07-01 00:00:00 onwards: UK national lottery 2013-06-19: 7 12 14 19 33 41, bonus ball 28<br />
<br />
(Obviously the meta-level words "for use from... onwards" aren't really needed - I just put them in for clarity.) Each line is added in a leisurely, unhurried fashion, at some time (it doesn't matter when) between the draw and the intended start-paying-attention-to-it date. (Some time between 2013-06-19 and 2013-07-01 00:00:00, in the case of the example last line above.) This gives plenty of time for people to add it themselves, from their favourite news source, and check by out-of-band means that they've added what everybody else has added, right down to spelling and punctuation. (Which in practice probably means copying it from somewhere. The point is, the "somewhere" doesn't need to be trusted - a lie, or an unexpected variation in format or spelling or punctuation, would be called out well within the leisurely timescale.)<br />
<br />
RAND(t) is then HASH(config-file [excluding any lines that are "for use from ''time later than t'' onwards" of course], plus t itself [in some standard format, e.g. 2013-07-02 23:14:05, or just the Unix numeric time] as a final line). - Or if you like, HASH(HASH(config-file) ++ t), for efficiency. (Where "++" means "append together in some standard fashion".) "HASH()" is your favourite hash function, e.g. SHA256(SHA256()). Thus RAND(t) is a 256-bit integer, which we regard conceptually as a real number between 0 and 1 by putting a binary point in front.<br />
<br />
(I'm aware that people on the forums are coming up with randomness protocols for proof-of-stake, proof-of-activity and the like which ''don't'' involve external true randomness like lotteries - they just hash the last hundred blocks' hashes together, or something like that. I don't think this is good enough. [For their application or for mine!] Someone producing the latest block, given the previous 99, can privately produce billions of cheap variations on it, by varying the order the transactions are listed etc, until they find, and publish, the one that "games" the randomness in their favour. However, if I'm wrong about this, and hashing the last hundred blocks is in fact fine, then good! We can drop the lottery rigmarole! Anyway, for the rest of this description, I'll simply assume that RAND(t) becomes available for all t, but remains unknown until a week or two before t, and in particular, RAND(2 months or more from now) is "massively unknown" right now - unknown with many tens to hundreds of bits of unknowable future entropy. That's all that matters for turning burnt coins into simulated mining rigs.)<br />
<br />
Right then! What do we do with this RAND(t) stream? We simulate the capricious behaviour of a true proof-of-work mining rig! Let us assume that, in the real proof-of-work world, you can buy an h hashes/second mining rig for b=c*h BTC. (c varies with technical progress, BTC price fluctuations, etc; but in the simulated world it can just be left constant.) Or, inverting this, if you spend b BTC, you acquire a mining rig of h=b/c hashes/s power. Now, what does it actually mean for your rig to perform h hashes during 1 second? It means you're producing h uniform random numbers between 0 and 1. (That binary point again!) But you don't really care what they all are individually - how well you did during that 1 second is defined as "what was the '''lowest''' hash value you produced during that 1 second?". This is then inspected for whether it beats [is lower than] the network's current target; or, perhaps, whether it beats the lesser [i.e. numerically greater] target of a pooled mining operation. If it's good enough, that precious lowest hash is published to the network (or mining pool), and the others are just thrown away (not published). If it's not good enough, even the [not-so-]precious lowest hash isn't published - and certainly not the others. So, in the simulation, we only need to produce, for each second, a simulated "lowest hash for that 1 second". The "others" don't have to exist at all!<br />
<br />
For reproducing (statistically) the pattern of hits and misses w.r.t. targets tough enough to not be achieving several hits within 1 second, and for h>>1, we can take the simulated lowest hash for time t to be (1/h) * HASH(signatures-of-the-act-of-burning-the-b-BTC ++ RAND(t)). [In fact this even works for h<1, despite the rather surreal appearance of "lowest hashes" >1 every so often in that case - i.e. values outside the range that ''real'' lowest (or any other!) hashes can ever actually be: it turns out this surreal behaviour is just what's needed to degrade the probability of beating the target by just the right amount. Values >1 in effect represent "I didn't generate any hashes at all during this particular 1-second window".]<br />
<br />
Two further subtleties. First of all, it turns out to be desirable to include the block number (chain height @ 1 per block) in the formula - just to keep the owners of simulated mining rigs "on their toes" and not be able to tell a week or so in advance when they'll be lucky. (This encourages them to run a continuous full node. Maybe that's not in fact that important.) So we take simulated-lowest-hash = (1/h) * HASH(signatures-of-the-act-of-burning-the-b-BTC ++ block-number-of-would-be-block ++ RAND(t)). (We should '''not''' include finer details of the block, to avoid "gaming" a la the hundred blocks business I mentioned earlier. - Or if I'm wrong about that, then OK, by all means mix in finer details of the block!)<br />
<br />
Secondly, it turns out that to keep the burning process going forever, rather than a pulse of initial burning that no-one ever again wants to contribute further burning to, we should simulate one more property of real-world mining rigs: they break down! That is, we should demurrage away the strength of a simulated mining rig. (A plea to the reader: Don't be alarmed by the word "demurrage". This is '''burnt''' coins I'm talking about - they ''should'' be treated "harshly", in whatever style mimics real-world mining rigs to the required fidelity. Ordinary unburnt coins are not being demurraged! [Unless that's independently desirable as a policy matter, e.g. if it's felt that network strength can only be achieved via more revenue for miners than fees alone will ever provide.]) A real mining rig likely works at full tilt for a few years and then conks out. We ''could'' demurrage each burnt coin in that style - it abruptly expires E years after its creation - but I think a smooth exponential demurrage is nicer, i.e. its burnt value after y years is b'=b*exp(-y/E). Thus h = b'/c = (b/c)*exp(-y/E). [And 1/h = c/b' = (c/b)*exp(y/E).]<br />
<br />
Taking these two further subtleties into account, we get the following formula:<br />
<br />
simulated-lowest-hash(t) = (c/b)*exp([t - t_burning]/E) * HASH(signatures-of-the-act-of-burning-the-b-BTC ++ block-number-of-would-be-block ++ RAND(t)).<br />
<br />
So there you have it! With this formula, life as a miner is spookily similar to the real proof-of-work case. You "buy a mining rig" - you burn coins, and that hits ''you'' in exactly the way sending off money to a chip supplier would have hit you, even though over the whole economy, no real resources have been expended - and you then hope that, by submitting lucky hashes to the network in the form of blocks, you can make more back in fees over time than you spent initially. If you don't keep connected to the network, you won't know what transactions are eligible for including in your next would-be block, and your next lucky hash will run to waste. Meanwhile, other people are "buying mining rigs" (burning coins) too, either freshly or to make up for the "wearing out" of their existing ones; and the network is adjusting its target hash value [reciprocal difficulty] to regulate the rate all this mining effort is producing blocks at, to some preferred average rate. All spookily normal, in other words!<br />
<br />
Now, I'm being a little bit disingenuous to say that ''everything'' is normal. We need protection against certain things (use of a lucky hash on two or more competing chains; timestamp-falsification abuse) which either do not exist at all under true proof-of-work - the former - or exist but with the consequences and mitigation strategy being different in detail - the latter. I believe I have a way of standing up to the various forms of malice we need to worry about of those kinds. More to follow soon hopefully!<br />
<br />
=== Economic implications ===<br />
<br />
The key insight is that verifiably, publicly burning some coins of a known-total-stock-issued currency is the same as "remurrage" (opposite of "demurrage" - it may not be a correct word, but it's a nice back-formation) on the remainder. That is, if there are verifiably 21 million issued-and-not-burned coins, and then you go to sleep and wake up later and there are now only 20 million issued-and-not-burned coins, that's the same as if some magic genie multiplied all wake-up-time nominal bitcoin figures by 21/20. Another way to see the identity of real effect would be to redefine "burning n bitcoins" to mean, not "sending n to an unspendable address", but rather "scattering" the n bitcoins, i.e. sending them to '''every existing''' [non-zero-balance] address, in proportion to the balance [sum of unspent txouts] already stored in each. This would be a horribly gigantic transaction to actually do explicitly, but the point is, burning can be thought of "as if" done that way. (Slogan: Quantity-deflation is remurrage in disguise, in exactly the same way that quantity-inflation is demurrage in disguise.)<br />
<br />
So, what ''that'' means is, if while you're sleeping you (a non-miner) hold 1 bitcoin purely passively, i.e. it just sits undisturbed on the blockchain, well, when you wake up, it's as if you've received a "dividend" (of 5% in the particular numeric example above) on top of the general economy-tracking price we expect of a constant-quantity currency. In a world with actual, visibly performed remurrage, this is made explicit - your balance is now 21/20, with the nominal circulation [issued-and-not-burned, and remurraged for good measure] constant at 21 million. You can go and spend the 1/20 "dividend" on some treat, and still have the same fraction (1 out of 21 million) of the money stock as when you went to sleep.<br />
<br />
In a world ''without'' any attempt at explicit remurrage, the real facts of the situation are (of course!) the same, but their nominal expression is not perhaps so instantly obvious. Your nominal holding is unchanged at 1; but this is now 1 part in 20 million of the whole money stock, not the 1 part in 21 million it was before. So, you can go and spend 1/21 of it on some treat, taking your nominal balance down to 20/21, and ''that'' nominal balance is the same (1 out of 21 million) fraction of the money stock as when you went to sleep.<br />
<br />
So, basically, if you're holding bitcoins and trying to hold an "economy-tracking amount", no more and no less, you find you can go out into the market and use the fraction of your holdings that counts as "dividend above and beyond economy-tracking" on some treat or other. (Indeed, "you can go out..." should read "you ''must'' go out...", if you're really determined to pursue precisely that tracking strategy.)<br />
<br />
Who's selling you the real resources embodied in the "treat"? And what's ''their'' motive? Well, transaction fee payers presumably like to re-stock their bitcoin real balances to roughly the same [economy-tracking] level as before, on average - they're paying for the transaction processing as a service. These fees are then burned by miners. (Well, not literally the fees themselves - the fees themselves are ''collected'' by miners, but the way they achieve this is to burn an approximately equal amount, as explained earlier.) So, ordinary Bitcoin users, to achieve their desired re-stocking, have to either produce slightly more, or consume slightly less, or a proper or improper mixture thereof, than they would have needed to in a hypothetical (presumably impracticable) alternative world where they pay no fees for their everyday transactions (and some magic mining-god just altruistically and reliably creates a blockchain out of all the transactions, without charging anybody anything). [This follows directly from their re-stocking desire, and has nothing to do with proof-of-burn specifically. That is, they have to do this regardless of whether the protocol is proof-of-work, proof-of-stake, proof-of-burn or whatever.] It's that extra gap between production and consumption - "extra" on top of whatever gap people are already choosing as a real saving[/dis-saving] strategy - that goes on to the market, for you and all other bitcoin holders to bid off the market by spending on your "treat".<br />
<br />
This whole stable pattern of spending habits is, perhaps surprisingly, the same pattern of real resource allocation as would have happened if Cunicula's proof of stake (with close to 100% stake / 0% work admixture) had been in operation, and all bitcoin holders, large and small, had enthusiastically thrown their bitcoins (that is, their stream of bitcoin days destroyed) into the stake-claiming process. The fraction of fees they'd collect if they did that would be just like the "dividend" as I called it above - it would be like explicit remurrage, except instead of being automatic, it would require each holder's active participation (i.e. they couldn't just go to sleep, unless they left some sort of "trusted bot" running and using their private keys to sign their stream of bitcoin days destroyed). So, if you like, proof-of-burn is like automated, 100%-stakeholder-participation Cunicula-style proof-of-stake!<br />
<br />
Incidentally, it's also fascinating to consider what happens if the community does decide a demurraging of [ordinary, unburnt] coins, the revenue being added as a coin-[re-]minting stream to the flow of fees, ''is'' necessary to continue with forever, for the sake of network strength. The amazing answer, as far as I can honestly work out, is that in long-run equilibrium, the burn rate is just such as '''to make hardly any of this demurrage ''real'' demurrage at all!''' [The implicit remurrage of burning almost exactly cancels the explicit demurrage of network-strengthening coin-[re-]minting! (Or if you like, the implicit demurrage of inflationary fresh-coin-minting.) Either way, we ''seem'' to get the possibility of amazing network strength "for free"!] This opens up the shocking possibility of turning up the demurrage/inflation rate to startlingly high levels - 5% of money stock / year, 10% of money stock / year... levels that would bring the whole cryptocurrency into disrepute in the true proof-of-work case, since coin-holders really would suffer that actual amount of explicit or implicit demurrage - and yet '''not''' hitting coin-holders with more than a frictional residual fraction of that ''in real terms'' at all, because of the way burning simulates remurrage! Extraordinary stuff! I plan to say more about this soon - but this quick teaser description should already be food for thought.<br />
<br />
=== Coin-burning as a tool for transition between cryptocurrencies ===<br />
<br />
Proof of burn may also be of interest as a tool for managing an orderly transition from one cryptocurrency ("oldcoin", let's call it) to another ("newcoin"). If the developers of newcoin are looking for a way of avoiding proof-of-work's real resource consumption '''even in newcoin's initial distribution phase''', they can't use proof of newcoin-burn: newcoins don't exist yet. But they ''can'' use proof of oldcoin-burn! (Assuming their reason for creating newcoin is '''not''' a doubting of oldcoin's security model, anyway. - Or at least, not a doubting severe enough to affect sufficiently deeply buried oldcoins, these being the candidates for burning.)<br />
<br />
The newcoin blockchain would thus start with (at least a hash referring to) a complete catalogue of all the [sufficiently deeply buried] unspent txouts of oldcoin. Miners would then exhibit burning events within oldcoin up to a certain date; after which, the protocol would switch to burning of newcoin itself (and the dependency on oldcoin could even be thrown away entirely, if a checkpoint of that transition moment was promulgated and accepted by the newcoin community).<br />
<br />
This has the nice consequence that, if people throughout the broader economy are gradually deserting oldcoin (as newcoin catches on), '''''its value need not collapse!''''' Instead, oldcoin gets burnt in the transition process, neatly reducing its nominal supply in just such a way as to roughly keep pace with its declining real demand. Meanwhile, those same acts of burning are minting fresh newcoins, at just the pace required to keep up with newcoin's ''growing'' real demand. (At least, that's the case if miners anticipate the transition speed correctly, and enter / exit the coins' respective mining trades at a pace that competes away supra-normal profits. We also have to assume that the ''total'' real demand for both[/all...] cryptocurrencies is roughly stable in "economy-tracking" terms; or at least, that miners anticipate the time path of the size of total real demand, and of its currency-by-currency composition, correctly, or near enough correctly.)<br />
<br />
'''To sum up:''' proof of burn ''could'', just maybe, qualify as a new tool to greatly assist overall (multi-cryptocurrency) economic robustness and stability!<br />
<br />
== Earlier work suggesting a role for the burning of coins ==<br />
<br />
[https://bitcointalk.org/index.php?topic=131139.msg1404195#msg1404195 Forum member ripper234 points out] an earlier work by forum member [https://bitcointalk.org/index.php?action=profile;u=3313 dacoinminster] suggesting coins could be burnt as one component of a broader protocol. [https://bitcointalk.org/index.php?topic=56901.0 The earlier work] is [http://bitcoin.stackexchange.com/questions/2458/is-dacoinminsters-second-bitcoin-whitepaper-logically-economically-consistent discussed on StackExchange]. It revolves around a centralised "trusted entity" system, and so is not directly comparable to decentralised proof-of-burn mining; but it may be of interest to some readers.<br />
<br />
== See also ==<br />
*[[Proof_of_work|Proof of work]]<br />
*[[Proof_of_Stake|Proof of stake]]<br />
<br />
[[category:mining]]<br />
[[category:proof-of-x]]</div>Ripper234https://en.bitcoin.it/w/index.php?title=Proof_of_Stake&diff=47849Proof of Stake2014-06-02T20:35:55Z<p>Ripper234: </p>
<hr />
<div>Proof of Stake is a proposed alternative to [[Proof of Work]]. Like proof of work, proof of stake provides a mechanism for determining who signs bitcoin transactions (see [https://bitcointalk.org/index.php?topic=68213.0 "main" bitcointalk thread], and a [https://bitcointalk.org/index.php?topic=96854.0 Bounty Thread]).<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 "Proof of Stake blocks".<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 >= 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<s<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="wikitable"<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 "the wrong version" - 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 />
== Peeroin ==<br />
[http://ppcoin.org Peercoin] is the first known implementation of a combined PoS/PoW system (released August 19 2012).<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>Ripper234https://en.bitcoin.it/w/index.php?title=Category:Proof-of-x&diff=47848Category:Proof-of-x2014-06-02T20:35:27Z<p>Ripper234: Created page with "Various methods of using blockchain technologies to prove something in a way that is cryptographically verifiable."</p>
<hr />
<div>Various methods of using blockchain technologies to prove something in a way that is cryptographically verifiable.</div>Ripper234https://en.bitcoin.it/w/index.php?title=Proof_of_work&diff=47847Proof of work2014-06-02T20:34:53Z<p>Ripper234: </p>
<hr />
<div>A '''proof of work''' is a piece of data which was difficult (costly, time-consuming) to produce so as to satisfy certain requirements. It must be trivial to check whether data satisfies said requirements. Producing a proof of work can be a random process with low probability, so that a lot of trial and error is required ''on average'' before a valid proof of work is generated. Bitcoin uses the [[Hashcash]] proof of work.<br />
<br />
One application of this idea is using [http://en.wikipedia.org/wiki/Hashcash hashcash] as a method to preventing email spam, requiring a proof of work on the email's contents (including the To address), on every email. Legitimate emails will be able to do the work to generate the proof easily (not much work is required for a single email), but mass spam emailers will have difficulty generating the required proofs (which would require huge computational resources).<br />
<br />
Hashcash proofs of work are used in Bitcoin for block generation. Proofs of work that are tied to the data of each block are required for the blocks to be accepted. The [[difficulty]] of this work is adjusted so as to limit the rate at which new blocks can be generated by the network to one every 10 minutes. Due to the very low probability of successful generation, this makes it unpredictable which worker computer in the network will be able to generate the next block.<br />
<br />
For a block to be valid it must hash to a value less than the current [[target]]; this means that each block indicates that work has been done generating it. Each block contains the hash of the preceding block, thus each block has a [[block chain|chain]] of blocks that together contain a large amount of work. Changing a block (which can only be done by making a new block containing the same predecessor) requires regenerating all successors and redoing the work they contain. This protects the block chain from tampering.<br />
<br />
== Example ==<br />
<br />
Let's say the base string that we are going to do work on is "Hello, world!". Our target is to find a variation of it that SHA-256 hashes to a value beginning with '000'. We vary the string by adding an integer value to the end called a [[nonce]] and incrementing it each time. Finding a match for "Hello, world!" takes us 4251 tries (but happens to have zeroes in the first four digits):<br />
<br />
"Hello, world!0" => 1312af178c253f84028d480a6adc1e25e81caa44c749ec81976192e2ec934c64<br />
"Hello, world!1" => e9afc424b79e4f6ab42d99c81156d3a17228d6e1eef4139be78e948a9332a7d8<br />
"Hello, world!2" => ae37343a357a8297591625e7134cbea22f5928be8ca2a32aa475cf05fd4266b7<br />
...<br />
"Hello, world!4248" => 6e110d98b388e77e9c6f042ac6b497cec46660deef75a55ebc7cfdf65cc0b965<br />
"Hello, world!4249" => c004190b822f1669cac8dc37e761cb73652e7832fb814565702245cf26ebb9e6<br />
"Hello, world!4250" => 0000c3af42fc31103f1fdc0151fa747ff87349a4714df7cc52ea464e12dcd4e9<br />
<br />
4251 hashes on a modern computer is not very much work (most computers can achieve at least 4 million hashes per second). Bitcoin automatically varies the [[difficulty]] (and thus the amount of work required to generate a block) to keep a roughly constant rate of block generation. The probability of a single hash succeeding can be found [http://blockexplorer.com/q/probability here].<br />
<br />
In Bitcoin things are a bit more complex, especially since the header contains the [http://en.wikipedia.org/wiki/Merkle_tree Merkle tree] which depends on the included [[transactions]]. This includes the generation transaction, a transaction "out of nowhere" to our own address, which in addition to providing the miner with incentive to do the work, also ensures that every miner hashes a unique data set.<br />
<br />
== List of algorithms ==<br />
<br />
=== Traditional proof of work ===<br />
# hashcash with double iterated SHA256<br />
# hashcash with [[scrypt]] internal hash<br />
# [[Momentum]] birthday collision<br />
# Cuckoo cycle proof of work https://github.com/tromp/cuckoo <br />
# Various other proof of works functions (e.g. [[Ethereum]] had a few candidates)<br />
<br />
=== Proof of X ===<br />
# [[Proof of Stake]] (Used in [[Peercoin]], [[Nxt]])<br />
# [[Proof of Burn]] (Used for the [[Counterparty]] IPO)<br />
<br />
[[Category:Vocabulary]]<br />
[[Category:Proof-of-x]]<br />
<br />
[[fr:Preuve de travail]]</div>Ripper234https://en.bitcoin.it/w/index.php?title=Proof_of_Publication&diff=47846Proof of Publication2014-06-02T20:34:22Z<p>Ripper234: Created page with "{{stub}} A method that uses Bitcoin or Bitcoin-like technologies to authenticate that a certain information was published at a certain date, or was known at a certain date...."</p>
<hr />
<div>{{stub}}<br />
<br />
A method that uses Bitcoin or Bitcoin-like technologies to authenticate that a certain information was published at a certain date, or was known at a certain date.<br />
<br />
The technique entails encoding the secure hash of a certain publication (plaintext) inside the Bitcoin blockchain. It was probablly first described in the paper from 2012 titled "CommitCoin: Carbon Dating Commitments with Bitcoin" ([http://people.scs.carleton.ca/~clark/papers/2012_fc.pdf extended abstract] and [http://eprint.iacr.org/2011/677.pdf technical report]).<br />
<br />
One website that provides an easy gateway to Proof of Publication is [http://www.proofofexistence.com/ ProofOfExistance.com].<br />
<br />
[[Category:Proof-of-x]]</div>Ripper234https://en.bitcoin.it/w/index.php?title=Talk:Research&diff=47845Talk:Research2014-06-02T20:30:48Z<p>Ripper234: /* Paper order */ new section</p>
<hr />
<div>== Paper order ==<br />
<br />
I [https://en.bitcoin.it/w/index.php?title=Research&action=historysubmit&diff=47844&oldid=47816 reordered] the papers by chronological order, with the exception that Satoshi's whitepaper appears first.<br />
<br />
[[User:Ripper234|Ripper234]] ([[User talk:Ripper234|talk]]) 20:30, 2 June 2014 (UTC)</div>Ripper234https://en.bitcoin.it/w/index.php?title=Research&diff=47844Research2014-06-02T20:29:38Z<p>Ripper234: Order everything chronologically, except for Satoshi's paper which is first.</p>
<hr />
<div>Publications including research and analysis of Bitcoin or related areas.<br />
<br />
{| class="wikitable sortable"<br />
! Title<br />
! Author<br />
! Type<br />
! Year<br />
! Links<br />
|-<br />
| Bitcoin: A Peer-to-Peer Electronic Cash System<br />
| Satoshi Nakamoto<br />
| Research paper<br />
| 2009<br />
| [http://bitcoin.org/bitcoin.pdf Download] [[Bitcoin_paper |wiki page]]<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<br />
| [http://iang.org/papers/triple_entry.html Download]<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<br />
| [http://www.bakerinstitute.org/publications/ITP-pub-FinancialTransactions-082911.pdf Download]<br />
|-<br />
| An Analysis of Anonymity in the Bitcoin System<br />
| Fergal Reid, Martin Harrigan<br />
| Research paper<br />
| 2011<br />
| [http://arxiv.org/abs/1107.4524 Download], [http://bitcointalk.org/index.php?topic=31539.0 discussion]<br />
|-<br />
| Bitcoin: An Innovative Alternative Digital Currency<br />
| Reuben Grinberg<br />
| Research paper<br />
| 2011<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<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<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<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<br />
| 2012 (preliminary)<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<br />
| 2012 (preliminary)<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 & 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]<br />[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 "ThePiachu" 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<br />
| 2012 (preliminary)<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). "This paper considers reform possibilities posed by a type of base money that has heretofore been overlooked in the literature on monetary economics."<br />
| George Selgin<br />
| Working Papers Series<br />
| 2012<br />
| [http://ssrn.com/abstract=2000118 Download]<br />
|-<br />
| Virtual currency schemes - "This report is a first attempt to provide the basis for a discussion on virtual currency schemes."<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 & 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&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&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&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 />
| 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.7418v1 Download]<br />
|}<br />
<br />
==See Also==<br />
<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>Ripper234https://en.bitcoin.it/w/index.php?title=Proof_of_Stake&diff=46896Proof of Stake2014-04-29T17:56:19Z<p>Ripper234: </p>
<hr />
<div>Proof of Stake is a proposed alternative to [[Proof of Work]]. Like proof of work, proof of stake provides a mechanism for determining who signs bitcoin transactions (see [https://bitcointalk.org/index.php?topic=68213.0 "main" bitcointalk thread], and a [https://bitcointalk.org/index.php?topic=96854.0 Bounty Thread]).<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 "Proof of Stake blocks".<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 >= 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<s<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="wikitable"<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 "the wrong version" - 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 />
== Peeroin ==<br />
[http://ppcoin.org Peercoin] is the first known implementation of a combined PoS/PoW system (released August 19 2012).<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]]</div>Ripper234https://en.bitcoin.it/w/index.php?title=Ron_Gross&diff=45997Ron Gross2014-04-06T08:41:42Z<p>Ripper234: </p>
<hr />
<div>[[image:Ron Gross.jpg]]<br />
<br />
Ron has graduated from the Technion with an M. Sc in Computer Science.<br />
He has worked at several companies, ranging from small startups to Google,<br />
and has an extensive experience in web architecture, security, and algorithms.<br />
<br />
Ron has been continuously involved with Bitcoin since March 2011,<br />
spreading the word, knowledge, and love of Bitcoin. He is a firm advocate of <br />
open source, transparency and decentralization of power and technology.<br />
Ron co-founded the Israeli Bitcoin community and foundation and is a board member of the [[Mastercoin Foundation]].<br />
<br />
He was a partner in [[Bitcoil]], the first Israeli exchange.<br />
<br />
He briefly worked on [[Bitblu]] in the summer of 2013.<br />
<br />
As of November 2013 Ron is the Executive Director of the [[Mastercoin]] project.<br />
<br />
You can reach Ron at:<br />
* ron@mastercoin.org<br />
* skype - ripper234<br />
* [https://www.sococo.com/web/join/bg0gjoqu5xv0tvq62pud1mz21 Sococo]<br />
<br />
See also read [http://ripper234.com/about the about page on his blog].<br />
<br />
[[Category:People]]</div>Ripper234https://en.bitcoin.it/w/index.php?title=Conferences&diff=44397Conferences2014-02-10T19:33:35Z<p>Ripper234: </p>
<hr />
<div>Please announce new conferences on [https://bitcointalk.org/index.php?topic=238093 bitcointalk].<br />
Also you can [https://github.com/bitcoin/bitcoin.org/tree/master/_events submit a pull request on bitcoin.org] ([https://github.com/bitcoin/bitcoin.org#events see doc])<br />
<br />
== Forthcoming Conferences ==<br />
<br />
=== Miami Jan 25-26 2014 ===<br />
January 25 & 26, 2014 Miami Beach Convention Center in South Beach<br />
http://btcmiami.com<br />
https://bitcointalk.org/index.php?topic=330061<br />
<br />
=== Berlin Feb 12-13 2014 ===<br />
[http://insidebitcoins.de/en/?c=bcoinberlpage Inside Bitcoins Berlin]<br />
<br />
=== Austin March 6 2014 ===<br />
[http://texasbitcoinconference.com/ Texas Bitcoin Conference]<br />
<br />
=== New York March 12 2014 ===<br />
[http://www.themankoffcompany.com/CryptocurrenciesNYMarch2014 The Mankoff Company New York]<br />
<br />
=== San Francisco March 20 2014 ===<br />
[http://www.themankoffcompany.com/CryptocurrenciesSanFranMarch2014<br />
The Mankoff Company San Francisco]<br />
<br />
=== London, April 3, 2014 ===<br />
[http://www.themankoffcompany.com/CryptocurrenciesLondonApril2014 The Mankoff Company London]<br />
<br />
=== New York April 7-8 2014 ===<br />
[http://www.mediabistro.com/insidebitcoins/new-york/ Inside Bitcoins New York]<br />
<br />
=== Toronto April 11th-13th 2014 ===<br />
[http://www.bitcoinexpo.ca/ Bitcoin Expo 2014]<br />
<br />
=== Holland May 15-17 2014 ===<br />
[https://bitcointalk.org/index.php?topic=343065 Bitcoin 2014], organized by the Bitcoin Foundation<br />
<br />
=== Washington June 20-22 2014 ===<br />
[http://www.bitcoinbeltway.com/ Beltway]<br />
<br />
=== Hong Kong June 24-25, 2014 ===<br />
TBD<br />
<br />
=== Israel July 2014 ===<br />
Inside Bitcoins. Details TBD<br />
<br />
=== Black Rock City,Nevada - August 25th - September 1st 2014 ===<br />
[http://campbitcoin.hivewallet.com/ Camp Bitcoin]<br />
<br />
=== London September 10, 2014 ===<br />
TBD<br />
<br />
=== Las Vegas October 6-7, 2014 ===<br />
TBD<br />
<br />
=== Israel 3-4 November 2014 ===<br />
TBD<br />
<br />
== Past Conferences ==<br />
* [http://www.bitgroups.org Bitcoin & Future Technology], European Conference, Prague, November 25 - 27, 2011<br />
* [http://bitcoin.uni-rostock.de Bitcoin Tutorial and Workshop], Annual Meeting of the German Computer Science association GI, Braunschweig, September 20, 2012.<br />
* [http://bitcoin2012.com Bitcoin Conference], London, 2012.<br />
<br />
==See Also==<br />
<br />
* [http://bitcoin.org/en/events Events] on Bitcoin.org website<br />
* [https://bitcointalk.org/index.php?topic=238093 List of conferences thread on bitcointalk]</div>Ripper234https://en.bitcoin.it/w/index.php?title=Proof_of_Burn&diff=44394Proof of Burn2014-02-10T14:46:14Z<p>Ripper234: Redirected page to Proof of burn</p>
<hr />
<div>#REDIRECT [[Proof of burn]]</div>Ripper234https://en.bitcoin.it/w/index.php?title=Proof_of_work&diff=44393Proof of work2014-02-10T14:45:39Z<p>Ripper234: </p>
<hr />
<div>A '''proof of work''' is a piece of data which was difficult (costly, time-consuming) to produce so as to satisfy certain requirements. It must be trivial to check whether data satisfies said requirements. Producing a proof of work can be a random process with low probability, so that a lot of trial and error is required ''on average'' before a valid proof of work is generated. Bitcoin uses the [[Hashcash]] proof of work.<br />
<br />
One application of this idea is using [http://en.wikipedia.org/wiki/Hashcash hascash] as a method to preventing email spam, requiring a proof of work on the email's contents (including the To address), on every email. Legitimate emails will be able to do the work to generate the proof easily (not much work is required for a single email), but mass spam emailers will have difficulty generating the required proofs (which would require huge computational resources).<br />
<br />
Hashcash proofs of work are used in Bitcoin for block generation. Proofs of work that are tied to the data of each block are required for the blocks to be accepted. The [[difficulty]] of this work is adjusted so as to limit the rate at which new blocks can be generated by the network to one every 10 minutes. Due to the very low probability of successful generation, this makes it unpredictable which worker computer in the network will be able to generate the next block.<br />
<br />
For a block to be valid it must hash to a value less than the current [[target]]; this means that each block indicates that work has been done generating it. Each block contains the hash of the preceding block, thus each block has a [[block chain|chain]] of blocks that together contain a large amount of work. Changing a block (which can only be done by making a new block containing the same predecessor) requires regenerating all successors and redoing the work they contain. This protects the block chain from tampering.<br />
<br />
== Example ==<br />
<br />
Let's say the base string that we are going to do work on is "Hello, world!". Our target is to find a variation of it that SHA-256 hashes to a value beginning with '000'. We vary the string by adding an integer value to the end called a [[nonce]] and incrementing it each time. Finding a match for "Hello, world!" takes us 4251 tries (but happens to have zeroes in the first four digits):<br />
<br />
"Hello, world!0" => 1312af178c253f84028d480a6adc1e25e81caa44c749ec81976192e2ec934c64<br />
"Hello, world!1" => e9afc424b79e4f6ab42d99c81156d3a17228d6e1eef4139be78e948a9332a7d8<br />
"Hello, world!2" => ae37343a357a8297591625e7134cbea22f5928be8ca2a32aa475cf05fd4266b7<br />
...<br />
"Hello, world!4248" => 6e110d98b388e77e9c6f042ac6b497cec46660deef75a55ebc7cfdf65cc0b965<br />
"Hello, world!4249" => c004190b822f1669cac8dc37e761cb73652e7832fb814565702245cf26ebb9e6<br />
"Hello, world!4250" => 0000c3af42fc31103f1fdc0151fa747ff87349a4714df7cc52ea464e12dcd4e9<br />
<br />
4251 hashes on a modern computer is not very much work (most computers can achieve at least 4 million hashes per second). Bitcoin automatically varies the [[difficulty]] (and thus the amount of work required to generate a block) to keep a roughly constant rate of block generation. The probability of a single hash succeeding can be found [http://blockexplorer.com/q/probability here].<br />
<br />
In Bitcoin things are a bit more complex, especially since the header contains the [http://en.wikipedia.org/wiki/Merkle_tree Merkle tree] which depends on the included [[transactions]]. This includes the generation transaction, a transaction "out of nowhere" to our own address, which in addition to providing the miner with incentive to do the work, also ensures that every miner hashes a unique data set.<br />
<br />
== List of algorithms ==<br />
<br />
=== Traditional proof of work ===<br />
# hashcash / SHA256<br />
# [[scrypt]]<br />
# [[Momentum]]<br />
# Various other proof of works functions (e.g. [[Ethereum]] had a few candidates)<br />
<br />
=== Proof of X ===<br />
# [[Proof of Stake]] (Used in [[Peercoin]], [[Nxt]])<br />
# [[Proof of Burn]] (Used for the [[Counterparty]] IPO)<br />
<br />
[[Category:Vocabulary]]<br />
<br />
[[fr:Preuve de travail]]</div>Ripper234https://en.bitcoin.it/w/index.php?title=Proof_of_work&diff=44392Proof of work2014-02-10T14:43:58Z<p>Ripper234: Adding list of algorithms</p>
<hr />
<div>A '''proof of work''' is a piece of data which was difficult (costly, time-consuming) to produce so as to satisfy certain requirements. It must be trivial to check whether data satisfies said requirements. Producing a proof of work can be a random process with low probability, so that a lot of trial and error is required ''on average'' before a valid proof of work is generated. Bitcoin uses the [[Hashcash]] proof of work.<br />
<br />
One application of this idea is using [http://en.wikipedia.org/wiki/Hashcash hascash] as a method to preventing email spam, requiring a proof of work on the email's contents (including the To address), on every email. Legitimate emails will be able to do the work to generate the proof easily (not much work is required for a single email), but mass spam emailers will have difficulty generating the required proofs (which would require huge computational resources).<br />
<br />
Hashcash proofs of work are used in Bitcoin for block generation. Proofs of work that are tied to the data of each block are required for the blocks to be accepted. The [[difficulty]] of this work is adjusted so as to limit the rate at which new blocks can be generated by the network to one every 10 minutes. Due to the very low probability of successful generation, this makes it unpredictable which worker computer in the network will be able to generate the next block.<br />
<br />
For a block to be valid it must hash to a value less than the current [[target]]; this means that each block indicates that work has been done generating it. Each block contains the hash of the preceding block, thus each block has a [[block chain|chain]] of blocks that together contain a large amount of work. Changing a block (which can only be done by making a new block containing the same predecessor) requires regenerating all successors and redoing the work they contain. This protects the block chain from tampering.<br />
<br />
== Example ==<br />
<br />
Let's say the base string that we are going to do work on is "Hello, world!". Our target is to find a variation of it that SHA-256 hashes to a value beginning with '000'. We vary the string by adding an integer value to the end called a [[nonce]] and incrementing it each time. Finding a match for "Hello, world!" takes us 4251 tries (but happens to have zeroes in the first four digits):<br />
<br />
"Hello, world!0" => 1312af178c253f84028d480a6adc1e25e81caa44c749ec81976192e2ec934c64<br />
"Hello, world!1" => e9afc424b79e4f6ab42d99c81156d3a17228d6e1eef4139be78e948a9332a7d8<br />
"Hello, world!2" => ae37343a357a8297591625e7134cbea22f5928be8ca2a32aa475cf05fd4266b7<br />
...<br />
"Hello, world!4248" => 6e110d98b388e77e9c6f042ac6b497cec46660deef75a55ebc7cfdf65cc0b965<br />
"Hello, world!4249" => c004190b822f1669cac8dc37e761cb73652e7832fb814565702245cf26ebb9e6<br />
"Hello, world!4250" => 0000c3af42fc31103f1fdc0151fa747ff87349a4714df7cc52ea464e12dcd4e9<br />
<br />
4251 hashes on a modern computer is not very much work (most computers can achieve at least 4 million hashes per second). Bitcoin automatically varies the [[difficulty]] (and thus the amount of work required to generate a block) to keep a roughly constant rate of block generation. The probability of a single hash succeeding can be found [http://blockexplorer.com/q/probability here].<br />
<br />
In Bitcoin things are a bit more complex, especially since the header contains the [http://en.wikipedia.org/wiki/Merkle_tree Merkle tree] which depends on the included [[transactions]]. This includes the generation transaction, a transaction "out of nowhere" to our own address, which in addition to providing the miner with incentive to do the work, also ensures that every miner hashes a unique data set.<br />
<br />
== List of algorithms ==<br />
<br />
=== Traditional proof of work ===<br />
# hashcash / SHA256<br />
# SCRYPT<br />
# Momentum<br />
# Various other proof of works functions (e.g. Ethereum had a few candidates)<br />
<br />
=== Proof of X ===<br />
# Proof of Stake (Peercoin, Nxt)<br />
# Proof of Burn (XCP)<br />
<br />
[[Category:Vocabulary]]<br />
<br />
[[fr:Preuve de travail]]</div>Ripper234https://en.bitcoin.it/w/index.php?title=Conferences&diff=44128Conferences2014-01-29T20:08:22Z<p>Ripper234: Added Bitcoin Expo 2014</p>
<hr />
<div>Please announce new conferences on [https://bitcointalk.org/index.php?topic=238093 bitcointalk].<br />
<br />
== Forthcoming Conferences ==<br />
<br />
=== Miami Jan 25-26 2014 ===<br />
January 25 & 26, 2014 Miami Beach Convention Center in South Beach<br />
http://btcmiami.com<br />
https://bitcointalk.org/index.php?topic=330061<br />
<br />
=== Berlin Feb 12-13 2014 ===<br />
[http://insidebitcoins.de/en/?c=bcoinberlpage Inside Bitcoins Berlin]<br />
<br />
=== Austin March 6 2014 ===<br />
[http://texasbitcoinconference.com/ Texas Bitcoin Conference]<br />
<br />
=== New York March 12 2014 ===<br />
[http://www.themankoffcompany.com/CryptocurrenciesNYMarch2014 The Mankoff Company New York]<br />
<br />
=== San Francisco March 20 2014 ===<br />
[http://www.themankoffcompany.com/CryptocurrenciesSanFranMarch2014<br />
The Mankoff Company San Francisco]<br />
<br />
=== London, April 3, 2014 ===<br />
[http://www.themankoffcompany.com/CryptocurrenciesLondonApril2014 The Mankoff Company London]<br />
<br />
=== New York April 7-8 2014 ===<br />
[http://www.mediabistro.com/insidebitcoins/new-york/ Inside Bitcoins New York]<br />
<br />
=== Toronto April 11th-13th 2014 ===<br />
[http://www.bitcoinexpo.ca/ Bitcoin Expo 2014]<br />
<br />
=== Holland May 15-17 2014 ===<br />
[https://bitcointalk.org/index.php?topic=343065 Bitcoin 2014], organized by the Bitcoin Foundation<br />
<br />
=== Washington June 20-22 2014 ===<br />
[http://www.bitcoinbeltway.com/ Beltway]<br />
<br />
=== Hong Kong June 24-25, 2014 ===<br />
TBD<br />
<br />
=== Israel July 2014 ===<br />
Inside Bitcoins. Details TBD<br />
<br />
=== Black Rock City,Nevada - August 25th - September 1st 2014 ===<br />
[http://campbitcoin.hivewallet.com/ Camp Bitcoin]<br />
<br />
=== London September 10, 2014 ===<br />
TBD<br />
<br />
=== Las Vegas October 6-7, 2014 ===<br />
TBD<br />
<br />
=== Israel 3-4 November 2014 ===<br />
TBD<br />
<br />
== Past Conferences ==<br />
* [http://www.bitgroups.org Bitcoin & Future Technology], European Conference, Prague, November 25 - 27, 2011<br />
* [http://bitcoin.uni-rostock.de Bitcoin Tutorial and Workshop], Annual Meeting of the German Computer Science association GI, Braunschweig, September 20, 2012.<br />
* [http://bitcoin2012.com Bitcoin Conference], London, 2012.<br />
<br />
==See Also==<br />
<br />
* [http://bitcoin.org/en/events Events] on Bitcoin.org website<br />
* [https://bitcointalk.org/index.php?topic=238093 List of conferences thread on bitcointalk]</div>Ripper234https://en.bitcoin.it/w/index.php?title=Conferences&diff=43944Conferences2014-01-22T22:04:37Z<p>Ripper234: Add Mankoff events</p>
<hr />
<div>Please announce new conferences on [https://bitcointalk.org/index.php?topic=238093 bitcointalk].<br />
<br />
== Forthcoming Conferences ==<br />
<br />
=== Miami Jan 25-26 2014 ===<br />
January 25 & 26, 2014 Miami Beach Convention Center in South Beach<br />
http://btcmiami.com<br />
https://bitcointalk.org/index.php?topic=330061<br />
<br />
=== Berlin Feb 12-13 2014 ===<br />
[http://insidebitcoins.de/en/?c=bcoinberlpage Inside Bitcoins Berlin]<br />
<br />
=== Austin March 6 2014 ===<br />
[http://texasbitcoinconference.com/ Texas Bitcoin Conference]<br />
<br />
=== New York March 12 2014 ===<br />
[http://www.themankoffcompany.com/CryptocurrenciesNYMarch2014 The Mankoff Company New York]<br />
<br />
=== San Francisco March 20 2014 ===<br />
[http://www.themankoffcompany.com/CryptocurrenciesSanFranMarch2014<br />
The Mankoff Company San Francisco]<br />
<br />
=== London, 3 April, 2014 ===<br />
[http://www.themankoffcompany.com/CryptocurrenciesLondonApril2014 The Mankoff Company London]<br />
<br />
=== New York April 7-8 2014 ===<br />
[http://www.mediabistro.com/insidebitcoins/new-york/ Inside Bitcoins New York]<br />
<br />
=== Holland May 15-17 2014 ===<br />
[https://bitcointalk.org/index.php?topic=343065 Bitcoin 2014], organized by the Bitcoin Foundation<br />
<br />
=== Washington June 20-22 2014 ===<br />
[http://www.bitcoinbeltway.com/ Beltway]<br />
<br />
=== Hong Kong June 24-25, 2014 ===<br />
TBD<br />
<br />
=== Israel July 2014 ===<br />
Inside Bitcoins. Details TBD<br />
<br />
=== Black Rock City,Nevada - August 25th - September 1st 2014 ===<br />
[http://campbitcoin.hivewallet.com/ Camp Bitcoin]<br />
<br />
=== London September 10, 2014 ===<br />
TBD<br />
<br />
=== Las Vegas October 6-7, 2014 ===<br />
TBD<br />
<br />
=== Israel 3-4 November 2014 ===<br />
TBD<br />
<br />
== Past Conferences ==<br />
* [http://www.bitgroups.org Bitcoin & Future Technology], European Conference, Prague, November 25 - 27, 2011<br />
* [http://bitcoin.uni-rostock.de Bitcoin Tutorial and Workshop], Annual Meeting of the German Computer Science association GI, Braunschweig, September 20, 2012.<br />
* [http://bitcoin2012.com Bitcoin Conference], London, 2012.<br />
<br />
==See Also==<br />
<br />
* [http://bitcoin.org/en/events Events] on Bitcoin.org website<br />
* [https://bitcointalk.org/index.php?topic=238093 List of conferences thread on bitcointalk]</div>Ripper234https://en.bitcoin.it/w/index.php?title=Conferences&diff=43904Conferences2014-01-21T18:29:22Z<p>Ripper234: </p>
<hr />
<div>Please announce new conferences on [https://bitcointalk.org/index.php?topic=238093 bitcointalk].<br />
<br />
== Forthcoming Conferences ==<br />
<br />
=== Miami Jan 25-26 2014 ===<br />
January 25 & 26, 2014 Miami Beach Convention Center in South Beach<br />
http://btcmiami.com<br />
https://bitcointalk.org/index.php?topic=330061<br />
<br />
=== Berlin Feb 12-13 2014 ===<br />
[http://insidebitcoins.de/en/?c=bcoinberlpage Inside Bitcoins Berlin]<br />
<br />
=== Austin March 6 2014 ===<br />
[http://texasbitcoinconference.com/ Texas Bitcoin Conference]<br />
<br />
=== New York April 7-8 2014 ===<br />
[http://www.mediabistro.com/insidebitcoins/new-york/ Inside Bitcoins New York]<br />
<br />
=== Holland May 15-17 2014 ===<br />
[https://bitcointalk.org/index.php?topic=343065 Bitcoin 2014], organized by the Bitcoin Foundation<br />
<br />
=== Washington June 20-22 2014 ===<br />
[http://www.bitcoinbeltway.com/ Beltway]<br />
<br />
=== Hong Kong June 24-25, 2014 ===<br />
TBD<br />
<br />
=== Israel July 2014 ===<br />
Inside Bitcoins. Details TBD<br />
<br />
=== Black Rock City,Nevada - August 25th - September 1st 2014 ===<br />
[http://campbitcoin.hivewallet.com/ Camp Bitcoin]<br />
<br />
=== London September 10, 2014 ===<br />
TBD<br />
<br />
=== Las Vegas October 6-7, 2014 ===<br />
TBD<br />
<br />
=== Israel 3-4 November 2014 ===<br />
TBD<br />
<br />
== Past Conferences ==<br />
* [http://www.bitgroups.org Bitcoin & Future Technology], European Conference, Prague, November 25 - 27, 2011<br />
* [http://bitcoin.uni-rostock.de Bitcoin Tutorial and Workshop], Annual Meeting of the German Computer Science association GI, Braunschweig, September 20, 2012.<br />
* [http://bitcoin2012.com Bitcoin Conference], London, 2012.<br />
<br />
==See Also==<br />
<br />
* [http://bitcoin.org/en/events Events] on Bitcoin.org website<br />
* [https://bitcointalk.org/index.php?topic=238093 List of conferences thread on bitcointalk]</div>Ripper234https://en.bitcoin.it/w/index.php?title=Conferences&diff=43903Conferences2014-01-21T18:28:50Z<p>Ripper234: </p>
<hr />
<div>Please announce new conferences on [https://bitcointalk.org/index.php?topic=238093 bitcointalk].<br />
<br />
== Forthcoming Conferences ==<br />
<br />
=== Miami Jan 25-26 2014 ===<br />
January 25 & 26, 2014 Miami Beach Convention Center in South Beach<br />
http://btcmiami.com<br />
https://bitcointalk.org/index.php?topic=330061<br />
<br />
=== Berlin Feb 12-13 2014 ===<br />
[http://insidebitcoins.de/en/?c=bcoinberlpage Inside Bitcoins Berlin]<br />
<br />
=== Austin March 6 2014 ===<br />
[http://texasbitcoinconference.com/ Texas Bitcoin Conference]<br />
<br />
=== New York April 7-8 2014 ===<br />
[http://www.mediabistro.com/insidebitcoins/new-york/ Inside Bitcoins New York]<br />
<br />
=== Holland May 15-17 2014 ===<br />
[https://bitcointalk.org/index.php?topic=343065 Bitcoin 2014], organized by the Bitcoin Foundation<br />
<br />
=== Washington June 20-22 2014 ==<br />
[http://www.bitcoinbeltway.com/ Beltway]<br />
<br />
=== Hong Kong June 24-25, 2014 ===<br />
TBD<br />
<br />
=== Israel July 2014 ===<br />
Inside Bitcoins. Details TBD<br />
<br />
=== Black Rock City,Nevada - August 25th - September 1st 2014 ===<br />
[http://campbitcoin.hivewallet.com/ Camp Bitcoin]<br />
<br />
=== London September 10, 2014 ===<br />
TBD<br />
<br />
=== Las Vegas October 6-7, 2014 ===<br />
TBD<br />
<br />
=== Israel 3-4 November 2014 ===<br />
TBD<br />
<br />
== Past Conferences ==<br />
* [http://www.bitgroups.org Bitcoin & Future Technology], European Conference, Prague, November 25 - 27, 2011<br />
* [http://bitcoin.uni-rostock.de Bitcoin Tutorial and Workshop], Annual Meeting of the German Computer Science association GI, Braunschweig, September 20, 2012.<br />
* [http://bitcoin2012.com Bitcoin Conference], London, 2012.<br />
<br />
==See Also==<br />
<br />
* [http://bitcoin.org/en/events Events] on Bitcoin.org website<br />
* [https://bitcointalk.org/index.php?topic=238093 List of conferences thread on bitcointalk]</div>Ripper234https://en.bitcoin.it/w/index.php?title=Conferences&diff=43902Conferences2014-01-21T18:18:32Z<p>Ripper234: </p>
<hr />
<div>== Forthcoming Conferences ==<br />
<br />
=== Miami Jan 25-26 2014 ===<br />
January 25 & 26, 2014 Miami Beach Convention Center in South Beach<br />
http://btcmiami.com<br />
https://bitcointalk.org/index.php?topic=330061<br />
<br />
== Past Conferences ==<br />
* [http://www.bitgroups.org Bitcoin & Future Technology], European Conference, Prague, November 25 - 27, 2011<br />
* [http://bitcoin.uni-rostock.de Bitcoin Tutorial and Workshop], Annual Meeting of the German Computer Science association GI, Braunschweig, September 20, 2012.<br />
* [http://bitcoin2012.com Bitcoin Conference], London, 2012.<br />
<br />
==See Also==<br />
<br />
* [http://bitcoin.org/en/events Events] on Bitcoin.org website<br />
* [https://bitcointalk.org/index.php?topic=238093 List of conferences thread on bitcointalk]</div>Ripper234https://en.bitcoin.it/w/index.php?title=Comparison_of_cryptocurrencies&diff=43736Comparison of cryptocurrencies2014-01-14T14:11:19Z<p>Ripper234: /* Major */ Added Mastercoin MSC (major due to market cap)</p>
<hr />
<div>This article aims to list relevant cryptocurrencies, even those too minor to have their own wiki entry. See also [[:Category:Alternative cryptocurrencies]]<br />
<br />
It is based [https://bitcointalk.org/index.php?topic=134179.0 on this thread].<br />
<br />
= Currencies =<br />
<br />
The order / grouping of these coins are still TBD.<br />
<br />
[[User:Ripper234|Ripper234]] proposes a grouping of Major, Minor and New by an arbitrary market cap limit. This can be done once the market caps of the alts are known.<br />
* Using market cap will make Tonal Bitcoin a "Major" despite de facto minor usage. Therefore, I suggest finding a different method of categorizing. --[[User:Luke-jr|Luke-jr]] ([[User talk:Luke-jr|talk]]) 05:06, 4 March 2013 (GMT)<br />
<br />
<br />
== Major ==<br />
=== Bitcoin (BTC) ===<br />
* http://bitcoin.org/ <br />
* blocks every '''10 min'''<br />
* coin supply* '''21 million''' coins will be available<br />
* difficulty adjustment* '''2016 blocks'''<br />
* hashing algorithm '''SHA256d'''<br />
* Initial Reward '''50 '''coins per block<br />
* Market Cap: $144,000,000 (Jan 5th, 2013)<br />
* Launch Date: January 3rd, 2009<br />
<br />
=== Namecoin (NMC) === <br />
* https://en.bitcoin.it/wiki/Namecoin<br />
* (merged mined with BTC) <br />
* https://github.com/vinced/namecoin <br />
* http://namecoin.info/<br />
* blocks every '''10 min'''<br />
* coin supply* '''21 million''' coins will be available<br />
* difficulty adjustment '''2016 blocks'''<br />
* hashing algorithm '''SHA256d'''<br />
* Initial Reward '''50 '''coins per block<br />
* Market Cap: ???? BTC<br />
* Launch Date: April 18, 2011<br />
<br />
=== Litecoin (LTC) ===<br />
* http://litecoin.org/<br />
* blocks every '''2.5 min'''<br />
* coin supply* '''84 million''' coins will be available<br />
* difficulty adjustment '''2016 blocks'''<br />
* hashing algorithm '''scrypt '''<br />
* Initial Reward '''50''' coins per block<br />
* Market Cap: 150,000 BTC<br />
* Launch Date: October 2011<br />
<br />
=== PPCoin (PPC) ===<br />
* http://ppcoin.org/<br />
* https://bitcointalk.org/index.php?topic=101820.0<br />
* blocks every '''10 min'''<br />
* Coin supply* '''non-deterministic ''' coins will be available<br />
* difficulty adjustment '''each block'''<br />
* hashing algorithm '''SHA-256'''<br />
* Reward '''varies on difficulty''' coins per block<br />
* EXTRA: Incorporates [[Proof Of Stake]] coin Generation, contains central checksums to kickstart the protocol<br />
* Market Cap: ???? BTC<br />
* Launch Date: approx August 19th, 2012 (date of its [http://ppcoin.org/static/ppcoin-paper.pdf whitepaper])<br />
** The public design phase of this coin was very brief.<br />
<br />
=== Mastercoin (MSC) ===<br />
* http://www.mastercoin.org<br />
* Coin supply: 619478.59338440 MSC<br />
* Launch Date: September 1, 2013<br />
* Blockchain: uses Bitcoin for transport, storage and security, inherits Bitcoin Protocol properties<br />
* Extended Properties: Distributed Exchange, Savings & Guardian Addresses, Contracts for Difference, Smart Properties, User Currencies<br />
* Protocol: Master Protocol <br />
* Spec Github Repo: https://github.com/mastercoin-MSC/spec<br />
<br />
== New ==<br />
New in on the scene.<br />
Please put here any coins whose concept are new. If a coin is discussed for 6 months and launched yesterday, it is not new.<br />
<br />
=== RonPaulCoin (RPC) ===<br />
* http://www.ronpaulcoin.com <br />
* Blocks every '''2 min'''<br />
* Coin supply '''2.1 million''' total coins<br />
* Difficulty adjustment '''1 day'''<br />
* Hashing algorithm '''scrypt'''<br />
* Initial Reward '''1 '''coin per block<br />
* Block reward halfed every 262k blocks (~ 4 years)<br />
* Launch Date: December 29, 2013<br />
<br />
=== Betacoin (BET) ===<br />
* http://betacoin.org/ <br />
* Blocks every '''4 min'''<br />
* Coin supply* '''32 million''' coins will be mined in ~ first 6 years + '''0,39% annual'''<br />
* Difficulty adjustment* '''6 blocks'''<br />
* Hashing algorithm '''SHA256d'''<br />
* Initial Reward '''128 '''coins per block<br />
* Block reward halfed every 126k blocks (~ 1 year)<br />
* Launch Date: October, 2013<br />
<br />
=== Nxt (NXT) ===<br />
* http://nextcoin.org<br />
* Pronounced as "Next"<br />
* Blocks every '''1 min'''<br />
* Designed as 100% PoS (Proof-of-Stake) system<br />
* Coin supply* '''1 billion''' coins exist from the start distributed by 74 founding stake holders<br />
* Launch Date: September, 29, 2013<br />
<br />
<br />
== Minor ==<br />
=== Megacoin (MΣC) ===<br />
* http://www.megacoin.co.nz/<br />
* https://forum.megacoin.co.nz<br />
* Block Target is 2.5 minutes<br />
* Block reward halved every every 420,000 blocks<br />
* 25 coins per block<br />
* 42 Million total coins<br />
* Difficulty changes every block<br />
<br />
The implentation of the Kimoto Gravity well retargets difficulty every block. This keeps mining fair and secure for all miners and users of the coin, and prevents the rampant multipool abuse that was (and still is) common with most all other altcoins out on the market today. <br />
<br />
=== AnonCoin (ANC) ===<br />
* https://anoncoin.net/<br />
* https://forum.anoncoin.net<br />
* Block Target is 3.4 minutes<br />
* Block reward halfed every 306k blocks<br />
* 5 coins per block<br />
* 4.2 million total coins<br />
* Difficulty changes every block<br />
<br />
Anoncoins goal is to make the user more Anonymous by having built-in support for I2P, Coincontrol, and more in the future.<br />
<br />
=== Franko (FRK) ===<br />
* http://www.frankos.org/<br />
* http://forum.frankos.org<br />
* Block Target is 0.5 minutes<br />
* Block reward halfed every 22m blocks<br />
* 0.25 coins per block<br />
* 11.2 million total coins<br />
* Difficulty changes every 720 blocks<br />
<br />
Franko is considered the crypto with the fairest adoption length. Accepted by over 50 merchants and 10 brick and mortar stores.<br />
<br />
Base currency used by the Franko Collective, a democratic group of developers.<br />
<br />
=== FeatherCoin (FTC) ===<br />
* http://feathercoin.com/<br />
* A fork of Litecoin<br />
* 243 million total coins<br />
<br />
=== CraftCoin (CRC) ===<br />
* http://craftcoin.net/<br />
* Based on Litecoin<br />
* Portable in-game currency for Minecraft Servers<br />
* 206,847 total coins<br />
<br />
=== Tonal Bitcoin (TBC) ===<br />
* [[Tonal Bitcoin]]<br />
* (merged mined with BTC)<br />
* (blockchain shared with BTC)<br />
* (automatically converted to/from BTC)<br />
* blocks every '''10 min'''<br />
* Coin supply* '''7.8 tam''' coins will be available<br />
* difficulty adjustment '''2016 blocks'''<br />
* hashing algorithm '''SHA-256'''<br />
* Initial Reward '''1,2905.2''' coins per block<br />
* Market Cap: $144,000,000 (Jan 5th, 2013)<br />
* Launch Date: January 2rd, 2011<br />
<br />
=== IxCoin (IXC) ===<br />
* https://bitcointalk.org/index.php?topic=36701.0<br />
* (merged mined with BTC)<br />
* blocks every '''10 min'''<br />
* Coin supply* '''21 million''' coins will be available<br />
* difficulty adjustment '''2016 blocks'''<br />
* hashing algorithm '''SHA1''' <br />
* Reward '''96 '''coins per block<br />
<br />
=== Devcoin (DEV) ===<br />
* https://bitcointalk.org/index.php?topic=34586.0<br />
* (merged mined with BTC)<br />
* blocks every '''10 min'''<br />
* coin supply* '''constant generation''' coins will be available (???)<br />
* difficulty adjustment '''2016 blocks'''<br />
* hashing algorithm '''SHA256d'''<br />
* Reward '''50,000''' coins per block<br />
* '''EXTRA 90% block subsidy goes to foundation'''<br />
<br />
=== Freicoin (FRC) ===<br />
* http://freico.in/<br />
* http://www.freicoin.org/<br />
* https://bitcointalk.org/index.php?topic=89843.0<br />
* https://bitcointalk.org/index.php?topic=3816.0<br />
* blocks every '''10 minutes'''<br />
* coin supply* '''100 million''' coins will be available<br />
* difficulty adjustment '''2016 blocks'''<br />
* hashing algorithm '''SHA-256'''<br />
* [http://www.freicoin.org/freicoin-generation-graph-t41-20.html#p532 Arithmetically decreasing] reward<br />
* EXTRA: <br />
-- 4.89% annual [http://en.wikipedia.org/wiki/Demurrage_currency demurrage]<br />
-- 80% block subsidy [http://www.freicoin.org/application-developer-best-practices-t87.html#p919 goes to foundation for the first 3 years] (about 500 coins for each of first 161280 blocks, total 80m)<br />
-- [u]In need of Dev work on daemon, client etc but network still running[/u]<br />
<br />
=== I0coin (I0C) ===<br />
* https://bitcointalk.org/index.php?topic=36425.0 ; https://github.com/kr105rlz/i0coin<br />
* Perhaps should be moved to Dead section?<br />
<br />
=== Terracoin (TRC) ===<br />
* http://terracoin.org/<br />
* blocks every '''2 minutes'''<br />
* coin supply* '''42 million''' coins will be available<br />
* difficulty adjustment '''30 blocks'''<br />
* hashing algorithm '''SHA-256'''<br />
* Reward '''20''' coins per block <br />
<br />
=== Liquidcoin (LQC) ===<br />
* https://bitcointalk.org/index.php?topic=60026.0 <br />
* blocks every '''10 minutes'''<br />
* '''no cap''' as block subsidy has a minimum of 1 coin<br />
* Constant difficulty of '''0.5'''<br />
* Coin reward drops over time<br />
<br />
=== BBQCoin (BQC) ===<br />
* http://blog.bbqcoin.org http://www.bbqcoin.com<br />
* blocks every '''1 minute'''<br />
* coin supply* '''88 million''' coins will be available<br />
* difficulty adjustment '''60 blocks'''<br />
* hashing algorithm '''Scrypt'''<br />
* Reward '''42''' coins per block<br />
<br />
=== BitBar (BTB) ===<br />
* http://bitbar.biz/home<br />
* blocks every '''10 minutes'''<br />
* hashing algorithm '''Scrypt'''<br />
* Reward '''1''' coin per block<br />
* Coin reward drops over time<br />
<br />
=== Netcoin (NET) ===<br />
* Main - http://netcoin.org.uk/<br />
* Forums - http://forum.netcoinfoundation.org/<br />
* blocks every '''1 min'''<br />
* coin supply* '''320.6 million''' coins will be available<br />
* difficulty adjustment* '''60 blocks'''<br />
* hashing algorithm '''Scrypt'''<br />
* Initial Reward '''1024 '''coins per block<br />
* Reward Halves '''Every 3 months or 129,600 Blocks'''<br />
* Market Cap: approx. $200,000 (Dec 4th, 2013)<br />
* Launch Date: Sept 2nd, 2013<br />
<br />
=== GoldCoin (GLD) ===<br />
* http://gldcoin.com/<br />
* https://www.gldtalk.org/<br />
* https://bitcointalk.org/index.php?topic=317568.0<br />
* blocks every '''2 minutes'''<br />
* coin supply* '''123 million''' coins will be available<br />
* difficulty adjustment* '''60 blocks'''<br />
* hashing algorithm '''Scrypt'''<br />
* reward '''45''' coins per block<br />
<br />
<br />
== Dead / dying ==<br />
===Qubic===<br />
https://bitcointalk.org/index.php?topic=112676.0<br />
Qubic Forum: http://qubic.boards.net<br />
===TimeKoin===<br />
Still alive* http://timekoin.org/* https://bitcointalk.org/index.php topic=88467.0<br />
===SC Solidcoin===<br />
scam?* https://en.bitcoin.it/wiki/SolidCoin ; http://solidcoin.info/<br />
===GG Geist Geld===<br />
https://bitcointalk.org/index.php?topic=42417.0 ; https://github.com/Lolcust/GeistGeld<br />
===TBX Tenebrix===<br />
https://bitcointalk.org/index.php?topic=45667.0 ; https://github.com/Lolcust/Tenebrix<br />
===FBX Fairbrix===<br />
https://bitcointalk.org/index.php?topic=46528.0 ; https://github.com/coblee/Fairbrix<br />
===CLC Coiledcoin===<br />
killed in 51% attack ; https://bitcointalk.org/index.php?topic=56675.0<br />
===RUC Rucoin===<br />
https://www.rucoin.org/ ; https://bitcointalk.org/index.php?topic=48582.0<br />
===MMM MMMcoin===<br />
dead<br />
===Weeds===<br />
[https://bitcointalk.org/index.php?topic=9493.0]<br />
===Beertoken===<br />
[https://bitcointalk.org/index.php?topic=9493.0]<br />
<br />
==See Also==<br />
<br />
* [http://bitcointalk.org/index.php?topic=134179.0 List of all cryptocoins] curated list on BitcoinTalk forum.<br />
<br />
[[Category:Alternative cryptocurrencies]]</div>Ripper234https://en.bitcoin.it/w/index.php?title=Distributed_Autonomous_Community_/_Decentralized_Application&diff=43707Distributed Autonomous Community / Decentralized Application2014-01-12T08:28:06Z<p>Ripper234: </p>
<hr />
<div>A '''Distributed Autonomous Community''' ('''DAC''') is an "entity" without any central point of control, with a certain agenda, business plan, and protocol. A '''Decentralized Application''' or '''DA''' is an alternative formulation of a DAC. The concept is currently being developed by David Johnston.<br />
<br />
There is an accelerating trend of more and more DACs being formed.<br />
<br />
== List of DACs ==<br />
* [[Bitcoin]] itself, the first DAC?<br />
* Altcurrencies, all of Bitcoin forks<br />
* [[Ripple]] Labs is borderline ... they are a registered company and could be ordered to shutdown. The protocol is perhaps a DAC.<br />
* [[Mastercoin]], a DAC replacement for Forex, Shares, and much more. Later evolved into a ProtoShares competitor.<br />
* [[ProtoShares]], a meta DAC with the purpose of provding infrastructure for other DACs. It is composed of<br />
** DomainShares, a DAC replacement for Namecoin<br />
** BitShares, a competitor to Mastercoin <!-- (with much more limited feature set IMHO) --><br />
** Keyhotee, a DAC replacement for OpenID<br />
** Other infrastructure components to follow... ? <br />
* [[Mitosys]] - a DAC replacement for Bit-Message<br />
* [[Colored Coins]] are working on defining themselves as a DAC ... no working business model spotted yet.<br />
<br />
== Ideas ==<br />
* A social network - Monetizable Diaspora<br />
<br />
<br />
== External links ==<br />
* [http://bitcoinmagazine.com/7050/bootstrapping-a-decentralized-autonomous-corporation-part-i/ Bitcoin Magazine: Bootstrapping a DAC]<br />
* [http://bitsharestalk.org/index.php?topic=297.0 Topic on bitsharestalk]<br />
* [http://invictus-innovations.com/i-dac/ What is a DAC?]<br />
* [http://invictus-innovations.com/i-dac-1/ The Three Laws of Robotics for DACs]<br />
* [https://github.com/DavidJohnstonCEO/DecentralizedApplications Decentralized Application]<br />
<br />
{{stub}}<br />
[[Category:DACs]]</div>Ripper234https://en.bitcoin.it/w/index.php?title=Irreversible_Transactions&diff=43569Irreversible Transactions2014-01-06T08:34:16Z<p>Ripper234: /* Vector76 attack */</p>
<hr />
<div>Double-spending is the result of successfully spending some money more than once. Bitcoin protects against double spending by verifying each transaction added to the [[block chain]] to ensure that the inputs for the transaction had not previously already been spent.<br />
<br />
Other electronic systems prevent double-spending by having a master authoritative source that follows business rules for authorizing each transaction. Bitcoin uses a decentralized system, where a consensus among nodes following the same protocol is substituted for a central authority. <br />
<br />
Bitcoin has some exposure to fraudulent double-spending when a transaction is first made, with less and less risk as a transaction gains [[confirmation|confirmations]].<br />
<br />
==Attack vectors==<br />
<br />
===Race attack===<br />
<br />
Traders and merchants who accept a payment immediately on seeing "0/unconfirmed" are exposed to a double-spend occurring is there was a fraudulent attempt that successfully communicated one transaction to the merchant yet communicated a different transaction that spends the same coin that was first to eventually make it into the block chain.<br />
<br />
Merchants can take precautions (e.g., disable incoming connections, only connect to well connected nodes) to lessen the risk of a race attack but the risk cannot be eliminated. Therefore, the cost/benefit of the risk needs to be considered when accepting payment on 0/unconfirmed when there is no recourse against the attacker.<br />
<br />
The [[research]] paper [http://eprint.iacr.org/2012/248.pdf Two Bitcoins at the Price of One] finds that the protocol allows a high degree of success by an attacker in performing race attacks. The method studied in the research paper depends on access to the merchant's Bitcoin node which is why that even prior to this paper, recommendations for merchants include disabling incoming connections and to choose specific outgoing connections<ref>[http://bitcointalk.org/index.php?topic=79090.msg881283#msg881283 BitcoinTalk Thread - Two Bitcoins at the Price of One]</ref>.<br />
<br />
===Finney attack===<br />
<br />
Another attack the trader or merchant is exposed to when accepting payment on 0/unconfirmed. The Finney attack is a fraudulent double-spend that requires the participation of a miner once a block has been mined<ref>[http://www.bitcointalk.org/index.php?topic=3441.msg48384#msg48384 Best practice for fast transaction acceptance - how high is the risk?]</ref>. The risk of a Finney attack cannot be eliminated regardless of the precautions taken by the merchant, but the participation of a miner is required and a specific sequence of events must occur. Thus the attack is not trivial nor inexpensive to perform and only makes sense for the attacker when the gains from the attack are significant. Just like with the race attack, a trader or merchant should consider the cost / benefit when accepting payment on just one confirmation when there is no recourse against the attacker.<br />
<br />
===Vector76 attack===<br />
<br />
Also referred to as a one-confirmation attack, is a combination of the race attack and the Finney attack such that a transaction that even has one confirmation can still be double-spent. The same protective action for the race attack (no incoming connections, explicit outgoing connection to a well-connected node) significantly reduces the risk of this occurring.<br />
<br />
It is worth noting that a successful attack costs the attacker one block - they need to 'sacrifice' a block by not broadcasting it, and instead relaying it only to the attacked node.<br />
<br />
[https://bitcointalk.org/index.php?topic=36788.msg463391#msg463391 See on bitcointalk]<br />
<br />
===Brute force attack===<br />
<br />
This attack has a chance to work even if the merchant waits for some confirmations, but requires relatively high hashrate.<br />
<br />
The attacker submits to the merchant/network a transaction which pays the merchant, while privately mining a blockchain fork in which a double-spending transaction is included instead. After waiting for ''n'' confirmations, the merchant sends the product. If the attacker happened to find more than ''n'' blocks at this point, he releases his fork and regains his coins; otherwise, he can try to continue extending his fork with the hope of being able to catch up with the network. If he never manages to do this, the attack fails and the payment to the merchant will go through.<br />
<br />
The probability of success is a function of the attacker's hashrate (as a proportion of the total network hashrate) and the number of confirmations the merchant waits for. For example, if the attacker controls 10% of the network hashrate but the merchant waits for 6 confirmations, the success probability is on the order of 0.1%<ref>[https://bitcoil.co.il/Doublespend.pdf Analysis of hashrate-based double-spending]</ref>.<br />
<br />
===>50% attack===<br />
<br />
If the attacker controls more than half of the network hashrate, the previous attack has a probability of 100% to succeed. Since the attacker can generate blocks faster than the rest of the network, he can simply persevere with his private fork until it becomes longer than the branch built by the honest network, from whatever disadvantage.<br />
<br />
No amount of confirmations can prevent this attack; however, waiting for confirmations does increase the aggregate resource cost of performing the attack, which could make it unprofitable or delay it long enough for the circumstances to change or slower-acting synchronization methods to kick in.<br />
<br />
==Risk management==<br />
<br />
There are third-party services to assist traders and merchants to help manage the risk or to insure against losses.<br />
<br />
==See Also==<br />
<br />
* [[Weaknesses]]<br />
* [http://codinginmysleep.com/bitcoin-attacks-in-plain-english Bitcoin Attacks in Plain English] by David Perry<br />
<br />
[[de:Doppelausgaben]]<br />
<br />
==References==<br />
<references /><br />
<br />
[[Category:Technical]]</div>Ripper234https://en.bitcoin.it/w/index.php?title=Irreversible_Transactions&diff=43568Irreversible Transactions2014-01-06T08:31:24Z<p>Ripper234: /* Vector76 attack */ Add reference</p>
<hr />
<div>Double-spending is the result of successfully spending some money more than once. Bitcoin protects against double spending by verifying each transaction added to the [[block chain]] to ensure that the inputs for the transaction had not previously already been spent.<br />
<br />
Other electronic systems prevent double-spending by having a master authoritative source that follows business rules for authorizing each transaction. Bitcoin uses a decentralized system, where a consensus among nodes following the same protocol is substituted for a central authority. <br />
<br />
Bitcoin has some exposure to fraudulent double-spending when a transaction is first made, with less and less risk as a transaction gains [[confirmation|confirmations]].<br />
<br />
==Attack vectors==<br />
<br />
===Race attack===<br />
<br />
Traders and merchants who accept a payment immediately on seeing "0/unconfirmed" are exposed to a double-spend occurring is there was a fraudulent attempt that successfully communicated one transaction to the merchant yet communicated a different transaction that spends the same coin that was first to eventually make it into the block chain.<br />
<br />
Merchants can take precautions (e.g., disable incoming connections, only connect to well connected nodes) to lessen the risk of a race attack but the risk cannot be eliminated. Therefore, the cost/benefit of the risk needs to be considered when accepting payment on 0/unconfirmed when there is no recourse against the attacker.<br />
<br />
The [[research]] paper [http://eprint.iacr.org/2012/248.pdf Two Bitcoins at the Price of One] finds that the protocol allows a high degree of success by an attacker in performing race attacks. The method studied in the research paper depends on access to the merchant's Bitcoin node which is why that even prior to this paper, recommendations for merchants include disabling incoming connections and to choose specific outgoing connections<ref>[http://bitcointalk.org/index.php?topic=79090.msg881283#msg881283 BitcoinTalk Thread - Two Bitcoins at the Price of One]</ref>.<br />
<br />
===Finney attack===<br />
<br />
Another attack the trader or merchant is exposed to when accepting payment on 0/unconfirmed. The Finney attack is a fraudulent double-spend that requires the participation of a miner once a block has been mined<ref>[http://www.bitcointalk.org/index.php?topic=3441.msg48384#msg48384 Best practice for fast transaction acceptance - how high is the risk?]</ref>. The risk of a Finney attack cannot be eliminated regardless of the precautions taken by the merchant, but the participation of a miner is required and a specific sequence of events must occur. Thus the attack is not trivial nor inexpensive to perform and only makes sense for the attacker when the gains from the attack are significant. Just like with the race attack, a trader or merchant should consider the cost / benefit when accepting payment on just one confirmation when there is no recourse against the attacker.<br />
<br />
===Vector76 attack===<br />
<br />
Also referred to as a one-confirmation attack, is a combination of the race attack and the Finney attack such that a transaction that even has one confirmation can still be double-spent. The same protective action for the race attack (no incoming connections, explicit outgoing connection to a well-connected node) significantly reduces the risk of this occurring.<br />
<br />
[https://bitcointalk.org/index.php?topic=36788.msg463391#msg463391 See on bitcointalk]<br />
<br />
===Brute force attack===<br />
<br />
This attack has a chance to work even if the merchant waits for some confirmations, but requires relatively high hashrate.<br />
<br />
The attacker submits to the merchant/network a transaction which pays the merchant, while privately mining a blockchain fork in which a double-spending transaction is included instead. After waiting for ''n'' confirmations, the merchant sends the product. If the attacker happened to find more than ''n'' blocks at this point, he releases his fork and regains his coins; otherwise, he can try to continue extending his fork with the hope of being able to catch up with the network. If he never manages to do this, the attack fails and the payment to the merchant will go through.<br />
<br />
The probability of success is a function of the attacker's hashrate (as a proportion of the total network hashrate) and the number of confirmations the merchant waits for. For example, if the attacker controls 10% of the network hashrate but the merchant waits for 6 confirmations, the success probability is on the order of 0.1%<ref>[https://bitcoil.co.il/Doublespend.pdf Analysis of hashrate-based double-spending]</ref>.<br />
<br />
===>50% attack===<br />
<br />
If the attacker controls more than half of the network hashrate, the previous attack has a probability of 100% to succeed. Since the attacker can generate blocks faster than the rest of the network, he can simply persevere with his private fork until it becomes longer than the branch built by the honest network, from whatever disadvantage.<br />
<br />
No amount of confirmations can prevent this attack; however, waiting for confirmations does increase the aggregate resource cost of performing the attack, which could make it unprofitable or delay it long enough for the circumstances to change or slower-acting synchronization methods to kick in.<br />
<br />
==Risk management==<br />
<br />
There are third-party services to assist traders and merchants to help manage the risk or to insure against losses.<br />
<br />
==See Also==<br />
<br />
* [[Weaknesses]]<br />
* [http://codinginmysleep.com/bitcoin-attacks-in-plain-english Bitcoin Attacks in Plain English] by David Perry<br />
<br />
[[de:Doppelausgaben]]<br />
<br />
==References==<br />
<references /><br />
<br />
[[Category:Technical]]</div>Ripper234https://en.bitcoin.it/w/index.php?title=Talk:Decentralized_Autonomous_Corporation_/_Decentralized_Application&diff=43344Talk:Decentralized Autonomous Corporation / Decentralized Application2013-12-21T08:10:29Z<p>Ripper234: Ripper234 moved page Talk:Decentralized Autonomous Corporation / Decentralized Application to Talk:Distributed Autonomous Community / Decentralized Application: Rename to follow Protoshares latest terminology (protoshares.com)</p>
<hr />
<div>#REDIRECT [[Talk:Distributed Autonomous Community / Decentralized Application]]</div>Ripper234