milli- and micro-Dogecoins are below dust threshold so do not make
any sense as display units. Instead, kilo- and mega-dogecoins are
probably more useful, as those make common amounts easier to read
instead of harder
Note that the test address was invalid in Bitcoin Core, and as such rather than
re-encoding as a Dogecoin address, I've simply swapped the first byte. Still
invalid, but looks correct at least.
Introduce a PlatformStyle to handle platform-specific customization of
the UI.
This replaces 'scicon', as well as #ifdefs to determine whether to place
icons on buttons.
The selected PlatformStyle defaults to the platform that the application
was compiled on, but can be overridden from the command line with
`-uiplatform=<x>`.
Also fixes the warning from #6328.
Update QT client messages and translations to Doge equivalents. Where specific contributions
were made in languages for Dogecoin, those translations are used in preference.
1) Maintain a salt to perturbate the address index (protection against
collisions).
2) Add support for address index entries in the block index, and
maintain those if -addrindex is specified. It indexes the use of
every >8-byte data push in output script or consumed script - or in
case of no such push, the entire script.
3) Add a searchrawtransactions RPC call, which can look up raw
transactions by address.
This change makes a node only accept transactions with low-s
signature encoding for relay and mining, but allows transactions
with high-s signature encoding in mined blocks (no blocks will
be rejected)
Pros:
- If deployed by all miners, this will eliminate this particular
malleability attack.
- There is no impact on consensus
Cons:
- Wallets that do not implement low-s signature encoding will
see their transactions be rejected by growing numbers of peers
and ultimately not be able to get any transaction mined.
Follow ups:
- Eventually, this verification needs to be confirmed through a
consensus rule (enforcement of BIP62)