Topic: [ANN][XCP] Counterparty - Pioneering Peer-to-Peer Finance - Official Thread - page 348. (Read 1277015 times)

+1 Indeed.

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.

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.

Highest volume on BTER goes to? XCP.

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).

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."

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

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

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.

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

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
 

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.

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

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

Thanks.

Counterparty is in no danger of being kicked off the Bitcoin blockchain.

We have contacted some of the Bitcoin core developers, though there is nothing in particular to report. We will let the community know if something comes up.

Upvoted!

Fine. I have to admit that the technical details are above my head. I trust that the you guys with the other devs will determine what is possible even if not ideal to all. What i keep trying to find out is whether there is a dialouge going on or is this a stalemate or will it develop to a cat and mouse game.

As I expressed in several places throughout the past 25 pages: the best solution is to find the common path and create a win win. CP has a great interest to stay on top of BTC and not have to look elsewhere. While we all know that CP is great for bitcoin.

This is why we need to reach consensus with the BTC team

If I am not mistaken, most of the simple operations should take less than 40 bytes already for both MSC and XCP.

It just makes it unnecessarily complicated for feeds, asset issuances, etc..when a few more bytes could keep things simple.

e.g. for some operations like asset issuance we could make two or more OP_RETURN40 operations.  But it's even more bloat.

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?