pull down to refresh
Now with Spark we are essentially back to where SN began with a custodial wallet users can access out of the box.
The situation is different because the custodian is 3rd party. So where before you'd put "trust" in the SN team to not rug you, now you put trust in SN to not mess up the integration, and Marcus to not rug you. So I think that this is a bad comparison.
I do understand the compliance issue - better than I like to - though, and like I said elsewhere, there are no good solutions for earners right now; only tradeoffs.
Exactly. Apples and oranges:
The situation is different because the custodian is 3rd party. So where before you'd put "trust" in the SN team to not rug you, now you put trust in SN to not mess up the integration, and Marcus to not rug you
Fair, yet many users have adjusted to SN's decision not to be a custodian by accepting trust in CoinOS or some other ecash mint not to rug them...with what seems likely relatively light assurances.
We (SN) were offloading the decision of who newbies should trust and mostly pretending not to notice that they are all just trusting a single custodial wallet. Indeed, the standard advice found on SN for which wallet to connect tended to be CoinOS. They operate a great service, I have used it in the past and have nothing bad to say about it -- however it felt a little like an "accidental" default for new users.
That wasn't what I was challenging though. But please be careful in what you make non-accidental. If the above means that you're no longer deferring who newbies should trust and the choice is "trust spark", then I'd like to find out why you and I have such different opinions regarding what trustworthiness looks like.
What about Spark makes it a better choice than any option you've seen so far, after 2 weeks of testing while everything else in the wallet list, including other custodial solutions, has been in use much longer? What is that magic that within 2 weeks makes it a recommendation over an option?
why you and I have such different opinions regarding what trustworthiness looks like.
If you ask me which service has more to lose by rugging users, I would say Spark does.
If you ask me which service is more likely to shotgun kyc users, I'd say Spark.
As you say, it's tradeoffs.
I think there is a lot of antipathy towards Spark because they look like "the man" and they may indeed be entirely under the thumb of the government, but I do not think that it is wise to assume something like CoinOS is not just because it is small.
But then why would anyone recommend this tradeoff over the CoinOs one? It's fine if it's only technical considerations (I really feel like it is, reading the release note), but I think that that should then just be said out loud instead of trying to find other narratives. The narratives are what make things bad in Bitcoin. That's exactly where the scammers operate. It's the thing we have no defense against.
Perhaps I am naive, but I think the likelihood of Spark introducing shotgun kyc is lower than the likelihood that CoinOS abruptly shuts down.
I have been advocating for something like a "one-click" wallet in SN for a while. My hope is that we get a dead-simple way for new people to start using SN. And I find CCs to be a confusing solution to this.
CoinOS seems to operate a good service and I don't want to insinuate anything about it. However, in my mind Spark has more to lose if they rug people, even if the rugging is "excused" by calling it compliance.
I don't want to introduce a narrative here where k00b kept it technical, and if that's what I'm doing it is entirely my own way of thinking about this problem (and possibly not even something he agrees with).
For me, at least, the problem has been that there was not an easy way for new users to get a wallet and i think Spark has a better set of tradeoffs in solving that problem than CoinOS.
Edit: it occurs to me that the problem here may be that I want an easy way for new users to get a water, rather than believing that education + UX can achieve "dead-simple"
So the way I read this, and this too is just my interpretation, so don't take what I am about to say as fact:
It is impossible to take custody of both the deposit and the withdraw side of sats without being a money transmitter / bank. This is why SN works the way it works today. It's a compliance issue and this is being taken seriously by SN, because it is a corporation, not someone's underground hobby project. The CC tradeoff is a feature of compliance requirements, and as shitty as it may be, it is there for a reason.
Spark offers a technical way to automate wallet creation similar to how you'd do it on L1 (offline receive to a key) and thus offers integration in an embedded manner without SN being on the hook for the custody. The only other thing that could enable that are bArk and npub.cash but these are even less mature and have similar issues. So bottom line there is a solution scarcity and this is a bid to potentially move away from some of the less optimal tradeoffs - from an SN and a newbie perspective - i.e. the ability to move past the CCs solution.
If we take SN not being the custodian as a non-negotiable, then there are other solutions and all of them are worse and IIRC would require partnership with a custodian. The other "fake L2" solutions are not going to change much; a user has similar risk on Liquid, and similar utxo-size economic exit prevention caveats on Ark. Thus there is no ideal solution. Spark is one of the not-ideal solutions.
So this isn't much going back to a situation where SN is a custodian; I don't think that that should be desirable anyway. I see this as the opposite direction: a forward one where SN holds less sats and credits that are 1:1 valued as sats, not more. I think that the thing that people fall over isn't so much the direction as the dependency on Spark in particular, and maybe the prominence of that in the onboarding process. I don't think that that is supposed to be a final state per se? It's just another experiment to see how this direction goes. Unfortunately, per k00b's words in the release post, the other ones aren't ready to get integrated, so it's this or there is no experiment. Since no one is forced to use it, it's fine with me. The disclaimers are good. I wish there were better alternatives.
I don't want to beat a dead horse, but coinos does not engage in the deceptive advertising that Spark does. Bitcoin doesn't need any more newbies getting rug pulled, particularly newbies who are told the wallet they are using is non custodial.
This whole conversation honestly feels to me like all of us shuffling deck chairs on the Titanic.
With ETFs and Saylor and banks holding bitcoin, bitcoin has bigger problems.
We'll all be paid handsomely to pretend "this is what adoption looks like." All anyone really gives a shit about is NGU.
All anyone really gives a shit about is NGU.
Perhaps I am still in the last waning stages of the flower of optimistic youth, but I don't think all bitcoiners are quite so degraded yet.
Many people here seem genuinely interested in figuring out how to use Bitcoin for a number of purposes (including making social media better).
I posted some days ago about all the various groups around the world pushing Bitcoin development forward #1551573, I don't know all of them personally, but the ones I have met struck me as sincere in their desire to increase the strength and usefulness of Bitcoin as freedom money.
Don't let the stupid Saylor boys and ETF heads convince you that everyone has sold out.
only tradeoffs
Key. Also,
the compliance issue
makes me wonder, how can spark be compliant here? because of the VTXO model?
I haven't seen any kyc required, so they must not be a license money transmitter.
Because they ride this little hole that is to date mostly unenforced, but every (US) legal counsel has been warning about since 2016: "if you can block a transaction, you're a custodian."
It's the same liability shifting into the void that the AI labs that are taking no responsibility for the actions of their models employ. "It wasn't me, it was the AI" -> "It wasn't me, it was the chain".
Just give me a tag: 🔓 custodial / 🔐 non-custodial next to each wallet and call it a day
You can't get on SN without a Lightning wallet to begin with, so what is a fake L2 wallet solving?
I assume you'll be paying for his admission to work around that, so he's your guest.
Since he's not going to set up a node, he's never going to use non-custodial Lightning. An SQL wallet is fine for this, cheaper and more reliable than Spark.
So again, fake L2 solved nothing.
Spark we are essentially back to where SN began with a custodial wallet users can access out of the box.
This couldn't be more wrong. It's extra fragility, extra fees, an extra trust layer.
And still doesn't answer for the fact you need sats to get on SN to begin with.
Since you're paying to onboard him, you're abdicating your responsibility as a host mid-journey. Like picking up up for the airport for a visit, and then dropping him off in the combat zone instead of bringing him back to catch his return flight.
The hospitable thing to do would be send him an invite link to your Lightning Pub, since that's where trust is already implicit.
I assume you'll be paying for his admission to work around that, so he's your guest
Sending an invite link with attached sats has worked for some of the people I've on boarded.
But my most successful approach so far has been to ask them to post a bio (which they can do without sats) and then zap it. Then, when they want to post, they already have sats (well, more precisely, they have CCs).
I am not convinced that an SQL wallet is more reliable than Spark. Seems to me that it all comes down to the operator (in both cases), and Spark has stronger incentives to keep things running.
It's extra fragility, extra fees, an extra trust layer.
Maybe this is where we disagree: I don't see Spark as an extra trust layer compared to a custodial lightning service. Nor do I see it as extra fragility. You are probably right about fees, though.
Spark as an extra trust layer compared to a custodial lightning service
I'm talking re:
where SN began with a custodial wallet
SN already wraps invoices and takes a percentage of payments, it's still a custodial intermediary (CC's never made sense to avoid the appearance of being custodial, but I digress...)
So Spark can't get us back to the original SN state, its no different than any other custodial wallet on top of the original trust in SN.
Nor do I see it as extra fragility
There's all the inherent Lightning fragility, plus the fake L2 swap fragility on top of that, which is also where the fees come from. Again, relative to SN internalizing.
A 3rd party SQL wallet vs. fake L2 you could argue is the same on the fragility side in theory, but not in practice. Abstracting a database over Bitcoin is inherently more complex than just using a database.
CLINK might already obviate the need to send a Lightning.Pub invite directly from ShockWallet
If you run a Pub and are using CLINK with SN, SN already has your Pub's nprofile.
SN also already tracks signup referrals.
The new CLINK enroll method could be used in SN to automatically provision a new users wallet on the referring users Pub automagically.
Use Pub on SN -> Refer users to SN -> New SN user is a Pub guests of yours.
The default case is slightly upgraded from CCs in my mind beca he can now send his sats to any other lightning wallet or to an on chain UTXO of he gets enough sats. Would you characterize the situation differently?
No, I wouldn't.
In fairness though, he probably won't set up an other LN wallet either, so then that pretty much just leaves him with one option, which is something like a boltz swap back on-chain.
I think my main gripe is the bastardisation of the notion of bitcoin custody.
Is a bitcoin on Spark a bearer asset in a similar manner to the old guard of Lightning wallets? It is hard for me to see it that way.
Thanks for these 2 sats. With respect to SN specifically, what do you think new users should use?
For instance, I have a prominent economist coming to do an AMA in October. He is not familiar with using Bitcoin. When he sets up his account, how should I advise him to proceed?
Options before this latest update were:
Now with Spark we are essentially back to where SN began with a custodial wallet users can access out of the box. The default case is slightly upgraded from CCs in my mind because he can now send his sats to any other lightning wallet or to an on chain UTXO of he gets enough sats. Would you characterize the situation differently?