rich1.0npub1c8flqlwmkh5vehm7rfcacurk9x5ggv36vtra2p97thynzfq0vxus5zgzt8https://nostr.ae/npub1c8flqlwmkh5vehm7rfcacurk9x5ggv36vtra2p97thynzfq0vxus5zgzt8njumphttps://nostr.ae📅 Original date posted:2020-01-15 📝 Original message:> 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. That's right, all you need to broadcast is a small proof, a non-interactive blockchain suffix proof https://eprint.iacr.org/2017/963.pdf On Sun, Jan 12, 2020 at 7:33 PM ZmnSCPxj via bitcoin-dev < bitcoin-dev at 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 at lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20200115/48d7ea4b/attachment-0001.html>