Skip to content

Commit f3f9b7a

Browse files
hardingjnewbery
harding
authored and
jnewbery
committed
New Topics: anchor outputs, BIP70, eclipse attacks, OP_CODESEPARATOR
1 parent 05250e8 commit f3f9b7a

File tree

5 files changed

+428
-0
lines changed

5 files changed

+428
-0
lines changed

‎_includes/references.md

Lines changed: 2 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -10,6 +10,7 @@
1010
[topic compact block filters]: /en/topics/compact-block-filters/
1111
[topic consensus cleanup]: /en/topics/consensus-cleanup-soft-fork/
1212
[topic covenants]: /en/topics/covenants/
13+
[topic cpfp]: /en/topics/cpfp/
1314
[topic cpfp carve out]: /en/topics/cpfp-carve-out/
1415
[topic descriptors]: /en/topics/output-script-descriptors/
1516
[topic eltoo]: /en/topics/eltoo/
@@ -24,6 +25,7 @@
2425
[topic psbt]: /en/topics/psbt/
2526
[topic rbf]: /en/topics/replace-by-fee/
2627
[topic reproducible builds]: /en/topics/reproducible-builds/
28+
[topic rbf]: /en/topics/replace-by-fee/
2729
[topic schnorr signatures]: /en/topics/schnorr-signatures/
2830
[topic sighash_noinput]: /en/topics/sighash_noinput/
2931
[topic signet]: /en/topics/signet/

‎_topics/en/anchor-outputs.md

Lines changed: 79 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,79 @@
1+
---
2+
title: Anchor outputs
3+
4+
## Optional. An entry will be added to the topics index for each alias
5+
aliases:
6+
- Simplified commitments
7+
8+
## Required. At least one category to which this topic belongs. See
9+
## schema for options
10+
categories:
11+
- Lightning Network
12+
13+
## Required. Use Markdown formatting. Only one paragraph. No links allowed.
14+
## Should be less than 500 characters
15+
excerpt: >
16+
**Anchor outputs** are special outputs in LN commitment transactions
17+
that are designed to allow the transaction to be fee bumped. An
18+
earlier name for the proposal was **simplified commitments.**
19+
20+
## Optional. Use Markdown formatting. Multiple paragraphs. Links allowed.
21+
extended_summary: |
22+
Each time the balance changes in an LN channel, a *commitment
23+
transaction* is created and signed by the participating parties. The
24+
transaction is only broadcast if one party decides to
25+
unilaterally close the channel (e.g. because the other party has
26+
become unresponsive). Because the broadcast of the commitment
27+
transaction may occur a long time after it was created, the commitment
28+
transaction may pay too much or too little in transaction fees.
29+
Paying a too-low feerate may prevent the commitment transaction from
30+
confirming before any timelocks contained within it expire, allowing
31+
funds to be stolen.
32+
33+
The solution to this is for the commitment transaction to pay a
34+
minimal amount of fees and then to allow either channel participant to fee
35+
bump the transaction. Early designs to accomplish this using [Replace-by-Fee
36+
(RBF)][topic rbf] fee bumping ran into problems with [transaction
37+
pinning][topic transaction pinning]. Later designs used
38+
[Child Pays For Parent (CPFP)][topic cpfp] fee bumping and came to
39+
depend on [CPFP carve-out][topic cpfp carve out] to circumvent the
40+
pinning problem.
41+
42+
As of this writing, the most recent versions of the design add two
43+
outputs to the commitment transaction---one for each LN party---and
44+
require all other outputs in the commitment transaction to have their
45+
scripts encumbered by a `1 OP_CHECKSEQUENCEVERIFY` (CSV) condition
46+
that prevents them from being spent for at least one block.
47+
48+
<!-- TODO: mention package relay here if we add a topic for that -->
49+
50+
## Optional. Produces a Markdown link with either "[title][]" or
51+
## "[title](link)"
52+
primary_sources:
53+
- title: Anchor outputs
54+
link: https://github.com/lightningnetwork/lightning-rfc/pull/688
55+
56+
## Optional. Each entry requires "title", "url", and "date". May also use "feature:
57+
## true" to bold entry
58+
optech_mentions:
59+
- title: Simplified fee bumping for LN
60+
url: /en/newsletters/2018/11/27/#simplified-fee-bumping-for-ln
61+
date: 2018-11-27
62+
63+
- title: LN simplified commitments discussion
64+
url: /en/newsletters/2019/10/30/#ln-simplified-commitments
65+
date: 2019-10-30
66+
67+
- title: Continued discussion of LN anchor outputs
68+
url: /en/newsletters/2019/11/06/#continued-discussion-of-ln-anchor-outputs
69+
date: 2019-11-06
70+
71+
- title: "2019 year-in-review: anchor outputs"
72+
url: /en/newsletters/2019/12/28/#anchor-outputs
73+
date: 2019-12-28
74+
75+
## Optional. Same format as "primary_sources" above
76+
see_also:
77+
- title: CPFP carve-out
78+
link: topic cpfp carve out
79+
---

‎_topics/en/bip70-payment-protocol.md

Lines changed: 120 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,120 @@
1+
---
2+
title: BIP70 payment protocol
3+
4+
## Optional. An entry will be added to the topics index for each alias
5+
#aliases:
6+
# - Foo
7+
8+
## Required. At least one category to which this topic belongs. See
9+
## schema for options
10+
categories:
11+
- Wallet Collaboration Tools
12+
13+
## Required. Use Markdown formatting. Only one paragraph. No links allowed.
14+
## Should be less than 500 characters
15+
excerpt: >
16+
**The BIP70 payment protocol** is an interactive protocol for
17+
sending payment requests and receiving payments.
18+
19+
## Optional. Use Markdown formatting. Multiple paragraphs. Links allowed.
20+
extended_summary: |
21+
The protocol involves several steps:
22+
23+
- Customer clicks a [BIP21][] `bitcoin:` URI extended with an
24+
additional `r` parameter (described in [BIP72][]). The URI handler
25+
opens the user's wallet in response
26+
27+
- The wallet contacts the merchant's server and asks for a payment request
28+
signed by the merchant's SSL certificate. Upon receipt and
29+
validation of the signed payment request, the payment details are
30+
automatically filled out on the wallet's *Send Transaction* screen.
31+
Optionally, the user is notified that they're paying the owner of
32+
the domain corresponding to signing certificate (e.g.
33+
"example.com")
34+
35+
- The customer reviews the payment details and clicks the *Send
36+
Transaction* button. The transaction is generated and broadcast to
37+
the Bitcoin network. A copy of the transaction is sent to the
38+
merchant, who then replies with an acknowledgment that the payment
39+
was received (optionally rebroadcasting the transaction from their
40+
own nodes)
41+
42+
The protocol had several advantages over plain BIP21 URIs:
43+
44+
- The merchant could request payment to any script---not just one
45+
of the popular address types---making the proposal forward
46+
compatible with new address formats
47+
48+
- The customer's wallet automatically sent their own script to be
49+
used in case a refund needed to be issued
50+
51+
- Payment requests had an expiration date after which point the quoted price
52+
would no longer apply
53+
54+
- It gave the spending transaction directly to the merchant,
55+
allowing them to broadcast it. This could allow a user to pay
56+
using Bluetooth or NFC even if they didn't currently have
57+
a connection to the Internet
58+
59+
Its main disadvantage was that it required that spenders support the SSL
60+
certificate system, which includes many algorithms not otherwise used
61+
in Bitcoin and a complex Public Key Infrastructure (PKI) system. In
62+
practice, this meant software needed to include a library such as
63+
OpenSSL as a dependency. Bugs in that library could then be used to
64+
exploit Bitcoin programs, such as the OpenSSL [heartbleed][]
65+
vulnerability that potentially allowed attackers to [access private
66+
keys][core heartbleed] from Bitcoin Core in 2014.
67+
68+
Ultimately, BIP70 never saw widespread adoption and almost all
69+
merchants and wallets that did once support it have either ended
70+
support or plan to end their support in the future.
71+
72+
[heartbleed]: http://heartbleed.com/
73+
[core heartbleed]: https://bitcoin.org/en/alert/2014-04-11-heartbleed
74+
75+
## Optional. Produces a Markdown link with either "[title][]" or
76+
## "[title](link)"
77+
primary_sources:
78+
## BIPs 70, 71, 72 were part of the original protocol. BIPs 73, 74,
79+
## 75 are all related to BIP70 but were extensions that came later, so
80+
## they probably shouldn't be linked as primary documentation
81+
- title: BIP70
82+
- title: BIP71
83+
- title: BIP72
84+
85+
## Optional. Each entry requires "title", "url", and "date". May also use "feature:
86+
## true" to bold entry
87+
optech_mentions:
88+
- title: Pay-to-EndPoint (P2EP) has elements similar to BIP70
89+
url: /en/newsletters/2018/08/14/#pay-to-end-point-p2ep-idea-proposed
90+
date: 2018-08-14
91+
92+
- title: "Bitcoin Core PR#14451 allows building Bitcoin-Qt without BIP70 support"
93+
url: /en/newsletters/2018/10/30/#bitcoin-core-14451
94+
date: 2018-10-30
95+
96+
- title: "Bitcoin Core PR#15063 allows falling back to BIP21 parsing of BIP72 URIs"
97+
url: /en/newsletters/2019/02/19/#bitcoin-core-15063
98+
date: 2019-02-19
99+
100+
- title: "Bitcoin Core PR#15584 disables support for BIP70 by default"
101+
url: /en/newsletters/2019/09/18/#bitcoin-core-15584
102+
date: 2019-09-18
103+
104+
- title: "Bitcoin Core PR#17165 removes support for BIP70 payment protocol"
105+
url: /en/newsletters/2019/10/30/#bitcoin-core-17165
106+
date: 2019-10-30
107+
108+
- title: "Bitcoin Core 0.19 released with BIP70 support disabled by default"
109+
url: /en/newsletters/2019/11/27/#deprecated-or-removed-features
110+
date: 2019-11-27
111+
112+
- title: "2019 year-in-review: Bitcoin Core BIP70 deprecation and disablement"
113+
url: /en/newsletters/2019/12/28/#bip70
114+
date: 2019-12-28
115+
116+
## Optional. Same format as "primary_sources" above
117+
# see_also:
118+
# - title:
119+
# link:
120+
---

‎_topics/en/eclipse-attacks.md

Lines changed: 77 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,77 @@
1+
---
2+
title: Eclipse attacks
3+
4+
## Optional. An entry will be added to the topics index for each alias
5+
#aliases:
6+
# - Foo
7+
8+
## Required. At least one category to which this topic belongs. See
9+
## schema for options
10+
categories:
11+
- P2P Network Protocol
12+
- Security Problems
13+
14+
## Required. Use Markdown formatting. Only one paragraph. No links allowed.
15+
## Should be less than 500 characters
16+
excerpt: >
17+
**Eclipse attacks** occur when a node is isolated from all honest
18+
peers but remains connected to at least one malicious peer.
19+
20+
## Optional. Use Markdown formatting. Multiple paragraphs. Links allowed.
21+
extended_summary: |
22+
Without any connections to honest peers, the eclipsed node won't
23+
receive the latest blocks on the most proof-of-work block chain. This
24+
gives the attacker an unlimited amount of time to generate blocks
25+
containing double spends, so even an attacker with a small minority of
26+
hash rate can trick the victim into accepting confirmed double spends.
27+
28+
The attacker will also control what transactions the victim's node
29+
receives. This allows them to tell the node about transactions not
30+
generally available on the network in order to prompt the victim's
31+
node into taking an action (e.g. the attacker sends a transaction
32+
closing an LN channel only to the eclipsed node).
33+
34+
Finally, the attacker can control what transactions the victim can
35+
send. This allows the attacker to prevent the victim from sending
36+
time-critical transactions such as LN penalty transactions. It also
37+
means that any transactions generated by the victim can be
38+
definitively identified as originating from the victim---a loss of
39+
privacy.
40+
41+
To prevent eclipse attacks, node operators are encouraged to run their
42+
nodes on [multiple network interfaces][] and, when possible, to maintain
43+
connections to at least a few other nodes over secure networks (e.g.
44+
VPNs). Within the limits possible for nodes with only a single
45+
interface, Bitcoin Core developers work to ensure the node connects to
46+
a large and diverse set of peers to reduce the chance that every one
47+
of a node's peers is the same [sybil attacker][sybil attack].
48+
49+
[sybil attack]: https://en.wikipedia.org/wiki/Sybil_attack
50+
[multiple network interfaces]: https://en.wikipedia.org/wiki/Multihoming
51+
52+
## Optional. Produces a Markdown link with either "[title][]" or
53+
## "[title](link)"
54+
primary_sources:
55+
- title: Eclipse attacks on Bitcoin's peer-to-peer network
56+
link: https://eprint.iacr.org/2015/263.pdf
57+
58+
## Optional. Each entry requires "title", "url", and "date". May also use "feature:
59+
## true" to bold entry
60+
optech_mentions:
61+
- title: Differentiating peers based on ASN instead of address prefix
62+
url: /en/newsletters/2019/06/26/#differentiating-peers-based-on-asn-instead-of-address-prefix
63+
date: 2019-06-26
64+
65+
- title: Discussion of eclipse attacks on LN nodes
66+
url: /en/newsletters/2019/12/18/#discussion-of-eclipse-attacks-on-ln-nodes
67+
date: 2019-12-18
68+
69+
- title: "2019 year-in-review: erlay and other P2P improvements"
70+
url: /en/newsletters/2019/12/28/#erlay-and-other-p2p-improvements
71+
date: 2019-12-28
72+
73+
## Optional. Same format as "primary_sources" above
74+
# see_also:
75+
# - title:
76+
# link:
77+
---

0 commit comments

Comments
 (0)