On Tue, Oct 14, 2014 at 11:54:36AM -0700, Pieter Wuille wrote:
> > 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 tran
To be clear: I indeed meant to only allow 0 and 1 as booleans (or,
more precisely: [] and [0x01]). Evaluating any stack element as a
boolean that is not any of these would result in script failure.
The only places where this is relevant:
* Inputs to OP_IF and OP_NOTIF (which are currently allowed
FYI:
"In order to progress towards exit to Last Call for the Web Crypto API, the
chair suggests the following resolution for that bug.
resolution : Bug CLOSED. This problem will be addressed by the extension bug
25618 https://www.w3.org/Bugs/Public/show_bug.cgi?id=25618.
If none objects before t
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
On Tue, Oct 14, 2014 at 9:27 AM, Thomas Zander 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
On Tue, Oct 14, 2014 at 7:27 AM, Thomas Zander 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
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 (m
7 matches
Mail list logo
