path: root/3c/5b1f0d0f325cf4d29c6e033611127298a554ca

Return-Path: <antoine.riard@gmail.com>
Received: from silver.osuosl.org (smtp3.osuosl.org [140.211.166.136])
 by lists.linuxfoundation.org (Postfix) with ESMTP id 2F2BCC004D
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Wed, 29 Jul 2020 20:17:31 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by silver.osuosl.org (Postfix) with ESMTP id 18B9020503
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Wed, 29 Jul 2020 20:17:31 +0000 (UTC)
X-Virus-Scanned: amavisd-new at osuosl.org
Received: from silver.osuosl.org ([127.0.0.1])
 by localhost (.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
 with ESMTP id TOEpO9B-Pd6p
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Wed, 29 Jul 2020 20:17:28 +0000 (UTC)
X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6
Received: from mail-wm1-f53.google.com (mail-wm1-f53.google.com
 [209.85.128.53])
 by silver.osuosl.org (Postfix) with ESMTPS id 904B1203D3
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Wed, 29 Jul 2020 20:17:28 +0000 (UTC)
Received: by mail-wm1-f53.google.com with SMTP id p14so3839602wmg.1
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Wed, 29 Jul 2020 13:17:28 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
 h=mime-version:from:date:message-id:subject:to;
 bh=dR+xXPdqi1vt+Ds8geoove/Zfyo5e4XzMrpzB2gU6cg=;
 b=HNZ2vy1psVm8pAoerAqcC55R418tSqnbZFd14HQUQIIsk8QrDRAwPC26nH0m3isZMM
 o1h2ZXInZ0ao/gCgO6MMir+sOH7AxoGiJuOakUjm7QXad2ZFZmsGGzuctYcb/Ish9DZR
 Z7kMO99nBoufiv6T8KwVcpXCP3D+4VRVErUhF/OOsZmrMR2kW2briGUXT9iyEj4noq24
 JjLfynWyPwfmye4nfmfv+1RDpIjPeoggy0Sxu6XGBlLvWimJmiLGIXNEmlKjReyu4mfk
 HReyK8NHDAyaPKuzkNcWey+qXzHQKnLm0C99H094tD1bnA6g3NqgBLfAWRSK2sg1eI2p
 Jewg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20161025;
 h=x-gm-message-state:mime-version:from:date:message-id:subject:to;
 bh=dR+xXPdqi1vt+Ds8geoove/Zfyo5e4XzMrpzB2gU6cg=;
 b=FucwvujDCgUtFTxUbPnBvPGt2BLx/Q5YLn/DiqmZ+DsI1yhAKbAjJaBLdvFiqr0zXe
 qD/sWCSUF4HavZkyTUKET4xCruRP8nhD/2toY5yoom2kYPgd1A2Axbm4h4wHd4XbEiFW
 rve+lvmtd+jmxq4aaIqvxBs+C/tQGJktjgY32Mlhb1j5sTQHIrATnGLlJeQ83Z6I8XRw
 DGzZpNNjWTcn4lOxDqy+foL+RgUchCvcCK72SjBTY7QkbFyLWk9jT3sLPwcR+tPPgryh
 T+aePC36jJ22Z7GqF8DHWPGpGSKH0DyNYri2SItDq9oBqZMqdn9p10OOJ6TU7/XkLORi
 Xsxw==
X-Gm-Message-State: AOAM5339763zRIn8ubCkV6WS++GbiZFtS6yaODxB4uQuJ+BAAZa2+pV1
 enHn9fXl0vhEG88NRDweeGVIitZuLiaasBirvbTnHaR3
X-Google-Smtp-Source: ABdhPJznUWBM4Rzz2VpQEblzoHrl2jjDZJhynetv9XTSJ5HH/RZYRu5Z53RtCkCSkkOuvhkeM6TPVyzBPLJetcX10Xg=
X-Received: by 2002:a1c:2dcb:: with SMTP id t194mr2237055wmt.94.1596053843270; 
 Wed, 29 Jul 2020 13:17:23 -0700 (PDT)
MIME-Version: 1.0
From: Antoine Riard <antoine.riard@gmail.com>
Date: Wed, 29 Jul 2020 16:17:11 -0400
Message-ID: <CALZpt+GKiHKxNVPkmegqDbwLok=7Th-j1E4C_HrUgs46gJAZjw@mail.gmail.com>
To: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary="0000000000005ee20305ab9a3edf"
X-Mailman-Approved-At: Wed, 29 Jul 2020 21:20:35 +0000
Subject: [bitcoin-dev] Advances in Bitcoin Contracting : Uniform Policy and
	Package Relay
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: Wed, 29 Jul 2020 20:17:31 -0000

--0000000000005ee20305ab9a3edf
Content-Type: text/plain; charset="UTF-8"

Hi list,

Security and operations of higher-layer protocols (vaults, LN, CoinJoin,
watchtowers, ...) come with different assumptions and demands with regards
to tx-relay and fee models. As the Bitcoin stack is quite young, it would
be great to make those ones more understood and what p2p/mempool changes we
might adopt at the base layer to better answer them. I would like to
explore this with my current post.

### Time-Sensitive Protocols Security-Model (you can skip this if you know
LN)

Lightning, the most deployed time-sensitive protocol as of now, relies on
the timely confirmations of some of its transactions to enforce its
security model. Like timing out an outgoing HTLC, claiming an incoming HTLC
or punishing a revoked commitment. Ensuring timely confirmation is
two-fold: a) propagating well-transactions across the network to quickly
hit miner mempools b) offering a competitive feerate to get in next coming
blocks.

Updating feerate just-in-time is quite challenging for LN as you can't
resign a commitment once your counterparty is non-responsive or malicious,
and thus any fee strategy assuming interactivity is closed. With current
constraints of maintaining a trustless chain of transactions (no
Parent-Pay-For-Child), the only option is a CPFP. Ongoing update of LN
protocol (anchor-outputs) will allow a channel participant to unilaterally
bump feerate of its commitment/HTLCs txn, assuming there is no
_adversarial_ network mempool conditions like a concurrent broadcast.

Beyond enforcing the need to secure its funds by bumping feerate, an
offchain user might be willingly to accelerate confirmation of a broadcast
for liquidity management in face of mempool-congestion. This issue is
likely shared by any multi-party protocol like Coinjoins where resigning is
painful and a party may have different liquidity preferences than other
participants and would like to express them in an unilateral fee bumping.

### Effective Transaction Propagation and Uniform Relay Policy

Even before competing on feerate, the first and foremost point of the
laid-out security model was the well-propagation of transactions across the
p2p network. Its effectiveness is determined by compliance to 1) consensus
rules 2) policy rules. This second set is a tighter one governing different
aspects of your transactions (like size, output type, feerate,
ancestors/descendants, ...) and introduced to sanitize the p2p network
against a wide scope of resources abuses (RBF bandwidth waste, package
evaluation CPU DoS, economic nonsense outputs, ...)

These rules diverge across implementations/versions and a subset of them
can be tightened or relaxed by node operators. This heterogeneity is
actually where the risk is scored for higher protocols, your LN's full-node
might be connected to tx-relay peers with more constraining policies than
yours and thus will always reject your time-sensitive transactions,
silently breaking security of your channels [0].

Of course, LN protocols devs have always been aware of these issues and
carefully reflect policies enforcement in their codebase. That said an
important subset of them aren't documented or even standardized and thus
hard to incorporate in upper layers specs. Testing them in a black box
approach (i.e `testmempoolaccept`) before production doesn't work as your
broadcast has to be valid against the union of your yet-unknown tx-relay
topology, further static checks are blurred with dynamic ones (the feerate
now is different than the one at a future broadcast), and your transaction
might be malleate by your counterparty (like a ridiculous feerate).

And the other side, AFAIK, Core developers have always acknowledged these
issues and been really conscientious when updating such API policy. The
concerning change with protocol like LN is the severity consequences in
case of incompatible changes. Previously, your basic transaction would have
been rejected by the network and your application could have been updated
before successfully rebroadcasting. Now, such changes potentially outlawing
your time-sensitive broadcasts is a direct, measurable risk of fund loss,
either triggered by mempool-congestion or exploited by a malicious
counterparty.

Therefore, moving towards such stable tx-relay/bumping API, I propose:
a) Identifying and documenting the subset of policy rules on which upper
layers have to rely on to enforce their security model
b) Guaranteeing backward-compatibility of those rules or, in case of
tightening change, making sure there is ecosystem coordination with some
minimal warning period (1 release ?)

Committing to a uniform policy would be a philosophical change, it would
ossify some parts of full-node implementations. Another side-effect means
that upper layer devs would be incentivized to rely on such stable API. In
case of new DoS on the base layer, we might have to tighten them in a short
timeline at the price of breaking some offchain applications [1] On the
other side, full-node operators have an interest to follow such uniform
policy, as it would improve the effective feerate discovery by their
mempools.

### Adversarial Fee Bumping and Package Relay

Assuming anchor-output gets adopted & deployed, even beyond LN, it doesn't
guarantee success of CPFP, where success is defined as letting know the
network mempools of your fee-bid, confirmation being always a function of
concurrent fee-bids from other users. Indeed, if it allows bump at the
transaction-level, there is no guarantee of enforcement at the tx-relay
layer. Mempool acceptance for any transaction is done on its own, a
low-feerate parent can be rejected while a high-feerate child might have to
follow fews microseconds later.

This has consequences both for network nodes, the ones with small mempools
won't discover the best feerate bid, which false their fee-estimator and
for CPFP users, their feerate bump having chances to fail. It's specially
concerning for LN where concurrent broadcast for the same utxo can be
leveraged by a counterparty to steal channel funds. A class of attacks
known as pinning achievable today [2].

Solving this means likely deploying a package relay, an old known
proposition to evaluate the feerate of a whole chain of transactions to
decide their mempool acceptance. Ensuring package relay effectiveness means
making it part of such uniform policy laid out above, thus providing a
censorship-resistant, reliable highway across the p2p network to always
increase feerate of your blockspace bids. It will force a pinning attacker
to enter in a feerate competition with the honest party to maintain the
pin, thus cancelling the threat.

Package relay design is also pending on bumping patterns. Ideally if a LN
hub is closing multiple channels at the same time, you should be able to
spread one CPFP on multiple parents, which is an increase of DoS surface
for the mempol. Also package relay might be the default broadcast policy by
LN nodes for unilateral broadcast, as you can't dissociate if your
transaction is stucking due to congestion or an ongoing pinning without
global view of network mempools. In the future, if LN broadcasts account
for an honest share of the whole tx-relay, it won't be free bandwidth-wise.


To conclude, upper layers of the Bitcoin stack require that single
full-nodes behave in a homogeneous way such that the base network as a
whole system provide a trustworthy propagation/fee bumping API [3]

I'm eager to get feedback on any subject introduced here, especially the
uniform policy proposal which is really worthy of discussion and
controversial for sure.

Cheers,

Antoine

[0] E.g
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2020-May/017883.html
or  https://github.com/bitcoin/bitcoin/issues/13283 when policy break your
broadcast

[1] Again this is not a LN specific issue, timelocked vaults have the same
issue

[2] https://github.com/t-bast/lightning-docs/blob/master/pinning-attacks.md

[3] In fact these requirements aren't specifics from the _new_ upper-layer
Bitcoin stack but a fundamental assumption made by anything using
timelocks/concurrent states, i.e also old-school 2013 payment channels
designs

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

<div dir=3D"ltr"><div>Hi list,<br><br>Security and operations of higher-lay=
er protocols (vaults, LN, CoinJoin, watchtowers, ...) come with different a=
ssumptions and demands with regards to tx-relay and fee models. As the Bitc=
oin stack is quite young, it would be great to make those ones more underst=
ood and what p2p/mempool changes we might adopt at the base layer to better=
 answer them. I would like to explore this with my current post.<br><br>###=
 Time-Sensitive Protocols Security-Model (you can skip this if you know LN)=
<br><br>Lightning, the most deployed time-sensitive protocol as of now, rel=
ies on the timely confirmations of some of its transactions to enforce its =
security model. Like timing out an outgoing HTLC, claiming an incoming HTLC=
 or punishing a revoked commitment. Ensuring timely confirmation is two-fol=
d: a) propagating well-transactions across the network to quickly hit miner=
 mempools b) offering a competitive feerate to get in next coming blocks.<b=
r><br>Updating feerate just-in-time is quite challenging for LN as you can&=
#39;t resign a commitment once your counterparty is non-responsive or malic=
ious, and thus any fee strategy assuming interactivity is closed. With curr=
ent constraints of maintaining a trustless chain of transactions (no Parent=
-Pay-For-Child), the only option is a CPFP. Ongoing update of LN protocol (=
anchor-outputs) will allow a channel participant to unilaterally bump feera=
te of its commitment/HTLCs txn, assuming there is no _adversarial_ network =
mempool conditions like a concurrent broadcast.<br><br>Beyond enforcing the=
 need to secure its funds by bumping feerate, an offchain user might be wil=
lingly to accelerate confirmation of a broadcast for liquidity management i=
n face of mempool-congestion. This issue is likely shared by any multi-part=
y protocol like Coinjoins where resigning is painful and a party may have d=
ifferent liquidity preferences than other participants and would like to ex=
press them in an unilateral fee bumping.<br><br>### Effective Transaction P=
ropagation and Uniform Relay Policy<br><br>Even before competing on feerate=
, the first and foremost point of the laid-out security model was the well-=
propagation of transactions across the p2p network. Its effectiveness is de=
termined by compliance to 1) consensus rules 2) policy rules. This second s=
et is a tighter one governing different aspects of your transactions (like =
size, output type, feerate, ancestors/descendants, ...) and introduced to s=
anitize the p2p network against a wide scope of resources abuses (RBF bandw=
idth waste, package evaluation CPU DoS, economic nonsense outputs, ...)<br>=
<br>These rules diverge across implementations/versions and a subset of the=
m can be tightened or relaxed by node operators. This heterogeneity is actu=
ally where the risk is scored for higher protocols, your LN&#39;s full-node=
 might be connected to tx-relay peers with more constraining policies than =
yours and thus will always reject your time-sensitive transactions, silentl=
y breaking security of your channels [0].<br><br>Of course, LN protocols de=
vs have always been aware of these issues and carefully reflect policies en=
forcement in their codebase. That said an important subset of them aren&#39=
;t documented or even standardized and thus hard to incorporate in upper la=
yers specs. Testing them in a black box approach (i.e `testmempoolaccept`) =
before production doesn&#39;t work as your broadcast has to be valid agains=
t the union of your yet-unknown tx-relay topology, further static checks ar=
e blurred with dynamic ones (the feerate now is different than the one at a=
 future broadcast), and your transaction might be malleate by your counterp=
arty (like a ridiculous feerate).<br><br>And the other side, AFAIK, Core de=
velopers have always acknowledged these issues and been really conscientiou=
s when updating such API policy. The concerning change with protocol like L=
N is the severity consequences in case of incompatible changes. Previously,=
 your basic transaction would have been rejected by the network and your ap=
plication could have been updated before successfully rebroadcasting. Now, =
such changes potentially outlawing your time-sensitive broadcasts is a dire=
ct, measurable risk of fund loss, either triggered by mempool-congestion or=
 exploited by a malicious counterparty.<br><br>Therefore, moving towards su=
ch stable tx-relay/bumping API, I propose:<br>a) Identifying and documentin=
g the subset of policy rules on which upper layers have to rely on to enfor=
ce their security model<br>b) Guaranteeing backward-compatibility of those =
rules or, in case of tightening change, making sure there is ecosystem coor=
dination with some minimal warning period (1 release ?)<br><br>Committing t=
o a uniform policy would be a philosophical change, it would ossify some pa=
rts of full-node implementations. Another side-effect means that upper laye=
r devs would be incentivized to rely on such stable API. In case of new DoS=
 on the base layer, we might have to tighten them in a short timeline at th=
e price of breaking some offchain applications [1] On the other side, full-=
node operators have an interest to follow such uniform policy, as it would =
improve the effective feerate discovery by their mempools.<br><br>### Adver=
sarial Fee Bumping and Package Relay<br><br>Assuming anchor-output gets ado=
pted &amp; deployed, even beyond LN, it doesn&#39;t guarantee success of CP=
FP, where success is defined as letting know the network mempools of your f=
ee-bid, confirmation being always a function of concurrent fee-bids from ot=
her users. Indeed, if it allows bump at the transaction-level, there is no =
guarantee of enforcement at the tx-relay layer. Mempool acceptance for any =
transaction is done on its own, a low-feerate parent can be rejected while =
a high-feerate child might have to follow fews microseconds later.<br><br>T=
his has consequences both for network nodes, the ones with small mempools w=
on&#39;t discover the best feerate bid, which false their fee-estimator and=
 for CPFP users, their feerate bump having chances to fail. It&#39;s specia=
lly concerning for LN where concurrent broadcast for the same utxo can be l=
everaged by a counterparty to steal channel funds. A class of attacks known=
 as pinning achievable today [2].<br><br>Solving this means likely deployin=
g a package relay, an old known proposition to evaluate the feerate of a wh=
ole chain of transactions to decide their mempool acceptance. Ensuring pack=
age relay effectiveness means making it part of such uniform policy laid ou=
t above, thus providing a censorship-resistant, reliable highway across the=
 p2p network to always increase feerate of your blockspace bids. It will fo=
rce a pinning attacker to enter in a feerate competition with the honest pa=
rty to maintain the pin, thus cancelling the threat.<br><br>Package relay d=
esign is also pending on bumping patterns. Ideally if a LN hub is closing m=
ultiple channels at the same time, you should be able to spread one CPFP on=
 multiple parents, which is an increase of DoS surface for the mempol. Also=
 package relay might be the default broadcast policy by LN nodes for unilat=
eral broadcast, as you can&#39;t dissociate if your transaction is stucking=
 due to congestion or an ongoing pinning without global view of network mem=
pools. In the future, if LN broadcasts account for an honest share of the w=
hole tx-relay, it won&#39;t be free bandwidth-wise.<br><br><br>To conclude,=
 upper layers of the Bitcoin stack require that single full-nodes behave in=
 a homogeneous way such that the base network as a whole system provide a t=
rustworthy propagation/fee bumping API [3]<br><br>I&#39;m eager to get feed=
back on any subject introduced here, especially the uniform policy proposal=
 which is really worthy of discussion and controversial for sure.<br><br>Ch=
eers,<br><br>Antoine<br><br>[0] E.g <a href=3D"https://lists.linuxfoundatio=
n.org/pipermail/bitcoin-dev/2020-May/017883.html">https://lists.linuxfounda=
tion.org/pipermail/bitcoin-dev/2020-May/017883.html</a> or=C2=A0 <a href=3D=
"https://github.com/bitcoin/bitcoin/issues/13283">https://github.com/bitcoi=
n/bitcoin/issues/13283</a> when policy break your broadcast<br><br>[1] Agai=
n this is not a LN specific issue, timelocked vaults have the same issue<br=
><br>[2] <a href=3D"https://github.com/t-bast/lightning-docs/blob/master/pi=
nning-attacks.md">https://github.com/t-bast/lightning-docs/blob/master/pinn=
ing-attacks.md</a><br><br></div>[3] In fact these requirements aren&#39;t s=
pecifics from the _new_ upper-layer Bitcoin stack but a fundamental assumpt=
ion made by anything using timelocks/concurrent states, i.e also old-school=
 2013 payment channels designs<br></div>

--0000000000005ee20305ab9a3edf--