gm

Gm

Meeting 1.75hr

meeting time

1. greetings

hello

Hello!

Hello

hi

Hi

Hi

2. updates, what’s everyone working on?

I did some serialization stuff again (tests still dont work), and got sucked into lws dev work (first potential commerical deployment)

so not much related to -mrl, more -dev

the lws work shouldnt be too long hopefully

Analyzing data about mining pools' block template update behavior. It affects the amount of time it takes for a transaction to receive its first confirmation on the blockchain.

me: continued library cleanup, also did some reviewing of dangerousfreedom’s seraphis knowledge proof work and made some adjustments to jamtis to support enote ownership proofs and address index proofs

(greetings)

UkoeHB: I have a question to your new proposed scheme. Why K_1 represents a full address? An address is not defined by three public keys, K_1,K_2,K_3? If you are proving knowledge of only K_1 I believe that there may be room for generating a fake proof even if the enote would be unspendable. I dont see a real use case for that since enotes are meant to be owned by someone but it may leave room for that, what do you think?

I agree it is much cleaner though now

(the schemes)

3. discussion

hi

dangerousfreedom: ownership doesn’t require spendability I think

(Those "updates" should be these, I think: gist.github.com/tevador/50160d160d2…ment_id=4432591#gistcomment-4432591 )

Anyway, including an address ownership proof and amount proof is sufficient to prove an enote is spendable

Yeah, Ok. I agree with that.

I have a question out of curiousity, as a layman regarding crypto: Was it easy to find these adjustments you propose there?

To me it looks almost like magic - add a factor here, hash a bit more there, and presto, the system has more desirable capabilities

Somehow amazing that such a complex construct is still so malleable

And do I see that correctly: If Seraphis and Jamtis were already active on Mainnet, such changes would need a hardfork to introduce?

p2pool will upgrade to reduce the number of p2pool payout outputs by 50-66%: reddit.com/r/MoneroMining/comments/…twork_upgrade_aka_hardfork_on_march

wasn't too hard for me, but I have a lot of experience with crypto protocol engineering

Rucknium[m]: it's good news nice work sech1

Rucknium[m]: Nice!

I hope that p2pool hardfork does not get contested, and the variants multiply :)

With the p2pool upgrade, I think the proposed (1) coinbase consolidation tx type and (2) avoiding selecting coinbase outputs as decoys is still needed. Just not as urgently needed.

So maybe we can muddle through until Seraphis

right, I proposed this last week monero-project/research-lab #108

after thinking about it more, I'm not sure that's the right direction

Coinbase consolidation tx type has to wait for a hard fork anyway. Decoy selection changes could (and probably should) be implemented at the same time as OSPEAD improvements, assuming OSPEAD passes review.

needing to merge coinbase enotes is one example of a broader class of problems - a public group consolidating enotes is statistically significant

a coinbase consolidation tx type is not a general solution, it is a specific solution

You mean a public group of Monero users that do something, namely consolidate?

Will the code surrounding bulletproofs + need to be rewritten for Seraphis? The part of the code that proves inputs = outputs + fee?

this solution amounts to elevating the circumstances of miners to first-class status in the protocol, while still leaving the general problem unsolved (e.g. what about consolidating the outputs of consolidation txs?)

fr33_yourself[m]: no, range proofs are plug and play

So that part of the codebase(rangegproofs) won't be touched meaning the security level of Seraphis transaction amount proofs will be exactly equal to what it currently is?

rbrunner: well any user that receives multiple enotes from outside parties and consolidates those enotes will have a statistically significant tx

fr33_yourself[m]: yes, unless BP++ is implemented (which should have equivalent security properities) monero-project/research-lab #101

I see. Doesn't sound that a bit like an unsolvable problem? Like trying to consolidate without consolidating, because with that I get too many enotes on a single heap?

actually I did duplicate BP+ so I could use the seraphis transcript and multiexponentiation tools, which add a little bit of efficiency

rbrunner: the solution is a global membership proof

Sounds good, thanks for the quick response. I think the fact that transaction amount proofs stay the same in terms of security will help lessen friction of Seraphis upgrade down the pipe.

Is something like that akin to nuclear fusion, always 20 years in the future? :)

As an end user, I only think transactions size in kb and overhaul of address scheme could turn out to be points of friction in the future assuming the security of the code implementation of bulletproofs + or ++ is the same as it is presently.

rbrunner: perhaps

fr33_yourself[m]: tx size will not increase by more than 2x (probably only 1.3x or so)

UkoeHB: Thanks I thought I read something similar to this recently. Like a Seraphis will be about 3kb as opposed to 2kb currently. However, is the tradeoff of having more ring members really worth increasing the tx size? One of the things that I think has helped Monero's adoption over the past hardforks is that transaction size has decreased and speed has increased consistently.

I think the shift from standard rangeproofs to the first implementation of bulletproofs greatly spurred people to shift from other cryptos to Monero and consider the tradeoff of running a full node more favorable than it would've been previously with the huge rangeproof tx's

fr33_yourself: The decision on the tradeoff between tx size and ring size is something that is in the hands of the community. As someone who researches statistical attacks against Monero user privacy, IMHO, the tradeoff would be worth it.

Rucknium[m]: I understand your perspective and appreciate the work you have done on statistical monitoring of spends. However, isn't there some middle-ground solution where we keep the transactions size in kb of Seraphis equivalent to what we have now?

Is it so that much of the size increase comes from the larger rings? I doubt it a bit because they are "binned" / encoded in a completely different way.

fr33_yourself[m]: for me, the advantage of increased ring sizes is binning the decoys - basically instead of single decoys selected from the chain you select clumps of decoys in the same way. This addresses an analysis mode that uses timing information about when you receive enotes to ignore decoys that don't match the timing profile.

Rucknium[m]: Would be the difference in ring size of the current proposed Seraphis tx versus a Seraphis tx that is only 2kb\

fr33_yourself[m]: you can look at estimates I made here monero-project/research-lab #91#issuecomment-1047191259

right now I have seraphis-squashed implemented

I think almost everything is a bit bigger with Seraphis, I doubt we win much if we go down to e.g. 50 ring members, but I may be mistaken

verification time is actually lower than clsag with 16-size rings with seraphis-squashed at 128-size rings

I mean it's not the end of the world if transactions are 3kb, but I feel like there is a Monero adoption timeline where hardware begins to trouble individuals wanting to run full nodes. Currently, it's hard to imagine with less than 20k tx per day, but things can change quicker than we may imagine.

Would that be, in the doc linked above, the graph "Reference Set Size vs Transaction Size"? To check the influence on number of ring members on tx size?

Preliminary results on tx confirmation delay: Most mining pools update their block template only once: when they see a new block. They don't include new transactions that appear in the mempool after the previous block was found.

As a result, the average time to first confirmation is actually 30 seconds longer for a XMR tramsaction than a Litecoin transaction, despite Litecoin having a 2.5 minute target block time (compared to XMR's 2 mins).

fr33_yourself[m]: you can read a bit about the advantages of binning here monero-project/research-lab #84 and in the references

If all centralized pools used p2pool's update policy, the average time to first confirmation would fall by a full minute

Quite surprising that this fact becomes known so late.

I'm going to release a write-up on the results with graphs next week. I think the course of action is to try to convince mining pool operators to update their block templates more frequently and/or change the defaults on jtgrassie 's monero-pool software.

If centralized pools refuse, then we will go all-in with p2pool adoption! (This is a joke)

Anecdotally, I noticed this with my own transactions. You can also see it on txstreet.com

Do these pools win something by doing so?

btw, I think you could use a SAG (simplified CLSAG) with seraphis to get 16-size rings and verify txs maybe 20-40% faster than today

The Isabellas are kicked off the bus right before it launches into the blockchain.

p2pool on average is getting 0.003 XMR more in fee revenue per block than other miners. So pools are losing a bit. But according to sech1 the pools need to do database operations when they update the block templates, which may cost money.

They need to update db when they send out new jobs to all connected miner workers

which can be tens of thousands jobs for each block template

I wonder if other PoW coins (I am analyzing LTC, BCH, and DOGE) have more mining centralization so they don't have the database cost.

They do

but they still update template more often

They do have the cost or they are more centralized?

I looked at pool code before, and I think 90% of the problem is pool operators just use what's default

Monero pools can update more often

at least every 30 seconds

but it will require some qualification and knowledge from pool operators

Yes I would guess that it is "default-itis" rather than a deliberate decision.

One of the pool operators seems to update every two minutes if a block hasn't been found. So a +2,+4, +6, etc. minutes

Most of the other ones don't update

The pool labeling data was gathered by datahoarder.

we are past the hour so I'll call it, thanks for attending everyone

<UkoeHB> "we are past the hour so I'll..." <- UkoeHB, what is VTnerd's verdict on your current code implementation of binning? I was deeply comforted to see some intelligent criticism of your binning proposal, but he seems to have reached the conlcusion that binning privacy is at least equivalent to single decoy selection privacy so long as the number of bins is 16 or greater (our current single decoy size) ?

Id have to look at it again, but the initial struggle was there was two different binning modes, and the one representing recent outputs was a bit funky

overall, it _probably_ is better after I thought about it (theres a decent space savings with no obvious privacy downside)

arguably the randomized mode we have now is preferrable, but I dunno its still a tough argument

fr33_yourself: Binning has not been rigorously analyzed by any statistician. Hopefully we will have a rigorous analysis before the include/exclude decision is needed closer to Seraphis mainnet activation.

vtnerd: I would appreciate it if you share your thoughts and pin me after you've looked at the most recent implementation. I can't read code, but I want to thank you deeply for pushing back with reasonable criticism. One thing that made me a bit bearish on Monero is how quickly people are assuming that Seraphis is all good with no bad. I think preserving the current level of supply integrity and privacy are paramount

above all other possible gains.

that MRL issue describes a fully-deterministic approach, but my implementation is only partially deterministic so it's a bit simpler

vtnerd: What about security downsides? Is there any way binning increases, even if at the edge / margin, the probability of an inflation bug?

UkoeHB: And if my understanding is correct, the idea is that with binning an increase or decrease in total key_images or decoys or whatever doesn't have a huge impact on tx size, so may aswell do 128 as opposed to 64 decoys

^ If this is true, then I'm fine with tx size in kb going up some as it seems to be an inherent feature of binning, so might as well increase decoys a notable amount if decreasing decoys doesn't decrease tx size much.

yes the size scaling is better

Ok i am happy camper then

it's unrelated to binning though, binning just saves some reference bytes (~4-6 bytes per decoy)

if scaling is reasonable and supply security (no bugs in coin emission or amount proofs) occur, then Seraphis seems to have low tradeoffs

That just leaves address scheme overhaul, but as someone who monitors Monero network and dev discussion this doesn't seem like a big deal to me.

Maybe it will be for people who have a cold wallet sitting dormant that they can't access until "n" years after Seraphis roll out

cold wallets won't be able to receive funds without being updated, but legacy funds will be spendable seamlessly

I know it's annoying in the moment for you guys to debate and argue as developers, but it's quite nice to see strong pushback on different sides of issues. For a while I was seeing some weird rhetoric surrounding seraphis like people making comments along the lines of: "if we present seraphis this way, it will lessen people's angst about possible vulnerabilities or bugs" or something like this

UkoeHB: ahhhh, so basically a cold wallet must be updated post-seraphis to receive funds, but it will be able to spend funds seamlessly from an airgapped laptop or hardware wallet

"if we present seraphis this way, it will lessen ..." That sounds weird. Maybe I am biased, but I never read something that I would put into this particular drawer.

I do have a question about Bitcoin though, I thought I saw someone state that Bitcoin protocol could somewhat survive a splinternet by having wallet software resend a tx immediately after the subnetwork chain reconnects to the mainchain? is this really true? If so it is a genuine technical advantage bitcoin has over Monero in this case.

rbrunner: I don't think it was a developer who said it, but someone else in one of the matrix rooms.

Well, then all bets are off :) We have an average of over 1000 people present in the Monero subreddit at almost any given time

I also don't appreciate all these instant gratification consumer's trying to weasle a way around the 10-block lock lol. It doesn't make any sense to me. Like why can't you just wait 30 minutes chill

If the person's use-case is, I want to give up my privacy to spend immediately after receiving, then they should use Litecoin or BCH or something IMO

Sometimes I wonder why not *more* nonsense gets posted, with so many people

fr33_yourself[m]: I guess it depends on the cold wallet implementation - do existing cold wallets not have to update with each hard fork?

The transactions in a bitcoin splinternet would be erased after reconnection to the chain with the most proof-of-work

I feel like most of the low IQ comments remain on reddit as it is easier to access than the matrix rooms

The transactions in the splitnet that spend outputs from the splitnet would be invalid on the main chain after reconnection.

UkoeHB: I don't know. I've never tried to spend from a cold wallet.

I would say cold signing only works with a Monero version of the right version, most of the time. Maybe there were hardforks where you could "cheat" and continue to sign with an older version.

UkoeHB: Are you being sarcastic here? If my understanding is correct, then I can send XMR from a hot wallet running the 16 member version of Monero to a cold wallet that's address was generated in offline software and it will still go to the appropriate cold wallet because the address scheme is the same.

*Monero software

Maybe we are talking about two different kind of "cold wallets" now.

Basically sending to cold wallet from hot wallet only becomes impossible if the address scheme changes, not simply due a hardfork which does not tamper with the address scheme

rbrunner: I'm talking about a paper wallet

Of course you can send to a mere address as long as you like, until the address format changes, as it will with Jamtis

Ah, yes, "paper wallet" is it

? you can't send to legacy addresses in a seraphis tx, but you can spend from legacy wallets if your software supports it

Let's say you generated a paper wallet with Moo's offline wallet generator (I think he made that right?) then you can send to it UNTIL the address scheme changes assuming Seraphis is implemented

I would say so

As I said, can't see what would stopping you sending XMR to the correct address of your paper wallet

As long as the address itself stands

UkoeHB: Got it, but the idea is that in order to spend you will have to update the wallet anyways. I guess the only way something could go wrong is if someone didn't update after Seraphis and funds were sent to their cold wallet with legacy address

Who would mine that tx?

Will the GUI wallet post-Seraphis automatically block a sender from sending to a legacy address to prevent the funds from getting burned?

In a splinternet situation, most miners would probably stop mining in the minority hashrate region since their coins would disappear when connect to the majority hashrate region. So probably no transactions would be confirmed on the minority splintnet anyway.

You can't send to a legacy address. There is no way to construct a tx for doing so. Even if somebody forgot to check and allow the input of old address, a valid tx could not be built, IMO

As far as I know, funds cannot be sent to legacy transactions after non-Seraphis txs would be discontinued on mainnet.

fr33_yourself[m]: you'd need to do a lot of dev work to make a seraphis tx using a legacy address, so no that situation should never occur

Challenge acc... nevermind

Rucknium[m]: how quickly do you think miner's would react? Do you think the miner's are also savvy enough to know what a splinternet is and that they would have the means of detecting that one was implemented within hours of a splinternet implementation?

UkoeHB: Basically wallet software will prevent funds from being sent to legacy addresses by default? No one will accidentally burn funds?

Sorry these are ELI5 questions some technical things I still don't understand clearly

Think of it like a key and a keyhole. If you change keyhole, old key doens't fit. Unless someone takes the time to file the key to make it sort-of-fit (but not actually work).

Gotcha

I'm just trying to ensure that simpletons like me don't accidentally burn XMR post-seraphis

because it is impossible or near impossible by the sounds of it

There are easy ways to prevent that (though you can't of course stop dumbasses making their own code that misuses keys).

fr33_yourself: Check for the latest monero software at GetMonero.org, download it, get it going, and you'll be good to go after any future update. There really isn't anything else you'll need to do.

it would take some very sketchy hackery since jamtis uses x25519 keys for the DH exchange

moneromoooo: I am too big of a dumbass to make my own code so I am safe :)

one-horse-wagon[: I know, I was concerned about a paper wallet that has never touched the GUI software before and was generated using a paper wallet generator.

But looks I will need to bring that online when/if Seraphis is implemented

Not complaining, just making sure I understand correctly

I don't think you have to bring it "online". You will have to generate a new address with an airgapped computer if you want to receive funds after the hard fork.

fr33_yourself: The gist of the Seraphis upgrade is "No Wallet Left Befhind". That is the name of the Matrix room where the developers are meeting. They are taking the task very seriously because some people's life savings are at stake.

gotcha thanks sir

Rucknium[m]: roger, and then I can spend the legacy funds in the cold paper wallet after I download the seraphis software and restore this paper wallet from mnemonic seed?

inside the new seraphis software

fr33_yourself: Yes. Why don't you write a FAQ based on the answers here? They we can link other users to it.

Just ping me when you get other simpletons like me asking questions

and i will answer them

I like talking about monero

haha rucknium getting tired of answering my questions haha

:P Well, it's much more time efficient to answer questions in a FAQ format for all users.