* [bitcoin-dev] IsStandard
@ 2019-04-27 10:37 Aymeric Vitte
2019-04-29 1:46 ` ZmnSCPxj
` (2 more replies)
0 siblings, 3 replies; 12+ messages in thread
From: Aymeric Vitte @ 2019-04-27 10:37 UTC (permalink / raw)
To: Bitcoin Dev
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
^ permalink raw reply [flat|nested] 12+ messages in thread* Re: [bitcoin-dev] IsStandard 2019-04-27 10:37 [bitcoin-dev] IsStandard Aymeric Vitte @ 2019-04-29 1:46 ` ZmnSCPxj 2019-04-29 3:01 ` Luke Dashjr 2019-04-29 17:27 ` Marco Falke 2 siblings, 0 replies; 12+ messages in thread From: ZmnSCPxj @ 2019-04-29 1:46 UTC (permalink / raw) To: Aymeric Vitte, Bitcoin Protocol Discussion Good morning Aymeric, Different versions may consider different output scripts standard. Your rule of thumb, post-SegWit, should be: * If not P2PKH or P2WPKH, then wrap it in a P2SH or P2WSH. There are more standard outputs accepted, but you can be reasonably sure that P2PKH, P2WPKH, P2SH, and P2WSH are the only standard output scripts that are likely to remain supported in the mid-future (5->10 years from 2019). Lightning uses P2WSH for its scripts. Any m-of-n signing scheme in Bitcoin is P2SH (usually) or P2WSH (if you are cool). Regards, ZmnSCPxj Sent with ProtonMail Secure Email. ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐ On Saturday, April 27, 2019 6:37 PM, Aymeric Vitte via bitcoin-dev <bitcoin-dev@lists•linuxfoundation.org> 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 > > bitcoin-dev mailing list > bitcoin-dev@lists•linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [bitcoin-dev] IsStandard 2019-04-27 10:37 [bitcoin-dev] IsStandard Aymeric Vitte 2019-04-29 1:46 ` ZmnSCPxj @ 2019-04-29 3:01 ` Luke Dashjr 2019-04-29 9:30 ` Aymeric Vitte 2019-04-29 17:27 ` Marco Falke 2 siblings, 1 reply; 12+ messages in thread From: Luke Dashjr @ 2019-04-29 3:01 UTC (permalink / raw) To: bitcoin-dev, Aymeric Vitte 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 ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [bitcoin-dev] IsStandard 2019-04-29 3:01 ` Luke Dashjr @ 2019-04-29 9:30 ` Aymeric Vitte 2019-04-30 4:29 ` ZmnSCPxj 0 siblings, 1 reply; 12+ messages in thread From: Aymeric Vitte @ 2019-04-29 9:30 UTC (permalink / raw) To: Luke Dashjr, bitcoin-dev, ZmnSCPxj 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 ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [bitcoin-dev] IsStandard 2019-04-29 9:30 ` Aymeric Vitte @ 2019-04-30 4:29 ` ZmnSCPxj 2019-04-30 9:43 ` Aymeric Vitte 0 siblings, 1 reply; 12+ messages in thread From: ZmnSCPxj @ 2019-04-30 4:29 UTC (permalink / raw) To: Aymeric Vitte; +Cc: bitcoin-dev Good morning Aymeric, Sent with ProtonMail Secure Email. ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐ On Monday, April 29, 2019 5:30 PM, Aymeric Vitte <vitteaymeric@gmail•com> wrote: > ZmnSCPxj, OK, but you can put whatever you like in the different > standard output script you mention (my example below whether legacy or > segwit) > I am uncertain what you mean by this. For P2PKH and P2WPKH, you must present a hash of a public key. You cannot present a hash of anything else. The P2PKH template can be interpreted as a script, but is actually recognized as a template by most current nodes (in a way that is consistent with interpreting it as a script). For P2SH and P2WSH, you must present a hash of a script. It is more helpful to consider that *today* nodes recognize particular patterns (P2PKH, P2WPKH, P2SH, P2WSH) as templates and not as scripts to be executed. In any case, if you want to make anything more complicated than "single signer" you should use P2SH or P2WSH regardless, and give your script. If you want to assure somebody that a particular P2SH or P2WSH commits to a particular policy, just expose the policy script to them and have them (i.e. their client software) verify that the policy is what the user wants and that when hashed it matches the P2SH/P2WSH. As Luke said, nodes can have any policy for propagating transactions. However it is generally expected that P2PKH, P2WPKH, P2SH, and P2WSH will be propagated by a majority of nodes, if only because those are reliably "passed" by `isStandard` in the default latest Bitcoin Core and most people will not modify the Core code. Generally, anything that isn't P2PKH, P2WPKH, P2SH, or P2WSH will not likely be propagated by the network. You *could* still coordinate with one or more miners to get it mined: you can put anything in the block, it is simply that most nodes will not inform miners about transactions that do not pay out to P2PKH, P2WPKH, P2SH, or P2WSH. Regards, ZmnSCPxj ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [bitcoin-dev] IsStandard 2019-04-30 4:29 ` ZmnSCPxj @ 2019-04-30 9:43 ` Aymeric Vitte 2019-05-02 0:10 ` ZmnSCPxj 0 siblings, 1 reply; 12+ messages in thread From: Aymeric Vitte @ 2019-04-30 9:43 UTC (permalink / raw) To: ZmnSCPxj; +Cc: bitcoin-dev I must badly explain my point (or just wondering things that do not exist finally), the question is indeed whether nodes will relay non usual transactions or not and how to know what they will accept or not: - my modified multisig 2 of 3: I did put OP_2 out of the usual redeem script, the redeem script still matches scriptpubkey and scriptsig will execute succesfully, that's a normal legacy P2SH or segwit P2WSH - bch segwit recovery: it's a p2sh transaction without any signature verification, as far as I remember there was a story that it could not propagate in the network (even taking the risk to be stolen) and that people had to contact a (honest) miner - sha bounties: same as above, p2sh transactions without signatures etc Will all of those transactions propagate normally? And then the rule is just that it matches the P2PKH, P2WPKH, P2SH, or P2WSH templates whatever scripts you put inside? Le 30/04/2019 à 06:29, ZmnSCPxj a écrit : > Good morning Aymeric, > > > Sent with ProtonMail Secure Email. > > ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐ > On Monday, April 29, 2019 5:30 PM, Aymeric Vitte <vitteaymeric@gmail•com> wrote: > >> ZmnSCPxj, OK, but you can put whatever you like in the different >> standard output script you mention (my example below whether legacy or >> segwit) >> > I am uncertain what you mean by this. > > For P2PKH and P2WPKH, you must present a hash of a public key. > You cannot present a hash of anything else. > > The P2PKH template can be interpreted as a script, but is actually recognized as a template by most current nodes (in a way that is consistent with interpreting it as a script). > > For P2SH and P2WSH, you must present a hash of a script. > > It is more helpful to consider that *today* nodes recognize particular patterns (P2PKH, P2WPKH, P2SH, P2WSH) as templates and not as scripts to be executed. > > In any case, if you want to make anything more complicated than "single signer" you should use P2SH or P2WSH regardless, and give your script. > If you want to assure somebody that a particular P2SH or P2WSH commits to a particular policy, just expose the policy script to them and have them (i.e. their client software) verify that the policy is what the user wants and that when hashed it matches the P2SH/P2WSH. > > As Luke said, nodes can have any policy for propagating transactions. > However it is generally expected that P2PKH, P2WPKH, P2SH, and P2WSH will be propagated by a majority of nodes, if only because those are reliably "passed" by `isStandard` in the default latest Bitcoin Core and most people will not modify the Core code. > > Generally, anything that isn't P2PKH, P2WPKH, P2SH, or P2WSH will not likely be propagated by the network. > You *could* still coordinate with one or more miners to get it mined: you can put anything in the block, it is simply that most nodes will not inform miners about transactions that do not pay out to P2PKH, P2WPKH, P2SH, or P2WSH. > > Regards, > ZmnSCPxj -- Move your coins by yourself (browser version): https://peersm.com/wallet Bitcoin transactions made simple: https://github.com/Ayms/bitcoin-transactions Zcash wallets made simple: https://github.com/Ayms/zcash-wallets Bitcoin wallets made simple: https://github.com/Ayms/bitcoin-wallets Get the torrent dynamic blocklist: http://peersm.com/getblocklist Check the 10 M passwords list: http://peersm.com/findmyass Anti-spies and private torrents, dynamic blocklist: http://torrent-live.org Peersm : http://www.peersm.com torrent-live: https://github.com/Ayms/torrent-live node-Tor : https://www.github.com/Ayms/node-Tor GitHub : https://www.github.com/Ayms ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [bitcoin-dev] IsStandard 2019-04-30 9:43 ` Aymeric Vitte @ 2019-05-02 0:10 ` ZmnSCPxj 2019-05-02 10:01 ` Aymeric Vitte 0 siblings, 1 reply; 12+ messages in thread From: ZmnSCPxj @ 2019-05-02 0:10 UTC (permalink / raw) To: Aymeric Vitte; +Cc: bitcoin-dev Good morning Aymeric, Sent with ProtonMail Secure Email. ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐ On Tuesday, April 30, 2019 5:43 PM, Aymeric Vitte <vitteaymeric@gmail•com> wrote: > I must badly explain my point (or just wondering things that do not > exist finally), the question is indeed whether nodes will relay non > usual transactions or not and how to know what they will accept or not: > > - my modified multisig 2 of 3: I did put OP_2 out of the usual redeem > script, the redeem script still matches scriptpubkey and scriptsig will > execute succesfully, that's a normal legacy P2SH or segwit P2WSH > > - bch segwit recovery: it's a p2sh transaction without any signature > verification, as far as I remember there was a story that it could not > propagate in the network (even taking the risk to be stolen) and that > people had to contact a (honest) miner > > - sha bounties: same as above, p2sh transactions without signatures > > etc > > Will all of those transactions propagate normally? And then the rule is > just that it matches the P2PKH, P2WPKH, P2SH, or P2WSH templates > whatever scripts you put inside? P2PKH and P2WPKH cannot have custom script. However, yes, any custom script can be wrapped in P2SH and P2WSH and it will be propagated. The P2SH/P2WSH hides the details of your custom script so cannot be filtered based on your custom script. Do realize that once a claim on your modified x-of-3 is propagated your `redeemScript` is known and someone can attempt to RBF (or coordinate with a miner) with a modified `witness` stack or `scriptSig` to claim your UTXO. (I do not know if `OP_CHECKMULTISIG` supports 0-of-3 but at least one of your signatories could make it a 1-of-3 and bribe a miner to get it claimed) I cannot answer for BCH; arguably that is off-topic here. The old SHA bounty transactions were propagated in the days before `isStandard` I think. Either that or they were put in by miners. An SHA bounty can still be propagated today if they are wrapped in a P2SH or P2WSH, but you have to publish the `redeemScript` yourself in some other method. Or bribe a miner if the transaction is not time-sensitive (for an SHA bounty, unlikely to be time-sensitive). Regards, ZmnSCPxj ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [bitcoin-dev] IsStandard 2019-05-02 0:10 ` ZmnSCPxj @ 2019-05-02 10:01 ` Aymeric Vitte 2019-05-02 23:33 ` James Prestwich 2019-05-02 23:35 ` Pieter Wuille 0 siblings, 2 replies; 12+ messages in thread From: Aymeric Vitte @ 2019-05-02 10:01 UTC (permalink / raw) To: ZmnSCPxj; +Cc: bitcoin-dev Thanks for the answer, indeed for the redeem script and someone attempting a 0/1 of 3, good example So to summarize everything is standard as long as it matches P2PKH, P2SH, P2WPKH or P2WSH , the redeem scripts for the sha bounties are in op_return Still the case of bch is unclear (it's related since based on bitcoin code unless they changed the policy), was the story that nodes would not propagate the fix or that people did not want to take the risk to propagate it? And why a non segwit old bitcoin node would not accept it either? Le 02/05/2019 à 02:10, ZmnSCPxj a écrit : > Good morning Aymeric, > > > Sent with ProtonMail Secure Email. > > ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐ > On Tuesday, April 30, 2019 5:43 PM, Aymeric Vitte <vitteaymeric@gmail•com> wrote: > >> I must badly explain my point (or just wondering things that do not >> exist finally), the question is indeed whether nodes will relay non >> usual transactions or not and how to know what they will accept or not: >> >> - my modified multisig 2 of 3: I did put OP_2 out of the usual redeem >> script, the redeem script still matches scriptpubkey and scriptsig will >> execute succesfully, that's a normal legacy P2SH or segwit P2WSH >> >> - bch segwit recovery: it's a p2sh transaction without any signature >> verification, as far as I remember there was a story that it could not >> propagate in the network (even taking the risk to be stolen) and that >> people had to contact a (honest) miner >> >> - sha bounties: same as above, p2sh transactions without signatures >> >> etc >> >> Will all of those transactions propagate normally? And then the rule is >> just that it matches the P2PKH, P2WPKH, P2SH, or P2WSH templates >> whatever scripts you put inside? > P2PKH and P2WPKH cannot have custom script. > However, yes, any custom script can be wrapped in P2SH and P2WSH and it will be propagated. > The P2SH/P2WSH hides the details of your custom script so cannot be filtered based on your custom script. > Do realize that once a claim on your modified x-of-3 is propagated your `redeemScript` is known and someone can attempt to RBF (or coordinate with a miner) with a modified `witness` stack or `scriptSig` to claim your UTXO. > (I do not know if `OP_CHECKMULTISIG` supports 0-of-3 but at least one of your signatories could make it a 1-of-3 and bribe a miner to get it claimed) > > I cannot answer for BCH; arguably that is off-topic here. > > The old SHA bounty transactions were propagated in the days before `isStandard` I think. > Either that or they were put in by miners. > An SHA bounty can still be propagated today if they are wrapped in a P2SH or P2WSH, but you have to publish the `redeemScript` yourself in some other method. > Or bribe a miner if the transaction is not time-sensitive (for an SHA bounty, unlikely to be time-sensitive). > > Regards, > ZmnSCPxj -- Move your coins by yourself (browser version): https://peersm.com/wallet Bitcoin transactions made simple: https://github.com/Ayms/bitcoin-transactions Zcash wallets made simple: https://github.com/Ayms/zcash-wallets Bitcoin wallets made simple: https://github.com/Ayms/bitcoin-wallets Get the torrent dynamic blocklist: http://peersm.com/getblocklist Check the 10 M passwords list: http://peersm.com/findmyass Anti-spies and private torrents, dynamic blocklist: http://torrent-live.org Peersm : http://www.peersm.com torrent-live: https://github.com/Ayms/torrent-live node-Tor : https://www.github.com/Ayms/node-Tor GitHub : https://www.github.com/Ayms ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [bitcoin-dev] IsStandard 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 1 sibling, 1 reply; 12+ messages in thread From: James Prestwich @ 2019-05-02 23:33 UTC (permalink / raw) To: Aymeric Vitte, Bitcoin Protocol Discussion [-- Attachment #1: Type: text/plain, Size: 4560 bytes --] Hi Aymeric, As Luke and ZmnSCPxj have pointed out, documenting standardness is sisyphean, as it varies from version to version. I recently put together a reference for default TX_NONSTANDARD policies in v0.18, which can be found here: https://prestwi.ch/the-bitcoin-nonstandard/ It applies only to v0.18, and may already be outdated. Best, James On Thu, May 2, 2019 at 4:29 PM Aymeric Vitte via bitcoin-dev < bitcoin-dev@lists•linuxfoundation.org> wrote: > Thanks for the answer, indeed for the redeem script and someone > attempting a 0/1 of 3, good example > > So to summarize everything is standard as long as it matches P2PKH, > P2SH, P2WPKH or P2WSH , the redeem scripts for the sha bounties are in > op_return > > Still the case of bch is unclear (it's related since based on bitcoin > code unless they changed the policy), was the story that nodes would not > propagate the fix or that people did not want to take the risk to > propagate it? And why a non segwit old bitcoin node would not accept it > either? > > Le 02/05/2019 à 02:10, ZmnSCPxj a écrit : > > Good morning Aymeric, > > > > > > Sent with ProtonMail Secure Email. > > > > ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐ > > On Tuesday, April 30, 2019 5:43 PM, Aymeric Vitte < > vitteaymeric@gmail•com> wrote: > > > >> I must badly explain my point (or just wondering things that do not > >> exist finally), the question is indeed whether nodes will relay non > >> usual transactions or not and how to know what they will accept or not: > >> > >> - my modified multisig 2 of 3: I did put OP_2 out of the usual redeem > >> script, the redeem script still matches scriptpubkey and scriptsig > will > >> execute succesfully, that's a normal legacy P2SH or segwit P2WSH > >> > >> - bch segwit recovery: it's a p2sh transaction without any signature > >> verification, as far as I remember there was a story that it could > not > >> propagate in the network (even taking the risk to be stolen) and > that > >> people had to contact a (honest) miner > >> > >> - sha bounties: same as above, p2sh transactions without signatures > >> > >> etc > >> > >> Will all of those transactions propagate normally? And then the > rule is > >> just that it matches the P2PKH, P2WPKH, P2SH, or P2WSH templates > >> whatever scripts you put inside? > > P2PKH and P2WPKH cannot have custom script. > > However, yes, any custom script can be wrapped in P2SH and P2WSH and it > will be propagated. > > The P2SH/P2WSH hides the details of your custom script so cannot be > filtered based on your custom script. > > Do realize that once a claim on your modified x-of-3 is propagated your > `redeemScript` is known and someone can attempt to RBF (or coordinate with > a miner) with a modified `witness` stack or `scriptSig` to claim your UTXO. > > (I do not know if `OP_CHECKMULTISIG` supports 0-of-3 but at least one of > your signatories could make it a 1-of-3 and bribe a miner to get it claimed) > > > > I cannot answer for BCH; arguably that is off-topic here. > > > > The old SHA bounty transactions were propagated in the days before > `isStandard` I think. > > Either that or they were put in by miners. > > An SHA bounty can still be propagated today if they are wrapped in a > P2SH or P2WSH, but you have to publish the `redeemScript` yourself in some > other method. > > Or bribe a miner if the transaction is not time-sensitive (for an SHA > bounty, unlikely to be time-sensitive). > > > > Regards, > > ZmnSCPxj > > -- > Move your coins by yourself (browser version): https://peersm.com/wallet > Bitcoin transactions made simple: > https://github.com/Ayms/bitcoin-transactions > Zcash wallets made simple: https://github.com/Ayms/zcash-wallets > Bitcoin wallets made simple: https://github.com/Ayms/bitcoin-wallets > Get the torrent dynamic blocklist: http://peersm.com/getblocklist > Check the 10 M passwords list: http://peersm.com/findmyass > Anti-spies and private torrents, dynamic blocklist: > http://torrent-live.org > Peersm : http://www.peersm.com > torrent-live: https://github.com/Ayms/torrent-live > node-Tor <https://github.com/Ayms/torrent-livenode-Tor> : > https://www.github.com/Ayms/node-Tor > GitHub : https://www.github.com/Ayms > > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists•linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > [-- Attachment #2: Type: text/html, Size: 6407 bytes --] ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [bitcoin-dev] IsStandard 2019-05-02 23:33 ` James Prestwich @ 2019-05-03 9:51 ` Aymeric Vitte 0 siblings, 0 replies; 12+ messages in thread From: Aymeric Vitte @ 2019-05-03 9:51 UTC (permalink / raw) To: James Prestwich, Bitcoin Protocol Discussion [-- Attachment #1: Type: text/plain, Size: 6876 bytes --] Great doc, thanks, then my previous summarized conclusion was wrong, trying on my side to write a "demistifying (simply) once for all bitcoin scripting", not sure that "simply" can stay in the title at the end... So my multisig modification is non standard, now I am still puzzled by something, mainly the fact that we have op_pushdata inside op_pushdata, maybe I am misreading the specs, but in case of p2sh only the last op_pushdata (called {serialized script} (or redeem script) is executed, then if succesfull it comes back onto the stack and scriptpubkey is executed So, let's take again the BCH recovery example, scriptSig was OP_PUSHDATA 0014<hash160 of pubkey>, and scriptPubKey OP_HASH160 <hash160 of 0014<hash160 of pubkey> OP_EQUAL, then scriptSig executes pushing nothing and <hash160 of pubkey> into the stack, then scriptSig is pushed again and executed with scriptPubKey, at the end we get nothing + <hash160 of pubkey> + 1 in the stack, then cleanstack (maybe among others, I have to read in more details your doc) says it is a correct transaction but non standard, is this correct? Le 03/05/2019 à 01:33, James Prestwich a écrit : > Hi Aymeric, > > As Luke and ZmnSCPxj have pointed out, documenting standardness is > sisyphean, as it varies from version to version. I recently put > together a reference for default TX_NONSTANDARD policies in v0.18, > which can be found here: https://prestwi.ch/the-bitcoin-nonstandard/ > > It applies only to v0.18, and may already be outdated. > > Best, > James > > On Thu, May 2, 2019 at 4:29 PM Aymeric Vitte via bitcoin-dev > <bitcoin-dev@lists•linuxfoundation.org > <mailto:bitcoin-dev@lists•linuxfoundation.org>> wrote: > > Thanks for the answer, indeed for the redeem script and someone > attempting a 0/1 of 3, good example > > So to summarize everything is standard as long as it matches P2PKH, > P2SH, P2WPKH or P2WSH , the redeem scripts for the sha bounties are in > op_return > > Still the case of bch is unclear (it's related since based on bitcoin > code unless they changed the policy), was the story that nodes > would not > propagate the fix or that people did not want to take the risk to > propagate it? And why a non segwit old bitcoin node would not > accept it > either? > > Le 02/05/2019 à 02:10, ZmnSCPxj a écrit : > > Good morning Aymeric, > > > > > > Sent with ProtonMail Secure Email. > > > > ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐ > > On Tuesday, April 30, 2019 5:43 PM, Aymeric Vitte > <vitteaymeric@gmail•com <mailto:vitteaymeric@gmail•com>> wrote: > > > >> I must badly explain my point (or just wondering things that do not > >> exist finally), the question is indeed whether nodes will relay non > >> usual transactions or not and how to know what they will accept > or not: > >> > >> - my modified multisig 2 of 3: I did put OP_2 out of the > usual redeem > >> script, the redeem script still matches scriptpubkey and > scriptsig will > >> execute succesfully, that's a normal legacy P2SH or segwit > P2WSH > >> > >> - bch segwit recovery: it's a p2sh transaction without any > signature > >> verification, as far as I remember there was a story that > it could not > >> propagate in the network (even taking the risk to be > stolen) and that > >> people had to contact a (honest) miner > >> > >> - sha bounties: same as above, p2sh transactions without > signatures > >> > >> etc > >> > >> Will all of those transactions propagate normally? And then > the rule is > >> just that it matches the P2PKH, P2WPKH, P2SH, or P2WSH > templates > >> whatever scripts you put inside? > > P2PKH and P2WPKH cannot have custom script. > > However, yes, any custom script can be wrapped in P2SH and P2WSH > and it will be propagated. > > The P2SH/P2WSH hides the details of your custom script so cannot > be filtered based on your custom script. > > Do realize that once a claim on your modified x-of-3 is > propagated your `redeemScript` is known and someone can attempt to > RBF (or coordinate with a miner) with a modified `witness` stack > or `scriptSig` to claim your UTXO. > > (I do not know if `OP_CHECKMULTISIG` supports 0-of-3 but at > least one of your signatories could make it a 1-of-3 and bribe a > miner to get it claimed) > > > > I cannot answer for BCH; arguably that is off-topic here. > > > > The old SHA bounty transactions were propagated in the days > before `isStandard` I think. > > Either that or they were put in by miners. > > An SHA bounty can still be propagated today if they are wrapped > in a P2SH or P2WSH, but you have to publish the `redeemScript` > yourself in some other method. > > Or bribe a miner if the transaction is not time-sensitive (for > an SHA bounty, unlikely to be time-sensitive). > > > > Regards, > > ZmnSCPxj > > -- > Move your coins by yourself (browser version): > https://peersm.com/wallet > Bitcoin transactions made simple: > https://github.com/Ayms/bitcoin-transactions > Zcash wallets made simple: https://github.com/Ayms/zcash-wallets > Bitcoin wallets made simple: https://github.com/Ayms/bitcoin-wallets > Get the torrent dynamic blocklist: http://peersm.com/getblocklist > Check the 10 M passwords list: http://peersm.com/findmyass > Anti-spies and private torrents, dynamic blocklist: > http://torrent-live.org > Peersm : http://www.peersm.com > torrent-live: https://github.com/Ayms/torrent-live > node-Tor <https://github.com/Ayms/torrent-livenode-Tor> : > https://www.github.com/Ayms/node-Tor > GitHub : https://www.github.com/Ayms > > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists•linuxfoundation.org > <mailto:bitcoin-dev@lists•linuxfoundation.org> > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > -- Move your coins by yourself (browser version): https://peersm.com/wallet Bitcoin transactions made simple: https://github.com/Ayms/bitcoin-transactions Zcash wallets made simple: https://github.com/Ayms/zcash-wallets Bitcoin wallets made simple: https://github.com/Ayms/bitcoin-wallets Get the torrent dynamic blocklist: http://peersm.com/getblocklist Check the 10 M passwords list: http://peersm.com/findmyass Anti-spies and private torrents, dynamic blocklist: http://torrent-live.org Peersm : http://www.peersm.com torrent-live: https://github.com/Ayms/torrent-live node-Tor : https://www.github.com/Ayms/node-Tor GitHub : https://www.github.com/Ayms [-- Attachment #2: Type: text/html, Size: 11577 bytes --] ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [bitcoin-dev] IsStandard 2019-05-02 10:01 ` Aymeric Vitte 2019-05-02 23:33 ` James Prestwich @ 2019-05-02 23:35 ` Pieter Wuille 1 sibling, 0 replies; 12+ messages in thread From: Pieter Wuille @ 2019-05-02 23:35 UTC (permalink / raw) To: Aymeric Vitte, Bitcoin Protocol Discussion On Thu, 2 May 2019 at 16:28, Aymeric Vitte via bitcoin-dev <bitcoin-dev@lists•linuxfoundation.org> wrote: > > Thanks for the answer, indeed for the redeem script and someone > attempting a 0/1 of 3, good example > > So to summarize everything is standard as long as it matches P2PKH, > P2SH, P2WPKH or P2WSH , the redeem scripts for the sha bounties are in > op_return Generally, all spends of P2SH/P2WSH is standard, with the following exceptions: * Non-push operations in the scriptSig * Resource limitations (too large scripts or items on the stack) * Protections against known attack vectors (low s rule, cleanstack rule, minimally encoded numbers rule, codesep usage, ...) * Usage of unconditionally spendable constructions intended for future extensions, such as spending future segwit versions. Cheers, -- Pieter ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [bitcoin-dev] IsStandard 2019-04-27 10:37 [bitcoin-dev] IsStandard Aymeric Vitte 2019-04-29 1:46 ` ZmnSCPxj 2019-04-29 3:01 ` Luke Dashjr @ 2019-04-29 17:27 ` Marco Falke 2 siblings, 0 replies; 12+ messages in thread From: Marco Falke @ 2019-04-29 17:27 UTC (permalink / raw) To: Bitcoin Protocol Discussion There is not a single document that describes what is standard and what is not. Transaction relay policy (including minimum relay fees) may change over time, across different implementations or different versions of the same implementation. Generally you can assume that commonly used scripts that are standard today remain standard. To test if a script is standard and accepted by current relay policy of a Bitcoin Core node, you can create a tx that spends from it on mainnet or on testnet and see if it is accepted to the mempool of your local node. Make sure to disable -acceptnonstdtxn=0 on testnet. Should the standardness-rules of a script type ever change, it will be announced and discussed on this mailing list. And of course, lightning transactions are standard as they otherwise wouldn't propagate. Best, Marco On Sun, Apr 28, 2019 at 9:06 PM Aymeric Vitte via bitcoin-dev <bitcoin-dev@lists•linuxfoundation.org> 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 > > > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists•linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev ^ permalink raw reply [flat|nested] 12+ messages in thread
end of thread, other threads:[~2019-05-03 9:51 UTC | newest] Thread overview: 12+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2019-04-27 10:37 [bitcoin-dev] IsStandard Aymeric Vitte 2019-04-29 1:46 ` ZmnSCPxj 2019-04-29 3:01 ` Luke Dashjr 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
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox