From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id 299546C for ; Mon, 13 Mar 2017 04:59:13 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-pg0-f48.google.com (mail-pg0-f48.google.com [74.125.83.48]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id ADDAA190 for ; Mon, 13 Mar 2017 04:59:11 +0000 (UTC) Received: by mail-pg0-f48.google.com with SMTP id b129so59437471pgc.2 for ; Sun, 12 Mar 2017 21:59:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=RSt2qcHO8oP/ATboIz8c586TXtyhbylX+lX2PaXNcGw=; b=OlTn8ym8FovLxbAAfYzy2MQjlHYUyCNMpGECe1KQYiKWfxUoKFdpOyL8ZNd0jUMin0 UPZ036vJ/7mGg5TDP/EB5SM32n2q05coPKc+oa3UlV2XiEcq3qs5tqoyhFr9ZGZf/Yl3 mNSaDuMYb2gXkzGEQ7TOElGVKkFms55+BccaYkTs6NgmvDfUEbYiep2GOIIuNxRfzQ5v ovqGEdFmQdcL+gK36soZ51LsLvLaVOFs7RNJQuH2+bRbv0QU5hSf+0WlrLU1AF8HVaRN 6RdyDaelcDOTk5UNu4dA+d0Zb3xYCWZcfbh5DoCCZgFnyWN7g+vtaLJT3imlJvWnlazJ v1zw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=RSt2qcHO8oP/ATboIz8c586TXtyhbylX+lX2PaXNcGw=; b=XtYqOSUmYmg3SRLUN7RGzGFBqcV/9gtw7CCPNBnlVE/O3Okk6nqzkudE7gGjTERHt9 zim1MojQ5WGghs929AwgWZMcGwwsbo0S9N9dM3hLztCerzLgebswkmd8QgLB8/iSA+oI QFUyHxzkXwz2/DJCX33qqh5q/9QeHdMhbFzOST+CWAk/VG+CPMDy27Mu0ae7H3afmy8i 1WH5OCRn1Qf4/STogTpyPacDhKZqC7kwWNtiJ9bnsYj+Q/mV6CYJAxhebQtrlsZxNywA rOuus3AKBcftgWQCPVorUJRY73BMNtvF5HnL4ZQ0nPdmRGtT5SnPvSwwEeEKZHE6CfBX bAiQ== X-Gm-Message-State: AMke39kVtMPywHyWZfZjw4mTmtg2+s0aOWYRpdfvV4JP6n3RjH3nIALKKcjkeKF+WZpQ8beq8Kyq7m2U5K2lZQ== X-Received: by 10.98.70.198 with SMTP id o67mr35778245pfi.39.1489381151228; Sun, 12 Mar 2017 21:59:11 -0700 (PDT) MIME-Version: 1.0 Received: by 10.100.166.75 with HTTP; Sun, 12 Mar 2017 21:59:10 -0700 (PDT) In-Reply-To: References: From: Nick ODell Date: Sun, 12 Mar 2017 22:59:10 -0600 Message-ID: To: shaolinfry , Bitcoin Protocol Discussion Content-Type: multipart/alternative; boundary=94eb2c0b839a744aaa054a959216 X-Spam-Status: No, score=-2.0 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, FREEMAIL_FROM, HTML_MESSAGE, RCVD_IN_DNSWL_NONE autolearn=ham version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on smtp1.linux-foundation.org Subject: Re: [bitcoin-dev] Flag day activation of segwit X-BeenThere: bitcoin-dev@lists.linuxfoundation.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Bitcoin Protocol Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Mar 2017 04:59:13 -0000 --94eb2c0b839a744aaa054a959216 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable The problem with modifying Bitcoin to work around community norms is that it's a two-way street. Other people can do it too. Let me propose a counter-fork, or a "Double UASF." This is also a BIP9 fork, and it uses, say, bit 2. starttime is 1489449600, and the end time is 1506812400. It enforces every rule that UASF enforces, plus one additional rule. If 60% of blocks in any retargeting period signal for Double UASF, any descendant block that creates or spends a segregated witness output is invalid. Double UASF signaling never coincides with UASF signaling, because the signaling periods don't overlap. Full nodes happily validate the chain, because Double UASF doesn't break any rules; it just adds new ones. Miners who adopt Double UASF don't need to understand segwit, because all segwit transactions are banned. Miners don't need to commit to a wtxid structure, either. Per BIP 141, "If all transactions in a block do not have witness data, the commitment is optional." Segwit is activated, but useless. Miners who *do* adopt segwit will lose money, as their blocks are orphaned. Thanks, --Nick On Sun, Mar 12, 2017 at 9:50 AM, shaolinfry via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > I recently posted about so called "user activated soft forks" and receive= d > a lot of feedback. Much of this was how such methodologies could be appli= ed > to segwit which appears to have fallen under the miner veto category I > explained in my original proposal, where there is apparently a lot of > support for the proposal from the economy, but a few mining pools are > vetoing the activation. > > It turns out Bitcoin already used flag day activation for P2SH[1 > = ], > a soft fork which is remarkably similar to segwit. The disadvantage of a > UASF for segwit is there is an existing deployment. A UASF would require > another wide upgrade cycle (from what I can see, around 80% of existing > nodes have upgraded from pre-witness, to NODE_WITNESS capability[2 > ][3 > ]. > While absolute node count is meaningless, the uprgrade trend from version > to version seems significant. > > Also it is quite clear a substantial portion of the ecosystem industry ha= s > put in time and resources into segwit adoption, in the form of upgrading > wallet code, updating libraries and various other integration work that > requires significant time and money. Further more, others have built > systems that rely on segwit, having put significant engineering resources > into developing systems that require segwit - such as several lightning > network system. This is much more significant social proof than running a > node. > > The delayed activation of segwit is also holding back a raft protocol of > innovations such as MAST, Covenants, Schnorr signature schemes and > signature aggregation and other script innovations of which, much of the > development work is already done. > > A better option would be to release code that causes the existing segwit > deployment to activate without requiring a completely new deployment nor > subject to hash power veto. This could be achieved if the economic majori= ty > agree to run code that rejects non-signalling segwit blocks. Then from th= e > perspective of all existing witness nodes, miners trigger the BIP9 > activation. Such a rule could come into effect 4-6 weeks before the BIP9 > timeout. If a large part of the economic majority publicly say that they > will adopt this new client, miners will have to signal bip9 segwit > activation in order for their blocks to be valid. > > I have drafted a BIP proposal so the community may discuss > https://gist.github.com/shaolinfry/743157b0b1ee14e1ddc95031f1057e4c (full > text below). > > References: > [1]: https://github.com/bitcoin/bitcoin/blob/v0.6.0/ > src/main.cpp#L1281-L1283 > [2]: http://luke.dashjr.org/programs/bitcoin/files/charts/services.html > [3]: https://www.reddit.com/r/Bitcoin/comments/5yyqt1/ > evidence_of_widespread_segwit_support_near50_of/ > > Proposal text: > > 
>   BIP: bip-segwit-flagday
>   Title: Flag day activation for segwit deployment
>   Author: Shaolin Fry 
>   Comments-Summary: No comments yet.
>   Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-????
>   Status: Draft
>   Type: Informational
>   Created: 2017-03-12
>   License: BSD-3-Clause
>            CC0-1.0
>
> > =3D=3DAbstract=3D=3D > > This document specifies a BIP16 like soft fork flag day activation of the= segregated witness BIP9 deployment known as "segwit". > > =3D=3DDefinitions=3D=3D > > "existing segwit deployment" refer to the BIP9 "segwit" deployment using = bit 1, between November 15th 2016 and November 15th 2017 to activate BIP141= , BIP143 and BIP147. > > =3D=3DMotivation=3D=3D > > Cause the mandatory activation of the existing segwit deployment before t= he end of midnight November 15th 2017. > > =3D=3DSpecification=3D=3D > > All times are specified according to median past time. > > This BIP will be activate between midnight October 1st 2017 (epoch time 1= 538352000) and midnight November 15th 2017 (epoch time 1510704000) if the e= xisting segwit deployment is not activated before epoch time 1538352000. Th= is BIP will cease to be active when the existing segwit deployment activate= s. > > While this BIP is active, all blocks must set the nVersion header top 3 b= its to 001 together with bit field (1<<1) (according to the existing segwit= deployment). Blocks that do not signal as required will be rejected. > > =3D=3D=3D Reference implementation =3D=3D=3D > > 
> // mandatory segwit activation between Oct 1st 2017 and Nov 15th 2017 inc=
lusive
> if (pindex->GetMedianTimePast() >=3D 1538352000 && pindex->GetMedianTimeP=
ast() <=3D 1510704000 && !IsWitnessEnabled(pindex->pprev, chainparams.GetCo=
nsensus())) {
>     if (!((pindex->nVersion & VERSIONBITS_TOP_MASK) =3D=3D VERSIONBITS_TO=
P_BITS) && (pindex->nVersion & VersionBitsMask(params, Consensus::DEPLOYMEN=
T_SEGWIT)) !=3D 0) {
>         return state.DoS(2, error("ConnectBlock(): relayed block must sig=
nal for segwit, please upgrade"), REJECT_INVALID, "bad-no-segwit");
>     }
> }
>
> > =3D=3DBackwards Compatibility=3D=3D > > This deployment is compatible with the existing "segwit" bit 1 deployment= scheduled between midnight November 15th, 2016 and midnight November 15th,= 2017. > > =3D=3DRationale=3D=3D > > Historically, the P2SH soft fork (BIP16) was activated using a predetermi= ned flag day where nodes began enforcing the new rules. P2SH was successful= ly activated with relatively few issues > > By orphaning non-signalling blocks during the last month of the BIP9 bit = 1 "segwit" deployment, this BIP can cause the existing "segwit" deployment = to activate without needing to release a new deployment. > > =3D=3DReferences=3D=3D > > [https://github.com/bitcoin/bitcoin/blob/v0.6.0/src/main.cpp#L1281-L1283 = P2SH flag day activation]. > > =3D=3DCopyright=3D=3D > > This document is placed in the public domain. > > > > > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > > --94eb2c0b839a744aaa054a959216 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
The problem with modifying Bitcoin to work aroun= d community norms is that it's a two-way street. Other people can do it= too.

Let me propose a counter-fork, or a "Do= uble UASF." This is also a BIP9 fork, and it uses, say, bit 2. startti= me is 1489449600, and the end time is 1506812400. It enforces every rule th= at UASF enforces, plus one additional rule. If 60% of blocks in any retarge= ting period signal for Double UASF, any descendant block that creates or sp= ends a segregated witness output is invalid.

Doubl= e UASF signaling never coincides with UASF signaling, because the signaling= periods don't overlap. Full nodes happily validate the chain, because = Double UASF doesn't break any rules; it just adds new ones. Miners who = adopt Double UASF don't need to understand segwit, because all segwit t= ransactions are banned. Miners don't need to commit to a wtxid structur= e, either. Per BIP 141, "If all transactions in a block do not have wi= tness data, the commitment is optional." Segwit is activated, but usel= ess. Miners who *do* adopt segwit will lose money, as their blocks are orph= aned.

Thanks,
--Nick

On Sun, Mar 12, 201= 7 at 9:50 AM, shaolinfry via bitcoin-dev <bitcoin-dev@= lists.linuxfoundation.org> wrote:
I recently post= ed about so called "user activated soft forks" and received a lot= of feedback. Much of this was how such methodologies could be applied to s= egwit which appears to have fallen under the miner veto category I explaine= d in my original proposal, where there is apparently a lot of support for t= he proposal from the economy, but a few mining pools are vetoing the activa= tion.

It turns out Bitcoi= n already used flag day activation for P2SH[1], a soft fork which is r= emarkably similar to segwit. The disadvantage of a UASF for segwit is there= is an existing deployment. A=C2=A0UASF would require another wide upgrade = cycle (from what I can see, around 80% of existing nodes have upgraded from= pre-witness, to NODE_WITNESS capability[2][3]. While absolute node count is meaningless, the uprgrade trend from versi= on to version seems significant.


The delayed activation of s= egwit is also holding back a raft protocol of innovations such as MAST, Cov= enants, Schnorr signature schemes and signature aggregation and other scrip= t innovations of which, much of the development work is already done.

A better option would be to re= lease code that causes the existing segwit deployment to activate without r= equiring a completely new deployment nor subject to hash power veto. This c= ould be achieved if the economic majority agree to run code that rejects no= n-signalling segwit blocks. Then from the perspective of all existing witne= ss nodes, miners trigger the BIP9 activation. Such a rule could come into e= ffect 4-6 weeks before the BIP9 timeout. If a large part of the economic ma= jority publicly say that they will adopt this new client, miners will have = to signal bip9 segwit activation in order for their blocks to be valid.
=


References:

Proposal text:

<pre>
  BIP: bip-segwit-flagday
  Title: Flag day activation for segwit deployment
  Author: Shaolin Fry <shaolinfry@protonmail.ch>
  Comments-Summary: No comments yet.
  Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BI=
P-????
  Status: Draft
  Type: Informational
  Created: 2017-03-12
  License: BSD-3-Clause
           CC0-1.0
</pre>

=3D=3DAbstract=3D=3D

This document specifies a BIP16 like soft fork flag day activation of the s=
egregated witness BIP9 deployment known as "segwit".

=3D=3DDefinitions=3D=3D

"existing segwit deployment" refer to the BIP9 "segwit"=
 deployment using bit 1, between November 15th 2016 and November 15th 2017 =
to activate BIP141, BIP143 and BIP147.

=3D=3DMotivation=3D=3D

Cause the mandatory activation of the existing segwit deployment before the=
 end of midnight November 15th 2017.

=3D=3DSpecification=3D=3D

All times are specified according to median past time.

This BIP will be activate between midnight October 1st 2017 (epoch time 153=
8352000) and midnight November 15th 2017 (epoch time 1510704000) if the exi=
sting segwit deployment is not activated before epoch time 1538352000. This=
 BIP will cease to be active when the existing segwit deployment activates.

While this BIP is active, all blocks must set the nVersion header top 3 bit=
s to 001 together with bit field (1<<1) (according to the existing se=
gwit deployment). Blocks that do not signal as required will be rejected.

=3D=3D=3D Reference implementation =3D=3D=3D

<pre>
// mandatory segwit activation between Oct 1st 2017 and Nov 15th 2017 inclu=
sive
if (pindex->GetMedianTimePast() >=3D 1538352000 && pindex->=
;GetMedianTimePast() <=3D 1510704000 && !IsWitnessEnabled(pindex=
->pprev, chainparams.GetConsensus())) {
    if (!((pindex->nVersion & VERSIONBITS_TOP_MASK) =3D=3D VERSIONBI=
TS_TOP_BITS) && (pindex->nVersion & VersionBitsMask(params, =
Consensus::DEPLOYMENT_SEGWIT)) !=3D 0) {
        return state.DoS(2, error("ConnectBlock(): relayed block must =
signal for segwit, please upgrade"), REJECT_INVALID, "bad-no-segw=
it");
    }
}
</pre>

=3D=3DBackwards Compatibility=3D=3D

This deployment is compatible with the existing "segwit" bit 1 de=
ployment scheduled between midnight November 15th, 2016 and midnight Novemb=
er 15th, 2017.

=3D=3DRationale=3D=3D

Historically, the P2SH soft fork (BIP16) was activated using a predetermine=
d flag day where nodes began enforcing the new rules. P2SH was successfully=
 activated with relatively few issues

By orphaning non-signalling blocks during the last month of the BIP9 bit 1 =
"segwit" deployment, this BIP can cause the existing "segwit=
" deployment to activate without needing to release a new deployment.

=3D=3DReferences=3D=3D

[https://github.com/bitcoin/bitcoin/blob/v0=
.6.0/src/main.cpp#L1281-L1283 P2SH flag day activation].

=3D=3DCopyright=3D=3D

This document is placed in the public domain.



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


--94eb2c0b839a744aaa054a959216--