Repository navigation
Newsletters: add 49 (2019-06-05) - #150
Conversation
081248c to
51f8860
Compare
|
tACK 51f8860 |
This comment has been minimized.
This comment has been minimized.
| [bech32 easy]: {{news38}}#bech32-sending-support | ||
| [news48 coshv]: {{news48}}#proposed-transaction-output-commitments | ||
| [alt-coshv]: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2019-June/016997.html | ||
| [kotliar ln]: /{% comment %}<!-- FIXME -->{% endcomment %} |
There was a problem hiding this comment.
I have the URL for his, but the video is marked private and I don't think we want to release it until shortly before publication, so this is a FIXME for now.
|
utACK 6982a49 Fantastic description of Erlay! |
jnewbery
left a comment
jnewbery
left a comment
There was a problem hiding this comment.
Looks great. I've left a bunch of nits inline.
We were going to include a blurb for the review club (https://bitcoin-core-review-club.github.io/) this week. Would you like me to write that?
|
|
||
| After describing the Erlay protocol, the paper analyzes its performance | ||
| using both a simulated network of 60,000 nodes (similar in number and use to | ||
| the current Bitcoin network) and a live set of 100 nodes spread Internationally |
There was a problem hiding this comment.
s/Internationally/internationally
(or "spread across datacenters in several countries")
|
|
||
| Having established that the protocol is a worthwhile efficiency | ||
| improvement, the paper considers the most important of its secondary aspects: | ||
| its effect on privacy. Bitcoin Core currently implements artificial delays |
There was a problem hiding this comment.
s/artificial/randomized/ ?
| incoming connections, Erlay always performed as well or better than the current | ||
| protocol. In cases where the spy nodes were private nodes making connections | ||
| to honest nodes, Erlay sometimes performed better and sometimes performed | ||
| worse---but never more than 10% worse (and then in an unlikely situation). <!-- |
There was a problem hiding this comment.
Consider removing or rewording "(and then in an unlikely situation)."
| notes that an increase in the number of outbound peers from 8 to 32 would only | ||
| increase the bandwidth used by a node to announce the existence of new | ||
| transactions by 32% with Erlay compared to 300% using the current protocol. | ||
| <!-- figure 10 --> Note, as described in the paragraph above about Erlay's two |
| to 8 peers, but nodes would perform set reconciliation with 32 peers. | ||
| A four-fold increase in the number of outbound peers could improve the | ||
| probability that each node makes a connection to at least one honest peer that | ||
| is itself well connected. Without reliable connections between honest peers, |
There was a problem hiding this comment.
Consider removing "Without reliable connections..." to the end of the paragraph. I think we can assume our readership understands the importance of having one well-connected honest peer.
|
|
||
| - **COSHV proposal replaced:** the author of the COSHV proposal we described | ||
| [last week][news48 coshv] has replaced it with a [similar | ||
| proposal][alt-coshv] (under a different name). The new proposal checks more |
| allowing a single input is still recommended to avoid unwanted interactions). | ||
|
|
||
| Except for the new name, the changes don't affect the summary of COSHV we | ||
| wrote last week. However, the changes do affect some additional material about |
There was a problem hiding this comment.
I'd remove this sentence. I know we announced it last week. We could:
- keep this sentence here.
- remove this sentence, and add a note to the tween announcing the newsletter "Due to the fast-changing nature of the OP_COSHV proposal, we are not including the 'advanced use cases' of OP_COSHV we announced last week. We will continue to cover OP_COSHV as the proposal matures." or similar.
- just remove this sentence.
I prefer (2) or (3).
We could also remove "In next week’s newsletter, we’ll look at some other ways COSHV could be used to improve efficiency, privacy, or both." from the website version of last week's newsletter.
There was a problem hiding this comment.
I did (3). I don't know what "tween" means in (2), but it also seems predicated on removing this sentence, so I went with that. If I'm not around, please feel free to add a note (or not).
As for editing last week's newsletter, I wouldn't feel comfortable making a substantial edit like that without leaving a note about the edit, which I think would kinda defeat the purpose.
There was a problem hiding this comment.
I figured out "tween" probably means "tweet". I think tweeting that initially is unnecessary, but that it'd be good for any one of us to tweet something like that in reply to anyone asking about the previously-announced text.
There was a problem hiding this comment.
I wouldn't feel comfortable making a substantial edit like that without leaving a note about the edit, which I think would kinda defeat the purpose.
I feel comfortable making edits to old newsletters on the website that make them more accurate/clearer for readers, since I see them as a more permanent resource. We can discuss more over the IRC.
| - **COSHV proposal replaced:** the author of the COSHV proposal we described | ||
| [last week][news48 coshv] has replaced it with a [similar | ||
| proposal][alt-coshv] (under a different name). The new proposal checks more | ||
| than just the hash of a transaction's outputs, now it includes the transaction's |
There was a problem hiding this comment.
nit: replace the comma with a -, ;, or and now also includes...
| than just the hash of a transaction's outputs, now it includes the transaction's | ||
| version number, number of inputs, sequence numbers, and locktime. This | ||
| change eliminates concerns related to transaction malleability that would've | ||
| affected using the opcode with some types of payment channels (such as those |
There was a problem hiding this comment.
nit: shorten this to "using the opcode with Lightning Network and other contract proposals."
|
|
||
| - [LND #2985][] waits to relay gossip announcements until there are there are | ||
| at least ten of them to send and five seconds have elapsed since the previous | ||
| batch, reducing bandwidth overhead. |
There was a problem hiding this comment.
Maybe note that as the number of channels on the lightning network has increased, all LN implementations have had to do work to handle gossip messages efficiently (eg LND 2538, c-lighning 2297 and eclair 948)
jnewbery
changed the title
harding
changed the title
|
Pushed edits for @jnewbery feedback (thanks!) and some final small edits of my own. Unless there's any additional feedback, the only todo is adding the link to Kotliar's video. |
|
ACK 3da641d @harding is going to add a 'Bitcoin Core Review Club' blurb, then I think it's ready for @bitschmidty to squash and merge. |
|
I've moved the 'Optech recommends' section further up (in my mind the regular weekly sections 'bech32 support' and 'notable commits' fit together), and reworded slightly to remove the repeated 'established' and the names of the contributors. utACK 83e1be1 once the commits have been squashed |
83e1be1 to
57c95b7
Compare
|
ACK 57c95b7 🚢 it! |
|
squashed commits to a single commit and force-pushed |
No description provided.