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