Newsletters: add 100 (2020-06-03) #410
Conversation
|
💯 |
jonatack
left a comment
jonatack
left a comment
There was a problem hiding this comment.
Shaping up to be an excellent 100th issue!
| BOLTs][bolts repo].* | ||
|
|
||
| *Note: the commits to Bitcoin Core mentioned below apply to its master | ||
| development branch and so those changes will likely not be released |
There was a problem hiding this comment.
I think "so those changes" can be omitted (or replaced by ", and unless backported,")
There was a problem hiding this comment.
Backporting is one concern, but my main concern is promising that X merged feature will be in release Y. There's always the chance that something will be reverted before then. I agree that this warning is probably more verbose than necessary given that all reasonable developers understand that things can change between a development merge and a release---but a few years ago I polled some Bitcoin developers for some deadlines on segwit stuff, used that to make a table of planned release dates, and then saw /r/btc republish that table over and over again in attacks on the project when those dates weren't met. Several core devs have told me they don't blame me for what happened, but ever since I've been very careful about writing anything that sounds like a promise to release specific features, much less promises to release at a certain point in time.
jnewbery
left a comment
jnewbery
left a comment
There was a problem hiding this comment.
Looks great so far. A few small comments inline. The transcripts section is an excellent addition. Thank you @michaelfolkson !
| Near the end of his email, Belcher summarizes the requirements for | ||
| the system he describes: | ||
|
|
||
| > * [Two-party ECDSA] |
There was a problem hiding this comment.
The square brackets here are slightly confusing. I understand you've added them because it's not a direct quote, but without the original 'ECDSA-2P', that's not immediately obvious. My first two interpretations of this were that 2P-ECDSA is an optional requirement, or that this was a badly formed markdown link.
Does this list need to be a direct quote at all?
There was a problem hiding this comment.
Eh, I think we don't actually need the list at all, so I'll just remove it.
| ([transcript][decker xs], [video][decker vid]) | ||
|
|
||
| - **Payjoin/P2EP:** Adam Gibson led a discussion at London BitDevs about | ||
| [payjoin][topic payjoin], including the recent implementation of it by |
There was a problem hiding this comment.
"the recent implementation of it by BTCPay Server" feels a bit convoluted. I think you can just drop this entirely from the sentence, since almost exactly the same words are repeated below.
|
|
||
| - **Payjoin/P2EP:** Adam Gibson led a discussion at London BitDevs about | ||
| [payjoin][topic payjoin], including the recent implementation of it by | ||
| BTCPay Server. Payjoin allows the sender and receiver of a |
There was a problem hiding this comment.
I think this sentence could be shortened and made clearer by removing the unnecessary "to coordinate in order" and the repetitive "allows". Something like: "Payjoin allows a transaction's sender and receiver to both contribute inputs the transaction. This breaks the common wallet ownership assumption and subset sum analysis, and improves the sender's and receiver's privacy."
|
|
||
| - [Bitcoin Core #19010][] net processing: Add support for getcfheaders FIXME:jonatack | ||
|
|
||
| - [Bitcoin Core #16030][] changes how long Bitcoin Core waits until |
harding
force-pushed
the
2020-06-03-newsletter
branch
from
cc78278 to
e3c366e
Compare
|
Changes look good. Thanks @harding |
|
Coverage for the BIP157 changes (PRs 19010 and 19044) here: jonatack@9372d3b5e It's an adapted update of the previous coverage two weeks ago in news98. I described overall BIP157 progress and provided links as an exercise for the reader to go into the per-PR changes. |
|
@jonatack thanks, that's just what I wanted! Besides @jnewbery's edits to use the PR link helper, I just used the serial comma to match other content in this newsletter and combined the final two paragraphs (logically I agree they were better off separate but, when it doesn't cause too much problem, I try to keep the bullets looking short by eliminating short paragraphs). |
|
I actually wrote it with the Oxford commas, since they are more precise, then removed them just before pushing 😄 taking note to use them ;) |
|
I've added the members' logos screenshot but feel free to change that @harding if it's not what you were envisioning. We're not going to make any changes to the members list between now and tomorrow. |
|
@jnewbery screenshot looks exactly like what I envisioned, thanks! |
|
Screenshot of the local rendering of the screenshot: https://imgur.com/a/zsGc94n |
|
Closing and then reopening to see if I can restart the builds, which say they timed out. |
|
LND 4228 description looks good to me. |
|
Was able to manually trigger a successful build and netlify preview, although checks are still referencing an earlier build. |
|
For info, we had an unusual, possibly semi-related issue on Sat/Sun with the review club. The builds passed (they are perhaps shorter to run than here), but the changes were not deployed to production until the next push a day later. |
|
Pushed a small commit replacing the Bitcoin Core RC bullet with a note that it's about to be released and that we'll cover the release in more detail next week. |
adamjonas
left a comment
adamjonas
left a comment
There was a problem hiding this comment.
I'm very proud to be mentioned in this edition as a contributor though I object to be given equal credit for the production of this newsletter. Thanks for all you do @bitschmidty, @moneyball, @jonatack, and @dongcarl. @harding you are a Bitcoin treasure. 💯is a testament to your discipline and dedication. Thank you.
| calculator][lopp calc] he'd developed as well as a similar [calculator | ||
| developed by Optech][optech calc]. Neither tool claims to be complete | ||
| or bug-free, but both should be useful to developers who want to | ||
| quickly compare the sizes of different types of transactions. |
There was a problem hiding this comment.
split infinitive
| quickly compare the sizes of different types of transactions. | |
| compare the sizes of different types of transactions quickly. |
| into Bitcoin Core, dual funding in C-Lightning, and modern soft fork | ||
| activation. The history of Linux kernel development and segwit |
There was a problem hiding this comment.
Modern isn't really the right word here. It's more like "possible soft fork activation methods".
| Devs. They outlined specific details such as its reliance on | ||
| co-signing servers and how it compares to some other vault designs | ||
| that require key deletion, anticipating spending amounts, or both. | ||
| Their presentation was preceded the week before by a wider discussion |
There was a problem hiding this comment.
| Their presentation was preceded the week before by a wider discussion | |
| Their presentation was preceded the week before by a broader discussion |
| node will entirely use P2P address discovery without relying on the | ||
| centralized DNS seeds. | ||
|
|
||
| - [LND #4228][] adds a new wallet command `labeltx` for labelling past onchain |
There was a problem hiding this comment.
Grepped for our use of labeling and labelling in the code and found this to be the first instance of the non-American variant and three instances in the RBF in the Wild post.
| - [LND #4228][] adds a new wallet command `labeltx` for labelling past onchain | |
| - [LND #4228][] adds a new wallet command `labeltx` for labeling past onchain |
There was a problem hiding this comment.
perhaps set off labeltx with commas:
"LND #4228 adds a new wallet command, labeltx, to label onchain transactions."
| centralized DNS seeds. | ||
|
|
||
| - [LND #4228][] adds a new wallet command `labeltx` for labelling past onchain | ||
| transactions. This is a continuation of the work done in [LND #4213][] which |
There was a problem hiding this comment.
| transactions. This is a continuation of the work done in [LND #4213][] which | |
| transactions. This is a continuation of the work done in [LND #4213][], which |
| and simple as we initially expected it to be. Accordingly, we'd like to | ||
| take this chance to thank the people who make this newsletter possible | ||
| by generously contributing a significant amount of their valuable time | ||
| week after week: [Adam Jonas][], [Carl Dong][], [David A. Harding][], |
There was a problem hiding this comment.
I have to say I'm uncomfortable being mentioned first on this line with @harding buried in the middle (I get it's alphabetical). I don't believe that credit should be equally shared. Can emphases or an additional sentence be added to make it clear who does most of the work to make this newsletter happen?
There was a problem hiding this comment.
I'm sorry this makes you feel uncomfortable. :-( However, an alphabetical list of contributors in the standard for lists of credits in most free software projects even though all of those projects have the same situation of different people contributing different amounts of time to the project. I think we're better off following that simple and pragmatic standard than we are trying to fairly apportion credit among ourselves.
There was a problem hiding this comment.
@harding Just feel that you deserved to be highlighted since you put in the most work.
| contributed field reports and other special content to the newsletter | ||
| over the past two years. | ||
|
|
||
| Publishing a high-quality weekly newsletter and working to fulfill other |
There was a problem hiding this comment.
| Publishing a high-quality weekly newsletter and working to fulfill other | |
| Publishing a high-quality, weekly newsletter and working to fulfill other |
There was a problem hiding this comment.
This seems better to me without the comma, but I admit I'm not sure enough about the grammar rules to know which way is technically correct.
| [John Newbery][], [Jon Atack][], [Mike Schmidt][], and [Steve Lee][]. | ||
|
|
||
| We additionally thank the experienced Bitcoin and LN contributors who | ||
| kindly provided us with special help on certain complex topics or who |
There was a problem hiding this comment.
2 specials in the sentence.
| kindly provided us with special help on certain complex topics or who | |
| kindly provided us with help on certain complex topics or who |
| We also remain eternally thankful to our founding sponsors [Wences | ||
| Casares][], [John Pfeffer][], and [Alex Morcos][] <!-- same order as on | ||
| About page --> as well as to organizations such as [Chaincode Labs][] | ||
| and [SquareCrypto][] who both allow and encourage their staff to use |
There was a problem hiding this comment.
| and [SquareCrypto][] who both allow and encourage their staff to use | |
| and [Square Crypto][] who both allow and encourage their staff to use |
There was a problem hiding this comment.
Final read-through and links verification in the bottom of the ninth inning to help ensure this 100th newsletter is as good as can be. A few comments below; feel free to ignore.
One issue with the links helper for GitHub PRs: it uses the out-of-date and less helpful "issues" url path for PRs, which seem to be redirected by GitHub to the current, more clear, "pull" url path.
| --- | ||
| This week's newsletter summarizes a proposed design for a coinswap | ||
| implementation, describes new middleware for allowing lightweight | ||
| wallets to request information directly from a user's own node, and links to |
There was a problem hiding this comment.
micro nit: perhaps s/links to/highlights/ (or similar)
- avoids the ambiguity of "links" being both a noun and a verb
- avoids the semi-awkward "to two"
| - **The Revault multiparty vault architecture:** Kevin Loaec and Antoine | ||
| Poinsot presented their vault design *Revault* at London Bitcoin | ||
| Devs. They outlined specific details such as its reliance on | ||
| co-signing servers and how it compares to some other vault designs |
| node will entirely use P2P address discovery without relying on the | ||
| centralized DNS seeds. | ||
|
|
||
| - [LND #4228][] adds a new wallet command `labeltx` for labelling past onchain |
There was a problem hiding this comment.
perhaps set off labeltx with commas:
"LND #4228 adds a new wallet command, labeltx, to label onchain transactions."
| [phoenix]: https://phoenix.acinq.co/ | ||
| [Adam Jonas]: https://github.com/adamjonas | ||
| [Carl Dong]: https://github.com/dongcarl | ||
| [David A. Harding]: https://github.com/harding |
There was a problem hiding this comment.
extra space between A. and Harding, but the link is fine
| newsletter, we've also discovered that summarizing isn't quite as quick | ||
| and simple as we initially expected it to be. Accordingly, we'd like to | ||
| take this chance to thank the people who make this newsletter possible | ||
| by generously contributing a significant amount of their valuable time |
There was a problem hiding this comment.
s/time week after week/time, week after week/
| We also remain eternally thankful to our founding sponsors [Wences | ||
| Casares][], [John Pfeffer][], and [Alex Morcos][] <!-- same order as on | ||
| About page --> as well as to organizations such as [Chaincode Labs][] | ||
| and [SquareCrypto][] who both allow and encourage their staff to use |
There was a problem hiding this comment.
perhaps omit "both", it's ambiguous whether it refers to both orgs or both "allow and encourage", and both of the meanings are understood without it
|
ACK d1e84d1 |
bitschmidty
force-pushed
the
2020-06-03-newsletter
branch
from
d1e84d1 to
96c9ce6
Compare
|
Squashed and merged. Thanks @harding @dongcarl @jonatack @michaelfolkson @adamjonas and @jnewbery ! |
7 participants
#100, and any additional merged PRsBitcoin Core #19010LND #4228