Quote from: adam3us on March 18, 2014, 03:12:37 AM

Quote from: AnonyMint on March 11, 2014, 10:22:59 AM

Thanks Meni for sharing that.

On the historical technical level (not applicable to be implemented in Bitcoin), Adam Back did not mention the double-spending solution where the person who double-spends would expose their identity.

Hal Finney summarized it.

The offline double-spend of Chaum reveals identity. Brands also has a mechanism to do that (reveal private key and all attributes, one of which could be identity).

Other than these advanced ecash protocols, the one-show signature idea is quite simple and somewhat general (eg can be applied to an ECDSA signature) and can reveal the private key if the user double spends. That would be an alternative mechanism to deter double spending (rather than one coin coming first as voted by miners), you can go ahead and double spend, and the miner will take your coin (because anyone can compute your private key if you double spend, they can create a third spend where the miner pays himself, and mine that.

All you have to do is with ECDSA there is Q the public key and r,s the signature; to leak the private key on double spend if you define the public key as Q,r and the signature as s, the signer is forced to reuse k (as R=kG, r=R.x) and if you reuse k with different messages you reveal a simultaneous equation allowing the private key to be computed.

s=k^-1(h(m)+rd)
s2=k^-1(h(m2)+rd)

=> sk = h(m)+rd, s2k = h(m2)+rd => (s-s2)k = h(m)-h(m2), k=(h(m)-h(m2))/(s-s2).
then sk=h(m)+rd => d=(sk-h(m))/r

An address would then be addr=H(Q,r) signature would be Q,r,s and signature is not valid unless addr=?H(Q,r) and sR =? h(m)G+rQ

The main problem with doing that in bitcoin is if you accidentally send twice (because your client crashes) you lose money. And people keep reusing addresses. These extended addresses would "discourage" address reuse (which some would say is a good thing:)

But there is a concept of a limited-show signature where you can spend n times but not more, just define r1,r2, ... rn and you are allowed to use any of those; but if you use one twice your private key leaks.

For bitcoin also you could put the recipients r choice in the transaction (allowing Q to be reused, across different tx, but a single r to be used once for the tx). Unfortunately that inconvenient as the recipient must choose r.

Adam

This is brilliant! Is it just me or does this have huge implications?

And can it be implemented in Bitcoin script, if we define some new opcodes?