pull down to refresh

Here is a response by the CTO and co-founder Lightspark, Kevin Hurley:

There's been a round of misinformation about Spark going around, so for the sake of setting the record straight, I'll briefly clear up a few things.

For one, unilateral exit has been around since the early days of Spark. Many developers and users have used it. This has been demonstrated many times both here on X and during the process of integration by developers. Unilateral exit also does not require the SOs to be online when a user wishes to exit. When a transaction is received, users can save the unilateral exit information and later use those pre-signed, valid L1 Bitcoin transactions at any time on Bitcoin. There are existing Github issues to expose unilateral exits in a more intuitive way in the SDKs, but unilateral exits themselves have been functional for a very long time. Unilateral exits do require CPFP - this is used to ensure that the expected value for an attacker is negative. The typical user would perform a cooperative exit, which does not require any on-chain funds and is an atomic swap of on-chain funds in exchange for Spark funds. Unilateral exits are generally reserved for a worst-case scenario and can be sponsored by an L1 fund provider if needed.

Second, the confusion around "Sparkcore". At Lightspark, we use a monorepo for our server code. This one service is called Sparkcore - the naming of which preceded the creation of Spark. Lightspark runs an SSP within this service. Our Lightning infrastructure uses both LDK and LND - both of which we contribute code towards. Sparkcore itself is not open sourced - that would mean open sourcing our entire server-side stack for every product we have built. The Spark network code, however, has always been open source - and that's the openness that matters, because it's the code that actually enforces the rules of Spark. The SSP is an optional, replaceable convenience role.

A recent post claimed that APIs used for other products are part of the SSP. We have many products, and we have never been shy about describing UMA, which allows regulated entities to exchange information to process transactions over Lightning. This is not a Spark product. The SSP does not hold your seed phrase (that should never leave your device), the SSP cannot freeze your funds, and the SSP isn't even a required role to use Spark - it is the interop layer between Lightning and Spark and helps do swaps for exact denominations of leaves. Running an SSP is something we have talked with many partners about. The client chooses which SSP they wish to interact with (if any) - we cannot control if a client talks to a new SSP.

Finally, privacy. I've discussed this many times in the past, so won't belabor the point again. Spark allows for transactions to be hidden from external visibility. As I've spoken about at length both here and at various conferences, we care deeply about making sure that there is true privacy, and we aren't satisfied with anything short of that. It's an ongoing effort to continue to further the research in this area.

I'll leave it with this. In the network our critics operate, the default payment path is one where the operator colluding with any prior owner can double-spend the current holder - their own docs say so. Receiving over Lightning means trusting that the operator deleted a key - their own docs say so. If you don't come online every 28 days, the operator can take your funds. In their founder's own words: "In theory it could steal it." The automatic re-issuance of expired funds promised in March 2025 still hasn't shipped. Their operator's liquidity costs scale with payment volume, which by their own admission "will translate into user fees." And there is exactly one operator - their own docs tell everyone else: "Do not attempt to run an Ark server in production (yet!)." Spark has three independent operators, exits that don't expire, and no flow where a single operator can take user funds. Users can judge for themselves.

Our users and the developers building on top of Spark care about bringing Bitcoin to more people. They value the ease of use and simplicity of Spark. They care that we have 3 independent SOs. They care that we are pushing for more and better functionality. And they value that we spend all of our time thinking about how to make Spark better each and every day. Ok, now back to building because that's what we do at Spark.

This feels to me like the community reaction to spark when wallet of satoshi launched with it #1020261 and to the frustration when some wallets using spark put a user's spark address in the route hints of a lightning invoice #1251232.

Spark's advertising could use a lot more clarity.

Spark can see all your transactions, and like any entity that can see all your transactions (isn't this true for many LSPs?) they can log what they see and compare them to other data to which they have access.

It may be fair to say that spark spies on you, but so does every other service you use. The only ones who don't spy on you are the ones who can't spy on you.

reply
7 sats \ 1 reply \ @ek 13 Jul

lol, “I shot him down”. You wrote this:

It doesn't take that many paragraphs just to say "Spark is custodial and can spy on all of your transactions".

You have only disqualified yourself from the discussion with that unproductive reply.

Saying it’s custodial is as smart as saying it’s not.

reply

Brevity is the soul of wit. Do you think anyone would care about their 10 page essay if it started with the truthful sentence "Spark is custodial and can spy on all of your transactions"?

reply

I saw that. I was hoping he would respond to you.

I'm curious though: is spark so different from a lightning wallet where you have only one channel with your LSP (a la Phoenix)?

I guess you can get to the chain more easily, but they still can see all your txs, I think.

reply

No, it's not so different, only slightly worse.

But I don't think it's too much to ask that we try for "slightly better" instead of giving up entirely.

We already had Mercury Layer statechains. These used blind signatures so the statechain couldn't spy on users. The custody issue remains for both Mercury and Spark, but why the FUCK is the privacy getting WORSE as new projects replace old ones?

reply
109 sats \ 1 reply \ @ek 13 Jul -1069 sats
I was hoping he would respond to you.

Would you, if he had replied to you like that? I certainly wouldn’t. What is there even to reply to?

Hmm... I just realized that if you apply the process of toxicity that nopara describes in #1523710 in a generic way to the spark discussions going on, then there are parallels and this is probably once more a situation where implementation criticism goes toxic, divides people, and then in the end, the user within the divide that actually believes any of these toxic narratives will get victimized, again.

Both the Bitcoiner that falls for this narrative and the one that stay away from but becomes emboldened in their use of other conveniencetech (that has a 99% chance of being at least as bad) risk getting rekt over narrative instead of facts. This has been a problem for very long and the fix ("don't trust, verify") is applicable poorly to users of conveniencetech. People do not really want to be secure, because that takes real effort; they just wanna believe that they are secure and brag to their buddies. Some magic solution that solves everything and you have true freedom now. I hope anyone with half a brain realizes how fucking retarded that is.


After all, if you fall for the narrative that:

  1. we use a monorepo for our all our server code
  2. because of that it is not open source

, which is not even an excuse, and think that this makes it somehow okay, then you are a fucking retard. Especially because there's virtue signaling in that same paragraph about how they contribute to LDK and LND - as if that fucking matters. You can run whatever on a non-attested service endpoint.

As a user, you are depending on a closed source component, hosted as a service. This is the only fact that defines your entire risk assessment: it's a blackbox. For most of us that truly need security, the buck stops there, but let's amuse the thought that there is no other way, just this.

The next step is to figure out which data goes to that service. Everything that goes in there is exposed.

Now, if all your transactions go into the blackbox then all your transactions are exposed. If some key or address material goes in there, that is exposed. Public keys and addresses are sensitive information, from a privacy perspective! Now let's assume that you're not using anything to mask the origin of the connections to that service: then that is exposed too, and linkable to whatever data you submit.

How is it linkable? Example legal path:

  • Court order: Hey Spark give us all data you have on address <xyz> (response contains IP addresses, timestamped)
  • No need court order: SELECT ad_id, app, lat, lon FROM purchased_data_from_broker WHERE ip IN (x,y) AND timestamp BETWEEN y AND b;
  • Optional court order 2: Hey <app> give us all data you have on the account associated with <ad_id>.

You can replace the court orders with data leaks and the popo with your favorite kidnapping organized crime group to construct the less legal path.


Bottom line. If you need privacy, you cannot use ANY service without risk, and even if you roll your own for everything, it probably carries more risk (also because there is a 99.9999% chance that you will trust GPT or Claude and the bot will fuck you up, bigtime[1])

There is always risk. You can minimize and manage the impact of that risk, which takes effort; the opposite of convenience. However, a service that denies being a risk is a massive liability. Don't fall for their lies.

reply
193 sats \ 1 reply \ @gbks 13 Jul
For one, unilateral exit has been around since the early days of Spark. Many developers and users have used it.

A thing to note is that unilateral exit does not exist in any production apps. I tested all the big Spark apps recently because I wanted to see how they handle the exit, and could not find a single mention of exits in any of them. A regular Wallet of Satoshi user who bought into "The worlds simplest bitcoin wallet" is not going to hop on the CLI. I do think we can expect this to be properly implemented for end-users, when there's $175 million investment behind it, a big ecosystem with millions of users, other Lightspark products built on top of it, and the CEO making a big deal about it on podcasts. If not at this scale, then when? And where's the bitcoin ethos? It is also playing with fire, because if something happens, users are screwed, and the whole bitcoin payments ecosystem gets the blowback. Maybe a bit of pressure is healthy here.

reply

Thanks for doing that work. I played with the idea of working through one or two open implementations but then I figured that I will never use it for production moneys, even if this were perfected, and I think that no one else should either.

This is the same trap like FB or Reddit, where the public gets tricked to feed it as much data points as possible because "it's cool" or "it's useful", and then, this gets turned into profit in ways which, if it were disclosed upfront, would make a lot of people think twice. Prime enshittification material.

So as much as I can be triggered to say "yo, let's just build it", there is a very good reason of not becoming a steward of future betrayal now. And I'm honestly trying to stay far away from this crap.

reply
see all your transactions (isn't this true for many LSPs?)

No, Lightning works with a channel peer seeing the next hop along the route, not the destination

spark spies on you, but so does every other service

Key Point: Spark is a custodial service, not Lightning, so they should quit pretending otherwise.

reply

Agree with your key point, but at least a while ago I thought phoenix was using trampoline routing and that this made it so they could see all your destinations. But this was some time ago, so perhaps it is different now. I'll look into it.

reply

That raises a separate matter, the stupidity of mobile Lightning nodes, and how everything stupid in Lightning is a direct result of the mobile node fantasy.

By using Phoenix, you're also not getting the full benefit of justice transactions since your device is not always-on to publish them. It'd be trivial for the LSP to target infrequent peers for rugging.

Phoenix is Lightning with asterisks at best and shouldn't be considered when comparing Lightning to fake L2s because they share the same underlying thesis of stupidity.

reply
The only ones who don't spy on you are the ones who can't spy on you.

This is a great principle to operate from as a foundation. I recommend writing it on a whiteboard with permanent marker.

reply
Sparkcore itself is not open sourced - that would mean open sourcing our entire server-side stack for every product we have built

Well that’s kind of the point Mister!!

Isn’t this the reason why we bitcoin? But everyone is adding spark to their applications calling it non custodial lightning just LARPING.

It’s annoying to the node runners who took the time to learn and failed how to maintain a lightning node.

Cake wallet saying they care about privacy and putting this technology in their application is completely ridiculous!!

Odell putting this in primal is ridiculous!

Breeze adding this to their SDK is ridiculous!

reply