On Mon, Jan 26, 2015 at 10:35 AM, Gregory Maxwell gmaxw...@gmail.com 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
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 laa...@gmail.com 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
right now, which is a one-line change that's obviously
On Tue, Feb 3, 2015 at 4:00 AM, Wladimir laa...@gmail.com 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
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 pieter.wui...@gmail.com
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
+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 gavinandre...@gmail.com
wrote:
I think we should just do it, and include it with the other DERSIG changes
for 0.10.
On
On Tue, Feb 3, 2015 at 10:15 AM, Pieter Wuille pieter.wui...@gmail.com 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.
On Sun, Jan 25, 2015 at 6:48 AM, Gregory Maxwell gmaxw...@gmail.com 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
On Tue, Feb 3, 2015 at 12:44 AM, Pieter Wuille pieter.wui...@gmail.com 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 Mon, 26 Jan 2015, Gregory Maxwell wrote:
On Mon, Jan 26, 2015 at 5:14 AM, Pieter Wuille pieter.wui...@gmail.com
wrote:
On Tue, Jan 20, 2015 at 8:35 PM, Pieter Wuille pieter.wui...@gmail.com
wrote:
I therefore propose a softfork to make non-DER signatures illegal
(they've been
On Mon, Jan 26, 2015 at 5:14 AM, Pieter Wuille pieter.wui...@gmail.com wrote:
On Tue, Jan 20, 2015 at 8:35 PM, Pieter Wuille pieter.wui...@gmail.com
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
On Thu, Jan 22, 2015 at 6:41 PM, Zooko Wilcox-OHearn
zo...@leastauthority.com 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
On Tue, Jan 20, 2015 at 8:35 PM, Pieter Wuille pieter.wui...@gmail.com 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
On Wed, Jan 21, 2015 at 8:32 PM, Rusty Russell ru...@rustcorp.com.au 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
.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
-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 11:45 PM, Rusty Russell ru...@rustcorp.com.au 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
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
-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.
On Wed, Jan 21, 2015 at 3:37 PM, Gavin Andresen gavinandre...@gmail.com 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
-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 d...@bitcoinarmory.com 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
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
Pieter Wuille pieter.wui...@gmail.com 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
To be more in the C++ spirit, I would suggest changing the (const
std::vectorunsigned char sig, size_t off) parameters to
(std::vectorunsigned char::const_iterator itr, std::vectorunsigned
char::const_iterator end).
Example:
bool ConsumeNumber(std::vectorunsigned char::const_iterator itr,
Seems like a good change to me.
On Wed, Jan 21, 2015 at 7:32 PM, Rusty Russell ru...@rustcorp.com.au
wrote:
Pieter Wuille pieter.wui...@gmail.com 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
On Wed, Jan 21, 2015 at 11:18 PM, Matt Whitlock b...@mattwhitlock.name wrote:
To be more in the C++ spirit, I would suggest changing the (const
std::vectorunsigned char sig, size_t off) parameters to
(std::vectorunsigned char::const_iterator itr, std::vectorunsigned
char::const_iterator
Pieter Wuille pieter.wui...@gmail.com 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
29 matches
Mail list logo
