search

lightningdevkit / ldk-sample

Sample node implementation using LDK
Apache License 2.0
166 stars 94 forks source link

Panic due to funding transaction rejected with "non-BIP68-final" #9

Closed valentinewallace closed 3 years ago

valentinewallace commented 3 years ago 
> openchannel 0227d8e3f25e4d991cc51a19782c0277904f1590db7da27b33bf96cca181022bd8@127.0.0.1:9737 1000000
EVENT: initiated channel with peer 0227d8e3f25e4d991cc51a19782c0277904f1590db7da27b33bf96cca181022bd8.
thread 'tokio-runtime-worker' panicked at 'called `Result::unwrap()` on an `Err` value: Custom { kind: Other, error: "Errored with status: 500 and contents: {\"result\":null,\"error\":{\"code\":-26,\"message\":\"non-BIP68-final\"},\"id\":\"129\"}\n" }', src/bitcoind_client.rs:241:88

Then on restart:

thread 'tokio-runtime-worker' panicked at 'called `Result::unwrap()` on an `Err` value: Custom { kind: Other, error: "Errored with status: 500 and contents: {\"result\":null,\"error\":{\"code\":-27,\"message\":\"Transaction already in block chain\"},\"id\":\"5\"}\n" }', src/bitcoind_client.rs:241:88

Matt's explanation: "yes, we currently are quite lazy and send transactions which conflict with ones we see on the chain (this addresses some super-theoretical basically nonsense cases around eclipse-style attacks) as well as ones which are not yet broadcastable as they are time-locked. in the second case, the docs currently say its the users' responsibility to rebroadcast the transactions until the timelock is reached (hence the "non-BIP68-final" error you see above), but I'd realllllyyyy like to change that requirement."

Before addressing this known issue, we'll want to get https://github.com/rust-bitcoin/rust-lightning/pull/642 merged, as the solution will heavily conflict.

TheBlueMatt commented 3 years ago

This should be resolved now.