1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
|
Return-Path: <luke@dashjr.org>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id 34E4C1D59
for <bitcoin-dev@lists.linuxfoundation.org>;
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 <bitcoin-dev@lists.linuxfoundation.org>;
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 <luke@dashjr.org>
To: bitcoin-dev@lists.linuxfoundation.org,
Aymeric Vitte <vitteaymeric@gmail.com>
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 <bitcoin-dev.lists.linuxfoundation.org>
List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>,
<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe>
List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/>
List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org>
List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help>
List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>,
<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=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 <pubkey1><pubkey2><pubkey3> OP_3 OP_CHECKM=
ULTISIG
> =C2=A0=C2=A0=C2=A0
> scriptPubKey:
> =C2=A0=C2=A0=C2=A0 OP_HASH160 hash160(<pubkey1><pubkey2><pubkey3> 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
|
