> Ah, right. > > A feasible attack, without the above, would be to connect to the > fullnode of the victim, and connect to miners separately. Then you > broadcast to the victim one of the old txes, call it tx A, but you > broadcast to the miners a *different* old tx, call it B. The victim > reacts only to tA, but does not react to B since it does not see B in > the mempool. > > On the other hand --- what the victim needs to react to is *onchain* > confirmed transactions. So I think all the victim needs to do, in a > Lightning universe utilizing primarily `SIGHASH_NOINPUT`-based > mechanisms, is to monitor onchain events and ignore mempool events. > > So if we give fairly long timeouts for our mechanisms, it should be > enough, I think, since once a transaction is confirmed its txid does > not malleate without a reorg and a `SIGHASH_NOINPUT` signature can > then be "locked" to that txid, unless a reorg unconfirms the > transaction. We only need to be aware of deep reorgs and re-broadcast > with a malleated prevout until the tx being spent is deeply confirmed.
This is indeed part of the reason why we chose to describe the protocol on-chain first in the paper and lift it off-chain after showing the basic functionality. This means that the protocol is still correct even if executed solely on information derived from blocks and confirmed transactions in those blocks. The timeouts have to be chosen carefully to allow reacting in a timely fashion, however that is true for all off-chain protocols. > In addition, we want to implement scorch-the-earth, > keep-bumping-the-fee strategies anyway, so we would keep > rebroadcasting new versions of the spending transaction, and spending > from a transaction that is confirmed. Correct, it might be desirable to give a misbehaving node a papercut by letting their update transaction confirm (taking their fee along with it) and then reacting to the outdated update by overriding the effects with a new update-settlement pair. So, while being able to react to a transaction in the memory pool early might be a nice addition, it is not strictly required for safety of the protocol. I say nice addition, because it can allow replacing the outdated transaction directly, thus saving the misbehaving node from the fee papercut, but also save a bit of blockspace which that fee would have paid for, and leave it available for other transactions. Cheers, Christian _______________________________________________ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
