152 sats \ 0 replies \ @JohnCantrell97 OP 27 Jul 2022 \ parent \ on: [Education] Onion Routing on the Lightning Network bitcoin
Yeah it hasn't been too much of a problem so far. It might be more than 90% honestly. I've seen some reports of 99%.
I'm not actually too versed on potential solutions but I think it will need to be addressed at some point. I know there are a couple competing ideas people are arguing about trade-offs over but no obvious solution at this point.
Whoops, my bad. I just assumed it was basically the same. I guess it's still onion routed in the sense each layer is encrypted for the next hop? I'll have to look into how tor works at some point.
Yes, this is possible. The last hop will fail the payment because it won't know who the next hop is supposed to go to.
What is more common is to have the payment hash be set to a random value so the sender knows for sure the payment will fail. This is called "probing" and people do it to figure out if a payment for a certain amount will work on a given path.
It's VERY spammy at the moment, something like 90+% of payments over lightning are currently probing attempts that fail (on purpose).
I'm not too familiar with them at the moment. It sounds like they can potentially provide a slightly better custodial experience so it probably makes sense to add support to sensei for them. Will look more into it soon!
I haven't actually read many btc books actually. I only have read the more technical ones (programming bitcoin, mastering bitcoin, mastering lightning network, etc). Since I'm largely focused on lightning these days I'll say mastering lightning network is my favorite btc book :)
Non bitcoin book, I guess I have to go with cryptonomicon since it's where my pseudonym comes from.
As for my building journey I don't think there's really a book I would recommend there. I think I've learned way more by actually building and then reading and watching docs/guides/tutorials/youtube to help get me unstuck.
Hard to pinpoint something that I would want to tell my younger self other than to mine bitcoin in 2009. I don't have many regrets in my life thus far, things have worked out pretty well.
I think maybe I would have said to not spend so much time playing video games. While I think they ultimately lead me towards becoming a software engineer, I probably spent way too much time with them when I was in middle/high school.
Hey! Yeah that was a project I put together for the impervious hackathon. It's still unclear if it's really a good idea to use lightning to move data back and forth like this does. In reality I'd love to find a way to do the same thing but just use lightning for pay-per-execution. I think you can pretty much do this type of thing with LSATs but would still be nice to build a little framework around it. I'd also love to find a way to enable 'trustless' code execution where you can pay someone to run the function for you but have proof they didn't modify the code that is run. I think there's a way to do this as some future extension of ideas used in DLCs.
Once VLS is integrated it's probably a workable solution if you need to be non-custodial. The problem is that the partner orgs would still need to run some kind of long-running daemon (the signer) so if they can do that they probably can just run their own CLN/LND node.
I guess once some of the LSP functionality lands in Sensei then there might be an argument that you could essentially manage liquidity for their nodes for them without them needing to deal with it. They'd still need to run the signer though.
I'm not a lawyer but it's also possible even running Sensei in custodial mode (keys are in memory on the machine) might not count as custodial in the legal sense. You can set it up so they still log in with their own username/passphrase and this passphrase encrypts the seed on disk so you never have direct access to it. This is the voltage model and they largely claim to the non-custodial (as far as I know).
I guess it largely depends on the exact requirements?
I think maybe the most 'obvious' fit for Sensei could be as a completely open-sourced greenlight alternative (though I think they have plans to eventually open-source the backend).
Another interesting use-case for Sensei might be for businesses who conceptually like the idea of LDK and have plans down-the-road to require a more customized lightning experience but don't have the resources to start down that path today.
They can start with Sensei (a LDK based node) and easily migrate their entire infrastructure to their future custom ldk based node without having to 'start over'. They can migrate their existing channels and funds without real downtime.
I think it's early days for Sensei and I'm confident it will find its niche as its feature set gets more developed. Stay tuned :)
-
I can't actually remember where I first stumbled upon it. I think it was maybe on reddit? I was already aligned with the censorship/seizure resistance mindset and was probably on a path to become a gold-bug before discovering it.
-
I initially started with just interfacing with bitcoind via the rpc apis and had built a binary options / futures market prototype with it. From there I think I used Jimmy Song's programming bitcoin as a reference for building and understanding bitcoin more deeply. I've also been through aantop's mastering bitcoin and mastering the lightning network books. I also participated in chaincode's lightning seminar and highly recommend the self-paced content should you have the time and motivation. I tend to learn best by having a project that I'm excited to build and using it to motivate me to learn what I need to in order to get the project done.
-
Hm, it sort of depends on why you are running a node. If it's just for you to be able to make lightning payments somewhat regularly then I don't think it's that difficult at the moment. You could get away with using a mobile wallet pretty easily in that scenario. If you are a merchant/business who needs to receive lots of payments then managing your inbound liquidity is probably an important challenge to tackle.
-
I don't really read that much other than bitcoin/programming books. I'm currently doing another read-through of Mastering the Lightning Network at the moment alongside the bolts to make sure I really understand everything. As for fiction, I'd recommend neal stephenson (cryptonomicon and snow crash?).
Sure, they shared it in the tweet thread when they announced the grant. The original document is here: https://docs.google.com/document/d/1--5Hh9zi2kKEZrvhAhWP_Ge9oUVPm00wcMQ40arYhoI/edit
Like I said though, my work has greatly deviated from the initial idea.
I think I had hopes that the initial sidechain proposal by blockstream would have panned out. I think that would have lead to rapid experimentation and development but it never came to fruition.
I haven't looked enough into BIP-300/Drivechains but they offer a similar promise. I'd love to better understand the arguments against it but in general would love to get something like it eventually. Perhaps the best we can do are federations like liquid and fedimint though.
With that said, I am generally a proponent of the 'take it slow and don't break things' approach when it comes to bitcoin. It's definitely not the way you should build a business but when it comes to a once-in-a-human-history project like bitcoin I'd prefer to make sure we don't screw it up.
It's a great question. With custodial Sensei and use-cases like you describe lnbits/lndhub are probably better solutions.
We are working on integrating with the VLS (validated lightning signer) project to enable remote signing for all of the nodes run on a sensei instance. Once this lands you'll be able to spin up your own personal blockstream greenlight alternative running entirely from your own instance instead of relying on blockstream's servers.
There are likely some other use cases, maybe in gaming, where you (as the game developer) don't want to deal with the regulations that come into play when you are custody'ing bitcoin and so sensei w/ remote signing might be a good solution.
Even without the remote signing, there might be some research-y use-cases around simulation/testing different network topologies where you want to simulate and control thousands of nodes easily.
I'm still sort of adjusting to it. I haven't really changed my lifestyle at all. I drive a minivan (no lambo here) and live in a modest house. At this point I can't really think of any real downsides.
I guess there's some new 'problems' of how to manage the money so you don't lose it. Luckily we have bitcoin for that ;)
Best way to go from idea to product would be to try to come up with a way to cheaply test your idea. It could be as simple as setting up a type-form or some other way to survey your potential customer base to find out if they'd pay for whatever product you have in mind.
I got my first customers the old fashioned way by picking up the phone and calling them. Since we initially were focused on merchants accepting bitcoin (bitpay was mainly only option back then) we were able to find a list of bitpay merchants and looked up their contact information on their website.
After talking to enough of them we learned they didn't really want the initial product but we did learn a ton about what they wanted. We collected and reflected on all the feedback and we were able to steer the product in a direction that some of those initial phone calls turned into our initial customers.
I don't love price predictions but my conservative estimate would be for $500K by 2050. I think at a minimum it replaces the market for gold as sov.