01:20:07 <jeffro256[m]> 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. 
01:21:37 <jeffro256[m]> 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
01:27:27 <Alex|LocalMonero> <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.
01:28:44 <Alex|LocalMonero> jeffro256: you can use a curl command to call monero-wallet-rpc for this: https://www.getmonero.org/es/resources/developer-guides/wallet-rpc.html#export_key_images
01:29:28 <Alex|LocalMonero> Then you can pipe that output to a preferred format with an additional terminal program
01:29:35 <plowsof11> the wallet-rpc has a suspiciously named key_image inside incoming_transfers ,, the wallet-cli also has incomoing_transfers?
01:30:29 <plowsof11> jtgrassie mentions it here https://monero.stackexchange.com/a/11869 
01:33:43 <Alex|LocalMonero> https://github.com/monero-project/monero/issues/7980
01:34:01 <plowsof11> just hard code the fee like mymonero did /s
01:34:09 <plowsof11> simple
01:34:26 <Alex|LocalMonero> 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.
01:35:10 <Alex|LocalMonero> 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.
01:35:58 <Alex|LocalMonero> And, of course, sweep_all requires the entire balance to be sent, which may not be desirable in all cases.
01:40:07 <plowsof11> sweep_all can be the entire balance of a specific subaddress sweep_all fud!!!!
01:41:23 <plowsof11> i think most places just have a hardcoded withdraw fee (enough to cover the onchain transaction with a few picos spare)
01:41:30 <Alex|LocalMonero> Yes but that still isn't good enough. And it doesn't address the multidestination case.
01:41:57 <plowsof11> sweep_all does have outputs=16 (so its half way there)
01:42:40 <Alex|LocalMonero> Point is, it seems like sweep_all code should contain the necessary building blocks to add this functionality to any transfer.
01:43:20 <Alex|LocalMonero> subtractfeefromoutput is a very useful feature
01:43:57 <Alex|LocalMonero> Particularly given that there is no way to know the fee ahead of constructing the transction, unlike with Bitcoin.
01:44:32 <Alex|LocalMonero> Constructing transactions takes time because the wallet needs to communicate with the daemon to build the decoys.
01:45:43 <plowsof11> do_not_relay -> get the fee -> im going to hard code the fee using this value mymonero hardcoded fee version 2.0
01:46:01 <plowsof11> if the fee really does change 1 ms later 
01:46:09 <Alex|LocalMonero> It does, we ran tests.
01:46:44 <plowsof11> implications of hardcoding the fee estimate we got 1ms ago?
01:47:20 <Alex|LocalMonero> 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.
01:47:55 <Alex|LocalMonero> so you have to be piconero-perfect
01:51:11 <plowsof11> 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 
01:57:42 <jeffro256[m]> <plowsof11> "the wallet-rpc has a suspiciousl..." <- Ahhhhhhhh so nice thank you so much. I think that's exactly what I need
01:57:54 <jeffro256[m]> That'll save a lot of time lol
01:57:58 <plowsof11> yeah dont do that 'all these tx's who had ~1% less/more than everything else'
01:59:20 <plowsof11> --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
04:41:18 <hv-bridge> <Jacob269> "5"
05:34:43 <MaddieKalan> 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
05:34:45 <MaddieKalan> 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.
06:25:46 <rbrunner> Seems the mordinals people made a software update: https://twitter.com/m0rdinals/status/1642448369284182017
06:26:45 <rbrunner> 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
06:28:10 <rbrunner> If I look at the mordinals website I see no new ones right now, strange ...
06:32:36 <cockliuser[m]> What's stopping someone from just using the old software
06:32:59 <cockliuser[m]> Did they just update their indexer to ignore fees less than their standard one lol
06:33:15 <cockliuser[m]> So decentralized
06:37:17 <rbrunner> 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 :)
06:40:35 <rbrunner> So it could be that hundreds of lame kitties, lame creatures, lame puppies and GooGirls triggered the mordinals dev into drastic action
06:41:25 <rbrunner> And net result might be more or less the end of the whole spectre already :)
06:58:32 <ofrnxmr[m]> not quite. pos
06:59:13 <ofrnxmr[m]> adding cost to enter meant more for-profit attempts
08:41:26 <DanIsnotthemanBr> whats happens if they dont update monerod to the restricted tx_extra
08:43:31 <sech1> who they? The most important is that mining pools update to v0.18.2.2
12:39:16 <juliadev> 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...
12:39:46 <juliadev> 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.
13:43:12 <juliadev> i'll probably just create a discussion issue on github regarding monero's ipv4 only problem
14:00:15 <selsta> juliadev: I'm not even sure if IPv6 works correctly
14:00:18 <ofrnxmr[m]> ipv4 outgoing or incoming?
14:00:22 <ofrnxmr[m]> print_cn
14:01:31 <ofrnxmr[m]> selsta:  same. lol. but my service provider doesnt do ipv6 properly
14:01:50 <juliadev> welp, i'll probably just shut down my node. i've raised a discussion on github: https://github.com/monero-project/monero/issues/8818
14:02:11 <selsta> IPv6 was added in a PR by an external contributor and never properly supported
14:03:04 <selsta> there were some sybil related concerns that's why currently IPv4 is default / preferred
14:03:40 <juliadev> 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
14:13:55 <Rucknium[m]> juliadev: Do you actually use Julia the programming language or is your username a reference to something else?
14:14:45 <juliadev> 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
16:08:59 <sgp[m]> 😉🤫 https://twitter.com/vikrantnyc/status/1643283451531911170
16:23:57 <JacobGonzales[m]> <sgp[m]> "😉🤫 https://twitter.com/..." <- It’s a custom application I see 
16:24:17 <sgp[m]> Yeah, just an alpha build for now. Beta should be out quite soon
16:24:31 <sgp[m]> Like, soon = <2 weeks :)
16:26:30 <JacobGonzales[m]> This is great I’ll test is there an GitHub repo
16:28:17 <sgp[m]> will be part of the same /cake-tech/cake_wallet repo, but the branch isn't yet live
16:30:02 <guruji[m]> <sgp[m]> "😉🤫 https://twitter.com/..." <- Cake wallet is in Linux already?! Fuck me 😎🥸
16:30:10 <guruji[m]> s/in/on/
16:33:27 <sgp[m]> guruji[m]: Want the alpha build? I can send it your way. Emphasis on the alpha, but it does work
16:59:05 <modul8[m]> <sgp[m]> "😉🤫 https://twitter.com/..." <- i wonder why an operating system called tails still doesnt have a monero wallet installed by default :) oh look cake is everywhere.
17:34:21 <rbrunner> In 10 minutes we will have 24 hours without a single new visible mordinal.
17:36:13 <rbrunner> 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.
17:45:46 <r4v3r23[m]> <modul8[m]> "i wonder why an operating system..." <- feather or monero-gui would be the only default tails candidates 
17:46:14 <r4v3r23[m]> surprised feather isnt included already
17:53:58 <k4r4b3y[m]> PrestiumOS showing the way
17:55:08 <vikCake[m]> <modul8[m]> "i wonder why an operating system..." <- We will do a Monero only one too based on our monero.com wallet.
18:14:43 <bridgerton[m]> <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.
18:14:43 <bridgerton[m]> wait so fees went up because of morbinals, or is it because of the PR. That shouldn't be live on mainnet, is it?
18:26:36 <rbrunner> No, the mordinals dev themselves modified fee calculation in their forked Monero software, to be exponentially more expensive the larger the mordinal
18:27:34 <rbrunner> 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
18:28:29 <mrfoxpro[m]> Hey! I want to run public Monero node.
18:28:29 <mrfoxpro[m]> There are two settings in Monero configuration i found confusing: `zmq-rpc-bind-port` and `zmq-pub`.
18:28:29 <mrfoxpro[m]> 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?
18:28:29 <mrfoxpro[m]> 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?
18:41:54 <bridgerton[m]> <BobbedBort> > No, the mordinals dev themselves modified fee calculation in their forked Monero software
18:41:54 <bridgerton[m]> Thanks I haven't heard about this development. I assume it was a compromise of sorts from them?
18:44:39 <rbrunner> https://twitter.com/m0rdinals/status/1642448369284182017
18:44:55 <rbrunner> You can now also "transfer" mordinals
18:45:21 <rbrunner> You could almost get the impression that the mordinals devs take NFTs seriously, but almost nobody else ...
18:45:36 <bridgerton[m]> <BobbedBort> oh yes I've heard about that. I haven't heard about any transfers being made
18:45:42 <bridgerton[m]> * being made tho
18:46:16 <rbrunner> Well, there is not much of any value and attractivness to transfer in the first place, IMHO
18:48:08 <bridgerton[m]> <BobbedBort> yea, it's just mass minted images for a community that stands the farthest from NFTs
18:49:01 <bridgerton[m]> <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
18:50:25 <bridgerton[m]> <salami donators!> I didn't build anything
18:52:29 <luna24[m]> <rbrunner> "You could almost get the..." <- Is this just nfts on monero bc😂
19:04:27 <Rucknium[m]> rbrunner: Updated data on Mordinal transaction volume: https://gist.github.com/Rucknium/67cc9efdf7e43a40c52417611b322d43
19:06:20 <rbrunner> Thanks, interesting as always :)
19:08:12 <rbrunner> So almost 1/4th of daily transactions were mordinals at peak. Impressive for a single stubborn individual heaping garbage into our blockchain ...
19:13:17 <Rucknium[m]> Yes. Close enough. This ^ measures outputs. Mordinals have 2 outputs. The average number of outputs per tx on the blockchain is usually 2.5
19:20:37 <lza_menace> FUK came back swinging :D
20:04:17 <plowsof11> mrfoxpro: i told you to rtfm on the p2pool repository. if you have any confusions about the guide there, ask away 
20:42:03 <jeffro256[m]> Rucknium: not to pester you, but have you checked out https://github.com/monero-project/monero/pull/8815? It implements research lab issue 109
20:44:56 <Rucknium[m]> jeffro256: Yes. I have read your PR summary. I am digesting it.
20:45:12 <Rucknium[m]> Maybe I will add comments to the PR later. Current Qs:
20:45:34 <Rucknium[m]> 1) What happens when an old wallet version connects to a new monerod version?
20:46:10 <Rucknium[m]> 2) What happens when an old monerod version connects to a new wallet version?
20:46:50 <Rucknium[m]> 3) What kind of checks can we do to make sure that the intended distribution is roughly unchanged?
20:46:52 <Rucknium[m]> I can't read the code by the way
20:48:31 <jeffro256[m]> 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
20:49:18 <jeffro256[m]> That's okay if you can't read it btw, I just wanted to make sure you knew it existed 
20:50:28 <plowsof11> could i test this on testnet by making a bunch of transactions? 
20:50:46 <jeffro256[m]> Yup! Should be functional as-is 
20:50:53 <Rucknium[m]> 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?
20:50:53 <jeffro256[m]> Please let me know if its not lol
20:51:25 <plowsof11> "either coinbase enotes or non-coinbase enotes." what does this either/or mean? do we get all coinbase rings if we select that somewhere?
20:52:53 <jeffro256[m]> 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
20:53:44 <Rucknium[m]> 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
20:54:23 <jeffro256[m]> 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 
20:55:06 <jeffro256[m]> plowsof11: exclusive OR, so any ring should include any coinbase enotes XOR non-coinbase enotes 
20:55:26 <jeffro256[m]> *any -> only 
20:56:12 <Rucknium[m]> Right. Coinbase outputs must be spendable by wallet2 of course.
20:56:57 <jeffro256[m]> They are spendable, and they use a gamma distribution over coinbase-only enotes 
20:57:28 <jeffro256[m]> This picking may not accurately reflect how miners spend their enotes, however 
20:58:38 <Rucknium[m]> 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.
20:58:48 <Rucknium[m]> Then* construct
21:00:11 <jeffro256[m]> Is this test for specifically NON-coinbase?
21:00:15 <Rucknium[m]> There is not a quickly accessible definition of "support" in statistics online :(
21:00:54 <Rucknium[m]> IMHO, we are concerned with non-coinbase the most. Privacy of coinbase outputs is already pretty low.
21:01:38 <Rucknium[m]> I guess we want to check coinbase outputs, too.
21:01:48 <jeffro256[m]> We should expect the distributions of non-coinbase spending to be off by approximately the portion of coinbase enotes / total enotes, yeah?
21:01:52 <Rucknium[m]> Any time the DSA is altered, we want to triple-check it.
21:01:59 <jeffro256[m]> Agreed 
21:02:46 <Rucknium[m]> Define "off"
21:03:51 <jeffro256[m]> I guess the average age of the distribution should stay the same actually 
21:04:10 <Rucknium[m]> You can probably try to re-run tests that jberman did back in mid-2021
21:04:31 <Rucknium[m]> By test I mean to regenerate rings
21:05:05 <jeffro256[m]> Okay, this is the input I needed
21:06:42 <jeffro256[m]> Time to decoy flood stagenet lol
21:07:24 <jeffro256[m]> Thank you!
21:07:25 <Rucknium[m]> jberman's decoy test code is here I think: https://github.com/monero-project/monero/pull/7821
21:08:31 <Rucknium[m]> 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.
21:09:42 <Rucknium[m]> If you can generate the data, I can check with my intuition and any formal tests if needed.
21:10:09 <jeffro256[m]> Awesome I really appreciate that!
21:11:21 <Rucknium[m]> Generate....100,000 rings, let's say. If you cannot get them in ring form but only individual decoys, that's OK too.
22:03:12 <r4v3r23[m]> whats the reason for the 16 max output protocol rule
22:03:17 <r4v3r23[m]> is it linked to ring size? 
22:11:57 <Rucknium[m]> r4v3r23: No. The ring size and 16 max output is now a coincidence.
22:12:49 <Rucknium[m]> 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.
22:17:24 <r4v3r23[m]> ok, so its likely to stay 16 for the forseeable future then
22:17:26 <r4v3r23[m]> thanks
22:18:44 <ofrnxmr[m]> not really
22:19:08 <ofrnxmr[m]> if anything it could drop to 2
22:20:18 <ofrnxmr[m]> theres nothing showing 16 to be a good number afaik. Equally no reason for it to stay the same
22:21:40 <ofrnxmr[m]> there is already discussion aboutstandardizing outputs and (or) tx chaining
22:22:42 <r4v3r23[m]> then why was 16 chosen
22:23:10 <ofrnxmr[m]> same reason txextra is 100kb
22:23:19 <ofrnxmr[m]> random number afaik
22:24:18 <nioc> not random but I forget why
22:24:31 <ofrnxmr[m]> it definitely wasnt chosen to allow spam
22:24:44 <ofrnxmr[m]> and definitely want chosento enhance privacy
22:24:53 <nioc> talking about 16 outs
22:24:55 <Rucknium[m]> Look in meeting logs, git commit messages, Zero to Monero or Mastering Monero for references maybe.
22:25:00 <ofrnxmr[m]> wasnt*
22:25:26 <r4v3r23[m]> nioc: outputs or txextra
22:25:27 <ofrnxmr[m]> i think something to do with binning or some other size math 
22:25:39 <nioc> something about size efficiency 
22:25:43 <boog900[m]> 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 
22:25:44 <nioc> outputs
22:26:12 <nioc> something something batching 
22:26:31 <nioc> r4v3r23[m]: outouts
22:26:33 <plowsof11> does my brain see a graph(s) from sarang in relation to boog900s comment
22:26:42 <ofrnxmr[m]> ie random number that could change to 2
22:27:14 <nioc> 13 would be a random #  :)
22:27:20 <ofrnxmr[m]> i just see randomnumbers
22:27:34 <ofrnxmr[m]> "could" my ass
22:27:47 <ofrnxmr[m]> 16 is amateur spam
22:27:53 <ofrnxmr[m]> inputs weigh more
22:28:39 <ofrnxmr[m]> (... iirc)
22:29:27 <anonimauzanto[m]> r4v3r23: This merge might help to track down more details if you're interested. It's from 2018-09-11 https://github.com/monero-project/monero/commit/7e67c52fa2a4ee68437a5fd906d9848a2f0a7150
22:29:57 <plowsof11> 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 @ https://www.getmonero.org/2020/12/24/Bulletproofs+-in-Monero.html
22:30:38 <ofrnxmr[m]> permitted means (?)
22:30:43 <nioc> 2, 4, 8, 16
22:31:20 <ofrnxmr[m]> yeah ^ those are the options lol
22:31:56 <nioc> :)
22:34:02 <ofrnxmr[m]> all i mean to say is there is no reason 16 will stick around 
22:34:27 <r4v3r23[m]> unless is was chosen for a specific reason
22:34:34 <ofrnxmr[m]> or 4,8 for that matter
22:34:39 <plowsof11> "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" @ https://medium.com/@jkendzicky16/monero-xmr-analysis-746cf0f656b1 
22:34:41 <nioc> to allow multiple outs 
22:34:49 <plowsof11> seems like 16 was just decided as being "enough" but not "too much" ?
22:35:03 <ofrnxmr[m]> aka random #
22:35:19 <nioc> also usefulness 
22:35:32 <ofrnxmr[m]> for who lmfap
22:35:53 <ofrnxmr[m]> its just another glaring security hole
22:35:59 <ofrnxmr[m]> yawn
22:36:00 <plowsof11> 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
22:36:38 <nioc> for sending multiple txs you don't have to wait for that unlock thing, or prepare to send multiple txs ahead of time
22:36:45 <politicalweasel[> 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 
22:36:45 <ofrnxmr[m]> localmonerodoesnt need 16 out.
22:36:45 <ofrnxmr[m]> for who?
22:37:19 <nioc> for those that need it  :D
22:37:24 <ofrnxmr[m]> its an ugly hack at a privacy removal
22:37:53 <nioc> guess it was designed for merchants and exchanges 
22:38:04 <nioc> not little old me
22:38:12 <ofrnxmr[m]> agreed
22:38:27 <ofrnxmr[m]> and its terrible for user privscy
22:38:29 <anonimauzanto[m]> Notes here too, that might be related: https://github.com/monero-project/monero/releases/tag/v0.13.0.2
22:38:36 <ofrnxmr[m]> ando designed for attackers
22:38:38 <ofrnxmr[m]> also
22:38:39 <r4v3r23[m]> ofrnxmr[m]: why
22:38:43 <nioc> ADOPTION !!
22:38:58 <anonimauzanto[m]> " finally sets the max transaction size at half of the penalty free block size"; "Blocks now have a max weight for a single transaction"
22:39:22 <nioc> THX FOR rtfm <3
22:39:28 <ofrnxmr[m]> regular users dont send 16 outs
22:39:52 <ofrnxmr[m]> every 16out in a regular persons ring can be excluded
22:40:06 <ofrnxmr[m]> as cab the 4+ in most cases
22:40:33 <politicalweasel[> not necessarily
22:40:41 <ofrnxmr[m]> lol
22:40:41 <nioc> sorry for capslock
22:40:43 <plowsof11> the only time i would use a 16 output is just cus "sweep_all" accepts outputs=16 
22:41:07 <politicalweasel[> payout from mining pools, exchanges
22:41:07 <plowsof11> if im sending to self / splitting 1 input 
22:41:10 <plowsof11> and feeling lazy
22:41:39 <ofrnxmr[m]> politicalweasel[: yea
22:41:46 <ofrnxmr[m]> those arent reg user tx
22:41:54 <ofrnxmr[m]> those are exchanges tx
22:42:08 <politicalweasel[> ...who do you think they're sending to?
22:42:09 <politicalweasel[> users
22:42:24 <ofrnxmr[m]> if i buy and priduct or service, its 2 out
22:42:35 <politicalweasel[> sure but thats not all usage 
22:42:46 <ofrnxmr[m]> plowsof laughing at me b uz i cant tyoe properlylolol
22:42:50 <politicalweasel[> you said they can be identified as decoys which isnt rly true
22:42:57 <ofrnxmr[m]> it is true
22:43:21 <r4v3r23[m]> 🍿
22:43:21 <ofrnxmr[m]> ofrnxmr[m]: ^
22:43:40 <nioc> ask ist hmus
22:43:46 <ofrnxmr[m]> you never send 16 outs to anyone buy yourself
22:44:15 <politicalweasel[> and if an exchange/pools sends a 16 out, those outputs are going to users. so obviously its possible theyre the real spend
22:44:29 <r4v3r23[m]> ofrnxmr[m]: who cares. once is you spend youre just another tx
22:44:36 <ofrnxmr[m]> nobody is talking out exchange privacy
22:44:42 <r4v3r23[m]> s/is//
22:44:48 <politicalweasel[> i think you're missing the point
22:44:55 <ofrnxmr[m]> r4v3r23[m]: whatt??
22:45:28 <ofrnxmr[m]> you spend a 1/2 with 15 decoys tgat are 1/16,
22:46:14 <ofrnxmr[m]> its obvious which is the real spend
22:46:21 <ofrnxmr[m]> and not a hypothetical
22:46:41 <ofrnxmr[m]> 30% ring size decrease from morbinals and coinbase
22:46:43 <politicalweasel[> why? What if I buy from an exchange or get a payout from a pool and then send some XMR to my friend?
22:46:50 <ofrnxmr[m]> lets add 16 outs and consolidations
22:46:59 <nioc> ofrnxmr[m]: from discussion in MRL I think that you are overstating
22:47:13 <nioc> the problem
22:47:14 <ofrnxmr[m]> politicalweasel[: if you send to your fruend, you send a 2 out
22:47:29 <ofrnxmr[m]> nioc: i talk on the phone too
22:47:34 <r4v3r23[m]> ofrnxmr[m]: spending from a 16-output split reveals the true spend...?
22:47:38 <politicalweasel[> we're talking about inputs, not outputs
22:47:51 <ofrnxmr[m]> holdthe thought
22:48:21 <ofrnxmr[m]> im running on crippled hw right now and this is too painful to type properly
22:48:39 <ofrnxmr[m]> finish up when i get back online 
22:48:41 <nioc> I gave up thinking, I let others do it for me  :)
22:54:27 <RavFX> Crippled hardware... ofrnxmr don't know what im using right now for chat ;) Probably using bloated software :p
22:55:03 <ofrnxmr[m]> my phone through scrcpy
22:55:28 <ofrnxmr[m]> using ssh and vnc to control from my tablet (which is my node)
22:55:43 <ofrnxmr[m]> phone screen rip
22:57:09 <RavFX> 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.
23:00:22 <ofrnxmr[m]> yea, its usually what im on 24/7
23:01:02 <ofrnxmr[m]> got everything backed up, just need a new phone now. i posted in off topic