Tom Zander [ARCHIVE] on Nostr: 📅 Original date posted:2016-10-16 📝 Original message:On Sunday, 16 October 2016 ...
📅 Original date posted:2016-10-16
📝 Original message: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
📝 Original message: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