From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp3.osuosl.org (smtp3.osuosl.org [IPv6:2605:bc80:3010::136]) by lists.linuxfoundation.org (Postfix) with ESMTP id E3B59C002D for ; Fri, 22 Apr 2022 19:57:57 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp3.osuosl.org (Postfix) with ESMTP id BB65C60E36 for ; Fri, 22 Apr 2022 19:57:57 +0000 (UTC) X-Virus-Scanned: amavisd-new at osuosl.org X-Spam-Flag: NO X-Spam-Score: -1.098 X-Spam-Level: X-Spam-Status: No, score=-1.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, BITCOIN_OBFU_SUBJ=1, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: smtp3.osuosl.org (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from smtp3.osuosl.org ([127.0.0.1]) by localhost (smtp3.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PNFxM0_luAQM for ; Fri, 22 Apr 2022 19:57:56 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.8.0 Received: from mail-yb1-xb29.google.com (mail-yb1-xb29.google.com [IPv6:2607:f8b0:4864:20::b29]) by smtp3.osuosl.org (Postfix) with ESMTPS id 72C7260C26 for ; Fri, 22 Apr 2022 19:57:56 +0000 (UTC) Received: by mail-yb1-xb29.google.com with SMTP id s30so128595ybi.5 for ; Fri, 22 Apr 2022 12:57:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=7KSSd9zTEXz4Syq4NQxDNDPW2GHI2lRqzyUtQBObwgk=; b=F4Urs9SHyqV83/1JclnZsuu95tPc3bC4yMzd6afcC0/noQfHmyBrIqVX9AUiNNEIcE gtxwIc2S3zqzp3vhOU86hw9OcbKkwgzc2R3gXRSWsIewTLRyMIBj0mCdmLtZoCqSk6YC gFGBbZse2O+3DUM9MRcc65E2JTsMdQ6XY7rpQnYsE9nDYYiSNbRv+iEtmF9NNTEUExFi N3GItbi++a93AfD9o+rY+Ayp+Ft/Iai3bMz3rqKUmTBu4rkGxFDXEVbCZgvcanQXkvbQ QXODtAHxE1Sr2X0Se4UzpQgQX8BsNIJxhFiYEj7wub+CvOTSzDl8N5QlAYK20oGx4lo7 MwnA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=7KSSd9zTEXz4Syq4NQxDNDPW2GHI2lRqzyUtQBObwgk=; b=syjwduJ9iq3DmEga3hNfrA+8DjH7QwQQMED18djvj41XOAr+ICO3DEcYHUDYmEOC+s 2ewZhAOUcR+uPBvxVkToWpFfRu0CYhh9w61tTOpjJV/Sb+6YWBt+vrifms8LJPyLWnVI I/ZD4CA0B0wK2Q3tbdHhc+FJdnmxUGFjv5ccrgLy5Y1GXoPIx4cHydEMgjPxgRMQiR4W GcI3Cng5a8o1KiBC/vXkSCnBcH2yJ+6uNewKXoz3PS9aAjykRhZibtOEavsMom88386J +gHMmnSeGjRFHK0PZDlKLfYzMKDUkByRvk3E+uOmn4FNHvS5RcR0FtAA5KXlc41tEbb5 vWyg== X-Gm-Message-State: AOAM531xO5Bz5xWHqf09ZL00/rVdW6Zuq+Tk+q8YiK4eo+acdx4NTj4K NJRJ4PmNFSJ3T5LmMdbQm9uk8c670czkKpJ+s/xaVOTnq/4= X-Google-Smtp-Source: ABdhPJyW81BuFI9L6SbWAePLlS+2MfU5ZZ0V9jsbSMhNUemwZu4C8ARPL7+3f/aComQipQNSBCCFmHCz4AyNKjKmmv4= X-Received: by 2002:a5b:f87:0:b0:62b:f9d8:ed5 with SMTP id q7-20020a5b0f87000000b0062bf9d80ed5mr6155125ybh.467.1650657475316; Fri, 22 Apr 2022 12:57:55 -0700 (PDT) MIME-Version: 1.0 References: <64a34b4d46461da322be51b53ec2eb01@dtrt.org> In-Reply-To: <64a34b4d46461da322be51b53ec2eb01@dtrt.org> From: Antoine Riard Date: Fri, 22 Apr 2022 15:57:43 -0400 Message-ID: To: "David A. Harding" , Bitcoin Protocol Discussion Content-Type: multipart/alternative; boundary="00000000000076507105dd43a4fa" X-Mailman-Approved-At: Fri, 22 Apr 2022 22:14:53 +0000 Subject: Re: [bitcoin-dev] Automatically reverting ("transitory") soft forks, e.g. for CTV X-BeenThere: bitcoin-dev@lists.linuxfoundation.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Bitcoin Protocol Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Apr 2022 19:57:58 -0000 --00000000000076507105dd43a4fa Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Dave, I think the transitory idea is interesting, though I would say it would take far more thinking to capture the implications. > 1. It creates a big footgun. Anyone who uses CTV without adequately preparing for the reversion could easily lose their money. I think that downside should be weighed far more. If we imagine CTV being used in the context of a said off-chain contract, it's not guaranteed you can downgrade to equivalent semantics around the reversion date, or not at the same witness cost which is raising implications for your cached fee-bumping reserves. Further, this downgrade path might have to be re-signed by your off-chain contract counterparties to migrate a balance distribution locked by CTV to one relying on pre-signed transactions. This contract "consensus" is not guaranteed and it could even be leveraged by some unfair counterparties, who have small balances at stake. If you can't gracefully downgrade to equivalent semantics or negotiate a migration, it's more likely the safe behavior to adopt would be to close the off-chain contract, ahead of the reversion date. As it might be a critical operation, the toolchain vendors might adopt the practice to coordinate the automatic closing with a flag day (e.g "close your LN channel at block XXX") or in a relative distributed fashion (e.g "close your LN channel at randomly picked up block between X and Y"). Such relatively automatic closure, if realized in mass, would provoke mempools congestion. An adversarial event which would cloak the security of all existing off-chain contracts. Therefore I'm not sure if a reversion date for a contracting primitive softfork is the soundest off-chain contract engineering practice... Further, I think there is one more downside not considered in your list : negative incentives for the CTV ecosystem stakeholders. As a CTV-enabled protocol developer, as you know time is counted to prove the worthiness of the primitive, you have an interest to design a protocol and develop/deploy a toolchain on a short-time basis, likely not the soundest principle in system software engineering. Such a development attitude is more likely to grieve the ecosystem with safety-critical bugs/vulnerabilities, of which the exploitation might eradicate the credibility of your CTV use-case, and with it the wider CTV ecosystem. So I think the data-collection method itself to advance the consensus-building process isn't neutral on the outcome yielded. The consensus-building stakeholders themselves aren't immune to the incentives disruptions brought by an innovation in the process. Antoine Le mer. 20 avr. 2022 =C3=A0 21:06, David A. Harding via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> a =C3=A9crit : > Hi all, > > The main criticisms I'm aware of against CTV seem to be along the > following lines: > > 1. Usage, either: > a. It won't receive significant real-world usage, or > b. It will be used but we'll end up using something better later > 2. An unused CTV will need to be supported forever, creating extra > maintenance > burden, increasing security surface, and making it harder to evaluate > later > consensus change proposals due to their interactions with CTV > > Could those concerns be mitigated by making CTV an automatically > reverting > consensus change with an option to renew? E.g., redefining OP_NOP4 as > OP_CTV > for five years from BIP119's activation date and then reverting to > OP_NOP4. > If, prior to the end of those five years, a second soft fork was > activated, it > could continue enforcing the CTV rules either for another five years or > permanently. > > This would be similar in nature to the soft fork described in BIP50 > where the > maximum block size was temporarily reduced to address the BDB locks > issue and > then allowed to return to its original value. In Script terms, any use > of > OP_CTV would effectively be: > > OP_IF > OP_CTV > OP_ELSE > <5 years after activation> OP_CLTV > OP_ENDIF > > As long as we are absolutely convinced CTV will have no negative effects > on the > holders or receivers of non-CTV coins, I think an automatically > reverting soft > fork gives us some ability to experiment with new features without > committing > ourselves to live with them forever. > > The main downsides I can see are: > > 1. It creates a big footgun. Anyone who uses CTV without adequately > preparing for > the reversion could easily lose their money. > > 2. Miners would be incentivized to censor spends of the reverting > opcode near its reversion date. E.g., if Alice receives 100 bitcoins > to a > script secured only by OP_CTV and attempts to spend them the day > before it > becomes OP_NOP4, miners might prefer to skip confirming that > transaction even > if it pays a high feerate in favor of spending her 100 bitcoins to > themselves > the next day after reversion. > > The degree to which this is an issue will depend on the diversity of > hashrate and the willingness of any large percentage of hashrate to > deliberately reorg the chain to remove confirmed transactions. This > could be > mitigated by having OP_CTV change to OP_RETURN, destroying any > unspent CTV-only > coins so that any censoring miners only benefited from the (hopefully > slight) > decrease in bitcoin currency supply. > > 3. A bias towards keeping the change. Even if it turned out very few > people > really used CTV, I think there would be a bias at the end of five > years towards > "why not just keep it". > > 4. The drama doesn't end. Activating CTV now, or decisively not > activating it, > may bring to an end our frequent discussions about it (though I > wouldn't > count on that). An automatically reverting soft fork would probably > guarantee we'll have further consensus-level discussions about CTV in > the > future. > > Thanks for reading. I'm curious to hear y'alls thoughts, > > -Dave > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > --00000000000076507105dd43a4fa Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Dave,

I think the transitory idea is interesting= , though I would say it would take far more thinking to capture the implica= tions.

> 1. It creates a big footgun.=C2=A0 Anyone who uses CTV w= ithout adequately
preparing for the reversion could easily lose their m= oney.

I think that downside should be weighed far more. If we imagin= e CTV being used in the context of a said off-chain contract, it's not = guaranteed you can downgrade to equivalent semantics around the reversion d= ate, or not at the same witness cost which is raising implications for your= cached fee-bumping reserves.

Further, this downgrade path might hav= e to be re-signed by your off-chain contract counterparties to migrate a ba= lance distribution locked by CTV to one relying on pre-signed transactions.= This contract "consensus" is not guaranteed and it could even be= leveraged by some unfair counterparties, who have small balances at stake.=

If you can't gracefully downgrade to equivalent semantics or ne= gotiate a migration, it's more likely the safe behavior to adopt would = be to close the off-chain contract, ahead of the reversion date.
As it = might be a critical operation, the toolchain vendors might adopt the practi= ce to coordinate the automatic closing with a flag day (e.g "close you= r LN channel at block XXX") or in a relative distributed fashion (e.g = "close your LN channel at randomly picked up block between X and Y&quo= t;). Such relatively automatic closure, if realized in mass, would provoke = mempools congestion. An adversarial event which would cloak the security of= all existing off-chain contracts.

Therefore I'm not sure if a = reversion date for a contracting primitive softfork is the soundest off-cha= in contract engineering practice...

Further, I think there is one mo= re downside not considered in your list : negative incentives for the CTV e= cosystem stakeholders. As a CTV-enabled protocol developer, as you know tim= e is counted to
prove the worthiness of the primitive, you have an inter= est to design a protocol and develop/deploy a toolchain on a short-time bas= is, likely not the soundest principle in system software engineering.
Su= ch a development attitude is more likely to grieve the ecosystem with safet= y-critical bugs/vulnerabilities, of which the exploitation might eradicate = the credibility of your CTV use-case, and with it the wider CTV ecosystem.<= br>
So I think the data-collection method itself to advance the consensu= s-building process isn't neutral on the outcome yielded. The consensus-= building stakeholders themselves aren't immune to the incentives disrup= tions brought by an innovation in the process.

Antoine

=
Le=C2=A0me= r. 20 avr. 2022 =C3=A0=C2=A021:06, David A. Harding via bitcoin-dev <bitcoin-dev@lists.lin= uxfoundation.org> a =C3=A9crit=C2=A0:
Hi all,

The main criticisms I'm aware of against CTV seem to be along the
following lines:

1. Usage, either:
=C2=A0 =C2=A0a. It won't receive significant real-world usage, or
=C2=A0 =C2=A0b. It will be used but we'll end up using something better= later
2. An unused CTV will need to be supported forever, creating extra
maintenance
=C2=A0 =C2=A0 burden, increasing security surface, and making it harder to = evaluate
later
=C2=A0 =C2=A0 consensus change proposals due to their interactions with CTV=

Could those concerns be mitigated by making CTV an automatically
reverting
consensus change with an option to renew?=C2=A0 E.g., redefining OP_NOP4 as=
OP_CTV
for five years from BIP119's activation date and then reverting to
OP_NOP4.
If, prior to the end of those five years, a second soft fork was
activated, it
could continue enforcing the CTV rules either for another five years or
permanently.

This would be similar in nature to the soft fork described in BIP50
where the
maximum block size was temporarily reduced to address the BDB locks
issue and
then allowed to return to its original value.=C2=A0 In Script terms, any us= e
of
OP_CTV would effectively be:

=C2=A0 =C2=A0 =C2=A0OP_IF
=C2=A0 =C2=A0 =C2=A0 =C2=A0<arguments> OP_CTV
=C2=A0 =C2=A0 =C2=A0OP_ELSE
=C2=A0 =C2=A0 =C2=A0 =C2=A0<5 years after activation> OP_CLTV
=C2=A0 =C2=A0 =C2=A0OP_ENDIF

As long as we are absolutely convinced CTV will have no negative effects on the
holders or receivers of non-CTV coins, I think an automatically
reverting soft
fork gives us some ability to experiment with new features without
committing
ourselves to live with them forever.

The main downsides I can see are:

1. It creates a big footgun.=C2=A0 Anyone who uses CTV without adequately <= br> preparing for
=C2=A0 =C2=A0 the reversion could easily lose their money.

2. Miners would be incentivized to censor spends of the reverting
=C2=A0 =C2=A0 opcode near its reversion date.=C2=A0 E.g., if Alice receives= 100 bitcoins
to a
=C2=A0 =C2=A0 script secured only by OP_CTV and attempts to spend them the = day
before it
=C2=A0 =C2=A0 becomes OP_NOP4, miners might prefer to skip confirming that =
transaction even
=C2=A0 =C2=A0 if it pays a high feerate in favor of spending her 100 bitcoi= ns to
themselves
=C2=A0 =C2=A0 the next day after reversion.

=C2=A0 =C2=A0 The degree to which this is an issue will depend on the diver= sity of
=C2=A0 =C2=A0 hashrate and the willingness of any large percentage of hashr= ate to
=C2=A0 =C2=A0 deliberately reorg the chain to remove confirmed transactions= .=C2=A0 This
could be
=C2=A0 =C2=A0 mitigated by having OP_CTV change to OP_RETURN, destroying an= y
unspent CTV-only
=C2=A0 =C2=A0 coins so that any censoring miners only benefited from the (h= opefully
slight)
=C2=A0 =C2=A0 decrease in bitcoin currency supply.

3. A bias towards keeping the change.=C2=A0 Even if it turned out very few =
people
=C2=A0 =C2=A0 really used CTV, I think there would be a bias at the end of = five
years towards
=C2=A0 =C2=A0 "why not just keep it".

4. The drama doesn't end.=C2=A0 Activating CTV now, or decisively not <= br> activating it,
=C2=A0 =C2=A0 may bring to an end our frequent discussions about it (though= I
wouldn't
=C2=A0 =C2=A0 count on that).=C2=A0 An automatically reverting soft fork wo= uld probably
=C2=A0 =C2=A0 guarantee we'll have further consensus-level discussions = about CTV in
the
=C2=A0 =C2=A0 future.

Thanks for reading.=C2=A0 I'm curious to hear y'alls thoughts,

-Dave
_______________________________________________
bitcoin-dev mailing list
= bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mail= man/listinfo/bitcoin-dev
--00000000000076507105dd43a4fa--