<p​laiwanone:matrix.org> Hi hi

<p​laiwanone:matrix.org> Anyone in Bangkok next month?

<p​laiwanone:matrix.org> Checkout this Meetup with Bangkok Privacy Crypto Collective: meetu.ps/e/P0KRQ/TWJ3Z/i

<o​cean:nope.chat> Plaiwan One nice try, russian mafia 😎

Why Zano? And Zano even mentioned first? Do they sponsor the event?

<t​rasherdk:monero.social> It's probably a zano event, only mentioning Monero to sound legit.

<e​longated:matrix.org> Host might be a bag holder

<a​mmortel:monero.social> Hello

<a​mmortel:monero.social> I would like to do a 0 Fee transaction but the CLI doesn't seem to allow it?

Monero nodes will node broadcast 0 fee transactions

*not broadcast

The only way for you to submit it to the network, is to modify your node and then mine it yourself

<a​mmortel:monero.social> Other nodes won't mine it ?

They could, but what's in it for them ?

<a​mmortel:monero.social> I mean that's the theory. In practice, is there a transaction selection algorithm that says "ignore the 0 fee transactions" ?

I think the tx selection algorithm does not explicitely prevent 0 fee txes. They'll just be used last. I've not double checked though.

There is a min fee for a transaction to be added to a node's mempool. So 0 fee transactions will not reach any nodes by default

20000 piconero per byte - transactions that pay less fees will be discarded and will not propagate through the network

<a​mmortel:monero.social> That's sad

P2pool mini could mine 0 fee tx consolidations xD

<a​mmortel:monero.social> That would be great

<s​yntheticbird:monero.social> SEETHE OFRN SEETHE ABOUT P2POOL

<o​frnxmr:xmr.mx> Seething about 0 fee tx

<s​yntheticbird:monero.social> probably idk im not even reading the conv

<o​frnxmr:xmr.mx> same, i only read from plowsof down

<a​mmortel:monero.social> 0 fee transactions need to be mined

<o​frnxmr:xmr.mx> by yourself

<o​frnxmr:xmr.mx> I assume you're trolling, [@ammortel:monero.social](https://matrix.to/#/@ammortel:monero.social)

<a​mmortel:monero.social> No I am not actually. But I might need to study the fee market before making assertions

<j​ivan:opaline.uk> Miners' only incentive to include 0-fee transactions in blocks is promoting use of the network by users that can't afford to pay fees.

<j​ivan:opaline.uk> Other than that, requiring a baseline fee is something many nodes and miners enforce as a sort of anti-spam measure. We don't want the network to be easily DDOS'd by spam transactions flooding the network.

<o​frnxmr:xmr.mx> .. the fee sets the block size

<o​frnxmr:xmr.mx> Its only network spam mitigation, but blockchain storage. dust transactions are the same size as any other tx

<j​ivan:opaline.uk> Not directly, no. There's just a sort of Laffer curve for "number of transactions included in the next block" vs. "revenue per byte".

<o​frnxmr:xmr.mx> If i can spam 0.000000000001 xmr transactions, i can MUCH more easily flood the blockchain

<o​frnxmr:xmr.mx> yes directly

<j​ivan:opaline.uk> But if a miner doesn't care about maximising revenue per byte, only revenue per hash computation, then the existence of that curve is irrelevant to them

<j​ivan:opaline.uk> Where is this in the code? If it's there, I'm not familiar with it

<m​onero.arbo:matrix.org> I'm pretty sure Bitcoin is the same way e.g. not relaying zero fee transactions by default

<o​frnxmr:xmr.mx> You cannot raise the blocksize without fees

<j​ivan:opaline.uk> Most gossip networks are.

<o​frnxmr:xmr.mx> Right. Its 1000 sat per vkb by default, as a relay rule

<j​ivan:opaline.uk> Bitcoin nodes only started doing that commonly in 2018, post-Segwit

<m​onero.arbo:matrix.org> the mempool spam would crush nodes trying to verify that many transactions. monero transactions are heavy to verify. min fee is arguably already too low

<j​ivan:opaline.uk> Many still do not, meaning they are happy to accept and relay 0-fee transactions

<j​ivan:opaline.uk> This is definitely not true. Bitcoin transactions paying less than 200 sat/vB routinely get confirmed.

<o​frnxmr:xmr.mx> Its not too low. Its the equivalent to 3000 sats on bitcoin, which is not cheao

<j​ivan:opaline.uk> Sorry, misread

<o​frnxmr:xmr.mx> Vkb

<j​ivan:opaline.uk> Thought you wrote vB, not vkB

<m​onero.arbo:matrix.org> my point though is that there's more than size to consider because xmr transactions are expensive to verify

<o​frnxmr:xmr.mx> 1 sat/b

<o​frnxmr:xmr.mx> I said vkb because that is how it is defined

<m​onero.arbo:matrix.org> and are about to get even more expensive

<o​frnxmr:xmr.mx> Monero pays equivalent to 2sats/vb

<j​ivan:opaline.uk> Nodes can always rate-limit incoming message processing. Fees will naturally adjust if users aren't getting their transactions relayed quickly enough for their liking.

<m​onero.arbo:matrix.org> you still need to verify every TX that gets put into a block though

<m​onero.arbo:matrix.org> nodes were buckling under spam attacks under the current fee structure. we already have observational data

<o​frnxmr:xmr.mx> Wrong

<m​onero.arbo:matrix.org> if the point of fees is spam mitigation (it is), zero fees are a nonstarter

<o​frnxmr:xmr.mx> Nodes were buckling due to an inefficient tx relay protocol

<m​onero.arbo:matrix.org> okay fuck it let's reduce fees to zero and see how it goes

<o​frnxmr:xmr.mx> I agree that 0 fee is a nonstarter, but because it decreased the effort to spam the blockchain storage by 20000

<m​onero.arbo:matrix.org> I wanna see this disaster, let's do it

<o​frnxmr:xmr.mx> Fk that

<o​frnxmr:xmr.mx> I can send 1000000000000 transactions for the low low cost of 1xmr

<o​frnxmr:xmr.mx> Actually, 0 cost, i'd send them to myself. But i could generate that many transactions and only own 1 xmr

<o​frnxmr:xmr.mx> And i can repeat the spam forever, at 0 cost, and inflate everyones blockchains by hundreds of mb per day

<m​onero.arbo:matrix.org> hey good think fcmp transactions will take like 30+ seconds to generate

<m​onero.arbo:matrix.org> new spam mitigation technique lol

<o​frnxmr:xmr.mx> lolol, should be 3 seconds they say

<o​frnxmr:xmr.mx> We'll see

<m​onero.arbo:matrix.org> I'm being a little facetious but tobtoht ran some tests the other day and it was pretty bad, some transactions were taking minutes with current code

<m​onero.arbo:matrix.org> with high numbers of inputs

<o​frnxmr:xmr.mx> Yea, like 8mins

<m​onero.arbo:matrix.org> mhm

<o​frnxmr:xmr.mx> for small number if inputs

<o​frnxmr:xmr.mx> Was much higher for the larger test he did

<m​onero.arbo:matrix.org> well if max inputs is like 8, "big" is relative :(

<m​onero.arbo:matrix.org> but ya

<o​frnxmr:xmr.mx> I cant imagine having to work around this

<o​frnxmr:xmr.mx> Probably breaks tf out of atomic swaps, exchange withdrawal, paying employees, purchasing expensive goods

<o​frnxmr:xmr.mx> 8 input max basically implies that no merchant will ever adopt monero, and we should expect monero to remain a niche where users dont typically a) have more than 8 outputs or b) have to spend more than 8

<o​frnxmr:xmr.mx> I dont have any problem with an 8 output max, but 8 inputs is treacherous

<m​onero.arbo:matrix.org> yeah it's not good

<o​frnxmr:xmr.mx> From tob's test, its obvious that one 8 input tx is smaller in size than two 4 input tx, and the verification time is pretty linear.

<o​frnxmr:xmr.mx> i dont see any benefit to sending eight 8 input tx, instead of one 64 input tx

<o​frnxmr:xmr.mx> On the contrary, it would save blockspace to send in 1 tx, and veritication costs would be pretty much identical, and ux would be greatly improved

<m​onero.arbo:matrix.org> something was said about nodes getting such big / long to verify blobs being a spam issue but I'm not gonna pretend I really understand it

<o​frnxmr:xmr.mx> Regardless whether you are sending eight 8 input, or one 64, the node has to verify 64 inputs..

<m​onero.arbo:matrix.org> that's what I would think, yeah

<o​frnxmr:xmr.mx> Its a spam issue if i send eight 8 input tx all the same

<o​frnxmr:xmr.mx> If it takes 3 sec to send an 8 input, then it should take 24 sec to send a 64 input. doesnt sound like a deal breaket to me

<s​packle:monero.social> Lyza: ofrnAI libera.monerologs.net/no-wallet-left-behind/20250416

<m​onero.arbo:matrix.org> oh nice thanks spackle that's really good to hear

<o​frnxmr:xmr.mx> An 8 in is less time than 2x4. Would like to see 16, 32, 64 etc

<o​frnxmr:xmr.mx> An 8 in is 10% less time than 2x4. Would like to see 16, 32, 64 etc

<m​onero.arbo:matrix.org> yeah I'm not sure why it shouldn't be like it is now, where max inputs is more related to blocksize than having an arbitrary limit, but I'm open to learning why that shouldn't be the case

<o​frnxmr:xmr.mx> Max inputs is related to max tx size**

<o​frnxmr:xmr.mx> It used to be related to blocksize many years ago

<o​frnxmr:xmr.mx> I honestly think its just a design choice

<o​frnxmr:xmr.mx> I dont think the reason to choose 8 over 4, is because 8 is fasterto verify. And the reason to not go higher than 8, is (afaict) arbitrary

<n​ull:unsilence.net> Hello 🙂

<a​tomfried:matrix.org> I would like to accept monero in my golang Backend.

<a​tomfried:matrix.org> Can i somehow deterministicaly create a monero address using a userID (i64)

<n​ull:unsilence.net> You can buy from an exchange depending on where you live. If there are no Monero exchanges where you live you can buy another crypto like BTC and exchange on a decentralized exchange

<a​tomfried:matrix.org> Or do i just generate an address per user and store it in my DB?

<n​ull:unsilence.net> daemon is only needed for the local node. if you want to connect to a remote node you don't need it

Addresses are deterministic. See get get_address RPC, you can give it an account index and a... minor, can't recall user terminology right now.

Use the user id one of them. Or (user id << 8) | [0..255] if you want the user to have up to 256 addresses.

Minor and major are 32 bit each.

If your user ids span the full 64 bit range, you can still do that but will end up in many accounts, which can be a pain to consolidate.

<x​3cc:nope.chat> If there is no need for a consistent address I think integrated addresses are very convenient, but will need to keep track of funds in atomic units in database

<x​3cc:nope.chat> If there is no need for a static address/address creation, I think integrated addresses are very convenient, but will need to keep track of funds in atomic units in database

<a​tomfried:matrix.org> Nice i will do that, thank you

<e​longated:matrix.org> Integrated addrs were supposed to be depreciated isn’t it

<j​ust_a_hoppean_from_kansas_1914:matrix.org> What's the difference between main and mini on p2pool?

<a​remor:matrix.org> By convention, small hash goes to mini. I think mini pays out in smaller denominations also

<x​3cc:nope.chat> Yea, but they still work, also they are not as private as just subaddresses as I heard

<e​longated:matrix.org> Yes, hopefully it’s depreciated with fcmp++

<x​3cc:nope.chat> I guess I shouldn’t be recommending nearly depreciated method of accepting a payment srry xd

<x​3cc:nope.chat> Just used integrated addresses a few months ago and it was convenient to track payments by payment_id, but anyways accounts/subaddresses will be better

"nearly depreciated" Well, depends whom you ask :) It's "depreciated" for many years already, but I can't see any real push ...

<e​longated:matrix.org> It still works so merchants are lazy to adopt subaddress

Well, I would guess many "merchants" don't adopt something themselves, but rely on software that somebody else makes, so they don't have free choice

I think we don't even have a simple list of Monero related software that does not yet support subaddresses. We can be lazy too :)

<j​ust_a_hoppean_from_kansas_1914:matrix.org> Next question I have is, i have a hashrate of about 11,000 h/s should I be mining on main or mini?

<g​ug68hes:matrix.org> Have you ever used the P2Pool mining pool?

<j​ust_a_hoppean_from_kansas_1914:matrix.org> No, it's why I'm asking

<d​roid192:matrix.org> monero or MOOOONero