>
> Responding below
The core idea is to modify Tapscript's `OP_CHECKSIG`. Instead of reading the
> signature as a single 64-bytes stack argument, let's add a small change to
> read
> the signature as two 32-bytes stack arguments: `R` first then `s`.
> Since Taproot already makes changes to this
From where I'm sitting the fact that OP_CAT allows people to build
more powerful constructions in Bitcoin without introducing additional
complexity at the consensus layer is a positive not a negative. Using
OP_CAT or OP_SUBSTRING to enforce ECDSA nonce reuse is a very powerful
protocol tool for
I hope you are having an great afternoon ZmnSCPxj,
You make an excellent point!
I had thought about doing the following to tag nodes
|| means OP_CAT
`node = SHA256(type||SHA256(data))`
so a subnode would be
`subnode1 = SHA256(1||SHA256(subnode2||subnode3))`
and a leaf node would be
`leafnode =
To avoid derailing the NO_INPUT conversation, I have changed the
subject to OP_CAT.
Responding to:
"""
* `SIGHASH` flags attached to signatures are a misdesign, sadly
retained from the original BitCoin 0.1.0 Alpha for Windows design, on
par with:
[..]
* `OP_CAT` and `OP_MULT` and `OP_ADD` and
>I don't find too compelling the potential problem of a 'bad wallet designer',
>whether lazy or dogmatic, misusing noinput. I think there are simpler ways to
>cut corners and there will always be plenty of good wallet options people can
>choose.
I want to second this. The most expensive part
