On Wed, Sep 8, 2021 = at 5:03 PM Antoine Riard <ant= oine.riard@gmail.com> wrote:

Hi Jeremy,

Answering here from #22871 discussions.

I agre= e on the general principle to not blur mempool policies signaling in commit= ted transaction data. Beyond preserving upgradeability, another good argume= nt is to let L2 nodes update the mempool policies signaling their pre-signe= d transactions non-interactively. If one of the transaction fields is assig= ned mempool semantics, in case of tightening policy changes, you will need = to re-sign or bear the risks of having non-propagating transactions which o= pens the door for exploitation by a malicious counterparty. I think this po= int is kinda relevant if we have future cross-layer coordinated safety fixe= s to deal with a la CVE-2021-31876.

Even further, a set of L2 counte= rparties would like to pick up divergent tx-relay/mempool policies, having = the signaling fields as part of the signature force them to come to consens= us.

I think we can take the opportunity of p2p packages to introduce= a new field to signal policy. Of course, a malicious tx-relay peer could m= odify its content to jam your transaction's propagation but in that cas= e it is easier to just drop it.

One issue with taking back the `nSeq= uence` field for consensus-semantic sounds is depriving the application-lay= er from a discrete, zero-cost payload (e.g the LN obfuscated commitment num= ber watermark). This might be controversial as we'll increase the price= of such applications if they're still willingly to relay application s= pecific data through the p2p network (e.g force them to use a costly OP_RET= URN output or payer/payee interactions to setup a pay-to-contract)

W= .r.t flag day activation to smooth policy deployment, I think that's so= mething we might rely on in the future though we could distinguish few type= s of policy deployments :
1) loosening changes (e.g full-rbf/dust thresh= old removal), a transaction which was relaying under
the former policy s= hould relay under the new one
2) tightening changes (e.g #22871), a tran= saction which was relaying under the former policy
might not relay under= the new one
3) new feature introduced (e.g packages), a transaction is = offered a new mode of relay

I think 1) doesn't need that level o= f ecosystem coordination as applications/second-layers should always benefi= t from such changes. Maybe with the exception of full-rbf, where we have hi= storical 0-conf softwares, with (broken) security assumptions made on the o= pt-out RBF mechanism. Same with 3), better to have new features deployed gr= adually, a flag day activation day in this case won't mean that all hig= her stacks will jump to use package-relay ?

Where a flag day might m= ake sense would be for 2) ? It would create a higher level of commitment by= the base layer software instead of a pure communication on the ML/GH, whic= h might not be concretized in the announced release due to slow review proc= ess/feature freeze/rebase conflicts... Reversing the process and asking for= Bitcoin applications/higher layers to update first might get us in the tra= p of never doing the change, as someone might have a small use-case in the = corner relying on a given policy behavior.

That said, w.r.t to the p= roposed policy change in #22871, I think it's better to deploy full-rbf= first, then give a time buffer to higher applications to free up the `nSeq= uence` field and finally start to discourage the usage. Otherwise, by intro= ducing new discouragement waivers, e.g not rejecting the usage of the top 8= bits, I think we're moving away from the policy design principle we= 9;re trying to establish (separation of mempool policies signaling from con= sensus data)

Le=C2=A0ven. 3 sept. 2021 =C3=A0=C2=A023:32, Jeremy via bit= coin-dev <bitcoin-dev@lists.linuxfoundation.org> a =C3=A9crit=C2= =A0:
Hi Bitcoin Devs,

I recently noticed a flaw in the Sequ= ence lock implementation with respect to upgradability. It might be the cas= e that this is protected against by some transaction level policy (didn'= ;t see any in policy.cpp, but if not, I've put up a blogpost=C2=A0expla= ining the defect and patching it=C2=A0https://rubin.io/bitcoin= /2021/09/03/upgradable-nops-flaw/

I've proposed patchin= g it here=C2=A0https://github.com/bitcoin/bitcoin/pull/22871, it is pr= oper to widely survey the community before patching to ensure no one is dep= ending on the current semantics in any live application lest this tightenin= g of standardness rules engender a confiscatory effect.

Best,

Jeremy

--
@J= eremyRubin
_______________________________________________
bitcoin-dev mailing list
= bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mail= man/listinfo/bitcoin-dev