Skip to content

Commit 292e8c6

Browse files
hardingharding
committed
Newsletters: add #23 (2018-11-27)
1 parent 7455812 commit 292e8c6

File tree

2 files changed

+213
-0
lines changed

2 files changed

+213
-0
lines changed

‎_includes/references.md‎

Lines changed: 3 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -26,6 +26,7 @@
2626
[BIP151]: https://github.com/bitcoin/bips/blob/master/bip-0151.mediawiki
2727
[BIP157]: https://github.com/bitcoin/bips/blob/master/bip-0157.mediawiki
2828
[BIP158]: https://github.com/bitcoin/bips/blob/master/bip-0158.mediawiki
29+
[BIP173]: https://github.com/bitcoin/bips/blob/master/bip-0173.mediawiki
2930
[BIP174]: https://github.com/bitcoin/bips/blob/master/bip-0174.mediawiki
3031
[BIP320]: https://github.com/bitcoin/bips/blob/master/bip-0320.mediawiki
3132

@@ -67,6 +68,8 @@
6768
[newsletter #16]: {{news16}}
6869
{% assign news17 = "/en/newsletters/2018/10/16/" %}
6970
[newsletter #17]: {{news17}}
71+
{% assign news18 = "/en/newsletters/2018/10/23/" %}
72+
[newsletter #18]: {{news18}}
7073
{% assign news19 = "/en/newsletters/2018/10/30/" %}
7174
[newsletter #19]: {{news19}}
7275
{% assign news21 = "/en/newsletters/2018/11/13/" %}

‎_posts/en/newsletters/2018-11-27-newsletter.md‎

Lines changed: 210 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,210 @@
1+
---
2+
title: "Bitcoin Optech Newsletter #23"
3+
permalink: /en/newsletters/2018/11/27/
4+
name: 2018-11-27-newsletter
5+
type: newsletter
6+
layout: newsletter
7+
lang: en
8+
---
9+
This week's newsletter provides a reminder about potential feerate
10+
increases, summarizes suggested improvements to sighash flags to
11+
accompany BIP118 `SIGHASH_NOINPUT_UNSAFE`, and briefly describes a
12+
proposal to simplify fee bumping for LN commitment transactions. Also
13+
included are selected recent Q&A from Bitcoin StackExchange and
14+
descriptions of notable code changes in popular Bitcoin infrastructure
15+
projects.
16+
17+
## Action items
18+
19+
- **Monitor feerates:** recent reductions in the exchange rate have lead
20+
to modest decreases in hashrate and (possibly) increases in the number
21+
of coins traveling to or from exchanges, which could lead to increased
22+
feerates during the next week. Unless there is a dramatic new change
23+
in hashrate during the next week, a difficulty adjustment is expected
24+
around Sunday that will mitigate most of the recent hashrate reductions.
25+
26+
## News
27+
28+
- **Sighash updates:** Pieter Wuille started a [thread][wuille sighash]
29+
on the Bitcoin-Dev mailing list suggesting two additions for future
30+
changes to segwit sighashes, especially [BIP118][]
31+
`SIGHASH_NOINPUT_UNSAFE`. A signature hash is the data committed to
32+
by a signature in a transaction. Normally the hash commits to a list
33+
of which coins are being spent, which scripts are receiving the coins,
34+
and some metadata---but it's possible to sign only some of the
35+
transaction fields in order to allow other users to change your
36+
transactions in specific ways you might find acceptable (e.g. for
37+
layer-two protocols).
38+
39+
Wuille suggests two additions to what metadata is hashed: first, the
40+
transaction fee is included in the hash in order to ensure hardware
41+
wallets or offline wallets can be absolutely sure that they aren't
42+
being tricked into sending excess amounts of money to miners.
43+
Second, the scriptPubKey of the coins being spent is also included
44+
in the hash---this also helps secure hardware wallets and offline
45+
wallets by eliminating a current ambiguity about whether the script
46+
being spent is a scriptPubKey, P2SH redeemScript, or segwit
47+
witnessScript.
48+
49+
- **Simplified fee bumping for LN:** funds in a payment channel are
50+
protected in part by a multisig contract that requires both parties
51+
sign any state in which the channel can close. Although this provides
52+
trustless security, it has an unwanted side-effect related to
53+
transaction fees---the parties may be signing channel states weeks or
54+
months before the channel is actually closed, which means they have to
55+
guess what the transaction fees will be far in advance.
56+
57+
Rusty Russell has opened a [PR][simple commit PR] to the BOLT
58+
repository and started a mailing list [thread][simple commit thread]
59+
for feedback on a proposal to modify the construction and signing
60+
of some of the LN transactions in order to allow both [BIP125][]
61+
Replace-by-Fee (RBF) fee bumping and Child-Pays-For-Parent (CPFP)
62+
fee bumping. In a [follow-up email][corallo simple commit], Matt
63+
Corallo indicated that the proposal is probably dependent on some
64+
changes being made to the methods and policies nodes use for
65+
relaying unconfirmed transactions.
66+
67+
## Selected Q&A from Bitcoin StackExchange
68+
69+
{% comment %}<!-- https://bitcoin.stackexchange.com/search?tab=votes&q=created%3a1m..%20is%3aanswer -->{% endcomment %}
70+
71+
*[Bitcoin StackExchange][bitcoin.se] is one of the first places Optech
72+
contributors look for answers to their questions---or when we have a
73+
few spare moments of time to help answer other people's questions. In
74+
this monthly feature, we highlight some of the top voted questions and
75+
answers made since our last update.*
76+
77+
- [How could you create a fake signature to pretend to be
78+
Satoshi?][bse 81115] Gregory Maxwell asks and answers a question about
79+
you could create a value that looked like an ECDSA signature corresponding
80+
to an arbitrary public key---such as one known to belong to Satoshi
81+
Nakamoto---but without having access to the private key. Maxwell's
82+
explains that it's easy---if you can trick people into skipping part
83+
of the verification procedure.
84+
85+
- [How to encrypted a message using a Bitcoin keypair?][bse 80640]
86+
Pieter Wuille and Gregory Maxwell each answer a question about using
87+
Bitcoin private and public keys for encryption rather than their
88+
typical use for signing and verification. Wuille's answer provides
89+
detail about the mechanism for accomplishing this, but both answers
90+
warn users about the dangers of trying to perform encryption with
91+
keys and tools that are intended for non-encrypted use with Bitcoin.
92+
93+
- [What is transaction pinning?][bse 80804] John Newbery asks and
94+
answers a question about the term *transaction pinning.* His
95+
definition describes a way to make it prohibitively expensive to
96+
fee bump even a small transaction that signals opt-in Replace-by-Fee
97+
(RBF). (Transaction pinning can create problems for protocols such as
98+
LN where security depends on some transactions confirming within a
99+
certain period of time.)
100+
101+
- [What makes batch verification of Schnorr signatures effective?][bse
102+
80702] Pieter Wuille provides a simple explanation for how it's
103+
possible to do several multiplication operations simultaneously on an
104+
elliptic curve. This can be significantly faster than doing single
105+
multiplication in series, allowing multiple signatures to be verified
106+
together faster than they could be individually verified.
107+
108+
## Notable code changes
109+
110+
*Notable code changes this week in [Bitcoin Core][core commits],
111+
[LND][lnd commits], [C-lightning][cl commits], and [libsecp256k1][secp
112+
commits].*
113+
114+
{% include linkers/github-log.md
115+
refname="core commits"
116+
repo="bitcoin/bitcoin"
117+
start="35739976c1d9ad250ece573980c57e7e7976ae23"
118+
end="a7dc03223e915d7afb30498fe5faa12b5402f7d8"
119+
%}
120+
{% include linkers/github-log.md
121+
refname="lnd commits"
122+
repo="lightningnetwork/lnd"
123+
start="4da1c867c3209dab4e4a824b73d89fc38b616b37"
124+
end="8924d8fb20eb2abfd9cc93c6cc7eb6951184cb88"
125+
%}
126+
{% include linkers/github-log.md
127+
refname="cl commits"
128+
repo="ElementsProject/lightning"
129+
start="d5aaa11373cc6759f9f894a1daf7fb88d0834bc9"
130+
end="95e47cdac298b8e534feb073c70da004c08b3e93"
131+
%}
132+
{% include linkers/github-log.md
133+
refname="secp commits"
134+
repo="bitcoin-core/secp256k1"
135+
start="314a61d72474aa29ff4afba8472553ad91d88e9d"
136+
end="314a61d72474aa29ff4afba8472553ad91d88e9d"
137+
%}
138+
139+
- [Bitcoin Core #14708][] prints a warning when unrecognized section
140+
names are used in the `bitcoin.conf` configuration file. For example,
141+
if you create the following configuration file using the name
142+
`testnet` instead of the correct name `test`, Bitcoin Core would
143+
previously silently ignore the testnet options. This merged PR causes
144+
it to print a notice: "Warning: Section [testnet] is not recognized."
145+
146+
147+
```toml
148+
[testnet]
149+
txindex = 1
150+
```
151+
152+
- [C-Lightning #2087][] adds new fields to the results of the `getinfo` RPC for
153+
the number of the node's peers, number of pending channels, number of
154+
active channels, and number of inactive channels. This now matches
155+
information displayed by LND's `getinfo` RPC.
156+
157+
- [C-Lightning #2096][] strips the text `lightning:` prefixed to a
158+
[BOLT11][] invoice before attempting to process it. This text is
159+
sometimes added so that LN wallets can register for it as URI
160+
handlers. The prefix text will be striped if it is all lowercase or
161+
all uppercase (but not mixed case) per the [BIP173][] bech32
162+
specification.
163+
164+
- C-Lightning [#2081][c-lightning #2081] and [#2092][c-lightning #2092]
165+
fix a problem with running multiple RPC commands in parallel. As a
166+
user-visible change, lightningd now adds a double newline (`\n\n`)
167+
instead of just a single newline to the final output from an RPC. As
168+
single newlines may be used elsewhere in RPC output, terminating with
169+
a double newline makes it easy for a non-JSON parser to find the end
170+
of the results from one RPC call and the beginning of the results from
171+
a subsequent call when the same socket is used for both.
172+
173+
- [Bitcoin Core #14756][] adds the ability for the `rpcauth.py` script to
174+
accept a password on stdin rather than as a command-line parameter
175+
that might be stored in shell history. This script is the preferred
176+
way to generate login credentials for RPC access when not using
177+
`bitcoin-cli` as the same user that started the `bitcoind` daemon.
178+
179+
- [Bitcoin Core #14532][] changes the settings used to bind Bitcoin
180+
Core's RPC port to anything besides the default (localhost).
181+
Previously, using the `-rpcallowip` configuration option would cause
182+
Bitcoin Core to listen on all interfaces (although still only
183+
accepting connections from the allowed IP addresses); now, the
184+
`-rpcbind` configuration option also needs to be passed to specify the
185+
listening addresses. New warnings are printed for unlikely
186+
configurations and to advise users about the danger of listening on
187+
untrusted networks. It is hoped that this change will help reduce the
188+
number of nodes listening for RPC connections on public interfaces,
189+
the danger of which was described in the *News* section of [Newsletter
190+
#18][].
191+
192+
- [C-Lightning #2095][] enforces the [BOLT2][] maximum amounts for
193+
channel and payment value after it was discovered that C-Lightning wasn't
194+
obeying these limits. A future change will likely support an optional
195+
wumbo bit (jumbo bit) that allows the node to negotiate extra-large
196+
channels and payment amounts.
197+
198+
{% include references.md %}
199+
{% include linkers/issues.md issues="14708,2087,2096,2081,2092,14756,14532,2095" %}
200+
201+
{% assign bse = "https://bitcoin.stackexchange.com/a/" %}
202+
[bse 81115]: {{bse}}81115
203+
[bse 80640]: {{bse}}80640
204+
[bse 80804]: {{bse}}80804
205+
[bse 80702]: {{bse}}80702
206+
207+
[wuille sighash]: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2018-November/016488.html
208+
[simple commit PR]: https://github.com/lightningnetwork/lightning-rfc/pull/513
209+
[simple commit thread]: https://lists.linuxfoundation.org/pipermail/lightning-dev/2018-November/001643.html
210+
[corallo simple commit]: https://lists.linuxfoundation.org/pipermail/lightning-dev/2018-November/001666.html

0 commit comments

Comments
 (0)