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

Interested too.

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.

Bitcoin the Universal Crypto-Clock. Nice.

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

Impressive concept and work!

Huge change incoming

SuperNET, Coinomat FTW

Cheers

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.

The above just solves half the problem, the common externally verifiable time reference.

The other half is being discussed in #passport in supernet slack, the goals are making each asset have its own PoS chain where it uses itself to protect itself. So no more hardfork attacks and each asset chain is not dependent on any other chain, other than BTC for the common clock and backstop security.

since each asset chain is technically independent, there is literally no limit to the number of them that are possible

[3:49]
no single chain is having to authenticate all chains

[3:49]
no single chain is having to store all the tx for all chains

[3:49]
no single chain has to deal with the bandwidth for all chains

[3:49]
asset immigration/emigration events need to go somewhere, BTCD is logical place

[3:50]
some sort of assetchain defined storing of summary hashes need to go somewhere, BTCD for higher frequency, BTC for lower frequency

[3:51]
from a practical point, each asset can do tx denominated in itself and if desired "zero cost" txfee can be used

[3:52]
before you start saying, "spam attack, spam attack, what about the spam attack"

[3:52]
I say that PoW nonces can be required for even submitting to the network, for a non-attacker it is a second of computation, which wont be a big deal

[3:53]
for the attacker, its a second of computation per spam. doesnt sound like much, but 3600 packets per hour is not much of a spam attack.

[3:55]
each asset chain can decide how far back it wants to store data, but using ramchain tech, the BTC blockchain now is about 15GB and it syncs at bandwidth speed, so the reason blockchain bloat has been such an issue is because iguana didnt exist to make things 100x to 1000x faster

[3:56]
If anybody likes proof about the disconnect between cmc marketcaps and tech, rimbit is almost trading at the combined BTCD + SuperNET marketcap

jl777 [4:07 AM]
It seems pretty clear to me that anything that solves the crypto scalability problem as the above will do, will generate significant value. But do not worry about any new IPO to raise thousands of BTC, there wont be, especially as there is no need to. Daily latte's just dont cost that much

jl777 [4:15 AM]
If you are trying to read the tea leaves to find the best place to invest to benefit from this, the best place is in the assets as it changes them from being a total slave to full master of their own destiny, with the future evolution only limited by what new tech can be created. I was serious when I said I would use the crypto777 asset as a way for people to get customized features for their asset chain. There would be some period of exclusivity, but after a few months, then the other asset chains would be able to use it too. But realistically it will take a bit of time for a chain to adopt new tech and probably most will be watching things to make sure it works. So I would estimate 3 to 6 months of practical exclusivity. Not much, but being the first can never be taken away, so we will end up with assets that are the leaders and the ones that are followers as far as their asset chain functions go.

SuperNET nodes will likely be needed to add strength to many asset chains, in addition to the indirect benefit that SuperNET owned assets are using asset chains, there will likely be some asset txfees earned by SuperNET nodes, but this would be more up to the free market to determine

BTCD would benefit from its DCH (decentralized clearing house) role and being the likely conduit to the BTC atomic function, at least as first. I cant say the exact details of what BTCD will do, just that if any bitcoin protocol chain with a 1 minute time is the right tech solution, BTCD will be utilized.

But the big win will be the entire SuperNET ecosystem, as any diaspora of asset chains would bring a lot of new users and issuers into the iguana based universe of browser based crypto systems.

or you could bet on rimbit continuing its march toward replacing bitcoin itself

James

In order for independent chains to securely trade with each other, all chains must be secure. The problem with smaller coins and any asset specific chain is it security. The following is the first half of the solution that enables weaker chains to inherit some of BTC's security.


From Satoshi's paper:

3. Timestamp Server
The solution we propose begins with a timestamp server. A timestamp server works by taking a hash of a block of items to be timestamped and widely publishing the hash, such as in a newspaper or Usenet post [2-5]. The timestamp proves that the data must have existed at the time, obviously, in order to get into the hash. Each timestamp includes the previous timestamp in its hash, forming a chain, with each additional timestamp reinforcing the ones before it.

###

It is the timestamp server that enables the rest of bitcoin to work and without a timestamp server, it appears trivial to double spend as there wont be a way to know the balance of an account at any given time. Regardless of whether a timestamp server alone is sufficient, it is clearly necessary.

We will ignore all issues regarding PoW vs PoS vs PoAnything and concentrate on creating a universal timestamp, or rather a time sequence server via bitcoin. The effect of having a universal clock is that synchronized operations can be done across all other blockchains who adopt the bitcoin time sequence server.

A. In the beginning there was no bitcoin and until genesis block it was not possible to be utilized in any way. However, now that it exists and is clearly "real", we have enormous amounts of hashrate securing the steady stream of bitcoin blocks. Due to the way the consensus works, there is a chance that the current block is superceded by a "better" block and even the most recent 2 blocks, or 3, or ... However, the chances rapidly diminish to an extremely remote possibility. The exact number of confirmations that is considered safe from reorg is certainly a critical decision, but it does not affect the proof of time stamp serverness.

Let us call this depth L, for lag. It will be assumed that any bitcoin blocks with L or more confirmations are permanent. For practical applications, it is suggested to have a mechanism to detect and recalibrate in the rare case of a bitcoin reorg beyond L blocks, but if the probability of such an event is remote enough, other means of compensating for it are also possible, ie insurance type methods of risk sharing.

B. Given the assumption that any blocks with L confirmations are valid, at any given time there is a "current" permanent BTC block, with its blockhash. And most times a new block is generated, we get a new permanent BTC block. However, when there is a small reorg or a replacement of the tip, we do not get a new permanent BTC block. A simple way to calculate whether a new BTC block advances the permanet BTC block is to verify that it is L+1 confirmations from the previous permanent block.

What this means is that as bitcoin does its small reorgs, the permanent blocks will not advance until things catch up. However since most reorgs are caused by a new pair of blocks that extend the chain and bypassing the current tip, this stop/starting of the permanent blocks are mostly insulated. This stop and go behavior combined with the +/- 2 hours tolerance on timestamps makes the BTS not a timestamp server, but a time sequence server. It is not as useful, but still a framework that can be built upon.

We now have a sequence of permanent blocks Ti, Ti+1, Ti+2, ... with the proven characteristic that each Ti came after the preceding one, ie. an ordering of blockhashes. Another small concession that will be made is that we will assume that SHA256 collisions can be ignored, bitcoin now does not allow duplicate blockhashes, so even if there is a collision it will probably not affect things, but the odds of such are so small, it will simplify the analysis to ignore its effects.

C. What can be done with the set of permanent blockhashes? They can be used by any external blockchain or in fact anything as proof of time sequence. Using the law of common sense and assuming the ban on time travel is still in effect, we can see that to be able to know a specific blockhash Ti indicates it must have happened after that blockhash appeared. Since Ti first appeared in the mining node even before it was submitted, it could have been known right after blockhash Ti-1 appeared. Yes, this will be a very slow clock indeed, but a clock nonetheless.

Being able to refer to a permanent blockhash Ti shows that it happened after L+1 confirmations ago. What this means is that regardless of whether this hash Ti is put into the altcoin's chain via consensus or by attacker, all blocks after it are shown to have happened after the earliest time that Ti was known.

Let us assume that the permanent blockhash sequence is either fully or partially referred to in the external chain. This gives us a partial ordering of all the external chain blocks as having happened no sooner than when Ti was known. If the protocol gives more weight to referals to the oldest Ti, then an eventual consensus will arise with external chain blocks grouped into segments such that each segment is known to have happened after the blocks in the prior segment. By having a block rejection rule to reject blocks too far from the past, if this "too far" is set to be a fraction of the times between Ti, then we get a provable time ordering if there is 1 or more Ti between two external chain segments and a likely time ordering for adjacent segments.

D. Now each external chain is divided into universally verifiable groups of blocks, that regardless of the strength of the consensus mechanism for that external chain (even if it has none!), it is able to conduct cross chain transactions with other external chains using the same segmentation. Well, not quite. 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. This R (for reorg) factor will then allow other external chains to know that after R permanent blocks it cannot change and also the partial time sequence is externally verifiable.

E. This is just a first draft and many improvements are possible. For instance, by using blocks very close to the current, the external chain can create a lot finer grain ordering internally, unless bitcoin reorgs the referred blocks away.

F. tl:dr it wont be fast, but using bitcoin as the universal clock, all external chains that add a few consensus rules can interact as long as enough bitcoin confirmations are waited.

G. Appendix: put fancy math that almost nobody understands here

Alright thanks.
I will follow.

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

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?

Hallelujah & amen!

-j.

My reference implementation will be based on iguana. asset holders want the security of BTC, but it is too slow. So using BTCD for trading at one minute blocks and BTC for long term parking/coldstorage is the logical setup.

I like to use logical setups.

Since iguana is already talking to both BTC and BTCD at the same time, this requires more work, but PAX already needed AE type of functionality, so now I just need to extend that codebase to allow using NXT assets and NXT accounts directly.

Will be a bit getting used to for having an asset on different blockchains, but really it is like having deposits at different central exchanges. With a nice GUI to track it, shouldnt be a problem and this fits exactly into one of the InstantDEX GUI's: https://instantdex-gui-avidayal91.c9users.io/#/coin_exchange

It is work in progress and not always running, but if you see it you can get the idea of the "easyDEX" that is oriented toward the casual trader and not the advanced technical analysis charts

James

Awesome news James,  I love the way you view the big picture. Will BTCD be taking the lead in the revolution?

Cheers Jon 

they thought we were slaves and had no choice. Dont they realize who I am?

James

+1million

Impressive ideas here.

It's great to see a return to the ROOTS of crypto. The Don't tread on me attitude. The we don't need permission from anyone attitude. The system should benefit the users attitude. The decentralized free market places.


Thank you for addressing the views of asset holders that are powerless on a system that decided to not protect it's users but cater to business's that haven't contributed anything and might not contribute anything, yet somehow waved a magic carrot.

This is a real organic revolution of crypto asset liberation. 

I mean in the discussion and setting of standard. The coloredcoins.org spec is a pretty good place to start, but it doesnt handle multiple chains.

And a blockchain would need to implement importing, so if they dont do that, they are prevented from joining. If this standard is closed and secret, then any chain not in the inner circle would have been prevented.

James

Can a blockchain be prevented from joining?

Cheers

Graham

Makes perfect sense to me, cool

Atomic Cross chain https://bitcointalksearch.org/topic/atomic-swaps-using-cut-and-choose-1364951 is not easy, but possible. Additionally side chains shows another method for cross chain.

The key is to make sure that at the high level all the current and likely future blockchains can provide the required import function. Ideally into the native asset type, but some coins like Bitcoin and all its forks, of course dont have any intrinsic assets. but with OP_RETURN data or colored coins, even for blockchains without native asset support can support assets.

I think "simple" things like asset id preservation/mapping and support of a meta-assetid is probably the trickiest issue. Once we have a way to have a universal assetid, then it becomes possible for each blockchain to track it and transfer it and trade it.

It is a bit space intensive, but one way is to combine the issuers pubkey with the assetid it was originally created on. This will typically be between 256 bits to 512 bits. One way to make it more convenient is to map that to an rmd160 hash like bitcoin, which then gets us to 160 bits, or 20 bytes per address. That also allows creating bitcoin-style address out of the universal assetid. To avoid confusion with bitcoin addresses, the address type shouldnt be 0 or 5, best to use a unique address type, maybe 0xff which I havent seen used in any coin yet, but I have seen all of them so it might still conflict.

James

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

Federal Reserve+income tax were born as temporary solution (noone would ever be able to justify  making such a monster permanent) and everybody witnessed evil at work through whole 20th century before and after it became permanent. Funny that it became permanent with justification that everything is good right before crash of 1929. It would have trouble extending it's powers after 1929 and the monster knew that and acted promptly and successfully.
That evil neutralized great permanent achievements of 1776.

I am quite sure Kennedy was killed by the same monster. With its permanent power it became much easier for evil to keep the status quo by killing presidents and other key people who try to shake it.

It's time to put evil back into its bottle for good.

James please make sure that bottle is closed tightly so that it's not as easy to open as it was in 1913 for that moron Woodrow Wilson and his buddies.
Specifically, don't make the same mistake as the Founding Fathers did by making it too flexible.

I love you James.

Sorry, too busy to deal with anything but technical issues.
This is purely an interop standards effort. All participating blockchains benefit from the network effect.

The user centric goals, means that users that are most comfortable on blockhain X, just stay there. Trades against the host currency will be the most efficient, so for most of the people most of the time nothing changes.

However, if something makes a different blockchain more attractive for that specific user, he would be able to migrate some or all of his assets there. This sets up the different blockchains to compete for residency of the assets and since the asset total is blockchain(s) enforced, short of a blockchain totally stopping, the asset value is protected. Even in that case, we could probably have some provisions for snapshot resurrections.

Due to essentially side chain type of issues, the transfers will necessarily take many confirmations, but like moving your own place of residence, it is not something that is done very often, if at all.

Also, for a blockchain that is afraid of losing their assets and thus not wanting to participate, there will need to be methods created for a onetime exit from that chain. However that is a oneway move (until that blockchain supports importing external assets), so not one to be made lightly.

From what I can tell, all existing decentralized asset systems support exporting already, not specifically as such, but if an asset can be burned, it can be exported using a burn protocol

This appears to be a form of meta-decentralization, where the decentralized assets can be spread across multiple blockchains, yet retain their fixed supply. While the relatively small number of host blockchains makes it more like a distributed model, since each blockchain is decentralized (we hope!) maybe that property infused into the distributed aspect.

Regardless of its exact taxonomy in this space, what is clear is that having a passport to travel is much better than not having one.

James

wow, good development. 

Well this is new  had my fud ready and all.

Declaration of Independence

We the asset holders hereby declare our independence from any single blockchain.

An open and jointly developed specification on cross chain atomic asset transfers will be developed. Any current or future blockchain is invited to join.

Each blockchain will need to not only promise protections for asset holder interests, they need to live up to them. Otherwise, all the assets will simply move to blockchains that do.

Additionally, once assets become mobile, the different blockchains will start to differentiate themselves with better features for the assets. Better liquidity, better fees, more functions.

This ability for the asset holder to choose where their assets reside is the only protection from the tyranny of the hardfork.

Traditional companies trade on multiple exchanges, it is time for decentralized assets to distribute the blockchains they exist on. Maintaining a constant total number of assets issued across all blockchains will allow maintaining a fixed total, but only if each participating blockchain follows strict rules on asset issuance.

The reality is that everything in crypto trades against BTC. One of the conditions for cross chain assets is the ability to trade directly against BTC, preferably native BTC and not a derivative. I will be working on a reference implementation as a first draft and look forward to collaborate with all other asset oriented projects.

This is an interop standards effort and it needs to be blockchain agnostic and asset centric.

James

P.S. I am not asking for any funds or investments.