Newsletters: add 118 (2020-10-07)#471
Conversation
|
I was pointed at this pull by @jonatack :) Wrt mentioned bitcoin/bitcoin#19991 I'd like to note that in Bitcoin Core repo the "onion service" term is preferred to "hidden service". Details: bitcoin/bitcoin#19638 |
| signing that would use a technique called virtual transactions. The | ||
| first virtual transaction would be deliberately invalid by | ||
| attempting to spend from a non-existent previous transaction (one | ||
| who's txid was all zeroes). This first transaction pays the address |
| The advantage to using virtual transactions, which were also adopted | ||
| in the [BIP325][] specification for [signet][topic signet] (see | ||
| [Newsletter #109][news109 signet bip]), is that they may work with | ||
| existing software that's willing to sign arbitrary transactions, |
There was a problem hiding this comment.
maybe s/willing/able/ (though perhaps the soul of the machine means that software can be willing ;)
|
|
||
| - **Brief discussion about merging taproot in Bitcoin Core:** this | ||
| week's Bitcoin Core Developer Meeting included a [brief discussion][meeting | ||
| taproot] about whether the main taproot implementation ([PR |
There was a problem hiding this comment.
as the implementation PR changed recently, perhaps:
(currently PR #19953)
| week's Bitcoin Core Developer Meeting included a [brief discussion][meeting | ||
| taproot] about whether the main taproot implementation ([PR | ||
| #19953][bitcoin core #19953]) should be merged in the next couple | ||
| weeks before the version 0.21 code is scheduled to be branched off, |
There was a problem hiding this comment.
maybe s/branch-off/feature freeze/ (I'm guessing you simplified it for the reader, but since FF is mentioned in the next paragraph it may be fine to say it here)
| #19953][bitcoin core #19953]) should be merged in the next couple | ||
| weeks before the version 0.21 code is scheduled to be branched off, | ||
| whether it should be merged into the development branch shortly after | ||
| the branch off, or whether there should be no special ordering. All |
There was a problem hiding this comment.
s/branch off/branch-off/ (see also release-notes.md)
| - [Bitcoin Core #15367][] feature: Added ability for users to add a startup command FIXME:dongcarl | ||
|
|
||
| - [Bitcoin Core #19723][] ignores unknown P2P protocol messages sent | ||
| before the `verack` (version acknowledgment) message. This allows a |
There was a problem hiding this comment.
maybe something like "message, rather than considering them as peer misbehavior" to make the change from previous behavior more clear (like in line 125 below)
There was a problem hiding this comment.
Yes, I think something like this is needed. The change in n19723 allows future nodes to use the pre-verack feature negotiation method in a backwards-compatible way (i.e. that future node can send feature negotiation messages without being disconnected from old peers).
| - [Bitcoin Core #19725][] updates the `getpeerinfo` RPC. Its results | ||
| now return a new `connection_type` field that indicates the | ||
| reason the node either opened that connection to an outbound peer or | ||
| accepted in inbound connection from the peer. The existing `addnode` |
| notification. | ||
|
|
||
| - [Bitcoin Core #19501][] updates the `sendtoaddress` and `sendmany` | ||
| RPCs with a new optional `verbose` parameter that will return what |
There was a problem hiding this comment.
s/will return/returns/ (present tense as seen in the other PR summaries)
idem in line 134
| - [Eclair #1528][] allows plugins (see [Newsletter #43][news43 | ||
| eclair plugins]) to register new features and message types. The | ||
| features will be advertised to peers and potential peers, and any | ||
| messages using a registered message types will be routed to the appropriate |
There was a problem hiding this comment.
s/types/type/ or omit "a"
There was a problem hiding this comment.
A few small style comments (I see some overlap with Jon's that I didn't see before submitting)
The only thing that stood out was the IRC discussion section about whether to merge taproot. I'm -0.5 on this as I worry that it signals that taproot will be merged in the next 10 days (yes, I know you stressed that isn't the case in the write-up). I just worry that optimism of this kind has the potential to add more pressure to a review process without much margin for error.
| messages identifying any special features it supports, and then its | ||
| `verack` message indicating it has received the remote node's |
There was a problem hiding this comment.
Suggest two sentences here.
| messages identifying any special features it supports, and then its | |
| `verack` message indicating it has received the remote node's | |
| messages identifying any special features it supports. Its | |
| `verack` message then indicates it has received the remote node's |
| mechanism was used to select the transaction's feerate, such as | ||
| whether the user manually selected the feerate, an appropriate feerate |
There was a problem hiding this comment.
Another long sentence that could be broken into two:
| mechanism was used to select the transaction's feerate, such as | |
| whether the user manually selected the feerate, an appropriate feerate | |
| mechanism was used to select the transaction's feerate. Common use cases might | |
| include whether the user manually selected the feerate, an appropriate feerate |
| - [Eclair #1528][] allows plugins (see [Newsletter #43][news43 | ||
| eclair plugins]) to register new features and message types. The | ||
| features will be advertised to peers and potential peers, and any | ||
| messages using a registered message types will be routed to the appropriate |
There was a problem hiding this comment.
| messages using a registered message types will be routed to the appropriate | |
| messages using registered message types will be routed to the appropriate |
| that peer, it routes the payment by whichever channel has the least | ||
| amount of remaining bitcoin value. This means attackers will end up | ||
| jamming low-value channels before high-value channels. This doesn't | ||
| eliminate the attack but it does mean an attacker will need more |
There was a problem hiding this comment.
| eliminate the attack but it does mean an attacker will need more | |
| eliminate the attack, but it does mean an attacker will need more |
| jamming attacks. When a node receives a payment it's supposed to | ||
| route to one of its peers, and it has two or more channels open to | ||
| that peer, it routes the payment by whichever channel has the least | ||
| amount of remaining bitcoin value. This means attackers will end up |
There was a problem hiding this comment.
This sentence is a little hard to read... I tried to clarify:
| jamming attacks. When a node receives a payment it's supposed to | |
| route to one of its peers, and it has two or more channels open to | |
| that peer, it routes the payment by whichever channel has the least | |
| amount of remaining bitcoin value. This means attackers will end up | |
| jamming attacks. When a node receives a payment that it's supposed | |
| to route to a peer connected by two or more open channels, it routes | |
| the payment by whichever channel has the least amount of remaining | |
| bitcoin value. This means attackers will end up |
| included onchain because it spends from an invalid previous | ||
| transaction). | ||
|
|
||
| The advantage to using virtual transactions, which were also adopted |
There was a problem hiding this comment.
| The advantage to using virtual transactions, which were also adopted | |
| The advantage of using virtual transactions, which were also adopted |
I have the same concern and it didn't turn out to be as useful a section as I hoped (I was hoping it would encourage people to do final reviews---both the people who committed in the meeting and anyone else who wanted to review). I'll leave it in for now and make a decision about keeping/removing it tomorrow (Tuesday) to see if anyone else has an opinion. |
Maybe too early to know. (I'm planning on finishing reviewing at the latest this weekend). In any case, this newletter seems an ideal date to publish it, if the goal is to stimulate a final review push. |
| whether the user manually selected the feerate, an appropriate feerate | ||
| was automatically selected, or the configured fallback feerate was used. | ||
|
|
||
| - [Bitcoin Core #20003][] will result in the program immediately exiting |
There was a problem hiding this comment.
I say "the program" here because you can run Bitcoin Core under several names (bitcoind, bitcoin-qt, bitcoin-node (with certain --configure options), bitcoin-core (in the Snap), etc...). No matter which name you use, the --proxy behavior described here should apply.
|
Newsletter looks good so far. I dont not have a strong opinion on the taproot messaging. |
jnewbery
left a comment
There was a problem hiding this comment.
Looks good harding. Just a couple of small comments inline.
I'd lean towards removing the taproot merge section. It doesn't feel newsworthy that developers are prioritizing reviewing a particular PR (even though the historic comparison to segwit is interesting)
| - [Bitcoin Core #15367][] feature: Added ability for users to add a startup command FIXME:dongcarl | ||
|
|
||
| - [Bitcoin Core #19723][] ignores unknown P2P protocol messages sent | ||
| before the `verack` (version acknowledgment) message. This allows a |
There was a problem hiding this comment.
Yes, I think something like this is needed. The change in n19723 allows future nodes to use the pre-verack feature negotiation method in a backwards-compatible way (i.e. that future node can send feature negotiation messages without being disconnected from old peers).
|
Removed the taproot bullet per discussion above and made most other suggested edits. Thanks for the reviews! |
|
|
||
| - [Bitcoin Core #15367][] adds a `-startupnotify` configuration parameter that accepts | ||
| a shell command to be executed after Bitcoin Core has finished its | ||
| initialization and is ready to handle requests on enabled interfaces (ZMQ, |
There was a problem hiding this comment.
minor point: the ZMQ interface doesn't service requests, it only serves notifications.
|
One minor comment on the Bitcoin Core 15367 write-up. Otherwise all looks good! |
| signing that would use a technique called virtual transactions. The | ||
| first virtual transaction would be deliberately invalid by | ||
| attempting to spend from a non-existent previous transaction (one | ||
| whose txid was all zeroes). This first transaction pays the address |
|
Changes look good to me, no further comments. |
jnewbery
left a comment
There was a problem hiding this comment.
19898 write-up looks great. Just one minor comment.
| log to be printed only when the validation log category is set, rather than | ||
| unconditionally. Originally designed to alarm users that miners and users | ||
| might be coordinating a soft fork activation using BIP9 versionbits, these | ||
| frequent warnings had become spurious and were both unactionable and the |
There was a problem hiding this comment.
'a source' sounds marginally better to me than 'the source'
|
Light rescan ACK. Nothing to add besides what's already been mentioned. |
|
Pushed (hopefully) final edits. Thanks everyone for the contributions and reviews! No releases/RC changes. |
5005843 to
c81aef1
Compare
Bitcoin Core #19898log: print unexpected version warning in validation log category @jonatackBitcoin Core #15367feature: Added ability for users to add a startup command @dongcarl