Re: [Bitcoin-development] Malleable booleans
On Tuesday 14. October 2014 04.34.16 Pieter Wuille wrote: This means that scripts that use booleans as inputs will be inherently malleable. I've ran into this issue in C++ often enough, a funny example is assigning 2 to a native c++ bool and then you can do a if (myBool == true) else if (myBool == false) and neither of them will hit. I would like to change BIP62 to also state that interpreted booleans must be of minimal encoded size (in addition to numbers). What about rejecting a script where a bool is not explicitly zero or one? -- Thomas Zander -- Comprehensive Server Monitoring with Site24x7. Monitor 10 servers for $9/Month. Get alerted through email, SMS, voice calls or mobile push notifications. Take corrective actions from your mobile device. http://p.sf.net/sfu/Zoho ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Malleable booleans
On Tue, Oct 14, 2014 at 7:27 AM, Thomas Zander tho...@thomaszander.se wrote: What about rejecting a script where a bool is not explicitly zero or one? I believe this is what he actually meant. -- Comprehensive Server Monitoring with Site24x7. Monitor 10 servers for $9/Month. Get alerted through email, SMS, voice calls or mobile push notifications. Take corrective actions from your mobile device. http://p.sf.net/sfu/Zoho ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Malleable booleans
On Tue, Oct 14, 2014 at 9:27 AM, Thomas Zander tho...@thomaszander.se wrote:
On Tuesday 14. October 2014 04.34.16 Pieter Wuille wrote:
This means that scripts that use booleans as inputs will be inherently
malleable.
I've ran into this issue in C++ often enough,
a funny example is assigning 2 to a native c++ bool and then you can do a
if (myBool == true)
else if (myBool == false)
and neither of them will hit.
Off topic nit: I think you're confused with custom BOOL typedefs in C?
C++ booleans are protected against this (C++ standard ยง4.7/4 according
to Google).:
```
#include stdio.h
int main()
{
bool myBool;
myBool = 2;
if (myBool == true)
printf(It is true!\n);
else if (myBool == false)
printf(It is false!\n);
else
printf(It is something else!\n);
}
```
Prints 'It is true'. You can also use bool(something) as equivalent of
`x != 0`; as in `assert(bool(2) == true);`.
Wladimir
--
Comprehensive Server Monitoring with Site24x7.
Monitor 10 servers for $9/Month.
Get alerted through email, SMS, voice calls or mobile push notifications.
Take corrective actions from your mobile device.
http://p.sf.net/sfu/Zoho
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Malleable booleans
On Mon, Oct 13, 2014 at 07:34:16PM -0700, Pieter Wuille wrote: Hi all, while working on a BIP62 implementation I discovered yet another type of malleability: the interpretation of booleans. Any byte array with non-zero bytes in it (ignoring the highest bit of the last byte, which is the sign bit when interpreting as a number) is interpreted as true, anything else as false. Other than numbers, they're not even restricted to 4 bytes. Worse, the code for dealing with booleans is not very consistent: OP_BOOLAND and OP_BOOLOR first interpret their arguments as numbers, and then compare them to 0 to turn them into boolean values. This means that scripts that use booleans as inputs will be inherently malleable. Given that that seems actually useful (passing in booleans to guide some OP_IF's during execution of several alternatives), I would like to change BIP62 to also state that interpreted booleans must be of minimal encoded size (in addition to numbers). Any opinions for or against? I noticed this awhile back myself. More interestingly, I remember noticing some non-std scripts on mainnet that had opcodes that appeared to be attempts to solve this issue with variations of the following: DUP IF 1 EQUALVERIFY do stuff ELSE 0 EQUALVERIFY do stuff ENDIF I'll have to admit, I decided to keep quiet about it because it's a good example of how relying on BIP62 for specialty contract applications that absolutely need to avoid malleability for security reasons is a dubious idea; it's hard to be sure that we've really gotten every relevant case correct. I think a decent argument *for* doing this is that if a script author fails to properly 'bool-ize' every boolean-using path that can have non-minimal encodings in normal execution, you can always create a nVersion=1 transaction manually to spend the output, preventing funds from getting lost. Meanwhile in the general case of a compenent script author having the canonical bool testing in every boolean-using opcode saves a lot of bytes. -- 'peter'[:-1]@petertodd.org 147fe2005d7d4490938a7ab96901b8256dcd9d4eac78cb8c signature.asc Description: Digital signature -- Comprehensive Server Monitoring with Site24x7. Monitor 10 servers for $9/Month. Get alerted through email, SMS, voice calls or mobile push notifications. Take corrective actions from your mobile device. http://p.sf.net/sfu/Zoho___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
