00:00:27 OrangeFren.com is one of the organisers of the Bitcoin Film Fest. We're also researching organising Monerokon in 2026. We're considering different locations, among them Istanbul πŸ‡ΉπŸ‡·. However during a discussion with the founder of the BFF it was suggested that we host Monerokon in the same venue, at the same time. MK woul [... too long, see https://mrelay.p2pool.observer/e/mPuGptAKRHllNVd6 ] 00:00:36 The BFF takes place in Warsaw πŸ‡΅πŸ‡± 00:18:15 SHOOTING RANGE πŸ”₯πŸ”₯πŸ”₯ 00:30:16 Stupid matrix doesn't have real gun emojis 00:32:20 orangefren Where does BFF happen again? 00:32:34 https://bitcoinfilmfest.com/ 00:32:42 Poland!? Warsaw!? 00:33:01 * dukenukem goes πŸ‘€... 00:33:51 dukenukem: Warsaw, Poland 00:35:00 orangefren Okay, please full send with this idea. 00:35:15 Can I sign anywhere? Make it be. 08:44:50 Aren’t you tired of just talking nonsense while having your status? > <@ofrnxmr> Coin Wallet aligns themselves with changelly πŸ˜‚ 08:44:50 Besides changelly, we have 3 other Monero swap providers 11:04:38 https://mrelay.p2pool.observer/m/matrix.org/ctYOiItqwqCiqtpDOxJwpolp.png (image.png) 11:13:11 @monerobull:matrix.org: Literally me 11:13:27 Now that's a bingo card of how many things from the screen you use :D 11:13:44 I counted 6 11:19:41 I would say I use all of them except session 11:19:41 if only 6 you're ngmi 11:26:48 Okay, 7 11:26:52 Forgot about gnupg 11:44:18 heads beats coreboot anytime 12:10:43 every single person ive seen use HTTPS actually has nothing worth hiding 12:59:07 how do you know monerobull/ 13:14:27 i assume that was a "/s" and the intention of posting that image is to normalise usage of privacy tools, as everyone uses them in some form already. tldr im looking for recipes to make an apple pie but id rather you didnt look over my shoulder 13:15:33 you could be making an apple pie ... or a pineapple grenade 13:16:45 straight to jail! 16:08:25 sech1: I counted 7. :DD 16:08:43 No, 8! 18:38:23 <321bob321> Is that Luks or luks2 ? 19:08:06 If hard-limit is added to Monero block-size, it's game over man! game over... 19:10:43 not only we know it will stay forever (this shit always ends like this) but also we could miss oportunity of Monero being chosen to be used by some government 19:11:53 maybe... just fix the damn bug, instead of cutting Monero balls - it's all about scalability. 19:13:46 also, i doubt even nation sponsored attacker will have enough money to pull a spam attack that would increase block size to over 90 MB 19:14:54 hopefully - Justing will finally fuck off and developers could think more straight. 19:16:07 azunda: Lol? Its not that expensive 19:16:23 And if you're a pool operator, the cost is much, much less 19:16:53 didn't do the math but 90 MB is how many tx ? i think it's a big number 19:17:01 And if you use lvl 3 fees, its MUCH much less (as you force honest users to use lvl 4 fees to get confirmed) 19:17:27 And honest users using lvl 3-4 fees, causes the blocks to grow even faster 19:17:57 do you have some numbers for this? 19:18:03 i'm curious 19:18:19 azunda: 30-60k txs using ringct, abour 7-15k fcmp 19:18:31 the biggest spam attacks we had didn't even break 1 MB block size 19:18:44 But you cant bring block size to 90mb instantly 19:18:59 30-60 k tx per what ? 19:19:08 azunda: Ive ran on testnet and reached 15mb in ~24hrs 19:19:13 azunda: Per block 19:19:17 ok 19:19:25 per 90mb* 19:19:42 how much in fees it would be then? 19:20:38 19-38xmr for a lvl 3 fee 90mb block 19:21:03 i'm also wondering - if the attack is so easy - why previous spam attacks where not even close to 1 MB blocks 19:21:21 because the spammers are incompetent 19:21:42 it only takes a couple hrs to hit 5+mb 19:22:12 The incompetent spammers used low fees, paused the spam (did it in waves), etc. 19:22:43 When one did use lvl 2 fees, they allowed the txpool to empty and only pushed blocks to like 350kb. 19:22:47 aren't blocks increasing based on the average of last X blocks (i can't remember - 120 or more) 19:23:08 2x median of the last 100 blocks 19:23:12 ok 19:24:49 It grows fast at lvl 3 and 4. Lvl 4 is expensive, so i wouldnt expect a spammer to use it. But lvl 3 isnt bad, and if a state actor or mining pool (like qubic) wanted to bring blocks to 30mb, they could w/o too much trouble 19:24:58 let's say attacker wanted to spam attack for 24 hours with average price of 38 xmr per block - it would cost him more than 10 million USD today 19:25:16 hmm... 19:25:43 i know 10M is not much for state sponsored attack 19:26:54 instead of cap on block size, i would add code that increases fees exponentially when this 90 MB / bug area gets close 19:27:04 for the time being- until it's fixed 19:27:27 let's say at 20 MB even 19:27:42 because we can't probably expect natural growth that fast 19:28:03 so anything beyond 20 MB for the next - at least two years, is 99.999% attack 19:28:21 i think it's enough time for some dev to fix that shit 19:29:52 the hard cap on block size is attack itself - on consensus we have (at least my view on consensus of what Monero stands for) 19:30:25 this is not the first time they try to attack our principals 19:30:52 you probably seen the spam on reddit with PoW change bullshit 19:32:24 we already have a cap, in that if you reach it the network breaks 19:32:29 the biggest advantage of Monero always was (in my opinion) - that it's protocol is not limited, only the underlying infrastructure 19:32:40 lol yeah 19:32:54 so protocol is limited 19:33:01 always has been 19:33:02 well yeah, but it's limited by a bug 19:33:21 it was put in on purpose 19:33:28 haha good one 19:33:36 It was 19:33:47 All cryptonote coins have the limit 19:33:57 Zano, monero, etc 19:35:21 what was monero's block size limit at genesis? 19:35:54 don't remember 19:36:05 I wasn't born yet 19:36:25 My point is that, if monero added dynamic block sizes, then monero adding them is the "bug" 19:36:40 As they were added, without regard for existong limits 19:37:21 but imagine if all the fuzz is coming from a bug that is one byte long, because somewhere in code there is a "<" instead of "<=" :D 19:37:56 ofrnxmr - probably so 19:38:04 They should have never been coded to scale above hard limits, and worse, we (monero) added other limits (even lower than the 100mb packet limit) that cause issues or break block sync below 100mb 19:38:48 Example: there is a 4mb limit on fluffyblock data 19:39:13 that old code should be revisited but devs are pursuing newer tech instead of cleaning old shit 19:39:53 yes because ring sigs are a weakness 19:40:01 So if you receive a fluffyblock and you're missing 3.9mb of the txs, you'll sent a block + the 3.9mb of txs. If there are 15mb of missing txs, you'll just fail to sync the block repeatesly until you receive the txs separately 19:40:16 there is more work to be done than we have devs to do it 19:40:34 yeah i know, but we have to have strong legs before doing upper part 19:41:09 yes leg day b4 arm day :) 19:42:15 it's like - we will have this best cryptographical blockchain based cryptocurrency on the planet, but it could be destoryed by a rich parents script kiddie :D 19:42:16 but somehow these new arms are now causing us to realize the importance of our legs 19:42:38 We should limit to 2.5mb since thats bigger than zcash's /s 19:43:22 limit to 500 kb - we will finally flip Bitcoin 19:43:29 Monero scaling to 15mb in a day is too low 19:43:55 90mb blocks that will fracture the network are too low /s 19:44:40 Seriously though, the proposal to have a sanity cap wouldnt allow 90mb blocks for 6(!) More years. Keep in mind that monero is 11 19:45:34 probably wouldn't hurt, but history of hard caps on other blockchains is not colorful.. 19:45:58 In 6 years, monero will either be "fixed" where it can handle >90mb blocks (and the limit will be removed) or it wont be fixed 19:46:02 i know we can agree today, but i don't know if this agreement will hold tomorrow 19:46:05 azunda: This isnt bitcoin 19:46:22 yes and no... 19:46:43 if someone would fork Moner today (it's not early days of cryptonote) - then it would most probably fail 19:47:17 If monero is captured in the future, whoever captures it will add a hard cap regardless. Avoiding adding it today (out of precaution), doesnt prevent bad actors from adding (maliciously) in the future 19:47:41 hmm... yeah... 19:47:50 Also, i dont think we need to add a "hard" (consensus) cap 19:48:25 But just needs to be a default, like opcodes in btc. 19:48:39 i like that 19:48:54 gotta go, thanks for nice talk. 19:49:54 how many hardforks has btc had? 19:50:13 0 19:50:37 I asked the question for the person that just left :) 19:51:00 ah :) 20:08:26 https://blog.lopp.net/has-bitcoin-ever-hard-forked/ 20:08:26 > BitMEX's list has 3 events labelled as "hard fork." I myself believe there to be 7 consensus changes that could be argued to be hard forks but will make a case for why most should not be considered as such. 20:10:44 > There is a strong case that the Bitcoin protocol has only implemented 1 practical permanent hard fork. The forking condition appears to have triggered back when Bitcoin was a little over 3 years old, the exchange rate was $5, and there were surely far fewer nodes on the network. 20:10:58 Interpret the facts as you will. 20:22:46 1 HF is what I vaguely remembered as I don't pay close attention to corn 20:30:19 there have been chain forks but one survives, you can sync with the originally released code still with some massaging (of things like db locks)