Good morning Robin,
> Good morning ZmnSCPxj, > > Thank you for your detailed feedback! Two topics: > > Lightning vs Sidechains > > ------------------------ > > Why an either-or-solution, if we can connect sidechains via the LN to get the > best of both worlds? > > The LN works exceptionally great under the following conditions: > > - you're always online > - you have BTC to manage your channels' inbound-capacity > - you can afford BTC transactions > - in your channel is much more than the minimum on-chain TX fees > > The next Billion users do not fit that category. They are on > unreliable cell phone connections and do not have any BTC yet. > And the more popular Bitcoin becomes, the fewer people can afford LN > channels. Even Eltoo requires your funds to be significantly higher than > Bitcoin's TX fees, right? > > Already today, more and more services like tippin.me, BlueWallet, > etc, provide custodial solutions. > For small amounts, custody is an acceptable workaround. And I love > their usability. Install it and immediately I can send you $0.01. Yet, > scaling their approach globally does not lead to desirable outcomes, since > we'd be back to trusting banks with their Excel sheets. > > So let's make their internal ledgers public and trustless, via > independent sidechains. Decentralized Blockchains do scale decently up to a > couple Million UTXOs. So a couple thousand Sidechains is probably sufficient > for a global medium of exchange. Cross-chain communication without requiring > cross-chain validation is possible via atomic swaps and through Bitcoin's LN. > That scales because it separates chain-validators from swap-validators. > Bitcoin's LN acts as the central settlement layer for efficient > cross-chain transactions between all sidechains. > > So Endusers "living" in sidechains instead of directly in the LN has > many advantages: > > - no bitcoin blockspace required for on-boarding new users > - no need to lock funds to provide inbound-capacity > - no need to stay online or pay watch towers > - no need to store channel histories > - account balances can be much smaller than BTC TX fees > > Those are the exact same reasons why BlueWallet built their LndHub. But > sidechains can be trustless. Also a generic protocol provides flexibility for > sidechain innovations with arbitrary digital assets and consensus rules. Which is why I brought up multiparticipant offchain updateable cryptocurrency systems. The "channel factories" concepts does what you are looking for, except with better trust-minimization than sidechains can achieve. Just replace "sidechain" with either Decker-Wattenhofer or Decker-Russell-Osuntokun constructions. You can even use the Somsen "statechain" mechanism, which rides a Decker-Wattenhofer/Decker-Russell-Osuntokun construction, though its trust-minimization is only very very slightly better than federated sidechains. It is helpful to remember that Poon-Dryja, Decker-Wattenhofer, Decker-Russell-Osuntokun, and all other future such constructions, can host any contract that its lower layer can support. So if you ride a Poon-Dryja on top of the Bitcoin blockchain, you can host HTLCs inside the Poon-Dryja, since the Bitcoin blockchain can host HTLCs. Similarly, if you ride a Decker-Wattenhofer on top of the Bitcoin blockchain, you can host a Poon-Dryja inside the Decker-Wattenhofer, since the Bitcoin blockchain can host Poon-Dryja channels. This central insight leads one to conclude that anything you can put onchain, you an generally also put offchain, so why use a chain at all except as an ultimate anchor to reality? Poon-Dryja is strictly two-participant, while Decker-Wattenhofer limits the practical number of updates due to its use of decrementing relative timelocks: so you put the payment layer in a bunch of Poon-Dryja channels which support tons of updates each but only two participants per channel, and create a layer that supports changes to the channel topology (where changes to the channel connectivity are expected to be much rarer than payments) and is multiparticipant so you can *actually* scale. Instead of using sidechains, just use channel factories. You do not need to broadcast the entire internal ledgers of those services, only their customers need to know those internal ledgers, and sign off on the updates of those ledgers. Regards, ZmnSCPxj _______________________________________________ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
