This would allow miners to cheat by choosing a timestamp.
Fact check: miners can and do choose the timestamp. Miners are free to change to timestamp within a certain time window. That helps stir the block hash, when 32-bit nonce is not sufficient. |
|
|
|
|
Indeed. The email registration is free, just to read that article. And it sends a message that they are writing good material.
|
|
|
|
I think there is a minor flaw in the design of the bitcoin; in calculation differency, the change should be accounted, so instead of "changing diff to a value which would have gave 10 minute interval last 2 weeks" the rule should be "changing diff to a value which gives 10 minute interval, if the calculation power changes as last 2 weeks".
I'm not convinced. I think it's possible that your scheme could result in a less stable difficulty, with the difficulty adjustment continuously overshooting, overcorrecting. Like watching a novice trying to steer a boat. From a macro perspective that's precisely what happens anyway. Just like anything in nature, or markets; there is never an equilibrium. Any appearance of such is simply a frozen snapshot in time, that doesn't reflect reality seconds before or after the snapshot was taken. Equilibrium is forever sought, never attained. |
|
|
|
Is there any other site that hosts (regularly updated) blockchain files? I tried using bootstap.dat, but that still leaves ~17k blocks to download, and those take forever.
Read the post in this thread, immediately preceding yours  |
|
|
|
I was thinking about the ways of reducing the cost of running a full node. The only solutions I could think of also reduced the hashing power.
A full node just verifies and shovels blocks. We have a few thousand full nodes (and need more!). The whole point of bitcoin's Proof-Of-Work scheme is that data is cheap to verify, but expensive to produce. A miner is different from a full node. |
|
|
|
|
Thanks for keeping us in the loop. Good stuff.
|
|
|
|
|
The peer-to-peer network is more vulnerable to low level network attack, than the ever-discussed 51% hashing attack.
You can help, by running a full node that accepts incoming connections.
|
|
|
|
Hi! Does this patch also exist for the current 0.7.1 version? See https://github.com/bitcoin/bitcoin/pull/220Introduces four new RPC calls: * dumpprivkey: retrieve the private key corresponding to an address * importprivkey: add a private key to your wallet * dumpwallet: export the contents of your wallet in various ways * importwallet: import/merge a dumped wallet into your own dumpprivkey and importprivkey long been upstream, and in released software. dumpwallet and importwallet are not yet merged. |
|
|
|
Trying to figure out how this number makes sense..
2012: 60,896 trillion BTC sent
60,000 trillion, with only 10 million btc in circulation, with 365 days in a year...each bitcoin is transfered over 16,000 times a day. If it was 10 times a day I could see it, but every bitcoin moves 16,000 times per day .. that doesnt seem to make sense.
It is a simple total of each bitcoin transaction's output values, from Jan 1 2012 to Sept 10 2012. |
|
|
|
Pieter,
I am trying to make my blockparser utility work with your changes ...
In particular, it looks like blkXXXX.dat files do not obey the same structure as the
original blkXXX.dat files of the previous version (e..g sometimes the block magic
is not what I expect it to be).
They should be exactly the same as <= 0.7.1: 4-byte pchMessageStart, 4-byte size, data. If that is not the case, there is a bug that should be fixed. They block magic is not always pchMessageStart. It's very often zero, but looking at things closer, it looks like it's always close to the end of the blkXXXX.dat, and therefore, I suspect it's an EOF mark. The older blkXXX.dat did end exactly on the last byte of the last block. Any chance you can do a hexdump, or otherwise narrow down what is being seen? Just re-reviewed the code. Each record is written as described (4/4/block), with no EOF marks or anything else. Perhaps your bitcoind crashed during a write, or a similar cause? Try downloading again, and see if you still have a corrupted blk*.dat. |
|
|
|
Pieter,
I am trying to make my blockparser utility work with your changes ...
In particular, it looks like blkXXXX.dat files do not obey the same structure as the
original blkXXX.dat files of the previous version (e..g sometimes the block magic
is not what I expect it to be).
They should be exactly the same as <= 0.7.1: 4-byte pchMessageStart, 4-byte size, data. If that is not the case, there is a bug that should be fixed. |
|
|
|
Until version 0.8 arrives (very fast!), you may use the Bitcoin blockchain torrent to speed the big first part of your download. Edit: heh, pekv2 and I posted at the same time, it seems. |
|
|
|
The clock might be wrong... but it's not gonna days or weeks wrong.
That's wrong assumption. If the battery on your motherboard is empty the date would be 1.1.1970. I can come up with some other scenarios where the date/time is seriously incorrect. You're stretching. Anything is "possible" but using a 0.01% case to justify giving new users a bad experience is not reasonable. |
|
|
|
I've been battling this concept in Armory with its deterministic wallets, for a while. I implemented "blockCreated" and "timeCreated" variables for each address, but I have been hesitant to actually use them for anything. Because, I determined that getting it wrong was not worth the performance benefit of when it is right: if you trust the timestamps are created and stored correctly, but it turns out that something was wrong (incorrect clock when it was stored), the user could be missing a big chunk of their wallet and it could be a mess trying to figure out what happened (during recovery of a deterministic wallet, that is). Plus, even if it is right, unless the user knows exactly how much they had they don't know that it's right unless you do the full scan anyway. At least for right now, doing the full scan isn't that much more cumbersome than a partial scan, so it's easier to just do it.
The clock might be wrong... but it's not gonna days or weeks wrong. You have to include variability anyway, because blocks can vary. So given birthday X, start scanning at X minus 2 days, or X minus 1 week. |
|
|
|
|
Birthday is of continuing relevance to: new users, new wallets.
|
|
|
|
Can you elaborate?
It has significant advantage as your wallet has been created recently. You created wallet around block 200k, so you need to synchronize only around 10k of blocks (20x speedup). However in few years of usage, on block 1M, you'll need to synchronize 800k of blocks. Then the advantage of timestamp is almost neglible, because the speedup will be only 0.2x (probably a lot less, as blocks are bigger and bigger). All this is predicted on an invalid assumption: the common case will be older, existing bitcoin users carrying around one big wallet. First, wallet creation date is much different than individual key creation dates. Keys are constantly created, therefore a portion of the wallet state is always created recently. As blocks get bigger and bigger, key birthday reduces the number of keys one must scan in each block, especially if key retirement is also supported. Long term you will have a rolling window of keys, no matter when the wallet is created. Key birthdays will always be relevant and useful, for this reason. Furthermore, there will always be new users creating new wallets, and users with multiple wallets. |
|
|
|
Generally speaking, yes, you should store the key birthday (or seed birthday) somewhere. When [re]scanning, this makes a huge difference in startup and network-sync times.
While it might make a huge difference now (because seeded private keys are relatively new concept), it won't make a big difference in a future. I agree it might help to avoid unnecessary rescanning, but relying on that feature is flawed ... Can you elaborate? All the major client developers agree this is a good idea. The benefits into the future increase, as the block chain gets larger. It makes an even bigger difference in the future. |
|
|
|
Anyhow, is it possible to know the birthdate of a wallet ? By this I mean the date when the wallet seed was created.
Is there a real-time network-synced clock on the device that could be remember this and expose it? Or the host computer could give the device the current time perhaps.
Generally speaking, yes, you should store the key birthday (or seed birthday) somewhere. When [re]scanning, this makes a huge difference in startup and network-sync times. |
|
|
|
|
Show Posts
