Skip to content

Commit 9e16d31

Browse files
hardingbitschmidty
harding
authored and
bitschmidty
committed
Newsletters: add 252 (2023-05-24)
1 parent fbe08f4 commit 9e16d31

File tree

5 files changed

+199
-0
lines changed

5 files changed

+199
-0
lines changed

‎_includes/specials/policy/en/02-cache-utility.md

Lines changed: 10 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,10 @@
1+
<!--
2+
300 to 1000 words
3+
put title in main newsletter
4+
put links in this file
5+
for any subheads use h3 (i.e., ###)
6+
illustrations welcome (max width 800px)
7+
if uncertain about anything, just do what seems best and harding will edit
8+
-->
9+
10+
FIXME:glozow

‎_posts/en/newsletters/2023-05-24-newsletter.md

Lines changed: 180 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,180 @@
1+
---
2+
title: 'Bitcoin Optech Newsletter #252'
3+
permalink: /en/newsletters/2023/05/24/
4+
name: 2023-05-24-newsletter
5+
slug: 2023-05-24-newsletter
6+
type: newsletter
7+
layout: newsletter
8+
lang: en
9+
---
10+
This week's newsletter describes research into zero-knowledge validity
11+
proofs for Bitcoin and related protocols. Also included is another entry
12+
in our limited weekly series about mempool policy, plus our regular
13+
sections describing updates to clients and services, new releases and
14+
release candidates, and changes to popular Bitcoin infrastructure
15+
projects.
16+
17+
## News
18+
19+
- **State compression with zero-knowledge validity proofs:** Robin Linus
20+
[posted][linus post] to the Bitcoin-Dev mailing list about a
21+
[paper][lg paper] he co-authored with Lukas George about using
22+
validity proofs to reduce the amount of state that a client needs to
23+
download in order to trustlessly verify future operations in a system.
24+
They first apply their system to Bitcoin. They report having a
25+
prototype that proves the cumulative amount of proof of work in a
26+
chain of block headers and allows a client to verify that a particular
27+
block header is part of that chain. This allows a client that
28+
receives multiple proofs to determine which demonstrates the most
29+
proof of work.
30+
31+
They also have a suboptimal prototype which proves that all
32+
transaction state changes for the block chain respected the currency
33+
rules (e.g., how many bitcoins can be created by a new block, that
34+
each non-coinbase transaction must not create UTXOs with more
35+
bitcoin value than those it destroys (spends), and that a miner may
36+
claim any difference between the UTXOs destroyed in a block and
37+
those created). A client receiving this proof and a copy of the
38+
current UTXO set would be able to verify that the set was accurate
39+
and complete. They call this an _assumevalid_ proof after the
40+
[feature in Bitcoin Core][assumevalid] that optionally skips
41+
verification of scripts for older blocks when many contributors
42+
agree that their nodes all validated those blocks successfully.
43+
44+
To minimize the complexity of their proof, they use a version of
45+
[utreexo][topic utreexo] with a hash function optimized for their
46+
system. They separately suggest that combining their proof with a
47+
utreexo client will allow that client to begin operating as a full
48+
node almost immediately after downloading a very small amount of
49+
data.
50+
51+
Regarding the usability of their prototypes, they write that "we
52+
have implemented the header chain proof and the assumevalid state
53+
proof as prototypes. The former is feasible to prove, while the
54+
latter still requires performance improvements to prove
55+
reasonable-sized blocks". They are also working on validating
56+
complete blocks, including scripts, but say that they need at least
57+
a 40x speed up for that to be viable.
58+
59+
In addition to state compression of the Bitcoin block chain, they
60+
also describe a protocol that can be used for a
61+
client-side-validation token protocol similar to that used for Lightning Labs'
62+
Taproot Assets and some uses of RGB (see Newsletters [#195][news195
63+
taro] and [#247][news247 rgb]). When Alice transfers to Bob some
64+
amount of a token, Bob needs to verify the history of every previous
65+
transfer of those specific tokens back to when they were created.
66+
In an ideal scenario, that history grows linearly with the number of
67+
transfers. But if Bob wants to pay Carol an amount higher than he
68+
received from Alice, he will need to combine some of the tokens he
69+
received from Alice with some tokens he received in a
70+
different transaction. Carol will then need to verify both the
71+
history going back through Alice and also the history of Bob's other
72+
tokens. This is called a merge. If merges happen often, the size
73+
of the history that needs to be verified approaches the size of the
74+
history of every transfer of that token between any users. In
75+
comparative terms, in Bitcoin every full node verifies every
76+
transaction made by every user; in token protocols using client-side
77+
validation, that's not strictly required but eventually becomes
78+
effectively the case if merges are common.
79+
80+
That means a protocol that can compress the state of Bitcoin can
81+
also be adapted to compress the state of a token's history, even one
82+
where merges are common. The authors describe how they would
83+
accomplish that. Their goal is to produce a proof that each
84+
previous transfer of the token followed the token's rules, including
85+
using their proofs for Bitcoin to prove that each previous transfer
86+
was anchored in the block chain. Alice could then transfer the
87+
tokens to Bob and give him a short constant-sized proof of validity;
88+
Bob could verify the proof to know that the transfer happened at a
89+
certain block height and paid his token wallet, giving him exclusive
90+
control over the tokens.
91+
92+
Although the paper frequently mentions additional research and
93+
development that can be performed,
94+
we find this to be encouraging progress towards a
95+
[feature][coinwitness] that Bitcoin developers have desired for over
96+
a decade.
97+
98+
## Waiting for confirmation #2: FIXME:glozow title
99+
100+
_A limited weekly series about transaction relay, mempool inclusion, and
101+
mining transaction selection---including why Bitcoin Core has a more
102+
restrictive policy than allowed by consensus and how wallets can use
103+
that policy most effectively._
104+
105+
{% include specials/policy/en/02-cache-utility.md %}
106+
107+
## Changes to services and client software
108+
109+
*In this monthly feature, we highlight interesting updates to Bitcoin
110+
wallets and services.*
111+
112+
FIXME:bitschmidty
113+
114+
## Releases and release candidates
115+
116+
*New releases and release candidates for popular Bitcoin infrastructure
117+
projects. Please consider upgrading to new releases or helping to test
118+
release candidates.*
119+
120+
- [Core Lightning 23.05][] is a release of the newest version of this LN
121+
implementation. It includes support for [blinded payments][topic rv
122+
routing], version 2 [PSBTs][topic psbt], and more flexible feerate
123+
management among many other improvements.
124+
125+
- [Bitcoin Core 23.2][] is a maintenance release for the previous
126+
major version of Bitcoin Core.
127+
128+
- [Bitcoin Core 24.1][] is a maintenance release for the current
129+
version of Bitcoin Core.
130+
131+
- [Bitcoin Core 25.0rc2][] is a release candidate for the next major
132+
version of Bitcoin Core.
133+
134+
## Notable code and documentation changes
135+
136+
*Notable changes this week in [Bitcoin Core][bitcoin core repo], [Core
137+
Lightning][core lightning repo], [Eclair][eclair repo], [LDK][ldk repo],
138+
[LND][lnd repo], [libsecp256k1][libsecp256k1 repo], [Hardware Wallet
139+
Interface (HWI)][hwi repo], [Rust Bitcoin][rust bitcoin repo], [BTCPay
140+
Server][btcpay server repo], [BDK][bdk repo], [Bitcoin Improvement
141+
Proposals (BIPs)][bips repo], [Lightning BOLTs][bolts repo], and
142+
[Bitcoin Inquisition][bitcoin inquisition repo].*
143+
144+
- [Bitcoin Core #27021][] Implement Mini version of BlockAssembler to calculate mining scores FIXME:harding (hoping glozow or Xekyo will volunteer, though)
145+
146+
- [LND #7668][] adds the ability to associate up to 500 characters of
147+
private text with a channel when opening it and allows the operator to
148+
retrieve that information later, which may help them recall why they
149+
opened that particular channel.
150+
151+
- [LDK #2204][] adds the ability to set custom feature bits for
152+
announcing to peers, or for use when attempting to parse a peer's
153+
announcement.
154+
155+
- [LDK #1841][] implements a version of a security recommendation
156+
previously added to the LN specification (see [Newsletter
157+
#128][news128 bolts803]) where a node using [anchor outputs][topic
158+
anchor outputs] should not attempt to batch together inputs controlled
159+
by multiple parties when the transaction needs to be confirmed
160+
promptly. This prevents other parties from being able to delay
161+
confirmation.
162+
163+
- [BIPs #1412][] updates [BIP329][] for [wallet label export][topic
164+
wallet labels] with a field to store key origin information.
165+
Additionally, the specification now suggests a label length limit of
166+
255 characters.
167+
168+
{% include references.md %}
169+
{% include linkers/issues.md v=2 issues="27021,7668,2204,1841,1412" %}
170+
[Core Lightning 23.05]: https://github.com/ElementsProject/lightning/releases/tag/v23.05
171+
[bitcoin core 23.2]: https://bitcoincore.org/bin/bitcoin-core-23.2/
172+
[bitcoin core 24.1]: https://bitcoincore.org/bin/bitcoin-core-24.1/
173+
[bitcoin core 25.0rc2]: https://bitcoincore.org/bin/bitcoin-core-25.0/
174+
[linus post]: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2023-May/021679.html
175+
[lg paper]: https://zerosync.org/zerosync.pdf
176+
[news128 bolts803]: /en/newsletters/2020/12/16/#bolts-803
177+
[news247 rgb]: /en/newsletters/2023/04/19/#rgb-update
178+
[news195 taro]: /en/newsletters/2022/04/13/#transferable-token-scheme
179+
[coinwitness]: https://bitcointalk.org/index.php?topic=277389.0
180+
[assumevalid]: https://bitcoincore.org/en/2017/03/08/release-0.14.0/#assumed-valid-blocks

‎_topics/en/anchor-outputs.md

Lines changed: 3 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -146,6 +146,9 @@ optech_mentions:
146146
- title: "LDK #1860 adds support for channels using anchor outputs"
147147
url: /en/newsletters/2023/02/01/#ldk-1860
148148

149+
- title: "LDK #1841 implements a solution for the fee-stealing attack described in BOLTs #824"
150+
url: /en/newsletters/2023/05/24/#ldk-1841
151+
149152
## Optional. Same format as "primary_sources" above
150153
see_also:
151154
- title: CPFP carve-out

‎_topics/en/utreexo.md

Lines changed: 3 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -37,6 +37,9 @@ optech_mentions:
3737
- title: "Service bit for Utreexo"
3838
url: /en/newsletters/2023/03/15/#service-bit-for-utreexo
3939

40+
- title: ZeroSync protocol which uses a variation of utreexo
41+
url: /en/newsletters/2023/05/24/#state-compression-with-zero-knowledge-validity-proofs
42+
4043
## Optional. Same format as "primary_sources" above
4144
# see_also:
4245
# - title:

‎_topics/en/wallet-labels.md

Lines changed: 3 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -42,6 +42,9 @@ optech_mentions:
4242
- title: "BTCPay Server #4799 allows export wallet labels as specified in BIP329"
4343
url: /en/newsletters/2023/04/05/#btcpay-server-4799
4444

45+
- title: "BIPs #1412 updates BIP329 wallet label export with support for key origin information"
46+
url: /en/newsletters/2023/05/24/#bips-1412
47+
4548
## Optional. Same format as "primary_sources" above
4649
# see_also:
4750
# - title:

0 commit comments

Comments
 (0)