letstalkbitcoin on committed tx, homomorphic value, fungibility, privacy

[adam3us]

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

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):

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

homomorphic values:

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

fungibility, identity & privacy

fungibility, coinvalidation/red-list:

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

fungibility risk explained:

https://bitcointalk.org/index.php?topic=333882.msg3584447#msg3584447

fungibility transaction layer vs identity privacy payment layer:

https://bitcointalk.org/index.php?topic=333882.msg3585877#msg3585877

transaction layer vs payment layer:

https://bitcointalk.org/index.php?topic=333882.msg3586236#msg3586236

why society & businesses value payment privacy:

https://bitcointalk.org/index.php?topic=333882.msg3590223#msg3590223

hashcash

https://en.bitcoin.it/wiki/Hashcash

coinjoin

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

zerocoin

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

zerocoin crypto summary
https://bitcointalk.org/index.php?topic=175156.msg2296916#msg2296916

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

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

https://bitcointalk.org/index.php?topic=205533.msg2149044#msg2149044

Enjoy

Adam

[1713515445]

1713515445

[1713515445]

1713515445

[1713515445]

1713515445

[1713515445]

1713515445

[1713515445]

1713515445

[d'aniel]

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]

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):

Oct 2013 beta chain revisited (aka bitcoin-staging):

http://www.mail-archive.com/bitcoin-development@lists.sourceforge.net/msg02944.html

May 2013 original post.
http://www.mail-archive.com/bitcoin-development@lists.sourceforge.net/msg02212.html

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.

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

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

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

[MadMoneyMachine]

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]

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]

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. 

[d'aniel]

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]

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.

[adam3us]

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

[datafish]

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]

@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).