When initially reading the blockchain, we start 100 back from the
current block, or at the first block with a funding transaction,
whichever is earlier.
This slows testing slightly, so use whatever the "forever" value is
(10 on testnet, still 100 on mainnet).
make check -j12 times:
Before: 7m52.005s
After: 6m31.896s
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Instead of using wall-clock time, we use blocks. This is simpler and
better for database restores. And both sides will time out.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
This allows us to add a new field for a callback at the end, but
more subtle, ensures broadcast in order (which simplifies testing).
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
broadcast_remainder() does two things: get the error message for the
previous transaction, and send the next one (shrinking the array).
But it has two bugs:
1) It logs results on the tx at the end of the array, which is the one
it is *about* to send, and
2) The initial caller (rebroadcast_txs) hands it the complete array,
so the first tx gets broadcast twice.
The correct thing to do is to strip the array, then send the tail for
the next callback. And use nicely-named vars to help document what
we're doing.
Reported-by: Christian Decker
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
This is in preparation for the next step.
Note that we now don't add it to the linked list of txs we've send
until after it's sent by the immediate callback; this means it won't
get broadcast by the timer until after it's been done by broadcast_tx.
Also, this means we no longer steal the tx in broadcast_tx(); but we'll fix
up the leaks 4 patches later.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Added channel announcement serialization and parsing, as well as the
entrypoints for the IRC peer discovery. Announcements are signed by the
sending endpoint and signatures are verified before adding the channels
to the local view of the topology. We do not yet verify the existence of
the anchor transaction.
Caught because we generated an HTLCs which had already expired, since
we didn't know the latest block. Other errors are certainly possible,
so it's safest to load the entire thing before going live.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
This avoids us having to query it when we create anchor transaction, and
lets us always use dynamic fee information.
The config options for max and min are now percentages, rather than absolute.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
getchaintips returns tips even if we don't have the body for them, so
we need to look for the active tip, not just the first (most-work) one.
Here's what happens in the log:
+2849.963414597 lightningd(26779):BROKEN: bitcoin-cli getblock 0000000000000000018626ff7160bdf38a602e6650bd04ec258759ea578b106d false exited 91: 'error code: -32603
error message:
Can't read block from disk
'
And here's an example problematic getchaintips output:
[
{
"height": 419635,
"hash": "0000000000000000000fd32d87fce19efb7ccd07aa4ddaf1b94b9a219deec0f9",
"branchlen": 1,
"status": "headers-only"
},
{
"height": 419634,
"hash": "000000000000000002988d6512719697147cf252b2f64d247cf229266615d2bb",
"branchlen": 0,
"status": "active"
},
{
"height": 416372,
"hash": "0000000000000000004d0a54341c992ae174a91c8dd3981a9f2b3d3f6221ba59",
"branchlen": 1,
"status": "valid-headers"
},
{
"height": 416231,
"hash": "0000000000000000044d0d2c25f33cb48931540366149cde3fb0154f55b58c76",
"branchlen": 1,
"status": "headers-only"
}
]
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
The protocol still supports both, but we now only support blocks.
It's hard to do risk management with timeouts in seconds, given block
variance. This is also signficantly simpler, as HTLC timeouts are
always fired in response to blocks, not wall-clock times.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Uses a gcc extension (cast to union) for typechecking, but that can be
removed for compilers which don't support it.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Currently this mean --bitcoin-poll; we're going to change the other time
options to block heights anyway.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Since bitcoind doesn't propagate non-main chains, there's little point
trying to be smart when we see them. This simplifies things immensely.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
It's primitive, but we re-broadcast any txs not included in the main
chain every time the tip moves. We only track transactions we are
watching, but that turns out to cover every transaction we generate
anyway.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
This turns out to make life easier for watching HTLC timeouts (we just
place a new watch for each HTLC).
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Since any transaction with all segregated-witness inputs is non-malleable,
and all our transactions are that, we can remove normalized txids.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
There isn't a single blockhash; we may be on multiple forks. But the one
caller which cares is commit_tx_depth(), which wants to know if the tx is
spendable yet. So that uses get_last_mediantime().
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Rather than polling for interesting bitcoin txs via importaddress, we use
the chain topology to register our interest directly.x
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
This gets the median time of the block the tx is in. If there is more
than one (different tips), it gets the last median time.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
This allows us to track precise transaction depth ourselves,
particularly in the case of branching.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Rusty Russell
Glenn Willen
Christian Decker