Kicking the Hornet's Nest - part 8
# Kicking the Hornet's Nest - third edition - part 8
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 150 - 175
----
**Martii Malmi (AKA Sirius) “COPA trial” email #57**
**Date: Thu, 05 Nov 2009 05:31:03 +0000**
**From: Satoshi Nakamoto <satoshin@gmx.com>**
**Subject: Re: Linux build**
**To: Martti Malmi <mmalmi@cc.hut.fi>**
I merged the linux changes into the main trunk on SVN. It compiles and
runs now. I think all the problems are in the UI. The menus quickly
quit working and it doesn't repaint when it's supposed to unless I
resize it, and the UI is getting some segfaults. Shouldn't be too hard
to debug with gdb. I haven't tested if it plays nice with other nodes
yet so keep it off-net.
build-unix.txt and makefile.unix added
**Martii Malmi (AKA Sirius) “COPA trial” email #58**
Date: Thu, 05 Nov 2009 15:25:27 +0000
From: Satoshi Nakamoto <satoshin@gmx.com>
Subject: Re: Proxy
To: mmalmi@cc.hut.fi
_mmalmi@cc.hut.fi wrote:_
_> Enabling the proxy setting and restarting Bitcoin I got the first_
_> connections in less than a minute and ultimately even 8 connections. I_
_> wonder if they're all really through TOR. Netstat shows only 2_
_> connections to localhost:9050 and 7 connections from local port 8333 to_
_> elsewhere. (Some of the shown connections may be already disconnected_
_> ones.) For some reason there's no debug.log in the folder where I'm_
_> running it._
debug.log moved to the data directory "%appdata%/bitcoin/debug.log"
7 inbound and 2 outbound sounds about as expected.
My last SVN commit included an overhaul of the code that selects the
order of addresses to connect to, trying them in the order of most
recently seen online, so it should get connected in a more reasonable
amount of time if IRC is unavailable. IRC is really only needed to seed
the first connection, but we've been using it as a crutch to get
connected faster.
_>> If some nodes that accept incoming connects were willing to have their_
_>> IP coded into the program, it could seed automatically. Or some IP_
_>> seed addresses posted on a Wiki page with the instructions._
_>_
_> The wiki page sounds like a good and quickly applicable solution. I_
_> could keep my ip updated there and we could ask others to do the same._
_> When the Linux build works, it's easier to set up nodes on servers that_
_> are online most of the time and have a static IP. A static ip list_
_> shipped with Bitcoin and a peer exchange protocol would be cool. That_
_> way there'd be no need for an IRC server._
That would be great. It's only TOR users that need it, so in the
instructions saying "bitcoin -proxy=127.0.0.1:9050 -addnode=<someip>",
someip could be an actual static IP, with the wiki free-for-all
add-your-ip list nearby or a link to it. There should be a link to that optional step, add your IP to this list now that you can accept incoming if you're static.
Do you think anonymous people are looking to be completely stealth, as
in never connect once without TOR so nobody knows they use bitcoin, or
just want to switch to TOR before doing any transactions? It's just if
you want to be completely stealth that you'd have to go through the
-proxy -addnode manual seeding. It would be very easy to fumble that
up; if you run bitcoin normally to begin with it immediately
automatically starts connecting.
**Martii Malmi (AKA Sirius) “COPA trial” email #59**
**Date: Thu, 05 Nov 2009 17:33:58 +0000**
**From: Satoshi Nakamoto <satoshin@gmx.com>**
**Subject: Forum**
**To: Martti Malmi <mmalmi@cc.hut.fi>**
Now that the forum on bitcoin.sourceforge.net is catching on, we really
should look for somewhere that freehosts full blown forum software. The
bitweaver forum feature is just too lightweight. I assume the "Forum"
tab on the homepage can link out to wherever the forum is hosted.
I've seen projects that have major following just from forum talk and
pie-in-the-sky planning without even having any code yet. Having a lot
of forum talk gives a project more presence on the net, more search
hits, makes it look big, draws new users in, helps solve support
questions, hashes out what features are most of wanted.
It would be a big plus if it could support SSL, at least for the login
page if not sitewide. Multiple people on the forum have expressed
interest in TOR/I2P, and those users need SSL because a lot of TOR exit
nodes are probably password scrapers run by identity thieves. A lot of
the core interest in Bitcoin is going to be from the privacy crowd.
Any ideas where we can get a free forum? Maybe we should look at where
some other projects have their forums hosted for ideas where to look.
**Martii Malmi (AKA Sirius) “COPA trial” email #60**
**Date: Fri, 06 Nov 2009 06:20:15 +0000**
**From: Satoshi Nakamoto <satoshin@gmx.com>**
**Subject: Re: Linux build**
**To: Martti Malmi <mmalmi@cc.hut.fi>**
It works reliably on Linux now, except if it uses wxMessageBox() outside
the GUI thread, it'll crash because non-GUI threads can't open a window
on Linux. I haven't got to fixing that yet. I've been running my
stress test on it and it's functioning normally.
Most of wxWidgets is not thread-safe to use in threads other than the UI
thread, but as a rule of thumb on Windows anything not UI related is OK.
It turns out its more thread-unsafe on GTK. I replaced a bunch of
stuff at once so I don't know if it was just one thing (probably
Repaint), but I have to assume even any wx function that uses wxString
is not safe to use outside the UI thread. So dang, there goes all the
nice wxWidgets portability support functions. I left a few simple
things like wxThread::GetCPUCount() that I checked the source and it's
all numerical, and wxMutex has to be safe or it'd be useless.
There's an issue that if you exit and run it again right away, it can't
bind port 8333. The port frees up after about a minute. Unless I'm
missing something, I am closing the socket before exit, so I don't know
what else I can do. Maybe this is just something about Linux that it
takes a minute to free up a port you had bound. Possibly a security
feature so some trojan doesn't kill the web server and quickly jump into
its place and pick up all the client retries.
Still gotta figure out how to do the xpm version of the icon correctly.
I wonder if the database dat files are interchangeable with Windows.
**Martii Malmi (AKA Sirius) “COPA trial” email #62**
**Date: Sun, 08 Nov 2009 05:23:13 +0000**
**From: Satoshi Nakamoto <satoshin@gmx.com>**
**Subject: Linux build ready for testing (attached)**
**To: Martti Malmi <mmalmi@cc.hut.fi>, Liberty Standard <newlibertystandard@gmail.com>**
bitcoin-linux-0.1.6-test1.tar.bz2 attached
**Martii Malmi (AKA Sirius) “COPA trial” email #63**
**Date: Sun, 08 Nov 2009 05:52:11 +0000**
**From: Satoshi Nakamoto <satoshin@gmx.com>**
**Subject: Linux build ready for testing**
**To: Martti Malmi <mmalmi@cc.hut.fi>, Liberty Standard <newlibertystandard@gmail.com>**
The Linux build is ready for testing on the network. It seems solid. I
sent the executable as an attachment in the previous e-mail, but if the
mail server didn't let it through (it's 12MB), you can download it here:
http://rapidshare.com/files/303914158/linux-0.1.6-test1.tar.bz2.html
**Martii Malmi (AKA Sirius) “COPA trial” email #66**
**Date: Sun, 08 Nov 2009 17:39:39 +0000**
**From: Satoshi Nakamoto <satoshin@gmx.com>**
**Subject: Re: Linux build ready for testing**
**To: Liberty Standard <newlibertystandard@gmail.com>**
**Cc: Martti Malmi <mmalmi@cc.hut.fi>**
In the debug.log, it requests the block list, receives the block list,
then begins uploading the list of blocks requested. It doesn't receive
the blocks, but it didn't run long enough for me to be sure it would
have had time yet. Everything else looks normal.
How long did you run it? It could take a few minutes to start
downloading the blocks. Especially if you're on a cable modem, the
uplink can be much lower bandwidth so it would take some time to upload
the block request list.
If you run it again and it still doesn't download blocks, keep it
running for several hours at least and then send me the debug.log. That
should give it time for my node to connect to you and I could see what
it says on my side and correlate it with your debug.log.
You're right about the minimize on close option, there's no reason that
can't be separate. Martti originally had it separate and I made it a
sub-option, my bad. I'll change it back.
_Liberty Standard wrote:_
_> That is what I meant. The blocks displayed in the status bar did not_
_> increase at all while i ran the program. I have attached my debug.log._
_>_
_> A good way for you to test the tray icon in Gnome is to remove the_
_> notification area and then add it back. If the icon is still displayed_
_> after adding the notification back, then it's working correctly._
_>_
_> I generally set application preferences to not minimize to the tray, but_
_> to close to the tray. And I keep the application minimized. That way I_
_> don't accidentally close the program and still have the convenience of_
_> being able to open the application from the tray. (I don't display open_
_> windows in the 'task bar' but I have an icon that if clicked displays_
_> open windows as sub-menu items.) Then if the tray icon disappears, I go_
_> into the settings disable and re-enable the tray icon setting to get it_
_> to reappear. That's currently not possible with the bitcoin preferences_
_> because the close to tray check mark can not be enabled without the_
_> minimize to tray check box being enabled._
_>_
_>_
_> On Sun, Nov 8, 2009 at 9:08 AM, Satoshi Nakamoto <satoshin@gmx.com_
_> <mailto:satoshin@gmx.com>> wrote:_
_>_
_> Liberty Standard wrote:_
_>_
_> I downloaded it and it runs. It and it is using plenty of CPU,_
_> so I think it's working properly. It has not downloaded_
_> previously generated blocks. Is that a bug or a new feature?_
_>_
_>_
_> If you mean the blocks count in the status bar isn't working its way_
_> up to around 26600, then that's a bug, you should send me your_
_> debug.log. (which is at ~/.bitcoin/debug.log)_
_>_
_>_
_> The system tray in Gnome is not very reliable. Sometimes an icon_
_> will disappear leaving no way to get back to the program. I have_
_> verified that this can happen with bitcoin. It would be nice if_
_> starting bitcoin while it's already running would just bring up_
_> the GUI of the already running bitcoin process._
_>_
_>_
_> We haven't figured out how to find and bring up the existing running_
_> program yet on Linux like it does on Windows. Given what you say, I_
_> should at least turn off the minimize to tray option initially by_
_> default._
_>_
**Martii Malmi (AKA Sirius) “COPA trial” email #67**
**Date: Sun, 08 Nov 2009 18:48:38 +0000**
**From: Satoshi Nakamoto <satoshin@gmx.com>**
**Subject: Re: Forum**
**To: mmalmi@cc.hut.fi**
I'm not really a fan of that type of forum layout. The thread list only
fits about 4 threads on a page, posts are treated like news articles or
blog posts with reply comments at the bottom. It's more of a social
networking site, not really conducive to technical discussion.
I'm thinking phpBB or IPB or similar. One line of text per thread,
small fonts, efficient use of vertical space. Most people are already
familiar with the interface.
mmalmi@cc.hut.fi wrote:
> I made a ning.com site for testing: bitcoin.ning.com. At least it's
> there to get Google hits, even if we didn't use it.
>
**Martii Malmi (AKA Sirius) “COPA trial” email #68**
**Date: Mon, 09 Nov 2009 01:23:59 +0000**
**From: Satoshi Nakamoto <satoshin@gmx.com>**
**Subject: Re: Linux build ready for testing**
**To: Liberty Standard <newlibertystandard@gmail.com>**
**Cc: Martti Malmi <mmalmi@cc.hut.fi>**
_Liberty Standard wrote:_
_> Ok, blocks have now started to increase. It definitely takes longer for_
_> them to start increasing than with the Windows version. Also, I think_
_> they might be increasing at a slower rate than in with the Windows_
_> version. Is there perhaps debugging enabled in the Linux build that you_
_> sent me? Block are increasing at about 15 blocks per second (eyeball_
_> estimate while looking at a clock). I didn't time how fast they_
_> increased in the Windows version, but it seems like it was much faster._
About how long did it take to start? It could be the node that you
happened to request from is slow. The slow start is consistent with the
slow download speed.
I'd like to look at your current debug.log file and try to understand
what's going. It might just be a really slow connection on the other
side, or maybe something's wrong and failed and retried. Taking too
long could confuse other users.
Martti, how long did it take to start downloading blocks when you ran
it, and how fast did it download?
_> When I launch bitcoin and the bitcoin port is not available, I get_
_> the following messages to the command line. I don't get those_
_> messages when the bitcoin port is available. Would it be possible_
_> for bitcoin to pick another port if the default port is taken? The_
_> same think sometimes happens to me with my BitTorrent client. When I_
_> restart it, my previously open port is closed. All I have to do is_
_> change the port and it starts working again._
_>_
_> /usr/lib/gio/modules/libgvfsdbus.so: wrong ELF class: ELFCLASS64_
_> Failed to load module: /usr/lib/gio/modules/libgvfsdbus.so_
_> /usr/lib/gio/modules/libgioremote-volume-monitor.so: wrong ELF_
_> class: ELFCLASS64_
_> Failed to load module:_
_> /usr/lib/gio/modules/libgioremote-volume-monitor.so_
_> /usr/lib/gio/modules/libgiogconf.so: wrong ELF class: ELFCLASS64_
_> Failed to load module: /usr/lib/gio/modules/libgiogconf.so_
It already uses SO_REUSEADDR so it can bind to the port if it's in
TIME_WAIT state after being closed. The only time it should fail to
bind is when the program really is already running. It's important that
two copies of Bitcoin not run on the same machine at once because they
would be modifying the database at the same time. There is never any
need to run two on one machine as coin generation will now use multiple
processors automatically.
I'm not sure what those lib errors are, I'll do some searching.
**Martii Malmi (AKA Sirius) “COPA trial” email #69**
**Date: Mon, 09 Nov 2009 05:42:59 +0000**
**From: Satoshi Nakamoto <satoshin@gmx.com>**
**Subject: Re: Linux build ready for testing**
**To: Liberty Standard <newlibertystandard@gmail.com>**
**Cc: Martti Malmi <mmalmi@cc.hut.fi>**
Thanks for that, I see what happened. Because the first one was slow,
it ended up requesting the blocks from everybody else, which only bogged
everything down. I can fix this, I just need to think a while about the
right way.
There's no risk in shutting down while there are unconfirmed. When you
make a transaction or new block, it immediately broadcasts it to the
network. After that, the increasing #/confirmed number is just
monitoring the outcome. There's nothing your node does during that time
to promote the acceptance.
Now that I think about it, when you close Bitcoin, it closes the main
window immediately but in the background continues running to finish an
orderly flush and shutdown of the database. Before I implemented that,
it was annoying having a dead hung unresponsive window hanging around.
Until it finishes the orderly shutdown in the background, the port would
be locked, and this is an important protection to make sure another copy
can't touch the database until it's done. I haven't seen the shutdown
take more than a few seconds.
In Wine, there's no way for the Windows version to do SO_REUSEADDR, so
that would add 60 seconds (on my system) of TIME_WAIT after the port is
closed.
If you need to transfer between two copies, you could send it to the
other's bitcoin address. The receiving copy doesn't have to be online
at the time.
The command line to use a different data directory is
bitcoin -datadir=<directory>
For example, on Linux, the default directory is (don't use ~)
bitcoin -datadir=/home/yourusername/.bitcoin
You shouldn't normally have any need to use this switch. It still won't
let you run two instances at once.
Liberty Standard wrote:
> On Mon, Nov 9, 2009 at 3:23 AM, Satoshi Nakamoto <satoshin@gmx.com
> <mailto:satoshin@gmx.com>> wrote:
>
> Liberty Standard wrote:
>
> Ok, blocks have now started to increase. It definitely takes
> longer for them to start increasing than with the Windows
> version. Also, I think they might be increasing at a slower rate
> than in with the Windows version. Is there perhaps debugging
> enabled in the Linux build that you sent me? Block are
> increasing at about 15 blocks per second (eyeball estimate while
> looking at a clock). I didn't time how fast they increased in
> the Windows version, but it seems like it was much faster.
>
>
> About how long did it take to start? It could be the node that you
> happened to request from is slow. The slow start is consistent with
> the slow download speed.
>
**Martii Malmi (AKA Sirius) “COPA trial” email #71**
**Date: Mon, 09 Nov 2009 19:30:53 +0000**
**From: Satoshi Nakamoto <satoshin@gmx.com>**
**Subject: Re: Linux build ready for testing**
**To: Liberty Standard <newlibertystandard@gmail.com>**
**Cc: Martti Malmi <mmalmi@cc.hut.fi>**
You really don't want to keep running in Wine, you're getting database
errors (db.log). You probably developed these rituals of transferring
to a fresh install to cope with database corruption. If there is a way
to lose unconfirmed blocks, it would have to be the database errors.
Any problems you find in the Linux build can be fixed. The Wine
incompatibility deep inside Berkeley DB is unfixable.
I think GCC 4.3.3 on the Linux build optimized the SHA-256 code better
than the old GCC 3.4.5 on Windows. When I was looking for the best
SHA-256 code, there was a lot of hand tuned highly optimized SHA1 code
available, but not so much for SHA-256 yet. I should see if I can
upgrade MinGW to 4.3.x to get them on a level playing field.
Liberty Standard wrote:
> Everyone that contributed to making this Linux build really did a great
> job! Thanks for the hard work. It has started maturing some bitcoins, so
> I'm going to continue to run the Linux client for the time being until I
> decide whether it's at least as good or better at generating coins than
> the Windows version running in Wine.
>
>
> On Mon, Nov 9, 2009 at 8:59 AM, Liberty Standard
> <newlibertystandard@gmail.com <mailto:newlibertystandard@gmail.com>> wrote:
>
> Another instance when I would like to run multiple instances is when
> I upgrade bitcoin. I will uncheck the generate coin check box in the
> outdated bitcoin, launch and start generating coins in the new
> bitcoin using a separate data directory, then when the old
> application's coins have matured I will send them to the new
> application and then close the old application. I prefer do do clean
> installs rather than upgrading while maintaining old data.
>
**Martii Malmi (AKA Sirius) “COPA trial” email #72**
**Date: Mon, 09 Nov 2009 19:41:11 +0000**
**From: Satoshi Nakamoto <satoshin@gmx.com>**
**Subject: Re: Linux build ready for testing**
**To: mmalmi@cc.hut.fi**
**Cc: Liberty Standard <newlibertystandard@gmail.com>**
You got a lot done with the Linux build, autostart, minimize to tray,
setup and everything, it's really appreciated. Good luck on your C++
project.
_mmalmi@cc.hut.fi wrote:_
_> I'll have to focus on a school project (coincidentally C++ coding) for_
_> about a month now, so I don't have that much time for active developing_
_> until December. Let's keep contact anyway._
_>_
**Martii Malmi (AKA Sirius) “COPA trial” email #73**
**Date: Tue, 10 Nov 2009 16:46:04 +0000**
**From: Satoshi Nakamoto <satoshin@gmx.com>**
**Subject: Re: Linux - dead sockets problem**
**To: Liberty Standard <newlibertystandard@gmail.com>**
**Cc: Martti Malmi <mmalmi@cc.hut.fi>**
I see what happened. All your sockets went dead somehow. You had no
communication with the network, but because you had 8 zombie
connections, it thought it was still online and kept generating blocks.
You can tell this is happening when your blocks are numbered
sequentially, without other people's blocks interspersed, like:
2/unconfirmed
3/unconfirmed
4/unconfirmed
5/unconfirmed
6 blocks
7 blocks
It's implausible that you would be the only one to find blocks for 6
blocks in a row like that.
When you exited and restarted, it connected and downloaded 45 blocks
that the network found in your absence. Since your blocks were not
broadcast to the network immediately, the network went on without them.
It sounds like you had exactly the same problem on Wine. There's
clearly something about socket handling on Linux that's effecting it
either way.
I'll start researching this. Ultimately if I can't find the root of the
problem, I'll have to make some kind of mechanism to watch for an
absence of messages and disconnect. The only workaround for you right
now would be to exit and restart more often.
All but one of your node connections went dead at the same time, one
shortly after. IRC was still working, so it wasn't that you were
offline from the internet.
I wonder if the status of blocks should say "#/unconfirmed" all the way
up to maturity (119/unconfirmed then 120 blocks) instead. The meaning
of the number isn't as strong for blocks as for transactions.
I think it would be an improvement not to count one's own blocks as
confirmations. A drawback would be that the status numbers shown by
different nodes would not match. The status number would no longer be
coordinated with the maturity countdown on blocks either. A lighter
option would be a special case only if all confirmations are your own.
Liberty Standard wrote:
> I just lost 6 sets of maturing coins! I had 10 sets of bitcoins
> maturing. The last set was generated at about 0:22. It got to
> 2/unconfirmed before bitcoin got stuck. At 10:10, the bitcoin which was
> generated at 0:22 was still only at 2/unconfirmed. Since you had told me
> that I wasn't going to lose coins, I shutdown and restarted bitcoin. On
> the bright side, it shutdown and started up very smoothly. But
> unfortunately, when the blocks updated, I lost 6 sets of bitcoins. Four
> sets were still unconfirmed, but two sets were confirmed. And there's no
> trace of them now. Perhaps now that you have the 'Show Generated Coins'
> option available, you can put back in failed bitcoin generations. I just
> don't like that those bitcoins just disappeared into thin air. I'm still
> running the Linux build at the moment, but the Wine version is suddenly
> looking much more attractive now that 6 out of the 10 sets of bitcoins I
> generated in the past 24 hours just vanished. I've included my debug.log.
>
**Martii Malmi (AKA Sirius) “COPA trial” email #74**
**Date: Wed, 11 Nov 2009 00:39:19 +0000**
**From: Satoshi Nakamoto <satoshin@gmx.com>**
**Subject: Re: Linux - linux-0.1.6-test2**
**To: Liberty Standard <newlibertystandard@gmail.com>**
**Cc: Martti Malmi <mmalmi@cc.hut.fi>**
I fixed a few places I found where it was possible for a socket to get
an error and not get disconnected. If your connections go dead again,
it should disconnect and reconnect them. I also implemented an
inactivity timeout as a fallback.
This also includes a partial fix for the slow initial block download.
You should run with the "-debug" switch to get some additional debug.log
information I added that'll help if there are more problems.
linux-0.1.6-test2.tar.bz2 12,134,012 bytes
Download:
http://rapidshare.com/files/305231818/linux-0.1.6-test2.tar.bz2.html
**Martii Malmi (AKA Sirius) “COPA trial” email #75**
**Date: Wed, 11 Nov 2009 00:41:06 +0000**
**From: Satoshi Nakamoto <satoshin@gmx.com>**
**Subject: Re: Linux - linux-0.1.6-test2 attachment**
**To: Liberty Standard <newlibertystandard@gmail.com>**
**Cc: Martti Malmi <mmalmi@cc.hut.fi>**
linux-0.1.6-test2.tar.bz2 attached
**Martii Malmi (AKA Sirius) “COPA trial” email #76**
**Date: Thu, 12 Nov 2009 05:36:06 +0000**
**From: Satoshi Nakamoto <satoshin@gmx.com>**
**Subject: Linux - linux-0.1.6-test3**
**To: Liberty Standard <newlibertystandard@gmail.com>**
**Cc: Martti Malmi <mmalmi@cc.hut.fi>**
Right now (04:50 GMT) my node is connecting to yours and getting zombie
connections each time. The socket isn't returning an error, just zombie
without notice. If you're running the linux build right now, it would
be interesting to see what the log says on your side.
test3:
I've added specific code to detect zombie sockets. It'll detect if the
socket hasn't sent or received any data within 60 seconds of connecting,
and detect if data is queued to send and hasn't sent for 3 minutes.
I think I may have weakened the reconnect speed in test2. In test3 I'm
making it more determined to reconnect quickly.
I added checking to track whether other nodes received your generated
blocks. If none did, it'll warn you in the description:
"Generated - Warning: This block was not received by any other nodes and
will probably not be accepted!"
The status can go to "#/offline?" for blocks or transactions you create
if they don't get out to any other nodes.
With all this, it should be impossible not to notice as soon as it
screws up. It should hopefully disconnect all the zombie sockets.
After that, whether it's able to make some good connections, or sockets
is completely hosed and it stays at 0 connections, I don't know.
If this doesn't work, I guess I'll look at the sourcecode of some other
P2P apps like BitTorrent and see how they deal with this stuff. Maybe
there's some magic flag or procedure to bash the sockets system back to
life.
File linux-0.1.6-test3.tar.bz2 attached in the next message.
_Liberty Standard wrote:_
_> On Wed, Nov 11, 2009 at 8:08 AM, Liberty Standard_
_> <newlibertystandard@gmail.com <mailto:newlibertystandard@gmail.com>> wrote:_
_>_
_> My network connection is direct to my computer. My ISP requires that_
_> I run VPN to connect to the Internet. I then have a second NIC that_
_> shares my Internet with other devices. My IP address while using my_
_> computer is my actual IP address, but the devices connected through_
_> my second NIC use NAT. When I connect through a virtual machine,_
_> that also uses NAT. All this requires very little configuration._
_> NetworkManager in Ubuntu has an option to share my Internet_
_> connection through the second NIC and VirtualBox has the option to_
_> use NAT._
_>_
_> I lost a couple packs of bitcoins again, so that problem is not yet_
_> fixed. It's a bit more bearable now that I have an idea of what is_
_> going on. I figure for now I'll just restart bitcoin whenever I see_
_> a pack of bitcoins starting to mature. I may go back and forth a bit_
_> between Linux and Wine, but I'll definitely test every new version_
_> that comes out. At the moment I'm still running the Linux build._
_>_
**Martii Malmi (AKA Sirius) “COPA trial” email #77**
**Date: Thu, 12 Nov 2009 05:37:58 +0000**
**From: Satoshi Nakamoto <satoshin@gmx.com>**
**Subject: linux-0.1.6-test3.tar.bz2 attached**
**To: Liberty Standard <newlibertystandard@gmail.com>**
**Cc: Martti Malmi <mmalmi@cc.hut.fi>**
File linux-0.1.6-test3.tar.bz2 attached
linux-0.1.6-test3.tar.bz2 12,143,473 bytes
**Martii Malmi (AKA Sirius) “COPA trial” email #78**
**Date: Thu, 12 Nov 2009 23:39:44 +0000**
**From: Satoshi Nakamoto <satoshin@gmx.com>**
**Subject: linux-0.1.6-test5 fix for zombie sockets**
**To: Liberty Standard <newlibertystandard@gmail.com>**
**Cc: Martti Malmi <mmalmi@cc.hut.fi>**
test 5:
I added MSG_DONTWAIT to the send and recv calls in case they forgot the
socket is non-blocking. If that doesn't work, there's now the catch-all
solution: another thread monitors the send/recv thread and terminates
and restarts it if it stops. It prints "*** Restarting
ThreadSocketHandler ***" in debug.log, and an error message displays on
the status bar for a while.
Before terminating, it tries closing the socket that's hung. If that
works, it doesn't have to resort to terminating.
I ran a test where it terminated the thread about 1000 times without
trouble, so it should be safe. The terminate on linux is
pthread_cancel, which throws it into C++'s exception handler.
The thread calls we were using didn't have terminate, so I created our
own wrappers in util.h to use CreateThread on windows and pthread_create
on linux, instead of:
_beginthread is windows only and lacks terminate
boost::thread is really attractive, but lacks terminate
wxThread requires you to create a class for every function you might
call (yuck)
File attached in the next e-mail
**Martii Malmi (AKA Sirius) “COPA trial” email #79**
Date: Thu, 12 Nov 2009 23:42:29 +0000
From: Satoshi Nakamoto <satoshin@gmx.com>
Subject: linux-0.1.6-test5.tar.bz2 attached
To: Liberty Standard <newlibertystandard@gmail.com>
Cc: Martti Malmi <mmalmi@cc.hut.fi>
12,033,918 linux-0.1.6-test5.tar.bz2
**Martii Malmi (AKA Sirius) “COPA trial” email #80**
**Date: Sat, 14 Nov 2009 05:46:22 +0000**
**From: Satoshi Nakamoto <satoshin@gmx.com>**
**Subject: Zetaboards forum**
**To: Martti Malmi <mmalmi@cc.hut.fi>**
I created a forum on Zetaboards, InvisionFree's new site that they're
migrating to.
http://s1.zetaboards.com/Bitcoin/index/
I made an admin account you can use to upgrade your own account to admin:
u: admin
pw: B98VzUUA
BTW, the admin pages have a huge blank space at the top, you have to
scroll down.
It doesn't support SSL, but none of them do. I replaced the ugly
default orange and blue theme with the Frostee theme, which was the only
decent looking theme I could find after extensive searching. Searching
for themes is futile, there are thousands of rubbish themes. It turns
out the solution is to look at button sets instead
(http://resources.zetaboards.com/forum/1000328/)
I only created two subforums to begin with. I'll create new ones as the
need arises. I like to start with a flat namespace until there's enough
items to justify subsections. Technical Support makes sense as a
separate section to get that stuff out of the main spotlight so our
dirty laundry isn't in everyone's face, and to make people feel more
free to report bugs there. Mostly only devs and people checking on a
bug need read the Technical Support section.
**Martii Malmi (AKA Sirius) “COPA trial” email #81**
**Date: Sun, 15 Nov 2009 15:40:29 +0000**
**From: Satoshi Nakamoto <satoshin@gmx.com>**
**Subject: Linux update**
**To: Martti Malmi <mmalmi@cc.hut.fi>**
linux-0.1.6-test5 solved Liberty's zombie socket problem. The
MSG_DONTWAIT fixed the root cause, it's not having to terminate and
restart the thread. The sockets are marked non-blocking already, so I
don't understand why. Maybe it forgot. I suppose if a socket fails and
the OS closes it then there's nothing left to remember it was
non-blocking, but then accessing a closed handle should return
immediately with an error. There's no MSG_DONTWAIT on Windows, marking
the socket as nonblocking is the only way, so if anyone runs the Windows
version in Wine it will have to rely on terminating the thread.
The only problem now is the DB exceptions he's getting.
************************
EXCEPTION: 11DbException
Db::open: Bad file descriptor
bitcoin in ThreadMessageHandler()
************************
EXCEPTION: 11DbException
Db::close: Bad file descriptor
bitcoin in ThreadMessageHandler()
I had expected those to be a Wine problem, but he's getting them on
Linux just the same. He tried moving the datadir to a different drive,
no help. I've never gotten them. I'm running a stress test that
continuously generates a lot of activity and DB access and never got it.
He has Ubuntu 64-bit and I have 32-bit, so I'm assuming that's the
difference. Is your Linux machine 64-bit or 32-bit? Have you ever had
a DB exception? (see db.log also) Now that the zombie problem is fixed
in test5, could you start running it on your Linux machine? We could
use a 3rd vote to get a better idea of what we're dealing with here.
The DB exception is uncaught, so it'll stop the program if you get it.
BTW, zetaboards insists on displaying "Member #", so you better sign up
soon and grab a good account number.
**Martii Malmi (AKA Sirius) “COPA trial” email #83**
**Date: Sun, 15 Nov 2009 19:15:42 +0000**
**From: Satoshi Nakamoto <satoshin@gmx.com>**
**Subject: Re: Linux update**
**To: mmalmi@cc.hut.fi**
I'd better install 64-bit then. I imagine it's something about the
32-bit version of Berkeley DB on 64-bit Linux.
BTW, in things like the feature list credits, do you want me to refer to
you as sirius-m or Martti Malmi? I think most projects go by real names
for consistency.
**Martii Malmi (AKA Sirius) “COPA trial” email #85**
**Date: Sun, 15 Nov 2009 20:25:26 +0000**
**From: Satoshi Nakamoto <satoshin@gmx.com>**
**Subject: Re: Linux update**
**To: mmalmi@cc.hut.fi**
At first glance, bitcoinshop.com looks better. bitcoinexchange.com
might be better than bitcoinx.com.
Be careful where you search domain names, many will front-run you. Even
network solutions, although they've said they won't if you use their
whois page not the homepage. The only safe place is
http://www.internic.com/whois.html
mmalmi@cc.hut.fi wrote:
> Perhaps the real name is better.
>
> Another name question: I've been thinking of a name for the exchange
> service, and I came up with Bitcoin X (bitcoinx.com) and Bitcoin Shop
> (bitcoinshop.com). Which one do you find better?
>
**Martii Malmi (AKA Sirius) “COPA trial” email #86**
**Date: Mon, 16 Nov 2009 06:20:52 +0000**
**From: Satoshi Nakamoto <satoshin@gmx.com>**
**Subject: Re: Db::open/Db::close "Bad file descriptor" exception**
**To: Liberty Standard <newlibertystandard@gmail.com>**
**Cc: Martti Malmi <mmalmi@cc.hut.fi>**
I have an idea for a workaround, but it depends on what files the errors
are on. If you've accumulated several errors in db.log, could you send
it to me? (even if it's rather simple and boring) Is the file listed
always blkindex.dat, or does it include addr.dat or wallet.dat too?
Liberty Standard wrote:
> I moved the data directory back to my SSD card and started bitcoin test
> 6. It encountered a segmentation fault today with Db::open in the log. I
> had changed the settings to only use one processor/core while I watched
> a 720p mkv movie. I noticed the segmentation fault after the film had ended.
>
> On Sun, Nov 15, 2009 at 12:45 AM, Satoshi Nakamoto <satoshin@gmx.com
> <mailto:satoshin@gmx.com>> wrote:
>
> Here's one where I linked Berkeley DB a different way. It's worth a
> try. Otherwise identical to test5.
>
> (Keep the datadir on the hard drive at least until you get it to
> fail the same way there. That has a fair chance of success.)
>
**Martii Malmi (AKA Sirius) “COPA trial” email #88**
**Date: Mon, 16 Nov 2009 19:34:56 +0000**
**From: Satoshi Nakamoto <satoshin@gmx.com>**
**Subject: Re: Forum**
**To: mmalmi@cc.hut.fi**
_mmalmi@cc.hut.fi wrote:_
_> I installed a TikiWiki on my VPS at 174.143.149.98. SSL is currently_
_> enabled with a self-signed certificate. Admin password is the same as in_
_> the Bitweaver. How about using this as the site platform? Maybe we can_
_> make bitcoin.org or at least bitcoin.sf.net point there?_
What do you see as the benefits of switching the wiki?
Some I can think of:
SSL
get away from sourceforge's unreliable hosting
everything not logged by sourceforge
The forum feature is about as weak as bitweaver. We need a full blown
forum software for that.
My priority right now is to get a forum going, either phpBB or similar.
What do you think of the zetaboards option? Should we go ahead with that?
**Martii Malmi (AKA Sirius) “COPA trial” email #90**
**Date: Mon, 16 Nov 2009 21:10:22 +0000**
**From: Satoshi Nakamoto <satoshin@gmx.com>**
**Subject: Re: Forum**
**To: mmalmi@cc.hut.fi**
That's a good idea to go in a more web-publishing CMS type direction
like Drupal. That's a better fit and can produce a better looking
website than a wiki. I think I was wrong about wiki. Only a few
specific people will do any website design work and those people can go
ahead and have a separate login. In that case, login integration with
the forum doesn't matter much. For security, I'd almost rather have a
different login than be constantly checking the forum with the same
login that could pwn the website.
Drupal's forum is less bad than the wikis, but still a long way from
something I would want to use.
zetaboards pros and cons:
pros:
- we don't have to worry about bandwidth
- they handle the backend management and security patches
con:
- lack of SSL
- lack of privacy, everything is logged
- lack of control over the php code for customization
- no CAPTCHA, and if they add one later it might be unacceptable flash
- ads (could pay to get rid of them later if we care enough)
- there's always the risk they abruptly cancel the site for some petty
reason
_mmalmi@cc.hut.fi wrote:_
>> What do you see as the benefits of switching the wiki?
>> Some I can think of:
>> SSL
>> get away from sourceforge's unreliable hosting
>> everything not logged by sourceforge
_>_
_> I think the biggest advantage is having a single site so you don't need_
_> a separate account for the wiki and the forum, and the functionalities_
_> are also nicely integrated with the main site itself. Also being ad-free_
_> is a plus._
_>_
>> The forum feature is about as weak as bitweaver. We need a full blown
>> forum software for that.
_>_
_> How about Drupal's forum functionality? Address:_
_> https://174.143.149.98/drupal/. The CMS in general looks better and_
_> simpler than TikiWiki. If the forum's not good enough, then we can of_
_> course use a specialized forum software like phpBB._
_>_
>> My priority right now is to get a forum going, either phpBB or similar.
>> What do you think of the zetaboards option? Should we go ahead with
>> that?
_>_
_> Otherwise fine, but the ads and the lack of SSL are a minus._
_>_
**Martii Malmi (AKA Sirius) “COPA trial” email #91**
**Date: Tue, 17 Nov 2009 03:41:26 +0000**
**From: Satoshi Nakamoto <satoshin@gmx.com>**
**Subject: linux-0.1.6-test7**
**To: Liberty Standard <newlibertystandard@gmail.com>**
**Cc: Martti Malmi <mmalmi@cc.hut.fi>**
test 7:
Backup your data directory before running this, just in case.
Workaround for the Db::open/Db::close "Bad file descriptor" exception.
Might also make the initial block download faster. The workaround is to
open the database handles and keep them open for the duration of the
program, which is actually the more common thing to do anyway. If we're
not closing and opening all the time, the error shouldn't get a chance
to happen.
The one exception is wallet.dat, which I still close after writing is
finished so I can flush the transaction logs into the dat file, making
the dat file standalone. That way if someone does a backup while
Bitcoin is running, they'll get a wallet.dat that is valid by itself
without the database transaction logs.
This is a restructuring of the database handling, so we might find some
new deadlocks. Usually if it deadlocks, either the UI will stop
repainting, or it'll stop using CPU even though it still says Generating.
**Martii Malmi (AKA Sirius) “COPA trial” email #92**
**Date: Tue, 17 Nov 2009 16:57:26 +0000**
**From: Satoshi Nakamoto <satoshin@gmx.com>**
**Subject: Re: Forum**
**To: mmalmi@cc.hut.fi**
_mmalmi@cc.hut.fi wrote:_
_> How about Drupal's forum functionality? Address:_
_> https://174.143.149.98/drupal/. The CMS in general looks better and_
_> simpler than TikiWiki. If the forum's not good enough, then we can of_
_> course use a specialized forum software like phpBB._
Another issue I thought of with zetaboards: most free forum sites won't
let you export the user account database if you want to move. I don't
know why I don't see any other software projects using a free forum, but
I have to assume there might be a reason we would discover later.
If you can install phpBB3 on your VPS, that's probably the better option.
From what I've seen on other forums, if the cost of bandwidth becomes
an issue, a small Google Adwords (text links) at the top generates more
than the cost of bandwidth even for very low value traffic like gaming.
This would be much higher value traffic well targeted for high paying
gold merchant keywords and VPN hosts. It could eventually be a valuable
revenue stream you wouldn't want to give away to some free site.
I want to pre-announce some of the features in version 0.2 on the forum
and try to get some anticipation going. Even if hardly anyone else is
posting, I have seen project forums where most of the posts are the
author announcing what's going on with the latest changes. Users can
see progress going on, see that it's improving and supported and not
abandonware. It's a little like a blog in that case, but easier for
users to use it as a searchable FAQ and better organized. Whenever I
google search software questions, most of the hits are forum posts.
**Martii Malmi (AKA Sirius) “COPA trial” email #95**
**Date: Wed, 18 Nov 2009 04:35:32 +0000**
**From: Satoshi Nakamoto <satoshin@gmx.com>**
**Subject: Re: linux-0.1.6-test7**
**To: Liberty Standard <newlibertystandard@gmail.com>**
**Cc: Martti Malmi <mmalmi@cc.hut.fi>**
Finally an easy one. I see a way that could happen on a long operation
such as the initial download. The TryLock bug is unrelated to the db
stuff. Fix will be in test8.
I've been able to reproduce the db::open/close exception 3 times now on
32-bit linux by hitting it with a continuous flood of non-stop requests.
It looks like even periodically closing the wallet.dat database to
flush it gets the db::close exceptions. I'm disabling the wallet flush
feature on Linux. On Linux we'll never close a database handle until
we're ready to exit. So far with this disabled, no exceptions.
I'm also implementing the orderly initial block download. Instead of
naively requesting all the blocks at once, it'll request batches of 500
at a time. This way, it'll receive the blocks before the retry timeout,
so it shouldn't go requesting it from other nodes unless it actually
doesn't receive them or it's too slow. The change is in the requestee's
side, so this functionality won't be visible until your initial block
download is coming from a node that has the new version.
I'm going to test this some more before sending test8.
_Liberty Standard wrote:_
_> I started with a fresh data directory with test7. Blocks started to_
_> download much faster. It only took about 15 seconds where it took a few_
_> minutes previously with the Linux build. It crashed once while it was_
_> downloading blocks with the following message in the terminal._
_>_
_> ../include/wx/thrimpl.cpp(50): assert "m_internal" failed in TryLock():_
_> wxMutex::TryLock(): not initialized [in child thread]_
_> Trace/breakpoint trap_
_>_
_> I've included my log file, but I forgot to back it up before restarting_
_> bitcoin, so I'm not sure at what point in the log file the crash occurred._
_>_
_> Fortunately I haven't encountered the segmentation fault yet. The_
_> frequency of segmentation faults in the previous builds varied quite a_
_> bit, so I'll keep running it and let you know if i run into any problems._
_>_
**Martii Malmi (AKA Sirius) “COPA trial” email #96**
**Date: Wed, 18 Nov 2009 05:14:45 +0000**
**From: Satoshi Nakamoto <satoshin@gmx.com>**
**Subject: Re: Db::open/Db::close "Bad file descriptor" exception**
**To: mmalmi@cc.hut.fi**
Thanks. The db::open/close errors confirm the pattern.
More interesting is the zombie sockets activity towards the end, and the
socket thread monitor tripped but didn't get it going again. Was the
machine disconnected from the net? MSG_DONTWAIT in test5 solved the
zombie problem for Liberty. What test version were you running? (I
should print the test version in the log)
mmalmi@cc.hut.fi wrote:
> Here's the logs in case they're still useful.
>
>> I have an idea for a workaround, but it depends on what files the
>> errors are on. If you've accumulated several errors in db.log, could
>> you send it to me? (even if it's rather simple and boring) Is the file
>> listed always blkindex.dat, or does it include addr.dat or wallet.dat
>> too?
>
**Martii Malmi (AKA Sirius) “COPA trial” email #97**
**Date: Wed, 18 Nov 2009 05:32:22 +0000**
**From: Satoshi Nakamoto <satoshin@gmx.com>**
**Subject: Re: Forum**
**To: mmalmi@cc.hut.fi**
That's great, this is going to fun! I'll research what people say about
the two.
mmalmi@cc.hut.fi wrote:
> I installed both phpBB3 and Simple Machines Forum, which are kind of
> the market leaders among the open source forums. SMF's interface looks
> better on the first look, especially the admin panel. What do you
> think, shall we go with SMF or phpBB3?
>
**Martii Malmi (AKA Sirius) “COPA trial” email #99**
**Date: Fri, 20 Nov 2009 05:14:56 +0000**
**From: Satoshi Nakamoto <satoshin@gmx.com>**
**Subject: SMF forum, need a mod installed**
**To: Martti Malmi <mmalmi@cc.hut.fi>**
I've been configuring the SMF forum. They're saying SMF is better
written than phpBB and more reliable, so if I can get SMF to look right,
that's the preferable choice.
Most forums run vBulletin (big-boards.com lists 1376 vBulletin, 275
Invision, 245 phpBB and 41 SMF), so if you don't look like vBulletin or
Invision, it looks like you compromised because you couldn't afford
vBulletin. SMF's UI started out further away from the standard look,
but I've been able to use CSS to make it look more like the others.
I've done as much as I can with CSS, the rest requires editing PHP files
and uploading images. The forum doesn't have a built in file
upload/edit admin feature, it's added separately as the SMF File Manager
mod. I uploaded the mod but some files need to be chmod 777 so it can
install. If you go to Admin->Packages->Browse Packages and click on
Apply Mod, it offers to do it automatically if you enter an ftp login.
Someone says you might also have to
mkdir /var/www/bitcoin/smf/packages/temp
The error in the error log is:
failed to open stream: Permission denied
File: /var/www/bitcoin/smf/Sources/Subs-Package.php
(I'm sure that's just the first file)
Is it OK to go live with this SMF installation when I'm finished
configuring it? I should be able to point forum.bitcoin.org to it.
Liberty reports that linux-test8 has been running smoothly. My tests
have been running fine as well. The Linux version looks fully
stabilized to me.
Good news: he says he made his first sale of bitcoins. Someone bought
out all he had. I had been wondering whether it would be buyers or sellers.
----
