lightningdevkit / ldk-sample Goto Github PK

Github recently announced the deprecation of Node12-based actions.

We should upgrade all actions of the CI to stop them complaining.

Currently blocked on actions-rs/toolchain#220.

We really should support them here, any work towards this @wpaulino or @tnull?

See details here #126 (comment)

The payment_parameters_from_invoice, introduced in #2727, should be used, as it encapsulates some of the error handling.

We should let users specify a funding feerate manually.

we need to check bounds when parsing a pubkey in the hex utils method.

> 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 lightningdevkit/rust-lightning#642 merged, as the solution will heavily conflict.

And tell users to use ^D.

I saw this was commented TODO in main.rs, but I wanted to open an issue to see if others think this would be valuable to implement before I start working on a PR for it.

Motivation

It seems this--keeping track of payment info between times that a node is on/offline--would be helpful to demonstrate to a user. I don't think this adds significant complexity compared to what's already here, but I'm open to what others have to say.

Implementing this

My initial thoughts for what needs to be done to implement this:

• On startup, read inbound_payments and outbound_payments if they have been previously persisted.

• Whenever inbound_payments or outbound_payments gets updated, persist payment info to disk.

• Haven’t totally fleshed out what’s the best way to persist/update payment info, but considering some of the following:

  • Add custom read_payment_info and persist_payment_info functions to disk.rs.
  • Implement Writeable trait (and maybe Readable) on PaymentInfoStorage so that we can persist using FilesystemPersister similar to how other things are persisted.
  • Likely split up inbound_payments and outbound_payments into 2 different files to not complicate serializing payment info
• Where does payment info get updated?

  • main.rs
    • inbound_payments | Event::PaymentClaimed
    • outbound_payments | Event::PaymentSent
    • outbound_payments | Event::PaymentFailed
  • cli.rs
    • inbound_payments | get_invoice
    • outbound_payments | send_payment
    • outbound_payments | keysend

Perhaps use a library such as https://github.com/tailhook/rust-argparse? That way, arguments can be provided in any order rather than requiring adherence to a prescribed sequence.

I'm trying to run against a regtest node according to the README but I'm hitting this error. I get it with or without specifying a port explicitly. Am I doing something wrong or is this a bug?

$ cargo run user:[email protected]:18443 ~/.ldk regtest
    Finished dev [unoptimized + debuginfo] target(s) in 0.03s
     Running `target/debug/ldk-tutorial-node 'user:[email protected]:18443' /home/danielmcnally/.ldk regtest`
thread 'main' panicked at 'invalid digit found in string', src/cli.rs:73:25
stack backtrace:
   0: rust_begin_unwind
             at /rustc/a178d0322ce20e33eac124758e837cbd80a6f633/library/std/src/panicking.rs:515:5
   1: std::panicking::begin_panic_fmt
             at /rustc/a178d0322ce20e33eac124758e837cbd80a6f633/library/std/src/panicking.rs:457:5
   2: ldk_tutorial_node::cli::parse_startup_args
             at ./src/cli.rs:73:19
note: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose backtrace.
Aborted (core dumped)

Hi, really like this sample project and its been for learning lightning/ldk. If one would like to write a function for getting the current Wallet balance is there a method in LDK for this purpose? I looked over docs and couldn't find anything.

Let me know if I should instead ask this question in Discord (please include the channel).

Depends on lightningdevkit/rust-lightning#943

This helps users correlate spendable outputs to individual channels (CC https://github.com/orgs/lightningdevkit/discussions/2407).

bitcoind_client:: send_raw_transaction receives a RawTx and calls rpc.call_method expecting a return of the same type (rpc.call_method::<RawTx>...).

This feels wrong*, given sendrawtransaction returns a txid if successful. It may make more sense to pass a RawTx to send_raw_transaction and returning a TxidHex or something of those lines.

*Notice this actually works given RawTx is simply a wrapper around String.

Docs - https://docs.rs/lightning/0.0.105/lightning/util/config/struct.UserConfig.html#structfield.manually_accept_inbound_channels

cc @ViktorTigerstrom

I tried to use this tool and was unable to connect, after digging I found out it was because of the split procedure and the expectation of 2 vectors after split. I opened a PR with a potential fix, which allowed me to get through this block, I am still new to rust.

#37

And possibly for other properties, too, such that not every single launch has to be a super long command, and such that the auth data doesn't get added to the command history.

MaxFangX, on discord, reported:

Spent the last few hours pinning down the root cause of a channel manager panic. Turns out it was a race condition inherited from ldk-sample:

• (1) If a channel manager is starting for the first time, it gets its initial block hash by calling BlockSource::get_blockchain_info() and constructing a BestBlock out of that.
• (2) During the initial chain sync, if chain_tip.is_none() then the best chain_tip is retrieved using lightning_block_sync::init::validate_best_block_header() which similarly uses BlockSource::get_best_block()
  If blocks were mined between (1) and (2), the channel manager’s block hash will be at a lower height than that of the block hash contained inside the chain_tip fed to the SpvClient. Suppose that this results in the channel manager being at block 1 and the SpvClient being at block 2. Once block 3 comes in and the SpvClient detects it via poll_best_tip(), the SpvClient computes the ChainDifference between its saved chain_tip value and block 3, concluding that it just needs to connect block 3. However, when Listen::filtered_block_connected is called using the data in block 3, the channel manager panics with “Blocks must be connected in chain-order - the connected header must build on the last connected header” - because block 3’s prev block hash is block 2’s block hash, rather than block 1’s block hash which the channel manager expects.

It seems very unlikely to happen in practice but that also means it has the potential to be a superrrrr flaky bug for someone else in the future. Came up in our integration tests because we have separate "init" and "sync" stages, where "init" initializes the channel manager and "sync" calls into lightning_block_sync::init, and we were mining blocks in between.

Setup:

1. LDK sample on desktop
2. SBW testnet wallet on android
3. SBW opened towards LDK a channel.

The SBW side info:

Channel details

Remote peer node ID
02ba6795ff89159b58dd95305569355cbad23301e286468410bbb65c5c2f20fd28

Local wallet node ID
023488cfb58a6b46f83bbeb185b4b4b6087de62a5a5141425dd83f37a3a8041201

Channel short ID
2578902323927449600

Funding txid
7cf45c3be6f231f8a60c10716a4048806508705eccf0c0c4b073a2480dfb9dc1

Channel started
2 hours ago

The LDK info:

> listchannels
[
	{
		channel_id: c19dfb0d48a273b0c4c0f0cc5e7008658048406a71100ca6f831f2e63b5cf47c,
		funding_txid: 7cf45c3be6f231f8a60c10716a4048806508705eccf0c0c4b073a2480dfb9dc1,
		peer_pubkey: 023488cfb58a6b46f83bbeb185b4b4b6087de62a5a5141425dd83f37a3a8041201,
		short_channel_id: 2578902323927449600,
		is_channel_ready: true,
		channel_value_satoshis: 650000,
		local_balance_msat: 800000,
		available_balance_for_send_msat: 150000,
		available_balance_for_recv_msat: 642700000,
		channel_can_send_payments: true,
		public: false,
	},
]
> listpeers
{
	pubkey: 023488cfb58a6b46f83bbeb185b4b4b6087de62a5a5141425dd83f37a3a8041201
},

Payment of invoice produced by LDK is ok. But, when I try to pay invoice produced by SBW, I got:

> sendpayment lntb500n1p33v9sxpp532xw4h2utv0dx8rm0q37kc288crv555evq5sqtpxv22v8w2ar4zqdqqsp57dg9y0fest04hfgs6we7kvxu0wqy7teqxn7csqjtvtnhcsj0dhcsxqy9gcqcqzys9qyysgqrzjq2ax090l3y2ekkxaj5c926f4tjadyvcpu2rydpqshwm9chp0yr7jsg72rgqqqgqqqqqqqqlgqqqqqqqqfq0l22mmx258r0cfgwzqusjjl76zmwyhchum52496snmakalevhkxnk7m5hv0pdvllyd49js50qjpm78634k7xzhxwr9u8gsjc37gjhlsqjywpza
ERROR: failed to find route: Failed to find a path to the given destination

The example of invoice produced by LDK (that is ok):

lntb7u1p33v9dfdqud3jxktt5w46x7unfv9kz6mn0v3jsnp4q2ax090l3y2ekkxaj5c926f4tjadyvcpu2rydpqshwm9chp0yr7jspp5s64ap9480lpxh4tcf6ufcumjx8qy28xelwfg3fy7nhnvgpylhnmssp5llyfacaaefmxdjauqv3s8g7mujhujedx8gsz2ghh0u3ps6ye3qns9qyysgqcqpcxqzjcyr049wn9qwh93mya66ak75c0e6untgr5fyr2fnqu8pe7k8q8rqlz8qn420r2ewv2g07t32sla2fgdnx28m0st9cs30d75pmej9upy8spqn2rr6

Docs - https://docs.rs/lightning/0.0.105/lightning/routing/scoring/index.html#

cc @jkczyz

When feerates are high we may fail to spend outputs (eg low-value htlcs or to-self outputs), which currently unwrap's. We really need a pipeline to store them to disk and claim on a timer anyway in case fees go up after a claim, but we at least shouldn't unwrap.

Trying to clone the repo with:
git clone https://github.com/lightningdevkit/ldk-sample
gives the error:

Cloning into 'ldk-sample'...
fatal: invalid branch name: init.defaultBranch = 

Necessary to download and unpack the source zip file.

When I was working on a project, I tried to start a Lightning Network node with reference to the ldk-sample project.
If the bitcoin-network parameter is filled with mainnet or main, the following information will be prompted:
Unsupported network provided. Options are: regtest, testnet, and signet

Standard practice for unix-y things is to reload the log output on SIGHUP to allow logrotate to move the log every day. Obviously the sample isnt really intended as a daemon given it has a cli input, but it may still be nice to do so.

I'd like to use a pair of ldk nodes in an integration test and I found this project. I was thinking it would be nice for my purposes to add a lib.rs with the start_ldk function exposed to add the option of importing it directly into another rust project.

I'm wondering if this would be a welcome PR -- or if for some reason it isn't. Would be happy to contribute. :)

I'm able to open channels eclair -> LDK but not the other way around.
The LDK node crashes after receiving accept_channel:

> thread '<unnamed>' panicked at 'called `Result::unwrap()` on an `Err` value: Custom { kind: Other, error: "Unexpected key fee_rate" }', src/bitcoind_client.rs:202:78
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
Aborted (core dumped)

It looks like an issue with the bitcoind_client not understanding a field in the response (probably while trying to create the funding tx). I was using bitcoind 0.20.1 for this test.

See lightningdevkit/rust-lightning#2259 (comment)

I was wondering if you would be willing to add a readline dependency such as rustyline? It would be very useful to be able to recall history with the up arrow as well as use other shortcuts. If not then I could implement something primitive, but either way I think it would save time writing out commands.

Update it to 0.30.2 (from 0.29), as ldk is now using that version.

lightningdevkit/rust-lightning@ec928d5

Perhaps use a library like https://github.com/mitsuhiko/dialoguer? It also adds support for autocompletion.