Thank you for the great feedback.
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.
Ok, let’s go through a few test steps starting with 4 FLDC at 14CL3h16BQw7XZfv98dWngye3ve5yN91cu assuming bitcoincash blocks are significantly faster:
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
Next, the 2 FLDC on bitcoincash is sent to another bitcoincash address and confirmed at cashblock#600200:
send --source=bitcoincash:qqyph6hvahsr02feejkn30uneac7h4pkmyr3n48k0v --quantity=2
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?
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.
By creating more values, I believe we will actually increase developer participations. Anyone who understands bitcoin will understand bitcoin cash.
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.
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?