path: root/52/5a00cf41d7d0eee5a9d3c4199bc134dfb17e6f

Return-Path: <gsanders87@gmail.com>
Received: from smtp3.osuosl.org (smtp3.osuosl.org [IPv6:2605:bc80:3010::136])
 by lists.linuxfoundation.org (Postfix) with ESMTP id 99E66C002D
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Tue, 10 May 2022 18:53:27 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by smtp3.osuosl.org (Postfix) with ESMTP id 833EA60F89
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Tue, 10 May 2022 18:53:27 +0000 (UTC)
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: -1.848
X-Spam-Level: 
X-Spam-Status: No, score=-1.848 tagged_above=-999 required=5
 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1,
 DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1,
 FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001,
 HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001,
 SPF_PASS=-0.001] autolearn=ham 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 OXwZr-VeDVkY
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Tue, 10 May 2022 18:53:26 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.8.0
Received: from mail-yw1-x112f.google.com (mail-yw1-x112f.google.com
 [IPv6:2607:f8b0:4864:20::112f])
 by smtp3.osuosl.org (Postfix) with ESMTPS id 2FB6260F57
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Tue, 10 May 2022 18:53:26 +0000 (UTC)
Received: by mail-yw1-x112f.google.com with SMTP id
 00721157ae682-2f16645872fso190126477b3.4
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Tue, 10 May 2022 11:53:26 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112;
 h=mime-version:from:date:message-id:subject:to;
 bh=UWGjZzIzUAB6kFhLmdWRROUn1aHCoCEhjmlPmx95tHE=;
 b=qIGQD+LHhbE9OzGfbPdwG2w7ybBDSfoc27egvZnpmZ3LIzGgVqU3bDwErujrzEamm6
 UPq5FZadSV9qEe7iX+cluyRI7JqXLwfjINQgn2RilFqEybAKcG2h/7fFU9ApLwtIxJT3
 +/+MNQB68/d/pwfjJfyBQ8MnJ1qwtgCYBnmkPDcnvUi6LPhMnECaqfuWByhax+5aOnHP
 u4BTuC0TGas9KNgfhp9iChKEZvrSV47SV2DQl1JdC4sYRc/s4BnBKI1wbr+COzRPyjFq
 hD4b2PbCouU9pGHH3RgY23MwcQsMHPLdPpOp3sp6JvtDuh4MmAfc9CG2ACvnvsh3SQqe
 EOrA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20210112;
 h=x-gm-message-state:mime-version:from:date:message-id:subject:to;
 bh=UWGjZzIzUAB6kFhLmdWRROUn1aHCoCEhjmlPmx95tHE=;
 b=4GkvIwfxRMcq2hXLSuoZTuFUQoC3Zo+oHWty/0FQlVndX4UF2yRkygM/10cM7/ztaO
 SvW2Mm+epPwIrNkWua1zdvWh6sN/tvrDI7OBnaDOt5JviJLwqVXIhkLfK4kEpEVNdtom
 rC1heFRfGj6QcM+gY5nV23dPmK+Hi9vXtx0ndE9EfAegqsRodlRibIHQPIX4y0eSoyJt
 0oCEae2zFXLKMVkq0nceLANtNQA+1wrQSHUTr3X2slXSjCqyC6G5ZPlkqhopY9Nqll9L
 ACkgo64nEMzDILJj+8YsIvuGQxcu+RjrEQLJgUfwoiiaJOHU/hMa6dvmYRnLZJj5jz+q
 Gj8g==
X-Gm-Message-State: AOAM530rPEONFmOPKmSnENNpXcrc+KSr8mKRAo13xlrGr0JynaOyWtG5
 yfd2EMCpzWMBIGcPWxWd1lsUkvP81ZbroaQ/Cyh6tNKD
X-Google-Smtp-Source: ABdhPJxGWPQmMnyFWmxp1G8s8aujrNBxbgQG7S5GRQ1PhRjL5jeztjg1riNIPeTDD1f0tS7gjSkhCQjGs5OZcq7yXAU=
X-Received: by 2002:a81:1f02:0:b0:2f8:5866:9431 with SMTP id
 f2-20020a811f02000000b002f858669431mr22683871ywf.403.1652208804888; Tue, 10
 May 2022 11:53:24 -0700 (PDT)
MIME-Version: 1.0
From: Greg Sanders <gsanders87@gmail.com>
Date: Tue, 10 May 2022 14:53:14 -0400
Message-ID: <CAB3F3Dtp7YQBhLJQbCLpSKau8Hj=5gN4yuGCFN=u=6e1o6o=dA@mail.gmail.com>
To: Bitcoin Dev <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary="000000000000e905b605deacd6e8"
Subject: [bitcoin-dev] Bringing a nuke to a knife fight: Transaction
 introspection to stop RBF pinning
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Bitcoin Protocol Discussion <bitcoin-dev.lists.linuxfoundation.org>
List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>, 
 <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe>
List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/>
List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org>
List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help>
List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>, 
 <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=subscribe>
X-List-Received-Date: Tue, 10 May 2022 18:53:27 -0000

--000000000000e905b605deacd6e8
Content-Type: text/plain; charset="UTF-8"

Hello devs,

I've had this thought rattling around and thought it was worth putting to a
wider audience since
I haven't really seen it in other contexts. I've been working on eltoo
designs for Elements and
eventual inclusion into Bitcoin. With that in mind there's been a
reasonable amount of discussion
on the remaining unknowns on how well eltoo could work. To me the biggest
issue is BIP125 rule#3.

To quote:"The replacement transaction pays an absolute fee of at least the
sum paid by the original
transactions."

In the ANYONECANPAY-like scenarios like eltoo that require "bring your own
fees", this essentially
means the counterparty(or anyone, if you don't include chaperone sigs[0])
can post a series of low
feerate update transactions, or the final update, with bloated
inputs/outputs(depending on flags),
and this results in illicit HTLC timeouts as the channel is unable to be
settled in time, unless you fork
over quite a few sats. This is a problem in both "vanilla" eltoo[1] from
the original paper, as well as the
"layered commitments" style of eltoo[2]. This problem is highly reminiscent
of the ANYONECANPAY
pinning that others have discussed for vaults and other usecases, in that
anyone can include new
inputs(and sometimes outputs) to make the overall feerate lower. To
promptly get the final transactions
settled, you are forced to over-pay, and essentially refund your griefing
counterparty by knocking their
inputs out of the mempool.

Fixing BIP125 rule#3 would be great. It's also a while out at a minimum.

There are thoughts on how to mitigate some cases[3] of this pinning using
policy, and could be extended
to cover this particular pinning case(restrict both transaction weight AND
the weight of the descendant
package, or maybe just include the txns weight in the original idea?). This
might be the simplest idea,
if it ends up being deemed incentive compatible and deployed.

In case the above is not incentive compatible, we can use more drastic
measures. Another tactic would
be to use transaction introspection opcodes to smooth around these policy
issues.

Elements has its own set of transaction introspection codes[4], but fairly
standard introspection codes
seem to be sufficient.

This example is using Rusty's quite recent OP_TX proposal[5] with a single
extension but as mentioned
before it's all fairly standard. The actual eltoo-enabling opcode
implementation is basically orthogonal
to this problem, so I'm simply focusing on restricting the size of the
transaction package being
submitted to mempools.

For simplicity of a working example, we'll assume a set of "state" outputs
that are continuously being spent
off-chain and sent to a committed set of outputs. In vanilla eltoo case
this corresponds to the first
input and output you typically see in diagrams. The state transitions
include no fees themselves,
sending inputs of sum value N to outputs that sum to the value of N.
Vanilla eltoo uses SIGHASH_SINGLE
to bind just the first input/ouput pair. To post on-chain, we will need to
include at least one input,
and likely an output for change.

We add OPTX_SELECT_WEIGHT(pushes tx weight to stack, my addition to the
proposal) to the "state" input's script.
This is used in the update transaction to set the upper bound on the final
transaction weight.
In this same input, for each contract participant, we also conditionally
commit to the change output's scriptpubkey
via OPTX_SELECT_OUTPUT_SCRIPTPUBKEY and OPTX_SELECT_OUTPUTCOUNT==2. This
means any participant can send change back
to themselves, but with a catch. Each change output script possibility in
that state input also includes a 1 block
CSV to avoid mempool spending to reintroduce pinning. This allows the
change value to be anything, contra to
what SIGHASH_ALL would give you instead.

With this setup, you can't CPFP-spend the fee change outputs you create,
but you can RBF as much as
you'd like by RBFing at higher feerates, using any number of inputs you'd
like provided the total tx
weight doesn't exceed the OPTX_SELECT_WEIGHT argument.

With more engineering we can re-enable CPFP of this change output as well.
Handwaves here, but we could
encumber change outputs to either the aformentioned 1 block CSV encumbered
outputs or one to another
OPTX_SELECT_WEIGHT, recursively. This would allow each counterparty to CPFP
N times, each transaction
a maximum weight, and use the 1 block CSV as an "escape hatch" to get their
fee output back out from
the covenant structure. We could mix and match strategies here as well
allowing bigger transactions at
each step, or more steps. I suspect you'd want a single weight-bound CPFP
that can later be RBF'd any
number of times under this same weight limit.

TL;DR: Mempool is hard, let's use transaction weight, output count, and
output scriptpubkey,
and ??? introspection to avoid solving life's hard problems.

0:
https://lists.linuxfoundation.org/pipermail/lightning-dev/2019-May/001994.html
1: https://blockstream.com/eltoo.pdf
2:
https://lists.linuxfoundation.org/pipermail/lightning-dev/2020-January/002448.html
3:
https://gist.github.com/glozow/25d9662c52453bd08b4b4b1d3783b9ff?permalink_comment_id=4058140#gistcomment-4058140
4:
https://github.com/ElementsProject/elements/blob/master/doc/tapscript_opcodes.md
5:
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-May/020450.html

--000000000000e905b605deacd6e8
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">Hello devs,<br><br>I&#39;ve had this thought rattling arou=
nd and thought it was worth putting to a wider audience since<br>I haven&#3=
9;t really seen it in other contexts. I&#39;ve been working on eltoo design=
s for Elements and<br>eventual inclusion into Bitcoin. With that in mind th=
ere&#39;s been a reasonable amount of discussion<br>on the remaining unknow=
ns on how well eltoo could work. To me the biggest issue is BIP125 rule#3.<=
div><br>To quote:&quot;The replacement transaction pays an absolute fee of =
at least the sum paid by the original<br>transactions.&quot;<br><br>In the =
ANYONECANPAY-like scenarios like eltoo that require &quot;bring your own fe=
es&quot;, this essentially<br>means the counterparty(or anyone, if you don&=
#39;t include chaperone sigs[0]) can post a series of low<br>feerate update=
 transactions, or the final update, with bloated inputs/outputs(depending o=
n flags),<br>and this results in illicit HTLC timeouts as the channel is un=
able to be settled in time,=C2=A0unless you fork</div><div>over quite a few=
 sats. This is a problem in both &quot;vanilla&quot; eltoo[1] from the orig=
inal paper, as well as the</div><div>&quot;layered commitments&quot; style =
of eltoo[2]. This problem is highly reminiscent of the ANYONECANPAY</div><d=
iv>pinning that others have discussed for vaults and other usecases, in tha=
t anyone can include new</div><div>inputs(and sometimes outputs) to make th=
e overall feerate lower. To promptly get the final transactions</div><div>s=
ettled, you are forced to=C2=A0over-pay, and essentially refund your griefi=
ng counterparty by knocking their</div><div>inputs out of the mempool.<br><=
br>Fixing BIP125 rule#3 would be great. It&#39;s also a while out at a mini=
mum.<br><br>There are thoughts on how to mitigate some cases[3] of this pin=
ning using policy, and could be extended<br>to cover this particular pinnin=
g case(restrict both transaction weight AND the weight of the descendant<br=
>package, or maybe just include the txns weight in the original idea?). Thi=
s might be the simplest idea,<br>if it ends up being deemed incentive compa=
tible and deployed.<br><br>In case the above is not incentive compatible, w=
e can use more drastic measures. Another tactic would<br>be to use transact=
ion introspection opcodes to smooth around these policy issues.<br><br>Elem=
ents has its own set of transaction introspection codes[4], but fairly stan=
dard introspection codes<br>seem to be sufficient.<br><br>This example is u=
sing Rusty&#39;s quite recent OP_TX proposal[5] with a single extension but=
 as mentioned<br>before it&#39;s all fairly standard. The actual eltoo-enab=
ling opcode implementation is basically orthogonal<br>to this problem, so I=
&#39;m simply focusing on restricting the size of the transaction package b=
eing<br>submitted to mempools.<br><br>For simplicity of a working example, =
we&#39;ll assume a set of &quot;state&quot; outputs that are continuously b=
eing spent<br>off-chain and sent to a committed set of outputs. In vanilla =
eltoo case this corresponds to the first<br>input and output you typically =
see in diagrams. The state transitions include no fees themselves,<br>sendi=
ng inputs of sum value N to outputs that sum to the value of N. Vanilla elt=
oo uses SIGHASH_SINGLE<br>to bind just the first input/ouput pair. To post =
on-chain, we will need to include at least one input,<br>and likely an outp=
ut for change.<br><br>We add OPTX_SELECT_WEIGHT(pushes tx weight to stack, =
my addition to the proposal) to the &quot;state&quot; input&#39;s script.<b=
r>This is used in the update transaction to set the upper bound on the fina=
l transaction weight.<br>In this same input, for each contract participant,=
 we also conditionally commit to the change output&#39;s scriptpubkey<br>vi=
a OPTX_SELECT_OUTPUT_SCRIPTPUBKEY and OPTX_SELECT_OUTPUTCOUNT=3D=3D2. This =
means any participant can send change back<br>to themselves, but with a cat=
ch. Each change output script possibility in that state input also includes=
 a 1 block<br>CSV to avoid mempool spending to reintroduce pinning. This al=
lows the change value to be anything, contra to<br>what SIGHASH_ALL would g=
ive you instead.<br><br>With this setup, you can&#39;t CPFP-spend the fee c=
hange outputs you create, but you can RBF as much as<br>you&#39;d like by R=
BFing at higher feerates, using any number of inputs you&#39;d like provide=
d the total tx<br>weight doesn&#39;t exceed the OPTX_SELECT_WEIGHT argument=
.<br><br>With more engineering we can re-enable CPFP of this change output =
as well. Handwaves here, but we could<br>encumber change outputs to either =
the aformentioned 1 block CSV encumbered outputs or one to another<br>OPTX_=
SELECT_WEIGHT, recursively. This would allow each counterparty to CPFP N ti=
mes, each transaction<br>a maximum weight, and use the 1 block CSV as an &q=
uot;escape hatch&quot; to get their fee output back out from<br>the covenan=
t structure. We could mix and match strategies here as well allowing bigger=
 transactions at<br>each step, or more steps. I suspect you&#39;d want a si=
ngle weight-bound CPFP that can later be RBF&#39;d any<br>number of times u=
nder this same weight limit.<br><br>TL;DR: Mempool is hard, let&#39;s use t=
ransaction weight, output count, and output scriptpubkey,<br>and ??? intros=
pection to avoid solving life&#39;s hard problems.<br><br>0: <a href=3D"htt=
ps://lists.linuxfoundation.org/pipermail/lightning-dev/2019-May/001994.html=
" target=3D"_blank">https://lists.linuxfoundation.org/pipermail/lightning-d=
ev/2019-May/001994.html</a><br>1: <a href=3D"https://blockstream.com/eltoo.=
pdf" target=3D"_blank">https://blockstream.com/eltoo.pdf</a><br>2: <a href=
=3D"https://lists.linuxfoundation.org/pipermail/lightning-dev/2020-January/=
002448.html" target=3D"_blank">https://lists.linuxfoundation.org/pipermail/=
lightning-dev/2020-January/002448.html</a><br>3: <a href=3D"https://gist.gi=
thub.com/glozow/25d9662c52453bd08b4b4b1d3783b9ff?permalink_comment_id=3D405=
8140#gistcomment-4058140" target=3D"_blank">https://gist.github.com/glozow/=
25d9662c52453bd08b4b4b1d3783b9ff?permalink_comment_id=3D4058140#gistcomment=
-4058140</a><br>4: <a href=3D"https://github.com/ElementsProject/elements/b=
lob/master/doc/tapscript_opcodes.md" target=3D"_blank">https://github.com/E=
lementsProject/elements/blob/master/doc/tapscript_opcodes.md</a><br>5: <a h=
ref=3D"https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-May/020=
450.html" target=3D"_blank">https://lists.linuxfoundation.org/pipermail/bit=
coin-dev/2022-May/020450.html</a>=C2=A0<br></div></div>

--000000000000e905b605deacd6e8--