pull down to refresh

0 sats \ 1 reply \ @BitcoinHistory OP 14 Nov 2023 \ parent \ on: Bitcoin P2P e-cash paper | Satoshi Nakamoto satoshi at vistomail.com Fri Oct 31 bitcoin
Nicolas Williams https://www.metzdowd.com/pipermail/cryptography/2008-November/014864.html Nicolas.Williams at sun.com Mon Nov 17 16:54:28 EST 2008 Previous message: Bitcoin P2P e-cash paper Next message: Bitcoin P2P e-cash paper Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] 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 recourse. It's all prevention.
Okay, that's surprising. If you're not using buyer/seller identities, then you are not checking that a spend is being made by someone who actually is the owner of (on record as having recieved) the coin being spent.
How do identities help? It's supposed to be anonymous cash, right? And say you identify a double spender after the fact, then what? Perhaps you're looking at a disposable ID. Or perhaps you can't chase them down.
Double spend detection needs to be real-time or near real-time.
Nico
write
preview
0 sats \ 0 replies \ @BitcoinHistory OP 14 Nov 2023
James A. Donald https://www.metzdowd.com/pipermail/cryptography/2008-November/014866.html jamesd at echeque.com Mon Nov 17 20:26:31 EST 2008 Previous message: Bitcoin P2P e-cash paper Next message: ADMIN: end of bitcoin discussion for now Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] 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 looking at a disposable ID. Or perhaps you can't chase them down.
Double spend detection needs to be real-time or near real-time.
Near real time means we have to use UDP or equivalent, rather than TCP or equivalent, and we have to establish an approximate consensus, not necessarily the final consensus, not necessarily exact agreement, but close to it, in a reasonably small number of round trips.
reply