05:02:20 Hi hi 05:02:30 Anyone in Bangkok next month? 05:03:15 Checkout this Meetup with Bangkok Privacy Crypto Collective: https://meetu.ps/e/P0KRQ/TWJ3Z/i 05:09:26 Plaiwan One nice try, russian mafia 😎 05:13:50 Why Zano? And Zano even mentioned first? Do they sponsor the event? 05:30:01 It's probably a zano event, only mentioning Monero to sound legit. 06:20:15 Host might be a bag holder 08:06:10 Hello 08:06:10 I would like to do a 0 Fee transaction but the CLI doesn't seem to allow it? 08:17:41 Monero nodes will node broadcast 0 fee transactions 08:17:44 *not broadcast 08:18:21 The only way for you to submit it to the network, is to modify your node and then mine it yourself 08:39:43 Other nodes won't mine it ? 08:40:25 They could, but what's in it for them ? 08:45:29 I mean that's the theory. In practice, is there a transaction selection algorithm that says "ignore the 0 fee transactions" ? 08:51:46 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. 09:25:19 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 09:27:21 20000 piconero per byte - transactions that pay less fees will be discarded and will not propagate through the network 10:25:21 That's sad 10:27:16 P2pool mini could mine 0 fee tx consolidations xD 10:43:30 That would be great 10:52:51 SEETHE OFRN SEETHE ABOUT P2POOL 10:53:06 Seething about 0 fee tx 10:53:26 probably idk im not even reading the conv 10:53:48 same, i only read from plowsof down 11:05:45 0 fee transactions need to be mined 11:21:28 by yourself 11:22:11 I assume you're trolling, [@ammortel:monero.social](https://matrix.to/#/@ammortel:monero.social) 11:24:18 No I am not actually. But I might need to study the fee market before making assertions 11:28:34 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. 11:29:45 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. 11:39:01 .. the fee sets the block size 11:40:40 Its only network spam mitigation, but blockchain storage. dust transactions are the same size as any other tx 11:40:55 Not directly, no. There's just a sort of Laffer curve for "number of transactions included in the next block" vs. "revenue per byte". 11:41:22 If i can spam 0.000000000001 xmr transactions, i can MUCH more easily flood the blockchain 11:41:32 yes directly 11:41:33 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 11:41:50 Where is this in the code? If it's there, I'm not familiar with it 11:41:56 I'm pretty sure Bitcoin is the same way e.g. not relaying zero fee transactions by default 11:41:58 You cannot raise the blocksize without fees 11:42:31 Most gossip networks are. 11:42:48 Right. Its 1000 sat per vkb by default, as a relay rule 11:42:54 Bitcoin nodes only started doing that commonly in 2018, post-Segwit 11:43:01 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 11:43:09 Many still do not, meaning they are happy to accept and relay 0-fee transactions 11:43:44 This is definitely not true. Bitcoin transactions paying less than 200 sat/vB routinely get confirmed. 11:43:46 Its not too low. Its the equivalent to 3000 sats on bitcoin, which is not cheao 11:43:55 Sorry, misread 11:43:56 Vkb 11:44:06 Thought you wrote vB, not vkB 11:44:22 my point though is that there's more than size to consider because xmr transactions are expensive to verify 11:44:24 1 sat/b 11:44:41 I said vkb because that is how it is defined 11:44:43 and are about to get even more expensive 11:45:25 Monero pays equivalent to 2sats/vb 11:45:46 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. 11:46:29 you still need to verify every TX that gets put into a block though 11:47:15 nodes were buckling under spam attacks under the current fee structure. we already have observational data 11:47:25 Wrong 11:47:33 if the point of fees is spam mitigation (it is), zero fees are a nonstarter 11:47:46 Nodes were buckling due to an inefficient tx relay protocol 11:48:21 okay fuck it let's reduce fees to zero and see how it goes 11:48:30 I agree that 0 fee is a nonstarter, but because it decreased the effort to spam the blockchain storage by 20000 11:48:32 I wanna see this disaster, let's do it 11:48:46 Fk that 11:49:13 I can send 1000000000000 transactions for the low low cost of 1xmr 11:50:08 Actually, 0 cost, i'd send them to myself. But i could generate that many transactions and only own 1 xmr 11:50:46 And i can repeat the spam forever, at 0 cost, and inflate everyones blockchains by hundreds of mb per day 11:51:25 hey good think fcmp transactions will take like 30+ seconds to generate 11:51:31 new spam mitigation technique lol 11:51:44 lolol, should be 3 seconds they say 11:51:50 We'll see 11:52:21 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 11:52:38 with high numbers of inputs 11:53:07 Yea, like 8mins 11:53:12 mhm 11:53:19 for small number if inputs 11:53:41 Was much higher for the larger test he did 11:53:51 well if max inputs is like 8, "big" is relative :( 11:53:53 but ya 11:54:39 I cant imagine having to work around this 11:55:05 Probably breaks tf out of atomic swaps, exchange withdrawal, paying employees, purchasing expensive goods 11:56:41 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 11:57:35 I dont have any problem with an 8 output max, but 8 inputs is treacherous 11:59:35 yeah it's not good 11:59:36 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. 11:59:38 i dont see any benefit to sending eight 8 input tx, instead of one 64 input tx 12:00:20 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 12:01:15 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 12:01:20 Regardless whether you are sending eight 8 input, or one 64, the node has to verify 64 inputs.. 12:01:41 that's what I would think, yeah 12:01:44 Its a spam issue if i send eight 8 input tx all the same 12:03:08 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 12:08:30 Lyza: ofrnAI https://libera.monerologs.net/no-wallet-left-behind/20250416 12:10:20 oh nice thanks spackle that's really good to hear 12:12:27 An 8 in is less time than 2x4. Would like to see 16, 32, 64 etc 12:12:55 An 8 in is 10% less time than 2x4. Would like to see 16, 32, 64 etc 12:13:56 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 12:16:45 Max inputs is related to max tx size** 12:16:57 It used to be related to blocksize many years ago 12:17:24 I honestly think its just a design choice 12:18:31 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 14:18:50 Hello 🙂 14:33:03 I would like to accept monero in my golang Backend. 14:33:04 Can i somehow deterministicaly create a monero address using a userID (i64) 14:37:35 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 14:37:41 Or do i just generate an address per user and store it in my DB? 14:39:04 daemon is only needed for the local node. if you want to connect to a remote node you don't need it 14:41:25 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. 14:42:18 Use the user id one of them. Or (user id << 8) | [0..255] if you want the user to have up to 256 addresses. 14:42:28 Minor and major are 32 bit each. 14:43:24 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. 14:54:11 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 14:54:55 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 14:57:36 Nice i will do that, thank you 15:08:48 Integrated addrs were supposed to be depreciated isn’t it 15:09:40 What's the difference between main and mini on p2pool? 15:17:37 By convention, small hash goes to mini. I think mini pays out in smaller denominations also 15:26:55 Yea, but they still work, also they are not as private as just subaddresses as I heard 15:27:17 Yes, hopefully it’s depreciated with fcmp++ 15:41:59 I guess I shouldn’t be recommending nearly depreciated method of accepting a payment srry xd 15:43:13 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 15:51:56 "nearly depreciated" Well, depends whom you ask :) It's "depreciated" for many years already, but I can't see any real push ... 15:54:07 It still works so merchants are lazy to adopt subaddress 15:58:13 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 15:59:22 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 :) 15:59:29 Next question I have is, i have a hashrate of about 11,000 h/s should I be mining on main or mini? 16:09:26 Have you ever used the P2Pool mining pool? 16:20:35 No, it's why I'm asking 20:44:54 monero or MOOOONero