MIME-Version: 1.0
In-Reply-To: <3326159.7vNQY8OkXt@strawberry>
References: <CAPg+sBjdyJ297-GZvVc-wQwCEX-cRAGTNWDd92SgVzdCcD_ZMw@mail.gmail.com>
	<2034434.4WpKWoeOrB@strawberry> <5803D698.2080102@mattcorallo.com>
	<3326159.7vNQY8OkXt@strawberry>
From: Btc Drak <btcdrak@gmail.com>
Date: Mon, 17 Oct 2016 14:13:25 +0100
Message-ID: <CADJgMzu_0_W5X_+00Rfx=LC88nGcc4Qn9yGU7GEMKic_Sob1LA@mail.gmail.com>
To: Tom Zander <tomz@freedommail.ch>, 
	Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary=001a114f17807f2f00053f0f58cd
Subject: Re: [bitcoin-dev] (no subject)
Precedence: list

--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

<div dir=3D"ltr">For continuity, Matt took the discussion to the bitcoin-di=
scuss lists here=C2=A0<a href=3D"https://lists.linuxfoundation.org/pipermai=
l/bitcoin-discuss/2016-October/000104.html">https://lists.linuxfoundation.o=
rg/pipermail/bitcoin-discuss/2016-October/000104.html</a></div><div class=
=3D"gmail_extra"><br><div class=3D"gmail_quote">On Sun, Oct 16, 2016 at 9:4=
5 PM, Tom Zander via bitcoin-dev <span dir=3D"ltr">&lt;<a href=3D"mailto:bi=
tcoin-dev@lists.linuxfoundation.org" target=3D"_blank">bitcoin-dev@lists.li=
nuxfoundation.org</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote=
" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><=
span class=3D"">On Sunday, 16 October 2016 19:35:52 CEST Matt Corallo wrote=
:<br>
&gt; You keep calling flexible transactions &quot;safer&quot;, and yet you =
haven&#39;t<br>
&gt; mentioned that the current codebase is riddled with blatant and massiv=
e<br>
&gt; security holes.<br>
<br>
</span>I am not afraid of people finding issues with my code, I&#39;m only =
human. Would<br>
appreciate you reporting actual issues instead of hinting at things here.<b=
r>
Can&#39;t fix things otherwise :)<br>
<br>
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<br>
on Bitcoin later will need to know about them in order to do proper<br>
development.<br>
I counted 10 in my latest vlog entry.=C2=A0 FT only changes 2.<br>
<br>
Its safer because its simpler.<br>
<span class=3D""><br>
&gt; For example, you seem to have misunderstood C++&#39;s memory<br>
&gt; model - you would have no less than three out-of-bound, probably<br>
&gt; exploitable memory accesses in your 80-LoC deserialize method at<br>
&gt; <a href=3D"https://github.com/bitcoinclassic/bitcoinclassic/blob/devel=
op/src/primitiv" rel=3D"noreferrer" target=3D"_blank">https://github.com/<w=
br>bitcoinclassic/bitcoinclassic/<wbr>blob/develop/src/primitiv</a><br>
</span>&gt; es/transaction.cpp#L119 if you were to turn on flexible transac=
tions (and<br>
<span class=3D"">&gt; I only reviewed that method for 2 minutes).<br>
<br>
</span>The unit test doesn&#39;t hit any of them. Valgrind only reports suc=
h possibly<br>
exploitable issues in secp256k and CKey::MakeNewKey. The same as in Core.<b=
r>
<br>
I don&#39;t doubt that your 2 minute look shows stuff that others missed, a=
nd<br>
that valgrind doesn&#39;t find either, but I&#39;d be really grateful if yo=
u can<br>
report them specifically to me in an email off list (or github, you know th=
e<br>
drill).<br>
More feedback will only help to make the proposal stronger and even better.=
<br>
Thanks!<br>
<span class=3D""><br>
&gt; If you want to propose an<br>
&gt; alternative to a community which has been in desperate need of fixes t=
o<br>
&gt; many problems for several years, please do so with something which wou=
ld<br>
&gt; not take at least a year to complete given a large team of qualified<b=
r>
&gt; developers.<br>
<br>
</span>I think FT fits the bill just fine :)=C2=A0 After your 2 minute look=
, take a bit<br>
longer and check the rest of the code. You may be surprised with the<br>
simplicity of the approach.<br>
<span class=3D"HOEnZb"><font color=3D"#888888">--<br>
Tom Zander<br>
Blog: <a href=3D"https://zander.github.io" rel=3D"noreferrer" target=3D"_bl=
ank">https://zander.github.io</a><br>
Vlog: <a href=3D"https://vimeo.com/channels/tomscryptochannel" rel=3D"noref=
errer" target=3D"_blank">https://vimeo.com/channels/<wbr>tomscryptochannel<=
/a><br>
</font></span><div class=3D"HOEnZb"><div class=3D"h5">_____________________=
_________<wbr>_________________<br>
bitcoin-dev mailing list<br>
<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@lists.=
<wbr>linuxfoundation.org</a><br>
<a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" =
rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation.<wbr>org=
/mailman/listinfo/bitcoin-<wbr>dev</a><br>
</div></div></blockquote></div><br></div>

--001a114f17807f2f00053f0f58cd--