litecoin VS dogecoin

In order to add MWEB support to PSBTs, I first had to merge in PSBTv2 (BIP-0370), which can be seen here. I then defined the MWEB fields we needed to add, and added them to the PSBT data structures along with serialization and deserialization here.

it literally is. just check its title https://github.com/litecoin-project/litecoin

A pull request has also been submitted for downloading and verifying HogEx transactions, MWEB headers, and the UTXO leafset bitmap. This covers steps 2 and 3 of the light client sync process.

Only in the source code ... https://github.com/litecoin-project/litecoin/blob/master/src/consensus/consensus.h

It took several iterations of fixes, but we seem to finally be displaying the transaction history reliably. As part of these fixes, the code was moved to a location where we could more easily write automated tests for it. Having repeatable tests should ensure that this continues to function properly in v0.21.2, and in all future releases. You can find most of the related changes here.

hey maybe your petition was a success or simply things have their own speed. https://github.com/litecoin-project/litecoin/commits/0.21

Please report any issues you find with the release using github.

Probably this depends on what you want to do. It is my understanding that the devs use regtest to check all functions after changing some of the core wallet's code (all local). This will create a new blockchain where you can do all the test from (https://github.com/dogecoin/dogecoin/tree/master/src/test). But I am also not sure about this (;

Absolutely, because what we're doing is trying to catch up on 4 years of very intensive Bitcoin development. Recent Bitcoin Core versions (such as the base we use for 1.21) are really good software and per the small discussion we had on GitHub, we would ideally wish this to become a stable base for Dogecoin to build further upon in the future. This is good because once that is done, contributors will no longer see all their work deleted with every major release.

Anyway, to give a recent and practical example: when I was re-testing Victor's wallet compatibility fix that we merged last week, I found that the regtest network in 1.21 was much more incompatible with 1.14 than I expected based on comments made in previous PRs and we cannot automatically test for regressions cross-version until it is fixed.

Unfortunately I hadn't thought this through when we worked on 1.10 back in 2015 (I too am a dumb) so now we're having it custom for dogecoin... Many wallets however are suspected to NOT implement Dogecoin's prefixes and just use Bitcoin prefixes, which should work fine.

I think the last time I saw Comic Sans used in any software as a main font was when I compiled dogecoin[1]. Can't remember any before that.

[1] https://github.com/dogecoin/dogecoin

After that - anything. I promised before that as we get closer to a release, I will re-propose a softfork plan and I intend to keep that. It will NOT be the same plan that I posted 16 months ago because reality has changed quite a lot since then, but I will try to make it a good and open plan, that - in the tradition of the plans I've been putting out since a year or so now - furthers decentralization and operator freedom.

I assume you can see what is going on here: https://github.com/dogecoin/dogecoin/commits/1.21-dev

victorsk2019 is proposing many of the changes we need to drive this forward so we are making progress, but slowly. The main factor for this process being slow is that, unlike 1.14.0 where we needed 5 releases over 2.5 years to get rid of tech debt so far (and tbh we're not there yet at all), we want to keep debt at a minimum because otherwise we'll just replace one broken software with another. It's got to offer a stable base for the future. So I'm trying to make sure that we don't slack on quality.

My best thought is that we've fixed a miniscule bug with high dpi that in some cases may cause QT to render wrong, at https://github.com/dogecoin/dogecoin/pull/2778, that could cause the application windows to be rendered outside of your visible screen because of a change in how positioning is calculated.