I’ve been working on a new electronic cash system that’s fully
\npeer-to-peer, with no trusted third party.<\/p>\n
The paper is available at:
\nhttp:\/\/www.bitcoin.org\/bitcoin.pdf<\/p>\n
The main properties:
\nDouble-spending is prevented with a peer-to-peer network.
\nNo mint or other trusted parties.
\nParticipants can be anonymous.
\nNew coins are made from Hashcash style proof-of-work.
\nThe proof-of-work for new coin generation also powers the
\nnetwork to prevent double-spending.<\/p>\n
Bitcoin: A Peer-to-Peer Electronic Cash System<\/p>\n
Abstract. 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.<\/p>\n
Full paper at:
\nhttp:\/\/www.bitcoin.org\/bitcoin.pdf<\/p>\n
Satoshi Nakamoto<\/p>\n
>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.<\/p><\/blockquote>\nLong before the network gets anywhere near as large as that, it would be safe
\nfor users to use Simplified Payment Verification (section 8) to check for
\ndouble spending, which only requires having the chain of block headers, or
\nabout 12KB per day. Only people trying to create new coins would need to run
\nnetwork nodes. At first, most users would run network nodes, but as the
\nnetwork grows beyond a certain point, it would be left more and more to
\nspecialists with server farms of specialized hardware. A server farm would
\nonly need to have one node on the network and the rest of the LAN connects with
\nthat one node.<\/p>\nThe bandwidth might not be as prohibitive as you think. A typical transaction
\nwould be about 400 bytes (ECC is nicely compact). Each transaction has to be
\nbroadcast twice, so lets say 1KB per transaction. Visa processed 37 billion
\ntransactions in FY2008, or an average of 100 million transactions per day.
\nThat many transactions would take 100GB of bandwidth, or the size of 12 DVD or
\n2 HD quality movies, or about $18 worth of bandwidth at current prices.<\/p>\nIf the network were to get that big, it would take several years, and by then,
\nsending 2 HD movies over the Internet would probably not seem like a big deal.<\/p>\nSatoshi Nakamoto<\/p>\n
\nRelated posts:<\/h3>
\n
- Bitcoin P2P e-cash paper <\/a> I’ve been working on a new electronic cash system that’s...<\/small><\/li>\n
- Re: Bitcoin P2P e-cash paper <\/a> James A. Donald wrote: > > Fortunately, it’s only necessary...<\/small><\/li>\n
- Re: Bitcoin P2P e-cash paper <\/a> James A. Donald wrote: > The core concept is that...<\/small><\/li>\n
- Re: Bitcoin P2P e-cash paper <\/a> James A. Donald wrote: > Furthermore, it cannot be made...<\/small><\/li>\n
- Re: Bitcoin P2P e-cash paper <\/a> Hal Finney wrote: > it is mentioned that if a...<\/small><\/li>\n
- Re: Bitcoin P2P e-cash paper <\/a> James A. Donald wrote: > So what happened to the...<\/small><\/li>\n<\/ol>\n<\/div>\n", "date": "2008-11-02 17:56:37" }, { "id": 11, "url": "http:\/\/satoshinakamoto.me\/2008\/11\/03\/re-bitcoin-p2p-e-cash-paper-2\/", "title": "Re: Bitcoin P2P e-cash paper", "content": "
>> 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.<\/p><\/blockquote>\nThanks for bringing up that point.<\/p>\n
I didn’t really make that statement as strong as I could have. The requirement
\nis that the good guys collectively have more CPU power than any single
\nattacker.<\/p>\nThere would be many smaller zombie farms that are not big enough to overpower
\nthe network, and they could still make money by generating bitcoins. The
\nsmaller farms are then the “honest nodes”. (I need a better term than
\n“honest”) The more smaller farms resort to generating bitcoins, the higher the
\nbar gets to overpower the network, making larger farms also too small to
\noverpower it so that they may as well generate bitcoins too. According to the
\n“long tail” theory, the small, medium and merely large farms put together
\nshould add up to a lot more than the biggest zombie farm.<\/p>\nEven if a bad guy does overpower the network, it’s not like he’s instantly
\nrich. All he can accomplish is to take back money he himself spent, like
\nbouncing a check. To exploit it, he would have to buy something from a
\nmerchant, wait till it ships, then overpower the network and try to take his
\nmoney back. I don’t think he could make as much money trying to pull a carding
\nscheme like that as he could by generating bitcoins. With a zombie farm that
\nbig, he could generate more bitcoins than everyone else combined.<\/p>\nThe Bitcoin network might actually reduce spam by diverting zombie farms to
\ngenerating bitcoins instead.<\/p>\nSatoshi Nakamoto<\/p>\n
\nRelated posts:<\/h3>
\n
- Bitcoin P2P e-cash paper <\/a> I’ve been working on a new electronic cash system that’s...<\/small><\/li>\n
- Re: Bitcoin P2P e-cash paper <\/a> >Satoshi Nakamoto wrote: >> I’ve been working on a new...<\/small><\/li>\n
- Re: Bitcoin P2P e-cash paper <\/a> Ray Dillinger: > the “currency” is inflationary at about 35%...<\/small><\/li>\n
- Re: Bitcoin P2P e-cash paper <\/a> James A. Donald wrote: > The core concept is that...<\/small><\/li>\n
- Re: Bitcoin P2P e-cash paper <\/a> Hal Finney wrote: > it is mentioned that if a...<\/small><\/li>\n
- Re: Bitcoin P2P e-cash paper <\/a> James A. Donald wrote: >OK, suppose one node incorporates a...<\/small><\/li>\n<\/ol>\n<\/div>\n", "date": "2008-11-03 11:45:39" }, { "id": 13, "url": "http:\/\/satoshinakamoto.me\/2008\/11\/07\/re-bitcoin-p2p-e-cash-paper-3\/", "title": "Re: Bitcoin P2P e-cash paper", "content": "
>[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.<\/p><\/blockquote>\nYes, but we can win a major battle in the arms race and gain a new territory of
\nfreedom for several years.<\/p>\nGovernments are good at cutting off the heads of a centrally controlled
\nnetworks like Napster, but pure P2P networks like Gnutella and Tor seem to be
\nholding their own.<\/p>\nSatoshi<\/p>\n
\nRelated posts:<\/h3>
\n
- Re: Bitcoin P2P e-cash paper <\/a> Ray Dillinger wrote: > One way to do this would...<\/small><\/li>\n
- Re: Bitcoin P2P e-cash paper <\/a> >Satoshi Nakamoto wrote: >> I’ve been working on a new...<\/small><\/li>\n
- Re: Bitcoin P2P e-cash paper <\/a> I’ll try and hurry up and release the sourcecode as...<\/small><\/li>\n
- Re: Bitcoin P2P e-cash paper <\/a> James A. Donald wrote: > Furthermore, it cannot be made...<\/small><\/li>\n
- Re: Bitcoin P2P e-cash paper <\/a> Ray Dillinger: > the “currency” is inflationary at about 35%...<\/small><\/li>\n
- Re: Bitcoin P2P e-cash paper <\/a> James A. Donald wrote: >OK, suppose one node incorporates a...<\/small><\/li>\n<\/ol>\n<\/div>\n", "date": "2008-11-07 09:30:24" }, { "id": 38, "url": "http:\/\/satoshinakamoto.me\/2008\/11\/08\/re-bitcoin-p2p-e-cash-paper-4\/", "title": "Re: Bitcoin P2P e-cash paper", "content": "
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<\/p><\/blockquote>\nIncreasing hardware speed is handled: “To compensate for increasing hardware
\nspeed and varying interest in running nodes over time, the proof-of-work
\ndifficulty is determined by a moving average targeting an average number of
\nblocks per hour. If they’re generated too fast, the difficulty increases.”<\/p>\nAs computers get faster and the total computing power applied to creating
\nbitcoins increases, the difficulty increases proportionally to keep the total
\nnew production constant. Thus, it is known in advance how many new bitcoins
\nwill be created every year in the future.<\/p>\nThe fact that new coins are produced means the money supply increases by a
\nplanned amount, but this does not necessarily result in inflation. If the
\nsupply of money increases at the same rate that the number of people using it
\nincreases, prices remain stable. If it does not increase as fast as demand,
\nthere will be deflation and early holders of money will see its value increase.<\/p>\nCoins have to get initially distributed somehow, and a constant rate seems like
\nthe best formula.<\/p>\nSatoshi Nakamoto<\/p>\n
\nRelated posts:<\/h3>
\n
- Re: Bitcoin P2P e-cash paper <\/a> James A. Donald wrote: > Furthermore, it cannot be made...<\/small><\/li>\n
- Re: Bitcoin P2P e-cash paper <\/a> >> As long as honest nodes control the most CPU...<\/small><\/li>\n
- Re: Bitcoin P2P e-cash paper <\/a> I’ll try and hurry up and release the sourcecode as...<\/small><\/li>\n
- Re: Bitcoin P2P e-cash paper <\/a> >Satoshi Nakamoto wrote: >> I’ve been working on a new...<\/small><\/li>\n
- Re: Bitcoin P2P e-cash paper <\/a> James A. Donald wrote: > So what happened to the...<\/small><\/li>\n
- Re: Bitcoin P2P e-cash paper <\/a> James A. Donald wrote: > It is not sufficient that...<\/small><\/li>\n<\/ol>\n<\/div>\n", "date": "2008-11-08 13:38:37" }, { "id": 52, "url": "http:\/\/satoshinakamoto.me\/2008\/11\/09\/re-bitcoin-p2p-e-cash-paper-5\/", "title": "Re: Bitcoin P2P e-cash paper", "content": "
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?<\/p><\/blockquote>\nRight, nodes keep transactions in their working set until they get into a
\nblock. If a transaction reaches 90% of nodes, then each time a new block is
\nfound, it has a 90% chance of being in it.<\/p>\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.)<\/p><\/blockquote>\nThat does not need to be checked for. The transaction in whichever branch ends
\nup getting ahead becomes the valid one, the other is invalid. If someone tries
\nto double spend like that, one and only one spend will always become valid, the
\nothers invalid.<\/p>\nReceivers of transactions will normally need to hold transactions for perhaps
\nan hour or more to allow time for this kind of possibility to be resolved.
\nThey can still re-spend the coins immediately, but they should wait before
\ntaking an action such as shipping goods.<\/p>\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.<\/p><\/blockquote>\nThe attacker isn’t adding blocks to the end. He has to go back and redo the
\nblock his transaction is in and all the blocks after it, as well as any new
\nblocks the network keeps adding to the end while he’s doing that. He’s
\nrewriting history. Once his branch is longer, it becomes the new valid one.<\/p>\nThis touches on a key point. Even though everyone present may see the
\nshenanigans going on, there’s no way to take advantage of that fact.<\/p>\nIt is strictly necessary that the longest chain is always considered the valid
\none. Nodes that were present may remember that one branch was there first and
\ngot replaced by another, but there would be no way for them to convince those
\nwho were not present of this. We can’t have subfactions of nodes that cling to
\none branch that they think was first, others that saw another branch first, and
\nothers that joined later and never saw what happened. The CPU power
\nproof-of-work vote must have the final say. The only way for everyone to stay
\non the same page is to believe that the longest chain is always the valid one,
\nno matter what.<\/p>\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?<\/p><\/blockquote>\nThe recipient just needs to verify it back to a depth that is sufficiently far
\nback in the block chain, which will often only require a depth of 2
\ntransactions. All transactions before that can be discarded.<\/p>\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?<\/p><\/blockquote>\nRight, exactly. When a node receives a block, it checks the signatures of
\nevery transaction in it against previous transactions in blocks. Blocks can
\nonly contain transactions that depend on valid transactions in previous blocks
\nor the same block. Transaction C could depend on transaction B in the same
\nblock and B depends on transaction A in an earlier block.<\/p>\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.<\/p><\/blockquote>\nI appreciate your questions. I actually did this kind of backwards. I had to
\nwrite all the code before I could convince myself that I could solve every
\nproblem, then I wrote the paper. I think I will be able to release the code
\nsooner than I could write a detailed spec. You’re already right about most of
\nyour assumptions where you filled in the blanks.<\/p>\nSatoshi Nakamoto<\/p>\n
\nRelated posts:<\/h3>
\n
- Re: Bitcoin P2P e-cash paper <\/a> James A. Donald wrote: > So what happened to the...<\/small><\/li>\n
- Re: Bitcoin P2P e-cash paper <\/a> I’ll try and hurry up and release the sourcecode as...<\/small><\/li>\n
- Re: Bitcoin P2P e-cash paper <\/a> Hal Finney wrote: > I think it is necessary that...<\/small><\/li>\n
- Re: Bitcoin P2P e-cash paper <\/a> James A. Donald wrote: > The core concept is that...<\/small><\/li>\n
- Re: Bitcoin P2P e-cash paper <\/a> James A. Donald wrote: >OK, suppose one node incorporates a...<\/small><\/li>\n
- Re: Bitcoin P2P e-cash paper <\/a> Ray Dillinger wrote: > One way to do this would...<\/small><\/li>\n<\/ol>\n<\/div>\n", "date": "2008-11-09 11:13:12" }, { "id": 61, "url": "http:\/\/satoshinakamoto.me\/2008\/11\/09\/re-bitcoin-p2p-e-cash-paper-7\/", "title": "Re: Bitcoin P2P e-cash paper", "content": "
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?<\/p><\/blockquote>\nThe proof-of-work chain is the solution to the synchronisation problem, and to
\nknowing what the globally shared view is without having to trust anyone.<\/p>\nA transaction will quickly propagate throughout the network, so if two versions
\nof the same transaction were reported at close to the same time, the one with
\nthe head start would have a big advantage in reaching many more nodes first.
\nNodes will only accept the first one they see, refusing the second one to
\narrive, so the earlier transaction would have many more nodes working on
\nincorporating it into the next proof-of-work. In effect, each node votes for
\nits viewpoint of which transaction it saw first by including it in its
\nproof-of-work effort.<\/p>\nIf the transactions did come at exactly the same time and there was an even
\nsplit, it’s a toss up based on which gets into a proof-of-work first, and that
\ndecides which is valid.<\/p>\nWhen a node finds a proof-of-work, the new block is propagated throughout the
\nnetwork and everyone adds it to the chain and starts working on the next block
\nafter it. Any nodes that had the other transaction will stop trying to include
\nit in a block, since it’s now invalid according to the accepted chain.<\/p>\nThe proof-of-work chain is itself self-evident proof that it came from the
\nglobally shared view. Only the majority of the network together has enough CPU
\npower to generate such a difficult chain of proof-of-work. Any user, upon
\nreceiving the proof-of-work chain, can see what the majority of the network has
\napproved. Once a transaction is hashed into a link that’s a few links back in
\nthe chain, it is firmly etched into the global history.<\/p>\nSatoshi Nakamoto<\/p>\n
\nRelated posts:<\/h3>
\n
- Re: Bitcoin P2P e-cash paper <\/a> James A. Donald wrote: > It is not sufficient that...<\/small><\/li>\n
- Re: Bitcoin P2P e-cash paper <\/a> Hal Finney wrote: > it is mentioned that if a...<\/small><\/li>\n
- Re: Bitcoin P2P e-cash paper <\/a> James A. Donald wrote: >OK, suppose one node incorporates a...<\/small><\/li>\n
- Re: Bitcoin P2P e-cash paper <\/a> James A. Donald wrote: > So what happened to the...<\/small><\/li>\n
- Re: Bitcoin P2P e-cash paper <\/a> I’ll try and hurry up and release the sourcecode as...<\/small><\/li>\n
- Bitcoin P2P e-cash paper <\/a> I’ve been working on a new electronic cash system that’s...<\/small><\/li>\n<\/ol>\n<\/div>\n", "date": "2008-11-09 11:14:36" }, { "id": 59, "url": "http:\/\/satoshinakamoto.me\/2008\/11\/09\/re-bitcoin-p2p-e-cash-paper-6\/", "title": "Re: Bitcoin P2P e-cash paper", "content": "
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?<\/p><\/blockquote>\nThey both broadcast their blocks. All nodes receive them and keep both, but
\nonly work on the one they received first. We’ll suppose exactly half received
\none first, half the other.<\/p>\nIn a short time, all the transactions will finish propagating so that everyone
\nhas the full set. The nodes working on each side will be trying to add the
\ntransactions that are missing from their side. When the next proof-of-work is
\nfound, whichever previous block that node was working on, that branch becomes
\nlonger and the tie is broken. Whichever side it is, the new block will contain
\nthe other half of the transactions, so in either case, the branch will contain
\nall transactions. Even in the unlikely event that a split happened twice in a
\nrow, both sides of the second split would contain the full set of transactions
\nanyway.<\/p>\nIt’s not a problem if transactions have to wait one or a few extra cycles to
\nget into a block.<\/p>\nSatoshi Nakamoto<\/p>\n
\nRelated posts:<\/h3>
\n
- Re: Bitcoin P2P e-cash paper <\/a> James A. Donald wrote: > The core concept is that...<\/small><\/li>\n
- Re: Bitcoin P2P e-cash paper <\/a> James A. Donald wrote: > > Fortunately, it’s only necessary...<\/small><\/li>\n
- Re: Bitcoin P2P e-cash paper <\/a> Hal Finney wrote: > it is mentioned that if a...<\/small><\/li>\n
- Re: Bitcoin P2P e-cash paper <\/a> Hal Finney wrote: > I think it is necessary that...<\/small><\/li>\n
- Re: Bitcoin P2P e-cash paper <\/a> James A. Donald wrote: > Furthermore, it cannot be made...<\/small><\/li>\n
- Bitcoin P2P e-cash paper <\/a> I’ve been working on a new electronic cash system that’s...<\/small><\/li>\n<\/ol>\n<\/div>\n", "date": "2008-11-09 11:17:39" }, { "id": 63, "url": "http:\/\/satoshinakamoto.me\/2008\/11\/10\/re-bitcoin-p2p-e-cash-paper-8\/", "title": "Re: Bitcoin P2P e-cash paper", "content": "
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.<\/p><\/blockquote>\nIf you’re having trouble with the inflation issue, it’s easy to tweak it for
\ntransaction fees instead. It’s as simple as this: let the output value from
\nany transaction be 1 cent less than the input value. Either the client
\nsoftware automatically writes transactions for 1 cent more than the intended
\npayment value, or it could come out of the payee’s side. The incentive value
\nwhen a node finds a proof-of-work for a block could be the total of the fees in
\nthe block.<\/p>\nSatoshi Nakamoto<\/p>\n
\nRelated posts:<\/h3>
\n
- Re: Bitcoin P2P e-cash paper <\/a> James A. Donald wrote: >OK, suppose one node incorporates a...<\/small><\/li>\n
- Re: Bitcoin P2P e-cash paper <\/a> Ray Dillinger: > the “currency” is inflationary at about 35%...<\/small><\/li>\n
- Re: Bitcoin P2P e-cash paper <\/a> James A. Donald wrote: > The core concept is that...<\/small><\/li>\n
- Re: Bitcoin P2P e-cash paper <\/a> I’ll try and hurry up and release the sourcecode as...<\/small><\/li>\n
- Bitcoin P2P e-cash paper <\/a> I’ve been working on a new electronic cash system that’s...<\/small><\/li>\n
- Re: Bitcoin P2P e-cash paper <\/a> James A. Donald wrote: > So what happened to the...<\/small><\/li>\n<\/ol>\n<\/div>\n", "date": "2008-11-10 11:09:51" }, { "id": 65, "url": "http:\/\/satoshinakamoto.me\/2008\/11\/11\/re-bitcoin-p2p-e-cash-paper-9\/", "title": "Re: Bitcoin P2P e-cash paper", "content": "
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.<\/p><\/blockquote>\nWhen there are multiple double-spent versions of the same transaction, one and
\nonly one will become valid.<\/p>\nThe receiver of a payment must wait an hour or so before believing that it’s
\nvalid. The network will resolve any possible double-spend races by then.<\/p>\nThe guy who received the double-spend that became invalid never thought he had
\nit in the first place. His software would have shown the transaction go from
\n“unconfirmed” to “invalid”. If necessary, the UI can be made to hide
\ntransactions until they’re sufficiently deep in the block chain.<\/p>\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<\/p><\/blockquote>\nSorry if I didn’t make that clear. The target time between blocks will
\nprobably be 10 minutes.<\/p>\nEvery block includes its creation time. If the time is off by more than 36
\nhours, other nodes won’t work on it. If the timespan over the last 6*24*30
\nblocks is less than 15 days, blocks are being generated too fast and the
\nproof-of-work difficulty doubles. Everyone does the same calculation with the
\nsame chain data, so they all get the same result at the same link in the chain.<\/p>\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.<\/p><\/blockquote>\nInstantant non-repudiability is not a feature, but it’s still much faster than
\nexisting systems. Paper cheques can bounce up to a week or two later. Credit
\ncard transactions can be contested up to 60 to 180 days later. Bitcoin
\ntransactions can be sufficiently irreversible in an hour or two.<\/p>\n> If one node is ignoring all spends that it does not
\n> care about, it suffers no adverse consequences.<\/p><\/blockquote>\nWith the transaction fee based incentive system I recently posted, nodes would
\nhave an incentive to include all the paying transactions they receive.<\/p>\nSatoshi Nakamoto<\/p>\n
\nRelated posts:<\/h3>
\n
- Re: Bitcoin P2P e-cash paper <\/a> Hal Finney wrote: > it is mentioned that if a...<\/small><\/li>\n
- Re: Bitcoin P2P e-cash paper <\/a> I’ll try and hurry up and release the sourcecode as...<\/small><\/li>\n
- Re: Bitcoin P2P e-cash paper <\/a> Ray Dillinger wrote: > One way to do this would...<\/small><\/li>\n
- Re: Bitcoin P2P e-cash paper <\/a> James A. Donald wrote: > The core concept is that...<\/small><\/li>\n
- Bitcoin P2P e-cash paper <\/a> I’ve been working on a new electronic cash system that’s...<\/small><\/li>\n
- Re: Bitcoin P2P e-cash paper <\/a> >Satoshi Nakamoto wrote: >> I’ve been working on a new...<\/small><\/li>\n<\/ol>\n<\/div>\n", "date": "2008-11-11 06:30:28" }, { "id": 67, "url": "http:\/\/satoshinakamoto.me\/2008\/11\/13\/re-bitcoin-p2p-e-cash-paper-10\/", "title": "Re: Bitcoin P2P e-cash paper", "content": "
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.<\/p><\/blockquote>\nThe proof-of-work chain is a solution to the Byzantine Generals’ Problem. I’ll
\ntry to rephrase it in that context.<\/p>\nA number of Byzantine Generals each have a computer and want to attack the
\nKing’s wi-fi by brute forcing the password, which they’ve learned is a certain
\nnumber of characters in length. Once they stimulate the network to generate a
\npacket, they must crack the password within a limited time to break in and
\nerase the logs, otherwise they will be discovered and get in trouble. They
\nonly have enough CPU power to crack it fast enough if a majority of them attack
\nat the same time.<\/p>\nThey don’t particularly care when the attack will be, just that they all agree.
\nIt has been decided that anyone who feels like it will announce a time, and
\nwhatever time is heard first will be the official attack time. The problem is
\nthat the network is not instantaneous, and if two generals announce different
\nattack times at close to the same time, some may hear one first and others hear
\nthe other first.<\/p>\nThey use a proof-of-work chain to solve the problem. Once each general
\nreceives whatever attack time he hears first, he sets his computer to solve an
\nextremely difficult proof-of-work problem that includes the attack time in its
\nhash. The proof-of-work is so difficult, it’s expected to take 10 minutes of
\nthem all working at once before one of them finds a solution. Once one of the
\ngenerals finds a proof-of-work, he broadcasts it to the network, and everyone
\nchanges their current proof-of-work computation to include that proof-of-work
\nin the hash they’re working on. If anyone was working on a different attack
\ntime, they switch to this one, because its proof-of-work chain is now longer.<\/p>\nAfter two hours, one attack time should be hashed by a chain of 12
\nproofs-of-work. Every general, just by verifying the difficulty of the
\nproof-of-work chain, can estimate how much parallel CPU power per hour was
\nexpended on it and see that it must have required the majority of the computers
\nto produce that much proof-of-work in the allotted time. They had to all have
\nseen it because the proof-of-work is proof that they worked on it. If the CPU
\npower exhibited by the proof-of-work chain is sufficient to crack the password,
\nthey can safely attack at the agreed time.<\/p>\nThe proof-of-work chain is how all the synchronisation, distributed database
\nand global view problems you’ve asked about are solved.<\/p>\n\nRelated posts:<\/h3>
\n
- Re: Bitcoin P2P e-cash paper <\/a> James A. Donald wrote: > The core concept is that...<\/small><\/li>\n
- Bitcoin P2P e-cash paper <\/a> I’ve been working on a new electronic cash system that’s...<\/small><\/li>\n
- Re: Bitcoin P2P e-cash paper <\/a> Hal Finney wrote: > it is mentioned that if a...<\/small><\/li>\n
- Re: Bitcoin P2P e-cash paper <\/a> I’ll try and hurry up and release the sourcecode as...<\/small><\/li>\n
- Re: Bitcoin P2P e-cash paper <\/a> James A. Donald wrote: >OK, suppose one node incorporates a...<\/small><\/li>\n
- Re: Bitcoin P2P e-cash paper <\/a> James A. Donald wrote: > Furthermore, it cannot be made...<\/small><\/li>\n<\/ol>\n<\/div>\n", "date": "2008-11-13 19:34:05" }, { "id": 69, "url": "http:\/\/satoshinakamoto.me\/2008\/11\/14\/re-bitcoin-p2p-e-cash-paper-11\/", "title": "Re: Bitcoin P2P e-cash paper", "content": "
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?<\/p><\/blockquote>\nFortunately, it’s only necessary to keep a pending-transaction pool for the
\ncurrent best branch. When a new block arrives for the best branch,
\nConnectBlock removes the block’s transactions from the pending-tx pool. If a
\ndifferent branch becomes longer, it calls DisconnectBlock on the main branch
\ndown to the fork, returning the block transactions to the pending-tx pool, and
\ncalls ConnectBlock on the new branch, sopping back up any transactions that
\nwere in both branches. It’s expected that reorgs like this would be rare and
\nshallow.<\/p>\nWith this optimisation, candidate branches are not really any burden. They
\njust sit on the disk and don’t require attention unless they ever become the
\nmain chain.<\/p>\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?<\/p><\/blockquote>\nBroadcasts will probably be almost completely reliable. TCP transmissions are
\nrarely ever dropped these days, and the broadcast protocol has a retry
\nmechanism to get the data from other nodes after a while. If broadcasts turn
\nout to be slower in practice than expected, the target time between blocks may
\nhave to be increased to avoid wasting resources. We want blocks to usually
\npropagate in much less time than it takes to generate them, otherwise nodes
\nwould spend too much time working on obsolete blocks.<\/p>\nI’m planning to run an automated test with computers randomly sending payments
\nto each other and randomly dropping packets.<\/p>\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.<\/p><\/blockquote>\nIt’s very attractive to the libertarian viewpoint if we can explain it
\nproperly. I’m better with code than with words though.<\/p>\nSatoshi Nakamoto<\/p>\n
\nRelated posts:<\/h3>