Proposal: activate CSV with 1.15

[patricklodder]

Currently there’s a protocol feature implemented in the code since 1.14.0, waiting to be activated: relative lock time (aka CSV). Because we only do one round of soft fork proposals per major release, and we cannot use versionbits as-is (part of the designated bits are already in use for AuxPow) only absolute lock time (aka CLTV) was proposed with 1.14.0. Now that we’re already working on a new major release and 1.14 is stable and maintenance-only, we can safely propose a protocol upgrade.

Note that maintainers have previously proposed to fork in CSV with 1.21. However, as progress on that effort has largely stalled for 2 years now, there is no reason to keep that a blocking requirement: all the code is there already, and we’re not bound to only doing minor updates for the current 1.15 release target.

I think that, because we only need to modify the versionbits location and make a decision about activation, this could be an excellent learning opportunity for those devs that have thus far not gained any practical experience with protocol extensions and softforks, on a relatively straight forward feature add and a smooth learning curve. If the Dogecoin developer community gains expertise around how protocol upgrades work, we can better collaborate with those people that for a longer time now have been waiting to be enabled with upstream protocol features we did not yet activate: I've personally talked to at least 5 teams that would love to work on implementing solutions on top of Dogecoin, but cannot because the protocol lags in features that Bitcoin and Litecoin already have; and I'm sure that there's many people out there with similar dilemmas that I don't know about.

Scope

1. Fix versionbits

We’ve tried fixing this in the past, but the plan was an unfinished and over-engineered effort that eventually got made obsolete by 1.14.0 - which didn’t solve the issue. We can however solve this in a much easier way than before, if we’re willing to limit ourself to 6 concurrent proposal slots (I haven’t seen anyone ever doing that many, isolated protocol change proposals concurrently, and for good reason: it’s good to be conservative in protocol changes, because consensus is the cornerstone of this tech.)

We have an entire byte in nVersion of which we only use 1 bit for indicating whether a block is AuxPoW, this leaves 7 bits, of which we should probably reserve 1 for any future auxpow-specific flagging, in case we need it. That leaves 6 pristine bits we can use for miner activation. If we change the bitmask in versionbits.cpp to cover only these 6 bits, we can effectively plan concurrent deployments. I have been a brat and mined a couple of testnet blocks with these bits set, to see if anyone complains - but every source code implementation I’ve checked (from electrumx to libdogecoin) properly applies the correct bitmask to decide on auxpowness of a block.

I’d personally be looking to deeply document both AuxPoW’s usage of block::nVersion and this new versionbits standard, for example in the form of a DIP, which is a facility we imho don’t use often enough.

2. Activation mechanism

We can then simply use BIP9, which also is included since 1.14.0 as an activation mechanism. It would be good to make an informed decision on this though, as we could also opt to use BIP8 which contains some lessons learned from BIP9, but at the very least make ourselves familiar with what Bitcoin learned from executing these methods for activating protocol upgrades, like this thread.

This doesn't have to be a big issue: I think that as long as we have some discussion and make an informed decision, we can make it work, even if we decide to just implement BIP9.

3. Marking CSV for potential activation

In parallel, we can test and prepare CSV (consisting of BIP68, BIP112 and BIP113) for activation. Its activation is currently disabled because the timestamp is in the past, but as we can 1-on-1 fork this in (which is great because we’d have full compatibility with any library written for Bitcoin). If we want to increase time granularity and make the lock-by-relative-height more meaningful for our 1-minute blocks (Bitcoin parametrization only allows for a translated 45 days worth of blocks), we can do that in a later softfork, so that we don’t break any bitcoin tooling and just non-obtrusively support 2 standards (which would be optional for transaction scripts to use)

And that’s it.

I’m interested to know what everyone thinks. Are you interested in this? Do you think it will help you learn more about the protocol? Let’s discuss.

[chromatic]

👍 to bringing in CSV (it's mature and well understood and has some interesting usage benefits) and 👍 to using this as a learning opportunity.

I want to think about the specific implementation in more detail before I fully commit to it, but I like this idea a lot on its face.

[patricklodder]

To summarize my thoughts thus far on parametrization: CSV reserves quite some space for granularity improvements, which we could use up. 21 bits of timestamp on 64-second granularity (2^6) means the maximum relative lock time becomes 4.25 years, which is also magically close to 21 bits of block heights - 4 years.

However doing that in a second softfork is easy (just need to add another flag bit in byte 0 and define the handling) and then we have both bitcoin/litecoin compatibility, which is useful because it guarantees compatibility with generic libraries like bitcoinjs or btcd/btcutils and at the same time allows us to create a dogecoin-optimized variant that extends that with a narrow-down flag on the first byte. That way, we do not force everyone to create dogecoin-specific libraries just to do basic relative locks, which may be very anti-maxi of me, but at the same time, the best wallets and software I've used in the past decade were not dogecoin-specific.

[AjaxPop]

I think focusing on implementing CSV instead of SegWit is a better choice. Given Dogecoin's faster block times, we're less likely to encounter issues with blocks becoming full. Dogecoin Ordinals may become a problem due to them clogging up the blockspace.

In terms of implementation, I support BIP9 over BIP8. My reasoning is that miners, who run the core infrastructure, have invested in the equipment and are the most enthusiastic about the protocol. I don't like how in BIP8, there is still a way to force network adoption even without full support.

I believe that in the future, mining will become more mainstream. For example, the Spiritus car has the capability to mine cryptocurrency, a move primarily driven by the market's increased interest in mining crypto compared to its interest around 2012.

[patricklodder]

Given Dogecoin's faster block times, we're less likely to encounter issues with blocks becoming full.

We've previously established that we anyway should not attempt to do a "segwit4x" like Bitcoin did. It's a threat as currently miners limit block size to under half the maximum during times of spam (to prevent orphans) and we don't need that additional space or discount for a softfork to work: as long as the new rules are tighter than the old rules, a fork can stay soft.

I still think that the pure implementation of segregating the signature from the transaction body that is hashed is a good and necessary feature to have. However, because of the extra effort we'd need to invest to explicitly not be like Bitcoin, I think it's better if we do that once we have more experience.

I don't like how in BIP8, there is still a way to force network adoption even without full support.

Agreed. I don't like that parameter much either as we've always had the model where developers do proposals, miners signal acceptance and readiness and validating nodes/wallets have the final say with their economic power (and can worst case UASF-signal disagreement). Therefore, super-powering developer decisions at the cost of miner decisions is something I'm personally not a fan of, as it upsets that balance.

[slightlyskepticalpotat]

Agree on CSV, it would definitely have interesting applications and build developer knowledge. Are there any other protocol upgrades you personally think we should take a look at assuming everything with CSV goes well?

[patricklodder]

I think that, unlike when we last had the discussion early 2021 between maintainers, making versionbits work is now an important enabler because it de-sequentializes protocol updates. Back then, the idea was to do 1.21, which is a more centralized effort and as it turned out, extremely painful and slow in lieu of having an experienced team that just decides things and pushes changes rapidly. For that, we didn't need parallel proposals, because there would have just been one proposal at a time.

In contrast, if right now we enable the means to concurrently propose protocol features, it means we can start working on many ideas in parallel in that area too. The amount of concurrent implementation changes has exploded already, because the number of contributors has done a 10x since early 2021. But all that is really just code optimization and software features, whereas the protocol itself has been completely static since 2019 because the plan was to change it with 1.21. Letting go of that constraint enables many ideas that until now were not realistic to even propose: no one will happily do the time investment needed to implement a protocol feature properly if there is a complete rewrite that is more likely than not to disrupt the work.

To elaborate what functionality and their needs I observe when talking to 3rd party teams:

1. Cross chain pegs/bridges: most of these projects would like to have multi-party tx malleability taken care of (=bare minimum segwit) and schnorr for multisig, MAST for fallback instead of p2sh (can be provided with the taproot softfork package (BIP340, BIP341, BIP342)). Note that there are still many things that can be optimized with some form of covenant or other multi-claimee struct (see bottom note in Nomic's emergency wind-down process) even with taproot available, so these will be fun in the long run - it doesn't end with taproot, that's just the beginning
2. Layer 2s: segwit again, more reliable time locks (=CSV), and ultimately L2s will want the taproot package too; for example, LND implements MuSig2 channels since last year
3. Atomic swaps: segwit + MAST

Some of these projects - in particular those that are currently or have been working on Bitcoin implementations - are looking at additional features that will make their protocols cheaper. For example those juicy opcodes that Elements re-enabled, or covenants, or perhaps new *VERIFY primitives.

Therefore, for me personally because I feel my role in all this should be that of enabler more than anything else, the most impactful generic feature to fork in after CSV is segwit, for the security properties and the witness program space, not the 4x; i.e. as long as we do just the segregation and abstraction part it will eliminate a lot of tx malleability risk when dealing with untrusted parties in a multisig setting.

That said, I'd take 'em one at a time really: for now, let's do CSV and more importantly, versionbits, and then we'll assess what else is beneficial at that time. I'm convinced that once some of these 3rd party projects see actual evidence that Dogecoin can have protocol updates without 4 people constantly rewriting the codebase or causing unintended complications, they'll be getting involved here more. For now, there's just talk and hope; I'm proposing to walk the walk, on the most gentle path we have to start with.

[daank-c]

for example in the form of a DIP

Does the DIP repo need any work (organization/updates) before we start using it again?

[patricklodder]

If we choose to use that, it could use a maintainer.