Topic: Declaration of Independence - Atomic Cross Chain Asset Standard (Read 9717 times)

For anyone still interested, jl777's atomic cross chain standard has become a reality and it's easy enough for anyone to use.

Command Line API, Desktop App, and Mobile App all exist.

https://atomicdex.io

https://github.com/komodoplatform/atomicdex-api

https://github.com/komodoplatform/atomicdex-desktop

Fantastic. If that is possible and becomes reality it will be the best thing to happen in crypto in 2016.

Moly have a lam i nothing understand what are you typing.

I dont know if to call it amazing is accurate, but it does detect duplicate cards, handles face up and face down, etc.

Alpha version was functional, before I got sidetracked with having to write iguana core. Now that is approaching the maintenance stage, I will be able to resume work on atomic cross chain swaps and pangea

James

https://nxtforum.org/general-discussion/what's-up-with-all-the-pessimism/msg213446/#msg213446

"I consider it a good thing that those with their own agenda are moving away and selling off"

Such comments by the core dev does not give any optimisim that asset holder's rights will be respected.

James

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!

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

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

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.


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.

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

no idea about blocknet details

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

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

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

https://bitcointalksearch.org/user/blocktree-258498

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://bitcointalksearch.org/topic/merged-mining-vs-side-chains-another-kind-of-merged-mining-313347)

thx for F&G 

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 !!!


 

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.

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

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