New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Remove reliance on OP_DATASIGVERIFY and simplify assert scripts #6

recursivesmelting opened this Issue Aug 11, 2018 · 6 comments


None yet
5 participants

recursivesmelting commented Aug 11, 2018

The original assert script was designed to accommodate features given in early development. The design is no longer required.

Proposal: We change assert scripts to
A = <token id, quantity> OP_EQUALVERIFY Y
and revoke scripts to
R = X <token id, quantity>
where X and Y are any traditional signature/pubkey script. (This subsumes flexible assert script functionality and hence we remove them).

A token-p2pkh would then be
A = <token id, quantity> OP_EQUALVERIFY p2pkh(Bob addr) and revoke script be R = <sig> <addr> <token id, quantity>.

This would allow recursive smelting to have more tight overlay the traditional bitcoin transactions and simplify the parsing of outputs (in turn simplifying proofs).


This comment has been minimized.


recursivesmelting commented Aug 11, 2018

In addition this should allow easier integration with existing wallets. Wallets can function as is with the only change being that the quantity is queried from the token "quantity" in output script rather than the transaction "quantity" in the transaction output itself.


This comment has been minimized.

2ndEntropy commented Aug 11, 2018

Great work!!

Looking forward to seeing this progress and the comments that follow this change.


This comment has been minimized.


digitsu commented Aug 11, 2018

This is great news, and great progress.
I knew that somehow this must be do-able without adding new OP_CODES.


This comment has been minimized.

xmodulus commented Aug 11, 2018

Is there an implementation in the works yet?


This comment has been minimized.


recursivesmelting commented Aug 11, 2018

Yep. So most of the implementation should be relatively easy - the token transactions are simply Bitcoin transactions with an extra condition supplemented to the pubkey/script signatures (see OP). Therefore most of the infrastructure for this already exists in wallets today!

The key ingredient is creating the backend to generate and verify proofs used in RS. And this is what we're hard at work at currently. We aim to create a library to do this which existing wallets can interface with easily and add token support with very little change to existing code.

The aim is to fork an existing wallet, write up a reference interface with the proof library and then let other wallets replicate it if they please.

Luckily great open-source libraries already exist from generating and verifying proofs:
is such an example and a fork of it is used in zcash. We are starting to prototype proofs using a front-end for libsnark called Snarky (created by the geniuses at O(1) labs)
Snarky provides a way of translating high-level programming languages into the low level R1CS which libsnark uses to generate proofs. This brings with it all the security benefits of using a functional language.

We are in the very early stages - producing candidate OCaml scripts at the moment and brainstorming. We hope to get a repository containing at least some rough drafts in the upcoming weeks. We are optimistic but realise that this first hurdle is the highest.


This comment has been minimized.

tbrannt commented Aug 11, 2018

For me this is the best thing that happend in the Bitcoin Cash space over the last months. If I get this right this is the perfect token proposal. Superior to everything we've heard so far.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment