Hi Genjix, why did you use a Polish Bank who charges for receiving SEPA? (Btw: the account is in EUR or in PLN?) May I add that Britconi has a way nice coloring? :-p Looking forward to the API coming  I know from certain special Corporate to other special Corporate accounts there are free transfers but I am not sure if there are other free transfers which people will be able to make use of. I see that there are probably ones in countries who have EUR as their standard currency. I will look into this further. As of right now receiving a SEPA transfer on our end is generally less than $2 (and a minimum of .25%... so if you are sending 800$ it actually would cost $2. There is a maximum of around 180PLN~$68, but this is if you are sending over $27,000). I will open an account in another country if it is advantageous. As of now our service is free as well. Our developers are all here in Poland which is why we opened the bank account in Poland. |
|
|
|
|
I saw already that there are other EUR exchanges such as btcex or bitcoin7... Wondering why they aren't used much.
Possibly people just use mtgox. We'll have to wait and see.
|
|
|
|
|
This is our European EU exchange.
Britcoin is still the UK exchange.
|
|
|
|
Send them to support@britcoin.co.ukWe're also working on a new site (more secure, better design to add new features) to be rolled out soon. |
|
|
|
|
Press CTRL + F5 if site graphics haven't been updated.
|
|
|
|
When the division isn't exact, one person loses less than 0.01 uBTC and the other gains it. I don't see how the exchange is absorbing anything.
That's my point. It's totally insignificant as far as I'm concerned, and the exchange operator could absorb that cost if need be. |
|
|
|
|
Also when phantom says 'rounding', he means to the 8th decimal place. I'm of the opinion that it's totally insignificant and we can make up those prices ourselves. It's unavoidable when you do 2 integer divisions that don't exactly go, and you get a remainder- what to do with it?
for instance, if the rounding is less than 0.000 000 01 and we get 1 million trades a year (optimistic) then that'd be 0.01
We round up for the person and absorb that cost ourselves. So the parties involved get more money than they asked for.
We could even increase the number of decimals internally to make that rounding error smaller.
|
|
|
|
|
There are no hacks. Check the commit logs.
|
|
|
|
https://gitorious.org/intersango/bitcoindI recommend this version of Bitcoin for people. Uses strings ("100000000") instead of doubles (1.0) for the RPC interface. And listreceivedsince <timest> RPC call. It's far better to keep polling for new received payments/sent payments, import them into your database and then act on it. Using bitcoin internal accounts is very bad in general.
|
|
|
|
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: update purses set amount = 123e8 where uid=99 and type='GBP';
Everything seems to work other than this. You need our special bitcoin, https://gitorious.org/intersango/bitcoind |
|
|
|
|
This is awesome! ^^ I'm definitely using this in my project as a guide if anything.
|
|
|
|
We were under-reporting our volume to bitcoinwatch/charts  Thanks to dooglus, we fixed a bug where our trades were dropping 0s on the end in our volume. New exchange is coming along nicely. We will be in a feature lock-down soon and start a week long bug fixing mode. |
|
|
|
Hey, You should email support@britcoin.co.uk so that it can go through the proper channels... I get too many messages everywhere and forget about them otherwise. If you email that, then our team can properly answer you |
|
|
|
|
Ah yes, I forgot about the checkpoints.
|
|
|
|
|
Basically if presented with 2 transactions then miners can randomly choose which to include in a block (if using the same outputs). The only condition is that the tx they include mustn't use the same outputs as a tx already in a block.
So you send out tx A with no fee, and tx B with a fee + lock time.
Two scenarios:
1. tx A gets included in a block before tx B's locktime finishes. By the time tx B becomes active, tx A is already in a block so it gets dropped.
2. tx A never gets into a block. tx B becomes active + gets into a block. tx A is forgotten.
|
|
|
|
|
Hi,
What happens if there's a fork really deep?
getdata uses CBlockLocator for the starting hashes. If presented with an ending hash deep enough in the chain, then it will return blocks starting from that forked point in CBlockLocator. However re-requesting the next chunk of blocks (after the first 500 on the forked branch) won't happen because the difficulty hasn't increased enough yet to cause an internal block chain reorganisation and become the new main chain.
This seems to be the case since the starting point for getdata is always the head of the best chain in the code.
I guess this is one of those astronomically unlikely scenarios that it's not a worry. In that case it might be a point to artificially limit the amount of start hashes in getdata and save some bandwidth.
|
|
|
|
|
There are already checkpoints in Bitcoin.
Also orphan blocks aren't verified unless there's a block chain re-organisation. At which point the block chain is invalidated from where it forks and the entire thing is recalculated from there.
|
|
|
|
|
Show Posts
