Re: [bitcoin-dev] IsStandard

[Aymeric Vitte via bitcoin-dev]

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, and scriptPubKey OP_HASH160  OP_EQUAL, then scriptSig executes pushing
nothing and  into the stack, then scriptSig is pushed
again and executed with scriptPubKey, at the end we get nothing +
 + 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
>  > 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
> mailto:vitteayme...@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):
> 

Re: [bitcoin-dev] IsStandard

[Pieter Wuille via bitcoin-dev]

On Thu, 2 May 2019 at 16:28, Aymeric Vitte via bitcoin-dev
 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
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] IsStandard

[James Prestwich via bitcoin-dev]

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 <
> vitteayme...@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
>
> ___
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] IsStandard

[Aymeric Vitte via 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  
> 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

___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] IsStandard

[Marco Falke via bitcoin-dev]

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
 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  OP_3 OP_CHECKMULTISIG
>
> scriptPubKey:
> OP_HASH160 hash160( 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
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] IsStandard

[Luke Dashjr via bitcoin-dev]

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  OP_3 OP_CHECKMULTISIG
>    
> scriptPubKey:
>     OP_HASH160 hash160( 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
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] IsStandard

[ZmnSCPxj via bitcoin-dev]

Good morning Aymeric,


Sent with ProtonMail Secure Email.

‐‐‐ Original Message ‐‐‐
On Tuesday, April 30, 2019 5:43 PM, Aymeric Vitte  
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
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] IsStandard

[Aymeric Vitte via 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  
> 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

___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] IsStandard

[ZmnSCPxj via bitcoin-dev]

Good morning Aymeric,


Sent with ProtonMail Secure Email.

‐‐‐ Original Message ‐‐‐
On Monday, April 29, 2019 5:30 PM, Aymeric Vitte  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
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] IsStandard

[ZmnSCPxj via bitcoin-dev]

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 
 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  OP_3 OP_CHECKMULTISIG
>    
> scriptPubKey:
>     OP_HASH160 hash160( 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


___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] IsStandard

[Aymeric Vitte via bitcoin-dev]

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  OP_3 OP_CHECKMULTISIG
>>    
>> scriptPubKey:
>>     OP_HASH160 hash160( 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

___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

[bitcoin-dev] IsStandard

[Aymeric Vitte via 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  OP_3 OP_CHECKMULTISIG
   
scriptPubKey:
    OP_HASH160 hash160( 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