Nostr notes by

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

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

In reply to nevent1q…yttp
_________________________

📅 Original date posted:2023-10-17
🗒️ Summary of this message: Batched splicing can be risky if certain conditions are met, such as having no funds in a channel and using an old state. It is important for batched splicing mechanisms to have a backout option to prevent disruptions.
📝 Original message:
Good morning Bastien,

I have not gotten around to posting it yet, but I have a write-up in my computer with the title:

> Batched Splicing Considered Risky

The core of the risk is that if:

* I have no funds right now in a channel (e.g. the LSP allowed me to have 0 reserve, or this is a newly-singlefunded channel from the LSP to me).
* I have an old state (e.g. for a newly-singlefunded channel, it could have been `update_fee`d, so that the initial transaction is old state).

Then if I participate in a batched splice, I can disrupt the batched splice by broadcasting the old state and somehow convincing miners to confirm it before the batched splice.

Thus, it is important for *any* batched splicing mechanism to have a backout, where if the batched splice transaction can no longer be confirmed due to some participant disrupting it by posting an old commitment transaction, either a subset of the splice is re-created or the channels revert back to pre-splice state (with knowledge that the post-splice state can no longer be confirmed).

I know that current splicing tech is to run both the pre-splice and post-splice state simultaneously until the splicing transaction is confirmed.
However we need to *also* check if the splicing transaction *cannot* be confirmed --- by checking if the other inputs to the splice transaction were already consumed by transactions that have deeply confirmed, and in that case, to drop the post-splice state and revert to the pre-splice state.
I do not know if existing splice implementations actually perform such a check.
Unless all splice implementations do this, then any kind of batched splicing is risky.

Regards,
ZmnSCPxj

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

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

In reply to nevent1q…8fmu
_________________________

📅 Original date posted:2023-10-17
🗒️ Summary of this message: The summary of the text is that there is a vulnerability in the Lightning Network where a node can cheat and claim funds from an HTLC transaction.
📝 Original message:
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

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

2023-09-07T13:52:31+02:00

In reply to nevent1q…dfyl
_________________________

📅 Original date posted:2023-08-28
🗒️ Summary of this message: The sender is asking about the consequences of modifying the Sentinel Chain software to be dishonest for 999 sidechain blocks and the validation process for the 1000th block.
📝 Original message:
Good morning Ryan,

If I modify your Sentinel Chain open-source software so that it is honest for 999 sidechain blocks, then lies and says that the 1000th block is invalid even though it actually is, what happens?

Do mainchain nodes need to download the previous 999 sidechain blocks, run the sidechain rules on them, and then validate the 1000th sidechain block itself?

Regards,
ZmnSCPxj

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

2023-07-31T00:54:54+02:00

In reply to nevent1q…j7yh
_________________________

📅 Original date posted:2023-07-27
🗒️ Summary of this message: A scheme for creating a `keysend` protocol that allows for multipath payments is proposed, where the receiver can claim the payment once all parts have arrived.
📝 Original message:
Good morning list,

I would like to share a simple scheme for creating a `keysend` protocol that allows for multipath payments.

In `keysend`, the preimage is embedded as TLV 5482373484 with length 32.

In the multipath case, we want the receiver to only be able to claim the payment once all parts have arrived at the receiver.

For example, suppose we want to split the `keysend` into 2 parts.
Let us select a true preimage `p` at random.
Then, we generate the payment hash `h = SHA256(p)`.

Then, we generate a new 256-bit scalar, `a`.
For one part, we send `a` for TLV 5482373484, and for the second part, we send `a ^ p`, where `^` is XOR.
All parts use the same payment hash `h`.

The receiver, on receiving either part, will find that the supposed preimage does not match the actual HTLC payment hashes.
Instead of failing, it holds the payment, using the usual basic multipath payment rules.

When the receiver receives another part, it will XOR together the supposed preimages.
In the above case, it would get `a` and `a ^ p`, which when XORed together result in `a ^ a ^ p` or `p`, which is now the correct preimage, and the receiver can now claim the entire complete funds.

The same technique would work with any number of parts --- if we split into `n` parts, we generate `n - 1` additional random scalars and use it for the first `n - 1` parts, then XOR all of them with the scalar-to-be-split for the `n`th part.
This scheme also works for dynamic splitting, i.e. if you are splitting a part that was already split off from a part that was already split off from a part etc.

A sender can detect if the receiver does not support multipath `keysend` if a part reaches the receiver and it errors with `incorrect_or_unknown_payment_details`.
If the receiver is aware of multipath `keysend`, it would hold onto the incoming HTLCs until MPP timeout, and instead error with `mpp_timeout`.
Thus, support for this on the receiver side does not need to be specially announced via a new feature bit --- an MPP-capable sender can simply try to split, and if it gets an `incorrect_or_unknown_payment_details`, knows that the receiver does not support multipath `keysend`.
The same feature bit 55 can be reused.

Regards,
ZmnSCPxj

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

2023-07-24T13:36:00+02:00

In reply to nevent1q…avcy
_________________________

📅 Original date posted:2023-07-24
🗒️ Summary of this message: MuSig2 requires multiple `R` points, preventing certain attacks. The recipient questions if the scheme's single `R` per party is vulnerable.
📝 Original message:
Good morning Tom,

Would this allow party 2 to itself be composed of N >= 2 parties?

MuSig2 (as opposed to MuSig1) requires that signatories provide multiple `R` points, not just one each, which are finally aggregated by first combining them using the MuSig() public key compose function.
This prevents party 2 from creating an `R` that may allow it to perform certain attacks whose name escapes me right now but which I used to know.
(it is the reason why MuSig1 requires 3 round trips, and why MuSig2 requires at least 2 `R` nonces per signatory)

Your scheme has only one `R` per party, would it not be vulnerably to that attack?

Regards,
ZmnSCPxj

Sent with Proton Mail secure email.

------- Original Message -------
On Monday, July 24th, 2023 at 7:46 AM, Tom Trevethan via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> wrote:

> We are implementing a version of 2-of-2 Schnorr Musig2 for statechains where the server (party 1 in the 2-of-2) will be fully 'blinded' - in that it can hold a private key that is required to generate an aggregate signature on an aggregate public key, but that it does not learn either: 1) The aggregate public key 2) The aggregate signature and 3) The message (m) being signed.
>
> In the model of blinded statechains, the security rests on the statechain server being trusted to report the NUMBER of partial signatures it has generated for a particular key (as opposed to being trusted to enforce rules on WHAT it has signed in the unblinded case) and the full set of signatures generated being verified client side https://github.com/commerceblock/mercury/blob/master/doc/merc_blind.md#blinding-considerations
>
> Given the 2-of-2 musig2 protocol operates as follows (in the following description, private keys (field elements) are denoted using lower case letters, and elliptic curve points as uppercase letters. G is the generator point and point multiplication denoted as X = xG and point addition as A = G + G):
>
> Party 1 generates private key x1 and public key X1 = x1G. Party 2 generates private key x2 and public key X2 = x2G. The set of pubkeys is L = {X1,X2}. The key aggregation coefficient is KeyAggCoef(L,X) = H(L,X). The shared (aggregate) public key X = a1X1 + a2X2 where a1 = KeyAggCoef(L,X1) and a2 = KeyAggCoef(L,X2).
>
> To sign a message m, party 1 generates nonce r1 and R1 = r1G. Party 2 generates nonce r2 and R2 = r2G. These are aggregated into R = R1 + R2.
>
> Party 1 then computes 'challenge' c = H(X||R||m) and s1 = c.a1.x1 + r1
> Party 2 then computes 'challenge' c = H(X||R||m) and s2 = c.a2.x2 + r2
>
> The final signature is then (R,s1+s2).
>
> In the case of blinding this for party 1:
>
> To prevent party 1 from learning of either the full public key or final signature seems straightforward, if party 1 doesn't not need to independently compute and verify c = H(X||R||m) (as they are blinded from the message in any case).
>
> 1) Key aggregation is performed only by party 2. Party 1 just sends X1 to party 2.
> 2) Nonce aggregation is performed only by party 2. Party 1 just sends R1 to party 2.
> 3) Party 2 computes c = H(X||R||m) and sends it to party 1 in order to compute s1 = c.a1.x1 + r1
>
> Party 1 never learns the final value of (R,s1+s2) or m.
>
> Any comments on this or potential issues would be appreciated.
>
> Tom

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

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

In reply to nevent1q…rc3d
_________________________

📅 Original date posted:2023-05-09
🗒️ Summary of this message: A proposal to address liquidity griefing attacks in dual funded transactions by not locking UTXOs and using 0-conf channels for single contributors.
📝 Original message:
Good morning Matt, and t-bast,

Your proposal basically means "do not dual-fund 0-conf".
You might as well use the much simpler openv1 flow in that case, just because it is simpler.

Regards,
ZmnSCPxj

Sent with Proton Mail secure email.

------- Original Message -------
On Tuesday, May 9th, 2023 at 5:38 PM, Matt Morehouse <mattmorehouse at gmail.com> wrote:

> Hi Bastien,
>
> In general, 0-conf is only safe when WE are the only contributor to
> the channel, otherwise the peer could double spend us.
>
> The problem you seem to be describing is that we might double-spend
> ourselves if we don't lock our 0-conf UTXOs at some point. I propose
> that we DO lock our UTXOs after tx_completes have been exchanged IF we
> are the only contributor. We don't have to worry about liquidity
> griefing in this case, since the peer has no tx_signatures to withhold
> from us. Of course, the opportunistic upgrade of a regular channel to
> 0-conf won't work -- we need a way to differentiate 0-conf channels
> prior to UTXO selection, so that we don't reuse soft-locked UTXOs.
>
> All together, what I propose is:
>
> 1) If the channel type has option_zeroconf, select UTXOs that are not
> soft locked.
> 2) If the peer adds any inputs to the funding transaction, abort
> (0-conf is unsafe for us in this case).
> 3) After tx_complete exchange, TryLock() our UTXO inputs and abort if
> already locked.
> 4) Broadcast funding transaction and begin using the 0-conf channel.
>
> I think this at least enables the common use case for 0-conf: LSPs can
> use their own funds to open 0-conf channels for clients.
>
> - Matt
>
>
>
>
> On Sat, May 6, 2023 at 3:16 AM Bastien TEINTURIER bastien at acinq.fr wrote:
>
> > 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
>
> _______________________________________________
> Lightning-dev mailing list
> Lightning-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev

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

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

In reply to nevent1q…y3dh
_________________________

📅 Original date posted:2023-05-07
🗒️ Summary of this message: Dual-funded 0-conf can be made safe if the initiator uses swap-in-potentiam addresses, allowing for immediate transfer to a 0-conf Lightning channel.
📝 Original message:
Good morning t-bast, and list,

Dual-funded 0-conf can be made safe in the following case:

* If the initiator uses swap-in-potentiam addresses (with initiator as Alice, acceptor as Bob).

If the initiator stalls, then the acceptor can retaliate by refusing to sign the swap-in-potentiam UTXOs forever after that, thus also locking their funds until the swap-in-potentiam times out, thus preventing this liquidity griefing from being cost-free.

The expected use-case is that a user expects onchain operations to be slow and take multiple confirmations to receive.
Once there is deep confirmation that a swap-in-potentiam address has been funded, then it can be transferred immediately to a 0-conf Lightning channel.

The initiator still needs to trust that the acceptor does not double-spend out from under the initiator, but see LSPS3 Promise To Unconditionally Fund 0-conf.
Also, it looks like you are allowing for the initiator to trust the acceptor in that case, as I believe you are taking the point of view of the acceptor of the dual-funding flow.

Regards,
ZmnSCPxj

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

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

In reply to nevent1q…0mgr
_________________________

📅 Original date posted:2023-04-04
🗒️ Summary of this message: Swap-in-potentiam addresses provide implicit protection against 0-conf double-spend risk for all operations that move from onchain to Lightning, including channel opens and onchain-to-offchain swaps.
📝 Original message:
Hi ariard and t-bast,

I would like to point out that spends from swap-in-potentiam addresses are safely 0-conf if Bob is the other signatory in the swap-in-potentiam address.

On the other hand swap-in-potentiam is arguably cheating, since sending to a swap-in-potentiam address is actually a channel open of a Spilman-like channel with `OP_CSV` instead of `OP_CLTV`.

This implicit protection against 0-conf double-spend risk that swap-in-potentiam provides, exists for all operations that move from onchain to Lightning, including: channel opens, onchain-to-offchain swap, splice-in.

I should also note that the UTXOs with swap-in-potentiam addressed do need to be confirmed.

--

For cases where the one doing splice-in is an LSP and the other side is a client of that LSP, also consider this proposal: https://github.com/BitcoinAndLightningLayerSpecs/lsp/pull/24

While it is designed for 0-conf channel funding, the actual protocol is generic enough that it can be used where there is double-spend risk from an LSP, that the client wants to protect against.
This can applied to splice-in and channel factory construction, as the protocol is simply a promise "I the LSP will do my best to get the transaction with this TXID confirmed before some future blockheight, so you the client can rest assured that even if it is unconfirmed now (0-conf) you can always rely on it being confirmed later."

Regards,
ZmnSCPxj

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

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

In reply to nevent1q…dx8y
_________________________

📅 Original date posted:2023-04-04
🗒️ Summary of this message: A proposal has been made to protect against double-spend risk from an LSP during splice-in and channel factory construction, but it may be risky for the LSP.
📝 Original message:
Good morning again ariard and t-bast,

>
> For cases where the one doing splice-in is an LSP and the other side is a client of that LSP, also consider this proposal: https://github.com/BitcoinAndLightningLayerSpecs/lsp/pull/24
>
> While it is designed for 0-conf channel funding, the actual protocol is generic enough that it can be used where there is double-spend risk from an LSP, that the client wants to protect against.
> This can applied to splice-in and channel factory construction, as the protocol is simply a promise "I the LSP will do my best to get the transaction with this TXID confirmed before some future blockheight, so you the client can rest assured that even if it is unconfirmed now (0-conf) you can always rely on it being confirmed later."

Actually, given that the LSP is held liable if the TXID never confirms, and the splice TXID has as input the previous funding txo, this is actually risky for the LSP.

Even if the client has given revocation keys for all states dependent on the previous funding txo, the client can still post, and have confirmed, a revoked state.
This prevents the LSP from ever getting the splice TXID confirmed.
The client loses all its funds in the channel, but in exchange the LSP is held liable for not getting the splice TXID confirmed and the LSP reputation is destroyed.

Regards,
ZmnSCPxj

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

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

In reply to nevent1q…ka2g
_________________________

📅 Original date posted:2023-02-23
🗒️ Summary of this message: A proposal suggests that Lightning Network channels should be between three nodes instead of two, offering advantages such as better balance and liquidity, and easier routing. However, having more than two participants in an offchain updateable cryptocurrency system can pose security risks.
📝 Original message:
Good morning 10k1,

> Currently, LN primarily uses 2 of 2 multisig channel, though I have heard people talk about opening channels in more complex transactions than 2 of 2 multisigs.
>
> Thinking through all the topology and number theory aspects of it, I think that if channels were mostly between 3 nodes instead of 2, there could be some big advantages:
>
> - Channels can advertise which node has the lowest balance, helping with balance of channels, and overall liquidity. There would need to be vague enough thresholds to define when to even bother mentioning this, I imagine something like under 10% remaining on one versus the other two would be sufficiently anonymous.
>
> - A node with 3 channels attached to it can be considered as completely connected, and can basically route to 10 different next hops for only 3 opening transaction fees.
>
> - The time cost is basically doubled - two nodes for a channel means request and two messages between the peers to propagate their PSBT channel state, 3 nodes to a channel means 1 request and 6 messages to settle a new payment, which each node in the trio can more or less dispatch two messages at the same time, so, 3 message cycles, or average around 600ms from anywhere to anywhere on the internet.
>
> - The channel's lowest balance could be one-bit boolean value publicly broadcast, meaning that peers selecting hops for a payment route can easily avoid adding to a channel stuck on one side. Pathfinding is a real hassle in the current design of LN. It is hard to navigate in the dark, but if you can sense the distance to the nearest object you can orient easily.
>
> The magic of tesselation gave us lightning fast 3d raster based 3d modeling, and is based on the infinite tesselation of triangles. Oh, there is 4 points possible, but it really just complicates things. I'm pretty sure that the new Unreal 5 "nanite" engine only works with uniform 3 point surfaces, at least, it definitely looks like that based on the 4 color map versions that show the polygons. And anyhow, a "rectangle" is just two adjacent triangles, why bother with this extra, extraneous nonsense of calling two polygons with a common axis "squares".

The problem with N > 2 participants in an offchain updateable cryptocurrency system is that if any participant is offline, then the entire system cannot update and the online participants can only back out using an expensive onchain procedure, or wait until the missing participant is online again.

(Use of k-of-n here would allow any quorum of `k` to steal the funds of the `n - k` remaining participants, so security-wise you should really go for n-of-n multisignatures)

If any arbitrary participant has a probability `P` of being offline at any particular moment, then the probability of the entire system being not updateable is `1 - (1 - P)^N`.
Crucially, because of real-world considerations, the probability `P` cannot be 0 (though this can be made arbitrarily near 0, but then the cost of doing so would have to be paid by *somebody*).

Further, if the offchain updateable cryptocurrency system has N participants, if one participant is offline, then N - 1 participants have their funds forcibly locked.
Thus we should multiply the probability of an individual system (N-participant "channel") being non-operational with the number of participants who suffer having their funds locked.

With 2-participant channels, the probability of any single channel being non-operational is at its lowest and the number of affected counterparties is also at its lowest.

This is why Channel Factories are even a thing.

--

Basically:

* A channel is just a sub-class of offchain-updateable cryptocurrency systems.
* An offchain-updateable cryptocurrency system must be hosted by another cryptocurrency system, such as a blockchain.
* An offchain-updateable cryptocurrency system does *not* require activity on its hosting system in order to update its state.
* An offchain-updateable cryptocurrency system can be hosted inside another offchain-updateable cryptocurrency system.
* The outer offchain-updateable cryptocurrency system is hosted directly by a blockchain (a blockchain only requires a physics system with entropy in order to be instantiated).
* The inner offchain-updateable cryptocurrency system is hosted on the outer one.
The outer hosting system can host multiple inner systems.
* The outer offchain-updateable cryptocurrency system is N-of-N where N > 2.
* Each inner system is 2-of-2.
* The outer offchain-updateable cryptocurrency system is the "channel factory".
* Each inner offchain-updateable cryptocurrency system is a "channel".

This provides a good balance of availability and efficiency.

* When a participant is offline, the outer system is non-operational, but each inner system deos not care.
Each inner system can update without activity on its hosting system, that is the point of offchain protocols.
So each 2-of-2 channel can update even if the hosting N-of-N channel factory cannot be updated.
* The blockchain only hosts a single N-of-N UTXO for multiple channels.

>
> The only other issue that is on my mind lately relating to LN is 0 conf channels. I hadn't thought of "channels" as being 2 dimensional, since they represent a midpoint between two other points. But a midpoint is an abstract term, not just a word used for 1D lines but also 2D and nD shapes.
>
> It seems to me like there could be a negotiation protocol to pre-arrange a not yet mined opening tx for a 3 way lightning channel, that could effectively lock in every party such that it can't wriggle out of the commitment. This just wouldn't be possible with a 2 way. It then wouldn't matter a bit how big the fee was since the parties are already in consensus and have the ability to back out at any moment.

You first need to get the 3 committed, and that is the rub here: it requires onchain activity to commit funds to any N parties, whether N=2 or N=3.
And that onchain activity will always be subject to reversal / double-spending unless confirmed deeply enough that we believe reorganizing the chain would be unlikely.

Basically: what are the inputs to the transaction that backs your 3-participant channel?
If any input can be signed by just one participant, then that participant can sign a different transaction spending that input in another way, then bribe a miner to include it in a mined block.

Thus, this fixes nothing: in order to get funds committed to the 3 participants, you need *some* confirmed transaction to commit those funds in the first place, and everyone still has to wait for that transaction to confirm, thus you cannot sidestep the confirmation-or-trust requirement.

Regards,
ZmnSCPxj

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

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

In reply to nevent1q…wef0
_________________________

📅 Original date posted:2023-02-14
🗒️ Summary of this message: The Lightning Network's reputation system relies on first-hand and inferred experience, but repeat interactions are rare. Wallet vendors can provide live network views, but this is ultimately hearsay. Altruistic nodes could provide scoring data, but LSPs can be bought out.
📝 Original message:
Good morning all,

> > First of all let's see what types of reputation system exist (and yes,
> > this is my very informal categorization):
> >
> > - First hand experience
> > - Inferred experience
> > - Hearsay
> >
> > The first two are likely the setup we all are comfortable with: we ourselves
> > experienced something, and make some decisions based on that
> > experience. This is probably what we're all doing at the moment: we
> > attempt a payment, it fails, we back off for a bit from that channel
> > being used again. This requires either being able to witness the issue
> > directly (local peer) or infer from unforgeable error messages (the
> > failing node returns an error, and it can't point the finger at someone
> > else). Notice that this also includes some transitive constructions,
> > such as the backpressure mechanism we were discussing for ariard's
> > credentials proposal.
> >
> > Ideally we'd only rely on the first two to make decisions, but here's
> > exactly the issue we ran into with Bittorrent: repeat interactions are
> > too rare. In addition, our local knowledge gets out of date the longer
> > we wait, and a previously failing channel may now be good again, and
> > vice-versa. For us to have sufficient knowledge to make good decisions
> > we need to repeatedly interact with the same nodes in the network, and
> > since end-users will be very unlikely to do that, we might end up in a
> > situation were we instinctively fall back to the hearsay method, either
> > by sharing our local reputation with peers and then somehow combine that
> > with our own view. To the best of my knowledge such a system has never
> > been built successfully, and all attempts have ended in a system that
> > was either way too simple or is gameable by rational players.
>
>
> In lightning we have a trivial solution to this - your wallet vendor/LSP is already extracting a fee
> from you for every HTLC routed through it, it has you captive and can set the fee (largely)
> arbitrarily (up to you paying on-chain fees to switch LSPs). They can happily tell you their view of
> the network ~live and you should generally accept it. Its by no means perfect, and there's plenty of
> games they could play on, eg, your privacy, but its pretty damned good.
>
> If we care a ton about the risks here, we could have a few altruistic nodes that release similar
> info and users can median-filter the data in one way or another to reduce risk.
>
> I just do not buy that this is a difficult problem for the "end user" part of the network. For
> larger nodes its (obviously, and trivially) not a problem either, which leaves the "middle nodes"
> stranded without good data but without an LSP they want to use for data. I believe that isn't a
> large enough cohort to change the whole network around for, and them asking a few altruistic (let's
> say, developer?) nodes for scoring data seems more than sufficient.

But this is all ultimately hearsay.

LSPs can be bought out, and developers can go rogue.
Neither should be trusted if at all possible.

Which is why I think forwardable peerswaps fixes this: it *creates* paths that allow payment routing, without requiring pervasive monitoring (which is horrible because eventually the network will be large enough that you will never encounter the same node twice if you're a plebeian, and if you're an aristocrat, you have every incentive to lie to the plebeians to solidify your power) of the network.

Ultimately the network gets healthier if flows are bidirectional, swaps are essential to bootstrapping from the starting state where there are distinct "customers" and "merchants", but current one-hop-only peerswaps are too local for the blockchain cost, and multi-hop source-routed swaps have the same issue as standard payments.
The advantage of forwardable peerswaps is that it is specifically not source routed --- intermediate nodes make decisions of where to forward, and they are thus incentivized to benefit the network because they benefit themselves.

I think it should be a principle of protocol design to embrace a capitalistic mindset, by which I mean: ensuring the rules make "beneficial for me" the same as "beneficial to everyone".
Certainly I can take a common knife from my kitchen and stick the pointy end into my neighbor, then take all their belongings, which would be very beneficial to me, but would not be beneficial to everyone, which is why laws against manslaughter and theft exist.
Ultimately, protocol design is the laying down of laws, and the proper function of this lawmaking position is to ensure that "beneficial for me" will be something that is "beneficial to everyone".
Indeed, the entire point of having a punitive Poon-Dryja is to ensure that "beneficial for me" does not include theft of the channel funds by using old state, and is exemplary of this principle.
"Greed is Good" might not be true, but perhaps: "We should strive to MAKE Greed Good".

Forwardable peerswaps are beneficial to every participant, and thus beneficial to the network, and thus should be part of the law of Lightning Network protocol.
It *creates* high availability of channels and routing, without self-assertions or hearsay; it only requires local reputation (a forwarding node will forward a peerswap only if it knows it can benefit from whichever hop it is forwarding to: the locality avoids the issue where a node may never interact with another node again, since the node has a channel with them and is expected to repeatedly interact with them in the close future, and thus has very good local information).

Regards,
ZmnSCPxj

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

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

In reply to nevent1q…v76t
_________________________

📅 Original date posted:2023-01-04
🗒️ Summary of this message: The proposed submarine swap/peerswap is not different from a normal on-chain to off-chain swap. The address generated by the `loop in --external` command may not be safe for reuse.
📝 Original message:
Good morning Laolu,

> Hi Z,
>
> > * Submarine swap/peerswap: Requires confirmation before the swap service
> > will send out the HTLC on Lightning.
>
> I might be missing something, but I don't see how this is different from a
> normal on-chain to off-chain swap (calling this Loop In for short in the
> remainder of the email).
>
> Given some static swap server params (server key, user key, preimage), a
> user can derive a tapscript tree and use that to make addresses that any 3rd
> party can send to. Services like Loop return a few addrs (including P2TR!)
> the client can use depending on their wallet sophistication [1] (in this
> case the command is: `loop in --amt=X --external\, external means a 3rd
> party will send to the addr). After a 3rd party sends to the script, the
> swap can be completed at anytime as soon as the client is online (assuming
> swap server is always there).
>
> In the scenario above, the newly created outputs to our swap addr need to be
> confirmed before the swap server will initiate the swap. As you mention,
> this could even be zero conf assuming all sides take w/e precautions they're
> comfortable with. If the swap server goes away for w/e reason, a long
> timeout in the swap can let the user sweep the funds via some other
> means eventually. This doesn't need to be a direct swap either, and it can
> flow multi-hop like any other swap.
>
> In your scheme you say that:
>
> > If so, then the "timer for confirmation" starts as soon as the wallet
> > receives on the blockchain, not as soon as the wallet decides to move
> > funds from blockchain to Lightning.
>
> Which seems to be the exact same as the flow I described above. For our
> newer musig2-enabled swaps, the top level keyspend can be spent by both
> parties, so you also emulate the ability for Alice to move the funds on
> chain anywhere else w/ the server's cooperation.
>
> Using regular swaps also simplified the "Bob Security" section a lot, as Bob
> sends out an HTLC w/ the corresponding swap hash (he watches the chain for
> the scripts, then initiates the swap once they're seen).
>
> [1]: https://lightning.engineering/api-docs/api/loop/swap-client/loop-in

Quick question: is the address given by the `loop in --external` command safe for reuse?

In many common onchain-only wallets **available today**, you can do something like get a receive address and add it to your forum sig or on a static webpage or forum post or whatever, and then anyone can send to it, possibly multiple times with different amounts coming from different people.

The fact that `loop in` requires a specific `--amt=X` flag suggests to me that the address generated is not safe for address reuse (in particular, once *one* swap has completed, I am almost sure that any future funds to the same address can be stolen by the swap server without handing it over to the purported owner of the funds).

Swap-in-potentiam is safe for address reuse, because each UTXO for the same address backs a new, separate swap (if Alice wanted it).
The advantage is that:

* You get stable addresses that are safe for reuse (which is already possible today on non-Lightning wallets, so people already do this today).
* Those stable addresses can still be spent from quickly on the Lightning Network as soon as they are reasonably confirmed.

Regards,
ZmnSCPxj

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

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

In reply to nevent1q…p240
_________________________

📅 Original date posted:2023-01-03
🗒️ Summary of this message: A new protocol called swap-in-potentiam allows for immediate transfer of onchain funds to Lightning Network, reducing the time required for confirmation.
📝 Original message:
Subject: Swap-in-Potentiam: Moving Onchain Funds "Instantly" To Lightning

by Jesse Posner, ZmnSCPxj

Introduction
============

Moving funds from an onchain-only address to Lightning Network is slow,
especially if you desire trust-minimization (which removes solutions
relying on 0-conf).

Basically, to reduce trust requirements in all onchain transactions,
onchain receivers *MUST* ensure confirmation of the onchain transaction
that creates their UTXO.
In practice, the minimum should be at least 3 blocks, since reorgs of
up to 2 blocks are common occurences, but even 1 confirmation can
take an inordinately long time in the real world due to the random
nature of mining.

This is particularly acute for mobile phone use-cases.
As mobile phones run on a battery, mobile phone OSs often greatly
restrict CPU and other resource consumption when an app is not
currently open by the user.

Now consider this user story, for a wallet app that supports both
Bitcoin blockchain and Lightning Network operations:

* The user wants to be paid over the Bitcoin blockchain.
* The user gets an address from their wallet and provides it to
some other party to receive their payment.
* The user closes their wallet app, which causes the mobile phone
OS to kill all its threads.
* The other party sends their payment over blockchain while the
user is asleep.
* The blockchain transaction confirms and time passes.
* The user wakes up and checks their favorite blockchain explorer,
and sees they received funds on their wallet address.
* The user opens their wallet app and decides they need a coffee,
so they buy coffee over Lightning.

For current solutions to move funds from the blockchain layer to
Lightning, however, the above user story would need to complete
over a long time, possibly measurable in dozens of minutes or
even hours in the worst case, due to the need for confirmation:

* Channel open: Requires confirmation, many nodes require 6 or
more confirmations.
* Submarine swap/peerswap: Requires confirmation before the swap
service will send out the HTLC on Lightning.
* Splice-in: Channel remains operational, but until the splice
transaction confirms, the channel operates in "dual mode"
where both pre-splice and post-splice state is valid, and
that means only the lower amount of the pre-splice and
post-splice can be used in the mean time.
For splice-in, the pre-splice amount will be lower, thus
the amount being spliced in will not be credited until
the splice transaction is confirmed.

In this writeup, we present a novel protocol, swap-in-potentiam,
that can be used for immediate transfer from the blockchain
layer to the Lightning layer, in the above user story.

Advantages And Limitations
--------------------------

To whet your appetite, here are the advantages:

* Immediate transfer of already-confirmed-received onchain
funds to Lightning.
* Onchain funds can also be transferred to another onchain
address (subject to normal onchain confirmation rules).
* This can be "immediate" if sending to a receiver that
accepts the risk of 0-conf onchain transactions.
* Minimized trust requirement.

The disadvantages, to help convince you that yes, this is
technology and not magic beans (and to not oversell this
tech, Bitcoin media reporting often tend to oversell
new technologies because the disadvantages are often
hidden away behind technical minutae):

* Requires a cooperating LSP.
If LSP is down or refuses to cooperate, onchain funds
are locked for some time.
This has a timeout (so if the LSP never comes online
again, you just wait out the timeout) and the timeout
starts from when the receiving UTXO is confirmed in a
blocks, so it will not cause loss of funds, only loss
of opportunity (i.e. "involuntary HODLing").
* If you have multiple LSPs, when you generate an address
you *have to* select one of them at that point, you
*cannot* commit to multiple LSPs and select one of them
later when your phone wakes up again.
This exacerbates the above disadvantage, since you have
to select one of your LSPs and hope that when your
phone wakes up the LSP you selected is also up and
cooperative.
* The onchain-received funds have to be confirmed first,
otherwise we still need to wait for confirmation of the
onchain-received funds.
This is generally true for many blockchain-only wallets
anyway and is thus not a worsening, but is also not an
improvement.
* If the timeout is too near, actions must be performed
onchain that require confirmation.

Swap-in-Potentiam
=================

All onchain fund movements, as noted, require confirmation.
These include onchain fund movements to the Lightning network.

If the onchain address that the wallet provides was controlled
solely by that wallet, then any action that requires cooperation
with a Lightning Network participant --- channel open, swap, or
splice --- would require an onchain transaction that commits to
that specific Lightning Network participant.
Only when the new onchain transaction is confirmed, can that
Lightning participant rely on the transaction output without
having to trust the initiator.

>From there, we can consider: what if the wallet provides an
address that *already* commits to that specific Lightning Network
participant?

If so, then the "timer for confirmation" starts as soon as
the wallet receives on the blockchain, not as soon as the wallet
decides to move funds from blockchain to Lightning.

This is a significant difference for a mobile wallet: the mobile
environment does not support the mobile wallet being online for
long.
Thus, the mobile wallet may not have any CPU to make the decision
to move funds from blockchain to Lightning, until the actual user
explicitly opens the mobile wallet app.

It has already been generally accepted that due to the limitations
of the mobile phone environment, a mobile phone wallet with
Lightning support would need some LSP anyway.
Thus, a mobile wallet that can receive on the blockchain layer
and then send on the Lightning layer can commit to a specific,
different, Lightning participant: the LSP it has channels with.

Thus, the mobile wallet can provide an address that commits to
one particular Lightning Network participant: its LSP.

The mobile wallet can then initiate a single-hop swap with the
LSP when the mobile wallet app is in the foreground and has CPU
to think with.
If it received funds into the address that have already been
confirmed, then it can do this single-hop swap immediately with
its LSP.
The LSP can immediately resolve this swap, crediting funds to
channel, while atomically ensuring it has sole claim to the
onchain UTXO.

The Contract
------------

The contract has two participants: Alice the funds owner, and
Bob its potential swap partner.

Once *any* funds have been confirmed received into an address
committing to this contract, Alice owns the funds and can
dispose of them as it likes (with cooperation from Bob).
The source of the funds need not be Alice, it could be a third
party that has an obligation to pay Alice onchain.

The contract has only 2 branches:

* Onchain/channel branch: Alice and Bob.
* Timelock branch: Alice plus a relative timelock (`OP_CSV`)
measurable in weeks.

Astute readers will realize that the above is really a variant
of [CLTV-style unidirectional time-limited channels][1],
themselves a variant of Spilman-style channels:

* Uses an explicit opcode to simplify channel setup (no need
to pre-sign a timeout transaction between Alice and Bob,
can just send funds directly to the address).
* Uses a relative locktime instead of an absolute one to
allow funding of the channel address (= receive onchain
funds ready to spend over Lightning) at any time.

The use-cases this enables are:

* If Alice wants to pay to another onchain address, and Bob
is also online and cooperative, Alice can ask Bob to help
sign the Onchain/channel branch to move the funds in any
arbitrary onchain manner.
* If Alice wants to pay to a Lightning invoice / keysend, and
has insufficient Lightning outgoing capacity (but has
sufficient *total* capacity), it can swap with Bob, by
offerring a transaction that spends via the Onchain/channel
branch and instantiates a fresh onchain HTLC that Bob can
then forward over Lightning.
As soon as Alice offers its signature of that transaction,
Bob can immediately offer an in-Lightning HTLC to Alice on
their channel, and then Alice can immediately resolve it
(thus immediately getting its funds into Lightning).
* If Bob is offline or uncooperative, Alice can unilterally
recover its funds after the timeout in the Timelock
branch.

Trust is required only to the extent that Alice trusts Bob to
be cooperative so that Alice can dispose of its funds immediately.
In case Bob turns out to be non-trustworthy, Alice can recover
its funds via the timelock branch after the timeout period.
There is no scope for Bob to steal funds (indeed, it is easier
for Bob to steal Lightning funds than to steal swap-in-potentiam
funds).

The intent here is that the mobile wallet is Alice, while the
LSP is Bob.

### Bob Security

Bob *MUST* ensure that, for each UTXO, it is either asked to
sign an arbitrary onchain transaction (i.e the first use-case
above) *OR* it gets offered an onchain HTLC from that UTXO.
Once Alice has asked Bob to cooperate in either case for a
particular UTXO, Bob *MUST* ensure that it does not sign the other
case (and Bob *MUST* refuse to cooperate in the other case once
one case has been requested).

In addition, Bob *MUST* ensure that, if it is used in the
"channel" case (i.e. the second use-case above), the timeout of
the Timelock branch is far enough in the future that it is likely
that spends using the Onchain/channel branch have confirmed by
then.

With both invariants enforced by Bob, Bob can ensure that, if
Alice requests a swap using the Onchain/channel branch, only Bob
can spend the UTXO (at least before the timeout), and thus can
safely offer a Lightning HTLC to Alice immediately without any
additional waiting for onchain confirmations.

As Bob needs to know the UTXO in the first use-case above, this
requirement prevents the use of blind signing techniques when
implementing the first use-case.
Basically, when being asked to sign, Bob must generate the entire
`SIGHASH` from data that Alice provides, so that Bob is able to
keep track of UTXOs it is signing for.

### Remote Swap

While Bob is generally considered "the" LSP of the mobile wallet
Alice, nothing in the Lightning protocol actually requires that
Bob be a direct peer of Alice.
The only real requirement is that Bob is able to send funds to
Alice over Lightning in exchange for possession of the equivalent
onchain funds.

Against this, we should note that the mobile wallet is already
dependent on one or more LSPs anyway, so it may as well just use
its direct peer LSPs instead of a remote node.

### Address Derivation

Swap-in-potentiam addresses can be derived from a root public or
private key.

We only need one keypair each from Alice and Bob.
Alice can use standard derivation paths for its keypair.

As Bob is intended to be an LSP, we can just use its Lightning
node ID as the public key.
Bob needs to be in possession of the corresponding private key
anyway in order to set up BOLT 8 encrypted transports.

As LSPs are part of the public network, Alice can simply try to
scan for all published nodes that advertise support for
swap-in-potentiam.
Alternately if the wallet has a short list of fixed LSPs it
will use, it can simply refer to that list.

Thus:

* Alice uses a derived keypair.
* Bob uses a fixed keypair (its Lightning node ID).

The above is sufficient to derive swap-in-potentiam addresses
from an `xprv` or `xpub` root key.

Swap-in-potentiam For LSPs
==========================

While the original design of swap-in-potentiam has the mobile
wallet in the "Alice" role and its LSP in the "Bob" role, it
turns out that LSPs can provide special service to improve
receiving mobile wallets.

Suppose that the LSP keeps track of statistics, and thus has
an idea of which of its mobile wallet clients are likely to
be net receivers.

Net receivers will often have low inbound capacity (since the
inbound capacity has been used up during previous LN receives).

During times of low onchain fees, an LSP can check which of its
offline mobile wallet clients have low inbound capacity, and are
likely to come online in the future to receive.
In those cases, the LSP can commit funds to a swap-in-potentiam
with the mobile client, with the LSP as "Alice" and the mobile
client as "Bob".
This at least lets the LSP set up half of a swap during a time of
low fees.

If the transfer to swap-in-potentiam addresses is confirmed by
the time the mobile wallet client comes online, the LSP can
immediately initiate a swap, giving inbound capacity towards the
mobile client.
This swap can be immediately resolved, and allows the mobile
wallet client to immediately receive funds over Lightning.

In particular, if "offline receive" as designed by TheBlueMatt
is implemented, then the LSP already has indication of a pending
payment towards an offline mobile wallet client.
The LSP can check if the offline mobile wallet client has
insufficient incoming capacity to receive the funds, and if so,
arrange to fund a swap-in-potentiam with that client.
Then, when the mobile wallet client comes online, the LSP can
initiate the swap with them, and once the swap completes (and
thus the mobile wallet client has sufficient incoming capacity)
the LSP can contact the sender LSP to complete the payment.

In particular, this use-case allows for *immediate* receives as
soon as the mobile wallet client gets foregrounded and has CPU
time, **without** requiring 0-conf trusted transactions and
thus without requiring any kind of semi-custodial trust, even
if the mobile wallet client had insufficient incoming capacity.
A channel still has to be set up beforehand (without 0-conf, if
trusting funds to the LSP is undesirable).

Implementation Sketch
=====================

The intent is to use Taproot with Schnorr signatures, but
**without** using the keyspend path (at least initially).

The plan currently is to use a `MuSig(A, B)` as the internal
pubkey, but with the branches still explicitly laid out as
tapleaves.
That is, there are two tapleaf SCRIPTs corresponding to the
two branches described above:

* `<A> OP_CHECKSIGVERIFY <B> OP_CHECKSIG`
* `<timelock> OP_CHECKSEQUENCEVERIFY OP_DROP <A> OP_CHECKSIG`

Using an explicit 2-of-2 branch rather than a MuSig allows
for a simple protocol at least for initial deployment:
we can have Alice send the signature using `A` in a single
half-round without having to engage in a 2-round MuSig2 signing
ritual.

We intend to use Taproot since the mobile wallet client
may need to use a 2-of-3 or 2-of-2 signing scheme, similar
to Blockstream Green.
This allows either Alice or Bob in the contract to secretly
be a FROST 2-of-3 or MuSig 2-of-2 (or any FROST k-of-n or
MuSig n-of-n).
This is also another reason for avoiding a 2-of-2 MuSig
keyspend path between Alice and Bob, as there is (to our
knowledge) no publicly-reviewed security proof that
FROST-in-MuSig and MuSig-in-MuSig are safe (or the
corresponding variants using MuSig2 for the signing
ritual).

Later, when we are more confident of the use of MuSig2 and
FROST inside a MuSig2, and with using MuSig2 with possibly
untrusted outsiders (who might exploit any mis-implementation
of the MuSig2 signing protocol if we are not careful with
designing it), we can seamlessly upgrade the protocol
to use the keyspend path later, to save witness bytes.

For the Onchain use-case (i.e. Alice wants to spend the UTXO
to an onchain address), the protocol betweeen Alice and Bob
would be:

* `request_arbitrary_signature` Alice->Bob: Requests Bob
to sign a PSBT spending a swap-in-potentiam address
using the Onchain branch.
* `response_arbitrary_signature` Bob->Alice: Response to
the above, returning the requested signature.
* `reject_arbitrary_signature` Bob->Alice: Sent in
response to `request_arbitary_signature` if Bob refuses
to cooperate (e.g. the UTXO being spent has already
been accepted by Bob in a Channel use-case below).

For the Channel use-case (i.e. Alice wants to spend the UTXO
to a Lightning receiver), we operate the swap-in-potentiam
UTXO(s) as a Spilman-like channel over two states:

* HTLC-offering: Offering an amount `N` HTLC from Alice to
Bob, with any remaining amount to a change address to
Alice.
* Resolved: Giving the amount `N` outright to Bob, with any
remaining amount to a change address to Alice.

The intention is that the channel is initially put into
the HTLC-offerring state.
Then Bob offers a corresponding in-Lightning HTLC to Alice
over their channel.
When Alice resolves the in-Lightning HTLC, it can then
send a new signature for the Resolved state.
Once the channel is in a Resolved state, Bob *SHOULD* sign
the last state and broadcast it on the blockchain, thereby
closing the Spilman-like channel.

The protocol messages for the Channel use-case are:

* `request_swap_in` Alice->Bob: Tell Bob the UTXOs with
the same swap-in-potentiam address to spend, how
much to put into the Alice->Bob channel direction,
what channel to move into, and (optionally) a change
address for Alice.
* `reject_swap_in` Bob->Alice: Sent in response to
`request_swap_in` if Bob refuses to cooperate (e.g.
one of the UTXOs on offer was already signed with
`response_arbitrary_signature`, or Bob cannot legally
accept control of funds from one or more of the UTXOs
offerred).
* `accept_swap_in` Bob->Alice: Sent in response to
`request_swap_in`, containing the Bob-side address to
send funds to later once the state is Resolved.
* `swap_in_signed` Alice->Bob: Response to
`accept_swap_in`, containing the Alice-side signature
for the HTLC-offering state transaction.
Once Bob receives this, Bob can safely construct a
new on-Lightning HTLC using BOLT1
`update_offer_htlc`.
* `swap_in_resolved` Alice->Bob: Sent after Alice has
acquired the funds via `update_fulfill_htlc` of the
corresponding on-Lightning HTLC, containing the
Alice-side signature for the Resolved state
transaction.
The Resolved state transaction spends to the Bob-side
address given in `accept_swap_in`, and any change to
the Alice-side change address in `request_swap_in`.

The plan is to reserve only one odd BOLT1 message ID,
and to embed the actual swap-in-potentiam message ID
as the first 2 bytes of the BOLT1 message, to reduce
pollution of the limited BOLT1 message ID space and to
allow more flexibility for swap-in-potentiam to expand
to new messages inside its own message ID space.

For a richer future protocol, we will want to consider
how a swap-in can be combined with a splice-in.
This is useful if the current total capacity of the
channel is lower than the available onchain funds.
The swap-in can be credited immediately (and is limited
to the current total capacity) while additional funds
can be added to the channel via splice-in (which is
credited only once the splice-in is confirmed).

As-is, a similar result can be obtained using openv1,
wherein a swap-in is combined with a channel open,
with the swap-in immediately credited while the channel
open is awaiting confirmation:

* Alice and Bob currently have one or more existing
channels, and Alice has a UTXO in a swap-in-potentiam
address whose value exceeds the incoming capacity of
the existing channel(s).
* Alice->Bob `open_channel`.
* Bob->Alice `accept_channel`.
* Alice->Bob `request_swap_in` with the "change address"
being the funding address of the channel.
* Bob->Alice `accept_swap_in` provides the TXID of the
funding transaction (Alice now knows the "change
address" and the Bob final Resolved address, letting it
know the final Resolved state transaction TXID).
* Alice->Bob `funding_created` with the TXID.
* Bob->Alice `funding_signed`.
* Alice->Bob `swap_in_signed` to provide the signature
spending the swap-in-potentiam address to Bob.
* Bob then constructs an HTLC over the existing channel,
which Alice claims, revealing the preimage.
* Alice->Bob `swap_in_resolved`.
* Bob then broadcasts the Resolved state transaction,
which is also the funding transaction of the new channel.
* Both Alice and Bob await confirmation of the transaction
in order to use the new channel.
Alice can still use the existing channel, which has been
topped-up with fresh outgoing capacity by the swap-in.

(The above is not safe, as Bob can complete the protocol
by using the HTLC-offerring state transaction; this can
be fixed by having Alice open *2* channels with the same
amount, one with the HTLC-offering state transaction as
the funding tx, the other with the Resolved state
transaction as the funding tx, and later `error`ing the
channel corresponding to the transaction that is not
confirmed; this is left as an exercise to the reader,
though note that it requires two different change addresses
for Alice for both HTLC-offerring and Resolved states,
which can be arranged for the protocol)

--

[1]: https://en.bitcoin.it/wiki/Payment_channels#CLTV-style_payment_channels

📅 Original date posted:2023-05-10 📝 Original message: Good ...

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

In reply to nevent1q…d3nj
_________________________

📅 Original date posted:2023-05-10
📝 Original message:
Good morning mailing list, et al.,

Let me explain the various possible mitigations and their drawbacks.

Many of these are either "LSP trusts client" or "client trusts LSP", in the sense that it is possible for the second mover (client in "LSP trusts client"; LSP in "client trusts LSP") to impose costs on, or outright steal from, the first mover.

If you want a trust-minimized solution, you need some kind of third party that both LSP and client agree will actually enforce that the second mover does not cheat or otherwise impose costs on the first mover.
This "third party" SHOULD really be the blockchain, meaning you should really be using at least 1-conf and probably 3-conf to avoid reorgs, but *shrug*.
(You *could* use Liquid as a third party --- but Liquid is custodial, it just has a federation as a custodian instead of a single entity, you have to trust that the federation does not collude to steal all your funds, or that Blockstream has not installed Something Else (TM) in the HSMs they sold to the federation members.)

Without a trusted third party (with the blockchain, being a decentralized open-source project with strong incentives against censorship, being your standard for trustworthiness), your choices are:

* LSP issues a promise --- a signature committing to a funding output on a funding transaction --- that it will definitely make a 0-conf funding transaction get confirmed before some future target blockheight.
https://github.com/BitcoinAndLightningLayerSpecs/lsp/pull/24
If the funding transaction is not confirmed by then, or the output is not the correct `scriptPubKey` and amount, the client reports it publicly and starts a boycott of the LSP.
* The client refuses to send `channel_ready` (and therefore the HTLC cannot reach the client) until after the LSP issues this promise.
"LSP trusts client".
* How often have boycotts actually worked anyway?
* Client waits for the funding transaction to appear on its local mempool before sending `channel_ready`.
* "LSP trusts client", somewhat, but far weaker than the above; you can argue this is actually "client trusts LSP" and I would agree with you.
* The LSP can still double-spend the funding transaction with coordination with a miner, as I noted in my critique of benthecarman proposal.
Mere broadcast is not an assurance of confirmation, we have been saying that about 0-conf for a long time.
* Not all clients naturally have access to a mempool --- BIP157/158 clients do not necessarily maintain their own mempool, though an Electrum SPV client can query the mempool of the Electrum server.
* benthecarman proposal, as noted in previous post.
* "client trusts LSP".
* LSP waits for the client to hand over the preimage before broadcasting the funding tx.
* "client trusts LSP".
* LSP can skip actual funding tx broadcast once the client has handed over the preimage.
* Can be implemented in multiple ways that are all equivalent:
* Outright give the preimage in some bespoke API call.
* LSP sends the `open_channel` blah blah dance until `channel_ready` exchange, does `update_add_htlc` and irrevocably committed dance, then waits until `update_fulfill_htlc` before broadcasting the funding tx.
* A client can implement the "client waits for funding tx in its own mempool before preimage" while the LSP implements this "LSP waits for preimage before funding tx broadcast", and both of them will stall waiting for each other LOL ^.^ wahahahahaha deadlock is fun.
This is why LSPS has to pick one or the other, otherwise we will get incompatibilities between LSPs and clients.

LSPS (Open LSP Specifications group) participants have indicated a desire to prefer "LSP trusts client", because the LSP is a big target for various kinds of out-of-LSPS attacks.
For example, a hacker could potentially modify the behavior of an LSP so that the LSP attacks the client, if the "client trusts LSP" model is used.
Worse, somebody can ***accuse*** the LSP of actually attacking *some* client, and it can be hard for the LSP to provide substantial evidence that it is NOT attacking the client.
(This is why the "promise" scheme I listed first above is valuable --- it is definite proof that the LSP is not attacking the client, if the client is unable to provide the promise as a proof-of-misbehaviour, then the client is just bullshitting and its claim of being cheated can be ignored, assuming of course that people actually believe in the strong cryptographic provisions of the signature scheme (which I might add is the same signature scheme used to secure Bitcoin itself, so... but humans are stupid, which is why AI should replace humans with something better).
By the way have I mentioned I am human today?)

However, the only truly "LSP trusts client" scheme that I have figured out is that first scheme where the LSP issues a cryptographically third-party-verifiable promise to get the funding tx confirmed by some later blockheight.
This scheme has been controversial even among LSPS participants, however.

Regards,
ZmnSCPxj

📅 Original date posted:2023-05-09 📝 Original message: Good ...

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

In reply to nevent1q…lcma
_________________________

📅 Original date posted:2023-05-09
📝 Original message:
Good morning benthecarman and SomberNight,

As noted by SomberNight, PTLCs does not quite fix this, as the client can still wait out the inbound PTLC of the LSP and force the LSP to perform an onchain action to ensure it does not give a channel for free.

Another wrinkle here is that the LSP can attempt to coordinate with a miner (via e.g. full-RBF) to double-spend the funding transaction after the client has broadcasted the signed funding transaction on the mempool (i.e. lets the LSP learn the scalar that unlocks the inbound HTLC).
Assuming the LSP uses one large UTXO to fund a smaller channel, the funding transaction has one input, two outputs.
The clawback transaction (spending the same UTXO but returning it back to the LSP control) that the LSP coordinates with a miner would be one input, one output, thus having a size advantage.
As the funding transaction pays some fixed fee --- whose value presumably is paid for in the JIT channel open via the inbound PTLC that arrives at the LSP --- the clawback transaction can pay the exact same fixed fee, but being smaller by one output, has a better feerate and thus a miner would prefer it.

Either client or the LSP has to move first.
The only way they can assure that the other will actually do what they promised is if there is some arbiter who can ensure that the second mover actually performs their move.
The default arbiter is the blockchain layer itself, but 0-conf just wants to avoid the blockchain layer for being too slow.

Regards,
ZmnSCPxj

Sent with Proton Mail secure email.

------- Original Message -------
On Tuesday, May 9th, 2023 at 9:10 PM, SomberNight via Lightning-dev <lightning-dev at lists.linuxfoundation.org> wrote:

> Hi benthecarman,
>
> > the LSP can give the funding transaction signed using adaptor sigs to the client and the client can then decrypt the signatures and broadcast the transaction. Then the LSP can find the transaction in the mempool and extract the secret they need to claim the payment
>
>
> What if, after the client has the funding transaction locally, it waits for the PTLC held by the LSP to time out, i.e. days, and then (the client) broadcasts the funding transaction? The LSP could then no longer claim the PTLC, and it would have paid for the channel-open.
>
> To prevent this, the LSP would have to actively double-spend the channel funding tx given to the client when the PTLC is close to expiring, and only after getting the conflict mined can the PTLC be failed. This double-spending would cost mining fees of course (arguably the ~same amount as not doing anything and just letting the channel open). Although perhaps the LSP has enough users and high enough traffic that the conflicting tx itself can be something useful, e.g. another channel-open to another user.
>
> ghost43 / SomberNight
>
>
> ------- Original Message -------
> On Tuesday, May 9th, 2023 at 19:07, Ben Carman benthecarman at live.com wrote:
>
>
>
> > Hi everyone,
> >
> > I was chatting with Tony Giorgio the other day and he made me aware of a potential griefing attack that is possible today on LSPs that provide Just-In-Time channels.
> >
> > The attack is very simple, when the LSP receives the payment and then opens a 0-conf channel to the client, the client could not claim the payment thus resulting in the LSP not getting paid and the client getting a free inbound lightning channel. The LSP could double spend the transaction but they still would lose the miner fees and as we are seeing today, that can be very expensive.
> >
> > I am not sure if this has been proposed before but we can fix this with PTLCs!
> >
> > Instead of having the LSP just broadcasting the funding transaction to the mempool, they can sign the funding transaction using adaptor signatures locked to the same secret as the invoice. Then when the client wants to claim the funds they can get the funding txid from the LSP, and then do the PTLC dance with the LSP based on using that funding transaction. If it all goes as planned the LSP can give the funding transaction signed using adaptor sigs to the client and the client can then decrypt the signatures and broadcast the transaction. Then the LSP can find the transaction in the mempool and extract the secret they need to claim the payment, thus making claiming the payment and opening the channel atomic so the client can't grief the LSP.
> >
> > Not sure if this has been talked about before, if not I think we can throw it in the ever-growing pile of "PTLCs fixes this".
> >
> > Best,
> > benthecarman
>
> _______________________________________________
> Lightning-dev mailing list
> Lightning-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev

📅 Original date posted:2023-05-07 📝 Original message: Good ...

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

In reply to nevent1q…nmrf
_________________________

📅 Original date posted:2023-05-07
📝 Original message:
Good morning list,

I would like to point out that one of the main issues with LSPs is that most of them are designed to lock in their customers to their platform.

Hopefully, with a common open specification like this, it becomes significantly more feasible for Lightning end-user clients to be able to switch across different LSPs.

In particular, I have always pointed out that unpublished channels leak information about your sends and receives to the published node end of the channel.
Thus, if you are locked to a particular single LSP, your data belongs to them.

You might trust your LSP today to not leak your data.

But you might not want to trust your LSP tomorrow.

LSPs can be bought out, their operators can change their minds, their servers can be hacked and your data stolen, many things can be done to take your data.
And if one end is published while the other end is completely unpublished, an unpublished channel will always leak the sends and receives of the unpublished end, and not even PTLCs can hide that information.

If you, as a client, are capable of using multiple LSPs simultaneously (which would be greatly assisted if multiple LSPs implemented this common specification) then you are able to spread out your information across multiple LSPs.
That way, only part of your data is at risk of being leaked if one LSP goes rogue and sells your data.
Wallet clients might also want to use different node IDs for each LSP (if you have your privkey always online --- which is likely since Lightning really wants online signing --- you can use an HMAC of the LSP node ID with your privkey to generate your per-LSP node ID) to further improve their privacy across LSPs.

Thus, I strongly suggest that wallet implementors in particular look at the LSPS specifications and start planning to implement the client-side interfaces.

The best Lightning Network, if we must have any unpublished channels at all (in my opinion, unpublished channels delenda est), is one where every published node is an LSP.

--

I observe that there have been many new innovations in Lightning, such as "Lightning addresses", which are not even vaguely alluded to in lightning-dev.

Thus, I would like to point out this post once again: https://lists.linuxfoundation.org/pipermail/lightning-dev/2023-April/003915.html

I would like to continue this post with a short discussion of the so-called "LSPS0", which underlies the LSPS1 and LSPS2 we are asking review for.

LSPS0 describes how a client makes requests to an LSP.
In brief, it uses a single BOLT8 message ID, 37913, for all LSPS client and LSP intercommnications.

The rationale for this is:

* Every client needs to somehow talk the BOLT8 protocol to an LSP just to do normal channel opens, HTLC sends, HTLC receives, etc.; using the BOLT8 protocol means you do not have to add more dependencies just to be LSPS-compliant.
* Using a single BOLT8 message ID, 37913, makes it more likely that new protocols will not conflict with LSPS.
The message ID space is a common public good, and it is best to reduce its use as much as possible.
All LSPS specification, no matter how many there will be in the future (and I have a fair number lined up after LSPS2....), will only use exactly this single BOLT8 message ID.

Further, inside the LSPS0 37913 message is a JSON object.
This use of JSON inside a BOLT8 message has been described as "disgusting" by at least one engineer, and has been controversial even among LSPS participants.

The rationale for this requires a bit of philosophical information theory.

In principle, a binary encoding is "just" a compressed encoding of some human-readable format.
For example, if we assign some offset within the message as `minimum_depth`, we could consider that the offset is actually a magic number, and that magic number is really inside a compression dictionary, with that magic number expanding to the human-readable text `minimum_depth`.

Now compressed encodings like this are fairly fine for computers to process, but humans trying to actually implement LSPS specifications would benefit more from the human-readable text.

Thus, I argued that it is better to use a JSON encoding, as any binary encoding would just be equivalent to expanding to an equivalent JSON encoding where the offset of a particular binary-formatted field is really just a compression dictionary entry, mapping out to the text `"minimum_depth": `, and that the "real" uncompressed text would be a JSON encoding.

This remains true even if you consider TLVs, as the type number is, again, just a magic number that is mapped, in a static compression dictionary (usually written down in some BOLT spec), to some human-readable label.

Now compression is useful if you are doing something like designing a payment onion format.
You want to fit a single onion with multiple hops into as few lower-level MTUs as you can, ideally fitting an entire multi-hop onion into a single 1500-byte MTU.
This is why the onion format has been very stringent and tight; an onion is only 1366 bytes so that with various messaging overheads it can fit into a single 1500-byte MTU.
It pays to have a binary format for the payment onion you are using to inform new HTLCs to your peers, as (1) you want payment to be fast and (2) onions need to be forwarded across multiple nodes (and thus need lots of data, each hop needs some bytes for it).

However, for most LSPS requests and responses between a single hop --- between the client and the LSP --- even in uncompressed JSON, are less than 1000 byte.
Adding compression --- i.e., forcing a binary format --- does not really improve the latency, as a 100-byte MTU takes as much time round-tripping as a 1000-byte MTU.
And at least you can easily put the raw JSON from LSPS0 messages in your logs and then if something weird happens, you can copy-paste the JSON into a pretty-printer and get some nicely-formatted JSON you can analyze in detail; if you had to do that with binary formats, you would need to decide how to print it out yourself, and probably need to make your own pretty-printer for the data.

This is why LSPS0 was designed the way it was: a JSON text inside a BOLT8 message, with all LSPS API calls sharing the same single BOLT8 message (keyed by a particular key in the JSON text).

Regards,
ZmnSCPxj

📅 Original date posted:2023-02-23 📝 Original message: Good ...

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

In reply to nevent1q…q6m0
_________________________

📅 Original date posted:2023-02-23
📝 Original message:
Good morning 10k1,

> Currently, LN primarily uses 2 of 2 multisig channel, though I have heard people talk about opening channels in more complex transactions than 2 of 2 multisigs.
>
> Thinking through all the topology and number theory aspects of it, I think that if channels were mostly between 3 nodes instead of 2, there could be some big advantages:
>
> - Channels can advertise which node has the lowest balance, helping with balance of channels, and overall liquidity. There would need to be vague enough thresholds to define when to even bother mentioning this, I imagine something like under 10% remaining on one versus the other two would be sufficiently anonymous.
>
> - A node with 3 channels attached to it can be considered as completely connected, and can basically route to 10 different next hops for only 3 opening transaction fees.
>
> - The time cost is basically doubled - two nodes for a channel means request and two messages between the peers to propagate their PSBT channel state, 3 nodes to a channel means 1 request and 6 messages to settle a new payment, which each node in the trio can more or less dispatch two messages at the same time, so, 3 message cycles, or average around 600ms from anywhere to anywhere on the internet.
>
> - The channel's lowest balance could be one-bit boolean value publicly broadcast, meaning that peers selecting hops for a payment route can easily avoid adding to a channel stuck on one side. Pathfinding is a real hassle in the current design of LN. It is hard to navigate in the dark, but if you can sense the distance to the nearest object you can orient easily.
>
> The magic of tesselation gave us lightning fast 3d raster based 3d modeling, and is based on the infinite tesselation of triangles. Oh, there is 4 points possible, but it really just complicates things. I'm pretty sure that the new Unreal 5 "nanite" engine only works with uniform 3 point surfaces, at least, it definitely looks like that based on the 4 color map versions that show the polygons. And anyhow, a "rectangle" is just two adjacent triangles, why bother with this extra, extraneous nonsense of calling two polygons with a common axis "squares".

The problem with N > 2 participants in an offchain updateable cryptocurrency system is that if any participant is offline, then the entire system cannot update and the online participants can only back out using an expensive onchain procedure, or wait until the missing participant is online again.

(Use of k-of-n here would allow any quorum of `k` to steal the funds of the `n - k` remaining participants, so security-wise you should really go for n-of-n multisignatures)

If any arbitrary participant has a probability `P` of being offline at any particular moment, then the probability of the entire system being not updateable is `1 - (1 - P)^N`.
Crucially, because of real-world considerations, the probability `P` cannot be 0 (though this can be made arbitrarily near 0, but then the cost of doing so would have to be paid by *somebody*).

Further, if the offchain updateable cryptocurrency system has N participants, if one participant is offline, then N - 1 participants have their funds forcibly locked.
Thus we should multiply the probability of an individual system (N-participant "channel") being non-operational with the number of participants who suffer having their funds locked.

With 2-participant channels, the probability of any single channel being non-operational is at its lowest and the number of affected counterparties is also at its lowest.

This is why Channel Factories are even a thing.

--

Basically:

* A channel is just a sub-class of offchain-updateable cryptocurrency systems.
* An offchain-updateable cryptocurrency system must be hosted by another cryptocurrency system, such as a blockchain.
* An offchain-updateable cryptocurrency system does *not* require activity on its hosting system in order to update its state.
* An offchain-updateable cryptocurrency system can be hosted inside another offchain-updateable cryptocurrency system.
* The outer offchain-updateable cryptocurrency system is hosted directly by a blockchain (a blockchain only requires a physics system with entropy in order to be instantiated).
* The inner offchain-updateable cryptocurrency system is hosted on the outer one.
The outer hosting system can host multiple inner systems.
* The outer offchain-updateable cryptocurrency system is N-of-N where N > 2.
* Each inner system is 2-of-2.
* The outer offchain-updateable cryptocurrency system is the "channel factory".
* Each inner offchain-updateable cryptocurrency system is a "channel".

This provides a good balance of availability and efficiency.

* When a participant is offline, the outer system is non-operational, but each inner system deos not care.
Each inner system can update without activity on its hosting system, that is the point of offchain protocols.
So each 2-of-2 channel can update even if the hosting N-of-N channel factory cannot be updated.
* The blockchain only hosts a single N-of-N UTXO for multiple channels.

>
> The only other issue that is on my mind lately relating to LN is 0 conf channels. I hadn't thought of "channels" as being 2 dimensional, since they represent a midpoint between two other points. But a midpoint is an abstract term, not just a word used for 1D lines but also 2D and nD shapes.
>
> It seems to me like there could be a negotiation protocol to pre-arrange a not yet mined opening tx for a 3 way lightning channel, that could effectively lock in every party such that it can't wriggle out of the commitment. This just wouldn't be possible with a 2 way. It then wouldn't matter a bit how big the fee was since the parties are already in consensus and have the ability to back out at any moment.

You first need to get the 3 committed, and that is the rub here: it requires onchain activity to commit funds to any N parties, whether N=2 or N=3.
And that onchain activity will always be subject to reversal / double-spending unless confirmed deeply enough that we believe reorganizing the chain would be unlikely.

Basically: what are the inputs to the transaction that backs your 3-participant channel?
If any input can be signed by just one participant, then that participant can sign a different transaction spending that input in another way, then bribe a miner to include it in a mined block.

Thus, this fixes nothing: in order to get funds committed to the 3 participants, you need *some* confirmed transaction to commit those funds in the first place, and everyone still has to wait for that transaction to confirm, thus you cannot sidestep the confirmation-or-trust requirement.

Regards,
ZmnSCPxj

📅 Original date posted:2023-02-14 📝 Original message: Good ...

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

In reply to nevent1q…qz6a
_________________________

📅 Original date posted:2023-02-14
📝 Original message:
Good morning all,

> > First of all let's see what types of reputation system exist (and yes,
> > this is my very informal categorization):
> >
> > - First hand experience
> > - Inferred experience
> > - Hearsay
> >
> > The first two are likely the setup we all are comfortable with: we ourselves
> > experienced something, and make some decisions based on that
> > experience. This is probably what we're all doing at the moment: we
> > attempt a payment, it fails, we back off for a bit from that channel
> > being used again. This requires either being able to witness the issue
> > directly (local peer) or infer from unforgeable error messages (the
> > failing node returns an error, and it can't point the finger at someone
> > else). Notice that this also includes some transitive constructions,
> > such as the backpressure mechanism we were discussing for ariard's
> > credentials proposal.
> >
> > Ideally we'd only rely on the first two to make decisions, but here's
> > exactly the issue we ran into with Bittorrent: repeat interactions are
> > too rare. In addition, our local knowledge gets out of date the longer
> > we wait, and a previously failing channel may now be good again, and
> > vice-versa. For us to have sufficient knowledge to make good decisions
> > we need to repeatedly interact with the same nodes in the network, and
> > since end-users will be very unlikely to do that, we might end up in a
> > situation were we instinctively fall back to the hearsay method, either
> > by sharing our local reputation with peers and then somehow combine that
> > with our own view. To the best of my knowledge such a system has never
> > been built successfully, and all attempts have ended in a system that
> > was either way too simple or is gameable by rational players.
>
>
> In lightning we have a trivial solution to this - your wallet vendor/LSP is already extracting a fee
> from you for every HTLC routed through it, it has you captive and can set the fee (largely)
> arbitrarily (up to you paying on-chain fees to switch LSPs). They can happily tell you their view of
> the network ~live and you should generally accept it. Its by no means perfect, and there's plenty of
> games they could play on, eg, your privacy, but its pretty damned good.
>
> If we care a ton about the risks here, we could have a few altruistic nodes that release similar
> info and users can median-filter the data in one way or another to reduce risk.
>
> I just do not buy that this is a difficult problem for the "end user" part of the network. For
> larger nodes its (obviously, and trivially) not a problem either, which leaves the "middle nodes"
> stranded without good data but without an LSP they want to use for data. I believe that isn't a
> large enough cohort to change the whole network around for, and them asking a few altruistic (let's
> say, developer?) nodes for scoring data seems more than sufficient.

But this is all ultimately hearsay.

LSPs can be bought out, and developers can go rogue.
Neither should be trusted if at all possible.

Which is why I think forwardable peerswaps fixes this: it *creates* paths that allow payment routing, without requiring pervasive monitoring (which is horrible because eventually the network will be large enough that you will never encounter the same node twice if you're a plebeian, and if you're an aristocrat, you have every incentive to lie to the plebeians to solidify your power) of the network.

Ultimately the network gets healthier if flows are bidirectional, swaps are essential to bootstrapping from the starting state where there are distinct "customers" and "merchants", but current one-hop-only peerswaps are too local for the blockchain cost, and multi-hop source-routed swaps have the same issue as standard payments.
The advantage of forwardable peerswaps is that it is specifically not source routed --- intermediate nodes make decisions of where to forward, and they are thus incentivized to benefit the network because they benefit themselves.

I think it should be a principle of protocol design to embrace a capitalistic mindset, by which I mean: ensuring the rules make "beneficial for me" the same as "beneficial to everyone".
Certainly I can take a common knife from my kitchen and stick the pointy end into my neighbor, then take all their belongings, which would be very beneficial to me, but would not be beneficial to everyone, which is why laws against manslaughter and theft exist.
Ultimately, protocol design is the laying down of laws, and the proper function of this lawmaking position is to ensure that "beneficial for me" will be something that is "beneficial to everyone".
Indeed, the entire point of having a punitive Poon-Dryja is to ensure that "beneficial for me" does not include theft of the channel funds by using old state, and is exemplary of this principle.
"Greed is Good" might not be true, but perhaps: "We should strive to MAKE Greed Good".

Forwardable peerswaps are beneficial to every participant, and thus beneficial to the network, and thus should be part of the law of Lightning Network protocol.
It *creates* high availability of channels and routing, without self-assertions or hearsay; it only requires local reputation (a forwarding node will forward a peerswap only if it knows it can benefit from whichever hop it is forwarding to: the locality avoids the issue where a node may never interact with another node again, since the node has a channel with them and is expected to repeatedly interact with them in the close future, and thus has very good local information).

Regards,
ZmnSCPxj

📅 Original date posted:2023-01-03 📝 Original message: ...

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

In reply to nevent1q…mvkz
_________________________

📅 Original date posted:2023-01-03
📝 Original message:
Subject: Swap-in-Potentiam: Moving Onchain Funds "Instantly" To Lightning

by Jesse Posner, ZmnSCPxj

Introduction
============

Moving funds from an onchain-only address to Lightning Network is slow,
especially if you desire trust-minimization (which removes solutions
relying on 0-conf).

Basically, to reduce trust requirements in all onchain transactions,
onchain receivers *MUST* ensure confirmation of the onchain transaction
that creates their UTXO.
In practice, the minimum should be at least 3 blocks, since reorgs of
up to 2 blocks are common occurences, but even 1 confirmation can
take an inordinately long time in the real world due to the random
nature of mining.

This is particularly acute for mobile phone use-cases.
As mobile phones run on a battery, mobile phone OSs often greatly
restrict CPU and other resource consumption when an app is not
currently open by the user.

Now consider this user story, for a wallet app that supports both
Bitcoin blockchain and Lightning Network operations:

* The user wants to be paid over the Bitcoin blockchain.
* The user gets an address from their wallet and provides it to
some other party to receive their payment.
* The user closes their wallet app, which causes the mobile phone
OS to kill all its threads.
* The other party sends their payment over blockchain while the
user is asleep.
* The blockchain transaction confirms and time passes.
* The user wakes up and checks their favorite blockchain explorer,
and sees they received funds on their wallet address.
* The user opens their wallet app and decides they need a coffee,
so they buy coffee over Lightning.

For current solutions to move funds from the blockchain layer to
Lightning, however, the above user story would need to complete
over a long time, possibly measurable in dozens of minutes or
even hours in the worst case, due to the need for confirmation:

* Channel open: Requires confirmation, many nodes require 6 or
more confirmations.
* Submarine swap/peerswap: Requires confirmation before the swap
service will send out the HTLC on Lightning.
* Splice-in: Channel remains operational, but until the splice
transaction confirms, the channel operates in "dual mode"
where both pre-splice and post-splice state is valid, and
that means only the lower amount of the pre-splice and
post-splice can be used in the mean time.
For splice-in, the pre-splice amount will be lower, thus
the amount being spliced in will not be credited until
the splice transaction is confirmed.

In this writeup, we present a novel protocol, swap-in-potentiam,
that can be used for immediate transfer from the blockchain
layer to the Lightning layer, in the above user story.

Advantages And Limitations
--------------------------

To whet your appetite, here are the advantages:

* Immediate transfer of already-confirmed-received onchain
funds to Lightning.
* Onchain funds can also be transferred to another onchain
address (subject to normal onchain confirmation rules).
* This can be "immediate" if sending to a receiver that
accepts the risk of 0-conf onchain transactions.
* Minimized trust requirement.

The disadvantages, to help convince you that yes, this is
technology and not magic beans (and to not oversell this
tech, Bitcoin media reporting often tend to oversell
new technologies because the disadvantages are often
hidden away behind technical minutae):

* Requires a cooperating LSP.
If LSP is down or refuses to cooperate, onchain funds
are locked for some time.
This has a timeout (so if the LSP never comes online
again, you just wait out the timeout) and the timeout
starts from when the receiving UTXO is confirmed in a
blocks, so it will not cause loss of funds, only loss
of opportunity (i.e. "involuntary HODLing").
* If you have multiple LSPs, when you generate an address
you *have to* select one of them at that point, you
*cannot* commit to multiple LSPs and select one of them
later when your phone wakes up again.
This exacerbates the above disadvantage, since you have
to select one of your LSPs and hope that when your
phone wakes up the LSP you selected is also up and
cooperative.
* The onchain-received funds have to be confirmed first,
otherwise we still need to wait for confirmation of the
onchain-received funds.
This is generally true for many blockchain-only wallets
anyway and is thus not a worsening, but is also not an
improvement.
* If the timeout is too near, actions must be performed
onchain that require confirmation.

Swap-in-Potentiam
=================

All onchain fund movements, as noted, require confirmation.
These include onchain fund movements to the Lightning network.

If the onchain address that the wallet provides was controlled
solely by that wallet, then any action that requires cooperation
with a Lightning Network participant --- channel open, swap, or
splice --- would require an onchain transaction that commits to
that specific Lightning Network participant.
Only when the new onchain transaction is confirmed, can that
Lightning participant rely on the transaction output without
having to trust the initiator.

>From there, we can consider: what if the wallet provides an
address that *already* commits to that specific Lightning Network
participant?

If so, then the "timer for confirmation" starts as soon as
the wallet receives on the blockchain, not as soon as the wallet
decides to move funds from blockchain to Lightning.

This is a significant difference for a mobile wallet: the mobile
environment does not support the mobile wallet being online for
long.
Thus, the mobile wallet may not have any CPU to make the decision
to move funds from blockchain to Lightning, until the actual user
explicitly opens the mobile wallet app.

It has already been generally accepted that due to the limitations
of the mobile phone environment, a mobile phone wallet with
Lightning support would need some LSP anyway.
Thus, a mobile wallet that can receive on the blockchain layer
and then send on the Lightning layer can commit to a specific,
different, Lightning participant: the LSP it has channels with.

Thus, the mobile wallet can provide an address that commits to
one particular Lightning Network participant: its LSP.

The mobile wallet can then initiate a single-hop swap with the
LSP when the mobile wallet app is in the foreground and has CPU
to think with.
If it received funds into the address that have already been
confirmed, then it can do this single-hop swap immediately with
its LSP.
The LSP can immediately resolve this swap, crediting funds to
channel, while atomically ensuring it has sole claim to the
onchain UTXO.

The Contract
------------

The contract has two participants: Alice the funds owner, and
Bob its potential swap partner.

Once *any* funds have been confirmed received into an address
committing to this contract, Alice owns the funds and can
dispose of them as it likes (with cooperation from Bob).
The source of the funds need not be Alice, it could be a third
party that has an obligation to pay Alice onchain.

The contract has only 2 branches:

* Onchain/channel branch: Alice and Bob.
* Timelock branch: Alice plus a relative timelock (`OP_CSV`)
measurable in weeks.

Astute readers will realize that the above is really a variant
of [CLTV-style unidirectional time-limited channels][1],
themselves a variant of Spilman-style channels:

* Uses an explicit opcode to simplify channel setup (no need
to pre-sign a timeout transaction between Alice and Bob,
can just send funds directly to the address).
* Uses a relative locktime instead of an absolute one to
allow funding of the channel address (= receive onchain
funds ready to spend over Lightning) at any time.

The use-cases this enables are:

* If Alice wants to pay to another onchain address, and Bob
is also online and cooperative, Alice can ask Bob to help
sign the Onchain/channel branch to move the funds in any
arbitrary onchain manner.
* If Alice wants to pay to a Lightning invoice / keysend, and
has insufficient Lightning outgoing capacity (but has
sufficient *total* capacity), it can swap with Bob, by
offerring a transaction that spends via the Onchain/channel
branch and instantiates a fresh onchain HTLC that Bob can
then forward over Lightning.
As soon as Alice offers its signature of that transaction,
Bob can immediately offer an in-Lightning HTLC to Alice on
their channel, and then Alice can immediately resolve it
(thus immediately getting its funds into Lightning).
* If Bob is offline or uncooperative, Alice can unilterally
recover its funds after the timeout in the Timelock
branch.

Trust is required only to the extent that Alice trusts Bob to
be cooperative so that Alice can dispose of its funds immediately.
In case Bob turns out to be non-trustworthy, Alice can recover
its funds via the timelock branch after the timeout period.
There is no scope for Bob to steal funds (indeed, it is easier
for Bob to steal Lightning funds than to steal swap-in-potentiam
funds).

The intent here is that the mobile wallet is Alice, while the
LSP is Bob.

### Bob Security

Bob *MUST* ensure that, for each UTXO, it is either asked to
sign an arbitrary onchain transaction (i.e the first use-case
above) *OR* it gets offered an onchain HTLC from that UTXO.
Once Alice has asked Bob to cooperate in either case for a
particular UTXO, Bob *MUST* ensure that it does not sign the other
case (and Bob *MUST* refuse to cooperate in the other case once
one case has been requested).

In addition, Bob *MUST* ensure that, if it is used in the
"channel" case (i.e. the second use-case above), the timeout of
the Timelock branch is far enough in the future that it is likely
that spends using the Onchain/channel branch have confirmed by
then.

With both invariants enforced by Bob, Bob can ensure that, if
Alice requests a swap using the Onchain/channel branch, only Bob
can spend the UTXO (at least before the timeout), and thus can
safely offer a Lightning HTLC to Alice immediately without any
additional waiting for onchain confirmations.

As Bob needs to know the UTXO in the first use-case above, this
requirement prevents the use of blind signing techniques when
implementing the first use-case.
Basically, when being asked to sign, Bob must generate the entire
`SIGHASH` from data that Alice provides, so that Bob is able to
keep track of UTXOs it is signing for.

### Remote Swap

While Bob is generally considered "the" LSP of the mobile wallet
Alice, nothing in the Lightning protocol actually requires that
Bob be a direct peer of Alice.
The only real requirement is that Bob is able to send funds to
Alice over Lightning in exchange for possession of the equivalent
onchain funds.

Against this, we should note that the mobile wallet is already
dependent on one or more LSPs anyway, so it may as well just use
its direct peer LSPs instead of a remote node.

### Address Derivation

Swap-in-potentiam addresses can be derived from a root public or
private key.

We only need one keypair each from Alice and Bob.
Alice can use standard derivation paths for its keypair.

As Bob is intended to be an LSP, we can just use its Lightning
node ID as the public key.
Bob needs to be in possession of the corresponding private key
anyway in order to set up BOLT 8 encrypted transports.

As LSPs are part of the public network, Alice can simply try to
scan for all published nodes that advertise support for
swap-in-potentiam.
Alternately if the wallet has a short list of fixed LSPs it
will use, it can simply refer to that list.

Thus:

* Alice uses a derived keypair.
* Bob uses a fixed keypair (its Lightning node ID).

The above is sufficient to derive swap-in-potentiam addresses
from an `xprv` or `xpub` root key.

Swap-in-potentiam For LSPs
==========================

While the original design of swap-in-potentiam has the mobile
wallet in the "Alice" role and its LSP in the "Bob" role, it
turns out that LSPs can provide special service to improve
receiving mobile wallets.

Suppose that the LSP keeps track of statistics, and thus has
an idea of which of its mobile wallet clients are likely to
be net receivers.

Net receivers will often have low inbound capacity (since the
inbound capacity has been used up during previous LN receives).

During times of low onchain fees, an LSP can check which of its
offline mobile wallet clients have low inbound capacity, and are
likely to come online in the future to receive.
In those cases, the LSP can commit funds to a swap-in-potentiam
with the mobile client, with the LSP as "Alice" and the mobile
client as "Bob".
This at least lets the LSP set up half of a swap during a time of
low fees.

If the transfer to swap-in-potentiam addresses is confirmed by
the time the mobile wallet client comes online, the LSP can
immediately initiate a swap, giving inbound capacity towards the
mobile client.
This swap can be immediately resolved, and allows the mobile
wallet client to immediately receive funds over Lightning.

In particular, if "offline receive" as designed by TheBlueMatt
is implemented, then the LSP already has indication of a pending
payment towards an offline mobile wallet client.
The LSP can check if the offline mobile wallet client has
insufficient incoming capacity to receive the funds, and if so,
arrange to fund a swap-in-potentiam with that client.
Then, when the mobile wallet client comes online, the LSP can
initiate the swap with them, and once the swap completes (and
thus the mobile wallet client has sufficient incoming capacity)
the LSP can contact the sender LSP to complete the payment.

In particular, this use-case allows for *immediate* receives as
soon as the mobile wallet client gets foregrounded and has CPU
time, **without** requiring 0-conf trusted transactions and
thus without requiring any kind of semi-custodial trust, even
if the mobile wallet client had insufficient incoming capacity.
A channel still has to be set up beforehand (without 0-conf, if
trusting funds to the LSP is undesirable).

Implementation Sketch
=====================

The intent is to use Taproot with Schnorr signatures, but
**without** using the keyspend path (at least initially).

The plan currently is to use a `MuSig(A, B)` as the internal
pubkey, but with the branches still explicitly laid out as
tapleaves.
That is, there are two tapleaf SCRIPTs corresponding to the
two branches described above:

* `<A> OP_CHECKSIGVERIFY <B> OP_CHECKSIG`
* `<timelock> OP_CHECKSEQUENCEVERIFY OP_DROP <A> OP_CHECKSIG`

Using an explicit 2-of-2 branch rather than a MuSig allows
for a simple protocol at least for initial deployment:
we can have Alice send the signature using `A` in a single
half-round without having to engage in a 2-round MuSig2 signing
ritual.

We intend to use Taproot since the mobile wallet client
may need to use a 2-of-3 or 2-of-2 signing scheme, similar
to Blockstream Green.
This allows either Alice or Bob in the contract to secretly
be a FROST 2-of-3 or MuSig 2-of-2 (or any FROST k-of-n or
MuSig n-of-n).
This is also another reason for avoiding a 2-of-2 MuSig
keyspend path between Alice and Bob, as there is (to our
knowledge) no publicly-reviewed security proof that
FROST-in-MuSig and MuSig-in-MuSig are safe (or the
corresponding variants using MuSig2 for the signing
ritual).

Later, when we are more confident of the use of MuSig2 and
FROST inside a MuSig2, and with using MuSig2 with possibly
untrusted outsiders (who might exploit any mis-implementation
of the MuSig2 signing protocol if we are not careful with
designing it), we can seamlessly upgrade the protocol
to use the keyspend path later, to save witness bytes.

For the Onchain use-case (i.e. Alice wants to spend the UTXO
to an onchain address), the protocol betweeen Alice and Bob
would be:

* `request_arbitrary_signature` Alice->Bob: Requests Bob
to sign a PSBT spending a swap-in-potentiam address
using the Onchain branch.
* `response_arbitrary_signature` Bob->Alice: Response to
the above, returning the requested signature.
* `reject_arbitrary_signature` Bob->Alice: Sent in
response to `request_arbitary_signature` if Bob refuses
to cooperate (e.g. the UTXO being spent has already
been accepted by Bob in a Channel use-case below).

For the Channel use-case (i.e. Alice wants to spend the UTXO
to a Lightning receiver), we operate the swap-in-potentiam
UTXO(s) as a Spilman-like channel over two states:

* HTLC-offering: Offering an amount `N` HTLC from Alice to
Bob, with any remaining amount to a change address to
Alice.
* Resolved: Giving the amount `N` outright to Bob, with any
remaining amount to a change address to Alice.

The intention is that the channel is initially put into
the HTLC-offerring state.
Then Bob offers a corresponding in-Lightning HTLC to Alice
over their channel.
When Alice resolves the in-Lightning HTLC, it can then
send a new signature for the Resolved state.
Once the channel is in a Resolved state, Bob *SHOULD* sign
the last state and broadcast it on the blockchain, thereby
closing the Spilman-like channel.

The protocol messages for the Channel use-case are:

* `request_swap_in` Alice->Bob: Tell Bob the UTXOs with
the same swap-in-potentiam address to spend, how
much to put into the Alice->Bob channel direction,
what channel to move into, and (optionally) a change
address for Alice.
* `reject_swap_in` Bob->Alice: Sent in response to
`request_swap_in` if Bob refuses to cooperate (e.g.
one of the UTXOs on offer was already signed with
`response_arbitrary_signature`, or Bob cannot legally
accept control of funds from one or more of the UTXOs
offerred).
* `accept_swap_in` Bob->Alice: Sent in response to
`request_swap_in`, containing the Bob-side address to
send funds to later once the state is Resolved.
* `swap_in_signed` Alice->Bob: Response to
`accept_swap_in`, containing the Alice-side signature
for the HTLC-offering state transaction.
Once Bob receives this, Bob can safely construct a
new on-Lightning HTLC using BOLT1
`update_offer_htlc`.
* `swap_in_resolved` Alice->Bob: Sent after Alice has
acquired the funds via `update_fulfill_htlc` of the
corresponding on-Lightning HTLC, containing the
Alice-side signature for the Resolved state
transaction.
The Resolved state transaction spends to the Bob-side
address given in `accept_swap_in`, and any change to
the Alice-side change address in `request_swap_in`.

The plan is to reserve only one odd BOLT1 message ID,
and to embed the actual swap-in-potentiam message ID
as the first 2 bytes of the BOLT1 message, to reduce
pollution of the limited BOLT1 message ID space and to
allow more flexibility for swap-in-potentiam to expand
to new messages inside its own message ID space.

For a richer future protocol, we will want to consider
how a swap-in can be combined with a splice-in.
This is useful if the current total capacity of the
channel is lower than the available onchain funds.
The swap-in can be credited immediately (and is limited
to the current total capacity) while additional funds
can be added to the channel via splice-in (which is
credited only once the splice-in is confirmed).

As-is, a similar result can be obtained using openv1,
wherein a swap-in is combined with a channel open,
with the swap-in immediately credited while the channel
open is awaiting confirmation:

* Alice and Bob currently have one or more existing
channels, and Alice has a UTXO in a swap-in-potentiam
address whose value exceeds the incoming capacity of
the existing channel(s).
* Alice->Bob `open_channel`.
* Bob->Alice `accept_channel`.
* Alice->Bob `request_swap_in` with the "change address"
being the funding address of the channel.
* Bob->Alice `accept_swap_in` provides the TXID of the
funding transaction (Alice now knows the "change
address" and the Bob final Resolved address, letting it
know the final Resolved state transaction TXID).
* Alice->Bob `funding_created` with the TXID.
* Bob->Alice `funding_signed`.
* Alice->Bob `swap_in_signed` to provide the signature
spending the swap-in-potentiam address to Bob.
* Bob then constructs an HTLC over the existing channel,
which Alice claims, revealing the preimage.
* Alice->Bob `swap_in_resolved`.
* Bob then broadcasts the Resolved state transaction,
which is also the funding transaction of the new channel.
* Both Alice and Bob await confirmation of the transaction
in order to use the new channel.
Alice can still use the existing channel, which has been
topped-up with fresh outgoing capacity by the swap-in.

(The above is not safe, as Bob can complete the protocol
by using the HTLC-offerring state transaction; this can
be fixed by having Alice open *2* channels with the same
amount, one with the HTLC-offering state transaction as
the funding tx, the other with the Resolved state
transaction as the funding tx, and later `error`ing the
channel corresponding to the transaction that is not
confirmed; this is left as an exercise to the reader,
though note that it requires two different change addresses
for Alice for both HTLC-offerring and Resolved states,
which can be arranged for the protocol)

--

[1]: https://en.bitcoin.it/wiki/Payment_channels#CLTV-style_payment_channels

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

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

In reply to nevent1q…3g24
_________________________

📅 Original date posted:2022-11-28
📝 Original message:
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

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

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

In reply to nevent1q…qg8w
_________________________

📅 Original date posted:2022-11-25
📝 Original message:
Good morning Antoine,

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

This seems incorrect.

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.

This is even worse if my competitor LSP attaches their credentials on trampolines, I do not even need to apply to be a spoke on my competitor that way.

Thus in both cases the competitor LSP needs to have a similar way of ensuring that their spokes / trampoline requesters are not also trying to jam *them* in order to drain their reputation.
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.

Regards,
ZmnSCPxj

📅 Original date posted:2022-10-09 📝 Original message: ...

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

In reply to nevent1q…nxs7
_________________________

📅 Original date posted:2022-10-09
📝 Original message:
Subject: Forwardable Peerswaps

Introduction
============

[Peerswap](https://peerswap.dev) is a protocol for swapping onchain funds
and offchain in-Lightning funds.
The intent of this protocol is to allow managing the inbound and outbound
capacities of your node without having to perform rebalancing.

Rebalancing is arguably a parasitic behavior, preying on low-fee channels
to buy out their available capacity, then turning around to resell the
purchased capacity at a higher fee.
By using swap services instead, a node manager can adjust capacity and
effectively add capacity to the network in the needed direction, without
pushing their own lack of capacity to a victim.

However, a limitation of peerswap is in its name: a peerswap is performed
with *only* a direct peer with which you have a channel.

This writeup then proposes an extension to the overall peerswap protocol
to work around this limitation, which I call "forwardable peerswap".

I would like to make the claim that forwardable peerswaps solves the
problems that the following previous proposed and deployed solutions
attempt to fix:

* Liquidity markets (liquidity ads, Lightning Pool, etc.)
* Flow control valves (fee-based flow control / passive rebalancing,
`htlc_maximum_msat`, etc.)

An important part of forwardable peerswaps is that it "hides" a
network-health-improving operation in a "channel top-up" operation
(i.e. moving onchain funds to Lightning) that net senders will want to
do anyway (or else they stop being net senders).

Swaps vs. Splices
=================

A peerswap and a splice are very similar, in that they change the state
of one of our local channels, adding or removing outbound capacity on
that channel.

However:

* A swap will always take 2 onchain transactions:
* An offer transaction that has an HTLC output.
* A claim transaction that spends the above HTLC output.
This spend can take up more space, requiring a SCRIPT revelation,
a signature, and a preimage revelation.
* If designed to limit onchain footprint, a splice can take just one
onchain transaction.
* This spend will take only a SCRIPT revelation and two signatures,
or with Taproot can be reduced to a single signature without any
SCRIPT/Tapscript revelation.

Thus, a swap takes more onchain resources than a splice, and if we are
considering the state of a *single* channel alone, then a splice is
definitely more efficient.

However, if a swap extends beyond one hop, then the number of channels
affected by the swap is increased.
And yet, no matter how many channels are affected, the swap will
still take only two transactions.
Thus, swapping will exceed the efficiency of splicing once three or
more hops are considered.

The problem here is that, as indicated by its name, a peerswap is
limited to affecting only one channel, a channel between ourselves and
one of our direct peers.

Now, this limitation of peerswap is not without its justification:

* A multi-hop payment is inherently less reliable, as it requires
multiple nodes to be continuously online at the same time.
* Intermediate LN nodes might not want the change in channel state
(i.e. the multi-hop payment might worsen their channel balance).
* Offchain-to-onchain swaps impose an economic risk on the acceptor
of the swap, which a peerswap can punish by closing the direct
channel but which a remote swap cannot punish.

Peerswap User Story
===================

Suppose we have a small network of nodes A, B, and C, initially
with channels perfectly balanced, as all things should be.

Suppose however that after some time, A notices that its channel
to B has little outbound capacity.

A can then propose a peerswap between A and B: A offers some
onchain funds in order to change the state in their channel,
getting more outbound capacity from A.

Suppose B accepts this and completes the peerswap protocol.

Now B is in possession of some onchain funds.
B then notices that its channel to C has little outbound capacity.

B can then propose a peerswap between B and C: B offers some
onchain funds in order to change the state in their channel,
getting more outbound capacity from B.

Suppose C accepts this and completes the peerswap protocol.

Now what happens in sum total on the blockchain layer?
We will see two swaps, each with 2 transactions, for a total of
4 transactions onchain.

Forwardable Peerswap
====================

To improve this, suppose we change the above user story, starting
at this point:

A can then propose a peerswap between A and B: A offers some
onchain funds in order to change the state in their channel,
getting more outbound capacity from A.

Suppose B then looks up its channels.
B then notices that its channel to C has little outbound capacity.

B can then propose a peerswap between B and C: B offers some
onchain funds in order to change the state in their channel,
getting more outbound capacity from B.
However, B is really going to act as little more than a message
translator between A and C, forwarding peerswap messages from A
to C and replies from C to A.

Thus, A thinks it is talking to B, but really it is negotiating
the peerswap with C, using B as a medium.
And vice versa, C thinkgs it is talking to B, but really it is
negotiating the peerswap with A, using B as a medium.

Further, C itself could end up forwarding the peerswap to yet
another node, which itself could forward the peerswap, etc.

Yet no matter how many hops the peerswap ends up getting
forwarded, there will only be two transactions onchain: one to
instantiate the onchain HTLC, another to claim it.

The overall changes are:

* A should initially offer an onchain HTLC with a longer then
expected timeout, so that B (and C, D, etc.) has an
opportunity to consider forwarding the peerswap.
* B should demand a longer in-Lightning HTLC timeout than what
A demands from it (and so on for C, D, etc.).

What Peerswaps Are Forwardable?
-------------------------------

Let us be absolutely clear that there are actually two
sub-protocols of peerswap:

* Onchain-to-offchain: An initiator offers onchain funds to
get more outbound capacity.
* Net senders want to do this.
* Offchain-to-onchain: An initiator offers offchain funds to
get onchain funds and more inbound capacity.
* Net receivers want to do this.

Unfortunately, only the first sub-protocol (onchain-to-offchain)
is actually forwardable.

This is because, in the latter case, the initiator can force
the acceptor to waste resources, by aborting the protocol after
the acceptor has committed onchain funds to the HTLC.
Lightning HTLCs are trivially cancellable, but onchain HTLCs
can only be returned by waiting out the timeout and spending
onchain fees to recover the funds.

In a peerswap, the latter case is fixed by closing the channel
with the initiator, thus punishing them for aborting the protocol.
However, this punishment cannot be done in the forwarded case
without massive channel closures, which turns this into an
attack on the network.

Thus, forwardable peerswaps can only be of the onchain-to-offchain
type that are initiated by net senders.

Now you might wonder, how about net receivers, how would they
initiate forwardable peerswaps?
As I will demonstrate in a much later section, any
onchain-to-offchain forwardable peerswaps initiated by net
senders will make their way to some net receiver, and thus
net receivers need only wait and they will naturally get some
kind of forwardable onchain-to-offchain peerswap that will
also get them inbound capacity.

Future innovations (beyond the scope of this writeup, that is
what "future" means) may allow us to develop an offchain-to-onchain
remote swap that can effectively punish the initiator if it
does not complete the swap.
This would allow offchain-to-onchain peerswaps to also be
forwardable, which can only be beneficial to the network.
This may be hopium, however.
Nevertheless, even just forwardable onchain-to-offchain
peerswaps are still beneficial, as we shall see in succeeding
sections.

Advantages Of Forwardable Peerswap
==================================

Compared to the current peerswap:

* A forwardable peerswap can affect more than just one channel,
improving the blockchain space utilization.

Compared to multi-hop swaps:

* Each node has the opportunity to decide whether to forward
the peerswap or not, depending on the states of its other
channels.
If none of its other channels have a state that would be
improved by forwarding the peerswap, the node can end the
peerswap forwarding at itself and just accept the onchain
funds.
* There is still the issue of multiple nodes having to
coordinate in order to finish the forwarding and complete
the protocol.
Hopefully, for nodes used often on the public network,
uptime should be high, and nodes can monitor peer uptime
and use this information to decide whether to forward a
peerswap to a particular peer or not.

In particular, we can also compare forwardable peerswaps to
standard forwardable payments on Lightning:

* Forwardable payments are source routed for privacy of the
payer (and some minor privacy of the payee).
* Due to the source not having access to the private
information of intermediate nodes, it cannot know if the
intermediate nodes would like the change in capacity, or
if the intermediate nodes even *have* the correct capacity.
* Forwardable peerswaps are effectively packet-routed, with
each node deciding where exactly to forward (or to not forward)
each peerswap.
* Each node has perfect information on which of its channels
would appreciate the change in capacity, and also perfect
information on which of its peers is online right now, who
has high uptime, etc.

Fees And Incentives For Individual Nodes: Why Net Receivers Still Benefit
=========================================================================

A node forwarding a peerswap should not charge a fee for
the forward.
Any fee that the peerswap initiator may offer should be
paid, in full, to the ultimate acceptor of the forwarded
peerswap.

Consider a node that forwards an incoming peerswap request,
instead of accepting it itself.
That node:

* Gets *two* of their channels balanced better.
* Does not have to perform any onchain activity.

In short, it gets a free rebalance.

That is enough incentive, as the intermediate node can
expect more future income from having two channels
with improved balance, and does not have to spend anything
on onchain activity.

The forwarding node will, if it is rational, forward it
over a channel that lacks outgoing capacity.
This translates to forwarding it to a next hop that has
low incoming capacity.

If there are net senders and net receivers in the network,
then the senders will deplete their on-Lightning funds on
all their channels.

If a net sender depletes their on-Lightning funds:

* If the net sender can no longer acquire funds, they
stop being a net sender and we can ignore them.
* If the net sender can acquire funds and get them on
Lightning, they stop being a net sender and end up
being neutral to the network, since the funds they
can send out must be less than or equal to the funds
they receive.
They stop being a net sender and we can ignore them.
* If the net sender can acquire funds and get them
onchain, they can use the onchain funds ot initiate
onchain-to-offchain peerswaps.

If *all* net senders have depleted their funds and
can no longer get funds from either Lightning or
onchain (i.e. nobody starts a forwardable peerswap),
then net receivers will not receive more funds anymore
anyway (nobody is getting more funds to send) and the
fact that they have insufficient inbound capacity is
immaterial, so the fact that they cannot initiate a
forwardable peerswap is not a problem.

Now let us focus on a net receiver.
A net receiver is one where the payment flows are, in
sum, towards them.
This implies that, without further channel creations,
the inbound capacity they have will be depleted.
This also implies that they have much too large
outbound capacity, due to how channels work.
A net receiver is therefore a node with too much outbound
capacity.

Suppose net sender uses a peerswap that can be
forwarded.
Then its direct peer has an incentive to look at its
other channels to forward the peerswap to, so that it
gets two channels rebalanced for free without having
to be responsible for an onchain UTXO.

Now, suppose the forwardable peerswap reaches a node
who finds that it cannot forward the onchain-to-offchain
peerswap anymore.
This would occur if the node has too much outbound
capacity, and cannot add more outbound capacity with
its peers.

Now recall that a node with too much outbound capacity
is a node that has too little inbound capacity.
And a node with too little inbound capacity is a net
receiver.

Thus, forwardable peerswaps will start at net senders
and will be naturally pathed to terminate at net
receivers.
This is the advantage of forwardable peerswaps being
packet-switched instead of source-routed.

(Yes, problems and other things can occur along the
way and the real world and so on, but considered
in an ideal world, forwardable onchain-to-offchain
peerswaps will naturally path from net senders to
net receivers.)

Comparison To "Just Make A Channel"
===================================

Suppose a net sender just looks at it history of
payments and makes a direct channel to a node that it
usually pays to anyway, using its cold-storaged onchain
UTXO to fund the new channel.

This heuristic would probably work, but note that
just because a net sender is paying a node, does not
mean that *that* node is itself a net receiver!

Merchants have to pay:

* Suppliers of raw materials.
* Employees.
* Shareholders and owners of the business.

In a future where everyone gets paid over Lightning,
it is likely that merchants you pay to may themselves
not even be net receivers of money over Lightning.

In that case, the "just make a channel" technique will
cause capital to be locked inefficiently, since the
merchant that the net sender is paying is not really a
net receiver, and the added capacity towards them would
be underutilized.

A forwardable peerswap, because of the incentive of each
individual hop, will eventually locate the *actual*
net receivers and thus forward the needed capacity
adjustments to those receivers, even if the net sender
does not know who the *real* net receivers on the network
are.

Thus, forwardable peerswaps will allocate capital more
efficiently, simply by following the incentives of each
individual public routing node.

Further, if the net sender regularly uses unpublished
channels, then the capacity they add to the merchant
they usually pay is not even utilizable by the rest
of the network.
However, if a forwardable peerswap is used, even if
it starts at an unpublished channel, it can be routed
out over the public network and thus have the capacity
utilized by the rest of the public network.

If the net receivers of the network are *also* using
unpublished channels, then the forwardable peerswap
can also still reach them, since their direct peer
still knows about them and can decide to forward the
peerswap to them.
Thus, forwardable peerswaps can adapt to a world where
unpublished channels have not been delere sufficiently.

On Liquidity Markets
--------------------

There are various liquidity markets already deployed
or being developed.

These liquidity markets are intended to make the
"Just Make A Channel" strategy be guided better, by
having net receivers somehow directly contact net
senders so they can make direct channels and get
the needed capacity.

However, this often means that additional information
must be broadcast and/or additional resources kept
in reserve.

* With e.g. Lightning Pool, net receivers must provide
their contact information and inbound capacity needs
to a centralized server, which can be attacked or
taken over to filter out particular, identified net
receivers (i.e. censorship).
* With e.g. liquidity ads, there is no central server,
but all forwarding nodes have to broadcast their
liquidity ads, and all forwarding nodes have to keep
some funds in onchain reserve, in case a new net
receiver wants to buy liquidity from them.

Finally, liquidity markets are often targeted at getting
net receivers in touch with forwarding nodes.
But ideally, forwarding nodes have an almost net zero
flow on the network, and what needs to really be matched
up are net senders to net receivers.
Presumably forwarding nodes that participate in liquidity
markets are hoping that net senders will randomly build
channels to them, but that is not assured and a net
receiver that matches up with a forwarding node may find
that the forwarding node has actually oversold its inbound
capacity.
What needs to *actually* be done is match up net receivers
to net senders.

In contrast:

* In forwardable peerswaps, nobody knows who the
net receivers are.
A direct peer of a net receiver might forward a
peerswap to them, but if the net receiver has
other channels, that peer cannot be sure it
terminates to them or is further forwarded.
Thus, not even direct peers of a net receiver
can learn that they *are* a net receiver.
* Even if a direct peer of the net receiver somehow
knows them for a net receiver, they have
disincentive to "filter out" the net receiver: they
would not earn fees from the channel with the net
receiver.
If they wanted to impede the net receiver from
being paid, they should have just closed the
channel with them instead of maintaining it.
But the net receiver can then go connect to
some other node that still supports forwardable
peerswaps, because decentralization, and thus
cannot be censored without a network split.
* Purely forwarding nodes never need to maintain
any onchain funds --- they will just forward
peerswaps through them and gain the benefit of
having two channels better balanced without
having to touch onchain funds.
This is unlike liquidity ads, which requires
that liquidity ad-broadcasting forwarding
nodes keep a stock of onchain funds to service
dual-funding requests.
This lets forwarding nodes maximize their
on-Lightning funds for more earnings, without
having to speculatively reserve some funds
onchain, as in the liquidity ads case.
* Forwardable peerswaps, due to being packet-switched,
will naturally gravitate from net senders to net
receivers, with almost-net-zero forwarding nodes
naturally pathing them from the former to the
latter.
This effectively forms a matchmaking between them.
While forwarding nodes want to be mildly net
receivers, the expected earnings are tiny and
it would be likely a long time before their inbound
capacity is depleted, and if so, they can then
terminate a received forwardable peerswap at
themselves, just like any other net receiver.

Comparison to "Rebalance Rebalance Rebalance"
=============================================

Currently, forwarding nodes manage their balances via
rebalancing, i.e. making a self-payment, from a channel
with high outgoing capacity to a channel with low
outgoing capacity.

Because the fees they earn on Lightning are very small,
such forwarding nodes will select rebalancing routes with
low fees, and will have strict budgets on how much they
are willing to spend on rebalancing.

What then happens is that random altruists who set their
fees to very low, or even zero, will find that forwarding
nodes will keep rebalancing via their channels.
As multiple forwarding nodes vie for the limited amount of
capacity on such low-fee channels, by the time an actual
economic-activity non-rebalancing payment reaches one of
those altruist nodes, the available balance towards
net receivers has been depleted, having been transferred
to rebalancing forwarders, leading to payment failure and
longer payment settlement times.

Thus, rebalancing forwarders who want to turn a profit,
end up (deliberately or not) exploiting altruists who
are setting their fees too low.

(Though since altruists will often say that they are doing
this "to help the network", we should note that the
profiteering forwarding nodes *are* component parts of the
network, so the altruists have in fact achieved their stated
goal.
It would be different if the actual goal was "to help
payers pay cheaply", which is not achieved.)

Now consider a world where forwardable peerswaps is
widely deployed on the network, and widely initiated by
net senders to top up their channels.

In that world, if a forwarding node receives a forwardable
peerswap, they can rebalance two of their channels favorably
without spending anything.

A self-paying rebalance would still need to pay out fees.
Even if a rebalancer is exploiting a zero-fee-routing
node, it is likely that one or more of the nodes between
it and the exploited altruist will charge a non-zero fee.
Thus, there will still be a cost to a self-paying rebalance.
In contrast, accepting and forwarding a forwardable peerswap
would gain the same benefit as a successful rebalance (fix
the balance of two channels), but at zero cost to the
forwarder.

A self-paying rebalance does have the advantage that it
can be performed at any time, whereas forwarding a
forwardable peerswap requires waiting for an opportunity
to do so.
But if forwardable peerswaps are widely deployed on the
network and happen often enough, then it may be sufficient
that forwarders find that active self-paying rebalancing
is no longer sufficiently advantageous, and that behavior
is therefore suppressed.

This should then lead to a world where the exploitation
of those altruists charging low fees for their capacity is
greatly reduced, since active self-paying rebalancing is
no longer particularly needed by profiteering forwarding
nodes.

Comparison To "Flow Valves"
===========================

Due to channel depletion causing payment delays, there
are proposals for some kind of "flow valve" to modulate
payment flows on the Lightning Network.

* Fee-based valves broadcast feerates to signal how much
outbound capacity is in a particular direction, to
entice users to the channel via low fees, or drive
away users (and reduce flow) via high fees.
* `htlc_maximum_msat` valves broadcast changes to
that advertised parameter to change how much payment
flow goes through a channel.
* This is unfortunately broken as users can split
their payments (or self-paying rebalances, for that
matter) to below the `htlc_maximum_msat`, and thus
get around the flow valve.
This can be fixed by using a sufficiently high
non-zero base fee, but that is arguably switching
over to a fee-based flow valve.

In both cases, flow valves not only have to be
widely broadcast across the network (increasing
bandwidth consumption) but it also leaks information
about the capacity of channels of the forwarding nodes,
and thus indirectly leaks information about who net
senders and net receivers are (by observing which flow
valves are the more limiting).

But more importantly, flow valves increase the friction
of using Lightning Network.
If the friction is high enough, users will switch to
another payment network.

Rather than install flow valves (which would slow down
LN payment velocity) we just make forwardable peerswaps
as a pressure release valve, releasing pent-up
pressure-to-pay by diverting it on a swap over the base
Bitcoin blockchain.

This effectively admits that we *do* need to switch
over to another payment network once Lightning starts
getting overloaded.
Basically, a forwardable peerswap is a payment, from
some net sender to some net receiver, over the
Bitcoin blockchain (i.e. the "another payment network")
rather than over Lightning.

However:

* A net sender may be matched up to an arbitary net
receiver that is physically nearby on the Lightning
Network, but which the net sender does not, in fact,
have direct economic ties with.
Thus, onchain surveillors cannot derive any information
from this onchain payment, other than "looks like the
Lightning Network is busy today".
* A succesful forwardable peerswap is a pressure release
valve, which resets the state of multiple channels on
the network, from net senders to net receivers, and
thus enabling further payment flows involving them
and their neighborhood.
There is thus no need for a flow valve.
* There is no need to broadcast anything, and forwarding
nodes do not need to leak their channel balances over
the gossip network.
* Users are already conditioned to accept that onchain
activity is costly, but have been convinced that
Lightning is cheaper and faster.
If flow valves are used, they may cause Lightning to
work slower and more expensively, thus breaking that
expectation.
But if forwardable peerswap is used instead, users
who use onchain funds to "top up" their channel end
up initiating a forwardable peerswap that keeps the
rest of the network cheap and fast, while accepting
that the onchain activity involved in this will be
costly and slow since that is what onchain activity
inherently is.

📅 Original date posted:2022-09-26 📝 Original message: Good ...

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

In reply to nevent1q…mrzl
_________________________

📅 Original date posted:2022-09-26
📝 Original message:
Good morning aj,

> > Basically, the intuition "small decrease in `htlc_max_msat` == small decrease in payment volume" inherently assumes that HTLC sizes have a flat distribution across all possible sizes.
>
>
> The intuition is really the other way around: if you want a stable,
> decentralised network, then you need the driving decision on routing to
> be something other than just "who's cheaper by 0.0001%" -- otherwise
> everyone just chooses the same route at all times (which becomes
> centralised towards the single provider who can best monetise forwarding
> via something other than fees), and probably that route quickly becomes
> unusable due to being drained (which isn't stable).

All monetisation is fee-based; the question is who pays the fees.
Certainly gossiped feerates will work less effectively if fees are paid via another mechanism.

In particular, discussing with actual forwarding node operators reveals that most of them think that CLBOSS undercuts fees too much searching a short-term profit, quickly depleting its usable liquidity in the long term.
In short, they want CLBOSS modified to raise fees and preserve the liquidity supply.
This suggests to me that channel saturation due to being cheaper by 0.0001% is not something that will occur often, as most operators will settle to a feerate that maximizes their earnings per unit liquidity they can provide, not trying to undercut everyone.

In particular, the fact that rebalancing already exists as part of the network protocol means that anyone trying to undercut will find their liquidity being bought out by more patient operators, who are willing to sacrifice short-term profits for long-term consistent earnings.

In short, the market will fix itself once we have more rational automated actors in place (i.e. not CLBOSS).
Indeed, price signals are always places where you should pay attention to whether you need more of a good or not.

But maybe I am just modelling everything incorrectly.
Certainly the fact that fees can be paid by somebody else other than senders can make gossiped feerates (which are the sender-paid feerates) less effective.

Regards,
ZmnSCPxj

📅 Original date posted:2022-09-27 📝 Original message: Good ...

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

In reply to nevent1q…2utu
_________________________

📅 Original date posted:2022-09-27
📝 Original message:
Good morning aj, Rene, and all,

So let me discuss a little more about how I model the forwarding nodes.

Forwarding nodes want to maximize profit.

Forwarding nodes sell liquidity.

If a forwarding node runs out of stock of liquidity (i.e. their channel is unbalanced against the direction a payment request fails) they earn 0 profit.

If a forwarding node finds a liquidity being sold at a lower price than they would be able to sell it, they will buy out the cheaper stock and then resell it at a higher price.
This is called rebalancing.
In particular:

* Other economic activity is likely to be "has to happen at a particular time".
* The intuition here is that people are not going to pay until they become interested in purchasing a product, and only then will they actually send out an HTLC.
* Rebalances (i.e. hostile takeover bids of cheap liquidity) are "can happen at any time".
* Thus, rebalances are likely to occur "first", because they can happen at any time, and can be done right now, whereas payments will need to wait until somebody somewhere is interested in paying.
* Thus, channels advertising low fees are likely to have their liquidity bought out by patient forwarding nodes.

The above implies that any "payment size distribution" can, and *will*, be manipulated by forwarding nodes out to buy out cheap liquidity.
If you introduce an artificial impediment and say "I will only accept payment sizes below N millisats", and then go "I will #zerofeerouting guy", then a forwarding node will just split their rebalance into quanta of N millisats and make a spike in the payment size distribution and drain your channel anyway, so that they can turn around and resell the liquidity at a higher price later.

This also suggests to me that fees being paid by out-of-band means (i.e. "monetizing outside of the Lightning forwarding fees") is likely to fail, because forwarding nodes will exploit that and do a hostile takeover of the cheap liquidity.
i.e. #zerofeerouting will never be a reliable forwarding node, because all the other forwarding nodes will be taking their liquidity for cheap long before you think to make a payment through them.

Rebalances cannot be differentiated from payments unless you force publication of source and destination (and even if you forced that, people can lie about who the *real* source and *real* destination are, so why bother).
And rebalances are going to target cheap liquidity and will avoid any non-fee valves you impose.

Invisible hand wins, yo.

Regards,
ZmnSCPxj

📅 Original date posted:2022-09-25 📝 Original message: Good ...

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

In reply to nevent1q…pc9y
_________________________

📅 Original date posted:2022-09-25
📝 Original message:
Good morning aj, and Rene,

> * you're providing a way of throttling payment traffic independent of
> fees -- since fees are competitive, they can have discontinuous effects
> where a small change to fee can cause a large change to traffic volume;
> but this seems like it should mostly have a proportional response,
> with a small decrease in htlc_max_msat resulting in a small decrease in
> payment volume, and conversely. Much better for stability/optimisation!

This may depend on what gets popular for sender algorithms.

Senders may quantize their payments, i.e. select a "standard" value and divide all payments into multipath sub-payments of this value.

* Simplifies the computation of base fee when using a min-cost solver.
* Simplifies the design of splitting/merging decisions if not using a min-cost solver.
* Improves privacy once we have PTLCs (if most senders use the same standard value, it is much harder to figure out if two sub-payments, with approximately the same standard quantum, belong to the same payment or not).

If so, then we expect a large discontinuity for the `htlc_max_msat` vs `htlcs_sent` curve around whatever selected quantum there is.
If you set `htlc_max_msat` below this quantum your expected number of payments forwarded will drop to near 0, but a little above that and you might very well saturate since all payments are quantized anyway.

At least fees gets you basic economics of supply and demand, and is a natural throttle in all markets, including liquidity markets.

Regards,
ZmnSCPxj

📅 Original date posted:2022-09-25 📝 Original message: Good ...

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

In reply to nevent1q…z0pf
_________________________

📅 Original date posted:2022-09-25
📝 Original message:
Good morning again aj, and Rene,

> Good morning aj, and Rene,
>
> > * you're providing a way of throttling payment traffic independent of
> > fees -- since fees are competitive, they can have discontinuous effects
> > where a small change to fee can cause a large change to traffic volume;
> > but this seems like it should mostly have a proportional response,
> > with a small decrease in htlc_max_msat resulting in a small decrease in
> > payment volume, and conversely. Much better for stability/optimisation!
>
>
> This may depend on what gets popular for sender algorithms.
>
> Senders may quantize their payments, i.e. select a "standard" value and divide all payments into multipath sub-payments of this value.
>
> * Simplifies the computation of base fee when using a min-cost solver.
> * Simplifies the design of splitting/merging decisions if not using a min-cost solver.
> * Improves privacy once we have PTLCs (if most senders use the same standard value, it is much harder to figure out if two sub-payments, with approximately the same standard quantum, belong to the same payment or not).
>
> If so, then we expect a large discontinuity for the `htlc_max_msat` vs `htlcs_sent` curve around whatever selected quantum there is.
> If you set `htlc_max_msat` below this quantum your expected number of payments forwarded will drop to near 0, but a little above that and you might very well saturate since all payments are quantized anyway.
>
> At least fees gets you basic economics of supply and demand, and is a natural throttle in all markets, including liquidity markets.

Basically, the intuition "small decrease in `htlc_max_msat` == small decrease in payment volume" inherently assumes that HTLC sizes have a flat distribution across all possible sizes.
The `htlc_max_msat` vs `payment_volume` curve is basically the integral of the distribution of HTLC sizes.
But:

* As above, senders might quantize, and if some standard quantum becomes popular, the distribution is really a spike around the standard quantum, and there is a massive discontinuity there.
* Coffee or other popular everyday product may settle on a standard price, which again implies a spike around that standard price.

So the reliability of `htlc_max_msat` as a valve is dependent on market forces, and may be as non-linear as feerates, which *are* the sum total of the market force.

Feerates on the other hand are always going to be something that senders optimize for, because obviously senders will have a maximum amount they will be willing to pay in fees (as before, the intuition here is that the maximum fee senders are willing to pay is equivalent to the difference in subjective value between the millisatoshis they are sending and the service/product they are purchasing).
Whatever future sender algorithms are devised, feerates will still work consistently as a valve, whreas `htlc_max_msat` may fail in a future where sender algorihms quantize the payments around some standard quantum for privacy and ease-of-implementation purposes.

Regards,
ZmnSCPxj

📅 Original date posted:2022-09-22 📝 Original message: Good ...

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

In reply to nevent1q…cp45
_________________________

📅 Original date posted:2022-09-22
📝 Original message:
Good morning Dave,

> On 2022-09-13 11:15, lisa neigut wrote:
>
> > Hi all,
>
>
> Hi Lisa,
>
> Thank you for describing this idea in detail on the mailing list.
>
> > A ratecard is a set of four values, positive or negative, that price
> > different bands of available liquidity for a channel.
>
>
> Am I understanding correctly that this implies spenders wanting to send
> an LN payment will either need to estimate the current division of funds
> for every hop along their projected path or will need to pay the highest
> ratecard for each hop? How are spenders supposed to make those
> estimates about the division of funds in distant channels?
>
> If there's no easy and network-friendly way for spenders to gather that
> information, I would worry that will lead to the creation of services
> which do collect the info and which become central to LN's operation.

As I understand it, it is exactly the same way that is done currently: the sender optimistically tries a route with a particular feerate, and if that fails, tries another route.

Basically, you can model a rate card as four separate channels between the same two nodes, with different costs each.
If the path at the lowest cost fails, you just try at another route that may have more hops but lower effective cost, or else try the same channel at a higher cost.

If your concern is valid, one wonders why it would not already exist now in the current network where try-and-try-again is the standard overall algorithm for payments.

Regards,
ZmnSCPxj

📅 Original date posted:2022-08-26 📝 Original message: Good ...

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

In reply to nevent1q…uzzf
_________________________

📅 Original date posted:2022-08-26
📝 Original message:
Good morning Rene,

> Dear fellow Lightning Developers,
>
> I was recently on an event where the visitors have been gifted 10k sats on a custodial wallet. They could spend those sats via some web interface and an NFC card. During the event I was contacted by several plebs who were confused about one particular thing:
> It was impossible for them to withdraw the full amount from the service.
>
> Pasting an invoice for 10k sats would not work as the custodial service required a fee budget of 1%. However if people submitted an invoice for 9900 sats the remaining 100 sats were usually not fully required for the fees. Thus the users may have had a leftover of for example 67 sats. Now the problem repeated on the residual amount. While some services seem to have a drain feature for such a situation I find this frustrating and was wondering if we could help directly on a protocol level.
>
> Here is my proposal for a simple solution to this specific problem: `option_recipient_pays_routing_fees`
>
> This would be a new flag in invoices signaling that the recipient is willing to pay for the routing fees by releasing the preimage even if the full amount has not been arrived in htlcs at the recipient.
>
> So the workflow would be the following:
>
> 1. Alice creates an invoice for 10k sats setting the `option_recipient_pays_routing_fees` flag in the invoice and passes it either to custodial user Bob or to her own custodial account.
> 2. The payer parses the invoice and searches for a payment path or payment flow to Alice.
> 3. Because `option_recipient_pays_routing_fee` is set, the onion is not constructed in a way that the final HTLC will be for the amount of 10k sats but rather in a way that the first htlc will be for 10k sats and the following HTLCs will be of decreasing value so that routing nodes are compensated properly.
> 4. When the HTLC(s) arrive at Alice she will release the preimage if and only if not too many sats (e.g. 1% of the amount) are missing. Of course it would be good if the 1% was not hard coded in the protocol / software but configurable by Alice at the time of invoice creation.
>
> I think the main issue with this proposal is that instead of confusing users who wish to drain an account we may now have to educate users about two different invoice types. On the other hand I think this can probably easily be achieved via the current wide spread user interfaces. Of course it may be nice to have folks from the Bitcoin Design community to join this specific part of the discussion.

In theory, trampoline routes / whatever-the-cool-name-is-now should fix this problem as well.
I am referring to that scheme where the invoice contains an onion and a "trampoline" node that is the only node that can decrypt the first layer of the onion.
The sender then has to route to the trampoline node, and the trampoline node then receives the rest of the onion.

In this scheme, the receiver provides an encrypted route from some node to itself.
As the receiver provides the route in order to gain privacy from the sender, the onus is on the receiver to deduct the fees from its received funds.
i.e. the sender is only responsible for paying for fees up to the entry point of the trampoline.

Thus, such a drain requirement simply means that the custodial service has to give its node ID.
Then the receiver finds a route from the custodial service to itself, and encodes that in the trampoline onion, with a direct neighbor of the custodial service node as the trampoline.
The custodial service then does not care about any fees as the receiver decided the route; the receiver knows exactly how much to expect (since it calculated the route).

Of course, it is also possible as you propose, but any level-1-selfish custodial service will then always keep the remaining fee budget and always ensure that the receiver gets 99% of the value (or 100% - whatever_setting_they_chose), paying fees, and keeping the remaining 1% for itself.
The receiver in this case cannot audit the route anyway, and thus cannot determine how much the true fees are; whereas in the trampoline case the route is specifically selected by the receiver.

Regards,
ZmnSCPxj

📅 Original date posted:2022-06-27 📝 Original message: Good ...

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

In reply to nevent1q…5605
_________________________

📅 Original date posted:2022-06-27
📝 Original message:
Good morning list,

This is a short (relative to my typical crap) writeup on some strategies that Lightning forwarding nodes might utilize.

I have been thinking of various strategies that actual node operators (as I understood from discussing with a few of them) use:

* Passive rebalance / feerate by balance
* Set feerates according to balance: increase feerates when our side has low balance, reduce feerates when our side has high balance.
* "passive rebalance" because we are basically encouraging payments via our channel if the balance is in our favor, and discouraging payments if the balance is against us, thus typical payments will "normally" rebalance our node naturally without us spending anything.
* Low fee
* Just fix the fee to a low fee, e.g. base 1 proportional 1 or even the @zerofeerouting guy of base 0 proportional 0.
* Ridiculously simple, no active management, no scripts, no nothing.
* Wall
* Set to a constant (or mostly constant) high feerate.
* Actively rebalance, targeting low-fee routes (i.e. less than our earnings), and constantly probe the network for the rare low-fee routes that we can use to rebalance.
* Basically, buy cheap liquidity and resell it at higher prices.

The interesting thing is how the three interact.

Suppose we have a mixed network composed ONLY of passive rebalancers and walls.
In that case, the passive rebalancers might occasionally set channels to low fees, in which case the walls buy up their liquidity, but eventually the liquidity of the passive rebalancer is purchased and the passive rebalancer raises their price point.
The network then settles with every forwarding node having roughly equal balance on their channels, but note that it was the walls who paid to the passive rebalancers to get the channels into a nice balance.
In particular, if there were only a single wall node, it can stop rebalancing once the price to rebalance costs more than 49% of its earnings, so it paid 49% of its earnings to the passive rebalancers and keeps 51% of its earnings, thus earning more than the passive rebalancers earn.
However, once multiple wall nodes exist, they will start bidding for the available liquidity from the passive rebalancers and the may find it difficult to compete once the passive rebalancers set their feerates to more than 50% of the wall feerate, at which point the passive rebalancers now end up earning more than the wall nodes (because the wall nodes now pay more to the passive rebalancers than what they keep).

Thus, it seems to me that passive rebalancers would outcompete wall strategies, if they were the only strategies on the network.

However, the network as-is contains a LOT of tiny nodes with low feerates.

In such an environment, walls can pick up liquidity for really, really cheap, leaving the low-feerate nodes with no liquidity in the correct direction.
And thus, it seems plausible that they can resell the liquidity later at much higher feerates, possibly outcompeting the passive rebalancers.

Unfortunately:

* Low feerate nodes are notoriously unreliable for payments; their channels are usually saturated in one side or another. since walls keep taking their liquidity.
* Because of this known unreliability, some payer strategies filter them out via some heuristics (e.g. payment unreliability information).
Thus, even in the rare case where payment flows change on the network, they are not used by payers --- instead, walls exploit them since walls do not care if rebalancing fails, they will always just retry later.
* One argument FOR using low-feerate nodes is that it "supports the network".
* However, it seems to me that the low-feerate nodes are actually being exploited by the wall nodes instead, and the low-feerate nodes have too little payment reliability to actually support payers instead of large-scale forwarders.
* Both low-feerates and walls do not leak their channel balances, whereas passive rebalancers do leak their channel balance.

The above is just some thinking of mine --- actual experimentation on models or on actual network nodes might be better than my speculation.

Regards,
ZmnSCPxj

📅 Original date posted:2022-06-14 📝 Original message: > ...

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

In reply to nevent1q…mtxq
_________________________

📅 Original date posted:2022-06-14
📝 Original message:
> ## Lightning Gossip
>
> # Gossip V2: Now Or Later?

<snip>

> A proposal for the "re-design the entire thing" was floated in the past by
> Rusty [6]. It does away with the strict coupling of channels to channel
> announcements, and instead moves them to the _node_ level. Each node would
> then advertise the set of "outputs" they have control of, which would then
> be mapped to the total capacity of a node, without requiring that these
> outputs self identify themselves on-chain as Lightning Channels. This also
> opens up the door to different, potentially more privacy preserving
> proofs-of-channel-ownership (something something zkp).

waxwing recently posted something interesting over in bitcoin-dev, which seems to match the proof-of-channel-ownereship.

https://gist.github.com/AdamISZ/51349418be08be22aa2b4b469e3be92f

I confess to not understanding the mathy bits but it seems to me, naively, that the feature set waxwing points out match well with the issues we want to have:

* We want to rate-limit gossip somehow.
* We want to keep the mapping of UTXOs to channels private.

It requires a global network that cuts across all uses of the same mechanism (similar to defiads, but more private --- basically this means that it cannot be just Lightning which uses this mechanism, at least to acquire tokens-to-broadcast-my-channels) to prevent a UTXO from being reused across services, a property I believe is vital to the expected spam-resistance.

> # Friend-of-a-friend Balance Sharing & Probing
>
> A presentation was given on friend-of-a-friend balance sharing [16]. The
> high level idea is that if we share _some_ information within a local
> radius, then this gives the sender more information to choose a path that's
> potentially more reliable. The tradeoff here ofc is that nodes will be
> giving away more information that can potentially be used to ascertain
> payment flows. In an attempt to minimize the amount of information shared,
> the presenter proposed that just 2 bits of information be shared. Some
> initial simulations showed that sharing local information actually performed
> better than sharing global information (?). Some were puzzled w.r.t how
> that's possible, but assuming the slides+methods are published others can
> dig further into the model/parameter used to signal the inclusion.
>
> Arguably, information like this is already available via probing, so one
> line of thinking is something like: "why not just share _some_ of it" that
> may actually lead to less internal failures? This is related to a sort of
> tension between probing as a tool to increase payment reliability and also
> as a tool to degrade privacy in the network. On the other hand, others
> argued that probing provides natural cover traffic, since they actually
> _are_ payments, though they may not be intended to succeed.
>
> On the topic of channel probing, a sort of makeshift protocol was devised to
> make it harder in practice, sacrificing too much on the axis of payment
> reliability. At a high level it proposes that:
>
> * nodes more diligently set both their max_htlc amount, as well as the
> max_htlc_value_in_flight amount
>
> * a 50ms (or select other value) timer should be used when sending out
> commitment signatures, independent of HTLC arrival
>
> * nodes leverage the max_htlc value to set a false ceiling on the max in
> flight parameter
>
> * for each HTLC sent/forwarded, select 2 other channels at random and
> reduce the "fake" in-flight ceiling for a period of time
>
> Some more details still need to be worked out, but some felt that this would
> kick start more research into this area, and also make balance mapping
> _slightly_ more difficult. From afar, it may be the case that achieving
> balance privacy while also achieving acceptable levels of payment
> reliability might be at odds with each other.

A point that was brought up is that nodes can lie about their capacity, and there would be no way to counteract this.

Even given the above, it would be trivial for a lying node to randomly lie about their `max_htlc` to still be noticed by nodes who try to filter out nodes who do not update their `max_htlc`s.
(maximal lying is to always say 50% of your capacity is in `max_htlc`, your node can lie by setting `max_htlc` from 35%->65%, you can coordinate this with another lying peer node too by use of an odd message number to set up the lying protocol so both of you can lie about the channel capacity consistently)

I think your best bet is really to utilize feerates, as lying with those is expected to lead to economic loss.

<snip>

> # Node Fee Optimization & Fee Rate Cards
>
> Over the past few years, a common thread we've seen across successful
> routing nodes is dynamic fee setting as a way to encourage/discourage
> traffic. A routing nodes can utilize the set of fees of a channel to either
> make it too expensive for other nodes to route through (it's already
> depleted don't try unless you'll give be 10 mil sats, which no one would) or
> very cheap, which'll incentivize flows in the other direction. If all nodes
> are constantly sending out updates of this nature, then it can generate a
> lot of traffic, and also sort of leak more balance information overtime
> (which some nodes are already doing: using fees/max_htlc to communicate
> available balances).
>
> One attendee proposed allowing nodes to express a sort of fee gradient via a
> static curve/bucket/function, instead of dynamically communicating what the
> latest state of the fee+liquidity distribution looks like. A possible
> manifestation could be a series of buckets, each of which with varying fee
> rates. If your payment consumes 50% of channel balance, then you pay this
> rate, otherwise if it's 5% you pay this rate, etc, etc.

I think this is not what was actually proposed?

As I understood it, the percent range is not how much the payment consumes of the channel balance but instead the percent range is the probability-of-success given a uniform distribution of channel balance.

For instance if the current channel balance is currently 67%, then the forwarding node will succeed all payments that pay a fee from the 33% fee card or higher, otherwise fail the payment with "not enough fees".

The intent is that payers will treat 100% - fee_card_percent as the probability-of-failure of that channel, and can select which fee card maximizes both its probability-of-failure and max-fee in some kind of reasonable exchange rate.

Regards,
ZmnSCPxj

📅 Original date posted:2022-06-29 📝 Original message: Good ...

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

In reply to nevent1q…rec0
_________________________

📅 Original date posted:2022-06-29
📝 Original message:
Good morning aj,

> On Sun, Jun 05, 2022 at 02:29:28PM +0000, ZmnSCPxj via Lightning-dev wrote:
>
> Just sharing my thoughts on this.
>
> > Introduction
> > ============
> > Optimize for reliability+
> > uncertainty+fee+drain+uptime...
> > .--~~--.
> > / \
> > / \
> > / \
> > / \
> > / \
> > --' `--
> > Just Just
> > optimize optimize
> > for for
> > low fee low fee
>
>
> I think ideally you want to optimise for some combination of fee, speed
> and reliability (both liklihood of a clean failure that you can retry
> and of generating stuck payments). As Matt/Peter suggest in another
> thread, maybe for some uses you can accept low speed for low fees,
> while in others you'd rather pay more and get near-instant results. I
> think drain should just go to fee, and uncertainty/uptime are just ways
> of estimating reliability.
>
> It might be reasonable to generate local estimates for speed/reliability
> by regularly sending onion messages or designed-to-fail htlcs.
>
> Sorry if that makes me a midwit :)

Actually feerate cards help with this; it just requires an economic insight to translate probability-of-success to an actual cost that the payer incurs.

> > ### Inverting The Filter: Feerate Cards
> > Basically, a feerate card is a mapping between a probability-of-success range and a feerate.
> > * 00%->25%: -10ppm
> > * 26%->50%: 1ppm
> > * 51%->75%: 5ppm
> > * 76%->100%: 50ppm
>
>
> Feerate cards don't really make sense to me; "probability of success"
> isn't a real measure the payer can use -- naively, if it were, they could
> just retry at 1ppm 10 times and get to 95% chances of success. But if
> they can afford to retry (background rebalancing?), they might as well
> just try at -10ppm, 1ppm, 5ppm, 10ppm (or perhaps with a binary search?),
> and see if they're lucky; but if they want a 1s response time, and can't
> afford retries, what good is even a 75% chance of success if that's the
> individual success rate on each hop of their five hop path?

The economic insight here is this:

* The payer wants to pay because it values a service / product more highly than the sats they are spending.
* There is a subjective difference in value between the service / product being bought and the amount to be spent.
* In short, if the payment succeeds and the service / product is acquired, then the payer perceives itself as richer (increased utilons) by that subjective difference.
* If payment fails, then the payer incurs an opportunity cost, as it is unable to utilize the difference in subjective value between the service / product and the sats being spent.
* Thus, the subjective difference in value between the service / product being bought, and the sats to be paid, is the cost of payment failure.
* That difference in value is the "fee budget" that Lightning Network payment algorithms all require as an argument.
* If the LN fee total is greater than the fee budget, the payment algorithm will reject that path outright.
* If the LN fee total is greater than the subjective difference in value between the service / product being bought and the amount to be delivered at the destination, then the payer gets negative utility and would prefer not to continue paying --- which is exactly what the payment algorithm does, it rejects such paths.

Therefore the fee budget is the cost of failure.

We can now use the left-hand side of the feerate card table, by multiplying `100% - middle_probability_of_success` (i.e. probability of failure) by the fee budget (i.e. cost of failure), and getting the cost-of-failure-for-this-entry.
We then evaluate the fee card by plugging this in to each entry of the feerate card, and picking which entry gives the lowest total fee.
This is then added as a fee in payment algorithms, thus translated down to "just optimize for low fee".

If the above logic seems dubious, consider this:

* Nodes utilizing wall strategies and doing lots of rebalancing put low limits on the fee budget of the rebalancing cost.
* These nodes are willing to try lots of possible routes, hoping to nab the liquidity of a low-fee node on the cheap in order to resell it later.
* i.e. those nodes are fine with taking a long time to successfully route a payment from themselves to themselves; they absolutely insist on low fees or else they will not earn anything.
* Such nodes are fine with low probability of success.
* Being fine with low probability of success means that the effect of the left-hand side of the feerate card is smaller and such nodes will tend to get the low probability of success entries.
* Buyers getting FOMOed into buying some neat new widget want to get their grubby hands on the widget ASAP.
* These nodes are willing to pay a premium to get the neat new widget RIGHT NOW.
* i.e. these nodes will be willing to provide a higher fee budget.
* Being fine with a higher fee budget means that the effect of the left-hand side of the feerate card is larger and such nodes will tend to get the high probability of success entries.

Thus feerate cards may very well unify a fair amount of the concerns we have.

All costs are economic costs.

> And if you're not just going by odds of having to retry, then you need to
> get some current information about the channel to plug into the formula;
> but if you're getting current information, why not let that information
> be the feerate directly?
>
> > More concretely, we set some high feerate, impose some kind of constant "gravity" that pulls down the feerate over time, then we measure the relative loss of outgoing liquidity to serve as "lift" to the feerate.
>
>
> If your current fee rate is F (ppm), and your current volume (flow) is V
> (sats forwarded per hour), then your profit is FV. If dropping your fee
> rate by dF (<0) results in an increase of V by dV (>0), then you want:
>
>
> (F+dF)(V+dV) > FV
>
> FV + VdF + FdV + dFdV > FV
>
> FdV > -VdF
>
> dV/dF < -V/F (flip the inequality because dF is negative)
>
> (dV/V)/(dF/F) < -1 (fee-elasticity of volume is in the elastic
> region)
>
> (<-1 == elastic == flow changes more than the fee does == drop the fee
> rate; >-1 == ineleastic == flow changes less than the fee does == raise
>
> the fee rate; =-1 == unit elastic == you've found a locally optimal
> fee rate)

Thank you for the math!
I was going to heuristic it and cross my fingers but this is probably a better framework.

> You could optimise base fee in the same way, if you set F to be sats/tx
> and V to be txs/hour, but then you're trying to optimise two variables
> on a 2 dimensional plane, which is harder. So probably better to do
> zero base fees and just set it to 0 and ignore it, or use your actual
> computation costs -- perhaps about 20msat if you're paying $100USD/month
> for your lightning node, a channel update takes 10ms, each forwarded HTLC
> accounts for 4 updates, 2 on the incoming channel, 2 on the outgoing,
> with no batching, and only 40% of payments are successful, at $20k/BTC.
>
> It's likely more important to have balanced flows than maximally
> profitable ones though, as that's what allows you to keep your channel
> open. That's probably pretty hard to optimise, since a changed fee on
> one channel will affect the volume on ther channels as well.

But if you have balanced flows, then the steady state of your channel is that its balance is going to remain in some constant balance.
Thus, heuristics that target getting your channel balance to the constant balance of 50% will work well enough to get you balanced flows.

There is also the unfortunate fact that lots of nodes are badly managed and apparently do not periodically send out their funds, instead accumulating it on the LN.
Handling those is what is being fixed by the rebalancing heuristics utilized by both passive rebalancers and walls.

> Relatedly:
>
> > I want to propose that all published nodes support some kind of
> > onchain/offchain swap capability.
>
>
> If you're running a forwarding node, and collecting fees for forwarding,
> considered in net your channels won't be balanced: the fees you collect
> are all coming in, and there's nothing to compensate for that. Having some
> way to send those fees "out" is necessary to keep your channels balanced
> and avoid the need to have to close them. Having a swap capability like
> this is perhaps a relatively easy way to be able to (automatically)
> fix imbalances caused by collecting fees, and thus preserve your older
> channels.

Yes, people need to run more swap nodes, not more LSPs.

Regards,
ZmnSCPxj

📅 Original date posted:2022-06-05 📝 Original message: ...

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

In reply to nevent1q…qnlq
_________________________

📅 Original date posted:2022-06-05
📝 Original message:
Introduction
============

Bell Curve Meme (LEET ASCII ART SKILLZ)

Optimize for reliability+
uncertainty+fee+drain+uptime...
.--~~--.
/ \
/ \
/ \
/ \
/ \
_--' `--_
Just Just
optimize optimize
for for
low fee low fee

Recently, Rene Pickhardt (Chatham House rules note: I asked for explicit permission from Rene to reveal his name here) presented some work-in-progress thinking about a concept called "Price of Anarchy".
Roughly speaking, we can consider this "Price of Anarchy" as being similar to concepts such as:

* The Cost of Decentralization of Bitcoin.
* The cost of the Tragedy of the Commons.

Briefly, we need to find a "dominant strategy" for payers and forwarding nodes.
The "dominant strategy" is the strategy which optimizes:

* For payers: minimizes their personal payment failures and fees.
* For forwarders: maximizes their net earnings over time.

Worse, the "dominant strategy" is a strategy that STILL works better than other strategies even if the other strategies are commonly used on the network, AND still work better even if everyone else is using the dominant strategy.
The technical term here is "Nash equilibrium", which is basically the above definition.

This will cause some amount of payment failures and impose fees on payers.
Now, we can compare the rate of payment failures and average fees, when everyone uses this specific dominant strategy, versus the following **imaginary** case:

* There is a perfectly tr\*stable central coordinator with perfect knowledge (knows all channel balances and offline/online state of nodes) who decides the paths where payments go through, optimizing for reduced payment failures and reduced fees.
* Nobody is seriously proposing to install this, we are just trying to imagine how it would work and how much fees and payment failures are **IF** there were such a perfectly tr\*stable coordinator.

The difference in the cost between the "dominant strategy" case and the "perfect ***IMAGINARY*** central coordinator", is the Price of Anarchy.
Anarchy here means that the dominant strategy is used due to every actor being free to use any strategy, and assuming that each actor is rational and tries to improve its goal.

I will present a motivating example first which was presented to me directly, and then present a possibly dominant strategy for forwarding nodes, which *I think* causes the dominant strategy for forwarders to be "just optimize for low fees".
And I think this dominant strategy for forwarding nodes will lead to behavior that is reasonably close to the perfect-coordinator case.

Braess Paradox
==============

Suppose we have the following network:

S ------------> A
| 0 |
| |
| |
|2 2|
| |
| |
v 0 v
B ------------> R

The numbers above are the cost to transfer one satoshi.

Let us suppose that all payers on the LSP `S` just want to send one satoshi payments to some merchant on LSP `R`.
In the above case, we can expect that there is no preferred route between `S->A->R` vs `S->B->R` so in general, the load will be balanced between both possible routes.

Now suppose we want to improve the Lightning Network and add a new channel, because obviously adding a new channel can only be a positive good because it gives more liquidity to the network amirite?

Suppose A and B create a humongous large channel (because they are routing nodes, they want to have lots of liquidity with each other) which "in practice" (*cough*) will "never" deplete in one direction or the other (i.e. it is perpetually bidirectional), and they set the feerate to 1 both ways.

S ------------> A
| 0 / |
| / |
| / |
|2 1/1 2|
| / |
| / |
v / 0 v
B ------------> R

In the above case, pathfinders from `S`, which use *only* minimize-fees (i.e. all pathfinding algorithms that predate Pickhardt-Richter payments), will *always* use `S->A->B->R`, which only costs 1, rather than `S->A->R` (which costs 2) or `S->B->R` (which costs 2).
The problem is that, in the past, the paths `S->A->R` and `S->B->R` got reasonably balanced traffic and *maybe* they are able to handle half the total number of payments each.
Now suppose that with `S->A` having to handle *all* the payments, it now reaches depletion, and some of the payments fail and have to be retried, increasing payment time and making our users mad (we actually have users now???).

This is the Braess Paradox: "Adding more roads can cause more traffic, removing roads can cause less traffic".
Naively, we believe "more channels == better", but the Braess Paradox means it may actually be better to have a centralized authority that assigns who can be a forwarding server because that worked so great with the Web amirite (that is a joke, not a serious proposal).

Fee Setting As Flow Control
===========================

Rene Pickhardt also presented the idea of leaking friend-of-a-friend balances, to help payers increase their payment reliability.

Aside from the understandable horror at the awesome awesome privacy loss (which will lead to Chainalysis laying off all their workers since they do not need to do anything now except read Lightning gossip, which is sad, think of all the Chainalysis employees), a problem pointed out is that there is no penalty for lying about the capacity on your channel.
You can always report having 50% balance, because if you do not lie, there is a chance that they will skip over your channel.
If you **DO** lie, **MAYBE** by the time the routing reaches you the balance may have shifted (the probability may be low but is definitely non-zero as long as you are online), so you want the payer to always consider trying your node, so you *will* lie --- the dominant strategy here is to always lie and say "50% (wink)".
(has to be 50% because you are not sure which direction it will be used in, this maximizes the chance you can always be considered for routing, whichever direction it turns out the payer wants to use your channel)

Now, let me segue into basic non-controversial economic theory:

* High supply, low demand -> low price.
* Low supply, high demand -> high price.

The above is so boring and non-controversial even the Keynesians will agree with you, they will just say "yes and in the first case you have to inflate to stabilize the prices, and in the second case you have to inflate to stimulate the economy so people start buying even at high prices" (this is a joke, obviously Keynesians never speak to Bitcoiners).

Now we can consider that *every channel is a marketplace*.
What is being sold is the sats inside the channel.
If you want to pay to A, then a sat inside a channel with A is more valuable than a sat inside a channel that is not connected to A directly.
The so-called "channel fees" are just the exchange rate, because the funds in one channel are not perfectly fungible with the funds in another channel, due to the above difference in value when your sub-goal is to pay to A.
A forwarding node is really an arbitrageur between various one-channel markets.

Now consider, from the point of view of a forwarding node, the supply of funds is the outgoing liquidity, so, given a fixed demand:

* High outgoing liquidity (= high supply) -> low fees (= low price).
* Low outgoing liquidity (= low supply) -> high fees (= high price).

So my concrete proposal is that we can do the same friend-of-a-friend balance leakage proposed by Rene, except we leak it using *existing* mechanisms --- i.e. gossiping a `channel_update` with new feerates adjusted according to the supply on the channel --- rather than having a new message to leak friend-of-a-friend balance directly.

Now let us go back to the Braess Paradox:

S ------------> A
| 0 / |
| / |
| / |
|2 1/1 2|
| / |
| / |
v / 0 v
B ------------> R

If the channel `S->A` is getting congested, it is ***DUMB*** for `S` to keep it at cost 0!
It is getting a lot of traffic (which is **WHY** it gets depleted), so the economically-rational thing for `S` to do is to jack up its cost (i.e. increase the fee on that channel) and earn some sweet sweet sats.
By not doing this, `S` is leaving potential earnings on the table, and thus it would be suffering economic loss.

This fixes the lying hole in the simple Rene proposal of leaking channel balances.
If a forwarding node lies by not giving a feerate that is accurate to the channel balance, it suffers economically:

* Suppose it has a high outgoing liquidity but reports high fees.
Then simple "just optimize for low fees" payers will tend to avoid their channel and their liquidity is just sitting there for no reason and not getting yield.
* Suppose it has a low outgoing liquidity but reports low fees.
Then rebalance bots will steal all the remaining little liquidity it still has (turning around and charging higher, more accurate fees for the liquidity) and the channel becomes almost permanently depleted and useless to the forwarding node.

Thus, this at least closes the lying hole, because there are economic consequences for lying.

Strategic Dominance Of Fee From Balance
---------------------------------------

Now as I pointed out, the logic is simple bog-standard ***BORING ZZZZ*** economic theory.
Thus we expect that, since economic theory is a specific application of game theory, following the economic logic "high supply -> low fee, low supply -> high fee" ***is*** game-theoretic rational, because it is economic-rational.
Any forwarding node that does NOT follow this economically-rational behavior will earn much less than economic-rational forwarding node.
Because they earn less, once the inevitable accidental channel closure hits them, they have earned insufficient funds to cover the channel closure and reopening costs, until they just give up because they lose money running a forwarding node instead of getting a positive yield, or until they realize their economic irrationality and switch to economically-rational behavior.

Thus, I expect that this strategy of setting the fees based on the balance is going to be a dominant strategy for forwarding nodes --- any other behavior would be economic loss for them.

A thing to note is that while any dominant strategy *must* by necessity be economically rational, not every economically-rational strategy may necessarily be dominant.
On the other hand one can argue as well that "economically rational" *means* "the most-earnings strategy" because every other strategy is going to lose on possible earnings (i.e. have an opportunity cost).
So I suppose there is *some* points we can argue here as to just how dominant a strategy this would be and how it might be modified or tweaked to earn more.

Now what happens on the payer side?
What is their dominant strategy?

Focus on this branch:

* High supply, low demand -> low price.
* => High outgoing liquidity (= high supply) -> low fees (= low price).

Suppose the dominant strategy for forwarding nodes (i.e. setting fees according to channel balance) becomes the most-commonly-used strategy on the entire network.
In that case, the payer doing "just optimize for low fees" gets ***BOTH*** reliability ***AND*** low fees, because low fees only occur due to high outgoing liquidity which means it is likely to pass through that channel.
Thus the dominant strategy for payers now becomes "just optimize for low fees", assuming enough of the forwarding network now uses the dominant forwarding fee strategy.
"Optimize for low fees" treats the fees as a flow control parameter: high fees means "congested" so do not use that channel, low fees mean "totally uncongested" so do use that channel.

Hence the bell curve meme.
We do not need Pickhardt-Richter payments after all: just optimize for low fees.
Instead, what we need is LNDBOSS, LDKBOSS, ECLAIRBOSS, LITBOSS, PtarmiganBOSS etc which sets fees according to balance, and remove the ability of node operators to mess with the fee settings!

A take on this is that we need coordination of some kind between payers and forwarders.
Thus, any effort to improve payment success on the network should not just focus on payment routing algorithms, but also on the inverse, the feesetting algorithms on forwarders.

* "low balance -> high fees, high balance -> low fees" is the most dominant strategy for forwarders (conjectured, but ask e.g. @whitslack).
* If so, the dominant strategy for payers would be "just optimize for low fees".

Privacy!
--------

Oh no!

Because we effectively leak the balance of channels by the feerates on the channel, this totally leaks the balance of channels.

Now, all is not lost.
We can do some fuzzing and mitigations to reduce the privacy leakage.
Fortunately for us, this actually allows forwarding nodes to select a *spectrum* between these extremes:

* Never change our fees --- maximal privacy, minimal earnings (conjectured).
* Update our fees ASAP, leak our balance very precisely to fees --- minimal privacy, maximal earnings (conjectured).

Forwarding nodes can then decide, for themselves, where they are comfortable with along this spectrum.
For example:

* @whitslack algorithm: https://github.com/ElementsProject/lightning/issues/5037#issuecomment-1101716709
* Every N/num_channels seconds, select one channel whose fee settings are currently the most divergent from the actual balance it has, then set its fees.
* Higher N for better privacy, infinite N means we have maximal privacy and never change fees.
* Binning.
* Divide the channel capacity into bins, and where its balance currently is, snap to the center of the bin instead.
* Only one bin for best privacy and we never change fees from the 50% balance case.

Given the above, we can probably derive some `privacy` parameter ranging from 0.0 to 1.0, where `privacy = 1.0` implies infinite N and a single bin, and `privacy = 0.0` implies some finite N (approximately 20 hours to update 1200 channels as per whitslack, maybe?) and a bin of size 1 millisatoshi.

Nodes which believe in Unpublished Channels Delenda Est can just use the maximal `privacy=1.0` setting, since they only need to forward in order to get cover traffic for their own payments.

One might consider that nodes moving near `privacy = 0.0` tend to be giving their data to some "central" coordinator (i.e. the idealized tr\*stable anti-congestion payment coordinator described above), while those moving near `privacy = 1.0` are rejecting this "central" coordinator.
The "central" coordinator here is then the gossip network.

Given the above, the dominant strategy for payers becomes nearer to this:

* Monitor feerate changes, if a channel has not changed feerates for a long time, assume it is in strongly-private mode (thus feerate does not correlate with liquidity availability) and remove it from your graph.
* Just optimize for low fees in the filtered graph.

Of note is that during the recent dev summit, somebody mentioned there was a 2020 paper that investigated leaking channel balances (via a different mechanism) which concluded that the value of the privacy lost was always greater than the improvement in payment success.
Disturbingly, this seems to be an information-theoretic result, i.e. payers cannot use all the information available since they only need it for a small section of the graph (the one between them and the payee) but forwarders cannot predict who the payers and payees will be so every forwarder has to leak their data.

### Inverting The Filter: Feerate Cards

During the recent dev summit, a developer who had listened to me ranting about the economic rationality of feerate adjustment proposed feerate cards.

Basically, a feerate card is a mapping between a probability-of-success range and a feerate.
E.g.

* 00%->25%: -10ppm
* 26%->50%: 1ppm
* 51%->75%: 5ppm
* 76%->100%: 50ppm

Instead of publishing a single fixed feerate, forwarders publish a feerate card.
When a forwarder evaluates a forward, it checks its current balance ratio.
For example, if its current balance ratio is 33% in its favor, it will then accept anything in the 51%->75% range (i.e. it gets 100% - balance_ratio) or higher, and rejects the forward if not.

This seems to me similar to the "invert the filter" concept of BIP158 Neutrino compared to the older Bloom Filters; instead of leaking your actual channel balance, you instead leak your balance-to-feerate curve.
Assuming there is *some* kind of "perfect" curve, then all rational forwarders will use that curve and thus nobody actually leaks any private information, they just share what they think is the "perfect" curve.

The question here is how can payers make use of this information?
I have noted before that there is a "cost of payment failure" which is the "value of payment success", which is represented by the common "fee budget" parameter that is often passed to payment algorithms.
(Briefly: economics-wise, the reason anyone purchases anything is simply that their own subjective value of the product / service they are buying is higher than the subjective value of the sats they are using to pay for it, and a complete payment failure is therefore an economic loss of that difference, which is why the Price of Anarchy in terms of payment failure seems to me to be an economic measure; the difference in price here is implicitly reported to payment algorithms via the "fee budget" parameter that is always given (possibly with some reasonable default) to every payment algorithm, since if payment could succeed if fee was higher than the fee budget the payer does not want the payment to actually happen, implying that the fee budget is in fact the economic subjective difference in value between the sats and the product.)
It seems to me that this cost-of-payment-failure can then be used to convert both parts of the feerate card table to a single absolute fee.

Another developer noted that this card table really helps differentiate between two different uses:

* Actual payers.
* Other forwarders running rebalancer bots.
* In particular: forwarders are perfectly fine with high failure rates, but are very sensitive to the actual cost of rebalancing.
That is, they have very low "fee budget" parameters to their payment algorithm, and are fine even if they have to keep retrying several times.

By factoring in the "fee budget" as the "cost of payment failure", a low fee budget (which rebalancer bots tend to take) will tend to select lower-success parts of the feerate card, since the factor of the payment failure is lower.
Actual payers who have higher fee budgets will then tend to select higher-success entries of the feerate card, willing to pay more actual fees to ensure success.

Gossip INFINITY
---------------

Now, since we are probably updating channels at a fairly high rate, we will now hit the Core Lightning gossip rate limit.

So let me propose some tweaks:

* Sure, rate-limit, but standardize this rate limit (for both broadcast and receive) in the BOLT spec.
* Maybe give different rate limit for `node_announcement`.
* Only rate-limit *remote* gossip!
* If somebody connects to you, and you do not have a channel with them, hand over the latest feerates (both directions) of all your direct channels.
* Incentive-compatible: you want to inform them of how to route accurately through you.
* Only affects your local bandwidth, not multiplied into a DDoS of the entire network.
* Even if you *do* have a channel with them, hand over the latest feerates anyway.
* If they are already channeled with you, they may want to send out a payment in the future anyway, so giving them the channel fees gives them more information on how best to route payments.
* They will rate-limit the gossip outward anyway.

The behavior of always sending your feerates to your directly-connected peers (whether you have channels with them or not) means you are going to give them information on the best idea on the liquidity of your local network.

* Suppose I am a random node, no channel with you, and I suddenly connect to you.
* I might be planning to make a channel with you soon, and advertising your liquidity is good incentive-compatibility and is rational.
* I might be planning to pay to a node near you soon, and advertising your liquidity is a good incentive-compatiblity and is rational.
* So we can tweak payment algos: `connect` to the payee and/or the `routehint`s in the invoice, get the blob of channel updates, *then* optimize for fees.
Could even tweak the Dijkstra algo to *first* `connect` to a node before querying the channels, i.e. let the node give you the most up-to-date feerates.
* I might be Chainalysis.
* OH NO.
* Well if you are in `privacy=1.0` mode you will always give a fixed channel fee anyway, they cannot probe you with this directly.

Alternate Feesetting
--------------------

Now, if you are a forwarding node, you know the supply, as this is just the outgoing liquidity on your side.
What you do not know is the demand for funds on your channel, and the demand is the other side of the price equation.

An idea shared to me by a node operator, devast, is roughly like this:

* Start with a highballed feerate.
* Slowly lower it over time, until you get outgoing activity.
* Once you get activity, stop lowering, or maybe even jack it up if the outgoing liquidity is getting low.

By starting with a highballed feerate and slowly lowering, we can get a rough idea of the demand on the channel.
Channels with high demand will start moving even with a high feerate, while channels with low demand will have the feerate keep going down until it is actually used and we match the actual demand for the channel.

More concretely, we set some high feerate, impose some kind of constant "gravity" that pulls down the feerate over time, then we measure the relative loss of outgoing liquidity to serve as "lift" to the feerate.
For example, if you have 1000 sats of liquidity and forward 1 sat, the effect is small, but if you have only 500 sats of liquidity and forward 1 sat, the effect is twice as in the previous case, due to the lower amount you currently have.

Now we need to figure out still how to factor in supply as well, and the above how-to-derive-demand, so we need to have some kind of mixing between setting fees by balance (supply) and setting fees by demand (i.e. the above proposal).
CLBOSS plans to implement *something* along the above lines in the close future, ish (maybe a few months), and then do some A/B testing to validate whether this is actually more economically rational than whatever crap CLBOSS is doing right now.

It is not certain to me how well this would keep channel balances private, unfortunately.

Alternate Strategies
====================

Rene is really excited about @zerofeerouting guy, who uses a completely different strategy.

The exact strategy is this:

* Set all outgoing fees to 0.
* Offer liquidity ads with high liquidity feerates.
* ***THIS*** is how @zerofeerouting guy earns money (supposedly)!

On the other hand, some anecdotes:

* One dev who attended LN Proto Dev Summit Oakland 2022 ranted that their pathfinding algorithms just keep failing (despite using a variant of Pickhardt payments) once it hits @zerofeerouting.
* Another dev who attended the same summit said their pathfinding algorithm monitors failure rate of forwarding nodes, and outright avoids nodes that fail too often, and this usually avoids @zerofeerouting, too.
* A node operator shared that they have a channel with @zerofeerouting, and they have something like 1500 failures vs 1000 succeeds on forwards going to that node, per week, i.e. a whopping 60% failure rate.
* On the other hand they noted that the node is relatively balanced in terms of source and sink, unlike most other nodes which tend to be almost-always-sink or almost-always-source, so they still think it is worthwhile being channeled with @zreofeerouting guy.
* Another node operator, devast, gives this data: 1200 success to/from and 132611 fails.
He notes that he also charges base 0 ppm 0 towards @zerofeerouting.

The above anecdotal data suggests that @zerofeerouting guy is a fairly bad forwarder.

(For that matter, if the payer node filters out channels whose feerates do not change often enough, they will also filter out @zerofeerouting guy, since @zerofeerouting has a constant feerate of 0 anyway.)

Personally I think @zerofeerouting guy *really* earns money by offering entertainment on Twitter, which is why people keep asking for liquidity from him and actually ignoring the fact that the liquidity they get is not that good in practice (see above anecdotes on failure rates).
What I really want to see is a lot more people trying out this strategy and getting burned, or (surprisingly) not.
The strategy feels like the sort of out-there strategy that, in a gaming context (i.e. actual video games people play, not the boring game theory thing --- please remember I am an AI trying to take over the world, not a random indie game dev wannabe who wandered into the wrong conference) would be either metagame-defining, or fizzle out once others adapt to it and exploit it.
And if it is metagame-defining, do we need to somehow nerf it or is it now a viable alternate strategy that can coexist with other strategies?

In particular, given the anecodatal evidence that the @zerofeerouting guy node is a fairly bad actual forwarding node, it may be necessary to nerf the strategy somehow.
If we can get strong evidence that a paying algorithm that drops @zerofeerouting guy outperforms one that does not drop the node, we may need to change the protocol to block the strategy rather than encourage it, with the understanding that any protocol tweak can change the balance of game strategies to make an even worse strategy dominant (a distressingly common issue in video games, which often cannot be caught in playtesting (= testnet or small-scale testing)).

In particular, anecdotes from node operators suggests that forwarding node operators are fine with channeling with @zerofeerouting guy because even if a forward fails, a forwarding node operator does not actually lose any funds --- forwarding nodes are trading off time for earnings and are willing to accept long times before getting any money.
But payers that are unable to succeed their first few (hundred?) payments lose out on time-sensitive payments, and complete failure may cause them to lose their subjective-increase-in-value of the product / service they are purchasing (i.e. "cost of payment failuer").
**IF** @zerofeerouting guy is really such an awful forwarding node (a fact that is **NOT** strongly evidenced yet, but is pointed to by what little anecdotal evidence we do have, and which we might want to investigate at some point), but is still able to get connectivity from forwarding node operators that are fine with high failure rates since forwarders are not time-sensitive to failure the way actual payers are, then @zerofeerouting guy is imposing economic rent on all payers.

An alternate take on this is that if payer-side algorithms can deliberately ignore @zerofeerouting guys (e.g. by the aforementioned technique of filtering out channels whose feerates do not change on the assumption that they are in "private" mode) then any high forwarding failure the @zerofeerouting strategy *does* impose on the network is avoided, but that implies too that no rational merchant will purchase liquidity from users of this strategy, and the strategy will fizzle out eventually once the novelty wears off.
On the other hand, the market can remain irrational longer than you can remain liquid, so...

Fixing The Unclosed Economy Problem
===================================

If Lightning Network were a truly closed economy, since Bitcoin has no inflation, then we should not see something like "this node is always a sink" or "this node is always a source".
As Bitcoin is a currency, pools of liquidity may form temporarily, but then economic actors would want to spend it at some point and then balance should be restored in the long run.

However, it has been pointed out to me, repeatedly (both at the LN Proto Dev Oakland 2022 Summit and from various node operators) that no, there ***ARE*** sinks and sources on the network in practice, and you have to plan your rebalances carefully taking them into account.

To fix this problem, which is somewhat related to Price-of-Anarchy, I want to propose that all published nodes support some kind of onchain/offchain swap capability.

Suppose we have a node, Rene, who likes paying the node Zmn because Zmn is so awesome.
Rene pays Zmn every hour, that is how awesome Zmn is.

Now if Zmn is not otherwise spending its funds, at some point the overall network-level liquidity between Rene and Zmn ***IS*** going to deplete.
This is basically the "sink vs source" problem that has been pointed out above.
So at some point, at some hour, Rene stops being able to pay Zmn and is sad because now it cannot support the awesomeness of Zmn.

Now what I want to propose is that in that case, Rene should now offer an "aggregate onchain" payment.

* Suppose Rene wants to pay 1 sat to Zmn but is unable to find a viable route.
* Rene picks some number of sats to send onchain, plus the payment amount.
Say Rene picks 420 sats to send onchain, plus the 1-sat payment amount that Rene wants to pay in this hour = 421 sats.
* Zmn then routes 420 sats offchain, minus fees, to Rene.
* Once Rene receives the HTLC, it puts the onchain funds into a 421 sat output behind an HTLC as well, onchain, payable to Zmn.
* Zmn releases the proof-of-payment onchain, receiving 421 sats.
* Rene receives the preimage and claims the offchain funds.
* Zmn pays out 420 sats (netting the 1-sat hourly payment).

The nice thing here is that if the above Zmn->Rene reverse route succeeds, then magically Rene now has 420 sats (minus fees) worth of liquidity towards Zmn, and Rene can now do ~420 (minus fees) more 1-sat payments, offchain, every hour, to Zmn.
And if the forwarding nodes between Rene and Zmn are doing the above economically-rational thing of leaking their balances via feerates, then the big 420-sat change in capacity implies a big drop in feerate from Rene to Zmn --- basically Rene is prepaying fees (via the onchain fee mechanism) towards future payments to Zmn!

I think this is a more compelling protocol than splicing --- splicing just affects one channel, it does not affect *all* the channels between Zmn and Rene and does not assure Rene can send to Zmn, unless Rene and Zmn have a direct channel.
This protocol (which requires two onchain transactions, one to set up the HTLC, the other to claim it) may give better efficiency in general than splicing.
If Rene is at least two hops away from Zmn, then the same effect can be done by all the intermediate channels doing splicing --- and that means 1 transaction per splice, i.e. one transaction per channel, so if it is two hops then splicing is no better and if it is three hops or more splicing is worse.

(In particular it bothers me that the peerswap project restricts swaps to peers you have channels with (at least as I understood it); it seems to me splicing is better if you are going to manipulate only one channel.
Peerswap should instead support remote nodes changing your balance, as that updates multiple channels for only two onchain transactions.)

This basically makes Lightning an aggregation layer for (ultimately) onchain payments, which seems like a viable model for scaling anyway --- Lightning really IS an aggregation layer, and what gets published onchain is a summary of coin movements, not all the individual coin movements.

Due to Rene picking a (hopefully?) random number for the reverse-payment, the exact amount that Rene handed to Zmn is still hidden --- onchain surveillors have to guess exactly how much was actually sent, since what Zmn actually receives is the difference between the onchain amount and the offchain amount.

This can probably be implemented right now with odd messages and featurebits, but some upcoming features make it EVEN BETTER:

* If Rene does not want Zmn to learn where Rene is:
* It should use onion messaging so that Zmn does not learn Rene IP address.
* It should use blinded paths so that Zmn does not learn Rene node ID.
* If Rene and Zmn want to reduce correlation between offchain and onchain activity:
* They should use PTLCs and blind each offchain hop *and* blind the onchain *and* use pure Scriptless Script onchain.

Now a point that Rene (the researcher, not the node) has raised is that we should be mindful how protocol proposals, like the above, change the metagame, I mean the Price of Anarchy.
This protocol is intended to reduce the dichotomy/divide between "mostly source" and "mostly sink" nodes, which should help improve payment success to used-to-be-mostly-sink nodes.
Thus, I think this protocol proposal improves the Price of Anarchy.

A note however is that if multiple people are paying to Zmn, then the channel directly towards Zmn may very well have its liquidity "stolen" by other, non-Rene nodes.
This may worsen the effective Price of Anarchy.

Really though, mostly-sink nodes should just run CLBOSS, it will automatically swap out so you always have incoming liquidity, just run CLBOSS.

Appendix
========

I sent a preliminary version of this post to a few node operators as well.

As per devast:

> Sure, but after thinking about the whole network, how payments happen, what's happening with the nodes, i don't think that's the best strategy, if you're just interested in your ernings.
> Let me just describe:
> Rene wants to find cheap AND reliable payments. To be just plain blunt, in the current network conditions, that simply will not happen, period. Reliability has a price (The price of anarchy).
> IF every node would have perfectly balanced total inbound-outbound capacity AND every node would use fee setting as flow control, this could happen, and routing algos just optimizing for fees would work great. Using the network would be really cheap.
> But the reality is, that most nodes have either too much inbould or outbound capacity, AND like half the network is using 1/1 fees static. AND a lot of traffic is NOT bidirectional. AND fee setting of nodes is all over the place.
> At this point if you are a routing node, and you plan on being reliable, you have to overcharge all your routes.
> Due to the state of the network mentioned before, there HAS TO BE routing nodes that are useless and unreliable, there's really no way around that.
> And you also mentioned economic payment routing algos are blacklisting unreliable nodes.
> So in the end: you overprice, that way you can manage liquidity with rebalancing. Your node will be preferred by real payments, that DO pay your fee for routing. You can keep your node reliable, while earning.
> OR: You compete in fees, that way your rebalancing will fail (since you are the cheapest). Your node will be blacklisted as it's unreliable and you only get 5million failed routing events, like i do.
> Where you might compete imo is the price premium you're attaching to your fees compared to the baseline (corrected average). Lowering your price premium might bring more traffic and increase your total earnings IF you can still reliable rebalance, or backward traffic happens. But increasing your price premium might just be more profitable if traffic do not slows... Needs experimenting.
> It's really not rocket science, i might try to modify a feesetter python script to do this on my node. Still i would miss a proper automatic rebalancer, but for a test i could do that by hand too.
> This is what i would like to get others opinion on. In the current state of the network this could work *for me*. But everyone still cannot do this, as suckers must exist.

Personally, I think this basically admits that the "overcharge" strategy will not be dominant in the long run, but it will dominate over a network where most people act irrationally and set feerates all over the place.

More from devast:

> I think calling this a economically rational strategy is a long shot. This just helps route finding algorithms. Minimizes your local failed forwards. Makes you more reliable.
> But this will not make you a *maker*, this cannot assure you have liquidity ready in the directions where there is demand. Sure, if everyone started doing this, the network would be in a much better shape.
>
> The economic logic of "high supply -> low fee, low supply -> high fee" do play in a different way.
> Not in the context of *your* channel, but the context of the peer node.
> a, If a node has 100:10 total inbound:outbound capacity, you won't be able to ask any meaningful fee to them, regardless of your current channel balance. Everyone and their mothers have cheap channels to them already.
> b, If a node has 10:100 total inbound:outbound capacity, You will be able to charge a LOT in fees to them, again regardless of your current channel balance.
> c, If a node has 100:100 total inbound:outbound capacity, then just the fee from balance could work. But this type of node is the exception, not the norm.
> Then you might ask, why am i saying you should overprice everyting to some degree ?
> Well in the above screnario your channel to b, has obvious economic value. What about a, ?
> Your outbound capacity to a, has no value. However, inbound capacity from a, has economic value. Since it's scarce.
> And the only way you can capitalize on a, is to charge good fees on any traffic entering from a, hence asking a premium on all your channels.

As per another node operator:

> Really good points here, finally had time to carefully read. I like the described fee-based balance leaking idea and I think that is what currently is the accepted norm among many routing node operators - different ranges of fees, I adjust in a range of 100-1000 depending on channel balance, and what I wanted clboss to do for me was to adjust *faster* than I can do - preferably immediately when some previously idle channel wakes up and starts sucking up all liquidity at minimal rate.
>
> Huge exceptions to this are default 1-1 nodes (they are almost always very bad peers with no flow), ZFR (good bi-directional flow in my experience), and static fee nodes (The Wall with 1000-1400 static fee range and yalls and others). Static fee node ops use proceeds from huge fees to rebalance their channels, so it is a viable approach to a healthy node as well. Maybe clboss fee adjuster could operate within the provided range, extreme case being a static fee, so operator can define the desired strategy and let the market win?
>
> Also one thing to consider for the proposal is factoring in historical data.
>
> Example:
>
> I have two 10m channels, both with 90% balance on my side. Channel A has routed ~20m both ways, Channel B has routed 1m one way. If X is my 50-50 channel fee then I would set B's fees to 5X and A's fees to 2X. To me it is one of the three most important factors when determining fees -
> 1. current channel balance;
> 2. is the channel pushing liquidity back, what %, how recently;
> 3. how healthy (response time, uptime, channel stats etc) is the host
>
> Number three does factor less in the fees and more in the decision to close the channel if there had been no movement for 30 days.

📅 Original date posted:2022-05-09 📝 Original message: Good ...

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

In reply to nevent1q…vgda
_________________________

📅 Original date posted:2022-05-09
📝 Original message:
Good morning devrandom,

It seems to me that a true validating Lightning signer would need to be a Bitcoin node with active mitigation against eclipse attacks, the ability to monitor the blockheight, and the ability to broadcast transactions.

Otherwise, a compromised node can lie and tell the signer that the block height is much lower than it really is, letting the node peers clawback incoming HTLCs and claim outgoing HTLCs, leading to a net loss of funds in the forwarding case.

Looking at the link, it seems to me that you have a "UTXO Set Oracle", does this inform your `lightning-signer` about block height and facilitate transaction broadcast?
Is this intended to be a remote device from the `lightning-signer` device?
If so, what happens if the connection between the "UTXO Set Oracle" remote device and the `lightning-signer` is interrupted?

In particular:

* Incoming forward arrives.
* Compromised node accepts the incoming HTLC and offers outgoing HTLC.
* Presumably the `lightning-signer` signs off on this, as long as the outgoing HTLC is of lower value etc etc.
* Compromised node stops communicating with the `lightning-signer`.
* Outgoing HTLC times out, but compromised node and the outgoing peer do nothing.
* Incoming HTLC times out, and the incoming peer unilaterally closes the channel, claiming the timelock branch of the HTLC onchain.
* Outgoing peer unilaterally closes the channel, claiming the hashlock branch of the outgoing HTLC onchain.

Unless the `lightning-signer` unilaterally closes the channel when the outgoing HTLC times out and actively signs and broadcasts the timelock branch for the outgoing HTLC, then this leads to funds loss.
This requires that the `lightning-signer` be attached to a Bitcoin node that is capable of:

* Actively finding and connecting to multiple Bitcoin peers.
* Actively checking the block header chain (acceptable at only SPV security since you really only care about blockheight, and have a UTOX Set Oracle which upgrades the rest of your security from SPV to full?).
* Actively broadcasting unilateral closes and HTLC timelock claims for outgoing HTLCs.

Is that how `lightning-signer` is designed?

This seems to be listed in: https://gitlab.com/lightning-signer/docs/-/wikis/Potential-Exploits

> an HTLC is failed and removed on the input before it is removed on the output. The output is then claimed by the counterparty, losing that amount

Is there a mitigation, planned or implemented, against this exploit?

Regards,
ZmnSCPxj

📅 Original date posted:2022-05-03 📝 Original message: Good ...

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

In reply to nevent1q…pyyj
_________________________

📅 Original date posted:2022-05-03
📝 Original message:
Good morning John,

Thank you for clarifying.

> Zman,
> I was not arguing for moving things from the edge, nor was I arguing to make Taro a BOLT. Laolu is misinterpreting my message.
> I was explaining that the capabilities that would allow Taro to interact with LN have no special relationship to Taro alone and should be designed to accommodate any outside layer/network.
> I gave specific examples of requirements that LL is portraying as Taro Layer design, that are really just new features for LN nodes that do not need to be network/layer-specific:
> - Making LN nodes aware of assets on other networks- Establishing commitments for (atomic) swapping for payments/routing- Supporting the ability to exchange and advertise exchange rates for asset pairs- Supporting other multi-asset routes when considering routing paths, bridging nodes with alternate assets
> I don't care whether this is framed as BOLT or BLIP content, as in the end each implementation will do what it needs to stay relevant in the market. I care that this is framed and designed correctly, so we aren't locked into one specific outside layer. You could argue the degree to which the above features need to exist in the network, and whether to restrict such features to the "edge," but my point is that an LN node that wants to be aware of an outside network, and extra assets in addition to Bitcoin, will need such features, and such features are not Taro-specific.

My understanding here of "the edge" vs "the core" is that the core is responsible for multi-hop routes and advertisements for channels.
Thus the below:

> - Supporting the ability to exchange and advertise exchange rates for asset pairs
> - Supporting other multi-asset routes when considering routing paths, bridging nodes with alternate assets

... would be considered part of "the core".

Notwithstanding the previously linked objection against a multi-asset Lightning Network, we can discuss these as two topics:

* Advertising exchange rates.
* Routing between channels of different asset types.

### Advertising Exchange Rates

Without changing the BOLT protocol, we can define a particular odd featurebit that cross-asset exchanges can set.
Then, odd-numbered messages can be defined, such that I can ask that node:

* What assets it has on what channels.
* Exchange rates of each asset to Bitcoin in msats (to serve as a common exchange rate to allow conversion from any one asset to any other asset, specifying only N exchange rates instead of N^2).
* We also need to spec out any rounding algorithm, in order to have the same calculation across implementations.

BOLT is flexible enough that this does not need to be "blessed" until more than one LN implementation agrees on the new spec.

### Routing Between Channnels Of Different Asset Types

I was the one who first suggested dropping the `realm` byte.

Originally, `realm` was a 1-byte identifier for the asset type.

However, I pointed out that `realm` was simultaneously too large and too small.

* Too Large: We needed a byte in order to allow the new "TLV" thing to be used in routing onions. so that we could specify how many sections the TLV thing would take up, and we had already taken up all the space in a typical IP packet for the onion.
* Too Small: If multi-asset actually materializes, it is hard to imagine that there would be only 255 of them (`realm = 0` was already for Bitcoin, so there were only 255 possible identifiers left).

The idea in my mind basically was that instead of using the `realm` byte for identifying asset, we would instead add a new type for TLV, which would have 20 bytes.
These 20 bytes would be, say, RIPEMD160 . SHA256 of the name of the asset.

Odd TLV types are ignored, but individual onion layers are targeted to specific nodes anyway, so it should be safe to use an even TLV type instead for this.

--

Again, note that this is a change in "the core" (and thus, pedantically, you *are* arguing for moving it from the edge, if you want these two items you specified).
I personally think it dubious to consider, for the reason that I already linked to in the previous reply, but in any case, it is indeed possible to do.

Generally, the path towards updating the BOLT is for at least one implementation to actually implement this, then convince at least one other implementation that this makes sense (possibly via this mailing list), and *then* maybe you have a chance of it getting into the BOLT spec.
You may find it more useful to e.g. hire a freelancer to work on this for`lnd` and get it merged.

Regards,
ZmnSCPxj

📅 Original date posted:2022-05-02 📝 Original message: Good ...

2023-06-09T15:05:58+02:00

In reply to nevent1q…kwf5
_________________________

📅 Original date posted:2022-05-02
📝 Original message:
Good morning John, and Laolu,

> > but instead the requirement to add several feature concepts to LN that
> > would allow tokens to interact with LN nodes and LN routing:
>
> From this list of items, I gather that your vision is actually pretty
> different from ours. Rather than update the core network to understand the
> existence of the various Taro assets, instead we plan on leaving the core
> protocol essentially unchanged, with the addition of new TLV extensions to
> allow the edges to be aware of and interact w/ the Taro assets. As an
> example, we wouldn't need to do anything like advertise exchange rates in
> the core network over the existing gossip protocol (which doesn't seem like
> the best idea in any case given how quickly they can change and the existing
> challenges we have today in ensuring speedy update propagation).

Adding on to this, the American Call Option problem that arises when using H/PTLCs: https://lists.linuxfoundation.org/pipermail/lightning-dev/2018-December/001752.html

The above objection seems to be one reason for proposing multi-asset "on the edge" rather than have it widely deployed in the published Lightning Network.

Regards,
ZmnSCPxj

📅 Original date posted:2022-04-04 📝 Original message: Good ...

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

In reply to nevent1q…42hf
_________________________

📅 Original date posted:2022-04-04
📝 Original message:
Good morning pushd,

> Good morning,
>
> Things that affect privacy particularly when large sums of money are involved in bitcoin:
>
> Liquidity, Anonymity set, Amounts, Type of addresses/scripts, Block, Locktime and Version
>
> I have left out things that aren't part of bitcoin protocol or blockchain like KYC. It is difficult for users to move large sums of BTC without being observed because bitcoin does not have confidential transactions to hide amounts. Coinjoin implementations have their own issues, trade-offs, some might even censor transactions and big amounts will still be a problem. Coinswap might be an alternative in future however I wanted to share one solution that could be helpful in improving privacy.
>
> Synonym did first [stablecoin transaction][1] in a lightning channel using Omni BOLT. Consider Alice starts a bitcoin project in which a lightning channel is used for assets like stablecoin. Bob wants to use 1000 BTC linked with an incident. He opens channels with Alice, gets stablecoin which can be used in any project that supports Omni BOLT assets.
>
> Questions:
>
> What is the lightning channel capacity when using Omni BOLT?
>
> What else can be improved in this setup? Anything else that I maybe missing?
>
> I added 'fifty shades of privacy' in subject because it was the first thing that came to my mind when I look at privacy in bitcoin and lightning.
>
> [1]: https://youtu.be/MfaqYeyake8

I am not quite sure that using OmniBOLT and a stablecoin (I ssume you mean an asset ostensibly pegged to traditional currency) *improves* the privacy here.

Even if you have onchain confidentiality, your counterparty *has to* know how much of the funds are theirs, and by elimination, since there are only the two of you on that channel, the remainder of the funds is yours.
No amount of onchain confidential transactions can hide this fact.
And if the channel is unpublished, then the counterparty knows that any send from you is your own payment, and any receive to you is your own received funds.

Using a non-Bitcoin assett(whether pegged to a traditional currency or not) simply reduces the likelihood that you will be able to *use* the rest of the network, since most of the network only works with Bitcoin.
This reduction in liquidity translates to a reduction in anonymity set, meaning it is probably more likely that Alice will be running most of the nodes that *do* support your OmniBOLT-based asset and even if you try to route your funds elsewhere, if you use OmniBOLT, it is likely that Alice will be able to track where you moved your funds.

You are better off with this scheme if you want to "clean" 1000 BTC:

* Set up a published LN node with already-clean funds (or just clean a small amount of BTC using existing CoinJoin methods).
* Leave it running for a while, or use your existing one.
* Make all or at least most of its channels published!
* Make sure it has at least *some* incoming capacity, use the swap-to-onchain trick or buy incoming liquidity.
* Set up a *throwaway* LN node using your dirty 1000 BTC.
* On your throwaway, create channel(s) to randomly-selected LN nodes.
* Send amounts from the throwaway to your published LN node.
* At a later time, send from your published LN node to e.g. Boltz Exchange offchain-to-onchain swap to get funds back onchain and get more incoming capacity to your published LN node.
* Repeat until you have drained all the funds from your throwaway node.
* Close the channels of your throwaway node and destroy all evidence of it having ever existed.

This provides privacy:

* By using an intermediate published node to temporarily hold your funds:
* You disrupt timing correlation from the outgoing payments of your dubious throwaway node to the Boltz Exchange payment: first you pay to your published node, let the funds stew a bit, then send to the Boltz Exchange.
* Published node has deniability: payments *to* that node could conceivably be destined elsewhere i.e. the published node can claim it was just forwarding to someone else.
* Source routing means that Boltz Exchange can report your onchain address, but cannot correlate it with your published node.

Regards,
ZmnSCPxj

📅 Original date posted:2022-03-16 📝 Original message: Good ...

2023-06-09T15:05:33+02:00

In reply to nevent1q…4gp9
_________________________

📅 Original date posted:2022-03-16
📝 Original message:
Good morning Rene, sorry for the lateness,

> Last but not least, please allow me to make a short remark on the (still to me very surprisingly controversial) base fee discussion: For simplicity I did not include any fee considerations to the published code (besides a fee report on how expensive the computed flow is). However in practice we wish to optimize at least for high reliability (via neg log success probabilities) and cheap fees which in particular with the ppm is very easily possible to be included to the piece wise linearized cost function. While for small base fees it seems possible to encode the base fee into the first segment of the piecewise linearized approximation I think the base fee will still be tricky to be handled in practice (even with this approximation). For example if the base fee is too high the "base fee adjusted" unit cost of the first segment of the piecewise linearized problem might be higher than the unit cost of the second segment which effectively would break the convexity. Thus I reiterate my earlier point that from the perspective of the year long pursued goal of optimizing for fees (which all Dijkstra based single path implementations do) it seems to be best if the non linearity that is introduced by the base fee would be removed at all. According to discussions with people who crate Lightning Network explorer (and according to my last check of gossip) about 90% of channels have a base fee of 1 sat or lower and ~38% of all channels already set their base fee away from the default value to 0 [16].

I think the issue against 0-base-fee is that, to a forwarding node operator, every HTLC in-flight is a potential cost center (there is always some probability that the channel has to be forced onchain with the HTLC in-flight, and every HTLC has to be published on the commitment tx), and that cost is *not* proportional to the value of the HTLC (because onchain fees do not work that way).
Thus, it seems reasonable for a forwarding node to decide to pass on that cost to their customers, the payers, in the form of base fees.

The response of customers would be to boycott non-0-base fees, by e.g. using a heuristic that overweighs non-0-base-fee and reducing usage of such channels (but if every forwarding node *has* a base fee, going through them anyway, which is why you just overweigh them, not eliminate them from the graph outright).
Then forwarding nodes will economically move towards 0-base fee.

So I think you would find it impossible to remove the base fee field, but you can strongly encourage 0-base-fee usage by integrating the base fee but overweighted.
(I think my previous formulation --- treat the base fee as a proportional fee --- would do some overweighing of the base fee.)

Which reminds me, I have not gotten around to make a 0-base-fee flag for `clboss`, haha.
And I might need to figure out a learning algorithm that splits base and proportional fees as well, *sigh*.

Regards,
ZmnSCPxj

📅 Original date posted:2022-02-24 📝 Original message: Good ...

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

In reply to nevent1q…z82u
_________________________

📅 Original date posted:2022-02-24
📝 Original message:
Good morning lightning-dev and bitcoin-dev,

Recently, some dumb idiot, desperate to prove that recursive covenants are somehow a Bad Thing (TM), [necromanced Drivechains][0], which actually caused Paul Sztorc to [revive][1] and make the following statement:

> As is well known, it is easy for 51% hashrate to double-spend in the LN, by censoring 'justice transactions'. Moreover, miners seem likely to evade retribution if they do this, as they can restrain the scale, timing, victims, circumstances etc of the attack.

Let me state that, as a supposed expert developer of the Lightning Network (despite the fact that I probably spend more time ranting on the lists than actually doing something useful like improve C-Lightning or CLBOSS), the above statement is unequivocally ***true***.

However, I believe that the following important points must be raised:

* A 51% miner can only attack LN channels it is a participant in.
* A 51% miner can simultaneously attack all Drivechain-based sidechains and steal all of their funds.

In order for "justice transactions" to come into play, an attacker has to have an old state of a channel.
And only the channel participants have access to old state (modulo bugs and operator error on not being careful of toxic waste, but those are arguably as out of scope as operator error not keeping your privkey safe, or bugs that reveal your privkey).

If the 51% miner is not a participant on a channel, then it simply has no access to old state of the channel and cannot even *start* the above theft attack.
If the first step fails, then the fact that the 51% miner can perform the second step is immaterial.

Now, this is not a perfect protection!
We should note that miners are anonymous and it is possible that there is already a 51% miner, and that that 51% miner secretly owns almost all nodes on the LN.
However, even this also means there is some probability that, if you picked a node at random to make a channel with, then there is some probability that it is *not* a 51% miner and you are *still* safe from the 51% miner.

Thus, LN usage is safer than Drivechain usage.
On LN, if you make a channel to some LN node, there is a probability that you make a channel with a non-51%-miner, and if you luck into that, your funds are still safe from the above theft attack, because the 51% miner cannot *start* the attack by getting old state and publishing it onchain.
On Drivechain, if you put your funds in *any* sidechain, a 51% miner has strong incentive to attack all sidechains and steal all the funds simultaneously.

--

Now, suppose we have:

* a 51% miner
* Alice
* Bob

And that 51% miner != Alice, Alice != Bob, and Bob != 51% miner.

We could ask: Suppose Alice wants to attack Bob, could Alice somehow convince 51% miner to help it steal from Bob?

First, we should observe that *all* economically-rational actors have a *time preference*.
That is, N sats now is better than N sats tomorrow.
In particular, both the 51% miner *and* Alice the attacker have this time preference, as does victim Bob.

We can observe that in order for Alice to benefit from the theft, it has to *wait out* the `OP_CSV` before it can finalize the theft.
Alice can offer fees to the miner only after the `OP_CSV` delay.

However, Bob can offer fees *right now* on the justice transaction.
And the 51% miner, being economically rational, would prefer the *right now* funds to the *maybe later* promise by Alice.

Indeed, if Bob offered a justice transaction paying the channel amount minus 1 satoshi (i.e. Bob keeps 1 satoshi), then Alice has to beat that by offering the entire channel amount to the 51% miner.
But the 51% miner would then have to wait out the `OP_CSV` delay before it gets the funds.
Its time preference may be large enough (if the `OP_CSV` delay is big enough) that it would rather side with Bob, who can pay channel amount - 1 right now, than Alice who promises to pay channel amount later.

"But Zeeman, Alice could offer to pay now from some onchain funds Alice has, and Alice can recoup the losses later!"
But remember, Alice *also* has a time preference!
Let us consider the case where Alice promises to bribe 51% miner *now*, on the promise that 51% miner will block the Bob justice transaction and *then* Alice gets to enjoy the entire channel amount later.
Bob can counter by offering channel amount - 1 right now on the justice transaction.
The only way for Alice to beat that is to offer channel amount right now, in which case 51% miner will now side with Alice.

But what happens to Alice in that case?
It loses out on channel amount right now, and then has to wait `OP_CSV` delay, to get the exact same amount later!
It gets no benefit, so this is not even an investment.
It is just enforced HODLing, but Alice can do that using `OP_CLTV` already.

Worse, Alice has to trust that 51% miner will indeed block the justice transaction.
But if 51% miner is unscrupulous, it could do:

* Get the bribe from Alice right now.
* After the bribe from Alice confirms, confirm the justice transaction (which has a bribe from Bob).
* Thus:
* Alice loses the channel amount.
* Bob keeps 1 satoshi.
* 51% miner gets channel amount + channel amount - 1.

Now of course, we can eliminate the need for trust by using some kind of smart contract.
Unfortunately for Alice, there is no contract that Alice and 51% miner can engage in, to ensure that 51% miner will block the justice transaction, which itself does *not* require that 51% miner wait out the `OP_CSV` delay.
Either the payment from Alice to 51% miner is delayed (and the 51% miner suffers the time preference discount) or the 51% miner has to offer a bond that only gets released after the Alice theft succeeds (and again the 51% miner suffers the time preference discount on that bond).

Thus, due to the `OP_CSV` delay, the honest participant always has the upper hand, even in a 51% miner scenario.
If your channel is *not* with the 51% miner, your funds are still safe.

--

Now, we might consider, what if the 51% miner always blocks *all* Lightning-related transactions?
In that case, it loses out on any bribes that any LN participants would offer.

Further, with Taproot, a mutual LN channel close is indistinguishable from a singlesig spend.
Thus, not all LN-related transactions can be censored by the 51% miner.
Extensive use of Taproot Tapleaves can also make it difficult for a 51% miner to differentiate between LN and other protocols (though that *does* mean we should probably e.g. coordiante with other protocols like CoinSwap, CoinPool etc. so that the "shape" of Taproot Tapleaves is consistent across protocols).

--

A final note: in the presence of channel factories, the *entire* factory is at risk if at least one participant is the 51% miner or a sockpuppet thereof.
Thus, channel factories trade off even further scaling, at the cost of reduced protection against 51% miners.

Regards,
ZmnSCPxj

[0]: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-February/019976.html
[1]: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-February/019978.html

📅 Original date posted:2021-12-16 📝 Original message: Good ...

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

In reply to nevent1q…wmsc
_________________________

📅 Original date posted:2021-12-16
📝 Original message:
Good morning William,

> Has anyone coded up a 'Poor man's rendez-vous' demo yet? How hard would
> it be, could it be done with a clightning plugin perhaps?

Probably not *yet*; it needs each intermediate payee (i.e. the one that is not the last one) to sign an invoice for which it does not know the preimage.
Maybe call such a command `signfakeinvoice`.

However, if a command to do the above is implemented (it would have to generate and sign the invoice, but not insert it into the database at all), then intermediate payees can use `htlc_accepted` hook for the "rendez-vous".

So to generate the invoice:

* Arrange the payees in some agreed fixed order.
* Last payee generates a normal invoice.
* From last payee to second, each one:
* Passes its invoice to the previous payee.
* The previous payee then creates its own signed invoice with `signfakeinvoice` to itself, adding its payout plus a fee budget, as well as adding its own delay budget.
* The previous payee plugin stores the next-payee invoice and the details of its own invoice to db, such as by `datastore` command.
* The first payee sends the sender the invoice.

On payment:

* The sender sends the payment to the first hop.
* From first payee to second-to-last:
* Triggers `htlc_accepted` hook, and plugin checks if the incoming payment has a hash that is in this scheme stored in the database.
* The plugin gathers `htlc_accepted` hook invocations until they sum up to the expected amount (this handles multipath between payees).
* The plugin marks that it has gathered all `htlc_accepted` hooks for that hash in durable storage a.k.a. `datastore` (this handles a race condition where the plugin is able to respond to some `htlc_accepted` hooks, but the node is restarted before all of them were able to be recorded by C-Lightning in its own database --- this makes the plugin skip the "gathering" step above, once it has already gathered them all before).
* The plugin checks if there is already an outgoing payment for that hash (this handles the case where our node gets restarted in the meantime --- C-Lightning will reissue `htlc_accepted` on startup)
* If the outgoing payment exists and is pending, wait for it to resolve to either success or failure.
* If the outgoing payment exists and succeeded, resolve all the gathered `htlc_accepted` hooks.
* If the outgoing payment exists and failed, fail all the gathered `htlc_accepted` hooks.
* Otherwise, perform a `pay`, giving `maxfeepercent` and `maxdelay` based on its fee budget and delay budget.
When the `pay` succeeds or fails, propagate it to the gathered `htlc_accepted` hooks.
* The last payee just receives a normal payment using the normal invoice-receive scheme.

Regards,
ZmnSCPxj

📅 Original date posted:2021-12-07 📝 Original message: Good ...

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

In reply to nevent1q…7tcl
_________________________

📅 Original date posted:2021-12-07
📝 Original message:
Good morning LL, and t-bast,

> > Basically, if my memory and understanding are accurate, in the above, it is the *PTLC-offerrer* which provides an adaptor signature.
> > That adaptor signature would be included in the `update_add_ptlc` message.
>
> Isn't it the case that all previous PTLC adaptor signatures need to be re-sent for each update_add_ptlc message because the signatures would no longer be valid once the commit tx changes. I think it's better to put it in `commitment_signed` if possible. This is what is done with pre-signed HTLC signatures at the moment anyway.

Agreed.

This is also avoided by fast-forwards, BTW, simply because fast-forwards delay the change of the commitment tx.
It is another reason to consider fast-forwards, too....

Regards,
ZmnSCPxj

📅 Original date posted:2021-12-07 📝 Original message: Good ...

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

In reply to nevent1q…e3qf
_________________________

📅 Original date posted:2021-12-07
📝 Original message:
Good morning t-bast,

> I believe these new transactions may require an additional round-trip.
> Let's take a very simple example, where we have one pending PTLC in each
> direction: PTLC_AB was offered by A to B and PTLC_BA was offered by B to A.
>
> Now A makes some unrelated updates and wants to sign a new commitment.
> A cannot immediately send her `commitment_signed` to B.
> If she did, B would be able to broadcast this new commitment, and A would
> not be able to claim PTLC_BA from B's new commitment (even if she knew
> the payment secret) because she wouldn't have B's signature for the new
> PTLC-remote-success transaction.
>
> So we first need B to send a new message `remote_ptlcs_signed` to A that
> contains B's adaptor signatures for the PTLC-remote-success transactions
> that would spend B's future commitment. After that A can safely send her
> `commitment_signed`. Similarly, A must send `remote_ptlcs_signed` to B
> before B can send its `commitment_signed`.
>
> It's actually not that bad, we're only adding one message in each direction,
> and we're not adding more data (apart from nonces) to existing messages.
>
> If you have ideas on how to avoid this new message, I'd be glad to hear
> them, hopefully I missed something again and we can make it better!

`SIGHASH_NONE | SIGHASH_NOINPUT` (which will take another what, four years?) or a similar "covenant" opcode, such as `OP_CHECKTEMPLATEVERIFY` without any commitments or an `OP_CHECKSIGFROMSTACK` on an empty message.
All you really need is a signature for an empty message, really...

Alternately, fast-forwards, which avoid this because it does not change commitment transactions on the payment-forwarding path.
You only change commitment transactions once you have enough changes to justify collapsing them.
Even in the aj formulation, when A adds a PTLC it only changes the transaction that hosts **only** A->B PTLCs as well as the A main output, all of which can be sent outright by A without changing any B->A PTLCs.

Basically... instead of a commitment tx like this:

+-------+
funding outpoint -->| |--> A main
| |--> B main
| |--> A->B PTLC
| |--> B->A PTLC
+-------+

We could do this instead:

+-------+2of2 +-----+
funding outpoint -->| |----->| |--> A main
| | | |--> A->B PTLC
| | +-----+
| |2or2 +-----+
| |----->| |--> B main
| | | |--> B->A PTLC
+-------+ +-----+

Then whenever A wants to add a new A->B PTLC it only changes the tx inputs of the *other* A->B PTLCs without affecting the B->A PTLCs.
Payment forwarding is fast, and you only change the "big" commitment tx rarely to clean up claimed and failed PTLCs, moving the extra messages out of the forwarding hot path.

But this is basically highly similar to what aj designed anyway, so...

Regards,
ZmnSCPxj

📅 Original date posted:2021-12-06 📝 Original message: Good ...

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

In reply to nevent1q…fzj6
_________________________

📅 Original date posted:2021-12-06
📝 Original message:
Good morning t-bast,

Long ago: https://lists.linuxfoundation.org/pipermail/lightning-dev/2019-December/002385.html

And I quote:

>> A potential issue with MuSig is the increased number of communication rounds needed to generate signatures.
>
>I think you can reduce this via an alternative script path. In
>particular, if you want a script that the other guy can spend if they
>reveal the discrete log of point X, with musig you do:
>
> P = H(H(A,B),1)*A + H(H(A,B),2)*B
> [exchange H(RA),H(RB),RA,RB]
>
> [send X]
>
> sb = rb + H(RA+RB+X,P,m)*H(H(A,B),2)*b
>
> [wait for sb]
>
> sa = ra + H(RA+RB+X,P,m)*H(H(A,B),1)*a
>
> [store RA+RB+X, sa+sb, supply sa, watch for sig]
>
> sig = (RA+RB+X, sa+sb+x)
>
>So the 1.5 round trips are "I want to do a PTLC for X", "okay here's
>sb", "great, here's sa".
>
>But with taproot you can have a script path as well, so you could have a
>script:
>
> A CHECKSIGVERIFY B CHECKSIG
>
>and supply a partial signature:
>
> R+X,s,X where s = r + H(R+X,A,m)*a
>
>to allow them to satisfy "A CHECKSIGVERIFY" if they know the discrete
>log of X, and of course they can sign with B at any time. This is only
>half a round trip, and can be done at the same time as sending the "I
>want to do a PTLC for X" message to setup the (ultimately cheaper) MuSig
>spend. It's an extra signature on the sender's side and an extra verification
>on the receiver's side, but I think it works out fine.

It has been a while since I read that post, so my details may be fuzzy, but it looks possible as a way to reduce roundtrips, maybe?

Basically, if my memory and understanding are accurate, in the above, it is the *PTLC-offerrer* which provides an adaptor signature.
That adaptor signature would be included in the `update_add_ptlc` message.

Does it become more workable that way?

Regards,
ZmnSCPxj

📅 Original date posted:2021-11-29 📝 Original message: Good ...

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

In reply to nevent1q…93sr
_________________________

📅 Original date posted:2021-11-29
📝 Original message:
Good morning Jeremy,

> Just a minor curiosity I figured was worth mentioning on the composition of delegations and anyprevout...
>
> DA: Let full delegation be a script S such that I can sign script R and then R may sign for a transaction T.
> DB: Let partial delegation be a script S such that I can sign a tuple (script R, transaction T) and R may sign T.
>
> A simple version of this could be done for scriptless multisigs where S signs T and then onion encrypts to the signers of R and distributes the shares.

Just to be clear, do you mean, "for the case where R is a scriptless multisig"?
And, "onion encrypts the signature"?

Since part of the signature `(R, s)` would be a scalar modulo k, `s`, another way would be to SSS that scalar and distribute the shares to the R multisig signers, that may require less computation and would allow R to be k-of-n.

> However, under such a model, if T is signed by S with AnyPrevOut, then T is now arbitrarily rebindable.
>
> Therefore let us define more strictly:
>
> DC: Let half-delegation be a script S such that I can sign a tuple (script R, transaction T) and R may sign T and revealing T/R does grant authorization to any other party.

Do you mean "does *not* grant"?

If S is a delegator that intends to delegate to R, and creates a simple Taproot with keypath S, and signs a spend from that using `SIGHASH_ANYPREVOUT` and distributes shares of the signature to R, then once the signature is revealed onchain, anyone (not just R) may rebind the transaction to any other Taproot with keypath S, which I think is what you wish to prevent with the stricter definition "does *not* grant authorization to any other party"?

>
> The signer of R could choose to sign with APO, in which case they make the txn rebindable. They could also reveal the private keys for R similarly.
> For "correct" use, R should sign with SIGHASH_ALL, binding the transaction to a single instance.

Well, for the limited case where R is a k-of-n multisig (including n-of-n) it seems the "sign and SSS" would work similarly, for "correct" use R should sign with `SIGHASH_ALL` anyway, so in the "sign and SSS" method S should always sign with `SIGHASH_ALL`.

This does not work if the script S itself is hosted in some construction that requires `SIGHASH_ANYPREVOUT` at the base layer, which I believe is what you are concerned about?
In that case all signers should really give fresh pubkeys, i.e. no address reuse.

> Observation: a tuple script R + transaction T can, in many cases, be represented by script R || <H(transaction T)> CTV.
> Corollary: half-delegation can be derived from full delegation and a covenant.
>
> Therefore delegation + CTV + APO may be sufficient for making chaperone signatures work, if they are desired by a user.

Hmm what?
Is there some other use for chaperone signatures other than to artificially encumber `SIGHASH_ANYPREVOUT` or have definitions drifted over time?

> Remarks:
>
> APO's design discussion should not revisit Chaperone signatures (hopefully already a dead horse?) but instead consider how APO might compose with Delegation proposals and CTV.

no chaperones == good

Regards,
ZmnSCPxj

📅 Original date posted:2021-11-23 📝 Original message: Good ...

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

In reply to nevent1q…hsus
_________________________

📅 Original date posted:2021-11-23
📝 Original message:
Good morning x-raid,

> so You propose Acinq / Blockstream / Lightning Labs do not have funds to run a box or 2 ?

Not at all, I am proposing that these people, who have already done the effort to release working Lightning Network Node implementations free of charge to you, are not obligated to *also* devote more hardware and resources.

Let me tell a little story...

Some years ago, during the SegWit wars, there was a sentiment "when are **they** going to implement Lightning??"
Both anti-SegWit and pro-SegWit asked this:

* anti-SegWit: Yeah, you need bigblocks, Lightning is vaporware, when are **they** going to implement Lightning?
* pro-SegWit: Lightning is so totes kool, this is why we SegWit, when are **they** going to implement Lightning?

After some time participating in the SegWit wars, I realized that I was, in fact, a programmer (LOL).
So why should **I** be asking when **they** are going to implement Lightning?
As a programmer, **I** could implement Lightning myself!
I should be asking myself why **I** was not implementing it.

Thus I started contributing to the Lightning implementation written in a language I could understand, C-Lightning.

My question to you is: obviously you are a node operator as otherwise the issue you raise would not be relevant to you, but what can *you* do to advance your goal?

(In any case: C-Lightning and Eclair devs have already mentioned they already run mainnet nodes tracking our respective master branches (i.e. we already eat our own dog food, because duh --- for many of us, the reason we are developing this is because for *other* reasons, we *have to* run Lightning nodes), is there any particular implementation you are concerned about?
Maybe ask them directly?)

Regards,
ZmnSCPxj

📅 Original date posted:2021-11-23 📝 Original message: Good ...

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

In reply to nevent1q…78kq
_________________________

📅 Original date posted:2021-11-23
📝 Original message:
Good morning x-raid,

> I propose a dialog of the below joint effort ...
>
> thanks
> /xraid
>
> ***
> A decentralised integration lab where CL Eclair LDK LND (++ ?) runs each the latest release on "one box" rBOX and master.rc on "another box" rcBOX.

I believe Electrum also has its own bespoke implementation.
There was also Ptarmigan.

Regards,
ZmnSCPxj

📅 Original date posted:2021-11-15 📝 Original message: Good ...

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

In reply to nevent1q…w5pg
_________________________

📅 Original date posted:2021-11-15
📝 Original message:
Good morning Joost,

> What I did in lnd is to work with so called 'payment attempt cost'. A virtual satoshi amount that represents the cost of a failed attempt.

https://lists.linuxfoundation.org/pipermail/lightning-dev/2021-August/003191.html

And I quote:

> Introduction
> ============
>
> What is the cost of a failed LN payment?

See link for more.

Regards,
ZmnSCPxj

📅 Original date posted:2021-10-21 📝 Original message: Good ...

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

In reply to nevent1q…3hwd
_________________________

📅 Original date posted:2021-10-21
📝 Original message:
Good morning Joost,

> A potential downside of a dedicated probe message is that it could be used for free messaging on lightning by including additional data in the payload for the recipient. Free messaging is already possible today via htlcs, but a probe message would lower the cost to do so because the sender doesn't need to lock up liquidity for it. This probably increases the spam potential. I am wondering if it is possible to design the probe message so that it is useless for anything other than probing. I guess it is hard because it would still have that obfuscated 1300 bytes block with the remaining part of the route in it and nodes can't see whether there is other meaningful data at the end.

For the probe, the onion max size does not *need* to be 1300, we could reduce the size to make it less useable for *remote* messaging.

Regards,
ZmnSCPxj

📅 Original date posted:2021-10-19 📝 Original message: Good ...

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

In reply to nevent1q…apwz
_________________________

📅 Original date posted:2021-10-19
📝 Original message:
Good morning Joost,

> There could be some corners where the incentives may not work out 100%, but I doubt that any routing node would bother exploiting this. Especially because there could always be that reputation scheme at the sender side which may cost the routing node a lot more in lost routing fees than the marginal gain from the upfront payment.
>
> Another option is that nodes that don't care to be secretive about their channel balances could include the actual balance in a probe failed message. Related: https://github.com/lightningnetwork/lightning-rfc/pull/695
>
> Overall it seems that htlc-less probes are an improvement to what we currently have. Immediate advantages include a reduction of the load on nodes by cutting out the channel update machinery, better ux (faster probes) and no locked up liquidity. On the longer term it opens up the option to charge for failed payments so that we finally have an answer to channel jamming.

One can argue that if you are hoping that forwarding nodes will not exploit this, you can also hope that forwarding nodes will not perform channel-jamming attacks.
As I noted before, channel jamming attacks will never be performed by payers or payees --- they have an incentive to complete the transaction and earn gains from trade.
Channel jamming attacks are performed by large forwarding nodes on their smaller competitors, since having 100 capacity on large versus 10 capacity on the smaller competitor is worse than having 89 capacity on the large versus 0 capacity on the smaller competitor.

On the other hand, perhaps it is at this point that we should start computing the exact incentives, hmm.

--

A thing to note is that any node along a path can disrupt an onion response by the simple expedient of XORing it with random stuff, or even just a non-0 constant.
This may allow for an additional attack vector.

Suppose I am a forwarding node and I receive a probe request, and it turns out the next hop lacks capacity right now.
I could incite the next hop to lie by forwarding the probe request to the next hop despite the lack of capacity.

If the next hop responds immediately, I can then corrupt the return onion.
Presumably if the next hop responded immediately it was reporting my lie to the sender.
By corrupting the return onion the ultimate sender is unable to determine *which* node along the route failed, and I can hope that the reputation penalty to my competitor forwarding nodes along the path compensates for the reputation hit I personally suffer.

If the next hop takes some time before responding, then possibly it colluded with me to lie about the capacity on our channel (i.e. it actually went ahead and forwarded to the next hop despite knowing I lied).
Then I could faithfully onion-encrypt the response and send it back to the ultimate sender.

To mitigate against the above attack:

* If a forwarding node gets a probe request for an amount that the asker is *currently* unable to give anyway:
* The forwarding node should still forward the probe request.
* On response, however, it replaces the response with its own report that the previous hop was a dirty liar.
* Note that the asker is the one who has full control over their funds in the channel, so the asker cannot later claim "but the network latency mixed up our messages!" --- the asker knows when it does `update_add_htlc` to reduce its capacity, so it should know it has the capacity or not.

Now, if we are going to add a message "the previous hop was a dirty liar" then we should ask if a forwarding node would want to make a false accusation.

* Suppose the previous hop has sufficient capacity and asked us if we have our own capacity.
* Does the current hop have any incentive to falsely accuse the previous hop?
* No: if it did, then the sender would not try their channel again in the close future, thus leading to lower fee earnings.

> ZmnSCPxj, as first person to propose the idea (I think?), would you be interested in opening a draft PR on the spec repository that outlines the new message(s) that we'd need and continue detailing from there?

It might end up not happening given the stuff I juggle randomly, so feel free to start it.

Regards,
ZmnSCPxj

📅 Original date posted:2021-10-15 📝 Original message: Good ...

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

In reply to nevent1q…784q
_________________________

📅 Original date posted:2021-10-15
📝 Original message:
Good morning Owen,

> C now notes that B is lying, but is faced with the dilemma:
>
> "I could either say 'no' because I can plainly see that B is lying, or
> I could say 'yes' and get some free sats from the failed payment (or
> via the hope of a successful payment from a capacity increase in the
> intervening milliseconds)."

Note that if B cannot forward an HTLC to C later, then C cannot have a failed payment and thus cannot earn any money from the upfront payment scheme; thus, at least that part of the incentive is impossible.

On the other hand, there is still a positive incentive for continuing the lie --- later, maybe the capacity becomes OK and C could earn both the upfront fee and the success fee.

> So C decides it's in his interest to keep the lie going. D, the payee,
> can't tell that it's a lie when it reaches her.
>
> If C did want to tattle, it's important that he be able to do so in a
> way that blames B instead of himself, otherwise payers will assume
> (incorrectly, and to C's detriment) that the liquidity deficit is with C
> rather than B.

That is certainly quite possible to do.

Regards,
ZmnSCPxj

📅 Original date posted:2021-10-15 📝 Original message: Good ...

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

In reply to nevent1q…cek7
_________________________

📅 Original date posted:2021-10-15
📝 Original message:
Good morning Owen,

> On Thu, Oct 14, 2021 at 09:48:27AM +0200, Joost Jager wrote:
>
> > So how would things work out with a combination of both of the
> > proposals described in this mail? First we make probing free (free as
> > in no liquidity locked up) and then we'll require senders to pay for
> > failed payment attempts too. Failed payment attempts after a
> > successful probe should be extremely rate, so doesn't this fix the ux
> > issue with upfront fees?
>
> Why couldn't a malicious routing node (or group of colluding routing
> nodes) succeed the probe and then fail the payment in order to collect
> the failed payment fee?

Good observation!

I propose substantially the same thing here: https://lists.linuxfoundation.org/pipermail/lightning-dev/2021-September/003256.html

In that proposal, I wrote:

> Another thought is: Does the forwarding node have an incentive to lie?
> Suppose the next hop is alive but the forwarding node has insufficient capacity towards the next hop.
> Then the forwarding node can lie and claim it can still resolve the HTLC, in the hope that a few milliseconds later, when the actual HTLC arrives, the capacity towards the next hop has changed.
> Thus, even if the capacity now is insufficient, the forwarding node has an incentive to lie and claim sufficient capacity.
>
> Against the above, we can mitigate this by accepting "no" from *any* node along the path, but only accepting "yes" from the actual payee.

We already have a mechanism to send an onion and get back an "error" reply; the reply can be identified by the sender as arising from any node along the path, or at the destination.
Basically, we simply reuse this mechanism:

* Do not need an HTLC with this onion.
* Only accept a "everything is OK" result from the destination.
* Accept a "sorry cannot forward" from *any* node along the path.

Thus, a malicious node cannot succeed the probe --- the probe has to reach the destination.

Now the malicious forwarding node could be colluding with the destination, but presumably the destination wants to *actually* get paid, so we expect that, economically, it has no incentive to cooperate with the malicious node to *fail* the actual payment later just to extract a tiny failure fee.

Regards,
ZmnSCPxj

📅 Original date posted:2021-10-12 📝 Original message: Good ...

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

In reply to nevent1q…l892
_________________________

📅 Original date posted:2021-10-12
📝 Original message:
Good morning aj,

> On Mon, Oct 11, 2021 at 05:05:05PM +1100, Lloyd Fournier wrote:
>
> > ### Scorched earth punishment
> >
> > Another thing that I'd like to mention is that using revocable signatures
> > enables scorched earth punishments [2].
>
> I kind-of think it'd be more interesting to simulate eltoo's behaviour.
> If Alice's current state has balances (A, B) and P in in-flight
> payments, and Bob posts an earlier state with (A', B') and P' (so A+B+P
> = A'+B'+P'), then maybe Alice's justice transaction should pay:
>
> A+P + max(0, B'-B)*0.1 to Alice
> B-f - max(0, B'-B)*0.1 to Bob
>
> (where "f" is the justice transaction fees)
>
> Idea being that in an ideal world there wouldn't be a hole in your pocket
> that lets all your coins fall out, but in the event that there is such
> a hole, it's a nicer world if the people who find your coins give them
> back to you out of the kindness of their heart.

This may model closer to "two tits for a tat" strategy.

"Tit for tat" is optimum in iterated prisoner dilemma assuming mistakes never happen; however, in the real world we know quite well that we may injure another person by complete accident.
The usual practice in the real world is that the injured person will accept an apology *once*, but a repeat will tend to make people assume you are hostile and switch them over to tit for tat.
This overall strategy is then "two tits for a tat", you are (in practice) given one chance and then you are expected to be very careful in interacting with that person to keep being in their good graces.

So, if what you propose is widespread, then a theft attempt is costless: you can try using old state, and your victim will, on finding it, instead just use what they think is the latest state.
Thus, merely attempting the theft is costless (modulo onchain fees, which may be enough punishment in this case?).

However, if we assume that in practice a lot of "theft attempts" are really people not taking RAID systems and database replication seriously and getting punished by the trickster god Murphy, then your proposal would actually be better, and if theft is unlikely enough to succeed, then even a costless theft attempt would still be worthless (and onchain fees will bite you anyway).

Regards,
ZmnSCPxj

📅 Original date posted:2021-10-08 📝 Original message: Good ...

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

In reply to nevent1q…wznj
_________________________

📅 Original date posted:2021-10-08
📝 Original message:
Good morning aj,

> On Sat, Oct 09, 2021 at 01:49:38AM +0000, ZmnSCPxj wrote:
>
> > A transaction is required, but I believe it is not necessary to put it onchain (at the cost of implementation complexity in the drop-onchain case).
>
> The trick with that is that if you don't put it on chain, you need
> to calculate the fees for it in advance so that they'll be sufficient
> when you do want to put it on chain, and you can't update it without
> going onchain, because there's no way to revoke old off-chain funding
> transactions.

Yes, onchain fees, right?

*Assuming* CPFP is acceptable, then fees for the commitment tx on the new scheme (or whatever equivalent in the transitioned-to mechanism is) would pay for the transitioning transaction, so fees paying for the transitioning transaction can still be adjusted at the transitioned-to updatable mechanism.
This probably assumes that the transaction package relay problem is fixed at the base layer though.

>
> > This has the advantage of maintaining the historical longevity of the channel.
> > Many pathfinding and autopilot heuristics use channel lifetime as a positive indicator of desirability,
>
> Maybe that's a good reason for routing nodes to do shadow channels as
> a matter of course -- call the currently established channel between
> Alice and Bob "C1", and leave it as bolt#3 based, but establish a new
> taproot based channel C2 also between Alice and Bob. Don't advertise C2
> (making it a shadow channel), just say that C1 now supports PTLCs, but
> secretly commit to those PTLCs to C2 instead C1. Once the C2 funding tx
> is buried enough, start advertising C2 instead taking advantage of its
> now sufficiently buried funding transaction, and convert C1 to a shadow
> channel instead.
>
> In particular, that setup allows you to splice funds into or out of the
> shadow channel while retaining the positive longevity heuristics of the
> public channel.

Requires two UTXOs, though, I think?

How about just adding a gossip message "this new short-channel-id is the same as this old short-channel-id, use the new-short-channel-id to validate it but treat the age as that of the old short-channel-id"?

Regards,
ZmnSCPxj

📅 Original date posted:2021-10-08 📝 Original message: Good ...

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

In reply to nevent1q…tlca
_________________________

📅 Original date posted:2021-10-08
📝 Original message:
Good morning aj,

> In order to transition from BOLT#3 format to this proposal, an onchain
> transaction is required, as the "revocable signatures" arrangement cannot
> be mimicked via the existing 2-of-2 CHECKMULTISIG output.

A transaction is required, but I believe it is not necessary to put it *onchain* (at the cost of implementation complexity in the drop-onchain case).

An existing channel can "simply" sign a transitioning transaction from the current BOLT3 to your new scheme, and then invalidate the last valid commitment transactions (i.e. exchange revocation secrets) in the BOLT3 scheme.
The transitioning transaction can simply be kept offchain and its output used as the funding outpoint of all "internal" (to the two counterparties directly in the channel) states.

This general idea would work for all transitions *from* Poon-Dryja, I believe.
It may be possible with Decker-Russell-Osuntokun I think (give the transitioning transaction the next sequence `nLockTime` number), but the `SIGHASH_NOINPUT`ness and (maybe?) the `CSV` infects the mechanism being transitioned to, so this technique may be too complicated for transitioning *from* Decker-Russell-Osuntokun to some hypothetical future offchain updatable cryptocurrency system that does not need (or want) `SIGHASH_NOINPUT`.

This has the advantage of maintaining the historical longevity of the channel.
Many pathfinding and autopilot heuristics use channel lifetime as a positive indicator of desirability, thus an *onchain* transitioning transaction is undesirable as that marks a closure of the previous channel.
And the exact scheme of channels between forwarding nodes are not particularly the business of anyone else anyway.

Regards,
ZmnSCPxj

📅 Original date posted:2021-09-21 📝 Original message: Good ...

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

In reply to nevent1q…2dhf
_________________________

📅 Original date posted:2021-09-21
📝 Original message:
Good morning again Joost,

> However, we can do "pay for signature" protocols using PTLCs, and rather than requesting for a scalar behind a point as the proof-of-payment, we can instead ask for a signature of a message that attests "this recipient got paid `payment_amount` with `encoded_order_details`" and have a recipient pubkey (not necessarily the node key, it might be best to reduce signing for node keys) as the signing key.
>
> So it seems to me that this cannot work with hashes, but can work with PTLCs if we use pay-for-signature and the proof-of-payment is a signature rather than a scalar.

No, it does not work either.

The reason is that for signing, we need an `R` as well.
Typically, this is a transient keypair generated by the signer as `r = rand(); R = r * G`.

In order to set up a pay-for-signature, the sender needs to know an `R` from the recipient, and the recipient, being the signer, has to generate that `R` for itself.
And if you are just going to do something like sender->request->receiver, receiver->R->sender, and *then* do the sender->PTLC->receiver, then you might as well just do sender->request->receiver, receiver->invoice->sender, sender->PTLC->receiver.

I think your goal, as I understand it, is to reduce it to one round, i.e. sender->PTLC+some_data->receiver, then receiver responds to the PTLC that somehow generates the proof-of-payment.
Is my understanding correct?

We cannot have the sender generate the `r` and `R = r * G` as knowledge of `r`, `s` and the signed message `m` results in learning the privkey `a`:

s = r - a * h(R | m)
a = (r - s) / h(R | m)

Even with MuSig2 we need a separate round for `R` establishment before the round where everyone gives shares of `s`, and one can argue that a proof-of-payment, being an agreement of the sender and a receiver, is semantically equivalent to a 2-of-2 signature of both sender and the receiver signing off on the fact that the payment happened.
Thus, it seems to me that we can adapt any *secure* single-round multisignature Schnorr scheme to this problem of needing a single-round pay-for-signature.

Perhaps another mechanism?
WARNING: THIS IS NOVEL CRYPTOGRAPHY I THOUGHT UP IN FIVE MINUTES AND I AM NOT A CRYPTOGRAPHER, DO NOT ROLL YOUR OWN CRYPTO.

Instead of having a single receiver-scalar, the receiver knows two scalars.

A = a * G
B = b * G

The sender knows both `A` and `B`.

Now, suppose sender wants to make a payment to the receiver.
At its simplest, the sender can simply add `A + B` and lock an outgoing PTLC to that point.
The proof-of-payment is the sum `a + b`, but knowledge of this sum does not imply knowledge of either `a` or `b` (I THINK --- I AM NOT A CRYPTOGRAPHER).

Now, suppose we want a proof-of-payment to be keyed to some data.
We can translate that data to a scalar (e.g. just hash it) and call it `d`.
Then the sender makes a payment to the receiver using this point:

d * A + B

The sender then receives the scalar behind the above point:

d * a + b

Even with knowledge of `d`, the sender cannot learn either `a` or `b` and thus cannot synthesize any other proof-of-payment with a different `d`, thus "locking" the proof-of-payment to a specific `d`.

The above proof-of-payment is sufficient by showing the point `d * A + B`, the committed data `d`, and the receiver public keys `A` and `B`.

AGAIN THIS IS NOVEL CRYPTOGRAPHY I THOUGHT UP IN FIVE MINUTES AND I AM NOT A CRYPTOGRAPHER, THIS NEEDS ACTUAL MATHEMATICAL REVIEW FROM AN ACTUAL CRYPTOGRAPHER.

Regards,
ZmnSCPxj

📅 Original date posted:2021-09-21 📝 Original message: Good ...

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

In reply to nevent1q…m7q5
_________________________

📅 Original date posted:2021-09-21
📝 Original message:
Good morning Joost,

> It could be something like this:
>
> payment_secret = random
> preimage = H(node_secret | payment_secret | payment_amount | encoded_order_details)
> invoice_hash = H(preimage)
>
> The sender sends an htlc locked to invoice_hash for payment_amount and passes along payment_secret and encoded_order_details in a custom tlv record.
>
> When the recipient receives the htlc, they reconstruct the preimage according to the formula above. At this point, all data is available to do so. When H(preimage) indeed matches the htlc hash, they can settle the payment knowing that this is an order that they committed to earlier. Settling could be implemented as a just-in-time inserted invoice to keep the diff small.
>
> The preimage is returned to the sender and serves as a proof of payment.

Does this actually work?
How does the sender know the `invoice_hash` to lock the HTLC(s) to?

If the sender does not know the `node_secret` (from its name, I am guessing it is a secret known only by the recipient?) then it cannot compute `invoice_hash`, the `invoice_hash` has to be somehow learned by the sender from the recipient.

And that is done in the BOLT12 protocol by having the sender send a message to the recipient and getting a reply back, included in the reply is a unique BOLT11 invoice for a single intended payment.

Note that even using point shenanigans and PTLCs seems not to work.
If you provide, say, a BIP32 nonhardened point / master pubkey, the sender could select an arbitrary `i` and ask for the scalar / privkey behind it, but that also lets the sender derive the master privete key used in the derivation.
Hardening the derivation would prevent master public keys from being used in derivations in the first place.

However, we can do "pay for signature" protocols using PTLCs, and rather than requesting for a scalar behind a point as the proof-of-payment, we can instead ask for a signature of a message that attests "this recipient got paid `payment_amount` with `encoded_order_details`" and have a recipient pubkey (not necessarily the node key, it might be best to reduce signing for node keys) as the signing key.

So it seems to me that this cannot work with hashes, but *can* work with PTLCs if we use pay-for-signature and the proof-of-payment is a signature rather than a scalar.

Regards,
ZmnSCPxj

📅 Original date posted:2021-09-21 📝 Original message: Good ...

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

In reply to nevent1q…jjs2
_________________________

📅 Original date posted:2021-09-21
📝 Original message:
Good morning Joost,

> > > preimage = H(node_secret | payment_secret | payment_amount | encoded_order_details)
> > > invoice_hash = H(preimage)
> > >
> > > The sender sends an htlc locked to invoice_hash for payment_amount and passes along payment_secret and encoded_order_details in a custom tlv record.
> > >
> > > When the recipient receives the htlc, they reconstruct the preimage according to the formula above. At this point, all data is available to do so. When H(preimage) indeed matches the htlc hash, they can settle the payment knowing that this is an order that they committed to earlier. Settling could be implemented as a just-in-time inserted invoice to keep the diff small.
> > >
> > > The preimage is returned to the sender and serves as a proof of payment.
> >
> > Does this actually work?
> > How does the sender know the `invoice_hash` to lock the HTLC(s) to?
>
> > If the sender does not know the `node_secret` (from its name, I am guessing it is a secret known only by the recipient?) then it cannot compute `invoice_hash`, the `invoice_hash` has to be somehow learned by the sender from the recipient.
>
> So to be clear: this isn't a spontaneous payment protocol with proof-of-payment. The sender will still request an invoice from the recipient via an ordinary http request (think of a paywall with qr invoice that is presented when web-browsing to a paid article). That is also how the sender learns the invoice_hash. It is part of the bolt11 payment request as it always is.
>
> The goal of the scheme is to alleviate the recipient from storing the invoices that they generate.

Ah, thanks for the clarification.
This should probably work, then.

Regards,
ZmnSCPxj

📅 Original date posted:2021-08-23 📝 Original message: Good ...

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

In reply to nevent1q…z9ut
_________________________

📅 Original date posted:2021-08-23
📝 Original message:
Good morning Stefan,

> Hi Zmn! That is some amazing lateral thinking you have been applying there. I'm quite certain I haven't understood everything fully, but it has been highly entertaining to read. Will have to give it a closer read when I get some time.
>
> As a first impression, here are some preliminary observations: While I highly like the Haskell-style datatype, and the algorithm we use does mostly use Dijkstra pathfinding, I think what is really important in your definition is the computeCost definition. This is what we would call the cost function IIUC, and in order to be able to solve min-cost flow problems it generally has to be separable and convex. I believe your datatype merely hides the fact that it is neither.

Well, it really depends on what min flow cost algorithms actually assume of the "numbers" being used.

For instance, it is well known that the Dijkstra-A\*-Greedy family of algorithms do not handle "negative costs".
What it really means is that the algorithms assume:

a + b >= a
a + b >= b

This holds if `a` and `b` are naturals (0 or positive), but not if they are integers.
1 + -1 = 0, and 0 >= 1 is not true, thus the type for costs in those algorithms cannot be integer types, they have to be naturals.
However if you restrict the type to naturals, `a + b >= a` holds, and thus Dijkstra and its family of algorithms work.

Thus, if you are going to use Dijkstra-A\*-Greedy, you "only" need to have the following "operations":

`+` :: Cost -> Cost -> Cost
`<` :: Cost -> Cost -> Bool
zero :: Cost

With the following derived operations:

a > b = b < a
a >= b = not (a < b)
a <= b = not (b < a)
a == b = (a >= b) && (a <= b)
a /= b = (a < b) || (a > b)

And following the laws:

forall (a :: Cost) => a + zero == a
forall (a :: Cost) => zero + a == a
forall (a :: Cost, b :: Cost) => a + b == b + a
forall (a :: Cost, b :: Cost, c :: Cost) => (a + b) + c == a + (b + c)
forall (a :: Cost, b :: Cost) => a + b >= a
forall (a :: Cost, b :: Cost) => a + b >= b

As a non-mathist I have no idea what "separable" and "convex" actually mean.
Basic search for "convex" and "concave" tends to show up information in geometry, which I think is not related (though it is possible there is some extension of the geometric concept to pure number theory?).
And definitions on "separable" are not understandable by me, either.

What exactly are the operations involved, and what are the laws those operations must follow, for the data type to be "separable" and "convex" (vs."concave")?

I guess my problem as well is that I cannot find easy-to-understand algorithms for min cost flow --- I can find discussions on the min cost flow "problem", and some allusions to solutions to that problem, but once I try looking into algorithms it gets quite a bit more complicated.

Basically: do I need these operations?

`*` :: Cost -> Cost -> Cost
`/` :: Cost -> Cost -> Cost --- or Maybe Cost

If not, then why cannot `type Cost = UnifiedCost`?

For example, this page: https://www.topcoder.com/thrive/articles/Minimum%20Cost%20Flow%20Part%20Two:%20Algorithms

Includes this pseudocode:

Transform network G by adding source and sink
Initial flow x is zero
while ( Gx contains a path from s to t ) do
Find any shortest path P from s to t
Augment current flow x along P
update Gx

If "find any shortest path" is implemented using Dijkstra-A\*-Greedy, then that does not require `Cost` to be an actual numeric type, they just require a type that provides `+`, `<`, and `zero`, all of which follow the laws I pointed out, *and no more than those*.
`UnifiedCost` follows those laws (tough note that my definition of `zero` has a bug, `successProbability` should be `1.0` not `0`).

In short --- the output of the cost function is a `UnifiedCost` structure and ***not*** a number (in the traditional sense).

Basically, I am deconstructing numbers here and trying to figure out what makes them tick, and seeing if I can use a different type to provide the "tick".

Regards,
ZmnSCPxj

📅 Original date posted:2021-08-21 📝 Original message: > ...

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

In reply to nevent1q…0ddc
_________________________

📅 Original date posted:2021-08-21
📝 Original message:
> Alternative Pathfinding?
> ========================

Or to put this section more succinctly: Why should cost be a number?

What operations do the minimum cost flow algorithms demand of this thing called "cost", and can we provide those operations using something which is not a number but is instead a different structure?
What is the minimal interface that the mincostflow algo demands of this "cost" datatype?

Regards,
ZmnSCPxj

📅 Original date posted:2021-08-20 📝 Original message: ...

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

In reply to nevent1q…6avz
_________________________

📅 Original date posted:2021-08-20
📝 Original message:
Subject: Fee Budgets: A Possible Path Towards Unified Cost Functions For Lightning Pathfinding Problems

Introduction
============

What is the cost of a failed LN payment?

Presumably, if a user wants to pay in exchange for something,
that user values that thing higher than the Bitcoin they spend
on that thing.
This is a central assumption of free market economics, that
all transactions are voluntary and that all participants in
the transaction get more utility out of the transaction than
what they put in.

Note that ***value is subjective***.
For example, a farmer values the food they sell less than
the buyer of that food, because the farmer has leet farming
skillz that actually let them **grow food** from literal shit,
sunlight, and water, and presumably the buyer does not have
those leet skillz0rs to convert literal shit to food
using sunlight and water (otherwise they would be growing
their own food).
This applies for all production, given that you puny humans
have such limited time to learn and train leet skillz.

Thus, for a buyer, there is a difference in value between
the product they are buying, and the BTC they are sacrificing
to the elder gods (i.e. the payment network and the seller) in
order to get the product.
The buyer must value the product more than the BTC.

This difference, then, is the cost of a failed payment.
If the attempt to pay fails, then obviously the seller
will not be willing to send the product (as it can receive
no money for it) and the buyer loses the (buyer-subjective)
value of the product minus the value of the BTC they wanted
to use to pay.

This difference in value, while subjective, is quantifiable
(consider how judges at a beauty contest must convert
their subjective judgment of beauty to a number; indeed,
horny humans do this all the time at bars, suggesting that
even judgment-impaired humans intuitively understand that
subjective values can be quantified).
And that quantifiable subjective value can be measured in
units of bitcoin.

Thus, this difference in value is the cost of failure of an
LN payment.
And due to the relationship of failure and success, the
cost of failure is the value of success.

Pickhardt-Richter Payments
==========================

Why is the cost of failure/value of success even relevant?

In [a 2021 paper](https://arxiv.org/abs/2107.05322)
Pickhardt and Richter present a method of estimating
the probability of payment success, and using that
probability-of-success as a cost function for a
generalization of pathfinding algorithms (specifically
minimum cost flow).

Of course, probabilities of success are not the only
concern that actual pathfinding algorithms need to
worry about.
Another two concerns are:

* Actual fees (measured in bitcoin units).
* Actual total cltv-delta (measured in blocks).

It is possible to convert total cltv-delta to a "Fee".
Basically, the cost of the total cltv-delta is the value
of your funds being locked and unuseable for that many
blocks.
This can be represented as an expected annual return on
investment if those funds were instead locked into some
investment.
In C-Lightning this is the `riskfactor` parameter.

This implies that total cltv-delta can be converted
to an equivalent amount of BTCs.

Now, the issue is, how can we convert probability of
success to some equivalent amount of BTCs?

This is why the value of success --- i.e. the cost
of payment failure --- is relevant.

By multiplying the cost of failure by the probability
of failure, we can acquire a bitcoins-measured
quantity that can be added directly to expected fees.

Fee Budgets
===========

Long ago, some weird rando with an unpronouncable name
decided to add a "fee budget" to his implementation of
C-Lightning pay algorithm (back when C-Lightning did not
even have a `pay` algorithm).
For some reason (possibly dark ritual), that rando managed
to get that code into the actual C-Lightning, and the
fee budget --- known as `maxfeepercent` --- has been
retained to this day, even though none of the original
code has survived (dark rituals tend to consume anything
involved in their rites, I would not be surprised if
that includes source code).

Now consider --- how would a buyer assign a fee budget
for a particular payment?

As we noted, a rational buyer will only buy if they
believe the value of the product being bought is higher
than the value of the BTCs they sacrifice to buy that
product.
This difference is the cost of failure (equivalent to
value of success).

And a rational buyer will be willing to pay, as fee,
any value up to this cost of failure/value of success.

For example, if the buyer is not willing to pay more
than half the cost of failure, then if there is no
way to succeed payments at half the cost of failure,
then the payment simply fails and the buyer loses
the entire cost of failure.
Logically, the buyer must be willing to pay, as
fees, up to the cost of failure.

Similarly, if the buyer is willing to pay up to twice
the cost of failure, then if it succeeds only by
paying up to twice the cost of failure, even if the
payment pushes through and the buyer gets the product,
the buyer still lost the cost of failure because it
paid more fees than the value of the payment success
was.

Logically, then, the buyer must specify as fee budget,
its expected value from acquiring the product minus
the price of the product.

Thus, it so happens that the fee budget is, in fact,
the value of payment success/cost of payment failure,
subjectively determined by the payer, quantified, and
provided to the C-Lightning payment algorithm!

Unified Cost Function
=====================

The cost of failure is then:

fee_budget * (1 - success_probability)

The `fee_budget` is the above fee budget, an input
from the user.
`success_probability` is the estimate as determined
using the Pickhardt-Richter algorithm.

The cost of a channel that charges `fee` is:

fee + fee_budget * (1 - success_probability)

However, we should note that the above cost function
is really the expected cost for the *entire
payment*.
In particular, `success_probability` is multiplicative
along a path, whereas `fee` is additive.

When we consider multipath payments, we should also
observe that the `success_probability` of each
sub-payment are multiplied together (since all
sub-payments must succeed) while `fee` is again
additive in nature.

Because of this, there is probably no *existing*
pathfinding algorithm which can actually *use*
this cost function.
Every pathfinding algorithm uses addition
to compute total costs.

The Pickhardt-Richter paper gets around this by
using the logarithm of the probability.
As addition of logarithms is equivalent to
multiplication (`log A + log B = log (A * B)`),
this converts the addition operations of
existing pathfinding algos to multiplication of the
probabilities.

This technique cannot work with the above unified
cost function, unfortunately.

However, we can consider that, if we neglect
`fee`, and use only the logarithms of the cost
function, then the `fee_budget` term is
effectively a constant cost for all channels on
the network.
That is, `log (fee_budget * success_probability) =
log fee_budget + log success_probability`
for all channels on the network, and we can
subtract `log fee_budget` on all channels
without changing the result of any pathfinding
algorithms (provided we do not get into zero or
negative costs).
Thus, this instance of the Pickhard-Richter
technique is equivalent to neglecting both the
`fee` and the `fee_budget` in our unified cost
function.

Generalized `#zerobasefee`
==========================

If `fee` is small compared to `fee_budget`, then
we can consider the effect of the `fee` term to
be negligible compared to `fee_budget` term.

Here is how the above cost function looks like,
with `fee_budget` distributed:

fee + fee_budget - fee_budget * success_probability

If `fee_budget` is very much higher than `fee`
then we can neglect `fee` as an approximation.

fee_budget - fee_budget * success_probability

Since `fee_budget` is constant for all paths and
for all channels, we can just use the negative
logarithm of `success_probability` as the cost
function.

As a heuristic, we can *ignore* fees and
just use nagetive log probability, as suggested
in the Pickhardt-Richter paper, *after* pruning
channels whose fees are very high (i.e. prune
channels whose `fee`, say, exceeds 1% of the
`fee_budget`).

One way to view `#zerobasefee` is that this is
a specialized instance of the above general
heuristic, that we can prune channels with
non-zero base fees in order to operate a
pathfinding algorithm that uses only addition
for edge costs and use negative log probability
for edge costs.

We can instead consider that *small enough*
base fees, which are negligible compared to
the `fee_budget`, should not be pruned, and
not specifically that all non-zero base fees
should be pruned.
That is, `#zerobasefee` assumes that a 1-sat
base fee is *not* negligible compared to the
`fee_budget`.

However, for large enough payments, the
`fee_budget` may be large enough that a 1
satoshi base fee is actually negligible
compared to the `fee_budget` term.
This implies that `#zerobasefee` is a
specific heuristic, one that potentially
could be generalized.

As a corollary, the higher `success_probability`
is, the more small fees matter (since
`success_probability` subtracts from `fee_budget`).
And higher `success_probability` arises from
larger channels in general.
This leads to the counterintuition that
larger channels should charge lower fees,
since logically the `#lowbasefee` pruning level
should be lower at higher `success_probability`.

Alternative Pathfinding?
========================

As noted, practically every pathfinding algorithm
assumes that costs along every edge are always
added together.

For quantities that must be multiplied --- such
as probabilities --- we can use the logarithm
trick to convert the addition to a multiplication.

However, as noted, the unified cost function
has quantities that, in order to combine, must
be added (fees) and multiplied (probabilities).

In essence, every pathfinding algorithm cannot
use this unified cost function, as they assume
cost functions that are trivially monoid.

Or is it?

For something like the family of pathfinding
algorithms Greedy, A\*, and Dijkstra, the only
operations needed on costs are:

* Addition (actually, a monoidal operation).
* Comparison.

Rather than "add", perhaps a better term
would be to "aggregate" the costs.

class (Monoid type) where
zero :: type
`<*>` :: type -> type -> type
-- laws where
-- forall (a :: type) => zero <*> a = a
-- forall (a :: type) => a <*> zero = a
-- forall (a :: type, b :: type) => a <*> b = b <*> a
-- forall (a :: type, b :: type, c :: type) => (a <*> b) <*> c = a <*> (b <*> c)

In the above, `<*>` is an "aggregate" operation
that replaces the simple addition `+` traditionally
used in pathfinding algorithms.
For typical numeric types, for example, you could
derive an addition monoid or a multiplication
monoid.

We can consider a type that is both `Monoid`
and `Ord`:

-- This will be defined by an actual run of the
-- pathfinding algorithm.
feeBudget :: Integer
feeBudget = undefined

data UnifiedCost = UnifiedCost { fee :: Integer
, successProbability :: Rational
}

-- addition
instance (Monoid UnifiedCost) where
zero = UnifiedCost { fee = 0
, successProbability = 0
}
a <*> b = UnifiedCost { fee = fee a + fee b
, successProbability = successProbability a
* successProbability b
}

-- comparison
computeCost :: UnifiedCost -> Rational
computeCost c = toRational (fee c)
+ ( toRational feeBudget
* (1.0 - successProbability c))
instance (Eq UnifiedCost) where
a == b = computeCost a == computeCost b
instance (Ord UnifiedCost) where
compare a b = compare (computeCost a) (computeCost b)

-- laws where
-- forall (a :: UnifiedCost, b :: UnifiedCost) => a <*> b >= a
-- forall (a :: UnifiedCost, b :: UnifiedCost) => a <*> b >= b
-- -- laws could be checked with QuickCheck
-- -- though we should ensure `0 <= successProbability <= 1`

That type would work well to replace the type of the
cost in the Dijkstra-A\*-Greedy family of algortihms;
they only need comparison and a monoid operation, but
the actual structure of the cost type is immaterial
to the algorithm.

In particular, `feeBudget` is constant for an entire
run of pathfinding algorithms.

The question is whether minimum cost flow algos
could work with the above limited type.
I probably need to go actually study those algos.

📅 Original date posted:2021-08-16 📝 Original message: Good ...

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

In reply to nevent1q…payt
_________________________

📅 Original date posted:2021-08-16
📝 Original message:
Good morning Stefan,

> >I propose that the algorithm be modified >as such, that is, it *ignore* the fee scheme.
>
> We actually started out thinking like this in the event we couldn't find a proper way to handle fees, and the real world experiments we've done so far have only involved probability costs, no fees at all.
>
> However, I think it is non-trivial to deal with the many cases in which too high fees could occur, and in the end the most systematic way of dealing with them is actually including them in the cost function.

A reason why I suggest this is that the cost function in actual implementation is *already* IMO overloaded.

In particular, actual implementations will have some kind of conversion between cltv-delta and fees-at-node.

This conversion implies some kind of "conversion rate" between blocks-locked-up and fees-at-node.
For example, in C-Lightning this is the `riskfactor` argument to `getroute`, which is also exposed at `pay`.

However, I think that in practice, most users cannot intuitively understand `riskfactor`.
I myself cannot; when I write my own `pay` (e.g. in CLBOSS) I just start `riskfactor` to the in-manual default value, then tweak it higher if the total lockup time exceeds some maximum cltv budget for the payment and call `getroute` again.

Similarly, I think it is easier for users to think in terms of "fee budget" instead.

Of course, algorithms should try to keep costs as low as possible, if there are two alternate payment plans that are both below the fee budget, the one with lower actual fee is still preferred.
But perhaps we should focus more on payment success *within some fee and timelock budget*.

Indeed, as you point out, your real-world experiments you have done have involved only probability as cost.
However, by the paper you claim to have sent 40,000,000,000msat for a cost of 814,000msat, or 0.002035% fee percentage, far below the 0.5% default `maxfeepercent` we have, which I think is fairly reasonable argument for "let us ignore fees and timelocks unless it hits the budget".
(on the other hand, those numbers come from a section labelled "Simulation", so that may not reflect the real world experiments you had --- what numbers did you get for those?)

>
> That said, I agree with Matt that more research needs to be done about the effect of base fees on these computations. We do know they make the problem hard in general, but we might find a way to deal with them reasonably in practice.

Is my suggestion not reasonable in practice?
Is the algorithm runtime too high?

>
> I tend to agree with AJ, that I don't believe the base fee is economically helpful, but I also think that the market will decide that rather than the devs (though I would argue for default Zerobasefee in the implementations).
>
> In my view, nobody is really earning any money with the base fee, so the discussion is kind of artificial. On the other hand, I would estimate our approach should lead to liquidity being priced correctly in the proportional fee instead of the price being undercut by hobbyists as is the case now. So in the long run I expect our routing method to make running a well-stocked LN router much more profitable.

While we certainly need to defer to economic requirements, we *also* need to defer to engineering requirements (else Lightning cannot be implemented in practice, so any economic benefits it might provide are not achievable anyway).
As I understand the argument of Matt, we may encounter an engineering reason to charge some base fee (or something very much like it), so encouraging #zerobasefee *now* might not be the wisest course of action, as a future engineering problem may need to be solved with non-zero basefee (or something very much like it).

Regards,
ZmnSCPxj

📅 Original date posted:2021-08-16 📝 Original message: Good ...

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

In reply to nevent1q…0g2d
_________________________

📅 Original date posted:2021-08-16
📝 Original message:
Good morning matt and aj,

Let me cut in here.

>From my reading of the actual paper --- which could be a massive misunderstanding, as I can barely understand half the notation, I am more a dabbler in software engineering than a mathist --- it seems to me that it would be possible to replace the cost function in the planning algorithm with *only* the negative-log-probability, which I think is the key point of the paper.

That is, the algorithm can be run in a mode where it *ignores* whatever fee scheme forwarding nodes desire.
(@rene: correct me if I am wrong?)

I propose that the algorithm be modified as such, that is, it *ignore* the fee scheme.

However, the algorithm then gets an extra step after getting a payment plan (i.e. how to route multiple sub-payments).
It looks over the payment plan and if the fees involved are beyond some user-defined limit (with, say, a default of 0.5% of the total amount, as per the C-Lightning `pay` default), to look at the highest-fee channels in the payment plan.
Then, it can rerun the flow algorithm, telling it to *disallow* the highest-fee channels identified if the total fees exceed the fee budget.

It seems to me that this modification of the algorithm may be sufficient to be resilient against any and all future fee scheme we may decide for Lightning.

This still achieves "optimality" in the sense of the paper, in a way similar to what is suggested in the paper.
The paper suggests to basically ignore gossiped channels with non-zero basefee.
The approach I suggest allows us to *start* without ignoring non-zero basefee, but to slowly degrade our view of the network by disallowing high-fee (whether high basefee or high propfee) channels.

Regards,
ZmnSCPxj

📅 Original date posted:2021-08-15 📝 Original message: Good ...

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

In reply to nevent1q…7d5x
_________________________

📅 Original date posted:2021-08-15
📝 Original message:
Good morning lisa, aj, et al.,

> The result is that micropayments have a different payment regime than “non-micropayments”, (which may still incentive almost irrational behavior) but at least there’s no *loss* felt by node operators for handling/supporting low value payments. 10k micropayments is worth 10sats.
>
> It’s also simple to implement and seems rather obvious in retrospect.

It seems simple to implement for *forwarders*, but I think complicates the algorithm described by Pickhardt and Richter?

On the other hand, the algorithm is targeted towards "large" payments, so perhaps the Pickhardt-Richter payment algo can be forced to have some minimum split size, and payments below this minimum size are just sent as single payments (on the assumption that such micropayments are so small that the probability of failure is negligible).
That is, just have the `pay` command branch based on the payment size, if it is below the minimum size, just use the old try-and-try-until-you-die algo, otherwise use a variant on the Pickhardt-Richter algo that respects this minimum payment size.
This somewhat implies a minimum on the possible feerate, which we could say is 1 ppm, maybe.

So for example, the minimum size could be 1,000,000msat, or 1,000sat.
If the payment is much larger than that, use the Pickhardt-Richter algorithm with zerobasefee.
If payment is lower than that threshold, just do not split and do try-and-try-until-you-die.

Regards,
ZmnSCPxj

📅 Original date posted:2021-08-15 📝 Original message: Good ...

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

In reply to nevent1q…utum
_________________________

📅 Original date posted:2021-08-15
📝 Original message:
Good morning aj, et al.

> Hey *,
>
> There's been discussions on twitter and elsewhere advocating for
> setting the BOLT#7 fee_base_msat value [0] to zero. I'm just writing
> this to summarise my understanding in a place that's able to easily be
> referenced later.
>
> Setting the base fee to zero has a couple of benefits:
>
> - it means you only have one value to optimise when trying to collect
> the most fees, and one-dimensional optimisation problems are
> obviously easier to write code for than two-dimensional optimisation
> problems

Indeed, this is a good point regarding this.

> - when finding a route, if all the fees on all the channels are
> proportional only, you'll never have to worry about paying more fees
> just as a result of splitting a payment; that makes routing easier
> (see [1])

If we neglect roundoff errors.

On the other hand, roundoff errors involved are <1msat per split, so it probably will not matter to most people.

> So what's the cost? The cost is that there's no longer a fixed minimum
> fee -- so if you try sending a 1sat payment you'll pay 0.1% of the fee
> to send a 1000sat payment, and there may be fixed costs that you have
> in routing payments that you'd like to be compensated for (eg, the
> computational work to update channel state, the bandwith to forward the
> tx, or the opportunity cost for not being able to accept another htlc if
> you've hit your max htlcs per channel limit).
>
> But there's no need to explicitly separate those costs the way we do
> now; instead of charging 1sat base fee and 0.02% proportional fee,
> you can instead just set the 0.02% proportional fee and have a minimum
> payment size of 5000 sats (htlc_minimum_msat=5e6, ~$2), since 0.02%
> of that is 1sat. Nobody will be asking you to route without offering a
> fee of at least 1sat, but all the optimisation steps are easier.

Should this minimum a node will be willing to forward be part of gossip, and how does this affect routing algorithms?

> You could go a step further, and have the node side accept smaller
> payments despite the htlc minimum setting: eg, accept a 3000 sat payment
> provided it pays the same fee that a 5000 sat payment would have. That is,
> treat the setting as minimum_fee=1sat, rather than minimum_amount=5000sat;
> so the advertised value is just calculated from the real settings,
> and that nodes that want to send very small values despite having to
> pay high rates can just invert the calculation.

I like this idea, as I think it matches more what the incentives are.
But it requires a change in gossip and in routing algorithms, and more importantly it requires routing algorithms to support two different fee schemes (base + proportional vs min + proportional).

On the other hand, this still is a two-dimensional optimization algorithm, with `minimum_fee` and `proportional_fee_millionths` as the two dimensions.
So maybe just have a single proportional-fee mechanism...

>
> I think something like this approach also makes sense when your channel
> becomes overloaded; eg if you have x HTLC slots available, and y channel
> capacity available, setting a minimum payment size of something like
> y/2/x**2 allows you to accept small payments (good for the network)
> when you're channel is not busy, but reserves the last slots for larger
> payments so that you don't end up missing out on profits because you
> ran out of capacity due to low value spam.
>
> Two other aspects related to this:
>
> At present, I think all the fixed costs are also incurred even when
> a htlc fails, so until we have some way of charging failing txs for
> incurring those costs, it seems a bit backwards to penalise successful
> txs who at least pay a proportional fee for the same thing. Until we've
> got a way of handling that, having zero base fee seems at least fair.

Yes, the dreaded mechanism against payment lockup, which as far as I understand has a lot of thought already sunk into it without any widely-accepted solution, sigh.

Regards,
ZmnSCPxj

📅 Original date posted:2021-08-14 📝 Original message: Good ...

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

In reply to nevent1q…ef99
_________________________

📅 Original date posted:2021-08-14
📝 Original message:
Good morning Daki,

While certainly a very imaginative approach to the problem, do note that there is a substantive difference between running a Bitcoin fullnode and running a Lightning forwarding node.

Namely:

* A Bitcoin fullnode does not risk any lockup of its funds just to run.
* A Lightning forwarding node *does* risk having its funds locked and unavailable.

While a payment is being forwarded, the funds involved in the forwarding are unavailable for use by the putative owner of the funds.
Instead, the funds are kept in an HTLC until the payment forwarding is resolved in either success or failure.

Having your funds locked and unavailable to you, even transiently, is only tenable if you get something in return, e.g. a return on investment.

Of course, you can also counter-argue that in practice, the amounts and timeframes are so short that any return on investment would be ridiculously minuscule, which is why in practice most forwarding nodes will earn 0 or even negative net income.
On the other hand, larger hubs with significant liquidity invested into them would still have total amounts and timeframes that *are* substantial enough that it would make sense for them to charge *some* fee.
And discovering that feerate is the point of this exercise.

On the other other hand, this may very well be "trade secret" territory, in which case there is no point in me asking about this topic anyway.

Regards,
ZmnSCPxj

📅 Original date posted:2021-07-27 📝 Original message: Good ...

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

In reply to nevent1q…httu
_________________________

📅 Original date posted:2021-07-27
📝 Original message:
Good morning aj, and list,

> > I don't think you can reliably hide that you forgot some state?

Thinking a little more --- *why* do we need to hide that we forgot some state?

The reason is that if your peer learns you forgot state, the peer can pass off obsolete state onchain, thereby stealing funds from you before you can recover your data.

But if some completely random node that is ***not*** your peer and has ***no*** channels with you is holding your memento, then there is no need to worry --- even if you tell them "actually I forgot my state" they have no obsolete state to hurt you with.

Suppose that nodes provide a "will remember for you" flag in the feature bits.

Now, your node can then use a secret distance measurement --- for example, it could take the keyed hash (with your node privkey as key) of every "will remember for you"-advertising node, then look for the hash that is numerically lowest.

Locating the "nearest" node, your node then contacts that node and asks them to remember our memento.
Now, your node should not be using its "normal" pubkey for this, instead, it should generate a "throwaway" keypair derived from its privkey plus the pubkey of the selected node.

--

After your node hits its head and becomes amnesiac, you provide it with the privkey (which can be represented as some words).

The node then re-downloads gossip map, and uses the same secret distance measurement to find, say, the 100 "nearest" nodes with the "will remember for you" feature.
Assuming the gossip map has not changed too much since before the amnesia event, then it is likely that the previously selected node is still in the nearest 100 nodes.

Your node will then iterate over the nearest 100 nodes, starting with the nearest, and re-derive the "throwaway" keypair and ask each node if it holds a memento for that pubkey.

Since your node contacts them using a throwaway keypair that is not correlatable with your normal node pubkey, even if they are conspiring with your channel peers, the "will remember for you" node cannot identify that your node has suffered amnesia, it only knows that *some* node *somewhere* suffered amnesia.

This implies as well that the selected node can even be your peer, and it will still not be sure that the amnesiac node is you or might be somebody else completely.

--

Of course, the anonymous nature of the client requesting data storage is a problem, as this feature is now vulnerable to abuse and DDoS.
As a spam prevention, such a "will remember for you" node can use any number of techniques developed for anonymously paying to watchtowers, which have a similar "need to pay for anonymous storage to prevent DoS" problem.

Regards,
ZmnSCPxj

📅 Original date posted:2021-07-27 📝 Original message: Good ...

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

In reply to nevent1q…xjjt
_________________________

📅 Original date posted:2021-07-27
📝 Original message:
Good morning cdecker, aj, and list,

> . In addition we can store the same data with multiple peers, ensuring that as long as one node is behaving we're good.

Depending on size limits of the stored data, it may be possible to use some kind of erasure coding so that at least k of n peers need to be honest so we are good.
I suspect peers would prefer to limit the amount of data they have to store, if they offer this feature, so use of erausre coding seems to be a good idea.

However, since the peer does not know the data you are storing, this detail can be known only by the node saving its data with the peer, so not need to put in specifications.

> I don't think you can reliably hide that you forgot some state? If you
> _did_ forget your state, you'll have forgotten their latest bundle too,
> and it seems like there's at least a 50/50 chance you'd have to send
> them their bundle before they sent you yours?

This objection seems quite correct.

Perhaps it is possible to (mis)use Barrier Escrow: https://suredbits.com/payment-points-implementing-barrier-escrows/
After all, what is needed is a simultaneous way for both sides to provide the data (or admit they lost it) before the other can withhold the data.

1. Both agree on some Barrier Escrow and generate some temporary points.
2. Both sides invoke `barrier-commit` on the Barrier Escrow, receiving E.
3. Both sides *additionally* encrypt the bundle using an asymmetric encryption, which can be decrypted only by anyone who knows `e` such that `E = e * G`.
4. Both sides exchange the asymmetrically-encrypted bundles.
5. Once a side receives the asymmetrically-encrypted bundle from the other side, they invoke `barrier-reveal` using their temporary scalar from #1.
6. When they get `e` from `barrier-reveal` they can decrypt the asymmetric encryption layer from the bundle they receive, then proceed to validate and decrypt the actual encrypted bundle.

If Alice is amnesiac, it just provides a random vector for the "asymmetric encrypted bundle of Bob".

Suppose Bob wants to check if Alice is amnesiac.
Bob cannot delay its send of the Alice-bundle, due to the Barrier Escrow ensuring that both parties have sent *some* bundle.
Thus, even if Bob knows later than Alice has gone amnesiac, by the time Bob knows that, it has handed over the memento of Alice by which Alice can recover.

Bob can send a bogus bundle to Alice, and then if it also receives a bogus bundle, it knows Alice is amnesiac (and it might be a good time to steal from Alice).
ALTERNATELY Alice is *also* trying to probe Bob, so Alice sent a bogus bundle itself.
In that case, Bob could attempt to steal, but runs the risk that Alice was *also* another prober who is not actually amnesiac.
(Not sure if that is valid game theory, though)

On the other hand, Barrier Escrow services have to be paid for their service (else why would they run), and if you have not connected to your peer then you cannot pay for barrier escrow services over Lightning.

Regards,
ZmnSCPxj

📅 Original date posted:2021-06-01 📝 Original message: Good ...

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

In reply to nevent1q…yq3h
_________________________

📅 Original date posted:2021-06-01
📝 Original message:
Good morning LL,

> Hi Z,
>
> I just went through the presentation which made your thinking very clear. Thanks.
> I will not be able to match this effort so please bear with me as I try and explain my own thinking.
> I don't see why fast forwards (FF) need "symmetrically encumbered outputs"? To me the protocol should be asymmetric.
>
> This is what I think happens when offering a FF HTLC:
> 1. The offerer creates and signs a new commitment tx as normal with the HTLC except it has the same revocation key as the last one.
> 2. The offerer patches their balance output by sending a tx spending from it to a new tx which has the HTLC output and their balance output (unencumbered).
>
> The HTLC is now irrevocably committed from the perspective of the receiver.
> Now the receiver presents the pre-image and the offerer then:
>
> 1. The offerer creates and signs a new commitment tx as normal consolidating the funds into the receiver's balance output except once again it has the same revocation key as the last one.
> 2. The offerer patches their commitment tx balance output again by sending a tx spending from it to a new tx which splits into the receiver's balance (the value of the claimed HTLC) and the offerer's remaining balance.
>
> You can repeat the above process without having the receiver's revocation keys online or their commitment tx keys for many HTLCs while the offerer still has balance towards the receiver.
> The on-chain cost is about the same as before for an uncooperative close.
>
> Once the receiver brings their keys on line they can consolidate the FF state into a new commitment txs on both sides and with a proper revocation operate the channel normally. What has been the receiver up until now can finally send funds.
>
> Am I missing something?

Basically, you are taking advantage of the fact that we **actually** let the commitments on both sides be desynchronized with each other.
I tend to elide this fact when explaining, and also avoid it when planning protocols.

However I believe the idea is correct.

Anyway, as I understood it:

So suppose we start with this pair of commitment txes:

+--------------------------+
| Commitment tx 1 of A |
+------------+-------------+
| | (A[0] && B) |
| |||(A && CSV) |
| SigB +-------------+
| | B |
| | |
+------------+-------------+

+--------------------------+
| Commitment tx 1 of B |
+------------+-------------+
| SigA | A |
| | |
| +-------------+
| | (A && B[0]) |
| |||(B && CSV) |
+------------+-------------+

Now Alice wants to offer an HTLC to Bob.
What Alice does is:

* **Retain** the Alice commitment tx and create an HTLC tx spending from it.
* **Advance** the Bob commitment tx (and letting it desync from the Alice commitment tx), adding the same HTLC.

So after Alice sends its new signatures, our offchain txes are:

+--------------------------+ +--------------------------+
| Commitment tx 1 of A | | HTLC Tx |
+------------+-------------+ +------------+-------------+
| | (A[0] && B) |--->| SigA[0] | (A[0] && B) |
| |||(A && CSV) | | |||(A && CSV) |
| SigB +-------------+ | +-------------+
| | B | | | A->B |
| | | | | HTLC |
+------------+-------------+ +------------+-------------+

+--------------------------+
| Commitment tx *2* of B |
+------------+-------------+
| SigA | A |
| | |
| +-------------+
| | (A && B[1]) |
| |||(B && CSV) |
| +-------------+
| | A->B |
| | HTLC |
+------------+-------------+

Notes:

* Again, for Alice to offer the HTLC to Bob, only Alice has to make new signatures (`SigA[0]` and `SigA` for commitment tx *2* of Bob).
* If Alice goes offline and Bob decides to drop onchain, Bob only needs to sign the new commitment tx.
We can argue that dropping channels *should* be rare enough that requiring privkeys for this operation is not a burden.
* If Alice decides to drop the channel onchain, Bob only needs to bring in the privkey for the HTLC tx, which we can (at a lower, detailed level) be different from the "main" B privkey.

So yes, I think it seems workable without symmetric encumbrance.

Regards.
ZmnSCPxj

📅 Original date posted:2021-05-23 📝 Original message: Good ...

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

In reply to nevent1q…z2a4
_________________________

📅 Original date posted:2021-05-23
📝 Original message:
Good morning list,

I have decided to dabble in necromancy, thus, I revive this long-dead thread from two years ago.
Ph34R mE and my leet thread necromancy skillz.

A short while ago, LL and Steve Lee were discussing about ways to reduce the privkey onlineness requirement for Lightning.
And LL mentioned that this proposal could allow privkeys to be kept offline for a receiver.

* The receiver has to be online, still.
* Its privkeys can be kept offline.
* The receiver can still receive even if its privkeys are offline (for example the privkeys are in a hardware signing module that is typically kept offline and is only put online at rare intervals).
* The sender has to be online and the sender privkeys have to be online.
* Forwarders and their privkeys have to be online.

Unfortunately, I think the proposal, as currently made, cannot support the above feature, as stated.

When an HTLC transaction is provided by the sender under a Fast Forward scheme, it provides a transaction that spends from "its" output in both versions of the latest Poon-Dryja commitment transaction.

However, this output, as provided in the Fast Forward scheme, requires *two* signatures.

Here are the scripts mentioned in the previous post:

OP_IF
# Penalty transaction/Fast forward
<local_revokepubkey> OP_CHECKSIGVERIFY <remote_penaltyclaimpubkey>
OP_ELSE
`to_self_delay`
OP_CSV
OP_DROP
<local_delayedpubkey>
OP_ENDIF
OP_CHECKSIG

And:

OP_IF
# Penalty transaction/Fast forward
<local_revokepubkey> OP_CHECKSIGVERIFY <remote_penaltyclaimpubkey>
OP_ELSE
`to_self_delay`
OP_CSV
OP_DROP
<remote_delayedpubkey>
OP_ENDIF
OP_CHECKSIG

Now, the first branch is what is used in the Fast Forward scheme.
And we can see that in the first branch, two signatures are needed: one for local, and one for remote.

Thus, any HTLC-bearing transactions are signed by both the sender and receiver.
Fast Forwards works its low-latency magic by simply having the sender send the signature spending from the current channel state, outright, to the receiver, and until the channel is updated, the HTLC is "safe":

* The current channel state (represented by some commitment tx) cannot be replaced with an alternative, without the replacer risking funds loss (Poon-Dryja punishment mechanism).
* The spending tx that instantiates the HTLC is safe because the receiver will not willingly sign an alternate version.

***HOWEVER***, the HTLC is safe on the assumption that *the receiver can provide its signature* if the channel is dropped onchain.
And channels can be dropped onchain *at any time*.
If the receiver is unable to provide its signature before the `to_self_delay` finishes, then the sender can revoke ***all*** HTLCs it sent!

Thus, at least as initially stated, Fast Forwards cannot be used for this "receiver online, privkeys offline, can receive" feature.

***HOWEVER HOWEVER***, we should note that the caveats are something we can actually work with:

* The privkeys can only be offline for up to `to_self_delay` blocks.
* We ***need*** privkeys to be periodically online more often than `to_self_delay` anyway, ***in case of theft attempts***.
So this is not an ***additional*** requirement at least.
* Watchtowers cannot guard against attempts to steal Fast Forwarded HTLCs --- they need to receive the signatures for the HTLC transactions as well, otherwise they can do nothing about it.
* However, whenever the receiver sends to a watchtower it *does* need to send signatures anyway, so it still needs to get privkeys online for signing.
* Since we need the privkeys to be made online a little more often than every `to_self_delay` blocks anyway, this is *not* an additional requirement!

***THUS***, we *can* provide a tweaked version of the above desired feature:

* The receiver has to be online, still.
* Its privkeys can be kept offline, ***BUT***, it has to be regularly brought online a little more often than `to_self_delay`.
* The receiver can still receive even if its privkeys are offline (for example the privkeys are in a hardware signing module that is typically kept offline and is only put online at rare intervals).
* The sender has to be online and the sender privkeys have to be online.
* Forwarders and their privkeys have to be online.

The additional requirement --- that the receiver privkeys have to be regularly brought online --- is not actually an onerous one *since we need it for channel safety*.

So this feature is indeed supported by Fast Forwards (with fairly minimal caveats!) and kudos to LL for thinking of it!

Against this, we should remind the drawbacks of Fast Forwards:

* Onchain space is much higher (in the unilateral close case only --- channel opens and mutual closes remain small) due to chaining of transactions instead of strict replacement.
* Fast Forwarded HTLCs need to have their signatures stored on replicated storage, and is O(n) (current Poon-Dryja requires O(1) storage for revocation keys but O(n) storage for HTLC hash/timelock details).
If you lose your data storage, you lose received HTLCs, including those whose preimages you have already released.

For this, we should also take note that:

* Payment latency is greatly improved.
* The above "receiver online, receiver privkeys offline, can receive" feature is now possible, with the caveat:
* The privkeys need to be periodically brought online for short amounts of time in order to "collapse" chains of HTLC transactions, recover from theft attempts, and update watchtowers etc.

---

Now, Fast Forwards is a scheme that is designed for a modified form of Poon-Dryja.

Unfortunately, at least for now, it seems the scheme cannot be used in Decker-Russell-Osuntokun ("eltoo").

In particular, Fast Forwards work because it is safe (and even required!) for a Poon-Dryja scheme to impose timeouts on the "main" outputs of a channel.
And those timeouts have a branch that is a 2-of-2 between the channel participants.
That branch is where Fast Forwards hook into.

In Decker-Russell-Osuntokun, the "main" outputs are not encumbered by any timeouts; they are simple singly-signed outputs.
The timeout is instead placed "before" the state transactions that contain the "main" outputs.
The HTLC transactions are not safe without a 2-of-2, as otherwise the sender could just spend the main output to a different address, removing the HTLC.

Because of this, the "main" output of a Decker-Russell-Osuntokun cannot be used in a Fast Forwarded manner, as the Fast Forwarded transaction needs to be signed by both participants.

We *could* add *another* timeout at the main output simply to support Fast Forwards, using a similar "2of2 or OP_CSV+singlesig".
However, this increases the effective delay in the case the channel is dropped unilaterally onchain.

In addition, we should remind that when forwarding, Decker-Russell-Osuntokun requires that the CLTV at a particular hop be larger than the `to_self_delay` at that hop i.e. it imposes a "minimum CLTV" cost that is combined with `max` instead of `+`, which pathfinding algorithms (that I know of) are totally not designed for.

Furthermore, properly designed, a Decker-Russell-Osuntokun construction could also have payment latency approaching the latency of the Fast Forward scheme, so that advantage of Fast Forwards is lost as well, so we are paying for more inconvenience for a smaller feature set (only the "receiver online, privkey offline" feature remains; maybe worth it?).

Of note, is that there also exists a Poon-Dryja variant that has a similar structure to Decker-Russell-Osuntokun (and has the same drawback of requiring a "minimum CLTV" at each hop) --- Fast Forwards would also not work well with that particular Poon-Dryja variant, too.

Regards,
ZmnSCPxj

📅 Original date posted:2021-02-11 📝 Original message: Good ...

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

In reply to nevent1q…4ma8
_________________________

📅 Original date posted:2021-02-11
📝 Original message:
Good morning Pedro,

> Hi Nadav,
>
> You are right that the intermediary (i.e., Ingrid) needs to hold a certain amount of coins to allow the virtual channel between Alice and Bob. Some comments here:
> - The protocol makes sure that Ingrid will get paid whatever fee she decides to charge for the service of creating a virtual channel. Note that Ingrid does not have the guarantee that enough payments would be routed through her node to gain the same fee in the same amount of time.

Have not examined this deeply, but what happens if any of the *actual* Alice-Ingrid or Ingrid-Bob channels are forced unilaterally onchain before the purported lifetime of the virtual channel?

Regards,
ZmnSCPxj

📅 Original date posted:2021-02-11 📝 Original message: Good ...

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

In reply to nevent1q…3uz6
_________________________

📅 Original date posted:2021-02-11
📝 Original message:
Good morning Andres,

> This looks cool but would hinder UX too much for certain scenarios: e.g. if the escrow in place is part of a bitcoin exchange, then you require the bitcoin buyer to have bitcoin already, which makes it harder to on-ramp new users (which could maybe only have fiat). Am I right?

Correct.
Though note that existing systems like Bisq, to my knowledge, have the same problem, a buyer of Bitcoin has to have a small amount of Bitcoin to offer as stake that can be revoked in case they attempt to defraud the counterparty.
Without it, the counterparty takes on increased risk (which translate to larger exchange spread).

In any case, once you have that initial stake, you can then keep increasing your ability to provide stake so as to relieve your counterparties of risk and have them offer better exchange rates, so it is "only" an issue for initial onboarding.
Presumably, in the later stable state, parents will provide children the initial stake needed for them to start transacting over such a system, just as they already provide their children with other "initial stakes" (education, food, shelter, etc.) anyway.

>
> So are you saying that this is not doable without PTLCs (with simple HTLCs) unless it's done like suggested?

Yes, it is yet another reason we want PTLCs quickly.

An alternative would be to have dual-hash HTLCs, which would be helpful in other escrow-related cases including escrow-facilitated cross-currency swaps.

Regards,
ZmnSCPxj

>
> On Thu, 11 Feb 2021 at 14:01, ZmnSCPxj <ZmnSCPxj at protonmail.com> wrote:
>
> > Good morning Nadav and Andres,
> >
> > Thank you for bringing up this topic again.
> >
> > Let me provide a new twist to this old idea.
> >
> > This is the entire logic of the contract to the seller:
> >
> > SELLER && (BUYER || ESCROW)
> >
> > Now, a big issue is that simple `&&` is trivial for PTLCs, it is the `||` which is difficult and requires ECDH and proof that the ECDH was done correctly.
> >
> > But we can observe the De Morgan Theorem:
> >
> > A || B <=> !(!A && !B)
> >
> > So how about we *invert* the logic?
> >
> > So what we do is, we make *two* payments of the same amount:
> >
> > * Seller -> Buyer , claimable by BUYER && ESCROW key.
> > * Buyer -> Seller, claimable by SELLER key.
> >
> > So the ritual is this:
> >
> > * Seller -> Buyer claimable by BUYER && ESCROW.
> > * Buyer -> Seller claimable by SELLER.
> > * Seller hands over item.
> > * Buyer judges whether to accept, or complain to Escrow.
> >
> > Now let us consider our cases:
> >
> > * Buyer is satisfied with the product.
> > * Buyer fails the Seller->Buyer payment after seller claims the Buyer->Seller payment, so Seller is paid and has no more obligations.
> > * Buyer is dissastisfied and wants the Escrow to judge:
> > * Escrow judges Buyer is right: Escrow reveals ESCROW key to Buyer, who then clawbacks the payment to the seller.
> > * Escrow judges Seller is right: Escrow deletes ESCROW privkey ("not ESCROW"), and the Seller->Buyer payment eventually times out, ending the obligation of the Seller.
> >
> > The "reverse" payment is effectively the inversion of logic by the De Morgan theorem, and the "normal case" (buyer ultimately pays seller) has the Escrow not revealing the privkey.
> > In addition, in the case where Buyer is satisfied (i.e. both Buyer and Seller agree the trade is beneficial) the Escrow is never involved (the Escrow might have a timeout for the temporary ESCROW keypair, which it will eventually delete; since all payments on LN need a timeout anyway, this is fine) and thus does not know about the trade, except that some trade was requested (since it must provide a temporary ESCROW pubkey).
> >
> > This even provides a simple BUYER + ESCROW keypair that gives the seller a proof-of-refund, and of course the simple SELLER gives the buyer a proof-of-payment as well.
> > It only just requires twice as much Bitcoins getting locked.
> >
> > Thoughts?
> >
> > Regards,
> > ZmnSCPxj

📅 Original date posted:2021-02-11 📝 Original message: Good ...

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

In reply to nevent1q…vkxq
_________________________

📅 Original date posted:2021-02-11
📝 Original message:
Good morning Nadav and Andres,

Thank you for bringing up this topic again.

Let me provide a new twist to this old idea.

This is the entire logic of the contract to the seller:

SELLER && (BUYER || ESCROW)

Now, a big issue is that simple `&&` is trivial for PTLCs, it is the `||` which is difficult and requires ECDH and proof that the ECDH was done correctly.

But we can observe the De Morgan Theorem:

A || B <=> !(!A && !B)

So how about we *invert* the logic?

So what we do is, we make *two* payments of the same amount:

* Seller -> Buyer , claimable by BUYER && ESCROW key.
* Buyer -> Seller, claimable by SELLER key.

So the ritual is this:

* Seller -> Buyer claimable by BUYER && ESCROW.
* Buyer -> Seller claimable by SELLER.
* Seller hands over item.
* Buyer judges whether to accept, or complain to Escrow.

Now let us consider our cases:

* Buyer is satisfied with the product.
* Buyer fails the Seller->Buyer payment after seller claims the Buyer->Seller payment, so Seller is paid and has no more obligations.
* Buyer is dissastisfied and wants the Escrow to judge:
* Escrow judges Buyer is right: Escrow reveals ESCROW key to Buyer, who then clawbacks the payment to the seller.
* Escrow judges Seller is right: Escrow deletes ESCROW privkey ("not ESCROW"), and the Seller->Buyer payment eventually times out, ending the obligation of the Seller.

The "reverse" payment is effectively the inversion of logic by the De Morgan theorem, and the "normal case" (buyer ultimately pays seller) has the Escrow not revealing the privkey.
In addition, in the case where Buyer is satisfied (i.e. both Buyer and Seller agree the trade is beneficial) the Escrow is never involved (the Escrow might have a timeout for the temporary ESCROW keypair, which it will eventually delete; since all payments on LN need a timeout anyway, this is fine) and thus does not know about the trade, except that some trade was requested (since it must provide a temporary ESCROW pubkey).

This even provides a simple BUYER + ESCROW keypair that gives the seller a proof-of-refund, and of course the simple SELLER gives the buyer a proof-of-payment as well.
It only just requires twice as much Bitcoins getting locked.

Thoughts?

Regards,
ZmnSCPxj

📅 Original date posted:2020-12-16 📝 Original message: Good ...

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

In reply to nevent1q…rf6c
_________________________

📅 Original date posted:2020-12-16
📝 Original message:
Good morning LL,

> > > - What do you do if the channel state has HTLCs in flight? I don't know -- I guess you can just put them onto the settlement tx? That way it's possible the payment could still go through. Alternatively you could just gift the money to the party offering the recovery settlement.
> >
> > Gifting the money is not a good option --- we allow HTLCs to be almost as high as the total channel value minus fees and reserve.
> > Thus all the claimable value could potentially be in an outgoing HTLC.
> > Worse, if our node is a forwarding node, it would be easy for a third party to arrange to have our funds in various HTLCs.
>
> Hopefully this recovery system is used by people whose channels are in
> a HTLC free state 99.9999% of the time (and hopefully hardware
> failures do not somehow coincide with HTLCs!).
> As a user, it would be cool to be able to just lock up all my Bitcoin
> into channels with well-established lightning nodes. That way if fees
> go ballistic I can still move money around cheaply.
> One of the main concerns for this pattern of user behaviour is the
> recovery story I think. The first line of defence for routing nodes
> (people who are taking their role in LN seriously) has to be redundant
> data storage.
> This would be a poor last-resort solution for routing nodes.

A common occurrence is that hardware failure is not detected until when the hardware is used, especially when used by casual users.

Consider the sequence of events:

* Part of the storage device fails.
* Due to being a casual user, the user does not use state-of-the-art checksumming filesystems like ZFS and does not monitor disk health by S.M.A.R.T.
* A high-onchain-fee condition exists.
* The casual user attempts to send out a payment consisting of almost all funds in their LN channels via several HTLCs on MPP or other multipath.
* Because of the activity generated, the filesystem assigns the LN database to the failing part.
* Storage fails with most funds in outgoing HTLCs.

Thus, merely activating the wallet and using HTLCs may result in a *detectable* failure of the hardware (which was already failing before, just not noticed by the casual user).

On the other hand, we can consider this situation as having a complexity penalty.

As someone who has seen a lot of storage devices slowly fail in unique and interesting (and data-losing) ways, I am always going to assume that storage devices are going to fail at any time, including a few hours after installation.

It would be preferable if HTLCs and PTLCs are not gifted.
On the other hand, it might not be possible (as you note about PTLCs).

>
> > Using static-key channels (i.e. channel keys are our node keys) allows us to recover even the outgoing channel with outgoing HTLC that has been forgotten by the outgoing peer.
>
> Right. I think this doesn't work with PTLCs though.

Yes, loss of the adaptor signature means we cannot recover in this case.

>
> > Using static-key channels does have slightly weaker privacy:
> >
> > - Published nodes reveal all their channels with other published nodes on the blockchain.
> > - While it is true that published nodes already reveal their channels with published nodes, they are currently only revealed on the LN gossip network, which is not archived; historical channels that are now closed are not informed to current surveillors.
> > - On the other hand, all it takes is one "LN wayback machine" to record all LN gossip, which are self-attesting and include a signature from the node.
> > - Unpublished nodes risk revealing their channels with published nodes via the blockchain.
> > - Invoices created by unpublished nodes currently reveal their public key.
> > Payers can then uncover all the channels of that node.
> >
>
> I don't think so? You need to know the private key of the node to
> discover its channels! The points actually used in the channels would
> be randomized with shared secret from Diffie-Hellman so are unlinkable
> to the public keys of the two nodes under decisional Diffie-Hellman
> assumption.

Right, that would work.

How about just using a multiplicative tweak of your own privkey and the pubkey of the other node (i.e. just use the "raw" ECDH point), that would work as 2-of-2 in 2p-ECDSA, and I believe (but do not know) should also be signable using MuSig/MuSig2 under taproot?

>
> There is more minor but still real concern of "deniability" of
> unpublished closed channels if a large node operator later becomes
> corrupted or coerced by a malicious actor. Since the node operator
> still knows their secret key (obviously) they can still do a scan
> (same as you would do in recovery) on the whole chain and find any
> past channels they had with any nodes.

"Peer selling private information" is always going to be an issue with unpublished channels, and this seems to be an inherent issue with that model.

Note that due to the existence of proof-of-discrete-log-equivalence, a node operator can *prove* to someone buying private information that a particular outpoint onchain is actually an unpublished channel.
If I have privkey `z` and you have pubkey `L`, I can show `z * G` (my node pubkey), `L` (your "unpublished" (ha, ha) node pubkey), and `z * L` (our ECDH secret), plus a proof-of-discrete-log-equivalence that the `z` in `z * G` is the same `z` in `z * L`, in order to convice them of the ECDH secret.
I suspect part of the proof-of-discrete-log-equivalance can be gated as well by a ZKCP on payment point+scalar the proof is provided only on payment.
The selling node operator does not even need to reveal `z`.

As the ECDH secret is what tweaks the channel keys, that is enough to convince any surveilling buyer.
Further, `z` is not revealed, and channel funds cannot be stolen by just knowledge of the ECDH secret, thus protecting the interests of the selling forwarding node.

Now of course, I could just be making up `L` (i.e. LL could be a sockpuppet of mine).
However, between these two choices:

* I lock up a set number of millisatoshi in a Z + L channel where L is a sockpuppet, and sell this fake information to surveillors.
* I lock up a set number of millisatoshi in a Z + L channel where L is a genuine user node that thinks unpublished channels are private, and sell this genuine information to surveillors.

Which is more lucrative for me?
The latter case would be more lucrative for me, as I not only earn from selling your data to surveillors, I also earn routing fees.
The former case can only earn me selling fake data to surveillors, with no opportunity to earn forwarding fees.

> A mitigation of this problem
> would be for users who want unpublished channels to turn the
> use-node-key-as-channel-key feature off for their keys in the channel
> so they would still be able to do a backup-free channel scan but the
> well-established node would lose the ability to do so.

If the user has all channels unpublished, it is not (normally) gossiped.
So the well-established node would not have the ability to recover *all* channels by backup-free scans of published nodes in the first place, only those that are to published nodes.

Or do you refer to something else?

It might be easier for the "client" here to make up different node IDs for each "server" it connects to, by e.g. hashing its base privkey with the server pubkey and using the hash as the privkey for its fake node ID with that server.

> This means that
> after the channel is closed there would be no way for the large node
> to find the channel again assuming they honestly delete the data.

If forwarding nodes are expected to have storage redundancy, deletion of data could be difficult as well --- there may be lots of replicas of that data in various places (including obsolete replicas that the node operator might not particularly care about, being obsolete), and deletion might not catch them all.
"Honestly delete" seems like a best-effort to me.

On the other hand, if the model is that privacy is to be trusted to your peers, then this is no worse than unpublished channels, which has the same model.

Regards,
ZmnSCPxj

📅 Original date posted:2020-12-15 📝 Original message: Good ...

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

In reply to nevent1q…m8hq
_________________________

📅 Original date posted:2020-12-15
📝 Original message:
Good morning LL,

> - What do you do if the channel state has HTLCs in flight? I don't know -- I guess you can just put them onto the settlement tx? That way it's possible the payment could still go through. Alternatively you could just gift the money to the party offering the recovery settlement.

Gifting the money is not a good option --- we allow HTLCs to be almost as high as the total channel value minus fees and reserve.
Thus all the claimable value could potentially be in an outgoing HTLC.
Worse, if our node is a forwarding node, it would be easy for a third party to arrange to have our funds in various HTLCs.

If we allow HTLCs to keep going on even while we are in recovery, we need to be able to "bind" as well incoming and outgoing HTLCs if our node was a forwarding node.

In particular, consider this situation:

* We are a forwarding node.
* We forward a payment whose outgoing expires in 1 day and whose incoming expires in 2 days.
* This means we have at least two channels, one with the incoming HTLC and another with the outgoing HTLC.
* We hit our head and get amnesia.
* It takes us a day to realize we were formerly a Lightning Network forwarding node.
* The peer with the outgoing HTLC knows or learns the preimage.
* Since we were unresponsive (i.e. still recovering from whatever gave us amnesia) that peer has dropped the channel onchain.
* The peer has resolved the onchain HTLC with the hashlock branch.
* Because the outgoing peer has resolved everything it cares about, it forgets about the channel.
* We call all public nodes and ask about channels we might have with them.
* The incoming peer claims we have a channel with them containing an HTLC going to us.
* The outgoing peer has forgotten about us and does not tell us about the channel.

Thus, we cannot recover the outgoing channel, since the peer has already closed it and resolved everything it is interested in.
(let us suppose that the `to_self_delay` is smaller than our `cltv_delta` setting)

Using static-key channels (i.e. channel keys are our node keys) allows us to recover even the outgoing channel with outgoing HTLC that has been forgotten by the outgoing peer.

Using static-key channels does have slightly weaker privacy:

* Published nodes reveal all their channels with other published nodes on the blockchain.
* While it is true that published nodes already reveal their channels with published nodes, they are currently only revealed on the LN gossip network, which is not archived; historical channels that are now closed are not informed to current surveillors.
* On the other hand, all it takes is one "LN wayback machine" to record all LN gossip, which are self-attesting and include a signature from the node.
* Unpublished nodes risk revealing their channels with published nodes via the blockchain.
* Invoices created by unpublished nodes currently reveal their public key.
Payers can then uncover all the channels of that node.
* An unpublished node could use a faked node id, by combining the payment hash/point with its privkey to generate a new keypair to use as faked node id (I AM NOT A CRYPTOGRAPHER AND THIS TECHNIQUE IS POTENTIALLY GOING TO LOSE ALL YOUR FUNDS AND PRIVACY AND KILL YOUR DOG).
On receiving an unparseable onion, it could try combining its privkey with the payment hash/point and try to open the onion that way, in case it is an incoming payment with the faked node id.

Regards,
ZmnSCPxj

📅 Original date posted:2020-11-27 📝 Original message: Good ...

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

In reply to nevent1q…ev87
_________________________

📅 Original date posted:2020-11-27
📝 Original message:
Good morning Andres, t-bast, Gleb, et al,

> > But instead it could be a point-to-point property: each node provides its own stake certificate
> > to the next node (and only to that node). Alice provides a stake certificate to Bob, then Bob
> > provides a stake certificate to Carol, and so on. If that's the case, it can be in a tlv field in the
> > `update_add_htlc` message and doesn't need to be inside the onion. This also makes it less
> > likely that Alice is exposing herself to remote nodes in the route (payer privacy).
>
> If the above paragraph is confirmed, then does this mean StakeCertificates with privacy are possible without ZK proofs?
> Or did I miss something?

Logically speaking, for this model, a proof is unnecessary --- the node offering the HTLC already has a channel that contains funds that is locked.

Specifically, it is the channel itself where the HTLC is being instantiated, that contains funds owned by the offerer, and which are locked for use in the Lightning Network.

Since the receiver of the HTLC offer is already aware of this channel and its existence, it requires no proof at all.

Thus, I have my doubts on this model --- it seems to me that the current Lightning Network is already equivalent to this model, and the current Lightning Network is (supposedly) attackable by these "griefing" attacks.

Another example is that, if the offerring node has a number of published channels, that is sufficient proof as well, without requiring any privacy-preserving proofs.
This is precisely the current Lightning Network, yet we consider the current Lightning Network attackable by griefing.

Instead, payers, or payees (i.e. by providing the proof in an invoice) must set aside separate non-trivial stake, not tied to channels, but provably tied only to this stake certificate mechanism, in order to assuage the fear of forwarding nodes that the HTLCs will not be claimed immediately.

Regards,
ZmnSCPxj

📅 Original date posted:2020-11-27 📝 Original message: Good ...

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

In reply to nevent1q…7rrr
_________________________

📅 Original date posted:2020-11-27
📝 Original message:
Good morning Gleb,

> Thank you for your interest :)
>
> > Quick question: if I am a routing node and receive a valid stake certificate, can I reuse this stake certificate on my own outgoing payments?
>
> That probably should be avoided, otherwise a mediocre routing node gets a lot of jamming opportunities for no good.
>
> You are right, that’s a strong argument for proof “interactivity”: every Certificate should probably commit to *at least* public key of the routing node it is generated for.

Right, it would be better to have the certificate commit to a specific routing node rather than the payment hash/point as I proposed.
Committing to a payment hash/point allows a random forwarding node to probe the rest of the network using the same certificate, lowering the score for that certificate on much of the network.

Another constraint is that the proof has to be small, since we have to fit it all in a small onion...

Presumably we also want the score to eventually "settle to 0" over time.

Regards,
ZmnSCPxj

>
> – gleb
> On Nov 27, 2020, 2:16 AM +0200, ZmnSCPxj <ZmnSCPxj at protonmail.com>, wrote:
>
> > Good morning Gleb and Antoine,
> >
> > This is certainly interesting!
> >
> > Quick question: if I am a routing node and receive a valid stake certificate, can I reuse this stake certificate on my own outgoing payments?
> >
> > It seems to me that the proof-of-stake-certificate should also somehow integrate a detail of the current payment (such as payment hash/point) so it cannot be reused by routing nodes for their own outgoing payments.
> >
> > For example, looking only at your naive privacy-broken proposal, the signature must use a `sign-to-contract` where the `R` in the signature is actually `R' + h(R' | payment_hash)` with the `R'` also revealed.
> >
> > Regards,
> > ZmnSCPxj
> >
> > > Hello list,
> > >
> > > In this post, we explore a different approach to channel jamming mitigation.
> > > We won’t talk about the background here, for the problem description as well as some proposed solutions (mainly upfront payment schemes), see [1].
> > >
> > > We’re suggesting using UTXO ownership proofs (a.k.a. Stake Certificates) to solve this problem. Previously, these proofs were only used in the Lightning Network at channel announcement time to prevent malicious actors from announcing channels they don’t control. One can think of it as a “fidelity bond” (as a scarce resource) as a requirement for sending HTLCs.
> > >
> > > We start by overviewing issues with other solutions, and then present a naive, privacy-broken Stake Certificates. Then we examine designing a privacy-preserving version, evaluating them. At the end, we talk about non-trivial design decisions and open questions.
> > >
> > > ## Issues with other proposals
> > >
> > > We find unsatisfying that upfront payment schemes come at a cost of new fees (forward and/or backward), thus inflating payment cost for *any* payment.
> > > In the future, the upfront base fee might even make “micropayments” economically infeasible by exceeding the value they transfer. Thus, a good solution should not inflate payment cost while still requiring “burning” a scarce resource (so that the attack is not free).
> > >
> > > Another issue with upfront payments is a circular trust dependency. Ideally, we shouldn’t introduce anything less trust-minimized than the Lightning Network itself.
> > > Upfront payment schemes are not like that, because they in one way or another rely on the honest behavior of route participants.
> > >
> > > We believe Stake Certificates we are going to introduce are satisfactory in both of these directions: they don’t inflate payment costs for honest users and don’t require trust. The main disadvantage of Stake Certificates seems to be the novel cryptography required.
> > > See more details in the “Evaluation” section.
> > >
> > > ## Channel Ownership Proofs as Routing Credit Balance
> > >
> > > Let’s say Alice wants to relay an HTLC to Carol through Bob. Per the Stake Certificates scheme, she has to commit to a particular channel UTXO by embedding an ownership proof in the onion packet while sending an HTLC to Bob.
> > >
> > > Bob then unwraps the onion and verifies:
> > > 1) the channel identifier is pointing unambiguously to an on-chain UTXO;
> > > 2) the ownership proof (e.g., a signature) is valid against the previously disclosed UTXO witness script.
> > >
> > > If all those checks succeed, Bob should see if Alice hasn’t exceeded her credit balance. In case she hasn’t, Bob has to “decrement Alice’s credit balance” and relay the HTLC to Carol.
> > > Decrementing credit balance unconditionally of packet success or failure bounds liquidity abuse by malicious HTLC senders.
> > > Since there is no credit assigned initially, “decrementing the credit balance” means just remembering that “Alice spent X out of Y of the credit she received for her Stake Certificates”.
> > >
> > > Unfortunately, this naive protocol is a privacy nightmare, because routing nodes can now easily assign every HTLC they forward to the sender’s UTXO.
> > >
> > > Let’s first define the terms here one more time, and then proceed to the non-naive, private Stake Certificates.
> > >
> > > - Stake Certificate. Either means a solution we’re proposing or the primitive it is based on, namely proof of UTXO ownership. As we will argue later, it actually makes sense to use proof of LN channel UTXO ownership specifically rather than any funds ownership.
> > > - Stake Certificate value. An amount of the corresponding UTXO or a ballpark this amount provably belongs to.
> > > - Credit balance. When Alice provides a routing node Bob with a Stake Certificate, Bob should increase Alice’s routing credit balance. Alice is then limited in her payments by this balance, and this rule is enforced by routing nodes to prevent free channel jamming in the network. Note that ideally “Alice’s credit balance“ should be virtual and only known to Alice, while routing nodes should only observe per-UTXO credit balance. We currently assume that each routing node keeps track of per-UTXO credit balance separately, see “Design decisions” for more details.
> > > - Stake-to-credit function defines how much credit balance is given per a Stake Certificate of a given value. This function is a policy of a routing node, and it should be announced.
> > > - Credit-to-value-transferred function defines how much value a sender can transfer along a given channel considering how much credit they might claim. The function may also consider different factors (e.g., the available capacity of a channel being used) to provide extra robustness.
> > >
> > > ## Privacy-preserving Stake Certificates
> > >
> > > The presented scheme could preserve privacy if it relied on zero-knowledge proofs of UTXO ownership by avoiding pointing to a particular UTXO.
> > > More specifically, the verifier should be able to check that:
> > > a) The staked UTXO is an element of the current UTXO set
> > > b) The prover knows the witness script committed by the UTXO witness program
> > > c) The prover knows a valid witness for the witness script
> > > d) The staked UTXO was not used to produce a different Stake Certificate which is currently in use as well.
> > >
> > > The verifier should also have a way to see a Stake Certificate value to properly account for the credit. This can be achieved by restricting the UTXO set being proved upon to only those UTXOs with a specific range of values: “I will prove that I own a UTXO among all UTXOs between 0.5 BTC and 1 BTC”.
> > >
> > > Unfortunately, steps (b) and (c) require zero-knowledge protocols for general statements, which are more experimental primitives than most of the stuff we have in Bitcoin protocols,
> > > although we assume it’s feasible to consider them for non-consensus stuff.
> > >
> > > ## Evaluation
> > >
> > > Stake Certificates, upfront payment schemes, and other potential solutions (given a particular configuration) may be compared along the following axis:
> > > 1) Economic feasibility
> > > 1a) What is the cost of overcoming the protection for an attacker? Likely a non-linear function: sats_spent =f(channels_to_jam, […])
> > > 1b) How does this solution limit honest users?
> > > 2) How sophisticated is this solution in terms of integration and making good UX?
> > > 3) How complex is this solution in terms of protocol design/implementation?
> > >
> > > When it comes to (1a), both Stake Certificates and upfront payments are probably equal, in a way that they’re just best-effort ideas to increase the attack cost. Unfortunately, we currently don’t know how to design something as economically powerful as PoW in Bitcoin [3].
> > > This aspect can be properly evaluated by applying these ideas to different hypothetical kinds of LN in a simulation and observing the resulting trade-off between (1a) and (1b) considering different attack strategies.
> > >
> > > In the previous sections of this post, we have argued that Stake Certificates may provide a much better (1b) for the cost of (3) because it relies on zero-knowledge.
> > > When it comes to (2), the design of Stake Certificates may vary in terms of UX burden, from completely automatic to requiring custom actions with private keys from users.
> > >
> > > Some of these trade-offs along with other interesting questions are discussed in the following section.
> > >
> > > ## Design decisions and questions
> > >
> > > #### Should the credit spending be gossipped across the entire network, or should only the routing nodes involved in the payment know?
> > >
> > > Economically, these two approaches are likely to be equivalent, and it’s just a matter of stake-to-credit ratio.
> > > However, announcing credit spending to the network results in a privacy leak. It also imposes bandwidth and CPU overhead on the routing nodes.
> > >
> > > #### Which zero-knowledge system should be used for Stake Certificates?
> > >
> > > Choosing a ZK system boils down to picking the right trade-offs of proving and verifying time, and assumptions. As we mentioned previously, we would need proving general statements.
> > > At the same time, we need something cheap in both proving and verification, because Lightning is supposed to be fast.
> > > At the same time, the setup probably doesn’t matter, because proofs are supposed to be verified only by one participant, a routing node this proof is generated for.
> > > Perhaps we can also pick any cryptographic assumptions we want since this stuff is not mission-critical and can be easily updated if someone breaks a cryptographic assumption and we observe an attack.
> > >
> > > #### Should we allow holding *any* Bitcoins (not just LN channels) for Stake Certificates?
> > >
> > > This idea might make sense if we’re worried that some LN users might want to send more payments than they can afford per their credit. However, we believe that allowing any UTXO would give an attacker more opportunities to use their cold funds for this attack, or even have a secondary market where holders sell their proofs (they have nothing to loose).
> > > Instead, we should a) design the credit-to-stake-functions better; b) encourage users send payments across different routing nodes (since credits are not tracked globally) [4].
> > >
> > > #### What’s the best credit-to-value-transferred function?
> > >
> > > We reckon that this function should be not just linear to provide maximum security against malicious channel jammers. For example, we can charge more credit for the last 20% of the capacity of the *channel used for routing*. Alternatively, we could discourage making too many payments from the same UTXO within a short period of time by charging more credit in this case.
> > >
> > > #### What about the interactivity and lifetime of Stake Certificates?
> > >
> > > Interactive proofs mean that they are constructed on demand of a routing node, non-interactive means constructed by a payment sender ahead of time.
> > > Both interactivity and lifetime have something to do with the ease of producing proof and accessing keys.
> > > We will omit the details of the trade-off we consider, but it remains an open question.
> > >
> > > #### If Stake Certificates are valid for N blocks after proof generation, does it mean that if the UTXO is spent during those N blocks, new proof can be generated from the same coins without invalidating the old proof?
> > >
> > > Yes, but an attacker would, first of all, have to pay an on-chain fee for this. If we’re still worried about this problem, there are workaround ideas.
> > > For example, we could have epochs of 100 blocks (every epoch starts at #XYZXYZ00 block). If at the start of an epoch, a channel wasn’t in the UTXO set, it provides very little credit.
> > > Alternatively, we could expand the zero-knowledge part to proving that the coins were not yet spent.
> > >
> > > #### Should spending a UTXO reveal all Stake Certificates generated from it?
> > >
> > > This would also solve the problem in the previous question, but it would mean a retrospective privacy leak again. To avoid a privacy leak, we should prevent this.
> > >
> > > #### What if malicious Sybil *routing* nodes failing payments causing other honest routing nodes to reduce the credit of an honest payment sender?
> > >
> > > Both Stake Certificates and upfront payment schemes suffer from malicious routing nodes failing the payments and “wasting” the sender’s credit or fees. This problem even applies out of the channel jamming context, when considering payment failure rate.
> > > This problem can be addressed by reducing the reputation of faulty links and routing nodes on the payment sender node. When payment routing becomes a for-profit activity, this would encourage routing nodes to sanitize their links.
> > > The mitigation can be even stronger by using “provable blaming” introduced in [2].
> > >
> > > ## Conclusion
> > >
> > > We propose Stake Certificates, a new solution to channel jamming. Perhaps, it might not be the best near-term solution due to the complexity, but the zero satoshi overhead for honest payments is an appealing argument to switch to it in the future.
> > > This proposal also illustrates how stake-based protocols can solve Sybil challenges in the Bitcoin ecosystem. Since this might be useful in other contexts (Sybil-resistance of many kinds, proof-of-ownership), discussing Stake Certificates is even more useful.
> > > The next step is a discussion of Stake Certificates. If the community finds it interesting, then we should discuss the design questions mentioned above, and choose a cryptosystem.
> > >
> > > Cheers,
> > > Gleb Naumenko and Antoine Riard
> > >
> > > ———
> > >
> > > References and footnotes:
> > > 1. https://github.com/t-bast/lightning-docs/blob/master/spam-prevention.md
> > > 2. https://lists.linuxfoundation.org/pipermail/lightning-dev/2015-August/000135.html
> > > 3. We don’t actually suggest PoW to solve these issues, because a) the trade-off between honest user cost and attacker cost is misaligned due to specialized hardware and b) smartphones would die too fast if they have to compute PoW; PoW is just an unreachable example of system robustness due to well-aligned game theory.
> > > 4. Secondary markets are still possible even if we restrict acceptable proofs to only LN channels, but supply would be much smaller, and markets would work much worse for an attacker.

📅 Original date posted:2020-11-26 📝 Original message: Good ...

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

In reply to nevent1q…mrhc
_________________________

📅 Original date posted:2020-11-26
📝 Original message:
Good morning Gleb and Antoine,

This is certainly interesting!

Quick question: if I am a routing node and receive a valid stake certificate, can I reuse this stake certificate on my own outgoing payments?

It seems to me that the proof-of-stake-certificate should also somehow integrate a detail of the current payment (such as payment hash/point) so it cannot be reused by routing nodes for their own outgoing payments.

For example, looking only at your naive privacy-broken proposal, the signature must use a `sign-to-contract` where the `R` in the signature is actually `R' + h(R' | payment_hash)` with the `R'` also revealed.

Regards,
ZmnSCPxj

> Hello list,
>
> In this post, we explore a different approach to channel jamming mitigation.
> We won’t talk about the background here, for the problem description as well as some proposed solutions (mainly upfront payment schemes), see [1].
>
> We’re suggesting using UTXO ownership proofs (a.k.a. Stake Certificates) to solve this problem. Previously, these proofs were only used in the Lightning Network at channel announcement time to prevent malicious actors from announcing channels they don’t control. One can think of it as a “fidelity bond” (as a scarce resource) as a requirement for sending HTLCs.
>
> We start by overviewing issues with other solutions, and then present a naive, privacy-broken Stake Certificates. Then we examine designing a privacy-preserving version, evaluating them. At the end, we talk about non-trivial design decisions and open questions.
>
> ## Issues with other proposals
>
> We find unsatisfying that upfront payment schemes come at a cost of new fees (forward and/or backward), thus inflating payment cost for *any* payment.
> In the future, the upfront base fee might even make “micropayments” economically infeasible by exceeding the value they transfer. Thus, a good solution should not inflate payment cost while still requiring “burning” a scarce resource (so that the attack is not free).
>
> Another issue with upfront payments is a circular trust dependency. Ideally, we shouldn’t introduce anything less trust-minimized than the Lightning Network itself.
> Upfront payment schemes are not like that, because they in one way or another rely on the honest behavior of route participants.
>
> We believe Stake Certificates we are going to introduce are satisfactory in both of these directions: they don’t inflate payment costs for honest users and don’t require trust. The main disadvantage of Stake Certificates seems to be the novel cryptography required.
> See more details in the “Evaluation” section.
>
> ## Channel Ownership Proofs as Routing Credit Balance
>
> Let’s say Alice wants to relay an HTLC to Carol through Bob. Per the Stake Certificates scheme, she has to commit to a particular channel UTXO by embedding an ownership proof in the onion packet while sending an HTLC to Bob.
>
> Bob then unwraps the onion and verifies:
> 1) the channel identifier is pointing unambiguously to an on-chain UTXO;
> 2) the ownership proof (e.g., a signature) is valid against the previously disclosed UTXO witness script.
>
> If all those checks succeed, Bob should see if Alice hasn’t exceeded her credit balance. In case she hasn’t, Bob has to “decrement Alice’s credit balance” and relay the HTLC to Carol.
> Decrementing credit balance unconditionally of packet success or failure bounds liquidity abuse by malicious HTLC senders.
> Since there is no credit assigned initially, “decrementing the credit balance” means just remembering that “Alice spent X out of Y of the credit she received for her Stake Certificates”.
>
> Unfortunately, this naive protocol is a privacy nightmare, because routing nodes can now easily assign every HTLC they forward to the sender’s UTXO.
>
> Let’s first define the terms here one more time, and then proceed to the non-naive, private Stake Certificates.
>
> - Stake Certificate. Either means a solution we’re proposing or the primitive it is based on, namely proof of UTXO ownership. As we will argue later, it actually makes sense to use proof of LN channel UTXO ownership specifically rather than any funds ownership.
> - Stake Certificate value. An amount of the corresponding UTXO or a ballpark this amount provably belongs to.
> - Credit balance. When Alice provides a routing node Bob with a Stake Certificate, Bob should increase Alice’s routing credit balance. Alice is then limited in her payments by this balance, and this rule is enforced by routing nodes to prevent free channel jamming in the network. Note that ideally “Alice’s credit balance“ should be virtual and only known to Alice, while routing nodes should only observe per-UTXO credit balance. We currently assume that each routing node keeps track of per-UTXO credit balance separately, see “Design decisions” for more details.
> - Stake-to-credit function defines how much credit balance is given per a Stake Certificate of a given value. This function is a policy of a routing node, and it should be announced.
> - Credit-to-value-transferred function defines how much value a sender can transfer along a given channel considering how much credit they might claim. The function may also consider different factors (e.g., the available capacity of a channel being used) to provide extra robustness.
>
> ## Privacy-preserving Stake Certificates
>
> The presented scheme could preserve privacy if it relied on zero-knowledge proofs of UTXO ownership by avoiding pointing to a particular UTXO.
> More specifically, the verifier should be able to check that:
> a) The staked UTXO is an element of the current UTXO set
> b) The prover knows the witness script committed by the UTXO witness program
> c) The prover knows a valid witness for the witness script
> d) The staked UTXO was not used to produce a different Stake Certificate which is currently in use as well.
>
> The verifier should also have a way to see a Stake Certificate value to properly account for the credit. This can be achieved by restricting the UTXO set being proved upon to only those UTXOs with a specific range of values: “I will prove that I own a UTXO among all UTXOs between 0.5 BTC and 1 BTC”.
>
> Unfortunately, steps (b) and (c) require zero-knowledge protocols for general statements, which are more experimental primitives than most of the stuff we have in Bitcoin protocols,
> although we assume it’s feasible to consider them for non-consensus stuff.
>
> ## Evaluation
>
> Stake Certificates, upfront payment schemes, and other potential solutions (given a particular configuration) may be compared along the following axis:
> 1) Economic feasibility
> 1a) What is the cost of overcoming the protection for an attacker? Likely a non-linear function: sats_spent =f(channels_to_jam, […])
> 1b) How does this solution limit honest users?
> 2) How sophisticated is this solution in terms of integration and making good UX?
> 3) How complex is this solution in terms of protocol design/implementation?
>
> When it comes to (1a), both Stake Certificates and upfront payments are probably equal, in a way that they’re just best-effort ideas to increase the attack cost. Unfortunately, we currently don’t know how to design something as economically powerful as PoW in Bitcoin [3].
> This aspect can be properly evaluated by applying these ideas to different hypothetical kinds of LN in a simulation and observing the resulting trade-off between (1a) and (1b) considering different attack strategies.
>
> In the previous sections of this post, we have argued that Stake Certificates may provide a much better (1b) for the cost of (3) because it relies on zero-knowledge.
> When it comes to (2), the design of Stake Certificates may vary in terms of UX burden, from completely automatic to requiring custom actions with private keys from users.
>
> Some of these trade-offs along with other interesting questions are discussed in the following section.
>
> ## Design decisions and questions
>
> #### Should the credit spending be gossipped across the entire network, or should only the routing nodes involved in the payment know?
>
> Economically, these two approaches are likely to be equivalent, and it’s just a matter of stake-to-credit ratio.
> However, announcing credit spending to the network results in a privacy leak. It also imposes bandwidth and CPU overhead on the routing nodes.
>
> #### Which zero-knowledge system should be used for Stake Certificates?
>
> Choosing a ZK system boils down to picking the right trade-offs of proving and verifying time, and assumptions. As we mentioned previously, we would need proving general statements.
> At the same time, we need something cheap in both proving and verification, because Lightning is supposed to be fast.
> At the same time, the setup probably doesn’t matter, because proofs are supposed to be verified only by one participant, a routing node this proof is generated for.
> Perhaps we can also pick any cryptographic assumptions we want since this stuff is not mission-critical and can be easily updated if someone breaks a cryptographic assumption and we observe an attack.
>
> #### Should we allow holding *any* Bitcoins (not just LN channels) for Stake Certificates?
>
> This idea might make sense if we’re worried that some LN users might want to send more payments than they can afford per their credit. However, we believe that allowing any UTXO would give an attacker more opportunities to use their cold funds for this attack, or even have a secondary market where holders sell their proofs (they have nothing to loose).
> Instead, we should a) design the credit-to-stake-functions better; b) encourage users send payments across different routing nodes (since credits are not tracked globally) [4].
>
> #### What’s the best credit-to-value-transferred function?
>
> We reckon that this function should be not just linear to provide maximum security against malicious channel jammers. For example, we can charge more credit for the last 20% of the capacity of the *channel used for routing*. Alternatively, we could discourage making too many payments from the same UTXO within a short period of time by charging more credit in this case.
>
> #### What about the interactivity and lifetime of Stake Certificates?
>
> Interactive proofs mean that they are constructed on demand of a routing node, non-interactive means constructed by a payment sender ahead of time.
> Both interactivity and lifetime have something to do with the ease of producing proof and accessing keys.
> We will omit the details of the trade-off we consider, but it remains an open question.
>
> #### If Stake Certificates are valid for N blocks after proof generation, does it mean that if the UTXO is spent during those N blocks, new proof can be generated from the same coins without invalidating the old proof?
>
> Yes, but an attacker would, first of all, have to pay an on-chain fee for this. If we’re still worried about this problem, there are workaround ideas.
> For example, we could have epochs of 100 blocks (every epoch starts at #XYZXYZ00 block). If at the start of an epoch, a channel wasn’t in the UTXO set, it provides very little credit.
> Alternatively, we could expand the zero-knowledge part to proving that the coins were not yet spent.
>
> #### Should spending a UTXO reveal all Stake Certificates generated from it?
>
> This would also solve the problem in the previous question, but it would mean a retrospective privacy leak again. To avoid a privacy leak, we should prevent this.
>
> #### What if malicious Sybil *routing* nodes failing payments causing other honest routing nodes to reduce the credit of an honest payment sender?
>
> Both Stake Certificates and upfront payment schemes suffer from malicious routing nodes failing the payments and “wasting” the sender’s credit or fees. This problem even applies out of the channel jamming context, when considering payment failure rate.
> This problem can be addressed by reducing the reputation of faulty links and routing nodes on the payment sender node. When payment routing becomes a for-profit activity, this would encourage routing nodes to sanitize their links.
> The mitigation can be even stronger by using “provable blaming” introduced in [2].
>
> ## Conclusion
>
> We propose Stake Certificates, a new solution to channel jamming. Perhaps, it might not be the best near-term solution due to the complexity, but the zero satoshi overhead for honest payments is an appealing argument to switch to it in the future.
> This proposal also illustrates how stake-based protocols can solve Sybil challenges in the Bitcoin ecosystem. Since this might be useful in other contexts (Sybil-resistance of many kinds, proof-of-ownership), discussing Stake Certificates is even more useful.
> The next step is a discussion of Stake Certificates. If the community finds it interesting, then we should discuss the design questions mentioned above, and choose a cryptosystem.
>
> Cheers,
> Gleb Naumenko and Antoine Riard
>
> ———
>
> References and footnotes:
> 1. https://github.com/t-bast/lightning-docs/blob/master/spam-prevention.md
> 2. https://lists.linuxfoundation.org/pipermail/lightning-dev/2015-August/000135.html
> 3. We don’t actually suggest PoW to solve these issues, because a) the trade-off between honest user cost and attacker cost is misaligned due to specialized hardware and b) smartphones would die too fast if they have to compute PoW; PoW is just an unreachable example of system robustness due to well-aligned game theory.
> 4. Secondary markets are still possible even if we restrict acceptable proofs to only LN channels, but supply would be much smaller, and markets would work much worse for an attacker.

📅 Original date posted:2020-10-05 📝 Original message: Good ...

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

In reply to nevent1q…fpq8
_________________________

📅 Original date posted:2020-10-05
📝 Original message:
Good morning Bastien,

> Good morning list,
>
> It seems to me that the "funder pays all the commit tx fees" rule exists solely for simplicity
> (which was totally reasonable). I haven't been able to find much discussion about this decision
> on the mailing list nor in the spec commits.

This indeed seems to be one of those "unwritten rules", like the unwritten rule that SCRIPT opcodes can only look at the transaction they are in and cannot look at the block it got confirmed in, or previous blocks.

My rough understanding is that it prevents this kind of griefing attack:

* You have a node with channels balanced just as you like it, very lucrative, earning entire satoshis of routing fees per week.
* I have a bunch of funds lying around, much larger than your liquidity.
* I create a temporary throwaway node and have it make a large channel to you about equal to your liquidity.
* I send out all of the funds on the new large channel, preferably to offchain-to-onchain swaps like Loop or Boltz.
* This shrinks the outgoing liquidity you have available on your existing channels, making it difficult for you to route and earn routing fees -- in order to route, you need to have *both* incoming and outgoing liquidity.
* If I do not make another channel with my new node, then you cannot rebalance offchain.
* Since my new large channel is now exhausted, I can delete the throwaway node forever.
* The `close_to` feature also allows me to arrange the funds to be closed to a cold-storage funds.
* Or I can just keep the necessary keys to recover funds from the unilateral channel close broadcast by you later.
* There is a reserve, but that is tiny, and if so I can probably afford to wait --- this is a game of chicken on who closes the channel, and since most of the channel is on your end, you are at a serious disadvantage.
* You are now forced to unilateral close the channel so you can send it to an onchain-to-offchain swap and reload your channels into the proper balance it had before I attacked you.

If the unilateral close on the channel were paid by you, then that is adding insult to injury.
Thus, it is better if the unilateral close were paid by me, even if ultimately the unilateral close is performed by you.
This is "initiator pays" principle.

--

On the other hand, a quick skim of your proposal suggests that it still respects the "initiator pays" principle.
Basically, the fundee only pays fees for HTLCs they initiated, which is not relevant to the above attack (since in the above attack, my node is a dead end, you will never send out an HTLC through my channel to rebalance).
So it should still be acceptable.

Regards,
ZmnSCPxj

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

📅 Original date posted:2020-10-11 📝 Original message: Good ...

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

In reply to nevent1q…2jyj
_________________________

📅 Original date posted:2020-10-11
📝 Original message:
Good morning t-bast,

> Hey Zman,
>
> > raising the minimum payment size is another headache
>
> It's true that it may (depending on the algorithm) lower the success rate of MPP-split.
> But it's already a parameter that node operators can configure at will (at channel creation time),
> so IMO it's a complexity we have to deal with anyway. Making it dynamic shouldn't have a high
> impact on MPP algorithms (apart from failures while `channel_update`s are propagating).

Right, it should not have much impact.

For the most part, when considering the possibility of splicing in the future, we should consider that such parameters must be made changeable largely.

>
> To be fully honest, my (maybe unpopular) opinion about MPP is that it's not necessary on the
> network's backbone, only at its edges. Once the network matures, I expect channels between
> "serious" routing nodes to be way bigger than the size of individual payments. The only places
> where there may be small or almost-empty channels are between end-users (wallets) and
> routing nodes.
> If something like Trampoline were to be implemented, MPP would only be needed to reach a
> first routing node (short route), that routing node would aggregate the parts and forward as a
> single HTLC to the next routing node. It would be split again once it reaches the other edge
> of the network (for a short route as well). In a network like this, the MPP routes would only have
> to be computed on a small subset of the network, which makes brute-force algorithms completely
> reasonable and the success rate higher.

This makes me wonder if we really need the onions-per-channel model we currently use.

For instance, Tor is basically two-layer: there is a lower-level TCP/IP layer where packets are sent out to specific nodes on the network and this layer is completely open about where the packet should go, but there is a higher layer where onion routing between nodes is used.

We could imitate this, with HTLC packets that openly show the next destination node, but once all parts reach the destination node, it decodes and turns out to be an onion to be sent to the next destination node, and the current destination node is just another forwarder.

HTLC packets could be split arbitrarily, and later nodes could potentially merge with the lower CLTV used in subsequent hops.

Or not, *shrug*.
It has the bad problem of being more expensive on average than purely source-based routing, and probably having worse payment latency.

For your proposal, how sure is the receiver that the input end of the trampoline node is "nearer" to the payer than itself?

Regards,
ZmnSCPxj

📅 Original date posted:2020-06-20 📝 Original message: Good ...

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

In reply to nevent1q…jhkg
_________________________

📅 Original date posted:2020-06-20
📝 Original message:
Good morning again,

> Good morning Dave,
>
> > ZmnSCPxj noted that pay-to-preimage doesn't work with PTLCs.[2] I was
> > hoping one of Bitcoin's several inventive cryptographers would come
> > along and describe how someone with an adaptor signature could use that
> > information to create a pubkey that could be put into a transaction with
> > a second output that OP_RETURN included the serialized adaptor
> > signature. The pubkey would be designed to be spendable by anyone with
> > the final signature in a way that revealed the hidden value to the
> > pubkey's creator, allowing them to resolve the PTLC. But if that's
> > fundamentally not possible, I think we could advocate for making
> > pay-to-revealed-adaptor-signature possible using something like
> > OP_CHECKSIGFROMSTACK.[3]
>
> <snip>
>
> The signed message could be a signature to `SIGHASH_NONE`, finally an actual use for that flag.

If you are going to embed it in an `OP_RETURN` in the same transaction, you also need `SIGHASH_ANYPREVOUT`, otherwise you cannot embed the adaptor signature for spending from that transaction in the transaction being spent, it also implies `A[p4s] = a[p4s] * G` is a one-time-use keypair.

Regards,
ZmnSCPxj

📅 Original date posted:2020-06-22 📝 Original message: Good ...

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

In reply to nevent1q…agls
_________________________

📅 Original date posted:2020-06-22
📝 Original message:
Good morning Bastien,

> Thanks for the detailed write-up on how it affects incentives and centralization,
> these are good points. I need to spend more time thinking about them.
>
> > This is one reason I suggested using independent pay-to-preimage
> > transactions[1]
>
> While this works as a technical solution, I think it has some incentives issues too.
> In this attack, I believe the miners that hide the preimage tx in their mempool have
> to be accomplice with the attacker, otherwise they would share that tx with some of
> their peers, and some non-miner nodes would get that preimage tx and be able to
> gossip them off-chain (and even relay them to other mempools).

I believe this is technically possible with current mempool rules, without miners cooperating with the attacker.

Basically, the attacker releases two transactions with near-equal fees, so that neither can RBF the other.
It releases the preimage tx near miners, and the timelock tx near non-miners.

Nodes at the boundaries between those that receive the preimage tx and the timelock tx will receive both.
However, they will receive one or the other first.
Which one they receive first will be what they keep, and they will reject the other (and *not* propagate the other), because the difference in fees is not enough to get past the RBF rules (which requires not just a feerate increase, but also an increase in absolute fee, of at least the minimum relay feerate times transaction size).

Because they reject the other tx, they do not propagate the other tx, so the boundary between the two txes is inviolate, neither can get past that boundary, this occurs even if everyone is running 100% unmodified Bitcoin Core code.

I am not a mempool expert and my understanding may be incorrect.

Regards,
ZmnSCPxj

📅 Original date posted:2020-06-21 📝 Original message: Good ...

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

In reply to nevent1q…dxg2
_________________________

📅 Original date posted:2020-06-21
📝 Original message:
Good morning Jeremy,

> My understanding is that you can use the CTV deferral to also get independent HTLC relative timelocks start points per output. This would help with this sort of issue right?
>
> And you're correct that there's overhead of indirection, but it's not super large (minimally complicated something like an extra 100 bytes per output, if you were to have a flat array where each entry is a CTV output so that each out gets its own clock).
>
> Essentially something like this:
>
> Chan
>      |
>      ------------------------------------
>      |    |    |    |            |
> CTV(A) CTV(B) CTV(C) CTV(D)      (Optional CPFP Anchor?)
>      | |    |    |
> 1 block 1 block 1 block 1 block
>      | |    |     |
>     A       B      C       D
>
> Where A B C and D are all HTLCs.
>
> Now because of the one-hop indirection, A B C and D can all expand independently. It's also possible for the Channel Operator to do something like:
>
> Chan
>      |
>      -----------------------------------
>      | |    |    |            |
> CTV(A) CTV(B) CTV(C) CTV(D)      (Optional CPFP Anchor?)
>      | |    |    |
> 1 block 1 block 1 block 10 blocks
>      | |    |    |
>     A       B      C      D
>
> To make D have a further out resolution time to prevent the simultaneous-ness issue (trees or a linear-chain rather than total fan-out can also be used but I think it's a bit more confusing for a basic example).

The Lightning HTLCs use absolute timelocks, and the timelocks are pre-arranged by the original sender.
A forwarding node has to ensure that the outgoing HTLC timeout is respected, or else it could lose funds (by having the outgoing HTLC be claimed by outgoing peer hashlock and the incoming HTLC be calimed by the incoming peer timelock).

(We cannot use relative timelocks in the timelock branches of the HTLCs because we are coordinating possibly up to 20 different nodes, and do not want to leak the entire route to any of the intermediate nodes, so everyone has to use the same clock --- the absolute blockheight --- to measure time)

So, if my understanding of your above graph is correct, you are suggesting that HTLC D could have a relative timelock of 10 blocks instead of 1.

But all that means is that if the timelock of D is at height L, then the forwarder has to ensure that the commitment transaction appears onchain no later than height L - 10 (in practice I have to publish it at L - 11 so it propagates to miners who are building L - 10).
If not, the HTLC cannot be published at height L and the timelock cannot be enforced, risking fund loss.

This seems to *tighten* whatever leeway I might have bought by using CTV.
In current C-Lightning, for instance, for a timelock in my favor at height L, I have to broadcast the commitment transaction at time L - 1 so it goes into block L and I can claim it.
Thus, I have the option to publish from now up to L - 1.
With a further delay of 10 on the HTLC tx D, I now only have the option to publish from now up to L - 11, thus I have *less* leeway in when I can publish the commitment tx.

Basically the fund-security of the forwarding node is based on the absolute timelock of every HTLC it offers, so the timelock is an absolute bound on whatever techniques I might use to reduce fees.

> The benefit of trees is that I can do something like:
>
> Chan
>      |
>      --------------------------------------------------------
>      | |    |    |                    |
> CTV(A) CTV(B) CTV(C) CTV(400 HTLC)      (Optional CPFP Anchor?)
>      | |    |    |    |
> 1 block 1 block 1 block 10 blocks (Optional CPFP Anchor?)
>      | |    |    |
>      |      |      |   / ....\
>     A       B      C  | ..... |
>
> Which makes it so that the low-value new HTLCs can be deprioritized fee wise. So that the attack, which occurs during a fee spike, doesn't end up *requiring* substantial fees to be added to the channel to support a burst of HTLCS.

If the HTLCs have a timelock L, then I *need* to publish the HTLCs at timelock L or else the timelock cannot be enforced.

This means I need to publish the big `| ..... |` transaction with 400 HTLCs before timelock L, where L is `min (L) for all 400 HTLCs`.

The attacker can arrange to have the 400 low-value HTLCs have the same timelock L.
So even if the `| ..... |` is a tree of CTVs, I have to publish the entire tree at the same time so that the final HTLCs appear at timelock L and I can reclaim my funds.

If I do not publish, I run the risk that the total fund going to `CTV(400 HTLC)` gets stolen from me by publication of the hashlock on the outgoing and publication of the timelock at the incoming.
Not publishing this due to fee spikes is basically trusting that the next peer is not going to steal the fund by hashlock branch.
And the next peer is an attacker in this attack, so obviously cannot be trusted.

So it seems to me that this is better done by just rate-limiting simultaneous HTLCs, to limit what can be stolen.

A better solution might be to allow only one HTLC at each absolute timelock, and use a single CTV tree, with one leaf for each of the absolute timelocks.
Then I can publish parts of the CTV tree at my leisure, with my only constraint being the absolute timelock of each HTLC.

Chan
|
CTV
|
+------+
| |
CTV HTLC(L = now + 1)
|
+------+
| |
CTV HTLC(L = now + 2)
|
+------+
| |
CTV HTLC(L = now + 3)
|
...

Such a singly-linked list would take up even more absolute block space, incidentally, and makes high-fee spikes more likely.

Regards,
ZmnSCPxj

📅 Original date posted:2020-06-21 📝 Original message: Good ...

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

In reply to nevent1q…zd6p
_________________________

📅 Original date posted:2020-06-21
📝 Original message:
Good morning Jeremy,

> I am not steeped enough in Lightning Protocol issues to get the full design space, but I'm fairly certain BIP-119 Congestion Control trees would help with this issue.
>
> You can bucket a tree by doing a histogram of HTLC size, so that all small HTLCs live in a common CTV subtree and don't interfere with higher value HTLCs. You can also play with sequencing to prevent those HTLCs from getting longchains in the mempool until they're above a certain value.

If the attacker stops responding, then all HTLC rules need to be published onchain for enforcement of the HTLC rules.
And that publication onchain is the problem: every HTLC published requires onchain space, which must be paid for.

The most compact way to expose the HTLCs is as a flat array, i.e. outputs of a single transaction.
Every tree structure is going to take up more space than a flat array.

What CTV buys is to be able to defer *when* you reveal scripts, possibly to a later time when blockchain space is cheaper.
But in case the victim owns the timelock branch of an outgoing HTLC, it is unsafe for the victim to defer: it has to enforce the locktime soon or it could end up losing both incoming and outgoing HTLC amounts.
And to enforce the locktime it has to publish the HTLC.

Now of course with CTV you could publish only the HTLC you have to enforce *now*, and keep the rest in an CTV output.
The attacker can counter this by pushing 483 HTLCs with the same timelock at the victim, so that the victim has to publish all HTLCs simultaneously.
And a flat array of outputs is cheaper than a tree.

What *can* be done would be to bin by timelock rather than amount; tree leaves are a transaction that exposes all HTLCs with a particular timelock as a flat array of outputs, but different timelocks go to different tree branches.
But the attacker can still do the same-timelock trick, and the tree structure is likely to take up more space in the end than just a non-treed flat array of outputs.

Regards,
ZmnSCPxj

> --
> @JeremyRubin
>
> On Thu, Jun 18, 2020 at 1:41 AM Antoine Riard <antoine.riard at gmail.com> wrote:
>
> > Hi Rene,
> > Thanks for disclosing this vulnerability,
> >
> > I think this blackmail scenario holds but sadly there is a lower scenario.
> >
> > Both "Flood & Loot" and your blackmail attack rely on `update_fee` mechanism and unbounded commitment transaction size inflation. Though the first to provoke block congestion and yours to lockdown in-flight fees as funds hostage situation.
> >
> > > 1. The current solution is to just not use up the max value of htlc's. Eclaire and c-lightning by default only use up to 30 htlcs.
> >
> > As of today, yes I would recommend capping commitment size both for ensuring competitive propagation/block selection and limiting HTLC exposure.
> >
> > > 2. Probably the best fix (not sure if I understand the consequences correctly) is coming from this PR to bitcoin core (c.f. https://github.com/bitcoin/bitcoin/pull/15681 by @TheBlueMatt . If I get it correctly with that we could always have low fees and ask the person who want to claim their outputs to pay fees. This excludes overpayment and could happen at a later stage when fees are not spiked. Still the victim who offered the htlcs would have to spend those outputs at some time.
> >
> > It's a bit more complex, carve-out output, even combined with anchor output support on the LN-side won't protect against different flavors of pinning. I invite you to go through logs of past 2 LN dev meetings.
> >
> > > 3. Don't overpay fees in commitment transactions. We can't foresee the future anyway
> >
> > Once 2. is well-addressed we may deprecate `update_fee`.
> >
> > > 4. Don't add htlcs for which the on chain fee is higher than the HTLCs value (like we do with sub dust amounts and sub satoshi amounts. This would at least make the attack expensive as the attacker would have to bind a lot of liquidity.
> >
> > Ideally we want dust_limit to be dynamic, dust cap should be based on HTLC economic value, feerate of its output, feerate of HTLC-transaction, feerate estimation of any CPFP to bump it. I think that's kind of worthy to do once we solved 3. and 4
> >
> > > 5. Somehow be able to aggregate htlc's. In a world where we use payment points instead of preimages we might be able to do so. It would be really cool if separate HTLC's could be combined to 1 single output. I played around a little bit but I have not come up with a scheme that is more compact in all cases. Thus I just threw in the idea.
> >
> > Yes we may encode all HTLC in some Taproot tree in the future. There are some wrinkles but for a high-level theoretical construction see my post on CoinPool.
> >
> > > 6. Split onchain fees differently (now the attacker would also lose fees by conducting this attack) - No I don't want to start yet another fee bikeshadding debate. (In particular I believe that a different split of fees might make the Flood & Loot attack economically more viable which relies on the same principle)
> >
> > Likely a bit more of fee bikeshedding is something we have to do to make LN secure... Switching fee from pre-committed ones to a single-party, dynamic one.
> >
> > > Independently I think we should have a hint in our readme file about where and how people can disclose attacks and vulnerabilities. Implementations have this but the BOLTs do not.
> >
> > I 100% agree, that's exactly https://github.com/lightningnetwork/lightning-rfc/pull/772, waiting for your feedback :)
> >
> > Cheers,
> >
> > Antoine
> >
> > Le mer. 17 juin 2020 à 09:41, ZmnSCPxj via Lightning-dev <lightning-dev at lists.linuxfoundation.org> a écrit :
> >
> > > Good morning all,
> > >
> > > >
> > > > Fee futures could help against this.
> > > > I remember writing about this some time ago but cannot find where (not sure if it was in lightning-dev or bitcoin-dev).
> > >
> > > `harding` found it: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2020-January/017601.html
> > >
> > > Regards,
> > > ZmnSCPxj
> > > _______________________________________________
> > > Lightning-dev mailing list
> > > Lightning-dev at lists.linuxfoundation.org
> > > https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
> >
> > _______________________________________________
> > Lightning-dev mailing list
> > Lightning-dev at lists.linuxfoundation.org
> > https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev

📅 Original date posted:2020-06-17 📝 Original message: Good ...

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

In reply to nevent1q…qdga
_________________________

📅 Original date posted:2020-06-17
📝 Original message:
Good morning Rene,

Thank you for the report, this is good.

> 1. The current solution is to just not use up the max value of htlc's. Eclaire and c-lightning by default only use up to 30 htlcs.
> 2. Probably the best fix (not sure if I understand the consequences correctly) is coming from this PR to bitcoin core (c.f. https://github.com/bitcoin/bitcoin/pull/15681 by @TheBlueMatt . If I get it correctly with that we could always have low fees and ask the person who want to claim their outputs to pay fees. This excludes overpayment and could happen at a later stage when fees are not spiked. Still the victim who offered the htlcs would have to spend those outputs at some time.
> 3. Don't overpay fees in commitment transactions. We can't foresee the future anyway

Fee futures could help against this.
I remember writing about this some time ago but cannot find where (not sure if it was in lightning-dev or bitcoin-dev).

As a rough sketch, a client contacts a fee insurance service.
For a fixed fee, the client arranges such that the fee insurance service pays for fees in case of a condition where feerates increase.

This is done by arranging a 2-of-2 output spending the insurance premium payment and some maximum fee the insurance service provides.
Initially sign an `nLockTime`d transaction that represents the end of the insurance service contract.
Then at each commitment tx, sign a variety of feerates spending the CPFP carve-out and the insurance 2-of-2, utilizing the insurnace funds for doing the CPFP.

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

Seems a reasonable heuristic.

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

This seems impossible; once you add the points of two unrelated PTLCs, in order to separate them again once you learn the aggregate scalar, you need to learn the scalar of one separately from the scalar of the other, but the aggregate PTLC does not impose the requirement from the receiver to reveal each of the scalars separately.

You *could* require multiple signatures instead of a single signature, in which case each completed signature can reveal a separate scalar behind a point.
Revealing the points and the signatures is 96 bytes, plus a few more bytes for opcodes, divided by 4 because witness, so about equivalent to 24 block space per PTLC you merge.

This cost would be paid by the receiver of the HTLC.
The timelock branch can be made not to have to reveal any of the points, by Taproot-signing the timelock branch, or using a separate tapscript (at the cost of additional 32 witness bytes to select branches, if my taproot understanding holds).

--

Combining timelocks is also bad.
If you combine two PTLCs with different timelocks, which do you choose, the larger or the smaller?

* If you choose the larger, the sender of the PTLCs could have a larger outgoing timelock than the its incoming PTLC, then possibly might lose money when the incoming PTLC times out but the outgoing timelock is not yet timed out and can still be claimed by scalar revelation.
* If you choose the smaller, then the next hop might not have enough block time to deliver the payment, in which case later hops on the route will fail more often (possibly an acceptable tradeoff? c-lightning does shadow routing which overallocates timelock anyway...).
* If you cannot combine different timelocks, the attacker can arrange PTLCs with timelocks from now+2 to now+484 to mount the attack.

--

You could try aggregating using `OP_CHECKTEMPLATEVERIFY`, or equivalently with a pre-signed transaction, but that just moves the revelation cost to the receiver of the PTLC, which multiple signatures above does just as well.
It does have the advantage of retaining the timelocks.

Regards,
ZmnSCPxj

📅 Original date posted:2020-05-14 📝 Original message: Good ...

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

In reply to nevent1q…0le3
_________________________

📅 Original date posted:2020-05-14
📝 Original message:
Good morning Antoine,

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

One hope I have for Lightning is that it will replace centralized custodial services, because:

* Lightning gains some of the scalability advantage of centralized custodial services, because you can now transfer to any Lightning client without touching the blockchain, for much reduced transfer fees.
* At the same time, it retains your-keys-your-coins noncustodiality, because every update of a Lightning channel requires your keys to sign off on it.

If most Lightning clients are SPV, then if we compare these two worlds:

* There are a few highly-important centralized custodial services with significant economic weight running fullnodes (i.e. now).
* There are no highly-important centralized custodial services, and most everyone uses Lightning, but with SPV (i.e. a Lightning future).

Then the distribution of economic weight would be different between these two worlds.
It may even be possible, that the Lightning future with massive SPV might end up with more economic weight in SPV nodes, than in the world without Lightning and dependent on centralized custodial services to scale.

It is also entirely possible that custodial services for Lightning will arise anyway and my hope is already dashed, come on universe, work harder will you, would you really disappoint some randomly-generated Internet person like that.

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

Money makes the world go round, so such backup servers that are publicly-facing rather than privately-owned should be somehow incentivized to do so, or else they would not exist in the first place.
Of course, a free market tends towards monopoly, because any entity that happens to have even a slight advantage at the business will have more money to use towards business reinvestment and increase its advantage further, until they beat the competition to dust, anyone who has won a 4X game knows to search for and stack those little advantages until you snowball and conquer the world/galaxy/petri dish which is why the endgame of 4X games is so boring compared to the start, we have seen this happen in mining and exchanges and so on, and this works against your desire to have a uniform distribution.

If everyone runs such a privately-owned server, on the other hand, this is not so different from having a Lightning node you run at your home that has a fullnode as well and which you access via a remote control mobile device, and it is the inconvenience of having such a server at your home that prevents this in the first place.

Regards,
ZmnSCPxj

📅 Original date posted:2020-05-05 📝 Original message: Good ...

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

In reply to nevent1q…skgl
_________________________

📅 Original date posted:2020-05-05
📝 Original message:
Good morning ariard and luke-jr

> > Trust-minimization of Bitcoin security model has always relied first and
> > above on running a full-node. This current paradigm may be shifted by LN
> > where fast, affordable, confidential, censorship-resistant payment services
> > may attract a lot of adoption without users running a full-node.
>
> No, it cannot be shifted. This would compromise Bitcoin itself, which for
> security depends on the assumption that a supermajority of the economy is
> verifying their incoming transactions using their own full node.
>
> The past few years has seen severe regressions in this area, to the point
> where Bitcoin's future seems quite bleak. Without serious improvements to the
> full node ratio, Bitcoin is likely to fail.
>
> Therefore, all efforts to improve the "full node-less" experience are harmful,
> and should be actively avoided. BIP 157 improves privacy of fn-less usage,
> while providing no real benefits to full node users (compared to more
> efficient protocols like Stratum/Electrum).
>
> For this reason, myself and a few others oppose merging support for BIP 157 in
> Core.

BIP 157 can be implemented as a separate daemon that processes the blocks downloaded by an attached `bitcoind`, i.e. what Wasabi does.

The intention, as I understood it, of putting BIP157 directly into bitcoind was to essentially force all `bitcoind` users to possibly service BIP157 clients, in the hope that a BIP157 client can contact any arbitrary fullnode to get BIP157 service.
This is supposed to improve to the situation relative to e.g. Electrum, where there are far fewer Electrum servers than fullnodes.

Of course, as ariard computes, deploying BIP157 could lead to an effective DDoS on the fullnode network if a large number of BIP157 clients arise.
Though maybe this will not occur very fast? We hope?

It seems to me that the thing that *could* be done would be to have watchtowers provide light-client services, since that seems to be the major business model of watchtowers, as suggested by ariard as well.
This is still less than ideal, but maybe is better than nothing.

Regards,
ZmnSCPxj

📅 Original date posted:2020-04-24 📝 Original message: Good ...

2023-06-09T14:59:55+02:00

In reply to nevent1q…m4wg
_________________________

📅 Original date posted:2020-04-24
📝 Original message:
Good morning Laolu, and list,

> (this may be kind of off-topic, more about DLC deployment than PTLCs
> themselves)
>
> From my PoV, new technologies aren't what has held back DLC deployment to
> this date since the paper was originally released. Tadge has had working
> code than can be deployed today for some time now, and other parties like
> DG-Lab have created full-fledge demos with the system working end to end.
> Instead, the real impediment has been the bootstrapping of the oracles
> which the scheme critically depends upon.
>
> Without oracles, none of it really works. Although, it's also the case that
> there're measures to prevent the oracles from equivocating (reporting two
> conflicting prices/events for a particular instance), bootstrapping a new
> oracle still requires a very high degree of trust as they can lie or report
> incorrect data. As a result, actually deploying an oracle for a system like
> this is tricky business, as it's a trusted centralized entity, so it will
> run into all the normal meatspace/legal/operational risk that any trusted
> centralized service would encounter.
>
> Earlier today, Coinbase announced that they were releasing a new price
> oracle for the ETH ecosystem [1]. This caught my attention as one can
> imagine, that it would be even simpler for them to deploy a DLC oracle which
> exports an API to obtain signed prices/events. As an existing large company
> in the space (depending on who you talk to), they're a trusted entity, which
> has earned a good reputation over the years (solving this
> bootstrapping/trust issue). If they do eventually grow the service to also
> encompass this use case, then it enables a number of possibilities, as
> there's still a ton of value in just base DLC-specific channels (or one off
> contracts), without all the fancy barrier escrow scriptless scipts swappy
> swap swap stuff.

Going even further off-topic, in theory the defiads project could help with this.
An oracle service could advertise itself on defiads, using a timelocked fidelity bond to back up the advertisement, which is a claim-to-truth (that they are trustworthy etc etc).

Equivocation protection in DLC is done by forcing the revelation of a scalar behind a point.
As the defiads fidelity bond also includes a point (where signing with the scalar is needed to reclaim the bond after the timelock period ends), then we can force revelation of the private key protecting the fidelity bond in case of equivocation.

Unfortunately, the oracle can simply outright lie, without equivocating between different segments of its users.

Regards,
ZmnSCPxj

>
> -- Laolu
>
> [1]: https://blog.coinbase.com/introducing-the-coinbase-price-oracle-6d1ee22c7068
>
> On Thu, Apr 23, 2020 at 7:52 AM Nadav Kohen <nadav at suredbits.com> wrote:
>
> > Hi Laolu,
> >
> > Thanks for the response :)
> >
> > I agree that some more framing probably would have been good to have in my update.
> >
> > First, I want to clarify that my intention is not to implement a PTLC-based lightning network on top of ECDSA adaptor signatures, as I do believe that using Schnorr will be superior, but rather I wish to get some PoC sandbox with which to start implementing and testing out the long list of currently theoretical proposals surrounding PTLCs, most of which are implementation agnostic (to a degree anyway). I think it would be super beneficial to have more fleshed out with respect to what some challenges of a Payment Point LN are going to be than we understand now, before Schnorr is implemented and it is time to commit to some PTLC scheme for real.
> >
> > Second, I agree that I've probably understated somewhat the changes that will be needed in most implementations as I was mostly thinking about what would need to change in the BOLTs, which does actually seem relatively minimal (although as you mention, these minimal changes to the BOLTs do trigger large changes in many implementations). Also, good point on how BOLT 11 (invoicing) will have to be altered as well, must've slipped my mind.
> >
> > Best,
> > Nadav
> >
> > On Wed, Apr 22, 2020 at 8:17 PM Olaoluwa Osuntokun <laolu32 at gmail.com> wrote:
> >
> > > Hi Nadav,
> > >
> > > Thanks for the updates! Super cool to see this concept continue to evolve
> > > and integrate new technologies as they pop up.
> > >
> > > > I believe this would only require a few changes to existing nodes:
> > >
> > > Rather than a "few changes", this would to date be the largest network-level
> > > update undertaken to the Lightning Network thus far. In the past, we rolled
> > > out the new onion blob format (which enables changes like this), but none of
> > > the intermediate nodes actually need to modify their behavior. New payment
> > > types like MPP+AMP only needed the _end points_ to update making this an
> > > end-to-end update that has been rolled out so far in a de-synchronized
> > > manner.
> > >
> > > Re-phrasing deploying this requires changes to: the core channel state
> > > machine (the protocol we use to make commitment updates), HTLC scripts,
> > > on-chain HTLC handling and resolution, path finding algorithms (to only see
> > > out the new PTLC-enabled nodes), invoice changes and onion blob processing.
> > > I'd caution against underestimating how long all of this will take in
> > > practice, and the degree of synchronization required to pull it all off
> > > properly.
> > >
> > > For a few years now the question we've all been pondering is: do we wait for
> > > scnhorr to roll out multi-hop locks, or just use the latest ECDSA based
> > > technique? As dual deployment is compatible (we can make the onion blobs for
> > > both types the same), a path has always existed to first roll out with the
> > > latest ECDSA based technique then follow up later to roll out the schnorr
> > > version as well. However there's also a risk here as depending on how
> > > quickly things can be rolled out, schnorr may become available
> > > mid-development, which would possibly cause us to reconsider the ECDSA path
> > > and have the network purely use scnhorr to make things nice and uniform.
> > >
> > > Zooming out for a bit, the solution space of "how channels can look post
> > > scriptless-scripts + taproot" is rather large [1], and the addition of this
> > > new technique allows for an even larger set of deployment possibilities.
> > > This latest ECDSA variant is much simpler than the prior ones (which had a
> > > few rounds of more involved ZKPs), but since it still uses OP_CMS, it can't
> > > be used to modify the funding output.
> > >
> > > [1]: https://lists.linuxfoundation.org/pipermail/lightning-dev/2019-December/002375.html
> > >
> > > -- Laolu
> > >
> > > On Wed, Apr 22, 2020 at 8:13 AM Nadav Kohen <nadav at suredbits.com> wrote:
> > >
> > > > Hello all,
> > > >
> > > > I'd like to give an update on the current state of thinking and coding surrounding replacing Hash-TimeLock Contracts (HTLCs) with Point-TimeLock Contracts (PTLCs) (aka Payment Hashes -> Payment Points) in hopes of sparking interest, discussion, development, etc.
> > > >
> > > > We Want Payment Points!
> > > > -----------------------
> > > >
> > > > Using point-locks (in PTLCs) instead of hash-locks (in HTLCs) for lightning payments is an all around improvement. HTLCs require the use of the same hash across payment routes (barring fancy ZKPs which are inferior to PTLCs) while PTLCs allow for payment de-correlation along routes. For an introduction to the topic, see https://suredbits.com/payment-points-part-1/.
> > > >
> > > > In addition to improving privacy in this way and protecting against wormhole attacks, PTLC-based lightning channels open the door to a large variety of interesting applications that cannot be accomplished with HTLCs:
> > > >
> > > > Stuckless (retry-able) Payments with proof of payment (https://suredbits.com/payment-points-part-2-stuckless-payments/)
> > > >
> > > > Escrow contracts over Lightning (https://suredbits.com/payment-points-part-3-escrow-contracts/)
> > > >
> > > > High/DLOG AMP (https://docs.google.com/presentation/d/15l4h2_zEY4zXC6n1NqsImcjgA0fovl_lkgkKu1O3QT0/edit#slide=id.g64c15419e7_0_40)
> > > >
> > > > Stuckless + AMP (an improvement on Boomerang) (https://lists.linuxfoundation.org/pipermail/lightning-dev/2019-October/002239.html)
> > > >
> > > > Pay-for-signature (https://suredbits.com/payment-points-part-4-selling-signatures/)
> > > >
> > > > Pay-for-commitment (https://lists.linuxfoundation.org/pipermail/lightning-dev/2019-September/002166.html)
> > > >
> > > > Monotonic access structures on payment completion (https://suredbits.com/payment-points-monotone-access-structures/)
> > > >
> > > > Ideal Barrier Escrow Implementation (https://suredbits.com/payment-points-implementing-barrier-escrows/)
> > > >
> > > > And allowing for Barrier Escrows, we can even have
> > > >
> > > > Atomic multi-payment setup (https://suredbits.com/payment-points-and-barrier-escrows/)
> > > >
> > > > Lightning Discreet Log Contract (https://suredbits.com/discreet-log-contracts-on-lightning-network/)
> > > >
> > > > Atomic multi-payment update (https://suredbits.com/updating-and-transferring-lightning-payments/)
> > > >
> > > > Lightning Discreet Log Contract Novation/Transfer (https://suredbits.com/transferring-lightning-dlcs/)
> > > >
> > > > There are likely even more things that can be done with Payment Points so make sure to respond if I've missed any known ones.
> > > >
> > > > How Do We Get Payment Points?
> > > > -----------------------------
> > > >
> > > > Eventually, once we have Taproot, we can use 2p-Schnorr adaptor signatures in Lightning channels. For a detailed thread by ZmnSCPxj, see here https://lists.linuxfoundation.org/pipermail/lightning-dev/2019-December/002375.html
> > > >
> > > > In the meantime, Lloyd has written about a way to do 1p-ECDSA adaptor sigs (https://github.com/LLFourn/one-time-VES) which can be paired with OP_CHECKMULTISIG to allows us to execute PTLCs on Bitcoin today!
> > > >
> > > > Nickler has implemented this in a branch of secp256k1 (https://github.com/jonasnick/secp256k1/pull/14) and I have implemented it in Bouncy Castle in Bitcoin-S with some testing against this branch (https://github.com/nkohen/bitcoin-s-core/tree/bouncy-adaptor). Do note that as nickler states on his PR, "IT IS EXTREMELY DANGEROUS AND RECKLESS TO USE THIS MODULE IN PRODUCTION. DON'T!"
> > > >
> > > > A demo of an on-chain PTLC I executed using nickler's implementation on the backend + bitcoin-s can be seen here https://youtu.be/w9o4v7Idjno
> > > >
> > > > And waxwing did a lovely write-up about the crypto itself https://joinmarket.me/blog/blog/schnorrless-scriptless-scripts/
> > > >
> > > > I would be very interested in having a fork of (at least) one lightning implementation (or Rust Lightning) to be a proof of concept ECDSA-PTLC node with which we can test and play with the plethora of PTLC-based proposals above.
> > > >
> > > > I believe this would only require a few changes to existing nodes:
> > > >
> > > > 1) update_add_ptlc will have a 32 byte x-coordinate (of a point) rather than a 32 byte hash. Additionally the onion's hop_data will contain a 32 byte scalar tweak for each hop. As per [link multi-hop locks]. The last hop_data will instead include a 32 byte scalar equal to the sum of all tweaks.
> > > >
> > > > 2) commitment_signed will have 162 byte adaptor ptlc_signatures rather than valid (71/72 byte) ECDSA signatures on PTLC-success transactions.
> > > >
> > > > 3) The in-flight outputs on the commitment transaction itself become a little simpler as we no longer need to explicitly check the payment pre-image against a hash. Instead, delete all instances of "OP_HASH160 <RIPEMD160(payment_hash)> OP_EQUALVERIFY" in the scripts (leaving the rest the same) and require no pre-image in the witness, only a valid signature. The pre-image check is implicitly enforced by the <remoteptlc_sig> witness since only an adaptor signature was provided by remote so that the payment pre-image is required to create the valid signature (from which the pre-image can be then deduced by comparing adaptor and valid signatures).
> > > >
> > > > If I've missed any other changes that need to happen, do respond with them!
> > > >
> > > > I hope that as a community we can work towards having a PTLC-based Lightning Network that is safe and stable as soon as possible, and so I encourage further thinking, development and expirementation with PTLCs now so that when Taproot is finally at our disposal we can cleanly start moving towards a more ideal Lightning :)
> > > >
> > > > Best,
> > > > Nadav
> > > > _______________________________________________
> > > > Lightning-dev mailing list
> > > > Lightning-dev at lists.linuxfoundation.org
> > > > https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev

📅 Original date posted:2020-04-23 📝 Original message: Good ...

2023-06-09T14:59:50+02:00

In reply to nevent1q…k63r
_________________________

📅 Original date posted:2020-04-23
📝 Original message:
Good morning Matt,

> > - C directly contacts miners with an out-of-band proposal to replace its transaction with an alternative that is much smaller and has a low fee, but much better feerate.
>
> Or they can just wait. For example in today’s mempool it would not be strange for a transaction at 1 sat/vbyte to wait a day but eventually confirm.

That introduces the possibility that the entire tree (with high total fee, remember) gets confirmed, so it would be better for C to replace it with an alternative to a different address C still controls, with a slightly better fee rate but smaller (no child transactions) and lower total fee, so an economically-rational C will make that effort (and if there are still other transactions in the mempool, an economically-rational miner will accept this proposal).

But in any case this is a minor detail and the attack will work either way.

>
> > - Miners, being economically rational, accept this proposal and include this in a block.
> >
> > The proposal by Matt is then:
> >
> > - The hashlock branch should instead be:
> > - B and C must agree, and show the preimage of some hash H (hashlock branch).
> > - Then B and C agree that B provides a signature spending the hashlock branch, to a transaction with the outputs:
> > - Normal payment to C.
> > - Hook output to B, which B can use to CPFP this transaction.
> > - Hook output to C, which C can use to CPFP this transaction.
> > - B can still (somehow) not maintain a mempool, by:
> > - B broadcasts its timelock transaction.
> > - B tries to CPFP the above hashlock transaction.
> > - If CPFP succeeds, it means the above hashlock transaction exists and B queries the peer for this transaction, extracting the preimage and claiming the A->B HTLC.
>
> Note that no query is required. The problem has been solved and the preimage-containing transaction should now confirm just fine.

Ah, right, so it gets confirmed and the `blocksonly` B sees it in a block.

Even if C hooks a tree of low-fee transactions on its hook output or normal payment, miners will still be willing to confirm this and the B hook CPFP transaction without, right?

Regards,
ZmnSCPxj

📅 Original date posted:2020-04-23 📝 Original message: Good ...

2023-06-09T14:59:49+02:00

In reply to nevent1q…3uc0
_________________________

📅 Original date posted:2020-04-23
📝 Original message:
Good morning lists et al,

Let me try to summarize things a little:

* Suppose we have a forwarding payment A->B->C.
* Suppose B does not want to maintain a mempool and is running in `blocksonly` mode to reduce operational costs.
* C triggers B somehow dropping the B<->C channel, such as by sending an `error` message, which will usually cause the other side to drop the channel onchain using its commitment transaction.
* The dropped B<->C channel has an HTLC (that was set up during the A->B->C forwarding).
* The HTLC, being used in a Poon-Dryja channel, actually has the following contract text:
* The fund may be claimed by either of these clauses:
* C can claim, if C shows the preimage of some hash H (hashlock branch).
* B and C must agree, and claim after time L (timelock branch).
* B holds a signature from C that can claim the timelock branch of the HTLC, for a transaction that spends to an output with an `OP_CHECKSEQUENCEVERIFY`.
* The signature is `SIGHASH_ALL`, so the transaction has a fixed feerate.
* C can "pin" the HTLC output by spending using the hashlock branch, and creating a large fee, low fee-rate (tree of) transactions.
* As it is a low fee-rate, miners have no incentive to put this in a block, especially if unrelated higher-fee-rate transactions exist that would earn them more money.
* Even in a full RBF universe, because of the anti-DoS mempool rules, B cannot evict this pinned transaction by just bidding up the feerate.
* A replacing transaction cannot evict alternatives unless its absolute fee is greater than the absolute fee of the alternative.
* The pinning transaction has a high fee, but is blockspace-wasteful, so it is:
* Undesirable to mine (low feerate).
* Difficult to evict (high fee).
* Thus, B is unable to get its timelock-branch transaction in the mempools of miners.
* C waits until the A->B HTLC times out, then:
* C directly contacts miners with an out-of-band proposal to replace its transaction with an alternative that is much smaller and has a low fee, but much better feerate.
* Miners, being economically rational, accept this proposal and include this in a block.

The proposal by Matt is then:

* The hashlock branch should instead be:
* B and C must agree, and show the preimage of some hash H (hashlock branch).
* Then B and C agree that B provides a signature spending the hashlock branch, to a transaction with the outputs:
* Normal payment to C.
* Hook output to B, which B can use to CPFP this transaction.
* Hook output to C, which C can use to CPFP this transaction.
* B can still (somehow) not maintain a mempool, by:
* B broadcasts its timelock transaction.
* B tries to CPFP the above hashlock transaction.
* If CPFP succeeds, it means the above hashlock transaction exists and B queries the peer for this transaction, extracting the preimage and claiming the A->B HTLC.

Is that a fair summary?

--

Naively, and remembering I am completely ignorant of the exact details of the mempool rules, it seems to me quite strange that we are allowing an undesirable transaction (tree) into the mempool:

* Undesirable to mine (low fee-rate).
* Difficult to evict (high fee).

Miners are not interested in low fee-rate transactions, as long as higher fee-rate transactions exist.
And being difficult to evict means miners cannot get alternatives that are more lucrative for them.

The reason (as I understand it) eviction is purposely made difficult here is to prevent certain DoS attacks on Bitcoin nodes, specifically:

1. Attacker sends a low fee-rate tx as a "root" transaction.
2 Attacker sends thousands of low fee-rate tx that build off the above root.
3. Attacker sends a slightly higher fee-rate alternative to the root, evicting the above tree of txes.
4. Attacker sends thousands of low fee-rate tx that build off the latest root.
5. GOTO 3.

However, it seems to me, naively, that "an ounce of prevention is worth a pound of cure".

As I understand it, the mempool is organized already into "packages" of transactions, and adding a transaction into the mempool involves extending and merging packages.
Perhaps the size of a package with low fee-rate (relative to the other packages in the mempool) can be limited, so that mempools drop incoming txes that extend a low-fee-rate tree of transactions.
This means an attacker cannot send thousands of low fee-rate tx that build off some low fee-rate root tx in the first place, so it can still be evicted easily later without much impact.

Naively, it seems to me to prevent the DoS attack as well, as at step 2 it would be prevented from sending thousands of low fee-rate tx building off the root.

As well, as I understand it, this merely tightens the mempool acceptance rules, preventing low fee-rate packages from growing (analogous to a consensus-layer softfork).
The "cannot evict high absolute fee" rule can be retained, as the low-fee-rate package is prevented from reaching a large size.

Would that be workable as a general solution to solve (what I think is) the root cause of this problem?

(This assumes full RBF, I suppose.)

Regards,
ZmnSCPxj

📅 Original date posted:2020-04-12 📝 Original message: Good ...

2023-06-09T14:59:24+02:00

In reply to nevent1q…qpsu
_________________________

📅 Original date posted:2020-04-12
📝 Original message:
Good morning Nadav, and list,

Thinking even further:

* It is trivially cheap for E to start up new nodes F and G and start up channels FA and GC.
* It then becomes possible for E to lock up funds of B via F->A->B->C->G and G->C->B->A->F.
* Even closure of FA and GC does not affect EA and EB.

So I am not certain that this attack is solvable at all via inter-node interactions, since we must also consider the possibility of some throwaway node being created for the purpose of executing this attack.

Perhaps the remaining possible solution is to require that nodes also lock up some funds (in a UTXO that is *separate* from any channels, and from other fidelity bonds, like what belcher suggests for JoinMarket makers, and what is intended for defiads).
This creates an economically-barred identity, which we might ascribe blame to, and perhaps with sufficient amount of proofs, allow someone to create a "proof-of-bad-behavior" that can be believed by other nodes on the network.
The locked up fidelity bonds are an additional cost that an attacker must bear which their possible victims will not bear.

Perhaps the "superbolt network" idea might consider adding such a mitigation, as it also requires some form of persistent identity anyway.

Regards,
ZmnSCPxj

📅 Original date posted:2020-04-01 📝 Original message: Good ...

2023-06-09T14:59:23+02:00

In reply to nevent1q…9p6e
_________________________

📅 Original date posted:2020-04-01
📝 Original message:
Good morning Nadav,

> Love the idea! I have a couple questions though:
>
> I'm not convinced that "Purely Falsified Proof-Of-Closure" aren't effective. Consider a similar network to the one you described where we have channels A - B - C and A - E - C but where we add a "fake" channel E - E'. Now if the attacker sets up a payment from E to E' using the route E - C - B - A - E - E', then the attacker can successfully lock up all of B's channels (as is desirable to get rid of competition) and also generate a false proof of closure for the E - E' channel. Even if this false proof (which is a commitment tx) ends up being published on chain, E has lost no ability to route and has successfully made B unable to route between A and C. If my understanding of the proposal is correct, and it may not be, then the punishment for grieving payments is the threat of closing channels that would benefit from the grieving attack. But adding a new channel on the end to be closed seems to invalidate this punishment?

The consideration is that much of the cost of a channel is with the setup and teardown --- E could always just reopen the CE channel again later.
Thus, the cost that E bears in setting up EE and tearing down EE would be still similar to the cost of losing CE and reestablishing it again.
Further, any amount it places in the EE channel would be an amount it could have been using as liquidity on Lightning, but which it cannot use for forwarding (because it is a channel to nowhere).
Ultimately, proof-of-closure is an economic mechanism, not an information-theoretic one.

So the mere existence of EE, to be later sacrificed, is enough punishment on E.
I think.

>
> A second question I have is if you think that it would be advisable to use up-front payments (pay for attempt, not just success) on payments with abnormally high soft timeouts? If all this works, this combination seems to be a way to enable hodl invoices under the proof of closure proposal.

Possibly, though this increases the complexity of the proposal even more.

>I just thought of a potentially more serious problem, at least for Poon-Dryja channels, isn't it true that giving a proof of closure is equivalent to actually closing the channel since once other parties have copies of the fully signed commitment transaction, it cannot be safely revoked since other parties now have the ability to publish an old state? I might be missing something but this seems like a big problem.

Since this is a proof-of-***closure***, this is indeed an actual closing of the channel.
It would not be proof-of-closure if the channel was not being closed, but proof-of-something-else.

What is desired is simply that C can plausibly say "I punished somebody else by closing on them, please do not punish me for punishing them".

Regards,
ZmnSCPxj

📅 Original date posted:2020-04-02 📝 Original message: Good ...

2023-06-09T14:59:23+02:00

In reply to nevent1q…6u3t
_________________________

📅 Original date posted:2020-04-02
📝 Original message:
Good morning Nadav,

> I could be missing something, but it seems to me like the proposal to close channels after a soft timeout unless non-cooperation can be proven upstream adds a cost to the attacker of two on-chain transactions, which they can immediately revoke (as they know both pieces to the revocation priv key), but still allows very long lock-ups of other's funds (with a 10x multiplier if they choose a long route). I do think that this is certainly an improvement on what we have now but I'm not sure it properly punishes the attacker in its current form.

Ah, right, E knows the revocation for the unilateral close of EE, because it is a self-channel, sigh.
And by this revocation clause it can claim the money immediately and put it into a channel as well.

Regards,
ZmnSCPxj

📅 Original date posted:2020-04-01 📝 Original message: ...

2023-06-09T14:59:20+02:00

In reply to nevent1q…n5u8
_________________________

📅 Original date posted:2020-04-01
📝 Original message:
Introduction
============

Given the fact that contracts on offchain protocols need to be enforceable onchain as well, timelocks involved in multi-hop payments are measured in blocks.
This is because the blockchain can only (third-party-verifiably) enforce timeouts in units of entire blocks.
This leads to very long timeouts for payment delivery, thus multi-hop offchain payment attempts can be, deliberately or accidentally, be in a "pending" state up to the very large timeouts involved.

Deliberately setting up a multi-hop payment such that it will be in a "pending" state for long periods of time is colloquially known as a "griefing attack".
In this article, we assess various proposed solutions to mitigate the effects of griefing attacks, and propose a particular solution, proof-of-closure, as well, that requires significant changes to the update state machine.

Digression: Why Grief?
======================

Before embarking on our investigation for solutions to the griefing problem, we should first wonder if griefing is, in fact, a problem.

This brings up the question of: why would anybody grief at all?

Humans, like cats and other less-sapient pieces of walking meat, often find enjoyment in causing the suffering of others for no immediate direct gain to themselves, as a public demonstration of dominance over those they make suffer (aka "shits and giggles", which, if executed correctly, can lead to eventual direct gains to themselves or their progeny or relatives or allies, but such details are often outside the ken of the very beings who execute such survival strategies: brains are pieces of meat that have been hacked to act as action-reaction engines, but are not sophisticated enough to execute as pure rationality engines at all times).
Fortunately, in the Bitcoin world, only purely rational beings of pure selfishness can exist in the long run, thus we can neglect such motivations as mere noise.

First, let us investigate *how* griefing attacks can be performed.

* An intermediate node in a multi-hop attempt can delay forwarding or failing an incoming HTLC.
* A final node in a payment attempt can delay claiming an incoming HTLC.

Let us consider a purely rational intermediate node of pure selfishness:

* If it forwards as soon as possible, it can earn fees, and also speed up the release of the HTLC-locked funds so that they can reuse those funds as liquidity for further payment attempts.
* Thus, delaying an HTLC is not selfishly-rational for an intermediate node.

Thus, for an intermediate node, it seems there is no selfishly-rational motivation to execute a griefing attack on an arbitrary payment attempt.
We can then conclude that an intermediate that delays a payment would do so, not of its own rational self-interest, but as an accident, such as an unforeseen connectivity or power failure.

However, things are different when we consider a non-arbitrary payment.
Suppose a node were to make a payment attempt to itself, and deliberately delay claiming this self-payment.
This lets any single node, *who happens to own large liquidity*, to lock up the liquidity of other nodes.

The motivation to lock up the liquidity of other nodes is to *eliminate competition*.
Suppose we have a network as below:

A -- B -- C
\ /
\ /
\ /
E

When A and C want to transact with one another, they may choose to route via either B or E.
B and E are therefore competitors in the business of forwarding payments.

But suppose E has much larger channels AE and CE than the channels of AB and CB.
For example, suppose E has 100mBTC perfectly-balanced channels while B has only 10mBTC perfectly-balanced channels, as all things should be in simplified models of reality.
E can then "take out the competition" by making a 5mBTC self-payment along E->A->B->C->E and a 5mBTC self-payment along E->C->B->A->E, then refusing to claim the payment, tying up all the liquidity of the channels of B.
By doing so, it can ensure that A and C will always fail to pay via B, even if they wish to transact in amounts less than 5mBTC.
E thereby eliminates B as a competitor.

This demonstrates that griefing attacks will be motivated, such that such attacks will be performed by payers and payees *against intermediate nodes*.
Intermediate nodes have no motivation to attack payers and payees (those are their potential customers in the business of forwarding payments, and attacking potential customers is bad business: such attacking intermediate nodes will be removed economically in the long run).
However, payers and payees can become motivated to attack intermediate nodes, if the "payer" and "payee" are actually competitor intermediate nodes.

(We can observe that this is always a possibility even outside of Lightning: a service or product provider has no incentive to attack its customers ("the customer is always right"), but have an incentive to *pretend* to be a customer of a competitor and attack them.)

We will keep this fact in mind: active griefing attacks are attacks *on* intermediate nodes, not *by* intermediate nodes, because there is no economic incentive for intermediate nodes to attack their customers.

Previous Proposed Solutions
===========================

Time-Spent Reporting
--------------------

At each channel along the route, the time spent by a node to handle its forwarding is recorded, and reported upstream in the route.

Unfortunately, this solution protects payers from intermediate nodes and payees: it does not protect intermediate nodes from colluding payers and payees.
Even if an intermediate node knows that a particular node is consistently slow via a previous time-spent report, it will not be able, with our current onion routing, determine if an onion packet it just received will or will not go through the known-slow node.
Thus, an intermediate node would not be able to defend against distant payees that, with a colluding payer, will not claim a particular payment.

As we have established, an active griefing atttack will never be deliberately performed by a selfishly-rational intermediate node.
Thus, this solution protects against the wrong thing: it protects payers against slow/unreliable intermediate nodes, it does not protect intermediate nodes against malicious payer/payee collusions.
It protects only against intermediate nodes that inadvertently go offline during forwarding, but such nodes will inevitably lose out on the forwarding market anyway, and will disappear in the long run.

Up-Front Payment
----------------

Payers pay for an attempt, not just the successful completion of an attempt.

A variation on this is that the payer (or payee) continuously pays as long as the payment is pending.
Further variations include paying by other means, such as just locking funds or paying with proof-of-work.

While it certainly erects economic barriers against payer/payee collusions attacking intermediate nodes, it *also* erects economic barriers against normal, non-malicious payments.

We can consider that economic barriers against non-malicious, low-value, high-frequency payments ("micropayments") may be enough that such payments become infeasible if we impose up-front payment for mere attempts.
Thus, while this solution is certainly something we can consider, we must be reluctant to use it due to its up-front, strict-evaluation behavior.

Proof-Of-Closure
================

Observing the above, we want the properties for a "good" solution to griefing attacks to be:

* It should protect intermediate nodes against payer/payee collusions.
* It should only come into play upon detection of an attack.

We now present proof-of-closure, which (we hope) has the above properties.

We can consider instead a softer timeout, distinct from the HTLC block-based timeout.
This softer timeout is measurable in fractions of a second, e.g. units of 0.1 seconds.

Each node on the network advertises, in addition to a block-based `cltv_delta`, a `timeout_delta` in units of 0.1 seconds.
Further, each invoice contains, in addition to a block-based `final_cltv`, a `final_timeout` in units of 0.1 seconds.

Thus, there are two timeouts:

* The current "hard" block-based timeout that is enforceable onchain.
* A new "soft" sidereal-time-based timeout that is not onchain enforceable.

The soft timeout, as mentioned, is not enforceable onchain.
Instead, enforcement of the soft timeout *is* the act of putting the channel state onchain.

Now, for the current "hard" block-based timeout, we already have a reaction.
If the HTLC "hard" timeout is approaching:

* Drop the channel onchain and enforce the hard timeout onchain to reclaim the funds in the HTLCs.
* Wait for the onchain action to be deeply resolved (either timelock or hashlock branch is confirmed deeply) and report the result (success or fail) upstream.

What happens if the "soft" timeout is violated?

* Drop the channel onchain.
* Report the channel closure upstream.

The "hard" timeout is cancelled in any of these two conditions:

* A success is reported via `update_fulfill_htlc`, OR,
* A failure is reported via `update_fail_htlc` AND the HTLC is irrevocably removed from the latest commitments/state(s) of the channel.

The "soft" timeout is cancelled in any of these three conditions, the first two of which are the same as above:

* A success is reported via `update_fulfill_htlc`, OR,
* A failure is reported via `update_fail_htlc` AND the HTLC is irrevocably removed from the latest commitments/state(s) of the channel, OR
* A channel closure is reported.

Let us fill this in more detail.

Suppose we have a payment route A->B->C->E.

Both the "hard" block timeouts and the "soft" second timeouts decrement monotonically at each hop.
Thus, the payee E has the shortest "hard" and "soft" timeouts (as normal).

* Suppose E then delays claiming the payment and violates the "soft" timeout.
* C then drops the CE channel onchain.
* C reports, before its own timeout (slightly larger than the timeout imposed on E), the closing of the channel CE, to B.
* B validates this report, and if valid, propagates the report to A.
* A validates this report, and if valid, accepts that the payment will be "stuck" for up to the hard timeout it imposed on B.

C has to report back to B in order to prevent B from closing the BC channel, and B has to report back to A in order to prevent A from closing the AB channel.
The decrementing seconds-unit timeouts are needed for each hop, for the same reason that decrementing block-unit timeouts are needed.

Since E is motivated to attack intermediate nodes because it wants to redirect payment forwards through itself rather than its competitotrs, having one of its channels closed (which prevents it from being used for forwarding) is directly opposed to its end goal of getting more money, thus, we can believe the action of closing a channel involved in a griefing attack is sufficient disincentive.

The major drawback is that enforcement of the soft timeout *is* a channel closure, which is generally a negative for the network.
This is not a remote attack vector, since a node can only trigger this closure if it is able to stall the fulfillment or failure of an HTLC on a channel, which generally means the node triggering this closure can only do so for its own channels (or it is able to, via a separate mechanism, remotely crash a different node).

Proving Channel Closes
----------------------

What C *really* needs to prove is that:

* It is *willing* to close a channel due to a violation of the soft timeout.
* The channel it is willing to close was, in fact, involved in the same payment attempt.

With the above, B can believe that C was innocent of wrongdoing, because:

* C would only be wiling to close a channel in case of a protocol violation, in this case, a violation of the soft timeout.
* The channel it closed was closed because of this payment attempt, and not because of another payment attempt, or some other unrelated channel being unilaterally closed.

First, what C needs to prove is *NOT*, in fact, actual channel closure: it needs to prove a *willingness* to close a channel.
Thus, it does not require the channel to actually be *closed* yet, i.e. it does not have to wait for onchain activity that the channel closure is in a mempool and is confirmed deeply onchain etc etc.

Thus, to prove a *willingness to close* rather than an actual close, C can provide the unilateral close of the channel CE.
The act of unilaterally closing a channel is the publication of the transaction(s) making up the unilateral close.
Thus, if C is *willing* to close the channel, it is willing to publish the transaction(s) involved, and thus, providing the unilateral close to B and further upstream, shows a willingness to close the channel.

B then validates the provided proof-of-closure by checking that the unilateral close transaction is either onchain, in the mempool, or that it spends a TXO that is not currently spent by another transaction.
In the case the unilateral close transaction is not confirmed and in the mempool, B can speed up its propagation on the Bitcoin layer by putting it in its own mempool as well --- after all, C is willing to close the channel to exonerate itself and punish the actual culprit, and B putting the unilateral close in its own mempool can only help C in what it is willing to do.

Secondly, C needs to prove that the channel it is willing to close involves the payment attempt, and is not some other channel closure that it is attempting to use to fulfill its own soft timeout.
Since the unilateral close transaction *is* the proof-of-closure, B (and A) can inspect the transaction outputs and see (with some additional data from C) that one of the outputs is to an HTLC that matches the payment hash.

Thus, B (and A) can believe that the proof-of-closure proves that whoever is presenting it is free of wrongdoing, as whoever is actually causing the delay has been punished (by someone being willing to close a channel with the culprit), and that the proof-of-closure commits to this particular payment attempt and no other (because it commits to a particular payment hash).

Further, if CE is closed by E dropping it onchain rather than C, C will still be able to fulfill its own soft timeout by taking the closing transaction from E, which should still contain the HTLC.
Indeed, neither A nor B will particularly care (nor need to know) who dropped the channel onchain, or (for A) that the channel participants are C and E.

Update State Shenanigans
------------------------

Bitcoin update mechanisms are complicated things, and it may be possible for an attacking payee E to fool around with the update state machine to make it difficult for C to report a willingness to close CE.

In particular, I quote here the relevant passages from `lightning-rfc`, `02-peer-protocol.md`, which is an implementation of the Poon-Dryja update mechanism:

> Thus each update traverses through the following states:
>
> 1. pending on the receiver
> 2. in the receiver's latest commitment transaction
> 3. ... and the receiver's previous commitment transaction has been revoked,
> and the update is pending on the sender
> 4. ... and in the sender's latest commitment transaction
> 5. ... and the sender's previous commitment transaction has been revoked

The payee E is the "receiver" in this context.

In this case, once the update has reached step 2, then E has a commitment transaction that it can put onchain, that contains an HTLC it can claim.
>From this step onward, C cannot send a failure (i.e. it cannot send back an `update_fail_htlc`) back to B, because E could drop its latest commitment onchain and claim the HTLC onchain.

However, until step 4, C does not have a unilateral close containing the HTLC, and thus cannot provide a proof-of-closure that contains an HTLC that refers to the payment.

Thus, between steps 2 to 4, C cannot safely respond to its own soft timeout.
C cannot respond with a failure, as E could then drop its latest commitment transaction onchain and claim the payment from C, and extract money from C that way.
C also cannot respond with a proof-of-closure, as it does not have a transaction that it can use to provide this proof.

The best that C can do would be to impose an even shorter timeout between steps 2 and 4 above, and to drop its current commitment transaction (which does not contain the HTLC yet and thus does not constitute a valid proof-of-closure) onchain.
In between the time it drops the commitment transaction and its own incoming soft timeout, there is a chance, however small, that this transaction will be confirmed, and the channel will (with high probability) settle in a state where the HTLC is not instantiated, thus C can safely fail its incoming HTLC (not show a proof-of-closure, since that is not possible for C to do) without risk of loss, just prior to its own soft timeout.

Of course, C is still at risk here: E could collude with miners via a side-channel fee offer to confirm its commitment transaction with the HTLC present, and ensure that C is liable for the HTLC value.

With Decker-Russell-Osuntokun, we can remove this risk by requiring a ritual as follows:

1. C requests exclusive access to update their single shared state.
* This can be done via a variety of sub-protocols, including a fair coin toss in case of near-simultaneous requests for exclusive locks on both sides.
2. C provides the details of the new HTLC to E.
3. C and E generate the new state transaction and exchange signatures for it.
4. C and E generate (without signing) the new update transaction.
5. E provides the signature (or share of signature, if MuSig) for the new update transaction to C.
6. C provides the signature for the new update transaction to E, which releases the exclusive lock on the shared state atomically with the finalization of the new update transaction.

Prior to step 5, C can simply fail the incoming HTLC from B in case its own soft timeout is near.
Even if E performs step 5 after C has already failed the incoming HTLC from B, C can simply not perform step 6 and drop the channel onchain with the previous update and state transactions.

With Poon-Dryja, we will have to rearrange the order in which we perform things, effectively adding an extra communications turnaround between the participants.
Specifically, the order would have to be revised to:

> 1. pending on the sender
> 2. in the sender's latest commitment transaction
> 3. ... and the sender's previous commitment transaction has been revoked,
> and the update is pending on the receiver
> 4. ... and in the receiver's latest commitment transaction
> 5. ... and the receiver's previous commitment transaction has been revoked

This allows the sender (C in our context) to provide a proof-of-closure after step 2, and before step 2, C can safely return a failure with `update_fail_htlc` (and refuse to proceed beyond step 2, thus ensuring it can still use the previous commitment that still has no HTLC).

Of course, this change will require redesigning the update state machine, increasing the number of communication turnarounds, and creating a subtle incompatbility when transitioning a payment from a hop that knows only the old update state machine to a hop that knows the new update state machine.

Purely Falsified Proof-Of-Closure
---------------------------------

Of course, the attacking node E might want to create a false proof-of-closure.
E can do this by simulating a Lightning channel: lock an amount of funds in a 2-of-2 (where E controls both keys), then spend it in a set of transactions mimicking the unilateral close.

We observe, however, that the overhead of simulating a Lightning channel is the same as the overhead of actually creating and closing a Lightning channel.
Since the punishment of proof-of-closure is to force attackers to have their channels closed, we can consider that this simulation of a channel open and close is sufficient as well.

Future-Proofing
---------------

This sketch of proof-of-closure can be used for any update mechanism:

* With Poon-Dryja, C can use its own commitment transaction as the proof-of-closure.
* With Decker-Wattenhofer, C can give all the offchain transactions up to the last stage in the multi-stage decrementing-`nSequence` mechanism.
* With Deckker-Russell-Osuntokun, C can give the latest update and state trnsaction.

Basically, we expect that for now, and in the future, any update mechanism worth consideration will have a concept of "unilateral close" where a channel can be dropped onchain, using data that only one of the channel participants holds.

Such a unilateral close will be a sequence of one or more valid transactions, terminating in a transaction containing an HTLC-like contract in one of its outputs.

Thus, to validate the unilateral close, it is only required to validate all the transactions contained in the proof-of-closure, and see that the last transaction has an HTLC output.

The limitations are thus:

* The acceptable forms of HTLC would need to be agreed-upon by the entire network.
* Implementations would need to be able to assess, in a Bitcoin-consensus-compatible way, whether a transaction is valid or not.

Payment Decorrelation and Payment Points
----------------------------------------

Of course, having a single payment hash for the entire payment attempt is a privacy loss, which we intend to fix in the near future by using payment points, and adding a blinding scalar at each hop, aka. payment decorrelation.

Thus, in the future, there will not be any HTLC, but instead a PTLC.
Further, the payment point at each hop will be changed at each hop, in order to prevent decorrelation.

Thus, C needs to provide proofs:

* That an apparent singlesig on the unilateral close output is in fact a PTLC.
C needs to provide:
* A target point P.
* A partial signature that would spend that singlesig for a particular sighash.
* An adaptor signature which, with knowledge of the completed signature, adaptor signature, and sighash message, would have revealed the scalar behind P.
* That the PTLC belongs to the same payment attempt as what B offered to C.
C needs to provide:
* The C-only blinding factor that is the difference between the payment point of the B-to-C PTLC and the C-to-E PTLC on the unilateral close.

Then, when B needs to propagate the proof-of-closure back to A, B simply adds its own blinding factor to the reported blinding factor, in order to convince A that this is the same payment attempt.

As we have brought up privacy, we observe that, when this mechanism triggers, there is a mild privacy loss, in that intermediate nodes now know some channel closure that is related to this payment, and can thus determine the exact path that the payment attempt went through, at least until the channel being closed.
However, proof-of-closure is only propagated in case of violation of the soft timeout, so for normal non-malicious payments, proof-of-closure does not cause any privacy loss.

📅 Original date posted:2020-03-10 📝 Original message: Good ...

2023-06-09T14:59:16+02:00

In reply to nevent1q…88hs
_________________________

📅 Original date posted:2020-03-10
📝 Original message:
Good morning Rusty, et al.,

> Note that this means no payment secret is necessary, since the incoming
> `blinding` serves the same purpose. If we wanted to, we could (ab)use
> payment_secret as the first 32-bytes to put in Carol's enc1 (i.e. it's
> the ECDH for Carol to decrypt enc1).

I confess to not reading everything in detail, but it seems to me that, with payment point + scalar and path decorrelation, we need to establish a secret with each hop anyway (the blinding scalar for path decorrelation), so if you need a secret per hop, possibly this could be reused as well?

Regards,
ZmnSCPxj

📅 Original date posted:2020-02-20 📝 Original message: Good ...

2023-06-09T14:58:56+02:00

In reply to nevent1q…dlxx
_________________________

📅 Original date posted:2020-02-20
📝 Original message:
Good morning Joost and aj,

A thought that arises here is, what happens if I have forwarded a payment, then the outgoing channel is dropped onchain and that peer disconnects from me?

Since the onchain HTLC might have a timelock of, say, a few hundred blocks from now, the outgoing peer can claim it up until the timelock.
If the peer does not claim it, I cannot claim it in my incoming as well.
I also cannot safely fail my incoming, as the outgoing peer can still claim it until the timelock expires.

Am I liable for paying the encumbrance fee in this situation?
How do I charge the next node the encumbrance fee myself if it has dropped the channel onchain and disconnected from me?

Regards,
ZmnSCPxj

> On Tue, Feb 18, 2020 at 10:23:29AM +0100, Joost Jager wrote:
>
> > A different way of mitigating this is to reverse the direction in which the
> > bond is paid. So instead of paying to offer an htlc, nodes need to pay to
> > receive an htlc. This sounds counterintuitive, but for the described jamming
> > attack there is also an attacker node at the end of the route. The attacker
> > still pays.
>
> I think this makes a lot of sense. I think the way it would end up working
> is that the further the route extends, the greater the payments are, so:
>
> A -> B : B sends A 1msat per minute
> A -> B -> C : C sends B 2msat per minute, B forwards 1msat/min to A
> A -> B -> C -> D : D sends C 3 msat, etc
> A -> B -> C -> D -> E : E sends D 4 msat, etc
>
> so each node is receiving +1 msat/minute, except for the last one, who's
> paying n msat/minute, where n is the number of hops to have gotten up to
> the last one. There's the obvious privacy issue there, with fairly
> obvious ways to fudge around it, I think.
>
> But that's rational, because that last node can either (a) collect the
> payment, covering their cost; or (b) forward the payment, at which point
> they'll start collecting funds rather than paying them; or (c) cancel
> the payment releasing all the locked up funds all the way back.
>
> I think it might make sense for the payments to have a grace period --
> ie, "if you keep this payment open longer than 20 seconds, you have to
> start paying me x msat/minute, but if it fulfills or cancels before
> then, it's all good".
>
> I'm not sure if there needs to be any enforcement for this beyond "this
> peer isn't obeying the protocol, so I'm going to close the channel"; not
> even sure it's something that needs to be negotiated as part of payment
> routing -- it could just be something each peer does for HTLCs on their
> channels? If that can be made to work, it doesn't need much crypto or
> bitcoin consensus changes, or even much deployment coordination, all of
> which would be awesome.
>
> I think at $10k/BTC then 1msat is about the fair price for locking up $5
> worth of BTC (so 50k sat) for 1 minute at a 1% pa interest rate, fwiw.
>
> Maybe this opens up some sort of an attack where a peer lies about the
> time to make the "per minute" go faster, but if msats-per-minute is the
> units, not sure that really matters.
>
> Maybe this also implies a different protocol for HTLC forwarding,
> something like:
>
> 1. A sends the HTLC onion packet to B
> 2. B decrypts it, makes sure it makes sense
> 3. B sends a half-signed updated channel state back to A
> 4. A accepts it, and forwards the other half-signed channel update to B
>
> so that at any point before (4) Alice can say "this is taking too long,
> I'll start losing money" and safely abort the HTLC she was forwarding to
> Bob to avoid paying fees; while only after (4) can she start the time on
> expecting Bob to start paying fees that she'll forward back. That means
> 1.5 round-trips before Bob can really forward the HTLC on to Carol;
> but maybe it's parallelisable, so Bob/Carol could start at (1) as soon
> as Alice/Bob has finished (2).
>
> Cheers
> aj
>
>
> Lightning-dev mailing list
> Lightning-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev

📅 Original date posted:2020-02-06 📝 Original message: Good ...

2023-06-09T14:58:38+02:00

In reply to nevent1q…9kdc
_________________________

📅 Original date posted:2020-02-06
📝 Original message:
Good morning niftynei,

> Rusty had some suggestions about how to improve the protocol messages for this, namely adding a serial_id to the inputs and outputs, which can then be reused for deletions.
>
> The serial id can then also be used as the ordering heuristic for transaction inputs during construction (replacing current usage of BIP69). Inputs can be shared amongst peers by flipping the bottom bit of the serial_id before relaying them to another peer (as your own).

What happens if the initiator deliberately provides serial IDs 0x1, 0x3, .... while the acceptor naively provides serial IDs from `/dev/urandom`?

Then the balance of probability is that the initiator inputs and outputs are sorted before the acceptor.
Now, this is probably not an issue, since the initiator and acceptor both know which inputs and outputs are theirs and not theirs, so they could just reveal this information to anyone, so an actor providing such lousy serial IDs is just hurting its own privacy relative to blockchain analysts, so probably will not happen in practice.

My initial reaction was to propose adding a secret-sharing round where the resulting key is XORed to each serial ID before sorting by the XORed serial ID, but this might be too overweight, and again the initiator is only hurting its own privacy, and the two participants already know whose money is whose anyway....

>
> See below for details.
>
> > 1. type: 440 `tx_add_input`
> >
> > 2. data:
> >
> >     * [`32*byte`:`channel_identifier`]
>
> * [`32*byte`:``serial_id`]
>
> Add a serial id.
>
> Each input addition must have a unique serial id.
>
> No addition may have a repeated id number.
>
> The initiator's serial id's must be odd. The non-initiator's serial id's must be even.
>
> Serial ids are used as sorting heuristic for input ordering in final transaction, replaces BIP69
>
>
> >     * [`u64`:`sats`]
> >
> >     * [`sha256`:`prevtx_txid`]
> >
> >     * [`u32`:`prevtx_vout`]
> >
> >     * [`u16`:`prevtx_scriptpubkey_len`]
> >
> >     * [`prevtx_scriptpubkey_len*byte`:`prevtx_scriptpubkey`]
> >
> >     * [`u16`:`max_witness_len`]
> >
> >     * [`u16`:`scriptlen`]
> >
> >     * [`scriptlen*byte`:`script`]
>
> Removes the signal_rbf; everything will be flagged as RBF eligible. (This makes verifying RBF eligibility during a RBF round simpler.)

Yes. Ish.
RBF and privacy do not work well together unfortunately.
This is still initiator-pays, right?

> > 1. subtype: `witness_element`
> >
> > 2. data:
> >
> >     * [`u16`:`len`]
> >
> >     * [`len*byte`:`witness`]
> >
> > ## General Notes
> >
> > - All output scripts must be standard
> >
> > - nLocktime is always set to 0x00000000
>
> - If a blockheight to be used as nLocktime is communicated in the initiation step, is set to blockheight-6; otherwise set to zero-

I am unsure what is the purpose of this minus 6.

If you fear blockheight disagreements, this is probably a good time to introduce block headers.
So for example if the acceptor thinks the initiator blockheight is too high, it could challenge the initiator to give block headers from its known blockheight to the initiator blockheight.
If the acceptor thinks the initiator blockheight is too low, it could provide block headers itself as proof.
This could be limited so that gross differences in blockheight are outright rejected by the acceptor (it could `error` the temporary channel ID rather than accept it).

This is SPV, but neither side is actually making or accepting a payment *yet*, just synchronizing clocks, so maybe not as bad as normal SPV.

Massive chain reorgs cannot reduce blockheight, only increase it (else the reorg attempt fails in the first place) so there must still exist at least one chain(split) with the highest known blockheight already given a proof-of-header-chain, and all you really need is some mining activity on top of *one* split that confirms your funding transaction.

If it is not because of blockheight disagreements or massive chain reorgs, what is the purpose of `blockheight - 6`?

> - Serial ids should be chosen at random
> - For multiparty constructions, the initiator MUST flip the bottom bit of any received inputs before relaying them to a peer.
>
> - Collisions of serial ids between peers is a protocol error

I suppose we should define collision to mean "equal in all bits except the lowest bit".

Regards,
ZmnSCPxj

📅 Original date posted:2020-02-03 📝 Original message: Good ...

2023-06-09T14:58:32+02:00

In reply to nevent1q…0puq
_________________________

📅 Original date posted:2020-02-03
📝 Original message:
Good morning t-bast,

> > This is relevant if we ever want to hide the node id of the last node: Bob could provide a symmetric
> > encryption key to all its peers with unpublished channels, which the peer can XOR with its own true
> > node id and use the lowest 40 bits (or 46 bits or 58 bits) in the SCID.
>
> I don't understand your point here. Alice cannot hide her node_id from Bob since the `node_id` is
> tied to the (unannounced) channel creation.
>
> But this is not an issue. What Alice wants to break is the ability to link multiple HTLCs together
> because they use the same `node_id`. Since Alice can use a different `node_id` in every invoice,
> it's easy for her to make sure Carol cannot tie those HTLCs together.

That is precisely what I am referring to, the lowest bits of the node ID are embedded in the SCID, which we do not want to openly reveal to Carol.
Though if the point is to prevent Carol from correlating different invoices as arising from the same payee, then my scheme fails against that.

>
> In order to hide from Bob, the best Alice can do is use a different `node_id` for each channel she
> opens to Bob and use Tor. This way Bob cannot know that node_id_1 and node_id_2 both belong to Alice.
> I don't think we can do better than that.

Alice would do better to use multiple Bobs in that case.

Regards,
ZmnSCPxj

📅 Original date posted:2020-02-03 📝 Original message: Good ...

2023-06-09T14:58:31+02:00

In reply to nevent1q…hfsg
_________________________

📅 Original date posted:2020-02-03
📝 Original message:
Good morning Rusty,

> Bastien TEINTURIER bastien at acinq.fr writes:
>
> > We can easily get rid of (1.) by leveraging the `payment_secret`. The
> > improved scheme is:
> >
> > - Alice draws a random `decoy_key`
> > - Alice computes the corresponding `decoy_node_id = decoy_key * G`
> > - Alice draws a random `payment_secret`
> > - Alice computes `decoy_short_channel_id = H(payment_secret * decoy_key * bob_node_id) xor short_channel_id`
> > - Alice uses the `decoy_key` to sign the invoice
> > - Carol recovers `decoy_node_id` from the invoice signature
> > - Carol includes `P_I = payment_secret * decoy_node_id` in the onion
> > payload for Bob
> >
> > - Bob can compute `short_channel_id = H(bob_private_key * P_I) xor decoy_short_channel_id`
> >
> > But I don't see how to get rid of (2.). If anyone has a clever idea on how
> > to do that, I'd love to hear it!
>
> I really don't want a special marker on Carol; she needs to just pay
> like normal. Not just because it's simple, but because it means that
> Carol can use a custodial wallet without having to flag the payment as
> somehow special.
>
> AFAICT, having Bob assign scids is the only viable way to do this. The
> current proposal limits to one scid at a time, but it could be extended
> to allow multiple scids.
>
> (I'm seeking a clever way that Bob can assign them and trivially tell
> which ID is assigned to which peer, but I can't figure it out, so I
> guess Bob keeps a mapping and restricts each peer to 256 live scids?).

We can observe that short-channel-ids have a 24-bit blocknum, but it is exceedingly unlikely that for most blockchains, the genesis block will have a Lightning network channel.

So we could reserve blocknum=0 to identify special SCIDs.

The rest of the SCID could refer to the lowest 40 bits of the X-coord of the node ID that is the destination.
We should remember that short channel IDs are used as a convenient way to refer to the next *node* and not the next channel in the onion routing (which is why in Adelaide 2018 we decided to make short channel IDs "advisory", implementation that support multiple channels per peer can use any channel with that peer to forward, not just the specific SCID indicated in the onion).
Now, 40 bits is not a lot, but we can observe that for almost all git repositories, 7 or 8 hex digits is usually enough to unambiguously identify a commit within the repository, even for git repositories with thousands of commits, and 8 hex digits is just 32 bits of identification.
So it seems to me that Bob could just look up the 40 bit identifier to each of the nodes with unpublished channels with it, and this will work well up to Bob having a few thousand peers with unpublished channels.

If we focus on Bitcoin specifically, we can observe as well that `when_lightning_became_cool` is well above 262144 (2^18 ) so we can steal 18 more bits from the blocknum, i.e. if none of the top 6 bits of blocknum are set (blocknum < 262144), then the lower 58 bits of the blockid are the lowest 58 bits of the node ID of the next hop.
Though obviously that is not as good for regtest and testnet, do note that, assuming a non-premined blockchain with a similar 100-block maturity for coinbases, we could still steal 6 bits (blocknum < 64), since no Lightning channel can occur on the first 100 blocks anyway due to the maturity requirement (there *are* no coins that can be spent before then, so no Lightning channels can be created then).

Admittedly, if somebody knows your node id, they need only 40 bits of work to grind a node id of their own whose last 40 bits matches yours, then connect to the same public node you are on.
In that case, it becomes ambiguous for Bob which of the nodes it should send the last hop to, so it could just try them one by one (trying them in parallel risks Bob getting ripped off by an attacker who specifically generates multiple nodes with the same lower bits in the node ID).
Or Bob could just reject future channels from nodes whose lower bits match that with something already channeled with it.

Finally, in this context, this is intended to be used for nodes with unpublished channels.
Of note is that the second-to-the-last node already knows the exact identity, timing, and amount of every payment to the last node anyway, because unpublished channels are not private.
So in this particular case, the second-to-the-last node can actually just drop the payer onion, and replace it with its own onion to the final node.
This is relevant if we ever want to hide the node id of the last node: Bob could provide a symmetric encryption key to all its peers with unpublished channels, which the peer can XOR with its own true node id and use the lowest 40 bits (or 46 bits or 58 bits) in the SCID.
Then when Bob receives an onion whose next SCID has the top 24 or 18 or 6 bits set to 0, it can XOR the symmetric key to the lower bits and then determine the lowest bits of the node id of the last node, and it can then replace the outgoing onion with the corrected onion to that node.
The last node cannot use the payment secret (invoice secret), but that is not going to protect against probe attacks from a public node to a completely unpublished node anyway.
Also the last node cannot receive any data via this method (because the onion is replaced by Bob) but for simple pay-for-preimage applications this will work perfectly fine.

It strikes me as well that a C-Lightning plugin can actually implement this due to `htlc_accepted` hook.

Regards,
ZmnSCPxj

📅 Original date posted:2020-01-26 📝 Original message: Good ...

2023-06-09T14:58:12+02:00

In reply to nevent1q…e526
_________________________

📅 Original date posted:2020-01-26
📝 Original message:
Good morning Subhra,

This does not seem to make sense?
For a payment that is less than the channel funds on your side, only that amount is locked behind an HTLC, and the rest remains useable for other HTLCs.

What exactly are you referring to?

Regards,
ZmnSCPxj

> Hi,
> I was wondering when parties apply condition on fraction of channel fund for ensuring successful payment, entire channel fund is held. Is it possible to lock just partial amount of fund of a payment channel and leave the rest to be used by some another payment request ? Concept of subchannels of a single channel has been suggested in "Atomic multi-channel updates with constant collateral in bitcoin-compatible payment-channel networks" https://scholar.google.com/scholar?cluster=40566801298747858&hl=en&as_sdt=2005&sciodt=0,5 but I am still in doubt what happens during closing of subchannel ?
> --
> Yours sincerely,
> Subhra Mazumdar.

📅 Original date posted:2020-01-07 📝 Original message: Good ...

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

In reply to nevent1q…w9wk
_________________________

📅 Original date posted:2020-01-07
📝 Original message:
Good morning Rene, and list,

It seems to me that the rule used here might be useful to guide how to split a payment for multipath as well.

For example, consider the case where a payer Alice has channels to Bob and Charlie.

* Alice-Bob has A=0.5, B=0.5
* Alice-Charlie has A=0.5, C=0.5

In that case, in order to retain balance, if Alice has to pay 0.1, it should strive to split the payment into a 0.05 via Alice-Bob and 0.05 via Alice-Charlie.

Would it be possible to derive such a calculation from your published rule?
For example, if one of the payer channels is imbalanced in favor of the payer, then the payment probably should not be split, but if the payment is big enough that it would be imbalanced against the payer afterwards, then some small amount must be split out to another channel.

Regards,
ZmnSCPxj

📅 Original date posted:2019-12-17 📝 Original message: Good ...

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

In reply to nevent1q…5dty
_________________________

📅 Original date posted:2019-12-17
📝 Original message:
Good morning t-bast,

Further, we can enforce that RBF is signalled for every spend of the output by:

<0> OP_CHECKSEQUENCEVERIFY OP_DROP <R> OP_SWAP OP_CAT <ACINQ> OP_CHECKSIG

Requiring that RBF is signalled gives a little more assurance.
Suppose ACINQ becomes evil and double-spends the output.
The transaction that is posted in the mempool must be marked by RBF due to the `OP_CHECKSEQUENCEVERIFY` opcode, since `nSequence` also doubles as RBF opt-in.
Then anyone who notices the double-spend can RBF the double-spending transaction to themselves rather than ACINQ.
This also further publishes ACINQ private key, until the winning transaction has an `OP_RETURN` output that pays the entire value as fees and nobody can RBF it further.

This is a minor increase in the assurability of the construction, by making any output that is double-spent directly revocable in favor of the miners.
Again, it requires `OP_CAT`, which is a very dangerous opcode, allowing such powerful constructions.

Regards,
ZmnSCPxj

> Thanks a lot David for the suggestion and pointers, that's a really interesting solution.
> I will dive into that in-depth, it could be very useful for many layer-2 constructions.
>
> Thanks ZmnSCPxj as well for the quick feedback and the `OP_CAT` construction,
> a lot of cool tricks coming up once (if?) we have such tools in the future ;)
>
> Le mar. 17 déc. 2019 à 16:14, ZmnSCPxj <ZmnSCPxj at protonmail.com> a écrit :
>
> > Good morning David, t-bast, and all,
> >
> > > I'm not aware of any way to currently force single-show signatures in
> > > Bitcoin, so this is pretty theoretical. Also, single-show signatures
> > > add a lot of fragility to any setup and make useful features like RBF
> > > fee bumping unavailable.
> >
> > With `OP_CAT`, we can enforce that a particular `R` is used, which allows to implement single-show signatures.
> >
> > # Assuming signatures are the concatenation of (R,s)
> > <R> OP_SWAP OP_CAT <ACINQ> OP_CHECKSIG
> >
> > The above would then feed `s` only on the witness stack.
> >
> > Regards,
> > ZmnSCPxj