AOPP 2.0 using OP_CAT and OP_CSFS

AOPP 2.0 using OP_CAT and OP_CSFS
2024-06-01 12:34 ` Ethan Heilman
  
From: /dev /fd0 @ 2024-06-01  2:27 UTC (permalink / raw)
  To: Bitcoin Development Mailing List


[-- Attachment #1.1: Type: text/plain, Size: 1673 bytes --]

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

-- 
2: Type: text/html, Size: 2465 bytes --]

 permalink raw reply	[|nested]
2024-06-01  2:27 [bitcoindev] AOPP 2.0 using OP_CAT and OP_CSFS /dev /fd0

  
From: Ethan Heilman @ 2024-06-01 12:34 UTC (permalink / raw)
  To: /dev /fd0;  Bitcoin Development Mailing List

[-- Attachment #1: Type: text/plain, Size: 2649 bytes --]

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:

> 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>
> .
>

-- 


[-- Attachment #2: Type: text/html, Size: 3897 bytes --]

 permalink raw reply	[|nested]