hey i'm niftynei (aka nifty). i write code at blockstream, mostly on clightning. happy to chat about anything, but here's some ideas of what to get started on
  • working on clightning
  • dual-funding, i mean, collaborative close channel spec proposal
  • spec proposals
  • the lightning spec process (how to get involved etc etc)
  • lightning's last mile problem
  • lightning as banking technology
  • shitposting
  • educating the next 100 bitcoin devs
  • bitcoin LARPs
  • working at blockstream
  • FOSSSSSSSSS
  • what's commando?
  • why houston is the best texas city
  • why the mempool is obsolete
  • lightning MEV
Besides Lightning, what are your favorite ideas for transferring coins without touching the chain?
reply
WBTC, final answer
reply
50k cold ones from the boys. TY for your work. What's your favorite pokemon?
reply
toss up btw haunter and pikachu
reply
how do you see taproot being implemented into the lightning protocol?
reply
the last lightning dev meetup we had in zurich back in october, it's generally agreed upon at the spec layer that it's something we'd all like to implement at some point. the real blocker here, afaict is the inclusion of MuSig2 into the "mainline" libsecp256k1 branch -- that or bitcoin-core etc adopting the -zkp branch that currently hosts it.
it'll happen, it's just a matter of time. last i heard the LND team is pushing ahead really hard with this -- laolu's been tweeting about reimplementing MuSig2 into his go-backed version of a bitcoin client, btcd, which i think speaks to the importance of MuSig2 adoption
reply
why do you need MuSig2 at all?
afaiu with just 2p / interactivity there are some much simpler variants that work fine...
reply
if you could magically peacefully get all the LN companies, LN devs, and Bitcoin devs to stop working on what they're working on and prioritize/focus on one thing, what would it be?
reply
world peace, aka eltoo.
people make a lot of noise about how great the penalty system is for keeping nodes honest on lightning, but the burden of that penalty data is actually enormous. it weighs down every single lightning node, especially the most "productive" or routing heavy ones. you end up paying on-chain fees to close channels to be able to compact your database to a manageable size -- there's a real world cost to the ability to enforce penalties in those extra onchain fees.
eltoo fixes this by bounding the required state storage per channel update to 1, rather than n.
reply
doesn't getting rid of state work with just AJ's proposal from https://lists.linuxfoundation.org/pipermail/lightning-dev/2021-October/003278.html
should everyone be focused on that?
w.r.t. musig being the barrier, could we just start using Taproot with a NUMS point and a traditional multisig & still get this benefit?
reply
i feel like you're using this as an opportunity to propose your own solutions rather than asking my insight about something i actually have good context for
reply
i think you're presuming bad faith -- i asked an open ended question, and asked a follow up. you could have responded with anything -- you said eltoo, and said for the purposes of state compaction being the issue. in the ranking of all problems i didn't think that was so severe. i'm mostly an outsider to lightning development, and AJ's proposal has nothing to do with anything i work on. but if it's a solution for state compaction you didn't know about, that's groovy and i hope useful information. if it's not, i'd love to learn why you don't think so.
reply
  1. Why Blockstream didn't add LN to Green wallet? Or at least making a full C-Lightning wallet / node management wallet?
  2. Will be possible in a not distant future to migrate LN channels from LND/eclair to C-Lightning?
  3. Which country do you think will be the next boom in Bitcoin adoption?
reply
no LN to Green wallet
it's on our roadmap! we're currently working on a project called "greenlight" which is how we're planning to get lightning onto mobile clients. one cool thing about greenlight is that it keeps most of the node's data in a datacenter proper, while the private keys for your node exist on the client app. this means the money can't move without your wallet's signoff, but your phone doesn't have to worry about maintaining state or keeping up with the gossip network to do routing etc.
migrate LN channels
providing a migration client seems like a great idea and we're definitely open to someone building a tool to help with this but given that LND/eclair etc are currently moving targets (they ship new releases every few months) the ongoing work to keep something like this up to date and working is more than our small team can handle.
if someone wanted to build a tool and maintain it though, sounds like a great idea!
one first step for this would be to add support for aezeed (LND's seed wallet generation scheme) and whatever eclair's using to clightning, so you could seamlessly move your channel keys over.
country
does the USA count? are we booming yet? the USA, of course.
reply
What is Lightning's last mile problem?
Also curious to know why the mempool is obsolete
reply
last mile problem
you know how telecom companies have no trouble justifying committing capital to building cable networks between extremely busy hubs because there's lots of users (and they can get lots of monthly subscriptions per cable laid)? it's harder to get them to lay miles of cable out to everyone's house in the boonies etc though because the cost to lay the cable will never be repaid by the customer that it serves
the analogous thing in lightning is capital, which is to say who's putting what bitcoin in what channels. if you're a smart capital allocator, you'll only want to commit your funds to channels where it'll get used -- this is because you have real network costs like onchain fees etc that need to be covered (in theory) by the routing fees that you're able to earn from that capital.
who's going to want to put lots of bitcoin into small channels with every end user, who maybe receives a $100 payment every week or two? the onchain costs are high for the amount of turnover that capital gets
mempool is obsolete
I wrote a post to the mailing list about this sometime last year; the general gist of it is that the mempool makes plenty of sense when every other node on the network is participating in looking for the next block (aka mining). in that case, sending every transaction to every node on the network makes a lot of sense
most block construction is fairly centralized now to a handful of mining pools, yet we're still wasting a bunch of bandwidth btw bitcoin nodes ... rather uselessly imo.
reply
Appreciate the thoughtful responses here.
most block construction is fairly centralized now to a handful of mining pools, yet we're still wasting a bunch of bandwidth btw bitcoin nodes ... rather uselessly imo
What solution makes the most sense to you given the fairly centralized nature of mining pools today?
reply
so like, i've been meaning to write a follow up post to ML post about this but whatever, sure staker news it is.
stratumv2. specifically, i think the mempool should be ported out of bitcoin-core to stratumv2.
reply
I'm not familiar with the specifics but i disagree out of hand... here is my 2 sats:
  1. transaction sending is critical bitcoin's functionality, i broadcast transactions that i am sent by friends from my node on a somewhat regular basis. therefore it should not be removed from core.
  2. individual node operators who would prefer not to relay transactions may reduce their bandwidth with Blocksonly mode.
Blocksonly reduced the node's bandwidth usage by 88%.
That's significant. But i still think that bitcoin core needs to have the ability to receive & broadcast transactions, therefore it should not be removed from core.
What questions should i be asking to better understand your point of view?
reply
broadcasting a transaction is not the same as relaying a transaction to a miner?? you'd still be able to broadcast a transaction to the relay network from your node, you just wouldn't see other node's transactions until they were included in a block.
if you cared about participating in the bitcoin relay network, you could run stratumv2.
reply
I agreeing that investment makes sense where ample use will pay it back. The telecom example is excellent. A thought: Customers can be found living in many places but shopping in a few. Perhaps a shopping mall (or an investor near one) could create a medium-size node and connect to it (a) the stores in the mall, and (b) the customers coming to the mall? I will be the first to say that MUCH communication will be needed to accomplish this, but I thought I would throw it out there.
in which ways is clightning better than lnd and eclair?
reply
this would be an easy question to answer if i used LND or eclair or had any understanding of what featuresets they offered etc. unfortunately i dont really have that insight. instead i'm going to talk about the features on clightning that i like.
  • we're about to ship some pretty in-depth bookkeeping data collection for every move each and every msat makes on your node. it'll include CSV dumps for a few popular tax tracking apps (cointracker, koinly, etc). unfortunately it won't be historical. :'(
  • i've been really really excited about the commando plugin work that @jb55 is doing with LNLink https://lnlink.app/
  • offers (aka bolt12 invoice) are such an incredible upgrade to the lightning invoicing process. i've personally been itching to do more with them.
  • you can advertise liquidity from you node using liquidity ads! it doesn't cost you anything, you don't have to install anything extra, just set some parameters and it'll show up on LNRouter's liquidity ad marketplace https://lnrouter.app/liquidity-ads. someone just posted in the telegram group about how they set one up not expecting much (since you can use other services like LN+ to get inbound liquidity) but they ended up getting 24k sats from a channel sale randomly!
  • the collab channel opens protocol i added to clightning makes it possible to do decentralized coinjoins via a channel open -- just do a multifundchannel and buy inbound liquidity using advertised ads from 2-3 people and viola. you've basically executed a neat little coinjoin into multiple channel opens.
reply
Yeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeesss! Upgrading to c-Lightning atm and keen to dig into all of these :-)
Thanks for all your work!
reply
Do you have a Lightning Address? (other than the one that Stacker News gives you)?
What are your thoughts on that gaining traction?
reply
i do not have a lightning address. tbh i don't actually know much about lightning addresses. having a nym that people can just send you money to sounds great? i'm into the idea. seems pretty important for peer to peer payments to have easy handles to send cash to each other.
reply
What's your opinion on stabilized Lightning (the idea of doing stablecoins on LN, or being able to peg fiat balance, etc)?
reply
ok so let's talk a bit about what the hell "lightning" even is.
lightning is a (near) instantaneous settlement layer for bitcoin transactions. you lock bitcoin balances into a contract and then you and some other party decide how much of that total bitcoin balance locked in the contract that you're entitled to.
i'm not sure what anyone means by "stablecoins" on LN as they're over a bitcoin pool, but if you wanted to use different rules for deciding who's entitled to how much bitcoin in the shared pool, that sounds like a challenging and fun project.
at some point you run into an "expressivity" problem with bitcoin scripts though, is my understanding, which is to say "what rules are you able to enforce via the bitcoin contracts themselves is limited". this in turn limits what rulesets are even available to you to use for deciding who gets what in the bitcoin pool.
iiuc taproot allows for far more complicated scripts, so moving lightning contracts to taproot ones gives you a lot more options for new rulesets to introduce about who owns what in the shared bitcoin pool.
the downside to a bunch of rulesets imo is communicating how those rulesets work to people that might want to use them. the current ruleset is incredibly straightforward (this is my balance, this is your balance. you can ask me to put some of that balance into escrow but can't claim it until you prove you've got authorization to move those funds).
reply
Thank you for those thoughts, very much appreciated! I'm coming at this from UX perspective of what experience me (and other users, especially outside of US) would want and need from "Bitcoin". My question is exploratory about whether the place where our requirements meet with the implementation is on the Lightning boundary or whether that's elsewhere.
In essence, we want to have a fully self-custodial open-source mobile wallet where I can hold balance in two currencies - one in fiat (especially USD) and one in Bitcoin. I want to be able to easily move value between those two currencies on demand and I want to use either to pay for stuff with standardized QRs (i.e. I want the wallet to figure that out for me...).
The main two reasons to want fiat balance are:
  • Avoid Volatility: This is not just a meme, higher volatility can easily bankrupt individual or company that have large amount of money "on the line" because of slim margins. Further people in US don't realize that for many countries in the rest of the world, getting access to USD balance would be already thousand times better compared to their current situation. I have this experience and it thoroughly sucks to get USD account from another country and then it's not interoperable with other accounts anyway.
  • Onboarding: It'd be much better onboarding experience if I could first start using the wallet for USD and gradually start switching to Bitcoin when I'm ready. We have this already with Strike and CashApp, but we don't have self custodial solution and that sucks (this is again where people outside of US have generally much worse experience...)
Question no. 2: What's your favorite PIN?
reply
if you actually want a balance in the stablecoin and not some “the amount of bitcoin in this channel that you own is based on the current exchange rate of usd to btc” you’ll have to use something else. (This is a synthetic stablecoin on lightning, and requires changing the rules that govern who owns what in the channel, which is what my previous point was about).
I get really excited about the “peerswap for assets on liquid” proposal, which iiuc lets you hold stables on the liquid chain and swap them/send via lightning as atomic swap trades... it’s a simple solution to the problem and probably has some downsides (is liquid reliance a downside? im not sure). but definitely more decentralized than the existing solutions.
i actually think more “hold balance in liquid btc + lightning” is an imperfect yet perfectly decent way to help solve the lightning last mile problem. the first wallet that launches peerswap/liquid plus lightning support is gonna be extremely competitive imo, as it can always do the last hop via liquid if there’s not enough capacity in the end user’s channel. this will work really well until liquid becomes congested, but until then…
reply
Read a twatter post from Joko last night that talked to using LN to achieve the outcomes you're seeking - may be worth a squiz:
reply
Thank you! I saw it here on SN, but I'll keep an eye on it more, since initially I was skeptical. This seems to me like a really hard problem so I'm interested in seeing how they solve it. I still wonder if LN is even the right layer to do this on. (I know that HRF also has a bounty on this...)
reply
The Galoy folks were demo-ing their take on this at the Istanbul hackathon a few weekends ago
Any chance of recording your classes and selling them for sats?
reply
chance, yes. but it's not planned for this year. turns out i really like doing live instruction and really hate editing videos, lo siento.
reply
Do you have plans to start an online/remote bitcoin development class?
reply
base58 is online! we meet on zoom twice a week.
out of curiosity, what would you expect to learn in a "bitcoin development class"
reply
I'm not familiar with Base58. Is that just a brand and is Blockstream-related, or is that your own thing?
reply
it's my own thing. I teach classes on the bitcoin protocol for fun and profit.
We're on twitter here: https://twitter.com/base58btc Bitcoin TV here: https://bitcointv.com/c/base58/videos?s=1 Our website is here: https://www.base58.info/
We're going to be opening up signups for classes for the rest of this year really soon
reply
You can learn more here: https://www.base58.info/
reply
What's your caffeinated drink of choice?
reply
americano, black
but s/o to my bf who has gotten me really into nespressos ☕️
reply
Funny, my wife is also into nespresso.
The real question is, how much of it do you drink to code?
reply
when was your first tx?
reply
reply
Are there any available eye of satoshi instances I can simply connect my c-ln node to?
reply
this is a great question that i don't know the answer to. it's possible there is one, but i dont know of any.
reply
So why houston is the best texas city? All we ever hear about is the Austin hype...
reminds my why can't we have a Buc-ee's in between Nor-cal and LA...
reply
houston's the largest gritty/industiral southern city in the US. it's also got great (hot humid) weather, amazing crawfish boils, and some of the most affordable housing in america. people also tend to forget about houston on the national stage, which is kind of nice imo.
i think people forget what it's like to live in a city where most people can work a job, have a family, own a house, and just live their lives at the rate they see fit.
i also really like how incredibly insane the drivers are here, but i get that not everyone is into participating in a speed derby every time they get on the freeway. at least houston drivers all understand the rules of getting there; austin traffic is infuriating in a way i never get stressed on houston highways (which i largely blame on poor road design and underinvestment in viable public transit)
reply
Wow.. i think you just set the record for sats stacked from a post on SN… what are you going to do with your newfound riches?? 🙌
reply
pay some fees to liquidity advertisers to get more inbound channel capacity hehehe
reply
  1. favorite books?
  2. why did you pick txs as the basis for Base58?
  3. how will we get the lightning implementations to get along?
  4. Austin said the devs at blockstream have a kill switch or something that can blow up the company if they do the wrong thing, is that true?
reply
  1. don't shoot the dog by karen pryor; garth nix's abhorsen series; anything by michael lewis or jane jacobs
  2. i'm really proud of the method that we build up the knowledge about transactions in base58 (which includes elliptic curves and signature schemes and bitcoin script, btw). when i was learning about how txs worked for building the v2 of channel opens for lightning, i really struggled to figure out how to make transactions work. setting up base58 to teach it was really just me trying to figure out if other people would find the info valuable -- so far everyone seems to be having a good time and getting a lot out of it so i'd say that it was a pretty good intuition.
  3. non-network dominance. cooperation matters a lot more when you actually have to cooperate to see your new features get adoption
  4. based on the murmurings i've heard, i'd be more worried about the moon than the company per se...
reply
On (2), IMO it is the right thing to teach. I was just wondering how you knew it was. When I was doing chaincode, I felt like I learned everything really well but txs, which makes sense given chaincode's mission.
reply
it's been pretty delightful to find out that what i wanted to teach is filling a gap <3
reply
When Clint (at least I think it was him) was telling me about your class before it was base58, I was like "omg this is exactly what's needed."
It's really easy to get lost in the weeds with mining and stuff when txs are the things non-core developers are going to be using. txs are sort of like the api layer and everything else is implementation details.
reply
There might be a big gap for lightning "api layer" classes too if not even more so. I get so many questions about how to build stuff "on top" of lightning.
reply
i keep hearing this ;D
reply
What's something you believe about Bitcoin that few people agree with (including other bitcoiners)?
Forgive the Theilism.
reply
tbh i don't really think too hard about being agreeable, so this is actually a harder question to answer than you'd think.
that being said, i am not convinced that we need to bring financial engineering primitives to the bitcoin ecosystem.
reply