13:13:36
articmine:
https://github.com/seraphis-migration/monero/issues/44
13:14:01
articmine:
I do believe we have consensus here.
13:14:32
articmine:
Correction m
13:19:09
articmine:
I do not believe we have consensus on the scaling parameters.
13:19:09
articmine:
We also may have a significant conflict of interest here, given the very radical counter proposal that was presented.
13:22:35
articmine:
https://github.com/monero-project/research-lab/issues/152
13:26:08
articmine:
In my view the real purpose of this simple proposal is to destroy the use of Monero as peer to peer cash in order to protect the interests of the Blockchain Surveillance (BS) industry
13:33:47
articmine:
Having lived through the destruction of Bitcoin as peer to peer cash I can see why Roger Very had to write Hijacking Bitcoin and expose the very significant conflict of interest in that project.
13:37:32
articmine:
Given the current lack of consensus on the scaling parameters it is best to leave them as is. As for the penalty free zone it should be increased to reflect the ratio of the before and after weight for a 2in 2 out transaction. So 1200000 bytes.
13:38:31
articmine:
This is the most common type of Monero transaction.
13:41:11
articmine:
Do we really peer to peer cash and privacy or or centralized ledgers and surveillance?
13:43:19
articmine:
Bitcoin has become the latter, Monero is still the former.
13:46:56
sashimi.:matrix.org:
while i dont really have the knowledge to fully understand those github threads
13:46:56
sashimi.:matrix.org:
the 1 piconero fee, i would think is "in favor of" p2p digital cash, at it would keep it low in fee to transact even with a price increase (still able to buy the daily coffee or whatever for less then $0.01)
13:46:56
sashimi.:matrix.org:
is the whole "flex space" thing is what literally happened to bitcoin tho?
13:46:56
sashimi.:matrix.org:
setting a fix blocksize limit (which in that case then yea, totally against p2p digital cash) and then some increase of it over the years type thing? if so then yea, dont like that lol
13:48:09
articmine:
The flex space is very similar to one of the proposals in Bitcoin
13:48:59
monero.arbo:matrix.org:
I'm reading your posts now Arctic and with respect, can you explain the reason why it must be 2x and can't be 1.7x?
13:49:03
monero.arbo:matrix.org:
(on 44)
13:51:34
articmine:
@monero.arbo:matrix.org: Because we have to allow scaling over a 3 to 6 month period that is at least comparable to what has occurred in Monero and other similar coins in the past
13:54:08
monero.arbo:matrix.org:
do we?
13:54:39
articmine:
There is of course also the issue of a death by a thousand cuts. We used to have no restrictions on scaling the short term median. The sky did not fall. Quite the opposite.
13:54:42
monero.arbo:matrix.org:
I don't think the network can handle 20x or 100x transactions in a 12-18 month period, even if scaling parameters allow it
13:55:17
articmine:
@monero.arbo:matrix.org: Why? Because of rot in the code?
13:55:18
monero.arbo:matrix.org:
which means, imo, scaling parameters shouldn't allow it. A short term fee market is more than acceptable, it's preferable
13:56:04
monero.arbo:matrix.org:
because FCMP transactions are really heavy in terms of compute requirements, and 100x would imply 2,000,000 transactions per day
13:56:06
monero.arbo:matrix.org:
2 million
13:56:58
monero.arbo:matrix.org:
like be for real, he network would fall apart under that load. or more likely, miners would have to produce smaller blocks even though the consensus would let them go bigger
13:57:13
monero.arbo:matrix.org:
but tons of peers would fall behind, unable to sync
13:57:28
articmine:
Then we should stay with RingCT until we are ready
13:58:24
monero.arbo:matrix.org:
maybe, I've been worried about the heaviness of fcmp transactions for awhile, but trying to allow 100x or even 20x scaling from current transaction volume over the course of just a few months is putting our own head in the noose
13:59:02
monero.arbo:matrix.org:
even Ethereum only does like 1.5 million per day
13:59:50
articmine:
@monero.arbo:matrix.org: ... and breaks blockchain surveillance with little if any privacy
14:00:59
articmine:
We can be prudent about this HF if we need to.
14:01:50
articmine:
We do not have to rush into FCMP++ before we are ready.
14:03:44
monero.arbo:matrix.org:
my understanding of Monero scaling has been thus: Long term, blocks should grow with demand. Short term, demand can outpace scaling parameters and create a temporary (e.g. until scaling catches up) fee market. I think growing the blockspace slowly is important to the stability of the network. It doesn't seem to me that it dema [... too long, see https://mrelay.p2pool.observer/e/uqbmgcsKamVDTXdk ]
14:04:43
boog900:
the scaling today on RingCT is too aggressive
14:04:59
monero.arbo:matrix.org:
I agree
14:05:03
boog900:
sticking with it is not a solution
14:05:46
articmine:
When demand has been suppressed for a decade, what happens if the suppression is removed?
14:06:23
articmine:
Do we suppress ourselves?
14:06:29
boog900:
yes
14:06:38
boog900:
staying alive ? dying
14:07:06
monero.arbo:matrix.org:
@articmine: enough to keep the network running smoothly, yes
14:07:06
articmine:
No caving in to the BS industry
14:07:17
articmine:
Bitcoin is dying
14:07:17
monero.arbo:matrix.org:
what use is 100x growth if it becomes unusable
14:08:06
monero.arbo:matrix.org:
I understand the concern but we're just talking about practical limits of what's possible
14:08:07
articmine:
What use is Bitcoin?
14:08:25
monero.arbo:matrix.org:
well I find a lot of use for Bitcoin but that's neither here nor there
14:08:44
articmine:
What is the use
14:09:29
articmine:
Case?
14:09:29
monero.arbo:matrix.org:
on and off ramping, mostly. I can onboard people through apps like cashapp, that they already have. that's huge. but it's also kinda beside th epoint
14:09:36
boog900:
My opinion is that the limits should be decided by the limits of the system (at least on the months scale), then we can have spam prevention to stop short term extreme growth upto that limit.
14:10:15
boog900:
not by trying to find how much growth is needed as that can be changed by so many factors
14:10:28
monero.arbo:matrix.org:
that's my take as well
14:11:05
articmine:
@boog900: This is what I proposed and was shot down because of the long term threat to the BS industry
14:11:51
monero.arbo:matrix.org:
you are trying to propose being able to scale up to 100x in 18 months
14:12:01
monero.arbo:matrix.org:
that's so far past the limit of the system
14:15:18
articmine:
I MB in 2008 when the Bitcoin whitepaper was released is like 1GB today
14:16:46
articmine:
Are you saying peer to peer cash is not viable?
14:17:50
boog900:
with current tech in monero onboarding the world is not possible, no
14:18:30
articmine:
Then we cannot be increasing the burden
14:18:51
boog900:
exactly so lets lower the growth rate lol
14:19:23
articmine:
No let's stop the bloat
14:19:33
monero.arbo:matrix.org:
it's not really a bandwidth issue or storage issue imo, at least not primarily. it's a compute issue. have you tried syncing fcmp stressnet yet? > <@articmine> I MB in 2008 when the Bitcoin whitepaper was released is like 1GB today
14:19:57
boog900:
I think the increase in privacy is well worth the decrease is txs per MB
14:20:01
sashimi.:matrix.org:
might not be able to compete to mastercards level (50k/s) but i think visa levels (3k/s) should be able to
14:20:01
sashimi.:matrix.org:
i dont remember numbers from the stresstests a long while ago for monero, was it 1700/s or something like that? or i completely misremembering there
14:20:03
articmine:
Then FCMP has to wait
14:20:33
boog900:
who is for BS again?
14:20:49
articmine:
What is the point if people cannot use it?
14:21:08
boog900:
people can
14:21:19
boog900:
just like with RingCT the whole world can't
14:21:41
testtank:matrix.org:
Artic , if monero isn’t used by half the population and doesn’t have 10 millions daily transaction, it doesn’t mean that it failed, monero is already sucessfull it has just to stay alive for the people who need to use it
14:21:51
articmine:
@boog900: ... But you agree it is lightrt
14:22:04
monero.arbo:matrix.org:
yeah if we get too successful I don't see how we avoid needing a level 2. the blockchain trilemma still exists
14:22:06
articmine:
Lighter
14:22:33
monero.arbo:matrix.org:
@articmine: for sure, it's a question of tradeoffs, we all get that
14:22:41
articmine:
BS cannot scale at all
14:22:44
boog900:
@articmine: absolutely, but FCMP doesn't take us to our limit with current tx rates, we still have a lot of growth that we can do
14:23:18
articmine:
So we are better off staying with RingCT
14:23:35
monero.arbo:matrix.org:
@boog900: yup, and FCMP scaling will get better with time. even with zero optimizations, hardware continues to get more powerful and more widely available. but we still need to be cognizant of near term limitations
14:24:11
boog900:
@articmine: why? we have capacity to grow with FCMP still
14:24:15
monero.arbo:matrix.org:
@articmine: if you want to prioritize maximum room for growth, then yes, and we should also decrease the ring count for that matter
14:24:16
monero.arbo:matrix.org:
again, it's a question of tradeoffs
14:24:31
boog900:
fuck it ring size 1
14:24:33
redsh4de:matrix.org:
@boog900: Isn't it possible to reduce TX sizes in the future for FCMP++ with Curve Forests as well? 60% reduction in proof size + verification speed ups by 2-3x or something
14:24:33
redsh4de:matrix.org:
And Bulletproofs++ (instead of +) can reduce current BP proof sizes by 38%
14:25:07
boog900:
back to ring sigs instead of ringCT ...
14:25:43
articmine:
The prudent course of action is to stay where we are and focus bon code optimization instead
14:25:55
monero.arbo:matrix.org:
@boog900: fuck it let's just go fully transparent like BTC for maximum scaling
14:26:07
monero.arbo:matrix.org:
cashfusion is good enough
14:26:37
boog900:
@monero.arbo:matrix.org: why decentralization? centralization allows more growth
14:26:50
articmine:
We have decent privacy where we are now
14:27:47
articmine:
We are better off privacy wise scaling what we have
14:27:51
sashimi.:matrix.org:
(just for the record, the p2p market i have in mind to onboard, which would still take a long long while to do so, would probably be at best 0.5tx/s if fully onboarding it, which pretty much monero already can do that and would be able to do that with fcmps too as of right now, but that market itself could also grow overtime, it's still years away regardless anyways)
14:28:01
boog900:
@articmine:monero.social: I would agree with you if FCMP took us right to the limit or close to it with current tx rates, but it doesn't.
14:28:47
articmine:
... but current tx rates are the result of external suppression
14:29:04
monero.arbo:matrix.org:
I wonder if you could do like HCMP (half chain) or even less and be more efficient, hmmm
14:29:20
hardhatter:
> <@boog900> just like with RingCT the whole world can't
14:29:21
hardhatter:
Currently there’s no immediate need for that level of capacity for monero, but splitting the networks into separate instances of the currency for separate consensus would also work if there’s there enough demand to resort to that and if there’s no clear approach to improve efficiency or hardware capacity on a monolithic consensus model at the time
14:29:41
boog900:
@articmine: yeah and what says that without suppression RingCT is too heavy and we need to go the ring sigs?
14:30:18
articmine:
Yes an option FCMP with limited scaling is an option
14:30:38
articmine:
As an opt in
14:31:13
articmine:
@boog900: This has not been proven
14:31:33
boog900:
@articmine: EXACTLY
14:31:59
boog900:
neither has FCMP being too heavy with no suppression
14:32:25
boog900:
we are talking about made up scenarios that fits exactly into your argument
14:32:49
articmine:
@boog900: So why bake in the suppression into the consensus
14:32:58
monero.arbo:matrix.org:
Right now is about the "lightest" Monero has ever been relative to "current" hardware. We definitely have room, if that's the metric.
14:33:26
hardhatter:
@Lyza what are you disagreeing with? Not having an immediate need? Cause clearly a centralized consensus is a technical bottleneck. I’m not saying splitting consensus is ideal. It’s just obviously going to increase throughput
14:33:29
monero.arbo:matrix.org:
@articmine: because scaling is limited by reality and some of us want the scaling model to stay within the bounds of reality
14:33:37
boog900:
@articmine: we are allowing growth ....
14:33:40
monero.arbo:matrix.org:
otherwise fuck it, unlimited block size
14:34:30
sashimi.:matrix.org:
@monero.arbo:matrix.org: what are the current numbers right now for ringCT and FCMPs that are "within the bounds of reality"?
14:34:31
monero.arbo:matrix.org:
@hardhatter: splitting the network is one of the things we'd most like to avoid. it's not good for anyone
14:34:34
articmine:
@monero.arbo:matrix.org: At least this allows the market to deal with it
14:35:18
hardhatter:
@monero.arbo:matrix.org: I agree with that. That’s why said if “we had to resort to it”
14:35:35
monero.arbo:matrix.org:
@sashimi.:matrix.org: well, judging by my experience with FCMP stressnet, whatever transactions per day they've been doing (idk off the top of my head) is butting up against the limit. People are syncing 2 or 3 blocks per minute on typical hardware
14:35:46
articmine:
We do not have consensus for change so we stay as we are
14:36:19
articmine:
When we get consensus then we change
14:36:50
monero.arbo:matrix.org:
@articmine: I mean, we've never let one person block consensus and I don't think we would now. what are are doing right now is trying to come to consensus, so fi you could participate in that instead of basically saying "my way or nothing" that would be great
14:37:05
boog900:
I think we can move if everyone agrees but 1 person
14:37:23
quadriocellata:matrix.org:
wouldn't it be wise to bake in suppression to what is feasible with current hardware? to allow growth but not uncapped growth ? > <@articmine> So why bake in the suppression into the consensus
14:38:15
articmine:
@quadriocellata:matrix.org: You mean like Bitcoin
14:39:20
boog900:
FCMP will be the biggest upgrade to monero in a while, preventing it because it doesn't allow growth you think is acceptable is silly. What makes your numbers so special?
14:39:36
redsh4de:matrix.org:
As an outside observer, i see both sides of the argument. Scaling is very important, but i also think there is no need to delay privacy tech FCMP++ and Carrot further right when we are at the finish line.
14:39:36
redsh4de:matrix.org:
Yes, at the moment we cannot scale to global scale. And that should absolutely be worked towards, but Monero currently does not have that demand or usage - and likely wont for the next few years until we at least have easier onramp methods and accessibility.
14:39:36
redsh4de:matrix.org:
We’ll still have room to scale and reduce TX sizes afterward by upgrading proof systems to more efficient ones (Curve Forests, BP++, or whatever comes next) and by adjusting protocol parameters. None of that requires delaying FCMP++ today.[... more lines follow, see https://mrelay.p2pool.observer/e/9tHpgssKVjRyXzdz ]
14:39:53
quadriocellata:matrix.org:
@articmine: it doesn't have to be that capped, but we have to work within the limitations until things catch up ? wouldn't we have a big problem if the growth became too high ?
14:40:05
articmine:
@boog900: There has been no growth in like 6 years
14:40:19
monero.arbo:matrix.org:
@articmine: yes, we are making the same tradeoffs ass bitcoin. We made different tradeoffs, yes, but it's the same dilemme. or trilemme if you will. Monero is heavier than Bitcoin, that's just how it is, but we still have to work within reality
14:40:30
boog900:
@articmine: yeah and what if we get 1000000x growth tomorrow?
14:40:50
articmine:
@boog900: We don't have that
14:40:51
quadriocellata:matrix.org:
you should imagine there would be consensus in the future to allow further growth when the hardware etc catches up
14:41:12
sashimi.:matrix.org:
@boog900: consensus as of right now is the few devs over the ccs that have a voice for consensus
14:41:12
sashimi.:matrix.org:
while not every voice should matter, miners and whales imo should be able to have a voice (whatever the weight of that voice) regarding drastic changes to the protocol
14:41:16
testtank:matrix.org:
@articmine: How do you know?
14:41:21
boog900:
predicting the future is impossible so its not like you know what will happen if monero gets listed on exchanges again or whatever
14:41:28
articmine:
@quadriocellata:matrix.org: No. Vested interests get in the way
14:41:54
monero.arbo:matrix.org:
@sashimi.:matrix.org: more people will chime in as changes inch towards release. people who are choosing not to participate now will still have time to push back
14:42:31
articmine:
We have users
14:42:50
articmine:
We have the silent majority
14:43:08
boog900:
I am happy to listen to good arguments, but creating hypothetical futures where the growth is perfect for ringCT, not too much, but too much for FCMP is not a good argument.
14:43:34
boog900:
when that future is just a hypothetical
14:44:34
articmine:
While we argue the goalposts are changing in our favor
14:45:06
articmine:
So prudence here makes a lot y sense
14:45:53
articmine:
We don't have to rush into this
14:46:14
boog900:
exactly why we are here talking
14:46:39
boog900:
but you haven't managed to convince me we are going to grow into that perfect zone
14:46:40
testtank:matrix.org:
I find it funny, that you would prefer delaying FCMP++, which would basically make monero 100% safe from blockchain survilance companies, rather then not using your scaling params, because the BS companies would “win”
14:47:47
monero.arbo:matrix.org:
@testtank:matrix.org: there is some merit to the concern that if most transactions happen on centralized ledgers (e.g. exchanges and other companies) than the on chain privacy is much less effective
14:47:50
monero.arbo:matrix.org:
but I agree
14:51:02
testtank:matrix.org:
@monero.arbo:matrix.org: Unfortunately/fortunately (depends on who you ask) i don’t think we have to worry about xmr being listed on CEX’s
14:51:06
sashimi.:matrix.org:
@sgp_:monero.social: thanks for joining the conversation, your github thread: https://github.com/monero-project/research-lab/issues/152 is what's being discussed rn i guess
14:52:08
redsh4de:matrix.org:
@testtank:matrix.org: Im assuming the argument is that if in the future the demand increases to high levels for Monero but it doesnt scale well to demand, that would be good for blockchain surveillance companies - layer 2s and other centralized things can come into play
14:52:08
redsh4de:matrix.org:
I guess it boils down to this: In what time horizon do we believe Monero usage and demand would increase to such levels where scaling becomes important
14:52:08
redsh4de:matrix.org:
I personally think that we have a lot of other things to figure out before increased demand and thus scaling becomes a problem - onramp, accessibility, surpression etc. Since that gives time to scale after, privacy improvements should be prioritized.[... more lines follow, see https://mrelay.p2pool.observer/e/1ZiXg8sKUFBYVTBK ]
14:53:26
sgp_:
ArticMine if blockchain surveillance is as terrible as you say, why shouldn't Monero drop all the privacy tech, make transactions bitcoin-like and efficient, while keeping a generous growing block size to promote capacity? What's your argument against that if capacity is king?
14:53:49
sgp_:
Why let privacy slow us down at all, accepting that view?
14:55:24
articmine:
@sgp_: There is actually a case for privacy by growth
14:55:48
sgp_:
So privacy is important because it induces demand?
14:56:27
articmine:
One gets privacy as a result of growth
14:57:11
sgp_:
@articmine: Right so accepting that, why not go 100% on efficiency and growth? Drop FCMP and ringct
14:57:41
articmine:
There are tradeoffs
14:58:40
monero.arbo:matrix.org:
ArcticMine can we agree that short-medium term growth should be bounded by some kind of reasoned analysis of what the network can handle and what the effect on users might be at more/less aggressive growth rates?
14:59:48
articmine:
@monero.arbo:matrix.org: One can let the market deal with this.
15:00:10
articmine:
Better than a hard coded limit
15:00:11
monero.arbo:matrix.org:
How can the market deal with node hardware requirements?
15:00:38
articmine:
Node limit relay
15:00:49
boog900:
you can't allow the market to deal with consensus rules
15:00:57
boog900:
thats how you get chain splits
15:01:13
hardhatter:
> <@monero.arbo:matrix.org> there is some merit to the concern that if most transactions happen on centralized ledgers (e.g. exchanges and other companies) than the on chain privacy is much less effective
15:01:13
hardhatter:
What’s the deanonymizing attack vector if a large enough minority of on chain transactions are not from colluding entities for FCMP++? I was under the impression the possible signers that could be inferred in that case would reduce to transactions signed by non-colluding entities presently on the chain so far
15:01:45
testtank:matrix.org:
https://mrelay.p2pool.observer/m/matrix.org/uRjSpbBkzaVNyAIaARWHEXlL.jpeg (90a429d4-af24-4beb-bb05-a38c06cad027.jpeg)
15:01:59
articmine:
@hardhatter: Shared secrets
15:02:07
boog900:
@boog900: which allow double spends FWIW
15:02:42
monero.arbo:matrix.org:
@hardhatter: they'll just literally have their own records, makes things like amount correlations and timing attacks infinitely easier. it's nothing really to do with chain security at that point
15:02:56
hardhatter:
@monero.arbo:matrix.org: Oh good
15:04:01
sgp_:
Fwiw I definitely don't support dropping FCMP, I just see it as a way preferable solution to privacy than trying to outrun the bounds of what can be analyzed by volume
15:04:15
hardhatter:
There’s more manageable approaches to deal with timing and correlation attacks in that case
15:04:29
sashimi.:matrix.org:
@sgp_: fwiw delaying dont mean dropping
15:05:03
sgp_:
I don't think anyone besides ArticMine would be sad if we cut their max growth rate by 90% tbh
15:05:22
monero.arbo:matrix.org:
Is there anyone present with enough knowledge to know if FCMP is all or nothing? e.g. can we have "half" chain membership proofs and gain anything from it?
15:06:48
boog900:
@monero.arbo:matrix.org: even if this allowed us to reach @articmine:monero.social's numbers why does it matter?
15:07:02
boog900:
they arn't special
15:07:02
kayabanerve:matrix.org:
I am strongly against forgoing required technological progress for the idea of scaling. As a comparison, Monero may NEED to upgrade to post-quantum cryptography in the next few years, which will likely have much larger proofs. We will not have the ability to forgo that out of preference and will have to accept the limitations of our technology and the impact on scaling.
15:07:45
kayabanerve:matrix.org:
It's with that in mind we must turn to technology for more efficient solutions, whether on the protocol level with our proofs, or on the implementation level with all the great work the stressnet has done.
15:08:04
sgp_:
Personally I always value security and privacy above scaling. Scaling comes a distant third to me
15:08:05
kayabanerve:matrix.org:
As for if complete membership privacy is 'necessary'... obviously? There's more than enough issues with rings.
15:08:18
articmine:
@sgp_: N!/((N-K)!K!)). Is not order of K
15:09:03
kayabanerve:matrix.org:
Also, @jberman:monero.social: with a few weeks of review and myself with a couple days of work off of that reduced the memory use by 5x, and we already have a known ECC solution for effectively constant membership proof size (w.r.t. amount of inputs).
15:09:29
sgp_:
It's more important to get privacy right than to try to compete with Visa's scale
15:09:45
articmine:
@sgp_: Actually no
15:10:01
monero.arbo:matrix.org:
@boog900: I just like to know what the options / tradeoffs are, and I do have a concern with how heavy fcmp is on testnet
15:10:31
articmine:
The binomial coefficient does not scale lineraly
15:11:18
articmine:
@kayabanerve:matrix.org: My point is give this a chance frst
15:11:38
sashimi.:matrix.org:
@sgp_: visa scales would increase the pool of users which is shared with fcmps so more users also means more privacy there
15:11:38
sashimi.:matrix.org:
but i agree with kaya, those are changes that needs to be made eventually
15:11:38
sashimi.:matrix.org:
it just sucks that the tech itself is not there yet, but it is how it is i guess
15:11:43
articmine:
We do not have to rush
15:12:07
kayabanerve:matrix.org:
Give what a chance? We already put in the work on reducing memory and already have a stable candidate in combination with the necessary fixes to monerod itself
15:12:17
monero.arbo:matrix.org:
I wouldn't say we are rushing
15:12:20
monero.arbo:matrix.org:
nobody even set a date
15:12:45
kayabanerve:matrix.org:
The entire stressnet is taking our time and ensuring stability, without rushing it.
15:13:06
hardhatter:
Isn’t there a reasonable point at which the timeframe/block length is large enough to where it’s likely there’s atleast enough transactions from non-colluding entities within it to be reasonably secure? > <@kayabanerve:matrix.org> As for if complete membership privacy is 'necessary'... obviously? There's more than enough issues with rings.
15:13:52
kayabanerve:matrix.org:
yeah, I'd say the entire blockchain @hardhatter:monero.social would be fine
15:13:55
kayabanerve:matrix.org:
:p
15:14:13
hardhatter:
I mean genuinely do you think that?
15:14:32
articmine:
@kayabanerve:matrix.org: Even if there is a miniscule number of outputs
15:14:36
sgp_:
Another question is if you think ringct is good enough rn
15:14:45
sgp_:
Because that's what it is
15:14:49
kayabanerve:matrix.org:
Eh, if we had OSPEAD and Seraphis-style rings, we could continue playing the cat and mouse game where we can say it may be 'decent' but we'll still have targeted attacks and can never know for sure.
15:15:37
kayabanerve:matrix.org:
But that's the issue. It's never actually private to my standards. It's just 'fine' if you aren't targeted. That shouldn't be the promise nor the goal of Monero.
15:16:00
hardhatter:
@sgp_: I mean ringct has a dramatically smaller number of possible signers though for each transaction?
15:16:17
articmine:
@kayabanerve:matrix.org: Surveillance scales with order of a^k vs k for the chain itself
15:16:25
sashimi.:matrix.org:
@sgp_: ringct overstayed its welcome at this point, considering triptych was a thing being considered at one point, fcmp just has to come out eventually
15:16:37
sgp_:
@hardhatter: For targeted, it doesn't matter much even if you 10x or 100x
15:17:12
kayabanerve:matrix.org:
I think the best argument for scaling is layer twos and am disappointed the current discussion is on trying to place everyone's transactions onto each individual's device (n -> 1) instead of distributed solutions FWIW.
15:17:53
monero.arbo:matrix.org:
I concur the eventual need for L2s seems to come with success
15:18:00
hardhatter:
@sgp_: I mean I’m just asking if there’s a limit where it’s enough. If 100x isn’t enough then sure it’s not enough. Is there a point where it is?
15:18:06
kayabanerve:matrix.org:
@articmine:monero.social: There's been research into churning and it continues the cat and mouse game I described above. Why should we bicker about exactly how bad the privacy is (fine or not), when there's known fundamental attacks regardless?
15:18:19
articmine:
Banking is a layer 2
15:18:35
sgp_:
@hardhatter: Not really unfortunately, unless you lower your standards to not protect targeted
15:18:59
kayabanerve:matrix.org:
A centralized, trusted L2 when using succinct proofs, we could have a L2 with the same security and decentralization as the L1.
15:19:44
articmine:
So a trusted bank?
15:19:54
hardhatter:
@sgp_: I see, that’s unfortunate for scaling then
15:20:19
sashimi.:matrix.org:
@kayabanerve:matrix.org: MoNet:
15:20:19
sashimi.:matrix.org:
https://eprint.iacr.org/2022/744
15:20:19
sashimi.:matrix.org:
Grease:
15:20:19
sashimi.:matrix.org:
https://github.com/grease-xmr/grease
15:20:20
sashimi.:matrix.org:
(just for context, dont mind me lol)
15:20:28
kayabanerve:matrix.org:
It's unfortunate for this notion and discussion on scaling @hardhatter:monero.social:
15:20:42
sgp_:
Scaling has many more options than just txs on the chain itself
15:21:03
articmine:
@sgp_: You have to find targeted first
15:21:26
hardhatter:
@kayabanerve:matrix.org: I’m not one of the scaling bulls in this discussion haha But it still matters
15:23:19
articmine:
By the way finding targeted is the fundamental reason blockchain surveillance doi not scale
15:23:43
sashimi.:matrix.org:
@articmine: i mean, centralized exchanges can be considered "L2" at this point... it's all offchain...
15:24:38
articmine:
@sashimi.:matrix.org: Of course which is why restrictions t scaling layer 1 are paramount for blockchain surveillance
15:25:44
hardhatter:
@sgp_: Okay I see your point but then we’ll need guidelines for off chain privacy for people, so that leveraging more guaranteed privacy on chain remains effective between the two
15:26:51
kayabanerve:matrix.org:
Or creating L2s with equivalent properties to the L1?
15:27:16
sashimi.:matrix.org:
^ that would be the proper way to have L2 imo
15:27:43
articmine:
@kayabanerve:matrix.org: How is this even theoretically possible?
15:28:03
sashimi.:matrix.org:
@articmine: https://eprint.iacr.org/2022/744
15:28:03
sashimi.:matrix.org:
https://github.com/grease-xmr/grease
15:28:15
kayabanerve:matrix.org:
... that's the entire point of L2 theory?
15:28:44
kayabanerve:matrix.org:
You can create a succinct proof of the state of a network allowing verification, and enforcement, of it without processing it itself
15:28:46
hardhatter:
@kayabanerve:matrix.org: L2s with equivalent properties wouldn’t have the same scaling problems? Since my reply was to sgp’s suggestion that off chain is the solution to scaling
15:29:01
kayabanerve:matrix.org:
It removes the computational burden from the L1
15:29:39
kayabanerve:matrix.org:
Then there's solely the data burden, which is not only easier to handle when you just have to build a solution specifically for archiving data, but potentially also outsourceable
15:30:01
kayabanerve:matrix.org:
See payment channels where the L1 doesn't receive the state, solely the participants
15:30:32
articmine:
The same transaction throughout as the Bitcoin Lighting network? Seriously
15:31:43
articmine:
Define what this transaction rate is, and the required settlement rate on layer 1
15:32:37
sashimi.:matrix.org:
@articmine: bitcoin failed on that imo by having limitation in the code for its L1, literally preventing scaling on L1
15:32:37
sashimi.:matrix.org:
monero could have properly designed L2 without doing the same mistake bitcoin did
15:33:27
sashimi.:matrix.org:
and instead of limitation from the code, it would be just a tech limitation from hardware in case of monero
15:34:13
redsh4de:matrix.org:
Can something like this be done for the L1? So that instead of having to compute every block data, a proof is verified that a block is valid > <@kayabanerve:matrix.org> You can create a succinct proof of the state of a network allowing verification, and enforcement, of it without processing it itself
15:34:13
redsh4de:matrix.org:
Would that have any positive properties beyond loweing the node hardware requirements
15:35:40
articmine:
@sashimi.:matrix.org: A code limitation based upon the tech at a given point in time
15:36:00
hardhatter:
@kayabanerve:matrix.org: Makes sense, but then isn’t this a little too similar to many people’s issue with decentralizing consensus? The L2 is basically a bunch of separate consensus networks. But I get the benefit of still having the L1 there to link them back
15:36:14
articmine:
I am old enough to have programmed using punch cards
15:36:44
boog900:
monero punch card rewrite?
15:37:02
kayabanerve:matrix.org:
@sashimi.:matrix.org: I have an open issue for explicit support of a competent design
15:37:24
kayabanerve:matrix.org:
@redsh4de:matrix.org: This is just scaling the L1 using the same techniques
15:37:38
sashimi.:matrix.org:
@kayabanerve:matrix.org: link?
15:37:47
kayabanerve:matrix.org:
@hardhatter: Not really, as they resolve to the L1 consensus
15:38:43
kayabanerve:matrix.org:
https://github.com/monero-project/research-lab/issues/129
15:38:45
articmine:
Yes now the POS debate
15:39:04
kayabanerve:matrix.org:
@articmine:monero.social: That's a separate discussion
15:39:23
kayabanerve:matrix.org:
Bitcoin obviously has Lightning with PoW
15:39:46
monero.arbo:matrix.org:
it IS annoying to be like, oh are you sending Eth on Eth, are you sending Eth on Poly, are you sending Eth on Optimism? Oh damn my exchange doesn't support Eth on Arbitrium.
15:39:46
monero.arbo:matrix.org:
It's a UX nightmare to have level twos be that sharded, for sure
15:40:03
kayabanerve:matrix.org:
Agree UX can be difficult, though there's extensive work to improve that in the Ethereum eco
15:40:21
kayabanerve:matrix.org:
Just as privacy's UX can be difficult and we've done extensive work there
15:40:58
monero.arbo:matrix.org:
yeah I think we are stuck with L2s (if we're lucky enough to be so successful), I'm just sayin
15:41:03
rottenwheel:unredacted.org:
@testtank:matrix.org: First time? lol
15:41:10
articmine:
Payment channels have been deemed money transmission
15:41:23
kayabanerve:matrix.org:
We cannot fit 7 billion users' transactions onto the devices of each of their users.
15:41:53
articmine:
They can be part of the solution but are not a replacement for level 1 scaling
15:41:53
kayabanerve:matrix.org:
We can fit settlement proofs of 7 billion users' transactions onto the devices of each of those users
15:42:30
kayabanerve:matrix.org:
Yes but the goal of L1 scaling cannot be everything
15:42:33
kayabanerve:matrix.org:
It must be sufficiency
15:42:36
redsh4de:matrix.org:
@articmine: Agree
15:42:57
kayabanerve:matrix.org:
The work we're doing will create a more than sufficient result
15:43:05
kayabanerve:matrix.org:
We shouldn't block L1 progress in the name of the impossible
15:43:15
articmine:
Fair enough. Make it work > <@kayabanerve:matrix.org> We can fit settlement proofs of 7 billion users' transactions onto the devices of each of those users
15:43:27
lm:matrix.baermail.fr:
Jus a interjection: if today BS are making txs on chain to reduce the level of ringct, implementing fcmp would actually decrease current tx/day and make more room for everyone
15:44:11
articmine:
@lm:matrix.baermail.fr: They can try but it doesn't work
15:45:24
lm:matrix.baermail.fr:
@articmine: That was the fear when we had the spam episode
15:46:23
articmine:
There is a lot of FUD regarding spam in Monero
15:46:36
lm:matrix.baermail.fr:
Nothing prevents a BS to do it again, I think that's even why seraphis was abandoned for fcmp++
15:47:36
sashimi.:matrix.org:
spam literally did happen tho, wouldnt consider it just a "FUD" tbh
15:48:50
articmine:
@sashimi.:matrix.org: It stopped at the scaling. This is why the vulnerabilites in the code were not triggered
15:49:27
boog900:
bugs in the wallet was found though
15:49:48
sashimi.:matrix.org:
it stopped but still impacted regular users with their transactions not able to be included in blocks
15:49:48
sashimi.:matrix.org:
if you care about p2p digital cash, best UX possible with less "downtimes" for users is also to keep in mind
15:49:52
articmine:
@boog900: As a result of stress net
15:49:58
boog900:
no
15:50:18
articmine:
So it was fixed
15:50:24
boog900:
in the real spam we had last year (?) wallets were not setting their fee correctly IIRC
15:51:03
articmine:
Yes there was no recommendation
15:51:32
monero.arbo:matrix.org:
not having RBF is really the worst part about Monero having a transaction backlog
15:51:51
boog900:
but the argument was more about how the current tx rate could drop with FCMP, if BS are trickling txs now to try own a lot of the outputs
15:51:53
monero.arbo:matrix.org:
that's how transactions get stuck. "wrong fees" are gonna happen regardless if TX volume is high enough
15:53:21
articmine:
@monero.arbo:matrix.org: If the node relay fees are set properly and the recommendations are set properly this can be fixed
15:53:52
articmine:
It is not even a consensus issue
15:54:36
boog900:
it still prevented prevented scaling as fees were too low
15:54:42
boog900:
and thats a critical issue right?
15:54:51
boog900:
we should have died right?
15:55:24
articmine:
@boog900: It slowed it down.
15:55:35
articmine:
It does not prevent scaling
15:55:45
boog900:
as so slow scaling is ok now?
15:55:47
monero.arbo:matrix.org:
the issue is that you might think a fee is high enough, then after you send the transaction, but before it gets mined, a bunch of new transactions show up in the mempool and your fee is no longer high enough > <@articmine> If the node relay fees are set properly and the recommendations are set properly this can be fixed
15:55:54
monero.arbo:matrix.org:
this can't be fixed with better software
15:56:15
monero.arbo:matrix.org:
you can't see what the future mempool will be
15:56:42
articmine:
What killed Bitcoin is consensus changes to prevent scaling
15:58:17
articmine:
@monero.arbo:matrix.org: This is not a consensus issue
15:58:35
sashimi.:matrix.org:
thought was the other way around
15:58:35
sashimi.:matrix.org:
blocksize limit was added in late 2010 or so
15:58:35
sashimi.:matrix.org:
then the blocksize war happened later, since couldnt get to the consensus of making the actual changes
15:58:35
sashimi.:matrix.org:
so the limit stayed
15:59:07
monero.arbo:matrix.org:
@articmine: right, my point is that consensus can't fix the issue of transactions getting stuck
16:00:09
articmine:
@sashimi.:matrix.org: Which is why consensus limits on scaling are so dangerous
16:00:45
monero.arbo:matrix.org:
right, that's the whole point of having a dynamic block size
16:00:57
articmine:
@monero.arbo:matrix.org: Exactly
16:01:09
monero.arbo:matrix.org:
but we're talking about short term limits within that dynamic system
16:01:39
sashimi.:matrix.org:
@monero.arbo:matrix.org: for bitcoin it was supposed to be temporary as well, short term to prevent spam
16:01:52
articmine:
We are talking about long term consensus rules
16:02:08
sashimi.:matrix.org:
i guess point is that, when limit is introduced then it will be harder later on to get consensus to remove the limit
16:02:18
hardhatter:
I mean overall I agree with you about this and with why it’s useful to have the L1 there to further secure the consensus done on networks on the L2 > <@kayabanerve:matrix.org> Not really, as they resolve to the L1 consensus
16:02:18
hardhatter:
but some individual L2 networks are going to have less secure consensus inherently due to their smaller size before it reaches the L1. I don’t really have any problem this. People just need to be cognizant of the risks. But I think there are people who will have a problem conceptually with this.
16:02:18
hardhatter:
Personally I think the level of decentralized consensus here is very similar to what some people have a problem with (i don’t necessarily). But consensus additionally resolving back to L1 greatly improves stability of the L2 economy.
16:02:43
monero.arbo:matrix.org:
@sashimi.:matrix.org: not the same sort of "temporary" --- the argument is about how fast to let scaling happen. literally nobody is arguing for BTC style hard limits
16:03:11
articmine:
@sashimi.:matrix.org: So one fights the introduction of the limit into consensus in the first place
16:03:15
hardhatter:
Do we have any models about how the L1 will scale relative to the L2 in with this set up? Cause that might still end up being a problem down the line?
16:03:45
nioc:
silent majority here :) I agree with the perspectives presented by monero.arbo , boog900 and others and believe that they understand the valid points made by articmine
16:03:59
sashimi.:matrix.org:
@monero.arbo:matrix.org: then yall math guys need to get some actual numbers and figure what those limitations are
16:03:59
sashimi.:matrix.org:
today's discussion didnt have much numbers...
16:04:02
kayabanerve:matrix.org:
@hardhatter:monero.social: I don't think you understand how consensus works with a proper L2. Its consensus _is_ the L1's.
16:04:07
nioc:
<kayabanerve:matrix.org> Eh, if we had OSPEAD and Seraphis-style rings, we could continue playing the cat and mouse game where we can say it may be 'decent' but we'll still have targeted attacks and can never know for sure.
16:04:07
nioc:
<kayabanerve:matrix.org> But that's the issue. It's never actually private to my standards. It's just 'fine' if you aren't targeted. That shouldn't be the promise nor the goal of Monero.
16:04:18
nioc:
thumbup ^^
16:04:57
monero.arbo:matrix.org:
@sashimi.:matrix.org: For sure, analysis would be extremely good to do/have, but also hard to do when fcmp is changing so fast.
16:05:04
rottenwheel:unredacted.org:
speaking of L2, what's the status of the L2 announced by... Idk who anymore at MoneroKon 5?
16:05:13
monero.arbo:matrix.org:
a lot of optimizations have been / are being made still
16:05:15
rottenwheel:unredacted.org:
where are these great fellows? are they in this room?
16:05:40
DataHoarder:
this, rottenwheel? https://github.com/grease-xmr/grease
16:05:56
rottenwheel:unredacted.org:
DataHoarder: correct! grease!
16:06:31
hardhatter:
@kayabanerve:matrix.org: yea I might have misunderstood the type of L2 network you’re talking about. I’m not sure exactly which one you have in mind so I made an assumption
16:06:35
rottenwheel:unredacted.org:
apparently neither are on Matrix. :(
16:09:00
articmine:
@05monero.arbo:matrix.org: Actually some people have proposed a rigid simple proposal that amounts to the same thing. Even worse if on factors in the proposed difference in transaction weights
16:09:27
hardhatter:
If consensus completely resolved on the L1 a the moment im confused how the bottle neck is adequately resolved. I get there will be some computational burdens lessened but not asymptotically I imagine
16:10:04
articmine:
We cannot ignore the human element here
16:13:06
monero.arbo:matrix.org:
for reference, checking the stressnet channel, seems like we were doing 100k per day there. I have an older quad core laptop that was keeping up but like, idk just 2 or 5 blocks per minute. that's on the latest release, 1.4. just to give a ballpark idea. I recommend everyone taking part in this discussion try it for themselves tbh
16:13:27
sashimi.:matrix.org:
@03hardhatter: i think: https://github.com/monero-project/research-lab/issues/129
16:13:27
sashimi.:matrix.org:
is too techy for me so i cant speak on that, but that might have been what he's been talking about
16:14:26
hardhatter:
Ahh yea I should’ve checked that link he sent thanks
16:14:47
articmine:
@monero.arbo:matrix.org: 100k on FCMP?
16:14:58
monero.arbo:matrix.org:
@articmine: according to you (:
16:15:19
monero.arbo:matrix.org:
I never checked the numbers but it's what you had said at some point
16:15:35
monero.arbo:matrix.org:
err, sorry ofrnxmr said that
16:15:45
monero.arbo:matrix.org:
my bad
16:16:28
ofrnxmr:
100k tx/day?
16:16:39
monero.arbo:matrix.org:
yes
16:16:48
articmine:
Yes like 4x current
16:16:54
ofrnxmr:
And more, yea
16:18:04
ofrnxmr:
probably got well over 500k (700 tx/block)
16:19:34
monero.arbo:matrix.org:
nice, but yeah, my experience with testnet is that feels like it's near the limit for current consumer hardware. and if anyone hasn't tried syncing it themselves, please do
16:19:36
articmine:
so like 6 NB
16:19:43
articmine:
MB
16:20:14
ofrnxmr:
The reported block sized are not right on current stressnet (sum of txs is less than reported block size)
16:20:22
ofrnxmr:
So im not actually sure the real block size
16:21:46
articmine:
500 K transactions per day is like 25x. the current rate
16:22:14
monero.arbo:matrix.org:
yes
16:22:24
articmine:
So I am not that far off after all
16:22:40
monero.arbo:matrix.org:
I would be okay with growing fast up to that point, then slowing growth beyond that significantly
16:22:50
monero.arbo:matrix.org:
or you know, "about" that point
16:23:32
articmine:
@monero.arbo:matrix.org: In consensus this becomes a real problem
16:23:39
monero.arbo:matrix.org:
but understand that some nodes are already going to be falling off the network at 500k per day, or become unviable to sync
16:24:12
DataHoarder:
^ poor recent released RPI 4 / 5
16:24:13
articmine:
They have time to adjust
16:25:31
monero.arbo:matrix.org:
It's not just "adjusting" some people have limited hardware availability and imo they matter too
16:26:24
articmine:
@monero.arbo:matrix.org: They NB need to consider alternatives
16:26:38
articmine:
Need*
16:26:52
nioc:
ofrnxmr what are the # of inputs for the txs on stressnet, are they the 128 input ones or a mix?
16:27:44
monero.arbo:matrix.org:
@articmine: this type of thing (hgih hardware requirements) are exactly the sort of thing that pushed people towards the centralized solutions you are so against
16:28:10
articmine:
@monero.arbo:matrix.org: No I have to disagree here
16:28:31
monero.arbo:matrix.org:
It's why I don't run my own Ethereum node, I'll tell ya that much
16:28:43
articmine:
That is the excuse that was used in Bitcoin
16:29:36
articmine:
@monero.arbo:matrix.org: What is preventing you!
16:29:41
ofrnxmr:
nioc: For the 100k numbers? Mostly 1 or 2 input
16:30:05
nioc:
thx
16:30:22
ofrnxmr:
Doubt that. We have 2gb ram nodes syncing fine > <@monero.arbo:matrix.org> but understand that some nodes are already going to be falling off the network at 500k per day, or become unviable to sync
16:30:46
monero.arbo:matrix.org:
@articmine: hardware and bandwidth requirements. even though I technically could do it. and I'm an enthusiast who runs nodes for like, 3 or 4 different networks. and uses Ethereum!!
16:31:16
articmine:
What bandwidth requirements?
16:31:18
ofrnxmr:
ethereum nodes have like a 16gb ram min or recommended requirement, dont they?
16:31:24
monero.arbo:matrix.org:
I'm just one person, but to say hardware requirements don't push users away from running their own node is just on it's face untrue
16:31:37
ofrnxmr:
@monero.arbo:matrix.org: Youre like, making stuff up
16:31:56
ofrnxmr:
you can sync stressnet with 2gb ram
16:32:59
articmine:
Please understand why I have to take a hard line here
16:33:03
ofrnxmr:
Storage is the issue that we'd hit with sustained large volume, so obv we need to deploy an easy-to-use solution to allow splittingtje db across storage mediums
16:33:30
monero.arbo:matrix.org:
@ofrnxmr: bro you know I've been running a stressnet node
16:33:49
ofrnxmr:
so reduce your ram to 2gb and test your theory
16:34:11
monero.arbo:matrix.org:
my primary concern has, for about the third time this conversation, been compute requirements
16:34:30
ofrnxmr:
Reduce your vcpus to 4 and test your theory
16:34:54
monero.arbo:matrix.org:
I'm running it on a 4-core laptop and can see the performance with my own eyes sir
16:35:14
ofrnxmr:
Oh, you're having problems staying in syns?
16:35:17
ofrnxmr:
Sync*
16:35:20
articmine:
@monero.arbo:matrix.org: Which will easily be addressed with an increase in the price of Monero
16:35:24
ofrnxmr:
I havent seen you report any issues sar
16:35:46
monero.arbo:matrix.org:
@ofrnxmr: Not at all, I was saying in my original comment that I have been syncing 2-5 blocks per minute
16:36:05
articmine:
Seriously a 20x increase in on chain adoption will impact the price
16:36:08
ofrnxmr:
At what block sizes?
16:36:16
monero.arbo:matrix.org:
I was literally just trying to give people an idea of where performance is currently at with fcmp
16:36:34
monero.arbo:matrix.org:
@ofrnxmr: at whatever they've been, that's why I was asking
16:36:41
ofrnxmr:
Your idea is false thiugh! The speed is similar to ringct
16:37:00
monero.arbo:matrix.org:
ok? that's neither here nor there
16:37:33
monero.arbo:matrix.org:
I literally just said, hey, this is how fast I sync at this TX volume with fcmp on my laptop. you're reading so much into my comments that I did not say
16:37:34
articmine:
Anyway I have to leave for now
16:37:34
ofrnxmr:
its not some new problem. What is a new problem, is that sync with checkpoints is slowed
16:37:54
ofrnxmr:
Also, if you have more than 4cores, use --prep-blocks-threads=$(nproc) to greatly increase sync speed
16:38:06
ofrnxmr:
@ofrnxmr: Only works w/o checkpoints
16:38:25
monero.arbo:matrix.org:
I intentionally used this laptop to see how it performs on average to below average hardware
16:38:38
monero.arbo:matrix.org:
because I think that's important
16:39:07
ofrnxmr:
what are the specs that you're running with
16:39:18
monero.arbo:matrix.org:
oof hold on let me look
16:40:24
monero.arbo:matrix.org:
it's a 10th gen i5 with like, 32 GB of RAM
16:43:43
monero.arbo:matrix.org:
The people I'm thinking of downloaded the GUI from getmonero.org and open it up, maybe once a month, maybe once every 3 months, and they used to default option to run their own node, so they have to catch up the sync every time they open their wallet.
16:43:43
monero.arbo:matrix.org:
And if that's not how we want people to use Monero anymore, well we need to stop channeling people down that path
16:43:47
ofrnxmr:
Blocks are currently 300kb
16:46:53
ofrnxmr:
@ofrnxmr: On stressnet.
16:46:53
ofrnxmr:
1. Start your monerod with --offline
16:46:53
ofrnxmr:
2. flush_txpool
16:46:53
ofrnxmr:
3. pop_blocks 100[... more lines follow, see https://mrelay.p2pool.observer/e/muK7hssKTkV6TTFY ]
16:47:49
monero.arbo:matrix.org:
It's a couple weeks behind rn tbh but I can fire it up
16:48:16
monero.arbo:matrix.org:
we can also move to the #monero-stressnet:monero.social channel for this if you want
17:19:09
gingeropolous:
i need to dive into these github threads or something because i really don't get what the issue is. From reading through this conversation everyone seems to agree that we need a dynamic block size that has the two tier mechanism - a shorter term dynamic cap and then a longer term one (that will ultimately increase the shorter term one). I need graphs and stuff.
17:20:33
ofrnxmr:
Spackle has graphs
17:28:51
gingeropolous:
from my perspective we can get the numbers on what our current hardware can do, and adjust the scaling parameters accordingly. It might even be worthwhile to bake in some optimism re: tech advancement, just like a 2% increase in whatever parameter per year
17:29:34
gingeropolous:
i recent got my old core2 quad up and running again....
18:10:03
articmine:
@gingeropolous: This is not entirely true. There is at least one person who is opposed
18:10:54
articmine:
Opposed to the adaptive blocksize
18:20:01
articmine:
When I say opposed, I mean opposed to everything Monero has done in this area going back to the Monero genesis block in 2014and furthermore to the scaling specification in the Cryptonote whitepaper
18:21:11
articmine:
This is why this was also an issue ahead of the last hard fork
18:23:40
articmine:
The proof of the above lies in this simple proposal.
18:25:08
monero.arbo:matrix.org:
that poposal doesn't seem to have any traction as far as I can tell
18:27:20
articmine:
For good reason.
18:28:33
articmine:
... but that doesn't stop the proponent from lobbying behind the scenes
18:29:29
articmine:
I went through all of this before ahead of the last hard fork
18:34:09
articmine:
https://unbekoming.substack.com/p/hijacking-bitcoin-the-hidden-history
18:36:26
articmine:
We must keep in mind that there are serious economic interests to the tune of billions of US dollars at stake here for the blockchain surveillance industry
18:39:03
pubertus:matrix.org:
technically a sidechain. and this is needed either way for defi. > <@monero.arbo:matrix.org> yeah if we get too successful I don't see how we avoid needing a level 2. the blockchain trilemma still exists
18:39:38
pubertus:matrix.org:
an L2 would bloat the L1 which is obviously not something anyone wants.
18:42:36
articmine:
I am actually working on an analysis of the impact of scaling on blockchain surveillance (BS).
18:44:11
articmine:
My preliminary assessment is that scaling is really bad for blockchain surveillance. So I can really see the incentives here
18:51:50
pubertus:matrix.org:
how do you want to ensure users of an L2 always have the escape hatchet to the L1 in case the L1 stops? > <@kayabanerve:matrix.org> I think the best argument for scaling is layer twos and am disappointed the current discussion is on trying to place everyone's transactions onto each individual's device (n -> 1) instead of distributed solutions FWIW.
18:52:17
pubertus:matrix.org:
how do you want to ensure users of an L2 always have the escape hatchet to the L1 in case the L2 stops? > <@kayabanerve:matrix.org> I think the best argument for scaling is layer twos and am disappointed the current discussion is on trying to place everyone's transactions onto each individual's device (n -> 1) instead of distributed solutions FWIW.
18:53:57
articmine:
@pubertus:matrix.org: This is why Bitcoin Lighting has failed. A good L2 does not replace the L1 . It complements and enhances the L1
18:59:27
pubertus:matrix.org:
@articmine: yes. we have the privacy. now we need to get XMR into defi. and looking at the regulatory frameworks being prepared for us (CARF, MiCA, etc), we can see what it will need to look like long-term.
19:00:47
pubertus:matrix.org:
the current regulations for centralized exchanges etc. will start transferring to dexes eventually. and chains. making also chains compliant.
19:01:32
pubertus:matrix.org:
we can already see that several infras like bridges are implementing various mechanisms.
19:03:14
pubertus:matrix.org:
from this point of view, something like an L2 would be good for Monero's resilience
22:59:12
gingeropolous:
how will xmr benefit from defi?
22:59:29
sashimi.:matrix.org:
"liquidity"