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

mtbitcoin

legendary

Activity: 876

Merit: 1000

Etherscan.io

Quote from: superresistant on February 03, 2014, 09:17:34 AM

Quote from: wizzardTim on February 03, 2014, 08:47:35 AM

Quote from: 520Bit on February 03, 2014, 08:02:37 AM

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!

Exactly!!!

Oh yes please do it. I hate the client and having to download stuff everytime I move on an other computer.

Thank you. Blockscan is a personal project... And at the moment, I do not want to deal with anything related to the storage of actual funds as that is a responsibility that I am not willing to take on at the moment. There are still other non-wallet related but experimental ideas that I would like to deploy via blockscan first over time.

Lets give the Counterparty team the chance to develop, debug and roll out the official web client first. In addition, there is already a bounty on the GUI client ..

Cheers

superresistant

legendary

Activity: 2156

Merit: 1131

Quote from: wizzardTim on February 03, 2014, 08:47:35 AM

Quote from: 520Bit on February 03, 2014, 08:02:37 AM

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!

Exactly!!!

Oh yes please do it. I hate the client and having to download stuff everytime I move on an other computer.

jl777

legendary

Activity: 1176

Merit: 1134

Quote from: PhantomPhreak on February 03, 2014, 08:46:51 AM

Quote from: jl777 on February 03, 2014, 08:43:47 AM

Quote from: PhantomPhreak on February 03, 2014, 08:38:26 AM

Quote from: jl777 on February 03, 2014, 02:47:57 AM

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

If the money backing an asset were held in escrow, then the issuer wouldn't be able to use it.

(BTC can't be put into escrow by the network, but XCP can.)

The issuer shouldnt be able to issue something to somebody else and still use the actual asset that the issuance represented. What if he issuer lost the original asset, how would the issued asset be able to be redeemed? This is my concern with assets that are not 100% backed

If he can't use both, then there's no reason to issue the asset, which would otherwise just become a new denomination of the one escrowed away.

OK, I must be too tired to understand this. Gotta get some sleep

wizzardTim

legendary

Activity: 1708

Merit: 1000

Reality is stranger than fiction

Quote from: 520Bit on February 03, 2014, 08:02:37 AM

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!

Exactly!!!

jl777

legendary

Activity: 1176

Merit: 1134

Quote from: PhantomPhreak on February 03, 2014, 08:43:41 AM

Quote from: jl777 on February 03, 2014, 08:29:14 AM

Quote from: PhantomPhreak on February 03, 2014, 08:08:43 AM

Quote from: jl777 on February 03, 2014, 02:17:00 AM

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

Certainly snapshots of orderbooks can be manipulated, but not longer term moving averages. Things like EMA > SMA, not too hard to calculate assuming access to data and short of massive market actions, hard to change it.

I don't mean that the market itself could be manipulated, but rather just the orderbook, i.e. by selling to yourself.

Sure, but only within the spread. Otherwise you are moving the market. Just dont make bets that are a significant fraction of market liquidity.

For example if you make a 100000 BTC bet on the price of BTC, odds are you will lose as 10000 BTC will move the BTC market, even in China. However if you make a 10 BTC bet on price, you might be able to fiddle around the edges, but you wouldn't be able to push the price much at all with a 10 BTC budget.

If the price for the bet was the average price over 10 minutes (or longer) it would take quite a lot of BTC to change the price from where it wants to be

PhantomPhreak

sr. member

Activity: 476

Merit: 300

Counterparty Chief Scientist and Co-Founder

Quote from: jl777 on February 03, 2014, 08:43:47 AM

Quote from: PhantomPhreak on February 03, 2014, 08:38:26 AM

Quote from: jl777 on February 03, 2014, 02:47:57 AM

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

If the money backing an asset were held in escrow, then the issuer wouldn't be able to use it.

(BTC can't be put into escrow by the network, but XCP can.)

The issuer shouldnt be able to issue something to somebody else and still use the actual asset that the issuance represented. What if he issuer lost the original asset, how would the issued asset be able to be redeemed? This is my concern with assets that are not 100% backed

If he can't use both, then there's no reason to issue the asset, which would otherwise just become a new denomination of the one escrowed away.

jl777

legendary

Activity: 1176

Merit: 1134

Quote from: PhantomPhreak on February 03, 2014, 08:38:26 AM

Quote from: jl777 on February 03, 2014, 02:47:57 AM

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

If the money backing an asset were held in escrow, then the issuer wouldn't be able to use it.

(BTC can't be put into escrow by the network, but XCP can.)

The issuer shouldnt be able to issue something to somebody else and still use the actual asset that the issuance represented. What if he issuer lost the original asset, how would the issued asset be able to be redeemed? This is my concern with assets that are not 100% backed

PhantomPhreak

sr. member

Activity: 476

Merit: 300

Counterparty Chief Scientist and Co-Founder

Quote from: jl777 on February 03, 2014, 08:29:14 AM

Quote from: PhantomPhreak on February 03, 2014, 08:08:43 AM

Quote from: jl777 on February 03, 2014, 02:17:00 AM

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

Certainly snapshots of orderbooks can be manipulated, but not longer term moving averages. Things like EMA > SMA, not too hard to calculate assuming access to data and short of massive market actions, hard to change it.

I don't mean that the market itself could be manipulated, but rather just the orderbook, i.e. by selling to yourself.

PhantomPhreak

sr. member

Activity: 476

Merit: 300

Counterparty Chief Scientist and Co-Founder

Quote from: lonsharim on February 03, 2014, 08:04:04 AM

Quote

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.

Counterparty doesn't pay attention to confirmations. If the referenced transaction is earlier in the blockchain than the current one. it's valid.

A BTCpay does need to reference a particular order match.

Yes, if Sally does that, then she's out of luck.

jl777

legendary

Activity: 1176

Merit: 1134

Quote from: cityglut on February 03, 2014, 08:37:33 AM

Quote from: jl777 on February 03, 2014, 08:01:22 AM

Quote from: cityglut on February 03, 2014, 07:47:19 AM

Quote from: jl777 on February 03, 2014, 07:35:07 AM

Quote from: cityglut on February 03, 2014, 07:18:28 AM

Quote from: SyRenity on February 03, 2014, 07:12:47 AM

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?

fee_required is not a payment; it's a required fee for the counterparty to provide. fee_provided is deducted from an address upon putting up a give-asset=BTC order.

The idea is that if Sally doesn't want to be paired with fake give-asset=BTC orders, she can make the fee_required higher. Of course, the higher the fee, the less likely it is she will get paired, but also the less likely she will get paired with bogus orders.

Thanks. It's almost 6am so not thinking clearly enough to understand all the details. I will revisit this after some sleep

PhantomPhreak

sr. member

Activity: 476

Merit: 300

Counterparty Chief Scientist and Co-Founder

Quote from: jl777 on February 03, 2014, 02:47:57 AM

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

If the money backing an asset were held in escrow, then the issuer wouldn't be able to use it.

(BTC can't be put into escrow by the network, but XCP can.)

cityglut

full member

Activity: 216

Merit: 100

Quote from: jl777 on February 03, 2014, 08:01:22 AM

Quote from: cityglut on February 03, 2014, 07:47:19 AM

Quote from: jl777 on February 03, 2014, 07:35:07 AM

Quote from: cityglut on February 03, 2014, 07:18:28 AM

Quote from: SyRenity on February 03, 2014, 07:12:47 AM

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?

fee_required is not a payment; it's a required fee for the counterparty to provide. fee_provided is deducted from an address upon putting up a give-asset=BTC order.

The idea is that if Sally doesn't want to be paired with fake give-asset=BTC orders, she can make the fee_required higher. Of course, the higher the fee, the less likely it is she will get paired, but also the less likely she will get paired with bogus orders.

jl777

legendary

Activity: 1176

Merit: 1134

Quote from: PhantomPhreak on February 03, 2014, 08:08:43 AM

Quote from: jl777 on February 03, 2014, 02:17:00 AM

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

Certainly snapshots of orderbooks can be manipulated, but not longer term moving averages. Things like EMA > SMA, not too hard to calculate assuming access to data and short of massive market actions, hard to change it.

PhantomPhreak

sr. member

Activity: 476

Merit: 300

Counterparty Chief Scientist and Co-Founder

Quote from: jl777 on February 03, 2014, 02:17:00 AM

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

lonsharim

full member

Activity: 196

Merit: 100

Quote

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

sr. member

Activity: 476

Merit: 300

Counterparty Chief Scientist and Co-Founder

Quote from: Patel on February 03, 2014, 12:36:25 AM

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

Quote from: BitThink on February 03, 2014, 12:34:13 AM

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

520Bit

sr. member

Activity: 602

Merit: 252

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!

jl777

legendary

Activity: 1176

Merit: 1134

Quote from: cityglut on February 03, 2014, 07:47:19 AM

Quote from: jl777 on February 03, 2014, 07:35:07 AM

Quote from: cityglut on February 03, 2014, 07:18:28 AM

Quote from: SyRenity on February 03, 2014, 07:12:47 AM

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?

cityglut

full member

Activity: 216

Merit: 100

Quote from: lonsharim on February 03, 2014, 07:42:16 AM

Quote from: cityglut on February 03, 2014, 07:18:28 AM

Quote from: SyRenity on February 03, 2014, 07:12:47 AM

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.

cityglut

full member

Activity: 216

Merit: 100

Quote from: jl777 on February 03, 2014, 07:35:07 AM

Quote from: cityglut on February 03, 2014, 07:18:28 AM

Quote from: SyRenity on February 03, 2014, 07:12:47 AM

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.

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