On Fri, Sep 12, 2014 at 6:35 PM, Pieter Wuille wrote:
> Changes: https://github.com/bitcoin/bips/pull/102/files
>
> Gregory, Jeff: does this address your concerns?
> Others: comments?
I've made another change in the PR, as language about strictly only
compressed or uncompressed public keys was mi
On Mon, Sep 8, 2014 at 1:31 AM, Pieter Wuille wrote:
> I've sent out a new pull request
> (https://github.com/bitcoin/bips/pull/102/files) that:
> * Changes the order of the rules.
> * Adds more reference documentation about minimal pushes and number encodings.
> * Clarified that extra consensus r
On Wed, Sep 3, 2014 at 6:34 PM, Pieter Wuille wrote:
> On Mon, Sep 1, 2014 at 10:48 PM, Gregory Maxwell wrote:
>> Not related to this change but the definition of rule 4 may not be
>> sufficiently specific-- without a definition someone could reasonably
>> reach a different conclusion about OP_1N
On Mon, Sep 1, 2014 at 10:48 PM, Gregory Maxwell wrote:
> Not related to this change but the definition of rule 4 may not be
> sufficiently specific-- without a definition someone could reasonably
> reach a different conclusion about OP_1NEGATE being a "push
> operation", or might even decide any
On Fri, Jul 18, 2014 at 8:14 AM, Pieter Wuille wrote:
> Hi all,
>
> I've sent a pull request to make a small change to BIP 62 (my
> anti-malleability proposal) which is still a draft; see:
> * https://github.com/bitcoin/bips/pull/90 (the request)
> * https://github.com/sipa/bips/blob/bip62up/bip-0
Thanks g.maxwell, your explanation of *why* you can't just generate k
in a way that the verifier can duplicate is really helpful. This also
servers as a great illustration why engineers should never try to
designing their own crypto protocols! I knew enough to know not try
that at least.
Aaron Voi
On Jul 18, 2014 4:56 PM, "Wladimir" wrote:
>
> On Fri, Jul 18, 2014 at 5:39 PM, Mike Hearn wrote:
> > The rationale doesn't seem to apply to rule #4, what's so special about
that
> > one?
>
> > 4. Non-push operations in scriptSig Any non-push operation in a
scriptSig invalidates it.
>
> Having no
Ah, good point. For some reason I was thinking the k value was
generated only from the hash being signed, but it's derived from both
the private key and the hash, so as you say there's no way for the
verifier to tell if the scheme is being followed.
Aaron Voisine
breadwallet.com
On Fri, Jul 18
On Fri, Jul 18, 2014 at 9:38 PM, Aaron Voisine wrote:
> Well, you could always create a transaction with a different signature
> hash, say, by changing something trivial like nLockTime, or changing
> the order of inputs or outputs. Is that what you're talking about? Or
> is there some sophistry I'
Well, you could always create a transaction with a different signature
hash, say, by changing something trivial like nLockTime, or changing
the order of inputs or outputs. Is that what you're talking about? Or
is there some sophistry I'm ignorant of having to do with the elliptic
curve math in the
On Fri, Jul 18, 2014 at 3:03 PM, Aaron Voisine wrote:
>> 9. New signatures by the sender
>
> I'm not suggesting it be required, but it would be possible to
> mitigate this one by requiring that all signatures deterministically
> generate k per RFC6979. I'm using this in breadwallet.
Nope.
Your h
> 9. New signatures by the sender
I'm not suggesting it be required, but it would be possible to
mitigate this one by requiring that all signatures deterministically
generate k per RFC6979. I'm using this in breadwallet.
Aaron Voisine
breadwallet.com
On Fri, Jul 18, 2014 at 1:56 PM, Wladimir w
On Fri, Jul 18, 2014 at 5:39 PM, Mike Hearn wrote:
> The rationale doesn't seem to apply to rule #4, what's so special about that
> one?
> 4. Non-push operations in scriptSig Any non-push operation in a scriptSig
> invalidates it.
Having non-push operations in the scriptSig is a source of
malle
On Fri, Jul 18, 2014 at 5:14 PM, Pieter Wuille wrote:
> Hi all,
>
> I've sent a pull request to make a small change to BIP 62 (my
> anti-malleability proposal) which is still a draft; see:
> * https://github.com/bitcoin/bips/pull/90 (the request)
> * https://github.com/sipa/bips/blob/bip62up/bip-0
On Fri, Jul 18, 2014 at 7:25 PM, Pieter Wuille wrote:
> On Fri, Jul 18, 2014 at 5:45 PM, Pieter Wuille
> wrote:
>> But perhaps we should investigate how many non-DER signatures still
>> make it into blocks first...
>
> In the last 11 blocks (4148 transactions), apparently none.
Or even in the l
On Fri, Jul 18, 2014 at 5:45 PM, Pieter Wuille wrote:
> But perhaps we should investigate how many non-DER signatures still
> make it into blocks first...
In the last 11 blocks (4148 transactions), apparently none.
--
Pieter
-
On Fri, Jul 18, 2014 at 5:39 PM, Mike Hearn wrote:
> The rationale doesn't seem to apply to rule #4, what's so special about that
> one?
Nothing really. If it's controversial in any way, I'm fine with
changing that. It's just one those things that nobody needs, nobody
uses, has never been standar
The rationale doesn't seem to apply to rule #4, what's so special about
that one?
Although I agree not having to support all of DER is nice, in practice I
think all implementations do and libraries to parse DER are widespread.
Given that the last time we modified tx rules without bumping version
n
Hi all,
I've sent a pull request to make a small change to BIP 62 (my
anti-malleability proposal) which is still a draft; see:
* https://github.com/bitcoin/bips/pull/90 (the request)
* https://github.com/sipa/bips/blob/bip62up/bip-0062.mediawiki (the result)
It makes two of the 7 new rules mandat
19 matches
Mail list logo
