-
MooneroFanso i ran into a bit of a quirk. When sending a transfer (1 input) to 2 different addresses (or more?), the txn results in a larger "extra" field
-
MooneroFanTypically, a 1 input / 2 output transaction can be made in the following ways
-
MooneroFanA) sweep to address, which also produces a 'fake' change output
-
MooneroFanB) transfer to address, which sends change back to your main account at index #0
-
MooneroFanC) transfer to 2 addresses, which doesn't produce any change output, provided you're transfering the entire amount of the input (using "subtract_fee_from_outputs")
-
MooneroFanFocus on C) , if we transfer the entire input (split between 2 *distinct* recipient addresses) using the 'transfer' rpc call, we end up with a much longer "extra"
-
MooneroFanfield, which is typically an array of 44 bytes for A) and B). What's interesting is if you transfer the entire input to two copies of the same address, we get the
-
MooneroFannormal length of 44 extra bytes. we only get the long extra array when we transfer to multiple distinct recipient addresses.
-
MooneroFanIs this intended? because it seems like it could be a fingerprint that excludes A) B) and a subset of C)
-
MooneroFanI haven't tried any other combination of #inputs / #outputs, perhaps those can be fingerprinted as well!
-
MooneroFanhmm, getting a sun shades emoticon for " B ) "
-
sech1Transfer to different subaddresses increases tx_extra because of additional pubkeys. If you transfer to addresses starting with 4..., it shouldn't increase.