From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id 2780DA81 for ; Sun, 16 Oct 2016 20:45:24 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 Received: from mx-out03.mykolab.com (mx.kolabnow.com [95.128.36.1]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 64957E3 for ; Sun, 16 Oct 2016 20:45:23 +0000 (UTC) X-Virus-Scanned: amavisd-new at kolabnow.com X-Spam-Score: -2.9 X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_LOW autolearn=ham version=3.3.1 Received: from mx05.mykolab.com (mx05.mykolab.com [10.20.7.161]) by mx-out03.mykolab.com (Postfix) with ESMTPS id C614122D2F for ; Sun, 16 Oct 2016 22:45:20 +0200 (CEST) From: Tom Zander To: Bitcoin Protocol Discussion Date: Sun, 16 Oct 2016 22:45:19 +0200 Message-ID: <3326159.7vNQY8OkXt@strawberry> In-Reply-To: <5803D698.2080102@mattcorallo.com> References: <2034434.4WpKWoeOrB@strawberry> <5803D698.2080102@mattcorallo.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on smtp1.linux-foundation.org X-Mailman-Approved-At: Sun, 16 Oct 2016 20:46:51 +0000 Subject: Re: [bitcoin-dev] (no subject) X-BeenThere: bitcoin-dev@lists.linuxfoundation.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Bitcoin Protocol Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 16 Oct 2016 20:45:24 -0000 On Sunday, 16 October 2016 19:35:52 CEST Matt Corallo wrote: > You keep calling flexible transactions "safer", and yet you haven't > mentioned that the current codebase is riddled with blatant and massive > security holes. I am not afraid of people finding issues with my code, I'm only human. Would appreciate you reporting actual issues instead of hinting at things here. Can't fix things otherwise :) But, glad you brought it up, the reason that FT is safer is because of the amount of conceps that SegWit changes in a way that anyone doing development on Bitcoin later will need to know about them in order to do proper development. I counted 10 in my latest vlog entry. FT only changes 2. Its safer because its simpler. > For example, you seem to have misunderstood C++'s memory > model - you would have no less than three out-of-bound, probably > exploitable memory accesses in your 80-LoC deserialize method at > https://github.com/bitcoinclassic/bitcoinclassic/blob/develop/src/primitiv > es/transaction.cpp#L119 if you were to turn on flexible transactions (and > I only reviewed that method for 2 minutes). The unit test doesn't hit any of them. Valgrind only reports such possibly exploitable issues in secp256k and CKey::MakeNewKey. The same as in Core. I don't doubt that your 2 minute look shows stuff that others missed, and that valgrind doesn't find either, but I'd be really grateful if you can report them specifically to me in an email off list (or github, you know the drill). More feedback will only help to make the proposal stronger and even better. Thanks! > If you want to propose an > alternative to a community which has been in desperate need of fixes to > many problems for several years, please do so with something which would > not take at least a year to complete given a large team of qualified > developers. I think FT fits the bill just fine :) After your 2 minute look, take a bit longer and check the rest of the code. You may be surprised with the simplicity of the approach. -- Tom Zander Blog: https://zander.github.io Vlog: https://vimeo.com/channels/tomscryptochannel