|
Bitcoin internally does not use balances or wallets.
Each transaction explicitly refers to the previous transactions whose outputs it consumes. Think of it as coins: each unredeemed transaction output is a coin from the view of the system, and transactions consume coins, melt them together, and produce new coins from them.
On top of this, there is an authentication system: coins may be assigned to a particular address (or more generally, a script), whose owner is allowed to spend them. Consuming coins requires presenting proof of ownership of a private key associated with the address (which is a hash of the corresponding public key).
It is only client software that manages things like balances, which is just the sum of available coins to the private keys you have.
|
|
|
|
When I downloaded the blockchain for the first time yesterday with bitcoin-qt, I noticed my hard disk making a lot of noise. iostat showed that it was mostly writes. strace showed that there were many writev(2)s occurring, presumably due to checkpointing / flushing / syncing the database. Shouldn't it be possible to use a log structured on-disk format, or just to do transactions such that things only need to be written out every few minutes?
Berkleley DB is log-structured. During normal operation, it writes the effects of database transactions into log files, and when these log files exceed a given size or age (see the -dblogsize command-line option), they are committed to the database. The problem is that many parts of the current block chain index are overwritten many many times, so the total amount of log files to write is much more than the actual resulting database size. LevelDB already helps here, by moving the log-flush code to a separate thread. "Ultraprune" (basically a rewrite of the block validation logic that uses a pruned set of transaction outputs as main database, instead of an index of all transactions ever) will reduce the amount of data to be written significantly. |
|
|
|
|
The upcoming 0.7 release of bitcoind adds a "getrawtransaction" RPC that queries the blockchain instead of the wallet.
|
|
|
|
You mention that an IV is not used but the first block of AES needs to be initialised with *something*. I suggest you explicitly specify 16 bytes of 0x00 to pin down the spec.
I think you're talking about AES in CBC mode, which indeed needs an initialization vector. AES the block cipher itself doesn't, and may be what casascius meant. Regarding the key derivation: just using SHA256(passphrase) will expose the addresses in the blockchain to a relatively easy brute-force attack (bound by just an EC multiplication, a SHA256 round and a RIPEMD160 round). |
|
|
|
|
You expect people to trust this, if they have to upload their private keys to you?
|
|
|
|
For example, bitcoin doesn't prove, or even attempt to fully prove that a block is final, but as more blocks pile up, we can become increasingly confident that it won't be overruled. But never totally sure, because every block back to the last checkpoint in theory could be replaced if a better chain is found tomorrow.
That is exactly his point. Bitcoin is based on more weaker assumptions that what is commonly researched, and so it indeed cannot solve the Byzantine Generals problem. It can however reach something called stabilizing consensus, and that can also be researched and quantified. |
|
|
|
If you're really stuck, I'd very much like to have a look at it. But make sure: - You're not out of disk space
- You are really connected to some other peers
- Your internet connection is stable
- You are really stuck, and this does not change after letting the client be connected for let's say an hour
|
|
|
|
Could you: - Turn on detachdb (start with -detachdb, or check the relevant option in Bitcoin-Qt)
- Shutdown bitcoin
- Make a backup of your entire datadir, excluding the wallet
- Make that backup available somewhere, where I can access it
? We've been hearing reports like this for a while now, but never able to actually see the problem occurring or reproducing it ourself. |
|
|
|
OK, thanks for helping me to understand about the propagation part of it. So what you are saying is that such messages are being shuffled around in limbo via the P2P network, but don't touch the blockchain ever?
Exactly. |
|
|
|
so if gavin gave the CIA that key. then the cia could corrupt the blockchain whenever they want? or at least make a malicious bitcoin client "update"
No. The only thing that this key can do is signing an alert message that propagates through the network. Satoshi, Gavin and theymos have this key, IIRC. |
|
|
|
LOL. I believe that the country Satoshi lives in, should adopt bitcoin first, because he probably has most bitcoins.
Which country is that? Atlantis. |
|
|
|
|
Bitcoin transactions do not have a well-defined 'from' address.
Every transactions consumes some coins, combines them, splits them again in new coins, and assigns a rule about who can spend those new coins. Those rules can (but do not necessarily) correspond to an address.
It is possible to look up the coins consumed by a transaction, and check which addresses those were assigned to, though.
There is no guarantee that there is just one, there is no guarantee that there is one at all, and there is also no guarantee that sending something to those addresses will end up at the sender of the original transaction.
If you need a refund address for a transaction, the best practice is to just ask for a refund address from the customer/peer/...
|
|
|
|
|
I believe in almost all places of the world, vulcanos/earthquakes/other tectonic activity, rarely causes changes more than centimers per year.
Also, you don't need perfect accuracy; you can still have the system attempt coordinates in an area wider and wider around the chosen location. Using a coordinate with accuracy 1m, and using areas of 30m in size seems quite reasonable, and requires only trying a 1000 coordinates.
Seems like a nice idea, using this as entropy.
|
|
|
|
|
I believe a relatively easy solution would be allowing to delete an address, but not deleting its key (so that it becomes identical to a change address).
|
|
|
|
Know what you're pledging for. The basis of etotheipi's proposal is not pruning itself, as that was already described by Satoshi in his paper. It is about the ability to have a pruned node serve light clients with the same security guarantee as an SPV client (like BitcoinJ; trust the longest chain). Implementing this consists several parts, and some of them are useful by themselves: - Having fully validating nodes that explicitly maintain a pruned txout set
- ... and also keeps that set indexed per-address
- ... and maintain a merkle tree for that (or other authenticated data structure)
- ... and commit the merkle root of that in the coinbase (miners putting it there, other nodes verifying it)
- Having light nodes designed to use that information
(Alan, if you're reading this, please correct me if i'm wrong or missing something) I'm currently myself working on the first step in the reference client. It will speed up block validation, and allow (optional) pruning of old blocks. |
|
|
|
Bumping this old thread because I noticed that I still have a wallet.dat.rewrite in my data directory, even though I'm now on 0.6.3...
What exactly does this file contain? If it's true that it contains unencrypted private keys, then it is quite dangerous to leave it lying around.
If you don't delete the file, it will remain there. What happens is that when you encrypt your wallet, a new encrypted version of the wallet is written to wallet.dat.rewrite. Then the old one is closed, and the rewrite is renamed to wallet.dat. If for any reason that rename fails, the rewrite file stays there. This file does not contain unencrypted private keys, ever. |
|
|
|
Each time you do an iteration, you LOSE entropy. This is unavoidable, and the reason why we have algorithms like PBKDF2 using SHA256 HMAC.
That is why you use a hashing algorithm with more bits than the output. Use SHA512, and eventually (after all iterations), truncate the output to 256 bits. For any number of iterations computable using all available energy on earth, the loss in entropy will be negligable. |
|
|
|
I like it. Still 256 is probably too small. Modifying the algorithm so the min passphrase is say 2,000 iterations and the average passphrase is closer to 10,000 iterations would be better. Also I think we should move away from SHA-256. With all the OpenCL, FPGA, and soon ASIC hitting the market for massively acceleration SHA-256 hashing using a chained function of an algorithm already massively accelerated seems like steps forward, one step back. Even SHA-512 would be better. Something like bcrypt would be even better.
It is using SHA512; I prefer not to use SHA256 as the Bitcoin world already has way too much power for cracking that. Also, generating a 256-iteration/8-bit key requires 65536 iterations on average (both for you and for an attacker, except the attacker doesn't know you're only using a 256/8 key). |
|
|
|
|
Show Posts
