OP_MOXIE #6677

Implement an opcode that executes a Moxie architecture simulator over data + pre-compiled input.

Ref: http://moxielogic.org/blog/pages/architecture.html Ref: https://github.com/jgarzik/moxiebox

@jgarzik was there any context to this? Was this simply an idea you wanted to explore?

Could be an interesting experiment; what are example applications of this feature?

2015-09-16 8:51 GMT+02:00 Daniel Cousens notifications@github.com:

@jgarzik https://github.com/jgarzik was there any context to this? Was this simply an idea you wanted to explore?

— Reply to this email directly or view it on GitHub #6677 (comment).

@dcousens It was discussed at the conference. This allows any operation, any script, target-able with existing compiler toolchains.

I think I have some useful experience here. It's not an argument against, though.

Currently, if you want to add new script templates (not just the standardness, but also ability to sign, integration in RPCs, means of passing around partial signatures), there is a lot of work to do. I recently went through this exercise for Key Tree Signatures in Alpha (easily added to Bitcoin, but needs Schnorr and Merkle branch verification in Script first), and some people feel that this burden is the largest reason why more interesting Scripts aren't being used.

Moxie does not solve this. It adds a mechanism that in theory can trivially do anything (compiler targetable!), but in practice, writing signing code for it is going to be an order of magnitude harder even.

Some other references: http://gnusha.org/bitcoin-wizards/2015-01-01.log http://gnusha.org/bitcoin-wizards/2015-04-12.log http://gnusha.org/bitcoin-wizards/2015-09-02.log http://diyhpl.us/wiki/transcripts/bitcoin-sidechains-unchained-epicenter-adam3us-gmaxwell/

Some "hello worlds" for moxie oracles: http://gnusha.org/bitcoin-wizards/2014-06-22.log

Some general explanations of moxie: http://gnusha.org/bitcoin-wizards/2014-06-24.log

Anyway, I like the idea of getting a VM that is purpose-built for deterministic code execution. We could also just use vnTinyRAM while we're at it, for various SNARKs reasons. I would also like to get LLVM-IR-to-moxie at some point...

And from http://gnusha.org/bitcoin-wizards/2014-08-05.log

17:34 < jgarzik> Random flight of fancy before disappearing for kid bedtime: Put a moxie sandbox in every bitcoind, and if NODE_MOXIEBOX (etc.) is advertised, you may connect to that node, offer some bitcoin, and receive execution in return 17:35 < jgarzik> right 17:35 < jgarzik> bbiaw 17:36 < gmaxwell> jgarzik: Yeaâ<80><94> would be nice. Best I can suggest for greater oracle integrity in the near term is remote attest. In general secrecy makes it hard. Oracles implemented as multiparty computation give you what you want, but thats not terribly realistic right now. 17:37 < gmaxwell> (if you go down the rabbit hole of reading about multiparty computation, be aware that the lit is full of stuff under not-very-useful security models, like "semi-honest" or "passive" security where it's assumed that the participants may try to passively snoop but won't violate the protocol.)

etc:

14:41 < adam3us> Taek: i agree. moxie bytecode vm is a cool idea. for that and some other things also. 14:42 < adam3us> Taek: (other things in bitcoin) eg it can enforce deterministic execution of extensions that are coded in its bytecode.

etc http://gnusha.org/bitcoin-wizards/2015-01-09.log

19:20 @gmaxwell kanzure: the bytecode of the consensus rules. I've previously proposed we should be moving all the consensus rules into a bytecode with a very simple interpeter. 19:20 @gmaxwell This is part of where the interest in moxie comes from. 19:21 < kanzure> but what about things like highest block picking rules 19:21 < kanzure> surely that is important enough to go into the hash thing? 19:21 @gmaxwell that could be inside it as well. 19:21 @andytoshi i was thinking to vanity-grind some moxie no-ops, but actually changing the rules is a neat idea 19:22 < kanzure> i'm also not sure what to do about updates and bugfixes. you could grind some more until you hit on some bogus rules or no-ops that allow you to get "BITCOIN" but then what... just because it says "BITCOIN" does not mean this variant is bitcoin compatible or a good idea at all :) 19:24 < kanzure> i guess the ultimate dream is some proof of bitcoin compatibility, and then any statement that can be proven is (by definition of the proof system) definitely bitcoin-compatible? 19:24 < kanzure> and then you grind on those statements 19:24 @gmaxwell obviously one must define the hash function such that the first version says bitcoin trivially, and future versions can only be hashed by asking the prior version to hash them, and the prior version only lets them hash to bitcoin if you burned a lot of bitcoin to create then new version. 19:24 < kanzure> hah proof of burn. okay. 19:27 @gmaxwell e.g. it's a certitifcate chain where each version authenticates its successor.

Thanks for the references @kanzure.

@dakk

what are example applications of this feature

Everything. Literally -- you could (subject to push limits) compile libconsensus to moxie and have a blockchain in your blockchain. If the full transaction data were made available then there would be no limit to what could be done.

But I agree with @sipa: as a proposed addition to bitcoin core, there are serious deficiencies in this approach with respect to user experience. It would be a regression in base capability for wallets / signers. But it would motivate work on a better, more general and expressive scripting capability.

Also there are various formal verification benefits.

Actually my opinion is the opposite, that the disadvantage of OP_MOXIE is that signers are unable to do formal verification of the scripts before signing. Or at least, formal verification is just as difficult as other architectures like x86 or ARM.

A possibly better approach is a strongly typed stack language, or other architecture where formal verification isn't as onerous a task. But I think there is value to doing a moxiescript proposal to illuminate these issues.

However perhaps you were thinking of some other way in which there are formal verification benefits? I know there is another proposal to have the consensus rules of bitcoin compiled to moxie and use formal verification to prove the moxie interpreter. I believe that will be a fruitful avenue for research as well.

As this proposal affects bitcoin as a system and not just bitcoin core's implementation, discussion belongs on the mailing list (and BIPs etc), not here.