But, but go for it.

Yeah, and this is the, this is the pro and con of Silent Payments.

Just like everything in Bitcoin, it, everything in life, there are trade-offs.

So in Silent Payments, when a sender wants to pay a receiver, they enter the Silent Payment address, they go to send the transaction, they send it.

Looks simple.

On-chain, it just looks like a regular taproot output.

There's nothing that reveals that it was a Silent Payment payment, much less that it was between a specific two entities or anything like that.

Heartbreaking

Uh, it's been a very busy month in software development in general.

You mention it right at the tail end.

Something huge that shifted here is you s- you've always been able to get audits.

You've always been able to get very smart people to look at your code and validate that it's working properly, and that has been the normal path.

The problem is that takes weeks to months quite often, if not longer.

You often have to wait for a while until whatever the, the auditor's queue is currently filled with is empty.

They can get people on it.

You've massively accelerated where maybe I am off calling an API to Anthropic or OpenAI, it's all local for you.

Makes sense

... and then you're only doing coin swaps with post mixed funds, and you can guarantee that the other person is also only using post mixed funds so that you're getting a, a good, uh, untainted Bitcoin back, that would work, but it, it just has a lot of downsides.

Payjoin is much simpler.

So Payjoin is basically just if both wallets support it and if the receiver already has Bitcoin, when I go to pay you, I don't do anything different.

As a receiver, you don't do anything different.

In the QR code that you give me or in the, the URI that you give me, there will just be a, a Payjoin endpoint that I can use.

And when I go to pay you, you as the receiver actually contribute inputs as well.

Yep.

You don't see the CPU as being the ASIC of Monero?

No, that is how I view it and how I describe it.

I think the caveat for me is that I think ASIC resistance is the right choice today, but it has a lot of downsides compared to being ASIC-mind if you can ensure that they're broadly available.

and widely distributed the problem is like bitcoin had this bitcoiners misuse this term but this immaculate conception in the sense that they got to go through this progression of cpu mining gpu mining fpga mining asic mining in a slow controlled ramp because it was the first time any of that had ever happened No other cryptocurrency gets to do that slow controlled ramp.

Like we, there are some things we could do with algorithms to try to force a slow ramp where we could have a transition period where we slowly increase the amount of blocks that can be mined by this GPU algorithm.

And then we slowly increase the amount can be mined by this ASIC algorithm.

Uh, it's been tried before, uh, I should do a deep dive on how effective that actually ended up being.

What do you think about it? Is that like, do you think it's a real issue? Is that something that they're doing significantly better than we are? Is that something that narrow needs to do better?

That's

Yeah, I was just going to say, it's becoming much more normal because that demand for privacy is not just a personal thing as well.

The primary driver for privacy at scale with the AI space is enterprises.

I mean, if you're a business... who are dealing with sensitive internal data all the time, you don't want to be dumping all of that into Cloud or to ChatGPT.

There are huge, huge potential issues with you touching anything like that.

If you're dealing with customer data, if you're dealing with HIPAA-specific data, all of these specific use cases for AI at scale, You need those.

So it's already something to me like this is not a new technology.

yeah i mean you mentioned stablecoin integration on the room roadmap for for radar what what else in your mind do you think would be a good feature like how how far do you guys want to push it

Why build a Bitcoin messenger now?

Yeah, absolutely excited to be back.

It's been a while.

I think our last chat was the fungibility talk that we did a few years ago.

But the why, honestly, behind Radar, I mean, we've been thinking about this for a while.

Initially just started as an idea of like, hey, we have some features in Signal that we want to improve and work on.

Let's just make an alternative client.

I'm curious, is that something you're looking at on the Cake Wallet side?

Yeah, I

mean, there's nothing like legally, there's nothing they can do to radar the company.

What they can do is they can try to block radar user agents when your app tries to connect to their servers to get messages, to get contacts, all of that fun stuff.

That is something that they can definitely do.

So it's not as much asking permission as much as like they shouldn't block that as long as we're not doing something malicious.

But they have in the past, right? They have, but only in the long term past.

More when Moxie was there and he was very anti-alternate client and the most popular alt client for the past at least five years.

What is the thought process there? How are you guys thinking about that?