profile
viewpoint
Jonas Nick jonasnick https://nickler.ninja GPG 36C7 1A37 C9D9 88BD E825 08D9 B1A7 0E4F 8DCD 0366

fort-nix/nix-bitcoin 142

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

jonasnick/A-star 24

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.

jonasnick/eth-neg-value-tx 14

Ethereum Bug Bounty Submission: Sending Negative Value Transactions

jonasnick/bitcoin-node 9

"How to Run a Bitcoin Node" handout

apoelstra/zkstuff 6

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 😄

harding

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.

harding

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.

harding

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. :(

harding

comment created time in an hour

fork shesek/descriptor-wallet

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.

cdecker

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

harding

comment created time in 2 hours

issue commentbitcoin-core/secp256k1

ULL constants are not C89

long long is specified in C99, so possible fix would be just to replace C89 with C99 in the readme

real-or-random

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

Fix lnd nodeinfo

The Cirrus CI bug that caused a failure for this PR has now been fixed.

sputn1ck

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.

harding

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.)

sipa

comment created time in 6 hours

push eventlightningd/plugins

Michael Schmoock

commit sha 92aafe7404863d13da7810fe01ca5292e5fc5dc9

chore: rename feeadjustertoggle to feeadjuster-toggle

view details

push time in 7 hours

PR merged lightningd/plugins

chore: renames RPC feeadjusttoggle to feeadjust-toggle

After small chat with cdecker, using dash/minus in RPC name is good and will be translated to underscore in pyln on the fly.

+4 -4

4 comments

2 changed files

m-schmoock

pr closed 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.

I think the current feeadjuster-toggle is good in the code. Maybe the commit message could be more precise, but does not matter.

m-schmoock

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.

m-schmoock

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.

m-schmoock

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
harding

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 ...

m-schmoock

comment created time in 7 hours

PR opened lightningd/plugins

chore: renames RPC feeadjusttoggle to feeadjust-toggle

After small chat with cdecker, using dash/minus in RPC name is good and will be translated to underscore in pyln on the fly.

+4 -4

0 comment

2 changed files

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.

gallizoltan

comment created time in 7 hours

PR closed lightningd/plugins

rebalance: improve the feeadjust availability check

This can be done without invoking RPC help. Sorry I didnt get this earlier ;)

+2 -4

4 comments

1 changed file

m-schmoock

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?

m-schmoock

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")))
m-schmoock

comment created time in 8 hours

pull request commentlightningd/plugins

rebalance: improve the feeadjust availability check

Looks good to me, thanks! :)

m-schmoock

comment created time in 8 hours

pull request commentlightningd/plugins

rebalance: improve the feeadjust availability check

@gallizoltan does this also work for you?

m-schmoock

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

gallizoltan

comment created time in 8 hours

PR opened lightningd/plugins

rebalance: improve the feeadjust availability check

This can be done without invoking RPC help. Sorry I didnt get this earlier ;)

+2 -4

0 comment

1 changed file

pr created time in 8 hours

more