Bitcoin Optech newsletter #208 is here:
- summarizes discussion about half aggregation of schnorr signatures
- describes a workaround for protocols that can’t reliably use x-only pubkeys
- shares an idea of allowing deliberately slow LN payment forwarding
- recaps the "Manual block-relay-only connections with addnode" Bitcoin Core PR Review Club Meeting
- adds a Payment probes topic
Jonas Nick posted to the Bitcoin-Dev mailing list a draft BIP and blog post about half aggregation of Bitcoin’s schnorr signatures...
At the time, x-only public keys was thought to be an optimization with no significant tradeoffs, but later design work on OP_TAPLEAF_UPDATE_VERIFY (TLUV) revealed that x-only pubkeys required either computationally limiting the proposal or storing extra data in the block chain or UTXO set. The problem may affect other advanced uses of pubkeys as well...
In a reply to a thread about recursive/nested MuSig2 (see Newsletter #204) and the latency that nodes using it would add when routing payments, developer Peter Todd asked on the Lightning-Dev mailing list whether it would “be worthwhile to allow people to opt-in to their payments happening more slowly for privacy?”
Payment probes are packets designed to discover information about the LN channels they travel through, such as whether the channel can currently handle a payment of a certain size or how many bitcoins are allocated to each participant in the channel...
The social network of the future: No ads, no corporate surveillance, ethical design, and decentralization! Own your data with Mastodon!