> That day is nowhere near IMO and maybe we won't see it in my lifetime.
I think there is a reasonable argument to be made that maybe bitcoin needs
to move faster now than it should in the future, and the cost of having the
community remain vigilant against harmful changes is worth the extra spee
> We should strive to one day get to a point where the bitcoin consensus isn't
> updating at all.
That day is nowhere near IMO and maybe we won't see it in my lifetime.
> Perhaps we should come to a consensus as a consensus as a community what the
> minimum time between soft forks should be, an
I agree with you Michael, there is a risk to soft forks and we shouldn't do
them too often. We should do them as infrequently as practical. We should
strive to one day get to a point where the bitcoin consensus isn't updating
at all.
Perhaps we should come to a consensus as a consensus as a commun
> If you don't like the reduction of the block subsidy, well that's a much
> bigger problem.
It is reversible, because you can also increase the block subsidy by using
another kind of soft-fork. For example, you can create spendable outputs with
zero satoshis. In this way, old nodes will accept
> But whether or not it is a basic principle of general software
engineering kind of misses the point. Security critical software clearly
isn't engineered in the same way as a new social media app. Bugs are easily
reverted in a new social media app.On top of that we aren't just dealing
with securi
> Interesting discussion.Correct me if I'm wrong: but putting too many features
> together in one shot just can't make things harder to debug in production if
> something very unexpected happens.It's a basic principle of software
> engineering.
Soft fork features can (and should) obviously be t
Interesting discussion. Correct me if I'm wrong: but putting too many
features together in one shot just can't make things harder to debug in
production if something very unexpected happens. It's a basic principle of
software engineering.
Change. Deploy. Nothing bad happened? Change it a little mo
On Mon, Oct 11, 2021 at 12:12:58PM -0700, Jeremy via bitcoin-dev wrote:
> > ... in this post I will argue against frequent soft forks with a single or
> minimal
> > set of features and instead argue for infrequent soft forks with batches
> > of features.
> I think this type of development has been
On Tue, Oct 12, 2021 at 5:34 PM Prayank via bitcoin-dev
wrote:
>
> Hi Michael,
>
> Agree with almost everything.
>
> > Miner signaling is a tool for signaling readiness. It is not voting for the
> > soft fork or expressing support for the soft fork. There should not be any
> > attempt to facilit
Hi Michael,
Agree with almost everything.
> Miner signaling is a tool for signaling readiness. It is not voting for the
> soft fork or expressing support for the soft fork. There should not be any
> attempt to facilitate miner signaling until there is sufficient community
> consensus (the mini
Good morning Jeremy,
> This also has strong precedent in other important technical bodies, e.g. from
> https://datatracker.ietf.org/doc/html/rfc7282 On Consensus and Humming in the
> IETF.
>
> Even worse is the "horse-trading" sort of compromise: "I object to
> your proposal for such-and-so
*> ... in this post I will argue against frequent soft forks with a single
or minimal*
*> set of features and instead argue for infrequent soft forks with batches*
*> of features.*
I think this type of development has been discussed in the past and has
been rejected.
from: Matt Corallo's post:
h
I was hoping to delay this post as long as possible because there are so many
interesting and important things to discuss other than soft forks and consensus
changes that seem to have taken a backseat this year due to Taproot activation.
In addition, there seems to be a world of opportunity to l
13 matches
Mail list logo
