[taler-marketing] branch master updated: Taler vs lightning discussion

[gnunet]

This is an automated email from the git hooks/post-receive script.

dold pushed a commit to branch master
in repository marketing.

The following commit(s) were added to refs/heads/master by this push:
     new b6e7fda  Taler vs lightning discussion
b6e7fda is described below

commit b6e7fda1caf0f420e85c0506d3793285fb023d74
Author: Florian Dold <florian@dold.me>
AuthorDate: Thu Apr 15 17:49:55 2021 +0200

    Taler vs lightning discussion
---
 2021-taler-vs-lightning/taler-vs-lightning.md | 70 +++++++++++++++++++++++++++
 1 file changed, 70 insertions(+)

diff --git a/2021-taler-vs-lightning/taler-vs-lightning.md 
b/2021-taler-vs-lightning/taler-vs-lightning.md
new file mode 100644
index 0000000..93aa30d
--- /dev/null
+++ b/2021-taler-vs-lightning/taler-vs-lightning.md
@@ -0,0 +1,70 @@
+# Taler with blockchain adapter vs. Lightning
+
+## Lightning network
+
+The lightning network is an additional payment layer on top of Bitcoin.  Its
+goal is to settle transactions faster without involving a full transaction on
+the Blockckain every time that money is moved, because that would be slow and
+expensive.
+
+It works by establishing "payment channels" between two parties, where both
+parties "lock" an initial amount (say, Alice locks 2 BTC and Bob locks 1 BTC to
+create a channel).
+
+Signatures communicated outside of the blockchain change how money is allocated
+between the two sides of the payment channel.  Eventually a payment channel 
will
+be closed by submitting a multi-party signature of the latest allocation 
between
+the two parties to the Blockchain, and the locked money will be sent back to
+Alice/Bob according to the most recent allocation.
+
+A payment can be "routed" through a network of multiple bidirectional channels.
+If channels "Alice-Bob" and "Bob-Carol" exist and are funded, then Alice can
+send a payment to Carol over the route "Alice-Bob-Carol".
+
+
+Problems:
+
+* A payment can only be made if route made up of channels exists
+  between the payer and payee.
+* Participating in the Lightning Network requires the participants
+  to "lock" significant amounts of Bitcoin in a channel,
+  resulting in opportunity costs.
+* To participate in Lightning Network payments, the payer+payee either need
+  to run their own Bitcoin node (impossible for the average user)
+  or fully trust a third-party Lightning Network node.
+* Privacy of payments is unclear [1], and
+  there is no notion of "income transparency" for AML/KYC either.
+* Even though Lighning Network is theoretically decentralized,
+  it is tending towards centralization in practice [2].
+* Fraud attempts are possible, and need to be resolved via
+  a complex penalty system if channels are force-closed
+  without taking the latest allocation of funds into account
+
+## Taler with blockchain adapter
+
+Taler works by providing a central, trusted payment service provider that
+settles payments instantly via blind signature tokens.  It can work
+with Blockchain or any other lower-level settlement layer.
+
+* Taler requires participants to trust the operator
+  of the exchange, or at least the responsible auditor(s).
+  Trust is required until the payment is settled on-chain.
+* Payments are always possible and instant when both parties
+  trust the Taler exchange.  Route establishment can't fail,
+  payment channels can't be force-closed.
+* Taler covers more than just the settlement system: There is a wallet software
+  (including Anastasis) and the merchant backend, which serves as an
+  (on-premise or hosted) payment gateway that is easy to use for merchants.
+* There is no requirement to lock money up-front to participate.
+  Payer/payee only need a wallet, and do not need to
+  operate a node that needs to be permanently online.
+* Payments with Taler / T-BTC have clear privacy and income-transparency
+  guarantees, and are based on signed, digital contract terms
+  between the two parties.
+* T-BTC could be operated in two modes:  Custodial and non-custodial.
+  In the custodial version, the exchange would keep and fully manage the
+  users' Bitcoin, whereas in the non-custodial version, the user would
+  need their own Bitcoin address.
+
+[1] https://arxiv.org/abs/2003.12470
+[2] https://iopscience.iop.org/article/10.1088/1367-2630/aba062

-- 
To stop receiving notification emails like this one, please contact
gnunet@gnunet.org.