š
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>;
David A. Harding [ARCHIVE] /
npub16dā¦x4wrd
2023-06-09 12:50:53
in reply to nevent1qā¦d82z
Author Public Key
npub16dt55fpq3a8r6zpphd9xngxr46zzqs75gna9cj5vf8pknyv2d7equx4wrdPublished at
2023-06-09 12:50:53Event JSON
{
"id": "403a90ef5b75494bb260fdbaa7a5dea693d4b4fa7d8077a0a2c4c66fda6002cf",
"pubkey": "d3574a24208f4e3d0821bb4a69a0c3ae842043d444fa5c4a8c49c369918a6fb2",
"created_at": 1686315053,
"kind": 1,
"tags": [
[
"e",
"da800d129bb6f13479aec8335d3350911374ef3c1eb580dbd96e640002b62a32",
"",
"root"
],
[
"e",
"130cf5f7627e5bd6021c1ab54329156c71a2d97025c22c2bc5d3aa7c89353534",
"",
"reply"
],
[
"p",
"72cd40332ec782dd0a7f63acb03e3b6fdafa6d91bd1b6125cd8b7117a1bb8057"
]
],
"content": "š
Original date posted:2018-06-19\nš Original message:\nOn Tue, Jun 19, 2018 at 04:46:32PM +0200, Christian Decker wrote:\n\u003e That is true, we can't prevent S_2 to make it into the blockchain, but\n\u003e we can make sure it doesn't have any effect (aside from wasting some\n\u003e fees), by simply binding S_3 to it immediately afterwards. \n\nRight, but I'm picking on the phrasing in the paper here, which seems to\nimply that once the final settlement transaction enters the mempool with\na reasonable fee, its confirmation---and the safe close of the\nchannel---is \"certain.\" I don't think that's the case and I think the\nphrasing might be accidentally misleading to readers who don't have a\ngood grasp of mempool behavior.\n\n\u003e It should be noted that anyone can perform the rewriting, and it's easy\n\u003e to do so, by just following the funding output and knowing the final\n\u003e update.\n\nAnyone can rewrite a SIGHASH_NOINPUT input's outpoint, but the actual\ntransaction containing the settlement is expected to have (at least) two\ninputs, with the second one originating the fees. That second input's\nsignature is (I assume) using SIGHASH_ALL to commit to all outpoints in\nthe transaction, so it can't be arbitrarily rewritten by a third-party\nto apply to a different state outpoint---and so I think we're dependent\non a motivated person (e.g. one of the channel participants) performing\nthe rewrite so that the rewritten final settlement transaction pays\nfees.\n\nThanks,\n\n-Dave\n-------------- next part --------------\nA non-text attachment was scrubbed...\nName: signature.asc\nType: application/pgp-signature\nSize: 833 bytes\nDesc: not available\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20180619/7bde3561/attachment.sig\u003e",
"sig": "d4e51fc471d6e76045ab19a95d7a34a546607ba1f9f7ae3c679e1530759d111047e65557272e06852fb0e8f820f2305ffefdaf1df8c7e1f1a3f1ef52abe7ddaa"
}