|
You need on average 4295*difficulty Mhash before you generate a block (with a reward of 50 BTC, currently). At 260Mhash/s, that means approximately once a month. You're better off mining in a pool which such a hashrate, where you get much more frequent but smaller payouts.
|
|
|
|
|
Only the windows video drivers require a monitor to be plugged in. On other systems you're fine.
|
|
|
|
|
I believe that up to 0.3.19 -daemon was the default behaviour for bitcoind.
|
|
|
|
You know what this thing would be awesome for? Gift cards.
If you need to give someone, say, 5 BTC as a birthday gift, you:
- Generate public/private key pair
- Transfer 5 BTC to that pair
- Export (possibly with delete) the key from wallet
- Convert exported key to a QR code
- print the code on a postcard
I know, it's kinda geeky, but it could be awesome way to both give something of value, as well as get more people familiar with bitcoin
See jgarzic's scratchoff patch: http://bitcointalk.org/index.php?topic=4555.0 and BitBills http://bitcointalk.org/index.php?topic=7724.0. |
|
|
|
I have to disappoint you, but the bitcoin blockchain is not even intended to be a permanent storage device of financial transactions, let alone arbitrary data. The current implementation indeed lacks the ability to prune obsolete parts of the chain, but this won't remain the case. At this point, it's hard to guarantee that 0-txouts won't be pruned. [mike] explained in http://bitcointalk.org/index.php?topic=7219.0 why the block chain is not meant for arbitrary data storage, and showed an alternative for linking other chains to it, with almost no overhead. For a network that was designed as an anonymous data-storage system, see http://freenetproject.org/. |
|
|
|
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 The private key format is analoguous to the address format. It is a 51-character base58-encoded string, that includes a version number and a checksum. The wallet format is JSON-based, and includes: * addresses (informational, optional) * private keys * amounts and balances per address (informational, optional) * blocks where addresses were first used (optional) * ids of transactions in which addresses were credited (optional) * labels (optional) It specifically does not contain: * sender address book * settings * account information * unconfirmed wallet transactions I will post a full specification of the dump file format soon. Earlier posts: * Hal's challenge: http://bitcointalk.org/index.php?topic=3638.0* Early discussion of dump format: http://bitcointalk.org/index.php?topic=4448.0* Early patch with only private key export and import: http://bitcointalk.org/index.php?topic=3906.0 |
|
|
|
|
Do you have proof that the centralized server infrastructure is running the code they claim they are using?
|
|
|
|
|
This is a planned feature for 0.4.0.
|
|
|
|
|
Hello,
one of the aspects of the cost for the bitcoin network of a transaction, which is currently not taken into account in the default fee policy, is the permanent storage cost it requires. The size of a transaction is used, but not whether or not it will ever be possible to prune it from the chain.
It is possible to compensate for this, by giving a "bonus" for the redeeming of earlier txouts. If a transaction is large, but has a lot of 0.01 BTC inputs, and one big 10 BTC output, its cost for the network may actually be negative, since it may allow many older tx's to be pruned in the future.
Idea 1
Use a term A*(nTxOut - nTxIn) in the fee calculation.
This simply gives a bonus to transactions that merge a lot of coins, and a malus to transactions that split a lot of coins.
Idea 2
Do some weighing based on the value of the produced/consumed txout's, as small coins are worse for the network than large ones.
Use a term B*(sum(2log(21M/txout.amount),txout in tx.outputs) - sum(2log(21M/txin.amount),txin in tx.inputs)) in the fee calculation.
Essentially, we define a "weight" to each coin (=unredeemed txout), defined as the 2log of its fraction of the maximum amount. A 1 BTC coin would weigh 24.32, 1 ucBTC would weigh 50.90.
Splitting off 0.01 BTC from a 1 BTC coin, would increase the total weight of coins with 30.98, merging 100 coins of 0.01 BTC into a 1 BTC coin decreases the weight by 3072.45.
Idea 3
Use the actual sizes in the calculation.
Use a term (tx.size - C*sum(txin.prevout.tx.size/txin.prevout.tx.outputs.count, txin in tx.inputs)) instead of the normal per-size fee.
Essentially, we subtract a fraction of the size of all the prevout tx's from the current one. C should be between 0 and 1. C=0 is the current scheme, with C=1 a simple transfer-entirely transaction in a chain typically becomes costless (at least what its size concerns, there may and maybe should be other fee factors).
|
|
|
|
|
By the way, Hal, do you have any specific comments about the scheme, or the key sizes used?
|
|
|
|
Hm. I disagree. As I stated above, if I were a properly implementing merchant, my bitcoin node would simply watch for new transactions to my addresses and never spend those coins. Hence it should have no knowledge of the password (as your suggestion allows). However, if I were implementing properly, no one would have write access in any way to my bitcoin binary (or any other binary on my system for that matter). If someone were to be able to run code on my machine under the bitcoin user, they would only have access to writing to the wallet.dat which helps them none, because they don't get my coins, and I have a backup of my wallet.dat which is read-only.
Of course, there are various stages of write access an attacker may get. Addr.dat and wallet.dat while stored on offline media would be a first step, write access to the binary a last one. I guess what I was trying to say is that once one gets some write access, all kinds of things are possible, and those may be not realistic to defend against. What we're trying to solve here, is that if an attacker only has read access to wallet.dat, he cannot spend your coins. To a limited extent, it can try to minimize leaking of keys into swap/memory dumps, but that's already harder to guarantee. |
|
|
|
|
I was specifically trying to avoid the necessity of needing to enter a password for normal operation, except for sending
transactions. Of course, there is another option for those who are more paranoid, and guarantee that the private keys
cannot be tampered with without knowing some (possibly different) password, by using a scheme such as Hal suggests.
However, as soon as an attacker has write access to your wallet.dat (or other files), he can do a lot more, such as overwriting known addresses, giving you a fake block chain (not sure how viable that is), or even overwriting the bitcoin binary. As such, I'm not sure how realistic it is to protect against that scenario.
|
|
|
|
|
First of all, sorry this idea is only formed after a working encryption patch was already developed, but I believe the following scheme would be perfect for encryption of wallets.
There is one wallet-wide master key, itself symmetrically encrypted (aes-cbc-256) with a passphrase. We use public-key encryption here, to allow encryption of wallet privkeys without knowledge of the passphrase, while requiring a passphrase for decrypting them.
The only place in the source where the actual private keys are needed, is while signing. This means only for that operation the passphrase would be required. New keys can be generated and stored without passphrase.
It may not make sense cryptographically, but since N-bit EC cryptography only offers N/2 bits of security, I would suggest using a stronger curve than secp256k1 ("only" 128 bits of security) - let's say secp384r1 - for the master encryption.
Thus, for the whole wallet a master secp384r1 keypair must be stored - the pubkey unencrypted, the privkey encrypted. When using point compression and only storing the private parameter itself, that requires 49 bytes + 48 bytes per passphrase.
Each walletkey then, will be encrypted using a separate 256-bit AES key derived using ECDH from the master key and a per-walletkey ephemeral secp384r1 key (=EC-IES). As IV a hash of the pubkey can be used. Since we're upgrading the wallet format anyway, we can immediately switch to only storing the private parameter of the wallet privkey (32 bytes) instead of the full openssl-encoded form (279 bytes). We will need to add the pubkey part of the ephemeral key though, adding 49 bytes (when using point compression). Hence, encrypted wallet privkeys can be stored using 81 bytes per key.
Advantages:
* keys can be generated and stored in encrypted form without knowing the passphrase
* multiple passphrases can be present in a single wallet (by storing the private master key more than once)
* changing a passphrase is trivial
* private keys can remain encrypted in memory, decrypting them only when creating a transaction
* when combined with switching to a more efficient representation of private keys and using point compression, storage/memory requirements for private keys still go down a factor 3
Questions:
* Is it cryptographically sound?
* Does it make sense to use a larger EC curve for the master key / encryption of privkeys themselves?
* Is using point compression an option? I heard there are patents on it, but it is implemented in OpenSSL. If not, the master key will require 97 bytes + 48 bytes per passphrase, and wallet privkeys will require 129 bytes.
|
|
|
|
If you don't like this model, you're free to start again with your own block chain.  Don't worry, I have no such intention |
|
|
|
PS. I predict that people will complain that the areas under the graphs for the current scheme and the new scheme do not look equal.
The areas will be equal on a graph with a linear scale. Does your algorithm easily handle increases in precision like the current system does?
It is quite specifically tuned for 64-bit integer arithmetic to reach 21M. Nothing of course prevents one from introducing a new algorithm at the time a precision increase is introduced as well, along the lines of "if (blocknum < 3000000) { ...; ret *= 100000000; } else { ... }". The construction of the algorithm can be more or less automated once the function to match is known. I don't like that the end state would be changed. People signed up for particular rules. The end total BTC is very similar, but 132 years -> 93 years is significant.
Good point. I've tried finding a different function that mimicks the end behaviour better, but it's quite hard, and probably not worth it anyway. The concern over the transition is that there will be a sudden fall in network security as miners drop out, which would shake confidence in the system. But I'm not sure a slow steady decline can ever be achieved. The 50->25 transition is going to feel a bit like a bubble bursting, and that's OK. There will be sudden drops in hash power due to exchange rate bubbles over time even if the general trend is positive. So we'll have to handle wild fluctuations in difficulty anyway as BTC/USD moves in response to external events.
You're probably right. I wanted to show that it is quite possible to implement a nice exponential decrease, and somehow show my regret it wasn't in the original system. While I too don't like the sudden halving of the reward it is a pretty nice and simple algorithm. What is especially nice about it is that the reward from the coinbase (generated coins) never really reaches 0, so miners will not have to rely completely on fees.
Given the limited divisibility of bitcoin, this is not entirely true. In the current scheme, the reward becomes 0 after block 6929999. In my proposed scheme, it becomes 0 after block 4899870. "The perfect is the enemy of the good".
Indeed, but sometimes it's hard to see in advance whether it's good enough or not. |
|
|
|
|
Bitcoin does indeed require some trust, as every trade does; if you pay someone for something, you still need to receive what you've paid for.
However, bitcoin does *not* require trust that the other party will store his coins securely. If he doesn't, they may be stolen, lost or scammed, but that is his problem.
|
|
|
|
One question that often arises is what will happen when the block reward goes from 50 BTC to 25 BTC. I assume that after some temporary disturbances, a new mining equilibrium will be reached. I'm not sure what those disturbances will be though, or whether they are beneficial to bitcoin as a whole. Here is a wild proposal: after block 209999, we replace the block reward function with an approximated exponential, such that the reward in 210000 is still close to 50 BTC, and sum of all rewards ever still tends to (and doesn't reach) 21M BTC. Since we keep a higher reward (near 50 BTC) for longer, this will need to be compensated later. This results in a somewhat faster convergence towards 21M, with a halving of the reward every 145561 blocks (instead of 210000). Here is a C function that computes rewards whose sum reaches 20999999.99999336 at block 4899870 (the current system reaches 20999999.9769 at block 6929999). It only uses 64-bit integer arithmetic and is quite fast. static const int64_t coef[11]=
{ 419991, 630002, 840000, 1050003,
1260003, 1470003, 1680004, 1890005,
2100005, 2310005, 2520006};
uint64_t reward(int blocknum) {
int64_t ret = 5000000000ULL;
if (blocknum<210000) return ret;
blocknum -= 210000;
int shift = blocknum/145561;
blocknum %= 145561;
int64_t m = (blocknum*2380982516ULL)/100000;
ret -= m;
for (int i=0; i<11; i++) {
m = (-m*blocknum)/coef[i];
if (!m) break;
ret -= m;
}
return (ret>>shift);
}
The resulting reward is shown here:  The resulting distance from the target amount in circulation (21M BTC) is shown here:  With some tuning I'm sure it's possible to have it go to its final value somewhat smoother. So, questions: * Do you think a continuous decrease of the block reward is better? * Is it worth breaking backward compatibility for? * Does anyone know a nicer function than A*exp(B*x) that could be fitted to better match the existing reward? |
|
|
|
|
The way inputs are selected changed somewhat in 0.3.21. Before, either all or none of the outputs of a particular transaction were used, and the client had no concept of a particular output being used already or not.
I don't understand what can cause the symptoms you describe, but could you try with 0.3.21?
|
|
|
|
|
Which version of the client are you using?
|
|
|
|
|
Show Posts
