Draft Proposal - OP_CHECKGROTH16VERIFY: An ultra-lightweight, soft-forkable solution to trustlessly scale and add smart contract-like functionality to Dogecoin #3614

cf · 2024-07-29T17:17:07Z

cf
Jul 29, 2024

Note:
Over the past few months, we have been working on a proposal to an op code to Dogecoin which can verify zero knowledge proofs on Dogecoin. In addition to the proposal, we have wrote working fork of Dogecoin that implements and an end-to-end zk rollup that showcases in practice how a zkRollup could be used to scale Dogecoin.

We hope to gather feedback from the broader community to improve the proposal, with the ultimate goal of delivering new value to Dogecoin users without increasing the barrier of entry to running a full node.

OP_CHECKGROTH16VERIFY

An ultra-lightweight, soft-forkable solution to trustlessly scale and add smart contract-like functionality to Dogecoin

Highlights:

Allows for building complex applications like decentralized exchanges and smart contracts on Doge
Allows Doge to be trustlessly scaled virtually ad-infinitum without increasing the block size or the barrier of entry to running a Doge full node
Fully soft forkable
- Older versions of Doge can interpret OP_CHECKGROTH16VERIFY as OP_NOP as the stack is unmodified by our proposed op code
Does not require increasing/modifying any limits (stack depth, stack item size, transaction size, block size, etc)
- Fully functional zk Rollups enabling smart contracts/trustless rollups can be built using existing P2PKH + P2SH transactions
Does not require modifying any existing code in Dogecoin other than adding an op code handler to script/interpreter.cpp
Our team has already built a working reference rollup which demonstrates how OP_CHECKGROTH16VERIFY can be used to scale dogecoin and build complex applications, such as CityRollup

Summary:

We propose adding an op code to dogecoin which verifies a Groth16 zero knowledge proof over BLS12-381, OP_CHECKGROTH16VERIFY.

In particular, we propose that the op code verify a Groth16 proof with two public inputs, and support two modes of operation controlled by the stack:

Mode 0: Verify a proof with 2 public inputs and verifier key, all of which are stored on the stack, marking the transaction if the proof is invalid and behaving like OP_NOP otherwise
Mode 1: Verify a proof with 2 public inputs and verifier key, where the verifier key and first public input are stored on the stack, and the second public input is the transaction's SIGHASH.

By adding this op code (specifically mode 1), it makes it possible to verify any trustless computation on Dogecoin, build recursive covenants and design smart contract functionality via sighash introspection.

A working rough-draft implementation of OP_CHECKGROTH16VERIFY can be found in our fork, and you can also test it out with a docker image we built that includes a local testnet (regtest), block explorer (fork of blockstream electrs):

docker run -p 1337:1337 -it --rm qedprotocol/bitide-doge:latest

To test, you can visit http://localhost:1337 for BitIDE with OP_CHECKGROTH16VERIFY enabled, http://localhost:1337/explorer/ to view a block explorer and http://devnet:devnet@localhost:1337/bitcoin-rpc to interact with the local testnet via RPC.

Usage

In order to maintain backwards compatibility, we propose:

Redefining an available OP_NOP instruction such as 0xb3
Implementing OP_CHECKGROTH16VERIFY such that it verifies the proof and leave the stack unchanged (soft-forkable)
Mark the transaction as invalid if and only if the proof is invalid

The stack parameters accessed by OP_CHECKGROTH16VERIFY are as follows:

Mode 0 (Two public inputs)

<π_A_x> // (Proof) Fp -> 48 bytes
<π_A_y> // (Proof) Fp -> 48 bytes
<π_B_x_A0> // (Proof) Fp -> 48 bytes
<π_B_x_A1> // (Proof) Fp -> 48 bytes
<π_B_y_A0> // (Proof) Fp -> 48 bytes
<π_B_y_A1> // (Proof) Fp -> 48 bytes
<π_C_x> // (Proof) Fp -> 48 bytes
<π_C_y> // (Proof) Fp -> 48 bytes
<public input 0> // the first public input of the proof (32 bytes/Fr)
<public input 1> // the second public input of the proof (32 bytes/Fr)
<VERIFIER_DATA[0:80]> // bytes 0-80 of the verifier data
<VERIFIER_DATA[80:160]> // bytes 80-160 of the verifier data
<VERIFIER_DATA[160:240]> // bytes 160-240 of the verifier data
<VERIFIER_DATA[240:320]> // bytes 240-320 of the verifier data
<VERIFIER_DATA[320:400]> // bytes 320-400 of the verifier data  
<VERIFIER_DATA[400:480]> // bytes 400-480 of the verifier data  
OP_0 // mode 0
OP_CHECKGROTH16VERIFY

Mode 1 (Public Input 0 == user defined public input, Public Input 1 == SIGHASH)

<π_A_x> // (Proof) Fp -> 48 bytes
<π_A_y> // (Proof) Fp -> 48 bytes
<π_B_x_A0> // (Proof) Fp -> 48 bytes
<π_B_x_A1> // (Proof) Fp -> 48 bytes
<π_B_y_A0> // (Proof) Fp -> 48 bytes
<π_B_y_A1> // (Proof) Fp -> 48 bytes
<π_C_x> // (Proof) Fp -> 48 bytes
<π_C_y> // (Proof) Fp -> 48 bytes
<public input 0> // the first public input of the proof (32 bytes/Fr)
<VERIFIER_DATA[0:80]> // bytes 0-80 of the verifier data
<VERIFIER_DATA[80:160]> // bytes 80-160 of the verifier data
<VERIFIER_DATA[160:240]> // bytes 160-240 of the verifier data
<VERIFIER_DATA[240:320]> // bytes 240-320 of the verifier data
<VERIFIER_DATA[320:400]> // bytes 320-400 of the verifier data  
<VERIFIER_DATA[400:480]> // bytes 400-480 of the verifier data  
OP_1 // mode 1
OP_CHECKGROTH16VERIFY

Deep Dive: How Groth16 + Sighash enables trustless scaling and smart contract functionality on Dogecoin

To better explain how the OP_CHECKGROTH16VERIFY can help scale Dogecoin, it is necessary to first examine how zero knowledge proofs enable the verification of arbitrary computation from a birds eye view.

In general, zk-SNARK based zero knowledge proving backends allow a prover to succintly prove that a program described as an arithmetic constraint system is satisfied.

Consider the program:

void multiply(int a, int b, int c){
    assert(a * b == c);
}

if we wanted to prove that prover knows two numbers a and b which when multiplied equal c we could represent this program with the following diagram:

One could then take such a circuit and generate a corresponding verifier key which is unique to the program, and can be used to verify arbitrary executions of the program by utilizing a proving backend such as Groth16:

The verifier key of such a circuit can then be encoded in the spend script of a P2SH UTXO, and require a valid proof in order to be spent. One can then utilize a zk proving backend such as Groth16 to generate a valid proof:

The prover could then spend the UTXO by providing the proof in the witness of the P2SH spend transaction to successfully spend the UTXO:

Crucially, the size and complexity of verifying a Groth16 proof does not depend on the complexity or size of the computation being verified, meaning that OP_CHECKGROTH16VERIFY can verify an arbitrary amount of computation performed off chain without increasing the workload on Dogecoin nodes.

This enables Doge to validate new kinds of transactions like smart contract state machines and complex stateful without requiring any further changes to dogecoin, all while still respecting all existing limitations imposed on P2SH spends:

To enable trustless smart contract-like functionality without any additional burden on the network, we can use one of the public inputs as the spend transaction's SIGHASH and use the other public input to store the merkelized state of an application such as a smart contract:

Via the SIGHASH, we can allow the smart contract to be aware of any deposits of Doge made into the contract as well as any withdrawals or outputs that must be made in order to spend the UTXO:

To learn more about this sighash introspection technique, check out our reference implementation in CityRollup

Script Example

Ideally we would like to store the verifier data and current state root in the P2SH redeem script of the UTXO so that the UTXO can only be spent if we provide a valid state transition proof for given logic. Due to script limitations, stack elements must be at most 80 bytes and since the the verifier key is a total size of 480 bytes we can split it up to into 6 80-byte chunks.

In this case, our ideal script would look something like the following:

<public input 0> // the merkle root of the current state of the application (32 bytes)
<VERIFIER_DATA[0:80]> // bytes 0-80 of the verifier data
<VERIFIER_DATA[80:160]> // bytes 80-160 of the verifier data
<VERIFIER_DATA[160:240]> // bytes 160-240 of the verifier data
<VERIFIER_DATA[240:320]> // bytes 240-320 of the verifier data
<VERIFIER_DATA[320:400]> // bytes 320-400 of the verifier data  
<VERIFIER_DATA[400:480]> // bytes 400-480 of the verifier data  
OP_1 // mode 1
OP_CHECKGROTH16VERIFY // verify the proof and mark the transaction as invalid if the proof is invalid
OP_2DROP // clean up the stack data
OP_2DROP
OP_2DROP
OP_2DROP
OP_2DROP
OP_2DROP
OP_1 // successful spend

However, since the redeem script is limited to 520 bytes, we cannot directly use this approach. Instead we can hash the first 80 bytes of the verifier data, store the hash in the redeem script and provide the first 80 byte of the verifier key in the spend witness instead:

<public input 0> // the merkle root of the current state of the application
OP_SWAP // move the first 80 bytes of the verifier data to the top of the stack 
OP_DUP // duplicate the first 80 bytes of the verifier data on the stack
OP_SHA256 # hash the first 80 bytes of verifier data
<SHA256(VERIFIER_DATA[0:80])> // hard coded, known sha256 hash of the first 80 bytes of verifier data
OP_EQUALVERIFY // ensure the first 80 bytes of verifier data have the correct hash
// now the first 80 bytes of the verifier data are known to be correct and are at the top of the stack
<VERIFIER_DATA[80:160]> // bytes 80-160 of the verifier data
<VERIFIER_DATA[160:240]> // bytes 160-240 of the verifier data
<VERIFIER_DATA[240:320]> // bytes 240-320 of the verifier data
<VERIFIER_DATA[320:400]> // bytes 320-400 of the verifier data  
<VERIFIER_DATA[400:480]> // bytes 400-480 of the verifier data  
OP_1 // mode 1
OP_CHECKGROTH16VERIFY // verify the proof and mark the transaction as invalid if the proof is invalid
OP_2DROP // clean up the stack data
OP_2DROP
OP_2DROP
OP_2DROP
OP_2DROP
OP_2DROP
OP_1 // successful spend

To spend the UTXO, we provide the following witness:

<π_A_x> // (Proof) Fp -> 48 bytes
<π_A_y> // (Proof) Fp -> 48 bytes
<π_B_x_A0> // (Proof) Fp -> 48 bytes
<π_B_x_A1> // (Proof) Fp -> 48 bytes
<π_B_y_A0> // (Proof) Fp -> 48 bytes
<π_B_y_A1> // (Proof) Fp -> 48 bytes
<π_C_x> // (Proof) Fp -> 48 bytes
<π_C_y> // (Proof) Fp -> 48 bytes
<VERIFIER_DATA[0:80]> // bytes 0-80 of the verifier data

cf · 2024-08-14T08:03:55Z

cf
Aug 14, 2024
Author

Small progress update, we are currently working on removing the dependency on mcl, and adding support instead via https://github.com/cf/antelope-bls12-381/tree/cpp11compat for checking the proof, which is a c++ 11 compatible fork of the bls12-381 implementation already used in production by EOS.

1 reply

cf Oct 14, 2024
Author

Can checkout the full code for this here: https://github.com/QEDProtocol/dogecoin/blob/1.15.0-dev-groth16

louisguthmannStarkWare · 2024-10-14T08:49:47Z

louisguthmannStarkWare
Oct 14, 2024

While I appreciate the depth of the proposal and the work being produced, I could not be more opposed to an specific opcode than this one. While I will sound bias as an employee of StarkWare, this opcode seeks to reproduce the same mistake we saw on Ethereum, enshrining a specific curve into the chain as well as setting a privilege for a specific cryptographic primitive.
As of the more technical reasons for my opposition:

This opcode will make the codebase of Doge diverges forever with respect to BTC. As discussed with one of the maintainers, one ultimate goal to guarantee long term maintainability would be to rebase the codebase back from Bitcoin Core and benefit from the much larger dev community active on this repo. Additionally, the curve on which it is currently instantiate over while being well studied and standard is not the one most of the industry works on.
Based on the current dev capacity on this repository, adding a complex primitive would make it impossible for the maintainers to solve the issues without active participations of this improvement proposal while having no guarantees that the said proposers will remain actively involved in the maintenance after a potential upgrade. This scenario has already led other improvement proposals on other chains to be dropped (see: https://eips.ethereum.org/EIPS/eip-1829)
This opcode enshrines a new tech stack (ECC) which according to the latest state of affairs (see Scott Aaronson blogpost of Sept 2024: Quantum Computing: Between Hope and Hype https://scottaaronson.blog/?p=8329 with the following message: To any of you who are worried about post-quantum cryptography—by now I’m so used to delivering a message of, maybe, eventually, someone will need to start thinking about migrating from RSA and Diffie-Hellman and elliptic curve crypto to lattice-based crypto, or other systems that could plausibly withstand quantum attack. I think today that message needs to change. I think today the message needs to be: yes, unequivocally, worry about this now. Have a plan.), we should be careful about. I then don’t think we should add more opcodes that would make the transition more complex at the protocol level.

Finally and the most important point:

A quick guesstimate based on a MacBook Pro m3 chip (best CPU at date), for Bls381 on arkworks, a Pairing verification takes: 1.7ms against 19.4us for the second most expensive opcode Checksig while costing the same amount in vByte. In a worst case scenario, a block validation could take up to 8 minutes (assuming 3 public inputs and OP_CHECKGROTH16VERIFY, aka 4 vBytes and a block size of 1m vBytes). This is a massive DDOS vector for Doge which already suffers from high orphan blocks due to the 1m blocktime. Assuming worse performance from other other CPUs, it could get to even worse level.

While I am in favor of more ZKPs into Doge, I don’t believe this specific one is the right one. Hence I am opposed to this specific opcode.

4 replies

cf Oct 14, 2024
Author

Thanks for the feedback Louis!

Curious about a few of your points though:

1.

This opcode will make the codebase of Doge diverges forever with respect to BTC. As discussed with one of the maintainers, one ultimate goal to guarantee long term maintainability would be to rebase the codebase back from Bitcoin Core and benefit from the much larger dev community active on this repo. Additionally, the curve on which it is currently instantiate over while being well studied and standard is not the one most of the industry works on.

Maintenance is certainly important! Highly recommend checking out the source, as we only make a small modification to https://github.com/cf/dogecoin/blob/eaae7859367b0dab0ca0c0038ed71d4b021ccef0/src/script/interpreter.cpp#L1029, so should be relatively easy to maintain, also note that the Dogecoin codebase already has features that differ from Bitcoin (AuxPow).

2.

Based on the current dev capacity on this repository, adding a complex primitive would make it impossible for the maintainers to solve the issues without active participations of this improvement proposal while having no guarantees that the said proposers will remain actively involved in the maintenance after a potential upgrade. This scenario has already led other improvement proposals on other chains to be dropped (see: https://eips.ethereum.org/EIPS/eip-1829)```

Very valid point! We have already been working on getting a tip jar ready to fund years of maintenance into the future =)

3.

This opcode enshrines a new tech stack (ECC) which according to the latest state of affairs (see Scott Aaronson blogpost of Sept 2024: Quantum Computing: Between Hope and Hype https://scottaaronson.blog/?p=8329 with the following message: To any of you who are worried about post-quantum cryptography—by now I’m so used to delivering a message of, maybe, eventually, someone will need to start thinking about migrating from RSA and Diffie-Hellman and elliptic curve crypto to lattice-based crypto, or other systems that could plausibly withstand quantum attack. I think today that message needs to change. I think today the message needs to be: yes, unequivocally, worry about this now. Have a plan.), we should be careful about. I then don’t think we should add more opcodes that would make the transition more complex at the protocol level.

It's an interesting idea about quantum security, but it's worthwhile remember that every doge wallet is not quantum secure, and I guess it comes down to us believing that useful functionality should excluded by citing a different standard than the rest of the codebase follows.

4.

A quick guesstimate based on a MacBook Pro m3 chip (best CPU at date), for Bls381 on arkworks, a Pairing verification takes: 1.7ms against 19.4us for the second most expensive opcode Checksig while costing the same amount in vByte. In a worst case scenario, a block validation could take up to 8 minutes (assuming 3 public inputs and OP_CHECKGROTH16VERIFY, aka 4 vBytes and a block size of 1m vBytes). This is a massive DDOS vector for Doge which already suffers from high orphan blocks due to the 1m blocktime. Assuming worse performance from other other CPUs, it could get to even worse level.

Make sure to check out the code ;P,

You will note that P2SH redeem scripts are limited to 520 bytes, and if you try to do a DoS, you will find that the a proof requires a 855 vB of transaction space to verify a single proof (you cannot even fit the whole verifier data in P2SH script), so you cannot spam it in a transaction.

By that calculation (1000000/855)*1.7 = 2 seconds to process a block only filled with proof verifications (this is not a DoS if the block time is 1 minute).

If we want to support larger scripts in the future though, we could certainly limit the op code to 1 call per script which would avoid any spamming in that case as well.

Can you see any other downsides that you think we could consider and modify the proposal (also any PRs to our proposal would be highly appreciated ❤️), otherwise would really appreciate your support!

Especially interested in this one: gnark/consensys authors recommend using BLS12-381, what curve do you suggest we use instead?

patricklodder Oct 14, 2024
Maintainer

Thank you Louis, this helps getting the conversation going.

This opcode will make the codebase of Doge diverges forever with respect to BTC

This will happen no matter what and is already the case in some areas, otherwise this was just s/Bit/Doge/g and it's not. Cross-compatibility with existing Bitcoin features is something I'd personally like to guard for sure (i 8000 .e. don't make incompatible versions of the same functionality), most importantly because it allows for reuse of tools. But that only means to be compatible with how things are done on Bitcoin to the maximum extent possible for existing functionality on both chains, but not that Bitcoin has to support everything Dogecoin does. Therefore, in my opinion, adding a feature like this should in principle not be a threat, just like MWEB on Litecoin should not be a threat. Yes, there is additional code to maintain, but having code to maintain also attracts people; I personally wouldn't be here if it Dogecoin were simply Bitcoin testnet5. However - do tell me why I'm wrong.

I'd like to review how a change like this can be minimized in terms of potential conflict with Bitcoin protocol extensions, for example, which NOP to claim. This is important and will need to be done further down the line. Taking a NOP which will later be used by Bitcoin would be nasty.

As discussed with one of the maintainers, one ultimate goal to guarantee long term maintainability would be to rebase the codebase back from Bitcoin Core and benefit from the much larger dev community active on this repo.

Note that - and I also expressed this repeatedly in "discussions with one of the maintainers" - this is not the current strategy of this repository, for example see discussions here and here about this exact subject; the current status quo is the opposite of rebasing Dogecoin code back on Bitcoin Core. By my current best guesstimate, there are at best 5 people in the entire world that have the knowledge and capabilities to pull that off and doing a rebase would need all of them working together. Then, the amount of people willing to spend their time on such a boring job is arguably less than 2 since 2022, otherwise the 1.21 port would have been released years ago.

However, I do agree that it is both helpful and important to isolate, document and test Dogecoin-specific code inside this codebase. I proposed doing this for 1.21 already and would gladly work on that outside of that project (as that project is definitely dead.) This will keep the door open to a future rebase rather than backporting of individual improvements and make it much easier to create and maintain alternate codebases away from this repository. I'm more than happy to hold all implemented new functionality against a set of criteria to that end, including any implementation coming from this proposal, and propose rework to current code - assuming there's enough people willing to spend effort on getting that done.

Based on the current dev capacity on this repository, adding a complex primitive would make it impossible for the maintainers to solve the issues without active participations of this improvement proposal while having no guarantees that the said proposers will remain actively involved in the maintenance after a potential upgrade.

This is a concern for any code written for Dogecoin Core, including when backported from Bitcoin Core, but much more so for new protocol features; Developer consensus has historically been to be rather conservative (more so than Bitcoin Core) but I think everyone agrees that ossification out of fear is not a healthy approach and that Bitcoin has, post-taproot, come into the more conservative part of the cycle. Being as conservative as Bitcoin Core (or more) at this point is likely to be counterproductive, which is probably why this conversation is being had in the first place.

Either way, this risk needs to be addressed and ideally have multiple mitigations. I'm thinking minimizing the code impact, making sure that more than one use case is enabled with the feature, and making sure that processes are in place to keep things going. If @cf is able to reward people that work on the maintenance of the implementation through a tipjar as indicated above, then that helps too.

This opcode enshrines a new tech stack (ECC) which according to the latest state of affairs, we should be careful about. I then don’t think we should add more opcodes that would make the transition more complex at the protocol level.

If Bitcoin were to move to a quantum resistant signature scheme, then it would likely be done in the form of a new witness program - but correct me if there's reason to believe otherwise. (Yes, I'm ignoring potentially QR script spends on taproot because the post-OP_CAT lamport scheme looks huge and size matters in times of crisis; if tx size explodes 100x to safely spend then high fees will hurt 100x more (or: there will be only 1% of the people able to transact)

I think that it's safe to assume that Dogecoin would follow into such a new witness scheme with minimal changes. This would mean for a proposal such as this that it would need to (a) propose its own upgrade and (b) do that asynchronously - so there would likely have to be a separate softfork to allow a new primitive to be enabled in place of this one. This is definitely something to take into account / be aware of in the context of this proposal.

Would it ease the potential pain if the opcode itself were to be upgradeable, much like how witness programs are enumerated under segwit and maybe even more fitting: how CSV has reserved some bits for future upgrades? Maybe this could mean that verifying GROTH16 would be possible at activation, but then something like PLONK could be enabled in the future? This wouldn't be too hard to spec out a scheme for.

1.7ms against 19.4us for the second most expensive opcode Checksig

This is an important observation. Luckily there are means to limit this and this should be reviewed. 1 call per script per @cf above is a good measure (regardless of size), and per-block budgeting is probably needed too. This definitely needs to be measured and addressed during review - for this proposal and any other proposal that adds a primitive like this. Not measuring properly in the past has caused serious issues which can be felt every day when operating on Dogecoin, as some of the affected functions are part of consensus.

What alternatives do we have?

cf Oct 14, 2024
Author

Thank you Louis, this helps getting the conversation going.

This opcode will make the codebase of Doge diverges forever with respect to BTC

This will happen no matter what and is already the case in some areas, otherwise this was just s/Bit/Doge/g and it's not. Cross-compatibility with existing Bitcoin features is something I'd personally like to guard for sure (i.e. don't make incompatible versions of the same functionality), most importantly because it allows for reuse of tools. But that only means to be compatible with how things are done on Bitcoin to the maximum extent possible for existing functionality on both chains, but not that Bitcoin has to support everything Dogecoin does. Therefore, in my opinion, adding a feature like this should in principle not be a threat, just like MWEB on Litecoin should not be a threat. Yes, there is additional code to maintain, but having code to maintain also attracts people; I personally wouldn't be here if it Dogecoin were simply Bitcoin testnet5. However - do tell me why I'm wrong.

I'd like to review how a change like this can be minimized in terms of potential conflict with Bitcoin protocol extensions, for example, which NOP to claim. This is important and will need to be done further down the line. Taking a NOP which will later be used by Bitcoin would be nasty.

As discussed with one of the maintainers, one ultimate goal to guarantee long term maintainability would be to rebase the codebase back from Bitcoin Core and benefit from the much larger dev community active on this repo.

Note that - and I also expressed this repeatedly in "discussions with one of the maintainers" - this is not the current strategy of this repository, for example see discussions here and here about this exact subject; the current status quo is the opposite of rebasing Dogecoin code back on Bitcoin Core. By my current best guesstimate, there are at best 5 people in the entire world that have the knowledge and capabilities to pull that off and doing a rebase would need all of them working together. Then, the amount of people willing to spend their time on such a boring job is arguably less than 2 since 2022, otherwise the 1.21 port would have been released years ago.

However, I do agree that it is both helpful and important to isolate, document and test Dogecoin-specific code inside this codebase. I proposed doing this for 1.21 already and would gladly work on that outside of that project (as that project is definitely dead.) This will keep the door open to a future rebase rather than backporting of individual improvements and make it much easier to create and maintain alternate codebases away from this repository. I'm more than happy to hold all implemented new functionality against a set of criteria to that end, including any implementation coming from this proposal, and propose rework to current code - assuming there's enough people willing to spend effort on getting that done.

Based on the current dev capacity on this repository, adding a complex primitive would make it impossible for the maintainers to solve the issues without active participations of this improvement proposal while having no guarantees that the said proposers will remain actively involved in the maintenance after a potential upgrade.

This is a concern for any code written for Dogecoin Core, including when backported from Bitcoin Core, but much more so for new protocol features; Developer consensus has historically been to be rather conservative (more so than Bitcoin Core) but I think everyone agrees that ossification out of fear is not a healthy approach and that Bitcoin has, post-taproot, come into the more conservative part of the cycle. Being as conservative as Bitcoin Core (or more) at this point is likely to be counterproductive, which is probably why this conversation is being had in the first place.

Either way, this risk needs to be addressed and ideally have multiple mitigations. I'm thinking minimizing the code impact, making sure that more than one use case is enabled with the feature, and making sure that processes are in place to keep things going. If @cf is able to reward people that work on the maintenance of the implementation through a tipjar as indicated above, then that helps too.

This opcode enshrines a new tech stack (ECC) which according to the latest state of affairs, we should be careful about. I then don’t think we should add more opcodes that would make the transition more complex at the protocol level.

If Bitcoin were to move to a quantum resistant signature scheme, then it would likely be done in the form of a new witness program - but correct me if there's reason to believe otherwise. (Yes, I'm ignoring potentially QR script spends on taproot because the post-OP_CAT lamport scheme looks huge and size matters in times of crisis; if tx size explodes 100x to safely spend then high fees will hurt 100x more (or: there will be only 1% of the people able to transact)

I think that it's safe to assume that Dogecoin would follow into such a new witness scheme with minimal changes. This would mean for a proposal such as this that it would need to (a) propose its own upgrade and (b) do that asynchronously - so there would likely have to be a separate softfork to allow a new primitive to be enabled in place of this one. This is definitely something to take into account / be aware of in the context of this proposal.

Would it ease the potential pain if the opcode itself were to be upgradeable, much like how witness programs are enumerated under segwit and maybe even more fitting: how CSV has reserved some bits for future upgrades? Maybe this could mean that verifying GROTH16 would be possible at activation, but then something like PLONK could be enabled in the future? This wouldn't be too hard to spec out a scheme for.

1.7ms against 19.4us for the second most expensive opcode Checksig

This is an important observation. Luckily there are means to limit this and this should be reviewed. 1 call per script per @cf above is a good measure (regardless of size), and per-block budgeting is probably needed too. This definitely needs to be measured and addressed during review - for this proposal and any other proposal that adds a primitive like this. Not measuring properly in the past has caused serious issues which can be felt every day when operating on Dogecoin, as some of the affected functions are part of consensus.

What alternatives do we have?

Thanks for the feedback Patrick!
We will iterate and make a couple branches to better enumerate some possible options including the ones you mentioned, we'll make some new branches in the original repo that implements the proposed changes and will do some benchmarks on low spec hardware and follow up with some one liners so others can repeat and test for themselves =)

patricklodder Oct 15, 2024
Maintainer

We will iterate and make a couple branches to better enumerate some possible options including the ones you mentioned

If I were allowed a feature request, I'd ask if you could provide (deterministic) benchmarks (one for each mode) in src/bench? That way we can both track implementation improvements and get a standardized way of measuring performance on different hardware architectures.

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Uh oh!

Draft Proposal - OP_CHECKGROTH16VERIFY: An ultra-lightweight, soft-forkable solution to trustlessly scale and add smart contract-like functionality to Dogecoin #3614

Uh oh!

{{title}}

Uh oh!

Uh oh!

{{editor}}'s edit

{{editor}}'s edit

Uh oh!

Replies: 2 comments 5 replies

Uh oh!

{{title}}

Uh oh!

Uh oh!

{{title}}

Uh oh!

Uh oh!

{{title}}

Uh oh!

Uh oh!

{{editor}}'s edit

{{editor}}'s edit

Uh oh!

Uh oh!

{{title}}

Uh oh!

Uh oh!

{{title}}

Uh oh!

Uh oh!

{{title}}

Uh oh!

Uh oh!

{{title}}

Uh oh!

Select a reply

Uh oh!

Draft Proposal - OP_CHECKGROTH16VERIFY: An ultra-lightweight, soft-forkable solution to trustlessly scale and add smart contract-like functionality to Dogecoin #3614

Uh oh!

Uh oh!

cf Jul 29, 2024

OP_CHECKGROTH16VERIFY

Highlights:

Summary:

Usage

Mode 0 (Two public inputs)

Mode 1 (Public Input 0 == user defined public input, Public Input 1 == SIGHASH)

Deep Dive: How Groth16 + Sighash enables trustless scaling and smart contract functionality on Dogecoin

Script Example

Replies: 2 comments · 5 replies

Uh oh!

cf Aug 14, 2024 Author

Uh oh!

cf Oct 14, 2024 Author

Uh oh!

Uh oh!

louisguthmannStarkWare Oct 14, 2024

Uh oh!

cf Oct 14, 2024 Author

1.

2.

3.

4.

Uh oh!

patricklodder Oct 14, 2024 Maintainer

Uh oh!

cf Oct 14, 2024 Author

Uh oh!

patricklodder Oct 15, 2024 Maintainer

cf
Jul 29, 2024

Replies: 2 comments 5 replies

cf
Aug 14, 2024
Author

cf Oct 14, 2024
Author

louisguthmannStarkWare
Oct 14, 2024

cf Oct 14, 2024
Author

patricklodder Oct 14, 2024
Maintainer

cf Oct 14, 2024
Author

patricklodder Oct 15, 2024
Maintainer