What is the preferred amount of lockable memory to dispel the warning? Is this some established value?

If the goal is to dispel the warning, as much as you can. I don't know the minimum expected amount needed. It depends on usage I think, since it's the number of crypto::secret_key (and possibly other things) in memory at once.

It takes a page per though, which is wasteful. It'd be nice to group many 32 byte keys onto a page.

Most of the time it's not possible, but some cases might, which will reduce the page locked load.

moneromooo: is there some reason not to simply make it unlimited?

The OS won't allow you.

(for good reason, it'd be a DoS vector)

I suppose I'm just looking for some indication as to what a rational level is. 128k, 2G, ...

For some reason the wallet refreshed once, but now throws std::bad_alloc. Blocks received: ####

Locked memory shortage should not cause this. If it does, it can be fixed.

I wonder why in the world the wallet just broke like this

What's the stack trace in the log ?

oh, heh, I sent the log to /dev/null. Let me see about that

oh heavenly, idk what it means

7f881d398a80 INFO logging contrib/epee/src/mlog.cpp:273 New log categories: *:WARNING,net:FATAL,net.http:FATAL,net.ssl:FATAL,net.p2p:FATAL,net.cn:FATAL,global:INFO,verify:FATAL,serialization:FATAL,daemon.rpc.payment:ERROR,stacktrace:INFO,logging:INFO,msgwriter:INFO

It just tells you what logs are active. Run with --log-level 0.

The wallet disabled logs (request for people who're scared of leaving private traces on the filesystem).

from

Error: refresh failed: no connection to daemon. Please make sure daemon is running..

which is nonsense because ./monerod status shows that I am synced

and, the wallet just successfully refreshed 5m ago

moneromooo: closed the terminal and tried in a new terminal seemed to fix (maybe)

Is there a way to stop the cow from locking my wallet. I don't trust him.

set inactivity-timeout 0

Actual name may differ a bit, "set" will list it.

ah, sweet. I must have missed that feature release. Didn't know what to think when the cow showed up on the scene. Might be a mallicious hacker.

Out to milk you. Can't be too cowreful.

oh, that's a good one ^_^ punny

So, that issue resolved itself. Possibly can recreate by opening the wallet, allowing it to lock, and then closing the terminal without reentering password and properly closing the wallet. However, the fix was also close terminals, open a new one, and try again.

"Closing terminal" meaning... kill the terminal window ?

nvm, there's a save and swap files, can't be that.

Yup, I saw the cow and freaked out, closed the window. Then tried in another terminal (which may have been previously open) but kept getting std::bad_alloc

Then closed all windows and tried again. It refreshed again and I was able to close/reopen without issue.

I reckon it had something to do with the previous refresh not being 'completed' somehow when I closed the wallet how I did. Some bad data artifact somewhere.

When cow ascii on CLI release moo?

bigslim[m]: do you not have the cow in your cli?

15.0.5 release?

Should have it, I suspect.

Let me run the hidden command ``moo_moo_mooooooon``

Nope. Not there. Invalid request

That's a real thing?

There are many commands not listed by -help

Is there a live MRL meeting tomorrow? I may join now that I’m WFH

bigslim[m]: Research meeting Wednesdays @ 17:00 UTC ( monero-project/meta #454 )

#monero-research-lab

ErCiccione[m]: Can you explain the reason for *another* migration of the Monero site repo, (now to Github)? When is the next migration planned, and how many more will be in the future?

Is there any information, preferably structured, which repo (and where) remains relevant and which can be ignored?

TheFuzzStone[m]: we tried out gitlab and found that github is better for development

TheFuzzStone: There is no other migration planned. The only change is the monero-site repo moving from gitlab to github. the repo on gitlab is used for mirroring. The CCS repositories are staying on gitlab. The discussion is in this issue: monero-project/meta #236

something that we couldn’t know without testing first

the announcement is here: monero-project/monero-site #929

ErCiccione[m]:

Thanks

no problem :)

selsta: What was the difference?

Hello everyone. How likely is it, that some entity has so many monero nodes all over the world, that they are actually connected to every existing nodes? Thus making it possible to identify the node broadcasting a transaction for the first time, basically linking an IP to a transaction?

Well, they would have to be a peer of the nodes too.

As in, not just connected, but the peer that the transaction is sent to.

Which I guess is all of them

Low, anyway. Either they're using the same server for all of them, and then it would be clear as day in the logs

or they wouldn't, and then they would have to pay obscene amounts of money

but some agencies could easily get, say, 5-10 vps from each country

and since a node seems to connect to (at least) 8 other peers, if they had like, 50% of the nodes, ithink they would have every peer existing

With Dandelion, a node cannot tell even if they're connected to every other node.

may you explain what is dandelion?

A system which protects against this :) I think we don't quite have it yet, there's still a PR left to merge.

aquestion: There's 200 countries in the world, so that's 1000-2000 servers. Is the Monero network that small?

thx for both of your answers btw

i mean

Basically it sends a tx to just one node. So it can send to the adversary, or to a not adversary.

20 countries would be enough

But the adversary cannot know who is the originator then.

20x10vpsx$50 = $10k

well that's be nice

i know bitcoin is adding some sort of batching too

will monero do something like that?

moneromooo: Is dandelion source-routed? And why not just use Tor?

We do batching when syncing historical blocks. We could batch incoming "free" txes too, but the patch got rejected since it adds some latency.

i know about Tor though

but wondering about that

just ghetto Freenet-style routing seems like it could work otherwise

because many users probably dont use tor, if you can link txs by IP you can eliminate many, many decoys from rings

I make a packet, set HTL to a random value between 100 and 50, encrypt it with the key of my neighbor node

Source, yes. I guess because it also works if Tor is blocked. And if all your guard nodes are pwned, you don't get the dandelion protection.

That node decrements HTL by 1 and 10, sends it to a random neighbor

I'm sure there's a lot of talk on this on the net as it was made for bitcoin first.

It would not work if you'd be surrounded by bad nodes, but Better Than Nothing™

Can you explain "if you can link txs by IP you can eliminate many, many decoys from rings" ?

if Tor is blocked then you can just use bridges

give me a second im trying to formulate that properly

if some agency knows TX1 is from user A. And they also know which output is the change, and which one actually went to A. (say, they made the transaction themselves, or the exchange/other party told them).

They look each ring where that output appears. Lets make it easier, say it appears 3 times (TX2 and TX3 as a decoy, and TX4 as the real input).

We then have 6 outputs to watch. (2 from TX2, 2 from TX3, 2 from TX4)

Then they look at these 6 outputs, in which rings they appear.

If the same IP as TX4 broadcasts one of the transaction that has a ring with this output, its likely that one using the real output. The two others were decoys.

Makes sense, sounds like an important benefit from Dandelion++

damn, i hoped i was wrong somewhere and that wasnt an issue

Well, if you know lots of things, you can deduce more.

What's the largest ringsize possible?

Or is there no limit if you're willing to pay the fee?

i thought ring sizes were standardised (or maybe its just a minimum)

Fixed to 11.

(except special cases when spending pre-rct)

Prior to that, it was as much as there are outouts available and the tx does not go past ~150 kB.

I see

aquestion: Nodes cannot reliably determine whether the node that relays the transaction to them is also the node that created the transaction though

This only applies to local nodes

In case of a remote node, the node operator will be able to associate IP with the transaction

dEBRUYNE: Isn't a trivial countermeasure to find a random node to give your txn to, as if you were a full node?

A very ghetto approach is to just say, "whichever nodes would like to, please listen on port 12345 UDP for transactions"

you make sure your txn is <1.5 kb, pick a random 32 bit number, bada bing bada boom

it ain't perfect but it's a million times better than nothing, and fast to implement too

Yes, let's make shitty solutions where one good one exists, just because people want to save 30 GB.

This is instead of the so-far nonexistent anonymity networks.

Also it could be combined with the onion routing, so that it's harder for the entry guard to see your entry point

(It doesn't save 30 GB)

yanmaani: tor isn't nonexistent

no but Kovri is

couldn't get Tor to work when I tried it, and it certainly isn't on by default

I am getting a lot of " peer claims higher version that we think (13 for 2063919 instead of 12) - we may be forked from the network and a software upgrade may be needed"

You can ignore. Some other nodes are claiming this but it's false.

What does it mean?

You think version 12. The other computer says version 13.

So your dameon thinks maybe it's out of date.

I banned the two ips that claimed that, and now it is much better.

But version 12/13 of what?

Of the monero protocol.

It went fast from 0% till 63%, slow fom 63 till 98%, and now it is very slow. Is this normal?

Yes.

If you have a spinning disk, it'll be even slower (by a lot).

Got a Samsung nvme

Why does it slow down the closer it is to finish?

More usage, verifies PoW, verifies more tx data.

Also slower tx constructions to verify.

What is PoW?

proof of work

(=mining)

Proof of work. A system allowing distributed consensus among untrusted parties.

(eventual consensus)

I see, thanks.

How long does it take to get a amount that I can send to another wallet if I enable setup-background-mining? I am just testing monero.

visualshock, between 1-10000 days

On mainnet, probably a long time. Like a year or more.

It's basically a lottery.

To test, run with --testnet. You'll get monero a LOT sooner.

Oh, that long.

1.7 monero a block, so at, er... $50 ? That's like $80. $80 every year or two, depending on your hash rate.

So I can only get a whole block?

Yes. You try to get every block. First miner to find it gets the block reward.

yes, but you can mine in a pool if you want more predictable rewards

Solo mining, background mining = lottery. Pool = wage slave.

Both have about the same expected value in the long term.

Modulo decreasing block reward, pool fee, pool exit scam, that kind of thing.

Solo is also more private. We like privacy generally.

after 2 long years of hard mining, i finally neared the minimum payout threshold. and then the pool exit scammed and took it all away :'(

What's the point of a pool if you gotta wait 2 years...

What pool was that ?

oh i was just making that up. the only exit scamming monero pool i can think of (so far) is fasthash, and it only lasted a couple of weeks

Well, there's minergate which apparently claims you sent less hash than you did, and dwarfpool who scammed the ffs years ago (admittedly not a pool scam, just owned by the scammer).

it seems like there's a ~30% chance they decide to not credit a share :(

Isn't minergate part of the cryptonote scam network? Those guys are persistent

with hitbtc and friends

we need p2pool for monero...

Does it support coinbase to multiple addresses?

It's technically possible, idk how much effort would be needed to implement. Afaik _all_ coinbase tx have historically been 1-output

One way would be to make it so that coinbase delays kick in slower.

with a delay of one block

so instead of coinbase going to addr X and being stuck there for a day, if it's spent in the same block as it's created, then the delay kicks in after the first transaction

well the delay is 2hr

for p2pool systems to work, the delay must be 0 :/

It supports any number of coinbase outputs. Pre-rct, you typically had 8-ish outputs.

so a p2pool system would be possible?

I don't see why not.

But then I've not done it.

short of good mempool sync, the only requirement is for coinbase outputs to be able to send to multiple addresses

like, a few thousand preferably

Coinbase outputs are very small. A few thousands is fine.

seems like it's just mempool sync stopping the project from good decentralization then

I don't think it needs that (though I did not think much about your objection from yesterday, so it might be valid).

my objection isn't a super big deal. But if the mempool isn't sync, then it will just be logistical hell

if there are to be new blocks every 30s, and it takes more than 30s to move the transactions around, then it will just be chaos

iirc jtgrassie looked deep into p2pool for monero, and didn't have a positive conclusion

UkoeHB_: The Brit?

in the video?

Right, yes, Jethro Grassie. Yeah, his problem was that the mempool wasn't synced.

So the blocks were big

and RIP goes the consensus

mempool sync doesnt seem solvable

Why not? You just have to make sure that the transactions are sent rapidly.

What needs to happen for a wallet to connect to a node, hosted on a different device, on the same network. RPC port should be passed through and wallet should use --daemon-address=IP:Port no?

Does the daemon need to bind something?

I had a suggestion for this in #bitcoin-wizards a long time ago. Basically, you send transactions to everyone unprompted

wizardsmoke: `--rpc-bind-ip 0.0.0.0 --confirm-external-bind` on daemon to make it listen on all interfaces i think

And assuming transaction/block origin is geographically distributed, the local maxima will be to have a geographically dispersed set of 'friends'

Then, miners could just delay adding transactions into blocks for a few seconds to stay on the safe side and prevent being orphaned.

wizardsmoke: AFAIK --confirm-external-bind is only for binding to a non-localhost IP which is something you don’t want

I took that line out and just added --rpc-bind-ip 0.0.0.0 but now I'm getting `Error: Couldn't connect to daemon: 127.0.0.1:18081`

what is the exact command?

in your wallet you'll need to add --daemon-address 192.168.x.x:18081

I added rpc-bind-ip=0.0.0.0 to my config on the daemon, then restarted it and tried monerod status (on the server) but the server gave that error. Commenting rpc-bind-ip and restarting recovered it.

I haven't even tried on the remote client yet

can you post the exact command?

yanmaani: how is that different from what is normally done? idk much about tx dispersion

UkoeHB_: Usually you only send upon request

So the flow goes like

1) Hey, I have txn

2) OK, send it

3) Here you go

selsta: monerod status or do you mean for the daemon? the daemon is `./path/to/monerod --config-file /path/to/conf/file --detach --pid ...`

So if we have 3 nodes, A, B, and C, with 100ms one-way latency between A/B and C/D, then the delay comes to 900ms A <-> C.

wizardsmoke: and you put the rpc-bind-ip stuff in the config file?

Yeap, and that broke it even on the host device

Didn't bother to try the client after that didn't work

okay, can you check what your local ip?

i have it

can you bind it to the local ip?

not 127.0.0.1 and not 0.0.0.0

Sure, I can try that

Error: Couldn't connect to daemon: 127.0.0.1:18081

That's from trying monerod status on the server device

can you try monerod --rpc-bind-ip local-ip status

Error: Couldn't connect to daemon: local-ip:18081

I see what you mean yanmaani, is there some design reason for that flow vs pure broadcasting?

wizardsmoke: can you try adding --confirm-external-bind

sure thing

UkoeHB_: Well it wastes insane amounts of b/w

If you do it by just sending them on request, it's pretty much linear to the amount of nodes

selsta: in that case restarting the daemon fails

If you do it by sending them automatically, then you'll send it far more - each node would in expectation get 1 copy from each friend

hmm I’m sure it is quite easy to do but I’ve only made my daemon available on localhost or externally reachable

with 20 friends, that's 20x bw

maybe someone else can help you

The error it threw was --rpc-bind-ip permits inbound unencrypted external connections. Consider SSH tunnel or SSL proxy instead. Override with --confirm-external-bind

should my config be like confir-external-bind=1?

try it out

seems like it didn’t add the option properly

yeah, that got it to run actually

I'll try connecting now

Sweet, looking good. I changed the bind to 0.0.0.0 and I've got it now with both `monerod --rpc-bind-ip local-ip status` and `monerod status. Now, hopefully, the wallet will see it, too.

wizardsmoke: but make sure that it isn’t externally reachable

outside of your local network

oh, that's hot

I set the firewall to only pass through 18081 to the LAN. I will try different ways to get at it

er, to only allow in traffic on 18081 from the LAN, rather

Ideally, I'd like to bind only to the LAN IP and localhost, but I'm not sure its possible to have two binds

Does the cli also start the rpc?

visualshock, there are separate binaries for cli and rpc

if you're talking about the wallet

jwinterm, yes

Oh, weird, what is the difference

one starts the cli wallet the other starts the rpc wallet

The rpc closes when I try to open it, only the cli stays open

cli you interact with from your terminal, rpc you interact with over the network interface

you may need to launch it with some command line options

Not sure that makes it any clearer to me. Can't I connect to RPC with monero-wallet-cli --daemon-address ip:port

like wallet-file, password, etc

no daemon-address tells the wallet what the rpc interface for the daemon is

the wallet interacts with the daemon via rpc

you can interact with the dameon by terminal or rpc

you can only interact with cli wallet via terminal, and you can interact with rpc wallet only via rpc

How is the rpc wallet different from the cli wallet?

Now I don't even know what wallet I'm using or if it was necessary to open RPC port to get chain info from daemon

./monero-wallet-cli = cli wallet

cli wallet communicates with daemon over rpc, that’s why you had to open RPC port

rpc wallet is more for programmers

So monerod also starts the rpc?

monerod uses rpc for communication with the cli wallet (en.wikipedia.org/wiki/Remote_procedure_call)

monerod does not start monero-wallet-rpc

What is an example where I'd use monero-wallet-rpc

When your code wants to interact with your wallet

so its something I'd use programmatically to pass one RPC at a time?

like get_balance or whatevr

thanks'

Somebody can give me monero testnet ? many faucet doesn't work

wizardsmoke, you basically only would use rpc wallet if you're running a service with a lot of users and you're automating wallet interaction

like an exchange or something

jwinterm: maybe I aspire to own tradeogre one day

I am using it for a project I am slowly working on

btw is there a realtime api for rpc ? There was a thing in dev

the commands are all basically exactly the same as cli wallet, just made from another program

Freneticks, I think there was plans to put in like push notification type things, but don't think it was ever added

not sure tho

jwinterm: because log show when incoming money are received

i thing there was a rabbitmq thing not sure where it is

is this related? monero-project/monero #6418

zeromq I thought, but yea

ohyea, maybe it's finally coming selsta

jtgrassie: In your self-select pool implementation, is there any disincentive to making empty blocks, or charging fees out-of-band?

from what I can see, share_t is only height, difficulty, address, and timestamp

on lines ~680 in pool.c, it seems like you use the total fees in the found block when paying out, no?

with wownero there's no limit to what kind of wealth we may achieve

What is the difference between wallet and account?

one wallet can contain multiple accounts

So my wallet currently has 1 account?

are you using the CLI?

yes

yes, you can create a new account with account new

every account has their own balance

and history

every account has its own seed?

no

I still don't get how accounts work :-( So a seed can generate multiple main (4...) public addresses, and each main address can generate multiple subaddresses (8....)?

Yeah, sort of like how derive paths in Bitcoin work

midipoet: subaddresses have two indices (major, minor)

subaddress(0,0) = 4... main public address

all other subaddresses start with 8

the major index are accounts, the minor address are subaddresses

so 1 wallet (1 seed) can have multiple accounts with multiple subaddresses in them

not sure if that is more clear lol

monerodocs.org/public-address/subaddress is a good read and also explains accounts in more detail

ic

thanks selsta

what this line do at basic.h "if (std::is_same<Archive<W>, binary_archive<W>>())"