Re: [bitcoin-dev] On the regularity of soft forks

2022-01-19 Thread Billy Tetrud via bitcoin-dev
> 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

Re: [bitcoin-dev] On the regularity of soft forks

2022-01-18 Thread Prayank via bitcoin-dev
> 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,

Re: [bitcoin-dev] On the regularity of soft forks

2022-01-18 Thread Billy Tetrud via bitcoin-dev
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

Re: [bitcoin-dev] On the regularity of soft forks

2022-01-01 Thread vjudeu via bitcoin-dev
> 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

Re: [bitcoin-dev] On the regularity of soft forks

2021-12-31 Thread Keagan McClelland via bitcoin-dev
> 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

Re: [bitcoin-dev] On the regularity of soft forks

2021-10-16 Thread Michael Folkson via bitcoin-dev
> 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

Re: [bitcoin-dev] On the regularity of soft forks

2021-10-15 Thread Felipe Micaroni Lalli via bitcoin-dev
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

Re: [bitcoin-dev] On the regularity of soft forks

2021-10-14 Thread Anthony Towns via bitcoin-dev
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

Re: [bitcoin-dev] On the regularity of soft forks

2021-10-12 Thread Jorge Timón via bitcoin-dev
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

Re: [bitcoin-dev] On the regularity of soft forks

2021-10-12 Thread Prayank via bitcoin-dev
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

Re: [bitcoin-dev] On the regularity of soft forks

2021-10-11 Thread ZmnSCPxj via bitcoin-dev
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

Re: [bitcoin-dev] On the regularity of soft forks

2021-10-11 Thread Jeremy via bitcoin-dev
*> ... 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:

[bitcoin-dev] On the regularity of soft forks

2021-10-11 Thread Michael Folkson via bitcoin-dev
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