A collection of Nix packages and NixOS modules for easily installing full-featured Bitcoin nodes with an emphasis on security.
ElementsProject/scriptless-scripts 94
Documentation about scriptless scripts
ElementsProject/rust-elements 24
Rust support for Elements transaction/block deserialization
Straightforward A* implementation in Java
jonasnick/ecdsaPredictableNonce 18
Ethereum Bug Bounty Submission: Breaking ecdsa that uses `privKey xor message` as nonce.
jonasnick/bitcoinconsensus_testcases 14
These testcases are generated by running afl-fuzz against libbitcoinconsensus.
Ethereum Bug Bounty Submission: Sending Negative Value Transactions
"How to Run a Bitcoin Node" handout
Random collection of zero-knowledge stuff
Pull request review commentbitcoinops/bitcoinops.github.io
Newsletters: add 132 (2021-01-20)
+---+title: 'Bitcoin Optech Newsletter #132'+permalink: /en/newsletters/2021/01/20/+name: 2021-01-20-newsletter+slug: 2021-01-20-newsletter+type: newsletter+layout: newsletter+lang: en+---+This week's newsletter summarizes posts to the Bitcoin-Dev mailing list+about payjoin adoption and making hardware wallets compatible with more+advanced Bitcoin features. Also included are our regular sections with+overviews of changes to services and client software, new releases and+release candidates, and changes to popular Bitcoin infrastructure+software.++## News++- **Payjoin adoption:** Chris Belcher [posted][belcher payjoin] to the+ Bitcoin-Dev mailing list a request for people to look for ways to+ increase [payjoin][topic payjoin] adoption along with a [wiki+ page][payjoin wiki] tracking the projects that provide either sending+ or receiving support for payjoin. One [suggestion][raw payjoin] by+ Craig Raw was to extend the protocol to allow it to work even when the+ receiver doesn't operate a server.++- **Making hardware wallets compatible with more advanced Bitcoin features:**+ Kevin Loaec [started a discussion][loaec hww] on the Bitcoin-Dev+ mailing list about how hardware wallets could be changed to allow them+ to handle scripts more complicated than single-sig or multisig. For+ example, allowing a hardware wallet to handle in-channel LN payments+ or payments made from a [vault][topic vaults]. His post does a good+ job of describing various problems that current hardware wallets can't+ handle, but he notes that necessary "changes may be very difficult".
Given that @harding writes in American English though, the quote before the period would have received red ink corrections on any paper I submitted in the US 😄
comment created time in an hour
Pull request review commentbitcoinops/bitcoinops.github.io
Newsletters: add 132 (2021-01-20)
+---+title: 'Bitcoin Optech Newsletter #132'+permalink: /en/newsletters/2021/01/20/+name: 2021-01-20-newsletter+slug: 2021-01-20-newsletter+type: newsletter+layout: newsletter+lang: en+---+This week's newsletter summarizes posts to the Bitcoin-Dev mailing list+about payjoin adoption and making hardware wallets compatible with more+advanced Bitcoin features. Also included are our regular sections with+overviews of changes to services and client software, new releases and+release candidates, and changes to popular Bitcoin infrastructure+software.++## News++- **Payjoin adoption:** Chris Belcher [posted][belcher payjoin] to the+ Bitcoin-Dev mailing list a request for people to look for ways to+ increase [payjoin][topic payjoin] adoption along with a [wiki+ page][payjoin wiki] tracking the projects that provide either sending+ or receiving support for payjoin. One [suggestion][raw payjoin] by+ Craig Raw was to extend the protocol to allow it to work even when the+ receiver doesn't operate a server.++- **Making hardware wallets compatible with more advanced Bitcoin features:**+ Kevin Loaec [started a discussion][loaec hww] on the Bitcoin-Dev+ mailing list about how hardware wallets could be changed to allow them+ to handle scripts more complicated than single-sig or multisig. For+ example, allowing a hardware wallet to handle in-channel LN payments+ or payments made from a [vault][topic vaults]. His post does a good+ job of describing various problems that current hardware wallets can't+ handle, but he notes that necessary "changes may be very difficult".
My feedback is based on grammar correctness in English; I'm not aware of a difference between American and British usage here, but could be wrong.
comment created time in an hour
Pull request review commentbitcoinops/bitcoinops.github.io
Newsletters: add 132 (2021-01-20)
+---+title: 'Bitcoin Optech Newsletter #132'+permalink: /en/newsletters/2021/01/20/+name: 2021-01-20-newsletter+slug: 2021-01-20-newsletter+type: newsletter+layout: newsletter+lang: en+---+This week's newsletter summarizes posts to the Bitcoin-Dev mailing list+about payjoin adoption and making hardware wallets compatible with more+advanced Bitcoin features. Also included are our regular sections with+overviews of changes to services and client software, new releases and+release candidates, and changes to popular Bitcoin infrastructure+software.++## News++- **Payjoin adoption:** Chris Belcher [posted][belcher payjoin] to the+ Bitcoin-Dev mailing list a request for people to look for ways to+ increase [payjoin][topic payjoin] adoption along with a [wiki+ page][payjoin wiki] tracking the projects that provide either sending+ or receiving support for payjoin. One [suggestion][raw payjoin] by+ Craig Raw was to extend the protocol to allow it to work even when the+ receiver doesn't operate a server.++- **Making hardware wallets compatible with more advanced Bitcoin features:**+ Kevin Loaec [started a discussion][loaec hww] on the Bitcoin-Dev+ mailing list about how hardware wallets could be changed to allow them+ to handle scripts more complicated than single-sig or multisig. For+ example, allowing a hardware wallet to handle in-channel LN payments+ or payments made from a [vault][topic vaults]. His post does a good+ job of describing various problems that current hardware wallets can't+ handle, but he notes that necessary "changes may be very difficult".
We discussed the order of quotation mark and fullstop on a previous newsletter, but I don't remember whether there was a general ruling on it. In German, punctuation only goes inside the quotation marks when it belongs to the quoted sequence, e.g. when it's a question or a whole sentence is part of the quote. When the punctuation belongs to the carrier sentence, it belongs outside of the quotation marks. I think this may also differ between British English and American English. I would have considered it correct before this suggestion.
comment created time in 2 hours
Pull request review commentbitcoinops/bitcoinops.github.io
Newsletters: add 132 (2021-01-20)
+---+title: 'Bitcoin Optech Newsletter #132'+permalink: /en/newsletters/2021/01/20/+name: 2021-01-20-newsletter+slug: 2021-01-20-newsletter+type: newsletter+layout: newsletter+lang: en+---+This week's newsletter summarizes posts to the Bitcoin-Dev mailing list+about payjoin adoption and making hardware wallets compatible with more+advanced Bitcoin features. Also included are our regular sections with+overviews of changes to services and client software, new releases and+release candidates, and changes to popular Bitcoin infrastructure+software.++## News++- **Payjoin adoption:** Chris Belcher [posted][belcher payjoin] to the+ Bitcoin-Dev mailing list a request for people to look for ways to+ increase [payjoin][topic payjoin] adoption along with a [wiki+ page][payjoin wiki] tracking the projects that provide either sending+ or receiving support for payjoin. One [suggestion][raw payjoin] by+ Craig Raw was to extend the protocol to allow it to work even when the+ receiver doesn't operate a server.++- **Making hardware wallets compatible with more advanced Bitcoin features:**+ Kevin Loaec [started a discussion][loaec hww] on the Bitcoin-Dev+ mailing list about how hardware wallets could be changed to allow them+ to handle scripts more complicated than single-sig or multisig. For+ example, allowing a hardware wallet to handle in-channel LN payments+ or payments made from a [vault][topic vaults]. His post does a good+ job of describing various problems that current hardware wallets can't+ handle, but he notes that necessary "changes may be very difficult".++## Changes to services and client software++*In this monthly feature, we highlight interesting updates to Bitcoin+wallets and services.*++- **Blockstream announces Jade hardware wallet:**+ Blockstream's [new Jade hardware wallet][blockstream jade blog] is open source,+ supports Bitcoin and Liquid networks, and is compatible with Blockstream Green+ for Android.++- **Coldcard adds payjoin signing:**+ Coldcard's [3.2.1 release][coldcard 3.2.1] adds [BIP78][] payjoin signing+ support and various multisig improvements.++- **Mempool v2.0.0 released:**+ Open source [block explorer][topic block explorers] mempool, which backs the
Ugh, I wish people would stop naming their companies and projects after concepts that exist in Bitcoin. :(
comment created time in an hour
Library for building descriptor-based bitcoin wallets
fork in an hour
Pull request review commentlightningd/plugins
backup: Add the ability to compact the backups
def read_metadata(self): def add_change(self, entry: Change) -> bool: typ = b'\x01' if entry.snapshot is None else b'\x02' if typ == b'\x01':- payload = b'\x00'.join([t.encode('UTF-8') for t in entry.transaction])+ stmts = [t.encode('UTF-8') if isinstance(t, str) else t for t in entry.transaction]+ payload = b'\x00'.join(stmts)
Thanks—yeah no problem, these changes are very contained and easy to port over.
comment created time in an hour
Pull request review commentbitcoinops/bitcoinops.github.io
Newsletters: add 132 (2021-01-20)
+---+title: 'Bitcoin Optech Newsletter #132'+permalink: /en/newsletters/2021/01/20/+name: 2021-01-20-newsletter+slug: 2021-01-20-newsletter+type: newsletter+layout: newsletter+lang: en+---+This week's newsletter summarizes posts to the Bitcoin-Dev mailing list+about payjoin adoption and making hardware wallets compatible with more+advanced Bitcoin features. Also included are our regular sections with+overviews of changes to services and client software, new releases and+release candidates, and changes to popular Bitcoin infrastructure+software.++## News++- **Payjoin adoption:** Chris Belcher [posted][belcher payjoin] to the+ Bitcoin-Dev mailing list a request for people to look for ways to+ increase [payjoin][topic payjoin] adoption along with a [wiki+ page][payjoin wiki] tracking the projects that provide either sending+ or receiving support for payjoin. One [suggestion][raw payjoin] by+ Craig Raw was to extend the protocol to allow it to work even when the+ receiver doesn't operate a server.++- **Making hardware wallets compatible with more advanced Bitcoin features:**+ Kevin Loaec [started a discussion][loaec hww] on the Bitcoin-Dev+ mailing list about how hardware wallets could be changed to allow them+ to handle scripts more complicated than single-sig or multisig. For+ example, allowing a hardware wallet to handle in-channel LN payments+ or payments made from a [vault][topic vaults]. His post does a good+ job of describing various problems that current hardware wallets can't+ handle, but he notes that necessary "changes may be very difficult".++## Changes to services and client software++*In this monthly feature, we highlight interesting updates to Bitcoin+wallets and services.*++FIXME:bitschidty++## Releases and release candidates++*New releases and release candidates for popular Bitcoin infrastructure+projects. Please consider upgrading to new releases or helping to test+release candidates.*++FIXME:harding to update Tuesday++- [Bitcoin Core 0.21.0][Bitcoin Core 0.21.0] is a the next major version+ of this full node implementation and its associated wallet and other+ software. Major new features include support for Tor version 3 hidden+ services using [version 2 `addr` messages][topic addr v2], the optional+ ability to serve [compact block filters][topic compact block filters],+ support for [signets][topic signet] (including the default signet+ which has [taproot][topic taproot] activated). It also offers+ experimental support for wallets that natively use [output script+ descriptors][topic descriptors]. For a complete list of changes, see+ the [release notes][bcc 0.21.0 notes].++- [Rust Bitcoin 0.26.0][] is a new release of this library. Major new+ features include support for signet, version 2 `addr` messages,+ and several improvements to [PSBT][topic psbt] handling. See its+ [release notes][rb notes] for details.++- [BTCPay Server 1.0.6.7][] in the second maintenance release to+ [1.0.6.5][btcpay server 1.0.6.5] from last week, which added "support+ [for] a subset of output descriptors in the wallet setup" (see the+ *notable changes* section below). Other features and bug fixes were+ also included.++- [C-Lightning 0.9.3rc2][c-lightning 0.9.3] is a release candidate for a+ new minor version of this LN node.++- [LND 0.12.0-beta.rc5][LND 0.12.0-beta] is the latest release candidate+ for the next major version of this LN node.++## Notable code and documentation changes++*Notable changes this week in [Bitcoin Core][bitcoin core repo],+[C-Lightning][c-lightning repo], [Eclair][eclair repo], [LND][lnd repo],+[Rust-Lightning][rust-lightning repo], [libsecp256k1][libsecp256k1+repo], [Hardware Wallet Interface (HWI)][hwi repo],+[Rust Bitcoin][rust bitcoin repo], [BTCPay Server][btcpay server repo],+[Bitcoin Improvement Proposals (BIPs)][bips repo], and [Lightning+BOLTs][bolts repo].*++- [Bitcoin Core #19937][] signet mining utility FIXME:jnewbery++- [LND #4917][] disables the use of [anchor outputs][topic anchor+ outputs] by default, a feature that was planned to be released in the+ upcoming 0.12.0-beta. Advanced users can still opt-in to using
Came here to say this as well
comment created time in 2 hours
issue commentbitcoin-core/secp256k1
long long is specified in C99, so possible fix would be just to replace C89 with C99 in the readme
comment created time in 3 hours
starteddiscreetlogcontracts/dlcspecs
started time in 4 hours
startedparitytech/polkadot-launch
started time in 5 hours
pull request commentfort-nix/nix-bitcoin
The Cirrus CI bug that caused a failure for this PR has now been fixed.
comment created time in 5 hours
pull request commentbitcoinops/bitcoinops.github.io
Newsletters: add 132 (2021-01-20)
Pushed my write up of Bitcoin Core 19937.
comment created time in 6 hours
issue commentsipa/bips
BIP340: clarify impact of pre-hashed messages, or support variable-length messages
@rustyrussell
The clear guidance in BIP-340 was a delight. This was a fairly simple process, and I know how to optimize it later.
Just for my understanding: What guidance are you referring to? The current BIP does not (yet) provide guidance on how to handle variable-length messages.
It does: it tells you to hash it and prepend a tag :)
Well, not really. BIP340 defines a tagged hash function hash_tag(x)
and uses it internally. It doesn't say you should use this function to preprocess your messages. (Not that it matters for the discussion -- the BIP could of course to changed to say this and I see that this is your suggestion.)
@LLFourn
Of course we are only talking about nanoseconds here but having the standard way of signing arbitrary messages being variable length and therefore unoptimizable is good way to stop people wasting their time pre-computing things.
True and I don't even think that these optimizations in the nanosecond range are the most interesting thing here. Pre-hashing the messages potentially degrades the security of the signature scheme because then we need collision resistance instead of random-prefix preimage resistance and random-prefix second preimage resistance. This was one of the main motivations to discuss this (see initial comment in this issue). I don't think we should simply throw away this potential security benefit (and this is why I'd prefer not to recommend what the lightning spec does). This is in the line of @sipa's suggestion in https://github.com/sipa/bips/issues/207#issuecomment-673681901.
By the way, here's what the EdDSA RFC says, which specifies Ed25519, Ed25519ph (=prehashed), Ed25519ctx (=context, what we call tag) in the relevant sections: https://www.rfc-editor.org/rfc/rfc8032.html#section-4 (This brings up another aspect, namely "single pass".) https://www.rfc-editor.org/rfc/rfc8032.html#section-8.3 These many variants are really confusing... Idk. With that in mind, I tend to think that keeping the possible variants out of the formal spec (and just as a recommendation)is actually a good idea. Then users can and will still do what they want but at least every API implementing BIP340 will be compatible with it.
In my view that is worth adding complexity to the BIP but I don't feel too strongly about it anymore.
So, it's easier to have a discussion about concrete proposals. What's your proposal? (Sorry if the answer to that question can be found somewhere above. I'm somewhat lost in this discussion, and I feel I'm not the only one. But this feeling should not discourage us from having the discussion.)
comment created time in 6 hours
push eventlightningd/plugins
commit sha 92aafe7404863d13da7810fe01ca5292e5fc5dc9
chore: rename feeadjustertoggle to feeadjuster-toggle
push time in 7 hours
PR merged lightningd/plugins
After small chat with cdecker, using dash/minus in RPC name is good and will be translated to underscore in pyln on the fly.
pr closed time in 7 hours
pull request commentlightningd/plugins
chore: renames RPC feeadjusttoggle to feeadjust-toggle
Also: do we want
feeadjuster-toggle
orfeeadjust-toggle
? I tend to the first. Second one is only better if we rename the whole plugin, which I dont like.
I think the current feeadjuster-toggle
is good in the code. Maybe the commit message could be more precise, but does not matter.
comment created time in 7 hours
pull request commentlightningd/plugins
chore: renames RPC feeadjusttoggle to feeadjust-toggle
tACK fb05a96
Now I can call feeadjuster-toggle
(with dash) from command line and feeadjuster_toggle
(with underscore) from python RPC.
comment created time in 7 hours
pull request commentlightningd/plugins
chore: renames RPC feeadjusttoggle to feeadjust-toggle
Also: do we want feeadjuster-toggle
or feeadjust-toggle
? I tend to the first. Second one is only better if we rename the whole plugin, which I dont like.
comment created time in 7 hours
Pull request review commentbitcoinops/bitcoinops.github.io
Newsletters: add 132 (2021-01-20)
+---+title: 'Bitcoin Optech Newsletter #132'+permalink: /en/newsletters/2021/01/20/+name: 2021-01-20-newsletter+slug: 2021-01-20-newsletter+type: newsletter+layout: newsletter+lang: en+---+This week's newsletter summarizes posts to the Bitcoin-Dev mailing list+about payjoin adoption and making hardware wallets compatible with more+advanced Bitcoin features. Also included are our regular sections with+overviews of changes to services and client software, new releases and+release candidates, and changes to popular Bitcoin infrastructure+software.++## News++- **Payjoin adoption:** Chris Belcher [posted][belcher payjoin] to the+ Bitcoin-Dev mailing list a request for people to look for ways to+ increase [payjoin][topic payjoin] adoption along with a [wiki+ page][payjoin wiki] tracking the projects that provide either sending+ or receiving support for payjoin. One [suggestion][raw payjoin] by+ Craig Raw was to extend the protocol to allow it to work even when the+ receiver doesn't operate a server.++- **Making hardware wallets compatible with more advanced Bitcoin features:**+ Kevin Loaec [started a discussion][loaec hww] on the Bitcoin-Dev+ mailing list about how hardware wallets could be changed to allow them+ to handle scripts more complicated than single-sig or multisig. For+ example, allowing a hardware wallet to handle in-channel LN payments+ or payments made from a [vault][topic vaults]. His post does a good+ job of describing various problems that current hardware wallets can't+ handle, but he notes that necessary "changes may be very difficult".++## Changes to services and client software++*In this monthly feature, we highlight interesting updates to Bitcoin+wallets and services.*++- **Blockstream announces Jade hardware wallet:**+ Blockstream's [new Jade hardware wallet][blockstream jade blog] is open source,+ supports Bitcoin and Liquid networks, and is compatible with Blockstream Green+ for Android.++- **Coldcard adds payjoin signing:**+ Coldcard's [3.2.1 release][coldcard 3.2.1] adds [BIP78][] payjoin signing+ support and various multisig improvements.++- **Mempool v2.0.0 released:**+ Open source [block explorer][topic block explorers] mempool, which backs the+ [mempool.space][mempool.space website] website, has released [version+ 2.0.0][mempool v2]. Mempool supports Bitcoin Core, Electrum, and Esplora+ backends and also exposes block, transaction, and address information via APIs.++- **BlueWallet adds multisig:**+ Version [6.0.0 of BlueWallet][bluewallet 6.0.0. tweet] adds the ability to+ create and manage air-gapped, native segwit multisig vaults.++- **Sparrow supports connecting to Bitcoin Core:**+ [Sparrow 0.9.10][sparrow 0.9.10], using [Bitcoin Wallet Tracker v0.2.1][bwt+ 0.2.1]'s Java Native Interface bindings feature, now supports connecting+ directly to a backing Bitcoin Core node.++## Releases and release candidates++*New releases and release candidates for popular Bitcoin infrastructure+projects. Please consider upgrading to new releases or helping to test+release candidates.*++FIXME:harding to update Tuesday++- [Bitcoin Core 0.21.0][Bitcoin Core 0.21.0] is a the next major version+ of this full node implementation and its associated wallet and other+ software. Major new features include support for Tor version 3 hidden+ services using [version 2 `addr` messages][topic addr v2], the optional+ ability to serve [compact block filters][topic compact block filters],+ support for [signets][topic signet] (including the default signet+ which has [taproot][topic taproot] activated). It also offers+ experimental support for wallets that natively use [output script+ descriptors][topic descriptors]. For a complete list of changes, see+ the [release notes][bcc 0.21.0 notes].++- [Rust Bitcoin 0.26.0][] is a new release of this library. Major new+ features include support for signet, version 2 `addr` messages,+ and several improvements to [PSBT][topic psbt] handling. See its+ [release notes][rb notes] for details.++- [BTCPay Server 1.0.6.7][] in the second maintenance release to+ [1.0.6.5][btcpay server 1.0.6.5] from last week, which added "support+ [for] a subset of output descriptors in the wallet setup" (see the+ *notable changes* section below). Other features and bug fixes were+ also included.++- [C-Lightning 0.9.3rc2][c-lightning 0.9.3] is a release candidate for a+ new minor version of this LN node.++- [LND 0.12.0-beta.rc5][LND 0.12.0-beta] is the latest release candidate+ for the next major version of this LN node.++## Notable code and documentation changes++*Notable changes this week in [Bitcoin Core][bitcoin core repo],+[C-Lightning][c-lightning repo], [Eclair][eclair repo], [LND][lnd repo],+[Rust-Lightning][rust-lightning repo], [libsecp256k1][libsecp256k1+repo], [Hardware Wallet Interface (HWI)][hwi repo],+[Rust Bitcoin][rust bitcoin repo], [BTCPay Server][btcpay server repo],+[Bitcoin Improvement Proposals (BIPs)][bips repo], and [Lightning+BOLTs][bolts repo].*++- [Bitcoin Core #19937][] signet mining utility FIXME:jnewbery++- [LND #4917][] disables the use of [anchor outputs][topic anchor+ outputs] by default, a feature that was planned to be released in the+ upcoming 0.12.0-beta. Advanced users can still opt-in to using+ anchors. The commit messages notes that, "the plan is to enable+ anchors by default [in a later release]."++- [Rust-Lightning #742][] improves the signer API by providing per-transaction+ information necessary for the signer to perform additional checks and provide+ a signature. This PR is part of a larger effort to support external signers in+ Rust-Lightning tracked [here][Rust-Lightning #408].++- [BTCPay Server #2169][] adds functions that provide support for+ decoding [output script descriptors][topic descriptors] referring to+ wallets created following BIPs [44][BIP44] (P2PKH HD wallets),+ [45][BIP45] (P2SH multisig HD wallets), [49][BIP49] (P2SH-P2WPKH HD+ wallets), [84][BIP89] (native P2WPKH HD wallets), and a [proposed
Bad link.
wallets), [84][BIP84] (native P2WPKH HD wallets), and a [proposed
comment created time in 7 hours
fork kerolsAtef/ReceptiveFields
Receptive Fields in the primary visual pathway applied to images
fork in 7 hours
pull request commentlightningd/plugins
chore: renames RPC feeadjusttoggle to feeadjust-toggle
@gallizoltan as mentioned earlier ...
comment created time in 7 hours
PR opened lightningd/plugins
After small chat with cdecker, using dash/minus in RPC name is good and will be translated to underscore in pyln on the fly.
pr created time in 7 hours
Pull request review commentlightningd/plugins
rebalance: better feeadjuster integration
def get_ideal_ratio(channels: list, enough_liquidity: Millisatoshi): def feeadjust_would_be_nice(plugin: Plugin):- try:+ commands = [c for c in plugin.rpc.help().get("help") if c["command"].split()[0] == "feeadjust"]
Update: doesn't seem to work, as rpc code generates method on the fly when getattr is called.
comment created time in 7 hours
PR closed lightningd/plugins
This can be done without invoking RPC help. Sorry I didnt get this earlier ;)
pr closed time in 7 hours
pull request commentlightningd/plugins
rebalance: improve the feeadjust availability check
print(callable(getattr(plugin.rpc, "this_function_does_not_exist")))
Hm, just tried and it gives me: plugin-rebalance.py: True
Do you know why?
comment created time in 7 hours
pull request commentlightningd/plugins
rebalance: improve the feeadjust availability check
What happens if I call this?
print(callable(getattr(plugin.rpc, "this_function_does_not_exist")))
comment created time in 8 hours
pull request commentlightningd/plugins
rebalance: improve the feeadjust availability check
Looks good to me, thanks! :)
comment created time in 8 hours
pull request commentlightningd/plugins
rebalance: improve the feeadjust availability check
@gallizoltan does this also work for you?
comment created time in 8 hours
Pull request review commentlightningd/plugins
rebalance: better feeadjuster integration
def get_ideal_ratio(channels: list, enough_liquidity: Millisatoshi): def feeadjust_would_be_nice(plugin: Plugin):- try:+ commands = [c for c in plugin.rpc.help().get("help") if c["command"].split()[0] == "feeadjust"]
See https://github.com/lightningd/plugins/pull/201
comment created time in 8 hours
PR opened lightningd/plugins
This can be done without invoking RPC help. Sorry I didnt get this earlier ;)
pr created time in 8 hours