npub1ac…lswfj

📅 Original date posted:2021-02-19
📝 Original message:Personally I don't really have much of a view and think either
LOT=true or false is better in the context, they both seem safe given
the current context, where basically everyone is saying "are we there
yet", including pools (88.7% going out of their way to say YES
https://taprootactivation.com). Not that pools are deciding of
anything, being service providers to miners, who can and will switch
pool fast, and miners in-turn being service providers to the market
and as the various forks showed will follow the market.
I think it's a very good idea for safety, if there is a tested and
reviewed code with an option to force LOT=true, even if the
bitcoin-core implementation ends up defaulting to LOT=false.
Part of the danger is rushed versions of things like BIP 91 to avoid a
chain split where miners left brinkmanship just a bit too late, to
avert BIP 148 forking, and BIP 91 was used to expedite activation to
avoid that. The rushed proposal, code, review, ship cycle on that was
dangerously fast - less time and eyes for review was the danger.
> 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".
Adam
On Fri, 19 Feb 2021 at 11:30, ZmnSCPxj via bitcoin-dev
<bitcoin-dev at lists.linuxfoundation.org> wrote:
>
> Good morning list,
>
> > This is absolutely the case, however note that the activation method itself is consensus code which executes as a part
> > of a fork, and one which deserves as much scrutiny as anything else. While taproot is a model of how a soft-fork should
> > be designed, this doesn't imply anything about the consensus code which represents the activation thereof.
> >
> > Hence all the debate around activation - ultimately its also defining a fork, and given the politics around it, one
> > which almost certainly carries significantly more risk than Taproot.
> >
> > Note that I don't believe anyone is advocating for "try to activate, and if it fails, move on". Various people have
> > various views on how conservative and timelines for what to do at that point, but I believe most in this discussion are
> > OK with flag-day-based activation (given some level of care) if it becomes clear Taproot is supported by a vast majority
> > of Bitcoin users and is only not activating due to lagging miner upgrades.
>
>
> Okay, I am backing off this proposal to force the LOT=false/true decision on users, it was not particularly serious anyway (and was more a reaction to the request of Samson Mow to just release both versions, which to my mind is no different from such a thing).
>
>
> Nonetheless, as a thought experiment: the main issue is that some number of people run LOT=true when miners do not activate Taproot early for some reason and we decide to leave LOT=false for this particular bit until it times out.
> The issue is that those people will get forked off the network at the end of this particular deployment attempt.
>
> I suspect those people will still exist whether or not Bitcoin Core supports any kind of LOT=true mode.
> ("Never again" for some people)
>
> How do we convince them to go run LOT=false instead of getting themselves forked off?
> Or do we simply let them?
>
> (and how is that different from asking each user to decide on LOT=false/true right now?)
> ("reasonable default"?)
> (fundamentally speaking you still have to educate the users on the ramifications of accepting the default and changing it.)
>
>
> Another thought experiment: From the point of view of a user who strongly supports LOT=true, would dev consensus around releasing LOT=false be considered as "developers forcing their views on users"?
> Why or why not?
>
>
> Regards,
> ZmnSCPxj
>
> > Matt
> >
> > On 2/18/21 10:04, Keagan McClelland wrote:
> >
> > > Hi all,
> > > I think it's important for us to consider what is actually being considered for activation here.
> > > The designation of "soft fork" is accurate but I don't think it adequately conveys how non-intrusive a change like this
> > > is. All that taproot does (unless I'm completely missing something) is imbue a previously undefined script version with
> > > actual semantics. In order for a chain reorg to take place it would mean that someone would have to have a use case for
> > > that script version today. This is something I think that we can easily check by digging through the UTXO set or
> > > history. If anyone is using that script version, we absolutely should not be using it, but that doesn't mean that we
> > > can't switch to a script version that no one is actually using.
> > > If no one is even attempting to use the script version, then the change has no effect on whether a chain split occurs
> > > because there is simply no block that contains a transaction that only some of the network will accept.
> > > Furthermore, I don't know how Bitcoin can stand the test of time if we allow developers who rely on "undefined behavior"
> > > (which the taproot script version presently is) to exert tremendous influence over what code does or does not get run.
> > > This isn't a soft fork that makes some particular UTXO's unspendable. It isn't one that bans miners from collecting
> > > fees. It is a change that means that certain "always accept" transactions actually have real conditions you have to
> > > meet. I can't imagine a less intrusive change.
> > > On the other hand, choosing to let L=F be a somewhat final call sets a very real precedent that 10% of what I estimate
> > > to be 1% of bitcoin users can effectively block any change from here on forward. At that point we are saying that miners
> > > are in control of network consensus in ways they have not been up until now. I don't think this is a more desirable
> > > outcome to let ~0.1% of the network get to block /non-intrusive/ changes that the rest of the network wants.
> > > I can certainly live with an L=F attempt as a way to punt on the discussion, maybe the activation happens and this will
> > > all be fine. But if it doesn't, I hardly think that users of Bitcoin are just going to be like "well, guess that's it
> > > for Taproot". I have no idea what ensues at that point, but probably another community led UASF movement.
> > > I wasn't super well educated on this stuff back in '17 when Segwit went down, as I was new at that time, so if I'm
> > > missing something please say so. But from my point of view, we can't treat all soft forks as equal.
> > > Keagan
> > > On Thu, Feb 18, 2021 at 7:43 AM Matt Corallo via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org
> > > mailto:bitcoin-dev at lists.linuxfoundation.org> wrote:
> > >
> > > We've had several softforks in Bitcoin which, through the course of their activation, had a several-block reorg. That
> > > should be indication enough that we need to very carefully consider activation to ensure we reduce the risk of that as
> > > much as absolutely possible. Again, while I think Taproot is a huge improvement and am looking forward to being able to
> > > use it, getting unlucky and hitting a 4-block reorg that happens to include a double-spend and some PR around an
> > > exchange losing millions would be worse than having Taproot is good.
> > >
> > > Matt
> > >
> > > On 2/18/21 09:26, Michael Folkson wrote:
> > > > Thanks for your response Matt. It is a fair challenge. There is always going to be an element of risk with soft
> > > forks,
> > > > all we can do is attempt to minimize that risk. I would argue that risk has been minimized for Taproot.
> > > >
> > > > You know (better than I do in fact) that Bitcoin (and layers built on top of it) greatly benefit from upgrades
> > > such as
> > > > Taproot. To say we shouldn't do Taproot or any future soft forks because there is a small but real risk of chain
> > > splits
> > > > I think is shortsighted. Indeed I think even if we collectively decided not to do any future soft fork upgrades ever
> > > > again on this mailing list that wouldn't stop soft fork attempts from other people in future.
> > > >
> > > > I don't think there is anything else we can do to minimize that risk for the Taproot soft fork at this point
> > > though I'm
> > > > open to ideas. To reiterate that risk will never be zero. I don't think I see Bitcoin as fragile as you seem to
> > > (though
> > > > admittedly you have a much better understanding than me of what happened in 2017).
> > > >
> > > > The likely scenario for the Taproot soft fork is LOT turns out to be entirely irrelevant and miners activate Taproot
> > > > before it becomes relevant. And even the unlikely worst case scenario would only cause short term disruption and
> > > > wouldn't kill Bitcoin long term.
> > > >
> > > > On Thu, Feb 18, 2021 at 2:01 PM Matt Corallo <lf-lists at mattcorallo.com <mailto:lf-lists at mattcorallo.com>
> > > <mailto:lf-lists at mattcorallo.com <mailto:lf-lists at mattcorallo.com>>> wrote:
> > > >
> > > > If the eventual outcome is that different implementations (that have material *transaction processing* userbases,
> > > > and I’m not sure to what extent that’s true with Knots) ship different consensus rules, we should stop here
> > > and not
> > > > activate Taproot. Seriously.
> > > >
> > > > Bitcoin is a consensus system. The absolute worst outcome at all possible is to have it fall out of consensus.
> > > >
> > > > Matt
> > > >
> > > >> On Feb 18, 2021, at 08:11, Michael Folkson via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org
> > > <mailto:bitcoin-dev at lists.linuxfoundation.org>
> > > >> <mailto:bitcoin-dev at lists.linuxfoundation.org <mailto:bitcoin-dev at lists.linuxfoundation.org>>> wrote:
> > > >>
> > > >>
> > > >> Right, that is one option. Personally I would prefer a Bitcoin Core release sets LOT=false (based on what I have
> > > >> heard from Bitcoin Core contributors) and a community effort releases a version with LOT=true. I don't think
> > > users
> > > >> should be forced to choose something they may have no context on before they are allowed to use Bitcoin Core.
> > > >>
> > > >> My current understanding is that roasbeef is planning to set LOT=false on btcd (an alternative protocol
> > > >> implementation to Bitcoin Core) and Luke Dashjr hasn't yet decided on Bitcoin Knots.
> > > >>
> > > >>
> > > >>
> > > >> On Thu, Feb 18, 2021 at 11:52 AM ZmnSCPxj <ZmnSCPxj at protonmail.com <mailto:ZmnSCPxj at protonmail.com>
> > > <mailto:ZmnSCPxj at protonmail.com <mailto:ZmnSCPxj at protonmail.com>>> wrote:
> > > >>
> > > >> Good morning all,
> > > >>
> > > >> > "An activation mechanism is a consensus change like any other change, can be contentious like any other
> > > >> change, and we must resolve it like any other change. Otherwise we risk arriving at the darkest timeline."
> > > >> >
> > > >> > Who's we here?
> > > >> >
> > > >> > Release both and let the network decide.
> > > >>
> > > >> A thing that could be done, without mandating either LOT=true or LOT=false, would be to have a release that
> > > >> requires a `taprootlot=1` or `taprootlot=0` and refuses to start if the parameter is not set.
> > > >>
> > > >> This assures everyone that neither choice is being forced on users, and instead what is being forced on
> > > users,
> > > >> is for users to make that choice themselves.
> > > >>
> > > >> Regards,
> > > >> ZmnSCPxj
> > > >>
> > > >> >
> > > >> > On Thu, Feb 18, 2021 at 3:08 AM Michael Folkson via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org
> > > <mailto:bitcoin-dev at lists.linuxfoundation.org>
> > > >> <mailto:bitcoin-dev at lists.linuxfoundation.org <mailto:bitcoin-dev at lists.linuxfoundation.org>>> wrote:
> > > >> >
> > > >> > > Thanks for your response Ariel. It would be useful if you responded to specific points I have made
> > > in the
> > > >> mailing list post or at least quote these ephemeral "people" you speak of. I don't know if you're responding
> > > >> to conversation on the IRC channel or on social media etc.
> > > >> > >
> > > >> > > > The argument comes from a naive assumption that users MUST upgrade to the choice that is submitted
> > > into
> > > >> code. But in fact this isn't true and some voices in this discussion need to be more humble about what users
> > > >> must or must not run.
> > > >> > >
> > > >> > > I personally have never made this assumption. Of course users aren't forced to run any particular
> > > software
> > > >> version, quite the opposite. Defaults set in software versions matter though as many users won't change
> > > them.
> > > >> > >
> > > >> > > > Does no one realize that it is a very possible outcome that if LOT=true is released there may be
> > > only a
> > > >> handful of people that begin running it while everyone else delays their upgrade (with the very good
> > > reason of
> > > >> not getting involved in politics) and a year later those handful of people just become stuck at the
> > > moment of
> > > >> MUST_SIGNAL, unable to mine new blocks?
> > > >> > >
> > > >> > > It is a possible outcome but the likely outcome is that miners activate Taproot before LOT is even
> > > >> relevant. I think it is prudent to prepare for the unlikely but possible outcome that miners fail to
> > > activate
> > > >> and hence have this discussion now rather than be unprepared for that eventuality. If LOT is set to
> > > false in a
> > > >> software release there is the possibility (T2 in
> > > >> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-February/018380.html
> > > <https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-February/018380.html>
> > > >> <https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-February/018380.html
> > > <https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-February/018380.html>>) of individuals or a
> > > >> proportion of the community changing LOT to true. In that sense setting LOT=false in a software release
> > > >> appears to be no more safe than LOT=true.
> > > >> > >
> > > >> > > > The result: a wasted year of waiting and a minority of people who didn't want to be lenient with
> > > miners
> > > >> by default.
> > > >> > >
> > > >> > > There is the (unlikely but possible) possibility of a wasted year if LOT is set to false and miners fail
> > > >> to activate. I'm not convinced by this perception that LOT=true is antagonistic to miners. I actually
> > > think it
> > > >> offers them clarity on what will happen over a year time period and removes the need for coordinated or
> > > >> uncoordinated community UASF efforts on top of LOT=false.
> > > >> > >
> > > >> > > > An activation mechanism is a consensus change like any other change, can be contentious like any other
> > > >> change, and we must resolve it like any other change. Otherwise we risk arriving at the darkest timeline.
> > > >> > >
> > > >> > > I don't know what you are recommending here to avoid "this darkest timeline". Open discussions have
> > > >> occurred and are continuing and in my mailing list post that you responded to **I recommended we propose
> > > >> LOT=false be set in protocol implementations such as Bitcoin Core**. I do think this apocalyptic language
> > > >> isn't particularly helpful. In an open consensus system discussion is healthy, we should prepare for bad or
> > > >> worst case scenarios in advance and doing so is not antagonistic or destructive. Mining pools have pledged
> > > >> support for Taproot but we don't build secure systems based on pledges of support, we build them to minimize
> > > >> trust in any human actors. We can be grateful that people like Alejandro have worked hard on
> > > >> taprootactivation.com <http://taprootactivation.com> <http://taprootactivation.com
> > > <http://taprootactivation.com>> (and this effort has informed the discussion) without
> > > >> taking pledges of support as cast iron guarantees.
> > > >> > >
> > > >> > > TL;DR It sounds like you agree with my recommendation to set LOT=false in protocol implementations in my
> > > >> email :)
> > > >> > >
> > > >> > > On Thu, Feb 18, 2021 at 5:43 AM Ariel Lorenzo-Luaces <arielluaces at gmail.com
> > > <mailto:arielluaces at gmail.com>
> > > >> <mailto:arielluaces at gmail.com <mailto:arielluaces at gmail.com>>> wrote:
> > > >> > >
> > > >> > > > Something what strikes me about the conversation is the emotion surrounding the letters UASF.
> > > >> > > > It appears as if people discuss UASF as if it's a massive tidal wave of support that is
> > > inevitable, like
> > > >> we saw during segwit activation. But the actual definition is "any activation that is not a MASF".
> > > >> > > > A UASF can consist of a single node, ten nodes, a thousand, half of all nodes, all business' nodes, or
> > > >> even all the non mining nodes. On another dimension it can have zero mining support, 51% support, 49%
> > > support,
> > > >> or any support right up against a miner activation threshold.
> > > >> > > > Hell a UASF doesn't even need code or even a single node running as long as it exists as a possibility
> > > >> in people's minds.
> > > >> > > > The only thing a UASF doesn't have is miner support above an agreed activation threshold (some number
> > > >> above %51).
> > > >> > > > I say this because it strikes me when people say that they are for LOT=true with the logic that
> > > since a
> > > >> UASF is guaranteed to happen then it's better to just make it default from the beginning. Words like
> > > >> coordination and safety are sometimes sprinkled into the argument.
> > > >> > > > The argument comes from a naive assumption that users MUST upgrade to the choice that is submitted
> > > into
> > > >> code. But in fact this isn't true and some voices in this discussion need to be more humble about what users
> > > >> must or must not run.
> > > >> > > > Does no one realize that it is a very possible outcome that if LOT=true is released there may be
> > > only a
> > > >> handful of people that begin running it while everyone else delays their upgrade (with the very good
> > > reason of
> > > >> not getting involved in politics) and a year later those handful of people just become stuck at the
> > > moment of
> > > >> MUST_SIGNAL, unable to mine new blocks? Or attracting a minority of miners, activating, and forking off
> > > into a
> > > >> minority fork. Then a lot=false could be started that ends up activating the feature now that the stubborn
> > > >> option has ran its course.
> > > >> > > > The result: a wasted year of waiting and a minority of people who didn't want to be lenient with
> > > miners
> > > >> by default. The chains could be called BitcoinLenient and BitcoinStubborn.
> > > >> > > > How is that strictly safer or more coordinated?
> > > >> > > > I may be in the minority, or maybe a silent majority, or maybe a majority that just hasn't considered
> > > >> this as a choice but honestly if there is contention about whether we're going to be stubborn or lenient
> > > with
> > > >> miners for Taproot and in the future then I prefer to just not activate anything at all. I'm fine for
> > > calling
> > > >> bitcoin ossified, accepting that segwit is Bitcoin's last network upgrade. Taproot is amazing but no new
> > > >> feature is worth a network split down the middle.
> > > >> > > > Maybe in 10 or 20 years, when other blockchains implement features like Taproot and many more, we will
> > > >> become envious enough to put aside our differences on how to behave towards miners and finally activate
> > > Taproot.
> > > >> > > > An activation mechanism is a consensus change like any other change, can be contentious like any other
> > > >> change, and we must resolve it like any other change. Otherwise we risk arriving at the darkest timeline.
> > > >> > > > Cheers
> > > >> > > > Ariel Lorenzo-Luaces
> > > >> > > > On Feb 17, 2021, at 7:05 AM, Michael Folkson via bitcoin-dev
> > > <bitcoin-dev at lists.linuxfoundation.org <mailto:bitcoin-dev at lists.linuxfoundation.org>
> > > >> <mailto:bitcoin-dev at lists.linuxfoundation.org <mailto:bitcoin-dev at lists.linuxfoundation.org>>> wrote:
> > > >> > > >
> > > >> > > > > Yesterday (February 16th) we held a second meeting on Taproot
> > > >> > > > > activation on IRC which again was open to all. Despite what appeared
> > > >> > > > > to be majority support for LOT=false over LOT=true in the first
> > > >> > > > > meeting I (and others) thought the arguments had not been explored in
> > > >> > > > > depth and that we should have a follow up meeting almost entirely
> > > >> > > > > focused on whether LOT (lockinontimeout) should be set to true or
> > > >> > > > > false.
> > > >> > > > >
> > > >> > > > > The meeting was announced here:
> > > >> > > > > https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-February/018380.html
> > > <https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-February/018380.html>
> > > >> <https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-February/018380.html
> > > <https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-February/018380.html>>
> > > >> > > > >
> > > >> > > > > In that mailing list post I outlined the arguments for LOT=true (T1 to
> > > >> > > > > T6) and arguments for LOT=false (F1 to F6) in their strongest form I
> > > >> > > > > could. David Harding responded with an additional argument for
> > > >> > > > > LOT=false (F7) here:
> > > >> > > > > https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-February/018415.html
> > > <https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-February/018415.html>
> > > >> <https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-February/018415.html
> > > <https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-February/018415.html>>
> > > >> > > > >
> > > >> > > > > These meetings are very challenging given they are open to all, you
> > > >> > > > > don’t know who will attend and you don’t know most people’s views in
> > > >> > > > > advance. I tried to give time for both the LOT=true arguments and the
> > > >> > > > > LOT=false arguments to be discussed as I knew there was support for
> > > >> > > > > both. We only tried evaluating which had more support and which had
> > > >> > > > > more strong opposition towards the end of the meeting.
> > > >> > > > >
> > > >> > > > > The conversation log is here:
> > > >> > > > > http://gnusha.org/taproot-activation/2021-02-16.log
> > > <http://gnusha.org/taproot-activation/2021-02-16.log> <http://gnusha.org/taproot-activation/2021-02-16.log
> > > <http://gnusha.org/taproot-activation/2021-02-16.log>>
> > > >> > > > >
> > > >> > > > > (If you are so inclined you can watch a video of the meeting here.
> > > >> > > > > Thanks to the YouTube account “Bitcoin” for setting up the livestream:
> > > >> > > > > https://www.youtube.com/watch?v=vpl5q1ovMLM <https://www.youtube.com/watch?v=vpl5q1ovMLM>
> > > <https://www.youtube.com/watch?v=vpl5q1ovMLM <https://www.youtube.com/watch?v=vpl5q1ovMLM>>)
> > > >> > > > >
> > > >> > > > > A summary of the meeting was provided by Luke Dashjr on Mastodon here:
> > > >> > > > > https://bitcoinhackers.org/@lukedashjr/105742918779234566
> > > <https://bitcoinhackers.org/@lukedashjr/105742918779234566>
> > > >> <https://bitcoinhackers.org/@lukedashjr/105742918779234566
> > > <https://bitcoinhackers.org/@lukedashjr/105742918779234566>>
> > > >> > > > >
> > > >> > > > > Today's #Bitcoin #Taproot meeting was IMO largely unproductive, but we
> > > >> > > > > did manage to come to consensus on everything but LockinOnTimeout.
> > > >> > > > >
> > > >> > > > > Activation height range: 693504-745920
> > > >> > > > >
> > > >> > > > > MASF threshold: 1815/2016 blocks (90%)
> > > >> > > > >
> > > >> > > > > Keep in mind only ~100 people showed for the meetings, hardly
> > > >> > > > > representative of the entire community.
> > > >> > > > >
> > > >> > > > > So, these details remain JUST a proposal for now.
> > > >> > > > >
> > > >> > > > > It seems inevitable that there won't be consensus on LOT.
> > > >> > > > >
> > > >> > > > > Everyone will have to choose for himself. :/
> > > >> > > > >
> > > >> > > > > Personally I agree with most of this. I agree that there wasn’t
> > > >> > > > > overwhelming consensus for either LOT=true or LOT=false. However, from
> > > >> > > > > my perspective there was clearly more strong opposition (what would
> > > >> > > > > usually be deemed a NACK in Bitcoin Core review terminology) from
> > > >> > > > > Bitcoin Core contributors, Lightning developers and other community
> > > >> > > > > members against LOT=true than there was for LOT=false. Andrew Chow
> > > >> > > > > tried to summarize views from the meeting in this analysis:
> > > >> > > > > https://gist.github.com/achow101/3e179501290abb7049de198d46894c7c
> > > <https://gist.github.com/achow101/3e179501290abb7049de198d46894c7c>
> > > >> <https://gist.github.com/achow101/3e179501290abb7049de198d46894c7c
> > > <https://gist.github.com/achow101/3e179501290abb7049de198d46894c7c>>
> > > >> > > > >
> > > >> > > > > I am also aware of other current and previous Bitcoin Core
> > > >> > > > > contributors and Lightning developers who didn’t attend the meeting in
> > > >> > > > > person who are opposed to LOT=true. I don’t want to put them in the
> > > >> > > > > spotlight for no reason but if you go through the conversation logs of
> > > >> > > > > not only the meeting but the weeks of discussion prior to this meeting
> > > >> > > > > you will see their views evaluated on the ##taproot-activation
> > > >> > > > > channel. In addition, on taprootactivation.com <http://taprootactivation.com>
> > > <http://taprootactivation.com <http://taprootactivation.com>> some mining pools
> > > >> > > > > expressed a preference for lot=false though I don’t know how strong
> > > >> > > > > that preference was.
> > > >> > > > >
> > > >> > > > > I am only one voice but it is my current assessment that if we are to
> > > >> > > > > attempt to finalize Taproot activation parameters and propose them to
> > > >> > > > > the community at this time our only option is to propose LOT=false.
> > > >> > > > > Any further delay appears to me counterproductive in our collective
> > > >> > > > > aim to get the Taproot soft fork activated as early as possible.
> > > >> > > > >
> > > >> > > > > Obviously others are free to disagree with that assessment and
> > > >> > > > > continue discussions but personally I will be attempting to avoid
> > > >> > > > > those discussions unless prominent new information comes to light or
> > > >> > > > > various specific individuals change their minds.
> > > >> > > > >
> > > >> > > > > Next week we are planning a code review of the Bitcoin Core PR #19573
> > > >> > > > > which was initially delayed because of this LOT discussion. As I’ve
> > > >> > > > > said previously that will be loosely following the format of the
> > > >> > > > > Bitcoin Core PR review club and will be lower level and more
> > > >> > > > > technical. That is planned for Tuesday February 23rd at 19:00 UTC on
> > > >> > > > > the IRC channel ##taproot-activation.
> > > >> > > > >
> > > >> > > > > Thanks to the meeting participants (and those who joined the
> > > >> > > > > discussion on the channel prior and post the meeting) for engaging
> > > >> > > > > productively and in good faith.
> > > >> > >
> > > >> > > --
> > > >> > > Michael Folkson
> > > >> > > Email: michaelfolkson at gmail.com <mailto:michaelfolkson at gmail.com> <mailto:michaelfolkson at gmail.com
> > > <mailto:michaelfolkson at gmail.com>>
> > > >> > > Keybase: michaelfolkson
> > > >> > > PGP: 43ED C999 9F85 1D40 EAF4 9835 92D6 0159 214C FEE3
> > > >> > > _______________________________________________
> > > >> > > bitcoin-dev mailing list
> > > >> > > bitcoin-dev at lists.linuxfoundation.org <mailto:bitcoin-dev at lists.linuxfoundation.org>
> > > <mailto:bitcoin-dev at lists.linuxfoundation.org <mailto:bitcoin-dev at lists.linuxfoundation.org>>
> > > >> > > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
> > > <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>
> > > >> <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
> > > <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>>
> > > >>
> > > >>
> > > >>
> > > >>
> > > >> --
> > > >> Michael Folkson
> > > >> Email: michaelfolkson at gmail.com <mailto:michaelfolkson at gmail.com> <mailto:michaelfolkson at gmail.com
> > > <mailto:michaelfolkson at gmail.com>>
> > > >> Keybase: michaelfolkson
> > > >> PGP: 43ED C999 9F85 1D40 EAF4 9835 92D6 0159 214C FEE3
> > > >> _______________________________________________
> > > >> bitcoin-dev mailing list
> > > >> bitcoin-dev at lists.linuxfoundation.org <mailto:bitcoin-dev at lists.linuxfoundation.org>
> > > <mailto:bitcoin-dev at lists.linuxfoundation.org <mailto:bitcoin-dev at lists.linuxfoundation.org>>
> > > >> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
> > > <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>
> > > >> <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
> > > <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>>
> > > >
> > > >
> > > >
> > > > --
> > > > Michael Folkson
> > > > Email: michaelfolkson at gmail.com <mailto:michaelfolkson at gmail.com> <mailto:michaelfolkson at gmail.com
> > > <mailto:michaelfolkson at gmail.com>>
> > > > Keybase: michaelfolkson
> > > > PGP: 43ED C999 9F85 1D40 EAF4 9835 92D6 0159 214C FEE3
> > > _______________________________________________
> > > bitcoin-dev mailing list
> > > bitcoin-dev at lists.linuxfoundation.org <mailto:bitcoin-dev at lists.linuxfoundation.org>
> > > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
> > > <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>
> > >
> >
> > bitcoin-dev mailing list
> > bitcoin-dev at lists.linuxfoundation.org
> > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

📅 Original date posted:2015-06-15
📝 Original message:Hi Mike
Well thank you for replying openly on this topic, its helpful.
I apologise in advance if this gets quite to the point and at times
blunt, but transparency is important, and we owe it to the users who
see Bitcoin as the start of a new future and the$3b of invested funds
and $600m of VC funds invested in companies, we owe it to them that we
be open and transparent here.
I would really prefer on a personal nor professional basis to be
having this conversation period, never mind in public, but Mike - your
and Gavin's decision to promote a unilateral hard-fork and code fork
are extremely high risk for bitcoin and so there remains little
choice. So I apologise again that we have to have this kind of
conversation on a technical discussion list. This whole thing is
hugely stressful and worrying for developers, companies and investors.
I strongly urge that we return to the existing collaborative
constructive review process that has been used for the last 4 years
which is a consensus by design to prevent one rogue person from
inserting a backdoor, or lobbying for a favoured change on behalf of a
special interest group, or working for bad actor (without accusing you
of any of those - I understand you personally just want to scale
bitcoin, but are inclined to knock heads and try to force an issue you
see, rather than work collaboratively).
For you (and everyone)
- Should there be a summit of some kind, that is open attendance, and
video recorded so that people who are unable to attend can participate
too, so that people can present the technical proposals and risks in
an unbiased way?
(It is not theoretical question, I may have a sponsor and host - not
Blockstream, an independent, its a question for everyone, developers,
users, CTOs, CEOs.)
So here I come back to more frank questions:
Governance
The rest of the developers are wise to realise that they do not want
exclusive control, to avoid governance centralising into the hands of
one person, and this is why they have shared it with a consensus
process over the last 4 years. No offence but I dont think you
personally are thinking far enough ahead to think you want personal
control of this industry. Maybe some factions dont trust your
motives, or they dont mind, but feel more assured if a dozen other
people are closely reviewing and have collective review authority.
- Do you understand that attempting to break this process by
unilateral hard-fork is extremely weakening of Bitcoin's change
governance model?
- Do you understand that change governance is important, and that it
is important that there be multiple reviewers and sign-off to avoid
someone being blackmailed or influenced by an external party - which
could potentially result in massive theft of funds if something were
missed?
- Secondarily do you understand that even if you succeed in a
unilateral fork (and the level of lost coins and market cap and damage
to confidence is recoverable), that it sets a precedent that others
may try to follow in the future to introduce coercive features that
break the assurances of bitcoin, like fungibility reducing features
say (topically I hear you once proposed on a private forum the concept
of red-lists, other such proposals have been made and quickly
abandoned), or ultimately if there is a political process to obtain
unpopular changes by unilateral threat, the sky is the limit - rewrite
the social contract at that point without consensus, but by
calculation that people will value Bitcoin enough that they will
follow a lead to avoid risk to the system?
Security
As you probably know some extremely subtle bugs in Bitcoin have at
times slipped past even the most rigorous testings, often with
innocuous but unexpected behaviours, but some security issues Some
extremely intricate and time-sensitive security defect and incident
response happens from time to time which is not necessarily publicly
disclosed until after the issue has been rolled out and fixed, which
can take some time due to the nature of protocol upgrades,
work-arounds, software upgrade via contacting key miners etc. We
could take an example of the openSSL bug.
- How do you plan to deal with security & incident response for the
duration you describe where you will have control while you are
deploying the unilateral hard-fork and being in sole maintainership
control?
- Are you a member of the bitcoin security reporting list?
On 15 June 2015 at 11:56, Mike Hearn <mike at plan99.net> wrote:
> I will review both and mostly delegate to Gavin's good taste around the
> details, unless there is some very strong disagreement. But that seems
> unlikely.
> ...
> Feedback will be read. There are no NACKS in Bitcoin XT. Patch requests
> aren't scored in any way. The final decision rests with the maintainer as in
> ~all open source projects.
As you know the people who have written 95% of the code (and reviewed,
and tested, and formally proved segments etc) are strenuously advising
not to push any consensus code into public use without listening to
and addressing review questions which span beyond rigorous code &
automated guided fuzz testers, simulation and sometimes formal proofs,
but also economics, game-theory and critically very subtle
determinism/consensus safety that they have collectively 4-5 years
experience of each.
- Will you pause your release plans if all of the other developers
insist that the code or algorithm is defective?
- Please don't take this the wrong way, and I know your bitcoinj work
was a significant engineering project which required porting bitcoin
logic. But If the answer to the above question is no, as you seemed
to indicate in your response, as you not have not written much bitcoin
core code yourself (I think 3 PRs in total), do you find yourself more
qualified than the combination of peer review of the group of people
who have written 95% of it, and maintained it and refactored most of
it over the last 4-5 years?
I presume from your security background you are quite familiar with
the need for review of crypto protocol changes & rigorous code review.
That is even more the case with Bitcoin given the consensus
criticality.
>> - On the idea of a non-consensus hard-fork at all, I think we can
>> assume you will get a row of NACKs. Can you explain your rationale
>> for going ahead anyway? The risks are well understood and enormous.
>
> If Bitcoin runs out of capacity it will break and many of our users will
> leave. That is not an acceptable outcome for myself or the many other
> wallet, service and merchant developers who have worked for years to build
> an ecosystem around this protocol.
That you are frustrated, is not a sufficient answer as to why you are
proposing to go ahead with a universally acknowledged extreme network
divergence danger unilateral hard-fork, lacking wide-spread consensus.
People are quite concerned about this. Patience, caution and prudence
is necessary in a software system with such high assurance
requirements.
So I ask again:
- On the idea of a non-consensus hard-fork at all, I think we can
assume you will get a row of NACKs. Can you explain your rationale
for going ahead anyway? The risks are well understood and enormous.
Note the key point is that you are working on a unilateral hard-fork,
where there is a clear 4 year established process for proposing
improvements and an extremely well thought out and important change
management governance process. While there has been much discussion,
you nor Gavin, have not actually posted a BIP for review. Nor
actually was much of the discussion even conducted in the open: it was
only when Matt felt the need to clear the air and steer this
conversation into the open that discussion arose here. During that
period of private discussion you and Gavin were largely unknown to
most of us lobbying companies with your representation of a method
that concerns everyone of the Bitcoin users. Now that the technical
community aware aware they are strenuously discouraging you on the
basis of risks.
Openness
- Do you agree that bitcoin technical discussions should happen in the open?
- As this is a FOSS project, do you agree that companies should also
be open, about their requirements and trade-offs they would prefer?
- Can you disclose the list of companies you have lobbied in private
whether they have spoken publicly or not, and whether they have
indicated approval or not?
- Did you share a specific plan, like a BIP or white paper with these
companies, and if so can we see it?
- If you didnt submit a plan, could you summarise what you asked them
and what you proposed, and if you discussed also the risks? (If you
asked them if they would like Bitcoin to scale, I expect almost
everyone does, including every member of the technical community, so
that for example would not fairly indicate approval for a unilateral
hard-fork)
I and others will be happy to talk with the CTO and CEOs of companies
you have lobbied in private, for balance to assure ourselves and the
rest of the community that their support was given - and with full
understanding of the risks of doing it unilaterally, without peer
review, benefit of maintenance and security inidence management, and
what exactly they are being quoting as having signed up for.
(This maybe more efficiently and openly achieved by the open process,
on a mailing list, maybe a different one even special purpose to this
topic, with additional option of the open public meeting I proposed at
the top).
- Do you agree that it would be appropriate, that companies be aware
of both the scaling opportunities (of course, great everyone wants
scalability) as well as the technical limits and risks with various
approaches? And that these be presented by parties from a range of
views to ensure balance?
- Do you consider your expression of issues to hold true to the ideal
of representing balanced nuanced view of all sides of a technical
debate, even when under pressure or feeling impatient about the
process?
You may want to review the opening few minutes of your epicenter 82
bitcoin for example where you claimed and I quote "[the rest of the
technical community] dont want capacity to ever increase and want it
to stay where it is and when it fills up people move to other
systems".
- Do you think that is an accurate depiction of the complex trade-offs
we have been discussing on this list?
(For the record I am not aware of a single person who has said they do
not agree with scaling Bitcoin. Changing a constant is not the
hard-part. The hard part is validating a plan and the other factors
that go into it. It's not a free choice it is a security/scalability
tradeoff. No one will thank us if we "scale" bitcoin but break it in
hard to recover ways at the same time.)
- Were you similarly balanced in your explanations when talking to
companies in private discussions?
- Do you understand that if we do not work from balanced technical
discussion, that we may end up with some biased criteria?
Authority
Neither you nor Gavin have any particular authority here to speak on
behalf of Bitcoin (eg you acknowledge in your podcast that Wladimir is
dev lead, and you and Gavin are both well aware of the 4 year
established change management consensus decision making model where
all of the technical reviewers have to come to agreement before
changes go in for security reasons explained above). I know Gavin has
a "Chief Scientist" title from the Bitcoin Foundation, but sadly that
organisation is not held in as much regard as it once was, due to
various irregularities and controversies, and as I understand it no
longer employs any developers, due to lack of funds. Gavin is now
employed by MIT's DCI project as a researcher in some capacity. As
you know Wladimir is doing the development lead role now, and it seems
part of your personal frustration you said was because he did not
agree with your views. Neither you nor Gavin have been particularly
involved in bitcoin lately, even Gavin, for 1.5 years or so.
- Do you agree that if you presume to speak where you do not have
authority you may confuse companies?
> If Bitcoin runs out of capacity it will break and many of our users will
> leave. That is not an acceptable outcome for myself or the many other
> wallet, service and merchant developers who have worked for years to build
> an ecosystem around this protocol.
But I think this is a false dichotomy. As I said in previous mail I
understand people are frustrated that it has taken so long, but it is
not the case that no progress has been made on scalability.
I itemised a long list of scalability work which you acknowledged as
impressive work (CPU, memory, network bandwidth/latency) and RBF, CPFP
fee work, fee-estimation, and so on, which you acknowledged and are
aware of.
There are multiple proposals and BIPs under consideration on the list right now.
- what is the reason that you (or Gavin) would not post your BIP along
side the others to see if it would win based on technical merit?
- why would you feel uniquely qualified to override the expert opinion
of the rest of the technical community if your proposal were not
considered to have most technical merit? (Given that this is not a
simple market competition thing where multiple hard-forks can be
considered - it is a one only decision, and if it is done in a
divisive unilateral way there are extreme risks of the ledger
diverging.)
Network Divergence Risk
>> - How do you propose to deal with the extra risks that come from
>> non-consensus hard-forks? Hard-forks themselves are quite risky, but
>> non-consensus ones are extremely dangerous for consensus.
>
> The approach is the same for other forks. Voting via block versions and then
> when there's been >X% for Y time units the 1mb limit is lifted/replaced.
But this is not a soft-fork, it is a hard-fork. Miner voting is only
peripherally related. Even if in the extremis 75% of miners tried a
unilateral hard-fork but 100% of the users stayed on the maintained
original code, no change would occur other than those miners losing
reward (mining fork-coins with no resale value) and the difficulty
would adjust. The miners who made an error in choice would lose money
and go out of business or rejoin the chain.
However if something in that direction happens with actual users and
companies on both sides of it users will lose money, the ledger will
diverge as soon as a single double-spend happens, and never share a
block again, companies will go instantly insolvent, and chaos will
break out. This is the dangerous scenario we are concerned about.
So the same question again:
- How do you propose to deal with the extra risks that come from
non-consensus hard-forks? Hard-forks themselves are quite risky, but
non-consensus ones are extremely dangerous for consensus.
Being sensitive to alarming the market
It is something akin to Greece or Portugal or Italy exiting the euro
currency in a disorderly way. Economists and central bank policy
makers are extremely worried about such an eventuality and talk about
related factors in careful, measured terms, watch Mario Draghi when he
speaks.
Imagine that bitcoin is 10x or 100x bigger. Bitcoin cant have people
taking unilateral actions such as you have been proposing. It is not
following the consensus governance process, and not good policy and it
is probably affecting bitcoin confidence and price at this moment.
>> - Do you have contingency plans for what to do if the non-consensus
>> hard-fork goes wrong and $3B is lost as a result?
>
> Where did you get the $3B figure from? The fork either doesn't happen, or it
> happens after quite a long period of people knowing it's going to happen -
> for example because their full node is printing "You need to upgrade"
> messages due to seeing the larger block version, or because they read the
> news, or because they heard about it via some other mechanisms.
This is not a soft-fork, and the community will not want to take the
risks once they understand them, and they have months in which to
understand them and at this point you've motivated and wasted 100s of
developer man hours such that we will feel impelled to make sure that
no one opts into a unilateral hard-fork without understanding the
risks. It would be negligent to allow people to do that. Before this
gets very far FAQs will be on bitcoin.org etc explaining this risk I
would imagine. Its just starting not finished.
What makes you think the rest of the community may not instead prefer
Jeff Garzik's BIP after revisions that he is making now with review
comments from others?
Or another proposal. Taken together with a deployment plan that sees
work on decentralisation tying into that plan.
- If you persisted anyway, what makes you think bitcoin could not make
code changes defensively relating to your unilateral fork?
(I am sure creative minds can find some ways to harden bitcoin against
a unilateral fork, with a soft-fork or non-consensus update can be
deployed much faster than a hard-fork).
I tried to warn Gavin privately that I thought he was under-estimating
the risk of failure to his fork proposal due to it being unilateral.
Ie as you both seem sincere in your wish to have your proposal
succeed, then obviously the best way to do that is to release a BIP in
the open collaborative process and submit it to review like everyone
else. Doing it unilaterally only increases its chance of failure.
The only sensible thing to do here is submit a BIP and stop the
unilateral fork threat.
Scalability Plans
> Let me flip the question around. Do you have a contingency plan if Bitcoin
> runs out of capacity and significant user disruption occurs that results in
> exodus, followed by fall in BTC price? The only one I've seen is "we can
> perform an emergency hard fork in a few weeks"!
Yes people have proposed other plans. Bryan Bishop posted a list of them.
Jeff Garzik has a proposal, BIP-100 which seems already better than
Gavin's having benefit of peer review which he has been incorporating.
I proposed several soft-fork models which can be deployed safely and
immediately, which do not have ledger risk.
I have another proposal relating to simplified soft-fork one-way pegs
which I'll write up in a bit.
I think there are still issues in Jeff's proposal but he is very open
and collaborating and there maybe related but different proposals
presently.
>> As you can probably tell I think a unilateral fork without wide-scale
>> consensus from the technical and business communities is a deeply
>> inadvisable.
>
> Gavin and I have been polling many key players in the ecosystem. The
> consensus you seek does exist. All wallet developers (except Lawrence), all
> the major exchanges, all the major payment processors and many of the major
> mining pools want to see the limit lifted (I haven't been talking to pools,
> Gavin has).
It does not seem to me that you understand the issue. Of course they
want to increase the scalability of bitcoin. So does everyone else on
this mailing list.
That they would support that is obvious. If you presented your
unilateral action plan without explaining the risks too.
I think I covered this further above. If you would like to share the
company list, or we can invite them to the proposed public physical
meeting, I think it would be useful for them to have a balanced view
of the ledger divergence risks, and alternative in-consensus proposals
underway, as well as the governance risks, maintenance risks, security
incident risks.
Note that other people talk to companies too, as part of their day to
day jobs, or from contacts from being in the industry. You have no
special authority or unique ability to talk with business people. Its
just that the technical community did not know you were busy doing
that.
I can not believe that any company that would listen to their CTO, CSO
or failing that board would be ok with the risks implied by what you
are proposing on full examination.
> This notion that the change has no consensus is based on you polling the
> people directly around you and people who like to spend all day on this
> mailing list. It's not an accurate reflection of the wider Bitcoin community
> and that is one of the leading reasons there is going to be a fork. A small
> number of people have been flatly ignoring LOTS of highly technical and
> passionate developers who have written vast amounts of code, built up the
> Bitcoin user base, designed hardware and software, and yes built companies.
I know you want scale bitcoin, as I said everyone here does. I think
what you're experiencing is that you've had more luck explaining your
pragmatic unilateral plan to non-technical people without peer review,
and so not experienced the kind of huge pushback you are getting from
the technical community. The whole of bitcoin is immensely
complicated such that it takes an uber-geek CS genius years to
catchup, this is not a slight of any of the business people who are
working hard to deploy Bitcoin into the world, its just complicated
and therefore not easy to understand the game-theory, security,
governance and distributed system thinking. I have a comp sci PhD in
distributed systems, implemented p2p network systems and have 2
decades of applied crypto experience with a major interest in
electronic cash crypto protocols, and it took me a several years to
catchup and even I have a few hazy spots on low-level details, and I
addictively into read everything I could find. Realistically all of
us are still learning, as bitcoin combines so many fields that it
opens new possibilities.
What I am expecting that yourself and Gavin are thinking is that
you'll knock heads and force the issue and get to consensus.
However I think you have seriously misjudged the risks and have not
adequately explained them to companies you are talking with. Indeed
you do not fully seem to acknowledge the risks, nor to have a well
thought out plan here of how you would actually manage it, nor the
moral hazards of having a lone developer in hugely divisive
circumstances in sole control of bitcoins running code. Those are
exactly the reasons for the code change governance process!
Even though you are trying to help, the full result is you are not
helping achieve anything by changing a constant and starting a
unilateral hard-fork (not to trivialise the work of making a patch to
do that).
The work to even make the constant change be feasible was a result of
1000s of hours of work by others in the development community, that is
emphatically and unilaterally telling you that hard-forks are hugely
inadvisable.
You are trying to break the code change governance security procedure
that were put in place for good reason for the security of $3b of
other peoples money, even if you have a pragmatic intent to help, this
is flat out unacceptable.
There are also security implications to what you are proposing, which
I have heard you attempting to trivialise, that are core to Bitcoins
security and core functionality.
> the overwhelming impression I get from a few
> others here is that no, they don't want to scale Bitcoin. They already
> decided it's a technological dead end.
I think this is a significant mischaracterisation, and I think almost
everybody is on board with a combination plan:
1. work to improve decentralisation (specific technical work already
underway, and education)
2. create a plan to increase block-size in a slow fashion to not cause
system shocks (eg like Jeff is proposing or some better variant)
3. work on actual algorithmic scaling
In this way we can have throughput needed for scalability and security
work to continue.
As I said you can not scale a O(n^2) broadcast network by changing
constants, you need algorithmic improvements.
People are working on them already. All of those 3 things are being
actively worked on RIGHT NOW, and in the case of algorithmic scaling
and improve decentralisation have been worked on for months.
You may have done one useful thing which is to remind people that
blocks are only 3x-4x below capacity such that we should look at it.
But we can not work under duress of haste, nor unilateral ultimatums,
this is the realm of human action that leads to moral hazard, and
ironically reminds us of why Satoshi put the quote in the genesis
block.
Bitcoin is too complex a system with too much at stake to be making
political hasty decisions, it would be negligent to act in such a way.
Again please consider that you did your job, caused people to pay
attention, but return to the process, submit a BIP, retract the
unilateral hard-fork which is so dangerous and lets have things be
calm, civil and collaborative in the technical zone of Bitcoin and not
further alarm companies and investors.
Adam