[bitcoin-dev] CTV BIP Meeting #9 Notes

[bitcoin-dev] CTV BIP Meeting #9 Notes

[alicexbt]

[-- Attachment #1: Type: text/plain, Size: 4535 bytes --]

Hi Bitcoin Developers,

Summary for the last CTV meeting:

Topics:

1)OP_TX
2)OP_CAT / CSFS / General Covenants
3)Script interpreter flags

===================================================
OP_TX
===================================================

Jeremy Rubin thinks that if folks believe OP_TX is a superior upgrading path, he would be delighted to shift focus. Although prefers more thorough evaluation of CTV / NOP upgradability vs the multibyte op-success.

Anthony Towns doesn't find OP_TX interesting if it just does CTV from start. He prefers adding SEPARATELY, UNHASHED and maybe things to do APO equivalent behavior.

Harding considers OP_TX==OP_CTV only somewhat more interesting than just OP_CTV because it provides a very clear upgrade path. He would be more interested if it came with a few more initial features.

===================================================
OP_CAT / CSFS / General Covenants
===================================================

Harding believes that concerns regarding general covenants are unfounded. He indicated an interest in learning more about one of ZmnSCPxj's criticisms, which is the only one about which he is personally concerned. It has to do with general covenants making scripts more difficult to evaluate.

Harding's thoughts on CAT+CSFS:

13:01 < harding> Without regard to the generalized covenants concern, I think CAT+CSFS add the smallest amount of consensus complexity to enable the greatest amount of experimentation with covenants and other features (like signature delegation), which can provide significant data about real-world usage for informing future soft fork designs. There'd still be lots of question marks, plus chances for abuse (e.g. the sort of tx spamming we saw during the block
13:01 < harding> size debates), but I think it's worth giving devs the tools to experiment onchain (with only their and their supporters' money) and allowing economic full node operators to evualuate actual use before agreeing to enforce future soft forks whose code will need to be maintained in perpetuitity.
13:02 < harding> Consensus stability is a reference to, for example, being able to implement something like drivechains on top of CAT+CSFS?

Jeremy Rubin shared some issues that are being discussed on mailing list and social media related to general bitcoin covenants:

- Scripts harder to analyze
- Fungibility
- MEV & consensus stability
- Whitelist/Blacklist

Anthony Towns and TechMiX added that some users think covenants can be imposed on their coins without consent or everyone will accept covenants so unable to pay them. Some bitcoin users in Iran are afraid that a generalized form of the covenants would enable some kind of censorship.

MEV could be one the issues associated with general covenants. There are some resources on https://mev.day if anyone interested to read more about it.

13:06 <@jeremyrubin> the covenants are "self executing" and can be e.g. sandwiched
13:07 <@jeremyrubin> so given that bitmatrix is sandwich attackable, you'd see similar types of MEV as Eth sees
13:07 <@jeremyrubin> v.s. the MEV of e.g. lightning channels

13:14 < _aj_> i guess i'd rather not have that sort of MEV available, because then it makes complicated MEV extraction profitable, which then makes "smart" miners more profitable than "Dumb" ones, which is maybe centralising

===================================================
Script interpreter flags
===================================================

Anthony Towns likes the idea of documenting exactly what rules the flags are meant to enforce (associated BIPs).

13:54 <@jeremyrubin> The test flags infrastructure relies on some particular features of validity/invalidity and flagging, which has previously been avoided surfacing because upgrades were at the output type level. The way the flagging works is a not quite the right thing for testability and simple consensus code, it's worth re-evaluating?
13:55 < _aj_> we changed how "things are done" with taproot, and need to re-evaluate how we do script enforcement in light of wanting to keep doing things that way?
13:56 < _aj_> we don't really have to do things the way we did for taproot, but i thought it was kind-of nice, i guess
13:56 <@jeremyrubin> Well taproot just sidestepped the issue because it was an outputtype
13:56 < _aj_> taproot had it easy because it was an outputtype
13:57 <@jeremyrubin> yes

IRC Logs: https://gnusha.org/ctv-bip-review/2022-05-17.log

/dev/fd0

Sent with [ProtonMail](https://protonmail.com/) secure email.

[-- Attachment #2: Type: text/html, Size: 9625 bytes --]

Re: [bitcoin-dev] CTV BIP Meeting #9 Notes

[ZmnSCPxj]

Good morning fd0,


> MEV could be one the issues associated with general covenants. There are some resources on https://mev.day if anyone interested to read more about it.
> 13:06 <@jeremyrubin> the covenants are "self executing" and can be e.g. sandwiched13:07 <@jeremyrubin> so given that bitmatrix is sandwich attackable, you'd see similar types of MEV as Eth sees13:07 <@jeremyrubin> v.s. the MEV of e.g. lightning channels
> 13:14 < _aj_> i guess i'd rather not have that sort of MEV available, because then it makes complicated MEV extraction profitable, which then makes "smart" miners more profitable than "Dumb" ones, which is maybe centralising

Well that was interesting....

TLDR: MEV = Miner-extractable value, basically if your contracts are complex enough, miners can analyze which of the possible contract executions are most profitable for them, and order transactions on the block they are building in such a way that it is the most profitable path that gets executed.
(do correct me if that summary is inaccurate or incomplete)

As a concrete example: in a LN channel breach condition, the revocation transaction must be confirmed within the CSV timeout, or else the theft will be accepted and confirmed.
Now, some software will be aware of this timeout and will continually raise the fee of the revocation transaction per block.
A rational miner which sees a channel breach condition might prefer to not mine such a transaction, since if it is not confirmed, the software will bump up the fees and the miner could try again on the next block with the higher feerates.
Depending on the channel size and how the software behaves exactly, the miner may be able to make a decision on whether it should or should not work on the revocation transaction and instead hold out for a later higher fee.

Now, having thought of this problem for no more than 5 minutes, it seems to me, naively, that a mechanism with privacy would be helpful, i.e. the contract details should be as little-revealed as possible, to reduce the scope of miner-extractable value.
For instance, Taproot is good since only one branch at a time can be revealed, however, in case of a dispute, multiple competing branches of the Taproot may be revealed by the disputants, and the miners may now be able to make a choice.

Probably, it is best if our covenants systems take full advantage of the linearity of Schnorr signing, in that case, if there is at all some kind of branch involved; for example, a previous transaction may reveal, if you have the proper adaptor signature, some scalar, and that scalar is actually the `s` component for a signature of a different transaction.
Without knowledge of the adaptor signature, and without knowledge of the link between this previous transaction and some other one, a miner cannot extract additional value by messing with the ordering the transactions get confirmed on the blockchain, or whatever.

This may mean that mechanisms that inspect the block outside of the transaction being validated (e.g. `OP_BRIBE` for drivechains, or similar mechanisms that might be capable of looking beyond the transaction) should be verboten; such cross-transaction introspection should require an adaptor signature that is kept secret by the participants from the miner that might want to manipulate the transactions to make other alternate branches more favorable to the miner.

In addition, covenant mechanisms that require large witness data are probably more vulnerable to MEV.
For instance, if in a dispute case, one of the disputants needs to use a large witness data while the other requires a smaller one, then the disputant with the smaller witness data would have an advantage, and can match the fee offered by the disputant with the larger witness.
Then a fee-maximizing miner would prefer the smaller-witness branch of the contract, as they get more fees for less blockspace.
Of course, this mechanism itself can be used if we can arrange that the disputant that is inherently "wrong" (i.e. went against the expected behavior of the protocol) is the one that is burdened with the larger witness.

Or I could be entirely wrong and MEV is something even worse than that.

Hmmmmmm

Regards,
ZmnSCPxj

Re: [bitcoin-dev] CTV BIP Meeting #9 Notes

[alicexbt]

Hi ZmnSCPxj,


> TLDR: MEV = Miner-extractable value, basically if your contracts are complex enough, miners can analyze which of the possible contract executions are most profitable for them, and order transactions on the block they are building in such a way that it is the most profitable path that gets executed.
> (do correct me if that summary is inaccurate or incomplete)

Yes its elaborated as Miner Extractable Value and also referred as Maximal Extractable Value sometimes because value could be extracted by validators, sequencers and others in some chains. MEV is basically frontrunning some transactions based on mempool activity for profit. Profit could be achieved by order or include/exclude some transactions in block. Normally such opportunities are only found in complex smart contracts that allow trades being settled on-chain.

In this (IRC logs) context, Jeremy mentioned sandwich attack. An attacker looks for buy orders in mempool, buy before others and profit from selling at higher price.

> Now, having thought of this problem for no more than 5 minutes, it seems to me, naively, that a mechanism with privacy would be helpful, i.e. the contract details should be as little-revealed as possible, to reduce the scope of miner-extractable value.

This makes sense and Tarun has shared similar ideas for AMMs in this pdf: https://drive.google.com/file/d/1W6PtJhGgqlNTCENE7I5pO5Brh2oqasVc/view?usp=sharing

> Probably, it is best if our covenants systems take full advantage of the linearity of Schnorr signing, in that case, if there is at all some kind of branch involved; for example, a previous transaction may reveal, if you have the proper adaptor signature, some scalar, and that scalar is actually the `s` component for a signature of a different transaction.
> Without knowledge of the adaptor signature, and without knowledge of the link between this previous transaction and some other one, a miner cannot extract additional value by messing with the ordering the transactions get confirmed on the blockchain, or whatever.

I am assuming this is possible using all the bitcoin covenant proposals including CTV.

> In addition, covenant mechanisms that require large witness data are probably more vulnerable to MEV.

Which covenant mechanisms require large witness data?


/dev/fd0

Sent with ProtonMail secure email.
------- Original Message -------
On Friday, May 20th, 2022 at 6:33 AM, ZmnSCPxj <ZmnSCPxj@protonmail.com> wrote:


> Good morning fd0,
>
> > MEV could be one the issues associated with general covenants. There are some resources on https://mev.day if anyone interested to read more about it.
> > 13:06 <@jeremyrubin> the covenants are "self executing" and can be e.g. sandwiched13:07 <@jeremyrubin> so given that bitmatrix is sandwich attackable, you'd see similar types of MEV as Eth sees13:07 <@jeremyrubin> v.s. the MEV of e.g. lightning channels
> > 13:14 < aj> i guess i'd rather not have that sort of MEV available, because then it makes complicated MEV extraction profitable, which then makes "smart" miners more profitable than "Dumb" ones, which is maybe centralising
>
>
> Well that was interesting....
>
> TLDR: MEV = Miner-extractable value, basically if your contracts are complex enough, miners can analyze which of the possible contract executions are most profitable for them, and order transactions on the block they are building in such a way that it is the most profitable path that gets executed.
> (do correct me if that summary is inaccurate or incomplete)
>
> As a concrete example: in a LN channel breach condition, the revocation transaction must be confirmed within the CSV timeout, or else the theft will be accepted and confirmed.
> Now, some software will be aware of this timeout and will continually raise the fee of the revocation transaction per block.
> A rational miner which sees a channel breach condition might prefer to not mine such a transaction, since if it is not confirmed, the software will bump up the fees and the miner could try again on the next block with the higher feerates.
> Depending on the channel size and how the software behaves exactly, the miner may be able to make a decision on whether it should or should not work on the revocation transaction and instead hold out for a later higher fee.
>
> Now, having thought of this problem for no more than 5 minutes, it seems to me, naively, that a mechanism with privacy would be helpful, i.e. the contract details should be as little-revealed as possible, to reduce the scope of miner-extractable value.
> For instance, Taproot is good since only one branch at a time can be revealed, however, in case of a dispute, multiple competing branches of the Taproot may be revealed by the disputants, and the miners may now be able to make a choice.
>
> Probably, it is best if our covenants systems take full advantage of the linearity of Schnorr signing, in that case, if there is at all some kind of branch involved; for example, a previous transaction may reveal, if you have the proper adaptor signature, some scalar, and that scalar is actually the `s` component for a signature of a different transaction.
> Without knowledge of the adaptor signature, and without knowledge of the link between this previous transaction and some other one, a miner cannot extract additional value by messing with the ordering the transactions get confirmed on the blockchain, or whatever.
>
> This may mean that mechanisms that inspect the block outside of the transaction being validated (e.g. `OP_BRIBE` for drivechains, or similar mechanisms that might be capable of looking beyond the transaction) should be verboten; such cross-transaction introspection should require an adaptor signature that is kept secret by the participants from the miner that might want to manipulate the transactions to make other alternate branches more favorable to the miner.
>
> In addition, covenant mechanisms that require large witness data are probably more vulnerable to MEV.
> For instance, if in a dispute case, one of the disputants needs to use a large witness data while the other requires a smaller one, then the disputant with the smaller witness data would have an advantage, and can match the fee offered by the disputant with the larger witness.
> Then a fee-maximizing miner would prefer the smaller-witness branch of the contract, as they get more fees for less blockspace.
> Of course, this mechanism itself can be used if we can arrange that the disputant that is inherently "wrong" (i.e. went against the expected behavior of the protocol) is the one that is burdened with the larger witness.
>
> Or I could be entirely wrong and MEV is something even worse than that.
>
> Hmmmmmm
>
> Regards,
> ZmnSCPxj

Re: [bitcoin-dev] CTV BIP Meeting #9 Notes

[ZmnSCPxj]

Good morning fd0,


> > In addition, covenant mechanisms that require large witness data are probably more vulnerable to MEV.
>
>
> Which covenant mechanisms require large witness data?

`OP_CSFS` + `OP_CAT`, which requires that you copy parts of the transaction into the witness data if you want to use it for covenants.
And the script itself is in the witness data, and AFAIK `OP_CSFS` needs large scripts if used for covenants.

Arguably though `OP_CSFS` is not designed for covenants, it just *happens to enable* covenants when you throw enough data at it.

If we are going to tolerate recursive covenants, we might want an opcode that explicitly supports recursion, instead of one that happens to enable recursive covenants, because the latter is likely to require more data to be pushed on the witness stack.
E.g. instead of the user having to quine the script (i.e. the script is really written twice, so it ends up doubling the witness size of the SCRIPT part), make an explicitly quining opcode.

Basically, Do not Repeat Yourself.

Regards,
ZmnSCPxj

Re: [bitcoin-dev] CTV BIP Meeting #9 Notes

[Bram Cohen]

[-- Attachment #1: Type: text/plain, Size: 963 bytes --]

On Thu, May 19, 2022 at 9:17 AM alicexbt via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

>
> MEV could be one the issues associated with general covenants. There are
> some resources on https://mev.day if anyone interested to read more about
> it.
>

One of the top things to do about MEV is to make all transactions in a
block simultaneous, so for example if you have a price oracle it can be
limited to only reporting one price per block so although it can be
manipulated to either report a high or low price it can't simultaneously do
both. In Bitcoin ordering is strictly enforced but there's a loophole that
things which happen in the same transaction do happen simultaneously, so
future extensions could be made to only sign things they care about and are
okay with transactions getting aggregated just by smushing them together.
That of course requires a new signature opcode, because current signatures
always sign the whole transaction.

[-- Attachment #2: Type: text/html, Size: 1472 bytes --]