Features

• Receiving to SegWit addresses provides fee savings, as sending these funds is possible using less base-block space. In Bitcoin, transaction fees are proportional to the transaction size in bytes.
• Receiving to bech32 addresses provides more fee savings than P2SH Segwit addresses.
• Sending to SegWit addresses is sometimes required in order to use more modern tools that dropped support for legacy addresses, often because of another core property of SegWit transactions: They are not malleable, meaning that the transaction ID cannot be changed “in transit” (on unconfirmed transactions).

• Compatibility: Recipients have to choose an address format and due to efficiency improvements, they will tend more and more to expect being paid to a Taproot address. Wallets supporting this are generally more compatible.

• Cheaper: Taproot allows for smaller transactions, especially for more complex uses of Bitcoin such as multi signature.

• More private: As public data of a complicated transaction is usually indistinguishable from that of a simple transactions, special uses “hide in a bigger crowd” and become more private.

• More efficient for offline wallets: Hardware wallets ususally have only a very limited knowledge of the funds being spent, with the user confirming amounts sent but only implicitly the fee being paid. When spending from Taproot, the fee becomes knowable to the offline wallet, making protection against fee overpayment easier.

Transactions on LN are

• instant: It usually takes less than five seconds to finish a transaction.
• cheap: Transactions usually cost a tiny percentage (0.1%) of the transferred amount and might also be free.
• micro payments: The unit of account on the LN is micro Satoshis (mSat) or 0.00000000001 BTC.

The client doesn’t need to download all the block chain.

Compared to SPV using bloom filters:

• Private: Avoid the leak of the client’s addresses to the full nodes it talks to. If the blocks are downloaded through TOR with new TOR identities for each request from different nodes, the privacy of this mode is almost as good as running a full node. An attacker would have to control a big part of the TOR network to still learn about which addresses are of interes.
• Fast: No re-scan of the full chain needed when importing a wallet. Compared to using an indexing server of the provider, it leaks no data to the provider

• Speed: Quick access to blockchain data. This wallet probably supports cold wallet spending or importing accounts

• Speed: Low bandwidth requirements. The servers can deliver data tailored to the client’s needs without overhead.

• Speed: Low CPU and storage requirements. As the server does the heavy-lifting, the client doesn’t have to.

• Privacy: Random full nodes cannot spy on the user.

• Privacy: TOR shields the client’s IP address and thus his real world location or identity from servers it talks to.

• Security: The wallet can remain offline for extended periods without danger of losing funds.

Always online lightning node with the convenience of a mobile app.

• no address reuse
• simple backup
• no vendor lock-in

• Accounting: Multiple accounts allow for easier separation of funds.
• Privacy: Using an account with a positive balance at all time makes it relatively easy for blockchain analysis companies to determine the full history of the wallet. By using multiple accounts, emptying them at times, the user can retain some privacy.

• Cheaper: Transactions can be sent with very low fee and if later a soon confirmation is desired, the fee can be increased which allows the user to use lower fees with more confidence and thus results in fee savings.
• Cheaper: RBF in combination with batching allows the wallet to batch transactions transparent to the user, making the individual payment cheaper in transaction fees.

In Bitcoin, transactions always empty the output of received, prior transactions, so called “unspent transaction outputs” or UTXOs. Without batching, sending to five recipients requires the creation of five transactions with their change outputs - if you don’t have the exact amount you want to send to the recipient, you send “change” to yourself. This change UTXO gets then immediately spent in the next transaction and so on, building a chain of transactions.

• Batching avoids creating intermediate outputs, making the transaction smaller and thus cheaper in terms of mining fees.
• Batching avoids building chains of transactions. If one were to pay more than ten recipients, the network would probably not broadcast the later transactions as only short chains of unconfirmed transactions are being handled by full nodes. Batching fixes that.

With keys from distinct devices or users, an attacker would have to compromise multiple devices or users at once. Multi signature thus allows to protect against one device catching a virus, one wallet having a backdoor (if the multi signature works across different providers’ wallets), one hardware wallet not being trusted (if hardware wallets can be used for multi signature), etc.

Easily accept receiving more coins without actually holding them.

Ease of use.

• privacy for you
• fungibility for all

Security: Splitting an app into a part that keeps the keys safe without access to leak them online and an app that has internet and all the rest can reduce the attack surface for the private keys. In theory this setup can be much more secure than the usual app that has both the private keys and internet access in one.

• Faster Transactions: Liquid provides faster and cheaper transactions compared to Bitcoin’s main chain, improving the user experience for certain use cases like transfer between exchanges that support Liquid.

• Enhanced Privacy: Through Confidential Transactions, Liquid hides the amounts and types of assets being transferred, offering greater privacy for its users.

• Asset Issuance: Users can issue and manage digital assets on the Liquid Network.