lightningd: fix occasional missing txid detection. #2776
Conversation
I was working on rewriting our (somewhat chaotic) tx watching code for 0.7.2, when I found this bug: we don't always notice the funding tx in corner cases where more than one block is detected at once. This is just the one commit needed to fix the problem: it has some unnecessary changes, but I'd prefer not to diverge too far from my cleanup-txwatch branch. Fixes: ElementsProject#2352 Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
| txw = txwatch_hash_get(&topo->txwatches, txid); | ||
|
|
||
| if (txw && !txw->tx) | ||
| txw->tx = tal_steal(txw, tx_may_steal); |
There was a problem hiding this comment.
In case multiple watchers are watching the same txid (channel factories in the far future, where multiple peer-daemons want to see the confirmation depth of the same tx holding the channel factory), would not this stealing be troublesome? Would not be better to tal_dup instead?
There was a problem hiding this comment.
We need a deep copy, hence the FIXME in the header. libwally doesn't provide a copy function, which would make it easy to implement bitcoin_tx_dup().
There was a problem hiding this comment.
A lousy deep copy would be to serialize, then deserialize, i.e. the "JSON.parse(JSON.stringify())" trick.
Though I suppose, this is fine for now, we can always panic later when we actually have channel factories.
I was working on rewriting our (somewhat chaotic) tx watching code
for 0.7.2, when I found this bug: we don't always notice the funding
tx in corner cases where more than one block is detected at
once.
This is just the one commit needed to fix the problem: it has some
unnecessary changes, but I'd prefer not to diverge too far from my
cleanup-txwatch branch.
Fixes: #2352
Signed-off-by: Rusty Russell rusty@rustcorp.com.au