PhantomPhreak (OP)
Sr. Member
Offline
Activity: 476
Merit: 300
Counterparty Chief Scientist and Co-Founder
|
|
February 07, 2014, 02:14:29 AM |
|
If you don't want your orders to sell XCP for BTC to get eaten, then you need to set a higher fee_required. Note that only orders to buy BTC have this issue, and there's no way around it that I can think of.
Maybe someone else can think of something. . . To the Dev/s: The following counterpartyd protocol/CLI issues should be resolved: FIX: a) XCP for BTC offer should include an option/variable to limit block period for a matching order lock (lockperiod) and a failure to BTCpay in such time period should reinstate the temporarily locked offer (instead of canceling as it currently does)
This would prevent total wiping and make it temporary at best (10 blocks ~ 90 minutes, shorter for greater persistence). many other options, but this resolves multiple issues at once. My point IN RE FEES, is there should be NO FEES outside of OPTIONAL transaction fees if people choose to pay them, thus allowing XCP to be more usable. Each bitcoin transaction requires a 0.0001 BTC fee paid to the mining network.
wrong: https://blockchain.info/block-index/465919/00000000000000006e1a275bff2757913c4513c7e361ccb19ee6f2734ba1e8f1click advanced at bottom, and starting at bottom of page you will see MANY bitcoin transactions with NO FEE, AKA 0 FEE. The 0.0001086 BTC values in XCP transactions are put into a 1 of M Multisig escrow which you are theoretically able to spend. Currently I'm not sure which, if any, wallet clients support spending of Multisig outputs, but if you really wanted to you could craft a raw transaction to spend them today (not recommended) Hopefully counterpartyd will support spending of these outputs natively at some point.
Currently they are spent and at some point in the future, it is theoretical that we may get them back. On my balance statement I can only mark it as an expense for now. 2) no BTCSend support outside of BTCPay b) Improve: Allow counterpartyd BTCsend fromaddress toaddress BTC fee(optional/can use default) c) Improve: Allow BTCSend and XCP at same time to an address d) BONUS: Allow BTCSend to ASSET which divides the BTC among all asset holders similar to how XCP dividend should be distribued
3) Escrowed/Multisig Bitdust is unspendable in counterpartyd. a) fix: allow spending such dust natively in counterpartyd
4) MINOR: market display updates. a) Reorganize market CLI to display Feeds, then Bets, then Open Orders with BTC/XCP & XCP/BTC orders and Order matches awaiting BTCpay LAST in chart. b) Update sorting open orders by asset exchange type first (XCP/BTC, etc.), then ratio second (subsorting inside the different types). i.e. force XCP/BTC BTC/XCP last in chart for easier viewing.
5) Regarding Major Program/Protocol revisions: Please don't change significant aspects of the protocol (such as asset fees) without consulting stakeholders. Specifically In Re: Asset creation fees: Where does this new fee go? Ideally it would be either extinguished (to the burn address) or distributed among all XCP stakeholders.
Crossposted to my own thread: We have enabled a simple DEX trading option/platform to expand people's options and hopefully gain that market share (of allowing non-technical bitcoin holders to invest in or send XCP/DEX). This is an innovative and unique service similar to our MP/BTC trading services. Anyone with the private key for their BTC address can buy XCP/MPTSTOCK by sending BTC to our specified address (see our forum thread or website). We then spend the BTC on the DEX to buy XCP/MPTSTOCK which is sent (minus 10% commission) to the Buyer's address. Essentially - Anyone can buy XCP/DEX Assets by sending bitcoins from their bitcoin client to our current XCP buy address (shown on both our site and our bitcointalk thread for redundancy). This will work for any client/address which the buyer has the private key for (pretty much all BTC clients except exchange accounts). When our messenger (TC and/or FB) shows green, this service is available for rapid processing at a premium. Otherwise, our goal is to process all such transactions within 24-48 hrs. Frequency of trades will depend on volume of submitted orders.
THANKS to all the Dev's! It seems like these ideas are not under consideration, yes? Right now BTCpays are allowed until one of the matched orders expires. Changing this is a real possibility. Fees =/= min. dust output size. Transactions with multi-sig outputs that aren't at least .0001086 BTC in size are not delayed---they are flat-out rejected by the Bitcoind network. If you don't want to pay the .0001 BTC transaction fee, change the appropriate line in config.py. The Counterparty protocol doesn't care. Your previous suggestions are under consideration.
|
|
|
|
PhantomPhreak (OP)
Sr. Member
Offline
Activity: 476
Merit: 300
Counterparty Chief Scientist and Co-Founder
|
|
February 07, 2014, 02:16:28 AM |
|
If you don't want your orders to sell XCP for BTC to get eaten, then you need to set a higher fee_required. Note that only orders to buy BTC have this issue, and there's no way around it that I can think of. The problem with that, besides the fact that it kind of misses the point, is that Bitcoind cannot look up the balance of an arbitrary address. Surely though since counterparty can issue "lib.exceptions.BalanceError: Insufficient bitcoins at address" errors, that means it's possible to check locally if the person selling BTC actually has that much to sell (just as a sanity check)? I'm not worried about the balance in remote addresses. But that's a client-side check. Anyone can craft their own raw transaction to get around that. EDIT: Although I agree that having this client-side check would at least discourage most people from sweeping the book, as well as unintentionally trying to sell BTC they don't have +1, I think the people who want to try to sweep the order book and the people who know how to craft a raw transaction are pretty mutually exclusive. It's not even a question of crafting a raw transaction, but rather of deleting one line of Python code. Alright, you've made your point and I agree. How about moneypaktrader's suggestion though? A lockin period + the ability to reinstate orders automatically? Also is fee_required / fee_provided deducted at the time of match, or btc payment? If the latter, then that approach is also useless, because someone could simply put an absurdly high fee and not intend to actually pay it. This is kind of similar to the asset name issue we had a while back... Orders are reinstated automatically now. The issue is that users are given a long time to make the BTC payments. fee_required and fee_provided both refer to Bitcoin transaction fees paid to miners immediately.
|
|
|
|
mtbitcoin
Legendary
Offline
Activity: 876
Merit: 1000
Etherscan.io
|
|
February 07, 2014, 02:20:19 AM |
|
Another suggestion: Require 1XCP to be escrowed for each order match beyond the first, which is returned on successful BTCpay, otherwise it goes to the person whose order was offline for the lockin period? Thus a new BTC order must be submitted for EACH order to be wiped unless they escrow XCP
Edit: or even 0.01 XCP to be escrowed. Obviously such a change should be implemented at a certain block number in future to allow people to prepare for the changeover. Those are several of the glaring problems I see (order wiping, High fees, etc.).
+1 going forward we will need to work on mechanisms to prevent intentional abuse and trolling. A small value of 0.1 or perhaps a percentage value of the XCP purchased could be escrowed ( XCP or btc) and refunded after a btcpay is successfully completed. Failing which these coins are distributed among the matched orders that are not paid or just burnt as fees.
|
|
|
|
PhantomPhreak (OP)
Sr. Member
Offline
Activity: 476
Merit: 300
Counterparty Chief Scientist and Co-Founder
|
|
February 07, 2014, 02:25:39 AM |
|
Another suggestion: Require 1XCP to be escrowed for each order match beyond the first, which is returned on successful BTCpay, otherwise it goes to the person whose order was offline for the lockin period? Thus a new BTC order must be submitted for EACH order to be wiped unless they escrow XCP
Edit: or even 0.01 XCP to be escrowed. Obviously such a change should be implemented at a certain block number in future to allow people to prepare for the changeover. Those are several of the glaring problems I see (order wiping, High fees, etc.).
+1 going forward we will need to work on mechanisms to prevent intentional abuse and trolling. A small value of 0.1 or perhaps a percentage value of the XCP purchased could be escrowed and refunded after a btcpay is successfully completed. Failing which these coins are distributed among the matched orders that are not paid or just burnt as fees Then one would need to own XCP before being able to buy XCP on the distributed exchange (with BTC).
|
|
|
|
mtbitcoin
Legendary
Offline
Activity: 876
Merit: 1000
Etherscan.io
|
|
February 07, 2014, 02:35:13 AM |
|
Another suggestion: Require 1XCP to be escrowed for each order match beyond the first, which is returned on successful BTCpay, otherwise it goes to the person whose order was offline for the lockin period? Thus a new BTC order must be submitted for EACH order to be wiped unless they escrow XCP
Edit: or even 0.01 XCP to be escrowed. Obviously such a change should be implemented at a certain block number in future to allow people to prepare for the changeover. Those are several of the glaring problems I see (order wiping, High fees, etc.).
+1 going forward we will need to work on mechanisms to prevent intentional abuse and trolling. A small value of 0.1 or perhaps a percentage value of the XCP purchased could be escrowed and refunded after a btcpay is successfully completed. Failing which these coins are distributed among the matched orders that are not paid or just burnt as fees Then one would need to own XCP before being able to buy XCP on the distributed exchange (with BTC). Yes ...I noticed that after posting which is why I edited my post. Could a small value of btc be locked up then as fees transaction fees Going forward I wonder if some sort of reputation system could be placed depending on order history of the address. Perhaps when placing an order another requirement I.e fee-required ..could rep_required=5. Meaning an address that is correctly completed 5 successful btcpay orders are only allowed to match The above is a simplistic example but something similar could be worked on. Alternatively orders with escrowed XCP are categorized differently and sellers can specify that they will only want to match with purchasers that have XCP escrowed I think going forward it's quite obvious that using the platform for anything even closely resembling hft would be unpractical so the additional requirements before placing an order can be accepted
|
|
|
|
gacrux
Newbie
Offline
Activity: 22
Merit: 0
|
|
February 07, 2014, 02:35:29 AM |
|
Heads up, I see some more invalid order matches:
3288 284402 1AQPf7f3y37NN9XsYkfGGALHQiW1ig3MXb 2014-02-06 05:29:18 023d390307488909fc6b05a37a3335... Invalid: invalid order match ID, 023d390307488909f... 3286 284391 1JUXwDjh21yLkUhKNdggenexZK8XpeXTRx 2014-02-06 04:26:13 023d390307488909fc6b05a37a3335... Invalid: invalid order match ID, 023d390307488909f... 3285 284390 1CJTDpHBvcQw4e7FCKzkT9j62PuXegWdYN 2014-02-06 04:14:45 023d390307488909fc6b05a37a3335... Invalid: invalid order match ID, 023d390307488909f... 3282 284386 1CJTDpHBvcQw4e7FCKzkT9j62PuXegWdYN 2014-02-06 04:26:07 023d390307488909fc6b05a37a3335... Invalid: invalid order match ID, 023d390307488909f...
Someone needs to update their client?
Holy crap, that's me! Well, 1JUXwDjh21yLkUhKNdggenexZK8XpeXTRx and 1CJTDpHBvcQw4e7FCKzkT9j62PuXegWdYN at least. Wish I'd seen this thread earlier :-( Already posted about this here: https://bitcointalk.org/index.php?topic=406408.20And here: https://forums.counterparty.co/index.php/topic,2.0.htmlI thought I was up to date. I cloned from master yesterday. Did a git pull from ~/counterpartyd today, but forgot to also run git pull in ~/counterpartyd/dist/counterpartyd , which I'm guessing is what has bitten me. Would you do another test purchase now, so that I can be absolutely sure that the problem has in fact been fixed for you? As stated, the devs will compensate you for the BTC you send in those transactions. That's mighty kind of you; thank you! I'll PM you the relevant txns on the Counterparty Forums regarding your offered reimbursement, which is much appreciated. I have pulled from master and attempted another purchase to help you test: http://blockscan.com/order.aspx?q=3337However, with 6/10 blocks to go until expiry, my offer (buy 5 XCP @ 0.005 BTC per each) so far remains unmatched At the time I posted my buy order there were no sell orders within an order of magnitude of it. It appears that somebody has swept the order book clean with a ridiculously large offer (which they presumably don't intend to fulfil with BTCPAY) in order to get the front page of blockscan.com to display: Last DEX Matched Price : 1000.0000 BTC/XCP @ $756,500.000 I can try another test buy later, once the order book straightens itself out. Hope this helps. I'm not sure there's an easy way to mitigate this attack - does anyone who wants to match my order get automatically matched against the ridiculously high fake one first? I guess they could require a higher fee... and I could pay a higher fee....?
|
|
|
|
porqupine
|
|
February 07, 2014, 02:42:22 AM |
|
Could you require BTC Sell XCP Buy orders to Proof of Burn some very marginal amount of BTC? - it would serve as a deterrent from placing Spam orders.
|
|
|
|
mtbitcoin
Legendary
Offline
Activity: 876
Merit: 1000
Etherscan.io
|
|
February 07, 2014, 02:50:04 AM |
|
Could you require BTC Sell XCP Buy orders to Proof of Burn some very marginal amount of BTC? - it would serve as a deterrent from placing Spam orders.
It's a catch 22 in this case. Because a proof of burn address most likely already has XCP on balance and a XCP escrow would work. Also checking an address for proof of burn should be trivial but over time the effectiveness would diminish as new users flood the system. I think an optional XCP fees escrowed system and an option for sellers to only matched orders with XCP escrowed could work. As biggest fish pointed out its only time that centralized exchanges start popping out and most btc /XCP trades would take place here. The key word here is here is 'optional' escrow.
|
|
|
|
PhantomPhreak (OP)
Sr. Member
Offline
Activity: 476
Merit: 300
Counterparty Chief Scientist and Co-Founder
|
|
February 07, 2014, 03:01:04 AM |
|
Heads up, I see some more invalid order matches:
3288 284402 1AQPf7f3y37NN9XsYkfGGALHQiW1ig3MXb 2014-02-06 05:29:18 023d390307488909fc6b05a37a3335... Invalid: invalid order match ID, 023d390307488909f... 3286 284391 1JUXwDjh21yLkUhKNdggenexZK8XpeXTRx 2014-02-06 04:26:13 023d390307488909fc6b05a37a3335... Invalid: invalid order match ID, 023d390307488909f... 3285 284390 1CJTDpHBvcQw4e7FCKzkT9j62PuXegWdYN 2014-02-06 04:14:45 023d390307488909fc6b05a37a3335... Invalid: invalid order match ID, 023d390307488909f... 3282 284386 1CJTDpHBvcQw4e7FCKzkT9j62PuXegWdYN 2014-02-06 04:26:07 023d390307488909fc6b05a37a3335... Invalid: invalid order match ID, 023d390307488909f...
Someone needs to update their client?
Holy crap, that's me! Well, 1JUXwDjh21yLkUhKNdggenexZK8XpeXTRx and 1CJTDpHBvcQw4e7FCKzkT9j62PuXegWdYN at least. Wish I'd seen this thread earlier :-( Already posted about this here: https://bitcointalk.org/index.php?topic=406408.20And here: https://forums.counterparty.co/index.php/topic,2.0.htmlI thought I was up to date. I cloned from master yesterday. Did a git pull from ~/counterpartyd today, but forgot to also run git pull in ~/counterpartyd/dist/counterpartyd , which I'm guessing is what has bitten me. Would you do another test purchase now, so that I can be absolutely sure that the problem has in fact been fixed for you? As stated, the devs will compensate you for the BTC you send in those transactions. That's mighty kind of you; thank you! I'll PM you the relevant txns on the Counterparty Forums regarding your offered reimbursement, which is much appreciated. I have pulled from master and attempted another purchase to help you test: http://blockscan.com/order.aspx?q=3337However, with 6/10 blocks to go until expiry, my offer (buy 5 XCP @ 0.005 BTC per each) so far remains unmatched At the time I posted my buy order there were no sell orders within an order of magnitude of it. It appears that somebody has swept the order book clean with a ridiculously large offer (which they presumably don't intend to fulfil with BTCPAY) in order to get the front page of blockscan.com to display: Last DEX Matched Price : 1000.0000 BTC/XCP @ $756,500.000 I can try another test buy later, once the order book straightens itself out. Hope this helps. I'm not sure there's an easy way to mitigate this attack - does anyone who wants to match my order get automatically matched against the ridiculously high fake one first? I guess they could require a higher fee... and I could pay a higher fee....? Your new order has been matched.
|
|
|
|
jimhsu
|
|
February 07, 2014, 03:22:40 AM |
|
Could you require BTC Sell XCP Buy orders to Proof of Burn some very marginal amount of BTC? - it would serve as a deterrent from placing Spam orders.
It's a catch 22 in this case. Because a proof of burn address most likely already has XCP on balance and a XCP escrow would work. Also checking an address for proof of burn should be trivial but over time the effectiveness would diminish as new users flood the system. I think an optional XCP fees escrowed system and an option for sellers to only matched orders with XCP escrowed could work. As biggest fish pointed out its only time that centralized exchanges start popping out and most btc /XCP trades would take place here. The key word here is here is 'optional' escrow. +1. Once we stop caring that a buyer needs XCP to buy XCP there is a lot that's possible. Optional XCP escrow released upon successful BTCPay is another great idea. Where would XCP be without mtbitcoin... I am starting an mtbitcoin fan club. Not to be confused with mtgox. I would say the most immediate change should be a lockin parameter to directly address the inability to get XCP back in a short timeframe from this attack. We can then implement some sort of (optional) XCP escrow system, and then followed by a reputation system in the indeterminate future. To allow new buyers to currently buy XCP, allow single orders to be bought without regard to the escrow requirement. All of these things will of course need to be thoroughly tested.
|
Dans les champs de l'observation le hasard ne favorise que les esprits préparé
|
|
|
porqupine
|
|
February 07, 2014, 03:26:01 AM |
|
Could you require BTC Sell XCP Buy orders to Proof of Burn some very marginal amount of BTC? - it would serve as a deterrent from placing Spam orders.
It's a catch 22 in this case. Because a proof of burn address most likely already has XCP on balance and a XCP escrow would work. Also checking an address for proof of burn should be trivial but over time the effectiveness would diminish as new users flood the system. I think an optional XCP fees escrowed system and an option for sellers to only matched orders with XCP escrowed could work. As biggest fish pointed out its only time that centralized exchanges start popping out and most btc /XCP trades would take place here. The key word here is here is 'optional' escrow. I didn't mean a burn period Proof of Burn - but rather a fee based Proof of Burn for initializing an XCP buy order for a new address without XCP. (And then you could use the escrow method once an XCP balance for the address exists).
|
|
|
|
MoneypakTrader.com
Sr. Member
Offline
Activity: 472
Merit: 250
Never spend your money before you have it.
|
|
February 07, 2014, 03:36:09 AM Last edit: February 07, 2014, 04:31:31 AM by MoneypakTrader.com |
|
Requiring people to pay extra mining fees is wasteful. I'd suggest:
XCP/BTC orders can designate these new variables/fees: 1) BTCpay lockin time in blocks as a variable for XCP orders: ****only BTC orders with less than or equal to this time left are matchable.*** 2) BTC order lockin Fee (in XCP) (Ignored for first order match) allowed to be set by XCP orders and BTC orders. 3) Optional Lockin Fees (XCP) paid by BTC orders to cover matches beyond the first. (with maximum lockin fee per match in (2) above or no maximum if not set in 2 above). 4) XCP orders (beyond first match) in order are paid from the XCP paid in exchange for the privilege of the lock in time received to BTCpay. Only btc orders designating lockin fee more than or equal to the lockin fee required by the XCP orders are matchable IF the remaining lockin fees are sufficient to pay it. 5) Minimum match amount (in XCP) as another option for BTC orders (to prevent BTCpay fee problems) since each match requires btcpay, only makes sense to let btc orders set minimum they are willing to btcpay for.
I.E. NO XCP required for first BTC/XCP match, but optional market driven XCP requirements for additional matches. This will help drive demand for XCP as well as fix this bug.
Moving the XCP encoded transactions to a method that doesn't require BTC should be a high priority to allow the possibility of XCP trading using the absolute minimum of BTC fees required, ZERO in some cases if BTC is sent to senders address from sufficiently aged blocks.
But anyways, this is something that people should be given a few days to prepare for and be implemented at a specific block number. The core protocol shouldn't be tweaked so much and something stable needs to be pushed that will work indefinitely.
|
|
|
|
BitThink
Legendary
Offline
Activity: 882
Merit: 1000
|
|
February 07, 2014, 03:48:27 AM |
|
Could I confirm whether my understanding of current issue is correct?
Malicious people can match any XCP sell orders with a tiny cost now. Those eaten orders have to wait until the matches expire. Currently the client cannot check the buyer's BTC balance because bitcoind does not provide this function.
My question is 1) bitcoind does not provide the function to check balance of an arbitrary address, but it can provide the user's own balance and unspent outputs. Could we put this checking in XCP client or it is already there?
A solution of the chicken-egg problem:
Could we set a maximum buy order for those without XCP escrow. For example, without XCP escrow, you can only buy 10XCP. Then with this 10XCP as escrow, you can buy 1000XCP. Something like this can help to avoid abuse with Large buy orders without escrow.
|
|
|
|
MoneypakTrader.com
Sr. Member
Offline
Activity: 472
Merit: 250
Never spend your money before you have it.
|
|
February 07, 2014, 04:00:28 AM |
|
Could I confirm whether my understanding of current issue is correct? Malicious people can match any XCP sell orders with a tiny cost now. Those eaten orders have to wait until the matches expire.
The whole point of designing a protocol is to make "malicious people" irrelevant. We are designing a system that is provably fair to the participants with a simple rule system enforced at the protocol level just like bitcoin does. My suggestion 2 posts above allows more variables to allow orders to be customized and prevent the current problems.
|
|
|
|
ddink7
Legendary
Offline
Activity: 1120
Merit: 1000
|
|
February 07, 2014, 04:05:07 AM |
|
Tx0 Tx0_Address Forward Asset Tx1 Tx1_Address Backward Asset Remarks 3337 12b79vxJ3mv7b7mWJjApidEjcDntCHm6vT 0.02499951 BTC 3340 1Pcpxw6wJwXABhjCspe3CNf3gqSeh6eien 4.999902 XCP Valid: awaiting BTC payment 3336 1LVDTWudnKaNHjamPzRSjyhEuXeqK6BH5V 4802.70770001 BTC 3340 1Pcpxw6wJwXABhjCspe3CNf3gqSeh6eien 0.00009605 XCP Valid: awaiting BTC payment 3336 1LVDTWudnKaNHjamPzRSjyhEuXeqK6BH5V 4802.70770001 BTC 3338 1EEwWVYaSF2QUsv3nMz8h5uGifHiuza485 0.00009605 XCP Invalid: expired awaiting BTC payment 3325 1MNfSB1apnK45FacyFtFnxcopp6E6MV4nc 100 XCP 3336 1LVDTWudnKaNHjamPzRSjyhEuXeqK6BH5V 0.75 BTC Valid: awaiting BTC payment 3318 1bLockjTFXuSENM8fGdfNUaWqiM4GPe7V 10 XCP 3336 1LVDTWudnKaNHjamPzRSjyhEuXeqK6BH5V 0.1 BTC Valid: awaiting BTC payment 3314 18sinvadjvf7i5RXE4ns9sSH1iPrDeA1n9 1000 XCP 3336 1LVDTWudnKaNHjamPzRSjyhEuXeqK6BH5V 50 BTC Valid: awaiting BTC payment 3308 1Jkx1LVfHgZWa8sHEN9BnNeYN7WfSwNmbf 1000 XCP 3336 1LVDTWudnKaNHjamPzRSjyhEuXeqK6BH5V 50 BTC Valid: awaiting BTC payment 3306 14SwRtFfpVrSFYBHzzq6PcvR8dCexWrHZC 5.53238637 XCP 3335 1AQPf7f3y37NN9XsYkfGGALHQiW1ig3MXb 0.025 BTC Valid: awaiting BTC payment 3306 14SwRtFfpVrSFYBHzzq6PcvR8dCexWrHZC 1.54906818 XCP 3332 1LCrVCMAoKQ6QHEXLTXBWjhtgcF1cx2Wd6 0.007 BTC Valid 3306 14SwRtFfpVrSFYBHzzq6PcvR8dCexWrHZC 1.77036363 XCP 3328 1LCrVCMAoKQ6QHEXLTXBWjhtgcF1cx2Wd6 0.008 BTC Valid: awaiting BTC payment 3306 14SwRtFfpVrSFYBHzzq6PcvR8dCexWrHZC 8.85181818 XCP 3322 1AQPf7f3y37NN9XsYkfGGALHQiW1ig3MXb 0.04 BTC Invalid: expired awaiting BTC payment 3291 1Fz5idgemYfsszRMmaQNd2Anvm2JytAoU 72.72 XCP 3336 1LVDTWudnKaNHjamPzRSjyhEuXeqK6BH5V 0.5083 BTC Valid: awaiting BTC payment 3280 18sinvadjvf7i5RXE4ns9sSH1iPrDeA1n9 100 XCP 3336 1LVDTWudnKaNHjamPzRSjyhEuXeqK6BH5V 2 BTC Valid: awaiting BTC payment 3275 1PUis3DiofnDQjNS8HbuMABj8xYLiWWNWR 0.08 BTC 3319 1PBmybpJ9DXFCMqGdcMHd7FdbVYLajH5nU 20 XCP Valid: awaiting BTC payment 3275 1PUis3DiofnDQjNS8HbuMABj8xYLiWWNWR 0.008 BTC 3295 1PBmybpJ9DXFCMqGdcMHd7FdbVYLajH5nU 2 XCP Valid: awaiting BTC payment 3261 14SwRtFfpVrSFYBHzzq6PcvR8dCexWrHZC 50 XCP 3336 1LVDTWudnKaNHjamPzRSjyhEuXeqK6BH5V 0.25 BTC Valid: awaiting BTC payment Looks like someone went through and locked up all the sell orders on the DEX. Blockscan now shows only one sell order still standing.
|
|
|
|
BitThink
Legendary
Offline
Activity: 882
Merit: 1000
|
|
February 07, 2014, 04:10:52 AM |
|
Yes, without escrow, anyone can eat all the sell orders without much cost. Therefore, I suggest 1) add proportional escrow fee in XCP for buy orders. 2) buy orders less than 10 XCP is free from escrow fee, so new users without XCP can still use the exchange. All escrow fee goes to the seller if Btcpay is not sent in time. Otherwise, it goes back to the buyer.
|
|
|
|
BitThink
Legendary
Offline
Activity: 882
Merit: 1000
|
|
February 07, 2014, 04:40:40 AM |
|
Yes, without escrow, anyone can eat all the sell orders without much cost. Therefore, I suggest 1) add proportional escrow fee in XCP for buy orders. 2) buy orders less than 10 XCP is free from escrow fee, so new users without XCP can still use the exchange. All escrow fee goes to the seller if Btcpay is not sent in time. Otherwise, it goes back to the buyer.
I see one potential problem with the XCP escrow solution: what do we do about honest XCP buyers who want to place limit orders? Unless I am mistaken, under this system if I place a resting limit order to buy XCP and turn off my computer, I run the risk of an XCP seller hitting my bid and collecting the escrowed XCP, since I am not around to execute a BTCPay. This would really discourage XCP buyers from placing resting orders. Maybe this is not a bad thing though. Since XCP is not built for high-frequency trading there is nothing wrong with a 1-sided order book reflecting the asymmetry in XCP/BTC exchange. The XCP/BTC exchange would just resemble Ebay instead of the NYSE. I am not sure how the expire time of BTCPay is set. Is it always set by the XCP sellers? Could the buyer of limit order set it? If it is set by the buyer, then problem solved. How about who put the order first always determine the BTCPay expire time?
|
|
|
|
MoneypakTrader.com
Sr. Member
Offline
Activity: 472
Merit: 250
Never spend your money before you have it.
|
|
February 07, 2014, 04:44:21 AM |
|
Unless I am mistaken, under this system if I place a resting limit order to buy XCP and turn off my computer, I run the risk of an XCP seller hitting my bid and collecting the escrowed XCP, since I am not around to execute a BTCPay.
Doesn't my suggestion fix that? Yes, BTC orders should be observant close to their expiration time since the BTC order time left is the "lock in" time and they risk losing the fee without fulfilment if they aren't ready to execute the BTCpay. Alternatively, there could be an additional variable for BTC orders lock in time in addition to time left/time to live but then it would be difficult for the btc order wince they'd need to not leave their computer for longer than the lock in time while their order is open or they risk losing the fee without benefit. My suggestion: https://bitcointalk.org/index.php?topic=395761.msg4988118#msg4988118
|
|
|
|
mtbitcoin
Legendary
Offline
Activity: 876
Merit: 1000
Etherscan.io
|
|
February 07, 2014, 06:14:08 AM |
|
Hi PhantomPreak I am also running into this issue. Managed to get it resolved once by sending coins in but consequently the same issue occurred. I've sent you a pm with the debug information
|
|
|
|
Matt Y
|
|
February 07, 2014, 06:26:34 AM |
|
Want to buy:
Counterparty technical lessons. I want to know more about the protocol and would like someone to teach me. Skype is preferred but I can also do Google Hangouts Will pay in bitcoin. Please PM offers which include a short explanation of what you will be teaching me.
Thanks.
|
|
|
|
|