Re: [bitcoin-dev] Start time for BIP141 (segwit)

[Peter Todd <pete@petertodd.org>]

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

On Mon, Oct 17, 2016 at 01:17:39PM +0200, Tom Zander via bitcoin-dev wrote:
> On Sunday, 16 October 2016 17:19:37 CEST Andrew C wrote:
> > On 10/16/2016 4:58 PM, Tom Zander via bitcoin-dev wrote:
> > > Lets get back to the topic. Having a longer fallow period is a simple
> > > way to be safe.  Your comments make me even more scared that safety is
> > > not taken into account the way it would.
> > 
> > Can you please explain how having a longer grace period makes it any
> > safer? Once the fork reaches the LOCKED_IN status, the fork will become
> > active after the period is over. How does having a longer grace period
> > make this any safer besides just adding more waiting before it goes
> > active? 
> 
> As Marek wrote just minutes before your email came in; companies will not 
> roll out their updates until it locks in. Peter Todd says the same thing.
> So your assumption that the lock-in time is the END of the upgrading is 
> false. Thats only the case for miners.
> 
> The entire point here is that SegWit is much bigger than just full nodes 
> (including miner).
> An entire ecosystem of Bitconin will have a need to upgrade.
> 
> I understand people saying that non-miners don't *need* to upgrade in order 
> to avoid being kicked of the network, but truely, thats a bogus argument.
> 
> People want to actually participate in Bitcoin and that means they need to 
> understand all of it. Not just see anyone-can-spend transactions.
> I think its rather odd to think that developers on this list can decide
> the risk profile that Bitcoin using companies or individuals should have.

Please don't misleadingly reference/quote me.

I made it quite clear in my last post that because segwit is a backwards
compatible soft-fork, the vast majority of code out there will not have to
change; my own OpenTimestamps being a good example. All I'll have to do to
prepare for segwit is upgrade the (pruned) full nodes that the OpenTimestamps
servers depend on to determine what's the most-work valid chain, and in the
event I was concerned about compatibility issues, I could easily run my
existing nodes behind updated segwit-supporting (pruned) nodes.

Like most users, my OpenTimestamps code doesn't "fully understand" transactions
at all - I rely on my full node to do that for me. What it does understand
about transactions and blocks remains the same in segwit. I can receive
transactions from segwit users with lite-client security without any action at
all, and full-node security once I upgrade my full nodes (or run them behind
upgraded nodes).

Your proposed alternative to segwit - flexible transactions - has none of these
beneficial properties. And as Matt Corallo reported, it's no-where near ready
for deployment: three buffer overflows in 80 lines of code is a serious
problem.

-- 
https://petertodd.org 'peter'[:-1]@petertodd.org

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 455 bytes --]