Brainstorming Consensus Commitment Structure

#1

Right now, we have BIP-34 that enforces committing block height in coinbase input script.
Could we add more to it? I’ve been told it could risk breaking miner software.

What else is there? Bitcoin miners already add an OP_RETURN for SegWit, so can we just add something the same way? Because we know it wouldn’t break anything since they already have to do that for BTC.

Do we just add any fields we need verbatim, or do we just hash it all together and commit something like:

OP_RETURN <version> <hash>

Then we can just keep bumping the version and adding to what gets hashed if we need to commit to more data or ever change the hash function.

What could we be adding here?

Elsewhere I was suggesting to require the commitments OP_RETURN to be the last output so we could have compressed proofs
Today I found an old issue where Bitcoin Core folks were considering to make the same requirement for SegWit and for the same reason, what they called “midstate compression”. They gave up, because it looks like that would break some mining gear :frowning:

Unlike them, we’re doing hard forks anyway, so maybe we could just add a little commitments blob as a leaf into our main merkle tree? To serve as an extended and future-extensible header.

3 Likes
#2

Banger topic. I’ll be interested to see what people come up with. Is there any way we could somehow embed the price in trustlessly - perhaps calculated off chain difficulty as has been discussed before or in some other manner? That would be amazingly useful information.

Difficulty is already stored somewhere, does that fit in here?

I also think some kind of auto-adjusting scheme for the minimum relay fee or dust limit would be good, and perhaps that can use embedded values here like ABLA and the block sizes.

1 Like
#3

You can just calculate it client-side, all you need is headers + coinbases. No need to burden consensus with writing a calculated value which you can trivially calculate from headers & coinbases.

Compressed block target is what’s stored, difficulty is a calculated value.

Yup, we could base it off difficulty, and you’d only need existing headers and coinbases to compute it, as described here.
We already have the data, we just need an algorithm :slight_smile:

#4

I don’t love the idea of making “price” something embedded at the protocol level. It opens up a whole can of worms regarding trust and possible manipulation. In addition, even if we used some “objective” measure of price as some derivation of difficulty ratio between BCH and BTC, to me that reinforces the idea that BTC should matter and that BCH isn’t independent. Finally, there seem to be plenty of good alternatives for people to add price info to the chain through transactions if they want.

2 Likes
#5

It is agnostic of BTC. All you need is 3 pieces of information: BCH difficulty and target time for the block and fee+subsidy for the block.
The DAA is like an AMM for hash market: network bids for hashes (fees+subsidy) and miners sell the hashes (difficulty x time). Every block is a price point for gigahashes/BCH. If you assume a kind of Moore’s law for ASIC efficiency then you get MWh/BCH, just from on-chain data!

It’s off-topic here, so I suggest to move this topic here: Research: Block difficulty as a price oracle

1 Like
#6

OK, perhaps I misinterpreted. If the idea was simply to store a “price” that’s simply a function of BCH’s own difficulty, then I agree with your earlier comment that it’s unnecessary because difficulty is already embedded and anyone can run a function to transform it into some price-like proxy already.

1 Like