summaryrefslogtreecommitdiff
path: root/64/175d67163fc0e7fd29e009da3770cd6b7cd223
blob: b53cb7e7488586aad425c3fcda4c9432c5c0b46d (plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
Received: from sog-mx-4.v43.ch3.sourceforge.com ([172.29.43.194]
	helo=mx.sourceforge.net)
	by sfs-ml-2.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
	(envelope-from <grarpamp@gmail.com>) id 1Si1cJ-0008T4-CP
	for bitcoin-development@lists.sourceforge.net;
	Fri, 22 Jun 2012 11:01:31 +0000
Received-SPF: pass (sog-mx-4.v43.ch3.sourceforge.com: domain of gmail.com
	designates 209.85.212.181 as permitted sender)
	client-ip=209.85.212.181; envelope-from=grarpamp@gmail.com;
	helo=mail-wi0-f181.google.com; 
Received: from mail-wi0-f181.google.com ([209.85.212.181])
	by sog-mx-4.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
	(Exim 4.76) id 1Si1cD-0006Qr-Vk
	for bitcoin-development@lists.sourceforge.net;
	Fri, 22 Jun 2012 11:01:31 +0000
Received: by wibhn14 with SMTP id hn14so410156wib.10
	for <bitcoin-development@lists.sourceforge.net>;
	Fri, 22 Jun 2012 04:01:19 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.216.143.195 with SMTP id l45mr1004804wej.49.1340362879786;
	Fri, 22 Jun 2012 04:01:19 -0700 (PDT)
Received: by 10.180.7.105 with HTTP; Fri, 22 Jun 2012 04:01:19 -0700 (PDT)
Date: Fri, 22 Jun 2012 07:01:19 -0400
Message-ID: <CAD2Ti2_JL0HoNwkJJhzJ2CehPA0Ai0X7+CgF_n9-+H=vCU1F9A@mail.gmail.com>
From: grarpamp <grarpamp@gmail.com>
To: bitcoin-development@lists.sourceforge.net
Content-Type: text/plain; charset=UTF-8
X-Spam-Score: -1.0 (-)
X-Spam-Report: Spam Filtering performed by mx.sourceforge.net.
	See http://spamassassin.org/tag/ for more details.
	-1.5 SPF_CHECK_PASS SPF reports sender host as permitted sender for
	sender-domain
	0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider
	(grarpamp[at]gmail.com)
	-0.0 SPF_PASS               SPF: sender matches SPF record
	-0.1 DKIM_VALID_AU Message has a valid DKIM or DK signature from
	author's domain
	0.1 DKIM_SIGNED            Message has a DKIM or DK signature,
	not necessarily valid
	-0.1 DKIM_VALID Message has at least one valid DKIM or DK signature
	0.6 AWL AWL: From: address is in the auto white-list
X-Headers-End: 1Si1cD-0006Qr-Vk
Subject: [Bitcoin-development] Wallet related bug?
X-BeenThere: bitcoin-development@lists.sourceforge.net
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: <bitcoin-development.lists.sourceforge.net>
List-Unsubscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
	<mailto:bitcoin-development-request@lists.sourceforge.net?subject=unsubscribe>
List-Archive: <http://sourceforge.net/mailarchive/forum.php?forum_name=bitcoin-development>
List-Post: <mailto:bitcoin-development@lists.sourceforge.net>
List-Help: <mailto:bitcoin-development-request@lists.sourceforge.net?subject=help>
List-Subscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
	<mailto:bitcoin-development-request@lists.sourceforge.net?subject=subscribe>
X-List-Received-Date: Fri, 22 Jun 2012 11:01:31 -0000

I think there may be an ideal order of ops bug around rescan,
wallet upgrades/import and last block markers.

I dropped an old wallet in a current blockchain.

First ran - in rescan mode.
It said old walletver.
Then rescanned whole chain.
AddToWallet some blockhash, blocks out of range, invalid/nonwallet txid's,
which were already in there as legit ones in the old logs.

Second run in plain mode.
New wallet ver logged.
Rescanned  the last 20k blocks or so,
which might have been the marker last time the old wallet was used.

Third and later runs... duplicates the second.

Never did say 'upgrading wallet' as it sometimes does.

Running detach=1 always.

Why scan the last 20k every time? Shouldn't have to if
whole chain was scanned. And certainly no more than
once if not.

Also...
Dumping the run params (bitcoin.conf, cmdline) to the log would be good.

And not automatically truncate the log when big but just append or roll it.