public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
From: Emil Pfeffer <emu@emuadmin•com>
To: Luke Dashjr <luke@dashjr•org>,
	Bitcoin Protocol Discussion
	<bitcoin-dev@lists•linuxfoundation.org>
Subject: Re: [bitcoin-dev] Taproot activation meeting on IRC - Tuesday 16th March 19:00 UTC
Date: Tue, 16 Mar 2021 17:42:33 +0000	[thread overview]
Message-ID: <20210316174233.pfby4grwz5cudjqb@www01.emuadmin.com> (raw)
In-Reply-To: <202103151720.04687.luke@dashjr.org>

On Mon, Mar 15, 2021 at 05:20:04PM +0000, Luke Dashjr via bitcoin-dev wrote:
> At the previous meeting, there was consensus for BIP8 activation parameters 
> except for LOT, assuming a release around this time. Since then, a release 
> has not occurred, and the new idea of Speedy Trial has been proposed to 
> preempt the original/main activation plan.
> 
> It's probably a good idea to meet up again to discuss these things and adjust 
> accordingly.
> 
> Agenda:
> 
> - Speedy Trial: Can we get a comparable consensus on the proposal?
>   (Note: current draft conflicts with original plan timeline)

Definitely not. This looks like a hijacking attempt.
We are already bombarded with too much information, the last thing we need is
a rushed upgrade. Even if it works out it is not a good precedent.
The current timeline of 18 months if the minimum that is acceptable for upgrades
such as taproot. We're not changing things that we worked out already. What next?
and how long till we go back and change the coin supply?  
I understand some of you have no patience and would like mass adoption tomorrow
but those are exactly the people that do not have a say in Bitcoin development.
if you want to get rich quick you do not care about Bitcoin. If you want faster
development cycles then you have lightning to play with. 
I have to reiterate: we *DO NOT* change things we already established in the past.
There are reasons everything is as it is and if you want to develop Bitcoin you have
to build upon the already established rules.


> - Main activation, post ST: Moving startheight (and timeoutheight?) later
>   is probably a good idea at this point, both because too little progress has
>   been made on it, and to avoid the conflict with the current ST draft.

There is no conflict. We're not upgrading Bitcoin using fancy new tools.
We're still on track with the already established timeline. 
Although one is better than the other it doesn't really matter because we know
which way is going to go. In order to solve the LOT debate lets give Wladimir the
power to decide on his own and if he has no strong opinions he should just flip a coin.
the MAST threshold can be even lower because it is not representative of an economic
majority and it could speed up the upgrade.

> 
> - Making progress: To date, too few people have been involved in materialising
>   the main activation plan. If it's going to move forward, more people need to
>   get actively involved. This should not wait for ST to complete, unless we
>   want another 4-5 month slip of the timeline.

Nope. This is not the time where people need to get involved. There is no need for 
more noise. People will get involved progressivly as time advances but as long
as Core does not release the parameters of the game there are no incentives for
the actors that will play the Taproot upgrade to show up. If Taproot is what the
market wants then the game theoretics of Bitcoin will get us there but since an
upgrade essentially means a change in consensus then some disturbance is expected and guaranteed. 
At this point involve as few people as possible and get it done. This is just about
the software and the parameters of the new consesus. Theres plenty of time
for the show that's about to come, the market will do what the market does.

Worst case scenario Luke get some people behind and fork off Core with LOT=true and
lower MAST threshold. The market wants to play.

> 
> This meeting is tentatively scheduled for *tomorrow*, March 16th at the usual 
> time of 19:00 UTC, in freenode's ##Taproot-activation IRC channel. If turnout 
> is too low, we can postpone it a week, but it'd be nice to get things 
> resolved and moving sooner.
> 
> As a reminder, the channel is also open for ongoing discussion 24/7, and there 
> is a web chat client here:
> 
> https://webchat.freenode.net/?channel=##taproot-activation
> 
> Luke
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists•linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

-- 


  parent reply	other threads:[~2021-03-16 17:42 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-03-15 17:20 Luke Dashjr
2021-03-15 19:14 ` Jeremy
2021-03-15 19:37   ` Luke Dashjr
2021-03-15 20:59     ` Jeremy
2021-03-15 21:46       ` Luke Dashjr
2021-03-16 17:42 ` Emil Pfeffer [this message]
2021-03-17  8:21 Prayank
2021-03-19 10:45 ` Emil Pfeffer
2021-03-19 16:55   ` Prayank

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=20210316174233.pfby4grwz5cudjqb@www01.emuadmin.com \
    --to=emu@emuadmin$(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