From: Luke Dashjr <luke@dashjr.org>
To: bitcoin-dev@lists.linuxfoundation.org,
Aymeric Vitte <vitteaymeric@gmail.com>
Subject: Re: [bitcoin-dev] IsStandard
Date: Mon, 29 Apr 2019 03:01:41 +0000 [thread overview]
Message-ID: <201904290301.43459.luke@dashjr.org> (raw)
In-Reply-To: <21346b3c-dad5-c666-9234-8916aa5a56e4@gmail.com>
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:
> OP_0
> OP_PUSHDATA sign1
> OP_PUSHDATA sign2
> OP_2
> OP_PUSHDATA <pubkey1><pubkey2><pubkey3> OP_3 OP_CHECKMULTISIG
>
> scriptPubKey:
> 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 /
OP_RETURN outputs), and can vary freely from node to node (either by
configurable parameters, or by different/modified software) without breaking
consensus.
As it is a node-specific criteria, it is not itself even a possible *subject*
for standards.
Additionally, it should not be given much (if any) attention when defining new
standards. Just do what makes sense for the standard, and node policies can
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
next prev parent reply other threads:[~2019-04-29 3:02 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-04-27 10:37 [bitcoin-dev] IsStandard Aymeric Vitte
2019-04-29 1:46 ` ZmnSCPxj
2019-04-29 3:01 ` Luke Dashjr [this message]
2019-04-29 9:30 ` Aymeric Vitte
2019-04-30 4:29 ` ZmnSCPxj
2019-04-30 9:43 ` Aymeric Vitte
2019-05-02 0:10 ` ZmnSCPxj
2019-05-02 10:01 ` Aymeric Vitte
2019-05-02 23:33 ` James Prestwich
2019-05-03 9:51 ` Aymeric Vitte
2019-05-02 23:35 ` Pieter Wuille
2019-04-29 17:27 ` Marco Falke
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=201904290301.43459.luke@dashjr.org \
--to=luke@dashjr.org \
--cc=bitcoin-dev@lists.linuxfoundation.org \
--cc=vitteaymeric@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox