{"type":"rich","version":"1.0","author_name":"npub1f2nxequ09nz44775vv6lkffq2plzqvrqramnk29eddmwcc9z7jys8ms289","author_url":"https://nostr.ae/npub1f2nxequ09nz44775vv6lkffq2plzqvrqramnk29eddmwcc9z7jys8ms289","provider_name":"njump","provider_url":"https://nostr.ae","html":"📅 Original date posted:2020-05-14\n📝 Original message:\u003e It should be therefore a top priority to make the UX of connecting my\nmobile LN client to my home full node extremely easy, so that centralised\nservices can't improve much on that step. Especially if I already run a\nfull node.\n\nFor what it's worth, this is a main research area for us at Start9 Labs.\n\n\u003e Could someone briefly describe how this UX looks currently? And if it's\nnot as seamless as it could, what blockers are there?\n\nAt the root of all of these problems is that a \"private server\" is\nconsidered inconvenient. There is no fundamental reason this has to be the\ncase. The main UX challenges we've found are around installation and\nconfiguration of server applications, not to mention, that users don't have\nan existing mental model for how to imagine applications. Most people who\ndo not work on computers for a living have heard of servers but their\nfirsthand experience with software is \"apps\". The fact that there is a\ncomponent of their applications that runs remotely on computers they don't\nown.\n\nSo in short:\n1. Educating on the distinction between client and server apps is an open\nquestion whose burden will likely fall on the entire industry if we want to\nget this right and not have an exchange takeover of Bitcoin.\n2. Apps that either require \"zero configuration\" or have very easy in-app\nwalkthroughs of the bare essentials of configuration\n3. GUI style installs of server applications familiar to those who have\ninstalled desktop or mobile software.\n\nI'm sure there are more things we'll learn as we grow but these are the top\nthree observations we've made and this is our primary area of work.\n\n\u003e Private full nodes serving headers to a handful of weak devices have been\nmentioned many times as a good solution against all sorts of problems in a\nfuture full of LN + SPV nodes. I agree.\n\nThis is the main thesis I've been going on for a while. Once your full node\nhas synced the whole blockchain and the total set of headers is known, you\ndon't actually even need to carry 100% of the block data, as you can\nre-fetch a needed block from elsewhere and verify the block data matches\nthe header you've already checked for consensus. From there the header\nchain can serve as base truth for a whole set of L2+ services or L1 SPV\nwallets. Ideally, in a model like this, more expensive peer services would\nbe authenticated so that your other applications could get the data they\nneed without exposing your full node to the extra costs of those who are\nnot running their own nodes. Typically we've used Core's RPC API for this\nbut as others have mentioned upthread JSON is a wasteful format and there\nare good reasons that you'd want Lightning to be able to request peer\nservices without necessarily having ownership control over the node.\n\nThe other thing I wanted to note is the fact that the issue isn't that\nLightning does SPV, the issue is around whether or not the node it is\ntethered to is *actually* trusted since SPV necessarily trusts some\ndimensions of the information supplied to it. Doing SPV against a full node\nyou own is no more dangerous than indexing watch only addresses in Core and\nthen asking for wallet/utxo information over RPC.\n\nKeagan\n\nOn Thu, May 14, 2020 at 12:50 AM Orfeas Stefanos Thyfronitis Litos \u003c\no.thyfronitis at ed.ac.uk\u003e wrote:\n\n\u003e\n\u003e\n\u003e \u003eIf everyone runs such a privately-owned server, on the other hand, this\n\u003e \u003eis not so different from having a Lightning node you run at your home\n\u003e \u003ethat has a fullnode as well and which you access via a remote control\n\u003e \u003emobile device, and it is the inconvenience of having such a server at\n\u003e \u003eyour home that prevents this in the first place.\n\u003e\n\u003e Private full nodes serving headers to a handful of weak devices have been\n\u003e mentioned many times as a good solution against all sorts of problems in a\n\u003e future full of LN + SPV nodes. I agree. It should be therefore a top\n\u003e priority to make the UX of connecting my mobile LN client to my home full\n\u003e node extremely easy, so that centralised services can't improve much on\n\u003e that step. Especially if I already run a full node.\n\u003e\n\u003e Could someone briefly describe how this UX looks currently? And if it's\n\u003e not as seamless as it could, what blockers are there?\n\u003e\n\u003e Best,\n\u003e Orfeas\n\u003e\n\u003e --\n\u003e The University of Edinburgh is a charitable body, registered in\n\u003e Scotland, with registration number SC005336.\n\u003e\n\u003e _______________________________________________\n\u003e Lightning-dev mailing list\n\u003e Lightning-dev at lists.linuxfoundation.org\n\u003e https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev\n\u003e\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20200514/8cf2f0f1/attachment.html\u003e"}