path: root/65/51163f6b404c62501e727281c53600235de4a3

Return-Path: <carlo@spiller.com>
Received: from smtp2.osuosl.org (smtp2.osuosl.org [140.211.166.133])
 by lists.linuxfoundation.org (Postfix) with ESMTP id 36601C0001
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Mon,  8 Mar 2021 08:40:27 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by smtp2.osuosl.org (Postfix) with ESMTP id 1D877430F8
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Mon,  8 Mar 2021 08:40:27 +0000 (UTC)
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: -1.897
X-Spam-Level: 
X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5
 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001,
 RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001]
 autolearn=ham autolearn_force=no
Received: from smtp2.osuosl.org ([127.0.0.1])
 by localhost (smtp2.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
 with ESMTP id 49ovH9FNRwqs
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Mon,  8 Mar 2021 08:40:25 +0000 (UTC)
X-Greylist: delayed 22:26:36 by SQLgrey-1.8.0
Received: from smtprelay.hostedemail.com (smtprelay0043.hostedemail.com
 [216.40.44.43])
 by smtp2.osuosl.org (Postfix) with ESMTPS id 94FFA430F6
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Mon,  8 Mar 2021 08:40:25 +0000 (UTC)
Received: from smtprelay.hostedemail.com (10.5.19.251.rfc1918.com
 [10.5.19.251])
 by smtpgrave03.hostedemail.com (Postfix) with ESMTP id 2FD3318014D27
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Mon,  8 Mar 2021 08:24:23 +0000 (UTC)
Received: from filter.hostedemail.com (clb03-v110.bra.tucows.net
 [216.40.38.60])
 by smtprelay08.hostedemail.com (Postfix) with ESMTP id A7402182CED2A;
 Mon,  8 Mar 2021 08:24:19 +0000 (UTC)
X-Session-Marker: 6361726C6F407370696C6C65722E636F6D
X-Spam-Summary: 2, -9, 0, , d41d8cd98f00b204, carlo@spiller.com, ,
 RULES_HIT:1:2:41:69:72:152:355:379:599:800:854:960:962:967:968:973:983:988:989:1189:1208:1212:1221:1260:1263:1313:1314:1345:1359:1381:1431:1436:1437:1516:1517:1518:1575:1588:1589:1592:1594:1605:1606:1730:1776:1792:2068:2069:2194:2195:2198:2199:2200:2201:2525:2553:2568:2628:2682:2685:2829:2859:2897:2902:2933:2937:2939:2942:2945:2947:2951:2954:3022:3138:3139:3140:3141:3142:3865:3866:3867:3868:3870:3871:3872:3873:3874:3934:3936:3938:3941:3944:3947:3950:3953:3956:3959:4037:4250:4321:4362:4605:5007:6117:6248:6657:6674:6678:6996:6997:7514:7903:7996:8957:9010:9025:9036:9108:9121:9177:9388:10004:10848:11232:11233:11473:11657:11658:11914:12043:12050:12297:12379:12555:12660:12663:12683:12740:12895:12986:13139:14096:14659:15054:21060:21080:21401:21433:21450:21451:21627:21795:21809:21888:21939:22179:30051:30054:30056:30060:30070:30090,
 0, RBL:none, CacheIP:none, Bayesian:0.5, 0.5, 0.5, Netcheck:none,
 DomainCache:0, MSF:not bulk, SPF:, MSBL:0, DNSBL
X-HE-Tag: angle95_2215547276ef
X-Filterd-Recvd-Size: 10959
Received: from Carlos-Mac-Mini.local (bbcs-93-229.pub.wingo.ch [144.2.93.229])
 (Authenticated sender: carlo@spiller.com)
 by omf18.hostedemail.com (Postfix) with ESMTPA;
 Mon,  8 Mar 2021 08:24:18 +0000 (UTC)
To: Ariel Lorenzo-Luaces <arielluaces@gmail.com>,
 Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
References: <5a779c13-8ebf-5052-5bf7-846f970c21ef@spiller.com>
 <baad4898-6605-4edc-ad13-0f74289484ae@gmail.com>
From: Carlo Spiller <carlo@spiller.com>
Message-ID: <f1613726-527c-360f-f1c2-c34f8f933626@spiller.com>
Date: Mon, 8 Mar 2021 09:24:15 +0100
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.16; rv:78.0)
 Gecko/20100101 Thunderbird/78.8.0
MIME-Version: 1.0
In-Reply-To: <baad4898-6605-4edc-ad13-0f74289484ae@gmail.com>
Content-Type: multipart/alternative;
 boundary="------------1B3F731BF784D277617C1FEF"
X-Mailman-Approved-At: Mon, 08 Mar 2021 08:55:35 +0000
Subject: Re: [bitcoin-dev] Yet another Taproot activation logic
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Bitcoin Protocol Discussion <bitcoin-dev.lists.linuxfoundation.org>
List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>, 
 <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe>
List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/>
List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org>
List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help>
List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>, 
 <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=subscribe>
X-List-Received-Date: Mon, 08 Mar 2021 08:40:27 -0000

This is a multi-part message in MIME format.
--------------1B3F731BF784D277617C1FEF
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit

Hi Ariel

Thanks for your reply with the link to the SMA proposal, which I had 
missed previoulsy. It is indeed very similar.

I see that Speedy trial is currently gaining broad support, which is 
good. I think my proposal with the threshold set to 51% instead of 80% 
to change LOT=false to LOT=true is also pretty similar to ST, with the 
key difference being that the next step after a fail of MASF is already 
baked in.

Excited to see how it all plays out.

Best

Carlo

Carlo Spiller
+41 79 368 85 06
www.carlospiller.com

Am 07.03.21 um 22:13 schrieb Ariel Lorenzo-Luaces:
> Hi Carlo
>
> This your proposal is similar to the Simple Majority Activation 
> proposal (SMA). The difference is that your proposal has the final 
> activation threshold set to 80% and SMA has it set to 51% 
> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-March/018587.html 
> <https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-March/018587.html>
>
> The problem with what you're proposing is what do users do if 
> signaling is somewhere between 51% to 79%? Users that want to promote 
> a UASF know that their miner majority can activate Taproot and 
> activate without the 21% to 49% of miners needing to signal (or 
> purposefully stalling). A UASF knows they have majority mining power 
> so there is little risk to them and a big reward (activating Taproot) 
> so they are incentivized to do a UASF.
>
> A UASF with a miner majority can scare everyone else about them being 
> at risk of big reorgs to gain traction and followers.
>
> With the same proposal but the final threshold set to 51% instead of 
> 80% there can't be risk of a UASF because if 51% is not reached they 
> know they don't have enough miner support to keep the chain together.
>
> If support is less than 50% a UASF movement needs to hard fork anyway 
> to change the PoW (for protection) and change addresses to prevent 
> double spends.
>
> I really like the SMA proposal with 51% because it removes the 
> incentive to do a UASF.
>
> Cheers
> Ariel Lorenzo-Luaces
> On Mar 7, 2021, at 6:37 AM, Carlo Spiller via bitcoin-dev 
> <bitcoin-dev@lists.linuxfoundation.org 
> <mailto:bitcoin-dev@lists.linuxfoundation.org>> wrote:
>
>     Hi everybody
>
>     I'm new to this list, but not new to Bitcoin, having skin in the game
>     since 2014. I was there for the scaling war and the drama around SegWit,
>     as a simple user. This time, I run my own full node and follow
>     development. I hope to bring something new to the table.
>
>     Having witnessed the miner's unwillingness to activate SegWit truly
>     makes me concerened for a simple LOT=false. After reading the discussion
>     now for some time and thinking about it myself, I have come to the
>     following proposal.
>
>     Initially deploy with LOT=false and an activation threshold of 95% of
>     miner signaling.
>
>     *IFF* after 6 months Taproot is not activated by MASF, BUT at least 80%
>     of hashpower signaled for the upgrade, LOT gets a lock-in date another 6
>     months later and the threshold for MASF is lowered to 90%.
>
>     If after the initial 6 months of signaling with LOT=false, 80% is not
>     reached, the proposal expires.
>
>     This way, a small percent of hashpower does not get to stall activation,
>     rather, 80% of hashpower can activate LOT=true, and later, 90% can
>     activate Taproot. If a flaw is found in Taproot in the first six months
>     (unlikely anyway), miners simply don't signal and the proposal expires.
>     If miners don't signal at all, only six months are lost, before a new
>     activation logic can be deployed.
>
>     Don't mind this if something similar was already proposed somewhere else.
>
>     Best
>
>     Carlo
>
>     ------------------------------------------------------------------------
>
>     bitcoin-dev mailing list
>     bitcoin-dev@lists.linuxfoundation.org
>     https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev  <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>
>

--------------1B3F731BF784D277617C1FEF
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: 7bit

<html>
  <head>
    <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
  </head>
  <body>
    <p>Hi Ariel</p>
    <p>Thanks for your reply with the link to the SMA proposal, which I
      had missed previoulsy. It is indeed very similar. <br>
    </p>
    <p>I see that Speedy trial is currently gaining broad support, which
      is good. I think my proposal with the threshold set to 51% instead
      of 80% to change LOT=false to LOT=true is also pretty similar to
      ST, with the key difference being that the next step after a fail
      of MASF is already baked in.</p>
    <p>Excited to see how it all plays out.</p>
    <p>Best</p>
    <p>Carlo<br>
    </p>
    <pre class="moz-signature" cols="72">Carlo Spiller
+41 79 368 85 06
<a class="moz-txt-link-abbreviated" href="http://www.carlospiller.com">www.carlospiller.com</a></pre>
    <div class="moz-cite-prefix">Am 07.03.21 um 22:13 schrieb Ariel
      Lorenzo-Luaces:<br>
    </div>
    <blockquote type="cite"
      cite="mid:baad4898-6605-4edc-ad13-0f74289484ae@gmail.com">
      <meta http-equiv="content-type" content="text/html; charset=UTF-8">
      <div dir="auto">Hi Carlo<br>
        <br>
      </div>
      <div dir="auto">This your proposal is similar to the Simple
        Majority Activation proposal (SMA). The difference is that your
        proposal has the final activation threshold set to 80% and SMA
        has it set to 51% <a
href="https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-March/018587.html"
          moz-do-not-send="true">https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-March/018587.html</a><br>
        <br>
      </div>
      <div dir="auto">The problem with what you're proposing is what do
        users do if signaling is somewhere between 51% to 79%? Users
        that want to promote a UASF know that their miner majority can
        activate Taproot and activate without the 21% to 49% of miners
        needing to signal (or purposefully stalling). A UASF knows they
        have majority mining power so there is little risk to them and a
        big reward (activating Taproot) so they are incentivized to do a
        UASF.<br>
        <br>
      </div>
      <div dir="auto">A UASF with a miner majority can scare everyone
        else about them being at risk of big reorgs to gain traction and
        followers.<br>
        <br>
      </div>
      <div dir="auto">With the same proposal but the final threshold set
        to 51% instead of 80% there can't be risk of a UASF because if
        51% is not reached they know they don't have enough miner
        support to keep the chain together.<br>
        <br>
      </div>
      <div dir="auto">If support is less than 50% a UASF movement needs
        to hard fork anyway to change the PoW (for protection) and
        change addresses to prevent double spends.<br>
        <br>
      </div>
      <div dir="auto">I really like the SMA proposal with 51% because it
        removes the incentive to do a UASF.<br>
        <br>
      </div>
      <div dir="auto">Cheers<br>
      </div>
      <div dir="auto">Ariel Lorenzo-Luaces<br>
      </div>
      <div class="gmail_quote">On Mar 7, 2021, at 6:37 AM, Carlo Spiller
        via bitcoin-dev &lt;<a
          href="mailto:bitcoin-dev@lists.linuxfoundation.org"
          target="_blank" moz-do-not-send="true">bitcoin-dev@lists.linuxfoundation.org</a>&gt;
        wrote:
        <blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt
          0.8ex; border-left: 1px solid rgb(204, 204, 204);
          padding-left: 1ex;">
          <pre class="blue">Hi everybody

I'm new to this list, but not new to Bitcoin, having skin in the game 
since 2014. I was there for the scaling war and the drama around SegWit, 
as a simple user. This time, I run my own full node and follow 
development. I hope to bring something new to the table.

Having witnessed the miner's unwillingness to activate SegWit truly 
makes me concerened for a simple LOT=false. After reading the discussion 
now for some time and thinking about it myself, I have come to the 
following proposal.

Initially deploy with LOT=false and an activation threshold of 95% of 
miner signaling.

*IFF* after 6 months Taproot is not activated by MASF, BUT at least 80% 
of hashpower signaled for the upgrade, LOT gets a lock-in date another 6 
months later and the threshold for MASF is lowered to 90%.

If after the initial 6 months of signaling with LOT=false, 80% is not 
reached, the proposal expires.

This way, a small percent of hashpower does not get to stall activation, 
rather, 80% of hashpower can activate LOT=true, and later, 90% can 
activate Taproot. If a flaw is found in Taproot in the first six months 
(unlikely anyway), miners simply don't signal and the proposal expires. 
If miners don't signal at all, only six months are lost, before a new 
activation logic can be deployed.

Don't mind this if something similar was already proposed somewhere else.

Best

Carlo

<hr>
bitcoin-dev mailing list
<a class="moz-txt-link-abbreviated" href="mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@lists.linuxfoundation.org</a>
<a href="https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" moz-do-not-send="true">https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev</a>
</pre>
        </blockquote>
      </div>
    </blockquote>
  </body>
</html>

--------------1B3F731BF784D277617C1FEF--