Meeting Notes 2021 06 14
Elias Rohrer edited this page Aug 9, 2022
·
4 revisions
- ccdle12 -- lurking, joining the meeting
-
we have ppl who wanna use stuff, also getting to the point where things are reasonably stable. Been stabilizing on-disk format, etc. certainly API not stable, but in terms of usability, goal being focusing on testing etc, which would imply that we are rapidly approaching a 0.1 that we’d be happy w/ ppl using. So 0.0.98 seems appropriate, still fits in an 0.0.99 so we can have more fixups that miron finds.
-
Matt: ppl should read thru docs if they have time.
-
Antoine: so 0.1.0 will be first prod-ready/blessed for prod?
-
Matt: yes. Depends how comfy we are w/ mainnet, but in terms of sth we’d like people to be testing more broadly, yes. It’ll be ready when it’s ready, timeline is dependent on people testing it.
-
Antoine: compatibility testing would be good, and interop testing.
-
Jeff: we are currently doing interop testing w/ igor, including overtorm on mainnet.
-
Miron: i was doing interop testing w/ lnd as well.
-
Antoine: maybe we should have max amount in channel for first release. For the first release, avoid ppl throwing too much $$ into it.
-
Matt: we don’t support wumbo channels rn. Though even non-wumbo max is pretty high these days.
-
Steve: maybe we can add to agenda: i can review what some folks missed from miami retreat. Also, there’s 3 emerging users of ldk that i’m starting to feel like we should focus on and give clarity on what to say “no” to, so we should review that in this meeting.
- Antoine: rebased on main. Big Q around utxo pool api, which is a new api, not part of our scope. You need to use this pool to close your channel. Big Q, is this api sounds sane/correct? So would be glad to have concept ACKs before further review.
- Jeff: happy to take a look at it, we’ve had it on our radar for a while.
- Miron: had a couple of things against rust-secp256k1, added a lock feature. Previously had to allocate sep256k1 context for nostd, not so nice, esp since in RL we allocate a bunch of them. So i added that. Also added optimization for mobile devices, cuz each context would be many kilobytes. Also PR for context to be 50 bytes and with static multiplication tables, but got feedback that it should go into the c++ library and i don’t have experience w/ that lib, so that might take some time.
- Matt: dont think andrew has time for that, you could nag on their irc channel, #secp256k1 irc channel. Maybe sipa would have time.
- Antoine: i can review on libsecp.
- Miron: it’s a build thing, makefile thing. So i would just have to look at how exactly they do stuff, will take some context switching. But yeah i can keep progressing.
- Miron: added code to support this io library for nostd, and crate for bitcoin-hashes, went in. and i had a PR for rust-bitcoin, and we almos merged the first part of that. And then gene forneau started waking up his PR against RL so there’s good progress there.
- Mentioned in PR 948 commit mgs. What should we do with it?
- Matt: most of it’s really nice changes, but someone needs to sit down and rip up the git history. Not practical to review the whole diff at once. Not sure if much to discuss.
- Conclusion: backburner for now. Should close once it gets stale enough.
- Jeff: could give a heads up before closing it
- Matt: he muted the project so no need
- Miron: i did a bunch of testing against lnd on signet. So 3 nodes, lnrod twice, and lnd as the 3rd node. Found a bunch of interesting things, like bugs on lnd side. I ran into a bug that matt found a year ago, and it was forgotten and nobody did anything. Also found things in RL, private chans not sending unicast chan updates. Also a bug that hangs, busy-waiting on closing a socket. Finding interesting stuff, need to be able to do more things like that, be reckless and maybe even put stuff on mainnet and poke around cuz i think some things are impossible to find unless ur running an actual node and connect to random other things.
- Miron: one of the goals is to be a routing node, idk if top prio, but i think stuff mostly works for that use case.
- Matt: BW doesn’t intend to use this
- Conor working on that but he’s not here
- Steve: no updates here, it’s on my agenda to talk to him tmrw. Conors gonna work on website + dev docs, and a bitcoin builder event. Also give feedback on bdk and ldk, the dev process.
- Jeff: i think we didn’t focus much on this since last time. Updated to latest API, fairly minor. Then getting it up-to-date w/ using LDK guide. Not much else there.
- Jeff: matt and val have put a lot out last week. There’s a rust and java version for building a node cuz diffs between the two. I’m working on Using LDK guide, gonna get to your feedback today. Small change val opened for me in blockchain data for electrum users.
- Matt: how much promotion do we wanna do for this vs 0.99 vs 0.1?
- Jeff: could push back but i was thinking for 0.1 cuz it’ll have ldk website in a happier place hopefully. More shine on it.
- Ariard:
- Ariard: we wanna take initiative on it, discussed in miami. Gonna be a lotta work in internal api. The
- Arik: the greatest prereq is getting rust-bitcoin ready for it before we can start on RL. chris stewart reached out ytd, asking about DLCs. so there is interest in having a demo of DLCs that are powered by LDK, and that should not require as much work on RL’s part as multihop ptlc txs.
- Ariard: multihop dlcs, first we have to solve computation issues for sigs on every hop and stuff, dlc signature space, and the first goal should be 1st doing dlcs over payment chans, single-hop.
- Arik: agreed. Multihop can come later.
- Ariard: when done w/ anchor, OK to work actively on this. But wanna do anchor 1st. Tibo, the Cryptogarage guy, has rust dlc impl w/ main data sigs for dlc, it’s not prod ready and i need to hop in, but could be a dependency for LDK dlc support.
- Ariard: would be glad for us to support this soon. If someone wants to work on it, can review. Design not finalized yet, still under discussion. Sth every impl wants, to be able to do security upgrades on LN, etc. RFC PR 896. https://github.com/lightningnetwork/lightning-rfc/pull/869
- Ariard: talked chan jamming mitigations w/ laolu in miami. He wants these trusted solutions. Best we could agree on was an interface generic enough to negotiate chan jamming mitigation scheme.
- Steve: first of all, pointing out, i believe we had a lightning/bitcoin first, which was syncing an LN wallet between 2 devices. Multi device access on iphone and android, thru work on BW. i believe that’s a first, pretty cool demonstration of uniqueness of ldk. We won’t brag on twitter yet. Just a quick review of miami topics… 1. Prod readiness checklist, which we spoke to, so we have a goodish handle of what we wanna do before we can bless it for mainnet usage. 2. Taproot support. Schnorr, PTLC support, are all distinct. Also there’s additional work for multihop and w/ lightning routing. So why prioritize this? One motivation could be just to be leading rather than playing catchup, which ldk has been doing. Could help market proj as a great toolkit to do experiments on and next-gen innovation of bitcoin. 2nd motivation for supporting taproot sooner than later, will get to that. 3. Receiving lightning payments on mobile + HW wallets and challenges of offline. No genius answers here, so that’d be an ongoing topic. Medium-long term solution, HTC and apple should change their phone software to support it. And samsung did reach out after square’s HW wallet announcement, and they’re interested in collaborating there. E.g. allocating cpu time after receiving a push ntfn.
- Miron: how do we feel bout the UX of push ntfn, incoming payment, click on the ntfn to actually receive it, which would bring the app to the foreground?
- Steve: yeah samsung changes is still a bit wishful thinking. So we do have to think of other solutions like that. It remains a problem space for HW wallet or phone to receive.
- Steve: also, multisig lightning chans. Need TR (taproot) activation, need LDK support for schnorr sigs, and we need FROST support or custom scripts that exist between peers.
- Steve: potential focus for LDK projs: good news is, much more interest from projs in using LDK now than 6mos ago.
- Bluewallet. Which is looking very promising, they invested a lotta eng effort, lots of stuff working w/ ldk now on android+iphone, also syncing between the two. Prob will be the first app on ldk to launch. They’re a popular wallet, and i think there’s reason to believe they’ll have a lot of adoption. We should keep focusing on them
- Sphinx chat. They’re super cool app, actually want to run some subset of ldk on a lil hardware stick, and doing that for security reasons. And have both their chat app but also their business, which is connecting jobs/tasks with workers. Approach to noncustodial: which i hope passes regulatory muster: they consider themselves noncustodial, their customers basically run a lightning node in the cloud in which customer has access to that cloud instance and the keys. So not in an embedded device, but in the cloud. And they’re claiming to not be custodians because they’d have to hack into those cloud devices. So how to use HW devices for ldk+lightning signer? They’re just doing that to isolate the signing onto that device. So those lil raspis will be in a data center somewhere, and each customer account would have one initially. Long-term, maybe it’s a device the customer actually holds in their physical possession. Think they’re super promising.
- Square itself. Couple weeks ago, sq/jack tweeted that sq’s considering a HW wallet. Could lead to needing taproor/schnorr support in LDK.
- Steve: So these 3 looking promising and would likely have huge adoption. So prob not gonna bug matt or others about supporting react native in the near term, cuz there are ppl that want react native for LDK, but i do think the 3 projects just mentioned are so promising in unique use of LDK and potential impact that we should just prioritize that
- Matt: dude running this hackathon was wondering if someone would want to do a 5min video about how to integrate ldk into your app, why you’d want to use it, etc
- Action item(jeff): follow up on this video