Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id CA546959 for ; Mon, 17 Oct 2016 13:13:46 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-yw0-f176.google.com (mail-yw0-f176.google.com [209.85.161.176]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 0A150126 for ; Mon, 17 Oct 2016 13:13:46 +0000 (UTC) Received: by mail-yw0-f176.google.com with SMTP id t192so115151830ywf.0 for ; Mon, 17 Oct 2016 06:13:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=/N7W9kCiZTHqMHNK/PZKCQe+C9kjfTI8hJHvNMPqPjU=; b=d60XG2ZaJlXFH337wtktVXRtt1hwZ3GT1YDxDg2jvMdE/tRWCArNI4wioSYwl5yHuZ fArAcisOfQvx9KaTsyHQQGvFuK7CssOPkUVFxbSKRD1rUPWZlcrf0zl10l9CZab8VMCY zMxPwtHK6mS0YON76fRqgbuW0Vw5+UAZ7/OC+DOHQBXhZ4Olh81rtqOQkuoL3W0AkDMH nexdXjCrnEWL3AyoUOK8+6IOfmtqnxQ3e+DhIiVFxqb1ysFdLDFuaWgVzbQLoioXMQdN XU9RMmIn4act2dNZtufjPwht71BcSDrR4RDrm+lUaosHm5O2EA7KZmcVrwhFdd9unuGW BuHw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=/N7W9kCiZTHqMHNK/PZKCQe+C9kjfTI8hJHvNMPqPjU=; b=fb5qdYKkB4DyVstsKUtZ9fRrKwGI5Kj8bFkwwPzvumNBbEia3ExjpBiswy+z2V3qsx tfxuusRga31/TFDFqjGZoE+RJANEces9WjGKj3AWFFmsQS73u0cLE8DvM4wROBhQdGDA yyo1lD3pSOUKmRoMbBEOL67HiYBAvmTJZIEhvv2neJS+tZpZskNsBMVoPO+TXZNC2LrY G4OuXgLj2zmi7qcIifFQiQgg0dH4ITZ/JFSZRaLGciYhvXwSr/uUouqhhSxz6R1Nb5wH VsJchNbuitP6gAo6MjAZowv2RSjsVu9HITdovnSUDuo9Ars/jH/HKB8tZn7UbRIe+P5L w0DQ== X-Gm-Message-State: AA6/9RlyxbyQAdup2RXVUJQC66/eczBoGsb6QwMGgkMnGMGVc9iHWDd/ioLKrXE7a5FkBU6rcpq1N61jvOymbA== X-Received: by 10.13.202.79 with SMTP id m76mr22712722ywd.251.1476710025339; Mon, 17 Oct 2016 06:13:45 -0700 (PDT) MIME-Version: 1.0 Received: by 10.129.167.74 with HTTP; Mon, 17 Oct 2016 06:13:25 -0700 (PDT) In-Reply-To: <3326159.7vNQY8OkXt@strawberry> References: <2034434.4WpKWoeOrB@strawberry> <5803D698.2080102@mattcorallo.com> <3326159.7vNQY8OkXt@strawberry> From: Btc Drak Date: Mon, 17 Oct 2016 14:13:25 +0100 Message-ID: To: Tom Zander , Bitcoin Protocol Discussion Content-Type: multipart/alternative; boundary=001a114f17807f2f00053f0f58cd X-Spam-Status: No, score=-2.0 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, FREEMAIL_FROM, HK_RANDOM_ENVFROM, HTML_MESSAGE, RCVD_IN_DNSWL_NONE autolearn=no version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on smtp1.linux-foundation.org X-Mailman-Approved-At: Mon, 17 Oct 2016 13:15:47 +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: Mon, 17 Oct 2016 13:13:46 -0000 --001a114f17807f2f00053f0f58cd Content-Type: text/plain; charset=UTF-8 For continuity, Matt took the discussion to the bitcoin-discuss lists here https://lists.linuxfoundation.org/pipermail/bitcoin-discuss/2016-October/000104.html On Sun, Oct 16, 2016 at 9:45 PM, Tom Zander via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > 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 > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > --001a114f17807f2f00053f0f58cd Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
For continuity, Matt took the discussion to the bitcoin-di= scuss lists here=C2=A0https://lists.linuxfoundation.o= rg/pipermail/bitcoin-discuss/2016-October/000104.html

On Sun, Oct 16, 2016 at 9:4= 5 PM, Tom Zander via bitcoin-dev <bitcoin-dev@lists.li= nuxfoundation.org> wrote:
<= span class=3D"">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 massiv= e
> 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<= br> amount of conceps that SegWit changes in a way that anyone doing developmen= t
on Bitcoin later will need to know about them in order to do proper
development.
I counted 10 in my latest vlog entry.=C2=A0 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 transac= tions (and
> I only reviewed that method for 2 minutes).

The unit test doesn't hit any of them. Valgrind only reports suc= h 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, a= nd
that valgrind doesn't find either, but I'd be really grateful if yo= u can
report them specifically to me in an email off list (or github, you know th= e
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 t= o
> many problems for several years, please do so with something which wou= ld
> not take at least a year to complete given a large team of qualified > developers.

I think FT fits the bill just fine :)=C2=A0 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<= /a>

--001a114f17807f2f00053f0f58cd--