Anyone else starting to think they judged Kurzweil too harshly? Just had an AI call me about my home security, which modulated its speech when it realized my cellphone signal was bad. It got the info it needed and politely ended the call. Then I opened twitter and saw that they had solved Navier Stokes. It's all a bit much.

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?)

it seems that the bug ultimately comes down to this line: "

GitHub

elements/src/script/sigcache.cpp at c7e856fab1b0c4d37005e25c0940184d812a26a0 · ElementsProject/elements

Open-source implementation of advanced blockchain features extending the Bitcoin protocol - ElementsProject/elements

" . 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?

I think GLM 5.2 might have found this. See Poelstra's response in this github thread:

GitHub

Confidential peg-in transaction · Issue #1325 · ElementsProject/elements

Hi! I've found a confidential peg-in transaction fd36f216be666d43ec861feb756b1c5f48fb54f98bfeed25e5367b05cccc96e8 and I'm wondering why its amount ...

. 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

Liquid Explorer - Blockstream.info

Blockstream Explorer is an open source block explorer providing detailed blockchain data across Bitcoin, Testnet, and Liquid. Supports Tor and trac...

- this is the transaction at which people are saying there's a consensus split. View quoted note →

X (formerly Twitter)

Steven Roose (@stevenroose3) on X

@januszg_ I don't think they hacked the functionaries. The tx also delivered some other pegouts, so it looked like they someone got hold of 4k actu...

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.

Liquid rolling back the chain in 3.. 2...

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.

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.)

You can bet signet coins at

Thimbly — trustless Bitcoin betting

.. 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 :)

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.