From: Peter Todd <pete@petertodd•org>
To: Simon Liu <simon@bitcartel•com>
Cc: Bitcoin Dev <bitcoin-dev@lists•linuxfoundation.org>
Subject: Re: [bitcoin-dev] On Hardforks in the Context of SegWit
Date: Mon, 8 Feb 2016 17:54:36 -0500 [thread overview]
Message-ID: <20160208225436.GB25684@savin.petertodd.org> (raw)
In-Reply-To: <56B9187F.3040104@bitcartel.com>
[-- Attachment #1: Type: text/plain, Size: 2415 bytes --]
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.
>
> 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?
>
> 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.
--
https://petertodd.org 'peter'[:-1]@petertodd.org
000000000000000001ae7ca66e52359d67c407a739fde42b83ecc746d3ab735d
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 650 bytes --]
next prev parent reply other threads:[~2016-02-08 22:55 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-02-08 19:26 Matt Corallo
2016-02-08 20:37 ` jl2012
2016-02-08 22:24 ` Tao Effect
[not found] ` <CAAcC9yuJY3Lsd7Z0rx8TFLNT1fJLhrpxzKJREQ7FmdNNjdXJow@mail.gmail.com>
2016-02-09 2:45 ` Tao Effect
2016-02-08 22:36 ` Simon Liu
2016-02-08 22:54 ` Peter Todd [this message]
2016-02-09 9:00 ` Anthony Towns
2016-02-09 21:54 ` Matt Corallo
2016-02-09 22:00 ` Matt Corallo
2016-02-09 22:10 ` Luke Dashjr
2016-02-09 22:39 ` Matt Corallo
2016-02-10 5:16 ` Anthony Towns
2016-02-09 12:32 Nicolas Dorier
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20160208225436.GB25684@savin.petertodd.org \
--to=pete@petertodd$(echo .)org \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
--cc=simon@bitcartel$(echo .)com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox