> 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 tested thoroughly on testnet,
signet, custom signets, sidechains etc on a standalone basis and a bundled
basis. 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. A consensus change is extremely hard to revert and
probably requires a hard fork, a level of central coordination we generally
attempt to avoid and a speed of deployment that we also attempt to avoid. On
top of that we aren't just dealing with security critical software. One of the
most important objectives is to keep all the nodes on the network in consensus.
Introducing a consensus change before we are comfortable there is community
consensus for it is a massive effective bug in itself. The network can split in
multiple ways e.g. part of the network disagrees on whether to activate the
consensus change, part of the network disagrees on how to resist that consensus
change, part of the network disagrees on how to activate that consensus change
etc
In addition, a social media app can experiment in production whether Feature A
works, whether Feature B works or whether Feature A and B work best together.
In Bitcoin if we activate consensus Feature A, later decide we want consensus
Feature B but find out that by previously activating Feature A we can't have
Feature B (it is now unsafe to activate it) or its design now has to be
suboptimal because we have to ensure it can safely work in the presence of
Feature A we have made a mistake by activating Feature A in the first place.
Decentralized security critical consensus changes are an emerging field in
itself and really can't be treated like any other software project. This will
become universally understood I'm sure over time.
--
Michael Folkson
Email: michaelfolkson at protonmail.com
Keybase: michaelfolkson
PGP: 43ED C999 9F85 1D40 EAF4 9835 92D6 0159 214C FEE3
‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
On Friday, October 15th, 2021 at 1:43 AM, Felipe Micaroni Lalli via bitcoin-dev
<bitcoin-dev@lists.linuxfoundation.org> wrote:
> 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 more. Deployment.
>
> Or:Change, change, change. Deploy. Did something bad happen? What change
> caused the problem?
>
> On Thu, Oct 14, 2021 at 8:53 PM Anthony Towns via bitcoin-dev
> <bitcoin-dev@lists.linuxfoundation.org> wrote:
>
>> 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 discussed in the past and has been
>>> rejected.
>>
>>> AJ: - improvements: changes might not make everyone better off, but we
>>> don't want changes to screw anyone over either -- pareto
>>> improvements in economics, "first, do no harm", etc. (if we get this
>>> right, there's no need to make compromises and bundle multiple
>>> flawed proposals so that everyone's an equal mix of happy and
>>> miserable)
>>
>> I don't think your conclusion above matches my opinion, for what it's
>> worth.
>>
>> If you've got two features, A and B, where the game theory is:
>>
>> If A happens, I'm +100, You're -50
>> If B happens, I'm -50, You're +100
>>
>> then even though A+B is +50, +50, then I do think the answer should
>> generally be "think harder and come up with better proposals" rather than
>> "implement A+B as a bundle that makes us both +50".
>>
>> _But_ if the two features are more like:
>>
>> If C happens, I'm +100, You're +/- 0
>> If D happens, I'm +/- 0, You're +100
>>
>> then I don't have a problem with bundling them together as a single
>> simultaneous activation of both C and D.
>>
>> Also, you can have situations where things are better together,
>> that is:
>>
>> If E happens, we're both at +100
>> If F happens, we're both at +50
>> If E+F both happen, we're both at +9000
>>
>> In general, I think combining proposals when the combination is better
>> than the individual proposals were is obviously good; and combining
>> related proposals into a single activation can be good if it is easier
>> to think about the ideas as a set.
>>
>> It's only when you'd be rejecting the proposal on its own merits that
>> I think combining it with others is a bad idea in principle.
>>
>> For specific examples, we bundled schnorr, Taproot, MAST, OP_SUCCESSx
>> and CHECKSIGADD together because they do have synergies like that; we
>> didn't bundle ANYPREVOUT and graftroot despite the potential synergies
>> because those features needed substantially more study.
>>
>> The nulldummy soft-fork (bip 147) was deployed concurrently with
>> the segwit soft-fork (bip 141, 143), but I don't think there was any
>> particular synergy or need for those things to be combined, it just
>> reduced the overhead of two sets of activation signalling to one.
>>
>> Note that the implementation code for nulldummy had already been merged
>> and were applied as relay policy well before activation parameters were
>> defined (May 2014 via PR#3843 vs Sep 2016 for PR#8636) let alone becoming
>> an active soft fork.
>>
>> Cheers,
>> aj
>>
>> _______________________________________________
>> 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
