A UTXO on bitcoin is simply a public key that still has coin attached to it, hence the "unspent" part. A ring signature in monero is a type of digital proof which proves that at least one of the public keys that a transaction is trying to spend from signed this transaction.

Speaking of ouputs, does anyone know that easiest way to get the key image of an unspent output in monero-wallet-cli? Right now I have been doing export_key_images and writing custom code to read the file and extract the key images I need

<jeffro256[m]> "Speaking of ouputs, does..." <- Yeah this is a big UI flaw, there doesn't seem to be an easy way to do it in the CLI.

jeffro256: you can use a curl command to call monero-wallet-rpc for this: getmonero.org/es/resources/develope…s/wallet-rpc.html#export_key_images

Then you can pipe that output to a preferred format with an additional terminal program

the wallet-rpc has a suspiciously named key_image inside incoming_transfers ,, the wallet-cli also has incomoing_transfers?

jtgrassie mentions it here monero.stackexchange.com/a/11869

just hard code the fee like mymonero did /s

simple

Alex|LocalMonero: This issue has been open for over 2 years, and I feel that this is pretty basic functionality. There are many cases where you want the receiver to bear the fee.

sweep_all does that, but it only allows one destination address, whereas you might want to include multiple destinations and subtract the fee from one of them.

And, of course, sweep_all requires the entire balance to be sent, which may not be desirable in all cases.

sweep_all can be the entire balance of a specific subaddress sweep_all fud!!!!

i think most places just have a hardcoded withdraw fee (enough to cover the onchain transaction with a few picos spare)

Yes but that still isn't good enough. And it doesn't address the multidestination case.

sweep_all does have outputs=16 (so its half way there)

Point is, it seems like sweep_all code should contain the necessary building blocks to add this functionality to any transfer.

subtractfeefromoutput is a very useful feature

Particularly given that there is no way to know the fee ahead of constructing the transction, unlike with Bitcoin.

Constructing transactions takes time because the wallet needs to communicate with the daemon to build the decoys.

do_not_relay -> get the fee -> im going to hard code the fee using this value mymonero hardcoded fee version 2.0

if the fee really does change 1 ms later

It does, we ran tests.

implications of hardcoding the fee estimate we got 1ms ago?

In the time between building the first and second tx the fee often changes, by about 1%. Which may not seem like much but it becomes an issue when you're building txs that use up a set of utxos.

so you have to be piconero-perfect

theres probably bad things that would happen if you hardcoded the fee estimate you got 1 ms ago and then realise 6 months later youve spammed the chain with .00042069 fee transactions

<plowsof11> "the wallet-rpc has a suspiciousl..." <- Ahhhhhhhh so nice thank you so much. I think that's exactly what I need

That'll save a lot of time lol

yeah dont do that 'all these tx's who had ~1% less/more than everything else'

--no-initial-sync if you're using wallet-rpc and dont want to wait for the wallet file to be synced until you can say hello

<Jacob269> "5"

Someone probably already said this but to fix ordinals couldn't we just mix our transactions with other transactions that don't have tx_extra unless we do have tx_extra, in whitch case we only mix with tx_extra and also force tx_extra to be 1Mib encrypted blob, or you know, get rid of tx_extra entirely. I mean yeah I get it, then we'd have 2 types of transactions but if we really need tx_extra, I

don't see a better way. Aaaaany way, just wanted to make sure this idea has already been heard, better to ask redundently and increase the chance people think its good, then to not ask and make the chance of the solution being thought about, 0.

Seems the mordinals people made a software update: twitter.com/m0rdinals/status/1642448369284182017

Included is a steep increase in fees, if I read that correctly, it shall cost now 0.04 XMR (about USD 6) to mint a 10 KB mordinal with their software

If I look at the mordinals website I see no new ones right now, strange ...

What's stopping someone from just using the old software

Did they just update their indexer to ignore fees less than their standard one lol

So decentralized

I was wondering the same, but I think you nailed it: If the mordinals viewer does not show it, your mordinal might as well not exist :)

So it could be that hundreds of lame kitties, lame creatures, lame puppies and GooGirls triggered the mordinals dev into drastic action

And net result might be more or less the end of the whole spectre already :)

not quite. pos

adding cost to enter meant more for-profit attempts

whats happens if they dont update monerod to the restricted tx_extra

who they? The most important is that mining pools update to v0.18.2.2

hi, I have set p2p-ignore-ipv4=1 in my .conf for monerod, but it still trying ipv4 nodes for some reason. I'm trying to run a public ipv6 only node for shits and giggles...

and no, the host does not have IPv4 connectivity, I have only configured IPv6. that's why I'm trying to turn it off too.

i'll probably just create a discussion issue on github regarding monero's ipv4 only problem

juliadev: I'm not even sure if IPv6 works correctly

ipv4 outgoing or incoming?

print_cn

selsta: same. lol. but my service provider doesnt do ipv6 properly

welp, i'll probably just shut down my node. i've raised a discussion on github: monero-project/monero #8818

IPv6 was added in a PR by an external contributor and never properly supported

there were some sybil related concerns that's why currently IPv4 is default / preferred

that sucks... i'll try to contribute to ipv6 in the form of code once i'm more comfortable with c++, as it's required for the modern internet... for now maybe i can get the ball rolling by opening a disussion, who know

juliadev: Do you actually use Julia the programming language or is your username a reference to something else?

no, julia is my name irl, i would have chosen julia as a nick, but it's taken, so i went with juliadev, it's my mc nickname. i sometimes dev, but i mostly do networking/sysadmin stuff

😉🤫 twitter.com/vikrantnyc/status/1643283451531911170

<sgp[m]> "😉🤫 twitter.com..." <- It’s a custom application I see

Yeah, just an alpha build for now. Beta should be out quite soon

Like, soon = <2 weeks :)

This is great I’ll test is there an GitHub repo

will be part of the same /cake-tech/cake_wallet repo, but the branch isn't yet live

<sgp[m]> "😉🤫 twitter.com..." <- Cake wallet is in Linux already?! Fuck me 😎🥸

s/in/on/

guruji[m]: Want the alpha build? I can send it your way. Emphasis on the alpha, but it does work

<sgp[m]> "😉🤫 twitter.com..." <- i wonder why an operating system called tails still doesnt have a monero wallet installed by default :) oh look cake is everywhere.

In 10 minutes we will have 24 hours without a single new visible mordinal.

Imprinting a mordinal of around 1 KB costs about half a dollar now ... which seems to have the result that nobody wants to play anymore so far.

<modul8[m]> "i wonder why an operating system..." <- feather or monero-gui would be the only default tails candidates

surprised feather isnt included already

PrestiumOS showing the way

<modul8[m]> "i wonder why an operating system..." <- We will do a Monero only one too based on our monero.com wallet.

<BobbedBort> > Imprinting a mordinal of around 1 KB costs about half a dollar now ... which seems to have the result that nobody wants to play anymore so far.

wait so fees went up because of morbinals, or is it because of the PR. That shouldn't be live on mainnet, is it?

No, the mordinals dev themselves modified fee calculation in their forked Monero software, to be exponentially more expensive the larger the mordinal

And we guess the way they "enforce" the use of their software, with proper fee level, is only showing mordinals with enough fee paid in their viewer web app

Hey! I want to run public Monero node.

There are two settings in Monero configuration i found confusing: `zmq-rpc-bind-port` and `zmq-pub`.

Should ports defined in `zmq-pub` and `zmq-rpc-bind-port` be the same? If not, which one should be opened to public? Does `restricted-rpc` affects API opened on ZMQ?

And If I'm running P2Pool on same machine for mining, that is required to connect through ZMQ, which port should I supply to P2Pool?

<BobbedBort> > No, the mordinals dev themselves modified fee calculation in their forked Monero software

Thanks I haven't heard about this development. I assume it was a compromise of sorts from them?

You can now also "transfer" mordinals

You could almost get the impression that the mordinals devs take NFTs seriously, but almost nobody else ...

<BobbedBort> oh yes I've heard about that. I haven't heard about any transfers being made

* being made tho

Well, there is not much of any value and attractivness to transfer in the first place, IMHO

<BobbedBort> yea, it's just mass minted images for a community that stands the farthest from NFTs

<BobbedBort> I'm seriously interested if they have even made a single penny out of this venture. Because there were surely many expenses, from getting the sites up to minting to possibly hiring people/programmers

<salami donators!> I didn't build anything

<rbrunner> "You could almost get the..." <- Is this just nfts on monero bc😂

rbrunner: Updated data on Mordinal transaction volume: gist.github.com/Rucknium/67cc9efdf7e43a40c52417611b322d43

Thanks, interesting as always :)

So almost 1/4th of daily transactions were mordinals at peak. Impressive for a single stubborn individual heaping garbage into our blockchain ...

Yes. Close enough. This ^ measures outputs. Mordinals have 2 outputs. The average number of outputs per tx on the blockchain is usually 2.5

FUK came back swinging :D

mrfoxpro: i told you to rtfm on the p2pool repository. if you have any confusions about the guide there, ask away

Rucknium: not to pester you, but have you checked out monero-project/monero #8815? It implements research lab issue 109

jeffro256: Yes. I have read your PR summary. I am digesting it.

Maybe I will add comments to the PR later. Current Qs:

1) What happens when an old wallet version connects to a new monerod version?

2) What happens when an old monerod version connects to a new wallet version?

3) What kind of checks can we do to make sure that the intended distribution is roughly unchanged?

I can't read the code by the way

1) Nothing, everything functions exactly the same 2) Right now it gives a descriptive error message and tells you to update the daemon. This can easily be changed, but I figured that this shouldn't be backwards compatible in this case since it relates to privacy, but I'm open to discussion on this point 3) Idk if I understand this question

That's okay if you can't read it btw, I just wanted to make sure you knew it existed

could i test this on testnet by making a bunch of transactions?

Yup! Should be functional as-is

By (3) I mean that the DSA uses a particular age distribution where the support is all outputs. We are changing the support to just the non-coinbase outputs. Is the age distribution roughly the same now?

Please let me know if its not lol

"either coinbase enotes or non-coinbase enotes." what does this either/or mean? do we get all coinbase rings if we select that somewhere?

Rucknium[m]: Ahhh ok. This I'm not sure. It uses the same gamma distribution picker over just the coinbase enotes XOR just the non-coinbase enotes, but I don't know if that's appropriate for the coinbase enote distribution

I think for now it's OK to use the specified gamma for both. But we would want to test to make sure that the intended logic in your code is what actually comes out

I would imagine that this is adequate for non-coinbase since the distribution of picking over just non-coinbase is largely unchanged to picking over non-coinbase and coinbase with only 1 output a long (100) block unlock time

plowsof11: exclusive OR, so any ring should include any coinbase enotes XOR non-coinbase enotes

*any -> only

Right. Coinbase outputs must be spendable by wallet2 of course.

They are spendable, and they use a gamma distribution over coinbase-only enotes

This picking may not accurately reflect how miners spend their enotes, however

A simple test is something like this: Construct many ring with the current DSA. That defines some distribution over time. The construct many rings with your code. Determine if, empirically, the distributions are roughly the same.

Then* construct

Is this test for specifically NON-coinbase?

There is not a quickly accessible definition of "support" in statistics online :(

IMHO, we are concerned with non-coinbase the most. Privacy of coinbase outputs is already pretty low.

I guess we want to check coinbase outputs, too.

We should expect the distributions of non-coinbase spending to be off by approximately the portion of coinbase enotes / total enotes, yeah?

Any time the DSA is altered, we want to triple-check it.

Agreed

Define "off"

I guess the average age of the distribution should stay the same actually

You can probably try to re-run tests that jberman did back in mid-2021

By test I mean to regenerate rings

Okay, this is the input I needed

Time to decoy flood stagenet lol

Thank you!

jberman's decoy test code is here I think: monero-project/monero #7821

Use testnet to check for bugs, but it would be best to check the decoy distribution on mainnet (construct rings but do not broadcast) since that's the more realistic distribution.

If you can generate the data, I can check with my intuition and any formal tests if needed.

Awesome I really appreciate that!

Generate....100,000 rings, let's say. If you cannot get them in ring form but only individual decoys, that's OK too.

whats the reason for the 16 max output protocol rule

is it linked to ring size?

r4v3r23: No. The ring size and 16 max output is now a coincidence.

I don't know what the "official" reason is. People say that it improves transaction uniformity and makes output spamming for black marble/flooding attacks harder.

ok, so its likely to stay 16 for the forseeable future then

thanks

not really

if anything it could drop to 2

theres nothing showing 16 to be a good number afaik. Equally no reason for it to stay the same

there is already discussion aboutstandardizing outputs and (or) tx chaining

then why was 16 chosen

same reason txextra is 100kb

random number afaik

not random but I forget why

it definitely wasnt chosen to allow spam

and definitely want chosento enhance privacy

talking about 16 outs

Look in meeting logs, git commit messages, Zero to Monero or Mastering Monero for references maybe.

wasnt*

nioc: outputs or txextra

i think something to do with binning or some other size math

something about size efficiency

the outputs are capped at 16 because bulletproofs size scales logarithmicly when you increase the amount of outputs but its verification time scales linearly and fees are calculated based on size so if it was not capped someone could spam the chain I don't know why 16 was chosen specifically though

outputs

something something batching

r4v3r23[m]: outouts

does my brain see a graph(s) from sarang in relation to boog900s comment

ie random number that could change to 2

13 would be a random # :)

i just see randomnumbers

"could" my ass

16 is amateur spam

inputs weigh more

(... iirc)

r4v3r23: This merge might help to track down more details if you're interested. It's from 2018-09-11 monero-project/monero 7e67c52

what mean ", the number of outputs in a transaction is effectively rounded up to the next power of two for range proving purposes, with a maximum of 16 outputs permitted in a transaction. " under efficiency @ getmonero.org/2020/12/24/Bulletproofs+-in-Monero.html

permitted means (?)

2, 4, 8, 16

yeah ^ those are the options lol

:)

all i mean to say is there is no reason 16 will stick around

unless is was chosen for a specific reason

or 4,8 for that matter

"Range proofs scale linearly with respect to the number of outputs in a transaction, meaning multiple-output transactions must contain a corresponding amount of proofs. Range proofs make up a significant majority of the transaction size and are the precise reason why XMR transactions are so much larger" @ medium.com/@jkendzicky16/monero-xmr-analysis-746cf0f656b1

to allow multiple outs

seems like 16 was just decided as being "enough" but not "too much" ?

aka random #

also usefulness

for who lmfap

its just another glaring security hole

yawn

my brain wants to see a curvy line on a graph, and for sarang to say in a calm voice ' this line right here shows that 16 is the sweet spot ' and then we all live happily ever after

for sending multiple txs you don't have to wait for that unlock thing, or prepare to send multiple txs ahead of time

i think 16 was chosen because allowing higher would mean effectively rounding to the next power of 2. 17 outputs would take as long as 32, 33 -> 64, etc. 16 allows batching without allowing too much insanity

localmonerodoesnt need 16 out.

for who?

for those that need it :D

its an ugly hack at a privacy removal

guess it was designed for merchants and exchanges

not little old me

agreed

and its terrible for user privscy

Notes here too, that might be related: github.com/monero-project/monero/releases/tag/v0.13.0.2

ando designed for attackers

also

ofrnxmr[m]: why

ADOPTION !!

" finally sets the max transaction size at half of the penalty free block size"; "Blocks now have a max weight for a single transaction"

THX FOR rtfm <3

regular users dont send 16 outs

every 16out in a regular persons ring can be excluded

as cab the 4+ in most cases

not necessarily

lol

sorry for capslock

the only time i would use a 16 output is just cus "sweep_all" accepts outputs=16

payout from mining pools, exchanges

if im sending to self / splitting 1 input

and feeling lazy

politicalweasel[: yea

those arent reg user tx

those are exchanges tx

...who do you think they're sending to?

users

if i buy and priduct or service, its 2 out

sure but thats not all usage

plowsof laughing at me b uz i cant tyoe properlylolol

you said they can be identified as decoys which isnt rly true

it is true

🍿

ofrnxmr[m]: ^

ask ist hmus

you never send 16 outs to anyone buy yourself

and if an exchange/pools sends a 16 out, those outputs are going to users. so obviously its possible theyre the real spend

ofrnxmr[m]: who cares. once is you spend youre just another tx

nobody is talking out exchange privacy

s/is//

i think you're missing the point

r4v3r23[m]: whatt??

you spend a 1/2 with 15 decoys tgat are 1/16,

its obvious which is the real spend

and not a hypothetical

30% ring size decrease from morbinals and coinbase

why? What if I buy from an exchange or get a payout from a pool and then send some XMR to my friend?

lets add 16 outs and consolidations

ofrnxmr[m]: from discussion in MRL I think that you are overstating

the problem

politicalweasel[: if you send to your fruend, you send a 2 out

nioc: i talk on the phone too

ofrnxmr[m]: spending from a 16-output split reveals the true spend...?

we're talking about inputs, not outputs

holdthe thought

im running on crippled hw right now and this is too painful to type properly

finish up when i get back online

I gave up thinking, I let others do it for me :)

Crippled hardware... ofrnxmr don't know what im using right now for chat ;) Probably using bloated software :p

my phone through scrcpy

using ssh and vnc to control from my tablet (which is my node)

phone screen rip

I see. Yeah, that would be more crippled than my overclocked 486 DX2 (IRC comp mostly). It have some local TLS proxy shenanigans to support TLS.

yea, its usually what im on 24/7

got everything backed up, just need a new phone now. i posted in off topic