profile
viewpoint
Rene Pickhardt renepickhardt http://www.rene-pickhardt.de Self-employed Data Science Consultant (ML & NLP & Analytics), hacker, open (source, education, access, data,...) activist, bitcoin & lightning network admirer

ElementsProject/lightning 1776

c-lightning — a Lightning Network implementation in C

renepickhardt/generalized-language-modeling-toolkit 49

Generalized Language Modeling toolkit

renepickhardt/graphity-evaluation 30

Graphity is a graph data base index (currently based on @neo4j) that supports fast retrieval of social news stream like twitter / facebook. Its runtime depends only linear on the amount of retrieved items. It thus scales! This repo contains the source code of graphity together with an evaluation frame work against several baselines.

renepickhardt/lightning-helpers 22

A growing collections of shell scripts which ease the running of c-lightning c.f.: https://github.com/ElementsProject/lightning

renepickhardt/HackALapp 14

⚡Lightning Network Paywall App with c-lightning & Python in 5 Minutes! #HackALapp ⚡ video: https://www.youtube.com/watch?v=HXVDwRnU7_I and free course

renepickhardt/c-lightning-plugin-collection 13

A collection of c-lightning plugins which are ready to use for your lightning network node.

renepickhardt/dnc-email-crunching 7

analyzing the DNC-Email Corpus released on wikileaks

renepickhardt/Automatically-Generating-a-Robust-Topology-for-the-Lightning-Network-on-top-of-Bitcoin 5

trying to fix https://github.com/lightningnetwork/lnd/issues/677 and contribute my 2 cents to the lightning network

renepickhardt/Imbalance-measure-and-proactive-channel-rebalancing-algorithm-for-the-Lightning-Network 3

We introduce a statistical measure for the imbalance of Lightning Network Nodes and provide a greedy algorithm for nodes to selfishly decrease their imbalance which has positive effects for routing random payments

GollumEvent

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 2 hours

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

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

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

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

issue commentElementsProject/lightning

Multiple channels not supported

Thanks to @niftynei's efforts we have an experimental implementation of dual-funding (compile with EXPERIMENTAL_FEATURES=1). Once the specification is finalized we expect other implementations to implement the proposal as well.

peername

comment 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

PR opened ElementsProject/lightning

hsmtool: fix a segfault on `dumponchaindescriptors` default network parameter

fixes https://github.com/ElementsProject/lightning/issues/4339

+2 -2

0 comment

1 changed file

pr 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

issue commentElementsProject/lightning

Change sqlite page_size to 4096 - massive performance improvement

Suggest separate thread, maybe link some of the relevant text in this thread. Some of the other SCAN TABLEs in the query plan might be worth pursuing but as per my analysis the expected speed increase would be significantly lower.

I could create a short document for tweaking parameters of your SQLITE based on the underlying filesystem characteristics.

mb300sd

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

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)

Good point, I'm fine with either, since this is at runtime only and doesn't change the backup files.

Feel free to switch it around if that makes it easier to rebase.

Sorry for breaking your PR by merging this. I'll review #189 asap.

cdecker

comment created time in 8 hours

pull request commentlightningd/plugins

feeadjuster: no underscore in method name

@m-schmoock Ok, understood. I will submit a PR later today.

gallizoltan

comment created time in 8 hours

pull request commentlightningd/plugins

rebalance: better feeadjuster integration

Just looks a bit clunky ;)

* b80c558 (origin/master, origin/HEAD, master) rebalance: better feeadjuster integration - turns off feeadjuster's automatic fee updates while rebalance running - runs feeadjust only once, at the end - measures time for rebalance
* 7c88402 feeadjuster: no underscore in method name

Ok, I think I just hit one Enter in the commit message instead of two. Will do better next time.

gallizoltan

comment created time in 8 hours

more