Topic: Bip 119 conventant script rules are reinforced on l1 or upper layers? (Read 163 times)

that is true, but I did say "same outcome", because of course G. Ment will never give consent for A. Citizen () to leave the cult scheme.

Of course, A. Citizen can use some form of persuasion/coercion to change G. Ments' mind in the 2 of 2 scheme, whereas no amount of persuasion can undo an infinitely recursive covenant.



it was a totally unbacked, unexplained statement of fact, so worth as much as the author's reputation IOW



Well, yes. It's only possible to cease trading after the fact, but it's still useful. Some people you trade with will always keep coins you trade with them away from such covenants, you can check for yourself. Preferentially trade with those that do so the longest, ideally those who you observe 'never' involve your (previous) coins in coercive covenants. And if a sufficient number of Bitcoiners stuck to this, it would be difficult for people to simultaneously maintain unencumbered outputs and outputs in coercive covenants. Then I guess we would check the rate at which the poison was spreading before we take any other route (not sure what, but probably carefully re-designed altcoin would be the most drastic option)

Coercive covenants should be more easily identified onchain compared to coercive multisigs, so in that respect they're better.

Not the exact same. The difference is that coins in a 2-of-2 multi-sig can, with agreement from both parties, leave the multi-sig arrangement and be sent back to a regular address and then be made to be indistinguishable from all other bitcoin in circulation. If G. Ment were to lock coins in a recursive covenant which always requires their input to spend all future outputs, then those coins can never leave such a set up, are now non-fungible, and are effectively no longer bitcoin.

I don't think such a case is possible though with OP_CTV, but I've ready quite a few conflicting opinions on the matter, hence my desire for links and more clarity. I'll have another look through the mailing list to see if I missed something.

1 is easy, 2 is impossible. It is simply not possible for me to know all the different trades you are doing and whether or not you have coins in any such covenants.

i'll look, can't remember who said it, but it was a recent bitcoin-dev post



yeah, the claim is not that "they can't happen", but instead that "OP_CTV does not enable" them

---

the boat sailed on the "infinite covenant" issue quite a while ago, to wit:

Imagine a dastardly bully (let's arbitrarily give him the name G. Ment) forces you to send your BTC to a 2 of 2, 1 key yours and the other his. He can force you to always construct transactions that pay the change in any transaction to an address with exactly the same multisig; 2 of 2, 1 key yours, 1 his.

That scheme achieves the exact same outcome that bothers some people about infinite covenants, so we've been living with such a possibility since multisig (i think it was BIP34) was introduced, way back in 2011. And I think that "bare" multisig was even possible since the earliest or even the very first version of Bitcoin.


The only thing covenants do to change the situation is to remove the key exchange: with the above scheme, we need to ask G. Ment for his address to compute the next multisig in the sequence. That negotiation is not in the Bitcoin protocol, so it would be a clunky setup. With covenants, restricting where you can spend money to would be enforced by the script, not the overall sig validation, and so the multisig is not even necessary. Bitcoin nodes would reject the transaction as invalid, same outcome.


But don't worry.

1. Don't enter into such schemes to begin with
2. Don't trade with people that do

To help with point 2, simply use the blockchain to trace if people you traded with go on to put the money you gave them into such covenants. To be extra tough, start doing this twice or even thrice removed ("you're trading with some other clown who burned perfectly good BTC in a coercive covenant! Begone!")

Here is video with appropriate timeline where Jimmy Song is explaining what op_ctv is. https://youtu.be/i5VNiiCYnIg?t=2173

There is also a wider discussion wrt to support and opposition to this new op_code. Summary is here https://www.youtube.com/watch?v=i5VNiiCYnIg&t=7208s
 

Do you have a link to these discussions?

The last time I read about recursive covenants on the mailing list was here: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-February/019885.html. The general outcome was not that they can't happen, but rather that there were no strong reasons against them (which I'm not sure I agree with, but I definitely don't know enough about the wider situation yet).

all Bitcoin script is executed in blocks, onchain. That would include OP_CTV (which only works on a private testnet, not the main bitcoin blockchain).

any second layer protocols are subject to the outcomes of script at the onchain level.


But you seem to have got this confused. Any scripting done using off-chain protocols must be the same as real (i.e. onchain) Bitcoin script. There cannot be scripting possibilities that do not execute onchain. So don't worry about changes to scripting somehow affecting different layers, Bitcoin script has exactly the same possible operations whether on or off chain.

The point is to change the details of the script for a transation while it's off-chain, then execute the script onchain if/when wanted. Or never go onchain, that's another option.

Not inherently but within the script there is that potential?
If CTV is invoked when the tx goes on chain this means miners reinforce this ctv rule and all other layers need to follow.

Does this pose a systemic risk for the Bitcoin system itself as a WHOLE (l1 and cascading to other layers)? Or does it ONLY extend programmability and functionality that can be utilized to extend secondary layer protocols and improve security?

119 does not inherently do anything you mentioned.

What it does do happens at the level of the Bitcoin tx script, AFAIK (there are descriptions of ideas that work using protocols that use Bitcoin tx script i.e. lightning, but it seems as if the only time CTV is invoked is when the open/close tx's go on-chain)

I don't think there is any _meaningful_ ability to do black/whitelisting, as we have been reliably informed by script gurus that infinite recursion is not possible with CTV. However, better that we verify this for ourselves, Bitcoiners shouldn't want or need gurus IMO

One part I am still confused about is how the new covenant script rules (bip119 op_ctv) get reinforced. Is it the wallet devs that write the rules in their wallet? So user could just use another wallet.... Or are the rules (whitelisting/blacklisting for example)  reinforced by miners on chain & they simply reject all /whitelisted/blacklisted accounts from the block.

Upper layers are permissionless so additional requirements can be added. Wallets & exchanges can be considered l2. So if wallet providers decide to blacklist, KYC, comply with regulators and so on its their right. Users rights is to chose which wallet to use according to their need & principles.

Onchain l1 that's where I am extremely worried. If miners get to reinforce on l1 that means all wallets & everything built on top of l1 such as l2, l3 etc need to follow the same rules then that's literally hell for onchain neutrality and fungibility.

Onchain l1 needs to stay censorship resistant and neutral.

Can any one clarify this?