On Tue, Jun 19, 2018 at 04:46:32PM +0200, Christian Decker wrote: > That is true, we can't prevent S_2 to make it into the blockchain, but > we can make sure it doesn't have any effect (aside from wasting some > fees), by simply binding S_3 to it immediately afterwards.
Right, but I'm picking on the phrasing in the paper here, which seems to imply that once the final settlement transaction enters the mempool with a reasonable fee, its confirmation---and the safe close of the channel---is "certain." I don't think that's the case and I think the phrasing might be accidentally misleading to readers who don't have a good grasp of mempool behavior. > It should be noted that anyone can perform the rewriting, and it's easy > to do so, by just following the funding output and knowing the final > update. Anyone can rewrite a SIGHASH_NOINPUT input's outpoint, but the actual transaction containing the settlement is expected to have (at least) two inputs, with the second one originating the fees. That second input's signature is (I assume) using SIGHASH_ALL to commit to all outpoints in the transaction, so it can't be arbitrarily rewritten by a third-party to apply to a different state outpoint---and so I think we're dependent on a motivated person (e.g. one of the channel participants) performing the rewrite so that the rewritten final settlement transaction pays fees. Thanks, -Dave
signature.asc
Description: PGP signature
_______________________________________________ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
