Skip to content

Commit 08ec4a3

Browse files
hardingbitschmidty
harding
authored and
bitschmidty
committed
Newsletters: add 71 (2019-11-06)
1 parent 6fd23c9 commit 08ec4a3

File tree

2 files changed

+153
-0
lines changed

2 files changed

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

0 commit comments

Comments
 (0)