On Mon, Jan 26, 2015 at 10:35 AM, Gregory Maxwell wrote:
>> I'd like to request a BIP number for this.
>
> Sure. BIP0066.
Four implementations exist now:
* for master: https://github.com/bitcoin/bitcoin/pull/5713 (merged)
* for 0.10.0: https://github.com/bitcoin/bitcoin/pull/5714 (merged,
and inc
On Tue, Feb 3, 2015 at 10:15 AM, Pieter Wuille wrote:
>>> The much simpler alternative is just adding this to BIP66's DERSIG
>>> right now, which is a one-line change that's obviously softforking. Is
>>> anyone opposed to doing so at this stage?
I'm retracting this proposed change.
Suhar Daftuas
+1 I just ran an it-works test on #5743. Not exhaustive, but I do agree
it should be included w/ other DERSIG changes.
On Tue, Feb 3, 2015 at 1:19 PM, Gavin Andresen
wrote:
> I think we should just do it, and include it with the other DERSIG changes
> for 0.10.
>
> On Tue, Feb 3, 2015 at 1:1
I think we should just do it, and include it with the other DERSIG changes
for 0.10.
On Tue, Feb 3, 2015 at 1:15 PM, Pieter Wuille
wrote:
>
> I understand it's late, which is also why I ask for opinions. It's
> also not a priority, but if we release 0.10 without, it will first
> need a cycle of
On Tue, Feb 3, 2015 at 4:00 AM, Wladimir wrote:
>> One way to do that is to just - right now - add a patch to 0.10 to
>> make those non-standard. This requires another validation flag, with a
>> bunch of switching logic.
>>
>> The much simpler alternative is just adding this to BIP66's DERSIG
>> r
Could we see a PR that adds it to BIP 66? Perhaps we'd all agree quickly
that its so simple we can just add it...
In either case it doesn't seem strictly necessary to me that it was
non-standard before it becomes a soft-fork...
On Tue, Feb 3, 2015 at 7:00 AM, Wladimir wrote:
> > One way to do
> One way to do that is to just - right now - add a patch to 0.10 to
> make those non-standard. This requires another validation flag, with a
> bunch of switching logic.
>
> The much simpler alternative is just adding this to BIP66's DERSIG
> right now, which is a one-line change that's obviously s
On Tue, Feb 3, 2015 at 12:44 AM, Pieter Wuille wrote:
> The much simpler alternative is just adding this to BIP66's DERSIG
> right now, which is a one-line change that's obviously softforking. Is
> anyone opposed to doing so at this stage?
Thats my preference.
---
On Sun, Jan 25, 2015 at 6:48 AM, Gregory Maxwell wrote:
> So I think we should just go ahead with R/S length upper bounds as
> both IsStandard and in STRICTDER.
I would like to fix this at some point in any case.
If we want to do that, we must at least have signatures with too-long
R or S values
On Mon, 26 Jan 2015, Gregory Maxwell wrote:
> On Mon, Jan 26, 2015 at 5:14 AM, Pieter Wuille
> wrote:
>> On Tue, Jan 20, 2015 at 8:35 PM, Pieter Wuille
>> wrote:
>>> I therefore propose a softfork to make non-DER signatures illegal
>>> (they've been non-standard since v0.8.0). A draft BIP tex
On Mon, Jan 26, 2015 at 5:14 AM, Pieter Wuille wrote:
> On Tue, Jan 20, 2015 at 8:35 PM, Pieter Wuille
> wrote:
>> I therefore propose a softfork to make non-DER signatures illegal
>> (they've been non-standard since v0.8.0). A draft BIP text can be
>> found on:
>>
>> https://gist.github.com
On Tue, Jan 20, 2015 at 8:35 PM, Pieter Wuille wrote:
> I therefore propose a softfork to make non-DER signatures illegal
> (they've been non-standard since v0.8.0). A draft BIP text can be
> found on:
>
> https://gist.github.com/sipa/5d12c343746dad376c80
I'd like to request a BIP number for
On Thu, Jan 22, 2015 at 6:41 PM, Zooko Wilcox-OHearn
wrote:
> * Should the bipstrictder give a rationale or link to why accept the
> 0-length sig as correctly-encoded-but-invalid? I guess the rationale
> is an efficiency issue as described in the log entry for
> https://github.com/sipa/bitcoin/com
On Sun, Jan 25, 2015 at 2:34 PM, Pieter Wuille wrote:
> * Add it to the softfork now, and be done with it.
Initially I was of the opinion that we couldn't do that, because
soft-forks which hit transactions many nodes would relay+mine creates
a forking risk... but with the realization that imbalan
On Wed, Jan 21, 2015 at 8:32 PM, Rusty Russell wrote:
> One weirdness is the restriction on maximum total length, rather than a
> 32 byte (33 with 0-prepad) limit on signatures themselves.
Glad that you point this out; I believe that's a weakness with more
impact now that this function is used fo
.Hi there. Thank you for your work on this.
I've looked over https://gist.github.com/sipa/5d12c343746dad376c80 and
https://github.com/sipa/bitcoin/commit/bipstrictder . I didn't
actually audit the included reference implementation of
IsValidSignatureEncoding(), and I didn't check whether the test
On Wed, Jan 21, 2015 at 11:18 PM, Matt Whitlock wrote:
> To be more in the C++ spirit, I would suggest changing the (const
> std::vector &sig, size_t &off) parameters to
> (std::vector::const_iterator &itr, std::vector char>::const_iterator end).
I agree that is more in the spirit of C++, but p
To be more in the C++ spirit, I would suggest changing the (const
std::vector &sig, size_t &off) parameters to
(std::vector::const_iterator &itr, std::vector::const_iterator end).
Example:
bool ConsumeNumber(std::vector::const_iterator &itr,
std::vector::const_iterator end, unsigned int len)
{
Seems like a good change to me.
On Wed, Jan 21, 2015 at 7:32 PM, Rusty Russell
wrote:
> Pieter Wuille writes:
> > Hello everyone,
> >
> > We've been aware of the risk of depending on OpenSSL for consensus
> > rules for a while, and were trying to get rid of this as part of BIP
> > 62 (malleabil
Pieter Wuille writes:
> Hello everyone,
>
> We've been aware of the risk of depending on OpenSSL for consensus
> rules for a while, and were trying to get rid of this as part of BIP
> 62 (malleability protection), which was however postponed due to
> unforeseen complexities. The recent evens (see
I'm really glad to see this proposal. We already treat non-DER
signatures as non-standard in btcd and agree that extending them be
illegal as a part of a soft fork is a smart and sane thing to do.
It's also good to see the explicit use of signature parsing since it
matches what we already do as w
On Wed, Jan 21, 2015 at 3:37 PM, Gavin Andresen wrote:
> DERSIG BIP looks great to me, just a few nit-picky changes suggested:
>
> You mention the "DER standard" : should link to
> http://www.itu.int/ITU-T/studygroups/com17/languages/X.690-0207.pdf (or
> whatever is best reference for DER).
>
> "t
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
On 2015/1/21 15:30, Pieter Wuille wrote:
> Thanks for the comments. I hope I have clarified the text a bit
> accordingly.
You're welcome. All the revisions look good to me.
- ---
Douglas Roark
Senior Developer
Armory Technologies, Inc.
d...@bitcoi
I've read this and it looks A-OK to me.
Andrew
On Tue, Jan 20, 2015 at 07:35:49PM -0500, Pieter Wuille wrote:
> Hello everyone,
>
> We've been aware of the risk of depending on OpenSSL for consensus
> rules for a while, and were trying to get rid of this as part of BIP
> 62 (malleability prot
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
On 2015/1/21 15:37, Gavin Andresen wrote:
> You mention the "DER standard" : should link to
> http://www.itu.int/ITU-T/studygroups/com17/languages/X.690-0207.pdf
>
>
(or whatever is best reference for DER).
The link you gave is to the 2002 revision
DERSIG BIP looks great to me, just a few nit-picky changes suggested:
You mention the "DER standard" : should link to
http://www.itu.int/ITU-T/studygroups/com17/languages/X.690-0207.pdf (or
whatever is best reference for DER).
"this would simplify avoiding OpenSSL in consensus implementations" -
On Wed, Jan 21, 2015 at 2:29 PM, Douglas Roark wrote:
> Nice paper, Pieter. I do have a bit of feedback.
Thanks for the comments. I hope I have clarified the text a bit accordingly.
> 1)The first sentence of "Deployment" has a typo. "We reuse the
> double-threshold switchover mechanism from BIP
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
On 2015/1/20 19:35, Pieter Wuille wrote:> Hello everyone,
> Comments/criticisms are very welcome, but I'd prefer keeping the
> discussion here on the mailinglist (which is more accessible than
> on the gist).
Nice paper, Pieter. I do have a bit of
On Tue, Jan 20, 2015 at 07:35:49PM -0500, Pieter Wuille wrote:
I read this and it's boring, now that all my objections have been met. :)
I'll try get a chance to actually test/review this in detail; in SF for
the next three weeks with some ugly deadlines and a slow laptop. :(
> Hello everyone,
>
On Tue, Jan 20, 2015 at 11:45 PM, Rusty Russell wrote:
> // Null bytes at the start of R are not allowed, unless it would otherwise be
> // interpreted as a negative number.
> if (lenS > 1 && (sig[lenR + 6] == 0x00) && !(sig[lenR + 7] & 0x80))
> return false;
>
> You mean "null bytes at th
Pieter Wuille writes:
> Hello everyone,
>
> We've been aware of the risk of depending on OpenSSL for consensus
> rules for a while, and were trying to get rid of this as part of BIP
> 62 (malleability protection), which was however postponed due to
> unforeseen complexities. The recent evens (see
Hello everyone,
We've been aware of the risk of depending on OpenSSL for consensus
rules for a while, and were trying to get rid of this as part of BIP
62 (malleability protection), which was however postponed due to
unforeseen complexities. The recent evens (see the thread titled
"OpenSSL 1.0.0p
32 matches
Mail list logo
