Add a setting ensure_ascii to AuthServiceProxy. This setting,
defaulting to True (backwards compatible),
is passed through to json.dumps. If set to False, non-ASCII characters
>0x80 are not escaped. This is useful for testing server
input processing, as well as slightly more bandwidth friendly in case of
heavy unicode usage.
Input: read and validate full UTF-8, both Basic Multilingual Plane
and extended characters.
Collate surrogate pairs as specified in RFC467.
This ensures that UTF-8 strings that reach the application are
always valid.
Output: Assume UTF-8 strings provided for output are valid.
The escaping was broken, fix this by not encoding UTF-8 characters with \u.
Simply write them to the output stream as-is.
This is the right thing to do. See https://www.ietf.org/rfc/rfc4627.txt:
"JSON text SHALL be encoded in Unicode. The default encoding is UTF-8."
Fixes#16.
Also add tests for the new functionality.
strMessage for masternode broadcast (which we sign and verify) looks like this currently:
[2001:1608:45:3::242:ac11:6]:199991464464536
?~}&?Q?S?Ǚ?q ?0??????O?I/Y?(
?f?jJF??m??bssknN??9鲜JXVs?ә?5T?8??????~70200
which I believe in some cases leads to "Got bad Masternode ping signature" errors and banning.
I propose to change the way strMessage is composed so that it looks like this:
[2002:82ff:c04:2:a90f:2261:43c4:2745]:1999514645552319591ec70225aacadfafa4ab5d21e87cdce641fd4030d029485434533c5e481578a9d471089fb5ec170200
Further more nDos for old masternodes is set to 0 to stop false positives (message still gets rejected though).
- use "" account address instead
- remove `collateralPubKey` and `SetCollateralAddress()` from darksend and create `dummyScriptPubkey` and `InitDummyScriptPubkey()` in masternodeman instead
- initialize `dummyScriptPubkey` before loading cache otherwise MNs could be removed because of the invalid tx
If we want to be compatible to 12.0 on network layer we need them back in ppszTypeName[] to keep inv type consistent (allNetMessageTypes[] should not have them, we shouldn't accept non-implmented messages)
- Terrible bug which caused governance objects to have their hashes corrupted, causing objects to become invalid
- More proposal -> governance name changes
- every node should check for "pre-enabled" status of a newly added mn to relay message further (was "enabled" which is wrong - if node is enabled, that's not the first announce, so no need to relay it because most likely we were the one who asked for that mn directly via dseg)
- we should not add ourselves to mn list if announce message has outdated protocol version (report this in log)
- we should remove ourselves from saved list if we start updated mn for the first time and just loaded old list from mncache.dat
- Move heavy `IsVinAssociatedWithPubkey` deep inside of `CheckInputsAndAdd` to be actually executed only once per masternode and only after much simpler checks were executed;
- Verify `GetInputAge` (it uses cache) before trying to enter `AcceptToMemoryPool` (which hash many ifs and checks inside).
