[ { "id": 1, "sent_from": "Satoshi Nakamoto", "subject": "Bitcoin P2P e-cash paper", "text": "I've been working on a new electronic cash system that's fully\npeer-to-peer, with no trusted third party.\n\nThe paper is available at:\nhttp://www.bitcoin.org/bitcoin.pdf\n\nThe main properties:\n Double-spending is prevented with a peer-to-peer network.\n No mint or other trusted parties.\n Participants can be anonymous.\n New coins are made from Hashcash style proof-of-work.\n The proof-of-work for new coin generation also powers the\n network to prevent double-spending.\n\nBitcoin: A Peer-to-Peer Electronic Cash System\n\nAbstract. A purely peer-to-peer version of electronic cash would\nallow online payments to be sent directly from one party to another\nwithout the burdens of going through a financial institution.\nDigital signatures provide part of the solution, but the main\nbenefits are lost if a trusted party is still required to prevent\ndouble-spending. We propose a solution to the double-spending\nproblem using a peer-to-peer network. The network timestamps\ntransactions by hashing them into an ongoing chain of hash-based\nproof-of-work, forming a record that cannot be changed without\nredoing the proof-of-work. The longest chain not only serves as\nproof of the sequence of events witnessed, but proof that it came\nfrom the largest pool of CPU power. As long as honest nodes control\nthe most CPU power on the network, they can generate the longest\nchain and outpace any attackers. The network itself requires\nminimal structure. Messages are broadcasted on a best effort basis,\nand nodes can leave and rejoin the network at will, accepting the\nlongest proof-of-work chain as proof of what happened while they\nwere gone.\n\nFull paper at:\nhttp://www.bitcoin.org/bitcoin.pdf\n\nSatoshi Nakamoto\n\n---------------------------------------------------------------------\nThe Cryptography Mailing List\nUnsubscribe by sending \"unsubscribe cryptography\" to majordomo at metzdowd.com\n\n", "source": "cryptography", "original_date": "Fri Oct 31 14:10:00 EDT 2008", "date": "2008-10-31T18:10:00Z", "url": "http://www.metzdowd.com/pipermail/cryptography/2008-October/014810.html", "thread_id": 1, "source_id": "014810", "satoshi_id": 1 }, { "id": 2, "sent_from": "James A. Donald", "subject": "Bitcoin P2P e-cash paper", "text": "Satoshi Nakamoto wrote:\n> I've been working on a new electronic cash system that's fully\n> peer-to-peer, with no trusted third party.\n> \n> The paper is available at:\n> http://www.bitcoin.org/bitcoin.pdf\n\nWe very, very much need such a system, but the way I understand your \nproposal, it does not seem to scale to the required size.\n\nFor transferable proof of work tokens to have value, they must have \nmonetary value. To have monetary value, they must be transferred within \na very large network - for example a file trading network akin to \nbittorrent.\n\nTo detect and reject a double spending event in a timely manner, one \nmust have most past transactions of the coins in the transaction, which, \n naively implemented, requires each peer to have most past \ntransactions, or most past transactions that occurred recently. If \nhundreds of millions of people are doing transactions, that is a lot of \nbandwidth - each must know all, or a substantial part thereof.\n\n---------------------------------------------------------------------\nThe Cryptography Mailing List\nUnsubscribe by sending \"unsubscribe cryptography\" to majordomo at metzdowd.com\n\n", "source": "cryptography", "original_date": "Sun Nov 2 18:46:23 EST 2008", "date": "2008-11-02T23:46:23Z", "url": "http://www.metzdowd.com/pipermail/cryptography/2008-November/014814.html", "thread_id": 1, "source_id": "014814", "parent_id": 1 }, { "id": 3, "sent_from": "Satoshi Nakamoto", "subject": "Bitcoin P2P e-cash paper", "text": ">Satoshi Nakamoto wrote:\n>> I've been working on a new electronic cash system that's fully\n>> peer-to-peer, with no trusted third party.\n>> \n>> The paper is available at:\n>> http://www.bitcoin.org/bitcoin.pdf\n>\n>We very, very much need such a system, but the way I understand your \n>proposal, it does not seem to scale to the required size.\n>\n>For transferable proof of work tokens to have value, they must have \n>monetary value. To have monetary value, they must be transferred within \n>a very large network - for example a file trading network akin to \n>bittorrent.\n>\n>To detect and reject a double spending event in a timely manner, one \n>must have most past transactions of the coins in the transaction, which, \n> naively implemented, requires each peer to have most past \n>transactions, or most past transactions that occurred recently. If \n>hundreds of millions of people are doing transactions, that is a lot of \n>bandwidth - each must know all, or a substantial part thereof.\n>\n\n\nLong before the network gets anywhere near as large as that, it would be safe for users to use Simplified Payment Verification (section 8) to check for double spending, which only requires having the chain of block headers, or about 12KB per day. Only people trying to create new coins would need to run network nodes. At first, most users would run network nodes, but as the network grows beyond a certain point, it would be left more and more to specialists with server farms of specialized hardware. A server farm would only need to have one node on the network and the rest of the LAN connects with that one node.\n\nThe bandwidth might not be as prohibitive as you think. A typical transaction would be about 400 bytes (ECC is nicely compact). Each transaction has to be broadcast twice, so lets say 1KB per transaction. Visa processed 37 billion transactions in FY2008, or an average of 100 million transactions per day. That many transactions would take 100GB of bandwidth, or the size of 12 DVD or 2 HD quality movies, or about $18 worth of bandwidth at current prices.\n\nIf the network were to get that big, it would take several years, and by then, sending 2 HD movies over the Internet would probably not seem like a big deal. \n\nSatoshi Nakamoto\n\n---------------------------------------------------------------------\nThe Cryptography Mailing List\nUnsubscribe by sending \"unsubscribe cryptography\" to majordomo at metzdowd.com\n\n", "source": "cryptography", "original_date": "Sun Nov 2 20:37:43 EST 2008", "date": "2008-11-03T01:37:43Z", "url": "http://www.metzdowd.com/pipermail/cryptography/2008-November/014815.html", "thread_id": 1, "source_id": "014815", "parent_id": 2, "satoshi_id": 2 }, { "id": 4, "sent_from": "John Levine", "subject": "Bitcoin P2P e-cash paper", "text": "> As long as honest nodes control the most CPU power on the network,\n> they can generate the longest chain and outpace any attackers.\n\nBut they don't. Bad guys routinely control zombie farms of 100,000\nmachines or more. People I know who run a blacklist of spam sending\nzombies tell me they often see a million new zombies a day.\n\nThis is the same reason that hashcash can't work on today's Internet\n-- the good guys have vastly less computational firepower than the bad\nguys.\n\nI also have my doubts about other issues, but this one is the killer.\n\nR's,\nJohn\n\n\n---------------------------------------------------------------------\nThe Cryptography Mailing List\nUnsubscribe by sending \"unsubscribe cryptography\" to majordomo at metzdowd.com\n\n", "source": "cryptography", "original_date": "Mon Nov 3 08:32:39 EST 2008", "date": "2008-11-03T13:32:39Z", "url": "http://www.metzdowd.com/pipermail/cryptography/2008-November/014817.html", "thread_id": 1, "source_id": "014817", "parent_id": 1 }, { "id": 5, "sent_from": "Satoshi Nakamoto", "subject": "Bitcoin P2P e-cash paper", "text": ">> As long as honest nodes control the most CPU power on the network,\n>> they can generate the longest chain and outpace any attackers.\n>\n>But they don't. Bad guys routinely control zombie farms of 100,000\n>machines or more. People I know who run a blacklist of spam sending\n>zombies tell me they often see a million new zombies a day.\n>\n>This is the same reason that hashcash can't work on today's Internet\n>-- the good guys have vastly less computational firepower than the bad\n>guys.\n\nThanks for bringing up that point.\n\nI didn't really make that statement as strong as I could have. The requirement is that the good guys collectively have more CPU power than any single attacker. \n\nThere would be many smaller zombie farms that are not big enough to overpower the network, and they could still make money by generating bitcoins. The smaller farms are then the \"honest nodes\". (I need a better term than \"honest\") The more smaller farms resort to generating bitcoins, the higher the bar gets to overpower the network, making larger farms also too small to overpower it so that they may as well generate bitcoins too. According to the \"long tail\" theory, the small, medium and merely large farms put together should add up to a lot more than the biggest zombie farm.\n\nEven if a bad guy does overpower the network, it's not like he's instantly rich. All he can accomplish is to take back money he himself spent, like bouncing a check. To exploit it, he would have to buy something from a merchant, wait till it ships, then overpower the network and try to take his money back. I don't think he could make as much money trying to pull a carding scheme like that as he could by generating bitcoins. With a zombie farm that big, he could generate more bitcoins than everyone else combined.\n\nThe Bitcoin network might actually reduce spam by diverting zombie farms to generating bitcoins instead.\n\nSatoshi Nakamoto\n\n---------------------------------------------------------------------\nThe Cryptography Mailing List\nUnsubscribe by sending \"unsubscribe cryptography\" to majordomo at metzdowd.com\n\n", "source": "cryptography", "original_date": "Mon Nov 3 11:23:49 EST 2008", "date": "2008-11-03T16:23:49Z", "url": "http://www.metzdowd.com/pipermail/cryptography/2008-November/014818.html", "thread_id": 1, "source_id": "014818", "parent_id": 4, "satoshi_id": 3 }, { "id": 6, "sent_from": "James A. Donald", "subject": "Bitcoin P2P e-cash paper", "text": "James A. Donald:\n > > To detect and reject a double spending event in a\n > > timely manner, one must have most past transactions\n > > of the coins in the transaction, which, naively\n > > implemented, requires each peer to have most past\n > > transactions, or most past transactions that\n > > occurred recently. If hundreds of millions of people\n > > are doing transactions, that is a lot of bandwidth -\n > > each must know all, or a substantial part thereof.\n\nSatoshi Nakamoto wrote:\n > Long before the network gets anywhere near as large as\n > that, it would be Safe for users to use Simplified\n > Payment Verification (section 8) to check for double\n > spending, which only requires having the chain of\n > block headers,\n\nIf I understand Simplified Payment Verification\ncorrectly:\n\nNew coin issuers need to store all coins and all recent\ncoin transfers.\n\nThere are many new coin issuers, as many as want to be\nissuers, but far more coin users.\n\nOrdinary entities merely transfer coins. To see if a\ncoin transfer is OK, they report it to one or more new\ncoin issuers and see if the new coin issuer accepts it.\nNew coin issuers check transfers of old coins so that\ntheir new coins have valid form, and they report the\noutcome of this check so that people will report their\ntransfers to the new coin issuer.\n\nIf someone double spends a coin, and one expenditure is\nreported to one new coin issuer, and the other\nsimultaneously reported to another new coin issuer, then\nboth issuers to swifly agree on a unique sequence order\nof payments. This, however, is a non trivial problem of\na massively distributed massive database, a notoriously\ntricky problem, for which there are at present no peer\nto peer solutions. Obiously it is a solvable problem,\npeople solve it all the time, but not an easy problem.\nPeople fail to solve it rather more frequently.\n\n But let us suppose that the coin issue network is\ndominated by a small number of issuers as seems likely.\n\nIf a small number of entities are issuing new coins,\nthis is more resistant to state attack that with a\nsingle issuer, but the government regularly attacks\nfinancial networks, with the financial collapse ensuing\nfrom the most recent attack still under way as I write\nthis.\n\nGovernment sponsored enterprises enter the business, in\ndue course bad behavior is made mandatory, and the evil\nfinancial network is bigger than the honest financial\nnetwork, with the result that even though everyone knows\nwhat is happening, people continue to use the paper\nissued by the evil financial network, because of network\neffects - the big, main issuers, are the issuers you use\nif you want to do business.\n\nThen knowledgeable people complain that the evil\nfinancial network is heading for disaster, that the\ngovernment sponsored enterprises are about to cause a\n\"collapse of the total financial system\", as Wallison\nand Alan Greenspan complained in 2005, the government\ndebates shrinking the evil government sponsored\nenterprises, as with \"S. 190 [109th]: Federal Housing\nEnterprise Regulatory Reform Act of 2005\" but they find\neasy money too seductive, and S. 190 goes down in flames\nbefore a horde of political activists chanting that easy\nmoney is sound, and opposing it is racist, nazi,\nignorant, and generally hateful, the recent S. 190\ndebate on limiting portfolios (bond issue supporting dud\nmortgages) by government sponsored enterprises being a\nperfect reprise of the debates on limiting the issue of\nnew assignats in the 1790s.\n\nThe big and easy government attacks on money target a\nsingle central money issuer, as with the first of the\nmodern political attacks, the French Assignat of 1792,\nbut in the late nineteenth century political attacks on\nfinancial networks began, as for example the Federal\nreserve act of 1913, the goal always being to wind up\nthe network into a single too big to fail entity, and\nthey have been getting progressively bigger, more\nserious, and more disastrous, as with the most recent\none. Each attack is hugely successful, and after the\ncataclysm that the attack causes the attackers are\nhailed as saviors of the poor, the oppressed, and the\nnation generally, and the blame for the the bad\nconsequences is dumped elsewhere, usually on Jews,\ngreedy bankers, speculators, etc, because such attacks\nare difficult for ordinary people understand. I have\ntrouble understanding your proposal - ordinary users\nwill be easily bamboozled by a government sponsored\nsecurity update. Further, when the crisis hits, to\ndisagree with the line, to doubt that the regulators are\nright, and the problem is the evil speculators, becomes\npolitical suicide, as it did in America in 2007,\nsometimes physical suicide, as in Weimar Germany.\n\nStill, it is better, and more resistant to attack by\ngovernment sponsored enterprises, than anything I have\nseen so far.\n\n > Visa processed 37 billion transactions in FY2008, or\n > an average of 100 million transactions per day. That\n > many transactions would take 100GB of bandwidth, or\n > the size of 12 DVD or 2 HD quality movies, or about\n > $18 worth of bandwidth at current prices.\n\n > If the network were to get that big, it would take\n > several years, and by then, sending 2 HD movies over\n > the Internet would probably not seem like a big deal.\n\nIf there were a hundred or a thousand money issuers by\nthe time the government attacks, the kind of government\nattacks on financial networks that we have recently seen\nmight well be more difficult.\n\nBut I think we need to concern ourselves with minimizing\nthe data and bandwidth required by money issuers - for\nsmall coins, the protocol seems wasteful. It would be\nnice to have the full protocol for big coins, and some\nshortcut for small coins wherein people trust account\nbased money for small amounts till they get wrapped up\ninto big coins.\n\nThe smaller the data storage and bandwidth required for\nmoney issuers, the more resistant the system is the kind\nof government attacks on financial networks that we have\nrecently seen.\n\n---------------------------------------------------------------------\nThe Cryptography Mailing List\nUnsubscribe by sending \"unsubscribe cryptography\" to majordomo at metzdowd.com\n\n", "source": "cryptography", "original_date": "Mon Nov 3 15:20:13 EST 2008", "date": "2008-11-03T20:20:13Z", "url": "http://www.metzdowd.com/pipermail/cryptography/2008-November/014819.html", "thread_id": 1, "source_id": "014819", "parent_id": 3 }, { "id": 7, "sent_from": "Ray Dillinger", "subject": "Bitcoin P2P e-cash paper", "text": "On Tue, 2008-11-04 at 06:20 +1000, James A. Donald wrote:\n\n> If I understand Simplified Payment Verification\n> correctly:\n> \n> New coin issuers need to store all coins and all recent\n> coin transfers.\n> \n> There are many new coin issuers, as many as want to be\n> issuers, but far more coin users.\n> \n> Ordinary entities merely transfer coins. To see if a\n> coin transfer is OK, they report it to one or more new\n> coin issuers and see if the new coin issuer accepts it.\n> New coin issuers check transfers of old coins so that\n> their new coins have valid form, and they report the\n> outcome of this check so that people will report their\n> transfers to the new coin issuer.\n\n\nI think the real issue with this system is the market \nfor bitcoins. \n\nComputing proofs-of-work have no intrinsic value. We \ncan have a limited supply curve (although the \"currency\" \nis inflationary at about 35% as that's how much faster \ncomputers get annually) but there is no demand curve \nthat intersects it at a positive price point.\n\nI know the same (lack of intrinsic value) can be said of \nfiat currencies, but an artificial demand for fiat \ncurrencies is created by (among other things) taxation \nand legal-tender laws. Also, even a fiat currency can \nbe an inflation hedge against another fiat currency's \nhigher rate of inflation. But in the case of bitcoins \nthe inflation rate of 35% is almost guaranteed by the \ntechnology, there are no supporting mechanisms for \ntaxation, and no legal-tender laws. People will not \nhold assets in this highly-inflationary currency if \nthey can help it. \n\n Bear\n\n\n---------------------------------------------------------------------\nThe Cryptography Mailing List\nUnsubscribe by sending \"unsubscribe cryptography\" to majordomo at metzdowd.com\n\n", "source": "cryptography", "original_date": "Thu Nov 6 00:14:37 EST 2008", "date": "2008-11-06T05:14:37Z", "url": "http://www.metzdowd.com/pipermail/cryptography/2008-November/014822.html", "thread_id": 1, "source_id": "014822", "parent_id": 6 }, { "id": 8, "sent_from": "Satoshi Nakamoto", "subject": "Bitcoin P2P e-cash paper", "text": ">[Lengthy exposition of vulnerability of a systm to use-of-force\n>monopolies ellided.]\n>\n>You will not find a solution to political problems in cryptography.\n\nYes, but we can win a major battle in the arms race and gain a new territory of freedom for several years.\n\nGovernments are good at cutting off the heads of a centrally controlled networks like Napster, but pure P2P networks like Gnutella and Tor seem to be holding their own. \n\nSatoshi\n\n\n---------------------------------------------------------------------\nThe Cryptography Mailing List\nUnsubscribe by sending \"unsubscribe cryptography\" to majordomo at metzdowd.com\n\n", "source": "cryptography", "original_date": "Thu Nov 6 15:15:40 EST 2008", "date": "2008-11-06T20:15:40Z", "url": "http://www.metzdowd.com/pipermail/cryptography/2008-November/014823.html", "thread_id": 1, "source_id": "014823", "parent_id": 6, "satoshi_id": 4 }, { "id": 9, "sent_from": "Hal Finney", "subject": "Bitcoin P2P e-cash paper", "text": "Bitcoin seems to be a very promising idea. I like the idea of basing\nsecurity on the assumption that the CPU power of honest participants\noutweighs that of the attacker. It is a very modern notion that exploits\nthe power of the long tail. When Wikipedia started I never thought it\nwould work, but it has proven to be a great success for some of the\nsame reasons.\n\nI also do think that there is potential value in a form of unforgeable\ntoken whose production rate is predictable and can't be influenced\nby corrupt parties. This would be more analogous to gold than to fiat\ncurrencies. Nick Szabo wrote many years ago about what he called \"bit\ngold\"[1] and this could be an implementation of that concept. There have\nalso been proposals for building light-weight anonymous payment schemes on\ntop of heavy-weight non-anonymous systems, so Bitcoin could be leveraged\nto allow for anonymity even beyond the mechanisms discussed in the paper.\n\nUnfortunately I am having trouble fully understanding the system. The\npaper describes key concepts and some data structures, but does not\nclearly specify the various rules and verifications that the participants\nin the system would have to follow.\n\nIn particular I don't understand exactly what verifications P2P nodes\nperform when they receive new blocks from other nodes, and how they\nhandle transactions that have been broadcast to them. For example, it\nis mentioned that if a broadcast transaction does not reach all nodes,\nit is OK, as it will get into the block chain before long. How does this\nhappen - what if the node that creates the \"next\" block (the first node\nto find the hashcash collision) did not hear about the transaction,\nand then a few more blocks get added also by nodes that did not hear\nabout that transaction? Do all the nodes that did hear it keep that\ntransaction around, hoping to incorporate it into a block once they get\nlucky enough to be the one which finds the next collision?\n\nOr for example, what if a node is keeping two or more chains around as\nit waits to see which grows fastest, and a block comes in for chain A\nwhich would include a double-spend of a coin that is in chain B? Is that\nchecked for or not? (This might happen if someone double-spent and two\ndifferent sets of nodes heard about the two different transactions with\nthe same coin.)\n\nThis kind of data management, and the rules for handling all the packets\nthat are flowing around is largely missing from the paper.\n\nI also don't understand exactly how double-spending, or cancelling\ntransactions, is accomplished by a superior attacker who is able to muster\nmore computing power than all the honest participants. I see that he can\ncreate new blocks and add them to create the longest chain, but how can\nhe erase or add old transactions in the chain? As the attacker sends out\nhis new blocks, aren't there consistency checks which honest nodes can\nperform, to make sure that nothing got erased? More explanation of this\nattack would be helpful, in order to judge the gains to an attacker from\nthis, versus simply using his computing power to mint new coins honestly.\n\nAs far as the spending transactions, what checks does the recipient of a\ncoin have to perform? Does she need to go back through the coin's entire\nhistory of transfers, and make sure that every transaction on the list is\nindeed linked into the \"timestamp\" block chain? Or can she just do the\nlatest one? Do the timestamp nodes check transactions, making sure that\nthe previous transaction on a coin is in the chain, thereby enforcing\nthe rule that all transactions in the chain represent valid coins?\n\nSorry about all the questions, but as I said this does seem to be a\nvery promising and original idea, and I am looking forward to seeing\nhow the concept is further developed. It would be helpful to see a more\nprocess oriented description of the idea, with concrete details of the\ndata structures for the various objects (coins, blocks, transactions),\nthe data which is included in messages, and algorithmic descriptions\nof the procedures for handling the various events which would occur in\nthis system. You mentioned that you are working on an implementation,\nbut I think a more formal, text description of the system would be a\nhelpful next step.\n\nHal Finney\n\n[1] http://unenumerated.blogspot.com/2005/12/bit-gold.html\n\n---------------------------------------------------------------------\nThe Cryptography Mailing List\nUnsubscribe by sending \"unsubscribe cryptography\" to majordomo at metzdowd.com\n\n", "source": "cryptography", "original_date": "Fri Nov 7 18:40:12 EST 2008", "date": "2008-11-07T23:40:12Z", "url": "http://www.metzdowd.com/pipermail/cryptography/2008-November/014827.html", "thread_id": 1, "source_id": "014827", "parent_id": 1 }, { "id": 10, "sent_from": "Satoshi Nakamoto", "subject": "Bitcoin P2P e-cash paper", "text": "Ray Dillinger:\n> the \"currency\" is inflationary at about 35% \n> as that's how much faster computers get annually\n> ... the inflation rate of 35% is almost guaranteed \n> by the technology\n\nIncreasing hardware speed is handled: \"To compensate for increasing hardware speed and varying interest in running nodes over time, the proof-of-work difficulty is determined by a moving average targeting an average number of blocks per hour. If they're generated too fast, the difficulty increases.\"\n\nAs computers get faster and the total computing power applied to creating bitcoins increases, the difficulty increases proportionally to keep the total new production constant. Thus, it is known in advance how many new bitcoins will be created every year in the future.\n\nThe fact that new coins are produced means the money supply increases by a planned amount, but this does not necessarily result in inflation. If the supply of money increases at the same rate that the number of people using it increases, prices remain stable. If it does not increase as fast as demand, there will be deflation and early holders of money will see its value increase.\n\nCoins have to get initially distributed somehow, and a constant rate seems like the best formula.\n\nSatoshi Nakamoto\n\n\n---------------------------------------------------------------------\nThe Cryptography Mailing List\nUnsubscribe by sending \"unsubscribe cryptography\" to majordomo at metzdowd.com\n\n", "source": "cryptography", "original_date": "Sat Nov 8 13:54:38 EST 2008", "date": "2008-11-08T18:54:38Z", "url": "http://www.metzdowd.com/pipermail/cryptography/2008-November/014831.html", "thread_id": 1, "source_id": "014831", "parent_id": 7, "satoshi_id": 5 }, { "id": 11, "sent_from": "Satoshi Nakamoto", "subject": "Bitcoin P2P e-cash paper", "text": "Hal Finney wrote:\n> it is mentioned that if a broadcast transaction does not reach all nodes,\n> it is OK, as it will get into the block chain before long. How does this\n> happen - what if the node that creates the \"next\" block (the first node\n> to find the hashcash collision) did not hear about the transaction,\n> and then a few more blocks get added also by nodes that did not hear\n> about that transaction? Do all the nodes that did hear it keep that\n> transaction around, hoping to incorporate it into a block once they get\n> lucky enough to be the one which finds the next collision?\n\nRight, nodes keep transactions in their working set until they get into a block. If a transaction reaches 90% of nodes, then each time a new block is found, it has a 90% chance of being in it.\n\n\n> Or for example, what if a node is keeping two or more chains around as\n> it waits to see which grows fastest, and a block comes in for chain A\n> which would include a double-spend of a coin that is in chain B? Is that\n> checked for or not? (This might happen if someone double-spent and two\n> different sets of nodes heard about the two different transactions with\n> the same coin.)\n\nThat does not need to be checked for. The transaction in whichever branch ends up getting ahead becomes the valid one, the other is invalid. If someone tries to double spend like that, one and only one spend will always become valid, the others invalid.\n\nReceivers of transactions will normally need to hold transactions for perhaps an hour or more to allow time for this kind of possibility to be resolved. They can still re-spend the coins immediately, but they should wait before taking an action such as shipping goods. \n\n\n> I also don't understand exactly how double-spending, or cancelling\n> transactions, is accomplished by a superior attacker who is able to muster\n> more computing power than all the honest participants. I see that he can\n> create new blocks and add them to create the longest chain, but how can\n> he erase or add old transactions in the chain? As the attacker sends out\n> his new blocks, aren't there consistency checks which honest nodes can\n> perform, to make sure that nothing got erased? More explanation of this\n> attack would be helpful, in order to judge the gains to an attacker from\n> this, versus simply using his computing power to mint new coins honestly.\n\nThe attacker isn't adding blocks to the end. He has to go back and redo the block his transaction is in and all the blocks after it, as well as any new blocks the network keeps adding to the end while he's doing that. He's rewriting history. Once his branch is longer, it becomes the new valid one.\n\nThis touches on a key point. Even though everyone present may see the shenanigans going on, there's no way to take advantage of that fact. \n\nIt is strictly necessary that the longest chain is always considered the valid one. Nodes that were present may remember that one branch was there first and got replaced by another, but there would be no way for them to convince those who were not present of this. We can't have subfactions of nodes that cling to one branch that they think was first, others that saw another branch first, and others that joined later and never saw what happened. The CPU power proof-of-work vote must have the final say. The only way for everyone to stay on the same page is to believe that the longest chain is always the valid one, no matter what.\n\n\n> As far as the spending transactions, what checks does the recipient of a\n> coin have to perform? Does she need to go back through the coin's entire\n> history of transfers, and make sure that every transaction on the list is\n> indeed linked into the \"timestamp\" block chain? Or can she just do the\n> latest one? \n\nThe recipient just needs to verify it back to a depth that is sufficiently far back in the block chain, which will often only require a depth of 2 transactions. All transactions before that can be discarded.\n\n\n> Do the timestamp nodes check transactions, making sure that\n> the previous transaction on a coin is in the chain, thereby enforcing\n> the rule that all transactions in the chain represent valid coins?\n\nRight, exactly. When a node receives a block, it checks the signatures of every transaction in it against previous transactions in blocks. Blocks can only contain transactions that depend on valid transactions in previous blocks or the same block. Transaction C could depend on transaction B in the same block and B depends on transaction A in an earlier block.\n\n\n> Sorry about all the questions, but as I said this does seem to be a\n> very promising and original idea, and I am looking forward to seeing\n> how the concept is further developed. It would be helpful to see a more\n> process oriented description of the idea, with concrete details of the\n> data structures for the various objects (coins, blocks, transactions),\n> the data which is included in messages, and algorithmic descriptions\n> of the procedures for handling the various events which would occur in\n> this system. You mentioned that you are working on an implementation,\n> but I think a more formal, text description of the system would be a\n> helpful next step.\n\nI appreciate your questions. I actually did this kind of backwards. I had to write all the code before I could convince myself that I could solve every problem, then I wrote the paper. I think I will be able to release the code sooner than I could write a detailed spec. You're already right about most of your assumptions where you filled in the blanks.\n\nSatoshi Nakamoto\n\n\n---------------------------------------------------------------------\nThe Cryptography Mailing List\nUnsubscribe by sending \"unsubscribe cryptography\" to majordomo at metzdowd.com\n\n", "source": "cryptography", "original_date": "Sat Nov 8 20:58:48 EST 2008", "date": "2008-11-09T01:58:48Z", "url": "http://www.metzdowd.com/pipermail/cryptography/2008-November/014832.html", "thread_id": 1, "source_id": "014832", "parent_id": 9, "satoshi_id": 6 }, { "id": 12, "sent_from": "Satoshi Nakamoto", "subject": "Bitcoin P2P e-cash paper", "text": "James A. Donald wrote:\n> The core concept is that lots of entities keep complete and consistent\n> information as to who owns which bitcoins.\n>\n> But maintaining consistency is tricky. It is not clear to me what\n> happens when someone reports one transaction to one maintainer, and\n> someone else transports another transaction to another maintainer. The\n> transaction cannot be known to be valid until it has been incorporated\n> into a globally shared view of all past transactions, and no one can\n> know that a globally shared view of all past transactions is globally\n> shared until after some time has passed, and after many new\n> transactions have arrived.\n>\n> Did you explain how to do this, and it just passed over my head, or\n> were you confident it could be done, and a bit vague as to the details?\n\nThe proof-of-work chain is the solution to the synchronisation problem, and to knowing what the globally shared view is without having to trust anyone.\n\nA transaction will quickly propagate throughout the network, so if two versions of the same transaction were reported at close to the same time, the one with the head start would have a big advantage in reaching many more nodes first. Nodes will only accept the first one they see, refusing the second one to arrive, so the earlier transaction would have many more nodes working on incorporating it into the next proof-of-work. In effect, each node votes for its viewpoint of which transaction it saw first by including it in its proof-of-work effort.\n\nIf the transactions did come at exactly the same time and there was an even split, it's a toss up based on which gets into a proof-of-work first, and that decides which is valid.\n\nWhen a node finds a proof-of-work, the new block is propagated throughout the network and everyone adds it to the chain and starts working on the next block after it. Any nodes that had the other transaction will stop trying to include it in a block, since it's now invalid according to the accepted chain.\n\nThe proof-of-work chain is itself self-evident proof that it came from the globally shared view. Only the majority of the network together has enough CPU power to generate such a difficult chain of proof-of-work. Any user, upon receiving the proof-of-work chain, can see what the majority of the network has approved. Once a transaction is hashed into a link that's a few links back in the chain, it is firmly etched into the global history.\n\nSatoshi Nakamoto\n\n\n---------------------------------------------------------------------\nThe Cryptography Mailing List\nUnsubscribe by sending \"unsubscribe cryptography\" to majordomo at metzdowd.com\n\n", "source": "cryptography", "original_date": "Sat Nov 8 22:09:49 EST 2008", "date": "2008-11-09T03:09:49Z", "url": "http://www.metzdowd.com/pipermail/cryptography/2008-November/014833.html", "thread_id": 1, "source_id": "014833", "parent_id": 8, "satoshi_id": 7 }, { "id": 13, "sent_from": "James A. Donald", "subject": "Bitcoin P2P e-cash paper", "text": "Satoshi Nakamoto wrote:\n > The bandwidth might not be as prohibitive as you\n > think. A typical transaction would be about 400 bytes\n > (ECC is nicely compact). Each transaction has to be\n > broadcast twice, so lets say 1KB per transaction.\n > Visa processed 37 billion transactions in FY2008, or\n > an average of 100 million transactions per day. That\n > many transactions would take 100GB of bandwidth, or\n > the size of 12 DVD or 2 HD quality movies, or about\n > $18 worth of bandwidth at current prices.\n\nThe trouble is, you are comparing with the Bankcard\nnetwork.\n\nBut a new currency cannot compete directly with an old,\nbecause network effects favor the old.\n\nYou have to go where Bankcard does not go.\n\nAt present, file sharing works by barter for bits. This,\nhowever requires the double coincidence of wants. People\nonly upload files they are downloading, and once the\ndownload is complete, stop seeding. So only active\nfiles, files that quite a lot of people want at the same\ntime, are available.\n\nFile sharing requires extremely cheap transactions,\nseveral transactions per second per client, day in and\nday out, with monthly transaction costs being very small\nper client, so to support file sharing on bitcoins, we\nwill need a layer of account money on top of the\nbitcoins, supporting transactions of a hundred\nthousandth the size of the smallest coin, and to support\nanonymity, chaumian money on top of the account money.\n\nLet us call a bitcoin bank a bink. The bitcoins stand\nin the same relation to account money as gold stood in\nthe days of the gold standard. The binks, not trusting\neach other to be liquid when liquidity is most needed,\nsettle out any net discrepancies with each other by\nmoving bit coins around once every hundred thousand\nseconds or so, so bitcoins do not change owners that\noften, Most transactions cancel out at the account\nlevel. The binks demand bitcoins of each other only\nbecause they don't want to hold account money for too\nlong. So a relatively small amount of bitcoins\ninfrequently transacted can support a somewhat larger\namount of account money frequently transacted.\n\n---------------------------------------------------------------------\nThe Cryptography Mailing List\nUnsubscribe by sending \"unsubscribe cryptography\" to majordomo at metzdowd.com\n\n", "source": "cryptography", "original_date": "Sat Nov 8 23:55:23 EST 2008", "date": "2008-11-09T04:55:23Z", "url": "http://www.metzdowd.com/pipermail/cryptography/2008-November/014834.html", "thread_id": 1, "source_id": "014834", "parent_id": 3 }, { "id": 14, "sent_from": "James A. Donald", "subject": "Bitcoin P2P e-cash paper", "text": " --\nSatoshi Nakamoto wrote:\n > The proof-of-work chain is the solution to the\n > synchronisation problem, and to knowing what the\n > globally shared view is without having to trust\n > anyone.\n >\n > A transaction will quickly propagate throughout the\n > network, so if two versions of the same transaction\n > were reported at close to the same time, the one with\n > the head start would have a big advantage in reaching\n > many more nodes first. Nodes will only accept the\n > first one they see, refusing the second one to arrive,\n > so the earlier transaction would have many more nodes\n > working on incorporating it into the next\n > proof-of-work. In effect, each node votes for its\n > viewpoint of which transaction it saw first by\n > including it in its proof-of-work effort.\n\nOK, suppose one node incorporates a bunch of\ntransactions in its proof of work, all of them honest\nlegitimate single spends and another node incorporates a\nslightly different bunch of transactions in its proof of\nwork, all of them equally honest legitimate single\nspends, and both proofs are generated at about the same\ntime.\n\nWhat happens then?\n\n---------------------------------------------------------------------\nThe Cryptography Mailing List\nUnsubscribe by sending \"unsubscribe cryptography\" to majordomo at metzdowd.com\n\n", "source": "cryptography", "original_date": "Sun Nov 9 03:56:53 EST 2008", "date": "2008-11-09T08:56:53Z", "url": "http://www.metzdowd.com/pipermail/cryptography/2008-November/014835.html", "thread_id": 1, "source_id": "014835", "parent_id": 12 }, { "id": 15, "sent_from": "James A. Donald", "subject": "Bitcoin P2P e-cash paper", "text": "Satoshi Nakamoto wrote:\n > Increasing hardware speed is handled: \"To compensate\n > for increasing hardware speed and varying interest in\n > running nodes over time, the proof-of-work difficulty\n > is determined by a moving average targeting an average\n > number of blocks per hour. If they're generated too\n > fast, the difficulty increases.\"\n\nThis does not work - your proposal involves\ncomplications I do not think you have thought through.\n\nFurthermore, it cannot be made to work, as in the\nproposed system the work of tracking who owns what coins\nis paid for by seigniorage, which requires inflation.\n\nThis is not an intolerable flaw - predictable inflation\nis less objectionable than inflation that gets jiggered\naround from time to time to transfer wealth from one\nvoting block to another.\n\n---------------------------------------------------------------------\nThe Cryptography Mailing List\nUnsubscribe by sending \"unsubscribe cryptography\" to majordomo at metzdowd.com\n\n", "source": "cryptography", "original_date": "Sun Nov 9 05:05:05 EST 2008", "date": "2008-11-09T10:05:05Z", "url": "http://www.metzdowd.com/pipermail/cryptography/2008-November/014837.html", "thread_id": 1, "source_id": "014837", "parent_id": 10 }, { "id": 16, "sent_from": "Satoshi Nakamoto", "subject": "Bitcoin P2P e-cash paper", "text": "James A. Donald wrote:\n>OK, suppose one node incorporates a bunch of\n>transactions in its proof of work, all of them honest\n>legitimate single spends and another node incorporates a\n>different bunch of transactions in its proof of\n>work, all of them equally honest legitimate single\n>spends, and both proofs are generated at about the same\n>time.\n>\n>What happens then?\n\nThey both broadcast their blocks. All nodes receive them and keep both, but only work on the one they received first. We'll suppose exactly half received one first, half the other. \n\nIn a short time, all the transactions will finish propagating so that everyone has the full set. The nodes working on each side will be trying to add the transactions that are missing from their side. When the next proof-of-work is found, whichever previous block that node was working on, that branch becomes longer and the tie is broken. Whichever side it is, the new block will contain the other half of the transactions, so in either case, the branch will contain all transactions. Even in the unlikely event that a split happened twice in a row, both sides of the second split would contain the full set of transactions anyway.\n\nIt's not a problem if transactions have to wait one or a few extra cycles to get into a block. \n\nSatoshi Nakamoto\n\n\n\n---------------------------------------------------------------------\nThe Cryptography Mailing List\nUnsubscribe by sending \"unsubscribe cryptography\" to majordomo at metzdowd.com\n\n", "source": "cryptography", "original_date": "Sun Nov 9 11:31:26 EST 2008", "date": "2008-11-09T16:31:26Z", "url": "http://www.metzdowd.com/pipermail/cryptography/2008-November/014838.html", "thread_id": 1, "source_id": "014838", "parent_id": 12, "satoshi_id": 8 }, { "id": 17, "sent_from": "James A. Donald", "subject": "Bitcoin P2P e-cash paper", "text": " --\n > James A. Donald wrote:\n >> OK, suppose one node incorporates a bunch of\n >> transactions in its proof of work, all of them honest\n >> legitimate single spends and another node\n >> incorporates a different bunch of transactions in its\n >> proof of work, all of them equally honest legitimate\n >> single spends, and both proofs are generated at about\n >> the same time.\n >>\n >> What happens then?\n\nSatoshi Nakamoto wrote:\n > They both broadcast their blocks. All nodes receive\n > them and keep both, but only work on the one they\n > received first. We'll suppose exactly half received\n > one first, half the other.\n >\n > In a short time, all the transactions will finish\n > propagating so that everyone has the full set. The\n > nodes working on each side will be trying to add the\n > transactions that are missing from their side. When\n > the next proof-of-work is found, whichever previous\n > block that node was working on, that branch becomes\n > longer and the tie is broken. Whichever side it is,\n > the new block will contain the other half of the\n > transactions, so in either case, the branch will\n > contain all transactions. Even in the unlikely event\n > that a split happened twice in a row, both sides of\n > the second split would contain the full set of\n > transactions anyway.\n >\n > It's not a problem if transactions have to wait one or\n > a few extra cycles to get into a block.\n\nSo what happened to the coin that lost the race?\n\nOn the one hand, we want people who make coins to be\nmotivated to keep and record all transactions, and\nobtain an up to date record of all transactions in a\ntimely manner. On the other hand, it is a bit harsh if\nthe guy who came second is likely to lose his coin.\n\nFurther, your description of events implies restrictions\non timing and coin generation - that the entire network\ngenerates coins slowly compared to the time required for\nnews of a new coin to flood the network, otherwise the\nchains diverge more and more, and no one ever knows\nwhich chain is the winner.\n\nYou need to make these restrictions explicit, for\nnetwork flood time may well be quite slow.\n\nWhich implies that the new coin rate is slower.\n\nWe want spenders to have certainty that their\ntransaction is valid at the time it takes a spend to\nflood the network, not at the time it takes for branch\nraces to be resolved.\n\nAt any given time, for example at 1 040 689 138 seconds\nwe can look back at the past and say:\n\n At 1 040 688 737 seconds, node 5 was *it*, and\n he incorporated all the coins he had discovered\n into the chain, and all the new transactions he\n knew about on top of the previous link\n\n At 1 040 688 792 seconds, node 2 was *it*, and\n he incorporated all the coins he had discovered\n into the chain, and all the new transactions he\n knew about into the chain on top of node 5's\n link.\n\n At 1 040 688 745 seconds, node 7 was *it*, and\n he incorporated all the coins he had discovered\n into the chain, and all the new transactions he\n knew about into the chain on top of node 2's\n link.\n\nBut no one can know who is *it* right now\n\nSo how does one know when to reveal one's coins? One\nsolution is that one does not. One incorporates a hash\nof the coin secret whenever one thinks one might be\n*it*, and after that hash is securely in the chain,\nafter one knows that one was *it* at the time, one can\nthen safely spend the coin that one has found, revealing\nthe secret.\n\nThis solution takes care of the coin revelation problem,\nbut does not solve the spend recording problem. If one\nnode is ignoring all spends that it does not care about,\nit suffers no adverse consequences. We need a protocol\nin which your prospects of becoming *it* also depend on\nbeing seen by other nodes as having a reasonably up to\ndate and complete list of spends - which this protocol\nis not, and your protocol is not either.\n\n---------------------------------------------------------------------\nThe Cryptography Mailing List\nUnsubscribe by sending \"unsubscribe cryptography\" to majordomo at metzdowd.com\n\n", "source": "cryptography", "original_date": "Sun Nov 9 14:57:54 EST 2008", "date": "2008-11-09T19:57:54Z", "url": "http://www.metzdowd.com/pipermail/cryptography/2008-November/014841.html", "thread_id": 1, "source_id": "014841", "parent_id": 16 }, { "id": 18, "sent_from": "Satoshi Nakamoto", "subject": "Bitcoin P2P e-cash paper", "text": "James A. Donald wrote:\n> Furthermore, it cannot be made to work, as in the\n> proposed system the work of tracking who owns what coins\n> is paid for by seigniorage, which requires inflation.\n\nIf you're having trouble with the inflation issue, it's easy to tweak it for transaction fees instead. It's as simple as this: let the output value from any transaction be 1 cent less than the input value. Either the client software automatically writes transactions for 1 cent more than the intended payment value, or it could come out of the payee's side. The incentive value when a node finds a proof-of-work for a block could be the total of the fees in the block.\n\nSatoshi Nakamoto\n\n\n---------------------------------------------------------------------\nThe Cryptography Mailing List\nUnsubscribe by sending \"unsubscribe cryptography\" to majordomo at metzdowd.com\n\n", "source": "cryptography", "original_date": "Sun Nov 9 21:14:30 EST 2008", "date": "2008-11-10T02:14:30Z", "url": "http://www.metzdowd.com/pipermail/cryptography/2008-November/014842.html", "thread_id": 1, "source_id": "014842", "parent_id": 15, "satoshi_id": 9 }, { "id": 19, "sent_from": "Satoshi Nakamoto", "subject": "Bitcoin P2P e-cash paper", "text": "James A. Donald wrote:\n> So what happened to the coin that lost the race?\n>\n> ... it is a bit harsh if the guy who came second \n> is likely to lose his coin.\n\nWhen there are multiple double-spent versions of the same transaction, one and only one will become valid.\n\nThe receiver of a payment must wait an hour or so before believing that it's valid. The network will resolve any possible double-spend races by then.\n\nThe guy who received the double-spend that became invalid never thought he had it in the first place. His software would have shown the transaction go from \"unconfirmed\" to \"invalid\". If necessary, the UI can be made to hide transactions until they're sufficiently deep in the block chain.\n\n\n> Further, your description of events implies restrictions\n> on timing and coin generation - that the entire network\n> generates coins slowly compared to the time required for\n> news of a new coin to flood the network\n\nSorry if I didn't make that clear. The target time between blocks will probably be 10 minutes.\n\nEvery block includes its creation time. If the time is off by more than 36 hours, other nodes won't work on it. If the timespan over the last 6*24*30 blocks is less than 15 days, blocks are being generated too fast and the proof-of-work difficulty doubles. Everyone does the same calculation with the same chain data, so they all get the same result at the same link in the chain.\n\n\n> We want spenders to have certainty that their\n> transaction is valid at the time it takes a spend to\n> flood the network, not at the time it takes for branch\n> races to be resolved.\n\nInstantant non-repudiability is not a feature, but it's still much faster than existing systems. Paper cheques can bounce up to a week or two later. Credit card transactions can be contested up to 60 to 180 days later. Bitcoin transactions can be sufficiently irreversible in an hour or two.\n\n\n> If one node is ignoring all spends that it does not \n> care about, it suffers no adverse consequences.\n\nWith the transaction fee based incentive system I recently posted, nodes would have an incentive to include all the paying transactions they receive.\n\nSatoshi Nakamoto\n\n---------------------------------------------------------------------\nThe Cryptography Mailing List\nUnsubscribe by sending \"unsubscribe cryptography\" to majordomo at metzdowd.com\n\n", "source": "cryptography", "original_date": "Mon Nov 10 17:18:20 EST 2008", "date": "2008-11-10T22:18:20Z", "url": "http://www.metzdowd.com/pipermail/cryptography/2008-November/014843.html", "thread_id": 1, "source_id": "014843", "parent_id": 17, "satoshi_id": 10 }, { "id": 20, "sent_from": "James A. Donald", "subject": "Bitcoin P2P e-cash paper", "text": "Satoshi Nakamoto wrote:\n > When there are multiple double-spent versions of the\n > same transaction, one and only one will become valid.\n\nThat is not the question I am asking.\n\nIt is not trust that worries me, it is how it is\npossible to have a a globally shared view even if\neveryone is well behaved.\n\nThe process for arriving at a globally shared view of\nwho owns what bitgold coins is insufficiently specified.\nOnce specified, then we can start considering whether\neveryone has incentives to behave correctly.\n\nIt is not sufficient that everyone knows X. We also\nneed everyone to know that everyone knows X, and that\neveryone knows that everyone knows that everyone knows X\n- which, as in the Byzantine Generals problem, is the\nclassic hard problem of distributed data processing.\n\nThis problem becomes harder when X is quite possibly a\nvery large amount of data - agreement on who was the\nowner of every bitgold coin at such and such a time.\n\nAnd then on top of that we need everyone to have a\nmotive to behave in such a fashion that agreement\narises. I cannot see that they have motive when I do\nnot know the behavior to be motivated.\n\nYou keep repeating your analysis of the system under\nattack. We cannot say how the system will behave under\nattack until we know how the system is supposed to\nbehave when not under attack.\n\nIf there are a lot of transactions, it is hard to\nefficiently discover the discrepancies between one\nnode's view and another node's view, and because new\ntransactions are always arriving, no two nodes will ever\nhave the same view, even if all nodes are honest, and\nall reported transactions are correct and true single\nspends.\n\nWe should be able to accomplish a system where two nodes\nare likely to come to agreement as to who owned what\nbitgold coins at some very recent past time, but it is\nnot simple to do so.\n\nIf one node constructs a hash that represents its\nknowledge of who owned what bitgold coins at a\nparticular time, and another node wants to check that\nhash, it is not simple to do it in such a way that\nagreement is likely, and disagreement between honest\nwell behaved nodes is efficiently detected and\nefficiently resolved.\n\nAnd if we had a specification of how agreement is\ngenerated, it is not obvious why the second node has\nincentive to check that hash.\n\nThe system has to work in such a way that nodes can\neasily and cheaply change their opinion about recent\ntransactions, so as to reach consensus, but in order to\nprovide finality and irreversibility, once consensus has\nbeen reached, and then new stuff has be piled on top of\nold consensus, in particular new bitgold has been piled\non top of old consensus, it then becomes extremely\ndifficult to go back and change what was decided.\n\nSaying that is how it works, does not give us a method\nto make it work that way.\n\n > The receiver of a payment must wait an hour or so\n > before believing that it's valid. The network will\n > resolve any possible double-spend races by then.\n\nYou keep discussing attacks. I find it hard to think\nabout response to attack when it is not clear to me what\nnormal behavior is in the case of good conduct by each\nand every party.\n\nDistributed databases are *hard* even when all the\ndatabases perfectly follow the will of a single owner.\nMessages get lost, links drop, syncrhonization delays\nbecome abnormal, and entire machines go up in flames,\nand the network as a whole has to take all this in its\nstride.\n\nFiguring out how to do this is hard, even in the\ncomplete absence of attacks. Then when we have figured\nout how to handle all this, then come attacks.\n\n---------------------------------------------------------------------\nThe Cryptography Mailing List\nUnsubscribe by sending \"unsubscribe cryptography\" to majordomo at metzdowd.com\n\n", "source": "cryptography", "original_date": "Thu Nov 13 01:16:31 EST 2008", "date": "2008-11-13T06:16:31Z", "url": "http://www.metzdowd.com/pipermail/cryptography/2008-November/014847.html", "thread_id": 1, "source_id": "014847", "parent_id": 19 }, { "id": 21, "sent_from": "Hal Finney", "subject": "Bitcoin P2P e-cash paper", "text": "James A. Donald writes:\n> Satoshi Nakamoto wrote:\n> > When there are multiple double-spent versions of the\n> > same transaction, one and only one will become valid.\n>\n> That is not the question I am asking.\n>\n> It is not trust that worries me, it is how it is\n> possible to have a a globally shared view even if\n> everyone is well behaved.\n>\n> The process for arriving at a globally shared view of\n> who owns what bitgold coins is insufficiently specified.\n\nI agree that the description is not completely clear on how these matters\nare handled. Satoshi has suggested that releasing source code may be the\nbest way to clarify the design. As I have tried to work through details on\nmy own, it does appear that the rules become rather complicated and indeed\none needs at least a pseudo-code algorithm to specify the behavior. So\nperhaps writing real code is not a bad way to go. I found that there is\na sourceforge project set up for bitgold, although it does not have any\ncode yet.\n\nIn answer to James' specific question, about what happens when different\nnodes see different sets of transactions, due to imperfect broadcast, here\nis how I understand it. Each node must be prepared to maintain potentially\nseveral \"candidate\" block chains, each of which may eventually turn out\nto become the longest one, the one which wins. Once a given block chain\nbecomes sufficiently longer than a competitor, the shorter one can be\ndeleted. This length differential is a parameter which depends on the\nnode's threat model for how much compute power an attacker can marshall,\nin terms of the fraction of the \"honst\" P2P network's work capacity,\nand is estimated in the paper. The idea is that once a chain gets far\nenough behind the longest one, there is essentially no chance that it\ncan ever catch up.\n\nIn order to resolve the issue James raised, I think it is necessary\nthat nodes keep a separate pending-transaction list associated with\neach candidate chain. This list would include all transactions the node\nhas received (via broadcast by the transactees) but which have not yet\nbeen incorporated into that block chain. At any given time, the node is\nworking to extend the longest block chain, and the block it is working\nto find a hash collision for will include all of the pending transactions\nassociated with that chain.\n\nI think that this way, when a candidate chain is deleted because it\ngot too much shorter than the longest one, transactions in it are\nnot lost, but have continued to be present in the pending-transaction\nlist associated with the longest chain, in those nodes which heard the\noriginal transaction broadcast. (I have also considered whether nodes\nshould add transactions to their pending-transaction list that they\nlearn about through blocks from other nodes, even if those blocks do\nnot end up making their way into the longest block chain; but I'm not\nsure if that is necessary or helpful.)\n\nOnce these rules are clarified, more formal modeling will be helpful in\nunderstanding the behavior of the network given imperfect reliability. For\nexample, if on average a fraction f of P2P nodes receive a given\ntransaction broadcast, then I think one would expect 1/f block-creation\ntimes to elapse before the transaction appears in what is destined to\nbecome the longest chain. One might also ask, given that the P2P network\nbroadcast is itself imperfectly reliable, how many candidate chains\nmust a given node keep track of at one time, on average? Or as James\nraised earlier, if the network broadcast is reliable but depends on a\npotentially slow flooding algorithm, how does that impact performance?\n\n> And then on top of that we need everyone to have a\n> motive to behave in such a fashion that agreement\n> arises. I cannot see that they have motive when I do\n> not know the behavior to be motivated.\n\nI am somewhat less worried about motivation. I'd be satisfied if the\nsystem can meet the following criteria:\n\n1. No single node operator, or small collection of node operators\nwhich controls only a small fraction of overall network resources,\ncan effectively cheat, if other players are honest.\n\n2. The long tail of node operators is sufficiently large that no small\ncollection of nodes can control more than a small fraction of overall\nresources. (Here, the \"tail\" refers to a ranking based on amount of\nresources controlled by each operator.)\n\n3. The bitcoin system turns out to be socially useful and valuable, so\nthat node operators feel that they are making a beneficial contribution\nto the world by their efforts (similar to the various \"@Home\" compute\nprojects where people volunteer their compute resources for good causes).\n\nIn this case it seems to me that simple altruism can suffice to keep the\nnetwork running properly.\n\n> Distributed databases are *hard* even when all the\n> databases perfectly follow the will of a single owner.\n> Messages get lost, links drop, syncrhonization delays\n> become abnormal, and entire machines go up in flames,\n> and the network as a whole has to take all this in its\n> stride.\n\nA very good point, and a more complete specification is necessary in order\nto understand how the network will respond to imperfections like this. I\nam looking forward to seeing more detail emerge.\n\nOne thing I might mention is that in many ways bitcoin is two independent\nideas: a way of solving the kinds of problems James lists here, of\ncreating a globally consistent but decentralized database; and then using\nit for a system similar to Wei Dai's b-money (which is referenced in the\npaper) but transaction/coin based rather than account based. Solving the\nglobal, massively decentralized database problem is arguably the harder\npart, as James emphasizes. The use of proof-of-work as a tool for this\npurpose is a novel idea well worth further review IMO.\n\nHal Finney\n\n---------------------------------------------------------------------\nThe Cryptography Mailing List\nUnsubscribe by sending \"unsubscribe cryptography\" to majordomo at metzdowd.com\n\n", "source": "cryptography", "original_date": "Thu Nov 13 11:24:18 EST 2008", "date": "2008-11-13T16:24:18Z", "url": "http://www.metzdowd.com/pipermail/cryptography/2008-November/014848.html", "thread_id": 1, "source_id": "014848", "parent_id": 19 }, { "id": 22, "sent_from": "Satoshi Nakamoto", "subject": "Bitcoin P2P e-cash paper", "text": "James A. Donald wrote:\n> It is not sufficient that everyone knows X. We also\n> need everyone to know that everyone knows X, and that\n> everyone knows that everyone knows that everyone knows X\n> - which, as in the Byzantine Generals problem, is the\n> classic hard problem of distributed data processing.\n\nThe proof-of-work chain is a solution to the Byzantine Generals' Problem. I'll try to rephrase it in that context.\n\nA number of Byzantine Generals each have a computer and want to attack the King's wi-fi by brute forcing the password, which they've learned is a certain number of characters in length. Once they stimulate the network to generate a packet, they must crack the password within a limited time to break in and erase the logs, otherwise they will be discovered and get in trouble. They only have enough CPU power to crack it fast enough if a majority of them attack at the same time.\n\nThey don't particularly care when the attack will be, just that they all agree. It has been decided that anyone who feels like it will announce a time, and whatever time is heard first will be the official attack time. The problem is that the network is not instantaneous, and if two generals announce different attack times at close to the same time, some may hear one first and others hear the other first.\n\nThey use a proof-of-work chain to solve the problem. Once each general receives whatever attack time he hears first, he sets his computer to solve an extremely difficult proof-of-work problem that includes the attack time in its hash. The proof-of-work is so difficult, it's expected to take 10 minutes of them all working at once before one of them finds a solution. Once one of the generals finds a proof-of-work, he broadcasts it to the network, and everyone changes their current proof-of-work computation to include that proof-of-work in the hash they're working on. If anyone was working on a different attack time, they switch to this one, because its proof-of-work chain is now longer.\n\nAfter two hours, one attack time should be hashed by a chain of 12 proofs-of-work. Every general, just by verifying the difficulty of the proof-of-work chain, can estimate how much parallel CPU power per hour was expended on it and see that it must have required the majority of the computers to produce that much proof-of-work in the allotted time. They had to all have seen it because the proof-of-work is proof that they worked on it. If the CPU power exhibited by the proof-of-work chain is sufficient to crack the password, they can safely attack at the agreed time.\n\nThe proof-of-work chain is how all the synchronisation, distributed database and global view problems you've asked about are solved.\n\n\n---------------------------------------------------------------------\nThe Cryptography Mailing List\nUnsubscribe by sending \"unsubscribe cryptography\" to majordomo at metzdowd.com\n\n", "source": "cryptography", "original_date": "Thu Nov 13 17:56:55 EST 2008", "date": "2008-11-13T22:56:55Z", "url": "http://www.metzdowd.com/pipermail/cryptography/2008-November/014849.html", "thread_id": 1, "source_id": "014849", "parent_id": 20, "satoshi_id": 11 }, { "id": 23, "sent_from": "Satoshi Nakamoto", "subject": "Bitcoin P2P e-cash paper", "text": "Hal Finney wrote:\n> I think it is necessary that nodes keep a separate \n> pending-transaction list associated with each candidate chain. \n> ... One might also ask ... how many candidate chains must \n> a given node keep track of at one time, on average?\n\nFortunately, it's only necessary to keep a pending-transaction pool for the current best branch. When a new block arrives for the best branch, ConnectBlock removes the block's transactions from the pending-tx pool. If a different branch becomes longer, it calls DisconnectBlock on the main branch down to the fork, returning the block transactions to the pending-tx pool, and calls ConnectBlock on the new branch, sopping back up any transactions that were in both branches. It's expected that reorgs like this would be rare and shallow.\n\nWith this optimisation, candidate branches are not really any burden. They just sit on the disk and don't require attention unless they ever become the main chain.\n\n\n> Or as James raised earlier, if the network broadcast \n> is reliable but depends on a potentially slow flooding \n> algorithm, how does that impact performance?\n\nBroadcasts will probably be almost completely reliable. TCP transmissions are rarely ever dropped these days, and the broadcast protocol has a retry mechanism to get the data from other nodes after a while. If broadcasts turn out to be slower in practice than expected, the target time between blocks may have to be increased to avoid wasting resources. We want blocks to usually propagate in much less time than it takes to generate them, otherwise nodes would spend too much time working on obsolete blocks.\n\nI'm planning to run an automated test with computers randomly sending payments to each other and randomly dropping packets.\n\n\n> 3. The bitcoin system turns out to be socially useful and valuable, so\n> that node operators feel that they are making a beneficial contribution\n> to the world by their efforts (similar to the various \"@Home\" compute\n> projects where people volunteer their compute resources for good causes).\n> \n> In this case it seems to me that simple altruism can suffice to keep the\n> network running properly.\n\nIt's very attractive to the libertarian viewpoint if we can explain it properly. I'm better with code than with words though.\n\nSatoshi Nakamoto\n\n---------------------------------------------------------------------\nThe Cryptography Mailing List\nUnsubscribe by sending \"unsubscribe cryptography\" to majordomo at metzdowd.com\n\n", "source": "cryptography", "original_date": "Fri Nov 14 13:55:35 EST 2008", "date": "2008-11-14T18:55:35Z", "url": "http://www.metzdowd.com/pipermail/cryptography/2008-November/014853.html", "thread_id": 1, "source_id": "014853", "parent_id": 21, "satoshi_id": 12 }, { "id": 24, "sent_from": "Ray Dillinger", "subject": "Bitcoin P2P e-cash paper", "text": "Okay.... I'm going to summarize this protocol as I understand it. \n\nI'm filling in some operational details that aren't in the paper \nby supplementing what you wrote with what my own \"design sense\" \ntells me are critical missing bits or \"obvious\" methodologies for \nuse.\n\nFirst, people spend computer power creating a pool of coins to use \nas money. Each coin is a proof-of-work meeting whatever criteria \nwere in effect for money at the time it was created. The time of \ncreation (and therefore the criteria) is checkable later because \npeople can see the emergence of this particular coin in the \ntransaction chain and track it through all its \"consensus view\" \nspends. (more later on coin creation tied to adding a link). \n\nWhen a coin is spent, the buyer and seller digitally sign a (blinded) \ntransaction record, and broadcast it to a bunch of nodes whose purpose \nis keeping track of consensus regarding coin ownership. If someone \ndouble spends, then the transaction record can be unblinded revealing \nthe identity of the cheater. This is done via a fairly standard cut-\nand-choose algorithm where the buyer responds to several challenges \nwith secret shares, and the seller then asks him to \"unblind\" and \nchecks all but one, verifying that they do contain secret shares any \ntwo of which are sufficient to identify the buyer. In this case the \nseller accepts the unblinded spend record as \"probably\" containing \na valid secret share. \n\nThe nodes keeping track of consensus regarding coin ownership are in \na loop where they are all trying to \"add a link\" to the longest chain \nthey've so far recieved. They have a pool of reported transactions \nwhich they've not yet seen in a \"consensus\" signed chain. I'm going \nto call this pool \"A\". They attempt to add a link to the chain by\nmoving everything from pool A into a pool \"L\" and using a CPU-\nintensive digital signature algorithm to sign the chain including \nthe new block L. This results in a chain extended by a block \ncontaining all the transaction records they had in pool L, plus \nthe node's digital signature. While they do this, new \ntransaction records continue to arrive and go into pool A again \nfor the next cycle of work. \n\nThey may also recieve chains as long as the one they're trying to \nextend while they work, in which the last few \"links\" are links \nthat are *not* in common with the chain on which they're working.\nThese they ignore. (? Do they ignore them? Under what \ncircumstances would these become necessary to ever look at again, \nbearing in mind that any longer chain based on them will include \nthem?) \n\nBut if they recieve a _longer_ chain while working, they \nimmediately check all the transactions in the new links to make \nsure it contains no double spends and that the \"work factors\" of \nall new links are appropriate. If it contains a double spend, \nthen they create a \"transaction\" which is a proof of double \nspending, add it to their pool A, broadcast it, and continue work. \nIf one of the \"new\" links has an inappropriate work factor (ie, \nsomeone didn't put enough CPU into it for it to be \"licit\" \naccording to the rules) a new \"transaction\" which is a proof \nof the protocol violation by the link-creating node is created, \nbroadcast, and added to pool A, and the chain is rejected. In \nthe case of no double spends and appropriate work factors for \nall links not yet seen, they accept the new chain as consensus. \n\nIf the new chain is accepted, then they give up on adding their\ncurrent link, dump all the transactions from pool L back into pool \nA (along with transactions they've recieved or created since \nstarting work), eliminate from pool A those transaction records \nwhich are already part of a link in the new chain, and start work \nagain trying to extend the new chain. \n\nIf they complete work on a chain extended with their new link, they \nbroadcast it and immediately start work on another new link with \nall the transactions that have accumulated in pool A since they \nbegan work. \n\nDo I understand it correctly?\n\n\n\n\nBiggest Technical Problem: \n\nIs there a mechanism to make sure that the \"chain\" does not consist \nsolely of links added by just the 3 or 4 fastest nodes? 'Cause a \nbroadcast transaction record could easily miss those 3 or 4 nodes \nand if it does, and those nodes continue to dominate the chain, the \ntransaction might never get added. \n\nTo remedy this, you need to either ensure provable propagation of\ntransactions, or vary the work factor for a node depending on how \nmany links have been added since that node's most recent link. \n\nUnfortunately, both measures can be defeated by sock puppets. \nThis is probably the worst problem with your protocol as it \nstands right now; you need some central point to control the \nidentities (keys) of the nodes and prevent people from making \nnew sock puppets. \n\nProvable propagation would mean that When Bob accepts a new chain \nfrom Alice, he needs to make sure that Alice has (or gets) all\ntransactions in his \"A\" and \"L\" pools. He sends them, and \nAlice sends back a signed hash to prove she got them. Once \nAlice has recieved this block of transactions, if any subsequent \nchains including a link added by Alice do not include those \ntransactions at or before that link, then Bob should be able to \npublish the block he sent Alice, along with her signature, in a\ntransaction as proof that Alice violated protocol. Sock puppets \ndefeat this because Alice just signs subsequent chains using a \nnew key, pretending to be a different node. \n\nIf we go with varying the work factor depending on how many new \nlinks there are, then we're right back to domination by the 3 \nor 4 fastest nodes, except now they're joined by 600 or so \nsock puppets which they use to avoid the work factor penalty. \n\nIf we solve the sock-puppet issue, or accept that there's a central \npoint controlling the generation of new keys, then generation of \ncoins should be tied to the act of successfully adding a block to \nthe \"consensus\" chain. This is simple to do; creation of a coin \nis a transaction, it gets added along with all the other transactions \nin the block. But you can only create one coin per link, and of \ncourse if your version of the chain isn't the one that gets accepted,\nthen in the \"accepted\" view you don't have the coin and can't spend \nit. This gives the people maintaining the consensus database a \nreason to spend CPU cycles, especially since the variance in work \nfactor by number of links added since their own last link (outlined\nabove) guarantees that everyone, not just the 3 or 4 fastest nodes,\noccasionally gets the opportunity to create a coin.\n\nAlso, the work requirement for adding a link to the chain should \nvary (again exponentially) with the number of links added to that \nchain in the previous week, causing the rate of coin generation \n(and therefore inflation) to be strictly controlled. \n\nYou need coin aggregation for this to scale. There needs to be \na \"provable\" transaction where someone retires ten single coins \nand creates a new coin with denomination ten, etc. This is not \ntoo hard, using the same infrastructure you've already got; it \nsimply becomes part of the chain, and when the chain is accepted\nconsensus, then everybody can see that it happened. \n\n\n\n Bear\n\n\n\n---------------------------------------------------------------------\nThe Cryptography Mailing List\nUnsubscribe by sending \"unsubscribe cryptography\" to majordomo at metzdowd.com\n\n", "source": "cryptography", "original_date": "Fri Nov 14 21:20:23 EST 2008", "date": "2008-11-15T02:20:23Z", "url": "http://www.metzdowd.com/pipermail/cryptography/2008-November/014857.html", "thread_id": 1, "source_id": "014857", "parent_id": 22 }, { "id": 25, "sent_from": "Satoshi Nakamoto", "subject": "Bitcoin P2P e-cash paper", "text": "I'll try and hurry up and release the sourcecode as soon as possible to serve as a reference to help clear up all these implementation questions.\n\n\nRay Dillinger (Bear) wrote:\n> When a coin is spent, the buyer and seller digitally sign a (blinded)\n> transaction record.\n\nOnly the buyer signs, and there's no blinding. \n\n\n> If someone double spends, then the transaction record \n> can be unblinded revealing the identity of the cheater. \n\nIdentities are not used, and there's no reliance on recourse. It's all prevention.\n\n\n> This is done via a fairly standard cut-and-choose \n> algorithm where the buyer responds to several challenges\n> with secret shares\n\nNo challenges or secret shares. A basic transaction is just what you see in the figure in section 2. A signature (of the buyer) satisfying the public key of the previous transaction, and a new public key (of the seller) that must be satisfied to spend it the next time.\n\n\n> They may also receive chains as long as the one they're trying to\n> extend while they work, in which the last few \"links\" are links\n> that are *not* in common with the chain on which they're working.\n> These they ignore. \n\nRight, if it's equal in length, ties are broken by keeping the earliest one received.\n\n\n> If it contains a double spend, then they create a \"transaction\" \n> which is a proof of double spending, add it to their pool A, \n> broadcast it, and continue work.\n\nThere's no need for reporting of \"proof of double spending\" like that. If the same chain contains both spends, then the block is invalid and rejected. \n\nSame if a block didn't have enough proof-of-work. That block is invalid and rejected. There's no need to circulate a report about it. Every node could see that and reject it before relaying it.\n\nIf there are two competing chains, each containing a different version of the same transaction, with one trying to give money to one person and the other trying to give the same money to someone else, resolving which of the spends is valid is what the whole proof-of-work chain is about.\n\nWe're not \"on the lookout\" for double spends to sound the alarm and catch the cheater. We merely adjudicate which one of the spends is valid. Receivers of transactions must wait a few blocks to make sure that resolution has had time to complete. Would be cheaters can try and simultaneously double-spend all they want, and all they accomplish is that within a few blocks, one of the spends becomes valid and the others become invalid. Any later double-spends are immediately rejected once there's already a spend in the main chain. \n\nEven if an earlier spend wasn't in the chain yet, if it was already in all the nodes' pools, then the second spend would be turned away by all those nodes that already have the first spend.\n\n\n> If the new chain is accepted, then they give up on adding their\n> current link, dump all the transactions from pool L back into pool\n> A (along with transactions they've received or created since\n> starting work), eliminate from pool A those transaction records\n> which are already part of a link in the new chain, and start work\n> again trying to extend the new chain.\n\nRight. They also refresh whenever a new transaction comes in, so L pretty much contains everything in A all the time.\n\n\n> CPU-intensive digital signature algorithm to \n> sign the chain including the new block L. \n\nIt's a Hashcash style SHA-256 proof-of-work (partial pre-image of zero), not a signature. \n\n\n> Is there a mechanism to make sure that the \"chain\" does not consist\n> solely of links added by just the 3 or 4 fastest nodes? 'Cause a\n> broadcast transaction record could easily miss those 3 or 4 nodes\n> and if it does, and those nodes continue to dominate the chain, the\n> transaction might never get added.\n\nIf you're thinking of it as a CPU-intensive digital signing, then you may be thinking of a race to finish a long operation first and the fastest always winning.\n\nThe proof-of-work is a Hashcash style SHA-256 collision finding. It's a memoryless process where you do millions of hashes a second, with a small chance of finding one each time. The 3 or 4 fastest nodes' dominance would only be proportional to their share of the total CPU power. Anyone's chance of finding a solution at any time is proportional to their CPU power.\n\nThere will be transaction fees, so nodes will have an incentive to receive and include all the transactions they can. Nodes will eventually be compensated by transaction fees alone when the total coins created hits the pre-determined ceiling.\n\n\n> Also, the work requirement for adding a link to the chain should\n> vary (again exponentially) with the number of links added to that\n> chain in the previous week, causing the rate of coin generation\n> (and therefore inflation) to be strictly controlled.\n\nRight.\n\n\n> You need coin aggregation for this to scale. There needs to be\n> a \"provable\" transaction where someone retires ten single coins\n> and creates a new coin with denomination ten, etc. \n\nEvery transaction is one of these. Section 9, Combining and Splitting Value. \n\n\nSatoshi Nakamoto\n\n\n\n---------------------------------------------------------------------\nThe Cryptography Mailing List\nUnsubscribe by sending \"unsubscribe cryptography\" to majordomo at metzdowd.com\n\n", "source": "cryptography", "original_date": "Fri Nov 14 23:43:00 EST 2008", "date": "2008-11-15T04:43:00Z", "url": "http://www.metzdowd.com/pipermail/cryptography/2008-November/014858.html", "thread_id": 1, "source_id": "014858", "parent_id": 24, "satoshi_id": 13 }, { "id": 26, "sent_from": "Ray Dillinger", "subject": "Bitcoin P2P e-cash paper", "text": "On Sat, 2008-11-15 at 12:43 +0800, Satoshi Nakamoto wrote:\n\n> I'll try and hurry up and release the sourcecode as soon as possible \n> to serve as a reference to help clear up all these implementation \n> questions.\n\n> Ray Dillinger (Bear) wrote:\n> > When a coin is spent, the buyer and seller digitally sign a (blinded)\n> > transaction record.\n> \n> Only the buyer signs, and there's no blinding. \n> \n> \n> > If someone double spends, then the transaction record \n> > can be unblinded revealing the identity of the cheater. \n> \n> Identities are not used, and there's no reliance on recourse. It's all prevention.\n\nOkay, that's surprising. If you're not using buyer/seller \nidentities, then you are not checking that a spend is being made \nby someone who actually is the owner of (on record as having \nrecieved) the coin being spent. \n\nThere are three categories of identity that are useful to \nthink about. Category one: public. Real-world identities \nare a matter of record and attached to every transaction. \nCategory two: Pseudonymous. There are persistent \"identities\" \nwithin the system and people can see if something was done by \nthe same nym that did something else, but there's not necessarily \nany way of linking the nyms with real-world identities. Category \nthree: unlinkably anonymous. There is no concept of identity,\npersistent or otherwise. No one can say or prove whether the \nagents involved in any transaction are the same agents as involved \nin any other transaction. \n\nAre you claiming category 3 as you seem to be, or category 2?\nLots of people don't distinguish between anonymous and \npseudonymous protocols, so it's worth asking exactly what \nyou mean here. \n\nAnyway: I'll proceed on the assumption that you meant very \nnearly (as nearly as I can imagine, anyway) what you said, \nunlinkably anonymous. That means that instead of an \"identity\", \na spender has to demonstrate knowledge of a secret known only \nto the real owner of the coin. One way to do this would be \nto have the person recieving the coin generate an asymmetric \nkey pair, and then have half of it published with the \ntransaction. In order to spend the coin later, s/he must \ndemonstrate posession of the other half of the asymmetric \nkey pair, probably by using it to sign the key provided by \nthe new seller. So we cannot prove anything about \"identity\", \nbut we can prove that the spender of the coin is someone who \nknows a secret that the person who recieved the coin knows. \n\nAnd what you say next seems to confirm this: \n\n> No challenges or secret shares. A basic transaction is just \n> what you see in the figure in section 2. A signature (of the \n> buyer) satisfying the public key of the previous transaction, \n> and a new public key (of the seller) that must be satisfied to \n> spend it the next time.\n\n\nNote, even though this doesn't involve identity per se, it still \nmakes the agent doing the spend linkable to the agent who \nearlier recieved the coin, so these transactions are linkable. \nIn order to counteract this, the owner of the coin needs to \nmake a transaction, indistinguishable to others from any \nnormal transaction, in which he creates a new key pair and \ntransfers the coin to its posessor (ie, has one sock puppet \n\"spend\" it to another). No change in real-world identity of \nthe owner, but the transaction \"linkable\" to the agent who spent \nthe coin is unlinked. For category-three unlinkability, this \nhas to be done a random number of times - maybe one to six \ntimes? \n\n\nBTW, could you please learn to use carriage returns?? Your \nlines are scrolling stupidly off to the right and I have to \nscroll to see what the heck you're saying, then edit to add \ncarriage returns before I respond. \n\n\n> > If it contains a double spend, then they create a \"transaction\" \n> > which is a proof of double spending, add it to their pool A, \n> > broadcast it, and continue work.\n\n> There's no need for reporting of \"proof of double spending\" like \n> that. If the same chain contains both spends, then the block is \n> invalid and rejected. \n\n> Same if a block didn't have enough proof-of-work. That block is \n> invalid and rejected. There's no need to circulate a report \n> about it. Every node could see that and reject it before relaying it.\n\nMmmm. I don't know if I'm comfortable with that. You're saying \nthere's no effort to identify and exclude nodes that don't \ncooperate? I suspect this will lead to trouble and possible DOS \nattacks. \n\n> If there are two competing chains, each containing a different \n> version of the same transaction, with one trying to give money \n> to one person and the other trying to give the same money to \n> someone else, resolving which of the spends is valid is what \n> the whole proof-of-work chain is about.\n\nOkay, when you say \"same\" transaction, and you're talking about \ntransactions that are obviously different, you mean a double \nspend, right? Two transactions signed with the same key?\n\n> We're not \"on the lookout\" for double spends to sound the alarm \n> and catch the cheater. We merely adjudicate which one of the \n> spends is valid. Receivers of transactions must wait a few \n> blocks to make sure that resolution has had time to complete. \n\nUntil.... until what? How does anybody know when a transaction \nhas become irrevocable? Is \"a few\" blocks three? Thirty? A \nhundred? Does it depend on the number of nodes? Is it logarithmic \nor linear in number of nodes? \n\n \n> Would be cheaters can try and simultaneously double-spend all \n> they want, and all they accomplish is that within a few blocks, \n> one of the spends becomes valid and the others become invalid.\n\nBut in the absence of identity, there's no downside to them \nif spends become invalid, if they've already recieved the \ngoods they double-spent for (access to website, download, \nwhatever). The merchants are left holding the bag with \n\"invalid\" coins, unless they wait that magical \"few blocks\" \n(and how can they know how many?) before treating the spender \nas having paid. \n\nThe consumers won't do this if they spend their coin and it takes \nan hour to clear before they can do what they spent their coin on. \nThe merchants won't do it if there's no way to charge back a \ncustomer when they find the that their coin is invalid because \nthe customer has doublespent.\n\n> Even if an earlier spend wasn't in the chain yet, if it was \n> already in all the nodes' pools, then the second spend would \n> be turned away by all those nodes that already have the first \n> spend.\n\nSo there's a possibility of an early catch when the broadcasts of \nthe initial simultaneous spends interfere with each other. I assume \nhere that the broadcasts are done by the sellers, since the buyer \nhas a possible disincentive to broadly disseminate spends. \n\n> > If the new chain is accepted, then they give up on adding their\n> > current link ... and start work again trying to extend the new \n> > chain.\n> \n> Right. They also refresh whenever a new transaction comes in, \n> so L pretty much contains everything in A all the time.\n\nOkay, that's a big difference between a proof of work that takes \na huge set number of CPU cycles and a proof of work that takes a \ntiny number of CPU cycles but has a tiny chance of success. You \ncan change the data set while working, and it doesn't mean you \nneed to start over. This is good in this case, as it means nobody \nhas to hold recently recieved transactions out of the link they're\nworking on.\n\n> > Is there a mechanism to make sure that the \"chain\" does not consist\n> > solely of links added by just the 3 or 4 fastest nodes? \n\n> If you're thinking of it as a CPU-intensive digital signing, then \n> you may be thinking of a race to finish a long operation first and \n> the fastest always winning.\n\nRight. That was the misconception I was working with. Again, the \ndifference between a proof taking a huge set number of CPU cycles \nand a proof that takes a tiny number of CPU cycles but has a tiny \nchance of success.\n\n> Anyone's chance of finding a solution at any \n> time is proportional to their CPU power.\n\nIt's like a random variation in the work factor; in this way it works \nin your favor. \n\n> There will be transaction fees, so nodes will have an incentive \n> to receive and include all the transactions they can. Nodes \n> will eventually be compensated by transaction fees alone when \n> the total coins created hits the pre-determined ceiling.\n\nI don't understand how \"transaction fees\" would work, and how the money \nwould find its way from the agents doing transactions to those running \nthe network. But the economic effect is the same (albeit somewhat \nrandomized) if adding a link to the chain allows the node to create \na coin, so I would stick with that.\n\nAlso, be aware that the compute power of different nodes can be \nexpected to vary by two orders of magnitude at any given moment in \nhistory. \n\n Bear\n\n\n---------------------------------------------------------------------\nThe Cryptography Mailing List\nUnsubscribe by sending \"unsubscribe cryptography\" to majordomo at metzdowd.com\n\n", "source": "cryptography", "original_date": "Sat Nov 15 02:04:21 EST 2008", "date": "2008-11-15T07:04:21Z", "url": "http://www.metzdowd.com/pipermail/cryptography/2008-November/014859.html", "thread_id": 1, "source_id": "014859", "parent_id": 25 }, { "id": 27, "sent_from": "Satoshi Nakamoto", "subject": "Bitcoin P2P e-cash paper", "text": "Ray Dillinger wrote:\n> One way to do this would be\n> to have the person recieving the coin generate an asymmetric\n> key pair, and then have half of it published with the\n> transaction. In order to spend the coin later, s/he must\n> demonstrate posession of the other half of the asymmetric\n> key pair, probably by using it to sign the key provided by\n> the new seller.\n\nRight, it's ECC digital signatures. A new key pair is used for every\ntransaction.\n\nIt's not pseudonymous in the sense of nyms identifying people, but it\nis at least a little pseudonymous in that the next action on a coin\ncan be identified as being from the owner of that coin.\n\n\n> Mmmm. I don't know if I'm comfortable with that. You're saying\n> there's no effort to identify and exclude nodes that don't\n> cooperate? I suspect this will lead to trouble and possible DOS\n> attacks.\n\nThere is no reliance on identifying anyone. As you've said, it's\nfutile and can be trivially defeated with sock puppets.\n\nThe credential that establishes someone as real is the ability to\nsupply CPU power. \n\n\n> Until.... until what? How does anybody know when a transaction\n> has become irrevocable? Is \"a few\" blocks three? Thirty? A\n> hundred? Does it depend on the number of nodes? Is it logarithmic\n> or linear in number of nodes?\n\nSection 11 calculates the worst case under attack. Typically, 5 or\n10 blocks is enough for that. If you're selling something that\ndoesn't merit a network-scale attack to steal it, in practice you\ncould cut it closer.\n\n\n> But in the absence of identity, there's no downside to them\n> if spends become invalid, if they've already received the\n> goods they double-spent for (access to website, download,\n> whatever). The merchants are left holding the bag with\n> \"invalid\" coins, unless they wait that magical \"few blocks\"\n> (and how can they know how many?) before treating the spender\n> as having paid.\n>\n> The consumers won't do this if they spend their coin and it takes\n> an hour to clear before they can do what they spent their coin on.\n> The merchants won't do it if there's no way to charge back a\n> customer when they find the that their coin is invalid because\n> the customer has doublespent.\n\nThis is a version 2 problem that I believe can be solved fairly\nsatisfactorily for most applications.\n\nThe race is to spread your transaction on the network first. Think 6\ndegrees of freedom -- it spreads exponentially. It would only take\nsomething like 2 minutes for a transaction to spread widely enough\nthat a competitor starting late would have little chance of grabbing\nvery many nodes before the first one is overtaking the whole network.\n During those 2 minutes, the merchant's nodes can be watching for a\ndouble-spent transaction. The double-spender would not be able to\nblast his alternate transaction out to the world without the merchant\ngetting it, so he has to wait before starting.\n\nIf the real transaction reaches 90% and the double-spent tx reaches\n10%, the double-spender only gets a 10% chance of not paying, and 90%\nchance his money gets spent. For almost any type of goods, that's\nnot going to be worth it for the scammer.\n\nInformation based goods like access to website or downloads are\nnon-fencible. Nobody is going to be able to make a living off\nstealing access to websites or downloads. They can go to the file\nsharing networks to steal that. Most instant-access products aren't\ngoing to have a huge incentive to steal. \n\nIf a merchant actually has a problem with theft, they can make the\ncustomer wait 2 minutes, or wait for something in e-mail, which many\nalready do. If they really want to optimize, and it's a large\ndownload, they could cancel the download in the middle if the\ntransaction comes back double-spent. If it's website access,\ntypically it wouldn't be a big deal to let the customer have access\nfor 5 minutes and then cut off access if it's rejected. Many such\nsites have a free trial anyway.\n\nSatoshi Nakamoto\n\n\n---------------------------------------------------------------------\nThe Cryptography Mailing List\nUnsubscribe by sending \"unsubscribe cryptography\" to majordomo at metzdowd.com\n\n", "source": "cryptography", "original_date": "Sat Nov 15 13:02:00 EST 2008", "date": "2008-11-15T18:02:00Z", "url": "http://www.metzdowd.com/pipermail/cryptography/2008-November/014860.html", "thread_id": 1, "source_id": "014860", "parent_id": 26, "satoshi_id": 14 }, { "id": 28, "sent_from": "James A. Donald", "subject": "Bitcoin P2P e-cash paper", "text": "Satoshi Nakamoto wrote:\n > Fortunately, it's only necessary to keep a\n > pending-transaction pool for the current best branch.\n\nThis requires that we know, that is to say an honest\nwell behaved peer whose communications and data storage\nis working well knows, what the current best branch is -\nbut of course, the problem is that we are trying to\ndiscover, trying to converge upon, a best branch, which\nis not easy at the best of times, and becomes harder\nwhen another peer is lying about its connectivity and\ncapabilities, and yet another peer has just had a major\ndisk drive failure obfuscated by a software crash, and\nthe international fibers connecting yet a third peer\nhave been attacked by terrorists.\n\n > When a new block arrives for the best branch,\n > ConnectBlock removes the block's transactions from\n > the pending-tx pool. If a different branch becomes\n > longer\n\nWhich presupposes the branches exist, that they are\nfully specified and complete. If they exist as complete\nworks, rather than works in progress, then the problem\nis already solved, for the problem is making progress.\n\n > Broadcasts will probably be almost completely\n > reliable.\n\nThere is a trade off between timeliness and reliability.\nOne can make a broadcast arbitrarily reliable if time is\nof no consequence. However, when one is talking of\ndistributed data, time is always of consequence, because\nit is all about synchronization (that peers need to have\ncorresponding views at corresponding times) so when one\ndoes distributed data processing, broadcasts are always\nhighly unreliable Attempts to ensure that each\nmessage arrives at least once result in increased timing\nvariation. Thus one has to make a protocol that is\neither UDP or somewhat UDP like, in that messages are\nsmall, failure of messages to arrive is common, messages\ncan arrive in different order to the order in which they\nwere sent, and the same message may arrive multiple\ntimes. Either we have UDP, or we need to accommodate\nthe same problems as UDP has on top of TCP connections.\n\nRather than assuming that each message arrives at least\nonce, we have to make a mechanism such that the\ninformation arrives even though conveyed by messages\nthat frequently fail to arrive.\n\n > TCP transmissions are rarely ever dropped these days\n\nPeople always load connections near maximum. When a\nconnection is near maximum, TCP connections suffer\nfrequent unreasonably long delays, and connections\nsimply fail a lot - your favorite web cartoon somehow\nshows it is loading forever, and you try again, or it\ncomes up with a little x in place of a picture, and you\ntry again\n\nFurther very long connections - for example ftp\ndownloads of huge files, seldom complete. If you try to\nftp a movie, you are unlikely to get anywhere unless\nboth client and server have a resume mechanism so that\nthey can talk about partially downloaded files.\n\nUDP connections, for example Skype video calls, also\nsuffer frequent picture freezes, loss of quality, and so\nforth, and have to have mechanisms to keep going\nregardless.\n\n > It's very attractive to the libertarian viewpoint if\n > we can explain it properly. I'm better with code than\n > with words though.\n\nNo, it is very attractive to the libertarian if we can\ndesign a mechanism that will scale to the point of\nproviding the benefits of rapidly irreversible payment,\nimmune to political interference, over the internet,\nto very large numbers of people. You have an outline\nand proposal for such a design, which is a big step\nforward, but the devil is in the little details.\n\nI really should provide a fleshed out version of your\nproposal, rather than nagging you to fill out the blind\nspots.\n\n---------------------------------------------------------------------\nThe Cryptography Mailing List\nUnsubscribe by sending \"unsubscribe cryptography\" to majordomo at metzdowd.com\n\n", "source": "cryptography", "original_date": "Sat Nov 15 19:00:04 EST 2008", "date": "2008-11-16T00:00:04Z", "url": "http://www.metzdowd.com/pipermail/cryptography/2008-November/014861.html", "thread_id": 1, "source_id": "014861", "parent_id": 23 }, { "id": 29, "sent_from": "Satoshi Nakamoto", "subject": "Bitcoin P2P e-cash paper", "text": "James A. Donald wrote:\n> > Fortunately, it's only necessary to keep a\n> > pending-transaction pool for the current best branch.\n> \n> This requires that we know, that is to say an honest\n> well behaved peer whose communications and data storage\n> is working well knows, what the current best branch is -\n\nI mean a node only needs the pending-tx pool for the best branch it\nhas. The branch that it currently thinks is the best branch.\nThat's the branch it'll be trying to make a block out of, which is\nall it needs the pool for.\n\n\n> > Broadcasts will probably be almost completely\n> > reliable.\n> \n> Rather than assuming that each message arrives at least\n> once, we have to make a mechanism such that the\n> information arrives even though conveyed by messages\n> that frequently fail to arrive.\n\nI think I've got the peer networking broadcast mechanism covered. \n\nEach node sends its neighbours an inventory list of hashes of the\nnew blocks and transactions it has. The neighbours request the\nitems they don't have yet. If the item never comes through after a\ntimeout, they request it from another neighbour that had it. Since\nall or most of the neighbours should eventually have each item,\neven if the coms get fumbled up with one, they can get it from any\nof the others, trying one at a time.\n\nThe inventory-request-data scheme introduces a little latency, but\nit ultimately helps speed more by keeping extra data blocks off the\ntransmit queues and conserving bandwidth.\n\n\n> You have an outline\n> and proposal for such a design, which is a big step\n> forward, but the devil is in the little details.\n\nI believe I've worked through all those little details over the\nlast year and a half while coding it, and there were a lot of them.\nThe functional details are not covered in the paper, but the\nsourcecode is coming soon. I sent you the main files.\n(available by request at the moment, full release soon)\n\nSatoshi Nakamoto\n\n\n---------------------------------------------------------------------\nThe Cryptography Mailing List\nUnsubscribe by sending \"unsubscribe cryptography\" to majordomo at metzdowd.com\n\n", "source": "cryptography", "original_date": "Mon Nov 17 12:24:43 EST 2008", "date": "2008-11-17T17:24:43Z", "url": "http://www.metzdowd.com/pipermail/cryptography/2008-November/014863.html", "thread_id": 1, "source_id": "014863", "parent_id": 28, "satoshi_id": 15 }, { "id": 30, "sent_from": "Nicolas Williams", "subject": "Bitcoin P2P e-cash paper", "text": "On Fri, Nov 14, 2008 at 11:04:21PM -0800, Ray Dillinger wrote:\n> On Sat, 2008-11-15 at 12:43 +0800, Satoshi Nakamoto wrote:\n> > > If someone double spends, then the transaction record \n> > > can be unblinded revealing the identity of the cheater. \n> > \n> > Identities are not used, and there's no reliance on recourse. It's all prevention.\n> \n> Okay, that's surprising. If you're not using buyer/seller \n> identities, then you are not checking that a spend is being made \n> by someone who actually is the owner of (on record as having \n> recieved) the coin being spent. \n\nHow do identities help? It's supposed to be anonymous cash, right? And\nsay you identify a double spender after the fact, then what? Perhaps\nyou're looking at a disposable ID. Or perhaps you can't chase them\ndown.\n\nDouble spend detection needs to be real-time or near real-time.\n\nNico\n-- \n\n---------------------------------------------------------------------\nThe Cryptography Mailing List\nUnsubscribe by sending \"unsubscribe cryptography\" to majordomo at metzdowd.com\n\n", "source": "cryptography", "original_date": "Mon Nov 17 16:54:28 EST 2008", "date": "2008-11-17T21:54:28Z", "url": "http://www.metzdowd.com/pipermail/cryptography/2008-November/014864.html", "thread_id": 1, "source_id": "014864", "parent_id": 26 }, { "id": 31, "sent_from": "James A. Donald", "subject": "Bitcoin P2P e-cash paper", "text": "Ray Dillinger wrote:\n > Okay.... I'm going to summarize this protocol as I\n > understand it.\n >\n > I'm filling in some operational details that aren't in\n > the paper by supplementing what you wrote with what my\n > own \"design sense\" tells me are critical missing bits\n > or \"obvious\" methodologies for use.\n\nThere are a number of significantly different ways this\ncould be implemented. I have been working on my own\nversion based on Patricia hash trees, (not yet ready to\npost, will post in a week or so) with the consensus\ngeneration being a generalization of file sharing using\nMerkle hash trees. Patricia hash trees where the high\norder part of the Patricia key represents the high order\npart of the time can be used to share data that evolves\nin time. The algorithm, if implemented by honest\ncorrectly functioning peers, regularly generates\nconsensus hashes of the recent past - thereby addressing\nthe problem I have been complaining about - that we have\na mechanism to protect against consensus distortion by\ndishonest or malfunctioning peers, which is useless\nabsent a definition of consensus generation by honest\nand correctly functioning peers.\n\n > First, people spend computer power creating a pool of\n > coins to use as money. Each coin is a proof-of-work\n > meeting whatever criteria were in effect for money at\n > the time it was created. The time of creation (and\n > therefore the criteria) is checkable later because\n > people can see the emergence of this particular coin\n > in the transaction chain and track it through all its\n > \"consensus view\" spends. (more later on coin creation\n > tied to adding a link).\n >\n > When a coin is spent, the buyer and seller digitally\n > sign a (blinded) transaction record, and broadcast it\n > to a bunch of nodes whose purpose is keeping track of\n > consensus regarding coin ownership.\n\nI don't think your blinding works.\n\nIf there is a public record of who owns what coin, we\nhave to generate a public diff on changes in that\nrecord, so the record will show that a coin belonged to\nX, and soon thereafter belonged to Y. I don't think\nblinding can be made to work. We can blind the\ntransaction details easily enough, by only making hashes\nof the details public, (X paid Y for\n49vR7xmwYcKXt9zwPJ943h9bHKC2pG68m) but that X paid Y is\ngoing to be fairly obvious.\n\nIf when Joe spends a coin to me, then I have to have the\nability to ask \"Does Joe rightfully own this coin\", then\nit is difficult to see how this can be implemented in a\ndistributed protocol without giving people the ability\nto trawl through data detecting that Joe paid me.\n\nTo maintain a consensus on who owns what coins, who owns\nwhat coins has to be public.\n\nWe can build a privacy layer on top of this - account\nmoney and chaumian money based on bitgold coins, much as\nthe pre 1915 US banking system layered account money and\nbank notes on top of gold coins, and indeed we have to\nbuild a layer on top to bring the transaction cost down\nto the level that supports agents performing micro\ntransactions, as needed for bandwidth control, file\nsharing, and charging non white listed people to send us\ncommunications.\n\nSo the entities on the public record are entities\nfunctioning like pre 1915 banks - let us call them\nbinks, for post 1934 banks no longer function like that.\n\n > But if they recieve a _longer_ chain while working,\n > they immediately check all the transactions in the new\n > links to make sure it contains no double spends and\n > that the \"work factors\" of all new links are\n > appropriate.\n\nI am troubled that this involves frequent\nretransmissions of data that is already mostly known.\nConsensus and widely distributed beliefs about bitgold\nownership already involves significant cost. Further,\neach transmission of data is subject to data loss, which\ncan result in thrashing, with the risk that the\ngeneration of consensus may slow below the rate of new\ntransactions. We already have problems getting the cost\ndown to levels that support micro transactions by\nsoftware agents, which is the big unserved market -\nbandwidth control, file sharing, and charging non white\nlisted people to send us communications.\n\nTo work as useful project, has to be as efficient as it\ncan be - hence my plan to use a Patricia hash tree\nbecause it identifies and locate small discrepancies\nbetween peers that are mostly in agreement already,\nwithout them needing to transmit their complete data.\n\nWe also want to avoid very long hash chains that have to\nbe frequently checked in order to validate things. Any\ntime a hash chain can potentially become enormously long\nover time, we need to ensure that no one ever has to\nrewalk the full length. Chains that need to be\nre-walked can only be permitted to grow as the log of\nthe total number of transactions - if they grow as the\nlog of the transactions in any one time period plus the\ntotal number of time periods, we have a problem.\n\n > Biggest Technical Problem:\n >\n > Is there a mechanism to make sure that the \"chain\"\n > does not consist solely of links added by just the 3\n > or 4 fastest nodes? 'Cause a broadcast transaction\n > record could easily miss those 3 or 4 nodes and if it\n > does, and those nodes continue to dominate the chain,\n > the transaction might never get added.\n >\n > To remedy this, you need to either ensure provable\n > propagation of transactions, or vary the work factor\n > for a node depending on how many links have been added\n > since that node's most recent link.\n >\n > Unfortunately, both measures can be defeated by sock\n > puppets. This is probably the worst problem with your\n > protocol as it stands right now; you need some central\n > point to control the identities (keys) of the nodes\n > and prevent people from making new sock puppets.\n\nWe need a protocol wherein to be a money tracking peer\n(an entity that validates spends) you have to be\naccepted by at least two existing peers who agree to\nsynchronize data with you - presumably through human\nintervention by the owners of existing peers, and these\ntwo human approved synchronization paths indirectly\nconnect you to the other peers in the network through\nat least one graph cycle.\n\nIf peer X is only connected to the rest of the network\nby one existing peer, peer Y, perhaps because X's\ndirectly connecting peer has dropped out, then X is\ndemoted to a client, not a peer - any transactions X\nsubmits are relabeled by Y as submitted to Y, not X, and\nthe time of submission (which forms part of the Patricia\nkey) is the time X submitted them to Y, not the time\nthey were submitted to X.\n\nThe algorithm must be able swiftly detect malfunctioning\npeers, and automatically exclude them from the consensus\ntemporarily - which means that transactions submitted\nthrough malfunctioning peers do not get included in the\nconsensus, therefore have to be resubmitted, and peers\nmay find themselves temporarily demoted to clients,\nbecause one of the peers through which they were\nformerly connected to the network has been dropped by\nthe consensus.\n\nIf a peer gets a lot of automatic temporary exclusions,\nthere may be human intervention by the owners of those\npeers to which it exchanges data directly to permanently\ndrop them.\n\nSince peers get accepted by human invite, they have\nreputation to lose, therefore we can make the null\nhypothesis (the primary Bayesian prior) honest intent,\nvalid data, but unreliable data transmission - trust\nwith infrequent random verification. Designing the\nsystem on this basis considerably reduces processing\ncosts.\n\nRecall that SET died on its ass in large part because\nevery transaction involved innumerable public key\noperations. Similarly, we have huge security flaws in\nhttps because it has so many redundant public key\noperations that web site designers try to minimize the\nuse of https to cover only those areas that truly need\nit - and they always get the decision as to what truly\nneeds it subtly wrong.\n\nEfficiency is critical, particularly as the part of the\nmarket not yet served is the market for very low cost\ntransactions.\n\n > If we solve the sock-puppet issue, or accept that\n > there's a central point controlling the generation of\n > new keys,\n\nA central point will invite attack, will be attacked.\n\nThe problem with computer networked money is that the\npast can so easily be revised, so nodes come under\npressure to adjust the past - \"I did not pay that\"\nswiftly becomes \"I should not have paid that\", which\nrequires arbitration, which is costly, and introduces\nuncertainty, which is costly, and invites government\nregulation, which is apt to be utterly ruinous and\nwholly devastating.\n\nFor many purposes, reversal and arbitration is highly\ndesirable, but there is no way anyone can compete with\nthe arbitration provided by Visa and Mastercard, for\nthey have network effects on their side, and they do a\nreally good job of arbitration, at which they have vast\nexperience, accumulated skills, wisdom, and good repute.\nSo any new networked transaction system has to target\nthe demand for final and irreversible transactions.\n\nThe idea of a distributed network consensus is that one\nhas a lot of peers in a lot of jurisdictions, and once a\ntransaction has entered into the consensus, undoing it\nis damn near impossible - one would have to pressure\nmost of the peers in most of the jurisdictions to agree,\nand many of them don't even talk your language, and\nthose that do, will probably pretend that they do not.\nSo people will not even try.\n\nTo avoid pressure, the network has to avoid any central\npoint at which pressure can be applied. Recall Nero's\nwish that Rome had a single throat that he could cut. If\nwe provide them with such a throat, it will be cut.\n\n---------------------------------------------------------------------\nThe Cryptography Mailing List\nUnsubscribe by sending \"unsubscribe cryptography\" to majordomo at metzdowd.com\n\n", "source": "cryptography", "original_date": "Mon Nov 17 18:57:39 EST 2008", "date": "2008-11-17T23:57:39Z", "url": "http://www.metzdowd.com/pipermail/cryptography/2008-November/014865.html", "thread_id": 1, "source_id": "014865", "parent_id": 24 }, { "id": 32, "sent_from": "James A. Donald", "subject": "Bitcoin P2P e-cash paper", "text": "Nicolas Williams wrote:\n > How do identities help? It's supposed to be anonymous\n > cash, right?\n\nActually no. It is however supposed to be pseudonymous,\nso dinging someone's reputation still does not help\nmuch.\n\n > And say you identify a double spender after the fact,\n > then what? Perhaps you're looking at a disposable ID.\n > Or perhaps you can't chase them down.\n >\n > Double spend detection needs to be real-time or near\n > real-time.\n\nNear real time means we have to use UDP or equivalent,\nrather than TCP or equivalent, and we have to establish\nan approximate consensus, not necessarily the final\nconsensus, not necessarily exact agreement, but close to\nit, in a reasonably small number of round trips.\n\n---------------------------------------------------------------------\nThe Cryptography Mailing List\nUnsubscribe by sending \"unsubscribe cryptography\" to majordomo at metzdowd.com\n\n", "source": "cryptography", "original_date": "Mon Nov 17 20:26:31 EST 2008", "date": "2008-11-18T01:26:31Z", "url": "http://www.metzdowd.com/pipermail/cryptography/2008-November/014866.html", "thread_id": 1, "source_id": "014866", "parent_id": 30 }, { "id": 33, "sent_from": "Satoshi Nakamoto", "subject": "Bitcoin v0.1 released", "text": "Announcing the first release of Bitcoin, a new electronic cash\nsystem that uses a peer-to-peer network to prevent double-spending.\nIt's completely decentralized with no server or central authority.\n\nSee bitcoin.org for screenshots.\n\nDownload link:\nhttp://downloads.sourceforge.net/bitcoin/bitcoin-0.1.0.rar\n\nWindows only for now. Open source C++ code is included.\n\n- Unpack the files into a directory\n- Run BITCOIN.EXE\n- It automatically connects to other nodes\n\nIf you can keep a node running that accepts incoming connections,\nyou'll really be helping the network a lot. Port 8333 on your\nfirewall needs to be open to receive incoming connections.\n\nThe software is still alpha and experimental. There's no guarantee\nthe system's state won't have to be restarted at some point if it\nbecomes necessary, although I've done everything I can to build in\nextensibility and versioning.\n\nYou can get coins by getting someone to send you some, or turn on\nOptions->Generate Coins to run a node and generate blocks. I made\nthe proof-of-work difficulty ridiculously easy to start with, so\nfor a little while in the beginning a typical PC will be able to\ngenerate coins in just a few hours. It'll get a lot harder when\ncompetition makes the automatic adjustment drive up the difficulty.\nGenerated coins must wait 120 blocks to mature before they can be\nspent.\n\nThere are two ways to send money. If the recipient is online, you\ncan enter their IP address and it will connect, get a new public\nkey and send the transaction with comments. If the recipient is\nnot online, it is possible to send to their Bitcoin address, which\nis a hash of their public key that they give you. They'll receive\nthe transaction the next time they connect and get the block it's\nin. This method has the disadvantage that no comment information\nis sent, and a bit of privacy may be lost if the address is used\nmultiple times, but it is a useful alternative if both users can't\nbe online at the same time or the recipient can't receive incoming\nconnections.\n\nTotal circulation will be 21,000,000 coins. It'll be distributed\nto network nodes when they make blocks, with the amount cut in half\nevery 4 years.\n\nfirst 4 years: 10,500,000 coins\nnext 4 years: 5,250,000 coins\nnext 4 years: 2,625,000 coins\nnext 4 years: 1,312,500 coins\netc...\n\nWhen that runs out, the system can support transaction fees if\nneeded. It's based on open market competition, and there will\nprobably always be nodes willing to process transactions for free.\n\nSatoshi Nakamoto\n\n\n---------------------------------------------------------------------\nThe Cryptography Mailing List\nUnsubscribe by sending \"unsubscribe cryptography\" to majordomo at metzdowd.com\n\n", "source": "cryptography", "original_date": "Thu Jan 8 14:27:40 EST 2009", "date": "2009-01-08T19:27:40Z", "url": "http://www.metzdowd.com/pipermail/cryptography/2009-January/014994.html", "thread_id": 2, "source_id": "014994", "satoshi_id": 16 }, { "id": 34, "sent_from": "Hal Finney", "subject": "Bitcoin v0.1 released", "text": "Satoshi Nakamoto writes:\n> Announcing the first release of Bitcoin, a new electronic cash\n> system that uses a peer-to-peer network to prevent double-spending.\n> It's completely decentralized with no server or central authority.\n>\n> See bitcoin.org for screenshots.\n>\n> Download link:\n> http://downloads.sourceforge.net/bitcoin/bitcoin-0.1.0.rar\n\nCongratulations to Satoshi on this first alpha release. I am looking\nforward to trying it out.\n\n> Total circulation will be 21,000,000 coins. It'll be distributed\n> to network nodes when they make blocks, with the amount cut in half\n> every 4 years.\n>\n> first 4 years: 10,500,000 coins\n> next 4 years: 5,250,000 coins\n> next 4 years: 2,625,000 coins\n> next 4 years: 1,312,500 coins\n> etc...\n\nIt's interesting that the system can be configured to only allow a\ncertain maximum number of coins ever to be generated. I guess the\nidea is that the amount of work needed to generate a new coin will\nbecome more difficult as time goes on.\n\nOne immediate problem with any new currency is how to value it. Even\nignoring the practical problem that virtually no one will accept it\nat first, there is still a difficulty in coming up with a reasonable\nargument in favor of a particular non-zero value for the coins.\n\nAs an amusing thought experiment, imagine that Bitcoin is successful and\nbecomes the dominant payment system in use throughout the world. Then the\ntotal value of the currency should be equal to the total value of all\nthe wealth in the world. Current estimates of total worldwide household\nwealth that I have found range from $100 trillion to $300 trillion. With\n20 million coins, that gives each coin a value of about $10 million.\n\nSo the possibility of generating coins today with a few cents of compute\ntime may be quite a good bet, with a payoff of something like 100 million\nto 1! Even if the odds of Bitcoin succeeding to this degree are slim,\nare they really 100 million to one against? Something to think about...\n\nHal\n\n---------------------------------------------------------------------\nThe Cryptography Mailing List\nUnsubscribe by sending \"unsubscribe cryptography\" to majordomo at metzdowd.com\n\n", "source": "cryptography", "original_date": "Sat Jan 10 21:22:01 EST 2009", "date": "2009-01-11T02:22:01Z", "url": "http://www.metzdowd.com/pipermail/cryptography/2009-January/015004.html", "thread_id": 2, "source_id": "015004", "parent_id": 33 }, { "id": 35, "sent_from": "Satoshi Nakamoto", "subject": "Bitcoin v0.1 released", "text": "> Dustin D. Trammell wrote:\n> > Satoshi Nakamoto wrote:\n> > You know, I think there were a lot more people interested in the 90's,\n> > but after more than a decade of failed Trusted Third Party based systems\n> > (Digicash, etc), they see it as a lost cause. I hope they can make the\n> > distinction that this is the first time I know of that we're trying a\n> > non-trust-based system.\n>\n> Yea, that was the primary feature that caught my eye. The real trick\n> will be to get people to actually value the BitCoins so that they become\n> currency.\n \nI would be surprised if 10 years from now we're not using\nelectronic currency in some way, now that we know a way to do it\nthat won't inevitably get dumbed down when the trusted third party\ngets cold feet.\n\nIt could get started in a narrow niche like reward points,\ndonation tokens, currency for a game or micropayments for adult\nsites. Initially it can be used in proof-of-work applications\nfor services that could almost be free but not quite.\n\nIt can already be used for pay-to-send e-mail. The send dialog is\nresizeable and you can enter as long of a message as you like.\nIt's sent directly when it connects. The recipient doubleclicks\non the transaction to see the full message. If someone famous is\ngetting more e-mail than they can read, but would still like to\nhave a way for fans to contact them, they could set up Bitcoin and\ngive out the IP address on their website. \"Send X bitcoins to my\npriority hotline at this IP and I'll read the message personally.\"\n\nSubscription sites that need some extra proof-of-work for their\nfree trial so it doesn't cannibalize subscriptions could charge\nbitcoins for the trial.\n\nIt might make sense just to get some in case it catches on. If\nenough people think the same way, that becomes a self fulfilling\nprophecy. Once it gets bootstrapped, there are so many\napplications if you could effortlessly pay a few cents to a\nwebsite as easily as dropping coins in a vending machine. \n\nSatoshi Nakamoto\nhttp://www.bitcoin.org\n\n\n---------------------------------------------------------------------\nThe Cryptography Mailing List\nUnsubscribe by sending \"unsubscribe cryptography\" to majordomo at metzdowd.com\n\n", "source": "cryptography", "original_date": "Fri Jan 16 11:03:14 EST 2009", "date": "2009-01-16T16:03:14Z", "url": "http://www.metzdowd.com/pipermail/cryptography/2009-January/015014.html", "thread_id": 2, "source_id": "015014", "parent_id": 33, "satoshi_id": 17 }, { "id": 36, "sent_from": "Jonathan Thornburg", "subject": "Bitcoin v0.1 released", "text": "On Sat, 17 Jan 2009, Satoshi Nakamoto wrote:\n[[various possible uses of Bitcoin et al]]\n> Once it gets bootstrapped, there are so many\n> applications if you could effortlessly pay a few cents to a\n> website as easily as dropping coins in a vending machine. \n\nIn the modern world, no major government wants to allow untracable\ninternational financial transactions above some fairly modest size\nthresholds. (The usual catch-phrases are things like \"laundering\ndrug money\", \"tax evasion\", and/or \"financing terrorist groups\".)\nTo this end, electronic financial transactions are currently monitored\nby various governments & their agencies, and any but the smallest of\ntransactions now come with various ID requirements for the humans\non each end.\n\nBut if each machine in a million-node botnet sends 10 cents to a\nrandomly chosen machine in another botnet on the other side of the\nworld, you've just moved $100K, in a way that seems very hard to\ntrace. To me, this means that no major government is likely to allow\nBitcoin in its present form to operate on a large scale.\n\nI also worry about other \"domestic\" ways nasty people could exploit\na widespread Bitcoin deployment:\n* Spammer botnets could burn through pay-per-send email filters\n trivially (as usual, the costs would fall on people other than the\n botnet herders & spammers).\n* If each machine in a botnet sends 1 cent to a herder, that can add\n up to a significant amount of money. In other words, Bitcoin would\n make botnet herding and the assorted malware industry even more\n profitable than it already is.\n\nIs there something obvious I've missed? Is there a clever aspect of\nthe design which prevents botnets from exploiting the system? Is there\na way for every major government to monitor all Bitcoin transactions\nto watch for botnet-to-botnet sending?\n\n-- \n-- From: \"Jonathan Thornburg [remove -animal to reply]\" \n Dept of Astronomy, Indiana University, Bloomington, Indiana, USA\n \"Washing one's hands of the conflict between the powerful and the\n powerless means to side with the powerful, not to be neutral.\"\n -- quote by Freire / poster by Oxfam\n\n---------------------------------------------------------------------\nThe Cryptography Mailing List\nUnsubscribe by sending \"unsubscribe cryptography\" to majordomo at metzdowd.com\n\n", "source": "cryptography", "original_date": "Sat Jan 17 11:49:45 EST 2009", "date": "2009-01-17T16:49:45Z", "url": "http://www.metzdowd.com/pipermail/cryptography/2009-January/015016.html", "thread_id": 2, "source_id": "015016", "parent_id": 34 }, { "id": 37, "sent_from": "Hal Finney", "subject": "Bitcoin v0.1 released", "text": "Jonathan Thornburg writes:\n> In the modern world, no major government wants to allow untracable\n> international financial transactions above some fairly modest size\n> thresholds. (The usual catch-phrases are things like \"laundering\n> drug money\", \"tax evasion\", and/or \"financing terrorist groups\".)\n> To this end, electronic financial transactions are currently monitored\n> by various governments & their agencies, and any but the smallest of\n> transactions now come with various ID requirements for the humans\n> on each end.\n>\n> But if each machine in a million-node botnet sends 10 cents to a\n> randomly chosen machine in another botnet on the other side of the\n> world, you've just moved $100K, in a way that seems very hard to\n> trace. To me, this means that no major government is likely to allow\n> Bitcoin in its present form to operate on a large scale.\n\nCertainly a valid point, and one which has been widely discussed in\nthe debates over the years about electronic cash. Bitcoin has a couple\nof things going for it: one is that it is distributed, with no single\npoint of failure, no \"mint\", no company with officers that can be\nsubpoenaed and arrested and shut down. It is more like a P2P network,\nand as we have seen, despite degrees of at least governmental distaste,\nthose are still around.\n\nBitcoin could also conceivably operate in a less anonymous mode, with\ntransfers being linked to individuals, rather than single-use keys. It\nwould still be useful to have a large scale, decentralized electronic\npayment system.\n\nIt also might be possible to refactor and restructure Bitcoin to separate\nout the key new idea, a decentralized, global, irreversible transaction\ndatabase. Such a functionality might be useful for other purposes. Once\nit exists, using it to record monetary transfers would be a sort of side\neffect and might be harder to shut down.\n\n> I also worry about other \"domestic\" ways nasty people could exploit\n> a widespread Bitcoin deployment:\n> * Spammer botnets could burn through pay-per-send email filters\n> trivially (as usual, the costs would fall on people other than the\n> botnet herders & spammers).\n> * If each machine in a botnet sends 1 cent to a herder, that can add\n> up to a significant amount of money. In other words, Bitcoin would\n> make botnet herding and the assorted malware industry even more\n> profitable than it already is.\n\nIt's important to understand that the proof-of-work (POW) aspect of\nBitcoin is primarily oriented around ensuring the soundness of the\nhistorical transaction database. Each Bitcoin data block records a set\nof transactions, and includes a hash collision. Subsequent data blocks\nhave their own transactions, their own collisions, and also chain to\nall earlier hashes. The result is that once a block is \"buried\" under\nenough new blocks, it is essentially certain (given the threat model,\nnamely that attackers cannot muster more than X% of the compute power\nof legitimate node operators) that old transactions can't be reversed.\n\nCreating new coins is indeed currently also being done by POW, but I\nthink that is seen as a temporary expedient, and in fact the current\nsoftware phases that out over several years. Hence worries about botnets\nbeing able to manufacture large quantities of POW tokens are only a\ntemporary concern, in the context of Bitcoin.\n\nThere have been a number of discussions in the past about POW tokens as\nanti spam measures, given the botnet threat. References are available from\n\"Proof-of-work system\" on Wikipedia. Analyses have yielded mixed results,\ndepending on the assumptions and system design.\n\nIf POW tokens do become useful, and especially if they become money,\nmachines will no longer sit idle. Users will expect their computers to\nbe earning them money (assuming the reward is greater than the cost to\noperate). A computer whose earnings are being stolen by a botnet will\nbe more noticeable to its owner than is the case today, hence we might\nexpect that in that world, users will work harder to maintain their\ncomputers and clean them of botnet infestations.\n\nCountermeasures by botnet operators would include moderating their take,\nperhaps only stealing 10% of the productive capacity of invaded computers,\nso that their owners would be unlikely to notice. This kind of thinking\nquickly degenerates into unreliable speculation, but it points out the\ndifficulties of analyzing the full ramifications of a world where POW\ntokens are valuble.\n\nHal Finney\n\n---------------------------------------------------------------------\nThe Cryptography Mailing List\nUnsubscribe by sending \"unsubscribe cryptography\" to majordomo at metzdowd.com\n\n", "source": "cryptography", "original_date": "Sat Jan 24 11:48:03 EST 2009", "date": "2009-01-24T16:48:03Z", "url": "http://www.metzdowd.com/pipermail/cryptography/2009-January/015036.html", "thread_id": 2, "source_id": "015036", "parent_id": 36 }, { "id": 38, "sent_from": "Bill Frantz", "subject": "Bitcoin v0.1 released", "text": "hal at finney.org (\"Hal Finney\") on Saturday, January 24, 2009 wrote:\n\n>Countermeasures by botnet operators would include moderating their take,\n>perhaps only stealing 10% of the productive capacity of invaded computers,\n>so that their owners would be unlikely to notice. This kind of thinking\n>quickly degenerates into unreliable speculation, but it points out the\n>difficulties of analyzing the full ramifications of a world where POW\n>tokens are valuble.\n\nSome people tell me that the 0wned machines are among the most secure on\nthe network because botnet operators work hard to keep others from\ncompromising \"their\" machines. I could see the operators moving toward\nbeing legitimate security firms, protecting computers against compromise in\nexchange for some of the proof of work (POW) money.\n\nCheers - Bill\n\n-------------------------------------------------------------------------\nBill Frantz | When it comes to the world | Periwinkle\n(408)356-8506 | around us, is there any choice | 16345 Englewood Ave\nwww.pwpconsult.com | but to explore? - Lisa Randall | Los Gatos, CA 95032\n\n---------------------------------------------------------------------\nThe Cryptography Mailing List\nUnsubscribe by sending \"unsubscribe cryptography\" to majordomo at metzdowd.com\n\n", "source": "cryptography", "original_date": "Sat Jan 24 18:22:21 EST 2009", "date": "2009-01-24T23:22:21Z", "url": "http://www.metzdowd.com/pipermail/cryptography/2009-January/015038.html", "thread_id": 2, "source_id": "015038", "parent_id": 37 }, { "id": 39, "sent_from": "dan at geer.org", "subject": "Bitcoin v0.1 released", "text": "\nBill Frantz writes:\n-+-----------------\n | Some people tell me that the 0wned machines are among the most\n | secure on the network because botnet operators work hard to\n | keep others from compromising \"their\" machines. I could see the\n | operators moving toward being legitimate security firms,\n | protecting computers against compromise in exchange for some of\n | the proof of work (POW) money.\n\n\nI'm one of those people. Quoting from my speech of 1/20:\n\n> Virus attacks have, of course, become rarer over time, which is\n> to say that where infectious agents once ruled, today it is\n> parasites. Parasites have no reason to kill their hosts -- on\n> the contrary they want their hosts to survive well enough to\n> feed the parasite. A parasite will generally not care to be all\n> that visible, either. The difference between parasitism and\n> symbiosis can be a close call in some settings, and of the folks\n> who famously bragged of being able to take the Internet down in\n> twenty minutes, one has said that a computer may be better\n> managed once it is in a botnet than before since the bot-master\n> will be serious about closing the machine up tight against\n> further penetration and similarly serious about patch\n> management. Therefore, since one can then say that both the\n> machine's nominal owner and the bot master are mutually helped,\n> what we see is evolution from parasite to symbiont in action.\n> According to Margulis and Sagan, \"Life did not take over the\n> globe by combat, but by networking.\" On this basis and others,\n> bot-nets are a life form.\n\nRest of text upon request. Incidentally, I *highly* recommend\nDaniel Suarez's _Daemon_; trust me as to its relevance. Try\nthis for a non-fiction taste:\n\nhttp://fora.tv/2008/08/08/Daniel_Suarez_Daemon_Bot-Mediated_Reality\n\n\n--dan\n\n---------------------------------------------------------------------\nThe Cryptography Mailing List\nUnsubscribe by sending \"unsubscribe cryptography\" to majordomo at metzdowd.com\n\n", "source": "cryptography", "original_date": "Sat Jan 24 23:07:17 EST 2009", "date": "2009-01-25T04:07:17Z", "url": "http://www.metzdowd.com/pipermail/cryptography/2009-January/015040.html", "thread_id": 2, "source_id": "015040", "parent_id": 38 }, { "id": 40, "sent_from": "Satoshi Nakamoto", "subject": "Bitcoin v0.1 released", "text": "Hal Finney wrote:\n> > * Spammer botnets could burn through pay-per-send email filters\n> > trivially\n> If POW tokens do become useful, and especially if they become money,\n> machines will no longer sit idle. Users will expect their computers to\n> be earning them money (assuming the reward is greater than the cost to\n> operate). A computer whose earnings are being stolen by a botnet will\n> be more noticeable to its owner than is the case today, hence we might\n> expect that in that world, users will work harder to maintain their\n> computers and clean them of botnet infestations.\n\nAnother factor that would mitigate spam if POW tokens have value:\nthere would be a profit motive for people to set up massive\nquantities of fake e-mail accounts to harvest POW tokens from\nspam. They'd essentially be reverse-spamming the spammers with\nautomated mailboxes that collect their POW and don't read the\nmessage. The ratio of fake mailboxes to real people could become\ntoo high for spam to be cost effective. \n\nThe process has the potential to establish the POW token's value\nin the first place, since spammers that don't have a botnet could\nbuy tokens from harvesters. While the buying back would\ntemporarily let more spam through, it would only hasten the\nself-defeating cycle leading to too many harvesters exploiting the\nspammers.\n\nInterestingly, one of the e-gold systems already has a form of\nspam called \"dusting\". Spammers send a tiny amount of gold dust\nin order to put a spam message in the transaction's comment field.\n If the system let users configure the minimum payment they're\nwilling to receive, or at least the minimum that can have a\nmessage with it, users could set how much they're willing to get\npaid to receive spam.\n\nSatoshi Nakamoto\n\n\n---------------------------------------------------------------------\nThe Cryptography Mailing List\nUnsubscribe by sending \"unsubscribe cryptography\" to majordomo at metzdowd.com\n\n", "source": "cryptography", "original_date": "Sun Jan 25 10:47:10 EST 2009", "date": "2009-01-25T15:47:10Z", "url": "http://www.metzdowd.com/pipermail/cryptography/2009-January/015041.html", "thread_id": 2, "source_id": "015041", "parent_id": 37, "satoshi_id": 18 }, { "id": 41, "sent_from": "Satoshi Nakamoto", "subject": "[bitcoin-list] Welcome", "text": "Welcome to the Bitcoin mailing list!\n\n\n\n", "source": "bitcoin-list", "date": "2008-12-10T17:00:23Z", "url": "https://sourceforge.net/p/bitcoin/mailman/message/21033408/", "thread_id": 3, "source_id": "21033408", "satoshi_id": 19 }, { "id": 42, "sent_from": "Hal Finney", "subject": "Re: [bitcoin-list] Bitcoin v0.1 released", "text": "Satoshi Nakamoto writes:\n> Announcing the first release of Bitcoin, a new electronic cash\n> system that uses a peer-to-peer network to prevent double-spending.\n> It's completely decentralized with no server or central authority.\n>\n> See bitcoin.org for screenshots.\n>\n> Download link:\n> http://downloads.sourceforge.net/bitcoin/bitcoin-0.1.0.rar\n\nCongratulations to Satoshi on this first alpha release. I am looking\nforward to trying it out.\n\n> Total circulation will be 21,000,000 coins. It'll be distributed\n> to network nodes when they make blocks, with the amount cut in half\n> every 4 years.\n>\n> first 4 years: 10,500,000 coins\n> next 4 years: 5,250,000 coins\n> next 4 years: 2,625,000 coins\n> next 4 years: 1,312,500 coins\n> etc...\n\nIt's interesting that the system can be configured to only allow a\ncertain maximum number of coins ever to be generated. I guess the\nidea is that the amount of work needed to generate a new coin will\nbecome more difficult as time goes on.\n\nOne immediate problem with any new currency is how to value it. Even\nignoring the practical problem that virtually no one will accept it\nat first, there is still a difficulty in coming up with a reasonable\nargument in favor of a particular non-zero value for the coins.\n\nAs an amusing thought experiment, imagine that Bitcoin is successful and\nbecomes the dominant payment system in use throughout the world. Then the\ntotal value of the currency should be equal to the total value of all\nthe wealth in the world. Current estimates of total worldwide household\nwealth that I have found range from $100 trillion to $300 trillion. With\n20 million coins, that gives each coin a value of about $10 million.\n\nSo the possibility of generating coins today with a few cents of compute\ntime may be quite a good bet, with a payoff of something like 100 million\nto 1! Even if the odds of Bitcoin succeeding to this degree are slim,\nare they really 100 million to one against? Something to think about...\n\nHal\n\n\n", "source": "bitcoin-list", "date": "2009-01-11T03:16:43Z", "url": "https://sourceforge.net/p/bitcoin/mailman/message/21312757/", "thread_id": 4, "source_id": "21312757" }, { "id": 43, "sent_from": "Satoshi Nakamoto", "subject": "[bitcoin-list] Bitcoin v0.1.2 now available", "text": "Bitcoin v0.1.2 is now available for download.\n\nSee http://www.bitcoin.org for the download link.\n\nAll the problems I've been finding are in the code that\nautomatically finds and connects to other nodes, since I wasn't\nable to test it in the wild until now. There are many more ways\nfor connections to get screwed up on the real Internet.\n\nBugs fixed:\n- Fixed various problems that were making it hard for new nodes to\nsee other nodes to connect to.\n- If you're behind a firewall, it could only receive one\nconnection, and the second connection would constantly disconnect\nand reconnect.\n\nThese problems are kind of screwing up the network and will get\nworse as more users arrive, so please make sure to upgrade.\n\nSatoshi Nakamoto\n\n\n\n\n", "source": "bitcoin-list", "date": "2009-01-11T22:32:18Z", "url": "https://sourceforge.net/p/bitcoin/mailman/message/21303153/", "thread_id": 5, "source_id": "21303153", "satoshi_id": 20 }, { "id": 44, "sent_from": "Satoshi Nakamoto", "subject": "[bitcoin-list] Bitcoin v0.1 Alpha release notes", "text": "Release notes for Bitcoin v0.1 Alpha\n\nBitcoin is a new electronic cash system that uses a peer-to-peer \nnetwork to prevent double-spending. It's completely decentralized\nwith no server or central authority.\n \nYou can find screenshots and the download link at:\nhttp://www.bitcoin.org\n \nWindows only for now. Open source C++ code is included.\n\n- Unpack the files into a directory\n- Run BITCOIN.EXE\n- It automatically connects to other nodes\n\nIf you can keep a node running that accepts incoming connections,\nyou'll really be helping the network a lot. Port 8333 on your\nfirewall needs to be open to receive incoming connections.\n\nThe software is still alpha and experimental. There's no guarantee\nthe system's state won't have to be restarted at some point if it\nbecomes necessary, although I've done everything I can to build in\nextensibility and versioning.\n\nYou can get coins by getting someone to send you some, or turn on\nOptions->Generate Coins to run a node and generate blocks. I made\nthe proof-of-work difficulty ridiculously easy to start with, so\nfor a little while in the beginning a typical PC will be able to\ngenerate coins in just a few hours. It'll get a lot harder when\ncompetition makes the automatic adjustment drive up the difficulty.\nGenerated coins must wait 120 blocks to mature before they can be\nspent.\n\nThere are two ways to send money. If the recipient is online, you\ncan enter their IP address and it will connect, get a new public\nkey and send the transaction with comments. If the recipient is\nnot online, it is possible to send to their Bitcoin address, which\nis a hash of their public key that they give you. They'll receive\nthe transaction the next time they connect and get the block it's\nin. This method has the disadvantage that no comment information\nis sent, and a bit of privacy may be lost if the address is used\nmultiple times, but it is a useful alternative if both users can't\nbe online at the same time or the recipient can't receive incoming\nconnections.\n\nTotal circulation will be 21,000,000 coins. It'll be distributed\nto network nodes when they make blocks, with the amount cut in half\nevery 4 years.\n\nfirst 4 years: 10,500,000 coins\nnext 4 years: 5,250,000 coins\nnext 4 years: 2,625,000 coins\nnext 4 years: 1,312,500 coins\netc...\n\nWhen that runs out, the system can support transaction fees if\nneeded. It's based on open market competition, and there will\nprobably always be nodes willing to process transactions for free.\n\nSatoshi Nakamoto\n\n\n\n\n", "source": "bitcoin-list", "date": "2009-01-12T20:20:47Z", "url": "https://sourceforge.net/p/bitcoin/mailman/message/21312004/", "thread_id": 6, "source_id": "21312004", "satoshi_id": 21 }, { "id": 45, "sent_from": "Satoshi Nakamoto", "subject": "[bitcoin-list] Bitcoin v0.1.3", "text": "It looks like we're through with the worst of the Internet\nconnection issues. 0.1.3 fixed a problem where your node's\ncommunications could go dead after a while. The network is\nrunning much more smoothly now with this version. \n\nIf you've successfully generated a block, you've seen it has a\nmaturation countdown before you can spend it. Once it matures,\nthe Credit column will change from 0.00 to 50.00. For a block to\nbe valid, it has to be broadcasted to the network and get into the\nblock chain, which is why Generate does not run if you're not\nconnected. If you generated a block without being connected, the\nnetwork wouldn't know about it and would continue building the\nchain without it, leaving it behind, and the maturation countdown\nwould change to \"(not accepted)\" when your node sees that it\nwasn't used. If you subtract 1 from the status column, that's how\nmany blocks have been chained after yours.\n\nSatoshi Nakamoto\n\n\n\n\n", "source": "bitcoin-list", "date": "2009-01-12T22:48:23Z", "url": "https://sourceforge.net/p/bitcoin/mailman/message/21313152/", "thread_id": 7, "source_id": "21313152", "satoshi_id": 22 }, { "id": 46, "sent_from": "Satoshi Nakamoto", "subject": "Re: [bitcoin-list] Bitcoin v0.1 released", "text": "> Dustin D. Trammell wrote:\n> > Satoshi Nakamoto wrote:\n> > You know, I think there were a lot more people interested in the 90's,\n> > but after more than a decade of failed Trusted Third Party based systems\n> > (Digicash, etc), they see it as a lost cause. I hope they can make the\n> > distinction that this is the first time I know of that we're trying a\n> > non-trust-based system.\n>\n> Yea, that was the primary feature that caught my eye. The real trick\n> will be to get people to actually value the BitCoins so that they become\n> currency.\n \nI would be surprised if 10 years from now we're not using\nelectronic currency in some way, now that we know a way to do it\nthat won't inevitably get dumbed down when the trusted third party\ngets cold feet.\n\nIt could get started in a narrow niche like reward points,\ndonation tokens, currency for a game or micropayments for adult\nsites. Initially it can be used in proof-of-work applications\nfor services that could almost be free but not quite.\n\nIt can already be used for pay-to-send e-mail. The send dialog is\nresizeable and you can enter as long of a message as you like.\nIt's sent directly when it connects. The recipient doubleclicks\non the transaction to see the full message. If someone famous is\ngetting more e-mail than they can read, but would still like to\nhave a way for fans to contact them, they could set up Bitcoin and\ngive out the IP address on their website. \"Send X bitcoins to my\npriority hotline at this IP and I'll read the message personally.\"\n\nSubscription sites that need some extra proof-of-work for their\nfree trial so it doesn't cannibalize subscriptions could charge\nbitcoins for the trial.\n\nIt might make sense just to get some in case it catches on. If\nenough people think the same way, that becomes a self fulfilling\nprophecy. Once it gets bootstrapped, there are so many\napplications if you could effortlessly pay a few cents to a\nwebsite as easily as dropping coins in a vending machine. \n\nSatoshi Nakamoto\nhttp://www.bitcoin.org\n\n\n\n\n", "source": "bitcoin-list", "date": "2009-01-16T18:35:32Z", "url": "https://sourceforge.net/p/bitcoin/mailman/message/21356305/", "thread_id": 4, "source_id": "21356305", "satoshi_id": 23 }, { "id": 47, "sent_from": "Nicholas Bohm", "subject": "[bitcoin-list] Problems", "text": "I have had a couple of problems running bitcoin: is this an appropriate\nlist for reporting them (with about 70kb of attachments)?\n\nNicholas Bohm\n-- \nSalkyns, Great Canfield, Takeley,\nBishop's Stortford CM22 6SX, UK\n\nPhone 01279 870285 (+44 1279 870285)\nMobile 07715 419728 (+44 7715 419728)\n\nPGP public key ID: 0x899DD7FF. Fingerprint:\n5248 1320 B42E 84FC 1E8B A9E6 0912 AE66 899D D7FF\n\n\n", "source": "bitcoin-list", "date": "2009-01-25T10:17:52Z", "url": "https://sourceforge.net/p/bitcoin/mailman/message/21423198/", "thread_id": 8, "source_id": "21423198" }, { "id": 48, "sent_from": "Satoshi Nakamoto", "subject": "Re: [bitcoin-list] Problems", "text": "From: Nicholas Bohm 2009-01-25 10:17\n> I have had a couple of problems running bitcoin: is this an appropriate\n> list for reporting them (with about 70kb of attachments)?\n\nWhat's the problem you're having?\n\nIf you send me your debug.log file directly (best not to send attachments\nto the list), I can take a look at what's happening.\n\nSatoshi Nakamoto\nbitcoin-help at vistomail dot com\n\n\n\n\n", "source": "bitcoin-list", "date": "2009-01-25T16:45:25Z", "url": "https://sourceforge.net/p/bitcoin/mailman/message/21424626/", "thread_id": 8, "source_id": "21424626", "parent_id": 47, "satoshi_id": 24 }, { "id": 49, "sent_from": "Satoshi Nakamoto", "subject": "[bitcoin-list] Bitcoin v0.1.5 released", "text": "Version 0.1.5 is now available. It includes the fix for the problem\nNicholas had, checking for disk full and changes to try to improve\nthings that were confusing.\n\nSpecial thanks to Nicholas and Dustin for all their help and feedback!\n\nDownload link:\nhttp://sourceforge.net/project/showfiles.php?group_id=244765&package_id=298441\n\nChanges:\n- disk full warning\n- fixed a bug that could occur if dns lookup failed\n- prevent entering your own address in the address book,\n which confusingly changed the label for your own address\n- moved change address button to menu under options\n- tweaks to make it get connected faster\n- close sockets on exit\n- created minimum fee for transactions less than 1 cent\n- hid the transaction-type selection box that only had one choice\n- cleaned up ParseMoney a little\n- slightly cleaner reformatting of message text\n- changed the font in transaction details dialog\n- added some explanation text to transaction details for generated coins\n- reworded the description for transactions received with bitcoin address\n\nSatoshi Nakamoto\nhttp://www.bitcoin.org\n\n\n\n\n\n", "source": "bitcoin-list", "date": "2009-02-04T19:46:04Z", "url": "https://sourceforge.net/p/bitcoin/mailman/message/21500063/", "thread_id": 9, "source_id": "21500063", "satoshi_id": 25 }, { "id": 50, "sent_from": "Nicholas Bohm", "subject": "[bitcoin-list] Bitcoin v0.1.5 released", "text": "Version 0.1.5 seems to be running trouble free. I have a list of 201\ntransactions, I've accumulated about bc8550. Transfers in and out seem\nto work fine (after a bit of head-scratching to understand the labelling\nof incoming transactions).\n\nWhat's next?\n\nNicholas Bohm\n-- \nSalkyns, Great Canfield, Takeley,\nBishop's Stortford CM22 6SX, UK\n\nPhone 01279 870285 (+44 1279 870285)\nMobile 07715 419728 (+44 7715 419728)\n\nPGP public key ID: 0x899DD7FF. Fingerprint:\n5248 1320 B42E 84FC 1E8B A9E6 0912 AE66 899D D7FF\n\n\n", "source": "bitcoin-list", "date": "2009-02-18T14:55:50Z", "url": "https://sourceforge.net/p/bitcoin/mailman/message/21610990/", "thread_id": 9, "source_id": "21610990", "parent_id": 49 }, { "id": 51, "sent_from": "Satoshi Nakamoto", "subject": "Re: [bitcoin-list] Bitcoin v0.1.5 released", "text": "> What's next?\n\nThe next thing for v0.1.6 is to take advantage of multiple\nprocessors to generate blocks. Currently it only starts one\nthread. If you have a multi-core processor like a Core Duo or\nQuad this will double or quadruple your production.\n\nLater I want to add interfaces to make it really easy to integrate\ninto websites from any server side language.\n\nSatoshi\n\nhttp://www.bitcoin.org\n\n\n\n\n", "source": "bitcoin-list", "date": "2009-02-22T17:47:52Z", "url": "https://sourceforge.net/p/bitcoin/mailman/message/21646307/", "thread_id": 9, "source_id": "21646307", "parent_id": 50, "satoshi_id": 26 }, { "id": 52, "sent_from": "Hal Finney", "subject": "Re: [bitcoin-list] Bitcoin v0.1.5 released", "text": "On Sun, Feb 22, 2009 at 9:35 AM, Satoshi Nakamoto wrote:\n>> What's next?\n>\n> The next thing for v0.1.6 is to take advantage of multiple\n> processors to generate blocks. Currently it only starts one\n> thread. If you have a multi-core processor like a Core Duo or\n> Quad this will double or quadruple your production.\n\nThat sounds good. I'd also like to be able to run multiple coin/block\ngenerators on multiple machines, all behind a single NAT address. I\nhaven't tried this yet so I don't know if it works on the current\nsoftware.\n\nBTW I don't remember if we talked about this, but the other day some\npeople were mentioning secure timestamping. You want to be able to\nprove that a certain document existed at a certain time in the past.\nSeems to me that bitcoin's stack of blocks would be perfect for this.\n\n> Later I want to add interfaces to make it really easy to integrate\n> into websites from any server side language.\n\nRight, and I'd like to see more of a library interface that could be\ncalled from programming or scripting languages, on the client side as\nwell.\n\nHal\n\n\n", "source": "bitcoin-list", "date": "2009-02-27T20:00:12Z", "url": "https://sourceforge.net/p/bitcoin/mailman/message/21697543/", "thread_id": 9, "source_id": "21697543", "parent_id": 51 }, { "id": 53, "sent_from": "Satoshi Nakamoto", "subject": "Re: [bitcoin-list] Bitcoin v0.1.5 released", "text": "Hal Finney wrote:\n> That sounds good. I'd also like to be able to run multiple coin/block\n> generators on multiple machines, all behind a single NAT address. I\n> haven't tried this yet so I don't know if it works on the current\n> software.\n\nThe current version will work fine. They'll each connect over the\nInternet, while incoming connections only come to the host that\nport 8333 is routed to. \n\nAs an optimisation, I'll make a switch \"-connect=1.2.3.4\" to make\nit only connect to a specific address. You could make your extra\nnodes connect to your primary, and only the primary connects over\nthe Internet. It doesn't really matter for now, since the network\nwould have to get huge before the bandwidth is anything more than\ntrivial.\n\n\n> BTW I don't remember if we talked about this, but the other day some\n> people were mentioning secure timestamping. You want to be able to\n> prove that a certain document existed at a certain time in the past.\n> Seems to me that bitcoin's stack of blocks would be perfect for this.\n\nIndeed, Bitcoin is a distributed secure timestamp server for\ntransactions. A few lines of code could create a transaction with\nan extra hash in it of anything that needs to be timestamped. \nI should add a command to timestamp a file that way.\n\n\n> > > Later I want to add interfaces to make it really easy to integrate\n> > > into websites from any server side language.\n>\n> Right, and I'd like to see more of a library interface that could be\n> called from programming or scripting languages, on the client side as\n> well.\n \nExactly.\n\n \nSatoshi Nakamoto\n\nhttp://www.bitcoin.org\n\n\n\n", "source": "bitcoin-list", "date": "2009-03-04T16:59:12Z", "url": "https://sourceforge.net/p/bitcoin/mailman/message/21740046/", "thread_id": 9, "source_id": "21740046", "parent_id": 52, "satoshi_id": 27 }, { "id": 54, "sent_from": "Liberty Standard", "subject": "[bitcoin-list] Does Bitcoin Crash in Windows?", "text": " Do you Windows users experience occasional Bitcoin crashes?\n\nLately Bitcoin running in wine-1.0.1 has been crashing frequently. I was\njust wondering whether this is a Wine issue or a Bitcoin issue. I speculate\nit might have something to do with how many Bitcoins I have since it would\ncrash less when I had less bitcoins and now crashes more now that I have\nmore bitcoins. It makes me hesitant to send my balance of bitcoins to my\nfresh Bitcoin installation. But this might just be my imagination since it\nhas crashed a few times after installing Bitcoin afresh.\n\nThe following four lines print from the terminal when I start Bitcoin.\nfixme:toolhelp:CreateToolhelp32Snapshot Unimplemented: heap list snapshot\nfixme:toolhelp:Heap32ListFirst : stub\nfixme:toolhelp:CreateToolhelp32Snapshot Unimplemented: heap list snapshot\nfixme:toolhelp:Heap32ListFirst : stub\n\nI previously wasn't starting Bitcoin from the terminal, so I don't know what\ngets printed out when it crashes, but I'll reply with the results the next\ntime it crashes.\n\nWhile Bitcoin first downloads previously completed blocks, the file\ndebug.log grows grows to 17.4 MB and then stops growing. I imagine it will\ncontinue to grow as more bitcoins are completed.\n\n~NewLibertyStandard~\n\n", "source": "bitcoin-list", "date": "2009-10-23T11:50:10Z", "url": "https://sourceforge.net/p/bitcoin/mailman/message/23818861/", "thread_id": 10, "source_id": "23818861" }, { "id": 55, "sent_from": "Satoshi Nakamoto", "subject": "Re: [bitcoin-list] Does Bitcoin Crash in Windows?", "text": "Liberty Standard wrote:\n> Do you Windows users experience occasional Bitcoin crashes?\n> Lately Bitcoin running in wine-1.0.1 has been crashing frequently. I was\n> just wondering whether this is a Wine issue or a Bitcoin issue. \n\nI haven't had any reports of crashes in v0.1.5. It's been rock solid \nfor me on Windows. I think it must be Wine related. If you get another \ncrash in Wine and it prints anything on the terminal, e-mail me and I \nmay be able to figure out what happened, maybe something I can work \naround. Martti and I have been working on a new version to release soon \nand it would be nice to get any Wine fixes in there.\n\n> The following four lines print from the terminal when I start Bitcoin.\n> fixme:toolhelp:CreateToolhelp32Snapshot Unimplemented: heap list snapshot\n> fixme:toolhelp:Heap32ListFirst : stub\n> fixme:toolhelp:CreateToolhelp32Snapshot Unimplemented: heap list snapshot\n> fixme:toolhelp:Heap32ListFirst : stub\n\nThose don't look like anything to worry about. Probably functions \nunimplemented by Wine that are harmlessly stubbed out.\n\n> I previously wasn't starting Bitcoin from the terminal, so I don't know what\n> gets printed out when it crashes, but I'll reply with the results the next\n> time it crashes.\n> \n> While Bitcoin first downloads previously completed blocks, the file\n> debug.log grows grows to 17.4 MB and then stops growing. I imagine it will\n> continue to grow as more bitcoins are completed.\n\nYou can delete debug.log occasionally if you don't want to take the disk \nspace. It's just status messages that help with debugging.\n\nbitcoin.sourceforge.net looks fine now. Maybe sourceforge was doing \nsome maintenance.\n\nSatoshi\n\n\n", "source": "bitcoin-list", "date": "2009-10-23T23:57:51Z", "url": "https://sourceforge.net/p/bitcoin/mailman/message/23824064/", "thread_id": 10, "source_id": "23824064", "parent_id": 54, "satoshi_id": 28 }, { "id": 56, "sent_from": "Mike Hearn", "subject": "Re: [bitcoin-list] Does Bitcoin Crash in Windows?", "text": ">\n>\n> The following four lines print from the terminal when I start Bitcoin.\n> fixme:toolhelp:CreateToolhelp32Snapshot Unimplemented: heap list snapshot\n> fixme:toolhelp:Heap32ListFirst : stub\n> fixme:toolhelp:CreateToolhelp32Snapshot Unimplemented: heap list snapshot\n> fixme:toolhelp:Heap32ListFirst : stub\n>\n\nThat just means it failed to create a minidump, so yeah, not the cause of\nthe crash.\n\nTo find the cause of the crash you'd need to run it with a +seh,+relay trace\nand find out what the app was doing before it crashed, or look in the\nbitcoin logs.\n\n", "source": "bitcoin-list", "date": "2009-10-24T15:05:07Z", "url": "https://sourceforge.net/p/bitcoin/mailman/message/23827020/", "thread_id": 10, "source_id": "23827020", "parent_id": 54 }, { "id": 57, "sent_from": "Eugen Leitl", "subject": "Re: [bitcoin-list] Does Bitcoin Crash in Windows?", "text": "On Sat, Oct 24, 2009 at 12:55:06AM +0100, Satoshi Nakamoto wrote:\n\n> bitcoin.sourceforge.net looks fine now. Maybe sourceforge was doing \n\nDoesn't work right now.\n\n> some maintenance.\n\nStill no .deb packages for Bitcoin?\n\n-- \nEugen* Leitl leitl; http://leitl.org\n______________________________________________________________\nICBM: 48.07100, 11.36820 http://www.ativel.com http://postbiota.org\n8B29F6BE: 099D 78BA 2FD3 B014 B08A 7779 75B0 2443 8B29 F6BE\n\n\n", "source": "bitcoin-list", "date": "2009-10-26T12:46:27Z", "url": "https://sourceforge.net/p/bitcoin/mailman/message/23838155/", "thread_id": 10, "source_id": "23838155", "parent_id": 55 }, { "id": 58, "sent_from": "Satoshi Nakamoto", "subject": "[bitcoin-list] Bitcoin 0.2 released", "text": "Bitcoin 0.2 is here!\n\nDownload (Windows, and now Linux version available)\nhttp://sourceforge.net/projects/bitcoin/files/\n\nNew Features\n\nMartti Malmi\n - Minimize to system tray option\n - Autostart on boot option so you can keep it running in the \nbackground automatically\n - New options dialog layout for future expansion\n - Setup program for Windows\n - Linux version (tested on Ubuntu)\nSatoshi Nakamoto\n - Multi-processor support for coin generation\n - Proxy support for use with TOR\n - Fixed some slowdowns in the initial block download\n\nWe also have a new forum at http://www.bitcoin.org/smf/\n\nMany thanks to Martti (sirius-m) for all his development work, and to \nNew Liberty Standard for his help with testing the Linux version.\n\nSatoshi Nakamoto\n\n\n", "source": "bitcoin-list", "date": "2009-12-17T06:52:09Z", "url": "https://sourceforge.net/p/bitcoin/mailman/message/24205662/", "thread_id": 11, "source_id": "24205662", "satoshi_id": 29 }, { "id": 59, "sent_from": "Satoshi Nakamoto", "subject": "[bitcoin-list] Bitcoin 0.3 released!", "text": "Announcing version 0.3 of Bitcoin, the P2P cryptocurrency! Bitcoin is a \ndigital currency using cryptography and a distributed network to replace \nthe need for a trusted central server. Escape the arbitrary inflation \nrisk of centrally managed currencies! Bitcoin's total circulation is \nlimited to 21 million coins. The coins are gradually released to the \nnetwork's nodes based on the CPU power they contribute, so you can get a \nshare of them by contributing your idle CPU time.\n\nWhat's new:\n- Command line and JSON-RPC control\n- Includes a daemon version without GUI\n- Transaction filter tabs\n- 20% faster hashing\n- Hashmeter performance display\n- Mac OS X version (thanks to Laszlo)\n- German, Dutch and Italian translations (thanks to DataWraith, Xunie \nand Joozero)\n\nGet it at http://www.bitcoin.org, and read the forum to find out more.\n\n\n\n", "source": "bitcoin-list", "date": "2010-07-06T21:53:53Z", "url": "https://sourceforge.net/p/bitcoin/mailman/message/25686730/", "thread_id": 12, "source_id": "25686730", "satoshi_id": 30 }, { "id": 60, "sent_from": "Satoshi Nakamoto", "subject": "[bitcoin-list] Alert: upgrade to bitcoin 0.3.6", "text": "Please upgrade to 0.3.6 ASAP to get an important bugfix.\n\nSee the bitcoin.org homepage for download links.\n\n\n\n", "source": "bitcoin-list", "date": "2010-07-30T06:02:38Z", "url": "https://sourceforge.net/p/bitcoin/mailman/message/25843947/", "thread_id": 13, "source_id": "25843947", "satoshi_id": 31 }, { "id": 61, "sent_from": "Satoshi Nakamoto", "subject": "[bitcoin-list] ALERT - we are investigating a problem", "text": "*** WARNING *** We are investigating a problem. DO NOT TRUST ANY \nTRANSACTIONS THAT HAPPENED AFTER 15.08.2010 17:05 UTC (block 74638) \nuntil the issue is resolved.\n\n\n", "source": "bitcoin-list", "date": "2010-08-15T20:38:33Z", "url": "https://sourceforge.net/p/bitcoin/mailman/message/25954806/", "thread_id": 14, "source_id": "25954806", "satoshi_id": 32 }, { "id": 62, "sent_from": "Satoshi Nakamoto", "subject": "[bitcoin-list] Bitcoin 0.3.18 is released", "text": "Version 0.3.18 is now available.\n\nChanges:\n- Fixed a wallet.dat compatibility problem if you downgraded from 0.3.17 \nand then upgraded again\n- IsStandard() check to only include known transaction types in blocks\n- Jgarzik's optimisation to speed up the initial block download a little\n\nThe main addition in this release is the Accounts-based JSON-RPC \ncommands that Gavin's been working on (more details at \nhttp://www.bitcoin.org/smf/index.php?topic=1886.0).\n- getaccountaddress\n- sendfrom\n- move\n- getbalance\n- listtransactions\n\nDownload:\nhttp://sourceforge.net/projects/bitcoin/files/Bitcoin/bitcoin-0.3.18/\n\n\n\n\n\n", "source": "bitcoin-list", "date": "2010-12-08T23:11:55Z", "url": "https://sourceforge.net/p/bitcoin/mailman/message/26722835/", "thread_id": 15, "source_id": "26722835", "satoshi_id": 33 }, { "id": 63, "sent_from": "Satoshi Nakamoto", "subject": "[bitcoin-list] Bitcoin 0.3.19 is released", "text": "This is a minor release to add some DoS protection.\n\nChanges:\n- Added some DoS limits, though it's still far from DoS resistant.\n- Removed \"safe mode\" alerts.\n\nhttp://www.bitcoin.org/smf/index.php?topic=2228.0\n\nDownload:\nhttp://sourceforge.net/projects/bitcoin/files/Bitcoin/bitcoin-0.3.19/\n\n\n", "source": "bitcoin-list", "date": "2010-12-13T16:12:09Z", "url": "https://sourceforge.net/p/bitcoin/mailman/message/26744510/", "thread_id": 16, "source_id": "26744510", "satoshi_id": 34 }, { "id": 64, "sent_from": "Satoshi Nakamoto", "subject": "[p2p-research] Bitcoin open source implementation of P2P currency", "text": "I've developed a new open source P2P e-cash system called Bitcoin. It's \ncompletely decentralized, with no central server or trusted parties, \nbecause everything is based on crypto proof instead of trust. Give it a \ntry, or take a look at the screenshots and design paper:\n\nDownload Bitcoin v0.1 at http://www.bitcoin.org\n\nThe root problem with conventional currency is all the trust that's \nrequired to make it work. The central bank must be trusted not to \ndebase the currency, but the history of fiat currencies is full of \nbreaches of that trust. Banks must be trusted to hold our money and \ntransfer it electronically, but they lend it out in waves of credit \nbubbles with barely a fraction in reserve. We have to trust them with \nour privacy, trust them not to let identity thieves drain our accounts. \n Their massive overhead costs make micropayments impossible.\n\nA generation ago, multi-user time-sharing computer systems had a similar \nproblem. Before strong encryption, users had to rely on password \nprotection to secure their files, placing trust in the system \nadministrator to keep their information private. Privacy could always \nbe overridden by the admin based on his judgment call weighing the \nprinciple of privacy against other concerns, or at the behest of his \nsuperiors. Then strong encryption became available to the masses, and \ntrust was no longer required. Data could be secured in a way that was \nphysically impossible for others to access, no matter for what reason, \nno matter how good the excuse, no matter what.\n\nIt's time we had the same thing for money. With e-currency based on \ncryptographic proof, without the need to trust a third party middleman, \nmoney can be secure and transactions effortless.\n\nOne of the fundamental building blocks for such a system is digital \nsignatures. A digital coin contains the public key of its owner. To \ntransfer it, the owner signs the coin together with the public key of \nthe next owner. Anyone can check the signatures to verify the chain of \nownership. It works well to secure ownership, but leaves one big \nproblem unsolved: double-spending. Any owner could try to re-spend an \nalready spent coin by signing it again to another owner. The usual \nsolution is for a trusted company with a central database to check for \ndouble-spending, but that just gets back to the trust model. In its \ncentral position, the company can override the users, and the fees \nneeded to support the company make micropayments impractical.\n\nBitcoin's solution is to use a peer-to-peer network to check for \ndouble-spending. In a nutshell, the network works like a distributed \ntimestamp server, stamping the first transaction to spend a coin. It \ntakes advantage of the nature of information being easy to spread but \nhard to stifle. For details on how it works, see the design paper at \nhttp://www.bitcoin.org/bitcoin.pdf\n\nThe result is a distributed system with no single point of failure. \nUsers hold the crypto keys to their own money and transact directly with \neach other, with the help of the P2P network to check for double-spending.\n\nSatoshi Nakamoto\nhttp://www.bitcoin.org\n\n", "source": "p2p-research", "original_date": "Wed Feb 11 23:30:54 CET 2009", "date": "2009-02-11T22:37:54Z", "url": "https://diyhpl.us/~bryan/irc/bitcoin-satoshi/p2presearch-again/p2pfoundation.net/backups/p2p_research-archives/2009-February/001347.html", "thread_id": 17, "source_id": "001347", "satoshi_id": 35 }, { "id": 65, "sent_from": "Michel Bauwens", "subject": "[p2p-research] Bitcoin open source implementation of P2P currency", "text": "Thanks for sharing this initiative, I hope some of our more expert members\nwill intervene.\n\nI have an extra request if possible, our pages on Japanese initiatives, I'm\nassuming that is where you are based, though I could of course be wrong, are\nstill very undeveloped, so I'm wondering if you could not add a few of the\nimportant open/free and commons oriented initiatives that you know about,\nincluding your own.\n\nSee http://p2pfoundation.net/Japan\n\nMichel\n\nOn Thu, Feb 12, 2009 at 5:30 AM, Satoshi Nakamoto <satoshin at gmx.com> wrote:\n\n> I've developed a new open source P2P e-cash system called Bitcoin. It's\n> completely decentralized, with no central server or trusted parties, because\n> everything is based on crypto proof instead of trust. Give it a try, or\n> take a look at the screenshots and design paper:\n>\n> Download Bitcoin v0.1 at http://www.bitcoin.org\n>\n> The root problem with conventional currency is all the trust that's\n> required to make it work. The central bank must be trusted not to debase\n> the currency, but the history of fiat currencies is full of breaches of that\n> trust. Banks must be trusted to hold our money and transfer it\n> electronically, but they lend it out in waves of credit bubbles with barely\n> a fraction in reserve. We have to trust them with our privacy, trust them\n> not to let identity thieves drain our accounts. Their massive overhead\n> costs make micropayments impossible.\n>\n> A generation ago, multi-user time-sharing computer systems had a similar\n> problem. Before strong encryption, users had to rely on password protection\n> to secure their files, placing trust in the system administrator to keep\n> their information private. Privacy could always be overridden by the admin\n> based on his judgment call weighing the principle of privacy against other\n> concerns, or at the behest of his superiors. Then strong encryption became\n> available to the masses, and trust was no longer required. Data could be\n> secured in a way that was physically impossible for others to access, no\n> matter for what reason, no matter how good the excuse, no matter what.\n>\n> It's time we had the same thing for money. With e-currency based on\n> cryptographic proof, without the need to trust a third party middleman,\n> money can be secure and transactions effortless.\n>\n> One of the fundamental building blocks for such a system is digital\n> signatures. A digital coin contains the public key of its owner. To\n> transfer it, the owner signs the coin together with the public key of the\n> next owner. Anyone can check the signatures to verify the chain of\n> ownership. It works well to secure ownership, but leaves one big problem\n> unsolved: double-spending. Any owner could try to re-spend an already spent\n> coin by signing it again to another owner. The usual solution is for a\n> trusted company with a central database to check for double-spending, but\n> that just gets back to the trust model. In its central position, the\n> company can override the users, and the fees needed to support the company\n> make micropayments impractical.\n>\n> Bitcoin's solution is to use a peer-to-peer network to check for\n> double-spending. In a nutshell, the network works like a distributed\n> timestamp server, stamping the first transaction to spend a coin. It takes\n> advantage of the nature of information being easy to spread but hard to\n> stifle. For details on how it works, see the design paper at\n> http://www.bitcoin.org/bitcoin.pdf\n>\n> The result is a distributed system with no single point of failure. Users\n> hold the crypto keys to their own money and transact directly with each\n> other, with the help of the P2P network to check for double-spending.\n>\n> Satoshi Nakamoto\n> http://www.bitcoin.org\n>\n> _______________________________________________\n> p2presearch mailing list\n> p2presearch at listcultures.org\n> http://listcultures.org/mailman/listinfo/p2presearch_listcultures.org\n>\n\n\n\n-- \nThe P2P Foundation researches, documents and promotes peer to peer\nalternatives.\n\nWiki and Encyclopedia, at http://p2pfoundation.net; Blog, at\nhttp://blog.p2pfoundation.net; Newsletter, at\nhttp://integralvisioning.org/index.php?topic=p2p\n\nBasic essay at http://www.ctheory.net/articles.aspx?id=499; interview at\nhttp://poynder.blogspot.com/2006/09/p2p-very-core-of-world-to-come.html\nBEST VIDEO ON P2P:\nhttp://video.google.com.au/videoplay?docid=4549818267592301968&hl=en-AU\n\nKEEP UP TO DATE through our Delicious tags at http://del.icio.us/mbauwens\n\nThe work of the P2P Foundation is supported by SHIFTN,\nhttp://www.shiftn.com/\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://listcultures.org/pipermail/p2presearch_listcultures.org/attachments/20090212/41b802b7/attachment-0001.html>\n", "source": "p2p-research", "original_date": "Thu Feb 12 03:08:30 CET 2009", "date": "2009-02-12T02:15:30Z", "url": "https://diyhpl.us/~bryan/irc/bitcoin-satoshi/p2presearch-again/p2pfoundation.net/backups/p2p_research-archives/2009-February/001348.html", "thread_id": 17, "source_id": "001348", "parent_id": 64 }, { "id": 66, "sent_from": "Martien van Steenbergen", "subject": "[p2p-research] Bitcoin open source implementation of P2P currency", "text": "Very interesting. Is this akin to David Chaum's anonymous digital \nmoney? His concept makes sure money is anonymous unless it is \ncompromised, i.e. the same money spent more than once. As soon as it's \ncompromised, the \u2018counterfeiter\u2019 is immediately publicly exposed.\n\nAlso, in bitcoin, is there a limited supply of money (that must be \nmanaged)? Or is money created exaclty at the moment of transaction?\n\nSucces en plezier,\n\nMartien.\n\nOn 11 Feb 2009, at 23:30 , Satoshi Nakamoto wrote:\n\n> I've developed a new open source P2P e-cash system called Bitcoin. \n> It's completely decentralized, with no central server or trusted \n> parties, because everything is based on crypto proof instead of \n> trust. Give it a try, or take a look at the screenshots and design \n> paper:\n>\n> Download Bitcoin v0.1 at http://www.bitcoin.org\n>\n> The root problem with conventional currency is all the trust that's \n> required to make it work. The central bank must be trusted not to \n> debase the currency, but the history of fiat currencies is full of \n> breaches of that trust. Banks must be trusted to hold our money and \n> transfer it electronically, but they lend it out in waves of credit \n> bubbles with barely a fraction in reserve. We have to trust them \n> with our privacy, trust them not to let identity thieves drain our \n> accounts. Their massive overhead costs make micropayments impossible.\n>\n> A generation ago, multi-user time-sharing computer systems had a \n> similar problem. Before strong encryption, users had to rely on \n> password protection to secure their files, placing trust in the \n> system administrator to keep their information private. Privacy \n> could always be overridden by the admin based on his judgment call \n> weighing the principle of privacy against other concerns, or at the \n> behest of his superiors. Then strong encryption became available to \n> the masses, and trust was no longer required. Data could be secured \n> in a way that was physically impossible for others to access, no \n> matter for what reason, no matter how good the excuse, no matter what.\n>\n> It's time we had the same thing for money. With e-currency based on \n> cryptographic proof, without the need to trust a third party \n> middleman, money can be secure and transactions effortless.\n>\n> One of the fundamental building blocks for such a system is digital \n> signatures. A digital coin contains the public key of its owner. \n> To transfer it, the owner signs the coin together with the public \n> key of the next owner. Anyone can check the signatures to verify \n> the chain of ownership. It works well to secure ownership, but \n> leaves one big problem unsolved: double-spending. Any owner could \n> try to re-spend an already spent coin by signing it again to another \n> owner. The usual solution is for a trusted company with a central \n> database to check for double-spending, but that just gets back to \n> the trust model. In its central position, the company can override \n> the users, and the fees needed to support the company make \n> micropayments impractical.\n>\n> Bitcoin's solution is to use a peer-to-peer network to check for \n> double-spending. In a nutshell, the network works like a \n> distributed timestamp server, stamping the first transaction to \n> spend a coin. It takes advantage of the nature of information being \n> easy to spread but hard to stifle. For details on how it works, see \n> the design paper at http://www.bitcoin.org/bitcoin.pdf\n>\n> The result is a distributed system with no single point of failure. \n> Users hold the crypto keys to their own money and transact directly \n> with each other, with the help of the P2P network to check for \n> double-spending.\n>\n> Satoshi Nakamoto\n> http://www.bitcoin.org\n>\n> _______________________________________________\n> p2presearch mailing list\n> p2presearch at listcultures.org\n> http://listcultures.org/mailman/listinfo/p2presearch_listcultures.org\n\n\n", "source": "p2p-research", "original_date": "Thu Feb 12 08:40:53 CET 2009", "date": "2009-02-12T07:47:53Z", "url": "https://diyhpl.us/~bryan/irc/bitcoin-satoshi/p2presearch-again/p2pfoundation.net/backups/p2p_research-archives/2009-February/001355.html", "thread_id": 17, "source_id": "001355", "parent_id": 64 }, { "id": 67, "sent_from": "Satoshi Nakamoto", "subject": "[p2p-research] Bitcoin open source implementation of P2P currency", "text": "Martien van Steenbergen wrote:\n> Very interesting. Is this akin to David Chaum's anonymous digital money? \n> His concept makes sure money is anonymous unless it is compromised, i.e. \n> the same money spent more than once. As soon as it's compromised, the \n> \u2018counterfeiter\u2019 is immediately publicly exposed.\n\nIt's similar in that it uses digital signatures for coins, but different \nin the approach to privacy and preventing double-spending. The \nrecipient of a Bitcoin payment is able to check whether it is the first \nspend or not, and second-spends are not accepted. There isn't an \noff-line mode where double-spenders are caught and shamed after the \nfact, because that would require participants to have identities.\n\nTo protect privacy, key pairs are used only once, with a new one for \nevery transaction. The owner of a coin is just whoever has its private key.\n\nOf course, the biggest difference is the lack of a central server. That \nwas the Achilles heel of Chaumian systems; when the central company shut \ndown, so did the currency.\n\n> Also, in bitcoin, is there a limited supply of money (that must be \n> managed)? Or is money created exaclty at the moment of transaction?\n\nThere is a limited supply of money. Circulation will be 21,000,000 \ncoins. Transactions only transfer ownership.\n\nThank you for your questions,\n\nSatoshi\n\nhttp://www.bitcoin.org\n\n", "source": "p2p-research", "original_date": "Thu Feb 12 20:01:24 CET 2009", "date": "2009-02-12T19:08:24Z", "url": "https://diyhpl.us/~bryan/irc/bitcoin-satoshi/p2presearch-again/p2pfoundation.net/backups/p2p_research-archives/2009-February/001356.html", "thread_id": 17, "source_id": "001356", "satoshi_id": 36, "parent_id": 66 }, { "id": 68, "sent_from": "Martien van Steenbergen", "subject": "[p2p-research] Bitcoin open source implementation of P2P currency", "text": "\nOn 12 Feb 2009, at 20:01 , Satoshi Nakamoto wrote:\n\n> Martien van Steenbergen wrote:\n>> Very interesting. Is this akin to David Chaum's anonymous digital \n>> money? His concept makes sure money is anonymous unless it is \n>> compromised, i.e. the same money spent more than once. As soon as \n>> it's compromised, the \u2018counterfeiter\u2019 is immediately publicly \n>> exposed.\n>\n> It's similar in that it uses digital signatures for coins, but \n> different in the approach to privacy and preventing double- \n> spending. The recipient of a Bitcoin payment is able to check \n> whether it is the first spend or not, and second-spends are not \n> accepted. There isn't an off-line mode where double-spenders are \n> caught and shamed after the fact, because that would require \n> participants to have identities.\n\nThanks for clearing this up.\n\n> To protect privacy, key pairs are used only once, with a new one for \n> every transaction. The owner of a coin is just whoever has its \n> private key.\n\nIC.\n\n> Of course, the biggest difference is the lack of a central server. \n> That was the Achilles heel of Chaumian systems; when the central \n> company shut down, so did the currency.\n\nYes, that's really great. Reminds me of:\n\nAardRock \u00bb Wizard Rabbit Treasurer; and\nAardRock \u00bb Pekunio\n\n>> Also, in bitcoin, is there a limited supply of money (that must be \n>> managed)? Or is money created exaclty at the moment of transaction?\n>\n> There is a limited supply of money. Circulation will be 21,000,000 \n> coins. Transactions only transfer ownership.\n\nWould love to also see support for not having to supply and managing \nmoney. Would make it easier and cheaper to maintain and results in \nhave sufficient money, always and everywhere. No scarcity, no \nabundance, exactly the right amount all times, self-organizing.\n\nAre you familiar with Ripple?\n\nIs bitcoin also available as a protocol spec (facilitating differen \nlanguage bindings and implementations; unite on specs, compete on \nimplementation).\n\nSucces en plezier,\n\nMartien.\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://listcultures.org/pipermail/p2presearch_listcultures.org/attachments/20090212/9c83bdd1/attachment.html>\n", "source": "p2p-research", "original_date": "Thu Feb 12 21:01:03 CET 2009", "date": "2009-02-12T20:08:03Z", "url": "https://diyhpl.us/~bryan/irc/bitcoin-satoshi/p2presearch-again/p2pfoundation.net/backups/p2p_research-archives/2009-February/001357.html", "thread_id": 17, "source_id": "001357", "parent_id": 67 }, { "id": 69, "sent_from": "Satoshi Nakamoto", "subject": "[p2p-research] Bitcoin open source implementation of P2P currency", "text": "Martien van Steenbergen wrote:\n > Would love to also see support for not having to supply and\n > managing money. Would make it easier and cheaper to maintain\n > and results in have sufficient money, always and everywhere.\n > No scarcity, no abundance, exactly the right amount all times,\n > self-organizing.\n\nThat's do-able. It can be programmed to follow any set of rules.\n\nI see Bitcoin as a foundation and first step if you want to implement \nprogrammable P2P social currencies like Marc's ideas and others \ndiscussed here. First you need normal, basic P2P currency working. \nOnce that is established and proven out, dynamic smart money is an easy \nnext step.\n\nI love the idea of virtual, non-geographic communities experimenting \nwith new economic paradigms.\n\n> Reminds me of:\n> \n> * AardRock \u00bb Wizard Rabbit Treasurer\n> <http://wiki.aardrock.com/Wizard_Rabbit_Treasurer>; and\n> * AardRock \u00bb Pekunio <http://wiki.aardrock.com/Pekunio>\n\nIndeed, it is much like Pekunio in the concept of spraying redundant \ncopies of every transaction to a number of peers on the network, but the \nimplementation is not a reputation network like Wizard Rabbit Treasurer. \n In fact, Bitcoin does not use reputation at all. It sees the network \nas just a big crowd and doesn't much care who it talks to or who tells \nit something, as long as at least one of them relays the information \nbeing broadcast around the network. It doesn't care because there's no \nway to lie to it. Either you tell it crypto proof of something, or it \nignores you.\n\n> Are you familiar with Ripple?\n\nAs trust systems go, Ripple is unique in spreading trust around rather \nthan concentrating it.\n\n> Is bitcoin also available as a protocol spec (facilitating differen \n> language bindings and implementations; unite on specs, compete on \n> implementation).\n\nIt would be best to refer to the C++ source code. I plan to implement \ninterfaces for using the software to send and receive transactions from \nany language, so server side code can easily use it for web based \ne-commerce sites.\n\nSatoshi\n\n", "source": "p2p-research", "original_date": "Fri Feb 13 03:31:20 CET 2009", "date": "2009-02-13T02:38:20Z", "url": "https://diyhpl.us/~bryan/irc/bitcoin-satoshi/p2presearch-again/p2pfoundation.net/backups/p2p_research-archives/2009-February/001362.html", "thread_id": 17, "source_id": "001362", "satoshi_id": 37, "parent_id": 68 }, { "id": 70, "sent_from": "Michel Bauwens", "subject": "[p2p-research] Bitcoin open source implementation of P2P currency", "text": "Hi Satoshi,\n\nhow operational is your project? how soon do you think people will be able\nto use it in real life?\n\nMichel\n\nOn Fri, Feb 13, 2009 at 9:31 AM, Satoshi Nakamoto <satoshin at gmx.com> wrote:\n\n> Martien van Steenbergen wrote:\n> > Would love to also see support for not having to supply and\n> > managing money. Would make it easier and cheaper to maintain\n> > and results in have sufficient money, always and everywhere.\n> > No scarcity, no abundance, exactly the right amount all times,\n> > self-organizing.\n>\n> That's do-able. It can be programmed to follow any set of rules.\n>\n> I see Bitcoin as a foundation and first step if you want to implement\n> programmable P2P social currencies like Marc's ideas and others discussed\n> here. First you need normal, basic P2P currency working. Once that is\n> established and proven out, dynamic smart money is an easy next step.\n>\n> I love the idea of virtual, non-geographic communities experimenting with\n> new economic paradigms.\n>\n> Reminds me of:\n>>\n>> * AardRock \u00bb Wizard Rabbit Treasurer\n>> <http://wiki.aardrock.com/Wizard_Rabbit_Treasurer>; and\n>> * AardRock \u00bb Pekunio <http://wiki.aardrock.com/Pekunio>\n>>\n>\n> Indeed, it is much like Pekunio in the concept of spraying redundant copies\n> of every transaction to a number of peers on the network, but the\n> implementation is not a reputation network like Wizard Rabbit Treasurer. In\n> fact, Bitcoin does not use reputation at all. It sees the network as just a\n> big crowd and doesn't much care who it talks to or who tells it something,\n> as long as at least one of them relays the information being broadcast\n> around the network. It doesn't care because there's no way to lie to it.\n> Either you tell it crypto proof of something, or it ignores you.\n>\n> Are you familiar with Ripple?\n>>\n>\n> As trust systems go, Ripple is unique in spreading trust around rather than\n> concentrating it.\n>\n> Is bitcoin also available as a protocol spec (facilitating differen\n>> language bindings and implementations; unite on specs, compete on\n>> implementation).\n>>\n>\n> It would be best to refer to the C++ source code. I plan to implement\n> interfaces for using the software to send and receive transactions from any\n> language, so server side code can easily use it for web based e-commerce\n> sites.\n>\n> Satoshi\n>\n>\n> _______________________________________________\n> p2presearch mailing list\n> p2presearch at listcultures.org\n> http://listcultures.org/mailman/listinfo/p2presearch_listcultures.org\n>\n\n\n\n-- \nThe P2P Foundation researches, documents and promotes peer to peer\nalternatives.\n\nWiki and Encyclopedia, at http://p2pfoundation.net; Blog, at\nhttp://blog.p2pfoundation.net; Newsletter, at\nhttp://integralvisioning.org/index.php?topic=p2p\n\nBasic essay at http://www.ctheory.net/articles.aspx?id=499; interview at\nhttp://poynder.blogspot.com/2006/09/p2p-very-core-of-world-to-come.html\nBEST VIDEO ON P2P:\nhttp://video.google.com.au/videoplay?docid=4549818267592301968&hl=en-AU\n\nKEEP UP TO DATE through our Delicious tags at http://del.icio.us/mbauwens\n\nThe work of the P2P Foundation is supported by SHIFTN,\nhttp://www.shiftn.com/\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://listcultures.org/pipermail/p2presearch_listcultures.org/attachments/20090213/148aa6a5/attachment.html>\n", "source": "p2p-research", "original_date": "Fri Feb 13 07:12:18 CET 2009", "date": "2009-02-13T06:19:18Z", "url": "https://diyhpl.us/~bryan/irc/bitcoin-satoshi/p2presearch-again/p2pfoundation.net/backups/p2p_research-archives/2009-February/001366.html", "thread_id": 17, "source_id": "001366", "parent_id": 69 }, { "id": 71, "sent_from": "Satoshi Nakamoto", "subject": "[p2p-research] Bitcoin open source implementation of P2P currency", "text": "Michel Bauwens wrote:\n> how operational is your project? how soon do you think people will be \n> able to use it in real life?\n\nIt's fully operational and the network is growing. If you try the \nsoftware, e-mail me your Bitcoin address and I'll send you a few coins.\n\nWe just need to spread the word and keep getting more people interested.\n\nI'll forward the release introduction in the next message.\n\nSatoshi\n\nhttp://www.bitcoin.org\n\n", "source": "p2p-research", "original_date": "Fri Feb 13 19:29:45 CET 2009", "date": "2009-02-13T18:36:45Z", "url": "https://diyhpl.us/~bryan/irc/bitcoin-satoshi/p2presearch-again/p2pfoundation.net/backups/p2p_research-archives/2009-February/001370.html", "thread_id": 17, "source_id": "001370", "satoshi_id": 38, "parent_id": 70 }, { "id": 72, "sent_from": "Satoshi Nakamoto", "subject": "[p2p-research] Bitcoin P2P e-currency v0.1 released", "text": "Announcing the release of Bitcoin, a new open source peer-to-peer \nelectronic cash system that's completely decentralized, with no central \nserver or trusted parties. Users hold the crypto keys to their own \nmoney and transact directly with each other, with the help of the P2P \nnetwork to check for double-spending.\n\nWindows NT/2000/XP/Vista. Open source C++ code is included.\n\nDownload: http://www.bitcoin.org\n\n- Unpack the files into a directory\n- Run BITCOIN.EXE\n- It automatically connects to other nodes\n\nIf you can keep a node running that accepts incoming connections, you'll \nreally be helping the network a lot. Port 8333 on your firewall needs \nto be open to receive incoming connections.\n\nYou can get coins by getting someone to send you some, or turn on \nOptions->Generate Coins to run a node and generate blocks. I made the \nproof-of-work difficulty ridiculously easy to start with, so for a \nlittle while in the beginning a typical PC will be able to generate \ncoins in just a few hours. It'll get a lot harder when competition \nmakes the automatic adjustment drive up the difficulty. Generated coins \nmust wait 120 blocks to mature before they can be spent.\n\nThere are two ways to send money. If the recipient is online, you can \nenter their IP address and it will connect, get a new public key and \nsend the transaction with comments. If the recipient is not online, it \nis possible to send to their Bitcoin address, which is a hash of their \npublic key that they give you. They'll receive the transaction the next \ntime they connect and get the block it's in. This method has the \ndisadvantage that no comment information is sent, and a bit of privacy \nmay be lost if the address is used multiple times, but it is a useful \nalternative if both users can't be online at the same time or the \nrecipient can't receive incoming connections.\n\nTotal circulation will be 21,000,000 coins. It'll be distributed to \nnetwork nodes when they make blocks, with the amount cut in half every 4 \nyears.\n\nfirst 4 years: 10,500,000 coins\nnext 4 years: 5,250,000 coins\nnext 4 years: 2,625,000 coins\nnext 4 years: 1,312,500 coins\netc...\n\nWhen that runs out, the system can support transaction fees if needed. \nIt's based on open market competition, and there will probably always be \nnodes willing to process transactions for free.\n\nSatoshi Nakamoto\n\nhttp://www.bitcoin.org\n\n", "source": "p2p-research", "original_date": "Fri Feb 13 19:45:41 CET 2009", "date": "2009-02-13T18:52:41Z", "url": "https://diyhpl.us/~bryan/irc/bitcoin-satoshi/p2presearch-again/p2pfoundation.net/backups/p2p_research-archives/2009-February/001371.html", "thread_id": 18, "source_id": "001371", "satoshi_id": 39 } ]