15:02:42 Meeting 2hr 17:01:30 meeting time 17:01:35 https://github.com/monero-project/meta/issues/772 17:01:41 1. greetings 17:01:42 hello 17:01:46 Hi 17:01:55 Hello 17:02:03 Hello 17:02:20 hi 17:04:25 2. updates, what's everyone working on? 17:05:04 Collecting mempool and found block broadcast time for analysis of mining pools' block template update policies. Some analysis of p2pool payout outputs. 17:06:06 no real tangible updates since last week unfortunately - working on (other stuff) and bp++ 17:07:02 Hi. Jamtis checksum + updating the specs. 17:08:07 I read the OSPEAD doc again and started drafting up thoughts / questions. Converting from my own shorthand into comments shortly. 17:08:33 Thanks, isthmus. 17:08:59 Submitted a PR to rbrunner 's PR to optimize pool processing (https://github.com/rbrunner7/monero/pull/4) + been going through balance recovery in the Seraphis lib 17:09:24 me: continued cleanup of the seraphis library. I decided to move all member functions out of C-style structs for a more clean/consistent environment (and to discourage adding member functions in the future). 17:09:50 Yeah, things get so complex that now PR's need PR's :) Thanks jberman[m] 17:12:05 3. discussion 17:13:35 This seraphis design overview basically got no attention - everyone should read it though because this is what monero will get if nothing changes. https://gist.github.com/UkoeHB/f508a6ad973fbf85195403057e87449e 17:14:29 Not sure there was a lack of attention, I just think that it's not that controversial now 17:14:44 I read it and gave comments/questions :P 17:15:19 I read it and was impressed how much will really change, it only becomes clear if you heap it all in one place. 17:15:31 And not merely change of course, but improve 17:16:26 By the way, is there already support in the library for transaction chaining? I guess so, given how modular it is 17:17:08 Rucknium[m]: yes I'm grateful :) 17:17:28 Another question in my mind is how much of the structure would have to change if many years from now we eliminate ring signatures and have an "accumulator model". In other words, how future-proof is the modular Seraphis structure? 17:17:39 rbrunner: more or less, I didn't put a lot of effort into the mock offchain scanning stuff so it may or may not work 17:17:49 the offchain mockups may or may not work * 17:18:37 Ok, it will be hard work to support it "higher up" in wallets anyway, probably not the first thing to implement 17:18:48 Rucknium[m]: it depends on the accumulator model. If they are plug-and-play, doing the same thing as grootle proofs, then it should be easy enough 17:20:00 Amazing work @UkoeHB 17:20:00 /me is very happy about the transaction uniformity improvements 17:20:18 thanks isthmus 17:22:25 hmm are there any other topics to discuss today? 17:23:47 In the seraphis migration workgroup meeting on monday it was basically decided that no additional changes to the jamtis spec are needed to support accounts. Does anyone feel like weighing in today? 17:24:26 its still handled by the blowfish technique .. ? 17:24:57 twofish 17:25:27 I guess I could just read, but my last reading of the spec looked like it was a bit rough because it involved a block cipher in the design too, but it solved lots of existing problems 17:25:44 yes, it uses a block cipher 17:26:09 ah right the upgrade sorry, but I think it was probably worth the change 17:26:11 I'm in the process of updating the specs to match UkoeHB's library 17:26:14 it makes accounts more seamless 17:26:38 vtnerd: the 'mac' thing was renamed to 'address tag hint' and uses blake2b now 17:27:10 the address index is still ciphered with twofish 17:27:19 ok will scan the comment and proposed changes again 17:29:05 Some preliminary numbers on p2pool payout outputs: They account for about 15% of all outputs on the chain if my calculations are correct. Implications: larger storage needs (but coinbase outputs are lighter than most tx outputs); and some potential privacy issues with decoy selection since each ring will have two p2pool outputs on average. 17:29:32 The Monero Meet discussion encouraged me to run the numbers 17:30:06 This is with p2pool finding about 7% of all blocks 17:30:10 That's a bit surprising, given that not yet too many people mine there 17:30:18 on the other hand, it makes all transfers plausibly use freshly minted coins 17:30:59 It's more "possible" than "plausible" IMHO 17:31:40 p2pool payout consolidations would probably be distinct on the chain. 17:31:46 yes, possibly* 17:32:52 And then the addresses being mined to are transparent, which can lead to deeper analysis of what txs may be p2pool payout consolidations 17:33:30 What do you mean with "consolidation"? E.g. payout only after I participated on x blocks, x>1? 17:33:50 wow 15% 17:33:53 The average number of p2pool payout outputs per found block is about 150. the mini chain tends to have higher numbers of outputs. 17:35:22 Consolidation: If I am a p2pool miner, I would want to consolidate the very small payouts. I doubt that an individual p2pool output would be enough to pay for a good or service or be something to send to an exchange, etc. 17:36:20 High frequency of miner outputs in rings has benefits 17:36:22 https://usercontent.irccloud-cdn.com/file/lVoXxbJv/image.png 17:36:45 Nice if most or all rings have Y_{hops}(t) = 0 17:37:13 Sorry this is a very old doc 17:37:31 This p2pool coinbase has small amounts per output, for example: https://xmrchain.net/tx/f6c1cfcce9e531d3147f249638233e40a71153f47cac253c45d3f5d1fd06d7dc 17:37:31 only nice if the hops can't be ignored due to identifiable consolidations 17:38:25 https://usercontent.irccloud-cdn.com/file/fujH5bfH/image.png 17:40:06 At least those transactions are still small 17:40:39 Almost Bitcoin like :) 17:40:45 Also, if I'm an adversary receiving a user's payment (or I have cleartext view into that payment), the amount could easily exceed the possible amount of the sum of the cleartext p2pool payouts in the corresponding history. 17:41:00 🤔 17:43:10 Let's analyze single-hop: If sum(max(p2pool outputs in each ring)) > value_of_surveilled_tx_output, then you can rule out the p2pool outputs, (used as inputs) as a whole. 17:43:15 Or should I say enotes 17:44:43 If the target tx has a single input, then in this scenario the p2pool ring members could be ruled out completely. 17:49:27 Gotta run, catch y'all later 17:51:10 seems like we are at the end of the meeting, so let's wrap it up here; thanks for attending everyone 18:15:57 p2pool payout consolidations are very easy to spot if you track payout addresses: all or most of the inputs will have the same address as one of decoys. 18:19:19 there should be a smarter way of picking decoys for such consolidations, e.g. same 16 payout addresses for each input 18:20:45 the problem is you need to have external data to know which output is for which address so you can't pick decoys like this 18:21:04 external observer can run p2pool node and collect all this data, but it's not on Monero blockchain 18:24:00 p2pool could provide a function to select the decoys, which could then be used to make a tx if the RPC supported manually selected decoys 18:24:23 all miners on p2pool are running a p2pool node, so they have the data 18:30:28 what would be the consequences of not using ring sigs when spending coinbase enotes? and likewise excluding them from constructed ring sigs 18:40:01 We are not sure. IIRC sarang thought it would just push the problem one step up. It'd need Careful Study by People With a Clue to have a good grip on the consequences. 18:41:14 Could there be a way for p2pool miners to tell p2poll to "withold" the payouts until they reach a certain threshold? 18:43:10 Something like: "pay me only if I have accumulated 0.01 xmr with all my shares, or if I haven't found a share in the last 1000 p2pool blocks" 18:44:59 You'd need a way to tell other miners that you accept this. I guess it could be an on-chain signed message with the mining address, but you'd need to have a way to propagate these to other miners. 18:45:35 This would probably also require a longer chain, since you risk your shares lapsing otherwise. 18:45:58 A simpler way might be to have different p2pool chains configured differently. Pick the one you like. 18:46:39 ie, one very long chain, where miners add an output only for people with >= N shares. 18:47:10 Another issue would be how to handle p2pool blocks that find mainchain blocks: if you found a share but you're still below your threshold, where do those xmr go? They must go somewhere... 18:47:34 The rule could also say ">=N shares, or a share in the block about to lapse". That'd fix the lapsing issue... 18:48:18 They go... to whoever got outputs on that miner tx, same as now. 18:48:57 Right... finding two shares at half the difficulty should (?) have lower variance than one share at higher difficulty 18:50:12 Actually, ">=N shares, or a share in the block about to lapse" might be a good change for the default chain too. It'd cut down on miner tx size without drawback to small hash rate miners. 18:50:27 High hash rate miners would just stop spamming so much. 18:50:48 sech1: do you see a drawback here (beyond whiners wanting to be paid in 30 minutes rather than two days) ? 18:57:07 I tested different payout schemes when I started working on p2pool. All variations of "withhold payout until limit" were underpaying low hashrate miners. 18:57:37 they only worked if I kept _all_ p2pool blocks which is not feasible 18:58:11 as soon as you start pruning old blocks, some low hashrate miners get their shares lost 18:58:41 I tried to compensate it by "moving" their accumulated hashes into a newly found share, but it also skewed payouts in favor of high hashrate miners 18:59:28 I tried 4-5 variants, in the end only plain PPLNS window worked fine and didn't discriminate any miner in the long run 19:00:58 Lyza: When Sarang looked at it, p2pool didn't exist yet. If we separated coinbase outputs from normal outputs like that, I think p2pool miners would need to churn at least once after a consolidation transaction for good privacy. 19:01:59 cheap consolidation of p2pool payouts would be nice 19:02:25 why would they need to churn? They already get a single "regular" output after consolidation 19:03:19 EAE attack is not applicable because there's no first "E" for miner payout 19:04:27 hmm, but on the other hand, repeated consolidation -> single output -> direct send to exchange can be the same as EAE attack because p2pool data can provide the payout address 19:05:16 You're right. I should have said that they need to do a consolidation transaction (which is like a churn) rather than a direct payment from the coinbases to another entity. 19:05:55 even after a consolidation transaction, this output is still traceable to the original p2pool payouts, if it's a repeated send to an exchange 19:06:04 like a miner sending to exchange every month 19:06:28 Researching this issue may become a high priority if ring size stays the same and either (1) tx volume falls a lot or (2) p2pool hashpower share rises a lot. 19:06:45 the consolidated input should be churned 2-3 times to break this link 19:06:53 if the miner cares, of course 19:07:48 also, cheap consolidation can become important if p2pool gets significant % of hashrate 19:08:09 each individual payout in each block is 39 bytes and then ~520 bytes more when it gets consolidated 19:09:15 right now it's ~8000 payouts/day, so 4-4.5 MB of eventual blockchain growth for each day of p2pool operation 19:09:52 if p2pool gets 10 times bigger, it will be 40-50 MB/day from p2pool only 19:27:48 So 60% of the hash rate? 19:28:55 So like 20 GB a year? To have the chain be way, way more resistant to 51% attacks? Sounds like a decent trade-off 19:56:32 another aspect is network fees to consolidate miner payouts 19:56:46 it can reach 3-4% for low hashrate miners who only get smallest payouts 20:14:25 sech1: How does that compare to the "unfairness" of the alternative payout schemes you analyzed? 20:16:14 alternative payout schemes sometimes underpaid 50% to small miners 20:18:14 Ouch 20:21:31 some of my attempts resulted in small miners not even getting anything :D 20:25:40 the key problem here is that you get block reward of 0.6+ XMR and you _must_ distribute the entirety of it between eligible miners 20:26:12 if you introduce some form of min. payout and accumulation into the system, there will always be some time fraction of block reward left which must go somewhere 20:26:22 it results of some miners getting more and some miners getting less 20:26:27 *results in 20:26:44 and usually big miners get more because they get payouts in every block 20:27:48 for example, if you have 3 miners eligible for 0.02, 0.07 and 0.5 XMR payouts, it's 0.59 XMR and block reward is 0.6 XMR 20:28:06 you have to give 0.01 XMR to someone but all other miners have less than 0.01 XMR pending 20:28:24 either one of the 3 gets more, or one of other miners get more than they've accumulated 20:28:52 it can all be solved if the entire p2pool chain history is kept, but it's impossible 20:29:00 p2pool main is already approaching 4,000,000 blocks 20:30:01 sech1: Give it to starving developers! :P 20:39:49 does it all need to be kept everywhere? or just the miner tryin to prove their share? 20:40:25 hrm nah. 21:04:01 I do not understand why miners would be (dis)advantaged based on hash rate since the only change is delaying something, final balances are identical. 21:09:54 I think you skipped over the "or a share in the block about to lapse" part. This ensures you do not lose shares. 21:11:39 I may have been unclear. Here, "the block about to lapse" is the oldest block in the p2pool chain. The one which, after p2pool finds a new block, will be dropped from the chain, and thus the miner would found it would lose their share if it was not paid right now (if it was not paid out already). 21:12:16 It's the "safety" that means low hash rate miners do not get to lose their shares before they get to the payout threshold. 21:12:31 And with it, payout thresholds can even be infinity. 21:12:55 if you move these old blocks to remember what they mined, it results in low hashrate miners underpaid 21:12:59 Low hash rate miners would still be paid per share (just 3 days after they find their share). 21:13:03 partly because of the problem I described above 21:13:22 partly because it increases the total weight of PPLNS window and it favors bigger miners 21:13:41 I ran the simulations and I though it would work (accumulating old blocks), but it doesn't 21:14:26 it seems intuitive to do what you describe and I actually wanted to go with it at first 21:14:35 but couldn't find the solution 21:14:45 Are you saying that just delaying a payout in case it can be merged with another causes different payout overall ? 21:15:41 The "fraction of block reward left which must go somewhere" above ? 21:15:48 yes 21:16:01 if you delay payout to some miners, it basically means you're overpaying some other miners 21:16:06 Oh, I just nuderstood it now. 21:16:17 You can't pay from past blocks anymore. 21:16:17 and they can even game this system by changing their wallet address as soon as they're overpaid enough 21:17:02 Thanks.