Dogecoin Core [DOGE, Ð]

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.

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

Building dogecoin-qt 1.14 on modern macs.

Note that this requires changes made by michilumin on the 1.14-dev branch as well as some changes to BDB.

Tested on OSX 10.11 El Capitan, 10.13 High Sierra and 11.1 Big Sur.

Paper wallet printing support seems to work fine through this method as well.

Clone dogecoin locally, or check it out, etc.

For this purpose, just indicating the 1.14-branding branch in my repo.

$git clone -b 1.14-branding --single-branch https://github.com/michilumin/dogecoin.git

Set up OSX basic build dependencies.

Install xcode-select commandline utils.

$xcode-select --install

note: If you have Xcode installed, simply zip it up and move it for this process, as your current Xcode install will likely conflict. Unzip it back later.

Make sure frameworks dir is properly owned...

$sudo mkdir /usr/local/Frameworks
$sudo chown $(whoami):admin /usr/local/Frameworks

Install Brew. (If you already have Brew installed, perform a 'brew update'.)

$/usr/bin/ruby -e "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/master/install)"

Install dependencies via Brew.

$brew install autoconf automake libtool miniupnpc openssl pkg-config protobuf qt5 zeromq qrencode librsvg boost

Install Boost lib via Brew from source, and link it to be sure:

note Boost version may have changed by the time you're reading this, from 167.

$brew install boost --build-from-source --HEAD
$brew link boost167

Get, Patch And Compile BDB 5.3

Download bdb 5.3.28 source from Oracle.

$curl -o db-5.3.28.tar.gz http://download.oracle.com/berkeley-db/db-5.3.28.tar.gz
$tar xvfz db-5.3.28.tar.gz
$cd db-5.3.28

Build BDB 5.3.28

$cd ../.. 
$cd build_unix
$../dist/configure CXX=clang++ --enable-cxx
$make
$sudo mkdir /usr/local/BerkeleyDB.5.3
$sudo chown $(whoami):admin /usr/local/BerkeleyDB.5.3
$sudo make install

Set some environment variables and links for bdb and openssl

$export LDFLAGS=-L/usr/local/BerkeleyDB.5.3/lib
$export CPPFLAGS=-I/usr/local/BerkeleyDB.5.3/include

NOTE: for MacOS BigSur (11.1) or later, and possibly Catalina (10.15) you will also have to include the "OBJC_OLD_DISPATCH_PROTOTYPES=1" flag.

So in this case you want the above export to be:

$export CPPFLAGS="-I/usr/local/BerkeleyDB.5.3/include -DOBJC_OLD_DISPATCH_PROTOTYPES=1"

(Note that the quotes are required.)

$export INCPATHS=-I/usr/local/opt/openssl/include
$export LIBPATHS=-L/usr/local/opt/openssl/lib
$cd /usr/local/include 
$ln -s ../opt/openssl/include/openssl 

Go back to your Dogecoin repo

$cd ~/dogecoin
$./autogen.sh
$./configure --with-gui=qt5 --with-qrcode=yes
$make

Go have a beverage.

$make install

Go have another beverage.

Run it.

$/usr/local/bin/dogecoin-qt

Contributing to Dogecoin Core

Dogecoin Core is open source software, and we would welcome contributions which improve the state of the software. For those wanting to discuss changes, or look for work that needs doing, please see:

• Help requests
• Projects
• Dogecoindev on reddit

Branch Strategy

Dogecoin Core's default branch is intentionally a stable release, so that anyone downloading the code and compiling it gets a stable release. Active development occurs on branches named after the version they are targeting, for example the 1.14.4 branch is named 1.14.4-dev. When raising PRs, please raise against the relevant development branch and not against the master branch.

Contributor Workflow

The codebase is maintained using the "contributor workflow" where everyone without exception contributes patch proposals using "pull requests". This facilitates social contribution, easy testing and peer review.

To contribute a patch, the workflow is as follows:

• Fork the repository in GitHub, and clone it your development machine.
• Create a topic branch from the relevant development branch.
• Commit changes to the branch.
• Test your changes, which must include the unit and RPC tests passing.
• Push topic branch to your copy of the repository.
• Raise a Pull Request via GitHub.

The coding conventions in the developer notes must be adhered to.

In general commits should be atomic and diffs should be easy to read. For this reason do not mix any formatting fixes or code moves with actual code changes.

Commit messages should be verbose by default consisting of a short subject line (50 chars max), a blank line and detailed explanatory text as separate paragraph(s); unless the title alone is self-explanatory (like "Corrected typo in init.cpp") then a single title line is sufficient. Commit messages should be helpful to people reading your code in the future, so explain the reasoning for your decisions. Further explanation here.

Please refer to the Git manual for more information about Git.

The body of the pull request should contain enough description about what the patch does together with any justification/reasoning. You should include references to any discussions (for example other tickets or mailing list discussions). At this stage one should expect comments and review from other contributors. You can add more commits to your pull request by committing them locally and pushing to your fork until you have satisfied feedback.

Squashing Commits

If your pull request is accepted for merging, you may be asked by a maintainer to squash and or rebase your commits before it will be merged. The basic squashing workflow is shown below.

git checkout your_branch_name
git rebase -i HEAD~n
# n is normally the number of commits in the pull
# set commits from 'pick' to 'squash', save and quit
# on the next screen, edit/refine commit messages
# save and quit
git push -f # (force push to GitHub)

If you have problems with squashing (or other workflows with git), you can alternatively enable "Allow edits from maintainers" in the right GitHub sidebar and ask for help in the pull request.

Please refrain from creating several pull requests for the same change. Use the pull request that is already open (or was created earlier) to amend changes. This preserves the discussion and review that happened earlier for the respective change set.

The length of time required for peer review is unpredictable and will vary between pull requests.

Pull Request Philosophy

Pull Requests should always be focused. For example, a pull request could add a feature, fix a bug, or refactor code; but not a mixture. Please avoid submitting pull requests that attempt to do too much, are overly large, or overly complex as this makes review difficult.

Features

When adding a new feature, thought must be given to the long term technical debt and maintenance that feature may require after inclusion. Before proposing a new feature that will require maintenance, please consider if you are willing to maintain it (including bug fixing). If features get orphaned with no maintainer in the future, they may be removed.

Refactoring

Dogecoin Core is a direct fork of Bitcoin Core and therefore benefits from as little refactoring as possible on code that is created upstream. If you see any structural issues with upstream code, please propose these fixes for bitcoin/bitcoin and future Dogecoin Core releases will automatically benefit from these.

When refactoring Dogecoin-specific code, please keep refactoring requests short, low complexity and easy to verify.

Experimental features and optimizations

In some cases where a pull request introduces a new feature or optimization, reviewers or maintainers can request the feature to be introduced as an experimental-only feature, meaning that the feature will not be released in provided binaries but will be available for self-compilation for those who wish to test it. Experimental features are still expected to be complete and the process to be followed for all contribution guidelines as outlined in this document.

For more information, see the experimental feature documentation

"Decision Making" Process

The following applies to code changes to Dogecoin Core, and is not to be confused with overall Dogecoin Network Protocol consensus changes. All consensus changes must be ratified by miners; a proposal to implement protocol changes does not guarantee activation on the mainnet, not even when a binary gets released by maintainers.

Whether a pull request is merged into Dogecoin Core rests with the repository maintainers.

Maintainers will take into consideration if a patch is in line with the general principles of Dogecoin; meets the minimum standards for inclusion; and will take into account the consensus among frequent contributors.

In general, all pull requests must:

• have a clear use case, fix a demonstrable bug or serve the greater good of Dogecoin;
• be peer reviewed;
• have unit tests and functional tests;
• follow code style guidelines;
• not break the existing test suite;
• where bugs are fixed, where possible, there should be unit tests demonstrating the bug and also proving the fix. This helps prevent regressions.

The following patch types are expected to have significant discussion before approval and merge:

• Consensus rule changes (through softfork or otherwise)
• Policy changes
• Maturing experimental features into production

While each case will be different, one should be prepared to expend more time and effort than for other kinds of patches because of increased peer review and consensus building requirements.

Peer Review

Anyone may participate in peer review which is expressed by comments in the pull request. Typically, reviewers will review the code for obvious errors, as well as test out the patch set and opine on the technical merits of the patch. Repository maintainers take into account the peer review when determining if there is consensus to merge a pull request.

Maintainers reserve the right to weigh the opinions of peer reviewers using common sense judgement and also may weight based on meritocracy: Those that have demonstrated a deeper commitment and understanding towards Dogecoin (over time) or have clear domain expertise may naturally have more weight, as one would expect in all walks of life.

Where a patch set proposes to change the Dogecoin consensus, it must have been discussed extensively, be accompanied by widely discussed documentation and have a generally widely perceived technical consensus of being a worthwhile change, based on the judgement of the maintainers.

Merging pull requests

Maintainers can only merge pull requests after any maintainer, other than the author of a pull request, has approved the code according to the decision making process outlined above.

Maintainers must keep pull requests open for at least 24 hours after approval to merge is given, to allow anyone to voice a concern that may have been missed in review, or request more time to investigate a suspected issue. If a situation arises where more time has been requested but cannot be granted, at maintainer discretion, a new issue or pull request should be opened to address the defect or discuss improved alternatives. Requests for time and maintainer decision making are expected to be clearly documented on the pull request discussion on Github.

Maintenance tasks and time-critical patches can be exempted from this rule if these are clearly marked as such, at maintainer discretion.

Copyright

By contributing to this repository, you agree to license your work under the MIT license unless specified otherwise in contrib/debian/copyright or at the top of the file itself. Any work contributed where you are not the original author must contain its license header with the original author(s) and source.

Very Much Frequently Asked Questions ❓

How much doge can exist? – So many puppies! 🐕

Early 2015 (approximately a year and a half after release) there were approximately 100,000,000,000 coins. Each subsequent block will grant 10,000 coins to encourage miners to continue to secure the network and make up for lost wallets on hard drives/phones/lost encryption passwords/etc.

Such mining information ⛏

Dogecoin uses a simplified variant of the scrypt key derivation function as its proof of work with a target time of one minute per block and difficulty readjustment after every block. The block rewards are fixed and halve every 100,000 blocks. Starting with the 600,000th block, a permanent reward of 10,000 Dogecoin per block will be issued.

Originally, a different payout scheme was envisioned with block rewards being determined by taking the maximum reward as per the block schedule and applying the result of a Mersenne Twister pseudo-random number generator to arrive at a number between 0 and the maximum reward.

This was changed starting with block 145,000, to prevent large pools from gaming the system and mining only high reward blocks. At the same time, the difficulty retargeting was also changed from four hours to once per block (every minute), implementing an algorithm courtesy of the DigiByte Coin development team, to lessen the impact of sudden increases and decreases of network hashing rate.

The current block reward schedule:

The original block reward schedule, with one-minute block targets and four-hour difficulty readjustment:

Dogecoin Core 0.14.2

Development

The Dogecoin repo's root README contains relevant information on the development process and automated testing.

• Developer Notes
• Release Notes
• Release Process
• Translation Process
• Translation Strings Policy
• Travis CI
• Unauthenticated REST Interface
• Shared Libraries
• BIPS
• Dnsseed Policy
• Benchmarking

Resources

• Discuss on the BitcoinTalk forums, in the Dogecoin thread.
• Discuss on #dogecoin-dev on Freenode. If you don't have an IRC client use webchat here.

Miscellaneous

• Assets Attribution
• Files
• Fuzz-testing
• Reduce Traffic
• Tor Support
• Init Scripts (systemd/upstart/openrc)
• ZMQ

License

Distributed under the MIT software license. This product includes software developed by the Bitcoin developers for use in Dogecoin Core. This product includes software developed by the OpenSSL Project for use in the OpenSSL Toolkit. This product includes cryptographic software written by Eric Young (eay@cryptsoft.com), and UPnP software written by Thomas Bernard.

Deterministic OS X Dmg Notes.

Working OS X DMGs are created in Linux by combining a recent clang, the Apple binutils (ld, ar, etc) and DMG authoring tools.

Apple uses clang extensively for development and has upstreamed the necessary functionality so that a vanilla clang can take advantage. It supports the use of -F, -target, -mmacosx-version-min, and --sysroot, which are all necessary when building for OS X.

Apple's version of binutils (called cctools) contains lots of functionality missing in the FSF's binutils. In addition to extra linker options for frameworks and sysroots, several other tools are needed as well such as install_name_tool, lipo, and nmedit. These do not build under linux, so they have been patched to do so. The work here was used as a starting point: mingwandroid/toolchain4.

In order to build a working toolchain, the following source packages are needed from Apple: cctools, dyld, and ld64.

These tools inject timestamps by default, which produce non-deterministic binaries. The ZERO_AR_DATE environment variable is used to disable that.

This version of cctools has been patched to use the current version of clang's headers and its libLTO.so rather than those from llvmgcc, as it was originally done in toolchain4.

To complicate things further, all builds must target an Apple SDK. These SDKs are free to download, but not redistributable. To obtain it, register for a developer account, then download the Xcode 7.3.1 dmg.

This file is several gigabytes in size, but only a single directory inside is needed:

Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.11.sdk

Unfortunately, the usual linux tools (7zip, hpmount, loopback mount) are incapable of opening this file. To create a tarball suitable for Gitian input, there are two options:

Using Mac OS X, you can mount the dmg, and then create it with:

  $ hdiutil attach Xcode_7.3.1.dmg
  $ tar -C /Volumes/Xcode/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/ -czf MacOSX10.11.sdk.tar.gz MacOSX10.11.sdk

Alternatively, you can use 7zip and SleuthKit to extract the files one by one. The script contrib/macdeploy/extract-osx-sdk.sh automates this. First ensure the dmg file is in the current directory, and then run the script. You may wish to delete the intermediate 5.hfs file and MacOSX10.11.sdk (the directory) when you've confirmed the extraction succeeded.

apt-get install p7zip-full sleuthkit
contrib/macdeploy/extract-osx-sdk.sh
rm -rf 5.hfs MacOSX10.11.sdk

The Gitian descriptors build 2 sets of files: Linux tools, then Apple binaries which are created using these tools. The build process has been designed to avoid including the SDK's files in Gitian's outputs. All interim tarballs are fully deterministic and may be freely redistributed.

genisoimage is used to create the initial DMG. It is not deterministic as-is, so it has been patched. A system genisoimage will work fine, but it will not be deterministic because the file-order will change between invocations. The patch can be seen here: theuni/osx-cross-depends. No effort was made to fix this cleanly, so it likely leaks memory badly. But it's only used for a single invocation, so that's no real concern.

genisoimage cannot compress DMGs, so afterwards, the 'dmg' tool from the libdmg-hfsplus project is used to compress it. There are several bugs in this tool and its maintainer has seemingly abandoned the project. It has been forked and is available (with fixes) here: theuni/libdmg-hfsplus.

The 'dmg' tool has the ability to create DMGs from scratch as well, but this functionality is broken. Only the compression feature is currently used. Ideally, the creation could be fixed and genisoimage would no longer be necessary.

Background images and other features can be added to DMG files by inserting a .DS_Store before creation. This is generated by the script contrib/macdeploy/custom_dsstore.py.

As of OS X Mavericks (10.9), using an Apple-blessed key to sign binaries is a requirement in order to satisfy the new Gatekeeper requirements. Because this private key cannot be shared, we'll have to be a bit creative in order for the build process to remain somewhat deterministic. Here's how it works:

• Builders use Gitian to create an unsigned release. This outputs an unsigned dmg which users may choose to bless and run. It also outputs an unsigned app structure in the form of a tarball, which also contains all of the tools that have been previously (deterministically) built in order to create a final dmg.
• The Apple keyholder uses this unsigned app to create a detached signature, using the script that is also included there. Detached signatures are available from this repository.
• Builders feed the unsigned app + detached signature back into Gitian. It uses the pre-built tools to recombine the pieces into a deterministic dmg.

Unauthenticated REST Interface

The REST API can be enabled with the -rest option.

The interface runs on the same port as the JSON-RPC interface, by default port 8332 for mainnet and port 18332 for testnet.

Supported API

####Transactions GET /rest/tx/<TX-HASH>.<bin|hex|json>

Given a transaction hash: returns a transaction in binary, hex-encoded binary, or JSON formats.

For full TX query capability, one must enable the transaction index via "txindex=1" command line / configuration option.

####Blocks GET /rest/block/<BLOCK-HASH>.<bin|hex|json> GET /rest/block/notxdetails/<BLOCK-HASH>.<bin|hex|json>

Given a block hash: returns a block, in binary, hex-encoded binary or JSON formats.

The HTTP request and response are both handled entirely in-memory, thus making maximum memory usage at least 2.66MB (1 MB max block, plus hex encoding) per request.

With the /notxdetails/ option JSON response will only contain the transaction hash instead of the complete transaction details. The option only affects the JSON response.

####Blockheaders GET /rest/headers/<COUNT>/<BLOCK-HASH>.<bin|hex|json>

Given a block hash: returns amount of blockheaders in upward direction.

Blockhash by height

GET /rest/blockhashbyheight/<HEIGHT>.<bin|hex|json>

Given a height: returns hash of block in best-block-chain at height provided.

####Chaininfos GET /rest/chaininfo.json

Returns various state info regarding block chain processing. Only supports JSON as output format.

• chain : (string) current network name as defined in BIP70 (main, test, regtest)
• blocks : (numeric) the current number of blocks processed in the server
• headers : (numeric) the current number of headers we have validated
• bestblockhash : (string) the hash of the currently best block
• difficulty : (numeric) the current difficulty
• verificationprogress : (numeric) estimate of verification progress [0..1]
• chainwork : (string) total amount of work in active chain, in hexadecimal
• pruned : (boolean) if the blocks are subject to pruning
• pruneheight : (numeric) heighest block available
• softforks : (array) status of softforks in progress

####Query UTXO set GET /rest/getutxos/<checkmempool>/<txid>-<n>/<txid>-<n>/.../<txid>-<n>.<bin|hex|json>

The getutxo command allows querying of the UTXO set given a set of outpoints. See BIP64 for input and output serialisation: https://github.com/bitcoin/bips/blob/master/bip-0064.mediawiki

Example:

$ curl localhost:18332/rest/getutxos/checkmempool/b2cdfd7b89def827ff8af7cd9bff7627ff72e5e8b0f71210f92ea7a4000c5d75-0.json 2>/dev/null | json_pp
{
   "chaintipHash" : "00000000fb01a7f3745a717f8caebee056c484e6e0bfe4a9591c235bb70506fb",
   "chainHeight" : 325347,
   "utxos" : [
      {
         "scriptPubKey" : {
            "addresses" : [
               "mi7as51dvLJsizWnTMurtRmrP8hG2m1XvD"
            ],
            "type" : "pubkeyhash",
            "hex" : "76a9141c7cebb529b86a04c683dfa87be49de35bcf589e88ac",
            "reqSigs" : 1,
            "asm" : "OP_DUP OP_HASH160 1c7cebb529b86a04c683dfa87be49de35bcf589e OP_EQUALVERIFY OP_CHECKSIG"
         },
         "value" : 8.8687,
         "height" : 2147483647,
         "txvers" : 1
      }
   ],
   "bitmap" : "1"
}

####Memory pool GET /rest/mempool/info.json

Returns various information about the TX mempool. Only supports JSON as output format.

• size : (numeric) the number of transactions in the TX mempool
• bytes : (numeric) size of the TX mempool in bytes
• usage : (numeric) total TX mempool memory usage

GET /rest/mempool/contents.json

Returns transactions in the TX mempool. Only supports JSON as output format.

Risks

Running a web browser on the same node with a REST enabled dogecoind can be a risk. Accessing prepared XSS websites could read out tx/block data of your node by placing links like <script src="http://127.0.0.1:8332/rest/tx/1234567890.json"> which might break the nodes privacy.

The following is a list of assets used in the dogecoin source and their proper attribution.

Typicons/Stephen Hutchings

Info

• Icon Pack: Typicons (http://typicons.com)
• Designer: Stephen Hutchings (and more)
• License: MIT
• Site: https://github.com/stephenhutchings/typicons.font

Assets Used

src/qt/res/icons/add.png
src/qt/res/icons/address-book.png,
src/qt/res/icons/configure.png
src/qt/res/icons/debugwindow.png
src/qt/res/icons/edit.png,
src/qt/res/icons/exitcopy.png
src/qt/res/icons/editpaste.png,
src/qt/res/icons/export.png
src/qt/res/icons/eye.png,
src/qt/res/icons/filesave.png
src/qt/res/icons/history.png,
src/qt/res/icons/info.png
src/qt/res/icons/key.png,
src/qt/res/icons/lock_*.png
src/qt/res/icons/open.png,
src/qt/res/icons/overview.png
src/qt/res/icons/quit.png,
src/qt/res/icons/receive.png
src/qt/res/icons/remove.png,
src/qt/res/icons/send.png
src/qt/res/icons/synced.png,
src/qt/res/icons/transaction*.png
src/qt/res/icons/tx_output.png,
src/qt/res/icons/warning.png

Other

Info

• Designer: Jonas Schnelli, Bitboy, Stephen Hutchings, Marco Falke
• Dogecoin Icon: Based on the original Dogecoin logo from Christine Ricks
• Network connection icon: Inspired by flow-merge.svg from Stephen Hutchings
• Some icons are based on Stephan Hutchings Typicons
• License: MIT

Assets Used

src/qt/res/icons/about.png
src/qt/res/icons/about_qt.png,
src/qt/res/icons/dogecoin.icns
src/qt/res/icons/dogecoin.ico,
src/qt/res/icons/dogecoin.png
src/qt/res/icons/clock*.png,
src/qt/res/icons/connect*.png
src/qt/res/icons/eye_minus.png,
src/qt/res/icons/eye_plus.png
src/qt/res/icons/verify.png,
src/qt/res/icons/tx_inout.png
src/qt/res/icons/tx_input.png,
src/qt/res/src/bitcoin.svg,
src/qt/res/src/clock*.svg
src/qt/res/src/connect*.svg,
src/qt/res/src/mine.svg
src/qt/res/src/qt.svg
src/qt/res/src/tx*.svg,
src/qt/res/src/verify.svg

Benchmarking

Dogecoin Core has an internal benchmarking framework, with benchmarks for cryptographic algorithms such as SHA1, SHA256, SHA512 and RIPEMD160. As well as the rolling bloom filter.

After compiling dogecoin-core, the benchmarks can be run with: src/bench/bench_dogecoin

The output will look similar to:

#Benchmark,count,min,max,average
RIPEMD160,448,0.001245033173334,0.002638196945190,0.002461894814457
RollingBloom-refresh,1,0.000635000000000,0.000635000000000,0.000635000000000
RollingBloom-refresh,1,0.000108000000000,0.000108000000000,0.000108000000000
RollingBloom-refresh,1,0.000107000000000,0.000107000000000,0.000107000000000
RollingBloom-refresh,1,0.000204000000000,0.000204000000000,0.000204000000000
SHA1,640,0.000909024336207,0.001938136418660,0.001843086257577
SHA256,256,0.002209486499909,0.008500099182129,0.004300644621253
SHA512,384,0.001319904176016,0.002813005447388,0.002615700786312
Sleep100ms,10,0.205592155456543,0.210056066513062,0.104166316986084
Trig,67108864,0.000000014997003,0.000000015448112,0.000000015188842

More benchmarks are needed for, in no particular order:

• Script Validation
• CCoinDBView caching
• Coins database
• Memory pool
• Wallet coin selection

BIP List

This document lists the protocol features that are implemented by Dogecoin Core (up-to-date up to v1.14.6):

From Bitcoin

• BIP 11: Multisig outputs are standard since v1.4.0.
• BIP 13: The address format for P2SH addresses has been implemented since v1.0.0.
• BIP 14: The subversion string is being used as User Agent since v1.0.0.
• BIP 16: The pay-to-script-hash evaluation rules have been implemented since v1.6.0.
• BIP 21: The URI format for Dogecoin payments has been implemented since v1.0.0.
• BIP 22: The 'getblocktemplate' (GBT) RPC protocol for mining has been implemented since v1.7.0.
• BIP 23: Some extensions to GBT have been implemented since v1.10.0, including longpolling and block proposals.
• BIP 30: The evaluation rules to forbid creating new transactions with the same txid as previous not-fully-spent transactions were implemented since v1.0.0.
• BIP 31: The 'pong' protocol message (and the protocol version bump to 60001) has been implemented since v1.0.0.
• BIP 32: Hierarchical Deterministic Wallets has been implemented since v1.14.0.
• BIP 34: The rule that requires blocks to contain their height (number) in the coinbase input, and the introduction of version 2 blocks has been implemented since v1.4.0.
• BIP 35: The 'mempool' protocol message (and the protocol version bump to 60002) has been implemented since v1.0.0.
• BIP 37: The bloom filtering for transaction relaying, partial merkle trees for blocks, and the protocol version bump to 70001 (enabling low-bandwidth SPV clients) has been implemented since v1.4.0
• BIP 61: The 'reject' protocol message (and the protocol version bump to 70002) was added in v1.7.0.
• BIP 65: The CHECKLOCKTIMEVERIFY softfork was merged in v1.14.0
• BIP 66: The strict DER rules and associated version 3 blocks have been implemented since v1.10.0
• BIP 70 71 72: Payment Protocol support has been available in Dogecoin Core GUI since v1.7.0
• BIP 111: NODE_BLOOM service bit added, and enforced for all peer versions as of v1.10.0.
• BIP 125: Opt-in full replace-by-fee signaling honoured in mempool and mining as of v1.14.0.
• BIP 130: direct headers announcement is negotiated with peer versions >=70012 as of v1.14.0.
• BIP 133: feefilter messages are respected and sent for peer versions >=70013 as of v1.14.0.
• BIP 152: Compact block transfer version 1 are used as of v1.14.0.

From Litecoin

• (Spec missing!): Scrypt-1024 proof-of-work was enabled since v1.0.0.

From Namecoin

• Merged Mining (AuxPoW): AuxPoW blocks were enabled as valid proof of work as of v1.8.0.

From DigiByte

• (Spec missing!): DigiShield difficulty adjustments were enabled as of v1.6.0.

Arch Linux build guide

Last tested with: 1.14.6-dev (as of 22884709) Test date: 2022/07/15

This example lists the steps necessary to setup and build a command line only dogecoind on archlinux:

pacman -S git base-devel boost libevent python db
git clone https://github.com/dogecoin/dogecoin.git
cd dogecoin/
./autogen.sh
./configure --without-gui --without-miniupnpc
make

Fedora build guide

Last tested with: 1.14.6-dev (as of 22884709) Tested on: Fedora 35,35,36

Build requirements

Fedora < 36:

sudo dnf install gcc-c++ libtool which diffutils make autoconf automake \
                 openssl-devel libevent-devel boost-devel libdb-cxx-devel

Fedora >= 36:

sudo dnf install gcc-c++ libtool which diffutils make autoconf automake \
                 openssl1.1-devel libevent-devel boost-devel libdb-cxx-devel

Optional elements

MiniUPNP

Useful when your node is running behind a NAT router.

sudo dnf install miniupnpc-devel

ZeroMQ

sudo dnf install zeromq-devel

GUI requirements

To build the GUI with Qt 5 you need the following:

sudo dnf install qt5-qttools-devel qt5-qtbase-devel protobuf-devel qrencode-devel

Building on FreeBSD

Last tested with: 1.14.5-dev (as of 18dbe32) Tested on: FreeBSD 11.4

Clang is installed by default as cc compiler, this makes it easier to get started than on other distros. Installing dependencies:

pkg install autoconf automake libtool pkgconf
pkg install boost-libs openssl libevent
pkg install gmake

You need to use GNU make (gmake) instead of make. (libressl instead of openssl will also work)

For the wallet (optional):

pkg install db5

As of writing, the default hardening routines will fail on the scrypt code, so currently, no hardened executables can be built, and the --disable-hardening flag is needed for successful compilation.

Then build using:

  ./autogen.sh
  ./configure --disable-hardening MAKE="gmake" \
      CFLAGS="-I/usr/local/include" CXXFLAGS="-I/usr/local/include -I/usr/local/include/db5" \
      LDFLAGS="-L/usr/local/lib -L/usr/local/lib/db5"
  gmake

Note on debugging: The version of gdb installed by default is ancient and considered harmful. It is not suitable for debugging a multi-threaded C++ program, not even for getting backtraces. Please install the package gdb and use the versioned gdb command e.g. gdb7111.

NixOS build guide

This guide lists the steps necessary to setup and build a full GUI distribution of the latest changes on NixOS.

Clone and enter the repo:

$ git clone https://github.com/dogecoin/dogecoin
$ cd dogecoin

Enter the nix-shell environment with all the Dogecoin dependencies present:

$ nix-shell ./contrib/nixos/shell.nix

Run the build steps with flags necessary for NixOS:

$ ./autogen.sh
$ ./configure --with-incompatible-bdb --with-boost-libdir="$(nix eval --raw nixpkgs.boost.out)/lib" --with-gui
$ make

Start the GUI!

$ ./src/qt/dogecoin-qt

OpenBSD build guide

NOTE: This documentation is outdated and needs to be updated

(updated for OpenBSD 6.0)

This guide describes how to build dogecoind and command-line utilities on OpenBSD.

As OpenBSD is most common as a server OS, we will not bother with the GUI.

Preparation

Run the following as root to install the base dependencies for building:

pkg_add gmake libtool libevent
pkg_add autoconf # (select highest version, e.g. 2.69)
pkg_add automake # (select highest version, e.g. 1.15)
pkg_add python # (select highest version, e.g. 3.5)

The default C++ compiler that comes with OpenBSD 5.9 is g++ 4.2. This version is old (from 2007), and is not able to compile the current version of Dogecoin Core, primarily as it has no C++11 support, but even before there were issues. So here we will be installing a newer compiler.

GCC

You can install a newer version of gcc with:

pkg_add g++ # (select newest 4.x version, e.g. 4.9.3)

This compiler will not overwrite the system compiler, it will be installed as egcc and eg++ in /usr/local/bin.

Building boost

Do not use pkg_add boost! The boost version installed thus is compiled using the g++ compiler not eg++, which will result in a conflict between /usr/local/lib/libestdc++.so.XX.0 and /usr/lib/libstdc++.so.XX.0, resulting in a test crash:

test_dogecoin:/usr/lib/libstdc++.so.57.0: /usr/local/lib/libestdc++.so.17.0 : WARNING: symbol(_ZN11__gnu_debug17_S_debug_me ssagesE) size mismatch, relink your program
...
Segmentation fault (core dumped)

This makes it necessary to build boost, or at least the parts used by Dogecoin Core, manually:

# Pick some path to install boost to, here we create a directory within the dogecoin directory
BITCOIN_ROOT=$(pwd)
BOOST_PREFIX="${BITCOIN_ROOT}/boost"
mkdir -p $BOOST_PREFIX

# Fetch the source and verify that it is not tampered with
curl -o boost_1_61_0.tar.bz2 http://heanet.dl.sourceforge.net/project/boost/boost/1.61.0/boost_1_61_0.tar.bz2
echo 'a547bd06c2fd9a71ba1d169d9cf0339da7ebf4753849a8f7d6fdb8feee99b640  boost_1_61_0.tar.bz2' | sha256 -c
# MUST output: (SHA256) boost_1_61_0.tar.bz2: OK
tar -xjf boost_1_61_0.tar.bz2

# Boost 1.61 needs one small patch for OpenBSD
cd boost_1_61_0
# Also here: https://gist.githubusercontent.com/laanwj/bf359281dc319b8ff2e1/raw/92250de8404b97bb99d72ab898f4a8cb35ae1ea3/patch-boost_test_impl_execution_monitor_ipp.patch
patch -p0 < /usr/ports/devel/boost/patches/patch-boost_test_impl_execution_monitor_ipp

# Build w/ minimum configuration necessary for dogecoin
echo 'using gcc : : eg++ : <cxxflags>"-fvisibility=hidden -fPIC" <linkflags>"" <archiver>"ar" <striper>"strip"  <ranlib>"ranlib" <rc>"" : ;' > user-config.jam
config_opts="runtime-link=shared threadapi=pthread threading=multi link=static variant=release --layout=tagged --build-type=complete --user-config=user-config.jam -sNO_BZIP2=1"
./bootstrap.sh --without-icu --with-libraries=chrono,filesystem,program_options,system,thread,test
./b2 -d2 -j2 -d1 ${config_opts} --prefix=${BOOST_PREFIX} stage
./b2 -d0 -j4 ${config_opts} --prefix=${BOOST_PREFIX} install

Building BerkeleyDB

BerkeleyDB is only necessary for the wallet functionality. To skip this, pass --disable-wallet to ./configure.

See "Berkeley DB" in build_unix.md for instructions on how to build BerkeleyDB 4.8. You cannot use the BerkeleyDB library from ports, for the same reason as boost above (g++/libstd++ incompatibility).

# Pick some path to install BDB to, here we create a directory within the dogecoin directory
BITCOIN_ROOT=$(pwd)
BDB_PREFIX="${BITCOIN_ROOT}/db4"
mkdir -p $BDB_PREFIX

# Fetch the source and verify that it is not tampered with
curl -o db-4.8.30.NC.tar.gz 'http://download.oracle.com/berkeley-db/db-4.8.30.NC.tar.gz'
echo '12edc0df75bf9abd7f82f821795bcee50f42cb2e5f76a6a281b85732798364ef  db-4.8.30.NC.tar.gz' | sha256 -c
# MUST output: (SHA256) db-4.8.30.NC.tar.gz: OK
tar -xzf db-4.8.30.NC.tar.gz

# Build the library and install to specified prefix
cd db-4.8.30.NC/build_unix/
#  Note: Do a static build so that it can be embedded into the executable, instead of having to find a .so at runtime
../dist/configure --enable-cxx --disable-shared --with-pic --prefix=$BDB_PREFIX CC=egcc CXX=eg++ CPP=ecpp
make install # do NOT use -jX, this is broken

Resource limits

The standard ulimit restrictions in OpenBSD are very strict:

data(kbytes)         1572864

This is, unfortunately, no longer enough to compile some .cpp files in the project, at least with gcc 4.9.3 (see issue https://github.com/bitcoin/bitcoin/issues/6658). If your user is in the staff group the limit can be raised with:

ulimit -d 3000000

The change will only affect the current shell and processes spawned by it. To make the change system-wide, change datasize-cur and datasize-max in /etc/login.conf, and reboot.

Building Dogecoin Core

Important: use gmake, not make. The non-GNU make will exit with a horrible error.

Preparation:

export AUTOCONF_VERSION=2.69 # replace this with the autoconf version that you installed
export AUTOMAKE_VERSION=1.15 # replace this with the automake version that you installed
./autogen.sh

Make sure BDB_PREFIX and BOOST_PREFIX are set to the appropriate paths from the above steps.

To configure with wallet:

./configure --with-gui=no --with-boost=$BOOST_PREFIX \
    CC=egcc CXX=eg++ CPP=ecpp \
    BDB_LIBS="-L${BDB_PREFIX}/lib -ldb_cxx-4.8" BDB_CFLAGS="-I${BDB_PREFIX}/include"

To configure without wallet:

./configure --disable-wallet --with-gui=no --with-boost=$BOOST_PREFIX \
    CC=egcc CXX=eg++ CPP=ecpp

Build and run the tests:

gmake # can use -jX here for parallelism
gmake check

Clang (not currently working)

WARNING: This is outdated, needs to be updated for OpenBSD 6.0 and re-tried.

Using a newer g++ results in linking the new code to a new libstdc++. Libraries built with the old g++, will still import the old library. This gives conflicts, necessitating rebuild of all C++ dependencies of the application.

With clang this can - at least theoretically - be avoided because it uses the base system's libstdc++.

pkg_add llvm boost

./configure --disable-wallet --with-gui=no CC=clang CXX=clang++
gmake

However, this does not appear to work. Compilation succeeds, but link fails with many 'local symbol discarded' errors:

local symbol 150: discarded in section `.text._ZN10tinyformat6detail14FormatIterator6finishEv' from libbitcoin_util.a(libbitcoin_util_a-random.o)
local symbol 151: discarded in section `.text._ZN10tinyformat6detail14FormatIterator21streamStateFromFormatERSoRjPKcii' from libbitcoin_util.a(libbitcoin_util_a-random.o)
local symbol 152: discarded in section `.text._ZN10tinyformat6detail12convertToIntIA13_cLb0EE6invokeERA13_Kc' from libbitcoin_util.a(libbitcoin_util_a-random.o)

According to similar reported errors this is a binutils (ld) issue in 2.15, the version installed by OpenBSD 5.7:

• http://openbsd-archive.7691.n7.nabble.com/UPDATE-cppcheck-1-65-td248900.html
• https://llvm.org/bugs/show_bug.cgi?id=9758

There is no known workaround for this.

Mac OS X Build Instructions and Notes

The commands in this guide should be executed in a Terminal application. The built-in one is located in /Applications/Utilities/Terminal.app.

Preparation

Install the OS X command line tools:

xcode-select --install

When the popup appears, click Install.

Then install Homebrew.

Dependencies

brew install automake libtool boost miniupnpc openssl pkg-config protobuf qt5 libevent
brew install berkeley-db # You need to make sure you install a version >= 5.3.28, but as close to 5.3.28 as possible. Check the homebrew docs to find out how to install older versions.

If you want to build the disk image with make deploy (.dmg / optional), you need RSVG

brew install librsvg

NOTE: Building with Qt4 is still supported, however, could result in a broken UI. Building with Qt5 is recommended.

Build Dogecoin Core

1. Clone the dogecoin source code and cd into dogecoin

    git clone https://github.com/dogecoin/dogecoin
    cd dogecoin
   

2. Build dogecoin:

   Configure and build the headless dogecoin binaries as well as the GUI (if Qt is found).

   You can disable the GUI build by passing --without-gui to configure.

   ./autogen.sh
   ./configure
   make
   

3. It is recommended to build and run the unit tests:

   make check
   

4. You can also create a .dmg that contains the .app bundle (optional):

   make deploy
   

Running

Dogecoin Core is now available at ./src/dogecoind

Before running, it's recommended you create an RPC configuration file.

echo -e "rpcuser=dogecoinrpc\nrpcpassword=$(xxd -l 16 -p /dev/urandom)" > "/Users/${USER}/Library/Application Support/Dogecoin/dogecoin.conf"

chmod 600 "/Users/${USER}/Library/Application Support/Dogecoin/dogecoin.conf"

The first time you run dogecoind, it will start downloading the blockchain. This process could take several hours.

You can monitor the download process by looking at the debug.log file:

tail -f $HOME/Library/Application\ Support/Dogecoin/debug.log

Other commands:

./src/dogecoind -daemon # Starts the dogecoin daemon.
./src/dogecoin-cli --help # Outputs a list of command-line options.
./src/dogecoin-cli help # Outputs a list of RPC commands when the daemon is running.

Using Qt Creator as IDE

You can use Qt Creator as an IDE, for dogecoin development. Download and install the community edition of Qt Creator. Uncheck everything except Qt Creator during the installation process.

1. Make sure you installed everything through Homebrew mentioned above
2. Do a proper ./configure --enable-debug
3. In Qt Creator do "New Project" -> Import Project -> Import Existing Project
4. Enter "dogecoin-qt" as project name, enter src/qt as location
5. Leave the file selection as it is
6. Confirm the "summary page"
7. In the "Projects" tab select "Manage Kits..."
8. Select the default "Desktop" kit and select "Clang (x86 64bit in /usr/bin)" as compiler
9. Select LLDB as debugger (you might need to set the path to your installation)
10. Start debugging with Qt Creator

Notes

• Tested on OS X 10.8 through 10.12 on 64-bit Intel processors only.

• Building with downloaded Qt binaries is not officially supported. See the notes in #7714

Unix Build of Dogecoin Core

This installation guide serves as a basis for all UNIX and UNIX-like operating systems. All examples in this guide are illustrated using an Ubuntu/Debian OS, and guides for different OSs can be found in separate documentation, as listed below.

1. Install dependencies
   • Using packaged dependencies
   • Ubuntu & Debian example
2. Build steps
3. Build configuration
   • Enable Qt GUI
   • Wallet
   • Disable-wallet mode
   • Miniupnpc
   • Security
   • Memory requirements
4. ARM Cross-compilation
5. OS-specific documentation:
   • Archlinux
   • Fedora
   • FreeBSD
   • NixOs
   • OpenBSD

Install dependencies

You must install required dependencies to build a basic Dogecoin daemon, optional dependencies may vary according to your requirements.

Wallet is optional to run a node, see Wallet section to enable them.

Required dependencies :

Optional dependencies:

For the versions used in the release, see release-process.md under Fetch and build inputs.

Using packaged dependencies

Dogecoin Core's released binaries are built using the "depends system", which contains exact, tested versions of all dependencies. To create binaries that are using only fully tested dependencies, see the documentation in the depends directory and the Release process documentation.

Ubuntu & Debian example

Required dependencies :

sudo apt-get install build-essential libtool autotools-dev automake pkg-config libssl-dev libevent-dev bsdmainutils
sudo apt-get install libboost-system-dev libboost-filesystem-dev libboost-chrono-dev libboost-program-options-dev libboost-test-dev libboost-thread-dev

Optional dependencies :

# Qt (required for dogecoin-qt GUI)
sudo apt-get install libqt5gui5 libqt5core5a libqt5dbus5 qttools5-dev qttools5-dev-tools libprotobuf-dev protobuf-compiler libqrencode-dev

# BerkeleyDB (version 5.3)
sudo apt install libdb5.3++-dev libdb5.3++ libdb5.3-dev

# ZMQ (provides ZMQ API 4.x)
sudo apt-get install libzmq3-dev

# Miniupnpc
sudo apt-get install libminiupnpc-dev

Build steps

According to installed dependencies, the following steps will compile dogecoind, dogecoin-cli and dogecoin-qt.

./autogen.sh
./configure
make
make install # optional

See Build configuration for extra settings.

Build configuration

Configurations are done during the ./configure step. Use --help to see all available options.

Enable Qt GUI

Create dogecoin-qt, the core wallet GUI.

./configure --with-gui

Wallet

BerkeleyDB is required for wallet functionality and use of the wallet.dat file.

By default, Dogecoin Core expects BerkeleyDB 5.3. You can use a different version by specifying --with-incompatible-bdb flag.

If you have to build it yourself, you can use the installation script included in contrib/ like so:

./contrib/install_db5.sh `pwd`

from the root of the repository.

Otherwise, you can build Dogecoin Core from self-compiled depends.

Note: You only need Berkeley DB if the wallet is enabled (see Disable-wallet mode).

Disable-wallet mode

When the intention is to run only a P2P node without a wallet, Dogecoin may be compiled in disable-wallet mode with:

./configure --disable-wallet

Mining is also possible in disable-wallet mode, but only using the getblocktemplate RPC call, not getwork.

Miniupnpc

miniupnpc may be used for UPnP port mapping. It can be downloaded from here. UPnP support is compiled in and turned off by default. See the configure options for upnp behavior desired:

--without-miniupnpc      #No UPnP support miniupnp not required
--disable-upnp-default   #(the default) UPnP support turned off by default at runtime
--enable-upnp-default    #UPnP support turned on by default at runtime

Security

To help make your Dogecoin installation more secure by making certain attacks impossible to exploit even if a vulnerability is found, binaries are hardened by default. This can be disabled with:

Hardening Flags:

./configure --enable-hardening
./configure --disable-hardening

Hardening enables the following features:

• Position Independent Executable Build position independent code to take advantage of Address Space Layout Randomization offered by some kernels. Attackers who can cause execution of code at an arbitrary memory location are thwarted if they don't know where anything useful is located. The stack and heap are randomly located by default but this allows the code section to be randomly located as well.

  On an AMD64 processor where a library was not compiled with -fPIC, this will cause an error such as: relocation R_X86_64_32 against '......' can not be used when making a shared object;

  To test that you have built PIE executable, install scanelf, part of paxutils, and use:

  scanelf -e ./dogecoin

  The output should contain:

  TYPE ET_DYN

• Non-executable Stack If the stack is executable, trivial stack-based buffer overflow exploits are possible if vulnerable buffers are found. By default, Dogecoin should be built with a non-executable stack, but if one of the libraries it uses asks for an executable stack or someone makes a mistake and uses a compiler extension which requires an executable stack, it will silently build an executable without the non-executable stack protection.

  To verify that the stack is non-executable after compiling, use: scanelf -e ./dogecoin

  the output should contain: STK/REL/PTL RW- R-- RW-

  The STK RW- means that the stack is readable and writeable, but not executable.

Memory Requirements

C++ compilers are memory-hungry. It is recommended to have at least 1.5 GB of memory available when compiling Dogecoin Core. On systems with less, gcc can be tuned to conserve memory with additional CXXFLAGS:

./configure CXXFLAGS="--param ggc-min-expand=1 --param ggc-min-heapsize=32768"

ARM Cross-compilation

These steps can be performed on, for example, an Ubuntu VM. The depends system will also work on other Linux distributions, however the commands for installing the toolchain will be different.

Make sure you install the build requirements mentioned above. Then, install the toolchain and curl:

sudo apt-get install g++-arm-linux-gnueabihf curl

To build executables for ARM:

cd depends
make HOST=arm-linux-gnueabihf NO_QT=1
cd ..
./configure --prefix=$PWD/depends/arm-linux-gnueabihf --enable-glibc-back-compat --enable-reduce-exports LDFLAGS=-static-libstdc++
make

For further documentation on the depends system see README.md in the depends directory.

WINDOWS BUILD NOTES

Below are some notes on how to build Dogecoin Core for Windows.

Most developers use cross-compilation from Ubuntu to build executables for Windows. This is also used to build the release binaries.

While there are potentially a number of ways to build on Windows (for example using msys / mingw-w64), using the Windows Subsystem For Linux is the most straightforward. If you are building with another method, please contribute the instructions here for others who are running versions of Windows that are not compatible with the Windows Subsystem for Linux.

Compiling with Windows Subsystem For Linux

With Windows 10, Microsoft has released a new feature named the Windows Subsystem for Linux. This feature allows you to run a bash shell directly on Windows in an Ubuntu-based environment. Within this environment you can cross compile for Windows without the need for a separate Linux VM or server.

This feature is not supported in versions of Windows prior to Windows 10 or on Windows Server SKUs. In addition, it is available only for 64-bit versions of Windows.

To get the bash shell, you must first activate the feature in Windows.

1. Enable the Windows Subsystem for Linux feature

• Open the Windows Features dialog (OptionalFeatures.exe)
• Enable 'Windows Subsystem for Linux'
• Click 'OK' and restart if necessary

2. Install Ubuntu

• Open Microsoft Store and search for "Ubuntu 18.04" or use this link
• Click Install

3. Complete Installation

• Open a cmd prompt and type "Ubuntu1804"
• Create a new UNIX user account (this is a separate account from your Windows account)

After the bash shell is active, you can follow the instructions below, starting with the "Cross-compilation" section. Compiling the 64-bit version is recommended but it is possible to compile the 32-bit version.

Cross-compilation

These steps can be performed on, for example, an Ubuntu VM. The depends system will also work on other Linux distributions, however the commands for installing the toolchain will be different.

First, install the general dependencies:

sudo apt update
sudo apt upgrade
sudo apt-get install build-essential libtool autotools-dev automake pkg-config bsdmainutils curl git

If you want to build with the wallet and Qt GUI you also want to install the following (this example is under Ubuntu):

sudo apt-get install libssl-dev libboost-all-dev qt5-default libprotobuf-dev libqrencode4 libdb++-dev libdb-dev miniupnpc

A host toolchain (build-essential) is necessary because some dependency packages (such as protobuf) need to build host utilities that are used in the build process.

Building for 64-bit Windows

To build executables for Windows 64-bit, install the following dependencies:

sudo apt-get install g++-mingw-w64-x86-64

For Ubuntu 18.04 and 20.04, set the default mingw32 g++ compiler option to posix:

sudo update-alternatives --config x86_64-w64-mingw32-g++ 

...Choose the "posix" (vs 'auto' or 'win32') option, and continue.

Note that for WSL v1 the Dogecoin Core source path MUST be somewhere in the default mount file system, for example /usr/src/dogecoin, AND not under, for example, /mnt/d/dogecoin.

If this is not the case the dependency autoconf scripts will fail (silently.) This means you cannot use a directory that is located directly on the host Windows file system to perform the build.

If using WSL 1, you'll need to turn off WSL Support for Win32 applications temporarily, or you will get ABI errors and format errors for some .o files.

If using WSL 1 then build using:

PATH=$(echo "$PATH" | sed -e 's/:\/mnt.*//g') # strip out problematic Windows %PATH% imported var
sudo bash -c "echo 0 > /proc/sys/fs/binfmt_misc/status" # Temporarily Disable WSL support for Win32 applications.
cd depends
make HOST=x86_64-w64-mingw32
cd ..
./autogen.sh
CONFIG_SITE=$PWD/depends/x86_64-w64-mingw32/share/config.site ./configure --prefix=/
make
sudo bash -c "echo 1 > /proc/sys/fs/binfmt_misc/status" # Re-Enable WSL support for Win32 applications.

If using WSL 2 then you should be able to build just with:

cd depends
make HOST=x86_64-w64-mingw32
cd ..
./autogen.sh # not required when building from tarball
CONFIG_SITE=$PWD/depends/x86_64-w64-mingw32/share/config.site ./configure --prefix=/
make

Building for 32-bit Windows

To build executables for Windows 32-bit, install the following dependencies:

sudo apt-get install g++-mingw-w64-i686 mingw-w64-i686-dev 

Then build using:

cd depends
make HOST=i686-w64-mingw32
cd ..
./autogen.sh # not required when building from tarball
CONFIG_SITE=$PWD/depends/i686-w64-mingw32/share/config.site ./configure --prefix=/
make

Depends system

For further documentation on the depends system see README.md in the depends directory.

Installation

After building using the Windows subsystem it can be useful to copy the compiled executables to a directory on the windows drive in the same directory structure as they appear in the release .zip archive. This can be done in the following way. This will install to c:\workspace\dogecoin, for example:

make install DESTDIR=/mnt/c/workspace/dogecoin

Developer Notes

Various coding styles have been used during the history of the codebase, and the result is not very consistent. However, we're now trying to converge to a single style, so please use it in new code. Old code will be converted gradually and you are encouraged to use the provided clang-format-diff script to clean up the patch automatically before submitting a pull request.

• Basic rules specified in src/.clang-format.
  • Braces on new lines for namespaces, classes, functions, methods.
  • Braces on the same line for everything else.
  • 4 space indentation (no tabs) for every block except namespaces.
  • No indentation for public/protected/private or for namespace.
  • No extra spaces inside parenthesis; don't do ( this )
  • No space after function names; one space after if, for and while.
  • If an if only has a single-statement then-clause, it can appear on the same line as the if, without braces. In every other case, braces are required, and the then and else clauses must appear correctly indented on a new line.
  • ++i is preferred over i++.

Block style example:

namespace foo
{
class Class
{
    bool Function(const std::string& s, int n)
    {
        // Comment summarising what this section of code does
        for (int i = 0; i < n; ++i) {
            // When something fails, return early
            if (!Something()) return false;
            ...
            if (SomethingElse()) {
                DoMore();
            } else {
                DoLess();
            }
        }

        // Success return is usually at the end
        return true;
    }
}
}

Doxygen comments

To facilitate the generation of documentation, use doxygen-compatible comment blocks for functions, methods and fields.

For example, to describe a function use:

/**
 * ... text ...
 * @param[in] arg1    A description
 * @param[in] arg2    Another argument description
 * @pre Precondition for function...
 */
bool function(int arg1, const char *arg2)

A complete list of @xxx commands can be found at http://www.stack.nl/~dimitri/doxygen/manual/commands.html. As Doxygen recognizes the comments by the delimiters (/** and */ in this case), you don't need to provide any commands for a comment to be valid; just a description text is fine.

To describe a class use the same construct above the class definition:

/**
 * Alerts are for notifying old versions if they become too obsolete and
 * need to upgrade. The message is displayed in the status bar.
 * @see GetWarnings()
 */
class CAlert
{

To describe a member or variable use:

int var; //!< Detailed description after the member

or

//! Description before the member
int var;

Also OK:

///
/// ... text ...
///
bool function2(int arg1, const char *arg2)

Not OK (used plenty in the current source, but not picked up):

//
// ... text ...
//

A full list of comment syntaxes picked up by doxygen can be found at http://www.stack.nl/~dimitri/doxygen/manual/docblocks.html, but if possible use one of the above styles.

Development tips and tricks

compiling for debugging

Run configure with the --enable-debug option, then make. Or run configure with CXXFLAGS="-g -ggdb -O0" or whatever debug flags you need.

debug.log

If the code is behaving strangely, take a look in the debug.log file in the data directory; error and debugging messages are written there.

The -debug=... command-line option controls debugging; running with just -debug or -debug=1 will turn on all categories (and give you a very large debug.log file).

The Qt code routes qDebug() output to debug.log under category "qt": run with -debug=qt to see it.

testnet and regtest modes

Run with the -testnet option to run with "play dogecoins" on the test network, if you are testing multi-machine code that needs to operate across the internet.

If you are testing something that can run on one machine, run with the -regtest option. In regression test mode, blocks can be created on-demand; see qa/rpc-tests/ for tests that run in -regtest mode.

DEBUG_LOCKORDER

Dogecoin Core is a multithreaded application, and deadlocks or other multithreading bugs can be very difficult to track down. Compiling with -DDEBUG_LOCKORDER (configure CXXFLAGS="-DDEBUG_LOCKORDER -g") inserts run-time checks to keep track of which locks are held, and adds warnings to the debug.log file if inconsistencies are detected.

Locking/mutex usage notes

The code is multi-threaded, and uses mutexes and the LOCK/TRY_LOCK macros to protect data structures.

Deadlocks due to inconsistent lock ordering (thread 1 locks cs_main and then cs_wallet, while thread 2 locks them in the opposite order: result, deadlock as each waits for the other to release its lock) are a problem. Compile with -DDEBUG_LOCKORDER to get lock order inconsistencies reported in the debug.log file.

Re-architecting the core code so there are better-defined interfaces between the various components is a goal, with any necessary locking done by the components (e.g. see the self-contained CKeyStore class and its cs_KeyStore lock for example).

Threads

• ThreadScriptCheck : Verifies block scripts.

• ThreadImport : Loads blocks from blk*.dat files or bootstrap.dat.

• StartNode : Starts other threads.

• ThreadDNSAddressSeed : Loads addresses of peers from the DNS.

• ThreadMapPort : Universal plug-and-play startup/shutdown

• ThreadSocketHandler : Sends/Receives data from peers on port 22556.

• ThreadOpenAddedConnections : Opens network connections to added nodes.

• ThreadOpenConnections : Initiates new connections to peers.

• ThreadMessageHandler : Higher-level message handling (sending and receiving).

• DumpAddresses : Dumps IP addresses of nodes to peers.dat.

• ThreadFlushWalletDB : Close the wallet.dat file if it hasn't been used in 500ms.

• ThreadRPCServer : Remote procedure call handler, listens on port 22555 for connections and services them.

• DogecoinMiner : Generates dogecoins (if wallet is enabled).

• Shutdown : Does an orderly shutdown of everything.

Ignoring IDE/editor files

In closed-source environments in which everyone uses the same IDE it is common to add temporary files it produces to the project-wide .gitignore file.

However, in open source software such as Bitcoin Core, where everyone uses their own editors/IDE/tools, it is less common. Only you know what files your editor produces and this may change from version to version. The canonical way to do this is thus to create your local gitignore. Add this to ~/.gitconfig:

[core]
        excludesfile = /home/.../.gitignore_global

(alternatively, type the command git config --global core.excludesfile ~/.gitignore_global on a terminal)

Then put your favourite tool's temporary filenames in that file, e.g.

# NetBeans
nbproject/

Another option is to create a per-repository excludes file .git/info/exclude. These are not committed but apply only to one repository.

If a set of tools is used by the build system or scripts the repository (for example, lcov) it is perfectly acceptable to add its files to .gitignore and commit them.

Development guidelines

A few non-style-related recommendations for developers, as well as points to pay attention to for reviewers of Bitcoin Core code.

General Bitcoin Core

• New features should be exposed on RPC first, then can be made available in the GUI

  • Rationale: RPC allows for better automatic testing. The test suite for the GUI is very limited

• Make sure pull requests pass Travis CI before merging

  • Rationale: Makes sure that they pass thorough testing, and that the tester will keep passing on the master branch. Otherwise all new pull requests will start failing the tests, resulting in confusion and mayhem

  • Explanation: If the test suite is to be updated for a change, this has to be done first

Wallet

• Make sure that no crashes happen with run-time option -disablewallet.

  • Rationale: In RPC code that conditionally uses the wallet (such as validateaddress) it is easy to forget that global pointer pwalletMain can be NULL. See qa/rpc-tests/disablewallet.py for functional tests exercising the API with -disablewallet

• Include db_cxx.h (BerkeleyDB header) only when ENABLE_WALLET is set

  • Rationale: Otherwise compilation of the disable-wallet build will fail in environments without BerkeleyDB

General C++

• Assertions should not have side-effects

  • Rationale: Even though the source code is set to to refuse to compile with assertions disabled, having side-effects in assertions is unexpected and makes the code harder to understand

• If you use the .h, you must link the .cpp

  • Rationale: Include files define the interface for the code in implementation files. Including one but not linking the other is confusing. Please avoid that. Moving functions from the .h to the .cpp should not result in build errors

• Use the RAII (Resource Acquisition Is Initialization) paradigm where possible. For example by using unique_ptr for allocations in a function.

  • Rationale: This avoids memory and resource leaks, and ensures exception safety

C++ data structures

• Never use the std::map [] syntax when reading from a map, but instead use .find()

  • Rationale: [] does an insert (of the default element) if the item doesn't exist in the map yet. This has resulted in memory leaks in the past, as well as race conditions (expecting read-read behavior). Using [] is fine for writing to a map

• Do not compare an iterator from one data structure with an iterator of another data structure (even if of the same type)

  • Rationale: Behavior is undefined. In C++ parlor this means "may reformat the universe", in practice this has resulted in at least one hard-to-debug crash bug

• Watch out for out-of-bounds vector access. &vch[vch.size()] is illegal, including &vch[0] for an empty vector. Use vch.data() and vch.data() + vch.size() instead.

• Vector bounds checking is only enabled in debug mode. Do not rely on it

• Make sure that constructors initialize all fields. If this is skipped for a good reason (i.e., optimization on the critical path), add an explicit comment about this

  • Rationale: Ensure determinism by avoiding accidental use of uninitialized values. Also, static analyzers balk about this.

• Use explicitly signed or unsigned chars, or even better uint8_t and int8_t. Do not use bare char unless it is to pass to a third-party API. This type can be signed or unsigned depending on the architecture, which can lead to interoperability problems or dangerous conditions such as out-of-bounds array accesses

• Prefer explicit constructions over implicit ones that rely on 'magical' C++ behavior

  • Rationale: Easier to understand what is happening, thus easier to spot mistakes, even for those that are not language lawyers

Strings and formatting

• Be careful of LogPrint versus LogPrintf. LogPrint takes a category argument, LogPrintf does not.

  • Rationale: Confusion of these can result in runtime exceptions due to formatting mismatch, and it is easy to get wrong because of subtly similar naming

• Use std::string, avoid C string manipulation functions

  • Rationale: C++ string handling is marginally safer, less scope for buffer overflows and surprises with \0 characters. Also some C string manipulations tend to act differently depending on platform, or even the user locale

• Use ParseInt32, ParseInt64, ParseUInt32, ParseUInt64, ParseDouble from utilstrencodings.h for number parsing

  • Rationale: These functions do overflow checking, and avoid pesky locale issues

• For strprintf, LogPrint, LogPrintf formatting characters don't need size specifiers

  • Rationale: Bitcoin Core uses tinyformat, which is type safe. Leave them out to avoid confusion

Variable names

The shadowing warning (-Wshadow) is enabled by default. It prevents issues rising from using a different variable with the same name.

Please name variables so that their names do not shadow variables defined in the source code.

E.g. in member initializers, prepend _ to the argument name shadowing the member name:

class AddressBookPage
{
    Mode mode;
}

AddressBookPage::AddressBookPage(Mode _mode) :
      mode(_mode)
...

When using nested cycles, do not name the inner cycle variable the same as in upper cycle etc.

Threads and synchronization

• Build and run tests with -DDEBUG_LOCKORDER to verify that no potential deadlocks are introduced. As of 0.12, this is defined by default when configuring with --enable-debug

• When using LOCK/TRY_LOCK be aware that the lock exists in the context of the current scope, so surround the statement and the code that needs the lock with braces

  OK:

{
    TRY_LOCK(cs_vNodes, lockNodes);
    ...
}

Wrong:

TRY_LOCK(cs_vNodes, lockNodes);
{
    ...
}

Source code organization

• Implementation code should go into the .cpp file and not the .h, unless necessary due to template usage or when performance due to inlining is critical

  • Rationale: Shorter and simpler header files are easier to read, and reduce compile time

• Don't import anything into the global namespace (using namespace ...). Use fully specified types such as std::string.

  • Rationale: Avoids symbol conflicts

GUI

• Do not display or manipulate dialogs in model code (classes *Model)

  • Rationale: Model classes pass through events and data from the core, they should not interact with the user. That's where View classes come in. The converse also holds: try to not directly access core data structures from Views.

Subtrees

Several parts of the repository are subtrees of software maintained elsewhere.

Some of these are maintained by active developers of Bitcoin Core, in which case changes should probably go directly upstream without being PRed directly against the project. They will be merged back in the next subtree merge.

Others are external projects without a tight relationship with our project. Changes to these should also be sent upstream but bugfixes may also be prudent to PR against Bitcoin Core so that they can be integrated quickly. Cosmetic changes should be purely taken upstream.

There is a tool in contrib/devtools/git-subtree-check.sh to check a subtree directory for consistency with its upstream repository.

Current subtrees include:

• src/leveldb

  • Upstream at https://github.com/google/leveldb ; Maintained by Google, but open important PRs to Core to avoid delay

• src/libsecp256k1

  • Upstream at https://github.com/bitcoin-core/secp256k1/ ; actively maintaned by Core contributors.

• src/crypto/ctaes

  • Upstream at https://github.com/bitcoin-core/ctaes ; actively maintained by Core contributors.

• src/univalue

  • Upstream at https://github.com/jgarzik/univalue ; report important PRs to Core to avoid delay.

Git and GitHub tips

• For resolving merge/rebase conflicts, it can be useful to enable diff3 style using git config merge.conflictstyle diff3. Instead of

    <<<
    yours
    ===
    theirs
    >>>
  

  you will see

    <<<
    yours
    |||
    original
    ===
    theirs
    >>>
  

  This may make it much clearer what caused the conflict. In this style, you can often just look at what changed between original and theirs, and mechanically apply that to yours (or the other way around).

• When reviewing patches which change indentation in C++ files, use git diff -w and git show -w. This makes the diff algorithm ignore whitespace changes. This feature is also available on github.com, by adding ?w=1 at the end of any URL which shows a diff.

• When reviewing patches that change symbol names in many places, use git diff --word-diff. This will instead of showing the patch as deleted/added lines, show deleted/added words.

• When reviewing patches that move code around, try using git diff --patience commit~:old/file.cpp commit:new/file/name.cpp, and ignoring everything except the moved body of code which should show up as neither + or - lines. In case it was not a pure move, this may even work when combined with the -w or --word-diff options described above.

• When looking at other's pull requests, it may make sense to add the following section to your .git/config file:

    [remote "upstream-pull"]
            fetch = +refs/pull/*:refs/remotes/upstream-pull/*
            url = git@github.com:dogecoin/dogecoin.git
  

  This will add an upstream-pull remote to your git repository, which can be fetched using git fetch --all or git fetch upstream-pull. Afterwards, you can use upstream-pull/NUMBER/head in arguments to git show, git checkout and anywhere a commit id would be acceptable to see the changes from pull request NUMBER.

Expectations for DNS Seed operators

Dogecoin Core attempts to minimize the level of trust in DNS seeds, but DNS seeds still pose a small amount of risk for the network. As such, DNS seeds must be run by entities which have some minimum level of trust within the Dogecoin community.

Other implementations of Dogecoin software may also use the same seeds and may be more exposed. In light of this exposure, this document establishes some basic expectations for operating dnsseeds.

0. A DNS seed operating organization or person is expected to follow good host security practices, maintain control of applicable infrastructure, and not sell or transfer control of the DNS seed. Any hosting services contracted by the operator are equally expected to uphold these expectations.

1. The DNS seed results must consist exclusively of fairly selected and functioning Dogecoin nodes from the public network to the best of the operator's understanding and capability.

2. For the avoidance of doubt, the results may be randomized but must not single-out any group of hosts to receive different results unless due to an urgent technical necessity and disclosed.

3. The results may not be served with a DNS TTL of less than one minute.

4. Any logging of DNS queries should be only that which is necessary for the operation of the service or urgent health of the Dogecoin network and must not be retained longer than necessary nor disclosed to any third party.

5. Information gathered as a result of the operators node-spidering (not from DNS queries) may be freely published or retained, but only if this data was not made more complete by biasing node connectivity (a violation of expectation (1)).

6. Operators are encouraged, but not required, to publicly document the details of their operating practices.

7. A reachable email contact address must be published for inquiries related to the DNS seed operation.

If these expectations cannot be satisfied the operator should discontinue providing services and contact the active Dogecoin Core development team as well as posting on Dogecoin Dev.

Behavior outside of these expectations may be reasonable in some situations but should be discussed in public in advance.

See also

• dogecoin-seeder is a reference implementation of a DNS seed.

Experimental features

Features can be marked as experimental when the functionality is desired but further analysis, testing or follow-up work is needed to make sure that the feature is fully ready for rollout to every node in the network. This can specifically help the introduction of performance updates or other lower-level improvements where positive and/or negative effects may take a longer time to test. The PR benefits from being merged because this makes it easier for testers to pick and choose sets of features to experiment with in their custom built Dogecoin Core deployments.

Enabling experimental features

Experiments can be enabled by passing --enable-experimental AND the desired experimental feature to ./configure:

Current experiments

Requirements

1. An experimental feature shall be controlled by a configuration flag inside configure.ac that explicitly enables the feature.
2. The feature shall by default be disabled.
3. The feature shall call the DOGECOIN_REQUIRE_EXPERIMENTAL macro in configure.ac, to enforce that --enable-experimental was passed.
4. All code blocks related to the feature shall be guarded by a preprocessor check on the configuration flag, to prevent leaking code into releases.
5. Inside each experimental code block, a call shall be made to the DOGECOIN_REQUIRE_EXPERIMENTAL macro from support/experimental.h, to clearly mark the code as experimental and ease review and troubleshooting.
6. Only when an experimental feature matures into production shall the above requirements be voided.

Lifecycle

Experimental features move through different stages. By default, each experiment is "maturing", which means no decision is made whether the feature will be included in a release, and the feature does not have to be ready for inclusion at that time. This gives interested parties time to test, suggest changes and form an opinion about the benefits of the feature without this blocking release.

Once there is consensus that a feature is beneficial, it needs to be prepared for generic inclusion. This means that while it retains experimental status, the feature is tested to not break any builds on known platforms, after which it can be matured into production code in a separate PR.

It is also possible that an experiment is abandoned instead of included in a release, for example when it lacks a maintainer or when another implementation is proposed for the same functionality that is more desirable.

Dogecoin Fee Recommendation

last updated for 1.14.6

The Dogecoin chain has a relatively low block interval, 1 megabyte blockspace and aims to provide a cheap means for people to transact. Therefore, the biggest threat to the Dogecoin chain as a whole is spam and in 2014, a transaction fee and dust disincentive were introduced, to combat on-chain spam.

Dogecoin Core implements a number of defaults into the software that reflect the developers' recommendations towards fees and dust limits, that at the moment of release represent the developers best estimate of how these limits should be parametrized. The recommended defaults, as implemented in the Dogecoin Core wallet, are:

• 0.01 DOGE per kilobyte transaction fee
• 0.01 DOGE dust limit (discard threshold)
• 0.001 DOGE replace-by-fee increments

The wallet rejects transactions that have outputs under the dust limit, and discards change to fee if it falls under this limit.

Note: In the past, Dogecoin has enforced a rounding function in the fee mechanism. Since version 1.14.5, this is no longer the case, and fees are calculated over the exact size of a transaction. For example, a 192 byte transaction only has to pay 0.01 / 1000 * 192 = 0.00192 DOGE fee.

Miner default inclusion policies

The default values for miners to include a transaction in a block has been set to exactly the recommended fee of 0.01 DOGE/kB. Dust limits are defined by the miner's mempool policy, see below.

Relay and mempool policies

The relay and mempool acceptance policies are lower than the recommendations by default, to allow for a margin to change recommendations in the future (or user preference) without the need for an adopted software release in advance. This greatly simplifies future policy recommendations. As historically, most relay nodes do not change these default settings, these often represent an absolute mininum

Transaction fee

The default minimum transaction fee for relay is set at 0.001 DOGE/kB, exactly one-tenth of the recommended fee. This gives miners and relay operators a 10x downward margin to operate within from a spam management perspective.

Dust limits

The mempool logic implements 2 dust limits, a hard dust limit under which a transactions is considered non-standard and rejected, and a soft dust limit that requires the limit itself to be added to the transaction fee, making the output economically unviable.

• The hard dust limit is set at 0.001 DOGE - outputs under this value are invalid and rejected.
• The soft dust limit is set at 0.01 DOGE - sending a transaction with outputs under this value, are required to add 0.01 DOGE for each such output, or else will be considered to have too low fee and be rejected.

Replace-by-fee and mempool limiting increments

The increments used for replace-by-fee and limiting the mempool once it has reached its locally defined maximum size, is by default set at one-tenth of the relay fee, or 0.0001 DOGE.

Dogecoin Core file system

Contents

• Data directory location
• Data directory layout
• GUI settings
• Legacy subdirectories and files
• Notes

Data directory location

The data directory is the default location where the Dogecoin Core files are stored.

1. The default data directory paths for supported platforms are:

2. A custom data directory path can be specified with the -datadir option.

3. All content of the data directory, except for the dogecoin.conf file, is chain-specific. This means the actual data directory paths for non-mainnet cases differ:

Data directory layout

GUI settings

dogecoin-qt uses the QSettings class; this implies platform-specific locations where application settings are stored.

Legacy subdirectories and files

These subdirectories and files are no longer used by Dogecoin Core:

Notes

1. The / (slash, U+002F) is used as the platform-independent path component separator in this document.

Fuzz-testing Dogecoin Core

A special test harness test_dogecoin_fuzzy is provided to provide an easy entry point for fuzzers and the like. In this document we'll describe how to use it with AFL.

Building AFL

It is recommended to always use the latest version of afl:

wget http://lcamtuf.coredump.cx/afl/releases/afl-latest.tgz
tar -zxvf afl-latest.tgz
cd afl-<version>
make
export AFLPATH=$PWD

Instrumentation

To build Dogecoin Core using AFL instrumentation (this assumes that the AFLPATH was set as above):

./configure --disable-ccache --disable-shared --enable-tests CC=${AFLPATH}/afl-gcc CXX=${AFLPATH}/afl-g++
export AFL_HARDEN=1
cd src/
make test/test_dogecoin_fuzzy

We disable ccache because we don't want to pollute the ccache with instrumented objects, and similarly don't want to use non-instrumented cached objects linked in.

Preparing fuzzing

AFL needs an input directory with examples, and an output directory where it will place examples that it found. These can be anywhere in the file system, we'll define environment variables to make it easy to reference them.

mkdir inputs
AFLIN=$PWD/inputs
mkdir outputs
AFLOUT=$PWD/outputs

Example inputs for Bitcoin Core are available from:

• https://download.visucore.com/bitcoin/bitcoin_fuzzy_in.tar.xz
• http://strateman.ninja/fuzzing.tar.xz

Extract these (or other starting inputs) into the inputs directory before starting fuzzing. These will need adapting to Dogecoin before use.

Fuzzing

To start the actual fuzzing use:

$AFLPATH/afl-fuzz -i ${AFLIN} -o ${AFLOUT} -m52 -- test/test_bitcoin_fuzzy

You may have to change a few kernel parameters to test optimally - afl-fuzz will print an error and suggestion if so.

Getting started

This tutorial will help you to go through the basics to use Dogecoin Core after you completed the installation instructions. You now have dogecoind or dogecoin-qt executables available to run a node, and dogecoin-cli/dogecoin-tx tools to help you transact DOGE.

Note: For simplicity, this guide assumes that executables can be found under the PATH environment variable. If needed, you can specify their location by typing PATH=$PATH:/path/to/executables, or prepend the full path to the command like:

shibetoshi:~$ /path/to/dogecoin-cli [arguments ...]

Table of contents

1. Starting a dogecoin node
2. Introduction to the JSON-RPC API
   • Creating a wallet
   • Verifying your balance
   • Sending transactions
   • Inspecting blocks and transactions
3. Node configuration
   • Mainnet, testnet and regtest
   • Data directory
   • RPC credentials
   • Ports
   • Memory
   • Troubleshooting

Starting a Dogecoin node

To start your node, you can run an headless server using dogecoind:

shibetoshi:~$ dogecoind -daemon

Or you can use the Graphical User Interface (GUI), dogecoin-qt:

shibetoshi:~$ dogecoin-qt

Detailed logging is recorded in debug.log, located in the data directory. Use -help to see all available options for each executable.

Your node is now running and starts with a synchronization process that downloads the entire blockchain from other nodes. This operation will take many hours to complete, but you are now part of the Dogecoin network!

Note: The rest of this guide assumes the use of an headless node. The RPC server is not exposed with dogecoin-qt until you activate the -server option as a startup argument, but inside the GUI application, you can use all the commands explored below (without dogecoin-cli) by going to Help -> Debug window and inside the popup window selecting the tab Console.

Introduction to the JSON-RPC API

Dogecoin Core exposes a JSON-RPC interface that allows you to request information about the network, blockchain and individual transactions, send transactions to the networks and manage your wallet.

The Dogecoin Core installation provides the dogecoin-cli tool to interact with the JSON-RPC from the command line, and the interface is exposed over HTTP on port 22555, so that other tools and libraries can interact with it.

To have an overview of the available commands, use the help command:

#List all commands
shibetoshi:~$ dogecoin-cli help

#Get help for a specific command
shibetoshi:~$ dogecoin-cli help COMMAND

Some commands are different, but it's possible to use the bitcoin RPC API documentation.

Creating a wallet

To receive DOGE, you need an address that is securely derived from a private key through a series of automatic, cryptographic operations. The address can be shared with anyone to receive DOGE, but the private key is sensitive information that allows anyone that knows it to spend the DOGE on the associated address.

By default, the Dogecoin Core software will automatically create an address for you and securely store the private key in the wallet file.

You can list wallet addresses using getaddressesbyaccount:

shibetoshi:~$ dogecoin-cli getaddressesbyaccount ""
[
  "DA2fBazU8Y4epNJ2fQRZCcWpxKZY9HrhLN"
]

Using getnewaddress will generate a new wallet address:

shibetoshi:~$ dogecoin-cli getnewaddress
DNnGtXk9khadE7EKCmQzxjnehenX92PKAv

Private keys are stored in the wallet.dat file. You can use backupwallet to save a copy:

shibetoshi:~$ dogecoin-cli backupwallet /path/of/wallet/backup

Tip: Dogecoin addresses start with the letter D.

You now have two wallet addresses to share with other people to receive DOGE! Consider avoiding address reuse for anonymity and security reasons.

Verifying your balance

The total balance of all addresses held in your wallet can be found with the getbalance command.

#Syntax
shibetoshi:~$ dogecoin-cli getbalance "*" minconf

minconf stands for minimum confirmations. For example, to see current balance with transaction having at least 5 confirmations:

shibetoshi:~$ dogecoin-cli getbalance "*" 5
421.552000

Sending transactions

Dogecoin implements the Unspent Transaction Output (UTXO) model to track which amounts of coin belong to an address. Owning DOGE means that you know the private key(s) to addresses that are associated with unspent outputs. To spend them, you have to compose a new transaction that spends the value from currently unspent outputs to new outputs.

sendtoaddress

It's possible to use a single command to create, sign and send a transaction :

#Syntax
shibetoshi:~$ dogecoin-cli sendtoaddress address amount

#Example
shibetoshi:~$ dogecoin-cli sendtoaddress nWSYUqtimF7B6qW4GBdczaG6jvqKutS1Nh 420

So much spending power !

Alternatively, four commands are needed to manually create a transaction: listunspent, createrawtransaction, signrawtransaction and sendrawtransaction.

listunspent

This displays a list of UTXOs associated to addresses kept in the wallet.

#Syntax
shibetoshi:~$ dogecoin-cli listunspent minconf maxconf '["address", ...]'

#Example
shibetoshi:~$ dogecoin-cli listunspent 1 9999999 '["nnJDY1xCRgWQc7vBXHUPMPsEynuZW23Y3P"]'
[
  {
    "txid": "b869ed6606d52e6446dc12db02cf868ab693dd5b9f661116269536f0f8fa2433",
    "vout": 0,
    "address": "nnJDY1xCRgWQc7vBXHUPMPsEynuZW23Y3P",
    "account": "",
    "scriptPubKey": "76a914c6977da37560e1432c2e14e16952981a4c272cac88ac",
    "amount": 100.00000000,
    "confirmations": 1355,
    "spendable": true,
    "solvable": true
  }
]

The minconf and maxconf parameters filter the minimum and maximum number of confirmations of the UTXO returned.

Note: The example address starts with n instead of D, because it uses testnet.

createrawtransaction

You can now build a new transaction using the available UTXOs from above.

#Syntax
shibetoshi:~$ utxos_to_use='
  [
    {
      "txid": "id",
      "vout": n
    },
    ...
  ]'
shibetoshi:~$ dogecoin-cli createrawtransaction "$utxos_to_use" '{"address":amount, ...}'

#Example
shibetoshi:~$ utxos_to_use='
[
  {
    "txid": "b869ed6606d52e6446dc12db02cf868ab693dd5b9f661116269536f0f8fa2433",
    "vout": 0
  }
]'
shibetoshi:~$ dogecoin-cli createrawtransaction "$utxos_to_use" '{"nWSYUqtimF7B6qW4GBdczaG6jvqKutS1Nh":69, "nnJDY1xCRgWQc7vBXHUPMPsEynuZW23Y3P": 30.999}'
01000000013324faf8f03695261611669f5bdd93b68a86cf02db12dc46642ed50666ed69b80000000000ffffffff0200a5459b010000001976a91418a89ee36293f15c4db4c01173babd579243161188ac60b8c4b8000000001976a914c6977da37560e1432c2e14e16952981a4c272cac88ac00000000

You can combine multiple UTXO and send it to multiple recipients by extending the utxos_to_use and recipient JSON structures.

Tip: The transaction returned is encoded in hexadecimal encoding. You can use dogecoin-cli decoderawtransaction or dogecoin-tx -json to convert the content to JSON format.

signrawtransaction

Before sending a transaction, it must be signed by the private key that the address was derived from. Dogecoin Core will automatically use the correct private key when spending UTXO known to the wallet.

#Syntax
shibetoshi:~$ dogecoin-cli signrawtransaction encoded_transaction

#Example
shibetoshi:~$ dogecoin-cli signrawtransaction "01000000013324faf8f03695261611669f5bdd93b68a86cf02db12dc46642ed50666ed69b80000000000ffffffff0200a5459b010000001976a91418a89ee36293f15c4db4c01173babd579243161188ac60b8c4b8000000001976a914c6977da37560e1432c2e14e16952981a4c272cac88ac00000000"
{
  "hex": "01000000013324faf8f03695261611669f5bdd93b68a86cf02db12dc46642ed50666ed69b8000000006a47304402200e1bf722d4335179de170f7c762755b463b3f7b8f026f30950f701bc834f0e6e022036295fdd5e607ca41c4e0e62e59d0911b607bfabedde2424665ffae13564d0e001210388f8f226d12eccd3ba93c1454ec4498b065cea96e29b918fbdb517872ebbf581ffffffff0200a5459b010000001976a91418a89ee36293f15c4db4c01173babd579243161188ac60b8c4b8000000001976a914c6977da37560e1432c2e14e16952981a4c272cac88ac00000000",
  "complete": true
}

sendrawtransaction

Finally, broadcast the transaction to the network so that it can be included in a block by miners:

#Syntax
shibetoshi:~$ dogecoin-cli sendrawtransaction signed_transaction

#Example
shibetoshi:~$ dogecoin-cli sendrawtransaction 01000000013324faf8f03695261611669f5bdd93b68a86cf02db12dc46642ed50666ed69b8000000006a47304402200e1bf722d4335179de170f7c762755b463b3f7b8f026f30950f701bc834f0e6e022036295fdd5e607ca41c4e0e62e59d0911b607bfabedde2424665ffae13564d0e001210388f8f226d12eccd3ba93c1454ec4498b065cea96e29b918fbdb517872ebbf581ffffffff0200a5459b010000001976a91418a89ee36293f15c4db4c01173babd579243161188ac60b8c4b8000000001976a914c6977da37560e1432c2e14e16952981a4c272cac88ac00000000
b4fae2a43cb35f8016a547e9658e061f1da4a043efafecc42f739d46d95dee21

Inspecting blocks and transactions

Blocks and transactions are identified by unique hashes. Let's find the coinbase transaction of block 69.

Note: To be able to query transactions not related to your own wallet, like in this example, you will need to enable the -txindex option. This options requires the Dogecoin Core software to re-index the entire blockchain, and can take up to several hours.

First, request the information about block 69:

#Find block hash from his height
shibetoshi:~$ dogecoin-cli getblockhash 69
3d2def20cd0d3aca148741ef469bda11647a3040d7669c82745d03c728706a8b

#Get block data
shibetoshi:~$ dogecoin-cli getblock 3d2def20cd0d3aca148741ef469bda11647a3040d7669c82745d03c728706a8b
{
  "hash": "3d2def20cd0d3aca148741ef469bda11647a3040d7669c82745d03c728706a8b",
  "confirmations": 7816,
  "strippedsize": 190,
  "size": 190,
  "weight": 760,
  "height": 69,
  "version": 1,
  "versionHex": "00000001",
  "merkleroot": "695ce4208fa7a87ef9e99805b0910dc129058ecdceb5cef7e25f71dcdc7936db",
  "tx": [
    "695ce4208fa7a87ef9e99805b0910dc129058ecdceb5cef7e25f71dcdc7936db"
  ],
  "time": 1386475225,
  "mediantime": 1386475209,
  "nonce": 3923708672,
  "bits": "1e0ffff0",
  "difficulty": 0.000244140625,
  "chainwork": "0000000000000000000000000000000000000000000000000000000004600460",
  "previousblockhash": "ffa69e04f928b84f19d84da25fb544340e54dca6c03c33930da245719e61c5ea",
  "nextblockhash": "44bf8abbbb96d4dcfb95df563e606c37987133ea3e013b23bbddde8d7f905fdd"
}

The tx field contains a list of all transactions included in this block. Only one transaction exist in block 69, the coinbase transaction.

We can see the entire transaction by querying for its identifier:

#Syntax
shibetoshi:~$ dogecoin-cli getrawtransaction txid verbose

#Example
shibetoshi:~$ dogecoin-cli getrawtransaction 695ce4208fa7a87ef9e99805b0910dc129058ecdceb5cef7e25f71dcdc7936db 1
{
  "hex": "01000000010000000000000000000000000000000000000000000000000000000000000000ffffffff0e04d9eea3520101062f503253482fffffffff0100ac6156be23000023210340a42a5ad6c4c0cd5ae539657032e0a359bd3e0f95771f34d71691b13460a624ac00000000",
  "txid": "695ce4208fa7a87ef9e99805b0910dc129058ecdceb5cef7e25f71dcdc7936db",
  "hash": "695ce4208fa7a87ef9e99805b0910dc129058ecdceb5cef7e25f71dcdc7936db",
  "size": 109,
  "vsize": 109,
  "version": 1,
  "locktime": 0,
  "vin": [
    {
      "coinbase": "04d9eea3520101062f503253482f",
      "sequence": 4294967295
    }
  ],
  "vout": [
    {
      "value": 393004.00000000,
      "n": 0,
      "scriptPubKey": {
        "asm": "0340a42a5ad6c4c0cd5ae539657032e0a359bd3e0f95771f34d71691b13460a624 OP_CHECKSIG",
        "hex": "210340a42a5ad6c4c0cd5ae539657032e0a359bd3e0f95771f34d71691b13460a624ac",
        "reqSigs": 1,
        "type": "pubkey",
        "addresses": [
          "D5TjotnkoXekNQBCn54CBWxjEzCJMMe7WS"
        ]
      }
    }
  ],
  "blockhash": "3d2def20cd0d3aca148741ef469bda11647a3040d7669c82745d03c728706a8b",
  "confirmations": 3964556,
  "time": 1386475225,
  "blocktime": 1386475225
}

The vout structure will give you information about where the transaction output.

Node configuration

There are many parameters that can be configured to tune your node to your liking. There are two ways to change the configuration.

Using dogecoind -help will display all available configuration parameters that can be added as arguments:

Command example :

shibetoshi:~$ dogecoind -daemon -paytxfee=0.01 -sendfreetransactions=1 -maxconnections=150

Configuration can be persisted by creating a dogecoin.conf file. Create it in the directory defined with the datadir setting, $HOME/.dogecoin by default, or specify the file location with -conf.

dogecoin.conf example :

daemon=1
server=1
listen=1
paytxfee=0.01
sendfreetransactions=1
maxconnections=150

You can see a more concrete example here.

Mainnet, testnet and regtest

When trying out new things, for example to test your application that interacts with the Dogecoin chain, it is recommended to not use the main Dogecoin network. Multiple networks are built-in for this purpose.

Mainnet : The main network where real transaction operate.
Testnet : The test network, with peers.
Regtest : The regression test network, to test with only local peers and create blocks on-demand.

When not specifying any network, Mainnet is the network used by default. To enable testnet, use the dogecoind -testnet.

To enable regtest, use the -regtest option.

Tip: Remember to specify the network when you want to use dogecoin-cli.

Data directory

The data directory is the location where Dogecoin Core files are stored, including the wallet, log files and blocks. You can modify the location with the -datadir setting.

Default location :

You may need to specify -datadir also when using dogecoin-cli.

See the full documentation on file system for more information.

RPC credentials

Authentication is required to interact with the RPC interface. When no credentials are provided, Dogecoin uses a random cookie that gets generated when the software is launched. It's possible to define your own credentials using rpcuser and rpcpassword parameters.

Ports

A node can expose 2 different ports: one port for the Peer to Peer Network (P2P) to communicate with other nodes, and a second port for access to the RPC API. By default, the ports are configured as follows:

To configure them use the -port and -rpcport parameters.

Memory

Running Dogecoin Core can require a lot of memory, so in some situations it may be necessary to optimize its usage. You can find more information about reducing the memory footprint in the related guide.

Troubleshooting

By default, Dogecoin Core keeps detailed logs in the debug.log file, located in the datadir. Alternatively, the -printtoconsole parameter displays the log interactively to the terminal instead.

To get more verbose log output, you can enable debug mode by using the -debug=<topic> parameter to increase logic for a specific topic, or use -debug=all to see detailed logs on all topics.

Gitian building

Gitian is a secure source-control oriented software distribution method. This means you can download trusted binaries that are verified by multiple builders.
Source : Gitian.org

Gitian is a deterministic build process that is used to release Dogecoin Core executables. It uses a virtualized environment and a predetermined set of dependencies and system libraries to build binaries. This lets many independent builders compare and publish their results before releasing executables, allowing for an end-to-end auditable release that can be verified by anyone.

To reduce the probability of compromised releases, more independent gitian builders are needed!

Anyone can participate and help to increase the security of Dogecoin Core releases by following this guide.

Table of contents

1. Installing dependencies
   • Common dependencies
   • Docker
   • LXC
   • KVM
2. Usage
   • Syntax
   • Example
   • Signing externally
3. Publishing signatures

Installing dependencies

To perform a gitian build, you can use different virtualization software : Docker, KVM or LXC. Dependencies will change according to your choice.

You need to install some required dependencies whatever you will choose.

Use your packet manager to install them : apt, brew, dnf, pacman...

Common dependencies

The following common dependencies are required regardless of virtualization:

git ruby wget apt-cacher-ng gpg

Note: When asked to allow secure tunnels through apt-cacher, answer "no"

After installation, you will need to enable apt-cacher, eg:

sudo systemctl enable apt-cacher-ng.service
sudo systemctl start apt-cacher-ng.service

You can define your apt-cacher host by specifying MIRROR_HOST environment variable.

To create a PGP key to sign files, see : https://gnupg.org/gph/en/manual.html#INTRO.
You will need to specify your user ID, find it using gpg -k.

Docker

Please refer to the official Docker documentation to install it for your operating system.

Make sure your user can run the docker command without root privilege by being in the docker group:

sudo usermod -aG docker $(whoami)

#Enable group without logging out
newgrp docker

You can now use the --docker option with gitian-build.sh in the Usage section of this guide.

LXC

Install the following package :

lxc

Then use --lxc option with gitian-build.sh.

KVM

[Documentation not available, help is welcome]

Usage

gitian-build.sh is a standalone script, it can be downloaded and run outside of Dogecoin Core repository.

It can download dependency files for the Gitian, build and optionally sign binaries, or verify signatures.

Binaries and signatures will be created in a gitian-output folder, relative to where the gitian-build.sh script is ran.

Syntax

./gitian-build.sh [options] version

#See help menu for available options
./gitian-build.sh --help

Example

The entire gitian flow can be performed step by step, example using docker :

#Download Gitian dependencies
./gitian-build.sh --docker --setup 1.14.5

#Build & sign executables
./gitian-build.sh --docker --build --sign SIGNER 1.14.5

#Verify signatures
./gitian-build.sh --verify 1.14.5

Or to do everything at once :

./gitian-build.sh --docker --setup --build --sign SIGNER --verify 1.14.5

Signing externally

If you want to do the PGP signing on another device, that's also possible; just define SIGNER as mentioned and follow the steps in the build process as normal.

gpg: skipped "shibetoshi": secret key not available

When you execute gsign you will get an error from GPG, which can be ignored. Copy the resulting .assert files in gitian.sigs to your signing machine and do

gpg --detach-sign ${VERSION}-linux/${SIGNER}/dogecoin-linux-build.assert
gpg --detach-sign ${VERSION}-win/${SIGNER}/dogecoin-win-build.assert
gpg --detach-sign ${VERSION}-osx-unsigned/${SIGNER}/dogecoin-osx-build.assert

This will create the .sig files that can be committed together with the .assert files to assert your Gitian build.

Publish signatures

Gitian signatures for each release are added to https://github.com/dogecoin/gitian.sigs.

gitian-build.sh will create signatures inside gitian-output/sigs/ folder. Create a pull request to dogecoin/gitian.sigs to publish your signatures, the .assert and .assert.sig files.

When your PR is merged, you will be recorded for all future history as a Gitian Builder of Dogecoin Core!

Sample init scripts and service configuration for dogecoind

Sample scripts and configuration files for systemd, Upstart and OpenRC can be found in the contrib/init folder.

contrib/init/dogecoind.service:    systemd service unit configuration
contrib/init/dogecoind.openrc:     OpenRC compatible SysV style init script
contrib/init/dogecoind.openrcconf: OpenRC conf.d file
contrib/init/dogecoind.conf:       Upstart service configuration file
contrib/init/dogecoind.init:       CentOS compatible SysV style init script

1. Service User

All three Linux startup configurations assume the existence of a "dogecoin" user and group. They must be created before attempting to use these scripts. The OS X configuration assumes dogecoind will be set up for the current user.

2. Configuration

At a bare minimum, dogecoind requires that the rpcpassword setting be set when running as a daemon. If the configuration file does not exist or this setting is not set, dogecoind will shutdown promptly after startup.

This password does not have to be remembered or typed as it is mostly used as a fixed token that dogecoind and client programs read from the configuration file, however it is recommended that a strong and secure password be used as this password is security critical to securing the wallet should the wallet be enabled.

If dogecoind is run with the "-server" flag (set by default), and no rpcpassword is set, it will use a special cookie file for authentication. The cookie is generated with random content when the daemon starts, and deleted when it exits. Read access to this file controls who can access it through RPC.

By default the cookie is stored in the data directory, but it's location can be overridden with the option '-rpccookiefile'.

This allows for running dogecoind without having to do any manual configuration.

conf, pid, and wallet accept relative paths which are interpreted as relative to the data directory. wallet only supports relative paths.

For an example configuration file that describes the configuration settings, see contrib/debian/examples/dogecoin.conf.

3. Paths

3a) Linux

All three configurations assume several paths that might need to be adjusted.

Binary: /usr/bin/dogecoind
Configuration file: /etc/dogecoin/dogecoin.conf
Data directory: /var/lib/dogecoind
PID file: /var/run/dogecoind/dogecoind.pid (OpenRC and Upstart) or /var/lib/dogecoind/dogecoind.pid (systemd)
Lock file: /var/lock/subsys/dogecoind (CentOS)

The configuration file, PID directory (if applicable) and data directory should all be owned by the dogecoin user and group. It is advised for security reasons to make the configuration file and data directory only readable by the dogecoin user and group. Access to dogecoin-cli and other dogecoind rpc clients can then be controlled by group membership.

3b) Mac OS X

Binary: /usr/local/bin/dogecoind
Configuration file: ~/Library/Application Support/Dogecoin/dogecoin.conf
Data directory: ~/Library/Application Support/Dogecoin Lock file: ~/Library/Application Support/Dogecoin/.lock

4. Installing Service Configuration

4a) systemd

Installing this .service file consists of just copying it to /usr/lib/systemd/system directory, followed by the command systemctl daemon-reload in order to update running systemd configuration.

To test, run systemctl start dogecoind and to enable for system startup run systemctl enable dogecoind

4b) OpenRC

Rename dogecoind.openrc to dogecoind and drop it in /etc/init.d. Double check ownership and permissions and make it executable. Test it with /etc/init.d/dogecoind start and configure it to run on startup with rc-update add dogecoind

4c) Upstart (for Debian/Ubuntu based distributions)

Drop dogecoind.conf in /etc/init. Test by running service dogecoind start it will automatically start on reboot.

NOTE: This script is incompatible with CentOS 5 and Amazon Linux 2014 as they use old versions of Upstart and do not supply the start-stop-daemon utility.

4d) CentOS

Copy dogecoind.init to /etc/init.d/dogecoind. Test by running service dogecoind start.

Using this script, you can adjust the path and flags to the dogecoind program by setting the DOGECOIND and FLAGS environment variables in the file /etc/sysconfig/dogecoind. You can also use the DAEMONOPTS environment variable here.

4e) Mac OS X

Copy org.dogecoin.dogecoind.plist into ~/Library/LaunchAgents. Load the launch agent by running launchctl load ~/Library/LaunchAgents/org.dogecoin.dogecoind.plist.

This Launch Agent will cause dogecoind to start whenever the user logs in.

NOTE: This approach is intended for those wanting to run dogecoind as the current user. You will need to modify org.dogecoin.dogecoind.plist if you intend to use it as a Launch Daemon with a dedicated dogecoin user.

5. Auto-respawn

Auto respawning is currently only configured for Upstart and systemd. Reasonable defaults have been chosen but YMMV.

Reduce Memory

There are a few parameters that can be dialed down to reduce the memory usage of dogecoind. This can be useful on embedded systems or small VPSes.

In-memory caches

The size of some in-memory caches can be reduced. As caches trade off memory usage for performance, reducing these will usually have a negative effect on performance.

• -dbcache=<n> - the UTXO database cache size, this defaults to 450. The unit is MiB (1024).
  • The minimum value for -dbcache is 4.
  • A lower -dbcache makes initial sync time much longer. After the initial sync, the effect is less pronounced for most use-cases, unless fast validation of blocks is important, such as for mining.

Memory pool

• In Dogecoin Core there is a memory pool limiter which can be configured with -maxmempool=<n>, where <n> is the size in MB (1000). The default value is 300.

  • The minimum value for -maxmempool is 5.
  • A lower maximum mempool size means that transactions will be evicted sooner. This will affect any uses of dogecoind that process unconfirmed transactions.

• To completely disable mempool functionality there is the option -blocksonly. This will make the client opt out of receiving (and thus relaying) transactions completely, except as part of blocks.

  • Do not use this when using the client to broadcast transactions as any transaction sent will stick out like a sore thumb, affecting privacy. When used with the wallet it should be combined with -walletbroadcast=0 and -spendzeroconfchange=0. Another mechanism for broadcasting outgoing transactions (if any) should be used.

• Since 1.14.0, unused memory allocated to the mempool (default: 300MB) is shared with the UTXO cache, so when trying to reduce memory usage you should limit the mempool, with the -maxmempool command line argument.

Number of peers

• -maxconnections=<n> - the maximum number of connections, this defaults to 125. Each active connection takes up some memory. This option applies only if incoming connections are enabled, otherwise the number of connections will never be more than 10. Of the 10 outbound peers, there can be 8 full-relay connections and 2 block-relay-only ones.

Thread configuration

For each thread a thread stack needs to be allocated. By default on Linux, threads take up 8MiB for the thread stack on a 64-bit system, and 4MiB in a 32-bit system.

• -par=<n> - the number of script verification threads, defaults to the number of cores in the system minus one.
• -rpcthreads=<n> - the number of threads used for processing RPC requests, defaults to 4.

Linux specific

By default, since glibc 2.10, the C library will create up to two heap arenas per core. This is known to cause excessive memory usage in some scenarios. To avoid this make a script that sets MALLOC_ARENA_MAX before starting dogecoind:

#!/usr/bin/env bash
export MALLOC_ARENA_MAX=1
dogecoind

The behavior was introduced to increase CPU locality of allocated memory and performance with concurrent allocation, so this setting could in theory reduce performance. However, in Dogecoin Core very little parallel allocation happens, so the impact is expected to be small or absent.

Reduce Traffic

Some node operators need to deal with bandwidth caps imposed by their ISPs.

By default, dogecoin-core allows up to 125 connections to different peers, 8 of which are outbound. You can therefore, have at most 117 inbound connections.

The default settings can result in relatively significant traffic consumption.

Ways to reduce traffic:

1. Use -maxuploadtarget=<MiB per day>

A major component of the traffic is caused by serving historic blocks to other nodes during the initial blocks download phase (syncing up a new node). This option can be specified in MiB per day and is turned off by default. This is not a hard limit; only a threshold to minimize the outbound traffic. When the limit is about to be reached, the uploaded data is cut by no longer serving historic blocks (blocks older than one week). Keep in mind that new nodes require other nodes that are willing to serve historic blocks.

Whitelisted peers will never be disconnected, although their traffic counts for calculating the target.

2. Disable "listening" (-listen=0)

Disabling listening will result in fewer nodes connected (remember the maximum of 8 outbound peers). Fewer nodes will result in less traffic usage as you are relaying blocks and transactions to fewer nodes.

3. Reduce maximum connections (-maxconnections=<num>)

Reducing the maximum connected nodes to a minimum could be desirable if traffic limits are tiny. Keep in mind that Dogecoin's trustless model works best if you are connected to a handful of nodes.

Dogecoin Core version 1.14.6 is now available from:

https://github.com/dogecoin/dogecoin/releases/tag/v1.14.6/

This is a new minor version release, including important security updates and changes to network efficiency. All Dogecoin Core users - miners, services, relay operators and wallet users - are strongly recommended to upgrade.

Please report bugs using the issue tracker at github:

https://github.com/dogecoin/dogecoin/issues

To receive notifications about updates, subscribe to the release mailing list:

https://sourceforge.net/projects/dogecoin/lists/dogecoin-releases

Releases are also announced on reddit:

https://www.reddit.com/r/dogecoindev/

Compatibility

Dogecoin Core is extensively tested on Ubuntu Server LTS, Intel-based macOS and Windows 10.

Dogecoin Core should also work on most other Unix-like systems but is not frequently tested on them.

Notable changes

Important Security Updates

This release contains fixes that harden node and network security. These fixes are important for every node operator and wallet user.

Alert system removal

The P2P alert system has been removed and alert messages are no longer processed. This was planned for the next major release, but as bugs were found in the implementation, the full deprecation of this feature has been executed early, because it makes no sense to overhaul a system that is unused and already marked for removal in the near future.

Harden the transaction download mechanism

Significantly reduce the impact of peers that withhold transaction information (accidentally or otherwise) in the announcement stage, before the transaction is mined, by enforcing strict controls, limits and timeouts on all transaction announcements and giving preference to outgoing connections when deciding which peer to request transaction information from.

This improves the resilience of the entire network and improves reliability of transaction relay throughout.

Other security-related fixes

• Harden the protocol implementation to reject buggy or malformed messages. This helps protect the network against broken custom clients.
• Limit and tightly manage memory usage in events of high network traffic or when connected to extremely slow peers. This protects nodes on lower end hardware to not run out of memory in the face of increased network activity.

Fee Recommendation

This release changes the recommended dust limit for all participants on the Dogecoin network from 1 DOGE to 0.01 DOGE. The full recommendation can be found in the documentation.

This change has been implemented in the wallet as the default value of -discardthreshold, resulting in the following default logic:

1. The wallet will attempt to not create any outputs smaller than 0.03 DOGE as change if possible.
2. If after signing there is more than 0.01 DOGE left in the change output, the wallet will keep the output as-is.
3. If the change output drops under 0.01 DOGE, the wallet will discard the change and instead give it to miners as fee.
4. Any output under 0.01 DOGE will not be accepted as valid by default.

Breaking changes

Configuration of a wallet backup directory

Adds a new command line parameter -backupdir that allows operators to specify where to store wallet backups and dumps. When not set, the node will add a directory under the data directory called "backups".

This is a breaking change.

The behavior of the dumpwallet and backupwallet RPC methods has changed, as these will ignore any path given other than the filename, and will always store the filename in the directory defined with -backupdir or the above-mentioned default location.

These methods will also refuse to overwrite any existing files and will produce error messages to that effect.

Maximum number of addnode records

To protect against users accidentally submitting an insane amount of address records using the addnode RPC call, the maximum number of "addnode" records has been limited to 800, which is 100x the maximum number of manually added nodes that the software connects to (8).

Once this maximum is reached, the software will refuse to add any more addresses and return an error.

Users can remove existing addnode records from the software by running:

dogecoin-cli addnode <address> remove

Features

Improve stuck transaction detection

A new RPC method has been added to help wallet operators identify if any transactions are stuck (have not been mined and are not in the mempool) and enable resolution. This helps in cases where node-local fee or dust policies change, to prevent the node from sending out old transactions that got lost.

The method can be called with:

dogecoin-cli liststucktransactions

Add pruning configuration to the UI

Adds pruning configuration to the UI, to make it easier to save diskspace for users of graphical (wallet) installations. Before, this could only be done through manual editing of the configuration file.

The new setting allows a user to decrease the total disk space used for keeping full blocks the node down to 3GB, by removing blocks that are no longer needed for full incremental validation of the blockchain.

Caveats

Note that when running a pruned node, the following applies:

• The node will no longer relay blocks and transactions.
• If the node needs to recover after a hardware failure, it might need to re-download the entire chain.
• Features that need the entire block chain, such as rescanning the chain for wallet transactions, or importing old keys, will not function.
• Reverting this setting will make the node re-download the entire chain.

Manage the number of connections without restart

A new RPC method setmaxconnections has been introduced that enables wallet and node operators to change the maximum number of connections their node allows without needing to restart (and with that, lose all connections) allowing for more fine-grained control of the node's network capacities.

The node will allow reducing the number of connections until a minimum of 28, and will automatically adapt to a maximum that the host OS allows.

To change the maximum number of connections, run:

dogecoin-cli setmaxconnections <desired_amount>

Improve the traffic graph in the UI

Significantly improves the graph in the UI's traffic monitor by not throwing away data every time the graph scale got resampled, but instead keeping track of the traffic we see in the background and then rendering it on demand.

Add a rescan RPC method

A new RPC method, rescan, has been added to allow node operators to rescan the chain for wallet transactions from a certain height. This can help speed up the rescan process for keys that are known to be generated after a certain date or block height, as older blocks do not necessarily require to be scanned in that scenario. This may also be helpful when adding large quantities of watchonly addresses.

NOTE: rescanning the blockchain takes a lot of time.

To use the rescan functionality, use:

dogecoin-cli rescan <start_block>

It will inform of the state before and after when the process finishes:

{
  "before": {
    "balance": 69.00000000,
    "txcount": 1
  },
  "after": {
    "balance": 420.00000000,
    "txcount": 3
  },
  "blocks_scanned": 31337,
  "time_elapsed": 23
}

New REST endpoint: blockhashbyheight

A new endpoint has been added to the REST server to find the current best known block at a certain height, without having to do RPC calls. This is useful for service implementations that need to track or query blocks.

The new endpoint can be queried with:

GET /rest/blockhashbyheight/<height>

Translation Updates

Significant updates have been provided to the following languages:

• Bulgarian
• Dutch
• French
• Italian
• Korean
• Persian
• Portuguese (pt_PT)
• Tamil

Policies and tooling have been updated to enable translators better in their efforts to make Dogecoin more accessible to people that do not speak English.

RPC API Changes

• The verifychain RPC command no longer accepts negative values
• Added liststucktransactions
• Added setmaxconnections
• Added rescan
• addnode will now return error -32 when the address provided is too long
• getpeerinfo provides 2 new fields per peer, addr_processed and addr_rate_limited, that track addr message processing
• dumpwallet and backupwallet now write their output to the configurable backup directory and do not overwrite existing files

Dependency Updates

• Updated the default dependency zlib to 1.2.12.
• Updated the default dependency libevent to 2.1.12-stable.
• Update the LevelDB subtree to use the same version as Bitcoin 22.0, from the bitcoin-core maintained fork.

Minor Changes

• Added ARMv8 and ARMv82 crypto extensions as an experimental feature. This significantly improves the speed at which 64-bit ARM hardware can validate blocks and transactions.
• Fixed the graphical wallet to properly display in High-DPI resolutions.
• Improved privacy by preventing leaks of information about our wallet when setting the locktime field (automatically.)
• Added scrypt to the benchmark code.
• Change the granularity of data downloaded in the network tab to no longer display gigabytes and terrabytes, as this obscures too much detail. Instead, the largest unit is now megabytes.
• Fixed a bug in the getutxos REST endpoint to also show data when not including the mempool.
• Improved the tips displayed in the UI to be more concise and give better advice.
• Removed information from the graphical wallet that was attempting to indicate stuck transactions based on peer-to-peer traffic, but this does not work since 1.14.2, and can be misleading (showing false positives and negatives.)
• Improved and updated the bip list documentation that explains the protocol features implemented by Dogecoin Core.
• Greatly improved the gitian-build script to ease doing deterministic builds for everyone, and the documentation of that process.

Credits

Credit goes to all awesome contributors to this release, alphabetically:

• AbcSxyZ
• alamshafil
• Ayushman Singh Chauhan
• Bhaskar Kashyap
• ch0k1
• Chao Liu
• chromatic
• Chuanyi
• Chun Kuan Lee
• Dakoda Greaves
• DogecoinItalia
• dogespacewizard
• Ed Tubbs
• Evan Klitzke
• fanquake
• fdov
• Gregory Maxwell
• Hennadii Stepanov
• huedaya
• iamagf
• inevitable360
• Jade Hamel
• Jadi
• Jeremy Rubin
• Jimkov
• just-an-dev
• justAndrea1111
• katesalazar
• Kaz Wesley
• MVShishkov
• Maniixer
• MarcoFalke
• Martyornot
• Matheus Bach
• Matt Corallo
• Micael Malta
• Michi Lumin
• Misha Behersky
• MishaBoar
• Mohammad Ali Haghshenas
• Motahhar Mokf
• Patrick Lodder
• Pieter Wuille
• practicalswift
• RnoHach
• Roman Zeyde
• Russell Yanofsky
• scarletletters
• sinetek
• Staartvos
• Steve Chung
• thisiskeanyvy
• vertiond
• VJ
• Wladimir J. van der Laan
• ZeeAmini

Release Process

Before every release candidate:

• Update translations (ping wumpus on IRC) see translation_process.md.

• Update manpages, see gen-manpages.sh.

Before every minor and major release:

• Update bips.md to account for changes since the last release.
• Update version in sources (see below)
• Write release notes (see below)
• Update src/chainparams.cpp nMinimumChainWork with information from the getblockchaininfo rpc.
• Update src/chainparams.cpp defaultAssumeValid with information from the getblockhash rpc.
  • The selected value must not be orphaned so it may be useful to set the value two blocks back from the tip.
  • Testnet should be set some tens of thousands back from the tip due to reorgs there.
  • This update should be reviewed with a reindex-chainstate with assumevalid=0 to catch any defect that causes rejection of blocks in the past history.

Before every major release:

• Update hardcoded seeds, see this pull request for an example.
• Update BLOCK_CHAIN_SIZE to the current size plus some overhead.

First time / New builders

If you're using the automated script (found in contrib/gitian-build.sh), then at this point you should run it with the "--setup" command. Otherwise ignore this.

Check out the source code in the following directory hierarchy.

cd /path/to/your/toplevel/build
git clone https://github.com/dogecoin-core/gitian.sigs.git
git clone https://github.com/dogecoin-core/dogecoin-detached-sigs.git
git clone https://github.com/devrandom/gitian-builder.git
git clone https://github.com/dogecoin/dogecoin.git

Dogecoin maintainers/release engineers, update version in sources

Update the following:

• configure.ac:
  • _CLIENT_VERSION_MAJOR
  • _CLIENT_VERSION_MINOR
  • _CLIENT_VERSION_REVISION
  • _CURRENT_RELEASE_DATE
  • _EXPECTED_DAYS_TO_NEXT_RELEASE if necessary
  • Don't forget to set _CLIENT_VERSION_IS_RELEASE to true
• src/clientversion.h: (this mirrors configure.ac - see issue #3539)
  • CLIENT_VERSION_MAJOR
  • CLIENT_VERSION_MINOR
  • CLIENT_VERSION_REVISION
  • Don't forget to set CLIENT_VERSION_IS_RELEASE to true
• doc/README.md and doc/README_windows.txt
• doc/Doxyfile: PROJECT_NUMBER contains the full version
• contrib/gitian-descriptors/*.yml: usually one'd want to do this on master after branching off the release - but be sure to at least do it before a new major release

Write release notes. git shortlog helps a lot, for example:

git shortlog --no-merges v(current version, e.g. 0.7.2)..v(new version, e.g. 0.8.0)

(or ping @wumpus on IRC, he has specific tooling to generate the list of merged pulls and sort them into categories based on labels)

Generate list of authors:

git log --format='%aN' "$*" | sort -ui | sed -e 's/^/- /'

Tag version (or release candidate) in git

git tag -s v(new version, e.g. 0.8.0)

Setup and perform Gitian builds

If you're using the automated script (found in contrib/gitian-build.sh), then at this point you should run it with the "--build" command. Otherwise ignore this.

Setup Gitian descriptors:

pushd ./dogecoin
export SIGNER=(your Gitian key, ie bluematt, sipa, etc)
export VERSION=(new version, e.g. 0.8.0)
git fetch
git checkout v${VERSION}
popd

Ensure your gitian.sigs are up-to-date if you wish to gverify your builds against other Gitian signatures.

pushd ./gitian.sigs
git pull
popd

Ensure gitian-builder is up-to-date:

pushd ./gitian-builder
git pull
popd

Fetch and create inputs: (first time, or when dependency versions change)

pushd ./gitian-builder
mkdir -p inputs
wget -P inputs https://bitcoincore.org/cfields/osslsigncode-Backports-to-1.7.1.patch
wget -P inputs https://launchpad.net/ubuntu/+archive/primary/+sourcefiles/osslsigncode/1.7.1-1/osslsigncode_1.7.1.orig.tar.gz
popd

Create the OS X SDK tarball, see the OS X readme for details, and copy it into the inputs directory.

Optional: Seed the Gitian sources cache and offline git repositories

By default, Gitian will fetch source files as needed. To cache them ahead of time:

pushd ./gitian-builder
make -C ../dogecoin/depends download SOURCES_PATH=`pwd`/cache/common
popd

Only missing files will be fetched, so this is safe to re-run for each build.

NOTE: Offline builds must use the --url flag to ensure Gitian fetches only from local URLs. For example:

pushd ./gitian-builder
./bin/gbuild --url dogecoin=/path/to/dogecoin,signature=/path/to/sigs {rest of arguments}
popd

The gbuild invocations below DO NOT DO THIS by default.

Build and sign Dogecoin Core for Linux, Windows, and OS X:

pushd ./gitian-builder
./bin/gbuild --memory 3000 --commit dogecoin=v${VERSION} ../dogecoin/contrib/gitian-descriptors/gitian-linux.yml
./bin/gsign --signer $SIGNER --release ${VERSION}-linux --destination ../gitian.sigs/ ../dogecoin/contrib/gitian-descriptors/gitian-linux.yml
mv build/out/dogecoin-*.tar.gz build/out/src/dogecoin-*.tar.gz ../

./bin/gbuild --memory 3000 --commit dogecoin=v${VERSION} ../dogecoin/contrib/gitian-descriptors/gitian-win.yml
./bin/gsign --signer $SIGNER --release ${VERSION}-win-unsigned --destination ../gitian.sigs/ ../dogecoin/contrib/gitian-descriptors/gitian-win.yml
mv build/out/dogecoin-*-win-unsigned.tar.gz inputs/dogecoin-win-unsigned.tar.gz
mv build/out/dogecoin-*.zip build/out/dogecoin-*.exe ../

./bin/gbuild --memory 3000 --commit dogecoin=v${VERSION} ../dogecoin/contrib/gitian-descriptors/gitian-osx.yml
./bin/gsign --signer $SIGNER --release ${VERSION}-osx-unsigned --destination ../gitian.sigs/ ../dogecoin/contrib/gitian-descriptors/gitian-osx.yml
mv build/out/dogecoin-*-osx-unsigned.tar.gz inputs/dogecoin-osx-unsigned.tar.gz
mv build/out/dogecoin-*.tar.gz build/out/dogecoin-*.dmg ../
popd

Build output expected:

1. source tarball (dogecoin-${VERSION}.tar.gz)
2. linux 32-bit and 64-bit dist tarballs (dogecoin-${VERSION}-linux[32|64].tar.gz)
3. windows 32-bit and 64-bit unsigned installers and dist zips (dogecoin-${VERSION}-win[32|64]-setup-unsigned.exe, dogecoin-${VERSION}-win[32|64].zip)
4. OS X unsigned installer and dist tarball (dogecoin-${VERSION}-osx-unsigned.dmg, dogecoin-${VERSION}-osx64.tar.gz)
5. Gitian signatures (in gitian.sigs/${VERSION}-<linux|{win,osx}-unsigned>/(your Gitian key)/)

Verify other gitian builders signatures to your own. (Optional)

Add other gitian builders keys to your gpg keyring, and/or refresh keys.

gpg --import dogecoin/contrib/gitian-keys/*.pgp
gpg --refresh-keys

Verify the signatures

pushd ./gitian-builder
./bin/gverify -v -d ../gitian.sigs/ -r ${VERSION}-linux ../dogecoin/contrib/gitian-descriptors/gitian-linux.yml
./bin/gverify -v -d ../gitian.sigs/ -r ${VERSION}-win-unsigned ../dogecoin/contrib/gitian-descriptors/gitian-win.yml
./bin/gverify -v -d ../gitian.sigs/ -r ${VERSION}-osx-unsigned ../dogecoin/contrib/gitian-descriptors/gitian-osx.yml
popd

Next steps:

Commit your signature to gitian.sigs:

pushd gitian.sigs
git add ${VERSION}-linux/${SIGNER}
git add ${VERSION}-win-unsigned/${SIGNER}
git add ${VERSION}-osx-unsigned/${SIGNER}
git commit -a
git push  # Assuming you can push to the gitian.sigs tree
popd

Wait for Windows/OS X detached signatures:

• Once the Windows/OS X builds each have 3 matching signatures, they will be signed with their respective release keys.
• Detached signatures will then be committed to the dogecoin-detached-sigs repository, which can be combined with the unsigned apps to create signed binaries.

Create (and optionally verify) the signed OS X binary:

pushd ./gitian-builder
./bin/gbuild -i --commit signature=v${VERSION} ../dogecoin/contrib/gitian-descriptors/gitian-osx-signer.yml
./bin/gsign --signer $SIGNER --release ${VERSION}-osx-signed --destination ../gitian.sigs/ ../dogecoin/contrib/gitian-descriptors/gitian-osx-signer.yml
./bin/gverify -v -d ../gitian.sigs/ -r ${VERSION}-osx-signed ../dogecoin/contrib/gitian-descriptors/gitian-osx-signer.yml
mv build/out/dogecoin-osx-signed.dmg ../dogecoin-${VERSION}-osx.dmg
popd

Create (and optionally verify) the signed Windows binaries:

pushd ./gitian-builder
./bin/gbuild -i --commit signature=v${VERSION} ../dogecoin/contrib/gitian-descriptors/gitian-win-signer.yml
./bin/gsign --signer $SIGNER --release ${VERSION}-win-signed --destination ../gitian.sigs/ ../dogecoin/contrib/gitian-descriptors/gitian-win-signer.yml
./bin/gverify -v -d ../gitian.sigs/ -r ${VERSION}-win-signed ../dogecoin/contrib/gitian-descriptors/gitian-win-signer.yml
mv build/out/dogecoin-*win64-setup.exe ../dogecoin-${VERSION}-win64-setup.exe
mv build/out/dogecoin-*win32-setup.exe ../dogecoin-${VERSION}-win32-setup.exe
popd

Commit your signature for the signed OS X/Windows binaries:

pushd gitian.sigs
git add ${VERSION}-osx-signed/${SIGNER}
git add ${VERSION}-win-signed/${SIGNER}
git commit -a
git push  # Assuming you can push to the gitian.sigs tree
popd

After 3 or more people have gitian-built and their results match:

• Create SHA256SUMS.asc for the builds, and GPG-sign it:

sha256sum * > SHA256SUMS

The list of files should be:

dogecoin-${VERSION}-aarch64-linux-gnu.tar.gz
dogecoin-${VERSION}-arm-linux-gnueabihf.tar.gz
dogecoin-${VERSION}-i686-pc-linux-gnu.tar.gz
dogecoin-${VERSION}-x86_64-linux-gnu.tar.gz
dogecoin-${VERSION}-osx64.tar.gz
dogecoin-${VERSION}-osx.dmg
dogecoin-${VERSION}.tar.gz
dogecoin-${VERSION}-win32-setup.exe
dogecoin-${VERSION}-win32.zip
dogecoin-${VERSION}-win64-setup.exe
dogecoin-${VERSION}-win64.zip

The *-debug* files generated by the gitian build contain debug symbols for troubleshooting by developers. It is assumed that anyone that is interested in debugging can run gitian to generate the files for themselves. To avoid end-user confusion about which file to pick, as well as save storage space do not upload these to the dogecoin.com server, nor put them in the torrent.

• GPG-sign it, delete the unsigned file:

gpg --digest-algo sha256 --clearsign SHA256SUMS # outputs SHA256SUMS.asc
rm SHA256SUMS

(the digest algorithm is forced to sha256 to avoid confusion of the Hash: header that GPG adds with the SHA256 used for the files) Note: check that SHA256SUMS itself doesn't end up in SHA256SUMS, which is a spurious/nonsensical entry.

• Upload zips and installers, as well as SHA256SUMS.asc from last step, to the dogecoin.com Github repo

• Create a new GitHub release with a link to the archived release notes.

• Update dogecoin.com version - Langerhans to do

• Announce the release:

  • Release sticky on Dogecoin Forums: http://forum.dogecoin.com/forum/news-community/community-announcements

  • Dogecoin-development mailing list

  • Twitter, reddit /r/dogecoin

  • Update title of #dogecoin on Freenode IRC

  • Announce on reddit /r/dogecoin, /r/dogecoindev

• Add release notes for the new version to the directory doc/release-notes in git master

• To the moon!

Shared Libraries

dogecoinconsensus

The purpose of this library is to make the verification functionality that is critical to Dogecoin's consensus available to other applications, e.g. to language bindings.

API

The interface is defined in the C header dogecoinconsensus.h located in src/script/dogecoinconsensus.h.

Version

dogecoinconsensus_version returns an unsigned int with the API version (currently at an experimental 0).

Script Validation

dogecoinconsensus_verify_script returns an int with the status of the verification. It will be 1 if the input script correctly spends the previous output scriptPubKey.

Parameters

• const unsigned char *scriptPubKey - The previous output script that encumbers spending.
• unsigned int scriptPubKeyLen - The number of bytes for the scriptPubKey.
• const unsigned char *txTo - The transaction with the input that is spending the previous output.
• unsigned int txToLen - The number of bytes for the txTo.
• unsigned int nIn - The index of the input in txTo that spends the scriptPubKey.
• unsigned int flags - The script validation flags (see below).
• dogecoinconsensus_error* err - Will have the error/success code for the operation (see below).

Script Flags

• dogecoinconsensus_SCRIPT_FLAGS_VERIFY_NONE
• dogecoinconsensus_SCRIPT_FLAGS_VERIFY_P2SH - Evaluate P2SH (BIP16) subscripts
• dogecoinconsensus_SCRIPT_FLAGS_VERIFY_DERSIG - Enforce strict DER (BIP66) compliance
• dogecoinconsensus_SCRIPT_FLAGS_VERIFY_NULLDUMMY - Enforce NULLDUMMY (BIP147)
• dogecoinconsensus_SCRIPT_FLAGS_VERIFY_CHECKLOCKTIMEVERIFY - Enable CHECKLOCKTIMEVERIFY (BIP65)
• dogecoinconsensus_SCRIPT_FLAGS_VERIFY_CHECKSEQUENCEVERIFY - Enable CHECKSEQUENCEVERIFY (BIP112)
• dogecoinconsensus_SCRIPT_FLAGS_VERIFY_WITNESS - Enable WITNESS (BIP141)

Errors

• dogecoinconsensus_ERR_OK - No errors with input parameters (see the return value of dogecoinconsensus_verify_script for the verification status)
• dogecoinconsensus_ERR_TX_INDEX - An invalid index for txTo
• dogecoinconsensus_ERR_TX_SIZE_MISMATCH - txToLen did not match with the size of txTo
• dogecoinconsensus_ERR_DESERIALIZE - An error deserializing txTo
• dogecoinconsensus_ERR_AMOUNT_REQUIRED - Input amount is required if WITNESS is used

Example Implementations

• NBitcoin (.NET Bindings)
• node-libdogecoinconsensus (Node.js Bindings)
• java-libdogecoinconsensus (Java Bindings)
• dogecoinconsensus-php (PHP Bindings)

TOR SUPPORT IN DOGECOIN

It is possible to run Dogecoin as a Tor hidden service, and connect to such services.

The following directions assume you have a Tor proxy running on port 9050. Many distributions default to having a SOCKS proxy listening on port 9050, but others may not. In particular, the Tor Browser Bundle defaults to listening on port 9150. See Tor Project FAQ:TBBSocksPort for how to properly configure Tor.

1. Run Dogecoin behind a Tor proxy

The first step is running Dogecoin behind a Tor proxy. This will already make all outgoing connections be anonymized, but more is possible.

-proxy=ip:port  Set the proxy server. If SOCKS5 is selected (default), this proxy
                server will be used to try to reach .onion addresses as well.

-onion=ip:port  Set the proxy server to use for Tor hidden services. You do not
                need to set this if it's the same as -proxy. You can use -noonion
                to explicitly disable access to hidden service.

-listen         When using -proxy, listening is disabled by default. If you want
                to run a hidden service (see next section), you'll need to enable
                it explicitly.

-connect=X      When behind a Tor proxy, you can specify .onion addresses instead
-addnode=X      of IP addresses or hostnames in these parameters. It requires
-seednode=X     SOCKS5. In Tor mode, such addresses can also be exchanged with
                other P2P nodes.

In a typical situation, this suffices to run behind a Tor proxy:

./dogecoin -proxy=127.0.0.1:9050

2. Run a Dogecoin hidden server

If you configure your Tor system accordingly, it is possible to make your node also reachable from the Tor network. Add these lines to your /etc/tor/torrc (or equivalent config file):

HiddenServiceDir /var/lib/tor/dogecoin-service/
HiddenServicePort 22556 127.0.0.1:22556
HiddenServicePort 44556 127.0.0.1:44556

The directory can be different of course, but (both) port numbers should be equal to your dogecoind's P2P listen port (22556 by default).

-externalip=X   You can tell Dogecoin about its publicly reachable address using
                this option, and this can be a .onion address. Given the above
                configuration, you can find your onion address in
                /var/lib/tor/dogecoin-service/hostname. Onion addresses are given
                preference for your node to advertise itself with, for connections
                coming from unroutable addresses (such as 127.0.0.1, where the
                Tor proxy typically runs).

-listen         You'll need to enable listening for incoming connections, as this
                is off by default behind a proxy.

-discover       When -externalip is specified, no attempt is made to discover local
                IPv4 or IPv6 addresses. If you want to run a dual stack, reachable
                from both Tor and IPv4 (or IPv6), you'll need to either pass your
                other addresses using -externalip, or explicitly enable -discover.
                Note that both addresses of a dual-stack system may be easily
                linkable using traffic analysis.

In a typical situation, where you're only reachable via Tor, this should suffice:

./dogecoind -proxy=127.0.0.1:9050 -externalip=57qr3yd1nyntf5k.onion -listen

(obviously, replace the Onion address with your own). It should be noted that you still listen on all devices and another node could establish a clearnet connection, when knowing your address. To mitigate this, additionally bind the address of your Tor proxy:

./dogecoind ... -bind=127.0.0.1

If you don't care too much about hiding your node, and want to be reachable on IPv4 as well, use discover instead:

./dogecoind ... -discover

and open port 22556 on your firewall (or use -upnp).

If you only want to use Tor to reach onion addresses, but not use it as a proxy for normal IPv4/IPv6 communication, use:

./dogecoin -onion=127.0.0.1:9050 -externalip=57qr3yd1nyntf5k.onion -discover

3. Automatically listen on Tor

Starting with Tor version 0.2.7.1 it is possible, through Tor's control socket API, to create and destroy 'ephemeral' hidden services programmatically. Bitcoin Core has been updated to make use of this.

This means that if Tor is running (and proper authentication has been configured), Dogecoin Core automatically creates a hidden service to listen on. This will positively affect the number of available .onion nodes.

This new feature is enabled by default if Dogecoin Core is listening (-listen), and requires a Tor connection to work. It can be explicitly disabled with -listenonion=0 and, if not disabled, configured using the -torcontrol and -torpassword settings. To show verbose debugging information, pass -debug=tor.

Connecting to Tor's control socket API requires one of two authentication methods to be configured. For cookie authentication the user running dogecoind must have write access to the CookieAuthFile specified in Tor configuration. In some cases this is preconfigured and the creation of a hidden service is automatic. If permission problems are seen with -debug=tor they can be resolved by adding both the user running tor and the user running dogecoind to the same group and setting permissions appropriately. On Debian-based systems the user running dogecoind can be added to the debian-tor group, which has the appropriate permissions. An alternative authentication method is the use of the -torpassword flag and a hash-password which can be enabled and specified in Tor configuration.

4. Privacy recommendations

• Do not add anything but dogecoin ports to the hidden service created in section 2. If you run a web service too, create a new hidden service for that. Otherwise it is trivial to link them, which may reduce privacy. Hidden services created automatically (as in section 3) always have only one port open.

Translations

The Bitcoin-Core project has been designed to support multiple localisations. This makes adding new phrases, and completely new languages easily achievable. For managing all application translations, Bitcoin-Core makes use of the Transifex online translation management tool.

Helping to translate (using Transifex)

Transifex is setup to monitor the GitHub repo for updates, and when code containing new translations is found, Transifex will process any changes. It may take several hours after a pull-request has been merged, to appear in the Transifex web interface.

Multiple language support is critical in assisting Bitcoin’s global adoption, and growth. One of Bitcoin’s greatest strengths is cross-border money transfers, any help making that easier is greatly appreciated.

See the Transifex Bitcoin project to assist in translations. You should also join the translation mailing list for announcements - see details below.

Writing code with translations

We use automated scripts to help extract translations in both Qt, and non-Qt source files. It is rarely necessary to manually edit the files in src/qt/locale/. The translation source files must adhere to the following format: bitcoin_xx_YY.ts or bitcoin_xx.ts

src/qt/locale/bitcoin_en.ts is treated in a special way. It is used as the source for all other translations. Whenever a string in the source code is changed, this file must be updated to reflect those changes. A custom script is used to extract strings from the non-Qt parts. This script makes use of gettext, so make sure that utility is installed (ie, apt-get install gettext on Ubuntu/Debian). Once this has been updated, lupdate (included in the Qt SDK) is used to update bitcoin_en.ts.

To automatically regenerate the bitcoin_en.ts file, run the following commands:

cd src/
make translate

contrib/bitcoin-qt.pro takes care of generating .qm (binary compiled) files from .ts (source files) files. It’s mostly automated, and you shouldn’t need to worry about it.

Example Qt translation

QToolBar *toolbar = addToolBar(tr("Tabs toolbar"));

Creating a pull-request

For general PRs, you shouldn’t include any updates to the translation source files. They will be updated periodically, primarily around pre-releases, allowing time for any new phrases to be translated before public releases. This is also important in avoiding translation related merge conflicts.

When an updated source file is merged into the GitHub repo, Transifex will automatically detect it (although it can take several hours). Once processed, the new strings will show up as "Remaining" in the Transifex web interface and are ready for translators.

To create the pull-request, use the following commands:

git add src/qt/bitcoinstrings.cpp src/qt/locale/bitcoin_en.ts
git commit

Creating a Transifex account

Visit the Transifex Signup page to create an account. Take note of your username and password, as they will be required to configure the command-line tool.

You can find the Bitcoin translation project at https://www.transifex.com/projects/p/bitcoin/.

Installing the Transifex client command-line tool

The client it used to fetch updated translations. If you are having problems, or need more details, see http://docs.transifex.com/developer/client/setup

For Linux and Mac

pip install transifex-client

Setup your transifex client config as follows. Please ignore the token field.

nano ~/.transifexrc

[https://www.transifex.com]
hostname = https://www.transifex.com
password = PASSWORD
token =
username = USERNAME

For Windows

Please see http://docs.transifex.com/developer/client/setup#windows for details on installation.

The Transifex Bitcoin project config file is included as part of the repo. It can be found at .tx/config, however you shouldn’t need change anything.

Synchronising translations

To assist in updating translations, we have created a script to help.

1. python contrib/devtools/update-translations.py
2. Update src/qt/bitcoin_locale.qrc manually or via ls src/qt/locale/*ts|xargs -n1 basename|sed 's/\(bitcoin_\(.*\)\).ts/<file alias="\2">locale\/\1.qm<\/file>/'
3. Update src/Makefile.qt.include manually or via ls src/qt/locale/*ts|xargs -n1 basename|sed 's/\(bitcoin_\(.*\)\).ts/ qt\/locale\/\1.ts \\/'
4. git add new translations from src/qt/locale/

Do not directly download translations one by one from the Transifex website, as we do a few post-processing steps before committing the translations.

Handling Plurals (in source files)

When new plurals are added to the source file, it's important to do the following steps:

1. Open bitcoin_en.ts in Qt Linguist (included in the Qt SDK)
2. Search for %n, which will take you to the parts in the translation that use plurals
3. Look for empty English Translation (Singular) and English Translation (Plural) fields
4. Add the appropriate strings for the singular and plural form of the base string
5. Mark the item as done (via the green arrow symbol in the toolbar)
6. Repeat from step 2, until all singular and plural forms are in the source file
7. Save the source file

Translating a new language

To create a new language template, you will need to edit the languages manifest file src/qt/bitcoin_locale.qrc and add a new entry. Below is an example of the English language entry.

<qresource prefix="/translations">
    <file alias="en">locale/bitcoin_en.qm</file>
    ...
</qresource>

Note: that the language translation file must end in .qm (the compiled extension), and not .ts.

Questions and general assistance

The Bitcoin-Core translation maintainers include tcatm, seone, Diapolo, wumpus and luke-jr. You can find them, and others, in the Freenode IRC chatroom - irc.freenode.net #bitcoin-core-dev.

If you are a translator, you should also subscribe to the mailing list, https://groups.google.com/forum/#!forum/bitcoin-translators. Announcements will be posted during application pre-releases to notify translators to check for updates.

Translation Strings Policy

This document provides guidelines for internationalization of the Dogecoin Core software.

How to translate?

To mark a message as translatable

• In GUI source code (under src/qt): use tr("...")

• In non-GUI source code (under src): use _("...")

No internationalization is used for e.g. developer scripts outside src.

Strings to be translated

On a high level, these strings are to be translated:

• GUI strings, anything that appears in a dialog or window

• Command-line option documentation

GUI strings

Anything that appears to the user in the GUI is to be translated. This includes labels, menu items, button texts, tooltips and window titles. This includes messages passed to the GUI through the UI interface through InitMessage, ThreadSafeMessageBox or ShowProgress.

Command-line options

Documentation for the command line options in the output of --help should be translated as well.

Make sure that default values do not end up in the string, but use string formatting like strprintf(_("Threshold for disconnecting misbehaving peers (default: %u)"), 100). Putting default values in strings has led to accidental translations in the past, and forces the string to be retranslated every time the value changes.

Do not translate messages that are only shown to developers, such as those that only appear when --help-debug is used.

General recommendations

Avoid unnecessary translation strings

Try not to burden translators with translating messages that are e.g. slight variations of other messages. In the GUI, avoid the use of text where an icon or symbol will do. Make sure that placeholder texts in forms don't end up in the list of strings to be translated (use <string notr="true">).

Make translated strings understandable

Try to write translation strings in an understandable way, for both the user and the translator. Avoid overly technical or detailed messages

Do not translate internal errors

Do not translate internal errors, or log messages, or messages that appear on the RPC interface. If an error is to be shown to the user, use a translatable generic message, then log the detailed message to the log. E.g. "A fatal internal error occurred, see debug.log for details". This helps troubleshooting; if the error is the same for everyone, the likelihood is increased that it can be found using a search engine.

Avoid fragments

Avoid dividing up a message into fragments. Translators see every string separately, so may misunderstand the context if the messages are not self-contained.

Avoid HTML in translation strings

There have been difficulties with use of HTML in translation strings; translators should not be able to accidentally affect the formatting of messages. This may sometimes be at conflict with the recommendation in the previous section.

Plurals

Plurals can be complex in some languages. A quote from the gettext documentation:

In Polish we use e.g. plik (file) this way:
1 plik,
2,3,4 pliki,
5-21 pliko'w,
22-24 pliki,
25-31 pliko'w
and so on

In Qt code use tr's third argument for optional plurality. For example:

tr("%n hour(s)","",secs/HOUR_IN_SECONDS);
tr("%n day(s)","",secs/DAY_IN_SECONDS);
tr("%n week(s)","",secs/WEEK_IN_SECONDS);

This adds <numerusform>s to the respective .ts file, which can be translated separately depending on the language. In English, this is simply:

<message numerus="yes">
    <source>%n active connection(s) to Bitcoin network</source>
    <translation>
        <numerusform>%n active connection to Bitcoin network</numerusform>
        <numerusform>%n active connections to Bitcoin network</numerusform>
    </translation>
</message>

Where it is possible try to avoid embedding numbers into the flow of the string at all. e.g.

WARNING: check your network connection, %d blocks received in the last %d hours (%d expected)

versus

WARNING: check your network connection, less blocks (%d) were received in the last %n hours than expected (%d).

The second example reduces the number of pluralized words that translators have to handle from three to one, at no cost to comprehensibility of the sentence.

Finding strings to translate

Translation files are in the directory src/qt/locale/ and have the .ts suffix.

If you have the lupdate Qt development tool installed, run make translate language=... from the src/ directory. This will update translation files in the locale directory. For the language argument, use a language suffix and optional country code. For example, make translate language=en_GB will update the English language (en) file for the United Kingdom (GB). Look at the translation files for examples of existing supported languages

In the appropriate file for your language/locale, look for entries with the tags type="unfinished". These are new, untranslated entries. When you finish translating them, remove that tag.

You may also see entries with the tag type="vanished". These are entries where the original text has been removed from the source code. Remove these in a separate step.

String freezes

During a string freeze (often before a major release), no translation strings are to be added, modified or removed.

This can be checked by executing make translate in the src directory, then verifying that bitcoin_en.ts remains unchanged.

Travis CI

Support for using travis-ci has been added in order to automate pull-testing. See travis-ci.org for more info

This procedure is different than the pull-tester that came before it in a few ways.

There is nothing to administer. This is a major feature as it means that builds have no local state. Because there is no ability to login to the builders to install packages (tools, dependencies, etc), the entire build procedure must instead be controlled by a declarative script .travis.yml. This script declares each build configuration, creates virtual machines as necessary, builds, then discards the virtual machines.

A build matrix is constructed to test a wide range of configurations, rather than a single pass/fail. This helps to catch build failures and logic errors that present on platforms other than the ones the author has tested. This matrix is defined in the build script and can be changed at any time.

All builders use the dependency-generator in the depends dir, rather than using apt-get to install build dependencies. This guarantees that the tester is using the same versions as Gitian, so the build results are nearly identical to what would be found in a final release. However, this also means that builds will fail if new dependencies are introduced without being added to the dependency generator.

In order to avoid rebuilding all dependencies for each build, the binaries are cached and re-used when possible. Changes in the dependency-generator will trigger cache-invalidation and rebuilds as necessary.

These caches can be manually removed if necessary. This is one of the very few manual operations that is possible with Travis, and it can be done by the Dogecoin Core committer via the Travis web interface.

In some cases, secure strings may be needed for hiding sensitive info such as private keys or URLs. The travis client may be used to create these strings: http://docs.travis-ci.com/user/encryption-keys/

For the details of the build descriptor, see the official docs: http://docs.travis-ci.com/user/build-configuration/

Block and Transaction Broadcasting with ZeroMQ

ZeroMQ is a lightweight wrapper around TCP connections, inter-process communication, and shared-memory, providing various message-oriented semantics such as publish/subscribe, request/reply, and push/pull.

The Dogecoin Core daemon can be configured to act as a trusted "border router", implementing the dogecoin wire protocol and relay, making consensus decisions, maintaining the local blockchain database, broadcasting locally generated transactions into the network, and providing a queryable RPC interface to interact on a polled basis for requesting blockchain related data. However, there exists only a limited service to notify external software of events like the arrival of new blocks or transactions.

The ZeroMQ facility implements a notification interface through a set of specific notifiers. Currently there are notifiers that publish blocks and transactions. This read-only facility requires only the connection of a corresponding ZeroMQ subscriber port in receiving software; it is not authenticated nor is there any two-way protocol involvement. Therefore, subscribers should validate the received data since it may be out of date, incomplete or even invalid.

ZeroMQ sockets are self-connecting and self-healing; that is, connections made between two endpoints will be automatically restored after an outage, and either end may be freely started or stopped in any order.

Because ZeroMQ is message oriented, subscribers receive transactions and blocks all-at-once and do not need to implement any sort of buffering or reassembly.

Prerequisites

The ZeroMQ feature in Dogecoin Core requires ZeroMQ API version 4.x or newer. Typically, it is packaged by distributions as something like libzmq3-dev. The C++ wrapper for ZeroMQ is not needed.

In order to run the example Python client scripts in contrib/ one must also install python3-zmq, though this is not necessary for daemon operation.

Enabling

By default, the ZeroMQ feature is automatically compiled in if the necessary prerequisites are found. To disable, use --disable-zmq during the configure step of building dogecoind:

$ ./configure --disable-zmq (other options)

To actually enable operation, one must set the appropriate options on the command line or in the configuration file.

Usage

Currently, the following notifications are supported:

-zmqpubhashtx=address
-zmqpubhashblock=address
-zmqpubrawblock=address
-zmqpubrawtx=address

The socket type is PUB and the address must be a valid ZeroMQ socket address. The same address can be used in more than one notification.

For instance:

$ dogecoind -zmqpubhashtx=tcp://127.0.0.1:28332 \
           -zmqpubrawtx=ipc:///tmp/dogecoind.tx.raw

Each PUB notification has a topic and body, where the header corresponds to the notification type. For instance, for the notification -zmqpubhashtx the topic is hashtx (no null terminator) and the body is the hexadecimal transaction hash (32 bytes).

These options can also be provided in dogecoin.conf.

ZeroMQ endpoint specifiers for TCP (and others) are documented in the ZeroMQ API.

Client side, then, the ZeroMQ subscriber socket must have the ZMQ_SUBSCRIBE option set to one or either of these prefixes (for instance, just hash); without doing so will result in no messages arriving. Please see contrib/zmq/zmq_sub.py for a working example.

Remarks

From the perspective of dogecoind, the ZeroMQ socket is write-only; PUB sockets don't even have a read function. Thus, there is no state introduced into dogecoind directly. Furthermore, no information is broadcast that wasn't already received from the public P2P network.

No authentication or authorization is done on connecting clients; it is assumed that the ZeroMQ port is exposed only to trusted entities, using other means such as firewalling.

Note that when the block chain tip changes, a reorganisation may occur and just the tip will be notified. It is up to the subscriber to retrieve the chain from the last known block to the new tip.

There are several possibilities that ZMQ notification can get lost during transmission depending on the communication type your are using. Dogecoind appends an up-counting sequence number to each notification which allows listeners to detect lost notifications.

Dogecoin Core [DOGE, Ð]

Dogecoin é uma criptomoeda gerida pela comunidade que foi inspirada no meme Shiba Inu. O programa Dogecoin Core permite qualquer um operar um nó na rede blockchain da Dogecoin e utilizar o algoritmo de hash Scrypt para mineração usando Prova de Trabalho (Proof of Work). O Dogecoin Core é uma adaptação do Bitcoin Core e de outras criptomoedas.

Para maiores informações acerca das taxas de transação usadas na rede Dogecoin, por favor acesse: taxas recomendadas.

Website: dogecoin.com

Uso 💻

Para começar a sua jornada com o Dogecoin Core, veja o manual de instalação e o guia para iniciantes.

A API JSON-RPC fornecida pelo Dogecoin Core é auto documentada e pode ser buscada pelo comando dogecoin-cli help, informações mais detalhadas sobre cada comando podem ser encontradas usando dogecoin-cli help <command>. Alternativamente, veja a documentação do Bitcoin Core - que implementa um protocolo similar - para conseguir uma versão navegável.

Quais as portas

A Dogecoin Core utiliza por padrão a porta 22556 para comunicação par-a-par, que é necessária para sincronizar a blockchain da "rede principal" e se manter informada de novas transações e blocos. Outrosim, uma porta JSONRPC pode ser aberta, que por padrão é a porta 22555 para nós da rede principal. Recomendamos fortemente não expor portas RPC para a internet pública.

Desenvolvimento continuo - Plano Lua 🌒

A Dogecoin Core é um programa de código aberto gerido pela comunidade. O processo de desenvolvimento é aberto e visivel publicamente; qualquer um pode ver, discutir e trabalhar no programa.

Recursos principais de Desenvolvimento:

• Projetos do Github é utilizado para conduzir trabalhos planejados ou que estejam em desenvolvimento para as próximas atualizações.
• Discussão do Github é usado para discutir sobre funcionalidades, planejadas ou não, relacionadas ao desenvolvimento do programa Dogecoin Core, os protocolos adjacentes e o criptoativo DOGE.
• Dogecoindev subreddit

Estratégia das Versões

Os numeros de compilação seguem a seguinte semantica: major.minor.patch

Ramificações

Este repositório possui 3 principais ramificações (branchs), são essas:

• master: Estável, contém a ultima versão da ultima atualização principal major.minor.
• maintenance: Estável, contém a ultima versão de atualizações anteriores, que ainda estão em manutenção. Formato: <version>-maint
• development: Instável, contém código novo para atualizações planejadas. Formato: <version>-dev

As ramificações Master e Maintenance, são exclusivamente mutáveis por lançamento. Atualizações planejadas sempre terão uma ramificação de desenvolvimento e as solicitações de inclusão deverão ser encaminhadas por meio destas. Ramificações de manutenção existem apenas para correção de bugs, por favor, encaminhem novos recursos na ramificação de desenvolvimento com a versão mais alta.

Contribuindo 🤝

Se você achar um bug ou passar por alguma experiência incomum com este programa, por favor reporte o ocorrido usado o sistema de problemas (issues).

Por favor, acesse o guia de contribuições para ver como você pode participar do desenvolvimento do Dogecoin Core. Existem alguns pedidos de ajuda onde os contribuintes terão grande importância e apreço. wow.

Comunidades 🚀🍾

Você pode se juntar à comunidade em diferentes redes sociais. Pra ver o que está acontecendo, encontrar gente e discutir, receber o ultimo meme, aprender sobre Dogecoin, dar e receber ajuda e compartilhar seu projeto.

Aqui estão alguns lugares pra visitar:

• Dogecoin subreddit
• Dogeducation subreddit
• Discord
• Dogecoin Twitter

Perguntas frequentes ❓

Você possui alguma questão relacionada à Dogecoin? Talvez uma resposta já esteja disponivel no FAQ ou na seção Q&A do nosso quadro de discussão!

Licenças ⚖️

Dogecoin Core é disponibilizada sob os termos de uso da licença MIT. Veja, COPYING para mais informações ou opensource.org

狗狗币核心 (Dogecoin Core) [DOGE, Ð]

狗狗币是一款受柴犬表情包启发，由社区驱动的加密货币。通过狗狗币内核软件，任何人都可以在狗狗币区块链网络中建立一个节点。节点采用Scrypt哈希算法来实现工作量证明(Proof of Work)。狗狗币内核是从比特币内核和其它加密货币演化而来。

狗狗币网络默认交易费的相关信息请查看收费建议

网址: dogecoin.com

使用指南 💻

开始使用狗狗币内核软件，请参考安装指南和入门教程。

狗狗币内核提供基于自文档化的JSON-RPC API，可用dogecoin-cli help浏览。同时可用'dogecoin-cli help `浏览每条命令的详细信息。另外，可参考游览器版的比特币内核文档（ 它部署了类似的协议）。

炫酷的端口

狗狗币内核的点对点通信默的默认端口为22556，用于与主网络（mainnet）区块链同步，并接受新交易和新区块的信息。此外，还可打开一个默认端口号为22555的JSONRPC端口供主网络节点使用。强烈建议不要将RPC端口暴露给公共网络。

进行中的开发 - 月球计划 🌒

狗狗币内核是一个社区驱动的开源软件。其开发过程是开放的并公开可见的。任何人都可以查看，讨论和使用该软件。

主要开发资料：

• Github Projects用于跟踪即将发布的计划和正在进行的工作。
• Github Discussion用于讨论与狗狗币内核软件开发、底层协议和狗狗币资产相关的计划内和计划外功能。
• Dogecoindev subreddit

版本说明

版本号码遵循以下语法：major.minor.patch。

代码库分支(branch)

本代码库有3个branch：

• master（主代码库）: 稳定。包含最新版本的release，以major.minor形式呈现。
• maintenance（维护代码库）: 稳定。包含正在维护中的上一个release的最新版本。格式： <version>-maint
• development（正在开发代码库）: 不稳定。包含下一个release的最新代码。格式： <version>-dev

Master 和 maintenance 互不干扰。最新release永远包含一个development分支。新的 pull request 应该发布于此。Maintenance 分支只能用于调试程序。请将新开发的功能发布在 development 分支的最高版本。

炫酷的贡献 🤝

如果您发现错误或者遇到问题，请报告在问题系统

想了解如何参与狗狗币内核开发，请访问贡献指引。 那里常常有主题需要帮助。 您的贡献一定会产生很大的影响并赢得炫酷的称赞。哇哦(wow)。

社区 🚀🍾

您能通过不同的社交媒体加入狗狗币社区。在那里您可以看到最近的新闻，与别人见面和讨论，找到最新的表情包，进一步了解狗狗币，帮忙别人或者请求帮忙，分享您的项目。

以下是一些社区的访问链接:

• Dogecoin subreddit
• Dogeducation subreddit
• Discord
• Dogecoin Twitter

灰常常见的问题 ❓

如果对狗狗币有问题，答案很可能已经在常见问答或者问与答!里了。

许可证 - 灰常的许可 ⚖️

狗狗币内核是根据MIT许可条款发布的。更多相关信息，请参阅COPYING或者查看opensource.org

Dogecoin Core [DOGE, Ð]

دوج‌کوین (Dogecoin) یک رمزارز مبتنی بر عموم مردم بوده که از یک میم اینترنتی سگی با نژاد شیبا اینو الهام گرفته شده است. نرم‌افزار Dogecoin Core به همه این اجازه را می‌دهد که یک گره (Node) در شبکه‌های بلاک‌چین دوج‌کوین را اداره کنند که در آن از روش هش کردن Scrypt به عنوان Proof of Work یا اثبات انجام عملیات بهره برده شده است. در این پروژه از Bitcoin Core و سایر رمزارزها الگوبرداری شده است.

برای کسب اطلاعات درباره‌ی دستمزد جابه‌جایی در شبکه‌ی Dogecoin، لطفا به پیشنهادهای هزینه‌ای مراجعه نمایید.

سایت اینترنتی: dogecoin.com

استفاده 💻

به منظور آغاز سفرتان در Dogecoin Core، راهنمای نصب و راهنمای شروع کار را مطالعه فرمایید.

واسط برنامه‌نویسی کاربردی (JSON-RPC API) ارائه‌شده توسط Dogecoin Core دارای راهنمای استفاده‌ی درونی است و می‌تواند با استفاده از dogecoin-cli help مورد بهره‌برداری قرار گیرد، و نیز اطلاعات جامع در مورد هر یک از دستورها به واسطه‌ی dogecoin-cli help <command> قابل دستیابی هستند. علاوه بر این، می‌توانید راهنمای Bitcoin Core که پیاده‌سازی یک پروتکل مشابه است را برای دستیابی به یک منبع برخط مطالعه فرمایید.

چه پورت‌هایی

پروژه‌ی Dogecoin Core به طور پیش‌فرض از پورت شماره‌ی ۲۲۵۵۶ برای مکالمات نظیر-به-نظیر (peer-to-peer) که برای همگام‌سازی شبکه‌ی اصلی (mainnet) بلاک‌چین و حفظ آگاهی از تراکنش‌ها و بلاک‌هاست استفاده می‌کند. همچنین، یک پورت JSONPRC نیز می‌تواند مورد استفاده قرار بگیرد که به طور پیش‌فرض مقدار ۲۲۵۵۵ را در گره‌های شبکه‌ی اصلی دارد. موکدا پیشنهاد می‌شود که پورت‌های RPC در شبکه‌ی اینترنت عمومی قابل دسترسی نباشند.

توسعه‌ی در حال انجام - نقشه‌ی فتح ماه 🌒

پروژه‌ی Dogecoin Core یک نرم‌افزار مبتنی بر عموم و متن‌باز است. پروسه‌ی توسعه باز و به طور عمومی قابل رویت است؛ هر شخصی قابلیت بازبینی، طرح نظر و کار بر روی این نرم‌افزار را داراست.

منابع اصلی توسعه:

• پروژه‌های Github به منظور پیگیری کارهای برنامه‌ریزی‌شده و دردست‌اقدام برای نسخه‌های آتی استفاده می‌شوند.
• مباحث در Github به منظور مورد بحث قرار دادن شاخصه‌های برنامه‌ریزی‌شده و نشده‌ی نرم‌افزار Dogecoin Core، پروتکل‌های زیربنایی آن و دارایی DOGE مورد استفاده قرار می‌گیرد.
• زیرقسمت Dogecoindev در سایت Reddit

استراتژی نسخه‌گذاری

شماره‌های نسخ نرم‌افزار از الگوی اصلی.فرعی.رفع مشکل (major.minor.patch) تبعیت می‌کنند.

شاخه‌های (Branches)

در این مخزن نرم‌افزاری (repository) سه گونه از شاخه‌ها وجود دارند:

• شاخه‌ی master: پایدار بوده, شامل آخرین نسخه از آخرین پخش اصلی.فرعی نرم‌افزار است.
• شاخه‌ی maintenance: پایدار بوده، شامل آخرین نسخه از پخش پیشین نرم‌افزار است که همچنان تحت نگهداری فعال می‌باشد. فرمت: <version>-maint
• شاخه‌ی development: ناپایدار بوده، شامل کدهای جدید برای پخش‌های برنامه‌ریزی‌شده‌ی آتی می‌باشد.. فرمت: <version>-dev

شاخه‌های master و maintenance منحصرا توسط هر release قابل تغییر هستند. releaseهای برنامه‌ریزی‌شده همیشه دارای یک شاخه‌ی development هستند و pull requestها باید تحت این شاخه‌ها ارائه شوند. شاخه‌های maintenance فقط به منظور رفع باگ هستند. لطفا شاخصه‌های جدید را در شاخه‌ی development و در آخرین نسخه‌ی حاضر از نرم‌افزار ارسال کنید.

مشارکت 🤝

اگر باگی را یافته‌اید و یا مشکلی را در رابطه با این نرم‌افزار تجربه کرده‌اید، لطفا آن را با استفاده از سامانه‌ی مشکل‌ها. با ما مطرح نمایید.

لطفا قسمت شیوه‌نامه‌ی مشارکت را به منظور مطلع شدن از روش‌هایی که توسط آن‌ها می‌توانید در توسعه‌ی Dogecoin Core حضور داشته باشید را مطالعه فرمایید. اغلب موضوعات خواستار کمکی یافت می‌شوند که همکاری شما تاثیر بسزایی خواهد داشت و بسیار مورد ستایش قرار خواهد گرفت. وای!

انجمن‌ها 🚀🍾

شما می‌توانید برای باخبر شدن، ملاقات افراد و مباحثه، یافتن آخرین میم‌ها، دریافت اطلاعات درباره‌ی Dogecoin، کمک رساندن و یا درخواست کمک، و به‌اشتراک‌گذاری پروژه‌های خود به انجمن‌های مختلف در رسانه‌های اجتماعی بپیوندید.

این لیستی از برخی از جاهایی است که می‌توانید به آن سر بزنید:

• زیرقسمت Dogecoin در سایت Reddit
• زیرقسمت Dogeducation در سایت Reddit
• دیسکورد (Discord)
• توییتر Dogecoin

پرسش‌های بسیار خیلی زیاد پرسیده‌شده ❓

در مورد Dogecoin پرسشی دارید؟ ممکن است پاسخ آن همین الآن در FAQ و یا در قسمت پرسش و پاسخ مباحث وجود داشته باشد!

مجوز - مجوز خیلی زیاد ⚖️

نرم‌افزار Dogecoin Core تحت شرایط مجوز MIT ارائه شده است. برای اطلاعات بیش‌تر COPYING و یا opensource.org را مطالعه فرمایید.

Dogecoin Core [DOGE, Ð]

Dogecoin é uma criptomoeda voltada para a comunidade inspirada num meme Shiba Inu. O software Dogecoin Core permite que qualquer pessoa opere um nó nas redes blockchain Dogecoin e usa o método de hash Scrypt para Prova de Trabvalho. É adaptado do Bitcoin Core e outras criptomoedas.

Para mais informações acerca das taxas de transação utilizadas na rede Dogecoin, por favor clica aqui: taxas recomendadas.

Website: dogecoin.com

Utilização 💻

Para começares a tua jornada com o Dogecoin Core, ve o manual de instalação e o guia para iniciantes.

A API JSON-RPC incluida no Dogecoin Core é auto documentada e pode ser vista com o comando dogecoin-cli help, mais informações detalhadas sobre cada comando podem ser encontradas utilizando dogecoin-cli help <command>. Alternativamente, veja a documentação do Bitcoin Core - que implementa um protocolo similar - para conseguir uma versão navegável.

Quais as portas

O Dogecoin Core utiliza por padrão a porta 22556 para comunicação em rede ponto-a-ponto que é necessária para sincronizar a blockchain da "rede principal", (mainnet), e se manter actualizadadas novas transações e blocos. Adicionalmente a porta JSONRPC pode ser aberta que por defeito é 22555 para a rede principal. É fortemente recomendado a não expor as portas RPC publicamente na internet.

Desenvolvimento continuo - Plano, a Lua 🌒

O Dogecoin Core é um programa de código aberto gerido pela comunidade. O processo de desenvolvimento é aberto e visivel publicamente; qualquer um pode ver, discutir e trabalhar no programa.

Recursos principais de Desenvolvimento:

• Projetos do Github é utilizado para conduzir trabalhos planeado ou que estejam em desenvolvimento para as próximas atualizações.
• Discussão do Github é usado para discutir sobre as funcionalidades, planeadas ou não, relacionadas ao desenvolvimento do programa Dogecoin Core, os protocolos adjacentes e o criptoativo DOGE.
• Dogecoindev subreddit

Estratégia das Versões

Os numeros de compilação seguem a seguinte semantica: major.minor.patch

Ramificações

Este repositório possui 3 principais ramificações (branchs), são estas:

• master: Estável, contém a ultima versão da ultima atualização principal major.minor.
• maintenance: Estável, contém a ultima versão de atualizações anteriores, que ainda estão em manutenção. Formato: <version>-maint
• development: Instável, contém código novo para atualizações planeadas. Formato: <version>-dev

As ramificações Master e Maintenance, são exclusivamente mutáveis por lançamento. Atualizações planeadas terão sempre uma ramificação de desenvolvimento e as solicitações de inclusão deverão ser encaminhadas por meio destas. Ramificações de manutenção existem apenas para correção de bugs, por favor, encaminhem novos recursos na ramificação de desenvolvimento com a versão mais alta.

Contribuindo 🤝

Se encontrastes um bug ou tivestes alguma situação incomum com este programa, por favor informa-nos do ocorrido utilizando o sistema de problemas (issues).

Por favor, acede ao guia de contribuições para ver como podes participar no desenvolvimento do Dogecoin Core. Existem alguns pedidos de ajuda onde os contribuintes terão uma grande importância e apreço. wow.

Comunidades 🚀🍾

Podes te juntar à comunidade em diferentes redes sociais. Para veres o que está a acontecer, encontrar novas pessoas e discutir, receber o ultimo meme, aprender sobre Dogecoin, dar e receber ajuda e partilhares o teu projeto.

Aqui estão alguns lugares para visitares:

• Dogecoin subreddit
• Dogeducation subreddit
• Discord
• Dogecoin Twitter

Perguntas frequentes ❓

Tens alguma questão relacionada com o Dogecoin? Talvez já haja uma resposta, disponivel no FAQ ou na seção Q&A do nosso quadro de discussão!

Licenças ⚖️

Dogecoin Core é disponibilizada sob os termos de uso da licença MIT. Vê, COPYING para mais informações ou opensource.org

Dogecoin Core [DOGE, Ð]

Dogecoin là một loại tiền điện tử hướng tới cộng đồng được lấy cảm hứng từ meme Shiba Inu. Phần mềm Dogecoin Core cho phép bất kỳ ai vận hành node trong Dogecoin blockchain networks và sử dụng phương pháp băm Scrypt cho Proof of Work. Nó được điều chỉnh từ Bitcoin Core và các loại tiền điện tử khác.

Để biết thông tin về các khoản phí mặc định được sử dụng trên Dogecoin network, vui lòng tham khảo khuyến nghị phí.

Website: dogecoin.com

Cách sử dụng 💻

Để bắt đầu cuộc hành trình của bạn với Dogecoin Core, xem hướng dẫn cài đặt và hướng dẫn bắt đầu.

API JSON-RPC được cung cấp bởi Dogecoin Core là self-documenting và có thể đọc lướt qua với dogecoin-cli help, trong khi thông tin chi tiết cho từng lệnh có thể được xem với dogecoin-cli help <command>. Ngoài ra, hãy xem tài liệu Bitcoin Core - để triển khai một giao thức tương tự - hoặc có được phiên bản browsable.

Such ports

Dogecoin Core theo mặc định sử dụng cổng 22556 để giao tiếp peer-to-peer điều đó là cần thiết để đồng bộ hóa blockchain "mainnet" và cập nhật thông tin về các giao dịch và blocks mới. Ngoài ra, cổng JSONRPC có thể mở được, mặc định là cổng 22555 cho mainnet nodes. Chúng tôi đặc biệt khuyến nghị không để lộ các cổng RPC với internet công cộng.

Đang phát triển - Kế hoạch Moon 🌒

Dogecoin Core là một phần mềm nguồn mở và do cộng đồng hướng tới. Quá trình phát triển là công khai và được hiển thị công khai; bất kỳ ai cũng có thể xem, thảo luận và làm việc trên phần mềm.

Các nguồn lực phát triển chính::

• GitHub Projects được sử dụng để theo dõi công việc đã lên kế hoạch và đang tiến hành cho các bản phát hành sắp tới.
• GitHub Discussion được sử dụng để để thảo luận về các tính năng, được lên kế hoạch và chưa được kế hoạch, liên quan đến sự phát triển của phần mềm Dogecoin Core, các giao thức nền tảng và DOGE asset.
• Dogecoindev subreddit

Phiên bản Chiến lược

Số phiên bản tuân theo ngữ nghĩa major.minor.patch.

Các nhánh

Có 3 loại nhánh trong kho này:

• master: Ổn định, chứa phiên bản mới nhất của bản phát hành major.minor mới nhất .
• maintenance: Ổn định, chứa phiên bản mới nhất của các bản phát hành trước, vẫn đang được bảo trì tích cực. Định dạng: <version>-maint
• development: Không ổn định, chứa mã mới cho các bản phát hành theo kế hoạch. Định dạng: <version>-dev

Các nhánh master và maintenance có thể thay đổi độc quyền bằng cách phát hành. Các bản phát hành theo kế hoạch sẽ luôn có một nhánh để phát triển và các yêu cầu kéo phải được gửi theo các yêu cầu đó. Nhánh maintenance chỉ để sửa lỗi, vui lòng gửi các tính năng mới cho nhánh development với phiên bản cao nhất.

Đóng góp 🤝

Nếu bạn tìm thấy lỗi hoặc gặp sự cố với phần mềm này, vui lòng báo cáo nó bằng cách sử dụng hệ thống sự cố.

Vui lòng xem hướng dẫn đóng góp để biết cách bạn có thể tham gia vào quá trình phát triển Dogecoin Core. Thường có những chủ đề tìm kiếm sự trợ giúp trong đó những đóng góp của bạn sẽ có tác động cao và nhận được sự đánh giá rất cao. wow.

Cộng đồng 🚀🍾

Bạn có thể tham gia các cộng đồng trên các phương tiện truyền thông xã hội khác nhau. Để xem điều gì đang xảy ra, hãy gặp gỡ mọi người và thảo luận, tìm meme mới nhất, tìm hiểu về Dogecoin, cung cấp hoặc yêu cầu trợ giúp, để chia sẻ dự án của bạn.

Dưới đây là một số địa điểm để tham quan:

• Dogecoin subreddit
• Dogeducation subreddit
• Discord
• Dogecoin Twitter

Những Câu Hỏi Thường Gặp ❓

Bạn có câu hỏi liên quan đến Dogecoin? Câu trả lời có lẽ đã có trong phần FAQ hoặc Q&A section của hội đồng thảo luận!

Giấy phép ⚖️

Dogecoin Core được phát hành theo các điều khoản của giấy phép MIT. Xem COPYING để biết thêm thông tin hoặc xem opensource.org