Please help me. I have withdrawn XMR From binance to my gui wallet but still it has not come please help

MohammedMujahid[: monero.stackexchange.com/questions/…nsaction-to-in-the-gui-zero-balance

Interesting view on testnet: Somebody tries out big transactions :) testnet.xmrchain.com

<rbrunner> "Interesting view on testnet..." <- 3TX per block 😅

They could've made bigger transaction with this simple wallet2.cpp change...

Stress tests always welcome, I guess

Can they do the same on mainnet?

Similar tactic was used on mainnet not too long ago, could be prep for another "attack" or just someone playing around.

Yesterday was difficulty adjustement day, because mining went from about 8 kH/s to about 2 kH/s, and difficulty still has not yet fully adjusted

In all honesty, we may want to examine maximum tx size. Having only 3 tx in a block may be a problem for decoy selection, not to mention verification times

Lol. Professional hazard: Immediately seeing statistical problems everywhere :)

(Just joking)

That's...why I'm here ;)

Rucknium[m]: This isn't the max, it would adjust over time.

Is this node safe opennode.xmr-tw.org:18089

Oh, you mean limiting TX size further

Is there any relistic scenario in which a user might need a tx with 194 inputs?

sethsimmons: Right. Maybe we should consider its implications.

merope: Yes, sweeping p2pool payouts.

Can speak from experience 🙃

Hmmm, didn't think of that

But frankly they could do that with a series of smaller txs.

Obviously that could be broken up into more transactions, but that's not uncommon for those mining p2pool with smaller hashrates.

I already had to split out into multiple transactions...

Those are coinbase transactions though, so they could be treated as an exception? (Assuming they're not already)

merope: Hmm, that would be an interesting exception.

Do we already have some statistics on tx count vs input number? Perhaps we could introduce a 50-100 input limit per transaction

On Townforge, there is still a limit to the number of coinbase outputs that can be consolidated. It might not be a number limit; maybe a total tx size limit.

"Yesterday was difficulty adjustement day, because mining went from about 8 kH/s to about 2 kH/s" that's the answer. Someone was mining on testnet for a long time and is now consolidating

merope: neptune could help with that.

That way if a pool or an exchange need to consolidate lots of input they still can, while leaving some room in the block for more transactions

I mean I could help with that too. What stats do you want, exactly?

I think a simple histogram of the number of inputs per transaction would suffice (not sure what to choose as a starting point for the window)

It's discrete, so we can just have a table.

What time period? Between which block heights would you want?

Sorry, my stats language is a bit poor xD

Perhaps since block 2210000? The advent of CLSAG

Ok. Coming right up...

Or maybe 2210720, to exclude the last mlsag stragglers

neptune 's database stops in Sept I think, since it was last built to examine the summer tx volume anomaly.

That would mean ~11 months worth of transactions - should be rappresentative enough, right?

There are 5 txs with 1245 inputs. More stats incoming...

woah, that's massive

That seems like it may be the max. Here's what the bottom of the table looks like

973 1

1047 1

1243 1

1245 5

I can try to track down the hash of one of those txs....

Check out block 2006386. There's two 1245in txs, plus coinbase, and that's it. Actually that was before your time window. One sec..

ec646bdcfa905358209abd486de4fbabfe50cb1e83f8375058a3f7a69650a1f5

^ Not RingCT, though

Yeah, neither are the two from block 2006386

29eb6e840f9b41a0f659b43b0dcad36f368d2b021109f3e31e15d33f8aceae47

^ Another non-RingCT 🤔

I checked all 5 of those 1245in txs, and none of them are RingCT

The 5 that are in the >= 2210720 block height time window, that is

Aside from these few massive ones, what's the distribution like for the others? For instance, how many transactions have more than 100 inputs relative to the total?

Should I exclude RingCT txs to answer your question?

I mean NON-RingCT txs

Hmmm... I say let's include them: there might still be some old pre-ringct outputs that might need conversion, so we could still see some massive txes like that in the future. If there's a significant portion of transactions like that, it might justify a higher input limit

This analysis is being conducted on gingeropolous 's server, by the way. Thanks, gingeropolous !

Rucknium[m]: try table "tx_attribute_2489999", each row is a transaction, there is a column "tx_n_inputs" for number of inputs, and it goes up to block 2489999.

neptune: Thanks! All columns or no?

Ok, I will load all the columns. R shall eat zee RAM.

Rucknium[m]: all columns for what? if they're not part of your histogram I wouldn't SELECT them

Too late.

endor00: See

In moneromooo 's Pay for RPC system it costs COST_PER_BLOCK = 0.05 to fetch a single block from the daemon over RPC, but 10 times more COST_PER_TX = 0.5 to get a single tx

For the per-tx cost it does not matter whether it comes from the blockchain or the pool

As `wallet2` gets most of the txs currently in the pool at every refresh, that must get terribly expensive

Any idea why fetching txs should be so expensive in Pay for RPC?

(I am aware that it's hardly used, if at all, but I don't want to be the one to break it with changes I currently do connected with fetching of pool txs.)

from what i remember, the cost is proportional to the actual computational resources used to perform the actions

Yes, that's also my understanding of the situation, and that's why I wonder: I claim it's nowhere 10 times more resource-intensive to get a tx from the blockchain than a full block

And imagine the wallet syncing, needing one block, and seeing 100 tx in the pool: Cost is 0.05 for the block and 50 to fetch those pool txs ...

Maybe I will initiate the greatest cost reduction in the history of Monero: Fetching txs over RPC ten times cheaper now :)

Is there a way to measure (more or less accurately) the actual resources consumed by each request? (cpu cycles, ram, i/o, whatever)

Hmmm, I guess there must be. But I imagine that's not simple, e.g. because so much is happening at the same time, within multiple threads within the daemon

from my experience, messuring memory while running is a real pain in the ass...

The current costs look like guestimates, but as moneromooo almost always delivers solid work I am pretty sure there is an "idea" behind txs being expensive.

Maybe they will chime in later, taking a break from Townforge ...

So what are we waiting on for scheduling 0.18 HF? Would it be best if I start up a new meta issue to finalize discussion of the key items?

That sounds fine. It seems that no one(s) have taken the initiative to determine scheduling, so you could take such initiative :)

March?

I don't have much free time but will try to hash out some details in an issue we can use moving forward.

ANd yes, I think an early-Spring HF is ideal.

What are the main features being included outside of ring size increase and view tags? ANything else worth mentioning? Was there a decoy selection change from jberman?

Yeah, maybe their "simple binning" wallet-side is so good that we want that in

That was jberman, right? Not sure

Seth For Privacy: Keep in mind that, generally, changes to the decoy selection algorithm do not require a hard fork since it is a wallet-level feature.

BP+?

Binning has not yet been vetted by a statistician.

IIRC there was something specifically that would be best done as part of a HF.

Lyza: Yes, thanks

And fee changes

yeah decoy selection via wallet doesn't need to be doned via HF but there was concern about having people using different selection algos

fee changes very important ya

Seth For Privacy: It's true that bundling decoy selection changes with hard forks can be useful since a HF is a forced upgrade.

UkoeHB 's more robust multisig wallet construction, and some other PR still on the way to prevent an attack, as per Wednesday's MRL meeting

Does that require HF or will that be part of a point release/

Not sure, but seems to me the best time to put something like that into service is a HF, like for decoy selection changes

Maybe there are smaller things that only went into master so far, but not the 0.17 release branch. Don't have an overview, selsta may know more. Maybe more like improvements and optimizations

ArticMine suggested that the ring size increase be leveraged to gather additional statistical information for OSPEAD development. I agreed, so as of now about 1/3 to 1/4 of the tail end of OSPEAD work will take place after the HF.

Please let me know if I missed anything, and we can start using that as a reference while planning.

Friendly reminder that we have a release checklist, but it could probably use some updates/more review: github.com/monero-project/monero/bl…ob/master/docs/RELEASE_CHECKLIST.md

We can use that for the v0.18 release that enforces v15 hard-fork.

> <@rucknium:monero.social> endor00: See

> github.com/Rucknium/misc-research/b…stats/height-2210720-to-2489999.csv

Thanks!

Looking at the cumulative frequencies, I'd say that limiting transactions to 100 inputs should be fine

It covers (almost) 99.9% of all transactions within our sample

merope: Sad p2pool miner noises

And almost all of the ones excluded are the few thousands of 185-194 inputs

looking at more recent data would give a better accounting of p2pool users

monerobull[m]: Actually, now that I think about it, p2pool would not be affected at all. We're talking about inputs here, not outputs

yeah but p2pool miners often have many outputs to consolidate

"Many" - more than 100?

And even if so, it would take at most a couple of transactions to do that

Well we're not going to get big players to join p2pool if sending coins to a private wallet becomes a full-time job

I needed to send 3 separate transactions to get 10$ worth of xmr out of my mining wallet

p2pool pays out every block and there's a block ever 2 minutes if you're 1/3 of the hashrate that's 240 outputs per day

How many inputs did those have in total?

Monero's Algo kinda makes it pointless to mine for 99% of users

And botnets amplify this

nero-cultist[m]: That has nothing to do with the algo, nor the discussion at hand

Sure maybe the 1% of users with a Ryzen CPU can enjoy it

Saying "we shouldn't care about miners" is not really helpful

...

Okay what ever

Continue without my complaints

could we do something to make consolidating coinbase outputs more efficient?

compared to normal TX

monerobull: Let's write a little script to do multiple consolidation txs

monerobull[m]: Never said that - I'm asking you to quantify how many inputs did you have to consolidate, to get a better idea of the issue at hand

Huge txs may be a threat to user privacy due to decoy selection issues

That was the whole point of getting tx data in the first place - see how many transactions would be affected by a given input limit

merope: I had like 200 incoming transactions after mining for a month and i am a thousand times smaller than the big miners

what is the first spend of a coinbase TX just didn't use ring sigs. the amount and stuff is already transparent right? so the first spend of a coinbase TX become a sort of blinding TX then you use it normally afterwards

what if*

Doesnt p2pool send out payments the block after a block is found?

nah it pays out in the coinbase tx

splits the coinbase reward into a bunch of outputs

Lyza: That doesn't address the decoy selection issues. The decoy selection issue is that when there are huge txs, they can fill up the whole block, which drastically reduces the number of decoy outputs that can be pulled from that block

No, in the block you find.

Yeah

<Rucknium[m]> would the transactions not be much smaller without ring sigs attached?

Rucknium[m]: Feather already automates sending multiple TXs if the coins being swept are too large for one.

Max seems to be ~194 inputs for whatever reason.

Lyza: Yes

Lyza: I don't think coinbase txs have any ring sigs.

Aren't coinbase tx amounts transparent?

I'm suggesting to take away ring sigs from transactions that use only coinbase outputs as inputs

yes they are

This is getting too technical for me. Just wanted to make a point how restrictions like these can really harm the project in the future through ways one might not even think about

They still use rings, sgp_ has suggested for a while not using rings for coinbase outputs, or using only coinbase outputs in coinbases rings.

monerobull: so with an 100 input limit, it would take you 2 transactions to consolidate all your mining inputs

sethsimmons: That would make especial sense with p2pool use rising.

merope: I get like 1 share every two days if in lucky

But the big guys who get like 10 or more shares per 12 minute interval would need many, many transactions

As long as the wallet software can automatically handle splitting 100s of outputs into multiple TXs, the limit doesn't really matter TBH.

Feather already does this, not sure on GUI/CLI.

Those big guys should write a script. This may be a user privacy issue, which should take priority over miner UX issues.

The guy didn't even tell me what the problem was

Lets move this convo to #monero-research-lounge:monero.social, though, not really dev related.

Or, as Seth indicates, use a wallet like Feather.

Rucknium[m]: Youre not going to get p2pool adoption if it's way easier to just stay in centralized pools

<Rucknium[m]> "That would make especial sense..." <- in what way is this especially necessary with p2pool use rising?

sgp_: More small coinbase payouts

Rucknium: number of coinbase outputs are consistent though. p2pool miners and pool miners alike get C+1 outputs though

sethsimmons maximum of 194 inputs comes from wallet2.cpp tx size limitation, it can be changed in the code

not a part of consensus

sgp_: Looks like I'm wrong, then. What is C+1?

max transaction size that monerod will accept is 1,000,000 bytes

1 sec let me look more closely

sech1: What is the max tx size enforced by consensus?

1e6 bytes

#define CRYPTONOTE_MAX_TX_SIZE 1000000

sech1: Current max block size?

300kb

so it won't be mined even if it's in mempool

until blocks increase in size

To me, this is a privacy problem since decoy selection needs recent outputs to include in rings as decoys.

If blocks are full of just a few huge txs, decoy selection will be off kilter

And we saw this happen a month or two ago when we saw low-resource nodes struggling to keep up with those blocks that had a few huge txs. Seth For Privacy and others were reporting on it.

few huge or many small shouldn't be particularly different for low resource nodes

Did we ever get to the bottom of why nodes were struggling with those txs?

Maybe the threadpool in `verRctNonSemanticsSimple()` got too slammed.

is this accurate?

sgp_: Looks correct to me.

given that as correct, there's no incremental concern with coinbase outputs with p2pool

if anything, it makes the selection of C+1 outputs more convincing as decoys

Can we get back to talking about random x?

There's a chip shortage making buying random x hardware near ASIC territory

2 mobos

2 high end cpus

It's nearly profitable or viable for people trying to support the network at a loss

What could be the cause ?

Botnets ?

The Algo it's self preferring new cpus from a specific manufacturer

?

mining is supposed to be a boring commodity, especially when CPUs can be spun up or turned off on a whim

Not the room for that, use #monero-pow:monero.social.

yeah

Or #monero:monero.social.

??????

I'm suggesting a change to the developers

when you have a specific change you can suggest it here, the current discussion is just about mining

What change exactly?

A bottle neck for CPUs especially older ones is the cache

A new algo that fits his needs 🙃

sethsimmons: I have access to a Ryzen CPU

??????????

Go to one of the rooms mentioned, please.

Our coin isn't infallible you know.

This convo has nothing do with active development or any specific proposal.

....

Seth is right, start there and come back when you have a specific spec change or something

I did

We will gladly discuss it elsewhere, stop cluttering this room please 🙂

A scratch pad size change.

Along with reductions to cache usage

Think like randomwow

take it to #monero-pow or #monero

Kk

thanks

luigi1111w has the power, I guess 😀

endor00: I think we should make a GitHub issue exploring a reduction in the max input number and/or tx size. I'm not sure if its better as a /Monero issue or or /MRL issue

MRL, I would imagine, as it needs further research and reasoning.

luigi1112> few huge or many small shouldn't be particularly different for low resource nodes <<>> yet it does

*is

Yes, it crashed one of my nodes and ate 100% CPU and 100% RAM on the other till processed when we had the flood of large TXs.

I believe the issue was fixed since, though, selsta would know.

"Yes, it crashed one of my nodes and ate 100% CPU and 100% RAM on the other till processed when we had the flood of large TXs." there is 100MB limit for packet size

max number of connections of in/out connections should be chosen properly in order to have enough memory in the worst case (100MB * 2 * (in + out) + ... < RAM)

it's stupid to touch (limit number of in/out) consensus where it can be solved with better code without any hf

wfaressuissia[m]: Better code doesn't solve the potential privacy issue.

your reply isn't concrete, what do you mean ?

If consecutive blocks are filled with a few large transactions, that could mess up how the decoy selection algorithm is supposed to protect privacy.

<wfaressuissia[m]> "max number of connections of in..." <- is this done automatically, or still need to be done?

Since there will be few outputs to choose from in recent blocks

"is this done automatically, or still need to be done?" number of out peers is fixed by default, number of in peers is unlimited by default. These connection limits should be set manually by user

Would anyone here be able to run a meeting around HF planning? monero-project/meta #630

Meetings are tricky for me with day job, so would be best if someone else could.

There are many other problems in monerod that can't be mitigated with more resources dedicated to monerod. It requires almost complete rewrite with another design

Current p2p network is working only due to ~5 large mining pools that are being operated by humans 24/7

If someone want to remove big mining pools then firstly write software properly so that in can work automatically without human in the loop

"If consecutive blocks are filled with a few large transactions, that could mess up how the decoy selection algorithm is supposed to protect privacy." it's problem with implementation of decoy selection

general purpose implementation should work with any number of txs per block

No, because decoy selection is based on economic behavior. We shouldn't try to bend decoy selection around a "features" that a tiny, tiny proportion of users use.

Decoy selection is critical for user privacy. User privacy is Monero's #1 feature.

"We shouldn't try to bend decoy selection around a "features" that a tiny, tiny proportion of users use." proof

wfaressuissia[m]: I produced proof a mere 4 hours ago:

Don't we often get empty blocks with no transactions anyways?

So "big transaction mean fewer transactions" is part of a broader problem with decoy selection

carrington[m]: I don't think so. I could check though.

Although I agree there should be some sensible limit on transaction size. P2pool does seem to complicate things

If I understood the conversation earlier, max tx size is now three times larger than max block size.

effective tx size is 1/3 blocksize

empty blocks can happen when blocks are a few seconds apart

<sech1> "#define CRYPTONOTE_MAX_TX_SIZE 1..." <- Yes, this is 1/3 current median block size limit

You can see this from the recent testnet blocks with only 3 TX + coinbase in them.

it's not 1/3

Oh, oops my mistake, that is 1/3 and not 3/1.

it's 1 million bytes

Which equates to ~1/3 right now?

I know it's not coded as 1/3

no

Oh

I misread

300KB blocks size limit, actual block can be up to 2x300KB with reward penalty, txs size limit is 1MB

tx size limit is calculated as (block_size_limit / 2 - 600) * 2/3

in wallet2.cpp

which equates 99600 bytes currently

that is just a wallet barrier, not consensus

consensus is 1,000,000 bytes

Ahhh

the limit in wallet2 is soft - it can add more inputs above 99,600 bytes to pay fees

Got it

UkoeHB: Yes, that's what I am concerned about. What if someone spams huge txs and mines them, or can just broadcast them and nodes accept them.

<rucknium[m]> "No, because decoy selection is..." <- What's the difference if in both cases (number of inputs * number of txs) will remain constant and will leak the same information ? Also single aggregate tx is cheaper and smaller ?

So with "official" clients max is `(block_size_limit / 2 - 600) * 2/3`, but consensus will allow up to 1,000,000 bytes.

Got it.

And the current limit equates to ~100kb ATM.

rucknium[m]: it isn't spam, it's expected behaviour

wfaressuissia[m]: Why do you have to be so contrarian all the time? I don't get it. Yes, we had an apparent spam incident earlier this year. It was with small txs though.

"Yes, we had an apparent spam incident earlier this year. It was with small txs though." it isn't spam, it's allowed behaviour by code therefore it should be expected

that's more of a philosophical dispute

This system in the end should allow to do cheap private txs. if you are fighting with spam then increase fee so that no one will do txs and report that privacy is perfect now

I believe that the original definition of technological spam was in email, where the email systems technically allowed it but it was harmful to its operation. So, yes, spam.

wfaressuissia: large transactions are a bit more useful to a passive observer, who knows that one member in each ring is from the same person. If the large tx is split, then the observer only knows there are clumps of inputs, but there might be multiple tx authors.

wfaressuissia: large transactions are a bit more useful to a passive observer, who knows that one member in each ring is from the same person. If the large tx is split, then the observer only knows there are clumps of inputs, but there might be multiple tx authors. (bridge is depressingly unreliable)

solid 5 minutes to show up, nice

However, if you make more tx without churning, to further combine small tx, then graph analysis will make up at least part of the difference.

Sudden peak of txs vs sudden 1 huge tx, what's the difference ?

koe000[m]: are you writing via #monero-dev:libera.chat or via matrix room ?

wfaressuissia[m]: Other transactions can get in those blocks. With huge txs, those other txs are pushed out and cannot be used as decoys from those blocks.

There is a non-zero margin of plausible deniability added with small tx. My koe000 account is in the matrix room, my UkoeHB account is in libera.chat.

All txs are owned by the same entity, that means all of them can be revealed to public

wfaressuissia[m]: What proportion of view keys are publicly available at the moment?

I didn't count

not to be like a squeaky wheel but, if the only use case we have for large numbers of inputs is significant #s people consolidating coinbase outputs due to p2pool, why not make an exception specifically for those outputs? they are identifiable, they could be constructed without rings and be a ton smaller, I think without harming privacy

seems like if you're consolidating a bunch of coinbase outputs it's going to be obvious and the rings aren't actually obscuring anything anyway

"... I think without harming privacy ..." proof

it's a suggestion for consideration; I don't have proof except for what I already said, that it seems like the consolidation would already be obvious. and anyway you can always send to yourself again after consolidating

Lyza: you would just be making it easier for people to distinguish p2pool consolidations instead of forcing them to guess

yes on the basis that guessing is already trivial, which Idk is maybe an incorrect assumption

you got 100+ inputs and every single ring contains a coinbase output in it, I mean.... that seems unlikely to be random chance

unless coinbase outputs become a large proportion of all outputs I guess

Lyza: Which is not great for user privacy.

"that it seems like the consolidation would already be obvious", proofs please

due to random chance there has probably been many transactions which look like consolidations which are not, if you were to make a special class of transaction for consolidation any regular transaction that included many coinbases by chance would be affected

"if you were to make a special class of transaction for consolidation any regular transaction that included many coinbases by chance would be affected" <--- regular transactions would not include coinbase outputs in rings, under this suggestion

p2pool will significantly increase consolidation txs but they have always existed

doesn't CLI warn you that combining large numbers of outputs is bad for privacy? thought this was well known. and obvs it would be worse for consolidating coinbase outputs

and if we did this, we could limit inputs for other transactions to something very reasonable like idk 16 instead of 100, which might be a win for privacy as well

Keep in mind that there have been a lot of "nice features" in Monero that have later been recognized as a threat to privacy and had to be removed.

with p2pool you can get many txes that are temporarily close and yhe CLI warns you when they are

yeah I'm really not trying to make any ahrd claims just putting it out there to be considered

I guess another option is making it so there can only be one coinbase output but I think we like p2pool

Lyza: In case it wasn't clear, I was supporting your point.

cool :)

"I believe that the original definition of technological spam was in email, where the email systems technically allowed it but it was harmful to its operation. So, yes, spam." there is no difference between spam and demand

By "nice feature" I was implying that consolidating a huge number of outputs in a single tx was a nice feature.

Any demand can be marked as spam to justification for poorly designed system

* ... to justify ...

In my view decoys and ring signatures are a suboptimal system, but they are the best thing we have at the moment, given that other solutions rely on cryptography that has not been battle tested. So, yes, the system is not well designed but there is no other viable way at the moment.

^

Is increasing ring signatures simply just a bandaid for a bigger problem

An increase in ring sizes in the next network upgrade is a stop-gap until much larger ring sizes via Seraphis.

Monero community please help me

Kindly please help me😭

does the transaction appear in the blockchain?

nero-cultist: If you are interested in further reading on weaknesses with the ring signature model, you can read this piece by a Zcash Foundation member. Keep in mind that most of these attacks require you to interact with large nefarious entities:

also this is the wrong channel

This channel is not for support, please use #monero:monero.social and refer to the help you were already linked to earlier.

Mohammed Mujahid: This is not the correct room. Please go elsewhere. This is for development discussion.

<louipcm> "does the transaction appear in..." <- No sir

"... Keep in mind that most of these attacks require you to interact with large nefarious entities:" if your statistical solution will work then it should increase cost (amount of resources) required for these ways of deanonymization

wfaressuissia[m]: Right. That's part of the point of increasing the ring size and developing a better decoy selection algorithm. An adversary would need even more information about a target after the decoy issues are improved.

"An adversary would need even more information about ..." I mean your statistical solution can be tested (this test can be written even before your research) by anyone against those attacks

and there will be concrete numbers how much it helps or not doesn't help

Yes, you are correct

> <@rucknium:monero.social> nero-cultist: If you are interested in further reading on weaknesses with the ring signature model, you can read this piece by a Zcash Foundation member. Keep in mind that most of these attacks require you to interact with large nefarious entities:

> zfnd.org/blog/blockchain-privacy

Do you think we could apply similar concepts to Monero?

The best of both worlds ?

"That's part of the point of increasing the ring size" it makes system better in the worst case and doesn't rely on any assumptions except working cryptography

"... and developing a better decoy selection algorithm." don't know how useful it will be but it relies on many assumptions about usage pattern

If and when there is a better solution with acceptable tradeoffs that is battle-tested and requires no trusted setup, then probably Monero would adopt it.

and isn't ideal solution for decentralized system

wfaressuissia[m]: So the ultimate goal would be to have a dynamically-adjusting decoy selection aglorithm that matches the current usage pattern at every point in time.

It's more interesting to have test (that can be run by anyone) that will show cost for all known attacks on privacy. And this test doesn't require solution for the attacks. But for some reason it looks like this test will not be even written by you.

wfaressuissia[m]: Where's that thing you promised at the MRL meeting?

which one ?

wfaressuissia[m]: libera.monerologs.net/monero-research-lab/20211117#c47763

"Where's that thing ..." in my head yet

wfaressuissia[m]: I suggest you spend time trying to figure out how to move it from your head to the real world instead of being such a nag.

Woah, easy there Ruck.

"I suggest you ..." fortunately there is at least something in my head to move, unlike in others

wfaressuissia[m]: Yeah, who are you talking about? Who others? Out with it!

wfaressuissia[m]: You snipe at other and contribute nothing. Prove me wrong.

Prove me wrong by doing something.

Fellas, it's Friday. We're all nerds here. Let it go

<rock[m]> "Fellas, it's Friday. We're all..." <- speak for yourself! im a dork 😃

nerds dorks geeks

how hard would it be to add a config file option to add/exclude your node from using networks.

e.g. --network-exclude ipv4/6 --network-use i2p/tor?

for those who wish to have all node communications specifically through i2p/tor?

bitcoin config file has the option for onlynet=tor

onlynet=i2p, something I think would be worth porting over to monero :)

"porting command line arg" awesome idea. It also makes sense to port command args "--enable-sybil-resistance --enable-decentralized-mining --enable-high-throughput --enable-high-privacy"

wfaressuissia[m]: why so toxic, I am well aware that this is more than just adding a command

"clearnet: mandatory, all packets, --p2p-bind-ip/--p2p-bind-ipv6, i2p/tor: optional, only txs, `--tx-proxy/--anonymous-outbound/--anonymous-inbound`" these options are already doing, so you didn't even check `monerod --help` ?

"... I am well aware that this is more than just adding a command" there are a lot of problems in current code even with clearnet p2p network (add to this problems with anonymization network support)

also bitcoin is not the best reference of project with good p2p network

and it isn't task that can be described as "porting over"

wfaressuissia[m]: if you actually read the docs you would know that this does not make your node exclusive to that network, nor is there a command to do that

wfaressuissia[m]: you are making assumptions about what I am saying and then attacking your own assumptions. wownero has a dedicated port for i2p of 34565, how hard would it be to just block all connections except for the assigned i2p port. I said nothing about porting bitcoin node code

clearnet isn't working, i2p/tor support is even more funny, there is nothing inside to configure with command line options

what things will be transmitted over that imaginary dedicated i2p port ?

wfaressuissia[m]: what are you smoking? i am running my node over i2p tor and ipv4 with 500 incoming connections right now

Why did you mention 500 ?

wfaressuissia[m]: to tell you that the networking is fine and can handle many connections fine

botcoinnotbot[m]: can you link that wownero commit?

as far as I know wownero doesn't have anything that isn't a thing in monero

"... to tell you that the networking is fine and can handle many connections fine" anyone can send simultaneously 500 packets to your node it will occupy 100MB * 500 RAM at the same time

do you have so much memory ?