CIP Proposal - Crosschain Assets


#1

For some background, see:

The idea is simply that in the near future like starting with say block# 510000, we will parse both BTC/BCH chains.

Then assets can be sent across chains. Something like the following:

send --source=bitcoin:15GFYFXMjeLeamV7FUo1dHc16Wv1eLex7J --quantity=4
–asset=CAKE --destination=bitcoincash:qqyph6hvahsr02feejkn30uneac7h4pkmyr3n48k0v

Why?

  1. The development is simplified because Counterparty can basically already work on both chains.
  2. XCP keeps the security of bitcoin and gets the increased usefulness of bitcoin cash.
  3. BTC<->XCP<->BCH
  4. By starting with a simple bitcoin fork, we will pave the way to make it possible to send assets to other chains such as Litecoin in the future.
  5. XCP becomes the anti-forked coin. There are quite a few reasons for this, economic and practical.

Most importantly, this will ensure the longevity of Counterparty, strengthen our community, and make XCP one of the most useful and valuable asset yet.


#2

I have several concerns about this proposal. IMO - It’s good on paper, but bad in practice for reasons I will explain now:

Cost of running a node

  • The cost of running a federated node is already high.
  • Bcash community is okay with $20k CONOP. (“cost of node option”)
  • It’s indeterminant what future CONOP will be in any one chain. Multiple? Impossible to know.
  • Spiking CONOP in one chain could force emergency deprecation of chain and loss of funds
  • High CONOP will increase centralization over time. Not many nodes already.

Transaction ordering

  • Encoding into one blockchain is important because of tx ordering
  • Which blockchain gets parsed first?
  • How do we reconcile which tx matched the SELL/BUY order first?
  • Different blockchains have different block times
  • Litecoin transactions could front-run Bitcoin transactions on DEX

Technical debt

  • What will this change do to the federated node stack?
  • Technical debt is exponentially increased
  • This is a change that will affect almost all API calls

Code contributors

  • In an environment with low developer participation
  • Specializing in one blockchain is hard enough
  • How many multi-chain experts are in the world?

Resource allocation

  • If a chain gets supported, but little used, it won’t justify the increase in CONOP.
  • And, in this situation, you couldn’t deprecate the little used chain without people losing funds

Network adoption

  • Even if everything gets figured out, socially and technically complex to implement.
  • What will the UI be like to allow multiple chains?
  • Apps and exchanges may not want increased complexity/cost.
  • 1 XCP on Bitcoin is not fungible with 1 XCP on Litecoin. They will have different prices.

So, for all these reasons I think this proposal is a tough path to advocate. I’m also not sure what the use case is. If it’s to get lower fees, I think CIP 6, CIP 9, CIP 10, CIP 11, CIP 12, and CIP 15 are simpler, safer, and cohesive ways to achieve lower fees without taking on new challenges.


#3

There are rumblings of a fork brewing… and anyways, I’m sure some Bitcoin Cash users would still love to be a part of Counterparty

Crosschain counterparty is very interesting.


#4

Counterparty is often praised for its very fair launch; re: The Crossparty Protocol, taking the time to do due diligence in announcing alt blockchain counterparty launches well in advance and requiring the same sort of burn as was required on the bitcoin blockchain–or maybe even just locking it up–could be very interesting for the platform as a whole.


#5

Thank you for the great feedback.

Cost:
I agree that this is a big concern at first. I have struggled to analyze this. Meanwhile, I see more and more businesses starting to run both BTC and BCH. For now, my conclusion is that any added COST will be more than justified by the much higher VALUE that will be created. I see a future where XCP will have more value than both BTC and BCH combined. So in a twisted way, I see that the higher the CONOP the more valuable the platform had become.

Transaction ordering:
Ok, let’s go through a few test steps starting with 4 FLDC at 14CL3h16BQw7XZfv98dWngye3ve5yN91cu assuming bitcoincash blocks are significantly faster:

  1. When btc:FLDC is sent to bch:FLDC, the tx is confirmed on the BTC chain at block#510000.
    send --source=bitcoin:14CL3h16BQw7XZfv98dWngye3ve5yN91cu --quantity=4 --asset=FLDC --destination=bitcoincash:qqyph6hvahsr02feejkn30uneac7h4pkmyr3n48k0v
    Once the above sent is confirmed on the BTC chain, the 4 FLDC will be deducted from bitcoin:14CL3h16BQw7XZfv98dWngye3ve5yN91cu and credited to bitcoincash:qqyph6hvahsr02feejkn30uneac7h4pkmyr3n48k0v

  2. Next, the 2 FLDC on bitcoincash is sent to another bitcoincash address and confirmed at cashblock#600200:
    send --source=bitcoincash:qqyph6hvahsr02feejkn30uneac7h4pkmyr3n48k0v --quantity=2
    –asset=FLDC --destination=bitcoincash:qrpjrwdj59j3dsmj4yqdqakkh3x5n93h55s44p54lh

  3. Finally, this will also be confirmed on the BCH chain at cashblock#600605:
    send --source=bitcoincash:qrpjrwdj59j3dsmj4yqdqakkh3x5n93h55s44p54lh --quantity=1 --asset=FLDC --destination=bitcoin:1JUMkAo3siPgTPzUvzWwGZMAZLaf9MkxoN

Example balances at bitcoin block#510000 and cashblock#600605:
0 FLDC at bitcoin:14CL3h16BQw7XZfv98dWngye3ve5yN91cu
2 bch:FLDC at bitcoincash:qqyph6hvahsr02feejkn30uneac7h4pkmyr3n48k0v
1 bch:FLDC at bitcoincash:qrpjrwdj59j3dsmj4yqdqakkh3x5n93h55s44p54lh
1 btc:FLDC at bitcoin:1JUMkAo3siPgTPzUvzWwGZMAZLaf9MkxoN

What if the BTC block#500000 in step 1 is orphaned after steps 2 & 3 have been confirmed on the bitcoincash chain? So we need to revert all three steps. How? One way is when an asset is sent to a different chain, we keep track of the block numbers so we can roll back across chains, but it can get complicated quickly when assets can change hands multiple times on the faster chain. So it’s likely best to simply think of sending across chains as burning coins on one chain and creating coins on another. The coins will need to wait 100 blocks or however long it takes to mature on both chains before it can be used.

>Which blockchain gets parsed first?
This is a tough one to work out. Ideally both blockchains should be parsed at the same time independently.
Here’s one take on this. We start at bitcoinblock# 510000, then we will try to pick a starting cashblock#
that is close to the time of bitcoinblock#510000. The blocks can even start many days apart. Once the block timestamps on the two chains are parsed up to within a 4 hours window, assets can be sent across chains. Assets parsed from different chains will go into the same database as btc:FLDC, bch:FLDC, ltc:FLDC, etc…or they could go into different asset tables such as bch_assets or ltc_assets. On reparse, we will try to keep the two chains to within a 4 hours window. If the blocktime on one chain is more than 4 hours ahead, we pause until parsing on the other chain is caught up. To be safe, assets sent to another chain must wait at least 16 hours before it can be use. This solution is not very elegant because it’s like trying to connect two blockchains with a blocktimechain. Anyone with a better idea?

>How do we reconcile which tx matched the SELL/BUY order first?
SELL/BUY order works only on the same chain. No mix/match orders like btc:FLDC for ltc:SJCX.
To allow cross chain orders, we will probably need some complicated virtual chain to order blocks between the two chains. Is that even possible?

Technical debt:
I believe the technical debt is low for now because bitcoin cash is almost exactly like bitcoin.

>What will this change do to the federated node stack?
For now, I see an additional bitcoind and indexd for bitcoin cash. In the future, if another chain such as Litecoin is added we can come up with a common indexd server plugin architecture.

>This is a change that will affect almost all API calls
I have not looked into this, but I believe these changes can be made to be compatible with existing API calls. New API calls can take the crosschain assets into account while existing API would probably ignore assets with colons.

Code contributors:
By creating more values, I believe we will actually increase developer participations. Anyone who understands bitcoin will understand bitcoin cash.

Resource allocation
As we have seen in the recent fork talks, there is much interests in running transactions on the bitcoin cash chain. e.g. CIP16 - Pluggable Chains

>If a chain gets supported, but little used, it won’t justify the increase in CONOP.
>And, in this situation, you couldn’t deprecate the little used chain without people losing funds
Supposed somehow we ended up supporting dogecoin for a year. Suddenly after a year, no one uses that chain anymore. First, we make it known that Counterparty will stop parsing the dogecoin chain after block 3,000,000. What happens to all the assets such as doge:FLDC? We simply fold those assets back into a more useful chain. So one doge:FLDC can be moved into ltc:FLDC or even back into plain FLDC. This is possible because FLDC is essentially the same original Counterparty token that just happened to ride on different chains. It is very different from an FLDC token that was created in a Dogeparty fork which is now essentially lost. We do NOT ever leave assets behind on deprecated chains.

Network adoption
Being on more than 1 chain should increase network adoption. In the past every forked coin had to struggle with dividing its network and community, both politically and economically. All sides became weaker in the process as their values are divided or transferred to other platforms. By bridging the forked coins, XCP should gain adoptions from all sides. In the process, we will increase the usefulness and value of Counterparty.

>What will the UI be like to allow multiple chains?
I would imagine the UI can include a drop down to select the chain. Or just display crosschain assets with colon just like any other asset.

>Apps and exchanges may not want increased complexity/cost.
Exchanges should already be running multiple chains like BTC, BCH, and LTC. They can just add the appropriate indexd server and go. On an exchange there should be little differences between a bitcoin:FLDC, a bitcoincash:FLDC, or a litecoin:FLDC besides the speed/fees to withdraw them.

>1 XCP on Bitcoin is not fungible with 1 XCP on Litecoin. They will have different prices.
I would say 1 XCP should be mostly the same no matter which chain it’s on because no new XCP have been created. The only cost is the fees to send to the other chain. So, in some cases 1 litecoin:XCP might be worth more since it costs less to move around.

I know that this looks like a tough path to take. But the idea of being able to move to other chains had always been with us since the beginning even though we have never had to move to another chain. I believe the longer we wait the more tied down we are to one chain. One day, the technical debt will be so great that it will be even more difficult to move. This recent bitcoin fork is the perfect opportunity for Counterparty to capture the values on both sides. I believe that this tough path is more than just about lower fees. It is the only path forward to create more value than all the bitcoin forks combined.

I agree that the current CIPs to lower fees are important. But I fear that the more we try to adapt to one particular version of the chain, the less likely we are to survive under adverse conditions. For now, I would advocate to put the CIPs that are not compatible with bitcoin cash on hold. Maybe put those CIPs into a chain specific layer for later implementation. So instead of trying to save some fees now, we should take on the hard challenges. Take on the values in Bitcoin Cash. Then go on to take the values in Litecoin. By then, XCP should be worth it to run with as much CONOP as needed!

Ok, ok, it may not be so great that we can only trade between assets on the same chain. And it takes 16 hours to send assets between chains. What do you guys think?


#6

Here is a more elegant solution for this with low technical debt. It should be compatible with existing API calls and even counterwallets.

XSend
Add a new xsend command with the corresponding xc_assets table for transferring assets.

  1. On the BTC chain, xsend the asset to the new xc_assets with the destination addresses, source BTC block number, source block times, etc.

  2. Once the xsend moves an asset to xc_assets, an LTC transaction can transfer it to the LTC Counterparty chain after after the source block confirms plus some time greater than source block times.

For this example, imagine two almost independent Counterparty nodes running, one parsing Bitcoin and one parsing Litecoin. Each side uses its own chain, wallets, etc…very much like what we have today. The nodes only share xc_assets for transferring assets. The asset names remains the same. There is no need to distinguish btc:FLDC vs ltc:FLDC because the FLDC will either be in https://btc.counterwallet.io/ or https://ltc.counterwallet.io/ or xc_assets. We also need to disable asset creation on the non BTC chains to avoid mix ups.

LTC Counterparty can start parsing at any LTC block number. Counterwallet needs to be modified to be aware of xc_assets. If the second chain becomes too unwieldy we can transfer the assets back.

I think we can even come up with a separate node just for exchanging assets like an XCounterparty node, but I like the simplicity of a shared xc_assets table for transferring assets.


#7

I don’t see a way to contact you privately and I don’t want to redirect this conversation, but if you are on Counterparty.cash forum it would be great to see how far you want to go with these ideas as they present a novel structure.

JOY