You will activate the vows and you will like it ScrgruppEn

Shinobi’s Strawman is a weekly series where our technical editor Shinobi challenges the Bitcoin community, with the goal of sparking conversation around hot technical debates.

______________________________________________________________

It has been two years since the last Bitcoin upgrade, Taproot, was activated and went live on the network. Since then, there has been a proliferation of proposed changes for the next upgrade to the protocol, and they seem to be piling up faster than people can keep up with.

These proposals mostly fall into one category of change: charters. The primary purpose of the covenant is to fundamentally change how the script restricts Bitcoin spending. Currently, script in a UTXO can control or limit how a currently existing UTXO can be spent, and the goal of covenant design is to extend this restriction so that a script in a currently existing UTXO can restrict how future UTXOs that have not yet been created can spend. Spend.

I have it myself He expressed his concerns We have written in the past about the dangers of enabling covenants, but we have come to the conclusion (addressed here) that those initial concerns were greatly exaggerated. I still think there are negative consequences that could come from charters allowing too many restrictions on future UTXOs, but those concerns are mostly rooted in potential incentive changes, not the misuse of charters themselves to censor people.

Here’s the interesting thing: We definitely needed some form of convention for the direction of expansion we went in for it to really work in the long term. Systems like Lightning are all built on pre-signed transactions used to restrict spending terms for future UTXOs, but this can be very restrictive.

Changing the state of a Lightning channel with just two people is easy and only requires signing a few transactions. Balance changes, any HTLCs or new contracts, and a few transactions to deal with. However, the number of transactions you need to sign starts to increase the more complex the thing you are trying to do becomes. That is, involving more than two people in the channel. Think about punishments, now just one person punishes the other person, it’s very simple. The cheating party loses all of their money to the only party being cheated.

How does that work with three people in the channel? It’s no longer a matter of everything going to one person, him The right amount It should go to everyone else who gets cheated on. This integer amount changes each time the channel is updated. So every time a channel state changes, you have to sign (or somehow create) transactions that will penalize each old channel state while ensuring that the funds reach other participants correctly in accordance with the current state’s balances. You have to somehow make sure that only the most recent penalty can be used, otherwise older penalties made with different channel states will not distribute the money correctly after someone tries to cheat. Imagine having to sign all this growing set of transactions every time you update a channel, it’s not scalable at all (if you can even find a way to make it work logically in the first place). SIGHASH_ANYPREVOUT (APO) provides a solution to this problem by also allowing people to simply replace old states with the current state instead of penalizing people.

Similar problems occur when you think about trying to handle executing things on-chain. If you put 10 people on one channel, what happens when someone doesn’t respond? You should shut down everything off-chain and prevent everyone from continuing to update things off-chain. Proposals like OP_TAPLEAFUPDATEEVERIFY (TLUV) and OP_EVICT would provide a way for one user to exit the channel non-cooperatively without closing it for anyone else, or for all but one unresponsive person to efficiently take that offline group offline and keep the channel open for the duration of themselves.

Long chains of pre-signed transactions can commit individual payments, open channels, etc. ahead of time. However, to be trusted, this transaction chain must start from a multisig address where you are the key holder, otherwise everything committed can be double-spent and invalidated. This requires a long setup phase to create the multi-sig, as everyone has to be online to sign everything and then eventually fund it. OP_CHECKTEMPLATEVERIFY (CTV) allows this to be done trustlessly without having to engage in a long and complex setup phase.

Everywhere we look and find problems or points of friction in the operation of Lightning and other off-chain protocols, a few basic charter proposals can elegantly address the issues. There are a lot of them too:

• SIGHASH_ANYPREVOUT
• OP_CHECKTEMPLATEVERIFY
• OP_CHECKSIGFROMSTACK
• OP_TAPLEAF_UPDATE_VERIFY
• OP_EVICT
• OP_TXHASH
• OP_CAT
• OP_VAULT and OP_UNVAULT
• TX_HASH+CSFS
• Template key

I wouldn’t be shocked if I missed some too. Some of these proposals, derivatives, or new proposals that have not been thought of will be necessary to continue expanding Bitcoin’s scope. There is no way around this. We either accept the limitations of Bitcoin as it is now, or we improve it to address those limitations.

So, we’ll do the same thing we did with the last straw man. What are your thoughts on charters? Do you have specific suggestions that you think are the most interesting or useful? Do you have any ideas on what could be built, or what problems could be solved using it? Are there things you don’t understand about them? How does it work, what are its benefits, and what are the risks and drawbacks? Let’s listen to this.

Direct messages are open, and opportunity@bitcoinmagazine.com is available if that works best as a submission method. Next Wednesday we will do the same thing I did last time and I will post the responses with answers to any questions or thoughts on the responses.

The most trusted voice in bitcoin, Bitcoin Magazine provides news, analysis, information, commentary, and price data about Bitcoin blockchain tech