|
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. |
|
|
|
That user seems alright to me. If he's a spammer, he at least took the effort to understand Bitcoin. Even if his posts are not useful, they're not off-topic or disruptive, either. I'm always logged in to several IM networks when I'm online (which is often). Feel free to message me about forum spam. AIM: theymos YIM: theymos MSN: theymos@hotmail.comJabber: theymos at gmail dot com |
|
|
|
If we really want to give the average user a good chance of protecting his wallet, it would be more effective to allow the split of a wallet by just "pressing a button". A new wallet file, encrypted with a given password, would be created, and the corresponding coins would not be on the main file anymore.
This is the best solution. Bitcoin doesn't even need to do the encryption (though it would be nice) -- it just needs to split the wallet. Then users can secure their "savings account file" appropriately. |
|
|
|
Yes, look at a raw block with at least 2 txns in it at BBE, you'll find answers  The public key is also shown on address pages if it has ever been used on the network. (Don't scrape regular BBE pages, though. I'll add a page on /q if anyone actually needs it.) The sender attaches the public key of all output addresses to the transaction?
Right. When you redeem a transaction sent to an address, you include the public key in the scriptSig. Then this is checked against both the hash and the signature. |
|
|
|
Personnally I don't know any other encryption/signing software.
There's the original PGP. They don't offer any freeware versions that I know of, but the source code is public, so you could compile your own version for free. |
|
|
|
Take a look at https://en.bitcoin.it/wiki/Blocks and follow the links on that page. Also join the IRC channel. Each record of a transaction is called a block.
No. This seems to be your main point of confusion. A block contains multiple unrelated transactions. The block chain is every block in order of creation. The block chain is used to securely record the ordering of transactions, preventing people from spending the same coins twice. Most users don't produce blocks -- they only produce transactions, which other users put into blocks. stating that node now has x fewer coins and the receiving node now has x more coins Balances aren't used, and everything is done by address. A transaction "redeems" a previous transaction, gaining all coins from it. Then it sends these coins to one or more addresses. Then these recipient addresses can redeem this transaction at any time in order to send the bitcoins that they were assigned. what exactly is being encrypted. The transactions are digitally signed. Nothing is encrypted. What is to stop someone else from sending a message to the network stating that he is you and he transacts x funds to y account He doesn't have the private key associated with your Bitcoin address, and he can't find it in a reasonable time. Read: http://en.wikipedia.org/wiki/Public-key_cryptographyThe Bitcoin address is a public key (a hash of the public key, actually, but it doesn't matter in this case). The private key is stored in your wallet.dat. i cant for the life of me figure out how [proof-of-work] factors into the whole bitcoin equation In order to produce a block, you need to solve a proof-of-work. This prevents people from re-doing the entire block chain and ruining the guaranteed ordering property that we need. Bitcoin's proof-of-work works like this: - Everyone in the network agrees on a target number, which determines the difficulty of generating a block. - People trying to generate blocks create random numbers in a way that allows everyone else in the network to verify that the numbers are actually random. (They hash their temporary block.) - If their number is lower than the target, then their block is valid. Also isnt it possible that two different public keys could return the same hash value, i know its unlikely but if people are using this service 100 years from now on a global scale there could be a LOT of transactions by then. If every person on Earth makes ten addresses per second for 20 years (2x1018 total addresses), then the probability that two of these addresses collide is about 1.57x10-12.
|
|
|
|
|
Show Posts
