Received: from sog-mx-4.v43.ch3.sourceforge.com ([172.29.43.194] helo=mx.sourceforge.net) by sfs-ml-4.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1YicFf-00029d-Oy for bitcoin-development@lists.sourceforge.net; Thu, 16 Apr 2015 05:22:11 +0000 Received-SPF: pass (sog-mx-4.v43.ch3.sourceforge.com: domain of gmail.com designates 209.85.217.179 as permitted sender) client-ip=209.85.217.179; envelope-from=pieter.wuille@gmail.com; helo=mail-lb0-f179.google.com; Received: from mail-lb0-f179.google.com ([209.85.217.179]) by sog-mx-4.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.76) id 1YicFb-00066N-1k for bitcoin-development@lists.sourceforge.net; Thu, 16 Apr 2015 05:22:11 +0000 Received: by lbcga7 with SMTP id ga7so50193549lbc.1 for ; Wed, 15 Apr 2015 22:22:00 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.112.35.230 with SMTP id l6mr3501648lbj.5.1429161720676; Wed, 15 Apr 2015 22:22:00 -0700 (PDT) Received: by 10.112.19.7 with HTTP; Wed, 15 Apr 2015 22:22:00 -0700 (PDT) Received: by 10.112.19.7 with HTTP; Wed, 15 Apr 2015 22:22:00 -0700 (PDT) In-Reply-To: <552EF785.7000207@sky-ip.org> References: <552EF785.7000207@sky-ip.org> Date: Wed, 15 Apr 2015 22:22:00 -0700 Message-ID: From: Pieter Wuille To: s7r@sky-ip.org Content-Type: multipart/alternative; boundary=001a11c37876b0081c0513d0a460 X-Spam-Score: -0.6 (/) X-Spam-Report: Spam Filtering performed by mx.sourceforge.net. See http://spamassassin.org/tag/ for more details. -1.5 SPF_CHECK_PASS SPF reports sender host as permitted sender for sender-domain 0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider (pieter.wuille[at]gmail.com) -0.0 SPF_PASS SPF: sender matches SPF record 1.0 HTML_MESSAGE BODY: HTML included in message -0.1 DKIM_VALID_AU Message has a valid DKIM or DK signature from author's domain 0.1 DKIM_SIGNED Message has a DKIM or DK signature, not necessarily valid -0.1 DKIM_VALID Message has at least one valid DKIM or DK signature X-Headers-End: 1YicFb-00066N-1k Cc: Bitcoin Dev Subject: Re: [Bitcoin-development] 75%/95% threshold for transaction versions X-BeenThere: bitcoin-development@lists.sourceforge.net X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Apr 2015 05:22:11 -0000 --001a11c37876b0081c0513d0a460 Content-Type: text/plain; charset=ISO-8859-1 On Apr 16, 2015 1:46 AM, "s7r" wrote: > but for transaction versions? In simple terms, if > 75% from all the > transactions in the latest 1000 blocks are version 'n', mark all > previous transaction versions as non-standard and if > 95% from all the > transactions in the latest 1000 blocks are version 'n' mark all previous > transaction versions as invalid. What problem are you trying to solve? The reason why BIP62 (as specified, it is just a draft) does not make v1 transactions invalid is because it is opt-in. The creator of a transaction needs to agree to protect it from malleability, and this subjects him to extra rules in the creation. Forcing v3 transactions would require every piece of wallet software to be changed. -- Pieter --001a11c37876b0081c0513d0a460 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable


On Apr 16, 2015 1:46 AM, "s7r" <s7r@sky-ip.org> wrote:
> but for transaction versions? In simple terms, if > 75% from all th= e
> transactions in the latest 1000 blocks are version 'n', mark a= ll
> previous transaction versions as non-standard and if > 95% from all= the
> transactions in the latest 1000 blocks are version 'n' mark al= l previous
> transaction versions as invalid.

What problem are you trying to solve?

The reason why BIP62 (as specified, it is just a draft) does= not make v1 transactions invalid is because it is opt-in. The creator of a= transaction needs to agree to protect it from malleability, and this subje= cts him to extra rules in the creation.

Forcing v3 transactions would require every piece of wallet = software to be changed.

--
Pieter

--001a11c37876b0081c0513d0a460--