From: Aymeric Vitte <vitteaymeric@gmail•com>
To: Luke Dashjr <luke@dashjr•org>,
bitcoin-dev@lists•linuxfoundation.org,
ZmnSCPxj <ZmnSCPxj@protonmail•com>
Subject: Re: [bitcoin-dev] IsStandard
Date: Mon, 29 Apr 2019 11:30:39 +0200 [thread overview]
Message-ID: <56b67b57-dc11-183a-1f4e-5a8c296b64cc@gmail.com> (raw)
In-Reply-To: <201904290301.43459.luke@dashjr.org>
ZmnSCPxj, OK, but you can put whatever you like in the different
standard output script you mention (my example below whether legacy or
segwit)
Luke, I am still confused or missing something, from your answer I
understand that everything is accepted, so if we take the past example
of bch coins wrongly sent to a segwit address, why was the recovery
solution where scriptsig included the matching segwit address/program
not a standard transaction?
Le 29/04/2019 à 05:01, Luke Dashjr a écrit :
> 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
s
next prev parent reply other threads:[~2019-04-29 9:30 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-04-27 10:37 Aymeric Vitte
2019-04-29 1:46 ` ZmnSCPxj
2019-04-29 3:01 ` Luke Dashjr
2019-04-29 9:30 ` Aymeric Vitte [this message]
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=56b67b57-dc11-183a-1f4e-5a8c296b64cc@gmail.com \
--to=vitteaymeric@gmail$(echo .)com \
--cc=ZmnSCPxj@protonmail$(echo .)com \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
--cc=luke@dashjr$(echo .)org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
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