Hey guys,
Sorry about not getting the update in last night (for those following the thread but not on the dev email list my SSD unfortunately died an early death). Replaced, restored & back up and running. Update has just gone in now.
No major feature releases in this update, mainly bugfixes (only visible change of note is Masterchest.info will now display a warning when you're checking your balance if there is a consensus disagreement). Just a little added protection for the community.
Re address 1LjT88X7Zu8BdbqJw8vfRa83NJuzYL9kqm, that's one I'm going to need to investigate further. I haven't yet identified a root cause. Checking my validation output I found two entries for that address. I checked the balances table and the engine has somehow produced a second row for this address and another address with incorrect balances. It's that second entry that's being picked up by the consensus check. There should only ever be one entry for each address in the balances table. I'm in the process of debugging to hunt down how this could have occurred & squish the bug.
Re transaction ecb792bf58c67120d6d62149f542271c33e3df046460aebc2bae1012e5ba52e5, this is invalid according to spec. The data address seqnum is 75, the ref address seqnum is 76, and the change address seqnum is 77.
Ideally, all outputs should be the same (except the change). In fringe cases where the change output value is equal to the other output values the change address can be identified by sequence number, which must not equal or be +/-1 of the sequence number for either the reference address or the data address
Change address is 77, +1 of the reference address. Explicitly invalidated with current wording. Either that paragraph needs to be rewritten or the transaction should be invalidated by you guys. At face value it seems too restrictive when we have P&D available so I'm not against (after testing this is the only tx affected by the change) rewording it to something like:
Ideally, all outputs should be the same (except the change). In fringe cases where the change output value is equal to the other output values the change address may be identified by sequence number, which must not equal or be +1 of the sequence number for the data address
Re transaction c2a904dd47797736617bf5df555f029064de0fc2ff5ba71197638e469caae7f5, good example of whether P&D should be used for
anything decodable. All the outputs are the same AND there are duplicate sequence numbers. But I do agree P&D code can identify the data & reference addresses successfully.
I've got to throw it out there - I think largely the unasked question - where is the value in all these rules for Class A at all if P&D could be used in any decodable scenario?
Essentially P&D requires a valid data packet and a second address with a seqnum +1 that of the data packet for the reference - that's it. Everything else can be discarded if the rules that relate to them are optional. I thus see two viable options really:
1) Allow any P&D decodable transaction to validate. Strip the spec on Class A. Simplify the ruleset and take out everything related to change, same output values etc. All that is required for a valid Class A is a P&D decodeable data packet and another single address with data packet seqnum+1 for the reference (plus an output to Exodus of course).
2) Restrict P&D to specific scenarios. Outline & detail these in the spec via a matrix of valid and invalid cases.
3) Keep the rules as current and allow P&D fallback for any decodable transaction. This is the case that I see no value to, if P&D can always be used, then the rules are not enforced (and thus effectively pointless).
It may seem crazy at first look given how much effort we've expended on supporting Class A, and I'm not necessarily saying I've thought through 1) in detail, but if the end decision does end up being "P&D can be used for anything decodable" then perhaps it's time to throw out all the excess baggage and make P&D
the decoding method rather than a fallback. Would be interesting to see if that changed state at all.
Oh also FYI Tachikoma, consensus check runs at the end of every blockscan update (5 minutes currently) mate.
Thanks
Zathras
