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

nprofile1qqsy2pg8yaz2n5lyjzheyc4luw8xaefn3fm3w76ktd4nwuctvwnmscgprpmhxue69uhhyetvv9ujumn0wdmksetjv5hxxmmdqyt8wumn8ghj7un9d3shjtnwdaehgu3wvfskueqfe9t7n

Publishing to

relay.noswhere.com

relay.nostr.band

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

2023-06-09 13:01:33

- reply

📅 Original date posted:2020-11-27
📝 Original message:
Good morning Gleb,
> Thank you for your interest :)
>
> > Quick question: if I am a routing node and receive a valid stake certificate, can I reuse this stake certificate on my own outgoing payments?
>
> That probably should be avoided, otherwise a mediocre routing node gets a lot of jamming opportunities for no good.
>
> You are right, that’s a strong argument for proof “interactivity”: every Certificate should probably commit to *at least* public key of the routing node it is generated for.
Right, it would be better to have the certificate commit to a specific routing node rather than the payment hash/point as I proposed.
Committing to a payment hash/point allows a random forwarding node to probe the rest of the network using the same certificate, lowering the score for that certificate on much of the network.
Another constraint is that the proof has to be small, since we have to fit it all in a small onion...
Presumably we also want the score to eventually "settle to 0" over time.
Regards,
ZmnSCPxj
>
> – gleb
> On Nov 27, 2020, 2:16 AM +0200, ZmnSCPxj <ZmnSCPxj at protonmail.com>, wrote:
>
> > Good morning Gleb and Antoine,
> >
> > This is certainly interesting!
> >
> > Quick question: if I am a routing node and receive a valid stake certificate, can I reuse this stake certificate on my own outgoing payments?
> >
> > It seems to me that the proof-of-stake-certificate should also somehow integrate a detail of the current payment (such as payment hash/point) so it cannot be reused by routing nodes for their own outgoing payments.
> >
> > For example, looking only at your naive privacy-broken proposal, the signature must use a `sign-to-contract` where the `R` in the signature is actually `R' + h(R' | payment_hash)` with the `R'` also revealed.
> >
> > Regards,
> > ZmnSCPxj
> >
> > > Hello list,
> > >
> > > In this post, we explore a different approach to channel jamming mitigation.
> > > We won’t talk about the background here, for the problem description as well as some proposed solutions (mainly upfront payment schemes), see [1].
> > >
> > > We’re suggesting using UTXO ownership proofs (a.k.a. Stake Certificates) to solve this problem. Previously, these proofs were only used in the Lightning Network at channel announcement time to prevent malicious actors from announcing channels they don’t control. One can think of it as a “fidelity bond” (as a scarce resource) as a requirement for sending HTLCs.
> > >
> > > We start by overviewing issues with other solutions, and then present a naive, privacy-broken Stake Certificates. Then we examine designing a privacy-preserving version, evaluating them. At the end, we talk about non-trivial design decisions and open questions.
> > >
> > > ## Issues with other proposals
> > >
> > > We find unsatisfying that upfront payment schemes come at a cost of new fees (forward and/or backward), thus inflating payment cost for *any* payment.
> > > In the future, the upfront base fee might even make “micropayments” economically infeasible by exceeding the value they transfer. Thus, a good solution should not inflate payment cost while still requiring “burning” a scarce resource (so that the attack is not free).
> > >
> > > Another issue with upfront payments is a circular trust dependency. Ideally, we shouldn’t introduce anything less trust-minimized than the Lightning Network itself.
> > > Upfront payment schemes are not like that, because they in one way or another rely on the honest behavior of route participants.
> > >
> > > We believe Stake Certificates we are going to introduce are satisfactory in both of these directions: they don’t inflate payment costs for honest users and don’t require trust. The main disadvantage of Stake Certificates seems to be the novel cryptography required.
> > > See more details in the “Evaluation” section.
> > >
> > > ## Channel Ownership Proofs as Routing Credit Balance
> > >
> > > Let’s say Alice wants to relay an HTLC to Carol through Bob. Per the Stake Certificates scheme, she has to commit to a particular channel UTXO by embedding an ownership proof in the onion packet while sending an HTLC to Bob.
> > >
> > > Bob then unwraps the onion and verifies:
> > > 1) the channel identifier is pointing unambiguously to an on-chain UTXO;
> > > 2) the ownership proof (e.g., a signature) is valid against the previously disclosed UTXO witness script.
> > >
> > > If all those checks succeed, Bob should see if Alice hasn’t exceeded her credit balance. In case she hasn’t, Bob has to “decrement Alice’s credit balance” and relay the HTLC to Carol.
> > > Decrementing credit balance unconditionally of packet success or failure bounds liquidity abuse by malicious HTLC senders.
> > > Since there is no credit assigned initially, “decrementing the credit balance” means just remembering that “Alice spent X out of Y of the credit she received for her Stake Certificates”.
> > >
> > > Unfortunately, this naive protocol is a privacy nightmare, because routing nodes can now easily assign every HTLC they forward to the sender’s UTXO.
> > >
> > > Let’s first define the terms here one more time, and then proceed to the non-naive, private Stake Certificates.
> > >
> > > - Stake Certificate. Either means a solution we’re proposing or the primitive it is based on, namely proof of UTXO ownership. As we will argue later, it actually makes sense to use proof of LN channel UTXO ownership specifically rather than any funds ownership.
> > > - Stake Certificate value. An amount of the corresponding UTXO or a ballpark this amount provably belongs to.
> > > - Credit balance. When Alice provides a routing node Bob with a Stake Certificate, Bob should increase Alice’s routing credit balance. Alice is then limited in her payments by this balance, and this rule is enforced by routing nodes to prevent free channel jamming in the network. Note that ideally “Alice’s credit balance“ should be virtual and only known to Alice, while routing nodes should only observe per-UTXO credit balance. We currently assume that each routing node keeps track of per-UTXO credit balance separately, see “Design decisions” for more details.
> > > - Stake-to-credit function defines how much credit balance is given per a Stake Certificate of a given value. This function is a policy of a routing node, and it should be announced.
> > > - Credit-to-value-transferred function defines how much value a sender can transfer along a given channel considering how much credit they might claim. The function may also consider different factors (e.g., the available capacity of a channel being used) to provide extra robustness.
> > >
> > > ## Privacy-preserving Stake Certificates
> > >
> > > The presented scheme could preserve privacy if it relied on zero-knowledge proofs of UTXO ownership by avoiding pointing to a particular UTXO.
> > > More specifically, the verifier should be able to check that:
> > > a) The staked UTXO is an element of the current UTXO set
> > > b) The prover knows the witness script committed by the UTXO witness program
> > > c) The prover knows a valid witness for the witness script
> > > d) The staked UTXO was not used to produce a different Stake Certificate which is currently in use as well.
> > >
> > > The verifier should also have a way to see a Stake Certificate value to properly account for the credit. This can be achieved by restricting the UTXO set being proved upon to only those UTXOs with a specific range of values: “I will prove that I own a UTXO among all UTXOs between 0.5 BTC and 1 BTC”.
> > >
> > > Unfortunately, steps (b) and (c) require zero-knowledge protocols for general statements, which are more experimental primitives than most of the stuff we have in Bitcoin protocols,
> > > although we assume it’s feasible to consider them for non-consensus stuff.
> > >
> > > ## Evaluation
> > >
> > > Stake Certificates, upfront payment schemes, and other potential solutions (given a particular configuration) may be compared along the following axis:
> > > 1) Economic feasibility
> > > 1a) What is the cost of overcoming the protection for an attacker? Likely a non-linear function: sats_spent =f(channels_to_jam, […])
> > > 1b) How does this solution limit honest users?
> > > 2) How sophisticated is this solution in terms of integration and making good UX?
> > > 3) How complex is this solution in terms of protocol design/implementation?
> > >
> > > When it comes to (1a), both Stake Certificates and upfront payments are probably equal, in a way that they’re just best-effort ideas to increase the attack cost. Unfortunately, we currently don’t know how to design something as economically powerful as PoW in Bitcoin [3].
> > > This aspect can be properly evaluated by applying these ideas to different hypothetical kinds of LN in a simulation and observing the resulting trade-off between (1a) and (1b) considering different attack strategies.
> > >
> > > In the previous sections of this post, we have argued that Stake Certificates may provide a much better (1b) for the cost of (3) because it relies on zero-knowledge.
> > > When it comes to (2), the design of Stake Certificates may vary in terms of UX burden, from completely automatic to requiring custom actions with private keys from users.
> > >
> > > Some of these trade-offs along with other interesting questions are discussed in the following section.
> > >
> > > ## Design decisions and questions
> > >
> > > #### Should the credit spending be gossipped across the entire network, or should only the routing nodes involved in the payment know?
> > >
> > > Economically, these two approaches are likely to be equivalent, and it’s just a matter of stake-to-credit ratio.
> > > However, announcing credit spending to the network results in a privacy leak. It also imposes bandwidth and CPU overhead on the routing nodes.
> > >
> > > #### Which zero-knowledge system should be used for Stake Certificates?
> > >
> > > Choosing a ZK system boils down to picking the right trade-offs of proving and verifying time, and assumptions. As we mentioned previously, we would need proving general statements.
> > > At the same time, we need something cheap in both proving and verification, because Lightning is supposed to be fast.
> > > At the same time, the setup probably doesn’t matter, because proofs are supposed to be verified only by one participant, a routing node this proof is generated for.
> > > Perhaps we can also pick any cryptographic assumptions we want since this stuff is not mission-critical and can be easily updated if someone breaks a cryptographic assumption and we observe an attack.
> > >
> > > #### Should we allow holding *any* Bitcoins (not just LN channels) for Stake Certificates?
> > >
> > > This idea might make sense if we’re worried that some LN users might want to send more payments than they can afford per their credit. However, we believe that allowing any UTXO would give an attacker more opportunities to use their cold funds for this attack, or even have a secondary market where holders sell their proofs (they have nothing to loose).
> > > Instead, we should a) design the credit-to-stake-functions better; b) encourage users send payments across different routing nodes (since credits are not tracked globally) [4].
> > >
> > > #### What’s the best credit-to-value-transferred function?
> > >
> > > We reckon that this function should be not just linear to provide maximum security against malicious channel jammers. For example, we can charge more credit for the last 20% of the capacity of the *channel used for routing*. Alternatively, we could discourage making too many payments from the same UTXO within a short period of time by charging more credit in this case.
> > >
> > > #### What about the interactivity and lifetime of Stake Certificates?
> > >
> > > Interactive proofs mean that they are constructed on demand of a routing node, non-interactive means constructed by a payment sender ahead of time.
> > > Both interactivity and lifetime have something to do with the ease of producing proof and accessing keys.
> > > We will omit the details of the trade-off we consider, but it remains an open question.
> > >
> > > #### If Stake Certificates are valid for N blocks after proof generation, does it mean that if the UTXO is spent during those N blocks, new proof can be generated from the same coins without invalidating the old proof?
> > >
> > > Yes, but an attacker would, first of all, have to pay an on-chain fee for this. If we’re still worried about this problem, there are workaround ideas.
> > > For example, we could have epochs of 100 blocks (every epoch starts at #XYZXYZ00 block). If at the start of an epoch, a channel wasn’t in the UTXO set, it provides very little credit.
> > > Alternatively, we could expand the zero-knowledge part to proving that the coins were not yet spent.
> > >
> > > #### Should spending a UTXO reveal all Stake Certificates generated from it?
> > >
> > > This would also solve the problem in the previous question, but it would mean a retrospective privacy leak again. To avoid a privacy leak, we should prevent this.
> > >
> > > #### What if malicious Sybil *routing* nodes failing payments causing other honest routing nodes to reduce the credit of an honest payment sender?
> > >
> > > Both Stake Certificates and upfront payment schemes suffer from malicious routing nodes failing the payments and “wasting” the sender’s credit or fees. This problem even applies out of the channel jamming context, when considering payment failure rate.
> > > This problem can be addressed by reducing the reputation of faulty links and routing nodes on the payment sender node. When payment routing becomes a for-profit activity, this would encourage routing nodes to sanitize their links.
> > > The mitigation can be even stronger by using “provable blaming” introduced in [2].
> > >
> > > ## Conclusion
> > >
> > > We propose Stake Certificates, a new solution to channel jamming. Perhaps, it might not be the best near-term solution due to the complexity, but the zero satoshi overhead for honest payments is an appealing argument to switch to it in the future.
> > > This proposal also illustrates how stake-based protocols can solve Sybil challenges in the Bitcoin ecosystem. Since this might be useful in other contexts (Sybil-resistance of many kinds, proof-of-ownership), discussing Stake Certificates is even more useful.
> > > The next step is a discussion of Stake Certificates. If the community finds it interesting, then we should discuss the design questions mentioned above, and choose a cryptosystem.
> > >
> > > Cheers,
> > > Gleb Naumenko and Antoine Riard
> > >
> > > ———
> > >
> > > References and footnotes:
> > > 1. https://github.com/t-bast/lightning-docs/blob/master/spam-prevention.md
> > > 2. https://lists.linuxfoundation.org/pipermail/lightning-dev/2015-August/000135.html
> > > 3. We don’t actually suggest PoW to solve these issues, because a) the trade-off between honest user cost and attacker cost is misaligned due to specialized hardware and b) smartphones would die too fast if they have to compute PoW; PoW is just an unreachable example of system robustness due to well-aligned game theory.
> > > 4. Secondary markets are still possible even if we restrict acceptable proofs to only LN channels, but supply would be much smaller, and markets would work much worse for an attacker.

2023-06-09 13:01:32

- reply

📅 Original date posted:2020-11-26
📝 Original message:
Good morning Gleb and Antoine,
This is certainly interesting!
Quick question: if I am a routing node and receive a valid stake certificate, can I reuse this stake certificate on my own outgoing payments?
It seems to me that the proof-of-stake-certificate should also somehow integrate a detail of the current payment (such as payment hash/point) so it cannot be reused by routing nodes for their own outgoing payments.
For example, looking only at your naive privacy-broken proposal, the signature must use a `sign-to-contract` where the `R` in the signature is actually `R' + h(R' | payment_hash)` with the `R'` also revealed.
Regards,
ZmnSCPxj
> Hello list,
>
> In this post, we explore a different approach to channel jamming mitigation.
> We won’t talk about the background here, for the problem description as well as some proposed solutions (mainly upfront payment schemes), see [1].
>
> We’re suggesting using UTXO ownership proofs (a.k.a. Stake Certificates) to solve this problem. Previously, these proofs were only used in the Lightning Network at channel announcement time to prevent malicious actors from announcing channels they don’t control. One can think of it as a “fidelity bond” (as a scarce resource) as a requirement for sending HTLCs.
>
> We start by overviewing issues with other solutions, and then present a naive, privacy-broken Stake Certificates. Then we examine designing a privacy-preserving version, evaluating them. At the end, we talk about non-trivial design decisions and open questions.
>
> ## Issues with other proposals
>
> We find unsatisfying that upfront payment schemes come at a cost of new fees (forward and/or backward), thus inflating payment cost for *any* payment.
> In the future, the upfront base fee might even make “micropayments” economically infeasible by exceeding the value they transfer. Thus, a good solution should not inflate payment cost while still requiring “burning” a scarce resource (so that the attack is not free).
>
> Another issue with upfront payments is a circular trust dependency. Ideally, we shouldn’t introduce anything less trust-minimized than the Lightning Network itself.
> Upfront payment schemes are not like that, because they in one way or another rely on the honest behavior of route participants.
>
> We believe Stake Certificates we are going to introduce are satisfactory in both of these directions: they don’t inflate payment costs for honest users and don’t require trust. The main disadvantage of Stake Certificates seems to be the novel cryptography required.
> See more details in the “Evaluation” section.
>
> ## Channel Ownership Proofs as Routing Credit Balance
>
> Let’s say Alice wants to relay an HTLC to Carol through Bob. Per the Stake Certificates scheme, she has to commit to a particular channel UTXO by embedding an ownership proof in the onion packet while sending an HTLC to Bob.
>
> Bob then unwraps the onion and verifies:
> 1) the channel identifier is pointing unambiguously to an on-chain UTXO;
> 2) the ownership proof (e.g., a signature) is valid against the previously disclosed UTXO witness script.
>
> If all those checks succeed, Bob should see if Alice hasn’t exceeded her credit balance. In case she hasn’t, Bob has to “decrement Alice’s credit balance” and relay the HTLC to Carol.
> Decrementing credit balance unconditionally of packet success or failure bounds liquidity abuse by malicious HTLC senders.
> Since there is no credit assigned initially, “decrementing the credit balance” means just remembering that “Alice spent X out of Y of the credit she received for her Stake Certificates”.
>
> Unfortunately, this naive protocol is a privacy nightmare, because routing nodes can now easily assign every HTLC they forward to the sender’s UTXO.
>
> Let’s first define the terms here one more time, and then proceed to the non-naive, private Stake Certificates.
>
> - Stake Certificate. Either means a solution we’re proposing or the primitive it is based on, namely proof of UTXO ownership. As we will argue later, it actually makes sense to use proof of LN channel UTXO ownership specifically rather than any funds ownership.
> - Stake Certificate value. An amount of the corresponding UTXO or a ballpark this amount provably belongs to.
> - Credit balance. When Alice provides a routing node Bob with a Stake Certificate, Bob should increase Alice’s routing credit balance. Alice is then limited in her payments by this balance, and this rule is enforced by routing nodes to prevent free channel jamming in the network. Note that ideally “Alice’s credit balance“ should be virtual and only known to Alice, while routing nodes should only observe per-UTXO credit balance. We currently assume that each routing node keeps track of per-UTXO credit balance separately, see “Design decisions” for more details.
> - Stake-to-credit function defines how much credit balance is given per a Stake Certificate of a given value. This function is a policy of a routing node, and it should be announced.
> - Credit-to-value-transferred function defines how much value a sender can transfer along a given channel considering how much credit they might claim. The function may also consider different factors (e.g., the available capacity of a channel being used) to provide extra robustness.
>
> ## Privacy-preserving Stake Certificates
>
> The presented scheme could preserve privacy if it relied on zero-knowledge proofs of UTXO ownership by avoiding pointing to a particular UTXO.
> More specifically, the verifier should be able to check that:
> a) The staked UTXO is an element of the current UTXO set
> b) The prover knows the witness script committed by the UTXO witness program
> c) The prover knows a valid witness for the witness script
> d) The staked UTXO was not used to produce a different Stake Certificate which is currently in use as well.
>
> The verifier should also have a way to see a Stake Certificate value to properly account for the credit. This can be achieved by restricting the UTXO set being proved upon to only those UTXOs with a specific range of values: “I will prove that I own a UTXO among all UTXOs between 0.5 BTC and 1 BTC”.
>
> Unfortunately, steps (b) and (c) require zero-knowledge protocols for general statements, which are more experimental primitives than most of the stuff we have in Bitcoin protocols,
> although we assume it’s feasible to consider them for non-consensus stuff.
>
> ## Evaluation
>
> Stake Certificates, upfront payment schemes, and other potential solutions (given a particular configuration) may be compared along the following axis:
> 1) Economic feasibility
> 1a) What is the cost of overcoming the protection for an attacker? Likely a non-linear function: sats_spent =f(channels_to_jam, […])
> 1b) How does this solution limit honest users?
> 2) How sophisticated is this solution in terms of integration and making good UX?
> 3) How complex is this solution in terms of protocol design/implementation?
>
> When it comes to (1a), both Stake Certificates and upfront payments are probably equal, in a way that they’re just best-effort ideas to increase the attack cost. Unfortunately, we currently don’t know how to design something as economically powerful as PoW in Bitcoin [3].
> This aspect can be properly evaluated by applying these ideas to different hypothetical kinds of LN in a simulation and observing the resulting trade-off between (1a) and (1b) considering different attack strategies.
>
> In the previous sections of this post, we have argued that Stake Certificates may provide a much better (1b) for the cost of (3) because it relies on zero-knowledge.
> When it comes to (2), the design of Stake Certificates may vary in terms of UX burden, from completely automatic to requiring custom actions with private keys from users.
>
> Some of these trade-offs along with other interesting questions are discussed in the following section.
>
> ## Design decisions and questions
>
> #### Should the credit spending be gossipped across the entire network, or should only the routing nodes involved in the payment know?
>
> Economically, these two approaches are likely to be equivalent, and it’s just a matter of stake-to-credit ratio.
> However, announcing credit spending to the network results in a privacy leak. It also imposes bandwidth and CPU overhead on the routing nodes.
>
> #### Which zero-knowledge system should be used for Stake Certificates?
>
> Choosing a ZK system boils down to picking the right trade-offs of proving and verifying time, and assumptions. As we mentioned previously, we would need proving general statements.
> At the same time, we need something cheap in both proving and verification, because Lightning is supposed to be fast.
> At the same time, the setup probably doesn’t matter, because proofs are supposed to be verified only by one participant, a routing node this proof is generated for.
> Perhaps we can also pick any cryptographic assumptions we want since this stuff is not mission-critical and can be easily updated if someone breaks a cryptographic assumption and we observe an attack.
>
> #### Should we allow holding *any* Bitcoins (not just LN channels) for Stake Certificates?
>
> This idea might make sense if we’re worried that some LN users might want to send more payments than they can afford per their credit. However, we believe that allowing any UTXO would give an attacker more opportunities to use their cold funds for this attack, or even have a secondary market where holders sell their proofs (they have nothing to loose).
> Instead, we should a) design the credit-to-stake-functions better; b) encourage users send payments across different routing nodes (since credits are not tracked globally) [4].
>
> #### What’s the best credit-to-value-transferred function?
>
> We reckon that this function should be not just linear to provide maximum security against malicious channel jammers. For example, we can charge more credit for the last 20% of the capacity of the *channel used for routing*. Alternatively, we could discourage making too many payments from the same UTXO within a short period of time by charging more credit in this case.
>
> #### What about the interactivity and lifetime of Stake Certificates?
>
> Interactive proofs mean that they are constructed on demand of a routing node, non-interactive means constructed by a payment sender ahead of time.
> Both interactivity and lifetime have something to do with the ease of producing proof and accessing keys.
> We will omit the details of the trade-off we consider, but it remains an open question.
>
> #### If Stake Certificates are valid for N blocks after proof generation, does it mean that if the UTXO is spent during those N blocks, new proof can be generated from the same coins without invalidating the old proof?
>
> Yes, but an attacker would, first of all, have to pay an on-chain fee for this. If we’re still worried about this problem, there are workaround ideas.
> For example, we could have epochs of 100 blocks (every epoch starts at #XYZXYZ00 block). If at the start of an epoch, a channel wasn’t in the UTXO set, it provides very little credit.
> Alternatively, we could expand the zero-knowledge part to proving that the coins were not yet spent.
>
> #### Should spending a UTXO reveal all Stake Certificates generated from it?
>
> This would also solve the problem in the previous question, but it would mean a retrospective privacy leak again. To avoid a privacy leak, we should prevent this.
>
> #### What if malicious Sybil *routing* nodes failing payments causing other honest routing nodes to reduce the credit of an honest payment sender?
>
> Both Stake Certificates and upfront payment schemes suffer from malicious routing nodes failing the payments and “wasting” the sender’s credit or fees. This problem even applies out of the channel jamming context, when considering payment failure rate.
> This problem can be addressed by reducing the reputation of faulty links and routing nodes on the payment sender node. When payment routing becomes a for-profit activity, this would encourage routing nodes to sanitize their links.
> The mitigation can be even stronger by using “provable blaming” introduced in [2].
>
> ## Conclusion
>
> We propose Stake Certificates, a new solution to channel jamming. Perhaps, it might not be the best near-term solution due to the complexity, but the zero satoshi overhead for honest payments is an appealing argument to switch to it in the future.
> This proposal also illustrates how stake-based protocols can solve Sybil challenges in the Bitcoin ecosystem. Since this might be useful in other contexts (Sybil-resistance of many kinds, proof-of-ownership), discussing Stake Certificates is even more useful.
> The next step is a discussion of Stake Certificates. If the community finds it interesting, then we should discuss the design questions mentioned above, and choose a cryptosystem.
>
> Cheers,
> Gleb Naumenko and Antoine Riard
>
> ———
>
> References and footnotes:
> 1. https://github.com/t-bast/lightning-docs/blob/master/spam-prevention.md
> 2. https://lists.linuxfoundation.org/pipermail/lightning-dev/2015-August/000135.html
> 3. We don’t actually suggest PoW to solve these issues, because a) the trade-off between honest user cost and attacker cost is misaligned due to specialized hardware and b) smartphones would die too fast if they have to compute PoW; PoW is just an unreachable example of system robustness due to well-aligned game theory.
> 4. Secondary markets are still possible even if we restrict acceptable proofs to only LN channels, but supply would be much smaller, and markets would work much worse for an attacker.

2023-06-09 13:01:17

- reply

📅 Original date posted:2020-10-23
📝 Original message:
Good morning t-bast,
> > And in this case C earns.
>
> > Can C delay the refund to D to after the grace period even if D settled the HTLC quickly?
>
> Yes C earns, but D has misbehaved. As a final recipient, D isn't dependent on anyone downstream.
> An honest D should settle the HTLC before the `grace_period` ends. If D chooses to hold the HTLC
> for a while, then it's fair that he pays C for this.
Okay, now let us consider the case where the supposedly-delaying party is not the final destination.
So, suppose D indicates to C that it should fail the HTLC.
In this case, C cannot immediately propagate the `update_fail_htlc` upstream, since the latest commitment transaction for the C<->D channel still contains the HTLC.
In addition, our state machine is hand-over-hand, i.e. there is a small window where there are two valid commitment transactions.
What happens is we sign the next commitment transaction and *then* revoke the previous one.
So I think C can only safely propagate its own upstream `update_fail_htlc` once it receives the `revoke_and_ack` from D.
So the time measured for the grace period between C and D should be from C sending `update_add_htlc` to C receiving `revoke_and_ack` from D, in case the HTLC fails.
This is the time period that D is allowed to consume, and if it exceeds the grace period, it is penalized.
(In this situation, it is immaterial if D is the destination: C cannot know this fact.)
So let us diagram this better:
C D
|----update_add_htlc--->| ---
|---commitment_signed-->| ^
|<----revoke_and_ack----| |
|<--commitment_signed---| |
|-----revoke_and_ack--->| |
| | grace period
|<--update_fail_htlc----| |
|<--commitment_signed---| |
|-----revoke_and_ack--->| |
|---commitment_signed-->| v <--- grief point!
|<----revoke_and_ack----| ---
(somebody *else* better make sure my understanding of the state machine is correct!)
C can trivially grief D here, making it look like D is delaying, by delaying its own `commitment_signed` containing the *removal* of the HTLC.
D cannot send its own `revoke_and_ack` until it receives the signature for its own next commitment, as if it did so, it would lose the ability to close the channel unilaterally; it has to wait for C to send the `commitment_signed`.
Thus, it seems to me that C can grief D here.
The question is: does the above C-can-grief-D matter?
I think D does have a defense against C griefing in the above case:
* If the time between D->`update_fail_htlc`->C and the corresponding C->`commitment_signed`->D becomes too long:
* D drops the channel onchain.
* The dropped commitment tx still contains the HTLC, since it is the "previous" commitment that D happens to hold that has not yet had the `update_fail_htlc` committed.
If D performs the above, then C is forced to wait *even longer* (it has to wait out the HTLC timelock) before it can safely propagate the `update_fail_htlc`: D could be fooling with it and actually knows the preimage and claim it onchain, so C for its own safety *must* wait out the onchain timelock.
Does that make sense?
Does it sensibly protect against this griefing?
Is it too much of a punishment and could potentially hurt D more than it hurts C if C is a heavily-connected node that will not miss the channel while D has fewer channels and opened the C<->D channel in the first place?
--
For success case `update_fulfill_htlc`, I believe C can immediately propagate this back to its upstream since it can now.
Thus, in that case, we can stop the timer at the `update_fulfill_htlc`.
So at least for the *end point* of the grace period, I think the end point should be:
* If the HTLC failed:
* When both participants have sent `revoke_and_ack`.
* If the HTLC succeeded:
* When the downstream participant has sent `update_fulfill_htlc`.
For the *start point*, it seems the C->`commitment_signed`->D containing the HTLC would work as the start point.
In particular, it seems to me that C can also deliberately defer its own C->`revoke_and_ack`->D:
C D
|----update_add_htlc--->|
|---commitment_signed-->| ---
|<----revoke_and_ack----| ^
|<--commitment_signed---| |
|-----revoke_and_ack--->| | <--- grief point!
| | grace period
|<--update_fail_htlc----| |
|<--commitment_signed---| |
|-----revoke_and_ack--->| |
|---commitment_signed-->| v
|<----revoke_and_ack----| ---
(If D deliberately delays, then it is penalized, so we should consider the case where C attempts to trigger the reverse case).
D cannot safely fulfill the HTLC until after the previous commitment transactions of *both* sides have been revoked ("irrevocably committed" state).
So D can use the same defense, I think: if C is taking too long to send the `revoke_and_ack` pointed at above, it drops the channel onchain with the HTLC instantiated (which is why the *start time* has to be the C->`commitment_signed`->D that contains the new HTLC).
Thus the D grace period has two smaller grace periods that D imposes on C, using the threat of channel drop to protect against the C-side griefing.
Sorry for dropping into details already but so far this is the only griefing attack I can think of right now.
Regards,
ZmnSCPxj

2023-06-09 13:01:15

- reply

📅 Original date posted:2020-10-22
📝 Original message:
Good morning t-bast,
> Sorry in advance for the lengthy email,
Come on, ZmnSCPxj writes lengthier.
> but I think it's worth detailing my hybrid proposal
> (bidirectional upfront payments), it feels to me like a workable solution that builds on
> previous proposals. You can safely ignore the details at the end of the email and focus only on
> the high-level mechanism at first.
>
> Let's consider the following route: A -----> B -----> C -----> D
>
> We add a `hold_grace_period_delta` field to `channel_update` (in seconds).
> We add two new fields in the tlv extension of `update_add_htlc`:
>
> * `hold_grace_period` (seconds)
> * `hold_fees` (msat)
>
> We add an `outgoing_hold_grace_period` field in the onion per-hop payload.
>
> When nodes receive an `update_add_htlc`, they verify that:
>
> * `hold_fees` is not unreasonable large
> * `hold_grace_period` is not unreasonably small or large
> * `hold_grace_period` - `outgoing_hold_grace_period` >= `hold_grace_period_delta`
>
> Otherwise they immediately fail the HTLC instead of relaying it.
>
> For the example we assume all nodes use `hold_grace_period_delta = 10`.
>
> We add a forward upfront payment of 1 msat (fixed) that is paid unconditionally when offering an HTLC.
> We add a backwards upfront payment of `hold_fees` that is paid when receiving an HTLC, but refunded
> if the HTLC is settled before the `hold_grace_period` ends (see footnotes about this).
My first instinct is that additional complications are worse in general.
However, it looks like simpler solutions are truly not enough, so adding the complication may very well be necessary.
Possibly one of the issues with previous proposals is that we considered the source as the payer of upfront fees always, without considering the possibility of the destination paying upfront fees.
We should consider *why* we did so.
Is it only because of lack of imagination?
The succeeding text refers to HTLCs "settling".
What does this mean exactly?
Does it refer to the preimage being revealed only?
Or does it refer to *either* `update_fulfill_htlc` **OR** `update_fail_htlc`?
If "settling" does not include failing the HTLC, I can extract hold fees from my peers by giving them HTLCs to random hashes that with very high probability has a preimage unknown to my peer.
Thus, "settling" here must also include failing the HTLC.
Can we arrange the HTLC as below?
* The HTLC is lower by the from-destination hold fee than what it "should" be.
* So in your example, A would offer an HTLC that is 5 msat lower than what it "should" be, to represent the from-destination hold-fee.
* When the HTLC is fulfilled offchain, we move the hold fee amount from offerrer to acceptor, thus "refunding" the hold fee.
* If the HTLC is failed offchain, we just delete the HTLC.
The above would disincentivize dropping the channel onchain for whatever shenanigans might be possible there.
Note that if hold fees are always from the "main output" of the acceptor, then we cannot use single-funded channel opening.
Single-funded channel opening is significantly lower-risk as, if somebody opens a channel to you and then goes offline forever, you would not care, none of your funds are in the channel.
(Sure they could move funds out of the channel and *then* go offline forever, but you got paid for that by the forwarding fees in the first place.)
Dual-funding requires some amount of trust/reputation, where you would only be willing to put funds on the initiating peer if you are reasonably sure that they would remain online so that the funds you put in the channel are not uselessly locked.
If we also require that the hold fee be funded from the main output, then we cannot use single-funded channels, except perhaps with `push_msat`.
On the other hand, it might be useful to require that though, as a promise from the funder that yes, it *is* committed to making that channel work, and will thus `push_msat` at you so you can pay for hold fees.
>
> * A sends an HTLC to B:
> * `hold_grace_period = 100 sec`
> * `hold_fees = 5 msat`
> * `next_hold_grace_period = 90 sec`
> * forward upfront payment: 1 msat is deduced from A's main output and added to B's main output
> * backwards upfront payment: 5 msat are deduced from B's main output and added to A's main output
> * B forwards the HTLC to C:
> * `hold_grace_period = 90 sec`
> * `hold_fees = 6 msat`
> * `next_hold_grace_period = 80 sec`
> * forward upfront payment: 1 msat is deduced from B's main output and added to C's main output
> * backwards upfront payment: 6 msat are deduced from C's main output and added to B's main output
> * C forwards the HTLC to D:
> * `hold_grace_period = 80 sec`
> * `hold_fees = 7 msat`
> * `next_hold_grace_period = 70 sec`
> * forward upfront payment: 1 msat is deduced from C's main output and added to D's main output
> * backwards upfront payment: 7 msat are deduced from D's main output and added to C's main output
The fact that the hold fees are incrementing with distance from the source means intermediate nodes now have an unreliable oracle for distance-from-source, though I guess you mention that later.
It seems to me that we have no escape here, and we really do need to leak some more information, sigh.
>
> * Scenario 1: D settles the HTLC quickly:
> * all backwards upfront payments are refunded (returned to the respective main outputs)
> * only the forward upfront payments have been paid (to protect against `uncontrolled spam`)
>
> * Scenario 2: D settles the HTLC after the grace period:
> * D's backwards upfront payment is not refunded
> * If C and B relay the settlement upstream quickly (before `hold_grace_period_delta`) their backwards
> upfront payments are refunded
And in this case C earns.
Can C delay the refund to D to after the grace period even if D settled the HTLC quickly?
Hopefully the only way C can do that would be if it refused to respond to D giving the result of the HTLC, in which case --- would D be justified in dropping the channel onchain and hurting the connectivity of C (but also hurting its own connectivity, which might not be symmetric)?
> * all the forward upfront payments have been paid (to protect against `uncontrolled spam`)
>
> * Scenario 3: C delays the HTLC:
> * D settles before its `grace_period`, so its backwards upfront payment is refunded by C
> * C delays before settling upstream: it can ensure B will not get refunded, but C will not get
> refunded either so B gains the difference in backwards upfront payments (which protects against
> `controlled spam`)
> * all the forward upfront payments have been paid (to protect against `uncontrolled spam`)
>
> * Scenario 4: the channel B <-> C closes:
> * D settles before its `grace_period`, so its backwards upfront payment is refunded by C
> * for whatever reason (malicious or not) the B <-> C channel closes
> * this ensures that C's backwards upfront payment is paid to B
> * if C publishes an HTLC-fulfill quickly, B may have his backwards upfront payment refunded by A
> * if B is forced to wait for his HTLC-timeout, his backwards upfront payment will not be refunded
> but it's ok because B got C's backwards upfront payment
> * all the forward upfront payments have been paid (to protect against `uncontrolled spam`)
>
> If done naively, this mechanism may allow intermediate nodes to deanonymize sender/recipient.
> If the base `grace_period` and `hold_fees` are randomized, I believe this attack vector disappears,
> but it's worth exploring in more details.
>
> The most painful part of this proposal will be handling the `grace_period`:
>
> * when do you start counting: when you send/receive `update_add_htlc`, `commit_sig` or
> `revoke_and_ack`?
> * what happens if there is a disconnection (how do you account for the delay of reconnecting)?
You do not: a reliable peer would not have disconnected in the first place, in which case, it is the fault of the peer for getting disconnected and having a delay in reconnecting, possibly forfeiting the hold fee because of that.
> * what happens if the remote settles after the `grace_period`, but refunds himself when sending his
> `commit_sig` (making it look like from his point of view he settled before the `grace_period`)?
> I think in that case the behavior should be to give your peers some leeway and let them get away
> with it, but record it. If they're doing it too often, close channels and ban them; stealing
> upfront fees should never be worth losing channels.
Right, because there is the risk that communications latency delays a response that was *sent out* at the correct time but was *received in* after the grace period.
>
> I chose to make the backwards upfront payment fixed instead of scaling it based on the time an HTLC
> is left pending; it's slightly less penalizing for spammers, but is less complex and introduces less
> potential griefing against honest nodes. With the scaling approach, an honest node that has its
> channel unilaterally closed is too heavily penalized IMHO (because it has to pay for the maximum
> hold duration).
>
> I also chose to make the forward upfront payment constant (1 msat). Is it going to be a pain to
> bikeshed this constant? Do we need to add a mechanism to upgrade it? We don't want to make this
> more complex than it should.
Is 1msat going to even deter anyone?
I can make a thousand probes and just get charged a measly satoshi, which will not even buy a single piece of fish ball at a local street vendor (we call them "fish ball" as a courtesy, but in reality they are "flour disks" made with flour that was processed in equipment that was once in contact with fish at some unknown point in the past; still delicious when deep-fried and dipped in vinegar though), would that really deter anyone?
Regards,
ZmnSCPxj

2023-06-09 13:01:14

- reply

📅 Original date posted:2020-10-21
📝 Original message:
Good morning t-bast,
>
> I've started summarizing proposals, attacks and threat models on github [1].
> I'm hoping it will help readers get up-to-speed and avoid falling in the same pitfalls we already
> fell into with previous proposals.
Would my inane incremental routing idea also be in scope here? https://lists.linuxfoundation.org/pipermail/lightning-dev/2020-October/002811.html
Regards,
ZmnSCPxj

2023-06-09 13:01:10

- reply

📅 Original date posted:2020-10-13
📝 Original message:
Good morning Joost,
> > * I convince Rene to make a channel to me.
>
> You may succeed, but Rene is probably not going to pay you a hold fee because you're untrusted.
Immaterial: I am interested in damaging the Joost-Rusty and Rusty-Rene relationships, not necessarily recouping these funds.
>
>
> > * I connect to Joost.
> > * I prepay to Joost.
> > * I forward Me->Joost->Rusty->Rene->me.
> > * I am exploiting the pre-existing tr\*st that Rusty has to Joost, and the tr\*st that Rene has to Rusty.
> > * When the HTLC reaches me, I dicker around and wait until it is about to time out before ultimately failing.
> > * Rusty loses tr\*st in Joost, and Rene loses tr\*st in Rusty.
>
> But most importantly: you will have paid hold fees to Joost for the long lock time of the htlc. This should keep you from even trying this attack.
But I might be interested in paying money in order to damage your reputation with Rusty, and damaging the reputation of Rusty with Rene.
Thus my capacity to disrupt the network is increased linearly by the number of hops involved, thus my point: I think what should be paid should be for the entire route, not the first hop.
For that matter, how certain are you that Rene and Zeeman are not secretly the same person, have you seen them in the same room together?
As I pointed out before, the main reason to engage in these attacks is to lock up the capacity of less-capitalized competitors in the payment forwarding business.
Cases of slow payment resolution caused by intermediate nodes are more likely to be because of incompetence (crashing nodes, ISP disconnections, clumsy humans tripping on power supplies) than active malice.
Thus, the primary motivated attackers are the ends of the payment: the payer and payee, who, in this attack, are coordinating with each other to lock up the funds of multiple other lesser-capacity nodes (and which might be a single node).
To an extent, to protect against such attacks, we need to know the payer and payee and somehow judge their tr\*stworthiness --- but we want to not have to reveal their identities, since that works against our privacy.
Hmmm.
Regards,
ZmnSCPxj

2023-06-09 13:01:09

- reply

📅 Original date posted:2020-10-13
📝 Original message:
Good morning Joost,
> > > A. Prepayment: node pays an amount to its channel peer (for example via keysend) and the channel peer deducts the hold fees from that prepaid balance until it is at zero. At that point it somehow (in the htlc fail message?) communicates Lightning's version of http 402 to ask for more money.
> >
> > If the node has already forwarded the HTLC onward, what enforcement hold does the node have on the sender of the incoming HTLC?
> > Presumably the sender of the HTLC has already gotten what it wanted --- an outgoing HTLC --- so how can the forwarding node enforce this request to get more money.
>
> The idea is that the available prepaid hold fee balance is enough to cover the worst case hold fee. Otherwise the forward won't happen. The main difference with option B is that you pay a sum upfront which can be used to cover multiple forwards. And that this payment is a separate Lightning payment, not integrated with the add/fail/settle flow. I prefer option B, but implementation effort is also a consideration.
Okay, so basically, it becomes something like this.
* There exists a network Joost <-> Rusty <-> Rene
* I connect to Joost.
* I owe Rene some sats.
* First, I prepay Joost directly a bunch of sats.
* Joost is now willing to forward to Rusty, but Rusty is not yet willing to forward further.
* I prepay Rusty a bunch of sats.
* I effectively "spend" some of the prepaid service that I already paid to Joost in order to pay to Rusty.
* Finally, using the prepay to Joost and Rusty, I now can route a payment to Rene.
Is that approximately how it works out?
Does it mean that Joost and Rusty have to know the source of the payment route?
Worse, they have to keep track of prepaid fees from all nodes, not just their direct peers?
If the above is not done (i.e. if I only prepay Joost but not Rusty) then it seems to me that the below remote attack is possible:
* I convince Rene to make a channel to me.
* I connect to Joost.
* I prepay to Joost.
* I forward Me->Joost->Rusty->Rene->me.
* I am exploiting the pre-existing tr\*st that Rusty has to Joost, and the tr\*st that Rene has to Rusty.
* When the HTLC reaches me, I dicker around and wait until it is about to time out before ultimately failing.
* Rusty loses tr\*st in Joost, and Rene loses tr\*st in Rusty.
---
Thinking a little more deeply: it is in principle possible to give a financial value to an amount of msat being locked for an amount of time.
For instance the C-Lightning `getroute` has a `riskfactor` argument which is used in this conversion.
Basically, by being locked in an HTLC and later failing, then the forwarding node loses the expected return on investment if instead the amount were locked in an HTLC that later succeeds.
Now, the cost on a forwarding node is based on the actual amount of time that its outgoing HTLC is locked.
When we consider multi-hop payments, then we should consider that the initiator of the multi-hop payment is asking multiple nodes to put their funds at risk.
Thus, the initiator of a multi-hop payment should, in principle, prepay for *all* the risk of *all* the hops.
If we do not enforce this, then an initiator of a multi-hop payment can pay a small amount relative to the risk that *all* the hops are taking.
Secondarily, we currently assume that forwarding nodes will, upon having their outgoing HTLC claimed, seek to claim the incoming HTLC as quickly as possible.
This is because the incoming HTLC would be locked and unuseable until they claim their incoming HTLC, and the liquidity would not be usable for earning more fees until the incoming HTLC is claimed and put into its pool of liquidity.
However, if we make anything that is based on the time that a forwarding node claims its incoming HTLC, then this may incentivize the forwarding node to delay claiming the incoming HTLC.
>
> > > B. Tightly integrated with the htlc add/fail/settle messages. When an htlc is added, the maximum cost (based on maximum lock time) for holding is deducted from the sender's channel balance. When the htlc settles, a refund is given based on the actual lock time. An additional `update_fee`-like message is added for peers to update their hold fee parameters (fee_base and fee_rate).
> >
> > If I am a forwarding node, and I receive the preimage from the outgoing HTLC, can I deliberately defer claiming the incoming HTLC (pretending that the outgoing HTLC was taking longer than it actually took) in order to reduce the amount I have to refund?
>
> Yes you can. That is the trust part, your peer trusts you not to do this. If they don't trust you, they won't forward to you if you charge a (high) hold fee.
What happens if I charge a tiny hold feerate in msats/second, but end up locking the funds for a week?
How does my peer know that even though I charge a tiny hold fee, I will hold their funds hostage for a week?
> > > In both cases the sender needs to trust its peer to not steal the payment and/or artificially delay the forwarding to inflate the hold fee. I think that is acceptable given that there is a trust relation between peers already anyway.
> >
> > I am wary of *adding* trust.
> > You might trust someone to keep an eye on your snacks while you go refill your drink, but not to keep an eye on your hardware wallet when you do the same.
> > (Since consuming snacks and drinks and hardware wallets are human activities, this should show that I am in fact a human.)
>
> So I am arguing that there is trust already between peers. Quite considerable trust even in case of high on-chain fee conditions. The added risk of being scammed out of these prepay sats may not be significant.
Well, onchain activity is fairly rare in practice, so I am uncertain about the relative size of prepays compared to relative fees of onchain activity.
I imagine payment forwardings to be much more common than onchain activity, thus the prepays can add up and be significant compared to fees on onchain activity, thus the tr\*st being considered may end up being a good fraction of the current tr\*st.
Regards,
ZmnSCPxj

2023-06-09 13:01:08

- reply

📅 Original date posted:2020-10-12
📝 Original message:
Good morning Joost,
I would like some clarifications on this mechanism.
> A. Prepayment: node pays an amount to its channel peer (for example via keysend) and the channel peer deducts the hold fees from that prepaid balance until it is at zero. At that point it somehow (in the htlc fail message?) communicates Lightning's version of http 402 to ask for more money.
If the node has already forwarded the HTLC onward, what enforcement hold does the node have on the sender of the incoming HTLC?
Presumably the sender of the HTLC has already gotten what it wanted --- an outgoing HTLC --- so how can the forwarding node enforce this request to get more money.
> B. Tightly integrated with the htlc add/fail/settle messages. When an htlc is added, the maximum cost (based on maximum lock time) for holding is deducted from the sender's channel balance. When the htlc settles, a refund is given based on the actual lock time. An additional `update_fee`-like message is added for peers to update their hold fee parameters (fee_base and fee_rate).
If I am a forwarding node, and I receive the preimage from the outgoing HTLC, can I deliberately defer claiming the incoming HTLC (pretending that the outgoing HTLC was taking longer than it actually took) in order to reduce the amount I have to refund?
> In both cases the sender needs to trust its peer to not steal the payment and/or artificially delay the forwarding to inflate the hold fee. I think that is acceptable given that there is a trust relation between peers already anyway.
I am wary of *adding* trust.
You might trust someone to keep an eye on your snacks while you go refill your drink, but not to keep an eye on your hardware wallet when you do the same.
(Since consuming snacks and drinks and hardware wallets are human activities, this should show that I am in fact a human.)
How about this?
Before, when thinking about JIT routing, I suggested that a JIT-routing enabled forwarding node should only be willing to pay for the JIT rebalancing up to some fraction (less than 1.0) of the amount already earned from the outgoing channel, in order to protect against some attacks.
And when the JIT-routing node does a rebalance in order to serve the forwarding, it should deduct the cost of the rebalance from its cumulative sum of earnings from that outgoing channel.
The effect of the above is that the already-earned forwarding fees serves as a "level of trust" that the rebalancing in order to serve the outgoing forward will not be wasted.
Perhaps intermediate nodes should limit incoming HTLCs from peers that have not given them a lot of successful forwards and earned forwarding fees from those forwards.
i.e. if it is a new peer, you allow HTLCs up to a certain size, then if the outgoing HTLC is claimed quickly rather than slowly and you earn a good amount of fee, you might be willing to increase the limits of incoming HTLCs.
This is effectively "growing trust".
Of course, now we have to wonder about exit scams where a node manipulates you into increasing this "trust score" and later screwing you over when you are willing to accept larger total HTLCs.... Sigh.
On the other hand, if you base this on the amount of fees you earn per unit time and deducting the converted risk of having your fees locked in outgoing HTLCs, then attackers have to effectively pay you forwarding fees first before they can attack you, and once they attack, they lose the accumulated score.
So in some way, this system functions a little like pre-paid fees, except the pre-payment is in the actual pay-on-successful-forwarding of previous HTLCs you have forwarded.
Maybe.
Regards,
ZmnSCPxj

2023-06-09 13:01:03

- reply

📅 Original date posted:2020-10-07
📝 Original message:
Good morning Antoine, Bastien, and list,
> > Instead of relying on reputation, the other alternative is just to have an upfront payment system, where a relay node doesn't have to account for a HTLC issuer reputation to decide acceptance and can just forward a HTLC as long it paid enough. More, I think it's better to mitigate jamming with a fees-based system than a web-of-trust one, less burden on network newcomers.
>
> Let us consider some of the complications here.
>
> A newcomer wants to make an outgoing payment.
> Speculatively, it connects to some existing nodes based on some policy.
>
> Now, since forwarding is upfront, the newcomer fears that the node it connected to might not even bother forwarding the payment, and instead just fail it and claim the upfront fees.
>
> In particular: how would the newcomer offer upfront fees to a node it is not directly channeled with?
> In order to do that, we would have to offer the upfront fees for that node, to the node we are channeled with, so it can forward this as well.
>
> - We can give the upfront fee outright to the first hop, and trust that if it forwards, it will also forward the upfront fee for the next hop.
> - The first hop would then prefer to just fail the HTLC then and there and steal all the upfront fees.
> - After all, the offerrer is a newcomer, and might be the sybil of a hacker that is trying to tie up its liquidity.
> The first hop would (1) avoid this risk and (2) earn more upfront fees because it does not forward those fees to later hops.
>
> - This is arguably custodial and not your keys not your coins applies.
> Thus, it returns us back to tr\*st anyway.
>
> - We can require that the first hop prove where along the route errored.
> If it provably failed at a later hop, then the first hop can claim more as upfront fees, since it will forward the upfront fees to the later hop as well.
> - This has to be enforcable onchain in case the channel gets dropped onchain.
> Is there a proposal SCRIPT which can enforce this?
>
> - If not enforcable onchain, then there may be onchain shenanigans possible and thus this solution might introduce an attack vector even as it fixes another.
> - On the other hand, sub-satoshi amounts are not enforcable onchain too, and nobody cares, so...
One thing I have been thinking about, but have not proposed seriously yet, would be "incremental routing".
Basically, the route of pending HTLCs also doubles as an encrypted bidirectional tunnel.
Let me first describe how I imagine this "incremental routing" would look like.
First, you offer an HTLC with a direct peer.
The data with this HTLC includes a point, which the peer will ECDH with its own privkey, to form a shared secret.
You can then send additional messages to that node, which it will decrypt using the shared secret as the symmetric encryption key.
The node can also reply to those messages, by encrypting it with the same symmetric encryption key.
Typically this will be via a stream cipher which is XORed with the real data.
One of the messages you can send to that node (your direct peer) would be "please send out an HTLC to this peer of yours".
Together with that message, you could also bump up the value of the HTLC, and possibly the CLTV delta, you have with that node.
This bumping up is the forwarding fee and resolution time you have to give to that node in order to have it safely put an HTLC to the next hop.
If there is a problem on the next hop, the node replies back, saying it cannot forward the HTLC further.
Your node can then respond by giving an alternative next hop, which that node can reply back is also not available, etc. until you say "give up" and that node will just fail the HTLC.
However, suppose the next hop is online and there is enough space in the channel.
That node then establishes the HTLC with the next hop.
At this point, you can then send a message to the direct peer which is nothing more than "send the rest of this message as the message to the next hop on the same HTLC, then wait for a reply and wrap it and reply to me".
This is effectively onion-wrapping the message to the peer of your peer, and waiting for an onion-wrapped reply from the peer of your peer.
You can then talk to the peer of your peer (of your peer...) to incrementally build the rest of the route, until you reach the destination.
How is this related to upfront payments?
Well, in upfront payments, on the timelock branch, instead of the entire fund value returning to the offerer of the HTLC, part of the fund value is given forward to the next peer.
For onchain enforcement the upfront payment is simply added to the miner fees, so at least the one offerring it does not have incentive to drop it onchain to play onchain shenanigans.
Now, suppose your direct peer requires an upfront payment before it will even bother make an outgoing HTLC on the strength of your incoming one.
So, you bump up your HTLC, and arrange to have the timelock branch give the upfront payment to the direct peer.
Then, you can now ask the peer to open an HTLC to the next peer, on the basis of that upfront payment.
Of course, if the peer of the peer is not the destination, you still have to increment further.
You then bump up the upfront payment of the direct peer, with a message to offer an equivalent amount of upfront payment to the peer of the peer.
Your direct peer can then pretend that communication with the peer of the peer failed, so it should get the bumped-up upfront payment, equivalent to the upfront payments of itself plus the next peer.
However, at any one time, the upfront payment that can be stolen by your direct peer can only amount to the upfront fee of a single hop, the one that is being built out next in the incremental routing.
This is because it has already offered the upfront payment to the next hop.
Some numbers may make this easier to understand.
For example, suppose all nodes require 1msat prepaid to send out to the next hop.
At the start, you are just offering the HTLC amount with 0 msat in upfront payment.
Then you increase the upfront payment by 1msat, then tell the direct peer to create an HTLC to the peer of the peer, of equal HTLC value, but with 0 msats in upfront payment.
Next, you increase the upfront payment to the direct peer to 2msat, then tell the direct peer to bump up the upfront payment of its outgoing HTLC by 1 msat as well.
Then next, you increase the upfront payment to the direct peer to 3 msat.
The direct peer is giving out 1 msat upfront payment to the outgoing HTLC, which it is now supposed to increase to 2msat.
After doing that, it sends a message to the peer of the peer.
The peer of the peer is giving out 0 msat upfront payment, which it is now supposed to increase to 1 msat.
After doing that, it sends a message to the peer of the peer of the peer.
The peer of the peer of the peer has no outgoing HTLC yet, but since it is now being offered 1msat in upfront fee, it is now wlling to be instructed to send out an outgoing HTLC to another channel.
And so on.
At any one time, an intermediate node can pretend communications to the next node in the route failed, and claim 2msat in upfront fee instead of 1msat.
But it cannot steal more than the equivalent of the upfront fee of one node.
(I elide the fact that in this scheme, you would *also* offer a fee conditional on the HTLC actually pushing through; sort of like a "pay half now, pay half later on completion" deal; your imagination can fill in the rest.)
This is in contrast with upfront payments where you have to offer the upfront payment of all the nodes along the route to the direct peer.
The direct peer can, then and there, claim the entire upfront payment earmarked for the entire route.
A nice thing about incremental routing is that the time risk of your money being locked up can be managed a little easier.
You can start with an HTLC with the minimum time, then also bump up the time of the first HTLC (with time bumps rippling out along the incremental route) as you build up the incremental route until you reach the destination.
--
Against incremental routing, however, is that:
* It requires a lot more communication rounds and (symmetric, at least) cryptographic operations.
* Intermediate nodes can guess the distance from the source by measuring timing of a previous response to the next message from the payer.
* In particular, current LN can allow an intermediate node to guess the distance to the destination of a payment (by CLTV delta bounds) but *not* the distance to the source of the payment, with incremental routing the distance to the source of the payment is guessable as well from message timings.
* The idea is completely imaginary as of now with no peer review, and there may be actual cryptographic or practical problems with the idea.
Regards,
ZmnSCPxj

2023-06-09 13:01:00

- reply

📅 Original date posted:2020-10-05
📝 Original message:
Good morning Bastien,
> Good morning list,
>
> It seems to me that the "funder pays all the commit tx fees" rule exists solely for simplicity
> (which was totally reasonable). I haven't been able to find much discussion about this decision
> on the mailing list nor in the spec commits.
This indeed seems to be one of those "unwritten rules", like the unwritten rule that SCRIPT opcodes can only look at the transaction they are in and cannot look at the block it got confirmed in, or previous blocks.
My rough understanding is that it prevents this kind of griefing attack:
* You have a node with channels balanced just as you like it, very lucrative, earning entire satoshis of routing fees per week.
* I have a bunch of funds lying around, much larger than your liquidity.
* I create a temporary throwaway node and have it make a large channel to you about equal to your liquidity.
* I send out all of the funds on the new large channel, preferably to offchain-to-onchain swaps like Loop or Boltz.
* This shrinks the outgoing liquidity you have available on your existing channels, making it difficult for you to route and earn routing fees -- in order to route, you need to have *both* incoming and outgoing liquidity.
* If I do not make another channel with my new node, then you cannot rebalance offchain.
* Since my new large channel is now exhausted, I can delete the throwaway node forever.
* The `close_to` feature also allows me to arrange the funds to be closed to a cold-storage funds.
* Or I can just keep the necessary keys to recover funds from the unilateral channel close broadcast by you later.
* There is a reserve, but that is tiny, and if so I can probably afford to wait --- this is a game of chicken on who closes the channel, and since most of the channel is on your end, you are at a serious disadvantage.
* You are now forced to unilateral close the channel so you can send it to an onchain-to-offchain swap and reload your channels into the proper balance it had before I attacked you.
If the unilateral close on the channel were paid by you, then that is adding insult to injury.
Thus, it is better if the unilateral close were paid by me, even if ultimately the unilateral close is performed by you.
This is "initiator pays" principle.
--
On the other hand, a quick skim of your proposal suggests that it still respects the "initiator pays" principle.
Basically, the fundee only pays fees for HTLCs they initiated, which is not relevant to the above attack (since in the above attack, my node is a dead end, you will never send out an HTLC through my channel to rebalance).
So it should still be acceptable.
Regards,
ZmnSCPxj
>
> At first glance, it's true that at the beginning of the channel lifetime, the funder should be
> responsible for the fee (it's his decision to open a channel after all). But as time goes by and
> both peers earn value from this channel, this rule becomes questionable. We've discovered since
> then that there is some risk associated with having pending HTLCs (flood-and-loot type of attacks,
> pinning, channel jamming, etc).
>
> I think that *in some cases*, fundees should be paying a portion of the commit-tx on-chain fees,
> otherwise we may end up with a web-of-trust network where channels would only exist between peers
> that trust each other, which is quite limiting (I'm hoping we can do better).
>
> Routing nodes may be at risk when they *receive* HTLCs. All the attacks that steal funds come from
> the fact that a routing node has paid downstream but cannot claim the upstream HTLCs (correct me
> if that's incorrect). Thus I'd like nodes to pay for the on-chain fees of the HTLCs they offer
> while they're pending in the commit-tx, regardless of whether they're funder or fundee.
>
> The simplest way to do this would be to deduce the HTLC cost (172 * feerate) from the offerer's
> main output (instead of the funder's main output, while keeping the base commit tx weight paid
> by the funder).
>
> A more extreme proposal would be to tie the *total* commit-tx fee to the channel usage:
>
> * if there are no pending HTLCs, the funder pays all the fee
> * if there are pending HTLCs, each node pays a proportion of the fee proportional to the number of
> HTLCs they offered. If Alice offered 1 HTLC and Bob offered 3 HTLCs, Bob pays 75% of the
> commit-tx fee and Alice pays 25%. When the HTLCs settle, the fee is redistributed.
>
> This model uses the on-chain fee as collateral for usage of the channel. If Alice wants to forward
> HTLCs through this channel (because she has something to gain - routing fees), she should be taking
> on some of the associated risk, not Bob. Bob will be taking the same risk downstream if he chooses
> to forward.
>
> I believe it also forces the fundee to care about on-chain feerates, which is a healthy incentive.
> It may create a feedback loop between on-chain feerates and routing fees, which I believe is also
> a good long-term thing (but it's hard to predict as there may be negative side-effects as well).
>
> What do you all think? Is this a terrible idea? Is it okay-ish, but not worth the additional
> complexity? Is it an amazing idea worth a lightning nobel? Please don't take any of my claims
> for granted and challenge them, there may be negative side-effects I'm completely missing, this is
> a fragile game of incentives...
>
> Side-note: don't forget to take into account that the fees for HTLC transactions (second-level txs)
> are always paid by the party that broadcasts them (which makes sense). I still think this is not
> enough and can even be abused by fundees in some setups.
>
> Thanks,
> Bastien

2023-06-09 13:00:57

- reply

📅 Original date posted:2020-10-11
📝 Original message:
Good morning t-bast,
> Hey Zman,
>
> > raising the minimum payment size is another headache
>
> It's true that it may (depending on the algorithm) lower the success rate of MPP-split.
> But it's already a parameter that node operators can configure at will (at channel creation time),
> so IMO it's a complexity we have to deal with anyway. Making it dynamic shouldn't have a high
> impact on MPP algorithms (apart from failures while `channel_update`s are propagating).
Right, it should not have much impact.
For the most part, when considering the possibility of splicing in the future, we should consider that such parameters must be made changeable largely.
>
> To be fully honest, my (maybe unpopular) opinion about MPP is that it's not necessary on the
> network's backbone, only at its edges. Once the network matures, I expect channels between
> "serious" routing nodes to be way bigger than the size of individual payments. The only places
> where there may be small or almost-empty channels are between end-users (wallets) and
> routing nodes.
> If something like Trampoline were to be implemented, MPP would only be needed to reach a
> first routing node (short route), that routing node would aggregate the parts and forward as a
> single HTLC to the next routing node. It would be split again once it reaches the other edge
> of the network (for a short route as well). In a network like this, the MPP routes would only have
> to be computed on a small subset of the network, which makes brute-force algorithms completely
> reasonable and the success rate higher.
This makes me wonder if we really need the onions-per-channel model we currently use.
For instance, Tor is basically two-layer: there is a lower-level TCP/IP layer where packets are sent out to specific nodes on the network and this layer is completely open about where the packet should go, but there is a higher layer where onion routing between nodes is used.
We could imitate this, with HTLC packets that openly show the next destination node, but once all parts reach the destination node, it decodes and turns out to be an onion to be sent to the next destination node, and the current destination node is just another forwarder.
HTLC packets could be split arbitrarily, and later nodes could potentially merge with the lower CLTV used in subsequent hops.
Or not, *shrug*.
It has the bad problem of being more expensive on average than purely source-based routing, and probably having worse payment latency.
For your proposal, how sure is the receiver that the input end of the trampoline node is "nearer" to the payer than itself?
Regards,
ZmnSCPxj

2023-06-09 13:00:57

- reply

📅 Original date posted:2020-10-08
📝 Original message:
Good morning t-bast,
> Please forget about channel jamming, upfront fees et al and simply consider the parameters I'm
> mentioning. It feels to me that these are by nature dynamic channel parameters (some of them are
> even present in `channel_update`, but no-one updates them yet because direct peers don't take the
> update into account anyway). I'd like to raise `htlc_minimum_msat` on some big channels because
> I'd like these channels to be used only for big-ish payments. Today I can't, I have to close that
> channel and open a new one for such a trivial configuration update, which is sad.
At the risk of once more derailing the conversation: from the MPP trenches, raising the minimum payment size is another headache.
The general assumption with MPP is that smaller amounts are more likely to get through, but if anyone is making a significant bump up in `htlc_minimum_msat`, that assumption is upended and we have to reconsider if we may actually want to merge multiple failing splits into one, as well as considering asymmetric splits (in particular asymmetric presplits) because maybe the smaller splits will be unable to pass through the bigger channels but the bigger-side split *might*.
On the other hand: one can consider that the use of big payments as an aggregation.
For example: a forwarding node might support smaller `htlc_minimum_msat`, then after making multiple such forwards, find that a channel is now heavily balanced towards one side or another.
It can then make a single large rebalance via one of the high-`htlc_minimum_msat` channels t-bast is running.
Regards,
ZmnSCPxj

2023-06-09 13:00:56

- reply

📅 Original date posted:2020-10-06
📝 Original message:
Good morning Antoine, and Bastien,
> Instead of relying on reputation, the other alternative is just to have an upfront payment system, where a relay node doesn't have to account for a HTLC issuer reputation to decide acceptance and can just forward a HTLC as long it paid enough. More, I think it's better to mitigate jamming with a fees-based system than a web-of-trust one, less burden on network newcomers.
Let us consider some of the complications here.
A newcomer wants to make an outgoing payment.
Speculatively, it connects to some existing nodes based on some policy.
Now, since forwarding is upfront, the newcomer fears that the node it connected to might not even bother forwarding the payment, and instead just fail it and claim the upfront fees.
In particular: how would the newcomer offer upfront fees to a node it is not directly channeled with?
In order to do that, we would have to offer the upfront fees for that node, to the node we *are* channeled with, so it can forward this as well.
* We can give the upfront fee outright to the first hop, and trust that if it forwards, it will also forward the upfront fee for the next hop.
* The first hop would then prefer to just fail the HTLC then and there and steal all the upfront fees.
* After all, the offerrer is a newcomer, and might be the sybil of a hacker that is trying to tie up its liquidity.
The first hop would (1) avoid this risk and (2) earn more upfront fees because it does not forward those fees to later hops.
* This is arguably custodial and not your keys not your coins applies.
Thus, it returns us back to tr\*st anyway.
* We can require that the first hop prove *where* along the route errored.
If it provably failed at a later hop, then the first hop can claim more as upfront fees, since it will forward the upfront fees to the later hop as well.
* This has to be enforcable onchain in case the channel gets dropped onchain.
Is there a proposal SCRIPT which can enforce this?
* If not enforcable onchain, then there may be onchain shenanigans possible and thus this solution might introduce an attack vector even as it fixes another.
* On the other hand, sub-satoshi amounts are not enforcable onchain too, and nobody cares, so...
On the other hand, a web-of-tr\*st might not be *that* bad.
One can say that "tr\*st is risk", and consider that the size and age of a channel to a peer represents your tr\*st that that peer will behave correctly for fast and timely resolution of payments.
And anyone can look at the blockchain and the network gossip to get an idea of who is generally considered tr\*stworthy, and since that information is backed by Bitcoins locked in channels, this is reasonably hard to fake.
On the other hand, this risks centralization around existing, long-lived nodes.
*Sigh*.
Regards,
ZmnSCPxj

2023-06-09 13:00:50

- reply

📅 Original date posted:2020-09-03
📝 Original message:
Good morning Christian, Nadav, and all,
>
> Escrow collusion
>
> -----------------
>
> While not particularly familiar with SCU, I think the escrow might need
> to be ultimately trusted, since giving it the ability to act as
> co-signer in lieu of a subset of participants, or even sole signature
> authority could lead to collusion between the escrow and the remainder
> of the contract participants, but I'm happy to be corrected here.
This is correct.
It should be noted that Smart Contracts Unchained is simply the logical extension of the buyer-seller-escrow 2-of-3 setup.
When locking up its funds, the buyer trusts that the escrow does not collude with the seller to steal the funds without sending product.
And when sending its product, the seller trusts that the escrow does not collude with the buyer to clawback the funds without returning the product.
As such, even if the number of participants increases, trust that the escrow does not perform collusion with any of the participants, must still exist.
This can be mitigated by having the escrow be a k-of-n federation.
If you have `t` trusted escrow entities, you must ensure `n - k < t`.
For example, if you trust only 3 escrows, then you would accept a 5-of-7 setup where 3 of the escrows are among the trusted set, and you would ensure that at most 2 of them are not involved in the signing.
But you would not accept 4-of-7, as all three of your trusted escrows could potentially be removed from the signing federation.
>
> We had similar considerations while working on the original channel
> factories paper, where we tried to come up with a scheme that'd allow a
> subset of participants to split out an inactive participant in order to
> recover from what would otherwise be a deadlock. We decided to drop that
> possibility due to the complexity involved and the potential for serious
> damage if participants collude.
Indeed.
I would like to point out, that channel factories, as they host channels, "degrade gracefully".
If you have an ABC channel factory, that hosts AB, BC, and AC channels, even if C is offline, the AB channel continues to work "seamlessly", without any care that C is offline.
Thus, I contend that channel factories hosting channels is sufficient, and there is no need for a "split out" function as described.
Subsets *already work*, at reduced capability (in the above example, the BC and AC channels no longer work, because C is offline, but AB can continue to work perfectly fine), as long as you use channel factories (where the n >= 3 mechanism holds only channels, never direct HTLCs or HODLings) instead of CoinPools/multiparticipant channels.
---
Given that most of the activity will be in "standard" 2-of-2 Poon-Dryja channels, and the factory is just a host for channels, you do not really need a fully-featured channel factory layer.
For example, it might be acceptable to use the Decker-Wattenhofer decrementing-`nSequence` mechanism for the channel factory layer.
This is trustless (no need for an Smart Contracts Unchained escrow federation or a Somsen Statechains blinded federation), at the cost of having a bad locktime-to-updates-limit tradeoff.
The above is acceptable since you can update the channels independently of the factory that hosts them (that is the entire point of channels, and why they take activity offchain, they can be updated without having to update whatever hosts them, whether a blockchain or another offchain mechanism)
(Indeed, one can take the point-of-view that the blockchain "goes offline" for stretches of time of around 10 minutes (i.e., the inter-block time), during which no updates to the blockchain layer are possible, and if you want to keep operating while the blockchain "goes offline" (i.e. miners are still solving the next block) then you can use payment channels.)
The general use of updating the factory layer would be to rebalance the channels inside it.
But we already *can* rebalance today, without factories, and without any activity on the layer that hosts the channels, by self-paying.
Thus, having a limit on the number of updates on the factory layer may be an acceptable tradeoff, since you can always prioritize rebalancing at the channels layer (i.e. Lightning already currently works with just that), and only fall back to rebalancing at the factory layer if it would not be lucrative to do the rebalancing at the channels layer, and enough of the factory participants think it is a good idea to simultaneously rebalance on the factory layer at that point.
I think channel factories (which **only** host channels, and never HTLCs or HODLings, so I think "multiparticipant channels" is either a misnomer, or the wrong thing entirely) have the major advantage of greatly reducing the onchain footprint, and simultaneously having a decent "graceful degradation" (i.e. the individual channels in it continue to operate even if one of the factory participants is offline).
---
In any case, if you still want to continue to use Smart Contracts Unchained, I suggest merging the escrow functionality with watchtower functionality.
This does not improve security (escrows can still collude with other channel participants) but does improve privacy and increases your anonymity set when you are not colluding with your escrows.
With this, your setup to enter into a Smart Contracts Unchained contract would be:
* Agree on the contract.
* Create a funding transaction that pays to an n-of-n of the participants.
* Create a contract transaction that pays to a k-of-n of the escrow federation, spending the above funding transaction output.
* This is signed with a sign-to-contract, where the `R` commits to a hash of the contract.
* Broadcast and sign the funding transaction.
* Send a `(halftxid, encrypted_blob)` pair to the escrow federation.
* The `halftxid` is half of the `txid` of the contract transaction.
* The `encrypted_blob`, when decrypted, shows that it is actually a Smart Contracts Unchained contract (and not a normal Lightning watchtower blob) and contains the contract and the decommitment in the sign-to-contract.
When the contract transaction is confirmed onchain, the escrow federation performs the normal watchtower operation of taking the full txid of the encrypted blob, and if it decodes successfully, can now open the enrypted blob and read the contract.
It checks that the contract matches the signature on the contract transaction, then if that matches, enforces the contract.
(It seems to me a good idea to make watchtowers general enough that they can support not just Lightning, but also CoinSwap and Smart Contracts Unchained, if only for the improved anonymity set.)
I am almost certain that a Smart Contract Unchained Escrowed Decker-Russell-Osuntokun channel factory can merge the watchtower and escrow functionality as well, using the above basic sketch, with additional overlay network to allow for federated escrows.
The issue is really the increased complexity of the `(halftxid, encrypted_blob)` scheme with Decker-Russell-Osuntokun.
(To my knowledge, Decker-Russell-Osuntokun only simplifies watchtowers if the watchtower knows the funding outpoint, which is information we should really prefer the watchtower to not know unless an attack occurs; with an unknown-funding-outpoint, `(halftxid, encrypted_blob)` scheme, Decker-Russell-Osuntokun is actually more complicated, since hiding the funding outpoint prevents having a simple key for the watchtower to replace.)
Regards,
ZmnSCPxj

2023-06-09 13:00:35

- reply

📅 Original date posted:2020-07-17
📝 Original message:
Good morning Ankit,
I believe what you describe is a specific form of what is called the Wormhole attack.
In the general form, the Wormhole attack has two forwarding nodes in a path that are coordinating with each other, and they can "teleport" the preimage from one to the other, skipping intermediate forwarding nodes.
The case you describe is the specific case where one of the nodes performing this attack on a path is the payee itself.
What is stolen here is not the payment amount, but the fees that the "skipped" forwarding nodes should have earned for honestly forwarding.
On the other hand, in that case, it is simply a form of the griefing attack: C and E are able to cause D to lock its funds into HTLCs without earning fees, but C and E can mount that attack at any time regardless of A or B anyway, so it is not an additional attack surface on D.
At a high level, this attack is not a concern.
As long as A is able to acquire the preimage, it has proof of payment, and it is immaterial *how* A managed to get the preimage, as Rene describes.
Even if E claims that it did not deliberately give the preimage and that it was hacked by C, then it is C who is liable, in which case C and E, being a cooperating team, have gained nothing at all (and just made C angry at E for throwing C under the bus).
Basically, the preimage *is* the proof.
There are only two things you need to do:
* Ensure that invoices are signed by E (meaning E agreed to perform some service if the preimage is revealed by anyone).
BOLT11 already requires this.
* Ensure that invoices indicate *who exactly* is going to get the service or product.
Since the preimage is learned by every intermediate hop, it cannot be a bearer certificate, so it must indicate specifically that the beneficiary of the product or service will be A.
With the above, A can be sure that paying in exchange for getting the preimage, is a binding contract on the service indicated by the invoice.
The preimage and the invoice (that has a signature from E), are sufficient to show that E has an obligation to provide a service or product to A.
The wormhole attack (which steals fees from D) is fixed by using PTLCs and blinding factors.
E learns the total of all blinding factors, and knows the final scalar, but does not know the blinding factor delta from C to E, and thus cannot give C any information on how to claim the funds.
Regards,
ZmnSCPxj
> Hey Ankit,
>
> The lightning network sees the possession of a preimage as a proof of payment. And I believe everyone agrees that a court should rule in favor of A forcing E to deliver the good or reimburse A. The reason is that possession of the preimage matching the signed payment hash from E is a much stronger evidence of A actually having paid than E claiming to not have received anything.
> This is also due to the fact that guessing the preimage can practically be considered impossible (though there is a tiny likelihood)
>
> If E breaches the protocol by giving the preimage to C (for free) instead of claiming the money from D (and thus settling the Htlc) it will be considered E's problem, that E did not get reimbursed but just gave out the preimage for free. (actually E's so called "partner in crime" did get reimbursed). Even if D would testify that E never settled the Htlc one would wonder why E never settled the incoming htlc as they should only have created a payment hash for which they know the preimage. Since A can actually provide one it is again unlikely if E for example claims they just used a random hash for which they didn't know the preimage because they wanted to just see if A has enough liquidity.
>
> With kind regards Rene
>
> Ankit Gangwal <A.Gangwal at tudelft.nl> schrieb am Fr., 17. Juli 2020, 08:43:
>
> > Consider A wants to send some funds to E.
> >
> > They don’t have a direct payment channel among them. So, they use a following path A-B-C-D-E. A is the sender of payment and E is final recipient.
> >
> > E sends the hash of a secret r to A, A passes on the hash to B, B to C, C to D, and D to E.
> >
> > E discloses the secret to C (a partner in crime with E) and E do not respond to D. C gives the secret to B (settling the HTLC between them). Then, B gives the secret to A (settling the HTLC between them).
> >
> > A sent (and lost) the money, as E denies receiving the money (and the promised service/good).
> >
> > How the lightening network sees this? Out of their control?
> >
> > --
> >
> > A_G
> >
> >
> >
> > _______________________________________________
> > Lightning-dev mailing list
> > Lightning-dev at lists.linuxfoundation.org
> > https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev

2023-06-09 13:00:31

- reply

📅 Original date posted:2020-06-22
📝 Original message:
Good morning Bastien,
> Thanks for the detailed write-up on how it affects incentives and centralization,
> these are good points. I need to spend more time thinking about them.
>
> > This is one reason I suggested using independent pay-to-preimage
> > transactions[1]
>
> While this works as a technical solution, I think it has some incentives issues too.
> In this attack, I believe the miners that hide the preimage tx in their mempool have
> to be accomplice with the attacker, otherwise they would share that tx with some of
> their peers, and some non-miner nodes would get that preimage tx and be able to
> gossip them off-chain (and even relay them to other mempools).
I believe this is technically possible with current mempool rules, without miners cooperating with the attacker.
Basically, the attacker releases two transactions with near-equal fees, so that neither can RBF the other.
It releases the preimage tx near miners, and the timelock tx near non-miners.
Nodes at the boundaries between those that receive the preimage tx and the timelock tx will receive both.
However, they will receive one or the other first.
Which one they receive first will be what they keep, and they will reject the other (and *not* propagate the other), because the difference in fees is not enough to get past the RBF rules (which requires not just a feerate increase, but also an increase in absolute fee, of at least the minimum relay feerate times transaction size).
Because they reject the other tx, they do not propagate the other tx, so the boundary between the two txes is inviolate, neither can get past that boundary, this occurs even if everyone is running 100% unmodified Bitcoin Core code.
I am not a mempool expert and my understanding may be incorrect.
Regards,
ZmnSCPxj

2023-06-09 13:00:31

- reply

📅 Original date posted:2020-06-20
📝 Original message:
Good morning again,
> Good morning Dave,
>
> > ZmnSCPxj noted that pay-to-preimage doesn't work with PTLCs.[2] I was
> > hoping one of Bitcoin's several inventive cryptographers would come
> > along and describe how someone with an adaptor signature could use that
> > information to create a pubkey that could be put into a transaction with
> > a second output that OP_RETURN included the serialized adaptor
> > signature. The pubkey would be designed to be spendable by anyone with
> > the final signature in a way that revealed the hidden value to the
> > pubkey's creator, allowing them to resolve the PTLC. But if that's
> > fundamentally not possible, I think we could advocate for making
> > pay-to-revealed-adaptor-signature possible using something like
> > OP_CHECKSIGFROMSTACK.[3]
>
> <snip>
>
> The signed message could be a signature to `SIGHASH_NONE`, finally an actual use for that flag.
If you are going to embed it in an `OP_RETURN` in the same transaction, you also need `SIGHASH_ANYPREVOUT`, otherwise you cannot embed the adaptor signature for spending from that transaction in the transaction being spent, it also implies `A[p4s] = a[p4s] * G` is a one-time-use keypair.
Regards,
ZmnSCPxj

2023-06-09 13:00:30

- reply

📅 Original date posted:2020-06-20
📝 Original message:
Good morning Dave,
> ZmnSCPxj noted that pay-to-preimage doesn't work with PTLCs.[2] I was
> hoping one of Bitcoin's several inventive cryptographers would come
> along and describe how someone with an adaptor signature could use that
> information to create a pubkey that could be put into a transaction with
> a second output that OP_RETURN included the serialized adaptor
> signature. The pubkey would be designed to be spendable by anyone with
> the final signature in a way that revealed the hidden value to the
> pubkey's creator, allowing them to resolve the PTLC. But if that's
> fundamentally not possible, I think we could advocate for making
> pay-to-revealed-adaptor-signature possible using something like
> OP_CHECKSIGFROMSTACK.[3]
Not a cryptographer, I just play one on the Internet, but maybe the pay-for-signature construction could work...?
Assuming a PTLC has a pointlocked branch, which involves signing with MuSig(A, B).
A offers to B the amount if B reveals the secret `t` behind `T = t * G`; A knows `T` but not `t`.
This is done by B handing over `R[B]` and `s'[B]`:
R = R[A] + R[B] + T
s'[B] = r[B] + h(MuSig(A, B) | R | m) * b
Then A provides its partial signature to B.
s[A] = r[A] + h(MuSig(A, B) | R | m) * a
B has to complete the signature by:
s = s[A] + s'[B] + t
Since A knows both `s[A]` and `s'[B]`, once it knows `s`, it can compute `t`.
Now, we can massage the equation for `s`:
s = r[A] + h(MuSig(A, B) | R | m) * a + r[B] + h(MuSig(A, B) | R | m) * b + t
; multiply both sides by G
s * G = r[A] * G + h(MuSig(A, B) | R | m) * a * G + r[B] * G + h(MuSig(A, B) | R | m) * b * G + t * G
; replace with public points
s * G = R[A] + h(MuSig(A, B) | R | m) * A + R[B] + h(MuSig(A, B) | R | m) * B + T
Note that A can compute `s * G` above, because it generated `R[A]`, was given `R[B]` and `T`, and knows who `A` and `B` are.
So what A needs to do is to offer a fund that can only be claimed by leaking knowledge of `s` behind `s * G`.
A can do this by creating a new keypair `A[p4s] = a[p4s] * G` and putting a fund into it.
Then A generates an `R[A][p4s] = r[A][p4s] * G`, and computes:
R[p4s] = R[A][p4s] + s * G
s'[A][p4s] = r[A][p4s] + h(A | R[p4s] | m) * a[p4s]
The signed message could be a signature to `SIGHASH_NONE`, finally an actual use for that flag.
A reveals publicly (in an `OP_RETURN` as you suggest):
* `R[A][p4s]`
* `s * G`
* `s'[A][p4s]`
* `A[p4s]` - Already the Schnorr output pubkey.
In order to complete the above signature, a third party C has to learn `s` from B.
The third party has to scan every onchain 1-of-1 signature for an `s` that matches `s * G`, so there is greater processing (point multiplies are more expensive than hashes, also there are more 1-of-1s).
But once learned, the third party can complete the signature and claim the funds.
And A then learns `s`, from which it can derive `t`.
The third party learns about which channel (i.e. the UTXO that was spent to create the PTLC in the first place), but never learns `t` or `T`, which is a small but nice privacy bonus.
Regards,
ZmnSCPxj

2023-06-09 13:00:26

- reply

📅 Original date posted:2020-06-21
📝 Original message:
Good morning Jeremy,
> My understanding is that you can use the CTV deferral to also get independent HTLC relative timelocks start points per output. This would help with this sort of issue right?
>
> And you're correct that there's overhead of indirection, but it's not super large (minimally complicated something like an extra 100 bytes per output, if you were to have a flat array where each entry is a CTV output so that each out gets its own clock).
>
> Essentially something like this:
>
> Chan
>      |
>      ------------------------------------
>      |    |    |    |            |
> CTV(A) CTV(B) CTV(C) CTV(D)      (Optional CPFP Anchor?)
>      | |    |    |
> 1 block 1 block 1 block 1 block
>      | |    |     |
>     A       B      C       D
>
> Where A B C and D are all HTLCs.
>
> Now because of the one-hop indirection, A B C and D can all expand independently. It's also possible for the Channel Operator to do something like:
>
> Chan
>      |
>      -----------------------------------
>      | |    |    |            |
> CTV(A) CTV(B) CTV(C) CTV(D)      (Optional CPFP Anchor?)
>      | |    |    |
> 1 block 1 block 1 block 10 blocks
>      | |    |    |
>     A       B      C      D
>
> To make D have a further out resolution time to prevent the simultaneous-ness issue (trees or a linear-chain rather than total fan-out can also be used but I think it's a bit more confusing for a basic example).
The Lightning HTLCs use absolute timelocks, and the timelocks are pre-arranged by the original sender.
A forwarding node has to ensure that the outgoing HTLC timeout is respected, or else it could lose funds (by having the outgoing HTLC be claimed by outgoing peer hashlock and the incoming HTLC be calimed by the incoming peer timelock).
(We cannot use relative timelocks in the timelock branches of the HTLCs because we are coordinating possibly up to 20 different nodes, and do not want to leak the entire route to any of the intermediate nodes, so everyone has to use the same clock --- the absolute blockheight --- to measure time)
So, if my understanding of your above graph is correct, you are suggesting that HTLC D could have a relative timelock of 10 blocks instead of 1.
But all that means is that if the timelock of D is at height L, then the forwarder has to ensure that the commitment transaction appears onchain no later than height L - 10 (in practice I have to publish it at L - 11 so it propagates to miners who are building L - 10).
If not, the HTLC cannot be published at height L and the timelock cannot be enforced, risking fund loss.
This seems to *tighten* whatever leeway I might have bought by using CTV.
In current C-Lightning, for instance, for a timelock in my favor at height L, I have to broadcast the commitment transaction at time L - 1 so it goes into block L and I can claim it.
Thus, I have the option to publish from now up to L - 1.
With a further delay of 10 on the HTLC tx D, I now only have the option to publish from now up to L - 11, thus I have *less* leeway in when I can publish the commitment tx.
Basically the fund-security of the forwarding node is based on the absolute timelock of every HTLC it offers, so the timelock is an absolute bound on whatever techniques I might use to reduce fees.
> The benefit of trees is that I can do something like:
>
> Chan
>      |
>      --------------------------------------------------------
>      | |    |    |                    |
> CTV(A) CTV(B) CTV(C) CTV(400 HTLC)      (Optional CPFP Anchor?)
>      | |    |    |    |
> 1 block 1 block 1 block 10 blocks (Optional CPFP Anchor?)
>      | |    |    |
>      |      |      |   / ....\
>     A       B      C  | ..... |
>
> Which makes it so that the low-value new HTLCs can be deprioritized fee wise. So that the attack, which occurs during a fee spike, doesn't end up *requiring* substantial fees to be added to the channel to support a burst of HTLCS.
If the HTLCs have a timelock L, then I *need* to publish the HTLCs at timelock L or else the timelock cannot be enforced.
This means I need to publish the big `| ..... |` transaction with 400 HTLCs before timelock L, where L is `min (L) for all 400 HTLCs`.
The attacker can arrange to have the 400 low-value HTLCs have the same timelock L.
So even if the `| ..... |` is a tree of CTVs, I have to publish the entire tree at the same time so that the final HTLCs appear at timelock L and I can reclaim my funds.
If I do not publish, I run the risk that the total fund going to `CTV(400 HTLC)` gets stolen from me by publication of the hashlock on the outgoing and publication of the timelock at the incoming.
Not publishing this due to fee spikes is basically trusting that the next peer is not going to steal the fund by hashlock branch.
And the next peer is an attacker in this attack, so obviously cannot be trusted.
So it seems to me that this is better done by just rate-limiting simultaneous HTLCs, to limit what can be stolen.
A better solution might be to allow only one HTLC at each absolute timelock, and use a single CTV tree, with one leaf for each of the absolute timelocks.
Then I can publish parts of the CTV tree at my leisure, with my only constraint being the absolute timelock of each HTLC.
Chan
|
CTV
|
+------+
| |
CTV HTLC(L = now + 1)
|
+------+
| |
CTV HTLC(L = now + 2)
|
+------+
| |
CTV HTLC(L = now + 3)
|
...
Such a singly-linked list would take up even more absolute block space, incidentally, and makes high-fee spikes more likely.
Regards,
ZmnSCPxj

2023-06-09 13:00:08

- reply

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

2023-06-09 13:00:06

- reply

📅 Original date posted:2020-05-05
📝 Original message:
Good morning ariard and luke-jr
> > Trust-minimization of Bitcoin security model has always relied first and
> > above on running a full-node. This current paradigm may be shifted by LN
> > where fast, affordable, confidential, censorship-resistant payment services
> > may attract a lot of adoption without users running a full-node.
>
> No, it cannot be shifted. This would compromise Bitcoin itself, which for
> security depends on the assumption that a supermajority of the economy is
> verifying their incoming transactions using their own full node.
>
> The past few years has seen severe regressions in this area, to the point
> where Bitcoin's future seems quite bleak. Without serious improvements to the
> full node ratio, Bitcoin is likely to fail.
>
> Therefore, all efforts to improve the "full node-less" experience are harmful,
> and should be actively avoided. BIP 157 improves privacy of fn-less usage,
> while providing no real benefits to full node users (compared to more
> efficient protocols like Stratum/Electrum).
>
> For this reason, myself and a few others oppose merging support for BIP 157 in
> Core.
BIP 157 can be implemented as a separate daemon that processes the blocks downloaded by an attached `bitcoind`, i.e. what Wasabi does.
The intention, as I understood it, of putting BIP157 directly into bitcoind was to essentially force all `bitcoind` users to possibly service BIP157 clients, in the hope that a BIP157 client can contact any arbitrary fullnode to get BIP157 service.
This is supposed to improve to the situation relative to e.g. Electrum, where there are far fewer Electrum servers than fullnodes.
Of course, as ariard computes, deploying BIP157 could lead to an effective DDoS on the fullnode network if a large number of BIP157 clients arise.
Though maybe this will not occur very fast? We hope?
It seems to me that the thing that *could* be done would be to have watchtowers provide light-client services, since that seems to be the major business model of watchtowers, as suggested by ariard as well.
This is still less than ideal, but maybe is better than nothing.
Regards,
ZmnSCPxj

2023-06-09 12:59:55

- reply

📅 Original date posted:2020-04-24
📝 Original message:
Good morning Laolu, and list,
> (this may be kind of off-topic, more about DLC deployment than PTLCs
> themselves)
>
> From my PoV, new technologies aren't what has held back DLC deployment to
> this date since the paper was originally released. Tadge has had working
> code than can be deployed today for some time now, and other parties like
> DG-Lab have created full-fledge demos with the system working end to end.
> Instead, the real impediment has been the bootstrapping of the oracles
> which the scheme critically depends upon.
>
> Without oracles, none of it really works. Although, it's also the case that
> there're measures to prevent the oracles from equivocating (reporting two
> conflicting prices/events for a particular instance), bootstrapping a new
> oracle still requires a very high degree of trust as they can lie or report
> incorrect data. As a result, actually deploying an oracle for a system like
> this is tricky business, as it's a trusted centralized entity, so it will
> run into all the normal meatspace/legal/operational risk that any trusted
> centralized service would encounter.
>
> Earlier today, Coinbase announced that they were releasing a new price
> oracle for the ETH ecosystem [1]. This caught my attention as one can
> imagine, that it would be even simpler for them to deploy a DLC oracle which
> exports an API to obtain signed prices/events. As an existing large company
> in the space (depending on who you talk to), they're a trusted entity, which
> has earned a good reputation over the years (solving this
> bootstrapping/trust issue). If they do eventually grow the service to also
> encompass this use case, then it enables a number of possibilities, as
> there's still a ton of value in just base DLC-specific channels (or one off
> contracts), without all the fancy barrier escrow scriptless scipts swappy
> swap swap stuff.
Going even further off-topic, in theory the defiads project could help with this.
An oracle service could advertise itself on defiads, using a timelocked fidelity bond to back up the advertisement, which is a claim-to-truth (that they are trustworthy etc etc).
Equivocation protection in DLC is done by forcing the revelation of a scalar behind a point.
As the defiads fidelity bond also includes a point (where signing with the scalar is needed to reclaim the bond after the timelock period ends), then we can force revelation of the private key protecting the fidelity bond in case of equivocation.
Unfortunately, the oracle can simply outright lie, without equivocating between different segments of its users.
Regards,
ZmnSCPxj
>
> -- Laolu
>
> [1]: https://blog.coinbase.com/introducing-the-coinbase-price-oracle-6d1ee22c7068
>
> On Thu, Apr 23, 2020 at 7:52 AM Nadav Kohen <nadav at suredbits.com> wrote:
>
> > Hi Laolu,
> >
> > Thanks for the response :)
> >
> > I agree that some more framing probably would have been good to have in my update.
> >
> > First, I want to clarify that my intention is not to implement a PTLC-based lightning network on top of ECDSA adaptor signatures, as I do believe that using Schnorr will be superior, but rather I wish to get some PoC sandbox with which to start implementing and testing out the long list of currently theoretical proposals surrounding PTLCs, most of which are implementation agnostic (to a degree anyway). I think it would be super beneficial to have more fleshed out with respect to what some challenges of a Payment Point LN are going to be than we understand now, before Schnorr is implemented and it is time to commit to some PTLC scheme for real.
> >
> > Second, I agree that I've probably understated somewhat the changes that will be needed in most implementations as I was mostly thinking about what would need to change in the BOLTs, which does actually seem relatively minimal (although as you mention, these minimal changes to the BOLTs do trigger large changes in many implementations). Also, good point on how BOLT 11 (invoicing) will have to be altered as well, must've slipped my mind.
> >
> > Best,
> > Nadav
> >
> > On Wed, Apr 22, 2020 at 8:17 PM Olaoluwa Osuntokun <laolu32 at gmail.com> wrote:
> >
> > > Hi Nadav,
> > >
> > > Thanks for the updates! Super cool to see this concept continue to evolve
> > > and integrate new technologies as they pop up.
> > >
> > > > I believe this would only require a few changes to existing nodes:
> > >
> > > Rather than a "few changes", this would to date be the largest network-level
> > > update undertaken to the Lightning Network thus far. In the past, we rolled
> > > out the new onion blob format (which enables changes like this), but none of
> > > the intermediate nodes actually need to modify their behavior. New payment
> > > types like MPP+AMP only needed the _end points_ to update making this an
> > > end-to-end update that has been rolled out so far in a de-synchronized
> > > manner.
> > >
> > > Re-phrasing deploying this requires changes to: the core channel state
> > > machine (the protocol we use to make commitment updates), HTLC scripts,
> > > on-chain HTLC handling and resolution, path finding algorithms (to only see
> > > out the new PTLC-enabled nodes), invoice changes and onion blob processing.
> > > I'd caution against underestimating how long all of this will take in
> > > practice, and the degree of synchronization required to pull it all off
> > > properly.
> > >
> > > For a few years now the question we've all been pondering is: do we wait for
> > > scnhorr to roll out multi-hop locks, or just use the latest ECDSA based
> > > technique? As dual deployment is compatible (we can make the onion blobs for
> > > both types the same), a path has always existed to first roll out with the
> > > latest ECDSA based technique then follow up later to roll out the schnorr
> > > version as well. However there's also a risk here as depending on how
> > > quickly things can be rolled out, schnorr may become available
> > > mid-development, which would possibly cause us to reconsider the ECDSA path
> > > and have the network purely use scnhorr to make things nice and uniform.
> > >
> > > Zooming out for a bit, the solution space of "how channels can look post
> > > scriptless-scripts + taproot" is rather large [1], and the addition of this
> > > new technique allows for an even larger set of deployment possibilities.
> > > This latest ECDSA variant is much simpler than the prior ones (which had a
> > > few rounds of more involved ZKPs), but since it still uses OP_CMS, it can't
> > > be used to modify the funding output.
> > >
> > > [1]: https://lists.linuxfoundation.org/pipermail/lightning-dev/2019-December/002375.html
> > >
> > > -- Laolu
> > >
> > > On Wed, Apr 22, 2020 at 8:13 AM Nadav Kohen <nadav at suredbits.com> wrote:
> > >
> > > > Hello all,
> > > >
> > > > I'd like to give an update on the current state of thinking and coding surrounding replacing Hash-TimeLock Contracts (HTLCs) with Point-TimeLock Contracts (PTLCs) (aka Payment Hashes -> Payment Points) in hopes of sparking interest, discussion, development, etc.
> > > >
> > > > We Want Payment Points!
> > > > -----------------------
> > > >
> > > > Using point-locks (in PTLCs) instead of hash-locks (in HTLCs) for lightning payments is an all around improvement. HTLCs require the use of the same hash across payment routes (barring fancy ZKPs which are inferior to PTLCs) while PTLCs allow for payment de-correlation along routes. For an introduction to the topic, see https://suredbits.com/payment-points-part-1/.
> > > >
> > > > In addition to improving privacy in this way and protecting against wormhole attacks, PTLC-based lightning channels open the door to a large variety of interesting applications that cannot be accomplished with HTLCs:
> > > >
> > > > Stuckless (retry-able) Payments with proof of payment (https://suredbits.com/payment-points-part-2-stuckless-payments/)
> > > >
> > > > Escrow contracts over Lightning (https://suredbits.com/payment-points-part-3-escrow-contracts/)
> > > >
> > > > High/DLOG AMP (https://docs.google.com/presentation/d/15l4h2_zEY4zXC6n1NqsImcjgA0fovl_lkgkKu1O3QT0/edit#slide=id.g64c15419e7_0_40)
> > > >
> > > > Stuckless + AMP (an improvement on Boomerang) (https://lists.linuxfoundation.org/pipermail/lightning-dev/2019-October/002239.html)
> > > >
> > > > Pay-for-signature (https://suredbits.com/payment-points-part-4-selling-signatures/)
> > > >
> > > > Pay-for-commitment (https://lists.linuxfoundation.org/pipermail/lightning-dev/2019-September/002166.html)
> > > >
> > > > Monotonic access structures on payment completion (https://suredbits.com/payment-points-monotone-access-structures/)
> > > >
> > > > Ideal Barrier Escrow Implementation (https://suredbits.com/payment-points-implementing-barrier-escrows/)
> > > >
> > > > And allowing for Barrier Escrows, we can even have
> > > >
> > > > Atomic multi-payment setup (https://suredbits.com/payment-points-and-barrier-escrows/)
> > > >
> > > > Lightning Discreet Log Contract (https://suredbits.com/discreet-log-contracts-on-lightning-network/)
> > > >
> > > > Atomic multi-payment update (https://suredbits.com/updating-and-transferring-lightning-payments/)
> > > >
> > > > Lightning Discreet Log Contract Novation/Transfer (https://suredbits.com/transferring-lightning-dlcs/)
> > > >
> > > > There are likely even more things that can be done with Payment Points so make sure to respond if I've missed any known ones.
> > > >
> > > > How Do We Get Payment Points?
> > > > -----------------------------
> > > >
> > > > Eventually, once we have Taproot, we can use 2p-Schnorr adaptor signatures in Lightning channels. For a detailed thread by ZmnSCPxj, see here https://lists.linuxfoundation.org/pipermail/lightning-dev/2019-December/002375.html
> > > >
> > > > In the meantime, Lloyd has written about a way to do 1p-ECDSA adaptor sigs (https://github.com/LLFourn/one-time-VES) which can be paired with OP_CHECKMULTISIG to allows us to execute PTLCs on Bitcoin today!
> > > >
> > > > Nickler has implemented this in a branch of secp256k1 (https://github.com/jonasnick/secp256k1/pull/14) and I have implemented it in Bouncy Castle in Bitcoin-S with some testing against this branch (https://github.com/nkohen/bitcoin-s-core/tree/bouncy-adaptor). Do note that as nickler states on his PR, "IT IS EXTREMELY DANGEROUS AND RECKLESS TO USE THIS MODULE IN PRODUCTION. DON'T!"
> > > >
> > > > A demo of an on-chain PTLC I executed using nickler's implementation on the backend + bitcoin-s can be seen here https://youtu.be/w9o4v7Idjno
> > > >
> > > > And waxwing did a lovely write-up about the crypto itself https://joinmarket.me/blog/blog/schnorrless-scriptless-scripts/
> > > >
> > > > I would be very interested in having a fork of (at least) one lightning implementation (or Rust Lightning) to be a proof of concept ECDSA-PTLC node with which we can test and play with the plethora of PTLC-based proposals above.
> > > >
> > > > I believe this would only require a few changes to existing nodes:
> > > >
> > > > 1) update_add_ptlc will have a 32 byte x-coordinate (of a point) rather than a 32 byte hash. Additionally the onion's hop_data will contain a 32 byte scalar tweak for each hop. As per [link multi-hop locks]. The last hop_data will instead include a 32 byte scalar equal to the sum of all tweaks.
> > > >
> > > > 2) commitment_signed will have 162 byte adaptor ptlc_signatures rather than valid (71/72 byte) ECDSA signatures on PTLC-success transactions.
> > > >
> > > > 3) The in-flight outputs on the commitment transaction itself become a little simpler as we no longer need to explicitly check the payment pre-image against a hash. Instead, delete all instances of "OP_HASH160 <RIPEMD160(payment_hash)> OP_EQUALVERIFY" in the scripts (leaving the rest the same) and require no pre-image in the witness, only a valid signature. The pre-image check is implicitly enforced by the <remoteptlc_sig> witness since only an adaptor signature was provided by remote so that the payment pre-image is required to create the valid signature (from which the pre-image can be then deduced by comparing adaptor and valid signatures).
> > > >
> > > > If I've missed any other changes that need to happen, do respond with them!
> > > >
> > > > I hope that as a community we can work towards having a PTLC-based Lightning Network that is safe and stable as soon as possible, and so I encourage further thinking, development and expirementation with PTLCs now so that when Taproot is finally at our disposal we can cleanly start moving towards a more ideal Lightning :)
> > > >
> > > > Best,
> > > > Nadav
> > > > _______________________________________________
> > > > Lightning-dev mailing list
> > > > Lightning-dev at lists.linuxfoundation.org
> > > > https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev