Bitcoin Forum
May 11, 2024, 01:58:03 PM *
News: Latest Bitcoin Core release: 27.0 [Torrent]
 
   Home   Help Search Login Register More  
Pages: [1]
  Print  
Author Topic: Fungibility, Privacy & Identity - Adam Back (February 2014)  (Read 3541 times)
Meni Rosenfeld (OP)
Donator
Legendary
*
Offline Offline

Activity: 2058
Merit: 1054



View Profile WWW
March 10, 2014, 05:30:21 PM
 #1

Adam Back, inventor of Hashcash, has recently honored us with a visit to Israel. During this time we invited him to give a special guest lecture, on the topic of "Fungibility, Privacy & Identity".

Video: http://www.youtube.com/watch?v=3dAdI3Gzodo&feature=youtu.be
Slides: https://bitcoil.co.il/files/fungibility2.pdf

More details about this event at http://www.meetup.com/bitcoin-il/events/163456552/.

1EofoZNBhWQ3kxfKnvWkhtMns4AivZArhr   |   Who am I?   |   bitcoin-otc WoT
Bitcoil - Exchange bitcoins for ILS (thread)   |   Israel Bitcoin community homepage (thread)
Analysis of Bitcoin Pooled Mining Reward Systems (thread, summary)  |   PureMining - Infinite-term, deterministic mining bond
1715435883
Hero Member
*
Offline Offline

Posts: 1715435883

View Profile Personal Message (Offline)

Ignore
1715435883
Reply with quote  #2

1715435883
Report to moderator
"Bitcoin: the cutting edge of begging technology." -- Giraffe.BTC
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction.
1715435883
Hero Member
*
Offline Offline

Posts: 1715435883

View Profile Personal Message (Offline)

Ignore
1715435883
Reply with quote  #2

1715435883
Report to moderator
AnonyMint
Hero Member
*****
Offline Offline

Activity: 518
Merit: 521


View Profile
March 11, 2014, 10:22:59 AM
Last edit: March 11, 2014, 03:28:27 PM by AnonyMint
 #2

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.

unheresy.com - Prodigiously Elucidating the Profoundly ObtuseTHIS FORUM ACCOUNT IS NO LONGER ACTIVE
adam3us
Sr. Member
****
Offline Offline

Activity: 404
Merit: 360


in bitcoin we trust


View Profile WWW
March 18, 2014, 03:12:37 AM
Last edit: March 18, 2014, 09:22:40 PM by adam3us
 #3

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

hashcash, committed transactions, homomorphic values, blind kdf; researching decentralization, scalability and fungibility/anonymity
runeks
Legendary
*
Offline Offline

Activity: 980
Merit: 1008



View Profile WWW
April 10, 2014, 08:18:49 PM
Last edit: April 10, 2014, 08:32:54 PM by runeks
 #4

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?
Peter R
Legendary
*
Offline Offline

Activity: 1162
Merit: 1007



View Profile
April 10, 2014, 08:25:59 PM
Last edit: April 10, 2014, 10:40:17 PM by Peter R
 #5

My mind is blown on the double-spend-exposing-private-key concept.  Nice work!

Run Bitcoin Unlimited (www.bitcoinunlimited.info)
waldox
Sr. Member
****
Offline Offline

Activity: 252
Merit: 250


View Profile WWW
April 10, 2014, 10:26:48 PM
 #6

good video

I cant get enough of these bitcoin vids!

▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄
   * Dental Hygiene Cleaning in Toronto & Mississauga accepts Bitcoin  * Downtown Toronto Real Estate Realtor Blog & News * Toronto House Evaluation * Toronto Dental Cleaning Hygiene Centre
▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀
Pages: [1]
  Print  
 
Jump to:  

Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!