Consensus plan for next major release (1.21) #2264
Replies: 140 comments 34 replies
-
I support general idea of separating signatures from signed data. However, I oppose SegWit soft fork as implemented in Bitcoin with block extension and "weight". I think it was done that way mostly because BTC developers decided to "freeze base protocol" and implement any further changes as backwards-compatible extensions. That decision might make sense for BTC's investment and large transaction use cases, but not for Dogecoin's "people's money" use cases. If Dogecoin's popularity will grow significantly, we may have to technically diverge from BTC and address scaling issues in a different way. I want Dogecoin to be technically and organizationally prepared for positive changes in case they will come. I propose discussing SegWit and CSV separately and re-assessing whether they may be contentious. |
Beta Was this translation helpful? Give feedback.
-
Could you elaborate your concern with concept of block extensions? Asking as this is also a characteristic of EB and a requirement for TapRoot, so you're basically challenging an entire chain of protocol extensions. Open to counter-proposals - we can discuss that here. |
Beta Was this translation helpful? Give feedback.
-
Basically, it all can be implemented in a straightforward way. BTC does it in a more complicated way only to maintain backwards-compatibility. By following their development path, we would make it more difficult to diverge in the future, should it be needed. And I think it will likely be needed because of different economic priorities. Transaction malleability can be mitigated in different ways. As for SegWit, it can be implemented now with little effort by using BTC code. But I see it as technical debt, it may complicate things in the future. I propose evaluating expected benefits of these protocol changes and decide where they are worth implementing at all at this point. I am a bit pessimistic about cool new features, they often go unused in Dogecoin. 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. And this feature was there from the beginning, I think. We can put effort into solving transaction malleability and implementing some new features now and see some benefits a couple of years later. By that time it may turn out that the way we did it was not a good way. On the other hand, when there is already a demand for some feature, its benefits are more clear. |
Beta Was this translation helpful? Give feedback.
-
Replying in reverse order, because it suits my narrative better, sorry:
Absolutely. Our developer ecosystem is very small though, and this is a problem because we don't have much people working on libraries and integrations. 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. The good news is that these are not sexy features, at all.
The reason for segwit (or more specifically, witness segregation) is purely to reduce malleability. I think this is needed because the risk of not doing it is that there could - even today - be weaknesses in the implementation that are currently not found or found but not disclosed. After all, this actually happened at a time when the Bitcoin market cap was less than ours is today, but our current codebase is not much younger than that post. The security of the chain is the most important thing there is because without it, there is no value. The reason for CSV is that it allows for bi-directional payment channels using P2SH. So this is more of an enabler than a feature. It could enable Lightning, or something more intricate that allows transparent payment channels with cross-chain settlement. As a framework, this enables a lot of L2 solutions that we can work with later so I think this is worth doing. Assuming for now that we want to keep the issuing chain at least intact at its core, we'll likely need a payment channel solution eventually, because there is no way to do high tps on a PoW chain because of blocksize vs speed-of-light constraints - nor any chain mechanic that doesn't preselect its block producer for that matter. If our transaction volume explodes, I think that we're bound to need cross-chain payment channel solutions at some point. It doesn't have to be Lightning as designed for Bitcoin, but the ability to at least set up payment channels without needing to pre-fund multisig addresses needs to be there if we'd want anything remotely like an L2 solution. It's also important to note that a fully secure payment channel using CSV needs to have some guarantees about malleability too.
The question regarding segwit is how far we would take "standards compliance", where the standard is - like it or not - the Bitcoin Core implementation. Until now, staying compatible with Bitcoin's base stucts and serialization, Litecoin's scrypt and Namecoin's AuxPow has enabled a handful of wallet/service integrations that would otherwise have been difficult and maybe would not have happened at all. Divergence will probably lead to friction with adoption, and we really are in need of adoption. Overtaking the segwit extension framework from Bitcoin, or using EB, or doing non-standard structs/serialization, all have different impacts on 3rd party implementations and we have to weigh those carefully. As a reminder, no one can possibly like how the 1.14 fee enforcement is still haunting us (this literally is 6 lines of non-consensus code) and makes me wonder if we can actually make our own standards and get it adopted, especially when it's providing the same functionality as a Bitcoin solution, but in a bespoke jacket. Did you have a particular implementation in mind that is better than Bitcoin's segwit extension, i.e. something that exists and is field proven? |
Beta Was this translation helpful? Give feedback.
-
AFAIK, BCH implemented provisions of BIP 62. Pros: Simple, doesn't need new type of wallet, doesn't have stupid notion of "weight" which doesn't make sense for Dogecoin. Cons: Signatures are still mixed with signed data.
If/when BTC code will no longer suit Dogecoin's needs, it will be because adoption will be great, and we will need a new approach to allow further growth. And differences in implementation don't necessarily cause incompatibility. |
Beta Was this translation helpful? Give feedback.
-
In general, I think it's good to enforce those rules that we currently only treat as non-standard for mempool acceptance (basically only strict DER is enforced through BIP66), but this does not solve the problem that signatures change the tx hash (point 9 of BIP62.) I think that makes this solution suboptimal at best when dealing with spending queued multisig transaction outputs (as then, multiple parties can mutate the hash), so from where I'm sitting, it's not necessarily good enough.
Is your concern that wallets need to support P2WPKH and P2WSH output types? Wallets will have to change no matter what, because we desperately need better payment channel solutions. Or bech32 serialization? bech32 is already a much wider standard than just Bitcoin, and not coins close to us like LTC or DGB... but for example all cosmos-sdk implementations use it as a standard, including BSC and Terra. Even if we would not be doing segwit, bech32 is something we will have to look into (but as the note said, carefully.)
So this is very circumvent, I agree, and I suspect it mostly comes from the narrative that segwit is good for increasing blocksize. Which is something we should be extremely careful with on a 1-minute chain. How would you propose limiting witness size? Just keep it in check as part of the current block size limit? I'd be fine with that and that would kill the need for "weight".
Signature segregation (at least from tx hash input perspective) is sitting somewhere between a "SHOULD HAVE" and a "MUST HAVE" for me, see my first note in this comment. Leaning towards the latter.
I don't think we have the luxury to wait for that moment to make decisions. We need to have something in our pocket that is better than centralized bridging, with the next soft fork activation. I think of all the options that we have (EB, SB or our proposal), the current proposal is the most feasible as it's only touching well known, field-proven implementations on which scalability solutions can quickly be adapted. Looking into implementation specifics of segwit is fine with me, with the note that the less we change, the easier transition will be. But that doesn't mean we cannot change anything. Just to be clear about the alternatives: for EB, there is a conceptual issue with miner opt-in, which means we weaken security on whatever is touching extensions, and I'm not sure how SB could allow for x-chain agnosticism without falling back to an EB-like optionality - and neither are really field proven in the way we'd want to use them. |
Beta Was this translation helpful? Give feedback.
-
I think, BIP 62 could be beneficial regardless of whether we implement SegWit or not. So let's evaluate it on its own. Then if we decide to implement it, we can evaluate what benefits SegWit could provide on top of that. I think that BIP62 would be less contentious, so I propose this order of evaluation.
What protocols would suffer from that kind of malleability? Could they be amended to tolerate it? I think, it would be good to fix it, but I want to evaluate real benefits.
Yes, that would work. Currently, the cost for the network is approximated using total number of bytes in the block. I don't see why SegWit would need a different formula. What the total block size limit should be is a separate question. I am generally in favor of always having the limit that is higher than current demand.
I also don't think that we should wait that long. But while making decisions now, we need to consider pros and cons of each solution for different time frames. For shorter time frame:
For longer time frame:
What for? |
Beta Was this translation helpful? Give feedback.
-
why would dogecoin need a layer 2? no reason for lightning doge.. so probably don't need segwit either. just my two cents. |
Beta Was this translation helpful? Give feedback.
-
Faster transactions, incremental payments, interaction with other systems (bridges, sidechains, etc). |
Beta Was this translation helpful? Give feedback.
-
My suggestion is to propose these things also to the dogecoindev reddit to get actual user feedback and not just dev feedback. Please see this issue: #1849 to double blocksize at the same time as the introduction of segwit, which has received massive community support. |
Beta Was this translation helpful? Give feedback.
-
I think if we doubled blocksize at the same time as segwit, we would accomplish our goals of being peoples money. Also I think segwit addresses need to be optional. #1849 |
Beta Was this translation helpful? Give feedback.
-
Just because something is deemed "non-contentious" on BTC does not imply it is non-contentious with the dogecoin community. Please propose changes to them on the dogecoindev subreddit: https://www.reddit.com/r/dogecoindev/. BTC has weeded out everyone who wants it to scale on-chain. Dogecoin was created as on-chain scaling (10x as many blocks as BTC) so we have people in this community who support scaling on-chain. |
Beta Was this translation helpful? Give feedback.
-
Yeah, we need to discuss that. But preferably it should be a discussion with solid arguments. For each proposed change we should prepare a list of practical benefits that we expect from it. Then we will be able to evaluate benefits versus drawbacks and required effort. |
Beta Was this translation helpful? Give feedback.
-
Makes sense to me to float significant proposed moves with the reddit community, in as plain language as humanly possible of course. They may not necessarily understand the full implications, and level of argument or understanding should be weighted - ie great arguments for or against perhaps outweigh raw popularity but equally it doesn't seem very democratic to leave the userbase entirely out of the loop because non-coder folk like me, generally simply aren't going to jump on here. Twitter perhaps could be separately included via the dev channel. |
Beta Was this translation helpful? Give feedback.
-
It seems much more complex (at least proportional to the amount of benefit you get out of it) to me to introduce an entire extra proof-of-history mechanism to the consensus system to resolve RBF transaction replacement issue than it would be to either have people put up with waiting or use an L2 that gives users instant payments in addition to benefits with scale.
This is what all the wallets with autopilots are planning around. Here's a blog post from a while back discussing a lot of the thought and effort going into the design of these, and that was already from a while ago.
It's called keysend which lets you request an invoice in-protocol from a node's address and pay it there, it's been around for a while now in LND and with a plugin in c-lightning. Here's an easy tool for website owners to generate an invoice on-demand in a website. The reason it's designed like this is because payments rely on the payee providing the payer with a hash that the payee then reveals to claim the payment once it's made its way through the network. Most actual payments (at web checkouts, point-of-sale systems, etc.) involve generating a user-specfic address to send a payment to anyways, so Lightning's invoices fit into that workflow completely naturally. There's even a spec laid out (not finalized) for reusable invoices that provide multiple hashes for multiple payments. Someone that knows better should me if I'm wrong, but my intuition tells me that with PTLCs it should be possible to generate an invoice that can be reused an infinite number of times by using a derivation scheme like how HD wallets work.
I'm not sure what you mean by this. The wallet can prompt the user for whatever information
You're in luck because nodes you can already set aliases on their nodes. There's no enforcement that these being unique, but it's secondary to the public key that's used as the primary identifier. The Zap wallet already has a scheme for generating a unique avatar from your pubkey, which is a similar concept to randomart used to make node identities visually unique.
Be realistic here, that's a tremendous amount of activity to shift around. This chart shows ~3M BTC of daily volume, but that figure counts coins are spent multiple times and counts change being sent back to the wallet, so it's tricky to really say what that actually means. Someone should write an analysis tool that doesn't count coins if they're from a tx that was already counted for that 24-hr period. Anything growing at 11%/mo is pretty impressive. But what's more important is Metcalfe's Law. Which is on top of rising interest making people seek alternatives to L1 payments, that number is only going to increase. By the end of the year I wouldn't be surprised if the network reaches 30k nodes and 3k BTC in channels. I'm willing to bet on it, if I'm wrong then I'll pay you 1000 sats over Lightning. Lightning devs are very self aware and self-criticizing in their work, and there's a lot of people doing wildly different things with it. Not to be antagonistic, but pretty much every issue you've brought up, someone has put some effort into smoothing out rough edges or proposing changes to eliminate. Yeah some of it is dependent on soft forks, but that makes the soft fork all the better. Let me know if you want some more sats to play with and I'll send you 100 to go spend on satoshis.place or Yalls or something. |
Beta Was this translation helpful? Give feedback.
-
Also to extend an earlier point, when give someone an lightning node address, you can use a literal domain name instead of an IP address or onion. I'm not sure if there's a spec set up for connecting to an IP without a pubkey due to how the handshake works, but it should be possible to connect, ask for a pubkey on the fly to finish the handshake, then verify it in the DHT later to verify identity properly. |
Beta Was this translation helpful? Give feedback.
-
Yeah the benefit there is you don't need adoption. People are automatically using it. There's no 'if'. Also makes mining fairer. "This is what all the wallets with autopilots are planning around." I think that would be ideal. If you are trying to change user behavior, it should be minimal. Preferably essentially work the same as the mainnet. "Most actual payments (at web checkouts, point-of-sale systems, etc.) involve generating a user-specfic address to send a payment to anyways" You sort of need all types of payments though if your going to try to avoid all onchain scaling. People can and do make payments that aren't set up this way for fiat. Good that someone is working on a way to leave open channels to pay any continuous amount it, so this should be solved. "I'm not sure what you mean by this. The wallet can prompt the user for whatever information" I mean having two different types of wallet address is going to confuse some people. Basically assume the users are very drunk, and imagine what might go wrong. Ideally the lightning wallets can determine if it's a normal main net address and vice versa because people will try sending to the wrong types of addresses if they have two wallets. That's all I meant. If you have two different shaped slots, and to different shaped, assume both blocks will be shoves in both slots. "Be realistic here, that's a tremendous amount of activity to shift around." That's the idea though right? Like in order for offchain scaling to avoid any and all onchain scaling, indefinitely, it will need to take the vast majority of all network traffic. It can't just be some. You need to change most (and here most really means more than half more like 90-99%) users behavior, otherwise you'll just have to scale onchain anyway. That's the rub when it comes down to it. Nobody knows to what degree l2 will be adopted. So it contains a degree of speculation. An unknown - the actual future. If planning for all scenarios, and all probabilities, you have to scale onchain anyway. A pragmatically realist view might be that neither can be counted on, alone, to do the job. Even in the shorter term, adoption of an l2 would need to be fairly high. You can go from under capacity, to over capacity in a network in a small and hard to predict scale of time. It's one thing to like a solution, it's another to bet the farm on it. |
Beta Was this translation helpful? Give feedback.
-
i cant wait for segwit on doge |
Beta Was this translation helpful? Give feedback.
-
Cool, so soon?
…On Wed, Sep 29, 2021 at 4:35 PM shibe2 ***@***.***> wrote:
@buzztiaan <https://github.com/buzztiaan> What applications/protocols
will you be using that require or benefit from SegWit
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#2264 (reply in thread)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAHFSMEYKGX6TD43ZWJT2OTUEMP4FANCNFSM46GEBQ4A>
.
Triage notifications on the go with GitHub Mobile for iOS
<https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675>
or Android
<https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>.
|
Beta Was this translation helpful? Give feedback.
-
I'd like to make a best practices list for software/hardware to run a doge
node, also including
safety protocols. I could make a little booklet/video too. If anyone has
input I'd love it.
If appropriate, I can post docs on github for review. Please advise, oh
great shibes. Cat
…On Wed, Sep 29, 2021 at 12:11 PM buZz ***@***.***> wrote:
Cool, so soon?
On Wed, Sep 29, 2021 at 4:35 PM shibe2 ***@***.***> wrote:
> @buzztiaan <https://github.com/buzztiaan> What applications/protocols
> will you be using that require or benefit from SegWit
>
> —
> You are receiving this because you were mentioned.
> Reply to this email directly, view it on GitHub
> <
#2264 (reply in thread)
>,
> or unsubscribe
> <
https://github.com/notifications/unsubscribe-auth/AAHFSMEYKGX6TD43ZWJT2OTUEMP4FANCNFSM46GEBQ4A
>
> .
> Triage notifications on the go with GitHub Mobile for iOS
> <
https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675
>
> or Android
> <
https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub
>.
>
>
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<#2264 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AS7OED7FKDM3VEOILF2NBSTUEM3CFANCNFSM46GEBQ4A>
.
--
Cat Mayville
President, Spot Digital Media
404-357-4503
|
Beta Was this translation helpful? Give feedback.
-
How do you consider segwit non-contentious? It literally caused a massive split in Bitcoin community? |
Beta Was this translation helpful? Give feedback.
-
@Drael64 @GiverofMemory @Crybso @gubatron Hey everybody, hope all is well, it's been a while. Just wanted to follow up on the bet I made that nobody ever took me up on. Looks like I was a month and a half early with the >30k channels and >3k BTC by the end of the year estimate. And the momentum doesn't seem to be slowing down any time soon! 😎 ⚡ Here's a picture I took of paying for a tungsten cube over Lightning the other day, so yes it really does work. (Apologies for the crappy picture. And now that I think about it I feel like a fool for not blurring out the QR code, not that it's really a privacy leak at this point.) |
Beta Was this translation helpful? Give feedback.
-
So I have an idea that I think would be huge for Doge. I'd like to call it the Doge Long Split. The concept itself is actually very simple. I think it would also make Doge a more viable player vs the big crypto in the future and anyone currently holding Doge would have the potential to make a ton of cash. So assuming Doge got on board, the idea is simply this... in a Quarterly Report or Press Release Doge announces that once the price of Doge reaches the Equivalent of $1 (US) the price will remain locked in there. Then so long as demand for the currency continues to grow holders would receive increased fractional units of Doge based on stated proportional increase. Which I would like to call the Doge Long Split. So what's the purpose of this idea it doesn't really change anything right? Well it depends how you look at it really. If in the future an average person goes to a store and wants to buy a candy bar for $1 they would have essentially 3 options to pay for it...
Now obviously growth in demand for of any currency will drive up it's value. So there's really no new or exentuated growth taking place here. Except that it's a very easy concept for "average" people to wrap their head around. Also, it's a very easy way to excite growth for Doge currently trading around 6 cents to make the move up towards An finally, Doge would be the best company to first make a move like this. Why? Because, they've been sighted to break $1 at some point in the future by tons of advisors anyway. They generally are seen as a viable crypto currency. An crypto's like Bitcoin and Ethereum are so far out of range it's just impossible. Let me know what you think! Would especially like to get some input from anyone working for Doge |
Beta Was this translation helpful? Give feedback.
-
Sorry to bump this thread but what did all this resolve to after the discussions? Conclusions? I'm aware that development always takes a while but what are the actionables for the community to work on/test? Taproot was successfully deployed so that's something to consider now. :) |
Beta Was this translation helpful? Give feedback.
-
I posted this once before and I'm just gonna post it here again.... food for thought.... So I have an idea that I think would be huge for Doge. I'd like to call it the Doge Long Split. The concept itself is actually very simple. I think it would also make Doge a more viable player vs the big crypto in the future and anyone currently holding Doge would have the potential to make a ton of cash. So assuming Doge got on board, the idea is simply this... in a Quarterly Report or Press Release Doge announces that once the price of Doge reaches the Equivalent of $1 (US) the price will remain locked in there. Then so long as demand for the currency continues to grow holders would receive increased fractional units of Doge based on stated proportional increase. Which I would like to call the Doge Long Split. So what's the purpose of this idea it doesn't really change anything right? Well it depends how you look at it really. If in the future an average person goes to a store and wants to buy a candy bar for $1 they would have essentially 3 options to pay for it... Spend .0000487805 Bitcoin units with which just sounds very strange and hard to wrap your head around (especially for average person) even if you know it's just $1. An finally, Doge would be the best company to first make a move like this. Why? Because, they've been sighted to break $1 at some point in the future by tons of advisors anyway. They generally are seen as a viable crypto currency. An crypto's like Bitcoin and Ethereum are so far out of range it's just impossible. Let me know what you think! Would especially like to get some input from anyone working for Doge |
Beta Was this translation helpful? Give feedback.
-
I can't speak for segwit, but CSV sounds really useful. besides just time-locked escrow it could be useful for everyday people who lack self control when saving. |
Beta Was this translation helpful? Give feedback.
-
Hello, I saw some posts on Reddit, thought to check up on whether Doge has SegWit. Anyway, I'll just drop my 2c here. It's useful to have signatures separate so pre-signed chains can be immutable, however if you're OK with hard forks then you can do better and do stuff in more elegant way. Even the CHECKSEQUENCEVERIFY can be done better as HF and avoid the annoyance of a -VERIFY opcode leaving the item on stack, consequence of shipping it as a SF. @UsaRandom is right, it would be very useful, like if you want to do atomic swaps with other chains. Also, if you have covenants, then you don't need to rely on multisig hacky way of enforcing money flow and can just specify it directly with Script. Maybe you guys should consider following BCH upgrades instead, we've been busy during 6 years of independence: we implemented BIP-62 malfixes, got CSFS, Schnorr sigs, covenants, upgraded VM arithmetic opcodes to int64, added full set of TX introspection opcodes, got UTXO DeFi & native tokens (extension of TX output format to support token state, and we did it in a non-breaking way when it comes to non-node software). Also, we removed RBF/CPFP garbage so we can optimize mempool processing (we respect 1st seen rule) and so we can now support unlimited 0-conf chains in mempool. OP_RETURN is total limit of 223 bytes/TX and you can split that to multiple outputs, which is useful for some apps. Upcoming: in May '24 we will activate adaptive blocksize limit. Follow in our footsteps and you can make use of our smart contract tooling (higher level smart contract CashScript language, BitAuthIDE for Script assembly) for free. |
Beta Was this translation helpful? Give feedback.
-
While we do hard forks, our upgrade philosophy is the familiar "WE DO NOT BREAK USERSPACE" :) We're happy to break node-to-node compatibility (HF), but we're very careful not to break anything else. Not all HFs are the same. This is why we dropped PMv3 which would've segregated signatures at TX level, and that would break non-node sofware that would assume they just hash the raw TX blob to get TXID. I wrote a little technical bulletin that describes this in more detail, and describes a methodology on how to extend TX format in a non-breaking way: Bitcoin Cash Node Technical Bulletin - Evaluate Viability of Transaction Format or ID Change |
Beta Was this translation helpful? Give feedback.
-
I've done some reading and thinking on CSV and in general it seems uncontroversial and useful (I have a couple of implementation questions such as "is the 512-second window useful for Dogecoin" and "can we avoid the implementation issue that necessitated BIP-147", but let's leave those for the actual implementation. I'll do the same for segwit, but so far this plan seems sensible to me so I'm comfortable proceeding. |
Beta Was this translation helpful? Give feedback.
-
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
With the next major release, we plan to propose 2 protocol changes for activation at once: segwit and csv. Both have been deployed on Bitcoin's mainnet for a longer time and are considered non-contentious. As such it will save us all time when we do them at once instead of sequential. 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.
A block versions 5 and protocol version 70016 will be proposed for this implementation.
Details
In scope
Not in scope
Deployment
Deployment 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.Comments / questions? Let us know here.
Beta Was this translation helpful? Give feedback.
All reactions