01:49:09 so 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 01:49:09 Typically, a 1 input / 2 output transaction can be made in the following ways 01:49:10 A) sweep to address, which also produces a 'fake' change output 01:49:10 B) transfer to address, which sends change back to your main account at index #0 01:49:11 C) 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") 01:49:11 Focus 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" 01:49:12 field, 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 01:49:12 normal length of 44 extra bytes. we only get the long extra array when we transfer to multiple distinct recipient addresses. 01:49:13 Is this intended? because it seems like it could be a fingerprint that excludes A) B) and a subset of C) 01:49:13 I haven't tried any other combination of #inputs / #outputs, perhaps those can be fingerprinted as well! 01:49:52 hmm, getting a sun shades emoticon for " B ) " 06:13:25 Transfer to different subaddresses increases tx_extra because of additional pubkeys. If you transfer to addresses starting with 4..., it shouldn't increase.