I didn't see a cancel button there.
Couldn't a client just send a burst of small transactions in order to avoid the transaction fee? If/when 0.01 BTCs become valuable, then the charge might also be something to adjust.
There's no cancel button because the person doesn't have enough funds to pay the transaction fee. When there are already 80 kilobytes of transactions in a block, further transactions get only 3 kilobytes of free transactions. But I don't think the current implementation actually accounts for this when sending, so transactions over 3KB would get rejected and would have to wait for the next block. In any case, the total size of all transactions is capped at either 100KB or 200KB (not sure which), and any transactions beyond that will have to wait for the next block. It's pretty harmless to adjust transaction fee stuff, which is probably why the terms are not too well-defined right now. I am not too familiar with the source code (just did a bit of browsing), so I could be wrong about this stuff. |
|
|
|
that's not really what I'm afraid of, but thats an issue too.
hmm, but still, in theory, it would be possible for someone with physical access to your RAM to read my password, wouldn't it ?
If an attacker had that much access, he could modify the login page to remove the password-hashing JavaScript. |
|
|
|
It's based on data size. The first 60 kilobytes are free, and it's (around?) 0.01 BTC per kilobyte after that. Data size is increased when sending the transaction requires that you draw Bitcoins from many different sources. In the image below (from someone on IRC), 0.01 BTC was sent back and forth until their balance was made mostly of these "cents". Then, when they tried to send the entire balance, 1/8th of their transaction was required as a fee because combining all of these transactions took up so much data.  Transaction fees are at line 525 in main.h. |
|
|
|
afaik you can get the transaction fees even if you are not generating coins at all.
Nope. You only get them when you publish a block. It's added to the 50 BTC created from nothing. |
|
|
|
Currently, Bitcoins are stored as a 64-bit integer. The number of Bitcoins is multiplied by 100000000 to give eight decimals of precision. Exactly where the decimal point is placed in this large number is completely up the UI, so this can be easily changed. Extending this precision (by turning it into a 128-bit integer or whatever) is possible, but all clients that did this would be incompatible with old clients. It could be changed gradually in the same way SHA-256 could be: If the hash breakdown came gradually, we could transition to a new hash in an orderly way. The software would be programmed to start using a new hash after a certain block number. Everyone would have to upgrade by that time. The software could save the new hash of all the old blocks to make sure a different block with the same old hash can't be used. http://bitcointalk.org/index.php?topic=191.msg1585#msg1585 |
|
|
|
|
dete: You are losing the private keys in the case. Almost every time you send coins, you're also sending some coins back to yourself, to a brand new keypair. Since this new private key is not in the backup, you lose the coins.
|
|
|
|
|
Why would I use Mt. Gox instead of BitCoin Market?
|
|
|
|
This is how I do probability per hash: $hash=$hextarget;
$hash=strtoupper($hash);
$probability=`echo "obase=10;ibase=16;scale=37;$hash/FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF |bc`; (The tickmarks execute the command on the shell.) Then you do 1/$probability to get average number of hashes. Divide this by the number of hashes you're getting per second to get the number of seconds. You can calculate the target like this: 26959535291011309493156476344723991336010898738574164086137773096960/difficulty "Difficulty" is the number returned by getDifficulty. (The huge number is the maximum target, which getDifficulty is based on.) This calculation is not exact. I search debug.log to get the target, but the result of the last retarget seems to be less accurate than the calculation above. I'm not sure why this is. Maybe the code changed. (Edit: I now think that this is just an artifact from the "nBits" decompression.) |
|
|
|
1)I understand that 21,000,000 coins is the maximum. How many total blocks will this be, given the logarithmic decrease of coins/block when we hit the 21M?
Somewhere around block 5,355,000 (this will be sometime around 2111 at 6 blocks an hour.) I expect many things will have changed by then though. The last block that will generate coins will be block #6,929,999. Then the total number of coins in circulation will remain static at 20999999.9769. I've created some future-proof calculators for this: http://theymos.ath.cx:64150/q/bcperblock/6929999http://theymos.ath.cx:64150/q/totalbc/6929999(Change 6929999 to whatever number you want, or leave it out for the current number of blocks. |
|
|
|
|
Try "bitcoin -?" for a list.
|
|
|
|
Could someone make a graph of all the coin values ever awarded, their path through the system, and their current holder? Something like http://www.wheresgeorge.com/ but on the whole economy? I'm going to do that. It will be a website that will allow you to see inside of blocks and trace transaction histories. I think I know how to do everything required, so you might see it somewhat soon. What information is private? I suppose aggregation of multiple Bitcoin Addresses (a person, for example) is inscrutable. Yes. You can get the "top 10 most valuable BitCoin addresses", but not the "top 10 richest users" But could someone, conceivably, state with accuracy how much money has been donated to Bitfountain's posted address? You can see it exactly if the address doesn't change. |
|
|
|
|
There's another page somewhere where you can add addresses, which will then appear in that list.
|
|
|
|
|
PKCS #5 is used by TrueCrypt (and GPG, I think). If each iteration reduced the difficulty of finding collisions, as bdonlan suggests, then TrueCrypt would be easy to break. You'd just attack the hashing algorithm to find the master key.
|
|
|
|
I have no doubt that hashing multiple times is secure, since it is specified in PKCS #5 and other standards: An iteration count has traditionally served the purpose of increasing the cost of producing keys from a password, thereby also increasing the difficulty of attack. For the methods in this document, a minimum of 1000 iterations is recommended. This will increase the cost of exhaustive search for passwords significantly, without a noticeable impact in the cost of deriving individual keys. |
|
|
|
Don't use 8080. Freenet Message System uses that port by default (on localhost), and I expect that there are a lot of FMS users here. It's also a registered port. I suggest using a port that isn't listed here. |
|
|
|
|
If it really becomes an issue (which I really doubt), the client can be updated to support more precision. Everyone would need to update, but it should be possible to switch to the new system smoothly and gradually.
|
|
|
|
Is each "khash/sec" a whole attempt, or each single cycle through SHA256?
It's a whole attempt. |
|
|
|
|
You're trying to solve:
SHA256(SHA256(d'))==256-bit number
This still has 256 bits of security, and you have to do two hashes per attempt to brute-force it.
|
|
|
|
|
Show Posts
