00:50:59 <apotheon> garth: I was basically saying they'd probably be separate cryptocurrencies in hyc's sense of it, so it'd be distinct supply; the supply on each side would be regional.
00:51:04 <apotheon> That's my guess, anyway.
01:59:52 <garth> Gotcha
07:31:43 <starship> This big pool a threat or not ? Or just fear News?
07:40:39 <moneromooo> If you're asking "is anyone being in control of close to 50% of the network hash rate a danger", then yes.
07:40:50 <moneromooo> Whether pools or not doesn't matter.
07:41:34 <moneromooo> Now, there are incentives, which apply or not to various parties. You may not want to kill the golden goose if you're a pool. An attacker that doesn't intend to make money may not care.
07:41:59 <moneromooo> How to fix this in a satisfactory manner is a very difficult problem.
07:42:21 <starship> If it does happen, any good alternatives?
07:42:36 <moneromooo> Ideally you want a number of miners with opposite goals, keeping each other in check.
07:42:57 <moneromooo> "If it does happen, any good alternatives?" is an unclear question. Rephrase.
07:43:15 <moneromooo> If you mean any other chain to switch to... I dunno really.
07:43:30 <starship> To xmr or xmr not gonna die if the pool hits 51% it will still be worth value?
07:43:59 <moneromooo> That's not even grammar. Rephrase again.
07:44:38 <moneromooo> If you're asking "would monero lose its value if a party had > 50% of the netowrk hash rate", then no.
07:44:57 <moneromooo> We've seen that happen before on other chains, and the market mostly does not really care.
07:44:58 <starship> Yes that is what I asked. 
07:45:18 <starship> Cool
07:45:45 <moneromooo> Well, I guess. It just means the prices aren't defined by actual worth, but by... I dunno. Bullshit.
11:12:37 <garth> #truth
15:15:33 <NakedKing> o/. Why monero locks all of money?   Example:   I have 10 xmr on my wallet, and i pay 0.1 xmr and 9.9 xmr will be locked.
15:15:38 <NakedKing> local.ERROR: Request have return error: not enough unlocked money.  
15:15:53 <NakedKing> How can i solve this situation? It brokes the flow.
15:20:14 <moneromooo> It does this because you had one coin only, which you sent.
15:20:27 <Mochi102> NakedKing, it's like having a $100 in your wallet and paying $1 to the coorner store... They need to make change.
15:20:30 <moneromooo> The new coin (the change you get back) will be usable 10 blocks later.
15:21:39 <Mochi102> So you can send change back to yourself by sending yourself a bunch of smaller amounts (in the CLI): transfer <your wallet address> 0.1 <your wallet address> 0.1 <your wallet address> 0.1 <your wallet address> 0.1 
15:23:07 <Mochi102> If you do this then the amounts (outputs) that aren't used to make a transaction will not be locked.
15:23:21 <NakedKing> Mochi102, can i do this? I have address_index and subaddress.  Lets say address_index 1 and sub 0.   in this example: i need to pay somewhere 3xmr but i have 10xmr. First i pass 3xmr to my subaddress then send it from there
15:23:41 <NakedKing> will it work?
15:24:16 <NakedKing> i need to prevent locking moneys
15:24:31 <Mochi102> Are you using the CLI?
15:24:54 <NakedKing> yes
15:25:12 <NakedKing> running full node and started rpc
15:25:51 <Mochi102> So if you have 10 XMR you can type: transfer <your wallet address> 1 <your wallet address> 1 <your wallet address> 1 <your wallet address> 1 <your wallet address> 1 <your wallet address> 1 <your wallet address> 3
15:26:09 <Mochi102> but it'll still be locked for 10 blocks
15:26:18 <Mochi102> Then next time not though.
15:27:07 <Mochi102> No matter what you do your XMR will be locked for 10 blocks on the first outgoing tx if you have only ever had one transfer to your wallet.
15:27:31 <NakedKing> bad news. i need to change all my logic now
15:28:13 <Mochi102> NakedKing, why? What is the problem?
15:28:13 <NakedKing> i wasnt store things belongs to xmr on database. but now i need queued process
15:28:55 <Mochi102> NakedKing, if you just prepare your wallet with a lot of small outputs you should never really have a problem.
15:29:36 <NakedKing> Mochi102, users doesnt want to wait. Maybe i can cache the xmr value then process it with queued jobs
15:30:17 <Mochi102> What're you trying to do?
15:38:56 <merope> Maybe when you receive more than, say, 5 XMR, you can automatically run a script to split that into 5x 1 XMR outputs as soon as possible
15:39:44 <merope> That way, when you need to make a payment later on, you will have more outputs available
15:43:20 <Mochi102> Sometimes people make a problem out of things that really aren't.
15:44:06 <Mochi102> I spent 10-20$ in tx fees back before bulletproofs to prepare my wallet for monero.win and I've never had a problem.
15:44:59 <Mochi102> Hmm... can't get monerod to run on Window Subsystem for Linux
15:45:21 <Mochi102> Well, it runs but there's some socket error... maybe related to IPV6
15:54:38 <selsta> merope: monero-wallet-cli supports setting `min-outputs-count` and `min-outputs-value`, which basically does what you are describing, see https://github.com/monero-project/monero/issues/6254#issuecomment-567457415
15:55:51 <selsta> though I haven't used it myself so I don't know how it works exactly
15:56:33 <moneromooo> It won't split, it'll just avoid merging.
15:58:00 <Mochi102> just added google's nameserver in my /etc/resolv.conf and took out all other entries
15:58:02 <Mochi102> works
15:58:41 <Mochi102> oh is that new selsta ?
15:58:51 <selsta> no, existed for a while but isn't well known
15:59:24 <Mochi102> I need to look into that... looks interesting
16:05:16 <Mochi102> moneromooo, looks like selsta is referring to a set command in the wallet... is this just for choosing outputs to spend or does it actively make change?
16:06:08 <moneromooo> It will not add a second output if it is not needed and adding it would make the number of outputs above min-outputs-value be below min-outputs-count.
16:06:49 <moneromooo> Arguably, it should never add a second output if it is not needed. The intent of the second unneeded output was to try and make all (well, most) txes have 2 inputs.
16:07:04 <moneromooo> I'm not clear which is best.
16:08:18 <Mochi102> I se
16:08:20 <Mochi102> e
16:24:16 <DeanGuss> So what's up with Rucknium[m]'s work @ https://ccs.getmonero.org/proposals/Rucknium-OSPEAD-Fortifying-Monero-Against-Statistical-Attack.html
16:24:31 <DeanGuss> According to the milestones it was supposed to take 5 weeks for milestone 1 and it's now been 5 months with no milestones completed.  #Whatdadealio
16:24:40 <DeanGuss> This is probably the most important work in monero right now
16:57:50 <Rucknium[m]> DeanGuss: Thanks for following my work. The short answer is that the timing is reliant on the upcoming hard fork. jberman and I agreed that it would not go into the upcoming hard fork -- it is a wallet-level change, so it can be implemented in an updated release of the GUI wallet after the hard fork.
16:59:02 <DeanGuss> Rucknium[m]: So the hard fork is going to change the Decoy Selection Algorithm?  Is this the seraphis hard fork?
16:59:12 <Rucknium[m]> And as the proposal mentions, I will leverage the change in the ring size from 11 to 16 that will come in the hard fork to help with the statistical estimation
17:00:02 <Rucknium[m]> No, the upcoming hard fork does not change the decoy selection algorithm. The Seraphis hard fork, if and when it happens, is likely more than a year away.
17:00:07 <DeanGuss> I thought "Raising the ring size from 11 to, say, 16 would barely dent the potency of my attack."
17:00:26 <DeanGuss> So there's going to be another hard fork before seraphis?
17:01:15 <DeanGuss> Oh I gotcha, the hf just raises the ring size
17:01:47 <Rucknium[m]> There is not a need to do a hard fork to alter the decoy selection algorithm since the DSA is not enforced by any consensus rules. There are periodic updates to the official wallet that a overhaul of the  DSA will be released in.
17:02:53 <Rucknium[m]> DeanGuss: I have a draft of part of OSPEAD if you would like to take a look and give feedback.
17:04:40 <DeanGuss> Rucknium[m] Sure, I wouldn't mind taking a look.  I doubt I can give you much decent feedback tho, as statistics is ~99% something I know nothing about ;)
17:04:56 <Rucknium[m]> And this repo with a "dry run"on old data:
17:04:56 <Rucknium[m]> https://github.com/Rucknium/OSPEAD
17:06:44 <DeanGuss> Cool thanks.  So what's the point of waiting for the 16-ring-member hard fork?  That changes the DSA?  What is the incentive to switch to 16-ring-member rings?  Will that actually help things?
17:22:44 <Rucknium[m]> DeanGuss: From my understand the main reason was software development workflow reasons. We didn't want OSPEAD to become a "blocker" in the process of developing and releasing the hard fork. It is true that the hard fork's features has taken longer than expected to be developed and double-checked. 
17:22:47 <Rucknium[m]> See https://github.com/monero-project/meta/issues/630
17:23:55 <Rucknium[m]> 16-member rings will help things. Besides individual-level improvement in decoys, there is also the issue of a "flood" attack being much harder with a significantly larger ring size.
17:25:38 <Rucknium[m]> And there was an apparent flood incident on the blockchain last year. 
17:25:46 <Rucknium[m]> See https://www.reddit.com/r/Monero/comments/pvm634/fingerprinting_a_flood_forensic_statistical/
19:52:05 <gingeropolous> "so it can be implemented in an updated release of the GUI wallet after the hard fork." ... will OSPEAD-wallet-crafted txs be distinguishable from non-OPEAD-wallet-crafted?
20:12:24 <garth> Only by statistical analysis, in my estimate
23:58:08 <Rucknium[m]> gingeropolous: The short answer is yes, probabilistically. But even today some wallets that do not follow the GUI wallet's decoy selection algorithm are distinguishable. 
23:59:50 <Rucknium[m]> A downside of larger rings is that this type of distinguishability becomes easier since the sample size, in essence, is larger. Some ideas have been thrown around about how to enforce the decoy selection algorithm at the node-rebroadcast level, and whether doing so is advisable.