Aymeric Vitte [ARCHIVE] on Nostr: 📅 Original date posted:2019-05-03 📝 Original message:Great doc, thanks, then my ...
📅 Original date posted:2019-05-03
📝 Original message: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 at lists.linuxfoundation.org
> <mailto:bitcoin-dev at 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 at gmail.com <mailto:vitteaymeric at 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 at lists.linuxfoundation.org
> <mailto:bitcoin-dev at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20190503/fa40d55f/attachment-0001.html>;
📝 Original message: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 at lists.linuxfoundation.org
> <mailto:bitcoin-dev at 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 at gmail.com <mailto:vitteaymeric at 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 at lists.linuxfoundation.org
> <mailto:bitcoin-dev at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20190503/fa40d55f/attachment-0001.html>;