Skip to content

Commit 2c0b32c

Browse files
hardingjnewbery
authored andcommitted
Newsletters: add bitcoinops#30 (2019-01-22)
1 parent d0a45de commit 2c0b32c

File tree

1 file changed

+127
-0
lines changed

1 file changed

+127
-0
lines changed
Lines changed: 127 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,127 @@
1+
---
2+
title: 'Bitcoin Optech Newsletter #30'
3+
permalink: /en/newsletters/2019/01/22/
4+
name: 2019-01-22-newsletter
5+
type: newsletter
6+
layout: newsletter
7+
lang: en
8+
---
9+
This week's newsletter describes a proposed LN feature to allow making
10+
spontaneous payments and provides our longest-ever list of notable code
11+
changes to popular Bitcoin infrastructure projects.
12+
13+
## News
14+
15+
- **PR opened for spontaneous LN payments:** LN protocol developer
16+
Olaoluwa Osuntokun opened a [pull request][spontaneous payments] to
17+
allow an LN node to send a payment to another node without first
18+
receiving an invoice. This takes advantage of LN's Tor-like onion
19+
routing by allowing a spender to choose a preimage, encrypt it so
20+
that only the receiver's node can decrypt it, and then route a payment
21+
along LN like normal using the hash of the preimage. When the
22+
payment reaches the receiver, they decrypt the preimage and disclose
23+
it to the routing nodes in order to claim the payment.
24+
25+
Spontaneous payments
26+
help in cases where users just want to do ad hoc payment
27+
tracking, for example you initiate a 10 mBTC withdrawal from an
28+
exchange and either 10 mBTC shows up in your balance within a few
29+
moments or you contact support. Or you just publish your node's
30+
information and users can send you donations without having to get
31+
an invoice first. For tracking specific payments, users
32+
should still continue to generate invoices which can be uniquely
33+
associated with particular orders or other expected payments.
34+
35+
Osuntokun's pull request for LND is still marked as a work in
36+
progress as of this writing, so we don't know yet when the feature
37+
will become generally available to LND users or whether other LN
38+
implementations will also provide the same feature in a compatible
39+
way.
40+
41+
## Optech recommends
42+
43+
If you prefer listening to audio rather than reading the weekly Optech
44+
newsletter, Max Hillebrand of World Crypto Network has recorded readings
45+
of every newsletter to date---providing a total of more than 6 hours of
46+
technical news about Bitcoin so far. Audio and video is available on
47+
[YouTube][wcn optech playlist], and audio only is also available as a
48+
podcast via [iTunes][wcn itunes] and [acast][wcn acast]. Optech thanks
49+
Max for volunteering to perform the readings and for doing them so well.
50+
We encourage everyone who would prefer to receive the newsletter in
51+
video or audio form to follow Max for future readings.
52+
53+
## Notable code changes
54+
55+
*Notable code changes this week in [Bitcoin Core][bitcoin core repo],
56+
[LND][lnd repo], [C-Lightning][c-lightning repo], [Eclair][eclair repo],
57+
and [libsecp256k1][libsecp256k1 repo].*
58+
59+
- [Bitcoin Core #14941][] makes the `unloadwallet` RPC synchronous.
60+
It won't return now until the specified wallet has finished being
61+
unloaded.
62+
63+
- [Bitcoin Core #14982][] adds a new `getrpcinfo` RPC that provides
64+
information about the RPC interface. Right now it returns an
65+
`active_commands` array listing all RPCs that haven't returned yet.
66+
67+
- [LND #2448][] adds a standalone watchtower, allowing it to "negotiate
68+
sessions with clients, accept state updates for active sessions,
69+
monitor the chain for breaches matching known breach hints, [and] publish
70+
reconstructed justice transactions on behalf of tower clients."
71+
This is one of the last pieces of an initial watchtower implementation
72+
than can help protect LN nodes that are offline from having their
73+
funds stolen---a feature that's an important part of making LN mature
74+
enough for general use.
75+
76+
- [LND #2439][] adds the default policy for the watchtower, such as
77+
allowing the tower to handle a maximum of 1,024 updates from a client
78+
in a single session, allowing the watchtower to receive a reward of 1%
79+
of the channel capacity if the tower ends up defending the channel,
80+
and setting the default onchain feerate for justice transactions
81+
(breach remedy transactions).
82+
83+
- [LND #2198][] gives the `sendcoins` RPC a new `sweepall` parameter
84+
that will spend all of the wallet's bitcoins to the specified address
85+
without the user having to manually specify the amount.
86+
87+
- [C-Lightning #2232][] extends the `listpeers` command with a new
88+
`funding_allocation_msat` field that returns the amounts initially
89+
placed into a channel by each peer.
90+
91+
- [C-Lightning #2234][] extends the `listchannels` RPC to take a
92+
`source` parameter for filtering by node id. The same pull request also
93+
causes the `invoice` RPC to include route hints for private channels
94+
if you have no public channels unless you also set the new
95+
`exposeprivatechannels` parameter to false. Route hints suggest part
96+
of a routing path to the spender so they can send payments through
97+
nodes they previously didn't know about.
98+
99+
- [C-Lightning #2249][] enables plugins by default on C-Lightning again,
100+
but a note is added to their documentation indicating that the API is
101+
still "under active development".
102+
103+
- [C-Lightning #2215][] adds a libplugin library that provides a
104+
C-language API for plugins.
105+
106+
- [C-Lightning #2237][] gives plugins the ability to register hooks for
107+
certain events that can change how the main process handles those
108+
events. An example given in the code is a plugin that prevents the LN
109+
node from committing to a payment until a backup of important
110+
information about the payment has been completed.
111+
112+
- [Eclair #762][] adds limited probing. Probing in LN is sending an
113+
invalid payment to a node and waiting for it to return an error. If
114+
the node doesn't return an error, it likely means that it or some
115+
other node along a payment path to it is offline and unable to process
116+
payments. Because the probe was an invalid payment that can never be
117+
redeemed, the sending node can immediately treat it as a timed out
118+
payment with no risk of loss. This update to Eclair only allows
119+
probing a node's direct peers---the nodes with which Eclair has an
120+
open channel.
121+
122+
{% include references.md %}
123+
{% include linkers/issues.md issues="14941,14982,2448,2439,2198,2232,2234,2249,2215,2237,762" %}
124+
[spontaneous payments]: https://github.com/lightningnetwork/lnd/pull/2455
125+
[wcn optech playlist]: https://www.youtube.com/playlist?list=PLPj3KCksGbSY9pV6EI5zkHcut5UTCs1cp
126+
[wcn itunes]: https://itunes.apple.com/us/podcast/the-world-crypto-network-podcast/id825708806
127+
[wcn acast]: https://play.acast.com/s/world-crypto-network

0 commit comments

Comments
 (0)