Skip to content

Commit 1dd2ba1

Browse files
hardingharding
committed
Newsletters: add 71 (2019-11-06)
1 parent 6fd23c9 commit 1dd2ba1

File tree

2 files changed

+152
-0
lines changed

2 files changed

+152
-0
lines changed

‎_includes/references.md

Lines changed: 1 addition & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -57,6 +57,7 @@ When more recent information about a BIP is available not in the regular
5757
place, put links here. -->{% endcomment %}
5858

5959
{% comment %}<!-- BOLTs in order lowest to highest -->{% endcomment %}
60+
[BOLT1]: https://github.com/lightningnetwork/lightning-rfc/blob/master/01-messaging.md
6061
[BOLT2]: https://github.com/lightningnetwork/lightning-rfc/blob/master/02-peer-protocol.md
6162
[BOLT3]: https://github.com/lightningnetwork/lightning-rfc/blob/master/03-transactions.md
6263
[BOLT4]: https://github.com/lightningnetwork/lightning-rfc/blob/master/04-onion-routing.md

‎_posts/en/newsletters/2019-11-06-newsletter.md

Lines changed: 151 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,151 @@
1+
---
2+
title: 'Bitcoin Optech Newsletter #71'
3+
permalink: /en/newsletters/2019/11/06/
4+
name: 2019-11-06-newsletter
5+
slug: 2019-11-06-newsletter
6+
type: newsletter
7+
layout: newsletter
8+
lang: en
9+
---
10+
This week's newsletter requests help testing a Bitcoin Core release
11+
candidate, summarizes continued discussion of LN anchor outputs, and
12+
describes a proposal for allowing full nodes and lightweight clients to
13+
signal support for IP address relay. Also included is our regular
14+
section about notable changes to popular Bitcoin infrastructure
15+
projects.
16+
17+
{% comment %}<!-- include references.md below the fold but above any Jekyll/Liquid variables-->{% endcomment %}
18+
{% include references.md %}
19+
20+
## Action items
21+
22+
- **Help test Bitcoin Core release candidate:** experienced users are
23+
encouraged to help test the latest release candidates for the upcoming
24+
version of [Bitcoin Core][Bitcoin Core 0.19.0].
25+
26+
## News
27+
28+
- **Continued discussion of LN anchor outputs:** as described in [last
29+
week's newsletter][news70 simplified commitments], LN developers are
30+
working on allowing either party to a channel to CPFP fee bump
31+
settlement transactions, taking advantage of the CPFP carve-out
32+
mempool policy that's expected to be released as part of Bitcoin Core
33+
0.19.0. Topics [discussed][jager anchor] this week included:
34+
35+
- Whether both the party unilaterally closing the channel (the
36+
"local" party) and the other party ("remote") should experience
37+
the same delay before being able to claim their funds, or whether
38+
they should each be able to negotiate during the channel creation
39+
process for the delay duration to use when they're the remote
40+
party. Currently, only the local party is delayed and there's
41+
concern that this may result in some people trying to manipulate
42+
the other party to close the channel so that the manipulator will
43+
receive their funds faster.
44+
45+
- What script to use for the anchor outputs. It was previously
46+
proposed that the script should contain a clause that allows
47+
anyone to spend it after a suitable delay in order to prevent
48+
polluting the UTXO set with many small-value outputs. However,
49+
this is complicated by the script possibly needing to contain a
50+
unique pubkey which won't be known by third parties, preventing
51+
them from being able to independently generate the witness script
52+
necessary to spend the P2WSH output.
53+
54+
- What amount of bitcoin value to use for the anchor outputs. The
55+
person who initiates channel opening is responsible for paying
56+
this amount (as they are responsible for paying all fees in the
57+
current protocol), so they would probably like to keep it
58+
low---but the amount must be greater than most node's minimum
59+
output amount ("dust limit"). There was discussion about whether
60+
or not this should be a configurable amount.
61+
62+
- Whether each LN payment should pay different public keys (using
63+
pubkey tweaking). Removing key tweaking was proposed to reduce
64+
the amount state tracking necessary, but a concern was raised that
65+
this would make the channel state too deterministic. This could
66+
allow a watchtower that received a series of encrypted breach
67+
remedy transactions from one side of a channel to be able to
68+
decrypt not just the needed breach remedy transaction but all
69+
other breach remedy transactions from that channel---allowing the
70+
watchtower to reconstruct the amounts and hash locks used for each
71+
payment in that channel, significantly reducing privacy.
72+
73+
Discussion remains ongoing as solutions to the above concerns are
74+
suggested and the proposal receives additional review.
75+
76+
- **Signaling support for address relay:** full nodes share the IP
77+
addresses of other full nodes they've heard about with their peers
78+
using the P2P protocol's `addr` (address) message, enabling fully
79+
decentralized peer discovery. SPV clients can also use this mechanism
80+
to learn about full nodes, although most clients currently use some
81+
form of centralized peer discovery and so `addr` messages sent to those
82+
clients are wasted bandwidth.
83+
84+
Gleb Naumenko sent an [email][naumenko addr relay] to the
85+
Bitcoin-Dev mailing list suggesting that nodes and clients should
86+
signal to their peers whether or not they want to participate in
87+
address relay. This will avoid wasting bandwidth on clients that
88+
don't want the addresses and can make it easier to determine the
89+
consequences of certain network behavior related to address relay.
90+
91+
Two methods are proposed for allowing nodes to indicate whether or
92+
not they want to participate in address relay---a per-node method
93+
and a per-connection method. The per-node method could easily build
94+
on top of work already being done for addrv2 messages (see [Newsletter
95+
#37][news37 addrv2]), but it would be less flexible than the the
96+
per-connection method. In particular, the per-connection method
97+
could allow a node to dedicate some connections to transaction relay
98+
and other connections to address relay, producing possible privacy
99+
advantages. Naumenko's email requests feedback on which method would
100+
be preferred by implementers of both full nodes and lightweight
101+
clients.
102+
103+
## Notable code and documentation changes
104+
105+
*Notable changes this week in [Bitcoin Core][bitcoin core repo],
106+
[C-Lightning][c-lightning repo], [Eclair][eclair repo], [LND][lnd repo],
107+
[libsecp256k1][libsecp256k1 repo], [Bitcoin Improvement Proposals
108+
(BIPs)][bips repo], and [Lightning BOLTs][bolts repo].*
109+
110+
- [Bitcoin Core #16943][] adds a `generatetodescriptor` RPC that allows
111+
new blocks generated during testing (e.g. in regtest mode) to pay a
112+
script represented by an [output script descriptor][]. Prior to this
113+
change, only the `generatetoaddress` RPC was available and it can only
114+
pay P2PKH, P2SH, or P2WSH addresses.
115+
116+
- [C-Lightning #3220][] begins always creating signatures with a low *r*
117+
value, reducing the maximum size of the signature by one byte and
118+
saving about 0.125 vbytes on average per C-Lightning peer in onchain
119+
transactions. Bitcoin Core also previously adopted this change to its
120+
wallet's signature-generation code (see [Newsletter #8][news8 lowr]).
121+
122+
- [LND #3558][] synthesizes a unified policy for any case where two
123+
particular nodes have multiple channels open between them and then
124+
uses this synthetic policy when considering routing through any of
125+
those channels. [BOLT4][bolt4 non-strict rec] recommends that multiple channels
126+
between the same nodes should all use the same policy, but this
127+
doesn't always happen, so this change tries to determine "the greatest
128+
common denominator of all policies" between the nodes. Using a single
129+
policy reduces the number of routes the node needs to evaluate when
130+
making a payment.
131+
132+
- [LND #3556][] adds a new `queryprob` RPC that returns the expected
133+
probability that a payment would succeed given a particular
134+
destination node and amount. This replaces functionality previously
135+
removed from the `querymc` RPC.
136+
137+
- [BOLTs #660][] updates [BOLT1][] to reserve Type-Length-Value (TLV)
138+
type identifiers less than 2<sup>16</sup> for types defined in in the
139+
LN specification (the BOLT documents). The remaining values may be
140+
used freely as custom records by any LN implementation. The updated
141+
specification also now provides guidance on how to select numbers for
142+
custom record types.
143+
144+
{% include linkers/issues.md issues="16943,3558,3556,660,3220" %}
145+
[bitcoin core 0.19.0]: https://bitcoincore.org/bin/bitcoin-core-0.19.0/
146+
[bolt4 non-strict rec]: https://github.com/lightningnetwork/lightning-rfc/blob/master/04-onion-routing.md#recommendation
147+
[news37 addrv2]: /en/newsletters/2019/03/12/#version-2-addr-message-proposed
148+
[news8 lowr]: /en/newsletters/2018/08/14/#bitcoin-core-wallet-to-begin-only-creating-low-r-signatures
149+
[naumenko addr relay]: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2019-October/017428.html
150+
[news70 simplified commitments]: /en/newsletters/2019/10/30/#ln-simplified-commitments
151+
[jager anchor]: https://lists.linuxfoundation.org/pipermail/lightning-dev/2019-October/002264.html

0 commit comments

Comments
 (0)