Quote from: d5000 on August 23, 2020, 11:21:40 PM

The channel partner has a key, and in theory he could cooperate with the sender of the funding transaction. So what I meant was that the sender could send the money to the multisig address using another funding transaction which competes with the "legit" transaction which uses your input. We would arrive then at the same problem you described: the txid would have changed, invalidating the commitment transactions.

However, I don't know if this attack makes any sense - could the channel partner access these funds or could they only be mobilized again if both channel partners cooperate and provide their signatures to close the channel?

I don't think so, but i do think that it is an interesting thought because it comes to the blurry limits of what defines a Bitcoin payment. Not the technical mean which is the transaction, but the conceptual action of transferring value.

If you hand me an address, and i do a transaction which pays to another address. Would you accept it as a payment ? No.
If we collaborate to create a transaction to pay you, and i finally broadcast a different transaction, would you accept it as a payment ? You should not. This is not an attack, just an absence of payment.

This is why I think the proof of payment feature of Bitcoin Lightning Network payments is important, and that we *must preserve it*. We can always bikeshed on the definition of an onchain Bitcoin payment, and endlessly argue if there was a transfer of value. If we use the Lightning Network, we just have a proof that the transfer occurred.