From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from silver.osuosl.org (smtp3.osuosl.org [140.211.166.136]) by lists.linuxfoundation.org (Postfix) with ESMTP id 2F2BCC004D for ; 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 ; 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 ; 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 ; Wed, 29 Jul 2020 20:17:28 +0000 (UTC) Received: by mail-wm1-f53.google.com with SMTP id p14so3839602wmg.1 for ; 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 Date: Wed, 29 Jul 2020 16:17:11 -0400 Message-ID: To: Bitcoin Protocol Discussion 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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
Hi list,

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.

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

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.
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.

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.

### Effective Transaction P= ropagation 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 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, ...)
=
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'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].

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'= ;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'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).

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.

Therefore, moving towards su= ch stable tx-relay/bumping API, I propose:
a) Identifying and documentin= g the subset of policy rules on which upper layers have to rely on to enfor= ce their security model
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 ?)

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.

### Adver= sarial Fee Bumping and Package Relay

Assuming anchor-output gets ado= pted & deployed, even beyond LN, it doesn'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.

T= his has consequences both for network nodes, the ones with small mempools w= on't discover the best feerate bid, which false their fee-estimator and= for CPFP users, their feerate bump having chances to fail. It'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].

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.

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'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'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 t= rustworthy propagation/fee bumping API [3]

I'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.

Ch= eers,

Antoine

[0] E.g https://lists.linuxfounda= tion.org/pipermail/bitcoin-dev/2020-May/017883.html or=C2=A0 https://github.com/bitcoi= n/bitcoin/issues/13283 when policy break your broadcast

[1] Agai= n this is not a LN specific issue, timelocked vaults have the same issue
[2] https://github.com/t-bast/lightning-docs/blob/master/pinn= ing-attacks.md

[3] In fact these requirements aren'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
--0000000000005ee20305ab9a3edf--