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 34E4C1D59 for ; Mon, 29 Apr 2019 03:02:37 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 Received: from zinan.dashjr.org (zinan.dashjr.org [192.3.11.21]) by smtp1.linuxfoundation.org (Postfix) with ESMTP id CD9A0608 for ; Mon, 29 Apr 2019 03:02:36 +0000 (UTC) Received: from ishibashi.lan (adsl-98-70-226-33.gnv.bellsouth.net [98.70.226.33]) (Authenticated sender: luke-jr) by zinan.dashjr.org (Postfix) with ESMTPSA id 51B6738A0CB3; Mon, 29 Apr 2019 03:01:52 +0000 (UTC) X-Hashcash: 1:25:190429:bitcoin-dev@lists.linuxfoundation.org::crMjyYY1GhNda7ZI:ap6bK X-Hashcash: 1:25:190429:vitteaymeric@gmail.com::RTbrqOoOba0JaFkt:bW7ho From: Luke Dashjr To: bitcoin-dev@lists.linuxfoundation.org, Aymeric Vitte Date: Mon, 29 Apr 2019 03:01:41 +0000 User-Agent: KMail/1.9.10 References: <21346b3c-dad5-c666-9234-8916aa5a56e4@gmail.com> In-Reply-To: <21346b3c-dad5-c666-9234-8916aa5a56e4@gmail.com> X-KMail-QuotePrefix: > MIME-Version: 1.0 Content-Type: Text/Plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <201904290301.43459.luke@dashjr.org> X-Spam-Status: No, score=-4.2 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_MED autolearn=ham version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on smtp1.linux-foundation.org X-Mailman-Approved-At: Thu, 02 May 2019 23:19:53 +0000 Subject: Re: [bitcoin-dev] IsStandard X-BeenThere: bitcoin-dev@lists.linuxfoundation.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Bitcoin Protocol Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Apr 2019 03:02:37 -0000 On Saturday 27 April 2019 10:37:29 Aymeric Vitte via bitcoin-dev wrote: > Maybe trivial question but asking here because I can't find anything > clear (or updated) about it: is somewhere explained in details what txs > are considered standard and non standard today without having to read > the core code? > > For example, modification of multisig 2 of 3: > > scriptSig: > =C2=A0=C2=A0=C2=A0 OP_0 > =C2=A0=C2=A0=C2=A0 OP_PUSHDATA sign1 > =C2=A0=C2=A0=C2=A0 OP_PUSHDATA sign2 > =C2=A0=C2=A0=C2=A0 OP_2 > =C2=A0=C2=A0=C2=A0 OP_PUSHDATA OP_3 OP_CHECKM= ULTISIG > =C2=A0=C2=A0=C2=A0 > scriptPubKey: > =C2=A0=C2=A0=C2=A0 OP_HASH160 hash160( OP_3 > OP_CHECKMULTISIG) OP_EQUAL > > Is this standard? Are lightning txs standards ? etc The name is confusing. It has little to do with standards, really. IsStandard is just one of the functions which implement the node's policy. It allows many things for which there is no standard (eg, data carrier /=20 OP_RETURN outputs), and can vary freely from node to node (either by=20 configurable parameters, or by different/modified software) without breakin= g=20 consensus. As it is a node-specific criteria, it is not itself even a possible *subjec= t*=20 for standards. Additionally, it should not be given much (if any) attention when defining = new=20 standards. Just do what makes sense for the standard, and node policies can= =20 be adapted around that. So, overall, there's limited use case for documenting this beyond the code. It makes far more sense to document actual standards instead. Luke