Skip to content

Commit 66dc34b

Browse files
hardingbitschmidty
authored andcommitted
Newsletters: add 315 (2024-08-09)
1 parent dcd385c commit 66dc34b

18 files changed

Lines changed: 640 additions & 47 deletions

_includes/references.md

Lines changed: 2 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -110,6 +110,8 @@ for details --> {% endcomment %}
110110
[BIP90]: https://github.com/bitcoin/bips/blob/master/bip-0090.mediawiki
111111
[BIP91]: https://github.com/bitcoin/bips/blob/master/bip-0091.mediawiki
112112
[BIP93]: https://github.com/bitcoin/bips/blob/master/bip-0093.mediawiki
113+
[BIP94]: https://github.com/bitcoin/bips/blob/master/bip-0094.mediawiki
114+
[BIP103]: https://github.com/bitcoin/bips/blob/master/bip-0103.mediawiki
113115
[BIP111]: https://github.com/bitcoin/bips/blob/master/bip-0111.mediawiki
114116
[BIP112]: https://github.com/bitcoin/bips/blob/master/bip-0112.mediawiki
115117
[BIP113]: https://github.com/bitcoin/bips/blob/master/bip-0113.mediawiki

_posts/en/newsletters/2024-08-09-newsletter.md

Lines changed: 360 additions & 0 deletions
Large diffs are not rendered by default.

_topics/en/acc.md

Lines changed: 3 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -49,6 +49,9 @@ optech_mentions:
4949
- title: "BitVMX: an alternative to BitVM for verification of program execution"
5050
url: /en/newsletters/2024/05/17/#alternative-to-bitvm
5151

52+
- title: "Optimistic verification of zero-knowledge proofs using CAT, MATT, and Elftrace"
53+
url: /en/newsletters/2024/08/09/#optimistic-verification-of-zero-knowledge-proofs-using-cat-matt-and-elftrace
54+
5255
## Optional. Same format as "primary_sources" above
5356
see_also:
5457
- title: "Merklize All The Things (MATT)"

_topics/en/block-withholding.md

Lines changed: 89 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,89 @@
1+
---
2+
title: Block withholding
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+
title-aliases:
10+
- Oblivious shares
11+
12+
## Required. At least one category to which this topic belongs. See
13+
## schema for options
14+
topic-categories:
15+
- Mining
16+
17+
## Optional. Produces a Markdown link with either "[title][]" or
18+
## "[title](link)"
19+
primary_sources:
20+
- title: "Analysis of Bitcoin Pooled Mining Reward Systems (section 6.2: block withholding)"
21+
link: https://bitcoil.co.il/pool_analysis.pdf
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: Block withholding attacks and potential solutions
27+
url: /en/newsletters/2024/08/09/#block-withholding-attacks-and-potential-solutions
28+
29+
## Optional. Same format as "primary_sources" above
30+
see_also:
31+
- title: Pooled mining
32+
link: topic pooled mining
33+
34+
## Optional. Force the display (true) or non-display (false) of stub
35+
## topic notice. Default is to display if the page.content is below a
36+
## threshold word count
37+
#stub: false
38+
39+
## Required. Use Markdown formatting. Only one paragraph. No links allowed.
40+
## Should be less than 500 characters
41+
excerpt: >
42+
**Block withholding** is an attack against pooled mining where a miner
43+
submits and receives payment for shares that are not eligible to
44+
become full blocks but doesn't not submit shares that are eligible to
45+
become full blocks. This allows the miner to earn 99.9% of their
46+
expected revenue without the pool earning anything from the miner's
47+
work. **Oblivious shares** is a proposed solution to block
48+
withholding.
49+
50+
---
51+
In [pooled mining][topic pooled mining], there are two types of shares:
52+
those that have
53+
enough work to be a valid block and those that don't. In a pure
54+
pay-per-share (PPS) scheme, the pool pays the same amount for both types
55+
but the pool only earns rewards from the Bitcoin system for producing
56+
valid blocks. This can allow a pool member to forfeit a small amount of
57+
income in order to deny the pool a large amount of income.
58+
59+
For example, imagine the ratio between the network proof-of-work (PoW)
60+
target and the pool share target is 1,000, so for every 1,000 shares
61+
submitted by pool members,
62+
the pool would be expected to find one block on average. Malicious
63+
pool member Mallory submits each share she finds except those that have
64+
enough proof of work to be valid blocks. On average, Mallory gets
65+
paid for 999 shares out of every 1,000 she generates, reducing her
66+
income by 0.1% but costing the pool 100% of a block reward for every
67+
1,000 shares generated by Mallory.
68+
69+
If Mallory operates a pool, she might be motivated to use block
70+
withholding attacks against other pools, significantly reducing their
71+
profitability and potentially driving them out of business to Mallory's
72+
advantage.
73+
74+
We are unaware of any deployed method that fully addresses this problem.
75+
A common mitigation is for pools to pay more for shares that have enough
76+
work to be a valid block (which implies paying less for other shares).
77+
Some pools also restrict who can join their pools and use techniques
78+
from statistical analysis to attempt to detect block withholders.
79+
80+
A proposed solution is _oblivious shares_, which prevents the miner
81+
creating the share from determining whether it meets the network PoW
82+
target. Only the pool can make that determination, preventing the miner
83+
from being able to selectively withhold shares that would benefit the
84+
pool. Adding support for oblivious shares to Bitcoin requires a hard
85+
fork and may create [other problems][news315 oblivious].
86+
87+
{% include references.md %}
88+
{% include linkers/issues.md issues="" %}
89+
[news315 oblivious]: /en/newsletters/2024/08/09/#block-withholding-attacks-and-potential-solutions

_topics/en/compact-block-relay.md

Lines changed: 3 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -57,6 +57,9 @@ optech_mentions:
5757
- title: "Proposal to use weak blocks to improve compact block relay when mempool policies diverge"
5858
url: /en/newsletters/2024/04/24/#weak-blocks-proof-of-concept-implementation
5959

60+
- title: "Recent statistics on the success rate of compact block reconstruction"
61+
url: /en/newsletters/2024/08/09/#statistics-on-compact-block-reconstruction
62+
6063
## Optional. Same format as "primary_sources" above
6164
# see_also:
6265
# - title:

_topics/en/ephemeral-anchors.md

Lines changed: 6 additions & 2 deletions
Original file line numberDiff line numberDiff line change
@@ -6,8 +6,9 @@ title: Ephemeral anchors
66
# shortname: foo
77

88
## Optional. An entry will be added to the topics index for each alias
9-
#title-aliases:
10-
# - Foo
9+
title-aliases:
10+
- "Pay-to-Anchor (P2A)"
11+
- Ephemeral dust
1112

1213
## Required. At least one category to which this topic belongs. See
1314
## schema for options
@@ -59,6 +60,9 @@ optech_mentions:
5960
- title: Proposed changes to LN for v3 relay and ephemeral anchors
6061
url: /en/newsletters/2024/01/24/#proposed-changes-to-ln-for-v3-relay-and-ephemeral-anchors
6162

63+
- title: Description of a replacement cycling attack against transactions using P2A
64+
url: /en/newsletters/2024/08/09/#replacement-cycle-attack-against-pay-to-anchor
65+
6266
## Optional. Same format as "primary_sources" above
6367
see_also:
6468
- title: V3 Transaction Relay

_topics/en/exfiltration-resistant-signing.md

Lines changed: 6 additions & 3 deletions
Original file line numberDiff line numberDiff line change
@@ -1,5 +1,5 @@
11
---
2-
title: Exfiltration resistant signing
2+
title: Exfiltration-resistant signing
33

44
## Optional. Shorter name to use for reference style links e.g., "foo"
55
## will allow using the link [topic foo][]. Not case sensitive
@@ -24,7 +24,7 @@ primary_sources:
2424
## Optional. Each entry requires "title", "url", and "date". May also use "feature:
2525
## true" to bold entry
2626
optech_mentions:
27-
- title: Proposal to standardize an exfiltration resistant nonce protocol
27+
- title: Proposal to standardize an exfiltration-resistant nonce protocol
2828
url: /en/newsletters/2020/03/04/#proposal-to-standardize-an-exfiltration-resistant-nonce-protocol
2929

3030
- title: Overview of anti-covert-channel signing techniques
@@ -33,6 +33,9 @@ optech_mentions:
3333
- title: Description of anti-exfiltration technique being used in BitBox02 and Jade hardware wallets
3434
url: /en/newsletters/2021/02/17/#anti-exfiltration
3535

36+
- title: "Dark Skippy: faster exfiltration of HD wallet seeds"
37+
url: /en/newsletters/2024/08/09/#faster-seed-exfiltration-attack
38+
3639
## Optional. Same format as "primary_sources" above
3740
# see_also:
3841
# - title:
@@ -41,7 +44,7 @@ optech_mentions:
4144
## Required. Use Markdown formatting. Only one paragraph. No links allowed.
4245
## Should be less than 500 characters
4346
excerpt: >
44-
**Exfiltration resistant signing** is the process of creating
47+
**Exfiltration-resistant signing** is the process of creating
4548
signatures for Bitcoin transactions using a protocol that can be
4649
audited to ensure the signature doesn't contain any biased or
4750
otherwise manipulated elements that could be used to compromise the

_topics/en/hwi.md

Lines changed: 2 additions & 2 deletions
Original file line numberDiff line numberDiff line change
@@ -78,8 +78,8 @@ see_also:
7878
- title: Miniscript
7979
link: topic miniscript
8080

81-
- title: Exfiltration resistant signing
82-
link: topic exfiltration resistant signing
81+
- title: Exfiltration-resistant signing
82+
link: topic exfiltration-resistant signing
8383
---
8484
Designed primarily by Bitcoin Core developers to allow that software to
8585
use hardware wallets as external signers, HWI is now being used by

_topics/en/pooled-mining.md

Lines changed: 3 additions & 35 deletions
Original file line numberDiff line numberDiff line change
@@ -11,7 +11,6 @@ title-aliases:
1111
- Braidpool
1212
- Stratum
1313
- Stratum v2
14-
- Block withholding attack
1514

1615
## Required. At least one category to which this topic belongs. See
1716
## schema for options
@@ -74,8 +73,7 @@ excerpt: >
7473
collaborate on finding proof of work for new blocks, with them fairly
7574
dividing the rewards of any blocks they find. **Betterhash**,
7675
**Braidpool**, **Stratum**, and **Stratum v2** are protocols for
77-
coordinating pooled mining. A **block withholding attack** is a
78-
well-known attack against pooled mining.
76+
coordinating pooled mining.
7977
8078
---
8179
Hashing a block header will produce a value that can be interpreted as a
@@ -128,36 +126,6 @@ Pools may impose additional requirements on their members, either
128126
explicitly or by using a pool protocol that does not give members the
129127
flexibility to make certain choices.
130128

131-
## Block withholding attacks
132-
133-
Pooled mining is fundamentally vulnerable to a problem known as a _block
134-
withholding attack_. There are two types of shares: those that have
135-
enough work to be a valid block and those that don't. In a pure
136-
pay-per-share (PPS) scheme, the pool pays the same amount for both types
137-
but the pool only earns rewards from the Bitcoin system for producing
138-
valid blocks. This can allow a pool member to forfeit a small amount of
139-
income in order to deny the pool a large amount of income.
140-
141-
For example, imagine the ratio between the primary target and secondary
142-
target is 1,000, so for every 1,000 shares submitted by pool members,
143-
the pool would be expected to find one block on average. Malicious
144-
pool member Mallory submits each share she finds except those that have
145-
enough proof of work to be valid blocks. On average, Mallory gets
146-
paid for 999 shares out of every 1,000 she generates, reducing her
147-
income by 0.1% but costing the pool 100% of a block reward for every
148-
1,000 shares generated by Mallory.
149-
150-
If Mallory operates a pool, she might be motivated to use block
151-
witholding attacks against other pools, significantly reducing their
152-
profitability and potentially driving them out of business to Mallory's
153-
advantage.
154-
155-
We are unaware of any deployed method that fully addresses this problem.
156-
A common mitigation is for pools to pay more for shares that have enough
157-
work to be a valid block (which implies paying less for other shares).
158-
Some pools also restrict who can join their pools and use techniques
159-
from statistical analysis to attempt to detect block withholders.
160-
161129
## Pool protocols
162130

163131
The earliest pool protocol was built around transmitting block header
@@ -248,8 +216,8 @@ descriptions and from other pools.
248216
1.44 blocks per day and so would need to pay out rewards for about
249217
1.44 blocks worth of shares every day. However, that pool might go
250218
days without actually finding a block, requiring them to maintain a
251-
significant amount of capital. Additionally, even a slight block
252-
withholding attack could reduce pool profitability below a
219+
significant amount of capital. Additionally, even a slight [block
220+
withholding attack][topic block withholding] could reduce pool profitability below a
253221
sustainable level.
254222

255223
- **Full pay per share (FPPS)** works like PPS but includes transaction

_topics/en/replace-by-fee.md

Lines changed: 3 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -192,6 +192,9 @@ optech_mentions:
192192
- title: "Question: why does RBF rule #3 exist?"
193193
url: /en/newsletters/2024/07/26/#why-does-rbf-rule-3-exist
194194

195+
- title: "Nodes with full-RBF successfully reconstructing more compact blocks than nodes with only opt-in RBF"
196+
url: /en/newsletters/2024/08/09/#replacement-cycle-attack-against-pay-to-anchor
197+
195198
## Optional. Same format as "primary_sources" above
196199
see_also:
197200
- title: Transaction pinning

0 commit comments

Comments
 (0)