There was a bug where the spending address index could have the same key
as the receiving address index if the input and output indexes matched. This lead
to the output always overwriting the input index leading to incorrect balances
with missing spent amounts. This patch separates the two so that they have unique
keys so balances will be correctly calculated.
51696ac make use of getnameinfo() optional (default: true)
bec39b8 fix mnb sig bug for ipv6 addresses: use pure byte to hex conversion for construction of masternode broadcast signature, better logging
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
