public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
From: Matt Corallo <lf-lists@mattcorallo.com>
To: Ariel Lorenzo-Luaces <arielluaces@gmail.com>,
	Bitcoin Protocol Discussion
	<bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Yesterday's Taproot activation meeting on lockinontimeout (LOT)
Date: Sun, 21 Feb 2021 09:30:45 -0500	[thread overview]
Message-ID: <4A6F5D19-DF75-4C83-A435-53B6EAABD85F@mattcorallo.com> (raw)
In-Reply-To: <b5d23fb8-06a8-4dda-bdbb-2247a82fa1a0@gmail.com>

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

I don’t think “some vocal users are going to threaten to fork themselves off” is good justification for technical decisions. It’s important to communicate and for everyone to agree/understand that a failed BIP 8/9 activation, in the scenario people are worried about, is not the end of the story for Taproot activation. If it is clear that Taproot has broad consensus but some miners failed to upgrade in time (as it presumably would be), a flag day activation seems merited and I’m not sure anyone has argued against this. That said, forced-signaling via a UASF/BIP8(true)-style fork carries material additional risk that a classic flag-day activation does not, so let’s not optimize for something like that.

Matt

> On Feb 21, 2021, at 08:26, Ariel Lorenzo-Luaces via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org> wrote:
> 
> 
> What would be the tradeoffs of a BIP8(false, ∞) option? That would remove some of the concerns of having to coordinate a UASF with an approaching deadline.
> 
> Cheers
> Ariel Lorenzo-Luaces
>> On Feb 19, 2021, at 6:55 PM, ZmnSCPxj via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org> wrote:
>> Good morning list,
>> 
>>>  It was pointed out to me that this discussion is largely moot as the software complexity for Bitcoin Core to ship an
>>>  option like this is likely not practical/what people would wish to see.
>>> 
>>>  Bitcoin Core does not have infrastructure to handle switching consensus rules with the same datadir - after running with
>>>  uasf=true for some time, valid blocks will be marked as invalid, and additional development would need to occur to
>>>  enable switching back to uasf=false. This is complex, critical code to get right, and the review and testing cycles
>>>  needed seem to be not worth it.
>> 
>> Without implying anything else, this can be worked around by a user maintaining two `datadir`s and running two clients.
>> This would have an "external" client running an LOT=X (where X is whatever the user prefers) and an "internal" client that is at most 0.21.0, which will not impose any LOT rules.
>> The internal client then uses `connect=` directive to connect locally to the external client and connects only to that client, using it as a firewall.
>> The external client can be run pruned in order to reduce diskspace resource usage (the internal client can remain unpruned if that is needed by the user, e.g. for LN implementation sthat need to look up arbitrary short-channel-ids).
>> Bandwidth usage should be same since the internal client only connects to the external client and the OS should optimize that case.
>> CPU usage is doubled, though.
>> 
>> (the general idea came from gmax, just to be clear, though the below use is from me)
>> 
>> Then the user can select LOT=C or LOT=!C (where C is whatever Bitcoin Core ultimately ships with) on the external client based on the user preferences.
>> 
>> If Taproot is not MASF-activated and LOT=!U is what dominates later (where U is whatever the user decided on), the user can decide to just destroy the external node and connect the internal node directly to the network (optionally upgrading the internal node to LOT=!U) as a way to "change their mind in view of the economy".
>> The internal node will then follow the dominant chain.
>> 
>> 
>> Regards,
>> ZmnSCPxj
>> 
>>> 
>>>  Instead, the only practical way to ship such an option would be to treat it as a separate chain (the same way regtest,
>>>  testnet, and signet are treated), including its own separate datadir and the like.
>>> 
>>>  Matt
>>> 
>>>>  On 2/19/21 09:13, Matt Corallo via bitcoin-dev wrote:
>>>> 
>>>>  (Also in response to ZMN...)
>>>>  Bitcoin Core has a long-standing policy of not shipping options which shoot yourself in the foot. I’d be very disappointed if that changed now. People are of course more than welcome to run such software themselves, but I anticipate the loud minority on Twitter and here aren’t processing enough transactions or throwing enough financial weight behind their decision for them to do anything but just switch back if they find themselves on a chain with no blocks.
>>>>  There’s nothing we can (or should) do to prevent people from threatening to (and possibly) forking themselves off of bitcoin, but that doesn’t mean we should encourage it either. The work Bitcoin Core maintainers and developers do is to recommend courses of action which they believe have reasonable levels of consensus and are technically sound. Luckily, there’s strong historical precedent for people deciding to run other software around forks, so misinterpretation is not very common (just like there’s strong historical precedent for miners not unilaterally deciding forks in the case of Segwit).
>>>>  Matt
>>>> 
>>>>>>  On Feb 19, 2021, at 07:08, Adam Back adam@cypherspace.org wrote:
>>>>>> 
>>>>>>  would dev consensus around releasing LOT=false be considered as "developers forcing their views on users"?
>>>>> 
>>>>>  given there are clearly people of both views, or for now don't care
>>>>>  but might later, it would minimally be friendly and useful if
>>>>>  bitcoin-core has a LOT=true option - and that IMO goes some way to
>>>>>  avoid the assumptive control via defaults.
>>>> 
>>>>>  Otherwise it could be read as saying "developers on average
>>>>>  disapprove, but if you, the market disagree, go figure it out for
>>>>>  yourself" which is not a good message for being defensive and avoiding
>>>>>  mis-interpretation of code repositories or shipped defaults as
>>>>>  "control".
>>>> 
>>>>  bitcoin-dev mailing list
>>>>  bitcoin-dev@lists.linuxfoundation.org
>>>>  https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>> 
>> 
>> 
>> bitcoin-dev mailing list
>> bitcoin-dev@lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

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

  reply	other threads:[~2021-02-21 14:30 UTC|newest]

Thread overview: 42+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-02-17 12:51 [bitcoin-dev] Yesterday's Taproot activation meeting on lockinontimeout (LOT) Michael Folkson
2021-02-18  5:43 ` Ariel Lorenzo-Luaces
2021-02-18 11:01   ` Michael Folkson
2021-02-18 11:11     ` Samson Mow
2021-02-18 11:52       ` ZmnSCPxj
2021-02-18 12:20         ` Michael Folkson
2021-02-18 14:01           ` Matt Corallo
2021-02-18 14:26             ` Michael Folkson
2021-02-18 14:42               ` Matt Corallo
2021-02-18 14:51                 ` Michael Folkson
2021-02-18 14:53                   ` Matt Corallo
2021-02-18 15:01                     ` Matt Corallo
2021-02-18 15:04                 ` Keagan McClelland
2021-02-18 15:18                   ` Matt Corallo
2021-02-19  2:20                     ` Ariel Luaces
2021-02-19 11:30                     ` ZmnSCPxj
2021-02-19 12:05                       ` Adam Back
2021-02-19 14:13                         ` Matt Corallo
2021-02-19 17:48                           ` Matt Corallo
2021-02-20  2:55                             ` ZmnSCPxj
2021-02-20 17:20                               ` Ariel Lorenzo-Luaces
2021-02-21 14:30                                 ` Matt Corallo [this message]
2021-02-22  5:16                             ` Anthony Towns
2021-02-22  6:44                               ` Matt Corallo
2021-02-22 10:16                                 ` Anthony Towns
2021-02-22 14:00                                   ` Matt Corallo
2021-02-22 16:27                                     ` Anthony Towns
2021-02-22 16:31                                     ` Jorge Timón
2021-02-22 16:48                                       ` Jorge Timón
2021-02-23  2:10                                         ` Jeremy
2021-02-23 19:33                                           ` Keagan McClelland
2021-02-23 23:14                                             ` Ben Woosley
2021-02-24 22:37                                             ` Ariel Luaces
2021-03-01 13:54                                               ` Erik Aronesty
2021-03-02 18:32                                                 ` Ariel Lorenzo-Luaces
2021-02-24  7:18                                           ` Anthony Towns
2021-02-18 13:59         ` Matt Corallo
2021-02-21 16:21 ` Erik Aronesty
2021-02-19 22:12 Matt Hill
2021-02-19 23:30 ` Matt Corallo
2021-02-19 23:42   ` Bryan Bishop
2021-02-21 10:10 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=4A6F5D19-DF75-4C83-A435-53B6EAABD85F@mattcorallo.com \
    --to=lf-lists@mattcorallo.com \
    --cc=arielluaces@gmail.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