Monero Research Lab Meeting - Wed 20 November 2024, 17:00 UTC

[Rucknium]

Location: Libera.chat, #monero-research-lab | Matrix

Time: 17:00 UTC Check in your timezone

Main discussion topics:

1. Greetings

2. Updates. What is everyone working on?

3. FCMP++ tx size and compute cost and MAX_INPUTS/MAX_OUTPUTS

4. Making transaction weight a function of number of inputs, outputs, and tx_extra length instead of number of bytes.

5. Discussion: preventing P2P proxy nodes.

6. Any other business

7. Confirm next meeting agenda

Please comment on GitHub in advance of the meeting if you would like to propose an agenda item.

Logs will be posted here after the meeting.

Meeting chairperson: Rucknium

Previous meeting agenda/logs:

#1109

[Rucknium]

Logs

< r​ucknium:monero.social > Meeting time! #1112

< r​ucknium:monero.social > 1) Greetings

< c​haser:monero.social > hello

< a​rticmine:monero.social > Hi

< rbrunner > Hello

< v​tnerd:monero.social > hi

< j​effro256:monero.social > Howdy

< 0​xfffc:monero.social > Hi everyone

< r​ucknium:monero.social > 2) Updates. What is everyone working on?

< r​ucknium:monero.social > me: I put up a docs website for my xmrpeers R package: https://rucknium.github.io/xmrpeers/reference/index.html . The txpool archiver now stores key images, too, so it is easier to retrospectively measure intentional or unintentional double spend attempts.

< v​tnerd:monero.social > finished up span changes in monerod, working on merging PRs in LWS, and frontend for LWS

< r​ucknium:monero.social > My Monerotopia talk "Hard Data on Banking the Unbanked through Cryptocurrency" is up: https://vimeo.com/1029005523 https://github.com/Rucknium/presentations/blob/main/Rucknium-Monerotopia-2024-Banking-the-Unbanked.pdf . Thanks to xenumonero for voicing it. To answer the question from last time, the estimated aggregate spending on goods and services in the EU in 2022 using cryptoc<clipped message

< r​ucknium:monero.social > urrency was €4.1 billion. (90% confidence interval: €1.7 to €6.6 billion).

< a​rticmine:monero.social > Scaling changes to support FCMP++ One the questions I am looking at are changes in TX size when an additional layer is added to the FCMP++

< r​ucknium:monero.social > Two CCS proposal that we have discussed are now on the Ideas page: "Audit monero-serai and monero-wallet" https://repo.getmonero.org/monero-project/ccs-proposals/-/merge_requests/518 and "Gingeropolous 1TB MRC upgrade" https://repo.getmonero.org/monero-project/ccs-proposals/-/merge_requests/516

< r​ucknium:monero.social > Declare your thoughts with your thumbs.

< j​effro256:monero.social > Someone brought up an interesting question at the conference: FCMP++ unifies all anonymity pools, including pre-RingCT. How much money is actually tied up in unspent pre-RingCT outputs? I believe we can actually answer this question with 0 uncertainty if take the sum of "amount*(num_outs_of_amount-num_rings_of_amount)" for each amount. This is because previously, we only allowed r<clipped messag

< j​effro256:monero.social > ings to contain inputs of equal amount

< j​effro256:monero.social > Can anyone see a problem with this approach? I'll work on a script today that calculates it just for fun

< s​gp:monero.social >_ Hello

< j​effro256:monero.social > Hi sgp

< j​berman:monero.social > waves

< j​berman:monero.social > Sorry I might be a sporadically available dealing with a personal issue atm

< r​ucknium:monero.social > jeffro256: I don't know enough about how the pre-RCT protocol works, but your idea sounds very interesting.

< r​ucknium:monero.social > Usually my first step when building the Monero tx database is to delete pre-RingCT data :D

< j​effro256:monero.social > Regarding the CCS proposals, since multiple researchers have need for higher compute requirements, I'm totally okay with the 1TB upgrade CCS

< a​rticmine:monero.social > jeffro256: This should be doable with zero error. I also believe it is important to preserve the pre-ring CT block chain data and to make it easily available to the public in order to not give the blockchain surveillance companies an advantage

< r​ucknium:monero.social > 3) FCMP++ tx size and compute cost and MAX_INPUTS/MAX_OUTPUTS

< r​ucknium:monero.social > https://gist.github.com/kayabaNerve/c42aeae1ae9434f2678943c3b8da7898 monero-project/research-lab#100 (comment)

< r​ucknium:monero.social > Is kayabanerve available for this agenda item?

< r​ucknium:monero.social > Anyone else have thoughts about introducing a MAX_INPUTS limit and/or changes to the current MAX_OUTPUTS limit, with the FCMP++ hard fork activation?

< c​haser:monero.social > I'm generally in favor of any of the limits (except 2/2) in order to increase tx uniformity

< s​gp:monero.social >_ I defer to kayaba's analysis and opinion on this

< r​ucknium:monero.social > Good thing I have these typing notifications, or I would have moved on to the next item already :P

< b​oog900:monero.social > I actually did this at one point, could dig it out again, I remember there been quite a bit still there

< r​ucknium:monero.social > 4) Making transaction weight a function of number of inputs, outputs, and tx_extra length instead of number of bytes.

< r​ucknium:monero.social > IMHO, the protocol currently already has an implicit tradeoff value between verification time and tx size because of the Bulletproofs clawback. Does anyone know of any meeting logs or anything where the tradeoff was discussed?

< a​rticmine:monero.social > My preference with this is to eliminate TX weight entirely out of consensus

< a​rticmine:monero.social > This should be addressed if needed at the node relay level

< a​rticmine:monero.social > It is redundant especially with the proposed input and output proposals

< a​rticmine:monero.social > I was by the way involved in the tx weight department

< a​rticmine:monero.social > Development

< r​ucknium:monero.social > Doesn't consensus need some concept of tx weight to decide how much of the tail emission is not emitted when a miner mines a block above the aggregate penalty weight?

< a​rticmine:monero.social > We just use the actual transaction size in bytes

< a​rticmine:monero.social > No need to add an additional weight for verification time

< a​rticmine:monero.social > The latter was the idea behind the tx weight s

< s​gp:monero.social >_ Verification time would still not directly be related to transaction size though right?

< j​effro256:monero.social > Note that this would break economically if the transaction format ended up being malleable

< a​rticmine:monero.social > If the concern is a possible attack this can be dealt with by node relay

< s​gp:monero.social >_ Consensus seems like a far preferable way to address this to me

< r​ucknium:monero.social > For the potential malleability issue, I think you can just set a safeguard limit on tx size with respect to the input/output/tx_extra size

< j​effro256:monero.social > And then we end up hitting arbitrary limits during the next stressnet ;)

< a​rticmine:monero.social > With the proposed limitations in numbers of inputs and outputs 4 maybe 8 or 16. I really do not see the point

< a​rticmine:monero.social > It just adds un necessary complexity to consensus

< a​rticmine:monero.social > ... and the potential for bugs

< r​ucknium:monero.social > I think jeffro256 means "malleable" as if the tx fee is set by the number of inputs and outputs, and someone figures out how to pack more data into the input or outputs than expected, then tx size could be very large. A little like Ordinals getting a discount on data when putting it in the SegWit part of BTC blocks.

< j​effro256:monero.social > Yes

< j​effro256:monero.social > Malleable was the wrong word

< a​rticmine:monero.social > But we have a consensus limit on the number of inputs and outputs to certain discreet values

< s​gp:monero.social >_ I'm for skipping unnecessary complexity, but my understanding is that verification time cost can still be detached from size by a meaningful amount

< r​ucknium:monero.social > If the tx fee is set by number of bytes, it will be much easier for an adversary to guess which wallet software constructed each tx because wallet developers do not exactly match the reference software fee algorithm.

< s​gp:monero.social >_ I'm wading through kayaba's writings in search for the right numbers to compare

< a​rticmine:monero.social > Weights does not help with this

< a​rticmine:monero.social > The reason this was introduced is that at the time there was a choice between 1 and 16 outpouts

< a​rticmine:monero.social > Now the choice could at most between 4 and 16 outputs

< a​rticmine:monero.social > With no other choices in-between

< r​ucknium:monero.social > My suggestion is not to go with weights, as they exist today. But to set tx fees as a function of inputs, outputs, and tx_extra length. Two txs with the same ins/outs and tx_extra today can have different tx weights because the number of bytes is different, by chance.

< s​gp:monero.social >_ The reason kayaba recommended the specific multiplier in the transaction is to enforce specific fees, in this proposal per the weight. In theory it could be against size as ArticMine wants, afaict

< s​gp:monero.social >_ Maybe we need data on how different verification time is versus size for various transaction combinations before making a decision. Kayaba may have already done that but it's hard for me to read. If there's a single digit % difference then I lean ArticMine's way of simplicity

< a​rticmine:monero.social > Fees belong in node relay., and outside of consensus

< rbrunner > Not sure I understand. Then somebody can mine themselves a tx with any fee?

< v​tnerd:monero.social > then a miner could still “stuff” a longer to verify tx in a block? I don’t see anything wrong with doing it at both levels

< a​rticmine:monero.social > The miner can always do this by providing an off chain rebate or recruiting an off chain payment

< a​rticmine:monero.social > This is why fees must never be baked into consensus

< s​gp:monero.social >_ Yeah but this would allow a discernable on-chain, publicly-visible mark on transactions. Isn't that something we should at least try to make more difficult?

< s​gp:monero.social >_ The goal isn't to prevent miner fee sillyness (off chain dealing etc), it's transaction uniformity

< a​rticmine:monero.social > This issue is and can be addressed by node relay

< r​ucknium:monero.social > Consensus is baked into fees, I guess. The consensus rules on block size increase are activated by the interaction of fees and miners' self-interest. So the fees have to be set with the consensus rules in mind.

< a​rticmine:monero.social > Yes of course

< a​rticmine:monero.social > ... but the fees have also to keep in mind the free market

< s​gp:monero.social >_ consensus would require the majority of miners to agree to stupid fees; it would not allow a specific rogue miner to act stupidly like relay would do

< a​rticmine:monero.social > Fees can become really stupid over time

< j​effro256:monero.social > Look, I might be in the minority here, but I'm much much less worried about uniformity with FCMP++ since now the EXTERNAL impact is very much mitigated. It used to be that weird fees cause everyone's privacy to suffer, but that largely is less true anymore. We should start focusing on UX (off chain reimbursements in this case) when considering tradeoffs IMHO. A relay rule would p<clipped messag

< j​effro256:monero.social > revent silly mistakes for people who aren't colliding with miners

< a​rticmine:monero.social > I agree

< j​effro256:monero.social > Tho I do agree that vtnerd's point is valid : adding heavy txs would basically be free to a miner, but cause a lot of network load if fees aren't asserted at consensus

< a​rticmine:monero.social > ...but we do have and will have consensus rules on the number of inputs and outputs

< a​rticmine:monero.social > We can also limit the size of discretionary fields at consensus

< j​effro256:monero.social > I guess that's not a NEW concern: spam is free up to the penalty-free zone limit. It's just that that 300KB can be packed with more compute requirements

< s​gp:monero.social >_ the only cost before then is opportunity cost, consensus rule or no

< r​ucknium:monero.social > jeffro256: "I'm much much less worried about uniformity with FCMP++ since now the EXTERNAL impact is very much mitigated." I agree with this. IMHO, you can group a lot of de-anonymization "heuristics" into a class of "set intersection attacks". The ring size 16 is a set. Then you intersect that with the set of nonstandard fees. Then other sets if you have the data on it. The origi<clipped message

< r​ucknium:monero.social > nal ring size 16 makes the other set intersection operations much more powerful for an adversary. With FCMP, that initial set size is they whole chain. On the other hand, having as much tx uniformity as possible (especially to prevent against attacks that no one has anticipated yet) is a good goal IMHO.

< r​ucknium:monero.social > And IP address is a set, by the way

< j​effro256:monero.social > Yes uniformity is always a good thing, but you've also got to factor in the difference in the size of the total FCMP set if you bring in more people because of enabled use cases , UX, etc

< r​ucknium:monero.social > So you combine the nonstandard fee with the probable IP origin of a tx.

< r​ucknium:monero.social > I don't understand the UX issue involved here

< s​gp:monero.social >_ UX would be an issue only if terrible multipliers were chosen imo. Eg if moving up to the next tier costs 100x more

< r​ucknium:monero.social > The interaction of the fee tiers, users' economic behavior, and the block size adjustment algorithm is quite untested IMHO.

< r​ucknium:monero.social > Literally untested on mainnet until this year with March spam. A patch to wallet2 had to be released to get the wallet fees to automatically increase

< rbrunner > Wonder how an approach to test that could look, with user behavior in there ...

< r​ucknium:monero.social > You could estimate some demand curves from behavior on other chains, probably

< a​rticmine:monero.social > There is some limited information from early 2017, and also from some of the times that we have gone over the penalty free zone

< a​rticmine:monero.social > What I have seen in those cases is that users have not responded to the market efficiantly

< r​ucknium:monero.social > IIRC, this paper does some empirical demand estimation on BTC: Huberman, G., Leshno, J. D., & Moallemi, C. (2021). Monopoly without a Monopolist: An Economic Analysis of the Bitcoin Payment System, The Review of Economic Studies, 88(6), 3011–3040. https://moneroresearch.info/index.php?action=resource_RESOURCEVIEW_CORE&id=78

< a​rticmine:monero.social > They for example tend to pay a fee that is too low

< s​gp:monero.social >_ imo we have two real options. Pick sane multipliers and strongly enforce, or decide to allow truly arbitrary fees like Bitcoin

< s​gp:monero.social >_ Picking multipliers and then weakly enforcing seems like the worst of both worlds imo

< a​rticmine:monero.social > Any fee multiplayer enforcement has to be at node relay and not at consensus

< k​ayabanerve:matrix.org > Apologies. I'm off by about an hour. That's on me.

< s​gp:monero.social >_ That's not true though right? Kayaba demonstrated how you can do at consensus right? Are you speaking about a miner reimbursing out of band which is a different problem with different considerations?

< r​ucknium:monero.social > I think people pick a fee that is too low since they don't know that the txpool is congested. They just expect it not to be, as it almost always is like that. The auto fee increase in the patch this year helped a little with that.

< k​ayabanerve:matrix.org > My argument was for the fee per weight to be embedded in the TX, not the fee. In order for the TX to balance, the wallet must correctly calculate the TX weight.

< a​rticmine:monero.social > It can be done at consensus. It is not a good idea, because a miner can always circumvent off chain. This then can lead to centralized control

< j​effro256:monero.social > Sorry y'all , I have to dip out for the time being, but will catch up on the chats later. Thanks everyone for participating

< k​ayabanerve:matrix.org > We can still, at node relay rules, penalize specific TX patterns and demand they require a higher fee rate.

< r​ucknium:monero.social > Of course, the question with the auto fee increase is how high should it go? IIRC, right now it moves from the first to the second tier, and doesn't go higher unless manually changed by the user.

< k​ayabanerve:matrix.org > But forcing wallets to calculate the weight correctly should prevent them from being non-uniform with weight calculation.

< a​rticmine:monero.social > My proposal is to simply use the physical size in bytes of the tx and eliminate any weights

< a​rticmine:monero.social > KISS in consensus

< k​ayabanerve:matrix.org > That isn't inherently incompatible with my proposal.

< k​ayabanerve:matrix.org > I think it's wrong though as it harms certain functionality and is annoyingly complicated.

< k​ayabanerve:matrix.org > If we define a simplified weight formula, we never have the annoyance of what a varint is in practice.

< k​ayabanerve:matrix.org > That's where wallets are currently being wrong, causing fingerprinting issues.

< a​rticmine:monero.social > What we are doing is not trying to price verification time

< k​ayabanerve:matrix.org > It also harms pre-signed TXs (transaction chaining). If I sign a TX now, and go to publish it in a year, and the tree has grown a layer, I'll have signed a TX for byte length X and it'll now be byte length Y.

< a​rticmine:monero.social > This is appropriate if we limit the numbers it inputs and outputs

< k​ayabanerve:matrix.org > By using a simplified weight formula dependent on input/output count, we become agnostic to how big the membership proof is in practice.

< k​ayabanerve:matrix.org > I'd agree if we did 4/4 and transaction uniformity. I disagree if we allow 16 outputs. That justifies a clawback existing, as we have now, IMO.

< k​ayabanerve:matrix.org > *I'd agree we don't have to price verification time

< s​gp:monero.social >_ Thanks kayaba this is helpful

< k​ayabanerve:matrix.org > I still think weight shouldn't equal bytes due to the pre-signing usecase I mentioned and the complexities of calculating TX size ahead of time

< a​rticmine:monero.social > Yes this is a serious issue. The fee has to remain the same after a layer change

< k​ayabanerve:matrix.org > Since a layer change always increases the amount of bytes, that requires we pay by input count or prefix size, not by TX size.

< k​ayabanerve:matrix.org > Prefix size should be a valid alternative but it is a really really broad thing to do as it makes inputs as expensive as outputs, when by verification time, it's no where close.

< s​gp:monero.social >_ Speaking of KISS, is there a reason not to use powers of 2 as the allowed multipliers? And to set the default fee selection logic to be in effect "pick the lowest power of 2 that's likely to get me into the next block"

< r​ucknium:monero.social > We are twenty-five minutes over the hour. We can end the meeting time here, but feel free to continue discussing. Maybe someone could make a research-lab issue about it. We didn't get to the "Preventing P2P proxy nodes" item today, but we can get to it next meeting.

< a​rticmine:monero.social > There are two ways of doing this. One is to normalize the proof size by using weights to the initial number of layers. So the transaction weight does not change. The other is to change the minimum penalty free zone size.

< a​rticmine:monero.social > I really do like weighting the proof size to the initial number of layers

< s​gp:monero.social >_ The larger the multiplier differences, the greater the incentive there is to work with a mining pool on a fee rebate etc

< r​ucknium:monero.social > sgp_: AFAIK, two potential issues with that: 1) We don't know how well block size auctions actually work with just discrete bids allowed. Right now the 4-tiers are just a wallet convention, but wallets software can be changed easier than consensus rules. 2) If fees are discrete but weight is not, then users who happen to have a high tx weight (but the same fee as others) will be s<clipped message

< r​ucknium:monero.social > tuck at the back of the confirmation queue for a long time. Maybe until the txpool empties completely.

< a​rticmine:monero.social > So yes using a fixed weight instead of the actual size for the proof size would be the most elegant way to deal with the proof Bauer issue

< s​gp:monero.social >_ Miners are given a block weight to fill though right? Not a true, byte block size?

< a​rticmine:monero.social > Correct

< r​ucknium:monero.social > Right now the default block template creation behavior is first-in/first-out for txs on the same fee-per-weight tier

< s​gp:monero.social >_ since the fee per weight is the same, and miners pick (by default) for fee per weight, I don't quite get the back of the queue issue

< r​ucknium:monero.social > AFAIK, the raw fee in Seraphis was supposed to be an exponential power. That does not get you discrete fee-per-weight since weight is basically continuous.

< r​ucknium:monero.social > So you would have to define the discrete fee as fee-per-weight, not the raw fee.

< r​ucknium:monero.social > AFAIK, the Seraphis fee field in the tx was supposed to be an exponential power.

< s​gp:monero.social >_ that's similar to what we are discussing here, right? Defining the fee per weight (the multiplier) in the tx. And I'm suggesting specifying a power of 2 in there

< r​ucknium:monero.social > IIRC, txs do not say what their size nor weight is. You have to calculate that "manually". So you would have to change how that is handled in the data that txs carry.

< k​ayabanerve:matrix.org > ArticMine: Then we're back at not using TX size yet a formula dependent on the amount of inputs, outputs, and length of TX extra 😅

< k​ayabanerve:matrix.org > Because we're proposing using input_proof_base_cost * inputs instead of those actual proof sizes.

< k​ayabanerve:matrix.org > It doesn't have to be a complicated and long formula. I just wanted something better defined than 'build and test serialize a TX and also know how to handle XYZ variable length fields properly'.

< k​ayabanerve:matrix.org > If we define all the constants in the formula to be the byte lengths seen within a TX, that's still a massive step up.

< a​rticmine:monero.social > What we could do is set a fixed weight for the transaction excluding any discretionary fields based upon the number of inputs and outputs. This weight would be used instead of the proof and non discretionary fields size. In determining the TX weight . I would leave any discretionary fields if they are allowed outside of this calculation.

< k​ayabanerve:matrix.org > input_proof_base_cost + (input_ additional_cost * inputs) + output_proof_base_cost + (output_additional_cost * outputs) + tx_extra_len

< k​ayabanerve:matrix.org > Where cost can simply be the byte length expected for such items

< k​ayabanerve:matrix.org > As long as we define actual constants, and the only variables are inputs/outputs/length of TX extra, I'd be significantly happier.

< a​rticmine:monero.social > Yes based upon the initial proposed number of layers in the proofs

< a​rticmine:monero.social > This will also make me much happier

< k​ayabanerve:matrix.org > Cool

< k​ayabanerve:matrix.org > As of right now, fee, decoy selection, is in the way.

< k​ayabanerve:matrix.org > Even after FCMP++, the reference block and associated tree will be in the way.

< k​ayabanerve:matrix.org > *the fee field is a varint meaning calculation of the fee itself affects the fee as the calculated fee may have a distinct length than used in the calculation

< a​rticmine:monero.social > What I see is that we need defined weights for each allowed combination of inputs and outputs and any other required fields

< a​rticmine:monero.social > Tx extra if allowed would also have to have defined limits in bytes

< a​rticmine:monero.social > So this effectively makes transaction weights discreet at consensus, which is fine

< a​rticmine:monero.social > ... and solves the layer issue on scaling

< a​rticmine:monero.social > So all I would need is the proposed weight of a 4 in 4 out tx with no additional discretionary fields.

< a​rticmine:monero.social > ... and the appropriate estimated actual size with the initial number of layers in the proofs

< a​rticmine:monero.social > If we have discrete tx weights then we have discrete fees at each fee level

< k​ayabanerve:matrix.org > https://github.com/kayabaNerve/fcmp-plus-plus/blob/develop/crypto%2Ffcmps%2Fsrc%2Flib.rs#L127

< k​ayabanerve:matrix.org > This code exists for the FCMP itself (which is not the entire set of FCMP++ proofs).