Feed for tag: merges
Commit Activity For Thu, Nov 08
Notable issues and merges on Bitcoin Core, LND, c-lightning and libsecp256k1 Originally published by BitcoinOptech on newsletter #20 Bitcoin Core #14454 Adds support to the importmulti RPC for segwit addresses and scripts (P2WPKH, P2WSH, and P2SH-wrapped segwit). A new witnessscript parameter fulfills the same role for segwit as the redeemscript parameter for P2SH. Also a solvable parameter is added to the getaddressinfo RPC to let the user know whether the wallet knows the redeemScript or witnessScript for a P2SH or P2WSH address, i.
Commit Activity For Thu, Nov 01
Notable issues and merges on Bitcoin Core, LND, c-lightning and libsecp256k1 Originally published by BitcoinOptech on newsletter #19 Bitcoin Core #14451 Allows optionally building Bitcoin-Qt without support for the BIP70 payment protocol and adds a deprecation warning indicating the default support may be removed in a future release. The CEO of BitPay, which is the largest user of BIP70 (but which wants to use a different version of the protocol), indicated that they supported Bitcoin Core removing BIP70.
Commit Activity For Thu, Oct 25
Notable issues and merges on Bitcoin Core, LND, c-lightning and libsecp256k1 Originally published by BitcoinOptech on newsletter #18 Bitcoin Core #14291: For use with Bitcoin Core’s multiwallet mode, a new listwalletdir RPC can list all available wallets in the wallet directory. Bitcoin Core #14424: Fixes a likely regression in 0.17.0 for watch-only wallets that require users to import their public keys for multisig scripts (rather than just importing the script) in order for Bitcoin Core to attempt spending the script using RPCs such as fundrawtransaction with theincludeWatching flag.
Commit Activity For Thu, Oct 18
Notable issues and merges on Bitcoin Core, LND and c-lightning. Originally published by BitcoinOptech on newsletter #17 LND #1970: The AbandonChannel RPC method (only available in the developer debug mode) now provides additional information when users tell their node to abandon a payment channel (a method that can cause monetary loss if used carelessly). The additional information is enough to allow either restarting an open payment channel later or to prove that the program had enough information to make additional commitments to a now-closed payment channel.
Commit Activity For Thu, Oct 4
Notable issues and merges on Bitcoin Core, LND and c-lightning. Originally published by BitcoinOptech LND #1987: The NewWitnessAddress RPC has been removed and the NewAddress RPC now only supports generating addresses for P2SH-wrapped P2WKH and native P2WPKH. C-Lightning #1982: The invoice RPC now implements RouteBoost by including a BOLT11 r parameter in the invoice that provides routing information to the payer for an already-open channel that has the capacity to support paying the invoice.
Commit Activity For Thursday, Sep 27

Notable issues and merges on Bitcoin Core, LND and c-lightning.

Originall published by BitcoinOptech

Bitcoin Core #14305

After the discovery of a few cases where Python-based tests were passing incorrectly as a result of using misnamed variables, a variable name whitelist was implemented using Python 3’s __slots__ feature for classes.

Bitcoin Core #13152

When connected to the peer-to-peer network, nodes share the IP addresses of other nodes they’ve heard about and these addresses are stored in a database that Bitcoin Core queries when it wants to open a new connection. This PR adds a new RPC command,getnodeaddresses, that returns one or more of these addresses. This can be useful in conjunction with tools like bitcoin-submittx.

LND #1738

the logic for validating channel updates has been moved to the routing package so that it’s available both in routing (to handle failed payment sessions) and the gossiper (where it was handled before). This fixes issue #1707 (and implements a test case for it) that may have allowed a node to trick one of its peers into believing a different peer had a routing failure, thus possibly redirecting traffic to the malicious node.

C-Lightning

  • C-Lightning now provides a gossipwith tool that allows you to receive gossip from a node independently of lightningd or even to send the remote node a message. This tool is used for additional testing of lightningd’s gossip component. C-Lightning now provides a gossipwith tool that allows you to receive gossip from a node independently of lightningd or even to send the remote node a message. This tool is used for additional testing of lightningd’s gossip component.

  • C-Lightning now complies with updates to BOLT7 by splitting the previous flags field for the listchannels RPC into two new fields: message_flags and channel_flags. Also code comments and references to BOLT2 and BOLT11 have been updated.

  • C-Lightning has significantly expanded the in-code documentation of its secrets module. The documentation is remarkably good (and, at times, quite humorous). See hsmd.c. The code comments even document other code comments:

/*~ You'll find FIXMEs like this scattered through the code.
* Sometimes they suggest simple improvements which someone like
* yourself should go ahead an implement. Sometimes they're deceptive
* quagmires which will cause you nothing but grief. You decide!

*/ /* FIXME: We should cache these.*/
get_channel_seed(&c->id, c->dbid, &channel_seed);
derive_funding_key(&channel_seed, &funding_pubkey, &funding_privkey);
Commit Activity For Thursday, Sep 20

Notable issues and merges on Bitcoin Core, LND and c-lightning.

Bitcoin Core #14248 and #14249:

This was a fix to a denial-of-service vulnerability (CVE-2018-17144) exploitable by miners that has been discovered in Bitcoin Core versions 0.14.0 up to 0.16.2. It is recommended to upgrade any of the vulnerable versions to 0.16.3 as soon as possible. The fix was backported to the 0.16 branch.

Bitcoin Core #7965:

This week a long-standing issue that tracked the removal of code handling whether the wallet is compiled in the libbitcoin_server component was closed by the merge of #14168.

This issue is part of an ongoing long-term effort to separate the wallet related code from the server code, along with a number of issues such as #10973(separate wallet from node whose PR is still being reviewed) and #14180(Run all tests even if wallet is not compiled) which will provide many benefits such as easier code maintenance, more straightforward way to test individual components and overall could help for a more secure software if the wallet component is moved to its own process.

LND #1843

The configuration option --noencryptwallet that was originally intended only for testing has been renamed to --noseedbackup and has been marked as deprecated. The help text for the option has been updated to mostly uppercase warning text:

If true, NO SEED WILL BE EXPOSED AND THE WALLET WILL BE ENCRYPTED USING THE DEFAULT PASSPHRASE – EVER. THIS FLAG IS ONLY FOR TESTING AND IS BEING DEPRECATED.

This is intended for for users who might be using this option without realizing the real risk of losing money when using it.

NOTE: Any users that are actively using noencryptwallet will have to switch any scripts/confs to use noseedbackup as a result of this PR, though no further modification should be required.

LND #1516

This merge adds support for the v3 onion services available through Tor’s control port available since Tor v0.3.3.6. This will allow LND to automatically create and set up v3 onion services in addition to its exsiting v2 automation. For this to work users must have a running Tor service along side LND.

c-lightning #1963:

A series of patches that improve the cli and its help command by showing the command usage in the output. It also allows to verify a command without running it by using the check command:

lightning-cli check newaddr bech32

The above will check the parameter but won’t create a new address. It will just respond with “ok”.