Some of them also disclose txs with payout

but you are talking about something enforced

if not enforced, it will never be done

They do those disclosures due to implicit reason to gain trust of miners, probably

and there would be very little support for enforcing it

its a false sense of security

^ cohcho

honestly verifying payout is so trivial im surprised pools bother disclosing

yep

Isthmus: mentioned shuffling of txs a way to get uniq hashing blob for miner

What are other ways to generate uniq hashing blob without using tx_extra?

might be hard to verify the payout of fees though

cohcho change the timestamp slightly

koe: small space only 7200

not much then

expected_payout = avg_recent_block_amnt*(hashrate*120/difficulty)*(1-poolfee%) lol

well, given that extra has to allow for an undpecified amount of pub keys, if tx extra was to be enforced this requirement would still be needed (tx pub key, subaddress, multi-sig), pools could just add a dummy pub key and use the 32 bytes for their miner data.

s/undpecified/unspecified/

pools could do this right now if they wanted to.

That would cause a lot of scanning bloat (users looking for owned outputs)

What way miners should use tx_extra (in case if it will be adopted by pools and added into solo mining software) to not lose required flexibility and not leave fingerprint (probably with some space overhead)?

uniq tx per worker removes flexibility and doesn't remove fingerprint

but possible to implement :)

16:05 <cohcho> Isthmus: mentioned shuffling of txs a way to get uniq hashing blob for miner

Heh I meant transaction shuffling and timestamp spoofing as things to *not* do, lol

Indicative of a problem, not the right solution (definitely not one that depends on transaction volume hehe)

I've used it as example of sophisticated way to randomize tx's hash that bypass any retrisctions

skip it please

koe: "scanning bloat" <- correct, but if you force pools into a corner that's what you'll get)

pools tight now need some data space to function. enforcing sharing of private view key is a non-starter IMO, and if they cannot legitimately insert their own data, they'll insert a fake pub key.

s/tight/right

uniq tx per worker removes flexibility , doesn't remove fingerprint and can be bypassed to insert some data into tx_extra.

I'd actually be interested to know about the actual impact on scanning time for each public key in extra. Anyone have any numbers on this?

Hello all

I had hoped to have finished all of suraeNoether's CLSAG suggestions/edits by now, but we spent a lot of time yesterday discussing some finer points of security definition wording

The process continues :D

Sarang I am going over the details of these security models very closely today. I may whiteboard it out. I may want to have a call later

Sounds good

jtgrassie I doubt we'll ever get to a point where tx extra is so strict pools need to use fake pub keys. I'd consider it a victory if 75%+ of the hashrate makes blocks that look the same (on chain, can't do anything about offchain), and if future implementers are given a clear standardized way to blend in with other privacy-minded implementers.

One way to get that standard is to form a temporary committee between major pool operators, who can hash out an agreeable format. This is a common path tread by private industries.

Each additional byte per block is 263kB yearly, so I expect solutions to range from 1.052MB (4 bytes extra nonce) to 8.416MB (32 bytes extra nonce) yearly.

koe: the issue is surely scanning time not size (4 bytes vs 32 is not a biggie).

regarding that approach with uniq txs: intermediate mining proxy can return generated block_template with *r* used in coinbase tx

this way pool can share only address

and should receive generated tx with *r*

It's safe and doesn't force to disclose any private key

is r even necessary? sounds like you're just generating an output for the pool owner

koe: in general there can be pool -> 1st proxy -> 2nd proxy

and 1st proxy will know only pool's address and received *r*

so that it can verify destination localy and reject inappropriate coinbase

from 2nd proxy

interesting

direct miners don't need vene pool's address

even*

you surely can't be suggestion sharing *r* ?!

anyone will be able to get pool's address and some proxies will know *r* for some pool's coinbase txs

I think it would be ok to just have 2nd proxy generate output for pool, then pool verify it's theirs before publishing, and push feedback to proxy 1 if it is a bad coinbase, then proxy 1 can decide to punish proxy 2

why is it not safe?

koe: locality helps to decrease network usage

the situation where proxy 2 makes a bad coinbase will be very low

current state with tx_extra has good locality since you retrieve block_template only once

and push back nonce and additinola 8 bytes for tx_extra

This approach with uniq txs will require pushing back nonce + 32 bytes of *r* + complete tx

It's very inefficient comparintg with current state in mining ( but posssible)

oh I see interesting

it should be unnecessary with guidelines around tx extra

btw, this hassle with *r* (or (sec_view, pub_send) previously) is required only to support 2nd level proxies (only 1st level proxies exist in real monero mining)

so only nonce + complete coinbase tx to push back

jtgrassie by size I just mean different hypothetical standard size extra nonces, additional scanning solutions are pretty extreme

sharing r or a wekens pool privacy

wrt scanning time, one of you stated that using a fake pub key would increase scanning time, I want to know by how much.

because already there can be many pub keys in txs so I'd assume someone has already done the calculation rather than speculation.

2x the pub key = 2x the scanning, pretty good estimate I think. andytoshi mentioned the EC operations involved are so expensive they would be very difficult to implement in Bitcoin

if the impact is negligible, fake pub keys are a good solution, the ints could be varints in the fake pub key making the fake pub key indistinguisible from real pub keys.

koe: "2x the pub key = 2x the scanning, pretty good estimate I think" <- that is your guess, not fact.

and I question that assumption. Otherwise I'd assume multi-sig and subaddr would have looked at alternative ways to embed the pub keys.

I feel like fake pub keys are just as obvious as extra nonce fields.. and no less random than a good implementation could achieve.

e.g. does placing a pub key in TX_EXTRA_TAG_ADDITIONAL_PUBKEYS increase normal users scanning time?

"I feel like fake pub keys are just as obvious as extra nonce fields" <- how so? an observer has no idea whether any of the pub keys is real or not.

if there are two pub keys, and one output, obviously 1 pub key is the transaction pub key and the other is fake

which is how miner tx outputs would look

not necessarily

multi-sig, subaddress...

if subaddress then #pub keys == #outputs

there are scenarios where subaddress usage adds keys to extra

(IIRC)

does a fake pub key actually sound easier to implement than standardizing extra nonce? seems like it would be complicated

a fake pub key would allow *all* miners (not just pools) look the same.

can make solo miners use the extra nonce too, just randomize it

or not make, but recommend

yes, monerod even has option to put user defined fingerprint into extra

are the pool names here accurate? minexmr.com/pools.html I couldn't find the nodejs-pool and monero-pool mentioned earlier

which is why this whole discussion id pretty pointless. anyone can already put anything in extra. unless it's enforced it makes little point.

the point is standard guidelines, so people who care about privacy can flock together

if pools *want* to be indistinguishable, they already can

and pools IMO dont care about standing out

but they would care about sending out keys a or r

just because they haven't become indistinguishable, doesn't mean they won't if encouraged by others to do so, and given a clear avenue to accomplish it. It's seems a very black and white perspective..

I've already suggested one "solution" with fake pub key for the data. You could also make use of payment id. Sharing r/a is a terrible idea IMO.

jtgrassie: i've said that sharing r/a will not be required in practise since no one pool supports 2nd level proxies

your solutions seem to imply strict tx extra rules, which I doubt will ever be enacted; my recommendations, enforced sorted TLV + standard guidelines for using the extra nonce, are much more soft

moneromooo suggested it, I'm only trying to understand the easiest way to implement it. I don't prefer it more than any other solution to avoid fingerprint in coinbase

self-select mode that allows txs selection by miner locally has not been adopted by any pool in top 90% by hashrate

If there is no mechanism to push anything to many pools I agree with jtgrassie that this discussion is pointless.

One mechanism is to get major pools to collaborate on developing a standard. Then they are all stakeholders in a given solution.

Even if it's something broad like 32 bytes, and then they each fill it with different kinds of random data with different meanings. Progress

Isthmus will have an aneurism if nothing at all is done

I'll back with examples of block_template of as many pools as possible to get min/max of tx_extra used in practise now

^ accurate

cohcho usercontent.irccloud-cdn.com/file/g2Ms1LsZ/image.png

biggest extra nonce is around 64 bytes iirc, mostly padding

How long would those two curve ops for recreating the output take ?