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
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 us
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 re
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 i
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
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
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 digital
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 t
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 compute
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 pe
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 processi
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 shar
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 behave
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:
> 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'
--
> 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
>>
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 bot
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
--
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 transacti
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:
> 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 tra
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
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 run
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 it
>[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
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.
>
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 rec
>> 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
> 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 doe
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 sc
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
