Bitcoin Forum
March 01, 2017, 06:14:24 PM *
News: Latest stable version of Bitcoin Core: 0.13.2  [Torrent]. (New!)
 
   Home   Help Search Donate Login Register  
Pages: [1]
  Print  
Author Topic: letstalkbitcoin on committed tx, homomorphic value, fungibility, privacy  (Read 3772 times)
adam3us
Sr. Member
****
expert
Offline Offline

Activity: 400


in bitcoin we trust


View Profile WWW
January 23, 2014, 09:22:15 AM
 #1

A podcast from letstalkbitcoin where I am talking with Andreas Antonopulous: maybe a better summary of the committed tx & homomorphic value, the threads here were full of crypto-math and perhaps hard to decipher, also fungibility/red-list & tx-cost and how that relates to indentity and privacy; also hashcash, decentralization, coinjoin/payment protocol, zerocoin/zerocash, some history.  1h45 of "light" listening Smiley

http://letstalkbitcoin.com/e77-the-adam-back-interview/

Some bitcoin talk links to the topics discussed:

Committed transactions (that really needs a summary top post, too much design evolution through it):
Quote
homomorphic values:
Quote

fungibility, identity & privacy
Quote

hashcash

Quote

coinjoin
Quote

zerocoin
Quote

Mentioned some 1998/1999 cypherpunks posts by Wei Dai, Hal Finney & anonymous (Satoshi or not unclear).  The links are at the bottom of this:
Quote
Enjoy Smiley

Adam

hashcash, committed transactions, homomorphic values, blind kdf; researching decentralization, scalability and fungibility/anonymity
1488392064
Hero Member
*
Offline Offline

Posts: 1488392064

View Profile Personal Message (Offline)

Ignore
1488392064
Reply with quote  #2

1488392064
Report to moderator
1488392064
Hero Member
*
Offline Offline

Posts: 1488392064

View Profile Personal Message (Offline)

Ignore
1488392064
Reply with quote  #2

1488392064
Report to moderator
1488392064
Hero Member
*
Offline Offline

Posts: 1488392064

View Profile Personal Message (Offline)

Ignore
1488392064
Reply with quote  #2

1488392064
Report to moderator
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertise here.
d'aniel
Sr. Member
****
Offline Offline

Activity: 461


View Profile
January 23, 2014, 10:29:19 AM
 #2

Thanks, I really enjoyed the talk!

I'm wondering what the devs thought of the beta chain idea?  Any objections beyond aesthetics?  (Of course there's the required hard fork, but these are going to have to happen in the future anyway.)
adam3us
Sr. Member
****
expert
Offline Offline

Activity: 400


in bitcoin we trust


View Profile WWW
January 23, 2014, 12:04:55 PM
 #3

Thanks, I really enjoyed the talk!

I'm wondering what the devs thought of the beta chain idea?  Any objections beyond aesthetics?  (Of course there's the required hard fork, but these are going to have to happen in the future anyway.)
Forgot to link that topic.  You can see the comments yourself below threads (positive).  1-way peg doesnt need any bitcoin main protocol changes we could do it now.

A new even better but bitcoin-main change-requiring variant figured out since.  And someone who can comment if they wish said on #bitcoin-wizards IRC (about the hard fork of this variant) that a) maybe it can be done without a hard fork, and b) anyway its the "one change to rule them all".  Ie after you've done it, other changes can happen on a pegged merge-mined side chain with no bitcoin main security risk.

Bitcoin-dev threads see comments for yourself (thread comments are at visible at the bottom of the pages):

Quote

Dont think there is a forum thread on the specific subject of the long list of EdDSA (EC Schnorr) security/flexibility/compactness advantages, though Greg Maxwell has been exploring it for those and performance reasons.  There were some open questions for Dan Bernstein which he hasnt replied to yet.

Quote
short mention of Ed25519 by Greg Maxwell:

https://bitcointalk.org/index.php?topic=151120.0

short aside mention in committed tx

https://bitcointalk.org/index.php?topic=206303.20

Quote
One problem is DSA sigs needlessly complicated Schnorr's base protocol, NIST/NSA did it to avoid paying Schnorr for his patent.  In most ways Schnorr signatures are superior and more flexible than DSA, eg it is easy to make threshold and split key where that gets quite complicated with DSA.  (The Schnorr patent expired in 2008.)

another aside in homomorphic value thread:

https://bitcointalk.org/index.php?topic=305791.msg3298692#msg3298692

Quote
Generically n of n multisig (with one owner or a single owner with pre-split private key) is compact with schnorr.  Shnorr is a better sig than DSA, NSA reduced its flexibility when they tweaked it to avoid Prof Schnorr's patent.

Schnorr also supports efficient threshold signatures (k of n multisig) so you can also do k of n multisig in the space of one signature on the validation side.


and as I said EC Schnorr (EdDSA) also supports blind signatures, which are not so far known to be possible with ECDSA.  CoinJoin uses blind signatures based on RSA I think, so it'd be nicer, faster, more compact, to use the native EC Schnorr blind sig.

EC Schnorr also makes possible wallet with observer (Stefan Brands concept) which allows a hardware wallet to be made subliminal channel free (wallet prevents offline double spend up to tamper resistance but cant mark coins nor leak private key).  But I spoke about a more advanced wallet observer, what I described (on the podcast) is actually a use of Brands issuing protocol to extend wallet observer so the wallet can sign a transaction and has a ZKP that the subliminal channel free signature it is making is bound to the message it can then display on the bigger hw wallet screen.

Subliminal channel free means the wallet has no way to leak the private key even if it is malicious (short of having a radio emitter inside it)

Adam

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

Activity: 5


View Profile WWW
January 26, 2014, 01:07:35 AM
 #4

What an enthralling discussion! I took notes as I listened. Andreas asking questions? You know its got to be informative.
Would love to see the content of this show written up as an article (not a transcript), with references. The information was tightly packed, and that's saying something for a longer show.

Most fascinating idea I picked out was the Bitcoin-Dev idea, whereby new features could be tested on a prototype track and bitcoin could be moved into it. Has any work been done on it since October? Loved the thought that all mindshare should be focused on Bitcoin.

Next most interesting: scripts disabled in Bitcoin.  And of course, fungibility needs anonymity.

So regarding scripts and Bitcoin-Dev, what is the current thinking regarding re-implementing all of the scripts in Bitcoin?
Is anyone considering it? If so, how would it be similar or different from what they are proposing in Ethereum?
d'aniel
Sr. Member
****
Offline Offline

Activity: 461


View Profile
January 26, 2014, 01:43:26 AM
 #5

So regarding scripts and Bitcoin-Dev, what is the current thinking regarding re-implementing all of the scripts in Bitcoin?
Is anyone considering it? If so, how would it be similar or different from what they are proposing in Ethereum?
I worry about too much misplaced hype coming from Ethereum, leading to the problem Adam mentioned, so it'd be nice to take the wind out of their sails with a script 2.0.  Adam said in the interview that Mark Friedenbach (maaku) was working on a good implementation.  I doubt it'll be Turing-complete, like Ethereum's, as that's likely overkill/window dressing.
Peter R
Legendary
*
Offline Offline

Activity: 966



View Profile
January 26, 2014, 07:52:07 AM
 #6

I doubt it'll be Turing-complete, like Ethereum's, as that's likely overkill/window dressing.

I'm drinking wine and haven't looked into Ethereum at all, so please excuse me if I'm being ignorant, but even NAND gates and Rule #110 Wolfram Cellular Automaton are Turing complete, no?  The complexity required for universal computation is surprisingly low. 

Run Bitcoin Unlimited (www.bitcoinunlimited.info)
d'aniel
Sr. Member
****
Offline Offline

Activity: 461


View Profile
January 26, 2014, 07:56:45 AM
 #7

I doubt it'll be Turing-complete, like Ethereum's, as that's likely overkill/window dressing.

I'm drinking wine and haven't looked into Ethereum at all, so please excuse me if I'm being ignorant, but even NAND gates and Rule #110 Wolfram Cellular Automaton are Turing complete, no?  The complexity required for universal computation is surprisingly low. 
Here's a recent discussion on this: https://bitcointalk.org/index.php?topic=431513.0
Peter R
Legendary
*
Offline Offline

Activity: 966



View Profile
January 26, 2014, 08:10:46 AM
 #8

I doubt it'll be Turing-complete, like Ethereum's, as that's likely overkill/window dressing.

I'm drinking wine and haven't looked into Ethereum at all, so please excuse me if I'm being ignorant, but even NAND gates and Rule #110 Wolfram Cellular Automaton are Turing complete, no?  The complexity required for universal computation is surprisingly low.  
Here's a recent discussion on this: https://bitcointalk.org/index.php?topic=431513.0

Thanks d'aniel.  My initial feeling is that Turing-completeness is not necessary for bitcoin and would very likely lead to unforeseen problems and instability (mostly related to the halting problem).  Money isn't a computer.

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

Activity: 400


in bitcoin we trust


View Profile WWW
January 26, 2014, 01:37:28 PM
 #9

Thanks d'aniel.  My initial feeling is that Turing-completeness is not necessary for bitcoin and would very likely lead to unforeseen problems and instability (mostly related to the halting problem).  Money isn't a computer.

I moved this question about risks with turing complete scripting to this thread on turing complete / ethereum and added some comments.

https://bitcointalk.org/index.php?topic=431513.new#new

Adam

hashcash, committed transactions, homomorphic values, blind kdf; researching decentralization, scalability and fungibility/anonymity
datafish
Donator
Full Member
*
Offline Offline

Activity: 125


Swimming in a sea of data


View Profile
February 03, 2014, 02:17:13 AM
 #10

Listening to Adam's interview was one of the best hour and forty-five minutes I've spent in a long time.  Adam has a lot of really great ideas for the bitcoin community, and we'd do well to take him seriously.  These are the ideas which I think are the most important:

1. Preservation of fungibility through enhanced privacy.
2. Releasing major changes to the protocol as a parallel implementation that allows migration of coins from the old to the new.
3. Focusing on the improvement of bitcoin rather than wasting time and resources on alt coins (with point 2 considered when major improvements require a hard fork).

Adam, I sent you a nice tip, but it's orders of magnitude below the value you've added to the community.  It's unfortunate that you haven't profited more from cryptocurrencies given your contributions over the years.

maaku
Legendary
*
expert
Offline Offline

Activity: 905


View Profile
February 03, 2014, 10:30:33 AM
 #11

@d'aniel Turing completeness has a very specific academic definition that the language I am co-designing probably won't meet[1], but that distinction is not interesting or important. In a Turing-complete language you can write an infinite loop, but why would you ever need to do that in practice? There are more limited forms of recursion and required type safety which allow expression of solutions to nearly all real world problems, or the emulation of space- or time-constrained variants of Turing-complete solutions.

I don't consider this overkill or window dressing at all. There are some very serious applications (e.g. restricted buy back) which require these features if they are to be emulated in Script; I wouldn't be working on this otherwise. We should probably move this to the thread linked to by Adam, however.

[1] I haven't seen this proven yet, but it looks like we'll probably have to choose between decidability and Turing-completeness in the type system, and for this application decidability is far more important as I foresee wallets using theorem proving to determine script safety and to categorize / quarantine coins by their attached covenants. For similar reasons, it may make sense to restrict ourselves to a total functional programming language (which restricts the range of expressible programs to those which are provably terminating, and therefore not Turing-complete in the strict sense, but nevertheless sufficiently expressive just about any actual use).

I'm an independent developer working on bitcoin-core, making my living off community donations.
If you like my work, please consider donating yourself: 13snZ4ZyCzaL7358SmgvHGC9AxskqumNxP
Pages: [1]
  Print  
 
Jump to:  

Sponsored by , a Bitcoin-accepting VPN.
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!