I would like to see Smart Contracts on Bitcoin to have this feature:
A contract where people commit to depositing Bitcoins for a period of,
say, 10 years. If someone of the group withdraws before that time,
that person would pay a fine of for example of 10% of the amount they
deposited to the rest of the participants who continue to follow the
contract.
Acredito que a demanda ainda nรฃo รฉ grande o bastante pra que a comunidade bitcoiner desenvolva com mais esforรงo os Smartcontracts.
Inclusive, acho bem capaz de termos CBDCs como o DREX tendo Smart Contracts primeiro que o Bitcoin, mas รฉ sรณ uma hipรณtese.
Jรก tem muitos projetos que estรฃo em andamento para permitir isso usando rollups, sidechains. Em 2025 teremos com certeza isso de forma descentralizada.
Principais projetos:
3- https://www.botanixlabs.xyz/
Agora, nativamente no Bitcoin, acho que nunca irรก acontecer mesmo.
Lembrando que os projetos que mencionei usam o Bitcoin como token monetรกrio, para pagamento das taxas, nรฃo sรฃo blockchains com shitcoins prรณprias.
Estรฃo tentando fazer uma espรฉcie de Rede Liquid com Smart Contracts?
Estรฃo tentando fazer blockchains EVM, compatรญveis com os contratos da Ethereum, sรณ que sem o token ETH, e sim com BTC e de forma descentralizada.
Atualmente blockchain EVM que funciona com BTC como token monetรกrio, existe a rootstock.io mas ela nรฃo รฉ descentralizada e sim uma federaรงรฃo, assim como a Liquid. Talvez por esse motivo esses projetos nรฃo pegaram traรงรฃo, por nรฃo ser totalmente descentralizado.
A rootstock quer se tornar descentralizada com essa nova tecnologia chamada Bitvm. Mas por enquanto ainda รฉ uma federaรงรฃo.
O que seria essa Bitvm?
Poxa, vocรช nรฃo sabe? Uma das maiores inovaรงรตes de 2024, que irรก permitir ter pontes descentralizadas. Irรก permitir vocรช depositar Bitcoin em uma outra rede e quando vocรช quiser voltar para o Bitcoin, poderรก transferir de volta sem ser necessรกrio permissรฃo de ninguรฉm. Corrige os problemas das redes federadas.
Hรก um pouco de receio com essas redes federadas, apesar de serem boas, muitos usam a Rede Liquid por causa dessa compatibilidade, e funciona muito bem.
A beleza รฉ ter redes diferentes. A Liquid รฉ a mesma coisa que Bitcoin mas com algumas inovaรงรตes.
A beleza da Bitvm, rollups รฉ permitir criar blockchains mais inovadoras sem precisar de uma shitcoin. E sim usando Bitcoin.
nostr:npub1melv683fw6n2mvhl5h6dhqd8mqfv3wmxnz4qph83ua4dk4006ezsrt5c24 made smart contracts on bitcoin, ask him, maybe he can explain.
But by what i saw no one was interested.
Don't do this to me, man: I'm on holidays!
Ok, off the top of my head. Let's do a single UTXO, which you can spend. We represent all of the pubkey+balance pairs as a hash (separate output? In the script? I don't know).
Three ways to spend it:
1. New funds. Appends pubkey and the new input amount (maybe allow change output?). You have to provide all the previous pubkey+amount pairs, so this gets more expensive as size increases.
2. Early withdraw. You provide all the pubkeys and amounts, and a signature from your pubkey, and an offset of your pubkey. Your amount gets divided by 10, then divided by number of remaining participants (last one can't exit, too bad!) rounded up. Adding that to each participants amount is *hard*, because there is no iteration in Script. This means open iteration, so an upper limit on how many participants.
3. Final withdrawal. This is easier, simply spend with a single tx with outputs to each pubkey/amount.
So, you need introspection, ideally fully (OP_TX or multiple opcodes) to deal with amounts. You want Script restoration to sanely divide and handle whale amounts.
To do this *well* you want stack iteration, for which I am unaware of any proposal. varops could be amended to allow this in future, but it deliberately doesn't charge for some opcodes because we know there's a weight limit, and that will need to change if we have iteration.
But it's a cute idea!
That's possible to do if you have few participants. Just presign a bunch of transactions, or use CTV and whatnot.
But what else would that contract be able to do? Just keep the money still?
Because if you want people to be able to use the funds or move them in any way then it quickly becomes impossible. It's all the "payment pool" or "coinpools" idea again, a very flawed idea.
