Making Lightning wallets easier to use, especially the initial bootstrap will help a lot with both Lightning and Bitcoin adoption. But, it has to be non-custodial, otherwise we regress.
Good to see more wallets do it right. https://t.co/agtTP3sgYw
> There is nothing wrong with lightning in principle.
- Can't send money to someone who's offline like Bitcoin can. That's a regression in features.
- Isn't backed by Bitcoin's record hashrate. That's why they're working on 3rd party watchtower services to watch over your money. So you're sacrificing security for low fees.
- Has send limits based on your peers send capacity. /u/N0tMyRealAcct just found out the service he's shilling is capped to $450
- Merchants need to continously topoff their side of the channel... just to be able to keep receiving payments. Does that sound how you use money today? If not it's a regression.
the list goes on. Lightning is literally a regression to Bitcoin's feature in every way AND you sacrifice onchain security for low fees. What a joke.
no one falls for your lies.
Here's /u/N0tMyRealAcct getting caught lying twice in the same claim then dropping the conversation when caught lying:
Did anyone in this thread fall for your lies?
I dropped the discussion because you are nasty and are intentionally trying to misunderstand.
Note to others, I’m willing to continue the discussion with you in the thread he linked to. I’m just avoiding this guy from now on.
> I dropped the discussion because you are nasty and are intentionally trying to misunderstand.
that's a lie:
summary of lies so far:
- Bitcoin average blocksize is 1.2MB NOT 2.1MB
- Channel factories might save anywhere between 55% - 90% in blocksize, NOT your claimed 96%. And to get a 90% channel savings you'd literally need to open hundreds of LN channels at once, which is NOT what the typical LN user does.
When Bob wants to receive a payment but lacks inbound capacity, his Breez app recognizes the lack and issues two invoices using the same preimage: one to Alice requesting payment and a second to the Breez LSP.
Instead of limiting a single channel to 1M sats, Breez now limits the sum of all a user’s local balances to 4M sats.
So a whole lot of complexity and involving middlemen to only be able to send $450.
> So a whole lot of complexity and involving middlemen to only be able to send $450.
That is an arbitrary constant.
But even if it wasn’t, Lightning allows for a lot of new use cases. There are trade offs but there are many more possibilities.
Lightning is intended for you to buy chewing gum. It works well for that.
If you want a bigger transaction the wallet can fall back onto an on-chain transaction. No issues here.
It is backed by Bitcoins hash rate. As a protocol the Lightning protocol is cryptographically as strong as Bitcoin.
Much unlike 0-conf which isn’t backed by hash rate at all. But that is as far as I will let you troll me away from the topic at hand.
> If you want a bigger transaction the wallet can fall back onto an on-chain transaction. No issues here.
And pay high fees again? why?
> As a protocol the Lightning protocol is cryptographically as strong as Bitcoin.
Yeah that's why in Bitcoin you don't check in on your money because hashrate secures it, while in Lightning you do check in on your money because no hashrate secures it. Care to tell me why watchtowers are a thing if hashrate secures it?
just yesterday /u/N0tMyRealAcct was caught pushing lies and twisting numbers and dropped the conversation after 2 lies:
You got caught pushing lies yesterday. You claimed blocks are 2.1MB when they're actually 1.2Mb and claim in the future schnorr and channel factories will produce 96% saving, when it's closer to 50% rofl
your own words /u/N0tMyRealAcct
Zero-reserve makes theft attempts costless. It is fine if Breez server is demanding 0 reserve but the client is allowed to demand non-zero reserve, but if Breez does require the client to demand 0 reserve, it allows Breez to steal funds.
Though as noted in their zero-conf channels, Breez is already in a position to potentially steal funds from users when the user receives via a zero-conf channel that has not deeply confirmed yet. This is fine if e.g. the user is buying Bitcoins using a fiat ramp with Breez directly (the fiat part is always tr*st-requiring anyway), but not so much for general payments. Though as noted as well this is time-bound, once the channel is deeply confirmed it won't matter. Zero-reserve is more concerning, unless Breez allows clients to demand non-zero reserve while demanding zero-reserve itself.
np. You were right to comment.
Since we already reduced the channel reserve (only on the client end) to a near-dust value before this update, I didn't see a need to explain it, but maybe I should add it.
To those who stumble on this thread: note that removing the reserve on the client side only makes theft attempts *costless*, but not necessarily *successful*. Breez presumably can afford to run their nodes 24/7 with near 100% uptime and presumably has some kind of watchtower setup, so even if clients could theoretically drain their channel to 0 and then attempt to rewind time to when their channel had more at no risk to themselves, they would still not succeed in practice often enough to hurt Breez. So this is an acceptable policy for Breez to follow, assuming they have good redundancy and so on.
I love Breez. Such an easy app. The main thing I want it to do tho is run an android service that listens for attempted direct payments so I can pay someone directly without requiring them to take out their phone. Then it would truly be a replacement for venmo.
I have a couple questions:
A. What fees does Breez pay to open channels for its users? Like, how is it calculated and what are the average costs it takes on?
B. Why not splice in new balance into the same channel rather than creating new channels? Wouldn't that reduce channel complexity as well as giving more optimal avenues for adding funds to a channel?
We have the Lightning Rod to implement for offline payments: https://medium.com/breez-technology/introducing-lightning-rod-2e0a40d3e44a
Splicing isn't yet implemented. There are advantages to working with multiple channels like not being dependent on a specific peer. We are going to add 3rd party LSPs into Breez, so multi channel is important. Now that we have MPP, it's much less complicated to manage.
> Lightning Rod
I see that article is from a year ago. However I couldn't find any way to pay someone while their app wasn't open in March or April. When was that incorporated into the app? How do I use it?
> We are going to add 3rd party LSPs into Breez, so multi channel is important.
> not being dependent on a specific peer ... add 3rd party LSPs into Breez
Gotcha, very cool!
Hi u/Immediate-Host, thanks for tipping u/king-only **5000** satoshis!
*[^(More info)](https://www.reddit.com/r/lntipbot/wiki/index) ^| [^(Balance)](https://www.reddit.com/message/compose/?to=lntipbot&subject=balance&message=!balance) ^| [^(Deposit)](https://www.reddit.com/message/compose/?to=lntipbot&subject=deposit&message=!deposit 10000) ^| [^(Withdraw)](https://www.reddit.com/message/compose/?to=lntipbot&subject=withdraw&message=!withdraw put_invoice_here) ^| ^(Something wrong? Have a question?) [^(Send me a message)](https://www.reddit.com/message/compose/?to=drmoore718)*