Good morning mailing list, et al., Let me explain the various possible mitigations and their drawbacks.
Many of these are either "LSP trusts client" or "client trusts LSP", in the sense that it is possible for the second mover (client in "LSP trusts client"; LSP in "client trusts LSP") to impose costs on, or outright steal from, the first mover. If you want a trust-minimized solution, you need some kind of third party that both LSP and client agree will actually enforce that the second mover does not cheat or otherwise impose costs on the first mover. This "third party" SHOULD really be the blockchain, meaning you should really be using at least 1-conf and probably 3-conf to avoid reorgs, but *shrug*. (You *could* use Liquid as a third party --- but Liquid is custodial, it just has a federation as a custodian instead of a single entity, you have to trust that the federation does not collude to steal all your funds, or that Blockstream has not installed Something Else (TM) in the HSMs they sold to the federation members.) Without a trusted third party (with the blockchain, being a decentralized open-source project with strong incentives against censorship, being your standard for trustworthiness), your choices are: * LSP issues a promise --- a signature committing to a funding output on a funding transaction --- that it will definitely make a 0-conf funding transaction get confirmed before some future target blockheight. https://github.com/BitcoinAndLightningLayerSpecs/lsp/pull/24 If the funding transaction is not confirmed by then, or the output is not the correct `scriptPubKey` and amount, the client reports it publicly and starts a boycott of the LSP. * The client refuses to send `channel_ready` (and therefore the HTLC cannot reach the client) until after the LSP issues this promise. "LSP trusts client". * How often have boycotts actually worked anyway? * Client waits for the funding transaction to appear on its local mempool before sending `channel_ready`. * "LSP trusts client", somewhat, but far weaker than the above; you can argue this is actually "client trusts LSP" and I would agree with you. * The LSP can still double-spend the funding transaction with coordination with a miner, as I noted in my critique of benthecarman proposal. Mere broadcast is not an assurance of confirmation, we have been saying that about 0-conf for a long time. * Not all clients naturally have access to a mempool --- BIP157/158 clients do not necessarily maintain their own mempool, though an Electrum SPV client can query the mempool of the Electrum server. * benthecarman proposal, as noted in previous post. * "client trusts LSP". * LSP waits for the client to hand over the preimage before broadcasting the funding tx. * "client trusts LSP". * LSP can skip actual funding tx broadcast once the client has handed over the preimage. * Can be implemented in multiple ways that are all equivalent: * Outright give the preimage in some bespoke API call. * LSP sends the `open_channel` blah blah dance until `channel_ready` exchange, does `update_add_htlc` and irrevocably committed dance, then waits until `update_fulfill_htlc` before broadcasting the funding tx. * A client can implement the "client waits for funding tx in its own mempool before preimage" while the LSP implements this "LSP waits for preimage before funding tx broadcast", and both of them will stall waiting for each other LOL ^.^ wahahahahaha deadlock is fun. This is why LSPS has to pick one or the other, otherwise we will get incompatibilities between LSPs and clients. LSPS (Open LSP Specifications group) participants have indicated a desire to prefer "LSP trusts client", because the LSP is a big target for various kinds of out-of-LSPS attacks. For example, a hacker could potentially modify the behavior of an LSP so that the LSP attacks the client, if the "client trusts LSP" model is used. Worse, somebody can ***accuse*** the LSP of actually attacking *some* client, and it can be hard for the LSP to provide substantial evidence that it is NOT attacking the client. (This is why the "promise" scheme I listed first above is valuable --- it is definite proof that the LSP is not attacking the client, if the client is unable to provide the promise as a proof-of-misbehaviour, then the client is just bullshitting and its claim of being cheated can be ignored, assuming of course that people actually believe in the strong cryptographic provisions of the signature scheme (which I might add is the same signature scheme used to secure Bitcoin itself, so... but humans are stupid, which is why AI should replace humans with something better). By the way have I mentioned I am human today?) However, the only truly "LSP trusts client" scheme that I have figured out is that first scheme where the LSP issues a cryptographically third-party-verifiable promise to get the funding tx confirmed by some later blockheight. This scheme has been controversial even among LSPS participants, however. Regards, ZmnSCPxj _______________________________________________ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
