Date: Mon, 8 Feb 2016 17:54:36 -0500
From: Peter Todd <pete@petertodd.org>
To: Simon Liu <simon@bitcartel.com>
Message-ID: <20160208225436.GB25684@savin.petertodd.org>
References: <56B8EBF8.4050602@mattcorallo.com> <56B9187F.3040104@bitcartel.com>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha256;
	protocol="application/pgp-signature"; boundary="E39vaYmALEf/7YXx"
Content-Disposition: inline
In-Reply-To: <56B9187F.3040104@bitcartel.com>
Cc: Bitcoin Dev <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] On Hardforks in the Context of SegWit
Precedence: list


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

On Mon, Feb 08, 2016 at 02:36:47PM -0800, Simon Liu via bitcoin-dev wrote:
> > 1) The segregated witness discount is changed from 75% to 50%. The block
> > size limit (ie transactions + witness/2) is set to 1.5MB. This gives a
> > maximum block size of 3MB and a "network-upgraded" block size of roughly
> > 2.1MB. This still significantly discounts script data which is kept out
> > of the UTXO set, while keeping the maximum-sized block limited.
>=20
> What is the rationale for offering a discount?

UTXO set space is significantly more expensive for the network as all
full nodes must keep the entire UTXO set.

Additionally, transaction input/output data in general is argued by some
to be less expensive than signatures, as you have more options with
regard to skipping validation of signatures (e.g. how Bitcoin Core skips
validation of signatures prior to checkpoints).

> Is there an economic basis for setting the original discount at 75%
> instead of some other number?
>=20
> If it's okay to arbitrarily reduce the discount by 1/3, what are the
> actual boundary limits:  50% - 75% ?  40% - 80% ?

So, something to keep in mind in general in all these discussions is
that at best engineering always has "magic numbers" involved, the
question is where?

For example, I've proposed that we use a 99% miner vote threshold for
hard-forks (remember that the threshold can always be soft-forked down
later). The rational there is, among other things, you want to ensure
that the non-adopting miners' chain is useless for transacting due to
extremely long block times, as well as we want it to receive
confirmations slowly to prevent fraud. (of course, there's also the
non-technical argument that we want to adopt hard-forks with extremely
wide adoption) At 99% the 1% remaining chain will have a block interval
of about 16 hours.

Now, I've been asked "why 99%? isn't that a magic number?"

I could have instead said my goal was to increase the block interval to
24 hours, in which case I'd have used a 99.3% threshold. But again,
isn't 24 hours a magic number? Why not 25hrs?

The answer is 24 hours *is* a magic number - but trying to eliminate
that with yet another meta level of engineering analysis becomes a game
of diminishing returns.

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

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

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

iQGrBAEBCACVBQJWuRynXhSAAAAAABUAQGJsb2NraGFzaEBiaXRjb2luLm9yZzAw
MDAwMDAwMDAwMDAwMDAwNDJjOWZmZGJjODM3Mzc4MTIzYzViZWNhNzBhYzM4YmY0
YTAzYjc5NTNjZDgzM2EvFIAAAAAAFQARcGthLWFkZHJlc3NAZ251cGcub3JncGV0
ZUBwZXRlcnRvZC5vcmcACgkQJIFAPaXwkfuGQAgAjWK7TMEXWwtzzBwBzzj1epIe
Tz6oLcdbw28UZ7UQ9FzQVMAoZaAernO68i0P48d6CsICBW6EBH+jlqJYNcZtywff
Ff9dvmDY9wUvkZr9bFcr8qW+p+Ow65Jw5w0nvB41XGC8FegezYfTI1FQ/WmefOLu
SZZ4q/Yp2cpGt4GyZfQ0DKOM+qfw1LQ6PkcHo4B9eFPDShngBwa+hyVTZsuAFWrb
h+UTO/tk1OkKTMPdcilSkTBnP4H8RAPPjsRV3LLBbFYQECxvQN/XqRSmqj/oPGl4
z2HWNu07xorxfc0IzBPt5+6qbciEox0RaSJmIKKMAaY6/ompEup+GX97I/g3Hw==
=gnxj
-----END PGP SIGNATURE-----

--E39vaYmALEf/7YXx--