Rather than re-enable OP_LEFT, a NOP could be re= -purposed in a soft fork.

OP_DUP OP_HASH160 [pubKeyHash[:LEN_PARAM]]= [LEN_PARAM] OP_LEFTEQUALVERIFY OP_DROP OP_CHECKSIG

A B L OP_L= EFTEQUALVERIFY checks if the leftmost L bytes of A and B match.=C2=A0 If no= t, then the script immediately fails.=C2=A0 If either array is less than L = bytes or if there are fewer than 3 values on the stack, then it also fails.=

The OP_DROP is needed as the new opcode must count as a = NOP for legacy nodes.

A change like this would= only cause a once-off improvement in efficiency, so it is less likely to b= e worth the effort.

It also requires most clients to be u= pdated to support the new address system.

A different BIP= could be added for that.

An alternative way t= o add new opcodes is to use a different script engine like with P2SH.

On = Wed, Jul 22, 2015 at 9:15 PM, Jeremy Rubin via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org> wrote:

While we're all debating= the block size, please review this proposal to modestly increase the numbe= r of transactions per block.

https://g= ist.github.com/JeremyRubin/4d17d28d5c681a93fa63

Best,

Jeremy

_______________________________________________
bitcoin-dev mailing list
bitcoin-dev@lists.= linuxfoundation.org
https://lists.linuxfoundation.org/mail= man/listinfo/bitcoin-dev

--001a11c154e872c07f051b7cb245-- From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id AA81E48B for ; Wed, 22 Jul 2015 21:06:04 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-lb0-f181.google.com (mail-lb0-f181.google.com [209.85.217.181]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 13E8FE8 for ; Wed, 22 Jul 2015 21:06:04 +0000 (UTC) Received: by lblf12 with SMTP id f12so144721772lbl.2 for ; Wed, 22 Jul 2015 14:06:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=txGr+LzOLurtM1xhe8uCdiHz9mgcmnlpZgeNDtuRiJo=; b=XcM+y19ix69ObGz2iNCcl4wd05D9IQ82SGnD34+cG7LBlCjZtQzv2rqlNroVa88kzU zZc1q96NI6k5oJ4QJaFprIiDDLxUc/HsiuNlLetr1Xt0B1ss4friVO3RMzrSijtEfMya yU+fzPe5FjpBIKNlxclE7sn2eeMwXPq5xQ5iKHiBgwvCRdej1uUEUjDSkPbzipUy5U76 PhESA8/SClJJORD57ZN55XvArvRz+f8CpszOhr4gzhvheQBRqfcPIK/37XCuzm4U5taH bvYINynAdUDW7V0d2ECohqlnMfAQ9nl8aXgsjebHYuSOoJsprskx92C5u7D4DCL93jNa Cg+g== MIME-Version: 1.0 X-Received: by 10.112.8.108 with SMTP id q12mr4173556lba.113.1437599162133; Wed, 22 Jul 2015 14:06:02 -0700 (PDT) Received: by 10.25.90.75 with HTTP; Wed, 22 Jul 2015 14:06:02 -0700 (PDT) In-Reply-To: References:

Date: Wed, 22 Jul 2015 17:06:02 -0400 Message-ID: From: Gavin Andresen To: Tier Nolan Content-Type: multipart/alternative; boundary=001a1135e3d663740d051b7d2389 X-Spam-Status: No, score=-2.7 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FROM,HTML_MESSAGE,RCVD_IN_DNSWL_LOW autolearn=ham version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on smtp1.linux-foundation.org Cc: bitcoin-dev@lists.linuxfoundation.org Subject: Re: [bitcoin-dev] BIP: Short Term Use Addresses for Scalability X-BeenThere: bitcoin-dev@lists.linuxfoundation.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Bitcoin Development Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jul 2015 21:06:04 -0000 --001a1135e3d663740d051b7d2389 Content-Type: text/plain; charset=UTF-8 On Wed, Jul 22, 2015 at 4:34 PM, Tier Nolan via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > It also requires most clients to be updated to support the new address > system. That's the killer: introducing Yet Another Type of Bitcoin Address takes a very long time and requires a lot of people to change their code. At least, that was the lesson learned when we introduced P2SH addresses. I think it's just not worth it for a very modest space savings (10 bytes, when scriptSig+scriptPubKey is about 120 bytes), especially with the extreme decrease in security (going from 2^160 to 2^80 to brute-force). -- -- Gavin Andresen --001a1135e3d663740d051b7d2389 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

On W= ed, Jul 22, 2015 at 4:34 PM, Tier Nolan via bitcoin-dev &= lt;bitcoin-dev@lists.linuxfoundation.org> wrote:
It also requires most clients to be updated to suppor= t the new address system.

That's the killer: intr= oducing Yet Another Type of Bitcoin Address takes a very long time and requ= ires a lot of people to change their code. At least, that was the lesson le= arned when we introduced P2SH addresses.

I think it's just not worth it for a= very modest space savings (10 bytes, when scriptSig+scriptPubKey is about = 120 bytes), especially with the extreme decrease in security (going from 2^= 160 to 2^80 to brute-force).

--
Gavin Andresen

--001a1135e3d663740d051b7d2389-- From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id 2055140A for ; Thu, 23 Jul 2015 04:05:44 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-wi0-f181.google.com (mail-wi0-f181.google.com [209.85.212.181]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 43C2AFD for ; Thu, 23 Jul 2015 04:05:43 +0000 (UTC) Received: by wibxm9 with SMTP id xm9so189840275wib.0 for ; Wed, 22 Jul 2015 21:05:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=pDcmQ3VsnzP5pw7FmgWuT3Hvy3F7Oly+dl4YEK9XVe8=; b=agva8iSLyu0ZYdpLDwL5RxfoDN3NNSoHgC4iSKAB1pjGDqnkj9rC2T7Au1bz17bTiK EIqKSWQ09yp3bCTKD8EwZV9yMeX8qtSS03MrSsn25eIngjSwYGVFpivpMV8xP7Mo8/wh SlBoNG+r27ulRDGM+NehQ2J7NZg/ss3aheCPhb8LikUJRzuYURAGXIVl7nuHf7OnsJek 2Qfp7vCfV1a50nmcwEjsKEEo0gqriSmmGPOz2aHwSp0iq2qDQVkZhAwzuU/tJrzkSblR 5I1C9o26uU9GJevCOpyGteCgxC2RWfejiITBSNytKF/f/kZKru2+xlc8t9S7X1DsXk72 /YCQ== X-Received: by 10.194.82.167 with SMTP id j7mr11238126wjy.123.1437624341854; Wed, 22 Jul 2015 21:05:41 -0700 (PDT) MIME-Version: 1.0 Received: by 10.28.229.195 with HTTP; Wed, 22 Jul 2015 21:05:22 -0700 (PDT) In-Reply-To: References:

From: Jeremy Rubin Date: Thu, 23 Jul 2015 12:05:22 +0800 Message-ID: To: Gavin Andresen Content-Type: multipart/alternative; boundary=047d7bb04d2c377ff0051b8300e7 X-Spam-Status: No, score=-2.7 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FROM,HTML_MESSAGE,RCVD_IN_DNSWL_LOW autolearn=ham version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on smtp1.linux-foundation.org Cc: bitcoin-dev@lists.linuxfoundation.org Subject: Re: [bitcoin-dev] BIP: Short Term Use Addresses for Scalability X-BeenThere: bitcoin-dev@lists.linuxfoundation.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Bitcoin Development Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Jul 2015 04:05:44 -0000 --047d7bb04d2c377ff0051b8300e7 Content-Type: text/plain; charset=UTF-8 I think the catch here is that under STUA (short term use address) there is a strict incentive, you can reduce the transaction fee for these txns. This also fits with the general model that you pay the miners for security. My belief is that when there is a savings benefit to be had large players will prefer it at a minimum, and users will desire it. Your analysis of saving is inaccurate, it comes to be at or greater than 20 bytes because there is typically 2 UTXOs or more. I get that this is still marginal, but when the margins are tight this is a pretty decent gain. The security decrease is actually less extreme than it seems. This is for multiple reasons: 1) you can select LEN_PARAM when you make the tx to be secure at that time Adding a byte or two gets much more security while still keeping it lean. 2) For a small transaction, the hash power is less rewarding than just working on the blockchain or doing something else 3) These addresses are only for use for short term, not perm storage. As such, if you model the threat it isn't great (I'm using this address for one day, someone grinds it in that time). 4) Because it is a UTXO saving, it reduces memory bloat.t It would be interesting to get a more exact analysis on the time needed to run a brute force as it involves computing a valid keypair and hashing for each attempt. On Thu, Jul 23, 2015 at 5:06 AM, Gavin Andresen via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > On Wed, Jul 22, 2015 at 4:34 PM, Tier Nolan via bitcoin-dev < > bitcoin-dev@lists.linuxfoundation.org> wrote: > >> It also requires most clients to be updated to support the new address >> system. > > > That's the killer: introducing Yet Another Type of Bitcoin Address takes a > very long time and requires a lot of people to change their code. At least, > that was the lesson learned when we introduced P2SH addresses. > > I think it's just not worth it for a very modest space savings (10 bytes, > when scriptSig+scriptPubKey is about 120 bytes), especially with the > extreme decrease in security (going from 2^160 to 2^80 to brute-force). > > -- > -- > Gavin Andresen > > > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > > --047d7bb04d2c377ff0051b8300e7 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

I think the catch here is that under STUA (short term use = address) there is a strict incentive, you can reduce the transaction fee fo= r these txns. This also fits with the general model that you pay the miners= for security. My belief is that when there is a savings benefit to be had = large players will prefer it at a minimum, and users will desire it.

Your analysis of saving is inaccurate, it comes= to be at or greater than 20 bytes because there is typically 2 UTXOs or mo= re. I get that this is still marginal, but when the margins are tight this = is a pretty decent gain.

The securi= ty decrease is actually less extreme than it seems. This is for multiple re= asons:

1) you can select LEN_PARAM when you make the tx to be sec= ure at that time Adding a byte or two gets much more security while still k= eeping it lean.

2) For a small transaction, the hash power is les= s rewarding than just working on the blockchain or doing something else

3) These addresses are only for use for short term, not perm storage= . As such, if you model the threat it isn't great (I'm using this a= ddress for one day, someone grinds it in that time).

4) Because i= t is a UTXO saving, it reduces memory bloat.t

It w= ould be interesting to get a more exact analysis on the time needed to run = a brute force as it involves computing a valid keypair and hashing for each= attempt.

On Thu, Jul 23, 2015 at 5:06 AM, Gavin An= dresen via bitcoin-dev <bitcoin-dev@lists.linuxfoundat= ion.org> wrote:

On Wed, Jul 22, 2015 at 4:34 PM, Tier Nolan via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org> wrote:
It also requires most clients to be updated to = support the new address system.

That's the= killer: introducing Yet Another Type of Bitcoin Address takes a very long = time and requires a lot of people to change their code. At least, that was = the lesson learned when we introduced P2SH addresses.

I think it's just not w= orth it for a very modest space savings (10 bytes, when scriptSig+scriptPub= Key is about 120 bytes), especially with the extreme decrease in security (= going from 2^160 to 2^80 to brute-force).

--
Gavin Andre= sen

_______________________________________________
bitcoin-dev mailing list
bitcoin-dev@lists.= linuxfoundation.org
https://lists.linuxfoundation.org/mail= man/listinfo/bitcoin-dev

--047d7bb04d2c377ff0051b8300e7-- From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id 699424A2 for ; Thu, 23 Jul 2015 04:55:48 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 Received: from s47.web-hosting.com (s47.web-hosting.com [199.188.200.16]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 0AA34E9 for ; Thu, 23 Jul 2015 04:55:48 +0000 (UTC) Received: from localhost ([::1]:36105 helo=server47.web-hosting.com) by server47.web-hosting.com with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.82) (envelope-from ) id 1ZI8Xq-0026lL-Q0 for bitcoin-dev@lists.linuxfoundation.org; Thu, 23 Jul 2015 00:55:46 -0400 Received: from 119.246.245.241 ([119.246.245.241]) by server47.web-hosting.com (Horde Framework) with HTTP; Thu, 23 Jul 2015 04:55:46 +0000 Date: Thu, 23 Jul 2015 04:55:46 +0000 Message-ID: <20150723045546.Horde.KiM4VIQqwnFJ3lwdFrO-2w3@server47.web-hosting.com> From: jl2012@xbt.hk To: bitcoin-dev@lists.linuxfoundation.org References:

In-Reply-To: User-Agent: Internet Messaging Program (IMP) H5 (6.1.4) Content-Type: text/plain; charset=UTF-8; format=flowed; DelSp=Yes MIME-Version: 1.0 Content-Disposition: inline X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - server47.web-hosting.com X-AntiAbuse: Original Domain - lists.linuxfoundation.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - xbt.hk X-Get-Message-Sender-Via: server47.web-hosting.com: authenticated_id: jl2012@xbt.hk X-Source: X-Source-Args: X-Source-Dir: X-From-Rewrite: unmodified, already matched X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_LOW autolearn=ham version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on smtp1.linux-foundation.org Subject: Re: [bitcoin-dev] BIP: Short Term Use Addresses for Scalability X-BeenThere: bitcoin-dev@lists.linuxfoundation.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Bitcoin Development Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Jul 2015 04:55:48 -0000 Quoting Gavin Andresen via bitcoin-dev : > On Wed, Jul 22, 2015 at 4:34 PM, Tier Nolan via bitcoin-dev < > bitcoin-dev@lists.linuxfoundation.org> wrote: > >> It also requires most clients to be updated to support the new address >> system. > > > That's the killer: introducing Yet Another Type of Bitcoin Address takes a > very long time and requires a lot of people to change their code. At least, > that was the lesson learned when we introduced P2SH addresses. > > I think it's just not worth it for a very modest space savings (10 bytes, > when scriptSig+scriptPubKey is about 120 bytes), especially with the > extreme decrease in security (going from 2^160 to 2^80 to brute-force). > > -- > -- > Gavin Andresen I think it would only save ~5% with all overhead (value, sequence, locktime, version, etc.) counted A better way is to introduce shorter ECDSA keys, which will save a lot of space for public key and signature. It is safe as long as the output value is much lower than the cost of attack. If this happens, I think it will be part of the OP_MAST which will require a new address type anyway. From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id 58DE947E for ; Thu, 23 Jul 2015 06:05:34 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-wi0-f173.google.com (mail-wi0-f173.google.com [209.85.212.173]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 029B4DE for ; Thu, 23 Jul 2015 06:05:32 +0000 (UTC) Received: by wibxm9 with SMTP id xm9so192468148wib.0 for ; Wed, 22 Jul 2015 23:05:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=aaJ8X80XLZHMBR3MK0HSFh03gB9uQqQyqZLtKcWVIG4=; b=IS3K2Dv5nsZn+G5VmUUA3TmEufNZjUB7OgKIizwWsB4LlGprsYV/cmd0xbjc3ErVB/ Dr//UPpBQC0gdxhXl3IJjtEVnYzwQ/QiszcL39a6t6+o+PAhzUMzBWzK0vRk/Oxn9ehs ExgpEG0MIEykj/iFi4TThzeF5QygGzzzOTN+cR7vKO6wqM9H4Awf2hpdbAIscXmco8Pl g70w2savkFmh5rGSoZYOHGI7z62BfXgSFJu5clwGM2pTEWvpF1M3RT/mE1+UuQyB7mpb 0HPZEKVa+4ksuTnY+64wlfcCxfFwA8TG717Y35JI1X3KY3zRRhfSOGEaRNvAEQoXtpIt 2gLQ== X-Received: by 10.180.36.129 with SMTP id q1mr13870228wij.10.1437631531503; Wed, 22 Jul 2015 23:05:31 -0700 (PDT) MIME-Version: 1.0 Received: by 10.28.229.195 with HTTP; Wed, 22 Jul 2015 23:05:12 -0700 (PDT) In-Reply-To: <20150723045546.Horde.KiM4VIQqwnFJ3lwdFrO-2w3@server47.web-hosting.com> References:

<20150723045546.Horde.KiM4VIQqwnFJ3lwdFrO-2w3@server47.web-hosting.com> From: Jeremy Rubin Date: Thu, 23 Jul 2015 14:05:12 +0800 Message-ID: To: jl2012@xbt.hk Content-Type: multipart/alternative; boundary=e89a8f502ec2c0d63b051b84ac99 X-Spam-Status: No, score=-2.7 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FROM,HTML_MESSAGE,RCVD_IN_DNSWL_LOW autolearn=ham version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on smtp1.linux-foundation.org Cc: bitcoin-dev@lists.linuxfoundation.org Subject: Re: [bitcoin-dev] BIP: Short Term Use Addresses for Scalability X-BeenThere: bitcoin-dev@lists.linuxfoundation.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Bitcoin Development Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Jul 2015 06:05:34 -0000 --e89a8f502ec2c0d63b051b84ac99 Content-Type: text/plain; charset=UTF-8 A standard transaction is 225 bytes, leading to a savings of 8.6%. However, that is essentially the minimum saving. For other sizes (eg, 10 outputs) which seem to be pretty frequent savings can be greater. Furthermore, it is important to note that this is a memory saving for the UTXO pool so the reduction there is more (not super familiar with how the UTXO pool is stored, but it should be a better savings than 8.6%). Does anyone have the tools currently to be able to easily run through the chain and analyze the impact of this change on historical data more directly? On Thu, Jul 23, 2015 at 12:55 PM, jl2012 via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > > Quoting Gavin Andresen via bitcoin-dev < > bitcoin-dev@lists.linuxfoundation.org>: > > On Wed, Jul 22, 2015 at 4:34 PM, Tier Nolan via bitcoin-dev < >> bitcoin-dev@lists.linuxfoundation.org> wrote: >> >> It also requires most clients to be updated to support the new address >>> system. >>> >> >> >> That's the killer: introducing Yet Another Type of Bitcoin Address takes a >> very long time and requires a lot of people to change their code. At >> least, >> that was the lesson learned when we introduced P2SH addresses. >> >> I think it's just not worth it for a very modest space savings (10 bytes, >> when scriptSig+scriptPubKey is about 120 bytes), especially with the >> extreme decrease in security (going from 2^160 to 2^80 to brute-force). >> >> -- >> -- >> Gavin Andresen >> > > I think it would only save ~5% with all overhead (value, sequence, > locktime, version, etc.) counted > > A better way is to introduce shorter ECDSA keys, which will save a lot of > space for public key and signature. It is safe as long as the output value > is much lower than the cost of attack. > > If this happens, I think it will be part of the OP_MAST which will require > a new address type anyway. > > > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > --e89a8f502ec2c0d63b051b84ac99 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

A standard transaction is 225 bytes, leading to a savings = of 8.6%.

However, that is essentially the minimum saving= . For other sizes (eg, 10 outputs) which seem to be pretty frequent savings= can be greater.

Furthermore, it is important to n= ote that this is a memory saving for the UTXO pool so the reduction there i= s more (not super familiar with how the UTXO pool is stored, but it should = be a better savings than 8.6%).=C2=A0

Does anyone have the tools currently to be able to easily run throug= h the chain and analyze the impact of this change on historical data more d= irectly?

On Thu, Jul 23, 2015 at 12:55 PM, jl2012 via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org> wrote:

Quoting Gavin Andresen via bitcoin-dev <bitcoin-dev@lists.linuxfoundatio= n.org>:

On Wed, Jul 22, 2015 at 4:34 PM, Tier Nolan via bitcoin-dev <
= bitcoin-dev@lists.linuxfoundation.org> wrote:

It also requires most clients to be updated to support the new address
system.

That's the killer: introducing Yet Another Type of Bitcoin Address take= s a
very long time and requires a lot of people to change their code. At least,=
that was the lesson learned when we introduced P2SH addresses.

I think it's just not worth it for a very modest space savings (10 byte= s,
when scriptSig+scriptPubKey is about 120 bytes), especially with the
extreme decrease in security (going from 2^160 to 2^80 to brute-force).

--
--
Gavin Andresen

I think it would only save ~5% with all overhead (value, sequence, locktime= , version, etc.) counted

A better way is to introduce shorter ECDSA keys, which will save a lot of s= pace for public key and signature. It is safe as long as the output value i= s much lower than the cost of attack.

If this happens, I think it will be part of the OP_MAST which will require = a new address type anyway.

_______________________________________________
bitcoin-dev mailing list
= bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mail= man/listinfo/bitcoin-dev

--e89a8f502ec2c0d63b051b84ac99--