Newsletters: add 80 (2019-01-13) #314
Conversation
|
Ive looked into the failing of these checks and was able to force another netlify build which seemed to work. I suspect the next push to this branch will resolve the ❌ s |
harding
changed the title
harding
force-pushed
the
2020-01-15-newsletter
branch
from
914a6bc
to
36ab13f
Compare
|
Made edits for @bitschmidty feedback (thanks!). Force pushed because I had to correct a typo in the commit message anyway. |
|
|
||
| 4. The prevention, as much as possible, of the creation of blocks | ||
| that are invalid under the new rules, which could lead to false | ||
| confirmations in unupgraded nodes and SPV clients |
There was a problem hiding this comment.
perhaps s/unupgraded/non-upgraded/
| confirmations in unupgraded nodes and SPV clients | ||
|
|
||
| 5. The assurance that the abort mechanisms can't be misused by | ||
| griefers or partisans to withhold a widely-desired upgrade with |
| Corallo believes that a well-crafted soft fork using the [BIP9][] | ||
| versionbits activation mechanism and surrounded with good community | ||
| engagement fulfills the first four criteria---but not the fifth. | ||
| Alternatively, a [BIP8][] flag-day soft fork fulfills the fith |
|
|
||
| As an alternative to either BIP9 or BIP8 alone, Corallo proposes | ||
| a three-step process: use BIP9 to allow a proposal to be | ||
| activated within a one-year window; pause for a six month discussion |
There was a problem hiding this comment.
Nit: I'm not sure whether one-year, six-month and 42-month should be hyphened as used here (leaning toward yes), but perhaps they should be used consistently.
| activation possible using versionbits signaling). Node software can | ||
| prepare for this maximum 42 month process by including, even in its | ||
| initial versions, a configuration option users can manually enable | ||
| to enforce the BIP8 flag day if necessary. If the first 18 months of |
There was a problem hiding this comment.
Two uses of "flag-day" above followed by "flag day" here and again a little further down
There was a problem hiding this comment.
Good catch. One of the uses is "flag-day soft fork". I'm leaving the hyphen there and removing it in the other non-modifier usecases. Thanks!
| using a BIP8 flag-day set to two years in the future (with faster | ||
| activation possible using versionbits signaling). Node software can | ||
| prepare for this maximum 42 month process by including, even in its | ||
| initial versions, a configuration option users can manually enable |
There was a problem hiding this comment.
maybe s/option users/option that users/ for clarity
|
|
||
| - [Bitcoin Core #17578][] updates the `getaddressinfo` RPC to return an | ||
| array of strings corresponding to the labels used by an address. | ||
| Previously, it returned an array of objects where each label contained |
There was a problem hiding this comment.
Thanks for mentioning this PR :D 🍰... might be too deep into the weeds to mention, but only one label can be associated with an address, so perhaps s/labels used/label used/. May propose multiple labels soon.
| P2PKH, P2WPKH, P2SH-P2WPKH)---could be associated with each other on | ||
| the block chain even though the `avoid_reuse` behavior is supposed to | ||
| prevent this type of linkability. This merged PR fixes the problem for the | ||
| `avoid_reuse` flag and the ongoing adoption of [output script |
There was a problem hiding this comment.
nit: s/flag/flag,/ (or make two sentences) for clarity
There was a problem hiding this comment.
perhaps worth mentioning that this PR is being backported in bitcoin/bitcoin#17792 for release in 0.19.1
| - **Discussion of soft fork activation mechanisms:** Matt Corallo | ||
| started a [discussion][corallo sf] on the Bitcoin-Dev mailing list about | ||
| what attributes are desirable in a soft fork activation method and | ||
| submitted a proposal for a mechanism that contains those attributes. |
There was a problem hiding this comment.
FWIW I followed this ML exchange with interest, but wondered what the context was for launching the discussion. Was there an event, a trigger, something in particular? If yes, I think it would be interesting to mention it.
There was a problem hiding this comment.
There was a bit of discussion about what upgrade mechanism to use for taproot a few weeks ago; this didn't involve Matt (although he was mentioned): http://www.erisian.com.au/meetbot/taproot-bip-review/2019/taproot-bip-review.2019-12-17-19.01.log.html#l-56
But I don't know for sure whether that had anything to do with Matt's post, so I hesitate to link to it.
There was a problem hiding this comment.
Thanks @harding. I agree that it's too tenuous to link to it.
|
ACK 182cbab. I've marked all resolved comments as resolved |
|
ACK be6749e edits |
|
ACK be6749e |
bitschmidty
force-pushed
the
2020-01-15-newsletter
branch
from
be6749e
to
087bb27
Compare
|
ACK be6749e Squashed and merged 100th bitdevs happened in New York Changes in #16373 |
No description provided.