Op_get_current_block_height

[hosseinzde]

Hello There

I want to open a discussion on a new op code that retrieves current block height from the global state.

We do have CheckLockTimeVerify and CheckSequenceVerify. Both need block height or block timestamp to operate. And I know these two op codes have a certain characteristic. Once they will become valid in the chain. Their validity does not need verification on the next block.

Now the question is. Does bitcoin’s current implementation takes advantage of this behavior to operate, Meaning once the transaction becomes valid it will no longer check for validity on the next block. If so the implementation of the new opcode will become a big hassle.

Why this opcode is a great thing to have?

At the moment AnyHedge contracts cannot get settled at every block until the contract time is over. With the help of an opcode that retrieves current block height this will be possible to do.

For example lets say we are at block height 501 and the data from OP_CHECKDATASIG shows the price of the hedged asset at block 500. Then we construct a script that will only be valid in that particular block height.

I’ve studied bitcoin code a few years ago. I’m not clueless. But I’d be happy to get educated on this concept.

Please let me know what you think. Is this something bitcoin engine can handle?

[im_uname]

Any opcode that can result in an already admitted tx being evicted from mempool again, for any reason other than fees and congestion, will be terrible for scaling (you’ll have to reprocess the entire mempool every block), and so are unlikely to be adopted. It’s the same reason why CLTV can only do “valid after”, but not “valid before”.

[hosseinzde]

Too bad.

Mempool is not part of the consensus rules. A better solution may render it as obsolete.

I really liked this ability. Imagine being able to settle contracts at any time without the need to trust the other peer.

[hosseinzde]

Here’s another idea for accomplishing the same task.

If we can access the block height for parent transaction. This can be done. How is that?

The parent transaction should have a particular characteristic. It will only be spendable when it has been included in a block.

What do you think im_uname?

[garlonicon]

Then we construct a script that will only be valid in that particular block height.

This is reorg-unsafe. You don’t want to receive a zero-confirmation transaction that will be a child of such transaction. You will have transaction A (valid only in block N) and you will get some coins in transaction B, where A->B. You don’t want to accept transaction B, you can no longer trust zero-confirmation in that case. And you should not be forced to explore the whole chain of A->B->C->…->Z transactions, if you received transaction Z, to be sure that there are no suspicious things in any of those transactions.

If we can access the block height for parent transaction. This can be done. How is that?

It has the same problem, when both transactions are included in the same block.

Is this something bitcoin engine can handle?

Of course it can. Even Satoshi responded to such questions (see: OP_BLOCKNUMBER). His conclusion was just that it is not safe, in case of chain reorganization.

We can’t safely do OP_BLOCKNUMBER. In the event of a block chain reorg after a segmentation, transactions need to be able to get into the chain in a later block. The OP_BLOCKNUMBER transaction and all its dependants would become invalid. This wouldn’t be fair to later owners of the coins who weren’t involved in the time limited transaction.

nTimeLock does the reverse. It’s an open transaction that can be replaced with new versions until the deadline. It can’t be recorded until it locks. The highest version when the deadline hits gets recorded. It could be used, for example, to write an escrow transaction that will automatically permanently lock and go through unless it is revoked before the deadline. The feature isn’t enabled or used yet, but the support is there so it could be implemented later.

[bitcoincashautist]

We can’t get current height, but we could fetch height of mature blocks (100-deep), related: Viability of Native Introspection of Mature Block Headers and Coinbase Transactions

[Tinos]

I believe this may be the most important problem we all need to look at (or at least in the top-5). Ideally devs should just ignore CashTokens until this issue is resolved, unless long-term funding for both can be obtained. Bitcoin should be capable of Hedging long before it ever supports tokens like flexUSD or USDT. All the issues normally raised seem like nonsense. Instead of Op_get_current_block_height I’d have to suggest OP_CHECKBLOCKHEIGHTVERIFY (OP_CBHV), or maybe OP_BLOCKHEIGHT (once mentioned by P. Todd). OP_CBHV fits in better I think.

An important restriction is that all outputs should be frozen for like 10-confs afterwards, similar to how mining rewards are frozen for 100-confs. One might argue for 6-confs, but BCH hash rate is so low that maybe 10-confs is safer. 0-conf can’t apply to any txn following the execution of this OpCode, unless 10-confs are obtained. Therefore the network should not allow any UTXOs to be spent within 10 blocks. This one restriction could literally make some traders suicidal, but it looks necessary. (A gold bug must wait nearly 2 hrs to re-Hedge after an uncooperative Exit from a Hedge contract.)

The mempool can just flag & remove any & only txns which execute the OpCode (OP_CBHV), after a new block is found. Since there can be no chain of unconfirmed txns following its use, that seems simple enough.

The BCH community could be heading towards scam-watch levels of absurdity if CashTokens gain widespread support before Hedging. It looks like the only chance of CashTokens being successful is if we beg the government & police to uphold the rule of law, or something.

(Edit: Outputs only need be frozen for 10-confs if OpCode is executed. If in an unexecuted OP_IF branch then all outputs are free to instantly force a subsequent chain of 0-conf txns.
Also, unfortunately it’d be possible for a troublemaker to send payments to a merchant which are also locked for nearly 2hrs.)

[bitcoincashautist]

I’m not in the mood to argue this again, I’ll just c&p some of my responses from the Telegram discussion (started here) that prompted this.

you can prove to contract that some height has been reached through OP_CHECKLOCKTIMEVERIFY, you don’t need to hardcode a constant height, you can put the value in the input script and have other contract inspect it

umm if you depend on trusted oracle messages you can do in&out&inagain even in an unconfirmed chain, the message encodes a timestamp which contracts can read, it’s not tied to blockchain clock
gp msgs are published every 1minute iirc
you put one in input signature, the contract parses it and does w/e
then you spend the output with the next message and so on, all 1min apart
a chain of 10 hedges could get mined in the same block

no it’s not… we got a bunch of new opcodes with clear use cases and no negative impact to fundamental scaling properties of the network. OP_CBH would require miners to reevaluate TXes in mempool on every mined block, it’d be horrible for scaling
you’re rambling incoherently, what do you want to do with OP_CBH that can’t be done with clever application of OP_CLTV?
you want a TX that can’t be mined at any block height other than X? you can do that with OP_CLTV
but requires an alternative spending path where anyone can spend it in order to prevent it from later being spent by you

You keep posting your opinions as fact. That’s why I can’t read you and called it “incoherent rambling” because you only present your conclusions, but where’s the line of reasoning that led to it?

[tom]

Heya,

you seem to be convinced that a new feature is needed and I’m not sure I see any explanation from you on why.

Please give technical arguments and preferably with some examples of the current script which you tried that failed to do the trick. And why.

I suspect that it is possible today, but your test scripts have a bug in there or something. So, please share your experiments and let us help you figure this out.

[Tinos]

American-style options for various assets are ideal. The essential big 3 are BTC, XAU & USD. However a massive BCH Bull could gather a per-block interest rate against almost anything & if an effective Short adds up they can long the asset elsewhere to cover any potential loss. A Hedge to BTC is fundamental because BCH could have been forked as BitCoin-Hedge - a default Hedge back to BTC paying like 0.2%/month interest.

P2P Hedging for the world is arguably much more valuable than P2P Cash for the world, so it’s important to have the correct OpCode/s. While BTC may be considered a Store-of-Value, BCH could become a Hedge-to-Value. Even astronauts in orbit around Earth could conceivably Hedge to any asset using a wallet like Electron-Cash. BCH Bulls can charge higher Hedge-rates on exotic assets. Maybe we could “buy” almost any element on the Periodic Table, using just P2P Hedging.

American-style is when the Hedge can Exit at any time. Using OP_CBHV they’d have to wait a couple hours which is risky (they’d be holding BCH). So ideally we’d want BCH Bulls online 24/7 to auto-sign off on any Exit, at some agreed price.

An ideal would be for a smartphone Hedge-wallet to Exit, spend & Hedge instantly (3 txns). That’d require Bull’s signature. If a Bull is offline, the Hedge can Exit 2 hrs in advance. The contract may feel like a LightNing channel, since cooperation is required for max efficiency. But with OP_CBHV cooperation isn’t strictly required.

A price-stop-loss btwn 1% & 9% seems reasonable, but triggering it could cause a 2hr delay. +9%→-9% could be a -17% error (17% of life-savings lost). Ideally both Hedge & Bull could nominate a different Oracle, & if prices disagree by 5% there could be a special return clause. Even WTI crude oil price went -ve during 2020, so a whole industry can look scammy on occasion. A price ticker at the NYSE could be off. Errors may not be due to a scam-oracle. A smaller stop-loss may allow much more capital. If an oracle & counterparty both disappear, there can be like a 2-month time-lock to return principals.

OP_CBHV allows variable maturity in the AnyHedge contract, which means a per-block interest rate can be used to pay the Bull. They have to be available 24/7 365 days/year, to 2x long BCH against any asset. As a Hedge-to-Value, BCH Hedge-rates may be fundamental to how we present BCH to the public. Without OP_CBHV, a monthly Hedge is hard to imagine since a Hedge may want to Exit after a day but the Bull may charge a fee like a ransom, holding funds hostage for 29 days. The Hedge could be a multisig escrow, awaiting product shipping. Hedgers may be afraid to try untrusted Bulls, without OP_CBHV allowing a Hedge to Exit. Bulls may not be allowed to Exit, depending.

The 10-confs protection for further 0-confs seems elegant. Even if 0-conf were abandoned, the OP_CBHV could still cause mayhem without the 10-conf lock. Merchants could be warned of the issue where a customer can pay with a 2hr lock on all outputs, using some trick.

[bitcoincashautist]

@Tinos

OP_CBHV allows variable maturity in the AnyHedge contract

That is not the only way to have variable maturity.

You can have a covenant chain incrementing OP_CLTV where any link can be consumed either by the contract or by the next link, so if the chain is extended by the next link then it becomes unusable by the contract because it would be double-spending it, in which case the contract must use the next link. Essentially it’s a blockchain clock where contracts could use only the current time and not some past time because that clock state would’ve been spent by the updated time.

“the contract” - whatever time-sensitive settlement contract

Every contract instance would instantiate its own CashToken clock and hardcode the clockID so a clock can’t be forged to fool the settlement contract into settling at some past time.

[tom]

@Tinos

P2P Hedging for the world is arguably much more valuable than P2P Cash for the world

Depends on who you ask.

You might not know the background behind the 2008 financial collapse, but it was due to hedging and swaps. So, sure, people using those instruments got rich for a while, but the entire system damn near collapsed as a result.

P2P hedging (American style) is super profitable for the gamblers, but to ask for the Bitcoin Cash ecosystem to enable this kind of gambling you need to play on personal greed too. How does it benefit the merchant or the granny that just wants to keep her funds safe?

The BTC coin is where they invite “institutions” and hope from buy-in there. On the other hand, Bitcoin Cash is peer to peer cash. Which is the money of the people.

You might want to change your salespitch to match.

[Tinos]

OP_CLTV won’t work. Pretending AnyHedge could work makes it look like you’re just paving the way for some CashToken version of flexUSD to scam ppl. Without OP_CBHV, or at least a promise for it, I’d have to suggest cancelling the release of CashTokens. CashTokens might just be a scam. We’d need a dozen oracles for a hundred (or 10 thousand crypto prices alone) asset prices, all updating prices on-chain every 10 mins using some bizarre OP_CLTV+CashTokenID trick - it’s just nonsense.

Without OP_CBHV big-blockers may as well go back to BTC & fork again, because a Hedge-to-Value asset (a Value used to Hedge to everything else) should be forked from a Store-of-Value asset, since the HtV increases in value the more ppl short it, unlike a SoV. A valid SoV fork needs to Hedge back to BTC by default in the full node - or else it ain’t truly valid. Michael Saylor could call me a scammer for selling BCH as a HtV asset whose value derives from BTC.

In the past it may have been simpler to reject OP_CBHV, OP_CBH & OP_BH because of the 10-conf lock. Only mining rewards are locked in such a way. But if we must Hedge our coin by exchanging it for scam-tokens, the time has come to implement a BlockHeight OpCode.

OP_CBHV is most elegant imo because there’s never any need to re-evaluate the mempool. Only CBHV-flagged txns need be deleted, because executing the OpCode guarantees the txn will never be valid ever again.

[bitcoincashautist]

@Tinos

I’d have to suggest cancelling the release of CashTokens. CashTokens might just be a scam.

“It can’t do what I think it needs to do exactly how I think it needs to do it, therefore, it’s a scam.” Great line of reasoning right there.

Pretending AnyHedge could work makes it look like you’re just paving the way for some CashToken version of flexUSD to scam ppl.

AnyHedge already works. It doesn’t even need CashTokens. It needs UX and market makers.

[RowanSkye]

AnyHedge has been working well since 2020 with Detoken before it went out of sync and closed due to a lack of maintenance. And that version of AnyHedge didn’t have Introspection or CashTokens.

@Tinos

OP_CBHV is most elegant imo because there’s never any need to re-evaluate the mempool. Only CBHV-flagged txns need be deleted, because executing the OpCode guarantees the txn will never be valid ever again.

And how do you check if a transaction is CBHV-flagged? Or its descendants?

We all know that BCH has a 10-conf reorg lock, yet we also do know that XEC disregarded it completely when they reorganized their chain just a few months after their split from BCH while they still have the same 10-conf reorg lock that we do.

[bitcoincashautist]

@RowanSkye

And how do you check if a transaction is CBHV-flagged? Or its descendants?

When you validate a TX you have to execute every input’s Script. If the script uses CBHV then all outputs of that TX would be added to some list of immature outputs, same like coinbase outputs are now treated. If we wanted to be consistent it should be 100 blocks to mature, not 10.

So maybe it could work without messing up mempool/scalability, but why would we need that opcode? And if we want to introduce something like it, the <block_hash> <data_element> OP_GETBLOCKDATA would give more bang for the buck.

[ShadowOfHarbringer]

@im_uname

Any opcode that can result in an already admitted tx being evicted from mempool again, for any reason other than fees and congestion, will be terrible for scaling (you’ll have to reprocess the entire mempool every block), and so are unlikely to be adopted. It’s the same reason why CLTV can only do “valid after”, but not “valid before”.

@garlonicon

This is reorg-unsafe. You don’t want to receive a zero-confirmation transaction that will be a child of such transaction. You will have transaction A (valid only in block N) and you will get some coins in transaction B, where A->B. You don’t want to accept transaction B, you can no longer trust zero-confirmation in that case.

I see.

I actually deeply understand the issue, because I am in the process of designing OP_LOTTERY.

A similiar issue appeared there because calculating the result of the lottery in the same block lottery ends, is reorg-unsafe and requires re-calculation of all the possible variants in similar way. Which is why I had to re-design the get-lottery-result algorithm.

So basically, this new opcode would enable some new types of hedge smart contracts, while potentially breaking 0-conf transactions and destroying BCH scaling in the process.

I say strong no.

This is a terrible idea that should just be dropped right now. Scalability of BCH and 0-conf transactions are of the highest importance for Bitcoin Cash. Anything that can damage these two things is a no-go.

[ShadowOfHarbringer]

@Tinos

I believe this may be the most important problem we all need to look at (or at least in the top-5). Ideally devs should just ignore CashTokens until this issue is resolved

No, I believe your entire line of reasoning is wrong.

You also shouldn’t tell any devs what to do in this manner, it is at best impolite and insolent at worst. If you dislike something, code something else yourself. Don’t tell the devs what to do. You’re not the one setting priorities here.

Also read my previous post. Your idea will never make it into Bitcoin Cash because it potentially impedes scaling and can potentially increase the severity of reorgs (due to recalculation of everything every time there is a change on the “block tip”).

Scaling and 0-conf are the 2 most important priorities for Bitcoin(Cash). Actually always were since 2009, some people just were fooled into thinking otherwise.