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.
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
BIP321 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.
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
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.
Nathan Parker made a proposal aimed to solve block transaction spam problem. His idea is based on the premise that some miners might want to fill their blocks with placeholder high fee transactions at no cost.
The proposed solution would reward the fees of the current block to the miner of next block or some block in the future: