#Blitz Wallet quick hands-on
View quoted note →
Login to reply
Replies (10)
Spark毫无意义,愣是把自己加到L2
展开说说👀
都是用submarine swap🎭,lightning才是L2
The security of off-chain BTC is not uniform—counterparty risk increases in the following order: Lightning-Channel BTC → Ark BTC → Spark BTC → Liquid BTC → Cashu BTC → Custodial BTC.
The Lightning Network is a channel layer plus a routing layer. If you run your own channel, the routing layer lets you settle payments directly.
For the other five off-chain wallets, the operator shares its own Lightning channels with users, allowing them to send and receive Lightning payments.
Liquid example
• Paying — your wallet sends the same amount of L-BTC, and the operator pays the invoice through its channels.
• Receiving — the operator first receives BTC over Lightning, then sends you the equivalent L-BTC.
Liquid, Spark, and Ark can make users’ sending and receiving of Lightning payments atomic.
Lightning is the transport network—other off-chain solutions plug in as special nodes.

View quoted note →

Spark 第一次听说。确实感觉不好用。
will前两天转了一个Ark的最新协议文档,应该不是基于LN的上层应用,而是可以和LN互通的L2


Second Docs
Intro to the Ark protocol | Second Docs
A brief primer for the basic concepts of the Ark protocol. Learn the mechanics of how Ark makes bitcoin payments fast, cheap, and self-custodial.
Spark is a variant of Statechains.
Statechains are an original second-layer protocol originally developed by Ruben Somsen in 2018.
Statechains are a proposed off-chain system that allows a user (such as Alice) to delegate the ability to spend a UTXO to another user (Bob), who can then further delegate the spending authority to a third user (Carol), and so on.
The off-chain delegation operations are all performed using signature adaptors and the cooperation of a trusted third party who employs the eltoo mechanism—and their knowledge of every previous delegation—to ensure each new delegation uses a state number higher than any previously used state number. These incrementing state numbers ensure that an on-chain spend by the most recent delegate (Carol) can take precedence over spends by previous delegates (Alice and Bob), provided the trusted third party hasn’t colluded with a previous delegate to cheat.
Beyond collusion with a delegated signer (such as Alice or Bob), there is no way for the trusted third party to steal funds. A delegated signer can always spend the UTXO on-chain without needing permission from the trusted third party, arguably making Statechains less trusted than federated sidechains.
We can think of Statechains as a digital version of Opendime. We know that Statechains can’t provide the same trustless self-custody as the Lightning Network, but we still like them. Statechains can be part of the Lightning Network.
https://medium.com/@RubenSomsen/statechains-non-custodial-off-chain-bitcoin-transfer-1ae4845a4a39
https://bitcoinops.org/en/topics/statechains/
https://opendime.com/
https://bitcoinmagazine.com/technical/bitcoin-layer-2-statechains
https://www.spark.money/
View quoted note →
View quoted note →
If you operate your own Lightning channel, that’s the best case — you can use a fully native Lightning wallet.
If not, the five wallets mentioned above, each with their own tradeoffs, can still be used to send and receive Lightning payments by leveraging the service provider’s inbound liquidity. The difference lies in how “bitcoin” is stored under the hood — each takes a different form.
When both sender and receiver use the same provider and system, payments are typically settled internally without touching the Lightning Network. But if they’re on different providers, the payment is routed through the Lightning Network.
View quoted note →
View quoted note →
The counterparty risk for Wallet of Satoshi and Cashu users is that the server operator might run away with the funds. Liquid users face the risk that multiple federation members might collude to steal the funds. Spark users face the risk that the service providers might collude with the previous sender to double-spend the received funds. The counterparty risk for Ark is that if the user stays offline for too long and their VTXO expires, the service provider may be able to take control of it.
You could imagine a wallet that works like this: for balances under 1,000 sats, it uses Cashu; for amounts over 10,000 sats, it switches to Spark; for over 100,000 sats, it uses Ark; and once the balance exceeds 500,000 sats, it sets up a self-managed Lightning channel.
View quoted note →
View quoted note →
Just as a Cashu wallet mainly facilitates transfers within the mint, Spark also primarily handles internal transfers, with receiving and sending payments via the Lightning Network being relatively rare. Cashu, Spark, and Ark all use a server–client architecture, and the user experience for internal transfers can be very smooth.
Spark and Ark are both designed for users who do not have their own Lightning channels.
The Lightning Network remains the most secure option.
From a purely technical perspective, many so‑called Layer 2 designs aim to perform more actions off‑chain from a single on‑chain UTXO operation, thereby reducing the burden on the base layer. This is likely one reason they are grouped under the “Layer 2” label. However, my view comes from another angle.
When it comes to Bitcoin usage, most alternatives to Lightning require introducing a pre‑defined third‑party trust model. These third parties are ultimately legal entities, which means that the assets flowing within such systems are only nominally Bitcoin. Service providers in these designs often have the ability to censor or freeze transactions under certain circumstances. Even if users retain some form of unilateral exit, Bitcoin itself is inherently supra‑sovereign, whereas the security of these systems falls below that threshold. In contrast, Lightning transactions represent actual Bitcoin, and the risk of attack is highly localized. By comparison, centralized service providers present larger attack surfaces.
From this perspective, I see non‑Lightning solutions more as on‑chain extensions that trade some security for additional functionality, whereas Lightning is the only true Layer 2. For most users, the majority of their Bitcoin will likely remain either on‑chain or in Lightning channels, rather than locked in these alternative systems, which act more like specialized functionality bridges.
In terms of design, compatibility with Lightning atomic swaps exists mainly for interoperability; in practical payment use cases, these solutions tend to operate around Lightning rather than replace it.
我也觉得Spark没什么意义,和闪电同期生才这发展水平,用户其实已经投票了,很多时候技术只是其中一方面。
这些方案都是围绕在闪电周围通过原子互换去兼容,就支付而言,不兼容闪电可以直接去投胎了,最终用户钱其实还是留在链上和闪电上。闪电是超主权的,其他方案都是主权以下的,这一个区别就拉开层次了。
Ark目前看很不错,看后续发展了,比较担心ASP中心化甚至趋向高度中心化。
The Lightning Network remains the most secure option.
From a purely technical perspective, many so‑called Layer 2 designs aim to perform more actions off‑chain from a single on‑chain UTXO operation, thereby reducing the burden on the base layer. This is likely one reason they are grouped under the “Layer 2” label. However, my view comes from another angle.
When it comes to Bitcoin usage, most alternatives to Lightning require introducing a pre‑defined third‑party trust model. These third parties are ultimately legal entities, which means that the assets flowing within such systems are only nominally Bitcoin. Service providers in these designs often have the ability to censor or freeze transactions under certain circumstances. Even if users retain some form of unilateral exit, Bitcoin itself is inherently supra‑sovereign, whereas the security of these systems falls below that threshold. In contrast, Lightning transactions represent actual Bitcoin, and the risk of attack is highly localized. By comparison, centralized service providers present larger attack surfaces.
From this perspective, I see non‑Lightning solutions more as on‑chain extensions that trade some security for additional functionality, whereas Lightning is the only true Layer 2. For most users, the majority of their Bitcoin will likely remain either on‑chain or in Lightning channels, rather than locked in these alternative systems, which act more like specialized functionality bridges.
In terms of design, compatibility with Lightning atomic swaps exists mainly for interoperability; in practical payment use cases, these solutions tend to operate around Lightning rather than replace it.
View quoted note →