<r​ecanman:agoradesk.com> 4/9?!

<t​rasherdk:monero.social> 4/8

<r​ecanman:agoradesk.com> Lol

<r​ecanman:agoradesk.com> Lol, thanks

<t​rasherdk:monero.social> Max decentralization 🤪

<r​brunner7:monero.social> Well, quite in general the permissionless and fully decentralized oracle itself is something that looks impossible.

<m​onerobull:matrix.org> i need input

<m​onerobull:matrix.org> matrix.monero.social/_matrix/media/…matrix.org/PddWnjwdBYKjUGVFoVgsbKOa

<m​onerobull:matrix.org> someone tried to be smart and save some money by abusing the guerrilla system ._.

<m​onerobull:matrix.org> bro i subsidize these packages myself ._.

<m​onerobull:matrix.org> what do i do here

<p​lowsof:matrix.org> im not grasping it yet, the totals add up (im assuming this is an attempt at using a discount ('fund a guerrilla") to obtain free product?

<p​lowsof:matrix.org> paying 50 cent - but forcing you to spend 30~ euros?

<c​trej:matrix.org> Is it cheaper then buying a regular package overall?

<m​onerobull:matrix.org> so regular price is about 32,5€

<m​onerobull:matrix.org> the guy funded a package for 26,5 and then bought it

<c​trej:matrix.org> With shipping?

<m​onerobull:matrix.org> nah

<c​trej:matrix.org> Ship proportional fewer stickers for this customer

<c​trej:matrix.org> And you should fix the loophole

<m​onerobull:matrix.org> "Receive a subsidized package funded by a generous Monero Extremist. Please only pick this option when you really can not afford the regular options but are eager to place tons of stickers out in the streets. ONLY ORDER 1 subsidized package, DO NOT ORDER MORE. Any funds from ordering more than 1 package will be regarded as a donation!"

<m​onerobull:matrix.org> i mean the rules are kinda clear

<c​trej:matrix.org> You are already subsidizing the stickers by working for free, no need to subsidize shipping as well

<p​lowsof:matrix.org> a major exploit in the smart contract

<m​onerobull:matrix.org> well i gladly do for the real guerrilla packages

<c​trej:matrix.org> Unfortunately for the hacker its a dumb contract

<m​onerobull:matrix.org> ok ill do it like this

<m​onerobull:matrix.org> if the guy is from a "rich" country it gets confiscated

<m​onerobull:matrix.org> if the guy is from spain, he can get it with less stickers

<m​onerobull:matrix.org> or eastern germany

<m​onerobull:matrix.org> i guess ill offer a refund first

<p​lowsof:matrix.org> send them zcash merch as a punishment

<m​onerobull:matrix.org> That would get me sued for copyright

<e​dge7:matrix.org> which ecommerce you handle?

<m​onerobull:matrix.org> monerosupplies.com

<m​onerobull:matrix.org> uhn

<m​onerobull:matrix.org> uhm

<m​onerobull:matrix.org> plowsof: why can i see amounts

<m​onerobull:matrix.org> matrix.monero.social/_matrix/media/…matrix.org/VUcOHzIIOeNdpDhtwyJfGsvI

<m​onerobull:matrix.org> just kidding this is stagenet. i was still surprised though, thought stagenet is identical to mainnet, or is this a coinbase?

<m​onerobull:matrix.org> oh yeah its coinbase

<e​dge7:matrix.org> man, you miss too many things in comparison with moneromerch.com

<e​dge7:matrix.org> Any plan to upgrade?

<1​23bob123:matrix.org> Yeah but does border security steal there sticks from shipments :)

<a​lpharabius:matrix.org> I'll bet 10 bucks i can get that monero flag in syria within the next 10 years

<m​onerobull:matrix.org> i dont see a point in trying to undercut them

<m​onerobull:matrix.org> id rather do special stuff like the standee or plushie

<n​ihilist001:matrix.org> matrix.monero.social/_matrix/media/…matrix.org/oRNCaLHhwRQXWlfWucgnOrnZ

<n​ihilist001:matrix.org> Check out my swag

NicknameJohn: m-relay

<p​lowsof:matrix.org> anyone heard of shopinbit? just noticed this reddit thread reddit.com/r/Monero/comments/16vg00…ducts_for_xmr_and_also_shipping_now (reminds me of what monero dot shopping but real(?))

<p​lowsof:matrix.org> do we retroactively owe them 800 ish monero 😬 (if you want to see the monero shopping proposal.. seems they removed the amounts repo.getmonero.org/monero-project/ccs-proposals/-/merge_requests/360)

<p​lowsof:matrix.org> 975 xmr*

<e​dge7:matrix.org> Yes I did

<e​dge7:matrix.org> matrix.monero.social/_matrix/media/…matrix.org/GqMDMsAUNKWCHbDOvDClCVuB

<e​dge7:matrix.org> Received my order yesterday

<e​dge7:matrix.org> Had small issue with delivery but not because of them. I contacted them through telegram support channel and fixed quickly the issue

<o​frnxmr:monero.social> "easy shopping with bitcoin" > wants monero to fund them retroactively 🧐

<e​dge7:matrix.org> I paid with monero and got 3% discount. Still too expensive though

<o​frnxmr:monero.social> Plenty of services accept multiple coins.

<o​frnxmr:monero.social> Is this already funded by BTC (or another supported coin's) community?

<o​frnxmr:monero.social> If not, why not?

<o​frnxmr:monero.social> If it is, why do they need us? were poor

<o​frnxmr:monero.social> 975 doesnt sound like monero integration

<o​frnxmr:monero.social> Sounds like fully funded

<c​trej:matrix.org> tried once, item wasn't in stock despite listed as such, got my monero back *shrug*

<e​dge7:matrix.org> Tbh that is the most complete shop I ve seen online where paying in xmr is possible. There is some decent variety

<c​trej:matrix.org> I'd love to see a site that pulls listings from all stores that support monero, and displays them in a single, searchable marketplace

<c​trej:matrix.org> because nobody is gonna check 100 different stores just to see if they have a specific item

ofrnxmr ah sorry, i was joking about the retro funding stuff (totlaly unrelated to monero shopping / not asking for funding)

<b​awdyanarchist:matrix.org> I have a question about change outputs. When you broadcast, let's just say a 1-in-2-out from wallet2, does the change address always occupy a static positional order in the transaction? In other words, is it knowable for an outside observer which output was the spend, and which one was the change?

<r​ucknium:monero.social> BawdyAnarchist: If it's not randomized, it would be a major mistake IMHO. Usually wallet2 makes the right choice with those types of issues. Check the source code or ask in #monero-dev:monero.social

<r​ucknium:monero.social> BIP 69 for bitcoin is supposed to reduce guessibility of the bitcoin change output FWIW: github.com/bitcoin/bips/blob/master/bip-0069.mediawiki

<r​ucknium:monero.social> It's a wallet-level BIP. Wallets don't have to implement it.

<r​ucknium:monero.social> BawdyAnarchist: "Outputs are randomly shuffled by the core implementation before getting assigned an index, so observers can’t

<r​ucknium:monero.social> build heuristics around their order. Inputs are sorted by key image within transaction data."

<r​ucknium:monero.social> Footnote 4 on pp. 50 of _Zero to Monero 2.0_

<b​awdyanarchist:matrix.org> Thanks Ruck! I just read your research on classifying spends with fungibility defects, which is what made me think of the question

<r​ucknium:monero.social> Thanks for reading it. What did you think about it? I titled it "Discussion Note" for a reason :)

<b​awdyanarchist:matrix.org> I thought it was great that you used Monte Carlo to validate the results after calculating a specific solution. I didnt dig into the equations though. Table 1 and 2 were interesting. PPV is significantly worse when a small percentage of outputs have a defect, but much alleviated as you pass 25% of defective outputs. I assume those tables are for "single puddle defects?" So hypoth<clipped message

<b​awdyanarchist:matrix.org> etically, multiple types (droplets) of defects makes the situation much worse?

<r​4v3r23:monero.social> Ruckniumare you still planning on doing an analysis on pocketchange's affect on transactional privacy?

<1​23bob123:matrix.org> Do you have a donate address?

<1​23bob123:matrix.org> Stuff like this css should help with

<1​23bob123:matrix.org> Stuff like this ccs should help with

<r​ucknium:monero.social> BawdyAnarchist: Right. We can take an empirical example.

<r​ucknium:monero.social> I estimated the PPV for several nonstandard fee levels I found on the blockchain in Table "Estimated PPV, beta, and mu_C, in percent" of github.com/Rucknium/misc-research/t…ero-Nonstandard-Fees#tabulated-data

<r​ucknium:monero.social> If you take beta as the prevalence of transactions that have a certain nonstandard fee level, then you can do a weighted average of PPV for the four nonstandard fee levels I identified. They add up to about 10% of recent transactions. Having those four levels is worse than having just a single larger category that composed 10% of transactions.

<r​ucknium:monero.social> The weighted average PPV is 29.8%

<r​ucknium:monero.social> Go to Table 1 in github.com/Rucknium/misc-research/b…o-Fungibility-Defect-Classifier/pdf

<r​ucknium:monero.social> (We also need the probability of spending change to use the table. We can take the weighted average for that, too. It is 32%.)

<r​ucknium:monero.social> If we have beta (% blockchain outputs with defect) at 10% in one large category and mu_C (% rings of defective txs with change output as the real spend) at 30%, the closest value to the weighted average I calculated above, then that PPV is only 19.7%.

<r​ucknium:monero.social> To summarize, the fact that there are multiple small anonymity droplets with nonstandard fee levels means that the average probability of guessing the real spend is 29.8%. If it were one big nonstandard fee category, then that probability would be 19.7%. That's a 10 percentage point difference.

<r​ucknium:monero.social> r4v3r23: In the Feather Wallet channel I said "I might put up a "wish" on my wishlist-as-a-service page to create a formal model and classification rule for an attack on PocketChange."

<r​ucknium:monero.social> I want to do it, but it's a matter of prioritization.

<r​ucknium:monero.social> I need to finish the OSPEAD improvements to the decoy selection algorithm (DSA). The analysis of using fungibility defects is indirectly related to OSPEAD since it can help answer the question of how safe it is to change the DSA at a point in time that is not a hard fork.

<r​ucknium:monero.social> The formula can be used to directly compare the privacy benefit of OSPEAD compared with the "cost" of having multiple wallet2 DSAs on the blockchain at the same time.

<r​ucknium:monero.social> Dan r/dark (Is not the man & Braxman Tomsparks Advocate ): My PGP-signed XMR address is at repo.getmonero.org/monero-project/c…als/-/merge_requests/255#note_18750

<r​ucknium:monero.social> I also have a page for specific projects. Right now the only unfunded project is server costs: rucknium.me/donate

<r​ucknium:monero.social> After I finish OSPEAD I will probably try to transition to part-time 3 month CCS proposals for research like some of the devs do. I would of course take input from the community on which research projects should be prioritized.

<1​23bob123:matrix.org> I was thinking that ccs should at least help

<1​23bob123:matrix.org> Worthy cause

<1​23bob123:matrix.org> reddit.com/r/Monero/comments/16uxj2…ming_jamtis_dynamic_view_tag_design

<b​awdyanarchist:matrix.org> I think I understand a bit better now. You calculated non-standard fee defect puddles, but there are other defects which an adversary could use, and/or combine, to improve PPV. Could including abnormal fee levels as part of the DSA, reduce PPV? Altho, even if true, it does seem a bit inelegant to start expanding the DSA to new parameters like that.

<b​awdyanarchist:matrix.org> I think I understand a bit better now. You calculated non-standard fee defect puddles, but there are other defect categories which an adversary could use, and/or combine, to improve PPV. Could including abnormal fee levels as part of the DSA, reduce PPV? Altho, even if true, it does seem a bit inelegant to start expanding the DSA to new parameters like that.

<b​awdyanarchist:matrix.org> I think I understand a bit better now. You calculated non-standard fee defect puddles, but there are other defect categories which an adversary could use, and/or combine, to improve PPV. Could including abnormal fee levels as part of the DSA, reduce PPV? Altho, even if so, it does seem a bit inelegant to start expanding the DSA to new parameters like that.

<b​awdyanarchist:matrix.org> Oh crap. Sorry, I forgot we're not supposed to edit messages due to the bridge. My bad.

<r​ucknium:monero.social> BawdyAnarchist: IMHO, abnormal fee levels are an implementation "mistake" by wallet developers. Same with nonstandard DSAs and nonstandard tx_extra contents. It's better to fix the mistake.

<r​ucknium:monero.social> In theory a wallet developer that committed a "mistake" could decide to only select decoys (when the user is spending change) that also have the same fungibility defect. It would probably be much easier for the developer to fix the original mistake than to expect them to implement a complicated fix like that.

<r​ucknium:monero.social> Furthermore, the monerod node doesn't tell wallets much info about the characteristics of each output when it is giving the wallets information about the outputs that can be used as decoys. Only age (timing) information is given now through get_output_distribution RPC call IIRC.

<r​ucknium:monero.social> For example, the Mordinals creator suggested that wallets just avoid the Mordinals outputs: nitter.net/m0rdinals/status/1639220577662795776

<r​ucknium:monero.social> A long time ago when Monero had optional ring sizes (including ring size 1!) there were a lot of outputs that were known to be spent. The blackball tool was created to avoid including those outputs: monero.stackexchange.com/questions/…ain-blackball-to-improve-my-privacy

<r​ucknium:monero.social> We don't want to complicate the DSA too much. And we don't want to change it many times when users could be using the old version(s) of the DSA between hard fork dates.

<r​ucknium:monero.social> One exception is coinbase outputs. We will always have coinbase outputs. It's not something that will go out of popularity like Mordinals. With P2Pool outputs, there are a lot of coinbase outputs now. Here is my suggestion for avoiding coinbase outputs in the DSA: monero-project/research-lab #109

<r​ucknium:monero.social> We could implement that at the same time as OSPEAD (once we figure out how safe it is to implement a new DSA outside of a hard fork).

<r​ucknium:monero.social> The ideal solution to transaction fungibility defects is to set protocol rules to not give wallet developers the "choice" to reduce their users' privacy.

<r​ucknium:monero.social> Monero has done that before. Setting mandatory ring size and making the 10 block lock part of consensus rules are two examples.