Published on: 2014-07-17T20:08:24+00:00
Jeremy has proposed a new transaction type that matches on script hashes similar to pay to script hash, but checks for one of N scripts. However, this idea is considered less flexible and efficient compared to the Merkelized Abstract Syntax Tree construction. The proposed idea was previously discussed by Tier Nolan in the "Selector Script" thread.The discussion revolves around the costs associated with implementing a new transaction type in Bitcoin's network. The proposed method is compared to P2SH, which is already analyzed by developers and working. The cost of updating everyone to relay this new transaction type is also considered, along with the cost of increasing the rate of UTXO growth versus P2SH and the implications of "default public" versus P2SH's "default private". In terms of space efficiency, publishing the script in the txout allows for easy auditing by third parties scanning the blockchain. However, this can also be accomplished by offering the script upon request out-of-band. The idea of creating a "cookbook" of useful scripts is presented.The proposal suggests doing a p2sh with a switch statement that allows selecting one of n scripts each 520 bytes long without bloating the utxo pool more than a p2sh. This could result in long-term space savings on disk for regular p2sh. Adding a "function-hash-pointer jump table / switch statement" could also save space and allow for more complicated scripts to be built.Considerations for a system like Bitcoin include the cost of upgrades and network-wide changes compared to already analyzed and working P2SH, as well as the predictability of P2SH outputs versus less predictable outputs. Updating everyone to relay new transaction types and increasing the rate of UTXO growth also add to the cost. Publishing the script in the txout allows for easy auditing, but it can also be done through out-of-band offering. The script is hash-sealed by the P2SH address, enabling perfect proof. A "cookbook" of useful scripts would help explore the power of Bitcoin scripts.A proposed method is simpler with fewer bytes for control flow, but additional costs would be in terms of chance of user error/application error, extra bytes for control flow, larger script size if scriptSig script has to store the logic for all potential permission groups, hidden-till-spent permission groups, and larger blockchain bloat overall. Blockchain analysis can actively monitor the utxo pool for known associated scripts, whereas specialty scripts assembled per group cannot. A SAT scripting language with an eval or something similar can also be added. Using a normal P2SH output with OP_IF and friends seems more straightforward when considering the costs of increased UTXO pool bloat and transaction complexity. Boolean logic with multisig groups is quite possible, and there is definitely a valid use case called "multi-multisig".The proposed method of using a 20-byte hash to represent a permission group incurs additional costs in terms of chance of user error/application error and extra bytes for control flow. However, this method allows for hidden-till-spent permission groups, reduces blockchain bloat, and enables repeated spends with groups without recalling all participants. The author suggests pushing the sigs onto the stack and having implicit orders, then doing expressions with their aliases, and being able to assign "spending groups" using a SAT scripting language with an eval. Doing boolean logic with multisig groups is quite possible, referred to as "multi-multisig".In an email conversation, Jeremy proposed a solution to express multiple ways that would incur additional costs in terms of complicated control flows. He suggested using a normal P2SH output and a script with OP_IF and friends, which seems more straightforward. However, there is an implication in terms of increased UTXO pool bloat and increased transaction complexity. Each 20-byte hash allows for a 500-byte script, and only one of the 500 byte scripts has to be permanently stored on the blockchain. Jeremy also mentioned that doing boolean logic with multisig groups is quite possible and considered it a valid use case called "multi-multisig".Jeremy Rubin proposed a new transaction type that matches on script hashes similar to pay to script hash but checks for one of N scripts. The motivation behind this idea is to create "permission groups" where multiple groups can spend a UTXO. Currently, expressing this would require additional costs in terms of complicated control flows. Therefore, Jeremy proposed the use of OP_HASH160 [20-byte-hash-value 1]...[20-byte-hash-value N] OP_N OP_MULTISCRIPTHASHVERIFY which could be spent with signatures and serialized script. While the permission group example is just one use case, there could be other interesting combinations as well. However, there is an implication in terms of increased UTXO pool bloat and increased transaction complexity.
Updated on: 2023-08-01T09:44:52.250059+00:00