|
Interesting idea. It'd probably be more counterfeit-proof than paper currency.
However, you could create a counterfeit card that does all of the signing and stuff, but when you try to withdraw the bitcoins, it deletes the private key. Whoever creates the card gets to trade it and keep the BTC it represents.
|
|
|
|
Backing up your wallet after every transaction is pure madness. Consider small marketplaces or "banks", that might receive several transactions per minute. If their server goes boom, the wallet and the backup might be both gone.
You don't have to back up after every transaction. You only have to back up every 100 sends or address creations. And if you set keypool=10000, you only have to back up every 10000 sends/keys. |
|
|
|
The pool maintainer makes all network decisions. If a pool has more than 50% of the network, the maintainer can double-spend. I see this as a good thing because it allows the network to adapt quickly. If the network is controlled by a few dozen people, software upgrades will happen within hours/days. Generators can change their code and have real effect before a new version is even released. The members of a pool will leave if they know that the maintainer is acting inappropriately, though this is more difficult to detect on slush's pool -- puddinpop's pool is better in this regard because the miners can see the block they are working on. He has about 9000 Gh/s. The entire network has 129 Gh/s. The pool has ~8 Gh/s. |
|
|
|
Doubtful, unless my computer tries to communicate with some new IP address when it has found a block and the firewall blocks that new IP. Is that the case? Or is some new program triggered when a block is found that an antivirus would block it? Hate to go another round for a few days, generate another winning block only to find that I once again have a communications failure of some sort and cannot claim the reward. hanks.
Bitcoin raises its priority and sends a bunch of identical data. This might seem suspicious to antivirus software. Try generating on the testnet and see if you get the same problem. My node didn't receive the block, either. |
|
|
|
socket recv error 10053
This sounds like a firewall/antivirus blocking Bitcoin. All of the other messages are normal. |
|
|
|
That block definitely failed to get into the chain for some reason.  Perhaps your network died for a while? Look at the logs between that section and the next SetBestChain message. |
|
|
|
|
If 00039d48 is part of the block hash, then the block didn't make it into the block chain, as a block with that hash doesn't exist. New blocks show up on BBE within 5 minutes, and they show up in your Bitcoin client after 1 additional block has been generated. Are you looking at the "all transactions" tab in the Bitcoin GUI? If you're using bitcoind, the block won't appear in your balance for 120 blocks.
Anything relevant in debug.log? Any "REORGANIZE" messages?
|
|
|
|
|
You could set up MyBitcoin accounts in certain denominations and sell the passwords.
|
|
|
|
It's not safe to do this. The "from" address could be some random MyBitcoin address. |
|
|
|
|
No, you don't have to turn it on. The time to generate a block varies widely -- don't worry if it's only a few days off.
|
|
|
|
If you get it from bitcoin.org, properly secured, than it's ok?
Maybe it's OK now, but your ISP could force you to download a modified version because Sourceforge doesn't support HTTPS. Or someone could infiltrate bitcoin.org/Sourceforge. Satoshi should sign the releases. The only really safe method is to keep a local version of the source, check the code changes for every release, and compile from that checked code. |
|
|
|
Is it easy to get old versions of Bitcoin?
You wouldn't want to. There have been changes that would tend to give your transactions lower priority. In particular, large transactions will take a long time to be accepted because the allowed size for free transactions has been decreased significantly and now network nodes won't relay transactions that they feel have too-low fees. It's an easy change to make in the source, though: if (!pcoin->IsFinal() || pcoin->fSpent) (Remove IsConfirmed()) return (SelectCoinsMinConf(nTargetValue, 1, 6, setCoinsRet) ||
SelectCoinsMinConf(nTargetValue, 1, 1, setCoinsRet) ||
SelectCoinsMinConf(nTargetValue, 0, 1, setCoinsRet))||
SelectCoinsMinConf(nTargetValue, 0, 0, setCoinsRet)); (Add a line that allows 0-confirmation coins) Transactions using coins with few confirmations have a low priority for generators. Make sure you keep lots of wallet backups if you do this -- you might end up having to double-spend your own invalid transaction. The best solution would be to change the sending priority. The client would first pick confirmed coins, since unconfirmed ones may remain like that for an indeterminate time. Maybe a warning message when there are only unconfirmed coins to be sent could be useful too. But completely blocking sounds "too authoritarian" to me... it's not up to the software to decide that. You can change the behavior, as above. That change will prioritize as you described. If I mine a block with my custom miner and accept to put <0,01 transactions in it, the default client won't refuse them, right? Right. That's the only way to do it right now -- I've not heard of any major miners accepting sub-cent transactions. Also, one doubt that I once had... can somebody else than the send of a transaction add fees to it? No. |
|
|
|
I seem to have misunderstood the generation process. I though it was only a matter of time but after reviewing some of the docs I noticed something about it being a race. Is that a race to generate the next block which restarts evertime someone generates the latest block?
No. There's only a race when two people create a block at the same time. It's not a "matter of time", either. Each second you have a certain small probability of generating a block. The probability is higher when you're using better hardware to generate. It's entirely possible that you'll never generate a block with just 2000 khash/s. |
|
|
|
I've never seen the Story of Cap and Trade, but their Story of Stuff was so full of economic errors that I couldn't finish it. I found it offensive that this was being shown to schoolchildren as some kind of education into economics and trade.
Yeah; I had to watch that for one of my college classes. It's the worst anti-capitalist propaganda I've ever seen. I can't believe anyone could agree with all of the nonsense in the video (though no one else in my class had any complaints). |
|
|
|
A lot of info on that page is wrong. The transactions are also sent in block messages. |
|
|
|
I have a question, why do you prefer Tor (or is there some vulnerability of i2p that you are aware of?)
I2P would be much easier to block than Tor if anyone cared about it. It uses a few "floodfill routers" to spread network information, so all you'd have to do to block I2P is keep track of the current floodfill routers and block them. |
|
|
|
So, it's not known yet what causes this error, and how to prevent it?
It's probably caused by the normal causes of file corruption: antivirus software, a failing disk, shutting down your computer improperly, etc. What are the other block database files you mentioned, which i should delete, even though Bitcoin seems to be working for now? Don't delete anything if it's working. The first thing you should try for all Bitcoin database problems is deleting everything in the data directory except wallet.dat, debug.log, and bitcoin.conf (if it exists). All of the other files can be safely regenerated. (Debug.log is not necessary, but it might be helpful to have it later.) If this problem happens repeatedly, and you're not getting errors in other programs, it could be a bug in Bitcoin. Post details in that case. |
|
|
|
(I guess, it's just coincidence, but so far, the only time i got this error, which corrupted my db, was exactly on the day that bitcoin calculator predicted that i would calculate another block. I mean almost to the hour...)  It must be a coincidence, since that calculation is purely an estimate. It would be very rare for it to be accurate to an hour. |
|
|
|
|
Show Posts
