Re: [bitcoin-dev] (no subject)

[Matt Corallo <lf-lists@mattcorallo.com>]

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