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 ------------------------------------------------------------------------------ EMC VNX: the world's simplest storage, starting under $10K The only unified storage solution that offers unified management Up to 160% more powerful than alternatives and 25% more efficient. Guaranteed. http://p.sf.net/sfu/emc-vnx-dev2dev _______________________________________________ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
