> Instead of using sidechains, just use channel factories. I am not familiar enough with the latest advancements in this field. Is it possible using LN/channel factories to achieve off-line-like participation user experience without previous registration with any kind of gateway provider? For example, can you go online, join the network [somehow instantly], generate address/invoice and then put it somewhere for others to later use it when you are off-line? Can you also participate while being off-line for very long periods of time without relying on third party providers to secure your channels? If not, is using sidechains really equally replaceable with LN/CF constructions?
Sent with ProtonMail Secure Email. ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐ On Monday, January 13, 2020 2:33 AM, ZmnSCPxj via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org> wrote: > 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 _______________________________________________ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
