-
m-relay
<busyboredom:tchncs.de> Makes sense tbh, lightning ux is still horrible if you want self custody.
-
m-relay
<strawberry:monero.social> Bitcoin friends aren't interested in self custody
-
m-relay
<xmrfamily:matrix.org> Self custody issue complicated
-
m-relay
<strawberry:monero.social> Considering bitcoin has been flipped, maybe CoinCards should change their slogan to Buy Gift Cards with Monero?
-
m-relay
<xmrfamily:matrix.org> 1000% 💯💶
-
m-relay
<strawberry:monero.social> The title on their website is even worse: Buy Gift Cards Using Bitcoin, Litecoin, Dash, Dogecoin
-
m-relay
<strawberry:monero.social> It's like when CoinGecko made that list of "top 10 privacy blockchains" and ignored Monero
-
nioCat
dash lololol
-
m-relay
<321bob321:monero.social> door dash?
-
m-relay
-
m-relay
<strawberry:monero.social> Is lightning this hard to use properly? What management time?
-
m-relay
<321bob321:monero.social> wait till they close the channel
-
m-relay
<neromonero1024:monero.social> under the latest "money transmission business" law, isn't Lightning now considered a money transmitter?
-
m-relay
<strawberry:monero.social> everything is a money transmission business
-
m-relay
<strawberry:monero.social> lightning nodes are money transmitters, miners are money transmitters, coin join builders are money transmitters
-
m-relay
<strawberry:monero.social> remember your 12 words? your brain is now a money transmitter
-
m-relay
<hapna:monero.social> 0% - dash
-
midipoet
custodial lightning wallets would more than likely be MSBs/CASPs. People that run lightning nodes for profit (as opposed to a hobby/home node), would also more than likely be classified as such. Miners that run L1 nodes for profit only could also potentially be considered MSBs as well, unfortunately.
-
n1oc
Boog900 full time work on Cuprate (3 months) is now fully funded!
ccs.getmonero.org/proposals/boog_3_months_cuprate_2.html @luigi1111
-
m-relay
<321bob321:monero.social> I think a working binary is very soon ™️ ?
-
m-relay
<dave.jp:matrix.org> No need to rush it, soon tm is good enough
-
m-relay
<321bob321:monero.social> I saw the words “alpha binary”
-
m-relay
<smith000:matrix.org> We hit 25 members on our signal monero group if anyone wants to join too
signal.group/#CjQKIMtPr_BcagCe6ARHn…jRX-QLye9foEhDjts9QEhsvErDn7i0oiZaV
-
m-relay
<r4v3r23:monero.social> signal lol
-
m-relay
<rottenwheel:kernal.eu> r4v3r lol.
-
m-relay
<xmrfamily:matrix.org> I joined, felt dead
-
ofrnxmr
signal lol
-
m-relay
<rottenwheel:kernal.eu> ofrn lol.
-
m-relay
<xmrfamily:matrix.org> Actually seems like a nice group
-
m-relay
<real_glitch:matrix.org> read the news bro
-
m-relay
<starlingfarchecker:monero.social> I use signal but it’s associated with my real name, i ise it with fam. Is there a way to make an alias or something when joining a public chat?
-
m-relay
<xmrfamily:matrix.org> Sadly I don't think so, that's benefit of using simplex
-
m-relay
<321bob321:monero.social> Signal has usernames, but i would get a voip number
-
ofrnxmr
Signal blocked me for using tor, so: signal lol
-
m-relay
<preland:monero.social> “No signal”
-
m-relay
<xmrfamily:matrix.org> Signal is great for it's purpose, don't hate preland
-
m-relay
<preland:monero.social> It’s okay
-
m-relay
<10tus:monero.social> Hi everyone !
-
m-relay
<10tus:monero.social> I thought about something lately, crypto latest advancements and how could it be combined with the monero tech
-
m-relay
<10tus:monero.social> Some might know now than there is this crypto project named Kaspa which is not at all a privacy coin but they saved the original ethic of bitcoin without the
-
m-relay
<10tus:monero.social> negatives pretty much
-
m-relay
<10tus:monero.social> They where able to successfully addressed blockchain trilemma of decentralization, scalability and security with their blockdag technology than allows for multiple blocks simultaneously and style using proof or work
-
m-relay
<10tus:monero.social> I am.just enthusiast thinking and imagining adapting Monero's privacy tech ( Ring signatures, RingCT, Stealth adresses ) to a BlockDAG structure
-
m-relay
<10tus:monero.social> I would like to know if someone thought about this as well, and asking you, monero community and skillfully crypto developers , if such project would be feasable or if my fantasy is not feasible
-
m-relay
<10tus:monero.social> If such a thing where possible, combining Monero's privacy features with blockDAG tech could theoretically provide both high privacy and improved scalability, with faster transaction conformations and higher throughput, this would be such a master piece
-
m-relay
<10tus:monero.social> Having the benefit of this relative "new tech" created by kaspa but for a privacy coin equivalent to monero
-
m-relay
<10tus:monero.social> I would like to have some thoughts in this
-
m-relay
<10tus:monero.social> Big thanks than such community exist
-
m-relay
<strawberry:monero.social> I've thought about the possibility of blockdag in Monero, but does it really solve enough for it to be high priority?
-
ofrnxmr
Xelis or dero, no?
-
m-relay
<10tus:monero.social> I think it would improve user experience and possibly making it more appealing and therefore increasing its acceptance, it should be nice than to don't always trade to much performance when we go to the road of privacy, which is generally a common painful tradeoff
-
m-relay
<10tus:monero.social> its just about upgrading and improving the tech without compromising the privacy aspect, is like do we want to stay on windows 98 or could it be nice to upgrade to improve performance and have more advantages to propose in this crypto economic competition, if this is feasible of course' I guess there might be some complex challenges on the way
-
m-relay
<10tus:monero.social> Maybe blockchain will one day be to old and then the crypto tech will improve more and more, maybe one day bitcoin and monero will become obselete in comparison to more advanced tech's
-
m-relay
<10tus:monero.social> We can bet in 10, 20 years, it could also improve more
-
m-relay
<10tus:monero.social> I think is nice to make our best to give as many advantages we can without compromising privacy, since it's our higher priority, but if there a possibility of improving the tradeoff we usually make, I think I only see good reason for it
-
m-relay
<10tus:monero.social> But I wonder what you all may think on this
-
m-relay
<10tus:monero.social> I think it's worth considering it
-
m-relay
<strawberry:monero.social> All it does from the user experience perspective is reduce the initial confirmation time from (in theory) up to 2 minutes to a second, but this doesn't actually matter much since lowering block times makes the confirmations "worth less" in terms of security
-
m-relay
<strawberry:monero.social> If you currently ask for 2 confs, then Monero adds this and reduces block time to 30 seconds, you'll now want to ask for 8 confs
-
m-relay
<ct:xmr.mx> the trilemma is a myth. We are not hitting any of the limits right now, the only true limit is people willing to transact in monero
-
m-relay
<strawberry:monero.social> I don't see how blockdags solve the trilemma in any case
-
m-relay
<ct:xmr.mx> of course once the limits become more noticeable, improvements will be required, but for now its more important to focus on more pressing issues. haveno, serai, bsx all help with accessibility and liquidity, projects like xmrbazaar allow easier trading for good/services
-
m-relay
<10tus:monero.social> Oh that's a valid point
-
m-relay
<10tus:monero.social> But wouldn't blockdag systems will achieve faster confirmations because multiple blocks can be created and validated simultaneously ? Which is reducing the overall confirmation time without necessarily reducing the number of confirmations
-
m-relay
<10tus:monero.social> Maybe I am.wrong but I thought than block do not reduce security since they rely on a different security model, the consensus mechanism and network conditions must ensure that the parallel blocks are consistently reconciled to avoid conflicts and maintain integrity
-
m-relay
<10tus:monero.social> Of course, in traditional blochain, more conformation means higher security
-
m-relay
<10tus:monero.social> But I thought in the case of blockdag faster block generation does not necessarily mean fewer conformation, instead it would means the same number of confirmation could be achieved in a shorter time frame
-
m-relay
<strawberry:monero.social> From what I understand, the only security benefit is that hashrate isn't being wasted on alternative blocks, since those blocks still get included
-
m-relay
<10tus:monero.social> Oh that's a valid point
-
m-relay
<10tus:monero.social> But wouldn't blockdag systems will achieve faster confirmations because multiple blocks can be created and validated simultaneously ? Which is reducing the overall confirmation time without necessarily reducing the number of confirmations
-
m-relay
<10tus:monero.social> Maybe I am wrong but I thought than block do not reduce security since they rely on a different security model, the consensus mechanism and network conditions must ensure that the parallel blocks are consistently reconciled to avoid conflicts and maintain integrity
-
m-relay
<10tus:monero.social> Of course, in traditional blockchain, more conformation means higher security
-
m-relay
<10tus:monero.social> But I thought in the case of blockdag faster block generation does not necessarily mean fewer conformation, instead it would means the same number of confirmation could be achieved in a shorter time frame
-
m-relay
<strawberry:monero.social> Don't quote me on this but on Monero that's like a 1% improvement
-
m-relay
<ct:xmr.mx> performance is currently benchmarked and improved on the stressnet, a testnet specifically build for overloading nodes. First results had already valuable results, which improve performance at large mempool sizes. This is important, because it gives robustness to spam attacks, or simply when having more active users.
-
m-relay
<ct:xmr.mx> Confirmation time is "merely" a security feature. For day to day use the zero conf transactions work well enough.
-
m-relay
<ct:xmr.mx> To increase security, the only way is to increase hash rate. Because emission is fixed, only an increase in coin value increases the amount of active miners. And a long term price increase requires active usage of people
-
m-relay
<monerobull:matrix.org> correct. stressnet is at 20 TPS
-
m-relay
<monerobull:matrix.org> mainnet is at 0.2
-
m-relay
<monerobull:matrix.org> that's a 100x
-
ofrnxmr
And 3x bitcoin
-
m-relay
<dave.jp:matrix.org> Stressnet is using ringsize 16? What about testing it for a higher ringsize which is planned
-
ofrnxmr
Its not planned
-
m-relay
<strawberry:monero.social> since when was ringsize increase planned?
-
ofrnxmr
Seraphis was supposed to bump to 128
-
m-relay
<monerobull:matrix.org> ofrn are you for real
-
m-relay
<monerobull:matrix.org> FCMPs or bust
-
m-relay
<dave.jp:matrix.org> It’s being discussed to increase ringsize pre fcmp/seraphis , as during spam attack effective ringsize drops
-
m-relay
<strawberry:monero.social> I've seen talk about raising it so that tx size is equivalent to what it will be under FCMPs
-
m-relay
<monerobull:matrix.org> i think that was about fees not ringsize
-
m-relay
<dave.jp:matrix.org> Just increasing fees isn’t going to do much if number of txs needed to decrease effective ringsize is lower
-
m-relay
<ct:xmr.mx> larger ringsize was discussed to bridge the time till fcmp is live
-
m-relay
<dave.jp:matrix.org> Ringsize + fee increase
-
m-relay
<ct:xmr.mx> depends on how long it'll take, or if there are any major flaws found
-
m-relay
<strawberry:monero.social> I'm personally a fan of increasing fees for tx with more outputs, so that we have a standard cost for creating 1 output
-
m-relay
<strawberry:monero.social> That way 16 out spam isn't more efficient
-
m-relay
<monerobull:matrix.org> thats already how it is?
-
m-relay
<dave.jp:matrix.org> Outputs are 1 to 16, needs to be 4/8/16
-
m-relay
<monerobull:matrix.org> they still pay more fees though?
-
m-relay
<strawberry:monero.social> They pay more fees, but 16 outs is still more efficient at creating outputs than 2 outs
-
m-relay
-
ofrnxmr
"larger ringsize was discussed to bridge the time till fcmp is live" << this is retarded
-
m-relay
<ct:xmr.mx> was discussed = many months ago
-
m-relay
<10tus:monero.social> Well if its only one % then... In that case is not worth it considering the amouth of work than this archecture would require
-
m-relay
<10tus:monero.social> It is possible than the security improvement from including alternative blocks is 1% if the current orphan rate is low and the network is efficiently managed
-
m-relay
<10tus:monero.social> I am still curious though, because we can't really know exactly the % of improvment without testing and analysing
-
m-relay
<10tus:monero.social> But I agree than the benefits of adopting blockdag might be modest for monero, or at list not worth the extensive work involved...
-
m-relay
<10tus:monero.social> That's why I came with this question, thanks for bringing up some nuances to my enthusiasm
-
ofrnxmr
-
ofrnxmr
-
ofrnxmr
If were waiting for fcmp, ^^
-
ofrnxmr
doing arbitrary stuff is senseless. Yoloing more decoys and higher fees doesnt solve anything
-
ofrnxmr
More decoys = more bloat
-
m-relay
<strawberry:monero.social> The main benefits imo are increased payout frequency for solo miners, and faster initial confirmation
-
m-relay
<dave.jp:matrix.org> And wasn’t rejected, everything monero moves slowly; we can’t be sitting duck while fcmp comes
-
m-relay
<strawberry:monero.social> Initial conf might stop an attacker sending conflicting tx to different nodes, though I'm not sure how applicable that sort of attack is to monero
-
m-relay
<10tus:monero.social> Yeah so receiving more payouts frequently
-
m-relay
<10tus:monero.social> Which is good impact
-
m-relay
<10tus:monero.social> This could incentivize more miners to participate in the network, which could increase the overall security through a higher hashrate
-
m-relay
<10tus:monero.social> Maybe the security improvement is marginal but I was more thinking about the user experience enhancment in the beginning
-
m-relay
<strawberry:monero.social> #1 benefit is that block explorers will look awesome
-
m-relay
<10tus:monero.social> I agree 😄
-
m-relay
<strawberry:monero.social> It's not that more miners will participate, but it will be practical for more people to solo mine instead of using pools
-
m-relay
<strawberry:monero.social> which arguably does mean they're now participating rather than following orders
-
ofrnxmr
"And wasn’t rejected, everything monero moves slowly; we can’t be sitting duck while fcmp comes" << mrl 108 and 109 have been open a long time
-
ofrnxmr
109 was mostly completed (and usable if you compiled yourself)
-
m-relay
<10tus:monero.social> Which would enhance decentralisation right ? This reduce the risk where a few large pools control a significant portion of the mining power
-
m-relay
<10tus:monero.social> Sounds like an healthier network to me
-
m-relay
<strawberry:monero.social> yes, that's the idea
-
m-relay
<strawberry:monero.social> we already have p2pool for this, but it creates many small outputs, hence:
-
m-relay
<strawberry:monero.social> that being said, decreasing block time does the same thing
-
m-relay
<strawberry:monero.social> and kaspa clearly has a solution for this, but if the same height can have several blocks, how is the block reward divided up? iirc kaspa doesn't have a tail emission or dynamic block sizes, so those might not be compatible
-
m-relay
<strawberry:monero.social> and there are coins which merge mine with monero, so it's unclear how those would work too