Genesis block message

Development and Technical Discussion
1

We all know what the bitcoin genesis block says about wallstreet / bank bailout. What will be the timeless message of gringots, have you any idea? we need a solid quote or something.

The best quote is quite long, maybe an exception as to the length of the message in the genesis block can be secured.

“Enter, stranger, but take heed
Of what awaits the sin of greed,
For those who take, but do not earn,
Must pay most dearly in their turn.
So if you seek beneath our floors
A treasure that was never yours,
Thief, you have been warned, beware
Of finding more than treasure there.”
― J.K. Rowling, Harry Potter and the Sorcerer’s Stone

“remember to wake devs from cryostatis in the year 2500 so that they can add big numbers to the source code”
― Harry Potter

2

It makes me a little sad but it doesn’t seem that we’ll be able to embed any text in our genesis block. Somewhat by design, all the data is obscured and there are no “open fields”.

2 Likes
5

We can put in a hash of any text we like as the prevhash (which would otherwise be 0).
That’s as good as putting the text itself in…

2 Likes
6

That won’t allow the whole qoute would it?

It would allow - THOSEWHOTAKEBUTDONOTEARNMUSTPAYMOSTDEARLYINTHEIRTURN

Or we could sneak in a message for Lord Voldemort from Harry Potter

but I believe that igno.peverell should call the shots and choose the best one.

7

I believe that what tromp meant is that it is possible to hash a message and put that hash as the first prev-hash, which is different from using the 32 bytes of the field as 32 characters and removes the restriction on the size of the message. It could then be the hash of all 7 JK’s books concatenated.
Or something more meaningful. Maybe we can wait for WW3 to launch Grin ?
“Chancelor on Brink of a Third World War”

8

I like having the previous hash be all zeroes. Makes it nice and explicit that this is the genesis block.

2 Likes
9

I agree having a 0 prevhash is a very desirable feature. Which leaves only a few places to put in the hash of a freely chosen text. One such place is the blinding factor of the coinbase. Which means the message could only be revealed once that coinbase is spent. Possibly (perhaps Yeastplume can confirm) it could also be injected into the coinbase rangeproof.
Any other places anyone can think of?

10

I’d be a special case in the code, but it could absolute be XORed into the bulletproof. It only uses 8 bytes of a max 64 bytes at the moment to store the amount.

11

@Yeastplume @harry.potter

I’ve spent a lot of time thinking about this in the course of a paper I am writing on Bitcoin timestamping and use of the Bitcoin blockchain for time-based proofs (trustless notary clock).

I strongly advoate that the genesis message be the hash of the latest bitcoin block. Forget my laziness, I will simply copy a passage from my upcomming article to justify this opinion.

What you are trying to do is a proof of absence. Essentially you are trying to prove that there was not a secret pre-mine. A good proof-of-absence has three features:

  • It cannot be guessed in advance
  • It is immutable
  • It is universally and independently verifiable

The only piece of data that satisfies these criteria (or that does it the best) is bitcoin block hashes

"Proof-of-absence: an overview

A proof-of-absence process involves finding a temporal marker and cryptographically associating it to a message or piece of data using a digital signature process. Digital signatures are what allows us to cryptographically bind the proof-of-absence time-marker to a message or data that is later timestamped in the Bitcoin blockchain. The digital signature is not just a step in our process: it is the objective of the process.

First, we need a piece of data to act as a temporal marker with two specific properties: it cannot be guessed in advance and it is publicly verifiable.

Bitcoin block hashes are perfect because they are both impossible to guess in advance but also trustlessly verifiable using open-source software. The Bitcoin blockchain is immutable and distributed, which makes it a reliable source.

Traditionally, a common technique has been to use newspaper headlines, such as in “proof-of-life” evidence generation, where hostages are photographed or filmed holding a recent copy of a newspaper to prove that, at least until the day the newspaper was printed, they were alive.

Satoshi Nakamoto, the inventor of Bitcoin, used this technique himself when he mined the first block of the Bitcoin blockchain, referred to as the Genesis Block. According to the Bitcoin protocol, a miner can include arbitrary text in a block he is creating which, if included in the blockchain, will be permanently recorded for all the world to witness. In the case of the Genesis Block, Nakamoto included the message: “The Times 03/Jan/2009 Chancellor on brink of second bailout for banks.” On January 3rd 2009, The Times newspaper published a frontpage article with the headline “Chancellor on brink of second bailout for banks”

The reason Satoshi Nakamoto included a newspaper headline in a Bitcoin block is of course to prove that he did not mine this block prior to January 3rd 2009. Indeed, Nakamoto could have mined blocks of the bitcoin blockchain long before this time, accumulating proof-of-work without giving the opportunity to others to engage in the process, which is often called a premine. All of the bitcoin transactions are part of a shared history which provably starts, at the earliest, on January 3rd 2009.

There are two major problems with the use of newspaper headlines, which highlight why our proposed method of using bitcoin block hashes is far superior. Firstly, newspaper headlines are by definition trusted third parties, and they are subject to collusion and manipulation. The process of generating newspaper headlines is not auditable, and is certainly not trustless.

Did Satoshi Nakamoto bribe James Harding, editor of The Times in 2009, to publish at an agreed-upon time in the future the headline “Chancellor on brink of second bailout for banks” in order to gain a secret unfair advantage over future users of the Bitcoin protocol? This is extremely unlikely, but it is certainly possible.

Second, temporal markers also need to be publicly and independently auditable. They should be immutable, tamper-resistant and distributed to remain auditable for extremely long periods of time. Online news headlines, for example, are not immutable nor tamper-resistant. If The Times newspaper had been only digital, it would have been trivial for them to retroactively modify the headline. To some degree, physical newspapers can be widely distributed, but not for long periods of time, as inevitably the evidence physically disintegrates, gets destroyed and disappears. For example, it is practically impossible today to find a physical copy of the famous January 3rd The Times paper. If The Times’ website goes down without a proper trusted archive (and assuming it is not corrupted) then physical papers would be the only method for future generations of verify the proof-of-absence of Bitcoin’s genesis block. Of course there are methods to mitigate this, such as distributed archives and timestamping using the OpenTimestamps protocol: but they inevitably also use the Bitcoin blockchain to achieve the level of security and certainty, so it makes sense to simply use the bitcoin block headers directly.

Bitcoin block headers cannot be guessed in advance since they are created from the random entropy of Bitcoin transaction data. If one includes the hash of a poem in a Bitcoin transaction, the hash of the bitcoin block will be generated using, in part, this data. The Merkle root and Bitcoin block hash could never have been created if that specific data hadn’t been included in the transaction. Because anybody can write into the Bitcoin blockchain, it is impossible to guess what data will be included in the next block, and consequently it is impossible to guess future block hashes.

But couldn’t attackers collude with miners to generate, in advance, a particular block hash by changing the block’s nonce in order to defraud a proof-of-absence? This question is very legitimate because Bitcoin miners are in fact constantly trying to create a specific block hash by hashing the block data and changing a nonce in that data in order to obtain block hash which starts this a required amount of zeroes. The amount of zeroes is the bitcoin difficulty. If a miner wanted to mine a specific hash in advance, she would essentially be mining at the highest difficulty possible, since she’s looking not only for the first few numbers but in fact the entire hash. It is practically impossible for a miner to mine a specific block hash, since the difficulty is so high that she would never find a valid block matching her specific block hash as other miners mining at the lower, normal difficulty would inevitably find them much faster. Of course, attempting this impossible task would also cost the miner trying to collude not only the direct costs of mining but also the opportunity cost of not earning Bitcoin rewards.

Bitcoin block hashes are easy to independently verify. To do so, someone simply has to download the Bitcoin core software. The software will request a copy of the blockchain from peers. Using the “getblock” function of the Bitcoin software, anybody can look up the bitcoin block hash. The software will return information on this block, which includes its height and also the timestamp. Because of the Bitcoin consensus process, we know that all Bitcoin software will have the same copy of the blockchain. The Bitcoin software will know if the hash does not exist.

The Bitcoin software code itself is open-source and cryptographically signed by the Bitcoin Core developers and can be independently audited which provides a complete level of certainty. Alternatively it is possible to used a third-party block explorer to look-up a block hash, but in this case you are trusting a third-party (the person or company operating the block explorer)."

5 Likes
12

In principle, I agree. But practically it conflicts with another requirement: the genesis block itself needs to be pre-mined. And that’s somewhat required to avoid something closer to “instamine” (unless we cheat in some other way).

We need to initialize the chain with a high enough difficulty so that the first few thousand blocks don’t get mined within minutes. How high exactly is hard to tell, but as high as possible is probably the best estimate we can come up with. This means the proof of work on the genesis block needs to satisfy that difficulty. And computing that PoW is going to take us weeks, maybe a month.

There’s one possible solution: allowing the genesis block to not satisfy the initial difficulty. However we find this somewhat distasteful, especially for @tromp.

13

as high as possible is probably the best estimate

Why? I can understand not setting it to 0 sure, but why not copy the testnet state or watch other coin starts and make an estimate that way

14

A GTX 1080 ti is around 32MH/s mining Ethereum. The total Ethereum hashrate is about 260,000 GH/s. That’s the equivalent of about 8.1 million such graphic cards. Let’s double this to account for other chains, and assume that 0.5% of that will want to give a shot at mining grin for a bit. That’s a conservative estimate of 80,000 GPUs that could be mining on mainnet at launch. For reference, when Zcash launched, it wiped out about 45% of Ethereum’s hashrate.

Now assume we can only get together 20 GTX 1080 ti to work on the genesis block. Those 20 will need to work for 80000/20 = 4000 minutes, or over 2.5 days, to build a single valid genesis.

15

Interesting post regarding using another blockchain as the genisis reference. There was a recent discussion about a similar topic with regard to ‘hybrid’ coins (POW/POS) utilising the BTC blockchain as a ‘immutibility’ reference marker.

One question I have from this; does the mimble wimble protocol allow confirmation of ‘current total supply’? Or can it only ever be estimated from mining estimates? Can the math be backwards compatible to confirm total outstanding supply?

16

As I understand it; it will be possible to make a very highly accurate estimate as the mining reward must be known, however small amounts of coins will get destroyed in standard transactions as a privacy measure. It should be 99% accurate just to add up all the mining rewards

17

Yes, ECC curve points addition (and subtraction) allows you to validate both that each block have the expected additional supply and that the total supply since the beginning of the chain is what’s expected as well. Every time a new node syncs, total supply is checked.

18

Hi there, this is interesting topic.

How about hiding the proof of absence in coinbase tx of first block? Would it be possible? Perhaps making the first coinbase tx unspendable, I think it would be worth it for the cost of proof that there was no pre-mine…

How about this:

When we are ready for mainnet launch, a modified grin node will be deployed on known address. This modified node will periodically check for last bitcoin block and include its header hash as coinbase for potential genesis grin block. It will also have hardcoded difficulty that the pow needs to satisfy. Volunteers among us, willing to donate GPU power will be running GPU miners connected to this node. When this modified grin node detects new bitcoin block, it behaves as if grin block is found, changes the coinbase transaction and sends “new job” message to miners, so they start mining with new pre_pow… When someone is enough lucky and finds pow with satisfying difficulty, modified node will notify Igno and he will publish genesis block and announce mainnet launch via announced channels?

This would allow anybody check that the genesis block was published in short time window relative to certain bitcoin block, and we would also have pow with big enough difficulty.

Disadvantage is that there would be no exact known date of launch.

1 Like
19

Thinking about it more, the strategy I outlined might perhaps solve also the instamine problem : In the modified grin node, we could hardcode the desired pow difficulty of genesis block to be really high, much higher than few developers with GPUs can hope to achieve.

If there are some serious miners with mining farms waiting to mine Grin, they might do this for us - try to find the pow for genesis block. Their incentive is that they would basically decide about the mainnet launch, which gives them advantage - making their farm ready and such.

Modified Grin node would still be under our control, and pow would be only valid for 10 minutes or so (until next bitcoin block is detected), so the miner cannot pre-mine.

If no big miner takes on that, difficulty could be decreased iteratively…

1 Like
20

The problem is not that we don’t have enough GPU power for finding the first block. The problem is to find the correct difficulty for the first block. What is too big for GPU farms ? What is too small ? That’s the difficulty.
We have no idea what is the amount of hashpower that will come to Grin at time t=0.

21

Yes so that is what I addressed in my second post. We can open the genesis hunt for mining farms and go with target difficulty from top (30% of Eth hashrate?) gradually down, until some miner will find genesis satisfying such difficulty.

3 Likes