sikkienl/dash
1
0
Fork 0
mirror of https://github.com/dashpay/dash.git synced 2024-12-25 12:02:48 +01:00
Code Issues Actions Packages Projects Releases Wiki Activity
Dash - Reinventing Cryptocurrency
19,233 Commits 24 Branches 554 Tags 573 MiB
C++ 52.7%
C 24.2%
Python 10.5%
Assembly 3.3%
JavaScript 2.6%
Other 6.5%
370ec04a02
Go to file
Wladimir J. van der Laan 370ec04a02
Merge #13002: Do not treat bare multisig outputs as IsMine unless watched 
7d0f80b Use anonymous namespace instead of static functions (Pieter Wuille)
b61fb71 Mention removal of bare multisig IsMine in release notes (Pieter Wuille)
9c2a8b8 Do not treat bare multisig as IsMine (Pieter Wuille)
08f3228 Optimization: only test for witness scripts at top level (Pieter Wuille)
3619735 Track difference between scriptPubKey and P2SH execution in IsMine (Pieter Wuille)
ac6ec62 Switch to a private version of SigVersion inside IsMine (Pieter Wuille)
19fc973 Do not expose SigVersion argument to IsMine (Pieter Wuille)
fb1dfbb Remove unused IsMine overload (Pieter Wuille)
952d821 Make CScript -> CScriptID conversion explicit (Pieter Wuille)

Pull request description:

  Currently our wallet code will treat bare multisig outputs (meaning scriptPubKeys with multiple public keys + `OP_CHECKMULTISIG` operator in it) as ours without the user asking for it, as long as all private keys in it are in our wallet.

  This is a pointless feature. As it only works when all private keys are in one place, it's useless compared to single key outputs (P2PK, P2PKH, P2WPKH, P2SH-P2WPKH), and worse in terms of space, cost, UTXO size, and ability to test (due to lack of address format for them).

  Furthermore, they are problematic in that producing a list of all `scriptPubKeys` we accept is not tractable (it involves all combinations of all public keys that are ours). In further wallet changes I'd like to move to a model where all scriptPubKeys that are treated as ours are explicit, rather than defined by whatever keys we have. The current behavior of the wallet is very hard to model in such a design, so I'd like to get rid of it.

  I think there are two options:
  * Remove it entirely (do not ever accept bare multisig outputs as ours, unless watched)
  * Only accept bare multisig outputs in situations where the P2SH version of that output would also be acceptable

  This PR implements the first option. The second option was explored in #12874.

Tree-SHA512: 917ed45b3cac864cee53e27f9a3e900390c576277fbd6751b1250becea04d692b3b426fa09065a3399931013bd579c4f3dbeeb29d51d19ed0c64da75d430ad9a
2021-06-05 22:13:00 +03:00
.github Update docker tags (#4103) 2021-04-17 16:08:45 -04:00
.tx Merge remote-tracking branch 'bitcoin/0.12' into HEAD 2016-02-06 16:48:04 +03:00
build-aux/m4 Merge #18591: Add C++17 build to Travis 2021-04-23 20:02:35 +05:30
ci bls|ci: Fix C++17 build, add it to CI (#4055) 2021-04-28 16:44:01 +02:00
contrib Merge #14416: Fix OSX dmg issue (10.12 to 10.14) 2021-05-25 01:05:41 +03:00
depends depends: Undefine BLSALLOC_SODIUM in bls-dash.mk (#4176) 2021-05-24 21:09:48 -05:00
doc Merge pull request #4178 from UdjinM6/backports-0.17-pr30 2021-06-05 22:08:47 +03:00
docker feat: add tor entrypoint script for use in dashmate (#4182) 2021-06-02 12:54:57 -05:00
share Merge #13617: release: require macOS 10.10+ 2020-12-18 01:14:34 +03:00
src Merge #13002: Do not treat bare multisig outputs as IsMine unless watched 2021-06-05 22:13:00 +03:00
test Partial merge #8499: Add several policy limits and disable uncompressed keys for segwit scripts 2021-06-05 22:12:55 +03:00
.gitattributes
.gitignore trivial|doc: Some trivial housekeeping (#4059) 2021-03-26 13:11:11 +01:00
.gitlab-ci.yml bls|ci: Fix C++17 build, add it to CI (#4055) 2021-04-28 16:44:01 +02:00
.travis.yml Merge #13066: Migrate verify-commits script to python, run in travis 2021-05-06 12:06:09 +03:00
autogen.sh Merge #13454: Make sure LC_ALL=C is set in all shell scripts 2020-07-28 21:35:31 -05:00
CMakeLists.txt refactor: PrivateSend -> CoinJoin + Move the tab (#4038) 2021-03-17 18:36:11 -04:00
configure.ac Merge #13005: Make --enable-debug to pick better options 2021-05-25 14:09:36 +03:00
CONTRIBUTING.md Merge #13165: doc: Mention good first issue list in CONTRIBUTING.md 2021-05-25 14:09:36 +03:00
COPYING Bump copyright year to 2020 (#3290) 2020-01-17 15:42:55 +01:00
INSTALL.md Dashify INSTALL.md and build-unix.md 2018-01-12 16:12:54 +01:00
libdashconsensus.pc.in Merge #7192: Unify product name to as few places as possible 2017-12-11 08:30:26 +01:00
Makefile.am Merge #13254: Remove improper qt/moc_* cleaning glob from the general Makefile 2021-05-25 14:11:35 +03:00
README.md Use build badges provided by Gitlab (#3915) 2021-01-08 13:33:50 -06:00

README.md

Dash Core staging tree 0.17

CI master develop
Gitlab Build Status Build Status

https://www.dash.org

What is Dash?

Dash is an experimental digital currency that enables instant, private payments to anyone, anywhere in the world. Dash uses peer-to-peer technology to operate with no central authority: managing transactions and issuing money are carried out collectively by the network. Dash Core is the name of the open source software which enables the use of this currency.

For more information, as well as an immediately useable, binary version of the Dash Core software, see https://www.dash.org/get-dash/.

License

Dash Core is released under the terms of the MIT license. See COPYING for more information or see https://opensource.org/licenses/MIT.

Development Process

The master branch is meant to be stable. Development is normally done in separate branches. Tags are created to indicate new official, stable release versions of Dash Core.

The contribution workflow is described in CONTRIBUTING.md.

Testing

Testing and code review is the bottleneck for development; we get more pull requests than we can review and test on short notice. Please be patient and help out by testing other people's pull requests, and remember this is a security-critical project where any mistake might cost people lots of money.

Automated Testing

Developers are strongly encouraged to write unit tests for new code, and to submit new unit tests for old code. Unit tests can be compiled and run (assuming they weren't disabled in configure) with: make check. Further details on running and extending unit tests can be found in /src/test/README.md.

There are also regression and integration tests, written in Python, that are run automatically on the build server. These tests can be run (if the test dependencies are installed) with: test/functional/test_runner.py

The Travis CI system makes sure that every pull request is built for Windows, Linux, and OS X, and that unit/sanity tests are run automatically.

Manual Quality Assurance (QA) Testing

Changes should be tested by somebody other than the developer who wrote the code. This is especially important for large or high-risk changes. It is useful to add a test plan to the pull request description if testing the changes is not straightforward.

Translations

Changes to translations as well as new translations can be submitted to Dash Core's Transifex page.

Translations are periodically pulled from Transifex and merged into the git repository. See the translation process for details on how this works.

Important: We do not accept translation changes as GitHub pull requests because the next pull from Transifex would automatically overwrite them again.

Translators should also follow the forum.