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
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
|
Received: from sog-mx-2.v43.ch3.sourceforge.com ([172.29.43.192]
helo=mx.sourceforge.net)
by sfs-ml-4.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <travis.johanssen@gmail.com>) id 1WNorf-0006L9-DU
for bitcoin-development@lists.sourceforge.net;
Wed, 12 Mar 2014 19:30:55 +0000
Received-SPF: pass (sog-mx-2.v43.ch3.sourceforge.com: domain of gmail.com
designates 209.85.213.65 as permitted sender)
client-ip=209.85.213.65;
envelope-from=travis.johanssen@gmail.com;
helo=mail-yh0-f65.google.com;
Received: from mail-yh0-f65.google.com ([209.85.213.65])
by sog-mx-2.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1WNore-0005Qm-Nw
for bitcoin-development@lists.sourceforge.net;
Wed, 12 Mar 2014 19:30:55 +0000
Received: by mail-yh0-f65.google.com with SMTP id z6so3169362yhz.8
for <bitcoin-development@lists.sourceforge.net>;
Wed, 12 Mar 2014 12:30:49 -0700 (PDT)
MIME-Version: 1.0
X-Received: by 10.236.122.173 with SMTP id t33mr5036769yhh.117.1394652649266;
Wed, 12 Mar 2014 12:30:49 -0700 (PDT)
Received: by 10.170.79.9 with HTTP; Wed, 12 Mar 2014 12:30:49 -0700 (PDT)
Date: Wed, 12 Mar 2014 13:30:49 -0600
Message-ID: <CAOyr6f1b94DFsmP6XeZ0KRaJSf0KQboOO_X1Au_e3EgiaN68dw@mail.gmail.com>
From: Travis Johansen <travis.johanssen@gmail.com>
To: bitcoin-development@lists.sourceforge.net
Content-Type: text/plain; charset=ISO-8859-1
X-Spam-Score: -1.6 (-)
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
(travis.johanssen[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
X-Headers-End: 1WNore-0005Qm-Nw
Subject: [Bitcoin-development] zapwallettxes problem and wallet DB ordering
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: Wed, 12 Mar 2014 19:30:55 -0000
Most of the issue seems to be because of
CWalletDB::ReorderTransactions. After applying zapwallettxes, I
noticed that listtransactions was no longer listing new transactions.
After further investigation, new tx records were being given a low
nOrderPos number while old acentry records were high enough that they
were being ordered at the end of listtransactions all the time. My
theory is that after the malleability attacks, the wallet DB got
filled with dead transactions that were removed by zapwallettxes, then
somehow ReorderTransactions got invoked and reset nOrderPosNext. This
left the acentry records with high nOrderPos and the new transactions
being added near the beginning.
I believe this is due to two issues:
1. ReorderTransactions only collects the acentry records from "":
ListAccountCreditDebit("", acentries);
which should probably be:
ListAccountCreditDebit("*", acentries);
2. ReorderTransactions seems to try too hard to maintain previous
ordering and likely fails. Or at least it did after I applied the fix
above. Would it not be better to just reorder the records with:
for (TxItems::iterator it = txByTime.begin(); it != txByTime.end(); ++it)
{
CWalletTx *const pwtx = (*it).second.first;
CAccountingEntry *const pacentry = (*it).second.second;
int64_t& nOrderPos = (pwtx != 0) ? pwtx->nOrderPos :
pacentry->nOrderPos;
nOrderPos = ++nOrderPosNext;
if (pwtx)
{
if (!WriteTx(pwtx->GetHash(), *pwtx))
return DB_LOAD_FAIL;
}
else
if (!WriteAccountingEntry(pacentry->nEntryNo, *pacentry))
return DB_LOAD_FAIL;
}
if (!WriteOrderPosNext(nOrderPosNext))
return DB_LOAD_FAIL;
Perhaps I'm missing something here but this seems to be a better
solution given the simplicity of the ordering system.
Unsurprisingly, applying the two fixes (and hacking one entry to an
nOrderPos of -1 to trigger ReorderTransactions) corrects the ordering
in my wallet DB. Or at least I think it does. Does anyone know why
this might be a bad idea? I'm new to the code and would like to know
if I'm potentially breaking something else.
|
