[Bitcoin-development] New standard transaction types: time to schedule a blockchain split?

[Pieter Wuille]

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