This is hilarious. Top-notch security!

Thank you! Good to be back!

With this long break I figured it could make sense to restart the versioning. But it's a bit more wordy and ultimately people don't care that much, so maybe I should have stuck with #73.

I'd also like to have the number convey what week this issue is for to make it easier to find a specific week in archives, but once again it quickly becomes a bit wordy.

Thanks for your answer! VSS makes a lot of sense here, truly great stuff 🔥

Hey @nps! Congrats on the launch, I've been playing a bit with MDK in Vercel today and it's going great so far.

The only thing a bit confusing at first, at least to me, was the webhook. I wanted to test things locally first, but of course that didn't work because the node was not reachable on a public endpoint. Do you have any plans to simplify this first step, for example with a proxy between localhost and a temporary domain hosted by MDK?

Also am I correct in assuming that it's fine to run two instances at the same time with the same seed (one local, one deployment), since on payment reception the MDK infrastructure will just reach out to the deployed instance? But then how does the local instance knows the payment succeeded? I tried and it does notice the payment arrived.

Thanks!

Small update: we now have multiple news sources publishing on the subject, which all seem to stem from new directives issued by the interior minister to its services on how to handle devices running GrapheneOS (or, I assume, derivatives):

On the other side of the, we have balanced, nuanced articles from tech media:

John gave a nice presentation about this work at lightning++ (@btcplusplus LN edition) in Berlin last October. Sadly only the main stage videos are out right now, but hopefully the "talks stage" ones follow suit.

For future wanderers, the YouTube channel is: https://www.youtube.com/@btcplusplus

Seems to me there are a lot of "made in China" devices the CCP would leverage before turning to Bitcoin grinds.

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.