00:25:07 Just catching up on notes since meeting. Determining block time by orphan rate is relevant if the bottleneck is propagation. The other consideration is verification time. 00:25:27 Hmm, suppose an attacker wants to maximize verification_time/kB 00:25:53 i.e. if I'm going to make 200 kB worth of transactions, how can I maximize the time it takes for nodes to verify it? 00:26:06 s/i.e./e.g./ 00:26:06 Isthmus meant to say: e.g. if I'm going to make 200 kB worth of transactions, how can I maximize the time it takes for nodes to verify it? 00:26:49 Lots of little transactions? Are there things that I can do to increase verification complexity? 00:28:14 Hmm what's (2 minutes)/(average transaction verification time) 00:28:26 (just for a regular transaction, nothing designed to be heavy) 00:28:29 More outputs means higher BP complexity 00:28:49 More inputs means higher LRS complexity 00:29:07 The combination means higher balance check complexity 00:48:46 Interesting 00:49:07 What's the ballpark verification time for a 2-in/2-out? 01:06:13 Completely unrelated, I got caught in the weirdest mystery this afternoon. 01:06:13 So there are >100 transactions whose payment ID is some variation on `fluffypony is the best pony ever` (abbreviated as FITBPE below) 01:06:13 (this has been previously discussed). Weird, but if you’re hardcoding a uPID into some custom wallet, it’s a funny line. 01:06:13 Weirder though: some user/wallet started producing transactions whose PID is almost *but not quite* the base string. In most cases the a single random character is perturbed into a different character (string edit distance = 1) 01:06:14 This is confusing to me - did the transaction creator have the presence of mind to realize that putting the same plaintext string on every transaction is a fungibility defect, and yet think that a single character edit would forever foil analyses? 01:06:17 https://usercontent.irccloud-cdn.com/file/VRyTvaZ8/image.png 01:06:38 In general, regarding the FITBPE transactions, the other fascinating thing is that this doesn’t appear to be a day-to-day wallet… I hypothesize that they were generated by payout software. 01:06:39 If it were a day-to-day wallet, we would expect some of the transaction to include change outputs, which would be externally visible as FITBPE transactions who include ring members that are also from FITBPE transactions. This does not seem to be the case (although I have not exhaustively verified this, feel free to share a counterexample) 01:06:39 Also, we see transactions where FITBPE is duplicated by number of outputs. For example, https://xmrchain.net/search?value=94df27b38c9969e9d81caf76865f03825be8224838c7ea582754d295ea9d2c48 01:06:39 That’s a 1-in/4-out transaction, whose tx_extra contains 4 copies of FITBPE (see repeated `666c75666679706f6e7920697320746865206265737420706f6e792065766572`) 01:06:39 The only way I can make sense of this is if some wallet was tagging all its outgoing outputs with FITBPE or a slightly-edited variant. 01:06:39 I dunno, what are other possible explanations? 04:18:36 Isthmus: on a 2.1 GHz Opteron, a 2-input CLSAG (with balance check) is 21.2 ms to verify, and the per-proof BP (over, for this example, only 4 such proofs) is 7.7 ms 04:18:50 The BP numbers will be lower on a per-proof basis with more proofs in the batch 04:19:17 So something like 25-30 ms 15:59:47 120/(30/1000) ~ 4000 txns/block before validation time > block time 15:59:53 https://www.getmonero.org/resources/developer-guides/wallet-rpc.html#transfer 16:00:04 Does the RPC not support payment IDs? 16:00:29 *sending `transfer` with payment ID 16:01:14 Note that the numbers I provided do not account for database reads, key image checks, and other housekeeping operations... just the major stuff 16:01:22 Might well have been removed. 16:31:27 So I cannot specify an ePID in the transfer? But the wallet will still include include an ePID that is just encrypted 0s? 16:32:02 transfer to integrated address 16:32:38 we don’t want standalone PIDs 16:42:43 You mean subaddresses? 16:49:09 no 16:49:34 maybe I’m missing something :) 16:51:44 No, you made sense. 18:29:13 Oh I see what you mean. From an RPC call perspective 18:29:17 Ignore me :)