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.

Dual funding and splicing mechanisms allow initial negotiations between node to allow the node on the other end an opportunity to put funds at channel opening time or after it. Finding liquidity is a problem that had solutions suggested all the way back in November, the suggestion was, in summary, that a node will advertise initial liquidity matching via their node_announcement, this is meant to help these nodes source inbound capacity from a market of advertised liquidity rates as set by other nodes.

After a recent spec meeting, developer Rene Pickhardt noticed a potential privacy issue with this schema: a node can spam another probing for a lower bound for the amount of BTC available by this node, each time aborting the channel establishing before locking any of its own Bitcoin.

The Ledger Nano S’ firmware has been recently updated to 1.5.5, while this update brings several features like the support of Groestl and Blake2b as new hashes, Schnorr with Zilliqa as a new signature scheme, Bip32-ed25519 as a new derivation scheme and several other major security updates.

It also caused troubles for its owners wanting to update. As this firmware is slightly larger in size than old ones, HSM servers hosting this update became unresponsive as many users were simultaneously trying to update their device, causing access to the Manager and installing apps to be slower than usual, a significant amount of users reported their device getting stuck during the update which would be later addressed with another update and an apology from Ledger.

Recently developer James Hilliard, known for his BIP91 proposal (segwit upgrade), discovered a vulnerability in Bitmain’s Antminer S15 firmware, this was then turned into an exploit by independent security researcher under the twitter handle of @00whiterabbit.

The vulnerability allows a malicious hacker to remotely access the miner with SSH, allowing the attacker to flash a custom firmware without ever being in physical presence with the device. Flashing a firmware could cause an array of problems like decreasing its hash rate by underclocking its processors, shutting it down or even modifying the payout address of the miner, leaving thousands of miners vulnerable to basically anything the attacker desires under certain circumstances.

A fishing malware scheme has been spotted targeting electrum wallet users. Electrum users are advised to read the warning explainer that has been setup here.

Users of many versions of Electrum released may see messages as pictured when attempting to send a transaction with their wallet. The message, or some variation of, purports that a security update is required to continue.

This is not the case.

The message is generated by the server you are connected to, and contains a link to a malicious modification of the wallet which, if installed, will result in the immediate theft of all of your money. If you install any software shown in a message such as this you have no recourse to recover your funds.

Margherita Favaretto, a student working on remediation protocol for Lightning Network double-spend attacks asked for feedback for a proposed solution to double spend attacks using a “trusted remediation” gossip protocol.

ZmnSCPxj pointed out that double spend attacks are not possible on the Lightning Network unless both parties involved in the channel agree to it, which is not likely, first because the man at the other end of the channel will lose money. Secondly even if the other end of the channel is irrational enough to help the other guy double spend, they will still ask for an invoice and give the money using “existing invoice-payment mechanisms.” ZmnSCPxj added:

If the problem you are trying to solve, is the inadvertent publication of revoked commitment transactions, then the correct solution is not to have revocable transactions in the first place, i.e. eltoo. While it can be argued that it would take time for needed features of eltoo to appear on the blockchain layer (SIGHASH_NOINPUT_UNSAFE), it would also take time to implement “trusted remediation”, by which time the problem could be solved by switching over to eltoo.