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
On Fri, Nov 14, 2008 at 11:04:21PM -0800, Ray Dillinger wrote:
On Sat, 2008-11-15 at 12:43 +0800, Satoshi Nakamoto wrote:
If someone double spends, then the transaction record
can be unblinded revealing the identity of the cheater.
Identities are not used, and there's no reliance on
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
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
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.
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
--
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
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
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
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
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
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
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
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
The main properties:
Double-spending is prevented with a peer-to-peer network.
No mint or other trusted parties.
Participants
32 matches
Mail list logo