I haven't tested it, but the latest OSX binary listed on http://bitcoin.org is version 0.4.0, which should support wallet encryption. |
|
|
|
|
For each txout script encountered in the stored block chain, a test is done to verify whether our wallet is able to provide a matching txin script, or uses such a script as input. If so, it is added to the wallet.
|
|
|
|
I am pretty sure the client only sends change to addresses pulled in from the 'reserve' pool, not imported keys.
Correct, though the "importwallet" command has a function to import a key into the reserve pool. |
|
|
|
Is there some way to import a new key into an encrypted wallet?
I used to use pywallet but I'd expect that it can no longer support "--importprivkey" now.
Is there an json-rpc for importing a key? How would that be done?
There will be soon, most likely. |
|
|
|
|
There is no reason to make a single step slow, if you have a target difficulty which filters any requested percentage out.
The only reason is because 128 rounds of hashing may remain safe somewhat longer, in case a preimage attack against 64-round SHA256 is found.
|
|
|
|
Super Excellent!
What is the encryption method/algorithm used?
dynamic iterated SHA512 hashing to derive a password key, AES256-CBC using the password key to encrypt a master key, AES256-CBC using the master key to encrypt the wallet keys. Since the DB format has been updated how will that affect blockchain archives? Will there have to be two versions or will downloading an older version still work fine? I guess it auto-converts if it sees an older version DB?
The wallet format changed to support encrypted keys, the blockchain database format didn't. The binary is linked using bdb4.8 instead of bdb4.7 though, which will upgrade the database logs well, in a backward-incompatible way. |
|
|
|
|
Yes, you can easily change the code to modify the coin-introduction function.
However, if you did, all your blocks would be ignored by people that use the original client, and more importably, you'd ignore theirs, effectively separating you in a different network with all those who run your modified client.
What guarantees are there that the supply will be limited? The fact that the community has agreed on accepting bitcoin's rules, which dictate how many coins are introduced.
|
|
|
|
first off: congrats and thanks for the hard work to the devs.
A question:
How does using rpc call "sendtoaddress" work with an encrypted wallet?
From the point of RPC, the wallet is either in "locked" or "unlocked" state. You can use the "walletpassphrase" RPC call to unlock it for a limited time. Sendtoaddress and some other commands will fail if the wallet is locked. |
|
|
|
|
The "change is too small to go to wallet, let's send it to the miner" thing on itself wasn't a bug.
The problem was that 0.3.24 reintroduced a bug where that calculation went wrong, and occasionally up to 0.01 BTC would be sent as fee (instead of 0.0005 BTC). It's fixed in 0.4, by the way.
|
|
|
|
Should there be a method in the API like "checksendtransactionfees <address> <amount>" ?
Wouldn't work. The knapsack problem solver user to select coins is stochastic (uses rand()), therefore the coins selected from the wallet are really random for each call. You can probably propose a change where a rand() is replaced with some pseudo-random algorithm that seeds of some explicit value and therefore is 100% reproducible. That is not a problem really. The method i proposed could work the following way, by "preparing" the transaction: 1. Make the rand() and prepare the transaction + calculate fees 2. The transaction is stored in a "prepared" or "locked" state - all bitcoins from the transaction are locked, until the transaction is unlocked by user. 3. If the user likes the fees, he confirms the transaction, it becomes unlocked, and it is then relayed to the network. This shouldn't be extremely hard to implement. As I said, it already was implemented: https://github.com/TheBlueMatt/bitcoin/commit/5350a907a57b88bd86827c1f3e41b571cf130401. It seems to have been closed awaiting rebase... |
|
|
|
|
There will obviously be a need for communicating such outputs (either an address scheme, or out of band protocol, or ...), but that is independent from how those requirements get encoded in the block chain.
It is already possible to encode arbitrary boolean expressions over signature checks in scripts, given that they are allowed to pass the IsStandard() test. That sounds like a much better solution to me than trying to pack everything into the OP_CHECKSIG code: it breaks backward compatibility, and is far less flexible.
|
|
|
|
|
The solution is an out of band protocol to negotiate the transaction, instead of trying to pack everything into a static string (address, URI, ...).
|
|
|
|
|
There used to be a patch or pull request that added the ability to create a transaction for preview, i.e. not transmitting it yet to the network. This transaction could then be inspected, and afterwards either confirmed or aborted.
I very much liked that idea as a solution to the unknown-fees problem, but I can't find it anymore.
|
|
|
|
There's a large discussion around implementing boolean expressions over signature-verifications on github and the mailinglist already, and those work with the existing script languages without modifications. Does your proposal do anything beyond that? See https://github.com/bitcoin/bitcoin/pull/319 |
|
|
|
I avoided this here because key reconstruction from signatures depends on point compression, which is patented. I haven't looked into the patent itself, so it may not be applicable here, but for a simple signature string it may not matter that much. Anyway, the lack of distinction between wrong key and wrong signature is indeed to allow future extensibility with a signature format that uses key reconstruction.
Any other opinions about the use of key reconstruction? I have little respect for software patents, but I prefer avoiding potential legal trouble for bitcoin too.
After reading http://cr.yp.to/ecdh/patents.html I believe that patent is either invalid or not applicable, and point compression is implemented in OpenSSL, so I implemented it anyway. Current https://github.com/sipa/bitcoin/tree/signandverif now does message signing using compact signatures and key recovery: 88 base64 characters per signature. |
|
|
|
it's probably sensible to tolerate variation as much as possible.
In most practical situations I can imagine, the signature verification is likely to fail because the base-64 encoded string has become corrupted or truncated. Most instances of corruption or truncation can be quickly detected by a strict format base-64 decoder before performing the much slower signature verification. Also with little extra effort, we can tell if the base-64 encoding is malformed and we might as well report this fact to the user rather than throw the information away and amalgamate the two error conditions under the "verification failed" umbrella. Given that there is no other checksum mechanism in the signature strings, I agree here. I'll add strict checking. Also, I notice that the verifymessage doesn't help the user to distinguish between the signature failing because the address doesn't match the signature's public key and the ECDSA signature being invalid. I recall that one can infer the public key from a signature so we could shorten the signatures by 65 bytes or 87 base-64 characters by not bothering to encode the public key. This improvement would mean that checking the address matches the inferred public key would be the sole test of validity. I avoided this here because key reconstruction from signatures depends on point compression, which is patented. I haven't looked into the patent itself, so it may not be applicable here, but for a simple signature string it may not matter that much. Anyway, the lack of distinction between wrong key and wrong signature is indeed to allow future extensibility with a signature format that uses key reconstruction. Any other opinions about the use of key reconstruction? I have little respect for software patents, but I prefer avoiding potential legal trouble for bitcoin too. |
|
|
|
|
Private key import/export (which is ready for merging, but not yet in 0.4) is already rebased against wallet crypto, and will decrypt private keys on export, and encrypt them on import.
Also, backups work as before: even encrypted wallets contain reserve keys, and as long as you didn't use them all up, restoring a backup shouldn't be any problem.
|
|
|
|
|
Using the wallet encryption in upcoming version 0.4, this is possible: the client is fully functional without entering the password, except for doing transactions.
|
|
|
|
|
Show Posts
