I propose evaluating expected benefits of these protocol changes and decide where they are worth implementing at all at this point. The good news is that these are not sexy features, at all. But then, looking at how slow the v4 soft fork went, even it goes 2-3x faster this time, it's my opinion that we should rather think now than later about what we foresee in the future, because even if coding would take an hour, fork activation will take a very long time. Our developer ecosystem is very small though, and this is a problem because we don't have much people working on libraries and integrations. When there is already a demand for some feature, its benefits are more clear.Ībsolutely. I am a bit pessimistic about cool new features, they often go unused in Dogecoin. Replying in reverse order, because it suits my narrative better, sorry: On the other hand, when there is already a demand for some feature, its benefits are more clear. By that time it may turn out that the way we did it was not a good way. We can put effort into solving transaction malleability and implementing some new features now and see some benefits a couple of years later. And this feature was there from the beginning, I think. For example, I think that multi-signature transactions are useful in many cases, but I don't see them used as widely as it could be. But I see it as technical debt, it may complicate things in the future. As for SegWit, it can be implemented now with little effort by using BTC code. Transaction malleability can be mitigated in different ways. And I think it will likely be needed because of different economic priorities. By following their development path, we would make it more difficult to diverge in the future, should it be needed. BTC does it in a more complicated way only to maintain backwards-compatibility.
DOGECOIN CORE SYNC TIME UPDATE
Extension Blocks - Not yet deployed on Litecoinĭeployment is planned to be proposed through a single soft fork, identified by block version 5 (full version: 0x00620104) and a protocol update to version 70016 ( 0x011180) through the usual 95% SuperMajority consensus rule (full activation with 1900 blocks having v5 in a 2000 block window) similar to the BIP65 soft fork that was proposed with Dogecoin Core 1.14.īasically, it all can be implemented in a straightforward way.We deem this too risky to do at once with the features described above, especially for a meta-feature. VersionBits - Needs another, more dangerous soft-fork, see AuxPoW BIP9 Compatibility #1340 and Make AuxPoW consensus params versionable #1344.Rationale: Allows for much more sophisticated redeem scripts, must-have feature for Lightning-like L2 networks.Functionality: Allows consensus-enforced locking of an output until a relative time and exposes the field to redeem scripts.Note: we will carefully consider P2W* addressing.Rationale: Further reduces transaction malleability.signatures) from transactions when embedded in blocks Functionality: Separates spending proofs (i.e.VersionBits / BIP9 will not be proposed at this time because of the conflict in the version with AuxPow, and this would be a much more dangerous, and possibly contentious change.Ī block versions 5 and protocol version 70016 will be proposed for this implementation. As such it will save us all time when we do them at once instead of sequential. Both have been deployed on Bitcoin's mainnet for a longer time and are considered non-contentious. With the next major release, we plan to propose 2 protocol changes for activation at once: segwit and csv. This issue describes the planned protocol features that need to be activated by consensus for the next major release (planned to be 1.21) Summary
0 kommentar(er)
