Don’t worry, it’s going back up thought relative to BTC; a month ago it was at roughly .0057, now up at .0074 Should continue as the (hopeful) bull market continues to run up.
Happy Leap Day!
The non-interactive transaction proposal has gone through a few design iterations this month. I believe we’ve finally got a design that resolves the issues found with the first write-up, and I’ve turned that into a LIP (https://github.com/litecoin-project/lips/pull/13). I suspect it will still take some time before the LIP has had sufficient review to be considered safe enough to accept, but I’ll continue to keep one-sided transactions in mind as I develop.
Aside from the LIP, I’ve made good progress on the validation rules, but there’s still a lot more to do. I’ve made some modifications to the original kernel design to support the ability to soft-fork in new features in the future. I’ve also started to build out the merkle mountain ranges (MMRs), which are a data structure we use to commit to kernels & outputs. Once the MMR logic is finished, I should be able to get back to the block validation logic. I didn’t get to work on the Node API like I had hoped, but that’s something I also expect to get to next month.
I’ve so far been very hesitant to give exact dates on when things should be finished, because writing blockchain software is difficult, time-consuming, and unpredictable at times. I didn’t want artificial deadlines to force us to rush through parts of the code and introduce defects or security vulnerabilities. Having said that, I think it’s finally time to commit to the first major event…
End of Summer: MW Testnet Launch - This will include all block & tx validation rules, basic p2p messaging, transaction pool, syncing, and the ability to mine blocks. This will NOT include a usable GUI wallet for casual users to test it out. Transactions will likely need to be created manually at first, or via a cli or automated tool.
Thanks for the hard work & update David.
Hi everyone! It’s that time again.
I’ve finished up the Merkle Mountain Range (MMR) logic, and wrote some good tests around that. When originally writing Grin++, this was one of the most difficult pieces to code, and ended up being one of the messiest parts of the logic. It consistently led to many frustrations and headaches for myself. Fortunately, I learned from those mistakes, and was able to design a much cleaner implementation this time.
That was the final piece I needed in place to write the validation rules. The first pass at header and block validation is now complete, but is so far only minimally tested.
The next few months will be all about integrating with the existing litecoin codebase, and lots and lots of testing. Don’t be alarmed if the updates for April and May are shorter and less detailed, as this will be one of the most tedious and least exciting parts of the project. It’s also the most crucial part though, so lots of time will be dedicated to making sure everything is integrated correctly.
Thanks again for your continued support. Stay safe, stay home, and don’t forget to wash your hands. Happy Quarantine!
Thanks for the update. We appreciate you taking time to get it right.
Much respect and appreciation your way David. Looking to donate again once this whole crisis clears up a bit. Keep up the Great Work!
Great stuff, David! These regular updates are invaluable for a project as big as this. It might seem like no one’s paying attention right now, but soon this will be very big news!
I’ve built out a functional testing framework that builds valid headers, blocks, and transactions. I’ve now got some (mostly) complete end-to-end block validation tests.
I also began integrating with the litecoin codebase, starting with the ConnectBlock logic (See: https://en.bitcoin.it/wiki/Bitcoin_Core_0.11_(ch_6):_The_Blockchain#Connecting_a_block). This is the part where blocks are validated to ensure valid UTXOs are being spent, no double spends, etc, and is also responsible for actually adding the blocks to the chain.
I haven’t created the repo for this portion yet, but will try to get that out on github sometime in the next few weeks, once I’ve had the chance to clean the code up a bit.
There’s a few different directions I could go once I finish testing the ConnectBlock logic, but I’m still deciding what makes sense to tackle next. All I can give at this time is a high level plan for May, which involves continued integration with the LTC codebase, and lots more testing.
It’s been a few months since I gave an update on the Grin++ side, so for those interested how that’s going, there’s been some big news recently. David Tavarez (https://github.com/davidtavarez) has completely taken over the UI development, so I can focus solely on the C++ node & wallet logic. He actually rewrote the entire UI (https://github.com/GrinPlusPlus/GrinPlusPlusUI/tree/1.0) and it’s much nicer than it was before. Things are so stable now that we actually have a release candidate for v1.0.0, what we’re calling the first non-beta version of Grin++. That release has been tested with the help of several Grin community members, and will be pushed to all Grin++ users this weekend.
Happy Friday Everyone!
Hi David, thanks for the update. We appreciate your hard work & we I’ll continue to raise litecoin and bitcoin to fund your work.
You are building the future!
Is there any way we could contribute with our time? I’m sure there are a lot of programmers out there that are willing to chip in especially for the mundane bits.
Absolutely! That would be amazing. I’ve had a few manual testers and 1 or 2 UI devs message me to offer help, but it is a bit too early to pull them in. I can use c++ devs at anytime though, and if I take a few days to add RPC APIs, I could even use python devs interested in writing some functional tests.
I’ve finished implementing the
ConnectBlock integration logic, meaning that when a mimblewimble block is received, it will be fully validated, added to the chain, and the UTXO set will be updated. This ended up requiring a lot more rework than I hoped, since the approach I originally took on the mimblewimble side for adding, validating, and removing blocks didn’t line up well with the existing code’s approach to handling the UTXO set using “views” and “caches” (See “Data Access Layer and Caching” here: https://en.bitcoin.it/wiki/Bitcoin_Core_0.11_(ch_2):Data_Storage#The_UTXO_set.28chainstate_leveldb.29).
The logical next step was to work on
DisconnectBlock, which will remove a block from the chain in the case of chain reorgs. However, I chose instead to start working on the mempool, with the hopes that we can soon start mining Mimblewimble blocks. Being able to mine valid mw blocks will allow us to test the end-to-end flow of including mw transactions in a block, validating those blocks, removing the transactions from the mempool, adding the blocks to the chain, updating the UTXO set, and flushing everything to disk. There’s a lot that could go wrong there, so the sooner we can get everything working together, the smoother the rest of development should go.
This is all subject to change, but for now, here’s the plan between now and the end of Summer testnet launch:
June: Wrap up mempool logic, and start mining valid chains with mw extension blocks, making sure all pieces work well together.
July: Initial block download. The way initial block download is handled in mimblewimble is quite a bit different than how litecoin does it. In LTC, every single block from the genesis block is downloaded and validated in order. With mimblewimble, we don’t need the whole history, but instead only parts of each transaction, and all of the unspent outputs. I’ll need to find a way to make those two very different syncing approaches work smoothly together.
August: DisconnectBlock logic (for chain reorgs).
September: Testnet activation logic and launch of the first mimblewimble testnet. Then start fixing everything I broke
Thanks for the update David
Courage David! It’s almost done
Nice! Great work. Thank you
This is great. I really appreciate your ability to discuss the details of what you’re working on, and your plan to tackle it so clearly and concisely. That’s a rare skill.
Keep trucking David appreciate everything your doing:raised_hands:
Thanks for the updates and great work!
The existing LTC mempool logic ended up being quite a bit more complex than I predicted, so we’ll need to revisit this area after the testnet launches. For now though, a very minimal implementation supporting MW transactions has been written.
In addition to the mempool changes, code was written to support mining extension blocks, although there are a few edge cases left to handle, and much more testing is needed.
I’ve had concerns about the way we were storing mimblewimble block data in a separate database. It was originally designed this way to be a clean separation from the existing code, in order to facilitate merging future bitcoin commits. Having separate databases is generally a bad idea though, because we lose the ability to make atomic updates, which means the 2 databases could become out of sync. This can lead to a whole host of problems, potentially even ones that are exploitable by remote attackers.
Because of these concerns, I decided to spend some time modifying the code for serializing and deserializing MW blocks & transactions to disk. I was able to take advantage of the groundwork that was laid down as part of the segwit enhancement, to cleanly support serializing the additional data without making major changes to the existing block storage format. As a result, upgraded nodes can successfully save extension block data to disk the same place they’ve always saved blocks, without having to introduce an additional database. A side effect of these changes is that it was relatively straightforward to add support for sharing mimblewimble transactions over the p2p network, which is the first step toward July’s goal of handling MW data as part of the Initial Block Download.
The high-level plan for the rest of the summer remains the same:
July: Initial Block Download
August: Chain reorg logic
September: Activation logic and testnet launch