Skip to content

Commit 94e77b2

Browse files
hardingbitschmidty
harding
authored and
bitschmidty
committed
Topcis: add multiple topics for Newsletter 283
1 parent 3acd779 commit 94e77b2

File tree

6 files changed

+450
-9
lines changed

6 files changed

+450
-9
lines changed

‎_posts/en/newsletters/2024-01-03-newsletter.md‎

Lines changed: 7 additions & 9 deletions
Original file line numberDiff line numberDiff line change
@@ -71,8 +71,8 @@ infrastructure.
7171
confirmed at an acceptable feerate.
7272

7373
Law notes that this addresses one of the longstanding concerns noted
74-
in the [original Lightning Network paper][] about _forced expiration
75-
floods_ where too many channels all closing simultaneously may
74+
in the [original Lightning Network paper][] about [forced expiration
75+
floods][topic expiration floods] where too many channels all closing simultaneously may
7676
result in insufficient block space for all of them to be
7777
confirmed before their timelocks expire, potentially resulting in
7878
some users losing money. With fee-dependent timelocks in place,
@@ -111,7 +111,7 @@ infrastructure.
111111
- **Cluster fee estimation:** Abubakar Sadiq Ismail [posted][ismail
112112
cluster] to Delving Bitcoin about using some of the tools and insights
113113
from the design of [cluster mempool][topic cluster mempool] to improve
114-
fee estimation in Bitcoin Core. The current fee estimation algorithm
114+
[fee estimation][topic fee estimation] in Bitcoin Core. The current fee estimation algorithm
115115
in Bitcoin Core tracks the number of blocks it takes for transactions
116116
entering the local node's mempool to become confirmed. When
117117
confirmation happens, the transaction's feerate is used to update a
@@ -229,10 +229,9 @@ infrastructure.
229229
- **Verification of arbitrary programs using proposed opcode from MATT:**
230230
Johan Torås Halseth [posted][halseth ccv] to Delving Bitcoin about
231231
[elftrace][], a proof of concept program that can use the
232-
`OP_CHECKCONTRACTVERIFY` opcode from the [MATT][] soft fork proposal
233-
to allow a party in a contract protocol to claim money if an arbitrary
234-
program executed successfully. It is similar in concept to BitVM (see
235-
[Newsletter #273][news273 bitvm]) but simpler in its Bitcoin
232+
`OP_CHECKCONTRACTVERIFY` opcode from the [MATT][topic matt] soft fork proposal
233+
to allow a party in a contract protocol to [claim money][topic pcac] if an arbitrary
234+
program executed successfully. It is similar in concept to [BitVM][topic pcac] but simpler in its Bitcoin
236235
implementation due to using an opcode specifically designed for
237236
program execution verification. Elftrace works with programs compiled
238237
for the RISC-V architecture using Linux's [ELF][] format; almost any
@@ -288,7 +287,7 @@ infrastructure.
288287
constructing party. Ingala roughly describes how this feature could
289288
be added to a multiparty contract protocol using [OP_CAT][],
290289
`OP_CHECKCONTRACTVERIFY`, and amount introspection from the proposed
291-
[MATT][] soft fork, with him noting that it would be easier with the
290+
[MATT][topic matt] soft fork, with him noting that it would be easier with the
292291
addition also of [OP_CSFS][topic op_checksigfromstack] and 64-bit
293292
arithmetic operators in [tapscript][topic tapscript].
294293

@@ -405,7 +404,6 @@ Proposals (BIPs)][bips repo], [Lightning BOLTs][bolts repo], and
405404
[black descpsbt]: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2023-November/022186.html
406405
[halseth ccv]: https://delvingbitcoin.org/t/verification-of-risc-v-execution-using-op-ccv/313
407406
[elftrace]: https://github.com/halseth/elftrace
408-
[matt]: /en/newsletters/2022/11/16/#general-smart-contracts-in-bitcoin-via-covenants
409407
[news273 bitvm]: /en/newsletters/2023/10/18/#payments-contingent-on-arbitrary-computation
410408
[elf]: https://en.m.wikipedia.org/wiki/Executable_and_Linkable_Format
411409
[ingala exit]: https://delvingbitcoin.org/t/aggregate-delegated-exit-for-l2-pools/297

‎_topics/en/ark.md‎

Lines changed: 71 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,71 @@
1+
---
2+
title: Ark
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+
# - Foo
11+
12+
## Required. At least one category to which this topic belongs. See
13+
## schema for options
14+
categories:
15+
- Contract Protocols
16+
17+
## Optional. Produces a Markdown link with either "[title][]" or
18+
## "[title](link)"
19+
primary_sources:
20+
- title: "Basis Of Ark Technology (BOATs)"
21+
link: https://github.com/ark-network/boats
22+
23+
## Optional. Each entry requires "title" and "url". May also use "feature:
24+
## true" to bold entry and "date"
25+
optech_mentions:
26+
- title: Proposal for a managed joinpool protocol
27+
url: /en/newsletters/2023/05/31/#proposal-for-a-managed-joinpool-protocol
28+
feature: true
29+
30+
- title: Improving LN scalability with covenants in a similar way to Ark
31+
url: /en/newsletters/2023/09/27/#using-covenants-to-improve-ln-scalability
32+
33+
## Optional. Same format as "primary_sources" above
34+
see_also:
35+
- title: Joinpools
36+
link: topic joinpools
37+
38+
- title: Covenants
39+
link: topic covenants
40+
41+
## Optional. Force the display (true) or non-display (false) of stub
42+
## topic notice. Default is to display if the page.content is below a
43+
## threshold word count
44+
#stub: false
45+
46+
## Required. Use Markdown formatting. Only one paragraph. No links allowed.
47+
## Should be less than 500 characters
48+
excerpt: >
49+
**Ark** is a trustless joinpool-style protocol where a large numbers
50+
of users share a UTXO by accepting a counterparty as a co-signer on
51+
all transactions within a certain time period. This spreads the cost
52+
of onchain fees from using that UTXO across many users, minimizing
53+
their individual costs.
54+
55+
---
56+
The users can either unilaterally withdraw their bitcoins onchain
57+
after the expiry of the time period or instantly and trustlessly
58+
transfer them offchain to the counterparty before the end of the time
59+
period. Normally, a user will simply roll their bitcoins into another
60+
contract with the counterparty, which can be highly fee efficient when
61+
done with many other users at the same time. Alternatively, the
62+
counterparty may help the user make an LN payment, which also doesn't
63+
incur onchain fees.
64+
65+
Ark can be implemented on Bitcoin with no consensus changes required,
66+
but it will support a larger number of users---making it much more fee
67+
efficient---if a [covenant][topic covenants] feature is added to
68+
Bitcoin.
69+
70+
{% include references.md %}
71+
{% include linkers/issues.md issues="" %}

‎_topics/en/expiration-floods.md‎

Lines changed: 138 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,138 @@
1+
---
2+
title: Expiration floods
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+
- Forced expiration spam
11+
- Flood and loot
12+
13+
## Required. At least one category to which this topic belongs. See
14+
## schema for options
15+
categories:
16+
- Contract Protocols
17+
- Lightning Network
18+
- Security Problems
19+
- Security Enhancements
20+
21+
## Optional. Produces a Markdown link with either "[title][]" or
22+
## "[title](link)"
23+
primary_sources:
24+
- title: "The Bitcoin Lightning Network: Scalable Off-Chain Instant Payments"
25+
link: https://lightning.network/lightning-network-paper.pdf
26+
27+
- title: "Flood & Loot: A Systemic Attack On The Lightning Network"
28+
link: https://arxiv.org/abs/2006.08513
29+
30+
## Optional. Each entry requires "title" and "url". May also use "feature:
31+
## true" to bold entry and "date"
32+
optech_mentions:
33+
- title: LN developer discussion about flood and loot attacks
34+
url: /en/newsletters/2020/08/05/#chicago-meetup-discussion
35+
36+
- title: Concern about forced expiration spam in very large channel factories
37+
url: /en/newsletters/2023/09/27/#using-covenants-to-improve-ln-scalability
38+
39+
- title: Mitigating expiration floods with fee-depedent timelocks
40+
url: /en/newsletters/2024/01/03/#fee-dependent-timelocks
41+
42+
## Optional. Same format as "primary_sources" above
43+
see_also:
44+
- title: HTLCs
45+
link: topic htlc
46+
47+
- title: PTLCs
48+
link: topic ptlc
49+
50+
## Optional. Force the display (true) or non-display (false) of stub
51+
## topic notice. Default is to display if the page.content is below a
52+
## threshold word count
53+
#stub: false
54+
55+
## Required. Use Markdown formatting. Only one paragraph. No links allowed.
56+
## Should be less than 500 characters
57+
excerpt: >
58+
**Expiration floods** occur when many timelock-contingent payments are
59+
broadcast simultaneously. If not all of them can fit into blocks
60+
before their timelocks begin expiring, users are guaranteed to lose
61+
money.
62+
63+
---
64+
For example, Mallory runs a very popular LN node with many users. Each
65+
channel has the maximum-allowed number of incoming and outgoing pending
66+
[HTLCs][topic htlc], making the cost to resolve each of those channels
67+
onchain around 100,000 vbytes. A full block can only fit about 10 of
68+
those channels. If the most critical [timelocks][topic timelocks] on
69+
some of the HTLCs might expire in 10 blocks or less, Mallory can force
70+
close more than 100 of those channels to eliminate the guarantee that
71+
her honest counterparties will receive their money.
72+
73+
Although an expiration flood can be triggered deliberately by a
74+
malicious counterparty, it can also happen accidentally either by
75+
coincidence or by a situation that causes many users to attempt to close
76+
their channels simultaneously, e.g. a bug in a software implementation.
77+
In the accidental case, some honest users will get their money and other
78+
honest users may not, even though they all followed the protocol
79+
faithfully.
80+
81+
Expiration floods were described in the original [Lightning Network
82+
paper][] under the name **forced expiration spam**. A later
83+
[paper][flood and loot] called the attack **flood and loot**. Concern
84+
about expiration floods has heavily influenced the development of LN and
85+
other offchain protocols.
86+
87+
Mitigations that don't require consensus changes include:
88+
89+
- **Minimizing onchain enforcement data:** designing protocols and
90+
setting limits so that timelock-contingent payments are small. For
91+
example, many LN implementations default to accepting and creating
92+
much less than the protocol-allowed maximum number of pending HTLCs.
93+
(That also helps mitigate other attacks.)
94+
95+
- **Using long timelocks when possible:** in our example above, Mallory
96+
needs to close at least 100 channels with 10-block timelocks. If the
97+
timelocks were 100 blocks, she'd need to close 1,000 channels
98+
simultaneously. It would take more effort on her part to find that
99+
many victims and get their channels into an exploitable state.
100+
101+
- **Improving counterparty decentralization:** someone who is a
102+
counterparty to 100 users has more power to execute an expiration
103+
flood attack than someone who is only counterparty to 10 users.
104+
This suggests that a less centralized distribution of counterparties
105+
might be safer against deliberately triggered expiration floods.
106+
Of course, in privacy-protecting protocols, it may be impossible to
107+
prove that two counterparties are distinct entities and not colluding.
108+
109+
Proposed mitigations that require consensus changes include:
110+
111+
- **Dynamic bounded block sizes:** this would allow miners to create larger
112+
blocks during high periods of demand so that they can confirm more
113+
transactions during an expiration flood. [Proposals][friedenbach
114+
dynamic] of this [nature][maxwell dynamic]
115+
usually require miners to pay a cost for creating higher blocks, such
116+
as destroying bitcoins are generating more proof of work. The lost
117+
bitcoins and work are expected to be compensated for by the extra fee
118+
income they will receive from confirming urgent transactions.
119+
120+
- **Fee-dependent timelocks:** [this][fdt] would prevent a timelock from
121+
expiring when feerates were above a specified amount. If too many
122+
timelock-contingent payments entered the mempool at once; the users
123+
would bid up their feerates in competition with each other to get
124+
their transactions confirmed before the regular timelocks expired.
125+
When feerates exceeded the fee-dependent timelock, expiration of those
126+
timelocks would be delayed, keeping those users safe until feerates
127+
reduced. As long as the user paid a feerate above their fee-dependent
128+
timelock amount, their transaction should confirm before the timelock
129+
expires, ensuring the user's desired transaction gets confirmed before
130+
the timelock expires.
131+
132+
{% include references.md %}
133+
{% include linkers/issues.md issues="" %}
134+
[lightning network paper]: https://lightning.network/lightning-network-paper.pdf
135+
[flood and loot]: https://arxiv.org/abs/2006.08513
136+
[friedenbach dynamic]: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-May/008017.html
137+
[maxwell dynamic]: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-May/008038.html
138+
[fdt]: /en/newsletters/2024/01/03/#fee-dependent-timelocks

‎_topics/en/fee-estimation.md‎

Lines changed: 67 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,67 @@
1+
---
2+
title: Fee estimation
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+
# - Foo
11+
12+
## Required. At least one category to which this topic belongs. See
13+
## schema for options
14+
categories:
15+
- Fee Management
16+
17+
## Optional. Produces a Markdown link with either "[title][]" or
18+
## "[title](link)"
19+
primary_sources:
20+
- title: "Bitcoin Core Fee Estimation Algorithm (2017)"
21+
link: https://gist.github.com/morcos/d3637f015bc4e607e1fd10d8351e9f41
22+
23+
## Optional. Each entry requires "title" and "url". May also use "feature:
24+
## true" to bold entry and "date"
25+
optech_mentions:
26+
- title: "LND #4078 adds an `estimatemode` configuration setting for configuring its fee estimation"
27+
url: /en/newsletters/2020/04/01/#lnd-4078
28+
29+
- title: "Bitcoin Core #18766 disables the ability to get fee estimates when using blocks-only mode"
30+
url: /en/newsletters/2020/12/16/#bitcoin-core-18766
31+
32+
- title: "Bitcoin Core #22539 includes replacement transactions seen by the local node in fee estimates"
33+
url: /en/newsletters/2021/10/20/#bitcoin-core-22539
34+
35+
- title: "ECDSA signature grinding helps with fee estimation"
36+
url: /en/newsletters/2022/01/26/#what-is-signature-grinding
37+
38+
- title: "Rust Bitcoin #2213 amends the weight prediction for P2WPKH inputs during fee estimation"
39+
url: /en/newsletters/2023/11/29/#rust-bitcoin-2213
40+
41+
- title: "BTCPay Server #5490 begins using fee estimates from mempool.space"
42+
url: /en/newsletters/2023/12/13/#btcpay-server-5490
43+
44+
- title: "Cluster fee estimation to improve accuracy in a world with CPFP fee bumping"
45+
url: /en/newsletters/2024/01/03/#cluster-fee-estimation
46+
47+
## Optional. Same format as "primary_sources" above
48+
see_also:
49+
- title: Coin selection
50+
link: topic coin selection
51+
52+
## Optional. Force the display (true) or non-display (false) of stub
53+
## topic notice. Default is to display if the page.content is below a
54+
## threshold word count
55+
#stub: false
56+
57+
## Required. Use Markdown formatting. Only one paragraph. No links allowed.
58+
## Should be less than 500 characters
59+
excerpt: >
60+
**Fee estimation** is the process of estimating the feerate a
61+
transaction will need to pay to have a high probability of being
62+
confirmed within a certain number of blocks.
63+
64+
---
65+
66+
{% include references.md %}
67+
{% include linkers/issues.md issues="" %}

‎_topics/en/matt.md‎

Lines changed: 66 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,66 @@
1+
---
2+
title: MATT
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+
- OP_CHECKCONTRACTVERIFY
11+
12+
## Required. At least one category to which this topic belongs. See
13+
## schema for options
14+
categories:
15+
- Soft Forks
16+
17+
## Optional. Produces a Markdown link with either "[title][]" or
18+
## "[title](link)"
19+
primary_sources:
20+
- title: Merkleize All The Things
21+
link: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-November/021182.html
22+
23+
## Optional. Each entry requires "title" and "url". May also use "feature:
24+
## true" to bold entry and "date"
25+
optech_mentions:
26+
- title: Proposal for general smart contracts in Bitcoin via covenants
27+
url: /en/newsletters/2022/11/16/#general-smart-contracts-in-bitcoin-via-covenants
28+
29+
- title: MATT-based vaults
30+
url: /en/newsletters/2023/05/03/#matt-based-vaults
31+
32+
- title: Using MATT to replicate CTV and manage joinpools
33+
url: /en/newsletters/2023/06/07/#using-matt-to-replicate-ctv-and-manage-joinpools
34+
35+
- title: What opcodes are part of the MATT proposal?
36+
url: /en/newsletters/2023/08/30/#what-opcodes-are-part-of-the-matt-proposal
37+
38+
- title: Verification of arbitrary programs using proposed opcode from MATT
39+
url: /en/newsletters/2024/01/03/#verification-of-arbitrary-programs-using-proposed-opcode-from-matt
40+
41+
## Optional. Same format as "primary_sources" above
42+
see_also:
43+
- title: Covenants
44+
link: topic covenants
45+
46+
- title: OP_CHECKTEMPLATEVERIFY
47+
link: topic op_checktemplateverify
48+
49+
## Optional. Force the display (true) or non-display (false) of stub
50+
## topic notice. Default is to display if the page.content is below a
51+
## threshold word count
52+
#stub: false
53+
54+
## Required. Use Markdown formatting. Only one paragraph. No links allowed.
55+
## Should be less than 500 characters
56+
excerpt: >
57+
**MATT** is a soft fork proposal that would add a `OP_CHECKCONTRACTVERIFY`
58+
opcode to Bitcoin's script language and make some other changes that
59+
would allow limited transaction introspection. This could allow
60+
verification of arbitrary programs in contract protocols plus
61+
support the implementation of several covenant-based features.
62+
63+
---
64+
65+
{% include references.md %}
66+
{% include linkers/issues.md issues="" %}

0 commit comments

Comments
 (0)