Thread

bitcoin can't do MoE without capacity for storing all the lightning channels. bitcoin won't be able to do that until lightning protocol implementations get a lot smarter and more self-managing, right now they are like the first prototypes of the model T, far from ready for wide use bitcoin will not be able to do MoE until all the non-monetary transactions are eliminated (soft fork) from the protocol bitcoin will not be able to do this because ethereum, at least, and their handlers and funders, are jealous, retarded bitches and they want their problems to infect the money because they don't believe in money, they only believe in GAIIINNNNNZZ

Need better protocol level privacy for more ppl to use it in MoE, ppl are too paranoid to spend it knowing everything is fully traceable.

lightning is fine for that. but lightning is currently still duct tape and baling wire stage prototype. and it can't scale because of blocksize, which puts MoE at odds with shitcoinery.

Most blocks aren’t full even with arbitrary data. Lightning isn’t a privacy protocol it’s a scaling solution for micropayments. So it helps but it doesn’t fix privacy.

like all privacy fans, you don't actually understand how lightning works. lightning invoices are onion layers, with capacity for 20 hops. only the endpoints know the endpoints, every other node in the path only knows its neighbours. keysend is even more secure, even the receiver doesn't know the sender, sender only knows it. it's way more secure than ring signatures, and completely ephemeral, unlike onchain transactions with monero, or zcash. go read up on how lightning works before you say things that are verifiably wrong, and welcome to my "monero mute list"

also, the receiver only knows the IP address of the request for the invoice, not the lightning node that will originate the payment. using tor to fetch invoices closes this hole too. what's hard about lightning is the implementations have many design features that make them unstable and the source-routed onion design, like all source routed protocols, suffers from the existence of congestion and dead points in the path. this could also be fixed using atomic multipath redundant onions, but isn't possible unless the message size is increased (8kb is a good size) so that you can add a fork and join operation, and an atomic race-based cancellation of the later arriving sidepaths. there is solutions, just that nobody with an idea is being paid to build them. instead, at least this person writing it, is stuck building front end GUIs and supporting adoption of my relay project. i love the relay but i wish i could work specifically on lightning. between taproot and segwit and the slow progress of lightning to solve the obvious problems i'm getting tired of bitcoin too. not to mention the miner centralization problem and this opens up cooption to state-level actors.

Ok dude I didn’t even bring up Monero. Ok point me to a resource instead of being a dick about it believe it or not I like Lightning but from what I have read on chain settlement is still a big privacy risk. Maybe it’s outdated but I read the this guide recently https://www.voltage.cloud/blog/lightning-privacy-for-beginners and have done other research so I’m sorry I am not a genius like you and don’t know how lightning works.

Maybe ChatGPT is bullshit (I mean that) but this is what I read about it. So I’m not being biased I want to be informed Short answer: they aren’t directly comparable as “privacy stacks,” because they solve different problems. Bitcoin with Lightning Network (LN) focuses on scalable, low-fee, fast off-chain payments for Bitcoin, whereas Monero is a privacy-centric on-chain cryptocurrency. If your metric is privacy by default and on-chain unlinkability, Monero has stronger built-in privacy. If your metric is scalable payments for Bitcoin with reasonable privacy protections, Lightning offers different trade-offs. Key dimensions to compare Privacy model Monero: On-chain privacy by default. RingCT, stealth addresses, and ring signatures hide amounts, senders, and recipients on-chain. Strong unlinkability between transactions. Bitcoin + LN: Privacy is not default. LN enhances efficiency but reveals more network-level metadata. Payments traverse channels and hops; there can be metadata leaks about transaction graph and user activity unless additional privacy tactics are used (e.g., onion routing, privacy-preserving routing, avoiding reuse of channels). On-chain Bitcoin remains public. Layering and scope Monero: Pure on-chain privacy. No separate layer required. LN: A second-layer solution on top of Bitcoin. It offloads many transactions from the main chain, enabling micropayments but adding complexity and different privacy considerations (channel opening/closing on-chain, liquidity management, routing). Privacy is affected by how channels are opened/closed and how nodes observe traffic. Fungibility and auditability Monero: High fungibility due to hidden amounts and addresses. Hard to trace or blacklist funds. Bitcoin + LN: Fungibility is not as strong. On-chain UTXOs are traceable; LN payments can be subject to network-level analysis, though it’s less transparent than on-chain Bitcoin. Some privacy-enhancing research and implementations exist but aren’t as robust as Monero’s default privacy. Security model and trust Monero: Privacy is cryptographic and protocol-driven. Security rests on ring signatures, RingCT, stealth addresses; no trusted setup. LN: Security depends on channel state, liquidity, routing integrity, and eventual on-chain settlement. User needs to manage channel state, opening/closing costs, and potential liquidity risk. Adoption and ecosystem readiness Monero: Strong privacy feature set; narrower merchant/integration adoption due to regulatory concerns and fungibility debates. LN: Growing ecosystem for Bitcoin payments, wallets, and services. More scalable for merchant adoption and everyday payments; mais awareness of privacy trade-offs is increasing. Concrete privacy considerations for LN Channel creation: Opening a payment channel requires a transaction on-chain (on Bitcoin) that is visible. This can leak some timing and counterparty information. Route privacy: LN uses onion routing (Sphinx-like). In practice, adversaries with network visibility and global topology knowledge could infer payment paths or correlate payments, especially if many hops share the same nodes. Channel topology: Reusing channels and clustering payments through the same route can create fingerprinting opportunities. Watchtowers: To protect against invalid states, users may rely on watchtowers; this adds trust and complexity. Liquidity and liquidity-based privacy: Limited liquidity can reveal user preferences (where funds are moving), potentially reducing privacy. Practical guidance If your primary goal is strong, default privacy for value transfers, Monero remains the better option for on-chain privacy. If you want Bitcoin-level settlement with scalable microtransactions and are willing to accept less-than-default privacy, LN is compelling and widely deployed. For privacy-conscious Bitcoin users, consider: Using LN with privacy practices: avoid reusing channels, use different routing peers, and consider privacy-focused wallets that minimize metadata leakage. Keeping a mix of on-chain and off-chain activity to reduce linkability, while understanding that on-chain privacy remains lower than Monero. Being aware of regulatory and exchange implications, as LN usage can still be observed by operators and network observers. Bottom line Bitcoin LN and Monero target different problems: LN aims to scale and speed up Bitcoin payments with an added privacy layer that is not as strong or default as Monero’s on-chain privacy. If privacy is your core requirement, Monero offers stronger, default privacy; LN can complement Bitcoin’s scalability but does not reach Monero’s level of on-chain confidentiality. For practical use, evaluate your threat model: if you must transact privately and fungibly, Monero is superior; if you need Bitcoin-like settlement with high throughput, LN is valuable but accept the privacy trade-offs. If you want, tell me your specific use-case (on-chain vs off-chain, regulatory constraints, transaction sizes, target audience), and I can tailor a privacy-oriented comparison and recommendations.

MoE depends on normie simplified protocol. unless it's as easy as tapping a phone on a reader, it's going to be ignored. only bitcoin fans like lightning. i like lightning, but it's still alpha grade IMO

Ephemeral in thoery...except that most LN node software saves and stores transaction info by default, and you also don't control what info other nodes save. Peter Todd did a talk on this problem a few months ago showing how his node still had transactions he made over a year ago. Onion layers aren't a magic barrier. Tor has a long list of attacks that can reduce or completely deanonymize you. Now consider that even if you use LN in a private way (vast majority do not) less than 1% of lightning nodes hold over 99% of total liquidity... https://www.youtube.com/watch?v=r3iFrkESigo https://github.com/Attacks-on-Tor/Attacks-on-Tor

He's like super duper smart bro. You wouldn't understand.

That can be done with the tech existing today.

that's why it's not fit for mass adoption

the duopoly on mobile devices is also a huge obstacle. but i think that popularity would ensue if the tech was made invisible and the user couldn't tell the difference except for the currency

the cryptography is also key. how do we shift the overton window to the idea that cryptographic authentication and self sovereign identity is easy. that's the hardest puzzle.

*can* and *could* but it needs devs who understand the tech and have good normie-friendly design skills. still, introducing the secret key is your identity concept still is gonna be a really hard problem to scale