diff --git a/.gitbook/assets/01-cyphernode.png b/.gitbook/assets/01-cyphernode.png new file mode 100644 index 0000000..72c6e5c Binary files /dev/null and b/.gitbook/assets/01-cyphernode.png differ diff --git a/.gitbook/assets/01a-cyphernode.png b/.gitbook/assets/01a-cyphernode.png new file mode 100644 index 0000000..120600a Binary files /dev/null and b/.gitbook/assets/01a-cyphernode.png differ diff --git a/.gitbook/assets/02-cyphernode.png b/.gitbook/assets/02-cyphernode.png new file mode 100644 index 0000000..a63513c Binary files /dev/null and b/.gitbook/assets/02-cyphernode.png differ diff --git a/.gitbook/assets/03-cyphernode.png b/.gitbook/assets/03-cyphernode.png new file mode 100644 index 0000000..bc982d9 Binary files /dev/null and b/.gitbook/assets/03-cyphernode.png differ diff --git a/.gitbook/assets/04-cyphernode.png b/.gitbook/assets/04-cyphernode.png new file mode 100644 index 0000000..c46774e Binary files /dev/null and b/.gitbook/assets/04-cyphernode.png differ diff --git a/.gitbook/assets/amp-figure01.png b/.gitbook/assets/amp-figure01.png new file mode 100644 index 0000000..5cad819 Binary files /dev/null and b/.gitbook/assets/amp-figure01.png differ diff --git a/.gitbook/assets/amp-figure02.png b/.gitbook/assets/amp-figure02.png new file mode 100644 index 0000000..94b50db Binary files /dev/null and b/.gitbook/assets/amp-figure02.png differ diff --git a/.gitbook/assets/amp-figure03.png b/.gitbook/assets/amp-figure03.png new file mode 100644 index 0000000..ae8934a Binary files /dev/null and b/.gitbook/assets/amp-figure03.png differ diff --git a/.gitbook/assets/amp-figure04.png b/.gitbook/assets/amp-figure04.png new file mode 100644 index 0000000..a03dbff Binary files /dev/null and b/.gitbook/assets/amp-figure04.png differ diff --git a/.gitbook/assets/amp-figure05 (1).png b/.gitbook/assets/amp-figure05 (1).png new file mode 100644 index 0000000..5afecd5 Binary files /dev/null and b/.gitbook/assets/amp-figure05 (1).png differ diff --git a/.gitbook/assets/amp-figure05.png b/.gitbook/assets/amp-figure05.png new file mode 100644 index 0000000..5afecd5 Binary files /dev/null and b/.gitbook/assets/amp-figure05.png differ diff --git a/.gitbook/assets/amp-figure06.png b/.gitbook/assets/amp-figure06.png new file mode 100644 index 0000000..74d19f1 Binary files /dev/null and b/.gitbook/assets/amp-figure06.png differ diff --git a/.gitbook/assets/amp-figure07.png b/.gitbook/assets/amp-figure07.png new file mode 100644 index 0000000..7091517 Binary files /dev/null and b/.gitbook/assets/amp-figure07.png differ diff --git a/.gitbook/assets/amp-figure08.png b/.gitbook/assets/amp-figure08.png new file mode 100644 index 0000000..2bf2152 Binary files /dev/null and b/.gitbook/assets/amp-figure08.png differ diff --git a/.gitbook/assets/amp-figure09.png b/.gitbook/assets/amp-figure09.png new file mode 100644 index 0000000..d996cbd Binary files /dev/null and b/.gitbook/assets/amp-figure09.png differ diff --git a/.gitbook/assets/amp-figure10.png b/.gitbook/assets/amp-figure10.png new file mode 100644 index 0000000..e295b74 Binary files /dev/null and b/.gitbook/assets/amp-figure10.png differ diff --git a/.gitbook/assets/amp-figure11.png b/.gitbook/assets/amp-figure11.png new file mode 100644 index 0000000..9f2e6f0 Binary files /dev/null and b/.gitbook/assets/amp-figure11.png differ diff --git a/.gitbook/assets/bitcoin.conf b/.gitbook/assets/bitcoin.conf new file mode 100644 index 0000000..34cb089 --- /dev/null +++ b/.gitbook/assets/bitcoin.conf @@ -0,0 +1,14 @@ +# server=1 tells bitcoind to accept JSON-RPC commands +server=1 + +# Enable publish raw block in
+zmqpubrawblock=tcp://127.0.0.1:28332 + +# Enable publish raw transaction in +zmqpubrawtx=tcp://127.0.0.1:28333 + +# On client-side, you add the normal user/password pair to send commands: +rpcuser=rpcuser_here_844585 + +# change this password +rpcpassword=rpcpassword_here_12574 \ No newline at end of file diff --git a/.gitbook/assets/btcpay4aws-01 (1).png b/.gitbook/assets/btcpay4aws-01 (1).png new file mode 100644 index 0000000..a4b4933 Binary files /dev/null and b/.gitbook/assets/btcpay4aws-01 (1).png differ diff --git a/.gitbook/assets/btcpay4aws-01.png b/.gitbook/assets/btcpay4aws-01.png new file mode 100644 index 0000000..391b383 Binary files /dev/null and b/.gitbook/assets/btcpay4aws-01.png differ diff --git a/.gitbook/assets/btcpay4aws-01b.png b/.gitbook/assets/btcpay4aws-01b.png new file mode 100644 index 0000000..021e192 Binary files /dev/null and b/.gitbook/assets/btcpay4aws-01b.png differ diff --git a/.gitbook/assets/btcpay4aws-02 (1).png b/.gitbook/assets/btcpay4aws-02 (1).png new file mode 100644 index 0000000..493f2ad Binary files /dev/null and b/.gitbook/assets/btcpay4aws-02 (1).png differ diff --git a/.gitbook/assets/btcpay4aws-02.png b/.gitbook/assets/btcpay4aws-02.png new file mode 100644 index 0000000..493f2ad Binary files /dev/null and b/.gitbook/assets/btcpay4aws-02.png differ diff --git a/.gitbook/assets/btcpay4aws-03 (1).png b/.gitbook/assets/btcpay4aws-03 (1).png new file mode 100644 index 0000000..83d1c0e Binary files /dev/null and b/.gitbook/assets/btcpay4aws-03 (1).png differ diff --git a/.gitbook/assets/btcpay4aws-03.png b/.gitbook/assets/btcpay4aws-03.png new file mode 100644 index 0000000..83d1c0e Binary files /dev/null and b/.gitbook/assets/btcpay4aws-03.png differ diff --git a/.gitbook/assets/btcpay4aws-04 (1).png b/.gitbook/assets/btcpay4aws-04 (1).png new file mode 100644 index 0000000..b0fc7b5 Binary files /dev/null and b/.gitbook/assets/btcpay4aws-04 (1).png differ diff --git a/.gitbook/assets/btcpay4aws-04.png b/.gitbook/assets/btcpay4aws-04.png new file mode 100644 index 0000000..b0fc7b5 Binary files /dev/null and b/.gitbook/assets/btcpay4aws-04.png differ diff --git a/.gitbook/assets/btcpay4aws-05 (1).png b/.gitbook/assets/btcpay4aws-05 (1).png new file mode 100644 index 0000000..52da0c4 Binary files /dev/null and b/.gitbook/assets/btcpay4aws-05 (1).png differ diff --git a/.gitbook/assets/btcpay4aws-05.png b/.gitbook/assets/btcpay4aws-05.png new file mode 100644 index 0000000..52da0c4 Binary files /dev/null and b/.gitbook/assets/btcpay4aws-05.png differ diff --git a/.gitbook/assets/btcpay4aws-06 (1).png b/.gitbook/assets/btcpay4aws-06 (1).png new file mode 100644 index 0000000..104541b Binary files /dev/null and b/.gitbook/assets/btcpay4aws-06 (1).png differ diff --git a/.gitbook/assets/btcpay4aws-06 (2).png b/.gitbook/assets/btcpay4aws-06 (2).png new file mode 100644 index 0000000..907d26f Binary files /dev/null and b/.gitbook/assets/btcpay4aws-06 (2).png differ diff --git a/.gitbook/assets/btcpay4aws-06 (3).png b/.gitbook/assets/btcpay4aws-06 (3).png new file mode 100644 index 0000000..0d01afb Binary files /dev/null and b/.gitbook/assets/btcpay4aws-06 (3).png differ diff --git a/.gitbook/assets/btcpay4aws-06.png b/.gitbook/assets/btcpay4aws-06.png new file mode 100644 index 0000000..907d26f Binary files /dev/null and b/.gitbook/assets/btcpay4aws-06.png differ diff --git a/.gitbook/assets/btcpay4aws-06a.png b/.gitbook/assets/btcpay4aws-06a.png new file mode 100644 index 0000000..fd514ac Binary files /dev/null and b/.gitbook/assets/btcpay4aws-06a.png differ diff --git a/.gitbook/assets/btcpay4aws-06b.png b/.gitbook/assets/btcpay4aws-06b.png new file mode 100644 index 0000000..b0b9f36 Binary files /dev/null and b/.gitbook/assets/btcpay4aws-06b.png differ diff --git a/.gitbook/assets/btcpay4aws-07 (1).png b/.gitbook/assets/btcpay4aws-07 (1).png new file mode 100644 index 0000000..bcb0c2b Binary files /dev/null and b/.gitbook/assets/btcpay4aws-07 (1).png differ diff --git a/.gitbook/assets/btcpay4aws-07.png b/.gitbook/assets/btcpay4aws-07.png new file mode 100644 index 0000000..bcb0c2b Binary files /dev/null and b/.gitbook/assets/btcpay4aws-07.png differ diff --git a/.gitbook/assets/btcpay4aws-08 (1).png b/.gitbook/assets/btcpay4aws-08 (1).png new file mode 100644 index 0000000..c0254a9 Binary files /dev/null and b/.gitbook/assets/btcpay4aws-08 (1).png differ diff --git a/.gitbook/assets/btcpay4aws-08.png b/.gitbook/assets/btcpay4aws-08.png new file mode 100644 index 0000000..c0254a9 Binary files /dev/null and b/.gitbook/assets/btcpay4aws-08.png differ diff --git a/.gitbook/assets/btcpay4aws-09 (1).png b/.gitbook/assets/btcpay4aws-09 (1).png new file mode 100644 index 0000000..c9c7c5b Binary files /dev/null and b/.gitbook/assets/btcpay4aws-09 (1).png differ diff --git a/.gitbook/assets/btcpay4aws-09.png b/.gitbook/assets/btcpay4aws-09.png new file mode 100644 index 0000000..c9c7c5b Binary files /dev/null and b/.gitbook/assets/btcpay4aws-09.png differ diff --git a/.gitbook/assets/btcpay4aws-10 (1).png b/.gitbook/assets/btcpay4aws-10 (1).png new file mode 100644 index 0000000..a9d6cff Binary files /dev/null and b/.gitbook/assets/btcpay4aws-10 (1).png differ diff --git a/.gitbook/assets/btcpay4aws-10.png b/.gitbook/assets/btcpay4aws-10.png new file mode 100644 index 0000000..a9d6cff Binary files /dev/null and b/.gitbook/assets/btcpay4aws-10.png differ diff --git a/.gitbook/assets/btcpay4aws-10a (1).png b/.gitbook/assets/btcpay4aws-10a (1).png new file mode 100644 index 0000000..71e7c88 Binary files /dev/null and b/.gitbook/assets/btcpay4aws-10a (1).png differ diff --git a/.gitbook/assets/btcpay4aws-10a.png b/.gitbook/assets/btcpay4aws-10a.png new file mode 100644 index 0000000..71e7c88 Binary files /dev/null and b/.gitbook/assets/btcpay4aws-10a.png differ diff --git a/.gitbook/assets/btcpay4aws-10b (1).png b/.gitbook/assets/btcpay4aws-10b (1).png new file mode 100644 index 0000000..ef542a2 Binary files /dev/null and b/.gitbook/assets/btcpay4aws-10b (1).png differ diff --git a/.gitbook/assets/btcpay4aws-10b.png b/.gitbook/assets/btcpay4aws-10b.png new file mode 100644 index 0000000..ef542a2 Binary files /dev/null and b/.gitbook/assets/btcpay4aws-10b.png differ diff --git a/.gitbook/assets/btcpay4aws-11 (1).png b/.gitbook/assets/btcpay4aws-11 (1).png new file mode 100644 index 0000000..d6e6480 Binary files /dev/null and b/.gitbook/assets/btcpay4aws-11 (1).png differ diff --git a/.gitbook/assets/btcpay4aws-11.png b/.gitbook/assets/btcpay4aws-11.png new file mode 100644 index 0000000..d6e6480 Binary files /dev/null and b/.gitbook/assets/btcpay4aws-11.png differ diff --git a/.gitbook/assets/btcpay4aws-12 (1).png b/.gitbook/assets/btcpay4aws-12 (1).png new file mode 100644 index 0000000..69fa6c7 Binary files /dev/null and b/.gitbook/assets/btcpay4aws-12 (1).png differ diff --git a/.gitbook/assets/btcpay4aws-12.png b/.gitbook/assets/btcpay4aws-12.png new file mode 100644 index 0000000..69fa6c7 Binary files /dev/null and b/.gitbook/assets/btcpay4aws-12.png differ diff --git a/.gitbook/assets/btcpay4aws-13 (1).png b/.gitbook/assets/btcpay4aws-13 (1).png new file mode 100644 index 0000000..7fddc52 Binary files /dev/null and b/.gitbook/assets/btcpay4aws-13 (1).png differ diff --git a/.gitbook/assets/btcpay4aws-13.png b/.gitbook/assets/btcpay4aws-13.png new file mode 100644 index 0000000..7fddc52 Binary files /dev/null and b/.gitbook/assets/btcpay4aws-13.png differ diff --git a/.gitbook/assets/btcpay4aws-14 (1).png b/.gitbook/assets/btcpay4aws-14 (1).png new file mode 100644 index 0000000..2064865 Binary files /dev/null and b/.gitbook/assets/btcpay4aws-14 (1).png differ diff --git a/.gitbook/assets/btcpay4aws-14.png b/.gitbook/assets/btcpay4aws-14.png new file mode 100644 index 0000000..2064865 Binary files /dev/null and b/.gitbook/assets/btcpay4aws-14.png differ diff --git a/.gitbook/assets/btcpay4aws-15 (1).png b/.gitbook/assets/btcpay4aws-15 (1).png new file mode 100644 index 0000000..afbe27c Binary files /dev/null and b/.gitbook/assets/btcpay4aws-15 (1).png differ diff --git a/.gitbook/assets/btcpay4aws-15.png b/.gitbook/assets/btcpay4aws-15.png new file mode 100644 index 0000000..afbe27c Binary files /dev/null and b/.gitbook/assets/btcpay4aws-15.png differ diff --git a/.gitbook/assets/btcpay4aws-16 (1).gif b/.gitbook/assets/btcpay4aws-16 (1).gif new file mode 100644 index 0000000..d1a16ca Binary files /dev/null and b/.gitbook/assets/btcpay4aws-16 (1).gif differ diff --git a/.gitbook/assets/btcpay4aws-16.gif b/.gitbook/assets/btcpay4aws-16.gif new file mode 100644 index 0000000..d1a16ca Binary files /dev/null and b/.gitbook/assets/btcpay4aws-16.gif differ diff --git a/.gitbook/assets/btcpay4aws-17 (1).gif b/.gitbook/assets/btcpay4aws-17 (1).gif new file mode 100644 index 0000000..adb9eb1 Binary files /dev/null and b/.gitbook/assets/btcpay4aws-17 (1).gif differ diff --git a/.gitbook/assets/btcpay4aws-17.gif b/.gitbook/assets/btcpay4aws-17.gif new file mode 100644 index 0000000..adb9eb1 Binary files /dev/null and b/.gitbook/assets/btcpay4aws-17.gif differ diff --git a/.gitbook/assets/btcpay4aws-18 (1).png b/.gitbook/assets/btcpay4aws-18 (1).png new file mode 100644 index 0000000..0299162 Binary files /dev/null and b/.gitbook/assets/btcpay4aws-18 (1).png differ diff --git a/.gitbook/assets/btcpay4aws-18.png b/.gitbook/assets/btcpay4aws-18.png new file mode 100644 index 0000000..0299162 Binary files /dev/null and b/.gitbook/assets/btcpay4aws-18.png differ diff --git a/.gitbook/assets/btcpay4aws-19 (1).png b/.gitbook/assets/btcpay4aws-19 (1).png new file mode 100644 index 0000000..9c878ff Binary files /dev/null and b/.gitbook/assets/btcpay4aws-19 (1).png differ diff --git a/.gitbook/assets/btcpay4aws-19.png b/.gitbook/assets/btcpay4aws-19.png new file mode 100644 index 0000000..9c878ff Binary files /dev/null and b/.gitbook/assets/btcpay4aws-19.png differ diff --git a/.gitbook/assets/btcpay4aws-20.png b/.gitbook/assets/btcpay4aws-20.png new file mode 100644 index 0000000..92fb18b Binary files /dev/null and b/.gitbook/assets/btcpay4aws-20.png differ diff --git a/.gitbook/assets/btcpay4aws-21.png b/.gitbook/assets/btcpay4aws-21.png new file mode 100644 index 0000000..7a839d0 Binary files /dev/null and b/.gitbook/assets/btcpay4aws-21.png differ diff --git a/.gitbook/assets/channel-capacity.png b/.gitbook/assets/channel-capacity.png new file mode 100644 index 0000000..015e92a Binary files /dev/null and b/.gitbook/assets/channel-capacity.png differ diff --git a/.gitbook/assets/chjannel-flow.png b/.gitbook/assets/chjannel-flow.png new file mode 100644 index 0000000..76bd418 Binary files /dev/null and b/.gitbook/assets/chjannel-flow.png differ diff --git a/.gitbook/assets/image (1).png b/.gitbook/assets/image (1).png new file mode 100644 index 0000000..80ef192 Binary files /dev/null and b/.gitbook/assets/image (1).png differ diff --git a/.gitbook/assets/image (2).png b/.gitbook/assets/image (2).png new file mode 100644 index 0000000..c57d168 Binary files /dev/null and b/.gitbook/assets/image (2).png differ diff --git a/.gitbook/assets/image.png b/.gitbook/assets/image.png new file mode 100644 index 0000000..8913c0c Binary files /dev/null and b/.gitbook/assets/image.png differ diff --git a/.gitbook/assets/key-movement.png b/.gitbook/assets/key-movement.png new file mode 100644 index 0000000..2fa1d6b Binary files /dev/null and b/.gitbook/assets/key-movement.png differ diff --git a/.gitbook/assets/lightningpoll.png b/.gitbook/assets/lightningpoll.png new file mode 100644 index 0000000..890eeb8 Binary files /dev/null and b/.gitbook/assets/lightningpoll.png differ diff --git a/.gitbook/assets/lnd-home-00.png b/.gitbook/assets/lnd-home-00.png new file mode 100644 index 0000000..0f29027 Binary files /dev/null and b/.gitbook/assets/lnd-home-00.png differ diff --git a/.gitbook/assets/lnd-home-01.png b/.gitbook/assets/lnd-home-01.png new file mode 100644 index 0000000..276e7e3 Binary files /dev/null and b/.gitbook/assets/lnd-home-01.png differ diff --git a/.gitbook/assets/lnd-home-02.png b/.gitbook/assets/lnd-home-02.png new file mode 100644 index 0000000..79e821b Binary files /dev/null and b/.gitbook/assets/lnd-home-02.png differ diff --git a/.gitbook/assets/lnd-home-02b.png b/.gitbook/assets/lnd-home-02b.png new file mode 100644 index 0000000..c2fcbab Binary files /dev/null and b/.gitbook/assets/lnd-home-02b.png differ diff --git a/.gitbook/assets/lnd-home-02c.png b/.gitbook/assets/lnd-home-02c.png new file mode 100644 index 0000000..d77b06b Binary files /dev/null and b/.gitbook/assets/lnd-home-02c.png differ diff --git a/.gitbook/assets/lnd-home-02d.gif b/.gitbook/assets/lnd-home-02d.gif new file mode 100644 index 0000000..17dc109 Binary files /dev/null and b/.gitbook/assets/lnd-home-02d.gif differ diff --git a/.gitbook/assets/lnd-home-03.png b/.gitbook/assets/lnd-home-03.png new file mode 100644 index 0000000..c6bee36 Binary files /dev/null and b/.gitbook/assets/lnd-home-03.png differ diff --git a/.gitbook/assets/lnd-home-04.png b/.gitbook/assets/lnd-home-04.png new file mode 100644 index 0000000..16b3a4e Binary files /dev/null and b/.gitbook/assets/lnd-home-04.png differ diff --git a/.gitbook/assets/lnd-home-05.gif b/.gitbook/assets/lnd-home-05.gif new file mode 100644 index 0000000..474d9d0 Binary files /dev/null and b/.gitbook/assets/lnd-home-05.gif differ diff --git a/.gitbook/assets/lnd-home-06.png b/.gitbook/assets/lnd-home-06.png new file mode 100644 index 0000000..aa6effd Binary files /dev/null and b/.gitbook/assets/lnd-home-06.png differ diff --git a/.gitbook/assets/lnd-home-07.gif b/.gitbook/assets/lnd-home-07.gif new file mode 100644 index 0000000..742dc07 Binary files /dev/null and b/.gitbook/assets/lnd-home-07.gif differ diff --git a/.gitbook/assets/lnd-home-08.gif b/.gitbook/assets/lnd-home-08.gif new file mode 100644 index 0000000..4e9fda0 Binary files /dev/null and b/.gitbook/assets/lnd-home-08.gif differ diff --git a/.gitbook/assets/lnd-home-09.png b/.gitbook/assets/lnd-home-09.png new file mode 100644 index 0000000..3a5c4fd Binary files /dev/null and b/.gitbook/assets/lnd-home-09.png differ diff --git a/.gitbook/assets/lnd-home-10.png b/.gitbook/assets/lnd-home-10.png new file mode 100644 index 0000000..e219379 Binary files /dev/null and b/.gitbook/assets/lnd-home-10.png differ diff --git a/.gitbook/assets/lnd-home-11.png b/.gitbook/assets/lnd-home-11.png new file mode 100644 index 0000000..fda1d23 Binary files /dev/null and b/.gitbook/assets/lnd-home-11.png differ diff --git a/.gitbook/assets/lnd-home-12.png b/.gitbook/assets/lnd-home-12.png new file mode 100644 index 0000000..961cab0 Binary files /dev/null and b/.gitbook/assets/lnd-home-12.png differ diff --git a/.gitbook/assets/lnd-home-13.png b/.gitbook/assets/lnd-home-13.png new file mode 100644 index 0000000..66719ad Binary files /dev/null and b/.gitbook/assets/lnd-home-13.png differ diff --git a/.gitbook/assets/local-lightning.png b/.gitbook/assets/local-lightning.png new file mode 100644 index 0000000..11b47ac Binary files /dev/null and b/.gitbook/assets/local-lightning.png differ diff --git a/.gitbook/assets/logo.png b/.gitbook/assets/logo.png new file mode 100644 index 0000000..9f5610f Binary files /dev/null and b/.gitbook/assets/logo.png differ diff --git a/.gitbook/assets/payment-path.png b/.gitbook/assets/payment-path.png new file mode 100644 index 0000000..aa17f40 Binary files /dev/null and b/.gitbook/assets/payment-path.png differ diff --git a/.gitbook/assets/peek-2019-10-30-23-38.gif b/.gitbook/assets/peek-2019-10-30-23-38.gif new file mode 100644 index 0000000..7e8cb69 Binary files /dev/null and b/.gitbook/assets/peek-2019-10-30-23-38.gif differ diff --git a/.gitbook/assets/photo_2019-12-06_12-38-15.jpg b/.gitbook/assets/photo_2019-12-06_12-38-15.jpg new file mode 100644 index 0000000..150e878 Binary files /dev/null and b/.gitbook/assets/photo_2019-12-06_12-38-15.jpg differ diff --git a/.gitbook/assets/screen-shot-2019-06-13-at-2.38.11-pm.png b/.gitbook/assets/screen-shot-2019-06-13-at-2.38.11-pm.png new file mode 100644 index 0000000..bae02fa Binary files /dev/null and b/.gitbook/assets/screen-shot-2019-06-13-at-2.38.11-pm.png differ diff --git a/.gitbook/assets/screen-shot-2019-06-13-at-2.41.48-pm.png b/.gitbook/assets/screen-shot-2019-06-13-at-2.41.48-pm.png new file mode 100644 index 0000000..0720803 Binary files /dev/null and b/.gitbook/assets/screen-shot-2019-06-13-at-2.41.48-pm.png differ diff --git a/.gitbook/assets/screen-shot-2019-06-13-at-3.10.28-pm.png b/.gitbook/assets/screen-shot-2019-06-13-at-3.10.28-pm.png new file mode 100644 index 0000000..7998a49 Binary files /dev/null and b/.gitbook/assets/screen-shot-2019-06-13-at-3.10.28-pm.png differ diff --git a/.gitbook/assets/screen-shot-2019-06-19-at-2.24.27-pm.png b/.gitbook/assets/screen-shot-2019-06-19-at-2.24.27-pm.png new file mode 100644 index 0000000..e6e220f Binary files /dev/null and b/.gitbook/assets/screen-shot-2019-06-19-at-2.24.27-pm.png differ diff --git a/.gitbook/assets/screen-shot-2019-06-19-at-2.25.18-pm.png b/.gitbook/assets/screen-shot-2019-06-19-at-2.25.18-pm.png new file mode 100644 index 0000000..53f4f03 Binary files /dev/null and b/.gitbook/assets/screen-shot-2019-06-19-at-2.25.18-pm.png differ diff --git a/.gitbook/assets/screen-shot-2019-06-19-at-2.36.50-pm.png b/.gitbook/assets/screen-shot-2019-06-19-at-2.36.50-pm.png new file mode 100644 index 0000000..ec51e64 Binary files /dev/null and b/.gitbook/assets/screen-shot-2019-06-19-at-2.36.50-pm.png differ diff --git a/.gitbook/assets/screen-shot-2019-06-19-at-3.07.47-pm.png b/.gitbook/assets/screen-shot-2019-06-19-at-3.07.47-pm.png new file mode 100644 index 0000000..d9d485e Binary files /dev/null and b/.gitbook/assets/screen-shot-2019-06-19-at-3.07.47-pm.png differ diff --git a/.gitbook/assets/screenshot_20191129-170112.png b/.gitbook/assets/screenshot_20191129-170112.png new file mode 100644 index 0000000..d4c1dec Binary files /dev/null and b/.gitbook/assets/screenshot_20191129-170112.png differ diff --git a/.gitbook/assets/tiphub.png b/.gitbook/assets/tiphub.png new file mode 100644 index 0000000..82949e3 Binary files /dev/null and b/.gitbook/assets/tiphub.png differ diff --git a/.gitbook/assets/tiphubui.png b/.gitbook/assets/tiphubui.png new file mode 100644 index 0000000..8493ab4 Binary files /dev/null and b/.gitbook/assets/tiphubui.png differ diff --git a/README.md b/README.md index d9f658a..efc69d5 100644 --- a/README.md +++ b/README.md @@ -1,18 +1,56 @@ -# Welcome +--- +description: Learn. Share. Accelerate Lightning. +--- + +# ⚡Welcome to our Lightning Wiki⚡ + +## Featured Articles + +{% tabs %} +{% tab title="Onboarding" %} +* [What is the Lightning Network?](tech/lightning/lightning-network.md) +* [Lightning Wallets](tutorials/wallets/) +* [Bootstrapping Lightning Channels](tutorials/bootstrapping-liquidity.md) +* [Lightning with Tor](tutorials/nodes/tor.md) +* [Understanding Lightning Invoices](tech/lightning/invoice.md) +* [LND \(Lightning Network Daemon\)](tutorials/nodes/lnd.md) +{% endtab %} + +{% tab title="Apps" %} +* [Bitcoin Testnet Lightning Network](tutorials/altcoin/bitcoin-testnet-ln.md) +* [Litecoin Lightning Network](tutorials/altcoin/litecoin.md) +* [Spacebit Satellite Client](tutorials/apps/spacebit-satellite-client.md) +* [Lightning Torch](tutorials/apps/lightning-torch.md) +* [Lightning Tipping Sites](tutorials/apps/tipping-sites.md) +{% endtab %} + +{% tab title="R&D" %} +* [Atomic Multi-Path Payments \(AMP\)](tech/research/atomic-multi-path-payments.md) +* [Lightning Hardware Appliances](tech/research/lightning-appliance.md) +* [Watchtower Services](tech/research/watchtowers.md) +* [Trustless Layer1-Layer2 \(Submarine\) Swaps](tech/research/submarine-swap.md) +* [Macaroons for LND Authentication](tech/research/macaroons.md) +* [Channel Backup](tech/channels/channel-backups.md) +{% endtab %} +{% endtabs %} + +## Welcome to the ION Lightning Network Wiki! + +The Lightning Network is here, and it's delivering **fast, free, and final Bitcoin payments**.  -## Welcome to the Ion Wiki! +The number of nodes—and the amount of bitcoin—are increasing daily, and developers are creating new applications to experiment with the network and explore its possibilities. -The Lightning Network needed a wiki yesterday. By creating digestible, reliable, and objective knowledge covering concepts and developments in LN, we can help drive the next wave of innovation and adoption. +But as the resources for building with Lightning proliferate, they are spread across numerous GitHub repositories, Subreddits, Slack and Telegram chats, and Medium articles. -### Contributing [](http://makeapullrequest.com) +ION wiki is a tool for **collecting the best Lightning Network tutorials, references, tools, and apps** in one place. -Want to help us build this nexus of information? Start by reading our [contributing guide](https://github.com/RadarRelay/ionwiki/blob/master/contributing.md), and taking a look at our [GitHub repo](https://github.com/RadarRelay/ionwiki/commits/master). +## [Contributing](wiki-basics/contributing.md) [](http://makeapullrequest.com) -We welcome all contributions. Submit any ideas, bug reports, or organizational changes as [GitHub issues](https://github.com/RadarRelay/ionwiki/issues) and submit content changes as [pull requests](https://github.com/RadarRelay/ionwiki/pulls). +Know something about Lightning? **Share your know-how** and accelerate the rate of LN development. -### Content License +#### [**This wiki lives in GitHub**](wiki-basics/content-license.md) and is Creative Commons licensed! It's your Lightning lab notebook—it's not locked in someone else's database. -We use the **Creative Commons Attribution 4.0 International** license for the Ion wiki. [Take a look at our rationale and view the license here](content-license.md). +Check out the [**top contributors on GitHub**](https://github.com/RadarTech/ionwiki/graphs/contributors) and join the discussion [**on Telegram**](https://t.me/radarion). diff --git a/SUMMARY.md b/SUMMARY.md index f544754..ccea077 100644 --- a/SUMMARY.md +++ b/SUMMARY.md @@ -1,61 +1,104 @@ # Table of contents -* [Welcome](README.md) -* [How To Contribute](contributing.md) -* [How This Content is Licensed](content-license.md) -* [Bitcoin Basics](bitcoin-basics/README.md) - * [Satoshi \(unit of currency\)](bitcoin-basics/satoshi-unit-of-currency.md) - * [Fees](bitcoin-basics/fees.md) - * [Coin Faucets](bitcoin-basics/faucet.md) - * [Digital Signatures](bitcoin-basics/signatures-on-lightning.md) - * [Hash](bitcoin-basics/hash.md) - * [Preimage](bitcoin-basics/pre-image.md) - * [Opcodes](bitcoin-basics/op-codes.md) - * [HTLC](bitcoin-basics/hltc.md) - * [Dust](bitcoin-basics/dust-limit.md) - * [Transaction Malleability](bitcoin-basics/transaction-malleability.md) - * [Bitcoin Address Formats](bitcoin-basics/bitcoin-address-formats.md) - * [Pubkey](bitcoin-basics/pubkey.md) - * [Replace-By-Fee \(RBF\)](bitcoin-basics/replace-by-fee-rbf.md) - * [State Channels](bitcoin-basics/state-channel.md) -* [Lightning Basics](lightning-basics/README.md) - * [What is the Lightning Network?](lightning-basics/lightning-network.md) - * [Basis of Lightning Technology \(BOLT\)](lightning-basics/basics-of-lightning-technology-bolt.md) - * [Onion Routing](lightning-basics/onion-routing.md) - * [Network Capacity](lightning-basics/network-capacity.md) - * [Node](lightning-basics/node.md) - * [Payment Channel](lightning-basics/payment-channel.md) - * [Payment Routing](lightning-basics/payment-routing.md) - * [Gossip](lightning-basics/gossip.md) - * [Hub](lightning-basics/hub.md) - * [Invoice](lightning-basics/invoice.md) - * [Sphinx Packet](lightning-basics/sphinx-packet.md) -* [Lightning Software](lightning-software/README.md) - * [Network Implementations](lightning-software/implementations-of-lightning-network.md) - * [LND](lightning-software/lnd/README.md) - * [Macaroon](lightning-software/lnd/macaroon.md) - * [c-lightning](lightning-software/c-lightning.md) - * [Eclair](lightning-software/eclair.md) - * [Rust Lightning](lightning-software/rust-lightning.md) - * [Wallet](lightning-software/wallet/README.md) - * [Eclair](lightning-software/wallet/eclair.md) - * [Shango](lightning-software/wallet/shango.md) - * [Zap Desktop](lightning-software/wallet/zap-desktop.md) -* [Lightning Channels](lightning-channels/README.md) - * [Channel Capacity](lightning-channels/channel-capacity.md) - * [Opening A Channel](lightning-channels/channel-opening.md) - * [Closing A Channel](lightning-channels/channel-closing.md) - * [Channel Backup](lightning-channels/channel-backups.md) -* [Troubleshooting](troubleshooting/README.md) - * [Payment failures](troubleshooting/payment-failures.md) - * [Error codes](troubleshooting/error-codes.md) - * [Theft \(on Lightning Network\)](troubleshooting/theft-on-lightning-network.md) -* [Lightning R&D](lightning-r-and-d/README.md) - * [Lightning Appliance](lightning-r-and-d/lightning-appliance.md) - * [Submarine Swap](lightning-r-and-d/submarine-swap.md) - * [Watchtowers](lightning-r-and-d/watchtower.md) - * [Channel Factories](lightning-r-and-d/channel-factory.md) - * [Eltoo](lightning-r-and-d/eltoo.md) - * [Scriptless Scripts \(Schnorr\)](lightning-r-and-d/scriptless-scripts-schnorr.md) - * [Privacy \(on Lightning Network\)](lightning-r-and-d/privacy-on-lightning-network.md) +* [⚡Welcome to our Lightning Wiki⚡](README.md) + +## Wiki Basics + +* [How To Contribute](wiki-basics/contributing.md) +* [Platform & Content License](wiki-basics/content-license.md) + +## Events + +* [Boltathon LN Hackathon](events/boltathon/README.md) + * [TipHub](events/boltathon/tiphub.md) + * [Lightning Poll](events/boltathon/lightning-poll.md) + * [Local Lightning](events/boltathon/local-lightning.md) + * [Lightning Mapper](events/boltathon/lightning-mapper.md) + * [Somebody Make This!](events/boltathon/somebody-make-this.md) + * [Bolt Action](events/boltathon/bolt-action.md) + +## Tutorials + +* [Bootstrapping Liquidity](tutorials/bootstrapping-liquidity.md) +* [Nodes To Connect To](tutorials/routing-nodes.md) +* [Lightning Exchanges](tutorials/lightning-exchanges.md) +* [Lightning Stores](tutorials/stores.md) +* [Lightning Apps](tutorials/apps/README.md) + * [Spacebit Satellite Client](tutorials/apps/spacebit-satellite-client.md) + * [Lightning Pizza Walkthrough](tutorials/apps/lightning-pizza-walkthrough.md) + * [Lightning Torch](tutorials/apps/lightning-torch.md) + * [Tipping Sites](tutorials/apps/tipping-sites.md) +* [Lightning Wallets](tutorials/wallets/README.md) + * [Zap Desktop](tutorials/wallets/zap-desktop.md) + * [Eclair Mobile](tutorials/wallets/eclair-mobile.md) + * [Shango](tutorials/wallets/shango.md) +* [Lightning Node Setup](tutorials/nodes/README.md) + * [Lightning at Home](tutorials/nodes/lighting-at-home.md) + * [BTCPay Server + AWS EC2](tutorials/nodes/btcpay-+-aws-ec2.md) + * [Cyphernode](tutorials/nodes/cyphernode.md) + * [ION Drive](tutorials/nodes/ion-drive.md) + * [LND](tutorials/nodes/lnd.md) + * [c-lightning](tutorials/nodes/c-lightning.md) + * [Eclair](tutorials/nodes/eclair.md) + * [Rust Lightning](tutorials/nodes/rust-lightning.md) + * [Lightning with Tor](tutorials/nodes/tor.md) +* [Altcoin Lightning](tutorials/altcoin/README.md) + * [Bitcoin Testnet LN](tutorials/altcoin/bitcoin-testnet-ln.md) + * [Litecoin LN](tutorials/altcoin/litecoin.md) + * [Decred LN](tutorials/altcoin/decred.md) +* [Troubleshooting](tutorials/troubleshooting/README.md) + * [Public Nodes](tutorials/troubleshooting/public-nodes.md) + * [Payment failures](tutorials/troubleshooting/payment-failures.md) + * [Error codes](tutorials/troubleshooting/error-codes.md) + * [Theft \(on Lightning Network\)](tutorials/troubleshooting/theft-on-lightning-network.md) + * [Static Channel Backup](tutorials/troubleshooting/static-channel-backups.md) + +## Lightning Technology + +* [Bitcoin Basics](tech/bitcoin/README.md) + * [Satoshi \(unit of currency\)](tech/bitcoin/satoshi-unit-of-currency.md) + * [Fees](tech/bitcoin/fees.md) + * [Coin Faucets](tech/bitcoin/faucet.md) + * [Digital Signatures](tech/bitcoin/signatures-on-lightning.md) + * [Hash](tech/bitcoin/hash.md) + * [Preimage](tech/bitcoin/pre-image.md) + * [Opcodes](tech/bitcoin/op-codes.md) + * [HTLC](tech/bitcoin/hltc.md) + * [Dust](tech/bitcoin/dust-limit.md) + * [Transaction Malleability](tech/bitcoin/transaction-malleability.md) + * [Bitcoin Address Formats](tech/bitcoin/bitcoin-address-formats.md) + * [Pubkey](tech/bitcoin/pubkey.md) + * [Replace-By-Fee \(RBF\)](tech/bitcoin/replace-by-fee-rbf.md) + * [State Channels](tech/bitcoin/state-channel.md) +* [Lightning Basics](tech/lightning/README.md) + * [What is the Lightning Network?](tech/lightning/lightning-network.md) + * [Basis of Lightning Technology \(BOLT\)](tech/lightning/basics-of-lightning-technology-bolt.md) + * [Onion Routing](tech/lightning/onion-routing.md) + * [Network Capacity](tech/lightning/network-capacity.md) + * [Node](tech/lightning/node.md) + * [Payment Channel](tech/lightning/payment-channel.md) + * [Payment Routing](tech/lightning/payment-routing.md) + * [Gossip](tech/lightning/gossip.md) + * [Hub](tech/lightning/hub.md) + * [Lightning Invoice](tech/lightning/invoice.md) + * [Sphinx Packet](tech/lightning/sphinx-packet.md) +* [Lightning Channels](tech/channels/README.md) + * [Channel Capacity](tech/channels/channel-capacity.md) + * [Opening A Channel](tech/channels/channel-opening.md) + * [Closing A Channel](tech/channels/channel-closing.md) + * [Channel Backup](tech/channels/channel-backups.md) +* [Research and Development](tech/research/README.md) + * [Key Send](tech/research/sphinx-send.md) + * [Hold Invoices](tech/research/hodl-invoice.md) + * [Watchtowers](tech/research/watchtowers.md) + * [Privacy](tech/research/privacy.md) + * [Macaroons](tech/research/macaroons.md) + * [Submarine Swap](tech/research/submarine-swap.md) + * [Lightning Appliances](tech/research/lightning-appliance.md) + * [Channel Factories](tech/research/channel-factory.md) + * [Scriptless Scripts](tech/research/scriptless-scripts-schnorr.md) + * [Hardware Wallets](tech/research/hardware-wallets.md) + * [Atomic Multi-Path Payments](tech/research/atomic-multi-path-payments.md) + * [Eltoo](tech/research/eltoo.md) +* [Lightning News Sources](tech/news.md) diff --git a/bitcoin-basics/hash.md b/bitcoin-basics/hash.md deleted file mode 100644 index 7d0108e..0000000 --- a/bitcoin-basics/hash.md +++ /dev/null @@ -1,41 +0,0 @@ ---- -latest-revision: '2019-01-27T00:00:00.000Z' -original-author: Ryan Shea (ryan-shea) -created: '2019-01-01T00:00:00.000Z' -status: Accepted -title: Hash -contributors: Ryan Shea (ryan-shea); Gareth James (gjradar) -type: article -description: '' -discussions-to: GitHub URL -category: bitcoin-basics ---- - -# Hash - -## Overview - -A hash algorithm turns an arbitrary amount of data into a fixed-length **hash**. A hash is a fingerprint of the input data, and the same fingerprint can always be produced from the same input data. Hashes are essential to cryptographic functions not only on Bitcoin but also on the Lightning Network. - -## Details - -### Bitcoin Hashes - -Cryptographic hash functions are used extensively in Bitcoin: in bitcoin addresses, in script addresses, and in the mining Proof-of-Work algorithm. Bitcoin uses the SHA-256 algorithm to generate hashes. - -### Private and Public Keys - - - -In private and public key cryptography, a one-way cryptographic hash function is used to generate a bitcoin address. - -## Resources - -[SHA-256 Hash Generator](https://www.movable-type.co.uk/scripts/sha256.html) - -## References - -\[1\] [https://en.bitcoin.it/wiki/Hash](https://en.bitcoin.it/wiki/Hash) - -\[2\] [https://en.wikipedia.org/wiki/Cryptographic\_hash\_function](https://en.wikipedia.org/wiki/Cryptographic_hash_function) - diff --git a/content-license.md b/content-license.md deleted file mode 100644 index c03ec82..0000000 --- a/content-license.md +++ /dev/null @@ -1,14 +0,0 @@ -# How This Content is Licensed - -The Ion Wiki uses the **CC-BY-4.0** license to govern our content. Our main priority is to preserve the rights of individuals outside Radar that choose to contribute -- acknowledging their time investment and effort in contributing to such a far-reaching project. - -We also want to prevent the use of the wiki name in a fashion that is not consistent with its branding. - -Both of these priorities are best incarnated in the CC-BY license, outlined by [Creative Commons](https://creativecommons.org/). - -You can read the license below: - -{% hint style="info" %} -[Link to GitHub](https://github.com/RadarRelay/ionwiki/blob/master/LICENSE) -{% endhint %} - diff --git a/contributing.md b/contributing.md deleted file mode 100644 index 10e24c2..0000000 --- a/contributing.md +++ /dev/null @@ -1,92 +0,0 @@ -# How To Contribute - -## Introduction - -Thank you for considering contributing to the Ion Wiki. It's people like you that will pave the way for the next wave of Lightning developers and enthusiasts. - -Following these guidelines helps to establish a standard for high quality, useful content that will last for years to come. Establishing a nexus of information for the Lightning Network is needed; we're all here to make that happen in an organized, high quality way. - -### What type of contributions we're looking for - -Ion is an open source project and we love to receive contributions from our community! - -We're looking for support in the following areas: - -* Content creation -* Proofreading -* Improving stub articles -* Content research and roadmapping - -# [Click here to get started.](https://github.com/RadarTech/ionwiki/tree/master/.contributing/starthere.md) - -## Your First Contribution - -Unsure where to start? You can start by looking through these beginner and help-wanted issues: - -* [Beginner issues - issues which are great to start with](https://github.com/RadarRelay/ionwiki/issues?q=is%3Aopen+is%3Aissue+label%3A%22good+first+issue%22) -* [Help wanted issues - issues which should be a bit more involved than beginner issues.](https://github.com/RadarRelay/ionwiki/issues?q=is%3Aopen+is%3Aissue+label%3A%22help+wanted%22) - -### Never contributed to open source before? - -Check out the following resources to get you started. It's way easier than it looks. - -* [A Guide to Open Source](https://opensource.guide/) -* [How to Contribute to an Open Source Project on GitHub](https://egghead.io/series/how-to-contribute-to-an-open-source-project-on-github) -* [How to Make a Pull Request](http://makeapullrequest.com/) - -At this point, you're ready to make your changes! Feel free to ask for help; everyone is a beginner at first. - -## Getting started - -#### How to submit a contribution on GitHub - -Start by forking the Ion Wiki repo. From there, either: - -1. Create an article using the [template](https://github.com/RadarRelay/ionwiki/blob/master/template.md) in the root directory -2. Edit or revise existing articles -3. Move and restructure content - -As a rule of thumb, changes are obvious fixes if they do not introduce any new pages or structural organization. Some likely examples include the following: - -* Spelling / grammar fixes -* Typo correction, white space and formatting changes -* Comment clean up -* Adding notes in raw files for future contributors -* Changes to organizational files like Issue Templates, Contribution Guide, Table of Contents, etc. -* Moving files from one directory to another, restructuring page flow and organization - -After committing your changes, make a PR to the main repo and briefly describe your changes. - -#### How to contribute via GitBook - -Since we're using GitBook to manage our wiki, you can also submit content through the Gitbook GUI. - -Start by: - -1. Creating an account on GitBook -2. Opening a new draft and editing content in the draft -3. Saving the draft on GitBook with naming conventions - -We will be reviewing GitBook contributions with the same pipeline as GitHub contributions. Discussions will be posted in issue threads and PR discussions. - -#### Suggestion process - -If you find yourself searching for content that doesn't exist in the Ion Wiki, you're probably not alone. There are bound to be others out there with similar needs. Open an issue on GitHub describing the content you'd like to see, and we'll get on it in our next sprint. - -## Review process - -The core contributing team looks at Pull Requests on a regular basis and discusses content decisions in a weekly triage meeting that we hold in a public Google Hangout. The hangout is announced in the weekly status updates sent in the Ion Wiki developer chat. - -After feedback has been given, we anticipate responses within two weeks. After two weeks, we may close the pull request if it isn't showing any activity. If no feedback is needed, we'll merge the PR and credit you accordingly. - -For non-trivial contributions, pull requests should sit for at least 36 hours to ensure that contributors in other timezones have time to review. Consideration should also be given to weekends and other holiday periods to ensure active committers all have reasonable time to become involved in the discussion and review process if they wish. - -The default for each contribution is that it is accepted once no committer has an objection. During review committers may also request that a specific contributor who is most versed in a particular area takes a look before the PR can be merged. There is no additional "sign off" process for contributions to land. Once all issues brought by committers are addressed it can be landed by any committer. - -In the case of an objection being raised in a pull request by another committer, all involved committers should seek to arrive at a consensus by way of addressing concerns being expressed by discussion, compromise on the proposed change, or withdrawal of the proposed change. - -If a contribution is controversial and committers cannot agree about how to get it to land or if it should land then it will be escalated to the Ion Core team. Ion members will regularly discuss pending contributions in order to find a resolution. It is expected that only a small minority of issues be brought to the Ion Core team for resolution and that discussion and compromise among committers be the default resolution mechanism. - -## Outreach - -Have content or other suggestions, but aren't a fan of GitHub? You can reach us directly at outreach@ion.radar.tech. diff --git a/events/boltathon/README.md b/events/boltathon/README.md new file mode 100644 index 0000000..dc40949 --- /dev/null +++ b/events/boltathon/README.md @@ -0,0 +1,6 @@ +# Boltathon LN Hackathon + +{% embed url="https://boltathon.com/" %} + +\*\*\*\*[**Radar ION**](https://ion.radar.tech) was a sponsor of the 2019 Boltathon, the first virtual Lightning Network hackathon. In this page, you will find interviews with the Boltathon projects, links to speaker slides, and more! + diff --git a/events/boltathon/bolt-action.md b/events/boltathon/bolt-action.md new file mode 100644 index 0000000..5072b5f --- /dev/null +++ b/events/boltathon/bolt-action.md @@ -0,0 +1,29 @@ +# Bolt Action + + + + +**What inspired you to build Bolt Action?** + +I got inspired to start building on Lightning after experimenting with it early on, it seemed obvious to me that it will eventually be integrated into our lives like most other web protocols. The internet of money has found its HTTPS in my opinion. + +**In three sentences or less, tell us about your project.** + +Bolt Action was intended to be a concept demo showing how a lightning node could seamlessly fit into a social network. The name is a pun, Bolt of course for lightning, Bolt Action inferring a GUN. GUN is a decentralized database I'm using to build a social layer for lightning. + +**How did you build Bolt Action?** + +I ended up only having a few hours to devote to the hackathon, so I scratched out an agent in NodeJS and a view in React. + +**What are your plans for the project post hackathon?** + +I'm ultimately working on ShockWallet, which will integrate GUN and a number of social/commerce features it enables in a decentralized and trust-less way. \([http://shock.network](http://shock.network/)\) + +**What daemon features are you most excited about?** + +Atomic Multipath Payments, I think that will have a really large impact on UX that enables increased adoption. + + **What projects are you most excited about this next year?** + +The progress on the chain and lightning daemons aside, there are some potentially disruptive applications out there centered around lightning, such as SuredBits using it for monetizing API calls, to Koala Studios and Donner Lab adding a whole new element to the gaming scene. ShockWallet should be pretty cool too :\) + diff --git a/events/boltathon/lightning-mapper.md b/events/boltathon/lightning-mapper.md new file mode 100644 index 0000000..8c322b5 --- /dev/null +++ b/events/boltathon/lightning-mapper.md @@ -0,0 +1,34 @@ +# Lightning Mapper + +**What inspired you to build Lightning Mapper?** + +My main motivation was to take advantage of the learning environment that hackathons provide. I decided to build Lightning Mapper because of my background in geographic information systems. I had recently been using the mobile app "MapSwipe", where users volunteer their time to indicate whether or not certain features exist in portions of satellite images. When I saw the theme was "social good", I decided to implement a similar model to MapSwipe in the browser using Lightning payments to incentivize users. + +**In three sentences or less, tell us about your project.** + +In Lightning Mapper, users are paid to view satellite imagery and digitize features, such as roads and buildings, by drawing over them in the map. The digitized features can be used to help humanitarian groups locate people in need. Users can withdraw their earnings via Lightning Network at any time. + +**How did you build Lightning Mapper?** + +I built Lightning Mapper using a combination of open source tools: Blockstack Auth for authentication, Leaflet.js for mapping, NodeJS for webserver, Python and c-lightning for processing Lightning invoices and payments. + +**What were the biggest development challenges?** + +My background is not in software development, so learning to piece the different components together was challenging. + +**What operational challenges have you run into since launch?** + +Finding the time to finish the project. + +**What are your plans for the project post hackathon?** + +Unfortunately I wont be able to spend a lot of time working on Lightning Mapper in the near future, so I plan to shelve it for a bit. I will eventually finish and publish the source code, and potentially do a public launch if there is demand. + +**What projects are you most excited about this next year?** + +I'm most excited for the continuing work on the Lightning protocol itself as well as the major implementations. It's very important for these to be working well to have a healthy Lightning Network, and there is some exciting development coming in the next year! + +**Where can we find code or working application of your project?** + +Unfortunately it isn't ready to be released yet. When I do release it, I will be announcing it [on my Twitter account @billy\_btc](https://twitter.com/billy_btc). + diff --git a/events/boltathon/lightning-poll.md b/events/boltathon/lightning-poll.md new file mode 100644 index 0000000..ecc9e68 --- /dev/null +++ b/events/boltathon/lightning-poll.md @@ -0,0 +1,34 @@ +# Lightning Poll + + + +**What inspired you to build Lightning Poll?** + +I think that the Lightning Network is fascinating because it addresses some of the pain points associated with on chain transactions, without compromising the trustless nature of Bitcoin. The most apparent strength of the Lightning Network is micropayments, as many of the projects at Boltathon illustrated. I have been following the HODL invoices pull request for a while, because I think that the ease of refund they provide is another significant on chain pain point which lightning addresses. Pairing micropayments and easy refunds is exciting to me because it opens up possibilities which were previously unfeasible, and I wanted to explore ways in which this functionality could be used. + +**In three sentences or less, tell us about your project.** + +Lightning poll is a twist on the traditional votes-for-sats concept. Users can create polls with a refund strategy which refunds a certain set of users depending on the outcome of the vote. The hackathon theme was "hack social interaction", which lightning poll aligns with in the use case where content producers ask their followers what content they would like to see next, earn some sats from the majority vote and refund the voters whose choice doesn't get produced. + +**How did you build Lightning Poll?** + +Lightning poll is written in Golang, using a web framework called Gin and GOnic. I built LND with the HODL invoices tag, and used it to create refundable invoices for votes. I decided against using traditional login, because it is an annoying barrier when you're doing something as simple as creating a poll. Instead, a zero invoice \(which can be settled with any amount\) is required to create a poll, because we do not know how much will be paid out to the creator until after the poll is closed and users are refunded. + +**What were the biggest development challenges?** + +HODL invoices in LND are a new feature, and do not fit into the existing API. I assumed that they would be, and ended up having to backtrack a fair amount when I realised that they use a separate, and differently setup, set of endpoints. + +**What are your plans for the project post hackathon?** + +I am planning on launching lightning poll on mainnet. I have synced up a bitcoind and LND node, so just need to find the time to un-hack some of the more hacakthon-esque parts of lightning poll's code and then it will be up and running. + +**What daemon features are you most excited about?** + +I'm pretty excited for AMP, because I think it will really improve routing of bigger payments. Conner Fromknecht's Botlathon talk about watchtowers was also very exciting, because it opens up opportunities for mobile lightning apps, which I think are going to be a big part of driving the success of lightning. + +**What projects are you most excited about this next year?** + +I have been accepted into the Chaincode Bitcoin and Lightning Summer Residency, where we will have the opportunity to work on mentored projects contributing to Bitcoin Core or LND. I am going to look into extracting the signer interface from LND so that your private keys can sit separately from your LND node, which I am very excited about. + +**Hacking HODL invoices at \#Bothathon 2019** [https://medium.com/@kirkcohenc/hacking-hodl-invoices-at-bothathon-2019-7c540ccfa1ee](https://medium.com/@kirkcohenc/hacking-hodl-invoices-at-bothathon-2019-7c540ccfa1ee) + diff --git a/events/boltathon/local-lightning.md b/events/boltathon/local-lightning.md new file mode 100644 index 0000000..114f6ba --- /dev/null +++ b/events/boltathon/local-lightning.md @@ -0,0 +1,46 @@ +# Local Lightning + + + +**What inspired your team to work on Local Lightning?** + +At the time of the hackathon, I wasn't sure what to build. I spent a couple hours after hearing the "Social Good" prompt just brainstorming ideas and speaking to a few friends about it. Patrick Stanley from Blockstack had actually sent me a Blockstack post about a list of applications that could be built on Blockstack and one of the first ones was a decentralized Local Bitcoins. As soon as I saw that, I knew it was what I had to do. I already have some experience building a P2P decentralized application on Blockstack, so I knew a simple MVP of Local Lightning would work out well and definitely has a real-world use case, which mattered a lot to me. I'm all about marketplace freedom, which unfortunately with Local Bitcoins and with many crypto projects implementing KYC, is needed more and more each day. + +**In three sentences or less, tell us about your project.** + +Local Lightning is a website designed to get local sellers and buyers of bitcoin interacting with each other on the Lightning Network. By focusing on sellers/buyers interacting via the Lightning Network, what we'll see is quick engagements that end as soon as cash changes hands and the Lightning payment button is clicked. Instantly verifiable, \(near\) fee-less transactions with no need for escrows or waiting 10-60 minutes for block confirmations. + +**How did you build Local Lightning?** + +I built Local Lightning on top of Blockstack \(which allows for decentralized logins and data ownership for users\) and Lightning Charge. Lightning Charge made it easy to accept and query invoices via my own c-lightning node. For the hackathon, I made it a simple skeleton VueJS application, but have since put a lot of design effort into it to make it pretty. + +**What were the biggest development challenges?** + +The biggest challenge wasn't so much the development at all, but the interactions with Lightning tools. When I was trying to implement WebLN \(a web standard for browser plugin lightning payments\), I had a hard time finding things that supported c-lightning. Seems like a lot of tools/wallets in this space support LND instead of c-lightning. I was about to give up on trying to implement WebLN until fiatjaf \(another hackathon participant\) pointed out that he made a c-lightning WebLN compliant plugin \(kWh\), which worked out really well. + +**What operational challenges have you run into since launch?** + +I've never been the strongest at design and frontend in general, but I'd have to say that Lighting Channel management has been pretty challenging since launching. Luckily, with BTCPayServer, setting up a production level Lightning Node was easy, but since I am using c-lightning instead of LND, I miss out on a lot of channel management features like Loop Out. I have some ideas to bring more liquidity channels to my Lightning Node, without relying on people to open channels with me directly \(though there have been a couple kind souls that have already!\), but in general it hasn't as easy to deal with so far. + +**What are your plans for the project post hackathon?** + +The first plan was to design and launch, which I'm super excited that I was able to do so! Moving forward though, I hope to add possible core features such as messaging, review systems, and maybe even basic wallet support for connecting to your own nodes in app. Besides that, I hope to integrate with the community and provide an app and features that people want to use. + + +**What daemon features are you most excited about?** + +It just technically launched, but I'm really excited to try out Loop Out with LND. My home node is using LND, so I planned on upgrading soon to try it out. Besides that, I wanted to look into what plugins exist for c-lightning and what might come soon there as well. + + +**What projects are you most excited about this next year?** + +I'm really excited about the idea of submarine swap exchanges with lightning. I recently found out about SparkSwap and their Lightning exchange, so I'm looking forward to seeing it grow and using it. + + +**Where can we find code or working application of your project?** + +Website: [https://www.locallightning.net](https://www.locallightning.net) + +Github: [https://github.com/AnthonyRonning/Local-Lightning](https://github.com/AnthonyRonning/Local-Lightning) + + diff --git a/events/boltathon/somebody-make-this.md b/events/boltathon/somebody-make-this.md new file mode 100644 index 0000000..3adf9c3 --- /dev/null +++ b/events/boltathon/somebody-make-this.md @@ -0,0 +1,30 @@ +# Somebody Make This! + +**What inspired you to build Somebody Make This!** + +It was something I've wanted to do for some time, because I had some ideas and, mostly for Lightning-powered apps, and wanted to see them done. If more people shared my judgement that these were interesting ideas then it would be an incentive for builders everywhere, including myself. I then expanded this idea to a broader scope, but I think it just remains the same. + +**How did you build Somebody Make This!?** + +I wrote a "smart contract" on [https://etleneum.com/](https://etleneum.com/) with some lines of Lua, wrote some tests for it, then begin writing a purely-client side interface to it with JavaScript. + +**What were the biggest development challenges?** + +The time. I didn't have much time to work on it on that specific weekend, I spent all the time I could, but it wasn't enough. + +**What operational challenges have you run into since launch?** + +I didn't work on it since the hackathon. It needs quite a bit to be presentable. I spent too much of my brain on it during that weekend so I had to take a break. Only now I'm starting to think about it again. + +**What are your plans for the project post hackathon?** + +I'll finish the JavaScript interface and see if the community likes it. + +**What projects are you most excited about this next year?** + +I'm actually expecting Bitcoin to get mainstream interest again with new high prices or financial turmoils in the real world, hoping that will bring more people to the Lightning economy. + +**Where can we find code or working application of your project?** + +The "backend" code is at [https://etleneum.com/contract/94aj7mkrk](https://etleneum.com/contract/94aj7mkrk), the frontend will be published anytime soon. + diff --git a/events/boltathon/tiphub.md b/events/boltathon/tiphub.md new file mode 100644 index 0000000..c8bfb3a --- /dev/null +++ b/events/boltathon/tiphub.md @@ -0,0 +1,47 @@ +# TipHub + + + + + +**What inspired you and Carl to build TipHub?** + +We've both been really interested in alternative funding models for open source work. Maintaining open source projects has never been a lucrative endeavor in its own right, but the value of incentivizing it can't be understated. The majority of code today is written on top of open source languages, frameworks, and operating systems, and we need to continue to encourage people to keep contributing and maintaining. While we don't expect TipHub \(or any tip-based funding\) to completely solve the problem, a little bit of money and a nice message can sometimes be enough to keep someone passionate about working on their project. + +**In three sentences or less, tell us about your project.** + +TipHub is a non-custodial tipping service for open source projects. We make it easy to setup a tip button right in your project's readme to let users and other developers show some love to your project. Unlike most other Lightning tipping services, we facilitate a direct connection to developer's nodes. + + +**How did you build TipHub?** + +Our stack is a python backend using Flask and SQLAlchemy with a Postgres database, and a frontend written in Typescript using React and the Semantic UI component library. Carl focused on the backend and Lightning RPC layer, while I focused on the API and frontend. It's currently hosted on Heroku. + + +**What were the biggest development challenges?** + +Lightning developer libraries are still pretty early and sparse. The choice of Python for the backend was just something we were familiar with, but in general we found that the libraries available around Lightning, and Python and Flask's less-than-stellar handling of threading or asynchronous code made it less easy than we'd hoped. I won't speak for Carl on this, but personally I've found the Javascript \(better yet, Typescript\) tooling to be a little stronger so far, and its async-first approach to code makes working with sockets to the Lightning node and client a much better developer experience overall. + +**What operational challenges have you run into since launch** + +We haven't launched quite yet, and one of the things holding us back is making absolutely sure we handle all of the issues that can occur with accounting for tipping. While we're safe in the fact that users can never "lose" money since it's a direct tip to the developer's node with no intermediary, we want to make sure that it all gets logged correctly \(Since we record and notify when tips are made,\) or lets them know if something has gone wrong \(e.g. if their node is offline.\) + +**What are your plans for the project post hackathon?** + +The plan is to go live sometime in the next few weeks! As noted above, we want to be ready for everything that can go wrong with Lightning, and clean up some of our hackathon sins that made it in in the final hours. We've also got a handful of features planned such as on-chain fallback addresses for non-lightning users or those who want to make larger tips, and an embeddable leaderboard to show your project's highest tippers. Here's what that'd look like: + + + + + + + + +**What daemon features are you most excited about?** + +There are too many to go over, so I'll just pick one: The macaroon "bakery." LND provides you with auth tokens that have different levels of access called macaroons. It works similarly to oauth, giving external applications limited functionality. That's how TipHub is able to generate invoices for your node, without having access to do things such as make payments from your node, keeping your funds secure. The idea of the macaroon bakery would be a programmatic way of generating these macaroons. So one cool example of how this could work in the future is that you generate a macaroon that is only allowed to send a limited number of satoshis per month. Provide that macaroon to an external service, and now they can pull a monthly subscription directly from your node, that you can revoke at any time. + +**What projects are you most excited about this next year?** + +Lightning is moving so fast, it's hard to see what's coming beyond a few weeks. But stabilizing mainnet neutrino nodes to allow for easier setup is going to make Lightning absolutely explode, so I'm excited to onboard all of those new users. Likewise, so far most of what we've seen with Lightning have been built by solo enthusiasts, so I'm looking forward to what larger teams with will be able to put together once there's a much larger audience to attract them to building on Lightning. And hopefully, more hackathons like the Boltathon! + diff --git a/lightning-channels/channel-closing.md b/lightning-channels/channel-closing.md deleted file mode 100644 index b1ee04c..0000000 --- a/lightning-channels/channel-closing.md +++ /dev/null @@ -1,47 +0,0 @@ ---- -latest-revision: '2019-01-27T00:00:00.000Z' -original-author: Ryan Shea (ryan-shea) -created: '2019-01-01T00:00:00.000Z' -status: Accepted -title: Channel Closing -contributors: Ryan Shea (ryan-shea); Gareth James (gjradar) -type: article -description: '' -discussions-to: GitHub URL -category: lightning-channels ---- - -# Closing A Channel - -## Overview - -To **close** an established channel on the Lightning Network, a closing transaction must be initiated. On top of a normal mutual close, there are other ways to close a channel. - -## Details - -### Cooperative Close - -In a mutual close, both channel participants agree to a cooperative close, where final channel amounts are settled on-chain. Both participants sign a digital signature that then authorizes the on chain settlement transaction. - -Both parties are able to send as many payments to their counterparty as they wish, as long as they have funds available in the channel, knowing that in the event of disagreements they can broadcast to the blockchain the current state at any time. In the vast majority of cases, all the outputs from the Funding Transaction will never be broadcast on the blockchain. They are just there in case the other party is non-cooperative, much like how a contract is rarely enforced in the courts. A proven ability for the contract to be enforced in a deterministic manner is sufficient incentive for both parties to act honestly. When either party wishes to close out a channel cooperatively, they will be able to do so by contacting the other party and spending from the Funding Transaction with an output of the most current Commitment Transaction directly with no script encumbering conditions. No further payments may occur in the channel. - -### Unilateral Close - -In an uncooperative close of a channel, a peer broadcasts a commitment transaction. - -### Revoked Transaction Close - -An invalid close of a channel, accomplished by broadcasting a revoked commitment transaction. Since the other peer knows the commitment revocation secret key, it can create a penalty transaction. - -### Penalty Transaction - -A transaction that spends all outputs of a revoked commitment transaction, using the commitment revocation private key. A peer uses this if the other peer tries to "cheat" by broadcasting a revoked commitment transaction. - -## Resources - -[BOLT \#0, Introduction and Index](https://github.com/lightningnetwork/lightning-rfc/blob/master/00-introduction.md) - -## References - -\[1\] [https://github.com/lightningnetwork/lightning-rfc/blob/master/00-introduction.md](https://github.com/lightningnetwork/lightning-rfc/blob/master/00-introduction.md) - diff --git a/lightning-r-and-d/README.md b/lightning-r-and-d/README.md deleted file mode 100644 index 5a29f0b..0000000 --- a/lightning-r-and-d/README.md +++ /dev/null @@ -1,2 +0,0 @@ -# Lightning R&D - diff --git a/lightning-r-and-d/privacy-on-lightning-network.md b/lightning-r-and-d/privacy-on-lightning-network.md deleted file mode 100644 index 1388fe9..0000000 --- a/lightning-r-and-d/privacy-on-lightning-network.md +++ /dev/null @@ -1,39 +0,0 @@ ---- -latest-revision: '2019-01-27T00:00:00.000Z' -original-author: Ryan Shea (ryan-shea) -created: '2019-01-01T00:00:00.000Z' -status: Accepted -title: Privacy (on Lightning Network) -contributors: Ryan Shea (ryan-shea) -type: article -description: '' -discussions-to: GitHub URL -category: lightning-rnd ---- - -# Privacy \(on Lightning Network\) - -## Overview - -While there is no public, trackable ledger of Lightning transactions, **privacy** \_\_on Lightning is still a work in progress. Through techniques like [onion routing](../lightning-basics/onion-routing.md) and [eltoo](eltoo.md), privacy is improving. - -## Details - -### Implementation of Sphinx - -The current Lightning Network specification includes a solution to mask routing data from all intermediaries, based on [Sphinx](../lightning-basics/sphinx-packet.md). - -On Lightning, the payer determines a path over the peer-to-peer network and wraps a payment package in layers of encryption. Apart from just relay information, each intermediary also unpacks some additional data. This includes amounts, fees and more, along with allowing all intermediaries to set up a step in the payment chain. - -Importantly, all intermediaries only learn from which channel they receive tokens, and to which channel they must forward the payment. The intermediaries have no idea whether they are the first step in the chain, the last step, a step somewhere in the middle, or perhaps even the only step. Whoever originally sent the transaction, and the one who ultimately receives it, remain known to only the sender and the receiver. - -## Resources - -[Will Lightning Help or Hurt Bitcoin Privacy?](https://www.coindesk.com/will-lightning-help-hurt-bitcoin-privacy) - -## References - -\[1\] [https://medium.com/@rusty\_lightning/the-bitcoin-lightning-spec-part-5-8-onion-routing-protocol-86c91e455909](https://medium.com/@rusty_lightning/the-bitcoin-lightning-spec-part-5-8-onion-routing-protocol-86c91e455909) - -\[2\] [https://bitcoinmagazine.com/articles/how-the-lightning-network-layers-privacy-on-top-of-bitcoin-1482183775/](https://bitcoinmagazine.com/articles/how-the-lightning-network-layers-privacy-on-top-of-bitcoin-1482183775/) - diff --git a/lightning-r-and-d/submarine-swap.md b/lightning-r-and-d/submarine-swap.md deleted file mode 100644 index 2cfa428..0000000 --- a/lightning-r-and-d/submarine-swap.md +++ /dev/null @@ -1,69 +0,0 @@ ---- -latest-revision: '2019-01-27T00:00:00.000Z' -original-author: Ryan Shea (ryan-shea) -created: '2019-01-01T00:00:00.000Z' -status: Accepted -title: Submarine Swap -contributors: Ryan Shea (ryan-shea) -type: article -description: '' -discussions-to: GitHub URL -category: lightning-rnd ---- - -# Submarine Swap - -## Overview - -Submarine Swaps are atomic on-chain to off-chain conditional swaps \(and vice versa\) of cryptocurrencies. - -This was made possible \(and put into production\) by Alex Bosworth, who named it a "Submarine Swap" \(one half is above water \[on-chain\], one half is below water \[off-chain\]\). - -## Details - -### Problem - -Transactions between on-chain blockchain addresses and off-chain Lightning addresses are not directly compatible. This creates a transaction barrier between the underlying blockchain and the off-chain Lightning Network, regardless of implementation. - -Submarine swaps solve this issue by enabling Lightning channels to be refilled via an on-chain transfer from the underlying blockchain to the off-chain LN channel. - -### Structure - -A submarine swap essentially looks like this: - -1. Alice produces or retrieves a Lightning Network payment invoice. _It doesn't matter whether the Lightning payment is to Alice or to someone else that Alice is trying to pay_. -2. Alice presents the Lightning invoice to Bob, a "submarine swap provider". -3. Bob quotes what he must be paid _on chain_ in order to pay the Lightning invoice _off-chain_. -4. If Alice accepts the exchange rate, Bob and Alice work together and construct an HTLC that creates a conditional **on-chain** payment to Bob. -5. Alice makes the conditional payment to Bob. -6. The conditional payment to Bob is hashlocked with the same secret that will be revealed if the Lightning invoice is paid. Bob can only redeem the conditional payment from Alice by making the Lightning payment. -7. Bob pays the Lightning invoice, forcing the Lightning payment recipient to reveal the secret S. -8. Bob uses the secret S to redeem the conditional payment from Alice. - -If Bob does not pay the Lightning invoice before it expires, Bob is not able to redeem the conditional payment from Alice. In this case, Alice can wait for the HTLC to expire, then redeem the conditional payment's funds back to herself. - -What do submarine swaps allow you to do? - -* _trustlessly_ pay someone on-chain to perform an off-chain payment for you -* _trustlessly_ pay someone on-chain to buy coins on the Lightning Network from them - -This means that a user can make Lightning Network payments without being on the Lightning Network, rebalance their Lightning Network channels with a fast and low-cost payment on another chain, and perform fast trustless swaps where the usual slow step is made instant. - -Submarine conditional swaps have been demonstrated on the Bitcoin and Litecoin Lightning Networks, using on-chain payments on Bitcoin, Litecoin, and BCH. They should also be possible \(albeit with more steps\) using on-chain payments on other Bitcoin derivatives, Ethereum, Stellar, Ripple, and more. - -## Resources - -[Submarine Swaps](https://submarineswaps.org) - -### Key People - -* [Alex Bosworth](https://twitter.com/alexbosworth) - -### See also - -[Submarine Swaps Service](https://github.com/submarineswaps/swaps-service) - -## References - -\[1\] [https://submarineswaps.org/](https://submarineswaps.org/) - diff --git a/lightning-software/README.md b/lightning-software/README.md deleted file mode 100644 index d166880..0000000 --- a/lightning-software/README.md +++ /dev/null @@ -1,2 +0,0 @@ -# Lightning Software - diff --git a/lightning-software/implementations-of-lightning-network.md b/lightning-software/implementations-of-lightning-network.md deleted file mode 100644 index 6b50874..0000000 --- a/lightning-software/implementations-of-lightning-network.md +++ /dev/null @@ -1,45 +0,0 @@ ---- -latest-revision: '2019-01-27T00:00:00.000Z' -original-author: Gareth James (gjradar) -created: '2019-01-01T00:00:00.000Z' -status: Accepted -title: Network Implementations -contributors: Ryan Shea (ryan-shea); Gareth James (gjradar) -type: article -description: '' -discussions-to: GitHub URL -category: lightning-software ---- - -# Network Implementations - -## Overview - -Participation in the [Lightning Network](../lightning-basics/lightning-network.md) requires running an implementation of a Lightning Network daemon software. This software launches and runs a unique [node](../lightning-basics/node.md) that allows communication with other peers on the network. Multiple versions, or implementations, have been created by different entities, just as multiple implementations of core Bitcoin software exist. Different implementations maintain interoperability by conforming to [BOLT](../lightning-basics/basics-of-lightning-technology-bolt.md) \(Basis of Lightning Technology\) standards. - -## Details - -### Existing Implementations - -\*\*\*\*[**lnd**](lnd/), a BOLT-compliant Lightning node by Lightning Labs written in Golang [https://github.com/lightningnetwork/lnd](https://github.com/lightningnetwork/lnd) - -\*\*\*\*[**c-lightning**](c-lightning.md), a BOLT-compliant Lightning node by Blockstream written in C [https://github.com/ElementsProject/lightning](https://github.com/ElementsProject/lightning) - -\*\*\*\*[**Eclair**](eclair.md), a BOLT-compliant Lightning node by ACINQ written in Scala [https://github.com/ACINQ/eclair](https://github.com/ACINQ/eclair) - -**Ptarmigan**, a BOLT-compliant Lightning node by written in C++ [https://github.com/nayutaco/ptarmigan](https://github.com/nayutaco/ptarmigan) - -**LIT**, a non-BOLT-compliant Lightning node by MIT-DCI written in Go [https://github.com/mit-dci/lit](https://github.com/mit-dci/lit) Native multichain support and some other novel features developed by Tadge Dryja - -## References - -\[1\] [https://github.com/lightningnetwork/lnd](https://github.com/lightningnetwork/lnd) - -\[2\] [https://github.com/ElementsProject/lightning](https://github.com/ElementsProject/lightning) - -\[3\] [https://github.com/ACINQ/eclair](https://github.com/ACINQ/eclair) - -\[4\] [https://github.com/nayutaco/ptarmigan](https://github.com/nayutaco/ptarmigan) - -\[5\] [https://github.com/mit-dci/lit](https://github.com/mit-dci/lit) - diff --git a/lightning-software/lnd/README.md b/lightning-software/lnd/README.md deleted file mode 100644 index d2cae14..0000000 --- a/lightning-software/lnd/README.md +++ /dev/null @@ -1,64 +0,0 @@ ---- -latest-revision: '2019-01-27T00:00:00.000Z' -original-author: Ryan Shea (ryan-shea) -created: '2019-01-01T00:00:00.000Z' -status: Accepted -title: LND -contributors: Ryan Shea (ryan-shea); Gareth James (gjradar) -type: article -description: '' -discussions-to: GitHub URL -category: lightning-software ---- - -# LND - -## Overview - -`lnd`, or the Lightning Network Daemon, is a complete implementation of a [BOLT](../../lightning-basics/basics-of-lightning-technology-bolt.md)-compliant Lightning Network [node ](../../lightning-basics/node.md)developed by Lightning Labs. It is currently deployed on the Bitcoin Test Network `testnet3` and on mainnet. `lnd` 0.1 alpha was released on January 11th, 2017, and since has been in active beta development. - -## Details - -### Technical Details - -`lnd` has several back-end chain services including [`btcd`](https://github.com/btcsuite/btcd) \(a full-node\), [`bitcoind`](https://github.com/bitcoin/bitcoin), and [`neutrino`](https://github.com/lightninglabs/neutrino) \(an experimental light client\). `lnd` is fully compliant with the current network specifications, outlined in the [Basis of Lightning Technology](../../lightning-basics/basics-of-lightning-technology-bolt.md) standards outline. - -At the time of writing, January 14th, 2018, `lnd` is capable of: - -* Creating channels. -* Closing channels. -* Completely managing all channel states \(including the exceptional ones!\). -* Maintaining a fully authenticated+validated channel graph. -* Performing path finding within the network, passively forwarding incoming payments. -* Sending outgoing [onion-encrypted payments](https://github.com/lightningnetwork/lightning-onion) through the network. -* Updating advertised fee schedules. -* Automatic channel management \([`autopilot`](https://github.com/lightningnetwork/lnd/tree/master/autopilot)\). - -### Developer Resources - -Lightning Labs has created multiple developer resources to facilitate application development. Alongside their two RPC interfaces \(a HTTP REST API and a gRPC service\), Lightning Labs has supporting documentation and a healthy ecosystem of developer tools. - -## Resources - -[lnd GitHub repository](https://github.com/lightningnetwork/lnd) - -A set of developer resources including talks, articles, and example applications can be found at: [dev.lightning.community](https://dev.lightning.community/). - -### Key People - -* [Elizabeth Stark](https://twitter.com/starkness) -* [Olaoluwa Osuntokun](https://twitter.com/roasbeef) - -### See also - -* [Lightning Labs](https://lightning.engineering/) -* [Lightning Dev Slack](https://join.slack.com/t/lightningcommunity/shared_invite/enQtMzQ0OTQyNjE5NjU1LWRiMGNmOTZiNzU0MTVmYzc1ZGFkZTUyNzUwOGJjMjYwNWRkNWQzZWE3MTkwZjdjZGE5ZGNiNGVkMzI2MDU4ZTE) - -## References - -\[1\] [https://lightning.engineering/](https://lightning.engineering/) - -\[2\] [https://dev.lightning.community/](https://dev.lightning.community/) - -\[3\] [https://api.lightning.community/](https://api.lightning.community/) - diff --git a/bitcoin-basics/README.md b/tech/bitcoin/README.md similarity index 100% rename from bitcoin-basics/README.md rename to tech/bitcoin/README.md diff --git a/bitcoin-basics/bitcoin-address-formats.md b/tech/bitcoin/bitcoin-address-formats.md similarity index 96% rename from bitcoin-basics/bitcoin-address-formats.md rename to tech/bitcoin/bitcoin-address-formats.md index 72b0093..5fc1e60 100644 --- a/bitcoin-basics/bitcoin-address-formats.md +++ b/tech/bitcoin/bitcoin-address-formats.md @@ -19,7 +19,7 @@ A **Bitcoin address** is an identifier that represents a destination for a Bitco ## Details -### Formats (WIF = Wallet Import Format) +### Formats \(WIF = Wallet Import Format\) _Private Key WIF \(51 characters base58, starts with a '5'\):_ `5KLgsTKHMLmVxetAvN8Vqa9H7FWSj1DdXYeEKMy4nyHS5YKTpuq` diff --git a/bitcoin-basics/dust-limit.md b/tech/bitcoin/dust-limit.md similarity index 100% rename from bitcoin-basics/dust-limit.md rename to tech/bitcoin/dust-limit.md diff --git a/bitcoin-basics/faucet.md b/tech/bitcoin/faucet.md similarity index 83% rename from bitcoin-basics/faucet.md rename to tech/bitcoin/faucet.md index 2646919..b2c4756 100644 --- a/bitcoin-basics/faucet.md +++ b/tech/bitcoin/faucet.md @@ -29,7 +29,7 @@ Crypto faucets exist to introduce people to the concept of Bitcoin or cryptocurr ### Bitcoin Testnet Faucets -Currently, there is only one Bitcoin `testnet3` faucet, the Radar Ion Faucet. Previous faucets that were functional include: [coinfaucet.eu](https://coinfaucet.eu/en/btc-testnet/); [uo1.net](https://bitcoinfaucet.uo1.net/); [tpfaucet](http://tpfaucet.appspot.com/); and [backend.hamburg](https://testnet.manu.backend.hamburg/faucet). +Currently, there is only one Bitcoin `testnet3` faucet, the [Radar Ion Faucet](https://ion.radar.tech/#faucet). Previous faucets that were functional include: [coinfaucet.eu](https://coinfaucet.eu/en/btc-testnet/); [uo1.net](https://bitcoinfaucet.uo1.net/); [tpfaucet](http://tpfaucet.appspot.com/); and [backend.hamburg](https://testnet.manu.backend.hamburg/faucet). ## Resources diff --git a/bitcoin-basics/fees.md b/tech/bitcoin/fees.md similarity index 100% rename from bitcoin-basics/fees.md rename to tech/bitcoin/fees.md diff --git a/tech/bitcoin/hash.md b/tech/bitcoin/hash.md new file mode 100644 index 0000000..026500f --- /dev/null +++ b/tech/bitcoin/hash.md @@ -0,0 +1,50 @@ +--- +latest-revision: '2019-01-27T00:00:00.000Z' +original-author: Ryan Shea (ryan-shea) +created: '2019-01-01T00:00:00.000Z' +status: Accepted +title: Hash +contributors: Ryan Shea (ryan-shea); Gareth James (gjradar) +type: article +description: '' +discussions-to: GitHub URL +category: bitcoin-basics +--- + +# Hash + +## Overview + +A hash algorithm turns an arbitrary amount of data into a unique fixed-length **hash**. A hash is a fingerprint of the input data, and the same fingerprint can always be produced from the same input data. Hashes are essential to cryptographic functions not only on Bitcoin but also on the Lightning Network. + +## Details + +### Bitcoin Hashes + +Cryptographic hash functions are used extensively in Bitcoin: in bitcoin addresses, in script addresses, and in the mining Proof-of-Work algorithm. Bitcoin uses the SHA-256 algorithm to generate hashes. + +### Private and Public Keys + + + +Public-key cryptography involves a key pair: a _public key_ and a _private key_. Each entity has their own. The public key can be shared around, the private key is secret. + +They allow doing two things: + +* _Encrypt_ a message with the public key, _decrypt_ it with the private key +* _Sign_ a message with the private key, _verify_ it with the public key + +Some common algorithms are [RSA](https://en.wikipedia.org/wiki/RSA_%28cryptosystem%29) \(used for both\) and [ECDSA](https://en.wikipedia.org/wiki/Elliptic_Curve_Digital_Signature_Algorithm) \(only for signatures\). + +In the bitcoin protocol, a one-way cryptographic hash function is used to generate a bitcoin address. + +## Resources + +[SHA-256 Hash Generator](https://www.movable-type.co.uk/scripts/sha256.html) + +## References + +\[1\] [https://en.bitcoin.it/wiki/Hash](https://en.bitcoin.it/wiki/Hash) + +\[2\] [https://en.wikipedia.org/wiki/Cryptographic\_hash\_function](https://en.wikipedia.org/wiki/Cryptographic_hash_function) + diff --git a/bitcoin-basics/hltc.md b/tech/bitcoin/hltc.md similarity index 78% rename from bitcoin-basics/hltc.md rename to tech/bitcoin/hltc.md index 2c472ff..bad3d58 100644 --- a/bitcoin-basics/hltc.md +++ b/tech/bitcoin/hltc.md @@ -15,9 +15,9 @@ category: bitcoin-basics ## Overview -A **Hashed TimeLock Contract** or **HTLC** is smart contract that allows transactions to be sent between parties who do not have a direct [channel ](../lightning-basics/payment-channel.md)on the Lightning Network. HTLC's rely on the fact that an individual can structure a payment such that another party can only accept it if the party knows the secret whose [hash](hash.md) has been shared with them. +A **Hashed TimeLock Contract** or **HTLC** is smart contract that allows transactions to be sent between parties who do not have a direct [channel ](../lightning/payment-channel.md)on the Lightning Network. HTLCs rely on the fact that an individual can structure a payment such that another party can only accept it if the party knows the secret whose [hash](hash.md) has been shared with them. -HTLC's use hashlocks and timelocks to ensure payment security. HTLC's require that the receiver of a payment acknowledges receiving the payment prior to a deadline by generating cryptographic proof of payment or forfeits the ability to claim the payment, returning it to the payer. Because any receipt of funds triggers the creation of a new hash, this idea can be extended to allow a sequence of payments; with the right conditionality, payments can be securely routed through a series of users. +HTLCs use hashlocks and timelocks to ensure payment security. HTLCs require that the receiver of a payment acknowledges receiving the payment prior to a deadline by generating cryptographic proof of payment or forfeits the ability to claim the payment, returning it to the payer. Because any receipt of funds triggers the creation of a new hash, this idea can be extended to allow a sequence of payments; with the right conditionality, payments can be securely routed through a series of users. The cryptographic proof of payment the receiver generates can then be used to trigger other actions in other payments. diff --git a/bitcoin-basics/op-codes.md b/tech/bitcoin/op-codes.md similarity index 100% rename from bitcoin-basics/op-codes.md rename to tech/bitcoin/op-codes.md diff --git a/bitcoin-basics/pre-image.md b/tech/bitcoin/pre-image.md similarity index 81% rename from bitcoin-basics/pre-image.md rename to tech/bitcoin/pre-image.md index 3c0c44c..a6ae3ae 100644 --- a/bitcoin-basics/pre-image.md +++ b/tech/bitcoin/pre-image.md @@ -15,7 +15,7 @@ category: bitcoin-basics ## Overview -In the Lightning Network, a **preimage** is a data string that is passed into a [hash ](hash.md)function. Preimages are also referred to as 'secrets'. Possession of the relevant preimage allows users to claim [HTLC](hltc.md)s, which is a core process in the [routing](../lightning-basics/payment-routing.md) of payments between [nodes](../lightning-basics/node.md). +In the Lightning Network, a **preimage** is a data string that is passed into a [hash ](hash.md)function. Preimages are also referred to as 'secrets'. Possession of the relevant preimage allows users to claim [HTLC](hltc.md)s, which are a core process in the [routing](../lightning/payment-routing.md) of payments between [nodes](../lightning/node.md). ## References diff --git a/bitcoin-basics/pubkey.md b/tech/bitcoin/pubkey.md similarity index 100% rename from bitcoin-basics/pubkey.md rename to tech/bitcoin/pubkey.md diff --git a/bitcoin-basics/replace-by-fee-rbf.md b/tech/bitcoin/replace-by-fee-rbf.md similarity index 100% rename from bitcoin-basics/replace-by-fee-rbf.md rename to tech/bitcoin/replace-by-fee-rbf.md diff --git a/bitcoin-basics/satoshi-unit-of-currency.md b/tech/bitcoin/satoshi-unit-of-currency.md similarity index 100% rename from bitcoin-basics/satoshi-unit-of-currency.md rename to tech/bitcoin/satoshi-unit-of-currency.md diff --git a/bitcoin-basics/signatures-on-lightning.md b/tech/bitcoin/signatures-on-lightning.md similarity index 84% rename from bitcoin-basics/signatures-on-lightning.md rename to tech/bitcoin/signatures-on-lightning.md index a9446a4..6391696 100644 --- a/bitcoin-basics/signatures-on-lightning.md +++ b/tech/bitcoin/signatures-on-lightning.md @@ -27,7 +27,7 @@ The digital signature algorithm used in Bitcoin is the secp256k1 Elliptic Curve ### Signatures on Lightning -Digital signatures are an integral element of the multi signature holder address created in the establishment of a [channel](../lightning-basics/payment-channel.md). Two verified digital signatures are required to create the channel, as well as initiate the [closing transaction](../lightning-channels/channel-closing.md). Signatures are also essential to the [Hashed Timelock Transfer Contract](hltc.md), or HTLC, a smart contract that enables payments to be routed across the Lightning Network. +Digital signatures are an integral element of the multi signature holder address created in the establishment of a [channel](../lightning/payment-channel.md). Two verified digital signatures are required to create the channel, as well as initiate the [closing transaction](../channels/channel-closing.md). Signatures are also essential to the [Hashed Timelock Transfer Contract](hltc.md), or HTLC, a smart contract that enables payments to be routed across the Lightning Network. ## Resources diff --git a/bitcoin-basics/state-channel.md b/tech/bitcoin/state-channel.md similarity index 78% rename from bitcoin-basics/state-channel.md rename to tech/bitcoin/state-channel.md index ef6ab9b..1b80eda 100644 --- a/bitcoin-basics/state-channel.md +++ b/tech/bitcoin/state-channel.md @@ -15,7 +15,7 @@ category: bitcoin-basics ## Overview -State channels are a technique for allowing fast and cheap off-chain payments that retain the security of the underyling blockchain. They allow transacting users instant finality and minimal blockchain transaction fees. +**State channels** are a technique for allowing fast and cheap off-chain payments that retain the security of the underyling blockchain. They allow transacting users instant finality and minimal blockchain transaction fees. ## Details @@ -23,7 +23,7 @@ State channels are a technique for allowing fast and cheap off-chain payments th State channels enhance blockchain performance by taking state-modifying operations off of a blockchain and instead executing them directly between defined sets of participants. -[Payment channels ](../lightning-basics/payment-channel.md)were the first type of state channel to be described, using off-chain interactions to modify ownership of locked Bitcoin, thereby allowing users to make “off-chain payments” to each other. The term “state channels” generalizes this approach beyond payments, encompassing all types of blockchain state modification which operate within a security paradigm comparable to that of the payment channel. +[Payment channels ](../lightning/payment-channel.md)were the first type of state channel to be described, using off-chain interactions to modify ownership of locked Bitcoin, thereby allowing users to make “off-chain payments” to each other. The term “state channels” generalizes this approach beyond payments, encompassing all types of blockchain state modification which operate within a security paradigm comparable to that of the payment channel. State channels let parties securely modify locked portions of blockchain state called state deposits. These deposits are typically held in multisignature wallets, where the participants to the state channel are the signers to the multisig. diff --git a/bitcoin-basics/transaction-malleability.md b/tech/bitcoin/transaction-malleability.md similarity index 100% rename from bitcoin-basics/transaction-malleability.md rename to tech/bitcoin/transaction-malleability.md diff --git a/lightning-channels/README.md b/tech/channels/README.md similarity index 100% rename from lightning-channels/README.md rename to tech/channels/README.md diff --git a/lightning-channels/channel-backups.md b/tech/channels/channel-backups.md similarity index 100% rename from lightning-channels/channel-backups.md rename to tech/channels/channel-backups.md diff --git a/lightning-channels/channel-capacity.md b/tech/channels/channel-capacity.md similarity index 83% rename from lightning-channels/channel-capacity.md rename to tech/channels/channel-capacity.md index 02f8237..0be40c1 100644 --- a/lightning-channels/channel-capacity.md +++ b/tech/channels/channel-capacity.md @@ -23,15 +23,14 @@ Channels on the Lightning Network are 'bi-directional', as both participants are ### Inbound and outbound fund flow - + Funds may flow in and out of the Lightning Network for various reasons. -### Section 3 + -## Resources - -### See also +Option 1. Alice spends some of her channel balance with Lightning Chess and pushes funds over to them. +Option 2. Option 2 Lightning Chess opens a channel with Alice, with funds on Lightning Chess’s side. ## References diff --git a/tech/channels/channel-closing.md b/tech/channels/channel-closing.md new file mode 100644 index 0000000..0bddd6e --- /dev/null +++ b/tech/channels/channel-closing.md @@ -0,0 +1,57 @@ +--- +latest-revision: '2019-01-27T00:00:00.000Z' +original-author: Ryan Shea (ryan-shea) +created: '2019-01-01T00:00:00.000Z' +status: Accepted +title: Channel Closing +contributors: Ryan Shea (ryan-shea); Gareth James (gjradar) +type: article +description: '' +discussions-to: GitHub URL +category: lightning-channels +--- + +# Closing A Channel + +Payment channels on the Lightning Network have an unlimited lifespan, and will remain open forever until a participant in the channel initiates a **closing transaction**. + +Closing transactions come in different forms and may involve one or both parties to the channel. Closing transactions are broadcast to the blockchain, so the user must pay transaction fees and must wait for the transaction to be mined into the chain. A channel can no longer be used to route payments from the moment that the close is initiated. + +## Types of Closing Transactions + +Both parties are able to send as many Lightning payments to their counterparty as their funds in the Lightning channel allow, knowing that in the event of a disagreement they can settle their agreed-upon channel balance to the blockchain. In the vast majority of cases, there will be no disagreement and the entire lifecycle of a channel will consist of a single channel-funding transaction and a single cooperative close. + +Just in case there is a disagreement, every time a payment traverses the channel, participants create transactions committing to the current channel state and exchange secrets that revoke their previous commitments. The latest commitment and the secret keys that revoke previous commitments are kept by both parties just in case the other part is non-cooperative. + +During the normal operation of a Lightning channel with two non-malicious parties who cooperatively close a channel, no old commitment transactions or revocation keys are ever used, much like how a contract is rarely enforced in the courts. Because both parties understand exactly how the contracts that bind them in a channel will be enforced, both parties know that they cannot get away with fraud and they are incentivized to act honestly. + +### Cooperative Close + +In a cooperative close \(aka mutual close\), both channel participants agree to close the channel and settle the final state of the channel onto the blockchain. Both participants provide a digital signature that authorizes this cooperative settlement transaction. + +### Force Close + +If only one participant is online or if the participants disagree on the state of the channel, one participant can perform a force close \(aka unilateral close\) of the channel without the cooperation of the other participant. + +A force close is performed by broadcasting a "commitment transaction", a transaction that commits to a previous channel state that the channel participants have agreed upon. A force close is legitimate if the commitment transaction that is broadcast is the newest one that the channel participants have agreed upon; if the participant has broadcast a commitment transaction that has been revoked and superseded by a newer commitment, the force close is fraudulent can can be challenged by the other party when they come back online. + +The practical result of a force close is that both parties will receive their portion of the money in the channel, but the party that initiates the force close must wait anywhere from hours to weeks—the exact delay is negotiated by the nodes beforehand—to receive their funds. This delay, referred to as `to_self_delay` in the LND documentation, provides the offline node a window of opportunity to come back online and verify that the force-close was legitimate. If the force-close was fraudulent, the peer can challenge it with a penalty transaction. + +Fraudulent force close transactions can also be detected and responded to by [Watchtower services](../research/watchtowers.md). + +### Fraudulent Force Close + +An invalid unilateral close of a channel, caused by broadcasting a commitment transaction that does not represent the newest channel state agreed upon by the participants. + +If the invalid close is not detected by the other peer within the `to_self_delay` window, the malicious peer will get away with the fraudulent close and may steal some of their peer's money in the channel + +If the invalid close is detected by the other peer or by a [Watchtower service](../research/watchtowers.md), the other peer can use proof that the commitment was revoked, called a commitment revocation secret key, to create and broadcast a penalty transaction that punishes the peer who attempted a fraudulent force close. + +### Penalty Transaction + +A penalty transaction punishes a malicious node for attempting a fraudulent force close. The penalty transaction transfers the malicious node's portion of the funds in the channel to the node that they were attempting to defraud. + +## References + +1. [https://github.com/lightningnetwork/lightning-rfc/blob/master/00-introduction.md](https://github.com/lightningnetwork/lightning-rfc/blob/master/00-introduction.md) BOLT \#0, Introduction and Index + diff --git a/lightning-channels/channel-opening.md b/tech/channels/channel-opening.md similarity index 100% rename from lightning-channels/channel-opening.md rename to tech/channels/channel-opening.md diff --git a/lightning-basics/README.md b/tech/lightning/README.md similarity index 100% rename from lightning-basics/README.md rename to tech/lightning/README.md diff --git a/lightning-basics/basics-of-lightning-technology-bolt.md b/tech/lightning/basics-of-lightning-technology-bolt.md similarity index 95% rename from lightning-basics/basics-of-lightning-technology-bolt.md rename to tech/lightning/basics-of-lightning-technology-bolt.md index 17a7e24..a9fd049 100644 --- a/lightning-basics/basics-of-lightning-technology-bolt.md +++ b/tech/lightning/basics-of-lightning-technology-bolt.md @@ -15,7 +15,7 @@ category: lightning-basics ## Overview -The **Basis of Lightning Technology** is a standardized technical specification for the implementation of the Lightning Network. The standards define how various implementations can interoperate to interact with and create the same network. The specifications are currently a work-in-progress, and are continually being iterated upon as projects like [**lnd**](../lightning-software/lnd/) and [**c-lightning**](../lightning-software/c-lightning.md) are built in parallel. +The **Basis of Lightning Technology** is a standardized technical specification for the implementation of the Lightning Network. The standards define how various implementations can interoperate to interact with and create the same network. The specifications are currently a work-in-progress, and are continually being iterated upon as projects like [**lnd**](../../tutorials/nodes/lnd.md) and [**c-lightning**](../../tutorials/nodes/c-lightning.md) are built in parallel. ## Details diff --git a/lightning-basics/gossip.md b/tech/lightning/gossip.md similarity index 100% rename from lightning-basics/gossip.md rename to tech/lightning/gossip.md diff --git a/lightning-basics/hub.md b/tech/lightning/hub.md similarity index 100% rename from lightning-basics/hub.md rename to tech/lightning/hub.md diff --git a/lightning-basics/invoice.md b/tech/lightning/invoice.md similarity index 72% rename from lightning-basics/invoice.md rename to tech/lightning/invoice.md index f081b71..6e1044c 100644 --- a/lightning-basics/invoice.md +++ b/tech/lightning/invoice.md @@ -11,17 +11,19 @@ discussions-to: GitHub URL category: lightning-basics --- -# Invoice +# Lightning Invoice ## Overview -An **invoice** represents a request for funds on the Lightning Network. Invoices include numerous parameters, both required and optional, such as payment amount, chain, expiry date, payee [pubkey](../bitcoin-basics/pubkey.md), [routing hints](payment-routing.md#routing-hints), and other information. Invoices are used to make payments on the Lightning Network, rather than using [Bitcoin-style addresses](../bitcoin-basics/bitcoin-address-formats.md). +An **invoice** is a request for payment on the Lightning Network. Invoices include the information necessary to complete a payment on the network, such as payment amount, which blockchain the invoice applies to, expiry date, payee [pubkey](../bitcoin/pubkey.md), [routing hints](payment-routing.md#routing-hints), and other information. Invoices are used to make payments on the Lightning Network, rather than using [Bitcoin-style addresses](../bitcoin/bitcoin-address-formats.md). -Invoices are commonly presented as alphanumerical strings or QR codes. In order to parse specific information from the request string, users can pass the string into a decoding tool \[1\]. +Invoices are commonly presented as alphanumerical strings or QR codes. In order to parse specific information from the request string, users can pass the string into a decoding tool: -## Details +* [https://ion.radar.tech/developers\#decode](https://ion.radar.tech/developers#decode) +* [https://lightningdecoder.com/](https://lightningdecoder.com/) +* [https://lndecode.com/](https://lndecode.com/) -### Components +## Invoice Components Every Lightning invoice requires the following information in order to be valid: @@ -32,7 +34,9 @@ Every Lightning invoice requires the following information in order to be valid: * `timestamp`: Time when the invoice was created. This is measured in [seconds since 1970](https://github.com/lightningnetwork/lightning-rfc/blob/master/11-payment-encoding.md#data-part). * `cltv_expiry`: Delta to use for time-lock of CLTV extended to the final hop. -### Example Invoice +Convert timestamps to regular human time: [https://www.epochconverter.com/](https://www.epochconverter.com/) + +## Example Invoice Below is a sample invoice decoded using an invoice decoding tool. The standard fields included are: @@ -97,23 +101,11 @@ Below is a sample invoice decoded using an invoice decoding tool. The standard f } ``` -## Resources - -Lightning Decoder - -[https://lightningdecoder.com/](https://lightningdecoder.com/) - -Lightning Payment Request Decoder - -[https://lndecode.com/](https://lndecode.com/) - -### See also - -[Lightning Network Invoices](https://blockfuse.io/blog/lightning-network-invoices/) - ## References -\[1\] [Lightning Decoder](https://lightningdecoder.com/) - -\[2\] [BOLT \#11](https://github.com/lightningnetwork/lightning-rfc/blob/master/11-payment-encoding.md) +1. [BOLT \#11](https://github.com/lightningnetwork/lightning-rfc/blob/master/11-payment-encoding.md) standards document +2. [Lightning Payment Request Decoder](https://lndecode.com/) app +3. [Radar ION Invoice Decoder](https://ion.radar.tech/developers/#decode) +4. [Lightning Decoder](https://lightningdecoder.com/) app +5. ["Lightning Network Invoices"](https://blockfuse.io/blog/lightning-network-invoices/) , Blockfuse \(2018-12-08\) diff --git a/lightning-basics/lightning-network.md b/tech/lightning/lightning-network.md similarity index 99% rename from lightning-basics/lightning-network.md rename to tech/lightning/lightning-network.md index 090e52e..383f317 100644 --- a/lightning-basics/lightning-network.md +++ b/tech/lightning/lightning-network.md @@ -61,8 +61,6 @@ Through this network of interconnected payment channels, Lightning provides a sc **Single-funded channels:** when Alice needs to send a payment to Bob and doesn't currently have a way to pay him through the Lightning Network \(whether because she can't reach him or because she doesn't have enough money in an existing channel\), she can make a regular on-chain payment that establishes a channel without Bob needing to add any of his funds to the channel. Alice only uses 12 bytes more than she would for a non-Lightning direct payment and Bob would only need about 25 more segwit virtual bytes to close the channel than he would had he received a non-Lightning direct payment. -\_\_ - ## Resources ### Key People diff --git a/lightning-basics/network-capacity.md b/tech/lightning/network-capacity.md similarity index 70% rename from lightning-basics/network-capacity.md rename to tech/lightning/network-capacity.md index 9fbb6bb..2f3cc5c 100644 --- a/lightning-basics/network-capacity.md +++ b/tech/lightning/network-capacity.md @@ -21,22 +21,13 @@ category: null ## Overview -## Details - -### Section 1 - -### Section 2 - -### Section 3 +The **network capacity** on the Lightning Network is the sum total of all publicly indexed funds in channels. As of February 11th, 2019, $2.4 million US dollars are on the network. ## Resources -### Key People - -* [Person 1](network-capacity.md) -* [Person 2](network-capacity.md) - -### See also +[1ML, Lightning Network Visualizer](https://1ml.com/) ## References +\[1\] [1ML Stats](https://1ml.com/) + diff --git a/lightning-basics/node.md b/tech/lightning/node.md similarity index 87% rename from lightning-basics/node.md rename to tech/lightning/node.md index 22d1d1c..1d547a0 100644 --- a/lightning-basics/node.md +++ b/tech/lightning/node.md @@ -15,7 +15,7 @@ category: lightning-basics ## Overview -A **node** is an entity on the Lightning Network that is able to connect to other nodes by establishing a [payment channel](payment-channel.md). Users can create a node by running an implementation of [Lightning Network software](../lightning-software/implementations-of-lightning-network.md), either directly or as part of pre-packaged [wallet](../lightning-software/wallet/) software. +A **node** is an entity on the Lightning Network that is able to connect to other nodes by establishing a [payment channel](payment-channel.md). Users can create a node by running an implementation of [Lightning Network software](../../tutorials/nodes/), either directly or as part of pre-packaged [wallet](../../tutorials/wallets/) software. This should not be confused with a Bitcoin full node that validates Bitcoin blocks, although a full node's wallet may also be simultaneously used as a Lightning node to the advantage of the Lightning network user. diff --git a/lightning-basics/onion-routing.md b/tech/lightning/onion-routing.md similarity index 100% rename from lightning-basics/onion-routing.md rename to tech/lightning/onion-routing.md diff --git a/lightning-basics/payment-channel.md b/tech/lightning/payment-channel.md similarity index 71% rename from lightning-basics/payment-channel.md rename to tech/lightning/payment-channel.md index 0b8daf7..94e0ed0 100644 --- a/lightning-basics/payment-channel.md +++ b/tech/lightning/payment-channel.md @@ -17,13 +17,13 @@ category: lightning-basics On the [Lightning Network](lightning-network.md), a **payment channel** is a direct, bi-directional payment connection between two [nodes](node.md). -Payment channels are the primary building block for the Lightning Network as they allow for fast, low-cost transactions. Through on-chain [opening](../lightning-channels/channel-opening.md) and [closing ](../lightning-channels/channel-closing.md)transactions, payment channels leverage the security of the underlying blockchain to provide trustless payments between two parties. Based on the balance and [capacity](../lightning-channels/channel-capacity.md) of the channel, users exchange 'off-chain' commitments to each other outside of the Bitcoin blockchain. Payments within a channel are off-chain and do not require validation by or communication to the broader network. This means there is no explicit cost to each payment and no limit to the number of payments able to be shared within a channel. +Payment channels are the primary building block for the Lightning Network as they allow for fast, low-cost transactions. Through on-chain [opening](../channels/channel-opening.md) and [closing ](../channels/channel-closing.md)transactions, payment channels leverage the security of the underlying blockchain to provide trustless payments between two parties. Based on the balance and [capacity](../channels/channel-capacity.md) of the channel, users exchange 'off-chain' commitments to each other outside of the Bitcoin blockchain. Payments within a channel are off-chain and do not require validation by or communication to the broader network. This means there is no explicit cost to each payment and no limit to the number of payments able to be shared within a channel. -A payment channel can be [closed ](../lightning-channels/channel-closing.md)by broadcasting an on-chain transaction agreed upon by both parties that finalizes the net balance transferred over the life of the channel. +A payment channel can be [closed]() by broadcasting an on-chain transaction agreed upon by both parties that finalizes the net balance transferred over the life of the channel. ## Details -A channel is a fast, off chain method of mutually exchanging funds between to peers. To transact funds, peers exchange signatures to create a multi signature commitment transaction. The participants then fund the channel with an on-chain transaction, adding funds to the channel \(e.g., 0.1 bitcoin\) that is locked on the Bitcoin network. It is spendable only with both their signatures. +A channel is a fast, off-chain method of mutually exchanging funds between to peers. To transact funds, peers exchange signatures to create a multi signature commitment transaction. The participants then fund the channel with an on-chain transaction, adding funds to the channel \(e.g., 0.1 bitcoin\) that is locked on the Bitcoin network. It is spendable only with both their signatures. Initially they each hold a bitcoin transaction that sends all the bitcoin \(e.g. 0.1 bitcoin\) back to one party. They can later sign a new bitcoin transaction that splits these funds differently, e.g. 0.09 bitcoin to one party, 0.01 bitcoin to the other, and invalidate the previous bitcoin transaction so it won't be spent. @@ -34,7 +34,7 @@ An ideal use case for the technology is **micropayments**: Imagine a user making Other potential use cases: * Rewarding users for specific actions they take, such as contributing content to a blog, or writing a review -* Incrementally purchasing a service offering[j](https://storj.io/) +* Incrementally purchasing a service offering * Payments for other digital/virtual goods, such as a “contributor” badge on a forum * Referral network payments * Small/regular donations to charities, projects or individuals @@ -48,6 +48,8 @@ Other potential use cases: [Lightning Networks Part I: Revocable Transactions](https://rusty.ozlabs.org/?p=450) +[Micropayments, Abridged](https://medium.com/radartech/micropayments-abridged-2f110302677c) + ## References \[1\] [https://counterparty.io/docs/paymentchannels-lightning-faq/](https://counterparty.io/docs/paymentchannels-lightning-faq/) diff --git a/lightning-basics/payment-routing.md b/tech/lightning/payment-routing.md similarity index 93% rename from lightning-basics/payment-routing.md rename to tech/lightning/payment-routing.md index fb77f55..a638918 100644 --- a/lightning-basics/payment-routing.md +++ b/tech/lightning/payment-routing.md @@ -15,13 +15,13 @@ category: lightning-basics ## Overview -**Payment routing** is a fundamental concept in Lightning transactions, enabling nodes that do not have explicit channels to transmit payments to one another. Using [Hashed TimeLock Contracts](../bitcoin-basics/hltc.md), payments can be securely routed between intermediate nodes. +**Payment routing** is a fundamental concept in Lightning transactions, enabling nodes that do not have explicit channels to transmit payments to one another. Using [Hashed TimeLock Contracts](../bitcoin/hltc.md), payments can be securely routed between intermediate nodes. ## Details ### Multi-hop Payment Path - + ### Gateway Nodes diff --git a/lightning-basics/sphinx-packet.md b/tech/lightning/sphinx-packet.md similarity index 100% rename from lightning-basics/sphinx-packet.md rename to tech/lightning/sphinx-packet.md diff --git a/tech/news.md b/tech/news.md new file mode 100644 index 0000000..c5fe828 --- /dev/null +++ b/tech/news.md @@ -0,0 +1,94 @@ +--- +description: Hungry for news? Want to keep up to date with the LN ecosystem? +--- + +# Lightning News Sources + +### Email Lists + +**Lightning-dev:** Lightning Network discussion, proposals, and standards development + +{% embed url="https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev" %} + +**Bitcoin Optech**: weekly summary of development progress in Bitcoin and Lightning + +{% embed url="https://bitcoinops.org/en/newsletters/" %} + +**LND:** devs, users, vendors, anyone building on Lightning Labs' Lightning Network Daemon \(LND\): + +{% embed url="https://groups.google.com/a/lightning.engineering/forum/\#!forum/lnd" %} + +**RADAR ION mailing list:** Lightning news, project announcements, reviews, and tutorials to your inbox + +{% embed url="https://us20.campaign-archive.com/home/?u=51b99b5d546c08240db211eda&id=ab22bff805" %} + +**Lapps.co mailing list:** your weekly dose of Lightning apps + +{% embed url="https://www.lapps.co/" %} + +**Lightning Hood:** weekly roundup of Lightning and Bitcoin news + +{% embed url="https://us20.campaign-archive.com/home/?u=a7046eb01361b676a68480cb8&id=c0bcb5fa97" %} + + + + + +### LN Social Media + +Social media sites built on, by, or for the Lightning Network. + +LND Lightning Developers Slack: troubleshooting and discussion for LND users + +{% embed url="https://lightning.engineering/slack.html" %} + +**Lightning Makers:** Telegram group for Lightning project sharing and discussions + +{% embed url="https://t.me/joinchat/EFJwOxEZmjqjTBEx2883Hw" %} + +**Yalls:** post and read in a forum powered by Lightning tips + +{% embed url="https://yalls.org/" %} + +**Lightning Network Subreddit** + +{% embed url="https://www.reddit.com/r/lightningnetwork/" %} + + + + + +### Sites and Blogs + +{% embed url="https://dev.lightning.community/" %} + +{% embed url="https://www.bitcoinlightning.com/" %} + +{% embed url="https://hackernoon.com/@StopAndDecrypt" %} + +{% embed url="https://medium.com/@pierre\_rochard" %} + +{% embed url="https://medium.com/@lopp" %} + +{% embed url="https://medium.com/casa" %} + +{% embed url="https://medium.com/@lightninghood" %} + +{% embed url="https://medium.com/@timevalueofbtc" %} + +{% embed url="https://medium.com/@rusty\_lightning" %} + + + + + +### Twitter + +{% embed url="https://twitter.com/clockwrrk/lists/ln-influencers" %} + +### + + + + + diff --git a/tech/research/README.md b/tech/research/README.md new file mode 100644 index 0000000..69c9d0c --- /dev/null +++ b/tech/research/README.md @@ -0,0 +1,2 @@ +# Research and Development + diff --git a/tech/research/atomic-multi-path-payments.md b/tech/research/atomic-multi-path-payments.md new file mode 100644 index 0000000..ded3944 --- /dev/null +++ b/tech/research/atomic-multi-path-payments.md @@ -0,0 +1,83 @@ +# Atomic Multi-Path Payments + +## Overview + +### Problem + +* Alice has two channels with Bob + * channel 1: 1 BTC + * channel 2: 1 BTC +* Alice wants to send 2 BTC to Bob +* Bob sends a 2 BTC invoice to Alice +* Alice cannot pay the invoice because each channel only has 1 BTC + + + +### Solution 1: Naive Way + +* Alice wants to send 2 BTC to Bob +* Step 1 + * Bob sends a 1 BTC invoice to Alice + * Alice pays 1 BTC to Bob through channel 1 +* Step 2 + * Bob sends a 1 BTC invoice to Alice + * Alice pays 1 BTC to Bob through channel 2 + + + +### Solution 2: Atomic Multi-Path Payment + +* Alice opens a channel with Bob. +* Bob sends 2 BTC invoice to Alice +* Alice pays 2 BTC to Bob by splitting the payment + * 1 BTC goes through channel1 + * 1 BTC goes through channel2 +* Bob receives and combines the two payments to claim his BTC + + + +### Atomic Multi-Path Payment Goals + +* Atomicity: Bob cannot receive the full payment until he receives all of the partial payments +* Avoid Payment Hash Reuse: Each partial payment has a distinct payment hash +* Order Invariance: Partial payment order does not matter +* Non-interactive Setup: Bob does not have to know the transaction is an AMP + +## How It Works + +Alice generates two partial shares since she'll pay through two channels. In this example, we'll use two random numbers 123456 and 654321. + + + +Alice generates a base pre-image \(BP\) by adding the partial shares. 123456 + 654321 = 777777. If Bob knows BP, then he can claim the funds. + + + +Alice computes the partial pre-images by concatenating the base pre-image to the sequence number i, then hashing the result. + + + +Alice creates the payment payments by hashing the partial pre-image. This makes each pre-image distinct and indistinguishable from the others. + + + +Alice sends the partial payments and partial shares to Bob. + + + +When Bob receives all of the payments, he will then combine partial shares to generate the base pre-image. + + + +Bob can now use the base pre-image to generate the partial pre-images to claim funds. + + + +If Bob does not receive **all** of the partial payments, then he cannot generate the base pre-image thus making it atomic. + + + +### References + +\[1\] [https://lists.linuxfoundation.org/pipermail/lightning-dev/2018-February/000993.html](https://lists.linuxfoundation.org/pipermail/lightning-dev/2018-February/000993.html) + diff --git a/lightning-r-and-d/channel-factory.md b/tech/research/channel-factory.md similarity index 100% rename from lightning-r-and-d/channel-factory.md rename to tech/research/channel-factory.md diff --git a/lightning-r-and-d/eltoo.md b/tech/research/eltoo.md similarity index 100% rename from lightning-r-and-d/eltoo.md rename to tech/research/eltoo.md diff --git a/tech/research/hardware-wallets.md b/tech/research/hardware-wallets.md new file mode 100644 index 0000000..5b7c130 --- /dev/null +++ b/tech/research/hardware-wallets.md @@ -0,0 +1,4 @@ +# Hardware Wallets + +This article is a stub. Help us by [expanding it](../../wiki-basics/contributing.md). + diff --git a/tech/research/hodl-invoice.md b/tech/research/hodl-invoice.md new file mode 100644 index 0000000..a06b8ff --- /dev/null +++ b/tech/research/hodl-invoice.md @@ -0,0 +1,57 @@ +# Hold Invoices + +## Overview + +A **hodl invoice** \(or **hold invoice**\) is an implementation extension to a [Lightning Invoice](../lightning/invoice.md) where the final step of an [HTLC](https://github.com/RadarTech/ionwiki/tree/8fe28ac442984e71f4749aa4cabde12c4396bddf/tech/bitcoin/htlc.md) resolution is withheld by the payment `receiver`, such that the payment `sender` is fully committed, and cancelled or executed _conditionally_ at a later time. + +A **hodl invoice** is not distinguishable from a normal one to a payment `sender` other than it will have a longer-than-normal `expiry` parameter. + +## Details + +Successful [HTLC](https://github.com/RadarTech/ionwiki/tree/8fe28ac442984e71f4749aa4cabde12c4396bddf/tech/bitcoin/htlc.md) resolution in a [payment channel](../lightning/payment-channel.md) is complete when a payment `receiver` exposes a preimage that hashes to a `payment_hash` of an [Invoice](../lightning/invoice.md) and withdrawing the locked funds. When a `sender`'s funds are committed there is no option but to wait until hashlock resolution \(completing the payment\) or timelock `tl` expiration \(canceling the payment\). By setting a long enough `tl`, a payment `receiver` has the option to withhold \(or cancel\) resolution after funds have been committed until a time `t` such that `t < tl`, otherwise `tl` expires \(`t >= tl`\) and funds are returned back to the `sender`. The conditions by which the `receiver` settles or cancels the [invoice](../lightning/invoice.md) can be arbitrary or cryptographically conditional \(ie. the `receiver` does not know the preimage and must obtain it to settle the payment\). + +## Use Cases + +### Simplified Merchant Returns + +Return processes for settled purchases of out-of-stock inventory can be cumbersome. A merchant could use a **hodl invoice** to only accept payment after it has verified the inventory is in stock, or instantly refund the purchaser otherwise. + +### Fidelity Bond + +A user gains access to a service by paying a **hodl invoice**. If the user is malicious the service settles the [invoice](../lightning/invoice.md), otherwise it is canceled when the user is finished and funds return to the user. + +### Atomic Item Delivery Payment + +Consider an `item` delivery Shop, a Customer could generate a `hash` of a `preimage` and send it to the Shop. The Shop generates an [invoice](../lightning/invoice.md) with `payment_hash` equal to `hash` and Customer pays it, however the Shop cannot settle it without `preimage`. Upon `item` delivery the Customer reveals the `preimage` to the Shop Courier who then settles the [invoice](../lightning/invoice.md). + +### Atomic Multi-party Item Delivery Payment + +Consider an `item` Shop, an independent Courier, and a shop Customer: + +* Customer generates a `preimage` and sends `hash` of `preimage` to the Shop +* Shop creates **hodl invoice** `invoice0` and Customer pays it +* Shop sends `hash` to the Courier who creates another **hodl invoice** `invoice1` \(for delivery costs\) with the same `payment_hash` and Shop pays it +* Upon delivery the Customer gives the `preimage` to the Courier who settles `invoice1` revealing the preimage to Shop who then settles `invoice0`. + +### [Submarine Swap](submarine-swap.md) Variation + +* Alice creates a `preimage` and sends `hash` to Bob +* Bob creates a **hodl invoice** with `payment_hash` equal to `hash` +* Alice pays the **hodl invoice** +* Bob creates an on-chain [HTLC](https://github.com/RadarTech/ionwiki/tree/8fe28ac442984e71f4749aa4cabde12c4396bddf/tech/bitcoin/htlc.md) with `hashlock` equal to `hash` and funds it +* Alice uses `preimage` to sweep funds from the on-chain [HTLC](https://github.com/RadarTech/ionwiki/tree/8fe28ac442984e71f4749aa4cabde12c4396bddf/tech/bitcoin/htlc.md) +* Bob uses revealed `preimage` to settle the **hodl invoice** + +## Caveats + +Reusing a `payment_hash` across multiple [invoices](../lightning/invoice.md) to create conditional payment chains incurs risk for all parties receiving the `preimage` after it has been revealed once as intermediate nodes on mutual payment paths will access the `preimage` that can be used to claim funds before the respective [HTLC](https://github.com/RadarTech/ionwiki/tree/8fe28ac442984e71f4749aa4cabde12c4396bddf/tech/bitcoin/htlc.md) resolution is complete, thereby potentially blocking settlement by the **hodl invoice** holder. + +## Key People + +* [Joost Jager](https://twitter.com/joostjgr). + +## References + +1. [LND pull-request](https://github.com/lightningnetwork/lnd/pull/2022) +2. [The Lite Podcast](http://thelitepodcast.libsyn.com/lightning-network-routing-and-hodl-invoices) with Joost Jager. + diff --git a/lightning-r-and-d/lightning-appliance.md b/tech/research/lightning-appliance.md similarity index 98% rename from lightning-r-and-d/lightning-appliance.md rename to tech/research/lightning-appliance.md index 85711f6..f0e6a95 100644 --- a/lightning-r-and-d/lightning-appliance.md +++ b/tech/research/lightning-appliance.md @@ -11,7 +11,7 @@ discussions-to: GitHub URL category: lightning-rnd --- -# Lightning Appliance +# Lightning Appliances ## Overview diff --git a/lightning-software/lnd/macaroon.md b/tech/research/macaroons.md similarity index 95% rename from lightning-software/lnd/macaroon.md rename to tech/research/macaroons.md index 691ea60..83f9134 100644 --- a/lightning-software/lnd/macaroon.md +++ b/tech/research/macaroons.md @@ -11,7 +11,7 @@ discussions-to: GitHub URL category: lightning-software --- -# Macaroon +# Macaroons ## Overview @@ -49,3 +49,5 @@ A macaroon should be sent over a secure channel. `lnd` enforces TLS for RPC requ \[2\] [http://theory.stanford.edu/~ataly/Papers/macaroons.pdf](http://theory.stanford.edu/~ataly/Papers/macaroons.pdf) +\[3\] [https://store.clobig.com/what-are-macaroon-files-in-lnd/](https://store.clobig.com/what-are-macaroon-files-in-lnd/) + diff --git a/tech/research/privacy.md b/tech/research/privacy.md new file mode 100644 index 0000000..4df1fd1 --- /dev/null +++ b/tech/research/privacy.md @@ -0,0 +1,66 @@ +--- +latest-revision: '2019-01-27T00:00:00.000Z' +original-author: Ryan Shea (ryan-shea) +created: '2019-01-01T00:00:00.000Z' +status: Accepted +title: Privacy (on Lightning Network) +contributors: Ryan Shea (ryan-shea) +type: article +description: '' +discussions-to: GitHub URL +category: lightning-rnd +--- + +# Privacy + +While there is no public, trackable ledger of Lightning transactions, **privacy** on Lightning is still a work in progress. Through techniques like [onion routing](../lightning/onion-routing.md) and [eltoo](eltoo.md), privacy is improving. + +## Invoice and Channel Privacy + +When you **create** an invoice, it reveals your node's public key, which stays the same for the lifetime of your node. This has privacy implications: + +* if you post invoices in public places, the pubkey may link together your identities across platforms +* the recipient of an invoice can link multiple invoices from the same node to eachother +* anyone can view the value of bitcoins that a node pubkey has in non-private channels +* anyone can view the channel opening and closing history of a node pubkey +* anyone can match public channel opening and closing events to the on-chain inputs used to find them, and can trace those inputs using blockchain analysis +* if your node is configured to broadcast a public IP address, + * your invoice reveals the node's IP address and approximate geolocation + * network participants can link together multiple nodes hosted at a single IP address +* if you use multiple nodes with a single identity, invoice recipients can link together those two nodes + +When you **pay** invoices, much less information is revealed: + +* A payment does not indicate to the recipient what node pubkey it originated from +* A node that routes a payment does not know conclusively which node the payment came from or which node the payment is going to + * the routing node only knows which node forwarded it the payment and which node it was instructed to forward the payment to +* If the recipient service uses accounts of embeds user-provided information in the invoice, then obviously the service can link together invoices. + +What things stay private? + +* The existence and balance of **private channels** remains secret to every node except for the node you have opened the private channel to, unless that node chooses to disclose that information +* Your on-chain wallet balance that is not contained in a channel is not linked to your node pubkey, unless though it may be possible to link on-chain wallet balance to previously closed public channels through blockchain analysis +* If you use separate nodes with separate identities, there is not a straightforward way to link them + +How does using [Tor with Lightning](../../tutorials/nodes/tor.md) improve your privacy? + +* By connecting your node to Tor, other Lightning nodes connected to Tor can open channels to your node _without requiring you to broadcast a public IP address_ + +## Sphinx Routing + +The current Lightning Network specification includes a solution to mask routing data from all intermediaries, based on [Sphinx](../lightning/sphinx-packet.md). + +On Lightning, the payer determines a path over the peer-to-peer network and wraps a payment package in layers of encryption. Apart from just relay information, each intermediary also unpacks some additional data. This includes amounts, fees and more, along with allowing all intermediaries to set up a step in the payment chain. + +Importantly, all intermediaries only learn from which channel they receive tokens, and to which channel they must forward the payment. The intermediaries have no idea whether they are the first step in the chain, the last step, a step somewhere in the middle, or perhaps even the only step. Whoever originally sent the transaction, and the one who ultimately receives it, remain known to only the sender and the receiver. + +## Resources + +[Will Lightning Help or Hurt Bitcoin Privacy?](https://www.coindesk.com/will-lightning-help-hurt-bitcoin-privacy) + +## References + +\[1\] [https://medium.com/@rusty\_lightning/the-bitcoin-lightning-spec-part-5-8-onion-routing-protocol-86c91e455909](https://medium.com/@rusty_lightning/the-bitcoin-lightning-spec-part-5-8-onion-routing-protocol-86c91e455909) + +\[2\] [https://bitcoinmagazine.com/articles/how-the-lightning-network-layers-privacy-on-top-of-bitcoin-1482183775/](https://bitcoinmagazine.com/articles/how-the-lightning-network-layers-privacy-on-top-of-bitcoin-1482183775/) + diff --git a/lightning-r-and-d/scriptless-scripts-schnorr.md b/tech/research/scriptless-scripts-schnorr.md similarity index 99% rename from lightning-r-and-d/scriptless-scripts-schnorr.md rename to tech/research/scriptless-scripts-schnorr.md index 5445123..a3127a8 100644 --- a/lightning-r-and-d/scriptless-scripts-schnorr.md +++ b/tech/research/scriptless-scripts-schnorr.md @@ -11,7 +11,7 @@ discussions-to: GitHub URL category: lightning-rnd --- -# Scriptless Scripts \(Schnorr\) +# Scriptless Scripts ## Overview diff --git a/tech/research/sphinx-send.md b/tech/research/sphinx-send.md new file mode 100644 index 0000000..cd254d3 --- /dev/null +++ b/tech/research/sphinx-send.md @@ -0,0 +1,32 @@ +--- +description: Send Lightning payments without using an invoice! +--- + +# Key Send + +Today \(2019-02-15\), you must acquire a one-time-use [Lightning invoice](../lightning/invoice.md) from a user in order to initiate a Lightning payment to them. **Key Send** is a technology currently in development that will allow any node to send a payment to any other \(online\) node without requiring an invoice. + +In [lnd](../../tutorials/nodes/lnd.md) version 0.7.0, **Sphinx Send** was renamed to **Key Send**. + +## Implications + +Today, a payer must receive a unique invoice from a payee for each payment: + +{% embed url="https://twitter.com/pavolrusnak/status/1096414778845786113" %} + +Many tools have been built that LND users can host on a webserver in order to dispense invoices to users: + +{% embed url="https://github.com/brndnhrbrt/ln-donate-node" %} + +{% embed url="https://github.com/michael1011/lightningtip" %} + +With Key Send, these dynamic invoice generators can be replaced with a static string or QR code that anyone can pay to. + +## Progress + +[LND](../../tutorials/nodes/lnd.md) has work-in-progress code that will enable Key Send: + +{% embed url="https://github.com/lightningnetwork/lnd/pull/2455" %} + +This work is incomplete, but if you build two LND nodes from source using the `Roasbeef:new-eob-sphinx-send` feature branch, these nodes are able to exchange Sphinx Send payments. + diff --git a/tech/research/submarine-swap.md b/tech/research/submarine-swap.md new file mode 100644 index 0000000..afc8cf8 --- /dev/null +++ b/tech/research/submarine-swap.md @@ -0,0 +1,313 @@ +--- +latest-revision: '2019-11-21T00:00:00.000Z' +original-author: Ryan Shea (ryan-shea) +created: '2019-01-01T00:00:00.000Z' +status: Accepted +title: Submarine Swap +contributors: Ryan Shea (ryan-shea) +type: article +description: '' +discussions-to: GitHub URL +category: lightning-rnd +--- + +# Submarine Swap + +Submarine Swaps are atomic on-chain to off-chain swaps \(and vice versa, often called Reverse Submarine Swaps\) of cryptocurrencies. + +This was made possible \(and put into production\) by Alex Bosworth. Olaoluwa Osuntokun originally coined the term Submarine Swap — one half is above water \(on-chain\), one half is below water \(off-chain\). + +{% embed url="https://twitter.com/alexbosworth/status/964276161902624768?lang=en" %} + +## Technical Details + +### Problem + +Transactions between on-chain blockchain addresses and off-chain Lightning addresses are not directly compatible. This creates a transaction barrier between the underlying blockchain and the off-chain Lightning Network, regardless of implementation. + +Submarine swaps solve this issue by enabling Lightning channels to be refilled via an on-chain transfer from the underlying blockchain to the off-chain LN channel. Reverse Submarine swaps solves the off-chain to on-chain transactions and enable Lightning channels to be reversed obtaining inbound liquidity via an off-chain transfer in the LN to a on-chain address + +### Structure + +#### A submarine swap essentially looks like this: + +1. Alice produces or retrieves a Lightning Network payment invoice. _It doesn't matter whether the Lightning payment is to Alice or to someone else that Alice is trying to pay_. +2. Alice presents the Lightning invoice to Bob, a "submarine swap provider". +3. Bob quotes what he must be paid _on chain_ in order to pay the Lightning invoice _off-chain_. +4. If Alice accepts the exchange rate, Bob and Alice work together and construct an HTLC that creates a conditional **on-chain** payment to Bob. +5. Alice makes the conditional payment to Bob. +6. The conditional payment to Bob is hashlocked with the same secret that will be revealed if the Lightning invoice is paid. Bob can only redeem the conditional payment from Alice by making the Lightning payment. +7. Bob pays the Lightning invoice, forcing the Lightning payment recipient to reveal the secret S. +8. Bob uses the secret S to redeem the conditional payment from Alice. + +If Bob does not pay the Lightning invoice before it expires, Bob is not able to redeem the conditional payment from Alice. In this case, Alice can wait for the HTLC to expire, then redeem the conditional payment's funds back to herself. + +What do submarine swaps allow you to do? + +* _trustlessly_ pay someone on-chain to perform an off-chain payment for you + +This means that a user can make Lightning Network payments without being on the Lightning Network, rebalance their Lightning Network channels \(refill\) with a fast and low-cost payment on another chain, and perform fast trustless swaps where the usual slow step is made instant. + +Submarine conditional swaps have been demonstrated on the Bitcoin and Litecoin Lightning Networks, using on-chain payments on Bitcoin, Litecoin, and BCH. They are possible \(albeit with more steps\) using on-chain payments on other Bitcoin derivatives, Ethereum, Stellar, Ripple, and more. + +#### A reverse submarine swap essentially looks like this: + +1. Alice generates a secret preimage, think in the secret as a random number that only the user knows, we call it preimage because we are going to use it as an input of a hash function, and we are going to make public \(at the beginning\) only the hash, hashes are one way functions, so knowing the hash give other no clues about which is the secret, but reached the point where the secret is revealed anyone can check that the secret originated that exact hash +2. Alice sends off-chain \(via Lightning\) a conditional payment to Bob, a "submarine swap provider", implemented with a HODL invoice, the condition is that the payment need the secret as an input to be settled or it will return to the payer \(Alice\) if a determined amount of time has elapsed. As soon as Bob discovers the secret \(when Alice reveals it\) he could take that money off-chain, meanwhile it will be on hold \(HODL\). We will call this, the swap payment +3. Alice sends off-chain \(via Lightning\) another payment, called the prepayment, in this case, this is a normal payment of at most a few thousands satoshis, with no condition as its purpose is to cover Bobs on-chain fees that needed to afford while constructing the swap structure. In case the swap fails or its cancelled, Alice won’t get this prepayment back, as the provider has already \(if he is fair\) spent that in the on-chain fees of the tx described below +4. Bob broadcasts an on-chain hash locked output tx ,it is a transaction to an output that can only be spent using the secret preimage, \(the one only Alice knows\) this is the payment to Alice on-chain and the amount of this transaction is the amount of the intended swap. It also has a time condition in case the swap fails, so as we have described we are in front of a Hash Time Locked Contract \(HTLC\), this is constructed using the same hash mentioned in 1., so the secret needed to unlock it, is the same that Alice generated and that at this point only Alice knows. This contract is imposing the following condition to Alice: “if you want the on-chain payment in your wallet, you have to let me settle the swap payment \(off-chain conditional payment\) by publishing your secret” in this way we have the same secret that unlocks the swap payment in favor of Bob and the on-chain payment in favor of Alice +5. Alice publishes the secret by disclosing the secret preimage in the spending transaction, HTLC \(the on-chain transaction that put the money in Alice wallet, often called sweep the payment\), so now anyone can see the secret, especially the provider +6. Bob uses the same secret published by Alice in 5. to settle the swap payment, the HODL invoice \(Bobs off-chain money in exchange for the money he locked on-chain\) + +What do reverse submarine swaps allow you to do? + +* _trustlessly_ pay someone off-chain to perform an on-chain payment for you + +This means that a user can make BTC payments even if he has all his funds commited to Lightning Network channels, rebalance their Lightning Network channels obtaining inbound liquidity, etc. + +## Examples + +See more examples on the [Lightning Exchanges](../../tutorials/lightning-exchanges.md#trustless-noncustodial-exchanges) page. + +### RADAR REDSHIFT + +**Radar.tech** has released **REDSHIFT**, a multi-network submarine swap provider + +{% embed url="https://ion.radar.tech/redshift" %} + + + +### Lightning Labs Loop + +**Lightning Labs** has released **Loop**, a submarine swap service that plugs into LND. Loop allows users running LND nodes to exchange BTC in Lightning channels for BTC on-chain, and vice-versa. Loop charges a fee \(0.1% as of 2019-10-24\) for this service. The Loop client is open source but the server is proprietary—to perform a swap, you have to perform it with Lightning Labs. + +The Loop swap server is hosted on this node: + +`03fb2a0ca79c005f493f1faa83071d3a937cf220d4051dc48b8fe3a087879cf14a` + +It's not possible to connect to this node directly, but you can connect to [this node ](https://1ml.com/node/021c97a90a411ff2b10dc2a8e32de2f29d2fa49d41bfbb52bd416e460db0747d0d)that acts as a gateway to the Loop node: + +`021c97a90a411ff2b10dc2a8e32de2f29d2fa49d41bfbb52bd416e460db0747d0d@18.224.56.146:9735` + +A Loop server is also available on the Bitcoin testnet at [this node](https://1ml.com/testnet/node/0223acffd7f363b4591ce860eda870fea352e981212d8a25e96a0ebea37faae288): + +`0223acffd7f363b4591ce860eda870fea352e981212d8a25e96a0ebea37faae288@40.71.39.161:9735` + +{% embed url="https://blog.lightning.engineering/posts/2019/03/20/loop.html" caption="" %} + +{% embed url="https://github.com/lightninglabs/loop" caption="" %} + +Up to now, the min amount to loop in one itaration is 250000 and the max amount to loop: 2000000, it can be obtained installing the loop command line client and executing `loop terms` and a quote could be request with `loop quote