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
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
|
Received: from sog-mx-4.v43.ch3.sourceforge.com ([172.29.43.194]
helo=mx.sourceforge.net)
by sfs-ml-4.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <jtimon@monetize.io>) id 1WalNk-0001Zt-JZ
for bitcoin-development@lists.sourceforge.net;
Thu, 17 Apr 2014 12:25:32 +0000
Received: from mail-la0-f52.google.com ([209.85.215.52])
by sog-mx-4.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1WalNj-0007Gd-7C
for bitcoin-development@lists.sourceforge.net;
Thu, 17 Apr 2014 12:25:32 +0000
Received: by mail-la0-f52.google.com with SMTP id ec20so315425lab.11
for <bitcoin-development@lists.sourceforge.net>;
Thu, 17 Apr 2014 05:25:24 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20130820;
h=x-gm-message-state:mime-version:date:message-id:subject:from:to
:content-type:content-transfer-encoding;
bh=I7fyDT/PPAr5gn33PZt1WOOwKkPHcK+yzSAH5neUsGY=;
b=gXVK2Cp+MsxAgynhSfGlegtu8bM0lp1j0ulprxnvwe8dD5FeFRU/I4elge05qF5Hos
Rgp8ZOJQM/Q+QpYxA3xVAL2W9qZOcvtA54hbIvMLQfkFp3kSiWzc4dZBu5C09uDc8+b6
ByXyABQzXhu9cFMhOHWr3I+fUqR1uFNuu644y7v75hN/gyipS2gPWfRg7Fe0Zni2HAbZ
SDmJ3Nvxqup4FHt6Vy/c9fcMpOZMsJeH2UD6kaM2Qi4KwdHgw/BOsF6Sqi/AyYNJiNDT
fUOKBlYKPPhhMELo2MbdwB/qF4392qshsca1yxnh2kbfEDaQR6+wfKcEwMQPuQOg2OaP
BHJQ==
X-Gm-Message-State: ALoCoQlTtAwQ5jFWyzcpSll6maj6U5iFV7z6igAf5Lc0a36EgjGMAkkcNDkYGR8Haexh1y5tIkcr
MIME-Version: 1.0
X-Received: by 10.152.116.84 with SMTP id ju20mr84431lab.62.1397737524193;
Thu, 17 Apr 2014 05:25:24 -0700 (PDT)
Received: by 10.112.60.196 with HTTP; Thu, 17 Apr 2014 05:25:24 -0700 (PDT)
X-Originating-IP: [85.53.138.195]
Date: Thu, 17 Apr 2014 14:25:24 +0200
Message-ID: <CAC1+kJMrpx0tyE8d0wkwjBthhSPMCdr=9LrJHQFTF4G1vg4MAg@mail.gmail.com>
From: =?ISO-8859-1?Q?Jorge_Tim=F3n?= <jtimon@monetize.io>
To: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
X-Spam-Score: 0.0 (/)
X-Spam-Report: Spam Filtering performed by mx.sourceforge.net.
See http://spamassassin.org/tag/ for more details.
X-Headers-End: 1WalNj-0007Gd-7C
Subject: [Bitcoin-development] Timed testing
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: Thu, 17 Apr 2014 12:25:32 -0000
I'm implementing a new testing mode that produces blocks
periodically. You can get what I have so far here:
https://github.com/jtimon/bitcoin/tree/timed
It depends on pull request #3824 with some improvements on
CChainParams, but after that the changes required to add this new
mode are very small:
https://github.com/jtimon/bitcoin/commit/445321928a143cb9a6f56777cbb7479dd3=
2c3bcd
I guess I need a new genesis block, different magic numbers, etc. So
this is definitely not ready.
You can run it like this:
bitcoind -timedtest -gen=3D1 blocktime=3D2000
blocktime defaults to 1000 milliseconds for timedtest mode and 0 for
the rest of the modes.
What could this testing mode be useful for?
Basically, simulations.
For example, you could run several nodes implementing different mining
policies. Let's say I want to mine 50% of the blocks with standard policy,
25% with policy A and 25% with policy B. I can run 1 one for each of
one with block times 2000, 1000 and 1000 respectively.
Maybe I want to detect performance bottlenecks by stressing this mode
with as many transaction as can be processed, maybe removing the
block size limits in the simulations.
But this still doesn't serve for hardfork or double-spend attacks
simulations without calculating any pow, which would be another
interesting feature for a new testing mode.
I would like to implement the new mode following as the concept of
private chains described in freimarkets:
http://freico.in/docs/freimarkets.pdf
https://github.com/jtimon/freimarkets/blob/master/doc/freimarkets_specs.org=
#private-ledgers
https://github.com/jtimon/freimarkets/blob/master/doc/freimarkets_specs.org=
#off-chain-transactions
I know this could be considered a "non-bitcoinish" application and
therefore be controversial as discussed in PR 3824, so I want to keep
the conversation focused on testing use cases useful to bitcoin itself
only: additional changes can be implemented elsewhere.
One way I think you could support chain races simulations by using a
private mode could be the following:
1) The private mode works like the timed mode in how often it
produces blocks.
2) In private mode you replace the pow-related fields with a
blockPubkeyScript and a lastBlockSigScript fields. In the genesis
block, lastBlockSigScript is empty and the initial
blockPubkeyScript can be an optional parameter like blocktime. You
can set any valid script, probably p2sh, maybe with multisig to
allow different nodes to sign.
3) In this context, longer chains mean "more work". Another way to
see it is that all blocks just contain work=3D=3D1 in them.
So let's say we want to simulate an attack using 50% standard and 50%
attacker blocks. You set up the private mode script to be a 1 of 2
multisig and make each node sign always with the same private key
(maybe an additional parameter).
You make the attacker reject any blocks from height X that he hasn't
signed himself to get the result you wanted: the standard node will
produce blocks on top of the longest chain while the attacker will
only hash on top of his own blocks.
So my question to the community is, how invasive is this to bitcoin's
source code?
In my opinion, done properly could actually result (apart from getting
the new features) in more readable code, not less, since you will
probably need to make sure proof of work functionality is properly
encapsulated during the implementation process (see PR 3839 for a first
step on that direction).
But, should I push a private mode to the core or just the timed one
and implement the private mode elsewhere?
Of course other comments on the parameters, defaults or any other
design or implementation details are also welcomed.
--=20
Jorge Tim=F3n
http://freico.in/
|
