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

[sampei7777]

This is NOT a new alt-currency !

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

-----BEGIN TIMESTAMPED TEXT-----
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:

Code:

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

Code:

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
-----END TIMESTAMPED TEXT-----
The file is timestamped at UTC Date/Time: 2015-02-14 12:10:40 UTC
with 3 confirmations in block number 709250 - ID transaction: 089bf898715e35abd825dc3f191b6acdf6a941be1d2d0d3efca2510cd73fcb81
info



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

[Shadow_Runner]

wat

[crypto4jan]

It is not easy to follow but I think this is a great innovation for sucuring the blockchain of many cryptocurrencies.
It is also a good reason to reanimate datacoin and give it much more value then it has now.
I'm not a crypto expert but it sounds logical for me.
I hope you can also sucure EnergyCoin in the DataCoin blockchain.

[GameKyuubi]

Finally some real innovation again.  This is incredible and I hope it catches on.

[crypto4jan]

I hope someone can confirm that this application for Datacoin is real and solves the 51% percent threat of Bitcoin or other coins.

[GameKyuubi]

Makes sense to me.  Store the BTC blockchain hash in the DTC blockchain and you'd need to 51% both blockchains in order to rewrite any of them.  Add more blockchain hashes and it becomes essentially impossible to 51% any of them because you'd need to 51% all of them.  Brilliant.

[crypto4jan]

Makes sense to me.  Store the BTC blockchain hash in the DTC blockchain and you'd need to 51% both blockchains in order to rewrite any of them.  Add more blockchain hashes and it becomes essentially impossible to 51% any of them because you'd need to 51% all of them.  Brilliant.

If it is realy true then DTC2moon.

[GameKyuubi]

If it is realy true then DTC2moon.

It still has to be implemented in the wallets that will use crosschecking.

[safetybitcoin]

A very clever idea.
But she is already in operation Dev. Or in the testing phase?

[GameKyuubi]

A very clever idea.
But she is already in operation Dev. Or in the testing phase?

It's already in operation on the DTC side.  The examples OP gives above are already in the DTC blockchain.  It's up to the other coin devs to implement the protocol in their wallets at this point.

I have a question for OP.  How would a wallet distinguish checkpoints for its own blockchain?

[pineapples]

what it needs is a reliable copy of the BTC blockchain that matches the DTC input.
one or two nodes .


it'd be pretty funny if there was a succesful attack, and all that was left of the "real" chain was a few hashes in DTC.

--

i have recently been reading that op_return is a more useful way of storing data in the BTC chain.
gives 40 bits of data, and is not held in memory as an unspent transaction.

[GameKyuubi]

What if there are fraud hashes?  What prevents a 51%ed chain from using DTC in the same way?

[sampei7777]

Thank You to everybody and

Thank You for your interest in Cross Check Points

I will try to answer to all your questions, if I can.

I hope someone can confirm that this application for Datacoin is real and solves the 51% percent threat of Bitcoin or other coins.

Well, the application is real and working, but it does not solve the 51% threat, as stated. It only  reduce the risk of 51% attack.

It's just like your antivirus that reduce the risk you can infected, but you are always exposed to a 0 day attack, for example.

51% attack cannot be solved, because it is intrinsic in the nature of PoW. Neither Satoshi Nakamoto could solve it...

I have a question for OP.  How would a wallet distinguish checkpoints for its own blockchain?

Because it recognizes its own label. The checkpoints are stored in a form of an url that contains the label of the currency.

If you go to http://www.bytestamp.net/c/index/en and you click on the datacoin transaction ID of the Bitcoin row, you can see the data stored in this DTC transaction that is:

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

But if you, instead, from the same page click on the corresponding DTC transaction of the Litecoin row, the data stored in this  DTC transaction is

http://www.bytestamp.net/c/LTC/726829/746417eb708bb5fc72f30f1450c8e778989c4e50aa605c9fb952773dccf27916

So Bitcoin clients should consider only checkpoints under bytestamp.net/BTC and Litecoin clients only those ones under bytestamp.net/LTC

The other two parts are the block height and its hash.

i have recently been reading that op_return is a more useful way of storing data in the BTC chain.
gives 40 bits of data, and is not held in memory as an unspent transaction.

Yes, I know this and it is possible that I could use OP_RETURN in the future.

But let me say a few things about OP_RETURN

1) It is limited to 40 bytes and only one OP_RETURN is allowed for transaction. In order to store something like

http://bytestamp.net/c/DTC/704046/2ee91257b0f9eb0fe368a9e9ee5e47ec12ae78d4191f82327159b496d02ef7cd

we need 98 bytes. This means I had to split the checkpoint across 3 transactions, and you would have read

Code:

http://bytestamp.net/c/DTC/704046/2ee9

in a part of the blockchain,

Code:

1257b0f9eb0fe368a9e9ee5e47ec12ae78d419

in another part of the blockchain, and

Code:

1f82327159b496d02ef7cd

in another part.

So what checkpoint is this? One could also put togheter transactions not related to a checkpoint and do a fake checkpoint.

While in one transaction I can put a lot of addresses one below the other, and now you can read

Code:

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

2) With OP_RETURN bitcoins are no lost, that is true. But I have always to send the minimum TX FEE, that goes to the miner. But I already spend this amount, so does not change anything from my point of view.

I notarize transactions, so I should be payed for this (just as like as a miner).
I should not have to pay for this.

3) OP_RETURN was introduced in Bitcoin client 0.9, I think. So I suppose it is not a feature of Blackcoin, Primecoin, Litecoin that were forked before from Bitcoin. So using addresses instead of OP_RETURN I can keep the same approach with all cryptocurrencies.

4) Besides using addresses you can read checkpoints by cryptograffiti site that is independent from bytestamp. I don't know if their system is also compatible with OP_RETURN.

what it needs is a reliable copy of the BTC blockchain that matches the DTC input.
one or two nodes .

it'd be pretty funny if there was a succesful attack, and all that was left of the "real" chain was a few hashes in DTC.

What if there are fraud hashes?  What prevents a 51%ed chain from using DTC in the same way?

Well, there is no way to prevent someone to store fake checkpoints. And there is no way to delete a fake checkpoint (or any other thing) from blockchain.

But there is 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:

1)
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.


2)
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. 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 ....

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.


You can see this in action at http://www.bytestamp.net/c/block where are stored the latest blocks of several crypto currencies. Each block has a block history link that say you what was the hash of the block before. If a block had a different hash, let's say, for the first 4 confirmation then could have happened a double spending.
It's a tool to monitor in real time when an attack is happening.


BTW, all these ways assume that you trust bytestamp.


Let me say, besides, that with cross check points the Datacoin blockchain is secured into Bitcoin one.

This is already true.

So each file that has been timestamped by bytestamp, now has all the power of all Bitcoin miners that keeps its hash secure.

Thank You.

[najzenmajsen]

wat

indeed , alot of text i had to read it 2-3 times untill i understood it correctly , dev you should probably make a easy to understand video.

[pineapples]

i guess another problem is that in the event of a minor occurence of two split chains.
when both chains meet and sort themselves out, the hash from the wrong chain could end up being stored.

[provenceday]

wow, that's a nice idea!

hope you can continue this innovative idea.

[K1773R]

wat

indeed , alot of text i had to read it 2-3 times untill i understood it correctly , dev you should probably make a easy to understand video.

nothing for morons...

[sampei7777]

i guess another problem is that in the event of a minor occurence of two split chains.
when both chains meet and sort themselves out, the hash from the wrong chain could end up being stored.

I think this is the above case #3, isn't it?

[pineapples]

i guess another problem is that in the event of a minor occurence of two split chains.
when both chains meet and sort themselves out, the hash from the wrong chain could end up being stored.

I think this is the above case #3, isn't it?

well i was considering that minor forks are not uncommon with smaller coins. tbh i dont know how often a temporary fork may occur for any coin, but it does not seem necessarily to be indicative of an attack.

i guess the thing is that such a fork would be small and correct.
later blocks will be stored with correct hashes, perhaps making the incorrect one a curio rather than an actual problem.

[AtomSea]

Absolutely fabulous idea.
I really think Datacoin and coins like it hold some amazing potential.

If anyone is interested in getting a wallet going, i put together a how-to list.

https://bitcointalk.org/index.php?topic=325735.msg11527613#msg11527613

If someone would compile a new windows qt with updated nodes that'd be even more amazing.