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

[peled1986]

http://xcpbank.com/ are selling XCP.
they replay fast to e-mails.
i bought 1 xcp from them as a "test".
they seem legit.

what price did you get?

0.01 BTC per XCP but they give 20-25% bulk discounts.

[1714773447]

1714773447

[1714773447]

1714773447

[1714773447]

1714773447

[1714773447]

1714773447

[nakaone]

I have a question about Dividends. It relates to my previous question. Again it seems that trust in the issuer plays a giant role here. If we cannot completely trust the issuer, the value of the asset needs to be discounted.

Is there a way to create trustless assets? There seems to be a way to put BTC into escrow and I assume the same for XCP. I might have missed this, but is there a way to designate an Asset as being backed by assets in escrow? That way, the purchaser of an asset would have the option of always just redeeming it for the amount in escrow. For things like pooled BTC (XCP) funds, it can be 100% backed by escrow and there would be no risk of default or funny business.

If there was a way to put other cryptos in escrow, then a crypto fund could be setup, closed ended for sure, maybe even open ended and it could be composed of a variety of altcoins and BTC providing a diversified portfolio to reduce risk in this volatile market.

Further risk could be removed (or income produced) by buying put options or selling call options. I am envisioning professionally managed crypto portfolio that doesn't require trust!

Any chance of this anytime soon? Anytime at all?

James

Soon...Soon!

by the moment you get that managed, xcp will be one of the most valueable altcoins

[wizzardTim]

I have a question about Dividends. It relates to my previous question. Again it seems that trust in the issuer plays a giant role here. If we cannot completely trust the issuer, the value of the asset needs to be discounted.

Is there a way to create trustless assets? There seems to be a way to put BTC into escrow and I assume the same for XCP. I might have missed this, but is there a way to designate an Asset as being backed by assets in escrow? That way, the purchaser of an asset would have the option of always just redeeming it for the amount in escrow. For things like pooled BTC (XCP) funds, it can be 100% backed by escrow and there would be no risk of default or funny business.

If there was a way to put other cryptos in escrow, then a crypto fund could be setup, closed ended for sure, maybe even open ended and it could be composed of a variety of altcoins and BTC providing a diversified portfolio to reduce risk in this volatile market.

Further risk could be removed (or income produced) by buying put options or selling call options. I am envisioning professionally managed crypto portfolio that doesn't require trust!

Any chance of this anytime soon? Anytime at all?

James

Soon...Soon!

by the moment you get that managed, xcp will be one of the most valueable altcoins

1 BTC = 1 XCP!!

[led_lcd]

http://xcpbank.com/ are selling XCP.
they replay fast to e-mails.
i bought 1 xcp from them as a "test".
they seem legit.

edit: the site seems still under much develpoment.

That was quite fast.

If the developers of the site are hanging around, there is a typo on the front page:

core bitcon protocol

[SyRenity]

What is MPSTOCK? Why is it so expensive? 2000 XCP/MPSTOCK!!!

http://blockscan.com/order.aspx?q=2866

See http://blockscan.com/assetInfo.aspx?q=MPTSTOCK (MoneypakTrader.com)

Which is also linked to the richest single XCP account. Looks like he issued an asset MPTSTOCK and repurchased the assets with XCP making this the richest account http://blockscan.com/address.aspx?q=1FCkCQCnEtHQ3j7NqdkAnkqQUvqfti4XoA

Cheers

What was the point of that? To hide any XCP sends from other accounts?

[SyRenity]

By the way, I have a question - how exactly XCP will support paying in BTC for asset or XCP?

The offered BTC will be matched to offers on asset/Dex, and once the buyer sends the bTC to seller address, the seller will then send back XCP or asset shares back to the buyer BTC address?

[BitThink]

By the way, I have a question - how exactly XCP will support paying in BTC for asset or XCP?

The offered BTC will be matched to offers on asset/Dex, and once the buyer sends the bTC to seller address, the seller will then send back XCP or asset shares back to the buyer BTC address?

I think there's a sendBTC command to complete a matched order involving BTC.

[cityglut]

By the way, I have a question - how exactly XCP will support paying in BTC for asset or XCP?

The offered BTC will be matched to offers on asset/Dex, and once the buyer sends the bTC to seller address, the seller will then send back XCP or asset shares back to the buyer BTC address?

Let's say Alice is selling BTC for XCP with a 5 block expiration on her order and Sally is selling XCP for BTC with a 3 block expiration on her order, and their orders get matched. Upon the matching, the protocol debits the XCP from Sally's account, and then Alice has 3 blocks to send Sally her BTC using the btc-pay command. If Alice fails to send Sally BTC within 3 blocks, the deal is cancelled and Sally's account gets re-credited with the XCP.

[peled1986]

By the way, I have a question - how exactly XCP will support paying in BTC for asset or XCP?

The offered BTC will be matched to offers on asset/Dex, and once the buyer sends the bTC to seller address, the seller will then send back XCP or asset shares back to the buyer BTC address?

Let's say Alice is selling BTC for XCP with a 5 block expiration on her order and Sally is selling XCP for BTC with a 3 block expiration on her order, and their orders get matched. Upon the matching, the protocol debits the XCP from Sally's account, and then Alice has 3 blocks to send Sally her BTC using the btc-pay command. If Alice fails to send Sally BTC within 3 blocks, the deal is cancelled and Sally's account gets re-credited with the XCP.

good explanation.

[jl777]

By the way, I have a question - how exactly XCP will support paying in BTC for asset or XCP?

The offered BTC will be matched to offers on asset/Dex, and once the buyer sends the bTC to seller address, the seller will then send back XCP or asset shares back to the buyer BTC address?

Let's say Alice is selling BTC for XCP with a 5 block expiration on her order and Sally is selling XCP for BTC with a 3 block expiration on her order, and their orders get matched. Upon the matching, the protocol debits the XCP from Sally's account, and then Alice has 3 blocks to send Sally her BTC using the btc-pay command. If Alice fails to send Sally BTC within 3 blocks, the deal is cancelled and Sally's account gets re-credited with the XCP.

Is there a way to set it up so the btcpay is done automatically?

[lonsharim]

By the way, I have a question - how exactly XCP will support paying in BTC for asset or XCP?

The offered BTC will be matched to offers on asset/Dex, and once the buyer sends the bTC to seller address, the seller will then send back XCP or asset shares back to the buyer BTC address?

Let's say Alice is selling BTC for XCP with a 5 block expiration on her order and Sally is selling XCP for BTC with a 3 block expiration on her order, and their orders get matched. Upon the matching, the protocol debits the XCP from Sally's account, and then Alice has 3 blocks to send Sally her BTC using the btc-pay command. If Alice fails to send Sally BTC within 3 blocks, the deal is cancelled and Sally's account gets re-credited with the XCP.

Just to be clear - when Sally's account is debited, are they immediately credited with Alice? or only after Alice sent her BTC within the block expiration period. Where is it held until Alice coughs up some coins.

[NewLiberty]

A note of congratulations to team counterparty for a successful burn period.  Thank you for making it easier and better each day, you are heroes for taking this necessary challenge forward with such integrity and effectiveness.

[520Bit]

By the way, I have a question - how exactly XCP will support paying in BTC for asset or XCP?

The offered BTC will be matched to offers on asset/Dex, and once the buyer sends the bTC to seller address, the seller will then send back XCP or asset shares back to the buyer BTC address?

Let's say Alice is selling BTC for XCP with a 5 block expiration on her order and Sally is selling XCP for BTC with a 3 block expiration on her order, and their orders get matched. Upon the matching, the protocol debits the XCP from Sally's account, and then Alice has 3 blocks to send Sally her BTC using the btc-pay command. If Alice fails to send Sally BTC within 3 blocks, the deal is cancelled and Sally's account gets re-credited with the XCP.

Just to be clear - when Sally's account is debited, are they immediately credited with Alice? or only after Alice sent her BTC within the block expiration period. Where is it held until Alice coughs up some coins.

I remembered there is an escrow in the protocol to hold the fund.

[cityglut]

By the way, I have a question - how exactly XCP will support paying in BTC for asset or XCP?

The offered BTC will be matched to offers on asset/Dex, and once the buyer sends the bTC to seller address, the seller will then send back XCP or asset shares back to the buyer BTC address?

Let's say Alice is selling BTC for XCP with a 5 block expiration on her order and Sally is selling XCP for BTC with a 3 block expiration on her order, and their orders get matched. Upon the matching, the protocol debits the XCP from Sally's account, and then Alice has 3 blocks to send Sally her BTC using the btc-pay command. If Alice fails to send Sally BTC within 3 blocks, the deal is cancelled and Sally's account gets re-credited with the XCP.

Is there a way to set it up so the btcpay is done automatically?

No. The protocol can only debit assets that are created within the protocol, and BTC is not one of them.

It is important to note however that while payment is not automatic, there is nevertheless no counterparty risk. Moreover, the protocol will match Alice's order with Sally's only if Alice's fee_provided is greater than or equal to Sally's fee_required; these fees are miners' fees and are in BTC. Therefore, Sally can make her fee_required sufficiently high so that Alice is discouraged from putting up a BTC for XCP order which she fails to send.

fee_required is necessary if and only if one is buying BTC and fee_provided is required if and only if one is selling BTC.

EDIT: miswrote something.

[cityglut]

By the way, I have a question - how exactly XCP will support paying in BTC for asset or XCP?

The offered BTC will be matched to offers on asset/Dex, and once the buyer sends the bTC to seller address, the seller will then send back XCP or asset shares back to the buyer BTC address?

Let's say Alice is selling BTC for XCP with a 5 block expiration on her order and Sally is selling XCP for BTC with a 3 block expiration on her order, and their orders get matched. Upon the matching, the protocol debits the XCP from Sally's account, and then Alice has 3 blocks to send Sally her BTC using the btc-pay command. If Alice fails to send Sally BTC within 3 blocks, the deal is cancelled and Sally's account gets re-credited with the XCP.

Just to be clear - when Sally's account is debited, are they immediately credited with Alice? or only after Alice sent her BTC within the block expiration period. Where is it held until Alice coughs up some coins.

The protocol itself is the escrow service, and will credit Alice with the XCP if and only if she sends Sally the BTC within the block expiration period.

[jl777]

By the way, I have a question - how exactly XCP will support paying in BTC for asset or XCP?

The offered BTC will be matched to offers on asset/Dex, and once the buyer sends the bTC to seller address, the seller will then send back XCP or asset shares back to the buyer BTC address?

Let's say Alice is selling BTC for XCP with a 5 block expiration on her order and Sally is selling XCP for BTC with a 3 block expiration on her order, and their orders get matched. Upon the matching, the protocol debits the XCP from Sally's account, and then Alice has 3 blocks to send Sally her BTC using the btc-pay command. If Alice fails to send Sally BTC within 3 blocks, the deal is cancelled and Sally's account gets re-credited with the XCP.

Is there a way to set it up so the btcpay is done automatically?

No. The protocol can only debit assets that are created within the protocol, and BTC is not one of them.

It is important to note however that while payment is not automatic, there is nevertheless no counterparty risk. Moreover, the protocol will match Alice's order with Sally's only if Alice's fee_provided is greater than or equal to Sally's fee_required; these fees are miners' fees and are in BTC. Therefore, Sally can make her fee_required sufficiently high so that Alice is discouraged from putting up a BTC for XCP order which she fails to send.

fee_required is necessary if and only if one is buying BTC and fee_provided is required if and only if one is selling BTC.

EDIT: miswrote something.

Still a bit confused. Does this mean a "fee_required" is deducted even if Alice fails to send? Wouldn't a large fee_required be a barrier to trading?

[520Bit]

http://blockscan.com/ is such an awesome website. Why not integrate the online XCP wallet on the website like blockchain.info? If you guys can do that, it must be perfect!

[PhantomPhreak]

Note to self we're still in alpha and there will be bugs so don't play with more than you can lose

As long as the order is not matched by others, there's no problem. I think the bug can be fixed later, and your XCP will be back because you balance only depends on how the client parses the blockchain. It only gets messy when a cancelled order is still considered valid and get matched by others.

However, it's better to be confirmed by the developers.

Thanks

That's quite the bug! I'll get to fixing it right away. (Your XCP are not lost, Patel.)

[lonsharim]

The protocol itself is the escrow service, and will credit Alice with the XCP if and only if she sends Sally the BTC within the block expiration period.

I apologize if I am asking too many silly questions, the answers are probably listed in the specs but this gives us a chance for a dumbed down explanation.

Does the system track the BTC transaction via btc-pay and wait for confirmation (1 or 6?) This presumably means that btc-pay payload will require some reference to the original transaction. Once the transaction has been confirmed it will become part of the block chain. The counterparty client will then scan all transactions with XCP references and when it finds this particular one, it releases the XCP from escrow.

Another point is that Sally might intend to send the btc within the block expiration but it is not in her control when the bitcoin transaction is included and in which block. What happens if it is included in the next block after expiration.
 

[PhantomPhreak]

I have a question about Broadcast. From reading the spec, it seems like there is a strong element of trust needed for a broadcast feed. Certainly if major bets are being made, any funny business in the feed would be something that needs to be prevented. However, I could see no such mechanism.

Is there a way to get trustless feeds for very standard things, eg. data from BTC blockchain, orderbooks from specific exchanges, etc.?

I am envisioning a whole set of data feeds that are guaranteed to be reliable. If we can have that, then XCP will become a very safe place to trade crypto derivatives. Call and put options are sorely needed for some crypto business models, but the lack of liquidity in them make them very hard to get, plus currently requires trusting the option seller to be there when it comes time to exercise the option.

I think there could be a whole set of meta-commands that counterpartyd can implement based on just a large set of standard put/call options for all the assets that have realtime public datafeeds

James

The problem with allowing trustless bets on the orderbook, e.g., is that it can be easily manipulated.

There might be a way of creating trustless betting on something like the Bitcoin difficulty, however...