|
Miners typically do not modify the timestamp - they just use the timestamp in the block, as received by the getwork call.
|
|
|
|
|
The reason fees currently exist, is not really for rewarding miners. For now, the generation income will probably stay a lot higher than fee income. However, fees are useful for 1) speeding up transactions 2) preventing spam transactions and 3) getting people used to the idea that some fee will be needed in the future, and have the network experiment with it.
Anyway, the default minimum fee (for large or spammy transactions, or subcent outputs) is going to be decreased soon, and probably made more configurable.
|
|
|
|
|
loop:
var blockheader = DoGetWorkRPCCall()
var target = ExtractTarget(blockheader)
for nonce in 0..4294967295:
var attempt = ModifyNonce(blockheader, nonce)
var hash = SHA256(SHA256(attempt))
if (hash < target)
ReportSolution(attempt)
|
|
|
|
|
I think a bitcoin: URI is much more suited than the binary format intended for addresses.
|
|
|
|
|
The first rule of bitcoin is to backup your wallet.dat.
The second rule of bitcoin is to backup your wallet.dat.
Other than that, yes lost wallets result in permanently unspendable coins - effectively removed from circulation.
If you don't like to take that risk, you can use an online wallet, like mybitcoin.com or instawallet.org (given that you trust the operator of these sites).
|
|
|
|
2. wallet restore appfunctionality is needed. Lets say I have 100 BTC and i back up my wallet file, spend 20BTC and my PC crashes. I restore by only backup file, which has 100BTC in it. At this point i'd be double spending... Being a legitimate user, there should be a way to sync up my outdated wallet back-up file with the network, to have the 100BTC value in my outdated wallet adjusted to 80BTCs which the network thinks i have. Perhaps havewalet file remember when, which addresses pointed to it and them my PC can analyze the most current block chain to sync up the wallet file with network.
Thoughts?
Since 0.3.21 this should happen automatically. In 0.3.20 you can use -rescan to update your wallet with information from the block chain. |
|
|
|
|
The size limit referred to here is a size in bytes, not amount. If your 0.01 payment consumes a lot of small coins, it may grow quite large.
|
|
|
|
Good idea. Interestingly, the keys I tested with do not have the same structure as client-generated keys. The new kind have a shorter private key length. You might think they have fewer bits of entropy, but the client-generated keys (in DER/wallet form) have long strings of all 1's and other common subsequences. I have not figured out why.
OpenSSL-encoded private keys have a lot of redundancy, they store the field and curve parameters, the secret parameter and the public key, some of which have several possible encodings (eg. compact public key or not). What you should check is whether the public key - exported by OpenSSL - is identical to the public key bitcoin extracts after importing the OpenSSL-encoded private key. |
|
|
|
|
These are nice ideas. Cleaner messages and dialogs are always an improvement, and the ability to inspect a transaction before sending it is really needed, i believe.
I'm not sure yet how fee calculation and prioritization should be done in the future, it's certainly good to allow users to force a particular fee when sending (after enough warning).
|
|
|
|
|
Which version are you using?
|
|
|
|
|
In bitcoin 0.4.0, the minimum fee (for transactions that require one, per default policy) will be lowered to 0.0005.
Yes, fees go to the miner who puts your transaction into the block chain.
|
|
|
|
|
That looks like a hex-encoded block header, including padding done by the sha256 hasher.
Take the first 160 characters of it (80 bytes), decode each group of 2 characters as a hex to a byte, and feed those 80 bytes to a regular sha256 hasher, twice. That should give you the block's id.
|
|
|
|
|
The key pool was introduced in 0.3.14
Restoring of a wallet backup is supported since 0.3.20 with -rescan, in earlier versions you had to remove the block database and redownload it.
Since 0.3.21, -rescan is done automatically.
|
|
|
|
|
Miners receive the header, which contains: version number, previous block's hash, merkle root, timestamp, difficulty, nonce
This information is assembled by the bitcoin client they connect to, or the pool, and miners don't care what's in there.
The only thing they do, is try different values for nonce (knowing which bytes in the header constitute the nonce), and possibly the time stamp.
|
|
|
|
|
The only actions that require fresh keys from the pool, are change sent back when sending a payment, and generations (mining). You can do at least 100 such actions before a new backup is required.
|
|
|
|
|
When two successor blocks B1 and B2 are generated simultaneously for a single block A, part of the network will receive B1 first, and another part B2. Both will assume the one they saw first will win, and work with that. However, if B1 is extended first with a successor block C, while B2 isn't extended yet, all nodes that were working with B2 will realize the chain containing B1 is better now (as it longer, not because they individual blocks in it are better), and switch to A->B1->C as best chain.
|
|
|
|
|
Blocks count proportional to their difficulty, i.e. the fraction of the target they had to beat - not the actual fraction of it they reached.
There is no way to have a better solution for a given block when one is already created, as the difficulty is fixed.
Only when doing a multi-block attack crossing a retarget boundary (height multiple of 2016), one can influence the effect of the retarget, and thereby the difficulty.
|
|
|
|
I know bitcoin mining is like a lottery - any hash has the same chance of winning a block. But the only way transactions are confirmed is by someone winning a block so that the transactions get added to the chain. At 2M hashes/sec, I can expect to get a block something like every 15 to 30 years at a difficulty of 434883. I am not confirming transactions. I am not winning blocks. Am I contributing anything to the bitcoin network in some other way? I was using a GPU miner (only 20M hashes/sec) in a pool for about 6 weeks and decided it was not worth the heat on the GPU. I like the idea of bitcoin and would be glad to keep the client mining if I thought it was doing anything at all to support the bitcoin concept.
You always contribute a bit, by verifying transactions - you don't need to mine for that. Considering mining itself, IF you don't ever find a block, you haven't contributed anything. But you don't know you won't. If you have 2 Mhash/s, you have 3% chance of finding a block the next year - statistically speaking, you're contributing an expected 0.03 block per year (slightly more, even). It's up to you to decide whether that's worth it. For me, it wouldn't. |
|
|
|
|
In 0.3.22rc5 a bug was introduced that may cause this problem. Please try an earlier version, and use -rescan.
|
|
|
|
|
Show Posts
