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

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?

No rush just curious if we're on target for first week of April with the web wallet on mainnet? And is there anything I can do to help ?

Peter Todd has already explained why this is not a good idea: https://bitcointalksearch.org/topic/m.5824434

  , dexX7 must have dozens of nefarious tricks up his sleeves already if it ever gets to the cat and mouse game as someone puts it earlier.

What else does it take for the devs to realize that OP_RETURN is the OP_SCRIPT_SUPER_EXTENSION for transactions at the upper layers?
Instead the simple OP_RETURN is still being painted as just storing data when there are countless ways to do that already.

A recent comment on the LTB article (good one by the way except that it is abit too emotional in its 2nd part in my view):

"Firstly... Just ignore Luke-JR, everyone should do this and we will all be better for it.

Secondly... Mike Hearn seemed to have a good compromise solution where OP_Return was used to store a pointer to the data that is stored elsewhere...

So you get the benefits of being on the blockchain, and lessen the load on the network. Win win?

Dear DEVS: is this being discussed? is there an internal dialogue/discussion beyond the REDDIT and the articles?