> Yeah I agree with selsta. It makes more to put it in utils. The contrib folder (besides epee) is mostly compatibility, packaging, patches, etc

perfect, thanks! I'll do that tomorrow, I've been outside home this weekend

> Also do you know if these completions work with Bash also?

pretty sure they do not. Separate completion files should be written for Bash and zsh

Has the code been freezed for 0.18 ?

<plazma> what is this

<plazma> eprint.iacr.org/2022/744

<plazma> MoNet: A Fast Payment Channel Network for Scriptless Cryptocurrency Monero

<plazma> is it compatible with seraphis

<nikg83[m]> "Has the code been freezed for 0...." <- waiting on multisig audit

AFAICT, it uses ethereum, so pretty useless.

Is this actively developed?

I2p-zero

Melinda French knows

I finally got a cooling pad for one of the laptops, chance of meltdown is lowered now. lol

lol

.merges

we are making progress with ledger

Btw, OpenAlias still works great. If you have a domain, it's pretty simple.

selsta "we are making progress with ledger" <- This is great news!

Dan[m], check the github repo for i2p-zero i guess

Thanks to all the devs, I hope you are all getting donations for your work,

Time = monero, and the internet isn't free as in the bills,

any way to only mine, on testnet, when the tx pool is not empty/new transactions arrive? Would that be a useful thing for people if it does not exist?

You can mine whenever you're synced logic's a bit more complicated IIRC, but close enough). Whether the pool is empty or not does not matter. When txes arrive, monerod stops mining just for a short time while it verifies. While it *might* be possible to continue mining during that time, it's not worth the work I think.

Oh wait. I see what you're saying.

I guess it could be useful, yes.

There is a "smart mining" thing, which considers a number of configurable conditions before starting mining. You could add "is the pool empty" as another condition.

Though when I need a block, I use the python console and call genereateblocks(address, 1).

(I removed the "doesn't work except if --regtest is passed" check, which is pointless I think)

oh thank you! I think the "smart mining" does it for me. the rpc call `genereateblocks` is also useful, but maybe a `generate [numblocks]` command for monerod would also be useful (like the one bitcoin-cli has)? Or maybe it would be redundant?

I think selsta floated the idea yesterday or the day before to hold a dev meeting today to clear the release situation

but I could not find any formal announcement.

And it's almost the usual time for such a meeting, so ... :)

Hi !

Do we know if there has been any issues with view tags on test net so far?

I can only speak for myself. I tested them quite extensively on monerotech.info and had no problems whatsoever

Also did quite a number of testnet transactions since the fork, to test multisig, also without issues

p2pool testing with view tags went fine too

got em working on ledger on a local testnet, will test against live testnet shortly. ledger will be ready for the fork one way or another

rbrunner: still waiting on the audit

but in general everything should be fine, we have ledger and trezor and multisig isn't a necessity for the HF

jberman: were ledger and Trezor still able to parse txs with view tags before adding support, even if they didn’t utilize the feature ?

While I do not know, I'm certain they can't parse it since there's an extra byte per output they would not expect.

I do think the 16 July date may be a bit optimistic, would probably not be a bad idea to push it back 1-2 weeks

<selsta> "rbrunner: still waiting on the..." <- Yes, unfortunately. The auditors promised me a draft report by last Friday. Haven't heard from them since. Bit surprised they were super responsive up to now.

jeffro256: not sure about Trezor, but it doesn't look like Ledger parses txs. Looks like the wallet software (CLI) does the parsing, but I'll keep testing to confirm maybe I'm missing something

I am only involved in the multisig bits, and have no overview over the rest. What's the status of the other bits of the release? How much work is rebasing all the PRs?

most stuff is already merged, apart from multisig, trezor and ledger

dEBRUYNE: we also need to know when trezor will update their firmware

I've asked already and waiting on an answer currently

<selsta> "but in general everything should..." <- or not fine

or anything in between

<arnuschky[m]> "Yes, unfortunately. The auditors..." <- maybe they are realized that it's another trap; hahahahahaha

> <@arnuschky:matrix.org> Yes, unfortunately. The auditors promised me a draft report by last Friday. Haven't heard from them since. Bit surprised they were super responsive up to now.

* maybe they've realized that it's another trap; hahahahahaha

(rbrunner: "scammer" wasn't directed at you in that reply to erciccione)

<selsta> "we are making progress with..." <- how to track the progress ?

<jberman[m]> "got em working on ledger on a..." <- github.com/j-berman/app-monero, wow

rbrunner: indeed, that's how critical thinking is supposed to work

the patch will be public once tested and then it's up to ledger to test, merge it and publish an update

there is no reason to reject working patch done by others for free, pure benefit for them

<arnuschky[m]> "Yes, unfortunately. The auditors..." <- any upper boundary estimate on date ? and what's the next action in case of failure ?

`+inf, undefined the next action` is acceptable reply too

* `+inf, the next action is undefined` is acceptable reply too

00:01:07 WARN src/pool.c:2053: result not found... (full message at libera.ems.host/_matrix/media/r0/do…18bc68b246581cb30b7827967da05336f8f)

I may be missing something here but I see on xmrguide that the author suggests not using --tx-proxy

However, if all of your peers are onion addresses how does monerod know to use tor to actually reach them if you don't tell it to use tor as a proxy?

Ackermann[m]: who is the author of this website? it does not seem accurate

ok it's guidelines for remote node operators

tobtoht i believe : xmrguide author

i think this is about the end user being protected by tor

not the node operator

you can work around the propagation delays by using `disable_noise`

> <@bularotunda:0wnz.at> 00:01:07 WARN src/pool.c:2053: result not found... (full message at libera.ems.host/_matrix/media/r0/do…6971d3a72b34b21f0c2f0c109330a2ac375)

* redirect it to that pool sw

> <@bularotunda:0wnz.at> 00:01:07 WARN src/pool.c:2053: result not found... (full message at libera.ems.host/_matrix/media/r0/do…f10955cf59df8d4a25dba8a5421ea75cec2)

> <@ooo123ooo1234567[m]:libera.chat> > <@bularotunda:0wnz.at> 00:01:07 WARN src/pool.c:2053: result not found... (full message at libera.ems.host/_matrix/media/r0/do…57ef5a166ae911e281e9b3373ae8ab3bc1f)

wow, are there hex of that block in logs somewhere ?

That's a message by the pool manager that it can't find the "meta" counterpart to a tx that is in the pool

I don't know whether anybody ever researched that "to the bottom" when and how and why that happens

But it happens quite frequently, in comparison, without any visible bad effects

I think it can be so frequent that moneromooo made it "print only once", like the message tells

ooo123ooo1234567[m]: No, thats all my diaries.

monerod banning ips, is that expected?

are you sure that there is nothing in pool logs ?

What do you mean with "pool logs"?

In any case, with "pool manager" I mean that Monero code that manages the tx pool

As used internally by the daemon

> <@bularotunda[m]:libera.chat> > <@ooo123ooo1234567[m]:libera.chat> wow, are there hex of that block in logs somewhere ?

>

> No, thats all my diaries.

what's your pool setup: miners <->single pool <-> single monerod ?

> <@ooo123ooo1234567[m]:libera.chat> > <@bularotunda[m]:libera.chat> > <@ooo123ooo1234567[m]:libera.chat> wow, are there hex of that block in logs somewhere ?... (full message at libera.ems.host/_matrix/media/r0/do…e512108383870b7917e69ddd542c8b6c2b9)

<selsta> "not the node operator" <- Ok thats what I was thinking, thank you

it looks like pool submitted a block with a tx that isn't in txpool of daemon anymore, the next question is how that tx got into block template and how that tx disappeared from txpool ?

You can have that with regular daemon and wallet use, without any mining in play

(all messages about missing tx meta are irrelevant)

I lost a Reward because of this error, Pool reports finding the block, but in my wallet I don't see the reward

It isn't clear yet who is responsible for it

Ah, I see, the message "Transaction not found in pool" is relevant?

rbrunner: wow, good deduction

bularotunda[m]: which monerod version or commit do you run?

selsta, it is also likely unrelated

00:01:07 WARN src/pool.c:2069: Error (-7) with block submission: Block not accepted

2022-06-19 00:01:07.252 E Transaction not found in pool

happens in the same minute as the error in the pool

Very, very unfortunate sequence of events? Somebody finds and publishes the block a tiny bit earlier, bularotunda's daemon receives it juuuust before it can submit itself, and the new blocks takes the tx from the pool

*block, singular

selsta: Monero 'Oxygen Orion' (v0.17.3.2-release)

rbrunner: did you read code ?

> <@bularotunda[m]:libera.chat> 00:01:07 WARN src/pool.c:2069: Error (-7) with block submission: Block not accepted... (full message at libera.ems.host/_matrix/media/r0/do…91e7e03db3e7be92190b3b8929049bd734c)

You think I openly admit here I am just guessing :)

rbrunner: This is the third time this has happened to me. I've recorded it three times.

Ok, there probably goes my theory then

are you sure that you use only 1 pool instance and 1 monerod instance ?

My daemon also keeps blocking other IP is this expected... (full message at libera.ems.host/_matrix/media/r0/do…a391572c9394875106def6cd3dcc3593a78)

those blocks are stupid but it isn't important unless your daemon has 0 connections in result

is it possible that my LMDB database is corrupted?

> <@bularotunda[m]:libera.chat> > <@rbrunner:libera.chat> Very, very unfortunate sequence of events? Somebody finds and publishes the block a tiny bit earlier, bularotunda's daemon receives it juuuust before it can submit itself, and the new blocks takes the tx from the pool

>

> This is the third time this has happened to me. I've recorded it three times.

it would be good to increase verbosity of logs for both pool and daemon to have more info on the next failure

ooo123ooo1234567[m]: Height: 2650040/2650040 (100.0%) on mainnet, not mining, net hash 2.44 GH/s, v14, 130(out)+12(in) connections,

what are the heights for failed blocks ?

<gingeropolous> "Dan (Is not the man & Braxman..." <- I have last release 2020, just wonder cause its recommended either i2p or tor to connect node to wallet.

> <@bularotunda[m]:libera.chat> > <@ooo123ooo1234567[m]:libera.chat> those blocks are stupid but it isn't important unless your daemon has 0 connections in result

>

> Height: 2650040/2650040 (100.0%) on mainnet, not mining, net hash 2.44 GH/s, v14, 130(out)+12(in) connections,

is it possible to see monerod logs +- few hours around failed submit ?

Now is your Bitcoin wallet or coinbase 0.00000 I promise 0.80500 in less than 24 hours without sending money to anyone. Earn 0.764 in 7hours, No referrals, No Ads, No scams. Ask how(me)

Or join t.me/+JdEg2rIn7E0wZDFk

> <@123bob123:matrix.org> I have last release 2020, just wonder cause its recommended either i2p or tor to connect node to wallet.

> github.com/i2p-zero/i2p-zero

#monero:monero.social

Didn’t this get developed my monero developers?

Thought i’d asked here if someone did

it doesn't really matter if you use tor or i2p for rpc traffic, tor will likely be faster

<bularotunda[m]> "is it possible that my LMDB..." <- It's unlikely to have so sophisticated negative side effect due to corrupted db 3 times

> <@bularotunda[m]:libera.chat> > <@ooo123ooo1234567[m]:libera.chat> those blocks are stupid but it isn't important unless your daemon has 0 connections in result

>

> Height: 2650040/2650040 (100.0%) on mainnet, not mining, net hash 2.44 GH/s, v14, 130(out)+12(in) connections,

are there enough resources (bandwidth + cpu) on that machine to handle so many connections ?

Hey everyone,... (full message at libera.ems.host/_matrix/media/r0/do…4839dacb982759d5abef55612783b65c882)

s/tor/xmr/, s/Auto_XMR_Node/Auto\_XMR\_Node/

#monero-community-dev:monero.social

thanks

Monero build errors on OpenBSD pastebin.com/UyA8R1G9

looks like libunbound linker related

<fented> "looks like libunbound linker..." <- was it `make release-static` ?

env DEVELOPER_LOCAL_TOOLS=1 BOOST_ROOT=/usr/local gmake release-static

as indicated in the README for OpenBSD

deps for static build aren't complete, try `gmake release`

ooo123ooo1234567: building without static solved it, thanks for the help, you made my day :)

wow

are there enough enthusiasm to complete static deps ?

:D

s/are/is/