Skip to content

Commit 7d774b7

Browse files
hardingjnewbery
harding
authored and
jnewbery
committed
Newsletters: add #23 (2018-11-27)
1 parent 7455812 commit 7d774b7

File tree

2 files changed

+212
-0
lines changed

2 files changed

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

0 commit comments

Comments
 (0)