dogecoin / docker

Dogecoin Core on Docker

Dogecoin Core [DOGE, Ð]

Select language: EN | CN | PT | FA | VI

Dogecoin is a community-driven cryptocurrency that was inspired by a Shiba Inu meme. The Dogecoin Core software allows anyone to operate a node in the Dogecoin blockchain networks and uses the Scrypt hashing method for Proof of Work. It is adapted from Bitcoin Core and other cryptocurrencies.

For information about the default fees used on the Dogecoin network, please refer to the fee recommendation.

Website: dogecoin.com

Usage 💻

To start your journey with Dogecoin Core, see the installation guide and the getting started tutorial.

The JSON-RPC API provided by Dogecoin Core is self-documenting and can be browsed with dogecoin-cli help, while detailed information for each command can be viewed with dogecoin-cli help <command>. Alternatively, see the Bitcoin Core documentation - which implement a similar protocol - to get a browsable version.

Such ports

Dogecoin Core by default uses port 22556 for peer-to-peer communication that is needed to synchronize the "mainnet" blockchain and stay informed of new transactions and blocks. Additionally, a JSONRPC port can be opened, which defaults to port 22555 for mainnet nodes. It is strongly recommended to not expose RPC ports to the public internet.

Function	mainnet	testnet	regtest
P2P	22556	44556	18444
RPC	22555	44555	18332

Ongoing development - Moon plan 🌒

Dogecoin Core is an open source and community driven software. The development process is open and publicly visible; anyone can see, discuss and work on the software.

Main development resources:

• GitHub Projects is used to follow planned and in-progress work for upcoming releases.
• GitHub Discussion is used to discuss features, planned and unplanned, related to both the development of the Dogecoin Core software, the underlying protocols and the DOGE asset.
• Dogecoindev subreddit

Version strategy

Version numbers are following major.minor.patch semantics.

Branches

There are 3 types of branches in this repository:

• master: Stable, contains the latest version of the latest major.minor release.
• maintenance: Stable, contains the latest version of previous releases, which are still under active maintenance. Format: <version>-maint
• development: Unstable, contains new code for planned releases. Format: <version>-dev

Master and maintenance branches are exclusively mutable by release. Planned releases will always have a development branch and pull requests should be submitted against those. Maintenance branches are there for bug fixes only, please submit new features against the development branch with the highest version.

Contributing 🤝

If you find a bug or experience issues with this software, please report it using the issue system.

Please see the contribution guide to see how you can participate in the development of Dogecoin Core. There are often topics seeking help where your contributions will have high impact and get very appreciation. wow.

Communities 🚀🍾

You can join the communities on different social media. To see what's going on, meet people & discuss, find the latest meme, learn about Dogecoin, give or ask for help, to share your project.

Here are some places to visit:

• Dogecoin subreddit
• Dogeducation subreddit
• Discord
• Dogecoin Twitter

Very Much Frequently Asked Questions ❓

Do you have a question regarding Dogecoin? An answer is perhaps already in the FAQ or the Q&A section of the discussion board!

License - Much license ⚖️

Dogecoin Core is released under the terms of the MIT license. See COPYING for more information or see opensource.org

docker's Issues

Tons of Low fee Spam on the network right now

Theres like 20fold the volume in dust attacks, maybe more. are there any plans to mitigate this risk and also what are the motives of the attackers?

Arguments and environment priority order

Following #13 (comment)

The current behavior is that arguments override environment. Idk if we should do the opposite.

Regarding our choice, we would have to switch the following lines in entrypoint.main:

executable_args = convert_env(executable)
executable_args += sys.argv[1:]

Make multiarg work with env

While reviewing #10, I realized that one of the things that doesn't work with env-as-arg right now is multi-arg, i.e. -addnode=x -addnode=y.

We should add something for that.

Entrypoint variable renaming

entrypoint.convert_env uses a variable man_options, but man pages aren't used anymore to get options. It's now done by -help menu as introduced by #34.

Need a renaming.

docker/1.14.5/bullseye/entrypoint.py

Line 109 in 9dcc169

for option in man_options:

`-daemon` crash

Option -daemon do not work and is crashing with the following error:

$ docker run -it dogecoin -daemon
2021-12-04 00:35:31 
2021-12-04 00:35:31 Dogecoin version v1.14.4
2021-12-04 00:35:31 InitParameterInteraction: parameter interaction: -whitelistforcerelay=1 -> setting -whitelistrelay=1
2021-12-04 00:35:31 Assuming ancestors of block 77e3f4a4bcb4a2c15e8015525e3d15b466f6c022f6ca82698f329edef7d9777e have valid signatures.
Dogecoin server starting

Any idea if the daemon fork himself and kill its parent to daemonize ? Which may stop the container.

It's what I'm having in mind as a first thing to inspect. I'm not sure about it, but I suspect buggy behavior related to daemonization.

QA: Add Dockerfile linter

Currently the most complete Dockerfile linter seems to be hadolint, this basically implements the same principles from pylint and eslint+[semi]standard to Dockerfiles.

Open items on main as of dc0a034:

• DL3027: Do not use apt as it is meant to be a end-user tool, use apt-get or apt-cache instead - #42 at

  docker/1.14.5/bullseye/Dockerfile

  Line 28 in dc0a034

  RUN apt update && apt install --no-install-recommends -y \

  and

  docker/1.14.5/bullseye/Dockerfile

  Line 93 in dc0a034

  RUN apt update && apt install --no-install-recommends -y \

• DL4006: Set the SHELL option -o pipefail before RUN with a pipe in it - #44 at

  docker/1.14.5/bullseye/Dockerfile

  Line 37 in dc0a034

  RUN git clone --depth 1 ${REPO_GITIAN_BUILDER} gitian \

• SC2038: Use -print0/-0 or -exec + to allow for non-alphanumeric filenames. - #44 at

  docker/1.14.5/bullseye/Dockerfile

  Line 40 in dc0a034

  && find dogecoin/contrib/gitian-keys -name "*.pgp" |xargs -n 1 gpg --import

• DL3047: Avoid use of wget without progress bar. - #44
• SC2046: Quote this to prevent word splitting. - #44 at

  docker/1.14.5/bullseye/Dockerfile

  Line 54 in dc0a034

  && grep ${RLS_FILE_NAME} sigs/${SIG_PATH}/$(cat random_signer.txt)/*assert | sha256sum -c \

• SC2035 : Use ./glob or -- glob so names with dashes won't become options. - #44 at

  docker/1.14.5/bullseye/Dockerfile

  Line 80 in dc0a034

  && rm -rf *

Note that after fixing some items, new findings can arise. For example, after fixing DL3027 with #42, we will get the following:

• DL3008: Pin versions in apt get install. Instead of apt-get install <package> use apt-get install <package>=<version>

Repository Architecture : image base distribution and architecture

Following comments from PR #2 (comment) about used distribution & architecture for the Dockerfile.

I suggest speaking about architecture of the repository to see what would be possible to do to deal with versions, cross-platform portability & distributions. To clarify and move in a common direction.

Cross-platform portability

I wasn't sure, but Docker do not manage hardware abstraction, because it uses the kernel, setting up a predefined software layer.

ARM & other specific architecture would need some tricks to be handled. Docker & Docker Hub are providing two ways to manage cross-platform images, the simplest way is using docker buildx, the alternative is to create manually a manifest from multiple published image/tag using docker manifest. See docker blog.

docker buildx seems to not work, x86_64 executable is not able to launch on ARM even with qemu emulation, creating an exec format error, not sure why.

Alternatively, building a root manifest from multiple tag is possible, resulting in a single version endpoint to call for all architectures. Multiple tag will be pushed for each architecture, using with the appropriate executable, and then everything is grouped under the same tag.
For now, it's what I'm having.

You can find created images for both method on my Docker Hub.

So I've no certitude about the good path, but maybe docker manifest is something to explore. For now, I don't know if we have to create a folder for each architecture and how to publish all Dockerfiles. What is your current opinion ?

Providing multiple distribution

I'm not clear about the benefit of providing multiple distros. I know about alpine for the size, @patricklodder was speaking about upgrades :

Even if we were to choose to just support 1 distro (eg: debian) then there's still the issue that the Dogecoin Core release cycles are not at all in sync with distro release cycles. Since the goal must be to make production images (otherwise we may as well just keep all this in user repos and not care) we will have to think a bit about upgrade policies. You don't want to force updates cross distro release but instead enable custom security policies, the former will just lead to no one using the images we are proposing here at some point.
I think that we'll have to maintain, say, dogecoin:1.14.6-bullseye-slim and dogecoin:1.14.6-bookworm-slim concurrently in the most minimal of supported cases.

You want to support at least to successive version of a distribution to let user selecting image for a potential migration ? Because I agree giving access to alpine or whatever could be great, but may be wise to limit ourselves, at least for maintenance reason, and develop it later depending on the demand.

Regtest doesn't work as env

When using -e REGTEST=1, the daemon starts for mainnet:

$ docker run -e REGTEST=1 e4d68febe0e9 |grep Bound
2021-12-04 18:45:56 Bound to [::]:22556
2021-12-04 18:45:56 Bound to 0.0.0.0:22556

but when using -regtest, the daemon starts for regtest:

$ docker run e4d68febe0e9 -regtest |grep Bound
2021-12-04 18:48:17 Bound to [::]:18444
2021-12-04 18:48:17 Bound to 0.0.0.0:18444

Probably related to our discussion at #3 (comment) ?

Convert datadir pytest into CI tests

Convert test from #25 to CI tests using integration test framework.

def test_datadir(hook, host):
    """
    Verify if datadir can be changed and created proprely.

    Verify datadir metada, if it's owned by script user (dogecoin).
    """
    # Use a unique directory for this test
    tmp_datadir = "/tmp/datadir_test"
    datadir_argument = f"-datadir={tmp_datadir}"

    test_args = ["dogecoind", datadir_argument]
    test_environ = {}

    result_args = [
            pytest.abs_path("dogecoind"),
            datadir_argument,
            "-printtoconsole",
            ]
    result_environ = {}

    # Run test to generate datadir
    hook.test(test_args, test_environ, result_args, result_environ)
    assert hook.result == hook.reference

    # Test datadir metadata
    datadir_folder = host.file(tmp_datadir)
    assert datadir_folder.user == pytest.user
    assert datadir_folder.group == pytest.user
    assert datadir_folder.mode == 0o755

Dynamic version build using dynamic hash verification

Following comments from seed PR dogecoin/dogecoin#2337 (comment).

In the current situation, it's possible to build a single version with each Dockerfile because the hash of Dogecoin Core is hardcoded
within the Dockerfile.

By taking a look at Docker security instruction to build Dockerfile, they are suggesting alternatives to avoid this hardcoded hash.

Need extra investigation, I will share my finding about the topic here to see if an improvement is possible.

Review board

Added a review board at https://github.com/dogecoin/docker/projects/1, to help clarify review priorities. It identifies urgent and blocked PRs, and tries to order the individual columns by obstacle / priorities: easy quick wins on top, items that need a lot of discussion or rework at the bottom.

Add shell commands support in entrypoint

From some documentation about Docker Official Images:

All official images should provide a consistent interface. A beginning user should be able to docker run official-image bash (or sh) without needing to learn about --entrypoint. It is also nice for advanced users to take advantage of entrypoint, so that they can docker run official-image --arg1 --arg2 without having to specify the binary to execute.

Need to enable execution of any kind of command in the entrypoint. Need to follow one process if used command is related to dogecoin, otherwise launch arbitrary commands.

Script to generate Dockerfiles by version + Github Action integration

I'm starting to think about a script to generate a Dockerfile for each Dogecoin Core release, and to have a way to update existing Dockerfiles/images when a template is edited, by using GitHub Action (GA) to automate Docker Hub tasks.
The goal here is to draft the script & the GA process.

The repository architecture would be the following, as defined in the related issue:

.
└── version
    ├── distro1
    │   └── Dockerfile
    └── distro2
        └── Dockerfile
└── version2
   ├── distro1
   ....

As I see it now, we can have 2 type of event :

GitHub change	Docker Hub changes
push on release	1 version pushed, 1 image per distro
update of templates	all version updated, for all distros

By reading GA documentation, I think it can be possible to achieve something like that 🤞.

Should we update all Dockerfiles and images when a template is modified ? Docker Hub do not handle versioning for images, and changes can break related programs. Docker official images do not use a version strategy, but we may have change they don't.

I'm not sure how intensively GA should automate stuff. Do we try to do the publication of a new version with a workflow on Dogecoin Core called on releases ? Depend on the previous question, but do we automate update of templates (and Dockerfiles), GA propagating the change & committing automatically, or should do a PR ? Alternatively, do we let human run the script, creating locally new files & PR the result.

Any idea, expectation about the script/GA ? Any limitation to this current suggestion ?

Linter and tests

The linter as proposed with #52 will ignore a lot of rule violations on test code because pytest violates these. This may cause tech debt (and in itself is tech debt that we're inheriting from pytest.) We'll at some point need a solution for this.

Convert test from pytest to CI test framework

Need to convert the following test from pytest to the CI test framework.

def test_files_metadata(host):
    """Verify all image files generated by the Dockerfile"""
    dogecoind = host.file(abs_path("dogecoind"))
    assert dogecoind.user == "dogecoin"
    assert dogecoind.group == "dogecoin"
    assert dogecoind.mode == 0o4555

    dogecoinqt = host.file(abs_path("dogecoin-qt"))
    assert dogecoinqt.user == "dogecoin"
    assert dogecoinqt.group == "dogecoin"
    assert dogecoinqt.mode == 0o4555

    dogecointx = host.file(abs_path("dogecoin-tx"))
    assert dogecointx.user == "dogecoin"
    assert dogecointx.group == "dogecoin"
    assert dogecointx.mode == 0o4555

    dogecoincli = host.file(abs_path("dogecoin-cli"))
    assert dogecoincli.user == "dogecoin"
    assert dogecoincli.group == "dogecoin"
    assert dogecoincli.mode == 0o4555

    entrypoint_script = host.file(abs_path("entrypoint.py"))
    assert entrypoint_script.user == "root"
    assert entrypoint_script.group == "root"
    assert entrypoint_script.mode == 0o500

Optimize the build order

Originally posted by @AbcSxyZ in #6 (comment)

Separation of declaration and execution is not the rule in Dockerfile.

For exemple, php & golang are mixing declaration and execution. And probably all other Docker official images.

It's even a recommendation to use the cache with more efficiency, from cacheability recommendation:

Ensure that lines which are less likely to change come before lines that are more likely to change (with the caveat that each line should generate an image that still runs successfully without assumptions of later lines).

For example, the line that contains the software version number (ENV MYSOFTWARE_VERSION 4.2) should come after a line that sets up the APT repository .list file (RUN echo 'deb http://example.com/mysoftware/debian some-suite main' > /etc/apt/sources.list.d/mysoftware.list).

Doing all declarations at the top of a Dockerfile is defeating the utility of caching mechanism.

feat: Support non-complicated x86_64 builds.

Post-merge feature after #14:

If we can find a way to give the TARGETPLATFORM build argument a default value of linux/amd64, we can make the build process simpler.

From: #14 (comment)

apt add `--no-install-recommends` flags

Reduce downloaded/installed size of apt packages by adding --no-install-recommends.

Dogecoin on Kubernetes! (Ongoing effort already underway)

Preface: While trying to get started to see how I can contribute to Dogecoin, I found a lack of very clear guidance on best practices for running DogecoinD, especially in a server environment. Standardized and repeatable deployments with accompanying Documentation and Guides for operations would go a very long way to lower the barrier of entry into this community. Therefore, i'm making some things. I am posting this announcement here because:

1. This was posted to r/dogecoin but got drowned out by memes
2. I attempted to post to r/dogecoindev but Karma restrictions block any new users from contributing meaningfully or even posting
3. Tried to message the sub moderators but only got radio silence. I'm sure they're busy writing code instead of policing the internet ((Update: I was able to get ahold of a mod and get this posted to r/dogecoindev ))

---

At Aither Architects, our mission is to be an enabling factor and a force multiplier for Makers, Doers, and anyone with the creative spirit -- as that is what drives humanity forward. Whether you’re looking to showcase your creations, start and continuously operate your business, or organize a movement for the positive benefit of all humans, we’ll be right by your side to help provide the support and technical foundations for you to be you.

Aither’s values and morals line up with what Dogecoin’s potential and its community represent, so we will proudly commit to its adoption and growth. Even though Aither is a pre-launch startup, that doesn’t mean we’re unable to give to the community and I want our first public act to be one of giving and a gesture of goodwill. Dogecoin has massive fervor behind it; however, user adoption is a problem. That’s why today i’m proud to announce the alpha release and ongoing development of a Helm Chart and Docker images for running a Dogecoin FullNode on Kubernetes. It's rough and early, but I felt it more important to get this out to the world for collaboration opportunities instead of trying to deliver something overly polished 2 months from now. This will help standardization and make it easier to run Dogecoin in a server environment, develop for it, mine coins, and help secure the network. Most importantly, it’s a step in the right direction for reducing the barrier of entry into crypto. Using this vehicle, we can:

• Make it easier for anyone to run and operate Dogecoin FullNodes
• Enhance developer experience and tap into the massive Kubernetes ecosystem
• Lower the barrier of entry into crypto for education and for make benefit glorious community projects of Doge!
• Use it as a starting point for a Community Dogecoin DevOps program

https://github.com/Aither-Architect/dogecoin-docker

https://github.com/Aither-Architect/dogecoin-helm

https://hub.docker.com/r/aitherarchitect/dogecoin/tags

It's one thing to say we're going to Do Only Good Everyday, but it's another thing altogether to say exactly what that looks like. That’s an immensely complex topic owing to the fact that ‘good’ looks different to each of us. The most important thing of all that we need to keep in mind, which eclipses everything else and fuels this just cause, is our Why. Like so many of you, this coin --for me-- isn’t about novelty or beating another cryptocurrency, but a chance at some life altering income that represents security for my family and loved ones as well as setting up a fair and transparent financial system for humanity. It all boils down to hope in a brighter future, which can move mountains. In a world seemingly designed to squeeze us for all we’re worth, we could all use a little hope… and i’m willing to fight for that. What’s your DogeWhy?

As always, PULL REQUESTS ARE WELCOME!!!!!

Sean Brooks
Chief Architect & CVO