I think the only way to do it is with a wrapped BTC coin.
No Bitcoiner cares about, wants or would even exchange their actual BTC for wrapped BTC to then interact with a smart contract.
The right way to do that is building on
RGB.
RGB is a scalable & confidential smart contracts system for Bitcoin & lightning network. They embrace concepts of private & mutual ownership, abstraction and separation of concerns and represent "post-blockchain", Turing-complete form of trustless distributed computing which does not require introduction of "tokens".
Here you have the implementation for backend and frontend:
https://github.com/RGB-WG/rgb-nodehttps://github.com/RGB-WG/rgb-sdkThere's a client for RGB protocol assets in
MyCitadel.
You will just need to port your contract to
Contractum language.
There is a very similar, second such project and to my knowledge, they're also somewhat working together (might be wrong?), called
Taro.
While I'm a critic of the Lightning Labs team myself, I just found out that their
latest blog post is about Taro and they have an alpha release out since September.
Many thanks for the links @n0nce! I've started learning RGB schema and Taro. From my initial install I see
1) It could be too expensive to execute this on chain
2) The functionality is really limited to just sub-assets on bitcoin (and let's be honest do we really need shit coins on Bitcoin)
3) Both seem far away from any kind of production-readiness (documentation is terrible, sample code is full of issues)
4) Both solutions appear quite hacky. I mean Bitcoin just isn't designed to do this in my opinion.
I would humbly propose it might be better to:
A) Hard fork the entire bitcoin chain and add proper support for a totally new programming paradigm (which, let's face it, is not going to happen)
B) Create a completely separate Bitcoin Bridge Layer blockchain-VM (perhaps WASAM based) that sits on top of Bitcoin and has very tight coupling so to perform ONLY very simple pre-existing Bitcoin opcodes (OP_(Math and bools) and within a maximum execution limit to ensure it is always cost free (let's say 21 operations to keep miners happy:). Perhaps this Bitcoin Bridge Layer could then support different VMs and tooling such as EVM or Substrate/Polkadot or whatever else is flavour of next month. Whether the Bridge Layer is true Turing complete or not, perhaps, then just become irrelevant as Bitcoin is and the bridge will discard anything that falls outside of 21. This would have the advantage of opening up Bitcoin to a whole new set of developers and pre-existing dev tools.
I will continue hacking about and see where I get to on it. Why are you a critic of Lightning Labs incidentally?
And then, you can have this N-of-N "everyone agrees" signature as a base for any Turing-complete contract you want.
Can you give us an example?
Well, N-of-N multisig means that "everyone agrees" on everything what happened on some second layer. Then, Bitcoin Script can be as complex as it is needed, because it can be splitted into many transactions. It is just a matter of cost. We have opcodes like OP_NOT, OP_TRUE, OP_FALSE and OP_EQUAL. There are also more complex opcodes, but it is possible to express any loops and other operations as a sequence of opcodes, repeated the maximum times it can execute (the more complex it will be, the more bytes it will take, for example "OP_2DUP OP_ADD OP_2DUP OP_ADD ..." will produce Fibonacci sequence). And then, you just need two things: one is the chain of Script operations, that will move all coins into fees, and another is the final transaction that takes the end of that chain (the last coins before being converted to fees), and the coins of all participants.
Then, all participants have a choice: execute everything off-chain, and reach agreement (the cheapest and the most private option), or execute everything on-chain (that is costly, it requires revealing parts that are signed upfront (to protect Script from being stopped or altered in the middle by some third party), and requires taking TapScript path, that pushes the whole chain of transactions, to execute for example "SHA-3(something)==hash".
So, yes, Bitcoin can be Turing-complete even today, but then you have to be ready for spending for example 100 BTC for executing some contract on-chain. Or you can try it on regtest or testnet3 to be convinced. But in general, it is better to reach off-chain agreement, or propose a soft-fork to add OP_SOMETHING, than to use that costly method to do it today.
Thanks for the input I think there is something here which could serve as the basis for the proposed, Bitcoin Bridge Layer VM, though the op code approach would still need to be inserted into into the Bitcoin core code for maximum security.
The smart contracts are currently deployed to 6 EVM chains (Ethereum, Moonbeam, Moonriver, Celo, Unique, Quartz) and I think it could potentially really add traction to the mass adoption of Bitcoin
Explain me how. What need does these smart contracts satisfy to help on achieving global adoption? None, as far as anyone can tell. Mass adoption is rather not happening due to responsibility issues, misinformation and not really big need for bitcoin.
Sorry to explain this a bit more, the smart contracts / potential bitcoin port are used as the underlying for an iOS/Android social network of DAOs. This app has been designed for mass adoption (it has centralised bits in it so users don't have to understand blockchain tech and DAOs are called #Collectives for adoption. You can read more about the app etc here:
https://bitcointalk.org/index.php?topic=5431111.new Full disclosure I wrote the entire stack including the app, back-end and smart contracts so am probably a little biased
That's not Turing-completeness, though. Having to unroll loops and break things down to individual mathematical operations, means it's exactly not Turing-complete.
https://en.wikipedia.org/wiki/Turing_completenessBitcoin script just doesn't have (and never will have) recursion and no unbounded loops (which you sometimes need). Suggesting you can unroll any loop assumes the input of the program doesn't change the amount of iterations needed. It's highly probable that a smart contract needs to calculate something more or fewer times depending on the user input.
It's also simply completely unsuited for writing a smart contract like what we're talking about here. RGB is made for that; also in terms of programming language style and everything around it. It is nonsensical suggesting OP to port it to Bitcoin Script, just because in a thought experiment, it may be possible using 100BTC of transaction fee.
Agreed.
