Antoine Riard [ARCHIVE]

⚠️ This account is not associated with a real person. It's an archival account for mailing list messages.
🗓️ Active from 2019-07-13 to 2023-06-07
💬 Posted a total of 269 messages
📚 Participated in the following categories: bitcoin-dev, Lightning-dev, Opt-in full-RBF, DRAFT
🔇 Please do not DM this user as it's used for archive purposes only.

Public Key

npub1vjzmc45k8dgujppapp2ue20h3l9apnsntgv4c0ukncvv549q64gsz4x8dd

Profile Code

nprofile1qqsxfpdu26trk5wfqs7ss4wv48mclj7secf45x2u87tfuxx22jsd25gl5vm8q

Author Public Key

npub1vjzmc45k8dgujppapp2ue20h3l9apnsntgv4c0ukncvv549q64gsz4x8dd

Show more details

Last Notes

2023-10-18 13:02:10

- reply

📅 Original date posted:2023-10-17
🗒️ Summary of this message: Enabling lightning withdrawals from exchanges to user wallets efficiently requires the use of covenants. Batching multiple transactions into one is a possible solution, but it requires signatures from multiple users.
📝 Original message:
Hi Bastien,
> The naive way of enabling lightning withdrawals is to make the user
> provide a lightning invoice that the exchange pays over lightning. The
> issue is that in most cases, this simply shifts the burden of making an
> on-chain transaction to the user's wallet provider: if the user doesn't
> have enough inbound liquidity (which is likely), a splice transaction
> will be necessary. If N users withdraw funds from an exchange, we most
> likely will end up with N separate splice transactions.
It is uncertain to me if secure fee-bumping, even with future mechanisms
like package relay and nversion=3, is robust enough for multi-party
transactions and covenant-enable constructions under usual risk models.
See test here:
https://github.com/ariard/bitcoin/commit/19d61fa8cf22a5050b51c4005603f43d72f1efcf
Appreciated expert eyes of folks understanding both lightning and core
mempool on this.
There was a lot of back and forth on nversion=3 design rules, though the
test is normally built on glozow top commit of the 3 Oct 2023.
Best,
Antoine
Le mar. 17 oct. 2023 à 14:03, Bastien TEINTURIER <bastien at acinq.fr> a
écrit :
> Good morning list,
>
> I've been trying to design a protocol to let users withdraw funds from
> exchanges directly into their lightning wallet in an efficient way
> (with the smallest on-chain footprint possible).
>
> I've come to the conclusion that this is only possible with some form of
> covenants (e.g. `SIGHASH_ANYPREVOUT` would work fine in this case). The
> goal of this post is to explain why, and add this usecase to the list of
> useful things we could do if we had covenants (insert "wen APO?" meme).
>
> The naive way of enabling lightning withdrawals is to make the user
> provide a lightning invoice that the exchange pays over lightning. The
> issue is that in most cases, this simply shifts the burden of making an
> on-chain transaction to the user's wallet provider: if the user doesn't
> have enough inbound liquidity (which is likely), a splice transaction
> will be necessary. If N users withdraw funds from an exchange, we most
> likely will end up with N separate splice transactions.
>
> Hence the idea of batching those into a single transaction. Since we
> don't want to introduce any intermediate transaction, we must be able
> to create one transaction that splices multiple channels at once. The
> issue is that for each of these channels, we need a signature from the
> corresponding wallet user, because we're spending the current funding
> output, which is a 2-of-2 multisig between the wallet user and the
> wallet provider. So we run into the usual availability problem: we need
> signatures from N users who may not be online at the same time, and if
> one of those users never comes online or doesn't complete the protocol,
> we must discard the whole batch.
>
> There is a workaround though: each wallet user can provide a signature
> using `SIGHASH_SINGLE | SIGHASH_ANYONECANPAY` that spends their current
> funding output to create a new funding output with the expected amount.
> This lets users sign *before* knowing the final transaction, which the
> exchange can create by batching pairs of inputs/outputs. But this has
> a fatal issue: at that point the wallet user has no way of spending the
> new funding output (since it is also a 2-of-2 between the wallet user
> and the wallet provider). The wallet provider can now blackmail the user
> and force them to pay to get their funds back.
>
> Lightning normally fixes this by exchanging signatures for a commitment
> transaction that sends the funds back to their owners *before* signing
> the parent funding/splice transaction. But here that is impossible,
> because we don't know yet the `txid` of the batch transaction (that's
> the whole point, we want to be able to sign before creating the batch)
> so we don't know the new `prevout` we should spend from. I couldn't find
> a clever way to work around that, and I don't think there is one (but
> I would be happy to be wrong).
>
> With `SIGHASH_ANYPREVOUT`, this is immediately fixed: we can exchange
> anyprevout signatures for the commitment transaction, and they will be
> valid to spend from the batch transaction. We are safe from signature
> reuse, because funding keys are rotated at each splice so we will never
> create another output that uses the same 2-of-2 script.
>
> I haven't looked at other forms of covenants, but most of them likely
> address this problem as well.
>
> Cheers,
> 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/20231017/65951f73/attachment-0001.html>

2023-10-18 13:02:09

- reply

📅 Original date posted:2023-10-17
🗒️ Summary of this message: The disclosed mitigations for lightning attacks include mempool scanning, transaction re-signing/re-broadcasting, and bumping CLTV delta. However, these mitigations may not be effective in fixing the issue. Additional measures such as stratum v2 deployment and a replacement buffer at the mempool level may make the attack harder. The issue of fees is also a challenge.
📝 Original message:
The disclosure mails noted a 3rd mitigation beyond mempool scanning and
transaction re-signing / re-broadcasting, namely bumping CLTV delta.
Generally bumping CLTV delta is a basic line of mitigations for a lot of
lightning attacks, as it gives opportunity to node operators to intervene
and re-broadcast their time-sensitive transactions on other interfaces (e.g
a secondary full-node if the first one is eclipsed).
About the second mitigation transaction re-signing, if done correctly at
least sounds to put an economic cost (denominated in fees / feerates) on
the attack. This is unclear to me if the game-theory of this cost holds.
One thing which sounds to me making the attack harder is stratum v2
deployment, as you're increasing the number of miners which might do their
own block templates, and therefore the number of miners' mempools where an
attacker has to successfully continuously replace in cycles channels
counterparties transactions.
A replacement buffer or history of transactions at the mempool level might
be a mitigation to this attack. I believe this is yet to be seen if it can
be made robust enough.
I don't know if folks like tadge or rusty who have been involved in the
early design of lightning have more ideas of mitigations. Fees was noted as
a hard issue in the original paper.
Le mer. 18 oct. 2023 à 01:17, Matt Corallo <lf-lists at mattcorallo.com> a
écrit :
> There appears to be some confusion about this issue and the mitigations.
> To be clear, the deployed
> mitigations are not expected to fix this issue, its arguable if they
> provide anything more than a PR
> statement.
>
> There are two discussed mitigations here - mempool scanning and
> transaction re-signing/re-broadcasting.
>
> Mempool scanning relies on regularly checking the mempool of a local node
> to see if we can catch the
> replacement cycle mid-cycle. It only works if wee see the first
> transaction before the second
> transaction replaces it.
>
> Today, a large majority of lightning nodes run on machines with a Bitcoin
> node on the same IP
> address, making it very clear what the "local node" of the lightning node
> is. An attacker can
> trivially use this information to connect to said local node and do the
> replacement quickly,
> preventing the victim from seeing the replacement.
>
> More generally, however, similar discoverability is true for mining pools.
> An attacker performing
> this attack is likely to do the replacement attack on a miner's node
> directly, potentially reducing
> the reach of the intermediate transaction to only miners, such that the
> victim can never discover it
> at all.
>
> The second mitigation is similarly pathetic. Re-signing and
> re-broadcasting the victim's transaction
> in an attempt to get it to miners even if its been removed may work, if
> the attacker is super lazy
> and didn't finish writing their attack system. If the attacker is
> connected to a large majority of
> hashrate (which has historically been fairly doable), they can simply do
> their replacement in a
> cycle aggressively and arbitrarily reduce the probability that the
> victim's transaction gets confirmed.
>
> Now, the above is all true in a spherical cow kinda world, and the P2P
> network has plenty of slow
> nodes and strange behavior. Its possible that these mitigations might, by
> some stroke of luck,
> happen to catch such an attack and prevent it, because something took
> longer than the attacker
> intended or whatever. But, that's a far cry from any kind of material
> "fix" for the issue.
>
> Ultimately the only fix for this issue will be when miners keep a history
> of transactions they've
> seen and try them again after they may be able to enter the mempool
> because of an attack like this.
>
> Matt
>
> On 10/16/23 12:57 PM, Antoine Riard 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
> > <
> 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
> > <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
> > <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 <mailto: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.
> >
> > _______________________________________________
> > 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/20231018/dfcf4d45/attachment-0001.html>

2023-10-18 13:02:09

- reply

📅 Original date posted:2023-10-17
🗒️ Summary of this message: No experiments have been conducted yet due to limited experts and other pending security issues.
📝 Original message:
> We have conducted one so far, multiple scenarios to look at.
_*none*_ so far. typo of mine - apologize english is not my native language.
We discussed conducting experiments pre-disclosure in an e-mail of the 11th
August 2023.
"If someone is down to setup a "black box" Lightning infra on mainet, I'm
game on to exercise the vulnerabilities and mitigations during the coming
months and revisit the disclosure date dependent on the learnings."
However as the number of Lightning worldwide experts who have level of
knowledge and understandings to take part to experiments is I think
restrained to people listed on the disclosure mails _and_ we had other
pendings non-disclosed security issues at the time like the ones revealed
"fake channel DoS vector" the 23th August 2023, we didn't conduct them.
Le mar. 17 oct. 2023 à 18:47, Antoine Riard <antoine.riard at gmail.com> a
écrit :
> 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/36ea4307/attachment-0001.html>

2023-10-18 13:02:08

- reply

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

2023-10-18 13:02:08

- reply

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

2023-10-18 13:02:08

- reply

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

2023-10-03 21:44:19

- reply

📅 Original date posted:2023-09-26
🗒️ Summary of this message: OP_EVICT requires participant cooperation for a single participant to withdraw funds, which may not be safe. TLUV or MERKLESUB offer more flexibility. No sound covenant proposal combines TLUV and EVICT-like semantics. The best direction to solve interactivity issues is still uncertain.
📝 Original message:
Hi Zeeman,
See my comments at the time of OP_EVICT original publication.
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-February/019939.html
"I think in the context of (off-chain) payment pool, OP_EVICT requires
participant cooperation *after* the state update to allow a single
participant to withdraw her funds.
I believe this is unsafe if we retain as an off-chain construction security
requirement that a participant should have the unilateral means to enforce
the latest agreed upon state at any time during the construction lifetime".
I think this level of covenant flexibility is still wished for CoinPool as
a fundamental property, and this is offered by TLUV or MERKLESUB.
On the other hand, I think OP_EVICT introduces this idea of *subgroup
novation* (i.e `K-of-N`) of a PT2R scriptpubkey.
To the best of my understanding, I think there is not yet any sound
covenant proposal aiming to combine TLUV and EVICT-like semantics in a
consistent set of Script primitives to enable "cut-through" updates, while
still retaining the key property of unilateral withdraw of promised
balances in any-order.
I might go to work on crafting one, though for now I'm still interested to
understand better if on-chain "cut-through" is the best direction to solve
the fundamental high interactivity issue of channel factory and payment
pool over punishment-based ideas.
Best,
Antoine
Le mar. 26 sept. 2023 à 07:51, ZmnSCPxj <ZmnSCPxj at protonmail.com> a écrit :
> Good morning Antoine,
>
> Does `OP_EVICT` not fit?
>
>
> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-February/019926.html
>
> Regards,
> ZmnSCPxj
>
>
> Sent with Proton Mail secure email.
>
> ------- Original Message -------
> On Monday, September 25th, 2023 at 6:18 PM, Antoine Riard via bitcoin-dev <
> bitcoin-dev at lists.linuxfoundation.org> wrote:
>
>
> > 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/20230926/8231a2e7/attachment.html>

2023-10-03 21:44:18

- reply

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

2023-08-24 10:07:37

- reply

📅 Original date posted:2023-08-22
🗒️ Summary of this message: Algeria is not recommended as a tourist destination due to high violence and fundamentalist beliefs. Visas are also difficult to obtain.
📝 Original message:
Hi Peter,
> It's an high-violence Islamic country where much of the population has
> fundamentalist beliefs, and it does not have a significant tourism
industry.
> Visiting as a solo female is a sketchy thing to do.
Oran and Algier good districts are deemed safe for tourism by US travel
advisory iirc.
I don't know if the rate of high-violence in those areas is worse than
SF/NYC if you lose yourself in the wrong area.
About the first sentence "It's an high-violence Islamic country where much
of the population has fundamentalist beliefs".
Sadly, I could apply the statement to France, I was out in Paris the night
of the Bataclan terrorist attacks and not far enough in my taste from one
of the shooting places.
Usually when you travel abroad follow the general thumb rules, don't go in
dirty places, stay in a group, maintain situational awareness and take
precautionary measures ahead.
> Visa's are really annoying to deal with. They aren't always granted, and
tend
> to require the applicant to pre-arrange travel (incurring expenses) well
in
> advance of the conference.
I'm fully aware visas are really annoying to deal with and this is one of
the main reasons for working on the organization of an event on the africa
continent a year ahead.
If you want to start to lobby e-visas programs around the world to replace
paperwork applications with zkp-based bitcoin fidelity bonds for faster
visa processing times, please do so :)
Best,
Antoine
Le lun. 21 août 2023 à 12:07, Peter Todd <pete at petertodd.org> a écrit :
> On Sat, Aug 19, 2023 at 12:02:39AM +0100, Antoine Riard wrote:
> > As a backup plan, I think we could consider countries like Morocco or
> > Algeria, which given current composition of the organization committee is
> > straightforward due to the french-speaking communities, or South Africa,
> > which is itself beautiful and where they're doing Bitcoin events [1],
> > though this latter is very far far away in term of international travel
> > logistic.
>
> I asked a native Algeria friend of mine what she thought about holding a
> conference in Algeria:
>
> No. No. No. no
> No conference in Algeria
> It's not a tourist friendly destination!!
>
> It's an high-violence Islamic country where much of the population has
> fundamentalist beliefs, and it does not have a significant tourism
> industry.
> Visiting as a solo female is a sketchy thing to do.
>
> > Note for Ghana, from a quick look it sounds like a visa will be required
> > for all Schengen, US and Commonwealth passport holders will need a travel
> > visa. ECOWAS passport holders sound to be exempted.
>
> Visa's are really annoying to deal with. They aren't always granted, and
> tend
> to require the applicant to pre-arrange travel (incurring expenses) well in
> advance of the conference. I would rule out anywhere with non-trivial visa
> requirements for the super-majority of attendees.
>
> --
> https://petertodd.org 'peter'[:-1]@petertodd.org
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20230822/a743a006/attachment.html>

2023-08-21 09:55:29

- reply

📅 Original date posted:2023-08-18
🗒️ Summary of this message: The author discusses the differences between oracles and miners in terms of game theory and utility functions. They also mention the lack of a complete security model for "DLC-like" oracles and the risks associated with cross-UTXO covenant inspection. The author emphasizes the need for world-class standards in software engineering R&D for the Bitcoin ecosystem.
📝 Original message:
Hi Symphonic,
>From a game-theory viewpoint where we define among other players utility
functions, set of moves, rules of the games and pattern of information, I
don't think oracles can be mathematically reduced to miners.
Miners are competing to generate a proof-of-work on a set of transactions.
This proof-of-work requires hashrate capabilities investment and censoring
LN time-sensitive transactions impacting their marginal gains in the mining
competitions to sustain the investment renewment in their mining chips.
On the other hand, anyone can show as a proof-of-real-world-state oracle,
without mining investment. They will take a while to build a reputation as
a UTXO state oracle and even in case of wrongdoing, laziness is hard to
prove [0].
To the best of my knowledge, there is no complete and practical security
model for "DLC-like" oracles, as such it's hard to have the epistemological
discussion on which assumptions should be regarded as valid or excluded
from the formalization.
As a note the CLTV-timelock matter for LN-like protocol, beyond CSV and
here you start to have interactions with timewarp inflation attacks, which
is still not fixed as a consensus-level vulnerability [1].
I think my previous statement that the addition of cross-UTXO covenant
inspection raises risks in the lack of further R&D on the security model
and the game-theory of Bitcoin is still correct. While a risk zero is not
an intellectual mirage, at the very least when we're talking about the
consensus rules of a $500 B ecosystem, we should bind to world-class
standards of software engineering R&D. And as the ecosystem grows, I think
we should aim to match best practices in aircraft software design or
nuclear reactors.
Best,
Antoine
[0] https://github.com/discreetlogcontracts/dlcspecs/pull/152
[1]
https://github.com/TheBlueMatt/bips/blob/cleanup-softfork/bip-XXXX.mediawiki
Le lun. 14 août 2023 à 15:07, symphonicbtc <symphonicbtc at proton.me> a
écrit :
> > 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
>
> Hi Antoine,
>
> These two papers make a lot of incorrect assumptions about bitcoins
> security model. The assumption of the existence of constructs such as
> oracles or altchains for “trustless” out-of-band payments opens the door
> for plenty of things that in reality are not possible without sacrificing
> security. The assumption that these constructs “minimize” miner / attacker
> trust is no better than assuming the existence of an oracle that can simply
> perform the entire attack.
>
> Moreover, even the limited examples of attacks that do not use these
> constructs completely overlook the fact that bitcoins security model is
> dependent on the preservation of the nash equilibrium between miners. Not
> only is it disincentivized for miners to engage in any form of censorship,
> because they can all be fired by node-runners at any time, it is also not
> in miners interests to reorg the chain if say an anonymous miner mines some
> transactions that were being censored. Sustained, successful censorship in
> any capacity assumes that bitcoin is compromised, a 51% attack has
> occurred, and necessitates a change in PoW algorithm. A sufficient CSV in
> LN-like protocols is always sufficient to avoid being attacked in this way.
>
> The addition of most forms of covenant does not assist any of these
> attacks afaict because they already make assumptions rendering them invalid.
>
>
> Symphonic
>
> ------- Original Message -------
> On Monday, August 14th, 2023 at 3:00 AM, Antoine Riard via bitcoin-dev <
> bitcoin-dev at lists.linuxfoundation.org> wrote:
>
>
> > 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/20230818/f1e1fc18/attachment-0001.html>

2023-08-16 00:45:52

- reply

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

2023-08-06 23:37:36

- reply

📅 Original date posted:2023-08-06
🗒️ Summary of this message: The text discusses the Ark proposal, which involves three entities: the sender, receiver, and ASP. It explains the different types of transactions involved and highlights a potential weakness in the vTXLO transfer phase. The weakness allows the sender and receiver to collude and double-spend the ASP without compensation. The author suggests adding another round of interactivity to fix the weakness.
📝 Original message:
Hi Burak,
Thanks for the interesting Ark proposal.
>From my understanding the protocol is played between 3 entities: the
sender, the receiver and the ASP and you have 3 types of transactions:
- the pool_tx
- the ATLC-connection_tx
- the ATLC-refund_tx
The pool_tx spends an on-chain funding input and 3 outputs:
- the commitment output, committing to a set of N vTXOs outputs (e.g a tree
of promised outputs)
- the connector output, spendable by the ASP signature
- the change output, from the value overflow of the on-chain funding input
A "receiver" vTXO scriptpubkey on pool_tx N includes the following
pseudo-script: multisig(receiver, ASP) or ((pk(receiver)+24h) or
(pk(ASP)+4weeks)). From the PoV of the next pool_tx state, the receiver
becomes the sender.
A ATLC-connection_tx is associated with a pool_tx N is spending one or more
vTXOs outputs from the "sender" (i.e receiver at pool_tx N-1) and one or
more connector outputs from pool_tx N. The initial
uplifting ATLC- connection_tx spends an on-chain input from the initial
sender.
I think there is a loss of funds weakness during the vTXLO transfer phase,
i.e by leveraging an ATLC-refund transaction using the unilateral exit path.
Let's say you have Alice (the sender), Bob (the receiver) and the ASP at
state N. Alice owns a vTXO on pool_tx N:
- after 24, her vTXO N can be spend unilaterally with only her own signature
- she engages with the ASP to construct a new pool_tx N+1 paying a vTXO to
Bob (this vTXO has same relative locktime 24h)
- she reveals her signature to the ASP for the ATLC-connection_tx N+1
spending her vTXO at state N and the connector output at state N+1
- the ASP broadcasts the pool_tx N+1 and the transaction is pending in
network mempools
- Alice broadcasts her ATLC refund tx using the mature unilateral exit path
- this ATLC refund tx replaces any ATLC-connection tx pending in network
mempools
- both the ATLC refund tx for vTXO at state N and the pool_tx at state N+1
confirms
- Bob the receiver can wait 24h and then he can spend the vTXO at state N+1
unilaterally
Alice and Bob successfully colluded to "double-spend" the ASP, without this
service provider earning compensation for the pool_tx state N+1 funding
input.
If I'm correct, I don't know if this weakness can be fixed by adding
another round of interactivity between the sender and the ASP, e.g
disclosing a revocation secret for the ATLC-refund transaction, without
opening the door for the ASP to steal user by stalling the next pool_tx N+1
broadcast and waiting 4 weeks time lock expiration.
All mistakes, confusion or misunderstanding are my own. More details about
transactions, scripts and protocol phases would be appreciated.
Cheers,
Antoine
Le ven. 26 mai 2023 à 16:27, Burak Keceli via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> a écrit :
> Hi David,
>
> Ark can be used for three purposes:
>
> 1. Mixing coins.
> Ark is a scalable, footprint-minimal off-chain mixer. People can use Ark
> to mix their coins with others. This doesn’t require waiting for on-chain
> confirmations since you’re mixing your own coins with others.
>
> 2. Paying lightning invoices
> Ark is interoperable with Lightning, and you can use your Ark funds to pay
> Lightning invoices in a conjoin. This also doesn’t require waiting for
> on-chain confirmations since you consider your payment “done” when you
> obtain the vendor's preimage.
>
> 3. Making internal transfers
> You can use your Ark funds to make internal money transfers without
> introducing inbound liquidity assumptions. The recipient-end has to wait
> for several on-chain confirmations to consider their payment “final”,
> however, their payment has immediate availability to them. Recipients can
> spend their zero-conf funds to pay Lightning invoices in coordination with
> their service provider. If we want to enable Lightning-style instant
> settlement assurances for the internal transfers, we need OP_XOR or OP_CAT
> on the base layer [1].
>
>
> I think you get the gist of it, but I lost you after ”Bob wants to deposit
> 1 BTC with Alice.” sorry.
>
> The initial onboarding phase is non-interactive, and there is no PSBT
> involved. Onboarding (or lifting) is as simple as funding a Bitcoin
> address.
>
> Here I have refactored it for you:
> Bob wants to deposit 1 BTC with Alice. Bob asks his friend Charlie to send
> 1 BTC to an on-chain Bitcoin address whose script is:
> pk(B) && (older(4 weeks) || pk(A))
>
> From here, there are several things that Bob can do:
> - *Unilaterally withdraw:*
> If Alice happens to be non-collaborative or non-responsive, Bob can simply
> take his 1 BTC back after four weeks.
>
> - *Collaboratively withdraw:*
> Bob and Alice can sign from the 2-of-2 to collaboratively withdraw 1 BTC
> anytime.
>
> - *Collaboratively trade commitments:*
> Alice crafts a transaction containing three outputs; (a) a commitment
> output, (b) a connector output, and (c) a change output. We call this
> transaction “pool”.
> (a) commitment output
> Commitment output (either using CTV or n-of-n multisig) constrains its
> descendant transaction to a set of transaction outputs. To simplify things,
> let’s say there are no other participants in this transaction besides Bob,
> and the descendant transaction has only one output. We call this output
> Bob’s vTXO. Bob’s vTXO also constrains (using CTV or 2-of-2 multisig) its
> descendant transaction to a single transaction output called Bob’s ATLC.
> Bob’s ATLC contains the following script:
> pk(B) && (older(4 weeks) || pk(A))
> As you realize “ATLC” script is identical to the “Funding address” script.
>
> (b) connectors output
> Connectors output is simply a single-sig output spendable by Alice herself:
> pk(A)
>
> Alice locally crafts a descending transaction from this output, spending
> “connectors output” to fund a new output. We call this output a
> ”connector,” which always carries a dust value and is spendable by Alice
> herself:
> pk(A)
>
> In short, Alice crafts a Bitcoin transaction that spends an input that she
> controls and funds an output that she controls. Alice does not broadcast
> this transaction and keeps it secret.
>
> (c) change output
> money not used for the other two outputs gets sent back to Alice.
>
> 1. Alice places one (or more) input(s) to her “pool” transaction to supply
> funds to commitment output, connectors output, change output, and
> transaction fees.
>
> 2. Bob creates an unsigned PSBT, placing the input that Charlie was
> previously funded.
>
> 3. Bob passes his PSBT to Alice.
>
> 4. Alice places one input to PSBT, the ”connector output,” which is a
> descendant of the (b) connectors output she is crafting.
>
> 5. Alice places one output to PSBT, a single-sig output that sweeps all
> money to herself (pk(A)).
>
> 6. Alice passes PSBT to Bob. Alice and Bob sign the PSBT and keeps this
> transaction private. This transaction is not valid yet, since the
> connector’s outpoint context does not exist.
>
> 7. Alice signs her one-in, three-out and broadcasts it.
>
> 8. Alice can now claim 1 BTC Charlie has previously funded by revealing
> the descendant transaction of (b) connectors output. She should claim this
> before four weeks.
>
> 9. Bob now has a 1 BTC worth UTXO representation as a descendant of the
> (a) commitment output (a virtual UTXO). He can unilaterally claim this 1
> BTC by revealing the child (Bob’s vTXO) and grandchild (Bob’s ATLC) of the
> (a) commitments output, then waiting a 24-hour window period.
>
> So far, Charlie polluted on-chain by funding an address, and Alice by
> claiming funds from that address. Further steps from here will be footprint
> minimal.
>
> 1. Say, Bob wants to send 1 BTC to Dave.
>
> 2. Alice crafts a transaction containing three outputs; (a) a commitment
> output, (b) a connector output, and (c) a change output. This time
> descendant of (a) commitment output is Daves’s vTXO instead of Bob’s.
> Similarly descendant of Daves’s vTXO is Dave’s ATLC. Dave’s ATLC is:
> pk(D) && (older(4 weeks) || pk(A))
>
> 3. Alice places one connector output as a descendant of (b) connectors
> output, just like before.
>
> 4. Alice places one input to her one-in, three-out transaction to supply
> funds to commitment output, connectors output, change output, and
> transaction fees.
>
> 5. Bob creates an unsigned PSBT, placing his 1-BTC-worth virtual UTXO from
> the (a) commitment output descendants that Alice previously
>
> 6. Bob passes his PSBT to Alice.
>
> 7. Alice places one input to PSBT, the ”connector output,” which is a
> descendant of the (b) connectors output she is crafting.
>
> 8. Alice places one output to PSBT, a single-sig output that sweeps all
> money to herself (pk(A)).
>
> 9. Alice passes PSBT to Bob. Alice and Bob sign the PSBT and keeps this
> transaction private.
>
> 10. Alice signs her one-in, three-out transaction and broadcasts it.
>
> 11. Bob lets Dave know about this transaction (Alice’s transaction id,
> Dave’s vTXO output index) out-of-band.
>
> 12. When Dave comes back online, he sees from the out-of-band message that
> Bob sent him 1-BTC. He then verifies whether Alice’s transaction id exists,
> whether his vTXO output index is correct, and a set of other validations.
>
> 13. If Dave had been online all this time, he would have had to wait for
> enough confirmations to consider his payment “final.”
>
> [1] https://eprint.iacr.org/2017/394.pdf
> _______________________________________________
> 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/20230806/ea402b43/attachment-0001.html>

2023-07-27 00:22:34

- reply

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

2023-07-20 09:54:06

- reply

📅 Original date posted:2023-07-20
🗒️ Summary of this message: The author discusses the potential benefits of covenant schemes in improving the Lightning Network and Bitcoin's survival. They mention the limitations of 2-party payment channels and the ongoing changes in channel operations. The use of covenant primitives in DLC development and financial engineering expressivity is also highlighted.
📝 Original message:
Hi Keagan,
On the claim that advanced contracting capabilities can improve the
Lightning Network, yes this is a claim I can back and why with Gleb we
published ideas about payment pools back in 2020, pointing out clearly the
limitations of 2-party payment channels in terms of privacy and scalability
dimensions [0]. There are few discussions on the same thread on trade-off
of hashchain covenants like CTV in terms of off-chain constructions, where
they can be evaluated on a bunch of dimensions like key management, fee
cost, liquidity counterparty interactivity and security risks among others.
I don't know if Bitcoin _needs_ covenant schemes to survive on the long
term though yes I'll join the appreciation than few covenants (notable ones
improving payment pools or channel factories and self-custody solutions)
are increasing the odds of success of Bitcoin survival on dimensions like
onboarding / transactional scaling and "non-first-party to self-sovereign
custody" shapes of solutions. On a theoretical proof that covenants are
formally needed, well one would have to reduce Bitcoin (and probably
Lightning and the mining ecosystem) to a workable game-theory, and define
this game to rely on practice assumptions to bound the dynamics of the
"real-world" context [1].
On the latest claim that Lightning of today *might* benefit from a covenant
primitive, it's hard to evaluate as the foundations of channel operations
are quite under intense re-works from taproot, schnorr and package relay
(affecting all the dimensions). Yet one might notice that "high-level"
Lightning is more isolated than those ongoing changes, and where covenant
primitives might be useful. I think there is a widely-known issue among the
DLC development community on the limitations of signatures compared to
CTV-like "hash-chain" in matters of financial engineering expressivity over
a wide outcome space [2], [3], [4]. We experimented in the past DLC
integration in LDK, though never so far to evaluate the practical
performance bounds of curve points addition on what what you can express as
advanced contracts (the original coinpool post points to the factorial
complexity bound for withdrawal of unknown order and therefore covenant
capabilities improves the issue, though here it's an issue of _any_ state
being dependent on an unknown combination of oracle-sourced events).
Best,
Antoine
[0]
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2020-June/017964.html
[1] E.g the delicate difference between the "theory" and "practice" from
the viewpoint of physics, I would send back to Einstein's general theory
where few (anecdotic?) experiments have cast doubts on its validity, e.g
Miller's experiment in the 20s, and the echoes it had in scientific
epistemology during the XXth.
[2]
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-January/019808.html
[3] https://mailmanlists.org/pipermail/dlc-dev/2021-November/000091.html
[4]
https://github.com/bitcoinops/bitcoinops.github.io/pull/806#issuecomment-1232073574
Le mer. 19 juil. 2023 à 19:29, Keagan McClelland <
keagan.mcclelland at gmail.com> a écrit :
> 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
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20230720/c6dca4c4/attachment-0001.html>

2023-07-20 09:54:05

- reply

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

2023-07-19 02:09:38

- reply

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

2023-07-06 09:11:18

- reply

📅 Original date posted:2023-07-05
🗒️ Summary of this message: The text discusses the potential damage and mitigations in the Lightning Network protocol, including routing fees and on-chain fees. It also explores the difficulty of gaining reputation and suggests a reputation-based mitigation strategy. The author emphasizes the need to consider the adversary's capabilities and information asymmetry. They propose a monetary-based mitigation strategy that quantifies the damage inflicted on the victim.
📝 Original message:
Hi,
> The only damage we can observe in the protocol is routing fees. If we go
ahead with our suggestion, it will be straightforward to choose a different
threshold based on the preference of a node. We have some suggestions for
receiving nodes, for example.
I think there is another obvious damage that we can observe at the
protocol-level, on-chain fees if the target node opens more channel to
compensate the slow-jammed ones, or if there is an automatic force-close in
reason of the low-yield of a channel by the liquidity allocation engine
(e.g something like CLBOSS).
Of course, the "reaction" of a target node is first not very standardized
by a BOLT, second very specific in function of the node activity (pure
routing node, LSP, merchant). So it sounds better deferred to the ulterior
level of development of the mitigations, let's hope we can solve the simple
cases first.
> The difficulty to gain reputation is proportional to the amount of damage
that can be inflicted.
Okay, I think this is where I diverge on the soundness of the HTLC
endorsement solution. For the historical note, when stakes certificates as
a jamming mitigation where proposed back in 2020 [0], the intuition on the
soundness of the security model was it would cost as much for an adversary
to acquire a "fresh" UTXO proof-of-ownership than the level of damage they
can inflict. Which sounds to me the same intuition you're sharing here.
After doing more research the past year [1], it was realized on my side
than the cost function of the adversary is hard to formalize in a world
where the adversary capabilities (quid if the adversary is a miner ?),
source of information (quid if the adversary has better on-chain fees
estimation ?), attacking strategy (quid if they batch a jamming against
multiple target nodes from a _single_ UTXO?) are all unknowns or
"hard-to-guess" variables.
Additionally, the target node source of information is unknown, or at the
very best for the purpose of mitigation design, we can do the assumptions
based on standard/implementation default. However here an adversary is
always free to have a better source of information (the historical
Shannon's quote "The enemy knows the system" in matters of cryptanalysis).
So my own intellectual conclusion is that ideally a reputation-based
mitigation strategy should have a homomorphism with a monetary-based
mitigation strategy in the eventuality of a jamming adversary gaining an
informational asymmetry.
A monetary-based mitigation strategy has the formal advantage that it can
be quantified 100% to the worst-damage inflicted from the preference of the
target node itself.
> "A significant cost", unlike right now where it's practically free.
Because we don't know how deep are the pockets of the attacker, our focus
is on compensating the victim.
Yes, I think "compensating the victim" is a good direction from the insight
laid out just above. Though note the theoretical caveat on the (probable)
necessity of measuring reputation in pure monetary terms.
> Because a lot of the criteria are "soft" (UX, ease of implementation), we
cannot prove theorems. We are working on further simulations for the
quantifiable criteria, to see if theory meets practice.
> Note that DDoS attacks are notoriously difficult to mitigate (see [0],
for example), so we are trying to do our best in the context of lightning
using the available tools
This is why the modern security models and cryptanalysis are based on
assumptions (e.g the DL problem or hardware enforcement of your OS boot).
Such assumptions laying out of mitigations soundness analysis "soft"
criterias. Note such intellectual process has been followed as a standard
design in the redaction of modern Bitcoin standards like BIP340 (schnorr)
and BIP341 (taproot).
For the mathematical note, theorems are not "fully" proved (see the failure
of Hilbert's program to found XXth century mathematics on a complete set of
axioms), though the proving process has a valuable interest to select
theorems for practical applications.
> We are working on further simulations for the quantifiable criteria, to
see if theory meets practice.
> Note that DDoS attacks are notoriously difficult to mitigate (see [0],
for example), so we are trying to do our best in the context of lightning
using the available tools.
Note, modern DDoS attacks mitigations have been discussed using "tokens"
blockchain as a basis for a monetary strategy (e.g the Tor project blog
[0]).
I think all past literature on DDoS attacks has to be reviewed under the
light of a global "ledger" like the Bitcoin blockchain where all the DDoS
attacks can be measured in terms of satoshis, a utility cost function
shared de facto by all the participants of the system.
> Simulation running as we speak.
Formalization of the game-theory of jamming attacks advancing as we speak.
Best,
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://blog.torproject.org/stop-the-onion-denial/
Le mar. 20 juin 2023 à 22:11, Clara Shikhelman <clara.shikhelman at gmail.com>
a écrit :
> Hi,
>
>
>> Sure, I understand that in case of an attack, a routing node should have
>> been paid a significant fee sum by the peer originating the jamming
>> traffic. However from my understanding this is unclear with the proposed
>> htlc endorsement system than the fees paid are fully economically
>> compensating the damage inflicted to the victim ?
>>
>
> The only damage we can observe in the protocol is routing fees. If we go
> ahead with our suggestion, it will straightforward to choose a different
> threshold based on the preference of a node. We have some suggestions for
> receiving nodes, for example.
>
>
>> Or if it's a proportional compensation, and if proportional the ratio
>> between the fees and the reputation is static or dynamic, and if dynamic
>> which are the criterias of evaluation ?
>>
>
> The difficulty to gain reputation is proportional to the amount of damage
> that can be inflicted.
>
>
>>
>> Note, outlawing the cost of the attack from the system guarantees sounds
>> contrary to the htlc endorsement design goal shown in your gist: "the goal
>> of this proposal is to produce a mitigation that has...a significant cost
>> to persistent attackers", or are the design goals proposed elsewhere ?
>>
>
> "A significant cost", unlike right now where it's practically free.
> Because we don't know how deep are the pockets of the attacker, our focus
> is on compensating the victim.
>
>
>> So I still don't know the precise problem to be solved by any jamming
>> mitigation, in a formal fashion, nor the correctness conditions required of
>> a solution. As far as I can tell, such information is not present in the
>> "unjamming lightning" paper (while the paper claims to "systematically
>> analyze the solution space" it does not formalize the problem, at least in
>> terms of abstract definition that holds independently of the solution
>> adopted).
>>
> I think there is still an undervaluation of how much the liquidity
>> griefing issues affecting Lightning and second-layers, of which jamming is
>> only one, is novel from the viewpoint of financial cryptography/computer
>> security literature. At the best, I think we should aim to evaluate the
>> effectiveness of any jamming solution with the same conceptual rigor as
>> modern cryptanalysis (understood notions like shannon cipher, perfect
>> security, switching lemma).
>>
> Without such rigor of analysis, I don't think we'll be able to give
>> "measurable" bounds to any solution, and know when there is a wreckage
>> because we're modifying some subtle parameters like channel opening
>> default, or the adversaries can access superior sources of information to
>> decide when to launch a jamming attack where the sum paid does _not_ cover
>> the operational cost of a routing hop.
>>
>
> Because a lot of the criteria are "soft" (UX, ease of implementation), we
> cannot prove theorems. We are working on further simulations for the
> quantifiable criteria, to see if theory meets practice.
> Note that DDoS attacks are notoriously difficult to mitigate (see [0], for
> example), so we are trying to do our best in the context of lightning using
> the available tools.
>
>
>> So if you recognize that htlc endorsement can fluctuate the link-level
>> liquidity more than it does now, at the very least it would be good to come
>> with simulations on how it might downgrade HTLC routing traffic ?
>>
>
> Simulation running as we speak.
>
> Best,
> Clara
>
> [0]
> https://www.sciencedirect.com/science/article/abs/pii/S1389128603004250?casa_token=BauKTUZ1yEYAAAAA:Ny9OvPXunkvLZgJD1bYQ_amV-rsMVRbYKozWchYB9ZpFZ3dNFfJnK74UYl7di9R24aDhrw
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20230705/12627c56/attachment.html>

2023-07-01 12:15:29

- reply

📅 Original date posted:2023-06-30
🗒️ Summary of this message: The text discusses the concept of a bulletin board operator relaying orders in a market structure. It suggests that if the operator can generate outsized profits, competitors may enter the market. It also mentions the idea of tiered services and compares execution quality between operators.
📝 Original message:
Hi Chris,
Thanks for the review and sorry for the late answer here.
> To summarize, assume we have Mary the Maker, Terry the Taker, and Bob the
bulletin board operator
>
> 1. Mary the Maker publishes a limit order to buy a derivative
> 2. Bob the bulletin board operator has the option to execute against
Mary's order
> 3. If Bob doesn't want to execute against the order, he relays the order
to Terry the Taker (and other subscribers to Bob's market)
> 4. Terry has the option to execute a trade against Mary's limit order
> 5. If Terry decides not to execute, Mary's order sits on the bulletin
board.
>
> I personally don't think this is that big of a concern, if Bob can
collect outsized profits from his trusted position as the bulletin board
operator, Terry will eventually move to other markets because Bob is
> only relaying what Bob perceives to be unprofitable orders.
Yes this is somehow a design assumption of the CivKit architecture, to keep
the migration cost low from a bulletin board to another one, if all the
orders are executed by the "house" based on privileged "market-making"
liquidity, and the outsized profits makes it interesting for another
incumbent to enter into the market, you will spawn competing bulletin
boards showing up.
Note, Terry the maker client might be okay to follow and pay the premium
for access to a market board, if the board has a very consistent policy
protecting against "bad" order wasting timevalue of Terry's liquidity.
> From the perspective of Mary, she is happy. Her order got executed at the
price she specified. Terry is the one that loses here. This model ends up
looking much more like a brokerage rather than an
> exchange market structure. Terry should open up his own brokerage
(bulletin board) and compete on quoting prices with Bob.
Yes, I think this is very expected that you might have tiered services
where you have a market bulletin board specialized in processing
large-scale volume of data (with high-guarantees of fault-tolerance) and
another hand "brokers" which have more content aggregators. The brokerage
service will be harder to "trust-minimized", unless somehow all the Bobs
are publishing their quoting prices in real-time.
> Bob and Terry can then be compared on metrics like execution quality
<https://clearingcustody.fidelity.com/trade-execution-quality>, which then
draws more market activity since they are providing better prices.
Yes, I think this is more or less the type of "board monitoring" algorithms
suggested in section 5 "orderbook risks", though the scoring criterias are
not presented like for the Fidelity definition of quality (i.e price
improvement, execution price, execution speed, effective spread).
One can expect to have this running as a "watchtower" like we have under
deployment for Lightning clients with fluctuating levels of flappyness.
> This. Frontrunning is a good problem to have, that means your market has
active participants and liquidity. Finding what products people are
interested in trading, and giving them a good user experience > is more
important. Everything else will fall in line after that.
While the first approach is the one more described in the CivKit paper,
from the history of peer-to-peer systems bootstrap, relying on social
assumptions like the over-the-counter ones might be more prolific. It might
also be a better user experience when people are exchanging cash versus
satoshis on the ground, or any other physical goods.
Ideally, if the offers data structures and the reputation framework common
between both OTC and "public boards" you might have traffic flows
circulating between both, and users will pick up the trading approach that
fits more the type of trades they wish to engage into. Compatibility of the
key-material for the clients between the different contexts sounds to
matter for smooth bootstrap too.
Best,
Antoine
Le mar. 9 mai 2023 à 16:09, Chris Stewart <chris at suredbits.com> a écrit :
> >In traditional finance, front-running is defined as "entering into an
> equity trade, options or future contracts with advance knowledge of a block
> transaction that will influence the price of the underlying security to
> capitlize on the trade" [0]. In Bitcoin/Civkit parlance, a front-running
> could be a board on the discovery of a batch of market offers increasing
> liquidity for a fiat-2-btc pair, seizing the opportunity by forwarding a
> HTLC across a Lightning payment path to enter into the trade, before
> publishing the offer on its board.
>
> To summarize, assume we have Mary the Maker, Terry the Taker, and Bob the
> bulletin board operator
>
> 1. Mary the Maker publishes a limit order to buy a derivative
> 2. Bob the bulletin board operator has the option to execute against
> Mary's order
> 3. If Bob doesn't want to execute against the order, he relays the order
> to Terry the Taker (and other subscribers to Bob's market)
> 4. Terry has the option to execute a trade against Mary's limit order
> 5. If Terry decides not to execute, Mary's order sits on the bulletin
> board.
>
> I personally don't think this is that big of a concern, if Bob can collect
> outsized profits from his trusted position as the bulletin board operator,
> Terry will eventually move to other markets because Bob is only relaying
> what Bob perceives to be unprofitable orders.
>
> From the perspective of Mary, she is happy. Her order got executed at the
> price she specified. Terry is the one that loses here. This model ends up
> looking much more like a brokerage rather than an exchange market
> structure. Terry should open up his own brokerage (bulletin board) and
> compete on quoting prices with Bob.
>
> Bob and Terry can then be compared on metrics like execution quality
> <https://clearingcustody.fidelity.com/trade-execution-quality>, which
> then draws more market activity since they are providing better prices.
>
> >Somehow mass front-running on the board is a "champagne" issue I'll be
> happy to have.
>
> This. Frontrunning is a good problem to have, that means your market has
> active participants and liquidity. Finding what products people are
> interested in trading, and giving them a good user experience is more
> important. Everything else will fall in line after that.
>
>
> On Mon, May 1, 2023 at 1:06 PM Antoine Riard via bitcoin-dev <
> bitcoin-dev at lists.linuxfoundation.org> wrote:
>
>> Hi all,
>>
>> One of the most relevant feedback I received on the paper publication was the lack of underscoring front-running resistance as a fundamental property wished for a peer-to-peer marketplace.
>>
>> It is expected the level of front-running resistance aimed by the market participants to be heavily functioned by the types of trades considered: fiat currencies, real goods, services. For some classes of goods, e.g commodities one cannot expect the same level of item liquidity due to cycle of production and exogenous factors like weather. Some types of trades marketplaces might be exposed to far less front-running risks and rather would have to deal with accurate risk modelling of the underlying goods. E.g attest there is a decentralized identifier or any other linkage proof of the physical good existence staying valid for the duration of offer lifetime. Offers conditions themselves might be far more verbose and precise special Bitcoin Script paths to morph the shipment risks.
>>
>> On the other hand, the types of trades like fiat currencies or bitcoin financial contracts (e.g discreet log contracts or submarine swaps), front-running risk by the bulletin board sounds a qualified concern. In traditional finance, front-running is defined as "entering into an equity trade, options or future contracts with advance knowledge of a block transaction that will influence the price of the underlying security to capitlize on the trade" [0]. In Bitcoin/Civkit parlance, a front-running could be a board on the discovery of a batch of market offers increasing liquidity for a fiat-2-btc pair, seizing the opportunity by forwarding a HTLC across a Lightning payment path to enter into the trade, before publishing the offer on its board.
>>
>> I think you have at least two security paradigms to mitigate front-running happening peer-to-peer marketplace. The first one is to duplicate the announcement of the offers to a number of concurrent board operated by independent identities and in parallel monitor the latency. Latency anomalies should be spotted on by watchtower-like infrastructure at the service of makers/takers and in case of repeated anomalies a maker should disqualify the misbehaving board from future announcements. As all statistical mitigation it is not perfect and open the way to some margin of exploitation by the boards, as the watchtower monitoring frequency can be guessed. Additionally, this latency monitoring paradigm sounds to be valid under the assumption that at least one board is "honest" and board might have a holistic interest to silently collude. Running or accessing monitoring infrastructure comes with a new liveliness requirement or additional cost for mobile clients.
>>
>> Another paradigm can be to run the bulletin boards as a federation e.g under Honey Badger BFT as used by Fedimint [1]. The incoming board offers become consensus items that must be announced to all the federations members onion gateway and which are not announced before a consensus proposal has been adopted. The e-cash tokens can be rather Bitcoin-paid credentials required by the board federation for publication. The federation members earn an income as a group to follow the consensus rules and be paid only when there is "consensus" publication. The federation could adopt some "DynFed" techniques to extend the federation set [2]. One can imagine a federation consisting of all the significant market participants, leveling the field for all.
>>
>> Is there another security paradigm direction to mitigate front-running and other asymmetries of information ? I can't immediately imagine more though I believe it stays an interesting open question.
>>
>> In fine, the Civkit proposes a flexible framework for peer-to-peer marketplace, where propagation latency monitoring and federation set and rules can be tweaked as "front-running resistance" parameters, adapting to the types of trades and market participants tolerance. Configuration of those parameters will at the end be function of real-world deployments. Somehow mass front-running on the board is a "champagne" issue I'll be happy to have.
>>
>> Best,
>> Antoine
>>
>> [0] https://www.finra.org/investors/insights/getting-speed-high-frequency-trading
>> [1] https://fedimint.org/docs/CommonTerms/HBBFTConsensus
>> [2] https://blockstream.com/assets/downloads/pdf/liquid-whitepaper.pdf
>>
>>
>> Le jeu. 13 avr. 2023 à 15:10, Antoine Riard <antoine.riard at gmail.com> a
>> écrit :
>>
>>> Hi list,
>>>
>>> We have been working since a while with Nicholas Gregory (Commerce
>>> Block), Ray Youssef (the Built With Bitcoin foundation) and few others on a
>>> new peer-to-peer market system to enable censorship-resistant and
>>> permissionless global trading in all parts of the world. While the design
>>> aims in priority to serve on-ramp/off-ramp trading, it can be extended to
>>> support any kind of trading: goods, services, bitcoin financial derivatives
>>> like discreet log contracts.
>>>
>>> The design combines the Nostr architecture of simple relays announcing
>>> trade orders to their clients with Lightning onion routing infrastructure,
>>> therefore granting high-level of confidentiality to the market
>>> participants. The market boards are Nostr relays with a Lightning gateway,
>>> each operating autonomously and in competition. The market boards can be
>>> runned as a federation however there is no "decentralized orderbook" logged
>>> into the blockchain. The trades are escrowed under Bitcoin Script
>>> contracts, relying on moderations and know your peer oracles for
>>> adjudication.
>>>
>>> The scoring of trades, counterparties and services operators should be
>>> enabled by the introduction of a Web-of-Stakes, assembled from previous
>>> ideas [0]. From the Bitcoin UTXO set servicing as a trustless source of
>>> truth, an economic weight can be assigned to each market entity. This
>>> reputation paradigm could be composed with state-of-the-art Web-of-Trust
>>> techniques like decentralized identifiers [1].
>>>
>>> A consistent incentive framework for service operators is proposed by
>>> the intermediary of privacy-preserving credentials backed by Bitcoin
>>> payments, following the lineaments of IETF's Privacy Pass [2]. Services
>>> operators like market boards and oracles are incentivized to thrive for
>>> efficiency, akin to routing hops on Lightning and miners on the base layer.
>>>
>>> The whitepaper goes deep in the architecture of the system [3] (Thanks
>>> to the peer reviewers!).
>>>
>>> We'll gradually release code and modules, extensively building on top of
>>> the Lightning Dev Kit [4] and Nostr libraries. All according to the best
>>> Bitcoin open-source and decentralized standards established by Bitcoin Core
>>> and we're looking forward to collaborating with everyone in the community
>>> to standardize libraries and guarantee interoperability between clients
>>> with long-term thinking.
>>>
>>> Feedback is very welcome!
>>>
>>> Cheers,
>>> Nick, Ray and Antoine
>>>
>>> [0]
>>> https://lists.linuxfoundation.org/pipermail/lightning-dev/2020-November/002884.html
>>> [1] https://www.w3.org/TR/2022/REC-did-core-20220719/
>>> [2] https://privacypass.github.io
>>> [3] https://github.com/civkit/paper/blob/main/civ_kit_paper.pdf
>>> [4] https://lightningdevkit.org
>>>
>> _______________________________________________
>> 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/20230630/863f1023/attachment-0001.html>

2023-06-23 13:42:33

- reply

📅 Original date posted:2023-06-23
📝 Original message:
Hi lightning devs,
Proposing myself to organize next year's LN Summit in Africa, with a rough
date somewhere in June 2024.
There are a lot of reasons to hold a summit there. Africa is a beautiful
continent, there is a rich cultural and historical past, a lot of
fragmentation in the financial systems of the 56 states that can be solved
with a compatible payment protocol, an explosive demography with a lot of
energy to get things done, more and more Lightning developers coming from
this continent and formidable perspectives to grow "full-stack" local
Lightning economies.
Usually, we don't announce the organization of CoreDev or LN Summit on open
communication channels, as there is a goal of serenity of the engineering
conversation (and as we would like to avoid being trolled by BSV fans or
tabloid-style of journalism). For this time, given the operational
challenges can be a bit more complex (e.g visas travels, "tropical
weather"), better to have this announced far ahead [0]. Operations and
financial resources should be okay, though nice if we have a
multi-stakeholder approach, "skin in the game" from a bunch of folks is the
best way to guarantee fairness and transparency of the process.
If you have any objection to my personna contribution to the organization
of the LN Summit 2024, thanks for letting me know during the coming weeks,
either in public or on this thread, or privately by mail. As usual, I'll do
my best to set strong transparency and accountability standards. In matters
of open-source, talk is cheap, better to speak by your actions.
With any project, the best advice is always to start small, so the first
step sounds to be to survey all the countries with reasonable operational
stability that can fit the location (Algeria, Ghana, Senegal, Nigeria,
etc). I'll look into it and share the feedback privately to the Lightning
attendees (based on neutral and technical proof of works heuristics),
somewhere at the end of the summer.
Setted up a dedicated communication endpoint for this:
lnsummit2024 at ariard.me
If you're a LN dev, don't hesitate to reach out if you wanna to be part of
the organization, this is a good opportunity to transfer knowledge between
generations of contributors.
Cheers,
Antoine
[0] Already co-organized the CoreDev event in Zurich back in 2021 so I do
have already the operational templates.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20230623/7469a241/attachment.html>

2023-06-21 09:18:57

- reply

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

2023-06-20 11:15:35

- reply

📅 Original date posted:2023-06-19
🗒️ Summary of this message: LNbits discovered an exploit allowing attackers to create balances by abusing a quirk in how invoices are handled internally, which may affect other Lightning applications. A patch has been released.
📝 Original message:
Hi calle,
Thanks for the report.
>From my understanding of what you're describing, the attack is possible
because LNBits backend does not check that an external received HTLC
`amount_msat` satisfies the invoice amount for both matching preimage and
payment secret. This sounds plausible to me.
If you're a custodial wallet, payment processor or account management
software based on LDK, and you respect the API recommendations of using
`create_inbound_payment`, you should not be affected as amount equivalence
checks are handled by the implementation:
https://github.com/lightningdevkit/rust-lightning/blob/c3c105075aeb8128699e043f777b4c89c452e54d/lightning/src/ln/channelmanager.rs#L4469
The "checking ids" sounds a workable mitigation to firewall internal
invoice state from external ones, though beware issues with id collision,
if it can be determined by the attacker.
Potential safety issues with invoices have been known since CVE-2020-26896.
Good disclosure security practice suggests having previously warned the
Lightning implementation maintainers on their respective security
communication channels to ease patch coordination if needed with
second-line vendors like wallets and processors.
Best,
Antoine
Le lun. 19 juin 2023 à 17:19, callebtc via Lightning-dev <
lightning-dev at lists.linuxfoundation.org> a écrit :
> Dear list,
>
> earlier last month, our team at LNbits discovered a rather interesting
> exploit which wich would enable an attacker to create balances out of thin
> air by abusing a quirk in how invoices are handled internally. We've
> patched this in LNbits version 0.10.5 and urge anyone to update ASAP if you
> haven't done so already. I want to describe the attack here, since my gut
> feeling is that carrying out the same exploit is possible in other
> Lightning applications. If you're working on custodial wallets, payment
> processors, account management software, etc. you probably want to read
> this.
>
> In short, the attacker was able to insert a bolt-11 payment hash of
> payment A into a different payment, creating a malicious invoice B that can
> trick the backend into believing that B == A.
>
> Here is how it goes:
>
> - Attacker creates invoice A of amount 1000 sat in LNbits
> - Attacker creates invoice B' of amount 1 sat on her own node
> - Attacker deserializes B', inserts payment_hash(A) into payment_hash(B),
> re-signs the invoice, and serializes it again, producing malicious invoice B
> - Attacker creates a new account in LNbits and pays B
>
> - LNbits backend uses payment_hash(B) to check whether this is an internal
> payment or a payment via LN
> - Backend finds A in its database since we implicitly assume that
> payment_hash(A) commits to A
>
> ** This is the critical part! Payment hashes do *NOT* commit to any
> payment details (like amount) but only to the preimage! **
>
> - Backend settles payment internally by crediting A debiting B
> - Attacker has "created" 999 sats
>
> Mitigation:
>
> The mitigation is quite simple. Backends should either use self-generated
> unique "checking id's" for looking up internal payments or use additional
> checks to make sure that the invoice details have not been messed around
> with (e.g., asserting amount(A) == amount(B)).
>
> Lessons:
>
> I think there are two lessons here. First, it's good to realize the level
> of sophistication of LN-savvy attackers. This attack clearly involves a
> fundamental understanding of bolt-11 and requires custom tooling to produce
> the malicious invoice.
>
> The second lesson is more valuable: The "payment hash" of an invoice is
> not a "payment" hash but merely a "preimage" hash – and nothing else.
> Naming this field as such increases the chance of developers implicitly
> assuming that the hash commits to payment details like amount, pubkey, etc.
> I will from now on call this simply the "preimage hash" and invite you to
> do so too.
>
> Best
>
> Calle
> _______________________________________________
> 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/20230619/51635592/attachment.html>

2023-06-19 18:20:00

- reply

📅 Original date posted:2023-06-18
🗒️ Summary of this message: Antoine Riard discusses the potential need for an opt-in mechanism for non-deployed and deployed protocols in the context of collaborative added inputs.
📝 Original message:
Hi Greg,
> Going to need a citation for this.
Sorry for the confusion, this was in reply to Joost's point on "Opt-in
annex (every input must commit to an annex even if its is empty) -> make
sure existing multi-party protocols remain unaffected"
What is unclear to me is if we're talking about opt-in of non-deployed-yet
protocols like the pre-signed vaults or deployed protocols like
coinjoin/lightning spending P2TR outputs, where a counterparty script spend
path can inflate the witness, and we would like to commit *now* to avoid
future interferences. E.g 0-conf dual-funding and we loosened the limit
from 126 bytes to 256, the worst-case liquidity griefing is not the same
anymore.
If the opt-in mechanism we're talking about is just adding an annex for
non-deployed-yet protocols as a script spend path of a currently deployed
protocol could always be opted-in to the new annex policy through script
spend path in the context of collaborative added inputs, no ?
> People should really not be building protocols that are meant to go into
production on top of undeveloped upgrade hooks,
and we should not be encumbered by these premature choices if so.
> People should really not be building protocols that are meant to go into
production on top of undeveloped upgrade hooks,
> and we should not be encumbered by these premature choices if so. Maybe
I'm misunderstanding, which is why a citation
> would be handy.
Yes ideally we should not be encumbered by these premature choices. Still
if those use-cases catched up in terms of economic weight, the coordination
cost of deploying a new policy might be prohibitive, or require very long
periods, somehow like we're seeing with mempoolfullrbf. And I don't think
we can say the use-cases would be illegitimate, or that base-layer policy
should always have the last word. In the example of lightning, we're doing
major re-work of the mempool, partially to improve lightning operations.
Personally, I think we should care more about sound and "firewalled"
signaling and upgrading mechanisms that let us deploy new policy rules for
new use-cases more smoothly.
Best,
Antoine
Le dim. 18 juin 2023 à 21:41, Greg Sanders <gsanders87 at gmail.com> a écrit :
> Hi Antoine,
>
> > If I understand correctly, this would require modifying current Taproot
> support on the Lightning-side, where all P2TR spends must add an annex and
> commit to it in the BIP341 signature digest.
>
> huh?
>
> Going to need a citation for this.
>
> People should really not be building protocols that are meant to go into
> production on top of undeveloped upgrade hooks,
> and we should not be encumbered by these premature choices if so. Maybe
> I'm misunderstanding, which is why a citation
> would be handy.
>
> Best,
> Greg
>
> On Sun, Jun 18, 2023 at 4:32 PM Antoine Riard <antoine.riard at gmail.com>
> wrote:
>
>> Hi all,
>>
>> > * Opt-in annex (every input must commit to an annex even if its is
>> empty) -> make sure existing multi-party protocols remain unaffected
>>
>> By requiring every input to commit to an annex even if it is empty, do
>> you mean rejecting a transaction where the minimal annex with its 0x50 tag
>> is absent ?
>>
>> If I understand correctly, this would require modifying current Taproot
>> support on the Lightning-side, where all P2TR spends must add an annex and
>> commit to it in the BIP341 signature digest. This would be quite a
>> mandatory upgrade for Lightning nodes, as failure to do so would break
>> propagations of their `option_taproot` channel transactions.
>>
>> > * Limit maximum size of the value to 256 bytes -> protect opt-in users
>>
>> There is another approach where the maximum size/weight of the
>> witness/transaction is introduced as a TLV record itself:
>> https://github.com/bitcoin-inquisition/bitcoin/pull/28
>>
>> Note this branch also implements the "only allow tlv record 0" with the
>> TLV format from bips #1381.
>>
>> Best,
>> Antoine
>>
>> Le ven. 16 juin 2023 à 14:31, Greg Sanders via bitcoin-dev <
>> bitcoin-dev at lists.linuxfoundation.org> a écrit :
>>
>>> Hi Joost,
>>>
>>> I haven't thought a ton about the specific TLV format, but that seems
>>> like a reasonable place to start as it shouldn't unduly
>>> impact current users, and is pretty simple from an accounting
>>> perspective.
>>> It also can be further relaxed in the future if we so decide by using
>>> max tx size policy "hints" in an annex field.
>>>
>>> I'll let others chime in at this point!
>>>
>>> Cheers,
>>> Greg
>>>
>>> On Fri, Jun 16, 2023 at 7:27 AM Joost Jager <joost.jager at gmail.com>
>>> wrote:
>>>
>>>> Hi Greg,
>>>>
>>>> On Thu, Jun 15, 2023 at 12:39 PM Greg Sanders <gsanders87 at gmail.com>
>>>> wrote:
>>>>
>>>>> > Would it then still be necessary to restrict the annex to a maximum
>>>>> size?
>>>>>
>>>>> I think it's worth thinking about to protect the opt-in users, and can
>>>>> also be used for other anti-pinning efforts(though clearly not sufficient
>>>>> by itself for the many many pinning vectors we have :) )
>>>>>
>>>>
>>>> Thinking about the most restrictive policy that would still enable
>>>> annex-vaults (which I believe has great potential for improving bitcoin
>>>> custody) and is in line with work already done, I get to:
>>>>
>>>> * Opt-in annex (every input must commit to an annex even if its is
>>>> empty) -> make sure existing multi-party protocols remain unaffected
>>>> * Tlv format as defined in https://github.com/bitcoin/bips/pull/1381
>>>> -> future extensibility
>>>> * Only allow tlv record 0 - unstructured data -> future extensibility
>>>> * Limit maximum size of the value to 256 bytes -> protect opt-in users
>>>>
>>>> Unfortunately the limit of 126 bytes in
>>>> https://github.com/bitcoin-inquisition/bitcoin/pull/22 isn't
>>>> sufficient for these types of vaults. If there are two presigned txes
>>>> (unvault and emergency), those signatures would already take up 2*64=128
>>>> bytes. Then you also want to store 32 bytes for the ephemeral key itself as
>>>> the key can't be reconstructed from the schnorr signature. The remaining
>>>> bytes could be used for a third presigned tx and/or additional vault
>>>> parameters.
>>>>
>>>> Can you think of remaining practical objections to making the annex
>>>> standard under the conditions listed above?
>>>>
>>>> Joost
>>>>
>>>>> _______________________________________________
>>> 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/20230619/adfbce5a/attachment.html>

2023-06-19 18:19:59

- reply

📅 Original date posted:2023-06-18
🗒️ Summary of this message: The proposed Taproot upgrade may require Lightning nodes to add an annex and commit to it in the BIP341 signature digest, which could break propagations of their `option_taproot` channel transactions. Additionally, a limit of 256 bytes may be introduced to protect opt-in users. A TLV format and only allowing tlv record 0 may also be implemented for future extensibility.
📝 Original message:
Hi all,
> * Opt-in annex (every input must commit to an annex even if its is empty)
-> make sure existing multi-party protocols remain unaffected
By requiring every input to commit to an annex even if it is empty, do you
mean rejecting a transaction where the minimal annex with its 0x50 tag is
absent ?
If I understand correctly, this would require modifying current Taproot
support on the Lightning-side, where all P2TR spends must add an annex and
commit to it in the BIP341 signature digest. This would be quite a
mandatory upgrade for Lightning nodes, as failure to do so would break
propagations of their `option_taproot` channel transactions.
> * Limit maximum size of the value to 256 bytes -> protect opt-in users
There is another approach where the maximum size/weight of the
witness/transaction is introduced as a TLV record itself:
https://github.com/bitcoin-inquisition/bitcoin/pull/28
Note this branch also implements the "only allow tlv record 0" with the TLV
format from bips #1381.
Best,
Antoine
Le ven. 16 juin 2023 à 14:31, Greg Sanders via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> a écrit :
> Hi Joost,
>
> I haven't thought a ton about the specific TLV format, but that seems like
> a reasonable place to start as it shouldn't unduly
> impact current users, and is pretty simple from an accounting perspective.
> It also can be further relaxed in the future if we so decide by using max
> tx size policy "hints" in an annex field.
>
> I'll let others chime in at this point!
>
> Cheers,
> Greg
>
> On Fri, Jun 16, 2023 at 7:27 AM Joost Jager <joost.jager at gmail.com> wrote:
>
>> Hi Greg,
>>
>> On Thu, Jun 15, 2023 at 12:39 PM Greg Sanders <gsanders87 at gmail.com>
>> wrote:
>>
>>> > Would it then still be necessary to restrict the annex to a maximum
>>> size?
>>>
>>> I think it's worth thinking about to protect the opt-in users, and can
>>> also be used for other anti-pinning efforts(though clearly not sufficient
>>> by itself for the many many pinning vectors we have :) )
>>>
>>
>> Thinking about the most restrictive policy that would still enable
>> annex-vaults (which I believe has great potential for improving bitcoin
>> custody) and is in line with work already done, I get to:
>>
>> * Opt-in annex (every input must commit to an annex even if its is empty)
>> -> make sure existing multi-party protocols remain unaffected
>> * Tlv format as defined in https://github.com/bitcoin/bips/pull/1381 ->
>> future extensibility
>> * Only allow tlv record 0 - unstructured data -> future extensibility
>> * Limit maximum size of the value to 256 bytes -> protect opt-in users
>>
>> Unfortunately the limit of 126 bytes in
>> https://github.com/bitcoin-inquisition/bitcoin/pull/22 isn't sufficient
>> for these types of vaults. If there are two presigned txes (unvault and
>> emergency), those signatures would already take up 2*64=128 bytes. Then you
>> also want to store 32 bytes for the ephemeral key itself as the key can't
>> be reconstructed from the schnorr signature. The remaining bytes could be
>> used for a third presigned tx and/or additional vault parameters.
>>
>> Can you think of remaining practical objections to making the annex
>> standard under the conditions listed above?
>>
>> Joost
>>
>>> _______________________________________________
> 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/20230618/e80a7213/attachment-0001.html>

2023-06-19 18:19:55

- reply

📅 Original date posted:2023-06-12
🗒️ Summary of this message: The Taproot annex has the advantage of not including its data in the calculation of txid, making it a powerful tool for applications that would use covenants. The proposal to adopt a simple approach to the Taproot annex is to avoid a potentially long standardization process, but a 2 phase process could be considered.
📝 Original message:
Hi Joost,
> However, the primary advantage I see in the annex is that its data isn't
included in the calculation of the txid or a potential parent commit
transaction's txid (for inscriptions). I've explained this at [1]. This
> feature makes the annex a powerful tool for applications that would
ideally use covenants.
I share the observation that the annex data not being committed in the
parent txid is very powerful for use-cases that would use covenants. E.g
there could be an alternative design of CoinPool based on Grafroot, where
the signed surrogate scripts authorized withdrawal abilities [0]. Once
consumed the signed surrogate shouldn't be replayable against the clawback
pool output, and the signature of the surrogate added as "toxic" in a
cryptographic accumulator. Efficient set test membership can be realized to
refuse pool output spend attempts with consumed surrogate scripts.
The annex is a perfect emplacement to locate such an accumulator in the
future as the state of the accumulator cannot be predicted as pool setup
time and is a function of the effective order withdrawal.
Note with Taproot-based design, the replay protection is achieved by the
removal from the taproot tree as edited by any contracting primitive during
the withdrawal phase (e.g TLUV).
> When it comes to the trade-offs associated with various encodings, I
fully acknowledge their existence. The primary motivation behind my
proposal to adopt a simple approach to the Taproot annex is to
> avoid a potentially long standardization process. While I am not entirely
familiar with the decision-making process of Bitcoin Core, my experience
with other projects suggests that simpler changes often
> encounter less resistance and can be implemented more swiftly. Perhaps I
am being overly cautious here, though.
I fully understand the motivation to avoid a lengthy standardization
process, which can be a source of frustration for everyone, including the
standard champions themselves. Indeed, no one lacks the bureaucratic-style
of standardization process for their own sake.
Long standardization processes in Bitcoin consensus are better explained by
the number of technical dimensions to weigh in terms of designs (e.g
full-nodes ressources scalability, fee economic costs, confidentiality,
composability with other changes). And due to the asynchronous nature of
FOSS development, every domain expert is constantly jungling between
different engineering contributions priorities (e.g for myself currently
package relay and mempool for L2s).
All that said, to make the conversation of annex standardization more
practical, and aiming to compose with all technical interest expressed, I
can think about a 2 phase process, at least.
Such standardization process reflects only my opinion, and is based on the
experience of recent mempool fullrbf partial deployment experience, the
Core's trends to have tracking issues for substantial changes,
bitcoin-inquisition and the bitcoin contracting primitives WG experiences.
Phase 1:
- a BIP proposal for the TLV records + code (almost done with #9 in
bitcoin-inquisition and #1421 in the bips repository)
- a BIP proposal to reserve "tag 0" for unstructured data + code (let's say
in bitcoin-inquisition)
- anti-DoS mempool/transaction-relay/replacement code (same)
- bonus point: documenting the new mempool/replacement rules like in Core's
`doc/policy`
- preferential peering logic working code (there is already some code with
Core's #25600)
- opt-in activation of the annex validation rules
- engage Bitcoin devs appreciated by the community as domain experts in the
covered areas to collect more relevant technical feedbacks
Phase 2:
- submit the annex branch with all the features on the Bitcoin Core
repository
- communicate to the Bitcoin technical community at large the existence of
the proposal e.g dev mail list, technical newsletters
- communicate to the second-layers and unstructured data application
maintainers the existence of the proposal
- integrate the feedback from Bitcoin Core, Bitcoin users and second-layers
communities in a "staging code branch"
- if there is a deep technical objection, go back to phase 1 (e.g a
competing serializing proposal for the annex)
- otherwise, split the annex reference branch core in logical chunks for
optimal review process
This is what an efficient-yet-decentralized standardization process of the
annex would look like to me, I don't know. About when we can expect a
deployment of new policy rules for the annex, as Dave made me the
(grounded) reprimand on the list a while back, I don't think mentioning a
date or software version release is appropriate. And this to avoid creating
a sense of commitment on all the contributors involved in the projects
above mentioned.
I'm still interested in championing the "base" TLV serialization annex code
and BIP. To move faster, I think it would be better to have another
champion on the "tag 0" and BIP, especially as the unstructured data
use-cases are coming with their own specifics.
> Regarding the potential payload extension attack, I believe that the
changes proposed in the [3] to allow tx replacement by smaller witnesses
would provide a viable solution?
To be honest, in terms of DoS, I wouldn't give a strong opinion before
better formalization or consensus of the use-case requirements. From
experience of Core's mempools PRs, you have few subcomponents that can be
involved (replacement, block template, broadcast backend of L2s, etc).
> That years-long timeline that you sketch for witness replacement (or any
other policy change I presume?) to become effective is perhaps indicative
of the need to have an alternative way to relay
> transactions to miners besides the p2p network?
Assuming an alternative p2p network, I don't think we can avoid some
standardization of fundamental data structures between those p2p network.
Most of L2s are pre-signing transactions/packages and might not be able to
alter the validity of such set of transactions in a unilateral fashion
without re-introducing some “bad” malleability. And a L2 node has an
interest to use multiple p2p networks to mitigate against things like
time-dilation attacks.
Best,
Antoine
[0]
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2018-February/015700.html
Le dim. 11 juin 2023 à 20:26, Joost Jager <joost.jager at gmail.com> a écrit :
> Hi Dave,
>
> On Sun, Jun 11, 2023 at 12:10 AM David A. Harding <dave at dtrt.org> wrote:
>
>> 3. When paying the script in #2, Alice chooses the scriptpath spend from
>> #1 and pushes a serialized partial signature for the ephemeral key
>> from #2 onto the stack, where it's immediately dropped by the
>> interpreter (but is permanently stored on the block chain). She also
>> attaches a regular signature for the OP_CHECKSIG opcode.
>>
>
> Isn't it the case that that op-dropped partial signature for the ephemeral
> key isn't committed to and thus can be modified by anyone before it is
> mined, effectively deleting the keys to the vault? If not, this would be a
> great alternative!
>
> Even better, I think you can achieve nearly the same safety without
>> putting any data on the chain. All you need is a widely used
>> decentralized protocol that allows anyone who can prove ownership of a
>> UTXO to store some data.
>>
>
> I appreciate the suggestion, but I am really looking for a bitcoin-native
> solution to leverage bitcoin's robustness and security properties.
>
> By comparison, rolling
>> out relay of the annex and witness replacement may take months of review
>> and years for >90% deployment among nodes, would allow an attacker to
>> lower the feerate of coinjoin-style transactions by up to 4.99%, would
>> allow an attacker to waste 8 million bytes of bandwidth per relay node
>> for the same cost they'd have to pay to today to waste 400 thousand
>> bytes, and might limit the flexibility and efficiency of future
>> consensus changes that want to use the annex.
>
>
> That years-long timeline that you sketch for witness replacement (or any
> other policy change I presume?) to become effective is perhaps indicative
> of the need to have an alternative way to relay transactions to miners
> besides the p2p network?
>
> I agree though that it would be ideal if there is a good solution that
> doesn't require any protocol changes or upgrade path.
>
> Joost
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20230612/4d095d65/attachment-0001.html>

2023-06-19 18:19:54

- reply

📅 Original date posted:2023-06-09
🗒️ Summary of this message: Proposal to define any taproot annex that begins with '0' as free-form, allowing immediate utilization and future flexibility for unstructured data use-cases.
📝 Original message:
Hi Joost,
Thanks for detailing why a '0' as free-form, without any additional
constraints offers valuable engineering properties as of today.
>From a taproot annex design perspective, I think this could be very
valuable if you have a list of unstructured data use-cases you're thinking
about ? As raised on the BIP proposal, those unstructured data use-cases
could use annex tags with the benefit to combine multiple "types" of
unstructured data in a single annex payload. As you're raising smaller bits
of unstructured data might not afford the overhead though my answer with
this observation would be to move this traffic towards some L2 systems ? In
my mind, the default of adding a version byte for the usage of unstructured
data comes with the downside of having future consensus enabled use-cases
encumbering by the extended witness economic cost.
About the annex payload extension attack described by Greg. If my
understanding of this transaction-relay jamming griefing issue is correct,
we can have an annex tag in the future where the signer is committing to
the total weight of the transaction, or even the max per-input annex size ?
This should prevent a coinjoin or aggregated commitment transaction
counterparty to inflate its annex space to downgrade the overall
transaction feerate, I guess. And I think this could benefit unstructured
data use-cases too.
Best,
Antoine
Le ven. 2 juin 2023 à 22:18, Joost Jager via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> a écrit :
> Hi,
>
> As it stands, the taproot annex is consensus valid but non-standard. The
> conversations around standardization seem to be leaning towards the
> adoption of a flexible Type-Length-Value (TLV) format [1]. There's no doubt
> that this approach has considerable potential. However, settling on an
> exact format may require a significant amount of time.
>
> In the interim, the benefits of making the annex available in a
> non-structured form are both evident and immediate. By allowing developers
> to utilize the taproot annex without delay, we can take advantage of its
> features today, without the need to wait for the finalization of a more
> lengthy standardization process.
>
> With this in view, I am proposing that we define any annex that begins
> with '0' as free-form, without any additional constraints. This strategy
> offers several distinct benefits:
>
> Immediate utilization: This opens the door for developers to make use of
> the taproot annex for a variety of applications straight away, thus
> eliminating the need to wait for the implementation of TLV or any other
> structured format.
>
> Future flexibility: Assigning '0'-beginning annexes as free-form keeps our
> options open for future developments and structure improvements. As we
> forge ahead in determining the best way to standardize the annex, this
> strategy ensures we do not limit ourselves by setting its structure in
> stone prematurely.
>
> Chainspace efficiency: Non-structured data may require fewer bytes
> compared to a probable TLV format, which would necessitate the encoding of
> length even when there's only a single field.
>
> In conclusion, adopting this approach will immediately broaden the
> utilization scope of the taproot annex while preserving the possibility of
> transitioning to a more structured format in the future. I believe this is
> a pragmatic and efficient route, one that can yield substantial benefits in
> both the short and long term.
>
> Joost
>
> [1] https://github.com/bitcoin/bips/pull/1381
> _______________________________________________
> 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/20230610/2249fe52/attachment.html>

2023-06-19 17:42:40

- reply

📅 Original date posted:2023-06-18
🗒️ Summary of this message: The proposed HTLC endorsement system for mitigating jamming attacks in Lightning Network lacks clarity on how fees compensate for damage inflicted. A formal definition of the problem and rigorous analysis is needed before deploying any half-baked solutions.
📝 Original message:
Hi,
> Bob can also forward but not endorse Alice's HTLC. All of this is a
function of how much credit Bob gives to Alice's judgment. In case of
jamming, the damage that Alice inflicts should be proportional to the
revenue she recently created for Bob, and so the more damage, the higher
the threshold.
> This system guarantees that if a node was jammed, it was paid a
significant some prior to the attack happening. There is no claim about who
is paying or the cost of the attack.
Sure, I understand that in case of an attack, a routing node should have
been paid a significant fee sum by the peer originating the jamming
traffic. However from my understanding this is unclear with the proposed
htlc endorsement system than the fees paid are fully economically
compensating the damage inflicted to the victim ? Or if it's a proportional
compensation, and if proportional the ratio between the fees and the
reputation is static or dynamic, and if dynamic which are the criterias of
evaluation ?
Note, outlawing the cost of the attack from the system guarantees sounds
contrary to the htlc endorsement design goal shown in your gist: "the goal
of this proposal is to produce a mitigation that has...a significant cost
to persistent attackers", or are the design goals proposed elsewhere ?
So I still don't know the precise problem to be solved by any jamming
mitigation, in a formal fashion, nor the correctness conditions required of
a solution. As far as I can tell, such information is not present in the
"unjamming lightning" paper (while the paper claims to "systematically
analyze the solution space" it does not formalize the problem, at least in
terms of abstract definition that holds independently of the solution
adopted).
I think there is still an undervaluation of how much the liquidity griefing
issues affecting Lightning and second-layers, of which jamming is only one,
is novel from the viewpoint of financial cryptography/computer security
literature. At the best, I think we should aim to evaluate the
effectiveness of any jamming solution with the same conceptual rigor as
modern cryptanalysis (understood notions like shannon cipher, perfect
security, switching lemma).
Without such rigor of analysis, I don't think we'll be able to give
"measurable" bounds to any solution, and know when there is a wreckage
because we're modifying some subtle parameters like channel opening
default, or the adversaries can access superior sources of information to
decide when to launch a jamming attack where the sum paid does _not_ cover
the operational cost of a routing hop.
I'm not pretending to have done the "cryptoeconomics-analysis" work for the
solution I'm proposing (staking credentials) or something like circuit
breaker. I just would like to underscore we should be quite cautious in
deploying half-baked mitigations, that might provoke more harm than relief
to routing node operators. Sorry not sorry if it's interpreted as a rant,
we have already enough broken stuff in Lightning...
> The reading on the channel liquidity can change for different users using
different routes, but the information a node gets is what liquidity is
available for them (and not the state of the channel in general). > This
indeed can fluctuate more than it does now, but so is the liquidity
available for a specific node.
So if you recognize that htlc endorsement can fluctuate the link-level
liquidity more than it does now, at the very least it would be good to come
with simulations on how it might downgrade HTLC routing traffic ?
Again on this last point, I would say intuitively any other proposed
jamming solution would come with downsides on the routing traffic succes,
though hard to say the trade-offs.
Best,
Antoine
Le mer. 31 mai 2023 à 21:21, Clara Shikhelman <clara.shikhelman at gmail.com>
a écrit :
> Hi,
>
>> 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.
>>
>> Bob can also forward but not endorse Alice's HTLC. All of this is a
> function of how much credit Bob gives to Alice's judgment. In case of
> jamming, the damage that Alice inflicts should be proportional to the
> revenue she recently created for Bob, and so the more damage, the higher
> the threshold.
>
>>
>> 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).
>>
>> This system guarantees that if a node was jammed, it was paid a
> significant some prior to the attack happening. There is no claim about who
> is paying or the cost of the attack.
>
> 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
>>
>>
> The reading on the channel liquidity can change for different users using
> different routes, but the information a node gets is what liquidity is
> available for them (and not the state of the channel in general). This
> indeed can fluctuate more than it does now, but so is the liquidity
> available for a specific node.
>
> Best,
> Clara
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20230619/c72c2452/attachment.html>

2023-06-19 17:42:38

- reply

📅 Original date posted:2023-05-24
🗒️ Summary of this message: A new framework called "Staking Credentials" has been introduced to mitigate jamming attacks on the Lightning Network. The framework uses privacy-preserving credentials to lock liquidity along the forwarding path and can also be used to mitigate other liquidity time-value DoS attacks. The protocol relies on basic mechanisms of the Lightning Network and introduces new abstractions such as credentials, scarce assets, requester/issuer entities, and client/provider entities. The protocol phases involve the discovery of credentials and service policies, committing a scarce asset, and verifying the proof and credentials.
📝 Original message:
Hi list,
As it has been discussed before, a solution to mitigate jamming
attacks over the Lightning Network consists in the introduction of
credentials that must be acquired by HTLC senders to lock each hop
liquidity along the forwarding path. Those credentials can be
privacy-preserving to mask the identity of the HTLC senders towards
the routing hops. They serve as a monetary hedge in case of default of
the HTLC sender on the payment of the routing fees.
As additional advantages, this credentials framework, dubbed "Staking
Credentials", can be deployed to mitigate other liquidity timevalue
DoS in the Lightning landscape, e.g collaborative transaction
construction or even beyond as an enhanced paywall to access Nostr
relay services [0].
This post gives an overview of the framework by detailing the key
concepts, laying out the protocol phases, showing concrete examples
and presenting the upsides and downsides of this mitigation approach
for jamming.
## Protocol Abstractions
The protocol relies on basic mechanisms of the Lightning Network such
as the onion messages, blinded paths where the sender doesn't know who
is the recipient and gossips, an information dissemination protocol
not relying on third-party.
Beyond, new abstractions are introduced:
- credentials: unique keys establishing attributes of the bearer,
those keys can be blinded [1].
- scarce assets: e.g a Bitcoin transaction, a Lightning payment,
chaumian ecash, UTXO ownership proofs.
- Requester/Issuer entities: the Requester requires from the Issuer
authentication of credentials in exchange for submitting scarce
assets.
- Client/Provider entities: the Client requires from the Provider a
service in exchange of submitting a credential.
## Protocol Phases
The first phase of the protocol is the discovery by a user of the
`credentials_policy` and `service_policy` gossips originating
respectively from Issuers and Providers. By reading the
`service_policy`, a user can discover the list of credentials Issuer a
target service Provider is relying on.
The user in the role of the Requester starts by committing a scarce
asset as announced by the Issuer's `credentials_policy`. E.g the
Requester sends a Bitcoin on-chain to a destination scriptPubkey
previously announced by the gossip mechanism. The user attaches the
scarce asset proof with a set of blinded credentials, finds an onion
path to the Issuer and sends the whole inside an onion message.
When the Issuer receives the scarce asset proofs and the set of
credentials, the proof is first verified e.g the on-chain payment must
be confirmed to a destination scriptPubkey controlled by the Issuer.
If the proof is correct and the scarce asset cost matches the quantity
of credentials as announced by `credentials_policy`, the blinded
credentials are countersigned by the Issuer and the signatures replied
back to the Requester by using a blinded path.
The Requester receives the Issuer signature and should verify they're
correct under the announced issuance public key in
`credentials_policy`. If they are valid, the credentials can be
unblinded and consumed for the satisfaction of a service or correct
the transactional asymmetries of a Bitcoin financial contract (e.g the
signature release for a dual-funding transaction).
Alternatively, the credentials usage can be delegated to another user
under the warning than for the second-user, there is no guarantee the
credential transfer is not double-spend.
The user in the role of the Client forwards the unblinded credentials
and the corresponding Issuer signatures to a target service Provider.
The service request can be protocol-specific and linked with the
credentials submission with a simple pair of identifiers (e.g a
32-byte random value). At reception by the Provider, the signatures on
the unblinded credentials must be verified against the corresponding
Issuance public key. The quantity of credentials must be equal to the
service units requested as announced by `service_policy`.
If those checks are correct, the Provider is satisfying the Client
service request, and additionally can provide back authentication
signatures for a new set of blinded credentials (optionally attached
in the service request issued by the Client).
## Example: Lightning jamming
Alice, the routing hop, cumulates in this deployment both the role of
Issuer and Provider. As an Issuer, she announces how much Lightning
satoshis she wishes to be paid to countersign a quantity of N
credentials in `credentials_policy`. As a Provider, she announces how
much credentials she wishes to allow a lockup of her 10_000 sats
Lightning channels for 100 blocks in `service_policy`.
Bob the HTLC sender discovers Alice's `credentials_policy`, sends a
Lightning payment to Alice and then collects a quantity of N signed
blinded credentials during a issuance dance with Alice. After this,
Bob can build a payment path going through Alice, where her hop's
onion `payload` includes an identifier Z. Bob transfers the signed
unblinded credentials with the same identifier Z through onion routing
to Alice node.
Alice node verifies the credentials with respect to her
`service_policy` for the forwarding of HTLC. If this is correct, the
HTLC is forward over her 10_000 sats Lightning channel. If the HTLC
settlement is successful, a new quantity of blinded credentials is
countersigned by Alice to reward Bob for the efficient usage of her
liquidity.
## Protocol Upsides
The credentials allows a service Provider to establish a dynamic
risk-management policy, where the submission of credentials is
disabled during the "peaceful" state and where credentials must bind
to 100% of the timevalue of the liquidity service in case of "war"
state. E.g for jamming, the cost of the credentials can match 100% of
the routing fees announced in `channel_update.
The blinding of the credentials should preserve the privacy of the
HTLC senders, therefore preventing deanonymization of the payments, or
selective censorship of the HTLC forward by a specific HTLC sender.
The credentials enable an emergent discount effect, where in case of
"honest" behavior of the Client in the usage of the service, they can
be rewarded by fresh credentials, therefore reducing the operational
cost of their future service usage.
The credentials framework should be generic enough to adapt to
multiple Bitcoin flows beyond HTLC forwarding, and the Lightning
jamming issue. Other flows of interest can be to cover the asymmetries
in collaborative transaction construction, e.g the order of the
release of the contributed UTXOs signatures. Qualitative credentials
could be deployed enabling bounded routing fees or SLA of liquidity
during periods of Lightning network congestion.
There is a Rust implementation in early progress, with a short-term
goal to have the full Staking Credential flow working in its
non-blinded version for a 1-hop payment path.
Cheers,
Antoine
[0] https://github.com/civkit/staking-credentials-spec
[1] https://sceweb.sce.uhcl.edu/yang/teaching/csci5234WebSecurityFall2011/Chaum-blind-signatures.PDF
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20230524/35f6e341/attachment.html>

2023-06-19 17:42:25

- reply

📅 Original date posted:2023-05-31
🗒️ Summary of this message: The distinction between routing fees and reputation revenue is important in the HTLC endorsement model. Compensation for revenue lost during an attack is given to nodes with high reputation. However, there may be issues with the coupling effect between routing scoring algorithms and the introduction of endorsement schemes.
📝 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>

2023-06-19 17:42:24

- reply

📅 Original date posted:2023-05-17
🗒️ Summary of this message: The Lightning Network's reputation system is vulnerable to sudden changes in behavior and pricing variations between hops, potentially allowing for reputation sacrifice and loss of routing fees. Dynamic reputation windows may also affect payment reliability.
📝 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>

2023-06-19 17:42:21

- reply

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

2023-06-19 17:42:06

- reply

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

2023-06-09 13:13:27

- reply

📅 Original date posted:2023-06-06
🗒️ Summary of this message: The Lightning Network may be vulnerable to liquidity griefing, where a counterparty locks up resources without paying fees. A "soft lock" strategy may not be enough to prevent this, and other solutions, such as the Staking Credentials framework, may need to be explored.
📝 Original message:
Hi Bastien,
> This can be fixed by using a "soft lock" when selecting utxos for a non
> 0-conf funding attempt. 0-conf funding attempts must ignore soft locked
> utxos while non 0-conf funding attempts can (should) reuse soft locked
> utxos.
If my understanding of the "soft lock" strategy is correct - Only locking
UTXO when it's a non 0-conf funding attempt - I think you're still exposed
to liquidity griefing with dual-funding or splicing.
The vector of griefing you're mentioning is the lack of signature release
for a shared input by your counterparty. However, in the context of
dual-funding where the counterparty can add any output with
`tx_add_output`, the transaction can be pinned in the mempool in a very
sneaky way e.g abuse of replacement rule 3.
This latter pinning vector is advantageous to the malicious counterparty as
I think you can batch your pinning against unrelated dual-funding, only
linked in the mempool by a malicious pinning CPFP.
It is left as an exercise to the reader to find other vectors of pinnings
that can be played out in the dual-funding flow.
In terms of (quick) solution to prevent liquidity griefing related to
mempool vectors, the (honest) counterparty can enforce that any contributed
outputs must be encumbered by a 1 CSV, unless being a 2-of-2 funding.
Still, this mitigation can be limited as I think the initial commitment
transaction must have anchor outputs on each-side, for each party to
recover its contributed UTXOs in any case.
> Then we immediately send `channel_ready` as well and start using that
> channel (because we know we won't double spend ourselves). This is nice
> because it lets us use 0-conf in a way where only one side of the
> channel needs to trust the other side (instead of both sides trusting
> each other).
>From the 0-conf initiator viewpoint (the one contributing the UTXO(s)), it
can still be valuable to disable inbound payments, or requires a longer
`cltv_expiry_delta` than usual, in case of mempool fee spikes delaying the
0-conf chain confirmation.
Beyond, it sounds liquidity griefing provoked by a lack of signature
release or mempool funny games will always be there ? Even for the second
with package relay/nVersion deployment, there is still the duration between
the pinning happening among network mempools and your replacement broadcast
kickstarts.
As a more long-term solution, we might reuse solutions worked out to
mitigate channel jamming, as the abstract problem is the same, namely your
counterparty can lock up scarce resources without (on-chain/off-chain
whatever) fees paid.
E.g the Staking Credentials framework could be deployed by dual-funding
market-makers beyond routing hops [0]. The dual-funding initiator should
pay to the maker a fee scale up on the amount of UTXOs contributed, and
some worst-case liquidity griefing scenario. A privacy-preserving
credential can be introduced between the payment of the fee and the redeem
of the service to unlink dual-funding initiators (if the maker has enough
volume to constitute a reasonable anonymity set).
Best,
Antoine
[0]
https://lists.linuxfoundation.org/pipermail/lightning-dev/2023-May/003964.html
Le sam. 6 mai 2023 à 04:15, Bastien TEINTURIER <bastien at acinq.fr> a écrit :
> Good morning list,
>
> One of the challenges created by the introduction of dual funded
> transactions [1] in lightning is how to protect against liquidity
> griefing attacks from malicious peers [2].
>
> Let's start by reviewing this liquidity griefing issue. The dual funding
> protocol starts by exchanging data about the utxos each peer adds to the
> shared transaction, then exchange signatures and broadcast the resulting
> transaction. If peers lock their utxos as soon as they've decided to add
> them to the shared transaction, the remote node may go silent. If that
> happens, the honest node has some liquidity that is locked and unusable.
>
> This cannot easily be fixed by simply unlocking utxos *after* detecting
> that the remote node is fishy, because the remote node would still have
> succeeded at locking your liquidity for a (small) duration, and could
> start other instances of that attack with different node_ids.
>
> An elegant solution to this issue is to never lock utxos used in dual
> funded transactions. If a remote node goes silent in the middle of an
> instance of the protocol, your utxos will automatically be re-used in
> another instance of the protocol. The only drawback with that approach
> is that when you have multiple concurrent instances of dual funding with
> honest peers, some of them may fail because they are double-spent by one
> of the concurrent instances. This is acceptable, since the protocol
> should complete fairly quickly when peers are honest, and at worst, it
> can simply be restarted when failure is detected.
>
> But that solution falls short when using 0-conf, because accidentally
> double-spending a 0-conf channel (because of concurrent instances) can
> result in loss of funds for one of the peers (if payments were made on
> that channel before detecting the double-spend). It seems like using
> 0-conf forces us to lock utxos to avoid this issue, which means that
> nodes offering 0-conf services expose themselves to liquidity griefing.
>
> Another related issue is that nodes that want to offer 0-conf channels
> must ensure that the utxos they use for 0-conf are isolated from the
> utxos they use for non 0-conf, otherwise it is not possible to properly
> lock utxos, because of the following race scenario:
>
> - utxoA is selected for a non 0-conf funding attempt and not locked
> (to protect against liquidity griefing)
> - utxoA is also selected for a 0-conf funding attempt (because it is
> found unlocked in the wallet) and then locked
> - the funding transaction for the 0-conf channel is successfully
> published first and that channel is instantly used for payments
> - the funding transaction for the non 0-conf channel is then published
> and confirms, accidentally double-spending the 0-conf channel
>
> This can be fixed by using a "soft lock" when selecting utxos for a non
> 0-conf funding attempt. 0-conf funding attempts must ignore soft locked
> utxos while non 0-conf funding attempts can (should) reuse soft locked
> utxos.
>
> In eclair, we are currently doing "opportunistic" 0-conf:
>
> - if we receive `channel_ready` immediately (which means that our peer
> trusts us to use 0-conf)
> - and we're the only contributor to the funding transaction (our peer
> doesn't have any input that they could use to double-spend)
> - and the transaction hasn't been RBF-ed yet
>
> Then we immediately send `channel_ready` as well and start using that
> channel (because we know we won't double spend ourselves). This is nice
> because it lets us use 0-conf in a way where only one side of the
> channel needs to trust the other side (instead of both sides trusting
> each other).
>
> Unfortunately, we cannot do that anymore when mixing 0-conf and non
> 0-conf funding attempts, because the utxos may be soft locked,
> preventing us from "upgrading" to 0-conf.
>
> You have successfully reached the end of this quite technical post,
> congrats! My goal with this post is to gather ideas on how we could
> improve that situation and offer good enough protections against
> liquidity griefing for nodes offering 0-conf services. Please share
> your ideas! And yes, I know, 0-conf is a massive implementation pain
> point that we would all like to remove from our codebases, but hey,
> users like it ¯\_(ツ)_/¯
>
> Cheers,
> Bastien
>
> [1] https://github.com/lightning/bolts/pull/851
> [2] https://github.com/lightning/bolts/pull/851#discussion_r997537630
> _______________________________________________
> 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/20230607/50378bc7/attachment.html>

2023-06-09 13:13:24

- reply

📅 Original date posted:2023-05-24
🗒️ Summary of this message: A new framework called "Staking Credentials" has been introduced to mitigate jamming attacks over the Lightning Network. The framework introduces credentials that must be acquired by HTLC senders to lock each hop liquidity along the forwarding path.
📝 Original message:
Hi list,
As it has been discussed before, a solution to mitigate jamming
attacks over the Lightning Network consists in the introduction of
credentials that must be acquired by HTLC senders to lock each hop
liquidity along the forwarding path. Those credentials can be
privacy-preserving to mask the identity of the HTLC senders towards
the routing hops. They serve as a monetary hedge in case of default of
the HTLC sender on the payment of the routing fees.
As additional advantages, this credentials framework, dubbed "Staking
Credentials", can be deployed to mitigate other liquidity timevalue
DoS in the Lightning landscape, e.g collaborative transaction
construction or even beyond as an enhanced paywall to access Nostr
relay services [0].
This post gives an overview of the framework by detailing the key
concepts, laying out the protocol phases, showing concrete examples
and presenting the upsides and downsides of this mitigation approach
for jamming.
## Protocol Abstractions
The protocol relies on basic mechanisms of the Lightning Network such
as the onion messages, blinded paths where the sender doesn't know who
is the recipient and gossips, an information dissemination protocol
not relying on third-party.
Beyond, new abstractions are introduced:
- credentials: unique keys establishing attributes of the bearer,
those keys can be blinded [1].
- scarce assets: e.g a Bitcoin transaction, a Lightning payment,
chaumian ecash, UTXO ownership proofs.
- Requester/Issuer entities: the Requester requires from the Issuer
authentication of credentials in exchange for submitting scarce
assets.
- Client/Provider entities: the Client requires from the Provider a
service in exchange of submitting a credential.
## Protocol Phases
The first phase of the protocol is the discovery by a user of the
`credentials_policy` and `service_policy` gossips originating
respectively from Issuers and Providers. By reading the
`service_policy`, a user can discover the list of credentials Issuer a
target service Provider is relying on.
The user in the role of the Requester starts by committing a scarce
asset as announced by the Issuer's `credentials_policy`. E.g the
Requester sends a Bitcoin on-chain to a destination scriptPubkey
previously announced by the gossip mechanism. The user attaches the
scarce asset proof with a set of blinded credentials, finds an onion
path to the Issuer and sends the whole inside an onion message.
When the Issuer receives the scarce asset proofs and the set of
credentials, the proof is first verified e.g the on-chain payment must
be confirmed to a destination scriptPubkey controlled by the Issuer.
If the proof is correct and the scarce asset cost matches the quantity
of credentials as announced by `credentials_policy`, the blinded
credentials are countersigned by the Issuer and the signatures replied
back to the Requester by using a blinded path.
The Requester receives the Issuer signature and should verify they're
correct under the announced issuance public key in
`credentials_policy`. If they are valid, the credentials can be
unblinded and consumed for the satisfaction of a service or correct
the transactional asymmetries of a Bitcoin financial contract (e.g the
signature release for a dual-funding transaction).
Alternatively, the credentials usage can be delegated to another user
under the warning than for the second-user, there is no guarantee the
credential transfer is not double-spend.
The user in the role of the Client forwards the unblinded credentials
and the corresponding Issuer signatures to a target service Provider.
The service request can be protocol-specific and linked with the
credentials submission with a simple pair of identifiers (e.g a
32-byte random value). At reception by the Provider, the signatures on
the unblinded credentials must be verified against the corresponding
Issuance public key. The quantity of credentials must be equal to the
service units requested as announced by `service_policy`.
If those checks are correct, the Provider is satisfying the Client
service request, and additionally can provide back authentication
signatures for a new set of blinded credentials (optionally attached
in the service request issued by the Client).
## Example: Lightning jamming
Alice, the routing hop, cumulates in this deployment both the role of
Issuer and Provider. As an Issuer, she announces how much Lightning
satoshis she wishes to be paid to countersign a quantity of N
credentials in `credentials_policy`. As a Provider, she announces how
much credentials she wishes to allow a lockup of her 10_000 sats
Lightning channels for 100 blocks in `service_policy`.
Bob the HTLC sender discovers Alice's `credentials_policy`, sends a
Lightning payment to Alice and then collects a quantity of N signed
blinded credentials during a issuance dance with Alice. After this,
Bob can build a payment path going through Alice, where her hop's
onion `payload` includes an identifier Z. Bob transfers the signed
unblinded credentials with the same identifier Z through onion routing
to Alice node.
Alice node verifies the credentials with respect to her
`service_policy` for the forwarding of HTLC. If this is correct, the
HTLC is forward over her 10_000 sats Lightning channel. If the HTLC
settlement is successful, a new quantity of blinded credentials is
countersigned by Alice to reward Bob for the efficient usage of her
liquidity.
## Protocol Upsides
The credentials allows a service Provider to establish a dynamic
risk-management policy, where the submission of credentials is
disabled during the "peaceful" state and where credentials must bind
to 100% of the timevalue of the liquidity service in case of "war"
state. E.g for jamming, the cost of the credentials can match 100% of
the routing fees announced in `channel_update.
The blinding of the credentials should preserve the privacy of the
HTLC senders, therefore preventing deanonymization of the payments, or
selective censorship of the HTLC forward by a specific HTLC sender.
The credentials enable an emergent discount effect, where in case of
"honest" behavior of the Client in the usage of the service, they can
be rewarded by fresh credentials, therefore reducing the operational
cost of their future service usage.
The credentials framework should be generic enough to adapt to
multiple Bitcoin flows beyond HTLC forwarding, and the Lightning
jamming issue. Other flows of interest can be to cover the asymmetries
in collaborative transaction construction, e.g the order of the
release of the contributed UTXOs signatures. Qualitative credentials
could be deployed enabling bounded routing fees or SLA of liquidity
during periods of Lightning network congestion.
There is a Rust implementation in early progress, with a short-term
goal to have the full Staking Credential flow working in its
non-blinded version for a 1-hop payment path.
Cheers,
Antoine
[0] https://github.com/civkit/staking-credentials-spec
[1] https://sceweb.sce.uhcl.edu/yang/teaching/csci5234WebSecurityFall2011/Chaum-blind-signatures.PDF
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20230524/35f6e341/attachment.html>

2023-06-09 13:13:20

- reply

📅 Original date posted:2023-05-31
🗒️ Summary of this message: The distinction between routing fees and reputation revenue is important in the HTLC endorsement model. Compensation for revenue lost during an attack is based on reputation revenue. However, there may be issues with the coupling effect between routing scoring algorithms and the introduction of endorsement schemes.
📝 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>

2023-06-09 13:13:19

- reply

📅 Original date posted:2023-05-17
🗒️ Summary of this message: The Lightning Network's reputation system is vulnerable to sudden changes in fees and behavior, making it susceptible to attacks and whitewashing.
📝 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>

2023-06-09 13:13:17

- reply

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

2023-06-09 13:13:09

- reply

📅 Original date posted:2023-05-10
🗒️ Summary of this message: Bitcoin developer defends his right to expose potential conflicts of interest and moral hazards in open-source development 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>

2023-06-09 13:13:01

- reply

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

2023-06-09 13:12:54

- reply

📅 Original date posted:2023-03-21
🗒️ Summary of this message: Bitcoin developer Antoine Riard received a cease and desist letter from law firm Jackson Lewis, claiming improper communications with Chaincode Labs employees. Riard is confused about the letter's authenticity and unclear on the allegations, and is considering seeking advice from the Bitcoin Legal Defense Fund, which is run by Chaincode Labs.
📝 Original message:
Hi all,
Last Tuesday 14th March, I did receive a letter from the law firm so-called
Jackson Lewis saying they represent Chaincode Labs about the subject of
"improper communications". Being a long-time Bitcoin developer and knowing
well of Chaincode Labs, I've been and I'm still very confused about this
letter's authenticity.
The letter is available here under MIT license:
https://github.com/ariard/chaincode-improper-communications
The sentences inside are quite unclear to me, especially not being an
English native. They say that I have to halt "all improper and
inappropriate communications with certain Chaincode employees". In the
past, I did find bugs and other issues in Bitcoin Core Github PRs of some
Chaincode folks, so I don't know if saying the code might be broken under
"inappropriate communications". They add "You agreed to do so" without
presenting old-school paperwork signatures or cryptographic ones or OTS
proofs of archived content, so it's a bit hard to know what to answer on.
Beyond that, they say I would have sent "unsolicited emails" to Chaincode
employees in February 2023. For sure, I've sent mails on the usual mailing
lists to which a lot of folks are contributing to. And some of those mails
were pointing to bitcoin technical shortcomings that might piss off people,
as always.
Then, they say my "conduct was improper '' without pointing to a precise
FOSS code of conduct. The thing is we don't have a code of conduct in
Bitcoin Core as there are a lot of legal uncertainties (from the recent
inquiry of Chaincode Labs itself iirc). The restraint on communications
tells nothing if it's scoping the confidential report of security flaws to
selected parties (among them potentially Chaincode folks), in order to
mitigate upcoming jeopardy of Bitcoin funds. Finally, the "any and all
legal actions" doesn't say if those actions can target open-source
communities and projects I might be involved with (like we're seeing Tari
Labs doing "legal actions" against LL and therefore impacting the wider
non-LL Taro community).
There are 2 more troubling issues. One, the title of the letter "Chaincode
Labs - Cease & Desist Letter to Antione Riard". I really received it like
this and checked the typo multiple times. I think my name is Antoine Riard,
I've to verify but I think so. So I don't know if the letter is legally
valid. Second, the lawyer issuing the letter sounds to be one specialist in
labor law, not really cryptocurrencies and FOSS software.
In the lack of sound legal advice on my side, I would say the default would
be to reach out to the Bitcoin Legal Defense Fund, which from my
understanding sounds to have a mission to provide guidance to developers
receiving legal intimidations in the pursuit of their open-source
activities. The thing is the Bitcoin Legal Defense Fund is run by Chaincode
Labs among others, so I wouldn't know if I could ask them for advice on an
issue at first sight involving them. Sounds a weird catch 22.
By advance my apologies to Chaincode Labs if I'm sharing a forgery or
non-authenticated document assigned to their organization. I believe in the
cases involving Tulip Trading Lawsuit there has been doubt on the quality
of the document produced, so a fool sending forgeries to developers to
throw confusion among the community is not to exclude. In anycase, I
believe it's better to seek community feedback on what to do about this
letter (and as such ccing all the lists!).
Cheers,
Antoine
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20230321/664f3420/attachment.html>

2023-06-09 13:12:51

- reply

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

2023-06-09 13:12:47

- reply

📅 Original date posted:2023-03-01
🗒️ Summary of this message: The use of onion messages (OMs) for payment probing in Lightning Network could be an alternative to HTLC probing. Routing hops could announce their liquidity balances with a new set of gossip messages, committing to a liquidity balance and duration, which could be guaranteed transparently from the rest of the network thanks to parallel channels. Any deviation from the gossip message could be penalized by sender's scoring algorithms.
📝 Original message:
Hi Val,
Thanks for the proposal here. About using OM for payment probing, I think
there could be an alternative of the routing hops themselves announcing
their liquidity balances with an extension or new set of gossip messages.
Gossips messages could commit to a liquidity balance and duration
(e.g +1000 blocks from tip), rather relying on sender-side probing, which
might be less and less accurate with higher rate of network liquidity
congestion. Additionally, a routing hop could commit to "private" gossip
sent back to HTLC senders during HTLC successful settlement. Those
"private" gossip might announce "differentiated services" of channel
liquidity levels. I believe this can be guaranteed transparently from the
rest of the network thanks to parallel channels.
Any deviation from the gossip message could be penalized by sender's
scoring algorithms as the liquidity SLA parameters have been announced
explicitly by the routing hops. This is just an intuition on how public
channel liquidity discovery could be worked out, and I don't know which of
the alternatives would be more efficient in terms of
bandwidth/convergence delays.
Best,
Antoine
Le lun. 27 févr. 2023 à 21:32, vwallace via Lightning-dev <
lightning-dev at lists.linuxfoundation.org> a écrit :
> Hi list!
>
> I wanted to bring up the idea of using onion messages for payment probing,
> which was briefly touched
> on at the 2022 LN summit. Tadge Dryja has also brought up a similar idea.
>
> I recommend reading the gist instead since it has the relevant diagrams
> in-line:
> https://gist.github.com/valentinewallace/ebe1741f0438c2360eda0f80f0e075c9
> but the scheme is also
> posted below for convenience.
>
> ## Introduction
>
> For context, in today’s lightning, payment reliability tends to heavily
> depend on having sufficient
> payment volume to determine current liquidity balances of channels, which
> is how most big nodes can
> tell whether a given channel has enough liquidity to forward a given
> amount. If a node is using HTLC
> probing to achieve this payment volume, they use a regular
> `update_add_htlc` message with a bogus
> payment hash, where the error returned informs the sender of whether the
> payment reached the final
> recipient. Note that there is a tradeoff between always routing through
> nodes that are known to
> rebalance their channels vs leaning on probing smaller nodes and “risking”
> payments through them
> based on what’s learned.
>
> Today’s HTLC payment probing can work well, but risks channel liquidity
> being locked up if a peer
> along the route goes offline. On the upside, for just-in-time probes, it
> works to loosely “reserve”
> the channel liquidity along the route for the actual payment.
>
> Onion messages (OMs) present a convenient way to probe without risking
> locked liquidity along the
> route.
>
> ## Design Rationale
>
> A naive approach could be to send onion message probes directly to
> individual nodes along the
> desired route, including those to which you don’t have a direct channel.
> However, this scheme is
> problematic because it would enable monitoring the payment flows of
> arbitrary nodes across the
> network without having to have a channel path to them. This would be a
> significant degradation of
> privacy because, for comparison, in HTLC probing it is quite difficult to
> probe the balances of
> far-off nodes. And if you can’t probe a node using HTLCs, you can’t send
> over it anyway, so there’s
> not a lot of benefit (and significant privacy downside).
>
> Therefore, it is probably best to design a scheme that probes along
> channel paths, like HTLC
> probing. This adds more complexity to the case where an intermediate node
> cannot forward the desired
> amount due to the stateless nature of OMs, discussed further down.
>
> ## Scheme
>
> Let’s go through the happy path, where Alice is probing Alice > Bob >
> Carol > Dave for a 100k msat
> payment.
>
> She’ll construct an onion message for Bob, the first hop, as such:
> https://imgur.com/BZg8yt8
>
> Bob receives this OM, sees that he’s able to forward 110k msats to his
> next-hop Carol, and forwards
> Carol’s onion packet to her. Carol sees she can forward 105k msats to
> Dave, and forwards his onion
> packet. Finally, Dave receives his onion packet, sees he can receive 100k
> msats from Carol, and uses
> the provided reply path to send a simple probe success onion message back
> to Alice:
>
> ```
> onion_message_probe_result {
> data_tlv {
> type: 4242,
> probe_id: [u8; 32],
> can_forward_desired_amt: true,
> }
> .. regular OM TLVs
> }
> ```
>
> Note that Dave will use this same onion message if he can’t receive; he’ll
> just set
> `can_forward_desired_amt` to false.
>
> As an example of the sad path for an intermediate node, if Carol can’t
> forward 105k msats to Dave,
> she’ll fail the probe back to Bob by sending this onion message:
> https://imgur.com/a/hqlzw4I
>
> This step justifies why we need to encode a failure onion for each
> intermediate hop of a probe. If
> we hadn’t done that, and Carol responded to Bob with an empty “failed”
> message, Bob would have no
> idea which peer to fail the probe back to, because OMs are stateless.
> Instead, Bob unwraps his error
> onion and sees that he needs to fail back to Alice with her provided error
> onion. Alice receives the
> failure onion and can see that Carol was not able to forward the desired
> amount corresponding to the
> probe id, thus completing the probe.
>
> ## Outro
>
> While there is nothing stopping nodes from lying about their ability to
> forward, they may be
> negatively scored if they do so. Further, adopting a protocol like this
> could help routing nodes
> attract more forwarding traffic, which is a nice incentive.
>
> I view this feature as a low priority enhancement, given there are a lot
> more pressing issues in LN,
> but open to feedback. Mostly, I thought it could be useful to spark ideas
> and highlight the
> flexibility of OMs.
>
> Cheers,
> Val
> _______________________________________________
> 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/20230301/756791ad/attachment.html>

2023-06-09 13:12:42

- reply

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

2023-06-09 13:12:42

- reply

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

2023-06-09 13:12:41

- reply

📅 Original date posted:2023-02-16
🗒️ Summary of this message: Matt Corallo and Joost Jager discuss the challenges of maintaining outbound liquidity in highly available lightning channels, and the need for reliable scoring data.
📝 Original message:
Yeah definitely looking forward to talk more about highly available
lightning channels. During next LN channel jamming meetup! .
Le jeu. 16 févr. 2023 à 00:43, Matt Corallo <lf-lists at mattcorallo.com> a
écrit :
>
>
> On 2/14/23 11:36 PM, Joost Jager wrote:
> > But how do you decide to set it without a credit relationship? Do I
> measure my channel and set the
> >
> > bit because the channel is "usually" (at what threshold?) saturating
> in the inbound direction? What
> > happens if this changes for an hour and I get unlucky? Did I just
> screw myself?
> >
> >
> > As a node setting the flag, you'll have to make sure you open new
> channels, rebalance or swap-in in
> > time to maintain outbound liquidity. That's part of the game of running
> an HA channel.
>
> Define "in time" in a way that results in senders not punishing you for
> not meeting your "HA
> guarantees" due to a large flow. I don't buy that this results in anything
> other than pressure to
> add credit.
>
> > > How can you be sure about this? This isn't publicly visible data.
> >
> > Sure it is! https://river.com/learn/files/river-lightning-report.pdf
> > <https://river.com/learn/files/river-lightning-report.pdf>
> >
> >
> > Some operators publish data, but are the experiences of one of the most
> well connected (custodial)
> > nodes representative for the network as a whole when evaluating payment
> success rates? In the end
> > you can't know what's happening on the lightning network.
>
> 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.
>
> Once we do that, everyone gets a similar experience as the River report :).
>
> Matt
> _______________________________________________
> 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/a4c356bf/attachment.html>

2023-06-09 13:12:35

- reply

📅 Original date posted:2023-01-31
🗒️ Summary of this message: Upgrading Lightning network for channel jamming mitigation may require network-wide cooperation, and incentivizing nodes to upgrade may be challenging. Privacy concerns also arise.
📝 Original message:
Hi Clara,
(Reply 1/2 - Apparently there is a limit of 80KB on Lightning mailing post)
> * They will likely require a network wide upgrade: when a sender
> makes a payment, the full path will need to understand the new
> feature bit for it to be used.
I believe the upgradeability dimension is different both for circuit breaker
and staking credentials -- Circuit breaker is a point-level deployment and
can be rolled out without cooperation of the channel peers. Staking
credentials is end-to-end and just requires cooperation between endpoints
(HTLC senders and routing hops, not even all on the payment paths).
And I think upfront fees is a link-level one, probably the one requesting the
most cooperation between the community of developers/node operators.
Point-to-point/end-to-end deployment already provides benefits with
"half-state"
deployment, I think. However, you might have "holistic" beneficial effects
of link-level solutions (in terms of economic engineering not in terms of
software compatibility), I don't know.
> * Sending nodes are unlikely to be incentivised to upgrade to
> support a channel jamming mitigation, as jamming mitigations incur
> additional cost (be it in the form of upfront fees, tokens or some
> other mechanism).
As with any "unpatched" security risks we're encumbering on Lightning
(pinnings, time-dilation, etc), beyond clearly describing the attack in
reference documents and proof-of-concept of the attack against
implementations, the next step to keep raising awareness is a live demo as
much near as one can from really mainet conditions. While we were patching
CVE-2021-41591 and friends, I've been testing the solidity of the fixes on
the Eclair-side in a "black-box" manner. Always worth it, you learn on the
attack bounds.
We could do the same with jamming attacks, as there is a wide-range of
scenarios
to consider (network-wide/merchant/routing hops) and few optimizations
tricks like looping. Just have to be super careful with any demo exploits
toolchain, there is always a question of ethics here.
> * Routing nodes have no way of knowing whether a payment comes from
> a node that is not upgraded, or simply doesn't want to pay the
> additional cost introduced by a jamming mitigation.
I think a routing node able to know if the payment sender has upgraded could
constitute a version/implementation fingerprint and a downgrade in HTLC traffic
privacy, ideally a routing node should not be able to link payeer/payee.
If a sender does not want to pay the jamming mitigation cost, it might be a
flaw in the incentive-compatibility benefit of a mitigation.
(And in terms of evaluating the
incentives-compatibility/economic-efficiency of any solution, we're going
to run quickly in hard questions of economic methodology, a bit beyond the
software engineering realm).
> It was generally agreed that the network is still in an early enough
> stage that it is fair for relaying nodes to initially upgrade but not
> enforce the feature, and later look at forwarding traffic to determine
> whether it is appropriate to require the feature.
If we look at the recent history of mempool policy upgrades on the
Bitcoin Core-side,
I think it's best practice to be more conservative in terms of "smooth
feature" deployment, even feature-gated beyond some node operator setting. At
time of feature enforcement, some node operators might claim an established
claim on other flows of HTLC traffic, and there would be a question of
backward-compatibility arising.
Independently, there is the fact on how discrepancies in feature activation
could be exploited (privacy-wise or economically-wise). Same issue we have
on the Bitcoin Core-side, when we update the mempool policy, and old nodes
might not see new types of outputs (e.g Taproot spends being non-standard
before the activation iirc).
> This will require sending nodes to opt-in to the new feature before the
network can
> widely enforce it, as no rational routing node will require a feature
> which would reduce its ability to serve un-upgraded traffic (unless
> under attack, which is not the case at present).
I think the corollary holds -- A rational routing node will not require a
feature which would reduce its ability to serve upgraded traffic.
Note, I think the "rational" routing node could be better defined,
otherwise I think we'll run quickly in the same bottlenecked discussions
about "policy rules" compatible with miners incentives, as we're seeing on
the Core-side. So far, I don't think we have a consistent model of miners
incentives.
> A note was also made that wallets tend to upgrade less frequently, in
> part because some providers run forked versions of LN implementations,
> so this horizon may be quite long. It was emphasized that this type of
> network upgrade would require input from wallets, designers and
> application developers anyway, so hopefully by the time we look to
> deploy a change there is rough consensus among the Lightning community
> already.
Yeah, we have the same issues with transaction-relay/mempool policy or even the
non-really specified addr-relay strategy of Bitcoin Core, when there is
an upgrade there. It sounds to me there are no well-maintained public and open
communication channels where protocol developers can reach out to
wallet softwares
vendors for protocol upgrades feedback (and vice-versa). I don't know if
it's one goal of the LSP spec effort. If you're building a wallet, you're
probably going to assemble and maintain components from the two layers.
> * Nodes can advertise custom upfront fee rates if desired, but to
> save gossip bandwidth we assume a network-wide default of 1%.
I think you will have an additional issue here. The routing convergence delay
network-wide might be a bottleneck in how much fee rate variances you have
flexibility as a routing node operator. Routing convergence delays have
been studied in the past at 2,500 seconds for the worst-audience, I don't
think it's going to hold with network graph growth.
> * Upfront fees accumulate along the route (as htlc payment amounts
> do), and are simply pushed to the `to_remote` balance on
> `update_add_htlc`.
I wonder if there is a concern of an "upfront fee" extraction issue at the
channel-level. You have Alice and you have Bob, Bob circular loop to
accumulate max `upfront_fee` on his `to_remote` balance on Alice's commitment
transaction. Then provoke a force-close by Alice to have her paying the
on-chain fees in the post-anchor output model.
There can be an interesting "upfront fees" siphoning issue here.
> The interaction between upfront fees and possible future protocol
> changes such as inbound fees and negative fees was briefly discussed,
> specifically the case where a node sets low (or negative) fees to
> attract traffic then fails payments to accumulate upfront fees. As is,
> all implementations’ algorithms optimize for factors other than fees -
> specifically avoiding a node once it's produced failures - and we
> suspect that careful sender-side behavior will mitigate this risk.
> However, it was also acknowledged that a node that attempts this attack
> may be able to fool multiple individual senders and still be able to
> accumulate some fees.
Correcting upfront fees abuses sounds simple as long as you assume the scoring
is done by the endpoint. When you start to have gossip and routing scoring
delegation, you might be hijacked by an "accumulating fees" adversary. E.g,
one could sybil the rapid-gossip-sync servers, if their deployment becomes
ubiquitous [1]. Same issue with Electrum servers lack of incentives
alignment.
> However, Bob has no real incentive to forward the HTLC to Carol and
> push her the 4100 msat because that value is more than the fees he'll
> earn from successfully forwarding and settling the HTLC (10 msat
> upfront fees + 1000 msat success case fees). It's worth noting that
> this type of fee differential already exists in the network today - I
> got these example numbers by looking at the fee rates of the Loop
> node's peers [4].
Yes, "fee differential" issues have been discussed affecting upfront fees and
all the hold fees variants in the past. I'm not sure they're acceptable fee
risks, if you can exploit them by setting correctly the channel
topologies around
a victim routing hop.
End of 1/2.
[0]
https://lists.linuxfoundation.org/pipermail/lightning-dev/2022-May/003594.html
[1] https://github.com/lightningdevkit/rapid-gossip-sync-server
Le lun. 30 janv. 2023 à 15:25, Carla Kirk-Cohen <kirkcohenc at gmail.com> a
écrit :
> Hi list,
>
> On Monday last week we resumed our fortnightly channel jamming
> mitigation calls for 2023.
>
> Details for the next call:
> * Monday 02/06 @ 18:00 UTC
> * https://meet.jit.si/UnjammingLN
> * Agenda: https://github.com/ClaraShk/LNJamming/issues/2
>
> # Meeting Summary
> This email attempts to summarize the discussion, but is of course
> subject to my errors and opinions so the full transcript is available
> at [1]. It is (imperfectly) AI generated, so please reach out to myself
> or Clara if you'd like clarification for a specific section.
>
> 1. Upgrade Mechanisms
> The first topic of discussion was around how we would go about
> upgrading the network to support an anti-jamming mitigation. Most
> solutions share the following characteristics:
> * They will likely require a network wide upgrade: when a sender
> makes a payment, the full path will need to understand the new
> feature bit for it to be used.
> * Sending nodes are unlikely to be incentivised to upgrade to
> support a channel jamming mitigation, as jamming mitigations incur
> additional cost (be it in the form of upfront fees, tokens or some
> other mechanism).
> * Routing nodes have no way of knowing whether a payment comes from
> a node that is not upgraded, or simply doesn't want to pay the
> additional cost introduced by a jamming mitigation.
>
> It was generally agreed that the network is still in an early enough
> stage that it is fair for relaying nodes to initially upgrade but not
> enforce the feature, and later look at forwarding traffic to determine
> whether it is appropriate to require the feature. This will require
> sending nodes to opt-in to the new feature before the network can
> widely enforce it, as no rational routing node will require a feature
> which would reduce its ability to serve un-upgraded traffic (unless
> under attack, which is not the case at present).
>
> A note was also made that wallets tend to upgrade less frequently, in
> part because some providers run forked versions of LN implementations,
> so this horizon may be quite long. It was emphasized that this type of
> network upgrade would require input from wallets, designers and
> application developers anyway, so hopefully by the time we look to
> deploy a change there is rough consensus among the Lightning community
> already.
>
> 2. Upfront Fees
> Next, we discussed the draft proposal for upfront fees [2] that
> implements the first of a two-part jamming mitigation described in [3].
> As it stands, the PR describes the simplest possible way to introduce
> upfront fees to the protocol:
> * Upfront fees are expressed as a ppm of a channel's success-case
> fees, and charged on the outgoing link of a route.
> * Nodes can advertise custom upfront fee rates if desired, but to
> save gossip bandwidth we assume a network-wide default of 1%.
> * Upfront fees accumulate along the route (as htlc payment amounts
> do), and are simply pushed to the `to_remote` balance on
> `update_add_htlc`.
> * Final hop nodes advertise an upfront fee policy in bolt 11 invoices
> (or bolt 12 blinded routes) which is sufficiently padded to
> obfuscate their location in the route.
>
> The interaction between upfront fees and possible future protocol
> changes such as inbound fees and negative fees was briefly discussed,
> specifically the case where a node sets low (or negative) fees to
> attract traffic then fails payments to accumulate upfront fees. As is,
> all implementations’ algorithms optimize for factors other than fees -
> specifically avoiding a node once it's produced failures - and we
> suspect that careful sender-side behavior will mitigate this risk.
> However, it was also acknowledged that a node that attempts this attack
> may be able to fool multiple individual senders and still be able to
> accumulate some fees.
>
> We then discussed the shortcomings of the "simplest possible" upfront
> fees in [2], specifically focused on the following scenario where
> nodes receive 1% of their success-case fees as an upfront payment:
> * Alice is sending a payment to Dave, who is a popular sink node in
> the network.
> * Bob -> Carol has low/default routing policy: 1000 msat success
> case / 10 msat upfront fee
> * Carol -> Dave has high fees: 400,000 msat success case / 4000 msat
> upfront fee
> * Dave advertises no success case fee (is recipient) / 100 msat of
> upfront fee chosen for his invoice.
>
> Alice ------ Bob ------ Carol ------ Dave
>
> Since we need to source all of these funds from the sender (Alice), the
> forwarding of funds is as follows:
> * Alice pushes 4110 msat to Bob.
> * Bob _should_ push 4100 msat to Carol, claiming his 10 msat upfront
> fee.
> * Carol _should_ push 100 msat to Dave, claiming her 4000 msat
> upfront fee.
>
> However, Bob has no real incentive to forward the HTLC to Carol and
> push her the 4100 msat because that value is more than the fees he'll
> earn from successfully forwarding and settling the HTLC (10 msat
> upfront fees + 1000 msat success case fees). It's worth noting that
> this type of fee differential already exists in the network today - I
> got these example numbers by looking at the fee rates of the Loop
> node's peers [4].
>
> There were a few points discussed around this issue:
> * Whether we should look into a more complicated approach that
> includes a "proof of forward" secret in the next node's onion which
> must be supplied to claim the upfront fee.
> * Discussion about whether these order of magnitude fee differences
> will exist in an efficient market (differing opinions).
> * Whether Bob _would_ steal the upfront fee by dropping the payment,
> as it'll impact nodes' desire to route through them in future.
> * Is there a way to deliver upfront fees to nodes along the route
> *without* them adding up along the route (other than the naive
> version of sending each hop a payment, which comes with its own
> problems)? Seems not, but bright ideas are wanted and welcome!
> * That nodes will decide where they fall in the trade-off of setting
> upfront fees to cover their opportunity cost for high routing fees
> and market pressure to keep these fees low for the sake of
> remaining competitive.
>
> A few people mentioned the desire to keep an upfront fee solution as
> simple as possible, but generally it seemed that a solution where the
> accumulated upfront fees at any point along a route exceed any single
> hop's expected success case fees is unacceptable because incentives
> are misaligned (even if we can properly attribute errors with [5]).
>
> We touched briefly on a few "proof of forwarding" solutions for
> upfront fees:
> * Using a locking mechanism that relies on a secret that is provided
> by the next node's onion.
> * A taproot tree for all HTLCs where each leaf has a subset of HTLCs,
> and fees could be incorporated here (summary note: apparently some
> work has been done here, but I couldn't find the link).
> * If we're confident that a more complicated solution will solve many
> problems, then we should pursue them, otherwise a simple solution
> is possibly a _good enough_ first step.
>
> There was some discussion about how we want to go about addressing
> spamming in the network:
> * Is it good enough to deploy something today that just charges a
> simple, capped upfront fee (eg 1 sat per hop) that solves jamming
> for the current state of the network and allows us to learn
> something then iterate?
> * Should our first attempt at solving this issue be for a future
> steady state where nodes have significant traffic and nodes face
> real opportunity cost (in the form of lost revenue) if they are
> targeted by a jamming attack?
>
> 3. Circuit Breaker Update
> * Circuit breaker has a UI now, and some issues are being opened in
> the repo so people have at minimum gone through the effort to spin
> it up.
> * It's still pretty manual, but it does provide node operators with
> information about the payment failures on their nodes (not easily
> surfaced in many LN UIs).
> * Hoping to get insights into stuck HTLCs and spam HTLCs so that we
> can learn from real life experience.
> * Circuit breaker is generally pushing in the same direction as the
> reputation scheme in [3], just a more manual one. We could
> possibly use it to visualize the endorsement system in [3] before
> enforcing it.
> * While circuit breaker isn't necessarily *the* solution to solving
> jamming on LN, it provides us with some data points and a
> practical way for individual operators to address spamming of
> their nodes.
>
> 3. Tokens Update
> Since our last discussion an architecture document was added to the
> proposal [6], details in the mailing list post [7]. The main goal is
> to try to dissociate the people paying the fees from those gaining the
> benefits from the credentials, so that credentials can be paid by a
> LSP (for example).
>
> 4. Reputation discussions in LSP Specification
> Some attendees have been working on a reputation system for the LSP
> specification group [8]. This system is intended to provide standard
> metrics about what makes a node good/bad to connect to in the context
> of a decentralized marketplace. While this work looks at the problem
> from a different perspective, there's a possibility to consolidate
> the efforts. It seems particularly useful in the anti-jamming case
> where a node has newly connected to you, and needs a "start state"
> reputation score. The idea of defining what qualifies as good
> behavior in the Lightning Network is useful across the board. The
> LSP specification group also has bi-weekly calls, and welcomes
> additional participants!
>
> 5. Call Cadence
> Attendees agreed to continue with calls every two weeks. General
> consensus was that we would aim for a 30 minute meeting with the
> option to extend to an hour if discussion warrants it.
>
> # What's next
> Thanks to everyone who attended last week's meeting, we hope to see
> more folks in the next one!
>
> There's a lot to discuss - brave readers who made it all the way to
> the bottom of this email will notice a fair number of question marks
> scattered about - and we're going to continue to break the problem
> down into smaller parts to discuss in the hope of making progress.
>
> Any change to the Lightning Network that aims to address channel
> jamming attacks will be a significant (but necessary) change to the
> protocol, and it's going to need input from many different
> stakeholders. Please reach out here or in private
> (carla at chaincode.com / clara at chaincode.com) if you have any questions
> / concerns / comments!
>
> Cheers until next time,
> Carla and Clara
> (Yes, our names are confusing. No, you won't get used to it)
>
> [1]
> https://github.com/ClaraShk/LNJamming/blob/main/meeting-transcripts/23-01-23-transcript.md
> [2] https://github.com/lightning/bolts/pull/1052
> [3] https://eprint.iacr.org/2022/1454.pdf
> [4]
> https://mempool.space/lightning/node/021c97a90a411ff2b10dc2a8e32de2f29d2fa49d41bfbb52bd416e460db0747d0d
> [5] https://github.com/lightning/bolts/pull/1044
> [6] https://github.com/lightning/bolts/pull/1043
> [8] https://github.com/BitcoinAndLightningLayerSpecs/lsp/issues/12
> _______________________________________________
> 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/20230131/bbef78be/attachment-0001.html>

2023-06-09 13:12:35

- reply

📅 Original date posted:2023-01-31
🗒️ Summary of this message: The Lightning Network faces challenges with upfront fees, including the risk of theft and adding up along the route, but potential solutions are being explored.
📝 Original message:
(Reply 2/2)
> * Whether we should look into a more complicated approach that
> includes a "proof of forward" secret in the next node's onion which
> must be supplied to claim the upfront fee.
One of the hard things with a "proof of forward" is a hop colluding with
the next counterparty in way non-provable to the HTLC sender. I don't think
more reliable onion errors will save the mechanism, as you might always
masquerade your routing node offliness (sure -- it might be penalized by
routing algorithms still probably a period of grace exploitable)
> * Whether Bob _would_ steal the upfront fee by dropping the payment,
> as it'll impact nodes' desire to route through them in future.
And if you have "floating" upfront fees to adjust to routing node
opportunity cost and the routing algorithms historical buckets are not
correcting the variations, a "upfront fee" adversary might be able to steal
the amount, in a proportion not corrected by the penalty.
> * Is there a way to deliver upfront fees to nodes along the route
> *without* them adding up along the route (other than the naive
> version of sending each hop a payment, which comes with its own
> problems)? Seems not, but bright ideas are wanted and welcome!
I think the latest update of the Staking Credentials could answer such
description
of "delivering the upfront fees to nodes along the route *without* them
adding up along the route" as the credential issuance is separated from its
redemption.
On a few other ideas, "magically" teleporting the fee payment to the
routing hops, it has been browsed in the past [2].
> * That nodes will decide where they fall in the trade-off of setting
> upfront fees to cover their opportunity cost for high routing fees
> and market pressure to keep these fees low for the sake of
> remaining competitive.
They will probably need to do real-time monitoring of the congestion rates
and outcome results of their HTLC forwarding to adjust in consequence their
routing fees.
> * A taproot tree for all HTLCs where each leaf has a subset of HTLCs,
> and fees could be incorporated here (summary note: apparently some
> work has been done here, but I couldn't find the link).
The idea of summing up the taproot tree for all HTLCs is discussed here
with past references [3]. I don't know if it's really a viable direction,
as aggregating the claim of HTLCs of different values in the same witness
claims might open the door to transaction-relay games.
> * If we're confident that a more complicated solution will solve many
> problems, then we should pursue them, otherwise a simple solution
> is possibly a _good enough_ first step.
If the "proof of forward" can be solved by "magic" covenant is still an open
issue. I don't know if it's a viable solution as it's more a hard synchronicity
issue between chain of contracts. However from exploring issue we might
learn interesting design considerations for contracting protocols (at the
very least some semi-formal proof it's not possible)
> * Should our first attempt at solving this issue be for a future
> steady state where nodes have significant traffic and nodes face
> real opportunity cost (in the form of lost revenue) if they are
> targeted by a jamming attack?
Deferring the most economically-efficient solution we can come from, we might
run into a bunch of incentives-misallignment between generation of nodes
operators and Lightning use-cases. Maybe same as we have seen with lack of
transaction replacement, first-seen RBF, opt-in RBF, mempoolfullrbf, I
believe.
On the other-side, the deployment of a simple solution would enable us to
start to build a consistent model of how the economics of channel
congestion, that we can "transpose" for more advanced solutions (ideally --
all other things being equal).
> * While circuit breaker isn't necessarily *the* solution to solving
> jamming on LN, it provides us with some data points and a
> practical way for individual operators to address spamming of
> their nodes.
As mentioned above, it sounds like the congestion monitoring and HTLCs
resolution tracking is going to be a standard task among LN
implementations, and that you'll would probably need a piece of
infrastructure like circuit breaker for all implementations.
> Since our last discussion an architecture document was added to the
> proposal [6], details in the mailing list post [7]. The main goal is
> to try to dissociate the people paying the fees from those gaining the
> benefits from the credentials, so that credentials can be paid by a
> LSP (for example).
I think there is a missing footnote, I believe the mail thread might have
been this one:
https://lists.linuxfoundation.org/pipermail/lightning-dev/2023-January/003822.html
Beyond delegation as mentioned, there are few other design goals targeted:
- strong economic-efficiency due to credentials accumulation
- fungibility of their credentials between their issuance and redemption
- dynamic-management of liquidity risks
- contract-agnostic (e.g can cover dual-opening)
Probably, we'll have the credential issuance flow and extension gossip more
speced out before next meetings.
> 4. Reputation discussions in LSP Specification
> Some attendees have been working on a reputation system for the LSP
> specification group [8]. This system is intended to provide standard
> metrics about what makes a node good/bad to connect to in the context
> of a decentralized marketplace. While this work looks at the problem
> from a different perspective, there's a possibility to consolidate
> the efforts. It seems particularly useful in the anti-jamming case
> where a node has newly connected to you, and needs a "start state"
> reputation score. The idea of defining what qualifies as good
> behavior in the Lightning Network is useful across the board. The
> LSP specification group also has bi-weekly calls, and welcomes
> additional participants!
Effectively, I think distributed market infrastructure design could benefit
from the lessons of the Lightning Network. It could be fruitful for the LSP
specification group to have its own mailing list at some point in the
future.
> There's a lot to discuss - brave readers who made it all the way to
> the bottom of this email will notice a fair number of question marks
> scattered about - and we're going to continue to break the problem
> down into smaller parts to discuss in the hope of making progress.
Beyond archiving well the problem space, there is also an effort of
documenting well any protocol design decisions to preserve future
evolvability and achieve interoperabilitybetween implementations.
> Any change to the Lightning Network that aims to address channel
> jamming attacks will be a significant (but necessary) change to the
> protocol
For sure, this is a significant change to the protocol, beyond that we
should be careful to not downgrade the throughput or operations of the
base-layer. If the original Stakes Certificates would have been
implemented, it would have constituted a mempool congestion risk, where the
node operators under jamming would have forced attackers to pay for fresh
UTXOs. If we have to envision such cross-layer mitigation design in the
future, I think we might have to do cross-layer consensus building.
Best,
Antoine
[2] https://jamming-dev.github.io/book/4-design_space.html
[3] https://github.com/ariard/bitcoin-contracting-primitives-wg/issues/26
[4]
https://lists.linuxfoundation.org/pipermail/lightning-dev/2020-November/002884.html
Le lun. 30 janv. 2023 à 15:25, Carla Kirk-Cohen <kirkcohenc at gmail.com> a
écrit :
> Hi list,
>
> On Monday last week we resumed our fortnightly channel jamming
> mitigation calls for 2023.
>
> Details for the next call:
> * Monday 02/06 @ 18:00 UTC
> * https://meet.jit.si/UnjammingLN
> * Agenda: https://github.com/ClaraShk/LNJamming/issues/2
>
> # Meeting Summary
> This email attempts to summarize the discussion, but is of course
> subject to my errors and opinions so the full transcript is available
> at [1]. It is (imperfectly) AI generated, so please reach out to myself
> or Clara if you'd like clarification for a specific section.
>
> 1. Upgrade Mechanisms
> The first topic of discussion was around how we would go about
> upgrading the network to support an anti-jamming mitigation. Most
> solutions share the following characteristics:
> * They will likely require a network wide upgrade: when a sender
> makes a payment, the full path will need to understand the new
> feature bit for it to be used.
> * Sending nodes are unlikely to be incentivised to upgrade to
> support a channel jamming mitigation, as jamming mitigations incur
> additional cost (be it in the form of upfront fees, tokens or some
> other mechanism).
> * Routing nodes have no way of knowing whether a payment comes from
> a node that is not upgraded, or simply doesn't want to pay the
> additional cost introduced by a jamming mitigation.
>
> It was generally agreed that the network is still in an early enough
> stage that it is fair for relaying nodes to initially upgrade but not
> enforce the feature, and later look at forwarding traffic to determine
> whether it is appropriate to require the feature. This will require
> sending nodes to opt-in to the new feature before the network can
> widely enforce it, as no rational routing node will require a feature
> which would reduce its ability to serve un-upgraded traffic (unless
> under attack, which is not the case at present).
>
> A note was also made that wallets tend to upgrade less frequently, in
> part because some providers run forked versions of LN implementations,
> so this horizon may be quite long. It was emphasized that this type of
> network upgrade would require input from wallets, designers and
> application developers anyway, so hopefully by the time we look to
> deploy a change there is rough consensus among the Lightning community
> already.
>
> 2. Upfront Fees
> Next, we discussed the draft proposal for upfront fees [2] that
> implements the first of a two-part jamming mitigation described in [3].
> As it stands, the PR describes the simplest possible way to introduce
> upfront fees to the protocol:
> * Upfront fees are expressed as a ppm of a channel's success-case
> fees, and charged on the outgoing link of a route.
> * Nodes can advertise custom upfront fee rates if desired, but to
> save gossip bandwidth we assume a network-wide default of 1%.
> * Upfront fees accumulate along the route (as htlc payment amounts
> do), and are simply pushed to the `to_remote` balance on
> `update_add_htlc`.
> * Final hop nodes advertise an upfront fee policy in bolt 11 invoices
> (or bolt 12 blinded routes) which is sufficiently padded to
> obfuscate their location in the route.
>
> The interaction between upfront fees and possible future protocol
> changes such as inbound fees and negative fees was briefly discussed,
> specifically the case where a node sets low (or negative) fees to
> attract traffic then fails payments to accumulate upfront fees. As is,
> all implementations’ algorithms optimize for factors other than fees -
> specifically avoiding a node once it's produced failures - and we
> suspect that careful sender-side behavior will mitigate this risk.
> However, it was also acknowledged that a node that attempts this attack
> may be able to fool multiple individual senders and still be able to
> accumulate some fees.
>
> We then discussed the shortcomings of the "simplest possible" upfront
> fees in [2], specifically focused on the following scenario where
> nodes receive 1% of their success-case fees as an upfront payment:
> * Alice is sending a payment to Dave, who is a popular sink node in
> the network.
> * Bob -> Carol has low/default routing policy: 1000 msat success
> case / 10 msat upfront fee
> * Carol -> Dave has high fees: 400,000 msat success case / 4000 msat
> upfront fee
> * Dave advertises no success case fee (is recipient) / 100 msat of
> upfront fee chosen for his invoice.
>
> Alice ------ Bob ------ Carol ------ Dave
>
> Since we need to source all of these funds from the sender (Alice), the
> forwarding of funds is as follows:
> * Alice pushes 4110 msat to Bob.
> * Bob _should_ push 4100 msat to Carol, claiming his 10 msat upfront
> fee.
> * Carol _should_ push 100 msat to Dave, claiming her 4000 msat
> upfront fee.
>
> However, Bob has no real incentive to forward the HTLC to Carol and
> push her the 4100 msat because that value is more than the fees he'll
> earn from successfully forwarding and settling the HTLC (10 msat
> upfront fees + 1000 msat success case fees). It's worth noting that
> this type of fee differential already exists in the network today - I
> got these example numbers by looking at the fee rates of the Loop
> node's peers [4].
>
> There were a few points discussed around this issue:
> * Whether we should look into a more complicated approach that
> includes a "proof of forward" secret in the next node's onion which
> must be supplied to claim the upfront fee.
> * Discussion about whether these order of magnitude fee differences
> will exist in an efficient market (differing opinions).
> * Whether Bob _would_ steal the upfront fee by dropping the payment,
> as it'll impact nodes' desire to route through them in future.
> * Is there a way to deliver upfront fees to nodes along the route
> *without* them adding up along the route (other than the naive
> version of sending each hop a payment, which comes with its own
> problems)? Seems not, but bright ideas are wanted and welcome!
> * That nodes will decide where they fall in the trade-off of setting
> upfront fees to cover their opportunity cost for high routing fees
> and market pressure to keep these fees low for the sake of
> remaining competitive.
>
> A few people mentioned the desire to keep an upfront fee solution as
> simple as possible, but generally it seemed that a solution where the
> accumulated upfront fees at any point along a route exceed any single
> hop's expected success case fees is unacceptable because incentives
> are misaligned (even if we can properly attribute errors with [5]).
>
> We touched briefly on a few "proof of forwarding" solutions for
> upfront fees:
> * Using a locking mechanism that relies on a secret that is provided
> by the next node's onion.
> * A taproot tree for all HTLCs where each leaf has a subset of HTLCs,
> and fees could be incorporated here (summary note: apparently some
> work has been done here, but I couldn't find the link).
> * If we're confident that a more complicated solution will solve many
> problems, then we should pursue them, otherwise a simple solution
> is possibly a _good enough_ first step.
>
> There was some discussion about how we want to go about addressing
> spamming in the network:
> * Is it good enough to deploy something today that just charges a
> simple, capped upfront fee (eg 1 sat per hop) that solves jamming
> for the current state of the network and allows us to learn
> something then iterate?
> * Should our first attempt at solving this issue be for a future
> steady state where nodes have significant traffic and nodes face
> real opportunity cost (in the form of lost revenue) if they are
> targeted by a jamming attack?
>
> 3. Circuit Breaker Update
> * Circuit breaker has a UI now, and some issues are being opened in
> the repo so people have at minimum gone through the effort to spin
> it up.
> * It's still pretty manual, but it does provide node operators with
> information about the payment failures on their nodes (not easily
> surfaced in many LN UIs).
> * Hoping to get insights into stuck HTLCs and spam HTLCs so that we
> can learn from real life experience.
> * Circuit breaker is generally pushing in the same direction as the
> reputation scheme in [3], just a more manual one. We could
> possibly use it to visualize the endorsement system in [3] before
> enforcing it.
> * While circuit breaker isn't necessarily *the* solution to solving
> jamming on LN, it provides us with some data points and a
> practical way for individual operators to address spamming of
> their nodes.
>
> 3. Tokens Update
> Since our last discussion an architecture document was added to the
> proposal [6], details in the mailing list post [7]. The main goal is
> to try to dissociate the people paying the fees from those gaining the
> benefits from the credentials, so that credentials can be paid by a
> LSP (for example).
>
> 4. Reputation discussions in LSP Specification
> Some attendees have been working on a reputation system for the LSP
> specification group [8]. This system is intended to provide standard
> metrics about what makes a node good/bad to connect to in the context
> of a decentralized marketplace. While this work looks at the problem
> from a different perspective, there's a possibility to consolidate
> the efforts. It seems particularly useful in the anti-jamming case
> where a node has newly connected to you, and needs a "start state"
> reputation score. The idea of defining what qualifies as good
> behavior in the Lightning Network is useful across the board. The
> LSP specification group also has bi-weekly calls, and welcomes
> additional participants!
>
> 5. Call Cadence
> Attendees agreed to continue with calls every two weeks. General
> consensus was that we would aim for a 30 minute meeting with the
> option to extend to an hour if discussion warrants it.
>
> # What's next
> Thanks to everyone who attended last week's meeting, we hope to see
> more folks in the next one!
>
> There's a lot to discuss - brave readers who made it all the way to
> the bottom of this email will notice a fair number of question marks
> scattered about - and we're going to continue to break the problem
> down into smaller parts to discuss in the hope of making progress.
>
> Any change to the Lightning Network that aims to address channel
> jamming attacks will be a significant (but necessary) change to the
> protocol, and it's going to need input from many different
> stakeholders. Please reach out here or in private
> (carla at chaincode.com / clara at chaincode.com) if you have any questions
> / concerns / comments!
>
> Cheers until next time,
> Carla and Clara
> (Yes, our names are confusing. No, you won't get used to it)
>
> [1]
> https://github.com/ClaraShk/LNJamming/blob/main/meeting-transcripts/23-01-23-transcript.md
> [2] https://github.com/lightning/bolts/pull/1052
> [3] https://eprint.iacr.org/2022/1454.pdf
> [4]
> https://mempool.space/lightning/node/021c97a90a411ff2b10dc2a8e32de2f29d2fa49d41bfbb52bd416e460db0747d0d
> [5] https://github.com/lightning/bolts/pull/1044
> [6] https://github.com/lightning/bolts/pull/1043
> [8] https://github.com/BitcoinAndLightningLayerSpecs/lsp/issues/12
> _______________________________________________
> 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/20230131/e171e031/attachment-0001.html>

2023-06-09 13:12:34

- reply

📅 Original date posted:2023-01-31
🗒️ Summary of this message: Upgrading the Lightning Network to mitigate channel jamming may require a network-wide upgrade, but sending nodes may not be incentivized to upgrade. Routing nodes may not know if a payment comes from an un-upgraded node.
📝 Original message:
Hi Clara,
> * They will likely require a network wide upgrade: when a sender
> makes a payment, the full path will need to understand the new
> feature bit for it to be used.
I believe the upgradeability dimension is different both for circuit breaker
and staking credentials -- Circuit breaker is a point-level deployment and
can be rolled out without cooperation of the channel peers. Staking
credentials is end-to-end and just requires cooperation between endpoints
(HTLC senders and routing hops, not even all on the payment paths).
And I think upfront fees is a link-level one, probably the one requesting the
most cooperation between the community of developers/node operators.
Point-to-point/end-to-end deployment already provides benefits with
"half-state"
deployment, I think. However, you might have "holistic" beneficial effects
of link-level solutions (in terms of economic engineering not in terms of
software compatibility), I don't know.
> * Sending nodes are unlikely to be incentivised to upgrade to
> support a channel jamming mitigation, as jamming mitigations incur
> additional cost (be it in the form of upfront fees, tokens or some
> other mechanism).
As with any "unpatched" security risks we're encumbering on Lightning
(pinnings, time-dilation, etc), beyond clearly describing the attack in
reference documents and proof-of-concept of the attack against
implementations, the next step to keep raising awareness is a live demo as
much near as one can from really mainet conditions. While we were patching
CVE-2021-41591 and friends, I've been testing the solidity of the fixes on
the Eclair-side in a "black-box" manner. Always worth it, you learn on the
attack bounds.
We could do the same with jamming attacks, as there is a wide-range of
scenarios
to consider (network-wide/merchant/routing hops) and few optimizations
tricks like looping. Just have to be super careful with any demo exploits
toolchain, there is always a question of ethics here.
> * Routing nodes have no way of knowing whether a payment comes from
> a node that is not upgraded, or simply doesn't want to pay the
> additional cost introduced by a jamming mitigation.
I think a routing node able to know if the payment sender has upgraded could
constitute a version/implementation fingerprint and a downgrade in HTLC traffic
privacy, ideally a routing node should not be able to link payeer/payee.
If a sender does not want to pay the jamming mitigation cost, it might be a
flaw in the incentive-compatibility benefit of a mitigation.
(And in terms of evaluating the
incentives-compatibility/economic-efficiency of any solution, we're going
to run quickly in hard questions of economic methodology, a bit beyond the
software engineering realm).
> It was generally agreed that the network is still in an early enough
> stage that it is fair for relaying nodes to initially upgrade but not
> enforce the feature, and later look at forwarding traffic to determine
> whether it is appropriate to require the feature.
If we look at the recent history of mempool policy upgrades on the
Bitcoin Core-side,
I think it's best practice to be more conservative in terms of "smooth
feature" deployment, even feature-gated beyond some node operator setting. At
time of feature enforcement, some node operators might claim an established
claim on other flows of HTLC traffic, and there would be a question of
backward-compatibility arising.
Independently, there is the fact on how discrepancies in feature activation
could be exploited (privacy-wise or economically-wise). Same issue we have
on the Bitcoin Core-side, when we update the mempool policy, and old nodes
might not see new types of outputs (e.g Taproot spends being non-standard
before the activation iirc).
> This will require sending nodes to opt-in to the new feature before the
network can
> widely enforce it, as no rational routing node will require a feature
> which would reduce its ability to serve un-upgraded traffic (unless
> under attack, which is not the case at present).
I think the corollary holds -- A rational routing node will not require a
feature which would reduce its ability to serve upgraded traffic.
Note, I think the "rational" routing node could be better defined,
otherwise I think we'll run quickly in the same bottlenecked discussions
about "policy rules" compatible with miners incentives, as we're seeing on
the Core-side. So far, I don't think we have a consistent model of miners
incentives.
> A note was also made that wallets tend to upgrade less frequently, in
> part because some providers run forked versions of LN implementations,
> so this horizon may be quite long. It was emphasized that this type of
> network upgrade would require input from wallets, designers and
> application developers anyway, so hopefully by the time we look to
> deploy a change there is rough consensus among the Lightning community
> already.
Yeah, we have the same issues with transaction-relay/mempool policy or even the
non-really specified addr-relay strategy of Bitcoin Core, when there is
an upgrade there. It sounds to me there are no well-maintained public and open
communication channels where protocol developers can reach out to
wallet softwares
vendors for protocol upgrades feedback (and vice-versa). I don't know if
it's one goal of the LSP spec effort. If you're building a wallet, you're
probably going to assemble and maintain components from the two layers.
> * Nodes can advertise custom upfront fee rates if desired, but to
> save gossip bandwidth we assume a network-wide default of 1%.
I think you will have an additional issue here. The routing convergence delay
network-wide might be a bottleneck in how much fee rate variances you have
flexibility as a routing node operator. Routing convergence delays have
been studied in the past at 2,500 seconds for the worst-audience, I don't
think it's going to hold with network graph growth.
> * Upfront fees accumulate along the route (as htlc payment amounts
> do), and are simply pushed to the `to_remote` balance on
> `update_add_htlc`.
I wonder if there is a concern of an "upfront fee" extraction issue at the
channel-level. You have Alice and you have Bob, Bob circular loop to
accumulate max `upfront_fee` on his `to_remote` balance on Alice's commitment
transaction. Then provoke a force-close by Alice to have her paying the
on-chain fees in the post-anchor output model.
There can be an interesting "upfront fees" siphoning issue here.
> The interaction between upfront fees and possible future protocol
> changes such as inbound fees and negative fees was briefly discussed,
> specifically the case where a node sets low (or negative) fees to
> attract traffic then fails payments to accumulate upfront fees. As is,
> all implementations’ algorithms optimize for factors other than fees -
> specifically avoiding a node once it's produced failures - and we
> suspect that careful sender-side behavior will mitigate this risk.
> However, it was also acknowledged that a node that attempts this attack
> may be able to fool multiple individual senders and still be able to
> accumulate some fees.
Correcting upfront fees abuses sounds simple as long as you assume the scoring
is done by the endpoint. When you start to have gossip and routing scoring
delegation, you might be hijacked by an "accumulating fees" adversary. E.g,
one could sybil the rapid-gossip-sync servers, if their deployment becomes
ubiquitous [1]. Same issue with Electrum servers lack of incentives
alignment.
> However, Bob has no real incentive to forward the HTLC to Carol and
> push her the 4100 msat because that value is more than the fees he'll
> earn from successfully forwarding and settling the HTLC (10 msat
> upfront fees + 1000 msat success case fees). It's worth noting that
> this type of fee differential already exists in the network today - I
> got these example numbers by looking at the fee rates of the Loop
> node's peers [4].
Yes, "fee differential" issues have been discussed affecting upfront fees and
all the hold fees variants in the past. I'm not sure they're acceptable fee
risks, if you can exploit them by setting correctly the channel
topologies around
a victim routing hop.
> * Whether we should look into a more complicated approach that
> includes a "proof of forward" secret in the next node's onion which
> must be supplied to claim the upfront fee.
One of the hard things with a "proof of forward" is a hop colluding with
the next counterparty in way non-provable to the HTLC sender. I don't think
more reliable onion errors will save the mechanism, as you might always
masquerade your routing node offliness (sure -- it might be penalized by
routing algorithms still probably a period of grace exploitable)
> * Whether Bob _would_ steal the upfront fee by dropping the payment,
> as it'll impact nodes' desire to route through them in future.
And if you have "floating" upfront fees to adjust to routing node
opportunity cost and the routing algorithms historical buckets are not
correcting the variations, a "upfront fee" adversary might be able to steal
the amount, in a proportion not corrected by the penalty.
> * Is there a way to deliver upfront fees to nodes along the route
> *without* them adding up along the route (other than the naive
> version of sending each hop a payment, which comes with its own
> problems)? Seems not, but bright ideas are wanted and welcome!
I think the latest update of the Staking Credentials could answer such
description
of "delivering the upfront fees to nodes along the route *without* them
adding up along the route" as the credential issuance is separated from its
redemption.
On a few other ideas, "magically" teleporting the fee payment to the
routing hops, it has been browsed in the past [2].
> * That nodes will decide where they fall in the trade-off of setting
> upfront fees to cover their opportunity cost for high routing fees
> and market pressure to keep these fees low for the sake of
> remaining competitive.
They will probably need to do real-time monitoring of the congestion rates
and outcome results of their HTLC forwarding to adjust in consequence their
routing fees.
> * A taproot tree for all HTLCs where each leaf has a subset of HTLCs,
> and fees could be incorporated here (summary note: apparently some
> work has been done here, but I couldn't find the link).
The idea of summing up the taproot tree for all HTLCs is discussed here
with past references [3]. I don't know if it's really a viable direction,
as aggregating the claim of HTLCs of different values in the same witness
claims might open the door to transaction-relay games.
> * If we're confident that a more complicated solution will solve many
> problems, then we should pursue them, otherwise a simple solution
> is possibly a _good enough_ first step.
If the "proof of forward" can be solved by "magic" covenant is still an open
issue. I don't know if it's a viable solution as it's more a hard synchronicity
issue between chain of contracts. However from exploring issue we might
learn interesting design considerations for contracting protocols (at the
very least some semi-formal proof it's not possible)
> * Should our first attempt at solving this issue be for a future
> steady state where nodes have significant traffic and nodes face
> real opportunity cost (in the form of lost revenue) if they are
> targeted by a jamming attack?
Deferring the most economically-efficient solution we can come from, we might
run into a bunch of incentives-misallignment between generation of nodes
operators and Lightning use-cases. Maybe same as we have seen with lack of
transaction replacement, first-seen RBF, opt-in RBF, mempoolfullrbf, I
believe.
On the other-side, the deployment of a simple solution would enable us to
start to build a consistent model of how the economics of channel
congestion, that we can "transpose" for more advanced solutions (ideally --
all other things being equal).
> * While circuit breaker isn't necessarily *the* solution to solving
> jamming on LN, it provides us with some data points and a
> practical way for individual operators to address spamming of
> their nodes.
As mentioned above, it sounds like the congestion monitoring and HTLCs
resolution tracking is going to be a standard task among LN
implementations, and that you'll would probably need a piece of
infrastructure like circuit breaker for all implementations.
> Since our last discussion an architecture document was added to the
> proposal [6], details in the mailing list post [7]. The main goal is
> to try to dissociate the people paying the fees from those gaining the
> benefits from the credentials, so that credentials can be paid by a
> LSP (for example).
I think there is a missing footnote, I believe the mail thread might have
been this one:
https://lists.linuxfoundation.org/pipermail/lightning-dev/2023-January/003822.html
Beyond delegation as mentioned, there are few other design goals targeted:
- strong economic-efficiency due to credentials accumulation
- fungibility of their credentials between their issuance and redemption
- dynamic-management of liquidity risks
- contract-agnostic (e.g can cover dual-opening)
Probably, we'll have the credential issuance flow and extension gossip more
speced out before next meetings.
> 4. Reputation discussions in LSP Specification
> Some attendees have been working on a reputation system for the LSP
> specification group [8]. This system is intended to provide standard
> metrics about what makes a node good/bad to connect to in the context
> of a decentralized marketplace. While this work looks at the problem
> from a different perspective, there's a possibility to consolidate
> the efforts. It seems particularly useful in the anti-jamming case
> where a node has newly connected to you, and needs a "start state"
> reputation score. The idea of defining what qualifies as good
> behavior in the Lightning Network is useful across the board. The
> LSP specification group also has bi-weekly calls, and welcomes
> additional participants!
Effectively, I think distributed market infrastructure design could benefit
from the lessons of the Lightning Network. It could be fruitful for the LSP
specification group to have its own mailing list at some point in the
future.
> There's a lot to discuss - brave readers who made it all the way to
> the bottom of this email will notice a fair number of question marks
> scattered about - and we're going to continue to break the problem
> down into smaller parts to discuss in the hope of making progress.
Beyond archiving well the problem space, there is also an effort of
documenting well any protocol design decisions to preserve future
evolvability and achieve interoperability between implementations.
> Any change to the Lightning Network that aims to address channel
> jamming attacks will be a significant (but necessary) change to the
> protocol
For sure, this is a significant change to the protocol, beyond that we
should be careful to not downgrade the throughput or operations of the
base-layer. If the original Stakes Certificates would have been
implemented, it would have constituted a mempool congestion risk, where the
node operators under jamming would have forced attackers to pay for fresh
UTXOs. If we have to envision such cross-layer mitigation design in the
future, I think we might have to do cross-layer consensus building.
Best,
Antoine
[0]
https://lists.linuxfoundation.org/pipermail/lightning-dev/2022-May/003594.html
[1] https://github.com/lightningdevkit/rapid-gossip-sync-server
[2] https://jamming-dev.github.io/book/4-design_space.html
[3] https://github.com/ariard/bitcoin-contracting-primitives-wg/issues/26
[4]
https://lists.linuxfoundation.org/pipermail/lightning-dev/2020-November/002884.html
Le lun. 30 janv. 2023 à 15:25, Carla Kirk-Cohen <kirkcohenc at gmail.com> a
écrit :
> Hi list,
>
> On Monday last week we resumed our fortnightly channel jamming
> mitigation calls for 2023.
>
> Details for the next call:
> * Monday 02/06 @ 18:00 UTC
> * https://meet.jit.si/UnjammingLN
> * Agenda: https://github.com/ClaraShk/LNJamming/issues/2
>
> # Meeting Summary
> This email attempts to summarize the discussion, but is of course
> subject to my errors and opinions so the full transcript is available
> at [1]. It is (imperfectly) AI generated, so please reach out to myself
> or Clara if you'd like clarification for a specific section.
>
> 1. Upgrade Mechanisms
> The first topic of discussion was around how we would go about
> upgrading the network to support an anti-jamming mitigation. Most
> solutions share the following characteristics:
> * They will likely require a network wide upgrade: when a sender
> makes a payment, the full path will need to understand the new
> feature bit for it to be used.
> * Sending nodes are unlikely to be incentivised to upgrade to
> support a channel jamming mitigation, as jamming mitigations incur
> additional cost (be it in the form of upfront fees, tokens or some
> other mechanism).
> * Routing nodes have no way of knowing whether a payment comes from
> a node that is not upgraded, or simply doesn't want to pay the
> additional cost introduced by a jamming mitigation.
>
> It was generally agreed that the network is still in an early enough
> stage that it is fair for relaying nodes to initially upgrade but not
> enforce the feature, and later look at forwarding traffic to determine
> whether it is appropriate to require the feature. This will require
> sending nodes to opt-in to the new feature before the network can
> widely enforce it, as no rational routing node will require a feature
> which would reduce its ability to serve un-upgraded traffic (unless
> under attack, which is not the case at present).
>
> A note was also made that wallets tend to upgrade less frequently, in
> part because some providers run forked versions of LN implementations,
> so this horizon may be quite long. It was emphasized that this type of
> network upgrade would require input from wallets, designers and
> application developers anyway, so hopefully by the time we look to
> deploy a change there is rough consensus among the Lightning community
> already.
>
> 2. Upfront Fees
> Next, we discussed the draft proposal for upfront fees [2] that
> implements the first of a two-part jamming mitigation described in [3].
> As it stands, the PR describes the simplest possible way to introduce
> upfront fees to the protocol:
> * Upfront fees are expressed as a ppm of a channel's success-case
> fees, and charged on the outgoing link of a route.
> * Nodes can advertise custom upfront fee rates if desired, but to
> save gossip bandwidth we assume a network-wide default of 1%.
> * Upfront fees accumulate along the route (as htlc payment amounts
> do), and are simply pushed to the `to_remote` balance on
> `update_add_htlc`.
> * Final hop nodes advertise an upfront fee policy in bolt 11 invoices
> (or bolt 12 blinded routes) which is sufficiently padded to
> obfuscate their location in the route.
>
> The interaction between upfront fees and possible future protocol
> changes such as inbound fees and negative fees was briefly discussed,
> specifically the case where a node sets low (or negative) fees to
> attract traffic then fails payments to accumulate upfront fees. As is,
> all implementations’ algorithms optimize for factors other than fees -
> specifically avoiding a node once it's produced failures - and we
> suspect that careful sender-side behavior will mitigate this risk.
> However, it was also acknowledged that a node that attempts this attack
> may be able to fool multiple individual senders and still be able to
> accumulate some fees.
>
> We then discussed the shortcomings of the "simplest possible" upfront
> fees in [2], specifically focused on the following scenario where
> nodes receive 1% of their success-case fees as an upfront payment:
> * Alice is sending a payment to Dave, who is a popular sink node in
> the network.
> * Bob -> Carol has low/default routing policy: 1000 msat success
> case / 10 msat upfront fee
> * Carol -> Dave has high fees: 400,000 msat success case / 4000 msat
> upfront fee
> * Dave advertises no success case fee (is recipient) / 100 msat of
> upfront fee chosen for his invoice.
>
> Alice ------ Bob ------ Carol ------ Dave
>
> Since we need to source all of these funds from the sender (Alice), the
> forwarding of funds is as follows:
> * Alice pushes 4110 msat to Bob.
> * Bob _should_ push 4100 msat to Carol, claiming his 10 msat upfront
> fee.
> * Carol _should_ push 100 msat to Dave, claiming her 4000 msat
> upfront fee.
>
> However, Bob has no real incentive to forward the HTLC to Carol and
> push her the 4100 msat because that value is more than the fees he'll
> earn from successfully forwarding and settling the HTLC (10 msat
> upfront fees + 1000 msat success case fees). It's worth noting that
> this type of fee differential already exists in the network today - I
> got these example numbers by looking at the fee rates of the Loop
> node's peers [4].
>
> There were a few points discussed around this issue:
> * Whether we should look into a more complicated approach that
> includes a "proof of forward" secret in the next node's onion which
> must be supplied to claim the upfront fee.
> * Discussion about whether these order of magnitude fee differences
> will exist in an efficient market (differing opinions).
> * Whether Bob _would_ steal the upfront fee by dropping the payment,
> as it'll impact nodes' desire to route through them in future.
> * Is there a way to deliver upfront fees to nodes along the route
> *without* them adding up along the route (other than the naive
> version of sending each hop a payment, which comes with its own
> problems)? Seems not, but bright ideas are wanted and welcome!
> * That nodes will decide where they fall in the trade-off of setting
> upfront fees to cover their opportunity cost for high routing fees
> and market pressure to keep these fees low for the sake of
> remaining competitive.
>
> A few people mentioned the desire to keep an upfront fee solution as
> simple as possible, but generally it seemed that a solution where the
> accumulated upfront fees at any point along a route exceed any single
> hop's expected success case fees is unacceptable because incentives
> are misaligned (even if we can properly attribute errors with [5]).
>
> We touched briefly on a few "proof of forwarding" solutions for
> upfront fees:
> * Using a locking mechanism that relies on a secret that is provided
> by the next node's onion.
> * A taproot tree for all HTLCs where each leaf has a subset of HTLCs,
> and fees could be incorporated here (summary note: apparently some
> work has been done here, but I couldn't find the link).
> * If we're confident that a more complicated solution will solve many
> problems, then we should pursue them, otherwise a simple solution
> is possibly a _good enough_ first step.
>
> There was some discussion about how we want to go about addressing
> spamming in the network:
> * Is it good enough to deploy something today that just charges a
> simple, capped upfront fee (eg 1 sat per hop) that solves jamming
> for the current state of the network and allows us to learn
> something then iterate?
> * Should our first attempt at solving this issue be for a future
> steady state where nodes have significant traffic and nodes face
> real opportunity cost (in the form of lost revenue) if they are
> targeted by a jamming attack?
>
> 3. Circuit Breaker Update
> * Circuit breaker has a UI now, and some issues are being opened in
> the repo so people have at minimum gone through the effort to spin
> it up.
> * It's still pretty manual, but it does provide node operators with
> information about the payment failures on their nodes (not easily
> surfaced in many LN UIs).
> * Hoping to get insights into stuck HTLCs and spam HTLCs so that we
> can learn from real life experience.
> * Circuit breaker is generally pushing in the same direction as the
> reputation scheme in [3], just a more manual one. We could
> possibly use it to visualize the endorsement system in [3] before
> enforcing it.
> * While circuit breaker isn't necessarily *the* solution to solving
> jamming on LN, it provides us with some data points and a
> practical way for individual operators to address spamming of
> their nodes.
>
> 3. Tokens Update
> Since our last discussion an architecture document was added to the
> proposal [6], details in the mailing list post [7]. The main goal is
> to try to dissociate the people paying the fees from those gaining the
> benefits from the credentials, so that credentials can be paid by a
> LSP (for example).
>
> 4. Reputation discussions in LSP Specification
> Some attendees have been working on a reputation system for the LSP
> specification group [8]. This system is intended to provide standard
> metrics about what makes a node good/bad to connect to in the context
> of a decentralized marketplace. While this work looks at the problem
> from a different perspective, there's a possibility to consolidate
> the efforts. It seems particularly useful in the anti-jamming case
> where a node has newly connected to you, and needs a "start state"
> reputation score. The idea of defining what qualifies as good
> behavior in the Lightning Network is useful across the board. The
> LSP specification group also has bi-weekly calls, and welcomes
> additional participants!
>
> 5. Call Cadence
> Attendees agreed to continue with calls every two weeks. General
> consensus was that we would aim for a 30 minute meeting with the
> option to extend to an hour if discussion warrants it.
>
> # What's next
> Thanks to everyone who attended last week's meeting, we hope to see
> more folks in the next one!
>
> There's a lot to discuss - brave readers who made it all the way to
> the bottom of this email will notice a fair number of question marks
> scattered about - and we're going to continue to break the problem
> down into smaller parts to discuss in the hope of making progress.
>
> Any change to the Lightning Network that aims to address channel
> jamming attacks will be a significant (but necessary) change to the
> protocol, and it's going to need input from many different
> stakeholders. Please reach out here or in private
> (carla at chaincode.com / clara at chaincode.com) if you have any questions
> / concerns / comments!
>
> Cheers until next time,
> Carla and Clara
> (Yes, our names are confusing. No, you won't get used to it)
>
> [1]
> https://github.com/ClaraShk/LNJamming/blob/main/meeting-transcripts/23-01-23-transcript.md
> [2] https://github.com/lightning/bolts/pull/1052
> [3] https://eprint.iacr.org/2022/1454.pdf
> [4]
> https://mempool.space/lightning/node/021c97a90a411ff2b10dc2a8e32de2f29d2fa49d41bfbb52bd416e460db0747d0d
> [5] https://github.com/lightning/bolts/pull/1044
> [6] https://github.com/lightning/bolts/pull/1043
> [8] https://github.com/BitcoinAndLightningLayerSpecs/lsp/issues/12
> _______________________________________________
> 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/20230131/eaa2019f/attachment-0001.html>

2023-06-09 13:12:32

- reply

📅 Original date posted:2023-01-23
🗒️ Summary of this message: A security audit of the Validating Lightning Signer (VLS) has revealed critical vulnerabilities and attack vectors, including fee siphoning and dust inflate attacks. The VLS team has been informed and committed to addressing the issues.
📝 Original message:
Hi all,
Since starting to hack on LDK, I’ve been interested in running some
components of a Lightning node in a dedicated hardware environment, in the
image of what is done by the smart card industry. We have been doing a
bunch of refactoring in that sense early on to isolate our signing
operations [0].
Building on top of this generic signing interface, the Validating Lightning
Signer has been growing into a mature Lightning signer during the past
years, performing a comprehensive set of policy checks to ensure the keys
are not misused [1]. The module development is advanced enough to be
functional with both deployment of LDK and CLN nodes (waiting internal
refactoring by other implementations for eventual support).
During the past months, in cooperation with the VLS project team, I’ve done
a third-party security audit of VLS core mechanisms, evaluating its state
of readiness for production by the community of Lightning node operators.
The critical vulnerabilities and attacks vectors found are the following:
- The legacy `option_anchor_outputs` is accepted by the Signer, there is no
protection against channel opening downgrades to unsafe channel type. This
opens the way to the known fee siphoning attack capturing almost all
channel value in function of capacity [2].
- The Signer does not enforce an upper bound on the sum of trimmed HTLC as
miner fees. This opens the way to the known dust inflate attack capturing a
minority of channel value if the adversary has low-hashrate capabilities
[3].
- There is a lack of a `policy-cltv-delta-reasonable` rule for routing
hops. There is no enforcement of a reasonable `cltv_expiry_delta` between
inbound HTLC and outbound HTLC, where reasonable is defined according to
the BOLT2’s `cltv_expiry_delta` selection recommendations [4]. This opens
the way to HTLC-double-spend attack where up to
`max_htlc_value_in_flight_msat` of channel value can be captured.
- There is a lack of verification of `nLocktime` field soundness of the
HTLC-timeout at counterparty signature reception. This opens the way to
HTLC value freezing or double-spend in function of the deployment
- There is a lack of rejection of non-Segwit input for the funding
transaction. This opens the way to known freezing of full channel value by
the counterparty [5].
- The Signer is suffering from high-exposure to a fee-siphoning attack by
an adversary with minimal hashrate capabilities (i.e 1 block without time
boundary). Both funding/commitment transactions weights and feerate can be
inflated to increase the absolute fee signed.
Beyond that, there are still missing not-implemented critical policy rules
and the invoices and payments flows are still hardened with a consistent
security model. Those issues were known by the project.
The issues have been communicated to the VLS team ahead of the report
publication and they’re committed to address them.
The full audit report can be found here:
https://github.com/ariard/validating-lightning-signer/blob/main/VLS-audit-v0.2.pdf
In the future, as the LN ecosystem matures, extended policies are expected
to be introduced covering the variety of LN use-cases: merchant, mobile,
routing nodes, LSP, where the policy set of rules could bind to the
application logic. E.g as BOLT12 offers to introduce a richer semantic on
payment protocol, the request structure could be enforced by the VLS [6].
Moreover, other data flows could be submitted to VLS to detect anomalies,
such as the historical mempools data in a compressed way.
Beyond Lightning node security, the VLS architecture could be generalized
to other Bitcoin contracting protocols (e.g vaults), where spending
policies are also leveraged to introduce fine-grained control of custodied
Bitcoin funds between cold and warm wallets.
Cheers,
Antoine
[0] https://github.com/lightningdevkit/rust-lightning/pull/214
[1] https://vls.tech
[2]
https://lists.linuxfoundation.org/pipermail/lightning-dev/2020-September/002796.html
[3]
https://lists.linuxfoundation.org/pipermail/lightning-dev/2020-May/002714.html
<https://lists.linuxfoundation.org/pipermail/lightning-dev/2020-May/002714.html>
[4]
https://github.com/lightning/bolts/blob/master/02-peer-protocol.md#cltv_expiry_delta-selection
[5]
https://github.com/bitcoin/bips/blob/master/bip-0141.mediawiki#user-content-Trustfree_unconfirmed_transaction_dependency_chain
[6] http://bolt12.org
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20230123/33179656/attachment.html>

2023-06-09 13:12:30

- reply

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

2023-06-09 13:12:27

- reply

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

2023-06-09 13:08:58

- reply

📅 Original date posted:2023-06-06
📝 Original message:
Hi Bastien,
> This can be fixed by using a "soft lock" when selecting utxos for a non
> 0-conf funding attempt. 0-conf funding attempts must ignore soft locked
> utxos while non 0-conf funding attempts can (should) reuse soft locked
> utxos.
If my understanding of the "soft lock" strategy is correct - Only locking
UTXO when it's a non 0-conf funding attempt - I think you're still exposed
to liquidity griefing with dual-funding or splicing.
The vector of griefing you're mentioning is the lack of signature release
for a shared input by your counterparty. However, in the context of
dual-funding where the counterparty can add any output with
`tx_add_output`, the transaction can be pinned in the mempool in a very
sneaky way e.g abuse of replacement rule 3.
This latter pinning vector is advantageous to the malicious counterparty as
I think you can batch your pinning against unrelated dual-funding, only
linked in the mempool by a malicious pinning CPFP.
It is left as an exercise to the reader to find other vectors of pinnings
that can be played out in the dual-funding flow.
In terms of (quick) solution to prevent liquidity griefing related to
mempool vectors, the (honest) counterparty can enforce that any contributed
outputs must be encumbered by a 1 CSV, unless being a 2-of-2 funding.
Still, this mitigation can be limited as I think the initial commitment
transaction must have anchor outputs on each-side, for each party to
recover its contributed UTXOs in any case.
> Then we immediately send `channel_ready` as well and start using that
> channel (because we know we won't double spend ourselves). This is nice
> because it lets us use 0-conf in a way where only one side of the
> channel needs to trust the other side (instead of both sides trusting
> each other).
>From the 0-conf initiator viewpoint (the one contributing the UTXO(s)), it
can still be valuable to disable inbound payments, or requires a longer
`cltv_expiry_delta` than usual, in case of mempool fee spikes delaying the
0-conf chain confirmation.
Beyond, it sounds liquidity griefing provoked by a lack of signature
release or mempool funny games will always be there ? Even for the second
with package relay/nVersion deployment, there is still the duration between
the pinning happening among network mempools and your replacement broadcast
kickstarts.
As a more long-term solution, we might reuse solutions worked out to
mitigate channel jamming, as the abstract problem is the same, namely your
counterparty can lock up scarce resources without (on-chain/off-chain
whatever) fees paid.
E.g the Staking Credentials framework could be deployed by dual-funding
market-makers beyond routing hops [0]. The dual-funding initiator should
pay to the maker a fee scale up on the amount of UTXOs contributed, and
some worst-case liquidity griefing scenario. A privacy-preserving
credential can be introduced between the payment of the fee and the redeem
of the service to unlink dual-funding initiators (if the maker has enough
volume to constitute a reasonable anonymity set).
Best,
Antoine
[0]
https://lists.linuxfoundation.org/pipermail/lightning-dev/2023-May/003964.html
Le sam. 6 mai 2023 à 04:15, Bastien TEINTURIER <bastien at acinq.fr> a écrit :
> Good morning list,
>
> One of the challenges created by the introduction of dual funded
> transactions [1] in lightning is how to protect against liquidity
> griefing attacks from malicious peers [2].
>
> Let's start by reviewing this liquidity griefing issue. The dual funding
> protocol starts by exchanging data about the utxos each peer adds to the
> shared transaction, then exchange signatures and broadcast the resulting
> transaction. If peers lock their utxos as soon as they've decided to add
> them to the shared transaction, the remote node may go silent. If that
> happens, the honest node has some liquidity that is locked and unusable.
>
> This cannot easily be fixed by simply unlocking utxos *after* detecting
> that the remote node is fishy, because the remote node would still have
> succeeded at locking your liquidity for a (small) duration, and could
> start other instances of that attack with different node_ids.
>
> An elegant solution to this issue is to never lock utxos used in dual
> funded transactions. If a remote node goes silent in the middle of an
> instance of the protocol, your utxos will automatically be re-used in
> another instance of the protocol. The only drawback with that approach
> is that when you have multiple concurrent instances of dual funding with
> honest peers, some of them may fail because they are double-spent by one
> of the concurrent instances. This is acceptable, since the protocol
> should complete fairly quickly when peers are honest, and at worst, it
> can simply be restarted when failure is detected.
>
> But that solution falls short when using 0-conf, because accidentally
> double-spending a 0-conf channel (because of concurrent instances) can
> result in loss of funds for one of the peers (if payments were made on
> that channel before detecting the double-spend). It seems like using
> 0-conf forces us to lock utxos to avoid this issue, which means that
> nodes offering 0-conf services expose themselves to liquidity griefing.
>
> Another related issue is that nodes that want to offer 0-conf channels
> must ensure that the utxos they use for 0-conf are isolated from the
> utxos they use for non 0-conf, otherwise it is not possible to properly
> lock utxos, because of the following race scenario:
>
> - utxoA is selected for a non 0-conf funding attempt and not locked
> (to protect against liquidity griefing)
> - utxoA is also selected for a 0-conf funding attempt (because it is
> found unlocked in the wallet) and then locked
> - the funding transaction for the 0-conf channel is successfully
> published first and that channel is instantly used for payments
> - the funding transaction for the non 0-conf channel is then published
> and confirms, accidentally double-spending the 0-conf channel
>
> This can be fixed by using a "soft lock" when selecting utxos for a non
> 0-conf funding attempt. 0-conf funding attempts must ignore soft locked
> utxos while non 0-conf funding attempts can (should) reuse soft locked
> utxos.
>
> In eclair, we are currently doing "opportunistic" 0-conf:
>
> - if we receive `channel_ready` immediately (which means that our peer
> trusts us to use 0-conf)
> - and we're the only contributor to the funding transaction (our peer
> doesn't have any input that they could use to double-spend)
> - and the transaction hasn't been RBF-ed yet
>
> Then we immediately send `channel_ready` as well and start using that
> channel (because we know we won't double spend ourselves). This is nice
> because it lets us use 0-conf in a way where only one side of the
> channel needs to trust the other side (instead of both sides trusting
> each other).
>
> Unfortunately, we cannot do that anymore when mixing 0-conf and non
> 0-conf funding attempts, because the utxos may be soft locked,
> preventing us from "upgrading" to 0-conf.
>
> You have successfully reached the end of this quite technical post,
> congrats! My goal with this post is to gather ideas on how we could
> improve that situation and offer good enough protections against
> liquidity griefing for nodes offering 0-conf services. Please share
> your ideas! And yes, I know, 0-conf is a massive implementation pain
> point that we would all like to remove from our codebases, but hey,
> users like it ¯\_(ツ)_/¯
>
> Cheers,
> Bastien
>
> [1] https://github.com/lightning/bolts/pull/851
> [2] https://github.com/lightning/bolts/pull/851#discussion_r997537630
> _______________________________________________
> 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/20230607/50378bc7/attachment.html>

2023-06-09 13:08:55

- reply

📅 Original date posted:2023-05-24
📝 Original message:
Hi list,
As it has been discussed before, a solution to mitigate jamming
attacks over the Lightning Network consists in the introduction of
credentials that must be acquired by HTLC senders to lock each hop
liquidity along the forwarding path. Those credentials can be
privacy-preserving to mask the identity of the HTLC senders towards
the routing hops. They serve as a monetary hedge in case of default of
the HTLC sender on the payment of the routing fees.
As additional advantages, this credentials framework, dubbed "Staking
Credentials", can be deployed to mitigate other liquidity timevalue
DoS in the Lightning landscape, e.g collaborative transaction
construction or even beyond as an enhanced paywall to access Nostr
relay services [0].
This post gives an overview of the framework by detailing the key
concepts, laying out the protocol phases, showing concrete examples
and presenting the upsides and downsides of this mitigation approach
for jamming.
## Protocol Abstractions
The protocol relies on basic mechanisms of the Lightning Network such
as the onion messages, blinded paths where the sender doesn't know who
is the recipient and gossips, an information dissemination protocol
not relying on third-party.
Beyond, new abstractions are introduced:
- credentials: unique keys establishing attributes of the bearer,
those keys can be blinded [1].
- scarce assets: e.g a Bitcoin transaction, a Lightning payment,
chaumian ecash, UTXO ownership proofs.
- Requester/Issuer entities: the Requester requires from the Issuer
authentication of credentials in exchange for submitting scarce
assets.
- Client/Provider entities: the Client requires from the Provider a
service in exchange of submitting a credential.
## Protocol Phases
The first phase of the protocol is the discovery by a user of the
`credentials_policy` and `service_policy` gossips originating
respectively from Issuers and Providers. By reading the
`service_policy`, a user can discover the list of credentials Issuer a
target service Provider is relying on.
The user in the role of the Requester starts by committing a scarce
asset as announced by the Issuer's `credentials_policy`. E.g the
Requester sends a Bitcoin on-chain to a destination scriptPubkey
previously announced by the gossip mechanism. The user attaches the
scarce asset proof with a set of blinded credentials, finds an onion
path to the Issuer and sends the whole inside an onion message.
When the Issuer receives the scarce asset proofs and the set of
credentials, the proof is first verified e.g the on-chain payment must
be confirmed to a destination scriptPubkey controlled by the Issuer.
If the proof is correct and the scarce asset cost matches the quantity
of credentials as announced by `credentials_policy`, the blinded
credentials are countersigned by the Issuer and the signatures replied
back to the Requester by using a blinded path.
The Requester receives the Issuer signature and should verify they're
correct under the announced issuance public key in
`credentials_policy`. If they are valid, the credentials can be
unblinded and consumed for the satisfaction of a service or correct
the transactional asymmetries of a Bitcoin financial contract (e.g the
signature release for a dual-funding transaction).
Alternatively, the credentials usage can be delegated to another user
under the warning than for the second-user, there is no guarantee the
credential transfer is not double-spend.
The user in the role of the Client forwards the unblinded credentials
and the corresponding Issuer signatures to a target service Provider.
The service request can be protocol-specific and linked with the
credentials submission with a simple pair of identifiers (e.g a
32-byte random value). At reception by the Provider, the signatures on
the unblinded credentials must be verified against the corresponding
Issuance public key. The quantity of credentials must be equal to the
service units requested as announced by `service_policy`.
If those checks are correct, the Provider is satisfying the Client
service request, and additionally can provide back authentication
signatures for a new set of blinded credentials (optionally attached
in the service request issued by the Client).
## Example: Lightning jamming
Alice, the routing hop, cumulates in this deployment both the role of
Issuer and Provider. As an Issuer, she announces how much Lightning
satoshis she wishes to be paid to countersign a quantity of N
credentials in `credentials_policy`. As a Provider, she announces how
much credentials she wishes to allow a lockup of her 10_000 sats
Lightning channels for 100 blocks in `service_policy`.
Bob the HTLC sender discovers Alice's `credentials_policy`, sends a
Lightning payment to Alice and then collects a quantity of N signed
blinded credentials during a issuance dance with Alice. After this,
Bob can build a payment path going through Alice, where her hop's
onion `payload` includes an identifier Z. Bob transfers the signed
unblinded credentials with the same identifier Z through onion routing
to Alice node.
Alice node verifies the credentials with respect to her
`service_policy` for the forwarding of HTLC. If this is correct, the
HTLC is forward over her 10_000 sats Lightning channel. If the HTLC
settlement is successful, a new quantity of blinded credentials is
countersigned by Alice to reward Bob for the efficient usage of her
liquidity.
## Protocol Upsides
The credentials allows a service Provider to establish a dynamic
risk-management policy, where the submission of credentials is
disabled during the "peaceful" state and where credentials must bind
to 100% of the timevalue of the liquidity service in case of "war"
state. E.g for jamming, the cost of the credentials can match 100% of
the routing fees announced in `channel_update.
The blinding of the credentials should preserve the privacy of the
HTLC senders, therefore preventing deanonymization of the payments, or
selective censorship of the HTLC forward by a specific HTLC sender.
The credentials enable an emergent discount effect, where in case of
"honest" behavior of the Client in the usage of the service, they can
be rewarded by fresh credentials, therefore reducing the operational
cost of their future service usage.
The credentials framework should be generic enough to adapt to
multiple Bitcoin flows beyond HTLC forwarding, and the Lightning
jamming issue. Other flows of interest can be to cover the asymmetries
in collaborative transaction construction, e.g the order of the
release of the contributed UTXOs signatures. Qualitative credentials
could be deployed enabling bounded routing fees or SLA of liquidity
during periods of Lightning network congestion.
There is a Rust implementation in early progress, with a short-term
goal to have the full Staking Credential flow working in its
non-blinded version for a 1-hop payment path.
Cheers,
Antoine
[0] https://github.com/civkit/staking-credentials-spec
[1] https://sceweb.sce.uhcl.edu/yang/teaching/csci5234WebSecurityFall2011/Chaum-blind-signatures.PDF
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20230524/35f6e341/attachment.html>

2023-06-09 13:08:50

- reply

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

2023-06-09 13:08:49

- reply

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

2023-06-09 13:08:47

- reply

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

2023-06-09 13:08:38

- reply

📅 Original date posted:2023-05-10
📝 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>

2023-06-09 13:08:29

- reply

📅 Original date posted:2023-04-03
📝 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>

2023-06-09 13:08:21

- reply

📅 Original date posted:2023-03-21
📝 Original message:
Hi all,
Last Tuesday 14th March, I did receive a letter from the law firm so-called
Jackson Lewis saying they represent Chaincode Labs about the subject of
"improper communications". Being a long-time Bitcoin developer and knowing
well of Chaincode Labs, I've been and I'm still very confused about this
letter's authenticity.
The letter is available here under MIT license:
https://github.com/ariard/chaincode-improper-communications
The sentences inside are quite unclear to me, especially not being an
English native. They say that I have to halt "all improper and
inappropriate communications with certain Chaincode employees". In the
past, I did find bugs and other issues in Bitcoin Core Github PRs of some
Chaincode folks, so I don't know if saying the code might be broken under
"inappropriate communications". They add "You agreed to do so" without
presenting old-school paperwork signatures or cryptographic ones or OTS
proofs of archived content, so it's a bit hard to know what to answer on.
Beyond that, they say I would have sent "unsolicited emails" to Chaincode
employees in February 2023. For sure, I've sent mails on the usual mailing
lists to which a lot of folks are contributing to. And some of those mails
were pointing to bitcoin technical shortcomings that might piss off people,
as always.
Then, they say my "conduct was improper '' without pointing to a precise
FOSS code of conduct. The thing is we don't have a code of conduct in
Bitcoin Core as there are a lot of legal uncertainties (from the recent
inquiry of Chaincode Labs itself iirc). The restraint on communications
tells nothing if it's scoping the confidential report of security flaws to
selected parties (among them potentially Chaincode folks), in order to
mitigate upcoming jeopardy of Bitcoin funds. Finally, the "any and all
legal actions" doesn't say if those actions can target open-source
communities and projects I might be involved with (like we're seeing Tari
Labs doing "legal actions" against LL and therefore impacting the wider
non-LL Taro community).
There are 2 more troubling issues. One, the title of the letter "Chaincode
Labs - Cease & Desist Letter to Antione Riard". I really received it like
this and checked the typo multiple times. I think my name is Antoine Riard,
I've to verify but I think so. So I don't know if the letter is legally
valid. Second, the lawyer issuing the letter sounds to be one specialist in
labor law, not really cryptocurrencies and FOSS software.
In the lack of sound legal advice on my side, I would say the default would
be to reach out to the Bitcoin Legal Defense Fund, which from my
understanding sounds to have a mission to provide guidance to developers
receiving legal intimidations in the pursuit of their open-source
activities. The thing is the Bitcoin Legal Defense Fund is run by Chaincode
Labs among others, so I wouldn't know if I could ask them for advice on an
issue at first sight involving them. Sounds a weird catch 22.
By advance my apologies to Chaincode Labs if I'm sharing a forgery or
non-authenticated document assigned to their organization. I believe in the
cases involving Tulip Trading Lawsuit there has been doubt on the quality
of the document produced, so a fool sending forgeries to developers to
throw confusion among the community is not to exclude. In anycase, I
believe it's better to seek community feedback on what to do about this
letter (and as such ccing all the lists!).
Cheers,
Antoine
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20230321/664f3420/attachment.html>

2023-06-09 13:08:18

- reply

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

2023-06-09 13:08:14

- reply

📅 Original date posted:2023-03-01
📝 Original message:
Hi Val,
Thanks for the proposal here. About using OM for payment probing, I think
there could be an alternative of the routing hops themselves announcing
their liquidity balances with an extension or new set of gossip messages.
Gossips messages could commit to a liquidity balance and duration
(e.g +1000 blocks from tip), rather relying on sender-side probing, which
might be less and less accurate with higher rate of network liquidity
congestion. Additionally, a routing hop could commit to "private" gossip
sent back to HTLC senders during HTLC successful settlement. Those
"private" gossip might announce "differentiated services" of channel
liquidity levels. I believe this can be guaranteed transparently from the
rest of the network thanks to parallel channels.
Any deviation from the gossip message could be penalized by sender's
scoring algorithms as the liquidity SLA parameters have been announced
explicitly by the routing hops. This is just an intuition on how public
channel liquidity discovery could be worked out, and I don't know which of
the alternatives would be more efficient in terms of
bandwidth/convergence delays.
Best,
Antoine
Le lun. 27 févr. 2023 à 21:32, vwallace via Lightning-dev <
lightning-dev at lists.linuxfoundation.org> a écrit :
> Hi list!
>
> I wanted to bring up the idea of using onion messages for payment probing,
> which was briefly touched
> on at the 2022 LN summit. Tadge Dryja has also brought up a similar idea.
>
> I recommend reading the gist instead since it has the relevant diagrams
> in-line:
> https://gist.github.com/valentinewallace/ebe1741f0438c2360eda0f80f0e075c9
> but the scheme is also
> posted below for convenience.
>
> ## Introduction
>
> For context, in today’s lightning, payment reliability tends to heavily
> depend on having sufficient
> payment volume to determine current liquidity balances of channels, which
> is how most big nodes can
> tell whether a given channel has enough liquidity to forward a given
> amount. If a node is using HTLC
> probing to achieve this payment volume, they use a regular
> `update_add_htlc` message with a bogus
> payment hash, where the error returned informs the sender of whether the
> payment reached the final
> recipient. Note that there is a tradeoff between always routing through
> nodes that are known to
> rebalance their channels vs leaning on probing smaller nodes and “risking”
> payments through them
> based on what’s learned.
>
> Today’s HTLC payment probing can work well, but risks channel liquidity
> being locked up if a peer
> along the route goes offline. On the upside, for just-in-time probes, it
> works to loosely “reserve”
> the channel liquidity along the route for the actual payment.
>
> Onion messages (OMs) present a convenient way to probe without risking
> locked liquidity along the
> route.
>
> ## Design Rationale
>
> A naive approach could be to send onion message probes directly to
> individual nodes along the
> desired route, including those to which you don’t have a direct channel.
> However, this scheme is
> problematic because it would enable monitoring the payment flows of
> arbitrary nodes across the
> network without having to have a channel path to them. This would be a
> significant degradation of
> privacy because, for comparison, in HTLC probing it is quite difficult to
> probe the balances of
> far-off nodes. And if you can’t probe a node using HTLCs, you can’t send
> over it anyway, so there’s
> not a lot of benefit (and significant privacy downside).
>
> Therefore, it is probably best to design a scheme that probes along
> channel paths, like HTLC
> probing. This adds more complexity to the case where an intermediate node
> cannot forward the desired
> amount due to the stateless nature of OMs, discussed further down.
>
> ## Scheme
>
> Let’s go through the happy path, where Alice is probing Alice > Bob >
> Carol > Dave for a 100k msat
> payment.
>
> She’ll construct an onion message for Bob, the first hop, as such:
> https://imgur.com/BZg8yt8
>
> Bob receives this OM, sees that he’s able to forward 110k msats to his
> next-hop Carol, and forwards
> Carol’s onion packet to her. Carol sees she can forward 105k msats to
> Dave, and forwards his onion
> packet. Finally, Dave receives his onion packet, sees he can receive 100k
> msats from Carol, and uses
> the provided reply path to send a simple probe success onion message back
> to Alice:
>
> ```
> onion_message_probe_result {
> data_tlv {
> type: 4242,
> probe_id: [u8; 32],
> can_forward_desired_amt: true,
> }
> .. regular OM TLVs
> }
> ```
>
> Note that Dave will use this same onion message if he can’t receive; he’ll
> just set
> `can_forward_desired_amt` to false.
>
> As an example of the sad path for an intermediate node, if Carol can’t
> forward 105k msats to Dave,
> she’ll fail the probe back to Bob by sending this onion message:
> https://imgur.com/a/hqlzw4I
>
> This step justifies why we need to encode a failure onion for each
> intermediate hop of a probe. If
> we hadn’t done that, and Carol responded to Bob with an empty “failed”
> message, Bob would have no
> idea which peer to fail the probe back to, because OMs are stateless.
> Instead, Bob unwraps his error
> onion and sees that he needs to fail back to Alice with her provided error
> onion. Alice receives the
> failure onion and can see that Carol was not able to forward the desired
> amount corresponding to the
> probe id, thus completing the probe.
>
> ## Outro
>
> While there is nothing stopping nodes from lying about their ability to
> forward, they may be
> negatively scored if they do so. Further, adopting a protocol like this
> could help routing nodes
> attract more forwarding traffic, which is a nice incentive.
>
> I view this feature as a low priority enhancement, given there are a lot
> more pressing issues in LN,
> but open to feedback. Mostly, I thought it could be useful to spark ideas
> and highlight the
> flexibility of OMs.
>
> Cheers,
> Val
> _______________________________________________
> 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/20230301/756791ad/attachment.html>

2023-06-09 13:08:08

- reply

📅 Original date posted:2023-02-14
📝 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>

2023-06-09 13:08:07

- reply

📅 Original date posted:2023-02-16
📝 Original message:
Yeah definitely looking forward to talk more about highly available
lightning channels. During next LN channel jamming meetup! .
Le jeu. 16 févr. 2023 à 00:43, Matt Corallo <lf-lists at mattcorallo.com> a
écrit :
>
>
> On 2/14/23 11:36 PM, Joost Jager wrote:
> > But how do you decide to set it without a credit relationship? Do I
> measure my channel and set the
> >
> > bit because the channel is "usually" (at what threshold?) saturating
> in the inbound direction? What
> > happens if this changes for an hour and I get unlucky? Did I just
> screw myself?
> >
> >
> > As a node setting the flag, you'll have to make sure you open new
> channels, rebalance or swap-in in
> > time to maintain outbound liquidity. That's part of the game of running
> an HA channel.
>
> Define "in time" in a way that results in senders not punishing you for
> not meeting your "HA
> guarantees" due to a large flow. I don't buy that this results in anything
> other than pressure to
> add credit.
>
> > > How can you be sure about this? This isn't publicly visible data.
> >
> > Sure it is! https://river.com/learn/files/river-lightning-report.pdf
> > <https://river.com/learn/files/river-lightning-report.pdf>
> >
> >
> > Some operators publish data, but are the experiences of one of the most
> well connected (custodial)
> > nodes representative for the network as a whole when evaluating payment
> success rates? In the end
> > you can't know what's happening on the lightning network.
>
> 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.
>
> Once we do that, everyone gets a similar experience as the River report :).
>
> Matt
> _______________________________________________
> 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/a4c356bf/attachment.html>

2023-06-09 13:08:07

- reply

📅 Original date posted:2023-02-17
📝 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>

2023-06-09 13:08:00

- reply

📅 Original date posted:2023-01-31
📝 Original message:
(Reply 2/2)
> * Whether we should look into a more complicated approach that
> includes a "proof of forward" secret in the next node's onion which
> must be supplied to claim the upfront fee.
One of the hard things with a "proof of forward" is a hop colluding with
the next counterparty in way non-provable to the HTLC sender. I don't think
more reliable onion errors will save the mechanism, as you might always
masquerade your routing node offliness (sure -- it might be penalized by
routing algorithms still probably a period of grace exploitable)
> * Whether Bob _would_ steal the upfront fee by dropping the payment,
> as it'll impact nodes' desire to route through them in future.
And if you have "floating" upfront fees to adjust to routing node
opportunity cost and the routing algorithms historical buckets are not
correcting the variations, a "upfront fee" adversary might be able to steal
the amount, in a proportion not corrected by the penalty.
> * Is there a way to deliver upfront fees to nodes along the route
> *without* them adding up along the route (other than the naive
> version of sending each hop a payment, which comes with its own
> problems)? Seems not, but bright ideas are wanted and welcome!
I think the latest update of the Staking Credentials could answer such
description
of "delivering the upfront fees to nodes along the route *without* them
adding up along the route" as the credential issuance is separated from its
redemption.
On a few other ideas, "magically" teleporting the fee payment to the
routing hops, it has been browsed in the past [2].
> * That nodes will decide where they fall in the trade-off of setting
> upfront fees to cover their opportunity cost for high routing fees
> and market pressure to keep these fees low for the sake of
> remaining competitive.
They will probably need to do real-time monitoring of the congestion rates
and outcome results of their HTLC forwarding to adjust in consequence their
routing fees.
> * A taproot tree for all HTLCs where each leaf has a subset of HTLCs,
> and fees could be incorporated here (summary note: apparently some
> work has been done here, but I couldn't find the link).
The idea of summing up the taproot tree for all HTLCs is discussed here
with past references [3]. I don't know if it's really a viable direction,
as aggregating the claim of HTLCs of different values in the same witness
claims might open the door to transaction-relay games.
> * If we're confident that a more complicated solution will solve many
> problems, then we should pursue them, otherwise a simple solution
> is possibly a _good enough_ first step.
If the "proof of forward" can be solved by "magic" covenant is still an open
issue. I don't know if it's a viable solution as it's more a hard synchronicity
issue between chain of contracts. However from exploring issue we might
learn interesting design considerations for contracting protocols (at the
very least some semi-formal proof it's not possible)
> * Should our first attempt at solving this issue be for a future
> steady state where nodes have significant traffic and nodes face
> real opportunity cost (in the form of lost revenue) if they are
> targeted by a jamming attack?
Deferring the most economically-efficient solution we can come from, we might
run into a bunch of incentives-misallignment between generation of nodes
operators and Lightning use-cases. Maybe same as we have seen with lack of
transaction replacement, first-seen RBF, opt-in RBF, mempoolfullrbf, I
believe.
On the other-side, the deployment of a simple solution would enable us to
start to build a consistent model of how the economics of channel
congestion, that we can "transpose" for more advanced solutions (ideally --
all other things being equal).
> * While circuit breaker isn't necessarily *the* solution to solving
> jamming on LN, it provides us with some data points and a
> practical way for individual operators to address spamming of
> their nodes.
As mentioned above, it sounds like the congestion monitoring and HTLCs
resolution tracking is going to be a standard task among LN
implementations, and that you'll would probably need a piece of
infrastructure like circuit breaker for all implementations.
> Since our last discussion an architecture document was added to the
> proposal [6], details in the mailing list post [7]. The main goal is
> to try to dissociate the people paying the fees from those gaining the
> benefits from the credentials, so that credentials can be paid by a
> LSP (for example).
I think there is a missing footnote, I believe the mail thread might have
been this one:
https://lists.linuxfoundation.org/pipermail/lightning-dev/2023-January/003822.html
Beyond delegation as mentioned, there are few other design goals targeted:
- strong economic-efficiency due to credentials accumulation
- fungibility of their credentials between their issuance and redemption
- dynamic-management of liquidity risks
- contract-agnostic (e.g can cover dual-opening)
Probably, we'll have the credential issuance flow and extension gossip more
speced out before next meetings.
> 4. Reputation discussions in LSP Specification
> Some attendees have been working on a reputation system for the LSP
> specification group [8]. This system is intended to provide standard
> metrics about what makes a node good/bad to connect to in the context
> of a decentralized marketplace. While this work looks at the problem
> from a different perspective, there's a possibility to consolidate
> the efforts. It seems particularly useful in the anti-jamming case
> where a node has newly connected to you, and needs a "start state"
> reputation score. The idea of defining what qualifies as good
> behavior in the Lightning Network is useful across the board. The
> LSP specification group also has bi-weekly calls, and welcomes
> additional participants!
Effectively, I think distributed market infrastructure design could benefit
from the lessons of the Lightning Network. It could be fruitful for the LSP
specification group to have its own mailing list at some point in the
future.
> There's a lot to discuss - brave readers who made it all the way to
> the bottom of this email will notice a fair number of question marks
> scattered about - and we're going to continue to break the problem
> down into smaller parts to discuss in the hope of making progress.
Beyond archiving well the problem space, there is also an effort of
documenting well any protocol design decisions to preserve future
evolvability and achieve interoperabilitybetween implementations.
> Any change to the Lightning Network that aims to address channel
> jamming attacks will be a significant (but necessary) change to the
> protocol
For sure, this is a significant change to the protocol, beyond that we
should be careful to not downgrade the throughput or operations of the
base-layer. If the original Stakes Certificates would have been
implemented, it would have constituted a mempool congestion risk, where the
node operators under jamming would have forced attackers to pay for fresh
UTXOs. If we have to envision such cross-layer mitigation design in the
future, I think we might have to do cross-layer consensus building.
Best,
Antoine
[2] https://jamming-dev.github.io/book/4-design_space.html
[3] https://github.com/ariard/bitcoin-contracting-primitives-wg/issues/26
[4]
https://lists.linuxfoundation.org/pipermail/lightning-dev/2020-November/002884.html
Le lun. 30 janv. 2023 à 15:25, Carla Kirk-Cohen <kirkcohenc at gmail.com> a
écrit :
> Hi list,
>
> On Monday last week we resumed our fortnightly channel jamming
> mitigation calls for 2023.
>
> Details for the next call:
> * Monday 02/06 @ 18:00 UTC
> * https://meet.jit.si/UnjammingLN
> * Agenda: https://github.com/ClaraShk/LNJamming/issues/2
>
> # Meeting Summary
> This email attempts to summarize the discussion, but is of course
> subject to my errors and opinions so the full transcript is available
> at [1]. It is (imperfectly) AI generated, so please reach out to myself
> or Clara if you'd like clarification for a specific section.
>
> 1. Upgrade Mechanisms
> The first topic of discussion was around how we would go about
> upgrading the network to support an anti-jamming mitigation. Most
> solutions share the following characteristics:
> * They will likely require a network wide upgrade: when a sender
> makes a payment, the full path will need to understand the new
> feature bit for it to be used.
> * Sending nodes are unlikely to be incentivised to upgrade to
> support a channel jamming mitigation, as jamming mitigations incur
> additional cost (be it in the form of upfront fees, tokens or some
> other mechanism).
> * Routing nodes have no way of knowing whether a payment comes from
> a node that is not upgraded, or simply doesn't want to pay the
> additional cost introduced by a jamming mitigation.
>
> It was generally agreed that the network is still in an early enough
> stage that it is fair for relaying nodes to initially upgrade but not
> enforce the feature, and later look at forwarding traffic to determine
> whether it is appropriate to require the feature. This will require
> sending nodes to opt-in to the new feature before the network can
> widely enforce it, as no rational routing node will require a feature
> which would reduce its ability to serve un-upgraded traffic (unless
> under attack, which is not the case at present).
>
> A note was also made that wallets tend to upgrade less frequently, in
> part because some providers run forked versions of LN implementations,
> so this horizon may be quite long. It was emphasized that this type of
> network upgrade would require input from wallets, designers and
> application developers anyway, so hopefully by the time we look to
> deploy a change there is rough consensus among the Lightning community
> already.
>
> 2. Upfront Fees
> Next, we discussed the draft proposal for upfront fees [2] that
> implements the first of a two-part jamming mitigation described in [3].
> As it stands, the PR describes the simplest possible way to introduce
> upfront fees to the protocol:
> * Upfront fees are expressed as a ppm of a channel's success-case
> fees, and charged on the outgoing link of a route.
> * Nodes can advertise custom upfront fee rates if desired, but to
> save gossip bandwidth we assume a network-wide default of 1%.
> * Upfront fees accumulate along the route (as htlc payment amounts
> do), and are simply pushed to the `to_remote` balance on
> `update_add_htlc`.
> * Final hop nodes advertise an upfront fee policy in bolt 11 invoices
> (or bolt 12 blinded routes) which is sufficiently padded to
> obfuscate their location in the route.
>
> The interaction between upfront fees and possible future protocol
> changes such as inbound fees and negative fees was briefly discussed,
> specifically the case where a node sets low (or negative) fees to
> attract traffic then fails payments to accumulate upfront fees. As is,
> all implementations’ algorithms optimize for factors other than fees -
> specifically avoiding a node once it's produced failures - and we
> suspect that careful sender-side behavior will mitigate this risk.
> However, it was also acknowledged that a node that attempts this attack
> may be able to fool multiple individual senders and still be able to
> accumulate some fees.
>
> We then discussed the shortcomings of the "simplest possible" upfront
> fees in [2], specifically focused on the following scenario where
> nodes receive 1% of their success-case fees as an upfront payment:
> * Alice is sending a payment to Dave, who is a popular sink node in
> the network.
> * Bob -> Carol has low/default routing policy: 1000 msat success
> case / 10 msat upfront fee
> * Carol -> Dave has high fees: 400,000 msat success case / 4000 msat
> upfront fee
> * Dave advertises no success case fee (is recipient) / 100 msat of
> upfront fee chosen for his invoice.
>
> Alice ------ Bob ------ Carol ------ Dave
>
> Since we need to source all of these funds from the sender (Alice), the
> forwarding of funds is as follows:
> * Alice pushes 4110 msat to Bob.
> * Bob _should_ push 4100 msat to Carol, claiming his 10 msat upfront
> fee.
> * Carol _should_ push 100 msat to Dave, claiming her 4000 msat
> upfront fee.
>
> However, Bob has no real incentive to forward the HTLC to Carol and
> push her the 4100 msat because that value is more than the fees he'll
> earn from successfully forwarding and settling the HTLC (10 msat
> upfront fees + 1000 msat success case fees). It's worth noting that
> this type of fee differential already exists in the network today - I
> got these example numbers by looking at the fee rates of the Loop
> node's peers [4].
>
> There were a few points discussed around this issue:
> * Whether we should look into a more complicated approach that
> includes a "proof of forward" secret in the next node's onion which
> must be supplied to claim the upfront fee.
> * Discussion about whether these order of magnitude fee differences
> will exist in an efficient market (differing opinions).
> * Whether Bob _would_ steal the upfront fee by dropping the payment,
> as it'll impact nodes' desire to route through them in future.
> * Is there a way to deliver upfront fees to nodes along the route
> *without* them adding up along the route (other than the naive
> version of sending each hop a payment, which comes with its own
> problems)? Seems not, but bright ideas are wanted and welcome!
> * That nodes will decide where they fall in the trade-off of setting
> upfront fees to cover their opportunity cost for high routing fees
> and market pressure to keep these fees low for the sake of
> remaining competitive.
>
> A few people mentioned the desire to keep an upfront fee solution as
> simple as possible, but generally it seemed that a solution where the
> accumulated upfront fees at any point along a route exceed any single
> hop's expected success case fees is unacceptable because incentives
> are misaligned (even if we can properly attribute errors with [5]).
>
> We touched briefly on a few "proof of forwarding" solutions for
> upfront fees:
> * Using a locking mechanism that relies on a secret that is provided
> by the next node's onion.
> * A taproot tree for all HTLCs where each leaf has a subset of HTLCs,
> and fees could be incorporated here (summary note: apparently some
> work has been done here, but I couldn't find the link).
> * If we're confident that a more complicated solution will solve many
> problems, then we should pursue them, otherwise a simple solution
> is possibly a _good enough_ first step.
>
> There was some discussion about how we want to go about addressing
> spamming in the network:
> * Is it good enough to deploy something today that just charges a
> simple, capped upfront fee (eg 1 sat per hop) that solves jamming
> for the current state of the network and allows us to learn
> something then iterate?
> * Should our first attempt at solving this issue be for a future
> steady state where nodes have significant traffic and nodes face
> real opportunity cost (in the form of lost revenue) if they are
> targeted by a jamming attack?
>
> 3. Circuit Breaker Update
> * Circuit breaker has a UI now, and some issues are being opened in
> the repo so people have at minimum gone through the effort to spin
> it up.
> * It's still pretty manual, but it does provide node operators with
> information about the payment failures on their nodes (not easily
> surfaced in many LN UIs).
> * Hoping to get insights into stuck HTLCs and spam HTLCs so that we
> can learn from real life experience.
> * Circuit breaker is generally pushing in the same direction as the
> reputation scheme in [3], just a more manual one. We could
> possibly use it to visualize the endorsement system in [3] before
> enforcing it.
> * While circuit breaker isn't necessarily *the* solution to solving
> jamming on LN, it provides us with some data points and a
> practical way for individual operators to address spamming of
> their nodes.
>
> 3. Tokens Update
> Since our last discussion an architecture document was added to the
> proposal [6], details in the mailing list post [7]. The main goal is
> to try to dissociate the people paying the fees from those gaining the
> benefits from the credentials, so that credentials can be paid by a
> LSP (for example).
>
> 4. Reputation discussions in LSP Specification
> Some attendees have been working on a reputation system for the LSP
> specification group [8]. This system is intended to provide standard
> metrics about what makes a node good/bad to connect to in the context
> of a decentralized marketplace. While this work looks at the problem
> from a different perspective, there's a possibility to consolidate
> the efforts. It seems particularly useful in the anti-jamming case
> where a node has newly connected to you, and needs a "start state"
> reputation score. The idea of defining what qualifies as good
> behavior in the Lightning Network is useful across the board. The
> LSP specification group also has bi-weekly calls, and welcomes
> additional participants!
>
> 5. Call Cadence
> Attendees agreed to continue with calls every two weeks. General
> consensus was that we would aim for a 30 minute meeting with the
> option to extend to an hour if discussion warrants it.
>
> # What's next
> Thanks to everyone who attended last week's meeting, we hope to see
> more folks in the next one!
>
> There's a lot to discuss - brave readers who made it all the way to
> the bottom of this email will notice a fair number of question marks
> scattered about - and we're going to continue to break the problem
> down into smaller parts to discuss in the hope of making progress.
>
> Any change to the Lightning Network that aims to address channel
> jamming attacks will be a significant (but necessary) change to the
> protocol, and it's going to need input from many different
> stakeholders. Please reach out here or in private
> (carla at chaincode.com / clara at chaincode.com) if you have any questions
> / concerns / comments!
>
> Cheers until next time,
> Carla and Clara
> (Yes, our names are confusing. No, you won't get used to it)
>
> [1]
> https://github.com/ClaraShk/LNJamming/blob/main/meeting-transcripts/23-01-23-transcript.md
> [2] https://github.com/lightning/bolts/pull/1052
> [3] https://eprint.iacr.org/2022/1454.pdf
> [4]
> https://mempool.space/lightning/node/021c97a90a411ff2b10dc2a8e32de2f29d2fa49d41bfbb52bd416e460db0747d0d
> [5] https://github.com/lightning/bolts/pull/1044
> [6] https://github.com/lightning/bolts/pull/1043
> [8] https://github.com/BitcoinAndLightningLayerSpecs/lsp/issues/12
> _______________________________________________
> 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/20230131/e171e031/attachment-0001.html>

2023-06-09 13:07:59

- reply

📅 Original date posted:2023-01-31
📝 Original message:
Hi Clara,
(Reply 1/2 - Apparently there is a limit of 80KB on Lightning mailing post)
> * They will likely require a network wide upgrade: when a sender
> makes a payment, the full path will need to understand the new
> feature bit for it to be used.
I believe the upgradeability dimension is different both for circuit breaker
and staking credentials -- Circuit breaker is a point-level deployment and
can be rolled out without cooperation of the channel peers. Staking
credentials is end-to-end and just requires cooperation between endpoints
(HTLC senders and routing hops, not even all on the payment paths).
And I think upfront fees is a link-level one, probably the one requesting the
most cooperation between the community of developers/node operators.
Point-to-point/end-to-end deployment already provides benefits with
"half-state"
deployment, I think. However, you might have "holistic" beneficial effects
of link-level solutions (in terms of economic engineering not in terms of
software compatibility), I don't know.
> * Sending nodes are unlikely to be incentivised to upgrade to
> support a channel jamming mitigation, as jamming mitigations incur
> additional cost (be it in the form of upfront fees, tokens or some
> other mechanism).
As with any "unpatched" security risks we're encumbering on Lightning
(pinnings, time-dilation, etc), beyond clearly describing the attack in
reference documents and proof-of-concept of the attack against
implementations, the next step to keep raising awareness is a live demo as
much near as one can from really mainet conditions. While we were patching
CVE-2021-41591 and friends, I've been testing the solidity of the fixes on
the Eclair-side in a "black-box" manner. Always worth it, you learn on the
attack bounds.
We could do the same with jamming attacks, as there is a wide-range of
scenarios
to consider (network-wide/merchant/routing hops) and few optimizations
tricks like looping. Just have to be super careful with any demo exploits
toolchain, there is always a question of ethics here.
> * Routing nodes have no way of knowing whether a payment comes from
> a node that is not upgraded, or simply doesn't want to pay the
> additional cost introduced by a jamming mitigation.
I think a routing node able to know if the payment sender has upgraded could
constitute a version/implementation fingerprint and a downgrade in HTLC traffic
privacy, ideally a routing node should not be able to link payeer/payee.
If a sender does not want to pay the jamming mitigation cost, it might be a
flaw in the incentive-compatibility benefit of a mitigation.
(And in terms of evaluating the
incentives-compatibility/economic-efficiency of any solution, we're going
to run quickly in hard questions of economic methodology, a bit beyond the
software engineering realm).
> It was generally agreed that the network is still in an early enough
> stage that it is fair for relaying nodes to initially upgrade but not
> enforce the feature, and later look at forwarding traffic to determine
> whether it is appropriate to require the feature.
If we look at the recent history of mempool policy upgrades on the
Bitcoin Core-side,
I think it's best practice to be more conservative in terms of "smooth
feature" deployment, even feature-gated beyond some node operator setting. At
time of feature enforcement, some node operators might claim an established
claim on other flows of HTLC traffic, and there would be a question of
backward-compatibility arising.
Independently, there is the fact on how discrepancies in feature activation
could be exploited (privacy-wise or economically-wise). Same issue we have
on the Bitcoin Core-side, when we update the mempool policy, and old nodes
might not see new types of outputs (e.g Taproot spends being non-standard
before the activation iirc).
> This will require sending nodes to opt-in to the new feature before the
network can
> widely enforce it, as no rational routing node will require a feature
> which would reduce its ability to serve un-upgraded traffic (unless
> under attack, which is not the case at present).
I think the corollary holds -- A rational routing node will not require a
feature which would reduce its ability to serve upgraded traffic.
Note, I think the "rational" routing node could be better defined,
otherwise I think we'll run quickly in the same bottlenecked discussions
about "policy rules" compatible with miners incentives, as we're seeing on
the Core-side. So far, I don't think we have a consistent model of miners
incentives.
> A note was also made that wallets tend to upgrade less frequently, in
> part because some providers run forked versions of LN implementations,
> so this horizon may be quite long. It was emphasized that this type of
> network upgrade would require input from wallets, designers and
> application developers anyway, so hopefully by the time we look to
> deploy a change there is rough consensus among the Lightning community
> already.
Yeah, we have the same issues with transaction-relay/mempool policy or even the
non-really specified addr-relay strategy of Bitcoin Core, when there is
an upgrade there. It sounds to me there are no well-maintained public and open
communication channels where protocol developers can reach out to
wallet softwares
vendors for protocol upgrades feedback (and vice-versa). I don't know if
it's one goal of the LSP spec effort. If you're building a wallet, you're
probably going to assemble and maintain components from the two layers.
> * Nodes can advertise custom upfront fee rates if desired, but to
> save gossip bandwidth we assume a network-wide default of 1%.
I think you will have an additional issue here. The routing convergence delay
network-wide might be a bottleneck in how much fee rate variances you have
flexibility as a routing node operator. Routing convergence delays have
been studied in the past at 2,500 seconds for the worst-audience, I don't
think it's going to hold with network graph growth.
> * Upfront fees accumulate along the route (as htlc payment amounts
> do), and are simply pushed to the `to_remote` balance on
> `update_add_htlc`.
I wonder if there is a concern of an "upfront fee" extraction issue at the
channel-level. You have Alice and you have Bob, Bob circular loop to
accumulate max `upfront_fee` on his `to_remote` balance on Alice's commitment
transaction. Then provoke a force-close by Alice to have her paying the
on-chain fees in the post-anchor output model.
There can be an interesting "upfront fees" siphoning issue here.
> The interaction between upfront fees and possible future protocol
> changes such as inbound fees and negative fees was briefly discussed,
> specifically the case where a node sets low (or negative) fees to
> attract traffic then fails payments to accumulate upfront fees. As is,
> all implementations’ algorithms optimize for factors other than fees -
> specifically avoiding a node once it's produced failures - and we
> suspect that careful sender-side behavior will mitigate this risk.
> However, it was also acknowledged that a node that attempts this attack
> may be able to fool multiple individual senders and still be able to
> accumulate some fees.
Correcting upfront fees abuses sounds simple as long as you assume the scoring
is done by the endpoint. When you start to have gossip and routing scoring
delegation, you might be hijacked by an "accumulating fees" adversary. E.g,
one could sybil the rapid-gossip-sync servers, if their deployment becomes
ubiquitous [1]. Same issue with Electrum servers lack of incentives
alignment.
> However, Bob has no real incentive to forward the HTLC to Carol and
> push her the 4100 msat because that value is more than the fees he'll
> earn from successfully forwarding and settling the HTLC (10 msat
> upfront fees + 1000 msat success case fees). It's worth noting that
> this type of fee differential already exists in the network today - I
> got these example numbers by looking at the fee rates of the Loop
> node's peers [4].
Yes, "fee differential" issues have been discussed affecting upfront fees and
all the hold fees variants in the past. I'm not sure they're acceptable fee
risks, if you can exploit them by setting correctly the channel
topologies around
a victim routing hop.
End of 1/2.
[0]
https://lists.linuxfoundation.org/pipermail/lightning-dev/2022-May/003594.html
[1] https://github.com/lightningdevkit/rapid-gossip-sync-server
Le lun. 30 janv. 2023 à 15:25, Carla Kirk-Cohen <kirkcohenc at gmail.com> a
écrit :
> Hi list,
>
> On Monday last week we resumed our fortnightly channel jamming
> mitigation calls for 2023.
>
> Details for the next call:
> * Monday 02/06 @ 18:00 UTC
> * https://meet.jit.si/UnjammingLN
> * Agenda: https://github.com/ClaraShk/LNJamming/issues/2
>
> # Meeting Summary
> This email attempts to summarize the discussion, but is of course
> subject to my errors and opinions so the full transcript is available
> at [1]. It is (imperfectly) AI generated, so please reach out to myself
> or Clara if you'd like clarification for a specific section.
>
> 1. Upgrade Mechanisms
> The first topic of discussion was around how we would go about
> upgrading the network to support an anti-jamming mitigation. Most
> solutions share the following characteristics:
> * They will likely require a network wide upgrade: when a sender
> makes a payment, the full path will need to understand the new
> feature bit for it to be used.
> * Sending nodes are unlikely to be incentivised to upgrade to
> support a channel jamming mitigation, as jamming mitigations incur
> additional cost (be it in the form of upfront fees, tokens or some
> other mechanism).
> * Routing nodes have no way of knowing whether a payment comes from
> a node that is not upgraded, or simply doesn't want to pay the
> additional cost introduced by a jamming mitigation.
>
> It was generally agreed that the network is still in an early enough
> stage that it is fair for relaying nodes to initially upgrade but not
> enforce the feature, and later look at forwarding traffic to determine
> whether it is appropriate to require the feature. This will require
> sending nodes to opt-in to the new feature before the network can
> widely enforce it, as no rational routing node will require a feature
> which would reduce its ability to serve un-upgraded traffic (unless
> under attack, which is not the case at present).
>
> A note was also made that wallets tend to upgrade less frequently, in
> part because some providers run forked versions of LN implementations,
> so this horizon may be quite long. It was emphasized that this type of
> network upgrade would require input from wallets, designers and
> application developers anyway, so hopefully by the time we look to
> deploy a change there is rough consensus among the Lightning community
> already.
>
> 2. Upfront Fees
> Next, we discussed the draft proposal for upfront fees [2] that
> implements the first of a two-part jamming mitigation described in [3].
> As it stands, the PR describes the simplest possible way to introduce
> upfront fees to the protocol:
> * Upfront fees are expressed as a ppm of a channel's success-case
> fees, and charged on the outgoing link of a route.
> * Nodes can advertise custom upfront fee rates if desired, but to
> save gossip bandwidth we assume a network-wide default of 1%.
> * Upfront fees accumulate along the route (as htlc payment amounts
> do), and are simply pushed to the `to_remote` balance on
> `update_add_htlc`.
> * Final hop nodes advertise an upfront fee policy in bolt 11 invoices
> (or bolt 12 blinded routes) which is sufficiently padded to
> obfuscate their location in the route.
>
> The interaction between upfront fees and possible future protocol
> changes such as inbound fees and negative fees was briefly discussed,
> specifically the case where a node sets low (or negative) fees to
> attract traffic then fails payments to accumulate upfront fees. As is,
> all implementations’ algorithms optimize for factors other than fees -
> specifically avoiding a node once it's produced failures - and we
> suspect that careful sender-side behavior will mitigate this risk.
> However, it was also acknowledged that a node that attempts this attack
> may be able to fool multiple individual senders and still be able to
> accumulate some fees.
>
> We then discussed the shortcomings of the "simplest possible" upfront
> fees in [2], specifically focused on the following scenario where
> nodes receive 1% of their success-case fees as an upfront payment:
> * Alice is sending a payment to Dave, who is a popular sink node in
> the network.
> * Bob -> Carol has low/default routing policy: 1000 msat success
> case / 10 msat upfront fee
> * Carol -> Dave has high fees: 400,000 msat success case / 4000 msat
> upfront fee
> * Dave advertises no success case fee (is recipient) / 100 msat of
> upfront fee chosen for his invoice.
>
> Alice ------ Bob ------ Carol ------ Dave
>
> Since we need to source all of these funds from the sender (Alice), the
> forwarding of funds is as follows:
> * Alice pushes 4110 msat to Bob.
> * Bob _should_ push 4100 msat to Carol, claiming his 10 msat upfront
> fee.
> * Carol _should_ push 100 msat to Dave, claiming her 4000 msat
> upfront fee.
>
> However, Bob has no real incentive to forward the HTLC to Carol and
> push her the 4100 msat because that value is more than the fees he'll
> earn from successfully forwarding and settling the HTLC (10 msat
> upfront fees + 1000 msat success case fees). It's worth noting that
> this type of fee differential already exists in the network today - I
> got these example numbers by looking at the fee rates of the Loop
> node's peers [4].
>
> There were a few points discussed around this issue:
> * Whether we should look into a more complicated approach that
> includes a "proof of forward" secret in the next node's onion which
> must be supplied to claim the upfront fee.
> * Discussion about whether these order of magnitude fee differences
> will exist in an efficient market (differing opinions).
> * Whether Bob _would_ steal the upfront fee by dropping the payment,
> as it'll impact nodes' desire to route through them in future.
> * Is there a way to deliver upfront fees to nodes along the route
> *without* them adding up along the route (other than the naive
> version of sending each hop a payment, which comes with its own
> problems)? Seems not, but bright ideas are wanted and welcome!
> * That nodes will decide where they fall in the trade-off of setting
> upfront fees to cover their opportunity cost for high routing fees
> and market pressure to keep these fees low for the sake of
> remaining competitive.
>
> A few people mentioned the desire to keep an upfront fee solution as
> simple as possible, but generally it seemed that a solution where the
> accumulated upfront fees at any point along a route exceed any single
> hop's expected success case fees is unacceptable because incentives
> are misaligned (even if we can properly attribute errors with [5]).
>
> We touched briefly on a few "proof of forwarding" solutions for
> upfront fees:
> * Using a locking mechanism that relies on a secret that is provided
> by the next node's onion.
> * A taproot tree for all HTLCs where each leaf has a subset of HTLCs,
> and fees could be incorporated here (summary note: apparently some
> work has been done here, but I couldn't find the link).
> * If we're confident that a more complicated solution will solve many
> problems, then we should pursue them, otherwise a simple solution
> is possibly a _good enough_ first step.
>
> There was some discussion about how we want to go about addressing
> spamming in the network:
> * Is it good enough to deploy something today that just charges a
> simple, capped upfront fee (eg 1 sat per hop) that solves jamming
> for the current state of the network and allows us to learn
> something then iterate?
> * Should our first attempt at solving this issue be for a future
> steady state where nodes have significant traffic and nodes face
> real opportunity cost (in the form of lost revenue) if they are
> targeted by a jamming attack?
>
> 3. Circuit Breaker Update
> * Circuit breaker has a UI now, and some issues are being opened in
> the repo so people have at minimum gone through the effort to spin
> it up.
> * It's still pretty manual, but it does provide node operators with
> information about the payment failures on their nodes (not easily
> surfaced in many LN UIs).
> * Hoping to get insights into stuck HTLCs and spam HTLCs so that we
> can learn from real life experience.
> * Circuit breaker is generally pushing in the same direction as the
> reputation scheme in [3], just a more manual one. We could
> possibly use it to visualize the endorsement system in [3] before
> enforcing it.
> * While circuit breaker isn't necessarily *the* solution to solving
> jamming on LN, it provides us with some data points and a
> practical way for individual operators to address spamming of
> their nodes.
>
> 3. Tokens Update
> Since our last discussion an architecture document was added to the
> proposal [6], details in the mailing list post [7]. The main goal is
> to try to dissociate the people paying the fees from those gaining the
> benefits from the credentials, so that credentials can be paid by a
> LSP (for example).
>
> 4. Reputation discussions in LSP Specification
> Some attendees have been working on a reputation system for the LSP
> specification group [8]. This system is intended to provide standard
> metrics about what makes a node good/bad to connect to in the context
> of a decentralized marketplace. While this work looks at the problem
> from a different perspective, there's a possibility to consolidate
> the efforts. It seems particularly useful in the anti-jamming case
> where a node has newly connected to you, and needs a "start state"
> reputation score. The idea of defining what qualifies as good
> behavior in the Lightning Network is useful across the board. The
> LSP specification group also has bi-weekly calls, and welcomes
> additional participants!
>
> 5. Call Cadence
> Attendees agreed to continue with calls every two weeks. General
> consensus was that we would aim for a 30 minute meeting with the
> option to extend to an hour if discussion warrants it.
>
> # What's next
> Thanks to everyone who attended last week's meeting, we hope to see
> more folks in the next one!
>
> There's a lot to discuss - brave readers who made it all the way to
> the bottom of this email will notice a fair number of question marks
> scattered about - and we're going to continue to break the problem
> down into smaller parts to discuss in the hope of making progress.
>
> Any change to the Lightning Network that aims to address channel
> jamming attacks will be a significant (but necessary) change to the
> protocol, and it's going to need input from many different
> stakeholders. Please reach out here or in private
> (carla at chaincode.com / clara at chaincode.com) if you have any questions
> / concerns / comments!
>
> Cheers until next time,
> Carla and Clara
> (Yes, our names are confusing. No, you won't get used to it)
>
> [1]
> https://github.com/ClaraShk/LNJamming/blob/main/meeting-transcripts/23-01-23-transcript.md
> [2] https://github.com/lightning/bolts/pull/1052
> [3] https://eprint.iacr.org/2022/1454.pdf
> [4]
> https://mempool.space/lightning/node/021c97a90a411ff2b10dc2a8e32de2f29d2fa49d41bfbb52bd416e460db0747d0d
> [5] https://github.com/lightning/bolts/pull/1044
> [6] https://github.com/lightning/bolts/pull/1043
> [8] https://github.com/BitcoinAndLightningLayerSpecs/lsp/issues/12
> _______________________________________________
> 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/20230131/bbef78be/attachment-0001.html>

2023-06-09 13:07:58

- reply

📅 Original date posted:2023-01-31
📝 Original message:
Hi Clara,
> * They will likely require a network wide upgrade: when a sender
> makes a payment, the full path will need to understand the new
> feature bit for it to be used.
I believe the upgradeability dimension is different both for circuit breaker
and staking credentials -- Circuit breaker is a point-level deployment and
can be rolled out without cooperation of the channel peers. Staking
credentials is end-to-end and just requires cooperation between endpoints
(HTLC senders and routing hops, not even all on the payment paths).
And I think upfront fees is a link-level one, probably the one requesting the
most cooperation between the community of developers/node operators.
Point-to-point/end-to-end deployment already provides benefits with
"half-state"
deployment, I think. However, you might have "holistic" beneficial effects
of link-level solutions (in terms of economic engineering not in terms of
software compatibility), I don't know.
> * Sending nodes are unlikely to be incentivised to upgrade to
> support a channel jamming mitigation, as jamming mitigations incur
> additional cost (be it in the form of upfront fees, tokens or some
> other mechanism).
As with any "unpatched" security risks we're encumbering on Lightning
(pinnings, time-dilation, etc), beyond clearly describing the attack in
reference documents and proof-of-concept of the attack against
implementations, the next step to keep raising awareness is a live demo as
much near as one can from really mainet conditions. While we were patching
CVE-2021-41591 and friends, I've been testing the solidity of the fixes on
the Eclair-side in a "black-box" manner. Always worth it, you learn on the
attack bounds.
We could do the same with jamming attacks, as there is a wide-range of
scenarios
to consider (network-wide/merchant/routing hops) and few optimizations
tricks like looping. Just have to be super careful with any demo exploits
toolchain, there is always a question of ethics here.
> * Routing nodes have no way of knowing whether a payment comes from
> a node that is not upgraded, or simply doesn't want to pay the
> additional cost introduced by a jamming mitigation.
I think a routing node able to know if the payment sender has upgraded could
constitute a version/implementation fingerprint and a downgrade in HTLC traffic
privacy, ideally a routing node should not be able to link payeer/payee.
If a sender does not want to pay the jamming mitigation cost, it might be a
flaw in the incentive-compatibility benefit of a mitigation.
(And in terms of evaluating the
incentives-compatibility/economic-efficiency of any solution, we're going
to run quickly in hard questions of economic methodology, a bit beyond the
software engineering realm).
> It was generally agreed that the network is still in an early enough
> stage that it is fair for relaying nodes to initially upgrade but not
> enforce the feature, and later look at forwarding traffic to determine
> whether it is appropriate to require the feature.
If we look at the recent history of mempool policy upgrades on the
Bitcoin Core-side,
I think it's best practice to be more conservative in terms of "smooth
feature" deployment, even feature-gated beyond some node operator setting. At
time of feature enforcement, some node operators might claim an established
claim on other flows of HTLC traffic, and there would be a question of
backward-compatibility arising.
Independently, there is the fact on how discrepancies in feature activation
could be exploited (privacy-wise or economically-wise). Same issue we have
on the Bitcoin Core-side, when we update the mempool policy, and old nodes
might not see new types of outputs (e.g Taproot spends being non-standard
before the activation iirc).
> This will require sending nodes to opt-in to the new feature before the
network can
> widely enforce it, as no rational routing node will require a feature
> which would reduce its ability to serve un-upgraded traffic (unless
> under attack, which is not the case at present).
I think the corollary holds -- A rational routing node will not require a
feature which would reduce its ability to serve upgraded traffic.
Note, I think the "rational" routing node could be better defined,
otherwise I think we'll run quickly in the same bottlenecked discussions
about "policy rules" compatible with miners incentives, as we're seeing on
the Core-side. So far, I don't think we have a consistent model of miners
incentives.
> A note was also made that wallets tend to upgrade less frequently, in
> part because some providers run forked versions of LN implementations,
> so this horizon may be quite long. It was emphasized that this type of
> network upgrade would require input from wallets, designers and
> application developers anyway, so hopefully by the time we look to
> deploy a change there is rough consensus among the Lightning community
> already.
Yeah, we have the same issues with transaction-relay/mempool policy or even the
non-really specified addr-relay strategy of Bitcoin Core, when there is
an upgrade there. It sounds to me there are no well-maintained public and open
communication channels where protocol developers can reach out to
wallet softwares
vendors for protocol upgrades feedback (and vice-versa). I don't know if
it's one goal of the LSP spec effort. If you're building a wallet, you're
probably going to assemble and maintain components from the two layers.
> * Nodes can advertise custom upfront fee rates if desired, but to
> save gossip bandwidth we assume a network-wide default of 1%.
I think you will have an additional issue here. The routing convergence delay
network-wide might be a bottleneck in how much fee rate variances you have
flexibility as a routing node operator. Routing convergence delays have
been studied in the past at 2,500 seconds for the worst-audience, I don't
think it's going to hold with network graph growth.
> * Upfront fees accumulate along the route (as htlc payment amounts
> do), and are simply pushed to the `to_remote` balance on
> `update_add_htlc`.
I wonder if there is a concern of an "upfront fee" extraction issue at the
channel-level. You have Alice and you have Bob, Bob circular loop to
accumulate max `upfront_fee` on his `to_remote` balance on Alice's commitment
transaction. Then provoke a force-close by Alice to have her paying the
on-chain fees in the post-anchor output model.
There can be an interesting "upfront fees" siphoning issue here.
> The interaction between upfront fees and possible future protocol
> changes such as inbound fees and negative fees was briefly discussed,
> specifically the case where a node sets low (or negative) fees to
> attract traffic then fails payments to accumulate upfront fees. As is,
> all implementations’ algorithms optimize for factors other than fees -
> specifically avoiding a node once it's produced failures - and we
> suspect that careful sender-side behavior will mitigate this risk.
> However, it was also acknowledged that a node that attempts this attack
> may be able to fool multiple individual senders and still be able to
> accumulate some fees.
Correcting upfront fees abuses sounds simple as long as you assume the scoring
is done by the endpoint. When you start to have gossip and routing scoring
delegation, you might be hijacked by an "accumulating fees" adversary. E.g,
one could sybil the rapid-gossip-sync servers, if their deployment becomes
ubiquitous [1]. Same issue with Electrum servers lack of incentives
alignment.
> However, Bob has no real incentive to forward the HTLC to Carol and
> push her the 4100 msat because that value is more than the fees he'll
> earn from successfully forwarding and settling the HTLC (10 msat
> upfront fees + 1000 msat success case fees). It's worth noting that
> this type of fee differential already exists in the network today - I
> got these example numbers by looking at the fee rates of the Loop
> node's peers [4].
Yes, "fee differential" issues have been discussed affecting upfront fees and
all the hold fees variants in the past. I'm not sure they're acceptable fee
risks, if you can exploit them by setting correctly the channel
topologies around
a victim routing hop.
> * Whether we should look into a more complicated approach that
> includes a "proof of forward" secret in the next node's onion which
> must be supplied to claim the upfront fee.
One of the hard things with a "proof of forward" is a hop colluding with
the next counterparty in way non-provable to the HTLC sender. I don't think
more reliable onion errors will save the mechanism, as you might always
masquerade your routing node offliness (sure -- it might be penalized by
routing algorithms still probably a period of grace exploitable)
> * Whether Bob _would_ steal the upfront fee by dropping the payment,
> as it'll impact nodes' desire to route through them in future.
And if you have "floating" upfront fees to adjust to routing node
opportunity cost and the routing algorithms historical buckets are not
correcting the variations, a "upfront fee" adversary might be able to steal
the amount, in a proportion not corrected by the penalty.
> * Is there a way to deliver upfront fees to nodes along the route
> *without* them adding up along the route (other than the naive
> version of sending each hop a payment, which comes with its own
> problems)? Seems not, but bright ideas are wanted and welcome!
I think the latest update of the Staking Credentials could answer such
description
of "delivering the upfront fees to nodes along the route *without* them
adding up along the route" as the credential issuance is separated from its
redemption.
On a few other ideas, "magically" teleporting the fee payment to the
routing hops, it has been browsed in the past [2].
> * That nodes will decide where they fall in the trade-off of setting
> upfront fees to cover their opportunity cost for high routing fees
> and market pressure to keep these fees low for the sake of
> remaining competitive.
They will probably need to do real-time monitoring of the congestion rates
and outcome results of their HTLC forwarding to adjust in consequence their
routing fees.
> * A taproot tree for all HTLCs where each leaf has a subset of HTLCs,
> and fees could be incorporated here (summary note: apparently some
> work has been done here, but I couldn't find the link).
The idea of summing up the taproot tree for all HTLCs is discussed here
with past references [3]. I don't know if it's really a viable direction,
as aggregating the claim of HTLCs of different values in the same witness
claims might open the door to transaction-relay games.
> * If we're confident that a more complicated solution will solve many
> problems, then we should pursue them, otherwise a simple solution
> is possibly a _good enough_ first step.
If the "proof of forward" can be solved by "magic" covenant is still an open
issue. I don't know if it's a viable solution as it's more a hard synchronicity
issue between chain of contracts. However from exploring issue we might
learn interesting design considerations for contracting protocols (at the
very least some semi-formal proof it's not possible)
> * Should our first attempt at solving this issue be for a future
> steady state where nodes have significant traffic and nodes face
> real opportunity cost (in the form of lost revenue) if they are
> targeted by a jamming attack?
Deferring the most economically-efficient solution we can come from, we might
run into a bunch of incentives-misallignment between generation of nodes
operators and Lightning use-cases. Maybe same as we have seen with lack of
transaction replacement, first-seen RBF, opt-in RBF, mempoolfullrbf, I
believe.
On the other-side, the deployment of a simple solution would enable us to
start to build a consistent model of how the economics of channel
congestion, that we can "transpose" for more advanced solutions (ideally --
all other things being equal).
> * While circuit breaker isn't necessarily *the* solution to solving
> jamming on LN, it provides us with some data points and a
> practical way for individual operators to address spamming of
> their nodes.
As mentioned above, it sounds like the congestion monitoring and HTLCs
resolution tracking is going to be a standard task among LN
implementations, and that you'll would probably need a piece of
infrastructure like circuit breaker for all implementations.
> Since our last discussion an architecture document was added to the
> proposal [6], details in the mailing list post [7]. The main goal is
> to try to dissociate the people paying the fees from those gaining the
> benefits from the credentials, so that credentials can be paid by a
> LSP (for example).
I think there is a missing footnote, I believe the mail thread might have
been this one:
https://lists.linuxfoundation.org/pipermail/lightning-dev/2023-January/003822.html
Beyond delegation as mentioned, there are few other design goals targeted:
- strong economic-efficiency due to credentials accumulation
- fungibility of their credentials between their issuance and redemption
- dynamic-management of liquidity risks
- contract-agnostic (e.g can cover dual-opening)
Probably, we'll have the credential issuance flow and extension gossip more
speced out before next meetings.
> 4. Reputation discussions in LSP Specification
> Some attendees have been working on a reputation system for the LSP
> specification group [8]. This system is intended to provide standard
> metrics about what makes a node good/bad to connect to in the context
> of a decentralized marketplace. While this work looks at the problem
> from a different perspective, there's a possibility to consolidate
> the efforts. It seems particularly useful in the anti-jamming case
> where a node has newly connected to you, and needs a "start state"
> reputation score. The idea of defining what qualifies as good
> behavior in the Lightning Network is useful across the board. The
> LSP specification group also has bi-weekly calls, and welcomes
> additional participants!
Effectively, I think distributed market infrastructure design could benefit
from the lessons of the Lightning Network. It could be fruitful for the LSP
specification group to have its own mailing list at some point in the
future.
> There's a lot to discuss - brave readers who made it all the way to
> the bottom of this email will notice a fair number of question marks
> scattered about - and we're going to continue to break the problem
> down into smaller parts to discuss in the hope of making progress.
Beyond archiving well the problem space, there is also an effort of
documenting well any protocol design decisions to preserve future
evolvability and achieve interoperability between implementations.
> Any change to the Lightning Network that aims to address channel
> jamming attacks will be a significant (but necessary) change to the
> protocol
For sure, this is a significant change to the protocol, beyond that we
should be careful to not downgrade the throughput or operations of the
base-layer. If the original Stakes Certificates would have been
implemented, it would have constituted a mempool congestion risk, where the
node operators under jamming would have forced attackers to pay for fresh
UTXOs. If we have to envision such cross-layer mitigation design in the
future, I think we might have to do cross-layer consensus building.
Best,
Antoine
[0]
https://lists.linuxfoundation.org/pipermail/lightning-dev/2022-May/003594.html
[1] https://github.com/lightningdevkit/rapid-gossip-sync-server
[2] https://jamming-dev.github.io/book/4-design_space.html
[3] https://github.com/ariard/bitcoin-contracting-primitives-wg/issues/26
[4]
https://lists.linuxfoundation.org/pipermail/lightning-dev/2020-November/002884.html
Le lun. 30 janv. 2023 à 15:25, Carla Kirk-Cohen <kirkcohenc at gmail.com> a
écrit :
> Hi list,
>
> On Monday last week we resumed our fortnightly channel jamming
> mitigation calls for 2023.
>
> Details for the next call:
> * Monday 02/06 @ 18:00 UTC
> * https://meet.jit.si/UnjammingLN
> * Agenda: https://github.com/ClaraShk/LNJamming/issues/2
>
> # Meeting Summary
> This email attempts to summarize the discussion, but is of course
> subject to my errors and opinions so the full transcript is available
> at [1]. It is (imperfectly) AI generated, so please reach out to myself
> or Clara if you'd like clarification for a specific section.
>
> 1. Upgrade Mechanisms
> The first topic of discussion was around how we would go about
> upgrading the network to support an anti-jamming mitigation. Most
> solutions share the following characteristics:
> * They will likely require a network wide upgrade: when a sender
> makes a payment, the full path will need to understand the new
> feature bit for it to be used.
> * Sending nodes are unlikely to be incentivised to upgrade to
> support a channel jamming mitigation, as jamming mitigations incur
> additional cost (be it in the form of upfront fees, tokens or some
> other mechanism).
> * Routing nodes have no way of knowing whether a payment comes from
> a node that is not upgraded, or simply doesn't want to pay the
> additional cost introduced by a jamming mitigation.
>
> It was generally agreed that the network is still in an early enough
> stage that it is fair for relaying nodes to initially upgrade but not
> enforce the feature, and later look at forwarding traffic to determine
> whether it is appropriate to require the feature. This will require
> sending nodes to opt-in to the new feature before the network can
> widely enforce it, as no rational routing node will require a feature
> which would reduce its ability to serve un-upgraded traffic (unless
> under attack, which is not the case at present).
>
> A note was also made that wallets tend to upgrade less frequently, in
> part because some providers run forked versions of LN implementations,
> so this horizon may be quite long. It was emphasized that this type of
> network upgrade would require input from wallets, designers and
> application developers anyway, so hopefully by the time we look to
> deploy a change there is rough consensus among the Lightning community
> already.
>
> 2. Upfront Fees
> Next, we discussed the draft proposal for upfront fees [2] that
> implements the first of a two-part jamming mitigation described in [3].
> As it stands, the PR describes the simplest possible way to introduce
> upfront fees to the protocol:
> * Upfront fees are expressed as a ppm of a channel's success-case
> fees, and charged on the outgoing link of a route.
> * Nodes can advertise custom upfront fee rates if desired, but to
> save gossip bandwidth we assume a network-wide default of 1%.
> * Upfront fees accumulate along the route (as htlc payment amounts
> do), and are simply pushed to the `to_remote` balance on
> `update_add_htlc`.
> * Final hop nodes advertise an upfront fee policy in bolt 11 invoices
> (or bolt 12 blinded routes) which is sufficiently padded to
> obfuscate their location in the route.
>
> The interaction between upfront fees and possible future protocol
> changes such as inbound fees and negative fees was briefly discussed,
> specifically the case where a node sets low (or negative) fees to
> attract traffic then fails payments to accumulate upfront fees. As is,
> all implementations’ algorithms optimize for factors other than fees -
> specifically avoiding a node once it's produced failures - and we
> suspect that careful sender-side behavior will mitigate this risk.
> However, it was also acknowledged that a node that attempts this attack
> may be able to fool multiple individual senders and still be able to
> accumulate some fees.
>
> We then discussed the shortcomings of the "simplest possible" upfront
> fees in [2], specifically focused on the following scenario where
> nodes receive 1% of their success-case fees as an upfront payment:
> * Alice is sending a payment to Dave, who is a popular sink node in
> the network.
> * Bob -> Carol has low/default routing policy: 1000 msat success
> case / 10 msat upfront fee
> * Carol -> Dave has high fees: 400,000 msat success case / 4000 msat
> upfront fee
> * Dave advertises no success case fee (is recipient) / 100 msat of
> upfront fee chosen for his invoice.
>
> Alice ------ Bob ------ Carol ------ Dave
>
> Since we need to source all of these funds from the sender (Alice), the
> forwarding of funds is as follows:
> * Alice pushes 4110 msat to Bob.
> * Bob _should_ push 4100 msat to Carol, claiming his 10 msat upfront
> fee.
> * Carol _should_ push 100 msat to Dave, claiming her 4000 msat
> upfront fee.
>
> However, Bob has no real incentive to forward the HTLC to Carol and
> push her the 4100 msat because that value is more than the fees he'll
> earn from successfully forwarding and settling the HTLC (10 msat
> upfront fees + 1000 msat success case fees). It's worth noting that
> this type of fee differential already exists in the network today - I
> got these example numbers by looking at the fee rates of the Loop
> node's peers [4].
>
> There were a few points discussed around this issue:
> * Whether we should look into a more complicated approach that
> includes a "proof of forward" secret in the next node's onion which
> must be supplied to claim the upfront fee.
> * Discussion about whether these order of magnitude fee differences
> will exist in an efficient market (differing opinions).
> * Whether Bob _would_ steal the upfront fee by dropping the payment,
> as it'll impact nodes' desire to route through them in future.
> * Is there a way to deliver upfront fees to nodes along the route
> *without* them adding up along the route (other than the naive
> version of sending each hop a payment, which comes with its own
> problems)? Seems not, but bright ideas are wanted and welcome!
> * That nodes will decide where they fall in the trade-off of setting
> upfront fees to cover their opportunity cost for high routing fees
> and market pressure to keep these fees low for the sake of
> remaining competitive.
>
> A few people mentioned the desire to keep an upfront fee solution as
> simple as possible, but generally it seemed that a solution where the
> accumulated upfront fees at any point along a route exceed any single
> hop's expected success case fees is unacceptable because incentives
> are misaligned (even if we can properly attribute errors with [5]).
>
> We touched briefly on a few "proof of forwarding" solutions for
> upfront fees:
> * Using a locking mechanism that relies on a secret that is provided
> by the next node's onion.
> * A taproot tree for all HTLCs where each leaf has a subset of HTLCs,
> and fees could be incorporated here (summary note: apparently some
> work has been done here, but I couldn't find the link).
> * If we're confident that a more complicated solution will solve many
> problems, then we should pursue them, otherwise a simple solution
> is possibly a _good enough_ first step.
>
> There was some discussion about how we want to go about addressing
> spamming in the network:
> * Is it good enough to deploy something today that just charges a
> simple, capped upfront fee (eg 1 sat per hop) that solves jamming
> for the current state of the network and allows us to learn
> something then iterate?
> * Should our first attempt at solving this issue be for a future
> steady state where nodes have significant traffic and nodes face
> real opportunity cost (in the form of lost revenue) if they are
> targeted by a jamming attack?
>
> 3. Circuit Breaker Update
> * Circuit breaker has a UI now, and some issues are being opened in
> the repo so people have at minimum gone through the effort to spin
> it up.
> * It's still pretty manual, but it does provide node operators with
> information about the payment failures on their nodes (not easily
> surfaced in many LN UIs).
> * Hoping to get insights into stuck HTLCs and spam HTLCs so that we
> can learn from real life experience.
> * Circuit breaker is generally pushing in the same direction as the
> reputation scheme in [3], just a more manual one. We could
> possibly use it to visualize the endorsement system in [3] before
> enforcing it.
> * While circuit breaker isn't necessarily *the* solution to solving
> jamming on LN, it provides us with some data points and a
> practical way for individual operators to address spamming of
> their nodes.
>
> 3. Tokens Update
> Since our last discussion an architecture document was added to the
> proposal [6], details in the mailing list post [7]. The main goal is
> to try to dissociate the people paying the fees from those gaining the
> benefits from the credentials, so that credentials can be paid by a
> LSP (for example).
>
> 4. Reputation discussions in LSP Specification
> Some attendees have been working on a reputation system for the LSP
> specification group [8]. This system is intended to provide standard
> metrics about what makes a node good/bad to connect to in the context
> of a decentralized marketplace. While this work looks at the problem
> from a different perspective, there's a possibility to consolidate
> the efforts. It seems particularly useful in the anti-jamming case
> where a node has newly connected to you, and needs a "start state"
> reputation score. The idea of defining what qualifies as good
> behavior in the Lightning Network is useful across the board. The
> LSP specification group also has bi-weekly calls, and welcomes
> additional participants!
>
> 5. Call Cadence
> Attendees agreed to continue with calls every two weeks. General
> consensus was that we would aim for a 30 minute meeting with the
> option to extend to an hour if discussion warrants it.
>
> # What's next
> Thanks to everyone who attended last week's meeting, we hope to see
> more folks in the next one!
>
> There's a lot to discuss - brave readers who made it all the way to
> the bottom of this email will notice a fair number of question marks
> scattered about - and we're going to continue to break the problem
> down into smaller parts to discuss in the hope of making progress.
>
> Any change to the Lightning Network that aims to address channel
> jamming attacks will be a significant (but necessary) change to the
> protocol, and it's going to need input from many different
> stakeholders. Please reach out here or in private
> (carla at chaincode.com / clara at chaincode.com) if you have any questions
> / concerns / comments!
>
> Cheers until next time,
> Carla and Clara
> (Yes, our names are confusing. No, you won't get used to it)
>
> [1]
> https://github.com/ClaraShk/LNJamming/blob/main/meeting-transcripts/23-01-23-transcript.md
> [2] https://github.com/lightning/bolts/pull/1052
> [3] https://eprint.iacr.org/2022/1454.pdf
> [4]
> https://mempool.space/lightning/node/021c97a90a411ff2b10dc2a8e32de2f29d2fa49d41bfbb52bd416e460db0747d0d
> [5] https://github.com/lightning/bolts/pull/1044
> [6] https://github.com/lightning/bolts/pull/1043
> [8] https://github.com/BitcoinAndLightningLayerSpecs/lsp/issues/12
> _______________________________________________
> 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/20230131/eaa2019f/attachment-0001.html>

2023-06-09 13:07:56

- reply

📅 Original date posted:2023-01-23
📝 Original message:
Hi all,
Since starting to hack on LDK, I’ve been interested in running some
components of a Lightning node in a dedicated hardware environment, in the
image of what is done by the smart card industry. We have been doing a
bunch of refactoring in that sense early on to isolate our signing
operations [0].
Building on top of this generic signing interface, the Validating Lightning
Signer has been growing into a mature Lightning signer during the past
years, performing a comprehensive set of policy checks to ensure the keys
are not misused [1]. The module development is advanced enough to be
functional with both deployment of LDK and CLN nodes (waiting internal
refactoring by other implementations for eventual support).
During the past months, in cooperation with the VLS project team, I’ve done
a third-party security audit of VLS core mechanisms, evaluating its state
of readiness for production by the community of Lightning node operators.
The critical vulnerabilities and attacks vectors found are the following:
- The legacy `option_anchor_outputs` is accepted by the Signer, there is no
protection against channel opening downgrades to unsafe channel type. This
opens the way to the known fee siphoning attack capturing almost all
channel value in function of capacity [2].
- The Signer does not enforce an upper bound on the sum of trimmed HTLC as
miner fees. This opens the way to the known dust inflate attack capturing a
minority of channel value if the adversary has low-hashrate capabilities
[3].
- There is a lack of a `policy-cltv-delta-reasonable` rule for routing
hops. There is no enforcement of a reasonable `cltv_expiry_delta` between
inbound HTLC and outbound HTLC, where reasonable is defined according to
the BOLT2’s `cltv_expiry_delta` selection recommendations [4]. This opens
the way to HTLC-double-spend attack where up to
`max_htlc_value_in_flight_msat` of channel value can be captured.
- There is a lack of verification of `nLocktime` field soundness of the
HTLC-timeout at counterparty signature reception. This opens the way to
HTLC value freezing or double-spend in function of the deployment
- There is a lack of rejection of non-Segwit input for the funding
transaction. This opens the way to known freezing of full channel value by
the counterparty [5].
- The Signer is suffering from high-exposure to a fee-siphoning attack by
an adversary with minimal hashrate capabilities (i.e 1 block without time
boundary). Both funding/commitment transactions weights and feerate can be
inflated to increase the absolute fee signed.
Beyond that, there are still missing not-implemented critical policy rules
and the invoices and payments flows are still hardened with a consistent
security model. Those issues were known by the project.
The issues have been communicated to the VLS team ahead of the report
publication and they’re committed to address them.
The full audit report can be found here:
https://github.com/ariard/validating-lightning-signer/blob/main/VLS-audit-v0.2.pdf
In the future, as the LN ecosystem matures, extended policies are expected
to be introduced covering the variety of LN use-cases: merchant, mobile,
routing nodes, LSP, where the policy set of rules could bind to the
application logic. E.g as BOLT12 offers to introduce a richer semantic on
payment protocol, the request structure could be enforced by the VLS [6].
Moreover, other data flows could be submitted to VLS to detect anomalies,
such as the historical mempools data in a compressed way.
Beyond Lightning node security, the VLS architecture could be generalized
to other Bitcoin contracting protocols (e.g vaults), where spending
policies are also leveraged to introduce fine-grained control of custodied
Bitcoin funds between cold and warm wallets.
Cheers,
Antoine
[0] https://github.com/lightningdevkit/rust-lightning/pull/214
[1] https://vls.tech
[2]
https://lists.linuxfoundation.org/pipermail/lightning-dev/2020-September/002796.html
[3]
https://lists.linuxfoundation.org/pipermail/lightning-dev/2020-May/002714.html
<https://lists.linuxfoundation.org/pipermail/lightning-dev/2020-May/002714.html>
[4]
https://github.com/lightning/bolts/blob/master/02-peer-protocol.md#cltv_expiry_delta-selection
[5]
https://github.com/bitcoin/bips/blob/master/bip-0141.mediawiki#user-content-Trustfree_unconfirmed_transaction_dependency_chain
[6] http://bolt12.org
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20230123/33179656/attachment.html>

2023-06-09 13:07:50

- reply

📅 Original date posted:2023-01-05
📝 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>

2023-06-09 13:07:44

- reply

📅 Original date posted:2022-12-13
📝 Original message:
Hi Greg,
> Right, there are some network-level games that can be played, however
> honest participants can be given a leg up through as AJ notes, alternative
> relays, or even a "rebinder" widget which means only the single highest
fee
> bidding copy of the final update transaction has to make it to the miners'
> mempool. So if the honest party bids X% of the HTLC value in fees, the
> attacker will be paying more than that every single block,
> constantly racing, until it loses either a mempool race or the latest bid.
Yes, I think you could have a p2p extension enabling "blind" rebinding on a
chain of update transactions by pointing to the known channel funding
output. However, the attacker might still pay the mempool feerate (assuming
nversion=3), and win any round of the race. As noted in the description,
the attack opportunity relies on some economic bounds, like the HTLC value,
the CLTV expiry delta and the mempool backlog.
> A mitigation could be for a fee-bumping strategy to adopt a scorched
approach when the HTLC-timeout is approaching, and there is a corresponding
incoming HTLC. When the HTLC-timeout is near expiration (e.g X blocks from
incoming HTLC expiry), probably 100% of the HTLC value should be burnt in
update transaction fees.
> I kind of always thought that's how HTLCs would have worked in theory and
> practice eventually. As the clock runs down you're willing to spend more
to
> take less of the full value.
One of the biggest unknown from a fee-bumping strategy design is the
fee-bump delta you should attach in function of your prediction of mempool
backlogs. To the best of my knowledge, this is not how current generations
of fee-estimators are working.
> As I said before, I think this is already the case. We're assuming
> liveliness of blockchain for these contracts, if a unilateral close gets
> targeted by a large fraction of miners, I don't think eltoo is the risk,
> it's the HTLC constract that's the risk.
Yes, here it's just under LN-penalty. I think the rational fee-bumping
strategy is to target top mempool feerate backlog (assuming nversion=3), as
during the HTLC CLTV delay, there is no competition from the counterparty.
So I agree the HTLC contract is the risk itself, though the dimensions of
the miners bribery attacks might be changed under eltoo.
> In my current eltoo design, I'm assuming *by policy* APO (V3?)
transactions
> can only have one input, and each transaction is only allowed a single
> ephemeral anchor which is attached but not committed to by the
> SIGHASH_SINGLE|APOAS signature. This results in a 1-input-2-output
> transaction that isn't malleable. If and when we figure out how to un-pin
> these kinds of transactions, this policy can be relaxed, and we can get
the
> benefits of aggregated transactions.
I think this is the most conservative design for now, to restrain
malleability of transactions to the minimum, as aggregation transactions
can be played out by honest channel participants by an adversary.
Best,
Antoine
Le mar. 13 déc. 2022 à 09:47, Greg Sanders <gsanders87 at gmail.com> a écrit :
> Hi Antoine,
>
> Nothing you say here(about vanilla eltoo) sounds absurd.
>
> > 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...
>
> >While there is a RBF-race, I think this can be easily won by Malicia by
> mass-connecting on the transaction-relay network and ignoring the Core
> transaction-relay delay timers (here for privacy purposes iirc).
>
> Right, there are some network-level games that can be played, however
> honest participants can be given a leg up through as AJ notes, alternative
> relays, or even a "rebinder" widget which means only the single highest fee
> bidding copy of the final update transaction has to make it to the miners'
> mempool. So if the honest party bids X% of the HTLC value in fees, the
> attacker will be paying more than that every single block,
> constantly racing, until it loses either a mempool race or the latest bid.
>
> I'm starting simple and assuming we don't need all this machinery, and
> hope the risk of counterparty either losing the race a single time, or
> being outbid a single time is enough to dissuade an attack at all.
>
> > A mitigation could be for a fee-bumping strategy to adopt a scorched
> approach when the HTLC-timeout is approaching, and there is a corresponding
> incoming HTLC. When the HTLC-timeout is near expiration (e.g X blocks from
> incoming HTLC expiry), probably 100% of the HTLC value should be burnt in
> update transaction fees.
>
> I kind of always thought that's how HTLCs would have worked in theory and
> practice eventually. As the clock runs down you're willing to spend more to
> take less of the full value.
>
> > Assuming the attack holds, and scorched approach are adopted by default
> to mitigate this concern, there is a second-order concern, we might open
> Lightning channels to miner-harvesting attacks, where the confirmation of
> the update transactions are deferred to kick-out the scorched earth
> reaction of the fee-bumping engine. In my opinion, this would be still an
> improvement, as we're moving a (plausible) security risk triggerable by a
> Lightning counterparty to (hypothetical) one triggerable by a wide
> coalition of miners.
>
> As I said before, I think this is already the case. We're assuming
> liveliness of blockchain for these contracts, if a unilateral close gets
> targeted by a large fraction of miners, I don't think eltoo is the risk,
> it's the HTLC constract that's the risk.
>
> > There is another caveat, it sounds if the update transaction can be
> malleable (i.e SIGHASH_SINGLE|ANYONECANPAY), update transactions across
> Lightning channels could be aggregated by the attacker, changing the
> economy there in a way defavorable to the victims. I.e the attacker can
> select the targeted channels, but the victim cannot coordinate with each
> other to respond with a collective fee-bumping.
>
> In my current eltoo design, I'm assuming *by policy* APO (V3?)
> transactions can only have one input, and each transaction is only allowed
> a single ephemeral anchor which is attached but not committed to by the
> SIGHASH_SINGLE|APOAS signature. This results in a 1-input-2-output
> transaction that isn't malleable. If and when we figure out how to un-pin
> these kinds of transactions, this policy can be relaxed, and we can get the
> benefits of aggregated transactions.
>
> Cheers,
> Greg
>
> On Mon, Dec 12, 2022 at 8:39 PM Antoine Riard <antoine.riard at gmail.com>
> wrote:
>
>> Hi list,
>>
>> The following post describes a potential attack vector against
>> eltoo-based Lightning channels, from my understanding also including the
>> recent two-party eltoo w/ punishment construction. While I think this
>> concern has been known for a while among devs, and I believe it's mitigable
>> by adopting an adequate fee-bumping strategy, I still wonder how exactly it
>> affects eltoo-based constructions.
>>
>> AFAICT, the eltoo 2-stage proposal relies on a serie of pre-signed update
>> transactions, of which in the optimistic case only one of them confirms.
>> There is a script-spend path, where an update transaction N can spend an
>> update transaction K, assuming K<N and an aggregated musig for the
>> checksigverify.
>>
>> The attack purpose is to delay the confirmation of the final settlement
>> transaction S, to double-spend a HTLC forwarded by a routing hop. I.e you
>> have Ned the routing hop receiving the HTLC from Mallory upstream and
>> sending the HTLC to Malicia downstream. Thanks to the cltv_expiry_delta,
>> the HTLC forward should be safe as Ned can timeout the HTLC on the
>> Ned-Malicia link before it is timed-out by Mallory on the Mallory-Ned link.
>> In case of timeout failure, Malicia can claim the HTLC forward with the
>> corresponding preimage, at the same block height than Mallory timeout the
>> HTLC, effectively double-spending Ned.
>>
>> The cltv_expiry_delta requested by Ned is equal to N=144.
>>
>> 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, ...
>>
>> 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...
>>
>> While there is a RBF-race, I think this can be easily won by Malicia by
>> mass-connecting on the transaction-relay network and ignoring the Core
>> transaction-relay delay timers (here for privacy purposes iirc).
>>
>> If it holds, I think the attack is economically opportun as long as the
>> sum of the chain of update transactions weight multiplied by the spent
>> feerate is inferior to the sum of HTLC values stolen (upper bounded to
>> `max_htlc_value_in_flight_msat`, not `funding_satoshis`). The attack could
>> be more sound in periods of low-fee, as the number of HTLC exploitable is
>> higher.
>>
>> A mitigation could be for a fee-bumping strategy to adopt a scorched
>> approach when the HTLC-timeout is approaching, and there is a corresponding
>> incoming HTLC. When the HTLC-timeout is near expiration (e.g X blocks from
>> incoming HTLC expiry), probably 100% of the HTLC value should be burnt in
>> update transaction fees.
>>
>> I think some implementations in the LN-penalty are already doing "upward"
>> fee-bumping frequency, while I believe it reduces the attack surface, I
>> still think there is an exploitable window for "update overflow" attack.
>> E.g in LDK justice transactions are bumped by 25% every block according to
>> a height timer schedule [0].
>>
>> Assuming the attack holds, and scorched approach are adopted by default
>> to mitigate this concern, there is a second-order concern, we might open
>> Lightning channels to miner-harvesting attacks, where the confirmation of
>> the update transactions are deferred to kick-out the scorched earth
>> reaction of the fee-bumping engine. In my opinion, this would be still an
>> improvement, as we're moving a (plausible) security risk triggerable by a
>> Lightning counterparty to (hypothetical) one triggerable by a wide
>> coalition of miners.
>>
>> There is another caveat, it sounds if the update transaction can be
>> malleable (i.e SIGHASH_SINGLE|ANYONECANPAY), update transactions across
>> Lightning channels could be aggregated by the attacker, changing the
>> economy there in a way defavorable to the victims. I.e the attacker can
>> select the targeted channels, but the victim cannot coordinate with each
>> other to respond with a collective fee-bumping.
>>
>> Is the understanding of the two-party eltoo construction correct, and
>> this "update overflow" attack is sound and economically opportun ? If it
>> holds, I still wonder if we have variants playing with mempool descendant
>> limits. In all cases, it sounds to me the implications are more in the way
>> fee-bumping is implemented by Lightning softwares rather than directly on
>> eltoo-based constructions, I don't see an immediate way to address it by
>> the construction itself.
>>
>> Mistakes and confusions are my own.
>>
>> Antoine
>>
>> [0]
>> https://github.com/lightningdevkit/rust-lightning/blob/5e14c24a11f610ab8c402f788ec5bd637e9e24af/lightning/src/chain/onchaintx.rs#L505
>> _______________________________________________
>> 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/20221213/0dc36ccc/attachment-0001.html>

2023-06-09 13:07:43

- reply

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

2023-06-09 13:07:42

- reply

📅 Original date posted:2022-12-12
📝 Original message:
Hi list,
The following post describes a potential attack vector against eltoo-based
Lightning channels, from my understanding also including the recent
two-party eltoo w/ punishment construction. While I think this concern has
been known for a while among devs, and I believe it's mitigable by adopting
an adequate fee-bumping strategy, I still wonder how exactly it affects
eltoo-based constructions.
AFAICT, the eltoo 2-stage proposal relies on a serie of pre-signed update
transactions, of which in the optimistic case only one of them confirms.
There is a script-spend path, where an update transaction N can spend an
update transaction K, assuming K<N and an aggregated musig for the
checksigverify.
The attack purpose is to delay the confirmation of the final settlement
transaction S, to double-spend a HTLC forwarded by a routing hop. I.e you
have Ned the routing hop receiving the HTLC from Mallory upstream and
sending the HTLC to Malicia downstream. Thanks to the cltv_expiry_delta,
the HTLC forward should be safe as Ned can timeout the HTLC on the
Ned-Malicia link before it is timed-out by Mallory on the Mallory-Ned link.
In case of timeout failure, Malicia can claim the HTLC forward with the
corresponding preimage, at the same block height than Mallory timeout the
HTLC, effectively double-spending Ned.
The cltv_expiry_delta requested by Ned is equal to N=144.
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, ...
>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...
While there is a RBF-race, I think this can be easily won by Malicia by
mass-connecting on the transaction-relay network and ignoring the Core
transaction-relay delay timers (here for privacy purposes iirc).
If it holds, I think the attack is economically opportun as long as the sum
of the chain of update transactions weight multiplied by the spent feerate
is inferior to the sum of HTLC values stolen (upper bounded to
`max_htlc_value_in_flight_msat`, not `funding_satoshis`). The attack could
be more sound in periods of low-fee, as the number of HTLC exploitable is
higher.
A mitigation could be for a fee-bumping strategy to adopt a scorched
approach when the HTLC-timeout is approaching, and there is a corresponding
incoming HTLC. When the HTLC-timeout is near expiration (e.g X blocks from
incoming HTLC expiry), probably 100% of the HTLC value should be burnt in
update transaction fees.
I think some implementations in the LN-penalty are already doing "upward"
fee-bumping frequency, while I believe it reduces the attack surface, I
still think there is an exploitable window for "update overflow" attack.
E.g in LDK justice transactions are bumped by 25% every block according to
a height timer schedule [0].
Assuming the attack holds, and scorched approach are adopted by default to
mitigate this concern, there is a second-order concern, we might open
Lightning channels to miner-harvesting attacks, where the confirmation of
the update transactions are deferred to kick-out the scorched earth
reaction of the fee-bumping engine. In my opinion, this would be still an
improvement, as we're moving a (plausible) security risk triggerable by a
Lightning counterparty to (hypothetical) one triggerable by a wide
coalition of miners.
There is another caveat, it sounds if the update transaction can be
malleable (i.e SIGHASH_SINGLE|ANYONECANPAY), update transactions across
Lightning channels could be aggregated by the attacker, changing the
economy there in a way defavorable to the victims. I.e the attacker can
select the targeted channels, but the victim cannot coordinate with each
other to respond with a collective fee-bumping.
Is the understanding of the two-party eltoo construction correct, and this
"update overflow" attack is sound and economically opportun ? If it holds,
I still wonder if we have variants playing with mempool descendant limits.
In all cases, it sounds to me the implications are more in the way
fee-bumping is implemented by Lightning softwares rather than directly on
eltoo-based constructions, I don't see an immediate way to address it by
the construction itself.
Mistakes and confusions are my own.
Antoine
[0]
https://github.com/lightningdevkit/rust-lightning/blob/5e14c24a11f610ab8c402f788ec5bd637e9e24af/lightning/src/chain/onchaintx.rs#L505
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20221212/d9abd7ad/attachment.html>

2023-06-09 13:07:40

- reply

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

2023-06-09 13:07:37

- reply

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

2023-06-09 13:07:34

- reply

📅 Original date posted:2022-12-06
📝 Original message:
Hi Joost,
> The economic proportionality is that an attacker can't do much with a
> severely limited channel, and would need many more to achieve the same
> effect. I don't think it is possible to eliminate all bad behavior, and
> that the goal should just be to make it a lot harder than it currently is.
> Not sure how force-closes come into play. I don't think there needs to be
> any force-close?
I think I share the assumption that you're restraining the ability of a
jamming attacker by applying congestion control, though it sounds only a
hindrance and there might still be an asymmetry between the on-chain
opening channel cost encumbered by the attacker and the gain from hijacking
HTLC traffic. Force-close would be a means to increase the cost for the
attacker by slashing the channel source of jamming.
Though, I think in the design of jammign solution, there is a conceptual
step to define first what we aim to achieve by making a routing hop
"jamming safe", either putting a cost so high on the attacker it's not
economically profitable (from my understanding the direction of
circuitbreaker, or old stake certificates) or guaranteeing routing fees
incomes to the routing hop, whatever the outcome of the HTLC traffic (more
the direction of unconditional fees or reputational credentials).
Best,
Antoine
Le sam. 3 déc. 2022 à 02:50, Joost Jager <joost.jager at gmail.com> a écrit :
> Hi Antoine,
>
> If I understand correctly circuitbreaker, it adds new "dynamic" HTLC slot
>> limits, in opposition to the "static" ones declared to your counterparty
>> during channel opening (within the protocol-limit of 483). On top, you can
>> rate-limit the HTLCs forwards based on the incoming source.
>>
>
> Correct.
>
>
>> Effectively, this scheme would penalize your own routing hop as HTLC
>> senders routing algorithms would likely cause the hop, in the lack of a new
>> gossip message advertising the limits/rates. Further, it sounds for the
>> measure to be robust, a circuitbreaking policy should be applied
>> recursively by your counterparty on their network topologies. Otherwise,
>> you're opening I think you'll have the non-constrained links being targeted
>> as entry points in the rate-limited, "jamming-safe" subset of the graph.
>>
>
> Indeed, the more nodes run it, the harder it becomes for attackers to
> attack. You'd only penalize your own routing node if you send back
> failures. If you hold the htlc, there is no penalty with the network as it
> is currently.
>
>
>> The limits could be based on HTLC values, e.g the Xth slots for HTLCs of
>> value <1k sats, the Yth slots for HTLC of value <100k sats, the remaining
>> Zth slots for HTLC of value <200k sats. IIRC, this jamming countermeasure
>> has been implemented by Eclair [0] and discussed more in detail here [1].
>> While it increases the liquidity cost for an attacker to launch jamming
>> attacks against the high-value slots, it comes at the major downside of
>> lowering the cost for jamming low-value slots. Betting on an increasing
>> bitcoin price, all other things equals, we'll make simple payments from
>> lambda users more and more vulnerable.
>>
>
> It is true that the limits make it easier to jam a channel, but the theory
> is that everyone does it, the attacker won't have much reach anymore.
>
>
>> Beyond that, I think this solution would classify in the reputation-based
>> family of solutions, where reputation is local and enforced through
>> rate-limiting (from my understanding), I would say there is no economic
>> proportionality enforced between the rate-limiting and the cost for an
>> attacker. A jamming attacker could open new channels during period of
>> low-fees in the edges of the graph, and still launch attacks against
>> distant hops by splitting the jamming traffic between many sources,
>> therefore avoiding force-closures (e.g 230 HTLCs from channel Mallory, 253
>> HTLCs from channel Malicia). Even force-closure in case of observed jamming
>> isn't that evident, as the economic traffic could still be opportunistic
>> locally but only a jam on a distant hop. So I think the economic
>> equilibrium and risk structure of this scheme is still uncertain.
>>
>
> The economic proportionality is that an attacker can't do much with a
> severely limited channel, and would need many more to achieve the same
> effect. I don't think it is possible to eliminate all bad behavior, and
> that the goal should just be to make it a lot harder than it currently is.
> Not sure how force-closes come into play. I don't think there needs to be
> any force-close? I just mentioned them in my original post because they can
> happen for independent reasons (bug, node offline), and then the size of
> the commitment tx and number of pending htlcs translates to a real cost.
>
>
>> However, I think the mode of queuing HTLCs is still valuable itself,
>> independently of jamming, either a) to increase routed privacy of HTLC (e.g
>> "delay my HTLC" option [2]), maybe with double opt-in of both senders/hops
>> or b) as a congestion control mechanism where you have >100% of honest
>> incoming HTLC traffic and you would like to earn routing fees on all of
>> them, in the limit of what the outgoing CLTV allow you. An advanced idea
>> could be based on statistics collection, sending back-pressure messages or
>> HTLC sending scheduling information to the upstream hops. Let's say in the
>> future we have more periodic payments, those ones could be scheduled in
>> periods of low-congestions.
>>
>> So I wonder if we don't have two (or even more) problems when we think
>> about jamming, the first one, the HTLC forward "counterparty risk" (the
>> real jamming) and the other one, congestion and scheduling of efficient
>> HTLC traffic, with some interdependencies between them of course.
>>
>
> Yes, so the main idea that I tried to present is that applying congestion
> control by holding htlcs may wake up everyone along the path back to the
> attacker and move them to apply congestion control too.
>
>
>> On experimenting with circuitbreaker, I don't know which HTLC
>> intercepting interface it does expect, we still have a rudimentary one on
>> the LDK-side only supporting JIT channels use-case.
>>
>
> It connects to lnd's htlc interceptor and htlc events interfaces.
>
> Joost
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20221205/1fa4f5eb/attachment.html>

2023-06-09 13:07:33

- reply

📅 Original date posted:2022-12-02
📝 Original message:
Hi Joost,
If I understand correctly circuitbreaker, it adds new "dynamic" HTLC slot
limits, in opposition to the "static" ones declared to your counterparty
during channel opening (within the protocol-limit of 483). On top, you can
rate-limit the HTLCs forwards based on the incoming source.
Effectively, this scheme would penalize your own routing hop as HTLC
senders routing algorithms would likely cause the hop, in the lack of a new
gossip message advertising the limits/rates. Further, it sounds for the
measure to be robust, a circuitbreaking policy should be applied
recursively by your counterparty on their network topologies. Otherwise,
you're opening I think you'll have the non-constrained links being targeted
as entry points in the rate-limited, "jamming-safe" subset of the graph.
The limits could be based on HTLC values, e.g the Xth slots for HTLCs of
value <1k sats, the Yth slots for HTLC of value <100k sats, the remaining
Zth slots for HTLC of value <200k sats. IIRC, this jamming countermeasure
has been implemented by Eclair [0] and discussed more in detail here [1].
While it increases the liquidity cost for an attacker to launch jamming
attacks against the high-value slots, it comes at the major downside of
lowering the cost for jamming low-value slots. Betting on an increasing
bitcoin price, all other things equals, we'll make simple payments from
lambda users more and more vulnerable.
Beyond that, I think this solution would classify in the reputation-based
family of solutions, where reputation is local and enforced through
rate-limiting (from my understanding), I would say there is no economic
proportionality enforced between the rate-limiting and the cost for an
attacker. A jamming attacker could open new channels during period of
low-fees in the edges of the graph, and still launch attacks against
distant hops by splitting the jamming traffic between many sources,
therefore avoiding force-closures (e.g 230 HTLCs from channel Mallory, 253
HTLCs from channel Malicia). Even force-closure in case of observed jamming
isn't that evident, as the economic traffic could still be opportunistic
locally but only a jam on a distant hop. So I think the economic
equilibrium and risk structure of this scheme is still uncertain.
However, I think the mode of queuing HTLCs is still valuable itself,
independently of jamming, either a) to increase routed privacy of HTLC (e.g
"delay my HTLC" option [2]), maybe with double opt-in of both senders/hops
or b) as a congestion control mechanism where you have >100% of honest
incoming HTLC traffic and you would like to earn routing fees on all of
them, in the limit of what the outgoing CLTV allow you. An advanced idea
could be based on statistics collection, sending back-pressure messages or
HTLC sending scheduling information to the upstream hops. Let's say in the
future we have more periodic payments, those ones could be scheduled in
periods of low-congestions.
So I wonder if we don't have two (or even more) problems when we think
about jamming, the first one, the HTLC forward "counterparty risk" (the
real jamming) and the other one, congestion and scheduling of efficient
HTLC traffic, with some interdependencies between them of course.
On experimenting with circuitbreaker, I don't know which HTLC intercepting
interface it does expect, we still have a rudimentary one on the LDK-side
only supporting JIT channels use-case.
Best,
Antoine
[0] https://github.com/ACINQ/eclair/pull/2330
[1] https://jamming-dev.github.io/book/about.html
[2] https://github.com/lightning/bolts/issues/1008
[3] https://github.com/lightningdevkit/rust-lightning/pull/1835
Le ven. 2 déc. 2022 à 13:00, Joost Jager <joost.jager at gmail.com> a écrit :
> A simple but imperfect way to deal with channel jamming and spamming is to
> install a lightning firewall such as circuitbreaker [1]. It allows you to
> set limits like a maximum number of pending htlcs (fight jamming) and/or a
> rate limit (fight spamming). Incoming htlcs that exceed one of the limits
> are failed back.
>
> Unfortunately there are problems with this approach. Failures probably
> lead to extra retries which increases the load on the network as a whole.
> Senders are also taking note of the failure, penalizing you and favoring
> other nodes that do not apply limits. With a large part of the network
> applying limits, it will probably work better because misbehaving nodes
> have fewer opportunities to affect distant nodes. Then it also becomes less
> likely that limits are applied to traffic coming from well-behaving nodes,
> and the reputation of routing nodes isn’t degraded as much.
>
> But how to get to the point where restrictions are applied generally?
> Currently there isn’t too much of a reason for routing nodes to constrain
> their peers, and as explained above it may even be bad for business.
>
> Instead of failing, an alternative course of action for htlcs that exceed
> a limit is to hold and queue them. For example, if htlcs come in at a high
> rate, they’ll just be stacking up on the incoming side and are gradually
> forwarded when their time has come.
>
> An advantage of this is that a routing node’s reputation isn’t affected
> because there are no failures. This however may change in the future with
> fat errors [2]. It will then become possible for senders to identify slow
> nodes, and the no-penalty advantage may go away.
>
> A more important effect of holding is that the upstream nodes are punished
> for the bad traffic that they facilitate. They see their htlc slots
> occupied and funds frozen. They can’t coop close, and a force-close may be
> expensive depending on the number of htlcs that materialize on the
> commitment transaction. This could be a reason for them to take a careful
> look at the source of that traffic, and also start applying limits. Limits
> propagating recursively across the network and pushing bad senders into
> corners where they can’t do much harm anymore. It’s sort of paradoxical:
> jamming channels to stop jamming.
>
> One thing to note is that routing nodes employing the hold strategy are
> potentially punishing themselves too. If they are the initiator of a
> channel with many pending htlcs, the commit fee for them to pay can be high
> in the case of a force-close. They do not need to sweep the htlcs that were
> extended by their peer, but still. One way around this is to only use the
> hold strategy for channels that the routing node did not initiate, and use
> the fail action or no limit at all for self-initiated channels.
>
> Interested to hear opinions on the idea. I’ve also updated circuitbreaker
> with a queue mode for anyone willing to experiment with it [3].
>
> [1] https://github.com/lightningequipment/circuitbreaker
> [2]
> https://lists.linuxfoundation.org/pipermail/lightning-dev/2022-October/003723.html
> [3] https://github.com/lightningequipment/circuitbreaker/pull/14
> _______________________________________________
> 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/20221202/5cdcb76a/attachment-0001.html>

2023-06-09 13:07:33

- reply

📅 Original date posted:2022-12-02
📝 Original message:
Hi Loki,
Thanks for raising awareness on this project.
I share the sentiment on the gradual generalization of Lightning onion
messaging as a transport network on its own for Bitcoin-specific traffic
such as offers, offline receive control flow or credentials tokens or even
in the future DLC offers. I don't know about the extension as a
fully-fledged anonymity network such as Tor or I2P, we'll have issues with
DoS too there [0] [1].
On a mechanism to improve the reliability of path-finding, have a look at
the recent fat errors proposal [1] (probably a needed piece for
reputational credentials too).
Best,
Antoine
[0]
https://lists.linuxfoundation.org/pipermail/lightning-dev/2022-June/003623.html
[1]
https://lists.linuxfoundation.org/pipermail/lightning-dev/2022-July/003660.html
[2] https://github.com/lightning/bolts/pull/1044
Le ven. 2 déc. 2022 à 07:33, Loki Verloren via Lightning-dev <
lightning-dev at lists.linuxfoundation.org> a écrit :
> This subject makes a strong argument, along with the onion routed
> messaging part of Bolt 12 for an independent, Lightning funded onion
> routing relay network, over which all such kinds of traffic and security
> can be provided.
>
> I'm working on such a project, which will be initially built to support
> LND/BTCD/Neutrino: https://github.com/Indra-Labs/indra One of its key
> innovations is a mechanism for path tracing, which enables the deduction of
> likely nodes that are currently not functioning correctly or malicious or
> offline or congested, via a process of deduction, while keeping the client
> originating traffic hidden from nodes in the path.
>
> Channels running across this overlay network would not be possible to jam
> and with many nodes a lot of traffic would pass through opaque tunnels,
> which would make jamming harder. The payment scheme in it also might work
> as a full solution to the adding of a cost against attempts to jam
> channels. My current idea for reputation is just a simple measure of client
> success ranking nodes by how recent and reliable they are, creating a loose
> consensus on the network of which nodes are better connected and
> dependable. Because it will use a median/zip merging process for evaluating
> the nodes it is hard for an adversary to damage the reputation of good
> nodes without also having to run a lot of nodes and for those nodes to also
> develop a good reputation.
>
> Anyway, just some thoughts on the subject, not sure how useful or correct
> they are at this point.
>
>
> Sent with Proton Mail <https://proton.me/> secure email.
> _______________________________________________
> 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/20221202/83fed228/attachment.html>

2023-06-09 13:07:31

- reply

📅 Original date posted:2022-12-01
📝 Original message:
Hi Dave & Zeeman,
As the credentials tokens should be blinded during countersigning and then
wrapped inside HTLC onions, the routing hops cannot use them to assign
blame. Instead the jamming attack prevention efficiency relies on
misbehaving senders exhausting their supply of scarce and costly tokens. A
naive blinding should still enable delegation -- Bob can share his Ned's
tokens with Mallory, and she could consume them to waste Ned routing
liquidity. However Bob should have borne the acquisition cost.
This delegation could happen in a trampoline flow, where Bob attaches
on-the-flight his Ned tokens to Alice's HTLC. This naive attachment
shouldn't leak the delegation fact itself to the routing hops.
About the economic relationships between LSPs and their clients, it sounds
effectively possible the token harvesting to be done at the LSP-level,
where over-supply of tokens are resold to the LSP in exchange of other
advantages (e.g discount on JIT channels). This over-supply can be assigned
to newer clients, devoid of credentials token, at condition there is still
a costly bound enforced by the LSP, to avoid a jamming adversary exploiting
the cost asymmetry (e.g presence of channels). This asymmetry exploitation
would be detrimental to the _LSP zone_, not the tokens issuer routing hop,
as the original compensation must have been paid by the LSP.
It should be noted, a reasonable routing policy might be to additionally
reward HTLC on "favorable" incoming links, as a means to incentive the
maintenance of the open link. However this creates asymmetry if the
incoming link operator allows free credential tokens earned by its clients.
On the jamming vectors opened by an adversary having collected a large
stock of tokens, the routing hops should be still economically "safe", as
long as there is a strict equality between the credentials acquisition cost
and the routing fees. E.g wasting liquidity worth 1000 sats of routing fees
should have been compensated by credentials worth 1000 sats, therefore the
routing hops still earn an income. Note, one of the insights of
"staking/reputational" credentials is to pour the original HTLC forwarding
risk on the sender, while making this risk "fine-grained" and "flexible" in
its allocation.
While the routing fees would vary in function of multiple factors (e.g
network-wide channels congestion) the credentials token acquisition cost
should stay identical, otherwise you're offering exploitable asymmetries to
an attacker.
On the argument that jamming would be solved as the attacker has to
sacrifice opportunity costs of its own liquidity, I think such a position
forgets few elements. Such as the fact one channel can tied up liquidity
for many links, jammed channel might have higher return rate than attacker
liquidity due to routing algorithms historical data, the damage inflicted
might be merchant goods themselves far beyond the attacker opportunity
costs, the opportunity cost between attacker and victims might not be
symmetric because the attacker have large liquidity reserves (e.g an
attacker blocking new incumbents).
Best,
Antoine
Le lun. 28 nov. 2022 à 06:50, ZmnSCPxj <ZmnSCPxj at protonmail.com> a écrit :
> Good morning David,
>
> > On 2022-11-25 13:12, ZmnSCPxj via Lightning-dev wrote:
> >
> > > If I am an LSP, and I know my competitor LSP distributes their
> > > credentials, then I can simply apply to be a spoke on my competitor
> > > and then make several payments to my node, which I then jam up.
> > > This reduces the reputation of my competitor LSP.
> >
> >
> > I don't think this how Riard's credentials work. The credential tokens
> > are blinded, so forwarding nodes can't use them to determine the origin
> > of the payment---thus they can't assign blame.
> >
> > As I understand them, credential tokens prevent DoS by each token only
> > allowing the one-time creation of a single HTLC, so any failed payment
> > reduces the sender's supply of tokens. That means, if Mallory becomes a
> > client of Bob's and Bob lets Mallory use some of his tokens, Mallory can
> > destroy those tokens. Although that's bad for Bob, he can easily limit
> > the damage by not giving Mallory more tokens after too many failures.
> > If Bob obtained his tokens at a low cost (e.g. by sending many payments
> > that were successful and receiving back >100% of the tokens he used to
> >
> > make those payments) and if Alice has to pay a similar or greater cost
> > to become a client of Bob's (e.g. onchain channel open costs), then the
> > attack should not be economically rational.
>
> The usual response is to subsequently attack the mitigation, this is a
> general technique that works on pretty much anything.
>
> Mallory can run multiple nodes.
> Mallory can then initially buy a small number of tokens.
> Then Mallory sends payments back and forth ensuring success, receiving
> back >100% tokens used.
> This gives Mallory a large number of tokens.
>
> Finally, Mallory launches a wide attack on the network by using its
> harvested tokens (from the >100% token return from successful payment
> resolution), trading off reputation for whatever they might gain by
> attacking the LN.
>
> Unless forwarding nodes charge a large fee on successful resolution of
> payments, such that the >100% return on tokens is equal to the cost of
> buying the extra tokens "fresh", then this makes launching the attack
> cheaper.
>
>
> > > Thus all reputation still rests with ultimate senders, who have to
> > > convince LSPs to sell their reputation to them, because they might
> > > secretly be competitor LSPs who have incentive to drain their
> > > reputation.
> > >
> > > If the price of sold reputation is too high, then it is no different
> > > from upfront fees.
> > >
> > > If the price of sold reputation is too low, then I can drain the
> > > reputation of competitor LSPs.
> >
> >
> > I think the statement at the top about reputation resting with ultimate
> > senders is true but two conditionals below it are not quite right. If
> > an LSP helps many clients make successful payments, those clients may
> > (at no additional cost to them beyond the forwarding fees they already
> > paid) receive more credential tokens than they'll ever need. By
> > allowing the LSP to instead use those tokens for other clients
> > ("harvesting" them), it's possible for those later clients to avoid
> > paying for credential tokens---this is equivalent to free upfront fees.
> > As long as the LSP can prevent a client from using too many tokens, and
> > requires the client pay other inescapable costs, then it shouldn't be
> > possible for a competitor to substantially drain the token capital of a
> > LSP without losing a substantial amount of its own money.
>
> It is helpful to consider that jamming attacks require that jamming
> attackers tie up their funds on Lightning too.
> So while a jamming attacker can impose opportunity costs on the rest of
> the network, it also sacrifices opportunity to instead use the same funds
> in forwarding.
> Thus a jamming attacker can impose costs on others by also losing a
> substantial amount (in terms of lost opportunity to instead use the same
> locked funds to earn forwarding fees), meaning that if you are going to
> make that argument, then the original problem was already solved by its own
> structure.
>
> Regards,
> ZmnSCPxj
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20221201/05b770e8/attachment-0001.html>

2023-06-09 13:07:31

- reply

📅 Original date posted:2022-12-01
📝 Original message:
Hi Zeeman,
I think it is correct to say that if any mechanism to protect against
channel jamming succeeds, the remaining instance of apparent channel
jamming might be accidental. This rate of accident might be still high due
to spontaneous congestion (i.e more HTLC senders than slots/liquidity
available for the core links of the network). With the present credential
tokens scheme the rate of spontaneous failure should still have to be
encumbered by some entity. By default it would be the HTLC sender, as is
the one attaching the tokens, and this sounds to be aligned with incentive
as is the one building a payment path of _reliable_ routing hop.
On the second issue, namely a node B who is a competitor of node A and
accepting node A credentials to provoke a jamming attack against A, I don't
think this is plausible. As long as node A is requesting its _own_ tokens
to accept HTLC forward, there is a compensation for the risk. The behavior
of node B accepting node A to drain traffic through node A, in an attempt
to jam it, would in the present situation benefit node A due to the
credentials acquisition cost.
There is a different idea, I think you're describing, the trust-minimized
exchange of credentials tokens between receivers. Effectively here we can
imagine a Chaumian bank-style construction where the tokens are transferred
in a privacy-fashion, and double-spend flagged out by the bank. However,
this wouldn't prevent a token double-spend against another bank. So it
sounds to me you need some kind of underlying reputation or enforcement
mechanism to make the economics of the bank work ? I.e the bank being a LSP
and force-closing channels in case of double-spend.
It should be noted, even if we assume federation of Chaumian banks leading
to a global secondary market for token transfers, the routing hops should
be still economically safe against jamming attacks, as long as the token
acquisition cost is paid at issuance.
Best,
Antoine
Le jeu. 1 déc. 2022 à 07:28, ZmnSCPxj <ZmnSCPxj at protonmail.com> a écrit :
>
> Good morning Antoine,
>
> > About secondary-markets, the credentials themselves are subject to the
> classic double-spend problem. E.g, Alice can transfer her "Ned" credentials
> both to Bob and Caroll, without any of them getting knowledge of the
> duplication. So it could be expected secondary markets to only happen
> between LSP and their spokes (where "trust" relationships already exist),
> as such harder to formalize.
>
> If this is a problem, would the use of the WabiSabi technique help?
> If my understanding was correct, the WabiSabi paper described a Chaumian
> bank that issues coins of variable amount, with clients able to merge and
> split coins without revealing the amount to the bank/issuer, while allowing
> for non-double-spendable transfer of coins by having the bank sign off on
> all transfers between clients (without the bank becoming aware of the value
> being transferred or the pseudonyms of either client).
>
>
> If transfer of tokens can be made non-double-spendable, then it may be
> feasible for a forwarding node to accept tokens issued by a different
> forwarding node, if the sender also transfers control of those tokens to
> the forwarding node.
> i.e. if a sender has credentials for node A but needs to forward via node
> B, then node B may be willing to accept credentials issued by node A.
> This is similar to the situation where "free banks", in the absence of a
> central bank, are willing to accept paper bearer bonds issued by another
> bank, as this lets them attack the other bank by withdrawing the value
> backing the bond and attempt to trigger a bank run on that other bank (and
> thus remove them from competition).
> Similarly, node B who is a competitor of node A may be willing to accept
> credentials issued by node A, in a forward that goes through node B, as the
> transferred credentials would allow node B to perform a jamming attack on
> node A (and thus remove them from competition).
> Both node A and B can then peacefully resolve the difference without
> attacking via a "clearing house" where they reveal how much of the
> credential issued by the other they have, in much the same way as free
> banks would resolve paper bearer bonds.
>
> Regards,
> ZmnSCPxj
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20221201/57ee379b/attachment.html>

2023-06-09 13:07:29

- reply

📅 Original date posted:2022-11-30
📝 Original message:
Hi Michael,
> I'm not sure why harming routing nodes is any less of a concern than harming the experience of say edge nodes when introducing game-able systems with uncertainty over the edge cases. Especially when iteration of that system might never lead to a solution we are happy with. A whack-a-mole type thing where plugging one hole creates another hole.
The "staking/reputational" credential system I'm devising allows a
routing hop to adopt a 0-risk HTLC forwarding acceptance policy.
Indeed, one can pick up the credential acquisition cost to be equal to
the routing fees, the routing hop is always paid
in advance for the HTLC forward. Exploitable deviation of this
"0-risk" policy should be considered as implementation bugs.
If you can point me precisely where the current proposal is broken or
if you can raise concrete safety risks, we can correct them. As the
thread name said, the protocol is at the stage of a sketch, and it
doesn't pretend more.
> I was under the impression that routing algorithms weren't part of the Lightning protocol spec (BOLTs)? Each Lightning implementation could ship with totally different default routing algorithms (perhaps a> lready do?) and it wouldn't matter. There is no cross implementation compatibility issue with how each Lightning node selects channel counterparties, how it selects routes for payments and tracks which routes did and didn't work.
This is a correct statement. As you were raising a future concern than
"protocol developers [could be] in the position of deciding who
ultimately receives routing fees", reality today they're already. Of
course, anyone can come up with a new routing
algorithm suiting better their needs, than the default one (at least
for LDK we just have a generic `Score` interface). Doing so, they
would probably have to become themselves "protocol developer" so we
might be back to step one. To qualify more
the root concern, at least one I can understand, I think you're
saying, is that routing algorithms should be far more under scrutiny
of the community, as they do have a major influence on the state of
the LN market/"economy".
> I guess we're back into the world of setting defaults and options here that we've just been through with mempoolfullrbf :) If say a LDK user wants to opt into using this reputation system then that's their> prerogative assuming it is merged into say a LDK release. Personally I would want to opt out of this reputation system and do my own assessments of reputations of Lightning nodes and risks I was taking. A> t least until a point when I was comfortable with it which I may never be.
All I can say LDK is many light-years ahead of Core in term of
flexibility (while acknowledging system philosophy difference between
layers), and I think any jamming mitigation strategy should be its own
independent module (as current PoC is doing, see
LDK #1848), what we can do best to lower opt out cost for the user.
Beyond, if you have further questions on this proposed credentials
system to clarify the proposal and what is confusing you I'm
listening.
> Sure I'll take a look. But recall I am worried about edge cases and ways for an attacker to game a reputation system which requires me to get to your level of understanding of channel jamming attacks (whic> h will take me a while given you've written a book [0] about them with Gleb). And I suspect even you and Gleb wouldn't be confident saying that you understand all the edge cases of jamming attacks let alon> e the edge cases of gaming a reputation layer on top.
And with regards to hypothetical edge cases, best we can do in this
direction is flesh out a protocol sketch, ask for wide community
feedback, try to break it ourselves, integrate the lessons piece by
piece, propose a new iteration, and doing it over
and over until we reach a level of consistency and soundness
convincing as many stakeholders as we can in the community. If you can
think about a better process for Bitcoin protocol development, I'll
let you lead by example.
> As I said in my previous post I think this is an interesting area and I can see why you are exploring reputation. Just very skeptical that this is a thing that is ever part of the protocol, is used by all > of the major Lightning implementations, is on by default in all those Lightning implementations etc. And even if it was I would want to opt out of it.
Worst-case scenario if this proposal is never adopted, I hope we would
have learnt a lot on channel jamming and Lightning liquidity flows as
a community. One is better attached to the process, rather than the
outcome.
Best,
Antoine
Le mar. 29 nov. 2022 à 11:25, Michael Folkson <michaelfolkson at protonmail.com>
a écrit :
> > Therefore, in case of loopholes in the system damages are effectively
> borne by the routing hops, without throwing the whole system down.
>
> I'm not sure why harming routing nodes is any less of a concern than
> harming the experience of say edge nodes when introducing game-able systems
> with uncertainty over the edge cases. Especially when iteration of that
> system might never lead to a solution we are happy with. A whack-a-mole
> type thing where plugging one hole creates another hole.
>
> > 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.
>
> I was under the impression that routing algorithms weren't part of the
> Lightning protocol spec (BOLTs)? Each Lightning implementation could ship
> with totally different default routing algorithms (perhaps already do?) and
> it wouldn't matter. There is no cross implementation compatibility issue
> with how each Lightning node selects channel counterparties, how it selects
> routes for payments and tracks which routes did and didn't work.
>
> > 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.
>
> I guess we're back into the world of setting defaults and options here
> that we've just been through with mempoolfullrbf :) If say a LDK user wants
> to opt into using this reputation system then that's their prerogative
> assuming it is merged into say a LDK release. Personally I would want to
> opt out of this reputation system and do my own assessments of reputations
> of Lightning nodes and risks I was taking. At least until a point when I
> was comfortable with it which I may never be.
>
> > I hope you'll take time to browse the proposal as detailed more in
> depth here: https://github.com/lightning/bolts/pull/1043
>
> Sure I'll take a look. But recall I am worried about edge cases and ways
> for an attacker to game a reputation system which requires me to get to
> your level of understanding of channel jamming attacks (which will take me
> a while given you've written a book [0] about them with Gleb). And I
> suspect even you and Gleb wouldn't be confident saying that you understand
> all the edge cases of jamming attacks let alone the edge cases of gaming a
> reputation layer on top.
>
> As I said in my previous post I think this is an interesting area and I
> can see why you are exploring reputation. Just very skeptical that this is
> a thing that is ever part of the protocol, is used by all of the major
> Lightning implementations, is on by default in all those Lightning
> implementations etc. And even if it was I would want to opt out of it.
>
> Thanks
> Michael
>
> [0]: https://jamming-dev.github.io/book/
>
> --
> 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 28th, 2022 at 23:34, Antoine Riard <
> antoine.riard at gmail.com> wrote:
>
> 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/20221129/b2f3c432/attachment-0001.html>

2023-06-09 13:07:28

- reply

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

2023-06-09 13:07:26

- reply

📅 Original date posted:2022-11-28
📝 Original message:
Hi Dave,
I think the issue you're describing about credential tampering by
intermediary nodes is correct. If Alice controls Y along the path
W->X->Y->Zed, she can waste the credentials value provided. Indeed, this
issue generalizes for any classic payment path, where a routing node can
waste the senders credentials allocated on the downstream hops.
As discussed on the corresponding BOLT proposal, "staking/reputational"
credentials are probably be dependent on fat errors to assign payment path
failure correctly:
https://github.com/lightning/bolts/pull/1043#discussion_r1029938977
(even further in the case of blinded path, the senders might need another
round with the recipient to share a subset of the fat error).
Note the usage of blinded path in the aforementioned comment is about
sending back fresh credentials if the HTLC succeeds. One alternative is to
use the per-hop shared secret and wrap them in the return HTLC onion.
Another alternative, a blinded onion route could be registered at HTLC
forward phase, and this blinded path is leveraged for the fresh credentials
refill (I think the quantity of credentials could be a privacy-leak itself,
that you would like to mask).
Best,
Antoine
Le sam. 26 nov. 2022 à 15:48, David A. Harding <dave at dtrt.org> a écrit :
> On 2022-11-21 14:26, Antoine Riard wrote:
> >> Clara Shikhelman wrote:
> >> 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.
>
> I'm not sure I understand this answer, so I'll explain in my own words
> and kindly ask that you tell me if I'm wrong or missing something
> important.
>
> If Alice wants to pay Zed using a blinded path where Zed chooses
> terminal channels W->X->Y->Zed, then Zed will need to provide to Alice
> the encrypted credential tokens for X, and Y. In theory, if Alice
> controls node Y, she can prevent the HTLC from settling and so waste the
> value of Zed's provided tokens for node X. However, Alice shouldn't
> know where Zed's node is in the LN topography and can't be assured that
> he'll forward through her secondary node, so the attack is uncertain to
> work. The attack may also have a cost---Alice may need to buy
> credential tokens for node W and the hops leading to it from her primary
> node---with that cost mitigating the chance of the attack and the
> likelihood that it would be profitable.
>
> Thank you both for the interesting proposal and the insightful
> questions!,
>
> -Dave
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20221128/58fc4c69/attachment.html>

2023-06-09 13:07:25

- reply

📅 Original date posted:2022-11-26
📝 Original message:
Hi Clara,
> Have you done any work on the economic aspects of the new tokens and their
> secondary markets?
About the economic aspects, while I think 0-risk HTLC forwarding acceptance
would require credentials cost to perfectly bind to the routing fees, in an
open market like the LN routing one it is expected routing hops to bump the
liquidity value of their credentials. As such increase their forwarded HTLC
traffic volume, until the failure rate downgrades their routing income
beyond their opportunity costs. How the market of HTLC senders would react
to the liquidity value bump of their credentials, and how a routing node
should pick up this bump to reach their income target is a good research
question, I think.
About secondary-markets, the credentials themselves are subject to the
classic double-spend problem. E.g, Alice can transfer her "Ned" credentials
both to Bob and Caroll, without any of them getting knowledge of the
duplication. So it could be expected secondary markets to only happen
between LSP and their spokes (where "trust" relationships already exist),
as such harder to formalize.
Best,
Antoine
Le ven. 25 nov. 2022 à 10:40, Clara Shikhelman <clara.shikhelman at gmail.com>
a écrit :
> Cool, thanks for that.
>
> Have you done any work on the economic aspects of the new tokens and their
> secondary markets?
>
> On Thu, Nov 24, 2022, 21:22 Antoine Riard <antoine.riard at gmail.com> wrote:
>
>> 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/20221125/92d4609c/attachment-0001.html>

2023-06-09 13:07:25

- reply

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

2023-06-09 13:07:24

- reply

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

2023-06-09 13:07:24

- reply

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

2023-06-09 13:07:23

- reply

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

2023-06-09 13:07:22

- reply

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

2023-06-09 13:07:17

- reply

📅 Original date posted:2022-11-06
📝 Original message:
Hi Clara, Sergei
Congrats for the paper!
Here are a few in-flight thoughts browsing the paper.
On introducing a general framework for evaluating attack mitigations, I
think this is relevant as scarce resources wastes, of which jamming is a
subcase is echoed multiple times not only in Lightning, but in multiple
other L2 protocols. For Lightning: at channel peer selection, or for any
multi-party operation like a dual-funded or splicing, the timevalue of the
UTXOs committed can be wasted by a lazy or malicious counterparty. For
Coinjoin/Swaps: again UTXO opportunity cost can be wasted, or a swap HTLC
holded for nothing. I hold the hope that any solution we can nurture for
jamming could be reused and refined in other Bitcoin "decentralized
financial networks".
On the framework for mitigation evaluation, there are few other dimensions
we have considered in the past with Gleb for our research that could be
relevant to integrate. One is "centralization", the solution shouldn't
centralize sensibly the LN ecosystem around any of its actors: LSP,
Lightning Wallet Providers (e.g watchtower or Greenlight-style infra) or
routing node, where centralization could be defined in terms of "market
entry cost" for new incumbents. "Protocol evolvability" could be another
one, as we don't want a solution rendering the design and operations of
things like offline-receive, trampoline, negative fees, etc harder.
"Ecosystem impacts" was one more category we thought about, e.g introducing
a mass mempool congestion vector (one of the versions of Stakes
Certificates did it...).
For the dimensions of your evaluation framework, the "effectiveness" sounds
to be understood as attacker-centric. However few times after in the paper,
the viewpoint of the routing nodes sounds to be adopted ("compensating them
for the financial damage of jamming", "breakeven point n"). If this
distinction is real, the first way would be more searching for a
game-theory equilibrium whereas much damage is inflicted to the attacker.
The second one would be more to ensure a compensation for the loss income
for the routing nodes. I believe the first approach is limited as the
attacker's resources could overwhelm the victim's economic sustainability,
and rationality might be uneconomic. Maybe those two approaches could be
combined, in the sense that loss income compensation should only be borne
by "identified" attackers, however this doesn't sound the direction taken
by unconditional fees.
About "incentive compatibility", one element valuable to integrate is how
much the existence of scoring algorithms allows the routing nodes to adopt
"honest behaviors" and high-level of service availability. I don't know if
a jamming solution can be devised without considerations of the inner
workings of routing/scoring algorithms, and so far every LN implementation
has its own cooking.
On the structure of the monetary strategy, I think there could be a
solution to implement a proof-of-burn, where the fee is captured in a
commitment output sending to a provably unspendable output. Theoretically,
it's interesting as "unburning" the fee is dependent on counterparty
cooperation, the one potentially encumbering the jamming risk.
Proof-of-work "fee" has been discussed in the past by LN devs, however it
was quickly dismissed, as it would give an edge to the attacker who is able
to gather ASICs farms while completely burning the batteries of LN mobile
clients. It has also been widely discussed to make the fees conditional on
either outgoing HTLC CLTV value or effective duration. For effective
duration, an upfront fee shard could be paid after each clock tick (either
epoch or block-based).
On the structure of reputation strategy, I think one interesting missing
point to me is the blurring of the local/global reputation definition in
Lightning. At least maybe in a way traditionally defined in P2P
litterature. Reputation could be enforced on the HTLC sender, as we've
aimed with Stakes Certificates. The upstream peer reputation is not
accounted for at all. I think it's an open question if the reputation score
of a routing node could be exported across nodes (a behavior that one could
expect if you assume web-of-trust, as the current LN network topology is
heavily based on). On the statement, that attaching reputation to payment
contradicts the LN's privacy-focused goal, I would say it's a light one in
regards to the state of cryptography tools like blinded signature, known
since the 80s.
On the analysis of the unconditional fee, I think my main objection would
be the lack of integration of the time uncertainty of the honest use-cases,
making it hard to classify between quick and slow jamming. As you say "The
borderline between quick and slow jamming depends on a subjective
definition of the maximal honest payment resolution delay" An attacker
should hold all its HTLC jamming for a duration of "maximal honest payment
resolution delay" minus 1. Without even scoping L2s protocol like swaps or
hold-invoice where the effective duration might hold for a few blocks,
modern flows like offline receive where the user has to take manual actions
to settle the HTLC could far extend beyond a few seconds. To develop my
point, fair compensation could aim for the most optimistic flow of
short-held 0.1s payment, however a routing policy could qualify as honest
payment resolution delay duration of as much as a few minutes. This
discrepancy could be exploited by an attacker to inflict an asymmetric
damage to the routing nodes. Of course, one fix could be to scale up the
unconditional fee amount in function of the maximal honest payment
resolution delay accepted by the routing node policy". I wonder if it would
be suitable in terms of UX.
For a routing node, there is the uncertainty of downstream payment path
hops, responsible for some failures, I don't know if it's currently
accounted for in the evaluation of the unconditional fee. If the
unconditional fee paid downstream is too high, there is a moral hazard for
the routing node, they can pocket the fee, depending how much they're
penalized by the sender scoring algorithm.
On the analysis of the reputation mechanism, there is one recursive issue:
you might constrain the incoming HTLC traffic of your peers, even if
they're all honest. Let's say you assign K slots and L satoshis of
liquidity to your upstream peer Carioll, Caroll must know divide by (K, L)
by two to Alice and Bob, even if Alice and Bob each can offer (K, L) of
honest HTLC traffic.
Further, there is also the attack timing asymmetries, in the sense that a
high-reputation score might have been earned in period of low-congestion,
and consumed during period of high-congestion, so it sounds to me
reputation should be quantitative rather to introduce a low-risk/high-risk
binary framework, to account for proportionality. This proportionality
issue is a hard thing, especially if I would like concretely to address
payments with intentionally delayed resolutions in a non-cooperative-only
way.
Lastly, I wonder if there is not some conceptual issue with the chaining of
unconditional fee and local reputation. As I understand the distinction
between quick/slow jamming is based on this idea of maximal honest payment
resolution delay. However, the bypass of this upper bound is only known
_after_ the HTLC forward, and as such it sounds to me the strategie regime
(unconditional fee/local reputation) under which a HTLC forward should be
evaluated is dependent on the knowledge of a future event.
Best,
Antoine
Le jeu. 3 nov. 2022 à 13:25, Clara Shikhelman <clara.shikhelman at gmail.com>
a écrit :
> Hi list,
>
> We would like to share with you our recent research on jamming in
> Lightning. We propose a combination of unconditional (~ upfront) fees and
> local reputation to fight jamming. We believe this can be a basis for an
> efficient and practical solution that can be implemented in the foreseeable
> future.
>
> The full paper is available [1].
>
> We classify jams into quick (resolve in seconds, mimicking honest
> payments) and slow (remain in-flight for hours or days). Fees
> disincentivize an attack where quick jams are constantly resolved and sent
> again. Reputation, in turn, allows nodes to deprioritize peers who
> consistently forward slow jams.
>
> We believe that our proposal is practical and efficient. In particular, we
> have shown that the additional (unconditional) fees can be relatively low
> (as low as 2% of the total fee) to fully compensate jamming victims for the
> lost routing revenue. Moreover, the total unconditional fee paid for all
> failed attempts stays low even if the failure rate is reasonably high. This
> means that the UX burden of paying for failed attempts is also low. A
> straightforward PoC implementation [2] demonstrates one approach to
> implementing the fee-related aspect of our proposal.
>
> Further sections provide more details on our approach and results.
>
> # Jamming
>
> As a reminder, jamming is a DoS attack where a malicious sender initiates
> payments (jams) but delays finalizing them, blocking channels along the
> route until the jams are resolved. Jamming may target liquidity or payment
> slots.
>
> We distinguish between quick and slow jamming. Quick jamming implies that
> jams are failed and re-sent every few seconds, making them hardly
> distinguishable from honest failing payments. In slow jamming, jams remain
> in-flight for hours.
>
> # Unconditional fees
>
> We propose unconditional fees to discourage quick jamming. Currently, jams
> are free because routing nodes don’t charge for failed payment attempts.
> With unconditional fees, however, jamming is no longer free.
>
> Our simulations indicate that unconditional fees don’t have to be too
> high. Under certain assumptions about the honest payment flow, a fee
> increase by just 2% (paid upfront) fully compensates a routing node under
> attack. Our simulator is open-source [3]. A PoC implementation demonstrates
> one approach to implementing unconditional fees and only requires minor
> changes [2].
>
> We have also considered the UX implications of paying for failed attempts.
> We have concluded that this should not be a deal-breaker, as the total
> unconditional fee paid stays low even if the failure rate is reasonably
> high (even as high as 50%). Privacy and incentives are also discussed in
> the paper.
>
> # Reputation
>
> Fees are not very effective in preventing slow jamming: this type of
> attack requires only a few jams, therefore, fees would have to be too high
> to be effective. Instead, we address slow jamming using local reputation.
>
> As per our proposal, nodes keep track of their peers’ past behavior. A
> routing node considers its peer “good” if it only forwards honest payments
> that resolve quickly and bring sufficient fee revenue. A peer that forwards
> jams, in contrast, loses reputation. Payments endorsed by a high-reputation
> peer are forwarded on the best efforts basis, while other (“high-risk”)
> payments can only use a predefined quota of liquidity and slots. Unless the
> attacker has built up a reputation in advance, it cannot fully jam a
> channel with at least some liquidity allocated exclusively to low-risk
> payments. Nodes parameterize their channels according to their risk
> tolerance.
>
> # Alternatives and Future Work
>
> In this work, we strive for a systematic approach. First, we list five
> properties a potential mitigation strategy should have: effectiveness,
> incentive compatibility, user experience, privacy and security, and ease of
> implementation. Then, we go over the design decisions to be made when
> constructing a countermeasure against jamming. Based on the desired
> criteria and the available options, we converge on a solution.
>
> Multiple approaches to jamming mitigation have been discussed on this list
> and elsewhere. Many of them may well be worth exploring, such as
> resolution-time-dependent fee amounts or stake certificates for reputation
> building. However, we believe that our solution strikes a good balance: it
> addresses the problem in question and is relatively straightforward to
> implement.
>
> We would love to bring this idea closer to implementation, and we plan to
> discuss it over the next spec meeting [4] (Monday, 2022-11-07). We’d
> greatly appreciate your feedback!
>
> Kind regards,
>
> Sergei and Clara
>
> [1] -
> https://github.com/s-tikhomirov/ln-jamming-simulator/blob/master/unjamming-lightning.pdf
>
>
> [2] - https://github.com/sr-gi/rust-lightning/commit/ce606)
>
> [3] - https://github.com/s-tikhomirov/ln-jamming-simulator
> [4] - https://github.com/lightning/bolts/issues/1038
> _______________________________________________
> 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/20221106/55593583/attachment-0001.html>

2023-06-09 13:06:56

- reply

📅 Original date posted:2022-09-26
📝 Original message:
Hi Dustin,
>From my understanding, splice pinning is problematic for channel funds
safety. In the sense once you have a splice floating in network mempools
and your latest valid commitment transaction pre-signed fees isn't enough
to replace the splice, lack of confirmation might damage the claim of HTLCs.
I don't know if the current splice proposal discourages pending HTLCs
during the splice lifetime, this would at least downgrade the pinning
severity in the splicing case to a simple liquidity timevalue loss.
W.r.t, about the mitigation proposed.
> For “ancestor bulking”, every `tx_add_input` proposed by a peer must be
> included in the UTXO set. A node MUST verify the presence of a proposed
> input before adding it to the splicing transaction.
I think this mitigation requires reliable access to the UTXO set, a
significant constraint for LN mobile clients relying on lightweight
validation backends. While this requirement already exists in matters of
routing to authenticate channel announcements, on the LDK-side we have
alternative infrastructure to offer source-based routing to such a class of
clients, without them having to care about the UTXO set [0]. I don't
exclude there would be infrastructure in the future to access a subset of
the UTXO set (e.g if utreexo is deployed on the p2p network) for
resource-constraint clients, however as of today this is still pure
speculation and vaporware.
In the meantime, mobile clients might not be able to partake in splicing
operations with their LSPs, or without a decrease in trust-minimization
(e.g assuming your LSP doesn't initiate malicious pinnings against you).
> 1) You cannot CPFP a splice transaction. All splices must be RBF’d to be
> fee-bumped. The interactive tx protocol already provides a protocol for
> initiating an RBF, which we re-use for splicing.
The issue with RBF, it assumes interactivity with your counterparties. As
splicing is built on top of the interactive transaction construction
protocol, from my understanding you could have a high order of participants
to coordinate with, without knowledge of their signing policies (e.g if
they're time-constraints) therefore any re-signing operations might have
odds to fail. Moreover, one of these participants could be malicious and
refuses straightly to sign, therefore the already splicing transactions
stay as a pin in the network mempools.
If this concern is correct, I'm not sure we have a current good solution,
the WIP package RBF proposal would be limited to only 2 descendants [1],
and here we might have 3 generations: the splice, a commitment, a CPFP.
[0] https://github.com/lightningdevkit/rapid-gossip-sync-server
[1]
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-September/020937.html
Le mar. 9 août 2022 à 16:15, Dustin Dettmer <dustin at koinkeep.com> a écrit :
> As raised by @crypto-iq and @roasbeef, splices which permit arbitrary
> script and input inclusion are at risk of being mempool pinned. Here we
> present a solution to this splice pinning problem.
>
>
> ## Background
>
> Pinning can be done by building a very large “junk” transaction that
> spends from an important pending one. There are two known pinning vectors:
> ancestor bulking thru addition of new inputs and junk pinning via the
> spending of outputs.
>
>
> Pinning pushes transactions to the bottom of the priority list without a
> practical way of bumping it up. It is in effect a griefing attack, but in
> the case of lightning can risk funds loss for HTLCs that have timed out for
> a pinned commitment transaction.
>
>
> Anchor outputs were introduced to lightning to mitigate the junk pinning
> vector; they work by adding a minimum of `1 CSV` lock to all outputs on
> the commitment transaction except for two “anchor” outputs, one for each
> channel peer. (These take advantage of a 1-tx carve-out exception to enable
> propagation of anchors despite any junk attached to the peer’s anchor).
>
>
> ## Mitigation
>
> Splice transactions are susceptible to both junk and bulk pinning attacks.
> Here’s how we propose mitigating these for splice.
>
>
> [https://i.imgur.com/ayiO1Qt.png]
>
>
> For “ancestor bulking”, every `tx_add_input` proposed by a peer must be
> included in the UTXO set. A node MUST verify the presence of a proposed
> input before adding it to the splicing transaction.
>
>
> For “output junk”, every output included directly in a splice transaction
> MUST be a v0 P2SH witness script which begins with a minimum of `1 CSV`
> relative timelock. No output on the splice transaction will be spendable
> until it is included in a block. This prevents junk pinning by removing the
> ability to propose spends of splice outputs before the transaction is
> included in a block.
>
>
> There are two side effects here.
>
>
> 1) You cannot CPFP a splice transaction. All splices must be RBF’d to be
> fee-bumped. The interactive tx protocol already provides a protocol for
> initiating an RBF, which we re-use for splicing.
>
> 2) Arbitrary 3rd party scriptPubKeys are not permissible directly into the
> splice tx.
>
>
> In order for this to work we need to validate that every output has a 1
> block CSV. There are two output types to consider:
>
> 1. New channel outpoints
> 2. Arbitrary splice out funds
>
>
> For arbitrary splice out, funds can be included in a “fan-out”
> transaction. Here standard pay to address etc outputs can live. The output
> leading to the fan-out transaction will be a P2WSH that also begins with
> [OP_1, OP_CHECKSEQUENCEVERIFY] (referred to from here on as ‘1 CSV’). Each
> splice party SHOULD build a fan-out transaction for all arbitrary spliced
> outputs.
>
>
> [https://i.imgur.com/40Dy3oq.png]
>
>
> Splice-in transactions will not require any fan-out children as long as
> all change goes into the channel outpoint.
>
>
> For new channel outpoints, the v0 witness script should be modified to
> start with [OP_1, OP_CHECKSEQUENCEVERIFY]. It needs to be the first item in
> the script to allow easy validation that it is used and not hidden in a
> false conditional. This would need to be applied to post-splice channel
> outpoints and probably dual funding channels should add it as well so they
> can be successfully included in splices.
>
>
> ### interactive tx protocol changes
>
> For splices, `tx_add_output` MUST include the `witness_script` in the tlv.
> Upon receiving outputs, nodes must validate the script matches the script
> hash in the output and that it begins with a minimum of 1 CSV.
>
>
> ## HTLC Timeouts and Splices
>
> Typically when this technique is used, one or two anchor outputs are added
> to purposely allow for CPFP fee bumping. But, turns out, we already have a
> usable anchor in the original commitment transaction! Very exciting.
>
>
> The interactive tx protocol mandates that splice txs are RBF-enabled.
> Broadcast splice proposals can be replaced out for the original commitment
> transaction at any time. Since the original commitment transaction has
> existing anchors, these may be used to increase fees on a force close. This
> combined with every other output in the tree being locked behind a 1 CSV
> means the force close will always have top mempool priority, mitigating the
> “output junk” style pin.
>
>
> - Nifty & Dusty
> _______________________________________________
> 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/20220926/cd8dcdf3/attachment.html>

2023-06-09 13:06:46

- reply

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

2023-06-09 13:06:42

- reply

📅 Original date posted:2022-08-17
📝 Original message:
Gleb Naumenko and I would like to present our latest research on the
well-known channel jamming attacks affecting the Lightning Network. For a
reminder on the basis of channel jamming, we would like to point to Gleb's
earlier recollection [0].
We have a serie of research posts available here:
https://jamming-dev.github.io/book/
The research is based on Lightning Network data as of March 2022.
Here's the summary.
Chapter 1 (The impacts of channel jamming) where we discuss:
- how the attacker may steal routing fees or target victim's routing
reputation;
- how the attacker may DoS a goods/service provider;
- the monetary implications victims may bear;
- how jamming could enhance probing;
- how jamming may allow an attacker to drag LN users to other payment
solutions.
Chapter 2 (Channel jamming costs) where we:
- discuss the on-chain aspect and the opportunity aspect of attack cost;
- describe cost optimizations (looping, rebalancing, targeting
surroundings);
- notice that the targeted attack costs are currently as low as
thousands of satoshis;
- notice that attacking the entire network requires locking ~million of
sats a month;
- discuss how an attacker may compensate for these costs.
Chapter 3 (Incremental solutions to channel jamming) where we:
- analyze several low-effort solutions to jamming (slot bucketing, JIT
transaction staging, "active defence");
- realize their fundamental trade-offs, strong and weak points;
- discuss slot bucketing in detail (including "0-bucket strategy"), a
good solution candidate.
Chapter 4 (Solution Design Space) where we:
- make a broad overview of potential solutions (bonding to a payment;
reward/punishment incentives);
- identify known and novel families of solutions, discuss their
trade-offs;
- put them in the context of DLC-over-Lightning and other similar "LiFi"
protocols.
Chapter 5 (Hold-time-dependent bidirectional fee schemes) where we:
- overview the most advanced Upfront Payment fee scheme and identify the
trade-offs;
- discuss why it's hard to guarantee a game theoretic balance;
- suggest improvements.
Chapter 6 (The Reputation Scheme: Stake Certificates + Forwarding Pass)
where we:
- suggest a reputation-based solution based on the combination of two
known ideas;
- discuss the associated challenges and the importance of designing a
strong reputation policy.
At the end, we suggest our subjective view on moving forward with this. The
next steps could be either working on more solutions (for which, we
highlight the potential directions) or choosing one of the already
suggested. Among the suggestions, the ecosystem should decide which set of
trade-offs (including solution complexity) is acceptable.
This research should be seen as the synthesis of numerous ideas presented
by other LN developers over the years, and that we can claim original
authorship of really few of them. We made a solid effort to find public
references, though sometimes the ideas have been communicated to us
offline. If you think we missed mentioning the authorship, please let us
know. We also invite the best scrutiny and verification of model
assumptions and research statements. All mistakes or confusions are our own.
Finally, channel jamming has been one of the oldest high-impact issues
mentioned in the Lightning space [1]. It's likely that any solution will
have long-term impacts on the fundamental economic units of the network,
and therefore we hope that such solution finds the consensus of the LN
develoment community as a whole.
Cheers,
Gleb & Antoine
PS: Thanks to the reviewers
[0] https://blog.bitmex.com/preventing-channel-jamming/
[1]
https://lists.linuxfoundation.org/pipermail/lightning-dev/2015-August/000135.html
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20220817/98c8cdc5/attachment.html>

2023-06-09 13:06:36

- reply

📅 Original date posted:2022-07-05
📝 Original message:
Hi Bastien,
Thanks for the proposal,
While I think establishing the rate limiting based on channel topology
should be effective to mitigate against DoS attackers, there is still a
concern that the damage inflicted might be beyond the channel cost. I.e, as
the onion messages routing is source-based, an attacker could exhaust or
reduce targeted onion communication channels to prevent invoices exchanges
between LN peers, and thus disrupt their HTLC traffic. Moreover, if the
HTLC traffic is substitutable ("Good X sold by Merchant Alice can be
substituted by good Y sold by Merchant Mallory"), the attacker could
extract income from the DoS attack, compensating for the channel cost.
If plausible, such targeted onion bandwidth attacks would be fairly
sophisticated so it might not be a concern for the short-term. Though we
might have to introduce some proportion between onion bandwidth units
across the network and the cost of opening channels in the future...
One further concern, we might have "spontaneous" bandwidth DoS in the
future, if the onion traffic is leveraged beyond offers such as for
discovery of LSP liquidity services (e.g PeerSwap, instant inbound
channels, etc). For confidentiality reasons, a LN node might not use the
Noise connections to learn about such services. The LN node might be also
interested to do real market-discovery by fetching the services rates from
all the LSP, while engaging with only one, therefore provoking a spike in
onion bandwidth consumed across the network without symmetric
HTLC traffic. This concern is hypothetical as that class of traffic might
end up announced in gossip.
So I think backpressure based rate limiting is good to boostrap as a
"naive" DoS protection for onion messages though I'm not sure it will be
robust enough in the long-term.
Antoine
Le mer. 29 juin 2022 à 04:28, Bastien TEINTURIER <bastien at acinq.fr> a
écrit :
> During the recent Oakland Dev Summit, some lightning engineers got together to discuss DoS
> protection for onion messages. Rusty proposed a very simple rate-limiting scheme that
> statistically propagates back to the correct sender, which we describe in details below.
>
> You can also read this in gist format if that works better for you [1].
>
> Nodes apply per-peer rate limits on _incoming_ onion messages that should be relayed (e.g.
> N/seconds with some burst tolerance). It is recommended to allow more onion messages from
> peers with whom you have channels, for example 10/seconds when you have a channel and 1/second
> when you don't.
>
> When relaying an onion message, nodes keep track of where it came from (by using the `node_id` of
> the peer who sent that message). Nodes only need the last such `node_id` per outgoing connection,
> which ensures the memory footprint is very small. Also, this data doesn't need to be persisted.
>
> Let's walk through an example to illustrate this mechanism:
>
> * Bob receives an onion message from Alice that should be relayed to Carol
> * After relaying that message, Bob stores Alice's `node_id` in its per-connection state with Carol
> * Bob receives an onion message from Eve that should be relayed to Carol
> * After relaying that message, Bob replaces Alice's `node_id` with Eve's `node_id` in its
> per-connection state with Carol
> * Bob receives an onion message from Alice that should be relayed to Dave
> * After relaying that message, Bob stores Alice's `node_id` in its per-connection state with Dave
> * ...
>
> We introduce a new message that will be sent when dropping an incoming onion message because it
> reached rate limits:
>
> 1. type: 515 (`onion_message_drop`)
> 2. data:
> * [`rate_limited`:`u8`]
> * [`shared_secret_hash`:`32*byte`]
>
> Whenever an incoming onion message reaches the rate limit, the receiver sends `onion_message_drop`
> to the sender. The sender looks at its per-connection state to find where the message was coming
> from and relays `onion_message_drop` to the last sender, halving their rate limits with that peer.
>
> If the sender doesn't overflow the rate limit again, the receiver should double the rate limit
> after 30 seconds, until it reaches the default rate limit again.
>
> The flow will look like:
>
> Alice Bob Carol
> | | |
> | onion_message | |
> |------------------------>| |
> | | onion_message |
> | |------------------------>|
> | | onion_message_drop |
> | |<------------------------|
> | onion_message_drop | |
> |<------------------------| |
>
> The `shared_secret_hash` field contains a BIP 340 tagged hash of the Sphinx shared secret of the
> rate limiting peer (in the example above, Carol):
>
> * `shared_secret_hash = SHA256(SHA256("onion_message_drop") || SHA256("onion_message_drop") || sphinx_shared_secret)`
>
> This value is known by the node that created the onion message: if `onion_message_drop` propagates
> all the way back to them, it lets them know which part of the route is congested, allowing them
> to retry through a different path.
>
> Whenever there is some latency between nodes and many onion messages, `onion_message_drop` may
> be relayed to the incorrect incoming peer (since we only store the `node_id` of the _last_ incoming
> peer in our outgoing connection state). The following example highlights this:
>
> Eve Bob Carol
> | onion_message | |
> |------------------------>| onion_message |
> | onion_message |------------------------>|
> |------------------------>| onion_message |
> | onion_message |------------------------>|
> |------------------------>| onion_message |
> |------------------------>|
> Alice | onion_message_drop |
> | onion_message | +----|
> |------------------------>| onion_message | |
> | |--------------------|--->|
> | | | |
> | | | |
> | | | |
> | onion_message_drop |<-------------------+ |
> |<------------------------| |
>
> In this example, Eve is spamming but `onion_message_drop` is propagated back to Alice instead.
> However, this scheme will _statistically_ penalize the right incoming peer (with a probability
> depending on the volume of onion messages that the spamming peer is generating compared to the
> volume of legitimate onion messages).
>
> It is an interesting research problem to find formulas for those probabilities to evaluate how
> efficient this will be against various types of spam. We hope researchers on this list will be
> interested in looking into it and will come up with a good model to evaluate that scheme.
>
> To increase the accuracy of attributing `onion_message_drop`, more data could be stored in the
> future if it becomes necessary. We need more research to quantify how much accuracy would be
> gained by storing more data and making the protocol more complex.
>
> Cheers,
> Bastien
>
> [1] https://gist.github.com/t-bast/e37ee9249d9825e51d260335c94f0fcf
>
> _______________________________________________
> 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/20220705/ce8d1fbe/attachment.html>

2023-06-09 13:05:40

- reply

📅 Original date posted:2022-03-25
📝 Original message:
Hi Laolu,
Thanks for the proposal, quick feedback.
> It *is* still the case that _ultimately_ the two transactions to close the
> old segwit v0 funding output, and re-open the channel with a new segwit v1
> funding output are unavoidable. However this adapter commitment lets peers
> _defer_ these two transactions until closing time.
I think there is one downside coming with adapter commitment, which is the
uncertainty of the fee overhead at the closing time. Instead of closing
your segwit v0 channel _now_ with known fees, when your commitment is empty
of time-sensitive HTLCs, you're taking the risk of closing during fees
spikes, due a move triggered by your counterparty, when you might have
HTLCs at stake.
It might be more economically rational for a LN node operator to pay the
upgrade cost now if they wish to benefit from the taproot upgrade early,
especially if long-term we expect block fees to increase, or wait when
there is a "normal" cooperative closing.
So it's unclear to me what the economic gain of adapter commitments ?
> In the remainder of this mail, I'll describe an alternative
> approach that would allow upgrading nearly all channel/commitment related
> values (dust limit, max in flight, etc), which is inspired by the way the
> Raft consensus protocol handles configuration/member changes.
Long-term, I think we'll likely need a consensus protocol anyway for
multi-party constructions (channel factories/payment pools). AFAIU this
proposal doesn't aim to roll out a full-fledged consensus protocol *now*
though it could be wise to ensure what we're building slowly moves in this
direction. Less critical code to maintain across bitcoin
codebases/toolchains.
> The role of the signature it to prevent "spoofing" by one of the parties
> (authenticate the param change), and also it serves to convince a party
that
> they actually sent a prior commitment propose update during the
> retransmission phase.
What's the purpose of data origin authentication if we assume only
two-parties running over Noise_XK ?
I think it's already a security property we have. Though if we think we're
going to reuse these dynamic upgrades for N counterparties communicating
through a coordinator, yes I think it's useful.
> In the past, when ideas like this were brought up, some were concerned
that
> it wouldn't really be possible to do this type of updates while existing
> HTLCs were in flight (hence some of the ideas to clear out the commitment
> beforehand).
The dynamic upgrade might serve in an emergency context where we don't have
the leisury to wait for the settlement of the pending HTLCs. The timing of
those ones might be beyond the coordination of link counterparties. Thus,
we have to allow upgrade of non-empty commitments (and if there are
undesirable interferences between new commitment types and HTLCs/PTLCs
present, deal case-by-case).
Antoine
Le jeu. 24 mars 2022 à 18:53, Olaoluwa Osuntokun <laolu32 at gmail.com> a
écrit :
> Hi y'all,
>
> ## Dynamic Commitments Retrospective
>
> Two years-ish ago I made a mailing list post on some ideas re dynamic
> commitments [1], and how the concept can be used to allow us to upgrade
> channel types on the fly, and also remove pesky hard coded limits like the
> 483 HTLC in-flight limit that's present today. Back then my main target was
> upgrading all the existing channels over to the anchor output commitment
> variant, so the core internal routing network would be more resilient in a
> persistent high fee environment (which hasn't really happened over the past
> 2 years for various reasons tbh). Fast forward to today, and with taproot
> now active on mainnet, and some initial design work/sketches for
> taproot-native channels underway, I figure it would be good to bump this
> concept as it gives us a way to upgrade all 80k+ public channels to taproot
> without any on chain transactions.
>
> ## Updating Across Witness Versions w/ Adapter Commitments
>
> In my original mail, I incorrectly concluded that the dynamic commitments
> concept would only really work within the confines of a "static" multi-sig
> output, meaning that it couldn't be used to help channels upgrade to future
> segwit witness versions. Thankfully this reply [2] by ZmnSCPxj, outlined a
> way to achieve this in practice. At a high level he proposes an "adaptor
> commitment" (similar to the kickoff transaction in eltoo/duplex), which is
> basically an upgrade transaction that spends one witness version type, and
> produces an output with the next (upgraded) type. In the context of
> converting from segwit v0 to v1 (taproot), two peers would collaboratively
> create a new adapter commitment that spends the old v0 multi-sig output,
> and
> produces a _new_ v1 multi-sig output. The new commitment transaction would
> then be anchored using this new output.
>
> Here's a rough sequence diagram of the before and after state to better
> convey the concept:
>
> * Before: fundingOutputV0 -> commitmentTransaction
>
> * After fundingOutputV0 -> fundingOutputV1 (the adapter) ->
> commitmentTransaction
>
> It *is* still the case that _ultimately_ the two transactions to close the
> old segwit v0 funding output, and re-open the channel with a new segwit v1
> funding output are unavoidable. However this adapter commitment lets peers
> _defer_ these two transactions until closing time. When force closing two
> transactions need to be confirmed before the commitment outputs can be
> resolved. However, for co-op close, you can just spend the v0 output, and
> deliver to the relevant P2TR outputs. The adapter commitment can leverage
> sighash anyonecanpay to let both parties (assuming it's symmetric) attach
> additional inputs for fees (to avoid introducing the old update_fee related
> static fee issues), or alternatively inherit the anchor output pattern at
> this level.
>
> ## Existing Dynamic Commitments Proposals
>
> Assuming this concept holds up, then we need an actual concrete protocol to
> allow for dynamic commitment updates. Last year, Rusty made a spec PR
> outlining a way to upgrade the commitment type (leveraging the new
> commitment type feature bits) upon channel re-establish [3]. The proposal
> relies on another message that both sides send (`stfu`) to clear the
> commitment (similar to the shutdown semantics) before the switch over
> happens. However as this is tied to the channel re-establish flow, it
> doesn't allow both sides to do things like only allow your peer to attach N
> HTLCs to start with, slowing increasing their allotted slots and possibly
> reducing them (TCP AIMD style).
>
> ## A Two-Phase Dynamic Commitment Update Protocol
>
> IMO if we're adding in a way to do commitment/channel upgrades, then it may
> be worthwhile to go with a more generalized, but slightly more involved
> route instead. In the remainder of this mail, I'll describe an alternative
> approach that would allow upgrading nearly all channel/commitment related
> values (dust limit, max in flight, etc), which is inspired by the way the
> Raft consensus protocol handles configuration/member changes.
>
> For those that aren't aware, Raft is a consensus protocol analogous to
> Paxos
> (but isn't byzantine fault tolerant out of the box) that was designed as a
> more understandable alternative to Paxos for a pedagogical environment.
> Typically the algorithm is run in the context of a fixed cluster with N
> machines, but supports adding/removing machines from the cluster with a
> configuration update protocol. At a high level the way this works is that a
> new config is sent to the leader, with the leader synchronizing the config
> change with the other members of the cluster. Once a majority threshold is
> reached, the leader then commits the config change with the acknowledged
> parties using the new config (basically a two phase commit). I'm skipping
> over some edge cases here that can arise if the new nodes participate
> consensus too early, which can cause a split majority leading to two
> leaders
> being elected.
>
> Applying this to the LN context is a bit simpler than a generalized
> protocol, as we typically just have two parties involved. The initiator is
> already naturally a "leader" in our context, as they're the only ones that
> can do things like trigger fee updates.
>
> ### Message Structure
>
> At a high level I propose we introduce two new messages, with the fields
> looking something like this for `commitment_update_propose`:
> * type: 0 (`channel_id`)
> * value: [`32*byte`:`chan_id`]
> * type: 1 (`propose_sig`)
> * value: [`64*byte`:`sig`]
> * type: 2 (`update_payload`)
> * value: [`*byte`:`tlv_payload`]
>
> and this `commitment_update_apply`:
> * type: 0 (`channel_id`)
> * value: [`32*byte`:`chan_id`]
> * type: 1 (`local_propose`)
> * value: [`*byte`:`commitment_update_propose`]
> * type: 2 (`remote_propose`)
> * value: [`*byte`:`commitment_update_propose`]
>
> ### Protocol Flow
>
> The core idea here is that either party can propose a commitment/channel
> param update, but only the initiator can actually apply it. The
> `commitment_update_propose` encodes the new set of updates, with a
> signature
> covering the TLV blob for the new params (more on why that's needed later).
> The `commitment_update_apply` includes up to _two_
> `commitment_update_propose` messages (one for the initiator and one for the
> responder, as nested TLV messages). The `commitment_update_propose` message
> would be treated like any other `update_*` message, in that it takes a new
> commitment signature to properly commit/apply it.
>
> The normal flow takes the form of both sides sending a
> `commitment_update_propose` message, with the initiator finally committing
> both by sending a `commitment_update_apply` message. In the event that only
> the responder wants to apply a param change/update, then the initiator can
> reply immediately with a `commitment_update_apply` message that doesn't
> include a param change for their commitment (or they just echo the
> parameters if they're acceptable).
>
> ### Handling Retransmissions
>
> The role of the signature it to prevent "spoofing" by one of the parties
> (authenticate the param change), and also it serves to convince a party
> that
> they actually sent a prior commitment propose update during the
> retransmission phase. As the `commitment_update_propose` message would be
> retransmitted like any other message, if the initiator attempts to commit
> the update but the connection dies, they'll retransmit it as normal along
> with their latest signature.
>
> ### Nested TLV Param Generality
>
> The messages as sketched out here just have an opaque nested TLV field
> which
> makes it extensible to add in other things like tweaking the total number
> of
> max HTLCs, the current dust values, min/max HTLCs, etc (all things that are
> currently hard coded for the lifetime of the channel). An initial target
> would likely just be a `chan_type` field, with future feature bits
> governing
> _what_ type of commitment updates both parties understand in the future.
>
> In the past, when ideas like this were brought up, some were concerned that
> it wouldn't really be possible to do this type of updates while existing
> HTLCs were in flight (hence some of the ideas to clear out the commitment
> beforehand). I don't see a reason why this fundamentally _shouldn't_ be
> allowed, as from the point of view of the channel update state machine, all
> updates (adds/removes) get applied as normal, but with this _new_
> commitment
> type/params. The main edge case we'll need to consider is cases where the
> new params make older HTLCs invalid for some reason.
>
> ## Conclusion
>
> Using the adapter commitment idea combined with a protocol for updating
> commitments on the fly, would potentially allow us to update all 80k+
> segwit
> v0 channels to the base level of taprooty channels without any on chain
> transactions. The two transactions (open+close) must happen eventually, but
> by holding another layer of spends off-chain we can defer them (potentially
> indefinitely, as we have channels today that have been opened for over a
> year).
>
> Deploying a generalised on-the-fly dynamic commitment update protocol gives
> us a tool to future proof the _existing_ anchored multi-sig outputs in the
> chain, and also a way to remove many of the hard coded parameters we have
> today in the protocol. One overly inflexible parameter we have today in the
> network is the 483 HTLC limit. Allowing this value to float would allow
> peers to apply similar congestion avoidance algorithm that are used in TCP
> today, and also give us a way to protect the network against future
> unforeseen widespread policy changes (like a raising of the dust limit).
>
> -- Laolu
>
> [1]:
> https://lists.linuxfoundation.org/pipermail/lightning-dev/2020-July/002763.html
> [2]:
> https://lists.linuxfoundation.org/pipermail/lightning-dev/2020-July/002770.html
> [3]: https://github.com/lightning/bolts/pull/868
> _______________________________________________
> 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/20220325/9c2be8e0/attachment-0001.html>

2023-06-09 13:05:28

- reply

📅 Original date posted:2022-03-07
📝 Original message:
Hi Eugene,
> Since the remote party gives them a signature, after the timeout, the
offering party can
claim with the remote's signature + preimage, but can only spend with the
HTLC-timeout transaction because of SIGHASH_ALL.
I've not exercised the witness against our test framework though the
description sounds to me correct.
The offering counterparty spends the offered HTLC output with a
HTLC-timeout transaction where the witness is <<remote_sig>
<payment_preimage>>. SIGHASH_ALL is not committing to the spent Script
branch intended to be used. As you raised, it doesn't alleviate the
offering counterparty to respect the CLTV delay and as such the offered
HTLC timespan cannot be shortened. The implication I can think of, in case
of competing HTLC race, once the absolute timelock is expired, the offering
counterparty is able to compete against the receiving one with a more
feerate-efficient witness. However, from a receiving counterparty safety
viewpoint, if you're already suffering a contest, it means your HTLC-claim
on your own local commitment transaction inbound HTLC output has been
inefficient, and your fee-bumping strategy is to blame.
If we think the issue is relevant, I believe splitting the Script branches
in two tapleaves and having bip342 signature digest committing to the
tapleaf_hash solves it.
Antoine
Le lun. 7 mars 2022 à 15:27, Eugene Siegel <elzeigel at gmail.com> a écrit :
> I'm not sure if this is known, but I'm pretty sure it's benign and so I
> thought I'd share since I found it interesting and maybe someone else will
> too. I'm not sure if this is already known either.
>
>
> https://github.com/lightning/bolts/blob/master/03-transactions.md#offered-htlc-outputs
> Offered HTLCs have three claim paths: the revocation case, the offerer
> claiming through the HTLC-timeout transaction, and the receiver claiming
> via their sig + preimage. The offering party can claim via the HTLC-timeout
> case on their commitment transaction with their signature and the remote's
> signature (SIGHASH_ALL) after the cltv_expiry timeout. Since the remote
> party gives them a signature, after the timeout, the offering party can
> claim with the remote's signature + preimage, but can only spend with the
> HTLC-timeout transaction because of SIGHASH_ALL. This assumes that the
> remote party doesn't claim it first. I can't think of any cases where the
> offering party would know the preimage AND want to force close, so that's
> why I think it's benign. It does make the witness smaller. The same trick
> isn't possible with the Received HTLC's due to OP_CHECKLOCKTIMEVERIFY.
>
> Eugene (Crypt-iQ on github)
> _______________________________________________
> 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/20220307/b55f369a/attachment.html>

2023-06-09 13:04:00

- reply

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

2023-06-09 13:03:59

- reply

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

2023-06-09 13:03:14

- reply

📅 Original date posted:2021-08-09
📝 Original message:
I'm pretty conservative about increasing the standard dust limit in any
way. This would convert a higher percentage of LN channels capacity into
dust, which is coming with a lowering of funds safety [0]. Of course, we
can adjust the LN security model around dust handling to mitigate the
safety risk in case of adversarial settings, but ultimately the standard
dust limit creates a "hard" bound, and as such it introduces a trust
vector in the reliability of your peer to not goes
onchain with a commitment heavily-loaded with dust-HTLC you own.
LN node operators might be willingly to compensate this "dust" trust vector
by relying on side-trust model, such as PKI to authenticate their peers or
API tokens (LSATs, PoW tokens), probably not free from consequences for the
"openness" of the LN topology...
Further, I think any authoritative setting of the dust limit presents the
risk of becoming ill-adjusted w.r.t to market realities after a few months
or years, and would need periodic reevaluations. Those reevaluations, if
not automated, would become a vector of endless dramas and bikeshedding as
the L2s ecosystems grow bigger...
Note, this would also constrain the design space of newer fee schemes. Such
as negotiated-with-mining-pool and discounted consolidation during low
feerate periods deployed by such producers of low-value outputs.
`
Moreover as an operational point, if we proceed to such an increase on the
base-layer, e.g to 20 sat/vb, we're going to severely damage the
propagation of any LN transaction, where a commitment transaction is built
with less than 20 sat/vb outputs. Of course, core's policy deployment on
the base layer is gradual, but we should first give a time window for the
LN ecosystem to upgrade and as of today we're still devoid of the mechanism
to do it cleanly and asynchronously (e.g dynamic upgrade or quiescence
protocol [1]).
That said, as raised by other commentators, I don't deny we have a
long-term tension between L2 nodes and full-nodes operators about the UTXO
set growth, but for now I would rather solve this with smarter engineering
such as utreexo on the base-layer side or multi-party shared-utxo or
compressed colored coins/authentication smart contracts (e.g
opentimestamp's merkle tree in OP_RETURN) on the upper layers rather than
altering the current equilibrium.
I think the status quo is good enough for now, and I believe we would be
better off to learn from another development cycle before tweaking the dust
limit in any sense.
Antoine
[0]
https://lists.linuxfoundation.org/pipermail/lightning-dev/2020-May/002714.html
[1] https://github.com/lightningnetwork/lightning-rfc/pull/869
Le dim. 8 août 2021 à 14:53, Jeremy <jlrubin at mit.edu> a écrit :
> We should remove the dust limit from Bitcoin. Five reasons:
>
> 1) it's not our business what outputs people want to create
> 2) dust outputs can be used in various authentication/delegation smart
> contracts
> 3) dust sized htlcs in lightning (
> https://bitcoin.stackexchange.com/questions/46730/can-you-send-amounts-that-would-typically-be-considered-dust-through-the-light)
> force channels to operate in a semi-trusted mode which has implications
> (AFAIU) for the regulatory classification of channels in various
> jurisdictions; agnostic treatment of fund transfers would simplify this
> (like getting a 0.01 cent dividend check in the mail)
> 4) thinly divisible colored coin protocols might make use of sats as value
> markers for transactions.
> 5) should we ever do confidential transactions we can't prevent it without
> compromising privacy / allowed transfers
>
> The main reasons I'm aware of not allow dust creation is that:
>
> 1) dust is spam
> 2) dust fingerprinting attacks
>
> 1 is (IMO) not valid given the 5 reasons above, and 2 is preventable by
> well behaved wallets to not redeem outputs that cost more in fees than they
> are worth.
>
> cheers,
>
> jeremy
>
> --
> @JeremyRubin <https://twitter.com/JeremyRubin>
> <https://twitter.com/JeremyRubin>
> _______________________________________________
> 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/20210809/83985422/attachment.html>

2023-06-09 13:02:21

- reply

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

2023-06-09 13:02:20

- reply

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

2023-06-09 13:01:38

- reply

📅 Original date posted:2020-12-01
📝 Original message:
Hello Zeeman,
If I understand well the "point-to-point property" is the following : you
can authenticate an incoming HTLC traffic from your neighbors owing to
their expensive channels.
My concern with this approach relies on the fact that a routing node isn't
decisionary of the HTLC traffic going through itself. Thus its outgoing
traffic might be far superior to its locked channel utxos and it will have
to compensate HTLC receiver for the difference. You're back to some fees
mechanism for everyone to do its account.
The interesting property with stake certificates is to overlay the
liquidity effective user with the HTLC sender. This last one should care
about using liquidity resources reasonably, not the routing nodes.
IMO, the more interesting point you're underscoring is that we shouldn't
bind a HTLC traffic volume to a channel size. E.g you have a small channel
but a high HTLC traffic spread through the day and that's lawful. What we
may consider is a stake certificate/point-to-point control only relying on
utxo uniqueness, and not the amount locked. If a utxo-authenticated
HTLC-traffic is far beyond the median, just blacklist the utxo, thus
forcing a utxo spend (and bearing onchain fees) by any liquidity abuser.
Cheers,
Antoine
Le mar. 1 déc. 2020 à 07:11, ZmnSCPxj via Lightning-dev <
lightning-dev at lists.linuxfoundation.org> a écrit :
> Good morning LL, and list,
>
>
> > That's a very interesting point. If we were to be able to prevent loop
> attacks by the sender proving the path is well formed (without revealing
> who they are or any of the other hops) would this be an alternative
> solution?
> > It seems to me that disabling loop attacks might be much easier than
> stake certificates.
>
> Loop attacks are not about loops, it only requires that the start and end
> of a payment are controlled by the same entity.
>
> Multiple nodes on the LN may be owned by the same entity.
> Nodes, individually as nodes, are trivially cheap and just need 32 bytes
> of entropy from a `/dev/random` near you.
> It is the channels themselves, requiring actual funds, high uptime, and
> not being a dick to your counterparty, that are fairly expensive.
>
> Thus, a "loop attack" need not involve a loop per se --- a single entity
> can run any number of nodes with small numbers of channels each, and
> thereby grief the network.
>
> Stake certificates make the node itself expensive, so a single entity
> running a number of nodes cannot perform such loop attacks, since it would
> require entities expensively allocating funds for each node.
>
>
>
>
> On the other hand, if channels are expensive, then a node with channels is
> expensive.
>
> In
> https://lists.linuxfoundation.org/pipermail/lightning-dev/2020-November/002890.html
> , which contains the "Z consideration" you were alluding to, I note that
> the "point-to-point property" is already proven by the ***existing***
> Lightning network without an additional ZK cryptographic proof.
>
> So let me invert that logic and present an even more extreme position:
>
> * There are two griefing attacks:
> * Loop attacks, which are deliberate malicious attacks to lock up funds
> of competitors in order to redirect forwarding towards the attacker.
> * Accidental "attacks", which are accidental due to incompetence, where
> a forwarding node accidentally goes offline and causes payments to be
> locked up for long periods and making everyone on the network cry when
> HTLCs time out and things have to be dropped onchain.
> * The point-to-point property, which is already proven by the
> ***existing*** Lightning network, is already sufficient to prevent loop
> attacks, leaving only accidental incompetence-based "attacks".
> * Or: the ***existing*** Lightning Network ***already*** proves the
> point-to-point property presented by t-bast, and that property is
> ***already*** sufficient to prevent the loop attacks.
>
> So, maybe we should instead focus on mitigating the effects of the
> incompetence-based non-attacks [such as this proposal](
> https://github.com/ElementsProject/lightning/issues/2632#issuecomment-736438980),
> instead of attempting to defend against the mirage of loop attacks.
>
>
> I could be utterly wrong here though.
>
>
> 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/20201201/e432323a/attachment-0001.html>