Local automation is already an available service through CLBOSS and LNDg. However, making good decisions about whom to connect to is stymied by only using data local to the node. This optimization problem is a better fit to centralized processing as we see with Waze/google/Amazon.

The only Hydro setting that requires data is inbound liquidity targets. Setting target inbound liquidity automations requires attesting to the current inbound liquidity, but it's just an attestation.

No subscription is required to post an offer on Magma; anyone that runs a node can use the service.

No "doxxing" is needed; you simply have to prove node ownership by digitally signing a message.

We implemented a big change and are keen to hear feedback! The fee for Hydro is now down to 0.2% which flipped the business model to make Hydro liquidity automation a more cost effective option.

This is a lot of FUD to unpack!

We aren't creating fake orders on Magma; it pays out Bitcoin to sellers and that's simply not something we can afford as a small startup.

Hydro does not require sharing any channel information; it's simply a liquidity automation service for sovereign node operators. It could have just been called Auto Magma. The automation works best when there's liquidity information to inform channel opens, but that's optional and a conscious user choice.

Our ML research is used to inform better pathfinding and higher performance for lightning, just like giving better driving directions by using traffic data. Our predictions are not useful for exposing anything that is private; it's simply a more scalable tech than probing, which is invasive and damaging to network performance.

Identifying the payer of an invoice is nearly impossible in lightning unless the payer reveals that fact themselves.

Anyone with access to the lightning address or invoice is able to see this information, including the payer or the payee (they are usually the ones that made it after all, except for Ghost Addresses).

We'd love to help a wallet add these features. Be sure to let them know this is a feature you want!

Thanks! This stuff is fascinating ⚡

The computation and retraining is not intensive at this size of the network graph. As the network graph increases in size, the improvements in payment reliability offered by this type of calculation should increase versus anarchistic, source-based routing.

We're testing both zeroed-out mission control and a learned mission control.

Apriori is decidedly difficult to benchmark against!

Our benchmark testing is ongoing and the initial results are extremely promising vs off the shelf LND.

In a dynamic graph like Lightning, the need for advanced computation is even greater.

You can exclusively use someone else's UTXOs by buying channels from Magma or set it to auto-buy with Hydro.

This was an extremely helpful recap! Thanks for your work to keep us apprised.

We are all Satoshi Money Transmitters

No, if, as the destination of the payment, your node data gets seized, the channel you received a payment through is now known. To back-trace the payment, an investigator would need to contact the immediate prior hop. If they refuse an unwarranted search (likely case), the investigator would need to contact each of the prior hop's channels, say 30 channels.

Each lightning payment can reliably take 4 hops, so that's 13030*30 = 2700 people to interrogate if they refuse unwarranted search.

You can decrease onchain exposure by not opening any channels yourself. Instead, by purchasing channels, you use someone else's UTXO. You can buy channels with Magma or Hydro.

The number of channels that you have makes it exponentially more difficult (or infeasible) to trace the origin of a payment, even if a node lists their contact information. Cryptography is about asymmetric work and tracing a lightning payment is an extremely heavy lift.

That's beyond our ability to monitor; we primarily deal with analyzing already public data.

Reflex is a product that is only for businesses so it needed a separate site for landing, marketing materials, and future development.

Amboss space is consumer focused but we built Reflex as a subsection of Amboss to preserve the account infrastructure we created as part of Amboss.

Reflex doesn't require operating a node, but amboss space does.