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 9B9214A4 for ; Wed, 22 Jul 2015 20:34:28 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-qk0-f180.google.com (mail-qk0-f180.google.com [209.85.220.180]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 0AB8EE8 for ; Wed, 22 Jul 2015 20:34:28 +0000 (UTC) Received: by qkbm65 with SMTP id m65so106977809qkb.2 for ; Wed, 22 Jul 2015 13:34:27 -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:cc :content-type; bh=6pbEVmwbB7K0BGQTi6hNB2sMEt9HhiEB83NpGsGAfUs=; b=wpBqwIyjdx7wm9DSfWZRra7GVn23+NkNj68EB38/o3YdyWo7vy2W+Ngwv56xSiYN/6 lN/CnGWqQmRcCYfNThvezbpP70fRRhFyO+pxhmt2MK84dNNygoK/uUjSG8ZkbSheprbS rLwJRga5MKk5iaGW94Zxi+bgPvIGGgYlxbDSroKjmHBv7azjXFRgnN+rttLCajqcrsfs JHqzl5QLKjPP++1To0aIlnGcrqFB0m0XLkgemuGr1/bw6G+4IMiFYtcsYQzdA7SBFO84 871arhbEMQnBTJU/z8W/WAzHRzjaA2UYWXDm4cLAZ846bhCoqC8K2qvXYWyIDit8vHMD 2KKw== MIME-Version: 1.0 X-Received: by 10.140.84.163 with SMTP id l32mr6782862qgd.94.1437597267311; Wed, 22 Jul 2015 13:34:27 -0700 (PDT) Received: by 10.140.93.162 with HTTP; Wed, 22 Jul 2015 13:34:27 -0700 (PDT) In-Reply-To: References: Date: Wed, 22 Jul 2015 21:34:27 +0100 Message-ID: From: Tier Nolan Cc: bitcoin-dev@lists.linuxfoundation.org Content-Type: multipart/alternative; boundary=001a11c154e872c07f051b7cb245 X-Spam-Status: No, score=-1.7 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FROM,HTML_MESSAGE,MISSING_HEADERS, RCVD_IN_DNSWL_LOW autolearn=no 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: Wed, 22 Jul 2015 20:34:28 -0000 --001a11c154e872c07f051b7cb245 Content-Type: text/plain; charset=UTF-8 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_LEFTEQUALVERIFY checks if the leftmost L bytes of A and B match. If not, then the script immediately fails. 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 be worth the effort. It also requires most clients to be updated to support the new address system. A different BIP could be added for that. An alternative way to 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 number of transactions per block. > > https://gist.github.com/JeremyRubin/4d17d28d5c681a93fa63 > > Best, > > Jeremy > > > > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > > --001a11c154e872c07f051b7cb245 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
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.


Best,

Jeremy



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


--001a11c154e872c07f051b7cb245--