* [bitcoin-dev] Disallow insecure use of SIGHASH_SINGLE
@ 2018-05-31 18:53 Johnson Lau
2018-06-06 0:17 ` Chris Stewart
2018-06-06 0:49 ` Peter Todd
0 siblings, 2 replies; 4+ messages in thread
From: Johnson Lau @ 2018-05-31 18:53 UTC (permalink / raw)
To: bitcoin-dev
I’ve made a PR to add a new policy to disallow using SIGHASH_SINGLE without matched output:
https://github.com/bitcoin/bitcoin/pull/13360
Signature of this form is insecure, as it commits to no output while users might think it commits to one. It is even worse in non-segwit scripts, which is effectively SIGHASH_NOINPUT|SIGHASH_NONE, so any UTXO of the same key could be stolen. (It’s restricted to only one UTXO in segwit, but it’s still like a SIGHASH_NONE.)
This is one of the earliest unintended consensus behavior. Since these signatures are inherently unsafe, I think it does no harm to disable this unintended “feature” with a softfork. But since these signatures are currently allowed, the first step is to make them non-standard.
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [bitcoin-dev] Disallow insecure use of SIGHASH_SINGLE
2018-05-31 18:53 [bitcoin-dev] Disallow insecure use of SIGHASH_SINGLE Johnson Lau
@ 2018-06-06 0:17 ` Chris Stewart
2018-06-06 0:43 ` Peter Todd
2018-06-06 0:49 ` Peter Todd
1 sibling, 1 reply; 4+ messages in thread
From: Chris Stewart @ 2018-06-06 0:17 UTC (permalink / raw)
To: Johnson Lau, Bitcoin Protocol Discussion
[-- Attachment #1: Type: text/plain, Size: 1324 bytes --]
Do you have any thoughts on expanding this to SIGHASH_NONE? Perhaps someone
else on the dev list can enlighten me, but is there a current use case for
SIGHASH_NONE that would suffer from it being non standard?
-Chris
On Thu, May 31, 2018 at 1:53 PM, Johnson Lau via bitcoin-dev <
bitcoin-dev@lists•linuxfoundation.org> wrote:
> I’ve made a PR to add a new policy to disallow using SIGHASH_SINGLE
> without matched output:
>
> https://github.com/bitcoin/bitcoin/pull/13360
>
> Signature of this form is insecure, as it commits to no output while users
> might think it commits to one. It is even worse in non-segwit scripts,
> which is effectively SIGHASH_NOINPUT|SIGHASH_NONE, so any UTXO of the same
> key could be stolen. (It’s restricted to only one UTXO in segwit, but it’s
> still like a SIGHASH_NONE.)
>
> This is one of the earliest unintended consensus behavior. Since these
> signatures are inherently unsafe, I think it does no harm to disable this
> unintended “feature” with a softfork. But since these signatures are
> currently allowed, the first step is to make them non-standard.
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists•linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
[-- Attachment #2: Type: text/html, Size: 1952 bytes --]
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [bitcoin-dev] Disallow insecure use of SIGHASH_SINGLE
2018-06-06 0:17 ` Chris Stewart
@ 2018-06-06 0:43 ` Peter Todd
0 siblings, 0 replies; 4+ messages in thread
From: Peter Todd @ 2018-06-06 0:43 UTC (permalink / raw)
To: Chris Stewart, Bitcoin Protocol Discussion
[-- Attachment #1: Type: text/plain, Size: 571 bytes --]
On Tue, Jun 05, 2018 at 07:17:52PM -0500, Chris Stewart via bitcoin-dev wrote:
> Do you have any thoughts on expanding this to SIGHASH_NONE? Perhaps someone
> else on the dev list can enlighten me, but is there a current use case for
> SIGHASH_NONE that would suffer from it being non standard?
SIGHASH_NONE is important as it's the only way that a multisig signers can
relinquish the need for them to sign without giving up the private key.
FWIW the SIGHASH_SINGLE bug can be used in similar ways too.
--
https://petertodd.org 'peter'[:-1]@petertodd.org
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [bitcoin-dev] Disallow insecure use of SIGHASH_SINGLE
2018-05-31 18:53 [bitcoin-dev] Disallow insecure use of SIGHASH_SINGLE Johnson Lau
2018-06-06 0:17 ` Chris Stewart
@ 2018-06-06 0:49 ` Peter Todd
1 sibling, 0 replies; 4+ messages in thread
From: Peter Todd @ 2018-06-06 0:49 UTC (permalink / raw)
To: Johnson Lau, Bitcoin Protocol Discussion
[-- Attachment #1: Type: text/plain, Size: 1290 bytes --]
On Fri, Jun 01, 2018 at 02:53:01AM +0800, Johnson Lau via bitcoin-dev wrote:
> I’ve made a PR to add a new policy to disallow using SIGHASH_SINGLE without matched output:
>
> https://github.com/bitcoin/bitcoin/pull/13360
>
> Signature of this form is insecure, as it commits to no output while users might think it commits to one. It is even worse in non-segwit scripts, which is effectively SIGHASH_NOINPUT|SIGHASH_NONE, so any UTXO of the same key could be stolen. (It’s restricted to only one UTXO in segwit, but it’s still like a SIGHASH_NONE.)
>
> This is one of the earliest unintended consensus behavior. Since these signatures are inherently unsafe, I think it does no harm to disable this unintended “feature” with a softfork. But since these signatures are currently allowed, the first step is to make them non-standard.
I don't see why we should bother to soft fork this out on the basis of
security, given that there are many other ways to insecurely use private keys
(e.g. reused nonces). Maybe soft-fork it out on the basis of code complexity,
but this sounds like a lot of work.
Also, I have to wonder if it's just as likely the devs might think the
non-standardness means it is secure.
--
https://petertodd.org 'peter'[:-1]@petertodd.org
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2018-06-06 0:49 UTC | newest]
Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2018-05-31 18:53 [bitcoin-dev] Disallow insecure use of SIGHASH_SINGLE Johnson Lau
2018-06-06 0:17 ` Chris Stewart
2018-06-06 0:43 ` Peter Todd
2018-06-06 0:49 ` Peter Todd
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox