"So does Phoenix LSP. If they go down users can’t make payments." Sure, if you are using Phoenix Wallet, and their infrastructure goes down, you can't make payments. Same for lots of other providers, I agree here.

"They also know where you send to and when you receive." This is horrible misinformation, where did you get this idea? Please check this simple explainer on privacy in Lightning (generously authored by myself): https://docs.megalithic.me/the-lightning-network/how-private#lightning-is-very-private

Phoenix does NOT know who you are sending to. At best, they have a node id (public key) of the final hop --but that really provides NO provable data about where the payment goes to -- Phoenix has NO IDEA where you are sending to.

Not only that - when you RECEIVE a payment, Phoenix has NO IDEA where that payment has come from.

The amount of misinformation floating around about this is just horrible.. to some extent I blame Roy @ nostr:npub1jugar2agq6369p0l86razavs9shj2p6pscxecevs8j94ap37hkqsjlfc28 -- who previously was a proponent of Lightning and now goes around making totally dangerous claims about how proprietary APIs like Breez or LightSpark could somehow be used instead of the Lightning network.

Regarding "Any LSP that does the route finding for a user knows the destination of the payment." -- This isn't how it works. Lightning is "source-routed". The PAYING node constructs the route, not the LSP.

And even if you use a proprietary service like Phoenix, again, that service only know the public key of the last hop.

Compare this to the dire situation of one Blitz user sending a payment to another Blitz user, using LightSpark's token and API..... LightSpark sees the entire transaction, the transaction never touches Bitcoin, LightSpark sees BOTH the ENTRY and the EXIT IP address, entirely within their own token ecosystem.

Fucking terrifying.

At any time, David Marcus could export a spreadsheet of Blitz users, their IP addresses, the IP addresses of other Blitz users they made payments to... it's like Chainanalysis but 1000x easier for spying!

Reply to this note

Please Login to reply.

Discussion

Oh so maybe we’re misunderstanding each other. We thought you were talking about spark <> LN payments and LN <> Spark payments. Not Spark to Spark payments.

Yes spark to spark payments are very bad.

Also, one more thing: For the sake of argument, let's say Phoenix had surveillance power over its users, like LightSpark does.

Phoenix is still VASTLY superior to any service that uses Spark as a back end.

Phoenix runs one (1) out of 16,000 INTERCOMPATIBLE Lightning Nodes on the network, and one (1) out of hundreds of INTERCOMPATIBLE wallet services on the network.

the Lightning Network is DECENTRALIZED.

Anyone can spin up a Lightning Node. Anyone (with some tech skills) can build a wallet service.

If you are building technology to interact with Bitcoin, the only ethical way to do it is to use PUBLIC standards which are INTERCOMPATIBLE with other users, so you can help build a DECENTRALIZED system.

If you're not doing that, just use the Stripe API or something.

For anyone reading, we hope this has been an informative discussion.

In short, Spark payments have a few important privacy nuances. Transactions that stay entirely within Spark, Spark-to-Spark, aren’t private and reveal a link between users. When two Spark users pay each other over Lightning, the connection on a Spark explorer is obscured, but timing analysis can still expose the receiver. If you send from your Spark wallet to an external Lightning wallet, Spark only has the same level of visibility as any other LSP. When receiving from an external Lightning wallet into Spark, Spark similarly knows only what an LSP would about the sender. However, the receiver isn’t completely private either, timing attacks can reveal the receiving address and wallet balance, making it less private than a standard Lightning receive.

Let me translate, if I may:

"Spark payments have a few important privacy nuances."

Only use Blitz, or other Spark wallets, if you want your IP address to appear in David Marcus' personal database, along with your transaction history. Oh, and David loves to kill Palestinians. Does that bother you at all?

"timing analysis can still expose the receiver "

Noting "timing analysis" as a danger when you are using a fully centralized API run by LightSpark is like saying that a machine gun is dangerous because you might drop it on your foot. It's totally irresponsible to divert people with this.

"If you send from your Spark wallet to an external Lightning wallet, Spark only has the same level of visibility as any other LSP."

Fully incorrect. LSPs do NOT know the originator of a payment. Yes, they can see the entry node and exit node, but they do NOT know if the entry node is the actual "originator" or if the exit node is the actual "destination". Please educate yourself on how the Lightning Network works. The Lightning Network is DESIGNED for decentralization and privacy. Spark is not.

Get your facts straight. You can blame me all you want, but this is a complete misunderstanding of how Lightning works.

If the LSP knows the destination node, it knows the destination. period. And you don't understand how Phoenix works - they don't do source routing. They use they LSP as a trampoline nodes. They construct the path and they know the destination.

Moreover, even in cases of source routing - if the user is connected to a single LSP - the LSP effectively controls the path because the graph information is fed by the LSP...

And if you are referring to in-Spark transactions, the same issue exists in an in-LSP transaction... I.e. the sender and receiver are connected to the same LSP.

I recommended you a few times in the past not to overhype the privacy state of Lightning. I suggest you align your documentation with this: https://lightningprivacy.com/en/introduction

i.e., "there are certain theoretical ways to break privacy on Lightning".

I agree. And I strongly doubt any of these would be easy to pull off, and I really doubt anyone is attempting to pull them off.

But it's not fair to compare this situation with a user being married to one HTTP endpoint, which they have to use to do ANYTHING, and that HTTP endpoint being controlled by just one company -- and a company, at that, with a speciality in "compliance"?

1. It's not theoretical. Lightning is already being surveilled, don't be naive.

2. It's our job to allow users to switch LSPs and sub-networks at their will.

I don't subscribe to the FUD around Spark. I think it's a cool tech that will only get better and more private. And if not, the market will reject it and use something better.

There may be surveillance attempts on Lightning, but I doubt they are having much success. And again, how can you possibly compare that "possibility" -- to the fact that, for example, the government of Israel can send David Marcus a list of IP addresses and say "give us all the Spark transactions associated with these IP addresses"??

They can send it to you as well and to any Lightning node as a matter of fact. There's a reason Phoenix and WoS pulled out of the US. Now they are back - but nothing has changed from a tech standpoint.

Sure, those of us who are incentivized to do marketing for centralized, fully-surveilled, non-public solutions can continue to do that marketing.

Those of us who believe in freedom technology can also continue to make a fuss, especially when an app like Blitz, which was at one point associated with freedom technology, suddenly switches to sharing all of their user's transaction data with LightSpark.

Believe me, a lot of other Lightning participants are horrified, but a lot of them need to keep quiet because inevitably they will be looking for VC funding from the same funds which (unfortunately) are giving Breez money to market David Marcus' API.

I've been a Bitcoiner since 2012, don't need VC funding, so it's my role to explain to the community the danger of what you are marketing.

I just think you're on the wrong track. I know we're a good actor and we help Spark be more private. We already do so. We're also pushing other sub-networks and the native Lightning tech itself.

"we help Spark be more private"

A good actor would immediately recognize that LightSpark is building a closed, permissioned system, which allows them full surveillance, and would refuse to work with LightSpark until they showed a commitment to decentralization, privacy, and respect for the founding principles of Lightning and Bitcoin.

That's your blind spot, not mine. I think they are committed to an open network. They already executed on their commitment. They open sourced the SE/SO. They communicated a public roadmap wrt to privacy. I think you're completely misjudging because? You're not doing that with Arkade, you're not doing that with Phoenix, for some reason you're targeting David Marcus. I judge them based on their actions.

I would also encourage anyone following this thread to ask around at respected companies in Lightning like Lightning Labs, Blockstream, Phoenix, or others, and ask them about their opinion of using proprietary APIs like Breez and Spark, compared to using the Lightning Network as it was designed. You might find they say some interesting things in private, that they're too polite to say publicly.

I second that! Do your research. Do your due diligence.

Btw, by your definition, all the companies you listed above have "proprietary API", some of them don't even open source their code, but claim to be open source... So allow to lolz

Again, an extreme edge case where one LSP has a private channel with both the sender and receiver, something which is very, very rare in practice.

Not extreme at all. LSPs are inherently centralizing. The more liquidity you have, the more users you will attract.

Could be true to some extent, but the LSP system is OPEN. Anyone can run an LSP. Only Breez can run the Breez API and only LightSpark can run the Spark API. To compare LSPs to closed, proprietary APIs like Breez and Spark, and suggest that there are only some "tradeoffs" -- that's not cool. As long as people keep doing that, I'll keep pointing out how bad this is.

Not anyone can run an LSP. You need a lot of liquidity to run an LSP. I don't know what you mean by "proprietary API", the Spark SSP interface is public. The Spark SO is open source. You can run a Spark, an Ark or a Liquid federation. Yes, it's not easy to do, but the public interface isn't the showstopper here. It's the server management. Let's be honest, since we're operating an LSP, and interfaced with other large LSPs - running a LSP is super challenging as well. Perhaps the barrier of entry is lower now, because WE pushed for a spec and WE open sourced our LSP code - but it's still super challenging. They same dynamics apply to Spark, Ark etc.

You are likely right about Phoenix, it's true I haven't looked into that implementation.

"If the LSP knows the destination node, it knows the destination." Yes, but in the case of all the standards compliant LSPs, we DON'T know the destination. We only know the hop before the LSP and the hop after the LSP. Only the sender knows the actually destination.

"the LSP effectively controls the path because the graph information is fed by the LSP". This is an extreme edge case of a malicious LSP, and to pull this off at scale would be extremely complicated.... and also, the LSP could easily get caught by a savvy Lightning engineer who was troubleshooting payment problems.

So we agree. Effectively the biggest LSP, Phoenix, does know the destination and dies trampoline payments and implementations like LDK use an external graph sync mechanism because regular graph sync doesn't work with mobile clients. There are always trade-offs.

There are some trade-offs, but comparing the tradeoffs you list above -- graph sync & trampoline payments issues-- to the tradeoffs of allowing LightSpark to track the IP address, balances, and transaction details of all of your users -- I don'r think you can honestly put those in the same "ballpark" (as we say in the USA.)

But that's exactly what it is. An LSP can track balances, IPs, transaction details as well. We should be honest about it.