A counter-proposal to one you described for escrowing XCP: escrowing away a fixed fraction of XCP per order (5%?) if above a certain amount?
Another issue is that with the latest patch, the [tt]fee_provided[/tt] is reduced by the [tt]fee_required[/tt]s the same amount no matter the fraction of each sell order fulfilled.
EDIT: This commit fixes the second issue.
I liked the idea porqupine had to early expire orders which were matched but failed to btcpay.
https://bitcointalk.org/index.php?topic=395761.msg5068497#msg5068497
If the order that failed to btcpay was legitimate, they would have to resubmit the order (penalty for not being more vigilant). If the order was a troll, it’ll drop off the order book - helps in spam prevention of troll orders.
I don’t have a test environment available. Here’s my attempt at a patch hand written in notepad++). The code block is inserted into the order_match expiry loop. Logically, the failed-to-btcpay-tx is expired after assets are returned from the expired order match.
Hope I got ‘give_asset’ the right way round…
Since it should be mutually exclusive that tx0 should be paying btc or tx1 should be paying btc, would you prefer to have the tx1 expiry in an else?<br />--- order.py<br />+++ order2.py<br />@@ -331,6 +331,40 @@<br /> # Sanity check: one of the two must have expired.<br /> assert tx0_order_time_left or tx1_order_time_left<br /><br />- cursor.close()<br />+ # If tx0 failed to btcpay, expire the order<br />+ if tx0_order['give_asset'] == 'BTC':<br />+ bindings = {<br />+ 'validity': 'invalid: expired',<br />+ 'tx_index': tx0_order['tx_index']<br />+ }<br />+ sql='update orders set validity = :validity where tx_index = :tx_index'<br />+ cursor.execute(sql, bindings)<br />+<br />+ # and record expiry of the order tx0<br />+ bindings = {<br />+ 'order_index': tx0_order['tx_index'],<br />+ 'order_hash': tx0_order['tx_hash'],<br />+ 'block_index': block_index<br />+ }<br />+ sql='insert into order_expirations values(:order_index, :order_hash, :block_index)'<br />+ cursor.execute(sql, bindings)<br /><br /><br />+ # If tx1 failed to btcpay, expire the order<br />+ if tx1_order['give_asset'] == 'BTC':<br />+ bindings = {<br />+ 'validity': 'invalid: expired',<br />+ 'tx_index': tx1_order['tx_index']<br />+ }<br />+ sql='update orders set validity = :validity where tx_index = :tx_index'<br />+ cursor.execute(sql, bindings)<br />+<br />+ # and record expiry of the order tx0<br />+ bindings = {<br />+ 'order_index': tx1_order['tx_index'],<br />+ 'order_hash': tx1_order['tx_hash'],<br />+ 'block_index': block_index<br />+ }<br />+ sql='insert into order_expirations values(:order_index, :order_hash, :block_index)'<br />+ cursor.execute(sql, bindings)<br />+ cursor.close()<br /> # vim: tabstop=8 expandtab shiftwidth=4 softtabstop=4
[quote author=gacrux link=topic=69.msg365#msg365 date=1392004132]
[…]
* the seller should not receive any benefit if you fail to settle. ie. the “escrow” must be destroyed in this case. Otherwise, sellers will have a perverse incentive to try to prevent their orders settling (ping flooding the guy trying to send BTCpay? Setting insanely small expiry times in the hope your BTCpay doesn’t make it into a block on time? Use your imagination.)
[…]
[/quote]
Keep in mind, destroying the escrow is deflationary.
[quote author=gacrux link=topic=69.msg381#msg381 date=1392031334]
[quote author=mtbitcoin link=topic=69.msg373#msg373 date=1392021081]
Would like to add another proposal for allowing users to match specific buy/sell orders vs dex matching based on best price.
This ties back to the idea of reputation and if you look at the block data buyers who have consistently followed up with their BTCPay normally also do so for future orders. It would be quite easy to have an independent 3rd party optional reputation/score based system for specific address
The order command should be something like the following
i.e counterpartyd.py --order --offer_hash=XXXXXXXXXXXXXXXXXX --give-quantity=XX
Then blocks.py would parse the blockchain and automatically match these orders. If for one reason or other it is unable to do so (i.e order already prefilled or insufficient balance left) then the order is auto cancelled and the NON-BTC asset (i.e XCP) is refunded.
This proposal should give more control to clients and should be able to work alongside with the existing best matched pricing of dex.
[/quote]
This sounds like a workable idea, but I’m not sure that the extra complexity is worth it unless there’s no other way. I see what you’re trying to address - that annoying situation where the best price on the DEX is blatently some troll who won’t BTCpay, and due to the simple “best matched price” algorithm you’re powerless to avoid your order being matched against the troll. It’s tempting to think “I wish I could just force my order to match X”. I get it 
My objections are fundamental:
* in a properly functional market, you always want the best price.
* an average market user shouldn’t have to think about the complexity of reputation systems and matching specific orders. He just wants the best price, automatically.
* protocols like this need to be as simple and robust as possible
* your suggestion is a hack designed to mitigate damage rather than remove the source of the problem
The real problem here is that trolls are able to afford to match orders and refuse BTCpay in the first place.
If we can fix that, I think you’ll agree, your suggestion is unnecessary. If we can’t fix it then I’ll be the first one to embrace your damage mitigation as very sadly necessary. But it remains to be seen
In any case, it’s important to recognise when we’re going down the path of building a decentralised “craigslist exchange” rather than a decentralised “mtgox exchange” (if you can see the analogy.) One allows individuals to trade, but with the considerable friction of having to find matches and assess reputation themselves. The other is a real market, which simply lets people buy and sell for the best price automatically with zero friction. We should strive for the latter, and only settle for the former when the latter has proved impossible.
[/quote]
Thank you. Well said.
It is indeed obvious that DEX exchanges would never be able replace the traditional centralized exchanges …for anything even some sort of volume…
However, what a DEX does provide is a decentralized escrowed system for exchanging assets and in this lies it strength. The ability to directly match orders bypassing the “best matched” price would further enhance the escrow capability of counterparty. How many times have we seen on the bitcointalk forum people asking for escrow and trusted members offering “escrow” services, there is a demand for this kind of service.
The methodology of directed price matching is easy to understand for the average person and if offered as an additional option (not default) would provide additional utility. This could spawn a trustless escrowed system for anyone to exchange any kind of digital assets independently of a manual escrow.
[quote author=Global_trade_repo link=topic=69.msg407#msg407 date=1392097332]
[quote author=gacrux link=topic=69.msg365#msg365 date=1392004132]
* the seller should not receive any benefit if you fail to settle.
[/quote]
Keep in mind, destroying the escrow is deflationary.
[/quote]
Absolutely - I made the suggestion with full knowledge of this. Destroying the escrow - much like proof of burn - is effectively just a tiny donation to everybody else.
Once things shake out, and fees (“escrows”) settle at an appropriate level, and clients automatically do the right thing (ie. computers negotiate this protocol instead of humans) … then I’d hope that instances of somebody failing to BTCpay would be few and far between anyway. That’s sort of the point
[quote author=mtbitcoin link=topic=69.msg408#msg408 date=1392118196]
Thank you. Well said.
It is indeed obvious that DEX exchanges would never be able replace the traditional centralized exchanges …for anything even some sort of volume…
[/quote]
I don’t consider that to be obvious yet. But I admit I’m very new to counterparty
I’m fascinated by the concept of a DEX and curious to see how far it can be taken. The centralised exchanges certainly have their issues. Nobody really feels very comfortable keeping a large sum of money on one, even on MtGox 
What bitcoin does supremely well is replace flawed human systems (traditional banking) with a bulletproof trustless protocol. The idea of replacing the centralised exchanges, with all their flaws, with a trustless protocol is very appealing.
I believe a robust and scalable DEX will inevitably make centralised exchanges of purely digital assets obsolete one day. Whether that DEX will be counterparty’s or somebody else’s remains to be seen - but counterparty certainly has a good head start at this point.
Whether you can achieve the necessary scalability while running atop the bitcoin blockchain, with its average 10 minute granularity, also remains to be seen. But I do think you can get close to the robustness and simplicity required if you’re careful about how you design the protocol. I’m just curious to see how close
[quote author=mtbitcoin link=topic=69.msg408#msg408 date=1392118196]
However, what a DEX does provide is a decentralized escrowed system for exchanging assets and in this lies it strength. The ability to directly match orders bypassing the “best matched” price would further enhance the escrow capability of counterparty. How many times have we seen on the bitcointalk forum people asking for escrow and trusted members offering “escrow” services, there is a demand for this kind of service.
The methodology of directed price matching is easy to understand for the average person and if offered as an additional option (not default) would provide additional utility. This could spawn a trustless escrowed system for anyone to exchange any kind of digital assets independently of a manual escrow.
[/quote]
Fair enough It appears you and I have quite different ideas about what the DEX should be. Which is perfectly valid - different people often have different requirements or applications for a system in mind. I just don’t find a “trustless escrow” as interesting a problem as a full-fledged DEX. I agree it would also have its uses. It might be more simply implemented as a separate mechanism in the counterparty protocol, I’m not sure.
[quote author=PhantomPhreak link=topic=69.msg388#msg388 date=1392037349]
Take a look at this commit, https://github.com/PhantomPhreak/counterpartyd/commit/34a871fac50dad6a784766d4ba6de06bfccd5689, which now has all order fees specified as a percentage of the BTC to be transacted, and defaults to 1%.
[/quote]
Absolutely fantastic
You might want to update the help= string to reflect the fact that --fee_required and --fee_provided should only be provided if the user wishes to override default behaviour (eg. "override the default miner fee provided, specified as a fraction of BTC to be sold; if unsure leave blank" ?)
Would it be fair to say that everyone has to play with the consensus of what the fee should be in order to have their orders filled? Sounds pretty good actually. It sounds like it reduces market dynamics though.
How will the fee be decided? I know 1% was just a number picked out of air but it is pretty high compared to centralized exchanges.
[quote author=PhantomPhreak link=topic=69.msg399#msg399 date=1392077594]
A counter-proposal to one you described for escrowing XCP: escrowing away a fixed fraction of XCP per order (5%?) if above a certain amount?
[/quote]
Poor idea. Anything with “above a certain amount” baked into your protocol is doomed to break down.
Suppose your magic number is X. You select X carefully so that the majority of small, newbie orders fall below it, but so that it’s still low enough that trolls trying to dodge the XCP escrow can’t easily slip under it. You bake it into the protocol. Remember: whenever you change X, people who don’t upgrade by the deadline will diverge from the who-owns-what consensus, and very likely end up losing money. Plus, with every protocol change you’re accumulating “before block X the rule was this, after block X the rule was that” cruft that (correct me if I’m wrong) you can’t easily ever get rid of. People who re-implement the counterparty protocol will have to faithfully reproduce all that complexity in order to be compatible.
Now, the value of BTC (or XCP, if you like) jumps 10x. Do you modify X? What if next week the value falls by 50%? Whatever value you pick for X could end up being ridiculously large or ridiculously small.
Also:
* while not as problematic, being stuck with 5% could also prove annoying later if it becomes apparent it’s too high / too low
* you’re forcing some set of people (ordering > X quantity) to have XCP to be able to trade
* you’re forcing another set of people (selling < X quantity) to trade without the protection of XCP escrow
* some people will be forced to try to structure their orders to fit into one group or the other, which feels quite in-elegant
* everybody on the DEX can only trade with a subset of other people instead of everyone (call this “order fungibility” I guess?)
My proposal of “fees payable in any blend of the asset pair being traded that the fee-payer prefers” was designed to avoid these problems.
* no magic numbers in the protocol
* scales smoothly, with participants deciding at what point they want to swap over to paying fees with XCP (people probably will as soon as they can, to minimise costs - not at some arbitrary order magnitude)
* everyone can trade with everyone - ie. “fungible orders”. A whale can issue one large sell order without having to artificially break it up so there will be some small pieces that newbies are able to match (a newbie could match 1% of the whale’s sell order, paying the appropriate fee in BTC. Somebody else could match the other 99% of it, using XCP to avoid being out of pocket for a large fee. The whale doesn’t have to care about any of this - he just places his order and forgets about it.)
[quote author=PhantomPhreak link=topic=69.msg399#msg399 date=1392077594]
Another issue is that with the latest patch, the [tt]fee_provided[/tt] is reduced by the [tt]fee_required[/tt]s the same amount no matter the fraction of each sell order fulfilled.
EDIT: This commit fixes the second issue.
[/quote]
Awesome
[quote author=Global_trade_repo link=topic=69.msg415#msg415 date=1392124772]
How will the fee be decided? I know 1% was just a number picked out of air but it is pretty high compared to centralized exchanges.
[/quote]
If you can pay it with XCP (refunded upon BTCpay) then it’s essentially zero (not counting the unavoidable BTC miner fee for the txn of course.)
[quote author=gacrux link=topic=69.msg416#msg416 date=1392125351]
[quote author=PhantomPhreak link=topic=69.msg399#msg399 date=1392077594]
A counter-proposal to one you described for escrowing XCP: escrowing away a fixed fraction of XCP per order (5%?) if above a certain amount?
[/quote]
Poor idea. Anything with “above a certain amount” baked into your protocol is doomed to break down.
Suppose your magic number is X. You select X carefully so that the majority of small, newbie orders fall below it, but so that it’s still low enough that trolls trying to dodge the XCP escrow can’t easily slip under it. You bake it into the protocol. Remember: whenever you change X, people who don’t upgrade by the deadline will diverge from the who-owns-what consensus, and very likely end up losing money. Plus, with every protocol change you’re accumulating “before block X the rule was this, after block X the rule was that” cruft that (correct me if I’m wrong) you can’t easily ever get rid of. People who re-implement the counterparty protocol will have to faithfully reproduce all that complexity in order to be compatible.
Now, the value of BTC (or XCP, if you like) jumps 10x. Do you modify X? What if next week the value falls by 50%? Whatever value you pick for X could end up being ridiculously large or ridiculously small.
Also:
* while not as problematic, being stuck with 5% could also prove annoying later if it becomes apparent it’s too high / too low
* you’re forcing some set of people (ordering > X quantity) to have XCP to be able to trade
* you’re forcing another set of people (selling < X quantity) to trade without the protection of XCP escrow
* some people will be forced to try to structure their orders to fit into one group or the other, which feels quite in-elegant
* everybody on the DEX can only trade with a subset of other people instead of everyone (call this “order fungibility” I guess?)
My proposal of “fees payable in any blend of the asset pair being traded that the fee-payer prefers” was designed to avoid these problems.
* no magic numbers in the protocol
* scales smoothly, with participants deciding at what point they want to swap over to paying fees with XCP (people probably will as soon as they can, to minimise costs - not at some arbitrary order magnitude)
* everyone can trade with everyone - ie. “fungible orders”. A whale can issue one large sell order without having to artificially break it up so there will be some small pieces that newbies are able to match (a newbie could match 1% of the whale’s sell order, paying the appropriate fee in BTC. Somebody else could match the other 99% of it, using XCP to avoid being out of pocket for a large fee. The whale doesn’t have to care about any of this - he just places his order and forgets about it.)
[/quote]
The problem, as I am sure you know, is that having to customize the proportions of XCP and BTC fees raises the barrier to entry for using Counterparty dramatically. Also, depending on the actual implementation, you run the risk of orders not matching up, since you have added another variable . In highly liquid market this is less of a concern, but given the added complexity involved in making trades, it may actually interfere with adoption sufficiently so that the market never becomes liquid enough.
[quote author=Global_trade_repo link=topic=69.msg406#msg406 date=1392096752]
I liked the idea porqupine had to early expire orders which were matched but failed to btcpay.
https://bitcointalk.org/index.php?topic=395761.msg5068497#msg5068497
[/quote]
Interesting idea. It sounds reasonable at first.
I’m a big proponent of the idea that a BTC seller should be expected to settle promptly with BTCpay for all orders they place. The only exception is that the user (or his client, eg. counterpartyd) should always be defensive, and prefer to default on BTCpay rather than take a risk if the match is close to expiry. In reality you wouldn’t expect that to happen often.
So it sounds reasonable to blow away an entire order if any part of it matches and fails to BTCpay. But, then, cancelling matched orders is a very risky affair. Suppose that I’m accidentally too slow to BTCpay for part of my order (perhaps my network connection drops, and comes back an hour later?) - it’d be a fair penalty to lose the fee/escrow. But if I’d just sent BTCpay for a second part of my order which matched later (and thus had a later expiry), and that match was suddenly invalidated before my BTCpay made it into a block, causing me to lose the entire BTCpay, I’d be seriously pissed.
On the other hand, I suppose I could predict that that was going to happen (if you know any part of your order is about to expire, then you know it’s risky to send BTCpay for any part of it.) So maybe it is workable.
On the other hand, the troll’s order always offers such a high rate that he’s guaranteed to match everything on the book in one hit anyway. So the timeouts would all be the same, thus it’s sort of moot 
[quote author=cityglut link=topic=69.msg418#msg418 date=1392126552]
The problem, as I am sure you know, is that having to customize the proportions of XCP and BTC fees raises the barrier to entry for using Counterparty dramatically. Also, depending on the actual implementation, you run the risk of orders not matching up, since you have added another variable . In highly liquid market this is less of a concern, but given the added complexity involved in making trades, it may actually interfere with adoption sufficiently so that the market never becomes liquid enough.
[/quote]
Why should the user even have to know about fees, much less customise them? The whole point of my proposal is that the software should do the right thing automatically. The user should only have to worry about the quantity he wants to buy/sell and the price he wants to pay. Everything else should just work.
Counterpartyd (or some GUI client) could easily default to this logic:
* if user has only BTC then pay fee in BTC
* if user has XCP available then pay as high a proportion of the fee in XCP as possible, the rest in BTC
It is always desirable to pay in XCP if you can, because it is refunded in full upon BTCpay, so it saves you the fee essentially.
If you like you could include some information in the confirmation prompt.
eg: This order will cost you 0.0002 BTC in fees to place. Confirm (y/N) ?"
OR: This order will cost you 0.0001 BTC in fees to place, plus 1.3 XCP penalty if you fail to settle within 10 blocks. Confirm (y/N) ?"
Advanced users could always override this with a command line flag forcing it to always pay the fee in BTC if they wanted (but why would you?)
If implemented properly then orders should always match deterministically, with no risk. Algorithm is:
* rate R is the rate the orders have matched at (eg. 0.005 BTC per XCP)
* BTC-seller has paid B fees in BTC plus X fees in XCP
* B = B + (X * R)
* match as per normal.
[quote author=gacrux link=topic=69.msg420#msg420 date=1392127539]
[quote author=cityglut link=topic=69.msg418#msg418 date=1392126552]
The problem, as I am sure you know, is that having to customize the proportions of XCP and BTC fees raises the barrier to entry for using Counterparty dramatically. Also, depending on the actual implementation, you run the risk of orders not matching up, since you have added another variable . In highly liquid market this is less of a concern, but given the added complexity involved in making trades, it may actually interfere with adoption sufficiently so that the market never becomes liquid enough.
[/quote]
Why should the user even have to know about fees, much less customise them? The whole point of my proposal is that the software should do the right thing automatically. The user should only have to worry about the quantity he wants to buy/sell and the price he wants to pay. Everything else should just work.
Counterpartyd (or some GUI client) could easily default to this logic:
* if user has only BTC then pay fee in BTC
* if user has XCP available then pay as high a proportion of the fee in XCP as possible, the rest in BTC
It is always desirable to pay in XCP if you can, because it is refunded in full upon BTCpay, so it saves you the fee essentially.
If you like you could include some information in the confirmation prompt.
eg: This order will cost you 0.0002 BTC in fees to place. Confirm (y/N) ?"
OR: This order will cost you 0.0001 BTC in fees to place, plus 1.3 XCP penalty if you fail to settle within 10 blocks. Confirm (y/N) ?"
Advanced users could always override this with a command line flag forcing it to always pay the fee in BTC if they wanted (but why would you?)
If implemented properly then orders should always match deterministically, with no risk. Algorithm is:
* rate R is the rate the orders have matched at (eg. 0.005 BTC per XCP)
* BTC-seller has paid B fees in BTC plus X fees in XCP
* B = B + (X * R)
* match as per normal.
[/quote]
I agree that the protocol should take care of things automatically to the extent that it can and, moreover, think that the logic you have proposed is reasonable, but the consequences of users “finding out” about fees they have been charged are obvious and undesirable, and if users don’t have to customize their fees, then the protocol must default to some fee, and the latter will have precisely the magic number problem that you have discussed above. Do you have a way around that in mind?
[quote author=cityglut link=topic=69.msg421#msg421 date=1392128010]
[quote author=gacrux link=topic=69.msg420#msg420 date=1392127539]
[quote author=cityglut link=topic=69.msg418#msg418 date=1392126552]
The problem, as I am sure you know, is that having to customize the proportions of XCP and BTC fees raises the barrier to entry for using Counterparty dramatically. Also, depending on the actual implementation, you run the risk of orders not matching up, since you have added another variable . In highly liquid market this is less of a concern, but given the added complexity involved in making trades, it may actually interfere with adoption sufficiently so that the market never becomes liquid enough.
[/quote]
Why should the user even have to know about fees, much less customise them? The whole point of my proposal is that the software should do the right thing automatically. The user should only have to worry about the quantity he wants to buy/sell and the price he wants to pay. Everything else should just work.
Counterpartyd (or some GUI client) could easily default to this logic:
* if user has only BTC then pay fee in BTC
* if user has XCP available then pay as high a proportion of the fee in XCP as possible, the rest in BTC
It is always desirable to pay in XCP if you can, because it is refunded in full upon BTCpay, so it saves you the fee essentially.
If you like you could include some information in the confirmation prompt.
eg: This order will cost you 0.0002 BTC in fees to place. Confirm (y/N) ?"
OR: This order will cost you 0.0001 BTC in fees to place, plus 1.3 XCP penalty if you fail to settle within 10 blocks. Confirm (y/N) ?"
Advanced users could always override this with a command line flag forcing it to always pay the fee in BTC if they wanted (but why would you?)
If implemented properly then orders should always match deterministically, with no risk. Algorithm is:
* rate R is the rate the orders have matched at (eg. 0.005 BTC per XCP)
* BTC-seller has paid B fees in BTC plus X fees in XCP
* B = B + (X * R)
* match as per normal.
[/quote]
I agree that the protocol should take care of things automatically to the extent that it can and, moreover, think that the logic you have proposed is reasonable, but the consequences of users “finding out” about fees they have been charged are obvious and undesirable, and if users don’t have to customize their fees, then the protocol must default to some fee, and the latter will have precisely the magic number problem that you have discussed above. Do you have a way around that in mind?
[/quote]
A magic number in the UI is much better than a magic number in the protocol.
[quote author=PhantomPhreak link=topic=69.msg422#msg422 date=1392128230]
[quote author=cityglut link=topic=69.msg421#msg421 date=1392128010]
[quote author=gacrux link=topic=69.msg420#msg420 date=1392127539]
[quote author=cityglut link=topic=69.msg418#msg418 date=1392126552]
The problem, as I am sure you know, is that having to customize the proportions of XCP and BTC fees raises the barrier to entry for using Counterparty dramatically. Also, depending on the actual implementation, you run the risk of orders not matching up, since you have added another variable . In highly liquid market this is less of a concern, but given the added complexity involved in making trades, it may actually interfere with adoption sufficiently so that the market never becomes liquid enough.
[/quote]
Why should the user even have to know about fees, much less customise them? The whole point of my proposal is that the software should do the right thing automatically. The user should only have to worry about the quantity he wants to buy/sell and the price he wants to pay. Everything else should just work.
Counterpartyd (or some GUI client) could easily default to this logic:
* if user has only BTC then pay fee in BTC
* if user has XCP available then pay as high a proportion of the fee in XCP as possible, the rest in BTC
It is always desirable to pay in XCP if you can, because it is refunded in full upon BTCpay, so it saves you the fee essentially.
If you like you could include some information in the confirmation prompt.
eg: This order will cost you 0.0002 BTC in fees to place. Confirm (y/N) ?"
OR: This order will cost you 0.0001 BTC in fees to place, plus 1.3 XCP penalty if you fail to settle within 10 blocks. Confirm (y/N) ?"
Advanced users could always override this with a command line flag forcing it to always pay the fee in BTC if they wanted (but why would you?)
If implemented properly then orders should always match deterministically, with no risk. Algorithm is:
* rate R is the rate the orders have matched at (eg. 0.005 BTC per XCP)
* BTC-seller has paid B fees in BTC plus X fees in XCP
* B = B + (X * R)
* match as per normal.
[/quote]
I agree that the protocol should take care of things automatically to the extent that it can and, moreover, think that the logic you have proposed is reasonable, but the consequences of users “finding out” about fees they have been charged are obvious and undesirable, and if users don’t have to customize their fees, then the protocol must default to some fee, and the latter will have precisely the magic number problem that you have discussed above. Do you have a way around that in mind?
[/quote]
A magic number in the UI is much better than a magic number in the protocol.
[/quote]
Actually, isn’t the default [tt]fee_required[/tt]/[tt]fee_provided[/tt] a protocol thing?
Anyway, we have two goals that contradict each other, but which we have to reconcile: On the one hand, we want the “default fees” a user is charged to be as low as possible, and on the other hand we want the default fees to be high enough to maximally prevent trolling the order book. Unless I am mistaken, any number that we pick now for a default fee will fall into the category of “a magic number”.
gacrux, correct me if I am wrong, but I believe your XCP escrow idea requires that their be a maximum blocktime in which users can make a [tt]btcpay[/tt], right? In that case, we shouldn’t glaze over the fact that uses will lose their escrow ‘fee’ if they don’t [tt]btcpay[/tt] in X number of blocks, and even if we say, “It’s reasonable to expect that someone will complete his BTC transaction X in blocks”, there is still something magic number-y about this.
[quote author=cityglut link=topic=69.msg424#msg424 date=1392129983]
Actually, isn’t the default [tt]fee_required[/tt]/[tt]fee_provided[/tt] a protocol thing?
Anyway, we have two goals that contradict each other, but which we have to reconcile: On the one hand, we want the “default fees” a user is charged to be as low as possible, and on the other hand we want the default fees to be high enough to maximally prevent trolling the order book. Unless I am mistaken, any number that we pick now for a default fee will fall into the category of “a magic number”.
gacrux, correct me if I am wrong, but I believe your XCP escrow idea requires that their be a maximum blocktime in which users can make a [tt]btcpay[/tt], right? In that case, we shouldn’t glaze over the fact that uses will lose their escrow ‘fee’ if they don’t [tt]btcpay[/tt] in X number of blocks, and even if we say, “It’s reasonable to expect that someone will complete his BTC transaction X in blocks”, there is still something magic number-y about this.
[/quote]
Talking about “magic numbers”, perhaps I am missing something but why not leave this up entirely to the user. Let the user decide how much the required XCP escrow fee should be and let the user decide how long the BTCPay expiry period should be.
And to set some basic boundaries, hardcode a Max amount of XCP escrow fee allowed (eg. max percentage of 1%) and a Min number of blocks required for BTCPAY.
And over time as things become clearer and a better algorithm can be produced let the “XCP gui client” suggest a recommended fee/block expiry just like how bitcoinQT suggests a recommend “fee”.
I don’t know if this is possible, but can a new BTC address be automatically created for escrow, with the private key somehow hidden or inaccessible to anyone until the BTCpay has been confirmed (perhaps with the private key distributed across a few nodes in the network or something similar)? I picture it working something like this:
1.[size=7pt][font=Times New Roman] [/font][/size]Bob (XCP buyer) places an order to buy 200 XCP for 1 BTC.
2.[size=7pt][font=Times New Roman] [/font][/size]Bob’s 1 BTC is transferred automatically to an account with a hidden private key (NB: not sure exactly where this private key would reside during the escrow period).
3.[size=7pt][font=Times New Roman] [/font][/size]Mary (XCP seller) places an order to sell 100 XCP for 0.5 BTC.
4.[size=7pt][font=Times New Roman] [/font][/size]100 XCP of Mary’s order is matched to Bob’s original order.
5.[size=7pt][font=Times New Roman] [/font][/size]XCP protocol automatically sends the 100 XCP to Bob.
6.[size=7pt][font=Times New Roman] [/font][/size]Once the XCP transfer is confirmed, 0.5 BTC are sent to Mary, the other 0.5 BTC stay in escrow until the rest of Bob’s order is matched, cancelled by Bob, or expires. Or, since the private key has now been used, perhaps they are transferred to a new address created in the same way described above.
The critical part of this whole transaction is in point 2 above. Is there any way to have the escrow address be created in a trustless manner and have the private key distributed across a few nodes or in another way that makes it inaccessible to anyone until the order is matched? If this is possible than I don’t see why the steps outlined above couldn’t be implemented.
[quote author=cityglut link=topic=69.msg421#msg421 date=1392128010]
I agree that the protocol should take care of things automatically to the extent that it can
[/quote]
Disagree. The protocol should be simple, robust, and failure-proof in the face of the full range of possible inputs by users (even really silly stuff.)
The client software should take care of negotiating the protocol automatically, to the extent that it can optimally do so without bothering the user. (The user can always customise his client’s behaviour, however.)
The distinction is important (read on…)
[quote author=cityglut link=topic=69.msg421#msg421 date=1392128010]
the consequences of users “finding out” about fees they have been charged are obvious and undesirable, and if users don’t have to customize their fees, then the protocol must default to some fee, and the latter will have precisely the magic number problem that you have discussed above. Do you have a way around that in mind?
[/quote]
The protocol definitely must not default to any fee. There is no place for magic numbers in the protocol, as I’ve explained The protocol must gracefully handle the full range of fee values that a user could specify.
The client software, on the other hand, certainly could default the fee value it uses without any user input, and I would argue that it is appropriate for it to do so. I would argue that it should also automatically issue BTCpay upon match.
This introduces no magic number issue with the protocol. Quite the opposite - it’s actually exactly how you should handle this. Client defaults could be tweaked at any time without the protocol breaking (and indeed different clients would be free to use different defaults with no issue at all.)
The resulting user experience would be very reliable. Just enter the amount you wish to buy and the rate, and it just works. Every time. And it wastes the very bare minimum of BTC fees necessary each time, uses XCP wherever possible, and never loses any XCP (because it is well behaved and always settles with BTCpay.)
[quote author=cityglut link=topic=69.msg424#msg424 date=1392129983]
Actually, isn’t the default [tt]fee_required[/tt]/[tt]fee_provided[/tt] a protocol thing?
[/quote]
From the commit PhantomPhreak linked to earlier in this thread it did not appear that way to me. I’m sure he’ll correct me if I’m wrong
[quote author=cityglut link=topic=69.msg424#msg424 date=1392129983]
any number that we pick now for a default fee will fall into the category of “a magic number”.
[/quote]
Magic numbers baked into the protocol are a very bad idea (because you can’t easily update them.) Magic numbers in the client behaviour are just fine, because you can easily update them at any time, without fear of breaking anything.
[quote author=cityglut link=topic=69.msg424#msg424 date=1392129983]
gacrux, correct me if I am wrong, but I believe your XCP escrow idea requires that their be a maximum blocktime in which users can make a [tt]btcpay[/tt], right?
[/quote]
“optionally pay fees with XCP, which is refundable” and “separate/standardised expiry for matched orders” are two entirely separate ideas. I happen to think both are very good ideas, but neither relies upon the other in any way - you could implement either one of them in isolation.
[quote author=cityglut link=topic=69.msg424#msg424 date=1392129983]
In that case, we shouldn’t glaze over the fact that uses will lose their escrow ‘fee’ if they don’t [tt]btcpay[/tt] in X number of blocks, and even if we say, “It’s reasonable to expect that someone will complete his BTC transaction X in blocks”, there is still something magic number-y about this.
[/quote]
* Yes, users will lose their XCP fee (escrow if you like) if they fail to BTCpay. The idea is that failing to BTCpay should be exceptional for any honest node. 99% of the time you wouldn’t fail to BTCpay, because your client should automatically BTCpay as soon as it sees the match.
In the event of a catastrophe (eg. you lose your network connection before your client can BTCpay) then you would lose the XCP fee/escrow. I consider that risk acceptable, and anticipate that it would occur very very rarely. It remains to be seen if I am correct
Your client should also behave defensively. If match_expiry has already ticked down below some configured safety margin (eg. 5 blocks) then it should prefer to let the match expire rather than risk BTCpay. Again, this would almost never actually happen to an honest node, short of network failure at the critical moment.
* If “X blocks” is baked into the protocol, then yes - that’d be a magic number, and I’d argue sub-optimal. For now it is exactly like this (and X = 10.) Simplicity of implementation is a strong argument in favour of this as a starting point.
However, ideally I think you want to move this “magic number” to be a client default too. ie. the BTC buyer gets to specify the match_expiry and his client software should default it to eg. 10 blocks without asking. The protocol must enforce a minimum (eg. 10 blocks) of course, he can’t specify zero. But client software should retain the flexibility to bump this number up in the future if it is observed that people are having difficulty issuing BTCpay on time.