quoting nevent1q…0nvpit seems that the bug ultimately comes down to this line: "https://github.com/ElementsProject/elements/blob/c7e856fab1b0c4d37005e25c0940184d812a26a0/src/script/sigcache.cpp#L60 " . range proofs that hit the cache that is keyed to this hash, are counted as valid without checking. the problem is that the data fed into the hash is not length checked. so you can feed different (proof, commitment, asset) tuples into it by varying the length of the proof. the proof can be totally invalid and it'll still come back as valid. and this explains why OP_RETURN is involved: you need an extra output to sort of 'consume' the invalid amount. so you make a totally valid output of 4000 btc and you shove the negative corresponding value in the OP_RETURN. Apparently the anomalous size of the proof confirms this reading (bulletproofs rangeproofs have specific sizes based on the bit range 0..2^k). The only part I don't get is why there was a consensus deviation. Did some nodes have the rangeproof caching disabled or something?
The reason I got convinced is that this theory matches the size of the "garbage proof".