Date: Wed, 24 Aug 2011 18:18:54 +0200
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)
Subject: Re: [Bitcoin-development] New standard transaction types: time to
 schedule a blockchain split?
Precedence: list

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