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 >
_______________________________________________ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
