[bitcoin-dev] (no subject)

[bitcoin-dev] (no subject)

[cAmiLLe miGnon tRixia P. Anecito]

[-- Attachment #1: Type: text/plain, Size: 39 bytes --]



Sent from Yahoo Mail on Android


[-- Attachment #2: Type: text/html, Size: 202 bytes --]

Re: [bitcoin-dev] (no subject)

[Btc Drak]

[-- Attachment #1: Type: text/plain, Size: 2671 bytes --]

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
>

[-- Attachment #2: Type: text/html, Size: 4001 bytes --]

Re: [bitcoin-dev] (no subject)

[Tom Zander]

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

Re: [bitcoin-dev] (no subject)

[Matt Corallo]

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/
>