I feel like the indie hacking lifestyle doesn't really attract people who are at high risk for most other common causes of death at that age, in the same way that, say, raising venture capital seems to be an attractive option for people already at risk of suicide or drug overdose.
That’s exactly the opposite of why it’s an unrelated analogy (which was stated). People live days of their lives far more often than they check baggage. Death is not a once per year risk. The risk of losing luggage per day or per hour of traveling is much higher than the risk of dying per hour/day of living.
My point was a response to the statement that baggage checking happens more than once per year. Life also happens more than once per year, and in fact it happens more often than checking baggage, right?
It’s misleading to annualize these stats because the participation rates per hour and per day are very very different. This is why sports risk is usually calculated in participation hours and not annualized, to prevent such misleading comparisons.
It’s not a once per year risk, it’s an average. And you agree that changing the choice of time window for averaging will dramatically change the results, don’t you?
Unintentional injury (likely mostly car crashes?) seems to be the leading cause for all age group up to age 44. Then come suicide/homicide which only start declining in the ranks in your 40s, probably because other causes (cancer, heart conditions) start to take over.
I'm in my 40s and officially more likely to have my heart kill me, than myself.
it's possible to spot such transactions if they violate transaction forwarding rules (aka standardness rules) but not consensus rules. for example, a transaction greater than 100kB is not standard but still valid.
I've build a tool to detect differences between _my local_ mempool and what miners include in their block (there will always be slight differences). This is primarily intended to detect censorship, but can also detect transactions that never entered _my_ mempool.
Brilliant! I remember thinking about this problem a few years back: what stops miners of a blockchain just ignoring transactions/anything from certain entities. So it's good that there exists a way to track such behaviour, if it is occurring.
Economics. If miners consistently ignore certain transactions, there is space for new miners to enter the market and earn super-normal profit. After the next difficulty adjustment cycle, the old, censoring miners may be priced out.
Yes! Will be on umbrel eventually. Currently needs a Bitcoin Core build from the master branch. The features use should be in the upcoming release. Then Umbrel!
Yeah but wouldn’t it require some kind of fork of the BTC software (not chain) to actually include this transaction without sending it to everyone else?
Ok but is it really illegal? I doubt there’s a law on who can send who private BTC transactions? Or is it actually possible to mark this as laundering?
There's nothing illegal here. The goal of privacy is to avoid giving anyone a reason to suspect something. In the case of money laundering specifically, you want to turn money that looks extremely suspicious into money that doesn't look suspicious at all.
Little tiny 'gotchas' aren't going to save you from a determined investigator. They are trying to follow a trail of evidence so they can produce more evidence. What you need is a clean break, so that the investigator hits a dead end and has no productive leads they can follow.
Excited to see this new release. Seems to me this would (slightly?) negatively impact query performance for recent data (when the query concerns data is both in O3 and persisted zones), is that the case?
Query performance would be affected in so far as ingest jobs share the same thread pool as query jobs. As I am writing this I am also realising that perhaps we should have an option to separate these jobs... If we ignore resource usage and commit() latency, query performance would remain unaffected. Reader remains lockless largely unchanged code-wise. This was one of our major objectives to maintain data model as seen by the readers. I hope I'm making sense here?
Proof-of-stake coins lack one of proof-of-work coins most important properties: censorship resistance.
In both consensus systems, a censor is someone that has amassed 51% of the currently available stake (in PoW stake is mining machines, in PoS it is outstanding tokens).
In proof-of-work systems, a censor can be unseated by censored parties allocating more capital to mining machines until non-censoring parties own 51% of all machines.
In proof-of-stake systems, it is impossible to unseat a censor: since it owns 51% of tokens, it will also owns 51% of newly minted units in perpetuity (assuming it doesn't stop censoring and doesn't run into issues that would end up slashing some of their stake).
The math in this article makes it sound trivial for any major government to destroy bitcoin.
https://joekelly100.medium.com/how-to-kill-bitcoin-part-2-no...
It points out that "But we can spend more on hardware then they could." is false. Once it was outlawed, they can just seize the mining hardware.
So PoS may actually be more resistant. Instead of acquiring physical hardware governments would have to start acquiring the currency. If they have to purchase it, it will drive the price up. While they maybe able to seize it in this scenario as well, it would seem the virtual crypto world would have better protection than the physical world.
USDT-USD markets are indeed marginal. however, implied USDT price using BTC as a cross shows USDT is valued pretty much at parity with the dollar by the market:
Why not TSLA/gold? That proves there is inflation! Or I know, BTC/USD, that clearly proves there's lots inflation and look at that bitcoin price is perfectly correlated with it!
(I am only half-joking here, the point is that broad inflation is much much more important than some bull market in this or that asset class)
On a more serious note a lot of commodities are looking really bullish, including some foodstuffs, and that's obviously not good news ...
"miners somehowd eviate from the conventional wisdom or the norm, which dictates that transactions are prioritized for inclusion based on the fee-per-byte metric"
Miners prioritize by fee-per-byte, except that the on-chain fee only accounts for part of the fee paid for some transactions.
Over the years, many services have popped up where you can pay an out-of-band fee to a miner to include your transactions first.
Of course, this is detrimental to users not using these systems as it biases the algorithms used to determine what is the current best fee-per-byte to pay.
Hopefully proper implementation of CPFP (child-pays-for-parent) on the miners' side and in the wallets would bring fully decentralized solution to the problem. So you could simply "bump" your transaction by sending a child one that pays higher feerate for both itself and the parent. That would be more efficient since that fee would go to all miners, not just those with the deals with "accelerators". And no one in between to collect extra fee.
Why would people use one of them rather than increase the fee? Is it just for "forgot to do it, I'll pay extra now" situations, or is there a reason to do it anyway?
In some cases, increasing the fee once the transaction has been broadcast is not possible (original transaction doesn't use replace-by-fee OR child-pay-for-parent is not possible)
As someone replied I researched a similar service years ago to get a friend's transaction unstuck. Usually just a credit card payment and the tx id and they mine it.
Using a full node, you not only sync the history, but also validate it. In recent days, on a modern machine with a good internet connection, it takes less than 12hrs to achieve this.
If you don't care about validating the history, I guess using BigQuery would work but I don't know how to achieve it.
The real figure is more 2.1% (source: https://www.ssa.gov/oact/STATS/table4c6.html)