diff --git a/02_getting_started.asciidoc b/02_getting_started.asciidoc index ea330ac..d94fbd5 100644 --- a/02_getting_started.asciidoc +++ b/02_getting_started.asciidoc @@ -36,20 +36,46 @@ If users decide to outsource some functionality to a third party they usually gi Finally, those seeking simplicity and convenience, even at the expense of control and security, may choose a custodial Lightning wallet. This is the least technically challenging option, but it _undermines the trust model of cryptocurrency_ and should therefore be considered only as a stepping stone towards more control and self-reliance. -In <> we see the three broad categories of lightning wallets and the relative degree of control they offer to the user. +There are many ways wallets can be characterized or categorized. +The most important questions to ask about a specific wallet are: + +- Does this Lightning wallet have a full LN Node or does it use a third-party LN Node? +- Does this Lightning wallet have a full Bitcoin Node or does it use a third-party Bitcoin Node? footnote:[If a Lightning wallet uses a third-party Lightning node, it is this third-party Lightning node who decides how to communicate with Bitcoin. Hence, using a third-party Lightning node implies that you as a wallet user also use a third-party Bitcoin node. Only in the other case, when the Lightning wallet uses its own Lightning node, does the choice "full Bitcoin-node" vs. "thrid-party Bitcoin node" exist. ] +- Does this Lightning wallet store its own keys under user control (self-custody) or are the keys held be a third-party custodian? + +At the highest level of abstraction, question 1 and 3 are the most elementary ones. +From these two questions we can derive four possible categories. +We can place these four categories into a quadrant as seen in Table <>. +But remember that this is just one way of categorizing Lightning wallets. [[lnwallet-categories]] -.Broad Categories of "Lightning Wallets" +.Lightning Wallets Quadrant [options="header"] |=== -| Wallet Type | LN Node | Keystore/Custody | Technical Skill -| Full Node & Wallet | Full Node | Non-Custodial | High -| Non-Custodial Wallet | 3rd-party node | Non-Custodial | Medium -| Custodial Wallet | 3rd-party node | Custodial | Low +| | *Full LN Node* | *3rd-party LN Node* +| *Self-Custody* | Q1: High technical skill, least trust in 3rd parties, most permissionless | Q2: Below medium technical skills, below medium trust in 3rd parties, requires some permissions +| *Custodial* | Q3: Above medium technical skills, above medium trust in 3rd parties, requires some permissions | Q4: Low technical skills, high trust in 3rd parties, least permissionless |=== +Q3, quadrant 3, where a full LN node is used but the keys are held by a custodian is currently not common. +Future wallets from that quadrant would let a user worry about the operational aspects of their node, but then delegate the access to the keys to a third party which may use primarily cold storage. + Lightning wallets can be installed on a variety of devices, including laptops, servers, and mobile devices. To run a full Lightning node (one that participates in "gossip" and creates its own map of the network for path finding and routing) you will need to use a server or desktop computer, as mobile devices and laptops are usually not powerful enough in terms of capacity, processing, battery life, and connectivity. +The category "Third-party Ligntning Nodes" can again be subdivided into: + +- Lightweight: means that the Lightning Node is operated by a third party and that the wallet obtains the required information through an API that connects wallet and third-party LN node. +- None: means that not only is the Lightning Node operated by a third party but most of the wallet is operated by a third party in the cloud such that the wallet does not even need to make calls on a Lightning node API. + +These subcategories are used in Table <>. + +Other terms that need explanation in Table <> in column "Bitcoin Node" are: + +- Neutrino: Neutrino is a specific implementation of a protocol to get data from Bitcoin as outlined in BIP 157 and BIP 158. The Bitcoin Node is run by a third-party and accessed via "neutrino". +- Electrum: This means the wallet connects to an Electrum Server. The Bitcoin Node is run by a third-party and accessed via the "Electrum" protocol. +- Bitcoin Core: implementation of Bitcoin full node +- btcd: another implementation of Bitcoin full node + In <> we see some examples of currently popular Lightning node and wallet applications for different types of devices. // TODO: Add a lot more wallet/node examples, confirm the details for correctness @@ -58,13 +84,13 @@ In <> we see some examples of currently popular Lightning nod [options="header"] |=== | Application | Device | LN Node | Bitcoin Node | Keystore -| lnd | Server | Full Node | Bitcoin Core/btcd | User Control -| c-lightning | Server | Full Node | Bitcoin Core | User Control -| Eclair Server | Server | Full Node | Bitcoin Core/Electrum | User Control -| Zap Desktop | Desktop | Full Node | Bitcoin Core/btcd | User Control -| Eclair Mobile | Mobile | Lightweight | Electrum | User Control -| Breez Wallet | Mobile | Full Node | Bitcoin Core/btcd | User Control -| Phoenix Wallet | Mobile | Lightweight | Electrum | User Control +| lnd | Server | Full Node | Bitcoin Core/btcd | Self-Custody +| c-lightning | Server | Full Node | Bitcoin Core | Self-Custody +| Eclair Server | Server | Full Node | Bitcoin Core/Electrum | Self-Custody +| Zap Desktop | Desktop | Full Node | Neutrino | Self-Custody +| Eclair Mobile | Mobile | Lightweight | Electrum | Self-Custody +| Breez Wallet | Mobile | Full Node | Neutrino | Self-Custody +| Phoenix Wallet | Mobile | Lightweight | Electrum | Self-Custody | Blue Wallet | Mobile | None | None | Custodial |===