public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
From: "Hampus Sjöberg" <hampus.sjoberg@gmail.com>
To: shaolinfry <shaolinfry@protonmail.ch>
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Barry Silbert segwit agreement
Date: Mon, 22 May 2017 11:23:22 +0200	[thread overview]
Message-ID: <CAFMkqK_8CfaPmZgwMqGWpRujmmyGKXhZyxK_tQ6f1OMHKdEMJA@mail.gmail.com> (raw)
In-Reply-To: <2zSehquWdVTgHhfHfQpAHZTGAyzv-XFias7rRsns0j6TpJryz6Fyvst3N0v_2_Q3KsYiyRn9qd9Gb1QLUxh5F11RAlVmvezYN8d4m8q5F-A=@protonmail.ch>

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

I'm really happy to see people trying to cooperate to get SegWit activated.
But I'm really unsure about the technicalities about Silbert's proposal.

If we're going to do a hardfork, it makes most sense to assist Johnson in
his spoonnet/forcenet proposals.
Just doing a simple 2MB without fixing anything else is very uninteresting,
and a hardfork without addressing replay protection seems really
unprofessional to me.
And proposing a hardfork in 4 months in the future, is completely insane.
You cannot expect a 100% of all nodes in P2P network to upgrade in 4 months.

I think it's much better to activate BIP141 ASAP, and then hardfork to 2MB
September 2018, or 2019 (together with forcenet/spoonnet).
And if not, BIP148 is gaining momentum once again so that sounds much more
interesting.

Hampus

2017-05-22 8:12 GMT+02:00 shaolinfry via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org>:

> Someone sent me a copy of the Barry Silbert agreement, an agreement forged
> between a select number of participants https://pastebin.com/VuCYteJh
>
> Participants agree to immediately activate Segwit, however, under a
> different activation proposal. Since I have spent the last few months
> researching various activation strategies of the current BIP141 deployment,
> as well as redeployment, I feel I am quite well placed to comment on the
> technicalities.
>
> To be clear, the proposal as far as I can see does not activate BIP141,
> but is a completely new deployment which would be incompatible with the
> BIP141 deployment. I'm not sure how that can be considered "immediate"
> activation. Surely immediate activation would just be for miners to start
> signalling and segwit would be activated in 4-5 weeks. The proposal seems
> to require a lower 80% threshold, I assume because they were unable to
> convince 95% of the hashpower to go trigger activation.
>
> There are a few options to activating segwit now, the first being for 95%
> of hashrate to signal. The second is for the community to deploy BIP148
> UASF which will force miners to signal segwit. Being a UASF it is date
> triggered. The third option is a redeployment of segwit on a new bit, but
> requires waiting for the existing deployment to time out, because all the
> p2p messages and service bits related to segwit must be replaced too (which
> is what BIP149 does).
>
> A fourth option, first suggested to me by James Hilliard, was to make
> BIP148 miner triggered (MASF) with a lower threshold, above 50%. I coded
> this up a few weeks ago https://github.com/bitcoin/
> bitcoin/compare/master...shaolinfry:segsignal but didnt get around to
> posting to the ML yet. This effectively lowers the threshold from 95% to
> 65% as coded, or could be upped to 80% or whatever was preferable.
>
> I think this removes the primary risk of BIP148 causing the creation of
> two chains, and gives an improved chance to get segwit activated quickly
> (assuming a majority of miners wish to go this route). But hash a primary
> disadvantage of still leaving the activation in the hands of miners. If it
> doesn't work out, then BIP149 can then be used as proposed, but it'll be
> even safer because we'll have futher guaged support.
>
> References:
>
> SEGSIGNAL: https://github.com/bitcoin/bitcoin/compare/master...
> shaolinfry:segsignal
> BIP148: https://github.com/bitcoin/bips/blob/master/bip-0148.mediawiki
> BIP149: https://github.com/bitcoin/bips/blob/master/bip-0149.mediawiki
>
> I think the Barry Silbert agreement is very ill considered, and clearly
> lacking peer review from the technical community. Suggestions of a HF in 4
> months are completely unrealistic and without technical merits. But more
> importantly, closed door agreements between selected participants is not
> how to garner consensus to change a $30bn decentralized system. The purpose
> of my email is to try and assist in the "immediate activation of segwit"
> which only requires hashrate to participate; and to provide some techincal
> input since I have done a great deal of research and development into the
> topic.
>
> Given the history we've already passed the point where we should be
> expecting miners to cooperate in lowering their own fee income with a
> capacity increase; but we should be open to all reasonable options in the
> interest in moving things forward in a safe and collaborative way.
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>

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

  parent reply	other threads:[~2017-05-22  9:23 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-05-22  6:12 [bitcoin-dev] Barry Silbert segwit agreement shaolinfry
2017-05-22  6:27 ` Peter Todd
2017-05-22  9:23 ` Hampus Sjöberg [this message]
2017-05-22 12:29 Daniele Pinna
2017-05-26 17:47 Jacob Eliosoff
2017-05-26 18:48 ` Tom Zander
2017-05-26 20:02 ` Matt Corallo
2017-05-26 20:10   ` Jacob Eliosoff
2017-05-26 21:30     ` James Hilliard
2017-05-26 22:12       ` Tom Zander
     [not found]         ` <CADvTj4qdr2yGYFEWA7oVmL-KkrchYb5aQBRY9w0OK4ZVopSTSA@mail.gmail.com>
2017-05-28 20:51           ` Tom Zander
2017-05-28 23:28             ` James Hilliard
2017-05-26 22:44       ` Matt Corallo

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=CAFMkqK_8CfaPmZgwMqGWpRujmmyGKXhZyxK_tQ6f1OMHKdEMJA@mail.gmail.com \
    --to=hampus.sjoberg@gmail.com \
    --cc=bitcoin-dev@lists.linuxfoundation.org \
    --cc=shaolinfry@protonmail.ch \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
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