Peer to Peer messaging is already applied in Bitcoin courtesy of BIP 151, but the current way it is applied is inefficient and insecure, currently messages transported are non-encrypted so message tampering, block delay attacks and BGP hijacks are all valid threats using man in the middle attacks. A new BIP is aiming at adding opportunistic encryption using ChaCha20 as a cipher and Poly1305 as a message authentication code, which has been lately getting adopted in many state of the art protocol encryption schemes such as Wireguad and tinyssh.

The computation power required for encrypting and authenticating a message using these algorithms would be almost as much the current double-SHA256 checksum.

Excellent tutorial on how to setup a lightning node using Blockstream’s c-lightning over Tor on a Linux system.

Read the full tutorial here

Blockstream published a few updates to its block explorer that was launched last year 2018. The most obvious of the changes is the enabling of address search with unlimited transactions. Although it takes more disk space, that has led to increased search speed for the explorer. Secondly, disabling Java Script has also been made possible to allow for more browsing privacy as Java Script can be used to remove anonymity of users especially those using Tor, to improve user experience significantly. Thirdly, an API endpoint and a web form have been added to enable transaction broadcasting, a feature that developers or users who may want to easily broadcast transactions to the Bitcoin Network may find useful.

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

On of the pros of Bitcoin since its birth is that it’s a public ledger, anyone is allowed to send and receive payments and data on the Blockchain. However, Bitcoin’s network does not provide a way of encrypting communication between nodes, which allows manipulation of data, mass surveillance and analysis of its users.

Although encrypted communication is currently a possibility with VPNs, TOR or other mechanisms, it is not easy for the average user to setup such a connection. There is BIP draft called BIP151 that aims to add encrypted communication to Bitcoin’s network and which currently seems implemented only by Armory.

Jonas Schnelli presented an overhauled version for BIP 151 with some major changes: