I ran it with fake data, but it still seems there, although a lot better. SELECT
txid,
b_r AS b_rate,
a_r AS a_rate,
r AS rate,
r - a_r AS diff,
b_r > a_r,
r > a_r,
r < b_r
I don't understand what you're doing here. Is this regarding point 3) in my path, and the precision of prices? Which table are you selecting from? I don't see any b_r in the database schema at all. |
|
|
|
$our->amount >= $them->amount * $them->initial_want_amount / $them->initial_amount Which is the same as that end result above  Exactly. Basically, it's: how_much_we_now_have >= how_much_they_can_now_afford_at_the_price_they_originally_set |
|
|
|
As a comment for 1) I should have written something like this: We're trading at 'their' price, which is determined by:
$them->initial_want_amount
and
$them->initial_amount
We have
$our->amount
and they have
$them->amount
To determine who 'swamps' who, we check whether:
$our->amount / $them->amount
is greater or less than
$them->initial_want_amount / $them->initial_amount.
Multiply both sides by $them->initial_amount and $them->amount
shows that it's the same as checking whether:
$our->amount * $them->initial_amount
is greater or less than
$them->initial_want_amount * $them->amount
That should help in understanding the change. Add it to the code if you like. For 2), you're right - once we stop using the 'want' fields to make the trades, it's just a display thing. It's mostly not a problem for long on the site, since the leftover order is usually quickly matched, but sometimes they stick around. Here's one:  For 3), it was a problem with how MySQL defaults to only using 4 decimal places of precision when dividing. See this example:
mysql> select 1/3;
+--------+
| 1/3 |
+--------+
| 0.3333 |
+--------+
1 row in set (0.00 sec)
mysql> SET div_precision_increment = 8;
Query OK, 0 rows affected (0.02 sec)
mysql> select 1/3;
+------------+
| 1/3 |
+------------+
| 0.33333333 |
+------------+
1 row in set (0.00 sec)
To fix it, I set div_precision_increment to 8 instead of 4, and make sure that the division has the bigger number on top, here: if ($our->initial_amount > $our->initial_want_amount)
$order_by = "initial_want_amount / initial_amount ASC";
else
$order_by = "initial_amount / initial_want_amount DESC";
Hope that helps! |
|
|
|
|
Is it 0% commission? If so, that may be worth mentioning, since the competition isn't.
|
|
|
|
Anyway, I'm looking at this myself over the next few days. It's not as simple as just merging your fix, since I really need to go through everything with a fine toothed comb, run test suites and make sure the algorithm is fully understood. Although from the previous work we paid you for, your patches were good.
I can split my patch into smaller separate patches if that helps the process. I renamed the parameters of the 'pacman' function because they were really counter-intuitive as they were, and that's in the same patch that stops the "want" fields from being used to determine prices. |
|
|
|
This one should be easy to find in the database. It's the most recent trade: Mon Jul 18 13:19:01 2011 7.571500 7.954886
Mon Jul 18 13:21:02 2011 7.518800 3.990000
Mon Jul 18 13:25:01 2011 7.530900 10.286550
Mon Jul 18 13:32:01 2011 1.533500 0.045114
The orderbook has plenty of people willing to buy around the 7 to 8 GBP price:  but the price crashed down to 1.5 GBP:  Is anyone working on fixing this bug? |
|
|
|
|
Seems to me that the bitcoin network is doing integer operations, not floating point. So what's the relevance of FLOPS?
|
|
|
|
And of course, if the blocks continue to be found more frequently than every 10 minutes, that halving will be brought even further forward. Here's the calculation if the average block finding rate continues: >>> block=136943; time.ctime(time.time() + (210000 - block)*60*((time.time() - time.mktime((2009,1,9,02,54,25,0,0,0))) / block / 60))
'Tue Nov 20 12:45:31 2012'
blocks 136939 through 136943 (5 blocks) were found in the last 8 minutes! |
|
|
|
Not next year, it's 2013
We're currently on block 136938. Block reward halves after block 210000. New blocks happen about once every 10 minutes. >>> time.ctime(time.time() + (210000 - 136938)*60*10)
'Thu Dec 6 21:12:24 2012'
At that rate, we can expect the first halving in December 2012. This makes sense because the difficulty lags behind the network speed, and so blocks have been generated a little more quickly than every 10 minutes, meaning the reward will halve to 25 BTC in a little less than 4 years from 9-Jan-2009 (the date block 1 was found). >>> (time.time() - time.mktime((2009,1,9,02,54,25,0,0,0))) / 136938 / 60
9.678566721912704
The average time between blocks so far has been 9.7 minutes, not 10 minutes. |
|
|
|
Yea i see that too and that block was 3 hours ago, right? I mean is this normal behavior, because there should be 6 blocks per hour normally if i'm correct, and this would be a major statistical unlikeliness, something like 0,00001% chance for this to happen.
The gap between blocks was around 59 minutes. Not sure where you're getting 3 hours from. |
|
|
|
And true to form Britcoin continue to ignore the problem, and say it doesn't exist
I don't think I've ever seen them say it doesn't exist. But I don't think I've seen them acknowledge it, either. This seems weird, since there so clearly is a problem. Here's an example from less than 24 hours ago - it's still showing up in the API right now: Fri Jul 15 01:32:02 2011 8.865600 5.060000
Fri Jul 15 01:32:02 2011 8.870000 0.100000
Fri Jul 15 01:52:01 2011 13.517500 0.014591
Fri Jul 15 01:58:01 2011 8.896900 0.500000
Fri Jul 15 01:59:01 2011 8.896900 3.878000
It's a one bitcent trade. Are we to believe it moved the market price from 8.8 to 13.5? Here's the same trade on bitcoincharts:  |
|
|
|
In the INSTALL file of the intersango sources, it says: ln -s /path/to/this/dir/www www
but it should say ln -s /path/to/this/dir/htdocs www
|
|
|
|
There are/were two separate issues. It used to be that new orders were being matched with existing orders at the price specified in the new order. So if there was an existing offer to sell me bitcoins for 10 GBP each and I asked to buy some at 5000 GBP each, I would be charged 5000 GBP for them, rather than 10 GBP each. I made a patch for this and it was applied around the 26th or 27th of June: June 26, 2011, 06:08:15 am Merged dooglus's gitorious branch after testing it today.  June 27, 2011, 04:45:06 am yep, it was done a little afterwards since phantom forgot to do it.
After that, new orders were initially matched at the price specified by existing orders, but if they were only partially matched, the "I have" and "I want" fields were updated by subtracting the amounts that were bought and sold by the initial trade. This leaves undesirable implied prices in the order, as I described in my recent post: This is how very high priced trades happen:
User A has 5 BTC and wants 45 GBP (selling 5 BTC at 9 GBP/BTC)
User B has 51 GBP and wants 5.1 BTC (buying 5.1 BTC at 10 GBP/BTC)
User A's order goes in first, and is unmatched.
User B's order goes in 2nd, and is partially matched at User A's rate of 9 GBP/BTC.
User B gives 45 GBP to user A and gets 5 BTC in exchange.
User B now has 6 GBP and the 'wants' value is updated to 0.1 BTC.
User C can now come along and sell 0.1 BTC to User B for 6 GBP, at a price of 60 GBP/BTC even though the market price is in the range of 9 or 10 GBP/BTC.
Note that overall, User B gets 5+0.1=5.1 BTC for his 45+6=51 GBP, and so actually gets the price he was expecting to. It's just that some was better than expected (5 bought from A for 9 GBP each) and some was much worse than expected (0.1 bought from C for 60 GBP each).
Genjix claims that this "want" field isn't used, but it still is being used, and is the cause of this problem: June 26, 2011, 12:58:18 pm You're right, we do ignore the want field. It's mostly left for display and is kind of redundant. It's not even needed.
Now phantomcircuit asks for a 'specific order' showing the problem. It's hard to give specific details, since we don't have access to the britcoin database. All we can see are the trades that are published through the API: Can you point me to a specific order in which the order was filled at a price neither party requested?
In the past the problem has been people putting in orders that were a terrible deal for themselves and them going through.
This "in the past" problem is the one that I fixed in my first patch, applied on June 26th or 27th. But bad trades have been happening since then to a lesser extent. Here's one:  I mentioned it in this post, and provided a fix: Did anyone notice the recent trade at 45 pence per BTC? Fri Jul 1 10:21:01 2011 9.889100 2.214555
Fri Jul 1 10:49:01 2011 9.889100 5.423131
Fri Jul 1 11:19:01 2011 9.881400 1.000000
Fri Jul 1 12:00:01 2011 0.446300 0.007894
Fri Jul 1 12:26:01 2011 10.000000 10.000000
Fri Jul 1 12:31:02 2011 10.000000 3.000000
Fri Jul 1 12:31:02 2011 10.000000 2.000000
I think this was caused by the code still using the updated want_amount database field. I committed a fix for this a few days ago and mailed Genjix. The fix is here if anyone could look it over for me: https://gitorious.org/~dooglus/intersango/dooglus-intersango/commit/126d05d8f23a2745da8db65fb57414eca607d0d8I don't have a copy of the orderbook at the time, but I really think it is unlikely that no buy orders were in the book for anything above 0.45 GBP when the price was around 10 GBP/BTC at the time. |
|
|
|
I've seen it. Do you have any comment on my post immediately previous to yours? Do you accept that orders are being matched at prices neither party requested? |
|
|
|
Nothing is wrong with BritCoin itself, but there must be SOMETHING wrong when it is reporting that a sale was made where somebody paid 10,000 pound for a BitCoin, I am certain that sale never went through or was for a small amount of BitCoins, it shouldn't have even got matched in the first place!
All the erroneous data needs to be cleaned out, when you look at BitCoin Charts and display the last 60 days' activity for BritCoin its all skewered because of this rubbish data!
No, they really happen; I had one myself (not at that crazy rate though). Their software is buggy; user beware! Unfortunately if you point out this bug to Britcoin they fob you off. Their software is buggy and I've offered a fix for it several times now. The problem is that decisions are made based on how much you are still wanting, rather than the original price you requested. Genjix has claimed that the 'want' field isn't actually used any more: You're right, we do ignore the want field. It's mostly left for display and is kind of redundant. It's not even needed.
but I think he's mistaken. The 'want' field is still used, and is exactly what's causing the problem. Here are some examples that show how very low and very high priced trades happen:
This is how very low priced trades happen:User A has 50 GBP and wants 5 BTC (buying BTC at 10 GBP/BTC) User B has 6 BTC and wants 54 GBP (selling BTC at 9 GBP/BTC) User A's order goes in first, and is unmatched. User B's order goes in 2nd, and is partially matched at User A's rate of 10 GBP/BTC. User B gives 5 BTC to user A and gets 50 GBP in exchange. User B now has 1 BTC and the 'wants' value is updated to 4 GBP. User C can now come along and buy User B's remaining 1 BTC for 4 GBP, even though the market price is in the range of 9 or 10 GBP/BTC. Note that overall, User B gets 54 BTC for his 6 BTC, and so actually gets the price he was expecting to. It's just that some was better than expected (5 sold to A for 10 GBP each) and some was much worse than expected (1 sold to C for 4 GBP).
This is how very high priced trades happen:User A has 5 BTC and wants 45 GBP (selling 5 BTC at 9 GBP/BTC) User B has 51 GBP and wants 5.1 BTC (buying 5.1 BTC at 10 GBP/BTC) User A's order goes in first, and is unmatched. User B's order goes in 2nd, and is partially matched at User A's rate of 9 GBP/BTC. User B gives 45 GBP to user A and gets 5 BTC in exchange. User B now has 6 GBP and the 'wants' value is updated to 0.1 BTC. User C can now come along and sell 0.1 BTC to User B for 6 GBP, at a price of 60 GBP/BTC even though the market price is in the range of 9 or 10 GBP/BTC. Note that overall, User B gets 5+0.1=5.1 BTC for his 45+6=51 GBP, and so actually gets the price he was expecting to. It's just that some was better than expected (5 bought from A for 9 GBP each) and some was much worse than expected (0.1 bought from C for 60 GBP each).
This is why absurdly priced trades show up in the API - it's because they actually happen. My patch to fix this and stop the silly priced trades is here: https://gitorious.org/intersango/intersango/merge_requests/3 |
|
|
|
Why has BritCoin been taken off the BitCoin Charts?
It was there about 2 hours ago when I last looked. It was scaling horribly, due to britcoin still making trades well outside of the best bid and ask prices. I was talking to the bitcoincharts guy a few weeks ago about adding an option to bitcoincharts to allow the user to set the scale, because otherwise the $5000 trade on britcoin makes the chart useless. He wrote: I'll try to fix that. In the meantime, you could also bug britcoin to fix their order processing so such insane trades won't happen again I emailed britcoin a patch to fix the 'insane trades', but it seems it hasn't been applied, because the weird trades are still happening. The patch is here, in a merge request: https://gitorious.org/intersango/intersango/merge_requests/3 |
|
|
|
The full address doesn't match the firstbits address. Confusing. |
|
|
|
Let's assume that you have completed a block. You have the opportunity to include any available unconfirmed transactions.
Would you as a miner choose not to include transactions with no fee?
Probably yes.
That's not how it works. You decide which transactions to include before you "complete a block". Completing a block means finding a nonce that makes the block hash to a low enough value, where the block includes the list of transactions you're including. |
|
|
|
i have my wallet.dat on a usb key in my desk drawer at home. The usb key has a fingerprint reader on it. when i want to access my wallet, 1. I insert key, authenticate with my middle finger  2. copy my wallet to bitcoin dir, 3. start bitcoin... recieve/send, 4. close down bitcoin, 5. recopy to a new dir ( date/time labeled ) on usb drive, 6. remove key, place in drawer. So thumb in the eye for linux nerds... i can do it too cos im a PC  lol So you're copying an unencrypted wallet to an online Windows box. Wouldn't a trojan just have to wait for the file to be copied and then steal it? |
|
|
|
So you're saying that every time I want to remove a private key from my wallet, it's better that I should dump all of my private keys, then create a new wallet with all the keys except the one that I wanted to remove? Instead of just clicking a button or typing a command to remove the key?
That's absolutely ridiculous.
No, I'm saying that if you have a button that does A and a button that does B then having a button that does "A then B" isn't "incredibly useful". It's merely convenient. |
|
|
|
|
Show Posts
