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...
https://bitcoinops.org/en/newsletters/2022/07/13/#half-aggregation-of-bip340-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...
https://bitcoinops.org/en/newsletters/2022/07/13/#x-only-workaround
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?”
https://bitcoinops.org/en/newsletters/2022/07/13/#allowing-deliberately-slow-ln-payment-forwarding
Manual block-relay-only connections with addnode is a PR by Martin Zumsande to allow users to manually create connections with nodes on which only blocks (not transactions or peer addresses) are relayed. This option is intended to help prevent eclipse attacks, particularly for nodes running on privacy networks such as Tor.
https://bitcoinops.org/en/newsletters/2022/07/13/#bitcoin-core-pr-review-club
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...
