10:42:26 I think Seraphis permits a limited kind of tx chaining. In Seraphis, membership proofs (eg ring signatures) don’t require any special private key material (eg private view/spend keys). All you need is two blinding factors. So, if you are willing to expose the true spends of a transaction, you could offload constructing the membership proofs to a third party, and only prove ownership and construct the key images 10:42:26 locally. This pattern allows tx chaining because you can cache the blinding factors in a ‘partial tx’ structure while waiting for the true spend to be added to the ledger, then use those keys to finish the membership proofs. (assuming membership proofs are not part of the message signed by ownership proofs) 10:43:00 Of course, this would require significant tx malleability, so there may be some danger. 10:49:19 I say limited because it would not solve the confirmation time problem. 11:22:44 I think I found another small issue (not Monero code problem this time). Monero wallet has a quantization mask for transaction fees, so all fees amounts in piconeros are divisible by 10000. But some transactions don't follow this rule, probably from 3rd-party wallets. Examples: https://paste.debian.net/hidden/e69054f6/ 11:23:21 Approximately 0.8% of all transactions are like this 11:38:30 https://teddit.net/r/Monero/comments/nds92u/tracking_suspicious_monero_transactions_twitter/gycjvub/?context=10 11:38:30 It's know and there is even fingerprinting heuristic based on this fact. 11:41:15 "5.4.2 Round fees" 16:23:56 Nice find! 18:14:16 does seraphis somehow magically enforce ring member selection? 18:22:58 No? You can have any kind of membership proof you want. 18:23:11 (more or less) 18:25:09 What are you trying to get at? 18:33:04 When I said ‘expose the true spend’, I only mean exposing it to the third party who will construct your membership proof (eg the counterparty in an atomic swap, who knows the true spend anyway), if that was confusing. 19:12:09 i mean enforce the rules of ring member selection on the protocol level so all wallets use the same rules. 19:12:17 probably not related. 20:00:15 Seraphis does not require any specific ring member selection scheme, you can implement those rules on top if you want. 20:16:34 yeah. thats the problem. ideally we'd have a deterministic ring member selection or something so wallets wouldn't have fingerprints 20:22:02 rehrar posted triptych multisig draft: https://raw.githubusercontent.com/cypherstack/triptych-multisig/main/main.pdf 20:22:19 good news: multisig works, bad news: it's super complex as far as I understand it 20:34:57 This is unfortunate. I don't think multisig will take off if it has high communication complexity. It's the major reason why it isn't used more now. 20:46:47 sarang 20:46:47 > It may be necessary to require a specific commitment round for the autho-rizing proof pre-challenge values. Currently, these values are computed using MuSig-type hash aggregation in order to assert that the resulting aggregated values are uniformly distributed and cannot be controlled by malicious players. 20:46:47 I was under the impression you need a commitment round so no party can control the challenge hash produced. Even if all the alpha signature opening values are hash-prefixed, the challenge can still be controlled if you learn all other participants' alpha values before you define your own. The basic reason is the challenge itself is already a random oracle, so you are doing some kind of guess-and-check on the inputs to 20:46:47 get a useful challenge (in the Wagner attack). 20:46:47 However I don't have a deep understanding of the attack, and may be missing something. 21:37:50 should we set up a time to connect UkoeHB and maybe sarang (if you're free)? 21:49:20 atoc what would you like to talk about? maybe we can handle it asynch