<o​frnxmr:xmr.mx> Seed offsets for xmr generate new wallets (incl addresses)

<o​frnxmr:xmr.mx> Buy the wallet file isnt a secret wallet. Its the offset wallet

<i​mprevisto:matrix.org> subaddresses are sufficient for churn, correct?

<g​ooglemozilla:matrix.org> @kayabanerve:matrix.org If Seraphis was implemented, would that solve this input/output issue? It seems to be extremely bad considering marketplaces will not work anymore.

<k​ayabanerve:matrix.org> That's without a lot of context.

<o​frnxmr:xmr.mx> Incorrect

<g​ooglemozilla:matrix.org> I'm reminded of the block wars that took place on Bitcoin.

<o​frnxmr:xmr.mx> Google, context needed

<k​ayabanerve:matrix.org> Seraphis is irrelevant. A minimum input limit won't break services. It may demonstrate the necessity of aggregation code. That can be demonstrated with the current input limit.

<o​frnxmr:xmr.mx> theyrevreferring to 8/8 4/4 limit proposal

<g​ooglemozilla:matrix.org> Honestly, I'm a bit perplexed. According to @dave.jp:matrix.org , most instant swappers and marketplaces are expected to cease functioning with the new limitation.

<o​frnxmr:xmr.mx> Maximum input*

<k​ayabanerve:matrix.org> There already is an input limit. It's high enough people may not have noticed. Services already need to aggregate to work around it.

<k​ayabanerve:matrix.org> Yes, sorry, maximum input limit.

<o​frnxmr:xmr.mx> Is the concern afaict

<o​frnxmr:xmr.mx> The limit is the tx size

<d​ave.jp:matrix.org> 140s vs 4/8 lol such a small change

<k​ayabanerve:matrix.org> I'm not entertaining a minimum input limit discussion

<g​ooglemozilla:matrix.org> So the worst that could happen is a decline in UX.

<i​mprevisto:matrix.org> huh, so an observer could link one xmr address to another from the same seed?

<o​frnxmr:xmr.mx> It was higher b4 16 decoys

<i​mprevisto:matrix.org> I didn't think that was true.

<o​frnxmr:xmr.mx> Sorry, i read "insufficient"

<k​ayabanerve:matrix.org> ofrnxmr: Yes and that imposes a maximum input count of less than 256.

<k​ayabanerve:matrix.org> So if a service receives 256 transfers of 1 xmr, and attempts to transfer out 256 xmr, they will already error.

<k​ayabanerve:matrix.org> This is already a feasible to hit case in the Monero ecosystem

<o​frnxmr:xmr.mx> it will actually split into multiple tx

<o​frnxmr:xmr.mx> Happens all the time if consolidation thousands of p2pool inputs

<k​ayabanerve:matrix.org> ofrnxmr: If it will actually create and sign two TXs with two partial transfers, that is its own degree of fucked up.

<k​ayabanerve:matrix.org> I'm horrified at the idea a wallet transfer of 256 may become a transfer of 150 and 106.

<g​ooglemozilla:matrix.org> With the new maximum input limit, 256 transfers will decrease to 8. I don't see why this is a problem, other than existing services having to consider a bit more.

<k​ayabanerve:matrix.org> Completely unexpected behavior which absolutely shouldn't be standard.

<k​ayabanerve:matrix.org> But heard if wallet2 is so cursed.

<o​frnxmr:xmr.mx> transfer_split is the default, yep. Thats what it does

<k​ayabanerve:matrix.org> I'd ask for secondary confirmation though.

<o​frnxmr:xmr.mx> > transfer_split¶

<o​frnxmr:xmr.mx> Same as transfer, but can split into more than one tx if necessary.

<o​frnxmr:xmr.mx> docs.getmonero.org/rpc-library/wallet-rpc/#transfer_split

<o​frnxmr:xmr.mx> Vs docs.getmonero.org/rpc-library/wallet-rpc/#transfer

<d​ave.jp:matrix.org> If I have to pay 256 xmr how many do I need to do ? How much 10block wait time ; how much more crippled do I make myself

<o​frnxmr:xmr.mx> See the example json response

<k​ayabanerve:matrix.org> Is transfer the default???

<o​frnxmr:xmr.mx> Thats why its so easy to flood 100kb tx, you just need to sweep_all

<o​frnxmr:xmr.mx> transfer_split is

<k​ayabanerve:matrix.org> What does that mean

<d​ave.jp:matrix.org> If I have to pay 256 xmr how many txs do I need to do ? How much 10block wait time ; how much more crippled do I make myself

<k​ayabanerve:matrix.org> If I type transfer, does that reroute to transfer split

<k​ayabanerve:matrix.org> Where is transfer_split defaulted to

<k​ayabanerve:matrix.org> If I can explicitly call transfer over the RPC, and it doesn't by default redirect to transfer_split, it isn't the default.

<o​frnxmr:xmr.mx> wallet2 afaik. i cant remember where i read it, probably the pr that introduced _split, but `Transfer` is deprecated (but still works)

<k​ayabanerve:matrix.org> And if it by default doesn't redirect to split, as I'm guessing as there's no documented split argument (defaulting to true) to set to false, transfer_split is an option, not the default.

<o​frnxmr:xmr.mx> I think wallet2_api might use split aa default, but rpc still has transfer

<k​ayabanerve:matrix.org> K but if monero-wallet-rpc offers transfer, and transfer doesn't internally redirect to split, than services, which use the RPC, aren't by default using transfer_split

<k​ayabanerve:matrix.org> They just have the option of it. I have no idea what's used in practice

<g​ooglemozilla:matrix.org> I'm guessing that 32 should be consolidated.

<o​frnxmr:xmr.mx> Bsx uses both 😆

<d​ave.jp:matrix.org> Again if I have 256 outputs, how much time before I can spend it ? Without receiver knowing i had too many outputs and tx was split

<g​ooglemozilla:matrix.org> So at least 64 minutes?

<k​ayabanerve:matrix.org> If we set the input limit to 16, this at most adds one spend interval (10 blocks). It has an exponential fan in causing a logarithmic time bound.

<k​ayabanerve:matrix.org> So after just one time bound, if we have a limit of 16, you can spend what was 256 inputs.

<k​ayabanerve:matrix.org> My proposal was 8. The logarithm is 1 and some decimal which rounds up to 2 but also means after 2 spend intervals, you can spend not 256 but 512. That's 40 minutes.

<o​frnxmr:xmr.mx> youd have to create 16 consolidation tx tho?

<d​ave.jp:matrix.org> Will the app consolidate it for me or I have to play around myself ? As a end user don’t expect me to understand what is inputs

<k​ayabanerve:matrix.org> ofrnxmr: I ack split exists as an option but I don't accept it as the RPC default, as they both seem to be options, and have no idea the wallet2 behavior. I await secondary confirmation there.

<o​frnxmr:xmr.mx> Its not rpc default

<k​ayabanerve:matrix.org> dave.jp: Ask your wallet dev. transaction chaining allows you to sign aggregation TXs immediately and have them publish in the background without access to the private spend/view key. It should be very abstractable.

<d​ave.jp:matrix.org> Does monero-serai lib do it ?

<g​ooglemozilla:matrix.org> Wait, so swapping Serai assets for an amount like that would take at least this long?

<k​ayabanerve:matrix.org> But I'll repeat you already have to deal with this if you have enough inputs. I'm solely proposing changing the definition of enough.

<o​frnxmr:xmr.mx> I'll have to find where it was documented that split was to he the new default and "transfer" to be deprecated

<k​ayabanerve:matrix.org> googlemozilla: No?

<g​ooglemozilla:matrix.org> Sorry, swaps are currently on Substrate. I mean initially adding liquidity from Monero.

<o​frnxmr:xmr.mx> Thousands of inputs is a lot to deal with

<d​ave.jp:matrix.org> Lower you go, more ppl are hurt ; current limit doesn’t hurt 99%

<k​ayabanerve:matrix.org> ofrnxmr: At thousands, it doesn't really matter as you already have to incur intervals even with the current limit.

<g​ooglemozilla:matrix.org> If someone has to wait at least 40 minutes to send a Monero tx deposit into Serai, then HF arbitrage and LP bots will not be feasible.

<o​frnxmr:xmr.mx> If im a convenience store and need to pay my employees, thats a lot of on-chain wallet management

<k​ayabanerve:matrix.org> Serai is able to fulfill payments as soon as it has the necessary value. It attempts to form a master output with all value. Every time it has payments, it splits off the necessary amount to fulfill all payments it can. This means the master output is available after the next spend interval regardless of what payments are being executed in parallel.

<d​ave.jp:matrix.org> We are going to be laughing stock once ppl know number of inputs have been reduced to 8 from 140s

<g​ooglemozilla:matrix.org> For 256 XMR and above.

<o​frnxmr:xmr.mx> arent "more tx" more storage expensive than "more inputs"

<k​ayabanerve:matrix.org> When accumulating inputs, they're acknowledged the moment they hit Serai. Users adding XMR aren't affected by if we're internally aggregating.

<d​ave.jp:matrix.org> Sorry I get paid 0.1xmr so that’s 25.6xmr

<k​ayabanerve:matrix.org> Users removing (swapping to) XMR may be affected by temporary output unavailability which will always be true.

<d​ave.jp:matrix.org> Temporary like binance withdrawals

<k​ayabanerve:matrix.org> googlemozilla: Arbitrage is expected to happen on Substrate. It isn't affected by add/remove latency.

<k​ayabanerve:matrix.org> ofrnxmr: You already have to do such wallet management if you have 16 employees?

<k​ayabanerve:matrix.org> Dave.JP: Like we have a 10-block lock on Monero which is unavoidable?

<o​frnxmr:xmr.mx> What i mean by this: isnt is less blockchain storage expensive for me to send 5 totalling 740 inputs tx, than 90tx for the same number of inputs?

<d​ave.jp:matrix.org> It can be reduced, we are not increasing it to 40min though

<o​frnxmr:xmr.mx> 5 tx* totalling 740 inputs

<g​ooglemozilla:matrix.org> Yes, but adding the initial XMR liquidity will take a long time, which is what I gathered from this.

<g​ooglemozilla:matrix.org> Frontends will have to notify users with a time estimate for certain XMR amounts that are 'bridged'.

<g​ooglemozilla:matrix.org> That is, added to / removed from Substrate.

<d​ave.jp:matrix.org> 2/4/8/16/32/64/128 inputs should be allowed, increase txs fees if you care about computation/size ; let the user choose what they want to do split or pay a higher fee

<o​frnxmr:xmr.mx> if its heavier on chain to do more tx, than i dont think its a good idea to limit

<d​ave.jp:matrix.org> Again crippling already slow money flow

<k​ayabanerve:matrix.org> This discussion is still without full context, which is why I left earlier, and really full of whataboutisms. I understand the argument for UX. There's a lot of other arguments for privacy, performance, and stability. More users may be forced to face the already-present design limitations they prior didn't notice but those already need to be handled by any service at scale. transf<clipped message>

<k​ayabanerve:matrix.org> er_split exists, and is disgusting IMO, yet is even more beneficial in this context?

<g​ooglemozilla:matrix.org> This harms privacy.

<o​frnxmr:xmr.mx> Right now, more tx is less economical (more storage) than more inputs

<k​ayabanerve:matrix.org> googlemozilla: adding initial liquidity happens literally once and is solely subject to the confirmations we wait for. Aggregation policy has no effect at all.

<d​ave.jp:matrix.org> It doesn’t harm as much as you are crippling it

<k​ayabanerve:matrix.org> Uniformity stops identification of services?

<k​ayabanerve:matrix.org> It stops identification of people with large amounts of inputs?

<k​ayabanerve:matrix.org> It also stops identification of new users with only one input?

<g​ooglemozilla:matrix.org> Maybe I'm misunderstanding something, so I'll provide an example. If someone swaps 1 BTC for over 256 XMR, will they have to wait at least 40 minutes to withdraw onto the Monero network? Or if someone wants to add 256 XMR in liquidity, do they also have to wait?

<d​ave.jp:matrix.org> Those services have to decide how they want to do it ?

<g​ooglemozilla:matrix.org> Sorry for the silly questions.

<k​ayabanerve:matrix.org> Also, 128 inputs in one proof is such an stability issue I'd only advocate it if internally, we still used multiple proofs, and then that negates most of the bandwidth savings.

<o​frnxmr:xmr.mx> Does 128 fit in a tx?

<d​ave.jp:matrix.org> New user ? Pool create fresh wallets for single txs as churn is not safe lol and they don’t know how accounts work

<k​ayabanerve:matrix.org> It'd take a literal second to verify a singular proof for that many inputs ofrnxmr

<k​ayabanerve:matrix.org> dave.JP: Uniformity benefits new users.

<d​ave.jp:matrix.org> At what cost though ? When everything else moves at snails pace ?

<d​ave.jp:matrix.org> Even 20min is ridiculous for most users

<k​ayabanerve:matrix.org> This discussion remains uneducated, as I've said multiple times, and IMO, unproductive from the fundamental lack of context. I'm leaving for now as I am actually enjoying my Saturday night. Bye y'all. I'll share my summary when I write it. Please voice your opinions at the next MRL meeting if you care. Please also read the issues and prior meetings before doing so.

<d​ave.jp:matrix.org> I have to make a payment, on wait I need to wait 40min for it to consolidate

<d​ave.jp:matrix.org> Uneducated, yet simple to what is being proposed

<d​ave.jp:matrix.org> Consolidate your txs, take your time

<g​ooglemozilla:matrix.org> If this is indeed the case, it's not as bad of an issue as one might think. Ethereum L2s make users wait at least 10 minutes to bridge into Optimism, and they must wait 7 days to withdraw in order to verify fault proofs.

<d​ave.jp:matrix.org> We don’t care about pace of your money

<o​frnxmr:xmr.mx> For the slowpokes (like me) we'll also have a testnet

<o​frnxmr:xmr.mx> Soon

<d​ave.jp:matrix.org> Testnet by 2025 eoy

<o​frnxmr:xmr.mx> No

<d​ave.jp:matrix.org> 2026 eoy audit

<d​ave.jp:matrix.org> 20207 eoy block wars

<d​ave.jp:matrix.org> 2027 eoy block wars

<d​ave.jp:matrix.org> /s

<o​frnxmr:xmr.mx> like 30-90days, probably

<o​frnxmr:xmr.mx> For testnet

<d​ave.jp:matrix.org> That would be great

<g​ooglemozilla:matrix.org> It's not that bad, but I'm frustrated by the lack of accessible information. MRL logs are scattered throughout GitHub and can be difficult to navigate. I wish there was an easier way to review this, and perhaps I've overlooked something.

<o​frnxmr:xmr.mx> Blockwars in 6 months

<d​ave.jp:matrix.org> Alleasy we will have a extra coin to sell lol

<g​ooglemozilla:matrix.org> If this is indeed the case, it's not as bad of an issue as one might think. Optimism Rollups make users wait at least 10 minutes to bridge into Optimism, and they must wait 7 days to withdraw in order to verify fault proofs.

<d​ave.jp:matrix.org> Atleast we will have a extra coin to sell lol

<d​ave.jp:matrix.org> Maybe get listed on coinbase with the crippled version no longer a threat, you are welcome onboard 😂

<d​ave.jp:matrix.org> Atleast we will have a extra coin to sell lol

<g​ooglemozilla:matrix.org> If the wait time were 40 minutes, that wouldn't be so bad. As I mentioned earlier, Optimism Rollups is generally functioning well, and its 7-day withdrawal limits aren't causing significant issues. Most of these concerns can be addressed by abstracting the waiting process on wallet apps to display only waiting for confirmations.

<b​ast6:matrix.org> It's not an extra seed word, but a passphrase on Trezor, which leads to a hidden wallet. So if someone attacked you, you could always give him access to 2-3 decoy accounts and not to the real one. The problem with Monero GUI is that each and every wallet is shown in main menu. So if someone tries to rob me at gunpoint, I can't do anything except lose everything. Is it possible to <clipped message>

<b​ast6:matrix.org> have hidden wallets in Monero GUI and if not, how to protect oneself against the $5 wrench attack?

<b​ast6:matrix.org> I don't understand.. What do you mean?

<o​frnxmr:xmr.mx> Use feather

<h​opeful24:matrix.org> So who here uses the GUI wallet?

<g​ooglemozilla:matrix.org> I just reviewed the past 5 MRL meeting logs and found that there isn't a significant amount of information on how limiting max input size will affect transaction times. This lack of clarity is no wonder, given the confusion surrounding this issue. The only relevant resource I could find was: gist.github.com/Rucknium/784b243d75184333144a92b3258788f6

<g​ooglemozilla:matrix.org> @dave.jp:matrix.org

<h​opeful24:matrix.org> When I start the deamon won't connect

g​ooglemozilla from the way you are asking the question about a 256 xmr transfer it sounds like you think 1xmr = 1 input

<g​ooglemozilla:matrix.org> To be honest, I don't quite understand how inputs/output work for XMR.

<g​ooglemozilla:matrix.org> I'm going to wait until kayaba posts his summary by Tuesday, and hopefully by then I'll have a better understanding of what's going on.

<g​ooglemozilla:matrix.org> I'll also regularly attend the MRL meetings, as I'm still relatively new to Monero.

an input can be 0.00004 xmr or 18,000,000 xmr or anywhere in between

g​ooglemozilla just like btc

actually and input could be .000000000001 xmr

unspendable by itself because of a fee being needed

<g​ooglemozilla:matrix.org> So, if I understand correctly, if the max input limit is set to 8, for example, would it mean that if someone receives at least 8 separate outputs, they would be required to consolidate them if they want to send?

being that they are strongly looking at making a txs uniform means that all txs will have the same number of inputs or just 2 or maybe a few possibilities

I believe 4 inputs would be the minimum considered

<g​ooglemozilla:matrix.org> Yes.

so if you had 1 input the other 3 would need to be dummy inputs

not sure what the wallet logic would be if you had 8 inputs and 1 would be sufficient to do the needed transfer

still catching up with the MRL posts

Wednesdays meeting should be interesting but it's not really for the peanut gallery to comment at that time

<g​ooglemozilla:matrix.org> Upon reviewing Rucknium's gist, 19 outputs can be consolidated into a single input, and the remaining ones appear to be dummy inputs for MAX_INPUT = 4. What I was previously concerned about was the time required to perform this consolidation.

for each additional tx needed it is an additional10 block lock = ~20minutes

<g​ooglemozilla:matrix.org> All that is included in the gist are arbitrary costs for compute and transaction size.

it seems to me that consolidations are usually not time sensitive txs

<g​ooglemozilla:matrix.org> Can the 10-block lock be removed?

<g​ooglemozilla:matrix.org> @rucknium:monero.social What is total.size.cost in units? gist.github.com/Rucknium/784b243d75184333144a92b3258788f6

no, the possibilty has recently been revisited but it doesn't seem like it can be

should be bytes

my assumption is because block explorers currently show size in kB

also the numbers used

<g​ooglemozilla:matrix.org> I get it now. 256 outputs takes approximately 40 minutes to consolidate, not 256 XMR.

:)

<n​ot_a_money_printer:matrix.org> I did not understand the math under monero

<n​ot_a_money_printer:matrix.org> But why we need a 10 block lock?

<n​ot_a_money_printer:matrix.org> And why FCMP cannot remove it?

<b​lurt4949:matrix.org> See the "Motivation for 10-block-locks" section: monero-project/research-lab #95

<d​ave.jp:matrix.org> Increasing minimum is not a issue; decreasing maximum to just 8 is outrageous; needs to be atleast 64/128

<d​ave.jp:matrix.org> Consolidating inputs is also going to create multiple txs and consume more space on chain.

<d​ave.jp:matrix.org> Better work on optimising the compute code than limit it.

<k​ayabanerve:matrix.org> I spent 3h on a comprehensive statement. I'll publish in the morning after a night's sleep and review.

<k​ewbit:matrix.org> Yeah I tried that too

<r​ucknium:monero.social> googlemozilla:

<r​ucknium:monero.social> Let _b_ be the maximum number of inputs allowed by consensus rules. To consolidate _n_ inputs will require `ceiling(log_b(n))` rounds.

<r​ucknium:monero.social> _n_ outputs, I mean. One transaction's outputs is another's inputs. Seraphis started naming both of them "enotes", but it hasn't caught on yet.

<r​ucknium:monero.social> A round requires 10 blockchain confirmations of the consolidation transactions for the new outputs to be spendable. On average, one confirmation on the Monero blockchain requires 2 minutes.

<r​ucknium:monero.social> If we define a completed consolidation sequence as a state where the outputs have been consolidated, but the consolidated output is not yet spendable due to the ten block lock, then the amount of time it takes to consolidate outputs is `20 * (ceiling(log_b(n)) - 1)` minutes.

<b​ast6:matrix.org> Anyone know if it is possible to create hidden wallets in Monero GUI, as a protection against the $5 wrench attack? Right now each and every wallet is shown in main menu and can easily be found on the computer. With Trezor Suite, you have to enter a passphrase so every wallet is hidden... an attacker can't know how many wallets you have. Thanks.

<r​ucknium:monero.social> If `MAX_INPUTS` is 8 and the user wants to consolidate 100 outputs into one output, it will take `20 * ceiling(log_8(100) - 1) = 40` minutes.

<r​ucknium:monero.social> googlemozilla: Not interpretable yet: "The units are not yet interpretable, but the relative values can be compared between different `MAX_INPUTS` rules"

<d​ave.jp:matrix.org> No

<r​ucknium:monero.social> bast6: Go to #monero-gui:monero.social

<r​ucknium:monero.social> The gist ( gist.github.com/Rucknium/784b243d75184333144a92b3258788f6 ) is a rough draft. I was waiting for feedback on it before putting more time into it.

The "cost" numbers in these gist are not very useful, it's hard to understand how many milliseconds it will actually take on a mobile phone, for example. Need some real world numbers attached to it (I know that the current code is not optimized yet).

<o​frnxmr:xmr.mx> matrix.to/#/!YXAWqTPrnyDMWUqKVD:mat…mx&via=matrix.org&via=monero.social

<o​frnxmr:xmr.mx> Monero gui stores your wallet locations in a settings/config file.

<r​ucknium:monero.social> sech1: Yes, that too. The raw material I have to work with isn't in CPU milliseconds, anyway. AFAIK, we don't have real benchmarks yet.

<b​ast6:matrix.org> Yes, but from the main menu in Monero GUI they are all shown...

<o​frnxmr:xmr.mx> have you tried portable mode?

<b​ast6:matrix.org> What's the difference?

<b​ast6:matrix.org> And wouldn't wallets be shown as well?

<o​frnxmr:xmr.mx> One doesnt use global config file

<b​ast6:matrix.org> It would be nice if there was something like in Trezor Suite, where nobody can find any wallet unless the correct passphrase is entered

<b​ast6:matrix.org> I'm not tech savvy.

<b​ast6:matrix.org> What does it mean?

<o​frnxmr:xmr.mx> Open gui > when prompted for password click "cancel" > ckick "change wallet mode" > click "portable mode" > back to menu > open a wallet from file = no list

Rucknium it's weird that you don't even have real performance numbers yet, but already propose to limit max inputs to 8

Maybe everything is not that bad, after all

<o​frnxmr:xmr.mx> For bsx i think an 8 limit would break it

Optimizations, GPU parallelization in wallets will help

<b​ast6:matrix.org> Does the portable mode mean that I would use a remote node? Isn't it... less safe than using my own node? And I guess you would simply have to hide the wallet somewhere in an encrypted folder... would it work or would the fact that the folder is encrypted would prevent Monero from running it?

<o​frnxmr:xmr.mx> If i buy 0.5xmr 100x, i cant auto sell 10xmr without a series of consolidations

<b​ast6:matrix.org> I don't understand...

<o​frnxmr:xmr.mx> you can run the node manually

<o​frnxmr:xmr.mx> It also still have local node option

<r​ucknium:monero.social> sech1: I don't really like the proposed limits, but I'm trying to see the pros/cons. I also think there should be a coinbase consolidation tx type.

<o​frnxmr:xmr.mx> so no. It will still run a local node, but it means that it doesnt store your wallet info on the host pc

<b​ast6:matrix.org> What is the portable mode then? Does it run on my local node or on remote nodes? I read that remote nodes are risky

<b​ast6:matrix.org> OK... I need to try it

<o​frnxmr:xmr.mx> Coinbase or non-coinbase, we should be able consolidate. 8 pretty much forces any merchant to create a lot of transctions (a new output for every 8 inputs) to consolidate their tx

<b​ast6:matrix.org> If it doesn't store the wallet info on the PC... where do I get that wallet info?

<o​frnxmr:xmr.mx> bast6 are you running libux, windows, mac?

<b​ast6:matrix.org> linux

<o​frnxmr:xmr.mx> `~/.config/monero-project/`

<b​ast6:matrix.org> OK I checked.. it says to use portable mode if Monero is running on a USB stick or something external... My Monero is on my main drive, so I can run my own node... Do I choose simple mode then?

<o​frnxmr:xmr.mx> (rucknium asked us to move to #monero-gui or Monero Support becauae this is cluttering the general chat room)

<o​frnxmr:xmr.mx> No, use portable mode and ignore the recommendationb

<b​ast6:matrix.org> OK I went to advanced... but now I need to find back my wallet

<b​ast6:matrix.org> I clicked "portable mode" and "Advanced mode" and then "open a wallet from file"... now I need to find my wallet back

<b​ast6:matrix.org> I don't remember where they were stored... but even if I find them... wouldn't someone could simply force me to start Monero GUI in normal mode and find them in the menu? Or would the strategy be I put those wallet in encrypted folder? Would the fact that the folder are encrypted prevent Monero GUI from running them?

<b​ast6:matrix.org> How to prevent someone with access to my computer from finding the wallets, then?

<o​frnxmr:xmr.mx> Delete the config file

<o​frnxmr:xmr.mx> Before deleting..

<o​frnxmr:xmr.mx> Open the config file and youll see the locations of all of your wallets

<b​ast6:matrix.org> OK it's deleted

<b​ast6:matrix.org> but let's say I create new wallets... how do I protect them from someone with access to my computer?

hi, i'm trying to setup my own node and whenever i run monerod it seems to ignore my arguements...i am trying to specify an ip address for RPC to bind to and it just ignores that shit, and i pass --pruned-blockchain and it also appears to be ignoring that as it synches 300,000 blocks

i've tried using the github executables now i'm just using my distro's package with system

s/system/systemd

<o​frnxmr:xmr.mx> #monero-support pls

<b​ast6:matrix.org> I mean : someone could simply search for key files everywhere on the computer

ok...it's super dead in there

<o​frnxmr:xmr.mx> Use a passphrase or offset

<o​frnxmr:xmr.mx> Well, maybe if ppl stopped asking here, is reply there??? 🙈

<b​ast6:matrix.org> I can't find the monero-support... I'm new to Matrix... tried to post my question on Reddit, but they said my account was banned... didn't know where to ask

<o​frnxmr:xmr.mx> I'd*

<o​frnxmr:xmr.mx> Monero Support

<b​ast6:matrix.org> OK thanks for the link... I need to go to work but I'll ask later on monero-support... Thanks for your help... If I might ask a last question : how can I use a passphrase or offset to prevent someone with access to my computer from finding the key files to the wallets?

<b​ast6:matrix.org> Or if you could maybe send me to some link that explain how it can be done, I could read a bit before asking the questions... Just need to find a way to protect those wallets and make sure nobody can find them, or know how many I have, even with a gun to my head.

<s​nowman:tetaneutral.net> Every hard fork should make it easier to transact and mine monero

<s​nowman:tetaneutral.net> Or is privacy more important than usability

<s​yntheticbird:monero.social> If you have ideas that go in that sense don't hesitate to share them

<o​frnxmr:xmr.mx> Dont limit max inputs to 8, is an idea

<s​yntheticbird:monero.social> I briefly heard of the debate in MRL, isn't this constraint computationally based ?

<o​frnxmr:xmr.mx> Why dont we do that now? Simple. Its an extreme limit that hurts usability when paired with 10 block lock

<s​yntheticbird:monero.social> or is it just for uniformity

<s​nowman:tetaneutral.net> Does limiting inputs make monero worse p2p cash

<o​frnxmr:xmr.mx> I'm too stupid to answer that question

<o​frnxmr:xmr.mx> It makes it a PITA for merchants and services to pay people. Especially if the merchant receives small outputs that take multiple tx to consolidate

<s​yntheticbird:monero.social> depending on the amount, if on your wallet your don't have 10 outputs that sum up to the amount you wanna spend you need to consolidate first. So imaging you want to spend 50$ but only received 25 times 2$ you'll not be able to send it unless you consolidate it by sending it to yourself.

<o​frnxmr:xmr.mx> Or $1000*2$ selling hot dogs

<o​frnxmr:xmr.mx> And need to pay someone their $1000 paycheck

<s​yntheticbird:monero.social> if it is a privacy decision then its debatable, if it is computational then ig there is nothing that can be done about it thinking of an additional solution to make consolidation faster and easier

<o​frnxmr:xmr.mx> i don't "think" its computational, but again: ofrn = stupid guy

<s​yntheticbird:monero.social> you're fine. will do my research

<o​frnxmr:xmr.mx> need an ELIOFRN

<o​frnxmr:xmr.mx> This is why i'm thinking i might just wait for testnet and try the product before complaining further

<o​frnxmr:xmr.mx> It wont hit mainnet if its infeasible or unrealistic

ofrnxmr: If the wallet would split it into multiple transfers would it not kind of mitigate the issue?

<o​frnxmr:xmr.mx> transfer_split (and sweeps) does this already, and is something kayabanerve didnt seem to like the sound of

<o​frnxmr:xmr.mx> it doesn't work for something like basicswap, and is terrible for something like payroll, and i imagine incredibly spammy (and heavy) on chain

I see, ty for the input

<o​frnxmr:xmr.mx> Its correct that is is already a problem (we have a max input count already) but its 146.. a far cry from 8

I think someone else suggested to simply have a set of defaults and use dummy inputs/outputs if needed

e.g. all tx need to be 2/4/8/16/32/64 in/out

<o​frnxmr:xmr.mx> I suggestes 2/4/16/64/128 or smthn like that

I understand the idea of restricting it to 4/4 or 8/8, but that is going to impair user experience

Also I think FCMP++ should be less prone to any privacy leaks than the current implementation

<o​frnxmr:xmr.mx> 1:1 restrictions are strange to me. You aside from 1/2 ans 2/2 tx, you almost never input the same amount as output

Yes, I think 1/2 and 2/2 are the most common transaction types

Also comparing it to cash, if you give, say, a $50 bill to pay something worth $40, you get $10 back

Which would be 1/2 in the crypto landscape

<o​frnxmr:xmr.mx> Like 128/128. Under what circumstance, aside from sweep_single mass churn, would you be outputting the same number as you input

<o​frnxmr:xmr.mx> Seems wasteful

<o​frnxmr:xmr.mx> right. How often do you pay walmart in 8 outputs? Never

<o​frnxmr:xmr.mx> Your barber? Nwver

<o​frnxmr:xmr.mx> greater than 2 out tx are almost always a "special" type tx

Yes, though they make sense for services and exchanges

<o​frnxmr:xmr.mx> thats what i mean by special

<o​frnxmr:xmr.mx> 16 out is currently 30% of tx volume

<o​frnxmr:xmr.mx> Limiting to 8 would increase that to 60% of on chain volume is exchange noise

I am not sure it would be beneficial to change the current limits

Perhaps for inputs

<o​frnxmr:xmr.mx> a 16/16 tx is also insanity imo. Find me even one tx on chain in the lastbyr that is a 16/16 or 8/8

<o​frnxmr:xmr.mx> Standardizing outputs should me 2 and 16 imo. Inputs is a different beast, because it cripples spending and spams tx

<o​frnxmr:xmr.mx> too high for inputs currently allows users to take up whole blocks just to consolidate

If we allow 'levels', people could do 2/16, 4/16, 8/16 etc.

But also seems a bit wasteful to pad inputs to get to 8

for instance padding from 5 to 8 because we only allow 4 and 8

ofrnxmr: Yeah the current input limit seems a tad high

<o​frnxmr:xmr.mx> The current input isnt necessarily high, the size of those tx is

<o​frnxmr:xmr.mx> If fcmp brings down the size of consolidating, then the inputs should increase imo not decrease

Sure, fair point

<o​frnxmr:xmr.mx> Right now a new ring is created for each input. This is where the bloat comes from

<o​frnxmr:xmr.mx> Current limit isnt an input count limit, but a max tx size (2/3 of 50% of the median = 100kb, or something like that ) limit

<o​frnxmr:xmr.mx> So imo, whatever would allow the max tx size should be the input max. Spamming the chain with 100 tx to output 800 inputs is crazy work

<o​frnxmr:xmr.mx> And i dont mean pow, i mean sounds ridiculous to me

<o​frnxmr:xmr.mx> what i mean is: "Output 800 inputs" >> to spend* 800 inputs takes 100tx is pure spam

<o​frnxmr:xmr.mx> "look, monero did 300tx today" hut really we just started splitting one 146/2 tx into nineteen 8in tx with 114 new total outputs

<o​frnxmr:xmr.mx> that math is wrong. 150 new total outputs

<o​frnxmr:xmr.mx> Old method = 2 out. New method = 152 out

<o​frnxmr:xmr.mx> (8out * 19tx)

<o​frnxmr:xmr.mx> s/300tx/300k tx/

<o​frnxmr:xmr.mx> And of those 152 outputs, only 38 of them are real? (destination + change?)

<d​ave.jp:matrix.org> Gigantic ponzi

<o​frnxmr:xmr.mx> Idk. I'm not knowledgeable or educated enough to understand what i might be missing

<o​frnxmr:xmr.mx> But this sounds like a broken concept

ofrn did you read the recent discussion in MRL?

<o​frnxmr:xmr.mx> I sparked the controversy when i responded to articmine bringing up 4/4 and 8/8

<o​frnxmr:xmr.mx> Not before that though. A lot of it went way over my head

I haven't finished reading there

<x​mrhero:matrix.org> Does anyone know what the current progress is on implementing FCMP?

<o​frnxmr:xmr.mx> dev portion should be "done" soon

<o​frnxmr:xmr.mx> Soon like, less than 2 months afaik

<1​7e:matrix.org> Hello. Why is the amount of Monero not limited like Bitcoin?

<x​mrhero:matrix.org> Thanks. I hadn't kept up with monero for a while but when I found out about this new feature I got really excited.

So you can have some too.

Also to ensure that miners in the future are still inventivized to mine to secure the chain without having to rely on fees being high.

<b​asses:matrix.org> localmonero.co/knowledge/monero-tail-emission

<1​7e:matrix.org> But being unlimited making it less worth.

<o​frnxmr:xmr.mx> 18.4m xmr 19.5m btc

<o​frnxmr:xmr.mx> Like moo said, do you think 18m xmr is enough to go around?

<o​frnxmr:xmr.mx> its so you can have some too

<1​7e:matrix.org> > 18.4m xmr 19.5m btc

<1​7e:matrix.org> But BTC will always stay at 21m which makes it's worth go to unlimited. But XMR will be created more and more as far as I know and thats similar to Fiat.

<o​frnxmr:xmr.mx> if everyone owns just 0.00003xmr (tx fee), then xmr cant be spent

<1​7e:matrix.org> I can also have some BTC. Everyone can.

<o​frnxmr:xmr.mx> not true

<o​frnxmr:xmr.mx> If fees go above a certain amount, your btc is worthless

<1​7e:matrix.org> I'm not an expert. Just curious.

<1​7e:matrix.org> So what makes fees expensive?

<o​frnxmr:xmr.mx> Network security.

<o​frnxmr:xmr.mx> Miners spends money to mine btc. If btc block reward doesnt pay the electricity bill, the tx fee has to pay

<o​frnxmr:xmr.mx> Btc has a fixed block size, and therefore a fixed amount of tx/day. (around 600k tx per day)

<o​frnxmr:xmr.mx> Currently earning 310k usd / block from btc's emission

<o​frnxmr:xmr.mx> When btc has no emission, that 310k usd will have to come from tx fees

<o​frnxmr:xmr.mx> Btw, monero's current inflation is 3xmr every 10min. Btc is 3.125 btc every 10min

<1​7e:matrix.org> oh

<f​eli10101:matrix.org> base58 and ed25519 libraries are particular for monero right? In other words, generic libraries do not work for monero. Am I correct? I have spent a few hours trying to understand subaddress derivation using generic python libraries and I have not been successful

<k​ayabanerve:matrix.org> The Ed25519 libraries aren't Monero-specific

<o​frnxmr:xmr.mx> Doesnt monero have a custom version of one of them

<k​ayabanerve:matrix.org> It's still Ed25519

<f​eli10101:matrix.org> And base58?

<i​ty:itycodes.org> There's not a singular variation of Ed25519

<r​ecanman:kernal.eu> IIRC for encoding Monero uses Keccak-256 instead of SHA256

There is nothing special in Monero's Base58, as far as I remember.

<r​ecanman:kernal.eu> Monero base58 is different

<r​ecanman:kernal.eu> One sec

<r​ecanman:kernal.eu> github.com/monero-integrations/mone…25886d602490725036a4/src/Base58.php

<r​ecanman:kernal.eu> Encodes in blocks of 8 bytes instead of all at once

<r​ecanman:kernal.eu> The last block is padded

Ah, yes, the alphabet is the same, but the treatment in blocks isn't

<r​ecanman:kernal.eu> Alphabet is different as well

<r​ecanman:kernal.eu> I think

Hmm, this German Wikipedia article gives me the same that we have in our source: de.wikipedia.org/wiki/Base58. Maybe I overlook something?

<r​ecanman:kernal.eu> Nope, you're right.

<r​ecanman:kernal.eu> AFAIK the custom encoding is for a fixed output size

The proposed use of base32 for Seraphis / Jamtis had some clever alphabet variant. May never come to be now ...

<r​ecanman:kernal.eu> reddit.com/r/Monero/comments/zl4615

Already 2 years since that :)

jeffro256 even implemented that base32 stuff

<f​eli10101:matrix.org> Thanks

Maybe some things on my website will come handy to check and compare results, feli10101: monerotech.info

<s​yntheticbird:monero.social> For the love of god, these cards at the homepage are so confusing

<s​yntheticbird:monero.social> you think the button is the blue text but its the whole text

<s​yntheticbird:monero.social> so you boomers like me can't hover the text with their cursor

Hmmm, yes, probably a thing of the Bootstrap element that I used there ...

<s​yntheticbird:monero.social> oh if thats you that made the website I pardon you

<s​yntheticbird:monero.social> ok i should really read messages up to the link next time

<s​yntheticbird:monero.social> i pardon you

If boomers "hover the text with their cursor", what is supposed to happen?

<s​yntheticbird:monero.social> \* click \* hover the text so its highlighted, read it \* unclick \* rice and repeat

<b​asses:matrix.org> sir your website cuprate.org doesn't display correctly on my watch

<s​yntheticbird:monero.social> pic or never happened

<s​yntheticbird:monero.social> jk

<s​yntheticbird:monero.social> I only tested the responsiveness on mobile

<b​asses:matrix.org> never happened but doubt it will look good on such small screen size

<b​asses:matrix.org> it would have been weird if it looked ok tho

<j​effro256:monero.social> jeffro

<3​21bob321:monero.social> Get a bigger watch

<j​effro256:monero.social> Your concern about docs is certainly valid. I'll see if I can't update the docs soon. Were you getting problems when attempting to submit a transaction to a daemon by RPC or construct it using wallet RPC? Also, out of curiosity, why were you setting the `unlock_time` to 10?

<f​eli10101:matrix.org> I am trying to do something like that, to decode an address and to generate new addresses, but on my own, without monero libraries, just with generic ones

<f​eli10101:matrix.org> > <@m-relay:monero.social> <r​brunner> Maybe some things on my website will come handy to check and compare results, feli10101: monerotech.info

<f​eli10101:matrix.org> I am trying to do something like that, to decode an address and to generate new subaddresses, but on my own, without monero libraries, just with generic ones

I also do it "on my own" there, with C# code from the late Turtlecoin project plus code I wrote myself

<k​ayabanerve:matrix.org> Tranquil Ity: Ed25519 is a specific elliptic curve. There is a singular version of it. The 'basepoint' also has wide agreement and definition.