Newsletters: add 85 (2020-02-19)#346
Conversation
| - **Help test C-Lightning 0.8.1rc3:** this [release candidate][cl 0.8.1] adds | ||
| several new features (including those described in the *notable | ||
| changes* section below) and provides multiple bug fixes. Experienced | ||
| users are encouraged to help test. |
There was a problem hiding this comment.
maybe s/help test/test it/
| developers who preferred to remain anonymous (so we'll call them Anon) | ||
| wrote a [criticism][anon reflowed] of taproot as compared to | ||
| alternative approaches that enable [MAST][topic mast] and [schnorr | ||
| signatures][topic schnorr signatures] in Bitcoin. Anon concludes |
There was a problem hiding this comment.
The first and last sentences of this taproot-Anon section are written in past tense whereas the rest of the section is in present tense. I think it works but a consistent tense may be preferable. The past tense makes sense but is a bit heavier to read; the present tense is dynamic/punchier.
There was a problem hiding this comment.
I don't think there's anything I can do about the predicate in the opening sentence (though I can tweak some of the auxiliary verbs and the final sentence). I'd prefer to keep the present tense for the rest of the section, as I think it helps make this 750-word "summary" a bit easier to read (as you mention, punchier).
There was a problem hiding this comment.
Could make the verbs slightly less past tense and say "have written", "has not reached a conclusion".
| threshold signing (e.g. k-of-n), or adaptor signatures. Yet only | ||
| with taproot can the anonymity set also practically extend to | ||
| cases where spenders prefer to use single-sig but want the option | ||
| to fallback to using scripts if they can't generate the necessary |
There was a problem hiding this comment.
s/to fallback/to fall back/
| single signature. If MAST and schnorr were to be done separately, | ||
| single-sig users would need to pay more to spend a UTXO than they | ||
| do now, and so it's unlikely many of them would join the | ||
| anonymity set that covers fallback script users. |
There was a problem hiding this comment.
I wonder if there's a better description than "fallback script users" but I don't have a better idea.
| opening a channel with you, learn one or more of your UTXOs, and then | ||
| abandon the channel setup process before signing a transaction and | ||
| paying any fees. A proposed solution to this problem is to require | ||
| channel open proposals contain a Proof of Discrete Log Equivalence |
There was a problem hiding this comment.
perhaps s/Log/Logarithm/
There was a problem hiding this comment.
"discrete log" sounds way more normal than "discrete logarithm" to me, ymmv
| binaries are no longer being distributed by the project due to a | ||
| lack of use and hands-on developer testing. | ||
|
|
||
| - [C-Lightning #3488][] Bitcoin backend generalization FIXME:adamjonas |
There was a problem hiding this comment.
TIL about c-lightning's Optech Make Me Famous! label
| - [C-Lightning #3488][] Bitcoin backend generalization FIXME:adamjonas | ||
|
|
||
| - [C-Lightning #3500][] implements a simple solution to a problem that | ||
| could cause channels to become stuck with neither party able to sends |
There was a problem hiding this comment.
s/sends/send/ (or just "use it")
| attachments to other hooks in the future. For the `htlc_accepted` | ||
| hook, this allows a plugin to either reject the HTLC, resolve the HTLC | ||
| (i.e. claim any payment by returning the preimage), or pass the HTLC | ||
| onto the next plugin bound to the hook. |
There was a problem hiding this comment.
TIL:
- onto =~ upon
- on to =~ to the next
Nice catch!
| will be sent in the node's [BOLT1][] `init` message, the [BOLT7][] | ||
| `node_announcement` message, or the [BOLT11][] invoice's feature bits | ||
| field (field `9`). This allows a plugin to signal to other programs | ||
| its node can handle the advertised features. |
There was a problem hiding this comment.
suggestion s/its/that its/
|
|
||
| - [C-Lightning #3477][] allows plugins to register feature flags that | ||
| will be sent in the node's [BOLT1][] `init` message, the [BOLT7][] | ||
| `node_announcement` message, or the [BOLT11][] invoice's feature bits |
There was a problem hiding this comment.
(Looks like you are doing it but just in case) perhaps link to
- https://github.com/lightningnetwork/lightning-rfc/blob/master/01-messaging.md#the-init-message
- https://github.com/lightningnetwork/lightning-rfc/blob/master/07-routing-gossip.md#the-node_announcement-message
- https://github.com/lightningnetwork/lightning-rfc/blob/master/11-payment-encoding.md#feature-bits
jonatack
left a comment
jonatack
left a comment
There was a problem hiding this comment.
ACK mod a pair of additional nits; feel free to ignore
| single-sig users would need to pay more to spend a UTXO than they | ||
| do now, and so it's unlikely many of them would join the | ||
| anonymity set that covers fallback script users. | ||
| anonymity set that covers users of fallback script. |
There was a problem hiding this comment.
(should script be plural here? not sure)
| [3][taplearn3]). | ||
|
|
||
| 4. {:#tap4} Anon asks, "couldn't we forego the [Nothing Up My | ||
| Sleeve] NUMS point requirement and be able to check if it's a |
There was a problem hiding this comment.
is there supposed to be a url for Nothing Up My Sleeve?
There was a problem hiding this comment.
No, the bracketed text is an editorial insertion. However, a link would probably be a good idea; I'll add that.
|
I read through the newsletter and LGTM. |
|
Pushed some small edits and updates (e.g. C-Lightning released), but also a 90% rewrite of the first taproot discussion bullet point because I was very unhappy with the previous version's readability. My apologies to people who already reviewed (both for wasting your time and because you had to read that technobable). See 929808b |
jnewbery
left a comment
jnewbery
left a comment
There was a problem hiding this comment.
Looks good. Just a few small nits inline.
| --- | ||
| This week's newsletter requests help testing release candidates for | ||
| Bitcoin Core and C-Lightning, summarizes a discussion about taproot | ||
| versus implementing MAST and schnorr separately, describes new ideas for |
There was a problem hiding this comment.
s/schnorr/schnorr signatures/
| as the backend. This pull request is part of a larger project to allow more | ||
| freedom for how C-Lightning interacts with the Bitcoin backend as proposed | ||
| in [C-Lightning #3354][]. Keeping the backend interactions general and | ||
| unassuming allows for plugins to either make standard RPC calls, combine |
There was a problem hiding this comment.
I don't think unassuming (which usually means 'modest' or 'unpretentious') is quite the right word here. I think 'general and unassuming' could be replaced with 'generic'
| RPCs into more abstract methods, or even create notifications. While | ||
| `bitcoind` interaction through `bitcoin-cli` remains the default, this project | ||
| works towards opening up possibilities for mobile integration (see | ||
| [C-Lightning #3484][]) or allowing users to share a full-node like an |
There was a problem hiding this comment.
I don't understand what's meant by "a full-node like an esplora instance". Esplora isn't a full node, or have I entirely misunderstood the meaning of the sentence?
| - **BTCPay Vault using HWI for signing:** [BTCPay Vault][btcpay vault blog] is | ||
| a desktop application that uses [HWI][topic hwi] to coordinate signing | ||
| transactions with a variety of hardware wallets. While BTCPay Server created | ||
| BTCPay Vault, the software can be repuposed for use in other applications. |
|
|
||
| - **CKBunker using PSBTs for an HSM:** [CKBunker][coinkite bunker] allows users | ||
| to configure rule-based spending conditions for an online, Tor-enabled Coldcard | ||
| hardware wallet. The Coldcard then functions like an HSM, signing |
|
Pushed an edit for @jnewbery and @jonatack feedback to my sections (thanks!), and also a separate commit editing @adamjonas's bullet based on @jnewbery's feedback (hope that's ok!). |
|
ACK @bitschmidty's section and @adamjonas's PR summary. |
bitschmidty
left a comment
bitschmidty
left a comment
There was a problem hiding this comment.
@harding great one this week, thank you!
couple small suggestions
| - **Upgrade to C-Lightning 0.8.1:** this [release][cl 0.8.1] adds | ||
| several new features (including those described in the *notable | ||
| changes* section below) and provides multiple bug fixes. See the | ||
| [changelog][cl changelog] for detailed list of updates. |
There was a problem hiding this comment.
s/for detailed list/for a detailed list
| authorization pattern." Towns shows that single-sig spends | ||
| currently represent more than 57% of all transaction outputs (and | ||
| possibly much more, given the frequent use of P2SH-wrapped | ||
| P2WPKH). The number of users satisfied with single-sig will |
There was a problem hiding this comment.
"users satisfied with" sounds off to me. Perhaps "transactions satisfied with" or "transactions using" or other?
| Taproot eliminates that divide by allowing cheap single-sig | ||
| spends that are identical in appearance to those of users who can | ||
| use single-sig but who also have fallback scripts (though | ||
| actually using a fallback script will be identifiable onchain). |
There was a problem hiding this comment.
perhaps for clarity: s/identifiable onchain/identifiable onchain when spending
| shows that taproot actually only adds about 33 bytes in the | ||
| script-path spending case, making the cost-benefit analysis | ||
| asymmetric in favor of taproot. David Harding [notes][harding | ||
| tap] that the extra cost (which translates to 8.25 vbytes) is |
bitschmidty
force-pushed
the
2020-02-19-newsletter
branch
from
43b52ee to
8697b14
Compare
bitschmidty
force-pushed
the
2020-02-19-newsletter
branch
from
8697b14 to
1aed339
Compare
|
Added a small commit to clarify that c-lightning was an update and not RC and a couple smaller fixups. Squashed. |
|
@harding thanks for authoring as always and to @adamjonas for contributing the PR along with @jonatack @jnewbery and @ajtowns for the reviews! |
| [3][taplearn3]). | ||
|
|
||
| 4. {:#tap4} Anon asks, "couldn't we forego the [Nothing Up My | ||
| Sleeve]<!-- prevent link --> [NUMS][] point requirement and be able to check if it's a |
There was a problem hiding this comment.
When viewing the newletter online, I'm seeing
Anon asks, “couldn’t we forego the [Nothing Up My Sleeve] NUMS point requirement...
is the formatting correct?
There was a problem hiding this comment.
"[Nothing Up My Sleeve]" is an editorial interpolation from @harding. The original is "couldn't we forego the NUMS point requirement" so the formatting is correct.
There was a problem hiding this comment.
"[Nothing Up My Sleeve]" is an editorial interpolation from @harding. The original is "couldn't we forego the NUMS point requirement" so the formatting is correct.
Thanks, John!
|
Another great newsletter. Thanks Dave! |
7 participants
C-Lightning #3488@adamjonas