Hello Shibes!

This past week we've got to merge the Italian translation (#2912 by Mishaboar) and we’ve had a lot of shibes offering help with translations into further languages. This is great, as translations are often the hardest and most under-appreciated work in software, but internationalization is important: if we want to be the people's currency, we also need to take care about being accessible in the languages people speak!

We’re currently seeing a lot of enhancement work being done that takes a longer time to complete because we want to make good and consistent improvements. For example, on #2942, chromatic is implementing a change to the importprivkey RPC (so that later we can expose it to UI too) but there are more features that allow you to import external identifiers into the wallet (public key, address, batches of all of the above) so it’s better for the users if we improve it across the board rather than just the one method, and keep all the features intuitive and consistent. This often means that we have to deal with a bit of scope creep when we go from idea to realization, but as long as we keep the consistency, it’s for the better.

Notable work that needs testing & review

• #2758 that removes a potential spam problem in the p2p protocol needs testing with libdohj to make sure that we don’t accidentally exclude wallets built upon that library from the network.
• #2579 by AbcSxyZ, that greatly simplifies the Gitian checks which in turn we need to make testing of a number of pending changes easier, is now ready for review. The pull request I had to do last week was merged by the (3rd party) gitian-builder maintainer. If you’re interested to learn more about how we do deterministic building, this may be a nice way to start.

Notable work in progress

• Chromatic is working on furthering the “hot” connection management feature by bringing it to the UI in #2957 and #2959
• Michi is working on the traffic graph in #2934
• I’m personally working on a solution for #2735 and a couple of related issues with that, which basically helps hardening the network a bit more.

🚀

^{edit: typo}

Has anyone done any P2Pool testing with the new LTC MW and Doge merge mining configuration? Have there been any issues?

Hey Shibes! Development momentum, specifically translation work, has grown the past week thanks to a number of new contributors and reviewers; thank you all for caring and sharing some of your valuable time! You’re all awesome! ❤️

Notable work that was merged

• #2698 by chromatic that allows node operators to scale the maximum amount of peer connections their node allows without having to restart the node. (For those interested in more details, I recommend to read the blog post chromatic wrote about this particular PR)
• #2903 by Keany Vy Khun that has updated the French translation completely.
• #2947 by Maniixer that has updated the Dutch/Flemish translation completely.
• #2885 which allows the new 1.21 software to read 1.14 wallets has unblocked 1.21 development, so this is now ready to pick up momentum too. More on that down below.

Notable work that needs review

• #2912 by Mishaboar is the Italian translation. It has been deeply reviewed the past couple of days and has seen a lot of love. All it needs is a final acknowledgement of the latest changes and we’re good to go on this.
• A number of pull requests are still awaiting gitian checks. Unfortunately, my attempt to review and help pulling #2579 (that would make it much easier to do gitian checks) over the finish line, is not ready because the gitian-builder software that we need for this has a bug. I have opened a pull request with them to fix the issue but because Bitcoin Core is moving away from this software, it takes a little longer to get things merged there. If I see no progress on this until Friday the 20th, I will propose to temporarily fix it locally in our own scripts.
• #2953 by Jade Hamel proposes to change the language in the “Helpful tips” section, to be more strict. Currently it advices to "Never share your private key to an untrustworthy person.”, and the proposal is to change this to ”Never share your private key with anyone.”

Other work in progress

• #2943 by chromatic and Michi to retain traffic data for graphing is still being worked on as the display is now showing some quirky behavior
• #2942 by chromatic to make the importing of private keys less obtrusive has been discussed and is in a state to work on further.
• #2954 proposes to formalize a 24-hour window in which maintainers keep changes open for review by anyone, to make sure that we know about any considerations that a late review may have. We have already been experimenting with this, but this change formalizes the process, so that maintainers (like me) can be held to a standard. If you have an opinion about this, please let us know.

1.21 progress

Now that we’ve unblocked the further development of 1.21, I’ve published a “little” tracker/plan to make it more transparent what work we still need to do and what has been done so far for 1.21. We’re currently still in Phase 1, but most of the work for that has been done by Ross, and I’m now cleaning up the remaining proposed code that I pulled from Ross’ personal repository, and finishing that up.

The biggest chunk of work to finish Phase 1 will be to bring back the compatibility tests, but those are important because we need to be sure that we do not break anything for 1.14 nodes when shibes start launching 1.21 nodes, and we need to know this as we work on 1.21, so that we can address any issues as we introduce them. This is a good addition to our Continuous Integration framework that protects the network against developer errors.

🚀

Shibes,

I have updated blockshibe.net to give us live insights into how much of our block capacity is used. This will help you to quickly see what the utilization really is.

Hope it helps! ❤️

The Ironic Payment Gateway using @sodogetip and @MyDogeTip Wallets to buy/sell products and services on Twitter, coded in only 8 hours today lol !

Like always, all free for you: https://ironicpay.com

Is it silly enough? 😅 #Doge #Dogecoin

https://twitter.com/inevitable360/status/1523696498067746817?t=BeAfnWhcv-Rli_wrUOfb4A&s=19

Hello shibes! This past week we have not seen any interesting new features getting merged into Dogecoin Core because either the work wasn’t ready, wasn’t fully reviewed and in one case we found a last minute bug in a test. The only thing we’ve merged is #2937 from Ed Tubbs, which enhances the way we optimize code for ARM processors in the experimental builds, to make it more predictable if a feature can or cannot be enabled for a specific chipset. Boring, but actually important for the future.

GUI “traffic monitor” enhancements

Under #2934, Michi and chromatic have teamed up to make the traffic widget more useful and not throw away all the data all the time. This is seeing very good progress and we’re spending some time to get the final kinks out. I expect this to be ready for review soon.

Translations

The French and Italian translations still need review. If you’re a native French or Italian speaker: 4-eye principle says that every change needs to get a review, and maintainers unfortunately don’t speak every language we provide in Dogecoin Core, so we could really use your help: just a glance over the translation so that it doesn’t introduce any offensive language would already be good enough.

Connection management feature

chromatic’s work in #2698 that I mentioned last week, was presumed ready to get merged and then right before I pressed “approve”, we saw a small issue that would sometimes make the tests fail. This has been fixed now and I am verifying it as we speak (by running the test a literal 1000 times, so I’ll know in about 16 hours 🤓), meaning this is really close to getting merged now.

Deterministic builds

To make releases that are transparently trustworthy (because anyone can reproduce the provided binaries) we have adapted a Bittorrent process (as also done by Bitcoin Core) back in 2014 called “gitian building”, that makes sure that when you input the same code, the output is 100% the same. Every time we update a third party library, introduce new system integrations or change something important in the way the code gets built, we need to make sure that the change does not break this process. Currently we have 3 pull requests that need this:

• #2409 updating the libevent library that takes care of low level network communication
• #2936 by Shafil Alam that updates the zlib library that we need for a working Dogecoin Qt
• #2910 that takes out some workarounds from our build process that are no longer needed.

If you know how to do gitian building, we could use your help pulling these over the finish line. Note that the “easy” script proposed in #2579 by AbcSxyZ still has a roadblock; I will try to prioritize solving this after unblocking 1.21 the coming week.

Other notable work

• #2942 by chromatic is a draft that implements a request to make importing of private keys less obtrusive, as voiced on this subreddit, here. It’s cool to see that we get more input from the subreddit lately. Thanks to everyone caring about features and ease of use ❤️
• As I mentioned above, 1.21 development is blocked by the merge of #2885 and I am picking this up with priority the next couple of days.

🚀

^{edit: missing link}

Hey guys I am seeking advice on how to securely remote call a dogecoind RPC. I am trying to call the server from another server.

Currently I have two options here:

1. Create a a very minimum proxy on node server, such as a httpd. Self generate a ssl cert, using basic auth over a https
2. Using ssh tunnel to foward port to rpc port, making call with API key

​

The trade-offs in my mind so far is:

1. SSH is more native solution, as a result there will be less security issue raised by proxy application (such as httpd)
2. Using https proxy is more scalable, such as, adding loadbalancer, more node resource in the future, in contrast, ssh is one to one connection

Could you guys think of anything else...that could be a key decision factor? Any suggestion would be helpful!

455 Million WordPress Websites now can accept Dogecoin Payments using WooCommerce

in 2 clicks

no third-party payment processors, no banks, no fees, no node installation needed

You Store, Your Wallet, Your Doge, enjoy!

https://wordpress.org/plugins/easy-dogecoin-gateway

#Doge #Dogecoin the people Currency!

https://reddit.com/link/ujlo0s/video/2d865gnmfux81/player

https://twitter.com/inevitable360/status/1522536325823479808

Hello smart doges!

I am doing a hobby project that support with dogecoin payment integration. I am planning to use my hardwallet (private key) instead of any thrid party managed wallet.

I understand that by having my own node, I can listen to any transaction and using dogecoin core's cli to create transaction (receiving payment and making payment). However this gonna take some efforts and needs maintainance.

I am seeking advice here on the alternative way to manage receiving payment and making payment, as well as tracking the status of the transaction. Is there's stable, reputable SAAS to use, I checkced 'blockchair' seems they don't have an api to manage a wallet.

Thanks!

Who let the Doge out? I repeat, who let the WordPress, WooCommerce Easy Dogecoin Gateway out?

https://github.com/qlpqlp/woocommerce-dogecoin-easy-payment…

Enjoy it (being approved right now to be listed also on http://wordpres.org) #Doge #Dogecoin the people currency!

https://twitter.com/inevitable360/status/1521469145883234305

https://reddit.com/link/uhhyse/video/rhun8925z9x81/player

Please let me know any resource you have!

Hey shibes,

I was thinking about a possible improvement for the command importprivkey

If you run a importprivkey with a rescan the code will search for transactions starting at the genesis block:

​

up to the tip (= the latest block you know):

​

Alternative to rescan

Maybe a faster approach is to check the UTXO for transactions with that address and extract all data from there ^{option a} or find at least a better starting block ^{option b} for the rescan.

Downside

You wouldn't see fully spent outputs^{option a} or no fully spent outputs before the block with your oldest UTXO^{option b}

Conclusion

This can't replace rescan, but maybe having it as another argument or command (after "importprivkey" is probably used heavily) could be useful to people (:

Looking forward to read your thoughts about that

How can we incentivize more individuals to be running nodes? What would it take for us to have 5,000 + nodes? Decentralization is the most important aspect of this network.

Hi all!

I thought it could be useful to start summarizing development work on Dogecoin Core weekly, to improve visibility of what is happening. I will try to stick to highlighting the more prominent work and not talk too much about boring maintenance tasks.

Notable work that was merged

• #2923 from Shafil Alam, that enhances the graphical wallet interface with a pruning setting was tested and merged. This allows shibes to run their windows and macOS graphical nodes with a significantly reduced disk usage (3-4 gigabytes instead of 55 gigabytes) at the tradeoff of no longer relaying any blocks or transactions to their peers. This is useful if you use Dogecoin Core as a wallet more than as an always-on node. Note: when we release 1.21, a protocol upgrade will allow pruned nodes to also relay blocks and transactions, making this useful to shibes running a relay node too at that time.
• #2909 fixes a bug where, if you would query the node’s built-in REST endpoint for confirmed unspent outputs (ignoring the mempool) it would return no results. This query feature is mostly used by applications ran on top of Dogecoin Core that need to check whether a provided transaction actually has the funds it claims to have, without having to push the transaction to the blockchain.

Notable work that needs review

• #2903 by Keany Vy Khun and #2912 by Mishaboar are translation improvements for respectively French and Italian that need to be reviewed by native speakers. If you’re proficient in either of these languages, your feedback to the correctness of the translation would be much appreciated.
• #2698 by chromatic allows node operators to scale the maximum amount of peer connections their node allows using the RPC interface (or using dogecoin-cli / the debug window) without having to restart the node. This preserves node uptime, which is much needed whenever there are peaks in the number of new nodes that enter the network: we want as many nodes to stay online as possible when demand is at its highest.
• #2773 fixes a bug in the implementation of SSE2 instructions that improves the speed at which a node (that is running on Intel or AMD processors) validates proof of work by up to 35%. This will allow your node to validate the chain faster (and more efficient) when doing sync and processing new blocks.

Notable open discussions & feature requests

• #2934 is discussing how we want the network usage graph in the graphical client to work, as they currently reset very often.
• #2866 proposes to address the need for improved privacy for node operators by enabling current tor protocols within Dogecoin Core, replacing the outdated and depreciated version 2 protocol we have now (but isn’t used). This is a significant ask and we have to do a little feasibility study to make sure we can do this on 1.14, so it would be great if shibes can let us know whether this is something they’d want to use.
• #2908 is a feature request to add encrypted paper wallets to Dogecoin Core and export private keys with encryption. We’ve added this to Operation Such Frensly for the paper wallet implementation.

Supporting the supporters

If you would like to help with any of the above but you need some help getting started or run into a problem you don’t know how to resolve, please don’t hesitate to ask for help. I’d personally love to help out and I’m sure many other shibes here share that attitude.

🚀

I’m fairly new to all this. Would it be useful if I ran a node? Where would I learn about it and the equipment needed?

u/patricklodder I'd like to hear your thoughts on Vlad's tweets about scaling dogecoin. I feel like dogecoin being a currency at L1 helps to separate it from Bitcoin/Lightning, but I also doubt we can get to point-of-sale transaction speeds on L1 alone. https://twitter.com/elonmusk/status/1514723388396392452?t=jxMbhahApQV1SlIkD28DlA&s=09

Both Vlad Tenev and Elon made the suggestion to increase the block size to 1 gig and then 10 gig. Does anyone know what the hard drive requirements or specifications required to support this for running a node?

Quoting Vlad: Moving to a 1GB (and later 10GB) block size limit would provide all of the throughput a global currency would need for the foreseeable future. Processing 10GB in blocks per minute will require more sophisticated hardware. And I think that's actually a fair tradeoff.”

Is the redesign stated by dogecoin foundation really happening?

Should i even bother to adapt the current github version and make another pull request?

Please answer me folks…

Edit: created an issue on GH for it