diff --git a/_posts/en/newsletters/2022-07-06-newsletter.md b/_posts/en/newsletters/2022-07-06-newsletter.md new file mode 100644 index 0000000000..1eeefd36bd --- /dev/null +++ b/_posts/en/newsletters/2022-07-06-newsletter.md @@ -0,0 +1,214 @@ +--- +title: 'Bitcoin Optech Newsletter #207' +permalink: /en/newsletters/2022/07/06/ +name: 2022-07-06-newsletter +slug: 2022-07-06-newsletter +type: newsletter +layout: newsletter +lang: en +--- +This week's newsletter summarizes discussions about long-term +block reward funding, alternatives to BIP47 reusable payment +codes, options for announcing LN channel splices, LN routing fee +collection strategies, and onion message rate limiting. Also included +are our regular sections with announcements of new software releases and +release candidates, plus summaries of notable changes to popular Bitcoin +infrastructure software. + +## News + +- **Long-term block reward funding:** in a thread on the Bitcoin-Dev + mailing list ostensibly about [covenants][topic covenants], it was + noted that Bitcoin's long term security currently depends on + demand for block space. That demand must generate transaction + fees to pay for Proof of Work (PoW) in excess of what an attacker + would be willing to purchase to disrupt Bitcoin users. Developer + Peter Todd [pointed out][todd subsidy] that this dependency could be + removed if the Bitcoin protocol were modified to include a perpetual + subsidy. Several respondents indicated that they thought the system + is better off without a perpetual subsidy, while others looked for + alternatives or apparent equivalencies such as [demurrage][]. + + As of this writing, the thread appears to consist of casual + conversation rather than advocacy for any particular proposal to + change Bitcoin in the near future. + +- **Updated alternative to BIP47 reusable payment codes:** developer + Alfred Hodler [posted][hodler new codes] to the Bitcoin-Dev mailing + list a proposal for an alternative to [BIP47][] that attempts to + address some of the issues found during its use in production. BIP47 + allows Alice to publish a payment code that anyone can use in + combination with their own keys to create an unlimited number of + private addresses for Alice that only they and Alice will know belong + to her, avoiding the worst problems of [address reuse][topic output + linking]. + + However, one of the problems with BIP47 is that the first + transaction from spender Bob to receiver Alice is a *notification + transaction* that uses a special address associated with the payment + code. This definitely leaks to third parties who know Alice's + payment code that someone is planning to start paying her. If Bob's + wallet isn't carefully designed to segregate funds used for + notification transactions, the transaction may also leak that Bob is + planning to pay Alice---reducing or possibly even eliminating the + benefits of BIP47. + + Hodler's scheme would be less likely to leak this information but it + would increase the amount of data a client implementing the protocol + would need to learn from the block chain, making it less suitable + for light clients. Ruben Somsen indicated several alternatives + that could also be investigated, including Somsen's silent + payments idea (see [Newsletter #194][news194 silent payments]), + Robin Linus's [2022 stealth addresses][] idea, and [previous + discussion][prauge bip47] posted to the mailing list about improving + upon BIP47. + +- **Announcing splices:** in a [PR][bolts #1004] and a + [discussion][osuntokun splice] on the Lightning-Dev mailing list, + developers discussed the best way to communicate that a channel that + was seemingly being closed onchain was in fact a [splice][topic + splicing] where funds were being added to the channel or removed from + it. + + One proposal was for nodes to simply not consider a channel closed + until some amount of time after its onchain closing transaction was + seen. This would give time for the announcement of the new + (post-splice) channel to propagate. In the interim, nodes would + still attempt to route payments through the seemingly-closed + channel, as a spliced channel would still be able to forward + payments with full LN security even before its new channel open + transaction received a suitable number of confirmations. + + Another proposal was to include a signal onchain as part of the + closing transaction that a splice was in progress, telling nodes + that they could continue trying to forward payments through it. + + The discussion had not come to a clear conclusion at the time this + summary was being written. + +- **Fundamental fee-collection strategies for LN forwarding nodes:** + developer ZmnSCPxj [summarized][zmnscpxj forwarding] three strategies + LN forwarding nodes can use in collecting fees for routing payments + (including the strategy of not collecting fees). ZmnSCPxj then + analyzes possible outcomes of the different strategies. This seems + related to his proposal for nodes to use routing fees to improve + payment success rates, see [Newsletter #204][news204 fee signal], + which also received significant [additional commentary][towns fee + signal] in the past week from Anthony Towns. + +- **Onion message rate limiting:** Bastien Teinturier + [posted][teinturier rate limit] a summary of an idea he attributes to + Rusty Russell for rate limiting [onion messages][topic onion + messages]. The proposal has each node store just an extra 32 bytes of + information for each of their peers that allows them to + Probabilistically punish peers who send too much traffic. The + suggested penalty is to just halve the rate limit for a peer relaying + too much traffic for about 30 seconds. It's acceptable if this + lightweight penalty is occasionally enforced against the wrong peer, + as may happen with this idea. The proposal also allows the originator + of a message to learn which downstream nodes are rate limiting their + messages (again probabilistically), giving them a chance to resend the + message by a different route. + + Olaoluwa Osuntokun [suggested][osuntokun onion pay] reconsideration + of his previous proposal for preventing abuse of onion messages by + charging for data relay, see [Newsletter #190][news190 onion pay]. + Replies from other developers as of this writing seemed to indicate + they first try the lightweight rate limiting to see if it works + before adding the complexity of payments for onion messages. + +## Releases and release candidates + +*New releases and release candidates for popular Bitcoin infrastructure +projects. Please consider upgrading to new releases or helping to test +release candidates.* + +- [LDK 0.0.109][] is a new release of this LN node library, which + includes both of the new features described for LDK in the *notable + changes* section below. + +## Notable code and documentation changes + +*Notable changes this week in [Bitcoin Core][bitcoin core repo], [Core +Lightning][core lightning repo], [Eclair][eclair repo], [LDK][ldk repo], +[LND][lnd repo], [libsecp256k1][libsecp256k1 repo], [Hardware Wallet +Interface (HWI)][hwi repo], [Rust Bitcoin][rust bitcoin repo], [BTCPay +Server][btcpay server repo], [BDK][bdk repo], [Bitcoin Improvement +Proposals (BIPs)][bips repo], and [Lightning BOLTs][bolts repo].* + +- [Bitcoin Core #24836][] adds a regtest-only RPC, `submitpackage`, to + help L2 protocol and application developers who intend to use + [package relay][topic package relay] in the future test their transactions against the + Bitcoin Core default package policy. The current policy is outlined + [here][packages doc]. This RPC can also be used to test future + additions and changes, such as the proposed package RBF rules. + +- [Bitcoin Core #22558][] adds support for [BIP371][]’s additional [PSBT][topic + psbt] fields (see [Newsletter #155][news155 psbt extensions]) for [taproot][topic taproot]. + +- [Core Lightning #5281][] adds support for specifying the `log-file` + configuration option multiple times to write to multiple log files. + +- [LDK #1555][] updates its pathfinding code to slightly prefer routing + through channels which advertise that they won't accept payments + larger than half the amount of money committed to the channel. This + is believed to provide a slight privacy improvement by limiting the + amount of balance information a third party can discover by probing a + channel (sending a payment ([HTLC][topic htlc]) they don't intend to + settle). If a set of payments up to the total amount of a channel can + be sent, then a prober can learn nearly the exact balance of the + channel by just trying different sets of payments until all parts are + accepted. However, if the set of payments which can be sent is limited to + half the channel balance, it's harder for the prober to determine + whether payments are being rejected because of a lack of funds on one + side of the channel or because of the self-imposed limit (the + `max_htlc_in_flight_msat` limit). The [BOLT2][] + `max_htlc_in_flight_msat` limit isn't gossiped, so LDK instead uses + each channel's gossiped [BOLT7][] `htlc_maximum_msat` value as a proxy + value. + +- [LDK #1550][] provides the ability for users to add a list of nodes to + a local banlist which will prevent pathfinding from routing payments + through those nodes. + +- [LND #6592][] adds a new `requiredreserve` RPC to the wallet subserver + that prints the number of satoshis the wallet is reserving in UTXOs it + unilaterally controls to fee bump [anchor outputs][topic anchor + outputs] if necessary. An additional `--additionalChannels` RPC + parameter, which takes an integer argument, reports the number of + satoshis the wallet will reserve if that number of additional channels + are opened. + +- [Rust Bitcoin #1024][] adds additional code for helping developers + work around the [`SIGHASH_SINGLE` "bug"][shs1] where the Bitcoin protocol + expects a value of `1` to be signed when the input containing the + `SIGHASH_SINGLE` signature has an index number higher than the index + number of any output in the transaction. + +- [BTCPay Server #3709][] adds support for pull payments to be received + via a [LNURL withdraw][]. + +- [BDK #611][] begins setting the nLockTime of new transactions to the + height of the most recent block by default, enabling [anti fee + sniping][topic fee sniping]. + +{% include references.md %} +{% include linkers/issues.md v=2 issues="24836,22558,5281,1555,1550,1024,3709,611,1004,6592" %} +[ldk 0.0.109]: https://github.com/lightningdevkit/rust-lightning/releases/tag/v0.0.109 +[lnurl withdraw]: https://github.com/fiatjaf/lnurl-rfc/blob/luds/03.md +[todd subsidy]: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-June/020551.html +[hodler new codes]: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-June/020605.html +[news194 silent payments]: /en/newsletters/2022/04/06/#delinked-reusable-addresses +[prauge bip47]: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-June/020549.html +[osuntokun splice]: https://lists.linuxfoundation.org/pipermail/lightning-dev/2022-June/003616.html +[zmnscpxj forwarding]: https://lists.linuxfoundation.org/pipermail/lightning-dev/2022-June/003617.html +[news204 fee signal]: /en/newsletters/2022/06/15/#using-routing-fees-to-signal-liquidity +[towns fee signal]: https://lists.linuxfoundation.org/pipermail/lightning-dev/2022-June/003624.html +[teinturier rate limit]: https://lists.linuxfoundation.org/pipermail/lightning-dev/2022-June/003623.html +[osuntokun onion pay]: https://lists.linuxfoundation.org/pipermail/lightning-dev/2022-June/003631.html +[news190 onion pay]: /en/newsletters/2022/03/09/#paying-for-onion-messages +[2022 stealth addresses]: https://gist.github.com/RobinLinus/4e7467abaf0a0f8a521d5b512dca4833 +[demurrage]: https://en.wikipedia.org/wiki/Demurrage_%28currency%29 +[shs1]: https://www.coinspect.com/capture-coins-challenge-1-sighashsingle/ +[packages doc]: https://github.com/bitcoin/bitcoin/blob/09f32cffa6c3e8b2d77281a5983ffe8f482a5945/doc/policy/packages.md +[news155 psbt extensions]: /en/newsletters/2021/06/30/#psbt-extensions-for-taproot diff --git a/_topics/en/fee-sniping.md b/_topics/en/fee-sniping.md index e4cab7f649..a1b2d0febb 100644 --- a/_topics/en/fee-sniping.md +++ b/_topics/en/fee-sniping.md @@ -46,6 +46,9 @@ optech_mentions: - title: "LDK #1531 begins using anti fee sniping for LN funding transactions" url: /en/newsletters/2022/06/29/#ldk-1531 + - title: "BDK #611 begins using anti fee sniping by default" + url: /en/newsletters/2022/07/06/#bdk-611 + ## Optional. Same format as "primary_sources" above # see_also: # - title: diff --git a/_topics/en/onion-messages.md b/_topics/en/onion-messages.md index d73fabda9b..9e98cf3d07 100644 --- a/_topics/en/onion-messages.md +++ b/_topics/en/onion-messages.md @@ -53,6 +53,9 @@ optech_mentions: - title: "Proposal to charge for onion message bandwidth" url: /en/newsletters/2022/03/09/#paying-for-onion-messages + - title: "Proposals to either rate limit or charge for onion messages" + url: /en/newsletters/2022/07/06/#onion-message-rate-limiting + ## Optional. Same format as "primary_sources" above # see_also: # - title: diff --git a/_topics/en/output-linking.md b/_topics/en/output-linking.md index ed5ab17283..0c0fd7063f 100644 --- a/_topics/en/output-linking.md +++ b/_topics/en/output-linking.md @@ -72,6 +72,9 @@ optech_mentions: - title: "Experimentation with silent addresses" url: /en/newsletters/2022/06/01/#experimentation-with-silent-payments + - title: "Updated alternative to BIP47 reusable payment codes" + url: /en/newsletters/2022/07/06/#updated-alternative-to-bip47-reusable-payment-codes + ## Optional. Same format as "primary_sources" above see_also: - title: Uneconomical outputs (dust) diff --git a/_topics/en/package-relay.md b/_topics/en/package-relay.md index 57a275b02c..ed5087bd55 100644 --- a/_topics/en/package-relay.md +++ b/_topics/en/package-relay.md @@ -74,6 +74,9 @@ optech_mentions: - title: "Continued discussion of proposed package relay BIP" url: /en/newsletters/2022/06/15/#continued-package-relay-bip-discussion + - title: "Bitcoin Core #24836 adds a regtest-only RPC, `submitpackage`, to help test package relay" + url: /en/newsletters/2022/07/06/#bitcoin-core-24836 + ## Optional. Same format as "primary_sources" above see_also: - title: CPFP fee bumping diff --git a/_topics/en/psbt.md b/_topics/en/psbt.md index c11dec3426..e4ffc0e1cb 100644 --- a/_topics/en/psbt.md +++ b/_topics/en/psbt.md @@ -183,6 +183,9 @@ optech_mentions: - title: "LND #6450 adds support for signing PSBTs that spend taproot outputs" url: /en/newsletters/2022/05/18/#lnd-6450 + - title: "Bitcoin Core #22558 adds support for BIP371's additional PSBT fields" + url: /en/newsletters/2022/07/06/#bitcoin-core-22558 + ## Optional. Same format as "primary_sources" above see_also: - title: Output Script Descriptors diff --git a/_topics/en/splicing.md b/_topics/en/splicing.md index 08c7c6777c..60c177e814 100644 --- a/_topics/en/splicing.md +++ b/_topics/en/splicing.md @@ -40,6 +40,9 @@ optech_mentions: - title: Draft specification for LN splicing based on interactive funding protocol url: /en/newsletters/2021/04/28/#draft-specification-for-ln-splicing + - title: "Discussion about the best way to gossip channel splices" + url: /en/newsletters/2022/07/06/#announcing-splices + ## Optional. Same format as "primary_sources" above # see_also: # - title: