Topics: add new topics (jnewbery)

[harding]

Eight proposed pages for the new /en/topics/ section of the site. Suggested reviewer is @jnewbery

Note: tests expected to fail on the final "production" test because of the FIXME link pointing to a topic that's part of a different PR. That's the last test we run, so if it's the only failure, this should be ok.

[jnewbery]

Reviewing:

• compact-block-filters.md
• countersign.md
• cpfp-carve-out.md
• cve-2018-17144.md
• erlay.md
• replace-by-fee.md
• transaction-pinning.md
• v2-p2p-transport.md

[jnewbery]

Reviewed:

• compact-block-filters.md
• countersign.md
• cpfp-carve-out.md
• cve-2018-17144.md
• erlay.md
• replace-by-fee.md
• transaction-pinning.md
• v2-p2p-transport.md

[jnewbery]

Done a first pass of everything:

• compact-block-filters.md
• countersign.md
• cpfp-carve-out.md
• cve-2018-17144.md
• erlay.md
• replace-by-fee.md
• transaction-pinning.md
• v2-p2p-transport.md

[jnewbery]

ACK bd7556d

Great stuff @harding . Thanks for putting up with all my pedantry :)

[jnewbery]

This is ready for merge once the minisketch topic is merged (#243)

[harding]

@jnewbery this commit confuses me; why did you restore the prevout terminology after arguing against it?

[jnewbery]

why did you restore the prevout terminology after arguing against it?

Oops. I just wanted to revert the change I was talking about here: #246 (comment), and carelessly also re-added the reference to prevout.

I think the wording about 'the data necessary to validate the block' or 'some related data' is just confusing and unnecessary for the following reasons:

• A full node creates the GCS from the block data and undo data (see https://github.com/bitcoin/bitcoin/blob/master/src/blockfilter.cpp#L258). I wouldn't refer to undo data as 'data necessary to validate a block' so much as 'data necessary to rewind a block'
• If the index is sync'ed, then the full node obviously has the block data and undo data to construct the GCS.
• if the index is not sync'ed and wants to construct the GCS for an old block, then either:
  • the node has the historic block data and undo data and can construct the GCS
  • the node has pruned both the block data and undo data and can't construct the GCS (we prune block data and undo data for the same block at the same time)

The fact that a full node can construct a block filter index asynchronously from old data is really an implementation detail. I don't think it's important for understanding the concept.

I've added another commit that removes mention of 'additional data'. Let me know what you think.

[harding]

Your edit 76bb411 LGTM. Thanks. To nitpick your message a little:

I wouldn't refer to undo data as 'data necessary to validate a block' so much as 'data necessary to rewind a block'

Before the data is placed in the undo file, it's part of the set of data that's necessary to validate a block. After it's in the undo file, it's part of what's used to rewind a block. So I think it's fair to describe it either way.

The fact that a full node can construct a block filter index asynchronously from old data is really an implementation detail. I don't think it's important for understanding the concept.

I don't think I mentioned asynchronicity. I thought it was useful to mention the both data sources because otherwise it's hard for someone already familiar with the protocol to understand how data from just a single block can allow a wallet "to search for any matches to their scripts", since inputs don't necessary identify their scripts (e.g. the input spending a P2PK or bare multisig will just be a random-looking signature or set of signatures).

I'm sure you're right about the description getting into the weeds, which is why I'm fine with this removal, but I wanted to explain why I thought it was useful to note.

[jnewbery]

This is ready for merge once minisketch (#243) is merged

[jnewbery]

Squashed fixup commits and cherry-picked the commits from #243.