Oh, actually here's another example from the same LN node, in the same F2Pool block: https://mempool.space/tx/ad21f74d694a0aeffdba2da50d9d18a4b636c100e2d4003f24cc36dcf9a9556c
...and we have _another_ example of this type of pinning from a totally different Lightning node: https://mempool.space/tx/4f6ed6c3fe25571b883a631503ab84cccef450b96d8c9065c712246758e15e6b
Real world example of transaction pinning affecting someone's Lightning node that was fixed earlier today by replace-by-fee-rate (via Libre Relay).
Full write-up: https://groups.google.com/g/bitcoindev/c/n2GNmnz0btw/m/IemUVKBoAgAJ
Oh, actually here's another example from the same LN node, in the same F2Pool block: https://mempool.space/tx/ad21f74d694a0aeffdba2da50d9d18a4b636c100e2d4003f24cc36dcf9a9556c
Real world example of transaction pinning affecting someone's Lightning node that was fixed earlier today by replace-by-fee-rate (via Libre Relay).
Full write-up: https://groups.google.com/g/bitcoindev/c/n2GNmnz0btw/m/IemUVKBoAgAJ
Good read.
Notably, while it's often reported that Ashton Kutcher is behind chat control, usually articles give the impression that Kutcher's involvement is some kind of charitable cause.
It's not. He's an investor in chat control scanning tech, and stands to make plenty of money by making it mandatory.
Fucking psychopath.
Gee, why would they need to do that?
I thought chat control scanning would only violate the privacy of child abusers...
12V is harmless to you. It is not harmless to whatever metallic thing you accidentally short it across... and the resulting shower of sparks and molten metal is certainly not harmless to you...
Nope. Voltage kills, not current. Specifically, _energy_ kills, and without voltage not enough current will flow though you to deposit enough energy to be harmful.
https://youtube.com/shorts/_nZeIdTlaHI
Interesting farming tech.
Surprisingly cash-positive language! Seems like a pretty recent initiative.
https://atm.bancontact.cash/nl/bancontact-cash-brussel-anspach-the-mint-2481
OTOH, sometimes people change their minds.
Depends on what you are trying to do, and if and how you want the protocol to evolve in the future.
Update: sure enough F2Pool eventually mined my higher fee-rate, lower fee, double spend.
This is a great example of why the “free relay" objections to replace-by-fee-rate don't make sense: mempools aren't a consensus. So RBFR double spends get mined eventually anyway.
Heh, I actually just ran into transaction pinning in real life: so LND v0.18 has a new sweeper scheme, that, long story short, is trying to "sweep" both nearly worthless anchor outputs, and valuable outputs, from some LN channels I closed in the same transaction.
The anchor outputs are past their 16 block timeout, so someone else is trying to sweep them in a huge 3sat/vB transaction paying ~60,000 in fees. Far more than I can afford! But still a low fee-rate.
On my replace-by-fee-rate nodes the sweep will eventually succeed once LND picks a high enough fee rate (it repeatedly RBFs the sweeps). It might even get mined, either on a pool like F2Pool with short mempool expiration, or in the near future when turns on RBFR like they told me they would Soon™.
Our current generation of compilers and languages has a really serious limitation with regard to critical code like the Bitcoin Core consensus: you can't ask a compiler to compute the maximum possible stack size used during a function call.
This is easy for compilers to implement because the call graph is known. Obviously, in some cases such as recursive or external calls the answer is infinite, or unknown. But making it possible to compute this in advance would be a significant improvement on the status quo, where you simply have to do testing, and hope it works.
It's quite possible that the government is alleging he had money that he did not based on faulty (chain) surveillance, or outright fraud on the part of the prosecutors.
There's a reason these are just allegations.
As for measurement of % chance of confirmation, I think that should track very well with feerate compared to the rest of the mempool. This stuff doesn't have to be perfect. Just good enough.
Another way to do that, with a potentially simpler implementation, would be to allow replace-by-fee-rate after some timeout. Eg after # blocks have been mined with the tx remaining in your mempool.
I'm talking about Phoenix, but actually it's not RBF but alternative fee rates that I was thinking of:
https://github.com/ACINQ/lightning-kmp/pull/553
No one uses the old mobile Eclair.
Oh nice! That's basically what I was proposing. A more limited version of it. But it is the same idea.
Nice to see someone implemented it!
To be clear, is the current Phoenix wallet also using RBF? Or just the older Eclair wallet?
Re: uncooperative close, not exactly sure what you mean there, as both sides can do a uncooperative close.