Re: [bitcoin-dev] (no subject)
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
Re: [bitcoin-dev] (no subject)
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
Re: [bitcoin-dev] (no subject)
You keep calling flexible transactions "safer", and yet you haven't mentioned that the current codebase is riddled with blatant and massive security holes. 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/primitives/transaction.cpp#L119 if you were to turn on flexible transactions (and I only reviewed that method for 2 minutes). 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. You additionally have not yet bothered to address the discussion of soft-fork security at https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-December/012014.html which I believe answers all of your claims about upgrades required in a much more detailed discussion than I will include here. Please take your off-topic discussions there instead of this thread. On 10/16/16 18:20, Tom Zander via bitcoin-dev wrote: > On Sunday, 16 October 2016 09:47:40 CEST Douglas Roark via bitcoin-dev > wrote: >> Would I want anyone to lose money due to faulty wallets? Of course not. >> By the same token, devs have had almost a year to tinker with SegWit and >> make sure the wallet isn't so poorly written that it'll flame out when >> SegWit comes along. It's not like this is some untested, mostly unknown >> feature that's being slipped out at the last minute > > There have been objections to the way that SegWit has been implemented for a > long time, some wallets are taking a "wait and see" approach. If you look > at the page you linked[1], that is a very very sad state of affairs. The > vast majority is not ready. Would be interesting to get a more up-to-date > view. > Wallets probably won't want to invest resources adding support for a feature > that will never be activated. The fact that we have a much safer alternative > in the form of Flexible Transactions may mean it will not get activated. We > won't know until its actually locked in. > Wallets may not act until its actually locked in either. And I think we > should respect that. > > Even if all wallets support it (and thats a big if), they need to be rolled > out and people need to actually download those updates. > This takes time, 2 months after the lock-in of SegWit would be the minimum > safe time for people to actually upgrade. > > 1) https://bitcoincore.org/en/segwit_adoption/ > ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
