Skip to content

Commit 30eb26c

Browse files
hardingbitschmidty
harding
authored and
bitschmidty
committed
Newsletters: add 268 (2023-09-13)
1 parent d852fa0 commit 30eb26c

File tree

3 files changed

+209
-0
lines changed

3 files changed

+209
-0
lines changed

‎_posts/en/newsletters/2023-09-13-newsletter.md‎

Lines changed: 105 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,105 @@
1+
---
2+
title: 'Bitcoin Optech Newsletter #268'
3+
permalink: /en/newsletters/2023/09/13/
4+
name: 2023-09-13-newsletter
5+
slug: 2023-09-13-newsletter
6+
type: newsletter
7+
layout: newsletter
8+
lang: en
9+
---
10+
This week's newsletter links to draft specifications related to taproot
11+
assets and describes a summary of several alternative message protocols
12+
for LN that can help enable the use of PTLCs. Also included are our
13+
regular sections with the summary of a Bitcoin Core PR Review Club
14+
meeting, announcements of new software releases and release candidates,
15+
and descriptions of notable changes to popular Bitcoin infrastructure
16+
software.
17+
18+
## News
19+
20+
- **Specifications for taproot assets:** Olaoluwa Osuntokun posted
21+
separately to the Bitcoin-Dev and Lightning-Dev mailing lists about
22+
the _Taproot Assets_ [client-side validation protocol][topic client-side
23+
validation]. To the Bitcoin-Dev mailing list, he [announced][osuntokun
24+
bips] seven draft BIPs---one more than in the initial announcement of
25+
the protocol, then under the name _Taro_ (see [Newsletter
26+
#195][news195 taro]). To the Lightning-Dev mailing list, he
27+
[announced][osuntokun blip post] a [draft BLIP][osuntokun blip] for
28+
spending and receiving taproot assets using LN, with the protocol
29+
based on the experimental "simple taproot channels" feature planned to
30+
be released in LND 0.17.0-beta.
31+
32+
Note that, despite its name, Taproot Assets is not part of the
33+
Bitcoin Protocol and does not change the consensus protocol in any
34+
way. It uses existing capabilities to provide new features for
35+
users that opt-in to its client protocol.
36+
37+
None of the specifications had received any discussion on the
38+
mailing list as of this writing.
39+
40+
- **LN messaging changes for PTLCs:** as the first LN implementation
41+
with experimental support for channels using [P2TR][topic taproot]
42+
and [MuSig2][topic musig] is expected to be released soon, Greg
43+
Sanders [posted][sanders post] to the Lightning-Dev mailing list a
44+
[summary][sanders ptlc] of several different previously-discussed
45+
changes to LN messages to allow them to support sending payments with
46+
[PTLCs][topic ptlc] instead of [HTLCs][topic htlc]. For most
47+
approaches, the changes to messages do not seem large or invasive,
48+
but we note that most implementations will probably continue using one
49+
set of messages for handling legacy HTLC forwarding while also
50+
offering upgraded messages to support PTLC forwarding, creating two
51+
different paths that will need to be maintained concurrently until
52+
HTLCs are phased out. If some implementations add experimental PTLCs
53+
support before the messages are standardized, then implementations
54+
might even be required to support three or more different protocols
55+
simultaneously, to the disadvantage of all.
56+
57+
Sander's summary has not received any comments as of this writing.
58+
59+
## Bitcoin Core PR Review Club
60+
61+
*In this monthly section, we summarize a recent [Bitcoin Core PR Review
62+
Club][] meeting, highlighting some of the important questions and
63+
answers. Click on a question below to see a summary of the answer from
64+
the meeting.*
65+
66+
FIXME:LarryRuane
67+
68+
{% include functions/details-list.md
69+
q0="FIXME"
70+
a0="FIXME"
71+
a0link="https://bitcoincore.reviews/28122#l-126FIXME"
72+
%}
73+
74+
## Releases and release candidates
75+
76+
*New releases and release candidates for popular Bitcoin infrastructure
77+
projects. Please consider upgrading to new releases or helping to test
78+
release candidates.*
79+
80+
- [LND v0.17.0-beta.rc2][] is a release candidate for the next major
81+
version of this popular LN node implementation. A major new
82+
experimental feature planned for this release, which could likely
83+
benefit from testing, is support for "simple taproot channels".
84+
85+
## Notable code and documentation changes
86+
87+
*Notable changes this week in [Bitcoin Core][bitcoin core repo], [Core
88+
Lightning][core lightning repo], [Eclair][eclair repo], [LDK][ldk repo],
89+
[LND][lnd repo], [libsecp256k1][libsecp256k1 repo], [Hardware Wallet
90+
Interface (HWI)][hwi repo], [Rust Bitcoin][rust bitcoin repo], [BTCPay
91+
Server][btcpay server repo], [BDK][bdk repo], [Bitcoin Improvement
92+
Proposals (BIPs)][bips repo], [Lightning BOLTs][bolts repo], and
93+
[Bitcoin Inquisition][bitcoin inquisition repo].*
94+
95+
- [Bitcoin Core #26567][] Wallet: estimate the size of signed inputs using descriptors FIXME:Murchandamus
96+
97+
{% include references.md %}
98+
{% include linkers/issues.md v=2 issues="26567" %}
99+
[LND v0.17.0-beta.rc2]: https://github.com/lightningnetwork/lnd/releases/tag/v0.17.0-beta.rc2
100+
[news195 taro]: /en/newsletters/2022/04/13/#transferable-token-scheme
101+
[osuntokun bips]: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2023-September/021938.html
102+
[osuntokun blip post]: https://lists.linuxfoundation.org/pipermail/lightning-dev/2023-September/004089.html
103+
[osuntokun blip]: https://github.com/lightning/blips/pull/29
104+
[sanders post]: https://lists.linuxfoundation.org/pipermail/lightning-dev/2023-September/004088.html
105+
[sanders ptlc]: https://gist.github.com/instagibbs/1d02d0251640c250ceea1c66665ec163

‎_topics/en/client-side-validation.md‎

Lines changed: 101 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,101 @@
1+
---
2+
title: Client-side validation
3+
4+
## Optional. Shorter name to use for reference style links e.g., "foo"
5+
## will allow using the link [topic foo][]. Not case sensitive
6+
# shortname: foo
7+
8+
## Optional. An entry will be added to the topics index for each alias
9+
aliases:
10+
- RGB
11+
- Taro
12+
- Taproot Assets
13+
14+
## Required. At least one category to which this topic belongs. See
15+
## schema for options
16+
categories:
17+
- Contract Protocols
18+
19+
## Optional. Produces a Markdown link with either "[title][]" or
20+
## "[title](link)"
21+
#primary_sources:
22+
# - title: Example
23+
# link: https://example.com
24+
25+
## Optional. Each entry requires "title" and "url". May also use "feature:
26+
## true" to bold entry and "date"
27+
optech_mentions:
28+
- title: "Taro transferrable token scheme"
29+
url: /en/newsletters/2022/04/13/#transferable-token-scheme
30+
31+
- title: "Update on RGB"
32+
url: /en/newsletters/2023/04/19/#rgb-update
33+
34+
- title: "Specifications published for taproot assets"
35+
url: /en/newsletters/2023/09/13/#specifications-for-taproot-assets
36+
37+
## Optional. Same format as "primary_sources" above
38+
see_also:
39+
- title: "Pay to Contract (P2C)"
40+
link: topic p2c
41+
42+
## Optional. Force the display (true) or non-display (false) of stub
43+
## topic notice. Default is to display if the page.content is below a
44+
## threshold word count
45+
#stub: false
46+
47+
## Required. Use Markdown formatting. Only one paragraph. No links allowed.
48+
## Should be less than 500 characters
49+
excerpt: >
50+
**Client-side validation protocols** allow a Bitcoin transaction to
51+
commit to some data whose validity is determined separate from the
52+
validity of the transaction under Bitcoin's consensus rules. The
53+
client-side validation can take advantage of consensus rules, such as
54+
only allowing an output to be spent once within a valid block chain,
55+
but it may also impose additional rules known only to those interested
56+
in the validation.
57+
58+
---
59+
A conceptually simple client-side validation protocol might associate a
60+
token with a particular UTXO. Only the set of validators needs to know
61+
about that association; it does not need to be published to the block
62+
chain or anywhere else that is public. When the UTXO is spent, the
63+
spending transaction associates the token with a new UTXO. If Alice
64+
currently controls the UTXO associated with the token and Bob wants to
65+
buy it from her, she can provide him with evidence of the original
66+
association and then he can use his validated copy of the block chain
67+
plus client-side validation to verify the history of every transfer of the
68+
token leading up to Alice. He can also verify that a transaction
69+
created by Alice is correctly formatted to assign the token to a UTXO
70+
that Bob controls.
71+
72+
**[RGB][]** is a client-side validation protocol that uses
73+
[pay-to-contract][topic p2c] to allow transactions to commit to
74+
additional data, such as transfers. The protocol has been designed to
75+
be highly flexible.
76+
77+
**[Taproot Assets][]**, formerly called **Taro**, is a protocol heavily
78+
inspired by RGB that uses [taproot][topic taproot]'s commitment
79+
structure to allow transactions to commit to additional data.
80+
Taproot's construction itself derives from pay-to-contract. As the name
81+
suggests, initial protocol development is specifically focused on the
82+
transfer of assets (that is, digital tokens that represent assets).
83+
84+
Both protocols are designed to be compatible with offchain transactions,
85+
such as LN payments. Similar to the lifecycle of an LN channel, an
86+
onchain setup transaction is published that commits the tokens to the
87+
mutual control of involved parties; a series of offchain transactions
88+
each commits to the current allocation of the tokens between the
89+
parties; and a transaction containing the final commitment is published
90+
onchain.
91+
92+
Only wallets that want to support RGB or Taproot Assets need to
93+
understand the protocol, and only a wallet that wants to send or receive
94+
a specific token or other client-side validation contract needs to know
95+
anything about that contract. To everyone else, transactions created
96+
with RGB and Taproot Assets look like regular Bitcoin transactions.
97+
98+
{% include references.md %}
99+
{% include linkers/issues.md issues="" %}
100+
[rgb]: https://rgb.tech/
101+
[taproot assets]: https://docs.lightning.engineering/the-lightning-network/taproot-assets/

‎_topics/en/ptlc.md‎

Lines changed: 3 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -76,6 +76,9 @@ optech_mentions:
7676
- title: Using signature adaptors with PTLCs to prove acceptance of an LN async payment
7777
url: /en/newsletters/2023/02/01/#ln-async-proof-of-payment
7878

79+
- title: "Summary of proposed LN messaging changes for PTLCs"
80+
url: /en/newsletters/2023/09/13/#ln-messaging-changes-for-ptlcs
81+
7982
## Optional. Same format as "primary_sources" above
8083
see_also:
8184
- title: Hash Time Locked Contract (HTLC)

0 commit comments

Comments
 (0)