이메일 #071 - #075
원본 출처: Satoshi - Sirius emails 2009-2011
이메일 #071
Date: Mon, 09 Nov 2009 19:30:53 +0000
From: Satoshi Nakamoto <[email protected]>
Subject: Re: Linux build ready for testing
To: Liberty Standard <[email protected]>
Cc: Martti Malmi <[email protected]>
영어 원문
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
> <[email protected] <mailto:[email protected]>> 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.
>
>
>
> On Mon, Nov 9, 2009 at 7:42 AM, Satoshi Nakamoto <[email protected]
> <mailto:[email protected]>> wrote:
>
> 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.
>
이메일 #072
Date: Mon, 09 Nov 2009 19:41:11 +0000
From: Satoshi Nakamoto <[email protected]>
Subject: Re: Linux build ready for testing
To: [email protected]
Cc: Liberty Standard <[email protected]>
영어 원문
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.
[email protected] 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.
>
이메일 #073
Date: Tue, 10 Nov 2009 16:46:04 +0000
From: Satoshi Nakamoto <[email protected]>
Subject: Re: Linux - dead sockets problem
To: Liberty Standard <[email protected]>
Cc: Martti Malmi <[email protected]>
영어 원문
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.
>
>
> On Tue, Nov 10, 2009 at 1:45 AM, Liberty Standard
> <[email protected] <mailto:[email protected]>> wrote:
>
> The Linux build has generated a decent amount of bitcoins within the
> past 20 hours and I trust what you're telling me about database
> errors, so all signs point toward me running the Linux build from
> now on. The only half annoying thing about the Linux build is that
> my computer's fan has gone from 50% to 100%. :-P I know I can limit
> the CPU, so if it gets on my nerves too much and if I can live with
> less bitcoins being generated, perhaps I'll do that. Or maybe I just
> need to start listening to more music...
>
...
>
> 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.
>
>
>
이메일 #074
Date: Wed, 11 Nov 2009 00:39:19 +0000
From: Satoshi Nakamoto <[email protected]>
Subject: Re: Linux - linux-0.1.6-test2
To: Liberty Standard <[email protected]>
Cc: Martti Malmi <[email protected]>
영어 원문
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
Satoshi Nakamoto wrote:
> 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.
>>
>>
>> On Tue, Nov 10, 2009 at 1:45 AM, Liberty Standard
>> <[email protected] <mailto:[email protected]>>
>> wrote:
>>
>> The Linux build has generated a decent amount of bitcoins within the
>> past 20 hours and I trust what you're telling me about database
>> errors, so all signs point toward me running the Linux build from
>> now on. The only half annoying thing about the Linux build is that
>> my computer's fan has gone from 50% to 100%. :-P I know I can limit
>> the CPU, so if it gets on my nerves too much and if I can live with
>> less bitcoins being generated, perhaps I'll do that. Or maybe I just
>> need to start listening to more music...
>>
> ...
>>
>> 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.
>>
>>
>>
>
>
이메일 #075
Date: Wed, 11 Nov 2009 00:41:06 +0000
From: Satoshi Nakamoto <[email protected]>
Subject: Re: Linux - linux-0.1.6-test2 attachment
To: Liberty Standard <[email protected]>
Cc: Martti Malmi <[email protected]>
영어 원문
linux-0.1.6-test2.tar.bz2 attached