Hi. My company Alacris.io is building a Blockchain-agnostic operating system for DApps. So far we are targeting Ethereum, and I would like my next target to be BCH.
I have some proof of concept code for a trivial contract to play "Rock Paper Scissors" on the Bitcoin ABC blockchain, thanks to the opcodes reenabled in May 2018 and to the new CHECKDATASIG.
However, on the one hand I have a lot of questions about how CHECKSIG works. My understanding, is that I can use CHECKDATASIG to check a copy of the transaction data, such that I can constrain the outputs to be what the contract requires. But I couldn't find recent documentation or test vectors for how CHECKSIG works, and how exactly to reproduce the transaction data.
On the other hand, I am facing severe size limitations that I believe require some protocol change. To enable contracts that use non-trivial amounts of code and data, computing the transaction data may well require hashing strings that are longer than 520 bytes. Here are a few ways that this limitation can be lifted, not mutually exclusive:
1. The most immediately helpful way to package contract state would be a variant of P2SH that carries two hashes, one for data and one for code. The data could either be an array of push-only code, or be a single piece of raw data that the code takes apart. In either case, separating the two means that you can specify the continuation of your contract as a hash of code and state data that is being closed over. With the current P2SH, you have to reconstitute and hash the code+data, which means that each fragment of code needs to include as data all possible transitive future fragments of code, just so as to be able to create the P2SH hash, and it must all fit in 520 bytes, including the data being closed over. With a P2SH variant that has both code and data, each fragment would require only its own code, and would be able to refer to sign the continuation output by just hashing the contract data and referring to a constant code hash as a content-addressed pointer.
2. A more elaborate take on the above would be support for some more general kind of EVAL or MAST, but it's a tricky topic to get right, since you still want to keep evaluation time proportional to space. I admit I haven't thought hard enough about it and haven't looked at previous or current proposals in any bitcoin fork.
3. A simple and stupid way to allow hashing things larger than 520 bytes would be to have three opcodes SHA256_INIT, SHA256_MIX, SHA256_FINISH that allow to compute the hash of long strings, 520 bytes (max) at a time. Then, a script could reconstruct the transaction message to sign from long scripts, and verify that it matches expectations. But without the P2SH variant requested above it still would require every fragment of the contract to have a copy of the code for all the rest of the contract.
4. Another way would be to have opcodes that allow to inspect data from the current transaction and/or from other chain state. Thus, the script could not only validate the outputs, but also consult commitments to recent chain data, providing a free oracle on anything historically included in the chain itself.
Is this the right place to discuss those things? If not, what is the right place?
I have some proof of concept code for a trivial contract to play "Rock Paper Scissors" on the Bitcoin ABC blockchain, thanks to the opcodes reenabled in May 2018 and to the new CHECKDATASIG.
However, on the one hand I have a lot of questions about how CHECKSIG works. My understanding, is that I can use CHECKDATASIG to check a copy of the transaction data, such that I can constrain the outputs to be what the contract requires. But I couldn't find recent documentation or test vectors for how CHECKSIG works, and how exactly to reproduce the transaction data.
On the other hand, I am facing severe size limitations that I believe require some protocol change. To enable contracts that use non-trivial amounts of code and data, computing the transaction data may well require hashing strings that are longer than 520 bytes. Here are a few ways that this limitation can be lifted, not mutually exclusive:
1. The most immediately helpful way to package contract state would be a variant of P2SH that carries two hashes, one for data and one for code. The data could either be an array of push-only code, or be a single piece of raw data that the code takes apart. In either case, separating the two means that you can specify the continuation of your contract as a hash of code and state data that is being closed over. With the current P2SH, you have to reconstitute and hash the code+data, which means that each fragment of code needs to include as data all possible transitive future fragments of code, just so as to be able to create the P2SH hash, and it must all fit in 520 bytes, including the data being closed over. With a P2SH variant that has both code and data, each fragment would require only its own code, and would be able to refer to sign the continuation output by just hashing the contract data and referring to a constant code hash as a content-addressed pointer.
2. A more elaborate take on the above would be support for some more general kind of EVAL or MAST, but it's a tricky topic to get right, since you still want to keep evaluation time proportional to space. I admit I haven't thought hard enough about it and haven't looked at previous or current proposals in any bitcoin fork.
3. A simple and stupid way to allow hashing things larger than 520 bytes would be to have three opcodes SHA256_INIT, SHA256_MIX, SHA256_FINISH that allow to compute the hash of long strings, 520 bytes (max) at a time. Then, a script could reconstruct the transaction message to sign from long scripts, and verify that it matches expectations. But without the P2SH variant requested above it still would require every fragment of the contract to have a copy of the code for all the rest of the contract.
4. Another way would be to have opcodes that allow to inspect data from the current transaction and/or from other chain state. Thus, the script could not only validate the outputs, but also consult commitments to recent chain data, providing a free oracle on anything historically included in the chain itself.
Is this the right place to discuss those things? If not, what is the right place?
