Classic misdirection by JP Morgan. Having worked on banking software at various points throughout the last 40 years I can attest that this isn't a "technical glitch" but a *business risk" decision where the bank decided to credit funds to the depositors account at time of deposit, rather than when the cheque cleared.

Was that a stupid decision in hindsight? Der, YEAH! Was it a technical glitch .. no .. it was a stupid decision and unscrupulous customers exploited it ruthlessly.

Of course, if we used bearer money (Bitcoin) rather than credit money (USD/Fiat), none of these issues would exist!

Onwards!

Thanks for giving this some visibility .. excited to have a play with this and delighted to see Silent Payments making their way into wallets

thanks for building this .. an important new channel of progress to explore in this important ecosystem .. given value in privacy that Tor itself seeks to deliver, subsequent use of eCash could also help here .. but underlying concept of incentivising relay runners should help both network breadth and speed

OpenSats volunteer here .. yes, this pretty much aligns with my views too.

Like most healthy organisations, it's seeking to improve too - both outcomes, transparency and internal processes that increase efficiency and effectiveness. Thankfully it's not the sole organisation like this - Brink and HRF are two other US examples - tax deductible non-profits that support open source developers and projects working on freedom, bitcoin, and nostr and related projects.

Creating more such organisations would be a one way to "decentralise" the function; similar organisations in different parts of the world under different jurisdictions would be a good example. One other way is to contribute some portion of your energy to directly helping the organisations you think are doing important work.

For example, say you're a big Sparrow wallet user, or Zeus or Mutiny (or whatever) .. one of the ways you can help those teams is by testing early versions of new releases and giving them feedback. The earlier bugs or feature-idiocy is squashed in the development cycle, the better .. and as an existing real-world user .. you are one example of how that product is really used. Dev teams really appreciate this work .. and work it is because when you're giving that feedback it's not just "Hey, this is broken" .. it's "So, in this test case where I was doing the following things/flow, I observed <X> happened and I'm pretty sure <Y> should be happening because ...<reason>".

If you're technical, you can join github and contribute code or documentation expertise; there's lots of ways to actively contribute in the open source space. But it's up to you. YOU have to act.

This is a good starting point: https://btcguide.github.io/

If you prefer to listen rather than read: https://stephanlivera.com/episode/215/

Whilst the signing devices on offer for multi-sig, and Sparrow as probably best-in-class bitcoin wallet, are all new since Michael Flaxman wrote (and recorded) this, the reasoning and comparatives of single sig v multi-sig are really useful to work through

Big benefits flow from this being rolled out now:

Some LN implementations WAY ahead of others in implementation and deployment, and given the potential impact of these, will have to be playing catch-up

Go check it out at https://bolt12.org/

He was on point.

Is the current politician-promise-to-deliver ratio above zero?

Liquid is a great tool that bitcoiners should try out - have it in your 'toolbox'.

A key differentiator for Liquid v Lightning, is that Liquid does not require online infrastructure whereas Lightning does. I use both, and as others have pointed out, boltz.exchange is great for atomic swaps between Liquid and Lightning. I don't think Lightning obsoletes Liquid, although the publicly discussed use case for Liquid (fast private liquidity between exchanges) appears now better handled by Lightning.

As Bitcoin grows, the use cases evolve and change, and so do the tools that deliver against them. boltz.exchange is a good example. So, my advice is run it, use it, understand it, and then you've got the skills to use it if/when you need it .. or the understanding to say: not for me.

Great write-up and equally keen to continue playing with this as it evolves and see where it goes. Certainly the pace of development and change is astounding.

I value the privacy and the interoperability and that it requires no L1 softfork of any kind.

The three key points I'm thinking about at the moment with eCash:

Potential mitigations Part of the way to mitigate these risks, to varying extents, is to consider operating mints with a defined lifespan, and in the absence of action, to provide an address/invoice/eCash mint where your eCash is redeemed on shutdown. This forces the mint operator to deliver on the tokens issued, and validates for all users, that the sats are (were) there. A final fail-fallback in that circumstance (eg: provided LN URL no longer exists) could be to send to bitcoin charitable entities like OpenSats, Brink, HRF etc

+1 on the importance of team-fit

Also curious on this one.

America is about 4% of the world's population and USD is the current global settlement rails for (the vast majority of) international trade. That trade isn't just Australia selling oil to Asia, but it's people buying 'stuff' off Amazon and having it shipped to them. So money, state control/issuance, and international activity all become entwined.

Doesn't explain why the US seems to have some extra-judicial authority to slap non-US citizens. Suspect there would have to be legal instruments contained within extradition treaties established as part of diplomatic relations with the US.

Great framing of the difference Jimmy <3

Looks like that page that link connects to has been .. removed

Thanks for sharing!

Very similar to my journey but without the liquidity levels since I came to bitcoin much later on. Ran a node since late 2018 and was once in the top-100 .. and like you, got burned by the hot-mess that is LND.

I'm about to fire up a new node and it will be on CLN, but my focus is now quite different.

In the beginning (like you I suspect), I was keen to support the network, add some liquidity, and learn and help others learn. My node quickly became a routing node. I was involved in starting Ring-of-Fire, which like PlebNet which followed it, helped accelerate liquidity, connections and education for plebs learning about lightning.

Now, as Darth identifies, we've got some large exceptionally liquid and well connected nodes, and we've also got LSPs, both types need to be economically viable to survive - and we want them to do that. All I want to do is send and receive LN payments privately and I specifically do NOT want to route, so my thinking is:

Small node for private use 2-4 channels in total 2-10m sats/channel 1-2 channels with frens who run small reliable private nodes 1-2 channels with larger well-connected nodes Reliable redundant infrastructure Clearnet with a public proxy

I expect to continue to use Zeus as the mobile front-end to my own node - it's been great in the past - even on Tor .. which appears to be increasingly unreliable/attacked. Hoping that I'll be able to keep those channels open for years now. Small functional self-sovereign plebnode