AOPP 2.0 using OP_CAT and OP_CSFS

2 messages, 1 Jun 2024. Started by /dev /fd0.

/dev /fd0, Ethan Heilman

/dev /fd0 1 Jun 2024, 02:27 UTC permalink original

Hi Bitcoin Developers,

I have been following the conversation in BIP 322 thread: https://groups.google.com/g/bitcoindev/c/RCi1Exs0ZvQ/m/vp6Xo36aBwAJ and did some research about all the undesirable things we can do with proposed opcodes.

I think its possible to create a worse protocol in which withdrawal is done to a personally identifying string. It can only be claimed by the user if they generate a public key and get it certified by an identity verifier.

```
(pushes from scriptsig:  certsig, bpubkey, txsig, 0)
IF                      (certsig, bpubkey, txsig)
  <recovery_pubkey>     -skip-
  CHECKSIGVERIFY        -skip-
  <recovery_time>       -skip-
  CHECKLOCKTIMEVERIFY   -skip-
ELSE
  OVER                  (certsig, bpubkey, txsig, bpubkey)
  CHECKSIGVERIFY        (certsig, bpubkey,)
  SHA256                (certsig, SHA256(bpubkey),)
  <id>                  (certsig, SHA256(bpubkey), id)
  CAT                   (certsig, SHA256(bpubkey)|id)
  <tpubkey>             (certsig, SHA256(bpubkey)|id, tpubkey)
  CHECKDATASIG          (1)
ENDIF
```

CHECKDATASIG would be replaced by CHECKSIGFROMSTACK if testing on signet.

Here's the link to read more about it: https://gist.github.com/markblundeberg/bd28871548108fc66d958018b1bde085

/dev/fd0 floppy disk guy

Ethan Heilman 1 Jun 2024, 12:34 UTC in reply to /dev /fd0 permalink original

It seems like you could do this today, no new opcodes, if you made the pubkey identity check interactive rather than purely on-chain.

I'd imagine anyone building such a system would want to make it interactive so they could revoke leaked keys and have an expiration mechanism.

On Fri, May 31, 2024, 10:29 PM /dev /fd0 <alicexbtong@gmail•com> wrote:

Quoted text (47 lines)

> Hi Bitcoin Developers,
>
> I have been following the conversation in BIP 322 thread:
> https://groups.google.com/g/bitcoindev/c/RCi1Exs0ZvQ/m/vp6Xo36aBwAJ and
> did some research about all the undesirable things we can do with proposed
> opcodes.
>
> I think its possible to create a worse protocol in which withdrawal is
> done to a personally identifying string. It can only be claimed by the user
> if they generate a public key and get it certified by an identity verifier.
>
> ```
> (pushes from scriptsig:  certsig, bpubkey, txsig, 0)
> IF                      (certsig, bpubkey, txsig)
>   <recovery_pubkey>     -skip-
>   CHECKSIGVERIFY        -skip-
>   <recovery_time>       -skip-
>   CHECKLOCKTIMEVERIFY   -skip-
> ELSE
>   OVER                  (certsig, bpubkey, txsig, bpubkey)
>   CHECKSIGVERIFY        (certsig, bpubkey,)
>   SHA256                (certsig, SHA256(bpubkey),)
>   <id>                  (certsig, SHA256(bpubkey), id)
>   CAT                   (certsig, SHA256(bpubkey)|id)
>   <tpubkey>             (certsig, SHA256(bpubkey)|id, tpubkey)
>   CHECKDATASIG          (1)
> ENDIF
> ```
>
> CHECKDATASIG would be replaced by CHECKSIGFROMSTACK if testing on signet.
>
> Here's the link to read more about it:
> https://gist.github.com/markblundeberg/bd28871548108fc66d958018b1bde085
>
> /dev/fd0
> floppy disk guy
>
> --
> You received this message because you are subscribed to the Google Groups
> "Bitcoin Development Mailing List" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to bitcoindev+unsubscribe@googlegroups•com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/bitcoindev/439a982d-d9c1-4749-bcb6-59cc30add099n%40googlegroups.com
> <https://groups.google.com/d/msgid/bitcoindev/439a982d-d9c1-4749-bcb6-59cc30add099n%40googlegroups.com?utm_medium=email&utm_source=footer>
> .
>