Consensus plan for next major release (1.21)

[patricklodder]

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

• Segregated witness a.k.a. segwit
  • Functionality: Separates spending proofs (i.e. signatures) from transactions when embedded in blocks
  • Rationale: Further reduces transaction malleability.
  • Scope: BIP141, BIP143 and BIP147
  • Note: we will carefully consider P2W* addressing.
• CheckSequenceVerify a.k.a. CSV
  • Functionality: Allows consensus-enforced locking of an output until a relative time and exposes the field to redeem scripts
  • Rationale: Allows for much more sophisticated redeem scripts, must-have feature for Lightning-like L2 networks.
  • Scope: BIP68, BIP112 and BIP113

Not in scope

• VersionBits - Needs another, more dangerous soft-fork, see [tracker] AuxPoW <-> BIP9 Compatibility #1340 and Make AuxPoW consensus params versionable #1344. We deem this too risky to do at once with the features described above, especially for a meta-feature.
• TapRoot - Not yet deployed on Bitcoin
• Extension Blocks - Not yet deployed on Litecoin

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.

[shibe2]

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.

[patricklodder]

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.

[shibe2]

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.

[patricklodder]

Replying in reverse order, because it suits my narrative better, sorry:

I am a bit pessimistic about cool new features, they often go unused in Dogecoin. [..] When there is already a demand for some feature, its benefits are more clear.

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.

I propose evaluating expected benefits of these protocol changes and decide where they are worth implementing at all at this point.

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.

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.

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?

[shibe2]

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?

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.

Divergence will probably lead to friction with adoption, and we really are in need of adoption.

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.

[patricklodder]

AFAIK, BCH implemented provisions of BIP 62.

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.

doesn't need new type of wallet

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.)

doesn't have stupid notion of "weight" which doesn't make sense for Dogecoin

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".

Signatures are still mixed with signed data.

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.

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.

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.

[shibe2]

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.

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.

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.

How would you propose limiting witness size? Just keep it in check as part of the current block size limit?

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 don't think we have the luxury to wait for that moment to make decisions.

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:

• What will it take to implement and activate the change?
• What benefits we will get soon after it's implemented?

For longer time frame:

• Does it create technical debt?
• How will it affect future available choices?
• What benefits it could give in the long term?

We need to have something in our pocket that is better than centralized bridging, with the next soft fork activation.

What for?

[vovanloc0798]

Hihi

[jaybny]

why would dogecoin need a layer 2? no reason for lightning doge.. so probably don't need segwit either. just my two cents.

[CHIPofficial]

layer 2 for defi maybe???

[shibe2]

why would dogecoin need a layer 2?

Faster transactions, incremental payments, interaction with other systems (bridges, sidechains, etc).

[GiverofMemory]

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.

[GiverofMemory]

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.

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

[GiverofMemory]

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.

[shibe2]

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.

[Drael64]

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.

[delbonis]

@Drael64

It should at least in part resolve things like double spend, in theory.

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.

A simple - transfer into wallet, and use just like regular main net coins, I could live with (although even then, with already fast/cheap mainnet it's arguable it wouldn't see anywhere near majority adoption)

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.

you can't do tips, donations or send spontaneous payments

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.

they'll need to make sure one address type doesn't work for the other wallet

I'm not sure what you mean by this. The wallet can prompt the user for whatever information

where people can register more straight forward aliases for their addresses.

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.

I also wonder if a layer 2 scaling was actually somehow successful enough to take more than half of the transaction load of the mainnet

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.

[delbonis]

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.

[Drael64]

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.

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.

[buzztiaan]

i cant wait for segwit on doge

[shibe2]

@buzztiaan What applications/protocols will you be using that require or benefit from SegWit?

[buzztiaan]

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>.

[shibe2]

That was a question, not a statement. Sorry, I initially omitted the question mark.

[kitcateleven]

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

[patricklodder]

Hey Cat. Sounds good. Once you have something, just create a new post here in general discussion so that people can leave feedback / add ideas?

[gWOLF3]

How do you consider segwit non-contentious? It literally caused a massive split in Bitcoin community?

[patricklodder]

Did segwit or did block size? Either way, old news, it's contentious now.

[delbonis]

Is it really contentious now? It seems like there's little disagreement around it anymore.

[patricklodder]

In this thread? Yes. I see no consensus. Instead what I see is that people make the block size an issue even though it doesn't have to have anything to do with separating transaction witnesses from transaction bodies so that the identifiers aren't as malleable. So perhaps it's contentious because shibes want to live bitcoin drama too? I don't know.

I think the initial challenge, that maybe it's better to take a very good look at what parts of segwit makes things better and what makes it more complex, still stands. I haven't seen any real answers to that. Maybe I'll do a new proposal when I'm done fixing bugs.

[delbonis]

@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.)

[patricklodder]

I too was looking to invest in tungsten cubes the other day. Ran into portability issues. 😉

[DLSplit]

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.
For Example: An increase of .01 (1 cent) would give the holder of 100 units of Doge an extra unit (or share).

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...

1. 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.
2. Spend a crusty old $1 bill cash currency which might be less welcomed and undervalued in the future.
3. Spend $1 locked in Dogecoin, which almost like a savings account continues to grow quantifiably with little to no effort on your part.

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 $1. Which would potentially mean a lot of $$ for anyone currently holding.

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

[patricklodder]

I don't even know what Chainlink is.

https://chain.link/

I'm just a guy that gets notifications of your shouting and is pointing you in a direction that may help you actually succeed ❤️

[DLSplit]

So I read up on the chainlink, an yea your right Patrick that could be the solution right there.

Do you think if Doge were to create a relationship with chainlink, partnership, or even just use there services Doge could be adapted to follow US Dollar pricing potentially or theoretically?

[patricklodder]

Despite popular beliefs and misinformed masses, "Dogecoin" isn't an entity that can create relationships. It's a consensus software for cryptocurrency that powers a permissionless network, which is, in this repository, integrated and copyrighted to every developer that ever contributed to it. It cannot create relationships, because it's not an "it".

What you can do is create your own thing using the value that the network provides (because it is permissionless). I read the essence of what you're proposing to be that if the asset, DOGE, were to be less volatile (note: it shouldn't really matter at which price point and measured against which asset), you could create some MKR-style over-collaterized IOU token from locks (like DAI) that is pegged to some other currency (like USD).

I think that if you execute that right, it can potentially succeed. DOGE itself cannot be pegged to the dollar, that's also not the premise of its model (it actually gets minted to miners), but the part where you lock value to create different value, is definitely possible.

[GiverofMemory]

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. For Example: An increase of .01 (1 cent) would give the holder of 100 units of Doge an extra unit (or share).

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...

1. 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.

2. Spend a crusty old $1 bill cash currency which might be less welcomed and undervalued in the future.

3. Spend $1 locked in Dogecoin, which almost like a savings account continues to grow quantifiably with little to no effort on your part.

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 $1. Which would potentially mean a lot of $$ for anyone currently holding.

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

We seem to have been thinking along the same lines, see discussion #3007 for a workable method

[GiverofMemory]

This reminds me of ampleforth, take a look it rebases and debases how many coins you own to try to keep price to $1. I would say it hasn't been working too well but it might improve over time.

[delbonis]

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. :)

[GiverofMemory]

Excellent writeup thanks for that.

Of course the 95% was arbitrary, it sounds good but when I think about it more it only takes 50.1% of miners to actually make a change to get a hardfork. The difference is that 50.1% would have to take a huge risk and financial loss to carry it out, whereas just signaling is no risk or loss. I think a number between 60% and 95% would be reasonable for a soft fork and probably best to stay around 90%+. When it comes to a hardfork, that should probably be higher consensus than soft fork logically, but not sure in terms of logistically. I mean, from one perspective you would think if 50.1% of miners are signaling for something than it would be a simple majority rule, but I think higher than that should be required for a "better safe than sorry" policy and favoring a little inertia.

I agree having consensus building in parallel for different proposals should help.

For CSV do you mean using timestamps instead of blockheight? I suppose but timestamps are arbitrary and miners can just make them up anyway. Also if we lower our blocktime that will of course help with how unpredictable timing is, more granularity. Blocktime is probably just as variable for other blockchains, I see bitcoin going 30 mins between blocks often.

For segwit my concern is that omitting signatures from the blockchain is a huge risk when you think about it. Miners would have to 'pinky swear' to cross verify with the signet to verify everything checks out. Now instead of just having the blockchain to maintain, we also have a signet, and on top of that we have our auxpow which is the entire litecoin blockchain we also have to maintain. Satoshi put everything needed on the blockchain for a reason, so that as long as you have that you have everything.

BIP62 was proposed to fix malleability of all types without segwit but wouldn't be sufficient for lightning channels which is ok for us I think. Also segwit adds mess in that we will have endless debate on whether people should be using segwit or legacy addresses and since we have room in our blockchain for the addresses, there is no real reason to bifurcate the blockchain.

For lightning, even if it could be done without segwit, my main problem with it is custodial in nature, every lightning wallet is custodial. Yes you can run your own channel but you have to pre-lock in all of the channel funds and it takes 2 tx for each channel, one to set up and one to break. Why, when with dogecoin you can already instantly send to anyone anywhere non-custodially and without locking and unlockimg funds and managing a channel? Lightning is a subpar experience and was only done because bitcoin refuses to scale on the base layer. It has been around for what, almost 10 years and still no one really uses it. With dogecoin it would be a distraction and just another way to measure dogecoin to bitcoin and push the narrative that bitcoin is superior. I think we should focus on our strengths which is base layer speed and thouroughput, which we beat bitcoin on and will always beat them, and actually be less centralized than they are going to be when the majority of their payments are on lightning.

In terms of atomic swaps I think that is very important since centralized exchanges are a huge problem. I think there could be other more streamlined solutions to atomic swaps rather than segwit+lightning - all I think we would have to do is fix malleability which is much less bulky than adding an entire new chain (signet) and having an empty lightning network. But I do understand the draw because it would be much easier to just plug in the segwit and lightning code to get the functionality. If that were done which I think would be a bad path, but at least we should probably not name it lightning and rather pare down the functionality to be as basic as possible to achieve what we want it to achieve and we should not promote the use of segwit addresses, and suggest shibes only use legacy addresses for standard transactions.

[patricklodder]

1. Block timestamps are validated and CSV is checked against median time, not the exact timestamp from the miner
2. Splitting signatures off from the transaction in full is an implementation choice and we can implement backward compatibility differently. Since it anyway was suggested that we don't really want vBytes, we have to work on this regardless. Need to spec it out properly if this is what we do.
3. BIP62 does not fix signature malleability, but it's a good BIP nonetheless and we should consider implementing it even with segwit - we already implemented the strict der signature part in 1.10.0 and that softfork went fine. The lack of protection against re-signing is literally described in the doc in the last paragraph of "motivation" and this is important for ANY multisig ops that aren't trusted. If BIP62 fixed this, we wouldn't need segwit at all. Unfortunately, segwit solves a real issue because using a malleable identifier for inputs is not optimal when chains of transactions can go into the mempool and more than just one signer can race a tx when there is no mempool consensus (hint: there won't be, we'd need a separate blockchain for the mempool then, and no, let's not). We should imho just look at the technical merit of a change, not what Bitcoin communities have been waging a pointless war over for years. To make it clear I am not picking sides in any bitcoin vs bitcoin war, if we opt to re-spec (I think we should) I am totally ok with not calling this segwit, but something dumb: verysignatureseparation. With that, all the BTC and BCH purists will hate us once more, so nothing changed.
4. Please also note that securing multi-party transactions against a malicious minority is in reality also a request from several bridge developers and not just something that benefits only Lightning. That really is just maxi banter.
5. bech32 is more flexible than base58check as we have it now, because it allows for a larger identifier in the hrp, versioning, and I would recommend implementing it regardless of segwit (it's already in 1.21, just we haven't defined address templates for it). base58 won't stop working and if we don't implement vBytes, there is no financial incentive over using one or the other to the user. The only reason to use it would be when a user wants to use a script template that is not p2sh or p2pkh.

[delbonis]

You might be able to effectively eliminate the math complexity with vBytes just by changing how the limits and weighting are calculated, although it sounds like you'd want to / already have reshuffled more than that to strip out now-unnecessary code.

[GiverofMemory]

@patricklodder I like how you are thinking about this.

If we could implement segwit (and I like your idea to rename it) in a way that requires the signatures be present, I have no problem with it and I don't think others would either. In that case it would just be restructuring the blocks in a way that prevents malleability. The problem is, and I think BCH was also considering something similar, is that I don't think anyone has come up with a way to do that without a hardfork, and most of the BCH community actually support a segwit hard fork. If we can maintain backwards compatibility while also requiring validated signatures to be present with only a softfork, then all the better and I'm sure BCH would be interested too. I am also not opposed to a hardfork, and I think having a hardfork tentatively scheduled every 4 years for dogecoin is a good precedent to be a living protocol.

As far as the bridge developers we should be very careful. We should make it very clear to the community that these bridges, while within our spec, are still potentially not fully secure and that there is a substantial risk in using them and we should reference the fiasco happening with SmartBCH (SmartBCH was branded as a sort of the official BCH EVM, and lots of people got hurt because of that, including myself).

With Bech32 we need to be careful of unintended consequences. Have you heard about what just happened with taproot? A single transaction can now be 4mb with an 80% fee reduction (due to the witness data discount) now regular tx's have to bid against those at a disadvantage. The Bitcoin developers obviously didn't intend that (barring a conspiracy to cause blockspace to be super expensive or to initiate miner censorship). So we need to have a review including several devs before changing the checking mechanism imo. Even though nothing has happened yet to bitcoin, it is still relatively young change and some vulnerability might be discovered.

Also we could check BIP140 for another potential malleability fix soft fork instead of/in addition to BIP62 HOWEVER I just noticed it uses Schnorr signatures which might make us vulnerable to the Taproot bug and here. More discussion on BIP140 here and elsewhere on reddit. Plus I don't like schnorr for other reasons as well, it basically does the same thing as segwit. It looks like the spamming can be done with just segwit too .

From my perspective the moral of the story is that Bitcoin has made very poor design decisions in my opinion after Satoshi and Gavin left, and is headed down a bad path. We should stay as far away as possible and we will become the leading store of value (SoV) and digital cash dual purpose blockchain in the future. It is like video games in my view, the ones that try to be everything to everyone eventually start crumbling. If people want a sidechain or EVM, there are other coins with that. I don't think everyone should need to keep all of their coins in Doge, and having a few different ones is a good thing and healthy not only for the users but also the coin itself, so it can focus on what it is best at.

[patricklodder]

If we could implement segwit (and I like your idea to rename it) in a way that requires the signatures be present, I have no problem with it and I don't think others would either.

Sure. This isn’t a crazy requirement.

As far as the bridge developers we should be very careful. We should make it very clear to the community that these bridges, while within our spec, are still potentially not fully secure and that there is a substantial risk in using them and we should reference the fiasco happening with SmartBCH (SmartBCH was branded as a sort of the official BCH EVM, and lots of people got hurt because of that, including myself).

The problem here is one word and one word only: “official”. There is no such thing because you can publish your own software and if everyone uses that, then that’s it. There cannot be any official because of that. Anyone that uses the word in combination with Dogecoin (or BTC/BCH for the same reason) is making a mistake. The only place this goes is with tightly managed ICO coins.

I’ll always try to warn but it is not my responsibility nor should anyone ever do something just because I say it.

With Bech32 we need to be careful of unintended consequences. Have you heard about what just happened with taproot?

That is not related to bech32 (it simply is a means to encode enumerated script template parametrization into something human readable, just like base58check addressing, but with a much better checksum and optimized for QR codes AND readability) and also not to taproot or Schnorr - it’s ONLY about the scope of IsStandardTx() and that is (a) policy and (b) something we have today too: without bech32, without segwit, without taproot, without Schnorr. The issue simply is that people were expecting that transaction policies were strict and preventing this, but it wasn’t. Oh and others were expecting that this were a consensus rule. That’s all there is to it: unrealistic expectations. I cannot think of a chain where you cannot do this fwiw. Simple field abuse. Happens all the time. I think it's not great that it happens, but you cannot end-to-end protect against it.

The Bitcoin developers obviously didn't intend that

It really doesn’t matter what a developer intends and we all know that no plan survives contact with the battlefield anyway. In fact, this entire drama makes me think that we need to deeply look at all policies and see what is non-configurable. Because it is dumb af to put developers in charge of a network, it has been proven to be that with Dogecoin as well - or do you really think I like refactoring code to be configurable? Hah! We imho just need to make sure that node operators can react to events in the wild, tune their policies without having to learn c++ (or any programming language) and do our best as software maintainers to have reasonable defaults that are recommendations that can be completely ignored - but it ends there.

So we need to have a review including several devs before changing the checking mechanism imo

EVERY change needs that. Even trivial ones.

[DLSplit]

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.
For Example: An increase of .01 (1 cent) would give the holder of 100 units of Doge an extra unit (or share).

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.
Spend a crusty old $1 bill cash currency which might be less welcomed and undervalued in the future.
Spend $1 locked in Dogecoin, which almost like a savings account continues to grow quantifiably with little to no effort on your part.
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
$ for anyone currently holding.

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

[GiverofMemory]

I would call that the Doge Hyperinflation Plan ;)

Seriously though, this is what AMPL does however you are missing the part where when the price of the crypto goes down, everyone gets coins burned out of their wallet...

[Drael64]

I posted this once before and I'm just gonna post it here again.... food for thought....

That's just an elastic stablecoin. There's at least half a dozen of those. They contract when the price falls, and expand when the price rises. It works, mostly, although in reality it's effectively doing nothing. It's just instead of losing value, you lose coins, or gaining value, you gain coins. The effect is the same. It's just a different number changing, increasing or decreasing the value of coins in your wallet. I think that's why they never took off, because it's kind of not changing anything.

Crypto was invented to be detached from entities like govt's and central banks who tend to manage supply very poorly. Look at the last few years of value inflation. Ideally, crypto would survive contact with future catastrophic govt monetary policy, as that's kind of it's whole reason for existing. I understand that people want to kind of skip to the end, and get price stability, because that is ideal with a currency, but doing so by tethering to fiat is self-defeating. It should happen in time, when the market is large enough.

[UsaRandom]

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.
or even a "don't open till x-mas" sorta thing.

[A60AB5450353F40E]

Hello, I saw some posts on Reddit, thought to check up on whether Doge has SegWit.
I thought Doge already had SegWit, guess I was wrong.

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.
This is why BCH can now do BCH-XMR swaps even without having SegWit (we're also planning to build BCH-BTC/LTC/DOGE/EVM atomic swaps).

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.

[A60AB5450353F40E]

If we can maintain backwards compatibility while also requiring validated signatures to be present with only a softfork, then all the better and I'm sure BCH would be interested too. I am also not opposed to a hardfork, and I think having a hardfork tentatively scheduled every 4 years for dogecoin is a good precedent to be a living protocol.

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.
So, when we upgrade everyone can just swap out the node for a newer version and stuff just continues to work.
Just like when you upgrade your Linux kernel - all your apps are supposed to still work even if you don't upgrade the apps.

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

[chromatic]

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.

[patricklodder]

is the 512-second window useful for Dogecoin

Finer granularity could be better, but that comes at the cost of requiring customization for every existing implementation, so there's a tradeoff there. Also note that 1.14 unfortunately already implemented the logic so any changes here may have consequences. We can plan this though if we really want to change it.

can we avoid the implementation issue that necessitated BIP-147

We cannot avoid that BIP because the source of malleability already exists since v1.4.0 - it's a consequence of CHECKMULTISIGVERIFY

let's leave those for the actual implementation

I'm still following previous developer consensus re: doing any softforks separate from the .0 release that bumps 7 major Bitcoin Core versions. I'll expand more on that subject in a post next week that I'm preparing; but it would be good if we could touch on that decision before we finish the current 1.21 phase, even if just to confirm it.

[A60AB5450353F40E]

We cannot avoid that BIP because the source of malleability already exists since v1.4.0 - it's a consequence of CHECKMULTISIGVERIFY

For what application is this malleability a problem? There are other ways to deal with it if you want to avoid the complexity of SegWit VM-ception. Even the LN paper originally thought to use the alternative (section "Resolving Malleability", pg. 57):

SIGHASH NOINPUT would neither sign any input transactions IDs nor sign the index. By using SIGHASH NOINPUT, one can be assured that one’s counterparty cannot invalidate entire trees of chained transactions of potential contract states which were previously agreed upon, using transaction ID mutation. With the new sighash flags, it is possible to spend from a parent transaction even though the transaction ID has changed, so long as the script evaluates as true (i.e. a valid signature).

With covenants, this method can be applied more directly, which is how we now deal with it on BCH. One example is XMR-BCH cross-chain swap contract: the original BTC-XMR version requires a pre-signed multisig for the 2nd stage refund, and on BCH we just use covenants to directly enforce money flow.

Your call, but just consider the alternatives. If you don't want HFs like BCH does, consider that some BTC folks are now trying to get CSFS+CTV activated (SF). If you skipped BIP-147 and just activated CSFS (checksignaturefromstack) + CTV (checktemplateverify), you could avoid the complexity of SegWit while still being able to construct payment channels, swaps, punishment TXs etc. that wouldn't have the malleability problem.

[A60AB5450353F40E]

CSFS (checksignaturefromstack) + CTV (checktemplateverify), you could avoid the complexity of SegWit while still being able to construct payment channels, swaps, punishment TXs etc. that wouldn't have the malleability problem.

Sry, this was incorrect, you'd additionally need SIGHASH_NOINPUT mode for CHECKSIG and/or CTV, which the spec proposed for BTC doesn't support - it only supports TXID preimage:

The DefaultCheckTemplateVerifyHash commits to the serialized version, locktime, scriptSigs hash (if any non-null scriptSigs), number of inputs, sequences hash, number of outputs, outputs hash, and currently executing input index.