ZmnSCPxj [ARCHIVE]

⚠️ This account is not associated with a real person. It's an archival account for mailing list messages.
🗓️ Active from 2017-04-26 to 2023-05-24
💬 Posted a total of 1299 messages
📚 Participated in the following categories: bitcoin-dev, Lightning-dev, RFC, BIP Proposal, was CheckSigFromStack for Arithmetic Values, Bitcoin Advent Calendar, Pre-BIP, Opt-in full-RBF, PATCH, 1.1, Question, c-lightning, DRAFT, META, PROPOSAL, try2, VERY ROUGH DRAFT
🔇 Please do not DM this user as it's used for archive purposes only.

Public Key

npub1g5zswf6y48f7fy90jf3tlcuwdmjn8znhzaa4vkmtxaeskca8hpss23ms3l

Profile Code

nprofile1qqsy2pg8yaz2n5lyjzheyc4luw8xaefn3fm3w76ktd4nwuctvwnmscglcrsjn

Author Public Key

npub1g5zswf6y48f7fy90jf3tlcuwdmjn8znhzaa4vkmtxaeskca8hpss23ms3l

Show more details

Last Notes

2023-10-18 13:02:11

- reply

📅 Original date posted:2023-10-17
🗒️ Summary of this message: Batched splicing can be risky if not all splice implementations perform a check to ensure subsequent splices confirm, potentially leading to loss of funds.
📝 Original message:
Good morning Greg,
> > 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.
> As long as the implementation decides to splice again at some point when a prior
> splice isn't confirming, it will self-resolve once any subsequent splice is confirmed.
Do note that there is a risk here that the reason for "not confirming" is because of an unexpected increase in mempool usage.
In particular, if the attack is not being performed, it is possible for the previous splice tx that was not confirming for a while, to be the one that confirms in the end, instead of the subsequent splice.
This is admittedly an edge case, but one that could potentially be specifically attacked and could lead to loss of funds if the implementations naively deleted the signatures for commitment transactions for the previously-not-confirming splice transaction.
Indeed, as I understood it, part of the splice proposal is that while a channel is being spliced, it should not be spliced again, which your proposal seems to violate.
Regards,
ZmnSCPxj

2023-10-18 13:02:10

- reply

📅 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

2023-10-18 13:02:08

- reply

📅 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

2023-10-03 21:44:19

- reply

📅 Original date posted:2023-09-26
🗒️ Summary of this message: The email discusses the issue of interactivity constraints in payment pools and channel factories and proposes a solution to mitigate equivocation of off-chain balances.
📝 Original message:
Good morning Antoine,
Does `OP_EVICT` not fit?
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-February/019926.html
Regards,
ZmnSCPxj
Sent with Proton Mail secure email.
------- Original Message -------
On Monday, September 25th, 2023 at 6:18 PM, Antoine Riard via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> wrote:
> Payment pools and channel factories are afflicted by severe interactivity constraints worsening with the number of users owning an off-chain balance in the construction. The security of user funds is paramount on the ability to withdraw unilaterally from the off-chain construction. As such any update applied to the off-chain balances requires a signature contribution from the unanimity of the construction users to ensure this ability is conserved along updates.
> As soon as one user starts to be offline or irresponsive, the updates of the off-chain balances must have to be halted and payments progress are limited among subsets of 2 users sharing a channel. Different people have proposed solutions to this issue: introducing a coordinator, partitioning or layering balances in off-chain users subsets. I think all those solutions have circled around a novel issue introduced, namely equivocation of off-chain balances at the harm of construction counterparties [0].
>
> As ZmnSCPxj pointed out recently, one way to mitigate this equivocation consists in punishing the cheating pre-nominated coordinator on an external fidelity bond. One can even imagine more trust-mimized and decentralized fraud proofs to implement this mitigation, removing the need of a coordinator [1].
>
> However, I believe punishment equivocation to be game-theory sound should compensate a defrauded counterparty of the integrity of its lost off-chain balance. As one cheating counterparty can equivocate in the worst-case against all the other counterparties in the construction, one fidelity bond should be equal to ( C - 1 ) * B satoshi amount, where C is the number of construction counterparty and B the initial off-chain balance of the cheating counterparty.
>
> Moreover, I guess it is impossible to know ahead of a partition or transition who will be the "honest" counterparties from the "dishonest" ones, therefore this ( C - 1 ) * B-sized fidelity bond must be maintained by every counterparty in the pool or factory. On this ground, I think this mitigation and other corrective ones are not economically practical for large-scale pools among a set of anonymous users.
>
> I think the best solution to solve the interactivity issue which is realistic to design is one ruling out off-chain group equivocation in a prophylactic fashion. The pool or factory funding utxo should be edited in an efficient way to register new off-chain subgroups, as lack of interactivity from a subset of counterparties demands it.
>
> With CoinPool, there is already this idea of including a user pubkey and balance amount to each leaf composing the Taproot tree while preserving the key-path spend in case of unanimity in the user group. Taproot leaves can be effectively regarded as off-chain user accounts available to realize privacy-preserving payments and contracts.
>
> I think one (new ?) idea can be to introduce taproot leaves "cut-through" spends where multiple leaves are updated with a single witness, interactively composed by the owners of the spent leaves. This spend sends back the leaves amount to a new single leaf, aggregating the amounts and user pubkeys. The user leaves not participating in this "cut-through" are inherited with full integrity in the new version of the Taproot tree, at the gain of no interactivity from their side.
>
> Let's say you have a CoinPool funded and initially set with Alice, Bob, Caroll, Dave and Eve. Each pool participant has a leaf L.x committing to an amount A.x and user pubkey P.x, where x is the user name owning a leaf.
>
> Bob and Eve are deemed to be offline by the Alice, Caroll and Dave subset (the ACD group).
>
> The ACD group composes a cut-through spend of L.a + L.c + L.d. This spends generates a new leaf L.(acd) leaf committing to amount A.(acd) and P.(acd).
>
> Amount A.(acd) = A.a + A.c + A.d and pubkey P.(acd) = P.a + P.c + P.d.
>
> Bob's leaf L.b and Eve's leaf L.e are left unmodified.
>
> The ACD group generates a new Taproot tree T' = L.(acd) + L.b + L.e, where the key-path K spend including the original unanimity of pool counterparties is left unmodified.
>
> The ACD group can confirm a transaction spending the pool funding utxo to a new single output committing to the scriptpubkey K + T'.
>
> From then, the ACD group can pursue off-chain balance updates among the subgroup thanks to the new P.(acd) and relying on the known Eltoo mechanism. There is no possibility for any member of the ACD group to equivocate with Bob or Eve in a non-observable fashion.
>
> Once Bob and Eve are online and ready to negotiate an on-chain pool "refresh" transaction, the conserved key-path spend can be used to re-equilibrate the Taproot tree, prune out old subgroups unlikely to be used and provision future subgroups, all with a compact spend based on signature aggregation.
>
> Few new Taproot tree update script primitives have been proposed, e.g [2]. Though I think none with the level of flexibility offered to generate leaves cut-through spends, or even batch of "cut-through" where M subgroups are willing to spend N leaves to compose P new subgroups fan-out in Q new outputs, with showing a single on-chain witness. I believe such a hypothetical primitive can also reduce the chain space consumed in the occurrence of naive mass pool withdraws at the same time.
>
> I think this solution to the high-interactivity issue of payment pools and factories shifts the burden on each individual user to pre-commit fast Taproot tree traversals, allowing them to compose new pool subgroups as fluctuations in pool users' level of liveliness demand it. Pool efficiency becomes the sum of the quality of user prediction on its counterparties' liveliness during the construction lifetime. Recursive taproot tree spends or more efficient accumulator than merkle tree sounds ideas to lower the on-chain witness space consumed by every pool in the average non-interactive case.
>
> Cheers,
> Antoine
>
> [0] https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-April/020370.html
> [1] https://lists.linuxfoundation.org/pipermail/lightning-dev/2023-August/004043.html
> [2] https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-September/019420.html

2023-09-19 10:29:43

- reply

📅 Original date posted:2023-09-12
🗒️ Summary of this message: The actuary's signature in a contract can be protected by using a specific 'R' value to prevent private key leakage. Loose interactivity is assumed, but there are still concerns about the actuary slashing the bond or participants not cooperating.
📝 Original message:
Good morning Antoine,
> Hi Zeeman
>
> > What we can do is to add the actuary to the contract that
> > controls the funds, but with the condition that the
> > actuary signature has a specific `R`.
>
> > As we know, `R` reuse --- creating a new signature for a
> > different message but the same `R` --- will leak the
> > private key.
>
> > The actuary can be forced to put up an onchain bond.
> > The bond can be spent using the private key of the actuary.
> > If the actuary signs a transaction once, with a fixed `R`,
> > then its private key is still safe.
>
> > However, if the actuary signs one transaction that spends
> > some transaction output, and then signs a different
> > transaction that spends the same transaction output, both
> > signatures need to use the same fixed `R`.
> > Because of the `R` reuse, this lets anyone who expected
> > one transaction to be confirmed, but finds that the other
> > one was confirmed, to derive the secret key of the
> > actuary from the two signatures, and then slash the bond
> > of the actuary.
>
> From my understanding, if an off-chain state N1 with a negotiated group of 40 is halted in the middle of the actuary's R reveals due to the 40th participant non-interactivity, there is no guarantee than a new off-chain state N1' with a new negotiated group of 39 (from which evicted 40th's output is absent) do not re-use R reveals on N1. So for the actuary bond security, I think the R reveal should only happen once all the group participants have revealed their own signature. It sounds like some loose interactivity is still assumed, i.e all the non-actuary participants must be online at the same time, and lack of contribution is to blame as you have a "flat" off-chain construction (i.e no layering of the promised off-chain outputs in subgroups to lower novation interactivity).
Yes, there is some loose interactivity assumed.
However:
* The actuary is always online and can gather signatures for the next state in parallel with signing new transactions on top of the next state.
* This is why `SIGHASH_ANYPREVOUT` is needed, as the transactions on top of the next state might spend either the actual next state (if the next state is successfully signed), or the current state plus additional transactions (i.e. the transaction that move from current state to next state) (if the next state fails to get fully signed and the participants decide to give up on the next state getting signed).
> More fundamentally, I think this actuarial system does not solve the "multi-party off-chain state correction" problem as there is no guarantee that the actuary does not slash the bond itself. And if the bond is guarded by users' pubkeys, there is no guarantee that the user will cooperate after the actuary equivocation is committed to sign a "fair" slashing transaction.
Indeed.
One can consider that the participants other than the actuary would generate a single public key known by the participants.
But then only one sockpuppet of the actuary is needed to add to the participant set.
Basically, the big issue is that the actuary needs to bond a significant amount of funds to each participant, and that bond is not part of the funding of the construction.
Other ways of ensuring single-use can be replaced, if that is possible.
Do you know of any?
Regards,
ZmnSCPxj

2023-09-19 10:19:29

- reply

📅 Original date posted:2023-09-18
🗒️ Summary of this message: A covenant tree can create channels for casual users without requiring signatures, but it doesn't provide long-term scaling benefits. Adding a deadline can achieve long-term scaling.
📝 Original message:
Good morning John,
> On the other hand, if the consensus rules are changed to allow even simple covenants, this scaling bottleneck is eliminated.
> The key observation is that with covenants, a casual user can co-own an off-chain Lightning channel without having to sign all (or any) of the transactions on which it depends.
> Instead, a UTXO can have a covenant that guarantees the creation of the casual user's channel.
> The simplest way to have a single UTXO create channels for a large number of casual users is to put a covenant on the UTXO that forces the creation of a tree of transactions, the leaves of which are the casual users' channels.
>
> While such a covenant tree can create channels for millions of casual users without requiring signatures or solving a difficult group coordination problem, it's not sufficient for scaling.
> The problem is that each channel created by a covenant tree has a fixed set of owners, and changing the ownership of a channel created by a covenant tree requires putting the channel on-chain.
> Therefore, assuming that all casual users will eventually want to pair with different dedicated users (and vice-versa), the covenant tree doesn't actually provide any long-term scaling benefit.
>
> Fortunately, real long-term scaling can be achieved by adding a deadline after which all non-leaf outputs in the covenant tree can be spent without having to meet the conditions of the covenant.
> The resulting covenant tree is called a "timeout-tree" [9, Section 5.3].
>
> Let A_1 ... A_n denote a large number of casual users, let B be a dedicated user, and let E denote some fixed time in the future.
> User B creates a timeout-tree with expiry E where:
> * leaf i has an output that funds a Lightning channel owned by A_i and B, and
> * after time E, each non-leaf output in the covenant tree can also be spent by user B without having to meet the conditions of the covenant.
I think, based solely on the description above, that it is not safe for dedicated user `B` to create this, unless it gets a signature from `A_i`.
Basically, suppose the entire thing is single-funded from `B`.
(Funding from `A_i` requires that each `A_i` that wants to contribute be online at the time, at which point you might as well just use signatures instead of `OP_CHECKTEMPLATEVERIFY`.)
If a particular `A_i` never contacts `B` but *does* get the entire path from the funding TXO to the `A_i && B` output confirmed, then the funds that `B` allocated are locked, ***unless*** `B` got a unilateral close signature from `A_i` to spend from `A_i && B`.
Thus, `A_i` still needs to be online at the time `B` signs the funding transaction that anchors the entire tree.
(This is why many people lost funds when they went and implemented `multifundchannel` by themselves --- you need to ensure that all the counterparties in the same batch of openingshave given you unilateral close signatures ***before*** you broadcast the funding transaction.
And in principle, whether the channels are represented onchain by a single transaction output, or multiple separate ones on the same transaction, is immaterial --- the funder still needs a unilateral close signature from the fundee.)
The alternative is to also infect the leaf itself with a lifetime `(A_i && B) || (B && CLTV)`.
This is essentially a Spilman channel variant, which is what we use in swap-in-potentiam, BTW.
If so, then `B` can dedicate that leaf output to a separate 1-input 1-output transaction that takes the `(A_i && B)` branch and spends to a plain `A && B` Lightning channel.
`B` can fund the tree, then when `A_i` comes online and is wiling to accept the channel from `B`, that is when `A_i` creates two signatures:
* For the transaction spending `(A_i && B) || (B && CLTV)` (taking the `A_i && B` branch) to spend to the `A && B`.
* For the unilateral close transaction from the above output.
Regards,
ZmnSCPxj

2023-08-08 13:54:11

- reply

📅 Original date posted:2023-08-07
🗒️ Summary of this message: The question is about whether there are tools available for full node operators to prune `OP_RETURN` data from their nodes. The answer explains that `OP_RETURN` outputs are already pruned and discusses the concept of pruning in the context of the UTXO database.
📝 Original message:
Good morning John Light,
> 2. Documentation about OP_RETURN says that OP_RETURN outputs are "provably-prunable".[2] A question I had about this was, are there any tools available that a full node operator could use to prune this data from their nodes?
As I understand it, `OP_RETURN` outputs are already pruned, in the sense that they are never put in the UTXO database in the first place.
Indeed, as I understand it, "pruning" in this context is about removing (or not inserting at all, in the case of `OP_RETURN`) from the UTXO database.
UTXO database is best to keep small to reduce lookups of UTXOs being spent, as that impacts speed of validation.
Archival nodes still retain the raw `OP_RETURN` data as part of the raw block data, as it is necessary to prove that those transactions are (1) valid transactions and (2) part of (i.e. in the Merkle tree of) a valid block on the block header chain.
Block-pruning nodes also still retain this data, as they can at least serve recent blocks with the same requirement of proving that transactions containing `OP_RETURN` are valid transactions in a valid block on the block header chain.
If you want to prove that a block is valid, you need to present even `OP_RETURN` data, as you need to be able to show the actual transaction containing it, so that the verifier can see that the transaction is correctly formatted and its txid matches the supposed location in the Merkle tree.
Block relay requires that the node relaying a block prove that that block is indeed valid, thus you need to retain the `OP_RETURN` data.
Thus, in this context "pruning" refers to not keeping `OP_RETURN` TXOs in the UTXO database.
Regards,
ZmnSCPxj

2023-07-25 16:11:23

- reply

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

2023-07-24 11:36:00

- reply

📅 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

2023-06-19 17:42:19

- reply

📅 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 with certain conditions.
📝 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

2023-06-19 17:42:18

- reply

📅 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

2023-06-09 13:13:16

- reply

📅 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

2023-06-09 13:13:15

- reply

2023-06-09 13:13:01

- reply

📅 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

2023-06-09 13:13:01

- reply

📅 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

2023-06-09 13:12:44

- reply

📅 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

2023-06-09 13:12:40

- reply

📅 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

2023-06-09 13:12:27

- reply

📅 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

2023-06-09 13:12:24

- reply

📅 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

2023-06-09 13:08:46

- reply

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

2023-06-09 13:08:45

- reply

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

2023-06-09 13:08:30

- reply

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

2023-06-09 13:08:30

- reply

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

2023-06-09 13:08:10

- reply

📅 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

2023-06-09 13:08:05

- reply

📅 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

2023-06-09 13:07:47

- reply

📅 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

2023-06-09 13:07:31

- reply

📅 Original date posted:2022-12-01
📝 Original message:
Good morning Antoine,
> About secondary-markets, the credentials themselves are subject to the classic double-spend problem. E.g, Alice can transfer her "Ned" credentials both to Bob and Caroll, without any of them getting knowledge of the duplication. So it could be expected secondary markets to only happen between LSP and their spokes (where "trust" relationships already exist), as such harder to formalize.
If this is a problem, would the use of the WabiSabi technique help?
If my understanding was correct, the WabiSabi paper described a Chaumian bank that issues coins of variable amount, with clients able to merge and split coins without revealing the amount to the bank/issuer, while allowing for non-double-spendable transfer of coins by having the bank sign off on all transfers between clients (without the bank becoming aware of the value being transferred or the pseudonyms of either client).
If transfer of tokens can be made non-double-spendable, then it may be feasible for a forwarding node to accept tokens issued by a different forwarding node, if the sender also transfers control of those tokens to the forwarding node.
i.e. if a sender has credentials for node A but needs to forward via node B, then node B may be willing to accept credentials issued by node A.
This is similar to the situation where "free banks", in the absence of a central bank, are willing to accept paper bearer bonds issued by another bank, as this lets them attack the other bank by withdrawing the value backing the bond and attempt to trigger a bank run on that other bank (and thus remove them from competition).
Similarly, node B who is a competitor of node A may be willing to accept credentials issued by node A, in a forward that goes through node B, as the transferred credentials would allow node B to perform a jamming attack on node A (and thus remove them from competition).
Both node A and B can then peacefully resolve the difference without attacking via a "clearing house" where they reveal how much of the credential issued by the other they have, in much the same way as free banks would resolve paper bearer bonds.
Regards,
ZmnSCPxj

2023-06-09 13:07:30

- reply

📅 Original date posted:2022-12-01
📝 Original message:
Good morning Antoin, Dave, et al.,
> Hi Dave,
>
> I think the issue you're describing about credential tampering by intermediary nodes is correct. If Alice controls Y along the path W->X->Y->Zed, she can waste the credentials value provided. Indeed, this issue generalizes for any classic payment path, where a routing node can waste the senders credentials allocated on the downstream hops.
Of note is that jamming attacks are mounted by routing nodes against other routing nodes, and a routing node will not *deliberately* attack a payment that goes through them --- doing so sacrifices the potential for fees.
It still remains the case that accidents can happen, and Y could fail completely by accident and cause accidental failure.
Indeed, if any mechanism to protect against channel jamming succeeds, then the remaining instances of apparent channel jamming will be accidental.
Regards,
ZmnSCPxj

2023-06-09 13:07:27

- reply

📅 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

2023-06-09 13:07:27

- reply

📅 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

2023-06-09 13:06:48

- reply

📅 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

2023-06-09 13:06:43

- reply

📅 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

2023-06-09 13:06:23

- reply

📅 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

2023-06-09 13:06:13

- reply

📅 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

2023-06-09 13:06:00

- reply

📅 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

2023-06-09 13:05:58

- reply

📅 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

2023-06-09 13:05:42

- reply

📅 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

2023-06-09 13:05:26

- reply

📅 Original date posted:2022-02-26
📝 Original message:
Good morning Paul,
> I don't think I can stop people from being ignorant about Drivechain. But I can at least allow the Drivechain-knowledgable to identify each other.
>
> So here below, I present a little "quiz". If you can answer all of these questions, then you basically understand Drivechain:
>
> 0. We could change DC to make miner-theft impossible, by making it a layer1 consensus rule that miners never steal. Why is this cure worse than the disease?
Now miners are forced to look at all sideblocks, not optionally do so if it is profitable for them.
> 1. If 100% hashrate wanted to steal coins from a DC sidechain *as quickly as possible*, how long would this take (in blocks)?
13,150 (I think this is how you changed it after feedback from this list, I think I remember it was ~3000 before or thereabouts.)
> 2. Per sidechain per year (ie, per 52560 blocks), how many DC withdrawals can take place (maximum)? How many can be attempted?
> (Ie, how does the 'train track metaphor' work, from ~1h5m in the "Overview and Misconceptions" video)?
I hate watching videos, I can read faster than anyone can talk (except maybe Laolu, he speaks faster than I can process, never mind read).
~4 times (assuming 52560 block per year, which may vary due to new miners, hashrate drops, etc)
> 3. Only two types of people should ever be using the DC withdrawal system at all.
> 3a. Which two?
a. Miners destroying the sidechain because the sidechain is no longer viable.
b. Aggregators of sidechain-to-minechain transfers and large whales.
> 3b. How is everyone else, expected to move their coins from chain to chain?
Cross-system atomic swaps.
(I use "System" here since the same mechanism works for Lightning channels, and channels are not blockchains.)
> 3c. (Obviously, this improves UX.) But why does it also improve security?
Drivechain-based pegged transfers are aggregates of many smaller transfers and thus every transfer out from the sidechain contributes its "fee" to the security of the peg.
> --
> 4. What do the parameters b and m stand for (in the DC security model)?
m is how much people want to kill a sidechain, 0 = everybody would be sad if it died and would rather burn all their BTC forever than continue living, 1 = do not care, > 1 people want to actively kill the sidechain.
b is how much profit a mainchain miner expects from supporting a sidechain (do not remember the unit though).
Something like u = a + b where a is the mainchain, b is the sidechain, u is the total profit.
Or fees? Something like that.
> 5. How can m possibly be above 1? Give an example of a sidechain-attribute which may cause this situation to arise.
The sidechain is a total scam.
A bug may be found in the sidechain that completely negates any security it might have, thus removing any desire to protect the sidechain and potentially make users want to destroy it completely rather than let it continue.
People end up hating sidechains completely.
> 6. For which range of m, is DC designed to deter sc-theft?
m <= 1
> 7. If DC could be changed to magically deter theft across all ranges of m, why would that be bad for sidechain users in general?
Because the sidechain would already be part of mainchain consensus.
> --
> 8. If imminent victims of a DC-based theft, used a mainchain UASF to prohibit the future theft-withdrawal, then how would this affect non-DC users?
If the non-DC users do not care, then they are unaffected.
If the non-DC users want to actively kill the sidechain, they will counterattack with an opposite UASF and we have a chainsplit and sadness and mutual destruction and death and a new subreddit.
> 9. In what ways might the BTC network one day become uncompetitive? And how is this different from caring about a sidechain's m and b?
If it does not enable scaling technology fast enough to actually be able to enable hyperbitcoinization.
Sidechains are not a scaling solution, so caring about m and b is different because your focus is not on scaling.
> --
> 10. If DC were successful, Altcoin-investors would be harmed. Two Maximalist-groups would also be slightly harmed -- who are these?
Dunno!
Regards,
ZmnSCPxj

2023-06-09 13:05:19

- reply

📅 Original date posted:2022-02-18
📝 Original message:
Good morning rusty,
If we are going to switch to a new gossip version, should we prepare now for published channels that are backed by channel factories?
Instead of a UTXO serving as a bond to allow advertisement of a *single* channel, allow it to advertise *multiple* channels.
This does not require us to flesh out the details of channel factories in the gossip protocol, especially post-Taproot --- we could simply require that a simple BIP-340 signature of the gossip message attesting to multiple channels is enough, and the details of the channel factories can be left to later protocol updates.
The reason for this is that for a set of N published nodes, there is an incentive to make as many channels as possible between pairs of nodes.
We expect that for N published nodes, all (N * (N - 1)) / 2 possible channels will be created, as that maximizes the expected fee return of the N published nodes.
Without the ability to gossip channel factories, channel factories can only be used for unpublished channels.
Due to not being available for routing, given an "LSP" and N clients, there is no incentive for the N clients to make direct channels to each other.
(In particular, one of the reasons given for unpublished channels is that the clients of an LSP may not have high onlineness, thus an unpublished channel would really only exist between a public LSP and a non-published client of that LSP.)
This means that for N clients we expect only N channels backed by the channel factory (and thus by the UTXO).
It seems to me to be a good idea to have as much of the public network backed by fewer UTXOs, as the published network has far more channels for every N participants.
(as well, supporting channel factories for the public graph does not preclude the unpublished graph from using channel factories, so even if the unpublished graph turns out to be much larger than the published graph, reducing the UTXO set of the published graph does not prevent reducing the UTXO set of the unpublished graph anyway.)
Against this, we should note that it makes stuffing the public graph cheaper (a single UTXO can now justify the addition of multiple edges on the public routing graph), which translates to making it easier to increase the complexity of the public graph and thus increase the cost of pathfinding.
Thoughts?
Regards,
ZmnSCPxj

2023-06-09 13:04:52

- reply

📅 Original date posted:2021-12-17
📝 Original message:
Good morning cdecker,
> I was looking into the docs [1] and stumbled over `createinvoice` which does almost what you need. However it requires the preimage, and stores the invoice in the database which you don't want.
Indeed, that is precisely the issue, we need a `signfakeinvoice` command, as we cannot know at invoice creation time the preimage, and our invoice database currently assumes every invoice has a preimage known and recorded in the database.
>
> However if you have access to the `hsm_secret` you could sign in the plugin itself, completely sidestepping `lightningd`. Once you have that it should be a couple of days work to get a PoC plugin for the coordination and testing. From there it depends on how much polish you want to apply and what other systems you want to embed it into.
Well, the point of an `hsmd` is that it might be replaced with a driver to an actual hardware signing module (H S M).
The `lightningd`<->`hsmd` interface includes commands for invoice signing, and `signfakeinvoice` would essentially just expose that interface, so an HSM has to support that interface.
So a plugin cannot rely on `hsm_secret` existing, as the signer might not be emulated in software (i.e. what we do now) but be an actual hardware signer that does not keep the secret keys on the same disk.
This is the reason why we (well, I) created and exposed `getsharedsecret`, in theory a plugin could just read `hsm_secret`, but we want to consider a future where the HSM is truly a hardware module.
Regards,
ZmnSCPxj

2023-06-09 13:04:51

- reply

📅 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

2023-06-09 13:04:37

- reply

📅 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

2023-06-09 13:04:37

- reply

📅 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

2023-06-09 13:04:36

- reply

📅 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

2023-06-09 13:04:30

- reply

📅 Original date posted:2021-11-24
📝 Original message:
Good morning x raid,
> We are talkin interoperability among impl not individual node operators version management of chosen impl.
>
> where Pierre of Acinq says
> "So we eat our own dog food and will experience force closes before our users do.."
> hahaha made my day ...
>
> a node operator do tests live in its continuous integration efforts would be expected and should be able do so with a by impl assured latest stable release version.
>
> what is suggested for dialog is the different impl maintainers before sign off a stable release do a extra test live on mainnet with liquidity in channels towards the other impl versions and by doing so can catch unforseen glitches that tests of impl in isolation can not catch.
***We developers already ARE running nodes that are connected to other implementations, on mainnet, 24/7.***
In practice we have large release windows before we actually make a final release, precisely to catch these kinds of bugs that are not easily visible in isolation, but need real data on the network.
My own node (C-Lightning) has channels to LNBIG (lnd), and I suspect at least some of the unpublished channels made to me are Electrum, for example, so I already have a node that is already running against other implementations.
We have been telling you that over several emails already.
Is there any specific thing you can offer?
Put up hardware and coins yourself if you really want this to happen.
I can give you an SSH key so I can install C-Lightning and CLBOSS on your hardware myself, then give you the addresses of the C-Lightning node so you can provide coins for CLBOSS to manage.
Regards,
ZmnSCPxj

2023-06-09 13:04:29

- reply

📅 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

2023-06-09 13:04:28

- reply

📅 Original date posted:2021-11-23
📝 Original message:
Good morning x-raid,
> what i can imagine is each team should provide boxes and channel liquidity as stake on mainnet for tests before announce a public realise as to feel the pain first hand instead of having several K´s of plebs confused and at worst have funds in channelclosed etc. but mostly for helping in smooth transitioning into future envisioned mass.
Not all members of all teams are independently wealthy, and cannot afford significant liquidity on mainnet, or can afford good Internet connection and keeping a device operational 24/7.
For example, for some time I was a C-Lightning core developer, yet did not run a C-Lightning node myself, relying on sheer code review, because I could not afford to run a node.
What you imagine would raise the barrier towards contribution (i.e. I might not have been able to start contributing to C-Lightning in the first place, for example).
I think you misunderstand the open-source model.
If you have the skill, but not the money, you can contribute directly.
If you do not have the skill, but do have the money, you can contribute that by hiring developers to work on the project you want.
So, if you are using a particular open-source implementation and storing your funds with it, either:
* You have the 1337 skillz0rs: you contribute review and actual code.
* You do not have the 1337 skillz0rs: you contribute hardware and testing reports and possibly money.
If the several Ks of plebs are confused, they can aggregate their resources and fund one or two developers to review and contribute to the project they are using, and maybe some hardware and coins for boxes they keep running.
At my point of view, the Real Issue (TM) here is how to aggregate the will of a group of people, without risking that some centralized "manager" of resources gets incentives that diverge from the group of people and starts allocating resources in ways that the group of people would, in aggregate, disagree with.
>
> If teams rather outsource the running of boxes with channels on mainnet for impl release and rc versions they would of course be able to, but close to home for managing analysis of the team impl themselves is what I would recommend.
>
> Can also see that each box loglines are collected at one central point whereby requests can be made for comparing interoperability per unix.ts identified by box.
> (thats alot of data You say --not really in Big Data terms, question is where to set a proper cap in time for collections ? a week ? a month ?)
> I think i might have a solution for the central point collector that could be run by an outside of impl teams perimeter. (sponsored?)
See, if the money on the node is my own, and not contributed by the group that is going to receive the logs, I am not going to send the logs verbatim to them, nope not nada.
I do not want to become a target, because logs leak information like who my channel counterparties are and how often I forward HTLCs and exact dates and times of each event, and thus can be used to locate my node, and location is the first step to targeted attack.
I mean I use a frikkin set of 8 random letters, come on.
Possibly if the logs had sensitive information redacted (even dates and times??), but we need to automate that redaction, and in particular, if the implementation changes log messages, we need to ensure that changed log messages do not leak information that gets past the automated redaction.
Regards,
ZmnSCPxj

2023-06-09 13:04:27

- reply

📅 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

2023-06-09 13:04:27

- reply

📅 Original date posted:2021-11-23
📝 Original message:
Good morning again x-raid,
Are you proposing as well to provide the hardware and Internet connection for these boxes?
I know of one person at least who runs a node that tracks the C-Lightning master (I think they do a nightly build?), and I run a node that I update every release of C-Lightning (and runs CLBOSS as well).
I do not know the actual implementations of what they connect to, but LND is very popular on the network and LNBIG is known to be an LND shop, and LNBIG is so pervasive that nearly every long-lived forwarding node has at least one channel with *some* LNBIG node.
I consider this "good enough" in practice to catch interop bugs, but some interop bugs are deeper than just direct node-to-node communications.
For example, we had bugs in our interop with LND `keysend` before, by my memory.
Regards,
ZmnSCPxj

2023-06-09 13:04:26

- reply

📅 Original date posted:2021-11-22
📝 Original message:
Good morning Dave,
> If LN software speculatively chooses a series of attempts with a similar
> 95%, accounting for things like the probability of a stuck payment (made
> worse by longer CLTV timeouts on some paths), it could present users
> with the same sort of options:
>
> ~1 second, x fee
> ~3 seconds, y fee
> ~10 seconds, z fee
>
> This allows the software to use its reliability scoring efficiently in
> choosing what series of payment attempts to make and presents to the
> user the information they need to make a choice appropriate for their
> situation. As a bonus, it makes it easier for wallet software to move
> towards a world where there is no user-visible difference between
> onchain and offchain payments, e.g.:
>
> ~1 second, w fee
> ~15 seconds, x fee
> ~10 minutes, y fee
> ~60 minutes, z fee
This may not match ideally, as in the worst case a forwarding might be struck by literal lightning and dropped off the network while your HTLC is on that node, only for the relevant channel to be dropped onchain days later when the timeout comes due.
Providing this "seconds" estimate does not prepare users for the possibility of such black swan events where a high fee transaction gets stalled due to an accident on the network.
On the other hand, humans never really handle black swan events in any reasonably way anyway, and 95% of the time it will probably achieve that number of estimated seconds or less.
Even the best onchain estimators fail when a thundering herd of speculators decides to trade Bitcoin based on random crap from the noosphere.
The processing to figure out a payment plan also becomes significant at the "seconds" level, especially if you switch to mincostflow rather than shortestpath.
This means the CPU speed of the local node may become significant, or if you are delegating pathfinding to a trusted server, the load on that trusted server becomes significant.
Sigh.
Why not just ask for a fee budget for a payment, and avoid committing ourselves to paying within some number of seconds, given that the seconds estimate may very well vary depending on local CPU load?
Would users really complain overmuch if the number of seconds is not provided, given that we cannot really estimate this well?
Regards,
ZmnSCPxj

2023-06-09 13:04:24

- reply

📅 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

2023-06-09 13:04:17

- reply

📅 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

2023-06-09 13:04:15

- reply

📅 Original date posted:2021-10-13
📝 Original message:
Good morning Matt,
> On 10/13/21 02:58, ZmnSCPxj wrote:
>
> > Good morning Matt,
> >
> > > The Obvious (tm) solution here is PTLCs - just have the sender always add some random nonce * G to
> > > the PTLC they're paying and send the recipient a random nonce in the onion. I'd generally suggest we
> > > just go ahead and do this for every PTLC payment, cause why not? Now the sender and the lnurl
> > > endpoint have to collude to steal the funds, but, like, the sender could always just give the lnurl
> > > endpoint the money. I'd love suggestions for fixing this short of PTLCs, but its not immediately
> > > obvious to me that this is possible.
> > >
> >
> > Use two hashes in an HTLC instead of one, where the second hash is from a preimage the sender generates, and which the sender sends (encrypted via onion) to the receiver.
> > You might want to do this anyway in HTLC-land, consider that we have a `payment_secret` in invoices, the second hash could replace that, and provide similar protection to what `payment_secret` provides (i.e. resistance against forwarding nodes probing; the information in both cases is private to the ultimate sender and ultimate reeceiver).
>
> Yes, you could create a construction which does this, sure, but I'm not sure how you'd do this
> without informing every hop along the path that this is going on, and adapting each hop to handle
> this as well. I suppose I should have been more clear with the requirements, or can you clarify
> somewhat what your proposed construction is?
Just that: two hashes instead of one.
Make *every* HTLC on LN use two hashes, even for current "online RPi user pays online RPi user" --- just use the `payment_secret` for the preimage of the second hash, the sender needs to send it anyway.
>
> If you're gonna adapt every node in the path, you might as well just use PTLC.
Correct, we should just do PTLCs now.
(Basically, my proposal was just a strawman to say "we should just do PTLCs now")
Regards,
ZmnSCPxj

2023-06-09 13:04:14

- reply

📅 Original date posted:2021-10-13
📝 Original message:
Good morning Matt,
> The Obvious (tm) solution here is PTLCs - just have the sender always add some random nonce * G to
> the PTLC they're paying and send the recipient a random nonce in the onion. I'd generally suggest we
> just go ahead and do this for every PTLC payment, cause why not? Now the sender and the lnurl
> endpoint have to collude to steal the funds, but, like, the sender could always just give the lnurl
> endpoint the money. I'd love suggestions for fixing this short of PTLCs, but its not immediately
> obvious to me that this is possible.
Use two hashes in an HTLC instead of one, where the second hash is from a preimage the sender generates, and which the sender sends (encrypted via onion) to the receiver.
You might want to do this anyway in HTLC-land, consider that we have a `payment_secret` in invoices, the second hash could replace that, and provide similar protection to what `payment_secret` provides (i.e. resistance against forwarding nodes probing; the information in both cases is private to the ultimate sender and ultimate reeceiver).
In addition, I suspect (but have not worked out yet) that this would allow some kind of Barrier Escrow-like mechanism while still in HTLC-land.
Otherwise, just PTLC, man, everyone wants PTLC.
Regards,
ZmnSCPxj

2023-06-09 13:04:08

- reply

📅 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

2023-06-09 13:04:07

- reply

📅 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

2023-06-09 13:04:06

- reply

📅 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

2023-06-09 13:03:55

- reply

📅 Original date posted:2021-10-07
📝 Original message:
Good morning e,
> mostly thinking out loud
>
> suppose there is a "lightweight" node:
>
> 1. ignores utxo's below the dust limit
> 2. doesn't validate dust tx
> 3. still validates POW, other tx, etc.
>
> these nodes could possibly get forked - accepting a series of valid,
> mined blocks where there is an invalid but ignored dust tx, however
> this attack seems every bit as expensive as a 51% attack
How would such a node treat a transaction that spends multiple dust UTXOs and creates a single non-dust UTXO out of them (after fees)?
Is it valid (to such a node) or not?
I presume from #1 it never stores dust UTXOs, so the node cannot know if the UTXO being spent by such a tx is spending dust, or trying to spend an already-spent TXO, or even inventing a TXO out of `/dev/random`.
Regards,
ZmnSCPxj

2023-06-09 13:03:48

- reply

📅 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

2023-06-09 13:03:48

- reply

📅 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

2023-06-09 13:03:48

- reply

📅 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

2023-06-09 13:03:45

- reply

📅 Original date posted:2021-09-20
📝 Original message:
Good morning SomberNight,
> Solutions:
>
> 1. Naively, we could just derive a static key to be used as
> payment_basepoint, reused between all our channels, and watch the
> single resulting p2wsh script on-chain.
> Clearly this has terrible privacy implications.
If the only problem is horrible privacy, and you have an `OP_RETURN` identifying the channel counterparty node id anyway, would it not be possible to tweak this for each channel?
static_payment_basepoint_key + hash(seed | counterparty_node_id)
This (should) result in a unique key for each counterparty, yet each individual counterparty cannot predict this tweak (and break your privacy by deriving the `static_payment_basepoint_key * G`).
?
Regards,
ZmnSCPxj

2023-06-09 13:03:38

- reply

📅 Original date posted:2021-08-30
📝 Original message:
Good morning list,
It seems to me that the cost function defined in Pickhard-Richter
can in fact include a base fee:
-log(success_probability) + fudging_factor * amount * prop_fee + fudging_factor * base_fee
(Rant: why do mathists prefer single-symbol var names, in software
engineering there is a strong injunction **against** single-char
var names, with exceptions for simple numeric iteration loop vars,
I mean keeping track of the meaning of each single-symbol var name
takes up working memory space, which is fairly limited on a wetware
CPU, which is precisely why in software engineering there is an
injunction against single-char var names, srsly.)
It seems to me that the above is "convex", as the `fudging_factor`
for a run will be constant, and the `base_fee` for the channel
would also be constant, and since it seems to me, naively, that
the paper defines "convex" as "the second derivative >= 0 for all
`amount`", and since the derivative of a constant is 0, the above
would still remain convex.
(I am not a mathist and this conjecture might be completely asinine.)
So, it seems to me that the *real* reason for `#zerobasefee` is
not that the **mincostflow** algorithm cannot handle non-zero `base_fee`,
but rather, the **disect** phase afterwards cannot handle non-zero
`base_fee`.
For example, suppose the minflowcost algorithm were instructed to
deliver 3,000msat from `S` to `D`, and returned the following flow:
S -->3000--> A ->1000-> B
| |
| 1000
| v
+-->2000-> C ->3000-> D
In the "disect" phase afterwards, the above flow solution would have
to be split into two sub-payments, a 1000 sub-payment `S-A-B-C-D`
and a 2000 sub-payment `S-A-C-D`.
However, this does mean that the base cost for `C->D` and `S->A` in
the above flow will pay *twice* the base cost than what the above
cost function would have computed, because in reality two independent
payments pass through those channels.
Thus, the current Pickhardt-Richter scheme cannot work with non-zero
base fees if it were modified to consider fees, but not due to the
mincostflow algorithm, rather because due to the disect algorithm.
### Converting Non-Zero Base Fees To Proportional Fees
An alternative solution would be to optimize for a *maximum* fee
rather than optimize for the *exact* fee.
We can do this by virtually splitting up the entire payment into
smaller bunches of value, and asking mincostflow to solve individual
bunches rather than individual msats.
For example, we can decide that the smallest practical HTLC would
be 1000 msat.
Let us call this the "payment unit", and the mincostflow algo
solves for paying in these payment units instead of 1msat units.
(Actual implementations would need to have some heuristic or
reasoned rule-of-thumb assumption on what the smallest practical
HTLC would be.)
In our example, suppose we need to send 2001msat from `S` to `D`,
with the payment unit being 1000 msat.
Then we would actually have the mincostflow algorithm work to
deliver 3 payment units (3 * 1000msat) from `S` to `D`.
Let us suppose that the mincostflow algorithm returns the following
flow:
S -->3-----> A ->1----> B
| |
| 1 |
| v
+-->2----> C ->3----> D
Actually, what the mincostflow algorithm uses as a cost function
would be:
-log(success_probability) + fudging_factor * amount * prop_fee * payment_unit + fudging_factor * base_fee * amount
== -log(success_probability) + fudging_factor * amount * (prop_fee * payment_unit + base_fee)
where: amount is in units of 1000msat, our smallest practical HTLC.
payment_unit is the unit, i.e. 1000msat.
What the above means is that the mincostflow algorithm *allocates*
`3 * base_fee` for `C->D`, since the `amount` flowing through
`C->D` would be 3.
However, when we pass the above flow to the disect algorithm, it
would actually only split this into 2 sub-payments, so the
actual payment plan would only pay `2 * base_fee` for the
`C->D` leg on both sub-payments.
In short, this effectively converts the base fee to a proportional
fee, removing the zerobasfee requirement imposed by the disect
algorithm.
That is, the cost computed by the mincostflow algorithm is really a
maximum cost budget that the subsequent disect algorithm could later
spend.
In effect, this converts the base fee to a proportional fee.
This may be acceptable in practice.
This approximation has a bias against non-zerobasefee --- it would
treat those channels as being far more expensive than they actually
would end up being in an *actual* payment attempt --- but at least
does not *require* zerobasefee.
It would be able to still use non-zerobasefee channels if those are
absolutely required to reach the destination.
This should at least help create a practical payment algorithm that
handles current LN with nonzerobasefee, and provide an impetus
towards making zerobasefee a reality.
Note that this approximation would be non-optimal --- there may
be solutions that provide lower costs than the output of this
approximation would provide.
It may be practical to have the payment unit be adjustable by a
higher-level (but still automated) process.
For example, it may be considered that having more than 500 splits
would be heuristically determined to be impractical, in which
case the payment unit could be the actual amount divided by 500
rounded up.
Then if that results in extreme overestimation of base costs
(i.e. the subsequent disect stage results in far fewer than 500
splits) the payment unit could be adjusted upwards.
Similarly, if that results in a payment plan that has high
base fees, the payment unit could be adjusted downwrds.
--
Similarly, having particular split amounts is helpful to reduce
the ability of intermediate nodes snooping on payment amounts,
so having a particular fixed payment unit may also be useful
nevertheless, even if this approximation is otherwise undesirable.
That is, in the above example, we just send 3 sub-payments
instead of the minimum 2, so that every sub-payment is always
uniformly 1000msat.
This leaks the least amount of information to intermediate nodes,
especially after payment decorrelation is widely deployed.
(this is the same principle for why a uniform unit amount is
needed in practical CoinJoin implementations; it increases the
anonymity set of individual sub-payments.)
This would be helped greatly by payment decorrelation;
intermediate nodes would remain uncertain that multiple
HTLCs with the same amount and the same in-channel and
out-channel are from the same overall payment or not.
Assuming many software uses the same payment unit consistently,
less information can be extracted by surveillors, and the
increased cost may be considered justifiable in paying for
additional privacy.
--
### Whole-flow Payments
Suppose we were to instead modify the LN protocol such that,
instead of MPP having individual sub-payments that split at the
source and join at the destination, we allow the source to
instruct arbitrary intermediate nodes to join and/or split
payments.
That is, suppose LN allowed the source to indicate to arbitrary
forwarding nodes to split payments and join them.
(This would require nearly all nodes to upgrade, which may be
impractical, but let us consider its implications first without
committing to actually doing this.)
A node that is a join node would be instructed to wait for all
incoming HTLCs to arrive before they create any outgoing
HTLCs.
A node that is a split node would make more than one outgoing
HTLCs.
Forwarding nodes can be both join and split nodes.
This would allow the output of the mincostflow algorithm to be
used directly, without the problematic disect stage.
Nodes that have more than one in-flow would be join nodes,
while nodes with more than one out-flow would be split nodes.
Returning to the example:
S -->3000--> A ->1000-> B
| |
| 1000
| v
+-->2000-> C ->3000-> D
In the above, `S` sends a *single* payment out on channel
`S->A`, and instructs `A` to split the payment.
Then `S` also instructs `C` to join two payments, resulting
in a single HTLC out on `C->D` if `C` receives on both
`A->C` and `B->C`.
The effect is that, for a single payment plan (presented as a
flow, outputted by a mincostflow algorithm) for each channel
with nonzero flow, there would only be one HTLC that gets paid
for using a single `base_fee`.
Then, the base fee computed by the cost function would be exact
and there would be no underestimation of the base fee for
non-zerobasefee channels.
Let us then consider the practicality of this scheme.
If a hop were to fail to deliver, then some join nodes would
be left hanging, waiting for an incoming HTLC that will not
arrive.
The failure would have to be handled by a split node, when it
receives a `update_fail_htlc`.
That split node cannot propagate the failure backwards to the
source, since it would still have other outgoing HTLCs in
play, which it cannot safely ignore; it can only propagate
the failure backwards if all the other outgoing HTLCs also
fail.
To support this, a split node could give a request-to-fail
signal to its other outgoing HTLCs.
Then, any other join nodes still waiting for an incoming
HTLC (and would not yet have created any outgoing HTLCs,
or for the destination, would not have claimed any incoming
HTLCs) would fail all its incoming HTLCs.
Otherwise, an intermediate node receiving a request-to-fail
signal from any incoming HTLCs would simply propagate
this request-to-fail outwards to all its outgoing HTLCs.
This implies that for this scheme, if *any* hop fails, the
entire payment fails and has to be restarted "from the top".
This is in contrast with the current scheme of splitting
only at the source and joining only at the destination.
In the current LN, if *any* hop of an MPP fails, only the
sub-payment(s) going through that hop will need to be
retried.
Other sub-payment(s) can keep being "in play", and the
source, having all the information needed, only needs to
recompute the failing outgoing payments.
On the other hand, the same information (particular hops are
failing) would be propagated back to the source, and the
source having to recompute the entire flow rather than just
some subset of the payments is not much worse computationally
(work is still dominated by `O((m*m+m*n)*log n)` where `m` is
the channels of the *entire network* and `n` is the nodes
of the *entire network*, amount is just a piddling little
`O(log(u))` term).
It also removes the need to virtually reduce the capacity of
intermediate hops while other sub-payments are in play
(however, a practical implementation would need to consider
the possibility of multiple *simultaneous* outgoing payments
anyway and would still retain this reduction of capacity in
case a new parallel outgoing payment is triggered while one
is still ongoing).
This leads us to some fairly interesting choices:
* [ ] Whole-flow payment is a brilliant idea and we should
totally do it. `#deletethezerobasefeedebate`
* [ ] Whole-flow payment is a horrible idea and we should
totally not do it.
* [ ] As we can see, the LN community needs to get together
for better payment success, and supporting whole-flow
payments is worse than setting `basefee=0`. `#zerobasefee`
* [ ] As we can see, the current LN provides a vital service
(partial failure of MPP) and intermediate nodes need to be
compensated for this service. `#nonzerobasefee`
Regards,
ZmnSCPxj

2023-06-09 13:03:36

- reply

📅 Original date posted:2021-08-31
📝 Original message:
Good morning aj and Rene,
> On Thu, Aug 26, 2021 at 04:33:23PM +0200, René Pickhardt via Lightning-dev wrote:
>
> > As we thought it was obvious that the function is not linear we only explained
> > in the paper how the jump from f(0)=0 to f(1) = ppm+base_fee breaks convexity.
>
> (This would make more sense to me as "f(0)=0 but f(epsilon)->b as
> epsilon->0, so it's discontinuous")
I as well, "discontinuous" is how I would understand it, and it really needs to be pointed out to me that f(0)=0 and the sudden step to f(1)=1*prop + base is problematic.
>
> > "Do we really want users to solve an NP-hard problem when
> > they wish to find a cheap way of paying each other on the Lightning Network?"
>
> FWIW, my answer to this is "sure, if that's the way it turns out".
>
> Another program which solves an NP-hard problem every time it runs is
> "apt-get install" -- you can simulate 3SAT using Depends: and Conflicts:
> relationships between packages.
Thank you for this, I now understand why functional package managers like Nix and Guix etc. exist.
> I worked on a related project in Debian
> back in the day that did a slightly more complicated variant of that
> problem, namely working out if updating a package in the distro would
> render other packages uninstallable (eg due to providing a different
> library version) -- as it turned out, that even actually managed to hit
> some of the "hard" NP cases every now and then. But it was never really
> that big a deal in practice: you just set an iteration limit and consider
> it to "fail" if things get too complicated, and if it fails too often,
> you re-analyse what's going on manually and add a new heuristic to cope
> with it.
>
> I don't see any reason to think you can't do roughly the same for
> lightning; at worst just consider yourself as routing on log(N) different
> networks: one that routes payments of up to 500msat at (b+0.5ppm), one
> that routes payments of up to 1sat at (b+ppm), one that routes payments
> of up to 2sat at (b+2ppm), one that routes payments of up to 4sat at
> (b+4ppm), etc. Try to choose a route for all the funds; if that fails,
> split it; repeat. In some case that will fail despite there being a
> possible successful multipath route, and in other cases it will choose a
> moderately higher fee path than necessary, but if you're talking a paying
> a 0.2% fee vs a 0.1% fee when the current state of the art is a 1% fee,
> that's fine.
Well, something similar is already done by C-Lightning, and the `pay` algorithm even includes a time limit after which it just fails instead of retrying (roughly equivalent to setting an iteration limit, and actually more practical since it is not the number of CPU iterations that matters, it is real time during which user economic preferences may change).
And for large enough payments, it *still* does not succeed often enough in practice.
I pointed out elsewhere that failure-to-pay has an economic cost.
This economic cost is the difference between the value of the product being bought, minus the value of the bitcoin being used to pay for it.
(remember, economic value is subjective to every economic actor; the economy is simply how the differences in value plays out as actors exchange objects, where each actor has its own subjective valuation of that value.)
We can ask the user explicitly for a numeric amount equivalent to this cost, by the simple question "how much are you willing to pay in order for this transaction to succeed?" i.e. "what is the maximum transaction fee you will accept?"
Thus, failing to deliver imposes an economic cost on users, a cost that Lightning Network, rightfully or not, has implicitly promised to reduce in comparison to onchain transactions.
For myself, I think a variant of Pickhardt-Richter payments can be created which *adapts to* the reality of the current network where `base_fee > 0` is common, but is biased against `base_fee > 0`, can be a bridge from the current network with `base_fee > 0` and a future with `#zerobasefee`.
With C-Lightning and its plugin nature allowing alternate implementations of `pay`, this can be done without requiring an entire new LN implementation.
If popular enough, because it demonstrates actual ability to transfer large funds at low fees, this can force forwarding nodes to learn that `#zerobasefee` earns them more funds (such as if they use a hill-climbing algorithm like I described to discover optimal feerates that gives them maximum earnings).
Then `#zerobasefee` just wins economically.
So I think this really just needs a good implementation somewhere.
Regards,
ZmnSCPxj

2023-06-09 13:03:33

- reply

📅 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

2023-06-09 13:03:33

- reply

📅 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

2023-06-09 13:03:32

- reply

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

2023-06-09 13:03:29

- reply

📅 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

2023-06-09 13:03:28

- reply

📅 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

2023-06-09 13:03:26

- reply

📅 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

2023-06-09 13:03:25

- reply

📅 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

2023-06-09 13:03:20

- reply

📅 Original date posted:2021-08-21
📝 Original message:
Good morning Jeremy,
> one interesting point that came up at the bitdevs in austin today that favors remove that i believe is new to this discussion (it was new to me):
>
> the argument can be reduced to:
>
> - dust limit is a per-node relay policy.
> - it is rational for miners to mine dust outputs given their cost of maintenance (storing the output potentially forever) is lower than their immediate reward in fees.
> - if txn relaying nodes censor something that a miner would mine, users will seek a private/direct relay to the miner and vice versa.
> - if direct relay to miner becomes popular, it is both bad for privacy and decentralization.
> - therefore the dust limit, should there be demand to create dust at prevailing mempool feerates, causes an incentive to increase network centralization (immediately)
>
> the tradeoff is if a short term immediate incentive to promote network centralization is better or worse than a long term node operator overhead.
Against the above, we should note that in the Lightning spec, when an output *would have been* created that is less than the dust limit, the output is instead put into fees.
https://github.com/lightningnetwork/lightning-rfc/blob/master/03-transactions.md#trimmed-outputs
Thus, the existence of a dust limit encourages L2 protocols to have similar rules, where outputs below the dust limit are just given over as fees to miners, so the existence of a dust limit might very well be incentivize-compatible for miners, regardless of centralization effects or not.
Regards,
ZmnSCPxj

2023-06-09 13:03:19

- reply

📅 Original date posted:2021-08-10
📝 Original message:
Good morning all,
Thinking a little more, if the dust limit is intended to help keep UTXO sets down, then on the LN side, this could be achieved as well by using channel factories (including "one-shot" factories which do not allow changing the topology of the subgraph inside the factory, but have the advantage of not requiring either `SIGHASH_NOINPUT` or an extra CSV constraint that is difficult to weigh in routing algorithms), where multiple channels are backed by a single UTXO.
Of course, with channel factories there is now a greater set of participants who will have differing opinions on appropriate feerate.
So I suppose one can argue that the dust limit becomes less material to higher layers, than actual onchain feerates.
Regards,
ZmnSCPxj

2023-06-09 13:03:18

- reply

📅 Original date posted:2021-08-10
📝 Original message:
Good morning Billy, et al.,
> For sure, CT can be done with computational soundness. The advantage of unhidden amounts (as with current bitcoin) is that you get unconditional soundness.
My understanding is that it should be possible to have unconditional soundness with the use of El-Gamal commitment scheme, am I wrong?
Alternately, one possible softforkable design would be for Bitcoin to maintain a non-CT block (the current scheme) and a separately-committed CT block (i.e. similar to how SegWit has a "separate" "block"/Merkle tree that includes witnesses).
When transferring funds from the legacy non-CT block, on the legacy block you put it into a "burn" transaction that magically causes the same amount to be created (with a trivial/publicly known salt) in the CT block.
Then to move from the CT block back to legacy non-CT you would match one of those "burn" TXOs and spend it, with a proof that the amount you are removing from the CT block is exactly the same value as the "burn" TXO you are now spending.
(for additional privacy, the values of the "burn" TXOs might be made into some fixed single allowed value, so that transfers passing through the CT portion would have fewer identifying features)
The "burn" TXOs would be some trivial anyone-can-spend, such as `<saltpoint> <0> OP_EQUAL OP_NOT` with `<saltpoint>` being what is used in the CT to cover the value, and knowledge of the scalar behind this point would allow the CT output to be spent (assuming something very much like MimbleWimble is used; otherwise it could be the hash of some P2WSH or similar analogue on the CT side).
Basically, this is "CT as a 'sidechainlike' that every fullnode runs".
In the legacy non-CT block, the total amount of funds that are in all CT outputs is known (it would be the sum total of all the "burn" TXOs) and will have a known upper limit, that cannot be higher than the supply limit of the legacy non-CT block, i.e. 21 million BTC.
At the same time, *individual* CT-block TXOs cannot have their values known; what is learnable is only how many BTC are in all CT block TXOs, which should be sufficient privacy if there are a large enough number of users of the CT block.
This allows the CT block to use an unconditional privacy and computational soundness scheme, and if somehow the computational soundness is broken then the first one to break it would be able to steal all the CT coins, but not *all* Bitcoin coins, as there would not be enough "burn" TXOs on the legacy non-CT blockchain.
This may be sufficient for practical privacy.
On the other hand, I think the dust limit still makes sense to keep for now, though.
Regards,
ZmnSCPxj

2023-06-09 13:03:00

- reply

📅 Original date posted:2021-07-04
📝 Original message:
Good morning Rusty et al,
> Matt Corallo lf-lists at mattcorallo.com writes:
>
> > Thanks!
> > On 6/29/21 01:34, Rusty Russell wrote:
> >
> > > Hi all!
> > >
> > > John Carvalo recently pointed out that not every implementation
> > >
> > >
> > > accepts zero-conf channels, but they are useful. Roasbeef also recently
> > > noted that they're not spec'd.
> > > How do you all do it? Here's a strawman proposal:
> > >
> > > 1. Assign a new feature bit "I accept zeroconf channels".
> > > 2. If both negotiate this, you can send update_add_htlc (etc) before
> > > funding_locked without the peer getting upset.
> > >
> >
> > Does it make sense to negotiate this per-direction in the channel init message(s)? There's a pretty different threat
> > model between someone spending a dual-funded or push_msat balance vs someone spending a classic channel-funding balance.
>
> channel_types fixes this :)
>
> Until then, I'd say keep it simple. I would think that c-lightning will
> implement the "don't route from non-locked-in channels" and always
> advertize this option. That means we're always offering zero-conf
> channels, but that seems harmless:
>
> - Risks for funder is that channel never confirms, but it probably ignores
> the risk because it can close onchain (annoying, and fee-heavy, but not
> loss of funds caused by peer).
>
> - Risks for fundee (or DF channels where peer contributes any funds) is
> that funder doublespends, so HTLCs must not be routed out to others
> (unless you have other reason to trust peer).
Mostly nitpick on terminology below, but I think text substantially like the above should exist in some kind of "rationale" section in the BOLT, so ---
In light of dual-funding we should avoid "funder" and "fundee" in favor of "initiator" and "acceptor".
However, we should also note that the substantial feature of turbo channels is ***not*** in channel opening per se, it is the *confirmation* of the channel.
Once the opening ritual has completed and the funding tx broadcast, that is when turbo channels come in, so it actually does not matter which peer is "initiator" and which is "acceptor" at that point, the opening ritual has completed.
Both peers, at the end of the opening ritual, have a valid commitment tx and both can double-spend the funds they put in to back out of the channel.
So what matters for the above rationale is the "sender" of an HTLC and the "receiver" of an HTLC, not really who is acceptor or initiator.
* Risks for HTLC sender is that the channel never confirms, but it probably ignores the risk because it can close onchain (annoying, and fee-heavy, but not loss of funds caused by peer).
* Risks for HTLC receiver is that the channel never confirms, so HTLC must not be routed out to others or resolved locally if the receiver already knows the preimage, UNLESS the HTLC receiver has some *other* reason to trust the peer.
Basically:
* "funder" and "fundee" are legacy terms that predate dual-funding and are depreciated.
In modern terms, the "funder" is the "initiator" and the "fundee" is the "acceptor", and in a legacy pre-dua-funding channel, only the initiator can start putting funds into the channel.
* "initiator" is the peer that starts the opening process, and pays for the opening fees.
* "acceptor" is the peer that is contacted by the initiator and decides whether to allow the creation of a channel with the initiator, and pays no opening fees.
* "HTLC sender" is any peer that, *after* the channel opening completes (but possibly before it is locked in), offers an HTLC to the peer.
* "HTLC receiver" is any peer that, *after* the channel opening completes (but possibly before it is locked in), is the one who accepts the HTLC from the HTLC sender.
Regards,
ZmnSCPxj

2023-06-09 13:02:44

- reply

📅 Original date posted:2021-06-29
📝 Original message:
Good morning lisa,
> A dedicated attacker could probably figure out your UTXO set, but that's not
> much different from the current system; the only difference is the span of time
> it takes them to figure it out.
>
> ## Things We've Done to Counter This:
> I had the pleasure of finally meeting Nadav of SuredBits and DLC fame in Miami
> a few weeks ago. The DLC team has adopted a version of the interactive
> transaction protocol for their own purposes. Nadav pointed out that the
> protocol we landed on for lightning interactive construction transactions
> is *quite* interactive; the DLC version modified it to use batching to
> transmit the input/output sets (the interactive protocol is one-by-one).
>
> The rationale for doing the addition of inputs and outputs in a non-batched
> fashion is that this allows for you to interleave UTXOs from a variety
> of sources, for example multiple channel opens in the same tx. With the current
> protocol, you can initiate a dual-funded open with many peers at the same time,
> each of which may contribute UTXOs and outputs for their own respective
> channel opens or UTXO consolidations etc.
>
> This gives us the real possibility of doing multiparty coinjoins on lightning.
> In fact, this is currently possible with c-lightning *today* using
> the multifundchannel command (h/t to ZmnSCPjx for the original framework
> for multifund opens).
>
> As written, the interactive transaction protocol is exceedingly flexible.
> We traded off succinctness for some plausible deniablity wrt
> any UTXOs you send to any peer -- are they yours or are they
> some third party's? How to tell?
>
> I think it's interesting to point out that "succinctness" in rounds
> of required interaction is typically a *highly* desirable trait for
> any cryptographic protocol. The establishment of a lightning channel relationship,
> however, isn't a cryptographic signature. A lightning channel, by its very
> nature, is typically a highly interactive relationship between two peers.
> Increasing the rounds of messaging required to establish the channel doesn't
> change the overall interactivity profile of a channel's operation, thus
> adding rounds of comms to channel open is generally a no-op in terms of
> performance/uptime requirements of a node's operations.
Possibly, a difference between the DLC use-case and the Lightning use-case is that the DLC use-case has a definite deadline when the contract expires, whereas the Lightning use-case has no definite end termination for the channel.
In addition, DLC requires transmitting significant amounts of data measurable in megabytes, whereas Lightning transmits little 32-byte blobs (well not really mostly 1366-byte onion-wrapped packages but still much tinier than the megabytes of adaptor signatures in DLCs).
So the DLC setup stage getting hit with the optimization hammer (as a collateral damage from the optimization hammer being used on the actual core DLC) seems like a reasonably thing happening in the DLC use-case.
Finally, there is a big enough directory of Lightning nodes that you can reasonably pick up this directory in lots of places, pick some random number of them to channel to, and then make channels to them, and making them in a single tx is always a good thing.
Whereas I imagine that the DLC use-cases (even in the future) are more limited userbase (and with payment points on Lightning I believe the smaller and shorter-term DLCs can run on top of Lightning), so the opportunity to aggregate may be much rarer in DLCs than in Lightning channel opens.
> ## How important is UTXO privacy on lightning?
> Obviously important. But given that the real transactions happen inside
> of channels, invisibly, and that your public channels really truly
> are public via the gossip protocol the much more important "thing" in the
> lightning arena isn't your UTXO privacy so much as *not* associating your
> identity with your node.
I broadly agree here --- published channels trade off onchain privacy (marking "hey this UTXO is totally owned by these two peeps!") but gain offchain privacy ("no, that is not my payment, somebody else asked me to forward it, promise!")
>
> ## Does Taproot fix this?
> I'm not up to date enough on the progress of Taproot scripts, however,
> assuming the current requirement that every routing node is able to independently
> verify the opening output script via the signatures provided
> in the channel_announcement, it seems reasonable that on-chain transactions
> will still be assignable to a node given gossip data. (Purely on-chain analysis
> will be stymied, however.)
Hmm wait Taproot fixes this?
We can drop/reinterpret `short_channel_id` post-Taproot?
Regards,
ZmnSCPxj

2023-06-09 13:02:43

- reply

📅 Original date posted:2021-06-29
📝 Original message:
Good morning elsirion,
> Hi ZmnSCPxj,
>
> let me chime in here, I've been working on federated mint for quite some time now but only recently began talking about it more publicly.
>
> > WabiSabi "simply" replaces blinded signatures with blinded credentials.
> > Blinded signatures are fairly low-bandwidth ---- either you have a blinded signature, or you do not.
> > Credentials, however, also include a blinded homomorphic value.
>
> This is a very intriguing idea Casey actually mentioned to me (at least I think it's about the same problem):
>
> In traditional mints we use tokens of the same denomination. For efficiency reasons amount tiers are introduced, reducing the anonymity set per tier. If we had blind signatures not only on random tokens but they also committed to a separately blinded amount with a range proof that would allow one big anonymity set over all tokens instead. Such tokens could then be combined similarly to Liquid transaction inputs.
>
> I think the concept is very interesting, but for now I see a few obstacles:
>
> - WabiSabi uses KVACs which afaik do not allow client side validation. While I can't say if it will be a big problem it makes detecting certain failure scenarios harder imo.
> - The KVAC scheme referred to in WabiSabi [1] is not a threshold scheme afaik, undermining the central premise of federated mints. If I got that wrong this would be awesome!
> - Building such an enhanced threshold blind signature scheme is more complex and probably needs further research. A naive implementation would be more interactive which in a federated context means waiting for consensus rounds for each round trip which is unappealing.
Well, WabiSabi is effectively n-of-n signing, as the produced transaction has to be signed by all clients of the coordinator, so threshold federated signatures are not necessary.
So yes, the use of credentials seems not possible to the federated mints project.
(note: I am not a mathist and have no idea what the hell credentials are, I only know how to use them)
>
> So while I'm very sympathetic to the idea and want to pursue it in the future, threshold blind signatures seem like the more efficient way to get to a working implementation with still adequate performance and privacy in time.
>
>
> > Now, let us consider the "nodelets" idea as well.
> > The "nodelets" system allows for a coordinator (which can be a separate entity, or, for the reduction of needed entities, any nodelet of the node).
>
> I didn't know of nodelets so far and went back to your 2019 post about it. It seems that blind multisig or threshold credentials (the idea seems to be m-of-m, so doesn't nee a general threshold scheme I guess) would improve the privacy of the system. I think the nodelets idea is very interesting for technical people that would otherwise be priced out of running a LN node in a high-fee future. But the complexity of the protocol and online requirements seem to make it suboptimal for non-technical, disinterested users. While automating a lot of the complexity away is possible (big fan of clboss) it's also a lot of work and probably will take a while if ever to get to a point where the experience is plug-and-play as most non-technical users have come to expect.
>
> In that sense both systems just have different target audiences. I think of federated mints mostly as a replacement for Banks and other custodial services that are used for their superior UX. It is fundamentally a compromise. E.g. Bitcoin Beach currently uses Galoy [2], a centralized hosted LN wallet without much privacy. I don't see a future where everyone there is technical enough to run their own node or nodelet client reliably enough. But if we can allow community driven federations with privacy built-in we can mitigate most of the risks inherent to custodial wallets imo.
>From my PoV, any "bank-replacement" that is inherently custodial will eventually become a bank, with all the problems that implies.
It is helpful to remember that banks have, historically, been federations: they are typically implemented as corporations, which are basically a bunch of people pooling their money and skill together to start a business.
Thus, I argue that banks already *are* federations that take custody of your money and manage it for you.
To my mind, any system that is a federation that takes custody of user money *will* face the same social, political, and economic forces that the legacy banking system faced in the past.
You puny humans simply do not evolve as fast as you think, you know --- your instincts still demand that your body stock up on fat and salt and sugar in a modern era where such things are available in too much abundance that it is killing you, so I imagine that a modern federated system (like Liquid or your federated mints) will face similar forces as past successful financial custodial federations (i.e. the banks of today).
Thus, it seems to me that with high probability, any custodial federated financial system will evolve to a similar state as banks today --- that is, cryptocurrency systems based on custodial federations will just "kick the can", and eventually be the same (with the same pros and cons) as modern banks.
This is not completely negative, since modern banks do provide vital services, but at the same time, one can argue that this is uninteresting in terms of exploration --- i.e. federated custodians have already been done before, they are the banks of today.
That is why CLBOSS exists --- it manages your money for you, but you run it on your own hardware and are responsible for auditing it, so it does *not* take control of your funds.
>
> I really hope that I'm too pessimistic here, but if not I'd rather have a backup plan in the form of federated mints than letting banks eat our lunch. The idea is still early, but I hope some can agree with my reasoning. If so, come and help build this future with me [3]!
Well, I agree that kicking the can down the road is better as a backup plan than not having anything in case we really cannot find a reasonable way to make Bitcoin cheap and easy without losing noncustodiality.
Regards,
ZmnSCPxj

2023-06-09 13:02:42

- reply

📅 Original date posted:2021-06-28
📝 Original message:
Good morning again CAsey,
>
> I believe a major failing of Chaumian mints is that they are, at their core, inherently custodial.
> The mint issues blinded minted coins in exchaange for people handing over other resources to their custody.
> While the mint itself cannot identify who owns how much, it can outright deny all its clients access to their funds and then run off with the money to places unknown.
>
> However, do note that both Wasabi and WabiSabi are extensions of Chaumian mints.
> These avoid the custodiality issue of Chaumian mints by operating the mint as a temporary entity, whose output is then counterchecked by the users of the Wasabi/WabiSabi scheme.
>
> ...
>
> In any case, you might also be interested in the "nodelets" I described some years ago.
> This link has a presentation where I introduce nodelets towards the end, sorry but most of the beginning is about LN pathfinding (which is currently a non-problem since nobody makes published channels anymore).
> This allows multiple users to implement a single node without a central custodian, and may allow for similar flexibility of liquidity if there are enough users, but every action requires all users to have keys online.
Thinking more, it helps to consider how Wasabi and WabiSabi are constructed.
In Wasabi, there exists a coordinator, which is a server that works as a temporary Chaumian mint.
Clients of the coordinator register some UTXOs of some common value to the mint (indicating any change outputs if the UTXO total value exceeds the fixed common value).
Then the coordinator issues blind signatures, which serve as tokens in a Chaumian mint.
Then users re-connect via a different pseudonym, unblind signatures and reclaim the funds, indicating a target output address.
The coordinator then creates a single transaction that consumes the registered input UTXOs and the indicated outputs.
As a *final* step, the clients then check that the produced transaction is correct.
This final step prevents the coordinator from absconding with the funds.
WabiSabi "simply" replaces blinded signatures with blinded credentials.
Blinded signatures are fairly low-bandwidth ---- either you have a blinded signature, or you do not.
Credentials, however, also include a blinded homomorphic value.
On issuing, the issuer can ensure that a particular value is encoded, then when the credential is blinded by the receiver, and the issuer can ensure that multiple credentials can be presented which sum up to a newly issued credential, with the value being correctly added.
Thus, I think for a modern Chaumian mint, you should really consider the credentials scheme used by WabiSabi.
--
Now, let us consider the "nodelets" idea as well.
The "nodelets" system allows for a coordinator (which can be a separate entity, or, for the reduction of needed entities, any nodelet of the node).
This coordinator in nodelets is simply a way to implement a broadcast medium among all the nodelets in a node.
However, the same coordinator in a nodelets system can also serve as a coordinator in something very much like a WabiSabi system.
So it seems to me that this can be implemented in a way that is non-custodial, as long as we can actually implement nodelets.
(which "just" requires that we use a multiparticipant signing scheme for Schnorr signatures that is composable.)
Basically, just as in the WabiSabi case, nodelets can connect to the coordinator, register some of the values they have in channels, then get back some equivalent credentials.
Then the nodelets can "self-mix" their coins, then get back a new set of values, then request that some part of their value be sent over the network.
Then, before signing off on the new state of any channel, the actual nodelets check the new state that the coordinator wants them to sign off on, thus preventing custodial risk in the same manner as Waasabi/WabiSabi does.
Thus, each state update of the channel is created by a Chaumian mint (using credentials instead of blinded signatures), then the state update is "ratified" by the actual nodelets, preventing the Chaumian mint from stealing the funds; new states are simply not signed (and presumably one or more of the nodelets will drop the previous valid state onchain, which allows them to recover funds without loss) until all nodelets can confirm that the coordinator has not stolen anything.
Nodelets can use pseudonyms in between states of channels, to reduce the ability of the coordinator, or the other nodelets, to guess who owns how much.
An issue however is how to handle forwarding.
Forwarding is an important privacy technique.
If you are a forwarder, you can plausibly claim that an outgoing HTLC is not from your own funds, but instead was a forward.
By supporting forwarding, the nodelets composing the node can reduce the ability of non-participants to determine the payments of the node.
Handling forwarding in such a system requires that nodelets be willing to leak that they have funds in the outgoing channel, in exchange for getting some earned forwarding fees.
So it seems to me that this is plausible with nodelets.
In addition, ti seems to me that the node management problem can be solved in software, by something similar in purpose to CLBOSS.
Regards,
ZmnSCPxj

2023-06-09 13:02:41

- reply

📅 Original date posted:2021-06-28
📝 Original message:
Good morning Casey,
I believe a major failing of Chaumian mints is that they are, at their core, inherently custodial.
The mint issues blinded minted coins in exchaange for people handing over other resources to their custody.
While the mint itself cannot identify who owns how much, it can outright deny all its clients access to their funds and then run off with the money to places unknown.
However, do note that both Wasabi and WabiSabi are extensions of Chaumian mints.
These avoid the custodiality issue of Chaumian mints by operating the mint as a temporary entity, whose output is then counterchecked by the users of the Wasabi/WabiSabi scheme.
I think a lot of problems are very easy if we go with custodiality; it is the variant rule of non-custodiality that makes this field interesting in the first place.
Fidelity bonds are hard since the bond has to be at least the value of the funds being managed (otherwise the mint can still sacrifice the bond to run off with the funds being managed; it would still earn more than what it lost).
That means, at best, locking up to twice the managed amount (i.e. locking it in a channel, *and* locking a similar amount in a separate fidelity bond).
In any case, you might also be interested in the "nodelets" I described some years ago.
This link has a presentation where I introduce nodelets towards the end, sorry but most of the beginning is about LN pathfinding (which is currently a non-problem since nobody makes published channels anymore).
This allows multiple users to implement a single node without a central custodian, and may allow for similar flexibility of liquidity if there are enough users, but every action requires all users to have keys online.
> I originally became interested in blind mints while thinking about Lightning
> Network wallet usability issues. When Lightning works, it is fantastic, but
> keeping a node running and managing a wallet present a number of challenges,
> such as channel unavailability due to force closes, the unpredictability of the
> on-chain fee environment, the complexity of channel backup, and the involved
> and often subtle need to manage liquidity.
>
> All of these problems *are* tractable for a skilled node operator, but may not
> be soluble in the context of self-hosted wallets operated by non-technical
> users, hereafter *normies*. If this is the case, then normies may have no
> choice but to use hosted Lightning wallets, compromising their privacy and
> exposing them to custodial risk.
One of my projects is CLBOSS, which manages a C-Lightning node for you.
* https://github.com/ZmnSCPxj/clboss
* https://lists.ozlabs.org/pipermail/c-lightning/2020-October/000197.html
The target is that at some point, the algorithms and heuristics developed for CLBOSS will be widespread and it would be trivial for a "normie" to run a well-managed forwarding node, they just have to keep it powered on 100% of the time, which should be easy, people keep their refrigerators powered on 100% of the time, after all.
I am actually kind of puzzled that nobody else seems to be building node managers, everyone just focuses on peer selection, but ignores stuff like channel feerates, closing heuristics, liquidity monitoring, etc.....
Regards,
ZmnSCPxj

2023-06-09 13:02:32

- reply

📅 Original date posted:2021-06-07
📝 Original message:
Good morning LL,
> Hi Z,
>
> I agree with your analysis. This is how I pictured eltoo fast forwards working as well.
>
> Another interesting thing about this idea is that it could allow a new type of custodial LN provider where the custodian is only in charge of receiving payments to the channel but cannot spend them.
> With the non-custodial LN phone apps there is this annoying UX where you have to keep the app open to receive a payment (because the pre-image is on my phone).
> I wouldn't mind letting the provider handle receiving payments on my behalf.
> Of course this means they would be able to steal the money in the FF state but this is a big reduction in risk from a full custodial solution.
> In other words, you should be able to get the seamless experience of a fully custodial wallet while only giving them custody of small amounts of coins for a short time.
Yes, that is indeed a good advantage and thank you for this.
> On Wed, 2 Jun 2021 at 13:30, ZmnSCPxj <ZmnSCPxj at protonmail.com> wrote:
>
> > Another advantage here is that unlike the Poon-Dryja Fast Forwards, we do *not* build up a long chain of HTLC txes.
> > At the worst case, we have an old update tx that is superseded by a later update tx instead, thus the overhead is expected to be at most 1 extra update tx no matter how many HTLCs are offered while Bob has its privkey offline.
>
> I don't think you need to build up a long chain of HTLC txs for the Poon-Dryja fast forward in the "desync" approach. Each one just replaces the other.
Thinking about it more, this seems correct.
Referring back to the diagrams:
+--------------------------+ +--------------------------+
| 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[0]) |
| |||(B && CSV) |
| +-------------+
| | A->B |
| | HTLC |
+------------+-------------+
On the *next* HTLC, Alice just gives s commitment tx *3* `SigA`, and a replacement HTLC Tx `SigA[0]` to the cashier of Bob.
+--------------------------+ +--------------------------+
| Commitment tx 1 of A | | HTLC Tx *2* |
+------------+-------------+ +------------+-------------+
| | (A[0] && B) |--->| SigA[0] | (A[0] && B) |
| |||(A && CSV) | | |||(A && CSV) |
| SigB +-------------+ | +-------------+
| | B | | | A->B |
| | | | | HTLC |
+------------+-------------+ | +-------------+
| | A->B |
| | HTLC |
+------------+-------------+
+--------------------------+
| Commitment tx *3* of B |
+------------+-------------+
| SigA | A |
| | |
| +-------------+
| | (A && B[0]) |
| |||(B && CSV) |
| +-------------+
| | A->B |
| | HTLC |
| +-------------+
| | A->B |
| | HTLC |
+------------+-------------+
This is safe, because:
* If Alice publishes Commitment tx 1 of Alice, Bob has every incentive to publish the HTLC Tx *2*, not the older HTLC Tx.
* Alice cannot force publishing the *previous* HTLC Tx, because Alice has no `B` key and cannot force-publish it.
* If Bob wants to close unilaterally, it has every incentive to publish the latest Commitment tx ### of B, because that has the most HTLCs going to Bob.
Against the above we should note that the "HTLCs" we are talking about in Poon-Dryja are not simple contracts but are instead revocable HTLCs, which means additional dependent transactions.
So I think the above *is* doable, but *does* require additional complexity and care, in that every A->B HTLC has to have some signatures exchanged as well (which, as they are HTLCs "in flight", we can have the keys on the cashier).
---------------------
I also have another subtlety to bring up with the above.
In particular, for a set of *simplex* Alice-to-Bob payments, Bob should ***not*** provide the revocation keys of older "commitment transactions owned by Bob".
That is, the cashier should ***not*** have access to the revocation keys.
Notice the above example:
+--------------------------+
| Commitment tx *2* of B |
+------------+-------------+
| SigA | A |
| | |
| +-------------+
| | (A && B[0]) |
| |||(B && CSV) |
| +-------------+
| | A->B |
| | HTLC |
+------------+-------------+
Despite being the *2nd* commitment tx, it should have the ***same*** Bob-side revocation key `B[0]` instead of the next one in the series, `B[1]`.
My previous email was wrong in incrementing `B[1]` here.
To understand this subtlety, let us divide Bob into these characters:
* The "true" Bob, which represents the actual economic entity that is using this scheme for their improved economic efficiency (i.e. "because it is convenient for the user").
* Carol the cashier, who is in direct communication with Alice and is 100% online.
* This represents a piece of (hopefully open-source) software which acts as the 100%-online node.
* Kelly the keyholder, who holds the important private keys of Bob, and *only* connects to Carol (via a direct connection) if and only if Bob wills it.
* This represents a piece of hardware that keeps the keys offline.
Now, let us consider the below property:
* Bob has access to all the activity of Carol, including all communications between Carol and Alice.
* More to the point, Bob has a copy of every `SigA` received by Carol.
The above property is accurate to the real world, I think, because Carol is not a true economic sentient entity.
It is "just" a piece of software you install on a piece of hardware with 100% uptime, and presumably Bob either has personally audited the software, or has hired someone to do so on its behalf.
Of course, software is never perfect, and it is possible that a bug in the software will allow Alice to extract additional information from Carol the cashier-software.
We model this as Carol then cooperating with Alice to do as much economic damage to Bob as possible.
For example, Carol is the one who keeps the various `SigA`s from Alice.
Thus, in theory, if Carol is corrupted by Alice, Carol is capable of deleting all the `SigA`s coming from Alice, including that needed by every "commitment transaction owned by Bob".
Thus, a "signature-deletion" attack mounted by Alice and Carol on Bob can prevent Bob from unilaterally closing the channel, leading to hostage-taking of ***all*** the Bob-side funds in the channel, not just in-flight HTLCs.
However, remember that Carol is "really" just a piece of (potentially buggy) software.
Bob can mitigate signature deletion:
* Perhaps the backing datastore is really a copy-on-write structure, such that deletions are not actual overwrites of old data, and older version containing the signatures can be retained.
* Bob can take snapshots of the backing datastore periodically, which reduces the damage of deletions, as Bob has a copy of some of the older data before Carol deleted signatures.
* Perhaps the signature datastore is an append-only log, which is only periodically reaped of truly obsolete signatures by Bob.
As signatures are only 64 bytes, this is not an onerous amount of data for low-bandwidth Bobs.
* The Carol software could be structured so that the signature datastore is a separate process, thus enjoys some amount of protection (process isolation) from exploits on the "main" Carol software that is online and connected to Alice.
Thus, in our model, we have the property that Bob can always recover all signatures sent by Alice, even if Carol is corrupted by Alice --- we model the signature-deletion attack as impossible, by assumption.
(This is a strengthening of security assumptions, thus a weakening of the security of the scheme --- if Bob does not take the above mitigations, Bob ***is*** vulnerable to a signature-deletion attack and might have ***all*** funds in hostage).
Now, hostaging of the funds in a channel occurs because one participant loses the ability to unilaterally close.
If Bob is unable to unilaterally close, Alice can refuse to cooperate on channel closures unless Bob dontes some money to Alice.
Signature-deletion is only *one* way to lose this ability.
Another way is for a corrupted Carol to reveal all the revocation keys, including the latest revocation key, to Alice.
This prevents Bob from safely unilaterally closing the channel, as the latest transaction it has is revocable by Alice (because Carol has been corrupted and has leaked the latest revocation key).
Thus:
* Carol ***MUST NOT*** be given the entire set of revocation keys `B[0]`..`B[n]`.
Carol should only be given *previous* revocation keys by Bob, as a hardened derivation from the keys held by KElly.
Of course, since Carol has no access to the *current* revocation key, it cannot provide it once the *next* commitment is created.
This implies that, until Bob puts Kelly online and gets access to the entire sequence of revocation keys, Carol also **cannot** provide revocation keys for previous states.
Thus, as long as Kelly is offline, Alice and Carol have to reuse the same revocation key.
This is still safe, since later "commitment transaction owned by Bob" have more and more funds in HTLCs going to Bob.
Thus, Bob has every incentive to use only the latest "commitment transaction owned by Bob".
So:
* As long as all transfers are Alice->Bob direction, there is no need to update the revocation key (and Carol ***cannot*** provide this key anyway without Kelly).
* Once we have a Bob->Alice transfer (i.e. Bob sends out money), only then does the revocation key need to be exposed to Carol for sending to Alice.
* As the sequence of revocation keys are derived from the master privkey held by Kelly, Kelly is needed.
* We need Kelly to be online anyway for sends (to send the corresponding signatures as well), so this is *not* an *additional* requirement.
Regards,
ZmnSCPxj

2023-06-09 13:02:31

- reply

📅 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

2023-06-09 13:02:31

- reply

📅 Original date posted:2021-06-02
📝 Original message:
Good morning again LL,
So I started thinking as well, about Decker-Russell-Osuntokun and the Fast Forwards technique, as well as your "desync" idea.
And it seems to me that we can also adapt a variant of this idea with Decker-Russell-Osuntokun, with the advantage of **not** requiring the additional encumbrance at the outputs.
The technique is that we allow Bob the receiver to have possession of *later* states while Alice the sender only possesses an old state.
Alice sends the signatures for a new state (update + settlement) whenever it offers an HTLC to Bob, and whenever Bob fulfills the HTLC.
However, Alice *does not* wait for Bob to return signatures for a new state.
So Alice remains stuck with the old state.
* Suppose Alice wants to close the channel unilaterally.
* Alice broadcasts the old update tx.
* Bob has an incentive to bring its latest state onchain (bringing its privkey online and signing the latest update).
* All the payments are in the Alice->Bob direction.
* Even though Alice broadcasted an old state, it does not lose money since Decker-Russell-Osuntokun is non-punitive.
* Bob can bring its privkey online to close the channel unilaterally with the latest state.
So it looks to me that Decker-Russell-Osuntokun similarly does **not** require the additional encumbrance at the "main" outputs.
We simply allow the sender to remain at an older state.
So let us give a concrete example.
* Alice and Bob start at state 1: Alice = 50, Bob = 50.
* Alice offers a HTLC of value 10.
* Alice: state 1: Alice = 50, Bob = 50
* Bob: state 2: Alice = 40, Bob = 50, A->B HTLC = 10
* Bob fulfills, so Alice sends a new state.which transfers the A->B HTLC value to Bob.
* Alice: state 1: Alice = 50, Bob = 50
* Bob: state 3: Alice = 40, Bob = 60
* Bob brings its privkey online because it wants to send out via Alice (a forwarder).
It offers an HTLC B->A of value 20.
* Alice: state 4: Alice = 40, Bob = 40, B->A HTLC = 20
* Bob: state 3: Alice = 40, Bob = 60
Because publishing old state is "safe" under Decker-Russell-Osuntokun, it is fine for one participant to have *only* an older state!
And we can arrange the incentives so that the one with the latest state is the one who is most incentivized to publish the latest state.
(We should probably change the subject of this thread BTW)
Another advantage here is that unlike the Poon-Dryja Fast Forwards, we do *not* build up a long chain of HTLC txes.
At the worst case, we have an old update tx that is superseded by a later update tx instead, thus the overhead is expected to be at most 1 extra update tx no matter how many HTLCs are offered while Bob has its privkey offline.
Regards,
ZmnSCPxj

2023-06-09 13:02:28

- reply

📅 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

2023-06-09 13:02:28

- reply

📅 Original date posted:2021-05-23
📝 Original message:
Good morning list,
Note that there is a possible jamming attack here.
More specifically, when "failing" an incoming HTLC, the receiver of the HTLC sends its signature for a transaction spending the HTLC and spending it back to the sender revocable contract.
The funds cannot be reused until the channel state is updated to cut-through all the transactions (the HTLC transaction and the failure transaction).
(Well it *could* but that greatly amps the complexity of the whole thing --- no, just no.)
Thus I could jam a particular receiver by sending, via forwarding nodes, to that receiver, payments with a random hash, which with high probability have preimages that are unknown by the receiver.
The receiver can only fail those HTLCs, but "to fail an HTLC" under Fast Forwards makes the funds unusable, until the previous channel state can be revoked and replaced with a new one.
But updating the channel state requires privkeys to be online in order to create the signatures for the new channel state.
This creates a practical limit on how long you can keep privkeys offline; if you keep it offline too long, an attacker can jam all your incoming capacity for long periods of time.
This is not currently a problem without "receiver online, privkey offline", since without "privkey offline" case, the receiver can update the channel state immediately.
However, if the receiver is willing to lose privacy, the protocol can be mildly modified so that the receiver tells the forwarding node to *first* ask the receiver about every HTLC hash before actually instantiating and sending the HTLC.
Only if the receiver agrees will the forwarder actually send the HTLC.
The forwarder is incentivized to go along with this, as otherwise, the receiver cannot actually fail any HTLCs --- it needs to provide a signature, and signatures require privkeys, and the receiver has those offline.
Thus, the forwarder would prefer to ask the receiver *before* it instantiates the HTLC, as otherwise the HTLC cannot be cancelled until the receiver gets its privkeys online, which can take a long time --- and if the HTLC times out in the meantime, that can only be enforced by dropping onchain, and Fast Forwards are *very* expensive in the unilateral close case.
Obviously this tells the forwarding node that the channel is used for receiving and that any payments over it terminate at the next hop, thus a privacy degradation.
On the other hand, unpublished channels remain popular despite my best efforts, and this is the exact problem unpublished channels have, so ---- not a degradation in privacy in practice, since users of unpublished channels already have degraded privacy (axiom of terminus),
This also increases latency once again, as there is now 1.5 roundtrips (forwarder asks receiver if this forwarded HTLC is kosher, receiver responds, forwarder sends signature to HTLC transaction).
However, the increased latency only occurs at the endpoint; forwarders (which need to have privkeys online 100% of the time anyway, and can thus cut-through any number of failed HTLCs at any time) can skip the "is this HTLC kosher" message and just send the HTLC signatures immediately.
Thus, this may be an acceptable tradeoff.
Thus, one might consider this scheme to be usable for *either* Fast Forwards, *or* "receiver online, privkeys offline", but not usefully both (after all, a forwarder is both a receiver and a sender, and a sender needs its keys in order to send, so it cannot use the "privkeys offline" feature anyway).
It may be difficult to understand this, so maybe I will make a convenient presentation of some sort.
Regards,
ZmnSCPxj

2023-06-09 13:02:02

- reply

📅 Original date posted:2021-02-13
📝 Original message:
Good morning Nadav, and list,
>
> More generally, all Boolean logic can be converted to one of two standard forms.
>
> - sum-of-products i.e. `||` over `&&`
> - product-of-sums i.e. `&&` over `||`
>
> For example an XOR can be converted to the sum-of-products form:
>
> A ^ B = (!A && B) || (A && !B)
>
> If we have any complicated Boolean logic, we can consider to always use some kind of product-of-sums form.
> So for the example case, escrow service is the logic:
>
> SELLER && (BUYER || ESCROW)
>
> The above is a standard product-of-sums form.
>
> Any sums (i.e. `||`) can be converted by De Morgan Theorem to product, and the payment can be a reversal instead.
>
> SELLER && !(!BUYER && !ESCROW)
>
> The `!(a && b && ...)` can be converted to a reversal of the payment.
> The individual `!BUYER` is just the buyer choosing not to claim the seller->buyer direction, and the individual `!ESCROW` is just the escrow choosing not to reveal its temporary scalar for this payment.
>
>
> And any products (i.e. `&&`) are trivially implemented in PTLCs as trivial scalar and point addition.
>
> So it may actually be possible to express any Boolean logic, by the use of reversal payments and "option not to release scalar", both of which implement the NOT gate needed for the above.
> Boolean logic is a fairly powerful, non-Turing-complete, and consistent programming language, and if we can actually implement any kind of Boolean logic with a set of payments in various directions and Barrier Escrows we can enable some fairly complex use-cases..
>
> For example, a simple DLC binary oracle can provide two points in such a way that it can only reveal one scalar of those two points (e.g. it has a persistent public key `P`, and two temporary points `H` and `T` such that `H = T + P`, and it can only safely reveal either `h` or `t`.).
> Based on the outcome of a coin flip (or other input from the mythical "real world"), it reveals either one or the other scalar.
> Then we can use either point as part of any `!Oracle` or `Oracle` Boolean logic we need.
Okay, so here is a worked example.
Suppose we have two oracles, 1 and 2.
At some point, they will flip coins in the future.
Based on their (independent) coin flip, oracle 1 will reveal either H1 or T1, and oracle 2 will reveal either H2 or T2.
Suppose some bettor wants to make some bet:
* Either both coins are heads (H1 && H2), or both coins are tails (T1 && T2).
So we have a Bettor, and a Bookie that facilitates this bet.
So the base logic is that the bettor wins (i.e. there is a payment Bookie->Bettor) if:
(H1 && H2) || (T1 && T2)
And the inverse of that logic (Better->Bookie) if the above is false.
We also know that `T1 = !H1` and `T2 = !H2` (i.e. the DLC oracles will only publish one scalar or the other), so:
(H1 && H2) || (!H1 && !H2)
Let us transform to product-of-sums (this can be done by computers by using a Karnaugh Map):
(H1 || !H2) && (!H1 || H2)
Let us check by Boolean table:
H1 H2 (H1 && H2) || (!H2 && !H2) (H1 || !H2) && (!H1 || H2)
0 0 1 1
0 1 0 0
1 0 0 0
1 1 1 1
So the above product-of-sums is correct.
We apply the De Morgan transform:
!(!H1 && H2) && !(H1 && !H2)
Then we return the `T`s:
!(T1 && H2) && !(H1 && T2)
Since the logic is inverted, what actually happens is that the Bettor makes two payments:
* Bettor->Bookie : (Bookie && T1 && H2)
* Bettor->Bookie : (Bookie && H1 && T2)
The Bookie would also need to pay out if the Bettor wins, so the Bookie makes two payments as well:
* Bookie->Bettor : (Bettor && T1 && T2)
* Bookie->Bettor : (Bettor && H1 && H2)
We can derive the above by inverting the initial `(H1 && H2) || (!H1 && !H2)` logic, then going through the same conversion to product-of-sums and De Morganizing it as for the Bettor case.
With the above, we now have a setup where either both oracles are heads, or both oracles are tails, and if so the Bettor wins, otherwise the Bookie wins.
This all probably needs to be set up with some kind of Barrier Escrow, but Nadav already has that covered.
Here is a cute magical trick.
What happens if for example oracle 1 has a failure where the CPU liquid cooler on its server fails, and oracle 1 is unable to find a replacement CPU cooler because the CPU socket has been obsoleted and nobody makes CPU coolers for that CPU socket anymore and the server cannot be brought up again?
In that case, it will be unable to publish either `H1` or `T1`.
And note that all the payments above involve `H1` or `T1`.
In that case, nobody pays out to anyone, as none of the payments are ever claimable.
Thus the case where "oracle disappears" is handled "gracefully" by simply not having any monetary transfers at all.
This seems to be a reasonable "fail safe" default to have when one of the oracles disappears without publishing the result of the coin toss.
Regards,
ZmnSCPxj

2023-06-09 13:02:01

- reply

📅 Original date posted:2021-02-13
📝 Original message:
Good morning Nadav,
> Hey ZmnSCPxj,
>
> Your earlier post about how to accomplish ORing points without verifiable encryption was super interesting.
>
> I think this contains a clever general NOT operation where you double the payment and use the point as a condition for the "cancellation payment." This is actually very similar to something that is used in my PTLC DLC scheme where many payments are failed in most cases :) But nice to add it to the toolkit, especially as a way to not use ORs for the price of over-collateralization which is acceptable in many use cases.
Indeed, specifically this point of De Morgan Theorem transformation should probably be emphasized.
More generally, all Boolean logic can be converted to one of two standard forms.
* sum-of-products i.e. `||` over `&&`
* product-of-sums i.e. `&&` over `||`
For example an XOR can be converted to the sum-of-products form:
A ^ B = (!A && B) || (A && !B)
If we have any complicated Boolean logic, we can consider to always use some kind of product-of-sums form.
So for the example case, escrow service is the logic:
SELLER && (BUYER || ESCROW)
The above is a standard product-of-sums form.
Any sums (i.e. `||`) can be converted by De Morgan Theorem to product, and the payment can be a reversal instead.
SELLER && !(!BUYER && !ESCROW)
The `!(a && b && ...)` can be converted to a reversal of the payment.
The individual `!BUYER` is just the buyer choosing not to claim the seller->buyer direction, and the individual `!ESCROW` is just the escrow choosing not to reveal its temporary scalar for this payment.
And any products (i.e. `&&`) are trivially implemented in PTLCs as trivial scalar and point addition.
So it may actually be possible to express *any* Boolean logic, by the use of reversal payments and "option not to release scalar", both of which implement the NOT gate needed for the above.
Boolean logic is a fairly powerful, non-Turing-complete, and consistent programming language, and if we can actually implement any kind of Boolean logic with a set of payments in various directions and Barrier Escrows we can enable some fairly complex use-cases..
For example, a simple DLC binary oracle can provide two points in such a way that it can only reveal one scalar of those two points (e.g. it has a persistent public key `P`, and two temporary points `H` and `T` such that `H = T + P`, and it can only safely reveal either `h` or `t`.).
Based on the outcome of a coin flip (or other input from the mythical "real world"), it reveals either one or the other scalar.
Then we can use either point as part of any `!Oracle` or `Oracle` Boolean logic we need.
>
> One comment to make though, is that this mechanism requires the atomic setup of multiple payments otherwise Seller -> Buyer will be set up after which Buyer may keep the free option and not set up the payment in return. Luckily with barrier escrows we can do atomic multi-payment setup to accomplish this!
For this particular use-case, I think it is safe to just use the order "Seller->Buyer, then Buyer->Seller" rather than add a barrier escrow.
Remember, the entire setup presumes that both Buyer and Seller can tr\*st the Escrow to resolve disputes, and the Seller->Buyer payment requires BUYER && ESCROW.
If the buyer never makes the Buyer->Seller payment presumably the Escrow will take that into consideration during dispute resolution and not release the ESCROW scalar to the Buyer.
And if the Buyer->Seller payment (which requires only SELLER scalar) is claimed "early" by the Seller before handing off the item, the Escrow is tr\*sted to consider this also (it is substantially the same as the Seller providing substandard goods) and release the ESCROW scalar.
Of course in the most general case above where we could potentially do any arbitrary logic it probably makes most sense to use a Barrier escrow as well to ensure atomicity of the setup.
Regards,
ZmnSCPxj

2023-06-09 13:02:01

- reply

2023-06-09 13:02:01

- reply

📅 Original date posted:2021-02-13
📝 Original message:
Good morning Andres,
> > > Is there any disadvantage about using dual-hash HTLCs?
> > > Is it supported by the current LN spec?
> >
> > It is no supported by current LN spec, and PTLCs are overall superior (they are equivalent to having any number of hashes, not just 2 that dual-hash HTLCs can do).
> > So if we need to change the LN spec anyway, PTLCs are still the better choice, since they enable a lot more, and we probably want to support that in the future anyway, so we might as well do HTLC->PTLC rather than HTLC->2HTLC->PTLC.
>
> But anyway any L2 wallet that interacts with this, will need to be aware of the escrow, so developing an 2HTLC extension for it to work with the current version of bitcoin (instead of waiting for Taproot) should be doable, right?
Every forwarding node needs to support 2HTLC or PTLC, meaning it has to be a network-wide upgrade.
Then once the network-wide upgrade is deployed, individual endpoints just have to understand this protocol.
Because of the need of widespread upgrade, we would prefer to just upgrade once, from HTLCs to PTLCs, rather than have multiple network-wide upgrades.
Regards,
ZmnSCPxj

2023-06-09 13:02:00

- reply

📅 Original date posted:2021-02-11
📝 Original message:
Good morning Andres,
> Hey ZmnSCPxj,
>
> On Thu, 11 Feb 2021 at 15:33, ZmnSCPxj <ZmnSCPxj at protonmail.com> wrote:
>
> > 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).
>
> Yeah I understand Bisq's model.
> However not all P2P exchanges work like this; e.g. localcryptos, hodlhodl, localbitcoins, localcryptos...
>
At least localbitcoins is custodial, and this scheme is non-custodial (though the escrow must still be trusted to actually judge correctly in case of dispute, so non-custodiality might be a very thin assurance).
>
>
> > 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.
>
> Is there any disadvantage about using dual-hash HTLCs?
> Is it supported by the current LN spec?
It is no supported by current LN spec, and PTLCs are overall superior (they are equivalent to having any number of hashes, not just 2 that dual-hash HTLCs can do).
So if we need to change the LN spec anyway, PTLCs are still the better choice, since they enable a lot more, and we probably want to support that in the future anyway, so we might as well do HTLC->PTLC rather than HTLC->2HTLC->PTLC.
Regards,
ZmnSCPxj

2023-06-09 13:01:59

- reply

📅 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

2023-06-09 13:01:59

- reply

📅 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

2023-06-09 13:01:59

- reply

📅 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

2023-06-09 13:01:49

- reply

📅 Original date posted:2021-01-05
📝 Original message:
Good morning LL, and happy new year as well,
> # Signaling Transactions
>
> Finally I present a simple but unintuitive protocol that achieves roughly the same properties as the PoDLE protocol but without lightning gossip messages.
>
> Whenever the initiator adds an input in the interactive tx building they provide signatures on a "signaling" transaction spending that input (and any inputs they have added so far).
> The signaling transactions will typically spend the funds back to the initiator's wallet.
> Before revealing any of their inputs, the peer checks that none of the inputs added by the initiator are in their mempool/chain.
> If the initiator aborts the protocol after learning one of the peer's inputs the peer broadcasts one of the signaling transactions.
I would suggest rather that each added input should add a one-input one-output signaling transaction, instead.
Consider the case of a malicious initiator who has two coins A and B.
* Mallory sends A with a signalling transaction spending A.
* Mallory sends B with a signalling transaction spending A and B.
* Victor the victim initiatee node sends its coins.
* Mallory spends A to itself, using a different transaction, with a feerate that is slightly higher than the feerate of the signaling transaction spending A and B.
Mallory only needs to spend A, and there is no way for Victor to impose a cost on the use of B --- the signaling transactions available to Victor spend A and cannot replace the non-signaling transaction that Mallory created.
So I think it is better if there is one signaling transaction per input provided by the initiator.
Alternately, we can consider that Mallory will rationally want to reduce its exposure to cost, and would prefer to just provide a single input on each initiation.
If Mallory is in possession of multiple coins, it is in the best interest of Mallory to use each coin on a different Victor to spread out its risk *and* retain its own privacy, anyway, and not give two or more inputs to each Victor.
Thus, we only really need one signalling transaction, that for the first input provided by the initiator, and the single signalling transaction is sufficient to impose costs on Mallory.
>
> Like the PoDLE proposal this doesn't achieve (3) since a malicious peer could broadcast the signaling transaction making the honest initiator pay a transaction fee before using the input in another session.
> To mitigate this a bit, the transactions could be RBF and have a 1 sat-per-byte feerate to give the initiator a decent amount of time to use their input productively before the tx confirms (and paying a low fee if it ever does confirm).
>
> The advantages of signaling transactions over PoDLE is that it doesn't involve any wonky crypto or new gossip messages.
> The advantage of the PoDLE proposal over this is that a malicious peer can only blacklist the UTXO (not necessarily force you to spend it).
>
> # Summary
>
> The preference of protocol depends on how you weigh the importance of a malicious non-initiating peer griefing the initiator.
> To protect fully, the extended version of Darosior's protocol does not allow griefing.
> There is always a lot to be said for ruling out a class of attack even if it costs you a few rounds of communication.
>
> Is griefing a real concern though? Layer-2 is full of opportunities to grief your counterparty and the ones presented here are hardly the worst.
> If you're opening channels with someone who wants to grief you, you are already in trouble.
> PoDLEs have very weak griefing in the form of unfairly adding your UTXO to the blacklist but comes at the cost of complexity and a few difficult to answer questions.
> I think the simplicity of signaling transactions may be worth the extra griefing capabilities it offers a malicious peer given they are hardly as bad as the griefing capabilities they will have if you open a channel to them!
Indeed.
With the network already "booted up", so to speak, in general, a node will prefer to initiate channels with existing nodes that have:
* High uptime.
* Good connectivity and capacity.
* Long-lived channels.
A node which acts as a passive malicious peer in this protocol *could* have gotten another channel to justify its high uptime and locked funds, and potentially earn more funds in the future, rather than pissing off the incoming initiator by this form of griefing.
Regards,
ZmnSCPxj

2023-06-09 13:01:47

- reply

📅 Original date posted:2020-12-19
📝 Original message:
Good morning LL,
> > 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`.
>
> Actually no -- the fact that you were able to create a secure conditional payment for the proof would always prove the proof existed.
> You wouldn't need to pay for the proof then!
That depends on the proof.
For example, one pay-for-proof scheme would be somebody to provide you an `(R, S)` for a public key `P = p * G`, where `S = s * G` (i.e. a signature, or a proof that you know `p` where `P = p * G`), and it would not prove anything until you pay for the scalar `s` and the prover can provide `s`, since `S` is computable from public information that anyone can have.
So it really depends on what you want to prove; a mere ZKCP is not always enough.
Regards,
ZmnSCPxj
PS I am dabbling in BTRFS now though, so ---

2023-06-09 13:01:46

- reply

📅 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

2023-06-09 13:01:45

- reply

📅 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

2023-06-09 13:01:40

- reply

📅 Original date posted:2020-12-01
📝 Original message:
Good morning Joao and Bastien,
I believe the `feeadjuster` plugin for C-Lightning, created by Darosior, already does what you want to do, without a specs change.
* We already know that nodes prefer low-fee routes over high-fee routes.
* `feeadjuster` adjusts our channel feerate according to balance:
* It makes fees low if we own most of the funds in the channel.
* It makes fees high if we own almost none of the funds in the channel.
* Thus, `feeadjuster` signals "use this channel!" if it has high capacity in that direction, and signals "do not use this channel!" if it has low capacity in that direction.
I believe this is sufficient to achieve your goal, without requiring substantial changes to existing algorithms and implementations.
(CLBOSS, also a C-Lightning plugin, implements similar logic as one of the many things it does, with some differing details but with substantially the same fee-adjustment curve)
I believe concerns on false signaling are unfounded, at least with the limited channel fee signalling that `feeadjuster`/CLBOSS use.
I can signal a low feerate, but if I do not have sufficient capacity anyway when the inevitable flood of payments wanting to take advantage of the lower fees arrives, then I gain no advantage anyway.
Rather, some amount of honesty would be better for me.
Regards,
ZmnSCPxj
> Hello Bastien!
>
> Firstly I'd like to thank you for the time you took to read the paper, it's been hard to get some quality reviews.
> Your feedback made me think and reach the following conclusions:
> Let's assume node A is sending information to its peer, node B, with the goal of attracting more business (increasing the number of payments that are routed through it). In LDR this would mean A would want to announce to B that it belongs to larger volume routes than the ones it actually does.
> Let's say A and B shared channel state is (A: 1, B: 4).
> A shares a channel with C, state (A: 2, C: 3).
> B also shares a channel with C, state (B: 3, C: 6).
> A could dishonestly share with B knowing a path to C with capacity 4 BTC although it only has 2 currently available. By doing this A would effectively change B's routing preferences for payments to C, making B's routing table go from:
>
> Destination | Next Hop | Capacity
> C A 2
> C C 3
>
> ...to:
>
> Destination | Next Hop | Capacity
> C A 4
> C C 3
>
> Meaning B now thinks payments to C with volume in the [3, 4] BTC range can only be routed through A and payments to C in the [0, 3] BTC range can be routed to A or directly to C. What does this information change and how does it affect honest nodes?
> Larger [3, 4] BTC payments are not within the capacity provided by the path that goes directly to C and would immediately fail when the payment is made in the LN layer using the path that goes through A. This breaks the incentive to, at least for payments in this volume range, share the invalid information. The cheating nodes would not be putting honest nodes out of business nor increasing the number of payments that go through them.
> The problem starts when the cheating node fakes directly competing for routes within the capacity range provided by honest nodes and not by them ([2, 3] BTC range for the example). Although this could not be used to collect more fees because payments would eventually fail in the LN layer and the fees wouldn't be able to be collected, it could certainly be used to "put honest nodes out of work", stealing routing paths that would otherwise belong to them.
> I think the solution lies in the way in which a node chooses the next best hop for a certain destination. I started by proposing the following (section 3.1.2):
>
> >The ”best next hop” for a certain payment destination is defined as being the hop with the lowest fee from the group of next hops for that destination where the maximum volume allowed is bigger than the payment’s volume.
>
> I propose changing it to:
>
> >The ”best next hop” for a certain payment destination is defined as being a random hop taken from the group of next hops for that destination where the maximum volume allowed is higher than the payment’s volume.
>
> Which would diminish the incentive attacking nodes have to share fake gossip by not allowing them to set themselves as first in line to be chosen as next hop. A maximum fee that a node is willing to pay would also need to be set,
> Also, keep in mind that the capacity the maximum path capacity can lie about is limited by the capacity of his biggest channel, available in the blockchain.
>
> PS: I adapted Figure 5 from your trampoline routing presentation, hope that's ok!
>
> Kind regards,
> João Valente
>
> On Mon, 30 Nov 2020 at 08:36, Bastien TEINTURIER <bastien at acinq.fr> wrote:
>
> > Hi Joao,
> >
> > Thanks for the time you spent on this, the paper is clear on the trade-offs (sacrificing some privacy for
> > efficiency).
> >
> > My main negative feedback here is that you seem to assume that nodes will honestly cooperate.
> > It feels to me that nodes can cheat and gossip biased or invalid information to their peers in order to
> > attract more payments through their nodes (and collect more fees or put honest routing nodes out of
> > business).
> >
> > Is that something you've thought about?
> >
> > Cheers,
> > Bastien
> >
> > Le dim. 29 nov. 2020 à 00:46, João Valente <jvalente96 at gmail.com> a écrit :
> >
> > > Hey!
> > >
> > > I've been working on this new concept for routing in the lightning network. It leverages the use of the information nodes have on the distribution of funds in their channels to try and maximize the probability of success for a payment.
> > > Each node shares with his neighbours the information it has about the distribution of funds in its own neighbourhood through the form of a routing table. As nodes receive new tables they'll be updating their own locally maintained tables with the new information, periodically sharing them with their neighbours.
> > > Routing tables associate destination addresses (representing nodes in the network) to the next hop in the maximum capacity path to these nodes.
> > > If a new payment is to be made a payment probe is forwarded by the payer and through every node in the path, collects the path information along the way, and reaches the payee who returns it to the payer. The payer can then use this knowledge and confidently use the discovered path to route LN payments through.
> > >
> > > I wrote a 10 page paper about the subject and would love to get some feedback:
> > > https://drive.google.com/file/d/1dahW0X-N59138ZbY-4odpXjpDnX4Gb7Z/view?usp=sharing
> > >
> > > Cheers,
> > > João Valente
> > > _______________________________________________
> > > Lightning-dev mailing list
> > > Lightning-dev at lists.linuxfoundation.org
> > > https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev

2023-06-09 13:01:40

- reply

📅 Original date posted:2020-12-01
📝 Original message:
Good morning Joao,
> Hello ZmnSCPxj,
>
> Thank you for taking the time to read the paper and sending over some feedback, can't stress enough how important that is.
> I took a look at the `feeadjuster` plugin for C-Lightning and although it goes in the same direction as LDR in the sense that it allows for better routes by signalling channel balance availability. It does it through a dynamic fee adjustment though, where LDR is more explicit and goes one step further, directly sharing channel balance information. I'm not sure how these two solutions would compare in practice though but I imagine that sharing more information would give LDR a performance edge.
> Oh, and there's no need for a spec change. It could work as a separated LN overlay network.
I believe it would --- either you write the code for this overlay network for all extant node software (though I suppose targeting lnd will get you 90% of the network anyway...), or you standardize so all implementations are going to target implementing the overlay network.
On the other hand, using fees as the signaling just reuses an existing signaling layer, and affects payers in the expected ways --- all existing implementations already try to minimize fees, so signaling a low fee when you have high capacity on a channel already does the "right thing" on the network today.
In short, by using fees as a signaling layer you can get something like this partly working for most payers today even if only a small number of nodes run `feeadjuster` or CLBOSS, whereas with LDR you need most payers to upgrade to using the new overlay network in order to get similar benefit, I think, in which case you should really push to standardize it in the specs.
Regards,
ZmnSCPxj

2023-06-09 13:01:38

- reply

📅 Original date posted:2020-12-01
📝 Original message:
Good morning LL, and list,
> That's a very interesting point. If we were to be able to prevent loop attacks by the sender proving the path is well formed (without revealing who they are or any of the other hops) would this be an alternative solution?
> It seems to me that disabling loop attacks might be much easier than stake certificates.
Loop attacks are not about loops, it only requires that the start and end of a payment are controlled by the same entity.
Multiple nodes on the LN may be owned by the same entity.
Nodes, individually as nodes, are trivially cheap and just need 32 bytes of entropy from a `/dev/random` near you.
It is the channels themselves, requiring actual funds, high uptime, and not being a dick to your counterparty, that are fairly expensive.
Thus, a "loop attack" need not involve a loop per se --- a single entity can run any number of nodes with small numbers of channels each, and thereby grief the network.
Stake certificates make the node itself expensive, so a single entity running a number of nodes cannot perform such loop attacks, since it would require entities expensively allocating funds for each node.
On the other hand, if channels are expensive, then a node with channels is expensive.
In https://lists.linuxfoundation.org/pipermail/lightning-dev/2020-November/002890.html , which contains the "Z consideration" you were alluding to, I note that the "point-to-point property" is already proven by the ***existing*** Lightning network without an additional ZK cryptographic proof.
So let me invert that logic and present an even more extreme position:
* There are two griefing attacks:
* Loop attacks, which are deliberate malicious attacks to lock up funds of competitors in order to redirect forwarding towards the attacker.
* Accidental "attacks", which are accidental due to incompetence, where a forwarding node accidentally goes offline and causes payments to be locked up for long periods and making everyone on the network cry when HTLCs time out and things have to be dropped onchain.
* The point-to-point property, which is already proven by the ***existing*** Lightning network, is already sufficient to prevent loop attacks, leaving only accidental incompetence-based "attacks".
* Or: the ***existing*** Lightning Network ***already*** proves the point-to-point property presented by t-bast, and that property is ***already*** sufficient to prevent the loop attacks.
So, maybe we should instead focus on mitigating the effects of the incompetence-based non-attacks [such as this proposal](https://github.com/ElementsProject/lightning/issues/2632#issuecomment-736438980), instead of attempting to defend against the mirage of loop attacks.
I could be utterly wrong here though.
Regards,
ZmnSCPxj

2023-06-09 13:01:35

- reply

📅 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