📅 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
Aymeric Vitte [ARCHIVE] /
npub15f…g5grz
2023-06-07 18:17:51
in reply to nevent1q…j2wg
Author Public Key
npub15fc36esk6dy2x4ptk2ner209rl9u0d736gr99edtu9knu9uny80s4g5grzPublished at
2023-06-07 18:17:51Event JSON
{
"id": "b49ac50319f981612279c8bc08ca09e181860c24779631c70f997ea0e818f03a",
"pubkey": "a2711d6616d348a3542bb2a791a9e51fcbc7b7d1d20652e5abe16d3e179321df",
"created_at": 1686161871,
"kind": 1,
"tags": [
[
"e",
"0d900158f9d5b26bcb072426b2be38ab4201494265f56ca3fa9608d8abb0b82b",
"",
"root"
],
[
"e",
"f423383f481cb0a7bba2647de6800e71fd689fb6c822d2ca4fedfeb5ccacc7b4",
"",
"reply"
],
[
"p",
"04038841fa1dffefb87710e6ca5bcef647155d764360a6d1e77ab28e7646a869"
]
],
"content": "📅 Original date posted:2019-04-29\n📝 Original message:ZmnSCPxj, OK, but you can put whatever you like in the different\nstandard output script you mention (my example below whether legacy or\nsegwit)\n\nLuke, I am still confused or missing something, from your answer I\nunderstand that everything is accepted, so if we take the past example\nof bch coins wrongly sent to a segwit address, why was the recovery\nsolution where scriptsig included the matching segwit address/program\nnot a standard transaction?\n\nLe 29/04/2019 à 05:01, Luke Dashjr a écrit :\n\u003e On Saturday 27 April 2019 10:37:29 Aymeric Vitte via bitcoin-dev wrote:\n\u003e\u003e Maybe trivial question but asking here because I can't find anything\n\u003e\u003e clear (or updated) about it: is somewhere explained in details what txs\n\u003e\u003e are considered standard and non standard today without having to read\n\u003e\u003e the core code?\n\u003e\u003e\n\u003e\u003e For example, modification of multisig 2 of 3:\n\u003e\u003e\n\u003e\u003e scriptSig:\n\u003e\u003e OP_0\n\u003e\u003e OP_PUSHDATA sign1\n\u003e\u003e OP_PUSHDATA sign2\n\u003e\u003e OP_2\n\u003e\u003e OP_PUSHDATA \u003cpubkey1\u003e\u003cpubkey2\u003e\u003cpubkey3\u003e OP_3 OP_CHECKMULTISIG\n\u003e\u003e \n\u003e\u003e scriptPubKey:\n\u003e\u003e OP_HASH160 hash160(\u003cpubkey1\u003e\u003cpubkey2\u003e\u003cpubkey3\u003e OP_3\n\u003e\u003e OP_CHECKMULTISIG) OP_EQUAL\n\u003e\u003e\n\u003e\u003e Is this standard? Are lightning txs standards ? etc\n\u003e The name is confusing. It has little to do with standards, really.\n\u003e IsStandard is just one of the functions which implement the node's policy.\n\u003e It allows many things for which there is no standard (eg, data carrier / \n\u003e OP_RETURN outputs), and can vary freely from node to node (either by \n\u003e configurable parameters, or by different/modified software) without breaking \n\u003e consensus.\n\u003e\n\u003e As it is a node-specific criteria, it is not itself even a possible *subject* \n\u003e for standards.\n\u003e\n\u003e Additionally, it should not be given much (if any) attention when defining new \n\u003e standards. Just do what makes sense for the standard, and node policies can \n\u003e be adapted around that.\n\u003e\n\u003e So, overall, there's limited use case for documenting this beyond the code.\n\u003e It makes far more sense to document actual standards instead.\n\u003e\n\u003e Luke\n\ns",
"sig": "9703f4caee4a689fa92b89509da65590098b46a9fdddcb9dc99099571c003d8085f0f413c32f6171fbfc008e0febd1b6243b90f1eae006fc10efd975422c8446"
}