From: "Luke-Jr" <luke@dashjr.org>
To: bitcoin-development@lists.sourceforge.net
Date: Sun, 29 Jan 2012 09:40:01 -0500
User-Agent: KMail/1.13.7 (Linux/3.1.5-gentoo; KDE/4.7.4; x86_64; ; )
References: <1327812740.41242.YahooMailNeo@web121002.mail.ne1.yahoo.com>
	<1327835984.12365.YahooMailNeo@web121002.mail.ne1.yahoo.com>
	<CABsx9T2A8f64mh2-uSKwrjj9aEo0Z=jHyETQ5J9cka9JwyJqJw@mail.gmail.com>
In-Reply-To: <CABsx9T2A8f64mh2-uSKwrjj9aEo0Z=jHyETQ5J9cka9JwyJqJw@mail.gmail.com>
MIME-Version: 1.0
Content-Type: Text/Plain;
  charset="iso-8859-15"
Content-Transfer-Encoding: 7bit
Message-Id: <201201290940.02464.luke@dashjr.org>
Subject: Re: [Bitcoin-development] Fw: Quote on BIP 16
Precedence: list

On Sunday, January 29, 2012 9:30:10 AM Gavin Andresen wrote:
> On Sun, Jan 29, 2012 at 6:19 AM, Amir Taaki <zgenjix@yahoo.com> wrote:
> > (oops sorry greg- replied to you by mistake)
> > 
> > That address he gives is 77 characters/bytes (same thing). What I'm
> > asking is how can it be so small.
> 
> That's an alternative design for multisig addresses that would put a byte
> giving the type of transaction and the 20-byte hashes of each of the public
> keys involved. They would not have been redeemed using CHECKMULTISIG, but
> would use DUP HASH160 CHECKSIG and the arithmetic or logical opcodes to
> create the "m of n" condition.
> 
> Nobody really liked that solution because it means a new 'type' of bitcoin
> address every time we want a new transaction type and long addresses.
> 
> Its only advantage is it didn't use CHECKMULTISIG, so there were no
> problems with maximum-sigops-per-block.

In other words, if the max-sigops-per-block were ever approaching a real 
problem, we could just start using these kind of transactions instead hidden 
behind the P2SH... so the one remotely-tangible benefit of BIP 16 over 17 has 
been solved, right? ;)