00:17:40 <binaryFate> FYI the auto-update should now prompt to v0.18.1.0
03:11:51 <selsta> .merges
03:11:51 -xmr-pr- 8299 8323 8333 8352 8359 8379 8381 8415 8419 8427 8428 8442 8444 8450 8460 8462 8464 8465 8490 8491
05:57:32 <sech1> Will there be any post-mortem of the hardfork issues? IIRC there was one problem with transactions flushing from the mempool.
06:20:31 <ofrnxmr[m]> Sech1 https://libera.monerologs.net/monero-dev/20220813#c134478
06:24:41 <sech1> so 50 tx dropped, and old format transactions could only relay if they had higher than lowest priority fee
06:24:58 <sech1> but they could be mined
08:06:11 <ErCiccione> what could couse no incoming connection in a stagenet node. firewall ok, permissions seem to be ok. I have two almost identical config file for 2 nodes. 1 can receive incoming  connections just fine, the other one doesn't.
08:06:37 <ErCiccione> it's likely a local issue unrelated to Monero, but i cannot find it
08:10:50 <moneromooo> Very few stagenet nodes around ?
08:14:53 <ErCiccione> if i take down the node that receives connections the other one has still 0 incoming
08:24:25 <ErCiccione> now that i added each others as peers, the second instance is starting to pick up incoming connections. i guess it was because of the few nodes
08:44:03 <nssy> Is there a change that was made that guys need to know when batching up transactions?
08:44:22 <nssy> Cause its failing multiple times.
08:44:45 <nssy> Error with transfer RPC request to wallet daemon {"code":-4,"message":"transaction was rejected by daemon"}
08:47:48 <moneromooo> What error does the daemon report ?
09:00:15 <stretch1> DRSBcvRJDMPcoNzOTPaQXQvwZy2ttXDIwK6h1
09:08:00 <inge> indeed
09:08:36 <hyc> I too like to paste my web passwords into IRC windows from time to time
09:09:26 <inge> spices life up a little
09:09:37 <hyc> exactly
09:15:38 <nssy> moneromooo not showing any error.. Maybe will need to adjust log level
09:15:51 <moneromooo> ll1
09:15:51 <nssy> Have already sent the transactions individually though
09:18:37 <afungible[m]> <ofrnxmr[m]> "Sech1 https://libera.monerologs..." <- Curious, what are the consequence beyond dropping those 50k transactions? Have they been released from mempool & back to users wallet or will lurk around in txpool until timeout?
09:19:17 <sech1> 50 transactions, not 50k
09:19:26 <sech1> they should be shown as "failed" in the wallet
09:21:28 <afungible[m]> sech1: Ah, crap, misread it. Then I guess its not a big deal 😁
09:22:38 <spacekitty420[m4> could be a big deal, imagine a single one of those tx was sending 18 millions xmr o.o
09:23:15 <afungible[m]> And btw, what's the timeout of mempool like (hours or days?), should a transaction not go through or having too low fee at a time of network load?
09:24:09 <afungible[m]> I meant transaction goes through, bt waiting on 0/10 confirmations. Waiting to get into a block..
09:24:31 <hyc> 24hrs
09:28:09 <sech1> #define CRYPTONOTE_MEMPOOL_TX_LIVETIME                    (86400*3) //seconds, three days
09:28:09 <sech1> #define CRYPTONOTE_MEMPOOL_TX_FROM_ALT_BLOCK_LIVETIME     604800 //seconds, one week
09:28:29 <sech1> 3 days for new transaction, 1 week for transactions pushed back to mempool after a reorg
09:31:35 <nssy> moneromooo: Here is another one with error https://paste.debian.net/1250462/
09:34:47 <moneromooo> Well, spend your outputs only once then :P
09:34:58 <moneromooo> You may need to run "rescan_spent" once if it went out of sync.
09:36:14 <nssy> Ok. doing that now..
09:39:10 <moneromooo> hyc: is it ok, performance wise, to have *very* long lived read txns ?
09:39:21 <moneromooo> Like, hours.
09:40:07 <moneromooo> In this case, there won't be any writes to the db, but lots of reads.
09:41:00 <hyc> sure. the only issue is if a read prevents a write from reusing old pages. if there's no writes, no problem
09:42:03 <moneromooo> ty
09:47:52 <hyc> can mount a DB from a CDROM or some other read-only filesystem, then you can use a single read txn forever
10:06:54 <nssy> thanks moneromooo that worked, have not clue how the wallet went out of sync its always online
10:46:05 <afungible[m]> <sech1> "3 days for new transaction, 1..." <- Good information. Thanks.
10:47:51 <afungible[m]> Any idea why I don't see "mining_status" in CLI v0.18.1.0? I reckon it used to be there before..
10:55:32 <nikg83[m]> We have had 1/4th txs in last 24hrs , popular wallets pushed update only last minute, plenty of normal users didn’t even know about this fork/upgrade 
10:55:33 <nikg83[m]> Maybe next cycle we have fork announce and code freeze alteast a few months (4-5) before so the user wallets/nodes are ready in time ? Anyways we are now not in the old 6 month fork schedule, and fork/update like once in 2-3yrs 
10:55:33 <nikg83[m]> We can’t have serious adoption it majority of the payment ecosystem is down for days & users confused why monero is broken for them 😅
11:05:45 <moneromooo> Are you sure you're looking in the daemon ?
11:28:00 <nikg83[m]> Localmonero stats are wrong ?
11:28:33 <nikg83[m]> https://localmonero.co/blocks/stats/transaction-stats
11:41:50 <dEBRUYNE> nikg83[m]: Many services also disable withdrawals / deposits around the fork date, so part of the drop can be explained by that
11:50:05 <moneromooo> It would be nice if people could try 8503. The resulting DB works for me, at least.
11:50:23 <moneromooo> Something I should have fixed long ago.
11:52:28 <moneromooo> hyc: when pruning the chain, the process reads about 900 GB, from a ~140 GB file. Is this hiding some bug somewhere, or can it be explained by page interleaving if the SSD read quantum is > 4 kB (I have no idea what mine is) ?
12:05:26 <Guest63> Hey, is the RPC method flush_txpool deprecated? I tried to use it on my node with a list of transaction ids as shown on the website, but it failed with `method not found`
12:05:49 <Guest63> This is the command I tried:  `curl http:///monero.kevinthomas.dev:18089/json_rpc -d '{"jsonrpc":"2.0","id":"0","method":"flush_txpool","params":{"txids":["6fa3cfa75ef51d194dfbceac9714fd67c89eded4ce7711fe36b2b7ee7d74647c"]}}' -H 'Content-Type: application/json'`
12:07:06 <moneromooo> No.
12:07:16 <moneromooo> Make sure your node is not running in restricted mode.
12:08:57 <Guest63> Well, I don't know if that person's node is in restricted mode. I sent a transaction to his node, which looks to be bricked. Its block height is over a day old (2688894). I think his node is pre-0.18 and my transaction is sitting in his transaction pool. I wonder how long it will be before it's dropped. It's been there for over a day.
12:09:49 <Guest63> My txid is 6fa3cfa75ef51d194dfbceac9714fd67c89eded4ce7711fe36b2b7ee7d74647c, which wasn't relayed to other nodes so it's not visible on xmrchain.net
12:09:57 <moneromooo> If it's not your node, you can't expect us to help you :)
12:10:05 <Guest63> Yeah, RIP..
12:10:13 <moneromooo> Maybe in #monero though.
12:10:28 <sech1> Just relay a new tx to working node
12:10:40 <sech1> old not updated nodes are disconnected from the network now, so they're irrelevant
12:11:08 <Guest63> I guess my question is: My transaction is sitting in someone's memory pool. How long before it is dropped?
12:11:16 <sech1> 3 days
12:11:32 <moneromooo> If they feel like it. They might keep it for longer, or less.
12:11:41 <sech1> but if other nodes don't have it, they'll accept a new tx with the same inputs
12:11:56 <Guest63> I emailed him and told him to flush my transaction out of his memory pool.
12:12:09 <Guest63> Can I expedite this process somehow? You mentioned: Just relay a new tx to working node. What do you mean by this? Force a double-spend, essentially?
12:12:23 <Guest63> Is it even considered a double-spend if other nodes don't even know about the transaction?
12:12:24 <sech1> send a new tx from your wallet
12:12:35 <sech1> it's not a double spend
12:13:00 <Guest63> I sent 0.01 XMR to myself, I don't see a change in my balance (the recovery of the 1 XMR I (failed to) relay with the bricked node)
12:13:25 <Guest63> I think it's because the input selected for the 0.01 XMR wasn't the same as the inputs used for the 1 XMR I previously sent to the bricked node?
12:13:35 <moneromooo> Run your own node, then rescan_spent in the wallet.
12:13:51 <sech1> or connect to an updated and working node
12:13:55 <sech1> and then rescan_spent
12:14:00 <moneromooo> Or the wallet will probably auto do it if you refresh a couple times.
12:14:34 <Guest63> I sent the transaction from CakeWallet. Should I just restore the wallet on my desktop using the GUI wallet?
12:14:46 <moneromooo> Can't hurt.
12:15:03 <moneromooo> Well, you'll lose things like tx secret keys, destinations.
12:15:18 <moneromooo> ie, stuff that doesn't get recorded on the chain.
12:15:26 <Guest63> Notes, etc. I get that part. Thanks
12:15:50 <moneromooo> But from what you're saying, the wallet is fine. The node isn't.
12:16:36 <Guest63> Is the rescan_spent command available via the GUI wallet?
12:17:41 <moneromooo> I think so. Not sure where though.
12:17:52 <Guest63> Okay, I'm comfortable with the CLI, I'll use that.
12:39:22 <Guest63> Hmm, I did rescan_spent and my balance is the same.
12:40:16 <Guest63> Anyway for me to verify that I'm not crazy (that indeed I sent the transaction to a bricked node)?
12:41:23 <Guest63> And that my balance is indeed reflextive of Y Monero - Amount Sent to Bricked Node
12:42:41 <Guest63> Maybe I'm incorrectly recounting the amount of Monero I had before I sent a transaction to the bricked node. I just want to confirm that is the case if indeed it's true
12:42:57 <Guest63> help
12:43:04 <Guest63> Woops, I meant to type 'help' in my CLI.
12:44:05 <moneromooo> Maybe ask in #monero.
12:44:40 <Guest63> Sure
13:19:27 <nxs> can i recommend making a patch release reverting https://github.com/monero-project/monero/issues/8476 
13:19:46 <nxs> its causing issues for watch-only / offline signing setup 
13:20:25 <nxs> sorry, the commit is https://github.com/monero-project/monero/commit/ae0a840fdaa15054a7c0529869fb20df0e1605ea - the issue linked is the problem
13:29:51 <ofrnxmr[m]> Issues such as
13:43:58 <nxs> the signing node will fail to sign anything until you do a full output sync, which itself can take a while to process
13:44:40 <nxs> so for a *cough* large org using this setup, its quite a burden to continually do a full output sync before every withdrawal request to make sure it will complete
13:45:19 <nxs> and the monero node software shouldn't depend on this kind of behavior anyway - remote signing should work without continual output syncs
13:46:03 <nxs> it was problem introduced in v0.18.0.0
13:59:52 <woodser[m]> a few questions on signing/verifyin/encrypting messages:
13:59:53 <woodser[m]> - is there an advantage/disadvantage to signing with the speed vs view key? I suppose this simply lets one prove they have certain keys?
13:59:53 <woodser[m]> - is there a way to encrypt/decrypt arbitrary strings? the library could expose such functionality
13:59:53 <woodser[m]> - on `verify`, do the other fields like `old` or `version` need to be somehow checked, or does `good` cover the summary?
14:00:04 <woodser[m]> s/speed/spend/
14:02:47 <ofrnxmr[m]> nks: thanks for explaining 
14:03:02 <ofrnxmr[m]> nxs:  * 
14:08:27 <moneromooo> Signing with the view key -> if you gave your view key to someone, they can impersonate you.
14:09:02 <moneromooo> You can sign with any key. There's a RPC for signing arbitrary data with the spend key IIRC.
14:10:50 <woodser[m]> signing arbitrary data, yes, but not encrypting/decrypting to my knowledge
14:10:52 <moneromooo> Oh, I'm confusing encrypt/signing on the second question. I don't think there is for that.
14:11:26 <moneromooo> There's a funtion for it in wallet2 though, so it'd simple to add to RPC.
14:11:33 <moneromooo> authenticated too.
14:12:00 <moneromooo> Though vtnerd might have things he wants to change first if it's to be exposed via RPC.
14:14:12 <moneromooo> I cna't recall what changed between v1 and v2 for signing, but good means the sig was verified as eihter v1 or v2.
14:14:28 <moneromooo> So chcek for !old only if you want to ensure the signature was made with v2. Which is probably a good idea.
14:14:58 <moneromooo> git log might shed some light about the version change, maybe it was exploitable before. Can't recall.
14:35:34 <jozsef[m]> Thanks moo. I'd like to use encrypt/decrypt via the cpp api, so I'm thinking that I will look into creating a PR to expose those functions from wallet2 to the wallet-rpc and then exposing those to the cpp api. Should I coordinate with vtnerd or I will just ping him to the PR ...
14:48:44 <vtnerd> Im not working on such a thing, moo may have mentioned it because there's also the ZeroMQ API which mirrors the HTTP-JSON-RPC one
14:49:36 <vtnerd> or the tricky part over json is the encoding the binary ... hex I guess (thats how binary data is always encoding despite ineffiency on the wire)
14:51:20 <woodser[m]> if the api exports binary or hex, libraries could convert the binary client side
14:59:21 <vtnerd> both HTTP and ZeroMQ use JSON for encoding, so you have to convert before setting the values in the DOM (and the opposite in the other direction)
14:59:53 <vtnerd> the HTTP-JSON might do it automatically for all `std::string`, but I don't think they do
15:06:44 <moneromooo> I mentioned it because IIRC you wanted to improve the authenticated encryption from wallet2, using... I forget now...
15:07:04 <moneromooo> Poly1305 I think ?
15:08:43 <vtnerd> oh man what does it use, I forgot now
15:11:45 <moneromooo> Something I made :D
15:12:17 <vtnerd> https://github.com/monero-project/monero/blob/master/src/wallet/wallet2.cpp#L13740
15:12:20 <moneromooo> With at least *some* sanity though. Like sign after encrypt.
15:12:24 <vtnerd> thats the function they want to expose?
15:12:54 <moneromooo> I assume so.
15:15:10 <vtnerd> woodser[m] : do you want an API for sending encrypted TO another person? like you could optionally sign who created it, and but then send that blob to another person?
15:15:38 <vtnerd> because that function looks more like the same person doing the encryption/decryption, no? I think that may have been my point earlier if I made one
15:19:18 <woodser[m]> yeah we're looking to encrypt and decrypt arbitrary text using the same wallet keys
15:19:48 <vtnerd> oh same keys, yeah then that function will work
15:20:49 <woodser[m]> ^ jozsef
15:21:27 <vtnerd> you'd definitely authentication to be set to true, but otherwise yeah
15:23:42 <jozsef[m]> Yeah, looks like that fn will work. So we should expose to both HTTP and ZMQ RPC? And would the cyphertext have to be encoded before send to the API?
15:24:51 <vtnerd> yes in both cases it has to be manually set to/from some json friendly format
15:25:53 <vtnerd> everything else uses hex for simplicity, but its not wrong to use something else
15:26:26 <vtnerd> base85 from zmq if you want efficiency (and annoy programmers), etc
15:26:53 <jozsef[m]> Okay, I will look how other encode/decode is done.
15:28:55 <selsta> 12:55 <nikg83[m]> Maybe next cycle we have fork announce and code freeze alteast a few months (4-5) before so the user wallets/nodes are ready in time ? Anyways we are now not in the old 6 month fork schedule, and fork/update like once in 2-3yrs  <-- we released binaries 1 month in advance, that should be enough time
15:29:25 <selsta> exchanges disable deposit / withdrawals for security reasons when a fork happens
15:29:38 <jozsef[m]> vtnerd: Hehe. Not necessarily to annoy, but for efficiency: I'd like to encrypt/decrypt  and send relatively largeish data with it, e.g., containing multiple images and text.
15:29:39 <selsta> also who knows what kind of transaction spam scripts forgot to update
15:42:08 <nikg83[m]> <selsta> "12:55 <nikg83> Maybe next..." <- Yes, but prominent mobile wallets did a week/day before fork ? Also not every monero user tracks news/updates & most also defer it while everything is working
15:42:08 <nikg83[m]> if we had 3-4 months buffer then plenty of users would have updated it, we have major fork not that often now so a few months more buffer is not going to hurt ? Unless it’s a emergency fork 
15:43:05 <ofrnxmr[m]> Nikg i replied in community 
15:43:15 <ofrnxmr[m]> Ill post it here..
15:43:45 <ofrnxmr[m]> https://matrix.to/#/!WzzKmkfUkXPHFERgvm:matrix.org/$r19qQCUQruwNrZdNoyxsKTvbwo4IS6K0m5j_jQVJgLU?via=monero.social&via=matrix.org&via=libera.chat
15:44:08 <ofrnxmr[m]> https://libera.monerologs.net/monero-community/20220815#c135437
15:44:21 <Rucknium[m]> BCH node implementers agreed on the May 2022 hardfork date a full year in advance; binaries were available months before the fork; still transaction volume fell by about 50% at the fork. And it was a block rules consensus change, not even a backwards-compatibility issue for wallets IIRC.
15:45:14 <Rucknium[m]> I would agree that more advance notice/binaries would be nice, but many, many people do not realize there is a fork until their software stops working.
15:45:42 <ofrnxmr[m]> Tldr from my community post 
15:46:17 <selsta> nxs: will revert it
15:46:28 <ofrnxmr[m]> >Yes, but prominent mobile wallets did a week/day before fork ? 
15:46:28 <ofrnxmr[m]> This was their 100% their choice 
16:01:43 <hyc> moneromooo: any perf difference for that last change, always using MDB_APPEND?
16:02:02 <hyc> seems like it shouldn't affect most of the relevant tables
16:05:24 <moneromooo> I'll know in 1.5 hours :)
16:06:41 <hyc> cool
16:13:34 <moneromooo> hyc: well, before 1.6 hours. It fails with: Failed to write block_info record: MDB_KEYEXIST: Key/data pair already exists
16:14:25 <moneromooo> Is the previous version actually wrong, or just non optimal ?
16:16:35 <moneromooo> I reverted to the original patch for now.
16:17:36 <hyc> seemed not optimal to me. but this error implies you're not actually traversing the DB in DB order
16:17:43 <hyc> so ok, original patch is fine
16:18:46 <moneromooo> I use MDB_FIRST/MDB_NEXT.
16:18:53 * moneromooo double checks
16:19:54 <moneromooo> Yes, lines 221-226.
16:20:30 <moneromooo> Could an intervening commit and cursor reopen interfere maybe ?
16:20:38 <hyc> maybe
16:20:47 <moneromooo> Cause I do that.
16:21:04 <hyc> then your original patch is prob the way to go\
16:21:27 <moneromooo> I'll try clearing APPEND for the first put after a commit and see if that helps.
16:27:24 <moneromooo> It's got past that point.
16:27:31 <hyc> cool
16:28:12 <moneromooo> Oh wait, I'm not using your two flags at once change here.
16:32:13 <moneromooo> Meh, still borks. Always at hte same place, oddly. The first table copies fine, the secone table breaks at/near start.
16:33:32 <moneromooo> First atble takes about 3 minutes either way so it doesn't look like the two flags go faster anyway.
16:33:51 <hyc> ok then never mind it
16:50:42 <moneromooo> It now breaks with the old code... :S
16:50:47 <hyc> 8473 is just flaky hardware
16:50:52 <hyc> doh
16:52:10 <moneromooo> Ah, might have forgot a step, I don't test on the same VM.
16:52:27 <moneromooo> A number of copies involved :)
16:56:07 <moneromooo> Yeah nvm, it's fine.
17:13:46 <jozsef[m]> wallet api tests have been disabled for a long time, correct? https://github.com/monero-project/monero/issues/895
17:14:17 <moneromooo> Yes. They'be been borked since the start pretty much, and nobody cared about them.
17:14:43 <moneromooo> IIRC they had peculiar manual steps requirements to have them be able to run.
17:15:18 <jozsef[m]> So what's a good way of testing exposing a new fn (at least by hand) to see what I'm screwing up?
17:15:57 <moneromooo> Add some widget in the GUI to use it ? Even if placeholder for you.
17:16:16 <jozsef[m]> The gUI?
17:16:21 <moneromooo> Or replace an existing widget's code-that-calls-the-api with yours.
17:16:42 <moneromooo> The window based wallet ?
17:16:47 <moneromooo> monero-wallet-gui
17:17:09 <jozsef[m]> Oh, I maybe talking about something else due to my ignorance. No. I want to expose a function from wallet2 to wallet-rpc.
17:17:19 <moneromooo> Oh.
17:17:20 <jozsef[m]> I guess that's not tested with wallet api, then.
17:17:33 <moneromooo> Then you don't need wallet2_api at all, thankfully.
17:17:52 <moneromooo> You add a python layer for it to utils/python-rpc/framework/wallet.py
17:18:07 <moneromooo> Then you can call it from a test in tests/functional_tests/*.py
17:18:21 <moneromooo> For starters though, maybe curl's easier.
17:19:46 <moneromooo> The python function in utils/python-rpc/framework/wallet.py should be just a call with arguments btw, just expose the RPC, no extra logic please.
17:21:13 <jozsef[m]> OK
17:32:05 <selsta> hyc: https://github.com/monero-project/monero/issues/8504
17:32:11 <selsta> I thought we fixed this in randomx
17:39:42 <selsta> or is this a different issue?
19:00:18 <hyc> hm, this looks different
19:00:28 <hyc> never saw failure to allocate cache before
19:00:42 <hyc> and clearly it was succeeding up to that point
19:02:12 <hyc> could be an actual memory leak in monerod?
19:02:59 <selsta> I synced up with v0.18.1.0 and saw no increased memory usage on Mac
19:03:21 <selsta> 3.7GB full system RAM usage
19:03:33 <selsta> and I didn't restart after the full sync
19:03:40 <sech1> hyc it happened near or at randomx epoch change (block height 2689089)
19:03:46 <sech1> according to the log there
19:04:07 <hyc> yes so it may be a legit malloc failure, since it would alloc a new cache then
19:04:35 <hyc> if that was the first time it crossed an epoch boundary in that run
19:05:02 <sech1> it was
19:05:46 <hyc> so the machine was just out of RAM
19:06:07 <selsta> I can ask them how much RAM they have
19:45:21 <selsta> vtnerd: how much work would it be to add https://github.com/jedisct1/supercop/tree/master/crypto_scalarmult/curve25519/neon2 to our supercop repo for ARM CPUs?
19:55:42 <vtnerd> for jamtis or something more immediate?
19:55:56 <vtnerd> thats a speedup on curve25519/x25519 but not directly on ed25519
19:56:24 <vtnerd> I think it would require recovery of y-coord then a conversion between curves
19:57:06 <vtnerd> still might be faster (whereas jamtis is proposing x25519 directly for certain things)
19:57:23 <selsta> You wrote "This should speed up the ECDH portion of the address scanning on relevant arm processors." in an old GitHub issue
19:57:52 <selsta> so I wasn't sure if it was applicable for current monero
19:58:09 <selsta> https://github.com/monero-project/monero/issues/1828#issuecomment-284109776
19:58:19 <vtnerd> ah, yikes. Yeah I think it still would, it just loses some due to the extra math for conversion
20:02:03 <selsta> seems more involved compared to crypto_sign/ed25519/amd64-51-30k and amd64-64-24k
20:03:33 <vtnerd> a bit. y-coord recovery would be the blocker (at least for me)
20:03:58 <vtnerd> specifically the sign portion, but maybe someone else knows immediately off hand
20:04:44 <selsta> maybe I will have to live without ARM ASM optimizations until jamtis
20:04:51 <vtnerd> I'll try to dig through the details, this would be a huge boost for the increasing number of arm64 users
20:21:39 <ofrnxmr[m]> Users = nodes or wallets? 
20:21:56 <selsta> wallets mainly, but we also have more nodes
20:24:43 <vtnerd> supercop isn't currently used by the daemon for syncing, only for wallets
20:42:18 <selsta> using it for historical sync would be an easy win but that's a different topic
21:12:38 <UkoeHB> easiest to speed up would be ge_add(), which is at the core of multiexp (bulletproofs currently, then bps & grootle with seraphis)
21:30:03 <hyc> 3.9GB is kind of a suspicious size for #8504. check to make sure he used a 64bit binary, not 32bit?
21:30:53 <selsta> there is no 32bit mac binary
21:42:00 <hyc> oh right forgot that was a mac
21:42:06 <hyc> intel mac\
21:43:37 <selsta> that's the one we cross compile with the newer sdk, but i don't see how low level malloc is impacted by this
21:45:36 <hyc> right. well technically we allocate using mmap
21:45:44 <hyc> but still, shouldn't have any issue there