[ANN] Cross Check Points - Blockchain of blockchains - ByteSt@mp

[bytestamp]

Several months ago I announced http://www.bytestamp.net in this topic: https://bitcointalk.org/index.php?topic=781281

Now I’d like to talk you about Cross Check Points - Blockchain of blockchains

[size=7pt]-----BEGIN TIMESTAMPED TEXT-----[/size]
What are Cross Check Points?

Well, first of all I think you should know what check points are.

They are explained here, where you can read:

“Every once in a while, an old block hash is hardcoded into Bitcoin software. Different implementations choose different checkpoint locations. Checkpoints prevent various DoS attacks from nodes flooding unusable chains and attacks involving isolating nodes and giving them fake chains, but it is primarily an optimization for the initial blockchain download. Satoshi announced the feature here and it was discussed to death here.”

So, check points are couples of block height and block hash hardcoded into Bitcoin source code.

What is their function?

Let’s imagine a scenario where one organization controls more than 50% of hashing power in the network.
In June 2014, GHash.io reached the 51% of network power and even if they say in a press release that they “never have and never will participate in any 51% attack or double spend against Bitcoin”, the response of the market was a Bitcoin’s continuing price fall.

What’s happened?

Bitcoin lost its feature of being trust-less and so it lost its value. If I have to trust Ghash.io, then I trust my old bank.

And checkpoints?

The function of checkpoints is to prevent (reduce the risk of) a 51% attack, by hardcoding old block hashes in Bitcoin software.

To understand this, we must understand how a 51% attack works.

Let’s imagine to have a huge warehouse full of ASIC miners. Now we keep all this computers disconnected from the Internet and we install on them the Bitcoin protocol, launching the genesis block. All the ASIC miners begin to solve blocks and to produce bitcoins, and obviously we are the owner of all the bitcoins that exist on this parallel Bitcoin network. When our private blockchain becomes longer than the public one, we connect our machines to the Internet. At this point, two Bitcoin blockchain exist on the Internet but the Bitcoin protocol “sees” that our blockchain is longer, so it discards the public blockchain and we become the owners of all the bitcoins of the world.

Is it possible such a scenario?
No.
Why?
Checkpoints.

In fact to do this thing we have to replay all the blockchain, and so each block of our private blockchain will have a different hash of the same block of the public blockchain.
But, because the hashes of this old blocks are hardcoded in Bitcoin software (checkpoints), the Bitcoin protocol will discard our fake blocks.
So, the blockchain can be replayed only until the block height of the last checkpoint hardcoded in the software.

With checkpoints, the Bitcon protocol loses a bit of its peer-to-peer feature, because a developer of Bitcoin software could arbitrarily put a fake checkpoint, if he/she is the same person who holds the 51% of hashing power. So far, a better solution was not found.

So, what are Cross Check Points?

Well, the idea here is to store checkpoints in the Datacoin blockchain instead of hardcoding them in Bitcoin software.

With bytestamp we can have a proof of the date in which a document was made, as you know.
But also the Bitcoin blockchain is an electronic document, so we can use bytestamp the put a timestamp on it.

In other words, what we are doing is to use Datacoin blockchain to notarize Bitcoin transactions.

Because of the nature of Datacoin blockchain, everyone can check that the couples of block height/block hash stored in it are correct. Just like the checkpoints hardcoded in the Bitcoin open source software that you (have not) read and you (have not) compiled.

So, future Bitcoin clients could check block hashes against checkpoints stored in Datacoin, in addition to hardcoded checkpoints.

But the most important consequence of this is that the Bitcoin network becomes more resistant against 51% attacks.

In fact until now, to perfom a 51% attack, you needed the 51% of hashing power of Bitcoin network (and a friend in Bitcoin’s develepor team).

But now, because Bitcoin’s checkpoints are notarized into Datacoin blockchain, you also need 51% of computing power of Datacoin network.

In fact, if you replay Bitcoin’s blockchain changing all its blockhashes, you have to store in Datacoin blockchain new Bitcoin block hashes. But because Datacoin block hashes are computed also as a function of Bitcoin block hashes (i.e. the field data stored in the transactions), you have to replay Datacoin blockchain too.

Now you would say that if anyone has 51% of hashing power of Bitcoin network, he/she could certainly replay the Datacoin blockchain, too.

Well, the fact is that replay Datacoin blockchain is not so easy.

Let me elaborate.

First, Proof-of-Work of Bitcoin (SHA256) is different from PoW of Datacoin (Prime numbers). Yes, you can have A LOT of ASIC miner that could give you more than 50% of hashing power of Bitcoin network. But all the ASIC miner of the world togheter won’t give you one Cunningham chain (that is Datacoin PoW). So if one organization has 51% of Bitcoin hashing power, it is not to be said it has 51% of Datacoin computing power, too. Indeed it’s unlikely.

But, most important, Bitcoin blockchain and Datacoin blockchain are mutually enforced with other crypto-currencies against 51% attacks.

Let me explain.

If you go to Bytestamp Cross Check Point section, you can see two table.

Let’s look the first table, for now. It gives you a list of others crypto-currencies which checkpoints are stored in Datacoin blockchain.

The last row of this table tells you that the block 342867 of Bitcoin blockchain, was stored in Datacoin Transaction ID c1f3fb9597edeac651f0fc544511ea3c63129735e8c6af80330cf6c5be5ef292

In fact, if you open that datacoin transaction (by clicking the above link, or by Datacoin block explorer) in the data field you find:

http://www.bytestamp.net/c/BTC/342867/000000000000000010e0755a91b4e924373fc0156d4f9eb0af3a5e8ecd3914f4

This is an URL (that you can visit to obtain more info about BTC block 342867) that contains:
Crypto currency symbol (BTC)
Block height
Block hash (of that block height)

So this is a Bitcoin check point because the URL contains a couple of block height and block hash from Bitcoin blockchain.
Because this BTC block height and block hash is stored in that Datacoin transaction, and because that transaction was confirmed on 2015-02-10 18:02:48 UTC in Datacoin block number 702345, than that is the proof than at that time the Bitcoin block height 342867 had to be solved with hash 000000000000000010e0755a91b4e924373fc0156d4f9eb0af3a5e8ecd3914f4. In fact from Bitcoin blockchain we can see it was solved on 2015-02-10 13:28:52 UTC.

Now, you have to consider that when Datacoin block 702345 was solved its hash was also calculated as a function of its field data that contains a block height and block hash of Bitcoin blockchain. Besides, each block hash also confirms the previous block hash, as you know. So we can say that Datacoin block 702345 not only confirms Datacoin blockchain until block height 702345, but it also confirms Bitcoin blockchain until block height 342867.

If you want to replay Datacoin blockchain you must also replay Bitcoin Blockchain in order to obtain a Bitcoin block hash of BTC block height 342867 compatible with the new Datacoin Block hash of DTC height 702345 that you have falsified.

And, as above, if you want to replay Bitcoin blockchain, you also have to replay the Datacoin Blockchain.

But, as you certainly have seen, we store in Datacoin Blockchain also others crypto-currencies check point. There are Primecoin (PoW: Cunningham chains), Litecoin (PoW: scrypt) and Blackcoin (Proof-of-Stake instead of PoW). And we could add others.

So we can say that Datacoin block 702345 not only confirms Datacoin blockchain, but also confirms Bitcoin, Primecoin, Litecoin and Blackcoin blockchains.

Now if you want to replay Datacoin blockchain, you also have to replay Bitcoin, Primecoin, Litecoin and Blackcoin blockchains. Good Luck.

It’s for this reason that when we speak about Cross Check Points we could also call them Blockchain of blockchains.

A side effect of Cross Check Points are the number of confirmations of each transaction. Some people consider a Bitcon transaction as final only when it reaches 6 confirmations.
But if we consider Cross Check Points with others blockchains, we reach these 6 confirmation faster.

When Bitcoin network solved block 342870, the Bitcoin block 342867 had 3 confirmations. But in the meanwhile, Datacoin network could have solved block 702349, and so Datacoin block 702345 had 4 confirmations. But because Datacoin block 702345 also confirms Bitcoin block 342867, we could say that Bitcoin Block 342867 had 3 + 4 = 7 “mixed confirmations”.

But the crazy thing here is that we not only store Bitcoin, Primecoin, Litecoin and Blackcoin check points into Datacoin blockchain, but we also do the reverse, by storing Datacoin checkpoints into others blockchains.

In fact the Blockchain is so called because it is a chain of blocks: each block confirms itself and the previous one. So, looking at the above table, we can say that the hash of DTC block 702346 confirm block 702346 and block 702345, which in turn confirms Bitcoin, Primecoin, Litecoin and Blackcoin blockchains.
And we can say the same thing of block 702347 confirming 702346 and than confirming again 702345.
And we can say the same for block 702348, 702349, and so on.

So each subsequent block confirms all the previous blocks, including the block 702345 that confirms Bitcoin, Primecoin, Litecoin and Blackcoin blockchains.

We can continue to count up to, for example, the Datacoin block height 704046, and say that it confirms all the previous blocks (including 702345 that confirms others blockchains).

Now let’s see the second table that you can find at Bytestamp Cross Check Point section.

This table gives you a list of Datacoin checkpoints that are stored in blockchains of other crypto currencies.

For example, the last row tells you that Datacoin block height 704046 with its hash is stored in Bitcoin transaction ID 57febc0771c370ab51610f016dddcb9a816a309e4c0643f924c77a303a3b6805.
If you call this Bitcoin transaction at Blockchain.info, you can see it was confirmed in Bitcoin block height 343034 at 2015-02-11 17:40:57.
But because in this Bitcoin transaction is stored block height and block hash from Datacoin blockchain, then that block height and hash obviously had to exist at 2015-02-11 17:40:57, in fact Datacoin block was solved at 2015-02-11 12:25:09 UTC.

But, as above, the hash that solves Bitcoin block 343034 was computed also as a function of Datacoin checkpoint in it stored. So we can say, this time, that Bitcoin blockchain is used to notarize Datacoin blockchain, which in turn was used to notarize Bitcoin blockchain, as above. In fact if you want to replay Datacoin blockchain, now you have to replay also all the Bitcoin blockchain, to make sure that new hash of your fake Datacoin block height 704046 is compatible with a new hash of fake Bitcoin block height 343034.

And yes, you guessed it.

We put Datacoin block height 704046 with its hash also in Primecoin, Litecoin and Blackcoin blockchains, at transactionIDs shown in table.

So we have four (at moment) different blockchains that are used to notarize Datacoin blockchain that in turn is used to notarize the same four different blockchains. OK, Datacoin is used to notarize documents as well.

The result of this job is that if anyone wants to alter the blockchain of any of these crypto-currency, is no longer sufficient to have the 51% of power computing of that crypto currency, but is needed the 51% of power computing of ALL of these cryptocurrencies togheter.

So, anyone wants to perform a 51% attack against Bitcoin? Well, he/she needs 51% of power computing of Bitcoin network + 51% of power computing of Litecoin network + 51% of power computing of Primecoin network + 51% of power computing of Blackcoin network + 51% of power computing of Datacoin network.

Obviously, all this work is useless if someone else does not develop a software client that checks block height and hash against the checkpoints stored in others blockchains.

But if we will use cross check points, Bitcoin should become more secure and therefore have a more stable value on the market.

And others crypto-currencies involved will become safer, too. Do yo want to falsify the date of a document timestamped with http://www.bytestamp.net? OK, first you have to replay Bitcoin, Litecoin, Primecoin and Blackcoin blockchain…

But we missed a particular.

How are Datacoin checkpoints stored in others cryptocurrencies blockchain? In fact, unlike Datacoin, other cryptocurrencies do not have the field data in their transactions.

Well, the technique is to “burn” some bitcoins (or litecoins, or blackcoins, or primecoins) by sending them to nonexistent addresses containing Datacoin checkpoints.

I think this same technique is used by site Cryptograffiti, that “offers a functionality to encode custom messages as bitcoin addresses and import them to the wallet for storing text into block chain.”

Visiting their site, you can read all the messages hidden in the blockchain. So you can also read the message we put containing Datacoin checkpoint. For your convenience we report Cryptograffiti ID on the table above. If you open that cryptograffiti ID , you can read:

http://bytestamp.net /c/DTC/704046/2ee912 57b0f9eb0fe368a9e9ee 5e47ec12ae78d4191f82 327159b496d02ef7cd

That is an URL split on 5 rows. Again, because this URL contains block height and block hash of DTC (datacoin), this is a proof that at time of this Bitcoin transaction this Datacoin block height with its hash had to exist.
You can paste this URL on your browser to see details about Datacoin block 704046.

And what about others crypto-currencies?

Well, I do not know of a service like Cryptograffiti that does the same thing on Litecoin, Primecoin, or Blackcoin blockchains.

But the Datacoin checkpoints (as well as others messages hidden in the blockchain) are stored in the blockchain as human-readable characters.

So, if you download one of these blockchains (as well as Bitcoin blockchain) on your computer and you open it with an Hex editor, you can find somewhere these strings.

If you use Linux, you can use its command strings.

For example, if you have the Litecoin client installed, you already have downloaded all the Litecoin blockchain.
Now go to the directory where blockchain is saved (usually /home/user/.litecoin/blocks) and launch the command

strings blk*.dat > crosscheckpoint.txt

Now open crosscheckpoint.txt with a text editor and find for the text “bytestamp”. You may to search more then once, as I did same tests.
As you can see, Datacoin checkpoints are already saved on your local hard disk!

So we can say that there is no longer the risk of a 51% attack?

Well,with Cross Check Points this risk can diminish but not disappear completely.

To reduce the risk as much as possible we should store checkpoints into blockchains as often as possible.

But each time we store checkpoints we spend datacoins and we burn litecoins, primecoins, blackcoins, and, primarily, bitcoins.

So if you like this idea and you think cross checkpoints should be make more often, please consider donating.

http://www.bytestamp.net
14/2/2015
[size=7pt]-----END TIMESTAMPED TEXT-----
The file is timestamped at UTC Date/Time: 2015-02-14 14:43:15 UTC
with 1 confirmations in block number 709421 - ID transaction: 2edb9d761d06f3102cb2f3ac1ae90327626b027f94229b6842423d6273fd09d8
info
[/size]

Donations
BTC: 1Kua7FySPXQhH2XaW6LryZkPPnuejC2jc3
LTC: LgZjKX7paxeLPNsScxx1AWfHM23x7pFipw
DTC: DEVF4ej7TLi5R4FaXBYfdkbg6BmKZXkZQd
XPM: AVBEEMQ6QVomn98bszYuW13stUXUgJLfTj
BC : B7tbFWnJmt9U16Sgu6du6cZuCjBvEsDu8s

[Fuzzybear]

fuzzy@anonymized.invalid

[bytestamp]

Hi, thank you for your interest!

[quote=“FuzzyBear, post:2, topic:3333”]very interesting and great to see primecoin being used by bytestamp and would like to see peercoin added to your list of currencies supported.

Couple of questions:

1. How do you protect against someone inserting false info in a crosscheckpoint.txt?
2. This will no doubt add to the blockchain size but as a checkpoint and cross checkpoint this is perfectly valid and good use of the blockchain, but what stops someone spamming checkpoints to bloat the blockchain?
   2b. Is there a way to prune or remove bad / spam crosscheckpoint.txt?[/quote]

Well, first thing take in mind that all the system, at the moment, has to be seen as a “second opinion”. Ie you always have checkpoints hardcoded in your source code, but you now have also cross check point.

Please note that crosscheckpoint.txt is just a name file for strings extraction in linux, we could have been call it donald_duck.txt as well.

About question #2 I was thinking about a solution, too.

The first thing I thought is to digitall sign messages in blockchain, ie by PGP.

So Bytestamp as its own digital signature, FuzzyBear another digital signature and so on.

Each of us put checkpoints in the blockchain and sign them. If anyone will trust FuzzyBear, he/she will choose only his checkpoints and he/she will discard bytestamp’s ones.
I think this is the only solution, but I don’t like it because it’s based on trust (just like current checkpoints hardcoded in the software)

Another way could be to store into the blockchain checkpoints that come from several sources. So not only bytestamp and FuzzyBear, but anyone running the protocol software on any cryptocoin will store checkpoint in the blockchain. So if in the blockchain there is a transaction that says with block 1 solved by hash abab and there are 1000 transactions that say block 1 solved with bcbc we know that bcbc is the right hash of block1. Yes, an attacker could write 1000 times in 1000 transaction it’s fake block hash, but if you think that this is an expensive operation, he/she could not have so much money and, if he/she has, the risk is high.

This is a decentralized solution that works until the network is decentralized. If there are only few users, the attacker could have enough money to buy fake transactions.

Anyway nothing that is stored in blockchain can be prune. The only way is to establish a rule for discard some transactions.

@FuzzyBear

3. the hard coded checkpoints in the code are from blocks that are from points confirmed as being on the main chain as they are from a while ago. 51% attacks occur by gaining control of the current block and previous 4+ blocks, what is to stop the attacker sending a checkpoint.txt at that point with their starting block to confirm the main chain and agree with all current blocks on primecoin, datacoin etc?

Checkpoints are read from the local blockchains and then stored into (other) blockchains. So I read on my local blockchain that block 1 has hash 0a and I write this in the other blockchain. The attacker sends another checkpoint stating that block 1 has hash cb. So we find in the blockhash two times block 1, one with hash 0A and one with hash CB. Even if we don’t know who is right, we understand that something does not work. We could solve the problem of who’s right with PGP or with a decentralized system, as above. But yet now we understand that someone is doing a “bad thing”.

@FuzzyBear

4. have you tested this with testnet and performing various attacks? Have you tested with an attacked coin or launched your own coin with the feature to see if prevents attacks in early stages of coin?

I do not have the skills to do this. I launched the idea, now I wish that someone else could help.

BTW I think that Cross Check Points could protect a coin in its early stages. If we store in another blockchain the checkpoints of a new coin and an attacker (of the new coin) set up a parallel blockchain, having all the checkpoint stored (good and bad) we can rebuild the legitimate blockchain.

For example I store in Datacoin blockchain the new coin block 1 at time 1 and the block 2 at time 2. If then comes block 1 at time 3 than this block is fake. This assumes that genesis block was launched by legit user.

At this point all blocks wit hashes compatible with block 1 at time 3 are fake, even if they come first and even if they are on the longest branch of the blockchain.

@FuzzyBear

5. What are your logs like for seeing false chain information on the network? basically, does this help you monitor in real time when an attack is happening or some suspicious activity happening on the network, or is this just stamping “good” data into the blockchain to prevent bad data getting in?

Yes! This is just what it does, as above. Because no data from blockchain can be deleted, if I store first block 1 with an hash and then with another hash, than something bad is happening on the network. And we can use previous data of old checkpoint to understand what’s happening.

When I started with Bytestamp I did the first Datacoin block explorer.

A that time, something strange was happening on the Datacoin network, becaus chunks of 1000+ blocks got orphaned, and hashes of found blocks changed.

Then I began to keep track of the “history” of each block. For example, if you open the Datacoin block 709640 on the block explorer, at the bottom of the table you can see “Block History”. By clicking on it you can see all versions of that block, from the first time it was seen until it reached 10 confirmations.

As you can see, the block hash is always the same. This means “all good”.

But if the first versions of block differs from the last ones, this could means that someone is doing double spending. But also can mean that we are on the wrong branch.

At this point, further analysis is required. Does this happen only with some blocks or with all blocks? Does this happen only in certain hours? Who is mining at that time?

We can understand all these things because all is logged.

As far as Datacoin network had no more problems…

The downside of cross check points is that to reduce the risk as much as possible we should store checkpoints into blockchains as often as possible, as I stated in my previous post.

This is not done at moment because it is an expensive operation.

I think that the time between when a block has been solved and when it is stored in the blockchain of Datacoin is the time in which an attacker can do the double spending without that no one notices.

Thanks.

[bytestamp]

[quote=“FuzzyBear, post:2, topic:3333”]1. How do you protect against someone inserting false info in a crosscheckpoint.txt?
2. This will no doubt add to the blockchain size but as a checkpoint and cross checkpoint this is perfectly valid and good use of the blockchain, but what stops someone spamming checkpoints to bloat the blockchain?
3. the hard coded checkpoints in the code are from blocks that are from points confirmed as being on the main chain as they are from a while ago. 51% attacks occur by gaining control of the current block and previous 4+ blocks, what is to stop the attacker sending a checkpoint.txt at that point with their starting block to confirm the main chain and agree with all current blocks on primecoin, datacoin etc?[/quote]

I would like to add that there is already a way to discard fake checkpoints in blockchains.

In fact checkpoints are stored in the form:

http://www.bytestamp.net/c/BTC/342867/000000000000000010e0755a91b4e924373fc0156d4f9eb0af3a5e8ecd3914f4

and if you visit this link bytestamp gives you information about BTC block 342867, it’s time, etc. as you can see below

Now, an attacker could also store in the blockchain false check points, but if you follow the links bytestamp will give you errors.

In fact, you can have 3 cases:

The attacker writes a block that does not exist, like

http://www.bytestamp.net/c/BTC/MyFakeBlock/Hash

But if you follow it, you get an error because the block was never stored in blockchain by bytestamp:

The checkpoint could be or could not to be a fake. The couple of block height and block hash could also be correct, but this info was stored in blockchain by someone else, not by Bytestamp. And if someone else writes correct checkpoints in the blockchain, why use http://www.bytestamp.net as url?

Ideally, if we write all blocks, this error never occurs. But as said, we can’t write all blocks because it’s expensive.

the attacker writes a block that exists, but with a different hash because he/she is doing a double spending and so he/she writes his fake block in blockchain (your #3 question). Something like this:

http://www.bytestamp.net/c/BTC/342867/MyFakeHash

If you follow this link, you have an hash mismatch error:

Because you requested a block with an hash different from the one written in blockchain by bytestamp.

The hash could be a fake, but case #2 could also evolve towards case #3 …

In the blockchain there is the hash

http://www.bytestamp.net/c/BTC/342867/000000000000000010e0755a91b4e924373fc0156d4f9eb0af3a5e8ecd3914f4

that is correct, but before THE SAME BLOCK was stored in the blockchain by Bytestamp with ANOTHER hash.

In this case following the link you have a double hash error, with the old version(s) of the block:

This means that at first bytestamp itself was on the wrong branch of blockchain, then it went on the right branch. We could say Bytestamp was on the fake branch made by attacker.
But storing the previous blockhash we can notice that something does not work.

BTW, all these ways assume that you trust bytestamp.

Thank you.

[bytestamp]

@FuzzyBear

5. What are your logs like for seeing false chain information on the network? basically, does this help you monitor in real time when an attack is happening or some suspicious activity happening on the network, or is this just stamping “good” data into the blockchain to prevent bad data getting in?

look here