the penalty formula has nothing to do with the fee

moneromooo: that patch looks reasonable to me. the case where block_reward < fee means the miner burned some money, so the total coin supply is decreased. so maybe it makes sense to allow `base_reward` to take negative value to indicate that

though it's a pretty edge case because miners are usually incentivized to claim the maximum allowed reward

or perhaps we can leave it as is, meaning that miner txes aren't allowed to claim less reward than fee. feels reasonable to me

stoffu, " so the total coin supply is decreased." afaiu, it always kicks it down the lane, because the calculation is 18.4 - total emitted , right?

The fees should be paid in full to the miner even if they exceed the block reward.

So if this is not the case it would be a bug.

With the current fee formula when the penalty is maxed out and the block weight is 2x the short term median, this can happen and is necessary for a fee market to prioritize the highest paying transactions.

For that block Monero would behave like Bitcoin

gingeropolous: >>it always kicks it down the lane<< correct in the sense that the supply is indefinite due to tail emission. but this money burning does happen when the miner claims less than the fee; the total supply becomes *smaller* with that block

ArticMine: >>The fees should be paid in full to the miner even if they exceed the block reward.<< if you mean by the block reward the newly generated coins, it's irrelevant

denote the newly generated coins as G, the total fee as F, and the actual claimed reward as R. then the rule is R<= G+F

whether F is greater than G or not is irrelevant; what moneromooo's patch deals with is the case where R<F

currently this case is rejected due to overflow in github.com/monero-project/monero/bl…ryptonote_core/blockchain.cpp#L1214

i think it's fine to forbid miner txes with R<F, i don't see any reason why it should be allowed

sorry, correcting myself >> the newly generated coins as G,<< denote G as the maximum amount of newly generated coins defined by the protocol (emission curve & penalty formula)

the actually generated coins G' is defined as G'=R-F

which can be less than G

Hi guys.

suraeNoether this might sound a bit silly, but say i have a v1 ring signature. I can create a tx by bundling that ring signature alongside new outputs and their amounts

hashing it and firing it off to the wider network

What is to stop someone else from modifying the tx outputs to have a different destination and then relaying the tx?

I guess my question is: if the ring signature covers legitimacy of spending the inputs, what covers spending the outputs?

The signatures also sign the tx prefix, which happen to contain inputs and outputs.

perfect thanks MM

Questions, comments, and/or emoji requested for this research proposal: repo.getmonero.org/monero-project/ccs-proposals/merge_requests/110

:D

suraeNoether: see PM for musings on the relationship between linkability and unforgeability definitions

suraeNoether: I've updated the CLSAG linkability definition and proof, showing that a suitable linkability solver is a forger

It'd be nice to allow for arbitrary (non-challenger) keys in the provided rings, but this wouldn't reduce to unforgeability AFAICT

That being said, this does capture the case where the `q` non-forged signatures were generated using known signing keys

Non-frameability works similarly, but with additional signing oracle access that works with the unforgeability game

suraeNoether: Any advantage to giving the linkability player any signing oracle access? The forgery game would allow this

Right now I don't include it