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.
Function | mainnet | testnet | regtest |
---|---|---|---|
P2P | 22556 | 44556 | 18444 |
RPC | 22555 | 44555 | 18332 |
Ongoing development - Moon plan 🌒
Dogecoin Core is an open source and community driven software. The development process is open and publicly visible; anyone can see, discuss and work on the software.
Main development resources:
- GitHub Projects is used to follow planned and in-progress work for upcoming releases.
- GitHub Discussion is used to discuss features, planned and unplanned, related to both the development of the Dogecoin Core software, the underlying protocols and the DOGE asset.
- Dogecoindev subreddit
Version strategy
Version numbers are following major.minor.patch
semantics.
Branches
There are 3 types of branches in this repository:
- master: Stable, contains the latest version of the latest major.minor release.
- maintenance: Stable, contains the latest version of previous releases, which are still under active maintenance. Format:
<version>-maint
- development: Unstable, contains new code for planned releases. Format:
<version>-dev
Master and maintenance branches are exclusively mutable by release. Planned releases will always have a development branch and pull requests should be submitted against those. Maintenance branches are there for bug fixes only, please submit new features against the development branch with the highest version.
Contributing 🤝
If you find a bug or experience issues with this software, please report it using the issue system.
Please see the contribution guide to see how you can participate in the development of Dogecoin Core. There are often topics seeking help where your contributions will have high impact and get very appreciation. wow.
Communities 🚀🍾
You can join the communities on different social media. To see what's going on, meet people & discuss, find the latest meme, learn about Dogecoin, give or ask for help, to share your project.
Here are some places to visit:
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:
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:
Block | Reward in Dogecoin |
---|---|
1–99,999 | 0–1,000,000 |
100,000–144,999 | 0–500,000 |
145,000–199,999 | 250,000 |
200,000–299,999 | 125,000 |
300,000–399,999 | 62,500 |
400,000–499,999 | 31,250 |
500,000–599,999 | 15,625 |
600,000+ | 10,000 |
The original block reward schedule, with one-minute block targets and four-hour difficulty readjustment:
Block | Reward in Dogecoin |
---|---|
1–99,999 | 0–1,000,000 |
100,000–199,999 | 0–500,000 |
200,000–299,999 | 0–250,000 |
300,000–399,999 | 0–125,000 |
400,000–499,999 | 0–62,500 |
500,000–599,999 | 0–31,250 |
600,000+ | 10,000 |
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
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 node's 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.0BIP 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.0BIP 66
: The strict DER rules and associated version 3 blocks have been implemented since v1.10.0BIP 70
71
72
: Payment Protocol support has been available in Dogecoin Core GUI since v1.7.0BIP 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.7-dev (as of aa53a0d7) Tested on: Fedora 35-39 (x86 & ARM)
Build requirements
sudo dnf install gcc-c++ libtool which diffutils make autoconf automake \
openssl-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
.
Building dogecoin-qt 1.14 on MacOS
Tested on MacOs Ventura and Sonoma on Intel (x86_64) and Apple Silicon (arm64) macs.
Clone dogecoin locally, or check it out, etc.
git clone https://github.com/dogecoin/dogecoin.git
Set up OSX basic build dependencies.
Install xcode-select commandline utils.
xcode-select --install
Make sure frameworks dir is properly owned...
sudo mkdir -p /usr/local/Frameworks
sudo chown $(whoami):admin /usr/local/Frameworks
Install Brew. (If you already have Brew installed, perform a brew update
.)
git clone https://github.com/Homebrew/brew homebrew
eval "$(homebrew/bin/brew shellenv)"
brew update --force --quiet
chmod -R go-w "$(brew --prefix)/share/zsh"
Install dependencies via Brew.
brew install autoconf automake libtool miniupnpc openssl pkg-config protobuf@21 \
qt5 zeromq qrencode librsvg boost berkeley-db@5 libevent
brew link protobuf@21
Go back to your Dogecoin repo
cd ~/dogecoin
./autogen.sh
./configure --with-gui=qt5 --with-boost=`brew --prefix boost`
make
Go have a beverage.
make install
Go have another beverage.
Run it.
/usr/local/bin/dogecoin-qt
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
-
Clone the dogecoin source code and cd into
dogecoin
git clone https://github.com/dogecoin/dogecoin cd dogecoin
-
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
-
It is recommended to build and run the unit tests:
make check
-
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.
- Make sure you installed everything through Homebrew mentioned above
- Do a proper ./configure --enable-debug
- In Qt Creator do "New Project" -> Import Project -> Import Existing Project
- Enter "dogecoin-qt" as project name, enter src/qt as location
- Leave the file selection as it is
- Confirm the "summary page"
- In the "Projects" tab select "Manage Kits..."
- Select the default "Desktop" kit and select "Clang (x86 64bit in /usr/bin)" as compiler
- Select LLDB as debugger (you might need to set the path to your installation)
- 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.
- Install dependencies
- Build steps
- Build configuration
- ARM Cross-compilation
- OS-specific documentation:
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 :
Library | Purpose | Description |
---|---|---|
libssl | Crypto | Random Number Generation, Elliptic Curve Cryptography |
libboost | Utility | Library for threading, data structures, etc |
libevent | Networking | OS independent asynchronous networking |
Optional dependencies:
Library | Purpose | Description |
---|---|---|
miniupnpc | UPnP Support | Firewall-jumping support |
libdb5.3 | Berkeley DB | Wallet storage (only needed when wallet enabled) |
qt | GUI | GUI toolkit (only needed when GUI enabled) |
protobuf | Payments in GUI | Data interchange format used for payment protocol (only needed when GUI enabled) |
libqrencode | QR codes in GUI | Optional for generating QR codes (only needed when GUI enabled) |
univalue | Utility | JSON parsing and encoding (bundled version will be used unless --with-system-univalue passed to configure) |
libzmq3 | ZMQ notification | Optional, allows generating ZMQ notifications (requires ZMQ version >= 4.x) |
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
Before installing the dependencies, ensure your system is updated and has the latest security patches:
sudo apt-get update
sudo apt-get upgrade
**Required dependencies** :
```bash
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.
- 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
- Install Ubuntu
- Open Microsoft Store and search for "Ubuntu 20.04" or use this link
- Click Install
- Reboot (if prompted)
- Complete Installation
- Open a cmd prompt and type "Ubuntu2004"
- 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.
Some people have reported trouble with these steps and recommend that you apply all relevant Windows updates. Also be sure to enable virtualization in your BIOS if necessary.
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.
Install the general dependencies. First, ensure your system is updated and has the latest security patches.
sudo apt update
sudo apt upgrade
sudo apt-get install build-essential libtool autotools-dev automake pkg-config bsdmainutils curl git
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.
Get the Source Code
To build Dogecoin from source code, you'll need the source code. Either check it out via git
or download
a zip file. (Look at the green "<> Code" button on the Dogecoin GitHub repository).
Make sure this code is available in your Ubuntu directory. If you've unzipped a single downloaded file, you may need to change the permissions of all extracted files with command like:
sudo chmod -R <your_username> .
If you've downloaded via git
, do not use sudo
. Instead prefer something like:
cd $HOME
git clone https://github.com/dogecoin/dogecoin.git
git checkout <branchname>
... where <branchname>
is the name of the branch you want to build, such as
"1.14.7-dev" for the unstable branch or "master" for the most recent stable
release.
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 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.
To identify your version of WSL, run the command:
wsl -l -v
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 # not required when building from release tarball
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:
PATH=$(echo "$PATH" | sed -e 's/:\/mnt.*//g') # strip out problematic Windows %PATH% imported var
cd depends
make HOST=x86_64-w64-mingw32
cd ..
./autogen.sh # not required when building from release tarball
CONFIG_SITE=$PWD/depends/x86_64-w64-mingw32/share/config.site ./configure --prefix=/
make
In either case, be aware that if the first make
invocation fails, you will see further errors during the ./configure
and second make
stages. Please
report any errors with this in mind.
Also be careful using the -j
flag with any make
command. People have reported strange compilation errors when doing so.
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
Ensure that this toolchain can build for posix
(else you may have compilation errors for Dogecoin's dependencies):
sudo update-alternatives --config i686-w64-mingw32-g++
Choose the posix
option (instead of auto
or win32
), and continue. 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 fornamespace
. - No extra spaces inside parenthesis; don't do ( this )
- No space after function names; one space after
if
,for
andwhile
. - 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 overi++
.
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 pointerpwalletMain
can be NULL. Seeqa/rpc-tests/disablewallet.py
for functional tests exercising the API with-disablewallet
- Rationale: In RPC code that conditionally uses the wallet (such as
-
Include
db_cxx.h
(BerkeleyDB header) only whenENABLE_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
- 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
-
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
- Rationale:
-
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. Usevch.data()
andvch.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
char
s, or even betteruint8_t
andint8_t
. Do not use barechar
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
versusLogPrintf
.LogPrint
takes acategory
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
- Rationale: C++ string handling is marginally safer, less scope for
buffer overflows and surprises with
-
Use
ParseInt32
,ParseInt64
,ParseUInt32
,ParseUInt64
,ParseDouble
fromutilstrencodings.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 bracesOK:
{
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 asstd::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
andgit 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 usinggit fetch --all
orgit fetch upstream-pull
. Afterwards, you can useupstream-pull/NUMBER/head
in arguments togit 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.
-
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.
-
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.
-
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.
-
The results may not be served with a DNS TTL of less than one minute.
-
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.
-
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)).
-
Operators are encouraged, but not required, to publicly document the details of their operating practices.
-
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
Feature | Configure flag | Description |
---|---|---|
Scrypt SSE2 | --enable-scrypt-sse2 | SSE2 asm for Scrypt functions |
SHA ARMv8 | --with-armv8-crypto | SHA1/256 intrinsics for ARMv8-crypto capable processors |
SHA ARMv82 | --with-armv82-crypto | SHA512 intrinsics for ARMv8.2-crypto capable processors |
SHA AVX2 | --with-intel-avx2 | SHA1/256/512 intrinsics using Intel AVX2 extensions, depends on intel-ipsec-mb |
Requirements
- An experimental feature shall be controlled by a configuration flag inside
configure.ac
that explicitly enables the feature. - The feature shall by default be disabled.
- The feature shall call the
DOGECOIN_REQUIRE_EXPERIMENTAL
macro inconfigure.ac
, to enforce that--enable-experimental
was passed. - All code blocks related to the feature shall be guarded by a preprocessor check on the configuration flag, to prevent leaking code into releases.
- Inside each experimental code block, a call shall be made to the
DOGECOIN_REQUIRE_EXPERIMENTAL
macro fromsupport/experimental.h
, to clearly mark the code as experimental and ease review and troubleshooting. - 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
The data directory is the default location where the Dogecoin Core files are stored.
- The default data directory paths for supported platforms are:
Platform | Data directory path |
---|---|
Linux | $HOME/.dogecoin/ |
macOS | $HOME/Library/Application Support/Dogecoin/ |
Windows | %APPDATA%\Dogecoin\ [1] |
-
A custom data directory path can be specified with the
-datadir
option. -
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:
Chain | Data directory path |
---|---|
(default) | path_to_datadir/ |
-testnet | path_to_datadir/testnet3/ |
-regtest | path_to_datadir/regtest/ |
Data directory layout
Subdirectory | File(s) | Description |
---|---|---|
blocks/ | Blocks directory | |
blocks/index/ | LevelDB database | Block and transaction indices |
blocks/ | blkNNNNN.dat | Actual blocks (in network format, dumped in raw on disk, 128 MiB per file) |
blocks/ | revNNNNN.dat | Block undo data (custom format) |
chainstate/ | LevelDB database | Blockchain state, a.k.a UTXO database |
./ | anchors.dat | Anchor IP address database, created on shutdown and deleted at startup. Anchors are last known outgoing block-relay-only peers that are tried to re-connect to on startup |
./ | banlist.dat | Stores the IPs/subnets of banned nodes |
./ | dogecoin.conf | User-defined configuration settings for dogecoind or dogecoin-qt ; can be specified by -conf option |
./ | dogecoind.pid | Stores the process ID (PID) of dogecoind or dogecoin-qt while running; can be specified by -pid option |
./ | debug.log | Contains debug information and general logging generated by dogecoind or dogecoin-qt |
./ | fee_estimates.dat | Stores statistics used to estimate smart transaction fees and priorities required for confirmation |
./ | mempool.dat | Dump of the mempool's transactions |
./ | onion_private_key | Cached Tor onion service private key for -listenonion option |
./ | peers.dat | Peer IP address database |
./ | .cookie | Session RPC authentication cookie; if used, created at start and deleted on shutdown; can be specified by -rpccookiefile option |
./ | .lock | Data directory lock file |
./ | db.log | BDB error file |
./ | wallet.dat | Personal wallet (a BDB database) with keys and transactions |
./ | .walletlock | BDB wallet lock file |
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:
Path | Description |
---|---|
blktree/ | Blockchain index; replaced by blocks/index/ in 1.10.0 |
coins/ | Unspent transaction output database; replaced by chainstate/ in 1.10.0 |
blkindex.dat | Blockchain index BDB database; replaced by {chainstate/ , blocks/index/ , blocks/revNNNNN.dat } in 1.10.0 |
blk000?.dat | Block data (custom format, 2 GiB per file); replaced by blocks/blkNNNNN.dat in 1.10.0 |
addr.dat | Peer IP address BDB database; replaced by peers.dat in 1.7.0 |
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 typingPATH=$PATH:/path/to/executables
, or prepend the full path to the command like:shibetoshi:~$ /path/to/dogecoin-cli [arguments ...]
Table of contents
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 (withoutdogecoin-cli
) by going toHelp -> Debug window
and inside the popup window selecting the tabConsole
.
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 ofD
, 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
ordogecoin-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 :
Platform | Data directory path |
---|---|
Linux | $HOME/.dogecoin |
macOS | $HOME/Library/Application Support/Dogecoin |
Windows | %APPDATA%\Dogecoin |
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:
Function | mainnet | testnet | regtest |
---|---|---|---|
P2P | 22556 | 44556 | 18444 |
RPC | 22555 | 44555 | 18332 |
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
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
- 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.
- 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
.
- 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
- 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.
- 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 to450
. 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.
- The minimum value for
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 is300
.- 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.
- The minimum value for
-
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.
- 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
-
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 to4
.
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.9 is now available from:
https://github.com/dogecoin/dogecoin/releases/tag/v1.14.9/
This is a new minor version release that contains important bugfixes. Dogecoin users on any platform 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
Compatibility
Dogecoin Core is extensively tested on Ubuntu Server LTS, macOS and Windows. Minimum OS compatibility can be found in the INSTALL guide.
Notable changes
Important updates have been added that solve upstream bugs from Bitcoin Core and Namecoin Core that were inherited by Dogecoin Core.
Known Issues
Compiling on FreeBSD 14.1 may cause an error with endian-specific functions. See https://github.com/dogecoin/dogecoin/issues/3673 for a full description and workaround.
Credits
Credit goes to all awesome contributors to this release, alphabetically:
- chromatic
- Dakoda Greaves
- Daniel Kraft
- Niklas Goegge
- Michi Lumin
- Patrick Lodder
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
totrue
src/clientversion.h
: (this mirrorsconfigure.ac
- see issue #3539)CLIENT_VERSION_MAJOR
CLIENT_VERSION_MINOR
CLIENT_VERSION_REVISION
- Don't forget to set
CLIENT_VERSION_IS_RELEASE
totrue
doc/README.md
anddoc/README_windows.txt
doc/Doxyfile
:PROJECT_NUMBER
contains the full versioncontrib/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:
- source tarball (
dogecoin-${VERSION}.tar.gz
) - linux 32-bit and 64-bit dist tarballs (
dogecoin-${VERSION}-linux[32|64].tar.gz
) - 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
) - OS X unsigned installer and dist tarball (
dogecoin-${VERSION}-osx-unsigned.dmg
,dogecoin-${VERSION}-osx64.tar.gz
) - 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!
RPC method maturity
This document records the maturity of each method made available by the Dogecoin Core RPC. Maturity is expressed over 3 stages:
- UNSTABLE - These methods are often new, and can change within minor version updates.
- STABLE - These methods can be used safely and will not see breaking changes on minor version updates.
- DEPRECATED - These methods are no longer recommended to be used and may be removed in future versions.
method | Maturity | Comment |
---|---|---|
abandontransaction | STABLE | |
addmultisigaddress | STABLE | |
addnode | STABLE | |
addwitnessaddress | UNSTABLE | Not functional yet |
backupwallet | UNSTABLE | Breaking change since 1.14.6 |
bumpfee | STABLE | |
clearbanned | STABLE | |
createauxblock | STABLE | |
createmultisig | STABLE | |
createrawtransaction | STABLE | |
decoderawtransaction | STABLE | |
decodescript | STABLE | |
disconnectnode | STABLE | |
dumpprivkey | STABLE | |
dumpwallet | UNSTABLE | Breaking change since 1.14.6 |
encryptwallet | STABLE | |
estimatefee | UNSTABLE | Brought back from deprecation since 1.14.7 |
estimatepriority | DEPRECATED | To be replaced with estimatefee |
estimatesmartfee | UNSTABLE | Brought back from deprecation since 1.14.7 |
estimatesmartpriority | DEPRECATED | To be replaced with estimatesmartfee |
fundrawtransaction | STABLE | |
generate | STABLE | |
generatetoaddress | STABLE | |
getaccount | DEPRECATED | Deprecated since 1.14.0 |
getaccountaddress | DEPRECATED | Deprecated since 1.14.0 |
getaddednodeinfo | STABLE | |
getaddressesbyaccount | DEPRECATED | Deprecated since 1.14.0 |
getauxblock | STABLE | |
getbalance | STABLE | |
getbestblockhash | STABLE | |
getblock | STABLE | |
getblockchaininfo | STABLE | |
getblockcount | STABLE | |
getblockhash | STABLE | |
getblockheader | STABLE | |
getblockstats | UNSTABLE | Introduced in 1.14.7 |
getblocktemplate | STABLE | |
getchaintips | STABLE | |
getconnectioncount | STABLE | |
getdifficulty | STABLE | |
getinfo | DEPRECATED | Deprecated since 1.14.0 |
getmemoryinfo | STABLE | |
getmempoolancestors | STABLE | |
getmempooldescendants | STABLE | |
getmempoolentry | STABLE | |
getmempoolinfo | STABLE | |
getmininginfo | STABLE | |
getnettotals | STABLE | |
getnetworkhashps | STABLE | |
getnetworkinfo | STABLE | |
getnewaddress | STABLE | |
getpeerinfo | STABLE | |
getrawchangeaddress | STABLE | |
getrawmempool | STABLE | |
getrawtransaction | STABLE | |
getreceivedbyaccount | DEPRECATED | Deprecated since 1.14.0 |
getreceivedbyaddress | STABLE | |
gettransaction | STABLE | |
gettxout | STABLE | |
gettxoutproof | STABLE | |
gettxoutsetinfo | STABLE | |
getunconfirmedbalance | STABLE | |
getwalletinfo | STABLE | |
help | STABLE | |
importaddress | STABLE | |
importmulti | STABLE | |
importprivkey | STABLE | |
importprunedfunds | STABLE | |
importpubkey | STABLE | |
importwallet | STABLE | |
keypoolrefill | STABLE | |
listaccounts | DEPRECATED | Deprecated since 1.14.0 |
listaddressgroupings | STABLE | |
listbanned | STABLE | |
listlockunspent | STABLE | |
listreceivedbyaccount | DEPRECATED | Deprecated since 1.14.0 |
listreceivedbyaddress | STABLE | |
listsinceblock | STABLE | |
liststucktransactions | STABLE | |
listtransactions | STABLE | |
listunspent | STABLE | |
lockunspent | STABLE | |
move | DEPRECATED | Deprecated since 1.14.0 |
ping | STABLE | |
preciousblock | STABLE | |
prioritisetransaction | STABLE | |
pruneblockchain | STABLE | |
removeprunedfunds | STABLE | |
rescan | STABLE | |
sendfrom | STABLE | |
sendmany | STABLE | |
sendrawtransaction | STABLE | |
sendtoaddress | STABLE | |
setaccount | STABLE | |
setban | STABLE | |
setmaxconnections | UNSTABLE | New since 1.14.6 |
setnetworkactive | STABLE | |
settxfee | STABLE | |
signmessage | STABLE | |
signmessagewithprivkey | STABLE | |
signrawtransaction | STABLE | |
stop | STABLE | |
submitauxblock | STABLE | |
submitblock | STABLE | |
validateaddress | STABLE | |
verifychain | STABLE | |
verifymessage | STABLE | |
verifytxoutproof | STABLE |
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 thescriptPubKey
.const unsigned char *txTo
- The transaction with the input that is spending the previous output.unsigned int txToLen
- The number of bytes for thetxTo
.unsigned int nIn
- The index of the input intxTo
that spends thescriptPubKey
.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) subscriptsdogecoinconsensus_SCRIPT_FLAGS_VERIFY_DERSIG
- Enforce strict DER (BIP66) compliancedogecoinconsensus_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 ofdogecoinconsensus_verify_script
for the verification status)dogecoinconsensus_ERR_TX_INDEX
- An invalid index fortxTo
dogecoinconsensus_ERR_TX_SIZE_MISMATCH
-txToLen
did not match with the size oftxTo
dogecoinconsensus_ERR_DESERIALIZE
- An error deserializingtxTo
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.
- 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
- 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
- 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.
- 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.
python contrib/devtools/update-translations.py
- Update
src/qt/bitcoin_locale.qrc
manually or vials src/qt/locale/*ts|xargs -n1 basename|sed 's/\(bitcoin_\(.*\)\).ts/<file alias="\2">locale\/\1.qm<\/file>/'
- Update
src/Makefile.qt.include
manually or vials src/qt/locale/*ts|xargs -n1 basename|sed 's/\(bitcoin_\(.*\)\).ts/ qt\/locale\/\1.ts \\/'
git add
new translations fromsrc/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:
- Open
bitcoin_en.ts
in Qt Linguist (included in the Qt SDK) - Search for
%n
, which will take you to the parts in the translation that use plurals - Look for empty
English Translation (Singular)
andEnglish Translation (Plural)
fields - Add the appropriate strings for the singular and plural form of the base string
- Mark the item as done (via the green arrow symbol in the toolbar)
- Repeat from step 2, until all singular and plural forms are in the source file
- 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
): usetr("...")
-
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 re-translated 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.
Função | mainnet | testnet | regtest |
---|---|---|---|
P2P | 22556 | 44556 | 18444 |
RPC | 22555 | 44555 | 18332 |
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:
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端口暴露给公共网络。
功能 Function | 主网络 mainnet | 测试网络 testnet | 回归测试 regtest |
---|---|---|---|
P2P | 22556 | 44556 | 18444 |
RPC | 22555 | 44555 | 18332 |
进行中的开发 - 月球计划 🌒
狗狗币内核是一个社区驱动的开源软件。其开发过程是开放的并公开可见的。任何人都可以查看,讨论和使用该软件。
主要开发资料:
- 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)。
社区 🚀🍾
您能通过不同的社交媒体加入狗狗币社区。在那里您可以看到最近的新闻,与别人见面和讨论,找到最新的表情包,进一步了解狗狗币,帮忙别人或者请求帮忙,分享您的项目。
以下是一些社区的访问链接:
灰常常见的问题 ❓
如果对狗狗币有问题,答案很可能已经在常见问答或者问与答!里了。
许可证 - 灰常的许可 ⚖️
狗狗币内核是根据MIT许可条款发布的。更多相关信息,请参阅COPYING或者查看opensource.org
Dogecoin Core [DOGE, Ð]
Dogecoin est une crypto-monnaie communautaire qui s'inspire d'un mème de Shiba Inu. Le logiciel Dogecoin Core permet à quiconque d'exploiter un nœud dans les réseaux de la blockchain Dogecoin et utilise la méthode de hachage Scrypt pour la preuve de travail. Il est adapté de Bitcoin Core et d'autres crypto-monnaies.
Pour plus d'informations sur les frais par défaut utilisés sur le réseau Dogecoin, veuillez consulter la recommandation sur les frais.
Site web: dogecoin.com
Utilisation 💻
Pour commencer votre voyage avec Dogecoin Core, consultez le guide d'installation et le tutoriel de démarrage.
L'API JSON-RPC fournie par Dogecoin Core est auto-documentée et peut être parcourue avec dogecoin-cli help
, tandis que des informations détaillées pour chaque commande peuvent être visualisées avec dogecoin-cli help <command>
. Vous pouvez également consulter la documentation Bitcoin Core - qui implémente un protocole similaire - pour obtenir une version consultable.
Les ports
Dogecoin Core utilise par défaut le port 22556
pour la communication pair-à-pair qui est nécessaire pour synchroniser la blockchain au "mainnet" et rester informé des nouvelles transactions et blocs. De plus, un port JSONRPC peut être ouvert, dont par défaut le port 22555
est utilisé pour les nœuds du réseau principal. Il est fortement recommandé de ne pas exposer les ports RPC à l'Internet public.
Function | mainnet | testnet | regtest |
---|---|---|---|
P2P | 22556 | 44556 | 18444 |
RPC | 22555 | 44555 | 18332 |
Développement continu - Moon plan 🌒
Dogecoin Core est un logiciel libre et communautaire. Le processus de développement est ouvert et publiquement visible; tout le monde peut voir, discuter et travailler sur le logiciel.
Principales ressources de développement :
-
GitHub Projects est utilisé pour suivre les travaux prévus et en cours pour les prochaines versions.
-
GitHub Discussion est utilisé pour discuter des caractéristiques, planifiées et non planifiées, liées à la fois au développement du logiciel Dogecoin Core, les protocoles sous-jacents et l'actif DOGE.
Stratégie de version
Les numéros de version suivent la sémantique major.minor.patch
.
Branches
Il y a 3 types de branches dans ce référentiel :
- master: Stable, contient la dernière version de la dernière major.minor version.
- maintenance: Stable, contient la dernière version des versions précédentes, qui sont toujours en maintenance active. Format :
<version>-maint
- development: Instable, contient du nouveau code pour les versions prévues. Format :
<version>-dev
Les branches master et de maintenance sont exclusivement mutables par version. Les versions planifiées auront toujours une branche de développement et les demandes de pull doivent être soumises dans cette branche. Les branches de maintenance ne sont là seulement pour corriger les bugs, veuillez soumettre les nouvelles fonctionnalités dans la branche de développement avec la version la plus récente.
Contribution🤝
Si vous trouvez un bug ou rencontrez des problèmes avec ce logiciel, veuillez le signaler en utilisant le système de gestion des problèmes.
Veuillez consulter le guide de contribution pour voir comment vous pouvez participer au développement de Dogecoin Core. Il y a souvent des sujets demandant de l'aide où vos contributions auront un impact considérable et seront très appréciées. wow.
Communautés 🚀🍾
Vous pouvez rejoindre les communautés sur différents réseaux sociaux. Pour voir ce qu'il se passe, rencontrer des gens et discuter, trouver le dernier mème, apprendre sur le Dogecoin, donner ou demander de l'aide, pour partager votre projet.
Voici quelques endroits à visiter :
Questions très fréquemment posées ❓
Vous avez une question concernant le Dogecoin ? Une réponse se trouve peut-être déjà dans la FAQ ou dans la section Q&R du forum de discussion !
License - Much license ⚖️
Dogecoin Core est publié sous les termes de la licence MIT. Voir COPYING pour plus d'informations ou voir 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 در شبکهی اینترنت عمومی قابل دسترسی نباشند.
کاربرد | شبکهی اصلی | شبکهی آزمایشی | درخواست |
---|---|---|---|
P2P | 22556 | 44556 | 18444 |
RPC | 22555 | 44555 | 18332 |
توسعهی در حال انجام - نقشهی فتح ماه 🌒
پروژهی 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 Trabalho. É 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 atualizadas de 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.
Função | mainnet | testnet | regtest |
---|---|---|---|
P2P | 22556 | 44556 | 18444 |
RPC | 22555 | 44555 | 18332 |
Desenvolvimento continuo - Plano 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 planeados 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:
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.
Function | mainnet | testnet | regtest |
---|---|---|---|
P2P | 22556 | 44556 | 18444 |
RPC | 22555 | 44555 | 18332 |
Đ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:
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