From: Daniele Pinna <daniele.pinna@gmail•com>
To: Bitcoin Dev <bitcoin-dev@lists•linuxfoundation.org>
Subject: Re: [bitcoin-dev] Three hardfork-related BIPs
Date: Fri, 27 Jan 2017 13:12:57 +0100 [thread overview]
Message-ID: <CAEgR2PHnAGUjCyc9unkPnh+dj_zBa7SjHuvFV+VLKk6G-k3x0A@mail.gmail.com> (raw)
[-- Attachment #1: Type: text/plain, Size: 4003 bytes --]
Your BIP implementation should stress the capacity to softfork the rate of
blocksize increase if necessary. You briefly mention that:
*If over time, this growth factor is beyond what the actual technology
offers, the intention should be to soft fork a tighter limit.*
However this can work both ways so that the rate can potentially be
increased also. I think just mentioning this will soothe a lot of future
critiques.
Daniele
*Message: 5Date: Fri, 27 Jan 2017 01:06:59 +0000From: Luke Dashjr
<luke@dashjr•org
<luke@dashjr•org>>To: bitcoin-dev@lists•linuxfoundation.org
<bitcoin-dev@lists•linuxfoundation.org>Subject: [bitcoin-dev] Three
hardfork-related BIPsMessage-ID: <201701270107.01092.luke@dashjr•org
<201701270107.01092.luke@dashjr•org>>Content-Type: Text/Plain;
charset="utf-8"I've put together three hardfork-related BIPs. This is
parallel to the ongoingresearch into the MMHF/SHF WIP BIP, which might
still be best long-term.1) The first is a block size limit protocol change.
It also addresses threecriticisms of segwit: 1) segwit increases the block
size limit which isalready considered by many to be too large; 2) segwit
treats pre-segwittransactions ?unfairly? by giving the witness discount
only to segwittransactions; and 3) that spam blocks can be larger than
blocks mininglegitimate transactions. This proposal may (depending on
activation date)initially reduce the block size limit to a more sustainable
size in the short-term, and gradually increase it up over the long-term to
31 MB; it will alsoextend the witness discount to non-segwit transactions.
Should the initialblock size limit reduction prove to be too controversial,
miners can simplywait to activate it until closer to the point where it
becomes acceptableand/or increases the limit. However, since the BIP
includes a hardfork, theeventual block size increase needs community
consensus before it can bedeployed. Proponents of block size increases
should note that this BIP doesnot interfere with another more aggressive
block size increase hardfork in themeantime. I believe I can immediately
recommend this for adoption; however,peer and community review are welcome
to suggest
changes.Text: https://github.com/luke-jr/bips/blob/bip-blksize/bip-blksize.mediawiki
<https://github.com/luke-jr/bips/blob/bip-blksize/bip-blksize.mediawiki>Code:
https://github.com/bitcoin/bitcoin/compare/master...luke-jr:bip-blksize
<https://github.com/bitcoin/bitcoin/compare/master...luke-jr:bip-blksize>(consensus
code changes only)2) The second is a *preparatory* change, that should
allow triviallytransforming certain classes of hardforks into softforks in
the future. Itessentially says that full nodes should relax their rule
enforcement, aftersufficient time that would virtually guarantee they have
ceased to beenforcing the full set of rules anyway. This allows these
relaxed rules to bemodified or removed in a softfork, provided the proposal
to do so is acceptedand implemented with enough advance notice. Attempting
to implement this hasproven more complicated than I originally expected,
and it may make more sensefor full nodes to simply stop functioning (with a
user override) after thecut-off date). In light of this, I do not yet
recommend its adoption, but amposting it for review and comments
only.Text: https://github.com/luke-jr/bips/blob/bip-hfprep/bip-hfprep.mediawiki
<https://github.com/luke-jr/bips/blob/bip-hfprep/bip-hfprep.mediawiki>3)
Third is an anti-replay softfork which can be used to prevent replayattacks
whether induced by a hardfork-related chain split, or even in
ordinaryoperation. It does this by using a new opcode
(OP_CHECKBLOCKATHEIGHT) for theBitcoin scripting system that allows
construction of transactions which arevalid only on specific
blockchains.Text:
https://github.com/luke-jr/bips/blob/bip-noreplay/bip-noreplay.mediawiki
<https://github.com/luke-jr/bips/blob/bip-noreplay/bip-noreplay.mediawiki>Luke*
Daniele Pinna, Ph.D
[-- Attachment #2: Type: text/html, Size: 8942 bytes --]
next reply other threads:[~2017-01-27 12:13 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-01-27 12:12 Daniele Pinna [this message]
-- strict thread matches above, loose matches on Subject: below --
2017-01-27 1:06 Luke Dashjr
[not found] ` <CAAy62_L-mLhokVy4_WeLBVnxM0Y76dtFBaaDrRvQozxw=J1Ctw@mail.gmail.com>
[not found] ` <CAAy62_+1OjF3V5g4wpOyW0KtNGodddJu_cxOfG-f+8LB7D=rPA@mail.gmail.com>
2017-01-27 3:04 ` Andrew Johnson
2017-01-27 4:14 ` Luke Dashjr
[not found] ` <CAAy62_LHtrx7k73kznMpPvheA--0T9YiHkjHArf2KK0Qt+ViUg@mail.gmail.com>
2017-01-27 6:13 ` Andrew Johnson
[not found] ` <CAMZUoKnxqxvPQehdWo1ZaHB-1-od4cHvJRDTmF5x7ty1CdLbUQ@mail.gmail.com>
[not found] ` <CAMZUoK=eb3jgA7Rwt38tvZt0tYk7gRVPc_2=HUWg1L_vaD93uw@mail.gmail.com>
2017-01-27 20:34 ` Russell O'Connor
2017-01-27 20:47 ` Greg Sanders
2017-01-27 21:28 ` Christian Decker
2017-01-27 23:53 ` Andrew Johnson
2017-01-28 4:03 ` Luke Dashjr
2017-01-28 10:36 ` Natanael
2017-01-28 18:29 ` Peter Todd
2017-01-29 19:15 ` Tom Harding
2017-01-29 19:37 ` Eric Voskuil
2017-02-11 15:26 ` Staf Verhaegen
2017-01-29 19:39 ` David Vorick
2017-01-28 19:43 ` Luke Dashjr
2017-01-28 21:54 ` Peter Todd
2017-02-06 16:24 ` mbtc-dev
2017-02-07 20:32 ` Eric Voskuil
2017-01-28 18:22 ` Peter Todd
2017-01-27 4:21 ` Johnson Lau
2017-01-27 18:54 ` t. khan
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=CAEgR2PHnAGUjCyc9unkPnh+dj_zBa7SjHuvFV+VLKk6G-k3x0A@mail.gmail.com \
--to=daniele.pinna@gmail$(echo .)com \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
/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