06:15:12 <fRit_^> hello, I have lines with errors in log file. Any ideas? https://zerobin.net/?8dc8e48014d78ab6#LAJeWu/qtBv732AZYKLEodOCFBqTx3de2zfZz9gFIvY=
16:39:34 <Inge-> oof. Ravencoin had a malicious code change entered into their release https://twitter.com/brucefenton/status/1278834104683974656
16:41:15 <hyc> yeah. saw that they released a closed-source binary fix. wtf, are they not an open source project?
16:43:13 <Inge-> just posted here as a reminder to be vigilant.
16:46:33 <hyc> isn't this also the project that recently looked at changing their PoW algo to progpow, randomx, or whatever else?
16:49:06 <hyc> ah, yes it is. https://discord.com/channels/429127343165145089/612279616496730113
16:51:00 <sech1> yes, they changed to a variant of progpow
16:51:13 <sech1> more like the exact copy of progpow
16:58:42 <hyc> but they gave it their own name
16:59:10 <sech1> yes, the name is different
16:59:19 <sech1> but I added support to xmrig and it's the literal copy of progpow
16:59:30 <sech1> just period and epoch length are different
16:59:59 <hyc> ah. well I suppose they need a different name to distinguish it in miners
17:00:27 <hyc> or we can start putting param specs into the name, like ed25519
19:31:00 <fullmetalScience> Are the "hi" and "lo" variables part of the same value? That is, are they separated because the size of their value wouldn't fit into one variable?
19:48:29 <UkoeHB_> fullmetalScience: I have seen code that does that, though it's not clear exactly what you're referring to
19:49:48 <fullmetalScience> I'm looking at get_dynamic_base_fee().
19:50:30 <fullmetalScience> I wonder why lo /= 5 on https://github.com/monero-project/monero/blob/master/src/cryptonote_core/blockchain.cpp#L3363
19:50:47 <moneromooo> Yes.
19:52:20 <sech1> but why "lo /= 5" indeed?
19:52:29 <moneromooo> I don't remember.
19:52:36 <sech1> just to make per byte fees 5 times smaller?
19:53:10 <moneromooo> IIRC there were two equivalent equations for ArticMine's fee system. The equation is in the commit message that adds that fee system.
19:53:34 <UkoeHB_> fullmetalScience: the full justification for that function can be found in section 7.3.4 here: https://web.getmonero.org/library/Zero-to-Monero-2-0-0.pdf
19:53:36 <fullmetalScience> Maybe it's got to do with the F value (.002).
19:54:06 <UkoeHB_> it seems the hi/lo distinction is to make sure there is no integer overflow
19:54:15 <fullmetalScience> Pretty sure since /5 is equal to x.2
19:55:17 <UkoeHB_> "When transaction volume is below the median there is no real reason for fees to be at the reference level [73]. We set the minimum to be 1/5th the default."
19:55:57 <moneromooo> I'll have to read that pdf someday, I've only heard lavish praise about it.
19:56:05 <UkoeHB_> :p
19:56:36 <fullmetalScience> UkoeHB_ Thanks for pasting. Was just about to pull it up :)
19:58:29 <UkoeHB_> JollyMort originally said "It could be argued that something called a minimum should be some level below what an user is willing to pay by default." in his analysis https://github.com/JollyMort/monero-research/blob/master/Monero%20Dynamic%20Block%20Size%20and%20Dynamic%20Minimum%20Fee/Monero%20Dynamic%20Block%20Size%20and%20Dynamic%20Minimum%20Fee%20-%20DRAFT.md
20:00:44 <fullmetalScience> Had been analyzing the entire function and just now noticed the early return of low for anything >= v8 -.-
20:03:09 <moneromooo> Not low. Of limited height.
20:03:48 <UkoeHB_> keep in mind the minimum fee isn't enforced by the blockchain consensus protocol, so any old schemes are only historical curiosities; minimum fee is enforced by the network consensus, meaning transactions won't be relayed if the fee is too low, but blocks containing those transactions _will_ be relayed (afaik)
20:04:01 <moneromooo> schemes of limited age.
20:04:18 <moneromooo> Wait. No. Of great age.
20:05:07 <moneromooo> That rejection is not consensus.
20:05:32 <moneromooo> As you say in your first sentence. So just typo. nvm.
20:06:58 <UkoeHB_> well 'network consensus' loosely means all the rules that most nodes adhere to, a subset of which are the blockchain consensus rules that govern what may be added to the blockchain
20:08:02 <moneromooo> Well, you can call that whatever you like but if you start using consensus for that it's going to confuse people.
20:08:27 <ArticMine> The minimum fee is network consensus, but a block containing a lower fee is still valid
20:08:40 <ArticMine> If the tx get to the miner and the miner mines it
20:29:41 <fullmetalScience> What's currently the lowest weight a tx can have?
20:31:23 <moneromooo> I *think* around 50-55.
20:31:58 <moneromooo> (but might well be wrong)
20:34:37 <fullmetalScience> Hmm. ZtM states 2600 as "typical" for a 2-2 tx. @UkoeHB_ (?)
20:35:13 <moneromooo> Sounds about right.
20:35:41 <fullmetalScience> Is typical == minimum?
20:35:49 <moneromooo> Obviously not.
20:36:18 <fullmetalScience> Well not that obvious (to me fwiw :)
20:37:51 <fullmetalScience> Better said: How's the typical 50 times heavier that the minimum?
20:39:55 <moneromooo> Range proofs are the heaviest. Something like... 800 bytes I think ? And 400 for the second one.
20:40:06 <moneromooo> Then the MLSAGs are next.
20:40:30 <moneromooo> Couple hundred bytes each I think. Very roughly, order of magnitude.
20:40:39 <moneromooo> Then you have random stuff like extra.
20:40:59 <moneromooo> 50-55 would be an unspendable coinbase tx.
20:41:33 <moneromooo> It has a dummy^H^H^H^H^Hmumblemumble input, no MLSAGs, no outputs.
20:42:07 <moneromooo> Empty extra, so I think it's unspendable.
20:44:07 <fullmetalScience> I got disconnected.
20:44:32 <moneromooo> <+moneromooo> Range proofs are the heaviest. Something like... 800 bytes I think ? And 400 for the second one.
20:44:35 <moneromooo> <+moneromooo> Then the MLSAGs are next.
20:44:38 <moneromooo> <+moneromooo> Couple hundred bytes each I think. Very roughly, order of magnitude.
20:44:41 <moneromooo> <+moneromooo> Then you have random stuff like extra.
20:44:43 <moneromooo> <+moneromooo> 50-55 would be an unspendable coinbase tx.
20:44:46 <moneromooo> <+moneromooo> It has a dummy^H^H^H^H^Hmumblemumble input, no MLSAGs, no outputs.
20:44:49 <moneromooo> <+moneromooo> Empty extra, so I think it's unspendable.
20:44:55 <fullmetalScience> Thanks
20:45:17 <moneromooo> My numbers are on the low side, but the oom is right.
20:45:57 <moneromooo> Actually that might be in zero to monero :)
20:47:45 <fullmetalScience> I'm trying to verify my formula, by checking against the real world fees I recently paid.
20:48:54 <fullmetalScience> Those were around .00001800. However I only actually reach such low levels if I define tx weight at around 1700 bytes.
20:49:43 <fullmetalScience> Or wait, does the cli give me the actual weight those tx's had?
20:50:03 <moneromooo> IIRC 1700 is about right for a 1 in 2 out. So... that means a MLSAG is 900 bytes ? That doesn't seem right.
20:50:12 <moneromooo> Something's wrong and I'm not sure what :)
20:52:27 <moneromooo> OK, 800 bytes per MLSAG then. A lot heavier than I thought.
20:52:39 <moneromooo> Well, MLSAG+rest of ring stuff.
20:52:49 <fullmetalScience> I'm not (yet) saying my formula is correct.
20:53:42 <fullmetalScience> I stripped it of all the things that should be "default" (as long as block size <= 300 kB).
20:54:28 <fullmetalScience> Will any CLI or RPC command report tx weights?
20:54:35 <moneromooo> Yes.
20:54:42 <moneromooo> get_transactions at least.
20:55:31 <moneromooo> er.. it doens't. WTF.
20:56:20 <moneromooo> Well, I'll add adding it to my list.
20:57:45 <fullmetalScience> *happy*
21:25:35 <fullmetalScience> https://imgur.com/a/Y8RUB5g
21:27:12 <fullmetalScience> That's the current plot of min fee up to fee at 900 kB block size, if everything else remains the same.
21:28:25 <fullmetalScience> In 10^-8 XMR / bytes
21:34:02 <fullmetalScience> ii really doesn't like me today.
21:53:02 <fullmetalScience> *
22:02:07 <moneromooo> So the reason weight isn't returned is that it's not stored in the first place. You'd have to parse and recalc.
22:03:10 <moneromooo> Now, the txes are parsed if requested to be parsed as JSON. Which tbh is a shitty scheme, it's because I could not figure out how to embed the JSON directly into the reply structure.
22:08:20 <fullmetalScience> "if requested to be parsed as JSON" ?
22:10:57 <moneromooo> if "as_json" is set in the query.
22:16:41 <fullmetalScience> Okay
22:23:47 <UkoeHB_> fullmetalScience: the weight is only bigger than the size in bytes if there are more than 2 outputs
22:24:34 <UkoeHB_> section 7.3.2
22:29:43 <UkoeHB_> just look at any block explorer, 2600 weight for 2-in/2-out, and 1775 weight for 1-in/2-out
22:30:20 <UkoeHB_> you could make bigger transactions by cramming stuff into the tx_extra
22:30:28 <UkoeHB_> but that is 'uncommon'
23:28:26 <fullmetalScience> Perfect! Didn't think of using a block explorer.
23:29:33 <fullmetalScience> Also matches my number which I had estimated at around 1778 based on my recent tx's.