Nostr notes by

📅 Original date posted:2023-10-17 🗒️ Summary of this ...

2023-10-18T15:02:08+02:00

In reply to nevent1q…wsd9
_________________________

📅 Original date posted:2023-10-17
🗒️ Summary of this message: At block height 100, node B forces the B-C channel onchain because the B-C HTLC timelock has expired without node C claiming it. However, the onchain feerates have risen and the transactions do not confirm. At block height 144, node A drops the A-B channel onchain and is able to recover the HTLC funds. Node C then broadcasts an HTLC-success transaction with high feerates that replaces the HTLC-timeout transaction, allowing C to get the value of the HTLC. Node B is no longer able to use the knowledge of the preimage.
📝 Original message:
Hi Zeeman,

> At block height 100, `B` notices the `B->C` HTLC timelock is expired
without `C` having claimed it, so `B` forces the `B====C` channel onchain.
> However, onchain feerates have risen and the commitment transaction and
HTLC-timeout transaction do not confirm.

This is not that the HTLC-timeout does not confirm. It is replaced in
cycles by C's HTLC-preimage which is still valid after `B->C` HTLC timelock
has expired. And this HTLC-preimage is subsequently replaced itself.

See the test here:
https://github.com/ariard/bitcoin/commit/19d61fa8cf22a5050b51c4005603f43d72f1efcf

> At block height 144, `B` is still not able to claim the `A->B` HTLC, so
`A` drops the `A====B` channel onchain.
> As the fees are up-to-date, this confirms immediately and `A` is able to
recover the HTLC funds.
> However, the feerates of the `B====C` pre-signed transactions remain at
the old, uncompetitive feerates.

This is correct that A tries to recover the HTLC funds on the `A===B`
channel.

However, there is no need to consider the fee rates nor mempool congestion
as the exploit lays on the replacement mechanism itself (in simple
scenario).

> At this point, `C` broadcasts an HTLC-success transaction with high
feerates that CPFPs the commitment tx.
> However, it replaces the HTLC-timeout transaction, which is at the old,
low feerate.
> `C` is thus able to get the value of the HTLC, but `B` is now no longer
able to use the knowledge of the preimage, as its own incoming HTLC was
already confirmed as claimed by `A`.

This is correct that `C` broadcasts an HTLC-success transaction at block
height 144.

However `C` broadcasts this high feerate transaction at _every block_
between blocks 100 and 144 to replace B's HTLC-timeout transaction.

> Let me also explain to non-Lightning experts why HTLC-timeout is
presigned in this case and why `B` cannot feebump it.

Note `B` can feebump the HTLC-timeout for anchor output channels thanks to
sighash_single | anyonecanpay on C's signature.

Le mar. 17 oct. 2023 à 11:34, ZmnSCPxj <ZmnSCPxj at protonmail.com> a écrit :

> Good morning Antoine et al.,
>
> Let me try to rephrase the core of the attack.
>
> There exists these nodes on the LN (letters `A`, `B`, and `C` are nodes,
> `==` are channels):
>
> A ===== B ===== C
>
> `A` routes `A->B->C`.
>
> The timelocks, for example, could be:
>
> A->B timeelock = 144
> B->C timelock = 100
>
> The above satisfies the LN BOLT requirements, as long as `B` has a
> `cltv_expiry_delta` of 44 or lower.
>
> After `B` forwards the HTLC `B->C`, C suddenly goes offline, and all the
> signed transactions --- commitment transaction and HTLC-timeout
> transactions --- are "stuck" at the feerate at the time.
>
> At block height 100, `B` notices the `B->C` HTLC timelock is expired
> without `C` having claimed it, so `B` forces the `B====C` channel onchain.
> However, onchain feerates have risen and the commitment transaction and
> HTLC-timeout transaction do not confirm.
>
> In the mean time, `A` is still online with `B` and updates the onchain
> fees of the `A====B` channel pre-signed transactions (commitment tx and
> HTLC-timeout tx) to the latest.
>
> At block height 144, `B` is still not able to claim the `A->B` HTLC, so
> `A` drops the `A====B` channel onchain.
> As the fees are up-to-date, this confirms immediately and `A` is able to
> recover the HTLC funds.
> However, the feerates of the `B====C` pre-signed transactions remain at
> the old, uncompetitive feerates.
>
> At this point, `C` broadcasts an HTLC-success transaction with high
> feerates that CPFPs the commitment tx.
> However, it replaces the HTLC-timeout transaction, which is at the old,
> low feerate.
> `C` is thus able to get the value of the HTLC, but `B` is now no longer
> able to use the knowledge of the preimage, as its own incoming HTLC was
> already confirmed as claimed by `A`.
>
> Is the above restatement accurate?
>
> ----
>
> Let me also explain to non-Lightning experts why HTLC-timeout is presigned
> in this case and why `B` cannot feebump it.
>
> In the Poon-Dryja mechanism, the HTLCs are "infected" by the Poon-Dryja
> penalty case, and are not plain HTLCs.
>
> A plain HTLC offerred by `B` to `C` would look like this:
>
> (B && OP_CLTV) || (C && OP_HASH160)
>
> However, on the commitment transaction held by `B`, it would be infected
> by the penalty case in this way:
>
> (B && C && OP_CLTV) || (C && OP_HASH160) || (C && revocation)
>
> There are two changes:
>
> * The addition of a revocation branch `C && revocation`.
> * The branch claimable by `B` in the "plain" HTLC (`B && OP_CLTV`) also
> includes `C`.
>
> These are necessary in case `B` tries to cheat and this HTLC is on an old,
> revoked transaction.
> If the revoked transaction is *really* old, the `OP_CLTV` would already
> impose a timelock far in the past.
> This means that a plain `B && OP_CLTV` branch can be claimed by `B` if it
> retained this very old revoked transaction.
>
> To prevent that, `C` is added to the `B && OP_CLTV` branch.
> We also introduce an HTLC-timeout transaction, which spends the `B && C &&
> OP_CLTV` branch, and outputs to:
>
> (B && OP_CSV) || (C && revocation)
>
> Thus, even if `B` held onto a very old revoked commitment transaction and
> attempts to spend the timelock branch (because the `OP_CLTV` is for an old
> blockheight), it still has to contend with a new output with a *relative*
> timelock.
>
> Unfortunately, this means that the HTLC-timeout transaction is pre-signed,
> and has a specific feerate.
> In order to change the feerate, both `B` and `C` have to agree to re-sign
> the HTLC-timeout transaction at the higher feerate.
>
> However, the HTLC-success transaction in this case spends the plain `(C &&
> OP_HASH160)` branch, which only involves `C`.
> This allows `C` to feebump the HTLC-success transaction arbitrarily even
> if `B` does not cooperate.
>
> While anchor outputs can be added to the HTLC-timeout transaction as well,
> `C` has a greater advantage here due to being able to RBF the HTLC-timeout
> out of the way (1 transaction), while `B` has to get both HTLC-timeout and
> a CPFP-RBF of the anchor output of the HTLC-timeout transaction (2
> transactions).
> `C` thus requires a smaller fee to achieve a particular feerate due to
> having to push a smaller number of bytes compared to `B`.
>
> Regards,
> ZmnSCPxj
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20231017/e68491ea/attachment-0001.html>;

📅 Original date posted:2023-10-16 🗒️ Summary of this ...

2023-10-18T15:02:08+02:00

In reply to nevent1q…sk67
_________________________

📅 Original date posted:2023-10-16
🗒️ Summary of this message: Cross-posting mempool issues have exposed lightning channels to the risk of loss of funds, potentially affecting other multi-party bitcoin applications. Mitigations have been implemented, but their effectiveness against advanced replacement cycling attacks is still uncertain.
📝 Original message:
(cross-posting mempool issues identified are exposing lightning chan to
loss of funds risks, other multi-party bitcoin apps might be affected)

Hi,

End of last year (December 2022), amid technical discussions on eltoo
payment channels and incentives compatibility of the mempool anti-DoS
rules, a new transaction-relay jamming attack affecting lightning channels
was discovered.

After careful analysis, it turns out this attack is practical and
immediately exposed lightning routing hops carrying HTLC traffic to loss of
funds security risks, both legacy and anchor output channels. A potential
exploitation plausibly happening even without network mempools congestion.

Mitigations have been designed, implemented and deployed by all major
lightning implementations during the last months.

Please find attached the release numbers, where the mitigations should be
present:
- LDK: v0.0.118 - CVE-2023 -40231
- Eclair: v0.9.0 - CVE-2023-40232
- LND: v.0.17.0-beta - CVE-2023-40233
- Core-Lightning: v.23.08.01 - CVE-2023-40234

While neither replacement cycling attacks have been observed or reported in
the wild since the last ~10 months or experimented in real-world conditions
on bitcoin mainet, functional test is available exercising the affected
lightning channel against bitcoin core mempool (26.0 release cycle).

It is understood that a simple replacement cycling attack does not demand
privileged capabilities from an attacker (e.g no low-hashrate power) and
only access to basic bitcoin and lightning software. Yet I still think
executing such an attack successfully requests a fair amount of bitcoin
technical know-how and decent preparation.

>From my understanding of those issues, it is yet to be determined if the
mitigations deployed are robust enough in face of advanced replacement
cycling attackers, especially ones able to combine different classes of
transaction-relay jamming such as pinnings or vetted with more privileged
capabilities.

Please find a list of potential affected bitcoin applications in this full
disclosure report using bitcoin script timelocks or multi-party
transactions, albeit no immediate security risk exposure as severe as the
ones affecting lightning has been identified. Only cursory review of
non-lightning applications has been conducted so far.

There is a paper published summarizing replacement cycling attacks on the
lightning network:
https://github.com/ariard/mempool-research/blob/2023-10-replacement-paper/replacement-cycling.pdf

## Problem

A lightning node allows HTLCs forwarding (in bolt3's parlance accepted HTLC
on incoming link and offered HTLC on outgoing link) should settle the
outgoing state with either a success or timeout before the incoming state
timelock becomes final and an asymmetric defavorable settlement might
happen (cf "Flood & Loot: A Systematic Attack on The Lightning Network"
section 2.3 for a classical exposition of this lightning security property).

Failure to satisfy this settlement requirement exposes a forwarding hop to
a loss of fund risk where the offered HTLC is spent by the outgoing link
counterparty's HTLC-preimage and the accepted HTLC is spent by the incoming
link counterparty's HTLC-timeout.

The specification mandates the incoming HTLC expiration timelock to be
spaced out by an interval of `cltv_expiry_delta` from the outgoing HTLC
expiration timelock, this exact interval value being an implementation and
node policy setting. As a minimal value, the specification recommends 34
blocks of interval. If the timelock expiration I of the inbound HTLC is
equal to 100 from chain tip, the timelock expiration O of the outbound HTLC
must be equal to 66 blocks from chain tip, giving a reasonable buffer of
reaction to the lightning forwarding node.

In the lack of cooperative off-chain settlement of the HTLC on the outgoing
link negotiated with the counterparty (either `update_fulfill_htlc` or
`update_fail_htlc`) when O is reached, the lightning node should broadcast
its commitment transaction. Once the commitment is confirmed (if anchor and
the 1 CSV encumbrance is present), the lightning node broadcasts and
confirms its HTLC-timeout before I height is reached.

Here enter a replacement cycling attack. A malicious channel counterparty
can broadcast its HTLC-preimage transaction with a higher absolute fee and
higher feerate than the honest HTLC-timeout of the victim lightning node
and triggers a replacement. Both for legacy and anchor output channels, a
HTLC-preimage on a counterparty commitment transaction is malleable, i.e
additional inputs or outputs can be added. The HTLC-preimage spends an
unconfirmed and unrelated to the channel parent transaction M and conflicts
its child.

As the HTLC-preimage spends an unconfirmed input that was already included
in the unconfirmed and unrelated child transaction (rule 2), pays an
absolute higher fee of at least the sum paid by the HTLC-timeout and child
transaction (rule 3) and the HTLC-preimage feerate is greater than all
directly conflicting transactions (rule 6), the replacement is accepted.
The honest HTLC-timeout is evicted out of the mempool.

In an ulterior move, the malicious counterparty can replace the parent
transaction itself with another candidate N satisfying the replacement
rules, triggering the eviction of the malicious HTLC-preimage from the
mempool as it was a child of the parent T.

There is no spending candidate of the offered HTLC output for the current
block laying in network mempools.

This replacement cycling tricks can be repeated for each rebroadcast
attempt of the HTLC-timeout by the honest lightning node until expiration
of the inbound HTLC timelock I. Once this height is reached a HTLC-timeout
is broadcast by the counterparty's on the incoming link in collusion with
the one on the outgoing link broadcasting its own HTLC-preimage.

The honest Lightning node has been "double-spent" in its HTLC forwarding.

As a notable factor impacting the success of the attack, a lightning node's
honest HTLC-timeout might be included in the block template of the miner
winning the block race and therefore realizes a spent of the offered
output. In practice, a replacement cycling attack might over-connect to
miners' mempools and public reachable nodes to succeed in a fast eviction
of the HTLC-timeout by its HTLC-preimage. As this latter transaction can
come with a better ancestor-score, it should be picked up on the flight by
economically competitive miners.

A functional test exercising a simple replacement cycling of a HTLC
transaction on bitcoin core mempool is available:
https://github.com/ariard/bitcoin/commits/2023-test-mempool

## Deployed LN mitigations

Aggressive rebroadcasting: As the replacement cycling attacker benefits
from the HTLC-timeout being usually broadcast by lightning nodes only once
every block, or less the replacement cycling malicious transactions paid
only equal the sum of the absolute fees paid by the HTLC, adjusted with the
replacement penalty. Rebroadcasting randomly and multiple times before the
next block increases the absolute fee cost for the attacker.

Implemented and deployed by Eclair, Core-Lightning, LND and LDK .

Local-mempool preimage monitoring: As the replacement cycling attacker in a
simple setup broadcast the HTLC-preimage to all the network mempools, the
honest lightning node is able to catch on the flight the unconfirmed
HTLC-preimage, before its subsequent mempool replacement. The preimage can
be extracted from the second-stage HTLC-preimage and used to fetch the
off-chain inbound HTLC with a cooperative message or go on-chain with it to
claim the accepted HTLC output.

Implemented and deployed by Eclair and LND.

CLTV Expiry Delta: With every jammed block comes an absolute fee cost paid
by the attacker, a risk of the HTLC-preimage being detected or discovered
by the honest lightning node, or the HTLC-timeout to slip in a winning
block template. Bumping the default CLTV delta hardens the odds of success
of a simple replacement cycling attack.

Default setting: Eclair 144, Core-Lightning 34, LND 80 and LDK 72.

## Affected Bitcoin Protocols and Applications

>From my understanding the following list of Bitcoin protocols and
applications could be affected by new denial-of-service vectors under some
level of network mempools congestion. Neither tests or advanced review of
specifications (when available) has been conducted for each of them:
- on-chain DLCs
- coinjoins
- payjoins
- wallets with time-sensitive paths
- peerswap and submarine swaps
- batch payouts
- transaction "accelerators"

Inviting their developers, maintainers and operators to investigate how
replacement cycling attacks might disrupt their in-mempool chain of
transactions, or fee-bumping flows at the shortest delay. Simple flows and
non-multi-party transactions should not be affected to the best of my
understanding.

## Open Problems: Package Malleability

Pinning attacks have been known for years as a practical vector to
compromise lightning channels funds safety, under different scenarios (cf.
current bip331's motivation section). Mitigations at the mempool level have
been designed, discussed and are under implementation by the community
(ancestor package relay + nverrsion=3 policy). Ideally, they should
constraint a pinning attacker to always attach a high feerate package
(commitment + CPFP) to replace the honest package, or allow a honest
lightning node to overbid a malicious pinning package and get its
time-sensitive transaction optimistically included in the chain.

Replacement cycling attack seem to offer a new way to neutralize the design
goals of package relay and its companion nversion=3 policy, where an
attacker package RBF a honest package out of the mempool to subsequently
double-spend its own high-fee child with a transaction unrelated to the
channel. As the remaining commitment transaction is pre-signed with a
minimal relay fee, it can be evicted out of the mempool.

A functional test exercising a simple replacement cycling of a lightning
channel commitment transaction on top of the nversion=3 code branch is
available:
https://github.com/ariard/bitcoin/commits/2023-10-test-mempool-2

## Discovery

In 2018, the issue of static fees for pre-signed lightning transactions is
made more widely known, the carve-out exemption in mempool rules to
mitigate in-mempool package limits pinning and the anchor output pattern
are proposed.

In 2019, bitcoin core 0.19 is released with carve-out support. Continued
discussion of the anchor output pattern as a dynamic fee-bumping method.

In 2020, draft of anchor output submitted to the bolts. Initial finding of
economic pinning against lightning commitment and second-stage HTLC
transactions. Subsequent discussions of a preimage-overlay network or
package-relay as mitigations. Public call made to inquiry more on potential
other transaction-relay jamming attacks affecting lightning.

In 2021, initial work in bitcoin core 22.0 of package acceptance. Continued
discussion of the pinning attacks and shortcomings of current mempool rules
during community-wide online workshops. Later the year, in light of all
issues for bitcoin second-layers, a proposal is made about killing the
mempool.

In 2022, bip proposed for package relay and new proposed v3 policy design
proposed for a review and implementation. Mempoolfullrbf is supported in
bitcoin core 24.0 and conceptual questions about alignment of mempool rules
w.r.t miners incentives are investigated.

Along this year 2022, eltoo lightning channels design are discussed,
implemented and reviewed. In this context and after discussions on mempool
anti-DoS rules, I discovered this new replacement cycling attack was
affecting deployed lightning channels and immediately reported the finding
to some bitcoin core developers and lightning maintainers.

## Timeline

- 2022-12-16: Report of the finding to Suhas Daftuar, Anthony Towns, Greg
Sanders and Gloria Zhao
- 2022-12-16: Report to LN maintainers: Rusty Russell, Bastien Teinturier,
Matt Corallo and Olaoluwa Osuntunkun
- 2022-12-23: Sharing to Eugene Siegel (LND)
- 2022-12-24: Sharing to James O'Beirne and Antoine Poinsot (non-lightning
potential affected projects)
- 2022-01-14: Sharing to Gleb Naumenko (miners incentives and cross-layers
issuers) and initial proposal of an early public disclosure
- 2022-01-19: Collection of analysis if other second-layers and multi-party
applications affected. LN mitigations development starts.
- 2023-05-04: Sharing to Wilmer Paulino (LDK)
- 2023-06-20: LN mitigations implemented and progressively released. Week
of the 16 october proposed for full disclosure.
- 2023-08-10: CVEs assigned by MITRE
- 2023-10-05: Pre-disclosure of LN CVEs numbers and replacement cycling
attack existence to security at bitcoincore.org.
- 2023-10-16: Full disclosure of CVE-2023-40231 / CVE-2023-40232 /
CVE-2023-40233 / CVE-2023-40234 and replacement cycling attacks

## Conclusion

Despite the line of mitigations adopted and deployed by current major
lightning implementations, I believe replacement cycling attacks are still
practical for advanced attackers. Beyond this new attack might come as a
way to partially or completely defeat some of the pinning mitigations which
have been working for years as a community.

As of today, it is uncertain to me if lightning is not affected by a more
severe long-term package malleability critical security issue under current
consensus rules, and if any other time-sensitive multi-party protocol,
designed or deployed isn't de facto affected too (loss of funds or denial
of service).

Assuming analysis on package malleability is correct, it is unclear to me
if it can be corrected by changes in replacement / eviction rules or
mempool chain of transactions processing strategy. Inviting my technical
peers and the bitcoin community to look more on this issue, including to
dissent. I'll be the first one pleased if I'm fundamentally wrong on those
issues, or if any element has not been weighted with the adequate technical
accuracy it deserves.

Do not trust, verify. All mistakes and opinions are my own.

Antoine

"meet with Triumph and Disaster. And treat those two impostors just the
same" - K.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20231016/6e4e649f/attachment-0001.html>;

📅 Original date posted:2023-10-17 🗒️ Summary of this ...

2023-10-18T15:02:08+02:00

In reply to nevent1q…78cc
_________________________

📅 Original date posted:2023-10-17
🗒️ Summary of this message: No pinning attacks have been observed on the mainnet. Monitoring mempool logs can help detect suspicious behavior. Feebumping could be considered as a mitigation strategy.
📝 Original message:
Hi Ziggie,

> thanks for this detailed explanation. This class of pinning attacks sound
not too unlikely especially if the attacker targets channels with high
capacity and very loose channel policies (allowing the full htlc
> amount to be the channel capacity). Could you add more details about the
attack you observed on mainnet ? How did you monitor the chain, are the
some tools available I can run in parallel to my
> lightning software to record this kind of suspicious behaviour (which did
you use)?

Just to give a clarification no _such_ attack has been observed on mainnet,
since I and other LN maintainers have been aware of this issue. If there is
a confusion on the disclosure mail thanks to point to it, I'll correct it.

We discussed privately to experiment a demo attack in restrained dev
circles, like we have done in the past for some LN sec issues. We have
conducted one so far, multiple scenarios to look at.

I confirm the risk of exposure if an attacker targets channels with high
capacity and loose channel policies. Note there is no way to configure the
cap for the total value of outbound HTLC in-flight, which is the flow
affected.

If you would like to observe the existence of such an attack happening,
look at your mempool logs and the amount of HTLC output being
systematically conflicted out with the following sequence (HTLC-timeout -
HTLC-preimage - HTLC-timeout - ...).

As an observation note, this is not akin to a pinning attack, as there is
no "honest" or "malicious" transaction pinned in network mempools. And it
can happen without network mempools congestion.

> What's also worth mentioning here is that you do not really have to
control 2 neighbouring nodes to target your victim. If you can cycle the
attack on the tail side and delay the confirmation of the htlc- timeout
covenant the peer at the front (incoming link) of the victim will
force-close the channel and claim his timeout-path in the same way
(canceling back the initial htlc amount to the attackers initial node).

I think this is a behavior worthy of testing.

> Apart from that I think one can even introduce some kind of feebumping
race between the victim and the attacker on the tail side of the attack
making the attack even more costly. I think
> currently when lightning nodes see the preimage in the mempool (during
the time where they already can spend the same output with the
timeout-covenant) we are honest and just extract
> the preimage and don't try to race this tx output.

Local-mempool preimage monitoring has been implemented by Eclair for years
as a mitigation against old school pinning attacks on second-stage HTLC
transactions.

This mechanism has been implemented by LND in the last months, following
the report of replacement cycling attacks. As of today this is not
implemented by Core-Lightning or LDK.

> So we maybe should start feebumping this output if we end up in this
scenario? If we see the preimage and can also claim this output via the
htlc-timeout path, we should aggressively fee-bump (racing this output) our
htlc-output in addition to grabbing the preimage and claiming it on the
incoming. This is only feasible with anchor channels where we can add fees
to the htlc-covenant. This would make the attack more costly for a peer
when he knows that we use fees up to 50% of the htlc value. When you cycle
this 144 times you will be at a heavy loss trying to steal this htlc.

This is the "defensive fee mitigation" proposed in the paper. Coming with
some unknown.

> I would add another mitigation to the list for node runners to restrict
the amount and number of HTLCs for big channels to unknown peers. It
quickly comes with a loss when the HTLCs the attacker tries to steal are
small.

See the point above on the lack of way at the spec-level to negotiate cap
on the total value of outbound HTLC in-flight.

Le mar. 17 oct. 2023 à 08:21, ziggie1984 <ziggie1984 at protonmail.com> a
écrit :

> ## Deployed LN mitigations
>
> Aggressive rebroadcasting: As the replacement cycling attacker benefits
> from the HTLC-timeout being usually broadcast by lightning nodes only once
> every block, or less the replacement cycling malicious transactions paid
> only equal the sum of the absolute fees paid by the HTLC, adjusted with the
> replacement penalty. Rebroadcasting randomly and multiple times before the
> next block increases the absolute fee cost for the attacker.
>
> Implemented and deployed by Eclair, Core-Lightning, LND and LDK .
>
> Local-mempool preimage monitoring: As the replacement cycling attacker in
> a simple setup broadcast the HTLC-preimage to all the network mempools, the
> honest lightning node is able to catch on the flight the unconfirmed
> HTLC-preimage, before its subsequent mempool replacement. The preimage can
> be extracted from the second-stage HTLC-preimage and used to fetch the
> off-chain inbound HTLC with a cooperative message or go on-chain with it to
> claim the accepted HTLC output.
>
>
> Hi Antoine,
>
> thanks for this detailed explanation. This class of pinning attacks sound
> not too unlikely especially if the attacker targets channels with high
> capacity and very loose channel policies (allowing the full htlc amount to
> be the channel capacity). Could you add more details about the attack you
> observed on mainnet ? How did you monitor the chain, are the some tools
> available I can run in parallel to my lightning software to record this
> kind of suspicious behaviour (which did you use)?
> What's also worth mentioning here is that you do not really have to
> control 2 neighbouring nodes to target your victim. If you can cycle the
> attack on the tail side and delay the confirmation of the htlc-timeout
> covenant the peer at the front (incoming link) of the victim will
> force-close the channel and claim his timeout-path in the same way
> (canceling back the initial htlc amount to the attackers initial node).
>
> Apart from that I think one can even introduce some kind of feebumping
> race between the victim and the attacker on the tail side of the attack
> making the attack even more costly. I think currently when lightning nodes
> see the preimage in the mempool (during the time where they already can
> spend the same output with the timeout-covenant) we are honest and just
> extract the preimage and don't try to race this tx output. So we maybe
> should start feebumping this output if we end up in this scenario? If we
> see the preimage and can also claim this output via the htlc-timeout path,
> we should aggressively fee-bump (racing this output) our htlc-output in
> addition to grabbing the preimage and claiming it on the incoming. This is
> only feasible with anchor channels where we can add fees to the
> htlc-covenant. This would make the attack more costly for a peer when he
> knows that we use fees up to 50% of the htlc value. When you cycle this 144
> times you will be at a heavy loss trying to steal this htlc.
>
> I would add another mitigation to the list for node runners to restrict
> the amount and number of HTLCs for big channels to unknown peers. It
> quickly comes with a loss when the HTLCs the attacker tries to steal are
> small.
>
>
> Kind regards,
>
> ziggie
>
>
> ------- Original Message -------
> On Monday, October 16th, 2023 at 18:57, Antoine Riard <
> antoine.riard at gmail.com> wrote:
>
> (cross-posting mempool issues identified are exposing lightning chan to
> loss of funds risks, other multi-party bitcoin apps might be affected)
>
> Hi,
>
> End of last year (December 2022), amid technical discussions on eltoo
> payment channels and incentives compatibility of the mempool anti-DoS
> rules, a new transaction-relay jamming attack affecting lightning channels
> was discovered.
>
> After careful analysis, it turns out this attack is practical and
> immediately exposed lightning routing hops carrying HTLC traffic to loss of
> funds security risks, both legacy and anchor output channels. A potential
> exploitation plausibly happening even without network mempools congestion.
>
> Mitigations have been designed, implemented and deployed by all major
> lightning implementations during the last months.
>
> Please find attached the release numbers, where the mitigations should be
> present:
> - LDK: v0.0.118 - CVE-2023 -40231
> - Eclair: v0.9.0 - CVE-2023-40232
> - LND: v.0.17.0-beta - CVE-2023-40233
> - Core-Lightning: v.23.08.01 - CVE-2023-40234
>
> While neither replacement cycling attacks have been observed or reported
> in the wild since the last ~10 months or experimented in real-world
> conditions on bitcoin mainet, functional test is available exercising the
> affected lightning channel against bitcoin core mempool (26.0 release
> cycle).
>
> It is understood that a simple replacement cycling attack does not demand
> privileged capabilities from an attacker (e.g no low-hashrate power) and
> only access to basic bitcoin and lightning software. Yet I still think
> executing such an attack successfully requests a fair amount of bitcoin
> technical know-how and decent preparation.
>
> From my understanding of those issues, it is yet to be determined if the
> mitigations deployed are robust enough in face of advanced replacement
> cycling attackers, especially ones able to combine different classes of
> transaction-relay jamming such as pinnings or vetted with more privileged
> capabilities.
>
> Please find a list of potential affected bitcoin applications in this full
> disclosure report using bitcoin script timelocks or multi-party
> transactions, albeit no immediate security risk exposure as severe as the
> ones affecting lightning has been identified. Only cursory review of
> non-lightning applications has been conducted so far.
>
> There is a paper published summarizing replacement cycling attacks on the
> lightning network:
>
> https://github.com/ariard/mempool-research/blob/2023-10-replacement-paper/replacement-cycling.pdf
>
> ## Problem
>
> A lightning node allows HTLCs forwarding (in bolt3's parlance accepted
> HTLC on incoming link and offered HTLC on outgoing link) should settle the
> outgoing state with either a success or timeout before the incoming state
> timelock becomes final and an asymmetric defavorable settlement might
> happen (cf "Flood & Loot: A Systematic Attack on The Lightning Network"
> section 2.3 for a classical exposition of this lightning security property).
>
> Failure to satisfy this settlement requirement exposes a forwarding hop to
> a loss of fund risk where the offered HTLC is spent by the outgoing link
> counterparty's HTLC-preimage and the accepted HTLC is spent by the incoming
> link counterparty's HTLC-timeout.
>
> The specification mandates the incoming HTLC expiration timelock to be
> spaced out by an interval of `cltv_expiry_delta` from the outgoing HTLC
> expiration timelock, this exact interval value being an implementation and
> node policy setting. As a minimal value, the specification recommends 34
> blocks of interval. If the timelock expiration I of the inbound HTLC is
> equal to 100 from chain tip, the timelock expiration O of the outbound HTLC
> must be equal to 66 blocks from chain tip, giving a reasonable buffer of
> reaction to the lightning forwarding node.
>
> In the lack of cooperative off-chain settlement of the HTLC on the
> outgoing link negotiated with the counterparty (either
> `update_fulfill_htlc` or `update_fail_htlc`) when O is reached, the
> lightning node should broadcast its commitment transaction. Once the
> commitment is confirmed (if anchor and the 1 CSV encumbrance is present),
> the lightning node broadcasts and confirms its HTLC-timeout before I height
> is reached.
>
> Here enter a replacement cycling attack. A malicious channel counterparty
> can broadcast its HTLC-preimage transaction with a higher absolute fee and
> higher feerate than the honest HTLC-timeout of the victim lightning node
> and triggers a replacement. Both for legacy and anchor output channels, a
> HTLC-preimage on a counterparty commitment transaction is malleable, i.e
> additional inputs or outputs can be added. The HTLC-preimage spends an
> unconfirmed and unrelated to the channel parent transaction M and conflicts
> its child.
>
> As the HTLC-preimage spends an unconfirmed input that was already included
> in the unconfirmed and unrelated child transaction (rule 2), pays an
> absolute higher fee of at least the sum paid by the HTLC-timeout and child
> transaction (rule 3) and the HTLC-preimage feerate is greater than all
> directly conflicting transactions (rule 6), the replacement is accepted.
> The honest HTLC-timeout is evicted out of the mempool.
>
> In an ulterior move, the malicious counterparty can replace the parent
> transaction itself with another candidate N satisfying the replacement
> rules, triggering the eviction of the malicious HTLC-preimage from the
> mempool as it was a child of the parent T.
>
> There is no spending candidate of the offered HTLC output for the current
> block laying in network mempools.
>
> This replacement cycling tricks can be repeated for each rebroadcast
> attempt of the HTLC-timeout by the honest lightning node until expiration
> of the inbound HTLC timelock I. Once this height is reached a HTLC-timeout
> is broadcast by the counterparty's on the incoming link in collusion with
> the one on the outgoing link broadcasting its own HTLC-preimage.
>
> The honest Lightning node has been "double-spent" in its HTLC forwarding.
>
> As a notable factor impacting the success of the attack, a lightning
> node's honest HTLC-timeout might be included in the block template of the
> miner winning the block race and therefore realizes a spent of the offered
> output. In practice, a replacement cycling attack might over-connect to
> miners' mempools and public reachable nodes to succeed in a fast eviction
> of the HTLC-timeout by its HTLC-preimage. As this latter transaction can
> come with a better ancestor-score, it should be picked up on the flight by
> economically competitive miners.
>
> A functional test exercising a simple replacement cycling of a HTLC
> transaction on bitcoin core mempool is available:
> https://github.com/ariard/bitcoin/commits/2023-test-mempool
>
> ## Deployed LN mitigations
>
> Aggressive rebroadcasting: As the replacement cycling attacker benefits
> from the HTLC-timeout being usually broadcast by lightning nodes only once
> every block, or less the replacement cycling malicious transactions paid
> only equal the sum of the absolute fees paid by the HTLC, adjusted with the
> replacement penalty. Rebroadcasting randomly and multiple times before the
> next block increases the absolute fee cost for the attacker.
>
> Implemented and deployed by Eclair, Core-Lightning, LND and LDK .
>
> Local-mempool preimage monitoring: As the replacement cycling attacker in
> a simple setup broadcast the HTLC-preimage to all the network mempools, the
> honest lightning node is able to catch on the flight the unconfirmed
> HTLC-preimage, before its subsequent mempool replacement. The preimage can
> be extracted from the second-stage HTLC-preimage and used to fetch the
> off-chain inbound HTLC with a cooperative message or go on-chain with it to
> claim the accepted HTLC output.
>
> Implemented and deployed by Eclair and LND.
>
> CLTV Expiry Delta: With every jammed block comes an absolute fee cost paid
> by the attacker, a risk of the HTLC-preimage being detected or discovered
> by the honest lightning node, or the HTLC-timeout to slip in a winning
> block template. Bumping the default CLTV delta hardens the odds of success
> of a simple replacement cycling attack.
>
> Default setting: Eclair 144, Core-Lightning 34, LND 80 and LDK 72.
>
> ## Affected Bitcoin Protocols and Applications
>
> From my understanding the following list of Bitcoin protocols and
> applications could be affected by new denial-of-service vectors under some
> level of network mempools congestion. Neither tests or advanced review of
> specifications (when available) has been conducted for each of them:
> - on-chain DLCs
> - coinjoins
> - payjoins
> - wallets with time-sensitive paths
> - peerswap and submarine swaps
> - batch payouts
> - transaction "accelerators"
>
> Inviting their developers, maintainers and operators to investigate how
> replacement cycling attacks might disrupt their in-mempool chain of
> transactions, or fee-bumping flows at the shortest delay. Simple flows and
> non-multi-party transactions should not be affected to the best of my
> understanding.
>
> ## Open Problems: Package Malleability
>
> Pinning attacks have been known for years as a practical vector to
> compromise lightning channels funds safety, under different scenarios (cf.
> current bip331's motivation section). Mitigations at the mempool level have
> been designed, discussed and are under implementation by the community
> (ancestor package relay + nverrsion=3 policy). Ideally, they should
> constraint a pinning attacker to always attach a high feerate package
> (commitment + CPFP) to replace the honest package, or allow a honest
> lightning node to overbid a malicious pinning package and get its
> time-sensitive transaction optimistically included in the chain.
>
> Replacement cycling attack seem to offer a new way to neutralize the
> design goals of package relay and its companion nversion=3 policy, where an
> attacker package RBF a honest package out of the mempool to subsequently
> double-spend its own high-fee child with a transaction unrelated to the
> channel. As the remaining commitment transaction is pre-signed with a
> minimal relay fee, it can be evicted out of the mempool.
>
> A functional test exercising a simple replacement cycling of a lightning
> channel commitment transaction on top of the nversion=3 code branch is
> available:
> https://github.com/ariard/bitcoin/commits/2023-10-test-mempool-2
>
> ## Discovery
>
> In 2018, the issue of static fees for pre-signed lightning transactions is
> made more widely known, the carve-out exemption in mempool rules to
> mitigate in-mempool package limits pinning and the anchor output pattern
> are proposed.
>
> In 2019, bitcoin core 0.19 is released with carve-out support. Continued
> discussion of the anchor output pattern as a dynamic fee-bumping method.
>
> In 2020, draft of anchor output submitted to the bolts. Initial finding of
> economic pinning against lightning commitment and second-stage HTLC
> transactions. Subsequent discussions of a preimage-overlay network or
> package-relay as mitigations. Public call made to inquiry more on potential
> other transaction-relay jamming attacks affecting lightning.
>
> In 2021, initial work in bitcoin core 22.0 of package acceptance.
> Continued discussion of the pinning attacks and shortcomings of current
> mempool rules during community-wide online workshops. Later the year, in
> light of all issues for bitcoin second-layers, a proposal is made about
> killing the mempool.
>
> In 2022, bip proposed for package relay and new proposed v3 policy design
> proposed for a review and implementation. Mempoolfullrbf is supported in
> bitcoin core 24.0 and conceptual questions about alignment of mempool rules
> w.r.t miners incentives are investigated.
>
> Along this year 2022, eltoo lightning channels design are discussed,
> implemented and reviewed. In this context and after discussions on mempool
> anti-DoS rules, I discovered this new replacement cycling attack was
> affecting deployed lightning channels and immediately reported the finding
> to some bitcoin core developers and lightning maintainers.
>
> ## Timeline
>
> - 2022-12-16: Report of the finding to Suhas Daftuar, Anthony Towns, Greg
> Sanders and Gloria Zhao
> - 2022-12-16: Report to LN maintainers: Rusty Russell, Bastien Teinturier,
> Matt Corallo and Olaoluwa Osuntunkun
> - 2022-12-23: Sharing to Eugene Siegel (LND)
> - 2022-12-24: Sharing to James O'Beirne and Antoine Poinsot (non-lightning
> potential affected projects)
> - 2022-01-14: Sharing to Gleb Naumenko (miners incentives and cross-layers
> issuers) and initial proposal of an early public disclosure
> - 2022-01-19: Collection of analysis if other second-layers and
> multi-party applications affected. LN mitigations development starts.
> - 2023-05-04: Sharing to Wilmer Paulino (LDK)
> - 2023-06-20: LN mitigations implemented and progressively released. Week
> of the 16 october proposed for full disclosure.
> - 2023-08-10: CVEs assigned by MITRE
> - 2023-10-05: Pre-disclosure of LN CVEs numbers and replacement cycling
> attack existence to security at bitcoincore.org.
> - 2023-10-16: Full disclosure of CVE-2023-40231 / CVE-2023-40232 /
> CVE-2023-40233 / CVE-2023-40234 and replacement cycling attacks
>
> ## Conclusion
>
> Despite the line of mitigations adopted and deployed by current major
> lightning implementations, I believe replacement cycling attacks are still
> practical for advanced attackers. Beyond this new attack might come as a
> way to partially or completely defeat some of the pinning mitigations which
> have been working for years as a community.
>
> As of today, it is uncertain to me if lightning is not affected by a more
> severe long-term package malleability critical security issue under current
> consensus rules, and if any other time-sensitive multi-party protocol,
> designed or deployed isn't de facto affected too (loss of funds or denial
> of service).
>
> Assuming analysis on package malleability is correct, it is unclear to me
> if it can be corrected by changes in replacement / eviction rules or
> mempool chain of transactions processing strategy. Inviting my technical
> peers and the bitcoin community to look more on this issue, including to
> dissent. I'll be the first one pleased if I'm fundamentally wrong on those
> issues, or if any element has not been weighted with the adequate technical
> accuracy it deserves.
>
> Do not trust, verify. All mistakes and opinions are my own.
>
> Antoine
>
> "meet with Triumph and Disaster. And treat those two impostors just the
> same" - K.
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20231017/9d438d0e/attachment-0001.html>;

📅 Original date posted:2023-09-25 🗒️ Summary of this ...

2023-10-03T23:44:18+02:00

In reply to nevent1q…thwn
_________________________

📅 Original date posted:2023-09-25
🗒️ Summary of this message: Payment pools and channel factories face limitations in interactivity, affecting the security of user funds. Proposed solutions include introducing a coordinator or partitioning balances, but these may not be economically practical. A potential solution is to prevent off-chain group equivocation by editing the funding utxo in a way that allows for the registration of new off-chain subgroups. CoinPool's idea of including user pubkeys and balance amounts in Taproot leaves could be utilized for privacy-preserving payments and contracts.
📝 Original message:
Payment pools and channel factories are afflicted by severe interactivity
constraints worsening with the number of users owning an off-chain balance
in the construction. The security of user funds is paramount on the ability
to withdraw unilaterally from the off-chain construction. As such any
update applied to the off-chain balances requires a signature contribution
from the unanimity of the construction users to ensure this ability is
conserved along updates.

As soon as one user starts to be offline or irresponsive, the updates of
the off-chain balances must have to be halted and payments progress are
limited among subsets of 2 users sharing a channel. Different people have
proposed solutions to this issue: introducing a coordinator, partitioning
or layering balances in off-chain users subsets. I think all those
solutions have circled around a novel issue introduced, namely equivocation
of off-chain balances at the harm of construction counterparties [0].

As ZmnSCPxj pointed out recently, one way to mitigate this equivocation
consists in punishing the cheating pre-nominated coordinator on an external
fidelity bond. One can even imagine more trust-mimized and decentralized
fraud proofs to implement this mitigation, removing the need of a
coordinator [1].

However, I believe punishment equivocation to be game-theory sound should
compensate a defrauded counterparty of the integrity of its lost off-chain
balance. As one cheating counterparty can equivocate in the worst-case
against all the other counterparties in the construction, one fidelity bond
should be equal to ( C - 1 ) * B satoshi amount, where C is the number of
construction counterparty and B the initial off-chain balance of the
cheating counterparty.

Moreover, I guess it is impossible to know ahead of a partition or
transition who will be the "honest" counterparties from the "dishonest"
ones, therefore this ( C - 1 ) * B-sized fidelity bond must be maintained
by every counterparty in the pool or factory. On this ground, I think this
mitigation and other corrective ones are not economically practical for
large-scale pools among a set of anonymous users.

I think the best solution to solve the interactivity issue which is
realistic to design is one ruling out off-chain group equivocation in a
prophylactic fashion. The pool or factory funding utxo should be edited in
an efficient way to register new off-chain subgroups, as lack of
interactivity from a subset of counterparties demands it.

With CoinPool, there is already this idea of including a user pubkey and
balance amount to each leaf composing the Taproot tree while preserving the
key-path spend in case of unanimity in the user group. Taproot leaves can
be effectively regarded as off-chain user accounts available to realize
privacy-preserving payments and contracts.

I think one (new ?) idea can be to introduce taproot leaves "cut-through"
spends where multiple leaves are updated with a single witness,
interactively composed by the owners of the spent leaves. This spend sends
back the leaves amount to a new single leaf, aggregating the amounts and
user pubkeys. The user leaves not participating in this "cut-through" are
inherited with full integrity in the new version of the Taproot tree, at
the gain of no interactivity from their side.

Let's say you have a CoinPool funded and initially set with Alice, Bob,
Caroll, Dave and Eve. Each pool participant has a leaf L.x committing to an
amount A.x and user pubkey P.x, where x is the user name owning a leaf.

Bob and Eve are deemed to be offline by the Alice, Caroll and Dave subset
(the ACD group).

The ACD group composes a cut-through spend of L.a + L.c + L.d. This spends
generates a new leaf L.(acd) leaf committing to amount A.(acd) and P.(acd).

Amount A.(acd) = A.a + A.c + A.d and pubkey P.(acd) = P.a + P.c + P.d.

Bob's leaf L.b and Eve's leaf L.e are left unmodified.

The ACD group generates a new Taproot tree T' = L.(acd) + L.b + L.e, where
the key-path K spend including the original unanimity of pool
counterparties is left unmodified.

The ACD group can confirm a transaction spending the pool funding utxo to a
new single output committing to the scriptpubkey K + T'.

>From then, the ACD group can pursue off-chain balance updates among the
subgroup thanks to the new P.(acd) and relying on the known Eltoo
mechanism. There is no possibility for any member of the ACD group to
equivocate with Bob or Eve in a non-observable fashion.

Once Bob and Eve are online and ready to negotiate an on-chain pool
"refresh" transaction, the conserved key-path spend can be used to
re-equilibrate the Taproot tree, prune out old subgroups unlikely to be
used and provision future subgroups, all with a compact spend based on
signature aggregation.

Few new Taproot tree update script primitives have been proposed, e.g [2].
Though I think none with the level of flexibility offered to generate
leaves cut-through spends, or even batch of "cut-through" where M subgroups
are willing to spend N leaves to compose P new subgroups fan-out in Q new
outputs, with showing a single on-chain witness. I believe such a
hypothetical primitive can also reduce the chain space consumed in the
occurrence of naive mass pool withdraws at the same time.

I think this solution to the high-interactivity issue of payment pools and
factories shifts the burden on each individual user to pre-commit fast
Taproot tree traversals, allowing them to compose new pool subgroups as
fluctuations in pool users' level of liveliness demand it. Pool efficiency
becomes the sum of the quality of user prediction on its counterparties'
liveliness during the construction lifetime. Recursive taproot tree spends
or more efficient accumulator than merkle tree sounds ideas to lower the
on-chain witness space consumed by every pool in the average
non-interactive case.

Cheers,
Antoine

[0]
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-April/020370.html
[1]
https://lists.linuxfoundation.org/pipermail/lightning-dev/2023-August/004043.html
[2]
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-September/019420.html
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20230925/77e3936d/attachment.html>;

📅 Original date posted:2023-08-14 🗒️ Summary of this ...

2023-08-16T02:45:52+02:00

In reply to nevent1q…47rh
_________________________

📅 Original date posted:2023-08-14
🗒️ Summary of this message: The author discusses the potential risks of cross-input inspection in Bitcoin contracts, such as miners bribing contracts to censor transactions. They propose using flags or tags to enable selective introspection of inputs/outputs. The author also mentions the need for more malleability and efficient witness space consumption.
📝 Original message:
Hi Salvatore,

> This also allows inspection of other inputs, that was not possible with
the original opcodes.

I think cross-input inspection (not cross-input signature aggregation which
is different) is opening a pandora box in terms of "malicious" off-chain
contracts than one could design. E.g miners bribing contracts to censor the
confirmation of time-sensitive lightning channel transactions, where the
bribes are paid on the hashrate distribution of miners during the previous
difficulty period, thanks to the coinbase pubkey.

See https://blog.bitmex.com/txwithhold-smart-contracts/ and
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2023-February/021395.html

I wonder if we might face the dilemma of miners censorship attacks, if we
wish to have more advanced bitcoin contracts, though I think it would be
safe design practice to rule out those types of concerns thanks to smart
bitcoin contracting primitives.

I think this is a common risk to all second-layers vaults, lightning
channels and payment pools.

> A flag can disable this behavior"

More than a binary flag like a matrix could be introduced to encode subset
of introspected inputs /outputs to enable sighash_group-like semantic:
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-July/019243.html

> There are two defined flags:
> - CCV_FLAG_CHECK_INPUT = 1: if present, <index> refers to an input;
> otherwise, it refers to an output.
> - CCV_FLAG_IGNORE_OUTPUT_AMOUNT = 2: only defined when _CHECK_INPUT
> is absent, it disables the deferred checks logic for amounts.

Or even beyond a matrix, it could be a set of "tags". There could be a
generalized tag for unstructured data, and another one for bitcoin
transaction / script data types (e.g scriptpubkey, amount, nsequence,
merkle branch) that could be fetched from the taproot annex.

> After the evaluation of all inputs, it is verified that each output's
> amount is greater than or equal to the total amount in the bucket
> if that output (validation of the deferred checks).

At the very least, I think for the payment pool, where you're fanning-out
satoshis value from a subset of inputs to another subset of outputs, I
think you would need more malleability here.

> It is unclear if all the special values above will be useful in
> applications; however, as each special case requires very little added
> code, I tried to make the specs as flexible as possible at this time.

I think this generic framework is interesting for joinpool / coinpool /
payment pool, as you can check that any withdrawal output can be committed
as part of the input scriptpubkey, and spend it on
blessed-with-one-participant-sig script. There is still a big open question
if it's efficient in terms of witness space consumed.

That said, I still think you would need at least ANYPREVOUT and more
malleability for the amount transfer validation as laid out above.

Looking on the `DeferredCheck` framework commit, one obvious low-level
concern is the DoS risk for full-nodes participating in transaction-relay,
and that maybe policy rules should be introduced to keep the worst-CPU
input in the ranges of current transaction spend allowed to propagate on
the network today.

Thanks for the proposal,

Best,
Antoine

Le dim. 30 juil. 2023 à 22:52, Salvatore Ingala via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> a écrit :

> Hi all,
>
> I have put together a first complete proposal for the core opcodes of
> MATT [1][2].
> The changes make the opcode functionally complete, and the
> implementation is revised and improved.
>
> The code is implemented in the following fork of the
> bitcoin-inquisition repo:
>
> https://github.com/Merkleize/bitcoin/tree/checkcontractverify
>
> Therefore, it also includes OP_CHECKTEMPLATEVERIFY, as in a
> previous early demo for vaults [3].
>
> Please check out the diff [4] if you are interested in the
> implementation details. It includes some basic functional tests for
> the main cases of the opcode.
>
> ## Changes vs the previous draft
>
> These are the changes compared to the initial incomplete proposal:
> - OP_CHECK{IN,OUT}CONTRACTVERIFY are replaced by a single opcode
> OP_CHECKCONTRACTVERIFY (CCV). An additional `flags` parameter allows
> to specify if the opcode operates on an input or an output.
> This also allows inspection of other inputs, that was not possible
> with the original opcodes.
> - For outputs, the default behavior is to have the following deferred
> checks mechanism for amounts: all the inputs that have a CCV towards
> the same output, have their input amounts summed, and that act as a
> lower bound for that output's amount.
> A flag can disable this behavior. [*]
> - A number of special values of the parameters were defined in order
> to optimize for common cases, and add some implicit introspection.
> - The order of parameters is modified (particularly, <data> is at the
> bottom of the arguments, as so is more natural when writing Scripts).
>
> ## Semantics
>
> The new OP_CHECKCONTRACTVERIFY takes 5 parameters from the stack:
>
> <data>, <index>, <pk>, <taptree>, <flags>
>
> The core logic of the opcode is as follows:
>
> "Check if the <index>-th input/output's scriptPubKey is a P2TR
> whose public key is obtained from <pk>, (optionally) tweaked with
> <data>, (optionally) tap-tweaked with <taptree>".
>
> The following are special values of the parameters:
>
> - if <pk> is empty, it is replaced with a fixed NUMS point. [**]
> - if <pk> is -1, it is replaced with the current input's taproot
> internal key.
> - if <index> is -1, it is replaced with the current input's index.
> - if <data> is empty, the data tweak is skipped.
> - if <taptree> is empty, the taptweak is skipped.
> - if <taptree> is -1, it is replaced with the current input's root
> of the taproot merkle tree.
>
> There are two defined flags:
> - CCV_FLAG_CHECK_INPUT = 1: if present, <index> refers to an input;
> otherwise, it refers to an output.
> - CCV_FLAG_IGNORE_OUTPUT_AMOUNT = 2: only defined when _CHECK_INPUT
> is absent, it disables the deferred checks logic for amounts.
>
> Finally, if both the flags CCV_FLAG_CHECK_INPUT and
> CCV_FLAG_IGNORE_OUTPUT_AMOUNT are absent:
> - Add the current input's amount to the <index>-th output's bucket.
>
> After the evaluation of all inputs, it is verified that each output's
> amount is greater than or equal to the total amount in the bucket
> if that output (validation of the deferred checks).
>
> ## Comment
>
> It is unclear if all the special values above will be useful in
> applications; however, as each special case requires very little added
> code, I tried to make the specs as flexible as possible at this time.
>
> With this new opcode, the full generality of MATT (including the fraud
> proofs) can be obtained with just two opcodes: OP_CHECKCONTRACTVERIFY
> and OP_CAT.
> However, additional opcodes (and additional introspection) would
> surely benefit some applications.
>
> I look forward to your comments, and to start drafting a BIP proposal.
>
> Best,
> Salvatore Ingala
>
>
> [*] - Credits go to James O'Beirne for this approach, taken from his
> OP_VAULT proposal. I cherry-picked the commit containing the
> Deferred Checks framework.
> [**] - The same NUMS point suggested in BIP-0341 was used.
>
>
> References:
>
> [1] - https://merkle.fun/
> [2] -
> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-November/021182.html
> [3] -
> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2023-April/021588.html
> [4] -
> https://github.com/bitcoin-inquisition/bitcoin/compare/24.0...Merkleize:bitcoin:checkcontractverify
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20230814/cef35006/attachment-0001.html>;

📅 Original date posted:2023-07-25 🗒️ Summary of this ...

2023-07-27T02:22:34+02:00

In reply to nevent1q…acuc
_________________________

📅 Original date posted:2023-07-25
🗒️ Summary of this message: Proposal to use a tapscript branch instead of MuSig2 signing for unilateral closes in the Lightning Network. Discusses dynamic fees and Bitcoin as a universal clock.
📝 Original message:
Hi Zeeman,

> A proposal I made in the Signal group after the summit would be to not
use MuSig2 signing for commitment transactions (== unilateral closes).
> Instead, we add a tapscript branch that is just `<A> OP_CHECKSIGVERIFY
<B> OP_CHECKSIG` and use that for unilateral closes.
> We only sign with MuSig2 on mutual closes, after we have negotiated
closing fees (whether that is the current long closing conversation, or
simplified closing) so that only mutual closes require nonce
> storage.
>
> As mutual closes assume continuous connectivity anyway, we can keep
counterparty nonces in volatile RAM and not store nonces in persistent
storage; if a disconnection occurs, we just remove it from
> volatile RAM and restart the mutual close negotiation on reconnection.
>
> This is more palatable as even with a very restrictive hardware device
you do not have to store the peer nonce in persistent storage.
> The hope is that mutual closes dominate over unilateral closes.

Hardware devices with reasonable persistent storage sounds cheaper than the
additional fee-bumping reverse one (locally or a third-party), must
conserve to pay for the probabilistic worst-case `<A> OP_CHECKSIGVERIFY <B>
OP_CHECKSIG` satisfying witness.

> Conditinoal fees already on the Lightning Network are already dynamic,
with many people (including myself) writing software that measures demand
and changes price accordingly.
> Why would unconditional fees be necessarily static, when there is no
mention of it being static?

While I'm in sync with you on the Lightning Network being a system driven
by demand and charge price accordingly, some of the recent jamming
mitigation proposals where build on the proposal of "static fees" or
unconditional fees, e.g https://eprint.iacr/2022/1454.pdf. As soon as you
start to think in terms of dynamic fees, you start to have issues w.r.t
gossip convergence delays and rate-limitation of your local unconditional
fees updates.

> Given a "stereotypical" forwarding node, what is the most likely
subjective valuation?
> If a node is not a stereotypical forwarding node, how does it deviate
from the stereotypical one?

Answer is a function of your collection of historical forwarding HTLC
traffic and secondary source of information.
Somehow the same as for base-layer fee-estimation, the more consistent your
mempool data-set, the better will be your valuation.

> The problem is that the Bitcoin clock is much too coarsely grained, with
chain height advances occasionally taking several hours in the so-called
"real world" I have heard much rumor about.

Sure, I still think Bitcoin as a universal clock is still the most costly
for a Lightning counterparty to game on, if it has to be used as a
mechanism to arbitrate the fees / reputation paid for the in-flight
duration of a HTLC. Even relying on timestamp sounds to offer some margin
of malleation (e.g advance of max 2h, consensus rule) if you have hashrate
capabilities.

> Would not the halt of the channel progress be considered worthy of a
reputation downgrade by itself?

That's an interesting point, rather than halting channel progress being
marked as a strict reputation downgrade, you could negotiate a "grace
delay" during which channel progress must be made forward (to allow for
casualties like software upgrade or connectivity issue).

Best,
Antoine

Le lun. 24 juil. 2023 à 09:14, ZmnSCPxj <ZmnSCPxj at protonmail.com> a écrit :

>
>
> > > - For taproot/musig2 we need nonces:
> > > - Today we store the commitment signature from the remote party. We
> don’t need to store our own signature - we can sign at time of broadcast.
> > > - To be able to sign you need the verification nonce - you could
> remember it, or you could use a counter:
> > > - Counter based:
> > > - We re-use shachain and then just use it to generate nonces.
> > > - Start with a seed, derive from that, use it to generate nonces.
> > > - This way you don’t need to remember state, since it can always be
> generated from what you already have.
> > > - Why is this safe?
> > > - We never re-use nonces.
> > > - The remote party never sees your partial signature.
> > > - The message always stays the same (the dangerous re-use case is
> using the same nonce for different messages).
> > > - If we used the same nonce for different messages we could leak our
> key.
> > > - You can combine the sighash + nonce to make it unique - this also
> binds more.
> > > - Remote party will only see the full signature on chain, never your
> partial one.
> > > - Each party has sign and verify nonces, 4 total.
> > > - Co-op close only has 2 because it’s symmetric.
> >
> > (I don't know when mailing list post max size will be reached)
> >
> > Counter-based nonces versus stateful memorization of them from a user
> perspective depends on the hardware capabilities you have access to.
> >
> > The taproot schnorr flow could be transparent from the underlying
> signature scheme (FROST, musig2, TAPS in the future maybe).
>
> A proposal I made in the Signal group after the summit would be to not use
> MuSig2 signing for commitment transactions (== unilateral closes).
>
> Instead, we add a tapscript branch that is just `<A> OP_CHECKSIGVERIFY <B>
> OP_CHECKSIG` and use that for unilateral closes.
> We only sign with MuSig2 on mutual closes, after we have negotiated
> closing fees (whether that is the current long closing conversation, or
> simplified closing) so that only mutual closes require nonce storage.
>
> As mutual closes assume continuous connectivity anyway, we can keep
> counterparty nonces in volatile RAM and not store nonces in persistent
> storage; if a disconnection occurs, we just remove it from volatile RAM and
> restart the mutual close negotiation on reconnection.
>
> This is more palatable as even with a very restrictive hardware device you
> do not have to store the peer nonce in persistent storage.
> The hope is that mutual closes dominate over unilateral closes.
>
>
>
> > > - We run into the same pricing issues.
> > > - Why these combinations?
> > > - Since scarce resources are essentially monetary, we think that
> unconditional fees are the simplest possible monetary solution.
> > > - Unconditional Fees:
> > > - As a sender, you’re building a route and losing money if it doesn’t
> go through?
> > > - Yes, but they only need to be trivially small compared to success
> case fee budgets.
> > > - You can also eventually succeed so long as you retry enough, even if
> failure rates are very high.
> > > - How do you know that these fees will be small? The market could
> decide otherwise.
> >
> > Static unconditional fees is a limited tool in a world where rational
> economic actors are pricing their liquidity in function of demand.
>
> Conditinoal fees already on the Lightning Network are already dynamic,
> with many people (including myself) writing software that measures demand
> and changes price accordingly.
> Why would unconditional fees be necessarily static, when there is no
> mention of it being static?
>
>
> > > - We have to allow some natural rate of failure in the network.
> > > - An attacker can still aim to fall just below that failure threshold
> and go through multiple channels to attack an individual channel.
> > > - THere isn’t any way to set a bar that an attacker can’t fall just
> beneath.
> > > - Isn’t this the same for reputation? We have a suggestion for
> reputation but all of them fail because they can be gamed below the bar.
> > > - If reputation matches the regular operation of nodes on the network,
> you will naturally build reputation up over time.
> > > - If we do not match reputation accumulation to what normal nodes do,
> then an attacker can take some other action to get more reputation than the
> rest of the network. We don’t want attackers to be able to get ahead of
> regular nodes.
> > > - Let’s say you get one point for success and one for failure, a
> normal node will always have bad reputation. An attacker could then send 1
> say payments all day long, pay a fee for it > and gain reputation.
> > > - Can you define jamming? Is it stuck HTLCs or a lot of 1 sat HTLCS
> spamming up your DB?
> >
> > Jamming is an economic notion, as such relying on the subjectivism of
> node appreciation of local ressources.
>
> Given a "stereotypical" forwarding node, what is the most likely
> subjective valuation?
> If a node is not a stereotypical forwarding node, how does it deviate from
> the stereotypical one?
>
>
> > > - The dream solution is to only pay for the amount of time that a HTLC
> is held in flight.
> > > - The problem here is that there’s no way to prove time when things go
> wrong, and any solution without a universal clock will fall back on
> cooperation which breaks down in the case of > an attack.
> >
> > There is a universal clock in Bitcoin called the chain height advances.
>
> The problem is that the Bitcoin clock is much too coarsely grained, with
> chain height advances occasionally taking several hours in the so-called
> "real world" I have heard much rumor about.
>
>
> > > - What NACK says is: I’ve ignored all of your updates and I’m
> progressing to the next commitment.
> >
> > If resource bucketing or link-level liquidity management starts to be
> involved, one can mask behind "NACK" to halt the channel progress, without
> the reputation downgrade. Layer violation issue.
>
> Would not the halt of the channel progress be considered worthy of a
> reputation downgrade by itself?
>
> Regards,
> ZmnSCPxj
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20230726/4858e570/attachment-0001.html>;

📅 Original date posted:2023-07-20 🗒️ Summary of this ...

2023-07-20T11:54:05+02:00

In reply to nevent1q…x3lv
_________________________

📅 Original date posted:2023-07-20
🗒️ Summary of this message: The author discusses the development approach for consensus change primitives and mentions the importance of individual judgment for each BOLT. They also highlight the uncertainty surrounding Simplicity for small party channels and suggest exploring formal verification.
📝 Original message:
Hi Greg,

I'm very meeting your development approach with regards to starting smalls
about consensus change primitives, and I think taproot has demonstrated
some good historical process, which has good archives about how development
was conducted (e.g the community-wide taproot review of which the Bitcoin
Contracting Primitives WG was built on this experience [0]).

I don't know about saying that the BOLTs (and its process) should be
authoritative over the running code of implementations. While it's
definitely a mark of some bar of technical review and inter-compatibility,
I think ultimately each BOLT has to be judged individually on its own
technical merits. And I think we had a bunch of cases in the past when "the
map is not the territory". Even there are few areas of critical Lightning
operations which are not documented by the BOLTs to the best of my
knowledge (such as fee-bumping and transactions broadcast reactions as it
was for on-chain DLCs [1]).

Lastly, there is a huge area of uncertainty about the technical fitness of
Simplicity for 2/small party channels. I remember a Russell O'connor
presentation about Simplicity back in Paris (2017 or 2018 ?) and asking him
how it would work in a chain of transactions, while the answer was iirc
"yes it has been designed with this constraint", it's a very open question
when you have off-chain states which advances in independence from the
on-chain state between a dynamic number of counterparties (kinda the
interactivity issue for payment pools). Here I guess you would have to come
to a consensus to the model of logic followed for the analysis of such
distributed systems e.g Leslie Lamport's temporal logic [2]. Additionally,
the theoretical foundations on the Coq prover are still actively studied by
Xavier Leroy at the College de France and some novel insights might be
interesting for using formal verification in terms of Bitcoin consensus
changes development (and I don't know if all the works and lessons have
been translated from French to English).

Best,
Antoine

[0] https://github.com/ajtowns/taproot-review
[1]
https://github.com/discreetlogcontracts/dlcspecs/blob/master/Non-Interactive-Protocol.md
[2] https://en.wikipedia.org/wiki/Temporal_logic_of_actions

Le mer. 19 juil. 2023 à 21:45, Greg Sanders <gsanders87 at gmail.com> a écrit :

> Hello Keagen,
>
> Most of the complexity of LN cannot be resolved with covenants. Of the
> things that can be simplified in my experience, you're going to need more
> than CTV to get significant gains. And in the end, channels can only get so
> simple since we have many other BOLTs to deal with. And even then, you're
> going to have to convince LN spec writers to include such changes, whatever
> they are, then get deployment.
>
> Step 1 is finding a primitive that seems interesting. It's important to
> moderate enthusiasm for any primitive with reality, and probably by being
> concrete by writing specs that use a primitive, and code it up to discover
> what we're overlooking. We're always overlooking something! In my humble
> opinion these are step 2 and 3 of gathering mind-share.
>
> As a more productive tact, if we're thinking beyond 2/small party
> channels, probably better to snap your fingers, pretend we have Simplicity,
> see what we can build, and work backwards from there to see if we can
> accomplish this within the confines of bitcoin script?
>
> Cheers,
> Greg
>
> On Wed, Jul 19, 2023 at 3:59 PM Keagan McClelland via bitcoin-dev <
> bitcoin-dev at lists.linuxfoundation.org> wrote:
>
>> Hi Antoine,
>>
>> Thank you for the effort you've put towards this. I generally agree that
>> a smooth functioning Lightning Network is of greater importance than
>> advanced contracting capabilities. However, as I dive deeper into some of
>> the more ambitious goals for LN development I am learning that a great deal
>> of complexity of some current lightning (LN) proposals can be handily
>> discharged with CTV. While I am not intimately familiar with all of the
>> other covenant schemes to the same level of technical proficiency, I have a
>> suspicion that a number of them, if not all of them, are capable of
>> discharging the same flavor and amount of complexity as well. Others should
>> chime in if they can confirm this claim.
>>
>> I have been publicly on the record as supporting the addition of some
>> covenant scheme into Bitcoin for some time and have long held on
>> theoretical grounds that the addition of such a mechanism is both necessary
>> and inevitable if Bitcoin is to survive in the long term. However, as I've
>> started to work more directly with the Lightning protocol, these
>> theoretical and purely logical arguments became far more concrete and
>> immediately beneficial.
>>
>> I say this primarily to challenge the idea that covenants are a
>> distraction from lightning development. It may very well be that your areas
>> of focus on LN preclude you from splitting your attention and none of this
>> email should be interpreted as a criticism of you applying your efforts in
>> the highest leverage manner you can manage. That said, I don't want
>> observers of this thread to walk away with the impression that they are two
>> independent efforts as covenants can significantly contribute to LN's
>> maturity. When and how should they be prioritized? Unfortunately I don't
>> feel able to comment on that at this time. All I know is that Lightning
>> would almost certainly benefit substantially from having a covenant
>> primitive.
>>
>> Cheers,
>> Keags
>>
>> On Tue, Jul 18, 2023 at 3:40 PM Antoine Riard via bitcoin-dev <
>> bitcoin-dev at lists.linuxfoundation.org> wrote:
>>
>>> Hi list,
>>>
>>> Last year amid the failure of the CTV speedy trial activation and
>>> intense conversations about a rainbow of covenant proposals, I introduced
>>> the idea of a new community process to specify covenants [0]. This post is
>>> to resume the experiment so far and officially mark the process maintenance
>>> as "up for grabs", as I won't actively pursue it further (after wavering on
>>> such a decision a bit during May / June).
>>>
>>> Few of the goals announced at that time were to build a consistent
>>> framework to evaluate covenant proposals, see the common grounds between
>>> proposals if they could be composed or combined by their authors, open the
>>> consensus changes development process beyond the historical boundaries of
>>> Bitcoin Core and maintain high-quality technical archive as a consensus
>>> discussions have spawned half a decade from intellectual conception to
>>> activation in average (at least for segwit, schnorr, taproot).
>>>
>>> Such effort was a speak-by-the-act answer to the issues in
>>> consensus development changes pointed out by Jeremy Rubin in April of last
>>> year [1]: namely the lack of a "codified checklist" for consensus changes,
>>> that "consensus is memoryless" and "bitcoin core is not bitcoin"
>>> (independently of the technical concerns as I have as limited or
>>> non-adequate primitive for vaults / payment pools I expressed during the
>>> same time). Other complementary initiatives have been undertaken during the
>>> same period, AJ with the bitcoin-inquisition fork where the community of
>>> developers and contracting primitives of researchers on a consensus-enabled
>>> fork of core [2]. And Dave Harding with the careful archiving of all
>>> covenant proposals under the Optech umbrella [3].
>>>
>>> About the Bitcoin Contracting Primitives WG, a Github repository was
>>> started and maintained to archive and document all the primitives (apo,
>>> tluv, ctv, the taproot annex, sighash_group, CSFS, cat, txhash, evict,
>>> check_output_covenant_verify, inherited ids, anyamount, singletons,
>>> op_vault) and the corresponding protocols (payment pools, vaults,
>>> drivechains, trust-minimized mining pools payouts). We had a total of 6
>>> monthly meetings on the Libera chat #bitcoin-contracting-primitives-wg for
>>> a number of more than 20 individual attendees representing most of the
>>> parts of the community. I think (missing march logs). Numerous in-depth
>>> discussions did happen on the repository and on the channel on things like
>>> "merkelized all the things" or "payment pools for miners payoffs".
>>>
>>> As I've been busy on the Lightning-side and other Bitcoin projects, I've
>>> not run an online meeting since the month of April, while still having a
>>> bunch of fruitful technical discussions with folks involved in the effort
>>> at conferences and elsewhere. I launched the effort as an experiment with
>>> the soft commitment to dedicate 20% of my time on it, after few successful
>>> sessions I think such a process has an interest of its own, however it
>>> comes with direct competition of my time to work on Lightning robustness.
>>> Getting my hands dirty on low-level LDK development recently made me
>>> realize we still have years of titan work to get a secure and reliable
>>> Lightning Network.
>>>
>>> As such, between extended covenant capabilities for advanced contracts
>>> coming as a reality for Bitcoin _or_ LN working smoothly at scale with
>>> 50-100M UTXO-sharing users on it during the next 5-7 years cycle, I think
>>> the latter goal is more critical for Bitcoin existential survival, and
>>> where on a personal title I'll allocate the best of my time and energy (and
>>> somehow it match the "slow" technical activity on bitcoin-inquisition
>>> mostly done by Lightning hands).
>>>
>>> This is my personal conclusion only on the state of Bitcoin
>>> technological momentum, and this is quite tainted by my deep background in
>>> Lightning development. If you've been working on covenant changes
>>> proposals, please don't take it as a discouragement, I think Taproot
>>> (privacy-preserving script policies behind the taproot tree branches) and
>>> Schnorr (for native multi-sig) soft forks have shown how it can improve the
>>> building of self-custody solutions by one or two order of magnitude, and
>>> small incremental changes might be good enough to have a lower technical
>>> consensus bar.
>>>
>>> On my side, I'll pursue pure R&D works on CoinPool, notably coming with
>>> better solutions with the interactivity issue and mass-compression of
>>> withdrawal and design exotic advanced Bitcoin contracts based on the
>>> taproot annex, though more in a "l'art pour l'art" approach for the time
>>> being [4]. Additionally, I might start to submit an in-depth security
>>> review of consensus changes under pseudonyms, it has already been done in
>>> the past and somehow it's good practice in terms of "message neutrality"
>>> [5]. If folks wanna experiment in terms of payment pools deployment, Greg
>>> Maxwell's old joinpool can be used today (and somehow it's worthy of its
>>> own as a net advance for coinjoins).
>>>
>>> I'll honestly acknowledge towards the community, I might have
>>> overpromised with the kickstart of this new process aiming to move the
>>> frontlines in matters of Bitcoin consensus changes development process. On
>>> the other hand, I think enough sessions of the working group have been
>>> runned and enough marks of technical interests have been collected to
>>> demonstrate the minimal value of such a process, so I would estimate my
>>> open-source balance sheet towards the community to be in good standing ?
>>> (open-minded question).
>>>
>>> I don't think Bitcoin fundamentally lacks compelling technical proposals
>>> to advance the capabilities of Bitcoin Script today, nor the crowd of
>>> seasoned and smart protocol developers to evaluate mature proposals
>>> end-to-end and on multiple dimensions with a spirit of independence.
>>> Rather, I believe what Bitcoin is lacking is a small crowd of technical
>>> historians and archivist doing the work of assessing, collecting and
>>> preserving consensus changes proposals and QA devs to ensure any consensus
>>> change proposals has world-class battle-ground testing before to be
>>> considered for deployment, ideally with the best standards of Bitcoin
>>> decentralization and FOSS neutrality [6].
>>>
>>> If you would like to pursue the maintenance and nurturing of the Bitcoin
>>> Contracting Primitives WG (or the bitcoin-inquisition fork or collaborate
>>> with Optech to organize industry-wise workshop on covenants at the image of
>>> what has been done in 2019 for Taproot), that you're willing to show
>>> proof-of-work and you estimate that operational ground, legal information
>>> or financial resources will anchor your individual work on the long-term,
>>> don't hesitate to reach out, I'll see what I can do with a disinterested
>>> mind [7].
>>>
>>> With humility,
>>> Antoine
>>>
>>> [0]
>>> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-July/020763.html
>>> [1]
>>> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-April/020233.html
>>> [2]
>>> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-September/020921.html
>>> [3] https://github.com/bitcoinops/bitcoinops.github.io/pull/806
>>> [4] Version 0.2 of the CoinPool whitepaper addressing most of the
>>> remaining "Big Problems" is still pending on my visit to co-author Gleb
>>> Naumenko in Ukraine, which has been postponed few times in light of the
>>> conflict operational evolutions.
>>> [5] See
>>> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2020-February/017614.html.
>>> For the philosophical reasons of doing so, I invite you to read Foucault's
>>> famous essay "Le philosophe masque".
>>> [6] Somehow I come to share Jeremy's thesis's "Product management is not
>>> "my Job" it's yours" in matters of consensus changes. I believe we might be
>>> past the technical complexity threshold where even simple consensus changes
>>> can be conducted from A to Z as a one man job or even by a group of 2/3
>>> elite devs.
>>> [7] I've been reached out multiple times and consistently by R&D
>>> non-profits, plebs whales and VC firms who were interested to commit
>>> resources to advance softforks and covenants in the Bitcoin space, no doubt
>>> when you're reliable and with a track record, folks are ready to offer you
>>> opportunities to work full-time on consensus changes.
>>> _______________________________________________
>>> bitcoin-dev mailing list
>>> bitcoin-dev at lists.linuxfoundation.org
>>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>>
>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-dev at lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20230720/364b91a0/attachment-0001.html>;

📅 Original date posted:2023-07-18 🗒️ Summary of this ...

2023-07-19T04:09:38+02:00

In reply to nevent1q…khh5
_________________________

📅 Original date posted:2023-07-18
🗒️ Summary of this message: Last year, a new community process for specifying covenants was introduced, but the person behind it will no longer actively pursue it. Efforts were made to build a framework for evaluating covenant proposals and expand the consensus changes development process. Other initiatives were also undertaken during the same period. A Github repository was created to document Bitcoin contracting primitives and corresponding protocols. Monthly meetings were held with attendees from various parts of the community. However, the person behind the process has been busy with other Bitcoin projects and has not held online meetings since April.
📝 Original message:
Hi list,

Last year amid the failure of the CTV speedy trial activation and intense
conversations about a rainbow of covenant proposals, I introduced the idea
of a new community process to specify covenants [0]. This post is to resume
the experiment so far and officially mark the process maintenance as "up
for grabs", as I won't actively pursue it further (after wavering on such a
decision a bit during May / June).

Few of the goals announced at that time were to build a consistent
framework to evaluate covenant proposals, see the common grounds between
proposals if they could be composed or combined by their authors, open the
consensus changes development process beyond the historical boundaries of
Bitcoin Core and maintain high-quality technical archive as a consensus
discussions have spawned half a decade from intellectual conception to
activation in average (at least for segwit, schnorr, taproot).

Such effort was a speak-by-the-act answer to the issues in
consensus development changes pointed out by Jeremy Rubin in April of last
year [1]: namely the lack of a "codified checklist" for consensus changes,
that "consensus is memoryless" and "bitcoin core is not bitcoin"
(independently of the technical concerns as I have as limited or
non-adequate primitive for vaults / payment pools I expressed during the
same time). Other complementary initiatives have been undertaken during the
same period, AJ with the bitcoin-inquisition fork where the community of
developers and contracting primitives of researchers on a consensus-enabled
fork of core [2]. And Dave Harding with the careful archiving of all
covenant proposals under the Optech umbrella [3].

About the Bitcoin Contracting Primitives WG, a Github repository was
started and maintained to archive and document all the primitives (apo,
tluv, ctv, the taproot annex, sighash_group, CSFS, cat, txhash, evict,
check_output_covenant_verify, inherited ids, anyamount, singletons,
op_vault) and the corresponding protocols (payment pools, vaults,
drivechains, trust-minimized mining pools payouts). We had a total of 6
monthly meetings on the Libera chat #bitcoin-contracting-primitives-wg for
a number of more than 20 individual attendees representing most of the
parts of the community. I think (missing march logs). Numerous in-depth
discussions did happen on the repository and on the channel on things like
"merkelized all the things" or "payment pools for miners payoffs".

As I've been busy on the Lightning-side and other Bitcoin projects, I've
not run an online meeting since the month of April, while still having a
bunch of fruitful technical discussions with folks involved in the effort
at conferences and elsewhere. I launched the effort as an experiment with
the soft commitment to dedicate 20% of my time on it, after few successful
sessions I think such a process has an interest of its own, however it
comes with direct competition of my time to work on Lightning robustness.
Getting my hands dirty on low-level LDK development recently made me
realize we still have years of titan work to get a secure and reliable
Lightning Network.

As such, between extended covenant capabilities for advanced contracts
coming as a reality for Bitcoin _or_ LN working smoothly at scale with
50-100M UTXO-sharing users on it during the next 5-7 years cycle, I think
the latter goal is more critical for Bitcoin existential survival, and
where on a personal title I'll allocate the best of my time and energy (and
somehow it match the "slow" technical activity on bitcoin-inquisition
mostly done by Lightning hands).

This is my personal conclusion only on the state of Bitcoin technological
momentum, and this is quite tainted by my deep background in Lightning
development. If you've been working on covenant changes proposals, please
don't take it as a discouragement, I think Taproot (privacy-preserving
script policies behind the taproot tree branches) and Schnorr (for native
multi-sig) soft forks have shown how it can improve the building of
self-custody solutions by one or two order of magnitude, and small
incremental changes might be good enough to have a lower technical
consensus bar.

On my side, I'll pursue pure R&D works on CoinPool, notably coming with
better solutions with the interactivity issue and mass-compression of
withdrawal and design exotic advanced Bitcoin contracts based on the
taproot annex, though more in a "l'art pour l'art" approach for the time
being [4]. Additionally, I might start to submit an in-depth security
review of consensus changes under pseudonyms, it has already been done in
the past and somehow it's good practice in terms of "message neutrality"
[5]. If folks wanna experiment in terms of payment pools deployment, Greg
Maxwell's old joinpool can be used today (and somehow it's worthy of its
own as a net advance for coinjoins).

I'll honestly acknowledge towards the community, I might have overpromised
with the kickstart of this new process aiming to move the frontlines in
matters of Bitcoin consensus changes development process. On the other
hand, I think enough sessions of the working group have been runned and
enough marks of technical interests have been collected to demonstrate the
minimal value of such a process, so I would estimate my open-source balance
sheet towards the community to be in good standing ? (open-minded question).

I don't think Bitcoin fundamentally lacks compelling technical proposals to
advance the capabilities of Bitcoin Script today, nor the crowd of seasoned
and smart protocol developers to evaluate mature proposals end-to-end and
on multiple dimensions with a spirit of independence. Rather, I believe
what Bitcoin is lacking is a small crowd of technical historians and
archivist doing the work of assessing, collecting and preserving consensus
changes proposals and QA devs to ensure any consensus change proposals has
world-class battle-ground testing before to be considered for deployment,
ideally with the best standards of Bitcoin decentralization and FOSS
neutrality [6].

If you would like to pursue the maintenance and nurturing of the Bitcoin
Contracting Primitives WG (or the bitcoin-inquisition fork or collaborate
with Optech to organize industry-wise workshop on covenants at the image of
what has been done in 2019 for Taproot), that you're willing to show
proof-of-work and you estimate that operational ground, legal information
or financial resources will anchor your individual work on the long-term,
don't hesitate to reach out, I'll see what I can do with a disinterested
mind [7].

With humility,
Antoine

[0]
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-July/020763.html
[1]
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-April/020233.html
[2]
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-September/020921.html
[3] https://github.com/bitcoinops/bitcoinops.github.io/pull/806
[4] Version 0.2 of the CoinPool whitepaper addressing most of the remaining
"Big Problems" is still pending on my visit to co-author Gleb Naumenko in
Ukraine, which has been postponed few times in light of the conflict
operational evolutions.
[5] See
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2020-February/017614.html.
For the philosophical reasons of doing so, I invite you to read Foucault's
famous essay "Le philosophe masque".
[6] Somehow I come to share Jeremy's thesis's "Product management is not
"my Job" it's yours" in matters of consensus changes. I believe we might be
past the technical complexity threshold where even simple consensus changes
can be conducted from A to Z as a one man job or even by a group of 2/3
elite devs.
[7] I've been reached out multiple times and consistently by R&D
non-profits, plebs whales and VC firms who were interested to commit
resources to advance softforks and covenants in the Bitcoin space, no doubt
when you're reliable and with a track record, folks are ready to offer you
opportunities to work full-time on consensus changes.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20230718/0be965a9/attachment.html>;

📅 Original date posted:2023-06-21 🗒️ Summary of this ...

2023-06-21T11:18:57+02:00

In reply to nevent1q…24k9
_________________________

📅 Original date posted:2023-06-21
🗒️ Summary of this message: CivKit Node, a Nostr relay with peer-to-peer market board features, has been released. The CLI-only release is written in Rust and has basic NIP 01 support.
📝 Original message:
Hi Bitcoin Devs,

Proud to announce the first release of CivKit Node, a basic Nostr relay
with additional features to have a functional peer-to-peer market board,
written in Rust [0]. This is a very raw release as since we published the
paper back in April, we've been reached out by a bunch of folks asking how
they could contribute by code, or start to integrate CivKit in their Nostr
and Lightning peer-to-peer market clients [1].

Current release is CLI-only, just implementing basic NIP 01 support and is
full of bugs and todos, has not been tested on a lot of platforms and still
works as a local host for a lot of things [2]. There is a sample Nostr
client binary joined for deployment and testing purposes and an utility
binary to manage the node with a gRPC interface. Such an interface should
lay the groundwork to build one or more GUI applications on top, as it's a
recurring and consistent request from the community.

There is an experimental integration with BOLT8 Noise transport (thanks to
LDK), where one can connect to another CivKit Node has a peer, Idea is to
unify the communication infrastructure between Nostr and Lightning, and as
such have a single market of p2p service providers (watchtower, state
backup, boards) benefiting from network law effect. Beyond sharing all the
work between Lightning and Nostr ecosystem in terms of spamming
mitigations, careful crypto engineering (e.g onion routing) and
privacy-preserving monetary credentials [3].

With this released out, I think we'll go for sound onion routing support,
BOLT12 offers, the set of fundamental NIPs like NIP-09, NIP-16, NIP-33 and
others, and integration with a notary protocol (e.g Mainstay). Still, we
would like to listen to our users and we'll plumber features in the
function of relevant feedback collected from the community. One key lesson
from years contributing on LDK, we do not want to stay in a "purist
developer" ivory tower to avoid hard-to-integrate APIs, and make the
"product management" of the project owned by the community to ensure we're
building for the real-world of unstable and constrained mobile clients.

Once we have communication infrastructure and hopefully credentials
framework working, I think we'll start to have more serious development of
the CivKit functionaries services themselves (e.g market bulletin boards,
rank proof servers and moderation oracles in the paper parlance). Though
again, if folks want to start more custom services on top of CivKit Node,
we'll see what we can do, there is a brave new world to explore with Nostr
and Lightning maturation.

For the historical note, peer-to-peer market features were present in
Bitcoin Core circa 2010 (in fact before the ref client was dubbed Core).
Those features were removed by commit 5253d1ab "strip out unfinished
product, review and market stuff" by Satoshi [4]. Retrospectively, it was a
good insight as Core has evolved as a complex beast enough and careful
layerization is one of the best learning from the 50 years of Internet
history. Still, censorship-resistant and large-scale peer-to-peer markets
sounds still one of the missing blocks of the Bitcoin protocol stack.

Looking forward to growing the Bitcoin and Lightning internal economies by
an order of magnitude or two with the CivKit Node, if the kharma is with us.

All works are released under MIT/Apache licenses and we aim to bind to the
best open-source development standards as set by Bitcoin Core and the Linux
kernel communities and we're welcoming anyone strongly willing to build
with passion and love.

I think for the future, we'll do the announcement on its own communication
channel, whatever a new mailing list, or something experimental on top of
Nostr groups, Still, if we innove in terms of cryptography we're aiming to
have things standardized under BIPs.

"Sic itur ad astra" -
Block 000000000000000000053fd09a45f48e747f281122021edc2f7e97efcdd66248

Cheers,
Antoine

[0] https://github.com/civkit/civkit-node
[1]
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2023-April/021556.html
[2] Of course, there are gazillins of things to implement, please open an
issue on the repository directly rather to yell something doesn't work.
[3]
https://lists.linuxfoundation.org/pipermail/lightning-dev/2023-May/003964.html
[4] https://github.com/bitcoin/bitcoin/commit/5253d1ab
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20230621/7e720924/attachment-0001.html>;

📅 Original date posted:2023-05-06 🗒️ Summary of this ...

2023-06-19T19:42:21+02:00

In reply to nevent1q…4mg3
_________________________

📅 Original date posted:2023-05-06
🗒️ Summary of this message: The Lightning Network community is exploring data gathering and local reputation tracking to mitigate channel jamming, starting with a binary endorsement field. The goal is to experiment with different algorithms for tracking local reputation and gather real-world data for future simulation work.
📝 Original message:
Hi *,

> Our suggestion is to start simple with a binary endorsement field. As
> we learn more, we will be better equipped to understand whether a
> more expressive value is required.

I think the HTLC endorsement scheme as proposed is still suffering from a
vulnerability as local reputation can be built up during periods of low
routing fees, endorsement gained and then abused during periods of high
routing fees. Therefore, it sounds to me this scheme should aim for some
reputational transitivity between incoming traffic and outgoing traffic.
Namely, the acquisition cost of the local reputation should be equal to the
max timevalue damage that one can inflict on a routing node channel
accessible from its local counterparty granting this high-level of
reputation.

I don't know if this can be fixed by ensuring permanent link-level "gossip"
where counterparties along a payment path expose their reputation
heuristics to guarantee this transitivity, or it's a fundamental issue with
a point-to-point approach like HTLC endorsement.

Opened an issue on the repository to converge on a threat model:
https://github.com/ClaraShk/LNJamming/pull/13

I still think building data gathering infrastructure for Lightning is
valuable as ultimately any jamming mitigation will have to adapt its
upfront fees or reputation acquisition cost in function of HTLC traffic and
market forces.

Looking forward to giving an update on Staking Credentials [0], an
end-to-end approach to mitigate channel jamming.

Best,
Antoine

[0]
https://lists.linuxfoundation.org/pipermail/lightning-dev/2022-November/003754.html

Le dim. 30 avr. 2023 à 03:57, Carla Kirk-Cohen <kirkcohenc at gmail.com> a
écrit :

> Hi list,
>
> Some updates on channel jamming!
>
> # Next Call
> - Monday 01 May @ 15:00 UTC
> - https://meet.jit.si/UnjammingLN
> - Agenda: https://github.com/ClaraShk/LNJamming/issues/12
>
> # Data Gathering
> During these weekly calls, we've come to agreement that we would like
> to gather data about the use of HTLC endorsement and local reputation
> tracking for jamming mitigation. A reminder of the full scheme is
> included at the end of this email, and covered more verbosely in [1].
>
> We have a few goals in mind:
> - Observe the effect of endorsement in the steady state with
> logging-only implementation.
> - Gather real-world data for use in future simulation work.
> - Experiment with different algorithms for tracking local reputation.
>
> The minimal changes required to add HTLC endorsement are outlined in [2].
> Our suggestion is to start simple with a binary endorsement field. As
> we learn more, we will be better equipped to understand whether a
> more expressive value is required.
>
> With this infrastructure in place, we can start to experiment with
> various local reputation schemes and data gathering, possibly even
> externally to LN implementations in projects like circuitbreaker [3].
> We'd be interested to hear whether there's any appetite to deploy using
> an experimental TLV value?
>
> # Reputation Scheme
> - Each node locally tracks the reputation of its direct neighbors.
> - Each node allocates, per its risk tolerance:
> - A number of slots reserved for endorsed HTLCs from high reputation
> peers.
> - A portion of liquidity reserved for endorsed HTLCs from high
> reputation peers.
> - Forwarding of HTLCs:
> - If a HTLC is endorsed by a high reputation peer, it is forwarded
> as usual with endorsed = 1.
> - Otherwise, it is forwarded with endorsed = 0 if there are slots and
> liquidity available for unknown HTLCs.
>
> Endorsement and reputation are proposed as the first step in a two part
> scheme for mitigating channel jamming:
> - Reputation for slow jams which are easily detected as misbehavior.
> - Unconditional fees for quick jams that are difficult to detect, as
> they can always fall under a target threshold.
>
> Looking forward to discussing further in the upcoming call!
>
> Best,
> Carla and Clara
>
> [1] https://gist.github.com/carlaKC/be820bb638624253f3ae7b39dbd0e343
> [2] https://github.com/lightning/bolts/pull/1071
> [3] https://github.com/lightningequipment/circuitbreaker
> _______________________________________________
> Lightning-dev mailing list
> Lightning-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20230506/40daccce/attachment.html>;

📅 Original date posted:2023-05-10 🗒️ Summary of this ...

2023-06-19T19:42:06+02:00

In reply to nevent1q…nshc
_________________________

📅 Original date posted:2023-05-10
🗒️ Summary of this message: Bitcoin developer defends his right to expose potential conflicts of interest in open-source development and calls for protection of communication channels.
📝 Original message:
Hi Tony,

> Is there a better place to have public communication? Unfortunately since
one off topic email was sent here, it's been a ghost town. It appears that
there's many emails being held and only one moderator that checks them once
a week.

As I think you're referring to my post of March 21th and as the author of
this post, I'll politely refuse the qualification of "off-topic". I had and
I still have the concerns of "frivolous legal claims" being used between
bitcoin developers/organizations provoking a distortion of the neutrality
of the development and a chilling effect of the technical discussions (i.e
code we compile and spec we implement). For those reasons, it was my legal
right and moral duty to inform the community of what is happening between
Chaincode and myself. And here I'm following the recommendation of one of
the moderators of the Lightning mailing list himself "If this worries you
too, let's make sure we keep each other honest, OK?" [0].

When you think a group of people with open-source responsibilities are in a
situation of conflict of interests or "moral hazards", or even the
appearance of them, you have the right to expose the wrongdoing, including
the _proportional_ revelation of private elements. People have done the
"free choice" to conduct a career in open-source, for some even declaring
in some context to maintain integrity and accept their actions to be
submitted to external accountability [1]. While the exposure of private
elements of public personalities might break common courtesy, it's a
morally valid practice if you're familiar with the public institutions of
US and Europe, and I think this practice has found validity in the history
of open-source commons or IETF's protocol development [1].

Beyond, the Bitcoin and Lightning development communication channels
constitute a public forum, where by nature the participants are exchanging
ideas and defending competing interests. In consequence, the participants'
rights and capabilities to contribute and speak their minds in those
communication channels should be protected. Those communication channels
are not your usual corporate workplace, and in case of conflicting
principles, the maintainers of those communication channels should ensure a
balance of rights and a proportionality in any restraining measure.

And this new post is not to exonerate myself of any legal responsibility
for personal matters that could be recognized as the outcome of a judicial
process, respective of both rights of the accusation and rights of the
defense. Rather to enlighten the Bitcoin community that the formal
separation between private matters and open-source responsibilities, and
the adequate check-and-balances to guarantee this separation is somehow
what are the underlying stakes for this feud between Chaincode and myself,
from my perspective. I can say missing an open-source engineering meeting
or being revoked a few Github permissions matters far less than the clear
affirmation and respect of the freedom of expression, the presumption of
innocence and due process in the Bitcoin common space, all proportions
conserved.

I don't blame any party involved in this issue, nor assign "bad
intentions''. One position is really a function of your life experiences,
knowledge of the legal and cultural framework and access to the factual
elements. As all human conflicts it is not binary rather "grey". People can
be top executives at a billion-dollar company, having successful ventures
with hundreds of folks under management, or have a lot of responsibilities
for their relative young age, and still disagree on the set of legal and
moral principles to apply in the present case.

Finally, thanks to the Bitcoin friends who have reached out to call for
level-headedness and cool-mindness in the public discussion of this complex
topic. Like I said to them, in the lack of more suspected wrongdoing from
the other side, I won't communicate further on this subject on the Bitcoin
and Lightning technical channels. However I still firmly believe the
discussion on the principles, abstract in the maximum from its private
elements, should still be pursued on other channels. Independently, there
is a legal channel opened between Chaincode and myself and good progress is
made to find a serene and long-standing resolution to this issue.

Best,
Antoine

[0]
https://rusty-lightning.medium.com/the-corrosion-of-ethics-in-cryptocurrencies-f7ba77e9dfc3
[1]
https://github.com/btrustteam/board-book/blob/main/vision/genesis_principles.md
[2]
https://www.ietf.org/about/administration/policies-procedures/conflict-interest/

Le lun. 8 mai 2023 à 21:26, Tony Giorgio via Lightning-dev <
lightning-dev at lists.linuxfoundation.org> a écrit :

> Is there a better place to have public communication? Unfortunately since
> one off topic email was sent here, it's been a ghost town. It appears that
> there's many emails being held and only one moderator that checks them once
> a week.
>
> Would hate to see this list die but wondering if there's a better place
> for discussions?
>
> Tony
>
>
>
>
>
>
> -------- Original Message --------
> On Apr 29, 2023, 9:57 PM, niftynei < niftynei at gmail.com> wrote:
>
>
> Hi all,
>
> When I joined the lightning community a few years ago, I was relatively
> new to open source software and specification work. Rusty really impressed
> on me on the importance of holding conversations, as much as possible in
> public.
>
> Practically speaking, this encompasses IRC, this mailing list, and github
> issues/PRs.
>
> The reason for this is twofold. It helps document the range of options
> considered for technical decisions and it provides an interface point for
> new participants to contribute to the discussion.
>
> Given some recent mails that were posted to this list, now seems like a
> good time to reiterate the importance and preference of public
> communication whenever possible, especially for specification or technical
> discussions.
>
>
> ~ nifty
>
> _______________________________________________
> Lightning-dev mailing list
> Lightning-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20230510/1f0f9268/attachment.html>;

📅 Original date posted:2023-05-06 🗒️ Summary of this ...

2023-06-09T15:13:17+02:00

In reply to nevent1q…gc8f
_________________________

📅 Original date posted:2023-05-06
🗒️ Summary of this message: The Lightning Network community is exploring data gathering and local reputation tracking to mitigate channel jamming, starting with a binary endorsement field. They aim to experiment with different algorithms for tracking local reputation and gather real-world data for future simulation work.
📝 Original message:
Hi *,

> Our suggestion is to start simple with a binary endorsement field. As
> we learn more, we will be better equipped to understand whether a
> more expressive value is required.

I think the HTLC endorsement scheme as proposed is still suffering from a
vulnerability as local reputation can be built up during periods of low
routing fees, endorsement gained and then abused during periods of high
routing fees. Therefore, it sounds to me this scheme should aim for some
reputational transitivity between incoming traffic and outgoing traffic.
Namely, the acquisition cost of the local reputation should be equal to the
max timevalue damage that one can inflict on a routing node channel
accessible from its local counterparty granting this high-level of
reputation.

I don't know if this can be fixed by ensuring permanent link-level "gossip"
where counterparties along a payment path expose their reputation
heuristics to guarantee this transitivity, or it's a fundamental issue with
a point-to-point approach like HTLC endorsement.

Opened an issue on the repository to converge on a threat model:
https://github.com/ClaraShk/LNJamming/pull/13

I still think building data gathering infrastructure for Lightning is
valuable as ultimately any jamming mitigation will have to adapt its
upfront fees or reputation acquisition cost in function of HTLC traffic and
market forces.

Looking forward to giving an update on Staking Credentials [0], an
end-to-end approach to mitigate channel jamming.

Best,
Antoine

[0]
https://lists.linuxfoundation.org/pipermail/lightning-dev/2022-November/003754.html

Le dim. 30 avr. 2023 à 03:57, Carla Kirk-Cohen <kirkcohenc at gmail.com> a
écrit :

> Hi list,
>
> Some updates on channel jamming!
>
> # Next Call
> - Monday 01 May @ 15:00 UTC
> - https://meet.jit.si/UnjammingLN
> - Agenda: https://github.com/ClaraShk/LNJamming/issues/12
>
> # Data Gathering
> During these weekly calls, we've come to agreement that we would like
> to gather data about the use of HTLC endorsement and local reputation
> tracking for jamming mitigation. A reminder of the full scheme is
> included at the end of this email, and covered more verbosely in [1].
>
> We have a few goals in mind:
> - Observe the effect of endorsement in the steady state with
> logging-only implementation.
> - Gather real-world data for use in future simulation work.
> - Experiment with different algorithms for tracking local reputation.
>
> The minimal changes required to add HTLC endorsement are outlined in [2].
> Our suggestion is to start simple with a binary endorsement field. As
> we learn more, we will be better equipped to understand whether a
> more expressive value is required.
>
> With this infrastructure in place, we can start to experiment with
> various local reputation schemes and data gathering, possibly even
> externally to LN implementations in projects like circuitbreaker [3].
> We'd be interested to hear whether there's any appetite to deploy using
> an experimental TLV value?
>
> # Reputation Scheme
> - Each node locally tracks the reputation of its direct neighbors.
> - Each node allocates, per its risk tolerance:
> - A number of slots reserved for endorsed HTLCs from high reputation
> peers.
> - A portion of liquidity reserved for endorsed HTLCs from high
> reputation peers.
> - Forwarding of HTLCs:
> - If a HTLC is endorsed by a high reputation peer, it is forwarded
> as usual with endorsed = 1.
> - Otherwise, it is forwarded with endorsed = 0 if there are slots and
> liquidity available for unknown HTLCs.
>
> Endorsement and reputation are proposed as the first step in a two part
> scheme for mitigating channel jamming:
> - Reputation for slow jams which are easily detected as misbehavior.
> - Unconditional fees for quick jams that are difficult to detect, as
> they can always fall under a target threshold.
>
> Looking forward to discussing further in the upcoming call!
>
> Best,
> Carla and Clara
>
> [1] https://gist.github.com/carlaKC/be820bb638624253f3ae7b39dbd0e343
> [2] https://github.com/lightning/bolts/pull/1071
> [3] https://github.com/lightningequipment/circuitbreaker
> _______________________________________________
> Lightning-dev mailing list
> Lightning-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20230506/40daccce/attachment.html>;

📅 Original date posted:2023-04-03 🗒️ Summary of this ...

2023-06-09T15:13:01+02:00

In reply to nevent1q…wzjn
_________________________

📅 Original date posted:2023-04-03
🗒️ Summary of this message: Developers discuss challenges with implementing 0-conf splicing in Bitcoin's Lightning Network, including the risk of double-spending and potential vulnerabilities.
📝 Original message:
Hi Bastien,

Thanks for the update on the state of splicing.

> We've also discovered that implementing 0-conf splicing is tricky: you
> need to be very careful about scenarios where your peer force-closes
> using an *inactive* commitment that ends up double-spending what you
> think is the only *active* commitment but is unconfirmed. We'd be happy
> to discuss that in more details with other implementers to reduce the
> risk of introducing new vulnerabilities when shipping that feature.

I think halting 0-conf splicing is pretty easy for a counterparty by
abusing Bitcoin Core mempool replacement rule #5 on the maximum number of
original transactions replaced.

Let's say you have Alice with 10% of the channel capacity as a balance in
the "inactive" commitment and the 90% remaining in favor of Bob. Bob has
initiated a splice out of 70% of the channel capacity. On the interactive
transaction, Alice adds 4 unrelated confirmed inputs and then broadcasts 4
chains of 25 unconfirmed transactions from those inputs.

When Bob broadcasts the splice-out, it should be rejected by the network
mempools on the grounds of RBF rule #5, whatever the absolute fee and
feerate. So the "0-conf" splicing might be maintained under risk of
double-spend by your counterparty for a while.

It sounds like Bob's splice out funds should be segregated until the
corresponding "active commitment" is confirmed, i.e no use to fund another
channel,
with inbound/outbound HTLC flows.

Best,
Antoine

Le lun. 3 avr. 2023 à 00:25, Bastien TEINTURIER <bastien at acinq.fr> a écrit :

> Good morning list,
>
> As some of you may know, we've been hard at work experimenting with
> splicing [1]. Splicing is a complex feature with a large design space.
> It was interesting to iterate on two separate implementations (eclair
> and cln) and discover the pain points, edge cases and things that could
> be improved in the protocol specification.
>
> After a few months trying out different approaches, we'd like to share
> changes that we believe make the splicing protocol simpler and more
> robust.
>
> We call "active commitments" the set of valid commitment transactions to
> which updates must be applied. While one (or more) splices are ongoing,
> there is more than one active commitment. When signing updates, we send
> one `commitment_signed` message per active commitment. We send those
> messages in the order in which the corresponding funding transactions
> have been created, which lets the receiver implicitly match every
> `commitment_signed` to their respective funding transaction.
>
> Once we've negotiated a new splice and reached the signing steps of the
> interactive-tx protocol, we send a single `commitment_signed` for that
> new commitment. We don't revoke the previous commitment(s), as this adds
> an unnecessary step. Conceptually, we're simply adding a new commitment
> to our active commitments set.
>
> A sample flow will look like this:
>
> Alice Bob
> | stfu |
> |----------------------------->|
> | stfu |
> |<-----------------------------|
> | splice_init |
> |----------------------------->|
> | splice_ack |
> |<-----------------------------|
> | |
> | <interactive-tx> |
> |<---------------------------->|
> | |
> | tx_complete |
> |----------------------------->|
> | tx_complete |
> |<-----------------------------|
> | commit_sig | Sign the new commitment.
> |----------------------------->|
> | commit_sig | Sign the new commitment.
> |<-----------------------------|
> | tx_signatures |
> |----------------------------->|
> | tx_signatures |
> |<-----------------------------|
> | |
> | update_add_htlc | Alice and Bob use the channel while
> the splice transaction is unconfirmed.
> |----------------------------->|
> | update_add_htlc |
> |----------------------------->|
> | commit_sig | Sign the old commitment.
> |----------------------------->|
> | commit_sig | Sign the new commitment.
> |----------------------------->|
> | revoke_and_ack |
> |<-----------------------------|
> | commit_sig | Sign the old commitment.
> |<-----------------------------|
> | commit_sig | Sign the new commitment.
> |<-----------------------------|
> | revoke_and_ack |
> |----------------------------->|
> | |
> | splice_locked | The splice transaction confirms.
> |----------------------------->|
> | splice_locked |
> |<-----------------------------|
> | |
> | update_add_htlc | Alice and Bob can use the channel
> and forget the old commitment.
> |----------------------------->|
> | commit_sig | Sign the new commitment.
> |----------------------------->|
> | revoke_and_ack |
> |<-----------------------------|
> | commit_sig | Sign the new commitment.
> |<-----------------------------|
> | revoke_and_ack |
> |----------------------------->|
> | |
>
> You can find many more details and sample flows in [2].
>
> We require nodes to store data about the funding transaction as soon as
> they send their `commitment_signed` message. This lets us handle every
> disconnection scenario safely, allowing us to either resume the signing
> steps on reconnection or forget the funding attempt. This is important
> because if peers disagree on the set of active commitments, this will
> lead to a force-close. In order to achieve that, we only need to add
> the `next_funding_txid` to the `channel_reestablish` message, and fill
> it when we're missing signatures from our peer. Again, you can find more
> details and sample flows in [2].
>
> Finally, after trying various approaches, we believe that the funding
> amounts that peer exchange in `splice_init` and `splice_ack` should be
> relative amounts based on each peer's current channel balance.
>
> If Alice sends `funding_amount = 200_000 sats`, it means she will be
> adding 200 000 sats to the channel's capacity (splice-in).
>
> If she sends `funding_amount = -50_000 sats`, it means she will be
> removing 50 000 sats from the channel's capacity (splice-out).
>
> This makes it easier to compute the new channel balances (otherwise we
> have to deal with millisatoshi to satoshi truncation) and better matches
> the UX that node operators are expecting, which means there is less need
> to glue code between the RPC exposed to the node operator and the actual
> underlying protocol.
>
> We've also discovered that implementing 0-conf splicing is tricky: you
> need to be very careful about scenarios where your peer force-closes
> using an *inactive* commitment that ends up double-spending what you
> think is the only *active* commitment but is unconfirmed. We'd be happy
> to discuss that in more details with other implementers to reduce the
> risk of introducing new vulnerabilities when shipping that feature.
>
> Cheers,
> Bastien
>
> [1] https://github.com/lightning/bolts/pull/863
> [2] https://gist.github.com/t-bast/1ac31f4e27734a10c5b9847d06db8d86
> _______________________________________________
> Lightning-dev mailing list
> Lightning-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20230403/ef027b9b/attachment-0001.html>;

📅 Original date posted:2023-03-06 🗒️ Summary of this ...

2023-06-09T15:12:51+02:00

In reply to nevent1q…yhf3
_________________________

📅 Original date posted:2023-03-06
🗒️ Summary of this message: The local reputation channel involves forwarding requests from one party to another based on reputation and available outbound liquidity/slots. However, there are concerns about endorsement decision criteria, reputation slashing in case of HTLC failure, and exploitable reputation asymmetries.
📝 Original message:
Hi all,

My understanding of the local reputation channel is the following, when Bob
receives a HTLC forwarding request from Alice to Caroll:
- if Alice has reputation of 1 and Alice endorses the transaction, Bob
forwards and endorses the HTLC to Caroll
- else if the HTLC amount is under the available outbound liquidity quota
assigned to Alice and available outbound slots assigned to Alice, Bob
forwards the HTLC to Caroll and reduce available outbound liquidity/slots
assigned to Alice
- else the HTLC is rejected

This is unclear on which criterias the endorsement decision is made (e.g
CLTV expiry delta, odds of settlement, ongoing congestion of outbound
channels ?). Additionally, this is unclear how the available
liquidity/slots on a given outbound channel are initially distributed
between all the inbound channels (e.g proportional to the capacity) and how
they're balanced once the inbound channels start to accumulate reputation.

I don't know if this local reputation scheme precises how reputation is
slashed in case of HTLC failure, and if any "grace" amount/rate is granted
to the inbound channel counterparty, e.g Alice.

Independently of those considerations, I think this local reputation scheme
might suffer from exploitable reputation asymmetries by a jamming adversary.
Let's say you have the topology:

Alice - Bob - Caroll - Dave

Alice accumulated a reputation of 1 towards Bob and same for Bob towards
Caroll. As `fee_base_msat` Bob picked up 1000 msat and Caroll picked up
2000 msat. If Alice forwards a HTLC to Bob and it is endorsed by him before
relay to Caroll, Alice can now inflict a 50 sat damage to Caroll, while
only encumbering the lower-priced reputational cost towards Bob.

This concern could hold in case of asymmetries arising from the dynamic
adjustment of routing fees during an evaluated period of time. E.g both Bob
and Caroll requires routing fees of 1000 msat. Alice builds up a reputation
of 1 towards Bob during this period N. At period N+1, Caroll bumps her
routing fees to 2000 msat. From now on, Alice can exploit this asymmetry.

While I think this deficiency could be fixed by ensuring a proportionality
of the reputation acquisition cost between the inbound channels and the
cost requested by a counterparty on an outbound channel, I believe this
would come with the downside that any update in reputation cost should be
recursively applied to the downstream links (i.e Bob on Alice channel,
Alice on neighbouring inbound channels, etc).

Apart of this reputation asymmetry concern, I think the local reputation
scheme could suffer from spontaneous jamming by "honest" long-term held
packets (e.g CLTV delta=2 weeks), where even if Alice is not scored to 1 by
Bob, she always settles her long-term held packets. However, those packets
are yielding less routing fees to Bob than let's say 14 HTLC packets of
CLTV delta = 1 day.

Finally, the dynamic reduction of the available outbound liquidity/slots in
the occurrence of reputation=0 counterparty's HTLC being only known at the
link-level could break the expectations of the HTLC senders scoring
algorithms. E.g, being connected to Alice might have probed through another
path the available liquidity on the link Bob-Caroll. This Eve's probe is
falsified by any reduction done by Caroll towards Bob, and therefore Eve's
payment reliability is likely to be downgraded.

Best,
Antoine

Le jeu. 16 févr. 2023 à 21:29, Clara Shikhelman <clara.shikhelman at gmail.com>
a écrit :

> Hi List,
>
> We’re writing to seek early feedback on a draft for a neighbour reputation
> setting recommendation as a jamming mitigation. The main idea is that
> allowing full access to liquidity and slots in a channel can result in
> jamming. To prevent this, we allow full access only to neighbours that
> forward HTLC that resolve quickly and generate more profit than the damage
> they can potentially create.
>
> The full suggested jamming mitigation solution includes upfront fees
> together with reputation, see [1] for details.
>
> In the previous episodes:
>
> As presented here [1], we suggest a two part jamming mitigation strategy.
> Reputation-based forwarding is aimed to solve “slow jamming”, where the
> jamming transaction takes a long time to resolve.
>
> The main idea is that each node gives a binary reputation to its
> neighbour. Each channel has a quota of liquidity and slots (say 50% of the
> channel size and 50% of the slots in the channel) dedicated to transactions
> coming from neighbours with reputation 0, or for transactions coming from
> neighbours with reputation 1 that were not endorsed by the neighbour.
>
> For example, when Alice asks Bob to forward to Charlie then:
>
> If (Alice has reputation 1 with Bob) and (Alice endorses transaction):
>
> Forward and endorse
>
> Else:
>
> If (amount < available liquidity quota) and (available slots in quota>0):
>
> Forward HTLC without endorsing
>
> Reduce available liquidity and slots
>
> Else:
>
> Reject
>
> Reputation:
>
> The question we discuss here is how does Alice gain “good” reputation
> (i.e., a score of 1). Alice starts at 0, and she gains and keeps her good
> reputation of 1 by continuously paying more fees to Bob than the damage she
> can inflict.
>
> The 3 main parameters for reputation that each node operator picks are S,L
> and M. Our recommendations are as follows:
>
> -
>
> S should be chosen as the maximum time an HTLC can be unresolved in
> any of Bob’s channels.
> -
>
> M is the revenue generated by Bob’s node in the time S, representing
> the damage Alice could inflict.
> -
>
> L is the time in which Alice should generate M revenue for Bob for her
> to have a good reputation of 1. We suggest L=10S.
>
>
> Alice has reputation 1 if, in the last L seconds, she has forwarded
> payments that generated M satoshi in fees.
>
> As an example:
>
> -
>
> Bob has a maximum CLTV delta of 2 weeks [2]
> -
>
> Over the last 2 weeks, he has earned 0.5 BTC in routing fees
> -
>
> Alice will be considered to have good reputation if she has forwarded
> 0.5 BTC of routing revenue to Bob over the last 20 weeks
>
>
> Formally:
>
> Let t be the current time, and let S and L be constants.
>
> M is calculated to be the revenue of Bob in time [t-S,t]. The revenue of
> Bob is the sum of fees from transactions forwarded by any neighbour besides
> Alice + any payments received by Bob. Note that Bob can choose to also take
> into account utility gained from sending payments or anything of value to
> the node operator.
>
> Alice has reputation 1 if in the time [t-L,t] she has forwarded HTLCs
> that paid M in normalized fees.
>
> We normalize fees by resolution time to reward payments that resolve
> quickly and discount slow resolving payments. Here we assume 10 seconds is
> the “normal” resolution time, this number can be bikesheded, and we round
> up to avoid penalizing transactions resolved quicker than the “normal”.
>
> The fee from a single transaction is normalized by the time it took for
> the HTLC to resolve, counted in slots of 10 seconds. That is:
>
> Normalized_fee = (fee)/[ceiling(time_to_resolve/10s)]
>
>
>
> Some notes
>
> 1.
>
> The reputation management happens locally, that is, the only protocol
> change needed is the ability to signal endorsement as a TLV in
> UpdateAddHTLC. The various parameters can be selected for various risk
> preferences.
> 2.
>
> We currently suggest a binary reputation for simplicity. Having
> several buckets could be interesting to study, yet we don’t think that the
> complexity and the possible privacy issues are worth the potential benefits.
> 3.
>
> For most use cases, having reputation 0 is more than enough. If we
> send and receive transactions at a low rate, we usually don’t need the full
> liquidity and slots available in a channel. Reputation mostly comes into
> play only when a channel is under attack, and then not all transaction are
> allowed to go through.
> 4.
>
> Following this thread [3]: it is important to note that we are only
> giving reputation to our direct neighbours. An advantage of this is that we
> have repeated interactions with them. In practice, this is also the only
> clean data we have to use when deciding whether to forward an HTLC or not.
>
>
> Best,
>
> Carla and Clara
>
>
> [1]
> https://lists.linuxfoundation.org/pipermail/lightning-dev/2022-November/003740.html
> [2]
> https://github.com/lightningnetwork/lnd/blob/de94a4ea5e81799330a72dfde111817b38565d99/htlcswitch/link.go#L51
> [3]
> https://lists.linuxfoundation.org/pipermail/lightning-dev/2023-February/003842.html
> _______________________________________________
> Lightning-dev mailing list
> Lightning-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20230306/d19448db/attachment-0001.html>;

📅 Original date posted:2023-02-14 🗒️ Summary of this ...

2023-06-09T15:12:42+02:00

In reply to nevent1q…rx8t
_________________________

📅 Original date posted:2023-02-14
🗒️ Summary of this message: The Lightning Network may require routing nodes to operate flawlessly or face penalties, potentially impacting future routing revenue. Gradual implementation of strict penalties may be necessary for routing nodes to adapt.
📝 Original message:
Hi Joost,

> For a long time I've held the expectation that eventually payers on the
lightning network will become very strict about node performance. That they
will > require a routing node to operate flawlessly or else apply a hefty
penalty such as completely avoiding the node for an extended period of time
- multiple > weeks. The consequence of this is that routing nodes would
need to manage their liquidity meticulously because every failure
potentially has a large
> impact on future routing revenue.

I think the performance question depends on the type of payment flows
considered. If you're an
end-user sending a payment to your local Starbucks for coffee, here fast
payment sounds the end-goal.
If you're doing remittance payment, cheap fees might be favored, and in
function of those flows you're
probably not going to select the same "performant" routing nodes. I think
adding latency as a criteria for
pathfinding construction has already been mentioned in the past for LDK [0].

> I think movement in this direction is important to guarantee
competitiveness with centralised payment systems and their (at least
theoretical) ability to
> process a payment in the blink of an eye. A lightning wallet trying
multiple paths to find one that works doesn't help with this.

Or there is the direction to build forward-error-correction code on top of
MPP, like in traditional
networking [1]. The rough idea, you send more payment shards than the
requested sum, and then
you reveal the payment secrets to the receiver after an onion interactivity
round to finalize payment.

> A common argument against strict penalisation is that it would lead to
less efficient use of capital. Routing nodes would need to maintain pools of
> liquidity to guarantee successes all the time. My opinion on this is that
lightning is already enormously capital efficient at scale and that it is
worth
> sacrificing a slight part of that efficiency to also achieve the lowest
possible latency.

At the end of the day, we add more signal channels between HTLC senders and
the routing
nodes offering capital liquidity, if the signal mechanisms are efficient, I
think they should lead
to better allocation of the capital. So yes, I think more liquidity might
be used by routing nodes
to serve finely tailored HTLC requests by senders, however this liquidity
should be rewarded
by higher routing fees.

> This brings me to the actual subject of this post. Assuming strict
penalisation is good, it may still not be ideal to flip the switch from one
day to the other. > Routing nodes may not offer the required level of
service yet, causing senders to end up with no nodes to choose from.

> One option is to gradually increase the strength of the penalties, so
that routing nodes are given time to adapt to the new standards. This does
require > everyone to move along and leaves no space for cheap routing
nodes with less leeway in terms of liquidity.

I think if we have lessons to learn on policy rules design and deployment
on the base-layer
(the full-rbf saga), it's to be careful in the initial set of rules, and
how we ensure smooth
upgradeability, from one version to another. Otherwise the re-deployment
cost towards
the new version might incentive the old routing node to stay on the
non-optimal versions,
and as we have historical buckets in routing algorithms, or preference for
older channels,
this might lead the end-user to pay higher fees, than they could access to.

> Therefore I am proposing another way to go about it: extend the
`channel_update` field `channel_flags` with a new bit that the sender can
use to signal > `highly_available`.

> It's then up to payers to decide how to interpret this flag. One way
could be to prefer `highly_available` channels during pathfinding. But if
the routing
> node then returns a failure, a much stronger than normal penalty will be
applied. For routing nodes this creates an opportunity to attract more
traffic by > marking some channels as `highly_available`, but it also comes
with the responsibility to deliver.

This is where the open question lies to me - "highly available" can be
defined with multiple
senses, like fault-tolerance, latency processing, equilibrated liquidity.
And a routing node might
not be able to optimize its architecture for the same end-goal (e.g more
watchtower on remote
host probably increases the latency processing).

> Without shadow channels, it is impossible to guarantee liquidity up to
the channel capacity. It might make sense for senders to only assume high
> availability for amounts up to `htlc_maximum_msat`.

As a note, I think "senders assumption" should be well-documented,
otherwise there will be
performance discrepancies between node implementations or even versions.
E.g, an upgraded
sender penalizing a node for the lack of shadow/parallel channels
fulfilling HTLC amounts up to
`htlc_maximum_msat`.

> A variation on this scheme that requires no extension of `channel_update`
is to signal availability implicitly through routing fees. So the more
expensive > a channel is, the stronger the penalty that is applied on
failure will be. It seems less ideal though, because it
could disincentivize cheap but reliable
> channels on high traffic links.

> The effort required to implement some form of a `highly_available` flag
seem limited and it may help to get payment success rates up. Interested to
> hear your thoughts.

I think signal availability should be explicit rather than implicit. Even
if it's coming with more
gossip bandwidth data consumed. I would say for bandwidth performance
management, relying
on new gossip messages, where they can be filtered in function of the level
of services required
is interesting.

Best,
Antoine

[0] https://github.com/lightningdevkit/rust-lightning/issues/1647
[1] https://www.rfc-editor.org/rfc/rfc6363.html

Le lun. 13 févr. 2023 à 11:46, Joost Jager <joost.jager at gmail.com> a écrit :

> Hi,
>
> For a long time I've held the expectation that eventually payers on the
> lightning network will become very strict about node performance. That they
> will require a routing node to operate flawlessly or else apply a hefty
> penalty such as completely avoiding the node for an extended period of time
> - multiple weeks. The consequence of this is that routing nodes would need
> to manage their liquidity meticulously because every failure potentially
> has a large impact on future routing revenue.
>
> I think movement in this direction is important to guarantee
> competitiveness with centralised payment systems and their (at least
> theoretical) ability to process a payment in the blink of an eye. A
> lightning wallet trying multiple paths to find one that works doesn't help
> with this.
>
> A common argument against strict penalisation is that it would lead to
> less efficient use of capital. Routing nodes would need to maintain pools
> of liquidity to guarantee successes all the time. My opinion on this is
> that lightning is already enormously capital efficient at scale and that it
> is worth sacrificing a slight part of that efficiency to also achieve the
> lowest possible latency.
>
> This brings me to the actual subject of this post. Assuming strict
> penalisation is good, it may still not be ideal to flip the switch from one
> day to the other. Routing nodes may not offer the required level of service
> yet, causing senders to end up with no nodes to choose from.
>
> One option is to gradually increase the strength of the penalties, so that
> routing nodes are given time to adapt to the new standards. This does
> require everyone to move along and leaves no space for cheap routing nodes
> with less leeway in terms of liquidity.
>
> Therefore I am proposing another way to go about it: extend the
> `channel_update` field `channel_flags` with a new bit that the sender can
> use to signal `highly_available`.
>
> It's then up to payers to decide how to interpret this flag. One way could
> be to prefer `highly_available` channels during pathfinding. But if the
> routing node then returns a failure, a much stronger than normal penalty
> will be applied. For routing nodes this creates an opportunity to attract
> more traffic by marking some channels as `highly_available`, but it also
> comes with the responsibility to deliver.
>
> Without shadow channels, it is impossible to guarantee liquidity up to the
> channel capacity. It might make sense for senders to only assume high
> availability for amounts up to `htlc_maximum_msat`.
>
> A variation on this scheme that requires no extension of `channel_update`
> is to signal availability implicitly through routing fees. So the more
> expensive a channel is, the stronger the penalty that is applied on failure
> will be. It seems less ideal though, because it could disincentivize cheap
> but reliable channels on high traffic links.
>
> The effort required to implement some form of a `highly_available` flag
> seem limited and it may help to get payment success rates up. Interested to
> hear your thoughts.
>
> Joost
> _______________________________________________
> Lightning-dev mailing list
> Lightning-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20230214/893867dd/attachment-0001.html>;

📅 Original date posted:2023-02-17 🗒️ Summary of this ...

2023-06-09T15:12:42+02:00

In reply to nevent1q…mrxu
_________________________

📅 Original date posted:2023-02-17
🗒️ Summary of this message: The discussion is about the development and design of protocols, and the need for neutral approaches to ensure decentralization.
📝 Original message:
As long as protocol development and design is done neutrally, I'm all fine!

Le ven. 17 févr. 2023 à 10:48, Joost Jager <joost.jager at gmail.com> a écrit :

> Right, that was my above point about fetching scoring data - there's three
>> relevant "buckets" of
>> nodes, I think - (a) large nodes sending lots of payments, like the
>> above, (b) "client nodes" that
>> just connect to an LSP or two, (c) nodes that route some but don't send a
>> lot of payments (but do
>> send *some* payments), and may have lots or not very many channels.
>>
>> (a) I think we're getting there, and we don't need to add anything extra
>> for this use-case beyond
>> the network maturing and improving our scoring algorithms.
>> (b) I think is trivially solved by downloading the data from a node in
>> category (a), presumably the
>> LSP(s) in question (see other branch of this thread)
>> (c) is trickier, but I think the same solution of just fetching
>> semi-trusted data here more than
>> sufficies. For most routing nodes that don't send a lot of payments we're
>> talking about a very small
>> amount of payments, so trusting a third-party for scoring data seems
>> reasonable.
>>
>
> I see that in your view all nodes will either be large nodes themselves,
> or be downloading scoring data from large nodes. I'd argue that that is
> more of a move towards centralisation than the `ha` flag is. The flag at
> least allows small nodes to build up their view of the network in an
> efficient and independently manner.
>
> Joost
> _______________________________________________
> Lightning-dev mailing list
> Lightning-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20230217/36b81f39/attachment-0001.html>;

📅 Original date posted:2023-01-12 🗒️ Summary of this ...

2023-06-09T15:12:30+02:00

In reply to nevent1q…pg0m
_________________________

📅 Original date posted:2023-01-12
🗒️ Summary of this message: Lightning Network developers are documenting a protocol architecture for mitigating channel jamming with Staking Credentials, enabling deployment within a reputation or monetary strategy. The architecture separates the credentials issuance phase from the redemption phase and abstracts participants to answer multiple types of Lightning deployment. The credentials redemption mechanism covers diverse Lightning channel counterparty risks, with a primary focus on HTLC jamming. The module is designed to be uncoupled from LDK architecture specifics and generic to minimize interdependencies with independent advances in channel types/transaction-relay policy.
📝 Original message:
Hi LN devs,

Following the November proposal of mitigating channel jamming with
Reputation Credentials, started to document the protocol architecture.
After feedback on the naming protocol itself, I switched to Staking
Credentials. In fact the proposed architecture enables mitigations
deployment both within a reputation strategy or a monetary strategy in
function of the base collateral considered (proof-of-utxo ownership or
on-chain/off-chain payments).

The main advance is the clear separation of the credentials issuance phase
from the redemption phase. Participants in the architecture have been
abstracted to answer multiple types of Lightning deployment: credentials
issuance and redemption fully-sourced on the client-side, issuance
delegation where the credentials mining is delegated to a LSP, redemption
delegation where the credentials are attached on the fly to a HTLC by a hop
supporting trampoline. Abstraction has been done also on the routing-hop
side, where the credentials issuer can be dissociated from the routing hop
against which it can be redeemed (to allow "phantom node" style of
deployment [0]).

The credentials redemption mechanism itself has been abstracted to cover
diverse Lightning channel counterparty risks, with a primary focus on HTLC
jamming. Beyond, the redemption flow could be easily deployed to solve the
risk asymmetries brought by the signature release flow in the context of
dual-funding/splicing.

Architecture document is available here:
https://github.com/ariard/lightning-rfc/blob/2022-11-reputation-credentials/60-staking-credentials-archi.md

Credential issuance phase, redemption phase, onion communication channels
as credential transport protocol, credentials data format, cryptographic
primitives used for unlinking and recommendations for risk-management
strategy (among others) should land in their own documents with time.

Next focus on advancing the work-in-progress implementation:
https://github.com/ariard/lightning-risk-engine

Module is designed to be uncoupled from LDK architecture specifics and
generic to minimize interdependencies with independent advances in channel
types/transaction-relay policy.

Cheers,
Antoine

[0] https://lightningdevkit.org/blog/introducing-phantom-node-payments/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20230112/7ab3d050/attachment.html>;

📅 Original date posted:2023-01-05 🗒️ Summary of this ...

2023-06-09T15:12:27+02:00

In reply to nevent1q…qlln
_________________________

📅 Original date posted:2023-01-05
🗒️ Summary of this message: The article discusses the use of Chia's scripting capabilities in multi-party setups and breaking symmetry to prevent cheating in unilateral channel closures.
📝 Original message:
Hi AJ,

> Chia uses different terminology to bitcoin; "puzzle" is just what we call
> "scriptPubKey" in bitcoin, more or less. Since its scripting capabilities
> are pretty powerful, you can rig up a TLUV/OP_EVICT like mechanism, but
> for a two-party setup, in practice I think that mostly just means you
> can encode the logic directly as script, and when updating the state you
> then only need to exchange CHECKSIGFROMSTACK-like signatures along the
> lines of "state N implies outputs of A,B,C,... -- Alice", rather than
> signing multiple transactions.

In the multi-party setup, encoding more of the unrolling logic directly as
script could be a witness space gain, I guess. To express a channel
factory/payment pool withdrawal, at the minimum I think you need an
amount/exit scriptPubKey committed by the signature. Or maybe the output
value could be a spent input amount distribution among a set of signers, if
you would like some non-interactive pre-funded scheme.

> If you have fully symmetric transactions, then you could have the
> situation where Alice broadcasts update K, then attacks Bob and when
> he attempts to post update N, she instead does a pinning attack by
> broadcasting update K+1 (spending update K), which then forces Bob to
> generate a new version update N, which she then blocks with update K+2,
> etc. An attack like that is presumably pretty difficult to pull off in
> practice, but it makes it pretty hard to reason about many of the limits.
>
> A simple advantage to breaking the symmetry is that if A does a unilateral
> close, then B can immediately confirm that closure releasing all funds
> for both parties. Without breaking the symmetry, you can't distinguish
> that case from B attempting to confirm his own unilateral close, which
> would allow B to cheat.

Yes, IIUC the proposed flow is UA.n -> CB.n -> money, and in this
optimistic case, there is only one CLTV delay to respect the spend of the
UA. In terms of timevalue cost to redeem all the funds, I think this is
making the cost equivalent for all the parties. With today's LN-penalty,
the broadcaster balance is encumbered by the CSV delay, not the
counterparty one.

(Note on the gist, the UA state description includes a Pa or tapscript "IF
CODESEP n OP_CLTV DROP ENDIF 1 CHECKSIG" as spendable paths and the CA.n
state description nSequence = 0, so I'm not sure how the update/justice
delay is enforced)

> Yes, you can unilaterally close the channel with state N-1; but even
> then they might respond by bumping to state N anyway. If that happens,
> then the funds can remain locked up until the timeout, as you can no
> longer time the htlc out off-chain.
>
> Still, if it's one hung per htlc for the channel's entire lifetime
> (because you close it "immediately" when it happens), that's probably
> not going to cause problems frequently...

I think here the issue can be corrected by selecting conservatively your
implementation channel breakout timers, you should go to chain with the
state N-1 with X buffer of block and ensure your CLTV delta are always
bigger than X, where X=delay * 2. That way even if your counterparty is
broadcasting state N at X-1, your htlc-timeout should be safe, I guess.

> If Alice is dishonest, and posts a very old state (n-x), then Bob could
> post up to x watchtower txs (WB.(n-x+1) .. WB.n) causing Alice to be
> unable to access her funds for up to (x+1)*to_self_delay blocks. But
> that's just a reason for her to not be dishonest in the first place.

So I think there still is the case of Bob broadcasting a very old state and
Alice's watchtowers colluding to prevent Alice's honest funds access,
potentially preventing the HTLC-timeout, IIUC. I don't know if we're not
introducing some changes in the trust assumptions towards watchtowers where
with vanilla eltoo a single compromised watchtower can be corrected by the
honest channel holder or another watchtower, iirc.

> No -- the RB.n transactions immediately release A's funds after applying
> the penalty, so if the watchtower colludes with A and has an old RB.y
> transaction, Alice can steal funds by posting UA.x and RB.y, provided that
> her balance now is sufficiently less than her balance then (ie bal.n <
> bal.y - penalty).
>
> In this model, Bob shouldn't be signing RB.n or CB.n txs until Alice
> has already started a unilateral close and posted UA.n/UA.k.

So the penalty transactions should not be delegated to untrusted
watchtowers. In case of RB.n signing key compromise, the whole channel
funds might be lost.

> Doesn't generalise to redundant untrusted watchtowers though, but
> presumably nothing does. (You could use the same utxo across multiple
> watchtowers, but a rogue watchtower could just post an old WA.k tx and
> claim your funds, preventing some honest watchtower from helping)

So you could have a channel balance between the watchtower and yourself,
where the tower balance is the payment for the WA.n broadcast, and there is
an assumption the balance is cooperatively updated to adjust for on-chain
fees. For sure, I'm not sure either how it would generalize to an untrusted
watchtower, where interactions might be even bounded to avoid leak of the
client identity.

Still, I think eltoo channels would simplify the implementation of
distributed towers by Lightning implementation, notably handling concurrent
broadcast w.r.t chain asynchronicity issues, and hopefully removing the
concern of commitment transaction key duplication by tower [0].

Best,
Antoine

[0] https://github.com/lightningdevkit/rust-lightning/pull/679

Le ven. 9 déc. 2022 à 01:55, Anthony Towns <aj at erisian.com.au> a écrit :

> On Thu, Dec 08, 2022 at 02:14:06PM -0500, Antoine Riard wrote:
> > > - 2022-10-21, eltoo/chia:
> > https://twitter.com/bramcohen/status/1583122833932099585
> > On the eltoo/chia variant, from my (quick) understanding, the main
> > innovation aimed for is
>
> I'd say the main innovation aimed for is just doing something like
> lightning over the top of chia (rather than bitcoin, liquid, ethereum
> etc), and making it simple enough to be easily implemented.
>
> > the limitation of the publication of eltoo states
> > more than once by a counterparty, by introducing a cryptographic puzzle,
> > where the witness can be produced once and only once ? I would say you
> > might need the inheritance of the updated scriptpubkey across the chain
> of
> > eltoo states, with a TLUV-like mechanism.
>
> Chia uses different terminology to bitcoin; "puzzle" is just what we call
> "scriptPubKey" in bitcoin, more or less. Since its scripting capabilities
> are pretty powerful, you can rig up a TLUV/OP_EVICT like mechanism, but
> for a two-party setup, in practice I think that mostly just means you
> can encode the logic directly as script, and when updating the state you
> then only need to exchange CHECKSIGFROMSTACK-like signatures along the
> lines of "state N implies outputs of A,B,C,... -- Alice", rather than
> signing multiple transactions.
>
> > > The basic idea is "if it's a two party channel with just Alice and Bob,
> > > then if Alice starts a unilateral close, then she's already had her
> say,
> > > so it's only Bob's opinion that matters from now on, and he should be
> > > able to act immediately", and once it's only Bob's opinion that
> matters,
> > > you can simplify a bunch of things.
> > From my understanding, assuming Eltoo paper terminology, Alice can
> publish
> > an update K transaction, and then after Bob can publish an update
> > transaction K<N or Alice can publish the settlement transaction N, or Bob
> > can publish an update transaction N. The main advantage of this
> > construction I can see is a strict bound on the shared_delay encumbered
> in
> > the on-chain publication of the channel ?
>
> If you have fully symmetric transactions, then you could have the
> situation where Alice broadcasts update K, then attacks Bob and when
> he attempts to post update N, she instead does a pinning attack by
> broadcasting update K+1 (spending update K), which then forces Bob to
> generate a new version update N, which she then blocks with update K+2,
> etc. An attack like that is presumably pretty difficult to pull off in
> practice, but it makes it pretty hard to reason about many of the limits.
>
> A simple advantage to breaking the symmetry is that if A does a unilateral
> close, then B can immediately confirm that closure releasing all funds
> for both parties. Without breaking the symmetry, you can't distinguish
> that case from B attempting to confirm his own unilateral close, which
> would allow B to cheat.
>
> > > fast forwards: we might want to allow our channel partner
> > > to immediately rely on a new state we propose without needing a
> > > round-trip delay -- this potentially makes forwarding payments much
> > > faster (though with some risk of locking the funds up, if you do a
> > > fast forward to someone who's gone offline)
> >
> > IIRC, there has already been a "fast-forward" protocol upgrade proposal
> > based on update-turn in the LN-penalty paradigm [0]. I think reducing the
> > latency of HTLC propagation across payment paths would constitute a UX
> > improvement, especially a link-level update mechanism upgrade deployment
> > might be incentivized by routing algorithms starting to penalize routing
> > hops HTLC relay latency. What is unclear is the additional risk of
> locking
> > the funds up. If you don't receive acknowledgement the fast forward state
> > has been received, you should still be able to exit with the state N-1 ?
>
> Yes, you can unilaterally close the channel with state N-1; but even
> then they might respond by bumping to state N anyway. If that happens,
> then the funds can remain locked up until the timeout, as you can no
> longer time the htlc out off-chain.
>
> Still, if it's one hung per htlc for the channel's entire lifetime
> (because you close it "immediately" when it happens), that's probably
> not going to cause problems frequently...
>
> > > doubled delays: once we publish the latest state we can, we want to
> > > be able to claim the funds immediately after to_self_delay expires;
> > > however if our counterparty has signatures for a newer state than we
> > > do (which will happen if it was fast forwarded), they could post that
> > > state shortly before to_self_delay expires, potentially increasing
> > > the total delay to 2*to_self_delay.
> >
> > While the 2*to_self_delay sounds the maximum time delay in the state
> > publication scenario where the cheating counterparty publishes a old
> state
> > then the honest counterparty publishes the latest one, there could be the
> > case where the cheating counterparty broadcast chain of old states, up to
> > mempool's `limitancestorcount`. However, this chain of eltoo transactions
> > could be replaced by the honest party paying a higher-feerate (assuming
> > something like nversion=3).
>
> With the asymmetric transactions proposed here, you'd need to have your
> watchtowers collude with the attacker for this to happen.
>
> I think you could prevent chains from building up in the mempool by
> requiring a relative timelock of perhaps 2 or 3 blocks for a WA.n/WB.n
> tx to be valid (giving you time to post RA.n/RB.n in the meantime).
>
> > > * WA.n, WB.n : watchtower update to state n
> > > - this is for an untrusted watchtower to correct attempted cheating
> > > by Bob on behalf of Alice (or vice-versa). Spends UB.k or WA.k
> > > (or UA.k/WB.k) respectively, provided k < n.
> > I wonder if the introduction of watchtower specific transactions doesn't
> > break the 2*to_self_delay assumption
>
> The to_self_delay applies to whoever initiated the unilateral close,
> and provided they actually posted the most recent state, no watchtower
> tx is a valid spend. ie, if Alice is honest and n is the latest state,
> then the only possible spends of UA.n are SA.n (after a delay) or CB.n,
> and as soon as either of those are on chain, she gets access to her funds.
> No version of WB.k or RB.k (or WA.k, CA.k, RA.k) are valid if k<=n and
> UA.n is confirmed.
>
> If Alice is dishonest, and posts a very old state (n-x), then Bob could
> post up to x watchtower txs (WB.(n-x+1) .. WB.n) causing Alice to be
> unable to access her funds for up to (x+1)*to_self_delay blocks. But
> that's just a reason for her to not be dishonest in the first place.
>
> > (iiuc it's a design goal of current
> > protocol) and what is the design rationale. Beyond that, there is a
> concern
> > with watchtower-specific transactions, it might leak your towers topology
> > (i.e the number of them and the distribution in the p2p network) to an
> > adversary.
>
> If you have a watchtower and it takes action, I don't think you can
> expect to retain privacy over the fact that you have a watchtower,
> and how effective it is against an attacker with extensive monitoring
> of the p2p network...
>
> > > * SA.n, SB.n : slowly claim funds according to state n
> > > - this is for Alice to claim her funds if Bob is completely offline
> > > (or vice-versa). Spends UA.n, UB.n, WA.n or WB.n with relative
> > > timelock of to_self_delay.
> >
> > If I'm following correctly the description, this is logically equivalent
> to
> > the sweep of a `to_local`/`to_remote` output on a commitment transaction
> > though instead the waiting delay is eltoo shared_delay. There is no
> > to_self_delay, at the punishment seems only to happen on the
> update-level,
> > or maybe one should be also able to punish slow fund exit, and another
> > relative locktime should exist on the S* transactions.
>
> I'm just using "to_self_delay" as the X in "if you attempt to cheat,
> I'll definitely notice and take action within X blocks". If you post
> UA.n then post SA.n after X blocks (due to SA.n's relative time lock)
> then you've already proven you didn't cheat, because that was enough
> time for B to notice and take action.
>
> > > * Alice and Bob's watchtower collude, but Bob has many watchtowers:
> > > F -> UA.k1 -> WB.k2 -> WB.n -> (to_self_delay) -> SA.n -> money
> > Could the punishment transactions R* be also delegated to watchtowers,
> > assuming they have been pre-signed to lockdown the exit scriptpubkeys ?
>
> No -- the RB.n transactions immediately release A's funds after applying
> the penalty, so if the watchtower colludes with A and has an old RB.y
> transaction, Alice can steal funds by posting UA.x and RB.y, provided that
> her balance now is sufficiently less than her balance then (ie bal.n <
> bal.y - penalty).
>
> In this model, Bob shouldn't be signing RB.n or CB.n txs until Alice
> has already started a unilateral close and posted UA.n/UA.k.
>
> > > In order to allow fast-forwards, when Alice proposes a new state,
> > > she needs to send her partial signatures to allow Bob to unilaterally
> > > accept the new state, ie sigs for: UB.n, CB.n, SB.n, RB.n. But she
> > > also needs to be able to claim the funds if Bob proposes the new state
> > > and broadcasts UB.n, she needs to be able broadcast CA.n. This can be
> > > achieved with an adaptor signature approach (spelt out a bit more fully
> > > in the gist) or a CTV-like approach, provided that UB.n reveals the
> > > state needed to calculate the the CTV commitment (see "EXPR_SETTLE" in
> > >
> >
> https://github.com/instagibbs/bolts/blob/29fe6d36cbad4101d5ec76c2b19c83c1494ac2fc/XX-eltoo-transactions.md
> > ).
> >
> > If you would like to have fast forward of chain of transactions, I wonder
> > if there could be also the "sig-in-the-script" trick, where UB.n
> > scriptpubkey (or one of its tapscripts) contains the signature for CB.n,
> > SB.n, RB.n. Though you might have an issue of re-generating the
> > witnessscript in case of state loss.
>
> Broadcasting UB.n will only reveal signatures by B; so that would only
> potentially help with CA.n or RA.n; and if UB.n is on-chain, then RA.n
> isn't valid (since it would require "n < n").
>
> The EXPR_SETTLE stuff in the github link describes how to do the trick
> via a CTV-ish approach (including an APO signature in a tapscript in the
> scriptPubKey of UA.n here; and including data in the annex so that you
> can recalculate thinks if an old UA.n is broadcast after you've
> forgotten n's state details).
>
> > > * how to pay watchtowers -- when a watchtower broadcasts a W
> > > transaction, it needs to add fees, and it's not clear (to me) how it
> > > could fairly and reliably ensure it's compensated for those costs,
> > > particularly if multiple W transactions are broadcast for a single
> > > unilateral close attempt, due to one or more watchtowers colluding
> > > with an attacker, or simply having out of date information.
> > I wonder if paying a watchtower, or getting paid as a watchtower isn't a
> > "counterparty risk" similar to what is happening with jamming due to
> > non-covered HTLC forward risk.
>
> Actually, perhaps you could "yo dawg" it: if you give the watchtower a
> pre-signed transaction WA.n:
>
> input 1: UA.k/WA.k (ANYPREVOUTANYSCRIPT, SINGLE)
> input 2: my funds (SINGLE, ALL)
>
> output 1: WA.n
> output 2: new lightning channel between me and watchtower
> output 3: ephemeral OP_TRUE output
>
> then you could have the "new lightning channel" be setup with an initial
> capacity of "my funds", and off-chain update the state of that channel so
> that the watchtower's balance is how much you're willing to contribute in
> fees if the watchtower does its job. If you set things up so that you're
> always able to claim a penalty via WA.n->RA.n if the watchtower acts,
> then you can give up to that penalty to the watchtower and still end up
> making a profit.
>
> Doesn't generalise to redundant untrusted watchtowers though, but
> presumably nothing does. (You could use the same utxo across multiple
> watchtowers, but a rogue watchtower could just post an old WA.k tx and
> claim your funds, preventing some honest watchtower from helping)
>
> (Yo dawg, I heard you liked closing lightning channels, so we put a
> lightning channel in your watchtower, so you can close a channel while
> you're closing a channel. Alternatively: "when god closes one channel,
> he opens another")
>
> Cheers,
> aj
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20230105/a6627adb/attachment-0001.html>;

📅 Original date posted:2023-05-31 📝 Original message: > ...

2023-06-09T15:08:50+02:00

In reply to nevent1q…xw88
_________________________

📅 Original date posted:2023-05-31
📝 Original message:
> I think it's important to differentiate between fees a node charges and
> *reputation_revenue*. Reputation is determined as a function of the latter.
> If Caroll has a very high *reputation_revenue* and Bob has a very low one,
> then Bob probably won't have a high reputation with Caroll, as the amount
> of fees he forwards to Caroll is smaller than the damage he can create.
> That is, if Caroll is a huge node and Bob is a raspberry pi, then Bob will
> never have a good reputation with Caroll. If they have similar
> *reputation_revenue*, then getting a good reputation with Bob is as
> difficult as getting a good reputation with Caroll.
>
> In your example (if I got it correctly) Bob's *reputation_revenue* = 1,000,
> *reputation_window*=100 and *routing_window*=10. Could you explain what are
> Caroll's parameters are in your example? The *fee_base_msat* does not
> indicate Carolls *reputation_revenue* (unless Alice is the only one
> transacting on the Bob-Caroll channel, and then she is the one paying for
> Bob's reputation).
>
> That being said, we use *reputation_revenue *to estimate the damage an
> attacker can create. If there is a chain of nodes that have high reputation
> with each other, and they are jammed, they would be compensated for the
> revenue lost during the attack. If Bob finds that having a high reputation
> with Caroll is crucial and 1,000 sats will not compensate him for loosing
> it, then he should either never endorse anything on that channel, or at
> least put a higher bar than *reputation_revenue*.

I think the distinction you're proposing between routing fees and
reputation revenue matters in the HTLC endorsement model. For the
example I'm using let's say Caroll and Bob share the same exact
parameters, *reputation_revenue* = 1,000, *routing_window*=100 and
*routing_window*=10, where the reputation revenue of Bob towards
Caroll is made from multiple incoming links.

For each HTLC forwarding request issued from Alice, Bob has to make
the decision between refusing Alice HTLC forward over the Caroll
incoming link, and lose an opportunity of fee income, or accept the
HTLC and suffers from a damage if Alice reveals a posteriori as a
jamming attacker.

This is unclear to me how the compensation mechanism works in the
chain of nodes that have high reputation with each other, and I still
think the HTLC endorsement mitigation suffers from the classic issues
of reputation systems (i.e whitewashing).

> Not sure what you mean by that.

I think there is a coupling effec introduced between the historical
liquidity buckets of routing scoring algorithms and the introduction
of endorsment scheme with adjustement of the channel liquidity and
slots in function of local topology reputation.

See the LDK scoring engine comments here :
https://github.com/lightningdevkit/rust-lightning/blob/eec5ec6b50720144fc23503c3ee9c1c8850517ac/lightning/src/routing/scoring.rs#L336

Best,
Antoine

Le mer. 17 mai 2023 à 21:49, Clara Shikhelman <clara.shikhelman at gmail.com>
a écrit :

> Hi,
>
>
>> The lack of transitivity of the reputation acquisition cost (e.g based on
>> historical fees earned from forwards originating from the peer) between the
>> hops of the payment path still raises a vulnerability issue for the
>> endorsement scheme, I think.
>>
>> Namely, let's say you have Alice, Bob and Caroll where endorsement has
>> been obtained by Alice on the Bob incoming link by paying fees for an
>> amount of 1000 sats for the last 100 blocks. Caroll offers a far higher
>> pricing on her incoming link from Bob, 10000 sats as `fee_base_msat` on her
>> endorsed slots. It sounds to me there is nothing preventing Alice from
>> sacrificing her earned reputation to inflict a loss of routing fees damage
>> on Caroll incoming link ?
>>
>
> I think it's important to differentiate between fees a node charges and
> *reputation_revenue*. Reputation is determined as a function of the
> latter. If Caroll has a very high *reputation_revenue* and Bob has a very
> low one, then Bob probably won't have a high reputation with Caroll, as the
> amount of fees he forwards to Caroll is smaller than the damage he can
> create. That is, if Caroll is a huge node and Bob is a raspberry pi, then
> Bob will never have a good reputation with Caroll. If they have similar
> *reputation_revenue*, then getting a good reputation with Bob is as
> difficult as getting a good reputation with Caroll.
>
> In your example (if I got it correctly) Bob's *reputation_revenue* =
> 1,000, *reputation_window*=100 and *routing_window*=10. Could you explain
> what are Caroll's parameters are in your example? The *fee_base_msat*
> does not indicate Carolls *reputation_revenue* (unless Alice is the only
> one transacting on the Bob-Caroll channel, and then she is the one paying
> for Bob's reputation).
>
> That being said, we use *reputation_revenue *to estimate the damage an
> attacker can create. If there is a chain of nodes that have high reputation
> with each other, and they are jammed, they would be compensated for the
> revenue lost during the attack. If Bob finds that having a high reputation
> with Caroll is crucial and 1,000 sats will not compensate him for loosing
> it, then he should either never endorse anything on that channel, or at
> least put a higher bar than *reputation_revenue*.
>
> There is an independent new observation on the effect of dynamic
>> reputation windows on payment reliability, as those windows are not
>> announced to the rest of the network, sudden changes in the links
>> throughput based on HTLC resolution might break the historical liquidity
>> buckets of routing scoring algorithms (at least in the way we're doing it
>> for LDK), I think ?
>>
>
> Not sure what you mean by that.
>
> Best,
> Clara
>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20230531/5017e472/attachment.html>;

📅 Original date posted:2023-05-17 📝 Original message: Hi ...

2023-06-09T15:08:49+02:00

In reply to nevent1q…5s0m
_________________________

📅 Original date posted:2023-05-17
📝 Original message:
Hi all,

> That is, one cannot gain reputation during low fee times and use it when
fees are high.

> Good reputation is also a function of the general environment, and so if
there is a fee spike, reputation will change. It is true that nodes can go
rogue, but this is why we aim > for the price of a good reputation to be
similar to the amount of damage they can create.

The lack of transitivity of the reputation acquisition cost (e.g based on
historical fees earned from forwards originating from the peer) between the
hops of the payment path still raises a vulnerability issue for the
endorsement scheme, I think.

Namely, let's say you have Alice, Bob and Caroll where endorsement has been
obtained by Alice on the Bob incoming link by paying fees for an amount of
1000 sats for the last 100 blocks. Caroll offers a far higher pricing on
her incoming link from Bob, 10000 sats as `fee_base_msat` on her endorsed
slots. It sounds to me there is nothing preventing Alice from sacrificing
her earned reputation to inflict a loss of routing fees damage on Caroll
incoming link ?

Generally, I think the endorsement scheme assumes some synchronicity in the
setting of routing fees by the hops. In practice, it's expected there will
be variations based on their own pricing of liquidity, their accumulated
data sets (e.g historical view of LN gossips) and downstream link topology.
And this is the same between building a mitigation on concepts like
"peace/war" time, sophisticated attackers might be able to mask their
traffic as some spontaneous congestion.

There is an independent new observation on the effect of dynamic reputation
windows on payment reliability, as those windows are not announced to the
rest of the network, sudden changes in the links throughput based on HTLC
resolution might break the historical liquidity buckets of routing scoring
algorithms (at least in the way we're doing it for LDK), I think ?

Best,
Antoine

Le mer. 10 mai 2023 à 16:59, Clara Shikhelman <clara.shikhelman at gmail.com>
a écrit :

> Hi Christian,
>
> Thanks for your comments! We will discuss this further in the upcoming
> call on the 15th, would be great to see you there!
>
>
>> this is an intrinsic issue with reputation systems, and the main
>> reason I'm sceptical w.r.t. their usefulness in lightning.
>> Fundamentally any reputation system bases their expectations for the
>> future on experiences they made in the past, and they are thus always
>> susceptible to sudden behavioral changes (going rogue from a prior
>> clean record) and whitewashing attacks (switching identity, abusing
>> any builtin bootstrapping method for new users to gain a good or
>> neutral reputation before turning rogue repeatedly).
>>
>
> In the Lightning Network, fees are a native way to put a price on having a
> good reputation (see details here [0]). In the design that we suggest, the
> reputation gained today cannot be used in the distant future, and funds
> need to be invested continuously to keep a good reputation. Good reputation
> is also a function of the general environment, and so if there is a fee
> spike, reputation will change. It is true that nodes can go rogue, but this
> is why we aim for the price of a good reputation to be similar to the
> amount of damage they can create.
>
>
>> This gets compounded as soon as we start gossiping about reputations,
>> since now our decisions are no longer based just on information we can
>> witness ourselves, or at least verify its correctness, and as such an
>> attacker can most likely "earn" a positive reputation in some other
>> part of the world, and then turn around and attack the nodes that
>> trusted the reputation shared from those other parts.
>>
>
> Notice that we are not gossiping about our peer's reputation. The only
> thing that a node communicates to its neighbor is whether they see an HTLC
> as endorsed or just neutral, that is, should this HTLC be granted access to
> all of the resources or just the restricted part.
>
>
>> I'd be very interested in how many repeat interactions nodes get from
>> individual senders, since that also tells us how much use we can get
>> out of local-only reputation based systems, and I wouldn't be
>> surprised if, for large routing nodes, we have sufficient data for
>> them to make an informed decision, while the edges may be more
>> vulnerable, but they'd also be used by way fewer senders, and the
>> impact of an attack would also be proportionally smaller.
>>
>
> This is something we hope to learn once we'll start collecting data from
> our brave volunteers :)
>
> Cheers,
> Clara
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20230517/9cd075a3/attachment.html>;

📅 Original date posted:2023-05-06 📝 Original message: Hi *, ...

2023-06-09T15:08:47+02:00

In reply to nevent1q…ap7f
_________________________

📅 Original date posted:2023-05-06
📝 Original message:
Hi *,

> Our suggestion is to start simple with a binary endorsement field. As
> we learn more, we will be better equipped to understand whether a
> more expressive value is required.

I think the HTLC endorsement scheme as proposed is still suffering from a
vulnerability as local reputation can be built up during periods of low
routing fees, endorsement gained and then abused during periods of high
routing fees. Therefore, it sounds to me this scheme should aim for some
reputational transitivity between incoming traffic and outgoing traffic.
Namely, the acquisition cost of the local reputation should be equal to the
max timevalue damage that one can inflict on a routing node channel
accessible from its local counterparty granting this high-level of
reputation.

I don't know if this can be fixed by ensuring permanent link-level "gossip"
where counterparties along a payment path expose their reputation
heuristics to guarantee this transitivity, or it's a fundamental issue with
a point-to-point approach like HTLC endorsement.

Opened an issue on the repository to converge on a threat model:
https://github.com/ClaraShk/LNJamming/pull/13

I still think building data gathering infrastructure for Lightning is
valuable as ultimately any jamming mitigation will have to adapt its
upfront fees or reputation acquisition cost in function of HTLC traffic and
market forces.

Looking forward to giving an update on Staking Credentials [0], an
end-to-end approach to mitigate channel jamming.

Best,
Antoine

[0]
https://lists.linuxfoundation.org/pipermail/lightning-dev/2022-November/003754.html

Le dim. 30 avr. 2023 à 03:57, Carla Kirk-Cohen <kirkcohenc at gmail.com> a
écrit :

> Hi list,
>
> Some updates on channel jamming!
>
> # Next Call
> - Monday 01 May @ 15:00 UTC
> - https://meet.jit.si/UnjammingLN
> - Agenda: https://github.com/ClaraShk/LNJamming/issues/12
>
> # Data Gathering
> During these weekly calls, we've come to agreement that we would like
> to gather data about the use of HTLC endorsement and local reputation
> tracking for jamming mitigation. A reminder of the full scheme is
> included at the end of this email, and covered more verbosely in [1].
>
> We have a few goals in mind:
> - Observe the effect of endorsement in the steady state with
> logging-only implementation.
> - Gather real-world data for use in future simulation work.
> - Experiment with different algorithms for tracking local reputation.
>
> The minimal changes required to add HTLC endorsement are outlined in [2].
> Our suggestion is to start simple with a binary endorsement field. As
> we learn more, we will be better equipped to understand whether a
> more expressive value is required.
>
> With this infrastructure in place, we can start to experiment with
> various local reputation schemes and data gathering, possibly even
> externally to LN implementations in projects like circuitbreaker [3].
> We'd be interested to hear whether there's any appetite to deploy using
> an experimental TLV value?
>
> # Reputation Scheme
> - Each node locally tracks the reputation of its direct neighbors.
> - Each node allocates, per its risk tolerance:
> - A number of slots reserved for endorsed HTLCs from high reputation
> peers.
> - A portion of liquidity reserved for endorsed HTLCs from high
> reputation peers.
> - Forwarding of HTLCs:
> - If a HTLC is endorsed by a high reputation peer, it is forwarded
> as usual with endorsed = 1.
> - Otherwise, it is forwarded with endorsed = 0 if there are slots and
> liquidity available for unknown HTLCs.
>
> Endorsement and reputation are proposed as the first step in a two part
> scheme for mitigating channel jamming:
> - Reputation for slow jams which are easily detected as misbehavior.
> - Unconditional fees for quick jams that are difficult to detect, as
> they can always fall under a target threshold.
>
> Looking forward to discussing further in the upcoming call!
>
> Best,
> Carla and Clara
>
> [1] https://gist.github.com/carlaKC/be820bb638624253f3ae7b39dbd0e343
> [2] https://github.com/lightning/bolts/pull/1071
> [3] https://github.com/lightningequipment/circuitbreaker
> _______________________________________________
> Lightning-dev mailing list
> Lightning-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20230506/40daccce/attachment.html>;

📅 Original date posted:2023-03-06 📝 Original message: Hi ...

2023-06-09T15:08:18+02:00

In reply to nevent1q…ggky
_________________________

📅 Original date posted:2023-03-06
📝 Original message:
Hi all,

My understanding of the local reputation channel is the following, when Bob
receives a HTLC forwarding request from Alice to Caroll:
- if Alice has reputation of 1 and Alice endorses the transaction, Bob
forwards and endorses the HTLC to Caroll
- else if the HTLC amount is under the available outbound liquidity quota
assigned to Alice and available outbound slots assigned to Alice, Bob
forwards the HTLC to Caroll and reduce available outbound liquidity/slots
assigned to Alice
- else the HTLC is rejected

This is unclear on which criterias the endorsement decision is made (e.g
CLTV expiry delta, odds of settlement, ongoing congestion of outbound
channels ?). Additionally, this is unclear how the available
liquidity/slots on a given outbound channel are initially distributed
between all the inbound channels (e.g proportional to the capacity) and how
they're balanced once the inbound channels start to accumulate reputation.

I don't know if this local reputation scheme precises how reputation is
slashed in case of HTLC failure, and if any "grace" amount/rate is granted
to the inbound channel counterparty, e.g Alice.

Independently of those considerations, I think this local reputation scheme
might suffer from exploitable reputation asymmetries by a jamming adversary.
Let's say you have the topology:

Alice - Bob - Caroll - Dave

Alice accumulated a reputation of 1 towards Bob and same for Bob towards
Caroll. As `fee_base_msat` Bob picked up 1000 msat and Caroll picked up
2000 msat. If Alice forwards a HTLC to Bob and it is endorsed by him before
relay to Caroll, Alice can now inflict a 50 sat damage to Caroll, while
only encumbering the lower-priced reputational cost towards Bob.

This concern could hold in case of asymmetries arising from the dynamic
adjustment of routing fees during an evaluated period of time. E.g both Bob
and Caroll requires routing fees of 1000 msat. Alice builds up a reputation
of 1 towards Bob during this period N. At period N+1, Caroll bumps her
routing fees to 2000 msat. From now on, Alice can exploit this asymmetry.

While I think this deficiency could be fixed by ensuring a proportionality
of the reputation acquisition cost between the inbound channels and the
cost requested by a counterparty on an outbound channel, I believe this
would come with the downside that any update in reputation cost should be
recursively applied to the downstream links (i.e Bob on Alice channel,
Alice on neighbouring inbound channels, etc).

Apart of this reputation asymmetry concern, I think the local reputation
scheme could suffer from spontaneous jamming by "honest" long-term held
packets (e.g CLTV delta=2 weeks), where even if Alice is not scored to 1 by
Bob, she always settles her long-term held packets. However, those packets
are yielding less routing fees to Bob than let's say 14 HTLC packets of
CLTV delta = 1 day.

Finally, the dynamic reduction of the available outbound liquidity/slots in
the occurrence of reputation=0 counterparty's HTLC being only known at the
link-level could break the expectations of the HTLC senders scoring
algorithms. E.g, being connected to Alice might have probed through another
path the available liquidity on the link Bob-Caroll. This Eve's probe is
falsified by any reduction done by Caroll towards Bob, and therefore Eve's
payment reliability is likely to be downgraded.

Best,
Antoine

Le jeu. 16 févr. 2023 à 21:29, Clara Shikhelman <clara.shikhelman at gmail.com>
a écrit :

> Hi List,
>
> We’re writing to seek early feedback on a draft for a neighbour reputation
> setting recommendation as a jamming mitigation. The main idea is that
> allowing full access to liquidity and slots in a channel can result in
> jamming. To prevent this, we allow full access only to neighbours that
> forward HTLC that resolve quickly and generate more profit than the damage
> they can potentially create.
>
> The full suggested jamming mitigation solution includes upfront fees
> together with reputation, see [1] for details.
>
> In the previous episodes:
>
> As presented here [1], we suggest a two part jamming mitigation strategy.
> Reputation-based forwarding is aimed to solve “slow jamming”, where the
> jamming transaction takes a long time to resolve.
>
> The main idea is that each node gives a binary reputation to its
> neighbour. Each channel has a quota of liquidity and slots (say 50% of the
> channel size and 50% of the slots in the channel) dedicated to transactions
> coming from neighbours with reputation 0, or for transactions coming from
> neighbours with reputation 1 that were not endorsed by the neighbour.
>
> For example, when Alice asks Bob to forward to Charlie then:
>
> If (Alice has reputation 1 with Bob) and (Alice endorses transaction):
>
> Forward and endorse
>
> Else:
>
> If (amount < available liquidity quota) and (available slots in quota>0):
>
> Forward HTLC without endorsing
>
> Reduce available liquidity and slots
>
> Else:
>
> Reject
>
> Reputation:
>
> The question we discuss here is how does Alice gain “good” reputation
> (i.e., a score of 1). Alice starts at 0, and she gains and keeps her good
> reputation of 1 by continuously paying more fees to Bob than the damage she
> can inflict.
>
> The 3 main parameters for reputation that each node operator picks are S,L
> and M. Our recommendations are as follows:
>
> -
>
> S should be chosen as the maximum time an HTLC can be unresolved in
> any of Bob’s channels.
> -
>
> M is the revenue generated by Bob’s node in the time S, representing
> the damage Alice could inflict.
> -
>
> L is the time in which Alice should generate M revenue for Bob for her
> to have a good reputation of 1. We suggest L=10S.
>
>
> Alice has reputation 1 if, in the last L seconds, she has forwarded
> payments that generated M satoshi in fees.
>
> As an example:
>
> -
>
> Bob has a maximum CLTV delta of 2 weeks [2]
> -
>
> Over the last 2 weeks, he has earned 0.5 BTC in routing fees
> -
>
> Alice will be considered to have good reputation if she has forwarded
> 0.5 BTC of routing revenue to Bob over the last 20 weeks
>
>
> Formally:
>
> Let t be the current time, and let S and L be constants.
>
> M is calculated to be the revenue of Bob in time [t-S,t]. The revenue of
> Bob is the sum of fees from transactions forwarded by any neighbour besides
> Alice + any payments received by Bob. Note that Bob can choose to also take
> into account utility gained from sending payments or anything of value to
> the node operator.
>
> Alice has reputation 1 if in the time [t-L,t] she has forwarded HTLCs
> that paid M in normalized fees.
>
> We normalize fees by resolution time to reward payments that resolve
> quickly and discount slow resolving payments. Here we assume 10 seconds is
> the “normal” resolution time, this number can be bikesheded, and we round
> up to avoid penalizing transactions resolved quicker than the “normal”.
>
> The fee from a single transaction is normalized by the time it took for
> the HTLC to resolve, counted in slots of 10 seconds. That is:
>
> Normalized_fee = (fee)/[ceiling(time_to_resolve/10s)]
>
>
>
> Some notes
>
> 1.
>
> The reputation management happens locally, that is, the only protocol
> change needed is the ability to signal endorsement as a TLV in
> UpdateAddHTLC. The various parameters can be selected for various risk
> preferences.
> 2.
>
> We currently suggest a binary reputation for simplicity. Having
> several buckets could be interesting to study, yet we don’t think that the
> complexity and the possible privacy issues are worth the potential benefits.
> 3.
>
> For most use cases, having reputation 0 is more than enough. If we
> send and receive transactions at a low rate, we usually don’t need the full
> liquidity and slots available in a channel. Reputation mostly comes into
> play only when a channel is under attack, and then not all transaction are
> allowed to go through.
> 4.
>
> Following this thread [3]: it is important to note that we are only
> giving reputation to our direct neighbours. An advantage of this is that we
> have repeated interactions with them. In practice, this is also the only
> clean data we have to use when deciding whether to forward an HTLC or not.
>
>
> Best,
>
> Carla and Clara
>
>
> [1]
> https://lists.linuxfoundation.org/pipermail/lightning-dev/2022-November/003740.html
> [2]
> https://github.com/lightningnetwork/lnd/blob/de94a4ea5e81799330a72dfde111817b38565d99/htlcswitch/link.go#L51
> [3]
> https://lists.linuxfoundation.org/pipermail/lightning-dev/2023-February/003842.html
> _______________________________________________
> Lightning-dev mailing list
> Lightning-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20230306/d19448db/attachment-0001.html>;

📅 Original date posted:2022-12-13 📝 Original message: Hi ...

2023-06-09T15:07:43+02:00

In reply to nevent1q…pcdg
_________________________

📅 Original date posted:2022-12-13
📝 Original message:
Hi AJ,

I believe we're in sync on the attack description.

> prior to (1): UA.k (k <= n) -- However this allows Bob to immediately
> broadcast one of either CA.n or RA.n, and will then have ~150 blocks
> to claim the HTLC before its timeout

>From my understanding, with two party eltoo w/punihsment, UA.k has a
tapscript path with "1 CHECKSIGVERIFY k<n CLTV", where the internal pubkey
substituted is "musig(A,B)/1. Mallory should receive Bob's signature for
UA.k, though also UA.k+1, UA.k+2, UAk+3, until k=n.

Or is this a tapscript only existing for the dual-funding case ? I think
this a bit unclear from the gist construction, how Mallory is restrained to
use the tapscript path on UA.k, with UA.k+1 as she should be in possession
of Bob's signature for this state.

> I think traditional eltoo envisages being able to spend update transaction
> 1 immediately, without having to wait for the next block. This might
> not be compatible with the version 3 relay rules that are being thought
> about, though, and presumably would hit ancestor limits.

While update transaction 1 could spend update transaction 0 immediately,
there is no reliable knowledge by U*.1 transaction broadcaster of the state
of the network mempools. I believe the update transactions themselves could
be used to partition network mempools in multiple subsets (at least this is
achievable under LN-penalty with using old revoked states).

> I think a simple way to avoid that problem would be for eltoo nodes
> to have a priority tx relay network -- if they see a channel close to
> state N, always replace any txs closing to an earlier state K<N, and
> always quickly relay that close to all other peers. There's no reason
> to assume the bad guys have the best access to the network when we can
> write code so that the honest participants have it instead.

While I think this solution of eltoo nodes quickly replacing any state K
previous to the latest state N, there is no guarantee the latest state K
doesn't offer a higher feerate than state N, making it more attractive to
the miners.

One other solution could be a p2p extension allowing an update transaction
N to be "blindly" rebinded on any update transaction K, with K < N, by
pointing to the channel funding output, and a per-counterparty ancestor
limit enforced as a policy rule (otherwise the malicious counterparty could
still buy all the ancestor limits).

A more sophisticated solution could be to "trim" the counterparty ability
to confirm multiple update transactions with some TLUV mechanism.

> In the two-party scheme, the only transaction Mallory can broadcast
> after sending UA.k and having it confirmed on chain is SA.k, and that
> only after a 144 block relative timelock. UA.(k+1) etc only spend the
> funding output, but that has already been spent by UA.k.

See above question on the existence of a tapscript 1 path in update
transaction, and by which transaction type it could/should be spent. I
think the crux of the attack's soundness (or not) against two parties eltoo
w/ punishment relies here. AFAICT, if there is an unbounded spending path
cycle introduced for one of the counterparties, you're exposed to "eltoo
states overflow".

Best,
Antoine

Le lun. 12 déc. 2022 à 22:51, Anthony Towns <aj at erisian.com.au> a écrit :

> On Mon, Dec 12, 2022 at 08:38:43PM -0500, Antoine Riard wrote:
> > The attack purpose is to delay the confirmation of the final settlement
> > transaction S, to double-spend a HTLC forwarded by a routing hop.
> > The cltv_expiry_delta requested by Ned is equal to N=144.
>
> I believe what you're suggesting here is:
>
> Mallory has two channels with Bob, M1 and M2. Both have a to_self_delay
> of 144 blocks. In that case cltv_expiry_delay should include some slack,
> I'm going to assume it's 154 blocks in total.
>
> Mallory forwards a large payment, M1->Bob->M2.
>
> Mallory claims the funds on M2 just prior to the timeout, but
> goes offline on M1.
>
> Bob chose the timeout for M2 via cltv_expiry_delay, so now has 154
> blocks before the CLTV on the M1->Bob payment expires.
>
> In this scenario, under the two-party eltoo scheme, Bob should:
>
> 1) immediately broadcast the most recent UB.n state for M1/Bob,
> aiming for this to be confirmed within 5 blocks
>
> 2) wait 144 blocks for the relative timelock to expire
>
> 3) broadcast SB.n to finalise the funds, and immediately claim the
> large HTLC. providing this confirms within 5 blocks, it will confirm
> before the HTLC timelock expires, and Mallory will have been unable
> to claim the funds.
>
> The only transactions Mallory could broadcast are:
>
> prior to (1): UA.k (k <= n) -- However this allows Bob to immediately
> broadcast one of either CA.n or RA.n, and will then have ~150 blocks
> to claim the HTLC before its timeout
>
> during (2): CA.n -- Again, this allows Bob to claim the HTLC
> immediately, prior to its timeout
>
> The only delaying attack with repeated transactions comes if Bob
> broadcasts an old state UB.k (k < n), in which case Mallory can broadcast
> (n-k) WA.i watchtower transactions prior to finalising the state. However
> if Bob *only* has old state, Mallory can simply broadcast WA.n, at which
> point Bob can do nothing, as (by assumption) he doesn't have access
> to current state and thus doesn't have SB.n to broadcast it.
>
> > The attack scenario works in the following way: Malicia updates the Eltoo
> > channel N time, getting the possession of N update transactions. At block
> > A, she breaks the channel and confirms the update transaction 0 by
> > attaching a feerate equal to or superior to top mempool block space + 1
> > sat. At each new block, she iterates by confirming the next update
> > transaction, i.e update transaction 1 at block A+1, update transaction
> > transaction 2 at block A+2, update transaction 3 at block A+3, ...
>
> I think traditional eltoo envisages being able to spend update transaction
> 1 immediately, without having to wait for the next block. This might
> not be compatible with the version 3 relay rules that are being thought
> about, though, and presumably would hit ancestor limits.
>
> I think a simple way to avoid that problem would be for eltoo nodes
> to have a priority tx relay network -- if they see a channel close to
> state N, always replace any txs closing to an earlier state K<N, and
> always quickly relay that close to all other peers. There's no reason
> to assume the bad guys have the best access to the network when we can
> write code so that the honest participants have it instead.
>
> > From Ned's viewpoint, there is limited rationality of the network
> mempools,
> > as such each punishment transaction R, as it's confirmation could have
> been
> > delay due to "honest" slow propagation on the network is likely to be
> > pre-signed with top mempool block space feerate, but not more to save on
> > fees. Therefore, transaction RN.0 should fail to punish update
> transaction
> > 0 as it's double-spent by update transaction 1, transaction RN.1 should
> > fail to punish update transaction 1 as it's double-spent by update
> > transaction 2, transaction RN.2 should fail to punish update transaction
> 2
> > as it's double-spent by update transaction 3...
>
> In the two-party scheme, the only transaction Mallory can broadcast
> after sending UA.k and having it confirmed on chain is SA.k, and that
> only after a 144 block relative timelock. UA.(k+1) etc only spend the
> funding output, but that has already been spent by UA.k.
>
> Cheers,
> aj
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20221213/caed9efb/attachment-0001.html>;

📅 Original date posted:2022-12-09 📝 Original message: Hi ...

2023-06-09T15:07:40+02:00

In reply to nevent1q…r9w9
_________________________

📅 Original date posted:2022-12-09
📝 Original message:
Hi Clara,

Thanks for rolling the ball forward.

On the agenda, a few more thoughts.

> 1. Which parameters should be considered in reputation-based solutions?

I think before thinking about the parameters of reputation-based solutions,
we should discuss the security goal we're aiming to achieve with any
potential jamming solutions. Browsing the solution space some have aimed to
increase the opportunity cost for the attacker (e.g liquidity slots), some
to reduce the jamming intensity (e.g circuit breakers), some inflicting a
on-chain fee damage cost back to the adversary (e.g stake certificates),
some to achieve economic hedge of the routing hops (e.g unconditional
fees, reputation credentials). As of today, I would say a security goal
designed in the term of a monetary strategy could be more acceptable to the
routing hops node operators. Beyond that, I believe there is capturing this
design goal in a "measurable" notion, such as the unjamming lightning
paper's breakeven point, and see how we can enrich this "measurable" notion.

> 2. Circuitbreaker [1]

While reviewing the circuitbreaker last week, I started to wonder if there
wasn't another "hidden" issue while solving channel jamming, namely
congestion control of the HTLC flows. A node operator is not only
interested that any liquidity unit allocated for a HTLC forward is paid
back with routing fees, but also in case of more forward demand than
liquidity offer, ready to process it (potentially by deferring and sending
backpressure messages to the HTLC sender). I don't know, though I think
that can be an interesting point to discuss.

> 3. Onion relay network [2] and its potential uses.

Onion relay network rate-limits have been discussed earlier this year, with
a probabilistic backpressure scheme proposed. If the onion relay traffic
starts to have economically-weighable traffic (offers, credentials tokens,
etc), there could be a risk of onion-jamming. For the bootstrap of the
onion relay network, I believe this could be solved by leveraging more the
channel-network topology for the design of a solution. We could re-use the
evaluation framework from the unjamming lightning paper, I guess.

In the meeting, I think it could be very valuable if we have reliable
transcripts and if we start to maintain a community repository, where we
can pin the issues, problems and ideas.

On the frequency of the meeting, note some Lightning developers raised the
concern that biweekly might be too much:
https://gnusha.org/lightning-dev/2022-11-23.log (once a month could work
well too, if we have a sound agenda).

Best,
Antoine

Le jeu. 8 déc. 2022 à 11:08, Clara Shikhelman <clara.shikhelman at gmail.com>
a écrit :

> Hi all,
>
> The agenda for next week's meeting (Monday the 12th, 7 pm UTC) is the
> following:
>
> 1. Which parameters should be considered in reputation-based solutions?
> 2. Circuitbreaker [1]
> 3. Onion relay network [2] and its potential uses.
>
> The link to the call: https://meet.jit.si/UnjammingLN
>
> See you there,
> Clara
>
> [1]
> https://lists.linuxfoundation.org/pipermail/lightning-dev/2022-December/003781.html
> [2]
> https://lists.linuxfoundation.org/pipermail/lightning-dev/2022-December/003780.html
>
> On Sun, Nov 27, 2022 at 9:48 PM Clara Shikhelman <
> clara.shikhelman at gmail.com> wrote:
>
>> Hi all,
>>
>> In light of recent conversations ([1],[2]), the agenda for the call
>> tomorrow (Monday the 28th, 7 pm UTC) is roughly the following:
>>
>> 1. Overview of solutions under discussion
>> 2. Reputation (local/tokens)
>> 3. Fees
>>
>> This is the link to the call: https://meet.jit.si/UnjammingLN
>>
>> See you there,
>> Clara
>>
>> [1]
>> https://lists.linuxfoundation.org/pipermail/lightning-dev/2022-November/003740.html
>> [2]
>> https://lists.linuxfoundation.org/pipermail/lightning-dev/2022-November/003754.html
>> _______________________________________________
>> Lightning-dev mailing list
>> Lightning-dev at lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
>>
> _______________________________________________
> Lightning-dev mailing list
> Lightning-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20221208/e56d9ec4/attachment.html>;

📅 Original date posted:2022-12-08 📝 Original message: Hi ...

2023-06-09T15:07:37+02:00

In reply to nevent1q…zkcp
_________________________

📅 Original date posted:2022-12-08
📝 Original message:
Hi AJ,

The eltoo irc channel is ##eltoo on Libera chat.

> - 2022-10-21, eltoo/chia:
https://twitter.com/bramcohen/status/1583122833932099585

On the eltoo/chia variant, from my (quick) understanding, the main
innovation aimed for is the limitation of the publication of eltoo states
more than once by a counterparty, by introducing a cryptographic puzzle,
where the witness can be produced once and only once ? I would say you
might need the inheritance of the updated scriptpubkey across the chain of
eltoo states, with a TLUV-like mechanism.

> The basic idea is "if it's a two party channel with just Alice and Bob,
> then if Alice starts a unilateral close, then she's already had her say,
> so it's only Bob's opinion that matters from now on, and he should be
> able to act immediately", and once it's only Bob's opinion that matters,
> you can simplify a bunch of things.

>From my understanding, assuming Eltoo paper terminology, Alice can publish
an update K transaction, and then after Bob can publish an update
transaction K<N or Alice can publish the settlement transaction N, or Bob
can publish an update transaction N. The main advantage of this
construction I can see is a strict bound on the shared_delay encumbered in
the on-chain publication of the channel ?

> fast forwards: we might want to allow our channel partner
> to immediately rely on a new state we propose without needing a
> round-trip delay -- this potentially makes forwarding payments much
> faster (though with some risk of locking the funds up, if you do a
> fast forward to someone who's gone offline)

IIRC, there has already been a "fast-forward" protocol upgrade proposal
based on update-turn in the LN-penalty paradigm [0]. I think reducing the
latency of HTLC propagation across payment paths would constitute a UX
improvement, especially a link-level update mechanism upgrade deployment
might be incentivized by routing algorithms starting to penalize routing
hops HTLC relay latency. What is unclear is the additional risk of locking
the funds up. If you don't receive acknowledgement the fast forward state
has been received, you should still be able to exit with the state N-1 ?
However, the fast-forward trade-off might sound acceptable, with time you
might expect reliable routing hops in the core of the graph, and flappy
spokes at the edge.

> doubled delays: once we publish the latest state we can, we want to
> be able to claim the funds immediately after to_self_delay expires;
> however if our counterparty has signatures for a newer state than we
> do (which will happen if it was fast forwarded), they could post that
> state shortly before to_self_delay expires, potentially increasing
> the total delay to 2*to_self_delay.

While the 2*to_self_delay sounds the maximum time delay in the state
publication scenario where the cheating counterparty publishes a old state
then the honest counterparty publishes the latest one, there could be the
case where the cheating counterparty broadcast chain of old states, up to
mempool's `limitancestorcount`. However, this chain of eltoo transactions
could be replaced by the honest party paying a higher-feerate (assuming
something like nversion=3). I think there might still be an attack
triggerable under certain economic conditions, where the attacker overbids
with the higher-feerate transaction until the HTLC cltv expires. If this
attack is plausible, it could be even opportun if you're batching against
multiple channels, where the victims are not able to coordinate response.

> penalties: when you do a unilateral close, attempting to cheat comes
> with no cost to you and a possible benefit if you succeed, but
> potentially does cost your channel partner (either in forcing them
> to spend on-chain fees to update to the correct state, or in the risk
> of loss if their node malfunctions occassionally) -- a penalty could
> reduce this incentive to cheat

I think there has been a proposal in the past to enable penalties on top of
symmetric states by leveraging asymmetric witnesses [1]. Further, I wonder
if there is a game-theory interest for penalty-on-top-eltoo, it could be an
incentive against laziness, where a dysfunctional trusted watchtower
broadcasts an old state. On the qualification of the game-theory soundness,
I think one would have to run the empirical case study: select channel
counterparties randomly (no out-of-band assumptions), one set with
eltoo+penalty and the other with vanilla eltoo, observe the broadcast of
revoked states over some period.

> trustless watchtowers: we may want to consider the possibility of a
> watchtower holding onto obsolete states and colluding with an
> attacker to attempt to cheat us

In terms of pinning and other mempool games, I think honest participant own
states leveraged by a colluding watchtower might increase the attack
surface, especially post-anchor with the SIGHASH_SINGLE malleability on
second-stage HTLC transactions.

> (I think for initial eltoo experimentation it doesn't make sense to try to
> deal with all (or perhaps any) of those constraints; simple and working
> is better than complex and theoretical. But having them written down so
> the ideas can be thought about and looked up later still seems useful)

I share the belief -- "simple and working" enable shorter iteration cycles
and hopefully fasten the protocol design learning curve. Beyond, I think
it's also realistic in face of the state of the LN ecosystem, especially on
the watchtower issue. AFAICT, there is no even multi trusted watchtower
design covering the full execution of the protocol (i.e including
HTLC-preimage/ HTLC-timeout claim), and such implementation is far from
simple, as from now on you LN's chain backend might have asynchronicity
issue to solve between your on-chain monitoring state machine (at least
speaking in knowledge of the LDK-architecture).

> * WA.n, WB.n : watchtower update to state n
> - this is for an untrusted watchtower to correct attempted cheating
> by Bob on behalf of Alice (or vice-versa). Spends UB.k or WA.k
> (or UA.k/WB.k) respectively, provided k < n.

I wonder if the introduction of watchtower specific transactions doesn't
break the 2*to_self_delay assumption (iiuc it's a design goal of current
protocol) and what is the design rationale. Beyond that, there is a concern
with watchtower-specific transactions, it might leak your towers topology
(i.e the number of them and the distribution in the p2p network) to an
adversary.

> * SA.n, SB.n : slowly claim funds according to state n
> - this is for Alice to claim her funds if Bob is completely offline
> (or vice-versa). Spends UA.n, UB.n, WA.n or WB.n with relative
> timelock of to_self_delay.

If I'm following correctly the description, this is logically equivalent to
the sweep of a `to_local`/`to_remote` output on a commitment transaction
though instead the waiting delay is eltoo shared_delay. There is no
to_self_delay, at the punishment seems only to happen on the update-level,
or maybe one should be also able to punish slow fund exit, and another
relative locktime should exist on the S* transactions.

> * Alice and Bob's watchtower collude, but Bob has many watchtowers:
>
> F -> UA.k1 -> WB.k2 -> WB.n -> (to_self_delay) -> SA.n -> money

Could the punishment transactions R* be also delegated to watchtowers,
assuming they have been pre-signed to lockdown the exit scriptpubkeys ?

> In order to allow fast-forwards, when Alice proposes a new state,
> she needs to send her partial signatures to allow Bob to unilaterally
> accept the new state, ie sigs for: UB.n, CB.n, SB.n, RB.n. But she
> also needs to be able to claim the funds if Bob proposes the new state
> and broadcasts UB.n, she needs to be able broadcast CA.n. This can be
> achieved with an adaptor signature approach (spelt out a bit more fully
> in the gist) or a CTV-like approach, provided that UB.n reveals the
> state needed to calculate the the CTV commitment (see "EXPR_SETTLE" in
>
https://github.com/instagibbs/bolts/blob/29fe6d36cbad4101d5ec76c2b19c83c1494ac2fc/XX-eltoo-transactions.md
).

If you would like to have fast forward of chain of transactions, I wonder
if there could be also the "sig-in-the-script" trick, where UB.n
scriptpubkey (or one of its tapscripts) contains the signature for CB.n,
SB.n, RB.n. Though you might have an issue of re-generating the
witnessscript in case of state loss.

> * how to add fees -- the U/W transactions are 1-in/1-out transactions
> that can't be trivially CPFPed by the proposer and need to have
> fees added (either SINGLE/ANYONECANPAY signatures or having a 0-sat
> ephemeral output and package relay might be workable); the C/S/R
> transactions are 1-in/many-out transactions, but have balance outputs
> that can be immediately spent to pay for fees via CPFP if package
> relay is available.

Assuming something like nversion=3, the SINGLE/ANYONCANPAY could be a
viable fee-bumping mechanism, as ancestor-based pinning should be less of a
concern. Ephemeral anchor output could be a more efficient direction, if
the output value can be cooperatively inflated from the channel value,
rather than relying on external fee-bumping reserves. I think even more
efficient fee-bumping primitives can be introduced later.

> * how to pay watchtowers -- when a watchtower broadcasts a W
> transaction, it needs to add fees, and it's not clear (to me) how it
> could fairly and reliably ensure it's compensated for those costs,
> particularly if multiple W transactions are broadcast for a single
> unilateral close attempt, due to one or more watchtowers colluding
> with an attacker, or simply having out of date information.

I wonder if paying a watchtower, or getting paid as a watchtower isn't a
"counterparty risk" similar to what is happening with jamming due to
non-covered HTLC forward risk. The watchtower has the risk of not being
paid a posteriori and the user has the risk of the tower not acting. There
is even a trade-off between tower costs and safety, as the more towers you
have, more robust if your Lightning channel (in theory, as you also have a
duplication of the key material).

> * lack of layered transactions -- while this prevents you having to
> wait longer than to_self_delay before you can claim channel funds,
> it still means that any htlc that is going to timeout sooner than that
> may not be claimable on-chain, meaning you need to set
> cltv_expiry_delta >= to_self_delay.

>From a security perspective, offsetting the cltv_expiry_delta to a value
superior to to_self_delay can be considered as an improvement, especially
if it gradually does it network-wide. On the other hand, if routing
algorithms start to penalize long-cltv-delta payment paths as the timevalue
of liquidity is priced in routing fees, this design rationale might not be
aligned with long-term LN network incentives (as of today even more
loosely-defined than miner incentives).

> * extending to multiparty channels -- penalising is hard if there's
> more than two parties, fast forwards are probably impossible since
> you need multiple round-trips to coordinate signatures anyway, and if
> you're doing channels-within-channels to reduce your n-party channel
> to an easier to update 2-party channel you're probably forced to have
> to_self_delay for each layer of channels. Also, just figuring out how
> to coordinate multiparty state updates and even keeping everyone in
> a multiparty channel online consistently to generate new signatures
> seems potentially hard?

I don't know if penalising has been a solved issue for mulit-party, at
least in a trustless fashion in the same way we have with 2-party
LN-penalty (you could devise weird scheme based on timelock, taproot tree
and threshold signatures incentivizing towards the convergence of a
"consensus" punishment, still...) Figuring out coordinating multi-party
states updates sounds workable with modern consensus algorithms (e.g Raft),
though still conserving the fast forward effect is a high bar, it might be
better deferred to an uplifted layer of 2-of-2 LN channels. The only reason
you might have payments at the multi-party level (with the signature of the
N-of-N participants requested) only for privacy or liquidity allocation
reason. Though effectively, it sounds like your multiparty
channel coordination mechanism should encompass party eviction or
partitioning the offline parties. One or two orders of magnitude of
complexity beyond the 2-party eltoo channel case, I think.

Antoine

[0] https://github.com/lightning/bolts/pull/867
[1] https://github.com/LLFourn/witness-asymmetric-channel

Le mer. 7 déc. 2022 à 00:36, Anthony Towns <aj at erisian.com.au> a écrit :

> Hi all,
>
> On the eltoo irc channel we discussed optimising eltoo for the 2-party
> scenario; figured it was probably worth repeating that here.
>
> This is similar to:
>
> - 2018-07-18, simplified eltoo:
> https://lists.linuxfoundation.org/pipermail/lightning-dev/2018-July/001363.html
> - 2021-09-17, IID 2Stage,
> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-September/019470.html
> - 2022-09-29, Daric: https://eprint.iacr.org/2022/1295
> - 2022-10-21, eltoo/chia:
> https://twitter.com/bramcohen/status/1583122833932099585
>
> The basic idea is "if it's a two party channel with just Alice and Bob,
> then if Alice starts a unilateral close, then she's already had her say,
> so it's only Bob's opinion that matters from now on, and he should be
> able to act immediately", and once it's only Bob's opinion that matters,
> you can simplify a bunch of things.
>
> A "gist" for this idea is
> https://gist.github.com/ajtowns/53e0f735f4d5c06a681429d937200aa5 (it goes
> into a little more detail in places, though doesn't cover trustless
> watchtowers at all).
>
>
>
> In particular, there are a few practical constraints that we might like
> to consider for 2-party channels with eltoo:
>
> - fast forwards: we might want to allow our channel partner
> to immediately rely on a new state we propose without needing a
> round-trip delay -- this potentially makes forwarding payments much
> faster (though with some risk of locking the funds up, if you do a
> fast forward to someone who's gone offline)
>
> - doubled delays: once we publish the latest state we can, we want to
> be able to claim the funds immediately after to_self_delay expires;
> however if our counterparty has signatures for a newer state than we
> do (which will happen if it was fast forwarded), they could post that
> state shortly before to_self_delay expires, potentially increasing
> the total delay to 2*to_self_delay.
>
> - penalties: when you do a unilateral close, attempting to cheat comes
> with no cost to you and a possible benefit if you succeed, but
> potentially does cost your channel partner (either in forcing them
> to spend on-chain fees to update to the correct state, or in the risk
> of loss if their node malfunctions occassionally) -- a penalty could
> reduce this incentive to cheat
>
> - trustless watchtowers: we may want to consider the possibility of a
> watchtower holding onto obsolete states and colluding with an
> attacker to attempt to cheat us
>
> What follows is a rough approach for dealing with all those issues for
> two-party channels. It's spelled out in a little more detail in the gist.
>
> (I think for initial eltoo experimentation it doesn't make sense to try to
> deal with all (or perhaps any) of those constraints; simple and working
> is better than complex and theoretical. But having them written down so
> the ideas can be thought about and looked up later still seems useful)
>
> In more detail: unilateral closes are handled by each channel participant
> maintaining five transactions, which we'll call:
>
> * UA.n, UB.n : unilaterally propose closing at state n
> - this is for Alice or Bob to spend the funding tx for a unilater
> close to state n. Spends the funding transaction.
>
> * WA.n, WB.n : watchtower update to state n
> - this is for an untrusted watchtower to correct attempted cheating
> by Bob on behalf of Alice (or vice-versa). Spends UB.k or WA.k
> (or UA.k/WB.k) respectively, provided k < n.
>
> * CA.n, CB.n : cooperatively claim funds according to state n
> - this is for Alice to confirm Bob's unilateral close (or vice-versa).
> Spends UB.k, WA.k (or UA.k/WB.k respectively), provided k <= n
>
> * SA.n, SB.n : slowly claim funds according to state n
> - this is for Alice to claim her funds if Bob is completely offline
> (or vice-versa). Spends UA.n, UB.n, WA.n or WB.n with relative
> timelock of to_self_delay.
>
> * RA.n, RB.n : claim funds with penalty after unilateral close to
> revoked state
> - this is for Alice to update the state if Bob attempted to cheat
> (or vice-versa). Spends UB.k or WA.k (or UA.k/WB.k respectively)
> conditional on k < n - 1; outputs are adjusted to transfer a fixed
> penalty of penalty_msat from Bob's balance to Alice's (or vice-versa)
>
> Each of these "transactions" requires a pre-signed signature; however
> the actual transaction/txid will vary in cases where a transaction has
> the possibility of spending different inputs (eg "Spends UB.k or WA.k").
> In particular UA.n/UB.n can be constructed with known txids and non-APO
> signatures but WA.n/WB.n/CA.n/CB.n/SA.n/SB.n/RA.n/RB.n all require
> APO signatures.
>
> They're named such that Alice can immediately broadcast all the *A.n
> transactions (provided a tx that it can spend has been broadcast) and
> Bob can likewise immediately broadcast all the *B.n transactions.
>
> Scenarios where Alice decides to unilaterally close the channel might
> look like:
>
> * if Alice/Bob can't communicate directly, but both are online:
>
> F -> UA.n -> CB.n -> money
>
> (balances and htlcs claimed, no delay)
>
> * if Bob has gone offline entirely:
>
> F -> UA.n -> (to_self_delay) -> SA.n -> money
>
> * Alice cheats, Bob punishes:
>
> F -> UA.k -> RB.n -> money[Alice pays Bob penalty]
>
> * Bob is offline, Alice cheats, but Bob has a watchtower:
>
> F -> UA.k -> WB.n -> (to_self_delay) -> SA.n -> money
>
> * Alice and Bob's watchtower collude, but Bob's not offline:
>
> F -> UA.k1 -> WB.k2 -> RB.n -> money[Alice pays Bob penalty]
>
> * Alice and Bob's watchtower collude, but Bob has many watchtowers:
>
> F -> UA.k1 -> WB.k2 -> WB.n -> (to_self_delay) -> SA.n -> money
>
> For Alice to successfully cheat, she needs Bob to be offline for at least
> to_self_delay, and for all Bob's watchtowers to either also be offline,
> or colluding.
>
> This can be simplified somewhat, if you don't care about all the features:
>
> * If you don't care about trustless watchtowers you can drop WA.n/WB.n
> (and simplify SA.n/SB.n to not require an APO signature)
>
> * If you don't care about penalties you can set penalty_msat to 0 and
> allow RA.n/RB.n to spend k<=n. In this case, you can either drop
> CA.n/CB.n entirely, or you can have CA.n/CB.n only be used for directly
> spending of UB.n/UA.n and thus not require APO signatures
>
> In order to allow fast-forwards, when Alice proposes a new state,
> she needs to send her partial signatures to allow Bob to unilaterally
> accept the new state, ie sigs for: UB.n, CB.n, SB.n, RB.n. But she
> also needs to be able to claim the funds if Bob proposes the new state
> and broadcasts UB.n, she needs to be able broadcast CA.n. This can be
> achieved with an adaptor signature approach (spelt out a bit more fully
> in the gist) or a CTV-like approach, provided that UB.n reveals the
> state needed to calculate the the CTV commitment (see "EXPR_SETTLE" in
>
> https://github.com/instagibbs/bolts/blob/29fe6d36cbad4101d5ec76c2b19c83c1494ac2fc/XX-eltoo-transactions.md
> ).
>
> Note that in this scenario Alice doesn't provide WB.n to Bob
> immediately. This is okay, as if Alice proposes UA.(n-1) (her most
> recent state), Bob can still immediately claim via CA.n. If Bob did have
> WB.n; then if Alice proposed UA.(n-1) Bob could wait for an initial
> to_self_delay period and broadcast WB.n, forcing Alice to wait for an
> additional to_self_delay before being able to claim her funds via SA.n.
>
> Note also that this is why RA.n/RB.n require "k < n - 1" -- otherwise
> Alice would only be able to broadcast UA.(n-1) and Bob would immediately
> be able to penalise by broadcasting RB.n.
>
> Note that if you're using a watchtower and wish to punish your
> counterparty if it attempts to cheat, you should only pass WA.(n-2)
> to your watchtowers, not WA.(n-1) or WA.n.
>
>
>
> This doesn't address any potential issues from:
>
> * how to add fees -- the U/W transactions are 1-in/1-out transactions
> that can't be trivially CPFPed by the proposer and need to have
> fees added (either SINGLE/ANYONECANPAY signatures or having a 0-sat
> ephemeral output and package relay might be workable); the C/S/R
> transactions are 1-in/many-out transactions, but have balance outputs
> that can be immediately spent to pay for fees via CPFP if package
> relay is available.
>
> * how to pay watchtowers -- when a watchtower broadcasts a W
> transaction, it needs to add fees, and it's not clear (to me) how it
> could fairly and reliably ensure it's compensated for those costs,
> particularly if multiple W transactions are broadcast for a single
> unilateral close attempt, due to one or more watchtowers colluding
> with an attacker, or simply having out of date information.
>
> * lack of layered transactions -- while this prevents you having to
> wait longer than to_self_delay before you can claim channel funds,
> it still means that any htlc that is going to timeout sooner than that
> may not be claimable on-chain, meaning you need to set
> cltv_expiry_delta >= to_self_delay.
>
> * extending to multiparty channels -- penalising is hard if there's
> more than two parties, fast forwards are probably impossible since
> you need multiple round-trips to coordinate signatures anyway, and if
> you're doing channels-within-channels to reduce your n-party channel
> to an easier to update 2-party channel you're probably forced to have
> to_self_delay for each layer of channels. Also, just figuring out how
> to coordinate multiparty state updates and even keeping everyone in
> a multiparty channel online consistently to generate new signatures
> seems potentially hard?
>
> Cheers,
> aj
> _______________________________________________
> Lightning-dev mailing list
> Lightning-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20221208/6ba33096/attachment-0001.html>;

📅 Original date posted:2022-11-28 📝 Original message: Hi ...

2023-06-09T15:07:28+02:00

In reply to nevent1q…jr39
_________________________

📅 Original date posted:2022-11-28
📝 Original message:
Hi Michael,

Thanks for the feedback,

On the first point, I think it should be underscored how much this proposed
credential system, while labeled a reputational one, belongs more to a
monetary strategy (after the fact should be called "staking" credentials).
Indeed, there is a direct link between the credentials and a cost expressed
in satoshis. Therefore, in case of loopholes in the system damages are
effectively borne by the routing hops, without throwing the whole system
down. Note, the default policy should be some 0-risk HTLC forward
acceptance.

On the second point, we already have today's reputation systems in
Lightning, namely the routing algorithms keeping track of the performance
of the routing hops, and their liquidity. That information is used in a
continuous fashion to improve payment-path building. And while those
algorithms are doing probabilistic estimation of the balance distribution,
the proposed credential system is not all relying on past statistics for
its effectiveness (as long as the node operators are requiring credentials
of worthiness equivalent to routing fees).

On the third point, the protocol defer to the node operators all the
decisions on the credential acquisition costs, expiration height, binding
with liquidity units, or even allow additional routing policy checks.
Flexibility is offered to the node operators, without the protocol
developers trying to do any "centralized" decision on the cost of the
credentials or whatever.

>From my understanding, the critics you're raising, while potentially
correct for the reputation systems links you're including, does not bind to
any concrete point of my proposal. I hope you'll take time to browse the
proposal as detailed more in depth here:
https://github.com/lightning/bolts/pull/1043

Best,
Antoine

Le sam. 26 nov. 2022 à 05:53, Michael Folkson <michaelfolkson at protonmail.com>
a écrit :

> Hi Antoine
>
> I've got a lot to catch up on re channel jamming but just to say I'm
> deeply skeptical about attempting to embed a reputation layer or reputation
> credentials into the Lightning protocol. Admittedly I'm somewhat of a
> curious amateur in the field of reputation systems but a number of people
> (me included) have had to look into reputation systems in the past for
> projects/startups they were working on and *centralized* reputation
> systems are absolute minefields to manage effectively though some
> corporations do manage it. Decentralized reputation systems baked into a
> protocol is just a step too far. All you need is one edge case where the
> attacker can ensure an innocent party is blamed and the reputation system
> falls apart. The protocol developer is in the position of assessing who is
> telling the truth out of two opposing viewpoints on Reddit etc.
>
> I do think reputation systems will play a key part in a future Lightning
> Network (to some extent they already are with sites like 1ML and Amboss)
> but they won't be managed by protocol devs, they will be managed by
> multiple flavors of companies and projects (hopefully open source but most
> likely closed source too, for profit, non-profit etc) who are free to use
> whatever metrics and weigh those metrics however they like. The protocol
> just can't afford to expand into areas where there is case by case judgment
> and statistical analysis required. It will become bloated, ineffective and
> put protocol developers in the position of deciding who ultimately receives
> routing fees rather than just enabling payments can get from A to B.
> Identity is easier, you either control a private key or you don't.
> Reputation is much more difficult, there will be some attacks where a
> probabilistic assessment will need to be made on who the perpetrator of the
> attack was. You don't add that to the (already long) list of protocol
> developers' responsibilities.
>
> So feel free to continue to explore reputation and reputation systems but
> a strong warning that this is likely not solved at the protocol level.
> Decisions protocol developers make will impact what data can be collected
> and how easy that data is to collect (there are already some tricky
> trade-offs with regards to privacy, routing success and transparency for
> when things go wrong) but beyond that protocol developers should leave it
> to others. I've included some links to some additional reading on
> reputation systems in case you are interested.
>
> Thanks
> Michael
>
> [0]:
> https://www.amazon.com/Building-Reputation-Systems-Randy-Farmer/dp/059615979X/
> [1]:
> https://medium.com/openbazaarproject/decentralized-reputation-in-openbazaar-1a577fac5175
> [2]: https://www.bitrated.com/faq
>
> --
> Michael Folkson
> Email: michaelfolkson at protonmail.com
> Keybase: michaelfolkson
> PGP: 43ED C999 9F85 1D40 EAF4 9835 92D6 0159 214C FEE3
>
> ------- Original Message -------
> On Monday, November 21st, 2022 at 06:01, Antoine Riard <
> antoine.riard at gmail.com> wrote:
>
> Hi LN Devs,
>
> tl;dr A formalization of a reputation-based scheme to solve channel
> jamming is proposed. The system relies on "credentials" issued by routing
> hops and requested to be attached to each HTLC forward request. The
> "credentials" can be used by a reputation algorithm to reward/punish
> payment senders and allocate channel liquidity resources efficiently. The
> "credentials" initial distribution can be bootstrapped leveraging one-time
> upfront fees paid toward the routing hops. Afterwards, the "credentials"
> subsequent distribution can rely on previous HTLC traffic.
>
> A protocol description can be found here, with few extensions already to
> the BOLTs:
>
> https://github.com/lightning/bolts/pull/1043
>
> There is also a work-in-progress proof-of-concept in LDK (on top of our
> coming soon^TM HTLC intercepting API):
>
> https://github.com/lightningdevkit/rust-lightning/pull/1848
>
> This work builds on previous reputation-scheme research [0] [1]. It also
> integrates the more recent proposals of upfront fees as a straightforward
> mechanism to bootstrap the reputation system. Bootstrapping the system with
> more economically cost-effective privacy-preserving UTXO ownership proofs
> not only add another layer of engineering complexity, there is still a
> proof size vs proof generation/validation trade-off to arbiter between ZKP
> cryptosystems.
>
> Rather to seek for a game-theory equilibrium defined as a breakeven point
> as in the latest unconditional fee research [2], this proposal aims to use
> reputation credentials to allow HTLC traffic-shaping. This not only should
> protect against jamming situations (either malicious
> or spontaneous) but also allow active HTLC traffic-shaping, where a
> routing hop can allow extended channel liquidity lockups based on
> accumulated reputation (e.g for hold-invoices). This is also a reduced
> overhead cost, as upfront fees are only paid at bootstrap, or when the HTLC
> forward behavior can be qualified as "whitewashing" from the routing hop
> viewpoint.
>
> It should be noted, this current reputation-credential architectural
> framework assumes credentials distribution at the endpoint of the network.
> However, the framework should be flexible enough for the credentials to be
> harvested by the LSPs, and then distributed in a secondary fashion to their
> spokes, when they need it, or even attached transparently thanks to
> trampoline. So one design intuition, there is no strong attachment of the
> reputation to the endpoint HTLC sender, even if the protocol is described
> in a "flat" view for now.
>
> Let's evaluate quickly this mitigation proposal against a few criterias
> emerged from recent research.
>
> The mitigation is effective, in the sense a routing hop can apply a
> proportional relationship between the acquisition of the reputation and the
> amount of liquidity resources credited in function of said reputation. In a
> period of steady state, the reputation acquisition cost can be downgraded
> to 0. In periods of channel congestion, the reputation credentials to
> liquidity units translation can be severed, in the limit of routing hop
> acceptable competitiveness.
>
> The mitigation is incentive-compatible, if the credentials are not honored
> by their issuers, the HTLC senders can evict them from the routing network
> view for a while. The successful usage of credentials can lead to more
> credentials allocated for longer and more capacity-intensive channel
> lockups. In case of HTLC failure, the failure source could be forgiven by
> routing hops to maintain the worthiness of the sender credentials.
>
> The mitigation can be made transparent from the user, as the credentials
> harvesting can be done automatically from a pre-allocated budget, similar
> to the fee-bumping reserves requirement introduced by anchor output. At the
> end of today, if we take modern browsers as an example, the average user
> doesn't check manually the TLS certificates (for what they're worth...).
>
> The mitigation can conserve high-level privacy, as the usage of blinded
> signature (or another equivalent cryptosystem breaking signature/message
> linking) should allow the credentials issued during a preliminary phase to
> be undistinguishable during the redeem/usage phase. New CPU/memory DoS
> vectors due to the credentials processing should be watched out.
>
> About the ease of implementation, there are few protocol messages to
> modify, a HTLC intercepting API is assumed as supported by the
> implementation, onion messages support is also implied, landing EC blinded
> signature in libsecp256k1-zkp shouldn't be a big deal, routing algorithms
> adaptations might be more serious but still reasonable. The
> "credentials-to-liquidity" allocation algorithms are likely the new real
> beast, though I don't think any reputation scheme can spare them.
>
> There could be a concern about the centralization inertia introduced by a
> reputation system. Intuitively, the argument can be made that any
> historical tracking (such as routing buckets) favor established LN
> incumbents at the gain of efficiency. A counter-argument can be made, a new
> routing hop can lower the acquisition cost of its issued credentials to
> attract more HTLC traffic (accepting higher jamming risk).
>
> On the ecosystem impacts, it should be studied that this proposal would
> impact things like inbound channel routing fees [3], ratecard [4] or
> flow-control valve [5] and the whole liquidity toolchain. Hopefully, we
> don't significantly restrain the design space for future LN protocol
> upgrades.
>
> On the proposal modularity and flexibility, each routing node has
> oversight on its routing policy, acquisition methods, credentials to
> liquidity rate. New acquisition methods can be experimented or deployed
> when ready, e.g stakes certificates with only e2e upgrade. The credentials
> themselves could have "innate" expiration time if we use things like
> short-lived ZKP [6]. The credentials framework can be extended beyond
> solving jamming, as a generalized risk-management framework for Bitcoin
> decentralized financial network, e.g transaction signature exchange
> ordering in multi-party transactions [7] or finding reliable Coinjoin
> counterparties.
>
> Feedback welcome.
>
> Cheers,
> Antoine
>
> [0]
> https://lists.linuxfoundation.org/pipermail/lightning-dev/2020-November/002884.html
> [1]
> https://lists.linuxfoundation.org/pipermail/lightning-dev/2022-August/003673.html
> [2]
> https://lists.linuxfoundation.org/pipermail/lightning-dev/2022-November/003740.html
> [3]
> https://lists.linuxfoundation.org/pipermail/lightning-dev/2022-July/003643.html
> [4]
> https://lists.linuxfoundation.org/pipermail/lightning-dev/2022-September/003685.html
> [5]
> https://lists.linuxfoundation.org/pipermail/lightning-dev/2022-September/003686.html
> [6] https://eprint.iacr.org/2022/190.pdf
> [7] https://github.com/lightning/bolts/pull/851#issuecomment-1290727242
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20221128/31dea565/attachment-0001.html>;

📅 Original date posted:2022-11-25 📝 Original message: Hi ...

2023-06-09T15:07:25+02:00

In reply to nevent1q…535r
_________________________

📅 Original date posted:2022-11-25
📝 Original message:
Hi Clara,

The main benefit of this "staking"/reputational credentials is to save on
unconditional fees paid by HTLC senders. They benefit from their past HTLC
routing success in terms of more credentials allocated to them, and as such
minimize the overhead cost of their future HTLC sends, or allow them to
lock liquidity for longer periods. From a routing node viewpoint, a 0-risk
HTLC forwarding acceptance can be maintained by requesting strict binding
between credentials acquisition cost and channel liquidity routed. If
higher returns are seeked, the ratio credentials to liquidity can be
adjusted, of course coming with higher risks, and I think this is where the
model built for the current unconditional fees proposal could be useful (if
we integrate the channel congestion rate factor, I believe).

On top of this monetary paradigm, we can layer a "pure reputation" system,
where in function of the quality of the identities (e.g
proof-of-utxo-ownership), HTLC senders are allocated more significant
liquidity slots. Here, the real bottleneck is the cryptosystem, i.e proving
a UTXO ownership without revealing any other information. The rationale of
this "pure reputation" system, we could even save more in
upfront/unconditional fees in the steady state of the network (however such
a probabilistic model breaks hard in presence of attackers).

Best,
Antoine

Le jeu. 24 nov. 2022 à 09:45, Clara Shikhelman <clara.shikhelman at gmail.com>
a écrit :

> Hi Antoine,
>
> It sounds like unconditional fees cover most of what this policy does,
> without the extra risks that come from creating a new token. Is there a
> clear benefit to using a token compared to unconditional fees and
> local reputation?
>
> Best,
> Clara
>
> On Wed, Nov 23, 2022 at 9:48 PM Antoine Riard <antoine.riard at gmail.com>
> wrote:
>
>> Hi Clara,
>>
>> I think the simplest recommended policy you can devise is credential
>> shown to the routing hop should cover for full routing fees, therefore the
>> routing hop benefits from a zero-jamming risk situation. Then you can
>> appreciate the "liquidity value" credentials requested in function of your
>> local channel congestion rate, or even network data. Increasing your
>> returns in exchange of higher risk exposure. And even more, you can lay on
>> top a reputation layer, where the reputation scores are fully fungible
>> against monetary credentials, in the acceptance of a HTLC forward request.
>>
>> So I think I agree with you a recommended policy is needed, let's just
>> start with a simple one! And refine it with time once we sense we have
>> solid foundations.
>>
>> Best,
>> Antoine
>>
>>
>> Le mer. 23 nov. 2022 à 11:00, Clara Shikhelman <
>> clara.shikhelman at gmail.com> a écrit :
>>
>>> Hi Antoine,
>>>
>>> To discuss your proposed solution in detail, I think that some kind of
>>> recommended policy is needed. If presenting one is a low priority, and
>>> waiting for other things, my main concern is that it will just never happen
>>> ("any decade now" kind of situation).
>>>
>>> Best,
>>> Clara
>>>
>>> On Tue, Nov 22, 2022 at 8:13 PM Antoine Riard <antoine.riard at gmail.com>
>>> wrote:
>>>
>>>> Hi Clara,
>>>>
>>>> Shared the mail on #lightning-dev Libera chat to get more feedback on
>>>> schedule.
>>>>
>>>> > Do you have a timeline in mind for presenting such a policy?
>>>>
>>>> See the comments on the BOLT #1043 PR, for now I'm thinking more to
>>>> refine the proposed credentials architectural framework.
>>>> I think dynamic routing policy in function of channel congestion rate,
>>>> and you combine that with reputation to do active risk-management are far
>>>> more advanced questions.
>>>>
>>>> Best,
>>>> Antoine
>>>>
>>>> Le mar. 22 nov. 2022 à 15:54, Clara Shikhelman <
>>>> clara.shikhelman at gmail.com> a écrit :
>>>>
>>>>> Dear All,
>>>>>
>>>>> If the call time (Monday the 28th at 7 pm UTC) doesn't work out for
>>>>> you, please reach out!
>>>>>
>>>>> Thanks for your quick and detailed response, Antoine.
>>>>>
>>>>> If by recommend policy, you mean the set of algorithms that should
>>>>>> guide the token quantity, rate issuance, token acquisition cost, and the
>>>>>> adaptations in function of the local channel congestion, or even the
>>>>>> gossips of the other routing nodes, not at all.
>>>>>>
>>>>>
>>>>> Do you have a timeline in mind for presenting such a policy?
>>>>>
>>>>> Looking forward to discussing this further over the phone call, will
>>>>> make some inquiries to make sure the time works for most people.
>>>>>
>>>>> Best,
>>>>> Clara
>>>>>
>>>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20221124/e87d5d27/attachment-0001.html>;

📅 Original date posted:2022-11-22 📝 Original message: Hi ...

2023-06-09T15:07:24+02:00

In reply to nevent1q…epmx
_________________________

📅 Original date posted:2022-11-22
📝 Original message:
Hi Clara,

Shared the mail on #lightning-dev Libera chat to get more feedback on
schedule.

> Do you have a timeline in mind for presenting such a policy?

See the comments on the BOLT #1043 PR, for now I'm thinking more to refine
the proposed credentials architectural framework.
I think dynamic routing policy in function of channel congestion rate, and
you combine that with reputation to do active risk-management are far more
advanced questions.

Best,
Antoine

Le mar. 22 nov. 2022 à 15:54, Clara Shikhelman <clara.shikhelman at gmail.com>
a écrit :

> Dear All,
>
> If the call time (Monday the 28th at 7 pm UTC) doesn't work out for you,
> please reach out!
>
> Thanks for your quick and detailed response, Antoine.
>
> If by recommend policy, you mean the set of algorithms that should guide
>> the token quantity, rate issuance, token acquisition cost, and the
>> adaptations in function of the local channel congestion, or even the
>> gossips of the other routing nodes, not at all.
>>
>
> Do you have a timeline in mind for presenting such a policy?
>
> Looking forward to discussing this further over the phone call, will make
> some inquiries to make sure the time works for most people.
>
> Best,
> Clara
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20221122/11bab8b0/attachment.html>;

📅 Original date posted:2022-11-24 📝 Original message: Hi ...

2023-06-09T15:07:24+02:00

In reply to nevent1q…w3kq
_________________________

📅 Original date posted:2022-11-24
📝 Original message:
Hi Clara,

I think the simplest recommended policy you can devise is credential shown
to the routing hop should cover for full routing fees, therefore the
routing hop benefits from a zero-jamming risk situation. Then you can
appreciate the "liquidity value" credentials requested in function of your
local channel congestion rate, or even network data. Increasing your
returns in exchange of higher risk exposure. And even more, you can lay on
top a reputation layer, where the reputation scores are fully fungible
against monetary credentials, in the acceptance of a HTLC forward request.

So I think I agree with you a recommended policy is needed, let's just
start with a simple one! And refine it with time once we sense we have
solid foundations.

Best,
Antoine

Le mer. 23 nov. 2022 à 11:00, Clara Shikhelman <clara.shikhelman at gmail.com>
a écrit :

> Hi Antoine,
>
> To discuss your proposed solution in detail, I think that some kind of
> recommended policy is needed. If presenting one is a low priority, and
> waiting for other things, my main concern is that it will just never happen
> ("any decade now" kind of situation).
>
> Best,
> Clara
>
> On Tue, Nov 22, 2022 at 8:13 PM Antoine Riard <antoine.riard at gmail.com>
> wrote:
>
>> Hi Clara,
>>
>> Shared the mail on #lightning-dev Libera chat to get more feedback on
>> schedule.
>>
>> > Do you have a timeline in mind for presenting such a policy?
>>
>> See the comments on the BOLT #1043 PR, for now I'm thinking more to
>> refine the proposed credentials architectural framework.
>> I think dynamic routing policy in function of channel congestion rate,
>> and you combine that with reputation to do active risk-management are far
>> more advanced questions.
>>
>> Best,
>> Antoine
>>
>> Le mar. 22 nov. 2022 à 15:54, Clara Shikhelman <
>> clara.shikhelman at gmail.com> a écrit :
>>
>>> Dear All,
>>>
>>> If the call time (Monday the 28th at 7 pm UTC) doesn't work out for you,
>>> please reach out!
>>>
>>> Thanks for your quick and detailed response, Antoine.
>>>
>>> If by recommend policy, you mean the set of algorithms that should guide
>>>> the token quantity, rate issuance, token acquisition cost, and the
>>>> adaptations in function of the local channel congestion, or even the
>>>> gossips of the other routing nodes, not at all.
>>>>
>>>
>>> Do you have a timeline in mind for presenting such a policy?
>>>
>>> Looking forward to discussing this further over the phone call, will
>>> make some inquiries to make sure the time works for most people.
>>>
>>> Best,
>>> Clara
>>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20221123/4dfcbdf3/attachment.html>;

📅 Original date posted:2022-11-21 📝 Original message: Hi ...

2023-06-09T15:07:23+02:00

In reply to nevent1q…wz8q
_________________________

📅 Original date posted:2022-11-21
📝 Original message:
Hi Clara,

Thanks for reading!

> I think that another call to discuss jamming would be great. I would
> suggest making it a repeating call every 2 weeks, starting from Monday the
> 28th at 7 pm UTC.

Cool to take the initiative, the schedule works for me, however this slot
might conflict with the Core Lightning engineering call ? I remember we
moved the LDK meeting time from 7pm to 5pm, as we had folks willing to
attend both.

> 1. Are the tokens transferable between users? For example, if Ned is a
> routing node, and Alice has some of their tokens, can she give these
tokens
> to Bob?
> If yes - could this lead to the creation of a secondary market?
> If no - will that slow down the transaction flow that a new node can send?

Current version of the proposal, there is nothing preventing the tokens to
be transferred between the users, Alice can give these tokens to Bob. We
could make them binding to the prover, by requesting a new round where
Alice registers a pubkey towards Ned, and all tokens should be
counter-authenticated by Ned at forward. Ned would flag out the
double-usage of tokens, ideally in a ZKP-way. Still I think this would
never prevent Alice from sharing her key material with Bob. So I'm not sure
we can prevent a secondary-market, and it might be even more valuable if we
would like LSPs to collect tokens for their spokes nodes to simplify UX.

That said, beyond unlinkability between the blinded message and the
cleartext tokens/signatures, I think all the properties should be open to
more research.

> 2. Do you have a recommended policy for the creation of tokens and their
> use? Ideally, there will be a policy that would mitigate both slow and
> quick jamming, without harming usability too much.

If by recommend policy, you mean the set of algorithms that should guide
the token quantity, rate issuance, token acquisition cost, and the
adaptations in function of the local channel congestion, or even the
gossips of the other routing nodes, not at all. Just intuition, I think a
simple model should start from enforcing a proportionality between token
acquisition costs and the available channels liquidity, then you can add
more factors in function of your risk model.

About the slow/quick jamming distinction, I still believe a good
anti-jamming solution should aim to solve things in a continuous fashion,
rather than a discrete one. That way binds better to the reality of
differing hold time Lightning HTLC: simple payment, offline receive,
hold-invoice, swaps, etc...

> 3. You write "the reputation credentials to liquidity units translation
can
> be severed" - does this mean that the value of the token changes? Is that
> in the spirit of changing the fees in a channel?
> If this is the case, can't a routing node "trick" a user into buying many
> tokens and then bring the price up?

Yes, the "liquidity value" of the tokens is currently left as a floating
parameter. This is a good question if it should be fixed and only the
routing fees should fluctuate in function of channel congestion, or
floating e.g when the global quantity of tokens are required to re-dilute
their current values to maintain some proportion between acquisition cost
and available liquidity.

For sure, a routing node could "trick" a user into buying many tokens and
then break the promise of not only bringing the price up but also plainly
reject HTLC forward requests satisfying the announced routing policy.
Though note the user's routing algorithms could penalize in retorsion the
node, if the routing policy gossiped isn't respected.

> 4. How would these tokens work with blinded paths and other
> privacy-preserving suggestions?

Primarily, the tokens could use the new onion messages and blinded paths
for the dissemination and renewal rounds. Current design assumes they're
attached to the HTLC during forward along the payment path, though I think
one design alternative could be completely detached, and the HTLC onion
just contains a ref to the tokens.

Zooming out, after submitting this proposal to the mailing list yesterday,
I thought how much a token/credentials system bootstrapped on pre-paid fees
should be classified into monetary strategy or a reputation-based strategy,
and it turns out as there is an acquisition cost associated to the tokens,
in fact it might belong more to the monetary strategy classification. So I
wonder now if the usage of the reputation in the proposal title isn't
misleading and if a "breakeven point" isn't still implied ("the
proportionality" seeked). From a history of ideas standpoint, a
reputation-based strategy was more the Stakes Certificate solution
originally proposed in 2020. Though this proposal reuses the liquidity
units/credit score introduced there.

I think more and more we should have a "two-tier" mitigation strategy,
where the base tier is strictly defined in "pure fees" terms, and then
layered on top of a reputation system. A routing node could deviate from
the zero risk "pure fees" ones to increase its routing fees returns, by
relying more on assumptions like "Past HTLC senders behave well if there is
a proportionality between reputation cost and amount of liquidity resources
allocated in function of said-reputation".

Looking forward to pursuing discussions during calls!

Best,
Antoine

Le lun. 21 nov. 2022 à 13:16, Clara Shikhelman <clara.shikhelman at gmail.com>
a écrit :

> Dear Antoine and list,
>
> I think that another call to discuss jamming would be great. I would
> suggest making it a repeating call every 2 weeks, starting from Monday the
> 28th at 7 pm UTC.
>
> Antoine - Thank you for your work!
> I have a few questions to better understand the details.
>
> 1. Are the tokens transferable between users? For example, if Ned is a
> routing node, and Alice has some of their tokens, can she give these tokens
> to Bob?
> If yes - could this lead to the creation of a secondary market?
> If no - will that slow down the transaction flow that a new node can send?
>
> 2. Do you have a recommended policy for the creation of tokens and their
> use? Ideally, there will be a policy that would mitigate both slow and
> quick jamming, without harming usability too much.
>
> 3. You write "the reputation credentials to liquidity units translation
> can be severed" - does this mean that the value of the token changes? Is
> that in the spirit of changing the fees in a channel?
> If this is the case, can't a routing node "trick" a user into buying many
> tokens and then bring the price up?
>
> 4. How would these tokens work with blinded paths and other
> privacy-preserving suggestions?
>
> Thanks again,
> Clara
>
> On Sun, Nov 20, 2022 at 11:01 PM Antoine Riard <antoine.riard at gmail.com>
> wrote:
>
>> Hi LN Devs,
>>
>> tl;dr A formalization of a reputation-based scheme to solve channel
>> jamming is proposed. The system relies on "credentials" issued by routing
>> hops and requested to be attached to each HTLC forward request. The
>> "credentials" can be used by a reputation algorithm to reward/punish
>> payment senders and allocate channel liquidity resources efficiently. The
>> "credentials" initial distribution can be bootstrapped leveraging one-time
>> upfront fees paid toward the routing hops. Afterwards, the "credentials"
>> subsequent distribution can rely on previous HTLC traffic.
>>
>> A protocol description can be found here, with few extensions already to
>> the BOLTs:
>>
>> https://github.com/lightning/bolts/pull/1043
>>
>> There is also a work-in-progress proof-of-concept in LDK (on top of our
>> coming soon^TM HTLC intercepting API):
>>
>> https://github.com/lightningdevkit/rust-lightning/pull/1848
>>
>> This work builds on previous reputation-scheme research [0] [1]. It also
>> integrates the more recent proposals of upfront fees as a straightforward
>> mechanism to bootstrap the reputation system. Bootstrapping the system with
>> more economically cost-effective privacy-preserving UTXO ownership proofs
>> not only add another layer of engineering complexity, there is still a
>> proof size vs proof generation/validation trade-off to arbiter between ZKP
>> cryptosystems.
>>
>> Rather to seek for a game-theory equilibrium defined as a breakeven point
>> as in the latest unconditional fee research [2], this proposal aims to use
>> reputation credentials to allow HTLC traffic-shaping. This not only should
>> protect against jamming situations (either malicious
>> or spontaneous) but also allow active HTLC traffic-shaping, where a
>> routing hop can allow extended channel liquidity lockups based on
>> accumulated reputation (e.g for hold-invoices). This is also a reduced
>> overhead cost, as upfront fees are only paid at bootstrap, or when the HTLC
>> forward behavior can be qualified as "whitewashing" from the routing hop
>> viewpoint.
>>
>> It should be noted, this current reputation-credential architectural
>> framework assumes credentials distribution at the endpoint of the network.
>> However, the framework should be flexible enough for the credentials to be
>> harvested by the LSPs, and then distributed in a secondary fashion to their
>> spokes, when they need it, or even attached transparently thanks to
>> trampoline. So one design intuition, there is no strong attachment of the
>> reputation to the endpoint HTLC sender, even if the protocol is described
>> in a "flat" view for now.
>>
>> Let's evaluate quickly this mitigation proposal against a few criterias
>> emerged from recent research.
>>
>> The mitigation is effective, in the sense a routing hop can apply a
>> proportional relationship between the acquisition of the reputation and the
>> amount of liquidity resources credited in function of said reputation. In a
>> period of steady state, the reputation acquisition cost can be downgraded
>> to 0. In periods of channel congestion, the reputation credentials to
>> liquidity units translation can be severed, in the limit of routing hop
>> acceptable competitiveness.
>>
>> The mitigation is incentive-compatible, if the credentials are not
>> honored by their issuers, the HTLC senders can evict them from the routing
>> network view for a while. The successful usage of credentials can lead to
>> more credentials allocated for longer and more capacity-intensive channel
>> lockups. In case of HTLC failure, the failure source could be forgiven by
>> routing hops to maintain the worthiness of the sender credentials.
>>
>> The mitigation can be made transparent from the user, as the credentials
>> harvesting can be done automatically from a pre-allocated budget, similar
>> to the fee-bumping reserves requirement introduced by anchor output. At the
>> end of today, if we take modern browsers as an example, the average user
>> doesn't check manually the TLS certificates (for what they're worth...).
>>
>> The mitigation can conserve high-level privacy, as the usage of blinded
>> signature (or another equivalent cryptosystem breaking signature/message
>> linking) should allow the credentials issued during a preliminary phase to
>> be undistinguishable during the redeem/usage phase. New CPU/memory DoS
>> vectors due to the credentials processing should be watched out.
>>
>> About the ease of implementation, there are few protocol messages to
>> modify, a HTLC intercepting API is assumed as supported by the
>> implementation, onion messages support is also implied, landing EC blinded
>> signature in libsecp256k1-zkp shouldn't be a big deal, routing algorithms
>> adaptations might be more serious but still reasonable. The
>> "credentials-to-liquidity" allocation algorithms are likely the new real
>> beast, though I don't think any reputation scheme can spare them.
>>
>> There could be a concern about the centralization inertia introduced by a
>> reputation system. Intuitively, the argument can be made that any
>> historical tracking (such as routing buckets) favor established LN
>> incumbents at the gain of efficiency. A counter-argument can be made, a new
>> routing hop can lower the acquisition cost of its issued credentials to
>> attract more HTLC traffic (accepting higher jamming risk).
>>
>> On the ecosystem impacts, it should be studied that this proposal would
>> impact things like inbound channel routing fees [3], ratecard [4] or
>> flow-control valve [5] and the whole liquidity toolchain. Hopefully, we
>> don't significantly restrain the design space for future LN protocol
>> upgrades.
>>
>> On the proposal modularity and flexibility, each routing node has
>> oversight on its routing policy, acquisition methods, credentials to
>> liquidity rate. New acquisition methods can be experimented or deployed
>> when ready, e.g stakes certificates with only e2e upgrade. The credentials
>> themselves could have "innate" expiration time if we use things like
>> short-lived ZKP [6]. The credentials framework can be extended beyond
>> solving jamming, as a generalized risk-management framework for Bitcoin
>> decentralized financial network, e.g transaction signature exchange
>> ordering in multi-party transactions [7] or finding reliable Coinjoin
>> counterparties.
>>
>> Feedback welcome.
>>
>> Cheers,
>> Antoine
>>
>> [0]
>> https://lists.linuxfoundation.org/pipermail/lightning-dev/2020-November/002884.html
>> [1]
>> https://lists.linuxfoundation.org/pipermail/lightning-dev/2022-August/003673.html
>> [2]
>> https://lists.linuxfoundation.org/pipermail/lightning-dev/2022-November/003740.html
>> [3]
>> https://lists.linuxfoundation.org/pipermail/lightning-dev/2022-July/003643.html
>> [4]
>> https://lists.linuxfoundation.org/pipermail/lightning-dev/2022-September/003685.html
>> [5]
>> https://lists.linuxfoundation.org/pipermail/lightning-dev/2022-September/003686.html
>> [6] https://eprint.iacr.org/2022/190.pdf
>> [7] https://github.com/lightning/bolts/pull/851#issuecomment-1290727242
>> _______________________________________________
>> Lightning-dev mailing list
>> Lightning-dev at lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20221121/d1e83ac2/attachment-0001.html>;

📅 Original date posted:2022-11-21 📝 Original message: Hi LN ...

2023-06-09T15:07:22+02:00

In reply to nevent1q…luzn
_________________________

📅 Original date posted:2022-11-21
📝 Original message:
Hi LN Devs,

tl;dr A formalization of a reputation-based scheme to solve channel jamming
is proposed. The system relies on "credentials" issued by routing hops and
requested to be attached to each HTLC forward request. The "credentials"
can be used by a reputation algorithm to reward/punish payment senders and
allocate channel liquidity resources efficiently. The "credentials"
initial distribution can be bootstrapped leveraging one-time upfront fees
paid toward the routing hops. Afterwards, the "credentials" subsequent
distribution can rely on previous HTLC traffic.

A protocol description can be found here, with few extensions already to
the BOLTs:

https://github.com/lightning/bolts/pull/1043

There is also a work-in-progress proof-of-concept in LDK (on top of our
coming soon^TM HTLC intercepting API):

https://github.com/lightningdevkit/rust-lightning/pull/1848

This work builds on previous reputation-scheme research [0] [1]. It also
integrates the more recent proposals of upfront fees as a straightforward
mechanism to bootstrap the reputation system. Bootstrapping the system with
more economically cost-effective privacy-preserving UTXO ownership proofs
not only add another layer of engineering complexity, there is still a
proof size vs proof generation/validation trade-off to arbiter between ZKP
cryptosystems.

Rather to seek for a game-theory equilibrium defined as a breakeven point
as in the latest unconditional fee research [2], this proposal aims to use
reputation credentials to allow HTLC traffic-shaping. This not only should
protect against jamming situations (either malicious
or spontaneous) but also allow active HTLC traffic-shaping, where a routing
hop can allow extended channel liquidity lockups based on accumulated
reputation (e.g for hold-invoices). This is also a reduced overhead cost,
as upfront fees are only paid at bootstrap, or when the HTLC forward
behavior can be qualified as "whitewashing" from the routing hop viewpoint.

It should be noted, this current reputation-credential architectural
framework assumes credentials distribution at the endpoint of the network.
However, the framework should be flexible enough for the credentials to be
harvested by the LSPs, and then distributed in a secondary fashion to their
spokes, when they need it, or even attached transparently thanks to
trampoline. So one design intuition, there is no strong attachment of the
reputation to the endpoint HTLC sender, even if the protocol is described
in a "flat" view for now.

Let's evaluate quickly this mitigation proposal against a few criterias
emerged from recent research.

The mitigation is effective, in the sense a routing hop can apply a
proportional relationship between the acquisition of the reputation and the
amount of liquidity resources credited in function of said reputation. In a
period of steady state, the reputation acquisition cost can be downgraded
to 0. In periods of channel congestion, the reputation credentials to
liquidity units translation can be severed, in the limit of routing hop
acceptable competitiveness.

The mitigation is incentive-compatible, if the credentials are not honored
by their issuers, the HTLC senders can evict them from the routing network
view for a while. The successful usage of credentials can lead to more
credentials allocated for longer and more capacity-intensive channel
lockups. In case of HTLC failure, the failure source could be forgiven by
routing hops to maintain the worthiness of the sender credentials.

The mitigation can be made transparent from the user, as the credentials
harvesting can be done automatically from a pre-allocated budget, similar
to the fee-bumping reserves requirement introduced by anchor output. At the
end of today, if we take modern browsers as an example, the average user
doesn't check manually the TLS certificates (for what they're worth...).

The mitigation can conserve high-level privacy, as the usage of blinded
signature (or another equivalent cryptosystem breaking signature/message
linking) should allow the credentials issued during a preliminary phase to
be undistinguishable during the redeem/usage phase. New CPU/memory DoS
vectors due to the credentials processing should be watched out.

About the ease of implementation, there are few protocol messages to
modify, a HTLC intercepting API is assumed as supported by the
implementation, onion messages support is also implied, landing EC blinded
signature in libsecp256k1-zkp shouldn't be a big deal, routing algorithms
adaptations might be more serious but still reasonable. The
"credentials-to-liquidity" allocation algorithms are likely the new real
beast, though I don't think any reputation scheme can spare them.

There could be a concern about the centralization inertia introduced by a
reputation system. Intuitively, the argument can be made that any
historical tracking (such as routing buckets) favor established LN
incumbents at the gain of efficiency. A counter-argument can be made, a new
routing hop can lower the acquisition cost of its issued credentials to
attract more HTLC traffic (accepting higher jamming risk).

On the ecosystem impacts, it should be studied that this proposal would
impact things like inbound channel routing fees [3], ratecard [4] or
flow-control valve [5] and the whole liquidity toolchain. Hopefully, we
don't significantly restrain the design space for future LN protocol
upgrades.

On the proposal modularity and flexibility, each routing node has oversight
on its routing policy, acquisition methods, credentials to liquidity rate.
New acquisition methods can be experimented or deployed when ready, e.g
stakes certificates with only e2e upgrade. The credentials themselves could
have "innate" expiration time if we use things like short-lived ZKP [6].
The credentials framework can be extended beyond solving jamming, as a
generalized risk-management framework for Bitcoin decentralized financial
network, e.g transaction signature exchange ordering in multi-party
transactions [7] or finding reliable Coinjoin counterparties.

Feedback welcome.

Cheers,
Antoine

[0]
https://lists.linuxfoundation.org/pipermail/lightning-dev/2020-November/002884.html
[1]
https://lists.linuxfoundation.org/pipermail/lightning-dev/2022-August/003673.html
[2]
https://lists.linuxfoundation.org/pipermail/lightning-dev/2022-November/003740.html
[3]
https://lists.linuxfoundation.org/pipermail/lightning-dev/2022-July/003643.html
[4]
https://lists.linuxfoundation.org/pipermail/lightning-dev/2022-September/003685.html
[5]
https://lists.linuxfoundation.org/pipermail/lightning-dev/2022-September/003686.html
[6] https://eprint.iacr.org/2022/190.pdf
[7] https://github.com/lightning/bolts/pull/851#issuecomment-1290727242
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20221120/2a736ba2/attachment.html>;

📅 Original date posted:2022-09-01 📝 Original message: Hi ...

2023-06-09T15:06:46+02:00

In reply to nevent1q…wgx3
_________________________

📅 Original date posted:2022-09-01
📝 Original message:
Hi Alex,

Let's say the adversary targeting your high-value "LiFi" infrastructure is
a nation-state sponsored hacking-group with strong capabilities (as we're
seeing today in the cryptocurrencies DeFi space). This hacking group avails
hundreds of bitcoins to fund channels, is able to setup thousands of sybil
peers across the base-layer p2p network, has built a fine-grained knowledge
of the miner mempools, controls few Internet ASNs and has bought
second-hands mining chips on the market to own limited hashing capabilities.

As of today, they would have a marked embarrassment on which attack pickup
to target your Lightning infrastructure. They could start with an "old
known" jamming attack to permanently cut your channel links from the rest
of the wider network topology [0].
Or they could launch time-dilation attacks by building on BGP disruptions,
until your chain view is so far in the past from the network tip that your
on-chain HTLC-claiming safety reaction timers are useless [1]. Or they
could exercise pinning attacks to prevent you to claim back routed HTLC, as
a malicious commitment transaction sleeps in the network mempools until
it's too far [2]. Or they could target your pre-0.24 Bitcoin Core
full-node to provoke a memory crash thanks to a long-chain of low-work
headers [3].

And I would say that's only a subset of the attack surface of a Lightning
node.

Considering all those factors, moving a LN implementation architecture from
a single, monolithic process towards a collection of processes, where the
critical components of the LN active defense security model are replicated
and distributed, redundant access to the chain view guaranteed, sandboxing
access between processes enforced and data flow monitored to react on
anomalies, all things your #6843 would make easier, sounds a reasonable
direction. I think it's needed if you aim for your infrastructure to
survive strong attacks.

On the LDK-side, inheriting from the adversarial thinking and safety-first
mindset development culture from Bitcoin Core, we've always considered that
type of scenarii since the early days and designed our software in
consequence. We have been working and we'll keep working on many
security/safety hardening: external signing [4], replicated chain
monitoring [5], dynamic fee-bumping of time-sensitive transactions, various
attack vectors mitigations [6]. All that said, we're looking forward to
collaborate with the wider Lightning community on reusable security modules
across implementations (e.g jamming mitigations) and wished
"fix-the-annoying-holes" changes in Bitcoin Core (e.g package relay).

Cheers,
Antoine

[0] https://jamming-dev.github.io/book/
[1] https://arxiv.org/abs/2006.01418
[2]
https://lists.linuxfoundation.org/pipermail/lightning-dev/2020-June/002758.html
[3] https://github.com/bitcoin/bitcoin/pull/25717
[4] https://github.com/lightningdevkit/rust-lightning/pull/214
[5] https://github.com/lightningdevkit/rust-lightning/pull/679
[6] https://github.com/lightningdevkit/rust-lightning/pull/1009

Le jeu. 1 sept. 2022 à 13:56, Alex Akselrod via Lightning-dev <
lightning-dev at lists.linuxfoundation.org> a écrit :

> At NYDIG, we're considering ways to harden large LND deployments. Joost
> and I discussed that currently, when external untrusted peers make inbound
> connections, LND must verify the identity of the peer during the noise
> handshake, and it must do this before enforcing any potential key-based
> allow lists. This is done in the same process as the node's other critical
> tasks, such as monitoring the chain.
>
> To reduce the attack area of the main node process, we'd like to propose a
> means to optionally separate the peer communication into a separate
> process: something like CLN's connectd, running separately, and the
> connections would be multiplexed over a single network connection initiated
> from the node to the proxy. The core of our current idea is demonstrated in
> a draft PR: https://github.com/lightningnetwork/lnd/pull/6843
>
> I'd love some early feedback on the general direction of this. If this
> would be interesting, I'll build it out into a fully working feature.
>
> Thanks,
>
> Alex Akselrod
> _______________________________________________
> Lightning-dev mailing list
> Lightning-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20220901/d81ca8c8/attachment-0001.html>;

📅 Original date posted:2021-10-04 📝 Original message: > ...

2023-06-09T15:04:00+02:00

In reply to nevent1q…du5g
_________________________

📅 Original date posted:2021-10-04
📝 Original message:
> * C-lightning v0.10.2 (CVE-2021-41593)

Thanks I was unsure about the exact version number. I'll update the CVE
quickly.

Le lun. 4 oct. 2021 à 14:16, lisa neigut <niftynei at gmail.com> a écrit :

> FYI the next version of c-lightning will contain the proposed
> `max_dust_htlc_exposure_msat` as outlined in #919
> <https://github.com/lightningnetwork/lightning-rfc/pull/919/files>;; the
> given expected vulnerabilities patch table should have reflected this.
>
> > The vulnerabilities are expected to be patched in:
> > * Eclair: v0.6.2+ (CVE-2021-41591)
> > * LND: v0.13.3+ (CVE-2021-41592)
> > * LDK: v0.0.102 (not released as production software yet)
>
> * C-lightning v0.10.2 (CVE-2021-41593)
>
>
> Lisa
>
> On Mon, Oct 4, 2021 at 10:09 AM Antoine Riard <antoine.riard at gmail.com>
> wrote:
>
>> Hi,
>>
>> I'm writing a report to disclose specification-level vulnerabilities
>> affecting the Lightning implementations.
>>
>> The vulnerabilities are expected to be patched in:
>> * Eclair: v0.6.2+ (CVE-2021-41591)
>> * LND: v0.13.3+ (CVE-2021-41592)
>> * LDK: v0.0.102 (not released as production software yet)
>>
>> The vulnerabilities are also affecting c-lightning (CVE-2021-41593).
>>
>> Those vulnerabilities can be exploited in a wide range of attacks, going
>> from fee blackmailing of node operators, burning liquidity of your
>> competing LSPs or even stealing your counterparty channel balance if you
>> avail mining capabilities. Exercise of the vulnerability revealed that a
>> majority of the balance funds can be at loss.
>>
>> Credit to Eugene Siegel (Crypt-iQ) for reporting the trimmed-to-dust
>> exploitation and multiple insights about attacks.
>>
>> Thanks to Bastien Teinturier and Matt Corallo for numerous contributions
>> about mitigations development.
>>
>> # Problem
>>
>> The current BOLT specification only requires Alice's
>> `dust_limit_satoshis` (applied on Alice's commitment) to be under Alice's
>> `channel_reserve_satoshis` (applied on Bob). As those 2 parameters are
>> selectable by Alice, she can inflate the dust limit until reaching the
>> implementation-defined max value (e.g LND: 20% of chan capacity, LDK: 100%
>> of chan capacity).
>>
>> Any in-flight incoming HTLC under Alice's dust limit will be converted as
>> miner fees on Alice's commitment. This HTLC is deducted from Bob's balance
>> and as such they're still owned by Bob, until resolution (i.e a RAA
>> removing the HTLC from Alice's commitment). This limitation only applies
>> per-HTLC. No implementation enforces a limit on the sum of in-flight HTLCs
>> burned as fees. Therefore, Alice is free to inflict a substantial loss to
>> Bob funds by publishing her commitment on-chain.
>>
>> In-flight outgoing HTLC are also committed as fees on Bob's commitment if
>> they're under Bob's threshold. Alice can also exploit from this angle by
>> circular routing HTLCs until reaching Bob's
>> `max_htlc_value_in_flight_msat`. Alice withholds HTLCs resolution until Bob
>> goes on-chain to timeout an offered HTLC or claim an accepted HTLC.
>>
>> Dust HTLC processing can be also exploited at `update_fee` reception.
>>
>> As the BOLT3's fees computation encompasses the negotiated feerate from
>> `update_fee` for the 2nd-stage HTLC fees to decide if the HTLC must be
>> trimmed, the amount of balance at risk is a function of current mempool
>> feerates.
>>
>> The maximum of funds at risk on a counterparty commitment is:
>>
>> counterparty's `max_accepted_htlcs` * (`htlc_success_tx_kw` * opener's
>> `feerate_per_kw` + counterparty's `dust_limit_satoshis`) + holder's
>> `max_accepted_htlcs` * (`htlc_timeout_tx_kw` * opener's `feerate_per_kw` +
>> counterparty's `dust_limit_satoshis`)
>>
>> If the opener is also the attacker, the negotiated feerate can be
>> manipulated beyond the "honest" mempool feerates only upper bounded
>> implementation-defined value (before fixes, LDK: 2 * high-feerate of our
>> fee-estimator). If the opener is the victim, the negotiated feerate is
>> still a safety concern in case of spontaneous mempool spikes.
>>
>> Note, `anchors_zero_htlc_fee` channels are not affected by the feerate
>> inflation as the trimmed-to-dust fee computation mechanism for 2nd-stage
>> HTLC is removed. They're still at risk of the sum of the HTLCs under the
>> dust limit being maliciously burned.
>>
>> # Solution
>>
>> A first mitigation is to verify the counterparty's announced
>> `dust_limit_satoshis` at channel opening (`open_channel`/`accept_channel`)
>> reception and reject if it's estimated too large (see #894)
>>
>> For LDK, we choose the value of 660 satoshis as it's beyond the highest
>> dust threshold enforced by Bitcoin Core (p2pkh: 546) with a margin of
>> safety. Propagation of Lightning time-sensitive transactions shouldn't be
>> affected.
>>
>> A second mitigation is to define a new configurable limit
>> `max_dust_htlc_exposure` and apply this one at incoming and outgoing of
>> HTLC.
>>
>> For LDK, we choose the value of 5 000 000 milli-satoshis as we gauged
>> this value as a substantial loss for our class of users. Setting this too
>> low may prevent the sending or receipt of low-value HTLCs on high-traffic
>> nodes. A node operator should fine-tune this value in function of what
>> qualifies as an acceptable loss.
>>
>> We would like to ensure that the node isn't suddenly exposed to
>> significantly more trimmed balance if the feerate increases when we have
>> several HTLCs pending which are near the dust limit.
>>
>> To achieve this goal, we introduce a new `dust_buffer_feerate` defined as
>> the maximum of either 2530 sats per kWU or 125% of the current
>> `feerate_per_kw` (implementation-defined values).
>>
>> Then, upon an incoming HTLC, if the HTLC's `amount_msat` is inferior to
>> the counterparty's `dust_limit_satoshis` plus the HTLC-timeout fee at the
>> `dust_buffer_feerate`. If the `amount_msat` plus the
>> `dust_balance_on_counterparty_tx` is superior to `max_dust_htlc_exposure`,
>> the HTLC should be failed once it's committed.
>>
>> Upon an outgoing HTLC, if the HTLC's `amount_msat` is inferior to the
>> counterparty's `dust_limit_satoshis` plus the HTLC-success fee at the
>> `dust_buffer_feerate`. If the `amount_msat` plus the
>> `dust_balance_on_counterparty_tx` is superior to `max_dust_htlc_exposure`,
>> the HTLC should not be sent and fail without forwarding.
>>
>> The check symmetry must also be applied on holder commitment
>> transactions. See PR #919 for more details.
>>
>> A last mitigation is ensuring that at `update_fee` reception, the pending
>> `dust_balance` at the new proposed feerate isn't superior to
>> `max_dust_htlc_exposure_msat`.
>>
>> # Background
>>
>> The dust limit is a base layer policy stopping the relay of a transaction
>> if one of its outputs is under a given threshold. The goal of this policy
>> is to prevent the pollution of the UTXO set with low-value outputs and as
>> such increase the amount of work done by full-nodes.
>>
>> Lightning commitment transactions should be able to propagate at any
>> point during the channel lifetime to unilaterally enforce on-chain a
>> balance. A Lightning commitment transaction with one of its outputs below
>> the dust limit would fail to relay and thus jeopardizes funds safety.
>>
>> To prevent this, BOLT2 requires counterparties to announce a
>> `dust_limit_satoshis` during channel opening (at
>> `open_channel`/`accept_channel` exchange). This `dust_limit_satoshis` must
>> be under the same party's `channel_reserve_satoshis`. This value is static
>> for the channel lifetime.
>>
>> During commitment signatures exchange, each counterparty's limit is
>> applied on each counterparty's commitment (e.g A's `dust_limit_satoshis` is
>> applied on A's commitment, though both A and B have to generate and sign
>> the transaction). An output below this limit is trimmed to fees and won't
>> materialize on the commitment.
>>
>> The specification didn't require that the `open_channel`/`accept_channel`
>> receiver verify that the announced `dust_limit_satoshis` isn't too large.
>>
>> The specification didn't require that the sum of the dust HTLC committed
>> as fees was verified against an upper bound.
>>
>> # Discovery
>>
>> Vulnerabilities around our dust HTLC processing have been known for years
>> by some LN developers/researchers.
>>
>> During Q1 2019, private discussions on the Rust-Lightning-side (LDK
>> before marketing rebranding) about potential safety risks around dust HTLC
>> processing.
>>
>> In November 2019, Rusty Russell (c-lightning) opened an issue against the
>> specification mentioning the lack of check of counterparty's dust limit
>> (#696).
>>
>> In May 2020, I published a high-level attack scenario "Miners Dust
>> Inflation attacks on Lightning Network", leveraging this lack.
>>
>> In February 2021, I did a test of the first vulnerability against LND
>> software and successfully burnt the majority of the targeted node balance
>> in fees. As it sounds to me like a check missing in the specification, I
>> notified CL/LND/Eclair/LDK maintainers. Mitigations started to be developed
>> on the LDK-side.
>>
>> In July 2021, in the context of `option_dusty_htlcs_uncounted`
>> discussions, Eugene Spiegel (LND) reported on how to exploit the
>> trimmed-to-dust mechanism at `update_fee` reception. Discussions followed
>> on the best way to mitigate this new vector.
>>
>> During August 2021, mitigations were developed and released on the
>> LDK-side. vulnerabilities were disclosed to other Lightning projects (Muun
>> wallet, Electrum). From the LDK-side, a public disclosure date was proposed.
>>
>> Still during August 2021, the Bitcoin Core dust limit was actively
>> discussed on the mailing list. Changes of this dust limit would have
>> affected the ongoing development of the mitigations.
>>
>> While this report highlights the lack of well-defined communication
>> process across Lightning teams, developers from 3 different
>> implementations have actively participated in the vulnerabilities
>> diagnostic and mitigations development of those long-standing specification
>> issues affecting the whole Lightning ecosystem.
>>
>> All mistakes and opinions are my own and please verify any information
>> reported.
>>
>> # Timeline
>>
>> * 2021-04-19: Working exploit of the vulnerability against LND,
>> CL/LND/Eclair/LDK maintainers notified
>> * 2021-07-21: Finding by Eugene Siegel on how to exploit the
>> trimmed-to-dust mechanism at `update_fee` reception
>> * 2021-08-11: BOLT PR #894 opened by Bastien Teinturier, covering the
>> lack of verification of counterparty per-HTLC `dust_limit_satoshis`
>> * 2021-08-16: Mitigations developed in LDK, communication of a public
>> disclosure date
>> * 2021-08-26: Notification to Muun wallet, non-affected
>> * 2021-08-27: Notification to Electrum wallet
>> * 2021-10-04: Full Disclosure of CVEs
>> * 2021-10-04: Submit BOLT PR #919 covering the remaining vulnerabilities
>> _______________________________________________
>> Lightning-dev mailing list
>> Lightning-dev at lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20211004/7a56a20b/attachment-0001.html>;

📅 Original date posted:2021-10-04 📝 Original message: > ...

2023-06-09T15:03:59+02:00

In reply to nevent1q…359g
_________________________

📅 Original date posted:2021-10-04
📝 Original message:
> In other words, simply not secured.

How do you define Bitcoin base-layer security ? How strong are the
assumptions we're relying on the base-layer ?
Not easy answers :/

> L2s shouldn't build on flawed assumptions.

Waiting for your proposal to scale Bitcoin payments relying on pure
consensus assumptions :)

> No thanks. Not sure that would even help (since policies can always be
set to
a higher dust limit than any consensus rule)

Sure. Policies can always be more restrictive. One of them could be to not
relay transactions at all. If widely-deployed, such policy would make the
network quite unusable....

More seriously, I think when we consider this policy discussion, we should
have more in mind the consequences of adopting a given policy or another
one.
As long as they're economically-compatible, they should be followed by an
economically rational node operator.
I think we're already making that kind of social or economic assumption on
the user behavior w.r.t to full-node design. Blocks and transactions are
relayed for "free" today, not satoshis are received in exchange.

Le lun. 4 oct. 2021 à 12:28, Luke Dashjr <luke at dashjr.org> a écrit :

> On Monday 04 October 2021 16:14:20 Antoine Riard wrote:
> > > The "dust limit" is arbitrarily decided by each node, and cannot be
> > > relied upon for security at all. Expecting it to be a given default
> value
> > > is in itself a security vulnerability
> >
> > Reality is that an increasing number of funds are secured by assumptions
> > around mempool behavior.
>
> In other words, simply not secured.
>
> > And sadly that's going to increase with Lightning growth and deployment
> of
> > other L2s.
>
> L2s shouldn't build on flawed assumptions.
>
> > Maybe we could dry-up some policy rules in consensus like the dust limit
> > one :)
>
> No thanks. Not sure that would even help (since policies can always be set
> to
> a higher dust limit than any consensus rule)
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20211004/30471001/attachment.html>;

📅 Original date posted:2021-10-04 📝 Original message: Hi, ...

2023-06-09T15:03:57+02:00

In reply to nevent1q…7hv7
_________________________

📅 Original date posted:2021-10-04
📝 Original message:
Hi,

I'm writing a report to disclose specification-level vulnerabilities
affecting the Lightning implementations.

The vulnerabilities are expected to be patched in:
* Eclair: v0.6.2+ (CVE-2021-41591)
* LND: v0.13.3+ (CVE-2021-41592)
* LDK: v0.0.102 (not released as production software yet)

The vulnerabilities are also affecting c-lightning (CVE-2021-41593).

Those vulnerabilities can be exploited in a wide range of attacks, going
from fee blackmailing of node operators, burning liquidity of your
competing LSPs or even stealing your counterparty channel balance if you
avail mining capabilities. Exercise of the vulnerability revealed that a
majority of the balance funds can be at loss.

Credit to Eugene Siegel (Crypt-iQ) for reporting the trimmed-to-dust
exploitation and multiple insights about attacks.

Thanks to Bastien Teinturier and Matt Corallo for numerous contributions
about mitigations development.

# Problem

The current BOLT specification only requires Alice's `dust_limit_satoshis`
(applied on Alice's commitment) to be under Alice's
`channel_reserve_satoshis` (applied on Bob). As those 2 parameters are
selectable by Alice, she can inflate the dust limit until reaching the
implementation-defined max value (e.g LND: 20% of chan capacity, LDK: 100%
of chan capacity).

Any in-flight incoming HTLC under Alice's dust limit will be converted as
miner fees on Alice's commitment. This HTLC is deducted from Bob's balance
and as such they're still owned by Bob, until resolution (i.e a RAA
removing the HTLC from Alice's commitment). This limitation only applies
per-HTLC. No implementation enforces a limit on the sum of in-flight HTLCs
burned as fees. Therefore, Alice is free to inflict a substantial loss to
Bob funds by publishing her commitment on-chain.

In-flight outgoing HTLC are also committed as fees on Bob's commitment if
they're under Bob's threshold. Alice can also exploit from this angle by
circular routing HTLCs until reaching Bob's
`max_htlc_value_in_flight_msat`. Alice withholds HTLCs resolution until Bob
goes on-chain to timeout an offered HTLC or claim an accepted HTLC.

Dust HTLC processing can be also exploited at `update_fee` reception.

As the BOLT3's fees computation encompasses the negotiated feerate from
`update_fee` for the 2nd-stage HTLC fees to decide if the HTLC must be
trimmed, the amount of balance at risk is a function of current mempool
feerates.

The maximum of funds at risk on a counterparty commitment is:

counterparty's `max_accepted_htlcs` * (`htlc_success_tx_kw` * opener's
`feerate_per_kw` + counterparty's `dust_limit_satoshis`) + holder's
`max_accepted_htlcs` * (`htlc_timeout_tx_kw` * opener's `feerate_per_kw` +
counterparty's `dust_limit_satoshis`)

If the opener is also the attacker, the negotiated feerate can be
manipulated beyond the "honest" mempool feerates only upper bounded
implementation-defined value (before fixes, LDK: 2 * high-feerate of our
fee-estimator). If the opener is the victim, the negotiated feerate is
still a safety concern in case of spontaneous mempool spikes.

Note, `anchors_zero_htlc_fee` channels are not affected by the feerate
inflation as the trimmed-to-dust fee computation mechanism for 2nd-stage
HTLC is removed. They're still at risk of the sum of the HTLCs under the
dust limit being maliciously burned.

# Solution

A first mitigation is to verify the counterparty's announced
`dust_limit_satoshis` at channel opening (`open_channel`/`accept_channel`)
reception and reject if it's estimated too large (see #894)

For LDK, we choose the value of 660 satoshis as it's beyond the highest
dust threshold enforced by Bitcoin Core (p2pkh: 546) with a margin of
safety. Propagation of Lightning time-sensitive transactions shouldn't be
affected.

A second mitigation is to define a new configurable limit
`max_dust_htlc_exposure` and apply this one at incoming and outgoing of
HTLC.

For LDK, we choose the value of 5 000 000 milli-satoshis as we gauged this
value as a substantial loss for our class of users. Setting this too low
may prevent the sending or receipt of low-value HTLCs on high-traffic
nodes. A node operator should fine-tune this value in function of what
qualifies as an acceptable loss.

We would like to ensure that the node isn't suddenly exposed to
significantly more trimmed balance if the feerate increases when we have
several HTLCs pending which are near the dust limit.

To achieve this goal, we introduce a new `dust_buffer_feerate` defined as
the maximum of either 2530 sats per kWU or 125% of the current
`feerate_per_kw` (implementation-defined values).

Then, upon an incoming HTLC, if the HTLC's `amount_msat` is inferior to the
counterparty's `dust_limit_satoshis` plus the HTLC-timeout fee at the
`dust_buffer_feerate`. If the `amount_msat` plus the
`dust_balance_on_counterparty_tx` is superior to `max_dust_htlc_exposure`,
the HTLC should be failed once it's committed.

Upon an outgoing HTLC, if the HTLC's `amount_msat` is inferior to the
counterparty's `dust_limit_satoshis` plus the HTLC-success fee at the
`dust_buffer_feerate`. If the `amount_msat` plus the
`dust_balance_on_counterparty_tx` is superior to `max_dust_htlc_exposure`,
the HTLC should not be sent and fail without forwarding.

The check symmetry must also be applied on holder commitment transactions.
See PR #919 for more details.

A last mitigation is ensuring that at `update_fee` reception, the pending
`dust_balance` at the new proposed feerate isn't superior to
`max_dust_htlc_exposure_msat`.

# Background

The dust limit is a base layer policy stopping the relay of a transaction
if one of its outputs is under a given threshold. The goal of this policy
is to prevent the pollution of the UTXO set with low-value outputs and as
such increase the amount of work done by full-nodes.

Lightning commitment transactions should be able to propagate at any point
during the channel lifetime to unilaterally enforce on-chain a balance. A
Lightning commitment transaction with one of its outputs below the dust
limit would fail to relay and thus jeopardizes funds safety.

To prevent this, BOLT2 requires counterparties to announce a
`dust_limit_satoshis` during channel opening (at
`open_channel`/`accept_channel` exchange). This `dust_limit_satoshis` must
be under the same party's `channel_reserve_satoshis`. This value is static
for the channel lifetime.

During commitment signatures exchange, each counterparty's limit is applied
on each counterparty's commitment (e.g A's `dust_limit_satoshis` is applied
on A's commitment, though both A and B have to generate and sign the
transaction). An output below this limit is trimmed to fees and won't
materialize on the commitment.

The specification didn't require that the `open_channel`/`accept_channel`
receiver verify that the announced `dust_limit_satoshis` isn't too large.

The specification didn't require that the sum of the dust HTLC committed as
fees was verified against an upper bound.

# Discovery

Vulnerabilities around our dust HTLC processing have been known for years
by some LN developers/researchers.

During Q1 2019, private discussions on the Rust-Lightning-side (LDK before
marketing rebranding) about potential safety risks around dust HTLC
processing.

In November 2019, Rusty Russell (c-lightning) opened an issue against the
specification mentioning the lack of check of counterparty's dust limit
(#696).

In May 2020, I published a high-level attack scenario "Miners Dust
Inflation attacks on Lightning Network", leveraging this lack.

In February 2021, I did a test of the first vulnerability against LND
software and successfully burnt the majority of the targeted node balance
in fees. As it sounds to me like a check missing in the specification, I
notified CL/LND/Eclair/LDK maintainers. Mitigations started to be developed
on the LDK-side.

In July 2021, in the context of `option_dusty_htlcs_uncounted` discussions,
Eugene Spiegel (LND) reported on how to exploit the trimmed-to-dust
mechanism at `update_fee` reception. Discussions followed on the best way
to mitigate this new vector.

During August 2021, mitigations were developed and released on the
LDK-side. vulnerabilities were disclosed to other Lightning projects (Muun
wallet, Electrum). From the LDK-side, a public disclosure date was proposed.

Still during August 2021, the Bitcoin Core dust limit was actively
discussed on the mailing list. Changes of this dust limit would have
affected the ongoing development of the mitigations.

While this report highlights the lack of well-defined communication process
across Lightning teams, developers from 3 different implementations have
actively participated in the vulnerabilities diagnostic and mitigations
development of those long-standing specification issues affecting the whole
Lightning ecosystem.

All mistakes and opinions are my own and please verify any information
reported.

# Timeline

* 2021-04-19: Working exploit of the vulnerability against LND,
CL/LND/Eclair/LDK maintainers notified
* 2021-07-21: Finding by Eugene Siegel on how to exploit the
trimmed-to-dust mechanism at `update_fee` reception
* 2021-08-11: BOLT PR #894 opened by Bastien Teinturier, covering the lack
of verification of counterparty per-HTLC `dust_limit_satoshis`
* 2021-08-16: Mitigations developed in LDK, communication of a public
disclosure date
* 2021-08-26: Notification to Muun wallet, non-affected
* 2021-08-27: Notification to Electrum wallet
* 2021-10-04: Full Disclosure of CVEs
* 2021-10-04: Submit BOLT PR #919 covering the remaining vulnerabilities
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20211004/9af032f2/attachment.html>;

📅 Original date posted:2021-04-23 📝 Original message: Hi ...

2023-06-09T15:02:21+02:00

In reply to nevent1q…p5jg
_________________________

📅 Original date posted:2021-04-23
📝 Original message:
Hi Jeremy,

Yes dates are floating for now. After Bitcoin 2021, sounds a good idea.

Awesome, I'll be really interested to review again an improved version of
sponsorship. And I'll try to sketch out the sighash_no-input fee-bumping
idea which was floating around last year during pinnings discussions. Yet
another set of trade-offs :)

Le ven. 23 avr. 2021 à 11:25, Jeremy <jlrubin at mit.edu> a écrit :

> I'd be excited to join. Recommend bumping the date to mid June, if that's
> ok, as many Americans will be at Bitcoin 2021.
>
> I was thinking about reviving the sponsors proposal with a 100 block lock
> on spending a sponsoring tx which would hopefully make less controversial,
> this would be a great place to discuss those tradeoffs.
>
> On Fri, Apr 23, 2021, 8:17 AM Antoine Riard <antoine.riard at gmail.com>
> wrote:
>
>> Hi,
>>
>> During the lastest years, tx-relay and mempool acceptances rules of the
>> base layer have been sources of major security and operational concerns for
>> Lightning and other Bitcoin second-layers [0]. I think those areas require
>> significant improvements to ease design and deployment of higher Bitcoin
>> layers and I believe this opinion is shared among the L2 dev community. In
>> order to make advancements, it has been discussed a few times in the last
>> months to organize in-person workshops to discuss those issues with the
>> presence of both L1/L2 devs to make exchange fruitful.
>>
>> Unfortunately, I don't think we'll be able to organize such in-person
>> workshops this year (because you know travel is hard those days...) As a
>> substitution, I'm proposing a series of one or more irc meetings. That
>> said, this substitution has the happy benefit to gather far more folks
>> interested by those issues that you can fit in a room.
>>
>> # Scope
>>
>> I would like to propose the following 4 items as topics of discussion.
>>
>> 1) Package relay design or another generic L2 fee-bumping primitive like
>> sponsorship [0]. IMHO, this primitive should at least solve mempools spikes
>> making obsolete propagation of transactions with pre-signed feerate, solve
>> pinning attacks compromising Lightning/multi-party contract protocol
>> safety, offer an usable and stable API to L2 software stack, stay
>> compatible with miner and full-node operators incentives and obviously
>> minimize CPU/memory DoS vectors.
>>
>> 2) Deprecation of opt-in RBF toward full-rbf. Opt-in RBF makes it trivial
>> for an attacker to partition network mempools in divergent subsets and from
>> then launch advanced security or privacy attacks against a Lightning node.
>> Note, it might also be a concern for bandwidth bleeding attacks against L1
>> nodes.
>>
>> 3) Guidelines about coordinated cross-layers security disclosures.
>> Mitigating a security issue around tx-relay or the mempool in Core might
>> have harmful implications for downstream projects. Ideally, L2 projects
>> maintainers should be ready to upgrade their protocols in emergency in
>> coordination with base layers developers.
>>
>> 4) Guidelines about L2 protocols onchain security design. Currently
>> deployed like Lightning are making a bunch of assumptions on tx-relay and
>> mempool acceptances rules. Those rules are non-normative, non-reliable and
>> lack documentation. Further, they're devoid of tooling to enforce them at
>> runtime [2]. IMHO, it could be preferable to identify a subset of them on
>> which second-layers protocols can do assumptions without encroaching too
>> much on nodes's policy realm or making the base layer development in those
>> areas too cumbersome.
>>
>> I'm aware that some folks are interested in other topics such as
>> extension of Core's mempools package limits or better pricing of RBF
>> replacement. So l propose a 2-week concertation period to submit other
>> topics related to tx-relay or mempools improvements towards L2s before to
>> propose a finalized scope and agenda.
>>
>> # Goals
>>
>> 1) Reaching technical consensus.
>> 2) Reaching technical consensus, before seeking community consensus as it
>> likely has ecosystem-wide implications.
>> 3) Establishing a security incident response policy which can be applied
>> by dev teams in the future.
>> 4) Establishing a philosophy design and associated documentations (BIPs,
>> best practices, ...)
>>
>> # Timeline
>>
>> 2021-04-23: Start of concertation period
>> 2021-05-07: End of concertation period
>> 2021-05-10: Proposition of workshop agenda and schedule
>> late 2021-05/2021-06: IRC meetings
>>
>> As the problem space is savagely wide, I've started a collection of
>> documents to assist this workshop : https://github.com/ariard/L2-zoology
>> Still wip, but I'll have them in a good shape at agenda publication, with
>> reading suggestions and open questions to structure discussions.
>> Also working on transaction pinning and mempool partitions attacks
>> simulations.
>>
>> If L2s security/p2p/mempool is your jam, feel free to get involved :)
>>
>> Cheers,
>> Antoine
>>
>> [0] For e.g see optech section on transaction pinning attacks :
>> https://bitcoinops.org/en/topics/transaction-pinning/
>> [1]
>> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2020-September/018168.html
>> [2] Lack of reference tooling make it easier to have bug slip in like
>> https://lists.linuxfoundation.org/pipermail/lightning-dev/2020-October/002858.html
>> _______________________________________________
>> Lightning-dev mailing list
>> Lightning-dev at lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20210423/b87b1ec8/attachment-0001.html>;

📅 Original date posted:2021-04-23 📝 Original message: Hi, ...

2023-06-09T15:02:20+02:00

In reply to nevent1q…j3xk
_________________________

📅 Original date posted:2021-04-23
📝 Original message:
Hi,

During the lastest years, tx-relay and mempool acceptances rules of the
base layer have been sources of major security and operational concerns for
Lightning and other Bitcoin second-layers [0]. I think those areas require
significant improvements to ease design and deployment of higher Bitcoin
layers and I believe this opinion is shared among the L2 dev community. In
order to make advancements, it has been discussed a few times in the last
months to organize in-person workshops to discuss those issues with the
presence of both L1/L2 devs to make exchange fruitful.

Unfortunately, I don't think we'll be able to organize such in-person
workshops this year (because you know travel is hard those days...) As a
substitution, I'm proposing a series of one or more irc meetings. That
said, this substitution has the happy benefit to gather far more folks
interested by those issues that you can fit in a room.

# Scope

I would like to propose the following 4 items as topics of discussion.

1) Package relay design or another generic L2 fee-bumping primitive like
sponsorship [0]. IMHO, this primitive should at least solve mempools spikes
making obsolete propagation of transactions with pre-signed feerate, solve
pinning attacks compromising Lightning/multi-party contract protocol
safety, offer an usable and stable API to L2 software stack, stay
compatible with miner and full-node operators incentives and obviously
minimize CPU/memory DoS vectors.

2) Deprecation of opt-in RBF toward full-rbf. Opt-in RBF makes it trivial
for an attacker to partition network mempools in divergent subsets and from
then launch advanced security or privacy attacks against a Lightning node.
Note, it might also be a concern for bandwidth bleeding attacks against L1
nodes.

3) Guidelines about coordinated cross-layers security disclosures.
Mitigating a security issue around tx-relay or the mempool in Core might
have harmful implications for downstream projects. Ideally, L2 projects
maintainers should be ready to upgrade their protocols in emergency in
coordination with base layers developers.

4) Guidelines about L2 protocols onchain security design. Currently
deployed like Lightning are making a bunch of assumptions on tx-relay and
mempool acceptances rules. Those rules are non-normative, non-reliable and
lack documentation. Further, they're devoid of tooling to enforce them at
runtime [2]. IMHO, it could be preferable to identify a subset of them on
which second-layers protocols can do assumptions without encroaching too
much on nodes's policy realm or making the base layer development in those
areas too cumbersome.

I'm aware that some folks are interested in other topics such as extension
of Core's mempools package limits or better pricing of RBF replacement. So
l propose a 2-week concertation period to submit other topics related to
tx-relay or mempools improvements towards L2s before to propose a finalized
scope and agenda.

# Goals

1) Reaching technical consensus.
2) Reaching technical consensus, before seeking community consensus as it
likely has ecosystem-wide implications.
3) Establishing a security incident response policy which can be applied by
dev teams in the future.
4) Establishing a philosophy design and associated documentations (BIPs,
best practices, ...)

# Timeline

2021-04-23: Start of concertation period
2021-05-07: End of concertation period
2021-05-10: Proposition of workshop agenda and schedule
late 2021-05/2021-06: IRC meetings

As the problem space is savagely wide, I've started a collection of
documents to assist this workshop : https://github.com/ariard/L2-zoology
Still wip, but I'll have them in a good shape at agenda publication, with
reading suggestions and open questions to structure discussions.
Also working on transaction pinning and mempool partitions attacks
simulations.

If L2s security/p2p/mempool is your jam, feel free to get involved :)

Cheers,
Antoine

[0] For e.g see optech section on transaction pinning attacks :
https://bitcoinops.org/en/topics/transaction-pinning/
[1]
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2020-September/018168.html
[2] Lack of reference tooling make it easier to have bug slip in like
https://lists.linuxfoundation.org/pipermail/lightning-dev/2020-October/002858.html
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20210423/98e1f2cc/attachment.html>;

📅 Original date posted:2020-10-06 📝 Original message: Hello ...

2023-06-09T15:01:00+02:00

In reply to nevent1q…rdkc
_________________________

📅 Original date posted:2020-10-06
📝 Original message:
Hello Bastien,

I'm all in for a model where channel transactions are pre-signed with a
reasonable minimal relay fee and the adjustment is done by the closer. The
channel initiator shouldn't have to pay for channel-closing as it's somehow
a liquidity allocation decision ("My balance could be better allocated
elsewhere than in this channel").

That said, a channel closing might be triggered due to a security
mechanism, like a HTLC to timeout onchain. Thus a malicious counterparty
can easily loop a HTLC forwarding on an honest peer. Then not cancel it
on-time to force the honest counterparty to pay onchain fees to avoid a
offered HTLC not being claimed back on time.

AFAICT, this issue is not solved by anchor outputs. A way to decentivize
this kind of behavior from a malicious counterparty is an upfront payment
where the upholding HTLC fee * HTLC block-buffer-before-onchain is higher
than the cost of going onchain. It should cost higher for the counterparty
to withhold a HTLC than paying onchain-fees to close the channel.

Or can you think about another mitigation for the issue raised above ?

Antoine

Le lun. 5 oct. 2020 à 09:13, Bastien TEINTURIER via Lightning-dev <
lightning-dev at lists.linuxfoundation.org> a écrit :

> Good morning list,
>
> It seems to me that the "funder pays all the commit tx fees" rule exists
> solely for simplicity
> (which was totally reasonable). I haven't been able to find much
> discussion about this decision
> on the mailing list nor in the spec commits.
>
> At first glance, it's true that at the beginning of the channel lifetime,
> the funder should be
> responsible for the fee (it's his decision to open a channel after all).
> But as time goes by and
> both peers earn value from this channel, this rule becomes questionable.
> We've discovered since
> then that there is some risk associated with having pending HTLCs
> (flood-and-loot type of attacks,
> pinning, channel jamming, etc).
>
> I think that *in some cases*, fundees should be paying a portion of the
> commit-tx on-chain fees,
> otherwise we may end up with a web-of-trust network where channels would
> only exist between peers
> that trust each other, which is quite limiting (I'm hoping we can do
> better).
>
> Routing nodes may be at risk when they *receive* HTLCs. All the attacks
> that steal funds come from
> the fact that a routing node has paid downstream but cannot claim the
> upstream HTLCs (correct me
> if that's incorrect). Thus I'd like nodes to pay for the on-chain fees of
> the HTLCs they offer
> while they're pending in the commit-tx, regardless of whether they're
> funder or fundee.
>
> The simplest way to do this would be to deduce the HTLC cost (172 *
> feerate) from the offerer's
> main output (instead of the funder's main output, while keeping the base
> commit tx weight paid
> by the funder).
>
> A more extreme proposal would be to tie the *total* commit-tx fee to the
> channel usage:
>
> * if there are no pending HTLCs, the funder pays all the fee
> * if there are pending HTLCs, each node pays a proportion of the fee
> proportional to the number of
> HTLCs they offered. If Alice offered 1 HTLC and Bob offered 3 HTLCs, Bob
> pays 75% of the
> commit-tx fee and Alice pays 25%. When the HTLCs settle, the fee is
> redistributed.
>
> This model uses the on-chain fee as collateral for usage of the channel.
> If Alice wants to forward
> HTLCs through this channel (because she has something to gain - routing
> fees), she should be taking
> on some of the associated risk, not Bob. Bob will be taking the same risk
> downstream if he chooses
> to forward.
>
> I believe it also forces the fundee to care about on-chain feerates, which
> is a healthy incentive.
> It may create a feedback loop between on-chain feerates and routing fees,
> which I believe is also
> a good long-term thing (but it's hard to predict as there may be negative
> side-effects as well).
>
> What do you all think? Is this a terrible idea? Is it okay-ish, but not
> worth the additional
> complexity? Is it an amazing idea worth a lightning nobel? Please don't
> take any of my claims
> for granted and challenge them, there may be negative side-effects I'm
> completely missing, this is
> a fragile game of incentives...
>
> Side-note: don't forget to take into account that the fees for HTLC
> transactions (second-level txs)
> are always paid by the party that broadcasts them (which makes sense). I
> still think this is not
> enough and can even be abused by fundees in some setups.
>
> Thanks,
> Bastien
> _______________________________________________
> Lightning-dev mailing list
> Lightning-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20201006/eb3eaa1c/attachment.html>;

📅 Original date posted:2020-10-08 📝 Original message: > ...

2023-06-09T15:00:56+02:00

In reply to nevent1q…nvxu
_________________________

📅 Original date posted:2020-10-08
📝 Original message:
> There is no need to stop the channel's operations while you're updating
these parameters, since
they can be updated unilaterally anyway

I think it's just how you defne channel's operations, either emptying out
all pending HTLCs or more a `update_fee` alike semantic. You're right that
the latter should be good enough for the set of parameters you're proposing.
A lightweight `update_policy` doesn't sound to bear difficulty at first
sight.

Le jeu. 8 oct. 2020 à 08:23, Bastien TEINTURIER <bastien at acinq.fr> a écrit :

> Good morning Antoine and Zman,
>
> Thanks for your answers!
>
> I was thinking dynamic policy adjustment would be covered by the dynamic
>> commitment mechanism proposed by Laolu
>
>
> I didn't mention this as I think we still have a long-ish way to go before
> dynamic commitments
> are spec-ed, implemented and deployed, and I think the parameters I'm
> interested in don't require
> that complexity to be updated.
>
> Please forget about channel jamming, upfront fees et al and simply
> consider the parameters I'm
> mentioning. It feels to me that these are by nature dynamic channel
> parameters (some of them are
> even present in `channel_update`, but no-one updates them yet because
> direct peers don't take the
> update into account anyway). I'd like to raise `htlc_minimum_msat` on some
> big channels because
> I'd like these channels to be used only for big-ish payments. Today I
> can't, I have to close that
> channel and open a new one for such a trivial configuration update, which
> is sad.
>
> There is no need to stop the channel's operations while you're updating
> these parameters, since
> they can be updated unilaterally anyway. The only downside is that if you
> make your policy stricter,
> your peer may send you some HTLCs that you will immediately fail
> afterwards; it's only a minor
> inconvenience that won't trigger a channel closure.
>
> I'd like to know if other implementations than eclair have specificities
> that would make this
> feature particularly hard to implement or undesirable.
>
> Thanks,
> Bastien
>
> Le mar. 6 oct. 2020 à 18:43, ZmnSCPxj <ZmnSCPxj at protonmail.com> a écrit :
>
>> Good morning Antoine, and Bastien,
>>
>>
>> > Instead of relying on reputation, the other alternative is just to have
>> an upfront payment system, where a relay node doesn't have to account for a
>> HTLC issuer reputation to decide acceptance and can just forward a HTLC as
>> long it paid enough. More, I think it's better to mitigate jamming with a
>> fees-based system than a web-of-trust one, less burden on network newcomers.
>>
>> Let us consider some of the complications here.
>>
>> A newcomer wants to make an outgoing payment.
>> Speculatively, it connects to some existing nodes based on some policy.
>>
>> Now, since forwarding is upfront, the newcomer fears that the node it
>> connected to might not even bother forwarding the payment, and instead just
>> fail it and claim the upfront fees.
>>
>> In particular: how would the newcomer offer upfront fees to a node it is
>> not directly channeled with?
>> In order to do that, we would have to offer the upfront fees for that
>> node, to the node we *are* channeled with, so it can forward this as well.
>>
>> * We can give the upfront fee outright to the first hop, and trust that
>> if it forwards, it will also forward the upfront fee for the next hop.
>> * The first hop would then prefer to just fail the HTLC then and there
>> and steal all the upfront fees.
>> * After all, the offerrer is a newcomer, and might be the sybil of a
>> hacker that is trying to tie up its liquidity.
>> The first hop would (1) avoid this risk and (2) earn more upfront
>> fees because it does not forward those fees to later hops.
>> * This is arguably custodial and not your keys not your coins applies.
>> Thus, it returns us back to tr\*st anyway.
>> * We can require that the first hop prove *where* along the route errored.
>> If it provably failed at a later hop, then the first hop can claim more
>> as upfront fees, since it will forward the upfront fees to the later hop as
>> well.
>> * This has to be enforcable onchain in case the channel gets dropped
>> onchain.
>> Is there a proposal SCRIPT which can enforce this?
>> * If not enforcable onchain, then there may be onchain shenanigans
>> possible and thus this solution might introduce an attack vector even as it
>> fixes another.
>> * On the other hand, sub-satoshi amounts are not enforcable onchain
>> too, and nobody cares, so...
>>
>> On the other hand, a web-of-tr\*st might not be *that* bad.
>>
>> One can say that "tr\*st is risk", and consider that the size and age of
>> a channel to a peer represents your tr\*st that that peer will behave
>> correctly for fast and timely resolution of payments.
>> And anyone can look at the blockchain and the network gossip to get an
>> idea of who is generally considered tr\*stworthy, and since that
>> information is backed by Bitcoins locked in channels, this is reasonably
>> hard to fake.
>>
>> On the other hand, this risks centralization around existing, long-lived
>> nodes.
>> *Sigh*.
>>
>> Regards,
>> ZmnSCPxj
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20201008/4fe5af26/attachment-0001.html>;

📅 Original date posted:2020-10-06 📝 Original message: Hello ...

2023-06-09T15:00:55+02:00

In reply to nevent1q…dvap
_________________________

📅 Original date posted:2020-10-06
📝 Original message:
Hello Bastien,

As a first note , I was thinking dynamic policy adjustment would be covered
by the dynamic commitment mechanism proposed by Laolu as it presents the
same trade-offs, you need to stop channel HTLC processing before upgrading,
otherwise it might falsify your whole in-flight HTLC accounting.

> Recent discussions around channel jamming [1] have highlighted again the
> need to think twice when
> configuring your channels parameters.

I'm still dubious that straighter channel parameters are the best solution
to solve channel jamming. As a routing node evaluating a HTLC, I think the
question you're trying to answer is : "Is this a _honest_ HTLC to relay ?",
where honest is defined both as paying more fees that the liquidity lock
and with high odds of a positive settlement, otherwise you won't get paid.

The first predicate is easy to evaluate, just verify that the HTLC is
paying more as an incoming packet that you have to send forward.

On the other hand, the second predicate is hard to evaluate. A first lead
of a solution is to evaluate the packet forwarder instead of the packet
itself. You may have a web-of-trust/reputation system with a one-level rank
of trust which would be enforced at the channel opening layer, i.e don't
open/accept channels with random nodes. A less constraining version is
still a reputation system but where you statically attribute a HTLC
forwarding policy based on counterparty reputation (~today).

The more evolved reputation system version you implicitly seem to argue for
is adapting the forwarding policy based on counterparty past behavior, e.g
like relaxing channel parameters for a counterparty upstreaming a lot of
successful HTLCs. IMO, this is still presenting hurdles.

If you have 1 BTC of outgoing bandwidth but your counterparty is enforcing
a `max_htlc_value_in_flight_msat` of 0.5 BTC, it means you have a
"sleeping" outgoing liquidity. Rationally, you should only open a channel
with a capacity somehow equivalent to what is authorized by your
counterparty relay policy.

A lesson would be to negotiate first a policy then an opening, as of today
they're still bundled in one message flow. I don't think you can reduce the
capacity once you learn acceptor policy ? Don't overstake liquidity more
than you can actually gain from.

That said, if you have a dynamic policy model, at policy relaxation, you
need to increase channel capacity to profit from relaxation, let's say
through some kind of splice-in. But now you have on-chain fees at each
policy/liquidity adjustment.

Under a dynamic policy model based on accumulated reputation, it sounds
like there is some kind of trade-off between useless off-chain liquidity
and on-chain fees.

Instead of relying on reputation, the other alternative is just to have an
upfront payment system, where a relay node doesn't have to account for a
HTLC issuer reputation to decide acceptance and can just forward a HTLC as
long it paid enough. More, I think it's better to mitigate jamming with a
fees-based system than a web-of-trust one, less burden on network newcomers.

This doesn't prevent hybrid models where you might reward your good
behaving peers with a discount on your upfront payment policy.

What's your opinion ?

Antoine

Le lun. 5 oct. 2020 à 07:54, Bastien TEINTURIER via Lightning-dev <
lightning-dev at lists.linuxfoundation.org> a écrit :

> Good evening list,
>
> Recent discussions around channel jamming [1] have highlighted again the
> need to think twice when
> configuring your channels parameters. There are currently parameters that
> are set once at channel
> creation that would benefit a lot from being configurable throughout the
> lifetime of the channel
> to avoid closing channels when we just want to reconfigure them:
>
> * max_htlc_value_in_flight_msat
> * max_accepted_htlcs
> * htlc_minimum_msat
> * htlc_maximum_msat
>
> Nodes can currently unilaterally udpate these by applying forwarding
> heuristics, but it would be
> better to tell our peer about the limits we want to put in place
> (otherwise we're wasting a whole
> cycle of add/commit/revoke/fail messages for no good reason).
>
> I suggest adding tlv records in `commitment_signed` to tell our channel
> peer that we're changing
> the values of these fields.
>
> Is someone opposed to that?
> Are there other fields you think would need to become dynamic as well?
> Do you think that needs a new message instead of using extensions of
> `commitment_signed`?
>
> Cheers,
> Bastien
>
> [1] https://twitter.com/joostjgr/status/1308414364911841281
> _______________________________________________
> Lightning-dev mailing list
> Lightning-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20201006/8dc749f6/attachment.html>;

📅 Original date posted:2020-06-18 📝 Original message: Hi ...

2023-06-09T15:00:24+02:00

In reply to nevent1q…5zw7
_________________________

📅 Original date posted:2020-06-18
📝 Original message:
Hi Rene,

Thanks for disclosing this vulnerability,

I think this blackmail scenario holds but sadly there is a lower scenario.

Both "Flood & Loot" and your blackmail attack rely on `update_fee`
mechanism and unbounded commitment transaction size inflation. Though the
first to provoke block congestion and yours to lockdown in-flight fees as
funds hostage situation.

> 1. The current solution is to just not use up the max value of
htlc's. Eclaire and c-lightning by default only use up to 30 htlcs.

As of today, yes I would recommend capping commitment size both for
ensuring competitive propagation/block selection and limiting HTLC exposure.

> 2. Probably the best fix (not sure if I understand the consequences
correctly) is coming from this PR to bitcoin core (c.f.
https://github.com/bitcoin/bitcoin/pull/15681 by @TheBlueMatt . If I get it
correctly with that we could always have low fees and ask the person who
want to claim their outputs to pay fees. This excludes overpayment and
could happen at a later stage when fees are not spiked. Still the victim
who offered the htlcs would have to spend those outputs at some time.

It's a bit more complex, carve-out output, even combined with anchor output
support on the LN-side won't protect against different flavors of pinning.
I invite you to go through logs of past 2 LN dev meetings.

> 3. Don't overpay fees in commitment transactions. We can't foresee the
future anyway

Once 2. is well-addressed we may deprecate `update_fee`.

> 4. Don't add htlcs for which the on chain fee is higher than the HTLCs
value (like we do with sub dust amounts and sub satoshi amounts. This would
at least make the attack expensive as the attacker would have to bind a lot
of liquidity.

Ideally we want dust_limit to be dynamic, dust cap should be based on HTLC
economic value, feerate of its output, feerate of HTLC-transaction, feerate
estimation of any CPFP to bump it. I think that's kind of worthy to do once
we solved 3. and 4

> 5. Somehow be able to aggregate htlc's. In a world where we use payment
points instead of preimages we might be able to do so. It would be really
cool if separate HTLC's could be combined to 1 single output. I played
around a little bit but I have not come up with a scheme that is more
compact in all cases. Thus I just threw in the idea.

Yes we may encode all HTLC in some Taproot tree in the future. There are
some wrinkles but for a high-level theoretical construction see my post on
CoinPool.

> 6. Split onchain fees differently (now the attacker would also lose fees
by conducting this attack) - No I don't want to start yet another fee
bikeshadding debate. (In particular I believe that a different split of
fees might make the Flood & Loot attack economically more viable which
relies on the same principle)

Likely a bit more of fee bikeshedding is something we have to do to make LN
secure... Switching fee from pre-committed ones to a single-party, dynamic
one.

> Independently I think we should have a hint in our readme file about
where and how people can disclose attacks and vulnerabilities.
Implementations have this but the BOLTs do not.

I 100% agree, that's exactly
https://github.com/lightningnetwork/lightning-rfc/pull/772, waiting for
your feedback :)

Cheers,

Antoine

Le mer. 17 juin 2020 à 09:41, ZmnSCPxj via Lightning-dev <
lightning-dev at lists.linuxfoundation.org> a écrit :

>
> Good morning all,
>
> >
> > Fee futures could help against this.
> > I remember writing about this some time ago but cannot find where (not
> sure if it was in lightning-dev or bitcoin-dev).
>
> `harding` found it:
> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2020-January/017601.html
>
> Regards,
> ZmnSCPxj
> _______________________________________________
> Lightning-dev mailing list
> Lightning-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20200618/4505fed3/attachment.html>;

📅 Original date posted:2020-05-06 📝 Original message: I do ...

2023-06-09T15:00:10+02:00

In reply to nevent1q…awvr
_________________________

📅 Original date posted:2020-05-06
📝 Original message:
I do see the consensus capture argument by miners but in reality isn't this
attack scenario have a lot of assumptions on topology an deployment ?

For such attack to succeed you need miners nodes to be connected to clients
to feed directly the invalid headers and if these ones are connected to
headers/filters gateways, themselves doing full-nodes validation invalid
chain is going to be sanitized out ?

Sure now you trust these gateways, but if you have multiple connections to
them and can guarantee they aren't run by the same entity, that maybe an
acceptable security model, depending of staked amount and your
expectations. I more concerned of having a lot of them and being
diversified enough to avoid collusion between gateways/chain access
providers/miners.

But even if you light clients is directly connected to the backbone network
and may be reached by miners you can implement fork anomalies detection and
from then you may have multiples options:
* halt the wallet, wait for human intervention
* fallback connection to a trusted server, authoritative on your chain view
* invalidity proofs?

Now I agree you need a wide-enough, sane backbone network to build on top,
and we should foster node adoption as much as we can.

Le mar. 5 mai 2020 à 09:01, Luke Dashjr <luke at dashjr.org> a écrit :

> On Tuesday 05 May 2020 10:17:37 Antoine Riard via bitcoin-dev wrote:
> > Trust-minimization of Bitcoin security model has always relied first and
> > above on running a full-node. This current paradigm may be shifted by LN
> > where fast, affordable, confidential, censorship-resistant payment
> services
> > may attract a lot of adoption without users running a full-node.
>
> No, it cannot be shifted. This would compromise Bitcoin itself, which for
> security depends on the assumption that a supermajority of the economy is
> verifying their incoming transactions using their own full node.
>
> The past few years has seen severe regressions in this area, to the point
> where Bitcoin's future seems quite bleak. Without serious improvements to
> the
> full node ratio, Bitcoin is likely to fail.
>
> Therefore, all efforts to improve the "full node-less" experience are
> harmful,
> and should be actively avoided. BIP 157 improves privacy of fn-less usage,
> while providing no real benefits to full node users (compared to more
> efficient protocols like Stratum/Electrum).
>
> For this reason, myself and a few others oppose merging support for BIP
> 157 in
> Core.
>
> > Assuming a user adoption path where a full-node is required to benefit
> for
> > LN may deprive a lot of users, especially those who are already denied a
> > real financial infrastructure access.
>
> If Bitcoin can't do it, then Bitcoin can't do it.
> Bitcoin can't solve *any* problem if it becomes insecure itself.
>
> Luke
>
> P.S. See also
>
> https://medium.com/@nicolasdorier/why-i-dont-celebrate-neutrino-206bafa5fda0
>
> https://medium.com/@nicolasdorier/neutrino-is-dangerous-for-my-self-sovereignty-18fac5bcdc25
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20200506/7b20c4d4/attachment.html>;

📅 Original date posted:2020-05-17 📝 Original message: > ...

2023-06-09T15:00:10+02:00

In reply to nevent1q…vd7n
_________________________

📅 Original date posted:2020-05-17
📝 Original message:
> * At the same time, it retains your-keys-your-coins noncustodiality,
because every update of a Lightning channel requires your keys to sign off
on it.

Yes I agree, I can foresee an easier step where managing low-value channel
and get your familiar with smooth key management maybe a first step before
running a full-node and getting a more full-fledged key management solution.

> It may even be possible, that the Lightning future with massive SPV might
end up with more economic weight in SPV nodes, than in the world without
Lightning and dependent on centralized custodial services to scale.

Even evaluating economic weight in Lightning is hard, both parties have
their own chain view, and it's likely if you assume a hub-and-spoke
topology, leaf nodes are going to be SPV and internal nodes full-nodes ?

> Money makes the world go round, so such backup servers that are
publicly-facing rather than privately-owned should be somehow incentivized
to do so, or else they would not exist in the first place.

I was thinking about the current workflow, Alice downloads her New Shiny
LN-wallet, she is asked to backup the seed, she is asked to pick-up
backup(s) nodes among her friends, relatives or business partners and is
NOT provided any automatic hint and register backup nodes addresses, maybe
even do out-of-band key exchange with this full-node operator. Therefore
you may avoid centralization by having not such publicly-facing servers. Of
course, Alice can still scrawl the web to and be lured to pickup malicious
public servers but if she is severely notified to not do so that may be
enough.

So it would be a combination of UX+user education+fallback security
mechanism to avoid economy hijack. That maybe a better solution rather than
PoW-only SPV. We have an open network so you can't prevent someone to run
such type of client but at least if they have to do so you can provide them
with a better option ?

Antoine

Le jeu. 14 mai 2020 à 00:02, ZmnSCPxj <ZmnSCPxj at protonmail.com> a écrit :

> Good morning Antoine,
>
>
> > While approaching this question, I think you should consider economic
> weight of nodes in evaluating miner consensus-hijack success. Even if you
> expect a disproportionate ratio of full-nodes-vs-SPV, they may not have the
> same economic weight at all, therefore even if miners are able to lure a
> majority of SPV clients they may not be able to stir economic nodes. SPV
> clients users will now have an incentive to cancel their hijacked history
> to stay on the most economic meaningful chain. And it's already assumed,
> that if you run a bitcoin business or LN routing node, you do want to run
> your own full-node.
>
> One hope I have for Lightning is that it will replace centralized
> custodial services, because:
>
> * Lightning gains some of the scalability advantage of centralized
> custodial services, because you can now transfer to any Lightning client
> without touching the blockchain, for much reduced transfer fees.
> * At the same time, it retains your-keys-your-coins noncustodiality,
> because every update of a Lightning channel requires your keys to sign off
> on it.
>
> If most Lightning clients are SPV, then if we compare these two worlds:
>
> * There are a few highly-important centralized custodial services with
> significant economic weight running fullnodes (i.e. now).
> * There are no highly-important centralized custodial services, and most
> everyone uses Lightning, but with SPV (i.e. a Lightning future).
>
> Then the distribution of economic weight would be different between these
> two worlds.
> It may even be possible, that the Lightning future with massive SPV might
> end up with more economic weight in SPV nodes, than in the world without
> Lightning and dependent on centralized custodial services to scale.
>
>
> It is also entirely possible that custodial services for Lightning will
> arise anyway and my hope is already dashed, come on universe, work harder
> will you, would you really disappoint some randomly-generated Internet
> person like that.
>
>
> >
> > I agree it may be hard to evaluate economic-weight-to-chain-backend
> segments, specially with offchain you disentangle an onchain output value
> from its real payment traffic. To strengthen SPV, you may implement forks
> detection and fallback to some backup node(s) which would serve as an
> authoritative source to arbiter between branches. Such backup node(s) must
> be picked up manually at client initialization, before any risk of conflict
> to avoid Reddit-style of hijack during contentious period or other massive
> social engineering. You don't want autopilot-style of recommendations for
> picking up a backup nodes and avoid cenralization of backups, but somehow a
> uniform distribution. A backup node may be a private one, it won't serve
> you any data beyond headers, and therefore you preserve public nodes
> bandwidth, which IMO is the real bottleneck. I concede it won't work well
> if you have a ratio of 1000-SPV for 1-full-node and people are not
> effectively able to pickup a backup among their social environment.
> > What do you think about this model ?
>
> Money makes the world go round, so such backup servers that are
> publicly-facing rather than privately-owned should be somehow incentivized
> to do so, or else they would not exist in the first place.
> Of course, a free market tends towards monopoly, because any entity that
> happens to have even a slight advantage at the business will have more
> money to use towards business reinvestment and increase its advantage
> further, until they beat the competition to dust, anyone who has won a 4X
> game knows to search for and stack those little advantages until you
> snowball and conquer the world/galaxy/petri dish which is why the endgame
> of 4X games is so boring compared to the start, we have seen this happen in
> mining and exchanges and so on, and this works against your desire to have
> a uniform distribution.
>
> If everyone runs such a privately-owned server, on the other hand, this is
> not so different from having a Lightning node you run at your home that has
> a fullnode as well and which you access via a remote control mobile device,
> and it is the inconvenience of having such a server at your home that
> prevents this in the first place.
>
> Regards,
> ZmnSCPxj
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20200516/5aa4025e/attachment.html>;

📅 Original date posted:2020-05-13 📝 Original message: Hi ...

2023-06-09T15:00:08+02:00

In reply to nevent1q…tljk
_________________________

📅 Original date posted:2020-05-13
📝 Original message:
Hi Chris,

While approaching this question, I think you should consider economic
weight of nodes in evaluating miner consensus-hijack success. Even if you
expect a disproportionate ratio of full-nodes-vs-SPV, they may not have the
same economic weight at all, therefore even if miners are able to lure a
majority of SPV clients they may not be able to stir economic nodes. SPV
clients users will now have an incentive to cancel their hijacked history
to stay on the most economic meaningful chain. And it's already assumed,
that if you run a bitcoin business or LN routing node, you do want to run
your own full-node.

I agree it may be hard to evaluate economic-weight-to-chain-backend
segments, specially with offchain you disentangle an onchain output value
from its real payment traffic. To strengthen SPV, you may implement forks
detection and fallback to some backup node(s) which would serve as an
authoritative source to arbiter between branches. Such backup node(s) must
be picked up manually at client initialization, before any risk of conflict
to avoid Reddit-style of hijack during contentious period or other massive
social engineering. You don't want autopilot-style of recommendations for
picking up a backup nodes and avoid cenralization of backups, but somehow a
uniform distribution. A backup node may be a private one, it won't serve
you any data beyond headers, and therefore you preserve public nodes
bandwidth, which IMO is the real bottleneck. I concede it won't work well
if you have a ratio of 1000-SPV for 1-full-node and people are not
effectively able to pickup a backup among their social environment.

What do you think about this model ?

Cheers,

Antoine

Le mar. 12 mai 2020 à 17:06, Chris Belcher <belcher at riseup.net> a écrit :

> On 05/05/2020 16:16, Lloyd Fournier via bitcoin-dev wrote:
> > On Tue, May 5, 2020 at 9:01 PM Luke Dashjr via bitcoin-dev <
> > bitcoin-dev at lists.linuxfoundation.org> wrote:
> >
> >> On Tuesday 05 May 2020 10:17:37 Antoine Riard via bitcoin-dev wrote:
> >>> Trust-minimization of Bitcoin security model has always relied first
> and
> >>> above on running a full-node. This current paradigm may be shifted by
> LN
> >>> where fast, affordable, confidential, censorship-resistant payment
> >> services
> >>> may attract a lot of adoption without users running a full-node.
> >>
> >> No, it cannot be shifted. This would compromise Bitcoin itself, which
> for
> >> security depends on the assumption that a supermajority of the economy
> is
> >> verifying their incoming transactions using their own full node.
> >>
> >
> > Hi Luke,
> >
> > I have heard this claim made several times but have never understood the
> > argument behind it. The question I always have is: If I get scammed by
> not
> > verifying my incoming transactions properly how can this affect anyone
> > else? It's very unintuative. I've been scammed several times in my life
> in
> > fiat currency transactions but as far as I could tell it never negatively
> > affected the currency overall!
> >
> > The links you point and from what I've seen you say before refer to
> "miner
> > control" as the culprit. My only thought is that this is because a light
> > client could follow a dishonest majority of hash power chain. But this
> just
> > brings me back to the question. If, instead of BTC, I get a payment in
> some
> > miner scamcoin on their dishonest fork (but I think it's BTC because I'm
> > running a light client) that still seems to only to damage me. Where does
> > the side effect onto others on the network come from?
> >
> > Cheers,
> >
> > LL
> >
>
> Hello Lloyd,
>
> The problem comes when a large part of the ecosystem gets scammed at
> once, which is how such an attack would happen in practice.
>
> For example, consider if bitcoin had 10000 users. 10 of them use a full
> node wallet while the other 9990 use an SPV wallet. If a miner attacked
> the system by printing infinite bitcoins and spending coins without a
> valid signature, then the 9990 SPV wallets would accept those fake coins
> as payment, and trade the coins amongst themselves. After a time those
> coins would likely be the ancestors of most active coins in the
> 9990-SPV-wallet ecosystem. Bitcoin would split into two currencies:
> full-node-coin and SPV-coin.
>
> Now the fraud miners may become well known, perhaps being published on
> bitcoin news portals, but the 9990-SPV-wallet ecosystem has a strong
> incentive to be against any rollback. Their recent transactions would
> disappear and they'd lose money. They would argue that they've already
> been using the coin for a while, and it works perfectly fine, and anyway
> a coin that can be spent in 9990 places is more useful than one that can
> be spent in just 10 places. The SPV-wallet community might even decide
> to use something like `invalidateblock` to make sure their SPV-coin
> doesn't get reorg'd out of existence. There'd also likely be a social
> attack, with every bitcoin community portal being flooded with bots and
> shills advocating the merits of SPV-coin. This is not a hypothetical
> because we already saw the same thing during the scalability conflict
> 2015-2017.
>
> Before you know it, "Bitcoin" would become SPV-coin with inflation and
> arbitrary seizure. Any normal user could download software called
> "Bitcoin wallet" which they trust and have used before, but instead of
> using Bitcoin they'd be using SPV-coin. You may be one of the 10 wallets
> backed by a full node, but that won't do much good to you when 9990
> users happily use another coin as their medium of exchange.
>
> Regards
> CB
> _______________________________________________
> Lightning-dev mailing list
> Lightning-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20200513/91739e5e/attachment.html>;

📅 Original date posted:2020-05-06 📝 Original message: > ...

2023-06-09T15:00:07+02:00

In reply to nevent1q…hp4w
_________________________

📅 Original date posted:2020-05-06
📝 Original message:
> The choice between whether we offer them a light client technology that
is better or worse for privacy and scalability.

And offer them a solution which would scale in the long-term.

Again it's not an argumentation against BIP 157 protocol in itself, the
problem I'm interested in is how implementing BIP157 in Core will address
this issue ?

Le mar. 5 mai 2020 à 13:36, John Newbery via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> a écrit :

> There doesn't seem to be anything in the original email that's specific to
> BIP 157. It's a restatement of the arguments against light clients:
>
> - light clients are a burden on the full nodes that serve them
> - if light clients become more popular, there won't be enough full nodes
> to serve them
> - people might build products that depend on altruistic nodes serving
> data, which is unsustainable
> - maybe at some point in the future, light clients will need to pay for
> services
>
> The choice isn't between people using light clients or not. People already
> use light clients. The choice between whether we offer them a light client
> technology that is better or worse for privacy and scalability.
>
> The arguments for why BIP 157 is better than the existing light client
> technologies are available elsewhere, but to summarize:
>
> - they're unique for a block, which means they can easily be cached.
> Serving a filter requires no computation, just i/o (or memory access for
> cached filter/header data) and bandwidth. There are plenty of other
> services that a full node offers that use i/o and bandwidth, such as
> serving blocks.
> - unique-for-block means clients can download from multiple sources
> - the linked-headers/filters model allows hybrid approaches, where headers
> checkpoints can be fetched from trusted/signed nodes, with intermediate
> headers and filters fetched from untrusted sources
> - less possibilities to DoS/waste resources on the serving node
> - better for privacy
>
> > The intention, as I understood it, of putting BIP157 directly into
> bitcoind was to essentially force all `bitcoind` users to possibly service
> BIP157 clients
>
> Please. No-one is forcing anyone to do anything. To serve filters, a node
> user needs to download the latest version, set `-blockfilterindex=basic` to
> build the compact filters index, and set `-peercfilters` to serve them over
> P2P. This is an optional, off-by-default feature.
>
> Regards,
> John
>
>
> On Tue, May 5, 2020 at 9:50 AM ZmnSCPxj via bitcoin-dev <
> bitcoin-dev at lists.linuxfoundation.org> wrote:
>
>> Good morning ariard and luke-jr
>>
>>
>> > > Trust-minimization of Bitcoin security model has always relied first
>> and
>> > > above on running a full-node. This current paradigm may be shifted by
>> LN
>> > > where fast, affordable, confidential, censorship-resistant payment
>> services
>> > > may attract a lot of adoption without users running a full-node.
>> >
>> > No, it cannot be shifted. This would compromise Bitcoin itself, which
>> for
>> > security depends on the assumption that a supermajority of the economy
>> is
>> > verifying their incoming transactions using their own full node.
>> >
>> > The past few years has seen severe regressions in this area, to the
>> point
>> > where Bitcoin's future seems quite bleak. Without serious improvements
>> to the
>> > full node ratio, Bitcoin is likely to fail.
>> >
>> > Therefore, all efforts to improve the "full node-less" experience are
>> harmful,
>> > and should be actively avoided. BIP 157 improves privacy of fn-less
>> usage,
>> > while providing no real benefits to full node users (compared to more
>> > efficient protocols like Stratum/Electrum).
>> >
>> > For this reason, myself and a few others oppose merging support for BIP
>> 157 in
>> > Core.
>>
>> BIP 157 can be implemented as a separate daemon that processes the blocks
>> downloaded by an attached `bitcoind`, i.e. what Wasabi does.
>>
>> The intention, as I understood it, of putting BIP157 directly into
>> bitcoind was to essentially force all `bitcoind` users to possibly service
>> BIP157 clients, in the hope that a BIP157 client can contact any arbitrary
>> fullnode to get BIP157 service.
>> This is supposed to improve to the situation relative to e.g. Electrum,
>> where there are far fewer Electrum servers than fullnodes.
>>
>> Of course, as ariard computes, deploying BIP157 could lead to an
>> effective DDoS on the fullnode network if a large number of BIP157 clients
>> arise.
>> Though maybe this will not occur very fast? We hope?
>>
>> It seems to me that the thing that *could* be done would be to have
>> watchtowers provide light-client services, since that seems to be the major
>> business model of watchtowers, as suggested by ariard as well.
>> This is still less than ideal, but maybe is better than nothing.
>>
>> Regards,
>> ZmnSCPxj
>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-dev at lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20200506/8f7f3555/attachment.html>;

📅 Original date posted:2019-12-18 📝 Original message: Hi ...

2023-06-09T14:57:48+02:00

In reply to nevent1q…pdsm
_________________________

📅 Original date posted:2019-12-18
📝 Original message:
Hi Bastien,

The use case you're describing strikes me as similar to a slashing protocol
for a LN node and a watchtower, i.e punishing
a lazy watchtower for not broadcasting a penalty tx on remote revoked
state. In both case you want "if A don't do X
unlock some funds for B".

Here a rough slashing protocol I've sketched out to someone else off-list,
it may work for you use case if you replace the penalty tx
by the funding transaction as a way for the trusted channel funder to clear
his liability. Though you will need onchain interactivity
before the fact but you may be able to reuse slashing outpoint for multiple
channel funding.

Slashing Protocol
----------------------

Alice and Bob lock fund in channel outpoint X. They issue commitment tx N.
Will the accountable watchtower locks fund
in a 2-of-2 slashing outpoint Y with Bob the client.

When Alice and Bob update channels to N', Bob and Will use some output from
commitment N (like upcoming anchor output)
to create an accountable tx M. M is paying to Bob after timelock+Bob sig or
is paying to transaction success_penalty P
with Will sig + Bob sig. Success_penalty P will have 2 inputs, one from M
and from J the justice tx than Bob has given
to Will. J is spending Alice's revoked commitment N.

So this slashing protocol should avoid Bob making false claim, because you
need a revoked broadcast to enable the claim
and at same time we use a justice tx output as a proof than Will have done
its monitoring+punishment job. Will shouldn't
learn commitment balance if there is no channel breach and Alice and Bob
wouldn't be able to collude against Will, if
watchtower have a penalty tx on Alice non-revoked commitment tx, that's her
concern.

So topology would be:

to_Bob
/
X <---------- N <--------- J
^ ^
\ \
Y <--------------- M <---------- P - to_Will
\
to_Bob

Main idea of the protocol is to use transactions topology of a first
contract as proofs for a subsidiary contract.

I'm quite sure it's insecure, just quick ideas, any thoughts ?

(but would be really cool to have one accountable protocol to both
watchtower and pay-to-open use cases to save
engineering costs)

Cheers,

Antoine

Le mar. 17 déc. 2019 à 16:08, Ethan Heilman <eth3rs at gmail.com> a écrit :

> From where I'm sitting the fact that OP_CAT allows people to build
> more powerful constructions in Bitcoin without introducing additional
> complexity at the consensus layer is a positive not a negative. Using
> OP_CAT or OP_SUBSTRING to enforce ECDSA nonce reuse is a very powerful
> protocol tool for enforcing fairness in layer two protocols.
>
> On Tue, Dec 17, 2019 at 11:27 AM ZmnSCPxj via Lightning-dev
> <lightning-dev at lists.linuxfoundation.org> wrote:
> >
> > Good morning t-bast,
> >
> > Further, we can enforce that RBF is signalled for every spend of the
> output by:
> >
> > <0> OP_CHECKSEQUENCEVERIFY OP_DROP <R> OP_SWAP OP_CAT <ACINQ>
> OP_CHECKSIG
> >
> > Requiring that RBF is signalled gives a little more assurance.
> > Suppose ACINQ becomes evil and double-spends the output.
> > The transaction that is posted in the mempool must be marked by RBF due
> to the `OP_CHECKSEQUENCEVERIFY` opcode, since `nSequence` also doubles as
> RBF opt-in.
> > Then anyone who notices the double-spend can RBF the double-spending
> transaction to themselves rather than ACINQ.
> > This also further publishes ACINQ private key, until the winning
> transaction has an `OP_RETURN` output that pays the entire value as fees
> and nobody can RBF it further.
> >
> > This is a minor increase in the assurability of the construction, by
> making any output that is double-spent directly revocable in favor of the
> miners.
> > Again, it requires `OP_CAT`, which is a very dangerous opcode, allowing
> such powerful constructions.
> >
> > Regards,
> > ZmnSCPxj
> >
> >
> > > Thanks a lot David for the suggestion and pointers, that's a really
> interesting solution.
> > > I will dive into that in-depth, it could be very useful for many
> layer-2 constructions.
> > >
> > > Thanks ZmnSCPxj as well for the quick feedback and the `OP_CAT`
> construction,
> > > a lot of cool tricks coming up once (if?) we have such tools in the
> future ;)
> > >
> > > Le mar. 17 déc. 2019 à 16:14, ZmnSCPxj <ZmnSCPxj at protonmail.com> a
> écrit :
> > >
> > > > Good morning David, t-bast, and all,
> > > >
> > > > > I'm not aware of any way to currently force single-show signatures
> in
> > > > > Bitcoin, so this is pretty theoretical. Also, single-show
> signatures
> > > > > add a lot of fragility to any setup and make useful features like
> RBF
> > > > > fee bumping unavailable.
> > > >
> > > > With `OP_CAT`, we can enforce that a particular `R` is used, which
> allows to implement single-show signatures.
> > > >
> > > > # Assuming signatures are the concatenation of (R,s)
> > > > <R> OP_SWAP OP_CAT <ACINQ> OP_CHECKSIG
> > > >
> > > > The above would then feed `s` only on the witness stack.
> > > >
> > > > Regards,
> > > > ZmnSCPxj
> >
> >
> > _______________________________________________
> > Lightning-dev mailing list
> > Lightning-dev at lists.linuxfoundation.org
> > https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
> _______________________________________________
> Lightning-dev mailing list
> Lightning-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20191217/52ad7f11/attachment.html>;

📅 Original date posted:2019-12-09 📝 Original message: ...

2023-06-09T14:57:37+02:00

In reply to nevent1q…0dkk
_________________________

📅 Original date posted:2019-12-09
📝 Original message:
Time-Dilation Attacks on Offchain Protocols
===================================

Lightning works on reversing the double-spend problem to a private
state between parties instead of being a public issue verified by every
network peer. The security model is based on revocation of previous
states and in case of broadcast of any of them, being aware of it to
generate justice transactions to claim misbehaving peer onchain outputs
before contest period expiration. This period is driven by the blockchain
which is here the system clock.

Eclipse attacks's end-goal is to monopolize a victim's incoming and
outgoing connections, by this way isolating a node from the rest of its
peers in the network. A successful Eclipse attacks lets the attacker
filter the victim's view of the blockchain, i.e he controls transactions
and blocks announcements [0].

Every LN node must be tied to a bitcoin full-node or light-client to
verify independently channels opening/closing, HTLCs expiration and
previous/latest state broadcast. To operate securely, the view of the
blockchain must be up-to-date with the one shared with the rest of the
network. By considering Eclipse attacks on the base layer, this assumption
can be broken.

First scenario : Targeting the CSV security delay
--------------------------------------------------------------

Alice and Mallory are LN peers with a channel opened at state N. They
use a CSV of 144 blocks as a security parameter for contestation period.
Mallory is able to identify Alice full-node and start to eclipse it.
When done, it keeps announcing blocks to Alice node but delaying them by
2min. Given a variance of 10min, after 6 blocks, Mallory will have a
height ahead of Alice of 1, after 24 blocks, a lead of 4, after 144,
a lead of 24, after 1008, a lead of 168.

After maintaining the eclipse for a week, Mallory will have more than a
day of height advance on Alice view of blockchain. The difference being
superior at the CSV timelock, Mallory can broadcast a previous
commitment transaction at state N - 10 with a balance far more favorable
than the legit one at height H, the synchronized height with the rest
of the network.

At revoked commitment transaction broadcast, Alice is slow down at
height H - 168. At H+144, Mallory can unlock its funds out of the
commitment transaction outputs and by so closing the contestation period
while Alice is still stuck at H-24. When Alice learn about revoked
broadcast at H, it's already too late. Mallory may have stopped the
Eclipse attack after H+144, or he may pursue the attack on Alice because
of targeting multiple of her channels in parallel.

Second scenario : Targeting the per-hop CLTV-delta
-------------------------------------------------------------------

Alice, Bob and Caroll are LN peers with channel Alice-Bob and Bob-Caroll.
Bob enforce a cltv_delta of 12 blocks on incoming HTLCs. Alice and Caroll
are both malicious and start to eclipse Alice full-node until they gain a
lead of 15 blocks on Alice.

At height N, Alice route a payment E to Caroll through Bob with a base
delta of 24 blocks. On channel AB, HTLC will expire at height H+24, on
channel BC, it will expire at height H+12 while Alice ticking herself
at height H-15.

When real-network blockchain height reaches H+24, Caroll provides
preimage P to Bob and following protocol rules she gets a new
commitment transaction with balance increased of HTLC E. At same time,
Alice broadcast unilaterally commitment transaction for AB and claim
back HTLC E with a HTLC-timeout transaction as its nLockTime is already
final. Bob wrongly clocking at height H+9, HTLC on channel BC won't have
been timeout by him and provided preimage is now useless as HTLC as
already claimed back on mainnet blockchain.

Attack difficulty
-------------------

Following Eclipse attack paper publication, multiple counter-measures
have been implemented [1], [2]. Even if it's far harder, this kind of
attacks may still be possible for an off-path attacker. Including recent
changes, research should be done to ascertain it. Beyond, it still
widely feasible for attackers controlling key infrastructure between
the victim and the network [3]. A simple Tier 3 ISP doing deep packet
inspection and delaying your blocks may be able to practice this class
of attacks.

The case of LN nodes using light clients, like BIP157 or Electrum, as a
backend should be specially considered. Given the low number of servers
providing these services today it should be trivial for an attacker to run
swarm of them and from then control blockchain view of this class of LN
nodes.

Another difficulty of the attack, is to map the LN node to its full-node.
This can range from being trivial if both run in clear with same ipv4
address. It would be interesting to scan both networks and see how many
nodes pair are in this case. Learning the mapping can still be doable if
they are using an anonymous network like Tor with same exit node base on
message timing.

Further inter-layer mapping techniques could be developped like funding
transaction broadcast and seeing its propagation on the base layer. Or
knowledge of onchain utxo graph leaked by addressed reused to fund
channels.

On the LN-side, depending of the scenario, cost of the attack ranges
between opening one or two channels and paying the related onchain fees.
That being said, an attacker can also target victim-initiated channels
and costs would be reduced only to operating LN nodes.

Onchain counter-measures
-----------------------------------

Warnings could be triggered by full-node when the block issuance rate
becomes weird but first it's hard to dissociate weirdness from edges of
block variance and secondly the algo being public it should be easy for
an attacker to stay under the radar by choosing the right announcement
delay.

Raising alarms based on nTime of block headers being to far in the past
compare to local clock wouldn't make sense due to IBD.

A practical solution would be to have multiple bitcoin full-nodes
with multi-homing and doing reconciliation of blockchain views every
N hour/minute. This kind of method, already deployed by some bitcoin
infrastructures, would raise attack difficulty for off-path attackers
but wouldn't counter in-path attackers. Nevertheless, it would already
be a good step, the issue is the current absent of implementing this
in open-source software for hobbyists.

A defense in depth would require to have multiple data links, like
receiving headers from space/radio or tunneling through
some other protocols [4].

Even learning discrepancies between your local view of the blockchain
and the mainnet one, the right move to do isn't clear as an automatic
system may be triggered by false positives to halt operation of your LN
node, a human intervention to double-check may seem preferable. And
it's really likely the attacker control you ability of transactions
on the base layer. BIP324 may help there.

Offchain counter-measures
-----------------------------------

Some LN errors messages may be triggered at abnormal rate like
`expiry_too_soon` due to victim using a HTLC base in the past and may
be used to guess oddities.

A measure orthogonal to running multiple bitcoin full-nodes should be
to have multiples watchtowers running their own blocks provider (full-node
or light clients). Assuming attacker don't control your connection to them,
if at least one of them isn't eclipsed, it should be able to time-out HTLC/
justice revoked transaction efficiently.

Another option would be to use the control plane as a safety mechanism.
When a LN node learns a channel_announcement to far in the future it
would ask to this LN node, few next headers through this communication
channel and connect these headers to its full-node. Based on this
information, full-node may trigger alarms more accurately. This mechanism
would work assuming one of your gossiping LN node is honest. It may ask
for fine-tuning to avoid there too false-positives but it seems an
interesting topic of research to use L2 information to correct L1 blockchain
view and even further to use L2 communications channels as an emergency
transaction broadcast.

Further research could be lead to investigate attacks combining eclipsing
victim
view of both layer, that's said the LN one may seem harder to take on as
nodes
have persistent identities.

Eclipse attacks were already known to be very bad, offchain protocols
relying on time for their security model make them worst at it lower the bar
to exploit them from being a miner to being party to an offchain contract.

After talking with LN implementations teams, they don't think funds are at
risks,
given than light clients have low-value channels right now and it's not
worthy the
attack setup, but they acknowledge the issue on the long term for
processing nodes.

Thanks to Gleb Naumenko for fruitful discussions/review.

Cheers

[0] https://eprint.iacr.org/2015/263.pdf

[1] https://github.com/bitcoin/bitcoin/pull/9037

[2] https://github.com/bitcoin/bitcoin/pull/8282

[3] https://erebus-attack.comp.nus.edu.sg/

[4] https://github.com/bitcoin/bitcoin/pull/16834
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20191209/cd6947dc/attachment.html>;

📅 Original date posted:2022-12-01 📝 Original message:Hi ...

2023-06-08T01:17:11+02:00

In reply to nevent1q…lde4
_________________________

📅 Original date posted:2022-12-01
📝 Original message:Hi Daniel,

>From my understanding of GAP600, you're operating a zero-conf risk analysis
business, which is integrated and leveraged by payment processors/liquidity
providers and merchants. A deployment of fullrbf by enough full-node
operators and a subset of the mining hashrate would lower the cost of
double-spend attack by lamda users, therefore increasing the risk exposure
of your users. This increased risk exposure could lead you to alter the
acceptance of incoming zero-conf transactions, AFAICT in a similar
reasoning as exposed by Bitrefill earlier this year [0].

About the statistics you're asking for considerations, few further
questions, on those 1.5M transactions per month, a) how many are
Bitcoin-only (as I understand to be multi-cryptocurrencies), b) how many
are excluded from zeroconf due to factors like RBF, long-chain of
unconfirmed ancestors or too high-value and c) what has been the average
feerate (assuming a standard size of 200 bytes) ?

My personal position on fullrbf is still the same as expressed in #26525
[1]. As a community, I think we still don't have conceptual consensus on
deploying full-rbf, neither to remove it. In the direction of removing the
current option from Bitcoin Core, I think the prerequisite to address are
the qualification of enough economic flows at risk and the presence of a
sizable loss in miners income. Beyond that, I think there is still the open
question if we (we, as the Bitcoin protocol development community, with all
its stakeholders) should restrain user choice in policy settings in the
name of preserving mining income and established use-case stability.

To recall, the original technical motivation of this option, and the wider
smoother deployment was to address a DoS vector affecting another class of
use-case: multi-party transactions like coinjoin and contracting protocols
like Lightning [2] [3]. All of them expect to generate economic flows and
corresponding mining income. Since then, alternative paths to solve this
DoS vector have been devised, all with their own trade-offs and conceptual
issues [4] [5].

Best,
Antoine

[0]
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-October/021070.html
[1] https://github.com/bitcoin/bitcoin/pull/26525#issuecomment-1319499006
[2]
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-June/020557.html
[3]
https://lists.linuxfoundation.org/pipermail/lightning-dev/2021-May/003033.html
[4]
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-October/021135.html
[5]
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-November/021144.html

Le jeu. 1 déc. 2022 à 07:32, Daniel Lipshitz via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> a écrit :

> HI All
>
> I am the CEO of GAP600. We guarantee zero confirmed Bitcoin and other
> crypto transactions, BTC is a primary part of our business. Our guarantee
> enables our customers to recognise zero-conf deposits. We reimburse our
> clients value of the trx should we get it wrong and a transaction we
> confirmed gets double spent.
>
> Should full RBF become default enabled and significantly adopted this
> would have a major impact on the capacity to accept zerof confs on mainnet.
> With the end result being this use case will be forced to move to a
> different chain, with lightning being just another option.
>
> I wanted to share some statistics about how significant this use case is.
> GAP600 clients are primarily payment processors and non custodial
> liquidity providers; you can see some of our clients on our site
> www.gap600.com. There are also merchants who have developed their own
> tools so GAP600 statistics are only a subset of the full use case.
>
> I do not know of any wallet, exchange or custodian who accepts zero conf
> without having some sort of solution in place. The market seems to be fully
> aware of the risks of zero-conf. The opt-RBF seems to be a solution which
> gives a clear free choice for actors.
>
> Statistics for consideration as a sample of the zero conf use case -
>
>
> 1. As of end of Nov 2022 - GAP600 has processed i.e responded to circa
> 15M transactions
> 2. These transactions have a cumulative value of 2.3B USD value.
> 3. We currently are seeing circa 1.5M transactions queired per month.
>
>
> It's a sizable amount of trxs on mainet and we are by no means the full
> market of platforms accepting zero-conf. I realise there are other
> considerations which BTC has, I would urge you to take into account the
> major risk being placed on this significant market share when deciding to
> make this feature default enabled and encouraging full adoption.
>
> Thank you for your consideration
> Daniel
> ________________________________
>
> Daniel Lipshitz
> GAP600| www.gap600.com
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20221201/ef417993/attachment-0001.html>;

📅 Original date posted:2022-11-02 📝 Original message:Hi ...

2023-06-08T01:16:16+02:00

In reply to nevent1q…lf7v
_________________________

📅 Original date posted:2022-11-02
📝 Original message:Hi Suhas,

>From my understanding, the main crux of the reasoning exposed in your post
would be to solidify the transaction-relay paradigm we have been following
during the last years, e.g introducing the carve-out rule specifically for
lightning commitment transactions, or more recently version=3 transactions.
I think this paradigm could be described summarly as "to each use-case
belongs a set of transaction-relay policy rules". Some of this set of rules
could aim to non-replacement guarantees to the consumers of transactions
signaling under this regime (e.g zeroconf). Another set of rules could
provide a high-guarantee that a transaction would always get to a miner, no
matter what the state of node's mempools on the network (e.g "maximal rbf"
for contracting protocols).

First, coming out of my mind, we would have to consider isolation between
each set of policy rules, ensuring the signaling mechanism cannot be abused
by an attacker to create a new pinning vector. E.g, a hypothetical concern
could be BIP125 rules interfering with version=3 policy to block the
replacement of better ancestor feerate packages. Further, for each set of
policy rules arises the question of internal consistency, again an attacker
could abuse them to pin transactions
propagation. I think an earlier version of version=3 was suffering from
this concern of not scoping potential "junk" ancestors. None of those
issues are unsolvable, however we should be well-aware of the
non-negligeable design complexity encumbered by transaction-relay protocol
developers to achieve the correct goal. There is not only a need to ensure
careful policy rules security analysis, but further to communicate well
their usage to second-layers and wallets developers (a task far from easy
with all the confusions contained by current BIP125).

Now, in the evaluation process of a set of policy rules soundness are
proposed a few reasoning heuristics: namely that it shouldn't interfere
sensibly with a anti-DoS mempool acceptance algorithm, or shouldn't
interfere with other protocols on the network, or counter the interests of
miners or node operators. I hold the belief the latest question could be
the one raising the most concerns. Browsing in the history of Bitcoin Core,
I think one of the design goals aimed for has always been to level the
playing field between miners, e.g BIP152 improving block transfer latency
to reduce orphan rate. Following this principle, we might wonder if our
transaction-relay network should guarantee some equal access to transaction
information to all the miners.

In the present case of a non-replacement policy regime, we could see the
following situation to arise, on one side miners deploying private
transaction-relay communication channels or API to capture higher fees
income from non-standard transactions. On the other-side, transaction
issuers or consumers bypass the standard transaction-relay policy rules.
Bypass could be motivated by either a zeroconf service double-spend, or
faster confirmation of a collaborative transaction. E.g, to reuse the
example of unconfirmed transaction chaining, where the sender commit to
non-replacement by opting out from the RBF flag, this commitment could be
reevaluated in the light of changing network mempools congestion, or
liquidity preferences (e.g the quick need to open LN routing channels). The
sender could leverage such hypothetical private transaction-relay
communication channels to revoke its non-replacement commitment. Therefore
discrepancies between a set of policy rules design and miners incentives
sounds to lead to informational asymmetries, harmful for the long-term
decentralization of the mining ecosystem. Of course, miner incomes
asymmetries due to edge in transaction flows access might not be weighted
as serious today, in a world where transaction fees contribute to most of
the block reward, this is far more worrying!

Of course, one position could be to estimate that miner centralization is
beyond the scope of responsibility of the Bitcoin Core project. Or at least
as a result of lightweighted risks.

Such discrepancy between a set of policy rules design and miners incentives
could also lead to hidden security risks for second-layers. As we see more
security assumptions made on policy rules extension, e.g version=3, a
lightning channel counterparty could have a competing interest to forge a
raw package suiting better incentives, and as such nullify the security
advantage expected. This could be seen as a loose concern, however the last
time we have seen an actor deliberately providing non-standard transactions
to a miner to break second-layers was yesterday [0]!. From observing other
cryptocurrencies spaces, such "MEV-style" attacks could be more and more
concerning [1]. I don't think we should assume miners to behave as "network
gentlemen", in a world where mining can be anonymous, permissionless and
censorship-resistant (e.g Stratum V2 giving back template construction to
miners operators rather than pools).

According to me, one of the harder problem we're seeing with this fullrbf
discussion is the lack of a consistent, grounded and well-understood miner
incentive model, where not only block template construction but also
transaction collection and replacement strategies are analyzed, and against
which we could simulate the efficiency of a policy. Assuming we would have
such a model, rather than qualify a policy rule as incentive-compatible in
a binary fashion, we could evaluate them on a scale, and agree on when
they're satisfying enough in face of technical complexity, validation
resources, margin of adversarial exploitation, or whatever other relevant
criteria.

Answering a few other points raised in this post, what appears to me
obscure is the qualification that fullrbf doesn't solve the DoS issues for
contracting protocols (e..g coinjoin/dual-funded lightning). If I can
understand, it's on the ground that the imperfections of BIP125 underscore
only the direct conflict feerate. It should be remembered that allowing
replacement without considering the opting flag would be already an
improvement against the DoS attack, as the attack would have to offer a
more compelling feerate to maintain the pin. Improvements of BIP125 can
happen on the top, but solving the opt-out double-spend issue sounds to me
a prerequisite.

Beyond that, I think few questions are laid out on the conceptual soundness
of v3 transaction policy w.r.t concerns raised about fullrbf today. In my
opinion, I'm sadly with most of them, especially that miners might earn
more revenue if we allowed multiple descendant v3 transactions and the
unenforceable promise for the recipient of such package to not add more
high-value children, I've echoed those concerns earlier in the review of
nVersion=3 proposal [2]. We might have to swallow the bullet for now, and
be okay as lightning developers and operators that there is only a social
inertia of the miners and lack of reliable communication channels towards
them by an adversarial counterparty to offer security [3]. Additionally, I
think it would be acceptable to have an option to disable v3 transaction
policy, an operator could be willing to reduce the CPU/memory DoS surface
of its node from partaking to any package relay. Even if it comes at the
loss of a better view of blockspace demand and downgrades its
fee-estimation, I think we should give the maximum flexibility to operators
in choosing their risk model.

To put it in a nutshell, if we would like to pursue further in the paradigm
that "to each use-case belongs its set of policy rules" (as long as they
don't introduce any harm for the network stakeholders), I believe we would
be more grounded with a better quantitative understanding of so-called
"miners incentives". I'm still wondering if it's realistic to deploy policy
rules that are not sustainable in face of long-term mining dynamics.

Best,
Antoine

[0] https://github.com/lightningnetwork/lnd/issues/7096

[1] On risks of introducing miner harvesting attacks, especially when you
consider implications on lightning-style constructions
https://lists.linuxfoundation.org/pipermail/lightning-dev/2020-February/002569.html
and
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-November/019615.html

[2]
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-September/020939.html

"If you're a miner and you receive a non-V3, second descendant of an
unconfirmed V3 transaction, if the offered fee is in the top mempool
backlog, I think you would have an interest to accept such a transaction.

So I'm not sure if those two rules are compatible with miners incentives..."

[3] This wonders if we should look forward in the future to lock in the
CPFP weight of a Lightning commitment with some new consensus semantic, or
leveraging any covenant magic, cf.
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-March/020122.html
and
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-October/020991.html

Le lun. 31 oct. 2022 à 11:02, Suhas Daftuar via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> a écrit :

> AJ,
>
> Thanks for the thoughtful post. I think your observations about how we
> view mempool policy in the Bitcoin Core project, and how that seems to be
> changing in the discussions around `-mempoolfullrbf`, are on-point and
> provide a helpful baseline for considering future policy changes.
>
> For a long time I viewed fullrbf as an eventuality and I considered myself
> to be philosophically supportive of the idea. However, after giving this
> issue some thought in the past few weeks, I am reversing my thinking on
> this. Concretely, I will argue that we should continue to maintain a relay
> policy where replacements are rejected for transactions that don't opt-in
> to RBF (as described in BIP 125), and moreover, that we should remove the
> `-mempoolfullrbf` flag from Bitcoin Core’s latest release candidate and not
> plan to release software with that flag, unless (or until) circumstances
> change on the network, which I'll discuss below.
>
> This is, of course, a nuanced topic, and among the considerations is a
> philosophy of how to think about the relay policy and configuration options
> that we make available in Bitcoin Core (a consideration that is perhaps
> unique to that project, but I think relevant for this mailing list).
>
> I'll start with some technical issues regarding the benefits of enabling
> fullrbf on the network. In the current BIP 125 regime, every time a
> transaction is created, a choice is made whether to subject the transaction
> to BIP 125’s RBF rules or not (based on the sequence values of the
> inputs). So given that users can already opt-in to RBF, the benefit of a
> “fullrbf” network policy would be if, somehow, RBF users were still denied
> the benefits of RBF due to the existence of other transactions that don’t
> opt-in.
>
> Along those lines, Antoine Riard brought up[1] a DoS vector that is
> available to someone who wants to interfere with multi-party funded
> transactions, and suggested that fullrbf would eliminate the problem.
> After exploring that question again in this thread (thanks to Greg Sanders
> for clarifying this to me), I understand that the issue is around ensuring
> that a multiparty (coinjoin-type) protocol is able to make eventual
> progress, by having a candidate multiparty transaction either eventually
> confirm or become conflicted with something that has been confirmed, in
> which case the double-spend information could be used to start a new
> coinjoin round with fewer participants. The concern Antoine and Greg have
> brought up is that non-rbf transactions can persist in the mempool
> ~indefinitely (at a low feerate and not subject to replacement) and
> interfere with progress being made in a coinjoin protocol.
>
> However, it seems to me that similar problems exist for such a protocol
> even in a fullrbf world, as we understand that term today. I mentioned the
> ability for rbf “pinning” to interfere with relay of the multiparty
> transaction (even if the conflicting transaction signals for RBF – a set of
> large but low feerate conflicting transactions can persist in the mempool
> and make it difficult for the coinjoin transaction from confirming, at
> least without attaching a very large fee); and as Greg mentioned in a
> followup, the BIP 125 rule to only permit 100 transactions to be removed
> from the mempool at a time during a replacement can also be used to pin a
> coinjoin protocol in the same way as a non-rbf transaction today. It seems
> to me that what these multiparty protocols actually need is some sort of
> "maximal rbf" network policy: a way to guarantee that a transaction which
> should be desirable for a miner to mine would always get to a miner and
> considered for inclusion in a block, no matter what the state of node’s
> mempools on the network.
>
> While that sounds like a reasonable thing to want on its face (and worth
> working on), it's not how opt-in RBF works today, nor is it how transaction
> relay has ever conceptually worked. We have not, thus far, been able to
> come up with a total ordering on transaction desirability. Moreover, due
> to all the DoS issues that exist with transaction relay, there are plenty
> of seemingly legitimate ways to construct transactions that would not relay
> well on the network. Relay has only ever been a best-efforts concept,
> where we carve out a small subset of the entire transaction universe for
> which we try to optimize propagation. The idea behind this approach is
> that if every use case we can come up with has some way to achieve its
> goals using transactions that should (eventually) be able to relay, then
> users wouldn’t have much demand for transactions that would deviate from
> the supported policies, and we therefore shouldn’t need to worry too much
> about incentive compatibility concerns when it comes to transaction types
> that wouldn’t relay at all, even if they are high feerate. (And when those
> situations arise where the standard transactions do not accommodate some
> needed use case, developers typically work to define a policy that is
> compatible with our anti-DoS goals to support such use cases, such as with
> the recent proposal for version=3 transactions [2].)
>
> BIP 125's RBF rules themselves were an effort to carve out just a subset
> of situations where a transaction should evict conflicting ones -- it was
> not a design that anyone thought would ensure that all replacements which
> "should" be mined would always propagate. And I don't believe that we know
> how to design policy rules that would achieve the goals of this kind of
> multiparty protocol in a DoS resistant way, today. Along those lines, I
> would point out that even the BIP 125 design itself is not entirely
> incentive compatible, in that it is possible to construct a replacement
> transaction that would evict transactions which would be preferable to be
> included in a block! [3] (This has been known for years, but fixing this
> has proven difficult, and the only way to fix it that I’m aware of would be
> to make BIP 125 RBF even more restrictive than it is today. I do think this
> is something that needs to be worked on.)
>
> Given the limitations of RBF as we have it today, it appears to be
> incorrect that a fullrbf network policy would solve the problems Antoine
> raised. And so absent any other examples, it does not seem to me that
> fullrbf solves any problems for RBF users, who are already free to choose
> to subject their transactions to BIP 125’s RBF policy. From this
> perspective, "enabling fullrbf" is really just taking away user choice to
> opt a transaction into a non-replacement policy regime.
>
> I think we should ask, then, whether it is reasonable on its face that
> users might want to opt-in to a non-replacement policy? Or in other words,
> is it reasonable for a user to mark a transaction as non-replaceable and
> have that indication be enforced by the network? Note that these are two
> different questions: you could imagine a world where fullrbf is a dominant
> policy, but users still use the BIP 125 signaling method to indicate, in an
> unenforced way, their intention to not replace a transaction. This might
> give useful information to the network or the recipient for how to interact
> with such a transaction.
>
> And I think that it's entirely possible that users would continue to use
> the BIP 125 signaling to indicate that they do not intend to replace a
> transaction. For better or worse, this might be because zeroconf services
> continue to differentiate their behavior based on such a signal (possibly
> in conjunction with other factors), or it could be because there are other
> behaviors that could be utilized more effectively if the transaction
> originator has made such a signal, such as the recipient chaining an
> unconfirmed transaction as a way to bump the fee (CPFP) [4].
>
> If it were to be the case that users continued to use BIP 125-style
> signaling to indicate that they do not plan to replace a transaction, would
> that be harmful to the network? This is not something we can stop in our
> policy rules (short of censoring such transactions, an obviously bad
> idea). I think network actors can always do things that we might think are
> harmful for the network, but that doesn’t mean that there are no legitimate
> use cases for the tools that such actors might be using. Just because
> someone might use some policy to adopt a zeroconf model, doesn’t mean that
> others aren’t using the same policy to achieve benign ends (such as better
> CPFP behavior).
>
> Moreover, while users might attempt to exploit services that offer
> zeroconf or other differentiated behavior to non-replacement signaling
> transactions, they also might not -- I think predicting user behavior in
> this way (and specifically predicting the complexities of what a business
> might do and whether users might try to subvert it) is beyond the scope of
> what we can do as protocol developers. Instead, I think we can try to
> answer a different question: if a group of users were to want the ability
> to opt-in to a non-replacement policy regime, is that a technically sound
> option for us to have on the network and enforce in software?
> Specifically, does that interfere with having a sensible anti-DoS mempool
> acceptance algorithm, or interfere with other protocols on the network, or
> necessarily run counter to the interests of miners or node operators?
>
> And I think the answer to that question, in looking at the difference
> between opt-in RBF and fullrbf, is no: offering the ability to opt-in to a
> non-replacement regime for transactions doesn't introduce any fundamental
> issues with software or network policy or other protocols. In a world
> where we only had fullrbf, I could imagine at some point down the road
> proposing a non-replacement signal myself, because the complexities around
> transaction chains (and pinning) are more complex for the RBF case than for
> the non-RBF case (and BIP 125 is not always incentive compatible to begin
> with!). Conceptually, this is no different to me than the version=3
> transaction policy proposal that has been advancing, if we think of it as a
> special set of restrictions on transactions designed to accommodate a
> particular use case.
>
> Philosophically, I think we should be looking to add non-interfering use
> cases to what the network supports.
>
> To those who argue for making fullrbf a default policy on the network (or
> even just offering a flag for users to enable fullrbf), I pose this
> hypothetical: suppose we deploy the v3 transaction policy proposal (which I
> hope will happen in the near future). That policy would restrict the ways
> that outputs of a v3 transaction can be spent while the transaction is
> unconfirmed, including by limiting the number and size of descendants that
> such a transaction can have, and limiting the types of unconfirmed
> ancestors that can be included. Suppose in a few years someone proposes
> that we add a "-disable_v3_transaction_enforcement" flag to our software,
> to let users decide to turn off those policy restrictions and treat v3
> transactions the same as v2, for all the same reasons that could be argued
> today with fullrbf: miners might earn more revenue if we allowed multiple
> descendant v3 transactions; it's illogical for the recipient of a v3
> transaction to believe what is a fundamentally unenforceable promise of a
> sender to not issue more high value children that descend from an
> unconfirmed transaction; it's inappropriate for Bitcoin Core to dictate
> policy on the network and we should honor user choice to turn off that flag
> if that’s what users want; if users are relying on v3’s policy restrictions
> for security then that is an unstable model and we should assume it will
> get broken[5].
>
> It’s obvious to me that adding a flag to disable v3 policy would be
> subversive to making the lightning use case for v3 transactions work. And
> so my response to such a hypothetical proposal would be to argue that no,
> we should not enable users to disable this policy, because as long as that
> policy is just optional and working for those who want it, it shouldn’t
> harm anyone that we offer a tighter set of rules for a particular use
> case. Adding a way to bypass those rules is just trying to break someone
> else’s use case, not trying to add a new one. We should not wield
> "incentive compatibility" as a bludgeon for breaking things that appear to
> be working and not causing others harm.
>
> I think this is exactly what is happening with fullrbf.
>
> In comparing v3 transaction policy with opting out of transaction
> replacement, there is of course one significant difference that I have
> ignored thus far: I think the real difference is an opinion about whether
> non-replacement transactions that are being used today are, overall, bad
> for Bitcoin, and whether lightning’s use of v3 transactions in the future
> would be bad for Bitcoin. If you think that zeroconf is unequivocally bad,
> and that no one will be able to plausibly construct a case that lightning
> is bad, then that qualitative judgment might sway you to not worrying about
> the philosophical issues I've raised above, because these situations can be
> distinguished.
>
> However I am not personally willing to say that I think, overall,
> non-rbf-signaling transactions in use on the network today are bad for
> Bitcoin (or that fullrbf is definitely good – BIP 125’s rbf rules are
> something we’ve been trying to improve upon for years, with little
> success). Nor am I convinced that someone couldn’t put together a cogent
> argument for lightning being bad for Bitcoin, because of its reliance on
> relay policies that are difficult to design and impossible to guarantee as
> part of its security model. So I choose instead to merely make a judgment
> that seems more factually verifiable, which is that non-replacement is a
> policy widely in use on the network today, and we largely don't have reason
> to think (as far as I know!) that the network is seeing a lot of
> transactions that would violate that policy.
>
> If it did turn out that users were commonly signaling non-replacement, but
> then signing and trying to relay doublespends, then I think that would be a
> very good reason for Bitcoin Core to adopt fullrbf to reflect the reality
> of what is happening. In the meantime, I think it makes more sense to say
> that because we have BIP 125, there seems to be no need for users to signal
> one way and behave another, and therefore there is no need to offer
> software that might break a policy that is working well for some users.
> Other software projects might choose differently, and it is after all a
> permissionless network, so if this is in fact an unstable equilibrium that
> will not last, then presumably someday it will be apparent it is not
> working and we’ll abandon it. But I think the philosophy of transaction
> relay policy in Bitcoin Core should be to support disparate use cases in
> order to try to make everything work better, rather than break things
> prematurely because we guess others will break them eventually anyway.
>
> For those that have read this long email and still favor a fullrbf network
> policy (or even just the ability for users to be able to turn on fullrbf
> for themselves), I’d ask for thoughts on the following questions, which
> have guided my thinking on this:
>
> Does fullrbf offer any benefits other than breaking zeroconf business
> practices? If so, what are they?
>
> Is it reasonable to enforce BIP 125's rbf rules on all transactions, if
> those rules themselves are not always incentive compatible?
>
> If someone were to propose a command line option that breaks v3
> transaction relay in the future, is there a logical basis for opposing that
> which is consistent with moving towards fullrbf now?
>
> Cheers,
> Suhas
>
>
> [1]
> https://lists.linuxfoundation.org/pipermail/lightning-dev/2021-May/003033.html
>
> [2]
> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-September/020937.html
>
> [3] This is because under the BIP 125 rules, the feerate of the
> replacement transaction is not compared to the individual feerates of all
> transactions being evicted – we just compare feerates with the transactions
> that are directly in conflict (and not their descendants). So it’s possible
> for a transaction that would evict 2 or more transactions to have a higher
> feerate than the direct conflicts, and higher total fee than the set being
> evicted, but have a lower feerate (eg if it is larger) than that of some
> subset of the set of transactions being evicted.
>
> [4] Chaining unconfirmed transactions when the sender might RBF the
> parent is far riskier than if the sender indicates they don't plan to do so
> (chaining onto an RBF transaction creates pinning issues for the sender,
> and risks having the child wiped out if the parent is replaced), so I think
> this is a concrete reason why signaling that a transaction won’t be
> replaced could be useful.
>
> [5] This is a subtle point. I don’t think v3 transactions create an
> unreasonable security assumption for the use case it is being designed for.
> However, I don’t think anyone could rule out the possibility that someone
> could adopt a usage pattern for v3 transactions that subverts the intent of
> this policy. For example, if users started using v3 transactions for all
> their payments, then the limitations on the number of descendants could
> directly interfere with CPFP by a recipient, and someone could argue that
> we should break the policy in order to allow for this hypothetical
> behavior. I think this is a similar form of argument as saying that
> zeroconf practices + BIP 125 create an incentive to double-spend non-rbf
> signaling transactions.
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20221102/d2ff3925/attachment-0001.html>;

📅 Original date posted:2022-11-02 📝 Original message:Hi ...

2023-06-08T01:16:11+02:00

In reply to nevent1q…qxrt
_________________________

📅 Original date posted:2022-11-02
📝 Original message:Hi list,

Reading Suhas's post on mempool policy consistency rules, and the grounded
suggestion that as protocol developers we should work on special policy
rules to support each reasonable use case on the network rather to arbiter
between class of use-cases in the design of an
unified set of rules, reminded me there is another solution to solve
multi-party funding pinning rather than wide deployment of fullrbf. This
was communicated to me a while back, and it was originally dismissed
because of the privacy trade-offs (and potential slight fees overhead
cost). However, if widely adopted, they might sound acceptable to
contracting protocol developers and operators.

## The Problem: Pinning Contracting Protocols Funding Flows with Opt-out
Double-Spend

As originally laid out [0], multi-party collaborative flows
(coinjoin/dual-funding/swaps/splicing/etc), where every participant
contributes at least one input, are suffering from a low-cost and
high-success DoS vector with asymmetric damages. E.g with lightning
interactive transaction construction protocols limits of 252 inputs, 1
single input can bleed the timevalue of the remaining 251 inputs, or engage
in a MEV attack where the fee-bumping entity is lured to inflate feerate
beyond the current blockspace demand. The attack can be hidden and a
posteriori assigning blame consistently stays an open question in the lack
of a consensus mechanism between participants on the network mempools
states.

The issue lies in the fact that participants joining inputs together don't
have control, or even view, of the replacement signaling of any potential
double-spend of the other participants inputs. Indeed the opt-in fullrbf
signaling is enforced based on the nSequence field, and this one is fully
malleable by the UTXO spender. There is no current mechanism to require
replacement signaling provable to a third-party only on the knowledge of
the UTXO spents.

# The Solution: Opt-in Full-Replace-by-Fee Spent-nVersion Signaling

A new policy is specified in a new way a transaction can signal that it is
replaceable.

1. A confirmed transaction is considered to have opted in to allowing
replacement of any of its spends (or their descendants), if the last bit of
the nVersion field is set.

Rational: The future replacement status of any UTXO spend can be determined
by inspecting the nVersion, therefore protecting the collaborative
participants of a multi-party flows that the target transaction should
propagate to the miners, if the fee/feerate offered are the best ones
without opt-out based pinning. It can be required the UTXOs to have few
confirmations in case of shallow reorgs to increase DoS protection.

## Solution trade-offs

On the validation-side, there is one engineering issue, as I think there is
no access to the spent nversion fields by the mempool logic. This would
presume we add some new cache of all the confirmed UTXOs, so ~50M * 4bytes,
300 MB of additional state for policy-enforcing full-nodes. I don't know if
there is another strong drawback, even the reorg logic the replaceable
spends shouldn't be evicted if the confirmed ancestor is back to the
mempool, as mempool validity shouldn't be reevaluated before a replacement
candidate shows up. A fee penalty could be requested for nVersion-signaling
transactions to compensate for the additional state stored by full-node
operators (even if obviously they're not the ones earning the fees).

For the contracting protocols wallets, as you don't know in advance which
coins are going to be used for a collaborative flow, you're better off to
mark all your coins nVersion fields opting fullrbf. Otherwise, you will
have to go through an on-chain fee cost to change the replacement status of
the spends of your coins. However, this policy bookmarking comes as a
protocol fingerprint leak for an observer of the transaction logs. If all
the second-layers used by default, this is constituting a single anonymity
set, though it might still be the privacy gains we're harvesting from
Taproot output usage in the optimistic case (e.g in Lightning no commitment
+ HTLC transactions broadcast).

For the zeroconf operators, assuming they have access to the UTXO set, they
can inspect the receiving transactions ancestors nVersion fields, and sort
those transactions in the wider set of the replaceable ones, as they're
currently doing for BIP125 opt-in ones.

Long-term, the annoying privacy issue and the assumption that any wallet
will be a Lightning one could lead to the majority of wallets signaling RBF
for their spends. Therefore making those wallets incompatible with zeroconf
services, slowly economically outlawing them. From my perspective, though
it might be a simplification, it sounds an alternative full rbf way
forward, where rather than having miners deciding on the policy
enforcement, we let the users decide with their coins. However, this new
policy enforcement efficiency is still dependent on the existence of relay
paths and support at the endpoints that matter, the miner mempools. So in
fine we might have to realize incentive alignment with hashrate is what
matters in terms of transaction-relay rules ?

Credit to Greg Maxwell for this idea.

Cheers,
Antoine

[0]
https://lists.linuxfoundation.org/pipermail/lightning-dev/2021-May/003033.html
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20221101/7190a0df/attachment-0001.html>;

📅 Original date posted:2022-10-20 📝 Original message:> ...

2023-06-08T01:14:44+02:00

In reply to nevent1q…taq8
_________________________

📅 Original date posted:2022-10-20
📝 Original message:> There is a long list of countermeasures that can be built to reduce these
> attacks, but to be frank we've only implemented a small subset of these
and
> not had any issues, so even a lower level of security is more than fine
> today to have basically zero abuse. If issues arise we could implement
more
> of the countermeasures as appropriate to the abuse that has happened in
the
> wild.

>From reading one of your other mail, apparently 60% of Bitrefill payments
are non-rbfable on-chain transactions and as such fine for zeroconf. What
I'm wondering is, in case of a wide majority of the full-nodes supporting
full-rbf, if any incoming transaction traffic could be risk-managed
well-enough thanks to some additional countermeasures to be
zeroconf-acceptable ?

We can be technically creative here. One could think of some overlay
monitoring between zeroconf merchants, where mempooldiffs are exchanged to
observe if any acceptance candidate is double-spent inside some other
participant's mempool. Of course, the reconciliation rate would need to be
pretty high to still ensure an "instant payment" UX, though the bandwidth
overhead should be okay as we assume full-node enterprise hosts. I don't
think such functionality would be used by any full-node, it might leverage
p2p extensions but it would be some differentiated services on top of the
usual messages. This is just an idea, and the concrete 0conf acceptance
flow problem needs to be better specified.

> Fundamentally, my view is that all the UX problems related to RBF alone
are
> sufficient of an issue to hold off on rolling out these upgrades for the
> foreseeable future and think of other ways of solving the pinning issue
and
> other issues w the current policy. Might be that it's just a fundamental
> goal conflict that different people want different behavior but I remain
> optimistic for creative solutions from both sides. UX issues are soft as
> opposed to theoretical attack vectors which are hard and binary, we need
> find a way to weigh "even though it doesn't happen it can theoretically be
> hacked" against "many users find it confusing and stressful" which is not
a
> trivial assessment to do.

Seriously, solving the pinning issues for contracting protocols already
busy few of the most brilliant bitcoin developers almost full-time. If we
had straightforward and backward compatible with all classes of current
Bitcoin applications, we would go for it. Of course, it doesn't mean we
should close the problem of space exploration, and if someone can come up
with solutions offering equivalent trade-offs, I'm all to listen. This is
still an open question if we would have to allow a subset of transactions
to be full-rbf, to fully achieve the semantics of v3 transactions, or at
least if we would like to protect currently open Lightning channels. Hard
problems here.

While I'm hearing the uncertainty of an easy assessment weighting between
favoring UX issues or solving hard theoretical attacks, those latter
concerns I've been serious enough among the Lightning development community
to take it as one of the top engineering issues among all those last years.
>From my experience, pentesting in a "black-box" fashion of some subset of
LN vulnerabilities, they turn out as really practical after a few days of
hacking if you know where to hit. Moreover, it should be underscored that
the attacker incentive model between targeting a 0conf merchant like
Bitrefill and a sizable Lightning infrastructure is a bit different. On one
side, you will pocket free gift cards that are likely traceable to
real-world identities, or cancellable by calling out the issuers. On the
other side, you get a stack of free satoshis, easily fungible among all
other coins. As such, we might foresee far more exploitations against LN,
once the network has caught up in terms of volume and stakes to compare
with the most advanced Defi smart contract platforms in the wider
cryptocurrencies ecosystem, attracting today sophisticated attackers. Or at
least, I'm worried by such an outcome playing out for LN if we're too slow
on rolling out mitigations...

All that said, from my perspective upgrading mempool policy doesn't seem
incompatible with a parallel effort to improve the UX problems of RBF, by
automatic fee-bumping logic in a transparent way for the end-users. Like
you said, we should be all optimistic on creative solutions, and
communicate better between merchants and devs on the problem space.

Looking forward to having more interactions on these topics in the future!

Best,
Antoine

Le jeu. 20 oct. 2022 à 10:12, Sergej Kotliar <sergej at bitrefill.com> a
écrit :

>
>
> On Thu, 20 Oct 2022 at 03:37, Antoine Riard <antoine.riard at gmail.com>
> wrote:
>
>> Hi Sergej,
>>
>> Thanks for the insightful posting, especially highlighting the FX risk
>> which was far from being evident on my side!
>>
>> I don't know in details the security architecture of Bitrefill zeroconf
>> acceptance system, though from what I suppose there is at least a set of
>> full-nodes well-connected across the p2p network, on top of which some
>> mempools reconciliation is exercised
>> and zeroconf candidate sanitize against. While I believe this is a
>> far-more robust deployment against double-spend attempts, there is still
>> the ability for a sophisticated attacker to "taint" miner mempools, and
>> from then partition judiciously the transaction-relay network to game such
>> distributed mempool monitoring system. There is also the possibility of an
>> attacker using some "divide-and-conquer" transaction broadcast algorithm to
>> map Bitrefill monitoring point, though as far as I'm aware such algorithm
>> has not been discussed. I agree with all of that, easier said than done.
>>
>
> There is a long list of countermeasures that can be built to reduce these
> attacks, but to be frank we've only implemented a small subset of these and
> not had any issues, so even a lower level of security is more than fine
> today to have basically zero abuse. If issues arise we could implement more
> of the countermeasures as appropriate to the abuse that has happened in the
> wild.
>
>
>> On the efficacy of RBF, I understand the current approach of assuming
>> "manual" RBFing by power users ill UX thinking. I hope in the future to
>> have automatic fee-bumping implemented by user wallets, where a fee-bumping
>> budget and a confirmation preference are pre-defined for all payments, and
>> the fee-bumping logic "simply" enforcing the user policy, ideally based on
>> historical mempool data. True fact: we don't have such logic in consumer
>> wallets today.
>>
>
> In deed. And the vast majority of bitcoin users don't even have access to
> any RBF functionality today, so we're not even seeing gradual development
> of these things yet. I think this fact needs to be taken into account when
> designing breaking changes to bitcoin policy. Had these things been in
> place and widely used the conversation would have been much easier.
>
> Fundamentally, my view is that all the UX problems related to RBF alone
> are sufficient of an issue to hold off on rolling out these upgrades for
> the foreseeable future and think of other ways of solving the pinning issue
> and other issues w the current policy. Might be that it's just a
> fundamental goal conflict that different people want different behavior but
> I remain optimistic for creative solutions from both sides. UX issues are
> soft as opposed to theoretical attack vectors which are hard and binary, we
> need find a way to weigh "even though it doesn't happen it can
> theoretically be hacked" against "many users find it confusing and
> stressful" which is not a trivial assessment to do.
>
> All that said, I learn to converge that as a community we would be better
>> off to weigh deeper the risks/costs between 0confs applications and
>> contracting protocols in light of full-rbf.
>>
>
> In deed. And as you wrote in a different message, I agree that it's
> unfortunate that there isn't more interaction between the mailing list and
> services and companies using this stuff day-to-day. Not that it's anyone's
> fault in particular, let's try from all sides to find more ways to create
> more interaction on these topics. I've pinged a few colleagues that work on
> payments in the space and hope they will chime in more in this forum!
>
> All the best,
> Sergej
>
>
>> Le mer. 19 oct. 2022 à 10:33, Sergej Kotliar via bitcoin-dev <
>> bitcoin-dev at lists.linuxfoundation.org> a écrit :
>>
>>> Hi all,
>>>
>>> Chiming in on this thread as I feel like the real dangers of RBF as
>>> default policy aren't sufficiently elaborated here. It's not only about the
>>> zero-conf (I'll get to that) but there is an even bigger danger called the
>>> american call option, which risks endangering the entirety of BIP21 "Scan
>>> this QR code with your wallet to buy this product" model that I believe
>>> we've all come to appreciate. Specifically, in a scenario with high
>>> volatility and many transactions in the mempools (which is where RBF would
>>> come in handy), a user can make a low-fee transaction and then wait for
>>> hours, days or even longer, and see whether BTCUSD moves. If BTCUSD moves
>>> up, user can cancel his transaction and make a new - cheaper one. The
>>> biggest risk in accepting bitcoin payments is in fact not zeroconf risk
>>> (it's actually quite easily managed), it's FX risk as the merchant must
>>> commit to a certain BTCUSD rate ahead of time for a purchase. Over time
>>> some transactions lose money to FX and others earn money - that evens out
>>> in the end. But if there is an _easily accessible in the wallet_ feature to
>>> "cancel transaction" that means it will eventually get systematically
>>> abused. A risk of X% loss on many payments that's easy to systematically
>>> abuse is more scary than a rare risk of losing 100% of one occasional
>>> payment. It's already possible to execute this form of abuse with opt-in
>>> RBF, which may lead to us at some point refusing those payments (even with
>>> confirmation) or cumbersome UX to work around it, such as crediting the
>>> bitcoin to a custodial account.
>>>
>>> To compare zeroconf risk with FX risk: I think we've had one incident in
>>> 8 years of operation where a user successfully fooled our server to accept
>>> a payment that in the end didn't confirm. To successfully fool (non-RBF)
>>> zeroconf one needs to have access to mining infrastructure and probability
>>> of success is the % of hash rate controlled. This is simply due to the fact
>>> that the network currently won't propagage the replacement transaction to
>>> the miner, which is what's being discussed here. American call option risk
>>> would however be available to 100% of all users, needs nothing beyond the
>>> wallet app, and has no cost to the user - only upside.
>>>
>>> Bitrefill currently processes 1500-2000 onchain payments every day. For
>>> us, a world where bitcoin becomes de facto RBF by default, means that we
>>> would likely turn off the BIP21 model for onchain payments, instruct
>>> Bitcoin users to use Lightning or deposit onchain BTC to a custodial
>>> account that we have.
>>> This option is however not available for your typical
>>> BTCPayServer/CoinGate/Bitpay/IBEX/OpenNode et al. Would be great to hear
>>> from other merchants or payment providers how they see this new behavior
>>> and how they would counteract it.
>>>
>>> Currently Lightning is somewhere around 15% of our total bitcoin
>>> payments. This is very much not nothing, and all of us here want Lightning
>>> to grow, but I think it warrants a serious discussion on whether we want
>>> Lightning adoption to go to 100% by means of disabling on-chain commerce.
>>> For me personally it would be an easier discussion to have when Lightning
>>> is at 80%+ of all bitcoin transactions. Currently far too many bitcoin
>>> users simply don't have access to Lightning, and of those that do and hold
>>> their own keys Muun is the biggest wallet per our data, not least due to
>>> their ease-of-use which is under threat per the OP. It's hard to assess how
>>> many users would switch to Lightning in such a scenario, the communication
>>> around it would be hard. My intuition says that the majority of the current
>>> 85% of bitcoin users that pay onchain would just not use bitcoin anymore,
>>> probably shift to an alt. The benefits of Lightning are many and obvious,
>>> we don't need to limit onchain to make Lightning more appealing. As an
>>> anecdote, we did experiment with defaulting to bech32 addresses some years
>>> back. The result was that simply users of the wallets that weren't able to
>>> pay to bech32 didn't complete the purchase, no support ticket or anything,
>>> just "it didn't work 🤷‍♂️" and user moved on. We rolled it back, and later
>>> implemented a wallet selector to allow modern wallets to pay to bech32
>>> while other wallets can pay to P2SH. This type of thing is clunky, and
>>> requires a certain level of scale to be able to do, we certainly wouldn't
>>> have had the manpower for that when we were starting out. This why I'm
>>> cautious about introducing more such clunkiness vectors as they are
>>> centralizing factors.
>>>
>>> I'm well aware of the reason for this policy being suggested and the
>>> potential pinning attack vector for LN and other smart contracts, but I
>>> think these two risks/costs need to be weighed against eachother first and
>>> thoroughly discussed because the costs are non-trivial on both sides.
>>>
>>> Sidenote: On the efficacy of RBF to "unstuck" stuck transactions
>>> After interacting with users during high-fee periods I've come to not
>>> appreciate RBF as a solution to that issue. Most users (80% or so) simply
>>> don't have access to that functionality, because their wallet doesn't
>>> support it, or they use a custodial (exchange) wallet etc. Of those that
>>> have the feature - only the power users understand how RBF works, and
>>> explaining how to do RBF to a non-power-user is just too complex, for the
>>> same reason why it's complex for wallets to make sensible non-power-user UI
>>> around it. Current equilibrium is that mostly only power users have access
>>> to RBF and they know how to handle it, so things are somewhat working. But
>>> rolling this out to the broad market is something else and would likely
>>> cause more confusion.
>>> CPFP is somewhat more viable but also not perfect as it would require
>>> lots of edge case code to handle abuse vectors: What if users abuse a
>>> generous CPFP policy to unstuck past transactions or consolidate large
>>> wallets. Best is for CPFP to be done on the wallet side, not the merchant
>>> side, but there too are the same UX issues as with RBF.
>>> In the end a risk-based approach to decide on which payments are
>>> non-trivial to reverse is the easiest, taking account user experience and
>>> such. Remember that in the fiat world card payments have up to 5%
>>> chargebacks, whereas we in zero-conf bitcoin land we deal with "fewer than
>>> 1 in a million" accepted transactions successfully reversed. These days we
>>> have very few support issues related to bitcoin payments. The few that do
>>> come in are due to accidental RBF users venting frustration about waiting
>>> for their tx to confirm.
>>> "In theory, theory and practice are the same. In practice, they are not"
>>>
>>> All the best,
>>> Sergej Kotliar
>>> CEO Bitrefill.com
>>>
>>>
>>> --
>>>
>>> Sergej Kotliar
>>>
>>> CEO
>>>
>>>
>>> Twitter: @ziggamon <https://twitter.com/ziggamon>;
>>>
>>>
>>> www.bitrefill.com
>>>
>>> Twitter <https://www.twitter.com/bitrefill>; | Blog
>>> <https://www.bitrefill.com/blog/>; | Angellist
>>> <https://angel.co/bitrefill>;
>>>
>>>
>>> --
>>>
>>> Sergej Kotliar
>>>
>>> CEO
>>>
>>>
>>> Twitter: @ziggamon <https://twitter.com/ziggamon>;
>>>
>>>
>>> www.bitrefill.com
>>>
>>> Twitter <https://www.twitter.com/bitrefill>; | Blog
>>> <https://www.bitrefill.com/blog/>; | Angellist
>>> <https://angel.co/bitrefill>;
>>> _______________________________________________
>>> bitcoin-dev mailing list
>>> bitcoin-dev at lists.linuxfoundation.org
>>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>>
>>
>
> --
>
> Sergej Kotliar
>
> CEO
>
>
> Twitter: @ziggamon <https://twitter.com/ziggamon>;
>
>
> www.bitrefill.com
>
> Twitter <https://www.twitter.com/bitrefill>; | Blog
> <https://www.bitrefill.com/blog/>; | Angellist <https://angel.co/bitrefill>;
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20221020/70f554fa/attachment-0001.html>;

📅 Original date posted:2022-10-19 📝 Original message:Hi ...

2023-06-08T01:14:42+02:00

In reply to nevent1q…megv
_________________________

📅 Original date posted:2022-10-19
📝 Original message:Hi Sergej,

Thanks for the insightful posting, especially highlighting the FX risk
which was far from being evident on my side!

I don't know in details the security architecture of Bitrefill zeroconf
acceptance system, though from what I suppose there is at least a set of
full-nodes well-connected across the p2p network, on top of which some
mempools reconciliation is exercised
and zeroconf candidate sanitize against. While I believe this is a far-more
robust deployment against double-spend attempts, there is still the ability
for a sophisticated attacker to "taint" miner mempools, and from then
partition judiciously the transaction-relay network to game such
distributed mempool monitoring system. There is also the possibility of an
attacker using some "divide-and-conquer" transaction broadcast algorithm to
map Bitrefill monitoring point, though as far as I'm aware such algorithm
has not been discussed. I agree with all of that, easier said than done.

(Which let me think that such distributed mempool monitoring system should
be provide some enhanced security even in a full-rbf world, that they would
require far more resources than the average node from the p2p network as a
whole might be a counter-argument for their social acceptance, however I'm
also thinking that a robust Lightning infrastructure of the future might
require multiple mempool/transaction-relay endpoints, at least to reduce
cross-layer mapping links, though conversation for another day...).

About the FX risk itself, this is far from being isolated from 0conf, as
Lightning payments themselves might still have a time lapse between the
issuance of invoices and the settlement of the HTLC at the payee endpoint.
In fact this volatility concern is endured by anyone using Bitcoin
regularly in interface with the fiats worlds, i.e everyone excepted the
long-term store of wealth crowd. From a merchant perspective, effectively,
the options to cover themselves against this risk are simple. One could
take positions directly in traditional financial derivatives, like doing
participants in international trades, though it would require an educated
manpower on the merchant side. Or leveraging some stablecoins derivatives
system, coming with its own technical complexity and social trust hazards.
Another direction would be to clearly define the responsibility between
merchants or users, on whom is the FX risk. If it's on users, they should
be the one RBFing/CPFPing to increase the merchant address output, beyond
the fact "dynamic pricing" would be a weird UX, it would require liveliness
from the wallets until block confirmation (introducing here many
requirements of a LN wallet). If it's on the merchants, they could be the
ones CPFPing thanks to package relay, though it would come again with some
engineering complexity and overhead blockspace cost (and the first version
of package relay likely won't enable CPFP batching for concerns of
potential bandwidth/CPU DoS).

On the efficacy of RBF, I understand the current approach of assuming
"manual" RBFing by power users ill UX thinking. I hope in the future to
have automatic fee-bumping implemented by user wallets, where a fee-bumping
budget and a confirmation preference are pre-defined for all payments, and
the fee-bumping logic "simply" enforcing the user policy, ideally based on
historical mempool data. True fact: we don't have such logic in consumer
wallets today. Or at least only rudimentary in the backend of LN
implementations, and only for time-sensitive on-chain claims for now (or at
least speaking for LDK). If we take the history of browsers as a
comparison, while we might be out of the Lynx-style phase of wallets, we
might still be more in the late Netscape kind of thing than something like
Chrome today. In other words, there are many directions for improvements
for users' wallets.

All that said, I learn to converge that as a community we would be better
off to weigh deeper the risks/costs between 0confs applications and
contracting protocols in light of full-rbf.

Best,
Antoine

Le mer. 19 oct. 2022 à 10:33, Sergej Kotliar via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> a écrit :

> Hi all,
>
> Chiming in on this thread as I feel like the real dangers of RBF as
> default policy aren't sufficiently elaborated here. It's not only about the
> zero-conf (I'll get to that) but there is an even bigger danger called the
> american call option, which risks endangering the entirety of BIP21 "Scan
> this QR code with your wallet to buy this product" model that I believe
> we've all come to appreciate. Specifically, in a scenario with high
> volatility and many transactions in the mempools (which is where RBF would
> come in handy), a user can make a low-fee transaction and then wait for
> hours, days or even longer, and see whether BTCUSD moves. If BTCUSD moves
> up, user can cancel his transaction and make a new - cheaper one. The
> biggest risk in accepting bitcoin payments is in fact not zeroconf risk
> (it's actually quite easily managed), it's FX risk as the merchant must
> commit to a certain BTCUSD rate ahead of time for a purchase. Over time
> some transactions lose money to FX and others earn money - that evens out
> in the end. But if there is an _easily accessible in the wallet_ feature to
> "cancel transaction" that means it will eventually get systematically
> abused. A risk of X% loss on many payments that's easy to systematically
> abuse is more scary than a rare risk of losing 100% of one occasional
> payment. It's already possible to execute this form of abuse with opt-in
> RBF, which may lead to us at some point refusing those payments (even with
> confirmation) or cumbersome UX to work around it, such as crediting the
> bitcoin to a custodial account.
>
> To compare zeroconf risk with FX risk: I think we've had one incident in 8
> years of operation where a user successfully fooled our server to accept a
> payment that in the end didn't confirm. To successfully fool (non-RBF)
> zeroconf one needs to have access to mining infrastructure and probability
> of success is the % of hash rate controlled. This is simply due to the fact
> that the network currently won't propagage the replacement transaction to
> the miner, which is what's being discussed here. American call option risk
> would however be available to 100% of all users, needs nothing beyond the
> wallet app, and has no cost to the user - only upside.
>
> Bitrefill currently processes 1500-2000 onchain payments every day. For
> us, a world where bitcoin becomes de facto RBF by default, means that we
> would likely turn off the BIP21 model for onchain payments, instruct
> Bitcoin users to use Lightning or deposit onchain BTC to a custodial
> account that we have.
> This option is however not available for your typical
> BTCPayServer/CoinGate/Bitpay/IBEX/OpenNode et al. Would be great to hear
> from other merchants or payment providers how they see this new behavior
> and how they would counteract it.
>
> Currently Lightning is somewhere around 15% of our total bitcoin payments.
> This is very much not nothing, and all of us here want Lightning to grow,
> but I think it warrants a serious discussion on whether we want Lightning
> adoption to go to 100% by means of disabling on-chain commerce. For me
> personally it would be an easier discussion to have when Lightning is at
> 80%+ of all bitcoin transactions. Currently far too many bitcoin users
> simply don't have access to Lightning, and of those that do and hold their
> own keys Muun is the biggest wallet per our data, not least due to their
> ease-of-use which is under threat per the OP. It's hard to assess how many
> users would switch to Lightning in such a scenario, the communication
> around it would be hard. My intuition says that the majority of the current
> 85% of bitcoin users that pay onchain would just not use bitcoin anymore,
> probably shift to an alt. The benefits of Lightning are many and obvious,
> we don't need to limit onchain to make Lightning more appealing. As an
> anecdote, we did experiment with defaulting to bech32 addresses some years
> back. The result was that simply users of the wallets that weren't able to
> pay to bech32 didn't complete the purchase, no support ticket or anything,
> just "it didn't work 🤷‍♂️" and user moved on. We rolled it back, and later
> implemented a wallet selector to allow modern wallets to pay to bech32
> while other wallets can pay to P2SH. This type of thing is clunky, and
> requires a certain level of scale to be able to do, we certainly wouldn't
> have had the manpower for that when we were starting out. This why I'm
> cautious about introducing more such clunkiness vectors as they are
> centralizing factors.
>
> I'm well aware of the reason for this policy being suggested and the
> potential pinning attack vector for LN and other smart contracts, but I
> think these two risks/costs need to be weighed against eachother first and
> thoroughly discussed because the costs are non-trivial on both sides.
>
> Sidenote: On the efficacy of RBF to "unstuck" stuck transactions
> After interacting with users during high-fee periods I've come to not
> appreciate RBF as a solution to that issue. Most users (80% or so) simply
> don't have access to that functionality, because their wallet doesn't
> support it, or they use a custodial (exchange) wallet etc. Of those that
> have the feature - only the power users understand how RBF works, and
> explaining how to do RBF to a non-power-user is just too complex, for the
> same reason why it's complex for wallets to make sensible non-power-user UI
> around it. Current equilibrium is that mostly only power users have access
> to RBF and they know how to handle it, so things are somewhat working. But
> rolling this out to the broad market is something else and would likely
> cause more confusion.
> CPFP is somewhat more viable but also not perfect as it would require lots
> of edge case code to handle abuse vectors: What if users abuse a generous
> CPFP policy to unstuck past transactions or consolidate large wallets. Best
> is for CPFP to be done on the wallet side, not the merchant side, but there
> too are the same UX issues as with RBF.
> In the end a risk-based approach to decide on which payments are
> non-trivial to reverse is the easiest, taking account user experience and
> such. Remember that in the fiat world card payments have up to 5%
> chargebacks, whereas we in zero-conf bitcoin land we deal with "fewer than
> 1 in a million" accepted transactions successfully reversed. These days we
> have very few support issues related to bitcoin payments. The few that do
> come in are due to accidental RBF users venting frustration about waiting
> for their tx to confirm.
> "In theory, theory and practice are the same. In practice, they are not"
>
> All the best,
> Sergej Kotliar
> CEO Bitrefill.com
>
>
> --
>
> Sergej Kotliar
>
> CEO
>
>
> Twitter: @ziggamon <https://twitter.com/ziggamon>;
>
>
> www.bitrefill.com
>
> Twitter <https://www.twitter.com/bitrefill>; | Blog
> <https://www.bitrefill.com/blog/>; | Angellist <https://angel.co/bitrefill>;
>
>
> --
>
> Sergej Kotliar
>
> CEO
>
>
> Twitter: @ziggamon <https://twitter.com/ziggamon>;
>
>
> www.bitrefill.com
>
> Twitter <https://www.twitter.com/bitrefill>; | Blog
> <https://www.bitrefill.com/blog/>; | Angellist <https://angel.co/bitrefill>;
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20221019/5d40738b/attachment-0001.html>;

📅 Original date posted:2022-10-17 📝 Original message:Hi ...

2023-06-08T01:14:35+02:00

In reply to nevent1q…gftm
_________________________

📅 Original date posted:2022-10-17
📝 Original message:Hi John,

I hear your worry about RBF issuing concerns for 0conf acceptance
merchants. I don't think it has been denied in the first communication of
this opt-in rbf proposal back in June. Merchants/0confs builders have been
invited to bring voices to the surface at that time [0]. So this new
full-RBF proposal has at least tried to bind to best communication
standards towards the community at large. If you think about more community
venues (Reddit, podcast, newsletter, ...) that developers may weigh in when
proposing Core policy changes, we can improve for next time.

About the kernel of the concern I understand, I think the whole discussion
would benefit from clarifications in precising zero-conf security bounds.
Relying only on first-seen and lack of RBF as a solo ground to estimate the
safety of an incoming transaction isn't that robust in a distributed system
like the p2p network. However, building management risks framework on top,
as additional security layers sound a far more compelling approach from a
developer perspective. A year ago, when I initially proposed full-rbf, I
noted a few ideas that could be implemented such as double-spend monitoring
or staked reputation to enhance zero-conf security [1]. For sure, there is
a wide solution space to explore and build on to improve the 0conf flows,
and it would marginally benefit LN, as we have now zero-conf channels [2].

That said, saying RBF causes more problems than it resolves sounds hard to
hold as a line from my perspective. As LN security relies on a reactive
model, where time-sensitive transactions must be included before a given
height to ensure funds safety, the ability to replace-by-fee previous bids
and have them propagating well on the network is fundamental. While I think
this is correct to say that today 0conf might be still a more significant
economic traffic than Lightning, the bitcoin user of tomorrow is likely to
expect both 0conf and Lightning, without caring that much about the
quibbles of the security mechanisms backing them.

Overall, RBF is far from being a "black-and-white" thing, dependending of
the perspective you're coming from, and thanks to everyone for patience in
this discussion.

Best,
Antoine

[0]
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-June/020557.html
[1]
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-June/019074.html
[2] https://github.com/lightning/bolts/pull/910

Le ven. 7 oct. 2022 à 12:43, Dario Sneidermanis via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> a écrit :

> Hello list,
>
> I'm Dario, from Muun wallet, a mobile non-custodial bitcoin wallet. For
> the past
> few days we've been reviewing the latest bitcoin core release candidate,
> and we
> found some troubling facts related to the opt-in full-RBF deployment.
>
> We first learned about the opt-in full-RBF proposal last June when it was
> announced on the mailing list. Closing the gap between the protocol's relay
> policies and the miner incentives is inevitable, so it was a welcomed
> addition.
> Furthermore, allowing transaction replacements that remove the opt-in RBF
> flag
> was deeply problematic.
>
> At the time, we understood we had at least a year from the initial opt-in
> deployment until opt-out was deployed, giving us enough time to adapt Muun
> to
> the new policies. However, when reviewing the 24.0 release candidate just
> a few
> days ago, we realized that zero-conf apps (like Muun) must *immediately
> turn
> off* their zero-conf features.
>
> I understand this wasn't the intention when designing the opt-in deployment
> mechanism. Given this new information, do you see a path where we can
> delay the
> opt-in deployment and find a safer way to deploy full-RBF?
>
> It'd be great for this deployment to be a success so that we can continue
> fixing
> the remaining relay policy problems, such as package relay and the RBF
> rules.
> Maybe we could go straight to an opt-out deployment locked by code at a
> certain
> height in the future to give time to everyone and, at the same time, avoid
> a
> huge mempool divergence event?
>
> Below is our analysis of how zero-conf apps break with opt-in full-RBF. I
> hope
> it helps.
>
> Cheers,
> Dario
>
>
> # How do zero-conf apps work
>
> While the workings and trade-offs of zero-conf applications might be known
> by
> many in this list, it's useful to define precisely how they work to
> understand
> how they break.
>
> We call zero-conf applications to entities that accept on-chain payments
> from
> *untrusted parties* and will sometimes deliver the paid-for product or
> service
> without waiting for the transaction to be included in a block.
>
> Some examples of zero-conf apps:
>
> - Muun's submarine swaps for outgoing lightning payments
> - Bitrefill's on-chain payments for gift cards and phone top-ups
> - Many bitcoin ATMs' on-chain deposits for selling bitcoin for cash (at
> least
> the two biggest bitcoin ATM manufacturers support this: Genesis Coin and
> General Byte)
>
> All of these applications are receiving incoming on-chain transactions for
> which
> they don't control the inputs, and performing a risk analysis to decide
> whether
> they are ok with accepting the payment without confirmation.
>
> In practice, this works because once the bitcoin P2P network has fully
> propagated a non-RBF transaction, you need the collaboration of a miner to
> replace it, which isn't easy to get today. Even though many of the biggest
> miners offer off-band transaction broadcasting services, they currently
> won't
> process conflicting transactions.
>
> Roughly, the risk analysis goes like this:
>
> 1. if an incoming transaction is RBF (direct or inherited)
> --> too risky, wait for 1 conf (or more) since it can be replaced at
> any time
> 2. if the payment is for an amount greater than X
> --> too risky, wait for 1 conf (or more), since the amount is worthy of
> a
> sophisticated attacker
> 3. wait for full(ish) propagation of the incoming transaction
> 4. if there's no double-spend attempt
> --> accept 0-conf
>
> As with any other risk analysis, there's always a false-negative detection
> rate,
> leading to an expected loss, which the zero-conf app should be willing to
> bear.
> Notice that the expected loss is tunable via the amount X in the above
> analysis.
>
>
> # Why are zero-conf apps not protected with an opt-in deployment
>
> Full-RBF adoption works on three different layers:
>
> - The transaction application layer
> - The transaction relaying layer
> - The transaction mining layer
>
> If an application wants to replace with full-RBF an *outgoing*
> transaction, it
> will need:
>
> - An upgraded node that opted into full-RBF, from which it can broadcast
> the
> replacement transaction
> - A connected component of upgraded nodes that opted into full-RBF, that
> can
> relay the replacement transaction
> - A miner in that connected component with an upgraded node that opted into
> full-RBF, that can mine the replacement transaction
>
> However, an application cannot control whether a replacement to an
> *incoming*
> transaction is relayed via full-RBF. As soon as a single application can
> generate replacements easily via full-RBF, all other applications have to
> assume
> that any incoming transaction from an untrusted party might be replaced via
> full-RBF. That is, for the application layer this is a forced upgrade.
>
> As soon as an unsophisticated attacker can use opt-in full-RBF, the risk
> analysis performed by zero-conf applications stops working because the
> transactions to analyze are all incoming transactions from untrusted
> parties.
> Since some wallets already implement cancel functionality for opt-in RBF
> transactions, enabling the same functionality for every transaction
> wouldn't
> require much work, making canceling any unconfirmed transaction a one-click
> experience. After this, the security model of zero-conf applications goes
> from
> "susceptible to attacks from miners" to "anyone can perform an attack,
> with an
> easy-to-use interface".
>
> That is, the opt-in deployment of full-RBF doesn't protect zero-conf
> applications from having to turn off their zero-conf features very soon
> after
> the initial deployment. All mitigations are mostly ineffective against
> untrusted parties.
>
>
> # Other things we have to fix
>
> While it's clear how full-RBF breaks zero-conf applications, other more
> subtle
> things break in *many* wallets (Muun included). If given the opportunity,
> we
> would like to fix them before deployment. One could argue that these things
> were already broken, but they get considerably worse as the network adopts
> full-RBF (even with an opt-in deployment), so we should fix them.
>
> ## Mental model for unconfirmed incoming transactions
>
> Many wallets with support for on-chain payments (Muun included) show
> incoming
> external transactions in some way to their users before they confirm. This
> is a
> common practice because not showing them leads users to worry that their
> money
> disappeared (exchanges doing this is the #1 issue we have to deal with in
> our
> customer support channels).
>
> With full-RBF, wallets should make it extremely clear to users that
> unconfirmed
> funds are not theirs (yet). Otherwise, protocol-unaware users that are
> transacting on-chain with untrusted parties can be easily scammed if they
> don't
> know they have to wait for a confirmation. Eg. in Argentina, it's pretty
> common
> to meet someone in person to buy bitcoin P2P for cash, even for newcomers.
>
> ## Block explorers as payment receipts
>
> Most wallets with support for on-chain payments (Muun included) use the
> transaction view of a block explorer as a shareable payment receipt. The
> sender
> of an on-chain transaction usually shares this link with the receiver to
> let
> them know they made a payment. Protocol-unaware receivers sometimes take
> this
> link as proof of payment.
>
> Most explorers currently don't track payment replacements and, more
> importantly,
> don't warn users that unconfirmed funds are not theirs (yet). With
> full-RBF,
> wallets should either stop relying on explorers for this functionality or
> wait
> for them to support it explicitly.
>
>
> # Impact at Muun
>
> Work to transition Muun from using zero-conf submarine swaps to using
> payment
> channels is ongoing, but we are still several months away from being
> production
> ready. This means we would have to turn off outgoing lightning payments for
> +100k monthly active users, which is a good chunk of all users making
> non-custodial lightning payments today.
>
> Furthermore, the more subtle fixes imply non-trivial amounts of product
> work
> that we cannot reasonably deploy before they start affecting users.
>
> While I cannot talk for other applications, there are many impacted in one
> way
> or another, and none of the ones I checked with were aware of this change,
> or
> its implications.
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20221017/28add9f9/attachment.html>;

📅 Original date posted:2022-10-19 📝 Original message:> ...

2023-06-08T01:14:24+02:00

In reply to nevent1q…mhh2
_________________________

📅 Original date posted:2022-10-19
📝 Original message:> Full RBF doesn't need a majority or unanimity to have an impact; it needs
> adoption by perhaps 10% of hashrate (so a low fee tx at the bottom of
> a 10MvB mempool can be replaced before being mined naturally), and some
> way of finding a working path to relay txs to that hashrate.

Yes, this has been the crux of the conceptual discussion in #25600.

> I mean, I guess I can understand wanting to reduce that responsibility
> for maintainers of the github repo, even if for no other reason than to
> avoid frivolous lawsuits, but where do you expect people to find better
> advice about what things are a good/bad idea if core devs as a whole
> are avoiding that responsibility?
>
> Core devs are supposedly top technical experts at bitcoin -- which means
> they're the ones that should have the best understanding of all the
> implications of policy changes like this. Is opt-in RBF only fine? If
> you look at the network today, it sure seems like it; it takes a pretty
> good technical understanding to figure out what problems it has, and
> an even better one to figure out whether those problems can be solved
> while keeping an opt-in RBF regime, or if full RBF is needed.

In the present case, I don't think there is a real concern of a frivolous
or half-baked lawsuit. My concern is rather the pretension to omniscience
that we would adopt as Core devs w.r.t policy changes, as far from being a
more closed, hermetic system like the p2p stack, it's interfacing with the
operations of a number of Bitcoin applications and second-layer contracting
protocols. As of today, I think this is still a relatively short process to
analyze the implications of any policy changes on the major Bitcoin
applications
flows and L2s of the day (i.e mainly Lightning and coinjoins). I'm not sure
this statement will stay true in a future with a growing fauna of L2s (i.e
vaults, DLC-over-channel, peerswaps, etc), each presenting unique
characteristics.

How do we minimize the odds of policy-based disruptions for current Bitcoin
softwares and users ? I don't have strong ideas, though I wish for the Core
project to adopt a more open-ended and smooth approach to release
context-rich policy changes. I aimed with #25353 and #25600 to experiment
with such a smoother approach advocated for (rather than the last year
proposal of turning on by default full-rbf, that was a wrong and missing
context). I hope at least one good outcome of this gradual process has been
to give time to Dario to publish a thoughtful standpoint for 0conf
operators, of which at least I learnt a few interesting elements on the UX
of such applications.

> It's a bit disappointing that the people that's a problem for didn't
> engage earlier -- though looking back, I guess there wasn't all that
> much effort made to reach out, either. There were two mentions in the
> optech newsletter [3] [4] but it wasn't called out as an "action item"
> (maybe those aren't a thing anymore), so it may have been pretty missable,
> especially given RBF has been discussed on and off for so long. And the
> impression I got from the PR review club discussion more seemed like
> devs making assumptions about businesses rather than having talked to
> them (eg "[I] think there are fewer and fewer businesses who absolutely
> cannot survive without relying on zeroconf. Or at least hope so").

Yeah, I'm still valuing the mailing list as a kind of "broadcast-all"
communication channel towards all the community stakeholders, though this
is the perspective of a developer and I'm not sure business/services
operators have the same communication habits. There is definitely a
reflection to hold, if we, as Core devs, we should follow a better
communication standard when we propose significant policy changes. And go
the full-tour of Reddit AMA, podcasts and newsletters as suggested in my
reply to Dario. It's hard to know if lack of vocal reactions on the mailing
list or to the publication of optech newsletter signifies a lack of
opposition, a lack of negatively impacted users or lack of interest from
the wider community. Maybe we should have a formalized, bulletpoints -based
for future policy changes, with clear time buffers and actions items, I
don't know.

> If we're happy to not get feedback until we start doing rcs, that's fine;
> but if we want to say "oops, we're into release candidates, you should
> have something earlier, it's too late now", that's a pretty closed-off
> way of doing things.
>
> And I mean: all this is only about drawing a line in *sand*; if people
> think core devs are wrong, they can still let that line blow away in
> the wind, by running different software, configuring core differently,
> patching core, or whatever else.

In the present case, it's more a lack of feedback showing up until we start
doing rcs, rather than a pretty closed-off way of doing things. That we
should amend expected and already-merged changes in the function of
feedback, I'm all for it in principle. The hard question is the set of
decision heuristics to converge on to qualify such feedback as worthy to
react on. Again in this case, we're doing some risk arbitrage (which I
really dislike as a situation) between 0conf applications and multi-party
funding flows of contracting protocols. Correcting our release process
isn't free of implications as we're removing the risk burden on some class
of use-case to pour it on a second class, in my opinion. Moreover, assuming
we have to bind to reasonable communication standards which is an open
question, I'm also worried we would also normalize the publication of very
late feedback from community stakeholders.

> I don't think that's remotely true: take a look at taproot activation:
> it took two months between releasing code that supported signalling and
> having 98% of hashrate signalling; with 40% of blocks signalling within
> the first two weeks.

First, without more visibility brought back on the 0confs operations
necessary to adapt their operations, two months might be considered as
enough. 8 weeks is sensibly the release schedule followed by few
open-source projects in the ecosystem. Second, the communication machine
behind softforks activation sounds to be far more fine-tuned, or at least
gather spontaneously community self-coordination than policy changes, and
it would be reasonable to expect things to be slower with policy changes.
However, I would agree you can have a quick adoption a day from another
with one single well-crafted meme buzzing on Twitter. Social phenomenas
don't offer the same degree of predictability than system engineering. How
we cope up with that, as core devs, I don't know.

> But if the line in the sand is "we're doing this, no matter how much that
> increases the risk to existing businesses that weren't expecting it" then
> it seems *very* disingenuous not to make those risks very clear so that
> people who weren't expecting it actually take action to avoid those risks.

I'm not sure if it has been established clearly, though as I announced on
IRC two weeks ago, Dario reached out to me offline before publishing his
mail. My recommendation to him have been immediately to adjoin 0confs
services examples impacted, if possible with numbers on users affected and
evaluation of engineering and operational effort if would request to adapt
their use-cases, and inviting to publish on this venue, as business
operators might not be used to with open-source process (I can disclose the
correspondence if requested and with Dario approval).

Goal was to collect the maximum of data points in our community
decision-making process about full-rbf. Now this doesn't relieve us of
finding a common ground on what should be a minimal bar to accept those
points, how to value those data
points, if we should take operators on their raw numbers or request the
publication of "light" proofs like on-chain transactions, lightning
invoices (everyone in business would take the happy measure showing the
most active users possible). The question of what signals we should
collect, and how we process them is a hard question in a decentralized and
trust-minimized process like the Bitcoin development one, from my
perspective. I don't have strong ideas there.

Though speaking for myself, and not for other contributors, I've raised the
warnings about potential impacts of full-rbfs in both my June 2021 [0] and
June 2022 [1] mails, so I find the qualification of disingenuous is a bit
ungrounded. Overall, I would remind all that it's better to keep patience
in face of complex changes in Core, rather than to fall quickly in a blame
ascription position.

[0]
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-June/019074.html
[1]
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-June/020557.html

(I don't deny "blame-and-reward" assignments can be worthy a posteriori,
once we're out of the "hot" discussion phase, especially to introspect on
how we can improve our engineering process, though in the middle of a
discussion... I don't know, it sounds premature and noisy).

> (More generally, that's similar to one of the things I've hated
> watching in mainstream economics over the past few years: "doing this
> will cause massive inflation" "no it won't, there's no inflation risk"
> "oops, inflation magically appeared, how did that happen? oh well, too
> bad, we have to live with it now". This looks pretty similar to me: "do
> something risky, deny the risk, make sure nobody can hold us accountable
> when the risk eventuates later" so it makes me really uncomfortable)

I can share the sentiment about mainstream economics and the way
risk-management impacts large-range of human beings is completely shrug
on... Though again in the present case, I think it would be more productive
to describe what engineering
needs or standards expectations of you are not fulfilled rather than to
fallback on the pure expression of an uncomfortableness and how as a
community of contributors we could improve on that. Though to object,
speaking of risk appreciation, not hardening the funding phase of
multi-party funding protocols also lets the door open to DoS attacks by
deanonymizing attackers targeting things like coinjoin.

> Sure; that's a fine reason to draw the line in the sand. But it's not
> a good reason to have it happen immediately, rather than giving people
> time to react, and it's not a good reason to understate the risk of
> it happening now. Maybe there are good reasons for either or both of
> those, though?

I agree. I would like to observe that "reasonable time to react" and
"adequate risk statement" is more an art than a science.

> Using the passive voice there doesn't seem helpful. Who learnt these
> things? You, I and Dario all seem to agree with (a), but John Carvalho
> certainly appears not to, for instance. I'm not sure who agrees with
> (b) -- I know I do, and I think Dario does; but multiple people seem
> opposed to the clear timeline offered in #26323, and your #26305 seems
> more likely to encourage a "pollination" approach rather than discourage
> it ("oh, this will be the default option for 25.0, might as well enable
> it now like all the cool kids are").

About John Carvalho disagreeing about full-rbf, I think he voiced a concern
during the summer on one of the PR introducing a full-rbf setting and I did
invite to voice his concerns on the ML, invitation stayed without follow-up
until the recent days [2] [3]. I would have loved to spend time back then
arguing on the full-rbf and miners incentives compatibility.

[2] https://github.com/bitcoin/bitcoin/pull/25373#issuecomment-1163422654
[3] https://github.com/bitcoin/bitcoin/pull/25373#issuecomment-1163815017

I know we all have busy agendas and a short timeline to react to all the
changes happening in the Bitcoin ecosystem... I think I replied to John
Carvalho answer on this thread, inviting him to develop his argumentation
further and I'm staying available to discuss with any full-rbf opponents,
in a calm and respectful fashion [4].

[4]
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-October/021027.html

> For what it's worth, my guess is that releasing core with full rbf
> support and having you and Murch and others advocating for people to
> try it out, will mean that full RBF is usable on mainnet within two
> or three months, supported by perhaps 5%-20% hashpower, but probably
> still requiring special effort to actually find a peer that can relay
> full rbf txs to that hashpower (probably doing an addnode, despite the
> privacy implications). Even if that happens, I'm not super confident
> that it would mean people would actively steal from zeroconf businesses
> in any volume, though. It's not something I'd risk happening to me,
> but accepting zeroconf from strangers isn't something I'd risk anyway.

Yeah I mean this could have been a forward process before Dario published
his thoughts. Achieving 5%-20% hashpower and full-rbf relay paths would
have assumed landing #25600 _and_ actually reach out to few mining pools to
inform them about the potential economic benefits. Now, I think the best
process is to keep listening to more feedback from the community, lay out
all the deployment options in code we have done and think more before
committing to something.

> And if the choice is between "bikeshedding" and "merge a PR, then ignore
> feedback that it's harmful", I'd much rather the bikeshedding. What's
> the point of having rcs if you're going to ignore negative feedback?

I think this might be the point where I could say we're diverging. In
principle, I agree we should listen to negative feedback raising harmful
disruptions risks for users and services. The more open, practical question
to me is more how we collect, qualify and sanitize such negative feedback
in a way which is acceptable for the community at large. Giving concrete
bounds to the immediate dangers in a consensual way, and asserting this
danger results from a lack of communication of the Core project, I'm still
wondering on those subjects. And note again, I didn't deny the option 3)
approach as you laid out was zero-risk for 0conf operators.

All that said, if we think as a project we should offer a "zero-risk"
process towards 0conf operators w.r.t full-rbf, at the detriment of the
risk encumbered by contracting protocols, I think it can be wise to
resurrect #26287.

Best,
Antoine

Le mar. 18 oct. 2022 à 03:00, Anthony Towns <aj at erisian.com.au> a écrit :

> On Mon, Oct 17, 2022 at 05:41:48PM -0400, Antoine Riard via bitcoin-dev
> wrote:
> > > 1) Continue supporting and encouraging accepting unconfirmed
> "on-chain"
> > > payments indefinitely
> > > 2) Draw a line in the sand now, but give people who are currently
> > > accepting unconfirmed txs time to update their software and
> business
> > > model
> > > 3) Encourage mainnet miners and relay nodes to support unconditional
> > > RBF immediately, no matter how much that increases the risk to
> > > existing businesses that are still accepting unconfirmed txs
> > To give more context, the initial approach of enabling full RBF through
> > #25353 + #25600 wasn't making the assumption the enablement itself would
> > reach agreement of the economic majority or unanimity.
>
> Full RBF doesn't need a majority or unanimity to have an impact; it needs
> adoption by perhaps 10% of hashrate (so a low fee tx at the bottom of
> a 10MvB mempool can be replaced before being mined naturally), and some
> way of finding a working path to relay txs to that hashrate.
>
> Having a majority of nodes/hashrate support it makes the upsides better,
> but doesn't change the downsides to the people who are relying on it
> not being available.
>
> > Without denying that such equilibrium would be unstable, it was designed
> to
> > remove the responsibility of the Core project itself to "draw a hard
> line"
> > on the subject.
>
> Removing responsibility from core developers seems like it's very much
> optimising for the wrong thing to me.
>
> I mean, I guess I can understand wanting to reduce that responsibility
> for maintainers of the github repo, even if for no other reason than to
> avoid frivolous lawsuits, but where do you expect people to find better
> advice about what things are a good/bad idea if core devs as a whole
> are avoiding that responsibility?
>
> Core devs are supposedly top technical experts at bitcoin -- which means
> they're the ones that should have the best understanding of all the
> implications of policy changes like this. Is opt-in RBF only fine? If
> you look at the network today, it sure seems like it; it takes a pretty
> good technical understanding to figure out what problems it has, and
> an even better one to figure out whether those problems can be solved
> while keeping an opt-in RBF regime, or if full RBF is needed.
>
> At that point, the technical experts *should* be coming up with a
> specific recommendation, and, personally, I think that's exactly what
> happened with [0] [1] and [2].
>
> [0]
> https://lists.linuxfoundation.org/pipermail/lightning-dev/2021-May/003033.html
> [1] https://github.com/bitcoin/bitcoin/pull/25353
> [2]
> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-June/020557.html
>
> That did draw hard line in the sand: it said "hey, opt-in RBF had a good
> run, but it's time to switch over to full RBF, for these reasons".
>
> It's a bit disappointing that the people that's a problem for didn't
> engage earlier -- though looking back, I guess there wasn't all that
> much effort made to reach out, either. There were two mentions in the
> optech newsletter [3] [4] but it wasn't called out as an "action item"
> (maybe those aren't a thing anymore), so it may have been pretty missable,
> especially given RBF has been discussed on and off for so long. And the
> impression I got from the PR review club discussion more seemed like
> devs making assumptions about businesses rather than having talked to
> them (eg "[I] think there are fewer and fewer businesses who absolutely
> cannot survive without relying on zeroconf. Or at least hope so").
>
> [3] https://bitcoinops.org/en/newsletters/2022/06/22/
> [4] https://bitcoinops.org/en/newsletters/2022/07/13/
>
> If we're happy to not get feedback until we start doing rcs, that's fine;
> but if we want to say "oops, we're into release candidates, you should
> have something earlier, it's too late now", that's a pretty closed-off
> way of doing things.
>
> And I mean: all this is only about drawing a line in *sand*; if people
> think core devs are wrong, they can still let that line blow away in
> the wind, by running different software, configuring core differently,
> patching core, or whatever else.
>
> > Moreover, relying on node operators turning on the setting
> > provides a smoother approach offering time to zero-conf services to react
> > in consequence.
>
> I don't think that's remotely true: take a look at taproot activation:
> it took two months between releasing code that supported signalling and
> having 98% of hashrate signalling; with 40% of blocks signalling within
> the first two weeks.
>
> > So the current path definitely belongs more to a 3) approach.
>
> > > 3) Encourage mainnet miners and relay nodes to support unconditional
> > > RBF immediately, no matter how much that increases the risk to
> > > existing businesses that are still accepting unconfirmed txs
>
> Yes, that's how it appears to me, too. It's not my preference (giving
> people clear warning of changes seems much better to me), but I can
> certainly live with it.
>
> But if the line in the sand is "we're doing this, no matter how much that
> increases the risk to existing businesses that weren't expecting it" then
> it seems *very* disingenuous not to make those risks very clear so that
> people who weren't expecting it actually take action to avoid those risks.
>
> That is, it seems to me that Dario was exactly right in titling this
> thread "Zero-conf apps in immediate danger", and our co-developers who
> are dismissing the risk by saying things along the lines of "probably
> nothing will change anytime soon" are exactly wrong.
>
> (More generally, that's similar to one of the things I've hated
> watching in mainstream economics over the past few years: "doing this
> will cause massive inflation" "no it won't, there's no inflation risk"
> "oops, inflation magically appeared, how did that happen? oh well, too
> bad, we have to live with it now". This looks pretty similar to me: "do
> something risky, deny the risk, make sure nobody can hold us accountable
> when the risk eventuates later" so it makes me really uncomfortable)
>
> > While this
> > way cannot be denied to be a zero-risk deployment for business accepting
> > unconfirmed transactions, it should be weighed in face of multi-party
> > contracting protocols encumbering an annoying pinning vector.
>
> Sure; that's a fine reason to draw the line in the sand. But it's not
> a good reason to have it happen immediately, rather than giving people
> time to react, and it's not a good reason to understate the risk of
> it happening now. Maybe there are good reasons for either or both of
> those, though?
>
> > Since Dario's mail, I think we have learnt new data points, a) on the
> long
> > term full RBF to align miner incentives is acknowledged and b) a clear
> > timeline based on e.g a block height is favored over the pollination
> > deployment.
>
> Using the passive voice there doesn't seem helpful. Who learnt these
> things? You, I and Dario all seem to agree with (a), but John Carvalho
> certainly appears not to, for instance. I'm not sure who agrees with
> (b) -- I know I do, and I think Dario does; but multiple people seem
> opposed to the clear timeline offered in #26323, and your #26305 seems
> more likely to encourage a "pollination" approach rather than discourage
> it ("oh, this will be the default option for 25.0, might as well enable
> it now like all the cool kids are").
>
> For what it's worth, my guess is that releasing core with full rbf
> support and having you and Murch and others advocating for people to
> try it out, will mean that full RBF is usable on mainnet within two
> or three months, supported by perhaps 5%-20% hashpower, but probably
> still requiring special effort to actually find a peer that can relay
> full rbf txs to that hashpower (probably doing an addnode, despite the
> privacy implications). Even if that happens, I'm not super confident
> that it would mean people would actively steal from zeroconf businesses
> in any volume, though. It's not something I'd risk happening to me,
> but accepting zeroconf from strangers isn't something I'd risk anyway.
>
> Slowing that down from January-ish to May seems like it ought to be a
> big win for anyone who has been doing zeroconf, and having it be easy
> to find a path to miners when it is supported seems like a big win even
> given a cost of a few months delay.
>
> OTOH, if we're really not expecting full rbf to be available for many
> months, then I would have expected the "disable this for mainnet,
> reconsider after the release" PR (#26287) to have gone ahead already.
>
> > Tie-breaking between
> > both, I believe I would favor something like #26323 though only post 24.0
> > to avoid introducing a bikeshedding precedent in terms of release
> process,
>
> Doing something like #26323 only after 24.0 is out does nothing to
> mitigate whatever immediate risk there is to bitcoin businesses/users...
>
> And if the choice is between "bikeshedding" and "merge a PR, then ignore
> feedback that it's harmful", I'd much rather the bikeshedding. What's
> the point of having rcs if you're going to ignore negative feedback?
>
> I mean, if you think the feedback is wrong, that's different: maybe we
> shouldn't care that zeroconf apps are in immediate danger, and maybe
> bitcoin would be better if any that don't adapt immediately all die
> horribly as a lesson to others not to make similarly bad assumptions.
>
> But saying "we don't want them to be in danger" and also refusing to do
> anything to avoid it?
>
> Cheers,
> aj
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20221018/f492c8c2/attachment-0001.html>;

📅 Original date posted:2022-07-23 📝 Original message:Hi ...

2023-06-08T01:12:02+02:00

In reply to nevent1q…mmak
_________________________

📅 Original date posted:2022-07-23
📝 Original message:Hi Ryan,

> Certain human/organizational limitations prevent things being said in
> logged channels that sometimes can be shared in person. Sometimes
> people break through misunderstandings in person, through either
> informal mingling or the use of Chatham House rules. So I would also
> advocate restarting the Scaling Bitcoin conferences, twice a year.

Just for clarity, I'm proposing online meetings on IRC, not in-person. But
yes, logged channels can be really narrow on topics and in person sometimes
let people grasp the bigger picture or wider context more easily. In my
opinion, to build understanding and sync on a complex topic there is
nothing like an old school whiteboard session. That being said,
higher-bandwidth communication channels like invite-only events come at the
price of openness and context-archiving, which matters a lot in Bitcoin. So
I think it's good to have a mix of both. It could be interesting to restart
Scaling Bitcoin confs, the scaling landscape has grown wild in the past
years (statechains, payment pools, federated chaumian banks, new types of
sidechains, etc), though I've not heard about orgas kicking them again.

> I perceived a lot of "Oh, well it's also fine to just wait and see
> what comes" in the prior discussions. The idea that we should reopen
> this discussion presumes that it is better to not wait, because having
> even imperfect covenant designs will cause the ecosystem to explore
> what use cases to allocate developer interest in (as long as the fees
> are not too far off - yeah I'm looking at you, CSFS). Because of
> this, I also propose asking some of the more advanced scripting
> technologists to reveal what of their work is currently science, what
> is engineering, and what is product-oriented with understandable
> delivery dates. I think that if more people understood the answers to
> these questions then there would be more room for incremental
> exploration of the space.

For sure, there is a "chicken-and-egg" issue, in the sense that lack of
certainty on finding consensus on covenant designs can deter some of the
most experienced and knowledgeable developers to invest time in building
and maturing use-cases toolchains demonstrating the worthiness of such
consensus change. One way to avoid this circular dependency can be to start
with a state-of-Bitcoin-art version of the protocol, deploy then once there
is economic traffic, propose protocol improvement requiring consensus
changes back to the community. This is more or less what Lightning is doing
with ANYPREVOUT, now there is like 4,300 BTC locked on the network, it's
easier to argue there is economic interest. Though ultimately, I don't
believe you will ever solve that dead-end risk of Bitcoin research
to attract automatically more developers. It's common to any scientific
endeavor, as in the end it's more an "inner taste" and exploration for its
own sake that drives long-term research.

On the second point, giving clarity on the state of advanced scripting
use-cases, effectively I believe it would be an informative task to do for
each use-case "champion". Speaking for payments pools, solving the
high-interactivity issue is still science [0], a pool design for like
10-100 participants assuming liveliness we might have known engineering
solutions [1], yet with still a lot of trade-offs to explore on the core
pool tree mechanism, and now the real unknown and hard task might be to say
a "product-oriented" with delivery dates. From my LDK experience, counts
3/4 years at best to build and mature any FOSS production-ready Bitcoin
codebase though in reality if you have to request other changes in the
ecosystem like mempools ones for a L2, you don't know. So for discussion
clarity, yes it's good if champions give an honest account of knowns and
unknowns of their use-cases. I would have loved all the mempool issues
affecting Lightning to have been detected and mitigations development
started earlier in the protocol genesis.

Thanks for the feedback, keeping track of them.

Le sam. 23 juil. 2022 à 06:10, Ryan Grant <bitcoin-dev at rgrant.org> a écrit :

> +1 I'd participate.
>
> Certain human/organizational limitations prevent things being said in
> logged channels that sometimes can be shared in person. Sometimes
> people break through misunderstandings in person, through either
> informal mingling or the use of Chatham House rules. So I would also
> advocate restarting the Scaling Bitcoin conferences, twice a year.
>
> One request for the agenda:
> I perceived a lot of "Oh, well it's also fine to just wait and see
> what comes" in the prior discussions. The idea that we should reopen
> this discussion presumes that it is better to not wait, because having
> even imperfect covenant designs will cause the ecosystem to explore
> what use cases to allocate developer interest in (as long as the fees
> are not too far off - yeah I'm looking at you, CSFS). Because of
> this, I also propose asking some of the more advanced scripting
> technologists to reveal what of their work is currently science, what
> is engineering, and what is product-oriented with understandable
> delivery dates. I think that if more people understood the answers to
> these questions then there would be more room for incremental
> exploration of the space.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20220723/bacfa116/attachment.html>;

📅 Original date posted:2022-06-21 📝 Original message:HI ...

2023-06-08T01:10:34+02:00

In reply to nevent1q…fmcp
_________________________

📅 Original date posted:2022-06-21
📝 Original message:HI alicexbt,

> Lets consider there are 2 users with name Bob (normal LN user) and Carol
(attacker running LN node) which I will use in this email for examples. In
this case Bob and Carol can manage security of their OS and it is not
affected by others using vulnerable systems or OS.

Yes, I believe my argument was the set of components making the security of
your LN node is far beyond Bitcoin softwares. Of course, you might review
by yourself the millions lines of code entering in the trusted computing
base (OS, bootloader, BIOS, device firmwares, essential utilities, ...) on
which your cryptocurrency software stack lays out, and as such exercise an
extended span of control on your personal computation. Though, while I hope
we'll have more LN node operators doing so, I'm not sure it's realistic to
expect it will be the behavior standard among them..

> The odds are low as you said, this can be managed by Bob and Carol
because they can use a better ISP. Others using ISP with some issues may
not affect their LN usage.

Sure, though as I would like to underscore being dependent on a Bitcoin
node policy and being dependent on a ISP internet traffic routing policy
could be analyzed as logically equivalent, all things are equal. That said,
if your personal risk aversion is too high for the Lightning security
model, once it's well-understood there is a strong reliance on a
censorship-resistant tx-relay network back to economically-rational miners,
you're free to not use it and satisfy yourself with the Bitcoin base layer.

> Bob might use full-rbf as its suggested by LN developers for secure LN
usage and better for miners. Carol could use a different RBF policy for
some nodes and mining. In this case Bob may get affected at some point
because of Carol's choice to use a different RBF policy which was not true
above.

Indeed, your secure LN usage is going to be dependent of the number of p2p
network nodes running an economically-rational policy like full-rbf. That
said, I think it's reasonable to assume that the players of the Bitcoin
game are economically-rational, and as such incentived to pick up a policy
such as full-rbf. I know the term "economically-rational" is poorly defined
here, and I think it could be interesting for any academic with an economic
background to study the incentives of Bitcoin actors.

> Allowing users to create different mempool policies is great. My thought
process is to code for happy path, where X policy is expected for
replacement and edge cases where Y policy or no policy would be used. Users
can try out different policies and even act as attackers. This is also true
for other things in mempool, 'spkreuse=conflict' prevents address reuse in
the mempool when using knots. If I assume that address reuse is always
relayed, this could become a problem if some users and miners adopt this
setting in their mempool.

Agree, I'm all in for people to experiment with mempool policies. Though at
the end it's a software engineering resource question. If users are
interested in more features, they're always free to implement themselves.
Really, the binary distinction developers-vs-users doesn't make sense and
if we would like Bitcoin to be successful in the long-term, we should
promote high degree of software literacy among bitcoiners.

> This makes sense and I would be interested to follow two things once
full-rbf is available in a bitcoin core release: 1. Percentage of
transaction getting replaced 2. Miners profit (Fee for replaced Tx - Fee
for original Tx)

Yes, I would be interested too to have those metrics once full-rbf is
available in a bitcoin core release. I think that's something every
full-rbf curious node operator could observe on its own with a few more
loggers, at least for the first metric.

> Can you explain how p2p coinjoin is affected with mempool DoS vector with
some examples? What is considered a p2p coinjoin? Joinmarket or
[Stonewall][1]?

I don't remember the Joinmarket code right now and I don't know the ins and
outs of Samourai coinjoin as I'm not sure the code is open source. Though
let's say for a p2p coinjoin as one you can build once you have implemented
LN's interactive construction protocol [0].

[0] https://github.com/lightning/bolts/pull/851

Here the DoS attack situation :
- Alice, Bob and Caroll would like to coinjoin 3 inputs to 3 outputs
- Each of the input is singly controlled by one party, e.g Alice owns input
A, Bob owns input B, ...
- Alice, Bob and Caroll exchanges a PSBT to build a multi-party funded
transaction (the coinjoin_tx)
- Alice is elected as the multi-party transaction broadcaster once the
signatures have been exchanged
- The block feerate is around 10sat/vb
- One of the transaction input signals opt-in RBF, the transaction is
attached a compelling feerate 10sat/vb
- Caroll broadcasts a double-spend of her own input C, the double-spend is
attached with a low-fee (1sat/vb) and it does _not_ signal opt-in RBF
- Alice broadcasts the multi-party transaction, it is rejected by the
network mempools because Alice double-spend is already present
- Two alternatives are offered to the coinjoin participants :

Alternative A)
- They estimate the multi-party feerate as not high enough
- They fee-bump at 20sat/vb
- Caroll double-spend one of the input of her malicious double-spend to
eject it from the network mempools
- The multi-party transaction is confirmed at a block feerare far above
what was necessary
- Alice, Bob, Caroll have loss fee-bumping value without compensation
- Note, even if Caroll is attacker and assuming the fee-bumping burden is
fairly spread among participants, the economic loss inflicted is asymmetric

Alternative B)
- They wait until some time-out
- They double-spend their own inputs, Alice double-spend utxo A, Bob
double-spend utxo B
- They wasted the timevalue of their inputs for the time-out delay
- Note, even if Caroll is attacker and loss some timevalue too, the
economic loss inflicted is asymmetric

Let me know if you see any error or wrong in this DoS scenario exposure. I
believe it's fairly simple to execute
for a medium-skilled attacker.

Antoine

Le ven. 17 juin 2022 à 00:54, alicexbt <alicexbt at protonmail.com> a écrit :

> Hi Antoine,
>
>
> One could list the operating system on which is running your Lightning
> process or the compiler toolchain turning out your Lightning source code
> in a binary artifact. Some weird kernel's memory mapping change could allow
> access to your channel funding keys, _without_ breaking the Bitcoin
> consensus rules [0].
>
>
> Lets consider there are 2 users with name Bob (normal LN user) and Carol
> (attacker running LN node) which I will use in this email for examples. In
> this case Bob and Carol can manage security of their OS and it is not
> affected by others using vulnerable systems or OS.
>
> Moreover, your Lightning node is also relying on the existence of a
> global Internet allowing your HTLC transaction to flow from your physical
> host to the crowd of transactions confirming in the blockchain. Due to
> this "protocol assumption" your channel balance would be vulnerable to
> any change in your ISP routing policy, e.g refusing to accept your IPV4
> traffic by a sudden desiderata to impose an IPV6 supremacy. Still
> _without_ breaking the Bitcoin consensus rules. Of course, the odds of your
> ISP operator adopting this behavior are really low, mostly because your
> operator has to bind to social and economic constraints to stay in
> business.
>
>
> The odds are low as you said, this can be managed by Bob and Carol because
> they can use a better ISP. Others using ISP with some issues may not affect
> their LN usage.
>
> And I believe this imperative to stay in business is certainly not absent
> in the incentives of the Bitcoin node operators. You're free to run any
> policy on your node, especially one hardening the safety of your operations
> beyond the default one. However, if you start to a transaction-relay
> non-compatible with miner incentives, you won't have an efficient view of
> the blockspace demand, and from then won't be able to offer compelling
> feerates to execute your business transactions to satisfy your client
> needs. Or you won't consolidate your wallet UTXOs at times of low-demand.
> Indeed, a sane visibility of the mempools might not be critical now for your
> Bitcoin operations, but this is not likely to become true with miner's
> coinbase reward lowering with time and the system security relying on a
> fruitful fee market.
>
>
> Bob might use full-rbf as its suggested by LN developers for secure LN
> usage and better for miners. Carol could use a different RBF policy for
> some nodes and mining. In this case Bob may get affected at some point
> because of Carol's choice to use a different RBF policy which was not true
> above.
>
>
> So assuming there is a significant number of economically rational
> entities running p2p nodes, I think it's a reasonable assumption for
> Lightning developers that a policy maximizing miner's income and economic
> nodes operations will be widely run on the p2p network, and therefore lay
> its security model on that. When there is a gap between the economically
> optimal policy (full-rbf) and the effectively deployed one (optin), and
> this gap constitutes a flaw for exploitation, I believe it's better to
> fix it.
>
>
> Agree with the assumption there is nothing wrong in experimenting with a
> new RBF policy (non-default) if that helps some users and projects.
>
> If you have a different mode of thinking w.r.t how we should design
> protocol in a trust-minimized, open, adversarial environment such as
> Bitcoin, I'm curious to listen to it.
>
>
> Allowing users to create different mempool policies is great. My thought
> process is to code for happy path, where X policy is expected for
> replacement and edge cases where Y policy or no policy would be used. Users
> can try out different policies and even act as attackers. This is also true
> for other things in mempool, 'spkreuse=conflict' prevents address reuse in
> the mempool when using knots. If I assume that address reuse is always
> relayed, this could become a problem if some users and miners adopt this
> setting in their mempool.
>
> Of course not. If you deliver any critical software, you should attach a
> solid manual explaining all the corner cases and rough edges. Even better
> would be to enshrine the manual directly in your software API to minimize
> the footgunish behaviors. E.g, with any ECC library, forbidding to reuse
> nonces. If your user still ignores or misread the manual and provides an
> insecure input, there is not that much you can do.
>
>
> Agree with the documentation as it helps users.
>
> Given there are like 17000 public LN nodes, if half of them adopt full-rbf
> it should give already a good number of full-rbf transaction-relay routes
> across the p2p network graph. When we're there, we can measure and think
> more about how to tune the full-rbf sub-topology.
>
>
> Sounds good.
>
> Because it's breaking the reliability and security of their use-cases.
> Use-cases which didn't exist a few years ago. The mempool DoS vector is
> described here [4]. To the best of my understanding, it might affect a
> bunch of use-cases, such as dual-funded channels, on-chain DLCs, p2p
> coinjoins, batched submarine swaps out. With the attack described, the
> honest set of users might not have visibility of the network mempools
> that there is a malicious, low-cost, opt-out double-spend preventing the
> propagation of their multi-party transaction. With the existence of a
> full-rbf transaction-relay topology, the multi-party transaction is able
> to replace the optout.
>
>
> This makes sense and I would be interested to follow two things once
> full-rbf is available in a bitcoin core release: 1. Percentage of
> transaction getting replaced 2. Miners profit (Fee for replaced Tx - Fee
> for original Tx)
>
> Can you explain how p2p coinjoin is affected with mempool DoS vector with
> some examples? What is considered a p2p coinjoin? Joinmarket or
> [Stonewall][1]?
>
> Selecting a full-node to underpin any serious Bitcoin infrastructure or
> secure a significant stack of coins should be submitted to a
> fully-fledged decision-making process. Many factors are likely to matter such
> as the level of activity of the contributor community, the chain of trust
> w.r.t dependencies, the security incident track records, the quality of
> the documentation, the exhaustivity and robustness of the set of features,
> ...
>
>
> I agree that contributor community and documentation could be improved in
> Knots.
>
> Developers are also Bitcoin users, and they're modifying the software to
> suit their use-case needs. And that's exactly the purpose of the
> 'full-rbf' PR I'm proposing, aiming to propose a "good" policy for a
> Lightning node, without actually seeking to change the default.
>
>
> I like that default still remains opt-in and cool with different policies
> being tried out if that helps some users.
>
> If they're parties interested in implementing more RBF policy options in
> Bitcoin Core, I think they're free to propose such changes and invest the
> engineering effort to do so. If you're interested in advancing the state of
> policy options in Bitcoin Core, there are a lot of interesting resources available
> and communities to encourage you in the learning process to contribute to
> the codebase [6].
>
>
> Thanks for sharing the link. I would love to see 5 RBF policies available
> to use in bitcoin core. I have already tried experimenting with a few on
> regtest and will try to open pull request if there are enough people
> interested to test it on other chains (testnet3, signet, mainnet)
>
>
> [1]: https://docs.samourai.io/spend-tools
>
>
> /dev/fd0
>
>
> Sent with Proton Mail <https://proton.me/>; secure email.
>
> ------- Original Message -------
> On Friday, June 17th, 2022 at 7:04 AM, Antoine Riard <
> antoine.riard at gmail.com> wrote:
>
> Hi alicexbt,
>
>
> Thanks for taking time to review the pull request,
>
>
> > 1)If something relies on a policy which can be changed without breaking
> consensus rules, how is it secure in any case with or without full rbf?
>
>
> Your Lightning node software relies on far more software and hardware
> components than the transaction-relay p2p network. One could list the
> operating system on which is running your Lightning process or the compiler
> toolchain turning out your Lightning source code in a binary artifact.
> Some weird kernel's memory mapping change could allow access to your
> channel funding keys, _without_ breaking the Bitcoin consensus rules [0].
> Moreover, your Lightning node is also relying on the existence of a
> global Internet allowing your HTLC transaction to flow from your physical
> host to the crowd of transactions confirming in the blockchain. Due to
> this "protocol assumption" your channel balance would be vulnerable to
> any change in your ISP routing policy, e.g refusing to accept your IPV4
> traffic by a sudden desiderata to impose an IPV6 supremacy. Still
> _without_ breaking the Bitcoin consensus rules. Of course, the odds of your
> ISP operator adopting this behavior are really low, mostly because your
> operator has to bind to social and economic constraints to stay in
> business.
>
>
> And I believe this imperative to stay in business is certainly not absent
> in the incentives of the Bitcoin node operators. You're free to run any
> policy on your node, especially one hardening the safety of your operations beyond
> the default one. However, if you start to a transaction-relay
> non-compatible with miner incentives, you won't have an efficient view of
> the blockspace demand, and from then won't be able to offer compelling
> feerates to execute your business transactions to satisfy your client
> needs. Or you won't consolidate your wallet UTXOs at times of low-demand.
> Indeed, a sane visibility of the mempools might not be critical now for your
> Bitcoin operations, but this is not likely to become true with miner's
> coinbase reward lowering with time and the system security relying on a
> fruitful fee market.
>
>
> So assuming there is a significant number of economically rational
> entities running p2p nodes, I think it's a reasonable assumption for
> Lightning developers that a policy maximizing miner's income and economic
> nodes operations will be widely run on the p2p network, and therefore lay
> its security model on that. When there is a gap between the economically
> optimal policy (full-rbf) and the effectively deployed one (optin), and
> this gap constitutes a flaw for exploitation, I believe it's better to
> fix it.
>
>
> If you have a different mode of thinking w.r.t how we should design
> protocol in a trust-minimized, open, adversarial environment such as
> Bitcoin, I'm curious to listen to it.
>
>
> > If I write a python script that expects user to enter char 'a' or 'b'
> but user can enter 'c' and there is no code to handle exceptions or other
> chars, will it be secure?
>
>
> Of course not. If you deliver any critical software, you should attach a
> solid manual explaining all the corner cases and rough edges. Even better
> would be to enshrine the manual directly in your software API to minimize
> the footgunish behaviors. E.g, with any ECC library, forbidding to reuse
> nonces. If your user still ignores or misread the manual and provides an
> insecure input, there is not that much you can do.
>
>
> By analogy, I believe that's the same with Lightning. One recommendation
> of the deployment manual would be to be always connected to a full-rbf
> transaction-relay topology. Defaulting to this rule and your node exposes
> far more surface of attacks. Assuming the manual has been well-written (big
> assumption!), I don't think the system designer would be to blame.
>
>
> That said, one issue to confess with current Lightning is our lack of
> understanding of what should be figured out in the LN user manual for
> safe operations. I would say that's an active area of research [1] [2] [3]
>
>
> > 2)full-rbf is not default in the 2 open pull requests, so this
> experiment still relies on users changing RBF policies manually. If
> majority of nodes use default opt-in policy, how would this affect
> vulnerable projects?
>
>
> If we define the goal as ensuring there is a significant number of
> transaction-relay routes between the L2s nodes requiring full-rbf and the
> set of miners supporting this policy, and the set of miners is populated
> enough, there is no need to convince the majority of nodes operators to
> switch to full-rbf.
>
>
> Beyond landing the 'full-rbf' pull request, in pursuit of a partial
> full-rbf deployment, I'm thinking of reaching out to Lightning vendors to
> recommend running LN nodes operators run their full-node with the setting
> enabled. And also to few mining pool operators to advocate the potential
> increase in their income.
>
>
> Given there are like 17000 public LN nodes, if half of them adopt full-rbf
> it should give already a good number of full-rbf transaction-relay routes
> across the p2p network graph. When we're there, we can measure and think
> more about how to tune the full-rbf sub-topology.
>
>
> > 2-3% transactions are replaced with opt-in RBF, if someone did not
> replace earlier why would they do it with full RBF?
>
>
> Because it's breaking the reliability and security of their use-cases.
> Use-cases which didn't exist a few years ago. The mempool DoS vector is
> described here [4]. To the best of my understanding, it might affect a
> bunch of use-cases, such as dual-funded channels, on-chain DLCs, p2p
> coinjoins, batched submarine swaps out. With the attack described, the
> honest set of users might not have visibility of the network mempools
> that there is a malicious, low-cost, opt-out double-spend preventing the
> propagation of their multi-party transaction. With the existence of a
> full-rbf transaction-relay topology, the multi-party transaction is able
> to replace the optout.
>
>
> None of those use-cases were deployed a few years ago, and the
> understanding of the interactions with the mempool policy is still
> nascent among their operators. However, if we assume that layering is a way
> to grow the Bitcoin ecosystem, as I do, it is reasonable to expect they
> will constitute a notable share of the Bitcoin transaction traffic during
> the next decade.
>
>
> > I am not opposed to full-rbf; rather, I am opposed to the notion that
> full-rbf will solve all problems
>
>
> I wished we had a magic Silver Bullet (tm) solving all the Bitcoin
> problems...
>
>
> I'm only advocating a partial full-rbf deployment to solve a real precise
> security issue affecting multi-party funded transactions. That said,
> full-rbf is far from solving the known set of problems affecting the L2s
> due to interactions with network mempools. E,g, see package relay
> motivation [5]
>
>
> > I would suggest users to try Bitcoin Knots instead which already has an
> option to disable all RBF policies if required, opt-in and full RBF policy.
>
>
> Selecting a full-node to underpin any serious Bitcoin infrastructure or
> secure a significant stack of coins should be submitted to a
> fully-fledged decision-making process. Many factors are likely to matter
> such as the level of activity of the contributor community, the chain of
> trust w.r.t dependencies, the security incident track records, the
> quality of the documentation, the exhaustivity and robustness of the set of
> features, ...
>
>
> This process might take tens of hours, to be duplicated by the number of
> node operators who would have to do the full-node vending switch. If you
> consider the cognitive cost at the level of the Bitcoin ecosystem, it's
> far less costly to implement and review a few lines of codes in Bitcoin
> Core.
>
>
> > Developers should provide basic RBF policy options rather than
> attempting to define what constitutes a good policy and removing the
> ability to disable something when necessary.
>
>
> Of course, this statement assumes there is a clear line between the
> developers and the users. Developers are also Bitcoin users, and they're
> modifying the software to suit their use-case needs. And that's exactly the
> purpose of the 'full-rbf' PR I'm proposing, aiming to propose a "good"
> policy for a Lightning node, without actually seeking to change the
> default. If they're parties interested in implementing more RBF policy
> options in Bitcoin Core, I think they're free to propose such changes and
> invest the engineering effort to do so. If you're interested in advancing
> the state of policy options in Bitcoin Core, there are a lot of
> interesting resources available and communities to encourage you in the
> learning process to contribute to the codebase [6].
>
>
> Antoine
>
>
> [0] https://dirtycow.ninja
>
> [1]
> https://github.com/t-bast/lightning-docs/blob/master/pinning-attacks.md
>
> [2] https://arxiv.org/pdf/2006.01418.pdf
>
> [3] https://arxiv.org/pdf/2006.08513.pdf
>
> [4]
> https://lists.linuxfoundation.org/pipermail/lightning-dev/2021-May/003033.html
>
> [5]
> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-May/020493.html
>
> [6] https://www.summerofbitcoin.org
>
>
> Le jeu. 16 juin 2022 à 00:15, alicexbt <alicexbt at protonmail.com> a écrit :
>
>> Hi Antoine,
>>
>>
>> Thanks for opening the pull request to add support for full-rbf in
>> Bitcoin Core. I have a disagreements with the approach and questions.
>>
>> Recent discussions among LN devs have brought back on the surface
>> concerns about the security of multi-party funded transactions (coinjoins,
>> dual-funded LN channels, on-chain DLCs, ...). It turns out there is a
>> low-fruit, naive DoS vector playable against the funding flow of any such
>> construction due to the lack of existent full-rbf transaction-relay
>> topology on today's p2p network [0] [1].
>>
>>
>> 1)If something relies on a policy which can be changed without breaking
>> consensus rules, how is it secure in any case with or without full rbf? If
>> I write a python script that expects user to enter char 'a' or 'b' but user
>> can enter 'c' and there is no code to handle exceptions or other chars,
>> will it be secure?
>>
>> 2)full-rbf is not default in the 2 open pull requests, so this experiment
>> still relies on users changing RBF policies manually. If majority of nodes
>> use default opt-in policy, how would this affect vulnerable projects?
>>
>> If you're a mining operator looking to increase your income, you might be
>> interested to experiment with full-rbf as a policy.
>>
>>
>> Miners can only increase their income if users replace transactions. 2-3%
>> transactions are replaced with opt-in RBF, if someone did not replace
>> earlier why would they do it now even with full RBF? Or even if we add some
>> users in it who could not signal for some reasons, do you think it would be
>> anything above 5%?
>>
>> If you're a Bitcoin user or business and you don't like full-rbf, please
>> express an opinion on how it might affect your software/operations. I'm
>> always interested to learn more about mempool and transaction-relay
>> interactions with upper-layers and applications and to listen to feedback
>> in those areas, and I guess a lot of other Bitcoin researchers/devs too. I
>> know there have been a lot of concerns about full-rbf in the past, however
>> I believe the Bitcoin ecosystem has matured a lot since then.
>>
>>
>> I am not opposed to full-rbf; rather, I am opposed to the notion that
>> full-rbf will solve all problems and the lack of basic options in Bitcoin
>> Core to employ/disable different RBF policies. There is also a speculation
>> about making full RBF default in an year which isn't relevant to discuss at
>> this point without trying different RBF policies.
>>
>> I would suggest users to try Bitcoin Knots instead which already has an
>> option to disable all RBF policies if required, opt-in and full RBF policy.
>> This can also be done using GUI if not familiar with config option
>> mempoolreplacement.
>>
>> The rationale in PR #16171 was insufficient to justify removing it in the
>> first place, had 2 NACKs and was reopened to merge it. Why bother with a
>> few lines of code that may allow someone disable it if required in local
>> mempool since it's only useful when a big percentage of miners utilize it
>> and essentially underused according to the PR author? Developers should
>> provide basic RBF policy options rather than attempting to define what
>> constitutes a good policy and removing the ability to disable something
>> when necessary.
>>
>>
>> /dev/fd0
>>
>> Sent with Proton Mail <https://proton.me/>; secure email.
>>
>> ------- Original Message -------
>> On Tuesday, June 14th, 2022 at 5:55 AM, Antoine Riard via bitcoin-dev <
>> bitcoin-dev at lists.linuxfoundation.org> wrote:
>>
>> Hi list,
>>
>> Recent discussions among LN devs have brought back on the surface
>> concerns about the security of multi-party funded transactions (coinjoins,
>> dual-funded LN channels, on-chain DLCs, ...). It turns out there is a
>> low-fruit, naive DoS vector playable against the funding flow of any such
>> construction due to the lack of existent full-rbf transaction-relay
>> topology on today's p2p network [0] [1]. While it does not consist in a
>> direct loss of funds, if exploited well I think it's annoying enough to
>> inflict significant timevalue loss or fee-bumping waste
>> to the future providers or distributed swarm of users doing multi-party
>> funded transactions. Of course, it can be fixed one layer above by
>> introducing either fidelity bonds or a reliable centralized coordinator,
>> though at the price of an overhead per-participant ressources cost and loss
>> in system openness [1].
>>
>> For that reason, I believe it would be beneficial to the flourishing of
>> multi-party funded transactions to fix the Dos vector by seeing a subset of
>> the network running full-rbf and enabling propagation of honest multi-party
>> transactions to the interested miners, replacing potential non-signaling
>> double-spend from a malicious counterparty. Moving towards that direction,
>> I've submitted a small patch against Bitcoin Core enabling it to turn on
>> full-rbf as a policy, still under review [3]. The default setting stays
>> **false**, i.e keeping opt-in RBF as a default replacement policy. I've
>> started to run the patch on a public node at 146.190.224.15.
>>
>> If you're a node operator curious to play with full-rbf, feel free to
>> connect to this node or spawn up a toy, public node yourself. There is a
>> ##uafrbf libera chat if you would like information on the settings or
>> looking for full-rbf friends (though that step could be automated in the
>> future by setting up a dedicated network bit and reserving a few outbound
>> slots for them).
>>
>> If you're a mining operator looking to increase your income, you might be
>> interested to experiment with full-rbf as a policy. Indeed, in the future I
>> believe the multi-party transactions issuers who need full-rbf to secure
>> their funding flow should connect by default to full-rbf peers. One can
>> conjecture that their transactions are likely to be more compelling in
>> their feerate as their liquidity needs are higher than the simple
>> transaction. For today, I think we have really few standards and bitcoin
>> softwares relying on multi-party funded transactions [4].
>>
>> If you're a Bitcoin user or business and you don't like full-rbf, please
>> express an opinion on how it might affect your software/operations. I'm
>> always interested to learn more about mempool and transaction-relay
>> interactions with upper-layers and applications and to listen to feedback
>> in those areas, and I guess a lot of other Bitcoin researchers/devs too. I
>> know there have been a lot of concerns about full-rbf in the past, however
>> I believe the Bitcoin ecosystem has matured a lot since then.
>>
>> Any mistakes or missing context is my own.
>>
>> Cheers,
>> Antoine
>>
>> [0] For more info about replace-by-fee, see
>> https://bitcoinops.org/en/topics/replace-by-fee/
>>
>> [1] For more details about the DoS vector, see
>> https://lists.linuxfoundation.org/pipermail/lightning-dev/2021-May/003033.html
>>
>> [2] E.g I think it does not affect the Lightning Pool service, as there
>> is a preliminary step where the participant funds are locked first in a
>> 2-of-2 with the coordinator before being committed in the multi-party batch
>> transaction.
>>
>> [3] https://github.com/bitcoin/bitcoin/pull/25353
>>
>> [4] E.g DLCs :
>> https://github.com/discreetlogcontracts/dlcspecs/blob/master/Transactions.md
>> ; Lightning dual-funded channel :
>> https://github.com/lightning/bolts/pull/851
>>
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20220621/721b7e8e/attachment-0001.html>;

📅 Original date posted:2022-06-16 📝 Original message:Hi ...

2023-06-08T01:10:32+02:00

In reply to nevent1q…7yv8
_________________________

📅 Original date posted:2022-06-16
📝 Original message:Hi alicexbt,

Thanks for taking time to review the pull request,

> 1)If something relies on a policy which can be changed without breaking
consensus rules, how is it secure in any case with or without full rbf?

Your Lightning node software relies on far more software and hardware
components than the transaction-relay p2p network. One could list the
operating system on which is running your Lightning process or the compiler
toolchain turning out your Lightning source code in a binary artifact. Some
weird kernel's memory mapping change could allow access to your channel
funding keys, _without_ breaking the Bitcoin consensus rules [0]. Moreover,
your Lightning node is also relying on the existence of a global Internet
allowing your HTLC transaction to flow from your physical host to the crowd
of transactions confirming in the blockchain. Due to this "protocol
assumption" your channel balance would be vulnerable to any change in your
ISP routing policy, e.g refusing to accept your IPV4 traffic by a
sudden desiderata
to impose an IPV6 supremacy. Still _without_ breaking the Bitcoin consensus
rules. Of course, the odds of your ISP operator adopting this behavior are
really low, mostly because your operator has to bind to social and economic
constraints to stay in business.

And I believe this imperative to stay in business is certainly not absent
in the incentives of the Bitcoin node operators. You're free to run any
policy on your node, especially one hardening the safety of your
operations beyond
the default one. However, if you start to a transaction-relay
non-compatible with miner incentives, you won't have an efficient view of
the blockspace demand, and from then won't be able to offer compelling
feerates to execute your business transactions to satisfy your client
needs. Or you won't consolidate your wallet UTXOs at times of low-demand.
Indeed, a sane visibility of the mempools might not be critical now for your
Bitcoin operations, but this is not likely to become true with miner's
coinbase reward lowering with time and the system security relying on a
fruitful fee market.

So assuming there is a significant number of economically rational entities
running p2p nodes, I think it's a reasonable assumption for Lightning
developers that a policy maximizing miner's income and economic nodes
operations
will be widely run on the p2p network, and therefore lay its security model
on that. When there is a gap between the economically optimal policy
(full-rbf) and the effectively deployed one (optin), and this gap constitutes
a flaw for exploitation, I believe it's better to fix it.

If you have a different mode of thinking w.r.t how we should design
protocol in a trust-minimized, open, adversarial environment such as
Bitcoin, I'm curious to listen to it.

> If I write a python script that expects user to enter char 'a' or 'b' but
user can enter 'c' and there is no code to handle exceptions or other
chars, will it be secure?

Of course not. If you deliver any critical software, you should attach a
solid manual explaining all the corner cases and rough edges. Even better
would be to enshrine the manual directly in your software API to minimize
the footgunish behaviors. E.g, with any ECC library, forbidding to reuse
nonces. If your user still ignores or misread the manual and provides an
insecure input, there is not that much you can do.

By analogy, I believe that's the same with Lightning. One recommendation of
the deployment manual would be to be always connected to a full-rbf
transaction-relay topology. Defaulting to this rule and your node exposes
far more surface of attacks. Assuming the manual has been well-written (big
assumption!), I don't think the system designer would be to blame.

That said, one issue to confess with current Lightning is our lack of
understanding of what should be figured out in the LN user manual for safe
operations. I would say that's an active area of research [1] [2] [3]

> 2)full-rbf is not default in the 2 open pull requests, so this experiment
still relies on users changing RBF policies manually. If majority of nodes
use default opt-in policy, how would this affect vulnerable projects?

If we define the goal as ensuring there is a significant number of
transaction-relay routes between the L2s nodes requiring full-rbf and the
set of miners supporting this policy, and the set of miners is populated
enough, there is no need to convince the majority of nodes operators to
switch to full-rbf.

Beyond landing the 'full-rbf' pull request, in pursuit of a partial
full-rbf deployment, I'm thinking of reaching out to Lightning vendors to
recommend running LN nodes operators run their full-node with the setting
enabled. And also to few mining pool operators to advocate the potential
increase in their income.

Given there are like 17000 public LN nodes, if half of them adopt full-rbf
it should give already a good number of full-rbf transaction-relay routes
across the p2p network graph. When we're there, we can measure and think
more about how to tune the full-rbf sub-topology.

> 2-3% transactions are replaced with opt-in RBF, if someone did not
replace earlier why would they do it with full RBF?

Because it's breaking the reliability and security of their use-cases.
Use-cases which didn't exist a few years ago. The mempool DoS vector is
described here [4]. To the best of my understanding, it might affect a
bunch of use-cases, such as dual-funded channels, on-chain DLCs, p2p
coinjoins, batched submarine swaps out. With the attack described, the
honest set of users might not have visibility of the network mempools that
there is a malicious, low-cost, opt-out double-spend preventing the
propagation of their multi-party transaction. With the existence of a
full-rbf transaction-relay topology, the multi-party transaction is able to
replace the optout.

None of those use-cases were deployed a few years ago, and the
understanding of the interactions with the mempool policy is still nascent
among their operators. However, if we assume that layering is a way to grow the
Bitcoin ecosystem, as I do, it is reasonable to expect they will constitute
a notable share of the Bitcoin transaction traffic during the next decade.

> I am not opposed to full-rbf; rather, I am opposed to the notion that
full-rbf will solve all problems

I wished we had a magic Silver Bullet (tm) solving all the Bitcoin
problems...

I'm only advocating a partial full-rbf deployment to solve a real precise
security issue affecting multi-party funded transactions. That said,
full-rbf is far from solving the known set of problems affecting the L2s
due to interactions with network mempools. E,g, see package relay
motivation [5]

> I would suggest users to try Bitcoin Knots instead which already has an
option to disable all RBF policies if required, opt-in and full RBF policy.

Selecting a full-node to underpin any serious Bitcoin infrastructure or
secure a significant stack of coins should be submitted to a fully-fledged
decision-making process. Many factors are likely to matter such as the
level of activity of the contributor community, the chain of trust w.r.t
dependencies, the security incident track records, the quality of the
documentation, the exhaustivity and robustness of the set of features, ...

This process might take tens of hours, to be duplicated by the number of
node operators who would have to do the full-node vending switch. If you
consider the cognitive cost at the level of the Bitcoin ecosystem, it's far
less costly to implement and review a few lines of codes in Bitcoin Core.

> Developers should provide basic RBF policy options rather than attempting
to define what constitutes a good policy and removing the ability to
disable something when necessary.

Of course, this statement assumes there is a clear line between the
developers and the users. Developers are also Bitcoin users, and they're
modifying the software to suit their use-case needs. And that's exactly the
purpose of the 'full-rbf' PR I'm proposing, aiming to propose a "good"
policy for a Lightning node, without actually seeking to change the
default. If they're parties interested in implementing more RBF policy
options in Bitcoin Core, I think they're free to propose such changes and
invest the engineering effort to do so. If you're interested in advancing
the state of policy options in Bitcoin Core, there are a lot of interesting
resources available and communities to encourage you in the learning
process to contribute to the codebase [6].

Antoine

[0] https://dirtycow.ninja

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

[2] https://arxiv.org/pdf/2006.01418.pdf

[3] https://arxiv.org/pdf/2006.08513.pdf

[4]
https://lists.linuxfoundation.org/pipermail/lightning-dev/2021-May/003033.html

[5]
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-May/020493.html

[6] https://www.summerofbitcoin.org

Le jeu. 16 juin 2022 à 00:15, alicexbt <alicexbt at protonmail.com> a écrit :

> Hi Antoine,
>
>
> Thanks for opening the pull request to add support for full-rbf in Bitcoin
> Core. I have a disagreements with the approach and questions.
>
> Recent discussions among LN devs have brought back on the surface concerns
> about the security of multi-party funded transactions (coinjoins,
> dual-funded LN channels, on-chain DLCs, ...). It turns out there is a
> low-fruit, naive DoS vector playable against the funding flow of any such
> construction due to the lack of existent full-rbf transaction-relay
> topology on today's p2p network [0] [1].
>
>
> 1)If something relies on a policy which can be changed without breaking
> consensus rules, how is it secure in any case with or without full rbf? If
> I write a python script that expects user to enter char 'a' or 'b' but user
> can enter 'c' and there is no code to handle exceptions or other chars,
> will it be secure?
>
> 2)full-rbf is not default in the 2 open pull requests, so this experiment
> still relies on users changing RBF policies manually. If majority of nodes
> use default opt-in policy, how would this affect vulnerable projects?
>
> If you're a mining operator looking to increase your income, you might be
> interested to experiment with full-rbf as a policy.
>
>
> Miners can only increase their income if users replace transactions. 2-3%
> transactions are replaced with opt-in RBF, if someone did not replace
> earlier why would they do it now even with full RBF? Or even if we add some
> users in it who could not signal for some reasons, do you think it would be
> anything above 5%?
>
> If you're a Bitcoin user or business and you don't like full-rbf, please
> express an opinion on how it might affect your software/operations. I'm
> always interested to learn more about mempool and transaction-relay
> interactions with upper-layers and applications and to listen to feedback
> in those areas, and I guess a lot of other Bitcoin researchers/devs too. I
> know there have been a lot of concerns about full-rbf in the past, however
> I believe the Bitcoin ecosystem has matured a lot since then.
>
>
> I am not opposed to full-rbf; rather, I am opposed to the notion that
> full-rbf will solve all problems and the lack of basic options in Bitcoin
> Core to employ/disable different RBF policies. There is also a speculation
> about making full RBF default in an year which isn't relevant to discuss at
> this point without trying different RBF policies.
>
> I would suggest users to try Bitcoin Knots instead which already has an
> option to disable all RBF policies if required, opt-in and full RBF policy.
> This can also be done using GUI if not familiar with config option
> mempoolreplacement.
>
> The rationale in PR #16171 was insufficient to justify removing it in the
> first place, had 2 NACKs and was reopened to merge it. Why bother with a
> few lines of code that may allow someone disable it if required in local
> mempool since it's only useful when a big percentage of miners utilize it
> and essentially underused according to the PR author? Developers should
> provide basic RBF policy options rather than attempting to define what
> constitutes a good policy and removing the ability to disable something
> when necessary.
>
>
> /dev/fd0
>
> Sent with Proton Mail <https://proton.me/>; secure email.
>
> ------- Original Message -------
> On Tuesday, June 14th, 2022 at 5:55 AM, Antoine Riard via bitcoin-dev <
> bitcoin-dev at lists.linuxfoundation.org> wrote:
>
> Hi list,
>
> Recent discussions among LN devs have brought back on the surface concerns
> about the security of multi-party funded transactions (coinjoins,
> dual-funded LN channels, on-chain DLCs, ...). It turns out there is a
> low-fruit, naive DoS vector playable against the funding flow of any such
> construction due to the lack of existent full-rbf transaction-relay
> topology on today's p2p network [0] [1]. While it does not consist in a
> direct loss of funds, if exploited well I think it's annoying enough to
> inflict significant timevalue loss or fee-bumping waste
> to the future providers or distributed swarm of users doing multi-party
> funded transactions. Of course, it can be fixed one layer above by
> introducing either fidelity bonds or a reliable centralized coordinator,
> though at the price of an overhead per-participant ressources cost and loss
> in system openness [1].
>
> For that reason, I believe it would be beneficial to the flourishing of
> multi-party funded transactions to fix the Dos vector by seeing a subset of
> the network running full-rbf and enabling propagation of honest multi-party
> transactions to the interested miners, replacing potential non-signaling
> double-spend from a malicious counterparty. Moving towards that direction,
> I've submitted a small patch against Bitcoin Core enabling it to turn on
> full-rbf as a policy, still under review [3]. The default setting stays
> **false**, i.e keeping opt-in RBF as a default replacement policy. I've
> started to run the patch on a public node at 146.190.224.15.
>
> If you're a node operator curious to play with full-rbf, feel free to
> connect to this node or spawn up a toy, public node yourself. There is a
> ##uafrbf libera chat if you would like information on the settings or
> looking for full-rbf friends (though that step could be automated in the
> future by setting up a dedicated network bit and reserving a few outbound
> slots for them).
>
> If you're a mining operator looking to increase your income, you might be
> interested to experiment with full-rbf as a policy. Indeed, in the future I
> believe the multi-party transactions issuers who need full-rbf to secure
> their funding flow should connect by default to full-rbf peers. One can
> conjecture that their transactions are likely to be more compelling in
> their feerate as their liquidity needs are higher than the simple
> transaction. For today, I think we have really few standards and bitcoin
> softwares relying on multi-party funded transactions [4].
>
> If you're a Bitcoin user or business and you don't like full-rbf, please
> express an opinion on how it might affect your software/operations. I'm
> always interested to learn more about mempool and transaction-relay
> interactions with upper-layers and applications and to listen to feedback
> in those areas, and I guess a lot of other Bitcoin researchers/devs too. I
> know there have been a lot of concerns about full-rbf in the past, however
> I believe the Bitcoin ecosystem has matured a lot since then.
>
> Any mistakes or missing context is my own.
>
> Cheers,
> Antoine
>
> [0] For more info about replace-by-fee, see
> https://bitcoinops.org/en/topics/replace-by-fee/
>
> [1] For more details about the DoS vector, see
> https://lists.linuxfoundation.org/pipermail/lightning-dev/2021-May/003033.html
>
> [2] E.g I think it does not affect the Lightning Pool service, as there is
> a preliminary step where the participant funds are locked first in a 2-of-2
> with the coordinator before being committed in the multi-party batch
> transaction.
>
> [3] https://github.com/bitcoin/bitcoin/pull/25353
>
> [4] E.g DLCs :
> https://github.com/discreetlogcontracts/dlcspecs/blob/master/Transactions.md
> ; Lightning dual-funded channel :
> https://github.com/lightning/bolts/pull/851
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20220617/6775746f/attachment-0001.html>;

📅 Original date posted:2022-06-13 📝 Original message:Hi ...

2023-06-08T01:10:27+02:00

In reply to nevent1q…5lac
_________________________

📅 Original date posted:2022-06-13
📝 Original message:Hi list,

Recent discussions among LN devs have brought back on the surface concerns
about the security of multi-party funded transactions (coinjoins,
dual-funded LN channels, on-chain DLCs, ...). It turns out there is a
low-fruit, naive DoS vector playable against the funding flow of any such
construction due to the lack of existent full-rbf transaction-relay
topology on today's p2p network [0] [1]. While it does not consist in a
direct loss of funds, if exploited well I think it's annoying enough to
inflict significant timevalue loss or fee-bumping waste
to the future providers or distributed swarm of users doing multi-party
funded transactions. Of course, it can be fixed one layer above by
introducing either fidelity bonds or a reliable centralized coordinator,
though at the price of an overhead per-participant ressources cost and loss
in system openness [1].

For that reason, I believe it would be beneficial to the flourishing of
multi-party funded transactions to fix the Dos vector by seeing a subset of
the network running full-rbf and enabling propagation of honest multi-party
transactions to the interested miners, replacing potential non-signaling
double-spend from a malicious counterparty. Moving towards that direction,
I've submitted a small patch against Bitcoin Core enabling it to turn on
full-rbf as a policy, still under review [3]. The default setting stays
**false**, i.e keeping opt-in RBF as a default replacement policy. I've
started to run the patch on a public node at 146.190.224.15.

If you're a node operator curious to play with full-rbf, feel free to
connect to this node or spawn up a toy, public node yourself. There is a
##uafrbf libera chat if you would like information on the settings or
looking for full-rbf friends (though that step could be automated in the
future by setting up a dedicated network bit and reserving a few outbound
slots for them).

If you're a mining operator looking to increase your income, you might be
interested to experiment with full-rbf as a policy. Indeed, in the future I
believe the multi-party transactions issuers who need full-rbf to secure
their funding flow should connect by default to full-rbf peers. One can
conjecture that their transactions are likely to be more compelling in
their feerate as their liquidity needs are higher than the simple
transaction. For today, I think we have really few standards and bitcoin
softwares relying on multi-party funded transactions [4].

If you're a Bitcoin user or business and you don't like full-rbf, please
express an opinion on how it might affect your software/operations. I'm
always interested to learn more about mempool and transaction-relay
interactions with upper-layers and applications and to listen to feedback
in those areas, and I guess a lot of other Bitcoin researchers/devs too. I
know there have been a lot of concerns about full-rbf in the past, however
I believe the Bitcoin ecosystem has matured a lot since then.

Any mistakes or missing context is my own.

Cheers,
Antoine

[0] For more info about replace-by-fee, see
https://bitcoinops.org/en/topics/replace-by-fee/

[1] For more details about the DoS vector, see
https://lists.linuxfoundation.org/pipermail/lightning-dev/2021-May/003033.html

[2] E.g I think it does not affect the Lightning Pool service, as there is
a preliminary step where the participant funds are locked first in a 2-of-2
with the coordinator before being committed in the multi-party batch
transaction.

[3] https://github.com/bitcoin/bitcoin/pull/25353

[4] E.g DLCs :
https://github.com/discreetlogcontracts/dlcspecs/blob/master/Transactions.md
; Lightning dual-funded channel :
https://github.com/lightning/bolts/pull/851
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20220613/1a047265/attachment.html>;

📅 Original date posted:2021-09-26 📝 Original message:Hi ...

2023-06-08T00:59:20+02:00

In reply to nevent1q…t696
_________________________

📅 Original date posted:2021-09-26
📝 Original message:Hi Gloria,

Thanks for your answers,

> In summary, it seems that the decisions that might still need
> attention/input from devs on this mailing list are:
> 1. Whether we should start with multiple-parent-1-child or
1-parent-1-child.
> 2. Whether it's ok to require that the child not have conflicts with
> mempool transactions.

Yes 1) it would be good to have inputs of more potential users of package
acceptance . And 2) I think it's more a matter of clearer wording of the
proposal.

However, see my final point on the relaxation around "unconfirmed inputs"
which might in fact alter our current block construction strategy.

> Right, the fact that we essentially always choose the first-seen witness
is
> an unfortunate limitation that exists already. Adding package mempool
> accept doesn't worsen this, but the procedure in the future is to replace
> the witness when it makes sense economically. We can also add logic to
> allow package feerate to pay for witness replacements as well. This is
> pretty far into the future, though.

Yes I agree package mempool doesn't worsen this. And it's not an issue for
current LN as you can't significantly inflate a spending witness for the
2-of-2 funding output.
However, it might be an issue for multi-party protocol where the spending
script has alternative branches with asymmetric valid witness weights.
Taproot should ease that kind of script so hopefully we would deploy
wtxid-replacement not too far in the future.

> I could be misunderstanding, but an attacker wouldn't be able to
> batch-attack like this. Alice's package only conflicts with A' + D', not
A'
> + B' + C' + D'. She only needs to pay for evicting 2 transactions.

Yeah I can be clearer, I think you have 2 pinning attacks scenarios to
consider.

In LN, if you're trying to confirm a commitment transaction to time-out or
claim on-chain a HTLC and the timelock is near-expiration, you should be
ready to pay in commitment+2nd-stage HTLC transaction fees as much as the
value offered by the HTLC.

Following this security assumption, an attacker can exploit it by targeting
together commitment transactions from different channels by blocking them
under a high-fee child, of which the fee value
is equal to the top-value HTLC + 1. Victims's fee-bumping logics won't
overbid as it's not worthy to offer fees beyond their competed HTLCs. Apart
from observing mempools state, victims can't learn they're targeted by the
same attacker.

To draw from the aforementioned topology, Mallory broadcasts A' + B' + C' +
D', where A' conflicts with Alice's P1, B' conflicts with Bob's P2, C'
conflicts with Caroll's P3. Let's assume P1 is confirming the top-value
HTLC of the set. If D' fees is higher than P1 + 1, it won't be rational for
Alice or Bob or Caroll to keep offering competing feerates. Mallory will be
at loss on stealing P1, as she has paid more in fees but will realize a
gain on P2+P3.

In this model, Alice is allowed to evict those 2 transactions (A' + D') but
as she is economically-bounded she won't succeed.

Mallory is maliciously exploiting RBF rule 3 on absolute fee. I think this
1st pinning scenario is correct and "lucractive" when you sum the global
gain/loss.

There is a 2nd attack scenario where A + B + C + D, where D is the child of
A,B,C. All those transactions are honestly issued by Alice. Once A + B + C
+ D are propagated in network mempools, Mallory is able to replace A + D
with A' + D' where D' is paying a higher fee. This package A' + D' will
confirm soon if D feerate was compelling but Mallory succeeds in delaying
the confirmation
of B + C for one or more blocks. As B + C are pre-signed commitments with a
low-fee rate they won't confirm without Alice issuing a new child E.
Mallory can repeat the same trick by broadcasting
B' + E' and delay again the confirmation of C.

If the remaining package pending HTLC has a higher-value than all the
malicious fees over-bid, Mallory should realize a gain. With this 2nd
pinning attack, the malicious entity buys confirmation delay of your
packaged-together commitments.

Assuming those attacks are correct, I'm leaning towards being conservative
with the LDK broadcast backend. Though once again, other L2 devs have
likely other use-cases and opinions :)

> B' only needs to pay for itself in this case.

Yes I think it's a nice discount when UTXO is single-owned. In the context
of shared-owned UTXO (e.g LN), you might not if there is an in-mempool
package already spending the UTXO and have to assume the worst-case
scenario. I.e have B' committing enough fee to pay for A' replacement
bandwidth. I think we can't do that much for this case...

> If a package meets feerate requirements as a
package, the parents in the transaction are allowed to replace-by-fee
mempool transactions. The child cannot replace mempool transactions."

I agree with the Mallory-vs-Alice case. Though if Alice broadcasts A+B' to
replace A+B because the first broadcast isn't satisfying anymore due to
mempool spikes ? Assuming B' fees is enough, I think that case as child B'
replacing in-mempool transaction B. Which I understand going against "The
child cannot replace mempool transactions".

Maybe wording could be a bit clearer ?

> While it would be nice to have full RBF, malleability of the child won't
> block RBF here. If we're trying to replace A', we only require that A'
> signals replaceability, and don't mind if its child doesn't.

Yes, it sounds good.

> Yes, A+C+D pays 2500sat more in fees, but it is also 1000vB larger. A
miner
> should prefer to utilize their block space more effectively.

If your mempool is empty and only composed of A+C+D or A+B, I think taking
A+C+D is the most efficient block construction you can come up with as a
miner ?

> No, because we don't use that model.

Can you describe what miner model we are using ? Like the block
construction strategy implemented by `addPackagesTxs` or also encompassing
our current mempool acceptance policy, which I think rely on absolute fee
over ancestor score in case of replacement ?

I think this point is worthy to discuss as otherwise we might downgrade the
efficiency of our current block construction strategy in periods of
near-empty mempools. A knowledge which could be discreetly leveraged by a
miner to gain an advantage on the rest of the mining ecosystem.

Note, I think we *might* have to go in this direction if we want to replace
replace-by-fee by replace-by-feerate or replace-by-ancestor and solve
in-depth pinning attacks. Though if we do so,
IMO we would need more thoughts.

I think we could restrain package acceptance to only confirmed inputs for
now and revisit later this point ? For LN-anchor, you can assume that the
fee-bumping UTXO feeding the CPFP is already
confirmed. Or are there currently-deployed use-cases which would benefit
from your proposed Rule #2 ?

Antoine

Le jeu. 23 sept. 2021 à 11:36, Gloria Zhao <gloriajzhao at gmail.com> a écrit :

> Hi Antoine,
>
> Thanks as always for your input. I'm glad we agree on so much!
>
> In summary, it seems that the decisions that might still need
> attention/input from devs on this mailing list are:
> 1. Whether we should start with multiple-parent-1-child or
> 1-parent-1-child.
> 2. Whether it's ok to require that the child not have conflicts with
> mempool transactions.
>
> Responding to your comments...
>
> > IIUC, you have package A+B, during the dedup phase early in
> `AcceptMultipleTransactions` if you observe same-txid-different-wtixd A'
> and A' is higher feerate than A, you trim A and replace by A' ?
>
> > I think this approach is safe, the one who appears unsafe to me is when
> A' has a _lower_ feerate, even if A' is already accepted by our mempool ?
> In that case iirc that would be a pinning.
>
> Right, the fact that we essentially always choose the first-seen witness
> is an unfortunate limitation that exists already. Adding package mempool
> accept doesn't worsen this, but the procedure in the future is to replace
> the witness when it makes sense economically. We can also add logic to
> allow package feerate to pay for witness replacements as well. This is
> pretty far into the future, though.
>
> > It sounds uneconomical for an attacker but I think it's not when you
> consider than you can "batch" attack against multiple honest
> counterparties. E.g, Mallory broadcast A' + B' + C' + D' where A' conflicts
> with Alice's honest package P1, B' conflicts with Bob's honest package P2,
> C' conflicts with Caroll's honest package P3. And D' is a high-fee child of
> A' + B' + C'.
>
> > If D' is higher-fee than P1 or P2 or P3 but inferior to the sum of HTLCs
> confirmed by P1+P2+P3, I think it's lucrative for the attacker ?
>
> I could be misunderstanding, but an attacker wouldn't be able to
> batch-attack like this. Alice's package only conflicts with A' + D', not A'
> + B' + C' + D'. She only needs to pay for evicting 2 transactions.
>
> > Do we assume that broadcasted packages are "honest" by default and that
> the parent(s) always need the child to pass the fee checks, that way saving
> the processing of individual transactions which are expected to fail in 99%
> of cases or more ad hoc composition of packages at relay ?
> > I think this point is quite dependent on the p2p packages format/logic
> we'll end up on and that we should feel free to revisit it later ?
>
> I think it's the opposite; there's no way for us to assume that p2p
> packages will be "honest." I'd like to have two things before we expose on
> P2P: (1) ensure that the amount of resources potentially allocated for
> package validation isn't disproportionately higher than that of single
> transaction validation and (2) only use package validation when we're
> unsatisifed with the single validation result, e.g. we might get better
> fees.
> Yes, let's revisit this later :)
>
> > Yes, if you receive A+B, and A is already in-mempoo, I agree you can
> discard its feerate as B should pay for all fees checked on its own. Where
> I'm unclear is when you have in-mempool A+B and receive A+B'. Should B'
> have a fee high enough to cover the bandwidth penalty replacement
> (`PaysForRBF`, 2nd check) of both A+B' or only B' ?
>
> B' only needs to pay for itself in this case.
>
> > > Do we want the child to be able to replace mempool transactions as
> well?
>
> > If we mean when you have replaceable A+B then A'+B' try to replace with
> a higher-feerate ? I think that's exactly the case we need for Lightning as
> A+B is coming from Alice and A'+B' is coming from Bob :/
>
> Let me clarify this because I can see that my wording was ambiguous, and
> then please let me know if it fits Lightning's needs?
>
> In my proposal, I wrote "If a package meets feerate requirements as a
> package, the parents in the transaction are allowed to replace-by-fee
> mempool transactions. The child cannot replace mempool transactions." What
> I meant was: the package can replace mempool transactions if any of the
> parents conflict with mempool transactions. The child cannot not conflict
> with any mempool transactions.
> The Lightning use case this attempts to address is: Alice and Mallory are
> LN counterparties, and have packages A+B and A'+B', respectively. A and A'
> are their commitment transactions and conflict with each other; they have
> shared inputs and different txids.
> B spends Alice's anchor output from A. B' spends Mallory's anchor output
> from A'. Thus, B and B' do not conflict with each other.
> Alice can broadcast her package, A+B, to replace Mallory's package, A'+B',
> since B doesn't conflict with the mempool.
>
> Would this be ok?
>
> > The second option, a child of A', In the LN case I think the CPFP is
> attached on one's anchor output.
>
> While it would be nice to have full RBF, malleability of the child won't
> block RBF here. If we're trying to replace A', we only require that A'
> signals replaceability, and don't mind if its child doesn't.
>
> > > B has an ancestor score of 10sat/vb and D has an
> > > ancestor score of ~2.9sat/vb. Since D's ancestor score is lower than
> B's,
> > > it fails the proposed package RBF Rule #2, so this package would be
> > > rejected. Does this meet your expectations?
>
> > Well what sounds odd to me, in my example, we fail D even if it has a
> higher-fee than B. Like A+B absolute fees are 2000 sats and A+C+D absolute
> fees are 4500 sats ?
>
> Yes, A+C+D pays 2500sat more in fees, but it is also 1000vB larger. A
> miner should prefer to utilize their block space more effectively.
>
> > Is this compatible with a model where a miner prioritizes absolute fees
> over ancestor score, in the case that mempools aren't full-enough to
> fulfill a block ?
>
> No, because we don't use that model.
>
> Thanks,
> Gloria
>
> On Thu, Sep 23, 2021 at 5:29 AM Antoine Riard <antoine.riard at gmail.com>
> wrote:
>
>> > Correct, if B+C is too low feerate to be accepted, we will reject it. I
>> > prefer this because it is incentive compatible: A can be mined by
>> itself,
>> > so there's no reason to prefer A+B+C instead of A.
>> > As another way of looking at this, consider the case where we do accept
>> > A+B+C and it sits at the "bottom" of our mempool. If our mempool reaches
>> > capacity, we evict the lowest descendant feerate transactions, which are
>> > B+C in this case. This gives us the same resulting mempool, with A and
>> not
>> > B+C.
>>
>> I agree here. Doing otherwise, we might evict other transactions mempool
>> in `MempoolAccept::Finalize` with a higher-feerate than B+C while those
>> evicted transactions are the most compelling for block construction.
>>
>> I thought at first missing this acceptance requirement would break a
>> fee-bumping scheme like Parent-Pay-For-Child where a high-fee parent is
>> attached to a child signed with SIGHASH_ANYONECANPAY but in this case the
>> child fee is capturing the parent value. I can't think of other fee-bumping
>> schemes potentially affected. If they do exist I would say they're wrong in
>> their design assumptions.
>>
>> > If or when we have witness replacement, the logic is: if the individual
>> > transaction is enough to replace the mempool one, the replacement will
>> > happen during the preceding individual transaction acceptance, and
>> > deduplication logic will work. Otherwise, we will try to deduplicate by
>> > wtxid, see that we need a package witness replacement, and use the
>> package
>> > feerate to evaluate whether this is economically rational.
>>
>> IIUC, you have package A+B, during the dedup phase early in
>> `AcceptMultipleTransactions` if you observe same-txid-different-wtixd A'
>> and A' is higher feerate than A, you trim A and replace by A' ?
>>
>> I think this approach is safe, the one who appears unsafe to me is when
>> A' has a _lower_ feerate, even if A' is already accepted by our mempool ?
>> In that case iirc that would be a pinning.
>>
>> Good to see progress on witness replacement before we see usage of
>> Taproot tree in the context of multi-party, where a malicious counterparty
>> inflates its witness to jam a honest spending.
>>
>> (Note, the commit linked currently points nowhere :))
>>
>>
>> > Please note that A may replace A' even if A' has higher fees than A
>> > individually, because the proposed package RBF utilizes the fees and
>> size
>> > of the entire package. This just requires E to pay enough fees, although
>> > this can be pretty high if there are also potential B' and C' competing
>> > commitment transactions that we don't know about.
>>
>> Ah right, if the package acceptance waives `PaysMoreThanConflicts` for
>> the individual check on A, the honest package should replace the pinning
>> attempt. I've not fully parsed the proposed implementation yet.
>>
>> Though note, I think it's still unsafe for a Lightning
>> multi-commitment-broadcast-as-one-package as a malicious A' might have an
>> absolute fee higher than E. It sounds uneconomical for
>> an attacker but I think it's not when you consider than you can "batch"
>> attack against multiple honest counterparties. E.g, Mallory broadcast A' +
>> B' + C' + D' where A' conflicts with Alice's honest package P1, B'
>> conflicts with Bob's honest package P2, C' conflicts with Caroll's honest
>> package P3. And D' is a high-fee child of A' + B' + C'.
>>
>> If D' is higher-fee than P1 or P2 or P3 but inferior to the sum of HTLCs
>> confirmed by P1+P2+P3, I think it's lucrative for the attacker ?
>>
>> > So far, my understanding is that multi-parent-1-child is desired for
>> > batched fee-bumping (
>> > https://github.com/bitcoin/bitcoin/pull/22674#issuecomment-897951289)
>> and
>> > I've also seen your response which I have less context on (
>> > https://github.com/bitcoin/bitcoin/pull/22674#issuecomment-900352202).
>> That
>> > being said, I am happy to create a new proposal for 1 parent + 1 child
>> > (which would be slightly simpler) and plan for moving to
>> > multi-parent-1-child later if that is preferred. I am very interested in
>> > hearing feedback on that approach.
>>
>> I think batched fee-bumping is okay as long as you don't have
>> time-sensitive outputs encumbering your commitment transactions. For the
>> reasons mentioned above, I think that's unsafe.
>>
>> What I'm worried about is L2 developers, potentially not aware about all
>> the mempool subtleties blurring the difference and always batching their
>> broadcast by default.
>>
>> IMO, a good thing by restraining to 1-parent + 1 child, we artificially
>> constraint L2 design space for now and minimize risks of unsafe usage of
>> the package API :)
>>
>> I think that's a point where it would be relevant to have the opinion of
>> more L2 devs.
>>
>> > I think there is a misunderstanding here - let me describe what I'm
>> > proposing we'd do in this situation: we'll try individual submission
>> for A,
>> > see that it fails due to "insufficient fees." Then, we'll try package
>> > validation for A+B and use package RBF. If A+B pays enough, it can still
>> > replace A'. If A fails for a bad signature, we won't look at B or A+B.
>> Does
>> > this meet your expectations?
>>
>> Yes there was a misunderstanding, I think this approach is correct, it's
>> more a question of performance. Do we assume that broadcasted packages are
>> "honest" by default and that the parent(s) always need the child to pass
>> the fee checks, that way saving the processing of individual transactions
>> which are expected to fail in 99% of cases or more ad hoc composition of
>> packages at relay ?
>>
>> I think this point is quite dependent on the p2p packages format/logic
>> we'll end up on and that we should feel free to revisit it later ?
>>
>>
>> > What problem are you trying to solve by the package feerate *after*
>> dedup
>> rule ?
>> > My understanding is that an in-package transaction might be already in
>> the mempool. Therefore, to compute a correct RBF penalty replacement, the
>> vsize of this transaction could be discarded lowering the cost of package
>> RBF.
>>
>> > I'm proposing that, when a transaction has already been submitted to
>> > mempool, we would ignore both its fees and vsize when calculating
>> package
>> > feerate.
>>
>> Yes, if you receive A+B, and A is already in-mempoo, I agree you can
>> discard its feerate as B should pay for all fees checked on its own. Where
>> I'm unclear is when you have in-mempool A+B and receive A+B'. Should B'
>> have a fee high enough to cover the bandwidth penalty replacement
>> (`PaysForRBF`, 2nd check) of both A+B' or only B' ?
>>
>> If you have a second-layer like current Lightning, you might have a
>> counterparty commitment to replace and should always expect to have to pay
>> for parent replacement bandwidth.
>>
>> Where a potential discount sounds interesting is when you have an
>> univoque state on the first-stage of transactions. E.g DLC's funding
>> transaction which might be CPFP by any participant iirc.
>>
>> > Note that, if C' conflicts with C, it also conflicts with D, since D is
>> a
>> > descendant of C and would thus need to be evicted along with it.
>>
>> Ah once again I think it's a misunderstanding without the code under my
>> eyes! If we do C' `PreChecks`, solve the conflicts provoked by it, i.e mark
>> for potential eviction D and don't consider it for future conflicts in the
>> rest of the package, I think D' `PreChecks` should be good ?
>>
>> > More generally, this example is surprising to me because I didn't think
>> > packages would be used to fee-bump replaceable transactions. Do we want
>> the
>> > child to be able to replace mempool transactions as well?
>>
>> If we mean when you have replaceable A+B then A'+B' try to replace with a
>> higher-feerate ? I think that's exactly the case we need for Lightning as
>> A+B is coming from Alice and A'+B' is coming from Bob :/
>>
>> > I'm not sure what you mean? Let's say we have a package of parent A +
>> child
>> > B, where A is supposed to replace a mempool transaction A'. Are you
>> saying
>> > that counterparties are able to malleate the package child B, or a
>> child of
>> > A'?
>>
>> The second option, a child of A', In the LN case I think the CPFP is
>> attached on one's anchor output.
>>
>> I think it's good if we assume the
>> solve-conflicts-after-parent's`'PreChecks` mentioned above or fixing
>> inherited signaling or full-rbf ?
>>
>> > Sorry, I don't understand what you mean by "preserve the package
>> > integrity?" Could you elaborate?
>>
>> After thinking the relaxation about the "new" unconfirmed input is not
>> linked to trimming but I would say more to the multi-parent support.
>>
>> Let's say you have A+B trying to replace C+D where B is also spending
>> already in-mempool E. To succeed, you need to waive the no-new-unconfirmed
>> input as D isn't spending E.
>>
>> So good, I think we agree on the problem description here.
>>
>> > I am in agreement with your calculations but unsure if we disagree on
>> the
>> > expected outcome. Yes, B has an ancestor score of 10sat/vb and D has an
>> > ancestor score of ~2.9sat/vb. Since D's ancestor score is lower than
>> B's,
>> > it fails the proposed package RBF Rule #2, so this package would be
>> > rejected. Does this meet your expectations?
>>
>> Well what sounds odd to me, in my example, we fail D even if it has a
>> higher-fee than B. Like A+B absolute fees are 2000 sats and A+C+D absolute
>> fees are 4500 sats ?
>>
>> Is this compatible with a model where a miner prioritizes absolute fees
>> over ancestor score, in the case that mempools aren't full-enough to
>> fulfill a block ?
>>
>> Let me know if I can clarify a point.
>>
>> Antoine
>>
>> Le lun. 20 sept. 2021 à 11:10, Gloria Zhao <gloriajzhao at gmail.com> a
>> écrit :
>>
>>>
>>> Hi Antoine,
>>>
>>> First of all, thank you for the thorough review. I appreciate your
>>> insight on LN requirements.
>>>
>>> > IIUC, you have a package A+B+C submitted for acceptance and A is
>>> already in your mempool. You trim out A from the package and then evaluate
>>> B+C.
>>>
>>> > I think this might be an issue if A is the higher-fee element of the
>>> ABC package. B+C package fees might be under the mempool min fee and will
>>> be rejected, potentially breaking the acceptance expectations of the
>>> package issuer ?
>>>
>>> Correct, if B+C is too low feerate to be accepted, we will reject it. I
>>> prefer this because it is incentive compatible: A can be mined by itself,
>>> so there's no reason to prefer A+B+C instead of A.
>>> As another way of looking at this, consider the case where we do accept
>>> A+B+C and it sits at the "bottom" of our mempool. If our mempool reaches
>>> capacity, we evict the lowest descendant feerate transactions, which are
>>> B+C in this case. This gives us the same resulting mempool, with A and not
>>> B+C.
>>>
>>>
>>> > Further, I think the dedup should be done on wtxid, as you might have
>>> multiple valid witnesses. Though with varying vsizes and as such offering
>>> different feerates.
>>>
>>> I agree that variations of the same package with different witnesses is
>>> a case that must be handled. I consider witness replacement to be a project
>>> that can be done in parallel to package mempool acceptance because being
>>> able to accept packages does not worsen the problem of a
>>> same-txid-different-witness "pinning" attack.
>>>
>>> If or when we have witness replacement, the logic is: if the individual
>>> transaction is enough to replace the mempool one, the replacement will
>>> happen during the preceding individual transaction acceptance, and
>>> deduplication logic will work. Otherwise, we will try to deduplicate by
>>> wtxid, see that we need a package witness replacement, and use the package
>>> feerate to evaluate whether this is economically rational.
>>>
>>> See the #22290 "handle package transactions already in mempool" commit (
>>> https://github.com/bitcoin/bitcoin/pull/22290/commits/fea75a2237b46cf76145242fecad7e274bfcb5ff),
>>> which handles the case of same-txid-different-witness by simply using the
>>> transaction in the mempool for now, with TODOs for what I just described.
>>>
>>>
>>> > I'm not clearly understanding the accepted topologies. By "parent and
>>> child to share a parent", do you mean the set of transactions A, B, C,
>>> where B is spending A and C is spending A and B would be correct ?
>>>
>>> Yes, that is what I meant. Yes, that would a valid package under these
>>> rules.
>>>
>>> > If yes, is there a width-limit introduced or we fallback on
>>> MAX_PACKAGE_COUNT=25 ?
>>>
>>> No, there is no limit on connectivity other than "child with all
>>> unconfirmed parents." We will enforce MAX_PACKAGE_COUNT=25 and child's
>>> in-mempool + in-package ancestor limits.
>>>
>>>
>>> > Considering the current Core's mempool acceptance rules, I think CPFP
>>> batching is unsafe for LN time-sensitive closure. A malicious tx-relay
>>> jamming successful on one channel commitment transaction would contamine
>>> the remaining commitments sharing the same package.
>>>
>>> > E.g, you broadcast the package A+B+C+D+E where A,B,C,D are commitment
>>> transactions and E a shared CPFP. If a malicious A' transaction has a
>>> better feerate than A, the whole package acceptance will fail. Even if A'
>>> confirms in the following block,
>>> the propagation and confirmation of B+C+D have been delayed. This could
>>> carry on a loss of funds.
>>>
>>> Please note that A may replace A' even if A' has higher fees than A
>>> individually, because the proposed package RBF utilizes the fees and size
>>> of the entire package. This just requires E to pay enough fees, although
>>> this can be pretty high if there are also potential B' and C' competing
>>> commitment transactions that we don't know about.
>>>
>>>
>>> > IMHO, I'm leaning towards deploying during a first phase
>>> 1-parent/1-child. I think it's the most conservative step still improving
>>> second-layer safety.
>>>
>>> So far, my understanding is that multi-parent-1-child is desired for
>>> batched fee-bumping (
>>> https://github.com/bitcoin/bitcoin/pull/22674#issuecomment-897951289)
>>> and I've also seen your response which I have less context on (
>>> https://github.com/bitcoin/bitcoin/pull/22674#issuecomment-900352202).
>>> That being said, I am happy to create a new proposal for 1 parent + 1 child
>>> (which would be slightly simpler) and plan for moving to
>>> multi-parent-1-child later if that is preferred. I am very interested in
>>> hearing feedback on that approach.
>>>
>>>
>>> > If A+B is submitted to replace A', where A pays 0 sats, B pays 200
>>> sats and A' pays 100 sats. If we apply the individual RBF on A, A+B
>>> acceptance fails. For this reason I think the individual RBF should be
>>> bypassed and only the package RBF apply ?
>>>
>>> I think there is a misunderstanding here - let me describe what I'm
>>> proposing we'd do in this situation: we'll try individual submission for A,
>>> see that it fails due to "insufficient fees." Then, we'll try package
>>> validation for A+B and use package RBF. If A+B pays enough, it can still
>>> replace A'. If A fails for a bad signature, we won't look at B or A+B. Does
>>> this meet your expectations?
>>>
>>>
>>> > What problem are you trying to solve by the package feerate *after*
>>> dedup rule ?
>>> > My understanding is that an in-package transaction might be already in
>>> the mempool. Therefore, to compute a correct RBF penalty replacement, the
>>> vsize of this transaction could be discarded lowering the cost of package
>>> RBF.
>>>
>>> I'm proposing that, when a transaction has already been submitted to
>>> mempool, we would ignore both its fees and vsize when calculating package
>>> feerate. In example G2, we shouldn't count M1 fees after its submission to
>>> mempool, since M1's fees have already been used to pay for its individual
>>> bandwidth, and it shouldn't be used again to pay for P2 and P3's bandwidth.
>>> We also shouldn't count its vsize, since it has already been paid for.
>>>
>>>
>>> > I think this is a footgunish API, as if a package issuer send the
>>> multiple-parent-one-child package A,B,C,D where D is the child of A,B,C.
>>> Then try to broadcast the higher-feerate C'+D' package, it should be
>>> rejected. So it's breaking the naive broadcaster assumption that a
>>> higher-feerate/higher-fee package always replaces ?
>>>
>>> Note that, if C' conflicts with C, it also conflicts with D, since D is
>>> a descendant of C and would thus need to be evicted along with it.
>>> Implicitly, D' would not be in conflict with D.
>>> More generally, this example is surprising to me because I didn't think
>>> packages would be used to fee-bump replaceable transactions. Do we want the
>>> child to be able to replace mempool transactions as well? This can be
>>> implemented with a bit of additional logic.
>>>
>>> > I think this is unsafe for L2s if counterparties have malleability of
>>> the child transaction. They can block your package replacement by
>>> opting-out from RBF signaling. IIRC, LN's "anchor output" presents such an
>>> ability.
>>>
>>> I'm not sure what you mean? Let's say we have a package of parent A +
>>> child B, where A is supposed to replace a mempool transaction A'. Are you
>>> saying that counterparties are able to malleate the package child B, or a
>>> child of A'? If they can malleate a child of A', that shouldn't matter as
>>> long as A' is signaling replacement. This would be handled identically with
>>> full RBF and what Core currently implements.
>>>
>>> > I think this is an issue brought by the trimming during the dedup
>>> phase. If we preserve the package integrity, only re-using the tx-level
>>> checks results of already in-mempool transactions to gain in CPU time we
>>> won't have this issue. Package childs can add unconfirmed inputs as long as
>>> they're in-package, the bip125 rule2 is only evaluated against parents ?
>>>
>>> Sorry, I don't understand what you mean by "preserve the package
>>> integrity?" Could you elaborate?
>>>
>>> > Let's say you have in-mempool A, B where A pays 10 sat/vb for 100
>>> vbytes and B pays 10 sat/vb for 100 vbytes. You have the candidate
>>> replacement D spending both A and C where D pays 15sat/vb for 100 vbytes
>>> and C pays 1 sat/vb for 1000 vbytes.
>>>
>>> > Package A + B ancestor score is 10 sat/vb.
>>>
>>> > D has a higher feerate/absolute fee than B.
>>>
>>> > Package A + C + D ancestor score is ~ 3 sat/vb ((A's 1000 sats + C's
>>> 1000 sats + D's 1500 sats) / A's 100 vb + C's 1000 vb + D's 100 vb)
>>>
>>> I am in agreement with your calculations but unsure if we disagree on
>>> the expected outcome. Yes, B has an ancestor score of 10sat/vb and D has an
>>> ancestor score of ~2.9sat/vb. Since D's ancestor score is lower than B's,
>>> it fails the proposed package RBF Rule #2, so this package would be
>>> rejected. Does this meet your expectations?
>>>
>>> Thank you for linking to projects that might be interested in package
>>> relay :)
>>>
>>> Thanks,
>>> Gloria
>>>
>>> On Mon, Sep 20, 2021 at 12:16 AM Antoine Riard <antoine.riard at gmail.com>
>>> wrote:
>>>
>>>> Hi Gloria,
>>>>
>>>> > A package may contain transactions that are already in the mempool. We
>>>> > remove
>>>> > ("deduplicate") those transactions from the package for the purposes
>>>> of
>>>> > package
>>>> > mempool acceptance. If a package is empty after deduplication, we do
>>>> > nothing.
>>>>
>>>> IIUC, you have a package A+B+C submitted for acceptance and A is
>>>> already in your mempool. You trim out A from the package and then evaluate
>>>> B+C.
>>>>
>>>> I think this might be an issue if A is the higher-fee element of the
>>>> ABC package. B+C package fees might be under the mempool min fee and will
>>>> be rejected, potentially breaking the acceptance expectations of the
>>>> package issuer ?
>>>>
>>>> Further, I think the dedup should be done on wtxid, as you might have
>>>> multiple valid witnesses. Though with varying vsizes and as such offering
>>>> different feerates.
>>>>
>>>> E.g you're going to evaluate the package A+B and A' is already in your
>>>> mempool with a bigger valid witness. You trim A based on txid, then you
>>>> evaluate A'+B, which fails the fee checks. However, evaluating A+B would
>>>> have been a success.
>>>>
>>>> AFAICT, the dedup rationale would be to save on CPU time/IO disk, to
>>>> avoid repeated signatures verification and parent UTXOs fetches ? Can we
>>>> achieve the same goal by bypassing tx-level checks for already-in txn while
>>>> conserving the package integrity for package-level checks ?
>>>>
>>>> > Note that it's possible for the parents to be
>>>> > indirect
>>>> > descendants/ancestors of one another, or for parent and child to
>>>> share a
>>>> > parent,
>>>> > so we cannot make any other topology assumptions.
>>>>
>>>> I'm not clearly understanding the accepted topologies. By "parent and
>>>> child to share a parent", do you mean the set of transactions A, B, C,
>>>> where B is spending A and C is spending A and B would be correct ?
>>>>
>>>> If yes, is there a width-limit introduced or we fallback on
>>>> MAX_PACKAGE_COUNT=25 ?
>>>>
>>>> IIRC, one rationale to come with this topology limitation was to lower
>>>> the DoS risks when potentially deploying p2p packages.
>>>>
>>>> Considering the current Core's mempool acceptance rules, I think CPFP
>>>> batching is unsafe for LN time-sensitive closure. A malicious tx-relay
>>>> jamming successful on one channel commitment transaction would contamine
>>>> the remaining commitments sharing the same package.
>>>>
>>>> E.g, you broadcast the package A+B+C+D+E where A,B,C,D are commitment
>>>> transactions and E a shared CPFP. If a malicious A' transaction has a
>>>> better feerate than A, the whole package acceptance will fail. Even if A'
>>>> confirms in the following block,
>>>> the propagation and confirmation of B+C+D have been delayed. This could
>>>> carry on a loss of funds.
>>>>
>>>> That said, if you're broadcasting commitment transactions without
>>>> time-sensitive HTLC outputs, I think the batching is effectively a fee
>>>> saving as you don't have to duplicate the CPFP.
>>>>
>>>> IMHO, I'm leaning towards deploying during a first phase
>>>> 1-parent/1-child. I think it's the most conservative step still improving
>>>> second-layer safety.
>>>>
>>>> > *Rationale*: It would be incorrect to use the fees of transactions
>>>> that are
>>>> > already in the mempool, as we do not want a transaction's fees to be
>>>> > double-counted for both its individual RBF and package RBF.
>>>>
>>>> I'm unsure about the logical order of the checks proposed.
>>>>
>>>> If A+B is submitted to replace A', where A pays 0 sats, B pays 200 sats
>>>> and A' pays 100 sats. If we apply the individual RBF on A, A+B acceptance
>>>> fails. For this reason I think the individual RBF should be bypassed and
>>>> only the package RBF apply ?
>>>>
>>>> Note this situation is plausible, with current LN design, your
>>>> counterparty can have a commitment transaction with a better fee just by
>>>> selecting a higher `dust_limit_satoshis` than yours.
>>>>
>>>> > Examples F and G [14] show the same package, but P1 is submitted
>>>> > individually before
>>>> > the package in example G. In example F, we can see that the 300vB
>>>> package
>>>> > pays
>>>> > an additional 200sat in fees, which is not enough to pay for its own
>>>> > bandwidth
>>>> > (BIP125#4). In example G, we can see that P1 pays enough to replace
>>>> M1, but
>>>> > using P1's fees again during package submission would make it look
>>>> like a
>>>> > 300sat
>>>> > increase for a 200vB package. Even including its fees and size would
>>>> not be
>>>> > sufficient in this example, since the 300sat looks like enough for
>>>> the 300vB
>>>> > package. The calculcation after deduplication is 100sat increase for a
>>>> > package
>>>> > of size 200vB, which correctly fails BIP125#4. Assume all
>>>> transactions have
>>>> > a
>>>> > size of 100vB.
>>>>
>>>> What problem are you trying to solve by the package feerate *after*
>>>> dedup rule ?
>>>>
>>>> My understanding is that an in-package transaction might be already in
>>>> the mempool. Therefore, to compute a correct RBF penalty replacement, the
>>>> vsize of this transaction could be discarded lowering the cost of package
>>>> RBF.
>>>>
>>>> If we keep a "safe" dedup mechanism (see my point above), I think this
>>>> discount is justified, as the validation cost of node operators is paid for
>>>> ?
>>>>
>>>> > The child cannot replace mempool transactions.
>>>>
>>>> Let's say you issue package A+B, then package C+B', where B' is a child
>>>> of both A and C. This rule fails the acceptance of C+B' ?
>>>>
>>>> I think this is a footgunish API, as if a package issuer send the
>>>> multiple-parent-one-child package A,B,C,D where D is the child of A,B,C.
>>>> Then try to broadcast the higher-feerate C'+D' package, it should be
>>>> rejected. So it's breaking the naive broadcaster assumption that a
>>>> higher-feerate/higher-fee package always replaces ? And it might be unsafe
>>>> in protocols where states are symmetric. E.g a malicious counterparty
>>>> broadcasts first S+A, then you honestly broadcast S+B, where B pays better
>>>> fees.
>>>>
>>>> > All mempool transactions to be replaced must signal replaceability.
>>>>
>>>> I think this is unsafe for L2s if counterparties have malleability of
>>>> the child transaction. They can block your package replacement by
>>>> opting-out from RBF signaling. IIRC, LN's "anchor output" presents such an
>>>> ability.
>>>>
>>>> I think it's better to either fix inherited signaling or move towards
>>>> full-rbf.
>>>>
>>>> > if a package parent has already been submitted, it would
>>>> > look
>>>> >like the child is spending a "new" unconfirmed input.
>>>>
>>>> I think this is an issue brought by the trimming during the dedup
>>>> phase. If we preserve the package integrity, only re-using the tx-level
>>>> checks results of already in-mempool transactions to gain in CPU time we
>>>> won't have this issue. Package childs can add unconfirmed inputs as long as
>>>> they're in-package, the bip125 rule2 is only evaluated against parents ?
>>>>
>>>> > However, we still achieve the same goal of requiring the
>>>> > replacement
>>>> > transactions to have a ancestor score at least as high as the original
>>>> > ones.
>>>>
>>>> I'm not sure if this holds...
>>>>
>>>> Let's say you have in-mempool A, B where A pays 10 sat/vb for 100
>>>> vbytes and B pays 10 sat/vb for 100 vbytes. You have the candidate
>>>> replacement D spending both A and C where D pays 15sat/vb for 100 vbytes
>>>> and C pays 1 sat/vb for 1000 vbytes.
>>>>
>>>> Package A + B ancestor score is 10 sat/vb.
>>>>
>>>> D has a higher feerate/absolute fee than B.
>>>>
>>>> Package A + C + D ancestor score is ~ 3 sat/vb ((A's 1000 sats + C's
>>>> 1000 sats + D's 1500 sats) /
>>>> A's 100 vb + C's 1000 vb + D's 100 vb)
>>>>
>>>> Overall, this is a review through the lenses of LN requirements. I
>>>> think other L2 protocols/applications
>>>> could be candidates to using package accept/relay such as:
>>>> * https://github.com/lightninglabs/pool
>>>> * https://github.com/discreetlogcontracts/dlcspecs
>>>> * https://github.com/bitcoin-teleport/teleport-transactions/
>>>> * https://github.com/sapio-lang/sapio
>>>> *
>>>> https://github.com/commerceblock/mercury/blob/master/doc/statechains.md
>>>> * https://github.com/revault/practical-revault
>>>>
>>>> Thanks for rolling forward the ball on this subject.
>>>>
>>>> Antoine
>>>>
>>>> Le jeu. 16 sept. 2021 à 03:55, Gloria Zhao via bitcoin-dev <
>>>> bitcoin-dev at lists.linuxfoundation.org> a écrit :
>>>>
>>>>> Hi there,
>>>>>
>>>>> I'm writing to propose a set of mempool policy changes to enable
>>>>> package
>>>>> validation (in preparation for package relay) in Bitcoin Core. These
>>>>> would not
>>>>> be consensus or P2P protocol changes. However, since mempool policy
>>>>> significantly affects transaction propagation, I believe this is
>>>>> relevant for
>>>>> the mailing list.
>>>>>
>>>>> My proposal enables packages consisting of multiple parents and 1
>>>>> child. If you
>>>>> develop software that relies on specific transaction relay assumptions
>>>>> and/or
>>>>> are interested in using package relay in the future, I'm very
>>>>> interested to hear
>>>>> your feedback on the utility or restrictiveness of these package
>>>>> policies for
>>>>> your use cases.
>>>>>
>>>>> A draft implementation of this proposal can be found in [Bitcoin Core
>>>>> PR#22290][1].
>>>>>
>>>>> An illustrated version of this post can be found at
>>>>> https://gist.github.com/glozow/dc4e9d5c5b14ade7cdfac40f43adb18a.
>>>>> I have also linked the images below.
>>>>>
>>>>> ## Background
>>>>>
>>>>> Feel free to skip this section if you are already familiar with
>>>>> mempool policy
>>>>> and package relay terminology.
>>>>>
>>>>> ### Terminology Clarifications
>>>>>
>>>>> * Package = an ordered list of related transactions, representable by
>>>>> a Directed
>>>>> Acyclic Graph.
>>>>> * Package Feerate = the total modified fees divided by the total
>>>>> virtual size of
>>>>> all transactions in the package.
>>>>> - Modified fees = a transaction's base fees + fee delta applied by
>>>>> the user
>>>>> with `prioritisetransaction`. As such, we expect this to vary
>>>>> across
>>>>> mempools.
>>>>> - Virtual Size = the maximum of virtual sizes calculated using
>>>>> [BIP141
>>>>> virtual size][2] and sigop weight. [Implemented here in Bitcoin
>>>>> Core][3].
>>>>> - Note that feerate is not necessarily based on the base fees and
>>>>> serialized
>>>>> size.
>>>>>
>>>>> * Fee-Bumping = user/wallet actions that take advantage of miner
>>>>> incentives to
>>>>> boost a transaction's candidacy for inclusion in a block, including
>>>>> Child Pays
>>>>> for Parent (CPFP) and [BIP125][12] Replace-by-Fee (RBF). Our intention
>>>>> in
>>>>> mempool policy is to recognize when the new transaction is more
>>>>> economical to
>>>>> mine than the original one(s) but not open DoS vectors, so there are
>>>>> some
>>>>> limitations.
>>>>>
>>>>> ### Policy
>>>>>
>>>>> The purpose of the mempool is to store the best (to be most
>>>>> incentive-compatible
>>>>> with miners, highest feerate) candidates for inclusion in a block.
>>>>> Miners use
>>>>> the mempool to build block templates. The mempool is also useful as a
>>>>> cache for
>>>>> boosting block relay and validation performance, aiding transaction
>>>>> relay, and
>>>>> generating feerate estimations.
>>>>>
>>>>> Ideally, all consensus-valid transactions paying reasonable fees
>>>>> should make it
>>>>> to miners through normal transaction relay, without any special
>>>>> connectivity or
>>>>> relationships with miners. On the other hand, nodes do not have
>>>>> unlimited
>>>>> resources, and a P2P network designed to let any honest node broadcast
>>>>> their
>>>>> transactions also exposes the transaction validation engine to DoS
>>>>> attacks from
>>>>> malicious peers.
>>>>>
>>>>> As such, for unconfirmed transactions we are considering for our
>>>>> mempool, we
>>>>> apply a set of validation rules in addition to consensus, primarily to
>>>>> protect
>>>>> us from resource exhaustion and aid our efforts to keep the highest fee
>>>>> transactions. We call this mempool _policy_: a set of (configurable,
>>>>> node-specific) rules that transactions must abide by in order to be
>>>>> accepted
>>>>> into our mempool. Transaction "Standardness" rules and mempool
>>>>> restrictions such
>>>>> as "too-long-mempool-chain" are both examples of policy.
>>>>>
>>>>> ### Package Relay and Package Mempool Accept
>>>>>
>>>>> In transaction relay, we currently consider transactions one at a time
>>>>> for
>>>>> submission to the mempool. This creates a limitation in the node's
>>>>> ability to
>>>>> determine which transactions have the highest feerates, since we
>>>>> cannot take
>>>>> into account descendants (i.e. cannot use CPFP) until all the
>>>>> transactions are
>>>>> in the mempool. Similarly, we cannot use a transaction's descendants
>>>>> when
>>>>> considering it for RBF. When an individual transaction does not meet
>>>>> the mempool
>>>>> minimum feerate and the user isn't able to create a replacement
>>>>> transaction
>>>>> directly, it will not be accepted by mempools.
>>>>>
>>>>> This limitation presents a security issue for applications and users
>>>>> relying on
>>>>> time-sensitive transactions. For example, Lightning and other
>>>>> protocols create
>>>>> UTXOs with multiple spending paths, where one counterparty's spending
>>>>> path opens
>>>>> up after a timelock, and users are protected from cheating scenarios
>>>>> as long as
>>>>> they redeem on-chain in time. A key security assumption is that all
>>>>> parties'
>>>>> transactions will propagate and confirm in a timely manner. This
>>>>> assumption can
>>>>> be broken if fee-bumping does not work as intended.
>>>>>
>>>>> The end goal for Package Relay is to consider multiple transactions at
>>>>> the same
>>>>> time, e.g. a transaction with its high-fee child. This may help us
>>>>> better
>>>>> determine whether transactions should be accepted to our mempool,
>>>>> especially if
>>>>> they don't meet fee requirements individually or are better RBF
>>>>> candidates as a
>>>>> package. A combination of changes to mempool validation logic, policy,
>>>>> and
>>>>> transaction relay allows us to better propagate the transactions with
>>>>> the
>>>>> highest package feerates to miners, and makes fee-bumping tools more
>>>>> powerful
>>>>> for users.
>>>>>
>>>>> The "relay" part of Package Relay suggests P2P messaging changes, but
>>>>> a large
>>>>> part of the changes are in the mempool's package validation logic. We
>>>>> call this
>>>>> *Package Mempool Accept*.
>>>>>
>>>>> ### Previous Work
>>>>>
>>>>> * Given that mempool validation is DoS-sensitive and complex, it would
>>>>> be
>>>>> dangerous to haphazardly tack on package validation logic. Many
>>>>> efforts have
>>>>> been made to make mempool validation less opaque (see [#16400][4],
>>>>> [#21062][5],
>>>>> [#22675][6], [#22796][7]).
>>>>> * [#20833][8] Added basic capabilities for package validation, test
>>>>> accepts only
>>>>> (no submission to mempool).
>>>>> * [#21800][9] Implemented package ancestor/descendant limit checks for
>>>>> arbitrary
>>>>> packages. Still test accepts only.
>>>>> * Previous package relay proposals (see [#16401][10], [#19621][11]).
>>>>>
>>>>> ### Existing Package Rules
>>>>>
>>>>> These are in master as introduced in [#20833][8] and [#21800][9]. I'll
>>>>> consider
>>>>> them as "given" in the rest of this document, though they can be
>>>>> changed, since
>>>>> package validation is test-accept only right now.
>>>>>
>>>>> 1. A package cannot exceed `MAX_PACKAGE_COUNT=25` count and
>>>>> `MAX_PACKAGE_SIZE=101KvB` total size [8]
>>>>>
>>>>> *Rationale*: This is already enforced as mempool
>>>>> ancestor/descendant limits.
>>>>> Presumably, transactions in a package are all related, so exceeding
>>>>> this limit
>>>>> would mean that the package can either be split up or it wouldn't pass
>>>>> this
>>>>> mempool policy.
>>>>>
>>>>> 2. Packages must be topologically sorted: if any dependencies exist
>>>>> between
>>>>> transactions, parents must appear somewhere before children. [8]
>>>>>
>>>>> 3. A package cannot have conflicting transactions, i.e. none of them
>>>>> can spend
>>>>> the same inputs. This also means there cannot be duplicate
>>>>> transactions. [8]
>>>>>
>>>>> 4. When packages are evaluated against ancestor/descendant limits in a
>>>>> test
>>>>> accept, the union of all of their descendants and ancestors is
>>>>> considered. This
>>>>> is essentially a "worst case" heuristic where every transaction in the
>>>>> package
>>>>> is treated as each other's ancestor and descendant. [8]
>>>>> Packages for which ancestor/descendant limits are accurately captured
>>>>> by this
>>>>> heuristic: [19]
>>>>>
>>>>> There are also limitations such as the fact that CPFP carve out is not
>>>>> applied
>>>>> to package transactions. #20833 also disables RBF in package
>>>>> validation; this
>>>>> proposal overrides that to allow packages to use RBF.
>>>>>
>>>>> ## Proposed Changes
>>>>>
>>>>> The next step in the Package Mempool Accept project is to implement
>>>>> submission
>>>>> to mempool, initially through RPC only. This allows us to test the
>>>>> submission
>>>>> logic before exposing it on P2P.
>>>>>
>>>>> ### Summary
>>>>>
>>>>> - Packages may contain already-in-mempool transactions.
>>>>> - Packages are 2 generations, Multi-Parent-1-Child.
>>>>> - Fee-related checks use the package feerate. This means that wallets
>>>>> can
>>>>> create a package that utilizes CPFP.
>>>>> - Parents are allowed to RBF mempool transactions with a set of rules
>>>>> similar
>>>>> to BIP125. This enables a combination of CPFP and RBF, where a
>>>>> transaction's descendant fees pay for replacing mempool conflicts.
>>>>>
>>>>> There is a draft implementation in [#22290][1]. It is WIP, but
>>>>> feedback is
>>>>> always welcome.
>>>>>
>>>>> ### Details
>>>>>
>>>>> #### Packages May Contain Already-in-Mempool Transactions
>>>>>
>>>>> A package may contain transactions that are already in the mempool. We
>>>>> remove
>>>>> ("deduplicate") those transactions from the package for the purposes
>>>>> of package
>>>>> mempool acceptance. If a package is empty after deduplication, we do
>>>>> nothing.
>>>>>
>>>>> *Rationale*: Mempools vary across the network. It's possible for a
>>>>> parent to be
>>>>> accepted to the mempool of a peer on its own due to differences in
>>>>> policy and
>>>>> fee market fluctuations. We should not reject or penalize the entire
>>>>> package for
>>>>> an individual transaction as that could be a censorship vector.
>>>>>
>>>>> #### Packages Are Multi-Parent-1-Child
>>>>>
>>>>> Only packages of a specific topology are permitted. Namely, a package
>>>>> is exactly
>>>>> 1 child with all of its unconfirmed parents. After deduplication, the
>>>>> package
>>>>> may be exactly the same, empty, 1 child, 1 child with just some of its
>>>>> unconfirmed parents, etc. Note that it's possible for the parents to
>>>>> be indirect
>>>>> descendants/ancestors of one another, or for parent and child to share
>>>>> a parent,
>>>>> so we cannot make any other topology assumptions.
>>>>>
>>>>> *Rationale*: This allows for fee-bumping by CPFP. Allowing multiple
>>>>> parents
>>>>> makes it possible to fee-bump a batch of transactions. Restricting
>>>>> packages to a
>>>>> defined topology is also easier to reason about and simplifies the
>>>>> validation
>>>>> logic greatly. Multi-parent-1-child allows us to think of the package
>>>>> as one big
>>>>> transaction, where:
>>>>>
>>>>> - Inputs = all the inputs of parents + inputs of the child that come
>>>>> from
>>>>> confirmed UTXOs
>>>>> - Outputs = all the outputs of the child + all outputs of the parents
>>>>> that
>>>>> aren't spent by other transactions in the package
>>>>>
>>>>> Examples of packages that follow this rule (variations of example A
>>>>> show some
>>>>> possibilities after deduplication): ![image][15]
>>>>>
>>>>> #### Fee-Related Checks Use Package Feerate
>>>>>
>>>>> Package Feerate = the total modified fees divided by the total virtual
>>>>> size of
>>>>> all transactions in the package.
>>>>>
>>>>> To meet the two feerate requirements of a mempool, i.e., the
>>>>> pre-configured
>>>>> minimum relay feerate (`minRelayTxFee`) and dynamic mempool minimum
>>>>> feerate, the
>>>>> total package feerate is used instead of the individual feerate. The
>>>>> individual
>>>>> transactions are allowed to be below feerate requirements if the
>>>>> package meets
>>>>> the feerate requirements. For example, the parent(s) in the package
>>>>> can have 0
>>>>> fees but be paid for by the child.
>>>>>
>>>>> *Rationale*: This can be thought of as "CPFP within a package,"
>>>>> solving the
>>>>> issue of a parent not meeting minimum fees on its own. This allows L2
>>>>> applications to adjust their fees at broadcast time instead of
>>>>> overshooting or
>>>>> risking getting stuck/pinned.
>>>>>
>>>>> We use the package feerate of the package *after deduplication*.
>>>>>
>>>>> *Rationale*: It would be incorrect to use the fees of transactions
>>>>> that are
>>>>> already in the mempool, as we do not want a transaction's fees to be
>>>>> double-counted for both its individual RBF and package RBF.
>>>>>
>>>>> Examples F and G [14] show the same package, but P1 is submitted
>>>>> individually before
>>>>> the package in example G. In example F, we can see that the 300vB
>>>>> package pays
>>>>> an additional 200sat in fees, which is not enough to pay for its own
>>>>> bandwidth
>>>>> (BIP125#4). In example G, we can see that P1 pays enough to replace
>>>>> M1, but
>>>>> using P1's fees again during package submission would make it look
>>>>> like a 300sat
>>>>> increase for a 200vB package. Even including its fees and size would
>>>>> not be
>>>>> sufficient in this example, since the 300sat looks like enough for the
>>>>> 300vB
>>>>> package. The calculcation after deduplication is 100sat increase for a
>>>>> package
>>>>> of size 200vB, which correctly fails BIP125#4. Assume all transactions
>>>>> have a
>>>>> size of 100vB.
>>>>>
>>>>> #### Package RBF
>>>>>
>>>>> If a package meets feerate requirements as a package, the parents in
>>>>> the
>>>>> transaction are allowed to replace-by-fee mempool transactions. The
>>>>> child cannot
>>>>> replace mempool transactions. Multiple transactions can replace the
>>>>> same
>>>>> transaction, but in order to be valid, none of the transactions can
>>>>> try to
>>>>> replace an ancestor of another transaction in the same package (which
>>>>> would thus
>>>>> make its inputs unavailable).
>>>>>
>>>>> *Rationale*: Even if we are using package feerate, a package will not
>>>>> propagate
>>>>> as intended if RBF still requires each individual transaction to meet
>>>>> the
>>>>> feerate requirements.
>>>>>
>>>>> We use a set of rules slightly modified from BIP125 as follows:
>>>>>
>>>>> ##### Signaling (Rule #1)
>>>>>
>>>>> All mempool transactions to be replaced must signal replaceability.
>>>>>
>>>>> *Rationale*: Package RBF signaling logic should be the same for
>>>>> package RBF and
>>>>> single transaction acceptance. This would be updated if single
>>>>> transaction
>>>>> validation moves to full RBF.
>>>>>
>>>>> ##### New Unconfirmed Inputs (Rule #2)
>>>>>
>>>>> A package may include new unconfirmed inputs, but the ancestor feerate
>>>>> of the
>>>>> child must be at least as high as the ancestor feerates of every
>>>>> transaction
>>>>> being replaced. This is contrary to BIP125#2, which states "The
>>>>> replacement
>>>>> transaction may only include an unconfirmed input if that input was
>>>>> included in
>>>>> one of the original transactions. (An unconfirmed input spends an
>>>>> output from a
>>>>> currently-unconfirmed transaction.)"
>>>>>
>>>>> *Rationale*: The purpose of BIP125#2 is to ensure that the replacement
>>>>> transaction has a higher ancestor score than the original
>>>>> transaction(s) (see
>>>>> [comment][13]). Example H [16] shows how adding a new unconfirmed
>>>>> input can lower the
>>>>> ancestor score of the replacement transaction. P1 is trying to replace
>>>>> M1, and
>>>>> spends an unconfirmed output of M2. P1 pays 800sat, M1 pays 600sat,
>>>>> and M2 pays
>>>>> 100sat. Assume all transactions have a size of 100vB. While, in
>>>>> isolation, P1
>>>>> looks like a better mining candidate than M1, it must be mined with
>>>>> M2, so its
>>>>> ancestor feerate is actually 4.5sat/vB. This is lower than M1's
>>>>> ancestor
>>>>> feerate, which is 6sat/vB.
>>>>>
>>>>> In package RBF, the rule analogous to BIP125#2 would be "none of the
>>>>> transactions in the package can spend new unconfirmed inputs." Example
>>>>> J [17] shows
>>>>> why, if any of the package transactions have ancestors, package
>>>>> feerate is no
>>>>> longer accurate. Even though M2 and M3 are not ancestors of P1 (which
>>>>> is the
>>>>> replacement transaction in an RBF), we're actually interested in the
>>>>> entire
>>>>> package. A miner should mine M1 which is 5sat/vB instead of M2, M3,
>>>>> P1, P2, and
>>>>> P3, which is only 4sat/vB. The Package RBF rule cannot be loosened to
>>>>> only allow
>>>>> the child to have new unconfirmed inputs, either, because it can still
>>>>> cause us
>>>>> to overestimate the package's ancestor score.
>>>>>
>>>>> However, enforcing a rule analogous to BIP125#2 would not only make
>>>>> Package RBF
>>>>> less useful, but would also break Package RBF for packages with
>>>>> parents already
>>>>> in the mempool: if a package parent has already been submitted, it
>>>>> would look
>>>>> like the child is spending a "new" unconfirmed input. In example K
>>>>> [18], we're
>>>>> looking to replace M1 with the entire package including P1, P2, and
>>>>> P3. We must
>>>>> consider the case where one of the parents is already in the mempool
>>>>> (in this
>>>>> case, P2), which means we must allow P3 to have new unconfirmed
>>>>> inputs. However,
>>>>> M2 lowers the ancestor score of P3 to 4.3sat/vB, so we should not
>>>>> replace M1
>>>>> with this package.
>>>>>
>>>>> Thus, the package RBF rule regarding new unconfirmed inputs is less
>>>>> strict than
>>>>> BIP125#2. However, we still achieve the same goal of requiring the
>>>>> replacement
>>>>> transactions to have a ancestor score at least as high as the original
>>>>> ones. As
>>>>> a result, the entire package is required to be a higher feerate mining
>>>>> candidate
>>>>> than each of the replaced transactions.
>>>>>
>>>>> Another note: the [comment][13] above the BIP125#2 code in the
>>>>> original RBF
>>>>> implementation suggests that the rule was intended to be temporary.
>>>>>
>>>>> ##### Absolute Fee (Rule #3)
>>>>>
>>>>> The package must increase the absolute fee of the mempool, i.e. the
>>>>> total fees
>>>>> of the package must be higher than the absolute fees of the mempool
>>>>> transactions
>>>>> it replaces. Combined with the CPFP rule above, this differs from
>>>>> BIP125 Rule #3
>>>>> - an individual transaction in the package may have lower fees than the
>>>>> transaction(s) it is replacing. In fact, it may have 0 fees, and the
>>>>> child
>>>>> pays for RBF.
>>>>>
>>>>> ##### Feerate (Rule #4)
>>>>>
>>>>> The package must pay for its own bandwidth; the package feerate must
>>>>> be higher
>>>>> than the replaced transactions by at least minimum relay feerate
>>>>> (`incrementalRelayFee`). Combined with the CPFP rule above, this
>>>>> differs from
>>>>> BIP125 Rule #4 - an individual transaction in the package can have a
>>>>> lower
>>>>> feerate than the transaction(s) it is replacing. In fact, it may have
>>>>> 0 fees,
>>>>> and the child pays for RBF.
>>>>>
>>>>> ##### Total Number of Replaced Transactions (Rule #5)
>>>>>
>>>>> The package cannot replace more than 100 mempool transactions. This is
>>>>> identical
>>>>> to BIP125 Rule #5.
>>>>>
>>>>> ### Expected FAQs
>>>>>
>>>>> 1. Is it possible for only some of the package to make it into the
>>>>> mempool?
>>>>>
>>>>> Yes, it is. However, since we evict transactions from the mempool by
>>>>> descendant score and the package child is supposed to be sponsoring
>>>>> the fees of
>>>>> its parents, the most common scenario would be all-or-nothing. This is
>>>>> incentive-compatible. In fact, to be conservative, package validation
>>>>> should
>>>>> begin by trying to submit all of the transactions individually, and
>>>>> only use the
>>>>> package mempool acceptance logic if the parents fail due to low
>>>>> feerate.
>>>>>
>>>>> 2. Should we allow packages to contain already-confirmed transactions?
>>>>>
>>>>> No, for practical reasons. In mempool validation, we actually
>>>>> aren't able to
>>>>> tell with 100% confidence if we are looking at a transaction that has
>>>>> already
>>>>> confirmed, because we look up inputs using a UTXO set. If we have
>>>>> historical
>>>>> block data, it's possible to look for it, but this is inefficient, not
>>>>> always
>>>>> possible for pruning nodes, and unnecessary because we're not going to
>>>>> do
>>>>> anything with the transaction anyway. As such, we already have the
>>>>> expectation
>>>>> that transaction relay is somewhat "stateful" i.e. nobody should be
>>>>> relaying
>>>>> transactions that have already been confirmed. Similarly, we shouldn't
>>>>> be
>>>>> relaying packages that contain already-confirmed transactions.
>>>>>
>>>>> [1]: https://github.com/bitcoin/bitcoin/pull/22290
>>>>> [2]:
>>>>> https://github.com/bitcoin/bips/blob/1f0b563738199ca60d32b4ba779797fc97d040fe/bip-0141.mediawiki#transaction-size-calculations
>>>>> [3]:
>>>>> https://github.com/bitcoin/bitcoin/blob/94f83534e4b771944af7d9ed0f40746f392eb75e/src/policy/policy.cpp#L282
>>>>> [4]: https://github.com/bitcoin/bitcoin/pull/16400
>>>>> [5]: https://github.com/bitcoin/bitcoin/pull/21062
>>>>> [6]: https://github.com/bitcoin/bitcoin/pull/22675
>>>>> [7]: https://github.com/bitcoin/bitcoin/pull/22796
>>>>> [8]: https://github.com/bitcoin/bitcoin/pull/20833
>>>>> [9]: https://github.com/bitcoin/bitcoin/pull/21800
>>>>> [10]: https://github.com/bitcoin/bitcoin/pull/16401
>>>>> [11]: https://github.com/bitcoin/bitcoin/pull/19621
>>>>> [12]: https://github.com/bitcoin/bips/blob/master/bip-0125.mediawiki
>>>>> [13]:
>>>>> https://github.com/bitcoin/bitcoin/pull/6871/files#diff-34d21af3c614ea3cee120df276c9c4ae95053830d7f1d3deaf009a4625409ad2R1101-R1104
>>>>> [14]:
>>>>>
>>>>> [15]:
>>>>>
>>>>> [16]:
>>>>>
>>>>> [17]:
>>>>>
>>>>> [18]:
>>>>>
>>>>> [19]:
>>>>>
>>>>> [20]:
>>>>>
>>>>> _______________________________________________
>>>>> bitcoin-dev mailing list
>>>>> bitcoin-dev at lists.linuxfoundation.org
>>>>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>>>>
>>>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20210926/16f08de9/attachment-0001.html>;

📅 Original date posted:2021-09-23 📝 Original message:> ...

2023-06-08T00:59:18+02:00

In reply to nevent1q…x33f
_________________________

📅 Original date posted:2021-09-23
📝 Original message:> Correct, if B+C is too low feerate to be accepted, we will reject it. I
> prefer this because it is incentive compatible: A can be mined by itself,
> so there's no reason to prefer A+B+C instead of A.
> As another way of looking at this, consider the case where we do accept
> A+B+C and it sits at the "bottom" of our mempool. If our mempool reaches
> capacity, we evict the lowest descendant feerate transactions, which are
> B+C in this case. This gives us the same resulting mempool, with A and not
> B+C.

I agree here. Doing otherwise, we might evict other transactions mempool in
`MempoolAccept::Finalize` with a higher-feerate than B+C while those
evicted transactions are the most compelling for block construction.

I thought at first missing this acceptance requirement would break a
fee-bumping scheme like Parent-Pay-For-Child where a high-fee parent is
attached to a child signed with SIGHASH_ANYONECANPAY but in this case the
child fee is capturing the parent value. I can't think of other fee-bumping
schemes potentially affected. If they do exist I would say they're wrong in
their design assumptions.

> If or when we have witness replacement, the logic is: if the individual
> transaction is enough to replace the mempool one, the replacement will
> happen during the preceding individual transaction acceptance, and
> deduplication logic will work. Otherwise, we will try to deduplicate by
> wtxid, see that we need a package witness replacement, and use the package
> feerate to evaluate whether this is economically rational.

IIUC, you have package A+B, during the dedup phase early in
`AcceptMultipleTransactions` if you observe same-txid-different-wtixd A'
and A' is higher feerate than A, you trim A and replace by A' ?

I think this approach is safe, the one who appears unsafe to me is when A'
has a _lower_ feerate, even if A' is already accepted by our mempool ? In
that case iirc that would be a pinning.

Good to see progress on witness replacement before we see usage of Taproot
tree in the context of multi-party, where a malicious counterparty inflates
its witness to jam a honest spending.

(Note, the commit linked currently points nowhere :))

> Please note that A may replace A' even if A' has higher fees than A
> individually, because the proposed package RBF utilizes the fees and size
> of the entire package. This just requires E to pay enough fees, although
> this can be pretty high if there are also potential B' and C' competing
> commitment transactions that we don't know about.

Ah right, if the package acceptance waives `PaysMoreThanConflicts` for the
individual check on A, the honest package should replace the pinning
attempt. I've not fully parsed the proposed implementation yet.

Though note, I think it's still unsafe for a Lightning
multi-commitment-broadcast-as-one-package as a malicious A' might have an
absolute fee higher than E. It sounds uneconomical for
an attacker but I think it's not when you consider than you can "batch"
attack against multiple honest counterparties. E.g, Mallory broadcast A' +
B' + C' + D' where A' conflicts with Alice's honest package P1, B'
conflicts with Bob's honest package P2, C' conflicts with Caroll's honest
package P3. And D' is a high-fee child of A' + B' + C'.

If D' is higher-fee than P1 or P2 or P3 but inferior to the sum of HTLCs
confirmed by P1+P2+P3, I think it's lucrative for the attacker ?

> So far, my understanding is that multi-parent-1-child is desired for
> batched fee-bumping (
> https://github.com/bitcoin/bitcoin/pull/22674#issuecomment-897951289) and
> I've also seen your response which I have less context on (
> https://github.com/bitcoin/bitcoin/pull/22674#issuecomment-900352202).
That
> being said, I am happy to create a new proposal for 1 parent + 1 child
> (which would be slightly simpler) and plan for moving to
> multi-parent-1-child later if that is preferred. I am very interested in
> hearing feedback on that approach.

I think batched fee-bumping is okay as long as you don't have
time-sensitive outputs encumbering your commitment transactions. For the
reasons mentioned above, I think that's unsafe.

What I'm worried about is L2 developers, potentially not aware about all
the mempool subtleties blurring the difference and always batching their
broadcast by default.

IMO, a good thing by restraining to 1-parent + 1 child, we artificially
constraint L2 design space for now and minimize risks of unsafe usage of
the package API :)

I think that's a point where it would be relevant to have the opinion of
more L2 devs.

> I think there is a misunderstanding here - let me describe what I'm
> proposing we'd do in this situation: we'll try individual submission for
A,
> see that it fails due to "insufficient fees." Then, we'll try package
> validation for A+B and use package RBF. If A+B pays enough, it can still
> replace A'. If A fails for a bad signature, we won't look at B or A+B.
Does
> this meet your expectations?

Yes there was a misunderstanding, I think this approach is correct, it's
more a question of performance. Do we assume that broadcasted packages are
"honest" by default and that the parent(s) always need the child to pass
the fee checks, that way saving the processing of individual transactions
which are expected to fail in 99% of cases or more ad hoc composition of
packages at relay ?

I think this point is quite dependent on the p2p packages format/logic
we'll end up on and that we should feel free to revisit it later ?

> What problem are you trying to solve by the package feerate *after* dedup
rule ?
> My understanding is that an in-package transaction might be already in
the mempool. Therefore, to compute a correct RBF penalty replacement, the
vsize of this transaction could be discarded lowering the cost of package
RBF.

> I'm proposing that, when a transaction has already been submitted to
> mempool, we would ignore both its fees and vsize when calculating package
> feerate.

Yes, if you receive A+B, and A is already in-mempoo, I agree you can
discard its feerate as B should pay for all fees checked on its own. Where
I'm unclear is when you have in-mempool A+B and receive A+B'. Should B'
have a fee high enough to cover the bandwidth penalty replacement
(`PaysForRBF`, 2nd check) of both A+B' or only B' ?

If you have a second-layer like current Lightning, you might have a
counterparty commitment to replace and should always expect to have to pay
for parent replacement bandwidth.

Where a potential discount sounds interesting is when you have an univoque
state on the first-stage of transactions. E.g DLC's funding transaction
which might be CPFP by any participant iirc.

> Note that, if C' conflicts with C, it also conflicts with D, since D is a
> descendant of C and would thus need to be evicted along with it.

Ah once again I think it's a misunderstanding without the code under my
eyes! If we do C' `PreChecks`, solve the conflicts provoked by it, i.e mark
for potential eviction D and don't consider it for future conflicts in the
rest of the package, I think D' `PreChecks` should be good ?

> More generally, this example is surprising to me because I didn't think
> packages would be used to fee-bump replaceable transactions. Do we want
the
> child to be able to replace mempool transactions as well?

If we mean when you have replaceable A+B then A'+B' try to replace with a
higher-feerate ? I think that's exactly the case we need for Lightning as
A+B is coming from Alice and A'+B' is coming from Bob :/

> I'm not sure what you mean? Let's say we have a package of parent A +
child
> B, where A is supposed to replace a mempool transaction A'. Are you saying
> that counterparties are able to malleate the package child B, or a child
of
> A'?

The second option, a child of A', In the LN case I think the CPFP is
attached on one's anchor output.

I think it's good if we assume the
solve-conflicts-after-parent's`'PreChecks` mentioned above or fixing
inherited signaling or full-rbf ?

> Sorry, I don't understand what you mean by "preserve the package
> integrity?" Could you elaborate?

After thinking the relaxation about the "new" unconfirmed input is not
linked to trimming but I would say more to the multi-parent support.

Let's say you have A+B trying to replace C+D where B is also spending
already in-mempool E. To succeed, you need to waive the no-new-unconfirmed
input as D isn't spending E.

So good, I think we agree on the problem description here.

> I am in agreement with your calculations but unsure if we disagree on the
> expected outcome. Yes, B has an ancestor score of 10sat/vb and D has an
> ancestor score of ~2.9sat/vb. Since D's ancestor score is lower than B's,
> it fails the proposed package RBF Rule #2, so this package would be
> rejected. Does this meet your expectations?

Well what sounds odd to me, in my example, we fail D even if it has a
higher-fee than B. Like A+B absolute fees are 2000 sats and A+C+D absolute
fees are 4500 sats ?

Is this compatible with a model where a miner prioritizes absolute fees
over ancestor score, in the case that mempools aren't full-enough to
fulfill a block ?

Let me know if I can clarify a point.

Antoine

Le lun. 20 sept. 2021 à 11:10, Gloria Zhao <gloriajzhao at gmail.com> a écrit :

>
> Hi Antoine,
>
> First of all, thank you for the thorough review. I appreciate your insight
> on LN requirements.
>
> > IIUC, you have a package A+B+C submitted for acceptance and A is already
> in your mempool. You trim out A from the package and then evaluate B+C.
>
> > I think this might be an issue if A is the higher-fee element of the ABC
> package. B+C package fees might be under the mempool min fee and will be
> rejected, potentially breaking the acceptance expectations of the package
> issuer ?
>
> Correct, if B+C is too low feerate to be accepted, we will reject it. I
> prefer this because it is incentive compatible: A can be mined by itself,
> so there's no reason to prefer A+B+C instead of A.
> As another way of looking at this, consider the case where we do accept
> A+B+C and it sits at the "bottom" of our mempool. If our mempool reaches
> capacity, we evict the lowest descendant feerate transactions, which are
> B+C in this case. This gives us the same resulting mempool, with A and not
> B+C.
>
>
> > Further, I think the dedup should be done on wtxid, as you might have
> multiple valid witnesses. Though with varying vsizes and as such offering
> different feerates.
>
> I agree that variations of the same package with different witnesses is a
> case that must be handled. I consider witness replacement to be a project
> that can be done in parallel to package mempool acceptance because being
> able to accept packages does not worsen the problem of a
> same-txid-different-witness "pinning" attack.
>
> If or when we have witness replacement, the logic is: if the individual
> transaction is enough to replace the mempool one, the replacement will
> happen during the preceding individual transaction acceptance, and
> deduplication logic will work. Otherwise, we will try to deduplicate by
> wtxid, see that we need a package witness replacement, and use the package
> feerate to evaluate whether this is economically rational.
>
> See the #22290 "handle package transactions already in mempool" commit (
> https://github.com/bitcoin/bitcoin/pull/22290/commits/fea75a2237b46cf76145242fecad7e274bfcb5ff),
> which handles the case of same-txid-different-witness by simply using the
> transaction in the mempool for now, with TODOs for what I just described.
>
>
> > I'm not clearly understanding the accepted topologies. By "parent and
> child to share a parent", do you mean the set of transactions A, B, C,
> where B is spending A and C is spending A and B would be correct ?
>
> Yes, that is what I meant. Yes, that would a valid package under these
> rules.
>
> > If yes, is there a width-limit introduced or we fallback on
> MAX_PACKAGE_COUNT=25 ?
>
> No, there is no limit on connectivity other than "child with all
> unconfirmed parents." We will enforce MAX_PACKAGE_COUNT=25 and child's
> in-mempool + in-package ancestor limits.
>
>
> > Considering the current Core's mempool acceptance rules, I think CPFP
> batching is unsafe for LN time-sensitive closure. A malicious tx-relay
> jamming successful on one channel commitment transaction would contamine
> the remaining commitments sharing the same package.
>
> > E.g, you broadcast the package A+B+C+D+E where A,B,C,D are commitment
> transactions and E a shared CPFP. If a malicious A' transaction has a
> better feerate than A, the whole package acceptance will fail. Even if A'
> confirms in the following block,
> the propagation and confirmation of B+C+D have been delayed. This could
> carry on a loss of funds.
>
> Please note that A may replace A' even if A' has higher fees than A
> individually, because the proposed package RBF utilizes the fees and size
> of the entire package. This just requires E to pay enough fees, although
> this can be pretty high if there are also potential B' and C' competing
> commitment transactions that we don't know about.
>
>
> > IMHO, I'm leaning towards deploying during a first phase
> 1-parent/1-child. I think it's the most conservative step still improving
> second-layer safety.
>
> So far, my understanding is that multi-parent-1-child is desired for
> batched fee-bumping (
> https://github.com/bitcoin/bitcoin/pull/22674#issuecomment-897951289) and
> I've also seen your response which I have less context on (
> https://github.com/bitcoin/bitcoin/pull/22674#issuecomment-900352202).
> That being said, I am happy to create a new proposal for 1 parent + 1 child
> (which would be slightly simpler) and plan for moving to
> multi-parent-1-child later if that is preferred. I am very interested in
> hearing feedback on that approach.
>
>
> > If A+B is submitted to replace A', where A pays 0 sats, B pays 200 sats
> and A' pays 100 sats. If we apply the individual RBF on A, A+B acceptance
> fails. For this reason I think the individual RBF should be bypassed and
> only the package RBF apply ?
>
> I think there is a misunderstanding here - let me describe what I'm
> proposing we'd do in this situation: we'll try individual submission for A,
> see that it fails due to "insufficient fees." Then, we'll try package
> validation for A+B and use package RBF. If A+B pays enough, it can still
> replace A'. If A fails for a bad signature, we won't look at B or A+B. Does
> this meet your expectations?
>
>
> > What problem are you trying to solve by the package feerate *after*
> dedup rule ?
> > My understanding is that an in-package transaction might be already in
> the mempool. Therefore, to compute a correct RBF penalty replacement, the
> vsize of this transaction could be discarded lowering the cost of package
> RBF.
>
> I'm proposing that, when a transaction has already been submitted to
> mempool, we would ignore both its fees and vsize when calculating package
> feerate. In example G2, we shouldn't count M1 fees after its submission to
> mempool, since M1's fees have already been used to pay for its individual
> bandwidth, and it shouldn't be used again to pay for P2 and P3's bandwidth.
> We also shouldn't count its vsize, since it has already been paid for.
>
>
> > I think this is a footgunish API, as if a package issuer send the
> multiple-parent-one-child package A,B,C,D where D is the child of A,B,C.
> Then try to broadcast the higher-feerate C'+D' package, it should be
> rejected. So it's breaking the naive broadcaster assumption that a
> higher-feerate/higher-fee package always replaces ?
>
> Note that, if C' conflicts with C, it also conflicts with D, since D is a
> descendant of C and would thus need to be evicted along with it.
> Implicitly, D' would not be in conflict with D.
> More generally, this example is surprising to me because I didn't think
> packages would be used to fee-bump replaceable transactions. Do we want the
> child to be able to replace mempool transactions as well? This can be
> implemented with a bit of additional logic.
>
> > I think this is unsafe for L2s if counterparties have malleability of
> the child transaction. They can block your package replacement by
> opting-out from RBF signaling. IIRC, LN's "anchor output" presents such an
> ability.
>
> I'm not sure what you mean? Let's say we have a package of parent A +
> child B, where A is supposed to replace a mempool transaction A'. Are you
> saying that counterparties are able to malleate the package child B, or a
> child of A'? If they can malleate a child of A', that shouldn't matter as
> long as A' is signaling replacement. This would be handled identically with
> full RBF and what Core currently implements.
>
> > I think this is an issue brought by the trimming during the dedup phase.
> If we preserve the package integrity, only re-using the tx-level checks
> results of already in-mempool transactions to gain in CPU time we won't
> have this issue. Package childs can add unconfirmed inputs as long as
> they're in-package, the bip125 rule2 is only evaluated against parents ?
>
> Sorry, I don't understand what you mean by "preserve the package
> integrity?" Could you elaborate?
>
> > Let's say you have in-mempool A, B where A pays 10 sat/vb for 100 vbytes
> and B pays 10 sat/vb for 100 vbytes. You have the candidate replacement D
> spending both A and C where D pays 15sat/vb for 100 vbytes and C pays 1
> sat/vb for 1000 vbytes.
>
> > Package A + B ancestor score is 10 sat/vb.
>
> > D has a higher feerate/absolute fee than B.
>
> > Package A + C + D ancestor score is ~ 3 sat/vb ((A's 1000 sats + C's
> 1000 sats + D's 1500 sats) / A's 100 vb + C's 1000 vb + D's 100 vb)
>
> I am in agreement with your calculations but unsure if we disagree on the
> expected outcome. Yes, B has an ancestor score of 10sat/vb and D has an
> ancestor score of ~2.9sat/vb. Since D's ancestor score is lower than B's,
> it fails the proposed package RBF Rule #2, so this package would be
> rejected. Does this meet your expectations?
>
> Thank you for linking to projects that might be interested in package
> relay :)
>
> Thanks,
> Gloria
>
> On Mon, Sep 20, 2021 at 12:16 AM Antoine Riard <antoine.riard at gmail.com>
> wrote:
>
>> Hi Gloria,
>>
>> > A package may contain transactions that are already in the mempool. We
>> > remove
>> > ("deduplicate") those transactions from the package for the purposes of
>> > package
>> > mempool acceptance. If a package is empty after deduplication, we do
>> > nothing.
>>
>> IIUC, you have a package A+B+C submitted for acceptance and A is already
>> in your mempool. You trim out A from the package and then evaluate B+C.
>>
>> I think this might be an issue if A is the higher-fee element of the ABC
>> package. B+C package fees might be under the mempool min fee and will be
>> rejected, potentially breaking the acceptance expectations of the package
>> issuer ?
>>
>> Further, I think the dedup should be done on wtxid, as you might have
>> multiple valid witnesses. Though with varying vsizes and as such offering
>> different feerates.
>>
>> E.g you're going to evaluate the package A+B and A' is already in your
>> mempool with a bigger valid witness. You trim A based on txid, then you
>> evaluate A'+B, which fails the fee checks. However, evaluating A+B would
>> have been a success.
>>
>> AFAICT, the dedup rationale would be to save on CPU time/IO disk, to
>> avoid repeated signatures verification and parent UTXOs fetches ? Can we
>> achieve the same goal by bypassing tx-level checks for already-in txn while
>> conserving the package integrity for package-level checks ?
>>
>> > Note that it's possible for the parents to be
>> > indirect
>> > descendants/ancestors of one another, or for parent and child to share a
>> > parent,
>> > so we cannot make any other topology assumptions.
>>
>> I'm not clearly understanding the accepted topologies. By "parent and
>> child to share a parent", do you mean the set of transactions A, B, C,
>> where B is spending A and C is spending A and B would be correct ?
>>
>> If yes, is there a width-limit introduced or we fallback on
>> MAX_PACKAGE_COUNT=25 ?
>>
>> IIRC, one rationale to come with this topology limitation was to lower
>> the DoS risks when potentially deploying p2p packages.
>>
>> Considering the current Core's mempool acceptance rules, I think CPFP
>> batching is unsafe for LN time-sensitive closure. A malicious tx-relay
>> jamming successful on one channel commitment transaction would contamine
>> the remaining commitments sharing the same package.
>>
>> E.g, you broadcast the package A+B+C+D+E where A,B,C,D are commitment
>> transactions and E a shared CPFP. If a malicious A' transaction has a
>> better feerate than A, the whole package acceptance will fail. Even if A'
>> confirms in the following block,
>> the propagation and confirmation of B+C+D have been delayed. This could
>> carry on a loss of funds.
>>
>> That said, if you're broadcasting commitment transactions without
>> time-sensitive HTLC outputs, I think the batching is effectively a fee
>> saving as you don't have to duplicate the CPFP.
>>
>> IMHO, I'm leaning towards deploying during a first phase
>> 1-parent/1-child. I think it's the most conservative step still improving
>> second-layer safety.
>>
>> > *Rationale*: It would be incorrect to use the fees of transactions
>> that are
>> > already in the mempool, as we do not want a transaction's fees to be
>> > double-counted for both its individual RBF and package RBF.
>>
>> I'm unsure about the logical order of the checks proposed.
>>
>> If A+B is submitted to replace A', where A pays 0 sats, B pays 200 sats
>> and A' pays 100 sats. If we apply the individual RBF on A, A+B acceptance
>> fails. For this reason I think the individual RBF should be bypassed and
>> only the package RBF apply ?
>>
>> Note this situation is plausible, with current LN design, your
>> counterparty can have a commitment transaction with a better fee just by
>> selecting a higher `dust_limit_satoshis` than yours.
>>
>> > Examples F and G [14] show the same package, but P1 is submitted
>> > individually before
>> > the package in example G. In example F, we can see that the 300vB
>> package
>> > pays
>> > an additional 200sat in fees, which is not enough to pay for its own
>> > bandwidth
>> > (BIP125#4). In example G, we can see that P1 pays enough to replace M1,
>> but
>> > using P1's fees again during package submission would make it look like
>> a
>> > 300sat
>> > increase for a 200vB package. Even including its fees and size would
>> not be
>> > sufficient in this example, since the 300sat looks like enough for the
>> 300vB
>> > package. The calculcation after deduplication is 100sat increase for a
>> > package
>> > of size 200vB, which correctly fails BIP125#4. Assume all transactions
>> have
>> > a
>> > size of 100vB.
>>
>> What problem are you trying to solve by the package feerate *after* dedup
>> rule ?
>>
>> My understanding is that an in-package transaction might be already in
>> the mempool. Therefore, to compute a correct RBF penalty replacement, the
>> vsize of this transaction could be discarded lowering the cost of package
>> RBF.
>>
>> If we keep a "safe" dedup mechanism (see my point above), I think this
>> discount is justified, as the validation cost of node operators is paid for
>> ?
>>
>> > The child cannot replace mempool transactions.
>>
>> Let's say you issue package A+B, then package C+B', where B' is a child
>> of both A and C. This rule fails the acceptance of C+B' ?
>>
>> I think this is a footgunish API, as if a package issuer send the
>> multiple-parent-one-child package A,B,C,D where D is the child of A,B,C.
>> Then try to broadcast the higher-feerate C'+D' package, it should be
>> rejected. So it's breaking the naive broadcaster assumption that a
>> higher-feerate/higher-fee package always replaces ? And it might be unsafe
>> in protocols where states are symmetric. E.g a malicious counterparty
>> broadcasts first S+A, then you honestly broadcast S+B, where B pays better
>> fees.
>>
>> > All mempool transactions to be replaced must signal replaceability.
>>
>> I think this is unsafe for L2s if counterparties have malleability of the
>> child transaction. They can block your package replacement by opting-out
>> from RBF signaling. IIRC, LN's "anchor output" presents such an ability.
>>
>> I think it's better to either fix inherited signaling or move towards
>> full-rbf.
>>
>> > if a package parent has already been submitted, it would
>> > look
>> >like the child is spending a "new" unconfirmed input.
>>
>> I think this is an issue brought by the trimming during the dedup phase.
>> If we preserve the package integrity, only re-using the tx-level checks
>> results of already in-mempool transactions to gain in CPU time we won't
>> have this issue. Package childs can add unconfirmed inputs as long as
>> they're in-package, the bip125 rule2 is only evaluated against parents ?
>>
>> > However, we still achieve the same goal of requiring the
>> > replacement
>> > transactions to have a ancestor score at least as high as the original
>> > ones.
>>
>> I'm not sure if this holds...
>>
>> Let's say you have in-mempool A, B where A pays 10 sat/vb for 100 vbytes
>> and B pays 10 sat/vb for 100 vbytes. You have the candidate replacement D
>> spending both A and C where D pays 15sat/vb for 100 vbytes and C pays 1
>> sat/vb for 1000 vbytes.
>>
>> Package A + B ancestor score is 10 sat/vb.
>>
>> D has a higher feerate/absolute fee than B.
>>
>> Package A + C + D ancestor score is ~ 3 sat/vb ((A's 1000 sats + C's 1000
>> sats + D's 1500 sats) /
>> A's 100 vb + C's 1000 vb + D's 100 vb)
>>
>> Overall, this is a review through the lenses of LN requirements. I think
>> other L2 protocols/applications
>> could be candidates to using package accept/relay such as:
>> * https://github.com/lightninglabs/pool
>> * https://github.com/discreetlogcontracts/dlcspecs
>> * https://github.com/bitcoin-teleport/teleport-transactions/
>> * https://github.com/sapio-lang/sapio
>> * https://github.com/commerceblock/mercury/blob/master/doc/statechains.md
>> * https://github.com/revault/practical-revault
>>
>> Thanks for rolling forward the ball on this subject.
>>
>> Antoine
>>
>> Le jeu. 16 sept. 2021 à 03:55, Gloria Zhao via bitcoin-dev <
>> bitcoin-dev at lists.linuxfoundation.org> a écrit :
>>
>>> Hi there,
>>>
>>> I'm writing to propose a set of mempool policy changes to enable package
>>> validation (in preparation for package relay) in Bitcoin Core. These
>>> would not
>>> be consensus or P2P protocol changes. However, since mempool policy
>>> significantly affects transaction propagation, I believe this is
>>> relevant for
>>> the mailing list.
>>>
>>> My proposal enables packages consisting of multiple parents and 1 child.
>>> If you
>>> develop software that relies on specific transaction relay assumptions
>>> and/or
>>> are interested in using package relay in the future, I'm very interested
>>> to hear
>>> your feedback on the utility or restrictiveness of these package
>>> policies for
>>> your use cases.
>>>
>>> A draft implementation of this proposal can be found in [Bitcoin Core
>>> PR#22290][1].
>>>
>>> An illustrated version of this post can be found at
>>> https://gist.github.com/glozow/dc4e9d5c5b14ade7cdfac40f43adb18a.
>>> I have also linked the images below.
>>>
>>> ## Background
>>>
>>> Feel free to skip this section if you are already familiar with mempool
>>> policy
>>> and package relay terminology.
>>>
>>> ### Terminology Clarifications
>>>
>>> * Package = an ordered list of related transactions, representable by a
>>> Directed
>>> Acyclic Graph.
>>> * Package Feerate = the total modified fees divided by the total virtual
>>> size of
>>> all transactions in the package.
>>> - Modified fees = a transaction's base fees + fee delta applied by
>>> the user
>>> with `prioritisetransaction`. As such, we expect this to vary
>>> across
>>> mempools.
>>> - Virtual Size = the maximum of virtual sizes calculated using
>>> [BIP141
>>> virtual size][2] and sigop weight. [Implemented here in Bitcoin
>>> Core][3].
>>> - Note that feerate is not necessarily based on the base fees and
>>> serialized
>>> size.
>>>
>>> * Fee-Bumping = user/wallet actions that take advantage of miner
>>> incentives to
>>> boost a transaction's candidacy for inclusion in a block, including
>>> Child Pays
>>> for Parent (CPFP) and [BIP125][12] Replace-by-Fee (RBF). Our intention in
>>> mempool policy is to recognize when the new transaction is more
>>> economical to
>>> mine than the original one(s) but not open DoS vectors, so there are some
>>> limitations.
>>>
>>> ### Policy
>>>
>>> The purpose of the mempool is to store the best (to be most
>>> incentive-compatible
>>> with miners, highest feerate) candidates for inclusion in a block.
>>> Miners use
>>> the mempool to build block templates. The mempool is also useful as a
>>> cache for
>>> boosting block relay and validation performance, aiding transaction
>>> relay, and
>>> generating feerate estimations.
>>>
>>> Ideally, all consensus-valid transactions paying reasonable fees should
>>> make it
>>> to miners through normal transaction relay, without any special
>>> connectivity or
>>> relationships with miners. On the other hand, nodes do not have unlimited
>>> resources, and a P2P network designed to let any honest node broadcast
>>> their
>>> transactions also exposes the transaction validation engine to DoS
>>> attacks from
>>> malicious peers.
>>>
>>> As such, for unconfirmed transactions we are considering for our
>>> mempool, we
>>> apply a set of validation rules in addition to consensus, primarily to
>>> protect
>>> us from resource exhaustion and aid our efforts to keep the highest fee
>>> transactions. We call this mempool _policy_: a set of (configurable,
>>> node-specific) rules that transactions must abide by in order to be
>>> accepted
>>> into our mempool. Transaction "Standardness" rules and mempool
>>> restrictions such
>>> as "too-long-mempool-chain" are both examples of policy.
>>>
>>> ### Package Relay and Package Mempool Accept
>>>
>>> In transaction relay, we currently consider transactions one at a time
>>> for
>>> submission to the mempool. This creates a limitation in the node's
>>> ability to
>>> determine which transactions have the highest feerates, since we cannot
>>> take
>>> into account descendants (i.e. cannot use CPFP) until all the
>>> transactions are
>>> in the mempool. Similarly, we cannot use a transaction's descendants when
>>> considering it for RBF. When an individual transaction does not meet the
>>> mempool
>>> minimum feerate and the user isn't able to create a replacement
>>> transaction
>>> directly, it will not be accepted by mempools.
>>>
>>> This limitation presents a security issue for applications and users
>>> relying on
>>> time-sensitive transactions. For example, Lightning and other protocols
>>> create
>>> UTXOs with multiple spending paths, where one counterparty's spending
>>> path opens
>>> up after a timelock, and users are protected from cheating scenarios as
>>> long as
>>> they redeem on-chain in time. A key security assumption is that all
>>> parties'
>>> transactions will propagate and confirm in a timely manner. This
>>> assumption can
>>> be broken if fee-bumping does not work as intended.
>>>
>>> The end goal for Package Relay is to consider multiple transactions at
>>> the same
>>> time, e.g. a transaction with its high-fee child. This may help us better
>>> determine whether transactions should be accepted to our mempool,
>>> especially if
>>> they don't meet fee requirements individually or are better RBF
>>> candidates as a
>>> package. A combination of changes to mempool validation logic, policy,
>>> and
>>> transaction relay allows us to better propagate the transactions with the
>>> highest package feerates to miners, and makes fee-bumping tools more
>>> powerful
>>> for users.
>>>
>>> The "relay" part of Package Relay suggests P2P messaging changes, but a
>>> large
>>> part of the changes are in the mempool's package validation logic. We
>>> call this
>>> *Package Mempool Accept*.
>>>
>>> ### Previous Work
>>>
>>> * Given that mempool validation is DoS-sensitive and complex, it would be
>>> dangerous to haphazardly tack on package validation logic. Many
>>> efforts have
>>> been made to make mempool validation less opaque (see [#16400][4],
>>> [#21062][5],
>>> [#22675][6], [#22796][7]).
>>> * [#20833][8] Added basic capabilities for package validation, test
>>> accepts only
>>> (no submission to mempool).
>>> * [#21800][9] Implemented package ancestor/descendant limit checks for
>>> arbitrary
>>> packages. Still test accepts only.
>>> * Previous package relay proposals (see [#16401][10], [#19621][11]).
>>>
>>> ### Existing Package Rules
>>>
>>> These are in master as introduced in [#20833][8] and [#21800][9]. I'll
>>> consider
>>> them as "given" in the rest of this document, though they can be
>>> changed, since
>>> package validation is test-accept only right now.
>>>
>>> 1. A package cannot exceed `MAX_PACKAGE_COUNT=25` count and
>>> `MAX_PACKAGE_SIZE=101KvB` total size [8]
>>>
>>> *Rationale*: This is already enforced as mempool ancestor/descendant
>>> limits.
>>> Presumably, transactions in a package are all related, so exceeding this
>>> limit
>>> would mean that the package can either be split up or it wouldn't pass
>>> this
>>> mempool policy.
>>>
>>> 2. Packages must be topologically sorted: if any dependencies exist
>>> between
>>> transactions, parents must appear somewhere before children. [8]
>>>
>>> 3. A package cannot have conflicting transactions, i.e. none of them can
>>> spend
>>> the same inputs. This also means there cannot be duplicate transactions.
>>> [8]
>>>
>>> 4. When packages are evaluated against ancestor/descendant limits in a
>>> test
>>> accept, the union of all of their descendants and ancestors is
>>> considered. This
>>> is essentially a "worst case" heuristic where every transaction in the
>>> package
>>> is treated as each other's ancestor and descendant. [8]
>>> Packages for which ancestor/descendant limits are accurately captured by
>>> this
>>> heuristic: [19]
>>>
>>> There are also limitations such as the fact that CPFP carve out is not
>>> applied
>>> to package transactions. #20833 also disables RBF in package validation;
>>> this
>>> proposal overrides that to allow packages to use RBF.
>>>
>>> ## Proposed Changes
>>>
>>> The next step in the Package Mempool Accept project is to implement
>>> submission
>>> to mempool, initially through RPC only. This allows us to test the
>>> submission
>>> logic before exposing it on P2P.
>>>
>>> ### Summary
>>>
>>> - Packages may contain already-in-mempool transactions.
>>> - Packages are 2 generations, Multi-Parent-1-Child.
>>> - Fee-related checks use the package feerate. This means that wallets can
>>> create a package that utilizes CPFP.
>>> - Parents are allowed to RBF mempool transactions with a set of rules
>>> similar
>>> to BIP125. This enables a combination of CPFP and RBF, where a
>>> transaction's descendant fees pay for replacing mempool conflicts.
>>>
>>> There is a draft implementation in [#22290][1]. It is WIP, but feedback
>>> is
>>> always welcome.
>>>
>>> ### Details
>>>
>>> #### Packages May Contain Already-in-Mempool Transactions
>>>
>>> A package may contain transactions that are already in the mempool. We
>>> remove
>>> ("deduplicate") those transactions from the package for the purposes of
>>> package
>>> mempool acceptance. If a package is empty after deduplication, we do
>>> nothing.
>>>
>>> *Rationale*: Mempools vary across the network. It's possible for a
>>> parent to be
>>> accepted to the mempool of a peer on its own due to differences in
>>> policy and
>>> fee market fluctuations. We should not reject or penalize the entire
>>> package for
>>> an individual transaction as that could be a censorship vector.
>>>
>>> #### Packages Are Multi-Parent-1-Child
>>>
>>> Only packages of a specific topology are permitted. Namely, a package is
>>> exactly
>>> 1 child with all of its unconfirmed parents. After deduplication, the
>>> package
>>> may be exactly the same, empty, 1 child, 1 child with just some of its
>>> unconfirmed parents, etc. Note that it's possible for the parents to be
>>> indirect
>>> descendants/ancestors of one another, or for parent and child to share a
>>> parent,
>>> so we cannot make any other topology assumptions.
>>>
>>> *Rationale*: This allows for fee-bumping by CPFP. Allowing multiple
>>> parents
>>> makes it possible to fee-bump a batch of transactions. Restricting
>>> packages to a
>>> defined topology is also easier to reason about and simplifies the
>>> validation
>>> logic greatly. Multi-parent-1-child allows us to think of the package as
>>> one big
>>> transaction, where:
>>>
>>> - Inputs = all the inputs of parents + inputs of the child that come from
>>> confirmed UTXOs
>>> - Outputs = all the outputs of the child + all outputs of the parents
>>> that
>>> aren't spent by other transactions in the package
>>>
>>> Examples of packages that follow this rule (variations of example A show
>>> some
>>> possibilities after deduplication): ![image][15]
>>>
>>> #### Fee-Related Checks Use Package Feerate
>>>
>>> Package Feerate = the total modified fees divided by the total virtual
>>> size of
>>> all transactions in the package.
>>>
>>> To meet the two feerate requirements of a mempool, i.e., the
>>> pre-configured
>>> minimum relay feerate (`minRelayTxFee`) and dynamic mempool minimum
>>> feerate, the
>>> total package feerate is used instead of the individual feerate. The
>>> individual
>>> transactions are allowed to be below feerate requirements if the package
>>> meets
>>> the feerate requirements. For example, the parent(s) in the package can
>>> have 0
>>> fees but be paid for by the child.
>>>
>>> *Rationale*: This can be thought of as "CPFP within a package," solving
>>> the
>>> issue of a parent not meeting minimum fees on its own. This allows L2
>>> applications to adjust their fees at broadcast time instead of
>>> overshooting or
>>> risking getting stuck/pinned.
>>>
>>> We use the package feerate of the package *after deduplication*.
>>>
>>> *Rationale*: It would be incorrect to use the fees of transactions that
>>> are
>>> already in the mempool, as we do not want a transaction's fees to be
>>> double-counted for both its individual RBF and package RBF.
>>>
>>> Examples F and G [14] show the same package, but P1 is submitted
>>> individually before
>>> the package in example G. In example F, we can see that the 300vB
>>> package pays
>>> an additional 200sat in fees, which is not enough to pay for its own
>>> bandwidth
>>> (BIP125#4). In example G, we can see that P1 pays enough to replace M1,
>>> but
>>> using P1's fees again during package submission would make it look like
>>> a 300sat
>>> increase for a 200vB package. Even including its fees and size would not
>>> be
>>> sufficient in this example, since the 300sat looks like enough for the
>>> 300vB
>>> package. The calculcation after deduplication is 100sat increase for a
>>> package
>>> of size 200vB, which correctly fails BIP125#4. Assume all transactions
>>> have a
>>> size of 100vB.
>>>
>>> #### Package RBF
>>>
>>> If a package meets feerate requirements as a package, the parents in the
>>> transaction are allowed to replace-by-fee mempool transactions. The
>>> child cannot
>>> replace mempool transactions. Multiple transactions can replace the same
>>> transaction, but in order to be valid, none of the transactions can try
>>> to
>>> replace an ancestor of another transaction in the same package (which
>>> would thus
>>> make its inputs unavailable).
>>>
>>> *Rationale*: Even if we are using package feerate, a package will not
>>> propagate
>>> as intended if RBF still requires each individual transaction to meet the
>>> feerate requirements.
>>>
>>> We use a set of rules slightly modified from BIP125 as follows:
>>>
>>> ##### Signaling (Rule #1)
>>>
>>> All mempool transactions to be replaced must signal replaceability.
>>>
>>> *Rationale*: Package RBF signaling logic should be the same for package
>>> RBF and
>>> single transaction acceptance. This would be updated if single
>>> transaction
>>> validation moves to full RBF.
>>>
>>> ##### New Unconfirmed Inputs (Rule #2)
>>>
>>> A package may include new unconfirmed inputs, but the ancestor feerate
>>> of the
>>> child must be at least as high as the ancestor feerates of every
>>> transaction
>>> being replaced. This is contrary to BIP125#2, which states "The
>>> replacement
>>> transaction may only include an unconfirmed input if that input was
>>> included in
>>> one of the original transactions. (An unconfirmed input spends an output
>>> from a
>>> currently-unconfirmed transaction.)"
>>>
>>> *Rationale*: The purpose of BIP125#2 is to ensure that the replacement
>>> transaction has a higher ancestor score than the original transaction(s)
>>> (see
>>> [comment][13]). Example H [16] shows how adding a new unconfirmed input
>>> can lower the
>>> ancestor score of the replacement transaction. P1 is trying to replace
>>> M1, and
>>> spends an unconfirmed output of M2. P1 pays 800sat, M1 pays 600sat, and
>>> M2 pays
>>> 100sat. Assume all transactions have a size of 100vB. While, in
>>> isolation, P1
>>> looks like a better mining candidate than M1, it must be mined with M2,
>>> so its
>>> ancestor feerate is actually 4.5sat/vB. This is lower than M1's ancestor
>>> feerate, which is 6sat/vB.
>>>
>>> In package RBF, the rule analogous to BIP125#2 would be "none of the
>>> transactions in the package can spend new unconfirmed inputs." Example J
>>> [17] shows
>>> why, if any of the package transactions have ancestors, package feerate
>>> is no
>>> longer accurate. Even though M2 and M3 are not ancestors of P1 (which is
>>> the
>>> replacement transaction in an RBF), we're actually interested in the
>>> entire
>>> package. A miner should mine M1 which is 5sat/vB instead of M2, M3, P1,
>>> P2, and
>>> P3, which is only 4sat/vB. The Package RBF rule cannot be loosened to
>>> only allow
>>> the child to have new unconfirmed inputs, either, because it can still
>>> cause us
>>> to overestimate the package's ancestor score.
>>>
>>> However, enforcing a rule analogous to BIP125#2 would not only make
>>> Package RBF
>>> less useful, but would also break Package RBF for packages with parents
>>> already
>>> in the mempool: if a package parent has already been submitted, it would
>>> look
>>> like the child is spending a "new" unconfirmed input. In example K [18],
>>> we're
>>> looking to replace M1 with the entire package including P1, P2, and P3.
>>> We must
>>> consider the case where one of the parents is already in the mempool (in
>>> this
>>> case, P2), which means we must allow P3 to have new unconfirmed inputs.
>>> However,
>>> M2 lowers the ancestor score of P3 to 4.3sat/vB, so we should not
>>> replace M1
>>> with this package.
>>>
>>> Thus, the package RBF rule regarding new unconfirmed inputs is less
>>> strict than
>>> BIP125#2. However, we still achieve the same goal of requiring the
>>> replacement
>>> transactions to have a ancestor score at least as high as the original
>>> ones. As
>>> a result, the entire package is required to be a higher feerate mining
>>> candidate
>>> than each of the replaced transactions.
>>>
>>> Another note: the [comment][13] above the BIP125#2 code in the original
>>> RBF
>>> implementation suggests that the rule was intended to be temporary.
>>>
>>> ##### Absolute Fee (Rule #3)
>>>
>>> The package must increase the absolute fee of the mempool, i.e. the
>>> total fees
>>> of the package must be higher than the absolute fees of the mempool
>>> transactions
>>> it replaces. Combined with the CPFP rule above, this differs from BIP125
>>> Rule #3
>>> - an individual transaction in the package may have lower fees than the
>>> transaction(s) it is replacing. In fact, it may have 0 fees, and the
>>> child
>>> pays for RBF.
>>>
>>> ##### Feerate (Rule #4)
>>>
>>> The package must pay for its own bandwidth; the package feerate must be
>>> higher
>>> than the replaced transactions by at least minimum relay feerate
>>> (`incrementalRelayFee`). Combined with the CPFP rule above, this differs
>>> from
>>> BIP125 Rule #4 - an individual transaction in the package can have a
>>> lower
>>> feerate than the transaction(s) it is replacing. In fact, it may have 0
>>> fees,
>>> and the child pays for RBF.
>>>
>>> ##### Total Number of Replaced Transactions (Rule #5)
>>>
>>> The package cannot replace more than 100 mempool transactions. This is
>>> identical
>>> to BIP125 Rule #5.
>>>
>>> ### Expected FAQs
>>>
>>> 1. Is it possible for only some of the package to make it into the
>>> mempool?
>>>
>>> Yes, it is. However, since we evict transactions from the mempool by
>>> descendant score and the package child is supposed to be sponsoring the
>>> fees of
>>> its parents, the most common scenario would be all-or-nothing. This is
>>> incentive-compatible. In fact, to be conservative, package validation
>>> should
>>> begin by trying to submit all of the transactions individually, and only
>>> use the
>>> package mempool acceptance logic if the parents fail due to low feerate.
>>>
>>> 2. Should we allow packages to contain already-confirmed transactions?
>>>
>>> No, for practical reasons. In mempool validation, we actually aren't
>>> able to
>>> tell with 100% confidence if we are looking at a transaction that has
>>> already
>>> confirmed, because we look up inputs using a UTXO set. If we have
>>> historical
>>> block data, it's possible to look for it, but this is inefficient, not
>>> always
>>> possible for pruning nodes, and unnecessary because we're not going to do
>>> anything with the transaction anyway. As such, we already have the
>>> expectation
>>> that transaction relay is somewhat "stateful" i.e. nobody should be
>>> relaying
>>> transactions that have already been confirmed. Similarly, we shouldn't be
>>> relaying packages that contain already-confirmed transactions.
>>>
>>> [1]: https://github.com/bitcoin/bitcoin/pull/22290
>>> [2]:
>>> https://github.com/bitcoin/bips/blob/1f0b563738199ca60d32b4ba779797fc97d040fe/bip-0141.mediawiki#transaction-size-calculations
>>> [3]:
>>> https://github.com/bitcoin/bitcoin/blob/94f83534e4b771944af7d9ed0f40746f392eb75e/src/policy/policy.cpp#L282
>>> [4]: https://github.com/bitcoin/bitcoin/pull/16400
>>> [5]: https://github.com/bitcoin/bitcoin/pull/21062
>>> [6]: https://github.com/bitcoin/bitcoin/pull/22675
>>> [7]: https://github.com/bitcoin/bitcoin/pull/22796
>>> [8]: https://github.com/bitcoin/bitcoin/pull/20833
>>> [9]: https://github.com/bitcoin/bitcoin/pull/21800
>>> [10]: https://github.com/bitcoin/bitcoin/pull/16401
>>> [11]: https://github.com/bitcoin/bitcoin/pull/19621
>>> [12]: https://github.com/bitcoin/bips/blob/master/bip-0125.mediawiki
>>> [13]:
>>> https://github.com/bitcoin/bitcoin/pull/6871/files#diff-34d21af3c614ea3cee120df276c9c4ae95053830d7f1d3deaf009a4625409ad2R1101-R1104
>>> [14]:
>>>
>>> [15]:
>>>
>>> [16]:
>>>
>>> [17]:
>>>
>>> [18]:
>>>
>>> [19]:
>>>
>>> [20]:
>>>
>>> _______________________________________________
>>> bitcoin-dev mailing list
>>> bitcoin-dev at lists.linuxfoundation.org
>>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20210923/f8611b91/attachment-0001.html>;

📅 Original date posted:2021-09-19 📝 Original message:Hi ...

2023-06-08T00:59:16+02:00

In reply to nevent1q…7gga
_________________________

📅 Original date posted:2021-09-19
📝 Original message:Hi Gloria,

> A package may contain transactions that are already in the mempool. We
> remove
> ("deduplicate") those transactions from the package for the purposes of
> package
> mempool acceptance. If a package is empty after deduplication, we do
> nothing.

IIUC, you have a package A+B+C submitted for acceptance and A is already in
your mempool. You trim out A from the package and then evaluate B+C.

I think this might be an issue if A is the higher-fee element of the ABC
package. B+C package fees might be under the mempool min fee and will be
rejected, potentially breaking the acceptance expectations of the package
issuer ?

Further, I think the dedup should be done on wtxid, as you might have
multiple valid witnesses. Though with varying vsizes and as such offering
different feerates.

E.g you're going to evaluate the package A+B and A' is already in your
mempool with a bigger valid witness. You trim A based on txid, then you
evaluate A'+B, which fails the fee checks. However, evaluating A+B would
have been a success.

AFAICT, the dedup rationale would be to save on CPU time/IO disk, to avoid
repeated signatures verification and parent UTXOs fetches ? Can we achieve
the same goal by bypassing tx-level checks for already-in txn while
conserving the package integrity for package-level checks ?

> Note that it's possible for the parents to be
> indirect
> descendants/ancestors of one another, or for parent and child to share a
> parent,
> so we cannot make any other topology assumptions.

I'm not clearly understanding the accepted topologies. By "parent and child
to share a parent", do you mean the set of transactions A, B, C, where B is
spending A and C is spending A and B would be correct ?

If yes, is there a width-limit introduced or we fallback on
MAX_PACKAGE_COUNT=25 ?

IIRC, one rationale to come with this topology limitation was to lower the
DoS risks when potentially deploying p2p packages.

Considering the current Core's mempool acceptance rules, I think CPFP
batching is unsafe for LN time-sensitive closure. A malicious tx-relay
jamming successful on one channel commitment transaction would contamine
the remaining commitments sharing the same package.

E.g, you broadcast the package A+B+C+D+E where A,B,C,D are commitment
transactions and E a shared CPFP. If a malicious A' transaction has a
better feerate than A, the whole package acceptance will fail. Even if A'
confirms in the following block,
the propagation and confirmation of B+C+D have been delayed. This could
carry on a loss of funds.

That said, if you're broadcasting commitment transactions without
time-sensitive HTLC outputs, I think the batching is effectively a fee
saving as you don't have to duplicate the CPFP.

IMHO, I'm leaning towards deploying during a first phase 1-parent/1-child.
I think it's the most conservative step still improving second-layer safety.

> *Rationale*: It would be incorrect to use the fees of transactions that
are
> already in the mempool, as we do not want a transaction's fees to be
> double-counted for both its individual RBF and package RBF.

I'm unsure about the logical order of the checks proposed.

If A+B is submitted to replace A', where A pays 0 sats, B pays 200 sats and
A' pays 100 sats. If we apply the individual RBF on A, A+B acceptance
fails. For this reason I think the individual RBF should be bypassed and
only the package RBF apply ?

Note this situation is plausible, with current LN design, your counterparty
can have a commitment transaction with a better fee just by selecting a
higher `dust_limit_satoshis` than yours.

> Examples F and G [14] show the same package, but P1 is submitted
> individually before
> the package in example G. In example F, we can see that the 300vB package
> pays
> an additional 200sat in fees, which is not enough to pay for its own
> bandwidth
> (BIP125#4). In example G, we can see that P1 pays enough to replace M1,
but
> using P1's fees again during package submission would make it look like a
> 300sat
> increase for a 200vB package. Even including its fees and size would not
be
> sufficient in this example, since the 300sat looks like enough for the
300vB
> package. The calculcation after deduplication is 100sat increase for a
> package
> of size 200vB, which correctly fails BIP125#4. Assume all transactions
have
> a
> size of 100vB.

What problem are you trying to solve by the package feerate *after* dedup
rule ?

My understanding is that an in-package transaction might be already in the
mempool. Therefore, to compute a correct RBF penalty replacement, the vsize
of this transaction could be discarded lowering the cost of package RBF.

If we keep a "safe" dedup mechanism (see my point above), I think this
discount is justified, as the validation cost of node operators is paid for
?

> The child cannot replace mempool transactions.

Let's say you issue package A+B, then package C+B', where B' is a child of
both A and C. This rule fails the acceptance of C+B' ?

I think this is a footgunish API, as if a package issuer send the
multiple-parent-one-child package A,B,C,D where D is the child of A,B,C.
Then try to broadcast the higher-feerate C'+D' package, it should be
rejected. So it's breaking the naive broadcaster assumption that a
higher-feerate/higher-fee package always replaces ? And it might be unsafe
in protocols where states are symmetric. E.g a malicious counterparty
broadcasts first S+A, then you honestly broadcast S+B, where B pays better
fees.

> All mempool transactions to be replaced must signal replaceability.

I think this is unsafe for L2s if counterparties have malleability of the
child transaction. They can block your package replacement by opting-out
from RBF signaling. IIRC, LN's "anchor output" presents such an ability.

I think it's better to either fix inherited signaling or move towards
full-rbf.

> if a package parent has already been submitted, it would
> look
>like the child is spending a "new" unconfirmed input.

I think this is an issue brought by the trimming during the dedup phase. If
we preserve the package integrity, only re-using the tx-level checks
results of already in-mempool transactions to gain in CPU time we won't
have this issue. Package childs can add unconfirmed inputs as long as
they're in-package, the bip125 rule2 is only evaluated against parents ?

> However, we still achieve the same goal of requiring the
> replacement
> transactions to have a ancestor score at least as high as the original
> ones.

I'm not sure if this holds...

Let's say you have in-mempool A, B where A pays 10 sat/vb for 100 vbytes
and B pays 10 sat/vb for 100 vbytes. You have the candidate replacement D
spending both A and C where D pays 15sat/vb for 100 vbytes and C pays 1
sat/vb for 1000 vbytes.

Package A + B ancestor score is 10 sat/vb.

D has a higher feerate/absolute fee than B.

Package A + C + D ancestor score is ~ 3 sat/vb ((A's 1000 sats + C's 1000
sats + D's 1500 sats) /
A's 100 vb + C's 1000 vb + D's 100 vb)

Overall, this is a review through the lenses of LN requirements. I think
other L2 protocols/applications
could be candidates to using package accept/relay such as:
* https://github.com/lightninglabs/pool
* https://github.com/discreetlogcontracts/dlcspecs
* https://github.com/bitcoin-teleport/teleport-transactions/
* https://github.com/sapio-lang/sapio
* https://github.com/commerceblock/mercury/blob/master/doc/statechains.md
* https://github.com/revault/practical-revault

Thanks for rolling forward the ball on this subject.

Antoine

Le jeu. 16 sept. 2021 à 03:55, Gloria Zhao via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> a écrit :

> Hi there,
>
> I'm writing to propose a set of mempool policy changes to enable package
> validation (in preparation for package relay) in Bitcoin Core. These would
> not
> be consensus or P2P protocol changes. However, since mempool policy
> significantly affects transaction propagation, I believe this is relevant
> for
> the mailing list.
>
> My proposal enables packages consisting of multiple parents and 1 child.
> If you
> develop software that relies on specific transaction relay assumptions
> and/or
> are interested in using package relay in the future, I'm very interested
> to hear
> your feedback on the utility or restrictiveness of these package policies
> for
> your use cases.
>
> A draft implementation of this proposal can be found in [Bitcoin Core
> PR#22290][1].
>
> An illustrated version of this post can be found at
> https://gist.github.com/glozow/dc4e9d5c5b14ade7cdfac40f43adb18a.
> I have also linked the images below.
>
> ## Background
>
> Feel free to skip this section if you are already familiar with mempool
> policy
> and package relay terminology.
>
> ### Terminology Clarifications
>
> * Package = an ordered list of related transactions, representable by a
> Directed
> Acyclic Graph.
> * Package Feerate = the total modified fees divided by the total virtual
> size of
> all transactions in the package.
> - Modified fees = a transaction's base fees + fee delta applied by the
> user
> with `prioritisetransaction`. As such, we expect this to vary across
> mempools.
> - Virtual Size = the maximum of virtual sizes calculated using [BIP141
> virtual size][2] and sigop weight. [Implemented here in Bitcoin
> Core][3].
> - Note that feerate is not necessarily based on the base fees and
> serialized
> size.
>
> * Fee-Bumping = user/wallet actions that take advantage of miner
> incentives to
> boost a transaction's candidacy for inclusion in a block, including
> Child Pays
> for Parent (CPFP) and [BIP125][12] Replace-by-Fee (RBF). Our intention in
> mempool policy is to recognize when the new transaction is more economical
> to
> mine than the original one(s) but not open DoS vectors, so there are some
> limitations.
>
> ### Policy
>
> The purpose of the mempool is to store the best (to be most
> incentive-compatible
> with miners, highest feerate) candidates for inclusion in a block. Miners
> use
> the mempool to build block templates. The mempool is also useful as a
> cache for
> boosting block relay and validation performance, aiding transaction relay,
> and
> generating feerate estimations.
>
> Ideally, all consensus-valid transactions paying reasonable fees should
> make it
> to miners through normal transaction relay, without any special
> connectivity or
> relationships with miners. On the other hand, nodes do not have unlimited
> resources, and a P2P network designed to let any honest node broadcast
> their
> transactions also exposes the transaction validation engine to DoS attacks
> from
> malicious peers.
>
> As such, for unconfirmed transactions we are considering for our mempool,
> we
> apply a set of validation rules in addition to consensus, primarily to
> protect
> us from resource exhaustion and aid our efforts to keep the highest fee
> transactions. We call this mempool _policy_: a set of (configurable,
> node-specific) rules that transactions must abide by in order to be
> accepted
> into our mempool. Transaction "Standardness" rules and mempool
> restrictions such
> as "too-long-mempool-chain" are both examples of policy.
>
> ### Package Relay and Package Mempool Accept
>
> In transaction relay, we currently consider transactions one at a time for
> submission to the mempool. This creates a limitation in the node's ability
> to
> determine which transactions have the highest feerates, since we cannot
> take
> into account descendants (i.e. cannot use CPFP) until all the transactions
> are
> in the mempool. Similarly, we cannot use a transaction's descendants when
> considering it for RBF. When an individual transaction does not meet the
> mempool
> minimum feerate and the user isn't able to create a replacement transaction
> directly, it will not be accepted by mempools.
>
> This limitation presents a security issue for applications and users
> relying on
> time-sensitive transactions. For example, Lightning and other protocols
> create
> UTXOs with multiple spending paths, where one counterparty's spending path
> opens
> up after a timelock, and users are protected from cheating scenarios as
> long as
> they redeem on-chain in time. A key security assumption is that all
> parties'
> transactions will propagate and confirm in a timely manner. This
> assumption can
> be broken if fee-bumping does not work as intended.
>
> The end goal for Package Relay is to consider multiple transactions at the
> same
> time, e.g. a transaction with its high-fee child. This may help us better
> determine whether transactions should be accepted to our mempool,
> especially if
> they don't meet fee requirements individually or are better RBF candidates
> as a
> package. A combination of changes to mempool validation logic, policy, and
> transaction relay allows us to better propagate the transactions with the
> highest package feerates to miners, and makes fee-bumping tools more
> powerful
> for users.
>
> The "relay" part of Package Relay suggests P2P messaging changes, but a
> large
> part of the changes are in the mempool's package validation logic. We call
> this
> *Package Mempool Accept*.
>
> ### Previous Work
>
> * Given that mempool validation is DoS-sensitive and complex, it would be
> dangerous to haphazardly tack on package validation logic. Many efforts
> have
> been made to make mempool validation less opaque (see [#16400][4],
> [#21062][5],
> [#22675][6], [#22796][7]).
> * [#20833][8] Added basic capabilities for package validation, test
> accepts only
> (no submission to mempool).
> * [#21800][9] Implemented package ancestor/descendant limit checks for
> arbitrary
> packages. Still test accepts only.
> * Previous package relay proposals (see [#16401][10], [#19621][11]).
>
> ### Existing Package Rules
>
> These are in master as introduced in [#20833][8] and [#21800][9]. I'll
> consider
> them as "given" in the rest of this document, though they can be changed,
> since
> package validation is test-accept only right now.
>
> 1. A package cannot exceed `MAX_PACKAGE_COUNT=25` count and
> `MAX_PACKAGE_SIZE=101KvB` total size [8]
>
> *Rationale*: This is already enforced as mempool ancestor/descendant
> limits.
> Presumably, transactions in a package are all related, so exceeding this
> limit
> would mean that the package can either be split up or it wouldn't pass this
> mempool policy.
>
> 2. Packages must be topologically sorted: if any dependencies exist between
> transactions, parents must appear somewhere before children. [8]
>
> 3. A package cannot have conflicting transactions, i.e. none of them can
> spend
> the same inputs. This also means there cannot be duplicate transactions.
> [8]
>
> 4. When packages are evaluated against ancestor/descendant limits in a test
> accept, the union of all of their descendants and ancestors is considered.
> This
> is essentially a "worst case" heuristic where every transaction in the
> package
> is treated as each other's ancestor and descendant. [8]
> Packages for which ancestor/descendant limits are accurately captured by
> this
> heuristic: [19]
>
> There are also limitations such as the fact that CPFP carve out is not
> applied
> to package transactions. #20833 also disables RBF in package validation;
> this
> proposal overrides that to allow packages to use RBF.
>
> ## Proposed Changes
>
> The next step in the Package Mempool Accept project is to implement
> submission
> to mempool, initially through RPC only. This allows us to test the
> submission
> logic before exposing it on P2P.
>
> ### Summary
>
> - Packages may contain already-in-mempool transactions.
> - Packages are 2 generations, Multi-Parent-1-Child.
> - Fee-related checks use the package feerate. This means that wallets can
> create a package that utilizes CPFP.
> - Parents are allowed to RBF mempool transactions with a set of rules
> similar
> to BIP125. This enables a combination of CPFP and RBF, where a
> transaction's descendant fees pay for replacing mempool conflicts.
>
> There is a draft implementation in [#22290][1]. It is WIP, but feedback is
> always welcome.
>
> ### Details
>
> #### Packages May Contain Already-in-Mempool Transactions
>
> A package may contain transactions that are already in the mempool. We
> remove
> ("deduplicate") those transactions from the package for the purposes of
> package
> mempool acceptance. If a package is empty after deduplication, we do
> nothing.
>
> *Rationale*: Mempools vary across the network. It's possible for a parent
> to be
> accepted to the mempool of a peer on its own due to differences in policy
> and
> fee market fluctuations. We should not reject or penalize the entire
> package for
> an individual transaction as that could be a censorship vector.
>
> #### Packages Are Multi-Parent-1-Child
>
> Only packages of a specific topology are permitted. Namely, a package is
> exactly
> 1 child with all of its unconfirmed parents. After deduplication, the
> package
> may be exactly the same, empty, 1 child, 1 child with just some of its
> unconfirmed parents, etc. Note that it's possible for the parents to be
> indirect
> descendants/ancestors of one another, or for parent and child to share a
> parent,
> so we cannot make any other topology assumptions.
>
> *Rationale*: This allows for fee-bumping by CPFP. Allowing multiple parents
> makes it possible to fee-bump a batch of transactions. Restricting
> packages to a
> defined topology is also easier to reason about and simplifies the
> validation
> logic greatly. Multi-parent-1-child allows us to think of the package as
> one big
> transaction, where:
>
> - Inputs = all the inputs of parents + inputs of the child that come from
> confirmed UTXOs
> - Outputs = all the outputs of the child + all outputs of the parents that
> aren't spent by other transactions in the package
>
> Examples of packages that follow this rule (variations of example A show
> some
> possibilities after deduplication): ![image][15]
>
> #### Fee-Related Checks Use Package Feerate
>
> Package Feerate = the total modified fees divided by the total virtual
> size of
> all transactions in the package.
>
> To meet the two feerate requirements of a mempool, i.e., the pre-configured
> minimum relay feerate (`minRelayTxFee`) and dynamic mempool minimum
> feerate, the
> total package feerate is used instead of the individual feerate. The
> individual
> transactions are allowed to be below feerate requirements if the package
> meets
> the feerate requirements. For example, the parent(s) in the package can
> have 0
> fees but be paid for by the child.
>
> *Rationale*: This can be thought of as "CPFP within a package," solving the
> issue of a parent not meeting minimum fees on its own. This allows L2
> applications to adjust their fees at broadcast time instead of
> overshooting or
> risking getting stuck/pinned.
>
> We use the package feerate of the package *after deduplication*.
>
> *Rationale*: It would be incorrect to use the fees of transactions that
> are
> already in the mempool, as we do not want a transaction's fees to be
> double-counted for both its individual RBF and package RBF.
>
> Examples F and G [14] show the same package, but P1 is submitted
> individually before
> the package in example G. In example F, we can see that the 300vB package
> pays
> an additional 200sat in fees, which is not enough to pay for its own
> bandwidth
> (BIP125#4). In example G, we can see that P1 pays enough to replace M1, but
> using P1's fees again during package submission would make it look like a
> 300sat
> increase for a 200vB package. Even including its fees and size would not be
> sufficient in this example, since the 300sat looks like enough for the
> 300vB
> package. The calculcation after deduplication is 100sat increase for a
> package
> of size 200vB, which correctly fails BIP125#4. Assume all transactions
> have a
> size of 100vB.
>
> #### Package RBF
>
> If a package meets feerate requirements as a package, the parents in the
> transaction are allowed to replace-by-fee mempool transactions. The child
> cannot
> replace mempool transactions. Multiple transactions can replace the same
> transaction, but in order to be valid, none of the transactions can try to
> replace an ancestor of another transaction in the same package (which
> would thus
> make its inputs unavailable).
>
> *Rationale*: Even if we are using package feerate, a package will not
> propagate
> as intended if RBF still requires each individual transaction to meet the
> feerate requirements.
>
> We use a set of rules slightly modified from BIP125 as follows:
>
> ##### Signaling (Rule #1)
>
> All mempool transactions to be replaced must signal replaceability.
>
> *Rationale*: Package RBF signaling logic should be the same for package
> RBF and
> single transaction acceptance. This would be updated if single transaction
> validation moves to full RBF.
>
> ##### New Unconfirmed Inputs (Rule #2)
>
> A package may include new unconfirmed inputs, but the ancestor feerate of
> the
> child must be at least as high as the ancestor feerates of every
> transaction
> being replaced. This is contrary to BIP125#2, which states "The replacement
> transaction may only include an unconfirmed input if that input was
> included in
> one of the original transactions. (An unconfirmed input spends an output
> from a
> currently-unconfirmed transaction.)"
>
> *Rationale*: The purpose of BIP125#2 is to ensure that the replacement
> transaction has a higher ancestor score than the original transaction(s)
> (see
> [comment][13]). Example H [16] shows how adding a new unconfirmed input
> can lower the
> ancestor score of the replacement transaction. P1 is trying to replace M1,
> and
> spends an unconfirmed output of M2. P1 pays 800sat, M1 pays 600sat, and M2
> pays
> 100sat. Assume all transactions have a size of 100vB. While, in isolation,
> P1
> looks like a better mining candidate than M1, it must be mined with M2, so
> its
> ancestor feerate is actually 4.5sat/vB. This is lower than M1's ancestor
> feerate, which is 6sat/vB.
>
> In package RBF, the rule analogous to BIP125#2 would be "none of the
> transactions in the package can spend new unconfirmed inputs." Example J
> [17] shows
> why, if any of the package transactions have ancestors, package feerate is
> no
> longer accurate. Even though M2 and M3 are not ancestors of P1 (which is
> the
> replacement transaction in an RBF), we're actually interested in the entire
> package. A miner should mine M1 which is 5sat/vB instead of M2, M3, P1,
> P2, and
> P3, which is only 4sat/vB. The Package RBF rule cannot be loosened to only
> allow
> the child to have new unconfirmed inputs, either, because it can still
> cause us
> to overestimate the package's ancestor score.
>
> However, enforcing a rule analogous to BIP125#2 would not only make
> Package RBF
> less useful, but would also break Package RBF for packages with parents
> already
> in the mempool: if a package parent has already been submitted, it would
> look
> like the child is spending a "new" unconfirmed input. In example K [18],
> we're
> looking to replace M1 with the entire package including P1, P2, and P3. We
> must
> consider the case where one of the parents is already in the mempool (in
> this
> case, P2), which means we must allow P3 to have new unconfirmed inputs.
> However,
> M2 lowers the ancestor score of P3 to 4.3sat/vB, so we should not replace
> M1
> with this package.
>
> Thus, the package RBF rule regarding new unconfirmed inputs is less strict
> than
> BIP125#2. However, we still achieve the same goal of requiring the
> replacement
> transactions to have a ancestor score at least as high as the original
> ones. As
> a result, the entire package is required to be a higher feerate mining
> candidate
> than each of the replaced transactions.
>
> Another note: the [comment][13] above the BIP125#2 code in the original RBF
> implementation suggests that the rule was intended to be temporary.
>
> ##### Absolute Fee (Rule #3)
>
> The package must increase the absolute fee of the mempool, i.e. the total
> fees
> of the package must be higher than the absolute fees of the mempool
> transactions
> it replaces. Combined with the CPFP rule above, this differs from BIP125
> Rule #3
> - an individual transaction in the package may have lower fees than the
> transaction(s) it is replacing. In fact, it may have 0 fees, and the
> child
> pays for RBF.
>
> ##### Feerate (Rule #4)
>
> The package must pay for its own bandwidth; the package feerate must be
> higher
> than the replaced transactions by at least minimum relay feerate
> (`incrementalRelayFee`). Combined with the CPFP rule above, this differs
> from
> BIP125 Rule #4 - an individual transaction in the package can have a lower
> feerate than the transaction(s) it is replacing. In fact, it may have 0
> fees,
> and the child pays for RBF.
>
> ##### Total Number of Replaced Transactions (Rule #5)
>
> The package cannot replace more than 100 mempool transactions. This is
> identical
> to BIP125 Rule #5.
>
> ### Expected FAQs
>
> 1. Is it possible for only some of the package to make it into the mempool?
>
> Yes, it is. However, since we evict transactions from the mempool by
> descendant score and the package child is supposed to be sponsoring the
> fees of
> its parents, the most common scenario would be all-or-nothing. This is
> incentive-compatible. In fact, to be conservative, package validation
> should
> begin by trying to submit all of the transactions individually, and only
> use the
> package mempool acceptance logic if the parents fail due to low feerate.
>
> 2. Should we allow packages to contain already-confirmed transactions?
>
> No, for practical reasons. In mempool validation, we actually aren't
> able to
> tell with 100% confidence if we are looking at a transaction that has
> already
> confirmed, because we look up inputs using a UTXO set. If we have
> historical
> block data, it's possible to look for it, but this is inefficient, not
> always
> possible for pruning nodes, and unnecessary because we're not going to do
> anything with the transaction anyway. As such, we already have the
> expectation
> that transaction relay is somewhat "stateful" i.e. nobody should be
> relaying
> transactions that have already been confirmed. Similarly, we shouldn't be
> relaying packages that contain already-confirmed transactions.
>
> [1]: https://github.com/bitcoin/bitcoin/pull/22290
> [2]:
> https://github.com/bitcoin/bips/blob/1f0b563738199ca60d32b4ba779797fc97d040fe/bip-0141.mediawiki#transaction-size-calculations
> [3]:
> https://github.com/bitcoin/bitcoin/blob/94f83534e4b771944af7d9ed0f40746f392eb75e/src/policy/policy.cpp#L282
> [4]: https://github.com/bitcoin/bitcoin/pull/16400
> [5]: https://github.com/bitcoin/bitcoin/pull/21062
> [6]: https://github.com/bitcoin/bitcoin/pull/22675
> [7]: https://github.com/bitcoin/bitcoin/pull/22796
> [8]: https://github.com/bitcoin/bitcoin/pull/20833
> [9]: https://github.com/bitcoin/bitcoin/pull/21800
> [10]: https://github.com/bitcoin/bitcoin/pull/16401
> [11]: https://github.com/bitcoin/bitcoin/pull/19621
> [12]: https://github.com/bitcoin/bips/blob/master/bip-0125.mediawiki
> [13]:
> https://github.com/bitcoin/bitcoin/pull/6871/files#diff-34d21af3c614ea3cee120df276c9c4ae95053830d7f1d3deaf009a4625409ad2R1101-R1104
> [14]:
>
> [15]:
>
> [16]:
>
> [17]:
>
> [18]:
>
> [19]:
>
> [20]:
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20210919/f11e1976/attachment-0001.html>;

📅 Original date posted:2021-04-23 📝 Original message:Hi ...

2023-06-08T00:52:04+02:00

In reply to nevent1q…94nu
_________________________

📅 Original date posted:2021-04-23
📝 Original message:Hi Luke,

For the records and the subscribers of this list not following
#bitcoin-core-dev, this mail follows a discussion which did happen during
yesterday irc meetings.
Logs here : http://gnusha.org/bitcoin-core-dev/2021-04-22.log

I'll reiterate my opinion expressed during the meeting. If this proposal to
extend the bip editorship membership doesn't satisfy parties involved or
anyone in the community, I'm strongly opposed to have the matter sliced by
admins of the Bitcoin github org. I believe that defect or uncertainty in
the BIP Process shouldn't be solved by GH janitorial roles and I think
their roles don't bestow to intervene in case of loopholes. Further, you
have far more contributors involved in the BIP Process rather than only
Bitcoin Core ones. FWIW, such precedent merits would be quite similar to
lobby directly GH staff...

Unless we harm Bitcoin users by not acting, I think we should always be
respectful of procedural forms. And in the lack of such forms, stay patient
until a solution satisfy everyone.

I would recommend the BIP editorship, once extended or not, to move in its
own repository in the future.

Cheers,
Antoine

Le jeu. 22 avr. 2021 à 22:09, Luke Dashjr via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> a écrit :

> Unless there are objections, I intend to add Kalle Alm as a BIP editor to
> assist in merging PRs into the bips git repo.
>
> Since there is no explicit process to adding BIP editors, IMO it should be
> fine to use BIP 2's Process BIP progression:
>
> > A process BIP may change status from Draft to Active when it achieves
> > rough consensus on the mailing list. Such a proposal is said to have
> > rough consensus if it has been open to discussion on the development
> > mailing list for at least one month, and no person maintains any
> > unaddressed substantiated objections to it.
>
> A Process BIP could be opened for each new editor, but IMO that is
> unnecessary. If anyone feels there is a need for a new Process BIP, we can
> go
> that route, but there is prior precedent for BIP editors appointing new
> BIP
> editors, so I think this should be fine.
>
> Please speak up soon if you disagree.
>
> Luke
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20210423/fb5bccd8/attachment-0001.html>;

📅 Original date posted:2020-09-20 📝 Original message:Right, ...

2023-06-07T20:26:57+02:00

In reply to nevent1q…hlz9
_________________________

📅 Original date posted:2020-09-20
📝 Original message:Right, I was off the shot. Thanks for the explanation.

As you mentioned, if the goal of the sponsor mechanism is to let any party
drive a state N's first tx to completion, you still have the issue of
concurrent states being pinned and thus non-observable for sponsoring by an
honest party.

E.g, Bob can broadcast a thousand of revoked LN states and pin them with
low-feerate sponsors such as these malicious packages absolute fee are
higher than the honest state N. Alice can't fee-sponsor
them as we can assume she hasn't a global view of network mempools. Due to
the proposed policy rule "The Sponsor Vector's entry must be present in the
mempool", Alice's sponsors won't propagate. Even amending this rule, we
can't assume Alice has a thousand of sponsoring utxos to avoid conflict
between her own broadcast.

Of course, offchain protocols designers can limit a participant's
capability to construct a pinning package by constraining its malleability
and thus to always have a compelling feerate. E.g in Lightning you can bind
the size of a commitment transaction by refusing relayed HTLCs and thus
have less HTLC outputs. This security increase comes at the price of less
protocol flexibility, e.g reducing payments throughput.

Further, a malicious counterparty can still take advantage of
mempool-congestion spikes. Even if the pinning package has a compelling
feerate, high enough to bounce off a honest broadcast, there is no
guarantee it stays such. Just after the pinning, congestion can increase
and bury it for long-enough until a timelock expires.

If we want to solve the hard cases of pinning, I still think mempool
acceptance of a whole package only on the merits of feerate is the easiest
solution to reason on.

Le sam. 19 sept. 2020 à 15:46, Jeremy <jlrubin at mit.edu> a écrit :

> Antoine,
>
> Yes I think you're a bit confused on where the actual sponsor vector is.
> If you have a transaction chain A->B->C and a sponsor S_A, S_A commits to
> txid A and A is unaware of S.
>
>
> W.r.t your other points, I fully agree that the 1-to-N sponsored case is
> very compelling. The consensus rules are clear that sponsor commitments are
> non-rival, so there's no issue with allowing as many sponsors as possible
> and including them in aggregate. E.g., if S_A and S'_A both sponsor A with
> feerate(S*) > feerate(A), there's no reason not to include all of them in a
> block. The only issue is denial of service in the mempool. In the future,
> it would definitely be desirable to figure out rules that allow mempools to
> track both multiple sponsors and multiple sponsor targets. But in the
> interest of KISS, the current policy rules are designed to be minimally
> invasive and maximally functional.
>
> In terms of location for the sponsor vector, I'm relatively indifferent.
> The annex is a possible location, but it's a bit odd as we really only need
> to allow one such vector per tx, not one per input, and one per input would
> enable some new use cases (maybe good, maybe bad). Further, being in the
> witness space would mean that if two parties create a 2 input transaction
> with a desired sponsor vector they would both need to specify it as you
> can't sign another input's witness data. I wholeheartedly agree with the
> sentiment though; there could be a more efficient place to put this data,
> but nothing jumps out to me as both efficient and simple in implementation
> (a new tx-level field sounds like a lot of complexity).
>
>
> > n >=1 ? I think you can have at least one vector and this is matching
> the code
>
> yes, this has been fixed in the gist (cred to Dmitry Petukhov for pointing
> it out first), but is correct in the code. Thank you for your careful
> reading.
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20200920/d9355f8d/attachment-0001.html>;

📅 Original date posted:2020-09-19 📝 Original message:EDIT: ...

2023-06-07T20:26:56+02:00

In reply to nevent1q…y4vw
_________________________

📅 Original date posted:2020-09-19
📝 Original message:EDIT: I misunderstood the emplacement of the sponsor vector, please
disregard previous review :( Beyond where the convenient place should live,
which is still accurate I think.

> The
> Sponsor Vector TXIDs must also be
> in the block the transaction is validated in, with no restriction on
> order or on specifying a TXID
> more than once.

Le sam. 19 sept. 2020 à 14:39, Antoine Riard <antoine.riard at gmail.com> a
écrit :

> Hi Jeremy,
>
> This is a really interesting proposal to widen the scope of fee
> mechanisms.
>
> First, a wider point on what this proposal brings with regards to pinning,
> to the best of my knowledge.
>
> A pinning may have different vectors by exploiting a) mempools limits (e.g
> descendants) or b) mempools absolute-fee/feerate/conflicts logic. The lack
> of a global mempool means you can creatively combine them to provoke
> mempools-partitions [0]
>
> As far as I understand this proposal, it aims to solve the class a) of
> pinnings by allowing fee-bumping with a new definition of dependencies. I'm
> not sure it achieves to do so as the Sponsor Vector TXIDs being committed
> in the Sponsoree signature hash means the Sponsor feerate is part of this
> commitment and can't be unilaterally adjusted to actual mempool-congestion.
>
> After broadcasting the Sponsor/Sponsoree pair, mempools feerate may
> increase again and thus obsoleting the previous fee-bump. Or you need a
> Sponsor Vector for every blockspace feerate, in the worst-case bound by the
> value of the Sponsoree funds.
>
> Further, I would say this proposal won't solve class b) of pinnings for
> multi-party time-sensitive protocols without further modifications. E.g in
> a LN-channel, assuming the commitment transaction is the Sponsoree, Alice
> the honest party can't increase Sponsor feerate by mal eating its outputs
> without breaking the sponsoring dependency. And thus evict a Bob's
> malicious pin across network mempools.
>
> I think a further softfork proposal with regards to sighash malleability
> is needed to achieve the security semantic for Lightning type of protocols.
> Roughly, a SIGHASH_IOVECTOR allows N-inputs to commit to N-outputs, thus
> committing to all the balance/HTLC outputs minus the last output Vector,
> non-interactively malleable by channel participants. This would be a form
> of transaction finalization delegation, allowing Alice to direct the
> Sponsor vector to a good-feerate adjusted transaction.
>
> Note, I may have misunderstood completely the proposal as the feerate
> observed might be the Sponsor _package_ one and each party could have a
> pair of outputs to spend from to non-interactively increase the Sponsoree.
> Though sounds like re-introducing the limits issues...
>
> That said, see following review points.
>
> > This is insufficient because if new attacks are found, there is
> > limited ability to deploy fixes for
> > them against deployed contract instances (such as open lightning
> > channels). What is required is a
> > fully abstracted primitive that requires no special structure from an
> > underlying transaction in
> > order to increase fees to confirm the transactions.
>
> This is really true, in case of vulnerability discovered mass closing of
> the channel would be in itself a concern as it would congest mempools and
> open to looter behaviors [1]. Though I don't think a special structure can
> claim covering every potential source of vulnerability for off-chain
> protocols as some of them might be tx-relay based (e.g reject-filters for
> segwit txn).
>
> Further, a "fully abstracted primitive" is loosely defined, one could
> argue that anchor outputs don't require special structure from an
> underlying transaction (i.e on the order of outputs ?).
>
> > where
> n>1, it is interpreted as a vector of TXIDs (Sponsor Vector).
>
> n >=1 ? I think you can have at least one vector and this is matching the
> code
>
> > If there is another convenient place to put the TXID vector, that's fine
> too.
>
> You might use the per-input future Taproot annex, and even apply a witness
> discount as this mechanism could be argued to be less blockspace expensive
> than a CPFP for the same semantic.
>
> An alternative could be a new transaction field like a new `stxid` :
>
>
> `[nVersion][marker][flag][txins][txouts][witness][nLockTime][nSponsor][nVersion][n*STXID]`
>
> It would be cheaper as you likely save the output amount size and OP_VER.
> And you don't have to subtract a dust output + 1 from the other output
> amount to make sure the Sponsor output meets dust propagation requirements.
>
> Though it's more demanding on the tx-relay layer (new serialization and
> transaction identifier) and new a version bump of the signature digest algo
> to avoid a third-party malleating the per-transaction sponsor field
>
> > To prevent garbage sponsors, we also require that:
>
> Does the reverse hold ? Garbage Sponsoree by breaking the dependency and
> double-spending the utxo spent by the Sponsor and thus decreasing
> Sponsoree's feerate to mempool bottom. AFAIK you can't do this with CPFP.
>
> > rational miners may wish to permit multiple sponsor
> > targets, or multiple sponsoring
> > transactions,
>
> I'm not sure if your policy sktech prevents multiple
> 1-Sponsor-to-N-Sponsoree. Such a scheme would have some edges. A mempool
> might receive Sponsoree in different order than evaluated by original
> sender and thus allocate the Sponsor feerate to the less-urgent Sponsoree.
>
> > This is treated as a separate
> > concern, as any strides on
> > package relay generally should be able to support sponsors trivially.
>
> This is one more reason to carefully version package relay, beyond the
> transaction package complexity, you now have a new type of graph dependency
> to scope. What we should be worried about is network mempools partitions
> between different mechanisms of incompatible package relay if we implement
> one.
>
> Overall, a missing point which is making this proposal compelling is the
> fact that you may have one 1-Sponsor-for-N-Sponsoree which is a far reduced
> cost compared to N-Parent-1-CPFP as the CPFP must include an input for each
> bumped parent. Here you only have the Sponsor output. Thus observing
> input_size > output_size, this proposal is better for multi-transactions
> bumping (but not for N=1 as you have to bear the input spending of the
> Sponsor).
>
> Antoine
>
> [0] Within LN-context, for class b) see
> https://lists.linuxfoundation.org/pipermail/lightning-dev/2020-June/002758.html
>
> [1] See the recent Dynamic Commitments proposal to ponder this concern
> https://lists.linuxfoundation.org/pipermail/lightning-dev/2020-July/002763.html
>
> Le ven. 18 sept. 2020 à 20:52, Jeremy via bitcoin-dev <
> bitcoin-dev at lists.linuxfoundation.org> a écrit :
>
>> Hi Bitcoin Devs,
>>
>>
>> I'd like to share with you a draft proposal for a mechanism to replace CPFP and RBF for
>> increasing fees on transactions in the mempool that should be more robust against attacks.
>>
>> A reference implementation demonstrating these rules is available
>> [here](https://github.com/bitcoin/bitcoin/compare/master...JeremyRubin:subsidy-tx) for those who
>> prefer to not read specs.
>>
>> Should the mailing list formatting be bungled, it is also available as a gist [here](https://gist.github.com/JeremyRubin/92a9fc4c6531817f66c2934282e71fdf).
>>
>> Non-Destructive TXID Dependencies for Fee Sponsoring
>> ====================================================
>>
>> This BIP proposes a general purpose mechanism for expressing non-destructive (i.e., not requiring
>> the spending of a coin) dependencies on specific transactions being in the same block that can be
>> used to sponsor fees of remote transactions.
>>
>> Motivation
>> ==========
>>
>> The mempool has a variety of protections and guards in place to ensure that miners are economic and
>> to protect the network from denial of service.
>>
>> The rough surface of these policies has some unintended consequences for second layer protocol
>> developers. Applications are either vulnerable to attacks (such as transaction pinning) or must go
>> through great amounts of careful protocol engineering to guard against known mempool attacks.
>>
>> This is insufficient because if new attacks are found, there is limited ability to deploy fixes for
>> them against deployed contract instances (such as open lightning channels). What is required is a
>> fully abstracted primitive that requires no special structure from an underlying transaction in
>> order to increase fees to confirm the transactions.
>>
>> Consensus Specification
>> =======================
>>
>> If a transaction's last output's scripPubKey is of the form OP_VER followed by n*32 bytes, where
>> n>1, it is interpreted as a vector of TXIDs (Sponsor Vector). The Sponsor Vector TXIDs must also be
>> in the block the transaction is validated in, with no restriction on order or on specifying a TXID
>> more than once. This can be accomplished simply with the following patch:
>>
>>
>> ```diff
>> +
>> + // Extract all required fee dependencies
>> + std::unordered_set<uint256, SaltedTxidHasher> dependencies;
>> +
>> + const bool dependencies_enabled = VersionBitsState(pindex->pprev, chainparams.GetConsensus(), Consensus::DeploymentPos::DEPLOYMENT_TXID_DEPENDENCY, versionbitscache) == ThresholdState::ACTIVE;
>> + if (dependencies_enabled) {
>> + for (const auto& tx : block.vtx) {
>> + // dependency output is if the last output of a txn is OP_VER followed by a sequence of 32*n
>> + // bytes
>> + // vout.back() must exist because it is checked in CheckBlock
>> + const CScript& dependencies_script = tx->vout.back().scriptPubKey;
>> + // empty scripts are valid, so be sure we have at least one byte
>> + if (dependencies_script.size() && dependencies_script[0] == OP_VER) {
>> + const size_t size = dependencies_script.size() - 1;
>> + if (size % 32 == 0 && size > 0) {
>> + for (auto start = dependencies_script.begin() +1, stop = start + 32; start < dependencies_script.end(); start = stop, stop += 32) {
>> + uint256 txid;
>> + std::copy(start, stop, txid.begin());
>> + dependencies.emplace(txid);
>> + }
>> + }
>> + // No rules applied otherwise, open for future upgrades
>> + }
>> + }
>> + if (dependencies.size() > block.vtx.size()) {
>> + return state.Invalid(BlockValidationResult::BLOCK_CONSENSUS, "bad-dependencies-too-many-target-txid");
>> + }
>> + }
>> +
>> for (unsigned int i = 0; i < block.vtx.size(); i++)
>> {
>> const CTransaction &tx = *(block.vtx[i]);
>> + if (!dependencies.empty()) {
>> + dependencies.erase(tx.GetHash());
>> + }
>>
>> nInputs += tx.vin.size();
>>
>> @@ -2190,6 +2308,9 @@ bool CChainState::ConnectBlock(const CBlock& block, BlockValidationState& state,
>> }
>> UpdateCoins(tx, view, i == 0 ? undoDummy : blockundo.vtxundo.back(), pindex->nHeight);
>> }
>> + if (!dependencies.empty()) {
>> + return state.Invalid(BlockValidationResult::BLOCK_CONSENSUS, "bad-dependency-missing-target-txid");
>> + }
>> ```
>>
>> ### Design Motivation
>> The final output of a transaction is an unambiguous location to attach metadata to a transaction
>> such that the data is available for transaction validation. This data could be committed to anywhere,
>> with added implementation complexity, or in the case of Taproot annexes, incompatibility with
>> non-Taproot addresses (although this is not a concern for sponsoring a transaction that does not use
>> Taproot).
>>
>> A bare scriptPubKey prefixed with OP_VER is defined to be invalid in any context, and is trivially
>> provably unspendable and therefore pruneable.
>>
>> If there is another convenient place to put the TXID vector, that's fine too.
>>
>> As the output type is non-standard, unupgraded nodes will by default not include Transactions
>> containing them in the mempool, limiting risk of an upgrade via this mechanism.
>>
>> Policy Specification
>> ====================
>>
>> The mechanism proposed above is a general specification for inter-transaction dependencies.
>>
>> In this BIP, we only care to ensure a subset of behavior sufficient to replace CPFP and RBF for fee
>> bumping.
>>
>> Thus we restrict the mempool policy such that:
>>
>> 1. No Transaction with a Sponsor Vector may have any child spends; and
>> 1. No Transaction with a Sponsor Vector may have any unconfirmed parents; and
>> 1. The Sponsor Vector must have exactly 1 entry; and
>> 1. The Sponsor Vector's entry must be present in the mempool; and
>> 1. Every Transaction may have exactly 1 sponsor in the mempool; except
>> 1. Transactions with a Sponsor Vector may not be sponsored.
>>
>>
>> The mempool treats ancestors and descendants limits as follows:
>>
>> 1. Sponsors are counted as children transactions for descendants; but
>> 1. Sponsoring transactions are exempted from any limits saturated at the time of submission.
>>
>> This ensures that within a given package, every child transaction may have a sponsor, but that the
>> mempool prefers to not accept new true children while there are parents that can be cleared.
>>
>> To prevent garbage sponsors, we also require that:
>>
>> 1. The Sponsor's feerate must be greater than the Sponsored's ancestor fee rate
>>
>> We allow one Sponsor to replace another subject to normal replacement policies, they are treated as
>> conflicts.
>>
>>
>> ### Design Motivation
>>
>> There are a few other ways to use OP_VER sponsors that are not included. For instance, one could
>> make child chains that are only valid if their parent is in the same block (this is incompatible
>> with CTV, exercise left to reader). These use cases are in a sense incidental to the motivation
>> of this mechanism, and add a lot of implementation complexity.
>>
>> What is wanted is a minimal mechanism that allows arbitrary unconnected third parties to attach
>> fees to an arbitrary transaction. The set of rules given tightly bounds how much extra work the
>> mempool might have to do to account for the new sponsors in the worst case, while providing a "it
>> always works" API for end users that is not subject to traditional issues around pinning.
>>
>> Eventually, rational miners may wish to permit multiple sponsor targets, or multiple sponsoring
>> transactions, but they are not required for the mechanism to work. This is a benefit of the
>> minimality of the consensus rule, it is compatible with future policy should it be implemented.
>>
>>
>> #### Attack Analysis of new Policy
>>
>> In the worst case the new policy can lead to a 1/2 reduction in the number of children allowed
>> (e.g., if there are 13 children submitted, then 12 sponsors, the 25 child limit will saturate
>> before) and a 2x increase in the maximum children (e.g., if there are 25 children submitted, and
>> then each are sponsored). Importantly, even in the latter attack scenario, the DoS surface is not
>> great because the sponsor transactions have no children nor parents.
>>
>> #### Package Relay/Orphan Pool
>>
>> Future policy work might be able to insert sponsors into a special sponsor pool with an eviction
>> policy that would enable sponsors to be queried and tracked for transactions that have too low fee
>> to enter the mempool in the first place. This is treated as a separate concern, as any strides on
>> package relay generally should be able to support sponsors trivially.
>>
>> Reference Implementation
>> ========================
>> A reference implementation demonstrating these rules is available
>> [here](https://github.com/bitcoin/bitcoin/compare/master...JeremyRubin:subsidy-tx). This is a best
>> effort implementation, but has not been carefully audited for correctness and likely diverges from
>> this document in ways that should either be reflected in this document or amended in the code.
>>
>>
>> Best,
>>
>> Jeremy
>>
>>
>>
>> --
>> @JeremyRubin <https://twitter.com/JeremyRubin>;
>> <https://twitter.com/JeremyRubin>;
>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-dev at lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20200919/7b4110fb/attachment-0001.html>;

📅 Original date posted:2020-09-19 📝 Original message:Hi ...

2023-06-07T20:26:55+02:00

In reply to nevent1q…h4eq
_________________________

📅 Original date posted:2020-09-19
📝 Original message:Hi Jeremy,

This is a really interesting proposal to widen the scope of fee mechanisms.

First, a wider point on what this proposal brings with regards to pinning,
to the best of my knowledge.

A pinning may have different vectors by exploiting a) mempools limits (e.g
descendants) or b) mempools absolute-fee/feerate/conflicts logic. The lack
of a global mempool means you can creatively combine them to provoke
mempools-partitions [0]

As far as I understand this proposal, it aims to solve the class a) of
pinnings by allowing fee-bumping with a new definition of dependencies. I'm
not sure it achieves to do so as the Sponsor Vector TXIDs being committed
in the Sponsoree signature hash means the Sponsor feerate is part of this
commitment and can't be unilaterally adjusted to actual mempool-congestion.

After broadcasting the Sponsor/Sponsoree pair, mempools feerate may
increase again and thus obsoleting the previous fee-bump. Or you need a
Sponsor Vector for every blockspace feerate, in the worst-case bound by the
value of the Sponsoree funds.

Further, I would say this proposal won't solve class b) of pinnings for
multi-party time-sensitive protocols without further modifications. E.g in
a LN-channel, assuming the commitment transaction is the Sponsoree, Alice
the honest party can't increase Sponsor feerate by mal eating its outputs
without breaking the sponsoring dependency. And thus evict a Bob's
malicious pin across network mempools.

I think a further softfork proposal with regards to sighash malleability is
needed to achieve the security semantic for Lightning type of protocols.
Roughly, a SIGHASH_IOVECTOR allows N-inputs to commit to N-outputs, thus
committing to all the balance/HTLC outputs minus the last output Vector,
non-interactively malleable by channel participants. This would be a form
of transaction finalization delegation, allowing Alice to direct the
Sponsor vector to a good-feerate adjusted transaction.

Note, I may have misunderstood completely the proposal as the feerate
observed might be the Sponsor _package_ one and each party could have a
pair of outputs to spend from to non-interactively increase the Sponsoree.
Though sounds like re-introducing the limits issues...

That said, see following review points.

> This is insufficient because if new attacks are found, there is
> limited ability to deploy fixes for
> them against deployed contract instances (such as open lightning
> channels). What is required is a
> fully abstracted primitive that requires no special structure from an
> underlying transaction in
> order to increase fees to confirm the transactions.

This is really true, in case of vulnerability discovered mass closing of
the channel would be in itself a concern as it would congest mempools and
open to looter behaviors [1]. Though I don't think a special structure can
claim covering every potential source of vulnerability for off-chain
protocols as some of them might be tx-relay based (e.g reject-filters for
segwit txn).

Further, a "fully abstracted primitive" is loosely defined, one could argue
that anchor outputs don't require special structure from an underlying
transaction (i.e on the order of outputs ?).

> where
n>1, it is interpreted as a vector of TXIDs (Sponsor Vector).

n >=1 ? I think you can have at least one vector and this is matching the
code

> If there is another convenient place to put the TXID vector, that's fine
too.

You might use the per-input future Taproot annex, and even apply a witness
discount as this mechanism could be argued to be less blockspace expensive
than a CPFP for the same semantic.

An alternative could be a new transaction field like a new `stxid` :

`[nVersion][marker][flag][txins][txouts][witness][nLockTime][nSponsor][nVersion][n*STXID]`

It would be cheaper as you likely save the output amount size and OP_VER.
And you don't have to subtract a dust output + 1 from the other output
amount to make sure the Sponsor output meets dust propagation requirements.

Though it's more demanding on the tx-relay layer (new serialization and
transaction identifier) and new a version bump of the signature digest algo
to avoid a third-party malleating the per-transaction sponsor field

> To prevent garbage sponsors, we also require that:

Does the reverse hold ? Garbage Sponsoree by breaking the dependency and
double-spending the utxo spent by the Sponsor and thus decreasing
Sponsoree's feerate to mempool bottom. AFAIK you can't do this with CPFP.

> rational miners may wish to permit multiple sponsor
> targets, or multiple sponsoring
> transactions,

I'm not sure if your policy sktech prevents multiple
1-Sponsor-to-N-Sponsoree. Such a scheme would have some edges. A mempool
might receive Sponsoree in different order than evaluated by original
sender and thus allocate the Sponsor feerate to the less-urgent Sponsoree.

> This is treated as a separate
> concern, as any strides on
> package relay generally should be able to support sponsors trivially.

This is one more reason to carefully version package relay, beyond the
transaction package complexity, you now have a new type of graph dependency
to scope. What we should be worried about is network mempools partitions
between different mechanisms of incompatible package relay if we implement
one.

Overall, a missing point which is making this proposal compelling is the
fact that you may have one 1-Sponsor-for-N-Sponsoree which is a far reduced
cost compared to N-Parent-1-CPFP as the CPFP must include an input for each
bumped parent. Here you only have the Sponsor output. Thus observing
input_size > output_size, this proposal is better for multi-transactions
bumping (but not for N=1 as you have to bear the input spending of the
Sponsor).

Antoine

[0] Within LN-context, for class b) see
https://lists.linuxfoundation.org/pipermail/lightning-dev/2020-June/002758.html

[1] See the recent Dynamic Commitments proposal to ponder this concern
https://lists.linuxfoundation.org/pipermail/lightning-dev/2020-July/002763.html

Le ven. 18 sept. 2020 à 20:52, Jeremy via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> a écrit :

> Hi Bitcoin Devs,
>
>
> I'd like to share with you a draft proposal for a mechanism to replace CPFP and RBF for
> increasing fees on transactions in the mempool that should be more robust against attacks.
>
> A reference implementation demonstrating these rules is available
> [here](https://github.com/bitcoin/bitcoin/compare/master...JeremyRubin:subsidy-tx) for those who
> prefer to not read specs.
>
> Should the mailing list formatting be bungled, it is also available as a gist [here](https://gist.github.com/JeremyRubin/92a9fc4c6531817f66c2934282e71fdf).
>
> Non-Destructive TXID Dependencies for Fee Sponsoring
> ====================================================
>
> This BIP proposes a general purpose mechanism for expressing non-destructive (i.e., not requiring
> the spending of a coin) dependencies on specific transactions being in the same block that can be
> used to sponsor fees of remote transactions.
>
> Motivation
> ==========
>
> The mempool has a variety of protections and guards in place to ensure that miners are economic and
> to protect the network from denial of service.
>
> The rough surface of these policies has some unintended consequences for second layer protocol
> developers. Applications are either vulnerable to attacks (such as transaction pinning) or must go
> through great amounts of careful protocol engineering to guard against known mempool attacks.
>
> This is insufficient because if new attacks are found, there is limited ability to deploy fixes for
> them against deployed contract instances (such as open lightning channels). What is required is a
> fully abstracted primitive that requires no special structure from an underlying transaction in
> order to increase fees to confirm the transactions.
>
> Consensus Specification
> =======================
>
> If a transaction's last output's scripPubKey is of the form OP_VER followed by n*32 bytes, where
> n>1, it is interpreted as a vector of TXIDs (Sponsor Vector). The Sponsor Vector TXIDs must also be
> in the block the transaction is validated in, with no restriction on order or on specifying a TXID
> more than once. This can be accomplished simply with the following patch:
>
>
> ```diff
> +
> + // Extract all required fee dependencies
> + std::unordered_set<uint256, SaltedTxidHasher> dependencies;
> +
> + const bool dependencies_enabled = VersionBitsState(pindex->pprev, chainparams.GetConsensus(), Consensus::DeploymentPos::DEPLOYMENT_TXID_DEPENDENCY, versionbitscache) == ThresholdState::ACTIVE;
> + if (dependencies_enabled) {
> + for (const auto& tx : block.vtx) {
> + // dependency output is if the last output of a txn is OP_VER followed by a sequence of 32*n
> + // bytes
> + // vout.back() must exist because it is checked in CheckBlock
> + const CScript& dependencies_script = tx->vout.back().scriptPubKey;
> + // empty scripts are valid, so be sure we have at least one byte
> + if (dependencies_script.size() && dependencies_script[0] == OP_VER) {
> + const size_t size = dependencies_script.size() - 1;
> + if (size % 32 == 0 && size > 0) {
> + for (auto start = dependencies_script.begin() +1, stop = start + 32; start < dependencies_script.end(); start = stop, stop += 32) {
> + uint256 txid;
> + std::copy(start, stop, txid.begin());
> + dependencies.emplace(txid);
> + }
> + }
> + // No rules applied otherwise, open for future upgrades
> + }
> + }
> + if (dependencies.size() > block.vtx.size()) {
> + return state.Invalid(BlockValidationResult::BLOCK_CONSENSUS, "bad-dependencies-too-many-target-txid");
> + }
> + }
> +
> for (unsigned int i = 0; i < block.vtx.size(); i++)
> {
> const CTransaction &tx = *(block.vtx[i]);
> + if (!dependencies.empty()) {
> + dependencies.erase(tx.GetHash());
> + }
>
> nInputs += tx.vin.size();
>
> @@ -2190,6 +2308,9 @@ bool CChainState::ConnectBlock(const CBlock& block, BlockValidationState& state,
> }
> UpdateCoins(tx, view, i == 0 ? undoDummy : blockundo.vtxundo.back(), pindex->nHeight);
> }
> + if (!dependencies.empty()) {
> + return state.Invalid(BlockValidationResult::BLOCK_CONSENSUS, "bad-dependency-missing-target-txid");
> + }
> ```
>
> ### Design Motivation
> The final output of a transaction is an unambiguous location to attach metadata to a transaction
> such that the data is available for transaction validation. This data could be committed to anywhere,
> with added implementation complexity, or in the case of Taproot annexes, incompatibility with
> non-Taproot addresses (although this is not a concern for sponsoring a transaction that does not use
> Taproot).
>
> A bare scriptPubKey prefixed with OP_VER is defined to be invalid in any context, and is trivially
> provably unspendable and therefore pruneable.
>
> If there is another convenient place to put the TXID vector, that's fine too.
>
> As the output type is non-standard, unupgraded nodes will by default not include Transactions
> containing them in the mempool, limiting risk of an upgrade via this mechanism.
>
> Policy Specification
> ====================
>
> The mechanism proposed above is a general specification for inter-transaction dependencies.
>
> In this BIP, we only care to ensure a subset of behavior sufficient to replace CPFP and RBF for fee
> bumping.
>
> Thus we restrict the mempool policy such that:
>
> 1. No Transaction with a Sponsor Vector may have any child spends; and
> 1. No Transaction with a Sponsor Vector may have any unconfirmed parents; and
> 1. The Sponsor Vector must have exactly 1 entry; and
> 1. The Sponsor Vector's entry must be present in the mempool; and
> 1. Every Transaction may have exactly 1 sponsor in the mempool; except
> 1. Transactions with a Sponsor Vector may not be sponsored.
>
>
> The mempool treats ancestors and descendants limits as follows:
>
> 1. Sponsors are counted as children transactions for descendants; but
> 1. Sponsoring transactions are exempted from any limits saturated at the time of submission.
>
> This ensures that within a given package, every child transaction may have a sponsor, but that the
> mempool prefers to not accept new true children while there are parents that can be cleared.
>
> To prevent garbage sponsors, we also require that:
>
> 1. The Sponsor's feerate must be greater than the Sponsored's ancestor fee rate
>
> We allow one Sponsor to replace another subject to normal replacement policies, they are treated as
> conflicts.
>
>
> ### Design Motivation
>
> There are a few other ways to use OP_VER sponsors that are not included. For instance, one could
> make child chains that are only valid if their parent is in the same block (this is incompatible
> with CTV, exercise left to reader). These use cases are in a sense incidental to the motivation
> of this mechanism, and add a lot of implementation complexity.
>
> What is wanted is a minimal mechanism that allows arbitrary unconnected third parties to attach
> fees to an arbitrary transaction. The set of rules given tightly bounds how much extra work the
> mempool might have to do to account for the new sponsors in the worst case, while providing a "it
> always works" API for end users that is not subject to traditional issues around pinning.
>
> Eventually, rational miners may wish to permit multiple sponsor targets, or multiple sponsoring
> transactions, but they are not required for the mechanism to work. This is a benefit of the
> minimality of the consensus rule, it is compatible with future policy should it be implemented.
>
>
> #### Attack Analysis of new Policy
>
> In the worst case the new policy can lead to a 1/2 reduction in the number of children allowed
> (e.g., if there are 13 children submitted, then 12 sponsors, the 25 child limit will saturate
> before) and a 2x increase in the maximum children (e.g., if there are 25 children submitted, and
> then each are sponsored). Importantly, even in the latter attack scenario, the DoS surface is not
> great because the sponsor transactions have no children nor parents.
>
> #### Package Relay/Orphan Pool
>
> Future policy work might be able to insert sponsors into a special sponsor pool with an eviction
> policy that would enable sponsors to be queried and tracked for transactions that have too low fee
> to enter the mempool in the first place. This is treated as a separate concern, as any strides on
> package relay generally should be able to support sponsors trivially.
>
> Reference Implementation
> ========================
> A reference implementation demonstrating these rules is available
> [here](https://github.com/bitcoin/bitcoin/compare/master...JeremyRubin:subsidy-tx). This is a best
> effort implementation, but has not been carefully audited for correctness and likely diverges from
> this document in ways that should either be reflected in this document or amended in the code.
>
>
> Best,
>
> Jeremy
>
>
>
> --
> @JeremyRubin <https://twitter.com/JeremyRubin>;
> <https://twitter.com/JeremyRubin>;
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20200919/6e143592/attachment-0001.html>;

📅 Original date posted:2020-06-07 📝 Original message:Hi ...

2023-06-07T20:25:12+02:00

In reply to nevent1q…wamm
_________________________

📅 Original date posted:2020-06-07
📝 Original message:Hi ZmnSCPxj,

> (Of note as well, is that the onchain contract provided by such services
is the same in spirit as those instantiated in channels of the Lightning
Network, thus the same attack schema works on the onchain side.)

If you onchain contract uses a timelock and has concurrent transactions
arbiter by this one , it's subject to time-dilation attack. So yes
submarine swaps, or any kind of atomic swap is concerned. We note this in
discussion.
But you're right for the attack cost, you don't need a channel to these
services, which is also concerning for their attack surface.

> Since the issue here is that eclipsing of Bitcoin nodes is risky, it
strikes me that a mitigation would be to run your Bitcoin fullnode on
clearnet while running your Lightning node over Tor

We clearly mention that risk of running a Bitcoin node over Tor, where do
we recommend running a LN node over Tor ?

> And this seems to tie with what you propose: that the LN node should
use a different view-fullnode from the broadcast-fullnode.

Yes in Countermeasures - Link layer diversity, specially if it's easy for
an attacker to provoke a transaction broadcast by buying a channel to the
LN node.

> A mitigation to this would be to run a background process which sleeps
for 20 minutes, then does `bitcoin-cli addnode ${BITCOINNODE} onetry`.

Yeah instead of having every node operator running their own hacky scripts,
without them being bulletproofs on detection, I'm working on getting such
mitigations directly in Core, easily deployable for everyone.

> The victim *could* instead check that the absolute timelocks seem very
far in the future relative to its own view of the current blockheight.

I think you're right it's really dependent on CLTV_delta deployed on the
path and time-dilation offset. The alternative you're proposing is a good
one, but you shouldn't know where you're in the path and max CLTV is 2048
blocks IIRC.

Thanks for your reading and review,

Cheers,
Antoine

Le mer. 3 juin 2020 à 22:58, ZmnSCPxj via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> a écrit :

> Good morning Gleb and Antoine,
>
> This is good research, thank you for your work.
>
> > **Targeting Per-Hop Packet Delay** is based on routing via the victim,
> and the victim should have at least two channels with the attacker.
>
> The existence of offchain-to-onchain swap services means that the attacker
> needs only build one channel to the victim for this attack to work.
> Rather than route to themselves, the attacker routes to a convenient
> service providing such a swap service, and receives the stolen funds
> onchain, with no need even for an incoming channel from a different node.
> (Of note as well, is that the onchain contract provided by such services
> is the same in spirit as those instantiated in channels of the Lightning
> Network, thus the same attack schema works on the onchain side.)
>
> Indeed, the attack can be mounted on such a service directly.
>
> Even without such a service, the incoming channel need not be directly
> connected to the victim.
>
>
> > [Tor is tricky](https://arxiv.org/abs/1410.6079) too
>
> Since the issue here is that eclipsing of Bitcoin nodes is risky, it
> strikes me that a mitigation would be to run your Bitcoin fullnode on
> clearnet while running your Lightning node over Tor.
> Eclipsing the Lightning node (but not the Bitcoin fullnode it depends on)
> "only" loses you the ability to pay, receive, or route (and thereby earn
> forwarding fees), but as long as your blockchain view is clear, it should
> be fine.
>
> Of course, the Lightning node could still be correlated with the Bitcoin
> node when transactions are broadcast with the attached Bitcoin node (as
> noted in the paper).
> Instead the Lightning node should probably connect, over Tor, to some
> random Bitcoin fullnodes / Electrum servers and broadcast txes to them.
>
> And this seems to tie with what you propose: that the LN node should use a
> different view-fullnode from the broadcast-fullnode.
>
>
> > if a node doesn’t observe a block within the last 30 minutes, it
> attempts to make a new random connection to someone in the network.
>
> A mitigation to this would be to run a background process which sleeps for
> 20 minutes, then does `bitcoin-cli addnode ${BITCOINNODE} onetry`.
> It might want to `disconnectnode` any previous node it attempted to
> connect to.
>
> However I note that the help for `addnode` contains the text "though such
> peers will not be synced from", which confuses me, since it also refers to
> the `-connect` command line option, and `-connect` means you only connect
> out to the specific nodes, so if those are not synced from.... huh?
>
> And of course the interesting part is "how do we get a `${BITCOINNODE}`
> that we think is not part of the eclipsing attacker?"
>
>
> > If a Lightning node is behind in its Bitcoin blockchain view, but
> Lightning payments between honest nodes are still flowing through it, this
> node will have a high routing failure rate. This would happen because
> honest nodes on the routing path would reject the forwarded HTLC for being
> too close to expired.
>
> I am uncertain this would happen very often.
> In the first place, the incoming HTLC would have "reasonable" timeouts, or
> else the incoming honest node would not have routed it at all, and the
> outgoing HTLC would be relative to this incoming one, so the outgoing
> honest node will still accept this.
>
> The victim *could* instead check that the absolute timelocks seem very far
> in the future relative to its own view of the current blockheight.
> (a forwarding node miht want to do that anyway to have an upper bound
> against griefing attacks)
>
> What would definitely increase in failure rate would be payments arising
> from the victim node; the victim node believes the blockheight to be much
> lower than it actually is, and either the payee node, or some intermediate
> node along the route, will claim to have too little time to safely forward
> the funds.
> This does not help for nodes which are primarily forwarding nodes.
>
>
>
> Regards,
> ZmnSCPxj
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20200607/45de6e7a/attachment.html>;