this is a very rare, irreversible bug in the order matching (normally bugs like this are reversible, but not BTCpay
Can you perhaps explain what exactly the issue is? Or is it buried somewhere a couple of pages back in the forum?
Sure:
https://bt.irlbtc.com/view/395761.msg4957701#msg4957701Basically, the rounding code for master and develop was different, so BTCpays for one did not match the other, and went to the wrong accounts (still Counterparty accounts though). As I understand, such a thing will probably almost never happen in the future again, because BTCpay (the only protocol-level irreversible part of Counterparty, besides proof-of-burn) and the rounding issues have been addressed permanently.
Note I said almost never.This event is sort of like Counterparty's version of Bitcoin's infamous
blockchain fork. (though since we don't have mining, the analogy is tenuous). [Devs correct me on this]. Fortunately it happened early on, as opposed to when it happened for bitcoin.
I don't get it. When I ran "counterpartyd market" I saw that I had a match for my order along with an order match id. So I did a "counterpartyd btcpay --order-match-id <the id>". A bit later, I did a "counterpartyd wallet" and saw the XCP nicely reported. Except for the little, quite disturbing fact that they were not actually in my wallet at all.
So "counterpartyd wallet" has been lying about the amount of XCP in my wallet. How could that happen? Even for alpha software, that's a bit unsettling.
And also, a comment to this being a "rounding error". The hashes are just large integer numbers. Rounding does not apply at all, at least not the rounding of the floating-point variety. If the devs say it's a rounding issue, do they really understand the issue at all? I'd really like to know more about this issue, if only to know if it might still be there. Right now I am not confident it's resolved, to be honest.
EDIT: not implying the devs don't know what they're doing. What they did was brilliant - just commenting on this one issue.