|
I use chromium and also had to empty the disk cache before I could see the new version.
|
|
|
|
Trading update:
-I don't have time to trade hourly candles in the BTC market right now, so I am moving to daily.
-Exited the trade at $6.33 - a loss of $.02 per BTC or .3% pre-commission.
-Short signal generated at current prices on daily charts using 21/10 (SMA)
-Short at $6.28 (Low leverage - the higher the timeframe, the more wiggle room you need to allow)
I'm not seeing it. Are you saying there was a crossing while today's candlestick was still forming? Do you not wait for each candlestick to complete before looking for crossings? Either way, it doesn't look like the price has been low enough at any point today for the moving averages to have crossed:  |
|
|
|
Thanks. git://gitorious.org/+bitcoin-stable-developers/bitcoin/bitcoind-stable.git worked for me. |
|
|
|
|
Which git repository is the v0.5.2 tag in? I've not been able to find it.
|
|
|
|
Hi. I coded up an API for the World Bitcoin Exchange site a while back. How would you like to be its first user? I've done a bunch of testing, and it looks good to go, but so far we've not announced it as being available. If you want to try it out, tell me your WBX userid, or openid, and I'll get you set up. I prefer email ( dooglus@gmail.com) but PM here works for me too. Chris. |
|
|
|
If they are true to their word, then even were their site completely and utterly hacked, the attacker would not have your money.
That's not quite true. If the site was hacked such that the attacker was able to modify the javascript to collect all typed passwords then the attacker would indeed have your money if you logged in after the hack happened but before it was detected. |
|
|
|
what's 'vanilla'? you mean softcore?
Vanilla sex (or conventional sex) is a description of what a culture regards as standard or conventional sexual behaviour. Different cultures, subcultures and individuals have different ideas about what constitutes this type of sex. Often, it is interpreted as sex which does not involve such elements as BDSM, kink, or fetish activities.
|
|
|
|
Just recently I looked at the node I run on my router and was alarmed to see the data size much bigger than I expected (at around 4G iirc...I'll do more analysis later, but my initial impression was that the block chain would be less size at this time.)
I've been running the bitcoin client for almost a year, and my .bitcoin folder is only just over 1G in size. The 'database' folder is 10M, and the only files of significant size in .bitcoin are: -rw------- 1 chris chris 32K Nov 16 11:13 __db.002
-rw------- 1 chris chris 264K Nov 16 11:13 __db.003
-rw------- 1 chris chris 780K Nov 16 11:07 wallet.dat
-rw------- 1 chris chris 904K Nov 16 11:13 __db.001
-rw------- 1 chris chris 2.4M Nov 16 11:14 debug.log
-rw-r----- 1 chris chris 10M Oct 6 21:06 log.0000000001
-rw------- 1 chris chris 45M Nov 16 11:12 addr.dat
-rw------- 1 chris chris 292M Nov 16 11:12 blkindex.dat
-rw------- 1 chris chris 719M Nov 16 11:07 blk0001.dat
Do you have several copies of the blockchain in your 4G folder? |
|
|
|
So it'd have to be something more like 6 or 8 blocks in the future, to ensure no one can hold blocks to try and win.
That doesn't fix the problem at all. I just look back 6 or 8 blocks for entries I made before submitting a block instead of looking back 1 block. |
|
|
|
I'd rather be able to tell someone instantly whether they were a winner or not.
If you can tell someone instantly whether they won or not, you could tell your buddy whether he was about to win or not before he made his entry. It seems like you can't have instant decidability as well as having it be impossible for you to cheat. |
|
|
|
for unencrypted keys on freespace on disks: sudo dd if=/dev/urandom of=/dev/sda
DO NOT TRY THIS AT HOME. I don't know if this was meant as a joke, but it's probably worth pointing out that this will overwrite all the partitions on the first hard drive with random junk, not just the "freespace". |
|
|
|
Since the coins used in a transaction are randomly selected by the client, you may well be able to get a hash beginning with the required byte if you have enough private keys with funds on them, and enough patience.
Even simpler, you can keep attempting to spend the same amount from the same private key(s), but send the change to a different new address each time. That's enough to change the transaction hash. |
|
|
|
Just curious... are transaction hashes predictable at all?
They're as predictable as any other hash. The algorithm used to generate the hash is known, so in that sense they're entirely predictable. But you have to run the hashing algorithm to 'predict' them. It would be possible to put a confirmation step in the client before sending a transaction: "this transaction with have hash xxxxxx: [send] [cancel]. Since the coins used in a transaction are randomly selected by the client, you may well be able to get a hash beginning with the required byte if you have enough private keys with funds on them, and enough patience. Or the process could be automated. |
|
|
|
|
I found a way to make the release candidate crash:
1. use bitcoind to send to an address that's not in the address book
2. in the client, right click the greyed-out address in the 'address' column of the transactions tab
3. 'edit label'
4. the address field is blank - would be nice if it was populated automatically. type or copy/paste the address in, and type a new label name
5. click 'ok' and get a segmentation fault
|
|
|
|
It might be worth it to put that wallet on another computer and do some kind of transaction. Then the wallet he/she has will no longer be valid.
Are you sure? If you send the entire balance to a new address, the thief's copy of the wallet will be empty, but still valid. If you send less than the entire balance, you stand a chance of leaving some coins untouched and still available to the thief, and any change from the coins you do send will be sent to an address from the keypool, which the thief will also have access to. I don't think there's any "kind of transaction" you can make that will invalidate the thief's copy of your wallet. |
|
|
|
It turns out that's exactly what the client is using. The problem is that there's no English translation file. That should be easy to provide. I'll make a pull request.
Here's an English translation that makes the strings appear correctly: https://github.com/bitcoin/bitcoin/pull/606 |
|
|
|
Is it really so hard to do "%d second%s", x, (x != 1 ? "s" : "")
That's not hard, but it's not correct either. The client currently supports 7 different languages. http://doc.qt.nokia.com/qq/qq19-plurals.html talks about a better way to support plural forms in QT apps. It turns out that's exactly what the client is using. The problem is that there's no English translation file. That should be easy to provide. I'll make a pull request. |
|
|
|
Is it really so hard to do "%d second%s", x, (x != 1 ? "s" : "")
That's not hard, but it's not correct either. The client currently supports 7 different languages. http://doc.qt.nokia.com/qq/qq19-plurals.html talks about a better way to support plural forms in QT apps. |
|
|
|
When I hover over the green checkmark in the bottom right corner, it tells me: "Last received block was generated 54 second(s) ago".
If I go back to it 10 seconds later, it says the same, when I would expect it to say "67 seconds ago" or "1 minute ago". I guess what the time is telling me is how much time elapsed between the block being generated and the block being received by my client, but that's not what the tooltip says. "Last received block was generated 54 second(s) before it was received"
or "Last received block was 54 second(s) old when it was received"
or even just "Last received block was 54 second(s) old"
would be more accurate. "Ago" means "before now". |
|
|
|
|
Show Posts
