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
|
Received: from sog-mx-2.v43.ch3.sourceforge.com ([172.29.43.192]
helo=mx.sourceforge.net)
by sfs-ml-1.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <chris.double@gmail.com>) id 1Qzqe3-0007rT-UF
for bitcoin-development@lists.sourceforge.net;
Sat, 03 Sep 2011 13:52:27 +0000
Received-SPF: pass (sog-mx-2.v43.ch3.sourceforge.com: domain of gmail.com
designates 209.85.161.47 as permitted sender)
client-ip=209.85.161.47; envelope-from=chris.double@gmail.com;
helo=mail-fx0-f47.google.com;
Received: from mail-fx0-f47.google.com ([209.85.161.47])
by sog-mx-2.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1Qzqe1-0001Ly-UG
for bitcoin-development@lists.sourceforge.net;
Sat, 03 Sep 2011 13:52:27 +0000
Received: by fxg11 with SMTP id 11so3533405fxg.34
for <bitcoin-development@lists.sourceforge.net>;
Sat, 03 Sep 2011 06:52:19 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.223.88.23 with SMTP id y23mr1901440fal.95.1315057939638; Sat,
03 Sep 2011 06:52:19 -0700 (PDT)
Sender: chris.double@gmail.com
Received: by 10.223.107.10 with HTTP; Sat, 3 Sep 2011 06:52:19 -0700 (PDT)
Date: Sun, 4 Sep 2011 01:52:19 +1200
X-Google-Sender-Auth: oY7Gw8L99QNailIXZELz5-qv4a8
Message-ID: <CALn1vHHynfb-u8fSwsStA=e5vR6x-e3yA44Z9Mt9A+AgO1+ezQ@mail.gmail.com>
From: Chris Double <chris.double@double.co.nz>
To: bitcoin-development@lists.sourceforge.net
Content-Type: text/plain; charset=ISO-8859-1
X-Spam-Score: -1.5 (-)
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
(chris.double[at]gmail.com)
-0.0 SPF_PASS SPF: sender matches SPF record
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.0 T_TO_NO_BRKTS_FREEMAIL To: misformatted and free email service
-0.0 AWL AWL: From: address is in the auto white-list
X-Headers-End: 1Qzqe1-0001Ly-UG
Subject: [Bitcoin-development] Transaction limit size in
CWallet::CreateTransaction
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: Sat, 03 Sep 2011 13:52:28 -0000
In CWallet::CreateTransaction there is a call to 'GetSerializeSize' on
line 979 (https://github.com/bitcoin/bitcoin/blob/master/src/wallet.cpp#L979).
It looks like:
---------8<----------
unsigned int nBytes = ::GetSerializeSize(*(CTransaction*)&wtxNew, SER_NETWORK)
if (nBytes >= MAX_BLOCK_SIZE_GEN/5)
return false;
dPriority /= nBytes;
---------8<----------
'wtxNew' is a CWalletTxn. So this gets the serialized size of the
transaction, including all the extra data held in the wallet for that
transaction, and uses that size for computation of priority. Is that
correct? Should it be only the size of the CTransaction* part of the
transaction that should be used?
It looks this was from the casting shenanigans but unless I'm
mistaken, that casting doesn't actually do anything. We get a pointer
to a CTransaction but then dereference it, so the template function
'GetSerializeSize' would get the most derived class, right?
So was the intent to use the CWalletTxn size, and the casting is
superfluous, or was it supposed to be the CTransaction* portion and
the cast is an incorrect way of doing that? Or am I suffering from
late night programmer syndrome and reading it wrong?
Chris.
--
http://www.bluishcoder.co.nz
|
