Meeting 2hr

meeting time

1. greetings

hello

Hi

Hello

Hello

hi

2. updates, what's everyone working on?

Collecting mempool and found block broadcast time for analysis of mining pools' block template update policies. Some analysis of p2pool payout outputs.

no real tangible updates since last week unfortunately - working on (other stuff) and bp++

Hi. Jamtis checksum + updating the specs.

I read the OSPEAD doc again and started drafting up thoughts / questions. Converting from my own shorthand into comments shortly.

Thanks, isthmus.

Submitted a PR to rbrunner 's PR to optimize pool processing (rbrunner7/monero #4) + been going through balance recovery in the Seraphis lib

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).

Yeah, things get so complex that now PR's need PR's :) Thanks jberman[m]

3. discussion

This seraphis design overview basically got no attention - everyone should read it though because this is what monero will get if nothing changes. gist.github.com/UkoeHB/f508a6ad973fbf85195403057e87449e

Not sure there was a lack of attention, I just think that it's not that controversial now

I read it and gave comments/questions :P

I read it and was impressed how much will really change, it only becomes clear if you heap it all in one place.

And not merely change of course, but improve

By the way, is there already support in the library for transaction chaining? I guess so, given how modular it is

Rucknium[m]: yes I'm grateful :)

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?

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

the offchain mockups may or may not work *

Ok, it will be hard work to support it "higher up" in wallets anyway, probably not the first thing to implement

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

Amazing work @UkoeHB

/me is very happy about the transaction uniformity improvements

thanks isthmus

hmm are there any other topics to discuss today?

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?

its still handled by the blowfish technique .. ?

twofish

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

yes, it uses a block cipher

ah right the upgrade sorry, but I think it was probably worth the change

I'm in the process of updating the specs to match UkoeHB's library

it makes accounts more seamless

vtnerd: the 'mac' thing was renamed to 'address tag hint' and uses blake2b now

the address index is still ciphered with twofish

ok will scan the comment and proposed changes again

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.

The Monero Meet discussion encouraged me to run the numbers

This is with p2pool finding about 7% of all blocks

That's a bit surprising, given that not yet too many people mine there

on the other hand, it makes all transfers plausibly use freshly minted coins

It's more "possible" than "plausible" IMHO

p2pool payout consolidations would probably be distinct on the chain.

yes, possibly*

And then the addresses being mined to are transparent, which can lead to deeper analysis of what txs may be p2pool payout consolidations

What do you mean with "consolidation"? E.g. payout only after I participated on x blocks, x>1?

wow 15%

The average number of p2pool payout outputs per found block is about 150. the mini chain tends to have higher numbers of outputs.

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.

High frequency of miner outputs in rings has benefits

Nice if most or all rings have Y_{hops}(t) = 0

Sorry this is a very old doc

This p2pool coinbase has small amounts per output, for example: xmrchain.net/tx/f6c1cfcce9e531d3147…e40a71153f47cac253c45d3f5d1fd06d7dc

only nice if the hops can't be ignored due to identifiable consolidations

At least those transactions are still small

Almost Bitcoin like :)

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.

🤔

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.

Or should I say enotes

If the target tx has a single input, then in this scenario the p2pool ring members could be ruled out completely.

Gotta run, catch y'all later

seems like we are at the end of the meeting, so let's wrap it up here; thanks for attending everyone

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.

there should be a smarter way of picking decoys for such consolidations, e.g. same 16 payout addresses for each input

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

external observer can run p2pool node and collect all this data, but it's not on Monero blockchain

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

all miners on p2pool are running a p2pool node, so they have the data

what would be the consequences of not using ring sigs when spending coinbase enotes? and likewise excluding them from constructed ring sigs

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.

Could there be a way for p2pool miners to tell p2poll to "withold" the payouts until they reach a certain threshold?

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"

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.

This would probably also require a longer chain, since you risk your shares lapsing otherwise.

A simpler way might be to have different p2pool chains configured differently. Pick the one you like.

ie, one very long chain, where miners add an output only for people with >= N shares.

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...

The rule could also say ">=N shares, or a share in the block about to lapse". That'd fix the lapsing issue...

They go... to whoever got outputs on that miner tx, same as now.

Right... finding two shares at half the difficulty should (?) have lower variance than one share at higher difficulty

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.

High hash rate miners would just stop spamming so much.

sech1: do you see a drawback here (beyond whiners wanting to be paid in 30 minutes rather than two days) ?

I tested different payout schemes when I started working on p2pool. All variations of "withhold payout until limit" were underpaying low hashrate miners.

they only worked if I kept _all_ p2pool blocks which is not feasible

as soon as you start pruning old blocks, some low hashrate miners get their shares lost

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

I tried 4-5 variants, in the end only plain PPLNS window worked fine and didn't discriminate any miner in the long run

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.

cheap consolidation of p2pool payouts would be nice

why would they need to churn? They already get a single "regular" output after consolidation

EAE attack is not applicable because there's no first "E" for miner payout

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

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.

even after a consolidation transaction, this output is still traceable to the original p2pool payouts, if it's a repeated send to an exchange

like a miner sending to exchange every month

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.

the consolidated input should be churned 2-3 times to break this link

if the miner cares, of course

also, cheap consolidation can become important if p2pool gets significant % of hashrate

each individual payout in each block is 39 bytes and then ~520 bytes more when it gets consolidated

right now it's ~8000 payouts/day, so 4-4.5 MB of eventual blockchain growth for each day of p2pool operation

if p2pool gets 10 times bigger, it will be 40-50 MB/day from p2pool only

So 60% of the hash rate?

So like 20 GB a year? To have the chain be way, way more resistant to 51% attacks? Sounds like a decent trade-off

another aspect is network fees to consolidate miner payouts

it can reach 3-4% for low hashrate miners who only get smallest payouts

sech1: How does that compare to the "unfairness" of the alternative payout schemes you analyzed?

alternative payout schemes sometimes underpaid 50% to small miners

Ouch

some of my attempts resulted in small miners not even getting anything :D

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

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

it results of some miners getting more and some miners getting less

*results in

and usually big miners get more because they get payouts in every block

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

you have to give 0.01 XMR to someone but all other miners have less than 0.01 XMR pending

either one of the 3 gets more, or one of other miners get more than they've accumulated

it can all be solved if the entire p2pool chain history is kept, but it's impossible

p2pool main is already approaching 4,000,000 blocks

sech1: Give it to starving developers! :P

does it all need to be kept everywhere? or just the miner tryin to prove their share?

hrm nah.

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.

I think you skipped over the "or a share in the block about to lapse" part. This ensures you do not lose shares.

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).

It's the "safety" that means low hash rate miners do not get to lose their shares before they get to the payout threshold.

And with it, payout thresholds can even be infinity.

if you move these old blocks to remember what they mined, it results in low hashrate miners underpaid

Low hash rate miners would still be paid per share (just 3 days after they find their share).

partly because of the problem I described above

partly because it increases the total weight of PPLNS window and it favors bigger miners

I ran the simulations and I though it would work (accumulating old blocks), but it doesn't

it seems intuitive to do what you describe and I actually wanted to go with it at first

but couldn't find the solution

Are you saying that just delaying a payout in case it can be merged with another causes different payout overall ?

The "fraction of block reward left which must go somewhere" above ?

yes

if you delay payout to some miners, it basically means you're overpaying some other miners

Oh, I just nuderstood it now.

You can't pay from past blocks anymore.

and they can even game this system by changing their wallet address as soon as they're overpaid enough

Thanks.