nbd-wtf/trustedcoin

A lightningd plugin that replaces bitcoind with trusted public explorers.

trustedcoin's Issues

misreporting version number after v0.6.0 been released

trustedcoin/main.go

Line 53 in 13645b4

Version: "v0.5.6",

Trustedcoin crashes on startup

2022-10-17T07:58:26.684Z DEBUG   plugin-manager: started(23) /opt/lightningd/plugins/trustedcoin
/opt/lightningd/plugins/trustedcoin: 1: Syntax error: word unexpected (expecting ")")
2022-10-17T07:58:26.689Z DEBUG   plugin-manager: started(24) /opt/lightningd/plugins/poncho_x64
2022-10-17T07:58:26.695Z INFO    plugin-trustedcoin: Killing plugin: exited before replying to getmanifest

Release: https://github.com/nbd-wtf/trustedcoin/releases/download/v0.5.7/trustedcoin-linux-arm64.tar.gz
CLN version 0.12.0

Unable to catch to the tip

On startup the plugin correctly reports tip block, but then is lagging behind and never catches up. It looks like it is not even trying, and just accepts old blocks one by one in ~10 min. intervals, so it can never progress and catch with current block.

(I run this on beefy Ryzen, so it is not by lack of computing power)

Request: GPG-sign releases or commits

While packaging trustedcoin for nix-bitcoin, where we use signature checking for all package releases, I noticed that trustedcoin provides no signatures at all.
Could you add sigs? This would remove Github as a trusted party for distributing trustedcoin.

(Yes, it's slightly amusing to request this for a package like trustedcoin.)

trusted coin keeps crashing my CLN, seemingly because it can't "sendrawtransaction"

no new blocks are being downloaded, this "sendrawtranxaction" bug seems to completely disable my CLN.

2024-04-24T05:41:14.553Z **BROKEN** lightningd: /home/cl/src/plugins/trustedcoin/trustedcoin error: bad response to sendrawtransaction (bad 'result' field: Parsing '{result:': object does not have member result), response was {"jsonrpc":"2.0","id":"cln:sendrawtransaction#1739","error":{"code":21,"message":"Post \"https://mempool.space/api/tx\": dial tcp 103.165.192.203:443: i/o timeout","data":null}}
2024-04-24T05:41:14.638Z **BROKEN** lightningd: FATAL SIGNAL 6 (version v23.08.1)
2024-04-24T05:41:14.638Z **BROKEN** lightningd: backtrace: common/daemon.c:38 (send_backtrace) 0x562f534d87b8
2024-04-24T05:41:14.638Z **BROKEN** lightningd: backtrace: common/daemon.c:75 (crashdump) 0x562f534d893e
2024-04-24T05:41:14.638Z **BROKEN** lightningd: backtrace: ./signal/../sysdeps/unix/sysv/linux/x86_64/libc_sigaction.c:0 ((null)) 0x7fc78959204f
2024-04-24T05:41:14.638Z **BROKEN** lightningd: backtrace: ./nptl/pthread_kill.c:44 (__pthread_kill_implementation) 0x7fc7895e0e2c
2024-04-24T05:41:14.638Z **BROKEN** lightningd: backtrace: ../sysdeps/posix/raise.c:26 (__GI_raise) 0x7fc789591fb1
2024-04-24T05:41:14.638Z **BROKEN** lightningd: backtrace: ./stdlib/abort.c:79 (__GI_abort) 0x7fc78957c471
2024-04-24T05:41:14.638Z **BROKEN** lightningd: backtrace: lightningd/log.c:1025 (fatal_vfmt) 0x562f53466237
2024-04-24T05:41:14.638Z **BROKEN** lightningd: backtrace: lightningd/log.c:1035 (fatal) 0x562f534662e8
2024-04-24T05:41:14.638Z **BROKEN** lightningd: backtrace: lightningd/bitcoind.c:118 (bitcoin_plugin_error) 0x562f5342e371
2024-04-24T05:41:14.638Z **BROKEN** lightningd: backtrace: lightningd/bitcoind.c:394 (sendrawtx_callback) 0x562f5342ee20
2024-04-24T05:41:14.638Z **BROKEN** lightningd: backtrace: lightningd/plugin.c:593 (plugin_response_handle) 0x562f53495f2c
2024-04-24T05:41:14.638Z **BROKEN** lightningd: backtrace: lightningd/plugin.c:704 (plugin_read_json_one) 0x562f53496177
2024-04-24T05:41:14.638Z **BROKEN** lightningd: backtrace: lightningd/plugin.c:749 (plugin_read_json) 0x562f53496357
2024-04-24T05:41:14.638Z **BROKEN** lightningd: backtrace: ccan/ccan/io/io.c:59 (next_plan) 0x562f535ae6c3
2024-04-24T05:41:14.638Z **BROKEN** lightningd: backtrace: ccan/ccan/io/io.c:407 (do_plan) 0x562f535af26d
2024-04-24T05:41:14.638Z **BROKEN** lightningd: backtrace: ccan/ccan/io/io.c:417 (io_ready) 0x562f535af2ab
2024-04-24T05:41:14.638Z **BROKEN** lightningd: backtrace: ccan/ccan/io/poll.c:453 (io_loop) 0x562f535b14c1
2024-04-24T05:41:14.638Z **BROKEN** lightningd: backtrace: lightningd/io_loop_with_timers.c:22 (io_loop_with_timers) 0x562f5345bc9a
2024-04-24T05:41:14.638Z **BROKEN** lightningd: backtrace: lightningd/lightningd.c:1332 (main) 0x562f53462878
2024-04-24T05:41:14.638Z **BROKEN** lightningd: backtrace: ../sysdeps/nptl/libc_start_call_main.h:58 (__libc_start_call_main) 0x7fc78957d249
2024-04-24T05:41:14.638Z **BROKEN** lightningd: backtrace: ../csu/libc-start.c:360 (__libc_start_main_impl) 0x7fc78957d304
2024-04-24T05:41:14.638Z **BROKEN** lightningd: backtrace: (null):0 ((null)) 0x562f5342c419
2024-04-24T05:41:14.638Z **BROKEN** lightningd: backtrace: (null):0 ((null)) 0xffffffffffffffff

Tor RPC bitcoind

Can I connect to my node behind Tor?

Tests

In the future the plugin repo will require plugins to have tests that can be run in CI. Please add tests for your plugin using pyln-testing

lightningd: SQLITE version mismatch: compiled 3031001, now 3035005

Installed using,
https://github.com/fiatjaf/trustedcoin#extra-how-to-bootstrap-a-lightning-node-from-scratch-without-bitcoin-core-on-ubuntu-amd64

After a server restart, now getting lightningd: SQLITE version mismatch: compiled 3031001, now 3035005

Found this, ElementsProject/lightning#1497

Do I need to recompile trustedcoin_linux_amd64?

Whats the safest way to get it running?

plugin-trustedcoin getblock error

Hello all, thanks for the plugin we have been using it with our LNBits server for months now. Just recently it keeps on shutting down on us. We went into our terminal again to start lightningd again and we now see this error as it tries to return blocks

plugin-trustedcoin getblock error: readScript: script witness item is larger than the max allowed size [count 33970, max 11000]

any thoughts to help out would be much appreciated

Occasional RPC error when running offline

When starting trustedcoin in an offline environment, it sometimes fails with:

error: bad response to getchaininfo (bad 'result' field: Parsing '{result:': object does not have member result), response was {"jsonrpc":"2.0","id":"cln:getchaininfo#15","error":{"code":20,"message":"failed to get tip: Get \"https://mempool.space/api/blocks/tip/height\": dial tcp: lookup mempool.space: no such host","data":null}}

This causes the clightning process to exit with a failure.

cc @seberm

`estimatefees` has changed in CLN version v23.05

estimatefees has changed in CLN version v23.05.

See deprecated section in https://github.com/ElementsProject/lightning/blob/master/CHANGELOG.md#23051---2023-06-05-austin-texas-agreementatxa-ii.

The new spec is (https://github.com/ElementsProject/lightning/blob/master/doc/PLUGINS.md#estimatefees):

estimatefees

Polled by lightningd to get the current feerate, all values must be passed in sat/kVB.

The plugin must return feerate_floor (e.g. 1000 if mempool is
empty), and an array of 0 or more feerates. Each element of
feerates is an object with blocks and feerate, in
ascending-blocks order, for example:

{
	"feerate_floor": <sat per kVB>,
	"feerates": {
		{ "blocks": 2, "feerate": <sat per kVB> },
		{ "blocks": 6, "feerate": <sat per kVB> },
		{ "blocks": 12, "feerate": <sat per kVB> }
		{ "blocks": 100, "feerate": <sat per kVB> }
	}
}

lightningd will currently linearly interpolate to estimate between given blocks (it will not extrapolate, but use the min/max blocks values).

Bug in fee-retrieval logic

I have an intuition that it may be related to channel force-closes.

Oct 15 07:06:57 satoshis-box lightningd[30247]: plugin-trustedcoin returning block 652815, 0000000000000000000a22cf38…, 1415537 bytes
Oct 15 07:07:18 satoshis-box lightningd[30247]: panic: runtime error: invalid memory address or nil pointer dereference
Oct 15 07:07:18 satoshis-box lightningd[30247]: [signal SIGSEGV: segmentation violation code=0x1 addr=0x40 pc=0x746303]
Oct 15 07:07:18 satoshis-box lightningd[30247]: goroutine 393 [running]:
Oct 15 07:07:18 satoshis-box lightningd[30247]: main.getFeeRatesFromEsplora(0xc000326738, 0x0, 0x0)
Oct 15 07:07:18 satoshis-box lightningd[30247]:         /home/fiatjaf/comp/go/src/github.com/fiatjaf/lightningd-gjson-rpc/cmd/trustedcoin/estimatefees.go:23 +0x113
Oct 15 07:07:18 satoshis-box lightningd[30247]: main.main.func3(0xc0000b60f0, 0x0, 0x815e78, 0x0, 0x0, 0x0, 0x0)
Oct 15 07:07:18 satoshis-box lightningd[30247]:         /home/fiatjaf/comp/go/src/github.com/fiatjaf/lightningd-gjson-rpc/cmd/trustedcoin/main.go:90 +0x34
Oct 15 07:07:18 satoshis-box lightningd[30247]: github.com/fiatjaf/lightningd-gjson-rpc/plugin.handleMessage(0xc0000b60f0, 0xc0000582d0, 0xc000484f87, 0x3, 0x784060, 0xc0004
Oct 15 07:07:18 satoshis-box lightningd[30247]:         /home/fiatjaf/comp/go/src/github.com/fiatjaf/lightningd-gjson-rpc/plugin/plugin.go:204 +0x5c2
Oct 15 07:07:18 satoshis-box lightningd[30247]: created by github.com/fiatjaf/lightningd-gjson-rpc/plugin.(*Plugin).Listener
Oct 15 07:07:18 satoshis-box lightningd[30247]:         /home/fiatjaf/comp/go/src/github.com/fiatjaf/lightningd-gjson-rpc/plugin/plugin.go:182 +0xa7e
Oct 15 07:07:20 satoshis-box lightningd[30247]: txprepare: Lost connection to the RPC socket.
Oct 15 07:07:20 satoshis-box lightningd[30247]: keysend: Lost connection to the RPC socket.
Oct 15 07:07:20 satoshis-box lightningd[30247]: autoclean: Lost connection to the RPC socket.
Oct 15 07:07:20 satoshis-box systemd[1]: lightningd.service: Main process exited, code=dumped, status=6/ABRT
Oct 15 07:07:20 satoshis-box systemd[1]: lightningd.service: Failed with result 'core-dump'.

different/changing fee estimates

1. if you type lightning-cli estimatefees multiple times - the fees jump from one second to the other. i guess this is because the 3 esplora instances return different feerates
2. the estimates are different from what bitcoind would give as a backend which can lead to some side effects (peers not agreeing on fees for example, leading to closed channels)

the first point i could solve with just using one esplora backend (which kind of makes it less reliable if that backend goes bust, but would be kind of okay) - but i am not sure about the second point. would it be possible to use bitcoind for the estimatefees call and the esplora instances for the rest, especially getting the blocks? i would like to use trustedcoin with a pruned bitcoind backend

i also looked into btc-rpx-proxy (which would support getting missing blocks), but failed to run it on openbsd

edit: maybe i could use something like https://github.com/Toorop/go-bitcoind
edit2: maybe i can tweak trustedcoin itself here to get similar feerates