It is possible to set two expire time ?
1) expire time for the order
2) expire time for the btcpay
Thks
Topic: [ANN][XCP] Counterparty - Pioneering Peer-to-Peer Finance - Official Thread - page 538. (Read 1276928 times)
February 07, 2014, 07:39:47 AM
February 07, 2014, 07:14:18 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.
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?
The expire time of BTCpay is simply the lesser of the two expirations involved in the transaction.
Thanks. Then it is a little bit more difficult to punish the late buyers since the sellers can attack the buyers by setting a very short expire time.
One possible solution is maybe only the one who matches the existing orders needs to put some XCP in escrow. This could prevent someone eat up all sell orders without cost.
This solution, however, cannot prevent another kind of manipulation. Say current the lowest sell order is at 0.01. Then I can put a limit buy order 1M XCP @ 0.009999, so that I can ensure nobody can really sell to the bid walls.
It seems this kind of attack is arguably less harmful than a big buy orders to eat up all sell orders.
Let's think together to see whether there's better solution.
Moreover, even checking BTC bandwidth is doable, it cannot prevent the attack. Only put BTC in escrow can avoid this kind of attack completely.
The only reason that all of those sell orders got eaten is that nobody set a reasonable fee_required. The current fee system is somewhat inefficient, though.
If the time allowed for a btcpay were to be shortened, which would be done simply so that the market is more responsive, then it would be made a fixed length, e.g. of 10 blocks. I can't imagine why a seller would care about how this value is set, as long as it's long enough.
February 07, 2014, 07:07:02 AM
Code:
C:\python32\python.exe C:\counterpartyd_build\run.py order --source=1Fxxxxxx........ --get-quantity=20 --get-asset=BTC --give-quantity=990 --give-asset=XCP --expiration=3000 --fee_required=.0001
then
Code:
Traceback (most recent call last):
File "C:\counterpartyd_build\dist\counterpartyd\counterpartyd.py", line 521, i
n
args.expiration, fee_required, fee_provided, unsigned=args.unsigned)
File "C:\counterpartyd_build\dist\counterpartyd\lib\order.py", line 47, in cre
ate
return bitcoin.transaction(source, None, None, fee_provided, data, unsigned=
unsigned)
File "C:\counterpartyd_build\dist\counterpartyd\lib\bitcoin.py", line 371, in
transaction
transaction = serialise(inputs, destination_output, data_output, change_outp
ut, multisig=multisig, source=source, unsigned=unsigned)
File "C:\counterpartyd_build\dist\counterpartyd\lib\bitcoin.py", line 217, in
serialise
secret_exponent, compressed = wif_to_tuple_of_secret_exponent_compressed(pri
vate_key_wif, is_test=testnet)
TypeError: wif_to_tuple_of_secret_exponent_compressed() got an unexpected keywor
d argument 'is_test'
File "C:\counterpartyd_build\dist\counterpartyd\counterpartyd.py", line 521, i
n
args.expiration, fee_required, fee_provided, unsigned=args.unsigned)
File "C:\counterpartyd_build\dist\counterpartyd\lib\order.py", line 47, in cre
ate
return bitcoin.transaction(source, None, None, fee_provided, data, unsigned=
unsigned)
File "C:\counterpartyd_build\dist\counterpartyd\lib\bitcoin.py", line 371, in
transaction
transaction = serialise(inputs, destination_output, data_output, change_outp
ut, multisig=multisig, source=source, unsigned=unsigned)
File "C:\counterpartyd_build\dist\counterpartyd\lib\bitcoin.py", line 217, in
serialise
secret_exponent, compressed = wif_to_tuple_of_secret_exponent_compressed(pri
vate_key_wif, is_test=testnet)
TypeError: wif_to_tuple_of_secret_exponent_compressed() got an unexpected keywor
d argument 'is_test'
Why
Code:
TypeError: wif_to_tuple_of_secret_exponent_compressed() got an unexpected keywor
d argument 'is_test'
d argument 'is_test'
You're running an old version of pycoin.
February 07, 2014, 06:21: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.
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?
The expire time of BTCpay is simply the lesser of the two expirations involved in the transaction.
Thanks. Then it is a little bit more difficult to punish the late buyers since the sellers can attack the buyers by setting a very short expire time.
One possible solution is maybe only the one who matches the existing orders needs to put some XCP in escrow. This could prevent someone eat up all sell orders without cost.
This solution, however, cannot prevent another kind of manipulation. Say current the lowest sell order is at 0.01. Then I can put a limit buy order 1M XCP @ 0.009999, so that I can ensure nobody can really sell to the bid walls.
It seems this kind of attack is arguably less harmful than a big buy orders to eat up all sell orders.
Let's think together to see whether there's better solution.
Moreover, even checking BTC bandwidth is doable, it cannot prevent the attack. Only put BTC in escrow can avoid this kind of attack completely.
February 07, 2014, 06:19:50 AM
[quote autforhor=520Bit link=topic=395761.msg4992441#msg4992441 date=1391764373]
You may want to check the tutorial and see how Counterpartyd works first. Remember to install the latest version.
https://bitcointalksearch.org/topic/m.4975462
[/quote]
Thank you for your considerable effort.
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.
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.
You may want to check the tutorial and see how Counterpartyd works first. Remember to install the latest version.
https://bitcointalksearch.org/topic/m.4975462
[/quote]
Thank you for your considerable effort.
February 07, 2014, 05:24:54 AM
Got this error when trying to do a simple send (run from source, vista x64)
Quote
Traceback (most recent call last):
File "C:\counterpartyd_build\dist\counterpartyd\counterpartyd.py", line 496, i
n
print(unsigned_tx_hex) if args.unsigned else json_print(bitcoin.transmit(uns
igned_tx_hex))
File "C:\counterpartyd_build\dist\counterpartyd\lib\bitcoin.py", line 382, in
transmit
if input('Confirm? (y/N) ') != 'y':
AttributeError: 'UnicodeOutput' object has no attribute 'errors'
File "C:\counterpartyd_build\dist\counterpartyd\counterpartyd.py", line 496, i
n
print(unsigned_tx_hex) if args.unsigned else json_print(bitcoin.transmit(uns
igned_tx_hex))
File "C:\counterpartyd_build\dist\counterpartyd\lib\bitcoin.py", line 382, in
transmit
if input('Confirm? (y/N) ') != 'y':
AttributeError: 'UnicodeOutput' object has no attribute 'errors'
Did you update to the latest version? https://github.com/xnova/counterpartyd_build
Yes, of course (and I got the same error as you when trying to make an order)
February 07, 2014, 05:23:56 AM
I have another error when I make an order:
How to fix the 'no attribute 'errors''?
My counterpartyd is up-to-date by the way.
Also posted here: https://forums.counterparty.co/index.php?topic=22.new#new
Code:
c:\counterpartyd_build>counterpartyd order --source 1XXX --get-quantity 20 --get-asset BTC --give-quantity 200 --give-asset XCP --expiration 5000 --fee_required 0.01
c:\counterpartyd_build>echo off
Transaction (unsigned): 010000000191bc9ad6c118669cb9ef0425310793357f2d42d7e27ad6c040908b1210ce22520200000000ffffffff036c2a0000000000006751410424e0d192e25d4eea9ef8ba4f32d45a025d0aa80172c45580762f3d417b
6eb804d8d7f3e1ee43863a165ae507bbf67b15bf137ed0d5072f1334e489cb6368c14d2120434e5452505254590000000a000000000000000100000004a817c8000000000052ae6c2a0000000000006751410424e0d192e25d4eea9ef8ba4f32d45a025d
0aa80172c45580762f3d417b6eb804d8d7f3e1ee43863a165ae507bbf67b15bf137ed0d5072f1334e489cb6368c14d2116000000000000000077359400138800000000000f42400000000000000000000052ae95847402000000001976a914779835a784
adb00b7cc20357da16ad282c6ff88588ac00000000
Traceback (most recent call last):
File "c:\counterpartyd_build\dist\counterpartyd\counterpartyd.py", line 522, in
print(unsigned_tx_hex) if args.unsigned else json_print(bitcoin.transmit(unsigned_tx_hex))
File "c:\counterpartyd_build\dist\counterpartyd\lib\bitcoin.py", line 382, in transmit
if input('Confirm? (y/N) ') != 'y':
AttributeError: 'UnicodeOutput' object has no attribute 'errors'
c:\counterpartyd_build>echo off
Transaction (unsigned): 010000000191bc9ad6c118669cb9ef0425310793357f2d42d7e27ad6c040908b1210ce22520200000000ffffffff036c2a0000000000006751410424e0d192e25d4eea9ef8ba4f32d45a025d0aa80172c45580762f3d417b
6eb804d8d7f3e1ee43863a165ae507bbf67b15bf137ed0d5072f1334e489cb6368c14d2120434e5452505254590000000a000000000000000100000004a817c8000000000052ae6c2a0000000000006751410424e0d192e25d4eea9ef8ba4f32d45a025d
0aa80172c45580762f3d417b6eb804d8d7f3e1ee43863a165ae507bbf67b15bf137ed0d5072f1334e489cb6368c14d2116000000000000000077359400138800000000000f42400000000000000000000052ae95847402000000001976a914779835a784
adb00b7cc20357da16ad282c6ff88588ac00000000
Traceback (most recent call last):
File "c:\counterpartyd_build\dist\counterpartyd\counterpartyd.py", line 522, in
print(unsigned_tx_hex) if args.unsigned else json_print(bitcoin.transmit(unsigned_tx_hex))
File "c:\counterpartyd_build\dist\counterpartyd\lib\bitcoin.py", line 382, in transmit
if input('Confirm? (y/N) ') != 'y':
AttributeError: 'UnicodeOutput' object has no attribute 'errors'
How to fix the 'no attribute 'errors''?
My counterpartyd is up-to-date by the way.
Also posted here: https://forums.counterparty.co/index.php?topic=22.new#new
February 07, 2014, 05:13:17 AM
Got this error when trying to do a simple send (run from source, vista x64)
Quote
Traceback (most recent call last):
File "C:\counterpartyd_build\dist\counterpartyd\counterpartyd.py", line 496, i
n
print(unsigned_tx_hex) if args.unsigned else json_print(bitcoin.transmit(uns
igned_tx_hex))
File "C:\counterpartyd_build\dist\counterpartyd\lib\bitcoin.py", line 382, in
transmit
if input('Confirm? (y/N) ') != 'y':
AttributeError: 'UnicodeOutput' object has no attribute 'errors'
File "C:\counterpartyd_build\dist\counterpartyd\counterpartyd.py", line 496, i
n
print(unsigned_tx_hex) if args.unsigned else json_print(bitcoin.transmit(uns
igned_tx_hex))
File "C:\counterpartyd_build\dist\counterpartyd\lib\bitcoin.py", line 382, in
transmit
if input('Confirm? (y/N) ') != 'y':
AttributeError: 'UnicodeOutput' object has no attribute 'errors'
Did you update to the latest version? https://github.com/xnova/counterpartyd_build
February 07, 2014, 05:06:39 AM
Got this error when trying to do a simple send (run from source, vista x64)
Quote
Traceback (most recent call last):
File "C:\counterpartyd_build\dist\counterpartyd\counterpartyd.py", line 496, i
n
print(unsigned_tx_hex) if args.unsigned else json_print(bitcoin.transmit(uns
igned_tx_hex))
File "C:\counterpartyd_build\dist\counterpartyd\lib\bitcoin.py", line 382, in
transmit
if input('Confirm? (y/N) ') != 'y':
AttributeError: 'UnicodeOutput' object has no attribute 'errors'
File "C:\counterpartyd_build\dist\counterpartyd\counterpartyd.py", line 496, i
n
print(unsigned_tx_hex) if args.unsigned else json_print(bitcoin.transmit(uns
igned_tx_hex))
File "C:\counterpartyd_build\dist\counterpartyd\lib\bitcoin.py", line 382, in
transmit
if input('Confirm? (y/N) ') != 'y':
AttributeError: 'UnicodeOutput' object has no attribute 'errors'
February 07, 2014, 04:12:53 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.
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.
You may want to check the tutorial and see how Counterpartyd works first. Remember to install the latest version.
https://bitcointalksearch.org/topic/m.4975462
February 07, 2014, 03:46:01 AM
Code:
C:\python32\python.exe C:\counterpartyd_build\run.py order --source=1Fxxxxxx........ --get-quantity=20 --get-asset=BTC --give-quantity=990 --give-asset=XCP --expiration=3000 --fee_required=.0001
then
Code:
Traceback (most recent call last):
File "C:\counterpartyd_build\dist\counterpartyd\counterpartyd.py", line 521, i
n
args.expiration, fee_required, fee_provided, unsigned=args.unsigned)
File "C:\counterpartyd_build\dist\counterpartyd\lib\order.py", line 47, in cre
ate
return bitcoin.transaction(source, None, None, fee_provided, data, unsigned=
unsigned)
File "C:\counterpartyd_build\dist\counterpartyd\lib\bitcoin.py", line 371, in
transaction
transaction = serialise(inputs, destination_output, data_output, change_outp
ut, multisig=multisig, source=source, unsigned=unsigned)
File "C:\counterpartyd_build\dist\counterpartyd\lib\bitcoin.py", line 217, in
serialise
secret_exponent, compressed = wif_to_tuple_of_secret_exponent_compressed(pri
vate_key_wif, is_test=testnet)
TypeError: wif_to_tuple_of_secret_exponent_compressed() got an unexpected keywor
d argument 'is_test'
File "C:\counterpartyd_build\dist\counterpartyd\counterpartyd.py", line 521, i
n
args.expiration, fee_required, fee_provided, unsigned=args.unsigned)
File "C:\counterpartyd_build\dist\counterpartyd\lib\order.py", line 47, in cre
ate
return bitcoin.transaction(source, None, None, fee_provided, data, unsigned=
unsigned)
File "C:\counterpartyd_build\dist\counterpartyd\lib\bitcoin.py", line 371, in
transaction
transaction = serialise(inputs, destination_output, data_output, change_outp
ut, multisig=multisig, source=source, unsigned=unsigned)
File "C:\counterpartyd_build\dist\counterpartyd\lib\bitcoin.py", line 217, in
serialise
secret_exponent, compressed = wif_to_tuple_of_secret_exponent_compressed(pri
vate_key_wif, is_test=testnet)
TypeError: wif_to_tuple_of_secret_exponent_compressed() got an unexpected keywor
d argument 'is_test'
Why
Code:
TypeError: wif_to_tuple_of_secret_exponent_compressed() got an unexpected keywor
d argument 'is_test'
d argument 'is_test'
February 07, 2014, 03:06:36 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.
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?
I think attempting to solve all issues directly with the protocol would be challenging so early on. However using some of the suggestions stated earlier certain checks can be placed to prevent 'obvious' abuse / trolling issues like the buyer eating up all btc orders with little to no cost.
As for the notification when a btcpay is due, some form of client side notification could be developed. Once the GUI clients are out and the information becomes more accessible issues like these become more manageable. There also can be perhaps a minimum allowance limit time limit to allow the buyer to make the payment before the escrow is forfeited in case the expiration period is too short
Cheers
February 07, 2014, 03:05:31 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.
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?
The expire time of BTCpay is simply the lesser of the two expirations involved in the transaction.
February 07, 2014, 01: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.
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.
February 07, 2014, 01:14:08 AM
After i put an order i get this:
Code:
raise exceptions.BitcoindError('{}'.format(response_json['error']))
lib.exceptions.BitcoindError: {'code': -22, 'message': 'TX rejected'}https://counterparty.co/faqs/i-got-an-error-tx-rejected-code-22-what-is-that/
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
February 06, 2014, 11:44:21 PM
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://bitcointalksearch.org/topic/m.4988118
February 06, 2014, 11:40:40 PM
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.
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?
February 06, 2014, 11:10:52 PM
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.
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.
February 06, 2014, 11:05:07 PM
Quote
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
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.
February 06, 2014, 11:00:28 PM
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.Malicious people can match any XCP sell orders with a tiny cost now. Those eaten orders have to wait until the matches expire.
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.
Jump to: