From: Tom Zander <tomz@freedommail.ch>
To: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Date: Sun, 16 Oct 2016 22:45:19 +0200
Message-ID: <3326159.7vNQY8OkXt@strawberry>
In-Reply-To: <5803D698.2080102@mattcorallo.com>
References: <CAPg+sBjdyJ297-GZvVc-wQwCEX-cRAGTNWDd92SgVzdCcD_ZMw@mail.gmail.com>
	<2034434.4WpKWoeOrB@strawberry> <5803D698.2080102@mattcorallo.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 7Bit
Content-Type: text/plain; charset="us-ascii"
Subject: Re: [bitcoin-dev] (no subject)
Precedence: list

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