[bitcoin-dev] IsStandard

Aymeric Vitte vitteaymeric at gmail.com
Mon Apr 29 09:30:39 UTC 2019


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



More information about the bitcoin-dev mailing list