Date: Mon, 17 Oct 2016 09:09:27 -0400
From: Peter Todd <pete@petertodd.org>
To: Tom Zander <tomz@freedommail.ch>,
	Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Message-ID: <20161017130927.GA19897@fedora-21-dvm>
References: <CAPg+sBjdyJ297-GZvVc-wQwCEX-cRAGTNWDd92SgVzdCcD_ZMw@mail.gmail.com>
	<7939356.11nSWPlGYM@strawberry>
	<22046ac7-df36-2e2a-759e-b3dd01601c59@gmail.com>
	<2381760.VTJ5BOIlGi@strawberry>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha256;
	protocol="application/pgp-signature"; boundary="NzB8fVQJ5HfG6fxh"
Content-Disposition: inline
In-Reply-To: <2381760.VTJ5BOIlGi@strawberry>
User-Agent: Mutt/1.5.23 (2014-03-12)
Subject: Re: [bitcoin-dev] Start time for BIP141 (segwit)
Precedence: list


--NzB8fVQJ5HfG6fxh
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

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.
> >=20
> > 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?=20
>=20
> As Marek wrote just minutes before your email came in; companies will not=
=20
> 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=
=20
> false. Thats only the case for miners.
>=20
> The entire point here is that SegWit is much bigger than just full nodes=
=20
> (including miner).
> An entire ecosystem of Bitconin will have a need to upgrade.
>=20
> I understand people saying that non-miners don't *need* to upgrade in ord=
er=20
> to avoid being kicked of the network, but truely, thats a bogus argument.
>=20
> People want to actually participate in Bitcoin and that means they need t=
o=20
> 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 OpenTimestam=
ps
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" transact=
ions
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 t=
hese
beneficial properties. And as Matt Corallo reported, it's no-where near rea=
dy
for deployment: three buffer overflows in 80 lines of code is a serious
problem.

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

--NzB8fVQJ5HfG6fxh
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: Digital signature

-----BEGIN PGP SIGNATURE-----

iQEcBAEBCAAGBQJYBM2EAAoJEGOZARBE6K+yCRQH/14iEWDZEKbaYslJxjJIBwp+
okkQImISH9/LQ0aG8F1E0TjmQ6WDu1WcvKgF0pO3/J0/VYljnVb4Ttn8vHE4UYkJ
VZfH2F0dwB8gSBeNQceW9YBP1EWL52cmc5XENk7aQaCfVD9iax9XdBE8MCYU/Pv1
mtJVXWl/dW2G6nBe0tGW5DPmS5pnDqOrSx2I8k2HzCakRg831Xp6Zd9kUCEt5Rfo
MgOPUuiJqT9FShhC8lU5MtgzvnuytzypFGKs7umtqStRSWyN5zOrd9EZEm2Owb6J
iC/mUMIj8soIteJXb4PaxcQvKImkdiYaRXC4oc8ZSJ/6RqkXb7HV78XixBrKfls=
=3vyT
-----END PGP SIGNATURE-----

--NzB8fVQJ5HfG6fxh--