This :

Litecoin MWEB Security Incident Postmortem

is another example of the problem with obfuscation at the L1 blockchain layer. The Zcash incident from years ago was a more obvious one, this one is more subtle. The problem here actually manifested in mining and checking the validity of a peg-out from the mimblewimble extension block. So the bug itself was not cryptographic, it was a consensus bug. But the privacy feature (the obfuscation) made it a lot harder for the system to react to the failure mode. And they still have the unauditability problem, even now, I think.

Some pretty meaty Joinmarket anonymity set analysis here from @m0wer :

JoinMarket Maker Clustering and Taker Anonymity-Set Reduction

Haven't gone through it yet myself.

A new (or better, semi-new) idea: 'hodlchain' : if people timelock their coins, they're sacrificing value. that can be used to permissionlessly mint coins on an "L2". Semi-new because this is exactly Somsen's old spacechains idea, except, I think it's way more interesting if you don't *have* to burn your bitcoin (though, you can) to get the value. The meat of this was trying to find the logical way to modulate how much L2 coin can be minted by e.g. locking your bitcoin up for 1 month. There's also a POC code referenced, but it's vibe-coded; fun to play with but just a very basic illustration. I called it 'hodlchain' because it amusingly answers the question of whether hodling is using. You're provably removing selling pressure from other bitcoiners *and* getting additional value in spendable L2 tokens -without selling your btc! 😄 https://github.com/AdamISZ/hodlchain-paper/blob/master/hodlchainv1.pdf

Honestly a really interesting argument going on in this thread. View quoted note →

Am I right that we still don't know how the FBI got hold of the 127000 btc from the Prince Group (while they failed to extradite the guy, ofc, the CCP grabbed him)? Same story for the 63(?) Btc from the Colonial pipeline ransomware from a few years back. I guess it's about hacking, but if it's anything else, that could be interesting.

Citrea, which has been live on mainnet since January, uses basically the entire BitVM stack to create ~ trustless proof of a valid withdrawal.

IACR Cryptology ePrint Archive

Clementine: A Collateral-Efficient, Trust-Minimized, and Scalable Bitcoin Bridge

This whitepaper introduces Clementine, a secure, collateral-efficient, trust-minimized, and scalable Bitcoin bridge based on BitVM2 that enables wi...

But then it also lets N of N signers just sign off an exit unconditionally?. Section 8 of their Clementine bridge protocol paper: "Optimistic Payout. The protocol we described above guarantees that any peg out is completed even if all Signers are offline and all but one are malicious. However, if all Signers are honest and online, they have some time (in Clementine, it is ≃ 1 hour) to sign an issue a user’s peg out by posting an OptimisticPayout transaction. This transaction resembles the Payout transaction, with only two differences: (i) it spends the output of the MoveToVault transaction, so that the funds given to the user do not come from the Operator, and (ii) there is no OP RETURN output. If no OptimisticPayout transaction appears on-chain within some time, the peg out request is picked up by the Operator and the Clementine continue as described in Section 5. To enable the optimistic payout, Signers must not erase their keys, making the protocol secure against a non-adaptive adversary." I've spent the last half hour trying to find any discussion of this. It looks like a very bizarre decision as it seems to throw away most advantages over multisig federation control. Notice how the signing keys have to remain essentially hot.

Archiving joinmarket-clientserver ; see "final" (almost certainly) release:

GitHub

Release Final release of joinmarket-clientserver · JoinMarket-Org/joinmarket-clientserver

Please read the release notes at https://github.com/JoinMarket-Org/joinmarket-clientserver/blob/master/docs/release-notes/release-notes-0.9.12.md f...

. A couple of years back I pulled away from doing anything more on the project, hoping that it would kind of "organically" continue somehow or other, but activity was a lot less than expected (though it was actually maintained, we weren't producing releases etc. ) .. but i was also kind of vaguely "expecting" that some people might fork and/or rewrite, as rewriting could make a lot of sense; more recently, m0wer has actually done that; see

GitHub

GitHub - joinmarket-ng/joinmarket-ng: JoinMarket (Bitcoin CoinJoin) modern alternative implementation

JoinMarket (Bitcoin CoinJoin) modern alternative implementation - joinmarket-ng/joinmarket-ng

; as per notes, I can't literally "recommend", not without an absolute ton of work, and even then, it's only my opinion which isn't much. But what review I *have* done has been positive. The most interesting part is finding anti-DOS and anti-fingerprinting solutions that are practical; it's very difficult, but interesting work, so if anyone is interested, I'd recommend heading over to that repo.

To @Jameson Lopp and @Matt Corallo and other people that are advocating for coin freezing as a possibility: the responses in this thread I think provide a really useful window on the user level perspective. It seems like more than half of the responses to this Arbitrum tweet are saying "shucks, I guess we only have bitcoin to rely on not to freeze funds", e.g. a typical response is "Cash under your mattress and bitcoin are the only truly decentralized things" or the most apposite: "Well, bitcoin has no "security council" .. and I'm happy for it". But if you keep reading the replies you'll eventually find one that says "even in bitcoin they talk about freezing funds for whatever reason. Only left is monero then?"

X (formerly Twitter)

Arbitrum (@arbitrum) on X

The Arbitrum Security Council has taken emergency action to freeze the 30,766 ETH being held in the address on Arbitrum One that is connected to th...

I know that a decentralized system can't depend on goodwill, and everyone is always free to propose whatever the hell they want, but what things like bip361 are proposing is "let's completely destroy bitcoin" - because you're proposing replacing it with something that has a "security council". Users of bitcoin absolutely don't want that thing as the thread above illustrates, it's *the only thing that makes bitcoin valuable*. I honestly think even the discussion so far, because it has included a lot of influential devs (and not just a lot of suits who we are used to ignoring) has already damaged bitcoin's value (sorry don't mean to sound histrionic, lol, but I really do; it's a new threat vector that some of bitcoin's devs are proposing to destroy it!).

Glad to see a large number of people expressing themselves over the suggestion of freezing coins. It will not work; a Bitcoin in which that happens is basically worthless. I mean that both functionally and monetarily. Because the main thing that makes Bitcoin distinct from all the other coins is that it has no rulers. Users and eventually hash power will leave and go elsewhere if it proves to have rulers. And no it does not have rulers today because soft forks have somehow got activated, occasionally. In a decade there have been 4, iirc, and *crucially none of them impacted any user's existing property rights*. Just giving you more options, not 'rulers'. Still it's appropriately nearly impossible to make such changes. While contrary to the false statement in BIP361 about 'supply changes', there is no certainty about what happens if someone gets access to those old keys. It could be a big clusterfuck, or not, but at least it won't kill the project if a viable PQ alternative exists by then.