Re: [Bitcoin-development] [softfork proposal] Strict DER signatures
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 https://github.com/sipa/bitcoin/commit/041f1e3597812c250ebedbd8f4ef1565591d2c34 I've lately been updating the BIP text without updating the code in the repository; I've synced them now. The sigsize=0 case was actually already handled elsewhere already, so I removed the code and added a comment about it now in the BIP text. * Does this mean there are still multiple ways to encode a correctly encoded but invalid signature, one of which is the 0-length string? Would it make sense for this change to also treat any *other* correctly-encoded-but-invalid sig (besides the 0-length string) as incorrectly-encoded? Did I just step in some BIP62? You didn't miss anything; that's correct. In fact, Peter Todd already pointed out the possibility of making non-empty invalid signatures illegal. The reason for not doing it yet is that I'd like this BIP to be minimal and uncontroversial - it's a real problem we want to fix as fast as is reasonable. It wouldn't be hard to make this a standardness rule though, and perhaps later softfork it in as consensus rule if there was sufficient agreement about it. * It would be good to verify that all the branches of the new IsDERSignature() from https://github.com/sipa/bitcoin/commit/0c427135151a6bed657438ffb2e670be84eb3642 are tested by the test vectors in https://github.com/sipa/bitcoin/commit/f94e806f8bfa007a3de4b45fa3c9860f2747e427 . Eyeballing it, there are about 20 branches touched by the patch, and about 24 new test vectors. A significiant part of DERSIG behaviour (which didn't change, only the cases in which it is enforced) was already tested, in fact. Some branches remained untested however; I've added extra test cases in the repository. They give 100% coverage for IsValidSignatureEncoding (the new name for IsDERSignature) now (tested with gcov). * It would be good to finish the TODOs in https://github.com/sipa/bitcoin/commit/b7986119a5d41337fea1e83804ed6223438158ec so that it was actually testing the upgrade behavior. I agree, but that requires very significant changes to the codebase, as we currently have no way to mine blocks with non-acceptable transactions. Ideally, the RPC tests gain some means of building/mining blocks from without the Python test framework. Things like that would make the code changes also hard to backport, which we definitely will need to do to roll this out quickly. * missing comment: https://github.com/sipa/bitcoin/commit/e186f6a80161f9fa45fbced82ab1d22f081b942c#commitcomment-9406643 Fixed. Okay, that's all I've got. Hope it helps! Thanks again for your good work! Thanks! -- Pieter -- New Year. New Location. New Benefits. New Data Center in Ashburn, VA. GigeNET is offering a free month of service with a new server in Ashburn. Choose from 2 high performing configs, both with 100TB of bandwidth. Higher redundancy.Lower latency.Increased capacity.Completely compliant. http://p.sf.net/sfu/gigenet ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] BIP70: why Google Protocol Buffers for encoding?
That was essentially what we did in the end, we replaced the network identifier (main/test) with the genesis block hash. The result is never going to accidentally work with Bitcoin Core (nor vice-versa), but is readily extensible to any other altcoins that want to use the specification without requiring any sort of central registry. Ross On 24/01/15 13:19, Isidor Zeuner wrote: For what it's worth, there was consideration of replacing protocol buffers when modifying BIP70 to function with the altcoin I work on (changes were required anyway in eliminate any risk that payment requests could not be accidentally applied to the wrong blockchain). Why not serialize some kind of blockchain identifier with the messages? Arbitrarily deviating from a given design choice just for the sake of doing it differently may serve the goal of creating more overall code diversity, but would not necessarily serve the quality of the blockchain network where it is done for. Best regards, Isidor -- New Year. New Location. New Benefits. New Data Center in Ashburn, VA. GigeNET is offering a free month of service with a new server in Ashburn. Choose from 2 high performing configs, both with 100TB of bandwidth. Higher redundancy.Lower latency.Increased capacity.Completely compliant. http://p.sf.net/sfu/gigenet ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] [softfork proposal] Strict DER signatures
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 request a BIP number for this. -- Pieter -- Dive into the World of Parallel Programming. The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net/ ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] [softfork proposal] Strict DER signatures
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 function is used for consensus. Let me clarify. This function was originally written for Bitcoin Core v0.8.0, where it was only used to enforce non-standardness, not consensus. In that setting, there was no need to require a maximum length for the R and S arguments, as overly-long R or S values (which, because of a further rule, do not have excessive padding) will always result in integers = 2^256, which means the encoded signature would never be valid according to the ECDSA specification. A restriction on the total length is required however, as BER allows multi-byte length descriptors, which this function cannot (and shouldn't, as it's not DER) parse. However, in the currently proposed soft fork, non-DER results in immediate script failure, which is distinguishable from invalid signatures (by negating the result of a CHECKSIG, for example using a NOT after it). I must admit that having invalid signatures with overly-long R or S but acceptable R+S size be distinguishable from invalid signatures where R+S is too large is ugly, and unnecessary. Adding individual R and S length restrictions (ideally: saying that no more than 32 bytes, excluding the padding 0 byte in front, is invalid) would be trivial, but it means deviating slightly from the standardness rule implementation that has been deployed for a while. There should not really be much risk in doing so, as there are still no node implementation releases (apart from the v0.10.0 rc's) that would mine a CHECKSIG whose result is negated. So, I think there are two options: * Just add this R/S length restriction rule as a standardness requirement, but not make it part of the soft fork. A later softfork can then add this easily. The same can be done for several other changes if they are deemed useful, like only allowing 0 (the empty array) as invalid signature (any other causes failure script immediately), requiring correct encoding even for non-evaluated signatures, ... * Add it to the softfork now, and be done with it. Opinions? -- Pieter -- New Year. New Location. New Benefits. New Data Center in Ashburn, VA. GigeNET is offering a free month of service with a new server in Ashburn. Choose from 2 high performing configs, both with 100TB of bandwidth. Higher redundancy.Lower latency.Increased capacity.Completely compliant. http://p.sf.net/sfu/gigenet ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
