00:04:31 <moneromooo> Same long term expected value at first approximation, the big difference is the variance, which is much higher for solo mining.
00:04:49 <moneromooo> The daemon cannot mine to a pool.
05:52:16 <angrymonkeyboi[m> <Kapli "How good of an idea is to mine u"> I wouldn't recommend it. For it it was significantly slower. I was getting about 2kh/s using the wallet. With XMRig, I was getting about 16Kh/s
05:56:18 <nioc> that difference is much more than wallet vs xmrig
05:56:24 <nioc> some bad settings
05:57:00 <nioc> 16k vs 14.8k would be my guess for the difference
07:46:13 <mawk> I sold XMR for cash to a stranger on irc
07:46:21 <mawk> am I going to jail
08:03:57 <modul8[m]> is this a bsd joke?
08:25:30 <fluffypony> modul8[m]: rofl
08:31:08 <modul8[m]> i have more. does a tari equal an atari?
08:59:18 <davp> Hi. I'm interested, is monero underdevelopment? I mean specifically, is there an interface to the monero network where it can be configured or reconfigured ?
09:06:13 <davp> Does anyone know where I might be able to find out what limitations, if any, on the development team and what they can do? My angle here is, would it be possible for the authorities to knock on the door of a monero leading developer and force them to give admin privileges to the authorities
09:11:31 <charolastra> good question. by it beeing hosted on github it very much seems like that
09:20:54 <davp> Monero is hosted on github?
09:22:45 <charolastra> that's what a quick search tells me. maby it's just a mirror but i don't think so
09:30:56 <selsta> there is no risk in hosting on github
09:31:19 <selsta> git is decentralized and for issues / prs we have regular backups
09:34:50 <selsta> "would it be possible" yes but that would also be possible if we use self hosted repo
09:35:14 <selsta> maintainers / core team don't post code changes themselves so it would quickly be noticed
10:08:43 <davp> @selsta thanks. Are you involved with monero?
10:12:10 <davp> My point being here that to target monero it seems like they could target the individuals involved.
10:15:22 <endor00[m]> That's true for any human activity ever
10:20:29 <davp> Well, it could have been designed with no option for configuration post initialisation. ( i know nothing about this or whether that is possible). I thought the idea of cryptos was they were free from being able to be manipulated by humans as fiat currencies can
10:20:29 <Quotes> CRYPTO IS NOT CRYPTOCURRENCY ಠ_ಠ ~ IT REFERS TO CRYPTOGRAPHY, davp
10:20:59 <davp> Ok.
10:21:19 <davp> Well I mean cryptocurrency obviously
10:27:37 <endor00[m]> (It's just a silly bot, ignore it)
10:28:50 <endor00[m]> You can't manipulate it in the sense that you need everyone to be on-board in order to change the system
10:29:42 <charolastra> if you can manipulate the central source it's easy to get everyone on board
10:29:42 <endor00[m]> Nothing can stop people from saying: "Ok, we all agree to stop running this old version of the code and start using this new version of the code"
10:29:53 <selsta> there is a risk that a dev sneaks in unintended changes but that exists with every project
10:31:06 <endor00[m]> <charolastra "if you can manipulate the centra"> That's the nice thing about git: any change is tagged and labeled, and you can walk through it step by step and see everything, and revery any unwanted changes
10:31:38 <endor00[m]> Or better yet, just move to an uncompromised copy of the repo and treat it as your new main repo
10:32:36 <endor00[m]> The ability to download a full copy of the code and personally verify it is one of the greatest powers of open source software
10:33:06 <endor00[m]> It requires effort, sure, but at least you can
10:36:57 <davp> endor00[m]: I get that but i thought that the system ran independently of humans.  There needs to be a point of no more development, a shut off allowing no more interacting with it on an admin basis. I thought bitcoin was like that. Basically the human element are massive vulnerabilities, the hole development team could get held hostage a forced to comply, the stakes are masive
10:37:57 <endor00[m]> What you're thinking of cannot exist, because you would have to take away people's freedom to decide what code to run on their devices
10:38:57 <endor00[m]> Also, it would imply that you are 100% sure that your code contains no vulnerabilities or bugs of any code, nor will it ever be broken in any sort of way now and forever
10:39:26 <endor00[m]> And that, at best, would be a prime example of hubris
10:40:22 <davp> Sure. So someone has access to bitcoin as admin?
10:40:26 <endor00[m]> And no, not even bitcoin is like that. Hell, they're still polishing and tweaking things (even though it's mostly fluff, and not core features or protocol changes)
10:40:44 <selsta> davp: no
10:40:44 <endor00[m]> Yeah, they have maintainers merging code too
10:41:12 <selsta> they can't overwrite the network
10:41:26 <selsta> but sure someone has repo access
10:41:59 <selsta> but they don't have admins that can press buttons to turn off / change the network if that's what you meant
10:42:23 <endor00[m]> Oh wait, you meant accessing live running instances and messing with thise? Hell to the nope
10:42:34 <endor00[m]> <selsta "but they don't have admins that "> This
10:43:10 <endor00[m]> You are the only one in charge of the code you're running on your machine, and nobody can touch that. That's true for bitcoin, and true for Monero
10:43:39 <endor00[m]> The network works because we all agree to run versions of the code that are compatibile with eachother
10:44:37 <endor00[m]> But the only thing that maintainers can touch is the source code in the official repositories
10:46:58 <davp> I suppose there are two elements, the network element governing how communications are made but then another element governing monetary policy, coin issuance for example. Can the coin issuance policy get changed and pushed out to the network as an update, or could the ease of mining be changed?
10:54:31 <endor00[m]> I'm not familiar with the block validation code, but I would assume (hope) that there is a check for the new coins added with each new block
10:55:02 <endor00[m]> So if a peer tries to create a block with a trillion Monero for themselves, it would just get rejected by everyone else
10:55:56 <endor00[m]> The only way to change the emission curve would require changing the source and everybody agreeing to run that change
10:57:57 <endor00[m]> In terms of "what could be changed by changing the source code", the answer is "everhthing"
10:58:37 <endor00[m]> The real question is: will people run that changed code? Or will they reject your changes and keep running the previous version?
10:59:22 <endor00[m]> Nobody can come in and say "this is the new Monero, everybody do as I say"
10:59:54 <endor00[m]> Or rather: they can, but most likely nobody will listen to them and they'll achieve nothing
11:05:04 <davp> I am thinking that monero is going to get targeted, it is an obstacle to those who want no cash privacy. I reckon knocking on doors will be the last thing to happen if all else fails.
11:09:20 <davp> Presumably another way to target monero would be to push the price of monero down thus making mining not cost effective especially if the price of electric goes up. Can the monero network, or any network run without mining power just using user nodes?
11:13:01 <fluffypony> miners have been mining Monero at a loss for large periods of Monero's history
11:13:20 <fluffypony> it self-corrects - when the price is too low then they simply can't afford to sell
11:13:22 <fluffypony> so they hodl
11:13:35 <fluffypony> and the price goes up, because there is natural and speculative demand
11:13:53 <fluffypony> ie. there's only so much market manipulation even a sophisticated and resourceful attacker could deploy
11:14:44 <sech1> A big chunk of monero miners have near zero operating expenses, they don't care about price.
11:14:53 <fluffypony> yup
11:15:13 <sech1> Not only botnets, but also small scale home/college miners with "free" electricity
11:17:22 <davp> I see. Limit supply until price goes up. Cheers everyone for all your info. Much appreciated.
11:49:30 <biscuitsboars[m]> What takes elon to tweet monero . doge really
11:51:11 <ComplyLast> I heard that's a fellow south african that's into Monero
11:51:20 <ComplyLast> maybe those two country man should talk a bit
11:52:12 * ComplyLast looking at fluffypony 
11:52:23 <fluffypony> lol
11:52:38 <fluffypony> unfortunately rocking a South African accent isn't enough for Elon to pay attention to me
11:52:44 <ComplyLast> shit
11:52:48 <ComplyLast> not even the ZED stuff?
11:52:57 <ComplyLast> so disrespectful.
11:53:05 <fluffypony> well even the Brits and Ozzies say zed
11:53:18 <ComplyLast> ohh TIL
11:53:29 <ComplyLast> thought it was a south african and aussie thing
12:38:58 <hyc> it's a brit thing
12:40:00 <ComplyLast> also irish?
12:42:12 <hyc> hm could be
12:56:58 <raecarruth> it is a british thing
12:57:08 <raecarruth> and all their bastard offspring imitate
13:15:12 <charolastra> endor00[m]: yes, distributed development is nice but my point was more about having a SPOF. for me it seems that one or a handfull of guys are responsible of merging the different push requests into the official repo. by having that hosted by a US company those individuals are known
13:15:36 <charolastra> btw, are there mechanisms in place to verify the binaries?
13:16:59 <hyc> charolastra: the binaries are all the result of reproducible builds
13:17:15 <hyc> anyone can verify their hashes and build locally to compare results
13:17:48 <charolastra> yes, can. but does?
13:18:05 <hyc> so far it's not necessary as long as the hashes match
13:18:20 <hyc> and everyone is told to check the hashes of their downloads
13:19:02 <endor00[m]> I always verify my hashes
13:19:15 <endor00[m]> And the auto-updater does it automatically iirc, right?
13:19:24 <hyc> yes
13:19:35 <hyc> and you can look at the sig archive here https://github.com/monero-project/gitian.sigs
13:19:42 <hyc> lots of us have verified the hashes of each build
13:23:03 <CrowX-> so, doge coin has over 3x the market cap of monero
13:23:12 <CrowX-> how does that make you feel?
13:23:36 <hyc> market cap is a made up number
13:23:59 <hyc> I can fork a new coin, mint 1 billion tokens, sell 1 for $1, and instantly have a $1B mcap
13:24:06 <hyc> it's irrelevant
13:24:59 <sech1> Liquidity is a more important metric
13:25:22 <sech1> Bitcoin has $625M liquidity now (+-2% price change), Monero $14.8M
13:26:00 <sech1> So based on this metric, Monero should be $1000, or Bitcoin should be $6300, depending on your point of view
13:27:46 <dEBRUYNE> sech1: Where do you get that liquidity stat from?
13:27:59 <sech1> https://www.livecoinwatch.com/
13:28:11 <sech1> https://www.livecoinwatch.com/price/Monero-XMR
13:28:46 <sech1> I'd love to see top coins arranged by their liquidity, I'm sure Monero would be higher in rankings
13:30:32 <CrowX-> is liquidity the amount that is being traded in a period?
13:32:41 <sech1> Liquidity is the amount you can buy/sell without moving the price much
13:32:49 <sech1> i.e. the depth of order books
13:35:34 <hyc> then again, most order book volume is fake
13:36:33 <sech1> volume is not liquidity
13:36:57 <sech1> if an order in the order book is live you can in theory fill it, so liquidity is more real metric
13:37:16 <sech1> volume can be faked by trading bots of course, but not liquidity
13:37:33 <sech1> unless some exchanges create fake orders to increase liquidity
13:39:26 <endor00[m]> oooh, that's an interesting definition I was not aware of
13:39:39 <endor00[m]> "moving the price much": how much is "much"?
13:40:02 <sech1> the numbers I posted before are +-2% "much"
13:41:41 <endor00[m]> ok, so how do you go from order depth to the prices you mentioned?
13:45:21 <sech1> if order depth was proportional to the price then these are the prices we'd have (considering BTC and XMR have roughly the same amount of coins)
13:54:13 <endor00[m]> not sure I got it
13:56:01 <sech1> Monero has more liquidity compared to its market cap than Bitcoin
13:56:20 <sech1> like 6 times more
14:06:43 <endor00[m]> oooh, so it's a relative measure between two coins, not an absolute
14:24:34 <sethsimmons> tokineko hyc
14:24:52 <sethsimmons> tokineko:  has a question on using raw partition for LMDB
14:25:11 <sethsimmons> He's currently using btrfs on an HDD
14:25:55 <tokineko[m]> Mount options `noatime,compress-force=zstd:2,discard,autodefrag`
14:26:14 <tokineko[m]>  * Mount options `noatime,compress-force=zstd:2,autodefrag`
14:26:51 <tokineko[m]> Perhaps, disabling copy on write can improve performance a lot.
14:28:56 <sethsimmons> I'm sure it would.
14:29:42 <hyc> btrfs is definitely a poor choice
14:29:51 <hyc> any journaling filesystem is a poor choice for LMDB
14:30:09 <hyc> and yes, it would perform better on a raw partition
14:32:24 <hyc> you need commits 5c0dda76c96a3badc9c61fe840c7098451c7ffa2 and a7df9e63a5097b7915a3b4a2788c1166e3c1b470 to get that support
14:32:46 <hyc> (not in any public release)
14:37:30 <cobolus[m]> hi ! i installed the latest windows monero gui wallet and after some days I got now a virus warning from windows defender
14:37:43 <cobolus[m]> I checked the sha265 sum of the install package and it seems ok
14:37:59 <cobolus[m]> are there also hash sums for the other files included in the installer so that I can verify ?
14:38:02 <manifest> normal
14:38:20 <manifest> has a mining capabilities so windows mad
14:38:20 <Quotes> fuck windows, use linux!
14:39:55 <cobolus[m]> ok thx
14:54:50 <Inge-> cobolus[m]: you should also make a habit of checking the hash list against binaryfate's pgp signature
18:18:04 <lululimon> how does one restore a 24-word monero seed?
18:18:56 <valyriantinfoil> this should help
18:18:58 <valyriantinfoil> https://www.getmonero.org/resources/user-guides/restore_account.html
18:22:09 <lululimon> thanks
18:22:41 <lululimon> Is it only possible to restor 24-word with the gui?
18:23:21 <valyriantinfoil> you should be able to restore 24-word seeds as well as 25 word seeds with both gui and cli
18:24:31 <moneromooo> monero-wallet-cli --restore-deterministic-wallet
18:24:45 <moneromooo> The last word is optional, it's a checksum.
18:24:53 <moneromooo> Assuming it's the last one which is missing.
18:59:05 <lululimon> I tried my 24-word seed in the gui with that command but it keeps saying electrum blah blah not good
18:59:11 <lululimon> let me get you the exact error
18:59:57 <dEBRUYNE> Which software did you use to generate this seed?
19:01:12 <lululimon> no clue, it was long ago
19:02:17 <lululimon> Error: Electrum-style word list failed verification
19:06:17 <moneromooo> It could be a typo in one of the words, or extra spaces around.
19:08:55 <lululimon> I suppose that's possible
19:23:47 <gingeropolous> lululimon, if it helps, only first three letters of the word matter
19:23:51 <gingeropolous> also, are you sure its a monero seed?
19:36:08 <lululimon> Definitely, I wrote MONERO next to it lol
19:53:28 <nioc> lol
20:07:56 <ComplyLast> lululimon, could that be a trezor/ledger seed?
20:08:16 <ComplyLast> I guess they use bip39 formatting
20:09:34 <lululimon> Its just a regular monero seed from back before monero was a contender for world reserve currency
20:09:57 <ComplyLast> Monero was always a contender, what are you talking about then?
20:10:01 <ComplyLast> pre 2014?
20:10:09 <ComplyLast> like some 2011 monero seed?
20:10:45 <lululimon> No, I guess it was probably after that. I'm sorry, I really don't know. Some portuguese guy talked me through it back then.
20:10:59 <ComplyLast> oh really?
20:11:14 <ComplyLast> maybe check #monero-pt
20:11:21 <ComplyLast> lots of portuguese scammers there
20:11:30 <ComplyLast> maybe you'll recognize the culprit
20:48:56 <lululimon> I'm not sure. Each of the words is a normal, lexical word and they do not seem to be misspelled. I have even tried using only the first three letters as suggested.
20:49:40 <lululimon> but still it says `Electrum-style word list failed verification`
20:51:39 <moneromooo> English seed ?
20:53:44 <lululimon> yes
20:54:20 <moneromooo> There was a bug in... 2014 I think... where some words starting with i needed changing. Can't recall details though.
20:54:31 <moneromooo> Any word starting with i ?
20:55:02 <lululimon> two
20:55:39 <lululimon> I think this might be a 2015 wallet, but I really can't remember
20:56:30 <moneromooo> Anyone remembers what the deal was with those seeds ?
20:56:33 * mycorrhizae[m] uploaded an image: Screenshot_20210208-071601_Brave.jpg (323KiB) < https://matrix.org/_matrix/media/r0/download/matrix.org/yRtGvQZckZuUhNLPxmEOmCzM/Screenshot_20210208-071601_Brave.jpg >
20:57:11 <IRELATIVISM> <moneromooo "Any word starting with i ?"> ^ irelativism starts with i
20:57:31 <moneromooo> Aye.
20:58:56 <moneromooo> lululimon: I suppose you can run with --log-level 2, it might give you better detail, though this is not super likely.
21:00:48 <lululimon> Another question: suppose you had some files for a Monero wallet `wallet` and `wallet.keys` that represent a wallet you have forgotten the password to. However, you have the seed words and restore your wallet and have `newWallet` and `newWallet.keys`. Is there a way to verify that these are the same wallet (e.g. using diff on the .keys file or some other method) without recalling the password of the previous instance?
21:06:49 <moneromooo> No.
22:26:46 <multifractal> I'm seeing "Error: Couldn't connect to daemon 127.0.0.1:18081" on monero gui on tails, in the logs. Am I doing something wrong here? It's ben a while since I used it but as far as I recall I've always used it in simple mode on tails.
22:27:56 <lululimon> multifractal: what does `netstat -peanut | grep 18081` show
22:28:18 <selsta> multifractal: I don’t think simple mode works on tails yet
22:28:45 <selsta> due to tails being special, use advanced mode
22:29:22 <selsta> see also xmrguide42y34onq.onion
22:55:32 <leonardus> Is there any work being done to reduce the time to verify transactions?
22:55:58 <Lyza> knacc I got a question about i2p-zero -- the GUI has a tab called "eepsite" that runs a little built in web server. Is that functionality available in the CLI? I don't see documentation for it in the readme
22:56:07 <leonardus> In my experience it's been 20+ minutes which isn't very feasible if monero were ever to be used for in-person transactions, unless I'm mistaken about something?
22:56:27 <sethsimmons> 20+min?
22:56:35 <sethsimmons> Its a few ms to verify transactions
22:56:42 <sethsimmons> Do you mean to get confirmations, or sync?
22:56:50 <leonardus> Oh confirmations yeah
22:56:58 <sgp_[m]1> maybe they are talking about lock time
22:57:07 <sethsimmons> Its 2min confs, and you can do 0 conf for most transactions.
22:57:31 <sethsimmons> If you mean the wallet lock time like SGP says then no, that is locked intentionally.
22:57:57 <sethsimmons> If you intend on spending frequently you can break up your outputs into normal denominations to make sure you always have plenty unlocked.
22:58:13 <sethsimmons> That's simple to do in Feather wallet and is hopefully a feature that will come to other wallets at some point.
22:59:02 <sethsimmons> Think of outputs like bills in your wallet -- if you just have one big bill you have to wait for change before you can spend again, and Monero locks change for 10confs for safety and privacy.
22:59:15 <leonardus> I'm not talking about lock time
22:59:21 <sethsimmons> It you break down your big bill into multiple smaller bills ahead of time you always have what you need handy.
22:59:27 <sethsimmons> <leonardus "I'm not talking about lock time"> Oh
22:59:51 <sethsimmons> Then just decide how many confirmations you need -- most normal transactions can be zero conf
23:00:03 <sethsimmons> If you need a high assurance you can do multiple confirmation
23:00:18 <sethsimmons> But each conf should be ~2min
23:00:29 <sethsimmons> Give or take a bit due to randomness with mining.
23:00:39 <sethsimmons> * Give or take a bit due to variance with mining.
23:01:13 <leonardus> Thinking of Monero being used for IRL transactions like at a store, 0 confirmations seems too risky for a merchant to ever use, and 2 minutes still seems too long for something like that
23:01:39 <sethsimmons> 0conf is not really risky if you have the transaction in your own mempool.
23:02:04 <sethsimmons> I wouldn't trust a different node, but if you have your own node 0conf is fine for most.
23:02:20 <sethsimmons> Finality is not better with shorter block times.
23:02:26 <sethsimmons> That's a common misconception.
23:02:28 <sgp_[m]1> Generally agree, especially for purchases <$1000
23:03:22 <sethsimmons> <leonardus "Thinking of Monero being used fo"> Think of how no store validates cash for small transactions, but will use a UV light on big bills to make sure.
23:03:39 <sethsimmons> Same concept here, but simpler because your node validates transactions the moment they're seen automatically.
23:03:59 <leonardus> Well, counterfeiting a (realistic) bill is a more complicated process than say double spending
23:04:03 <sethsimmons> If your node accepts it to the mempool it will be mined in almost every scenario and the payee can't change that.
23:04:17 <sethsimmons> <leonardus "Well, counterfeiting a (realisti"> No, double spending is incredibly difficult.
23:04:36 <sgp_[m]1> Yeah it requires powerful friends to pull off
23:04:42 <sethsimmons> In almost every scenario.
23:04:51 <sethsimmons> And changing block time does not change finality as mentioned.
23:05:11 <sethsimmons> Its honestly not a problem at all IMO
23:05:23 <moneromooo> Dandelion might indeed make double spending easier.
23:05:24 <sethsimmons> Its just a native aspect of block chains -- choose what finality you're OK with.
23:05:31 <sethsimmons> In most scenarios 0conf is fine
23:05:45 <sgp_[m]1> Most people who are super cautious wait 1-2 confirms. Exchanges may wait longer since they often accept large deposits
23:05:56 <sethsimmons> <moneromooo "Dandelion might indeed make doub"> Not if comparing against your own nodes mempool, right?
23:06:08 <sethsimmons> Trusting the attackers/a random node would expose more surface
23:06:13 <moneromooo> Depends what you mean by that.
23:06:49 * sgp_[m]1 sent a long message:  < https://matrix.org/_matrix/media/r0/download/matrix.org/VQPElYjFtGOlFIHHnXYxqubl/message.txt >
23:06:49 <sethsimmons> But if your node has seen it its extremely extremely likely its already fluffed.
23:07:03 <moneromooo> Alice buys widget from Bob. Alice spends output O in a tx she sends Bobs's node with dandelion. At the time time, she sends a double spend without dandelion, including to pool nodes.
23:07:25 <moneromooo> Actually, she sends the other ones with dandelion too. Even better.
23:08:10 <sethsimmons> Two outputs can't both be spent in the mempool at once, can they?
23:08:18 <moneromooo> Bob will see a bit of a delay (probabilistically) before seeing the subsequent txes.
23:08:24 <sethsimmons> Err two transactions in the mempool can't both spend the same output
23:08:53 <sgp_[m]1> The delay in the mempool makes it a bit more uncertain
23:08:56 <sethsimmons> And Alice wouldn't know or be sending to Bobs node, she'd be using her own or a public node in almost every scenario
23:09:15 <moneromooo> Oh sure. It can hardly happen by chance. I was assuming Alice would be trying :)
23:09:50 <sethsimmons> True
23:10:06 <sethsimmons> But if the store owner didn't expose his node it would remove that whole vector.
23:11:57 <moneromooo> Then how would that store owner know about payments ?
23:12:26 <sethsimmons> Not expose as in not advertise
23:12:40 <sethsimmons> It would still be a synced node of course
23:13:24 <moneromooo> That's called security through obscurity and is typically not something you want to rely on as your main defense.
23:15:04 <sethsimmons> It would protect you from most small time attackers
23:15:18 <sethsimmons> But yeah not something for protecting against a large atyacker
23:15:24 <sethsimmons> Just mean for simple double spends etc
23:15:45 <sgp_[m]1> yeah, once we assume attackers of that capability, by all means wait for a few confirms
23:17:44 <gingeropolous> the p2p in store scenario can also leverage human trust relationships
23:18:02 <gingeropolous> if you goto the same store every day for coffee, the merchant can probably accept 0 conf
23:18:06 <gingeropolous> because you want to come back tomorrow
23:18:39 <gingeropolous> if you are a drifter / noob, merchant might wait for 1 conf or employ some double spend insurance
23:19:21 <gingeropolous> which could probably be a profit mechanism for wallet providers
23:20:03 <gingeropolous> "oh yeah you can 0conf your hamberders if you use walletX"
23:20:40 <sgp_[m]1> ah, basically saying they will cover the double spend risk
23:21:24 <endor00[m]> Accepting a 0conf makes sense for someone buying food in a place where you pay upfront
23:23:35 <sethsimmons> Or allow 0conf for rewards customers etc as a bonus advantage
23:23:43 <sethsimmons> Or raised 0conf limits for rewards
23:24:56 <sethsimmons> Good incentive for people potentially
23:35:45 <tokineko[m]> Which file system without journaling do you recommend for LMDB on linux?
23:35:54 <tokineko[m]>  * Which linux file system without journaling do you recommend for LMDB?
23:37:45 <tokineko[m]> Perhaps, ext4 without journaling?
23:38:22 <gingeropolous> y no journaling?
23:38:26 <tokineko[m]> By the way, max file size on ext4 is 16terabytes.
23:38:54 <tokineko[m]> Journaling seems to degrade LMDB performance.
23:39:53 <crm> You could try and see if your distro allows ZFS, if not, consider using FreeBSD for that
23:40:41 <tokineko[m]> I can have ZFS, but ZFS has journaling and copy on write which degrade LMDB performance.
23:47:28 <tokineko[m]> Can I optimize btrfs for monero blockchain LMDB?
23:48:00 <mawk> btrfs has CoW as well
23:48:32 <mawk> why don't you try ext4 w/o journaling tokineko[m] ?
23:48:38 <tokineko[m]> Perhaps, `nodatacow,nodatasum` btrfs mount options can improve performance.
23:48:49 <mawk> well there's no real point having btrfs then
23:48:53 <mawk> I'd just take ext4
23:48:56 <mawk> for its stability
23:49:10 <tokineko[m]> Max file size on btrfs is 16EiB. Max file size on ext4 is 16TiB.
23:49:25 <mawk> do you plan on having 16TiB files?
23:49:51 <mawk> blockchain is 104GiB currently
23:50:02 <mawk> you have some margin
23:50:32 <mawk> you can change the block size also, to have bigger files on ext4
23:50:40 <tokineko[m]> btrfs has no journal.
23:50:49 <mawk> you can have no journal with ext4 as well
23:50:52 <mawk> if you want you can have btrfs for your base system, then a ext4 partition
23:50:58 <mawk> or a ext4 loop device
23:51:10 <tokineko[m]> Disabling checksums and copy-on-write and compression can improve btrfs performance.
23:51:57 * moneromooo looks suspiciously at any talk of disabling cow...
23:52:02 <mawk> lol
23:52:04 <ComplyLast>  lol
23:52:10 <mawk> I'm not sure it will equal ext4 perf though tokineko[m]
23:52:26 <mawk> you want to do mining right?
23:52:33 <mawk> what else do you need the perf for
23:54:45 <mawk> ext4 with data=writeback would seem enough to me
23:59:06 <gingeropolous> all the perf is useful for running public remote nodes probably
23:59:19 <gingeropolous> well, with the current architecture
23:59:29 <gingeropolous> of wallets asking for useless data