Re: [Lightning-dev] On the scalability issues of onboarding millions of LN mobile clients
traffic to the backbone network. If > you assume 10K public nodes, like today, assuming _all_ of them opt-in to > signal BIP 157, that's an increase of 100GB/month for each. Which is > consequent with regards to the estimated cost of 350GB/month for running an > actual public node. Widening full-node adoption, specially in term of > geographic distribution means as much as we can to bound its operational > cost. > > Obviously, deployment of more efficient tx-relay protocol like Erlay will > free up some resources but it maybe wiser to dedicate them to increase > health and security of the backbone network like deploying more outbound > connections. > > Unless your light client protocol is so ridiculous cheap to rely on > niceness of a subset of node operators offering free resources, it won't > scale. And it's likely you will always have a ratio disequilibrium between > numbers of clients and numbers of full-node, even worst their growth rate > won't be the same, first ones are so much easier to setup. > > It doesn't mean servicing filters for free won't work for now, numbers of > BIP157 clients is still pretty low, but what is worrying is wallet vendors > building such chain access backend, hitting a bandwidth scalability wall > few years from now instead of pursuing better solutions. And if this > happen, maybe suddenly, isn't the quick fix going to be to rely on > centralized services, so much easier to deploy ? > > Of course, it may be brought that actually current full-node operators > don't get anything back from servicing blocks, transactions, addresses... > It may be replied that you have an indirect incentive to participate in > network relay and therefore guarantee censorship-resistance, instead of > directly connecting to miners. You do have today ways to select your > resources exposure like pruning, block-only or being private but the wider > point is the current (non?)-incentives model seems to work for the base > layer. For light clients data, are node operators going to be satisfied to > serve this new *class* of traffic en masse ? > > This doesn't mean you won't find BIP157 servers, ready to serve you with > unlimited credit, but it's more likely their intentions maybe not aligned, > like spying on your transaction broadcast or block fetched. And you do want > peer diversity to avoid every BIP157 servers being on few ASNs for > fault-tolerance. Do people expect a scenario a la Cloudflare, where > everyone connections is to far or less the same set of entities ? > > Moreover, the LN security model diverges hugely from basic on-chain > transactions. Worst-case attack on-chain a malicious light client server > showing a longest, invalid, PoW-signed chain to double-spend the user. On > LN, the *liveliness* requirement means the entity owning your view of the > chain can lie to you on whether your channel has been spent by a revoked > commitment, the real tip of the blockchain or even dry-up block > announcement to trigger unexpected behavior in the client logic. A > malicious light client server may just drop any filters/utxos spends, what > your LN client should do in this case ? [1] > > Therefore, you may want to introduce monetary compensation in exchange of > servicing filters. Light client not dedicating resources to maintain the > network but free-riding on it, you may use their micro-payment capabilities > to price chain access resources [3]. This proposition may suit within the > watchtower paradigm, where another entity is delegated some part of > protocol execution, alleviating client onliness requirement. It needs > further analysis but how your funds may be compromised by a watchtower are > likely to be the same scenario that how a chain validation provider can > compromise you. That said, how do you avoid such "chain access" market > turning as an oligopoly is an open question. You may "bind" them to > internet topology or ask for fidelity bonds and create some kind of > scarcity but still... > > Maybe I'm completely wrong, missing some numbers, and it's maybe fine to > just rely on few thousands of full-node operators being nice and servicing > friendly millions of LN mobiles clients. But just in case it may be good to > consider a reasonable alternative. > > Thanks Gleb for many points exposed here but all mistakes are my own. > > Cheers, > > Antoine > > [0] UTXO set size may be a bottleneck, but still if you have 2 channels by > clients that's 20M utxos, just roughly ~x3 than today. > > [1] And committing filters as part of headers may not solve everything as > an attacker can just delay or slow announcements to you, so you still need > n
Re: [Lightning-dev] Lightning JavaScript implementation that conforms BOLT
Hi Aleksey, Your biggest obstacle is probably the fact that c-lightning spawns several processes (subdaemons) and depends on the bitcoin-cli binary for bitcoind RPC. If WebAssembly supports multiple processes (not just threads) that's a good start I guess. There is a c-lightning specific mailing list on https://lists.ozlabs.org/listinfo/c-lightning Cheers, Igor On 12 April 2018 at 16:39, Быхун, Алексей Викторович < aleksey.byk...@phystech.edu> wrote: > Hi everyone! > > I am looking for a way to run a LN node inside the browser. One way would > be to implement BOLT protocol from scratch in JS, but I am thinking of a > more easy way. > > Has anyone succeed in compiling, for example, c-lightning project ( > https://github.com/ElementsProject/lightning) under WebAssembly ( > http://webassembly.org/getting-started/developers-guide/). > > WebAssembly is a C/C++ compiler into browser-compatible byte-code. It can > use JS-API, but can also work with low-level C functions. > > There are some things c-lighting does (e.g. sockets), that should stop it > from compiling easily. However, there are wrappers for many C-functions by > Emscripten lib: https://github.com/kripken/emscripten. > > My question is what should I look for when trying to run that? And also, I > want to hear your general feedback on the idea. > > Aleksey Bykhun. > > ___ > Lightning-dev mailing list > Lightning-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev > > -- *Igor Cota* Codex Apertus Ltd ___ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
Re: [Lightning-dev] QR of node information
Hi all, On 9 April 2018 at 11:47, Corné Plooy via Lightning-dev < lightning-dev@lists.linuxfoundation.org> wrote: > > Is this really only about reducing the size of QR codes? How many > percent reduction do you think you can accomplish with your approach? I > think, when it comes to reducing QR code size, it makes more sense to > think of a better way to encode the node ID. Hexadecimal isn't exactly > the most space-efficient encoding. > We'd save 33 bytes by not using hex. Makes the QR code a bit rarer (whatever is opposite of dense). I intend to support both approaches, if there are 33 bytes before the '@' it's raw, 66 it's hex. Igor > Op 07-04-18 om 17:17 schreef Robert Olsson: > > Hello all, > > > > I seem to not find a bolt regarding the QR code of node@ip:port > > > > It seems eclair only supports the format hex@ip:port format, and i > > haven't tried any other mobile wallets. > > > > I thought there would be support for bech32 nodeid:s to keep the QR > > small, but it doesn't seem that way. > > > > If it isn't standardized yet, i think we should do it soon so all > > wallets will support it from start and we can avoid bulky QR codes. > > > > To fully utilize QR it should work with charset in text-mode, so i > > would suggest a format like > > > > lightning:ln1bech32nodeid/ipnumber/port > > > > where /port is optional if port is 9735 > > > > this is to avoid @ and confusion of : in ipv6 and :portnumber > > (skip '[' and ']' in ipv6) > > > > another approach would be to encode ip and portnumber in bech32 as > > well. my opinion is that everything coded entirely in bech32 shouldn't > > need a protocol so the 'lightning:' part could possibly be omitted as > > well. > > > > or did i just miss a bolt somewhere? > > > > best regards > > Robert Olsson > > > > > > > > > > > > > > > > ___ > > Lightning-dev mailing list > > Lightning-dev@lists.linuxfoundation.org > > https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev > > > ___ > Lightning-dev mailing list > Lightning-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev > -- *Igor Cota* Codex Apertus Ltd ___ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
Re: [Lightning-dev] Lightning over NFC
Morning all, > However it seems to me that the payer will need a direct channel to the payee, or at least the payment terminal (of the payee...?). Yes, for the lightning NFC connection I had the local coffe shop use case in mind. > The trusted server can, for instance, be a full Lightning node running at the payer's home. This is my current setup and I feel the only feasible one for the privacy minded. For the time being at least. > The payer then only has to take a very light piece of electronics with him/her. It will still be larger than a credit card (since authentication should be done payer-side, e.g. with a PIN code), but it can be smaller than a smart phone. This is a great idea! > But what the payment terminal would provide, would not be a connection to the payment terminal node, but a connection to the Internet-in-general. ¿Por qué no los dos? I'm thinking of a protocol where (after initial BOLT-11 transfer) the terminal and device agree on the means of connection depending on what they respectively support or makes sense at that moment. There is a standard way for NFC to handover to bluetooth or wifi, I'll look into that. Basically whatever works as long as it seems seamless to the user and is relatively quick. I'm not so fussed about potential abuse for these types of payments. In my experience people are less likely to scam you if you are physically there. :) Thanks for your input! I made a pull request for the BOLT-11 MIME type and I'll have a think-over bout the connection-handover business. Cheers, Igor On 5 April 2018 at 18:53, ZmnSCPxj via Lightning-dev < lightning-dev@lists.linuxfoundation.org> wrote: > Good morning Corne, > > My understanding, of the setup of Igor, is that, there is a > Lightning-protocol connection between the mobile device and the base > station/payment terminal device. > > Initiating a payment to anyone on the network requires that you have > direct communication with whoever you have a direct channel to. > > If the mobile device can communicate only with the payment terminal, then > it can only pay using channels with the only node it has a connection to. > > The mobile device could pay anyone else on the network via that channel, > but presumably the purpose of the payment terminal is to be the node that > receives the payment. > > If the payment terminal itself connects to anyone else, on behalf of the > mobile device, then that is beyond the current Lightning protocol. Perhaps > Igor has added more messages that allow such a setup? > > Communicating over a secure channel to a trusted server is how I imagine > most practical mobile devices would work. But what the payment terminal > would provide, would not be a connection to the payment terminal node, but > a connection to the Internet-in-general. > > Regards, > ZmnSCPxj. > > > Sent with ProtonMail Secure Email. > > ‐‐‐ Original Message ‐‐‐ > > On April 5, 2018 11:52 PM, Corné Plooy via Lightning-dev < > lightning-dev@lists.linuxfoundation.org> wrote: > > > If there are censorship concerns, you could opt for a set-up where payer > > > > has an authenticated connection to a trusted server, through the > > > > Internet connection provided by payee. The trusted server can, for > > > > instance, be a full Lightning node running at the payer's home. > > > > The payer then only has to take a very light piece of electronics with > > > > him/her. It will still be larger than a credit card (since > > > > authentication should be done payer-side, e.g. with a PIN code), but it > > > > can be smaller than a smart phone. Personally, I like this kind of > > > > set-up, because I see cell phones as a huge privacy issue (you're > > > > continuously transmitting your rough location to the network). > > > > Why would there need to be a direct channel between payer and payee? We > > > > have the Lightning network to avoid needing direct channels, right? > > > > CJP > > > > Op 05-04-18 om 17:39 schreef ZmnSCPxj via Lightning-dev: > > > > > Good morning Igor, > > > > > > This is quite an interesting use-case for Lightning. > > > > > > However it seems to me that the payer will need a direct channel to > > > > > > the payee, or at least the payment terminal (of the payee...?). > > > > > > In addition the payer will need to somehow get blockchain information > > > > > > from the payee if the payer itself has no Internet. The payee may > > > > > > have an incentive to prevent the payer from knowing that timeouts have > > > > > > been reached
[Lightning-dev] Lightning over NFC
Hello all, I feel that one of the biggest promises of lightning lies in it being used for everyday retail payments. I'd like to see a system that's: 1) instantaneous like the contactless bank cards of today 2) encodes a fancy HTML receipt in bolt11 for the payers future reference QR codes are a bit unwieldy and even more so if you want a nice HTML table description of your grocery shopping with hundreds of items - this relatively large amount of data makes them impractical to scan. To this end I've been running an instance of c-lightning on Android [1][2][3] and experimenting with payments via NFC. I set up a machine with an NFC USB dongle that acts as an point-of-sale terminal [4]. So far so good! There are two basic ways you can use NFC enabled phones today - as passive tag readers or in card emulation mode (not sure if the latter is available on iOS). Passive tags are really simple and encoding bolt11 to them works as expected. If you set the right MIME type Android will open whatever app is registered to handle lightning and you can either pay instantaneously or after user confirmation. Works great provided both the phone and terminal are connected to the network and have a route to each other. Card emulation mode is more interesting because it enables us to have two way communication and therefore an ad hoc connection to the lightning network. After some handshaking, phone can tell the terminal that it wants to connect to lightning via NFC. All communication between these two lightning nodes can be done over NFC or even bluetooth [5]. This might be useful as fallback in situations where mobile data is not available. I settled on a MIME type (application/lightning) and an NFC application id (LIGHTNING). There is also a very simple protocol to forward socket data. For the sake of interoperability it would be great if we agreed on some standards but I'm not sure how to proceed with this. Should these be part of a future BOLT or is mailing list banter enough? I look forward to your views! Cheers, Igor [1] https://github.com/ElementsProject/lightning/commit/bd95aba7a5f9bad8f447bf3de8f7e8cfe83751af [2] https://github.com/ElementsProject/lightning/commit/d4d1c4acb08efb6be4f491cdee5cb6dd4b84ddf7 [3] https://github.com/ElementsProject/lightning/commit/bd95aba7a5f9bad8f447bf3de8f7e8cfe83751af [4] https://github.com/icota/presto [5] https://github.com/ElementsProject/lightning/pull/1323 ___ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
