|
Maybe you can ignore merges when counting number of commits, as these rarely contribute code themselves?
|
|
|
|
|
Again, coins are not moved between addresses. There is only one pool of coins the client chooses from, and it represents the entire wallet.
Accounts are only summaries, and have no connection to the actual addresses the available coins were last sent to (in fact, coins do not necessarily have an address they were last sent to).
|
|
|
|
|
Accounts have very little to do with addresses, they're just virtual balances. Move does not perform a transaction, it only increases the balance of one account and decreases another.
|
|
|
|
Gold supply increases exponentially,
Uhm there is only a finite amount of gold in the earth's crust... |
|
|
|
This has nothing to do with the current topic. I am not listening to you, until you explain what is the difference between bcrypt() and my func. Because i keep stating you have no fuckin idea what you are talking about. I dare you. Explain that to me. Still waiting. Also, about earlier post: Look at how easy this is: $hash = bcrypt_hash({
key_nul => 1,
cost => 8,
salt => $salt,
}, $password);
Look how easy this is: $hashedPassword = HashPassword::Make($password, 'LEVEL3 SALT', 2048); //Total of 6144 rounds
This will provide stronger hashing than bcrypt() with 12 rounds , as each round in bcrypt() is actually a power of 2 rounds (bcrypt(data, 12) gives you actually total 4096 small rounds if I am not mistaken) . The "strength" of the hashing is irrelevant (even an 80-bit hash function - used properly - cannot be bruteforced by the current bitcoin network in any reasonable time). The only thing that matters is how long it takes to try one key for an attacker. bcrypt and whatever iterated hashing you're using achieve this in a very different way, and it is hard to compare. It is true by the way that iterated hashing increases the chances for collisions, but only slightly. As explained in an earlier linked post, NIST recommends PBKDF2 for storing passwords, which is in fact based on salted iterated hashing. So please stop throwing insults to eachother. Yes, bcrypt() is a very good way for storing passwords, but so it a (well implemented) iterated hashing scheme. Iterated hashing schemes are better researched and used, but bcrypt() is somewhat slower to implement in hardware. If you really want maximal resistance to hardware-assisted attacks, scrypt() may be an even better choice, yet even more recent. |
|
|
|
Bcrypt means two things: a hashing algorithm and a file encryption utility, both of which are based on the blowfish algorithm. To encrypt passwords and want to prevent a stolen database from being hacked easily, you need a slowdown. If checking one password for correctness takes N times longer, it takes N times longer to crack as well. The intent is to make a single check as slow as you can bear. Schemes like iterated sha512 or pbkdf2 achieve this slowdown by hashing multiple times, bcrypt achieves it through a slow key scheduling step. Given that no preimage attack against the used hash function (sha1 on this forum and in pbkdf2, sha512 on mtgox) exist, I'd say they are equally safe if their verification step takes the same time. There exist attacks against sha1, but only collision attacks (which won't help you here) and theoretical preimage attacks (which don't really help much) The main advantage of bcrypt is that is slower to implement on hardware, but not so much anymore on modern hardware. A more recent password hashing system called scrypt was designed to overcome this, but is not very much used. Given that the bitcoin community has massive amounts of computation hardware, that may be the best choice. Sources: |
|
|
|
We're still printing them at a quarter million bitcoins a month, even if they are worth .00001 cent each.
If someone can logically answer why there is no mechanism to slow down the rate of printing then I want to hear it.
If you know of such a mechanism, which - can be enforced easily by each node (bitcoin's security system)
- does not depend on a centralized data source (exchange rate eg.)
- is not easily influenced by people who want to take advantage of it (eg. rate/size of transactions in the block chain)
then I want to hear it. |
|
|
|
|
Correct. The public key format is managed by OpenSSL, bitcoin treats it as a black box.
|
|
|
|
|
No, DER is used for signatures, but not for public keys. Several encodings of keys are possible (including patented compressed coordinates), but as Bitcoin depends (through the specification of addresses as ripemd160(sha256(pubkey))) on a normalized encoding, i think it is safe the 0x04 will always be there in the current generation of addresses.
|
|
|
|
See https://en.bitcoin.it/wiki/Accounts_explained. Accounts are virtual accounting tools, and their balance is not linked to any real coins. The sum of all account balances should equal your actual wallet balance though, and should never be negative. |
|
|
|
I would think they should be released a separately as the qt dependency changes the nature of the licenses being depended on, and a more free main branch would be preferable.
Qt is available under a commercial license, the LGPL, and the GPL. Can you elaborate on your concerns? It is just that. It would be the most restrictive license yet used for anything required. If this was brought in, anyone distributing binaries will also have to make available the source code to the Qt that they used for example or not bundle it. Wxwidgets made sure those conditions did not apply to derived works distributed in binary form. The creators of Qt got dragged a bit towards it even being as unrestricted as the LGPL in the beginning. I had noticed that the licenses picked so far are all much less restrictive and had thought that was a deliberate choice to keep the software free to more uses without the burdens of the GPL But the license of the bitcoin and bitcoin-qt code is still MIT, even though it links against an LGPL library. IANAL, but I believe this means that if you use the source to build a headless version (which doesn't link against Qt) there is no restriction on the distribution of the resulting binary. |
|
|
|
So since bitcoin is not money, does that mean that Tom Williams stole nothing at all?
So since jewelry is not money, does that mean that robbing a jewelry store means stealing nothing at all? |
|
|
|
Devil's advocate. Bitcoin is a currency. The issuer is the original miner who generated it. The only difference is that the issuers are distributed.
2. "electronic money" means electronically, including magnetically, stored monetary value as represented by a claim on the issuer which is issued on receipt of funds for the purpose of making payment transactions as defined in point 5 of Article 4 of Directive 2007/64/EC, and which is accepted by a natural or legal person other than the electronic money issuer;"
The issuer/central authority is a computer program/network, not the miner. You can argue about whether there is an issuer or not, but there is definitely no claim. Nobody - including the miner or the network - guarantee anything in return for a bitcoin (or a private key, seen as a certificate) except bitcoin itself. |
|
|
|
|
Thank you very much for this. I haven't had the time to go over everything in detail, but from what I've seen, it is correct and well researched. Please make sure this ends up on the wiki - people wanting to contribute need this kind of information.
|
|
|
|
|
Because RC stands for "release candidate"; it is NOT yet released. It's just a preview of the source code, so developers can hammer it and find bugs. You need a build environnement for that, and you shouldn't use it for production purposes unless you know what you are doing.
|
|
|
|
|
First of all, calling it "lost" bitcoin is a bit misleading; the problem is a occasional increase of the fee above what is expected, of at most 0.01 BTC. It occurs mostly when clearing out a wallet, and has indeed been fixed for 0.4.0.
Secondly, as 0.4.0 has not been released yet, there are no binaries to download. Yes, you could change those lines in 0.3.24, but even then you'll need to recompile it yourself.
If setting up a build environnement is too much work, just wait a bit longer until 0.4.0 is released.
|
|
|
|
|
Which code exactly are you compiling? The current git head compiles perfectly here on Ubuntu 10.10.
|
|
|
|
|
What about persistently storing the last block number at which the client was in sync with the network? Initially this is zero, and it remains zero until the client is entirely up-to-date. If at that point it goes offline, and comes back after having missed a few blocks, a new progress bar appears that represents the catching up from that previous point to the current blockchain tip.
|
|
|
|
The amount of time is irrelevant, it is the amount of blocks you know have made it onto the block chain that gives you confidence. Six confirmations is six confirmations, weather it took an hour or fifteen minutes. After six confirmations there is very little risk that your transaction is going to end up on an orphan block, and as long as difficulty is in balance you are not going to have blocks solved every few seconds.
To revert a part of the block chain, you need to do as much work (in terms of hashing power) as was done to create the part of the block chain you're trying to revert. It does not matter whether this corresponds to one or to one million blocks. The frequency of blocks has nothing to do with security - it is only a trade-off between convenience and frequency of stale blocks (caused by network latency). However, if you do not care about the security the block chain offers you (for example when you trust the sender not to try a double-spending attack), faster blocks are more useful. |
|
|
|
|
Show Posts
