00:01:35 <moneromooo> There's a vm for the current height's seed, and one used for others.
00:02:00 <moneromooo> So if you send blocks alternating between two epochs that don't include the current top, it should thrash.
00:28:56 <bonedaddy> is there a better way to locally run a private monero testnet other than launching my monerod node with `monerod --testnet --no-igd --hide-my-port --data-dir testnet/node1/datadir --fixed-difficulty 100 --offline --detach`
00:32:18 <n3ptune> I have a question about the daemon RPC method "get_transactions" where decode_as_json=true. Suppose I read the "extra" array for some transaction in "txs_as_json". In the case of extra subfields which explicitly specify their size, would the size still be varint encoded here, or already decoded? i.e. suppose the sub-field size was 1000, would it show here as [ ... 1000 ... ] or something like [ ... 128, 128, 128,
00:32:19 <n3ptune> 128, 128, 128, 128, 104 ... ]?
00:37:58 <moneromooo> If yo umean
00:38:27 <moneromooo> If you mean the existing size based fields, they're one byte IIRC. A custom field is free to use varints or whatever it wants though.
00:40:06 <moneromooo> Heh. I checked, I'm wrong. It's actually varint, but the nonce field adds a check it does not go beyond 255...
00:40:42 <moneromooo> The values in extra are bytes. So you would not see 1000.
00:52:31 <n3ptune> hmm, yeah in terms of the existing fields it could only be nonce. But I am considering possibility of nonstandard fields too. So when you say "It's actually varint": suppose there is a nonce with length 200, would it show here as [ ... 200 ... ] or [ ... 128, 72 ... ] ?  it's like, would it serialize it with the original varint encoding, or was it already decoded and it would be decoded in the serialization.
01:05:20 <moneromooo> It'd be 128, 72, assuming thar's the correct representation.
01:07:10 <n3ptune> ahh thx
02:32:53 <kayabaNerve> moneromooo: Thanks for the info :)
03:44:52 <bonedaddy> where can you request testnet monero, is there a faucet or something?
03:48:56 <niocbrrrrrr> bonedaddy: https://community.xmr.to/faucet/testnet/
03:49:32 <bonedaddy> thanks
03:49:41 <niocbrrrrrr> :)
03:49:58 <bonedaddy> are there any public testnet monerod nodes I can connect monero-wallet-rpc to? i dont have enough disk space to download the testnet
04:57:13 <rbrunner> bonedaddy: Right now we can be glad if testnet keeps running at all. So few people are running on current master already, seed nodes probably not yet ready, it's currently on its last leg :)
05:07:21 <bonedaddy> yea makes sense it can be hard to keep a testnet running
05:08:08 <bonedaddy> so on my local testnet im running im getting some peculiar errors for some addresses in a wallet, but not all addresses. The specific error is "not enough outputs to use Please use sweep_dust." is this because the decoy selection algorithm cant find enough decoys to select?
05:10:27 <rbrunner> Not sure, but somehow sounds like it.
05:11:29 <rbrunner> There are more than enough testnet nodes around, in principle. Before the hardfork my daemon connected to 50 other ones. I think we just need more people to upgrade-
06:58:28 <TrasherDK> Testnet is doing fine. Net hashrate 4.5 KH/s :)
07:20:09 <rbrunner> Yeah, mining is no problem, somebody provides that hashrate, all good. But the number of active and reachable servers is pretty miserable right now.
07:21:00 <rbrunner> Ah, better now than early this morning UTC, I have now 10 connections, 5 in and 5 out. Almost usable :)
07:24:57 <TrasherDK> [2020-09-06 09:24:21.150]  net      new job from localhost:8000 diff 95411 algo rx/0 height 1545861
07:24:58 <TrasherDK> [2020-09-06 09:24:38.300]  miner    speed 10s/60s/15m 768.0 767.6 663.5 H/s max 1168.1 H/s
09:07:10 <fluffypony> dsc_: merged
09:07:51 <fluffypony> now someone just needs to update the submodule
11:51:15 <moneromooo> fluffypony: thanks, 6802 now pulls it into monero.
11:58:03 <dsc_> thxxx
12:02:01 -xmr-pr- moneromooo-monero opened pull request #6802: unbound: update to get build fixes
12:02:01 -xmr-pr- > https://github.com/monero-project/monero/pull/6802
12:09:59 <dsc_> .merge+ I dont really have permission to add merges but ill add 6802 anyway
12:10:08 <dsc_> .merges
12:10:08 -xmr-pr- 6111
12:10:34 <dsc_> damn :|
12:11:01 <dsc_> .merge+ test #6802 test
12:11:17 <dsc_> I guess that voice permission thing works fine again.
12:12:33 <moneromooo> .merge+ looks like dsc_ can't add -6802-
12:12:33 <xmr-pr> Added
12:12:38 <moneromooo> .merges
12:12:38 -xmr-pr- 6111 6802
12:12:43 <dsc_> :>
12:15:55 <dsc_> I was able to cross-compile this https://i.imgur.com/9wUshar.jpg using https://mxe.cc/
12:16:33 <dsc_> Next up: libwallet + Qt
13:23:28 <rbrunner> Er ... I have now townforge running but no idea how to operate. Is there some menu? Didn't manage to display one. Special keys? No mouse clicks seem to result in anything. Either I am dumb, it's not obvious, or something does not work
13:23:51 <iDunk> Wrong channel.
13:35:41 <dsc_> Snipa: Pretty please merge #6802 :) ?
13:48:11 <fluffypony> I'll merge it if there's urgency
13:49:43 <fluffypony> done
13:49:50 <fluffypony> and doing 6111 as well
13:50:56 <fluffypony> done ✅
13:52:00 <dsc_> dsc's imaginary hurry
13:52:03 <dsc_> thank you!
18:00:31 <selsta> hmm, the unbound update broke gitian / depends build system
18:01:21 <selsta> https://www.irccloud.com/pastebin/U1ZYv7ln/
18:03:48 * moneromooo fetches a homer simpson quote about not bothering next time
18:06:44 <moneromooo> That uses autofools, which checks for the symbol, so it shuld work in theory.
18:07:09 * dsc_ statically compiled monero with the unbound patch and it worked
18:07:15 <moneromooo> Is there a quick way to build just nubound (or mostly it) with depends ?
18:07:42 <moneromooo> (And without vbox, which just doesn't work)
18:08:03 <selsta> TheCharlatan: ^ ?
18:08:12 <moneromooo> Or maybe just hardcode it in configure.
18:08:18 <moneromooo> since we know it's here.
18:09:42 <moneromooo> Oh wait no, that's an openssl api. Crap.
18:10:36 <selsta> depends uses 1.0.2r
18:10:41 <selsta> we can try to update it?
18:10:54 <moneromooo> ew, that's not even using 1.1.x.
18:10:59 <dsc_> 1.0 is deprecated yep
18:11:37 <moneromooo> So my unbound "fix" was actually wrong.
18:12:01 * moneromooo can't be arsed fighting with cmake *again* though
18:14:21 <dsc_> How the $#@$! am I able to compile with openssl 1.1.1g + unbound patch ?? :D
18:14:23 <moneromooo> If it breaks depends, the change is more bad than good.
18:14:29 <moneromooo> Shall I revert it ?
18:14:36 <iDunk> Yes
18:16:25 <moneromooo> 6803
18:16:34 <moneromooo> Sorry :)
18:17:01 -xmr-pr- moneromooo-monero opened pull request #6803: Revert "unbound: update to get build fixes"
18:17:01 -xmr-pr- > https://github.com/monero-project/monero/pull/6803
18:17:22 <selsta> There is also a second issue, mining functional tests returns res.pow_algorithm = "I'm not sure actually" instead of RandomX, could this be related to the CLSAG updates?
18:17:49 <selsta> core_rpc_server.cpp:1310
18:18:10 <dsc_> Oh, so it breaks because depends still uses 1.0?
18:18:19 <moneromooo> No, related to the fork. I guess I can make it assume randomx until further notice.
18:19:47 <selsta> sounds good as we don’t plan to change PoW anyway
19:01:15 <iDunk> x86_64-linux-gnu target builds fine with depends and OpenSSL 1.1.1g.
19:02:11 <moneromooo> With the reverted patch ?
19:02:20 <iDunk> I never pulled that.
19:02:50 <iDunk> What was the problem anyway ?
19:03:17 <selsta> https://travis-ci.com/github/monero-project/monero/builds/182957526
19:03:30 <moneromooo> EVP_MD_CTX_new is an openssl symbol, in 1.1.x but not 1.0.x. And detection seems borked.
19:04:22 <moneromooo> So my patch was to force it to "found". Because for some reason I had this notion it was an unbound symbol, and we had a fixed unbound tree.
19:04:24 <iDunk> depends always used 1.0.2 and EVP_MD_CTX_new detection never caused any problems.
19:05:16 <iDunk> Could it be the underscore in "_EVP_MD_CTX_new" ?
19:05:41 <iDunk> L2545 in selsta's link.
19:05:44 <moneromooo> Never seen this one. Maybe it depends on the openssl version :/
19:06:00 <iDunk> 5379.8
19:06:44 <selsta> https://travis-ci.com/github/monero-project/monero/jobs/381609321#L2545
19:15:32 <iDunk> Right, 1.0.2 doesn't have EVP_MD_CTX_new, 1.1.1 does. Any examples of build failures that prompted the patch ?
19:17:16 <moneromooo> invalid application of 'sizeof' to an incomplete type 'EVP_MD_CTX' (aka 'struct evp_md_ctx_st')
19:17:36 <moneromooo> If you want the context, I don't have it handy.
19:18:57 <moneromooo> Though... I only have openssl 1.1.x here. and I remember seeing this error at some point. So there might be a bit more to it.
19:19:02 <iDunk> And nothing really changed or was there an update to external/unbound to trugger this error ? Or is it that system vs "vendored" unbound thing ?
19:19:19 <selsta> we updated unbound submodule
19:19:45 <iDunk> I don't mean today's update.
19:20:04 <moneromooo> I *think* I saw it when I removed some OS libs to test. I removed unbound (so the in tree one got used).
19:20:09 <selsta> I had the issue because I tried out building with vendored unbound.
19:20:19 <selsta> I usually use system unbound.
19:20:32 <iDunk> I do vice versa.
19:20:37 <iDunk> Hmm
19:20:57 <moneromooo> I guess I'll dig into it some more when I'm done being sick to the gills of build systems.
19:21:55 <moneromooo> Though without gitian, given it's 30 minutes of 100% CPU vbox till I realize it's hopelessly wedged..
19:22:09 * moneromooo stabs vbox with cmake
19:22:36 <iDunk> You don't need gitian to build depends targets.
19:22:59 <iDunk> make -jx depends target=x86_64-linux-gnu
19:23:05 <moneromooo> ty
19:23:09 <iDunk> Yw
19:23:17 * moneromooo adds that line to TODO
19:29:34 <selsta> .merge+ 6803 6804 6798 6800
19:29:35 <xmr-pr> Added