We can imagine a LAN with several nodes and one explorer. The blockchain contains confirmed transactions with HTLC and existing payment channels to merchants. External third-party services can exist.
- Maybe merchants can still accept non-RBF onchain transactions if they are in mempool of several explorers and small amounts (to avoid any possible collusion with miners).
- New payment channels can't be established since these transactions require several blocs confirmed
- Existing payment channels can be used and new channel states can be sent to external entities protecting the channels (watchtower for LN)
- Existing payment channels can be rebalanced with centralized services allowing fast payment method (CEX/DEX with LN withdrawal, sign a contract, pay with altcoins, use 3DS for €/$)
The mempool of nodes in the LAN will differ from public mempool.
- New onchain transactions should be refused by merchants that noticed that the LAN's explorer is showing few nodes connected and no access to external explorers.
- Existing payment channels could still be used if delays for punishment in case of malicious behavior are respected
- Physical coins (cassassius) can still be exchanged without time constraint but can't be divided/splitted
- Merchants will be able to check if unconfirmed non-RBF onchain txes accepted as payment were confirmed
- Existing payment channels can check blockchain current state and act on time in case of malicious actor
- How to minimize risks ? We can use small amounts and demonstrate existance of external third-party entities protecting the channels. Malicious actor doesn't know if victim didn't had Internet during brief instant to send new channel state to the third-party entity that protects channels.
-
if physical holdings of each community member are placed in a safe with value higher than total value exchanged within channels. When community is back online, each member can check if other members acted honestly or maliciously and approve that physical holdings remain in the community safe. In case of thief or malicious behavior, holdings of the bad actor in the safe can be used to cover the loss.
-
if community is warnt before the Internet disconnection, spending all funds to have physical materials (land, energy, hardware, gear) or launch a new "blockchain" in the LAN (RGB tokens on BTC, issue tokens on ETH/KMD) Physical material can be better than launching a new "blockchain" where all nodes are in the LAN because the the single centralized actor that received funds can steal all funds spent initially. If spent funds are sent to a multisig, risk can be lowered
-
If full nodes are tweaked to spend unconfirmed funds from mempool and payment channel to be defined based on unconfirmed transactions,
- if before internet disconnection, community multisig n-n is created, community members makes low amount non-RBF transactions to the multisig address and payments channels establised between multisig and each LN user within the LAN with payment channels balances corresponding to the onchain non-RBF transaction amount of each member
- then after internet disconnection, each community member will be able to perform transactions securely within established payment channels
- Risk is that each community member can refuse to sign multisig to release funds (or signer can lose his private key). Risk can be mitigated with n-m multisig where additional keys are kept by members who sent higher amounts to the multisig
-
If Cards and card readers are available and proper software installed,
- if the card can't be backuped, ...
- if the card can be backuped, ...
-
LoRa
-
LN
- Fraudulent force close: https://wiki.ion.radar.tech/tech/channels/channel-closing#:~:text=A%20force%20close%20is%20legitimate,can%20be%20challenged%20by%20the
- Spec: https://github.com/lightning/bolts/blob/master/02-peer-protocol.md#channel-close "set to_self_delay sufficient to ensure the sender can irreversibly spend a commitment transaction output, in case of misbehavior by the receiver."
-
Komodo payment channels: https://developers.komodoplatform.com/basic-docs/antara/antara-api/channels.html#introduction
- signed raw transaction to be sent
normal tx p2sh LN commitment revocation secret key LN punish malicious actor (penalty transaction)
Normal tx = p2pkh todo: check tx type
0100000001958cb041d8369bbf6c2493accc4d949909a2c669cad883e232038d782eeb4fa4000000006a4730440220242c38740261799f9b6ccbde8f941e2567e86c84108c508d108d062ab9677b6e02206fea089b28c6d66d1c8f2343e1de7960dadafa3cf268c00f7dbe391cd8b9365f01210384c0db4f1eaa142a2745742b942f989375dbec32c55310a793225bb5c43cdc98ffffffff0140420f00000000001976a91456def632e67aa11c25ac16a0ee52893c2e5a2b6a88ac00000000
Without any compression, convert hex to binary:
000100000000000000000000000000000001100101011000110010110000010000011101100000110110100110111011111101101100001001001001001110101100110011000100110110010100100110010000100110100010110001100110100111001010110110001000001111100010001100100000001110001101011110000010111011101011010011111010010000000000000000000000000000000000011010100100011100110000010001000000001000100000001001000010110000111000011101000000001001100001011110011001111110011011011011001100101111011110100011111001010000011110001001010110011111101000011011001000010000010000100011000101000010001101000100001000110100000110001010101011100101100111011110110110111000000010001000000110111111101010000010001001101100101000110001101101011001101101000111001000111100100011010000111110000111011110011110010110000011011010110110101111101000111100111100100110100011000000000011110111110110111110001110010001110011011000101110010011011001011111000000010010000100000011100001001100000011011011010011110001111010101010000101000010101000100111010001010111010000101011100101000010111110011000100100110111010111011011111011000011001011000101010100110001000010100111100100110010001001011011101101011100010000111100110111001001100011111111111111111111111111111111000000010100000001000010000011110000000000000000000000000000000000000000000110010111011010101001000101000101011011011110111101100011001011100110011110101010000100011100001001011010110000010110101000001110111001010010100010010011110000101110010110100010101101101010100010001010110000000000000000000000000000000000
Length = 1524 bits
LoRa max legal bandwith is 2.5 bytes/sec UP & Down, let's choose 2 bytes/sec for upload
=> 1524 bits can be sent in (1524 / 8) / 2 = 96 seconds
Source of example:
API for raw confirmed tx:
https://www.npmjs.com/package/insight-api
Source for LoRa bandwidth: toadd
Data to be compressed ?
-
laptops/desktops to run 3 full nodes with p2p port open
-
laptops/desktops to run 2 LN nodes (and 2 KMD assetchains with payment channels enabled)
-
laptops/desktops to run 1 explorer
-
one modem/router (or 3G/4G shared from a smartphone + a laptop runs as DHCP)
-
one laptop must act as wifi hot spot (and be connected to the LAN with another network card, RJJ45 wire as example)
-
one laptop must act as DHCP server (or use the modem/
-
users with smartphones with LN app that can be connected to a LAN's LN node
-
merchants with same full node, LN node and so on OR smartphone with LN app that can be connected to a LAN's LN node
-
Papers to write Wifi credentials and LN nodes IP to connect to
-
Optional, cards to use as paper contracts and community members holdings to cover risk
- server to run 3 full nodes, 2 LN nodes, ... hosted on one VM with 2 VM on server and hypervisor
- infra link to redirect ports within the LAN for the LN nodes ports between the 2 VM
- if hypervisor (VMware, virtualbox), tweak (?) in the config of the VM to disable Internet inside the VM but keep LAN within the server
- the second VM that doesn't host full nodes will keep internet connectivity and it should relay only the LN ports to let user connect to