Stuff

lightning_node_management.md

@@ -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?
+
+

mastering_bitcoin_notes.md

@@ -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).
-
+- I got bored of writing, so I made some code. See `seed_playground.py`.
-```python
-
-entropy = "01000010011111001011100101101111001010010110101011011111000001101000110111111001010000101000000110011010110011110110010000011001"
-entropy_len = len(entropy)
-
-import hashlib 
-
-hash_of_entropy = hashlib.sha256(entropy)
-
-print(hash_of_entropy)
-
-
-
-
-```
 
 ----------
 
 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.
+inputs and the outputs of the transaction.
+