I’m heavily invested in the XCP system and want to see it succeed and do better.
MoneypakTrader offered some good solutions for fixing a few of the problems the system currently has: https://bitcointalk.org/index.php?topic=395761.msg5009075#msg5009075
Building on those suggestions, I’d advocate the following improvements:
FIRST SUGGESTION:
All orders should include the major version number of the client issuing the order to prevent matching problems that users have experienced. The protocol should not allow matches of different major version and should inform the user if other version numbers are more popular than the one used to suggest upgrading. The new version should show the old version order book and the new version order book to allow placing orders under either systems.
Essentially these are hard forks. Older clients can still make trades with each other, but for added features and trades with new clients, it must be updated.
Again, new clients should have a feature to view and issue orders/commands at older version levels just in case significant users/orders resist the upgrades and the new client user wishes to match older version orders.
SECOND SUGGESTION:
All orders involving BTC should be able to set an optional variable [minimum] (amount of BTC for each valid match), denominated in BTC (for efficiency reasons). Leftover amounts in the order book for less than the [minimum] should be cancelled from the order book and returned to the owner AFTER ALL other fractions of that order are COMPLETELY BTCpayd for.
This works particularly well when combined with the other following improvements.
Reason:
“BTC for XCP” orders require a second “BTCpay” to complete EACH order match made, this wouldn’t be an issue except:
1) Significant fees (around 40 cents/0.0004btc) are required for EACH “BTCpay” action make small transactions (<1 XCP) proportionally very expensive (as described by moneypaktrader on bitcointalk around their above linked post time).
Here’s a scenario, suppose I want to spend some BTC to buy 50XCP at the best possible DEX rates and the order book looks like this:
XCP for BTC orders:
1 XCP @ 0.0040 (total costs with btcpay = 0.0044 btc/xcp, ignoring the costs to place the btc/xcp orders)
2 XCP @ 0.0041 (total costs with btcpay = 0.0043 btc/xcp, ignoring the costs to place the btc/xcp orders)
1 XCP @ 0.0042 (total costs with btcpay = 0.0046 btc/xcp, ignoring the costs to place the btc/xcp orders)
50 XCP @ 0.00425 (total costs with btcpay = 0.004258 btc/xcp, ignoring the costs to place the btc/xcp orders)
I have an incentive to place a btc for xcp order for enough quantity (or more) to buy at least all the orders through the 50 XCP order but only “btcpay” for the single 50 XCP order match which is the best price for the quantity I want.
When combined with fees per match described below, this feature is almost necessary to avoid excessive fees from numerous matches.
THIRD SUGGESTION:
Because BTC orders get the option to pay or not to complete the order, the orders requesting BTC should be allowed to charge/receive an XCP fee for providing that option. I agree with MPT that this fee should be waived/ignored for the first matched order to prevent clogging the order book with high match fees, the BTC order will be paying sufficient network fees to justify getting a first match without a fee. Also using XCP for this fee will encourage XCP usage and drive demand for XCP by high volume traders.
New Variables needed -
A) Orders requesting BTC have an OPTIONAL variable [fee-charged] (defaults to 0 if not set).
B) Orders offering to pay BTC have an OPTIONAL input [fees-provided] (defaults to 0 if not set). This is deducted from the xcp of the BTC address of the BTC offer and escrowed for use until the order completes/expires.
C) Orders offering to pay BTC have an OPTIONAL variable [max-fee] (defaults to total fees-provided balance or 0 if not set).
How it would work -
The first otherwise valid match to a BTC order is matched with no fee deducted from B.
After the first match, B (fees-provided) and C (max-fee) must be greater than or equal to A (fee-charged) or it does not get matched and goes to the next order/match. The remaining balance of B and variable C must still be greater than or equal to each A of each future match (or A must equal 0 if B=0).
Each match after the first gets paid immediately the XCP value agreed and the balance of B is reduced accordingly. Balance of B is refunded to the BTC offer on completion/expiration of the order.
Why? “XCP for BTC” orders must wait until their order expires and currently receive no compensation for giving the option to buy to the “BTC for XCP” order for the duration of their order time. At the same time, the initial order requires some expense to create and that should be conidered enough payment to justify one free match. Also, requiring a fee for the first match would allow high fees and low prices reaulting in a strange looking order book.
FOURTH SUGGESTION:
1) Orders requesting BTC may designate an optional variable [max-time] to btcpay (defaults to remaining expiration time):
Only BTC offering orders with less than or equal to this amount of expiration time remaining are matchable. Matches that aren’t paid for in this time are returned to the order book as usual.
DECISION FOR HOW TO IMPLEMENT THIS FEATURE:
EITHER a) the max time will allow extending past the orders expiration time or b) the expiration time remaining must be greater than the max-time or the remaining orders are cancelled. It’s not so important which, just must be documented which method is used.
NOTE: BTC offering orders should NOT have a second variable for lock time because they should need to know EXACTLY when they will need to plan to be online to check orders and having such a variable is too random for someone who wants to collect several matches over a few days an then pay them all by their expiration time. i.e. it would make it too unpredictable just like the current system.
FIFTH SUGGESTION:
This is possibly unnecessary with the other features, but some people might want to trade with each other so this would help them:
Allow direct order matching for the cost of the fee-charged described above.
Self explanatory, but could be from just having a new variable --buy-order XXXX and the order will only match against that order number (either matched or not).
SIXTH SUGGESTION:
There should be a variable for order persistence (or not) (should default to yes as currently provided), but some people might want their order to NOT relist after failed purchases.
In regards to other people’s suggestion to simply charge more miner fees:
As MPT noted, it is wasteful to simply ask for the BTC for Asset order to burn/spend/waste BTC in miner fees, that is equivalent to asking them to piss away money for no benefit.
In regards to escrow, that does not give anyone value immediately for the immediate loss of use of the Asset. That’s why the fee is better. They should be compensated directly for the option if the option is given rather than only compensated in failure to pay.
Also, the current multisig BTC expenses should be fixed, it is crazy to ask people to pay 30 cent for EACH transaction, with most XCP actions requiring multiple transactions.
But that’s another can of worms.
[quote author=jeremy link=topic=71.msg321#msg321 date=1391902131]
I’m heavily invested in the XCP system and want to see it succeed and do better.
MoneypakTrader offered some good solutions for fixing a few of the problems the system currently has: https://bitcointalk.org/index.php?topic=395761.msg5009075#msg5009075
Building on those suggestions, I’d advocate the following improvements:
FIRST SUGGESTION:
All orders should include the major version number of the client issuing the order to prevent matching problems that users have experienced. The protocol should not allow matches of different major version and should inform the user if other version numbers are more popular than the one used to suggest upgrading. The new version should show the old version order book and the new version order book to allow placing orders under either systems.
Essentially these are hard forks. Older clients can still make trades with each other, but for added features and trades with new clients, it must be updated.
Again, new clients should have a feature to view and issue orders/commands at older version levels just in case significant users/orders resist the upgrades and the new client user wishes to match older version orders.
SECOND SUGGESTION:
All orders involving BTC should be able to set an optional variable [minimum] (amount of BTC for each valid match), denominated in BTC (for efficiency reasons). Leftover amounts in the order book for less than the [minimum] should be cancelled from the order book and returned to the owner AFTER ALL other fractions of that order are COMPLETELY BTCpayd for.
This works particularly well when combined with the other following improvements.
Reason:
“BTC for XCP” orders require a second “BTCpay” to complete EACH order match made, this wouldn’t be an issue except:
1) Significant fees (around 40 cents/0.0004btc) are required for EACH “BTCpay” action make small transactions (<1 XCP) proportionally very expensive (as described by moneypaktrader on bitcointalk around their above linked post time).
Here’s a scenario, suppose I want to spend some BTC to buy 50XCP at the best possible DEX rates and the order book looks like this:
XCP for BTC orders:
1 XCP @ 0.0040 (total costs with btcpay = 0.0044 btc/xcp, ignoring the costs to place the btc/xcp orders)
2 XCP @ 0.0041 (total costs with btcpay = 0.0043 btc/xcp, ignoring the costs to place the btc/xcp orders)
1 XCP @ 0.0042 (total costs with btcpay = 0.0046 btc/xcp, ignoring the costs to place the btc/xcp orders)
50 XCP @ 0.00425 (total costs with btcpay = 0.004258 btc/xcp, ignoring the costs to place the btc/xcp orders)
I have an incentive to place a btc for xcp order for enough quantity (or more) to buy at least all the orders through the 50 XCP order but only “btcpay” for the single 50 XCP order match which is the best price for the quantity I want.
When combined with fees per match described below, this feature is almost necessary to avoid excessive fees from numerous matches.
THIRD SUGGESTION:
Because BTC orders get the option to pay or not to complete the order, the orders requesting BTC should be allowed to charge/receive an XCP fee for providing that option. I agree with MPT that this fee should be waived/ignored for the first matched order to prevent clogging the order book with high match fees, the BTC order will be paying sufficient network fees to justify getting a first match without a fee. Also using XCP for this fee will encourage XCP usage and drive demand for XCP by high volume traders.
New Variables needed -
A) Orders requesting BTC have an OPTIONAL variable [fee-charged] (defaults to 0 if not set).
B) Orders offering to pay BTC have an OPTIONAL input [fees-provided] (defaults to 0 if not set). This is deducted from the xcp of the BTC address of the BTC offer and escrowed for use until the order completes/expires.
C) Orders offering to pay BTC have an OPTIONAL variable [max-fee] (defaults to total fees-provided balance or 0 if not set).
How it would work -
The first otherwise valid match to a BTC order is matched with no fee deducted from B.
After the first match, B (fees-provided) and C (max-fee) must be greater than or equal to A (fee-charged) or it does not get matched and goes to the next order/match. The remaining balance of B and variable C must still be greater than or equal to each A of each future match (or A must equal 0 if B=0).
Each match after the first gets paid immediately the XCP value agreed and the balance of B is reduced accordingly. Balance of B is refunded to the BTC offer on completion/expiration of the order.
Why? “XCP for BTC” orders must wait until their order expires and currently receive no compensation for giving the option to buy to the “BTC for XCP” order for the duration of their order time. At the same time, the initial order requires some expense to create and that should be conidered enough payment to justify one free match. Also, requiring a fee for the first match would allow high fees and low prices reaulting in a strange looking order book.
FOURTH SUGGESTION:
1) Orders requesting BTC may designate an optional variable [max-time] to btcpay (defaults to remaining expiration time):
Only BTC offering orders with less than or equal to this amount of expiration time remaining are matchable. Matches that aren’t paid for in this time are returned to the order book as usual.
DECISION FOR HOW TO IMPLEMENT THIS FEATURE:
EITHER a) the max time will allow extending past the orders expiration time or b) the expiration time remaining must be greater than the max-time or the remaining orders are cancelled. It’s not so important which, just must be documented which method is used.
NOTE: BTC offering orders should NOT have a second variable for lock time because they should need to know EXACTLY when they will need to plan to be online to check orders and having such a variable is too random for someone who wants to collect several matches over a few days an then pay them all by their expiration time. i.e. it would make it too unpredictable just like the current system.
FIFTH SUGGESTION:
This is possibly unnecessary with the other features, but some people might want to trade with each other so this would help them:
Allow direct order matching for the cost of the fee-charged described above.
Self explanatory, but could be from just having a new variable --buy-order XXXX and the order will only match against that order number (either matched or not).
SIXTH SUGGESTION:
There should be a variable for order persistence (or not) (should default to yes as currently provided), but some people might want their order to NOT relist after failed purchases.
In regards to other people’s suggestion to simply charge more miner fees:
As MPT noted, it is wasteful to simply ask for the BTC for Asset order to burn/spend/waste BTC in miner fees, that is equivalent to asking them to piss away money for no benefit.
In regards to escrow, that does not give anyone value immediately for the immediate loss of use of the Asset. That’s why the fee is better. They should be compensated directly for the option if the option is given rather than only compensated in failure to pay.
[/quote]
My current response to this is: 1) I don’t see how such a system would be better than the current one (which does work). 2) We need technical details as to how such protocol changes would be implemented, and implemented very simply.
Including version numbers in orders won’t solve anything, because orders are not the only potential problem points with backwards-incompatible protocol changes. We can’t have multiple, independent, complete Counterparty protocols all operating at once.
The multi-sig outputs are not fees, and their size is determined by the Bitcoin core devs… And if they were fees, they’d be very competitive! And they’re very probably temporary!
Your sixth suggestion is good, but I need to think about it some more.
[quote author=PhantomPhreak link=topic=71.msg329#msg329 date=1391913149]
Including version numbers in orders won’t solve anything, because orders are not the only potential problem points with backwards-incompatible protocol changes. We can’t have multiple, independent, complete Counterparty protocols all operating at once.
[/quote]
Indeed - you want to stick to one version at any point in time. Why not implement hard forking protocol changes to take effect “from block N onward”, where N is some future block by which point everybody is required to upgrade.
In such a scenario protocol version numbers in the block chain could be useful as a mechanism for outdated clients to recognise that they require an upgrade and warn users.
[quote author=gacrux link=topic=71.msg333#msg333 date=1391925441]
[quote author=PhantomPhreak link=topic=71.msg329#msg329 date=1391913149]
Including version numbers in orders won’t solve anything, because orders are not the only potential problem points with backwards-incompatible protocol changes. We can’t have multiple, independent, complete Counterparty protocols all operating at once.
[/quote]
Indeed - you want to stick to one version at any point in time. Why not implement hard forking protocol changes to take effect “from block N onward”, where N is some future block by which point everybody is required to upgrade.
In such a scenario protocol version numbers in the block chain could be useful as a mechanism for outdated clients to recognise that they require an upgrade and warn users.
[/quote]
That’s exactly how it’s being done. I’m about to add a sort of warning system to encourage users to upgrade their clients when necessary.
[quote author=PhantomPhreak link=topic=71.msg329#msg329 date=1391913149]
My current response to this is: 1) I don’t see how such a system would be better than the current one (which does work). 2) We need technical details as to how such protocol changes would be implemented, and implemented very simply.
[/quote]
If alpha tester/s do break the order book again, the fourth suggestion would be better than the current system because the btc offers would only lock the book for the duration of the btc offer and not for the full duration of the asset offer as could be currently done. I can’t wait until the protocol is hardened against such rigorous alpha testers.
The lock time variable doesn’t need to be implemented at first, the quick fix of comparing time left before matching could implement that non-matching algorythm in 200-300 blocks from the time the order book is broken to allow traders to resume trading. Then the full fix (allowing assets to designate the lock time) could be implemented in the future.
Technical details of the quick implementation/fix:
NEW CODE:
Orders offering btc DO NOT/WILL NOT MATCH WITH asset offers if the asset expiration time left is less than the btc offer expiration time left.
Orders requesting btc DO NOT/WILL NOT MATCH btc offers if the asset expiration time left is less than the btc offer expiration time left.
Then the new lockin time optional variable could be added in the future to replace the asset expiration time left once more effort can be put into fixing this problem and further minimizing the bug that is surely to be revealed again.
Here was the original fix description just described in more detail:
FOURTH SUGGESTION:
1) Orders requesting BTC may designate an optional variable [max-time] to btcpay (defaults to remaining expiration time):
Only BTC offering orders with less than or equal to this amount of expiration time remaining are matchable. Matches that aren’t paid for in this time are returned to the order book as usual.
DECISION FOR HOW TO IMPLEMENT THIS FEATURE:
EITHER a) the max time will allow extending past the orders expiration time or b) the expiration time remaining must be greater than the max-time or the remaining orders are cancelled. It’s not so important which, just must be documented which method is used.
NOTE: BTC offering orders should NOT have a second variable for lock time because they should need to know EXACTLY when they will need to plan to be online to check orders (the natural expiration of the btc offer) and having such a variable is too random for someone who wants to collect several matches over a few days an then pay them all by their expiration time. i.e. it would make it too unpredictable just like the current system.
Forcing all BTCpay to be conducted within a specific time and/or including a Auto BTCPay option are both bad ideas because:
BTC offers currently can set the time they intend to btcpay within and both of these suggestions remove that power of the btc order placer.
i.e the suggestions remove power from the client, the user of the protocol and would be going backwards instead of forwards.
Canceling BTC offers before their intended timeout is a bad idea because the BTC order placer knows best when they want to review the orders they collected and pay them. That’s the benefit of paying to put their order on the market. If Asset offerors don’t want to wait that long they should put shorter expiration times (or match timeout variable time if implemented).
Locking up a btc offer with a 10 round match time when the btc offer already stated “I will pay by 100 rounds” is removing the power from a trader to make that decision they can currently make.
Further, burning more fees are not going to make the problems better or solve them, there is no clear explanation of how burning more miner fees per order help active traders more than create another hurdle for decentralized trading altogether.
The points I made are fairly accurate for the more obvious issues.
A particularly useful and easy fix to the order matching problems that alpha testers experienced is suggestion 4 that I proposed which ADDS NO EXTRA FEES and solves the demonstrated order book problem with MINIMAL changes to the protocol.
Shouldn’t the traders be given freedom to use the protocol however they see fit? (high/low fees burned or paid to who they want to trade with in what quantities they want to trade per btcpay in the timeframe they select?)
Please, just implement suggestion (4) to allow btc traders to choose the timeframe they want to have and more fairly to minimize the effects of “gaming” the market from other random test orders but also not add MORE fees unless orders require it. The traders clearly want to not require (more) fees as you see from the order book the most popular choice is none.
Please read all the suggestions (above in thread), But here’s the technical details of how the protocol would change after the first fix:
NEW CODE:
Orders offering btc DO NOT/WILL NOT MATCH WITH asset offers if the asset expiration time left is less than the btc offer expiration time left.
Orders requesting btc DO NOT/WILL NOT MATCH btc offers if the asset expiration time left is less than the btc offer expiration time left.
Other proposals are not so different I just believe the one I detailed is more explicit with how it fixes and adds functionality to the protocol.