📅 Original date posted:2015-09-30
📝 Original message:
On Wed, Sep 30, 2015 at 11:11:09AM +0930, Rusty Russell wrote:
> > (I'm not following why the state coverage testing doesn't do something
> > more like: [...]
> Sure, but that's not even close to exhaustive testing (drawing diagrams
> was just a side-effect for me).
Absolutely. But... I'm not seeing what the code actually /does/ with the
exhaustive testing? There's a lot of asserts; but I'm not sure that's
actually testing things "make sense" or just "don't crash". Maybe having
some optional output of traces for successful test cases would make it
more obvious?
eg, (and I haven't tried pulling the code apart to really understand
it or anything) I can't tell if you're testing agreeing on two HTLCs then
having the first one time out, versus the second one time out first.
Hmm:
report_trail(&t, "CLOSED with htlc in progress?");
I figured that was expected and normal protocol behaviour? Not ideal,
but if you're still communicating at all, if someone decides the channel
has to be closed, it's still always better to do a mutual close to
avoid the CSV delays and any unnecessarily elevated fees, even with
outstanding HTLCs.
That would mean CLOSE should start tracking HTLCs (and spending when
timeouts hit or R's become known) just like when a commitment is
published; so I guess that's CLOSE_WAIT_HTLCs?
Cheers,
aj
Anthony Towns [ARCHIVE] /
npub17r…x9l2h
2023-06-09 12:44:41
in reply to nevent1q…akh8
Author Public Key
npub17rld56k4365lfphyd8u8kwuejey5xcazdxptserx03wc4jc9g24stx9l2hPublished at
2023-06-09 12:44:41Event JSON
{
"id": "5acd549517658dc8d6b7899cf107b09e78299982b5514e9ccaf03cf998d11a8e",
"pubkey": "f0feda6ad58ea9f486e469f87b3b9996494363a26982b864667c5d8acb0542ab",
"created_at": 1686314681,
"kind": 1,
"tags": [
[
"e",
"9128208f979ba16b9ae0be51d665e61e4d39f4748bd35992d09bb44edfaa05bc",
"",
"root"
],
[
"e",
"7bce8474625e9089a94d911a2ca4e483497a46b023f148b3d4d4ccaf27276f48",
"",
"reply"
],
[
"p",
"13bd8c1c5e3b3508a07c92598647160b11ab0deef4c452098e223e443c1ca425"
]
],
"content": "📅 Original date posted:2015-09-30\n📝 Original message:\nOn Wed, Sep 30, 2015 at 11:11:09AM +0930, Rusty Russell wrote:\n\u003e \u003e (I'm not following why the state coverage testing doesn't do something\n\u003e \u003e more like: [...]\n\u003e Sure, but that's not even close to exhaustive testing (drawing diagrams\n\u003e was just a side-effect for me).\n\nAbsolutely. But... I'm not seeing what the code actually /does/ with the\nexhaustive testing? There's a lot of asserts; but I'm not sure that's\nactually testing things \"make sense\" or just \"don't crash\". Maybe having\nsome optional output of traces for successful test cases would make it\nmore obvious?\n\neg, (and I haven't tried pulling the code apart to really understand\nit or anything) I can't tell if you're testing agreeing on two HTLCs then\nhaving the first one time out, versus the second one time out first.\n\nHmm:\n\n report_trail(\u0026t, \"CLOSED with htlc in progress?\");\n\nI figured that was expected and normal protocol behaviour? Not ideal,\nbut if you're still communicating at all, if someone decides the channel\nhas to be closed, it's still always better to do a mutual close to\navoid the CSV delays and any unnecessarily elevated fees, even with\noutstanding HTLCs.\n\nThat would mean CLOSE should start tracking HTLCs (and spending when\ntimeouts hit or R's become known) just like when a commitment is\npublished; so I guess that's CLOSE_WAIT_HTLCs?\n\nCheers,\naj",
"sig": "c81060d6e47eb52287bbb5970aaad5bc5266d36bbadf1e1a7da13a2e132df02f58c32653cbd6766ba322e2210ba39568002fa6d3a343adcd8263ea99845abdb1"
}