From fda388755a9d6a21b75c726861177d7f14c2415f Mon Sep 17 00:00:00 2001 From: "David A. Harding" Date: Mon, 27 Jul 2020 06:31:33 -0400 Subject: [PATCH 1/5] Newsletters: add 108 (2020-07-29) --- .../en/newsletters/2020-07-29-newsletter.md | 197 ++++++++++++++++++ 1 file changed, 197 insertions(+) create mode 100644 _posts/en/newsletters/2020-07-29-newsletter.md diff --git a/_posts/en/newsletters/2020-07-29-newsletter.md b/_posts/en/newsletters/2020-07-29-newsletter.md new file mode 100644 index 0000000000..aef4816e1d --- /dev/null +++ b/_posts/en/newsletters/2020-07-29-newsletter.md @@ -0,0 +1,197 @@ +--- +title: 'Bitcoin Optech Newsletter #108' +permalink: /en/newsletters/2020/07/29/ +name: 2020-07-29-newsletter +slug: 2020-07-29-newsletter +type: newsletter +layout: newsletter +lang: en +--- +This week's newsletter describes a proposal to allow upgrading LN +channel commitment transaction formats without opening new channels. +Also included are our regular sections with selected questions and +answers from the Bitcoin StackExchange, recent releases and release +candidates, and notable changes to popular Bitcoin infrastructure +projects. + +## Action items + +*None this week.* + +## News + +- **Upgrading channel commitment formats:** Olaoluwa Osuntokun + [posted][osuntokun upgrade] to the Lightning-Dev mailing list this + week with a suggested extension to the LN specification that will + allow two peers with an existing channel to negotiate a + new commitment transaction using a different format. Commitment + transactions are used to allow LN nodes to publish the current channel + state on chain, but the existing protocol only allows nodes to upgrade + to new commitment formats by opening new channels. Osuntokun's + proposal would allow a node to signal to its peer that it wants to + switch formats. If the peer agrees, the two nodes would port their + existing channel state over to the new format and then use the new + format going forward. + + All discussion participants seemed to support the basic idea. + Bastien Teinturier [suggested][teinturier simple] that + it would be simplest to only allow switching commitment formats when + channels had no pending payments (HTLCs)---implying nodes would + need to pause sending or relaying payments in a particular channel + in order to upgrade it. + + ZmnSCPxj [noted][zmnscpxj re-funding] that the same basic idea could + be used to essentially update the funding transaction offchain, such + as the case where [taproot][topic taproot] + and [SIGHASH_ANYPREVOUT][topic sighash_noinput] are implemented, + allowing [Eltoo][topic eltoo]-based channel commitments to be used. In + ZmnSCPxj's proposal, the output of the existing funding transaction + would be paid to a new funding transaction that is kept offchain. If + the channel terminates with a mutual close, the original funding + transaction output is paid to the final channel balances; otherwise, + the offchain secondary funding transaction can be published onchain + and the channel can be resolved using the appropriate unilateral + close protocol. + +## Selected Q&A from Bitcoin StackExchange + +*[Bitcoin StackExchange][bitcoin.se] is one of the first places Optech +contributors look for answers to their questions---or when we have a +few spare moments to help curious or confused users. In +this monthly feature, we highlight some of the top-voted questions and +answers posted since our last update.* + +{% comment %}{% endcomment %} +{% assign bse = "https://bitcoin.stackexchange.com/a/" %} + +FIXME:bitschmidty + +## 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.* + +- [C-Lightning 0.9.0rc3][C-Lightning 0.9.0] is a release candidate for + an upcoming major release. It adds support for the updated `pay` + command and new `keysend` RPC described in [last week's + newsletter's][news107 notable] *notable code changes* section. It also + includes several other notable changes and multiple bug fixes. + +- [Bitcoin Core 0.20.1rc1][Bitcoin Core 0.20.1] is a release candidate + for an upcoming maintenance release. In addition to bug fixes and + some RPC behavior changes resulting from those fixes, the planned + release provides compatibility with recent versions of [HWI][topic + HWI] and its support for hardware wallet firmware released for the + [fee overpayment attack][]. + +## Notable code and documentation changes + +*Notable changes this week in [Bitcoin Core][bitcoin core repo], +[C-Lightning][c-lightning repo], [Eclair][eclair repo], [LND][lnd repo], +[Rust-Lightning][rust-lightning repo], [libsecp256k1][libsecp256k1 repo], +[Hardware Wallet Interface (HWI)][hwi], [Bitcoin Improvement Proposals +(BIPs)][bips repo], and [Lightning BOLTs][bolts repo].* + +- [Bitcoin Core #19473][] net: Add -networkactive option + FIXME:bitschmidty + +- [Bitcoin Core #18044][] adds support for witness txid (wtxid) + transaction inventory announcements (`inv`) and requests (`getdata`) + as described in BIP339 (see [Newsletter #104][news104 bip339]). Prior + to this merge, all Bitcoin nodes announced new unconfirmed + transactions to their peers by the transaction's txid. However, txids + don't commit to the witness data in segwit transactions, so a node that + downloads an invalid or unwanted segwit transaction can't safely + assume that any transaction with that same txid is also invalid or + unwanted. That means nodes may waste bandwidth by downloading the + same bad transaction over and over from each peer announcing that + transaction. + + So far this hasn't been an issue---honest peers usually don't + announce transactions they wouldn't accept themselves, so only a + disruptive peer that wanted to waste its own upload bandwidth would + advertise invalid or unwanted transactions. However, one type of + unwanted transaction today are spends of v1 segwit UTXOs---the types + of spends the [BIP341][] specification of [taproot][topic taproot] + plans to use. If taproot activates, this means newer taproot-aware + nodes will advertise taproot spends to older taproot-unaware nodes. + Each time one those taproot-unaware nodes receives a + taproot-spending transaction, it will download it, realize it uses + v1 segwit, and throw it away. This could be very wasteful of + network bandwidth, both for older taproot-unaware nodes and newer + taproot-aware nodes. This same problem applies to other proposed + changes to network relay policy. + + The solution implemented in this merged PR is to announce + transactions by their wtxid---which includes a commitment to the + witness data for segwit transactions. A taproot implementation in + Bitcoin Core (see [PR #17977][Bitcoin Core #17977]) could then only + relay transactions by their wtxid to prevent newer nodes from + accidentally spamming older nodes. + + However, after this PR was merged into Bitcoin Core's master + development branch, it was [discussed][meeting xscript] during the + weekly Bitcoin Core Development Meeting whether taproot's soft + dependency on wtxid relay will make it more complicated to backport + taproot to the current 0.20.x branch of Bitcoin Core. Four options + were mentioned during the meeting and in subsequent discussions: + + 1. **Backport wtxid:** both wtxid relay and taproot will be + backported if there's a 0.20.x taproot release. John Newbery has + already created a [wtxid relay backport][]. + + 2. **Don't backport wtxid:** only backport taproot and just accept that + transaction announcements will use more bandwidth than usual + until everyone has upgraded to wtxid-using nodes. + + 3. **Don't relay taproot:** only backport taproot but don't enable + relaying of taproot transactions on backported nodes. This + prevents the immediate bandwidth waste but it may make it harder to + get taproot-spending transactions to miners and will reduce the + speed and efficiency of [BIP152][] compact blocks. Worse compact + block performance may temporarily increase the number of stale + blocks that miners create (especially since the [public FIBRE + network][] has recently shut down). + + 4. **Don't backport anything:** don't backport wtxid relay or + taproot---let taproot wait until some time after the release of Bitcoin + Core 0.21, roughly [expected][Bitcoin Core #18947] in December + 2020. + + No clear conclusion on which of these options to follow has been + reached. + +- [Eclair #1485][] adds support for [spontaneous payments][topic + spontaneous payments] using the same keysend protocol previously + implemented by LND (see [Newsletter #30][news30 spont]) and + C-Lightning (see Newsletters [#94][news94 keysend plugin] and + [#107][news107 keysend rpc]). This merged PR supports both receiving + spontaneous payments (labeled as donations) and sending payments + using the new `sendWithPreimage` method. + +- [Eclair #1484][] adds low-level support for the changes to commitment + transactions for [anchor outputs][topic anchor outputs]. Not yet + added is higher-level support that will allow Eclair to negotiate + the use of anchor outputs with peers, but this early step does pass + all [proposed test vectors][BOLTs #688 eclair tests]. + +- [LND #4455][] PSBT: add no_publish flag for safe batch channel opens v2 FIXME:dongcarl + +{% include references.md %} +{% include linkers/issues.md issues="19473,18044,17977,18947,1485,1484,4455" %} +[C-Lightning 0.9.0]: https://github.com/ElementsProject/lightning/releases/tag/v0.9.0rc3 +[Bitcoin Core 0.20.1]: https://bitcoincore.org/bin/bitcoin-core-0.20.1/ +[fee overpayment attack]: /en/newsletters/2020/06/10/#fee-overpayment-attack-on-multi-input-segwit-transactions +[osuntokun upgrade]: https://lists.linuxfoundation.org/pipermail/lightning-dev/2020-July/002763.html +[teinturier simple]: https://lists.linuxfoundation.org/pipermail/lightning-dev/2020-July/002764.html +[zmnscpxj re-funding]: https://lists.linuxfoundation.org/pipermail/lightning-dev/2020-July/002765.html +[news104 bip339]: /en/newsletters/2020/07/01/#bips-933 +[news30 spont]: /en/newsletters/2019/01/22/#pr-opened-for-spontaneous-ln-payments +[news94 keysend plugin]: /en/newsletters/2020/04/22/#c-lightning-3611 +[news107 keysend rpc]: /en/newsletters/2020/07/22/#c-lightning-3792 +[meeting xscript]: http://www.erisian.com.au/meetbot/bitcoin-core-dev/2020/bitcoin-core-dev.2020-07-23-19.00.log.html#l-63 +[news107 notable]: /en/newsletters/2020/07/22/#notable-code-and-documentation-changes +[bolts #688 eclair tests]: https://github.com/lightningnetwork/lightning-rfc/pull/688#issuecomment-656737250 +[public fibre network]: http://bitcoinfibre.org/public-network.html +[wtxid relay backport]: https://github.com/bitcoin/bitcoin/pull/19606 From 3e25c70a6785e9268829703ae1c5d52442ebfa7e Mon Sep 17 00:00:00 2001 From: Mike Schmidt Date: Mon, 27 Jul 2020 11:16:29 -0500 Subject: [PATCH 2/5] News108: add bitcoin core 19473 --- _posts/en/newsletters/2020-07-29-newsletter.md | 9 ++++++--- 1 file changed, 6 insertions(+), 3 deletions(-) diff --git a/_posts/en/newsletters/2020-07-29-newsletter.md b/_posts/en/newsletters/2020-07-29-newsletter.md index aef4816e1d..b1053fa986 100644 --- a/_posts/en/newsletters/2020-07-29-newsletter.md +++ b/_posts/en/newsletters/2020-07-29-newsletter.md @@ -93,9 +93,6 @@ release candidates.* [Hardware Wallet Interface (HWI)][hwi], [Bitcoin Improvement Proposals (BIPs)][bips repo], and [Lightning BOLTs][bolts repo].* -- [Bitcoin Core #19473][] net: Add -networkactive option - FIXME:bitschmidty - - [Bitcoin Core #18044][] adds support for witness txid (wtxid) transaction inventory announcements (`inv`) and requests (`getdata`) as described in BIP339 (see [Newsletter #104][news104 bip339]). Prior @@ -162,6 +159,12 @@ release candidates.* No clear conclusion on which of these options to follow has been reached. +- [Bitcoin Core #19473][] adds support for `networkactive` as both a command line + start-up and configuration file option. Setting this option enables or + disables all P2P network activity. After the node has been started, network + activity can be toggled using the existing `setnetworkactive` RPC or the network + activity button in the GUI. + - [Eclair #1485][] adds support for [spontaneous payments][topic spontaneous payments] using the same keysend protocol previously implemented by LND (see [Newsletter #30][news30 spont]) and From 114dec4659f28327f3487b50c56dbba969711618 Mon Sep 17 00:00:00 2001 From: Carl Dong Date: Mon, 27 Jul 2020 13:33:50 -0400 Subject: [PATCH 3/5] News108: Add LND 4455 description --- _posts/en/newsletters/2020-07-29-newsletter.md | 9 ++++++++- 1 file changed, 8 insertions(+), 1 deletion(-) diff --git a/_posts/en/newsletters/2020-07-29-newsletter.md b/_posts/en/newsletters/2020-07-29-newsletter.md index b1053fa986..4b9e0f2666 100644 --- a/_posts/en/newsletters/2020-07-29-newsletter.md +++ b/_posts/en/newsletters/2020-07-29-newsletter.md @@ -179,7 +179,14 @@ release candidates.* the use of anchor outputs with peers, but this early step does pass all [proposed test vectors][BOLTs #688 eclair tests]. -- [LND #4455][] PSBT: add no_publish flag for safe batch channel opens v2 FIXME:dongcarl +- [LND #4455][] enables safe PSBT-based batched channel opens. Previously, each + successful channel negotiation in the batch would prematurely broadcast the + whole transaction with all channel funding outputs. This meant + subsequent channel negotiation failures could result in stuck funds. + This merged PR introduces a `--no_publish` flag to the `openchannel` command, + which can be used to delay transaction broadcast until the very last channel + in the batch. + {% include references.md %} {% include linkers/issues.md issues="19473,18044,17977,18947,1485,1484,4455" %} From a4e1f06ba098059d00aa077aa11aa7d42f2ca88e Mon Sep 17 00:00:00 2001 From: Mike Schmidt Date: Mon, 27 Jul 2020 13:58:19 -0500 Subject: [PATCH 4/5] News108: add river field report --- _includes/articles/river-descriptors-psbt.md | 56 +++++++++++++++++++ .../en/2020-07-29-river-descriptors-psbt.md | 16 ++++++ .../en/newsletters/2020-07-29-newsletter.md | 9 ++- 3 files changed, 79 insertions(+), 2 deletions(-) create mode 100644 _includes/articles/river-descriptors-psbt.md create mode 100644 _posts/en/2020-07-29-river-descriptors-psbt.md diff --git a/_includes/articles/river-descriptors-psbt.md b/_includes/articles/river-descriptors-psbt.md new file mode 100644 index 0000000000..411210c079 --- /dev/null +++ b/_includes/articles/river-descriptors-psbt.md @@ -0,0 +1,56 @@ +{:.post-meta} +*by [Philip Glazman][], Engineer at [River Financial][]* + +*River Financial​ is a challenger financial institution specializing in Bitcoin +financial services. River Financial’s flagship product, a Bitcoin brokerage, +provides retail investors with a high-touch platform to buy and sell Bitcoin.* + +River Financial leverages two technologies in its wallet software: [Partially +Signed Bitcoin Transactions (PSBTs)][topic psbt] and [Output Script +Descriptors][topic descriptors]. The decision to incorporate these standards has +introduced greater flexibility and interoperability in River’s wallet operations. + +The decision to bring PSBTs into the wallet stack was influenced by the concept +of treating key signers as interfaces. PSBT is a format for signers described in +[BIP174][] authored by Andrew Chow. Before this standard, there had been no +standardized format to describe an unsigned transaction. As a consequence, each +signer used vendor-specific formats which could not interoperate. By conforming +to the PSBT standard, the wallet infrastructure can avoid vendor lock-in, reduce +the attack surface in the signer logic, and have better guarantees about the +transaction being created by the wallet. The standard has also made +multisignature scripts safer to use, therefore significantly improving security +without a notable increase in operational expense. + +The decision to implement Output Script Descriptors in the wallet software has +greatly reduced the complexity in wallet operations and has improved flexibility +in the feature set. Descriptors is a language for describing scripts that was +authored by Pieter Wuille and used in Bitcoin Core. In River’s wallet software, +the descriptor language is leveraged in several places from wallet creation to +address generation. Before descriptors, there had been no interoperable way for +wallets to import useful information about the scripts they used. By using +script descriptors, River’s wallet is able to reduce the necessary information +needed to start watching a script, address, or set of keys. Each wallet within +the wallet software has an associated descriptor with which scripts can be +created. This has two immediate benefits: + +1. **The wallet software is able to watch cold wallets using descriptors and + subsequently derive new addresses.** In our flagship brokerage product, River + clients can create fresh deposit addresses to deposit Bitcoin directly to a + secure cold multisignature wallet. +2. **Creating and importing new wallets is easy because the descriptor language + is able to define desired scripts.** River is able to maintain many wallets + with different scripts and as a result have separate security models for each + wallet. A P2WSH multi-signature descriptor is used for the cold wallet and a + P2WPKH descriptor for the hot (client withdrawal) wallet. Separate wallets + allow River to keep the absolute minimum Bitcoin in the hot wallet (to + minimize risk) and better manage the UTXO pool to service withdrawals. + +The decision to use both descriptors and the PSBT standard has so far been +rewarding because of the flexibility and interoperability. This foundation will +help River Financial scale its wallet infrastructure. + +{% include references.md %} +[Philip Glazman]: https://github.com/philipglazman +[River Financial]: https://river.com/ +[topic psbt]: /en/topics/psbt/ +[topic descriptors]: /en/topics/output-script-descriptors/ diff --git a/_posts/en/2020-07-29-river-descriptors-psbt.md b/_posts/en/2020-07-29-river-descriptors-psbt.md new file mode 100644 index 0000000000..27eee6bfc8 --- /dev/null +++ b/_posts/en/2020-07-29-river-descriptors-psbt.md @@ -0,0 +1,16 @@ +--- +title: 'Field Report: Using Descriptors and PSBT at River Financial' +permalink: /en/river-descriptors-psbt/ +name: 2020-07-29-river-descriptors-psbt +slug: 2020-07-29-river-descriptors-psbt +type: posts +layout: post +lang: en +version: 1 + +excerpt: > + A field report about how River Financial uses Partially Signed Bitcoin + Transactions (PSBTs) and Output Script Descriptors in its wallet software. + +--- +{% include articles/river-descriptors-psbt.md %} diff --git a/_posts/en/newsletters/2020-07-29-newsletter.md b/_posts/en/newsletters/2020-07-29-newsletter.md index 4b9e0f2666..cb22e55aeb 100644 --- a/_posts/en/newsletters/2020-07-29-newsletter.md +++ b/_posts/en/newsletters/2020-07-29-newsletter.md @@ -8,8 +8,9 @@ layout: newsletter lang: en --- This week's newsletter describes a proposal to allow upgrading LN -channel commitment transaction formats without opening new channels. -Also included are our regular sections with selected questions and +channel commitment transaction formats without opening new channels and includes +a field report from River Financial about building wallet software using PSBTs +and descriptors. Also included are our regular sections with selected questions and answers from the Bitcoin StackExchange, recent releases and release candidates, and notable changes to popular Bitcoin infrastructure projects. @@ -53,6 +54,10 @@ projects. and the channel can be resolved using the appropriate unilateral close protocol. +## Field report: Using Descriptors and PSBT at River + +{% include articles/river-descriptors-psbt.md %} + ## Selected Q&A from Bitcoin StackExchange *[Bitcoin StackExchange][bitcoin.se] is one of the first places Optech From 7ce3d3bbcc330192c2ae281e05fd5e8e8bcfdba1 Mon Sep 17 00:00:00 2001 From: Mike Schmidt Date: Mon, 27 Jul 2020 15:11:57 -0500 Subject: [PATCH 5/5] News108: add stack exchange --- .../en/newsletters/2020-07-29-newsletter.md | 26 ++++++++++++++++++- 1 file changed, 25 insertions(+), 1 deletion(-) diff --git a/_posts/en/newsletters/2020-07-29-newsletter.md b/_posts/en/newsletters/2020-07-29-newsletter.md index cb22e55aeb..3902e18341 100644 --- a/_posts/en/newsletters/2020-07-29-newsletter.md +++ b/_posts/en/newsletters/2020-07-29-newsletter.md @@ -69,7 +69,29 @@ answers posted since our last update.* {% comment %}{% endcomment %} {% assign bse = "https://bitcoin.stackexchange.com/a/" %} -FIXME:bitschmidty +- [What are "leaf versions" in Taproot?]({{bse}}97104) + Michael Folkson and Pieter Wuille explain that each leaf node of a + [taproot][topic taproot] tree commits to both a leaf version and a script. + This leaf version can be used for upgradability and designates the script + semantics that apply just to that leaf. + +- [What are the different upgradability features in the BIP-Taproot (BIP341) proposal?]({{bse}}96951) + Michael Folkson answers a question from Twitter regarding the different ways + in which taproot can enable upgradability including leaf versions for script + semantics, repurposing opcodes for future functionality, pubkey types, and the + annex for new fields. + +- [Is there an active list of BIPs currently open?]({{bse}}97043) + Pieter Wuille describes various methods that have previously been used to + activate soft forks and notes that, while there are currently no unactivated + soft forks in Bitcoin Core, there is a discussion about the activation method + for taproot. Pieter also answers a [similar question][stack exchange miner + signaling] about mining signaling support. + +- [Could we skip the Taproot soft fork and instead use Simplicity to write the equivalent of Taproot scripts?]({{bse}}97049) + Michael Folkson, quoting Pieter Wuille, outlines the current state of + [Simplicity][news96 simplicity] and also notes that integrating Simplicity in + taproot as a leaf version would be preferable. ## Releases and release candidates @@ -210,3 +232,5 @@ release candidates.* [bolts #688 eclair tests]: https://github.com/lightningnetwork/lightning-rfc/pull/688#issuecomment-656737250 [public fibre network]: http://bitcoinfibre.org/public-network.html [wtxid relay backport]: https://github.com/bitcoin/bitcoin/pull/19606 +[stack exchange miner signaling]: https://bitcoin.stackexchange.com/questions/97041/how-does-a-miner-put-his-vote-for-certain-bip/97047#97047 +[news96 simplicity]: /en/newsletters/2020/05/06/#simplicity-next-generation-smart-contracting