I started thinking about an attack vector against previous version of this opcode you proposed. So you create millions of transactions that have few OP_BLOCKHASHMATURED XHASHX, each of XHASHX is generated by taking an existing block hash and changing it in a way that it does not exist and is the longest to process (making sure that the search algorithm has to go through as many of existing blocks as possible just to determine that such block hash does not exist).
Your updated version invalidates this attack, because now you only need to check a single position at block height Y_BLOCKHEIGHT and going through whole index is unnecessary.
While the discussion of cost is good to have, it does skip directly to the ‘cons’ of equasion. Probably a bit bikeshedding going on as nobody is talking about the ‘pro’ side.
The gains given have at best been explained only in terse forms. What new usecases are we missing out on if this isn’t there?
I’m a dev, but I do know the meaning of “devs just like to dev” and while the cost may be low of the execution, the cost of many any hard fork change is supposed to not be just about that…
I asked this before and din’t get an answer back then either.
When a new idea is posted the cons should always be discussed first because there is little point in thinking about if it should be done before considering if it is feasible. A lot of ideas die in the evaluation of feasibility. Once it has been established that it is feasible the arguments for why it should be done have their time to shine.
Collect a bunch of ideas, throw away the ones that are not possible, re-evaluate the list, throw out the ideas that could be done but serve no purpose, the remainder are possible changes to make based on ecosystem support.
You mean OP_REVERSEBYTES? I was not there but was glad to find it once I started dabbling with Script and found use for it: parse block header pushed to stack and calculate chainwork from the compressed target. Part of the Script required conversion of BE to LE script numbers, and the opcode came in handy there.
Recent talk about tokenizing AnyHedge contract prompted this. Imagine you want to create a DAO that pools together tokenized AnyHedge contracts. The DAO needs to be able to verify, using nothing but Script and local TX context, that some NFT satisfies this:
Has rights to payout of a particular AnyHedge UTXO with such and such contract params;
The payout address is a pay-to-NFT;
There’s only 1 NFT of the target category.
As it is, we can set this up only if the NFT interacts with the funding TX, and it can interact in one of the 2 ways:
spend some public covenant’s NFT UTXO as an extra input so it can attest to the funding TX and emit a NFT as an extra output, with attestation of the TX encoded in the commitment;
have the funding TX set a covenant on output0 and the AnyHedge contract UTXO be some other index. The covenant would require creation of a NFT of new category in the next TX and the proof of funding TX existing would then be compressed in the categoryID of the NFT
Could we tokenize AnyHedge without changing the funding TX structure, by simply setting payout address(es) to some pay-to-token P2SH? Sure we could, but then the target token can’t make proofs to other contracts, and they couldn’t verify it for acceptance into some pool. This method of tokenization would only be usable for listing contracts on the secondary market as a means of early exit, but they wouldn’t be composable.
If we had something like the opcode above, then we’d have a way of tokenizing a proof of existence of any mature TX - and do so non-interactively. Simply have some public NFT covenant require the user to push whole SPV proof as input script data, and the contract would verify it matches a mature block hash, after which it would emit an attestation NFT with TXID encoded in the commitment.
Apart from that reaching an insane size, this isn’t exactly a usecase.
Side-note: I’m a bit vague on the technicals from your short version, but I don’t think it is possible to do what you said due to merkle-proofs having a variable number of hashes. And the only way you can do that without loops is to have the details already available at time of building the locking script, and then there is no point in including the proof at all.
Anyway, the point of me asking for a “usecase” is to avoid this going over the heads of 99% of the people.
I’m guessing this would go something like:
a user could already now sell their contract to a 3rd party without breaking the terms to the second party using tokens.
what this opcode adds is the ability to make derivative markets on-chain.
Personally I think the whole financial system is severaly broken and ever more complex ways of trading is Ok to leave behind. The financial system with all their derivatives and other fancy instruments extract more value out of normal people’s hands than any other system in existance. Why on earth would we want to invite those leaches onto crypto currencies? Let them do it via some centralized system. I’m sure they will eventually and likely prefer it over anything defi we build.
Keep it simple. Anyhedge (specifically their selling of risk contract) is probably the best idea that actually helps normal people. Adding more layers on top does not have my vote.
non-interactive “introspecting” any transaction older than 100 blocks, SPV method;
source of entropy / randomness;
easier and more secure implementation of chainwork oracle, which could be used for truly decentralized AnyHedge betting on BCH / BCH_chainwork;
non-interactive tokenization of AnyHedge contracts (as opposed to interactive: needing to make tokenizer contract be part of funding TX).
Why would it be insane size? To generate the NFT you’d be pushing up to 520 bytes (raw TX) + some hashes + up to 520 bytes of redeem script that validates the commitment set on the new NFT. That’d be done only once per some TX of interest. The NFT would be P2PKH afterwards, free to move without having to replicate the validation script, and another covenant could enable cloning the NFT and its proof with much less code. The initial proof would have to be made only once, and NFT could be copied as needed to plug the compact proof into any number of contracts that need it.
Other contracts could then just inspect the NFT’s categoryID and commitment and be assured that the TXID exists simply because the NFT of the category exists. That could be used to switch some logic (like a contract verifying that some pre-signed TX has been indeed mined) or it could be used to decompress the whole TX to inspect parts of the TX (requires again pushing the whole TX to stack, but without having to again verify it against the header - that part is already done by an ancestor TX).
Here again you can do the prove once, use many times approach - a contract can verify some template of the examined TX and emit compact proofs as NFTs, where contracts that need the proof could simply trust the NFTs claim without having to inspect the TX in question by themselves.
No, it’s an outline of a generic procedure. I have ideas for some use-cases listed above, but it could enable more if people get creative.
I want to tokenize AnyHedge, so I can exit a hedge position early by trading it for BCH. It’s possible to tokenize it now but it would require a different setup of the funding TX.
With the opcode, I could tokenize current BCH_BULL contracts all by myself, without having to depend on them changing the funding TX structure.
However, AnyHedge has clearly shown that what they are doing has massive merit and a huge upside to BCH as a whole.
They can remove the volatility risk from merchants, like it never existed. And it will join merchants and speculators under common goal at the same time. It’s almost like magic.
I think if this proposal makes it easier for services like AnyHedge to achieve success and continue what they are doing, this is a path worth following.
That ‘however’ states disagreement. There is no disagreement.
Read my closing statement again:
To split that into easy to digest facts,
Anyhedge today works. I love it, I support it fully. Always have. No new opcodes are needed (we already activated those!).
Anyhedge could become tradable on-chain, allowing people to sell their contract that sold their risk. This is possible today using NFTs, no new opcodes needed. Source: BCA above my post.
However, what this opcode would possibly add is the betting on, selling of contracts which sold your risk.
So, sure, anyhedge is great. But that is not what we are talking about. Its like pushing through censorship laws to protect the children. You can’t disagree without seeming to want to harm children. Please, my IQ is above 100…
So I ask, do you really need to add all those layers on top, on-chain?
I also stick to my former point that traders and financial people will absolutely build such things again since BCH allows permissionless innovation. Most probably centralized. And arguably that will work better and cheaper than anything on-chain. So any argument that saying NO to this is blocking someone or something is plain false.
Come up with a better usecase and I might change my mind, I will not, however, support anything that is there purely to reinvent the worst parts in our current society.
To @bitcoincashautist, usecases are not some techincal statement like “source of entropy”, that is not a usecase. Usecases involve an actual person and their ‘wants’ and how they interact with the system to get what they want.
The advantage of that is when you say “we can do a lottery using this and a source of entropy” we can talk about it, and I point to Satoshi’s Dice and you may need to explain why that isn’t good enough. And we can actually talk about this without it being academic high level BS that nobody else can chime in on.
Usecases are essential here, otherwise we are just devs that likes to dev.
I think this violates the unspoken but strict no-reevaluation policy of op codes. The value of this changes depending on blockchain state, specifically reorgs.
That means every transaction using this or descended from a transaction using this has to be re-evaluated continuously. That’s no bueno for scaling.
You’re correct, but you did miss that we have a class of outputs that “violate” it: coinbase outputs & their descendants.
This is why we have the maturity coinbase rule: they’re unspendable before they mature, so it can’t really happen that their validity changes as it would require a 100-deep reorg.
This is why the idea here is to push / verify only the matured headers. If it’s not matured yet, the opcode would fail and TX would be invalid. Once it would become valid - it would become due to header becoming mature, and flipping back to invalid would require 100-deep reorg.
Some of the functionality is possible in a roundabout way btw: convince some hash-rate to include a covenant as a coinbase output, such that requires CashTokens genesis and allows anyone to clone NFTs. Each such NFT would have categoryID of a coinbase TX, and “unpacking” the hash would reveal the coinbase TX. From there, the user could extract the height + add the other merkle node hash and verify it against a header produced by a chain of covenants. This could pin the height, but I think it’d still allow alternative covenant states by replaying the same coinbase TX on an alternative chain so still we can’t 100% prove a header to some contract.
Side-note, this high-level idea would allow Drivechain-like hash-rate voting:
Hashrate would opt in by using a simple one-time vote covenant (OTVC) address that requires bridge DAO input as sibling.
Bridge DAO could then burn and tally these one-time vote covenants and accumulate them in NFT’s commitment. By “unpacking” the TXID of the vote covenant’s input, the DAO can verify the vote is indeed coming from a coinbase TX, and extract the height from the input to verify belongs in the voting window.
I guess so. Same order of magnitude issue as checking descendants of coinbase.
Flipping back to immature requires “only” a reorg of m blocks replacing n, where m<n, right? Not 100. I don’t know how / how efficiently nodes handle that.
It’s a nice idea. It would be nice to have for a very slow-reacting chainwork oracle which could potentially be incredibly valuable.
Oh yeah you’re right, wait but how do nodes handle the same happening to coinbase outputs? I’d guess that once it becomes mature it’s considered mature even if one block gets popped. The hypothetical opcode should behave the same. Once the TX using it becomes 100 deep, it’s considered valid even if some reorg should happen to shorten the chain and make it 99 deep.
I think there are 2 thresholds for coinbase outputs. The output is spendable after 100 blocks, but clients don’t actually add the transactions to the memory pool until 120 blocks have passed.
Essentially, the protocol rule is 100 blocks, but the mining node rule is 120 blocks.
That way a re-evaluation would only need to occur if a 20 block re-org happened.
A re-org could also cause transactions with locktime to have to be evicted from the memory pool, so the client must have some way to handle that too. Those transactions would be spendable eventually though, so removal but keeping them in a pending store, or similar.
