--- Log opened Wed Feb 22 00:00:52 2023
06:35 < josie> sipa: per w0xlt's explanation, we are using a hash of the outpoints so that the sender doesn't derive the same recipient address when making repeated payments from the same pubkey(s). the hash is not to prevent an attack because it is already trivial for a sender to force address reuse by just remembering which addresses it has used for a customer and reusing them in subsequent
06:35 < josie> transactions. the hash is to prevent "accidental" address reuse
06:38 < josie> I gave some back of the napkin numbers as to why I think 64 bits should be fine: https://gnusha.org/silentpayments/2023-02-06.log
06:39 < josie> s/customer/recipient/
06:53 < Murch> I actually had an idea for a concern regarding Silent Payments. In the notification-based stealth address schemes you have a clear criteria how to keep funds separate: you know which subkeychain they got sent to and thus can separate different senders and only spend funds by the same sender together. How do you deal with wallet-tagging attacks where someone donates a smallish but not tiny amount to your stealth address? Since no sender information is
06:53 < Murch> transferred, does that constitute a need to keep every UTXO isolated from all others in order to not identify more information about your wallet to a potential surveillant-sender?
06:55 < Murch> I.e. the attacker in this scenario would donate multiple times to a stealth address and observe what UTXOs the donations are spent with.
07:26 < josie> Murch: great point! In this case, the attacker is relying on the common-input-ownership heuristic. To mitigate this, a silent payment wallet would need to spend in ways which break the CIO heuristic, such as coinjoining UTXOs before spending or spending via a payjoin. If using a notification based scheme, the wallet could prevent the attacker from learning about UTXOs from other senders by
07:26 < josie> only spending UTXOs from the same subkeychain together
07:29 < josie> I'd argue that a privacy focused notification based scheme should still coinjoin/payjoin before spending, because the attacker would still know _where_ the recipient is spending the coins, even if they don't learn about UTXOs from other senders
08:40 < w0xlt> Yes I agree. All stealth address schemes require some kind of coinjoin, payjoin or statechain for complete privacy, because senders can always link the funds they themselves send with others in a transaction.
08:44 < w0xlt> josie: A question related to 64-bit hashing.
08:44 < w0xlt> To make the tweak, the secp256k1 lib requires it to be a 32 byte tweak.
08:44 < w0xlt> https://github.com/bitcoin-core/secp256k1/blob/master/src/secp256k1.c#L703
08:45 < w0xlt> So the proposal is to have a 64-bit hash and fill the other 192 bits with 0 when tweaking?
09:22 < josie> w0xlt: huh, interesting. I think that should be fine? is it be possible to just assign the 64 bit hash to a uint256 type?
10:21 < w0xlt> josie: I think uint256 represents a vector of uint8_t with size 32.
10:21 < w0xlt> To represent 64 bits, it would be a vector of uint8_t with size 8.
10:21 < w0xlt> But you can manually assign the 64-bit hash to a uint256 type as long as you define what to do with the remaining bits. That's why I suggested padding with 0.
10:25 < w0xlt> But secp256k1 is a separate library from Bitcoin Core. 
10:25 < w0xlt> The `secp256k1_ec_seckey_tweak_mul` function requires the `tweak32` parameter to be a 32-byte array. This does not use and is not aware of the `uint256` data structure.
10:25 < w0xlt> The requirement is just a 32-byte C-style array.
10:30 < sipa> in fact the encoding is different
10:31 < josie> w0xlt: gotcha, that makes sense. I think padding should be fine, certainly for a PoC.
10:37 < josie> sipa: is there a reason `secp256k1_ec_seckey_tweak_mul` only allows for a 32-byte tweak, or is it just that's been the only use case so far?
10:38 < sipa> I don't think you should ever have anything but a uniformly random tweak.
10:38 < sipa> I haven't analyzed what you're doing and it may be fine, but using a smaller range smells like a red flag to me.
10:40 < sipa> But that tweak_mul function was effectively created specifically to support BIP38.
10:41 < sipa> I think if we'd do it today, we'd instead add a bip38 specific module, rather than such a weird low-level operation (it's really an exception compared to most libsecp256k1 functions in how low-level the tweak_add and tweak_mul operations are).
10:44 < josie> sipa: thanks, that's helpful context
11:42 < w0xlt> This is an example:
11:43 < w0xlt> uint256 hash:                        bd37fdb110dc3df7435c4bb6a3d95e297ce4e620768fd100730538e519f9cc65
11:43 < w0xlt> truncated to 64-bit hash: bd37fdb110dc3df700000000000000000000000000000000000000000000000000000000000
11:44 < w0xlt> ---
11:44 < w0xlt> bd37fdb110dc3df7435c4bb6a3d95e297ce4e620768fd100730538e519f9cc65                    
11:44 < w0xlt> bd37fdb110dc3df7000000000000000000000000000000000000000000000000
11:45 < w0xlt> According to this proposal, it is enough to send the 64 bits to the client.
11:45 < w0xlt> This is the idea?
11:45 < sipa> Could you take the 64-bit value, hash it again (resulting in a 256-bit value), and then use that 256-bit value as tweak?
11:46 < sipa> That feels much less footgunny, but again - I don't know if it matters.
11:49 < w0xlt> Seems to be a very interesting approach. The node can send 64 bits to the client and the client hashes to 256 bits.
21:40 < w0xlt> ---
21:41 < w0xlt> Updated the PR to change `getsilentpaymentblockdata` to send the truncated 8 byte hash to clients instead of 32 byte.
21:41 < w0xlt> I also added a new unit test, which validates specific addresses, which can be used as test vectors in BIP.
21:42 < w0xlt> The reason for this test is that I have also released a silent payment rust library.
21:42 < w0xlt> https://github.com/w0xlt/silentpayment-lib
21:43 < w0xlt> This can make easier for building silent payment clients, BDK integration and even an Electrs fork.
21:43 < w0xlt> So the lib and the Core implementation have the same test vector. This ensures interoperability.
23:41 < josie> sipa, w0xlt: sending the 64-bits and then hashing sounds much more straightforward than truncating and padding
23:42 < josie> w0xlt: the rust library looks awesome! also nice to have two implementations of the spec with test vectors. should help us catch any strange edge cases
--- Log closed Thu Feb 23 00:00:53 2023