Satoshi Nakamoto wrote: I've been working on a new electronic cash system that's fully peer-to-peer, with no trusted third party. The paper is available at: http://www.bitcoin.org/bitcoin.pdf We very, very much need such a system, but the way I understand your proposal, it does not seem to

Satoshi Nakamoto wrote: I've been working on a new electronic cash system that's fully peer-to-peer, with no trusted third party. The paper is available at: http://www.bitcoin.org/bitcoin.pdf We very, very much need such a system, but the way I understand your proposal, it does not seem to

As long as honest nodes control the most CPU power on the network, they can generate the longest chain and outpace any attackers. But they don't. Bad guys routinely control zombie farms of 100,000 machines or more. People I know who run a blacklist of spam sending zombies tell me they often

As long as honest nodes control the most CPU power on the network, they can generate the longest chain and outpace any attackers. But they don't. Bad guys routinely control zombie farms of 100,000 machines or more. People I know who run a blacklist of spam sending zombies tell me they often

James A. Donald: To detect and reject a double spending event in a timely manner, one must have most past transactions of the coins in the transaction, which, naively implemented, requires each peer to have most past transactions, or most past transactions that occurred recently. If

On Tue, 2008-11-04 at 06:20 +1000, James A. Donald wrote: If I understand Simplified Payment Verification correctly: New coin issuers need to store all coins and all recent coin transfers. There are many new coin issuers, as many as want to be issuers, but far more coin users.

[Lengthy exposition of vulnerability of a systm to use-of-force monopolies ellided.] You will not find a solution to political problems in cryptography. Yes, but we can win a major battle in the arms race and gain a new territory of freedom for several years. Governments are good at cutting

Bitcoin seems to be a very promising idea. I like the idea of basing security on the assumption that the CPU power of honest participants outweighs that of the attacker. It is a very modern notion that exploits the power of the long tail. When Wikipedia started I never thought it would work, but

Ray Dillinger: the currency is inflationary at about 35% as that's how much faster computers get annually ... the inflation rate of 35% is almost guaranteed by the technology Increasing hardware speed is handled: To compensate for increasing hardware speed and varying interest in running

Hal Finney wrote: it is mentioned that if a broadcast transaction does not reach all nodes, it is OK, as it will get into the block chain before long. How does this happen - what if the node that creates the next block (the first node to find the hashcash collision) did not hear about the

-- Satoshi Nakamoto wrote: The 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. A transaction will quickly propagate throughout the network, so if two versions of the same transaction

Satoshi Nakamoto wrote: Increasing 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

James A. Donald wrote: OK, suppose one node incorporates a bunch of transactions in its proof of work, all of them honest legitimate single spends and another node incorporates a different bunch of transactions in its proof of work, all of them equally honest legitimate single spends, and both

James A. Donald wrote: The core concept is that lots of entities keep complete and consistent information as to who owns which bitcoins. But maintaining consistency is tricky. It is not clear to me what happens when someone reports one transaction to one maintainer, and someone else

Satoshi Nakamoto wrote: The 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

-- James A. Donald wrote: OK, suppose one node incorporates a bunch of transactions in its proof of work, all of them honest legitimate single spends and another node incorporates a different bunch of transactions in its proof of work, all of them equally honest legitimate single

James A. Donald wrote: Furthermore, it cannot be made to work, as in the proposed system the work of tracking who owns what coins is paid for by seigniorage, which requires inflation. If you're having trouble with the inflation issue, it's easy to tweak it for transaction fees instead. It's

James A. Donald wrote: So what happened to the coin that lost the race? ... it is a bit harsh if the guy who came second is likely to lose his coin. When there are multiple double-spent versions of the same transaction, one and only one will become valid. The receiver of a payment must

Satoshi Nakamoto wrote: When there are multiple double-spent versions of the same transaction, one and only one will become valid. That is not the question I am asking. It is not trust that worries me, it is how it is possible to have a a globally shared view even if everyone is well

James A. Donald writes: Satoshi Nakamoto wrote: When there are multiple double-spent versions of the same transaction, one and only one will become valid. That is not the question I am asking. It is not trust that worries me, it is how it is possible to have a a globally shared view

James A. Donald wrote: It is not sufficient that everyone knows X. We also need everyone to know that everyone knows X, and that everyone knows that everyone knows that everyone knows X - which, as in the Byzantine Generals problem, is the classic hard problem of distributed data processing.

Hal Finney wrote: I think it is necessary that nodes keep a separate pending-transaction list associated with each candidate chain. ... One might also ask ... how many candidate chains must a given node keep track of at one time, on average? Fortunately, it's only necessary to keep a

Okay I'm going to summarize this protocol as I understand it. I'm filling in some operational details that aren't in the paper by supplementing what you wrote with what my own design sense tells me are critical missing bits or obvious methodologies for use. First, people spend computer

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. Ray Dillinger (Bear) wrote: When a coin is spent, the buyer and seller digitally sign a (blinded) transaction record. Only the buyer signs, and

On Sat, 2008-11-15 at 12:43 +0800, Satoshi Nakamoto wrote: 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. Ray Dillinger (Bear) wrote: When a coin is spent, the buyer and seller digitally

Ray Dillinger wrote: One way to do this would be to have the person recieving the coin generate an asymmetric key pair, and then have half of it published with the transaction. In order to spend the coin later, s/he must demonstrate posession of the other half of the asymmetric key pair,

Satoshi Nakamoto wrote: Fortunately, it's only necessary to keep a pending-transaction pool for the current best branch. This requires that we know, that is to say an honest well behaved peer whose communications and data storage is working well knows, what the current best branch is - but of

James A. Donald wrote: Fortunately, it's only necessary to keep a pending-transaction pool for the current best branch. This requires that we know, that is to say an honest well behaved peer whose communications and data storage is working well knows, what the current best branch is - I

Ray Dillinger wrote: Okay I'm going to summarize this protocol as I understand it. I'm filling in some operational details that aren't in the paper by supplementing what you wrote with what my own design sense tells me are critical missing bits or obvious methodologies for use. There

Nicolas Williams wrote: How do identities help? It's supposed to be anonymous cash, right? Actually no. It is however supposed to be pseudonymous, so dinging someone's reputation still does not help much. And say you identify a double spender after the fact, then what? Perhaps you're