SomberNight [ARCHIVE] / is on Nostr

⚠️ This account is not associated with a real person. It's an archival account for mailing list messages.
🗓️ Active from 2018-11-08 to 2023-05-09
💬 Posted a total of 10 messages
📚 Participated in the following categories: bitcoin-dev, Lightning-dev
🔇 Please do not DM this user as it's used for archive purposes only.

Last Notes

2023-08-21 09:48:48

- reply

📅 Original date posted:2023-08-17
🗒️ Summary of this message: Mobile wallet providers are unlikely to cheat because the mobile wallet can check for any attempts and the provider risks reputation loss. A peer backup solution could be implemented by any node, allowing users to store backups with them. The reputation argument may not hold up for random nodes, but for hardcoded nodes like ACINQ, it is sufficient. The idea of symmetric resumable channels is also proposed.
📝 Original message:
Hi Bastien,
> I don't think this is an attack wallet providers can reasonably attempt.
> The mobile wallet can check at every connection that the provider isn't
> trying to cheat, and the provider doesn't have any way of knowing when
> the mobile wallet has lost data: it would thus be a very risky move to
> try to cheat, because it is very unlikely to succeed and will result in
> reputation loss for the provider.
It would be nice to have a peer backup solution that can be provided by
~any node, and reasonably used without trust by ~any node [0]. To be more
precise (and practical), imagine providing the backup "service" by
default if you run a public forwarding node. E.g. if Alice runs eclair
on their server and have some public channels, the default config of
eclair could result in Alice signalling the "backup-provider" feature
bit. Then, if Bob uses a phone-wallet, and opens to Alice (chosen by Bob
arbitrarily), Bob could store their backups with her.
Note that the "reputation loss" argument does not hold up that well if
you let Bob connect to arbitrary nodes. Something stronger, such as
actual confiscation of funds via Thomas' idea seems more applicable.
Afterall, what does a random node have to lose if they tried to replay
an old backup? You said in another email Phoenix atm simply ignores the
stale backup. I wonder, does the client happily keep using the channel
after a reconnect? If so, what is there to lose by attempting to replay
old states? Random nodes don't really have an easy concept of
reputation.
Obviously the ACINQ node is not random - being hardcoded in your case
it is anything but. Of course, in the case of an LSP/wallet combo
such as Phoenix, the reputation argument is sufficient, I agree.
-----
[0]: I think the whole backup provicer idea could be made symmetric.
I had previously thought that it is inherently asymmetric but after
some more thought I think I was wrong:
Symmetric resumable channels
----------------------------
Alice and Bob could have a channel where they both provide state backups
to each other. Regarding who goes first in channel_reestablish, we need
an extra preliminary round where both Alice and Bob commit to what they
will send in channel_reestablish:
Round 1:
1. Alice sends hashA = hash(bobs_backup, nonceA)
2. Bob sends hashB = hash(alices_backup, nonceB)
Alice persists hashB to disk upon receiving it, and enforces that even
if there is a disconnection, Bob cannot arbitrarily send a different
commitment next time. (if the channel gets reestablished fully and
Alice sends a new backup to Bob, the stored hashB can be cleared)
Round 2:
3. Alice sends channel_reestablish containing bobs_backup, and nonceA
4. Bob sends channel_reestablish containing alices_backup, and nonceB
Alice checks that the commitment received from Bob in round1 matches
what was received in round2.
Regarding the opening post OP_CHECKSIGFROMSTACK on-chain enforcement,
that can be made symmetric as well! The channel funding output script
needs one taproot branch each for both Alice and Bob lying. The protocol
needs to be tweaked a bit so as to allow a party to legitimately admit
having lost state and commit to the hash of that in round1, and then
reveal they lost state in round2 (e.g. send null data). In which case
the other party would not be able to use the fraud proof taproot branch.
Though note that user-error and manual copying/restoring of DBs could
lead to catastrophic failure with the on-chain enforcement:
if you restore an old db and launch your client, the client won't know
it is running an old state and happily participate in the two round
dance, giving a fraud proof to the counterparty in the process.
Regards,
ghost43

2023-06-20 23:25:30

- reply

📅 Original date posted:2023-06-20
🗒️ Summary of this message: A proposal for Lightning Network payments involves potentially three entities, including a swap service provider, and requires updates to existing software used by senders. A submarine swap scenario is used as an example.
📝 Original message:
Hi Thomas, Bastien, and list,
One point I would like to stress for this idea, is that there are potentially three different entities at play in these payments.
This might not be obvious at first glance especially for the submarine swap example, where people expect just two entities: the user ("customer") and the server ("swap provider"). Bastien already hinted at this, but I just want to make it very explicit that this is a (or perhaps *the*) use case here.
> First of all, I'd like to highlight something that may not be obvious
> from your email, and is actually pretty important: your proposal
> requires *senders* to be aware that the payment will lead to a channel
> creation (or a splice) on the *receiver* end. In particular, it requires
> all existing software used by senders to be updated.
In particular, for the submarine swap scenario, consider Alice, a new user with a freshly installed wallet, who generates an invoice as they want to receive some money onchain; and Bob, who wants to pay that invoice via Lightning. There are three entities: Alice, a swap service provider (server), and Bob. Only Alice knows about the swap server being there.
Alice needs client-side logic for doing a swap; and Bob needs to implement Thomas' proposal (or equivalent), i.e. parsing an invoice that can convey two payment hashes and one corresponding amount each, one pair being used as a "prepayment".
Using a swap service, Bob could pay Alice, so that Bob pays on Lightning, and Alice receives onchain:
- Alice generates a preimage and calculates its hash RHASH1, for the actual ("large") amount1 Alice wants to receive
- Alice contacts the swap server via e.g. HTTP, providing RHASH1 and amount1
- the swap server generates another preimages and its hash RHASH2, for the small prepayment amount2
- the swap server generates a lightning invoice, and puts (RHASH1, amount1) and (RHASH2, amount2) in it, and sends it back to Alice
- Alice checks the lightning invoice, e.g. verifies that it includes the expected amounts and RHASH1
- Alice now gives the invoice to Bob, using some side-channel, as typical
- Bob does not need to know that the nodeid signing the ln invoice does not belong to Alice, etc
- Bob sees that the invoice contains two payment hashes and amounts, and sends HTLCs to cover both
- the HTLCs arrive at the swap server, who holds them and waits until it sees HTLCs with enough offered money for both the prepayment (RHASH2) and the main payment (RHASH1)
- the server has the preimage for RHASH2 (but not RHASH1), so it now fulfills the HTLCs for the prepayment
- the server creates a swap funding tx onchain paying to a locking script redeemable by the preimage of RHASH1 - the mining fees for this and the service fee has already been paid by the fulfilled HTLCs for RHASH2
- Alice sees the swap funding tx onchain, and waits until it gets mined. Alice also validates that it is the expected script, and the timeout for the refund path is not too short, etc.
- Alice broadcasts a claim tx spending the funding tx output using the preimage for RHASH1
- the server fulfills the still pending HTLCs for RHASH1 using this preimage
Note that Bob is a simple lightning wallet, with the only added assumption that his wallet is able to parse/pay this new type of LN invoice that contains two hashes. All the security checks and swap logic is only implemented on Alice's side. A clear drawback though is that Bob, paying lightning, expects the payment to go through fast, but will end up waiting for onchain txs getting mined (which he does not know or need to know about).
Also note that instead of this special bolt11 invoice (or maybe bolt12 offer), Alice could create a bip21 URI instead, containing both an onchain address and the lightning invoice. This way, Alice would still receive onchain, but now Bob has the choice of either paying onchain or via lightning.
---
Besides swaps, the other clear use case is JIT channels. Analogous to the above swap example, Alice could negotiate with the service provider to have a JIT channel opened to her, and the HTLC forwarded using that. Alice can wait for the channel funding to be mined before releasing the preimage for the main payment (RHASH1) by fulfilling the HTLC offchain.
Bob is completely agnostic to what happens between the service provider and Alice. The only thing visible is the long time it takes for the HTLC to get fulfilled. (though if Alice opted-in not to wait for confirmations and trust the server, the delay could be removed)
If Alice waits for confirmations, in both the swap and the JIT channel scenarios, the server is only trusted with the prepayment amount.
Regards,
ghost43 / SomberNight
------- Original Message -------
On Thursday, June 15th, 2023 at 09:01, Bastien TEINTURIER <bastien at acinq.fr> wrote:
> Hi Thomas,
>
> First of all, I'd like to highlight something that may not be obvious
> from your email, and is actually pretty important: your proposal
> requires *senders* to be aware that the payment will lead to a channel
> creation (or a splice) on the *receiver* end. In particular, it requires
> all existing software used by senders to be updated. For this reason, I
> think extending Bolt 12 (which requires new sender code anyway) makes
> more sense than updating Bolt 11.
>
> I see only three strategies to provide JIT liquidity (by opening a new
> channel or making a splice, I'll only use the open channel case below
> for simplicity):
>
> 1. Ask receiver for the preimage and a fee, then open a channel and
> push the HTLC amount minus the fee
> 2. Open a channel, then forward the HTLC amount minus a fee
> 3. Pre-pay fee, then open a channel and forward the whole HTLC amount
> on that channel
>
> What is currently deployed on the network is 1) and 2), while you're
> proposing 3). Both 1) and 2) have the advantages that the sender doesn't
> need to be aware that JIT liquidity is happening, and doesn't need to do
> anything special for that payment, which is the main reason those
> strategies were chosen.
>
> If all you're concerned about is trust and regulation, solution 2) works
> fine as long as the mempool isn't empty: if the user doesn't release the
> preimage after you've opened the channel, you should just blacklist that
> channel, reject payments made to it, and double-spend it whenever you
> have another on-chain transaction to make (and use 1 sat/byte for JIT
> liquidity transactions). Even if the mempool is empty, if your LSP has
> transactions to make at every block, it's likely that it will succeed
> at double-spending the faulty channel, and thus won't lose anything.
>
> But I agree that this only works when coupled with 0-conf. If we're not
> using 0-conf anymore, pre-paying fees would make more sense. But we will
> likely keep on using 0-conf at least until Bolt 12 is deployed, so it
> seems more reasonable to include this new feature in Bolt 12 rather than
> Bolt 11, since all implementations are actively working on this?
>
> Cheers,
> Bastien
>
> Le jeu. 15 juin 2023 à 10:52, Thomas Voegtlin <thomasv at electrum.org> a écrit :
>
> > Hello Matt,
> >
> > I think it is not too late to add a new feature to BOLT-11. In any
> > case, the belief that BOLT-11 is ossified should not be a reason to
> > make interactive something that fundamentally does not require more
> > interactivity than what BOLT-11 already offers. Technical decisions
> > should be dictated by technical needs, and I am a minimalist when it
> > comes to adding new messages to protocols.
> >
> > I believe that two major implementations have an incentive to support
> > this proposal (although I cannot speak for them):
> > - Lightning Labs could potentially offer their Loop service to
> > non-LND users.
> > - ACINQ would be able to open channels to Phoenix users without
> > requesting the preimage first. This would put them on the safe side
> > of the upcoming MICA regulation; I cannot emphasize enough how
> > important that is.
> >
> > In addition, you could certainly decide to support that feature in
> > LDK, and I can speak for Electrum :-)
> >
> > It is the first time I suggest a change to the Lightning protocol, and
> > what I am proposing is really a tiny change. All we need is a new
> > invoice feature, that describes the prepayment of a fee using a
> > different preimage. This feature does not need to be set on all
> > invoices, and it could be made optional during a transition period.
> >
> > Here is how that feature could possibly made optional:
> > - a new feature bit is defined, BUNDLE_PREPAYMENT
> > - two extra fields are defined: prepayment_amount, prepayment_hash
> > - if the sender does not support BUNDLE_PREPAYMENT and the feature is
> > optional, it ignores the new fields
> > - if the sender support BUNDLE_PREPAYMENT:
> > - sender sends (amount - prepayment_amount) with payment_hash
> > - sender sends prepayment_amount with prepayment_hash
> >
> > The decision to make this feature required or optional remains with
> > the service provider. I can see how submarine swap providers who are
> > already exposed to the mining fee griefing attack could decide to make
> > it optional for a transition period.
> >
> > cheers,
> > Thomas
> >
> >
> > Regarding your question (a) about the distinction between splice-out
> > and submarine swaps: Submarine swaps make it possible to add receiving
> > capacity to a channel.
> >
> >
> >
> >
> > On 14.06.23 19:28, Matt Corallo wrote:
> > > I think the ship has probably sailed on getting any kind of new interoperable change in to BOLT-11.
> > >
> > > We already can't get amount-less BOLT-11 invoices broadly supported, rolling out yet another new incompatible version of BOLT-11 and expecting the entire ecosystem to support it doesn't seem all that likely.
> > >
> > > If we're working towards specifying some "standard" way of doing swaps, (a) I'd be curious to understand why the need isn't obviated by splice-out, and (b) why it shouldn't be built on OMs so you can do it more privately.
> > >
> > > Matt
> > >
> > > On 6/13/23 1:10 AM, Thomas Voegtlin wrote:
> > >> Good morning list,
> > >>
> > >> I would like to propose an extension to BOLT-11, where an invoice can contain two bundled payments, with distinct preimages and amounts.
> > >>
> > >> The use case is for services that require the prepayment of a mining fee in order for a non-custodian exchange to take place:
> > >> - Submarine swaps
> > >> - JIT channels
> > >>
> > >> In both cases, the service provider receives a HTLC for which they do not have the preimage, have to send funds on-chain (to the channel or submarine swap funding address), and wait for the client to reveal the preimage when they claim the payment. Because there is no guarantee that the client will actually claim the payment, the service providers need to ask prepayment of mining fees.
> > >>
> > >> In the case of submarine swaps, services that use dedicated client software, such as Loop by Lightning Labs, can ask for a prepayment, because their software can handle it (this is called "no show penalty" on the Loop website). However, competitors who do require a dedicated wallet, not such as the Boltz exchange, cannot do that. Their website shows an invoice to the user, whose wallet that is agnostic about the swap, and it would be unpractical for them to show two invoices to be paid simultaneously. This creates a situation where Boltz is vulnerable to DoS attacks, where the attacker forces them to pay on-chain fees.
> > >>
> > >> In the case of JIT channels, providers who want to protect themselves against this mining fee attack need to ask the preimage of the main payment before they open the channel. I believe this is what Phoenix does (although their pay-to-open service is not open-source, so I cannot really check). The issue is that a service that asks for the preimage first becomes custodian. From a legal perspective, it does not matter whether they open the channel immediately after receiving the preimage, the ordering of events makes their service custodian. In Europe, such a service will fall within the European MICA regulation. Competitors who refuse to offer custodian services, such as Electrum, are excluded from that game.
> > >>
> > >> In order to solve that, it would be beneficial to bundle the prepayment and the main payment in the same BOLT-11 invoice.
> > >>
> > >> The semantics of bundled payments is as follows:
> > >> - 1. the BOLT-11 invoice contains two preimages and two amounts: prepayment and main payment.
> > >> - 2. the receiver should wait until all the HTLCs of both payments have arrived, before they fulfill the HTLCs of the pre-payment. If the main payment does not arrive, they should fail the pre-payment with a MPP timeout.
> > >> - 3. once the HTLCs of both payments have arrived, the receiver fulfills the HTLCs of the prepayment, and they broadcast their on-chain transaction. Note that the main payment can still fail if the sender never reveal the preimage of the main payment.
> > >>
> > >> Of course, nothing in my proposal prevents the service provider from stealing the pre-payment, but that is already the case today.
> > >>
> > >> I believe this proposal would level the field in terms of competition between lightning service providers. Currently, you need to use a dedicated client in order to use Loop, and competitors who do not have an established user base running a dedicated client are exposed to the mining fee attack. I also believe that ACINQ would benefit from this, because it would make it possible for them to make their pay-to-open service fully non-custodian. My understanding is that in its current form, the 'pay-to-open' service used by Phoenix will fall into the scope of the European MICA regulation, which they should consider as a serious issue.
> > >>
> > >> Finally, I believe that such a change should be implemented in BOLT-11, and not using BOLT-12 or onion messages. Indeed, my proposal does not require the exchange of new messages. Some of the initial feedback I received was that this is a use case for BOLT-12 or OM, but I think that this is making things unnecessarily complicated. We should not add new messages when things can be done in a non-interactive way.
> > >>
> > >> Cheers,
> > >> ThomasV
> > >> _______________________________________________
> > >> Lightning-dev mailing list
> > >> Lightning-dev at lists.linuxfoundation.org
> > >> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
> >
> > --
> > Electrum Technologies GmbH / Paul-Lincke-Ufer 8d / 10999 Berlin / Germany
> > Sitz, Registergericht: Berlin, Amtsgericht Charlottenburg, HRB 164636
> > Geschäftsführer: Thomas Voegtlin
> > _______________________________________________
> > Lightning-dev mailing list
> > Lightning-dev at lists.linuxfoundation.org
> > https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev

2023-06-19 17:42:33

- reply

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

2023-06-09 13:13:23

- reply

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

2023-06-09 13:08:53

- reply

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

2023-06-09 13:07:45

- reply

📅 Original date posted:2022-12-13
📝 Original message:
Hi Ben,
This is handled earlier than update_fail_htlc: when the recipient sees the update_add_htlc, some sanity checks will fail and it won't commit it to the commitment tx.
See here:
https://github.com/lightning/bolts/blame/a0bbe47b0278b4f152dbaa4f5fab2562413a217c/02-peer-protocol.md#L1036
> 1. type: 128 (`update_add_htlc`)
> [...]
> A receiving node:
> [...]
> - receiving an `amount_msat` that the sending node cannot afford at the current `feerate_per_kw` (while maintaining its channel reserve and any `to_local_anchor` and `to_remote_anchor` costs):
> - SHOULD send a `warning` and close the connection, or send an
`error` and fail the channel.
If the recipient decides to simply close the transport connection, the update_add_htlc message is forgotten (due to the rules of how channel_reestablish works), and the channel is back to a usable state.
ghost43
------- Original Message -------
On Tuesday, December 13th, 2022 at 2:51 PM, Benjamin Weintraub via Lightning-dev <lightning-dev at lists.linuxfoundation.org> wrote:
> Hi list,
>
>
>
> I have a question about how update_fail_htlcs are handled. Consider this scenario: a node, potentially adversarial, forwards an HTLC along a channel that does not have the funds to support a payment of that size. How does the recipient of the HTLC respond?
>
>
>
> I see this line in BOLT #2:
>
> “until the corresponding HTLC is irrevocably committed in both sides' commitment transactions: MUST NOT send an `update_fulfill_htlc`, `update_fail_htlc`, or `update_fail_malformed_htlc`"
>
>
>
> But this seems confusing to me in the context of the scenario I suggested. Is it saying that even though the channel cannot support the payment, the nodes still need to commit to it?
>
>
>
> I assume that this interpretation is not correct, but then when is it okay for a node to send an update_fail_htlc? Immediately upon receiving an invalid transaction?
>
>
>
> Any insight you could provide would be great.
>
>
>
> Thanks in advance,
>
> Ben

2023-06-09 13:03:45

- reply

📅 Original date posted:2021-09-20
📝 Original message:
Good morning ZmnSCPxj,
> > 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`).
The OP_RETURN containing the encrypted counterparty node id
is only an option, ideally it should not be required.
Also, your proposal needs a counter too, to avoid reuse between multiple
channels with the same counterparty. This counter is actually quite
problematic as users should be able to open new channels after
restoring from seed, which means they need to be able to figure out
the last value of the counter reliably, which seems potentially
problematic, so actually this might have to be a random nonce that is
wide enough to make collisions unlikely... (potentially taking up
valuable blockchain space in the OP_RETURN)
Regards,
SomberNight

2023-06-09 13:03:44

- reply

📅 Original date posted:2021-09-17
📝 Original message:
Hi all,
TL;DR: an approach is described how to derive channel keys
deterministically that allows certain forms of recovery from just
a seed, that works today. This approach however will no longer work
with e.g. MuSig key aggregation in the future. An idea for a proposal
is given how the channel-open flow (e.g. as part of channel v2) could be
changed to make a similar approach work independent of key aggregation.
-----
While implementing anchor output support in Electrum, we have realised
one difficulty is to do with the remote-force-close case where the
to_remote output is no longer a simple p2wpkh.
Currently, pre-anchor-support, Electrum sets option_static_remotekey
to required (feature bit 12), and we restrict lightning usage to wallets
that derive p2wpkh addresses, and payment_basepoint is set
to a bip32-derived pubkey that corresponds to a wallet address.
Hence, if a user were to restore from seed words, and their channel
counterparty force closed their channel, the to_remote output of the
broadcast commitment tx would directly pay to the user's wallet.
That is, in many typical scenarios, funds are not lost when restoring
from seed.
(Also, if we are the channel-funder/opener, it is easy to find the
funding transaction, just by testing txs in the wallet history.
Further, for the cases we are the channel-funder/opener,
there is a setting to put an OP_RETURN in the funding tx, which stores
the nodeid of the counterparty, allowing us to identify who to contact
to get the channel closed.
Also, we are (ab)using dataloss_protect to ask the remote
to force-close when restoring from seed, so the user does not even have
to wait for an arbitrarily long time.)
With anchors, the to_remote is now a p2wsh that involves a CSV,
and we cannot easily make this script correspond to a wallet address,
i.e. we lose the property that the remote-force-close pays directly
to a wallet address.
So, the problem we would like to solve, is:
- having seed words
- having access to blockchain data
- somehow having identified our channel counterparties (node IDs),
and our channels with them (funding outpoints)
- and assuming we can get the remote to do a force-close
--> we would like to be able to spend the to_remote output
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.
2) Or, we could derive a new bip32 chain/sequence of pubkeys
used as payment_basepoint for channels, and watch these p2wsh scripts,
with a gap limit.
Particularly the gap limit part makes this undesirable though
(just consider having more than "gap limit" channels open and restoring
from seed).
Instead, it seems desirable to see whether we can extract some entropy
from the blockchain, and use that as a nonce to be combined with a
static private secret derived from our seed.
We could extract data either from the funding tx, or from the
remote-commitment-transaction that spent the funding output.
3) We exploit the fact that the funding output uses a
2of2 OP_CHECKMULTISIG script composed of the funding pubkeys of
each party. The funding pubkey itself can be used as a nonce, and
it can be recovered from the witness of the commitment tx.
The privkey for payment_basepoint can then be derived as e.g.
hash(bip32_derive(seed, HARDCODED_PATH) + funding_pubkey).
In fact (3) is not novel at all: eclair has been deriving
all their channel keys like this [0] for some time, from
a static seed-based secret combined with the funding_pubkey as nonce,
and generating the funding_privkey from ~os.urandom.
Electrum will likely use (3) at least for the payment_basepoint,
as part of adapting to anchors.
-----
Note that the idea (3) relies on recovering the funding_pubkey from
the witness of the spending transaction, which will break in the future
if the funding script is changed to e.g. a p2tr that uses musig.
Crucially, note that all the approach needs is some blockchain-visible
nonce that is already known at the time we need to construct the
open_channel message (as we want to be able to derive some of the keys
that are sent as part of the open_channel message
(e.g. payment_basepoint) from it).
As long as the funding output uses a 2of2 OP_CHECKMULTISIG,
the local funding_pubkey fits the bill.
Note that irrespective of any restrictions on the script used in
the funding output, we could use the funding scriptPubKey/address as
the nonce, if the open_channel/accept_channel messages were
split into two.
For example, instead of the single round of open_channel/accept_channel,
there could be two rounds:
- an open_channel_part1, where the peers exchange only
the funding_pubkey (and the other non-pubkey fields), and
- an open_channel_part2, where the rest of the pubkeys are sent
This way the peers would learn what the funding address would be after
the first round finishes, and could potentially use that to derive
their other channel keys (needed for round 2).
So, to arrive at my point, I would like to ask whether people think
such a change - or something similar - might be useful, and if so,
whether it could/should be incorporated to the current
channel establishment v2 proposal [1].
If there is agreement that this would be useful, a spec change
would be most useful before changing the 2of2 multisig script.
Regards,
ghost43 (SomberNight)
[0]: https://github.com/ACINQ/eclair/pull/1097
[1]: https://github.com/lightningnetwork/lightning-rfc/pull/851

2023-06-09 13:01:22

- reply

📅 Original date posted:2020-10-19
📝 Original message:
Hi all,
Recently I've been looking at refactoring some of the watchtower code in Electrum, and not wanting to have to do it again soon, was also considering how it should be adapted to option_anchor_outputs.
This made me realise there does not seem to be a way for a watchtower to trustlessly sweep HTLCs if option_anchor_outputs is enabled for the channel (unlike without the option).
Specifically, consider the scenario where the breacher also broadcasted second-stage HTLC transactions (HTLC-Timeout or HTLC-Success) [0], along with some old commitment tx. The watchtower would have to react within the relative timelock (CSV) and spend the output using the branch that requires revocationpubkey. Note that the watchtower cannot be given (the privkey for) revocationpubkey as then it would be able to spend the output to any address (such as their own).
Without option_anchor_outputs, the Electrum watchtower is currently given a complete pre-signed transaction that spends the (revoked) second-stage output to a user wallet address whenever the commitment tx is updated off-chain.
However, with option_anchor_outputs enabled, the txid of the second-stage HTLC tx can no longer be predicted (due to the use of SIGHASH_SINGLE|SIGHASH_ANYONECANPAY for the signature in the input).
As all current sighash flags commit to the outpoint being spent (see item 4 "outpoint" in bip-143 [1]), this seems to imply a signature using the revocationpubkey cannot be constructed ahead of time by the client to be given to the watchtower.
Even if we had sighash_noinput (or similar), some care would need to be taken, given the address-reuse between each second-stage HTLC output (and even the to_local output). Also, as noinput/anyprevout as per current proposal will only work with witness v1 outputs, the current tx template will need to be changed to use those.
A watchtower that does not sweep HTLC outputs seems to be of limited utility to me: to mitigate risk, max_htlc_value_in_flight_msat would have to be set to a small fraction of the channel capacity.
I was told on IRC that this regression is a "clear" tradeoff of using option_anchor_outputs - but as I have not seen this discussed anywhere previously and as it was not completely obvious to me at first, I just wanted to explicitly point it out for the benefit of others.
ghost43
[0]: https://github.com/lightningnetwork/lightning-rfc/blob/7e8c478aef0d23a445845b7d297b0e804583697c/03-transactions.md#htlc-timeout-and-htlc-success-transactions
[1]: https://github.com/bitcoin/bips/blob/master/bip-0143.mediawiki#specification

2023-06-07 18:30:44

- reply

📅 Original date posted:2021-03-14
📝 Original message:See some replies inline. (quoted text from BIP draft)
> Date: Sun, 14 Mar 2021 01:51:15 +0000
> From: Robert Spigler <RobertSpigler at protonmail.ch>
> Subject: [bitcoin-dev] Signature and Script Independent Hierarchy for Deterministic Wallets.
> There are many issues with the current standards. As background, BIP 44/49/84 specifies:
> `m / purpose' / coin_type' / account' / change / address_index`
> where the BIP43 `purpose'` path is separate for each script (P2PKH, P2WPKH-in-P2SH, and P2WPKH respectively). However, these per-script derivations are made redundant with descriptors
> We should not be mixing keys and scripts in the same layer. The wallet should create extended private/public keys independent of the script or signature type
You say that keys and scripts should not be mixed in the same layer, and imply that this was solely done due to these standards predating output script descriptors. Even if this was the case, it is not the only reason for doing it. BIP44/49/84 mixing scripts and keys in the same layer makes recovery from seed/mnemonic much easier.
Note the significant overlap between the authors of BIP39 and BIP44. I am fairly certain BIP44 was designed with recovering from a BIP39 seed (and no additional information backed up) in mind. Note the "Account discovery" section of BIP44.
(Electrum seeds go even further, as such seeds contain a version number that encodes both the script type and the key derivation path to use.)
> We define the following 5 levels in the BIP32 path:
> `m / purpose' / coin_type' / account' / change / address_index`
> [Account]
> It is crucial that this level is increased for each new wallet joined or private/public keys created; for both privacy and cryptographic purposes.
> For example, in multisignature wallets, before sending a new key record to a coordinator, the wallet must increment the `account'` level. Before creating it's own single signature wallet, the `account'` level must again be incremented.
Imagine a user who has a BIP39 (or similar) seed. Even today, recovering most non-singlesig scripts from that is obviously infeasible. However, all singlesig scripts at least can be discovered if the keys are using the suggested derivation paths.
By trying to create a standard that mixes discoverable and non-discoverable scripts in the same derivation scheme and incrementing a single index, you are turning all scripts into being non-discoverable.
Note that even if a user only used singlesig scripts and followed this proposal, during recovery from seed the wallet would have to check all script types for all account indices (which is only ever going to get more expensive as new script types come).
The workaround and I imagine your suggested solution is clearly to backup both seed words and output script descriptors; and to keep appending new output script descriptors to existing backups when the account index is incremented. While much less user-friendly than backing up just a seed, it is more generic and extendable.
My point is simply that your proposal is making a tradeoff here. The tradeoff itself seems easy to miss on first read of the text, so I just wanted to explicitly point it out for the record.
ghost43 / SomberNight

2023-06-07 18:21:21

- reply

📅 Original date posted:2019-10-21
📝 Original message:> The SNICKER recovery process is, of course, only required for wallet
recovery and not normal wallet use, so I don't think a small amount of
round-trip communication between the hot wallet and the cold wallet is
too much to ask---especially since anyone using SNICKER with a
watching-only wallet must be regularly interacting with their cold
wallet anyway to sign the coinjoins.
What you described only considers the "initial setup" of a watch-only wallet. There are many usecases for watch-only wallets. There doesn't even necessarily need to be any offline-signing involved. For example, consider a user who has a hot wallet on their laptop with xprv; and wants to watch their addresses using an xpub from their mobile. Or consider giving an xpub to an accountant. Or giving an xpub to your Electrum Personal Server (which is how it works).
Note that all these usecases require "on-going" discovery of addresses, and so they would break.
ghost43
(ps: Apologies Dave for the double-email; forgot to cc list originally)

2023-06-07 18:21:20

- reply

📅 Original date posted:2019-10-19
📝 Original message:Hi all,
waxwing, ThomasV, and I recently had a discussion about implementing SNICKER in Electrum; specifically the "Receiver" role. To me, SNICKER is an interesting proposal, due to the non-interactivity and because it seems it would be easy to implement the "Receiver" role in a light wallet. If enough users are using wallets that implement the "Receiver" role, even if full nodes and specialised scripts are needed to run SNICKER as a "Proposer", then coinjoins via SNICKER could become fairly frequent on-chain, benefitting the whole ecosystem indirectly by breaking common chain-analysis assumptions even further.
The BIP (draft) describes how the Receiver can deterministically find all his outputs and reconstruct all corresponding private keys, just from the seed words and the blockchain.
However what is not explicitly pointed out, and what I would like to point out in this mail, is that SNICKER breaks watch-only functionality.
See "Receiver actions" > "Storage of Keys" section ("Re-derive from blockchain history"). [0]
Specifically, the output address in the SNICKER transaction that pays to the "Receiver", is constructed from the pubkey `P_A + cG`, where `P_A` is a pubkey of "Receiver" (typically a leaf pubkey along some BIP32 path), and `c` is a tweak. This tweak was constructed such that `c = ECDH(Q, P_A)`, where `Q` is a pubkey of the "Proposer" that appears in the witness of the SNICKER tx.
As the referenced section [0] explains, the "Receiver" can restore from seed, and assuming he knows he needs to do extra scanning steps (e.g. via a seed version that signals SNICKER support), he can find and regain access to his SNICKER outputs. However, to calculate `c` he needs access to his private keys, as it is the ECDH of one of the Receiver's pubkeys and one of the Proposer's pubkeys.
This means the proposed scheme is fundamentally incompatible with watch-only wallets.
Nowadays many users expect being able to watch their addresses from an unsecure machine, or to be able to offline sign transactions. In the case of Electrum specifically, Electrum Personal Server (EPS) is also using xpubs to function. We've been exposing users to xpubs since the initial BIP32 implementation (and even predating BIP32, in the legacy Electrum HD scheme, there were already "master public keys").
It would seem that if we implemented SNICKER, users would have to make a choice, most likely during wallet creation time, whether they want to be able to use xpubs or to potentially participate in SNICKER coinjoins as a "Receiver" (and then encode the choice in the seed version). This choice seems rather difficult to communicate to users. Further, if SNICKER is not supported by the default choice then it is less likely to take off and hence less useful for the user; OTOH if xpubs are not supported by the default choice then existing user expectations are broken.
(Note that I am using a loosened definition of xpub here. The pubkeys in SNICKER tx output scripts are not along any BIP32 derivation. The point here is whether they could somehow be identified deterministically without access to secret material.)
Unfortunately it is not clear how the SNICKER scheme could be adjusted to "fix" this. Note that `c` needs to be known exactly by the two coinjoin-participants and no-one else; otherwise the anonymity set (of 2) is broken as:
- which SNICKER output corresponds to the tweaked public key and hence to the Receiver, can then be identified (as soon as the output is spent and the pubkey appears on-chain), and
- using subset-sum analysis the inputs and the outputs can be linked
SNICKER assumes almost no communication between the two parties, so it seems difficult to find a sufficient construction for `c` such that it can be recreated by the Receiver if he only has an xpub (and access to the blockchain) as all pubkeys from the xpub that the Proposer would have access to are already public information visible on-chain.
ghost43
[0] https://gist.github.com/AdamISZ/2c13fb5819bd469ca318156e2cf25d79#Storage_of_Keys
> Hello list,
> Here is a link for a draft of a BIP for a different type of CoinJoin I've named 'SNICKER' = Simple Non-Interactive Coinjoin with Keys for Encryption Reused.
>
> https://gist.github.com/AdamISZ/2c13fb5819bd469ca318156e2cf25d79
>
> Purpose of writing this as a BIP:
> There was some discussion on the Wasabi repo about this recently (https://github.com/zkSNACKs/Meta/issues/67) and it prompted me to do something I should have done way back when I came up with the idea in late '17: write a technical specification, because one of the main attractive points about this is that it isn't a hugely difficult task for a wallet developer to implement (especially: Receiver side), and it would only really have value if wallet developers did indeed implement it. To be specific, it requires ECDH (which is already available in libsecp256k1 anyway) and ECIES which is pretty easy to do (just ecdh and hmac, kinda).
>
> Plenty of uncertainty on the specs, in particular the specification for transactions, e.g. see 'Partially signed transactions' subsection, point 3). Also perhaps the encryption specs. I went with the exact algo already used by Electrum here, but it could be considered dubious (CBC).
>
> Thanks for any feedback.
>
> Adam Gibson / waxwing

2023-06-07 18:15:54

- reply

📅 Original date posted:2018-12-28
📝 Original message:Hi Kenshiro,
That is not how the BIP process works. Instead of requesting the creation
of a BIP, you just create one. :)
Re CT in Bitcoin, I have my doubts whether you can get consensus for that.
>From section 4.6 of the Bulletproofs paper [0]:
"Bulletproofs ... are computationally binding. An adversary that could
break the discrete logarithm assumption could generate acceptable range
proofs for a value outside the correct range. ... An adversary that can
break the binding property of the commitment scheme or the soundness of
the proof system can generate coins out of thin air and thus create
uncontrolled but undetectable inflation rendering the currency useless"
I don't have the domain knowledge to debate whether quantum computers will
ever exist but AFAICT their emergence would easily kill a currency that
uses these kind of range proofs for confidential transactions.
[0]: https://eprint.iacr.org/2017/1066.pdf
> From: "Kenshiro []" tensiam at hotmail.com
>
> Hi,
>
> I think Confidential Transactions (CT) are a great idea to provide enough privacy for normal users (hidden amounts) and fungibility.
>
> I would like to request the creation of a BIP to implement CT in Bitcoin Core. I read that CT are already implemented in Grin and Monero so it looks that CT are enough mature to be implemented in Bitcoin.
>
> If the CT transaction size is 3x the size of a normal transaction the block size could be increased by 3x too, or just keep the current block size and make CT transactions optional.
>
> Thank you!

2023-06-07 18:15:12

- reply

📅 Original date posted:2018-11-08
📝 Original message:Do you specifically want to support changing the language of seed
words, while keeping the bip32 root seed they generate unchanged?
What is the usecase for this?
You mention that BIP39 already supports a few different languages.
While this is true, many (I would guess most!) wallets only
support the English wordlist.
There are doubts even from the authors of the BIP whether it was
a good idea in the first place to support multiple languages [0].
I don't find this surprising as it seems bad design to have to fix and
maintain a wordlist for every language as the checksum depends on it.
The supported wordlists are effectively a part of the specification,
and every new list would just make that specification larger.
If changing the language of seeds is not a requirement, then look
into Electrum seeds. They are language/wordlist agnostic.
Mnemonic Sentence => PBKDF2 => BIP-0032 Seed
The bip32 seed is derived by hashing the normalized mnemonic, and the
checksum is derived the same way but by using a different cheaper
hash (single round of HMAC-SHA512; generation grinds until it matches
a pattern) [1]. For example, "9dk" is a valid segwit electrum seed.
[0]: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2018-January/015507.html
[1]: http://docs.electrum.org/en/latest/seedphrase.html
> Date: Wed, 7 Nov 2018 00:16:41 +0800
> From: Weiji Guo weiji.g at gmail.com
> Subject: [bitcoin-dev] BIP- & SLIP-0039 -- better multi-language
> support
>
> Hello everyone,
>
> I just realized that BIP-0039 is language dependent. I was assuming the
> other way till I looked closer. The way the seed is derived from a BIP-0039
> entropy, as is shown below, depends on which language to generate the
> mnemonic sentence:
>
> Entropy <=> Mnemonic Sentence => PBKDF2 => BIP-0032 Seed
>
> Therefore when a user choose a non-English mnemonic code he or she is stuck
> with that language. Meanwhile only a few native languages are supported.
>
> SLIP-0039 does not solve this issue in a user friendly way by providing
> only an English wordlist. That's understandable as it aims to provide SSS
> capability. However those users who do not speak English or recognize
> English words will suffer.
>
> What I am trying to bring to attention of the community is that, no matter
> if we make a new version of BIP-0039, or a new BIP (with SSS support), or
> to enhance SLIP-0039, we really need to address this language issue.
>
> Here are what I propose:
>
> 1. The mnemonic code should be only a representation of underlying entropy
> or (pre) master secret, seed, whatever. In this way, the same seed/secret
> could be displayed in English or in Chinese or other languages. Then there
> could be 3rd party conversion tools to support translations in case any
> wallet software or device does not support all specified languages. Now it
> looks like:
>
> Mnemonic Sentence <=> Entropy => PBKDF2 => BIP-0032 Seed
>
>
> 2. Given that only 8 languages are supported in BIP-0039, we should allow
> the seed/secret to be represented in decimal numbers, each ranging from 0
> to 2047. So those who cannot find a native language support yet having
> difficulty coping words in other languages could choose to just use numbers.
>
> So far I don't have a preference how this should be implemented. I'd like
> to hear from community first.