path: root/f0/b9d04413af5031d0a93e93771765b02c8a1b89

Return-Path: <antoine.riard@gmail.com>
Received: from smtp3.osuosl.org (smtp3.osuosl.org [140.211.166.136])
 by lists.linuxfoundation.org (Postfix) with ESMTP id 80EA5C000B
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Thu, 10 Jun 2021 21:16:58 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by smtp3.osuosl.org (Postfix) with ESMTP id 5EDEC6070C
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Thu, 10 Jun 2021 21:16:58 +0000 (UTC)
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level: 
X-Spam-Status: No, score=-2.098 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_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 1lWD8K_eBG2D
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Thu, 10 Jun 2021 21:16:57 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.8.0
Received: from mail-wr1-x42a.google.com (mail-wr1-x42a.google.com
 [IPv6:2a00:1450:4864:20::42a])
 by smtp3.osuosl.org (Postfix) with ESMTPS id 1F29D60631
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Thu, 10 Jun 2021 21:16:56 +0000 (UTC)
Received: by mail-wr1-x42a.google.com with SMTP id f2so3760650wri.11
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Thu, 10 Jun 2021 14:16:56 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
 h=mime-version:references:in-reply-to:from:date:message-id:subject:to
 :cc; bh=rvfJqm/yGYlYgvWb8AfcRXZeZ+nlN42Fpi3t2GWGHVI=;
 b=BsIP/nSXPhswiwtmaN5a3S1Sloa/H3jdyiDtpFb48oC2wrYdZHhSWPpMCbn2em6k+6
 0hAvZ2RiqdRlACet0ax+8fZORGxlDJQFXmT8pmtDEaMxU/OOjNZ4gWdMYuG28uxzKRj6
 TKiVnMC3ILg62jiHGOmZ4frRqbJrl9ORPooxQcgHZ8UChaPp/FEAYefRUyxUWD9A76MX
 PJqh84ebm/w1hxk/vUmNaRFRYTni4MxMMcA6GqowZ8epF9wvN6kqe+yp6uPmSdkOCxwf
 4RZQcitmfi32lb940KHbaBV4kguc9dsfonTn1XXD7xlC5HXXrSwb1p8ckYPmRL44Orvc
 SlSg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20161025;
 h=x-gm-message-state:mime-version:references:in-reply-to:from:date
 :message-id:subject:to:cc;
 bh=rvfJqm/yGYlYgvWb8AfcRXZeZ+nlN42Fpi3t2GWGHVI=;
 b=SzAFxa4DY8NGkiWY7BTR8r39CuDj1rHUdC3GuUpRqNCQM7VOKIVa2TqtRHVYH4mhXO
 yzex9FiF8NlbmuFbHvXpHuf5BWFlVtvRYvEFE9XSzYYY4Omx+qDbvVskzgbUwXeLcSI+
 nB8JRQXWG5jSo/HPy+fRYCk5acyckrp1tvk+bLiVi0ASe/b8AEZqXuce9mz4IV5QPgS3
 JTmFzS+v7ee+vWwe2j0QhmdfsiHVuQKZBkcThxIFr5SjL2pUyOgzYLEMHlUpEnhz5NLc
 NWuzu/iIuh68FX3v6gcpiX8K8hQZlUCIvLis0SpqgVBDIykLh6M+d1s20FJD7ElGc4sC
 hUDQ==
X-Gm-Message-State: AOAM5300CTGzlU8d7MoETPkuQBv+T30UONcPMRmWWZvN7I6+t+pSMo+n
 PUc4rGEymlJVd1gOsWwklviDiMpCj8L4mttT/ktdf4iHwmA=
X-Google-Smtp-Source: ABdhPJySuLxWk2VR9rRDz7ZTfkHI35qJpkBkTsbfKm3DpED7ZwnSQaAMHU+zUpixsaY0N2i8sIievg/0NuLv6+nrwnk=
X-Received: by 2002:adf:a15c:: with SMTP id r28mr424687wrr.224.1623359815162; 
 Thu, 10 Jun 2021 14:16:55 -0700 (PDT)
MIME-Version: 1.0
References: <CALZpt+FvLb=N5Qygs+dPmh1o9QCwXj8RoznF5n47opOq7CG_0g@mail.gmail.com>
 <sfryINjjAWF5hDSvohEhqCl2nBlllag5nA9tiPleUb1HyjmBcb6Y6v7VwIfaHVXfyiXAHGAgQfbwNsIz8dvckOSjV-zxaq7DckjHStYPJZU=@protonmail.com>
 <CALZpt+G3cVam9oJRHA=11j9k7k4Fo99dP39P4pbWeHfh79Xs-g@mail.gmail.com>
 <v4UrF63P8_Mvu9QiyP4bK6zkfHpmLR0eT2gfckNnvA8cNjRr6hcCZMenJid7lNtUQgtI2NcxjfHuvgmRXCp0WQMqCh_Nwo2Xx7nHESvgogY=@protonmail.com>
In-Reply-To: <v4UrF63P8_Mvu9QiyP4bK6zkfHpmLR0eT2gfckNnvA8cNjRr6hcCZMenJid7lNtUQgtI2NcxjfHuvgmRXCp0WQMqCh_Nwo2Xx7nHESvgogY=@protonmail.com>
From: Antoine Riard <antoine.riard@gmail.com>
Date: Thu, 10 Jun 2021 17:16:43 -0400
Message-ID: <CALZpt+HZE7R6DcXcDr-A=HLJzotL__k-xAxuV5H0B9jfY3Y9xQ@mail.gmail.com>
To: darosior <darosior@protonmail.com>
Content-Type: multipart/alternative; boundary="00000000000020202305c46fe93d"
X-Mailman-Approved-At: Thu, 10 Jun 2021 21:44:08 +0000
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] A Stroll through Fee-Bumping Techniques :
 Input-Based vs Child-Pay-For-Parent
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: Thu, 10 Jun 2021 21:16:58 -0000

--00000000000020202305c46fe93d
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

> So something like
`or(and(pk(FB),pk(A)),and(pk(FB),pk(B)),and(pk(FB),pk(C)))` with each `or`
in their own leaf? I think it works, but only if the keys `A`, `B`, `C` are
"hot", as in available to the
fee-bumper. For Revault it means introducing a key for each watchtower in
the vaults descriptors, which is meh but technically feasible since they
are identified. This kinda break our replication
model though. On the other end for Lightning... You'd need to know what
watchtower (or your node) is going to be willing to feebump? The descriptor
can very quickly get very convoluted:
`or(and(pk(FB),pk(A_NODE)),and(pk(FB),pk(A_WT1)),and(pk(FB),pk(A_WT2)),and(=
pk(FB),pk(B_NODE)),and(pk(FB),pk(B_WT1)),and(pk(FB),pk(B_WT2)))`
for only 2 participants in a channel
where one of either the node or two watchtowers (identified beforehand !!)
can feebump.

I'm not sure if we agree on the purpose of the finalizing key ? Its goal is
to finalize the transaction state once another fee-bumping input has been
attached and should be part of the witnessScript of the "main" input. If a
third-party try to attach a malicious pinning input, doing so breaks the
finalizing signature and the transaction will be rejected as invalid by
network mempools.

This key doesn't secure funds and as such can be shared to any fee-bumper
entity (contract source, sourced towers, outsourced towers ?). Of course,
it means an outsourced tower can re-introduce malicious transaction
malleability but at least it's moving away malleability from the
contract-level and it's now a holder tower policy decision ?

Overall I agree any fee-bumping techniques comparison should also account
tower key management complexity (and this one was missing).

> Yes. That's a bit concerning, but i guess it's a tradeoff. Amusingly the
incentive is at odds with routing: you want to keep your channels
unbalanced if you run on fractional fee-bumping reserves
so that if things go south you can still salvage most of your funds by
focusing your fee-bumping on the unbalanced (to you) channels :p .

That's a good point! Switching to anchor now rebalances a security matter,
not sure if it was an intended effect of the design :) Also, you might take
HTLC forwarding acceptance decisions holistically instead of a per-channel
level. If your number of HTLC in-flight expressed as outputs on one
commitment transaction goes up, don't accept anymore HTLC on other
channels, otherwise, you might run short of fee-bumping reserve...

Le ven. 28 mai 2021 =C3=A0 18:25, darosior <darosior@protonmail.com> a =C3=
=A9crit :

>
> Oh yes, I should have mentioned this pinning vector. The witnessScript
> I've in mind to make secure that type of chain of transactions would be o=
ne
> MuSig key for all contract participants, where signature are committed wi=
th
> SIGHASH_ANYPREVOUT | SIGHASH_IOMAP, one pubkey per participant to lockdow=
n
> the transaction with SIGHASH_ALL. I think it works and prevents malicious
> in-flight attachment of input/output to a multi-party transaction ?
>
>
> So something like
> `or(and(pk(FB),pk(A)),and(pk(FB),pk(B)),and(pk(FB),pk(C)))` with each `or=
`
> in their own leaf? I think it works, but only if the keys `A`, `B`, `C` a=
re
> "hot", as in available to the
> fee-bumper. For Revault it means introducing a key for each watchtower in
> the vaults descriptors, which is meh but technically feasible since they
> are identified. This kinda break our replication
> model though. On the other end for Lightning... You'd need to know what
> watchtower (or your node) is going to be willing to feebump? The descript=
or
> can very quickly get very convoluted:
> `or(and(pk(FB),pk(A_NODE)),and(pk(FB),pk(A_WT1)),and(pk(FB),pk(A_WT2)),an=
d(pk(FB),pk(B_NODE)),and(pk(FB),pk(B_WT1)),and(pk(FB),pk(B_WT2)))`
> for only 2 participants in a channel
> where one of either the node or two watchtowers (identified beforehand !!=
)
> can feebump.
>
> I see, so you spread your bumping UTXO pool in two ranges : at least one
> bumping utxo per contract, and a subpool of emergency smaller coins, read=
y
> to be attached on any contract. I think this strategy makes sense for
> vaults as you can afford a bunch of small coins at different feerates,
> spending the ones not used afterwards. And higher cells of feerate reserv=
e
> as the worst historical feerate are relatively not that much compared to
> locked-in vaults value. That said, I'm more dubious about LN, where node
> operators might not keep the worst-case fee-bumping reserve, as the time
> value of the coins aren't worth the channel liquidity at stake.
>
>
> Yes. That's a bit concerning, but i guess it's a tradeoff. Amusingly the
> incentive is at odds with routing: you want to keep your channels
> unbalanced if you run on fractional fee-bumping reserves
> so that if things go south you can still salvage most of your funds by
> focusing your fee-bumping on the unbalanced (to you) channels :p .
>
> Yes, input-based bumping targeting the tail of the chain works at the
> transaction level. But if you assume bounded visibility of network
> mempools, one of your counterparties might have broadcast a concurrent
> state, thus making your CPFP irrelevant for propagation. Though smarter
> tx-relay techniques such as "attach-on-contract-utxo-root" CPFP (or also
> known as "blinded CPFP") might solve this issue.
>
>
> Oh, yes, good point.
>

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

<div dir=3D"ltr">&gt; So something like `or(and(pk(FB),pk(A)),and(pk(FB),pk=
(B)),and(pk(FB),pk(C)))` with each `or` in their own leaf? I think it works=
, but only if the keys `A`, `B`, `C` are &quot;hot&quot;, as in available t=
o the<br>fee-bumper. For Revault it means introducing a key for each watcht=
ower in the vaults descriptors, which is meh but technically feasible since=
 they are identified. This kinda break our replication<br>model though. On =
the other end for Lightning... You&#39;d need to know what watchtower (or y=
our node) is going to be willing to feebump? The descriptor can very quickl=
y get very convoluted:<br>`or(and(pk(FB),pk(A_NODE)),and(pk(FB),pk(A_WT1)),=
and(pk(FB),pk(A_WT2)),and(pk(FB),pk(B_NODE)),and(pk(FB),pk(B_WT1)),and(pk(F=
B),pk(B_WT2)))` for only 2 participants in a channel<br>where one of either=
 the node or two watchtowers (identified beforehand !!) can feebump.<br><br=
>I&#39;m not sure if we agree on the purpose of the finalizing key ? Its go=
al is to finalize the transaction state once another fee-bumping input has =
been attached and should be part of the witnessScript of the &quot;main&quo=
t; input. If a third-party try to attach a malicious pinning input, doing s=
o breaks the finalizing signature and the transaction will be rejected as i=
nvalid by network mempools.<br><br>This key doesn&#39;t secure funds and as=
 such can be shared to any fee-bumper entity (contract source, sourced towe=
rs, outsourced towers ?). Of course, it means an outsourced tower can re-in=
troduce malicious transaction malleability but at least it&#39;s moving awa=
y malleability from the contract-level and it&#39;s now a holder tower poli=
cy decision ?<br><br>Overall I agree any fee-bumping techniques comparison =
should also account tower key management complexity (and this one was missi=
ng).<br><br>&gt; Yes. That&#39;s a bit concerning, but i guess it&#39;s a t=
radeoff. Amusingly the incentive is at odds with routing: you want to keep =
your channels unbalanced if you run on fractional fee-bumping reserves<br>s=
o that if things go south you can still salvage most of your funds by focus=
ing your fee-bumping on the unbalanced (to you) channels :p .<br><br>That&#=
39;s a good point! Switching to anchor now rebalances a security matter, no=
t sure if it was an intended effect of the design :) Also, you might take H=
TLC forwarding acceptance decisions holistically instead of a per-channel l=
evel. If your number of HTLC in-flight expressed as outputs on one commitme=
nt transaction goes up, don&#39;t accept anymore HTLC on other channels, ot=
herwise, you might run short of fee-bumping reserve...<br></div><br><div cl=
ass=3D"gmail_quote"><div dir=3D"ltr" class=3D"gmail_attr">Le=C2=A0ven. 28 m=
ai 2021 =C3=A0=C2=A018:25, darosior &lt;<a href=3D"mailto:darosior@protonma=
il.com">darosior@protonmail.com</a>&gt; a =C3=A9crit=C2=A0:<br></div><block=
quote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1=
px solid rgb(204,204,204);padding-left:1ex"><div><br></div><blockquote type=
=3D"cite"><div dir=3D"ltr"><div>Oh yes, I should have mentioned this pinnin=
g vector. The witnessScript I&#39;ve in mind to make secure that type of ch=
ain of transactions would be one MuSig key for all contract participants, w=
here signature are committed with SIGHASH_ANYPREVOUT | SIGHASH_IOMAP, one p=
ubkey per participant to lockdown the transaction with SIGHASH_ALL. I think=
 it works and prevents malicious in-flight attachment of input/output to a =
multi-party transaction ?<br></div></div></blockquote><div><br></div><div>S=
o something like `or(and(pk(FB),pk(A)),and(pk(FB),pk(B)),and(pk(FB),pk(C)))=
` with each `or` in their own leaf? I think it works, but only if the keys =
`A`, `B`, `C` are &quot;hot&quot;, as in available to the<br></div><div>fee=
-bumper. For Revault it means introducing a key for each watchtower in the =
vaults descriptors, which is meh but technically feasible since they are id=
entified. This kinda break our replication<br></div><div>model though. On t=
he other end for Lightning... You&#39;d need to know what watchtower (or yo=
ur node) is going to be willing to feebump? The descriptor can very quickly=
 get very convoluted:<br></div><div><div>`or(and(pk(FB),pk(A_NODE)),and(pk(=
FB),pk(A_WT1)),and(pk(FB),pk(A_WT2)),and(pk(FB),pk(B_NODE)),and(pk(FB),pk(B=
_WT1)),and(pk(FB),pk(B_WT2)))` for only 2 participants in a channel<br></di=
v><div>where one of either the node or two   watchtowers (identified before=
hand !!) can feebump.<br></div></div><div><br></div><blockquote type=3D"cit=
e"><div dir=3D"ltr"><div>I see, so you spread your bumping UTXO pool in two=
 ranges : at least one bumping utxo per contract, and a subpool of emergenc=
y smaller coins, ready to be attached on any contract. I think this strateg=
y makes sense for vaults as you can afford a bunch of small coins at differ=
ent feerates, spending the ones not used afterwards. And higher cells of fe=
erate reserve as the worst historical feerate are relatively not that much =
compared to locked-in vaults value. That said, I&#39;m more dubious about L=
N, where node operators might not keep the worst-case fee-bumping reserve, =
as the time value of the coins aren&#39;t worth the channel liquidity at st=
ake.<br></div></div></blockquote><div><br></div><div>Yes. That&#39;s a bit =
concerning, but i guess it&#39;s a tradeoff. Amusingly the incentive is at =
odds with routing: you want to keep your channels unbalanced if you run on =
fractional fee-bumping reserves<br>so that if things go south you can still=
 salvage most of your funds by focusing your fee-bumping on the unbalanced =
(to you) channels :p .<br></div><div><br></div><blockquote type=3D"cite"><d=
iv dir=3D"ltr"><div>Yes, input-based bumping targeting the tail of the chai=
n works at the transaction level. But if you assume bounded visibility of n=
etwork mempools, one of your counterparties might have broadcast a concurre=
nt state, thus making your CPFP irrelevant for propagation. Though smarter =
tx-relay techniques such as &quot;attach-on-contract-utxo-root&quot; CPFP (=
or also known as &quot;blinded CPFP&quot;) might solve this issue.<br></div=
></div></blockquote><div><br></div><div>Oh, yes, good point.<br></div></blo=
ckquote></div>

--00000000000020202305c46fe93d--