02:59:20 the penalty formula has nothing to do with the fee 03:08:09 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 03:10:52 though it's a pretty edge case because miners are usually incentivized to claim the maximum allowed reward 03:21:46 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 04:46:01 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? 05:01:36 The fees should be paid in full to the miner even if they exceed the block reward. 05:02:16 So if this is not the case it would be a bug. 05:07:35 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. 05:09:47 For that block Monero would behave like Bitcoin 05:35:28 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 05:43:12 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 05:44:44 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 05:45:32 whether F is greater than G or not is irrelevant; what moneromooo's patch deals with is the case where R currently this case is rejected due to overflow in https://github.com/monero-project/monero/blob/master/src/cryptonote_core/blockchain.cpp#L1214 05:49:04 i think it's fine to forbid miner txes with R 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) 05:52:40 the actually generated coins G' is defined as G'=R-F 05:55:12 which can be less than G 15:22:28 Hi guys. 15:23:50 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 15:24:03 hashing it and firing it off to the wider network 15:25:13 What is to stop someone else from modifying the tx outputs to have a different destination and then relaying the tx? 15:26:38 I guess my question is: if the ring signature covers legitimacy of spending the inputs, what covers spending the outputs? 15:27:21 The signatures also sign the tx prefix, which happen to contain inputs and outputs. 15:29:59 perfect thanks MM 15:42:14 Questions, comments, and/or emoji requested for this research proposal: https://repo.getmonero.org/monero-project/ccs-proposals/merge_requests/110 16:18:37 :D 16:34:47 suraeNoether: see PM for musings on the relationship between linkability and unforgeability definitions 19:24:25 suraeNoether: I've updated the CLSAG linkability definition and proof, showing that a suitable linkability solver is a forger 19:28:02 It'd be nice to allow for arbitrary (non-challenger) keys in the provided rings, but this wouldn't reduce to unforgeability AFAICT 19:28:40 That being said, this does capture the case where the `q` non-forged signatures were generated using known signing keys 19:29:15 Non-frameability works similarly, but with additional signing oracle access that works with the unforgeability game 19:36:07 suraeNoether: Any advantage to giving the linkability player any signing oracle access? The forgery game would allow this 19:36:17 Right now I don't include it