New topics: OP_CHECKSIGFROMSTACK

[harding]

This brings us to 8/16 topics that I should've submitted by now.

The CSFS, CTV, and Vaults topics all derive somewhat from the existing Covenants topic, but I think it was time for them to each have separate topics. I've left the Covenants topic for now without any deletions to its existing links, but going forward I plan mainly to only use it for topics that are much more specific to covenants.

[kanzure]

By the way there was a discussion today about this,
https://diyhpl.us/wiki/transcripts/london-bitcoin-devs/2020-05-19-socratic-seminar-vaults/

There's also Jeremy's vault implementation which is in his bip119 branch.

There's also Fidelity's version- https://github.com/fmr-llc/Vault-mbed

and this thing https://github.com/JSwambo/bitcoin-vault

[jonatack]

Looks very good so far!

[jnewbery]

I've only reviewed the 'large channels' topic. Just a couple of comments on that one.

[jnewbery]

Just a quick scan of the OP_CHECKSIGFROMSTACK page. Most of the text is good, but I think it could be reformatted/rearranged to make the point a bit clearer.

[jnewbery]

I found this description quite confusing on first read. It wasn't initially clear to me that this paragraph and the rest of the summary were about a scheme to use OP_CSFS to do transaction introspection.

Is it possible to use subheadings in the summary? If so, perhaps this would be clearer as follows:

<generic description of OP_CSFS and existing OP_CHECKSIG opcodes>

#### Using OP_CSFS for transaction introspection

One of the most interesting applications of OP_CSFS is to be able to _introspect_ arbitrary parts of the transaction.

<describe what introspection means, using CLTV as an example>

<describe how OP_CSFS can be used for transaction introspection>

<some examples of what tx introspection could allow>

[harding]

1. Subheadings can be used in a summary, we already use one on the codesep topic: https://bitcoinops.org/en/topics/op_codeseparator/#later-changes-and-proposals

2. I don't mind adding the subhead you suggest, but I think it suggests that there are multiple uses for CSFS---yet I'm unaware of any that can't be done more efficiently some other way (e.g. paying for signatures to arbitrary messages can be done using adapter signatures).

[harding]

Er, for point n2, I meant to ask: are there any other uses you're aware of? If not, I think I'll just try rewriting to see if I can make the text more congruous.

[jnewbery]

I'm unaware of any that can't be done more efficiently some other way (e.g. paying for signatures to arbitrary messages can be done using adapter signatures).

Perhaps that's worth stating explicitly in the summary? I (not having looked into OP_CSFS) assumed that there would be other use cases for checking signatures over arbitrary messages in script.

[harding]

I asked about other uses in #sidechains-dev and Russell O'Connor replied, "Prior to introspection, I always assumed that CHECKSIGFROMSTACK was for oracle, as in a trusted third party that signs the outcome of various events in order to facilitate prediction / futures markets."

Although I think DLCs would be more private and efficient for that, there's an admirable simplicity to a contract that's <hash('The agreement...')> <oracle_pubkey> OP_CSFS (and DLCs weren't proposed when CSFS was first made available on Elements).

Anyway, I'll rewrite the topic and try to make the article clearer.

[harding]

I've narrowed this PR to just the OP_CHECKSIGFROMSTACK topic and updated it to describe all usecases for that opcode that I've been able to find. It should be ready for review again. Thanks for the previous feedback!

[jnewbery]

This is great. I think it's much clearer than the first version and is probably the best summary of OP_CFSF I've seen anywhere. Great stuff, @harding !

A few small nits inline. Feel free to take or ignore.

[jnewbery]

Perhaps 'precludes' instead of disallows?

[jnewbery]

nit: this may look better as h4, for more obvious contrast with the h2 "Primary code and documentation" element below.

[harding]

I made the h3 styling bolder to hopefully distinguish it from h4h2, that way we don't have to implement your craaaaaazy idea of skipping a level. Let me know if this is acceptable.

• Old:
  

• New:
  

[jnewbery]

Let's revert this. My suggestion to use h4 was to make it more obvious that it was a subsection of the summary, and not a sibling of the "Primary code..." and "Optech newsletter..." headings. To my eye, the boldening might make it look like it's a parent of those elements.

(I have ~zero talent for design, so feel free to tell me I'm talking nonsense).

This also has the undesirable side-effect of making all h3s on the site bold, including the newsletter links on our home page and newsletter index.

[jnewbery]

I think this is ready for merge once the h3 style change is reverted.