Aymeric Vitte [ARCHIVE] on Nostr: 📅 Original date posted:2019-04-29 📝 Original message:ZmnSCPxj, OK, but you can ...
📅 Original date posted:2019-04-29
📝 Original message: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
📝 Original message: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