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] Adding xpub field to PSBT to make multisig more secure

[Peter D. Gray via bitcoin-dev]

On Fri, Apr 26, 2019 at 05:21:06PM +0200, Stepan Snigirev wrote:
...
> Currently in PSBT there is no way to reliably say if the output uses the
> keys derived from the same root keys as the inputs aside from the key owned

Writing the multisig support for Coldcard, I've come to the same conclusion. 
I've
exchanged some helpful mail with Andrew Chow on this subject.

...
> I suggest to add the following key-value pairs to PSBT:
> Type: BIP 32 public key `PSBT_IN_BIP32_XPUB = 0x10`
...
> Type: BIP 32 public key `PSBT_OUT_BIP32_XPUB = 0x03`

I'd rather see the xpubs shared in the global section of the file,
with the restriction that they must/should only include the hardened
prefix of the path. The existing bip32 derivation path included in
individual inputs and outputs be merged in as needed.

After all in a typical PSBT, we would expect the same master keys
to be used on all inputs, and at least one output, and there might
be as many as 20 co-signers. No need to repeat all that information.

Even with this additions to the PSBT format, I think PSBT-signing
devices still need to store the xpubs of their co-signers. It's not
possible to safely show an incoming address to the user without a
full understanding of the other keys in a "multisig wallet". Also,
it represents data that should not change between PSBT instances
(ie. tomorrow's co-signers should match today's).

Having said that, the xpubs in the PSBT would allow a "trust on first
use" which I think can be a good feature.

---
Peter D. Gray  ||  Founder, Coinkite  ||  Twitter: @dochex  ||  GPG: A3A31BAD 
5A2A5B10


> Hi list,
> 
> I was looking at the bip174 PSBT specs, in particular for multisignature
> setup, and I think with current spec there is a way to steal user funds in
> M of N setup with M ≤ N/2.
> 
> I made a small write-up on this:
> https://github.com/stepansnigirev/random_notes/blob/master/psbt_multisig.md
> 
> To compress:
> 
> Currently in PSBT there is no way to reliably say if the output uses the
> keys derived from the same root keys as the inputs aside from the key owned
> by the signer => there is no way to verify that the output is a change
> output in multisig setup.
> 
> Therefore an attacker can replace half of the keys in the change address by
> his own keys and still get the transaction signed.
> 
> I suggest to add an xpub field to the inputs and outputs metadata, then
> signers can verify that the same xpubs are used for public keys in inputs
> and outputs => output is indeed a change.
> 
> Normally change and receiving addresses are derived from the same xpub with
> non-hardened derivation pathes, so providing xpub after the last hardened
> index should be enough to see that public keys of inputs and change output
> are derived from the same xpub.
> 
> I suggest to add the following key-value pairs to PSBT:
> 
> Type: BIP 32 public key `PSBT_IN_BIP32_XPUB = 0x10`
> - Key: derivation path for xpub
>   `{0x10}|{master key fingerprint}|{32-bit int}|...|{32-bit int}`
> - Value: 78-byte xpub value
>   `{xpub}`
> 
> Type: BIP 32 public key `PSBT_OUT_BIP32_XPUB = 0x03`
> - Key: derivation path for xpub
>   `{0x03}|{master key fingerprint}|{32-bit int}|...|{32-bit int}`
> - Value: 78-byte xpub value
>   `{xpub}`
> 
> Derivation paths are in the key of the key-value pair as they are used for
> lookup, and xpub itself is the actual value being looked up.
> 
> I also want to mention that Trezor for example doesn't suffer from this
> problem as they use xpubs to verify change outputs. So it may make sense to
> go through the communication protocols of existing hardware /
> multisignature wallets and see if there is something else we are missing.
> 
> If everyone is happy about the proposal I would prepare a pull request to
> the bip.
> 
> Best regards,
> Stepan Snigirev.
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev