<orangefren> 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 mrelay.p2pool.observer/e/mPuGptAKRHllNVd6 ]

<orangefren> The BFF takes place in Warsaw 🇵🇱

<prisj:matrix.org> SHOOTING RANGE 🔥🔥🔥

<orangefren> Stupid matrix doesn't have real gun emojis

orangefren Where does BFF happen again?

Poland!? Warsaw!?

<orangefren> dukenukem: Warsaw, Poland

orangefren Okay, please full send with this idea.

Can I sign anywhere? Make it be.

<coinwalletapp:matrix.org> Aren’t you tired of just talking nonsense while having your status? > <@ofrnxmr> Coin Wallet aligns themselves with changelly 😂

<coinwalletapp:matrix.org> Besides changelly, we have 3 other Monero swap providers

<monerobull:matrix.org> mrelay.p2pool.observer/m/matrix.org/ctYOiItqwqCiqtpDOxJwpolp.png (image.png)

<pickup23:matrix.org> @monerobull:matrix.org: Literally me

Now that's a bingo card of how many things from the screen you use :D

I counted 6

<pickup23:matrix.org> I would say I use all of them except session

<pickup23:matrix.org> if only 6 you're ngmi

Okay, 7

Forgot about gnupg

<hbs:matrix.org> heads beats coreboot anytime

<monerobull:matrix.org> every single person ive seen use HTTPS actually has nothing worth hiding

<mmxxx> how do you know monerobull/

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

you could be making an apple pie ... or a pineapple grenade

straight to jail!

<rottenwheel:unredacted.org> sech1: I counted 7. :DD

<rottenwheel:unredacted.org> No, 8!

<321bob321> Is that Luks or luks2 ?

If hard-limit is added to Monero block-size, it's game over man! game over...

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

maybe... just fix the damn bug, instead of cutting Monero balls - it's all about scalability.

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

hopefully - Justing will finally fuck off and developers could think more straight.

<ofrnxmr:xmr.mx> azunda: Lol? Its not that expensive

<ofrnxmr:xmr.mx> And if you're a pool operator, the cost is much, much less

didn't do the math but 90 MB is how many tx ? i think it's a big number

<ofrnxmr:xmr.mx> And if you use lvl 3 fees, its MUCH much less (as you force honest users to use lvl 4 fees to get confirmed)

<ofrnxmr:xmr.mx> And honest users using lvl 3-4 fees, causes the blocks to grow even faster

do you have some numbers for this?

i'm curious

<ofrnxmr:xmr.mx> azunda: 30-60k txs using ringct, abour 7-15k fcmp

the biggest spam attacks we had didn't even break 1 MB block size

<ofrnxmr:xmr.mx> But you cant bring block size to 90mb instantly

30-60 k tx per what ?

<ofrnxmr:xmr.mx> azunda: Ive ran on testnet and reached 15mb in ~24hrs

<ofrnxmr:xmr.mx> azunda: Per block

ok

<ofrnxmr:xmr.mx> per 90mb*

how much in fees it would be then?

<ofrnxmr:xmr.mx> 19-38xmr for a lvl 3 fee 90mb block

i'm also wondering - if the attack is so easy - why previous spam attacks where not even close to 1 MB blocks

<ofrnxmr:xmr.mx> because the spammers are incompetent

<ofrnxmr:xmr.mx> it only takes a couple hrs to hit 5+mb

<ofrnxmr:xmr.mx> The incompetent spammers used low fees, paused the spam (did it in waves), etc.

<ofrnxmr:xmr.mx> When one did use lvl 2 fees, they allowed the txpool to empty and only pushed blocks to like 350kb.

aren't blocks increasing based on the average of last X blocks (i can't remember - 120 or more)

<ofrnxmr:xmr.mx> 2x median of the last 100 blocks

ok

<ofrnxmr:xmr.mx> 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

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

hmm...

i know 10M is not much for state sponsored attack

instead of cap on block size, i would add code that increases fees exponentially when this 90 MB / bug area gets close

for the time being- until it's fixed

let's say at 20 MB even

because we can't probably expect natural growth that fast

so anything beyond 20 MB for the next - at least two years, is 99.999% attack

i think it's enough time for some dev to fix that shit

the hard cap on block size is attack itself - on consensus we have (at least my view on consensus of what Monero stands for)

this is not the first time they try to attack our principals

you probably seen the spam on reddit with PoW change bullshit

we already have a cap, in that if you reach it the network breaks

the biggest advantage of Monero always was (in my opinion) - that it's protocol is not limited, only the underlying infrastructure

lol yeah

so protocol is limited

always has been

well yeah, but it's limited by a bug

it was put in on purpose

haha good one

<ofrnxmr:xmr.mx> It was

<ofrnxmr:xmr.mx> All cryptonote coins have the limit

<ofrnxmr:xmr.mx> Zano, monero, etc

<ofrnxmr:xmr.mx> what was monero's block size limit at genesis?

don't remember

I wasn't born yet

<ofrnxmr:xmr.mx> My point is that, if monero added dynamic block sizes, then monero adding them is the "bug"

<ofrnxmr:xmr.mx> As they were added, without regard for existong limits

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

ofrnxmr - probably so

<ofrnxmr:xmr.mx> 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

<ofrnxmr:xmr.mx> Example: there is a 4mb limit on fluffyblock data

that old code should be revisited but devs are pursuing newer tech instead of cleaning old shit

yes because ring sigs are a weakness

<ofrnxmr:xmr.mx> 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

there is more work to be done than we have devs to do it

yeah i know, but we have to have strong legs before doing upper part

yes leg day b4 arm day :)

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

but somehow these new arms are now causing us to realize the importance of our legs

<ofrnxmr:xmr.mx> We should limit to 2.5mb since thats bigger than zcash's /s

limit to 500 kb - we will finally flip Bitcoin

<ofrnxmr:xmr.mx> Monero scaling to 15mb in a day is too low

<ofrnxmr:xmr.mx> 90mb blocks that will fracture the network are too low /s

<ofrnxmr:xmr.mx> Seriously though, the proposal to have a sanity cap wouldnt allow 90mb blocks for 6(!) More years. Keep in mind that monero is 11

probably wouldn't hurt, but history of hard caps on other blockchains is not colorful..

<ofrnxmr:xmr.mx> 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

i know we can agree today, but i don't know if this agreement will hold tomorrow

<ofrnxmr:xmr.mx> azunda: This isnt bitcoin

yes and no...

if someone would fork Moner today (it's not early days of cryptonote) - then it would most probably fail

<ofrnxmr:xmr.mx> 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

hmm... yeah...

<ofrnxmr:xmr.mx> Also, i dont think we need to add a "hard" (consensus) cap

<ofrnxmr:xmr.mx> But just needs to be a default, like opcodes in btc.

i like that

gotta go, thanks for nice talk.

how many hardforks has btc had?

<dan:cypherstack.com> 0

I asked the question for the person that just left :)

<dan:cypherstack.com> ah :)

<rucknium> blog.lopp.net/has-bitcoin-ever-hard-forked

<rucknium> > 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.

<rucknium> > 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.

<rucknium> Interpret the facts as you will.

1 HF is what I vaguely remembered as I don't pay close attention to corn

<dan:cypherstack.com> 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)