Declaration of Independence - Atomic Cross Chain Asset Standard

[sasha35625]

We are talking about common custom token standard here, for all chains.  If there's a common standard a burn protocol can be created which will allow moving assets between chains! it's like a trading network for stock exchanges, but for crypto. This should be a very important development.

[mxxxxxx]

Impressive concept and work!

Huge change incoming

SuperNET, Coinomat FTW

Cheers

[Seccour]

Bitcoin the Universal Crypto-Clock. Nice.

And i signed this " Declaration of Independence " for my assets.

[BARR_Official]

BARR was designed from the start with the ability to migrate to another platform whenever necessary.
But NXT was supposed to be the only platform we needed.

We have burned roughly $40,000 worth of coins from 8 different altcoin blockchains,
and we have redeemed those coins on the NXT blockchain with BARR.

The idea was that, after the exchange process/cross-blockchain migration,
the BARR tokens would be just as decentralized as any other cryptocurrency.
More decentralized in fact, since they can be traded without trusting any exchange.

NXT claimed to offer a solution for permanent decentralized record-keeping,
and anyone can easily view our issuing account and find altcoin txids proving the burns to match every unit of BARR that has ever been issued.

But now NXT will not keep those records permanently on the blockchain.
If NXT makes any other catastrophic changes that negatively affect the value of the coins which have been transferred to the NXT platform,
we are fully willing and capable of moving the entire project to another platform.
We can do it in 1 day.

Of course, doing it the normal way would leave the possibility that such a migration might again become necessary in the future.

But if users are able to transfer their own assets to their blockchain of choice,
then the future of true decentralization has just exploded in ways we can only imagine.

[Nxtblg]

Impressive concept and work!

Huge change incoming

SuperNET, Coinomat FTW

Cheers

Interested too.

[starik69]

1) New great project without finished any other one
2) It is not independent because it is dependant on bitcoin

[jl777]

1) New great project without finished any other one
2) It is not independent because it is dependant on bitcoin

Yes, let us not count that MGW is finished for over a year, lite wallet almost a year, and most of docs.supernet.org has working API. Of course, a project without a GUI cannot possibly have any value as all that matters are the pretty graphics visible on the screen and not the underlying core tech.

Anyway, scheduling issues are not what is at issuer for an interop standard.

All crypto is dependent financially on BTC, with the possible exception of ETH. I dont think many crypto projects would mind inheriting some of the BTC security. Might was well utilize all the electricity being used for BTC for all the cryptos.

If you dont want your coin to depend on BTC, that is fine. People will decide if a project that adds some BTC secured backstops is more secure than similar ones without. Let the market decide

James

[Seccour]

2) It is not independent because it is dependant on bitcoin

It is, it's use Bitcoin as extra-security. You can have an Assetchain that don't use the "Bitcoin crypto-clock" but it will be less secure.

[Blocktree]

1) New great project without finished any other one
2) It is not independent because it is dependant on bitcoin

Yes, let us not count that MGW is finished for over a year, lite wallet almost a year, and most of docs.supernet.org has working API. Of course, a project without a GUI cannot possibly have any value as all that matters are the pretty graphics visible on the screen and not the underlying core tech.

Anyway, scheduling issues are not what is at issuer for an interop standard.

All crypto is dependent financially on BTC, with the possible exception of ETH. I dont think many crypto projects would mind inheriting some of the BTC security. Might was well utilize all the electricity being used for BTC for all the cryptos.

If you dont want your coin to depend on BTC, that is fine. People will decide if a project that adds some BTC secured backstops is more secure than similar ones without. Let the market decide

James

Before you can still scam more money,just finished at least one and released it.
Now you just still want to scam with shit coins?

Where is your claimed Privatebet project?
Where is your claimed Skynet project?
Where is your claimed NXT2PAY project?
Where is your claimed Pangea project?
Where is your claimed crypto777 project?
Where is your claimed InstantDEX project?
Where is your claimed NXTcoinsco project?
Where is your claimed NXTprivacy project?
Where is your claimed jl777hodl project?
Where is your claimed SuperHODL project?
Where is your claimed SNN project?
Where is your claimed SpaceMesh project?
Where is your claimed omnigames project?

ALL ARE IN AIR.

Be alert with this SuperScammer !!!


 

[LiteCoinGuy]

thx for F&G 

[killerstorm]

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)

[l8orre]

Before you can still scam more money,just finished at least one and released it.
Now you just still want to scam with shit coins?

moldy smelling sock puppet pulled out of a humid drawer in some dingy cellar. not very original:

https://bitcointalk.org/index.php?action=profile;u=258498;sa=showPosts

[jl777]

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)

I have not specified anything about how the non-bitcoin chains achieve consensus within themselves yet. For now, just assume they are doing what chains do currently. Presumably they are working fairly well.

By having consensus rules in the chains that provide both an "after" and "before" time relationship, you can narrow down when something happened, even across chains.

As I said, there are more details to work out and this is just the synchronization part. Analogy is a train system. We can ignore how the trains work internally, when we are trying to make a travel plan, just assume the train will get there when it says it will, ie 9am.

But what is 9am? To be able to go from trainA to trainB, both need a common time reference. So it is good you notice that I did not deal with internal consensus, since I havent yet as I assumed that such things are possible, since we see so many blockchains around

James

[jl777]

Where is your claimed Privatebet project?
Where is your claimed Skynet project?
Where is your claimed NXT2PAY project?
Where is your claimed Pangea project?
Where is your claimed crypto777 project?
Where is your claimed InstantDEX project?
Where is your claimed NXTcoinsco project?
Where is your claimed NXTprivacy project?
Where is your claimed jl777hodl project?
Where is your claimed SuperHODL project?
Where is your claimed SNN project?
Where is your claimed SpaceMesh project?
Where is your claimed omnigames project?

Skynet http://docs.finhive.com/api/docs.cgi?run=page&sub=home
Privatebet, pangea, crypto777, InstantDEX, NXTcoinsco and NXTprivacy are in the supernet codebase docs.supernet.org

jl777hodl and superHODL have been completed for over a year since they are still doing the HODL thing.

Spacemesh https://docs.google.com/spreadsheets/d/1ya9fMS0Z0-xSew2rhLcHKbB9y4HVERwk9t-G1W4PzlY/edit?pref=2&pli=1

But you got me on the others, those projects I am not directly involved and and they are of unknown status.

Also, didnt you notice this is a call for interop standard and that I am not asking for any funds?

James

[jl777]

Hi James,

how does this relate to the (concept of) BlockNet project? Any thoughts?

thanks

no idea about blocknet details

[jl777]

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

[killerstorm]

Once each block has those, then how can an attacker rewrite the history?

It's very easy for an attacker to rewrite history. Suppose normal chain has blocks A1, A2, A3 which reference T1, T2, T3.

Attacker will create alternative blocks  A1', A2', A3' which also reference T1, T2, T3.

Perhaps he won't be able to create block A4 before T4 is known, but this has nothing to do with rewriting history.

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.

When you analyze consensus algorithms you should consider behavior of a new node which joins the network and doesn't have any pre-assumptions. So, suppose a new node connects to one honest node and one attacker's node. Suppose honest node gives it a chain which ends with A1...A100 and attacker's chain ends with blocks A1'...A100'. How can a new node tell which of them is valid? Timestamps don't help here.

It can be mathematically proven that your block-base timestamps are no better than ordinary UNIX timestamps, assuming that node clocks aren't horribly out of sync.

[jl777]

Once each block has those, then how can an attacker rewrite the history?

It's very easy for an attacker to rewrite history. Suppose normal chain has blocks A1, A2, A3 which reference T1, T2, T3.

Attacker will create alternative blocks  A1', A2', A3' which also reference T1, T2, T3.

Perhaps he won't be able to create block A4 before T4 is known, but this has nothing to do with rewriting history.

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.

When you analyze consensus algorithms you should consider behavior of a new node which joins the network and doesn't have any pre-assumptions. So, suppose a new node connects to one honest node and one attacker's node. Suppose honest node gives it a chain which ends with A1...A100 and attacker's chain ends with blocks A1'...A100'. How can a new node tell which of them is valid? Timestamps don't help here.

It can be mathematically proven that your block-base timestamps are no better than ordinary UNIX timestamps, assuming that node clocks aren't horribly out of sync.

I believe your mathematical proof is not using the proper assumptions. Of course you can make some assumptions to prove what you say, but  a bigger context can provide the external reference for the bootstrapping node.

With many chains all part of the system, they will all have hashes from the other chains. Wouldnt that require an attacker to compromise the majority of participating chains?

Even assuming the attacker has more than half the nodes, the new node will see many with A1... A100 along with the A1'...A100', however on all the other chains the A1'...A100' is not there.

So all the participating chains provides security to all the other chains. If each chain specifies which external chains they find as valid, this will prevent an attacker to set up a bunch of fake external chains.

Thank you for specific example. this is what is needed to make a bullet proof system. I believe you are agreeing that the sequence server does work for nodes that are current and the issue was the history attack. Let me know how you can mathematically prove that having a set of external chains cross verifying each other cannot provide an external reference for a bootstrapping node. Bootstrapping a node is a different case than confirming blocks, so it might be more than one method is needed to cover both aspects.

James

P.S. While I would like the BTC chain to also have the data, clearly it wont go into the bitcoin core, so the problem of how to validate data in the BTC chain needs to be solved before that can be used

[anon__]

Could you please explain this in laymen tearms for asset holder of supernet, nxtventure, jl777hodl, etc.
;Most of them are down 70-90%. Are we gonna loose the last 20% of value left?
Will they stay on these awkward child chain?

I will make a way to move to the BTC chain, so that seems not an awkward child chain.
do not worry, I will do what it takes to protect the assetholders.

James

I would like to point out that Nxt 2.0 will also allow trading assets against Bitcoin. Confirmed by Nxt developer Jean-Luc:

https://nxtforum.org/general-discussion/new-video-'nxt-interview-with-core-dev-riker!-)'/msg211743/#msg211743

[watashi-kokoto]

Amazing, will Pangea poker be based on zero knowledge mental poker or is there some amazing new tech to ensure duplicate cards will not be dealt from the deck?

A simple solution to detect card value collision and cancel the game would be enough!