fiatjaf

http://eclair.yourdomain.com {
  @whitelisted {
    path /createinvoice
  }

  @blacklisted {
    not path /createinvoice
  }

  reverse_proxy @whitelisted http://localhost:8877 {

fiatjaf

Drivechain Checklist

Check the boxes you understand and agree with. If you check more than 75% of the boxes you're a Drivechain maximalist. Otherwise you need treatment, join https://t.me/DCinsiders and ask for help.

• Sidechains are chains independent of Bitcoin consensus. They don't add any burden to the Bitcoin full nodes.
• Sidechains use bitcoins (BTC) as their base currency, not any shitcoin.
• Sidechains can have different rules, implement different features, be developed by different teams.
• Using a sidechain is completely optional.
• Sidechains are expected to be blindly merge-mined with Bitcoin, which means they increase the Bitcoin security budget without adding any burden to the normal Bitcoin miners.
• There are useful features that can be implemented in sidechains that we can't implement in Bitcoin today (and we don't want either, because it would clog the Bitcoin main chain which is already too small and want it to remain small).

fiatjaf

# just copy and paste this somewhere changing the target node id, ip and address.
# you must have python3 and virtualenv, which can be installed with 'sudo apt install python3-virtualenv' on ubuntu
# it will download the pyln.proto library to a virtualenv and run the script below passed as a string

python3 -m venv venv
./venv/bin/pip install pyln.proto
./venv/bin/python -c '
import sys
from pyln.proto.wire import connect, PrivateKey, PublicKey
from binascii import unhexlify

fiatjaf

import requests

username = 'alexberenson'

def write_tweets(f, tweets):
    for tweet in tweets:
        text = tweet["full_text"]
        for url in tweet["entities"]["urls"]:
            text = text.replace(url["url"], url["expanded_url"])

fiatjaf

bitcoin-requests

fiatjaf

for (( b=661000; b<=661884; b++ )) do
  x=`bitcoin-cli getblock $(bitcoin-cli getblockhash $b) 2 | jq -c '.tx | map(select(.version > 1)) | map(.vin | map(.sequence | select((. < 2147483648) and (. > 0)))) | reduce .[] as $ns ([]; . + $ns) | reduce .[] as $n ({}; .["\($n)"] = (.["\($n)"] // 0) + 1)'`
  if [ "$x" != '{}' ]
    then echo $b: $x
  fi
done

fiatjaf

# use with:
# bash -c 'version=$(curl -s https://api.github.com/gists/e20c109af9b07a871aacac37b4102c91 | jq -rc .history[0].version); curl -s https://gist.githubusercontent.com/fiatjaf/e20c109af9b07a871aacac37b4102c91/raw/$version/channels-balance-state.jq > /tmp/clsnippet.jq; lightning-cli listfunds | jq -f /tmp/clsnippet.jq'
# 
# lightning-cli listfunds | jq '
  .channels
| sort_by(.channel_sat) | reverse
| map
  (
    { peer: .peer_id
    , scid: .short_channel_id

fiatjaf

c-lightning 0.6 88
c-lightning 0.6.1 8a
c-lightning 0.6.2 8a
c-lightning 0.6.3 88
c-lightning 0.7.0 8a
c-lightning 0.7.1 aa
c-lightning 0.7.2.1 aa
c-lightning 0.7.3 28a2
c-lightning 0.8.0 02aaa2
c-lightning 0.8.1 02aaa2

fiatjaf

HTLCs below the dust limit are not possible, because they're uneconomical.

So currently whenever a payment below the dust limit is to be made Lightning peers adjust their commitment transactions to pay that amount as fees in case the channel is closed. That's a form of reserving that amount and incentivizing peers to resolve the payment, either successfully (in case it goes to the receiving node's balance) or not (it then goes back to the sender's balance).

SOLUTION

I didn't think too much about if it is possible to do what I think can be done in the current implementation on Lightning channels, but in the context of Eltoo it seems possible.

Eltoo channels have UPDATE transactions that can be published to the blockchain and SETTLEMENT transactions that spend them (after a relative time) to each peer. The barebones script for UPDATE transactions is something like (copied from the paper, because I don't understand these things):

fiatjaf

          +------+                             +-------+                                   +---------+
+-------> |      | +-------------------------> |       |   - - - - - - - - - - - - - - ->  |potential|
          | BMM  |                             |  BMM  |                                   |  BMM    |
          |block |                             | block |                                   | block   |
          |      |                             |       |                     - - - - - ->  |         | +---- - - -
          +------+                             +-------+                    |              +---------+            |
                                                                                             tx A
                                                                            |                                     |
                                                                                                                  v