03:22:53 <alcapaca> Hello, I am trying to make a Monero Flutter plugin so that monero wallets can more easily be made in flutter projects.
03:22:53 <alcapaca> I am able to make wallets, restore them, and send transactions so far, but I have run into a pretty serious native crash.
03:22:54 <alcapaca> When I restore a wallet sometimes it will crash with the following error.
03:22:59 <alcapaca> *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** ***
03:23:00 <alcapaca> Build fingerprint: 'google/taimen/taimen:11/RP1A.201005.004.A1/6934943:user/release-keys'
03:23:00 <alcapaca> Revision: 'rev_10'
03:23:01 <alcapaca> ABI: 'arm64'
03:23:01 <alcapaca> Timestamp: 2022-05-05 13:29:07+0800
03:23:02 <alcapaca> pid: 4323, tid: 4415, name: DartWorker  >>> com.example.flutter_libmonero_example <<<
03:23:02 <alcapaca> uid: 10435
03:23:03 <alcapaca> signal 11 (SIGSEGV), code 1 (SEGV_MAPERR), fault addr 0x0
03:23:03 <alcapaca> Cause: null pointer dereference
03:23:04 <alcapaca>     x0  00000077dc66e27c  x1  0000000000000000  x2  0000000000000020  x3  00000077dc90dfc0
03:23:04 <alcapaca>     x4  0000000000000020  x5  00000077dc66e29c  x6  6ba45c57ecedc839  x7  7b693b97342475af
03:23:05 <alcapaca>     x8  000000000029fdc3  x9  000000000000001f  x10 0000000000001b08  x11 00000077dc30e040
03:23:05 <alcapaca>     x12 f23b9fa7f5b2b920  x13 5ab56bcd7a095991  x14 0018b6584180a81a  x15 000000000a516280
03:23:06 <alcapaca>     x16 00000077f1367f90  x17 0000007b077e8000  x18 00000000000bb9d5  x19 0000000000000020
03:23:06 <alcapaca>     x20 0000000000000000  x21 0000000000000000  x22 00000077f1c6fc28  x23 0000000000000020
03:23:07 <alcapaca>     x24 00000077f1c71000  x25 00000077f12e9578  x26 00000077f12e9328  x27 00000077f12e94c8
03:23:07 <alcapaca>     x28 00000077f1c6fc10  x29 00000077f1c6fab0
03:23:08 <alcapaca>     lr  00000077f0844d00  sp  00000077f1c6fa80  pc  0000007b077e7eb0  pst 0000000080000000
03:24:17 <hyc> use a pastebin
03:25:40 <alcapaca> https://pastebin.com/kdgyGSMe
03:26:21 <alcapaca> I can trace the error back to the wallet2::get_cache_file_data function, and I think it is occuring at https://github.com/monero-project/monero/blob/master/src/wallet/wallet2.cpp#L5802
03:28:38 <alcapaca> it seems that in memcpy it tries to derefrence a null pointer, when the wallet is being serialized which causes the crash, however I dont really have an idea why this would happen.
06:48:12 <moneromooo> alcapaca: Try building with -O0 -g and getting a stack trace.
06:48:19 <ErCiccione> Next dev meeting: https://github.com/monero-project/meta/issues/703
06:48:44 <moneromooo> If you can't get a stack trace, printf all over the place repeatedly is what I do.
13:49:50 <xxfedexx[m]> I have got a question about the upcoming Monero view tags
13:49:50 <xxfedexx[m]> If you have the wallet A, and you want to transfer money to wallet B, the view tag included in the tx is A's or B's or both?
13:49:50 <xxfedexx[m]> And wouldn't it decrease privacy?
13:51:10 <sethforprivacy> > <@xxfedexx:matrix.org> I have got a question about the upcoming Monero view tags
13:51:10 <sethforprivacy> > If you have the wallet A, and you want to transfer money to wallet B, the view tag included in the tx is A's or B's or both?
13:51:10 <sethforprivacy> > And wouldn't it decrease privacy?
13:51:10 <sethforprivacy> Not a topic for this channel, but hopefully this answers your Qs: https://localmonero.co/knowledge/view-tags-reduce-monero-sync-time
13:55:04 <xxfedexx[m]> Thanks, but it says:
13:55:04 <xxfedexx[m]> > add a 1-byte “tag” to each transaction using a shared secret known only to the sender and receiver of that transaction.
13:55:04 <xxfedexx[m]> That secret gets regenerated on each transaction with the wallet keys?
13:55:13 <xxfedexx[m]>  * Thanks, but it says:
13:55:13 <xxfedexx[m]> > add a 1-byte “tag” to each transaction using a shared secret known only to the sender and receiver of that transaction.
13:55:13 <xxfedexx[m]> That secret gets regenerated on each transaction with the wallet keys?
13:55:26 <xxfedexx[m]> How can the receiver know it too?
13:55:38 <xxfedexx[m]>  * Thanks, but it says:
13:55:38 <xxfedexx[m]> > add a 1-byte “tag” to each transaction using a shared secret known only to the sender and receiver of that transaction.
13:55:38 <xxfedexx[m]>  That secret gets regenerated on each transaction with the wallet keys?
13:59:38 <xxfedexx[m]> nevermind, the localmonero post is not clear but the github issue https://github.com/monero-project/research-lab/issues/73 explains better 
14:25:48 <BigmenPixel[m]> Hello. Do I need to add the p2pool module for flatpak?
14:25:49 <BigmenPixel[m]> https://github.com/flathub/org.getmonero.Monero/issues/18
14:27:57 <selsta> BigmenPixel[m]: the problem is that the way p2pool is implemented it tries to install the binary in the same directory as the GUI
14:28:07 <selsta> package managers don't like this
14:29:13 <selsta> hyc: my gitian builds are running but will take a couple more hours, i don't have anything cached
14:30:46 <BigmenPixel[m]> selsta: Then I can put the binary file there in advance?
14:31:46 <selsta> might work
14:32:05 <BigmenPixel[m]> selsta: Thanks.
14:49:24 <hyc> selsta: ok
14:54:03 <BigmenPixel[m]> <selsta> "might work" <- Sorry for stupid question.)) Is this p2pool necessary?:
14:54:03 <BigmenPixel[m]> https://github.com/SChernykh/p2pool
14:54:28 <selsta> that's the software, yes
14:54:30 <ooo123ooo123[m]> > <@bigmenpixel:matrix.org> Sorry for stupid question.)) Is this p2pool necessary?:
14:54:30 <ooo123ooo123[m]> > https://github.com/SChernykh/p2pool
14:54:30 <ooo123ooo123[m]> No
14:54:55 <BigmenPixel[m]> 🤔
14:55:04 <selsta> is it 100% necessary to integrate in all distributions of monero-gui, no
14:57:03 <BigmenPixel[m]> selsta: In flatpak, can’t integrate it manually without rebuilding, so it’s better to do it.
14:59:17 <selsta> if you can easily integrate it then good, otherwise I'll add a compile time flag to disable p2pool for package managers
15:02:58 <BigmenPixel[m]> selsta: Thank you for the second time. :)
15:11:21 <merope> Btw, any chance that the rpc_pay feature gets "rewritten" to use p2pool instead of solo mining? As in, the client mines p2pool shares on behalf of the node, rather than full solo blocks
15:11:58 <merope> Fits much better with the "small but consistent payouts" model
15:12:24 <merope> (Perhaps point them directly to p2pool-mini even, rather than the main p2pool)
15:14:08 <gingeropolous> wouldn't that require having p2pool in the daemon, or somehow routing the rpc_pay stuff to a p2pool daemon?
15:15:19 <selsta> merope: the problem is that there is always incentive to run free of charge nodes for malicious actors, they need the data and not the hashrate
15:16:21 <merope> oh I don't mean that as a solution for the malicious node problem, it was an unrelated suggestion about promoting rpc-pay
15:16:29 <selsta> and as long as there are free nodes people are unlikely to use rpc-pay
15:18:11 <ooo123ooo123[m]> <merope> "Fits much better with the "small..." <- p2pool is just an illusion of "small but consistent payouts"
15:18:45 <merope> ooo123ooo123 not the place, and also wrong
15:19:45 <selsta> what i meant, as it currently is i don't see rpc-pay being adopted
15:20:58 <selsta> (even if it somehow uses p2pool)
15:21:45 <merope> Right - but think of it in terms of "send a tip to your favourite public node to support them". Most people don't do that now, because the odds of finding anything are so low that it's not even worth their effort to figure it out
15:22:14 <merope> But now that we have the p2pool integration, the odds of finding something on p2pool mini are significantly higher
15:22:36 <ooo123ooo123[m]> merope: how much significantly in numbers ?
15:22:50 <ooo123ooo123[m]> relatively to solo mining
15:23:56 <merope> Main chain diff is ~300G these days, while p2pool mini typically hangs around 100M-200M
15:24:31 <merope> so 1000x-3000x better odds of finding something
15:24:52 <merope> Of course, the payout is proportional - but it's something
15:25:12 <ooo123ooo123[m]> do you consider 1e-15 as something too ?
15:25:45 <ooo123ooo123[m]> can you just use numbers instead of words ?
15:25:53 <merope> Irrelevant question, but yes
15:25:54 <ooo123ooo123[m]> they are ambigious
15:28:34 <ooo123ooo123[m]> endor00[m]: There are no numbers in p2pool README too, only words "more frequent payouts"
15:28:34 <ooo123ooo123[m]> Therefore it's an illusion
15:29:18 <ooo123ooo123[m]> edit: it uses word "Regular"
15:43:00 <UkoeHB> How do p2pool payouts compare to the differential fee from spending a p2pool output?
15:50:30 <monerobull[m]> Fees are rather high, id say it's also rather easy to figure out the true sender
15:52:39 <monerobull[m]> Since p2pool addresses are public, you could cross reference them with transactions that have tons of inputs. Unless your ring includes some other people miner address sending a large transaction it would be very easy to pinpoint you as the real sender, right?
15:53:08 <monerobull[m]> s/people/p2pool/
15:59:41 <ooo123ooo123[m]> <merope> "so 1000x-3000x better odds of..." <- Are you sure that 1000x-3000x multiplier is applicable to equal amount of "something" from pool mining / solo mining / p2pool mining ?
16:00:28 <merope> Yes
16:00:54 <ooo123ooo123[m]> merope: You're good at math then
16:10:56 <ooo123ooo123[m]> <merope> "Yes" <- Can you help me to calculate it ? I believe it's at most 12x
16:11:37 <ooo123ooo123[m]> relatively to solo mining
16:11:53 <merope> This is not the right channel for this discussion
16:54:15 <sethforprivacy> Do these cmake flags look correct for building static binaries?... (full message at https://libera.ems.host/_matrix/media/r0/download/libera.chat/ee6981c667cbd256e84b98ab4ebfb453ff86181a)
16:55:46 <sethforprivacy> From https://github.com/sethforprivacy/simple-monerod-docker/blob/main/Dockerfile
16:56:15 <ooo123ooo123[m]> > <@sethforprivacy:matrix.optoutpod.com> Do these cmake flags look correct for building static binaries?... (full message at https://libera.ems.host/_matrix/media/r0/download/libera.chat/0aed50009cc9ee3d7497ce7c99252919e5a25949)
16:56:45 <selsta> yes, use depends like here https://github.com/monero-project/monero/blob/master/Dockerfile#L31
16:56:51 <moneromooo> STATIC=ON will build most libs statically, if found.
16:57:06 <moneromooo> Note "if found".
16:57:40 <moneromooo> Though not giving you a static binary, pedantically.
16:59:34 <sethforprivacy> Yeah, `file monerod` is still showing dynamically linked
17:00:02 <sethforprivacy> I want a unified Dockerfile for multiple arches so depends is not ideal...
17:00:07 <moneromooo> It's the best you're gonna get. Just make sure you don't have stuff you'd think should be static in ldd output.
17:00:20 <sethforprivacy> Thanks
17:00:21 <moneromooo> Like 0mq etc.
17:10:25 <hyc> aren't all the dependencies in our depends builds static?
17:10:42 <hyc> that's what gitian is for, setting up the env so nothing else is present
17:14:11 <selsta> my daemon on master branch had a segfault but ulimit -c was set to 0 (even though it was set to unlimit from the last segfault..)
17:14:34 <selsta> so I wasn't able to find a core file
17:14:39 <selsta> have it running in gdb now
17:15:34 <hyc> that's too bad. I've been running on master from (v0.17.0.0-67e5ca9ad) for ~9days now
17:30:43 <selsta> so far all hashes match but still 3 operating systems to go to go
17:31:48 <hyc> cool
17:32:19 <hyc> if there were any timestamp discrepancies they'd certainly show up by now, anyway
17:33:22 <selsta> btw all testnet node operators should compile master so that they end up on the correct chain
19:09:03 <gingeropolous[m]> whens that fork?
19:14:09 <hyc> less than a week\
19:15:10 <plowsof[m]> Testnet hard-fork: May 16th, 2022, block 1982800 and 1983520
19:15:10 <plowsof[m]> Stagenet hard-fork: July 9th
19:15:10 <plowsof[m]> Mainnet hard-fork: July 16th, 2022, block 2668888
19:17:34 <gingeropolous> ok, just compiled master and running testnet on xmrchain
19:18:28 <sech1> hmm, need to spin up testnet p2pool by May 16th
19:20:48 <gingeropolous[m]> lol cookie
19:38:05 <sethforprivacy> Will it be tagged before then? I'll push a Docker build as well once there is a tag, or I can do a special one if not.
19:40:54 <selsta> no tag
20:37:37 <UkoeHB> selsta: what kind of time-line should I aim for with the 'good to haves' remaining here https://github.com/monero-project/monero/issues/8237 ?
20:38:43 <selsta> I don't know, I don't see much point in not merging it just because some arbitrary dated passed.
20:39:01 <selsta> The current multisig is broken anyway so as long as we didn't tag it should be fine.
20:40:26 <UkoeHB> well it looks like you are wanting to tag in 5 days, when would the next tag be? or maybe I'm missing something
20:41:28 <selsta> no we won't tag in 5 days
20:41:41 <selsta> testnet hardfork doesn't require a tag
20:41:58 <UkoeHB> stagenet then? 21 days?
20:42:10 <UkoeHB> wait that's a month
20:42:15 <selsta> yep
20:42:29 <selsta> plan is to release ~1 month before mainnet hardfork
20:42:38 <UkoeHB> ok I will try to get them PR'd by next monday
20:42:57 <UkoeHB> or the first one anyway (and third one rebased)
20:43:09 <UkoeHB> this coming monday*
21:27:23 <monerobull[m]> this is about the ccs: i accidentally upvoted some ccs proposals with my gitlab github account eventhough i already upvoted them with my gitlab only account, I think i reverted everything but in case i missed one i wanted to make it clear that im not trying to manipulate any votes
22:04:51 <selsta> .merge+ 8312
22:04:51 <xmr-pr> Added