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 104FEE67 for ; Thu, 11 Feb 2016 23:04:43 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-io0-f173.google.com (mail-io0-f173.google.com [209.85.223.173]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 51C5311C for ; Thu, 11 Feb 2016 23:04:42 +0000 (UTC) Received: by mail-io0-f173.google.com with SMTP id l127so73214977iof.3 for ; Thu, 11 Feb 2016 15:04:42 -0800 (PST) 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=oSHGqZCha/eZBv6/dIfvJX0WGkzPyZqXlMeefo3S+bk=; b=oK8XWqWjuJFe8rpudsZUKZWt4bHX1rc7ElajyAeDHuiTp+gjGnUqmABuB0bVRG+Jez 3WrL8bzO9Rj5g7hH/Ts6bUzc1p59neu/i/q2fzHvj9NqwLhgHhp29bd/1Qv63Pwd1h+2 fv8m9K+uIFjfcRF4pWyLs0COpo3zD8s+xK3N9OMWyTFbq0UDyHm+M2x+fQVmAhM7mmru lszFKpNYTopTbI4D+g/hNtpeCG68POpOkRZA4yPJ3ujLU4xRZeq10tNZ9EEZba1fcqDq 06bzdLHbe9xRjTDRLr/INZpQoQJphylwq+emrcBHfn78vUF3EvOxXgQSHvc4Wxg3mO8o kEIg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:cc:content-type; bh=oSHGqZCha/eZBv6/dIfvJX0WGkzPyZqXlMeefo3S+bk=; b=Eop4i8z6gfN2qvs8Ut/NIphjJk3Ddxn3MB1VTzUYqIToDNeGi5P6ljFOgqEJs1AnYa Xd+A+G3T7cYumnNjfWx5aZwmHZ70Y85yFsZH+GyMuKF7UbHdyeXB977/oImKOEOW/OYf zwnE6jRQDa/VyYvWY4MgCw7WN84aMdZZI74+duaqo5839ynvJo/HJU8O/Bg65m2JmLKr vc2WEjTyBE0X7J7S6vwecjUcdfYoToHMWgblJOd1j6/890lQFGvDHk7VU7JIj7ObEHDh bL3cs5NyLgk9UeMo0G0ettrhgTzHocuHn6v6y3jb9RG2sKFL8UbkTZtnfoPC6s2CUEVF scPg== X-Gm-Message-State: AG10YOResXWImRGM4uLo5vkqta9qUUzskB6ZXCoyCnWw6i2nwdPwUmf4jpAqHGxiqTCPQg/QSbrQZOXGEkeRMA== MIME-Version: 1.0 X-Received: by 10.107.28.80 with SMTP id c77mr53301333ioc.98.1455231877838; Thu, 11 Feb 2016 15:04:37 -0800 (PST) Received: by 10.79.77.65 with HTTP; Thu, 11 Feb 2016 15:04:37 -0800 (PST) In-Reply-To: References: Date: Thu, 11 Feb 2016 23:04:37 +0000 Message-ID: From: Tier Nolan Cc: Bitcoin Dev Content-Type: multipart/alternative; boundary=001a11409b18255940052b869354 X-Spam-Status: No, score=1.0 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, FREEMAIL_FROM, HTML_IMAGE_ONLY_20, HTML_MESSAGE, HTML_SHORT_LINK_IMG_3, MALFORMED_FREEMAIL, MISSING_HEADERS, RCVD_IN_DNSWL_LOW, T_REMOTE_IMAGE autolearn=no version=3.3.1 X-Spam-Level: * X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on smtp1.linux-foundation.org Subject: Re: [bitcoin-dev] BIP CPRKV: Check private key verify 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, 11 Feb 2016 23:04:43 -0000 --001a11409b18255940052b869354 Content-Type: text/plain; charset=UTF-8 On Thu, Feb 11, 2016 at 10:20 PM, Thomas Kerin wrote: > I wonder if this is possible as a soft fork without using segwit? Increasing the sigop count for a NOP would be a hard fork, but such a change would be fine with a new segwit version. It might require specific support in the altcoin, which might be troublesome.. It is a soft fork since it makes things that were previous allowed disallowed. If it decreased the sigop count, then you could create a block that had to many sigops due to the old rules. With this rule, it increases the count. If the sigop count is valid under the new rules, it is also valid under the old rules. There is no need for specific support on the altcoin. It allows the Bitcoin network act as trusted 3rd party so that you can do channels safely on the altcoin, even though the altcoin still suffers from malleability and doesn't have OP_CHECKLOCKTIMEVERIFY. With regards to seg-witness, Ideally, the opcode would work in both old and new scripts by re-purposing OP_NOP3. This email has been sent from a virus-free computer protected by Avast. www.avast.com <#DDB4FAA8-2DD7-40BB-A1B8-4E2AA1F9FDF2> --001a11409b18255940052b869354 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Thu, Feb 11, 2016 at 10:20 PM, Thomas Kerin <th= omas.kerin@gmail.com> wrote:

> I wonder if this is possible as a soft fork without using segwit?=20 Increasing the sigop count for a NOP would be a hard fork, but such a=20 change would be fine with a new segwit version. It might require=20 specific support in the altcoin, which might be troublesome..

It is a= soft fork since it makes things that were previous allowed disallowed.=C2= =A0 If it decreased the sigop count, then you could create a block that had= to many sigops due to the old rules.

With this rule, it increases th= e count.=C2=A0 If the sigop count is valid under the new rules, it is also = valid under the old rules.

There is no need for specific support = on the altcoin.=C2=A0 It allows the Bitcoin network act as trusted 3rd part= y so that you can do channels safely on the altcoin, even though the altcoi= n still suffers from malleability and doesn't have OP_CHECKLOCKTIMEVERI= FY.

With regards to seg-witness, Ideally, the opcode would work in bo= th old and new scripts by re-purposing OP_NOP3.

This email has been = sent from a virus-free computer protected by Avast.
www.avas= t.com
--001a11409b18255940052b869354--