hello, I have lines with errors in log file. Any ideas? zerobin.net/?8dc8e48014d78ab6#LAJeW…Bv732AZYKLEodOCFBqTx3de2zfZz9gFIvY=

oof. Ravencoin had a malicious code change entered into their release twitter.com/brucefenton/status/1278834104683974656

yeah. saw that they released a closed-source binary fix. wtf, are they not an open source project?

just posted here as a reminder to be vigilant.

isn't this also the project that recently looked at changing their PoW algo to progpow, randomx, or whatever else?

ah, yes it is. discord.com/channels/429127343165145089/612279616496730113

yes, they changed to a variant of progpow

more like the exact copy of progpow

but they gave it their own name

yes, the name is different

but I added support to xmrig and it's the literal copy of progpow

just period and epoch length are different

ah. well I suppose they need a different name to distinguish it in miners

or we can start putting param specs into the name, like ed25519

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?

fullmetalScience: I have seen code that does that, though it's not clear exactly what you're referring to

I'm looking at get_dynamic_base_fee().

I wonder why lo /= 5 on github.com/monero-project/monero/bl…ryptonote_core/blockchain.cpp#L3363

Yes.

but why "lo /= 5" indeed?

I don't remember.

just to make per byte fees 5 times smaller?

IIRC there were two equivalent equations for ArticMine's fee system. The equation is in the commit message that adds that fee system.

fullmetalScience: the full justification for that function can be found in section 7.3.4 here: web.getmonero.org/library/Zero-to-Monero-2-0-0.pdf

Maybe it's got to do with the F value (.002).

it seems the hi/lo distinction is to make sure there is no integer overflow

Pretty sure since /5 is equal to x.2

"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."

I'll have to read that pdf someday, I've only heard lavish praise about it.

:p

UkoeHB_ Thanks for pasting. Was just about to pull it up :)

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 github.com/JollyMort/monero-researc…amic%20Minimum%20Fee%20-%20DRAFT.md

Had been analyzing the entire function and just now noticed the early return of low for anything >= v8 -.-

Not low. Of limited height.

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)

schemes of limited age.

Wait. No. Of great age.

That rejection is not consensus.

As you say in your first sentence. So just typo. nvm.

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

Well, you can call that whatever you like but if you start using consensus for that it's going to confuse people.

The minimum fee is network consensus, but a block containing a lower fee is still valid

If the tx get to the miner and the miner mines it

What's currently the lowest weight a tx can have?

I *think* around 50-55.

(but might well be wrong)

Hmm. ZtM states 2600 as "typical" for a 2-2 tx. @UkoeHB_ (?)

Sounds about right.

Is typical == minimum?

Obviously not.

Well not that obvious (to me fwiw :)

Better said: How's the typical 50 times heavier that the minimum?

Range proofs are the heaviest. Something like... 800 bytes I think ? And 400 for the second one.

Then the MLSAGs are next.

Couple hundred bytes each I think. Very roughly, order of magnitude.

Then you have random stuff like extra.

50-55 would be an unspendable coinbase tx.

It has a dummy^H^H^H^H^Hmumblemumble input, no MLSAGs, no outputs.

Empty extra, so I think it's unspendable.

I got disconnected.

<+moneromooo> Range proofs are the heaviest. Something like... 800 bytes I think ? And 400 for the second one.

<+moneromooo> Then the MLSAGs are next.

<+moneromooo> Couple hundred bytes each I think. Very roughly, order of magnitude.

<+moneromooo> Then you have random stuff like extra.

<+moneromooo> 50-55 would be an unspendable coinbase tx.

<+moneromooo> It has a dummy^H^H^H^H^Hmumblemumble input, no MLSAGs, no outputs.

<+moneromooo> Empty extra, so I think it's unspendable.

Thanks

My numbers are on the low side, but the oom is right.

Actually that might be in zero to monero :)

I'm trying to verify my formula, by checking against the real world fees I recently paid.

Those were around .00001800. However I only actually reach such low levels if I define tx weight at around 1700 bytes.

Or wait, does the cli give me the actual weight those tx's had?

IIRC 1700 is about right for a 1 in 2 out. So... that means a MLSAG is 900 bytes ? That doesn't seem right.

Something's wrong and I'm not sure what :)

OK, 800 bytes per MLSAG then. A lot heavier than I thought.

Well, MLSAG+rest of ring stuff.

I'm not (yet) saying my formula is correct.

I stripped it of all the things that should be "default" (as long as block size <= 300 kB).

Will any CLI or RPC command report tx weights?

Yes.

get_transactions at least.

er.. it doens't. WTF.

Well, I'll add adding it to my list.

*happy*

That's the current plot of min fee up to fee at 900 kB block size, if everything else remains the same.

In 10^-8 XMR / bytes

ii really doesn't like me today.

*

So the reason weight isn't returned is that it's not stored in the first place. You'd have to parse and recalc.

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.

"if requested to be parsed as JSON" ?

if "as_json" is set in the query.

Okay

fullmetalScience: the weight is only bigger than the size in bytes if there are more than 2 outputs

section 7.3.2

just look at any block explorer, 2600 weight for 2-in/2-out, and 1775 weight for 1-in/2-out

you could make bigger transactions by cramming stuff into the tx_extra

but that is 'uncommon'

Perfect! Didn't think of using a block explorer.

Also matches my number which I had estimated at around 1778 based on my recent tx's.