public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
From: Carlo Spiller <carlo@spiller.com>
To: bitcoin-dev@lists.linuxfoundation.org
Subject: [bitcoin-dev] Yet another Taproot activation logic
Date: Sun, 7 Mar 2021 10:58:30 +0100	[thread overview]
Message-ID: <5a779c13-8ebf-5052-5bf7-846f970c21ef@spiller.com> (raw)

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



             reply	other threads:[~2021-03-07 13:33 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-03-07  9:58 Carlo Spiller [this message]
2021-03-07 21:13 ` [bitcoin-dev] Yet another Taproot activation logic Ariel Lorenzo-Luaces
2021-03-08  8:24   ` Carlo Spiller

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=5a779c13-8ebf-5052-5bf7-846f970c21ef@spiller.com \
    --to=carlo@spiller.com \
    --cc=bitcoin-dev@lists.linuxfoundation.org \
    /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