counterweight/chatochi_notes
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions

Stuff

Browse source
This commit is contained in:
pablo 2022-01-14 09:43:21 +01:00
parent a3619df8cf
commit 986d207a04
2 changed files with 90 additions and 17 deletions
Download patch file Download diff file Expand all files Collapse all files

87
lightning_node_management.md Normal file
View file

@ -0,0 +1,87 @@
# Lightning Node Management
My umbrel node is almost in sync with the blockchain so soon I will be able to put my new lightning node into use. These
past days I have been consuming a lot of material on how to prepare the lightning node, with the idea in mind of making
a successful routing node.
These are the topics that I have in mind:
- UPS for uptime
- Channel opening strategy
- Channel rebalancing strategy
- Pricing strategy
## UPS for uptime
I have learnt through different sources that it is important to have a "good reputation" in order to have more chances
of peers connecting to my node. Now, reputation is rather fuzzy, and varies from simply people observing your node on
1ML or similar pages, to a variety of rankings and scores such as BOS, Lightning Terminal Tiers, 1ML node rank, etc.
One of the components of most of these scores, and more fundamentally, a strong signal of node quality, is uptime. Plain
and simple, never go down, and if you do, don't spend much time down.
In order to ensure that my node does a good job in terms of availability, I have been studying the possiblity of using a
UPS. In general terms, an outage is the only relevant (as in both probable and impactful) event that could put my node
down.
I have been reading up a bit on UPS. By design, they are designed to only provide a few minutes of availability to
securely put services down in the machine that is going to go dry. But since both Banky and my router are super low
consumption devices, I'm actually hoping that a decent UPS could provide a handful of hours of activity if needed.
Notice I'm also including the router in the equation because, obviously, if the internet connection goes down, keeping
Banky on is not enough.
So I need to:
- Decide what UPS I should get. The main points here are:
- Price
- Battery capacity
- That it has two sockets.
- Confirm that, in the event of a house-level power outage, the router still keeps connecting to WAN as long as it has
electricity. It would also be good to check with a building/street level outage, but I think simulating that goes
beyond my current capacities.
- Measure empirically how long does the setup last until the node disconnects.
## Channel Opening Strategy
Once I get funds in my lightning node, I need to start opening channels. As I do it, they will all be unbalanced, with
all the funds sitting in the local side. I'll have to compensate for that since I don't expect anyone opening towards me
initially (I'm not gonna showcase myself all over the place to get people's attention). But I'll discuss that in another
section.
So, I need to open channels to people. The key questions are:
- With who?
- How many sats to put into each channel?
Regarding channel size: generally, the larger, the better. It helps reduce the impact of onchain fees, offers more
opportunities for keeping things balanced and also enables larger transactions to go through. The downside of making one
channel large is the opportunity cost of having a few smaller channels, which increase the variety of nodes.
From what I've been reading, anything smaller than 1M sats gives yields more trouble than benefit. So I will keep that
as a minimum size for the channels I open. Question is, how big should the bigger channels be?
I'm copying a table from the statistics page in 1ML, on 13/01/22:
| Percentile | Capacity in Satoshis |
| --- |----------------------|
| 1 | __.__2.000 |
| 5 | __._24.900 |
| 25 | __.200.000 |
| 50 | _1.000.000 |
| 75 | _3.000.000 |
| 95 | 14.995.600 |
| 99 | 50.000.000 |
So, it's clear that going above 0.1 BTC is a pretty rare exercise. I'm planning on allocating 0.2 BTC in total during my
first experiments, so I think I will distribute them in the following way:
| How many channels | Capacity per channel |
|-------------------|----------------------|
| 1 | 5.000.000 |
| 4 | 2.500.000 |
| 5 | 1.000.000 |
| 10 | 10.000.000 |
The next question is: who to connect to?

18
mastering_bitcoin_notes.md
View file

@ -41,25 +41,11 @@ The checksum for this entropy is computed the following way:
- Starting from the left, grab one bit of the hash for every 32 bits of length
in the original entropy (if the entropy is 128 bits, 128/32 = 4, you grab the 4
first bits of the hash).
```python
entropy = "01000010011111001011100101101111001010010110101011011111000001101000110111111001010000101000000110011010110011110110010000011001"
entropy_len = len(entropy)
import hashlib
hash_of_entropy = hashlib.sha256(entropy)
print(hash_of_entropy)
```
- I got bored of writing, so I made some code. See `seed_playground.py`.
----------
Another interesting fact: miner fees for a transaction are not explicitly
specified anywhere, but are simply calculated as the difference between the
inputs and the outputs of the transaction.