Wasn't there talk of adding a command line switch or JSON-rpc command for the client that would force it to rescan the block chain? I thought the code might have already been written, even.
It is. A -rescan switch exists in gavin's branch. Key import has not been implemented, though, and export is only available through a third-party tool. The -rescan switch might be too slow to be frequently usable. I don't know how much faster it is to rescan than to re-download the block chain. |
|
|
|
|
GetDataBack has a good reputation for recovering data from formatted drives. You must run it on some other computer with the target drive attached. You should never attempt recovery by running an OS on the target drive.
|
|
|
|
|
The easiest method would be to create a key, send bitcoins to it, and then move that key.
To import the key again, you'd either have to re-scan the block chain, or Bitcoin would have to be modified to continue watching for transactions to that key.
|
|
|
|
Btw, what's with the big difference in blocks/hour and traded volumes between bitcoincharts.com and bitcoinwatch.com?
The blocks per hour figure depends on sample size. Bitcoin Charts seems to be looking back 72 blocks. Bitcoin Watch is probably looking back further. |
|
|
|
Thanks. Looks this is what I've been looking for. I don't quite understand your table definition though. Does "WHERE inputs IS NULL" restrict result only to coin-generation transactions?
It eliminates spent outputs. The total value of unspent outputs should equal the total BTC in circulation (as it does). The LEFT JOIN matches each output with the input that spent it. If inputs IS NULL for a row, then the output is unspent. I intend to release my getblock-to-SQL script at some point in the far future, since it allows easy access to stats like this. It's much too messy right now, though. |
|
|
|
LastPass supports one-time passwords, which is the best solution for untrusted locations such as work computers. You print off a page filled with passwords, and use one of those whenever you need to log in. There's also an app for the iPhone. LastPass uses client-side encryption, so it's pretty safe, even though there's a central server. The big problem is it is not password protected.
You're broadcasting everything unencrypted over a radio frequency. Not a good idea.
|
|
|
|
But as a paranoid person as I am, I feel much more comfortable if there's a way to independently count (or estimate) the total amount bitcoins in circulation, without relying on 50 btc x (# of blocks) calculation. -- i.e. can we look at all blocks, add up all the amount flowing into recipient addresses, then subtract whatever flows out of these addresses, and get the total amount of bitcoin in circulation?
It checks out on my database: SELECT sum(outputs.value) FROM outputs LEFT JOIN inputs ON (outputs.tx=inputs.prev AND outputs.index=inputs.index) WHERE inputs IS NULL;
sum
------------------
5343100.00000000
(1 row) My database updating script will refuse to accept a double-spend, though I doubt I will catch something that Bitcoin itself doesn't. |
|
|
|
I mentioned this a while ago on IRC, but hardly anyone seems to be using it: http://blockexplorer.com/q/nethash/144Possibly I need to explain the columns: - blockNumber: Each row looks at a section of blocks (the section size is specified by the query parameter). This is the latest block included in the section. So the section includes data from the last row's blockNumber+1 up to this blockNumber. The first row looks back to block 1. - time: Unix time at blockNumber. - target: Full decimal target at blockNumber. - difficulty: Difficulty at blockNumber. - hashesToWin: Average number of hashes required to solve a block at blockNumber's difficulty. - avgIntervalSinceLast: The average number of seconds between each block in the section. - netHashPerSecond: Number of hashes the network is doing per second in this section. Calculated by comparing avgIntervalSinceLast to hashesToWin. This data can be used to make a very nice graph of network power and difficulty. |
|
|
|
This topic should be closed and thrown out into the trash. Too bad this forum is not too well moderated yet...
I, for one, am glad that the forum has not become ruled by authoritarian moderators (as most forums are). The ideals of libertarianism should be extended to moderation as much as possible: everyone should be free to express any idea unless doing so infringes on the equal right of others. The idea expressed in the OP was given an accurate title, and it is in the correct section. Neither Sirius nor Satoshi (bitcoin.org operators) have expressed a desire to filter potentially-illegal content. Therefore, the topic is OK. Use your own brain to determine whether the offer is a scam. I should mention that the last several replies (and my own) have absolutely nothing to do with the OP. These off-topic replies are disruptive to readers and on-topic repliers. Please move further bitcoin.org discussion to a new topic in "Bitcoin Discussion", and move Gypsy discussion to a new topic in "Off-topic". |
|
|
|
JAP supports paying for Tor-like service (not yet with bitcoins, though): http://anonymous-proxy-servers.net/It uses onion routing like Tor, but you have to pay to use certain relays. All relays are contractually obligated not to attack your anonymity, so you also have more protection against certain "evil node" attacks. Even the free "mixes" are often much faster than Tor. |
|
|
|
|
A very large site would probably want use getblock, anyway, since it allows you to talk to Bitcoin only once per block instead of querying it every time you want to do anything.
|
|
|
|
Grrr. Mistake != Non-american convention
It is a mistake in English, which the OP is using. No English style guide advocates putting a space before a question mark, and it is never done in English literature. Clearly it would not be a mistake in French. |
|
|
|
I would be impressed if you could guess the nationality of someone that easily. Which was this mistake you're talking about?
I notice that the OP put a space before a question mark, which is a common French mistake. Maybe davux is thinking of something else, though. |
|
|
|
Not to nitpick, but, how useful is the private key without the public one?
ECDSA public keys are derived from the private keys using a formula. So including the public key is redundant. |
|
|
|
In terms of the API, the client would invoke listtransactionssince with the hash of the last known block. If found, the daemon would return the hash of the last confirmed block in the chain, together with all transactions which have occurred between the two blocks. And instead of a timestamp, the optional parameter indicating early breakout criteria would be the block number.
Good idea. This will work. The client can also keep a stack of block hashes if desired to reduce work in case of a reorg (which happens more often than you might think). It won't work for 0-confirmation transactions, of course. Bitcoin Block Explorer does something similar: it uses the current block number for ETag/If-None-Match caching on certain pages. |
|
|
|
transactions are timestamped, aren't they?
No, they're not. And if they were, the timestamp would be provided by the attacker... |
|
|
|
|
Bitcointools has the ability to analyze your addr.dat, which should contain nearly every node in the network if your client has been running for a while.
|
|
|
|
|
I originally made mine for an RPG character: Theymos Amastica. It was created without much thought, being only a minor adjustment of the "Thamior" and "Amastacia" names given as elven name examples in the D&D 3.5 Player's Handbook. I began using it for all of my online game accounts, as well, and then I used it even for non-game accounts so I wouldn't have to remember multiple usernames. (At this point most of my online accounts were game-related.)
I sometimes wish that I had chosen something better and more meaningful, though it is nicely unique: almost all Google results for "theymos" are related to me. It would be very difficult to change at this point, after using it for 5+ years.
|
|
|
|
Are these connection IPs hard-coded into the source?
No. You connect to an IRC channel to get a list of all active Bitcoin peers. Then you choose 8 at random (basically). You will also be listed on that channel, though peers won't be able to connect to you from the outside. I recommend running the miners with -connect=<IP of networked bitcoind>. This connects only to the specified IP, and it prevents you from being listed on IRC. Then you are well-connected, but you avoid wasting network resources. Not being well-connected is only a minor disadvantage. You can replicate some of the advantage by running the miners with -maxconnections=20, which will increase the number of outgoing connections to the specified amount. You might also do -maxconnections=4 and -noirc to decrease the number and stay off IRC (you'll bootstrap from your network node), and then use addnode to connect to your networked bitcoind: this decreases network load without relying completely on your networked computer. (Edit: I just discovered that maxconnections can't increase the number of connections from 8, as I always assumed.) |
|
|
|
|
Show Posts
