From mboxrd@z Thu Jan 1 00:00:00 1970 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 1YMCEn-0008Io-FW for bitcoin-development@lists.sourceforge.net; Fri, 13 Feb 2015 09:08:37 +0000 Received-SPF: pass (sog-mx-4.v43.ch3.sourceforge.com: domain of blockcorp.com designates 74.125.82.170 as permitted sender) client-ip=74.125.82.170; envelope-from=ruben@blockcorp.com; helo=mail-we0-f170.google.com; Received: from mail-we0-f170.google.com ([74.125.82.170]) by sog-mx-4.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.76) id 1YMCEm-0005od-72 for bitcoin-development@lists.sourceforge.net; Fri, 13 Feb 2015 09:08:37 +0000 Received: by mail-we0-f170.google.com with SMTP id q59so15302368wes.1 for ; Fri, 13 Feb 2015 01:08:30 -0800 (PST) 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:to:cc:content-type; bh=P/iEgINMW34xXhhdttbcmE2Nnq9vKcvtaMvu+Y1XFCQ=; b=cUDEjYLLseG4gsL2/GxT3t9O6TRYkxCzF18u8crodK0EJodNmWERGaHM1861+u1oQF exUxV8iSHKPH+UgIXA4sTfQ6cPAC4PxUiZXY78m2VjZgCF6j0LbAbE7BLAUQxAOvUKlP usCCru6N+YvNvvoSrGcd3UuNqwqI8Csio/Agr83VHWv+wQi1cddthVl8pJY6ApTW6/px PKuWagcc1HGFT6vheQyL4uq4wz9W7egHoeUCGLijU3FyVSqSxS1KIfaob3/DWUw44uA4 rTAx3H46EvmbaTbSwHCquYiCSeraJ+bnk8VAYeH7AA83lYxQ6tXzGMng3C+MAvYPMWpt 5efg== X-Gm-Message-State: ALoCoQlJI0FTiEw4sIHT0jPamd64e3nveEnABLAY4o+4Ej/df0T7C502IxjoKpXKNdcAKo3LP/3o MIME-Version: 1.0 X-Received: by 10.180.208.69 with SMTP id mc5mr4866169wic.75.1423818101659; Fri, 13 Feb 2015 01:01:41 -0800 (PST) Received: by 10.27.11.10 with HTTP; Fri, 13 Feb 2015 01:01:41 -0800 (PST) In-Reply-To: <20150213075314.GA2122@savin.petertodd.org> References: <54DD1E3F.60006@thomaskerin.io> <201502122213.34765.luke@dashjr.org> <20150213075314.GA2122@savin.petertodd.org> Date: Fri, 13 Feb 2015 10:01:41 +0100 Message-ID: From: Ruben de Vries To: Peter Todd Content-Type: multipart/alternative; boundary=001a11c36d782cb439050ef47ca1 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 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: 1YMCEm-0005od-72 Cc: Bitcoin Dev Subject: Re: [Bitcoin-development] BIP for deterministic pay-to-script-hash multi-signature addresses 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: Fri, 13 Feb 2015 09:08:37 -0000 --001a11c36d782cb439050ef47ca1 Content-Type: text/plain; charset=UTF-8 The idea is more like BIP44/45 to have a 'standard' that software can comply by and express they do so that it makes a step towards compatibility between (wallet) software. On Fri, Feb 13, 2015 at 8:53 AM, Peter Todd wrote: > On Thu, Feb 12, 2015 at 10:13:33PM +0000, Luke Dashjr wrote: > > Where is the Specification section?? Does this support arbitrary > scripts, or > > only the simplest CHECKMULTISIG case? > > It might be enough to rewrite this BIP to basically say "all pubkeys > executed by all CHECKMULTISIG opcodes will be in the following canonical > order", followed by some explanatory examples of how to apply this > simple rule. > > OTOH we don't yet have a standard way of even talking about arbitrary > scripts, so it may very well turn out to be the case that the above rule > is too restrictive in many cases - I certainly would not want to do a > soft-fork to enforce this, or even make it an IsStandard() rule. > > -- > 'peter'[:-1]@petertodd.org > 000000000000000013cf8270118ba2efce8b304f8de359599fef95c3ab43dcb1 > -- BlockTrail B.V. Barbara Strozzilaan 201 1083HN Amsterdam The Netherlands Phone: +31 (0)612227277 E-mail: ruben@blocktrail.com Web: www.blocktrail.com Github: www.github.com/rubensayshi BlockTrail B.V. Is registered with the Dutch Chamber of Commerce in Amsterdam with registration No.:60262060 and VAT No.:NL853833035B01 --001a11c36d782cb439050ef47ca1 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
The idea is more like BIP44/45 to have a 'standard' tha= t software can comply by and express they do
so that it makes a step toward= s compatibility between (wallet) software.=C2=A0

On Fri, Feb 13, 2015 at 8:53 AM,= Peter Todd <pete@petertodd.org> wrote:
On Thu, Feb 12, 2015 at 10:13:33PM +0000, L= uke Dashjr wrote:
> Where is the Specification section?? Does this support arbitrary scrip= ts, or
> only the simplest CHECKMULTISIG case?

It might be enough to rewrite this BIP to basically say "all pu= bkeys
executed by all CHECKMULTISIG opcodes will be in the following canonical order", followed by some explanatory examples of how to apply this
simple rule.

OTOH we don't yet have a standard way of even talking about arbitrary scripts, so it may very well turn out to be the case that the above rule is too restrictive in many cases - I certainly would not want to do a
soft-fork to enforce this, or even make it an IsStandard() rule.

--
'peter'[:-1]@pet= ertodd.org
000000000000000013cf8270118ba2efce8b304f8de359599fef95c3ab43dcb1



--
BlockTrail B.V.
<= div>Barbara Strozzilaan 201
1083HN Amsterdam<= /font>
The Netherland= s

Phone: +31 (0)612227277

BlockTrail B.V. Is registered with the Dutch Chamber o= f Commerce in Amsterdam with registration No.:60262060 and VAT No.:NL853833= 035B01
--001a11c36d782cb439050ef47ca1--