The Crossparty Protocol

We see a need to discuss the migration strategy, capabilities and, consequently, the longevity of the Counterparty Protocol.

The ability for Counterparty to thrive even in the situation where Bitcoin itself is destroyed is a valuable characteristic.

Also, discussions of this sort will likely touch on side chains, treechains and perhaps even simply backing up of Counterparty data on other relatively secure cryptocurrencies. [On that note, some individuals promote cryptocurrencies that have more than 1 economic measure (e.g. more than 1 proof of work, or a combination of proof of work and proof of stake). Well, one could potentially back up their XCP across many chains availing of this increased security and redundancy.]

One could call this The Crossparty Protocol.

This is a requirement before I commit marketing my entire blockscan.com/assetInfo.aspx?q=SOYBEANS crop.


I do not necessarily need a full cross-chain implementation, but I do need to know that I can fork the code and start my own blockchain and at least re-initialize the assets I’ve issued either manually or from forensics on the old blockchain.


There’s also a namespace issue. If I actually start running counterparty on another chain, there’s the whole burn thing that I don’t know if or how it makes any sense. Ideally the underlying alt-chain has support to either directly use the native chain tokens instead of XCP, or that burning native chain tokens is a way to implement creation of new XCP.


And please, let’s not get into a religious war about ‘there can be only one XCP’. There WILL be alt-xcp, so crossparty must be able to deal both with porting bitcoin-XCP as-is to other chains, and dealing with alt-XCP (xBTCXCP?)

[quote author=hozer link=topic=418.msg2749#msg2749 date=1403744524]
This is a requirement before I commit marketing my entire blockscan.com/assetInfo.aspx?q=SOYBEANS crop.


I do not necessarily need a full cross-chain implementation, but I do need to know that I can fork the code and start my own blockchain and at least re-initialize the assets I’ve issued either manually or from forensics on the old blockchain.


There’s also a namespace issue. If I actually start running counterparty on another chain, there’s the whole burn thing that I don’t know if or how it makes any sense. Ideally the underlying alt-chain has support to either directly use the native chain tokens instead of XCP, or that burning native chain tokens is a way to implement creation of new XCP.


And please, let’s not get into a religious war about ‘there can be only one XCP’. There WILL be alt-xcp, so crossparty must be able to deal both with porting bitcoin-XCP as-is to other chains, and dealing with alt-XCP (xBTCXCP?)
[/quote]


You  could use Vennd to have a gateway between an alt-xcp and xcp. There’s no problem here.

[quote author=cityglut link=topic=418.msg2751#msg2751 date=1403751345]
[quote author=hozer link=topic=418.msg2749#msg2749 date=1403744524]
This is a requirement before I commit marketing my entire blockscan.com/assetInfo.aspx?q=SOYBEANS crop.


I do not necessarily need a full cross-chain implementation, but I do need to know that I can fork the code and start my own blockchain and at least re-initialize the assets I’ve issued either manually or from forensics on the old blockchain.


There’s also a namespace issue. If I actually start running counterparty on another chain, there’s the whole burn thing that I don’t know if or how it makes any sense. Ideally the underlying alt-chain has support to either directly use the native chain tokens instead of XCP, or that burning native chain tokens is a way to implement creation of new XCP.


And please, let’s not get into a religious war about ‘there can be only one XCP’. There WILL be alt-xcp, so crossparty must be able to deal both with porting bitcoin-XCP as-is to other chains, and dealing with alt-XCP (xBTCXCP?)
[/quote]


You  could use Vennd to have a gateway between an alt-xcp and xcp. There’s no problem here.
[/quote]


How does one go about initializing an alt-XCP? I would like to have a little tighter integration between the underlying alt-blockchain and the alt-XCP, such as having the alt-chain enforce a 1:1 alt-token to alt-XCP mapping.

I have been developing an idea for a Proof-of-Stake backed Counterparty Protocol XCP Side-chain. Most people think of Merged Mining when they think of Side-chains; this does not apply in this case due to the different Proof of Work and Proof of Stake economic measures that would be utilized. In this case I would refer to this as a “Complimentary Chain”.

The XCP POS Complimentary Chain would only contain the relevant XCP transactions from the BTC Blockchain. And probably in a Mini-Blockchain manner as described here - http://cryptonite.info/files/mbc-scheme-rev2.pdf. So it would be more of a database of XCP data. “Miners” in this POS network compete to ensure that this database is kept up to date.

If that was the entire idea, I think that it would be a curious experiment just to see do the staked “miners” always maintain the correct Complimentary Blockchain/Mini-Blockchain, and how to deal with a situation if they don’t (perhaps consensus amongst a few “miners”).

However, the exciting bit is when a random XCP user performs a Counterparty Transaction. They can broadcast the transaction to the XCP POS Complimentary network and “trust” that that network will relay/broadcast it to the Bitcoin Network. But the benefit here is that it would appear very quickly in the XCP POS Complimentary Blockchain in anticipation of being included in the Bitcoin Blockchain! In this scenario, maybe we could give any burnt XCP to the POS “miners” as a transaction fee.

I think a nice consequence here is that one is trusting the POS network to relay the transaction to the Bitcoin Network but balances are updated quickly to resolve transactions/matches etc. However a user wouldn’t be able to spend (double-spend) some XCP tokens again until confirmed in the Bitcoin Blockchain.

This idea is obviously not complete in my mind but I am looking to share it with people to hopefully develop it further.

TLDR: Two Blockchains, 1 is the Bitcoin Blockchain (POW) , the other is a custom XCP Blockchain (POS) and it is like a dedicated XCP database including a structured Mem-pool of XCP transactions that will be included in the next few Bitcoin Blocks.

Discuss.


I have been developing an idea for a Proof-of-Stake backed Counterparty Protocol XCP Side-chain. Most people think of Merged Mining when they think of Side-chains; this does not apply in this case due to the different Proof of Work and Proof of Stake economic measures that would be utilized. In this case I would refer to this as a “Complimentary Chain”.

The XCP POS Complimentary Chain would only contain the relevant XCP transactions from the BTC Blockchain. And probably in a Mini-Blockchain manner as described here - http://cryptonite.info/files/mbc-scheme-rev2.pdf. So it would be more of a database of XCP data. “Miners” in this POS network compete to ensure that this database is kept up to date.

If that was the entire idea, I think that it would be a curious experiment just to see do the staked “miners” always maintain the correct Complimentary Blockchain/Mini-Blockchain, and how to deal with a situation if they don’t (perhaps consensus amongst a few “miners”).

However, the exciting bit is when a random XCP user performs a Counterparty Transaction. They can broadcast the transaction to the XCP POS Complimentary network and “trust” that that network will relay/broadcast it to the Bitcoin Network. But the benefit here is that it would appear very quickly in the XCP POS Complimentary Blockchain in anticipation of being included in the Bitcoin Blockchain! In this scenario, maybe we could give any burnt XCP to the POS “miners” as a transaction fee.

I think a nice consequence here is that one is trusting the POS network to relay the transaction to the Bitcoin Network but balances are updated quickly to resolve transactions/matches etc. However a user wouldn’t be able to spend (double-spend) some XCP tokens again until confirmed in the Bitcoin Blockchain.

This idea is obviously not complete in my mind but I am looking to share it with people to hopefully develop it further.

TLDR: Two Blockchains, 1 is the Bitcoin Blockchain (POW) , the other is a custom XCP Blockchain (POS) and it is like a dedicated XCP database including a structured Mem-pool of XCP transactions that will be included in the next few Bitcoin Blocks.

Discuss.

I of course meant to write “Complementary” Chain and not “Complimentary”. Unfortunately, this forum does not allow one to edit their post after 24 hours have elapsed.

Complementary Chain Concept Recap

[1] The Counterparty Protocol Data within the Bitcoin Blockchain is a subset of the Bitcoin Blockchain.
[2] Another Blockchain could be launched which only contains Counterparty Data - this would be a type of Side-Chain.
[3] This Complementary Blockchain could be secured by any economic measure (Proof-of-Work, Proof-of-Stake etc.), though a form of Proof-of-Stake (XCP ownership) may be ideal to avoid any possibility of merged-mining and the associated attacks.
[4] This trusted Complementary Blockchain could receive Counterparty transactions in the exact same format as they are broadcast to the Bitcoin network currently.
[5] Counterparty transactions could be broadcast to (a) only the Bitcoin Network, (b) only the Complementary Network or © both; depending on the application.
[6] In the case of Counterparty Transactions being exclusively broadcast to the Complementary Network, they would have to be relayed on to the Bitcoin Network by the Complementary Network. [Not every transaction needs to be relayed. Just some information
to update the lastest address balances. This allows for off-chain (off-Bitcoin-Blockchain transactions)].
[7] Various Complementary Chains could launch to take sole responsibility for different types of transactions (e.g. there could be a Decentralised Exchange Chain, a Message Broadcast Chain etc.)
[8] One could choose to trust whichever Blockchain they want - the Counterparty data in the Bitcoin Blockchain or the Counterparty Data in the Complementary Blockchain.

I feel that this idea to create a set of application specific Counterparty Complementary Chains is starting to take shape. But I need more discourse with the community in case I have made some serious mistakes. I think this approach solves some of the potential problems with Side-Chains, but it no doubt raises some problems of it’s own (though I can’t think of any obvious ones).

Some interesting information about a mini-blockchain implementation here - http://letstalkbitcoin.com/blog/post/beyond-bitcoin-18-cryptonite. Not that a Counterparty Complementary Chain would necessarily need to have a Mini-Blockchain.

I’ve been having an initial interaction with the developer of Cryptonite about his Mini Blockchain technology here - https://bitcointalk.org/index.php?topic=713538.msg9212209#msg9212209.

A Complementary/Side Chain Mini Blockchain could potentially serve quite eloquently as a component of Counterparty’s decentralized exchange.

This definitely needs to happen. Things are going to get way too confusing when there is like 10 different versions of XCP all on different blockchains with their own burn periods and duplicate asset names on each one. 

I believe the killer app for BTC 2.0 in general is when crosschain talking and quick reinitialization of an asset group can happen on any platform. 


So I am interested in side-chain/tree-chains as a possible solution. Though there are some considerations to keep in mind:

1) Consensus: There will be a delay between the main chain and its side-chains, so there has to be some kind of compensation mechanism that (ideally) should work in between the approximate time it takes for a block to confirm on the Bitcoin blockchain (since we are saying that Counterparty is the ‘canonical’ chain, and other are more or less backups of that chain)

2) Availability/consistency during a reorg - This is super important but not quite sure how to approach it - If a reorg occurs, then the data will change, we should have a mechanism to rollback the state of the chain if this should ever occur.

I think that complmentary chains are a great topic and might have a ton of heft in making crosstalk between bitcoin 2.0 projects more viable. 

If we keep bringing this topic up then someone will have to try it!

Thanks for your feedback. I’ll address your consensus and reorg comments tomorrow!

A Sidechains white paper has been released - http://www.blockstream.com/sidechains.pdf.

There is a strong backlash to the Blockstream (http://blockstream.com) proposed implementation of Sidechains - https://www.reddit.com/r/Bitcoin/comments/2k2j8f/austin_hill_ceo_of_blockstream_will_soon_have_a/.

I am convinced that Sidechains are easier to implement at the Counterparty Protocol Level rather than at the Bitcoin Protocol Level. This is an opportune time for the Counterparty community to outline a Sidechains development roadmap. We could have Sidechains for dedicated Assets or Sidechains for dedicated functionality (trading on the Dex).

Please join the discussion here!

I think I need to simplify this thread in light of the increased interest in/awareness of Sidechains with the Blockstream team announcement.

The Bitcoin Blockchain is big and strong and secure and reliable. But it is also relatively slow. So not every application that could benefit from a trustless distributed pubic ledger system (and particularly from it’s unparalleled security) can function optimally on the Bitcoin Blockchain.

It would be useful to have additional Blockchains that have different behaviors/rules. I.e. You make these sidechains fit the application rather than making the application fit the Bitcoin Blockchain.

The difficulty is in communicating between the Blockchains. This should involve “locking” some tokens on the parent chain (e.g. Bitcoin Blockchain) and issuing a related amount of Sidechain tokens such that these Sidechain tokens can be moved around within their own Sidechain as normal.

So far, this is very like the Proof of Burn method used to instantiate XCP balances of the Counterparty Protocol. But this was an irreversible process. The attraction of Sidechains as an idea is that one could send the Sidechain tokens back to redeem the originally locked parent tokens.

To do so, one should have a way of “locking” the Sidechain tokens and verifying that they are “locked” in the Parent Chain, such that the originally locked Parent Chain tokens become unlocked and useable again (as normal).

TLDR:

[1] “Lock” a Counterparty Asset (e.g. 10 XCP) in the Counterparty Protocol (embedded in the Bitcoin Blockchain), using a new Lock Transaction.
[2] Receive Sidechain Asset (e.g. 10 SXCP) and move around the sidechain as normal.
[3] Burn the 10 SXCP in the Sidechain.
[4] Broadcast an “Unlock” 10 XCP transaction to the Sidechain miners.
[5] Sidechain miners agree that the 10 SXCP was burned and the requested XCP unlock trasaction is broadcast to the BTC miners.
[6] The Counterparty Protocol unlocks the originally locked XCP.