Newsletters: add 65 #227

harding · 2019-09-19T23:54:54Z

No description provided.

harding

A couple concerns about confusion, but otherwise the B.SE section looks great. Thanks, @bitschmidty!

harding · 2019-09-23T23:28:53Z

_posts/en/newsletters/2019-09-25-newsletter.md

+- [Why does this coinbase transaction have two op_return outputs?]({{bse}}90127)
+Murch outlines that while there are some restrictions on coinbase transactions,
+there are no special script or quantity restrictions regarding coinbase
+transaction outputs.


Murch's full answer seems a bit confused to me by noting a place where generation transaction outputs are restricted (the case where the block contains segwit transactions) and then saying that there are no restrictions. Your summary only quotes the later part and so (it seems to me) twists the answer from confusing to wrong. I left a comment for Mark on the SE; maybe this could say something like "....regarding coinbase transaction outputs, save that any blocks containing segwit spends must have an output matching the BIP141 commitment structure."

Pushed a change based on Murch's revised answer and your feedback. Feel free to tweak!

harding · 2019-09-23T23:38:12Z

_posts/en/newsletters/2019-09-25-newsletter.md

+- [Why was 550 (MiB) chosen as a minimum storage size for prune mode?]({{bse}}90140)
+Behrad Khodayar answers his own question about why 550 (MiB) was chosen
+as a minimum storage size for pruned nodes. The storage amount was chosen
+to keep 288 blocks, about two days worth, on disk.


Maybe say "...keep 288 blocks worth of state transition data, about two days worth, on disk" as the data included in this calculation is both blocks and undo data (undo data is the UTXOs each block spends and which are then removed from the UTXO set; if the block is later forked off the chain, those UTXO entries need to be re-added to the database).

The original answer doesn't note this and I'm not sure we do either---since the question is about why the original number was chosen---but the two day value no longer stands as the maximum size of blocks was increased by segwit (also the typical size of undo data, although I think the adversarial size remains the same).

Took your suggestion and also added "originally" and "pre-segwit". You’re welcome to push a change if there is a better wording.

harding · 2019-09-24T02:27:41Z

Untested bf20f46 SE section LGTM. Thanks!

jnewbery · 2019-09-24T06:09:30Z

I've only had time for a quick skim this week, but everything looks good to me. Thanks @harding! And thanks @bitschmidty for the SE section!

jonatack

Great newletter! Embarassed apologies for all the comments below--your time is short, feel free to gleefully ignore, my ego isn't tied to them :) Tested the four links at the bottom, and they are all worth re-reading after this review. Thanks again, Dave.

jonatack · 2019-09-24T08:25:37Z

_posts/en/newsletters/2019-09-25-newsletter.md

+  creating taproot inputs by paying P2SH outputs (the way you can
+  currently use P2WPKH and P2WSH inputs created from P2SH outputs).
+  Anyone who expects to need P2SH-wrapped taproot should describe their
+  planned usecase on the mailing list or by contacting the bip-taproot


s/usecase/use case/?

jonatack · 2019-09-24T08:27:21Z

_posts/en/newsletters/2019-09-25-newsletter.md

+  currently use P2WPKH and P2WSH inputs created from P2SH outputs).
+  Anyone who expects to need P2SH-wrapped taproot should describe their
+  planned usecase on the mailing list or by contacting the bip-taproot
+  author privately.


"contacting the author" -> perhaps more details, unless the idea is to not facilitate doing so :)

jonatack · 2019-09-24T08:29:39Z

_posts/en/newsletters/2019-09-25-newsletter.md

+- **Tapscript resource limits:** the [bip-tapscript][] proposal limits
+  transactions to one signature-checking operation (sigop) for every 12.5 vbytes
+  the witness data adds to the size of the transaction (plus one free
+  sigop per input).  Because signatures are expected to be 16.0 vbytes,


sigop or SigOp, perhaps a style guide candidate unless an obvious/pre-established choice

jonatack · 2019-09-24T08:35:14Z

_posts/en/newsletters/2019-09-25-newsletter.md

+- **Tapscript resource limits:** the [bip-tapscript][] proposal limits
+  transactions to one signature-checking operation (sigop) for every 12.5 vbytes
+  the witness data adds to the size of the transaction (plus one free
+  sigop per input).  Because signatures are expected to be 16.0 vbytes,


nit: leading because; maybe "Signatures are expected to be 16 vbytes, so/therefore this limit should prevent abuse..." or similar

jonatack · 2019-09-24T08:36:15Z

_posts/en/newsletters/2019-09-25-newsletter.md

+  the witness data adds to the size of the transaction (plus one free
+  sigop per input).  Because signatures are expected to be 16.0 vbytes,
+  this limit prevents abuse without affecting normal users.  Compared to
+  earlier abuse-prevention solutions, it means any valid taproot


nit: can remove "it means"

jonatack · 2019-09-24T09:01:48Z

_posts/en/newsletters/2019-09-25-newsletter.md

+
+- [Bitcoin Core #16400][] refactors part of the mempool transaction
+  acceptance code.  We don't usually cover refactors, but this one has a
+  tantalizing comment---"this is in preparation for re-using these


perhaps: /---/: /

jonatack · 2019-09-24T09:04:24Z

_posts/en/newsletters/2019-09-25-newsletter.md

+  acceptance code.  We don't usually cover refactors, but this one has a
+  tantalizing comment---"this is in preparation for re-using these
+  validation components for a new version of `AcceptToMemoryPool()` that
+  can operate on multiple transactions ("package relay")."  Package


Can we haz avoid nested double quotes? Perhaps with italics or single quotes around package relay. FWIW package relay is the PR review club topic next week!

maybe it's perfectly legal, and the issue is the programmer in me that can't read them without wanting to \"escape\" the inside ones

maybe it's perfectly legal

Different style guides deal with it differently. Many allow it, but the style I personally use doesn't and I knew it when I lazily pasted this quote without editing, so thanks for calling me out on it. :-)

jonatack · 2019-09-24T09:04:55Z

_posts/en/newsletters/2019-09-25-newsletter.md

+  tantalizing comment---"this is in preparation for re-using these
+  validation components for a new version of `AcceptToMemoryPool()` that
+  can operate on multiple transactions ("package relay")."  Package
+  relay could allow allow nodes to accept a transaction below the node's


allow allow for extra permissivity

allow allow for extra permissivity

Do you have an example? I'd only heard of package relay being used to allow relay of transactions below the BIP133 minimum.

Oh, I was only mentioning that there is an extra "allow" in the sentence.

Oh, :picard_facepalm:

jonatack · 2019-09-24T09:09:11Z

_posts/en/newsletters/2019-09-25-newsletter.md

+  users who create transactions a long time before broadcasting them
+  (e.g. timelocked transactions or LN commitment transactions) to safely
+  pay the minimum possible fee.  When it came time to broadcast the
+  transaction, they could use Child-Pays-For-Parent (CPFP) fee bumping


unsure about those hyphens :D

jonatack · 2019-09-24T09:10:55Z

_posts/en/newsletters/2019-09-25-newsletter.md

+- [BOLTs #557][] updates [BOLT7][] gossip entries with an optional
+  extended query flag that allows nodes to request additional
+  information, namely a timestamp and checksum for each channel update
+  the node relays.  The node can then use another new feature in


"another new feature": which one?

bitschmidty

@jonatack thanks for the feedback. I pushed a change that made applicable changes to the SE section using my (dangerous!) best judgment.

moneyball · 2019-09-24T15:29:14Z

_posts/en/newsletters/2019-09-25-newsletter.md

+    > * Drop the 201 non-push ops limit per script.
+    > * Drop the 100 input stack elements standardness limit, and
+    >   replace with a (consensus) 1,000 limit.
+


What is the unit of the 1,000 limit?

From Pieter's email: "I believe we should keep this 1000 element stack limit for these reasons. " So I think we should state the unit "elements" in the newsletter.

That sentence does state the unit "stack elements".

harding · 2019-09-24T16:35:38Z

Pushed a commit with edits for @jonatack's feedback minus a few nits I thought were good enough as-is. Thanks!

jonatack · 2019-09-24T16:55:08Z

_posts/en/newsletters/2019-09-25-newsletter.md

@@ -46,12 +46,12 @@ popular Bitcoin infrastructure projects.
    He describes some of their findings and advocates the following rule
    changes:

-    > * Replace the separate sigops counter with a "executed sigops must
+    > * Replace the separate sigops counter with a [rule that] "executed sigops must
    >   not exceed (witness size / [12.5 vbytes]) + 1" rule (already in the BIP).


@harding should now drop the second instance of "rule" in the sentence?

Ugh. I'm going to revert this to just sipa's text, I think it's good enough and anyone who's confused can just read his entire email.

bitschmidty · 2019-09-25T14:05:08Z

Should taproot have p2sh-wrapped support?
Publishing this newsletter from the airport

Pieter and Poelstra doing script analyzing
Harding throwing out the word ‘tantalizing’

Great newsletter @harding
Thanks @jonatack for the reviews

Newsletters: add 65

807b8c8

harding commented Sep 23, 2019

View reviewed changes

jonatack reviewed Sep 24, 2019

View reviewed changes

bitschmidty reviewed Sep 24, 2019

View reviewed changes

moneyball reviewed Sep 24, 2019

View reviewed changes

harding mentioned this pull request Sep 24, 2019

Style guide updates #171

Closed

jonatack reviewed Sep 24, 2019

View reviewed changes

news65: add stack exchange

b7abc7c

bitschmidty force-pushed the 2019-09-25-newsletter branch from 057b2f6 to b7abc7c Compare September 25, 2019 13:29

bitschmidty merged commit 04ea81c into bitcoinops:master Sep 25, 2019

jnewbery added the newsletters Publishing/translating/editing newsletters label Oct 31, 2019

jirijakes mentioned this pull request Nov 23, 2022

Newsletter-227: Translate into Czech #942

Merged

murchandamus mentioned this pull request Jul 17, 2023

Newsletter 257 translate in french #1182

Merged

murchandamus mentioned this pull request Aug 1, 2023

Harmonize titles of French Newsletters #1222

Merged

Newsletters: add 65 #227

Newsletters: add 65 #227

Uh oh!

Conversation

harding commented Sep 19, 2019

Uh oh!

harding left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

harding commented Sep 24, 2019

Uh oh!

jnewbery commented Sep 24, 2019 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

jonatack left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

jonatack Sep 24, 2019 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

jonatack Sep 24, 2019 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

bitschmidty left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

harding commented Sep 24, 2019

Uh oh!

jonatack Sep 24, 2019 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

bitschmidty commented Sep 25, 2019

Uh oh!

Uh oh!

jnewbery commented Sep 24, 2019 •

edited

Loading

jonatack Sep 24, 2019 •

edited

Loading

jonatack Sep 24, 2019 •

edited

Loading

jonatack Sep 24, 2019 •

edited

Loading