An on-chain sidechain?

I think Counterparty should become the first actual bitcoin sidecahin, offering the same great protocol and wallet but with BTC as its native asset. There might be a way of doing it safely without moving to a new blockchain.

Becoming a bitcoin sidechain has two main advantages: the first is having bitcoin with it's network effect benefits as a native asset. The second is getting more control over the blockchain side, making it more compatible with the required features.

The later comes with a price - the security model of sidechains is not yet clear, there are potential issues with merged mining and all sort of technological risks related to developing and running a new blockchain. But counterparty already did a great job integrating to the bitcoin blocakchain and can continue enjoying the security benefits of bitcoin's hash power.

The first point however - having bitcoin as a native asset - could be critical to counterparty's sucess:

  • It will solve the BTCPay problem. Disabling BTC trade on counterwallt is a problem. It was one of the main advantages of building on top of bitcoin and without it the DEX can't compete with projects which aren't limited by the bitcoin blockchain or with centralized exchanges which offer BTC markets for assets.

  • It will allow bets and CFDs to enjoy bitcoin's liquidity, marketcap, infrastructure and basically the network effect. The first decentralized derivative market to really work will be more disruptive than bitcoin itself in terms of capital flowing in - it just won't make sense to manage investments elsewhere. But no real market can be created if XCP with its limited liquidity is required as a collateral, even if it grows dramatically.

  • It will open the door for other features which require a protocol that can move bitcoin.

  • Most of the great work which was done is still very much relevant.

Most of the advantages (with the exception of the 10 minute block time) are related to the bitcoin-as-native-currency, rather than to the benefits of a new blockchain. The new blockchain part however, is the complicated and risky one.

The 2-way-peg mechanism presented in the sidechains paper is not 100% clear yet, but it seems like we could use the new script (which validates SPV proofs) for a BTC<->XBTC peg while keeping the same security model and without changing much of the rest.

BTC will be sent to an SPV-locked output and XBTC will be created against it (and the other way around). I won't pretend to have figured it out to details, but i believe it will be possible. Once we are on the XBTC side everything works the same way.

As for XCP, fees could be collected and distributed between XCP holders.

I understand sidechains are only a paper so far, but it seem like a serious effort which will become reality sooner or later. I believe it could be a great opportunity and that it could be done without migrating to a different blockchain, not until it was proven safe.


What do you think?

I think the idea about fees: I don’t know if it’s possible to “skim” a bit from every transaction and redistribute to all existing addresses like some other coins do and whether the devs would want to do that. 


Disabling BTC trade on counterwallt is a problem.

Well Counterwallet is just one implementation. In theory somene can check out a recent release of Counterwallet and run it with BTCPay enabled… Or implement a better BTCPay solution in or outside of Counterwallet. 

(Related recent discussion on side-chains is at https://forums.counterparty.io/discussion/766/counterparty-as-sidechain#latest)

It would be possible for Counterparty to become a sidechain rather than a protocol layer on top of Bitcoin - when the Blockstream guys have released their plan - be it either a hard or soft fork, Counterparty would be able to look at federated pegging - its completely plausible

Many developers are having serious security concerns in regards to sidechains and two-way pegs. There is not really any reason to switch the existing system, and it would take a lot of time and effort.

Since i wrote it, the great Ethereum-on-Counterparty news came out. I believe it makes the native BTC support even more of an absolute must.


I think the idea about fees: I don’t know if it’s possible to “skim” a bit from every transaction and redistribute to all existing addresses like some other coins do and whether the devs would want to do that. 

Simply burn the fees. This is not my idea, that’s the actual plan now.

> Well Counterwallet is just one implementation. In theory somene can check out a recent release of Counterwallet and run it with BTCPay enabled…

True, but there are good reasons for disabling it. If CP devs couldn’t make it work properly , i doubt someone else will. 

Many developers are having serious security concerns in regards to sidechains and two-way pegs

I think most of those security concerns are related to moving and securing a new blockchain, not to the actual pegging logic. But i might be wrong here.


I think most of those security concerns are related to moving and securing a new blockchain, not to the actual pegging logic. But i might be wrong here.

Actually, that is just a large part of it. It also creates centralization pressure by spreading fees across chains, and increases the risk of hashpower attacks.


I think most of those security concerns are related to moving and securing a new blockchain, not to the actual pegging logic. But i might be wrong here.

Actually, that is just a large part of it. It also creates centralization pressure by spreading fees across chains, and increases the risk of hashpower attacks.

But this is why i suggested keeping the same security model and do the pegging while staying on the bitcoin blockchain. 

Relevant: https://www.cryptocoinsnews.com/ethereum-cloning-ethereum-comments-counterparty-responds/