이메일 #066 - #070
원본 출처: Satoshi - Sirius emails 2009-2011
이메일 #066
Date: Sun, 08 Nov 2009 17:39:39 +0000
From: Satoshi Nakamoto <[email protected]>
Subject: Re: Linux build ready for testing
To: Liberty Standard <[email protected]>
Cc: Martti Malmi <[email protected]>
영어 원문
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 <[email protected]
> <mailto:[email protected]>> 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.
>
>
이메일 #067
Date: Sun, 08 Nov 2009 18:48:38 +0000
From: Satoshi Nakamoto <[email protected]>
Subject: Re: Forum
To: [email protected]
영어 원문
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.
[email protected] 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.
>
>> 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.
>
>
>
이메일 #068
Date: Mon, 09 Nov 2009 01:23:59 +0000
From: Satoshi Nakamoto <[email protected]>
Subject: Re: Linux build ready for testing
To: Liberty Standard <[email protected]>
Cc: Martti Malmi <[email protected]>
영어 원문
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.
이메일 #069
Date: Mon, 09 Nov 2009 05:42:59 +0000
From: Satoshi Nakamoto <[email protected]>
Subject: Re: Linux build ready for testing
To: Liberty Standard <[email protected]>
Cc: Martti Malmi <[email protected]>
영어 원문
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 <[email protected]
> <mailto:[email protected]>> 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.
>
>
> It took about a half hour for it to start incrementing quickly.
> Interestingly, the CPU usage increased before it started to increment
> steadily and then lowered when it started to increment steadily.
> Although this time the block incremented to 2 within the first few
> minutes. I have not yet generated any bitcoins. I'll wait for as long as
> I have patience to generate a bitcoin, but if none are created by the
> time I lose patience, I'm going to move back to the wine version.
>
> 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.
>
>
> I've included my current debug.log.
>
>
> 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.
>
>
> The reason I run two instances at the same time is to transfer bitcoins
> from one bitcoin instance to another. They of course would need to be
> accessing different data directories. Perhaps that could be specified as
> a command line argument. I currently have to move my bitcoin data folder
> to a virtual machine to do this. Shutting down bitcoin and restarting it
> with a different data directory is a poor solution because shutting down
> bitcoin while there are unconfirmed bitcoins risks losing those bitcoins.
>
> Bitcoin was definitely not running when i get the busy port error. The
> process closes quickly and reliably from my experience, but it takes
> anywhere from 30 seconds to 3 minutes (estimation from memory) for the
> port to become available again. It occurred while switching from bitcoin
> 0.1.5 in Wine to the Linux build and again while switching from the
> Linux build to bitcoin 0.1.5 in Wine.
>
> Another thing that I noticed is that the about dialog text does not fit
> correctly and it cannot be resized.
>
> I'm not sure what those lib errors are, I'll do some searching.
>
>
이메일 #070
Date: Mon, 09 Nov 2009 10:32:08 +0200
From: [email protected]
To: Satoshi Nakamoto <[email protected]>
Cc: Liberty Standard <[email protected]>
Subject: Re: Linux build ready for testing
영어 원문
> Martti, how long did it take to start downloading blocks when you ran
> it, and how fast did it download?
Started very quickly when I got connected and downloaded quicker than
my Windows PC, which has a slower CPU.
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.
> 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.