[ANN][XCP] Counterparty - Pioneering Peer-to-Peer Finance - Official Thread

[iwillimust]

So one day in the near future, maybe 2 - 5 years out, when 1% - 5% of online transactions take place in Bitcoin, and 1% - 5% of the stock market has moved to Counterparty, I think it becomes obvious that pretty quickly it will no longer be feasible to run your own node that actually keeps the entire blockchain. Anyone have any thoughts on that ?

You think I think it is very creative
Why can you talk about your ideas
Very interested in

[1714485088]

1714485088

[1714485088]

1714485088

[1714485088]

1714485088

[1714485088]

1714485088

[CryptoFinanceUK]

Does any sort of collateralization requirement denominated in XCP limit the total amount of assets that can be traded on the exchange to the market cap of XCP? How do you work out the margin requirement? Or is the idea that any asset in one's possession can be used as collateral, but represented as an XCP equivalent?

In a world with XCP backed assets, one way I could imagine this working would be that the current market price of the asset (based on a price feed) would be locked away when the asset was created, and the issuer would place a bet to cover future variations in the price, up to a disclosed bet size, and future date.

An issuer could choose the amount of margin they want to put up, and when they run out, the asset would be automatically liquidated. This would have the side effect of dumpling an asset holder back into XCP if a market got volatile, but I think it could dramatically reduce counterparty risk (and everyone would know were they stood).

When issuing a $1 USD token, an issuer would lock away $1 worth of XCP to create the asset, and might choose to commit, say, another 25% to cover variation. So $1.25 worth of XCP might be locked away per USD token. They could sell the token to get $1 of XCP back, so they'd basically be net a long XCP bet.

I can imagine that this kind of usage would increase the scarcity of XCP and push the price up (so in the next round a unit of XCP could back a larger dollar value of assets, and so on).

Something like this could work in parallel with unbacked assets, and I could also imagine having fractionally backed assets, so users would have greater choice.

EDIT: Clarity

[cityglut]

Does any sort of collateralization requirement denominated in XCP limit the total amount of assets that can be traded on the exchange to the market cap of XCP? How do you work out the margin requirement? Or is the idea that any asset in one's possession can be used as collateral, but represented as an XCP equivalent?

In a world with XCP backed assets, one way I could imagine this working would be that the current market price of the asset (based on a price feed) would be locked away when the asset was created, and the issuer would place a bet to cover future variations in the price, up to a disclosed bet size, and future date.

An issuer could choose the amount of margin they want to put up, and when they run out, the asset would be automatically liquidated. This would have the side effect of dumpling an asset holder back into XCP if a market got volatile, but I think it could dramatically reduce counterparty risk, and everyone would know were they stood.

When issuing, an issuer would lock away $1 worth of XCP to create the asset, and might choose to commit, say, another 25% to cover variation. So $1.25 worth of XCP might be locked away per USD token. They could sell the token to get $1 of XCP back, so they'd basically be net a long XCP bet.

I can imagine that this kind of usage would increase the scarcity of XCP and push the price up (so in the next round a unit of XCP could back a larger dollar value of assets, and so on).

You cannot eliminate counterparty risk from an asset-backed currency peg, as there is no mechanism at the protocol level to stop the issuer (i.e. the user with the private key of the address with the XCP backing) from withdrawing funds. I still think though that is a really good use-case.

A currency peg that actually requires no trust is making a CFD on the price of an asset to which you would like to peg your holdings in XCP. The effectiveness of the peg, however, depends on one's leverage, which in turn increases one's risk. For anyone who is interested in making such a peg, I have come up with a few examples which would show how you do it.

[freedomfighter]

Here is a post just now by Mark F.- a BTC core developer explaining the issue as JGarzik did in previous posts here. I only bring it because even-though, again, I dont really like a paragraph such as his last one, I think that we should continue and speak to them as partners. so... his writing also requires a response in my book. 

Mark Friedenbach • 5 minutes ago
You say that "Counterparty users pay fees to Bitcoin miners who process their transactions." However it is not miners which process their transactions, it is the set of fully-validating nodes of which large mining pools make up a mere 0.01%. To the rest of these participants in the bitcoin network, processing of transactions is a fully externalized cost - you have electricity and storage expenses for running a full node but don't see a single satoshi of transaction fees in compensation.

This is a fundamental incentive problem with bitcoin today, and the parasitic use of the block chain as a publication system for Counterparty, Mastercoin, etc. is exacerbating the problem without any attempt to provide a solution. If and until the incentive problem is fixed (it's not clear it can be!) these groups should be doing their transactions on a separately validated side-chain, so only those users who opt-in to running the side chain incur the cost. Hopefully using 2-way pegging so their currency can be bitcoins, if they want to avoid the scummy currency issuance investment model.

If they don't do this, they are forceably extracting a rent from those current users of the bitcoin network which did not expect to be processing these transactions without pay when they started using bitcoin.

We are not hostile to this kind of innovation. In fact, I co-authored a distributed p2p exchange model using bitcoin side-chains accomplishing the same things as Counterparty and published six months before Counterpart started their development:

http://freico.in/docs/freimark...

What we are against is extorting other participants of the bitcoin network into processing your transactions which were not in the original social contract of bitcoin, especially when clearly explained alternatives exist. That is frankly evil, although I'll give you the benefit of the doubt and chalk it up to ignorance. This time.

Mark Friedenbach
Bitcoin Core developer
 

[CryptoFinanceUK]

Does any sort of collateralization requirement denominated in XCP limit the total amount of assets that can be traded on the exchange to the market cap of XCP? How do you work out the margin requirement? Or is the idea that any asset in one's possession can be used as collateral, but represented as an XCP equivalent?

In a world with XCP backed assets, one way I could imagine this working would be that the current market price of the asset (based on a price feed) would be locked away when the asset was created, and the issuer would place a bet to cover future variations in the price, up to a disclosed bet size, and future date.

An issuer could choose the amount of margin they want to put up, and when they run out, the asset would be automatically liquidated. This would have the side effect of dumpling an asset holder back into XCP if a market got volatile, but I think it could dramatically reduce counterparty risk, and everyone would know were they stood.

When issuing, an issuer would lock away $1 worth of XCP to create the asset, and might choose to commit, say, another 25% to cover variation. So $1.25 worth of XCP might be locked away per USD token. They could sell the token to get $1 of XCP back, so they'd basically be net a long XCP bet.

I can imagine that this kind of usage would increase the scarcity of XCP and push the price up (so in the next round a unit of XCP could back a larger dollar value of assets, and so on).

You cannot eliminate counterparty risk from an asset-backed currency peg, as there is no mechanism at the protocol level to stop the issuer (i.e. the user with the private key of the address with the XCP backing) from withdrawing funds. I still think though that is a really good use-case.

A currency peg that actually requires no trust is making a CFD on the price of an asset to which you would like to peg your holdings in XCP. The effectiveness of the peg, however, depends on one's leverage, which in turn increases one's risk. For anyone who is interested in making such a peg, I have come up with a few examples which would show how you do it.

Thanks cityglut, pity, something like this would have been very cool 

[cityglut]

Does any sort of collateralization requirement denominated in XCP limit the total amount of assets that can be traded on the exchange to the market cap of XCP? How do you work out the margin requirement? Or is the idea that any asset in one's possession can be used as collateral, but represented as an XCP equivalent?

In a world with XCP backed assets, one way I could imagine this working would be that the current market price of the asset (based on a price feed) would be locked away when the asset was created, and the issuer would place a bet to cover future variations in the price, up to a disclosed bet size, and future date.

An issuer could choose the amount of margin they want to put up, and when they run out, the asset would be automatically liquidated. This would have the side effect of dumpling an asset holder back into XCP if a market got volatile, but I think it could dramatically reduce counterparty risk, and everyone would know were they stood.

When issuing, an issuer would lock away $1 worth of XCP to create the asset, and might choose to commit, say, another 25% to cover variation. So $1.25 worth of XCP might be locked away per USD token. They could sell the token to get $1 of XCP back, so they'd basically be net a long XCP bet.

I can imagine that this kind of usage would increase the scarcity of XCP and push the price up (so in the next round a unit of XCP could back a larger dollar value of assets, and so on).

You cannot eliminate counterparty risk from an asset-backed currency peg, as there is no mechanism at the protocol level to stop the issuer (i.e. the user with the private key of the address with the XCP backing) from withdrawing funds. I still think though that is a really good use-case.

A currency peg that actually requires no trust is making a CFD on the price of an asset to which you would like to peg your holdings in XCP. The effectiveness of the peg, however, depends on one's leverage, which in turn increases one's risk. For anyone who is interested in making such a peg, I have come up with a few examples which would show how you do it.

Thanks cityglut, pity, something like this would have been very cool 

It's still a good service! And indeed I think that if a trusted exchange (or even a trusted community member) were to implement something like this on Counterparty, it would gain adoption.

[CryptoFinanceUK]

For anyone who is interested in making such a peg, I have come up with a few examples which would show how you do it.

It's still a good service! And indeed I think that if a trusted exchange (or even a trusted community member) were to implement something like this on Counterparty, it would gain adoption.

Great, maybe you could drop us a link / point us to your examples?

[Matt Y]

Newbie here.  So is proof-of-burn still how people are buying these?  Or should I buy through Poloniex?

I was a rookie
Hope to get help from others
Someone to help us?

Proof of burn is over. The easiest way to buy is on Poloniex or Bter.

[baddw]

Here is a post just now by Mark F.- a BTC core developer explaining the issue as JGarzik did in previous posts here. I only bring it because even-though, again, I dont really like a paragraph such as his last one, I think that we should continue and speak to them as partners. so... his writing also requires a response in my book. 

Mark Friedenbach • 5 minutes ago
You say that "Counterparty users pay fees to Bitcoin miners who process their transactions." However it is not miners which process their transactions, it is the set of fully-validating nodes of which large mining pools make up a mere 0.01%. To the rest of these participants in the bitcoin network, processing of transactions is a fully externalized cost - you have electricity and storage expenses for running a full node but don't see a single satoshi of transaction fees in compensation.
(snip)

My reply on the letstalkbitcoin comment thread:

"Yes, and any and all of those nodes are free to stop running at any time and to delete the blockchain from their hard drives. They run bitcoind/Bitcoin-QT and store the blockchain because they have some incentive to do so. The fact that this incentive is not explicit (i.e., direct compensation) does not mean that it does not exist. The cost of running a node is miniscule compared to the cost of mining. And there are plenty of minimal wallet programs out there that do not store the entire blockchain."

[BldSwtTrs]

What sucks is that while the term Decentralized exchange let imagine the possibility of the elimination of third party risk, actually there is a lot more counterparty risk by using it. (I prefer trust Bitstamp or Cryptsy than a random asset issuer on top of counterparty, and it's not even close).

[halfcab123]

Highest volume on BTER goes to? XCP.

[xnova]

Here is a post just now by Mark F.- a BTC core developer explaining the issue as JGarzik did in previous posts here. I only bring it because even-though, again, I dont really like a paragraph such as his last one, I think that we should continue and speak to them as partners. so... his writing also requires a response in my book. 

Mark Friedenbach • 5 minutes ago
You say that "Counterparty users pay fees to Bitcoin miners who process their transactions." However it is not miners which process their transactions, it is the set of fully-validating nodes of which large mining pools make up a mere 0.01%. To the rest of these participants in the bitcoin network, processing of transactions is a fully externalized cost - you have electricity and storage expenses for running a full node but don't see a single satoshi of transaction fees in compensation.

This is a fundamental incentive problem with bitcoin today, and the parasitic use of the block chain as a publication system for Counterparty, Mastercoin, etc. is exacerbating the problem without any attempt to provide a solution. If and until the incentive problem is fixed (it's not clear it can be!) these groups should be doing their transactions on a separately validated side-chain, so only those users who opt-in to running the side chain incur the cost. Hopefully using 2-way pegging so their currency can be bitcoins, if they want to avoid the scummy currency issuance investment model.

If they don't do this, they are forceably extracting a rent from those current users of the bitcoin network which did not expect to be processing these transactions without pay when they started using bitcoin.

We are not hostile to this kind of innovation. In fact, I co-authored a distributed p2p exchange model using bitcoin side-chains accomplishing the same things as Counterparty and published six months before Counterpart started their development:

http://freico.in/docs/freimark...

What we are against is extorting other participants of the bitcoin network into processing your transactions which were not in the original social contract of bitcoin, especially when clearly explained alternatives exist. That is frankly evil, although I'll give you the benefit of the doubt and chalk it up to ignorance. This time.

Mark Friedenbach
Bitcoin Core developer
 

Matt Y from our team spoke to Mark recently at Coinsummit. Mark is a very bright individual and has echoed some valid concerns. We are in the process of reaching out to Mark and hope to get a call going between him and I, so that we can begin to build a dialogue together on this topic and work towards a resolution that is acceptable for all parties.

[baddw]

What sucks is that while the term Decentralized exchange let imagine the possibility of the elimination of third party risk, actually there is a lot more counterparty risk by using it. (I prefer trust Bitstamp or Cryptsy than a random asset issuer on top of counterparty, and it's not even close).

The thing is, a centralized exchanged like Bitstamp or Cryptsy is really complicated, and you can't read the source.  There are potential vulnerabilities throughout their entire systems.

An asset issuer on Counterparty needs only do one thing correctly: hold the asset.  They don't need to make sure their wallet software is updated, they don't need to match orders correctly, they don't need to keep orders on the books.  They only have to do one thing, and that one thing can be provable (such as providing bank statements, photos of physical assets, etc.).  The rest is on the Counterparty implementation, which is open-source.

Do you trust that Cryptsy owns the correct amount of coins for the 50+ coins that they trade?  And that a vulnerability in one of the wallets in one of those coins won't lead people to make fake deposits, trade those fake coins for BTC, cash out the BTC and leave Cryptsy with nothing but a bunch of fake coins?  (Like supposedly happened with CryptoRush and BlackCoin?)

I'm not trying to pick on Cryptsy here, I use them myself and trust them more than I trust other centralized exchanges.  But for them to prove to me that they have all the required coin balances for 50 different coins would be quite complicated.  And then they would have to prove to me that their exchange code can't be cheated.

[BitcoinTangibleTrust]

What sucks is that while the term Decentralized exchange let imagine the possibility of the elimination of third party risk, actually there is a lot more counterparty risk by using it. (I prefer trust Bitstamp or Cryptsy than a random asset issuer on top of counterparty, and it's not even close).

The thing is, a centralized exchanged like Bitstamp or Cryptsy is really complicated, and you can't read the source.  There are potential vulnerabilities throughout their entire systems.

An asset issuer on Counterparty needs only do one thing correctly: hold the asset.  They don't need to make sure their wallet software is updated, they don't need to match orders correctly, they don't need to keep orders on the books.  They only have to do one thing, and that one thing can be provable (such as providing bank statements, photos of physical assets, etc.).  The rest is on the Counterparty implementation, which is open-source.

+1 Indeed.

[freedomfighter]

Here is a post just now by Mark F.- a BTC core developer explaining the issue as JGarzik did in previous posts here. I only bring it because even-though, again, I dont really like a paragraph such as his last one, I think that we should continue and speak to them as partners. so... his writing also requires a response in my book. 

Mark Friedenbach • 5 minutes ago
You say that "Counterparty users pay fees to Bitcoin miners who process their transactions." However it is not miners which process their transactions, it is the set of fully-validating nodes of which large mining pools make up a mere 0.01%. To the rest of these participants in the bitcoin network, processing of transactions is a fully externalized cost - you have electricity and storage expenses for running a full node but don't see a single satoshi of transaction fees in compensation.

This is a fundamental incentive problem with bitcoin today, and the parasitic use of the block chain as a publication system for Counterparty, Mastercoin, etc. is exacerbating the problem without any attempt to provide a solution. If and until the incentive problem is fixed (it's not clear it can be!) these groups should be doing their transactions on a separately validated side-chain, so only those users who opt-in to running the side chain incur the cost. Hopefully using 2-way pegging so their currency can be bitcoins, if they want to avoid the scummy currency issuance investment model.

If they don't do this, they are forceably extracting a rent from those current users of the bitcoin network which did not expect to be processing these transactions without pay when they started using bitcoin.

We are not hostile to this kind of innovation. In fact, I co-authored a distributed p2p exchange model using bitcoin side-chains accomplishing the same things as Counterparty and published six months before Counterpart started their development:

http://freico.in/docs/freimark...

What we are against is extorting other participants of the bitcoin network into processing your transactions which were not in the original social contract of bitcoin, especially when clearly explained alternatives exist. That is frankly evil, although I'll give you the benefit of the doubt and chalk it up to ignorance. This time.

Mark Friedenbach
Bitcoin Core developer
 

Matt Y from our team spoke to Mark recently at Coinsummit. Mark is a very bright individual and has echoed some valid concerns. We are in the process of reaching out to Mark and hope to get a call going between him and I, so that we can begin to build a dialogue together on this topic and work towards a resolution that is acceptable for all parties.

This is excellent and highly professional. Thanks for the update. There are also some good responses to his post from various individuals.

[porqupine]

How is this a comment from a bright individual you can reach out to? It's just another Luke Jr.

What we are against is extorting other participants of the bitcoin network into processing your transactions which were not in the original social contract of bitcoin, especially when clearly explained alternatives exist. That is frankly evil, although I'll give you the benefit of the doubt and chalk it up to ignorance. This time.

[l4p7]

What sucks is that while the term Decentralized exchange let imagine the possibility of the elimination of third party risk, actually there is a lot more counterparty risk by using it. (I prefer trust Bitstamp or Cryptsy than a random asset issuer on top of counterparty, and it's not even close).

The thing is, a centralized exchanged like Bitstamp or Cryptsy is really complicated, and you can't read the source.  There are potential vulnerabilities throughout their entire systems.

An asset issuer on Counterparty needs only do one thing correctly: hold the asset.  They don't need to make sure their wallet software is updated, they don't need to match orders correctly, they don't need to keep orders on the books.  They only have to do one thing, and that one thing can be provable (such as providing bank statements, photos of physical assets, etc.).  The rest is on the Counterparty implementation, which is open-source.

Do you trust that Cryptsy owns the correct amount of coins for the 50+ coins that they trade?  And that a vulnerability in one of the wallets in one of those coins won't lead people to make fake deposits, trade those fake coins for BTC, cash out the BTC and leave Cryptsy with nothing but a bunch of fake coins?  (Like supposedly happened with CryptoRush and BlackCoin?)

I'm not trying to pick on Cryptsy here, I use them myself and trust them more than I trust other centralized exchanges.  But for them to prove to me that they have all the required coin balances for 50 different coins would be quite complicated.  And then they would have to prove to me that their exchange code can't be cheated.

What advantage does an issuer have when issuing for example XLTC on Counterparty?

 

[cityglut]

For anyone who is interested in making such a peg, I have come up with a few examples which would show how you do it.

It's still a good service! And indeed I think that if a trusted exchange (or even a trusted community member) were to implement something like this on Counterparty, it would gain adoption.

Great, maybe you could drop us a link / point us to your examples?

I've PMed you.

[Matt Y]

There is a lot of emotion over the data storage topic right now on both sides and that's understandable. There is also a lot of bad information being circulated.

I am not going to judge Mark on a statement or two that I don't agree with. Mark proved to be very reasonable in our discussion at CoinSummit. He had some interesting ideas and is willing to have discussions with the Counterparty developers that will allow us to work towards a solution together. It was obvious that mark cares deeply about Bitcoin as well as the ethics and motivations of other projects in the digital currency space.

[l4p7]

Does any sort of collateralization requirement denominated in XCP limit the total amount of assets that can be traded on the exchange to the market cap of XCP? How do you work out the margin requirement? Or is the idea that any asset in one's possession can be used as collateral, but represented as an XCP equivalent?

In a world with XCP backed assets, one way I could imagine this working would be that the current market price of the asset (based on a price feed) would be locked away when the asset was created, and the issuer would place a bet to cover future variations in the price, up to a disclosed bet size, and future date.

An issuer could choose the amount of margin they want to put up, and when they run out, the asset would be automatically liquidated. This would have the side effect of dumpling an asset holder back into XCP if a market got volatile, but I think it could dramatically reduce counterparty risk, and everyone would know were they stood.

When issuing, an issuer would lock away $1 worth of XCP to create the asset, and might choose to commit, say, another 25% to cover variation. So $1.25 worth of XCP might be locked away per USD token. They could sell the token to get $1 of XCP back, so they'd basically be net a long XCP bet.

I can imagine that this kind of usage would increase the scarcity of XCP and push the price up (so in the next round a unit of XCP could back a larger dollar value of assets, and so on).

You cannot eliminate counterparty risk from an asset-backed currency peg, as there is no mechanism at the protocol level to stop the issuer (i.e. the user with the private key of the address with the XCP backing) from withdrawing funds. I still think though that is a really good use-case.

A currency peg that actually requires no trust is making a CFD on the price of an asset to which you would like to peg your holdings in XCP. The effectiveness of the peg, however, depends on one's leverage, which in turn increases one's risk. For anyone who is interested in making such a peg, I have come up with a few examples which would show how you do it.

as there is no mechanism at the protocol level to stop the issuer (i.e. the user with the private key of the address with the XCP backing) from withdrawing funds

But would it be possibility to implement such a mechanism: The issuer of XLTC sends the funds to a LTC wallet within the Counterparty system....