Our great sponsors
-
-
SurveyJS
Open-Source JSON Form Builder to Create Dynamic Forms Right in Your App. With SurveyJS form UI libraries, you can build and style forms in a fully-integrated drag & drop form builder, render them in your JS app, and store form submission data in any backend, inc. PHP, ASP.NET Core, and Node.js.
-
-
-
WorkOS
The modern identity platform for B2B SaaS. The APIs are flexible and easy-to-use, supporting authentication, user identity, and complex enterprise features like SSO and SCIM provisioning.
As proven by /u/loladam's work here, there are currently already ways to do that. Without a tx malleability fix, meaning Dogecoin as it is today, this means that we can create secure consumer-to-merchant payment channels but not yet p2p-routed payment channels like what lightning does, or at least not without it being clunky and custom. The difference between that and Lightning is that today, you could be a registered customer of "HotDoge, Inc" with a specific payment channel that locks some of your DOGE (under your control, but not usable for different purposes for an agreed-upon time) and get sub-second payment clearing as long as you pre-fund the locked channel.
I think that once I'm done writing the a proposal to deal with the EU stuff (I really hope to be done with that tomorrow - I'd pull out my hair from all this legal text if I had any 😂) I'll have to spend some time on the malleability issue and maybe write up an impact analysis of the suggested directions from the 1.21 consensus plan. That would also help explaining why we cannot have lightning right now and why it'll take some time to enable the Dogecoin chain for it.
Yesterday we agreed in the group meeting that I'd improve this doc so I did that and it was merged. I'll work a bit with /u/xanimo-net on the merchant-side prototype this week, to get that out of the way so that everyone can focus on integration. Once that's done, we'll design and propose some standards to the community, so that this can be implemented by everyone.
For the above payment channel protocol, it is already standardized on PSBT and for the invoice part I am hoping to be able to either use BOLT-11 (Lightning's invoice standard) or something that resembles it as close as possible.
For the above payment channel protocol, it is already standardized on PSBT and for the invoice part I am hoping to be able to either use BOLT-11 (Lightning's invoice standard) or something that resembles it as close as possible.
Related posts
- Is there any Bitcoin layer (eg. Bitcoin = L1, Lightning = L2, etc.) on which the satoshi (SAT) is divisible?
- Does Lightning Network have its own hard forks?
- What's LNURL and BOLT12?
- Safe Lightning Transactions Without The Need for Watch Towers or Continuous Network Connectivity
- Why don't use the intermediaries' public key directly to encrypt the onion packets?