public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
From: Andrew Johnson <andrew.johnson83@gmail•com>
To: Luke Dashjr <luke@dashjr•org>,
	Bitcoin Dev <bitcoin-dev@lists•linuxfoundation.org>
Subject: Re: [bitcoin-dev] Three hardfork-related BIPs
Date: Thu, 26 Jan 2017 21:04:50 -0600	[thread overview]
Message-ID: <CAAy62_JuWMQ=HMmcw8GsQSDM8S+4LJeG1GHw1OdT+mQC3H-DOA@mail.gmail.com> (raw)
In-Reply-To: <CAAy62_+1OjF3V5g4wpOyW0KtNGodddJu_cxOfG-f+8LB7D=rPA@mail.gmail.com>

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

Comment on #1.  You're dropping the blocksize limit to 300KB and only
reaching the limit that we have in place today 7 years later?  We're
already at capacity today, surely you're not serious with this proposal?
When you promised code for a hard forking block size increase in the HK
agreement I don't believe that a decrease first was made apparent.  While
not technically in violation of the letter of the agreement, I think this
is a pretty obviously not in the spirit of it.

On Jan 26, 2017 7:07 PM, "Luke Dashjr via bitcoin-dev" <
bitcoin-dev@lists•linuxfoundation.org> wrote:

I've put together three hardfork-related BIPs. This is parallel to the
ongoing
research 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 three
criticisms of segwit: 1) segwit increases the block size limit which is
already considered by many to be too large; 2) segwit treats pre-segwit
transactions “unfairly” by giving the witness discount only to segwit
transactions; and 3) that spam blocks can be larger than blocks mining
legitimate 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 also
extend the witness discount to non-segwit transactions. Should the initial
block size limit reduction prove to be too controversial, miners can simply
wait to activate it until closer to the point where it becomes acceptable
and/or increases the limit. However, since the BIP includes a hardfork, the
eventual block size increase needs community consensus before it can be
deployed. Proponents of block size increases should note that this BIP does
not interfere with another more aggressive block size increase hardfork in
the
meantime. 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
Code: 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 trivially
transforming certain classes of hardforks into softforks in the future. It
essentially says that full nodes should relax their rule enforcement, after
sufficient time that would virtually guarantee they have ceased to be
enforcing the full set of rules anyway. This allows these relaxed rules to
be
modified or removed in a softfork, provided the proposal to do so is
accepted
and implemented with enough advance notice. Attempting to implement this has
proven more complicated than I originally expected, and it may make more
sense
for full nodes to simply stop functioning (with a user override) after the
cut-off date). In light of this, I do not yet recommend its adoption, but am
posting it for review and comments only.
Text: 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 replay
attacks whether induced by a hardfork-related chain split, or even in
ordinary
operation. It does this by using a new opcode (OP_CHECKBLOCKATHEIGHT) for
the
Bitcoin scripting system that allows construction of transactions which are
valid only on specific blockchains.
Text: https://github.com/luke-jr/bips/blob/bip-noreplay/bip-
noreplay.mediawiki

Luke
_______________________________________________
bitcoin-dev mailing list
bitcoin-dev@lists•linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

[-- Attachment #2: Type: text/html, Size: 4963 bytes --]

  parent reply	other threads:[~2017-01-27  3:04 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
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 [this message]
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
2017-01-27 12:12 Daniele Pinna

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='CAAy62_JuWMQ=HMmcw8GsQSDM8S+4LJeG1GHw1OdT+mQC3H-DOA@mail.gmail.com' \
    --to=andrew.johnson83@gmail$(echo .)com \
    --cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
    --cc=luke@dashjr$(echo .)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