Kicking the Hornet's Nest - part 14
# Kicking the Hornet's Nest - third edition - part 14
All links, digital (pdf, txt, docx, md) and book in print, can be found at https://hive.blog/@crrdlx/satoshi
Edited by [crrdlx](nostr:nprofile1qyv8wumn8ghj7mn0wdj8y6tkv5hxzurs9aex2mrp0yq3wamnwvaz7tmjv4kxz7fwwpexjmtpdshxuet59uqzqqzmcn0yrn7ttq8hrjkk46ysn2tk26rr8f8k4y7xkl74hlh3rcdzm9d3t8), npub:
```
npub1qpdufhjpel94srm3ett2azgf49m9dp3n5nm2j0rt0l2mlmc3ux3qza082j
```
----
### Kicking the Hornet's Nest pages 300 - 325
----
##### BitcoinTalk
#### Re: Security
##### _2010-07-10 12:58:02 UTC_ - [-](https://bitcointalk.org/index.php?topic=240.msg2132#msg2132)
I'll start thinking about how to do this.
At the moment, you can kind of use -connect. You can use -connect to make it connect to local computers on your LAN, like -connect=192.168.0.100. If you start it out blank and don't let it connect to the main network, the difficulty is still at the original low difficulty. If you've port-forwarded though, then outside nodes might still connect inward to you.
With -connect it still uses IRC, do you think it shouldn't get on IRC when you're telling it to only connect to specific nodes with -connect? The main scenario for -connect is where you have a server farm, with two connected to the network and the rest connected to the first two. In that case, you wouldn't want the -connect computers on IRC.
void ThreadIRCSeed(void* parg)
{
if (mapArgs.count("-connect"))
return;
##### BitcoinTalk
#### Re: Major Meltdown
##### _2010-07-10 13:36:17 UTC_ - [-](https://bitcointalk.org/index.php?topic=202.msg2133#msg2133)
[_**Quote from: llama on July 01, 2010, 10:21:47 PM**_](https://bitcointalk.org/index.php?topic=202.msg1920#msg1920)
_However, if something happened and the signatures were compromised (perhaps integer factorization is solved, quantum computers?), then even agreeing upon the last valid block would be worthless._
True, if it happened suddenly. If it happens gradually, we can still transition to something stronger. When you run the upgraded software for the first time, it would re-sign all your money with the new stronger signature algorithm. (by creating a transaction sending the money to yourself with the stronger sig)
##### BitcoinTalk
#### Re: No blocks downloaded... why?
##### _2010-07-14 16:22:03 UTC_ - [-](https://bitcointalk.org/index.php?topic=323.msg2867#msg2867)
So that was responsible for keeping blocks from downloading?
The link: "Win32 CPU Cycles vs 'Live Protection' Engines"
For BitcoinFX, Live Protection was keeping it from getting CPU for generating coins. You said your friend was getting 1400-1600 khash/s, so it was getting CPU. I guess Live Protection must have been blocking some other part of the program then?
##### BitcoinTalk
#### Re: resource hog
##### _2010-07-14 16:29:39 UTC_ - [-](https://bitcointalk.org/index.php?topic=327.msg2871#msg2871)
In Windows, you select the process in the task manager, right click, Set Priority. Set it to BelowNormal or Low. That shouldn't make a difference though.
If you turn off Generate Coins, does the CPU usage go flat? That would confirm that all the CPU time it's taking is generate, which is idle priority already.
It could be it's slow just because you have too many things running at once and you're out of memory. When you switch from one thing to another, it has to page it in from disk.
##### BitcoinTalk
#### Re: stopped prodicing coins
##### _2010-07-14 17:04:02 UTC_ - [-](https://bitcointalk.org/index.php?topic=343.msg2880#msg2880)
Thanks for making that calculator.
The difficulty doubled a day or two ago, plus it's just random and you can have surprisingly long dry spells.
##### BitcoinTalk
#### Re: Building Bitcoin 0.3
##### _2010-07-14 17:34:50 UTC_ - [-](https://bitcointalk.org/index.php?topic=298.msg2885#msg2885)
It doesn't work with wxWidgets 2.8, it needs wxWidgets 2.9. Unfortunately, there isn't a Debian package of wxWidgets 2.9 yet.
##### BitcoinTalk
#### Re: bitcoin auto-renice-ing
##### _2010-07-14 17:38:31 UTC_ - [-](https://bitcointalk.org/index.php?topic=72.msg2886#msg2886)
Laszlo corrected this, but unfortunately it was too late to make it into 0.3.0. There will probably be a 0.3.1 soon though.
The problem is I used PRIO_MIN, I should have used PRIO_MAX for the lowest priority. The OS isn't supposed to let you increase priority, so the PRIO_MIN ought to leave it at priority 0.
##### BitcoinTalk
#### Re: Stuck on 513 blocks
##### _2010-07-14 18:02:28 UTC_ - [-](https://bitcointalk.org/index.php?topic=305.msg2895#msg2895)
This is the second time I've seen this "Live Protection" problem reported.
It must be blocking the program's network communication. It sounds like it's allowing connections to be made, hence the 10 connections shown, but not allowing any data to be sent or received on them.
We need to understand this problem better.
Can someone write some instructions on the wiki explaining how to turn off or add an exclusion to Live Protection or whatever its full proper name is.
**Martii Malmi (AKA Sirius) “COPA trial” email #202**
**Date: Wed, 14 Jul 2010 22:52:46 +0100**
**From: Satoshi Nakamoto <satoshin@gmx.com>**
**Subject: Fwd: Re: bitcoin!!!!**
**To: Martti Malmi <mmalmi@cc.hut.fi>**
I see the interior pages of the old sourceforge wiki are still up,
though the homepage forwards.
-------- Original Message --------
Subject: Re: bitcoin!!!!
Date: Wed, 14 Jul 2010 10:56:21 -0400
From: Sam <samm@sammaloney.com>
To: Satoshi Nakamoto <satoshin@gmx.com>
References: <201004111508.52168.samm@sammaloney.com>
<201007111859.29171.samm@sammaloney.com> <4C3DCD97.8030003@gmx.com>
It was an old FAQ on sourceforge that had been linked from slashdot (on a
highly visible comment). people were going there because bitcoin.org was
down
for a while.
http://bitcoin.sourceforge.net/wiki/index.php?page=FAQ
Probably not an issue anymore, but might be a good idea to delete or update
that wiki page.
> I don't see any 0.1.5 download links on the FAQ. Do you mean
> bitcoin.org/faq? Is it on one of the other languages? Or maybe someone
> else fixed it already.
>
##### BitcoinTalk
#### Re: Error on Ubuntu 10.04
##### _2010-07-14 18:25:41 UTC_ - [-](https://bitcointalk.org/index.php?topic=318.msg2903#msg2903)
What language is your computer set to? Is it set to German, Dutch or Italian? Is it one of those sub-languages like "nl-??"?
It's trying to load a translation and failing. You could delete the locale directory that came with bitcoin so it doesn't try to use it.
Can someone test each language on Ubuntu and see if there's a problem with just one of them or maybe all three?
##### BitcoinTalk
#### Re: Runaway CPU usage for 64bit BitCoin (Linux Client)
##### _2010-07-14 18:45:53 UTC_ - [-](https://bitcointalk.org/index.php?topic=299.msg2908#msg2908)
After it initially tries incorrectly to set itself to the lowest priority, the generate thread only changes its priority again temporarily when it finds a block. When you've found a block, you should want it to hurry up and broadcast it as soon a possible before someone else finds one and makes yours invalid. The generate thread only changes to higher priority for less than a second every few days.
There should be a 0.3.1 release for this soon. There are a few other issues we need to look at fixing in 0.3.1 before making a release.
[_**Quote from: knightmb on July 12, 2010, 10:39:13 PM**_](https://bitcointalk.org/index.php?topic=299.msg2409#msg2409)
_On a side note, I've tracked down the other GUI issue.
The "minimize to tray instead of taskbar" is what was eating up all the CPU on my system. After I turned this off, the issue was resolved with Runaway CPU.
This only seems to affect the 64 bit Client, as the 32 bit Clients I have don't seem to be affected by this.
I did notice on the 64 bit Client, what happens is, it spawns multiple "tray" icons until X server finally kills over, so I guess I should submit that as a bug to somewhere?_ 
That's interesting. I know the minimize to tray on Ubuntu is very clunky, but I didn't know it had a CPU peg problem too. Anyone else able to reproduce this problem? We had this feature disabled on Linux before, but then it seemed better to have the imperfect UI than to lose the feature entirely. I'm thinking we should disable it again on Linux.
##### BitcoinTalk
#### Re: Warning this block was not received by any other nodes
##### _2010-07-14 18:56:29 UTC_ - [-](https://bitcointalk.org/index.php?topic=291.msg2913#msg2913)
Microsoft Security Essentials Live Protection is blocking your communication with the network. You have connections, which tricks Bitcoin into thinking it's connected, but they are silent because the data is being blocked.
You need to make bitcoin.exe an excluded process in Live Protection.
This is becoming a common problem. Someone should write this up in a pegged thread.
The message "Warning: This block was not received by any other nodes" occurs when Bitcoin broadcasts a block, but nobody confirms they received it. The warning is there just for this kind of situation, where for some reason you have connections, but they have gone dead and nobody can hear you. Your block will never become valid because nobody received it.
##### BitcoinTalk
#### Re: Hash/sec Throttling for Democracy
##### _2010-07-14 20:25:06 UTC_ - [-](https://bitcointalk.org/index.php?topic=325.msg2935#msg2935)
[_**Quote from: knightmb on July 14, 2010, 07:17:43 PM**_](https://bitcointalk.org/index.php?topic=325.msg2917#msg2917)
_So if your computer was only 1% towards solving block 68000_
This is a common point of confusion. There's no such thing as being 1% towards solving a block. You don't make progress towards solving it. After working on it for 24 hours, your chances of solving it are equal to what your chances were at the start or at any moment.
It's like trying to flip 37 coins at once and have them all come up heads. Each time you try, your chances of success are the same.
The RNG is the OpenSSL secure random number generator. On Windows it's seeded with the complete set of all hardware performance counters since your computer started, on Linux it's dev/random.
##### BitcoinTalk
#### Re: Scalability
##### _2010-07-14 21:10:52 UTC_ - [-](https://bitcointalk.org/index.php?topic=286.msg2947#msg2947)
The design outlines a lightweight client that does not need the full block chain. In the design PDF it's called Simplified Payment Verification. The lightweight client can send and receive transactions, it just can't generate blocks. It does not need to trust a node to verify payments, it can still verify them itself.
The lightweight client is not implemented yet, but the plan is to implement it when it's needed. For now, everyone just runs a full network node.
I anticipate there will never be more than 100K nodes, probably less. It will reach an equilibrium where it's not worth it for more nodes to join in. The rest will be lightweight clients, which could be millions.
At equilibrium size, many nodes will be server farms with one or two network nodes that feed the rest of the farm over a LAN.
##### BitcoinTalk
#### Re: Runaway CPU usage for 64bit BitCoin (Linux Client)
##### _2010-07-15 00:18:23 UTC_ - [-](https://bitcointalk.org/index.php?topic=299.msg3008#msg3008)
OK, the undocumented switch "-minimizetotray" which re-enables the option.
I uploaded the change to SVN.
##### BitcoinTalk
#### Re: [Bitcoin 0.3.0] Runtime error
##### _2010-07-15 14:05:20 UTC_ - [-](https://bitcointalk.org/index.php?topic=373.msg3150#msg3150)
More directly, this:
[http://BitcoinTalk.org/index.php?topic=246.0](http://bitcointalk.org/index.php?topic=246.0)
I will be posting release candidate of 0.3.1 with this fix shortly. Please try that and let me know if it fixes the problem.
##### BitcoinTalk
#### Re: Static Linux x86_64 bins for those having libcrypto troubles
##### _2010-07-15 14:33:04 UTC_ - [-](https://bitcointalk.org/index.php?topic=326.msg3157#msg3157)
We don't even specify linking glibcxx_3.4.11, so gcc must automatically link it behind the scenes. There's probably a compiler switch that would tell it to static link it. I'm not sure what the licensing issues would be. Typically, compiler stuff is fully redistributable.
##### BitcoinTalk
#### Re: resource hog
##### _2010-07-15 14:59:00 UTC_ - [-](https://bitcointalk.org/index.php?topic=327.msg3162#msg3162)
Then all the CPU time is the generate thread, which definitely runs at the lowest possible priority, idle priority. It's normal that your CPU meter is 100%. Since it's idle priority, it won't actually slow anything else down, even though the CPU meter is 100%.
##### BitcoinTalk
#### Bitcoin 0.3.1 released
##### _2010-07-15 17:05:54 UTC_ - [-](https://bitcointalk.org/index.php?topic=383.msg3198#msg3198)
This is a bugfix maintenance release. It is now uploaded to SourceForge. Mac OS X didn't need any fixes so we don't really need to update it, 0.3.0 is still good.
The download links are on bitcoin.org
Changes:
- Added Portuguese translation by Tiago Faria
Windows
- Fix for 22DbRunRecoveryException if your username has non-ascii characters in it
Linux
- Laszlo's fix for lowering generate thread to lowest priority
- Fix for if you're having trouble with libcrypto linkage
- Gavin Andresen's implementation of "start on windowing system startup" option
##### BitcoinTalk
#### Re: 0.3.1 release candidate, please test
##### _2010-07-15 17:23:48 UTC_ - [-](https://bitcointalk.org/index.php?topic=383.msg3205#msg3205)
Well, it can't hurt to do a backup and it's a good idea to backup regularly, but no, a backup is not required before installing this.
##### BitcoinTalk
#### Re: 0.3.1 release candidate, please test
##### _2010-07-15 17:56:43 UTC_ - [-](https://bitcointalk.org/index.php?topic=383.msg3221#msg3221)
I don't think you have a particular problem, I think your system is laggy because you're running a lot of things at once and hitting the pagefile because memory is full. You confirmed when you shut off generation that your CPU drops to 0%, so the CPU usage is definitely all idle priority. There's nothing in the 0.3.1 that would affect these things.
##### BitcoinTalk
#### Re: Website and software translations
##### _2010-07-15 18:30:22 UTC_ - [-](https://bitcointalk.org/index.php?topic=151.msg3238#msg3238)
[_**Quote from: aidos on July 15, 2010, 12:49:11 AM**_](https://bitcointalk.org/index.php?topic=151.msg3017#msg3017)
_Ok here is the .po file for French. While I'm at it, I noted a couple of issues:
1. The "About" box didn't take the translation into account, it still displays the english version to me, even though the rest of the software is using the translated strings, and the .po file contains the translation string of the "About" box message. Same problem with the "Apply" button in the Settings window._
I need to give an updated .po file.
[_**Quote from: aidos on July 15, 2010, 12:49:11 AM**_](https://bitcointalk.org/index.php?topic=151.msg3017#msg3017)
_2. If an transaction's description in the list of transaction in the main window contains a diacritical character (such as "\u00e9\u00e0\u00e8\u00e7"), it's not displayed. I suppose the string is not being properly handled as UTF8 somewhere._
OK, this must be a problem somewhere, I'll have to take a look at it or one of the other devs can.
[_**Quote from: aidos on July 15, 2010, 12:49:11 AM**_](https://bitcointalk.org/index.php?topic=151.msg3017#msg3017)
_4. About the .po file :
- There are a few strings in the .po file that don't needs translation (ie: "Bitcoin"). Maybe those shouldn't be inside _("...") ?
- Others shouldn't be split. I can remember one message about transaction fee where the string is split in two to insert the fee value, where you could simply have put a %s. It makes the message harder to translate as I had to go in the source to find exactly what was going on.
- Some strings have whitespace at the end or start, which necessity is very debatable, and it's easy to miss in PoEdit._
Many of the strings are in code automatically generated from uiproject.fbp where nothing can be done about these things. I have a program I use to find all the spacing inconsistencies at the beginning and ending of strings in your .po file and manually fix them up before I upload them to SVN.
##### BitcoinTalk
#### Re: Website and software translations
##### _2010-07-15 18:37:13 UTC_ - [-](https://bitcointalk.org/index.php?topic=151.msg3242#msg3242)
I uploaded an updated bitcoin.po for 0.3.1 attached to this message:
[http://BitcoinTalk.org/index.php?topic=151.msg1259#msg1259](http://bitcointalk.org/index.php?topic=151.msg1259#msg1259)
please use it if you're starting a new translation.
If you already have a po file, poedit can update it.
- Get the src directory from the 0.3.1 release candidate posted in the development forum, any version will do:
[http://BitcoinTalk.org/index.php?topic=383.0](http://bitcointalk.org/index.php?topic=383.0)
- Make a subdirectory under src: locale/??/LC_MESSAGES
(?? could be anything really, "en" or your language 2-letter code)
- Put your .po file there
- Open it with poedit
- In poedit, Catalog->Update from sources
The key is that the src directory with the sourcefiles needs to be 3 directories up from the .po file.
**Martii Malmi (AKA Sirius) “COPA trial” email #203**
**Date: Thu, 15 Jul 2010 18:41:10 +0100**
**From: Satoshi Nakamoto <satoshin@gmx.com>**
**Subject: bitcoin.org drupal users**
**To: Martti Malmi <mmalmi@cc.hut.fi>**
Is it possible for the translators (at least the more trusted ones) to
have user accounts on drupal so they can update their translated text
directly? The user accounts on drupal appear to be pretty weak. I
created a satoshi account and it can't even edit the side bar stuff,
just the main text of pages. I don't think user accounts can access any
of the admin stuff. Do you think it's safe, or do you feel insecure
about doing that? If you're worried, maybe there's a way to lock just
the english version of the homepage.
It would be nice if when I need to make changes to the homepage, I could
enlist someone like Xunie to do the rote work of reflecting it to all
the translations instead of having to do all that work myself. (many
light changes don't require understanding the language to fix the
translated pages)
##### BitcoinTalk
#### Re: Website and software translations
##### _2010-07-15 18:43:54 UTC_ - [-](https://bitcointalk.org/index.php?topic=151.msg3247#msg3247)
[**Quote from: SmokeTooMuch on July 13, 2010, 06:55:55 PM**](https://bitcointalk.org/index.php?topic=151.msg2619#msg2619)
I recommend to remove the download links at the bottom of the main page.
As you can see the links on the English page points to the new 0.3 release, but the other languages only contain links for the old 0.2 version.
There's a download box with the current releases on the right anyway, so why not remove the links from the translated pages.
I updated them to 0.3.0.
I am tempted to remove the download links from the other languages and only keep it on English.
They will need to be updated for 0.3.1 soon. Perhaps there's a way for someone to manage the updating of the translated drupal pages.
**Martii Malmi (AKA Sirius) “COPA trial” email #204**
**Date: Thu, 15 Jul 2010 18:43:55 +0100**
**From: Satoshi Nakamoto <satoshin@gmx.com>**
**Subject: Fwd: Please update the bitcoin FAQ so new member can have the right info**
**To: Martti Malmi <mmalmi@cc.hut.fi>**
-------- Original Message --------
Subject: Please update the bitcoin FAQ so new member can have the right
info
Date: Mon, 12 Jul 2010 14:13:20 -0700
From: Jim Nguyen <jimmy.winn@gmail.com>
To: satoshin@gmx.com
Hi,
In the FAQ of bitcoin.org <http://bitcoin.org> the backing up of the
wallet had old instructions, right? Should it just be to back up
wallat.dat instead of the entire folder??? See below.
"How do I backup my wallet?
Your data is stored in the directory ''%appdata%\Bitcoin'', which is
typically:
Windows XP:
C:\Documents and Settings\username\Application Data\Bitcoin
Windows Vista:
C:\Users\username\AppData\Roaming\Bitcoin
It’s recommended that you stop Bitcoin before backing it up to make sure
the backup will be correct."
##### BitcoinTalk
#### Re: Website and software translations
##### _2010-07-15 19:12:14 UTC_ - [-](https://bitcointalk.org/index.php?topic=151.msg3257#msg3257)
Thanks for the Spanish and French translations! The edited and updated .po files are attached.
I uploaded these to the SVN.
**Martii Malmi (AKA Sirius) “COPA trial” email #205**
**Date: Thu, 15 Jul 2010 21:00:12 +0100**
**From: Satoshi Nakamoto <satoshin@gmx.com>**
**Subject: bitcoin.org server**
**To: Martti Malmi <mmalmi@cc.hut.fi>**
You did some research when choosing hosting, this was a well chosen one,
right? It seems like it would be a tremendous hassle to change, and
we've had good luck with this one. Cheaper will usually have some
offsetting drawback in quality.
I wonder if that extra memory is just disk cache or something.
I take it you haven't received anything from that donor yet? He seemed
pretty certain he was going to send it, maybe more. (if you get
anything, we need to keep private for him the fact that we got a donation)
##### BitcoinTalk
#### Re: 0.3.1 release candidate, please test
##### _2010-07-15 21:40:34 UTC_ - [-](https://bitcointalk.org/index.php?topic=383.msg3295#msg3295)
[_**Quote from: knightmb on July 15, 2010, 07:37:10 PM**_](https://bitcointalk.org/index.php?topic=383.msg3269#msg3269)
_On Windows, the priority of the Coin Generation is still net for normal. If you run BitCoin in Generate Coin mode, then load up something to eat up all the CPU (like CPU hog for example:_ [_http://www.microtask.ca/cpuhog.html_](http://www.microtask.ca/cpuhog.html)_) you'll see that both BitCoin and CPU hog share the CPU 50/50 instead of CPU Hog taking all the CPU and BitCoin running only on idle/low process. The khash/s is also reduced in half, so further evidence that the threads are not running in a lower than normal prioirty._
I was not able to reproduce this. I have dual-proc, so I ran two memory hogs. Bitcoin got 0% of CPU according to the task manager. The khash/sec meter stayed stuck because it couldn't get any CPU to update it.
Do you have dual-proc? Are you sure you weren't running a single processor hog?
##### BitcoinTalk
#### Re: 0.3.1 release candidate, please test
##### _2010-07-15 22:07:35 UTC_ - [-](https://bitcointalk.org/index.php?topic=383.msg3305#msg3305)
[_**Quote from: knightmb on July 15, 2010, 08:15:46 PM**_](https://bitcointalk.org/index.php?topic=383.msg3274#msg3274)
_On the Linux client (64 bit), the "minimize on close" will still minimize to tray (causing X server hang after a short while by spawning multiple tray icons)._
I updated the first post with a link to rc2 for linux with the fix for this. Please check that this is fixed for you. Thanks!
[http://www.bitcoin.org/download/bitcoin-0.3.1.rc2-linux.tar.gz](http://www.bitcoin.org/download/bitcoin-0.3.1.rc2-linux.tar.gz)
##### BitcoinTalk
#### Re: 0.3.1 release candidate, please test
##### _2010-07-15 22:10:19 UTC_ - [-](https://bitcointalk.org/index.php?topic=383.msg3306#msg3306)
[_**Quote from: db on July 15, 2010, 08:39:08 PM**_](https://bitcointalk.org/index.php?topic=383.msg3278#msg3278)
_The listreceivedbyaddress and getreceivedbyaddress commands are duplicated in bincoind help. (Same in 0.3.0.)_
Yes a bug. It'll have to be fixed in the next version.
##### BitcoinTalk
#### Re: "SetIcons(): icon bundle doesn't contain any suitable icon"
##### _2010-07-16 02:43:29 UTC_ - [-](https://bitcointalk.org/index.php?topic=391.msg3362#msg3362)
That must be it then.
It must be looking for a larger icon like 20x20 but we don't have one.
##### BitcoinTalk
#### Re: Proof-of-work difficulty increasing
##### _2010-07-16 14:46:12 UTC_ - [-](https://bitcointalk.org/index.php?topic=43.msg3488#msg3488)
The proof-of-work difficulty is currently 45.38. (see [http://www.alloscomp.com/bitcoin/calculator.php](http://www.alloscomp.com/bitcoin/calculator.php))
It's about to increase again in a few hours. It's only been 3-4 days since the last increase, so I expect it will increase by the max of 4 times, or very nearly the max. That would put it at 181.54.
The target time between adjustments is 14 days, 14/3.5 days = 4.0 times increase.
##### BitcoinTalk
#### Re: Assertion Failure - Ubuntu Lucid
##### _2010-07-16 14:52:04 UTC_ - [-](https://bitcointalk.org/index.php?topic=400.msg3492#msg3492)
That's the first time I've seen this error.
How many blocks do you have? (in the status bar)
You should move your blk*.dat files (in ~/.bitcoin) to another directory and let it start over downloading the block chain again. If you don't mind, could you keep the old blk*.dat files for a little while in case I need to look at them?
##### BitcoinTalk
#### Re: Fedora 13 libcrypto
##### _2010-07-16 14:55:23 UTC_ - [-](https://bitcointalk.org/index.php?topic=296.msg3495#msg3495)
Please try the 0.3.1 release candidate, it should at least resolve the libcrypto dependency:
[http://BitcoinTalk.org/index.php?topic=383.0](http://bitcointalk.org/index.php?topic=383.0)
Let me know if that works.
##### BitcoinTalk
#### Re: Resending transaction
##### _2010-07-16 15:01:33 UTC_ - [-](https://bitcointalk.org/index.php?topic=303.msg3499#msg3499)
Bitcoin automatically rebroadcasts your transactions if it receives new blocks that don't contain them. It may take about an hour to get rebroadcasted. It is relentless though. It will keep nagging the network forever until your transaction gets into a block.
##### BitcoinTalk
#### Re: 0.3.1 release candidate, please test
##### _2010-07-16 15:09:59 UTC_ - [-](https://bitcointalk.org/index.php?topic=383.msg3505#msg3505)
Because of all the dependencies that different systems don't have. It's easier to just static link what we can. It doesn't increase the size by very much.
##### BitcoinTalk
#### Re: Source code documentation
##### _2010-07-16 15:37:00 UTC_ - [-](https://bitcointalk.org/index.php?topic=393.msg3510#msg3510)
I like that in libraries for the external API's, but you can probably tell from the code that I'm not a fan of it for interior functions. Big obligatory comment headers for each function space out the code and make you hesitate about creating a small little function where the comment header would be bigger than the function. They're some trouble for maintenance, as changes to the function then require duplicate changes in the comment header. I like to keep code compact so you can see more code on the screen at once.
To add them now at this point, what would be written would just be what's obvious from looking at the function.
The external API we have, in rpc.cpp, the usage documentation is in the help string.
Sorry to be a wet blanket.
##### BitcoinTalk
#### Re: Hash() function not secure
##### _2010-07-16 16:13:53 UTC_ - [-](https://bitcointalk.org/index.php?topic=360.msg3520#msg3520)
SHA256 is not like the step from 128 bit to 160 bit.
To use an analogy, it's more like the step from 32-bit to 64-bit address space. We quickly ran out of address space with 16-bit computers, we ran out of address space with 32-bit computers at 4GB, that doesn't mean we're going to run out again with 64-bit anytime soon.
SHA256 is not going to be broken by Moore's law computational improvements in our lifetimes. If it's going to get broken, it'll be by some breakthrough cracking method. An attack that could so thoroughly vanquish SHA256 to bring it within computationally tractable range has a good chance of clobbering SHA512 too.
If we see a weakness in SHA256 coming gradually, we can transition to a new hash function after a certain block number. Everyone would have to upgrade their software by that block number. The new software would keep a new hash of all the old blocks to make sure they're not replaced with another block with the same old hash.
##### BitcoinTalk
#### Re: Request: expected bitcoins per day display
##### _2010-07-16 16:47:14 UTC_ - [-](https://bitcointalk.org/index.php?topic=397.msg3524#msg3524)
Many businesses are like that. For a car salesman, when will the next customer walk in the door?
On the OP's question, it's a good feature, but the question is, how would we word it so people don't expect to get something after that specific amount of time? "it said 7 days and I waited more than a week and didn't get anything!" Approx, average, but still they're going to think that way. It can't be a whole sentence, unless we think of somewhere else to put it, but where would that be? Suggestions?
The difficulty quadrupled a few minutes ago to 181.54. It's going to take typically about a week to generate now.
##### BitcoinTalk
#### Re: Proof-of-work difficulty increasing
##### _2010-07-16 16:56:54 UTC_ - [-](https://bitcointalk.org/index.php?topic=43.msg3526#msg3526)
It adjusted to 181.54 a few minutes ago. Typical time to get a block is about a week now.
The difficulty can adjust down as well as up.
The network should be generating close to 6 blocks per hour now.
##### BitcoinTalk
#### Re: Source code documentation
##### _2010-07-16 17:15:47 UTC_ - [-](https://bitcointalk.org/index.php?topic=393.msg3534#msg3534)
It's in init.cpp.
It's a wxWidgets app, so it doesn't have a main() function. It may in a little while, since I'm pretty close to making bitcoind build w/o wxBase. (it'll be in init.cpp)
Sorry about my choice of the filename "main.cpp", another possible name would have been "core.cpp". It's much too late to change. I still prefer main.cpp.
We're still in great need of sample code showing the recommended way to use the JSON-RPC functions, like for a basic account system on a typical storefront website. Using getreceivedbylabel using the username as the label, changing to a new bitcoin address once the stored one for that account gets used. I posted a sample code fragment on the forum somewhere. (search on getreceivedbylabel or getnewaddress) The sample code could be a plain vanilla bank site where you can deposit and send payments.
##### BitcoinTalk
#### Re: 0.3.1 release candidate, please test
##### _2010-07-16 17:26:17 UTC_ - [-](https://bitcointalk.org/index.php?topic=383.msg3536#msg3536)
Good point. If you're going to have more than 8 LAN nodes connect to one gateway node, then you'd better have the gateway node set up so it can receive incoming connections. Otherwise, while the gateway node has 8 or more connections, it will not try to add any more outbound connections. As the outside nodes you're connected to come and go, it doesn't make new outbound connections to replace them. You'll be fine if you can accept incoming connections, then there will be plenty of others connecting to you.
##### BitcoinTalk
#### Re: Proof-of-work difficulty increasing
##### _2010-07-16 17:29:28 UTC_ - [-](https://bitcointalk.org/index.php?topic=43.msg3537#msg3537)
Yes, about 20 hours. (120 conf / 6 blocks per hour = 20 hours) That's the normal length of time before you can spend it. You know long before that that you won one.
##### BitcoinTalk
#### Re: bitcoin trademark?
##### _2010-07-16 17:47:05 UTC_ - [-](https://bitcointalk.org/index.php?topic=378.msg3540#msg3540)
No, not related at all.
##### BitcoinTalk
#### Re: The dollar cost of bitmining energy
##### _2010-07-16 17:58:44 UTC_ - [-](https://bitcointalk.org/index.php?topic=403.msg3545#msg3545)
Neat chart.
Difficulty just increased by 4 times, so now your cost is US$0.02/BTC.
##### BitcoinTalk
#### Re: Website integration for bitcoin
##### _2010-07-16 18:23:04 UTC_ - [-](https://bitcointalk.org/index.php?topic=364.msg3559#msg3559)
I've been trying to encourage someone to write and release some sample Python code showing the recommended way to do the typical accounting stuff, but to no avail. It would be nice if you didn't have to re-invent the wheel like you're doing here. Search on getnewaddress and you should find a thread where I gave a small fragment of sample pseudocode.
##### BitcoinTalk
#### Re: Proof-of-work difficulty increasing
##### _2010-07-16 18:43:51 UTC_ - [-](https://bitcointalk.org/index.php?topic=43.msg3565#msg3565)
Right, the difficulty adjustment is trying to keep it so the network as a whole generates an average of 6 blocks per hour. The time for your block to mature will always be around 20 hours.
The recent adjustment put us back to close to 6 blocks per hour again.
There's a site where you can see the time between blocks, and since block 68545, it's been more like 10 minutes per block:
[http://nullvoid.org/bitcoin/statistix.php](http://nullvoid.org/bitcoin/statistix.php)
##### BitcoinTalk
#### Sample account system using JSON-RPC needed
##### _2010-07-16 19:45:10 UTC_ - [-](https://bitcointalk.org/index.php?topic=417.msg3579#msg3579)
We need someone to write sample code, preferably Python or Java, showing the recommended way to use the JSON-RPC interface to create an account system. Most sites that sell things will need something like this. Someone who's kept up on the JSON-RPC threads here should have some idea how it should work.
When a user is logged in to their account, you show the bitcoin address they can send to to add funds. Before showing it, you check if it's been used, if it has then you replace it with a new one (getnewaddress <username>). You only need to keep the latest bitcoin address for the account in your database. (I posted a sample code fragment for this in an earlier thread somewhere, search on getnewaddress)
You use getreceivedbylabel <username> with the username as the label to get the "credit" amount of the account. You need to keep a "debit" amount in your database. The current balance of the account is (credit - debit). When the user spends money, you increase debit.
If you're requiring more than 0 confirmations, it's nice if you show the current balance (0 confirmations) and the available balance (1 or more confirmations), so they can immediately see that their payment is acknowledged. Not all sites need to wait for confirmations, so the dual current & available should be optional. Most sites selling digital goods are fine to accept 0 confirmations.
A nice sample app for this would be a simple bank site, which would have the above, plus the option to send a payment to a bitcoin address. The sample code should be the simplest possible with the minimum extra stuff to make it a working site.
vekja.net is an example of a site like this.
##### BitcoinTalk
#### Re: Bitcoin 0.3.1 released
##### _2010-07-16 21:06:57 UTC_ - [-](https://bitcointalk.org/index.php?topic=383.msg3590#msg3590)
I uploaded windows 0.3.1 rc1 and linux 0.3.1 rc2 to SourceForge and updated the links on the homepage.
You don't need to update to 0.3.1 unless you had one of the problems listed in the first post. If you've got it working already, stay with 0.3.0.
##### BitcoinTalk
#### Re: A New Currency System for the World
##### _2010-07-16 22:20:09 UTC_ - [-](https://bitcointalk.org/index.php?topic=128.msg3605#msg3605)
[_**Quote from: hugolp on May 08, 2010, 10:38:51 AM**_](https://bitcointalk.org/index.php?topic=128.msg1082#msg1082)
_When I run bitcoin it becomes very sluggish, almost unusable. When I stop bitcoin everything goes ok again. Its running Ubuntu desktop 10.04 amd64 using ia32libs and the binary in bitcoin 0.20 tarball._
0.3.1 fixes that, sets the generate threads to the lowest priority. Download links are on the homepage now.
##### BitcoinTalk
#### Re: BUG Report: Rounding glitch
##### _2010-07-17 16:06:12 UTC_ - [-](https://bitcointalk.org/index.php?topic=432.msg3769#msg3769)
It must be a rounding error when getinfo converts to floating point to return the JSON-RPC result. The only place where it uses floating point to represent money is returning a value in JSON-RPC.
1.139999999999 is longer than bitcoin can internally represent.
internally, it could only be:
1.13999999 or
1.14000000
1.139999999999 is much much closer to 1.14000000 than 1.13999999, so it must be 1.14000000.
The code is this:
(double)GetBalance() / (double)COIN.
(I can't think of an easy way to fix it at the moment)
##### BitcoinTalk
#### Re: Privacy versus Safety: handling change
##### _2010-07-17 16:27:39 UTC_ - [-](https://bitcointalk.org/index.php?topic=434.msg3770#msg3770)
We should queue up a supply of pre-made addresses in the wallet to use when a new address is needed. They aren't very big, so it wouldn't hurt to have a lot of them. This would more generally cover the case also where someone backs up, then requests a new address and receives a big payment with it. Maybe there should be separate queues so one type of demand on addresses doesn't deplete it for the others.
The addresses would be created and stored in the normal place, but also listed on a separate list of created-but-never-used addresses. When an address is requested, the address at the front of the never-used queue is handed out, and a new address is created and added to the back.
There's some kind of rescan in the block loading code that was made to repair the case where someone copied their wallet.dat. I would need to check that the rescan handles the case of rediscovering received payments in blocks that were already received, but are forgotten because the wallet was restored.
##### BitcoinTalk
#### Re: Nenolod, the guy that wants to prove Bitcoin doesn't work.
##### _2010-07-17 16:56:06 UTC_ - [-](https://bitcointalk.org/index.php?topic=431.msg3773#msg3773)
0.3.2 has some security safeguards to lock in the block chain up to this point and limit the damage a little if someone gets 50%.
But if someone has 50%+ of the CPU power and malicious intent, they can prove what it already says in the design document.
##### BitcoinTalk
#### Bitcoin 0.3.2 released
##### _2010-07-17 21:35:51 UTC_ - [-](https://bitcointalk.org/index.php?topic=437.msg3807#msg3807)
Download links available now on bitcoin.org. Everyone should upgrade to this version.
- Added a simple security safeguard that locks-in the block chain up to this point.
- Reduced addr messages to save bandwidth now that there are plenty of nodes to connect to.
- Spanish translation by milkiway.
- French translation by aidos.
The security safeguard makes it so even if someone does have more than 50% of the network's CPU power, they can't try to go back and redo the block chain before yesterday. (if you have this update)
I'll probably put a checkpoint in each version from now on. Once the software has settled what the widely accepted block chain is, there's no point in leaving open the unwanted non-zero possibility of revision months later.
##### BitcoinTalk
#### Re: Bitcoin snack machine (fast transaction problem)
##### _2010-07-17 22:29:13 UTC_ - [-](https://bitcointalk.org/index.php?topic=423.msg3819#msg3819)
I believe it'll be possible for a payment processing company to provide as a service the rapid distribution of transactions with good-enough checking in something like 10 seconds or less.
The network nodes only accept the first version of a transaction they receive to incorporate into the block they're trying to generate. When you broadcast a transaction, if someone else broadcasts a double-spend at the same time, it's a race to propagate to the most nodes first. If one has a slight head start, it'll geometrically spread through the network faster and get most of the nodes.
A rough back-of-the-envelope example:
1 0
4 1
16 4
64 16
80% 20%
So if a double-spend has to wait even a second, it has a huge disadvantage.
The payment processor has connections with many nodes. When it gets a transaction, it blasts it out, and at the same time monitors the network for double-spends. If it receives a double-spend on any of its many listening nodes, then it alerts that the transaction is bad. A double-spent transaction wouldn't get very far without one of the listeners hearing it. The double-spender would have to wait until the listening phase is over, but by then, the payment processor's broadcast has reached most nodes, or is so far ahead in propagating that the double-spender has no hope of grabbing a significant percentage of the remaining nodes.
##### BitcoinTalk
#### Re: Assertion Failure - Ubuntu Lucid
##### _2010-07-17 22:37:06 UTC_ - [-](https://bitcointalk.org/index.php?topic=400.msg3823#msg3823)
[_**Quote from: singpolyma on July 17, 2010, 10:19:48 PM**_](https://bitcointalk.org/index.php?topic=400.msg3815#msg3815)
_My coins disappeared, but I assume they'll come back when it's up to current?_
Right, they'll re-appear when it's finished downloading all the blocks.
##### BitcoinTalk
#### Re: Bitcoin 0.3.2 released
##### _2010-07-17 22:54:24 UTC_ - [-](https://bitcointalk.org/index.php?topic=437.msg3825#msg3825)
[_**Quote from: llama on July 17, 2010, 09:56:25 PM**_](https://bitcointalk.org/index.php?topic=437.msg3810#msg3810)
_However, it's important that you don't lock all the way up the very latest block. Otherwise, the attacker could generate a fake block (or a few) right before you happen to lock it, and then his attack would be far easier than it would have been without the block lock._
I went about 200 blocks back. The block chain was a clean straight line without branches, and there was only one known version of the locked block.
[_**Quote from: llama on July 17, 2010, 09:56:25 PM**_](https://bitcointalk.org/index.php?topic=437.msg3810#msg3810)
_Also, I'm assuming that the block lock means that the blocks will also come prepackaged with the client. Is this so?_
Sorry, not yet, but I do want to make the initial block download faster.
##### BitcoinTalk
#### Re: Source code documentation
##### _2010-07-17 23:18:30 UTC_ - [-](https://bitcointalk.org/index.php?topic=393.msg3828#msg3828)
I didn't realize you were going to document all the intentionally undocumented commands. They're unsupported and not intended to be used by users.
All the user-facing commands are listed in the -? help.
##### BitcoinTalk
#### Re: Network Size
##### _2010-07-17 23:25:16 UTC_ - [-](https://bitcointalk.org/index.php?topic=419.msg3830#msg3830)
[_**Quote from: NewLibertyStandard on July 17, 2010, 10:22:09 PM**_](https://bitcointalk.org/index.php?topic=419.msg3817#msg3817)
_Version 0.3 was supposed to reduce the number of outgoing connections on non-port forwarded clients from 15 to 8, but I don't think it really happened. I'm not positive if this is the case. Correct me if I'm wrong._
In 0.3.0, the change to 8 only ended up in the Windows version, the other versions still had 15.
Please upgrade to 0.3.2, it's available now.
----
