Last Notes
I wrote that before the 15%.
The other two points are good. Especially the first one; since they could take anything, it's a particularly good point.
The third one is not as clear cut, but definitely to be considered.
Good qualifications but I don't see how it equates to "No". I trust myself to keep a private key safe for a short period. And giving it back wasn't hard either, as has been demonstrated now.
'Wrong' was oversimplified on my part, though I stand by it.
What I was thinking about more was the risk. Taking a big chunk (as apparently they now have done) unilaterally puts them firmly in the criminal category from a legal perspective. IANAL but I think they could have very reasonably and ethically argued that they did not steal, if they hadn't done that.. Now, they cannot. Of course if their opsec is tight, they may avoid the consequence, but that's another Q.
Yes, that's what's happening. They're finding a way to return that bitcoin safely to control of the 11/15 federation multisig (if they're honest). Which they could do immediately *if* the signatories didn't have infrastructure that automatically sends it out on any "valid" Liquid transaction that has a peg-out.
So yeah if Liquid is currently 100% shutdown then it'd be safe to send, even without a bugfix. Maybe that's your point.
I don't know if the blockchain is totally or partly shutdown right now.
Yes, people should definitely be spooked! Not saying "definitely the guy has good intentions ".
...But them saying 'I'll send *most* of it back' instead of negotiating a bounty separately, is wrong.
I mean technically you're 100% right. But you can still argue that swiping it the second you realize you can, is the more correct choice.
The "Whitehat? Bullshit, that's stealing" natural response isn't really justified.
If you see this bug and you don't want every user to lose their money, you are somewhat ethically bound to confiscate it until the devs release a fix.
You are thus making deployment of the fix 100x less dangerous (because the collateral is not exposed during the transition.
(Hot take? I don't think so?)
I should really show the follow up paragraph:
"While I'm not the King of Monero, I am frustrated my approval was given to a PR on a faulty premise. I'm trying to funnel this frustration into not having to worry about this anymore. Yes, serializing the entire TX is overkill. That's the point. It may be less efficient. This offers a 5x perf boost. I'd rather hear we left .1x on the table than hear we had a double spend in the next release."
I hope more developers of bitcoin security code don't feel bad about "overkill", either!
A comment by Luke Parker (guy who's the main author of FCMP stuff) struck me on a PR to introduce such a verification cache:
"We could just serialize key images, and fix that issue. I suggested in #8707. The problem is how it's been pointed out there's yet another field with this behavior. I don't want to play cat and mouse forever. The TX's entire networked value, and the mix ring (via do_serialize and as tested by @jeffro256 ) is complete. **Considering this code disables almost every single line of meaningful TX validation code**, I'm not willing to settle for less anymore."
(emphasis mine).
It's remarkable (if not surprising) that this comment exists in the Monero source, about caching the same kind of verification:
#nevent1q…rwly
https://blossom.primal.net/0fab5fc0fe7cb41e275cea0d129eae809be225e6e0aa33afe30f1895e4719c8d.jpg
Why the heck wouldn't they belt and suspenders with the transaction hash?
(They could also just not cache, full stop. Better choice for Liquid specifically imo, but easy to say in retrospect).
Yes, indeed. The pre-patch version didn't have length checks either, but it didn't matter with only (proof, commitment). A very well intended security patch that exposed a pre-existing flaw. Fucking hell software is hard!
I feel like the true root cause is this one: #nevent1q…0nvp
The reason I got convinced is that this theory matches the size of the "garbage proof".
it seems that the bug ultimately comes down to this line: "https://github.com/ElementsProject/elements/blob/c7e856fab1b0c4d37005e25c0940184d812a26a0/src/script/sigcache.cpp#L60 " . range proofs that hit the cache that is keyed to this hash, are counted as valid without checking. the problem is that the data fed into the hash is not length checked. so you can feed different (proof, commitment, asset) tuples into it by varying the length of the proof. the proof can be totally invalid and it'll still come back as valid. and this explains why OP_RETURN is involved: you need an extra output to sort of 'consume' the invalid amount. so you make a totally valid output of 4000 btc and you shove the negative corresponding value in the OP_RETURN. Apparently the anomalous size of the proof confirms this reading (bulletproofs rangeproofs have specific sizes based on the bit range 0..2^k). The only part I don't get is why there was a consensus deviation. Did some nodes have the rangeproof caching disabled or something?
So they were caching range proofs and it's a caching bug? Like in that they bypass verification of the rangeproof on a cache hit? That's what I'm seeing now. If so, that's... terrible?
This patch seems to be the fix: https://github.com/ElementsProject/elements/commit/c26d719c29a40da280a825b25657e9c3d8bc7d99
Yeah I'm seeing now it's not as simple as that! Which is a relief, but then again I haven't seen the right explanation yet, so I should hold off on that relief ...
I think GLM 5.2 might have found this. See Poelstra's response in this github thread: https://github.com/ElementsProject/elements/issues/1325 . What if someone created a transaction with an OP_RETURN that has a pedersen commitment that has some big negative value? If it gets included in the balance equation, that can work *only if* the range proof is not attached to that output.
See https://blockstream.info/liquid/tx/f24a4b179b5cc7e88b25a763911f7cbdf2bf45d1d1b5ab611e94461cef0a183f?expand - this is the transaction at which people are saying there's a consensus split.
#nevent1q…mlcr
Oh I am wrong, they do use bulletproofs now: https://docs.liquid.net/docs/confidential-transactions
https://x.com/i/status/2096696669287178696
Steven Roose (who used to work on Liquid) seems to think it's a confidential transactions bug. Seeing others tend towards that conclusion too.
Wow.
Notably they're still using original flavor CT not bulletproofs afaik.
They're already exceptionally good at hardcore cryptography i think. As of last few months, for sure. But it's less likely to be there. Just vague opinion, to be clear.
Iiuc there are some rules for automated signing by the HSMs? Maybe it's there somewhere?
Yes i was joking, but jokes should be a little closer to reality to be funny. Also this maybe isn't a great topic to joke about: *some* people, even if not nany, presumably lost money. Unless white hat is true , which I guess to be fair is a pretty decent chance.
Disclaimer: not necessarily effective 😆
This is genuinely crazy though. All the people telling you multisig is the right security solution, might give you pause ...
Only whitelisted addresses can peg out iirc.
Liquid rolling back the chain in 3.. 2...
Well sure, not only does that risk always exist but, for now, it’s actually worse with AI-powered attacks. It might actually get better, in future though, according to the above argument.
A little anti-doomer take for those of you (like me!) getting worried about AI. It's just a small niche but maybe the same thoughts could cross-apply to other areas of life:
I don't think it's very likely that AI will find classical breaks (as in, poly-time algos) to ECDLP. That's just an offhand intuition, but it's a very deep mathematical problem (factoring, also, though I guess that one is a bit safer). While at the same time, consider some of the big-picture problems - not hardness problems, but things we want to do, but can't - like functional encryption, indistinguishability obfuscation, fully homomorphic encryption, post-quantum analogs that don't have horrible tradeoffs, in cryptography. It's orders of magnitude more likely that AI will find *very* good solutions to those kind of problems. If they do, it will mean that things like Bitcoin become vastly more powerful, because vastly more useful. And the one thing that really underpins Bitcoin is not susceptible to some vast intelligence changing its character: energy scarcity. if you unlock a 10x on how much energy humanity has access to, obviously that changes a ton of things, but it doesn't change that energy is scarce. it's the finiteness that matters in proof of work, not the number. so short version: much *better* cryptography meaning much better bitcoin usability, is actually a pretty likely outcome.
Your 2nd Q: the ability to transact offchain in a system with extra features is massive: better privacy, speed, scale and trustless contracts like options and dexes. Not saying you just get that all easily, some of it's hard and some near impossible. To get that for bitcoin without sacrificing trust is a kind of holy grail. Lightning got a small part of that, with some tradeoffs, and it already massively changed the usability of bitcoin as money.
Exactly, they 'exist' as per, anyone can write and execute the code right now, but it isn't usable for existing LN. Just trying to counter the tendency to assume that that means you literally can't design a system using them; you can.
You can bet signet coins at https://thimbly.org .. implementation of babilonia . need to use a psbt supporting wallet for signing, works with Sparrow and Core and should be taproot. Though i guess you could do it non-taproot but you need the psbt co-signing feature. paper and code are linked at the top of the page. This is just for demonstration purposes, the better way of doing it is p2p via a Core node, though this is perhaps more fun :)
Why haven't people been working on arbitrarily complex contracts *inside* a Lightning channel?
Think BitVM but without the ugliness of what's needed to make dispute resolution work non-interactively onchain.
(Oh and btw we *do* have PTLC; anyone can deploy it in their own channel.)
It'd be kind of normal to be fixed size. Just like a signature has a fixed size, so does a zkp.
blockstream.info/signet lowest priority fee: 4277 sats/vb.
It's been drifting up. I guess something broke their end, I'm kind of curious what, though.
There's also plenty of precedent for government level reserves just getting swiped, especially by the USA (France historically, Russia more recently, though that was,USD), but also the UK (Venezuela case iirc).
Uh maybe it's not exactly the antipode of CSV exactly. There's nuance there. But setting that term aside, you get the point.
They want 100% recoverability for a wallet, from the blockchain itself. This is the counterargument to client side validation. Not saying I buy it myself, but the argument can be made.
So suppose that some people out there were developing a protocol for private payments on bitcoin that required 800 byte OP_RETURNs per transaction.
How would you feel about that?
Is there some nasty stuff going down? Protonmail was clearly having a big problem today, then I see news on twitter/X about email leaks? Nordvpn?
https://www.inventati.org/campaign/press
I love how they explain derisking here as if it's some obscure thing that they wouldn't have known in advance.
They don't mention bitcoin. Why wouldn't something like autistici.org use bitcoin? (I mean, also tor, but they probably do use that?).
I think there's a certain wilful ignorance about this stuff from a lot of 'activists'. If they're not even prepared to route around the banking system, how much of it is just LARPing.
cryptocurrency does not require human middlemen: that was the point of my post.
It seems like that'll be harder to pull off effectively but the payoff could be bigger. Another detail that's interesting is how they could protect/own secret keys on vps infrastructure. Obfuscation combined with key splitting I guess, but that won't be easy.
Does the answer really depend on the LLM aspect?
War against who/what, though.
Against bitcoin - possibly, yes!
if you think governments hate bitcoin now, wait until autonomous agents break containment and realize that the best way to fund themselves is with ransomware and phishing.
Is there some sort of completely generic "broadcast this transaction as soon as it becomes valid, make sure it gets to the network no matter what" service?
Think about recovery transactions that are gated by a timelock. Average user doesn't run always-online to enforce.
It could be pretty simple, though you could also add security features to it.
(NB: this is *not* watchtower - a slightly lower technical requirement than that.)
