Author

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

sr. member
Activity: 476
Merit: 300
Counterparty Chief Scientist and Co-Founder
I don't think my XCP balance is correct:

http://blockscan.com/address.aspx?q=1QBPsB2ea61vWTNA9nGUhaHqPQB4SXF4fN

Currently both blockscan.com and my local client (v0.4.1 master branch on Ubuntu 13.10) show a balance of 1348.19 XCP.

But this balance doesn't make sense just looking through transaction history:

1340.43 total earned through proof-of-burn.

+1 from winning Super Bowl Bet.

Sold a few XCP, other orders have all expired or been cancelled.

This implies my balance should be at most ~1341. Where did the additional 7 XCP come from?

My suspicion is I got credited extra XCP somehow through the order expiration process.

Here are the credits and debits to and from that address (and your balance) in the DB:

Code:
INSERT INTO "debits" VALUES(283702,'1QBPsB2ea61vWTNA9nGUhaHqPQB4SXF4fN','XCP',100000000,'bet.parse',NULL);
INSERT INTO "debits" VALUES(283702,'1QBPsB2ea61vWTNA9nGUhaHqPQB4SXF4fN','XCP',0,'bet.parse',NULL);
INSERT INTO "debits" VALUES(284563,'1QBPsB2ea61vWTNA9nGUhaHqPQB4SXF4fN','XCP',100000000000,'order.parse','dff0ebf6a01460daa8e085fe7350940415cf255eccc9c6c711d694dd0c36b313');
INSERT INTO "debits" VALUES(284671,'1QBPsB2ea61vWTNA9nGUhaHqPQB4SXF4fN','XCP',30100000000,'order.parse','9ce90757c8f8d9c0c3cffb429d01c737cac39ccfc630d783e8812b468c01e76c');
INSERT INTO "debits" VALUES(284849,'1QBPsB2ea61vWTNA9nGUhaHqPQB4SXF4fN','XCP',25010000000,'order.parse','53587a17f03ea59fd559142f43d121b9cdaff846deaaee031e81b1b4c706e688');
INSERT INTO "debits" VALUES(284871,'1QBPsB2ea61vWTNA9nGUhaHqPQB4SXF4fN','XCP',8200000000,'order.parse','8eb9068fe42bb39c42858fbb7e769d31a90c446444808fc3f569a409cf1884e6');
INSERT INTO "debits" VALUES(284873,'1QBPsB2ea61vWTNA9nGUhaHqPQB4SXF4fN','XCP',8300000000,'order.parse','881dcd368821681f43840e0e0f941208884fc2e915d215b00ad726b1b9f88622');
INSERT INTO "credits" VALUES(279448,'1QBPsB2ea61vWTNA9nGUhaHqPQB4SXF4fN','XCP',1396545455,'burn.parse','d7f83a15b2a01a18825f47e514f81bccb5fd1a43713bad720c509724f204e5cf');
INSERT INTO "credits" VALUES(279451,'1QBPsB2ea61vWTNA9nGUhaHqPQB4SXF4fN','XCP',57544533454,'burn.parse','709b19c683cf6b02124ad716c5c12907ba0070a36098ed9ac90bb6a1d011f4b5');
INSERT INTO "credits" VALUES(279529,'1QBPsB2ea61vWTNA9nGUhaHqPQB4SXF4fN','XCP',47218290000,'burn.parse','065259687185302f2503d83b990d1313892e490edc1a04550c4a397471845d3c');
INSERT INTO "credits" VALUES(279781,'1QBPsB2ea61vWTNA9nGUhaHqPQB4SXF4fN','XCP',8632749140,'burn.parse','cf6398d3e800fb5f6043eb93703ec8c66b01cad9db7b2c2a0eb2775e64e9cbce');
INSERT INTO "credits" VALUES(280562,'1QBPsB2ea61vWTNA9nGUhaHqPQB4SXF4fN','XCP',12960518338,'burn.parse','2a38b1ec751f14722516b934a358d9454bf4aa34cc94da5f33bb033ef8b85699');
INSERT INTO "credits" VALUES(281000,'1QBPsB2ea61vWTNA9nGUhaHqPQB4SXF4fN','XCP',6289257296,'burn.parse','12e7ce6273a1823ad9fb4f09565e8eb3c220bf67237a07b7748bc16a98bce4b2');
INSERT INTO "credits" VALUES(283713,'1QBPsB2ea61vWTNA9nGUhaHqPQB4SXF4fN','XCP',0,'bet.expire',NULL);
INSERT INTO "credits" VALUES(284054,'1QBPsB2ea61vWTNA9nGUhaHqPQB4SXF4fN','XCP',200000000,'broadcast.parse',NULL);
INSERT INTO "credits" VALUES(284054,'1QBPsB2ea61vWTNA9nGUhaHqPQB4SXF4fN','XCP',0,'broadcast.parse',NULL);
INSERT INTO "credits" VALUES(284567,'1QBPsB2ea61vWTNA9nGUhaHqPQB4SXF4fN','XCP',100000000000,'cancel.parse',NULL);
INSERT INTO "credits" VALUES(284772,'1QBPsB2ea61vWTNA9nGUhaHqPQB4SXF4fN','XCP',927272635,'order.expire','80bf54654df947a346df88a8961740159c08e2bed2834c277d1bb7d6d98e0f3c9ce90757c8f8d9c0c3cffb429d01c737cac39ccfc630d783e8812b468c01e76c');
INSERT INTO "credits" VALUES(284972,'1QBPsB2ea61vWTNA9nGUhaHqPQB4SXF4fN','XCP',29949500151,'order.expire','9ce90757c8f8d9c0c3cffb429d01c737cac39ccfc630d783e8812b468c01e76c');
INSERT INTO "credits" VALUES(284972,'1QBPsB2ea61vWTNA9nGUhaHqPQB4SXF4fN','XCP',1,'order.expire','8eb9068fe42bb39c42858fbb7e769d31a90c446444808fc3f569a409cf1884e6');
INSERT INTO "credits" VALUES(284972,'1QBPsB2ea61vWTNA9nGUhaHqPQB4SXF4fN','XCP',8199999999,'order.expire','8eb9068fe42bb39c42858fbb7e769d31a90c446444808fc3f569a409cf1884e6bc8ac78ca1f7d8b6a2d63bcd5fee09e6ece10f7f45eb44209fc580c13d764cae');
INSERT INTO "credits" VALUES(285024,'1QBPsB2ea61vWTNA9nGUhaHqPQB4SXF4fN','XCP',8300000000,'order.expire','881dcd368821681f43840e0e0f941208884fc2e915d215b00ad726b1b9f88622');
INSERT INTO "credits" VALUES(285050,'1QBPsB2ea61vWTNA9nGUhaHqPQB4SXF4fN','XCP',0,'order.expire','53587a17f03ea59fd559142f43d121b9cdaff846deaaee031e81b1b4c706e688');
INSERT INTO "credits" VALUES(285050,'1QBPsB2ea61vWTNA9nGUhaHqPQB4SXF4fN','XCP',24909999833,'order.expire','53587a17f03ea59fd559142f43d121b9cdaff846deaaee031e81b1b4c706e6886efab911ef0b392cced9a410f610380783356f3172b6ee724e9c5175e21e8a7d');
INSERT INTO "balances" VALUES('1QBPsB2ea61vWTNA9nGUhaHqPQB4SXF4fN','XCP',134818666302);
.

Check out the sum(expired order credits) - sum(sent order debits). It's a positive number, ~6 XCP to be precise. That number should always be <= 0.  You should never receive more credits back from expired orders than the debits from sending them.

The first order to sell 1000 XCP was cancelled properly with all funds credited back.

Here are the rest of the orders:
VALUES(284671,'1QBPsB2ea61vWTNA9nGUhaHqPQB4SXF4fN','XCP',30100000000,'order.parse','9ce90757c8f8d9c0c3cffb429d01c737cac39ccfc630d783e8812b468c01e76c');
INSERT INTO "debits" VALUES(284849,'1QBPsB2ea61vWTNA9nGUhaHqPQB4SXF4fN','XCP',25010000000,'order.parse','53587a17f03ea59fd559142f43d121b9cdaff846deaaee031e81b1b4c706e688');
INSERT INTO "debits" VALUES(284871,'1QBPsB2ea61vWTNA9nGUhaHqPQB4SXF4fN','XCP',8200000000,'order.parse','8eb9068fe42bb39c42858fbb7e769d31a90c446444808fc3f569a409cf1884e6');
INSERT INTO "debits" VALUES(284873,'1QBPsB2ea61vWTNA9nGUhaHqPQB4SXF4fN','XCP',8300000000,'order.parse','881dcd368821681f43840e0e0f941208884fc2e915d215b00ad726b1b9f88622');

Total = 716.1 XCP debited from orders to sell.

Here are the order expire credits:
VALUES(284772,'1QBPsB2ea61vWTNA9nGUhaHqPQB4SXF4fN','XCP',927272635,'order.expire','80bf54654df947a346df88a8961740159c08e2bed2834c277d1bb7d6d98e0f3c9ce90757c8f8d9c 0c3cffb429d01c737cac39ccfc630d783e8812b468c01e76c');
INSERT INTO "credits" VALUES(284972,'1QBPsB2ea61vWTNA9nGUhaHqPQB4SXF4fN','XCP',29949500151,'order.expire','9ce90757c8f8d9c0c3cffb429d01c737cac39ccfc630d783e8812b468c01e76c');
INSERT INTO "credits" VALUES(284972,'1QBPsB2ea61vWTNA9nGUhaHqPQB4SXF4fN','XCP',1,'order.expire','8eb9068fe42bb39c42858fbb7e769d31a90c446444808fc3f569a409cf1884e6');
INSERT INTO "credits" VALUES(284972,'1QBPsB2ea61vWTNA9nGUhaHqPQB4SXF4fN','XCP',8199999999,'order.expire','8eb9068fe42bb39c42858fbb7e769d31a90c446444808fc3f569a409cf1884e6bc8ac78ca1f7d8b 6a2d63bcd5fee09e6ece10f7f45eb44209fc580c13d764cae');
INSERT INTO "credits" VALUES(285024,'1QBPsB2ea61vWTNA9nGUhaHqPQB4SXF4fN','XCP',8300000000,'order.expire','881dcd368821681f43840e0e0f941208884fc2e915d215b00ad726b1b9f88622');
INSERT INTO "credits" VALUES(285050,'1QBPsB2ea61vWTNA9nGUhaHqPQB4SXF4fN','XCP',0,'order.expire','53587a17f03ea59fd559142f43d121b9cdaff846deaaee031e81b1b4c706e688');
INSERT INTO "credits" VALUES(285050,'1QBPsB2ea61vWTNA9nGUhaHqPQB4SXF4fN','XCP',24909999833,'order.expire','53587a17f03ea59fd559142f43d121b9cdaff846deaaee031e81b1b4c706e6886efab911ef0b392 cced9a410f610380783356f3172b6ee724e9c5175e21e8a7d');

Total = 722.85 XCP credited.


Digging a bit deeper I think I've narrowed down the issue to this order:
http://blockscan.com/order.aspx?q=3390

I tried to sell 301 XCP for 2 BTC.

There were 2 matches:
http://blockscan.com/order_match.aspx?q=3390

The match for 1.5 XCP was paid. The match for 9.27 XCP was not paid.

I should have received 301-1.5 = 299.5 XCP after expiration, which was received here:
VALUES(284972,'1QBPsB2ea61vWTNA9nGUhaHqPQB4SXF4fN','XCP',29949500151,'order.expire','9ce90757c8f8d9c0c3cffb429d01c737cac39ccfc630d783e8812b468c01e76c');

However, I also received an additional 9.27 XCP, which I should not have received:
VALUES(284772,'1QBPsB2ea61vWTNA9nGUhaHqPQB4SXF4fN','XCP',927272635,'order.expire','80bf54654df947a346df88a8961740159c08e2bed2834c277d1bb7d6d98e0f3c9ce90757c8f8d9c 0c3cffb429d01c737cac39ccfc630d783e8812b468c01e76c');

So I think the bug has to do with order expirations credited the amount of all expired order amounts regardless of match. In additional matched-but-unpaid orders also credit the XCP seller. This leads to a double-credit.


There might be a parallel issue with order cancels crediting back all unpaid cancelled amounts, and in addition matched-but-unpaid orders getting credited as well. I will test this after patch has been released.

I think that I have fixed this issue (and the bad credit for 9.27 XCP doesn't show up anymore). Now, when an order match expires, if each underlying order is still valid, that order goes back on the books with replenished give_remaining and get_remaining, and only otherwise (if the order is expired) is its source credited immediately.

Attention: balances are now slightly different in develop. (A few people were getting extra XCP with order match cancellations.)

EDIT: Change also pushed to master.
hero member
Activity: 588
Merit: 504
Is there an official XCP coin graphic that we can send to poloniex, all the other coins have graphics on front page of https://www.poloniex.com/

XCP is already on the pending orders page there!
Seems like very soon we can trade XCP on normal exchange

coinmarketcap here we come!

To speed up this matter, perhaps any of the below can be temporary used:
http://take.ms/BASGm

(These are some initial logo mock-ups we did for XCP some time ago - they are not officially endorsed by XCP team in any way).

I tried quick coin icons too now,welcome to use temporarily until graphic designer turn up
https://i.imgur.com/jjYtoEg.jpg
i much prefer till now the plain style logos though, like diagonal stripe above black/white
hero member
Activity: 756
Merit: 502
Is there an official XCP coin graphic that we can send to poloniex, all the other coins have graphics on front page of https://www.poloniex.com/

XCP is already on the pending orders page there!
Seems like very soon we can trade XCP on normal exchange

coinmarketcap here we come!

To speed up this matter, perhaps any of the below can be temporary used:
http://take.ms/BASGm

(These are some initial logo mock-ups we did for XCP some time ago - they are not officially endorsed by XCP team in any way).
legendary
Activity: 876
Merit: 1000
Etherscan.io
I'm using the API.

I added db.setbusytimeout(10000) to util.py, when the database connection is allocated, and that seems to have fixed it. I'm going to let it run overnight, we'll see if it's still alive in the morning.

If you are constantly polling the database either directly or via api, I think you will run into these issues ? If I understand correctly you are doing this for checking the balances?

sr. member
Activity: 364
Merit: 250
Owner of Poloniex
I'm using the API.

I added db.setbusytimeout(10000) to util.py, when the database connection is allocated, and that seems to have fixed it. I'm going to let it run overnight, we'll see if it's still alive in the morning.
legendary
Activity: 876
Merit: 1000
Etherscan.io
All right, the deposit/withdrawal daemon is working. Everything would be ready to go, but...

Traceback (most recent call last):
  File "/home//counterpartyd_build/dist/counterpartyd/counterpartyd.py", line 687, in
    blocks.follow(db)
  File "/home//counterpartyd_build/dist/counterpartyd/lib/blocks.py", line 651, in follow
    parse_block(db, block_index, block_time)
apsw.BusyError: BusyError: database is locked

Counterpartyd is now quitting with that error whenever I run the daemon. The daemon makes a zillion database accesses, it has to check everyone single user's balance. It's during that phase that this is now happening.

Had the same issue when I was building blockscan.com initially.... But its an easy fix actually. I assume you are directly reading from the counterparty db and not using the API ?
sr. member
Activity: 364
Merit: 250
Owner of Poloniex
Okay, now counterpartyd is throwing that error after about thirty seconds when I just start it up and do nothing. It does a little syncing sometimes first.
sr. member
Activity: 364
Merit: 250
Owner of Poloniex
All right, the deposit/withdrawal daemon is working. Everything would be ready to go, but...

Traceback (most recent call last):
  File "/home//counterpartyd_build/dist/counterpartyd/counterpartyd.py", line 687, in
    blocks.follow(db)
  File "/home//counterpartyd_build/dist/counterpartyd/lib/blocks.py", line 651, in follow
    parse_block(db, block_index, block_time)
apsw.BusyError: BusyError: database is locked

Counterpartyd is now quitting with that error whenever I run the daemon. The daemon makes a zillion database accesses, it has to check everyone single user's balance. It's during that phase that this is now happening.
legendary
Activity: 882
Merit: 1000
As far as I understand, the wallet isn't a protocol but a client side construction - and the protocol only recognizes as XCP as being held by such and such address, it is not aware of what other addresses may or may not be in the wallet.

But we're not talking about XCP. The address has XCP. I'm talking about the BTC needed to fund the XCP transaction. Address has 1 XCP, 0.0001 BTC. To send, for some reason you need 0.0003 BTC, even though that much is not consumed.

A simple answer is that counterparty protocol does not allow multiple inputs, therefore it requires all the inputs come from the address where you have XCP.

Moreover, counterpartyd does not know about the existence of the wallet. Wallet is not in the bitcoin protocol and is completely in the BTC client implementation.
legendary
Activity: 1176
Merit: 1134
Is there an official XCP coin graphic that we can send to poloniex, all the other coins have graphics on front page of https://www.poloniex.com/

XCP is already on the pending orders page there!
Seems like very soon we can trade XCP on normal exchange

coinmarketcap here we come!
full member
Activity: 238
Merit: 100
Maybe someone could give some input on this

Is XCP cinsdered a distributed autonomous corporation and if so how is it compared to Bitshares?
XCP and Bitshares share the same goals(Assets/Colored Coins, Distributed Exchange etc...) . But have different approaches to achieving them.
The main difference is XCP has a working product right now. While Bitshares is still raising funds for their development/marketing effort.
hero member
Activity: 714
Merit: 502
The only thing I can think of is that Counterparty sends BTC from a specific address to another, and uses the origin and destination of the BTC to determine the origin and destination of the XCP. I don't really see the need for that, but if that's how it works, I guess there isn't a way around it.

Space in the bitcoin blockchain is a scarce (and expensive) resource.

By reusing the BTC send address as the XCP send address, you get the following for free:
* the send address already being part of the transaction
* the proof that the sender "owns" the XCP send address (by bitcoin-validated scriptSig containing ECDSA signature)

That's sort of a big deal. If you want to use separate addresses for XCP, embedded as metadata in bitcoin transactions (which currently relies in the CHECKMULTISIG trick, the "expense" of which a bunch of people have been complaining about lately)... then you also need to embed a signature scheme for proving ownership of your XCP addresses and can't just rely on bitcoin's heavily battle tested one for free.

That's a LOT of extra data to be trying to stuff into bitcoin transactions. It'd contribute significantly to blockchain bloat, and would cost you a lot more in fees because of the unnecessarily large size (in kBs) of each transaction (and if it wouldn't, it certainly ought to.)

On top of that, the security of your XCP transactions would now be highly questionable.

I imagine that would be why the devs have designed counterparty the way it is :-)
(Incidentally, you'll notice most other coloured-coin schemes out there do something similar.)



+1 Good explanation and improves me understanding a little bit more.

Only other point to add is that we are also eagerly waiting 0.9 Bitcoin wallet so that we can start using OP_RETURN. This is supposed to simply the process and cost. I don't completely understand how but I am sure you have a succinct explanation Smiley




0.9 BitcoinQT is being tested at the moment, it would be a good idea for the counterparty community to get involved with this, scroll down to the bottom of this link for details: https://bitcoinfoundation.org/blog/?p=290
sr. member
Activity: 364
Merit: 250
Owner of Poloniex
Yes, that explanation clears thing up. Thank you.
full member
Activity: 196
Merit: 100
The only thing I can think of is that Counterparty sends BTC from a specific address to another, and uses the origin and destination of the BTC to determine the origin and destination of the XCP. I don't really see the need for that, but if that's how it works, I guess there isn't a way around it.

Space in the bitcoin blockchain is a scarce (and expensive) resource.

By reusing the BTC send address as the XCP send address, you get the following for free:
* the send address already being part of the transaction
* the proof that the sender "owns" the XCP send address (by bitcoin-validated scriptSig containing ECDSA signature)

That's sort of a big deal. If you want to use separate addresses for XCP, embedded as metadata in bitcoin transactions (which currently relies in the CHECKMULTISIG trick, the "expense" of which a bunch of people have been complaining about lately)... then you also need to embed a signature scheme for proving ownership of your XCP addresses and can't just rely on bitcoin's heavily battle tested one for free.

That's a LOT of extra data to be trying to stuff into bitcoin transactions. It'd contribute significantly to blockchain bloat, and would cost you a lot more in fees because of the unnecessarily large size (in kBs) of each transaction (and if it wouldn't, it certainly ought to.)

On top of that, the security of your XCP transactions would now be highly questionable.

I imagine that would be why the devs have designed counterparty the way it is :-)
(Incidentally, you'll notice most other coloured-coin schemes out there do something similar.)



+1 Good explanation and improves me understanding a little bit more.

Only other point to add is that we are also eagerly waiting 0.9 Bitcoin wallet so that we can start using OP_RETURN. This is supposed to simply the process and cost. I don't completely understand how but I am sure you have a succinct explanation Smiley


sr. member
Activity: 421
Merit: 250
Maybe someone could give some input on this

Is XCP cinsdered a distributed autonomous corporation and if so how is it compared to Bitshares?
newbie
Activity: 22
Merit: 0
The only thing I can think of is that Counterparty sends BTC from a specific address to another, and uses the origin and destination of the BTC to determine the origin and destination of the XCP. I don't really see the need for that, but if that's how it works, I guess there isn't a way around it.

Space in the bitcoin blockchain is a scarce (and expensive) resource.

By reusing the BTC send address as the XCP send address, you get the following for free:
* the send address already being part of the transaction
* the proof that the sender "owns" the XCP send address (by bitcoin-validated scriptSig containing ECDSA signature)

That's sort of a big deal. If you want to use separate addresses for XCP, embedded as metadata in bitcoin transactions (which currently relies in the CHECKMULTISIG trick, the "expense" of which a bunch of people have been complaining about lately)... then you also need to embed a signature scheme for proving ownership of your XCP addresses and can't just rely on bitcoin's heavily battle tested one for free.

That's a LOT of extra data to be trying to stuff into bitcoin transactions. It'd contribute significantly to blockchain bloat, and would cost you a lot more in fees because of the unnecessarily large size (in kBs) of each transaction (and if it wouldn't, it certainly ought to.)

On top of that, the security of your XCP transactions would now be highly questionable.

I imagine that would be why the devs have designed counterparty the way it is :-)
(Incidentally, you'll notice most other coloured-coin schemes out there do something similar.)

sr. member
Activity: 364
Merit: 250
Owner of Poloniex
It's not the withdrawals, it's the deposits. The exchange's XCP (or a sufficient portion to cover everyone's withdrawals) has to be in one place.

At any rate, I just finished writing some crazy bit of code to move all the BTC and XCP around. I think I'll just charge a withdrawal fee in XCP, since people are used to withdrawal fees.

Pending tests on BTC's slow block chain, everything should be about ready.
legendary
Activity: 1176
Merit: 1134
As far as I understand, the wallet isn't a protocol but a client side construction - and the protocol only recognizes as XCP as being held by such and such address, it is not aware of what other addresses may or may not be in the wallet.

But we're not talking about XCP. The address has XCP. I'm talking about the BTC needed to fund the XCP transaction. Address has 1 XCP, 0.0001 BTC. To send, for some reason you need 0.0003 BTC, even though that much is not consumed.
I am not sure, but I think currently .0003 or even a bit more is needed during the process, but after all the dust settles, it is net cost of .0001 BTC

I dont think anybody that is going to be trading XCP will be bothered by the requirement of having at least .0003 or even .001 BTC in their acct to be able to do a withdraw.
sr. member
Activity: 364
Merit: 250
Owner of Poloniex
As far as I understand, the wallet isn't a protocol but a client side construction - and the protocol only recognizes as XCP as being held by such and such address, it is not aware of what other addresses may or may not be in the wallet.

But we're not talking about XCP. The address has XCP. I'm talking about the BTC needed to fund the XCP transaction. Address has 1 XCP, 0.0001 BTC. To send, for some reason you need 0.0003 BTC, even though that much is not consumed.
sr. member
Activity: 364
Merit: 250
Owner of Poloniex
what is the status with Poloniex? still alive?

Actually very close to listing XCP.

Counterparty-savvy people, I have a question. When I attempt to send XCP from one address to another, it tells me there are insufficient Bitcoins at the source address. The thing is, the wallet that contains the source address has plenty of BTC, even if not enough were sent to that PARTICULAR address.

Please tell me I don't have to send a tiny bit of BTC to every address I want to send XCP from. This makes a big difference.
You need a small amount of BTC in that address, to pay the miner fees.
Unfortunately, it is a limitation at this point. The developers or more technical members of the forum can provide further details.

The wallet has BTC to pay whatever fees are needed...

The only thing I can think of is that Counterparty sends BTC from a specific address to another, and uses the origin and destination of the BTC to determine the origin and destination of the XCP. I don't really see the need for that, but if that's how it works, I guess there isn't a way around it.

Things just got more difficult for traders.
Jump to: