On the Lightning network, there’s potential for a malicious (or mistaken) channel counter-party to close your channel with old state. To combat this, you need to stay vigilant (read: online) at all times, watching to punish someone who tries at a moment’s notice.
For nodes unable to stay online 24/7, or anyone who’s worried about some malicious transaction censoring, the idea is that you could have a reliable third party server that keeps an eye on the chain, and punishes anyone who tries to close out your channels with an old invalid state. These are known as Watchtowers.
Since I first started working on Joule, I’ve always had the goal of enabling seamless micropayments to happen in the background so that you can enjoy content on the web without content creators having to resort to back channel methods to get paid. Methods such as selling your data, showing privacy leaking and potentially malicious ads, or even embedding advertising into the content itself (he writes, whilst sipping on a refreshingly cold Coors Light™️).
Today I’m happy to give a preview of the first of many steps to enable seamless payments in Joule, that you should have a chance to…
Hey, this is part 4 of a 5 part series on building a Lightning app. If you’re just interested in learning more about WebLN, it’s easy to follow along! But if you want to start from the beginning, you can check out part 1 here.
Our humble pay-to-post Lightning app from part 3 works pretty well at this point, but we can do a bit more to leverage functionality our node offers by integrating WebLN, and using its API for node interactions.
WebLN is a standard for browsers to facilitate communication between user’s Lightning nodes and web apps that want…
Hey, this is part 3 of a 5 part series on building a Lightning app. If you haven’t read parts 1 & 2, you might want to start from the beginning.
Our app as we left it in part 2 of the tutorial series is now a fully functioning Lightning web app, but it’s far from the polished result we’re aiming for. It relies on polling the server for updates, and makes the page refresh when we make a post. So we’re going to speed things up by replacing some of our traditional calls with Web Sockets.
Hey, this is part 2 of a 5 part series on building a Lightning app. If you haven’t read part 1, you might want to check it out.
We left off from the previous tutorial with a basic web server that had a single page for serving up our node’s information. While it was a good start to understand how we communicate with our node, we need a proper frontend with interactivity and style, as well as expand the server to store and provide user data to really consider our project an ‘app’.
The idea for this tutorial application is…
If you’ve been following Bitcoin, you’ve probably heard of the Lightning network: a layer 2 solution to the on-chain scaling problems that Bitcoin faces that allows for near-instantaneous payments with extremely low fees.
The Lightning network has caught fire over the last year, with over 8,000 nodes online and over 1,000 BTC in public channels. We’ve also seen a ton of cool applications pop up that take advantage of Lightning’s micropayments.
TL;DR a slick contract and NPM package for efficient and fast balance checks. Scroll to the bottom to try it out and find the package.
A common task that has plagued wallet providers and block explorers since ERC20 tokens came out is fetching all of the value associated with a single address. With tokens included, you need to both call
eth_getBalance , as well as
balanceOf for each token. But what if I told you we could bundle those into a single call, and not just for a single address, but as many addresses as we want? And you can…
Sometimes when making a React component, you define prop types that allow users to pass one of N types of props. For instance, we might have some form of input component that could either be a standard
<input/> or a larger
<textarea/>. These two HTML elements have certain properties that the other does not.
TypeScript can pleasantly surprise you with how smart it is, then make you question its stupidity minutes later (at least as of
2.6.2.) My first attempt at exclusive prop types was succinct, and seemed like it would make sense for TypeScript to follow along with; I’d…