Re: [bitcoin-dev] CHECKSIGFROMSTACK/{Verify} BIP for Bitcoin

[David A. Harding via bitcoin-dev]

On Sat, Jul 03, 2021 at 09:31:57AM -0700, Jeremy via bitcoin-dev wrote:
> Note that with *just* CheckSigFromStack, while you can do some very
> valuable use cases, but without OP_CAT it does not enable sophisticated
> covenants

Do you have concerns about sophisticated covenants, and if so, would you
mind describing them?  Your BIP119 CTV also mentions[1] being designed
to avoid sophisticated covenants.  If this is some sort of design
principle, I'd like to understand the logic behind it.

I'm a fan of CSFS, even mentioning it on zndtoshi's recent survey[2],
but it seems artificially limited without OP_CAT.  (I also stand by my
answer on that survey of believing there's a deep lack of developer
interest in CSFS at the moment.  But, if you'd like to tilt at that
windmill, I won't stop you.)

-Dave

[1] 
https://github.com/bitcoin/bips/blob/master/bip-0119.mediawiki#design-tradeoffs-and-risks

[2] https://twitter.com/zndtoshi/status/1405235814712422402



signature.asc
Description: PGP signature
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] CheckSigFromStack for Arithmetic Values

[ZmnSCPxj via bitcoin-dev]

Good morning Erik,

> i may be ignorant here but i have a question:
>
> Given that schnorr signatures now allow signers to perform complex arithmetic 
> signing operations out-of-band using their own communications techniques, 
> couldn't you just perform the publishing and accumulation of these signature 
> components without using a bitcoin script?
>
> In other words, push the effort of combination and computation off of the 
> bitcoin network and nodes.

Actually the post is not about *doing* Arithmetic using signing operations, it 
is about enabling signing operations *at all* using arithmetic operation 
`OP_ADD`.
Jeremy in the initial post is not doing arithmetic, he is using arithmetic to 
implement Lamport signatures (which cannot support arithmetic signing 
operations anyway, being a hash-based signing scheme).

The "for" arithmetic here is largely to mean that this cleverness allows an 
implementation of `OP_CHECKSIGFROMSTACK`, using arithmetic operation `OP_ADD`.

To my mind this cleverness is more of an argument against ever enabling 
`OP_ADD` and friends, LOL.
This is more of a "bad but ridiculously clever thing" post than a "Bitcoin 
should totally use this thing" post.

Regards,
ZmnSCPxj

>
> On Sat, Jul 3, 2021 at 12:01 AM Jeremy via bitcoin-dev 
>  wrote:
>
> > Yep -- sorry for the confusing notation but seems like you got it. C++ 
> > templates have this issue too btw :)
> >
> > One cool thing is that if you have op_add for arbitrary width integers or 
> > op_cat you can also make a quantum proof signature by signing the signature 
> > made with checksig with the lamport.
> >
> > There are a couple gotchas wrt crypto assumptions on that but I'll write it 
> > up soon 🙂 it also works better in segwit V0 because there's no keypath 
> > spend -- that breaks the quantum proofness of this scheme.
> >
> > On Fri, Jul 2, 2021, 4:58 PM ZmnSCPxj  wrote:
> >
> > > Good morning Jeremy,
> > >
> > > > Dear Bitcoin Devs,
> > > >
> > > > It recently occurred to me that it's possible to do a lamport signature 
> > > > in script for arithmetic values by using a binary expanded 
> > > > representation. There are some applications that might benefit from 
> > > > this and I don't recall seeing it discussed elsewhere, but would be 
> > > > happy for a citation/reference to the technique.
> > > >
> > > > blog post here, https://rubin.io/blog/2021/07/02/signing-5-bytes/, text 
> > > > reproduced below
> > > >
> > > > There are two insights in this post:
> > > > 1. to use a bitwise expansion of the number
> > > > 2. to use a lamport signature
> > > > Let's look at the code in python and then translate to bitcoin script:
> > > > ```python
> > > > def add_bit(idx, preimage, image_0, image_1):
> > > >     s = sha256(preimage)
> > > >     if s == image_1:
> > > >         return (1 << idx)
> > > >     if s == image_0:
> > > >         return 0
> > > >     else:
> > > >         assert False
> > > > def get_signed_number(witnesses : List[Hash], keys : List[Tuple[Hash, 
> > > > Hash]]):
> > > >     acc = 0
> > > >     for (idx, preimage) in enumerate(witnesses):
> > > >         acc += add_bit(idx, preimage, keys[idx][0], keys[idx][1])
> > > >     return x
> > > > ```
> > > > So what's going on here? The signer generates a key which is a list of 
> > > > pairs of
> > > > hash images to create the script.
> > > > To sign, the signer provides a witness of a list of preimages that 
> > > > match one or the other.
> > > > During validation, the network adds up a weighted value per preimage 
> > > > and checks
> > > > that there are no left out values.
> > > > Let's imagine a concrete use case: I want a third party to post-hoc 
> > > > sign a sequence lock. This is 16 bits.
> > > > I can form the following script:
> > > > ```
> > > >  checksigverify
> > > > 0
> > > > SWAP sha256 DUP  EQUAL IF DROP <1> ADD ELSE  
> > > > EQUALVERIFY ENDIF
> > > > SWAP sha256 DUP  EQUAL IF DROP <1<<1> ADD ELSE  
> > > > EQUALVERIFY ENDIF
> > > > SWAP sha256 DUP  EQUAL IF DROP <1<<2> ADD ELSE  
> > > > EQUALVERIFY ENDIF
> > > > SWAP sha256 DUP  EQUAL IF DROP <1<<3> ADD ELSE  
> > > > EQUALVERIFY ENDIF
> > > > SWAP sha256 DUP  EQUAL IF DROP <1<<4> ADD ELSE  
> > > > EQUALVERIFY ENDIF
> > > > SWAP sha256 DUP  EQUAL IF DROP <1<<5> ADD ELSE  
> > > > EQUALVERIFY ENDIF
> > > > SWAP sha256 DUP  EQUAL IF DROP <1<<6> ADD ELSE  
> > > > EQUALVERIFY ENDIF
> > > > SWAP sha256 DUP  EQUAL IF DROP <1<<7> ADD ELSE  
> > > > EQUALVERIFY ENDIF
> > > > SWAP sha256 DUP  EQUAL IF DROP <1<<8> ADD ELSE  
> > > > EQUALVERIFY ENDIF
> > > > SWAP sha256 DUP  EQUAL IF DROP <1<<9> ADD ELSE  
> > > > EQUALVERIFY ENDIF
> > > > SWAP sha256 DUP  EQUAL IF DROP <1<<10> ADD ELSE  
> > > > EQUALVERIFY ENDIF
> > > > SWAP sha256 DUP  EQUAL IF DROP <1<<11> ADD ELSE  
> > > > EQUALVERIFY ENDIF
> > > > SWAP sha256 DUP  EQUAL IF DROP <1<<12> ADD ELSE  
> > > > EQUALVERIFY ENDIF
> > > > SWAP sha256 DUP  EQUAL IF DROP <1<<13> ADD ELSE  
> > > > EQUALVERIFY ENDIF
> > > > SWAP sha256 DUP  EQ

Re: [bitcoin-dev] CHECKSIGFROMSTACK/{Verify} BIP for Bitcoin

[Russell O'Connor via bitcoin-dev]

There is one line written at
https://github.com/ElementsProject/elements/pull/949/files#r660130155. I
suppose we need to decide on which variants of *VERIFY and *ADD we want to
include (presumably all of them) and choose which opcodes they will be
assigned to.  And I guess for CHECKSIGFROMSTACKADD will want to place the n
value between the signature and the message on the stack.  ... So I suppose
we will need more than one sentence.

The semantics would be basically to call secp256k1_schnorrsig_verify <
https://github.com/bitcoin-core/secp256k1/blob/0440945fb5ce69d335fed32827b5166e84b02e05/include/secp256k1_schnorrsig.h#L158>,
treating pubkeys and signatures the same way the other CHECKSIG operations
do, and in passing the (variable length) message from the stack.
CHECKSIGFROMSTACK would also be subject to the same sigops budget that
CHECKSIG has in tapscript.

On Sat, Jul 3, 2021 at 2:30 PM Jeremy  wrote:

> Awesome to hear that!
>
> Actually I don't think I did know (or I forgot/didn't catch it) that there
> was an updated spec for elements, I searched around for what I could find
> and came up empty handed. Do you have any links for that? That sounds
> perfect to me.
>
>
> On Sat, Jul 3, 2021, 10:50 AM Russell O'Connor 
> wrote:
>
>> Hi Jermy,
>>
>> As you are aware, we, and by we I mean mostly Sanket, are developing an
>> updated OP_CHECKSIGFROMSTACK implementation for tapscript on elements.  The
>> plan here would be to effectively support the an interface to the
>> variable-length extension of BIP-0340 schnorr signatures.
>>
>> BIP-0340 would dispense with DER encoding (good riddance).
>> BIP-0340 signatures are batch verifiable along with other BIP-0340
>> transaction signatures and taproot tweak verification.
>> Support for variable length messages in BIP-0340 has been discussed in <
>> https://github.com/sipa/bips/issues/207> and an implementation has
>> recently been merged in <
>> https://github.com/bitcoin-core/secp256k1/pull/844>.  The BIP has not
>> yet been updated but the difference is that the message m does not have to
>> be 32-bytes (it is recommended that the message be a 32-bit tagged hash or
>> a message with a 64-bit application specific prefix). The CHECKSIGFROMSTACK
>> operation (in tapscript) would use a stack item for this m value to
>> BIP-0340 signature verification and would not necessarily have to be 32
>> bytes.
>>
>> I think this design we are aiming for would be perfectly suited for
>> Bitcoin as well.
>>
>> On Sat, Jul 3, 2021 at 12:32 PM Jeremy via bitcoin-dev <
>> bitcoin-dev@lists.linuxfoundation.org> wrote:
>>
>>> Reproduced below is the BIP text from Bitcoin Cash's (MIT-Licensed)
>>> specification for "CheckDataSig", more or less the same thing as
>>> CHECKSIGFROMSTACK
>>> https://github.com/bitcoincashorg/bitcoincash.org/blob/master/spec/op_checkdatasig.md.
>>> In contrast to Element's implementation, it does not have Element's bugs
>>> around verify semantics and uses the nullfail rule, and there is a
>>> specification document so it seemed like the easiest starting point for
>>> discussion v.s. drafting something from scratch.
>>>
>>> Does anyone have any issue with adapting this exact text and
>>> implementation to a BIP for Bitcoin using 2 OP_SUCCESSX opcodes?
>>>
>>> Note that with *just* CheckSigFromStack, while you can do some very
>>> valuable use cases, but without OP_CAT it does not enable sophisticated
>>> covenants (and as per
>>> https://www.wpsoftware.net/andrew/blog/cat-and-schnorr-tricks-i.html
>>> just CAT alone enables such uses).
>>>
>>> Design questions worth considering as modifications:
>>>
>>> 1. Should CSFS require some sort of tagged hash? Very likely answer is
>>> no – tags interfere with certain use cases
>>> 2. Should CSFS split the signature’s R & S value stack items for some
>>> applications that otherwise may require OP_CAT? E.g. using a pinned R value
>>> allows you to extract a private key if ever double signed, using 2 R values
>>> allows pay-to-reveal-key contracts. Most likely answer is no, if that is
>>> desired then OP_CAT can be introduced
>>> 3. Should CSFS support a cheap way to reference the taproot internal or
>>> external key? Perhaps, can be handled with undefined upgradeable keytypes.
>>> One might want to use the internal key, if the signed data should be valid
>>> independent of the tapscript tree. One might want to use the external key,
>>> if the data should only be valid for a single tapscript key + tree.
>>> 4. Should invalid public keys types be a NOP to support future extended
>>> pubkey types?
>>>
>>>
>>>
>>> Best,
>>>
>>>
>>> Jeremy
>>>
>>>
>>> ---
>>> layout: specification
>>> title: OP_CHECKDATASIG and OP_CHECKDATASIGVERIFY Specification
>>> category: spec
>>> date: 2018-08-20
>>> activation: 154230
>>> version: 0.6
>>> ---
>>>
>>> OP_CHECKDATASIG
>>> ===
>>>
>>> OP_CHECKDATASIG and OP_CHECKDATASIGVERIFY check whether a signature is 
>>> valid with respect to a message and a public key.
>>>
>>

Re: [bitcoin-dev] CHECKSIGFROMSTACK/{Verify} BIP for Bitcoin

[Jeremy via bitcoin-dev]

Awesome to hear that!

Actually I don't think I did know (or I forgot/didn't catch it) that there
was an updated spec for elements, I searched around for what I could find
and came up empty handed. Do you have any links for that? That sounds
perfect to me.


On Sat, Jul 3, 2021, 10:50 AM Russell O'Connor 
wrote:

> Hi Jermy,
>
> As you are aware, we, and by we I mean mostly Sanket, are developing an
> updated OP_CHECKSIGFROMSTACK implementation for tapscript on elements.  The
> plan here would be to effectively support the an interface to the
> variable-length extension of BIP-0340 schnorr signatures.
>
> BIP-0340 would dispense with DER encoding (good riddance).
> BIP-0340 signatures are batch verifiable along with other BIP-0340
> transaction signatures and taproot tweak verification.
> Support for variable length messages in BIP-0340 has been discussed in <
> https://github.com/sipa/bips/issues/207> and an implementation has
> recently been merged in <
> https://github.com/bitcoin-core/secp256k1/pull/844>.  The BIP has not yet
> been updated but the difference is that the message m does not have to be
> 32-bytes (it is recommended that the message be a 32-bit tagged hash or a
> message with a 64-bit application specific prefix). The CHECKSIGFROMSTACK
> operation (in tapscript) would use a stack item for this m value to
> BIP-0340 signature verification and would not necessarily have to be 32
> bytes.
>
> I think this design we are aiming for would be perfectly suited for
> Bitcoin as well.
>
> On Sat, Jul 3, 2021 at 12:32 PM Jeremy via bitcoin-dev <
> bitcoin-dev@lists.linuxfoundation.org> wrote:
>
>> Reproduced below is the BIP text from Bitcoin Cash's (MIT-Licensed)
>> specification for "CheckDataSig", more or less the same thing as
>> CHECKSIGFROMSTACK
>> https://github.com/bitcoincashorg/bitcoincash.org/blob/master/spec/op_checkdatasig.md.
>> In contrast to Element's implementation, it does not have Element's bugs
>> around verify semantics and uses the nullfail rule, and there is a
>> specification document so it seemed like the easiest starting point for
>> discussion v.s. drafting something from scratch.
>>
>> Does anyone have any issue with adapting this exact text and
>> implementation to a BIP for Bitcoin using 2 OP_SUCCESSX opcodes?
>>
>> Note that with *just* CheckSigFromStack, while you can do some very
>> valuable use cases, but without OP_CAT it does not enable sophisticated
>> covenants (and as per
>> https://www.wpsoftware.net/andrew/blog/cat-and-schnorr-tricks-i.html
>> just CAT alone enables such uses).
>>
>> Design questions worth considering as modifications:
>>
>> 1. Should CSFS require some sort of tagged hash? Very likely answer is no
>> – tags interfere with certain use cases
>> 2. Should CSFS split the signature’s R & S value stack items for some
>> applications that otherwise may require OP_CAT? E.g. using a pinned R value
>> allows you to extract a private key if ever double signed, using 2 R values
>> allows pay-to-reveal-key contracts. Most likely answer is no, if that is
>> desired then OP_CAT can be introduced
>> 3. Should CSFS support a cheap way to reference the taproot internal or
>> external key? Perhaps, can be handled with undefined upgradeable keytypes.
>> One might want to use the internal key, if the signed data should be valid
>> independent of the tapscript tree. One might want to use the external key,
>> if the data should only be valid for a single tapscript key + tree.
>> 4. Should invalid public keys types be a NOP to support future extended
>> pubkey types?
>>
>>
>>
>> Best,
>>
>>
>> Jeremy
>>
>>
>> ---
>> layout: specification
>> title: OP_CHECKDATASIG and OP_CHECKDATASIGVERIFY Specification
>> category: spec
>> date: 2018-08-20
>> activation: 154230
>> version: 0.6
>> ---
>>
>> OP_CHECKDATASIG
>> ===
>>
>> OP_CHECKDATASIG and OP_CHECKDATASIGVERIFY check whether a signature is valid 
>> with respect to a message and a public key.
>>
>> OP_CHECKDATASIG permits data to be imported into a script, and have its 
>> validity checked against some signing authority such as an "Oracle".
>>
>> OP_CHECKDATASIG and OP_CHECKDATASIGVERIFY are designed to be implemented 
>> similarly to OP_CHECKSIG [1]. Conceptually, one could imagine OP_CHECKSIG 
>> functionality being replaced by OP_CHECKDATASIG, along with a separate Op 
>> Code to create a hash from the transaction based on the SigHash algorithm.
>>
>> OP_CHECKDATASIG Specification
>> -
>>
>> ### Semantics
>>
>> OP_CHECKDATASIG fails immediately if the stack is not well formed. To be 
>> well formed, the stack must contain at least three elements [``, 
>> ``, ``] in this order where `` is the top element and
>>   * `` must be a validly encoded public key
>>   * `` can be any string
>>   * `` must follow the strict DER encoding as described in [2] and the 
>> S-value of `` must be at most the curve order divided by 2 as described 
>> in [3]
>>
>> If the stack is well formed

Re: [bitcoin-dev] CHECKSIGFROMSTACK/{Verify} BIP for Bitcoin

[Russell O'Connor via bitcoin-dev]

Hi Jermy,

As you are aware, we, and by we I mean mostly Sanket, are developing an
updated OP_CHECKSIGFROMSTACK implementation for tapscript on elements.  The
plan here would be to effectively support the an interface to the
variable-length extension of BIP-0340 schnorr signatures.

BIP-0340 would dispense with DER encoding (good riddance).
BIP-0340 signatures are batch verifiable along with other BIP-0340
transaction signatures and taproot tweak verification.
Support for variable length messages in BIP-0340 has been discussed in <
https://github.com/sipa/bips/issues/207> and an implementation has recently
been merged in .  The
BIP has not yet been updated but the difference is that the message m does
not have to be 32-bytes (it is recommended that the message be a 32-bit
tagged hash or a message with a 64-bit application specific prefix). The
CHECKSIGFROMSTACK operation (in tapscript) would use a stack item for this
m value to BIP-0340 signature verification and would not necessarily have
to be 32 bytes.

I think this design we are aiming for would be perfectly suited for Bitcoin
as well.

On Sat, Jul 3, 2021 at 12:32 PM Jeremy via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> Reproduced below is the BIP text from Bitcoin Cash's (MIT-Licensed)
> specification for "CheckDataSig", more or less the same thing as
> CHECKSIGFROMSTACK
> https://github.com/bitcoincashorg/bitcoincash.org/blob/master/spec/op_checkdatasig.md.
> In contrast to Element's implementation, it does not have Element's bugs
> around verify semantics and uses the nullfail rule, and there is a
> specification document so it seemed like the easiest starting point for
> discussion v.s. drafting something from scratch.
>
> Does anyone have any issue with adapting this exact text and
> implementation to a BIP for Bitcoin using 2 OP_SUCCESSX opcodes?
>
> Note that with *just* CheckSigFromStack, while you can do some very
> valuable use cases, but without OP_CAT it does not enable sophisticated
> covenants (and as per
> https://www.wpsoftware.net/andrew/blog/cat-and-schnorr-tricks-i.html just
> CAT alone enables such uses).
>
> Design questions worth considering as modifications:
>
> 1. Should CSFS require some sort of tagged hash? Very likely answer is no
> – tags interfere with certain use cases
> 2. Should CSFS split the signature’s R & S value stack items for some
> applications that otherwise may require OP_CAT? E.g. using a pinned R value
> allows you to extract a private key if ever double signed, using 2 R values
> allows pay-to-reveal-key contracts. Most likely answer is no, if that is
> desired then OP_CAT can be introduced
> 3. Should CSFS support a cheap way to reference the taproot internal or
> external key? Perhaps, can be handled with undefined upgradeable keytypes.
> One might want to use the internal key, if the signed data should be valid
> independent of the tapscript tree. One might want to use the external key,
> if the data should only be valid for a single tapscript key + tree.
> 4. Should invalid public keys types be a NOP to support future extended
> pubkey types?
>
>
>
> Best,
>
>
> Jeremy
>
>
> ---
> layout: specification
> title: OP_CHECKDATASIG and OP_CHECKDATASIGVERIFY Specification
> category: spec
> date: 2018-08-20
> activation: 154230
> version: 0.6
> ---
>
> OP_CHECKDATASIG
> ===
>
> OP_CHECKDATASIG and OP_CHECKDATASIGVERIFY check whether a signature is valid 
> with respect to a message and a public key.
>
> OP_CHECKDATASIG permits data to be imported into a script, and have its 
> validity checked against some signing authority such as an "Oracle".
>
> OP_CHECKDATASIG and OP_CHECKDATASIGVERIFY are designed to be implemented 
> similarly to OP_CHECKSIG [1]. Conceptually, one could imagine OP_CHECKSIG 
> functionality being replaced by OP_CHECKDATASIG, along with a separate Op 
> Code to create a hash from the transaction based on the SigHash algorithm.
>
> OP_CHECKDATASIG Specification
> -
>
> ### Semantics
>
> OP_CHECKDATASIG fails immediately if the stack is not well formed. To be well 
> formed, the stack must contain at least three elements [``, ``, 
> ``] in this order where `` is the top element and
>   * `` must be a validly encoded public key
>   * `` can be any string
>   * `` must follow the strict DER encoding as described in [2] and the 
> S-value of `` must be at most the curve order divided by 2 as described 
> in [3]
>
> If the stack is well formed, then OP_CHECKDATASIG pops the top three elements 
> [``, ``, ``] from the stack and pushes true onto the stack 
> if `` is valid with respect to the raw single-SHA256 hash of `` and 
> `` using the secp256k1 elliptic curve. Otherwise, it pops three 
> elements and pushes false onto the stack in the case that `` is the 
> empty string and fails in all other cases.
>
> Nullfail is enforced the same as for OP_CHECKSIG [3]. If the signature doe

[bitcoin-dev] CHECKSIGFROMSTACK/{Verify} BIP for Bitcoin

[Jeremy via bitcoin-dev]

Reproduced below is the BIP text from Bitcoin Cash's (MIT-Licensed)
specification for "CheckDataSig", more or less the same thing as
CHECKSIGFROMSTACK
https://github.com/bitcoincashorg/bitcoincash.org/blob/master/spec/op_checkdatasig.md.
In contrast to Element's implementation, it does not have Element's bugs
around verify semantics and uses the nullfail rule, and there is a
specification document so it seemed like the easiest starting point for
discussion v.s. drafting something from scratch.

Does anyone have any issue with adapting this exact text and implementation
to a BIP for Bitcoin using 2 OP_SUCCESSX opcodes?

Note that with *just* CheckSigFromStack, while you can do some very
valuable use cases, but without OP_CAT it does not enable sophisticated
covenants (and as per
https://www.wpsoftware.net/andrew/blog/cat-and-schnorr-tricks-i.html just
CAT alone enables such uses).

Design questions worth considering as modifications:

1. Should CSFS require some sort of tagged hash? Very likely answer is no –
tags interfere with certain use cases
2. Should CSFS split the signature’s R & S value stack items for some
applications that otherwise may require OP_CAT? E.g. using a pinned R value
allows you to extract a private key if ever double signed, using 2 R values
allows pay-to-reveal-key contracts. Most likely answer is no, if that is
desired then OP_CAT can be introduced
3. Should CSFS support a cheap way to reference the taproot internal or
external key? Perhaps, can be handled with undefined upgradeable keytypes.
One might want to use the internal key, if the signed data should be valid
independent of the tapscript tree. One might want to use the external key,
if the data should only be valid for a single tapscript key + tree.
4. Should invalid public keys types be a NOP to support future extended
pubkey types?



Best,


Jeremy


---
layout: specification
title: OP_CHECKDATASIG and OP_CHECKDATASIGVERIFY Specification
category: spec
date: 2018-08-20
activation: 154230
version: 0.6
---

OP_CHECKDATASIG
===

OP_CHECKDATASIG and OP_CHECKDATASIGVERIFY check whether a signature is
valid with respect to a message and a public key.

OP_CHECKDATASIG permits data to be imported into a script, and have
its validity checked against some signing authority such as an
"Oracle".

OP_CHECKDATASIG and OP_CHECKDATASIGVERIFY are designed to be
implemented similarly to OP_CHECKSIG [1]. Conceptually, one could
imagine OP_CHECKSIG functionality being replaced by OP_CHECKDATASIG,
along with a separate Op Code to create a hash from the transaction
based on the SigHash algorithm.

OP_CHECKDATASIG Specification
-

### Semantics

OP_CHECKDATASIG fails immediately if the stack is not well formed. To
be well formed, the stack must contain at least three elements
[``, ``, ``] in this order where `` is the
top element and
  * `` must be a validly encoded public key
  * `` can be any string
  * `` must follow the strict DER encoding as described in [2]
and the S-value of `` must be at most the curve order divided by
2 as described in [3]

If the stack is well formed, then OP_CHECKDATASIG pops the top three
elements [``, ``, ``] from the stack and pushes true
onto the stack if `` is valid with respect to the raw
single-SHA256 hash of `` and `` using the secp256k1
elliptic curve. Otherwise, it pops three elements and pushes false
onto the stack in the case that `` is the empty string and fails
in all other cases.

Nullfail is enforced the same as for OP_CHECKSIG [3]. If the signature
does not match the supplied public key and message hash, and the
signature is not an empty byte array, the entire script fails.

### Opcode Number

OP_CHECKDATASIG uses the previously unused opcode number 186 (0xba in
hex encoding)

### SigOps

Signature operations accounting for OP_CHECKDATASIG shall be
calculated the same as OP_CHECKSIG. This means that each
OP_CHECKDATASIG shall be counted as one (1) SigOp.

### Activation

Use of OP_CHECKDATASIG, unless occuring in an unexecuted OP_IF branch,
will make the transaction invalid if it is included in a block where
the median timestamp of the prior 11 blocks is less than 154230.

### Unit Tests

 - `   OP_CHECKDATASIG` fails if 15 November 2018
protocol upgrade is not yet activated.
 - `  OP_CHECKDATASIG` fails if there are fewer than 3 items on stack.
 - `   OP_CHECKDATASIG` fails if `` is not a
validly encoded public key.
 - `   OP_CHECKDATASIG` fails if `` is not a
validly encoded signature with strict DER encoding.
 - `   OP_CHECKDATASIG` fails if signature ``
is not empty and does not pass the Low S check.
 - `   OP_CHECKDATASIG` fails if signature ``
is not empty and does not pass signature validation of `` and
``.
 - `   OP_CHECKDATASIG` pops three elements and
pushes false onto the stack if `` is an empty byte array.
 - `   OP_CHECKDATASIG` pops three elements and
pushes true onto the stack if `` is a valid signature of ``
with respect to ``.

OP_CHECKD

Re: [bitcoin-dev] BIP Proposals for Output Script Descriptors

[Craig Raw via bitcoin-dev]

It's a consideration, not a serious concern.

When I made the point around alphanumeric characters being similar to the
path numbers, I was actually thinking of the output descriptor appearing in
a fixed character width font, which I prefer as more appropriate for
displaying hexidecimal values. In this case, the apostrophe provides more
whitespace which makes the path easier to parse visually. It's difficult to
reduce this to a mathematical argument, as is true for many UX
considerations. Your example in fixed width here:
https://gist.github.com/craigraw/fc98b9031a7e01e1bc5d75a77bdb72e5

That said you make good arguments around the shell quoting and stamps for
metal backups, and therefore I agree it is preferable to use the lowercase
"h". Thanks for the detailed reply.

Craig

On Sat, Jul 3, 2021 at 12:11 PM David A. Harding  wrote:

> On Sat, Jul 03, 2021 at 10:35:48AM +0200, Craig Raw wrote:
> > There is a downside to using "h"/"H" from a UX perspective - taking up
> more
> > space
>
> Is this a serious concern of yours?  An apostrophe is 1/2 en; an "h" is
> 1 en; the following descriptor contains three hardened derivations in 149
> characters; assuming the average non-'/h character width is 1.5 en, the
> difference between 207 en and 208.5 en is barely more than half a
> percent.
>
>
> pkh([d34db33f/44h/0h/0h]xpub6ERApfZwUNrhLCkDtcHTcxd75RbzS1ed54G1LkBUHQVHQKqhMkhgbmJbZRkrgZw4koxb5JaHWkY4ALHY2grBGRjaDMzQLcgJvLJuZZvRcEL/1/*)#ml40v0wf
>
> Here's a direct visual comparison:
> https://gist.github.com/harding/2fbbf2bfdce04c3e4110082f03ae3c80
>
> > appearing as alphanumeric characters similar to the path numbers
>
> First, I think you'd have to be using an awful font to confuse "h" with
> any arabic numeral.  Second, avoiding transcription errors is exactly
> why descriptors now have checksums.
>
> > they make derivation paths and descriptors more difficult to read.
>
> The example descriptor pasted above looks equally (un)readable to me
> whether it uses ' or h.
>
> > Also, although not as important, less efficient when making metal
> > backups.
>
> I think many metal backup schemes are using stamps or punch grids that
> are fixed-width in nature, so there's no difference either way.  (And
> you can argue that h is better since it's part of both the base58check
> and bech32 character sets, so you already need a stamp or a grid row for
> it---but ' is otherwise unused, so a stamp or grid row for it would be
> special).
>
> But even if people are manually etching descriptors into metal, we're
> back to the original point where we're looking at something like a 0.7%
> difference in "efficiency".
>
> By comparison, the Bitcoin Core issue I cited in my earlier post
> contains several examples of actual users needing technical support
> because they tried to use '-containing descriptors in a bourne-style
> shell.  (And I've personally lost time to that class of problems.)  In
> the worst case, a shell-quoting accident can cause loss of money by
> sending bitcoins to the descriptor for a key your hardware signing
> device won't sign for.  I think these problems are much more serious
> than using a tiny bit of extra space in a GUI or on a physical backup
> medium.
>
> -Dave
>
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] CheckSigFromStack for Arithmetic Values

[Erik Aronesty via bitcoin-dev]

i may be ignorant here but i have a question:

Given that schnorr signatures now allow signers to perform complex
arithmetic signing operations out-of-band using their own communications
techniques, couldn't you just perform the publishing and accumulation of
these signature components without using a bitcoin script?

In other words, push the effort of combination and computation off of the
bitcoin network and nodes.


On Sat, Jul 3, 2021 at 12:01 AM Jeremy via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> Yep -- sorry for the confusing notation but seems like you got it. C++
> templates have this issue too btw :)
>
> One cool thing is that if you have op_add for arbitrary width integers or
> op_cat you can also make a quantum proof signature by signing the signature
> made with checksig with the lamport.
>
> There are a couple gotchas wrt crypto assumptions on that but I'll write
> it up soon 🙂 it also works better in segwit V0 because there's no keypath
> spend -- that breaks the quantum proofness of this scheme.
>
> On Fri, Jul 2, 2021, 4:58 PM ZmnSCPxj  wrote:
>
>> Good morning Jeremy,
>>
>> > Dear Bitcoin Devs,
>> >
>> > It recently occurred to me that it's possible to do a lamport signature
>> in script for arithmetic values by using a binary expanded representation.
>> There are some applications that might benefit from this and I don't recall
>> seeing it discussed elsewhere, but would be happy for a citation/reference
>> to the technique.
>> >
>> > blog post here, https://rubin.io/blog/2021/07/02/signing-5-bytes/,
>> text reproduced below
>> >
>> > There are two insights in this post:
>> > 1. to use a bitwise expansion of the number
>> > 2. to use a lamport signature
>> > Let's look at the code in python and then translate to bitcoin script:
>> > ```python
>> > def add_bit(idx, preimage, image_0, image_1):
>> > s = sha256(preimage)
>> > if s == image_1:
>> > return (1 << idx)
>> > if s == image_0:
>> > return 0
>> > else:
>> > assert False
>> > def get_signed_number(witnesses : List[Hash], keys : List[Tuple[Hash,
>> Hash]]):
>> > acc = 0
>> > for (idx, preimage) in enumerate(witnesses):
>> > acc += add_bit(idx, preimage, keys[idx][0], keys[idx][1])
>> > return x
>> > ```
>> > So what's going on here? The signer generates a key which is a list of
>> pairs of
>> > hash images to create the script.
>> > To sign, the signer provides a witness of a list of preimages that
>> match one or the other.
>> > During validation, the network adds up a weighted value per preimage
>> and checks
>> > that there are no left out values.
>> > Let's imagine a concrete use case: I want a third party to post-hoc
>> sign a sequence lock. This is 16 bits.
>> > I can form the following script:
>> > ```
>> >  checksigverify
>> > 0
>> > SWAP sha256 DUP  EQUAL IF DROP <1> ADD ELSE 
>> EQUALVERIFY ENDIF
>> > SWAP sha256 DUP  EQUAL IF DROP <1<<1> ADD ELSE 
>> EQUALVERIFY ENDIF
>> > SWAP sha256 DUP  EQUAL IF DROP <1<<2> ADD ELSE 
>> EQUALVERIFY ENDIF
>> > SWAP sha256 DUP  EQUAL IF DROP <1<<3> ADD ELSE 
>> EQUALVERIFY ENDIF
>> > SWAP sha256 DUP  EQUAL IF DROP <1<<4> ADD ELSE 
>> EQUALVERIFY ENDIF
>> > SWAP sha256 DUP  EQUAL IF DROP <1<<5> ADD ELSE 
>> EQUALVERIFY ENDIF
>> > SWAP sha256 DUP  EQUAL IF DROP <1<<6> ADD ELSE 
>> EQUALVERIFY ENDIF
>> > SWAP sha256 DUP  EQUAL IF DROP <1<<7> ADD ELSE 
>> EQUALVERIFY ENDIF
>> > SWAP sha256 DUP  EQUAL IF DROP <1<<8> ADD ELSE 
>> EQUALVERIFY ENDIF
>> > SWAP sha256 DUP  EQUAL IF DROP <1<<9> ADD ELSE 
>> EQUALVERIFY ENDIF
>> > SWAP sha256 DUP  EQUAL IF DROP <1<<10> ADD ELSE 
>> EQUALVERIFY ENDIF
>> > SWAP sha256 DUP  EQUAL IF DROP <1<<11> ADD ELSE 
>> EQUALVERIFY ENDIF
>> > SWAP sha256 DUP  EQUAL IF DROP <1<<12> ADD ELSE 
>> EQUALVERIFY ENDIF
>> > SWAP sha256 DUP  EQUAL IF DROP <1<<13> ADD ELSE 
>> EQUALVERIFY ENDIF
>> > SWAP sha256 DUP  EQUAL IF DROP <1<<14> ADD ELSE 
>> EQUALVERIFY ENDIF
>> > SWAP sha256 DUP  EQUAL IF DROP <1<<15> ADD ELSE 
>> EQUALVERIFY ENDIF
>> > CHECKSEQUENCEVERIFY
>> > ```
>>
>> This took a bit of thinking to understand, mostly because you use the
>> `<<` operator in a syntax that uses `< >` as delimiters, which was mildly
>> confusing --- at first I thought you were pushing some kind of nested
>> SCRIPT representation, but in any case, replacing it with the actual
>> numbers is a little less confusing on the syntax front, and I think (hope?)
>> most people who can understand `1<<1` have also memorized the first few
>> powers of 2
>>
>> > ```
>> >  checksigverify
>> > 0
>> > SWAP sha256 DUP  EQUAL IF DROP <1> ADD ELSE 
>> EQUALVERIFY ENDIF
>> > SWAP sha256 DUP  EQUAL IF DROP <2> ADD ELSE 
>> EQUALVERIFY ENDIF
>> > SWAP sha256 DUP  EQUAL IF DROP <4> ADD ELSE 
>> EQUALVERIFY ENDIF
>> > SWAP sha256 DUP  EQUAL IF DROP <8> ADD ELSE 
>> EQUALVERIFY ENDIF
>> > SWAP sha256 DUP  EQUAL IF DROP <16> ADD ELSE 
>> EQUALVERIFY ENDIF
>> > SWAP sha256 DUP  EQUAL IF DROP <32> ADD ELSE 
>> EQUALVERIFY ENDIF

Re: [bitcoin-dev] BIP Proposals for Output Script Descriptors

[Craig Raw via bitcoin-dev]

There is a downside to using "h"/"H" from a UX perspective - taking up more
space and appearing as alphanumeric characters similar to the path numbers,
they make derivation paths and descriptors more difficult to read. Also,
although not as important, less efficient when making metal backups.

On Sat, Jul 3, 2021 at 7:13 AM Andrew Chow via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> On 7/2/21 11:24 PM, David A. Harding wrote:
> > Is there any chance we can take this opportunity to make "h"/"H" the
> > preferred aliases?  Using "'" in bourne-style shells is very
> > annoying[1], and I suspect it's also creating unnecessary complications
> > elsewhere.
> I've updated the text to use "h".
> > Alternatives:
> >
> > - Completely kill "'" (I'd prefer this, but I realize it's complicated
> >with descriptors already being used widely).  If "h"/"H" are made the
> >preferred aliases, maybe it'd be enough to make implementing "'" a
> >SHOULD rather than a MUST; this would push implementations towards
> >displaying descriptors using the h versions for maximum compatibility.
> Since there already are software implementing descriptors, I don't think
> we can do this. I'm not sure about making "'" a SHOULD either.
> > - Calculate the checksum over s/(h|H)/'/ (again, I know that's
> >complicated with descriptors already widely used)
> This has been discussed in the past and the conclusion was that the
> checksum should be strictly over the string itself. This would allow for
> dumb checksum checkers which don't have to be able to parse descriptors
> in order to check the checksum.
>
> Thanks,
> Andrew
>
> >
> > Thanks,
> >
> > -Dave
> >
> > [1]
> https://github.com/bitcoin/bitcoin/issues/15740#issuecomment-695815432
>
>
> ___
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] BIP Proposals for Output Script Descriptors

[David A. Harding via bitcoin-dev]

On Sat, Jul 03, 2021 at 10:35:48AM +0200, Craig Raw wrote:
> There is a downside to using "h"/"H" from a UX perspective - taking up more
> space 

Is this a serious concern of yours?  An apostrophe is 1/2 en; an "h" is
1 en; the following descriptor contains three hardened derivations in 149
characters; assuming the average non-'/h character width is 1.5 en, the
difference between 207 en and 208.5 en is barely more than half a
percent.


pkh([d34db33f/44h/0h/0h]xpub6ERApfZwUNrhLCkDtcHTcxd75RbzS1ed54G1LkBUHQVHQKqhMkhgbmJbZRkrgZw4koxb5JaHWkY4ALHY2grBGRjaDMzQLcgJvLJuZZvRcEL/1/*)#ml40v0wf

Here's a direct visual comparison: 
https://gist.github.com/harding/2fbbf2bfdce04c3e4110082f03ae3c80

> appearing as alphanumeric characters similar to the path numbers

First, I think you'd have to be using an awful font to confuse "h" with
any arabic numeral.  Second, avoiding transcription errors is exactly
why descriptors now have checksums.

> they make derivation paths and descriptors more difficult to read.

The example descriptor pasted above looks equally (un)readable to me
whether it uses ' or h.

> Also, although not as important, less efficient when making metal
> backups.

I think many metal backup schemes are using stamps or punch grids that
are fixed-width in nature, so there's no difference either way.  (And
you can argue that h is better since it's part of both the base58check
and bech32 character sets, so you already need a stamp or a grid row for
it---but ' is otherwise unused, so a stamp or grid row for it would be
special).

But even if people are manually etching descriptors into metal, we're
back to the original point where we're looking at something like a 0.7%
difference in "efficiency".

By comparison, the Bitcoin Core issue I cited in my earlier post
contains several examples of actual users needing technical support
because they tried to use '-containing descriptors in a bourne-style
shell.  (And I've personally lost time to that class of problems.)  In
the worst case, a shell-quoting accident can cause loss of money by
sending bitcoins to the descriptor for a key your hardware signing
device won't sign for.  I think these problems are much more serious
than using a tiny bit of extra space in a GUI or on a physical backup
medium.

-Dave


signature.asc
Description: PGP signature
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Boost Bitcoin circulation, Million Transactions Per Second with stronger privacy

[raymo via bitcoin-dev]

Hi Billy,

> What if it was possible for the creditor to claw back the funds
As far as I know the “claw back” mechanism doesn’t exist in Bitcoin
system, and probably most Bitcoiners won’t be agree on it. 
Even if we want to add claw back to Bitcoin in general, and Sabu in
particular, it would add too complexities and uncertainty to Bitcoin. 
So, it would be better to not touch that part, instead focusing on
reduce the cheating risk by putting some penalty for both issuers,
creditors and miners. 
We already have the penalties for both issuers and creditors. 
It looks the miners still can abuse Sabu, but as I told before the miner
or better say the mining pool must be issuer (to be able to sign the
promised UTXO in cheating way) or must be creditor (in order to have a
copy of GT and not lose his money in favor of a stranger miner. Remember
the fact that creditor will lose 70% of their money in favor of Bitcoin
transaction fee in a typical GT) or collaborate one of them in a
conspiracy. Otherwise, there will be no economic benefit in this attack.
 
All these 3 cases of the attacks, theoretically could be happened, but
the risk to reward ratio is enough high to hinder potential malevolent
from a practical act.
Even this very small risk of miner attacks (which don’t care the attack
costs, since he is not interested in economic benefit, but he wants to
ruin Sabu), would be resolved by a slightly upgrade in Bitcoin protocol
by applying the BIPxxx “for flagging/unflagging promised UTXOs”. 
I am not in rush to apply this upgrade on Bitcoin protocol, instead I am
actively working in order to realize the Sabu protocol and Gazin wallet.
Later the Sabu community will carry the BIPxxx.

Best

On 2021-07-02 17:57, Billy Tetrud wrote:
> Thanks for the details Raymo. A thought occurred to me. Given the fact
> that miners can abuse this system without penalty, it would be useful
> to be able to fix this. What if it was possible for the creditor to
> claw back the funds even if the cheating transaction was mined instead
> of the guarantee transaction? Let's say there was a way to sign a
> transaction that gives the receiver of that transaction the ability to
> override any other transaction that uses the UTXO? If this were
> possible, the issuer could give the creditor this kind of transaction
> as the guarantee transaction, and in the case a cheat was done, the
> creditor could still use the GT to reallocate that UTXO to themselves.
> 
> Now there are issues with this. First of all, it could give anyone the
> ability to double spend. So it would be prudent to limit this in some
> way. The revocation probably should only be valid for up to 6 blocks,
> such that if the transaction has 6 confirmations, it can no longer be
> reallocated (thus preserving the 6 block finality rule). It could also
> be required that the UTXO be marked as opting into this behavior (so
> receivers would know about the possibility it could get revoked). This
> second requirement would require Sabu issuers to make an on-chain
> transaction to set themselves up as an issuer. 
> 
> Another issue is that this would make it possible for transactions to
> expire. Any claw-back transaction would expire 6 blocks after the
> initial transaction happened. This has been generally avoided in
> bitcoin, but I think the relevant issues are solvable. You can find
> additional discussion of that in this thread [1].
> 
> I would imagine this kind of ability would be pretty controversial,
> but since it can close out the possibility for miners to escape
> punishment, it could make this protocol viable. 
> 
> On Thu, Jul 1, 2021 at 3:15 PM  wrote:
> 
>> Hi Erik
>>
>> Please correct me if I misunderstood.
>>
>>> email is fully compromised.
>>
>> What I got is:
>> Email is not good because the sender and receiver are compromised.
>> Email is not good because the message content is revealed.
>> I can claim same argue about any other client/server model. Since
>> the
>> server (website) service provider will ask some sort of KYC. And
>> even if
>> the server uses end-to-end encryption, the provider company still
>> can
>> read the packets content.
>> In my model the passive listener only can discover who is
>> communicate to
>> whom and make a graph of connections. Although it is a threat for
>> privacy but the server/client model has this flaw inherently, since
>> provider already knew everything about everyone. In my model at
>> least
>> users can make some fake connections and send some fake emails in
>> order
>> to inject noise to communications.
>> Please note the fact that entire communication between mobile
>> wallets
>> (via emails) are asymmetric PGP encrypted. The PGP keys are
>> controlled
>> by end users unlike ALL pretending secure messengers (e.g whatsApp,
>> signal, zoom,…).
>> If you are worried about the way of exchanging PGP public key, you
>> are
>> right. The most secure way is in-person PGP key exchanging.
>> After that for payments the wallets communi

[bitcoin-dev] Templates, Eltoo, and Covenants, Oh My!

[Jeremy via bitcoin-dev]

Dear Bitcoin Devs,

I recently put a blog post up which is of interest for this list. Post
available here: https://rubin.io/blog/2021/07/02/covenants/ (text
reproduced below for archives).

The main technical points of interest for this list are:

1) There's a similar protocol to Eltoo built with CSFS + CTV
2) There may be a similar protocol to Eltoo with exclusively CSFS

I'm curious if there's any sentiment around if a soft fork enabling CSFS is
controversial? Or if there are any thoughts on the design questions posed
below (e.g., splitting r and s value).

Best,

Jeremy



If you've been following The Discourse, you probably know that Taproot is
merged, locked in, and will activate later this November. What you might not
know is what's coming next... and you wouldn't be alone in that. There are a
number of fantastic proposals floating around to further improve Bitcoin,
but
there's no clear picture on what is ready to be added next and on what
timeline. No one -- core developer, technically enlightened individuals,
power
users, or plebs -- can claim to know otherwise.


In this post I'm going to describe 4 loosely related possible upgrades to
Bitcoin -- SH_APO (BIP-118), OP_CAT, OP_CSFS, and OP_CTV (BIP-119). These
four
upgrades all relate to how the next generation of stateful smart contracts
can
be built on top of bitcoin. As such, there's natural overlap -- and
competition
-- for mindshare for review and deployment. This post is my attempt to
stitch
together a path we might take to roll them out and why that ordering makes
sense. This post is for developers and engineers building in the Bitcoin
space,
but is intended to be followable by anyone technical or not who has a keen
interest in Bitcoin.


## Bitcoin Eschews Roadmaps and Agendas.


I provide this maxim to make clear that this document is by no means an
official roadmap, narrative, or prioritization. However, it is my own
assessment of what the current most pragmatic approach to upgrading Bitcoin
is,
based on my understanding of the state of outstanding proposals and their
interactions.


My priorities in producing this are to open a discussion on potential new
features, risk minimization, and pragmatic design for Bitcoin.


### Upgrade Summaries


Below follows summaries of what each upgrade would enable and how it works.
You
might be tempted to skip it if you're already familiar with the upgrades,
but I
recommend reading in any case as there are a few non obvious insights.


 APO: SIGHASH_ANYPREVOUT, SIGHASH_ANYPREVOUTANYSCRIPT


Currently proposed as
[BIP-118](
https://github.com/bitcoin/bips/blob/d616d5492bc6e6566af1b9f9e43b660bcd48ca29/bip-0118.mediawiki).



APO provides two new signature digest algorithms that do not commit to the
coin
being spent, or the current script additionally. Essentially allowing
scripts
to use outputs that didn’t exist at the time the script was made. This
would be
a new promise enforced by Bitcoin (ex. “You can close this Lightning channel
and receive these coins if you give me the right proof. If a newer proof
comes
in later I’ll trust that one instead.”).


APO’s primary purpose is to enable off chain protocols like
[Eltoo](https://blockstream.com/2018/04/30/en-eltoo-next-lightning/), an
improved non-punitive payment channel protocol.


APO can also
[emulate](
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2019-June/017038.html
)
some of the main features of CTV and could be made to work with Sapio,
partially. See the complimentary upgrades section for more detail.


 CAT (+ variants)


Currently no BIP. However, CAT exists in
[Elements](
https://github.com/ElementsProject/elements/blob/bd2e2d5c64d38286b2ca0519f1215bed228e4dcf/src/script/interpreter.cpp#L914-L933
)
and [Bitcoin
Cash](
https://github.com/bitcoincashorg/bitcoincash.org/blob/3e2e6da8c38dab7ba12149d327bc4b259aaad684/spec/may-2018-reenabled-opcodes.md
)
as a 520 byte limited form, so a proposal for Bitcoin can crib heavily from
either.


Cat enables appending data onto other pieces of data. Diabolically simple
functionality that has many advanced use cases by itself and in concert with
other opcodes. There are many "straightforward" use cases of cat like
requiring
sighash types, requiring specific R values, etc, but there are too many
devious
use cases to list here.  Andrew Poelstra has a decent blogpost series ([part
1](https://www.wpsoftware.net/andrew/blog/cat-and-schnorr-tricks-i.html) and
[part
ii](https://www.wpsoftware.net/andrew/blog/cat-and-schnorr-tricks-ii.html))
if
you're interested to read more. In particular, with much cleverness, it
seems
possible one could implement full covenants with just CAT, which covers
(inefficiently) most of the other techniques discussed in this post.


 CSFS: CHECKSIGFROMSTACK


Curren