Proposals, Confidential Transactions and what is DigiByte doing?

I’m super happy to see that the Litecoin team have put together 2x LIP’s to add Extension Blocks (EB) and Confidential Transactions (CT) through MimbleWimble (MW).

I’ve been asked a few dozen times over the last couple of days to provide my thoughts on this, so rather than repeating myself a bunch I thought it would provide a good opportunity to write a brief-ish Medium post that will hopefully bring you up to speed too on what these LIPs mean. Hopefully this is also not overly technical, as most other discussion around it seems to be, and this is a lot more brief than other 20+ minute reads that I’ve seen. I’m also explaining a little about how it differs from DigiBytes process.

tl;dr: This is great to see, and I sincerely hope Extension Blocks get implemented in to Litecoin even if MW does not. I think MW is a great use of Extension Blocks / side-chains, and paves the way for a number of other interesting things with EB, despite the fact I don’t personally think the MW side-chain will be utilized very much.

The proposals can be seen here:

Extension Blocks: https://github.com/litecoin-project/lips/blob/master/lip-0002.mediawiki

MimbleWimble: https://github.com/litecoin-project/lips/blob/master/lip-0003.mediawiki

What do these mean? Where are LTC at?

Well, we have the proposals, in and ready for show-time (and feedback)!

At the moment the Litecoin team have had input from David Burkett (developer of Grin++ wallet; Grin also uses MimbleWimble) on Extension Blocks and the MimbleWimble sidechain implementation.

David has helped Andrew (ecurrencyhodler) and Charlie Lee write these LIPs (Litecoin Improvement Proposals — 002 & 003). These LIPs detail the need for Extension Blocks first of all, as a side-chain to place the Confidential Transactions in to. Then they detail the Extension Blocks would be followed by the actual MimbleWimble implementation itself (LIP overviews this) and a few specifics on how they envisage it would work.

MW will not be implemented in the underlying “Core” layer of the blockchain, but rather as an opt-in “only if you want to seek it out” addition on top of LTC in these EBs. The reason EB’s are required for MW is because they don’t want to hard-fork Litecoin, and require everyone to upgrade their Core Wallets to support MW.

However, because of that decision it means that like ZCash, MW “privacy transactions” are opt-in, and if ZCash is anything to go by for the “optional” privacy, then very few (<2%) actually utilize it. Still, at least the option is there for those who do want to use it.

This is now being put to the community for feedback and response.

This is all good progress!

I think it’s great to see Litecoin taking the opportunity to differentiate itself from Bitcoin, something that I’ve felt is needed for a while despite it being an unpopular opinion. Although MW is opt-in, it would further cement Litecoin as “Not just a 4x faster BTC”, but with a key differentiation, not to mention I personally like the notion of EBs (Despite being an on-chain scaling proponent myself).

Granted it’s taken 9 months to get this together since Charlie Lee stated “I am now focused on making Litecoin more fungible by adding Confidential Transactions”, but it’s still more progress than the MAST suggestion ever got in 2017 (How’s that demo going?).

At least there’s still two months left in 2019:

Where-to from here for EB / MW for LTC?

From here, there’s going to be several steps:

1/ Taking feedback (Already happening)

2/ Clarification from exchanges around de-listing “privacy coins” (As this has already happened to a number of others such as ZCash / Monero etc), this was requested as part of the feedback (1)

3/ Coding, coding, more coding, to implement both LIP proposed changes in the Litecoin Core Wallet, it’s going to take a LOT of work.

4a/ Releasing the Core Wallet with the update for EB / MW

4b/ Testnet implementation, to test out the “Go-live”, and how it functions

NOTE: 4a & 4b will likely happen around the same time.

5/ Signalling begins to occur on Mainnet

6/ Signalling has to reach 75% of all mined blocks over a specified period, in order to be “locked in”

7/ A short “grace period” is given (1 week?) to allow other miners the opportunity to upgrade to EB / MW supporting versions if they so desire

8/ Success!

9/ Bonus: Implementing EB / MW on non-Core wallets, such as Loafwallet etc

Why is this so different from how DigiByte did the Odocrypt upgrade?

That’s a great question. I can’t speak as to why Litecoin have gone down this path now for EB / MW, when they didn’t so much with SegWit. I would suggest that SegWit appeared to be a lot more contentious at the time. I can only presume this is because BTC had done all the work with SegWit and the code simply needed an hour or two of merging, whereas this will require significant man-hours to code up almost completely from scratch. Very significant development time.

Still, Charlie / Andrew / David have formalized their 2x proposals to take feedback on, before commencing any coding, and that does make a lot of sense given this is new ground being broken. MW has been implemented in other blockchains such as Grin, but not in EB’s like this before.

In a nutshell, what we have is Charlie, Andrew & David saying “We’ve got this great idea, but we’re not 100% certain on a few things” (And that’s OK).

With Odocrypt, the implementation was completely finalized and done prior to “putting it to the community” so that DigiByte devs could say “Here’s what we’ve got planned, we’ve done it, we’ve tested it on Testnet, we’re positive this is beneficial, this is why we think it’s going to be great, it’s now up to you to implement it or not”.

Neither is specifically better than the other, however it’s clear the Core DGB developers were entirely confident in Odocrypt and the implementation, which is why it was coded up and the upgrade tested on Testnet so it could be presented as “Here, it works, do you want it or not?”

The community still had their vote on it through miner signalling, much in the same way that Litecoin will be doing with their proposal here.

So if Miners don’t upgrade to an EB / MW supporting version, they won’t signal support for it. If Miners do upgrade, it will signal support by default.

Same goes for when DigiByte did Odocrypt. Core Wallet 7.17.2 included signalling support for Odocrypt by default, so when people upgraded to that version, blocks mined would signal support for it. They also got the added benefit of Dandelion.

How does MW differ from Dandelion++ in DigiByte?

When we implemented Dandelion++ in to DigiByte Core 7.17.2, that was not designed to be completely “confidential”, as MW is.

Dandelion obfuscates your IP address to an acceptable degree of certainty so that any “watchers” on the network cannot ascertain your source IP address, which could potentially be used to link to your physical location.

MimbleWimble by contrast obfuscates the amounts being transmitted, so watchers on the network wouldn’t know if you’re sending $1, or $1 million.

Litecoin could (and I would say “should”) implement Dandelion++ as DigiByte has, to best compliment EB’s / MW. Dandelion++ is also implemented in to Grin so I would imagine it’s likely something they will look at too, even though it’s not directly discussed in the LIPs.

How will DigiByte handle the ProgPOW upgrade?

The code will be implemented in to DigiByte Core, and it will be up to the community to decide if they want to upgrade to a ProgPOW indicating + supporting version, or not. There is absolutely nothing stopping anybody from implementing something, such as Lyra2Rev3 instead.

I began work a short while ago implementing ProgPOW myself. Unfortunately I’m no coder so it’s not entirely completed, I’m just a mediocre copy / paste monkey. Since then, we’ve had Kristy-Leigh Minehan (The “If” part of “IfDefElse”, ProgPOW authors) on the DigiByte and Friends show to talk about ProgPOW. She has offered to assist with implementation of the latest version (I was inadvertently working with ProgPOW 0.87 where as she will help us implement the latest 0.93).

This is super exciting and I’m incredibly grateful for her offer.

Will DigiByte be implementing Extension Blocks / MimbleWimble?

At this stage there are no plans to implement either Extension Blocks or MimbleWimble in to DigiByte Core.

With the recent addition of Dandelion++ as a very “low impact / high win” optional privacy improvement for users. This protocol improvement is available not just in the Core Wallet, but in Android & iOS DigiByte apps as well!

DigiByte development is currently centered around DigiAssets, as well as algorithm replacements to ensure the further improvement of our already shining decentralization and distribution.

That said, as is the case with any development, DigiByte is not a centralized blockchain, but a decentralized permissionless project that allows contributions from anybody, and there’s nothing stopping somebody from proposing and / or implementing EB / MW for DigiByte, then recommending the network upgrades.