When I try to dump my wallet, I get an error: $ bitcoind -rpcuser='xxx' -rpcpassword='yyy' dumpwallet
error: {"code":-1,"message":"CKEy::GetPrivKeyInner(): BN_bn2bin failed"}
I can dump a newly created wallet just fine, but my real one won't dump. Any idea why? Is it anything to worry about? Should I try spending all my coins to a new address? |
|
|
|
just for the hell of it, i'll take "never"; since nobody else has.
It might take a while to validate that your guess is correct. |
|
|
|
I have a special limited edition bitcoin available for just 5000 GBP if you would like to buy it.  Sure sounds good! Monopoly money ok?  Whatever you can convince Britcoin to accept is fine with me. |
|
|
|
My intention was to use online banking but I left my stupid card reader thing at my other home!
This is why I'm such a big supporter of these bitcoins because regular payment methods are an absolute joke.
I quite like the card-reader thing. Seems like a great solution to preventing fraud. People can guess my password, but without my plastic card they can't transfer funds. If MtGox had such a scheme in place they wouldn't have had the problems they're having. (But they'd probably have different ones...) Can't wait to buy some bitcoins!
I have a special limited edition bitcoin available for just 5000 GBP if you would like to buy it. |
|
|
|
an MMORPG
why does everyone make this mistake when it's clearly a Because they're reading the letters in their head: "em em oh are pee gee". So it's "an em ..." See also "an RPG" (About 4,350,000 Google results) vs. "a RGP" (About 2,380,000 results). |
|
|
|
Quick question...
I know it takes 3-5 working days for money to be deposited, but if it's deposited by cash directly into the account at a branch, does this speed up the process?
Thanks!
I deposited a few days ago using Nat West online banking into Britcoin's Lloyds TSB account and it took about 24 hours for the money to show up in my Britcoin account. I can't imagine that using cash would make it much faster. Also using cash you take a risk that the cashier might transcribe the reference code wrongly, and then there will be a delay while the guys at Britcoin try to match up the payment with your account. |
|
|
|
I am going to try to get in first and set a buy order for 0.001 BTC at $2000. Yep I would pay 2 bucks to have that data point show up. I am going to try and sell a BTC at $2000 also, if anyone wants to buy.
That wouldn't be the most anyone has paid for bitcoins. This morning someone paid $8000/BTC on https://britcoin.co.uk/ . Check the chart: http://bitcoincharts.com/charts/britcoinGBP#rg60zczsg2011-06-20zeg2011-06-23ztgSzm1g10zm2g25 (5000 GBP = 8000 USD, pretty much). From the Britcoin trades API: {"date": 1308779642, "price": 10.1702, "amount": 0.94},
{"date": 1308780181, "price": 10.2041, "amount": 0.00599566},
{"date": 1308780782, "price": 500.0000, "amount": 0.01},
{"date": 1308780841, "price": 5000.0000, "amount": 0.001},
{"date": 1308781381, "price": 10.2041, "amount": 0.48400469},
{"date": 1308781441, "price": 10.0000, "amount": 0.8},
|
|
|
|
Thanks dooglus for your help. We sent you 10 BC for your help  After some testing, we're going to pull that change. Did you get my email dooglus? Thanks a bunch. I did - and will reply right now. Is there any kind of bug tracker for your exchange code? If not, I think it would be good to have one. |
|
|
|
which chart are you referring to?
This chart: http://bitcoincharts.com/charts/britcoinGBP#rg60zczsg2011-06-23zeg2011-06-23ztgOzm1g10zm2g25 See also https://britcoin.co.uk/api/getTrades.php for numerical data: {"date": 1308779642, "price": 10.1702, "amount": 0.94},
{"date": 1308780181, "price": 10.2041, "amount": 0.00599566},
{"date": 1308780782, "price": 500.0000, "amount": 0.01},
{"date": 1308780841, "price": 5000.0000, "amount": 0.001},
{"date": 1308781381, "price": 10.2041, "amount": 0.48400469},
{"date": 1308781441, "price": 10.0000, "amount": 0.8},
1308780782 -> Wed Jun 22 15:13:02 2011 PST
1308780841 -> Wed Jun 22 15:14:01 2011 PST
so about 3 hours ago. I suspect someone read my posts here about a bug that causes all trades here to happen at the rate posted by new orders rather than existing ones, and wanted to try it out. If you attempt to buy 0.001 coins at 5000 BTC/GBP, you will be matched at that rate. You can pay as much as you like. That's the bug my patch fixes ( see https://gitorious.org/~dooglus/intersango/dooglus-intersango/commit/98961ecd84e6d8da2e7f4df3d15a90f4e1534dcb for the patch ). Looking back a bit, it happened too: {"date": 1308743881, "price": 10.0000, "amount": 0.06},
{"date": 1308746401, "price": 9.8000, "amount": 1},
{"date": 1308747301, "price": 270.2703, "amount": 0.111},
{"date": 1308747541, "price": 9.7600, "amount": 0.01},
{"date": 1308747541, "price": 9.7600, "amount": 0.01},
Somebody paid $27 for 0.111 BTC at Wed Jun 22 05:55:01 2011 PST - because that's what they asked for. http://bitcoincharts.com/charts/britcoinGBP#rg60zigDailyzczsg2011-06-13zeg2011-06-21ztgOzm1g10zm2g25 shows people also paid far too much for BTC on 13-Jun and 21-Jun.  |
|
|
|
I've taken a look at the cron/process_orders.php code and compared it to the doc/process_order documentation. It turns out that the code isn't doing what the documentation says it is [...]
I made a clone of the git repository and made some changes to fix these problems: 1) process new book entries in the order they arrive 2) chew through the existing order book matching best prices first 3) when a new order meets an existing order, use the price specified in the existing order, so if there are cheap coins available, it's impossible to buy expensive coins before the cheap coins are gone. https://gitorious.org/~dooglus/intersango/dooglus-intersangoI've done some basic testing on my local install and it seems fine, but please review the code! One question: If you place an order "I want to buy 10 bitcoins for $100" and it turns out there are coins available for less, would you want to (a) buy 10 bitcoins and get change from your $100, or (b) spend $100 and get more than 10 bitcoins Likewise, if I say "sell 10 bitcoins for $100" and someone wants to buy them for more, should it: (a) sell until you have $100 and keep some bitcoins around, or (b) sell all the bitcoins and give you more than $100 It strikes me that in both cases the sensible thing to do is option (b) - don't worry about exceeding what the user said they wanted to get, keep going until they've traded away everything they said they wanted to trade. Right? Currently the code is stopping early, doing option (a) in effect when lots of small orders are matched, and option (b) when your order is matched by a single large order. |
|
|
|
I've taken a look at the cron/process_orders.php code and compared it to the doc/process_order documentation. It turns out that the code isn't doing what the documentation says it is: For each order that is processed, we look to find other equivalent orders [...]
The fulfilling part checks to see if our order has a smaller depth than the
other one. If so, our order is completed at their exchange rate and closed. The
matching finishes up.
It's completed at 'our' exchange rate, ie. the newly processed order's, not the old order's. The other case is where we have a larger depth, and want to fulfill ourself
partly using their order.
[...]
We need to calculate how much of our order will be chipped off, while
preserving their exchange rate.
Again, what the code is doing is using the new order's rate, not theirs. I think the description you wrote is how it should be, and how you wanted it to be. But I think the code is backwards. This explains why people are getting the rate they ask for, rather than the best available rate in the order book. A better algorithm would firstly order the matching equivalent orders by best
price first so we move up the orderbook, rather than select random matches.
Order by price, and then by date. The first person to offer to sell at a certain price should be the first person to get matched at that price. Secondly an improvement perform linear programming to find the optimised rate
for two given orders given the constraints- although that isn't too important.
What's the optimised rate? For the seller, higher is better. For the buyer, lower is better. I think the way most exchanges work is that new orders get matched at the best price possible, and if they don't immediately match then they are left as standing orders and will only be matched at the requested price or not at all. One minor addition would be to never accept orders where the want / offer
doesn't produce a perfectly divisible amount so we don't get these random
remainders that are credited to a random account once the order matching is
completed.
I don't think that helps because different parts of the order can be matched at different prices. |
|
|
|
...
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
...
A new transaction is created for record keeping purposes and the users funds are
updated accordingly.
I'm not sure this is a good way of doing it. Suppose I'm trying to buy 1,000 BTC at 10 GBP each. The sellers are wanting 12 GBP each at the moment, so no trade happens. I'm waiting for a seller to ask for less. Then some joker comes along and offers to sell 1 BTC for 1 GBP. His offer matches my request to buy, and so, working the example as before: ... Order 14: We are offering 10,000 GBP for 1,000 BC ... Order 18: They are offering 1 BC for 1 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 1 GBP for 1 BC Order 14-2: We are offering 9,999 GBP for 9,999 BC ... We fulfill our order and close their order. ... Order 14-2: We are offering 9,999 GBP for 9,999 BC ... A new transaction is created for record keeping purposes and the users funds are updated accordingly. After buying the joker's 1 BTC for 1 GBP, the rest of out order is now changed, offering only 1 GBP per BTC. Unless someone else comes along with a very cheap sale, our buy order will never get matched. Even if some 2nd guy comes and offers 1 BTC for 2 GBP, we won't get to buy it, because we're now only offering 1 GBP per BTC. What's the reasoning for changing the rate in "Order 14-2" above? I think it should either keep the GBP spend and rate the same, and buy more BTC with the saving we made from the joker, so if the 2nd part is matched at the rate we requested we end up getting a total of 1,000.9 BTC for 10,000 GBP: ... Order 14-1: We are offering 1 GBP for 1 BC Order 14-2: We are offering 9,999 GBP for 999.9 BC ... or keep the rate and BTC requested the same, and spend less GBP, so if the 2nd part is matched at the requested rate we end up getting 1,000 BTC for a total of 9991 GBP: ... Order 14-1: We are offering 1 GBP for 1 BC Order 14-2: We are offering 9,990 GBP for 999 BC ... Did I misunderstand something? Was the example I quoted wrong? Or is the current implementation kind of weird? Notice this is what happened to Caesium. He offered to sell BTC at a low price when someone was already trying to buy at a higher price and the trade was carried out at his low price. |
|
|
|
genjix, ok, then it's not working.
I realise you have a lot on your plate at the moment with the bank situation, but if you or someone (is there a support address to email that might be better suited?) could take a look at why order 9314 was completed at £5 and not the £9+ that was on offer at the time, I would be most grateful.
It may be working as described and still do what you see. The algorithm as described is to find any two orders which match, and to fulfill them using the rate specified by of one of the orders. There seems to be no attempt to match the highest buy with the lowest sell, and no attempt to use the rate set by the older of the two orders. It's apparently random which of the suitable buy orders you get paired up with. "Looping through the matching orders with no ordering (we plan to fix that)"
See? |
|
|
|
Mike Hearn, the google fraud engineer who develops BitcoinJ, got the list and forced a password reset for all gmail accounts in that list.
I don't think that's true. I've just tried logging into dooglus@gmail.com which was on the list, and it's working as usual. I've not changed the password or been told about 'unusual activity'. I didn't use the MtGox password anywhere else though, so I'm not worried. It's true. Read the whole thread. I mean it's not true that he forced a password reset for all gmail accounts on that list, because my gmail account is on that list, and no password reset was forced on my account. It's basic logic. Re-reading the whole thread won't change anything. |
|
|
|
Have you tried using a debugger when it seems like it's in an infinite loop, breaking the execution, and stepping through it to test for an infinite loop?
He was making a joke. About this: http://en.wikipedia.org/wiki/Halting_problem |
|
|
|
No one else should know all that information except you, [...]
... unless their database was recently compromised, of course. |
|
|
|
Dose anyone have the Mt Gox list of usernames in alphabetical order, by email address preferably , im fcked if i can go through that many random accounts to find mine.
By username: http://tinypaste.com/f7a20 |
|
|
|
Mike Hearn, the google fraud engineer who develops BitcoinJ, got the list and forced a password reset for all gmail accounts in that list.
I don't think that's true. I've just tried logging into dooglus@gmail.com which was on the list, and it's working as usual. I've not changed the password or been told about 'unusual activity'. I didn't use the MtGox password anywhere else though, so I'm not worried. |
|
|
|
Many were trolls who lied, IMO.
A password hash does not allow you to login.
60000 password hashes, where 26 of them used the password "password", 11 used the password "abc123", 7 used the password "bitcoin" 3 used the password "secret" and 1 used the password "fuck" - that lets you log in. I don't have a GPU, and my CPU is slow, but it's still trivial to find (some) passwords given enough hashes. With a little more effort it's possible to find the combination of weak password and high balance. |
|
|
|
|
Show Posts
