TL;DR: it's basically phoenixd but you don't even have to run phoenixd on a server alongside your actual app (say, a store or a blog). Instead, your LN node runs on-demand inside your Nextjs app, on the backend.

Your node is connected to one of MDK's always-on nodes, which provides inbound liquidity and "wakes up" your node when a payment is incoming.

Received payments stack up on your side of the channel. You can then decide to transfer them to another node (via LN Address or Bolt12) from your MDK account, on MDK's website. The MDK infrastructure then issues a request to your MDK node, which only pays if the LN Address/Bolt12 matches one that you provided during the initial config. This ensures this setup is actually self-custodial, since payments can only be sent to whitelisted destinations. You can also, of course, recover on-chain with the seed phrase and some (yet unreleased?) recovery tool that should basically tell the MDK remote node to force close the channel.

I think a cool thing to add for merchants would be on-chain payouts (ie. withdrawing from your "serverless" node to an on-chain address). For example with splicing and by specifying a xpub during the initial configuration.

This is just a crappy article from a crappy mainstream media.

Now, France is definitely not the best place in the world for privacy-minded fellas. AFAIK, we're one of the last remaining western countries to have laws governing the import/supply of cryptographic tools¹ (basically, you have to declare it to the French cyber authority). We have a law that defines a presumption of guilt when the way money is handled "can only be justified by an attempt to conceal the origin of funds"², which now includes the use of privacy techniques in the context of crypto-currencies.

So yes, this police fella saying that "when this system is present on a mobile phone, it is a clear indicator of technical sophistication and an intent to conceal" is very concerning. But it's mostly that:

Braiiiiiiiins

Got the story wrong then haha

Wonderful photographs!

I love how the F250 one is telling a story: "heavy duty" vehicle but grass has started to grow around it, so maybe now it's retired?

Thanks again for chiming in @justin_shocknet! And thanks for posting the replay here (and the zaps forward ⚡️)

I guess because they'll need to also charge the cost of Claude.

The timeline is off: says disclosure on June 16th, and yet we're only the 12th.

Thanks for you kind words @DarthCoin :blush:

In that case I don't think they're anchor outputs. The 330 sats for anchors comes from the fact that it's the dust limit for this kind of output (i.e. the smallest standard amount). Here, they use the same amount to ensure standardness of their transaction, but from the look of it I'd wager they're encoding arbitrary data into the addresses (thus making the output unspendable).

Glad I could help!

Generally speaking adding a hop between a KYC exchange and your main wallet isn't going to do much privacy-wise. If you do exchange ---> temporary wallet ---> main wallet, then any surveillance company with knowledge that the funds sent to the temporary wallet belong to you will be able to infer that those sent to the main wallet also do, especially if the transaction from the temporary wallet to the main wallet is trivial to interpret¹.

Additionally coin control, however sophisticated, will never alleviate the fact that the KYC exchange holds a record of how much corn you bought. For instance, if your worry re. KYC is expropriation a la 6102, then the State would still know that you own at least the amount reported by KYC exchanges, and could come take it.

I think a common practice is to keep KYC and non-KYC stacks hermetically separated. It has the added benefit that KYC coins might be useful in the future, e.g. for any transaction that requires proof of origin (such as buying a house).

I think in most cases the best way to go around this is to use separate accounts (e.g. different derivation paths). Sparrow lets you do that pretty easily.

If open your current wallet and head to the "Settings" tab, you'll probably see under the Keystores section that your derivation path is something like m/84'/0'/0' (could also be something else depending on your setup). Using the same seed (eg the same hardware wallet, if you're using one) you should be able to create a new wallet, and specify a different derivation path (eg m/84'/0'/1'). You can give it a clear name (like "KYC wallet") for future reference.

You now have 2 different accounts, backed by the same seed, but from which you cannot accidentally spend in the same transaction.

Those are stunning!

Haha I was not ready for AMSR Alan Bits 😂

Hey @DarthCoin, thanks for sharing this!

Today will be an introduction to Lnbits core concepts, and we'll play a bit with the public v1 instance.

Haha I thought it was yet another vulnerability disclosure, but not this time!

I love the pairs of nodes in the fringes having their own bromance.

Interesting, thanks for pointing it out! It's a clever way to take the fee, although it has the drawback of not being atomic. But then if a merchant blocks the payment of the fee to Flash, they can terminate this merchant's account, and they can no longer use the service.

IIRC LNBits circumvented this by intercepting invoices before handing them to LND, and processing "to-self" invoices separately as database-only transfers. But it would indeed be nice if LND had it baked in, instead of everybody that has a use case for it reimplementing the feature.

Okay, 3 things:

Cowboy hats off!

I guess it depends on how much actual mint-to-mint transactions there are. If there are a lot, then audits are hidden in the crowd. Else, what you describe is indeed possible.

And yes, Bolt12's receiver privacy probably fixes this 🫡