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.

A proposal by Lisa Neigut allowing LN nodes advertise their willingness to provide incoming capacity in exchange of fees in a “market” of advertised liquidity rates. This would help merchants to have access to incoming capacity which they need in order to receive payments from customers. The current alternatives would be either for customers to wait for on-chain confirmations and open a new channel or for merchants to make arrangements with other merchants that offer channel liquidity.

Follow the discussion here

Alejandro Ranchal Pedrosa and Tucci-Piergiovanni proposed a new BIP to extend OP_CSV¹ and/or OP_CLTV² to allow and interpret negative values.

The discussion that followed concluded that the BIP would be breaking a fundamental rule which is that valid transactions remain valid. This could lead to loss of funds when several transactions are made invalid.

One of the core components of Bitcoin is the Digital signature algorithms, it is used in making public keys out of private keys, signing transactions and in multisig transactions. Bitcoin so far has been using Elliptic Curve Digital Signature Algorithm ECDSA, for the past few months developers in the Bitcoin community have been talking about changing this algorithm into another one called Schnorr Signatures.

Schnorr is another signing algorithm that bring multiple benefits to the table. A new BIP was recently submitted by Peter Wuille about the changes that should happen in the future to Bitcoin’s signing algorithm with all the bells and whistles it should bring. The security of Schnorr is easily provable given a certain assumption, this is not the case for ECDSA.

Extended private keys are defined in BIP32¹ and are used to recover funds in case of a loss, but recovering a wallet using just the extended private keys is a tricky process and can sometimes fail to recover all the funds as some metadata can be missing. The current implemenation also has a weakness in which there is a limit to the incoming payment requests, handing out more than 20 incoming payment requests could lead to destruction of funds.

To remedy this issue, an early draft of a new serialization/encoding format for extended public and private keys was proposed on the Bitcoin-dev channel.

A programmer and researcher, Brad Denby who’s team formerly proposed a BIP called Dandelion, published an update to the project.

We’re writing with an update on the Dandelion project. As a reminder, Dandelion is a practical, lightweight privacy solution that provides Bitcoin users formal anonymity guarantees. While other privacy solutions aim to protect individual users, Dandelion protects privacy by limiting the capability of adversaries to deanonymize the entire network.

A new bitcoin improvement protocol was proposed on the bitcoin-dev mailing list.

I have written a new BIP describing a BIP32 derivation path that supports a single or multi-signature and multi-coin wallet from a single master seed. It combines BIP44 and BIP45 and adds in a self-describing structure in the derivation path for multiple multi-sig combinations within the single wallet along with an extended public key export file format for public key distribution between parties. I can particularly see this being useful for multiple Lightning Network 2of2 accounts for different payment channels.

Following the discussion that happened around tyzbit’s proposal on advertising lightning nodes via DNS records, he followed up with a proposal that aims to provide human readable, secure and decentralized “names” and arbitrary data on the blockchain while solving Zook’s DCS triangle

I have been working on a proposal called Numerifides which would provide a general method to register human-readable names and arbitrary data (such as username->GPG key, domain->IP address, Lightning node Alias-> URI, etc).

Here are the key highlights:

• New transaction type called “numerifides” transactions
• Lock up Bitcoin for a certain amount of time to make the mappings valid, discourage “namesquatting”
• Transaction puzzle attached to transactions to allow community consensus revocation of highly contested names or “squatted” name mappings.
• Transactions are RBF so if name is contentious or miners wish to censor, one honest greedy miner can include the censored user’s high-fee transaction)
• Solves Zooko’s triangle of Secure, Decentralized and Human Meaningful

Two weeks ago, Corné Plooy published a draft for a promising protocol improvement to Bolt-11 called Bolt-12: Payment Protocol For Lightning.

I was thinking of how to use Lightning for various types of payments, and I think it’s currently fine for customer/(web)shop type interactions, but it seems a bit inconvenient for other use cases, e.g. salary payments or direct pay-out of cryptocurrency bought on an exchange. I came up with an idea that addresses some of these issues and more (e.g. payee anonymity) by having a direct line of communication between payer and payee instead of BOLT11-style interaction

tyzbit made a proposal last week that would allow Ligntning node operators to advertise their nodes using DNS (Domain Name System). Quote:

A challenge end-users face is connecting to nodes with enough liquidity to pay every merchant, and failing that, finding the merchant node in a reasonably sane way to open a channel to them for payments.

As it is now, people find nodes in other people’s visualizers, and pass node aliases around via word of mouth which is very prone to inaccuracy and MITM attacks. A current alternative is attempting to make a payment, decoding the payment request, finding the node on your graph and attempting to open a channel to the merchant. This is only possible if the destination is advertising addresses.