|
| 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