Quote from: killerstorm on March 04, 2016, 09:10:35 AM

Quote from: jl777 on February 28, 2016, 06:37:20 AM

Of course if the external chain is some arbitrary ledger that can be updated at will by some corporate entity, then these security assumptions do not hold up. What is required is another rule in the external chain that after R permanent Ti blocks have passed, that it is permanent.

Aha, so we just need to have a consensus to have consensus, got it.

You're begging the question. The whole point of this exercise is to make sure that transaction history cannot be rewritten. If you just assume that it cannot be rewritten, then you don't need all this Ti mumbo-jumbo.

Inclusion of Ti does not make it any harder to rewrite the history, as attacker has access to all Ti and thus he will be able to create a seemingly valid chain which references all Ti blocks but is completely different.

I think you've got things wrong, to improve security you need to reference alt-coin blocks from Bitcoin blocks, not the other way around. This is known as anchoring, it's already used in several projects (for example, Factom) and it can make alt-coin consensus as strong as Bitcoin. (See here: https://bitcointalk.org/index.php?topic=313347.0)

Inclusion of Ti allows to create new consensus rules that create both a "before" and "after" time relationship.

The "after" simply by the proof of common sense that if you refer to a specific blockhash, it most likely happened after that blockhash came into existence. The exact time of this is a bit fuzzy, but we can get it narrowed down to a relatively narrow time frame.

Did I get that part totally wrong?

So how to get the "before" part? This requires the chain to do some validation of all blocks and make sure it is referring to the currently valid Ti. There is a propagation delay that could make things off by one, but we assume propagation times in the network dont span a bitcoin block generation time.

If I didnt get things totally wrong, then this means each block happened after Ti, but before Ti+2 occured.

So we can now tag each block with an "earliest" and "latest" time reference.

Once each block has those, then how can an attacker rewrite the history? he can only create blocks within the allowed "earliest" and "latest" range of 2 bitcoin blocks. Yes, within this 20 minutes, I guess he can do whatever he wants, if that is the assumption. So any transactions within this timeframe is like a transaction without enough confirmations.

Once things go past the +/- 1 Ti blocks segment, maybe there are ways to overcome the earliest/latest bracketing. Maybe you can point out the obvious way to overcome the entire network checking each submitted block for valid time sequence? It is possible, but it isnt totally wrong.

Also, I think you are the one that is backwards, as it requires some blockchain group signature to validate data that is put into the BTC chain to use as a cross reference. That is possible, but it is a bit on the complicated side, though I do have ideas on how to do it. Just not having all the details yet.

For now, I want to make sure the time sequence can be established and across all chains that follow the same simple set of rules.

James