pull down to refresh

@TonyGiorgio's post of a few weeks ago is getting tons of traction on nostr. I think we all should consider subscribing to Mutiny +.

Keep in mind that I know I'm getting in over my head here technically, but are these reposts focusing on the blind signature aspects while ignoring the fedimint connection? They seem inseparable. Will this restart the whole argument of whether fedimint integration is custodial?
On another topic, this seems like a good solution for Stacker News zaps, no?

reply
Keep in mind that I know I'm getting in over my head here technically

That's the point, it's theater to mislead the non-technical into thinking there are better trust assumptions than just calling it a database

There's no way around the fact that servicing of the Lightning Address is still done with a web server, which is inherently single-party trusted to serve the invoice expected

Buzzwords to misrepresent trust assumptions is a sad trend in Lightning, wrote about this specific nomenclature recently: #517245

Even SN has fallen into this trend with the new wallet connections via wrapped invoices, in the blind hope that they're sufficient to scam the regulator: #534360

Now, a successor to LNURL that actually validates signatures from the source could solve much of this, but that would require Lightning entrepreneurs to be honest about their current mitigations

reply

I see your point, but I don't think it's an attempt to mislead. This is an accurate description, no?

Under a setup like this, neither the lightning node gateway nor the Hermes server can redeem any ecash locked to the user's pubkey. It also happens instantly without a hodl invoice locking up funds across the network. It still requires the Hermes server to set up the contract correctly, but otherwise, it is not involved in the lightning flow of funds. It doesn't require us to have a node or any liquidity. Users can use whatever federation they want and change federations anytime, further decentralizing the whole process.

Also, SN has certainly been open about it's obvious custodial character.

BTW, what do you see as the prospects for this?

a successor to LNURL that actually validates signatures from the source could solve much of this,
reply

Parsing it carefully we can see the intent

neither the lightning node gateway nor the Hermes server can redeem any ecash locked to the user's pubkey

This is misleading by false-contrast. This statement serves only to distinguish this system from a conventional custodial Lightning address, even though the trust assumptions are exactly the same.

It still requires the Hermes server to set up the contract correctly

"Contract" is used here to imply atomicity, which coincidentally is SN's plan to scam the regulator

otherwise, it is not involved in the lightning flow of funds

At this point the flow of funds already happened, to the custodian, they're shroedinger's funds- rugged or unrugged.

It doesn't require us to have a node or any liquidity

Sounds like magic when you put it that way, but the same is true of Wallet of Satoshi

further decentralizing the whole process

Wallet of Satoshi is decentralized too because you can simply use someone else to take delivery of your sats

reply

Please take this as an honest question. Where do you stand regarding a solution? Is this leading to a small v big block dispute?
If so, I personally am more worried about small, affordable nodes than complete trustlessness on L2. When you say things like

which coincidentally is SN's plan to scam the regulator

You lose me, mainly because I see the regulator here as doing the scamming, with SN as the victim.

reply

Solution to which problem exactly? Scaling?

I think most people will use Bitcoin in a trusted way and that most scaling advocates are lying to themselves by trying to scale to nowhere. Unfortunately, I also think we're near a self-custody maximum. Not for technical reasons, fees are near 0 still, it's just because its only an intransigent minority that will ever care about trustless-ness.

I see the regulator here as doing the scamming

I agree, I don't use scamming the regulator as a pejorative- it was either @giacomozucco or @supertestnet that used this term in a conversation recently about how Tether used being a shitcoin to scam the regulator as opposed to just calling itself a bank (to great success honestly)

Wrapped invoices, ecash, federations, blah blah blah... are all similar to Tether, using buzzwords to obfuscate the trust point.

It's when scamming the regulator turns into scamming the user, by implying trustless-ness, that's where I have a problem. That's becoming pervasive. At least Tether never pretended to have better trust trade-offs.

Also, SN has certainly been open about it's obvious custodial character.
BTW, what do you see as the prospects for this?

Missed these above...

SN is pivoting though to non-custodial, which is fine and understandable, but I had to correct that post saying it would use a trust-less wrapped-invoice mechanism to achieve this... it won't be trustless. Therefore, it's also not a direct benefit to the user, just more friction and less reliability in the name of custodial deniability.

I've been transparent in shilling my project that endeavors to succeed LNURL by using Nostr, as Nostr inherently uses signatures for any data transacted so that the invoice delivery does not have to be trusted.

Building actually trustless products that create new and permission-less means producing income streams online is the only hope of breaking through that self-custody maximum. It's one thing to trust pocket change, it's another to trust an income stream.

Using Nostr to obviate the networking challenges of node running shifts the juice to squeeze ratio in the node-runners favor, that's what we should be doing... not these weak obfuscation schemes that will age like milk.

reply

Thanks very much for your response. Now I have a much better idea of where you're coming from, and your proposed solutions. I am definitely going to check out your project.

reply

The blind authentication has nothing to do with fedimint except that they both utilize blind signatures.

The first blinded service we offer is lightning address registration. Which we just happen to also be using fedimint for.

reply

I see. Just got my address. I'm excited.

reply

Appreciate the support! Let me know if you have any further questions about how this works.

reply

Will do.

reply

Not sure why this in particular is resurfacing. The actual article itself just recently dropped: https://blog.mutinywallet.com/blinded-authentication/

reply

Maybe because it's less technical and more understandable for the typical user?

reply