00:05:44 <anarkiocrypto[m]> Unlisted fundraisers should work now.
00:23:14 <r4v3r23[m]> https://monero.observer/anonero-releases-anon-v0.4/
00:23:17 <r4v3r23[m]> nice update
00:34:29 <plowsof11> didn't they rename? or
00:35:20 <plowsof11> im thinking of the wallet from pokst? 
00:36:52 <plowsof11> mysu.dev (who renamed recently) is not anonero, ok this was my confusion
00:54:44 <bridgerton[m]> <Bon 💗> The app seems pretty good actually it has onion and proxy on it
00:55:02 <bridgerton[m]> <Bon 💗> It doesn't seem to have any exchanges tho or hard ledger function yet
00:57:08 <LZA_MENACE> meh, keep it simple
00:59:10 <bridgerton[m]> <Bon 💗> Fair enough
00:59:22 <bridgerton[m]> <Bon 💗> Have you tried it and is it actually good
03:40:25 <bridgerton[m]> <Bon 💗> Similar to what the guy above me posted by what they actually advertise about the new Anonero wallet.
03:40:25 <bridgerton[m]> https://cdn.discordapp.com/attachments/620459189097201669/1089755768422678528/Screenshot_20230326-195301.png
05:32:01 <dANBs[m]> kittypity[xmpp]: Is there a way to install mongodb, nodejs, nodejs express and react as a standalone executable or package? I don't want to fuck with package dependencies issues because I have to use old mongodb
05:32:05 <dANBs[m]> kittypity[xmpp]: Oops
05:41:10 <DanIsnotthemanBr> Only postrges with monerod ;)
06:07:53 <riceandbeans> If you have a wallet and the password for it, can you get the mnemonic for it just in case to back up?
06:08:09 <riceandbeans> Or would you need to make a new wallet, send everything there.
06:09:20 <hyc> you can always display the seed if you have the passphrase
06:09:29 <riceandbeans> How does one do that
06:09:45 <hyc> use the monero-wallet-cli and type "help" for a list of commands
06:18:57 <riceandbeans> Ah, I got it, thanks
12:44:19 <sech1> mordinals are really spamming their shit now: "XMR blocks above 300k   : 23.3 %"
12:44:25 <sech1> usually it's 2-3%
12:47:48 * ofrnxmr[m] uploaded an image: (95KiB) < https://libera.ems.host/_matrix/media/v3/download/monero.social/xONMpwroXKeGFflqeDJkphuJ/gan3tfbj4x7w3pt3.jpg >
12:49:44 * ofrnxmr[m] uploaded an image: (115KiB) < https://libera.ems.host/_matrix/media/v3/download/monero.social/PoHkJLFGvUsGMdfAJHswZzLJ/dsnw5s68g1agrji9.jpg >
12:52:32 <XMRPriest[m]> 😭😬
12:53:02 <ofrnxmr[m]> Of course, either they are incompetent or dont want to commit suicide 
12:53:32 <ofrnxmr[m]> Otherwise,im not sure why they are doing school zone speed limits 
12:53:56 <ofrnxmr[m]> Actually, its obvious
12:54:29 <ofrnxmr[m]> They really dont want usbto remove Txextra. If they did, they'd turn the printer on full
12:55:20 <XMRPriest[m]> We let a fox in the chicken pen to play nice but this is what we get, pr
12:55:25 <sech1> or they're just limited by 10 block lock time before sending new transactions
12:55:45 <ofrnxmr[m]> Sech, there are ways around the limit
12:55:56 <ofrnxmr[m]> It only costs 40c to get around it
12:55:58 <sech1> of course, but they require some scripting skills
12:56:08 <ofrnxmr[m]> 😆😆 yeah lmao
12:56:14 <plowsof11> just confirming that i spam testnet not/never mainnet 
12:56:30 <ofrnxmr[m]> Im not confirming anything 
12:57:44 <ofrnxmr[m]> Get it,? Get it? 
12:57:44 <ofrnxmr[m]> "Look at me. Im the txpool now"
12:59:06 <ofrnxmr[m]> walks away sad
13:02:36 <plowsof11> release is coming in the next day(s) - i need ALL our best men and women who have been posting about our interpol agent to get the word out to these mining pools
13:04:13 <plowsof11> another propaganda angle: the mining pools who do not update will allow node hunters to more easily 'find them' as they will stick out - we can use the 'update for security reasons or your nodes going offline' angle
13:04:46 <plowsof11> you get some fud, i get some fud
13:22:49 <cockliuser[m]> Make the wallet UDP flood non-compliant nodes 🚀 
13:25:35 <sech1> v0.18.2.1 has been tagged!
13:25:52 <sech1> which means release in a few of days
13:26:58 <ofrnxmr[m]> <plowsof11> "another propaganda angle: the..." <- Or they can hold 600mb txpools
13:31:19 <r_seed_42> Does anyone have a working monerod config file for a node exposed via tor only (ie. expose no clearnet rpc/p2p ports)?
13:31:49 <r_seed_42> I've cobbled something together that seems to work for the most part, but I keep getting a warning
13:32:03 <r_seed_42> "W Unable to send transaction(s), no available connections"
13:32:45 <plowsof11> sounds like a --tx-proxy thing
13:33:10 <plowsof11> or no tor connections (monerod print_cn) check for tor in/out
13:33:28 <plowsof11> post config paste bin link 
13:34:36 <plowsof11> if this is a long and drawn out affair  #monero-support:monero.social is here for ya 
13:38:37 <r_seed_42> lemme check monerod print_cn first
13:39:20 <r_seed_42> no luck on print_cn
13:39:45 <r_seed_42> "Error: Unsuccessful -- json_rpc_request: "
13:40:51 <ofrnxmr[m]> <plowsof11> "if this is a long and drawn..." <- ^^^^^^^^^^^^^ ^^^^^^^^^^^^^^
13:41:49 <r_seed_42> ack
13:42:05 <ofrnxmr[m]> Tdlr.your config sux cuz u changed rpc ports and did wacky old instructions
13:42:07 <ofrnxmr[m]> But yes, I have a nice one
13:49:49 <r_seed_42> ofrnxmr , can I get a link/copy pretty please? I'd also be happy for up-to-date instructions
13:51:28 <sech1> https://p2pool.io/explorer/ is running v0.18.2.1 now, so it will not show transactions with too large tx_extra in mempool (but will still show them in mined blocks)
13:55:37 <ofrnxmr[m]> https://github.com/nahuhh/android-termux-monero-node/blob/9513c8bbdc07431327fa8d5ceaf407c17dd0107c/src/install-monerod-in-termux.sh#L220... (full message at <https://libera.ems.host/_matrix/media/v3/download/libera.chat/38c94ff93581fc341b4f52f9c58a85897ac46e91>)
13:56:05 <r_seed_42> Thank you
13:57:28 <spackle_xmr[m]> On the topic of (dynamic) block size: I did a few 'back of the envelope' simulations this morning that made me feel better. My rough estimate is that an attacker would need to spend ~1000 XMR to complete a ramp to the longterm block size limit in ~500 blocks (16 hours). Keep in mind those are loose figures from a hobbyist's simulation, but you get the idea.
14:03:14 <AmbiguousYelp[m]> Anyone else unable to pay monero on mullvad rn?
14:57:23 <r4v3r23[m]> <bridgerton[m]> "<Bon 💗> Have you tried it and is..." <- yep its great. still in alpha but performance is excellent. the backup feature is really good oto
14:57:53 <r4v3r23[m]> s/good/useful/, s/oto/too/
15:23:38 <cockliuser[m]> Can I tell the cli to fetch blocks now, validate later for remote syncing?
15:59:56 <vikCake[m]> Hi all.. Cake Wallet for MacOS is out. https://apps.apple.com/us/app/cake-wallet/id1334702542
16:19:11 <rbrunner> The mordinals now are "GooGirls". I googled that to find out whether the collection is original, or whether they steal the NFTs somwhere.
16:19:30 <rbrunner> Well, Google mostly gives me links to pornos if I do that ...
16:19:50 <rbrunner> Brilliant
16:20:30 <cockliuser[m]> It's so low effort too 
16:20:52 <cockliuser[m]> Literally Dall-E 1 shit
16:22:00 <rbrunner> And looks like their minting script has bugs, as they often seem to mint the same girl several times. I am sure they will *all* become precious.
16:22:18 <rbrunner> My respect for this grows by the hour
17:11:12 <xmrfn[m]> Try https://tineye.com maybe?
17:13:47 <ofrnxmr[m]> They're really just being bitches now imo
17:15:28 <rbrunner> I wait for the mordinal devs scolding and attacking the NFT uploaders, because they do it too fast, and wrongly i.e. with duplicates
17:15:54 <rbrunner> Too fast = higher chance for resistance or counter-action
17:16:53 <rbrunner> xmrfn[m]: Thanks for the tip; a test with a googirl picked at random did not get me a match ...
17:18:21 <xmrfn[m]> Compiling takes forever on 1 thread but this is my life right now
17:19:08 <xmrfn[m]> Waiting for the moment my node can join the anti-NFS army
17:19:09 <xmrfn[m]> s/NFS/NFT/
17:19:10 <xmrfn[m]> (typo; I love NFS!)
17:20:21 <ofrnxmr[m]> rbrunner: They threatened worse behaviour because of limiting 
17:21:53 <xmrfn[m]> We could make a patch that just rejects their mordinal-specific flag in tx_extra
17:22:45 <rbrunner> You mean the "50 transactions for 50 KB NFT" threat? Yes, very realistic. I tried to sketch an implementation in my mind for that, boy that would be PITA to get to work
17:23:40 <rbrunner> But you wouldn't know without Monero codebase and dev knowledge, so that threat maybe finds targets
17:26:40 <rbrunner> If they (mordinal dev team plus all NFT series uploaders) force us into a hardfork I claim they will be restricted to Monero Punks style very small pixel-ly NFTs.
17:29:03 <hyc> the path of least resistance for them would be <whatever fits in tx_extra> certainly
17:29:37 <hyc> I think we could have skipped the hard size limit on tx_extra, and just jacked up the fees. make them exponential with size of tx_extra, for example
17:30:52 <xmrfn[m]> There'd still be a lot of low-entropy data on our chain
17:31:38 <hyc> dunno. if the cost for 1K of data was 1 million times the usual fee, that would make them think twice
17:32:38 <hyc> although miners would prob be happy to mine them. maybe that would still have been a bad idea
17:33:00 <xmrfn[m]> I had been thinking about adding a Shannon entropy check on txns. Reject those less than a threahold. I don't care how it was constructed with low entropy -- for example all but one decoys set to 0 address -- it doesn't belong on the chain
17:33:24 <xmrfn[m]> s/threahold/threshold/
17:33:26 <hyc> yeah, that sort of check has already been suggested
17:34:25 <xmrfn[m]> By apeing the changed Selsta made for the tx_extra length check, I'm partway there. Not sure where to put the calc_tx_entropy method
17:34:30 <xmrfn[m]> s/changed/change/, s/tx_extra/tx\_extra/, s/calc_tx_entropy/calc\_tx\_entropy/
17:34:41 <selsta> sech1 did the change
17:34:49 <selsta> i'm just testing it :P
17:35:00 <xmrfn[m]>  * By apeing the change Sech1 made for the tx_extra length check, I'm partway there. Not sure where to put the calc_tx_entropy method
17:35:21 <xmrfn[m]> my bad, fixed, TY
17:35:30 <xmrfn[m]> I'm only 83% of the way done compiling it :P
17:38:53 <Rucknium[m]> xmrfn: It's probably better to do a formal frequentist statistical check since then you set the false positive rate explicitly.
17:39:16 <Rucknium[m]> MRL discussions go back and forth about whether a statistical check should be researched
17:40:16 <xmrfn[m]> Oh yeah before submitting anything I'd want to dump the value for at least a bunch of blocks, esp comparing pre-mordinals to those containing them
17:40:52 <xmrfn[m]> I bet there's a step change
17:41:05 <xmrfn[m]>  * Oh yeah before submitting anything I'd want to dump the tx entropy values for at least a bunch of blocks, esp comparing pre-mordinals to those containing them
17:46:40 <Rucknium[m]> I don't think a simple entropy check will be the most powerful check. Power: https://en.wikipedia.org/wiki/Power_(statistics)
17:46:41 <Rucknium[m]> But anyway you are welcome to research entropy-based solutions :)
17:47:53 <xmrfn[m]> Is there a way to calculate the Power of a particular bit string?
17:48:37 <Rucknium[m]> A test has power. a bit string does not
17:49:20 <xmrfn[m]> Exactly. Seems like Power is a feature that is more intrinsically of a set. So not clear how it helps identify if a txn that come wallet or miner gave you, hurts fungibility
17:49:29 <xmrfn[m]> s/come/some/
17:51:17 <Rucknium[m]> I don't know how to respond other than it would be good to learn basic statistics
17:51:54 <xmrfn[m]> I don't get what I'm missing. The use-case is that someone hands us a txn, we need to know whether it is acceptable
17:53:51 <xmrfn[m]> One way is to look at tx_extra and see if it is "too big". Or that it has the expected number of decoys. Another perhaps for general way is to calculate the entropy of the blob of bits that make up the tx
17:53:54 <xmrfn[m]>  * One way is to look at tx\_extra and see if it is "too big". Or that the tx has the expected number of decoys. Another perhaps for general way is to calculate the entropy of the blob of bits that make up the tx
17:53:56 <xmrfn[m]>  * One way is to look at tx\_extra and see if it is "too big". Or that the tx has the expected number of decoys. Another perhaps more general way is to calculate the entropy of the blob of bits that make up the tx
17:55:09 <Rucknium[m]> Right. So you use a test to determine if the null hypothesis (tx_extra is random (encrypted) data) is correct. But there are many tests for that. So you want to use the most powerful one so that you have the highest detection rate. Or a very powerful one.
17:55:09 <xmrfn[m]> Given a tx someone hands us, and knowing what you know, suggest a way to know whether the tx acceptable or not, from a fungibility perspective?
17:55:17 <xmrfn[m]> This is about more than tx_extra
17:56:42 <xmrfn[m]> Yes, tests need to be done to know what ther threshold should be. I'm still at the stage of making some code that would just nicely print a number representing the tx entropy
17:56:46 <xmrfn[m]>  * Yes, tests need to be done to know what the acceptance threshold should be. I'm still at the stage of making some code that would just nicely print a number representing the tx entropy
17:57:13 <xmrfn[m]> (which itself might already have been done by someone else)
20:05:37 <xmrfn[m]> I just rediscovered that get_info doesn't actually tell you what version the node is running :/
20:05:37 <xmrfn[m]> 'version: ""`
20:05:45 <merope> Only for the restricted rpc though
20:08:36 <Alex|LocalMonero> <hyc> "I think we could have skipped..." <- If you jack up the tx_extra fees you're effectively redirecting arbitrary data injectors to use steg. So it's steg with extra steps. Just remove tx_extra.
20:10:01 <xmrfn[m]> or make it small enough that its information carrying capacity is not significant
20:10:41 <Alex|LocalMonero> So anyone who wants to mordinal will just steg. Again, steg with extra steps.
20:12:06 <Alex|LocalMonero> Remove tx_extra. Simplify the protocol and improve fungibility/uniformity. If arbitrary data is to be added to the blockchain it should look like any other tx data.
20:12:25 <merope> tx_extra can be pruned though, steg cannot
20:12:56 <Alex|LocalMonero> Pruning is irrelevant to full nodes.
20:13:23 <merope> So is steg
20:13:30 <Alex|LocalMonero> Huh?
20:15:08 <merope> Full nodes don't care if you're using steg or tx_extra to store extra data, so it makes no practical difference to them. But pruned nodes can at least benefit from the option of pruning tx_extra for blocks/txes full of garbage
20:15:53 <Alex|LocalMonero> fungibility/tx uniformity >>>>>>>>>>> prune node less space
20:16:25 <Alex|LocalMonero> you need full nodes unless you want to encourage network centralization
20:16:32 <merope> But steg breaks uniformity anyway, because the transaction graph will look bad anyway
20:16:51 <Alex|LocalMonero> depends on the steg
20:16:54 <Alex|LocalMonero> for CLSAG no
20:17:37 <merope> The tx graph looks bad because the minting process is just a bunch of chained self-spends
20:18:05 <merope> So even if you encrypted your steg data to make it indistinguishable, you're still leaving a trail due to the way the minting process works
20:18:14 <Alex|LocalMonero> Are you talking about CLSAG?
20:18:20 <merope> (Though I guess this point is more specific to the morb stuff)
20:18:53 <merope> I'm thinking of the case of storing data in the ring members
20:19:23 <merope> Not familiar enough with the inner workings of clsag :_
20:19:24 <merope> :/
20:49:25 <xmrfn[m]> okay seriously dumb question: 
20:49:25 <xmrfn[m]> How can you tell what version a remote node is running? I can type "version" on my own monerod, but all I know about for other nodes is to get the restricted RPC port /get_info, and version is blank there
20:51:47 <selsta> you can't know the exact version
20:52:29 <selsta> you can look for get_info fields that were added at a specific version and use it to estimate the version
20:53:39 <xmrfn[m]> hmmm.. OK. is that considered an issue to fix? ie, to have get_info return the version
20:54:40 <selsta> it's intentional
20:55:36 <xmrfn[m]> Not sure I understand why... but I'll accept that
20:56:25 <Rucknium[m]> Node version releases identifying information. Monero is a privacy protocol.
20:57:55 <selsta> hiding the version reduces ways a node can be fingerprinted
20:58:01 <Rucknium[m]> A wallet's relationship with a node is on a need-to-know basis. And the wallet does not need to know the version.
21:01:57 <xmrfn[m]> makes sense