Latest posts of: dooglus

Quote from: mouse on July 02, 2011, 01:32:55 AM

I havent looked through all the code, but I dont think the timestamp really matters. All that matters is that the solved block includes a hash of all previous blocks, to prove that it really is the next block solved. Right?

The timestamp matters when calculating the difficulty.

I found this, that rejects blocks which have a timestamp more than 2 hours into the future:

Code:

    // Check timestamp
    if (GetBlockTime() > GetAdjustedTime() + 2 * 60 * 60)
        return error("CheckBlock() : block timestamp too far in the future");

First off, there would be no need for such complication. The client is open source, so I can bypass all the p2p date averaging and use whatever timestamp I want in the blocks I find.

I think, however, that when a new block is published, it won't be accepted if the timestamp isn't reasonable.

I'll see if I can find the relevant code.

Quote from: SgtSpike on July 02, 2011, 12:25:23 AM

Well, I know they're anchored to UTC, but where do they get the UTC time from? An official time server? Or the block-creator's local system time?

I think what happens is your client asks all the other clients it talks to what they think the time is, and keeps a list of the offsets between them and what it thinks the time is. It then uses the middle of that list as the real time.

For example, in .bitcoin/debug.log I see:

Code:

Added time data, samples 59, offset +8 (+0 minutes)
-31539317  -156  -148  -115  -99  -89  -80  -77  -30  -29  -28  -22  -21  -19  -18  -16  -16  -12  -12  -11  -11  -9  -8  -7  -7  -6  -6  -5  -4  -2  -2  -1  -1  -1  +0  +0  +0  +0  +0  +1  +1  +1  +1  +2  +2  +2  +2  +3  +3  +3  +4  +5  +6  +8  +8  +9  +15  +31  +245  |  nTimeOffset = -2  (+0 minutes)

The client has got 59 different times from peers and those are the offsets from my clock in seconds.

5 of them agreed with my client to the nearest second. Most clients agreed to within a minute. A few were out by 2 to 5 minutes, and one guy doesn't know what year it is (365*24*60*60 = 31536000). The middle of that list of 59 time offsets is -2, and so 2 seconds is added (or subtracted?) from my computer clock to get the 'real' time.

Did anyone notice the recent trade at 45 pence per BTC?

Code:

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/126d05d8f23a2745da8db65fb57414eca607d0d8

Quote from: JeevesNZ on July 01, 2011, 02:45:09 AM

So i've downloaded the code to have a play around.
Im reasonably new at LAMP etc.. but have figured out most of the problems on my own. The thing is I am getting this on the profile page under balance:

Warning: gmp_cmp(): Unable to convert variable to GMP - wrong type in /var/www/bcx/util.php on line 115

Im guessing GMP or something may not be configured properly? Any ideas?

I get that all the time.

It only seems to affect the code that transfers bitcoins from the bitcoin client into the exchange database. I just ignore it, and deposit funds by doing something like:

Code:

  update purses set amount = 123e8 where uid=99 and type='GBP';

Everything seems to work other than this.

This thing?

Code:

Private user info

You are logged in.

User ID: 101

OpenID: https://www.google.com/accounts/o8/id?id=AItOawmmjsHzeUJPxKzlotok
Warning: fopen(http://...@127.0.0.1:8332/): failed to open stream: Connection refused in /home/chris/Programs/dooglus-intersango/jsonRPCClient.php on line 132 Fatal error: Uncaught exception 'Exception' with message 'Unable to connect.' in /home/chris/Programs/dooglus-intersango/jsonRPCClient.php:140 Stack trace: #0 /home/chris/Programs/dooglus-intersango/util.php(108): jsonRPCClient->__call('getbalance', Array)

I think that means that the bitcoind on the server stopped accepting connections. I've seen it before and it never seems to last for long. It means the site is unable to communicate with the bitcoin client, but trades still work.

Quote from: koopa on June 30, 2011, 02:37:18 PM

Have you entered bug fixing mode yet? The reason I ask is because i am currently seeing PHP errors all over your website. I was about to make my first BTC deposit.

I don't believe they have.

Can you show the errors you're getting, and/or tell us how to see them for ourselves? I've not noticed the errors.

I only used MtGox once.

I deposited 10.00 BTC, sold it, bought it back a little cheaper and tried to withdraw, but it told me I couldn't withdraw because of some problem with PayPal. I never used PayPal with MtGox; I don't think they even support it. I reported it to them and they ignored me. I think the problem may have been that my USD balance was -$0.01 after I tried to spend all my USD for BTC. So I sold the bitcoins again and bought them back a little cheaper again. This time my USD balance was $0.00 and I was able to withdraw my 10.17 BTC. So I made a 17 bitcent profit, realised I had been risking considerably more than I gained, and decided to stop messing about. My closing balances were $0,00 and 0,00 BTC.

Then the hack happened, and I went through the 'reclaim my account' process just to see how it worked.

When I got back in, I had $0.002 and 0.008 BTC. I used to have nothing.

It's not enough to worry about, but it makes me think that something is wrong, and if they can get my zero balances a little bit wrong I'm sure they can get other people's balances much more wrong.

I like https://britcoin.co.uk/ - it's commission free, and allows free bank transfers in and out (for UK banks).

Quote from: genjix on June 27, 2011, 11:45:06 AM

yep, it was done a little afterwards since phantom forgot to do it.

I was just watching the Britcoin market and saw a trade come in and get matched at the pre-existing market price, so my patch seems to be working:

Market depth before the new order arrived:

Code:

      11.000000        1.820000 :       10.761600        0.251498
      11.000000        0.012811 :       10.909100        0.578283
      10.994600        1.850000 :       10.989000        1.001001
           sell                               buy

A buy order came in at 11.5, well over the best existing sell price. Previously this would have been matched at 11.5:

Code:

      			        :       10.761600        0.251498
      11.000000        1.820000 :       10.909100        0.578283
      11.000000        0.012811 :       10.989000        1.001001
      10.994600        1.850000 :       11.563300        0.500000
           sell                               buy

After the trade was done, the best sell offer has been reduced by 0.5BTC:

Code:

      11.000000        1.820000 :       10.761600        0.251498
      11.000000        0.012811 :       10.909100        0.578283
      10.994600        1.324137 :       10.989000        1.001001
           sell                               buy

and the trade went through at 10.9946, for 0.525863 BTC:

Code:

Tue Jun 28 11:56:01 2011  10.994600   0.525863

The size of the order in GBP was kept the same. Since he got a better price than he asked for, he got correspondingly more BTC:

Code:

>>> 10.994600 * 0.525863
5.7816533398
>>> 11.563300 * 0.500000
5.78165

Quote from: Man From The Future on June 26, 2011, 10:50:25 PM

It'll be reduced to 0.0005 (Or 0.005, I can't remember Tongue

)

I bet if it had been written in mBTC you would remember: 0.5 mBTC (or 5 mBTC? Tongue

)

0.0005 and 0.005 just look too similar somehow. I think we're just not used to dealing with such tiny numbers.

Quote from: BkkCoins on June 27, 2011, 03:41:45 AM

Hopefully you didn't enter a wrong address when you did the transaction. AFAIK that would put funds in someones else's hands or a void address which can't be claimed.

There's a checksum built into Bitcoin addresses. You're very unlikely to typo an address and end up with another valid address. And if the address you type isn't a valid address, you'll not be able to send funds to it.

Quote from: genjix on June 26, 2011, 01:13:08 PM

I updated the document in the repo :p (although it's no longer true since you fixed it)

Did you put my fixes live?

It looks like you didn't (times are PST):

Code:

Sun Jun 26 14:39:01 2011  10.130500   0.010887
Sun Jun 26 14:40:01 2011  10.149700   5.891817
Sun Jun 26 14:41:01 2011  12.220000   0.008183
Sun Jun 26 14:45:01 2011  10.153800   0.650000
Sun Jun 26 14:46:01 2011  10.240200   2.080043

That 12.2 in the middle there shouldn't have happened if you had applied my patch, given that you have people offering to sell at 8 different 11.x prices.

Quote from: saadtariq30 on June 27, 2011, 01:16:07 AM

God are there some ridiculous orders..10000000 GBP wanted for 0.01 BTC....trolls be trollin.

My bad...

Can't blame me for trying tho' can you?

edit: oh, that's not me. I'm offering 1 bitcoin for 5k, 50k, 500k, and 5 million GBP. But someone has 1-up'ed me. How rude!

Quote from: CurbsideProphet on June 27, 2011, 12:24:09 AM

Quote from: KorJax on June 27, 2011, 12:19:55 AM

At 133,000 currently. Didn't know I had to leave it open for a while in order for me to get anything, thanks for the info.

Yup. Check the blockexplorer. Once you pass your block number you should see it show up.

You don't have to leave it open to 'get anything'. You own the BTC whether you run your program or not. It's just that it won't show up in your program until your program has downloaded the block which says you now own the BTC. There are about 133,433 blocks at the moment, and about 6 new ones are made each hour.

Quote from: jerfelix on June 26, 2011, 06:56:02 PM

Maybe with a Waldo-type device he'll get the market penetration that he's looking for.

Maybe with a device like this the market will be able to penetrate him.

Quote from: genjix on June 26, 2011, 07: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.

I think that's not the case. You're closing orders when want_amount <= 0.

See https://gitorious.org/intersango/intersango/blobs/master/cron/process_orders.php#line36 for example:

Code:

38     UPDATE orderbook
39     SET
40         status='CLOSED'
41     WHERE
42         orderid='$them_orderid'
43         AND (
44             amount <= 0
45             OR want_amount <= 0
46             );

Quote from: genjix on June 26, 2011, 01:13:08 PM

Quote from: dooglus on June 26, 2011, 03:27:55 AM

We don't get to spend the other 5 GBP that we asked to spend on bitcoins because we already got more than the 1 BC we initially requested. We'll have to make a new request and hope that that time it all gets spent.

Ahh, I meant to actually say 0.5 instead of 2.5... But your reasoning is valid and correct. I updated the document in the repo :p (although it's no longer true since you fixed it)

I think it would be best to just ignore both the want_amount values other than for determining the initial price, and only use the (have) amount values. If I have 10 GBP that I want to convert to BTC, I want to convert all 10. If you come at me with a better price than I was expecting, I want to end up with bonus bitcoins, not left over GBP. I've not fixed that bit (yet).

Quote from: genjix on June 26, 2011, 01:42:30 AM

This is wrong since it uses the initial_amount and initial_want_amount to calculate the exchange rate you set. The amount left that you want is more for display purposes and isn't used internally.

Yes, I see that now after reading the code.

I think you need to revise the example in the doc/process_order file:

Code:

    ...
    Order 14: We are offering 10 GBP for 1 BC
    ...
    Order 18: They are offering 2.5 BC for 5 GBP
    ...

We need to calculate how much of our order will be chipped off, while
preserving their exchange rate.

    ...
    Order 14-1: We are offering 5 GBP for 2.5 BC
    Order 14-2: We are offering 5 GBP for 2.5 BC
    ...

We fulfill our order and close their order.

    ...
    Order 14-2: We are offering 5 GBP for 2.5 BC
    ...

The order 14-2 isn't right, and makes it look like the whole of our order is adjusted to match the incoming order's rate.

What really happens is:

Code:

    ...
    Order 14-1: We are offering 5 GBP for 2.5 BC
    Order 14-2: We are offering 5 GBP for -1.5 BC
    ...

and since our want_amount is now negative, our order is closed too. We don't get to spend the other 5 GBP that we asked to spend on bitcoins because we already got more than the 1 BC we initially requested. We'll have to make a new request and hope that that time it all gets spent.