rodarmor

Very compelling and thoughtfully written article. Thank you!

There’s an easy solution: Bruce should place large bets on the prediction markets right before publishing the relevant data. It is legal, ethical, and, for him, risk free.

I wish that Opera Omnia, also by Stephen Lavelle, got more attention. It is mind-blowing exploration of the idea of propaganda and revisionist history, which somehow also manages to be engaging and fun, with an incredibly unique core mechanic.

It would be hilarious if people wound up snorting or boofing their GLP-1s (≧▽≦)

The best example of managing expectations of all time is in the Time Zone Database documentation:

> The tz database predicts future timestamps, and current predictions will be incorrect after future governments change the rules.

General-purpose deduplication sounds good in theory but tends not to work out in practice. IPFS uses a rolling hash with variable-sized pieces, in an attempt to deduplicate data rysnc-style. However, in practice, it doesn't actually make a difference, and adds complexity for no reason.

This is stupid good advice. I use quicksilver as a launcher, and by putting bookmarks in a folder, I can index them and launch them like any other app or document on disk. Thanks for writing this up!

I definitely don't think Just will ever unseat Make. Just doesn't have file-based dependencies, so it's not a build system, just a command runner.

As far as unseating Make as a command runner, I think that might just take Just being available in more places, since one of the main advantages of Make that many users cite is that it's available everywhere. Just is already available in a lot of package repos, but not all of them. Finally packaging Just for Debian[0] would help a lot.

[0] https://github.com/casey/just/issues/429

This is the canonical video on the subject: https://www.youtube.com/watch?v=TmVMh-nT200

One time me and a friend having an animated conversation on the 7th floor of Soda hall at Berkeley and William Kahan came out and gave us a coupon for Sizzlers. I think that was his way of telling us to get the fuck out.

It's usually actually bread baking, not painting, in my experience.

Misread the title as "Which John von Neumann Died at Los Alamos?" and now I really want to read that article.

Don't let the article put you off, the paper, no paywall, is much better and much more concrete:

https://academic.oup.com/ajcn/advance-article/doi/10.1093/aj...

The fact that consumers don't want phones with 7 years of guaranteed updates (if they did, they would be willing to pay more for them, and smartphone makers would happily oblige) means that the impact on resale values would likely be small, or that consumers are unlikely to try to resell their phones.

If this law comes into effect, consumers will pay the increased cost of delivery of 7 years of software updates when they purchase new phones.

Smartphone makers don't sell new phones with a higher price tag and the guarantee of 7 years of software updates, likely because consumers would prefer a lower price and no guarantee.

Thus, the law would effectively force people to buy something that they don't want.

The post doesn't seem to offer any evidence for its claim.

Fortunately, if you're feeling entrepreneurial, you can spin up an Agora* instance and start selling whatever you want for Lightning Payments.

* https://github.com/agora-org/agora/

You bet!

These are definitely not dumb questions!

Liquidity management is one of the most complicated aspects of the Lightning Network, and certainly one of the most counter-intuitive.

The basic primitive that makes up the Lightning Network is a "channel". A channel is between two nodes, has a fixed capacity, is opened by making a on-chain Bitcoin transaction, and is closed by making an on-chain Bitcoin transaction.

While the channel is open, the two parties to the channel can make payments between themselves, but do not have to publish a Bitcoin transaction for each one of these payments. They only have to publish a Bitcoin transaction when they want to close the channel, which nets-out the intermediate transactions made since it was opened.

As a concrete example, let's say Alice and Bob open a channel, with Alice contributing 1 BTC when the channel is opened, and Bob contributing 0 BTC. Initially, their balances on the channel are:

    Alice: 1 BTC
    Bob: 0 BTC

In this state, Alice can send a 0.1 BTC payment to bob, and the channel balances will be:

    Alice: 0.9 BTC
    Bob: 0.1 BTC

Alice and Bob can send each other money, but only up to the amount that they have in the channel. So at this point, Alice can send Bob up to 0.9 BTC, and Bob can send Alice up to 0.1 BTC.

However, at the very beginning, when Bob's balance was 0 BTC, he could not have sent money to Alice. Due to a lack of inbound liquidity, which is, quite simply, money on the other side of a channel, which can be sent to you.

This is an aspect of the Lightning Network that is very different from other payment systems, and from on-chain Bitcoin payments. You must arrange to have sufficient inbound liquidity to receive payments.

You ask a good question: What if I just want to assume that the customer is good for the money and queue it up myself for settlement once I have the liquidity to spare?

Let's imagine that we were in the initial state, Alice had 1 BTC in the channel, Bob 0 BTC, and Alice let Bob make a payment to her of 1 BTC. The new balance would be:

    Alice: 2 BTC
    Bob: -1 BTC

However! When a Lightning Network channel is closed, you divide up the funds from the funding transaction between the parties to the channel. The channel was funded with an on-chain Bitcoin transaction of 1 BTC, so there would be no way to pay out Alice 2 BTC from that initial transaction. Since both parties to a payment channel can close the channel at any time, Alice would be trusting Bob to keep the channel open until he no longer had a negative balance, and avoiding the need for trust is the whole purpose of the Lightning Network in the first place, otherwise we could just trade unenforceable IOUs back and forth.

If you're using htlc.me, that's probably the issue. htlc.me is a testnet wallet, so it can only pay testnet invoices, and agora.download is on mainnet.

Just saw this now, but agora.download is on mainnnet, and test.agora.download is on testnet, so if you're using a testnet wallet, it won't be able to pay the mainnet invoices from agora.download.

Can you explain why it will be an issue for anyone who hosts it? The host determines what content is available. Agora does not yet support user uploads.

The possibility of losing funds exists, but bugs are something you would expect with any in-development technology. And, existing payment services are not without risk. Getting your account frozen and funds taken is pretty common with PayPal, Square, and other payment providers, which is not possible with the Lightning Network.

Definitely!

It's actually pretty easy to get into and out of Bitcoin. river.com, is a US-based service that allows buying and selling bitcoin with USD, making USD transfers to and from a linked bank account, and making and receiving Lightning Network payments.

So you could set up an LND instance, get inbound liquidity with a service like Bitrefill*, and then withdraw any funds via the Lightning Network to a River account, sell the proceeds for USD, and transfer them to your bank account.

I use River as an example because it's my favorite, but there are many other services that you could also use.

* It's slightly subtle aspect of the Lightning Network, but in order to receive funds, you need inbound liquidity, i.e. a channel with your Lightning Network node with funds on your counterparty's side of the channel. This can be accomplished buy buying inbound liquidity from a service like Bitrefill: https://www.bitrefill.com/buy/lightning-channel/

It's definitely challenging to set up an LND instance. I'll try to find a good one and link to it from our readme!

Ahh, not quite. I thought you were asking about a wallet for making payments, i.e. for buying content from Agora.

In order to process payments for your Agora instance, you would need to connect it to an LND instance that you ran yourself.

If you connected an Agora instance to an LND instance, you would have to trust the person who ran that instance, since they would be in control of funds from payments, so I think the best idea is to run your own LND instance.

We have tested it using real BTC, so far so good! LND is definitely still in beta, and the Lightning Network itself is still in its infancy, so it's a good idea not to have too much funds in an LND wallet.

We're try to be very careful when developing Agora, and all features are covered by unit and integration tests. However, bugs are always a possibility.

Thank you for the kind words!