16:55:29 <m-relay> <c​haserene:matrix.org> thoughts about transaction uniformity and the numbers of inputs/outputs: https://github.com/monero-project/research-lab/issues/114
17:46:30 <m-relay> <r​ucknium:monero.social> chaser: It looks like requiring 2 inputs minimum would increase tx size by 45% for 1in/2out txs. I'm not sure how much privacy gain we get for the larger tx size.
17:48:40 <m-relay> <r​ucknium:monero.social> The number of tx inputs do not persist in a wallet like nonstandard tx fees do. For example, if a user creates a tx with 1 input, their next tx may be a 2 input tx, and vice versa. But if they use a wallet that produces nonstandard fees, that fee is stamped on every tx they make, which can help an observer narrow down the possible real spend in their chain of txs.
17:49:57 <m-relay> <r​ucknium:monero.social> You can calculate the privacy loss from wallet-persistent fungibility defects using the formula I developed: https://github.com/Rucknium/misc-research/tree/main/Monero-Fungibility-Defect-Classifier/pdf
17:50:04 <m-relay> <r​ucknium:monero.social> Application here: https://github.com/Rucknium/misc-research/tree/main/Monero-Nonstandard-Fees
17:50:46 <m-relay> <r​ucknium:monero.social> I don't know how you could calculate the privacy gain from requiring all txs to have at least 2 inputs.
17:53:47 <m-relay> <r​ucknium:monero.social> IMHO, the biggest privacy loss from allowing different numbers of inputs is when user consolidate a large number of outputs. An adversary may know that some of those outputs are owned by a single user. The probability is low that those sets of outputs all appear in several rings in the same tx because they were decoys. The probability that they were the real spends is high.
17:56:45 <m-relay> <r​ucknium:monero.social> See "Juraj Bednár - Analysing Monero Merchants‘ Traffic Using Simple Chainanalysis" https://piped.video/watch?v=-sTT84Up7FY
17:57:32 <m-relay> <r​ucknium:monero.social> You point out that restricting the number of tx inputs to just 2 would severely impact usability.
17:58:03 <sech1> But what if there's physically only one input available in the wallet?
17:59:21 <m-relay> <r​ucknium:monero.social> tevador's dummy tx inputs idea: https://github.com/monero-project/research-lab/issues/96
17:59:32 <m-relay> <r​ucknium:monero.social> "Turns out that the RingCT protocol can support dummy inputs if we make the following consensus change: All transaction input rings implicitly include the pseudo-amount commitment C as one of the ring keys."
17:59:52 <m-relay> <r​ucknium:monero.social> But: "(Unfortunately, the dummy input idea doesn't work with Seraphis AFAICS.)"
18:22:22 <m-relay> <k​ayabanerve:matrix.org> FCMPs can offer a dummy input. the concern is about cost and the linking tag of the dummy (so that it doesn't burn a legitimate enote)
21:43:02 <midipoet> Anyone know any papers/research on energy usage estimation methods for PoW algos? I know the Cambridge methodology, and the Seidlmer (spelling) et al paper, but wondering if anyone knew any other good ones?
21:57:01 <m-relay> <r​ucknium:monero.social> endor00 may know
22:05:27 <m-relay> <e​ndor00:matrix.org> I don't know about the other methodologies, but mine makes two fundamental assumptions: one is that miners are (overall) rational and don't go below 0% profitability, and the other is about the average cost of electricity for the whole network. Based on these, you can calculate the breakeven efficiency, and thus the (maximum) power usage for the whole network
22:06:28 <m-relay> <e​ndor00:matrix.org> I do recall watching a talk that mentioned some estimate for the power usage of Bitcoin, and my estimate was pretty close to theirs
22:09:00 <m-relay> <e​ndor00:matrix.org> I typically assume 0.10 $/kWh - mostly because it's a nice round value and makes calculations easy (electricity price and breakeven efficiency are directly proportional), but also because it feels like a reasonably "in the middle" value
22:10:58 <m-relay> <e​ndor00:matrix.org> `breakeven_efficiency = (difficulty * electricity_cost) / (coin_price * block_reward * 1000 * 3600 ))`
22:11:14 <m-relay> <e​ndor00:matrix.org> `network_power_consumption = nethash / breakeven_efficiency`