The difficulty is based on the *minimum* target, and this target is generated rather inexactly as 00000000ffff000000000000000... (eight 0s, four Fs, 0 to taste  ) No. That target (which I included in decimal in my second formula) is the maximum allowed target. The target is lowered to increase difficulty. The highest target is the lowest difficulty. This is because the probability of winning with one hash is target/ max. Reducing target reduces the probability of winning. |
|
|
|
Generation never "stops" - the number of coins generated gets halved every 210,240 blocks (4 years). It will take somewhere around 17.5 years from block 0 to generate 20 million coins. The next 1.024 million will never be completely generated. Generation won't "stop" until the number of coins generated per block is less than 10^-8 (minimum precision of Bitcoin). That will happen somewhere around block 6.76*10^6, or roughly 130years in the future.
Bitcoin has a Merkle Tree implementation that allows old block transactions to be purged or something like that. Read the design paper, it's all a little above my head.
Besides, in 10 years our phones will all have a terabyte of storage and our desktops will have god knows how much.
It will stop. The halving is done as a bitwise right shift instead of division, so the number of coins awarded will eventually be 0. Block #6,929,999 will be the last one to produce coins. This should happen around 2140. |
|
|
|
Is the bitcoin address a SHA-1 hash of the public key? or perhaps some other 160 bit hash? and why is it a 34 character string instead of say the more common 32 char 5 bit representation?
It's a RIPEMD-160 hash of the SHA-256 hash of the public key. It also contains version information and a check code. |
|
|
|
|
Yes. But make sure you stop BitCoin before doing that.
|
|
|
|
How long does Wikipedia typically leave a question like that open for comment? 7 days from the listing (so pretty soon). More if the closing administrator doesn't feel that a consensus has been reached. I doubt the article will survive the AfD, but it will be easy to recreate once it appears in a real news source. |
|
|
|
With Pecunix, you have to set a name which doesn't have to be your real name and can easily be changed. It is displayed when sending or receiving payments. Liberty Reserve does that, too. The receiver can also see the sender's account number unless the sender paid extra for privacy protection. |
|
|
|
- Atlas
- BitcoinFX
- BrightAnarchist
- _DarK_
- Diablo-D3
- Keefe
- Kiba
- NewLibertyStandard
- OneFixt
- Xunie
- c3e0a4636987bcc7152e6b8b9127c4fe (PayPal MD5)
- dwdollar (Bitcoin Market)
- grondilu
- jgarzik (Bitcoin Store)
- mtgox
- nanotube
- sturles
- xxmalouinxx
People listed in bold had the opportunity to scam me for a large amount of money. |
|
|
|
|
In the future you could pay an additional voluntary fee for your transactions to get priority, but this isn't implemented now (in either generating or sending, I think). Also, the max block size isn't a "hard limit", just an arbitrary number that will be changed in the future.
|
|
|
|
You must use HTTPS. Connections to port 80 are dropped. I think this is the source of most peoples' problems -- BitCoin Market is almost always up for me. https://www.bitcoinmarket.com/ |
|
|
|
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.) |
|
|
|
|
Show Posts
