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
|
Received: from sog-mx-3.v43.ch3.sourceforge.com ([172.29.43.193]
helo=mx.sourceforge.net)
by sfs-ml-2.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <sipa@ulyssis.org>) id 1QwGAQ-0001Su-93
for bitcoin-development@lists.sourceforge.net;
Wed, 24 Aug 2011 16:19:02 +0000
X-ACL-Warn:
Received: from rhcavuit02.kulnet.kuleuven.be ([134.58.240.130]
helo=cavuit02.kulnet.kuleuven.be)
by sog-mx-3.v43.ch3.sourceforge.com with esmtp (Exim 4.76)
id 1QwGAP-0000Bh-Ad for bitcoin-development@lists.sourceforge.net;
Wed, 24 Aug 2011 16:19:02 +0000
X-KULeuven-Envelope-From: sipa@ulyssis.org
X-Spam-Status: not spam, SpamAssassin (not cached, score=-48.797, required 5,
autolearn=disabled, DKIM_ADSP_CUSTOM_MED 0.00, FAKE_REPLY_C 0.00,
FREEMAIL_FROM 0.00, KUL_SMTPS -50.00, NML_ADSP_CUSTOM_MED 1.20)
X-KULeuven-Scanned: Found to be clean
X-KULeuven-ID: 4963D128081.A47F8
X-KULeuven-Information: Katholieke Universiteit Leuven
Received: from smtps01.kuleuven.be (smtpshost01.kulnet.kuleuven.be
[134.58.240.74])
by cavuit02.kulnet.kuleuven.be (Postfix) with ESMTP id 4963D128081
for <bitcoin-development@lists.sourceforge.net>;
Wed, 24 Aug 2011 18:18:54 +0200 (CEST)
Received: from smtp.ulyssis.org (mail.ulyssis.student.kuleuven.be
[193.190.253.235])
by smtps01.kuleuven.be (Postfix) with ESMTP id 083A731E702
for <bitcoin-development@lists.sourceforge.net>;
Wed, 24 Aug 2011 18:18:54 +0200 (CEST)
Received: from wop.ulyssis.org (wop.intern.ulyssis.org [192.168.0.182])
by smtp.ulyssis.org (Postfix) with ESMTP id 93266F8004
for <bitcoin-development@lists.sourceforge.net>;
Wed, 24 Aug 2011 18:22:28 +0200 (CEST)
Received: by wop.ulyssis.org (Postfix, from userid 615)
id 2DA3D87C1B0; Wed, 24 Aug 2011 18:18:54 +0200 (CEST)
Date: Wed, 24 Aug 2011 18:18:54 +0200
X-Kuleuven: This mail passed the K.U.Leuven mailcluster
From: Pieter Wuille <pieter.wuille@gmail.com>
To: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Message-ID: <20110824161853.GA29981@ulyssis.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.5.20 (2009-06-14)
X-Spam-Score: 1.2 (+)
X-Spam-Report: Spam Filtering performed by mx.sourceforge.net.
See http://spamassassin.org/tag/ for more details.
0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider
(pieter.wuille[at]gmail.com)
0.0 DKIM_ADSP_CUSTOM_MED No valid author signature, adsp_override is
CUSTOM_MED 0.0 FAKE_REPLY_C FAKE_REPLY_C
1.2 NML_ADSP_CUSTOM_MED ADSP custom_med hit,
and not from a mailing list
0.0 AWL AWL: From: address is in the auto white-list
X-Headers-End: 1QwGAP-0000Bh-Ad
Subject: Re: [Bitcoin-development] New standard transaction types: time to
schedule a blockchain split?
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, 24 Aug 2011 16:19:02 -0000
On Wed, Aug 24, 2011 at 11:12:10AM -0400, Gavin Andresen wrote:
> So, if we are going to have new releases that are incompatible with
> old clients why not do things right in the first place, implement or
> enable opcodes so the new bitcoin addresses can be small, and schedule
> a block chain split for N months from now.
What was the reason for disabling these opcodes in the first place? I can
understand wanting to prevent excessive signature-verification, or limitation
of arithmetic to a limited amount of bits, but completely disabling all
arithmetic beyond addition and subtraction, and all bitwise operations seems
very limiting to me. Thus, if we agree to do a future incompatible update,
i would vote to re-enable these, and maybe allow arithmetic up to 520 or
1024 bits numbers.
While we're at it, some additional opcodes could be useful. Either a custom
operator to do boolean evaluation, or a few more lowlevel operations. Given
the presence of bitwise operators, you could have scripts that process a
sequence of pubkey/signature pairs, build up a number in which each bit
corresponds to a valid signature, and then do some bitwise checks on this
number. I'd argue that a "count number of bits set in number" opcode would
be very useful for this.
In short: I'm in favor of re-enabling opcodes, and possibly adding an
OP_BITCOUNT operation.
--
Pieter
|
