[bitcoin-dev] Waiting SIGHASH_ANYPREVOUT and Packing Packages

[bitcoin-dev] Waiting SIGHASH_ANYPREVOUT and Packing Packages

[Antoine Riard]

[-- Attachment #1: Type: text/plain, Size: 12504 bytes --]

Hi,

It's a big chunk, so if you don't have time browse parts 1 and 2 and share
your 2 sats on the deployment timeline :p

This post recalls some unsolved safety holes about Lightning, how
package-relay or SIGHASH_ANYPREVOUT can solve the first one, how a mempool
hardening can solve the second one, few considerations on package-relay
design trade-offs and propose a rough deployment timeline.

1) Lightning Safety Holes : Pre-Signed Feerate and Tx-Pinning (to skip if
you're a LN dev)

As of today, Lightning is suffering from 2 safety holes w.r.t to base-layer
interactions, widely discussed among ln devs.

The first one, the pre-signed feerate issue with future broadcasted
time-sensitive transactions is laid out clearly in Matt Corallo's "CPFP
Carve-Out Fee-Prediction Issues in Contracting Applications (eg Lightning)"
[0]. This issue might provoke loss of funds, even in non-adversarial
settings, i.e a Lightning routing hub not being able to settle backward
onchain a successful HTLC during occurrences of sudden mempool congestion.

As blockspace demand increases with an always growing number of
onchain/offchain bitcoin users, coupling effects are more likely to happen
and this pre-signed feerate issue is going to become more urgent to solve
[1]. For e.g, few percentiles of increases in feerate being overpriced by
Lightning routing hubs to close "fractional-reserve" backed anchor
channels, driving mempools congestions, provoking anchor channels
fee-bumping reserves becoming even more under-provisioned and thus close
down, etc.

The second issue, malicious transaction pinnings, is documented in Bastien
Teinturier's "Pinning Attacks" [2]. AFAIK, there is a rough consensus among
devs on the conceptual feasibility of such a class of attacks against a LN
node, though so far we have not seen them executed in the wild and I'm not
aware of anyone having realized them in real-world conditions. Note, there
is a variety of attack scenarios to consider which is function of a wide
matrix (channel types, LN implementation's `update_fee` policy, LN
implementation's `cltv_delta` policy, mempool congestion feerate groups,
routing hubs or end nodes) Demoing against deployed LN implementations with
default settings has been on my todo for a while, though a priori One
Scenario To Exploit Them All doesn't fit well.

Side-note, as a LN operator, if you're worried about those security risks,
you can bump your `cltv_delta`/`cltv_expiry_delta` to significantly coarse
the attacks.

I think there is an important point to underscore. Considering the state of
knowledge we have today, I believe there is no strong interdependency
between solving pre-signed feerate and tx-pinning with the same mechanism
from a safety/usability standpoint. Or last such mechanism can be deployed
by stages.

2) Solving the Pre-Signed Feerate problem : Package-Relay or
SIGHASH_ANYPREVOUT

For Lightning, either package-relay or SIGHASH_ANYPREVOUT should be able to
solve the pre-signed feerate issue [3]

One of the interesting points recalled during the first transaction relay
workshops was that L2s making unbounded security assumptions on
non-normative tx-relay/mempool acceptance rules sounds a wrong direction
for the Bitcoin ecosystem long-term, and more prone to subtle bugs/safety
risks across the ecosystem.

I did express the contrary, public opinion a while back [4]. That said, I
start to agree it's wiser ecosystem-wise to keep those non-normatives rules
as only a groundwork for weaker assumptions than consensus ones. Though it
would be nice for long-term L2s stability to consider them with more care
than today in our base-layer protocol development process [4]

On this rational, I now share the opinion it's better long-term to solve
the pre-signed feerate problem with a consensus change such as
SIGHASH_ANYPREVOUT rather than having too much off-chain coins relying on
the weaker assumptions offered by bitcoin core's tx-relay/mempool
acceptance rules, and far harder to replicate and disseminate across the
ecosystem.

However, if SIGHASH_ANYPREVOUT is Things Done Right(tm), should we discard
package-relay ?

Sadly, in the worst-case scenario we might never reach consensus again
across the ecosystem and Taproot is the last softfork. Ever :/ *sad violons
and tissues jingle*

With this dilemma in mind, it might be wise for the LN/L2 ecosystems to
have a fall-back plan to solve their safety/usability issues and
package-relay sounds a reasonable, temporary "patch".

Even if package-relay requires serious engineering effort in Bitcoin Core
to avoid introducing new DoSes, swallowing well the complexity increase in
critical code paths such as the mempool/p2p stack and a gentle API design
for our friends the L2 devs, I believe it's worthy the engineering
resources cost. From-my-completely-biased-LN-dev viewpoint :p

In the best-case scenario, we'll activate SIGHASH_ANYPREVOUT and better
fee-bumping primitives softforks [5] slowly strip off the "L2 fee-bumping
primitive" semantic from "package-relay", friendly nudge the L2 ecosystem
to seat their fee-bumping on safer, consensus assumptions and maybe keep
the p2p packages to improve on the malicious mempool-partitions-side or as
a replacement of our orphan logic.

3) Solving Tx-Pinnings : Hardening the Mempool against Tx-Relay Jammings
attacks

Current Mempool anti-DoS rules have been mostly designed at a time where
the shared-utxo model with competing time-sensitive transactions was still
an idea on the whiteboard. The last few years have revealed those anti-DoS
rules as a source of security vulnerabilities for Lightning and a research
concern for L2s still in the early-phase of deployment [6].

Beyond real-world pinning exercises against production software as a
complement of the current pinning attacks research, it would be better to
agree on a common L2 attacker model before to modify widely-relied subset
of the mempool, such as the replace-by-fee logic or the in-mempool package
limits [7]. One risk of uncareful changes in this area would be to solve a
pinning vector for a L2-alice but introduce a new vuln for a L2-bob.

I believe the first part of such a revamp could hopefully land somehow next
year. Though, IMHO, in the years to come, we'll have to do more hard
reasoning to ensure the mempool supports advanced Bitcoin protocols (e.g
OP_CTV congestion tree,  CoinPool, interactive cut-through, ...)

Note the opinion I raised above on quality of assumptions on mempool
behavior, even if we harden it on the base-layer side,  L2s should be
well-aware the product is shipped with a guarantee limitation :p

4) Considerations on Package-Relay Design

Package relay relies on at least two cleanly separate components (awesome,
if we schedule to deprecate the higher half in the future!)
* "the higher half" : extension of the mempool logic, with a new
package-level policy, not strictly intersecting with the tx-level policy
* "the lower half" : at least three different designs, receiver initiated,
sender-initiated and relay-initiated

One open design question for the "higher half" is the package-size of the
acceptance logic, which is ultimately a function of the L2 ecosystem state.
Do we have deployed or in deployment phase L2 protocols with a need for
more than 2-stage and if yes what API bounds do they expect ? That's a
question I hope we'll gather feedback during next Thursday's transaction
relay workshops. IMO, such package API should come out with a specification
on which L2-community can be gathered and public consensus established. For
the same communications reasons towards downstream projects, we have a
BIP125 standard. And especially in this case the bitcoin core protocol
development process should carefully listen to the needs of actual L2
users. Also, a lot of those L2 devs, they don't speak C++ :)

One could imagine those mempool standards as "perishable" contracts between
a base-layer implementation and the upper layers, with ultimately the
full-node implementation reserving itself the right to deprecate them,
maybe with a lengthy-warning period ?

Beyond that, I believe there is another remaining interdependency between
"the lower half" design and L2s behaviors, namely bandwidth waste in case
of a high-frequency of package redundancy. Let's say if a package is
composed of {A, B}, and the package broadcaster fee-bump, triggering the
transformation to {A, B'}, A bandwidth at first propagation is going to be
wasted. Note, if we assume a dynamic fee-market, this package rebroadcast
behavior should be common across the ecosystem. Though ultimately, the
seriousness of this issue is going to be a function of the number of
Lightning nodes relying on base-layer tx-relay and the number of fee-bumped
onchain operations per Lightning node.

I believe it would be great to come up with simulations on this front, just
to avoid silently nullifying all the tedious, small improvements which have
been done in the last years to minimize bitcoin core node's bandwidth.

Another alternative would be to come with a cost-effective
package-replacement policy, so likely more complexity. But might it not
make sense to not economically outlaw Lightning nodes with a small fee
budget ?

Lastly, there is a consideration to have around anti-DoS measures we'll
have to deploy for package-relay. Too easy, and that's a security concern
for the base-layer, too hard, and that's introducing yet-another tx-relay
jamming vector against L2, this time at the p2p layer (though won't be the
first time [8]

In any-case we should carefully consider the upgradeability of
package-relay v.0, like if we upgrade some components of it such as package
format or package-announcement scheme.

So yeah why not early 0.24 ? Maybe a bit too short with all those p2p
questions to clear up among core devs. Ideally, we would land in the
beginning/middle of the cycle to have time for beta-testing on the L2-side
and share feedback.

Though ultimately, this question of p2p design belongs to the bitcoin core
dev process.

# Deployment timeline

So what I believe as a rough deployment timeline.

* "package-relay" in bitcoin core, early 0.24 or 0.25: a Core's release
cycle offered to the LN/L2 ecosystem to integrate/exercise/provide feedback
on package API

* "mempool hardening" in bitcoin core, early 0.26 or 0.27, a Core's release
cycle offered to the whole Bitcoin ecosystem to adapt their Bitcoin
clients, maybe with a boolean setting to smooth the new policy deployment

* SIGHASH_ANYPREVOUT softfork in the coming year(s), opt-in of any LN/L2
implementation to migrate its fee-bumping backend on top of it

* "optimized/multi-party fee-bumping primitive" softfork (one of tx
mutation/sigash_iomap/sponsorship proposals) softfork in the coming decade,
friendly uplift of the L2 ecosystem

Glad to answer any unclarity or uncorrectness of mine :)

Cheers,
Antoine,

[0] see
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2018-November/016518.html

[1] "The Coupling Principle states that as things get larger, they often
exhibit increased interdependence between components".

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

[2] see "Advances in Bitcoin Contracting : Uniform Policy and Package
Relay"
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2020-July/018063.html

[3] I don't think there is a clear discussion on how SIGHASH_ANYPREVOUT
solves pinnings beyond those LN meetings logs:
https://gnusha.org/lightning-dev/2020-06-08.log

[4] And I believe such great example has been done with this recent change
proposed for bitcoin core addr-relay policy:
https://github.com/bitcoin/bitcoin/pull/21528#issuecomment-809906430, where
the PR author did bear the burden of reaching out potentially affected
downstream projects.

[5] Like one of tx_mutation/sighash_iomap/sponsorship proposal proposed in
the thread "A Stroll through Fee-Bumping Techniques: Input-based vs
Child-Pay-for-Parent" :
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-May/019031.html

[6] For a discussion about fee-bumping issues for L2s extended beyond LN
see the analysis of the Revault protocol :
https://arxiv.org/pdf/2102.09392.pdf

[7] As a WIP towards establishing an attacker model, see "Secure
Fee-Bumping for L2s"
https://bitcoin-problems.github.io/problems/fee-bumping.html

[8] Tx-relay rules as a concern for second-layers has been raised early on,
at least during p2p segwit review
https://github.com/bitcoin/bitcoin/issues/8279

[-- Attachment #2: Type: text/html, Size: 14039 bytes --]

Re: [bitcoin-dev] Waiting SIGHASH_ANYPREVOUT and Packing Packages

[Antoine Riard]

[-- Attachment #1: Type: text/plain, Size: 13530 bytes --]

> That's a question I hope we'll gather feedback during next Thursday's
transaction relay workshops.

As someone kindly pointed out to me, workshop is happening Tuesday, June
22th. Not Thursday, mistake of mine :/



Le ven. 18 juin 2021 à 18:11, Antoine Riard <antoine.riard@gmail.com> a
écrit :

> Hi,
>
> It's a big chunk, so if you don't have time browse parts 1 and 2 and share
> your 2 sats on the deployment timeline :p
>
> This post recalls some unsolved safety holes about Lightning, how
> package-relay or SIGHASH_ANYPREVOUT can solve the first one, how a mempool
> hardening can solve the second one, few considerations on package-relay
> design trade-offs and propose a rough deployment timeline.
>
> 1) Lightning Safety Holes : Pre-Signed Feerate and Tx-Pinning (to skip if
> you're a LN dev)
>
> As of today, Lightning is suffering from 2 safety holes w.r.t to
> base-layer interactions, widely discussed among ln devs.
>
> The first one, the pre-signed feerate issue with future broadcasted
> time-sensitive transactions is laid out clearly in Matt Corallo's "CPFP
> Carve-Out Fee-Prediction Issues in Contracting Applications (eg Lightning)"
> [0]. This issue might provoke loss of funds, even in non-adversarial
> settings, i.e a Lightning routing hub not being able to settle backward
> onchain a successful HTLC during occurrences of sudden mempool congestion.
>
> As blockspace demand increases with an always growing number of
> onchain/offchain bitcoin users, coupling effects are more likely to happen
> and this pre-signed feerate issue is going to become more urgent to solve
> [1]. For e.g, few percentiles of increases in feerate being overpriced by
> Lightning routing hubs to close "fractional-reserve" backed anchor
> channels, driving mempools congestions, provoking anchor channels
> fee-bumping reserves becoming even more under-provisioned and thus close
> down, etc.
>
> The second issue, malicious transaction pinnings, is documented in Bastien
> Teinturier's "Pinning Attacks" [2]. AFAIK, there is a rough consensus among
> devs on the conceptual feasibility of such a class of attacks against a LN
> node, though so far we have not seen them executed in the wild and I'm not
> aware of anyone having realized them in real-world conditions. Note, there
> is a variety of attack scenarios to consider which is function of a wide
> matrix (channel types, LN implementation's `update_fee` policy, LN
> implementation's `cltv_delta` policy, mempool congestion feerate groups,
> routing hubs or end nodes) Demoing against deployed LN implementations with
> default settings has been on my todo for a while, though a priori One
> Scenario To Exploit Them All doesn't fit well.
>
> Side-note, as a LN operator, if you're worried about those security risks,
> you can bump your `cltv_delta`/`cltv_expiry_delta` to significantly coarse
> the attacks.
>
> I think there is an important point to underscore. Considering the state
> of knowledge we have today, I believe there is no strong interdependency
> between solving pre-signed feerate and tx-pinning with the same mechanism
> from a safety/usability standpoint. Or last such mechanism can be deployed
> by stages.
>
> 2) Solving the Pre-Signed Feerate problem : Package-Relay or
> SIGHASH_ANYPREVOUT
>
> For Lightning, either package-relay or SIGHASH_ANYPREVOUT should be able
> to solve the pre-signed feerate issue [3]
>
> One of the interesting points recalled during the first transaction relay
> workshops was that L2s making unbounded security assumptions on
> non-normative tx-relay/mempool acceptance rules sounds a wrong direction
> for the Bitcoin ecosystem long-term, and more prone to subtle bugs/safety
> risks across the ecosystem.
>
> I did express the contrary, public opinion a while back [4]. That said, I
> start to agree it's wiser ecosystem-wise to keep those non-normatives rules
> as only a groundwork for weaker assumptions than consensus ones. Though it
> would be nice for long-term L2s stability to consider them with more care
> than today in our base-layer protocol development process [4]
>
> On this rational, I now share the opinion it's better long-term to solve
> the pre-signed feerate problem with a consensus change such as
> SIGHASH_ANYPREVOUT rather than having too much off-chain coins relying on
> the weaker assumptions offered by bitcoin core's tx-relay/mempool
> acceptance rules, and far harder to replicate and disseminate across the
> ecosystem.
>
> However, if SIGHASH_ANYPREVOUT is Things Done Right(tm), should we discard
> package-relay ?
>
> Sadly, in the worst-case scenario we might never reach consensus again
> across the ecosystem and Taproot is the last softfork. Ever :/ *sad violons
> and tissues jingle*
>
> With this dilemma in mind, it might be wise for the LN/L2 ecosystems to
> have a fall-back plan to solve their safety/usability issues and
> package-relay sounds a reasonable, temporary "patch".
>
> Even if package-relay requires serious engineering effort in Bitcoin Core
> to avoid introducing new DoSes, swallowing well the complexity increase in
> critical code paths such as the mempool/p2p stack and a gentle API design
> for our friends the L2 devs, I believe it's worthy the engineering
> resources cost. From-my-completely-biased-LN-dev viewpoint :p
>
> In the best-case scenario, we'll activate SIGHASH_ANYPREVOUT and better
> fee-bumping primitives softforks [5] slowly strip off the "L2 fee-bumping
> primitive" semantic from "package-relay", friendly nudge the L2 ecosystem
> to seat their fee-bumping on safer, consensus assumptions and maybe keep
> the p2p packages to improve on the malicious mempool-partitions-side or as
> a replacement of our orphan logic.
>
> 3) Solving Tx-Pinnings : Hardening the Mempool against Tx-Relay Jammings
> attacks
>
> Current Mempool anti-DoS rules have been mostly designed at a time where
> the shared-utxo model with competing time-sensitive transactions was still
> an idea on the whiteboard. The last few years have revealed those anti-DoS
> rules as a source of security vulnerabilities for Lightning and a research
> concern for L2s still in the early-phase of deployment [6].
>
> Beyond real-world pinning exercises against production software as a
> complement of the current pinning attacks research, it would be better to
> agree on a common L2 attacker model before to modify widely-relied subset
> of the mempool, such as the replace-by-fee logic or the in-mempool package
> limits [7]. One risk of uncareful changes in this area would be to solve a
> pinning vector for a L2-alice but introduce a new vuln for a L2-bob.
>
> I believe the first part of such a revamp could hopefully land somehow
> next year. Though, IMHO, in the years to come, we'll have to do more hard
> reasoning to ensure the mempool supports advanced Bitcoin protocols (e.g
> OP_CTV congestion tree,  CoinPool, interactive cut-through, ...)
>
> Note the opinion I raised above on quality of assumptions on mempool
> behavior, even if we harden it on the base-layer side,  L2s should be
> well-aware the product is shipped with a guarantee limitation :p
>
> 4) Considerations on Package-Relay Design
>
> Package relay relies on at least two cleanly separate components (awesome,
> if we schedule to deprecate the higher half in the future!)
> * "the higher half" : extension of the mempool logic, with a new
> package-level policy, not strictly intersecting with the tx-level policy
> * "the lower half" : at least three different designs, receiver initiated,
> sender-initiated and relay-initiated
>
> One open design question for the "higher half" is the package-size of the
> acceptance logic, which is ultimately a function of the L2 ecosystem state.
> Do we have deployed or in deployment phase L2 protocols with a need for
> more than 2-stage and if yes what API bounds do they expect ? That's a
> question I hope we'll gather feedback during next Thursday's transaction
> relay workshops. IMO, such package API should come out with a specification
> on which L2-community can be gathered and public consensus established. For
> the same communications reasons towards downstream projects, we have a
> BIP125 standard. And especially in this case the bitcoin core protocol
> development process should carefully listen to the needs of actual L2
> users. Also, a lot of those L2 devs, they don't speak C++ :)
>
> One could imagine those mempool standards as "perishable" contracts
> between a base-layer implementation and the upper layers, with ultimately
> the full-node implementation reserving itself the right to deprecate them,
> maybe with a lengthy-warning period ?
>
> Beyond that, I believe there is another remaining interdependency between
> "the lower half" design and L2s behaviors, namely bandwidth waste in case
> of a high-frequency of package redundancy. Let's say if a package is
> composed of {A, B}, and the package broadcaster fee-bump, triggering the
> transformation to {A, B'}, A bandwidth at first propagation is going to be
> wasted. Note, if we assume a dynamic fee-market, this package rebroadcast
> behavior should be common across the ecosystem. Though ultimately, the
> seriousness of this issue is going to be a function of the number of
> Lightning nodes relying on base-layer tx-relay and the number of fee-bumped
> onchain operations per Lightning node.
>
> I believe it would be great to come up with simulations on this front,
> just to avoid silently nullifying all the tedious, small improvements which
> have been done in the last years to minimize bitcoin core node's bandwidth.
>
> Another alternative would be to come with a cost-effective
> package-replacement policy, so likely more complexity. But might it not
> make sense to not economically outlaw Lightning nodes with a small fee
> budget ?
>
> Lastly, there is a consideration to have around anti-DoS measures we'll
> have to deploy for package-relay. Too easy, and that's a security concern
> for the base-layer, too hard, and that's introducing yet-another tx-relay
> jamming vector against L2, this time at the p2p layer (though won't be the
> first time [8]
>
> In any-case we should carefully consider the upgradeability of
> package-relay v.0, like if we upgrade some components of it such as package
> format or package-announcement scheme.
>
> So yeah why not early 0.24 ? Maybe a bit too short with all those p2p
> questions to clear up among core devs. Ideally, we would land in the
> beginning/middle of the cycle to have time for beta-testing on the L2-side
> and share feedback.
>
> Though ultimately, this question of p2p design belongs to the bitcoin core
> dev process.
>
> # Deployment timeline
>
> So what I believe as a rough deployment timeline.
>
> * "package-relay" in bitcoin core, early 0.24 or 0.25: a Core's release
> cycle offered to the LN/L2 ecosystem to integrate/exercise/provide feedback
> on package API
>
> * "mempool hardening" in bitcoin core, early 0.26 or 0.27, a Core's
> release cycle offered to the whole Bitcoin ecosystem to adapt their Bitcoin
> clients, maybe with a boolean setting to smooth the new policy deployment
>
> * SIGHASH_ANYPREVOUT softfork in the coming year(s), opt-in of any LN/L2
> implementation to migrate its fee-bumping backend on top of it
>
> * "optimized/multi-party fee-bumping primitive" softfork (one of tx
> mutation/sigash_iomap/sponsorship proposals) softfork in the coming decade,
> friendly uplift of the L2 ecosystem
>
> Glad to answer any unclarity or uncorrectness of mine :)
>
> Cheers,
> Antoine,
>
> [0] see
> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2018-November/016518.html
>
> [1] "The Coupling Principle states that as things get larger, they often
> exhibit increased interdependence between components".
>
> [2] see
> https://github.com/t-bast/lightning-docs/blob/master/pinning-attacks.md
>
> [2] see "Advances in Bitcoin Contracting : Uniform Policy and Package
> Relay"
> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2020-July/018063.html
>
> [3] I don't think there is a clear discussion on how SIGHASH_ANYPREVOUT
> solves pinnings beyond those LN meetings logs:
> https://gnusha.org/lightning-dev/2020-06-08.log
>
> [4] And I believe such great example has been done with this recent change
> proposed for bitcoin core addr-relay policy:
> https://github.com/bitcoin/bitcoin/pull/21528#issuecomment-809906430,
> where the PR author did bear the burden of reaching out potentially
> affected downstream projects.
>
> [5] Like one of tx_mutation/sighash_iomap/sponsorship proposal proposed in
> the thread "A Stroll through Fee-Bumping Techniques: Input-based vs
> Child-Pay-for-Parent" :
> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-May/019031.html
>
> [6] For a discussion about fee-bumping issues for L2s extended beyond LN
> see the analysis of the Revault protocol :
> https://arxiv.org/pdf/2102.09392.pdf
>
> [7] As a WIP towards establishing an attacker model, see "Secure
> Fee-Bumping for L2s"
> https://bitcoin-problems.github.io/problems/fee-bumping.html
>
> [8] Tx-relay rules as a concern for second-layers has been raised early
> on, at least during p2p segwit review
> https://github.com/bitcoin/bitcoin/issues/8279
>

[-- Attachment #2: Type: text/html, Size: 14694 bytes --]

Re: [bitcoin-dev] [Lightning-dev] Waiting SIGHASH_ANYPREVOUT and Packing Packages

[David A. Harding]

[-- Attachment #1: Type: text/plain, Size: 2907 bytes --]

On Fri, Jun 18, 2021 at 06:11:38PM -0400, Antoine Riard wrote:
> 2) Solving the Pre-Signed Feerate problem : Package-Relay or
> SIGHASH_ANYPREVOUT
> 
> For Lightning, either package-relay or SIGHASH_ANYPREVOUT should be able to
> solve the pre-signed feerate issue [3]
>
> [...]
>
> [3] I don't think there is a clear discussion on how SIGHASH_ANYPREVOUT
> solves pinnings beyond those LN meetings logs:
> https://gnusha.org/lightning-dev/2020-06-08.log

For anyone else looking, the most relevant line seems to be:

  13:50 < BlueMatt> (sidenote: sighash_no_input is *really* elegant here
  - assuming a lot of complicated logic in core to do so, you could
  imagine blind-cpfp-bumping *any* commitment tx without knowing its
  there or which one it is all with one tx.......in theory)

That might work for current LN-penalty, but I'm not sure it works for
eltoo.  If Bitcoin Core can rewrite the blind CPFP fee bump transaction
to refer to any prevout, that implies anyone else can do the same.
Miners who were aware of two or more states from an eltoo channel would
be incentivized to rewrite to the oldest state, giving them fee revenue
now and ensuring fee revenue in the future when a later state update is
broadcast.

If the attacker using pinning is able to reuse their attack at no cost,
they can re-pin the channel again and force the honest user to pay
another anyprevout bounty to miners.  Repeat this a bunch of times and
the honest user has now spent more on fees than their balance from the
closed channel.

Even if my analysis above is wrong, I would encourage you or Matt or
someone to write up this anyprevout idea in more detail and distribute
it before you promote it much more.

> package-relay sounds a reasonable, temporary "patch".

Even if every protocol based on presigned transactions can magically
allow dynamically adding inputs and modifying outputs for fees, and we
also have a magic perfect transaction replacement protocol, package
relay is still fundamentally useful for CPFP fee bumping very low
feerate transactions received from an external party.  E.g. Alice pays
Bob, mempool min feerates increase and Alice's transaction is dropped,
Bob still wants the money, so he submits a package with Alice's
transaction plus his own high feerate spend of it.

Package relay is a clear improvement now, and one I expect to be
permanent for as long as we're using anything like the current protocol.
 
> # Deployment timeline
> 
> So what I believe as a rough deployment timeline.

I don't think it's appropriate to be creating timelines like this that
depend on the work of a large number of contributors who I don't believe
you've consulted.  For details on this point of view, please see
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-July/014726.html

Stuff will get done when it gets done.

-Dave

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [bitcoin-dev] [Lightning-dev] Waiting SIGHASH_ANYPREVOUT and Packing Packages

[Antoine Riard]

[-- Attachment #1: Type: text/plain, Size: 12876 bytes --]

Hi Dave,

> That might work for current LN-penalty, but I'm not sure it works for
eltoo.

Well, we have not settled yet on the eltoo design but if we take the later
proposal in date [0], signing the update transaction with
SIGHGASH_ANYPREVOUT lets you attach non-interactively a single-party
controlled input at broadcast-time. Providing the input amount is high
enough to bump the transaction feerate over network mempools, it should
allow the tx to propagate across network mempools and that way solve the
pre-signed feerate problem as defined in the post ?

>  If Bitcoin Core can rewrite the blind CPFP fee bump transaction
> to refer to any prevout, that implies anyone else can do the same.
> Miners who were aware of two or more states from an eltoo channel would
> be incentivized to rewrite to the oldest state, giving them fee revenue
> now and ensuring fee revenue in the future when a later state update is
> broadcast.

Yep, you can add a per-participant key to lockdown the transaction and
avoid any in-flight malleability ? I think this is discussed in the "A
Stroll through Fee-Bumping Techniques" thread.

> If the attacker using pinning is able to reuse their attack at no cost,
> they can re-pin the channel again and force the honest user to pay
> another anyprevout bounty to miners.

This is also true with package-relay where your counterparty, with a better
knowledge of network mempools, can always re-broadcast a CPFP-bumped
malicious package ? Under this assumption, I think you should always be
ready to bump our honest package.

Further, for the clarity of the discussion, can you point to which pinning
scenario you're thinking of or if it's new under SIGHASH_ANYPREVOUT,
describe it ?

> Repeat this a bunch of times and the honest user has now spent more on
fees than their balance from the
closed channel.

And sadly, as this concern also exists in case of a miner-harvesting attack
against LN nodes, a concern that Gleb and I expressed more than a year ago
in a public post [1], a good L2 client should always upper bound its
fee-bumping reserve. I've a short though-unclear note on this notion of
fee-bumping upper to warn other L2 engineers  in "On Mempool Funny Games
against Multi-Party Funded Transactions"

Please read so:

"A L2 client, with only a view of its mempool at best, won't understand why
 the transaction doesn't confirm and if it's responsible for the
 fee-bumping, it might do multiple rounds of feerate increase through CPFP,
 in vain. As the fee-bumping algorithm is assumed to be known if the victim
 client is open source code, the attacker can predict when the fee-bumping
 logic reaches its upper bound."

Though thanks for the recall! I should log dynamic-balances in RL's
`ChannelMonitorUpdate` for our ongoing implementation of anchor, updating
my TODO :p

> Even if my analysis above is wrong, I would encourage you or Matt or
someone to write up this anyprevout idea in more detail and distribute
it before you promote it much more.

That's a really fair point, as a lot of the reasoning was based on private
discussion with Matt. Though as SIGHASH_ANYPREVOUT isn't advocated for
community consensus and those things take time, should just take a few
hours of my time.

> Even if every protocol based on presigned transactions can magically
allow dynamically adding inputs and modifying outputs for fees, and we
also have a magic perfect transaction replacement protocol,

"“Any sufficiently advanced technology is indistinguishable from magic.”
Arthur C. Clarke

Wit apart, that might be the outcome with careful bitcoin protocol
development, where technical issues are laid out in a best effort (of
mine!) and spread to the Bitcoin community on the most public bitcoin
communication channel ?

And humbly, on all those L2 issues I did change my opinion, as I've written
so much explicitly in this thread post by pointing to an older post of mine
("Advances in Bitcoin Contracting : Uniform Policy and Package Relay").
This reversal, partially motivated by a lot of discussion with folks,
including yourself, initiated since at least mid last year.

> package relay is still fundamentally useful for CPFP fee bumping very low
> feerate transactions received from an external party.  E.g. Alice pays
> Bob, mempool min feerates increase and Alice's transaction is dropped,
> Bob still wants the money, so he submits a package with Alice's
> transaction plus his own high feerate spend of it.

I think this point would be a reverse of our p2p design where we are now
making the sender responsible for the receiver quality of its mempool
feerate ? This question has never been clear up during the years-long
discussion of package-relay design [1].

Though referring to the thread post and last week's transaction-relay
workshop, I did point out that package-relay might serve in the long-term
as a mempool-sync mechanism to prevent potential malicious mempool
partitions [2].

> Package relay is a clear improvement now, and one I expect to be
permanent for as long as we're using anything like the current protocol

Again, reading my post, I did point out that we might keep the "lower half"
of package-relay and deprecate only the higher part of it as we have more
feerate-efficient fee-bumping primitive available. If  it sounds too much
of a release engineering effort to synchronize on the scale of an
ecosystem, think about the ongoing deprecation of Tor V2.

Further, you did express a far less assertive opinion during last Tuesday
transaction-relay workshops, to which a lot of folks attended, where you
pointed it might not be a good idea for L2s to make more assumptions on
non-normative:

"harding> I do think we should be using miners profit incentive more for
stuff rather than trying to normalize mempool policy (which not entirely
possible), e.g. things like
https://lists.linuxfoundation.org/pipermail/lightning-dev/2020-April/002664.html
"

Arguing for package-relay "permanence" moves in the contrary decision IMHO ?

> I don't think it's appropriate to be creating timelines like this that
depend on the work of a large number of contributors who I don't believe

Thanks Dave, this is your opinion and I respect this. I'll let any
participant of this mailing list make an opinion on its own, following
their private judgement. It might be based from a lot of different factors,
e.g "trusting the experts" or gathering diverse in-field authorities'
opinions or reasoning from scratch based on raw, public facts.

Though might I ask you on which information sources are you finding your
belief ? I'm curious if you're aware of any contributors who feel entitled
to be consulted in a decentralized development process...

For the records, I did consult no one. As even in the technical circle that
would have been a lot of open source projects teams to reach out : LND,
c-ligtning, Eclair, coin-teleport, revault, sapio, btcsuite, bcoin,
libbitcoin, wasabi's coinjoin, samourai wallet's coinjoin, ...

I was lazy, I just shot a mail :p

W.r.t to Greg's 4-year old's piece, I'll let him express his opinion on how
the expressed framework applies to my post, the Bitcoin dev stage has grown
a lot since then. What was making sense when you had like ~20 Bitcoin dev
with 90% of the technical knowledge doesn't scale when you have multiple
second-layers specifications of which you have multiple implementations
teams, some of them  decentralized and spread through different
countries/timezones, IMHO.

Though, Dave if you strongly hold your opinion on my behavior, I would
invite you to do this intellectual work by yourself.

Browsing quickly through Greg's piece, a lot of the reasoning is based on
FOSS experience from Linux/Juniper, which to the best of my knowledge are
centralized software projects ?

Note, also Paul Storzc's post has the simple phrase :

"I emphasized concrete numbers, and concrete dates"

I believe my post doesn't have such numbers and concrete dates ?

Presence of Core version numbers are motivated as clear signalling for L2
developpers to update their backend in case of undocumented, subtle policy
changes slipping in the codebase. Let's minimize CVE-2020-26895
style-of-bugs across the ecosystem :/

Finally, the presence of timelines in this post is also a gentle call for
the Bitcoin ecosystem to act on those safety holes, of which the
seriousness has been underscored by a lot of contributors in the past,
especially for the pre-signed feerate problem and even before I was in the
Bitcoin stage.

So better to patch them before they do manifest in the wild, and folks
start to bleed coins.  What you learn from practicing security research,
the lack of action can be harmful :/

> Stuff will get done when it gets done.

Don't forget bugs might slip in but that's fine if you have the skilled
folks around to catch them :)

And yes I really care about Lightning, and all those cute new L2 protocols
fostering in the community :)

Finally, you know Dave, I'm just spreading ideas.

If those ideas are sound and folks love them, awesome! They're free to use,
study, share and modify them to build better systems.

If I'm wrong, like I've been in the past, like I might be today and like
I'll be in the future, I hope they will be patient to teach me back and
we'll learn.

Hacker ethos :) ?

Cheers,
Antoine

[0]
https://lists.linuxfoundation.org/pipermail/lightning-dev/2020-January/002448.html

[1] https://github.com/bitcoin/bitcoin/issues/14895

[2]
https://lists.linuxfoundation.org/pipermail/lightning-dev/2020-February/002569.html

Le sam. 19 juin 2021 à 09:38, David A. Harding <dave@dtrt.org> a écrit :

> On Fri, Jun 18, 2021 at 06:11:38PM -0400, Antoine Riard wrote:
> > 2) Solving the Pre-Signed Feerate problem : Package-Relay or
> > SIGHASH_ANYPREVOUT
> >
> > For Lightning, either package-relay or SIGHASH_ANYPREVOUT should be able
> to
> > solve the pre-signed feerate issue [3]
> >
> > [...]
> >
> > [3] I don't think there is a clear discussion on how SIGHASH_ANYPREVOUT
> > solves pinnings beyond those LN meetings logs:
> > https://gnusha.org/lightning-dev/2020-06-08.log
>
> For anyone else looking, the most relevant line seems to be:
>
>   13:50 < BlueMatt> (sidenote: sighash_no_input is *really* elegant here
>   - assuming a lot of complicated logic in core to do so, you could
>   imagine blind-cpfp-bumping *any* commitment tx without knowing its
>   there or which one it is all with one tx.......in theory)
>
> That might work for current LN-penalty, but I'm not sure it works for
> eltoo.  If Bitcoin Core can rewrite the blind CPFP fee bump transaction
> to refer to any prevout, that implies anyone else can do the same.
> Miners who were aware of two or more states from an eltoo channel would
> be incentivized to rewrite to the oldest state, giving them fee revenue
> now and ensuring fee revenue in the future when a later state update is
> broadcast.
>
> If the attacker using pinning is able to reuse their attack at no cost,
> they can re-pin the channel again and force the honest user to pay
> another anyprevout bounty to miners.  Repeat this a bunch of times and
> the honest user has now spent more on fees than their balance from the
> closed channel.
>
> Even if my analysis above is wrong, I would encourage you or Matt or
> someone to write up this anyprevout idea in more detail and distribute
> it before you promote it much more.
>
> > package-relay sounds a reasonable, temporary "patch".
>
> Even if every protocol based on presigned transactions can magically
> allow dynamically adding inputs and modifying outputs for fees, and we
> also have a magic perfect transaction replacement protocol, package
> relay is still fundamentally useful for CPFP fee bumping very low
> feerate transactions received from an external party.  E.g. Alice pays
> Bob, mempool min feerates increase and Alice's transaction is dropped,
> Bob still wants the money, so he submits a package with Alice's
> transaction plus his own high feerate spend of it.
>
> Package relay is a clear improvement now, and one I expect to be
> permanent for as long as we're using anything like the current protocol.
>
> > # Deployment timeline
> >
> > So what I believe as a rough deployment timeline.
>
> I don't think it's appropriate to be creating timelines like this that
> depend on the work of a large number of contributors who I don't believe
> you've consulted.  For details on this point of view, please see
>
> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-July/014726.html
>
> Stuff will get done when it gets done.
>
> -Dave
>

[-- Attachment #2: Type: text/html, Size: 14487 bytes --]

Re: [bitcoin-dev] [Lightning-dev] Waiting SIGHASH_ANYPREVOUT and Packing Packages

[Michael Folkson]

I don't want to divert from the topic of this thread ("Waiting
SIGHASH_ANYPREVOUT and Packing Packages"), we can set up a separate
thread if we want to discuss this further. But just a couple of
things.

> Browsing quickly through Greg's piece, a lot of the reasoning is based on FOSS experience from Linux/Juniper, which to the best of my knowledge are centralized software projects ?

That is Greg's point. If Linux doesn't look further than the current
version and the next version with a BDFL (Linus) a decentralized
project like Bitcoin Core is going to struggle even more with longer
term roadmaps.

I think it is important to discuss what order changes should be
attempted but I agree with David that putting specific future version
numbers on changes is speculative at best and misleading at worst. The
record of previous predictions of what will be included in particular
future versions is not strong :)

> What was making sense when you had like ~20 Bitcoin dev with 90% of the technical knowledge doesn't scale when you have multiple second-layers specifications

It is great that we have a larger set of contributors in the ecosystem
today than back in say pre 2017. But today that set of contributors is
spread widely across a number of different projects that didn't exist
pre 2017. Changes to Core are (generally) likely to be implemented and
reviewed by current Core contributors as Lightning implementation
developers (generally) seem to have their hands full with their own
implementations.

I think we can get the balance right by making progress on this
(important) discussion whilst also maintaining humility that we don't
know exact timelines and that getting things merged into Core relies
on a number of people who have varying levels of interest and
understanding of L2 protocols.

On Mon, Jun 21, 2021 at 9:13 AM Antoine Riard <antoine.riard@gmail.com> wrote:
>
> Hi Dave,
>
> > That might work for current LN-penalty, but I'm not sure it works for
> eltoo.
>
> Well, we have not settled yet on the eltoo design but if we take the later proposal in date [0], signing the update transaction with SIGHGASH_ANYPREVOUT lets you attach non-interactively a single-party controlled input at broadcast-time. Providing the input amount is high enough to bump the transaction feerate over network mempools, it should allow the tx to propagate across network mempools and that way solve the pre-signed feerate problem as defined in the post ?
>
> >  If Bitcoin Core can rewrite the blind CPFP fee bump transaction
> > to refer to any prevout, that implies anyone else can do the same.
> > Miners who were aware of two or more states from an eltoo channel would
> > be incentivized to rewrite to the oldest state, giving them fee revenue
> > now and ensuring fee revenue in the future when a later state update is
> > broadcast.
>
> Yep, you can add a per-participant key to lockdown the transaction and avoid any in-flight malleability ? I think this is discussed in the "A Stroll through Fee-Bumping Techniques" thread.
>
> > If the attacker using pinning is able to reuse their attack at no cost,
> > they can re-pin the channel again and force the honest user to pay
> > another anyprevout bounty to miners.
>
> This is also true with package-relay where your counterparty, with a better knowledge of network mempools, can always re-broadcast a CPFP-bumped malicious package ? Under this assumption, I think you should always be ready to bump our honest package.
>
> Further, for the clarity of the discussion, can you point to which pinning scenario you're thinking of or if it's new under SIGHASH_ANYPREVOUT, describe it ?
>
> > Repeat this a bunch of times and the honest user has now spent more on fees than their balance from the
> closed channel.
>
> And sadly, as this concern also exists in case of a miner-harvesting attack against LN nodes, a concern that Gleb and I expressed more than a year ago in a public post [1], a good L2 client should always upper bound its fee-bumping reserve. I've a short though-unclear note on this notion of fee-bumping upper to warn other L2 engineers  in "On Mempool Funny Games against Multi-Party Funded Transactions"
>
> Please read so:
>
> "A L2 client, with only a view of its mempool at best, won't understand why
>  the transaction doesn't confirm and if it's responsible for the
>  fee-bumping, it might do multiple rounds of feerate increase through CPFP,
>  in vain. As the fee-bumping algorithm is assumed to be known if the victim
>  client is open source code, the attacker can predict when the fee-bumping
>  logic reaches its upper bound."
>
> Though thanks for the recall! I should log dynamic-balances in RL's `ChannelMonitorUpdate` for our ongoing implementation of anchor, updating my TODO :p
>
> > Even if my analysis above is wrong, I would encourage you or Matt or
> someone to write up this anyprevout idea in more detail and distribute
> it before you promote it much more.
>
> That's a really fair point, as a lot of the reasoning was based on private discussion with Matt. Though as SIGHASH_ANYPREVOUT isn't advocated for community consensus and those things take time, should just take a few hours of my time.
>
> > Even if every protocol based on presigned transactions can magically
> allow dynamically adding inputs and modifying outputs for fees, and we
> also have a magic perfect transaction replacement protocol,
>
> "“Any sufficiently advanced technology is indistinguishable from magic.” Arthur C. Clarke
>
> Wit apart, that might be the outcome with careful bitcoin protocol development, where technical issues are laid out in a best effort (of mine!) and spread to the Bitcoin community on the most public bitcoin communication channel ?
>
> And humbly, on all those L2 issues I did change my opinion, as I've written so much explicitly in this thread post by pointing to an older post of mine ("Advances in Bitcoin Contracting : Uniform Policy and Package Relay"). This reversal, partially motivated by a lot of discussion with folks, including yourself, initiated since at least mid last year.
>
> > package relay is still fundamentally useful for CPFP fee bumping very low
> > feerate transactions received from an external party.  E.g. Alice pays
> > Bob, mempool min feerates increase and Alice's transaction is dropped,
> > Bob still wants the money, so he submits a package with Alice's
> > transaction plus his own high feerate spend of it.
>
> I think this point would be a reverse of our p2p design where we are now making the sender responsible for the receiver quality of its mempool feerate ? This question has never been clear up during the years-long discussion of package-relay design [1].
>
> Though referring to the thread post and last week's transaction-relay workshop, I did point out that package-relay might serve in the long-term as a mempool-sync mechanism to prevent potential malicious mempool partitions [2].
>
> > Package relay is a clear improvement now, and one I expect to be
> permanent for as long as we're using anything like the current protocol
>
> Again, reading my post, I did point out that we might keep the "lower half" of package-relay and deprecate only the higher part of it as we have more feerate-efficient fee-bumping primitive available. If  it sounds too much of a release engineering effort to synchronize on the scale of an ecosystem, think about the ongoing deprecation of Tor V2.
>
> Further, you did express a far less assertive opinion during last Tuesday transaction-relay workshops, to which a lot of folks attended, where you pointed it might not be a good idea for L2s to make more assumptions on non-normative:
>
> "harding> I do think we should be using miners profit incentive more for stuff rather than trying to normalize mempool policy (which not entirely possible), e.g. things like https://lists.linuxfoundation.org/pipermail/lightning-dev/2020-April/002664.html"
>
> Arguing for package-relay "permanence" moves in the contrary decision IMHO ?
>
> > I don't think it's appropriate to be creating timelines like this that
> depend on the work of a large number of contributors who I don't believe
>
> Thanks Dave, this is your opinion and I respect this. I'll let any participant of this mailing list make an opinion on its own, following their private judgement. It might be based from a lot of different factors, e.g "trusting the experts" or gathering diverse in-field authorities' opinions or reasoning from scratch based on raw, public facts.
>
> Though might I ask you on which information sources are you finding your belief ? I'm curious if you're aware of any contributors who feel entitled to be consulted in a decentralized development process...
>
> For the records, I did consult no one. As even in the technical circle that would have been a lot of open source projects teams to reach out : LND, c-ligtning, Eclair, coin-teleport, revault, sapio, btcsuite, bcoin, libbitcoin, wasabi's coinjoin, samourai wallet's coinjoin, ...
>
> I was lazy, I just shot a mail :p
>
> W.r.t to Greg's 4-year old's piece, I'll let him express his opinion on how the expressed framework applies to my post, the Bitcoin dev stage has grown a lot since then. What was making sense when you had like ~20 Bitcoin dev with 90% of the technical knowledge doesn't scale when you have multiple second-layers specifications of which you have multiple implementations teams, some of them  decentralized and spread through different countries/timezones, IMHO.
>
> Though, Dave if you strongly hold your opinion on my behavior, I would invite you to do this intellectual work by yourself.
>
> Browsing quickly through Greg's piece, a lot of the reasoning is based on FOSS experience from Linux/Juniper, which to the best of my knowledge are centralized software projects ?
>
> Note, also Paul Storzc's post has the simple phrase :
>
> "I emphasized concrete numbers, and concrete dates"
>
> I believe my post doesn't have such numbers and concrete dates ?
>
> Presence of Core version numbers are motivated as clear signalling for L2 developpers to update their backend in case of undocumented, subtle policy changes slipping in the codebase. Let's minimize CVE-2020-26895 style-of-bugs across the ecosystem :/
>
> Finally, the presence of timelines in this post is also a gentle call for the Bitcoin ecosystem to act on those safety holes, of which the seriousness has been underscored by a lot of contributors in the past, especially for the pre-signed feerate problem and even before I was in the Bitcoin stage.
>
> So better to patch them before they do manifest in the wild, and folks start to bleed coins.  What you learn from practicing security research, the lack of action can be harmful :/
>
> > Stuff will get done when it gets done.
>
> Don't forget bugs might slip in but that's fine if you have the skilled folks around to catch them :)
>
> And yes I really care about Lightning, and all those cute new L2 protocols fostering in the community :)
>
> Finally, you know Dave, I'm just spreading ideas.
>
> If those ideas are sound and folks love them, awesome! They're free to use, study, share and modify them to build better systems.
>
> If I'm wrong, like I've been in the past, like I might be today and like I'll be in the future, I hope they will be patient to teach me back and we'll learn.
>
> Hacker ethos :) ?
>
> Cheers,
> Antoine
>
> [0] https://lists.linuxfoundation.org/pipermail/lightning-dev/2020-January/002448.html
>
> [1] https://github.com/bitcoin/bitcoin/issues/14895
>
> [2] https://lists.linuxfoundation.org/pipermail/lightning-dev/2020-February/002569.html
>
> Le sam. 19 juin 2021 à 09:38, David A. Harding <dave@dtrt.org> a écrit :
>>
>> On Fri, Jun 18, 2021 at 06:11:38PM -0400, Antoine Riard wrote:
>> > 2) Solving the Pre-Signed Feerate problem : Package-Relay or
>> > SIGHASH_ANYPREVOUT
>> >
>> > For Lightning, either package-relay or SIGHASH_ANYPREVOUT should be able to
>> > solve the pre-signed feerate issue [3]
>> >
>> > [...]
>> >
>> > [3] I don't think there is a clear discussion on how SIGHASH_ANYPREVOUT
>> > solves pinnings beyond those LN meetings logs:
>> > https://gnusha.org/lightning-dev/2020-06-08.log
>>
>> For anyone else looking, the most relevant line seems to be:
>>
>>   13:50 < BlueMatt> (sidenote: sighash_no_input is *really* elegant here
>>   - assuming a lot of complicated logic in core to do so, you could
>>   imagine blind-cpfp-bumping *any* commitment tx without knowing its
>>   there or which one it is all with one tx.......in theory)
>>
>> That might work for current LN-penalty, but I'm not sure it works for
>> eltoo.  If Bitcoin Core can rewrite the blind CPFP fee bump transaction
>> to refer to any prevout, that implies anyone else can do the same.
>> Miners who were aware of two or more states from an eltoo channel would
>> be incentivized to rewrite to the oldest state, giving them fee revenue
>> now and ensuring fee revenue in the future when a later state update is
>> broadcast.
>>
>> If the attacker using pinning is able to reuse their attack at no cost,
>> they can re-pin the channel again and force the honest user to pay
>> another anyprevout bounty to miners.  Repeat this a bunch of times and
>> the honest user has now spent more on fees than their balance from the
>> closed channel.
>>
>> Even if my analysis above is wrong, I would encourage you or Matt or
>> someone to write up this anyprevout idea in more detail and distribute
>> it before you promote it much more.
>>
>> > package-relay sounds a reasonable, temporary "patch".
>>
>> Even if every protocol based on presigned transactions can magically
>> allow dynamically adding inputs and modifying outputs for fees, and we
>> also have a magic perfect transaction replacement protocol, package
>> relay is still fundamentally useful for CPFP fee bumping very low
>> feerate transactions received from an external party.  E.g. Alice pays
>> Bob, mempool min feerates increase and Alice's transaction is dropped,
>> Bob still wants the money, so he submits a package with Alice's
>> transaction plus his own high feerate spend of it.
>>
>> Package relay is a clear improvement now, and one I expect to be
>> permanent for as long as we're using anything like the current protocol.
>>
>> > # Deployment timeline
>> >
>> > So what I believe as a rough deployment timeline.
>>
>> I don't think it's appropriate to be creating timelines like this that
>> depend on the work of a large number of contributors who I don't believe
>> you've consulted.  For details on this point of view, please see
>> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-July/014726.html
>>
>> Stuff will get done when it gets done.
>>
>> -Dave
>
> _______________________________________________
> Lightning-dev mailing list
> Lightning-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev



-- 
Michael Folkson
Email: michaelfolkson@gmail.com
Keybase: michaelfolkson
PGP: 43ED C999 9F85 1D40 EAF4 9835 92D6 0159 214C FEE3

Re: [bitcoin-dev] [Lightning-dev] Waiting SIGHASH_ANYPREVOUT and Packing Packages

[Antoine Riard]

[-- Attachment #1: Type: text/plain, Size: 20481 bytes --]

Hi Michael,

> Browsing quickly through Greg's piece, a lot of the reasoning is based on
FOSS experience from Linux/Juniper, which to the best of my knowledge are
centralized software projects ?

> That is Greg's point. If Linux doesn't look further than the current
> version and the next version with a BDFL (Linus) a decentralized
> project like Bitcoin Core is going to struggle even more with longer
> term roadmaps.

I was far more inclined to recall the unsolved problems for Lightning/L2s
(pre-signed feerate/tx-pinnings) than calling out strong solutions to them.
I believe problem spaces are quite something stable in engineering/science,
at least until they're formalized differently. But even coming to consensus
on  the existence of problems and a shared perception of the severity of
them can take a long time. In fact, it might even be the hardest step in a
decentralized ecosystem like Bitcoin.

And I fill in on the low-relevance of roadmaps, real development is a
continuous zigzag. If we look in the past and take the transaction
malleability issue, I think we can observe it took multiple proposals (bip
62, normalized txid,  sighash_noinput, ...),  of which we're even
implemented in Core, before to finally settle on segwit. Though I would say
lessons were drawn about shortcomings of every transient proposal.

> I think it is important to discuss what order changes should be
> attempted but I agree with David that putting specific future version
> numbers on changes is speculative at best and misleading at worst. The
> record of previous predictions of what will be included in particular
> future versions is not strong :)

I recognize it wasn't delicate to put exact version numbers, though note
multiple, alternative versions numbers were deliberately proposed for each
specific change and timelines given in terms of years,  more as an invite
to open a discussion on such changes and where/when they could take place,
that in anyway a finite, consistent deployment proposal.

Further, I still believe it would be cool to have a bit more coordination
when Core implements sophisticated mechanisms designed for downstream
support, in the sense of feedback exchanged across projects all along their
release schedules. For e.g, with package-relay, as a Lightning team it's
likely you will have to rework your tx-broadcast module which might take a
few good weeks of review and test. Though, coming to this best practice
(imho) across the different Bitcoin layers might take years and that's
perfectly fine, we'll see what emerges :)

> What was making sense when you had like ~20 Bitcoin dev with 90% of the
technical knowledge doesn't scale when you have multiple second-layers
specifications

> It is great that we have a larger set of contributors in the ecosystem
> today than back in say pre 2017. But today that set of contributors is
> spread widely across a number of different projects that didn't exist
> pre 2017. Changes to Core are (generally) likely to be implemented and
> reviewed by current Core contributors as Lightning implementation
> developers (generally) seem to have their hands full with their own
> implementations.

Well I strongly believe that the Core review process is open to anyone :) ?
If some upper layers contributors are generously offering their time to
share back their experiences, especially during the design phase of
software features, I hope we might be on path to deliver better stuff.

Further, that's a more personal note, I'm worried long-term about
layer-monoculture cropping up in the ecosystem, a concern echoing the
history of Internet development [0].

> I think we can get the balance right by making progress on this
> (important) discussion whilst also maintaining humility that we don't
> know exact timelines and that getting things merged into Core relies
> on a number of people who have varying levels of interest and
> understanding of L2 protocols.

Yes, as answers to my post are showing, I might have lacked patience in
this case :/ Sometimes, it's hard to gauge your own cognitive dissonance on
topics.

Cheers,
Antoine

[0] See "Interactions between Layers" in "General Architectural and Policy
Considerations", RFC 3426

Le lun. 21 juin 2021 à 06:20, Michael Folkson <michaelfolkson@gmail.com> a
écrit :

> I don't want to divert from the topic of this thread ("Waiting
> SIGHASH_ANYPREVOUT and Packing Packages"), we can set up a separate
> thread if we want to discuss this further. But just a couple of
> things.
>
> > Browsing quickly through Greg's piece, a lot of the reasoning is based
> on FOSS experience from Linux/Juniper, which to the best of my knowledge
> are centralized software projects ?
>
> That is Greg's point. If Linux doesn't look further than the current
> version and the next version with a BDFL (Linus) a decentralized
> project like Bitcoin Core is going to struggle even more with longer
> term roadmaps.
>
> I think it is important to discuss what order changes should be
> attempted but I agree with David that putting specific future version
> numbers on changes is speculative at best and misleading at worst. The
> record of previous predictions of what will be included in particular
> future versions is not strong :)
>
> > What was making sense when you had like ~20 Bitcoin dev with 90% of the
> technical knowledge doesn't scale when you have multiple second-layers
> specifications
>
> It is great that we have a larger set of contributors in the ecosystem
> today than back in say pre 2017. But today that set of contributors is
> spread widely across a number of different projects that didn't exist
> pre 2017. Changes to Core are (generally) likely to be implemented and
> reviewed by current Core contributors as Lightning implementation
> developers (generally) seem to have their hands full with their own
> implementations.
>
> I think we can get the balance right by making progress on this
> (important) discussion whilst also maintaining humility that we don't
> know exact timelines and that getting things merged into Core relies
> on a number of people who have varying levels of interest and
> understanding of L2 protocols.
>
> On Mon, Jun 21, 2021 at 9:13 AM Antoine Riard <antoine.riard@gmail.com>
> wrote:
> >
> > Hi Dave,
> >
> > > That might work for current LN-penalty, but I'm not sure it works for
> > eltoo.
> >
> > Well, we have not settled yet on the eltoo design but if we take the
> later proposal in date [0], signing the update transaction with
> SIGHGASH_ANYPREVOUT lets you attach non-interactively a single-party
> controlled input at broadcast-time. Providing the input amount is high
> enough to bump the transaction feerate over network mempools, it should
> allow the tx to propagate across network mempools and that way solve the
> pre-signed feerate problem as defined in the post ?
> >
> > >  If Bitcoin Core can rewrite the blind CPFP fee bump transaction
> > > to refer to any prevout, that implies anyone else can do the same.
> > > Miners who were aware of two or more states from an eltoo channel would
> > > be incentivized to rewrite to the oldest state, giving them fee revenue
> > > now and ensuring fee revenue in the future when a later state update is
> > > broadcast.
> >
> > Yep, you can add a per-participant key to lockdown the transaction and
> avoid any in-flight malleability ? I think this is discussed in the "A
> Stroll through Fee-Bumping Techniques" thread.
> >
> > > If the attacker using pinning is able to reuse their attack at no cost,
> > > they can re-pin the channel again and force the honest user to pay
> > > another anyprevout bounty to miners.
> >
> > This is also true with package-relay where your counterparty, with a
> better knowledge of network mempools, can always re-broadcast a CPFP-bumped
> malicious package ? Under this assumption, I think you should always be
> ready to bump our honest package.
> >
> > Further, for the clarity of the discussion, can you point to which
> pinning scenario you're thinking of or if it's new under
> SIGHASH_ANYPREVOUT, describe it ?
> >
> > > Repeat this a bunch of times and the honest user has now spent more on
> fees than their balance from the
> > closed channel.
> >
> > And sadly, as this concern also exists in case of a miner-harvesting
> attack against LN nodes, a concern that Gleb and I expressed more than a
> year ago in a public post [1], a good L2 client should always upper bound
> its fee-bumping reserve. I've a short though-unclear note on this notion of
> fee-bumping upper to warn other L2 engineers  in "On Mempool Funny Games
> against Multi-Party Funded Transactions"
> >
> > Please read so:
> >
> > "A L2 client, with only a view of its mempool at best, won't understand
> why
> >  the transaction doesn't confirm and if it's responsible for the
> >  fee-bumping, it might do multiple rounds of feerate increase through
> CPFP,
> >  in vain. As the fee-bumping algorithm is assumed to be known if the
> victim
> >  client is open source code, the attacker can predict when the
> fee-bumping
> >  logic reaches its upper bound."
> >
> > Though thanks for the recall! I should log dynamic-balances in RL's
> `ChannelMonitorUpdate` for our ongoing implementation of anchor, updating
> my TODO :p
> >
> > > Even if my analysis above is wrong, I would encourage you or Matt or
> > someone to write up this anyprevout idea in more detail and distribute
> > it before you promote it much more.
> >
> > That's a really fair point, as a lot of the reasoning was based on
> private discussion with Matt. Though as SIGHASH_ANYPREVOUT isn't advocated
> for community consensus and those things take time, should just take a few
> hours of my time.
> >
> > > Even if every protocol based on presigned transactions can magically
> > allow dynamically adding inputs and modifying outputs for fees, and we
> > also have a magic perfect transaction replacement protocol,
> >
> > "“Any sufficiently advanced technology is indistinguishable from magic.”
> Arthur C. Clarke
> >
> > Wit apart, that might be the outcome with careful bitcoin protocol
> development, where technical issues are laid out in a best effort (of
> mine!) and spread to the Bitcoin community on the most public bitcoin
> communication channel ?
> >
> > And humbly, on all those L2 issues I did change my opinion, as I've
> written so much explicitly in this thread post by pointing to an older post
> of mine ("Advances in Bitcoin Contracting : Uniform Policy and Package
> Relay"). This reversal, partially motivated by a lot of discussion with
> folks, including yourself, initiated since at least mid last year.
> >
> > > package relay is still fundamentally useful for CPFP fee bumping very
> low
> > > feerate transactions received from an external party.  E.g. Alice pays
> > > Bob, mempool min feerates increase and Alice's transaction is dropped,
> > > Bob still wants the money, so he submits a package with Alice's
> > > transaction plus his own high feerate spend of it.
> >
> > I think this point would be a reverse of our p2p design where we are now
> making the sender responsible for the receiver quality of its mempool
> feerate ? This question has never been clear up during the years-long
> discussion of package-relay design [1].
> >
> > Though referring to the thread post and last week's transaction-relay
> workshop, I did point out that package-relay might serve in the long-term
> as a mempool-sync mechanism to prevent potential malicious mempool
> partitions [2].
> >
> > > Package relay is a clear improvement now, and one I expect to be
> > permanent for as long as we're using anything like the current protocol
> >
> > Again, reading my post, I did point out that we might keep the "lower
> half" of package-relay and deprecate only the higher part of it as we have
> more feerate-efficient fee-bumping primitive available. If  it sounds too
> much of a release engineering effort to synchronize on the scale of an
> ecosystem, think about the ongoing deprecation of Tor V2.
> >
> > Further, you did express a far less assertive opinion during last
> Tuesday transaction-relay workshops, to which a lot of folks attended,
> where you pointed it might not be a good idea for L2s to make more
> assumptions on non-normative:
> >
> > "harding> I do think we should be using miners profit incentive more for
> stuff rather than trying to normalize mempool policy (which not entirely
> possible), e.g. things like
> https://lists.linuxfoundation.org/pipermail/lightning-dev/2020-April/002664.html
> "
> >
> > Arguing for package-relay "permanence" moves in the contrary decision
> IMHO ?
> >
> > > I don't think it's appropriate to be creating timelines like this that
> > depend on the work of a large number of contributors who I don't believe
> >
> > Thanks Dave, this is your opinion and I respect this. I'll let any
> participant of this mailing list make an opinion on its own, following
> their private judgement. It might be based from a lot of different factors,
> e.g "trusting the experts" or gathering diverse in-field authorities'
> opinions or reasoning from scratch based on raw, public facts.
> >
> > Though might I ask you on which information sources are you finding your
> belief ? I'm curious if you're aware of any contributors who feel entitled
> to be consulted in a decentralized development process...
> >
> > For the records, I did consult no one. As even in the technical circle
> that would have been a lot of open source projects teams to reach out :
> LND, c-ligtning, Eclair, coin-teleport, revault, sapio, btcsuite, bcoin,
> libbitcoin, wasabi's coinjoin, samourai wallet's coinjoin, ...
> >
> > I was lazy, I just shot a mail :p
> >
> > W.r.t to Greg's 4-year old's piece, I'll let him express his opinion on
> how the expressed framework applies to my post, the Bitcoin dev stage has
> grown a lot since then. What was making sense when you had like ~20 Bitcoin
> dev with 90% of the technical knowledge doesn't scale when you have
> multiple second-layers specifications of which you have multiple
> implementations teams, some of them  decentralized and spread through
> different countries/timezones, IMHO.
> >
> > Though, Dave if you strongly hold your opinion on my behavior, I would
> invite you to do this intellectual work by yourself.
> >
> > Browsing quickly through Greg's piece, a lot of the reasoning is based
> on FOSS experience from Linux/Juniper, which to the best of my knowledge
> are centralized software projects ?
> >
> > Note, also Paul Storzc's post has the simple phrase :
> >
> > "I emphasized concrete numbers, and concrete dates"
> >
> > I believe my post doesn't have such numbers and concrete dates ?
> >
> > Presence of Core version numbers are motivated as clear signalling for
> L2 developpers to update their backend in case of undocumented, subtle
> policy changes slipping in the codebase. Let's minimize CVE-2020-26895
> style-of-bugs across the ecosystem :/
> >
> > Finally, the presence of timelines in this post is also a gentle call
> for the Bitcoin ecosystem to act on those safety holes, of which the
> seriousness has been underscored by a lot of contributors in the past,
> especially for the pre-signed feerate problem and even before I was in the
> Bitcoin stage.
> >
> > So better to patch them before they do manifest in the wild, and folks
> start to bleed coins.  What you learn from practicing security research,
> the lack of action can be harmful :/
> >
> > > Stuff will get done when it gets done.
> >
> > Don't forget bugs might slip in but that's fine if you have the skilled
> folks around to catch them :)
> >
> > And yes I really care about Lightning, and all those cute new L2
> protocols fostering in the community :)
> >
> > Finally, you know Dave, I'm just spreading ideas.
> >
> > If those ideas are sound and folks love them, awesome! They're free to
> use, study, share and modify them to build better systems.
> >
> > If I'm wrong, like I've been in the past, like I might be today and like
> I'll be in the future, I hope they will be patient to teach me back and
> we'll learn.
> >
> > Hacker ethos :) ?
> >
> > Cheers,
> > Antoine
> >
> > [0]
> https://lists.linuxfoundation.org/pipermail/lightning-dev/2020-January/002448.html
> >
> > [1] https://github.com/bitcoin/bitcoin/issues/14895
> >
> > [2]
> https://lists.linuxfoundation.org/pipermail/lightning-dev/2020-February/002569.html
> >
> > Le sam. 19 juin 2021 à 09:38, David A. Harding <dave@dtrt.org> a écrit :
> >>
> >> On Fri, Jun 18, 2021 at 06:11:38PM -0400, Antoine Riard wrote:
> >> > 2) Solving the Pre-Signed Feerate problem : Package-Relay or
> >> > SIGHASH_ANYPREVOUT
> >> >
> >> > For Lightning, either package-relay or SIGHASH_ANYPREVOUT should be
> able to
> >> > solve the pre-signed feerate issue [3]
> >> >
> >> > [...]
> >> >
> >> > [3] I don't think there is a clear discussion on how
> SIGHASH_ANYPREVOUT
> >> > solves pinnings beyond those LN meetings logs:
> >> > https://gnusha.org/lightning-dev/2020-06-08.log
> >>
> >> For anyone else looking, the most relevant line seems to be:
> >>
> >>   13:50 < BlueMatt> (sidenote: sighash_no_input is *really* elegant here
> >>   - assuming a lot of complicated logic in core to do so, you could
> >>   imagine blind-cpfp-bumping *any* commitment tx without knowing its
> >>   there or which one it is all with one tx.......in theory)
> >>
> >> That might work for current LN-penalty, but I'm not sure it works for
> >> eltoo.  If Bitcoin Core can rewrite the blind CPFP fee bump transaction
> >> to refer to any prevout, that implies anyone else can do the same.
> >> Miners who were aware of two or more states from an eltoo channel would
> >> be incentivized to rewrite to the oldest state, giving them fee revenue
> >> now and ensuring fee revenue in the future when a later state update is
> >> broadcast.
> >>
> >> If the attacker using pinning is able to reuse their attack at no cost,
> >> they can re-pin the channel again and force the honest user to pay
> >> another anyprevout bounty to miners.  Repeat this a bunch of times and
> >> the honest user has now spent more on fees than their balance from the
> >> closed channel.
> >>
> >> Even if my analysis above is wrong, I would encourage you or Matt or
> >> someone to write up this anyprevout idea in more detail and distribute
> >> it before you promote it much more.
> >>
> >> > package-relay sounds a reasonable, temporary "patch".
> >>
> >> Even if every protocol based on presigned transactions can magically
> >> allow dynamically adding inputs and modifying outputs for fees, and we
> >> also have a magic perfect transaction replacement protocol, package
> >> relay is still fundamentally useful for CPFP fee bumping very low
> >> feerate transactions received from an external party.  E.g. Alice pays
> >> Bob, mempool min feerates increase and Alice's transaction is dropped,
> >> Bob still wants the money, so he submits a package with Alice's
> >> transaction plus his own high feerate spend of it.
> >>
> >> Package relay is a clear improvement now, and one I expect to be
> >> permanent for as long as we're using anything like the current protocol.
> >>
> >> > # Deployment timeline
> >> >
> >> > So what I believe as a rough deployment timeline.
> >>
> >> I don't think it's appropriate to be creating timelines like this that
> >> depend on the work of a large number of contributors who I don't believe
> >> you've consulted.  For details on this point of view, please see
> >>
> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-July/014726.html
> >>
> >> Stuff will get done when it gets done.
> >>
> >> -Dave
> >
> > _______________________________________________
> > Lightning-dev mailing list
> > Lightning-dev@lists.linuxfoundation.org
> > https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
>
>
>
> --
> Michael Folkson
> Email: michaelfolkson@gmail.com
> Keybase: michaelfolkson
> PGP: 43ED C999 9F85 1D40 EAF4 9835 92D6 0159 214C FEE3
>

[-- Attachment #2: Type: text/html, Size: 23561 bytes --]