It is embarrassing and astonishing that this critical a bug was not caught before the 0.4 release; constructive suggestions on how to improve the testing and release processes that do not assume access to hundreds of thousands of dollars of funds to hire security consultants or QA teams are welcome. Getting sufficient testing of code BEFORE it is released has been a chronic problem for this project.
Don't know who would come up with the money for it, but it wouldn't be hundreds of thousands of dollars: Maybe offer BTC-bounties for bugs found in "official test releases". They probably wouldn't have to be high to motivate people in the bitcoin community to do better testing than is done now. About coming up with the money: I've had quite some success (although not yet what I hoped for) with collecting donations for a common cause ( https://bitcointalk.org/index.php?topic=51133.0). Maybe enough people would be willing to donate to "bitcoin testing", especially after things like the encryption bug or maybe even more serious stuff happen. |
|
|
|
I DID IT! It was not easy but it is possible. Hopefully there will be a more user friendly way to do this soon. Ideally we can eventually add a way to import mini private keys directly into the wallet through the Windows GUI on the standard Bitcoin client. For now I would settle for bribing the author(s) of pywallet into adding the mini private key format to pywallet. Not having that, this is how I did it: - I then made a file named “short” containing exactly these 22 characters. This is not as easy as it sounds because most editors add CR/LF and EOF characters to a file. I used hexedit to make a file of exactly these characters.
- Then I used openssl like so: bash-4.1# openssl dgst -sha256 < short
this can be done more elegantly in one step without the use of a file: echo "S4b3N3oGqDqR5jNuxEvDwf" | openssl dgst -sha256
|
|
|
|
Then picture more than ten of those aircraft hangars around the world. And these pictures are just Facebook, not a government.
Picture world peace. Well, it's more likely than that, got to give you that much. |
|
|
|
|
just registered together with a "non-bitcoin" friend.
we're probably driving by car from stuttgart on friday. If anyone wants a ride.... PM me.
|
|
|
|
@molecular: I double checked my bitcoin conf file and you are correct, it was set to pregenerate 100 addresses. Yet I can still only see a few in the address book from the bitcoin GUI. Does the client set them aside for later use, when I initiate the getnewaddress rpc? I'm assuming exactly that and I remember being told on #bitcoin-dev that's the way it works. There also seems to exist a rpc call "keypoolrefill" I just discovered (that's a modded version 0.5 of bitcoind, however, so you'd have to check with "help" if you have that). If it does what it sounds like, this would be something to call before the wallet-backup to avoid address loss in backup. In the end, to verify these assumption, we'd have to look at a wallet dump. I have a patched bitcoind on another system that has the sipa:showwallet patches ( https://github.com/sipa/bitcoin/tree/showwallet). These add a "dumpwallet" rpc call that dumps all the keys in the wallet (not just the ones displayed in the gui) in a human-parsable json format. I remember it was painfull to get these patches working and compile bitcoind. So maybe looking at pywallet (I never did myself) and verifying the behaviour of "keypoolrefill" and "-keypool=n" might be a good idea? I wonder if I increased this number up to, 500, for example - then restarted the client, would it pregenerate 400 additional new addresses and add them into the wallet?
Again, I'm assuming that's what would happen. If you want, I can verify these assumed behaviors using pywallet... I've been wanting to check that out anyways for importing/exporting keys (e.g. for casascius key import) |
|
|
|
One thing: I think the javascript alert confirming the payment appeared twice. I'm not sure what the first one said, cause I clicked OK too quickly.
I'm not sure what's going on. Might be nothing or a major bug  Here's what happened (idkey=6xvv4lma7t): my suspicion: when I downloaded the files, they were not really completely dled by the torrent client. When he downloaded them, they were "more complete". Just had a look, and it seems that you submitted the torrent twice somehow. The idkey of the first one is ieruqyd32m, the second one is the key you mentioned which was submitted 1 second later - you said that you saw the javascript popup twice? The website saw the previous torrent of the same name in the database, assumed it was finished and served up the files even though the torrent was not complete. I checked out the process a few times again with a couple of torrents and I can't seem to replicate the behavior. Very odd. I'll keep looking into it, but I think this was some sort of exception. It's entirely possible I submittet the torrent link twice. I think I even slightly remember doing that (/me scratches head) On the next small download I do I will try to replicate the bug. Until then, we can probably file it under "some extremely unlikely unknown crap happened when the user behaved unpredictibly". Of course, should users report broken files, alarms should go off in our heads. How many keys did you pre-generate before making the wallet copy? The default of 100 should be used up pretty quickly and bitcoind will generate new batches, right?
I didn't pregenerate any addresses other than the default amount created by the client. I plan to regularly download the wallet file from the server over an encrypted sftp connection, to ensure that the wallet is kept updated with any new addresses created. Actually I think you did implicitly pre-generate 100 addresses. Bitcoind fills the wallet with a certain amount of addresses initially. Default 100. there's a switch for bitcoind: -keypool=<n> Set key pool size to <n> (default: 100)
I never used it, but it seems maybe that way you could decrease the frequency of the wallet backup. Just an idea... it might be dangerous to fiddle with that, I'm not sure. Better do some tests and read docs before putting it in production blindly. Actually: backup frequency is not expensive in this case and the danger of loosing money is negligible. So I'd myself probably go with changing nothing here. IMG removed Hahaha!  0.00003 btc - less than 1mb. Didn't plan for torrent's that small! rofl Probably no need to fix this |
|
|
|
Nono I was absolutely sure that "out of coins" meant a 5xx error. I was unsure if everyone else knew this
Thanks for telling us. Maybe he discovered this would increase donations (because people make the same wrong assumption as I made) and now he'll be slow in fixing stuff |
|
|
|
that's up to you, really. wouldnt it be nice if a real "market" were to develop?
someone put up a buy order at .5 !
I have to agree. Unless we know for certain the seller's intention here. We have to assume they are just there for 'test' purposes or some such. I mean, unless they contacted you and said they needed to back out of their purchase.? Noone contacted me about this. Also: it's now only 5 @0.99BTC left (15 previously), so either someone bought 10 (to be expected and hoped for) or (part of) the order was cancelled (also good) Someone put up a sell order at 2 BTC, no harm. I decided to not buy back. |
|
|
|
Now only if charts.glbse.com would stop saying out of coins.  It'd probably help to send some coins to the displayed donation address. Ha! Ok I sent them a coin because I have used the crap out of that, hopefully coin karma makes the http 500 go away. Am I missing something? Where do you see a 500? The page is completely static, doesn't look like it loads anything via ajax, does it? Maybe I'm naive, but I seriously assumed this was a way to collect donations. |
|
|
|
Now only if charts.glbse.com would stop saying out of coins. It'd probably help to send some coins to the displayed donation address. |
|
|
|
I'm not sure what's going on. Might be nothing or a major bug Here's what happened (idkey=6xvv4lma7t): I downloaded a torrent with quite a few .mp3 files (legal ones, of course) in it. It downloaded to the server in a very short time (like 3-5 seconds after I got to the status page it was finished). I then downloaded all the files using "wget -r". The first mp3 plays, but the other are screwed. mplayer reports errors like crazy and even shows part of some movie (!!) when playing one of them. Either that torrent is screwed in the first place or (wild suspicion here), your download was assumed finished before it really was and the files are filled with leftovers from other downloads or whatever is was on the harddrive before. Is that possible??? EDIT: It get's better: a friend downloaded all the files a little later. He sent me one (number 26 on disc 2) and I compared the md5 sums: his: 32ec3b0d1055d665f32d956fcc632806 mine: 9f484155d5b68740a7c2bcbcd52eb95c my suspicion: when I downloaded the files, they were not really completely dled by the torrent client. When he downloaded them, they were "more complete". EDIT2: I'm re-downloading the files to confirm/reject my suspicion... md5sum of same file "26...": a4577bcbfd8a00cb3e9508a3aa33462e (yet another one) => suspicion more likely |
|
|
|
The site has now been fully transitioned to the new payment system. There have been no changes to the fronted of the site, but the whole payment code has been rehauled and is much simpler than it was before.
You are one of the most dedicated and productive persons I know of! The server will now generate a unique wallet payment address for each transaction. It will be generated as soon as the payment popup appears (this might delay the popup a few seconds). Once you send payment to the provided address, the server will poll bitcoind every 5 seconds to check if it has been received.
It all works in the exact same way as before, but is much more stable and secure with a lower chance of payment-dropping, as we are not not relying on third party payment processors for payment notifications.
Just went through the process (normal dl, no top-up stuff). Worked like a charm. One thing: I think the javascript alert confirming the payment appeared twice. I'm not sure what the first one said, cause I clicked OK too quickly. The one problem is the fact that the wallet has to be stored on the server, but I have put some thought into the best way to secure the earnings from attack. I have encrypted the wallet using a very strong password, and I will not enter the password into the server at any time (to combat keyloggers). I will keep a local copy of the wallet on my home computer that I will use to regularly remove any earnings into another, offline wallet. I don't envision any problems with this setup, as even if the wallet does get stolen, there will be no way for any attackers to decrypt - and therefore steal - any of the coin.
How many keys did you pre-generate before making the wallet copy? The default of 100 should be used up pretty quickly and bitcoind will generate new batches, right? I'm delighted with the current setup of the site now.
I have been meaning to do this since day one, but have not gotten around to it until now.
Very nice! |
|
|
|
And here I thought I only needed the username and secure password.
Exactly. Very confusing. Although once I understood how the system worked, I started to like it. |
|
|
|
[edit] It appears I did not understand the procedure regarding backing up the private key. Ah well, I did not have many bitcoin invested. I still do not understand the procedure for recovery even if I had backed up the private key.
You need not only the private key, but also the public key (can probably be derived from the private one) and the account id. If you had these, you could make a new account and paste the keys and id into the form and you'd have access. In my mind, all this should be explained somewhere, preferrably right on the respective pages. I remember how confused I was when I first started using this. I wasn't even aware the keys were stored in browser somehow and I didn't use the export feature until much later. I stored the private key, though. But that is not enough, you also need the account id. |
|
|
|
Looks like it is back up again.
yes, thanks nefario!!! It is still down for me. Maybe try to log out completely and re-enter the password? It won't bring me to the login page. It only asks for a PW without a UN. UN? This page: https://glbse.com/client/glbse/index.html always loaded for me, even when glbse was "down" (was just the backend). What do you mean by "login page"? UN = username. I get a password page. It accepts my password, then it goes to the account management page, but shows no account. All I can do is register, import, export and clear. Maybe my account was hacked? It's unlikely your account got hacked. Afaik the password asked is only used locally to en-/de-crypt local storage of keys. Did you export the account keys/id/... before using the Export feature? Maybe you deleted the local storage of your browser somehow which contains the keys and ids for the account (don't know exactly in what way this is done). That would be bad if you didn't export them. |
|
|
|
CBS news station KOLD in Tucson Arizona is currently showing a video commercial for an upcoming TV story about Bitcoin that will air at their 10:00 news which starts about 20 minutes from now (10:00 PM Arizona time, 0500 UTC). The video commercial is now visible on their website, as well as a prominent advertising blurb on the station's home page. http://www.kold.comIt appears there is a link on the home page that allows live watching of the newscast. So it aired? Anyone have a link/recording? Ken Colburn of Data Doctors fear-mongers: "You wanna be careful to use bitcoin. You wanna be careful with entities that are asking you to use bitcoin as their currency, cause there's generally [twitches, grins] nnnyeah, there's a possibility that they're trying to hide something." Mike did his best to counter this and other objections: "I don't have a philisophical problem with the government, I pay my taxes, as I should, I'm a good citizen, I follow the laws..." My favorite part is the narrator, because it totally gives away how uninformed the producers must be: "an e-mail to one of bitcoins managers has never been returned". lol, I wonder why this bitcoin company doesn't answer emails... hmmm. The clip leans a little too much against bitcoin to be called "unbiased" |
|
|
|
Looks like it is back up again.
yes, thanks nefario!!! It is still down for me. Maybe try to log out completely and re-enter the password? It won't bring me to the login page. It only asks for a PW without a UN. UN? This page: https://glbse.com/client/glbse/index.html always loaded for me, even when glbse was "down" (was just the backend). What do you mean by "login page"? |
|
|
|
Looks like it is back up again.
yes, thanks nefario!!! It is still down for me. Maybe try to log out completely and re-enter the password? |
|
|
|
|
Someone seems to want to "get out" and is selling 15 shares for 0.99 BTC.
This is perfectly legitimate.
We could play nice and just buy them back. It would set us back 14.85, of course. Considering that we probably have to sell most of the shares anyway, this wouldn't make a difference in the end, because new donators will buy the 0.99 BTC shares first anyway.
What should I do?
|
|
|
|
|
Show Posts
