David A. Harding [ARCHIVE] on Nostr: 📅 Original date posted:2018-06-19 📝 Original message: On Tue, Jun 19, 2018 at ...
📅 Original date posted:2018-06-19
📝 Original message:
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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20180619/7bde3561/attachment.sig>;
📝 Original message:
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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20180619/7bde3561/attachment.sig>;