00:00:14
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 https://mrelay.p2pool.observer/e/mPuGptAKRHllNVd6 ]
00:00:23
orangefren:
The BFF takes place in Warsaw 🇵🇱
00:18:02
prisj:matrix.org:
SHOOTING RANGE 🔥🔥🔥
00:30:03
orangefren:
Stupid matrix doesn't have real gun emojis
00:32:07
dukenukem:
orangefren Where does BFF happen again?
00:32:21
dukenukem:
https://bitcoinfilmfest.com/
00:32:29
dukenukem:
Poland!? Warsaw!?
00:32:47
dukenukem:
goes 👀...
00:33:38
orangefren:
dukenukem: Warsaw, Poland
00:34:47
dukenukem:
orangefren Okay, please full send with this idea.
00:35:02
dukenukem:
Can I sign anywhere? Make it be.
08:44:36
coinwalletapp:matrix.org:
Aren’t you tired of just talking nonsense while having your status? > <@ofrnxmr> Coin Wallet aligns themselves with changelly 😂
08:44:36
coinwalletapp:matrix.org:
Besides changelly, we have 3 other Monero swap providers
11:04:24
monerobull:matrix.org:
https://mrelay.p2pool.observer/m/matrix.org/ctYOiItqwqCiqtpDOxJwpolp.png (image.png)
11:12:57
pickup23:matrix.org:
@monerobull:matrix.org: Literally me
11:13:13
sech1:
Now that's a bingo card of how many things from the screen you use :D
11:13:31
sech1:
I counted 6
11:19:27
pickup23:matrix.org:
I would say I use all of them except session
11:19:27
pickup23:matrix.org:
if only 6 you're ngmi
11:26:34
sech1:
Okay, 7
11:26:38
sech1:
Forgot about gnupg
11:44:05
hbs:matrix.org:
heads beats coreboot anytime
12:10:30
monerobull:matrix.org:
every single person ive seen use HTTPS actually has nothing worth hiding
12:58:54
mmxxx:
how do you know monerobull/
13:14:14
plowsof:
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:20
DataHoarder:
you could be making an apple pie ... or a pineapple grenade
13:16:31
plowsof:
straight to jail!
16:08:11
rottenwheel:unredacted.org:
sech1: I counted 7. :DD
16:08:29
rottenwheel:unredacted.org:
No, 8!
18:38:10
321bob321:
Is that Luks or luks2 ?
19:07:52
azunda:
If hard-limit is added to Monero block-size, it's game over man! game over...
19:10:30
azunda:
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:39
azunda:
maybe... just fix the damn bug, instead of cutting Monero balls - it's all about scalability.
19:13:32
azunda:
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:40
azunda:
hopefully - Justing will finally fuck off and developers could think more straight.
19:15:53
ofrnxmr:xmr.mx:
azunda: Lol? Its not that expensive
19:16:09
ofrnxmr:xmr.mx:
And if you're a pool operator, the cost is much, much less
19:16:39
azunda:
didn't do the math but 90 MB is how many tx ? i think it's a big number
19:16:47
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)
19:17:13
ofrnxmr:xmr.mx:
And honest users using lvl 3-4 fees, causes the blocks to grow even faster
19:17:43
azunda:
do you have some numbers for this?
19:17:49
azunda:
i'm curious
19:18:05
ofrnxmr:xmr.mx:
azunda: 30-60k txs using ringct, abour 7-15k fcmp
19:18:18
azunda:
the biggest spam attacks we had didn't even break 1 MB block size
19:18:30
ofrnxmr:xmr.mx:
But you cant bring block size to 90mb instantly
19:18:45
azunda:
30-60 k tx per what ?
19:18:55
ofrnxmr:xmr.mx:
azunda: Ive ran on testnet and reached 15mb in ~24hrs
19:18:59
ofrnxmr:xmr.mx:
azunda: Per block
19:19:03
azunda:
ok
19:19:11
ofrnxmr:xmr.mx:
per 90mb*
19:19:29
azunda:
how much in fees it would be then?
19:20:24
ofrnxmr:xmr.mx:
19-38xmr for a lvl 3 fee 90mb block
19:20:50
azunda:
i'm also wondering - if the attack is so easy - why previous spam attacks where not even close to 1 MB blocks
19:21:07
ofrnxmr:xmr.mx:
because the spammers are incompetent
19:21:29
ofrnxmr:xmr.mx:
it only takes a couple hrs to hit 5+mb
19:21:59
ofrnxmr:xmr.mx:
The incompetent spammers used low fees, paused the spam (did it in waves), etc.
19:22:29
ofrnxmr:xmr.mx:
When one did use lvl 2 fees, they allowed the txpool to empty and only pushed blocks to like 350kb.
19:22:34
azunda:
aren't blocks increasing based on the average of last X blocks (i can't remember - 120 or more)
19:22:55
ofrnxmr:xmr.mx:
2x median of the last 100 blocks
19:22:59
azunda:
ok
19:24:35
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
19:24:44
azunda:
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:02
azunda:
hmm...
19:25:29
azunda:
i know 10M is not much for state sponsored attack
19:26:41
azunda:
instead of cap on block size, i would add code that increases fees exponentially when this 90 MB / bug area gets close
19:26:51
azunda:
for the time being- until it's fixed
19:27:13
azunda:
let's say at 20 MB even
19:27:29
azunda:
because we can't probably expect natural growth that fast
19:27:49
azunda:
so anything beyond 20 MB for the next - at least two years, is 99.999% attack
19:28:07
azunda:
i think it's enough time for some dev to fix that shit
19:29:39
azunda:
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:12
azunda:
this is not the first time they try to attack our principals
19:30:39
azunda:
you probably seen the spam on reddit with PoW change bullshit
19:32:10
nioc:
we already have a cap, in that if you reach it the network breaks
19:32:16
azunda:
the biggest advantage of Monero always was (in my opinion) - that it's protocol is not limited, only the underlying infrastructure
19:32:26
azunda:
lol yeah
19:32:40
nioc:
so protocol is limited
19:32:48
nioc:
always has been
19:32:48
azunda:
well yeah, but it's limited by a bug
19:33:07
nioc:
it was put in on purpose
19:33:15
azunda:
haha good one
19:33:23
ofrnxmr:xmr.mx:
It was
19:33:33
ofrnxmr:xmr.mx:
All cryptonote coins have the limit
19:33:43
ofrnxmr:xmr.mx:
Zano, monero, etc
19:35:07
ofrnxmr:xmr.mx:
what was monero's block size limit at genesis?
19:35:40
azunda:
don't remember
19:35:52
nioc:
I wasn't born yet
19:36:11
ofrnxmr:xmr.mx:
My point is that, if monero added dynamic block sizes, then monero adding them is the "bug"
19:36:27
ofrnxmr:xmr.mx:
As they were added, without regard for existong limits
19:37:07
azunda:
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:42
azunda:
ofrnxmr - probably so
19:37:50
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
19:38:34
ofrnxmr:xmr.mx:
Example: there is a 4mb limit on fluffyblock data
19:38:59
azunda:
that old code should be revisited but devs are pursuing newer tech instead of cleaning old shit
19:39:39
nioc:
yes because ring sigs are a weakness
19:39:48
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
19:40:02
nioc:
there is more work to be done than we have devs to do it
19:40:20
azunda:
yeah i know, but we have to have strong legs before doing upper part
19:40:55
nioc:
yes leg day b4 arm day :)
19:42:01
azunda:
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:02
nioc:
but somehow these new arms are now causing us to realize the importance of our legs
19:42:24
ofrnxmr:xmr.mx:
We should limit to 2.5mb since thats bigger than zcash's /s
19:43:09
azunda:
limit to 500 kb - we will finally flip Bitcoin
19:43:16
ofrnxmr:xmr.mx:
Monero scaling to 15mb in a day is too low
19:43:42
ofrnxmr:xmr.mx:
90mb blocks that will fracture the network are too low /s
19:44:27
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
19:45:20
azunda:
probably wouldn't hurt, but history of hard caps on other blockchains is not colorful..
19:45:44
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
19:45:49
azunda:
i know we can agree today, but i don't know if this agreement will hold tomorrow
19:45:51
ofrnxmr:xmr.mx:
azunda: This isnt bitcoin
19:46:08
azunda:
yes and no...
19:46:30
azunda:
if someone would fork Moner today (it's not early days of cryptonote) - then it would most probably fail
19:47:04
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
19:47:27
azunda:
hmm... yeah...
19:47:36
ofrnxmr:xmr.mx:
Also, i dont think we need to add a "hard" (consensus) cap
19:48:12
ofrnxmr:xmr.mx:
But just needs to be a default, like opcodes in btc.
19:48:26
azunda:
i like that
19:48:41
azunda:
gotta go, thanks for nice talk.
19:49:41
nioc:
how many hardforks has btc had?
19:49:59
dan:cypherstack.com:
0
19:50:23
nioc:
I asked the question for the person that just left :)
19:50:46
dan:cypherstack.com:
ah :)
20:08:12
rucknium:
https://blog.lopp.net/has-bitcoin-ever-hard-forked/
20:08:12
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.
20:10:30
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.
20:10:45
rucknium:
Interpret the facts as you will.
20:22:32
nioc:
1 HF is what I vaguely remembered as I don't pay close attention to corn
20:30:05
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)