[prev in list] [next in list] [prev in thread] [next in thread] 

List:       bitcoin-dev
Subject:    [bitcoin-dev] (no subject)
From:       btcdrak () gmail ! com (Btc Drak)
Date:       2016-10-17 13:13:25
Message-ID: CADJgMzu_0_W5X_+00Rfx=LC88nGcc4Qn9yGU7GEMKic_Sob1LA () mail ! gmail ! com
[Download RAW message or body]

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 at 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 at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
> 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20161017/5149957c/attachment.html>



[prev in list] [next in list] [prev in thread] [next in thread]