There's a vm for the current height's seed, and one used for others.

So if you send blocks alternating between two epochs that don't include the current top, it should thrash.

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`

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,

128, 128, 128, 128, 104 ... ]?

If yo umean

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.

Heh. I checked, I'm wrong. It's actually varint, but the nonce field adds a check it does not go beyond 255...

The values in extra are bytes. So you would not see 1000.

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.

It'd be 128, 72, assuming thar's the correct representation.

ahh thx

moneromooo: Thanks for the info :)

where can you request testnet monero, is there a faucet or something?

bonedaddy: community.xmr.to/faucet/testnet

thanks

:)

are there any public testnet monerod nodes I can connect monero-wallet-rpc to? i dont have enough disk space to download the testnet

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 :)

yea makes sense it can be hard to keep a testnet running

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?

Not sure, but somehow sounds like it.

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-

Testnet is doing fine. Net hashrate 4.5 KH/s :)

Yeah, mining is no problem, somebody provides that hashrate, all good. But the number of active and reachable servers is pretty miserable right now.

Ah, better now than early this morning UTC, I have now 10 connections, 5 in and 5 out. Almost usable :)

[2020-09-06 09:24:21.150] net new job from localhost:8000 diff 95411 algo rx/0 height 1545861

[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

dsc_: merged

now someone just needs to update the submodule

fluffypony: thanks, 6802 now pulls it into monero.

thxxx

.merge+ I dont really have permission to add merges but ill add 6802 anyway

.merges

damn :|

.merge+ test #6802 test

I guess that voice permission thing works fine again.

.merge+ looks like dsc_ can't add -6802-

Added

.merges

:>

I was able to cross-compile this i.imgur.com/9wUshar.jpg using mxe.cc

Next up: libwallet + Qt

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

Wrong channel.

Snipa: Pretty please merge #6802 :) ?

I'll merge it if there's urgency

done

and doing 6111 as well

done ✅

dsc's imaginary hurry

thank you!

hmm, the unbound update broke gitian / depends build system

That uses autofools, which checks for the symbol, so it shuld work in theory.

Is there a quick way to build just nubound (or mostly it) with depends ?

(And without vbox, which just doesn't work)

TheCharlatan: ^ ?

Or maybe just hardcode it in configure.

since we know it's here.

Oh wait no, that's an openssl api. Crap.

depends uses 1.0.2r

we can try to update it?

ew, that's not even using 1.1.x.

1.0 is deprecated yep

So my unbound "fix" was actually wrong.

How the $#@$! am I able to compile with openssl 1.1.1g + unbound patch ?? :D

If it breaks depends, the change is more bad than good.

Shall I revert it ?

Yes

6803

Sorry :)

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?

core_rpc_server.cpp:1310

Oh, so it breaks because depends still uses 1.0?

No, related to the fork. I guess I can make it assume randomx until further notice.

sounds good as we don’t plan to change PoW anyway

x86_64-linux-gnu target builds fine with depends and OpenSSL 1.1.1g.

With the reverted patch ?

I never pulled that.

What was the problem anyway ?

EVP_MD_CTX_new is an openssl symbol, in 1.1.x but not 1.0.x. And detection seems borked.

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.

depends always used 1.0.2 and EVP_MD_CTX_new detection never caused any problems.

Could it be the underscore in "_EVP_MD_CTX_new" ?

L2545 in selsta's link.

Never seen this one. Maybe it depends on the openssl version :/

5379.8

Right, 1.0.2 doesn't have EVP_MD_CTX_new, 1.1.1 does. Any examples of build failures that prompted the patch ?

invalid application of 'sizeof' to an incomplete type 'EVP_MD_CTX' (aka 'struct evp_md_ctx_st')

If you want the context, I don't have it handy.

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.

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 ?

we updated unbound submodule

I don't mean today's update.

I *think* I saw it when I removed some OS libs to test. I removed unbound (so the in tree one got used).

I had the issue because I tried out building with vendored unbound.

I usually use system unbound.

I do vice versa.

Hmm

I guess I'll dig into it some more when I'm done being sick to the gills of build systems.

Though without gitian, given it's 30 minutes of 100% CPU vbox till I realize it's hopelessly wedged..

You don't need gitian to build depends targets.

make -jx depends target=x86_64-linux-gnu

ty

Yw

.merge+ 6803 6804 6798 6800

Added