To: Tom Zander <tomz@freedommail.ch>,
	Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
References: <CAPg+sBjdyJ297-GZvVc-wQwCEX-cRAGTNWDd92SgVzdCcD_ZMw@mail.gmail.com>
	<CABsx9T2sWKFKpRYsjcgcdef+nL7X9-4+3H10hAy1FsXaax38Og@mail.gmail.com>
	<2d5abad7-cd9d-4396-4dd2-c687a1a808dc@vt.edu>
	<2034434.4WpKWoeOrB@strawberry>
From: Matt Corallo <lf-lists@mattcorallo.com>
Message-ID: <5803D698.2080102@mattcorallo.com>
Date: Sun, 16 Oct 2016 19:35:52 +0000
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101
	Thunderbird/38.7.0
MIME-Version: 1.0
In-Reply-To: <2034434.4WpKWoeOrB@strawberry>
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: 7bit
Subject: Re: [bitcoin-dev] (no subject)
Precedence: list

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