I'm fine with it too but I'll do what I can to make sure Bitcoin is the best programmable money ever and for that we need more op codes pure and simple

Reply to this note

Please Login to reply.

Discussion

It's not so obvious we need to add more op codes on layer 1 in order to get what we need.

For example cryptographers are making progress in homomorphic encryption [1,2] that would open the door to tamper proof scripting.

We're not there yet, but I imagine a scenario where an arbitrary number of people could agree on spending conditions for a UTXO-set (with whatever rules they want), write and encrypt a script that generates its own hidden xpriv using their individual keys, and then now any member of the group could potentially execute the script. The script and its rules could remain private among the interested parties.

It could be capable of generating addresses and signing transactions. Depending on the script it could support unilateral exit based on an input signature. It could improve lightning and wouldn't need anything new on chain.

It's more important to be patient and only make changes that are provably necessary in my humble opinion.

1. https://en.wikipedia.org/wiki/Homomorphic_encryption

2. https://machinelearning.apple.com/research/homomorphic-encryption

you can build a building with Popsicle sticks but concrete is better

Can you elaborate why everything has to be done on layer 1? Do you think payment channels (ie. lightning networks) are not sound? What’s wrong with building in layers?

Sure. I am a fan of LNHANCE.

I think getting rid of headaches like justice transactions is very important for Lightning integrity. I like the idea of non interactive channels where offline nodes can have third parties open channels on a node's behalf. I like payment pools and channel factories. The ability to pre-sign a channel open that broadcasts directly out of a shared UTXO at a certain condition can be extremely powerful. And I also like Vaults to a lesser extent, but can see how it is useful.

Thanks for the thoughtful response. I also like some of those features and would love to see them implemented but I’m stuck on the idea of unintended consequences.

Bitcoin does everything I need it to at the moment and I don’t want it to devolve into something like ETH. That’s why I would prefer to exhaust all the other options first and prove out the use case on a higher layer than risk jeopardizing what we already have. I think we still have lots of room to build even if it would be easier with a fork.

I'd like to be clear that the four op codes proposed in LNHANCE includes no new address types and no interference with ANYTHING that is possible right now. It's not like segwit or taproot. It's such a small thing in comparison.