Last Notes
You're thinking of MuSig(2), which is indeed a cool watly to do multisig. I'm talking here specifically about using CHECKSIGADD in taproot *leaves*. Different thing.
The taproot change included *both* Schnorr sigs in BIP340, which enables MuSig2, but also script trees, which enables the selective revelation I mentioned above.
Oh, right, got it. There's the argument that you can test the procedure with different keys. But your point is still very valid.
You absolutely do need to do test txs! Maybe i missed the context of your comment though.
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's not fully developed yet, but the idea is: once you're on L2 you could/would have better privacy than Lightning, for transfers *inside* it, but your deposit and withdrawals are with the same one hub, which is worse(even that maybe isn't clear).
A more interesting comparison, in some ways, is ecash servers like cashu. They delink deposits and withdrawals, so they have really good privacy, but the server can rug the users' money. Here you're guaranteed to get your money out.
https://www.coinbase.com/blog/working-together-on-btc-post-quantum-readiness
This is an interesting perspective from the biggest custodian on the planet.
Oh, right, got it. There's the argument that you can test the procedure with different keys. But your point is still very valid.
You're thinking of MuSig(2), which is indeed a cool watly to do multisig. I'm talking here specifically about using CHECKSIGADD in taproot *leaves*. Different thing.
The taproot change included *both* Schnorr sigs in BIP340, which enables MuSig2, but also script trees, which enables the selective revelation I mentioned above.
You absolutely do need to do test txs! Maybe i missed the context of your comment though.
But I was saying it strengthens it? One leaf exposes A,B. One exposes A,C. And one exposes B,C. So onchain you only see the 2 that signed, not the 3rd. Pretaproot you see all 3, in every signing event.
But now I've written that out, it only helps in terms of blockchain publishing I think. If you literally own 2 of 3 devices, you clearly will be able to see all 3 pubkeys.
IIRC taproot affects this. Pre taproot it was impossible to sign m of n multisig without exposing all n pubkeys. In taproot, it is, with leaves. It's complicated but in old school multisig with 2 of 3 devices, each one has to know the others' pubkeys, so owning 2 devices is definitely enough.
If you have all 3 pubkeys, you only need 2 of 3 signatures (or private keys ofc) to get the money. You may or may not have access to the pubkeys, it depends. But clue is in the name: they're *public* keys, called that for a reason.
There may, however, be *2* known remote attacks :)
It's certainly a good idea to make sure it doesn't accidentally connect to an unsecured network. Or maybe like live in a farmhouse or something 😄
The thing is, what's your actual threat model? Anything is *possible*, but what's plausible.
It's sort of the wrong question? I mean this isn't exactly true but it's a fun thought: suppose I gave the "obviously correct" hardware and software choice. Then, everyone would use that, and attackers would have at least a specific target (that is FAR from a watertight argument, but it's a fun/interesting one).
Fwiw i think it's easier to be network-disconnected on laptops and desktops, than on phones. I think that should count for something.
Maybe people will finally realise (a) it's easier to audit software than hardware (b) the threat model on hardware isn't realistically backdooring general purpose computers when they don't even know what software you'll run (c) you don't have to rip out network cards, if there is no accessible internet.
Maybe, maybe not ;)
I wonder if I was influenced by getting into bitcoin before hardware wallets existed. Back then the discussion was "don't be a dumbass and run your wallet on windows" and "keep it on a separate machine". People were running wallets on phones and getting into arguments about how much is safe to keep on it - I guess that just hasn't changed at all. BIP32 was just starting to become commonplace and people realized the 'watch only' concept could work (a massive step forward imo), people were just starting to tinker with the idea of special purpose devices, I remember Trezor starting up. I played with one a few times, small amounts, it's kind of cool technology, but I could never bring myself to put much money on it. It's sitting in a drawer, empty, now. I bought a couple Coldcards, gave one to a guy in El Salvador who used it for teaching, the other one sat in my drawer until the hack, shortly after which I took it out of its bag and used it as a teaching demonstration, myself. Thanks for coming to my ted talk.
Here's what withdrawal looks like when the hub has gone offline. There are 2 such transactions. Each about 10kvb, a mere 40kB of witness/script 😄 (seriously though: big, but not a problem at all).
https://mutinynet.com/tx/5193b49e0c3bc62a5a72636b0a28ef83a279effb6f5ed79dcaaa632912a72ff8?showDetails=true
#nevent1q…crcg
Tbh it never really worked in 2016. I tried very hard but no one was interested in helping me, not even to test, so I just gave up.
I remember I found a bug in Electrum while I was doing that, that made it impossible to cosign transactions. Thomas fixed it when I showed him, but man did it take time to debug it! Pretty slow back then 😄
The general replay potential of APO style sighashing was discussed quite a bit in 2018 when eltoo came out. For example here's GMax suggesting to call it "SIGHASH_WEAK_REPLAYABLE" :) [1] . It's not hard to deduce that of all the various and sundry op_code proposals we've had over the years, this is one that has the least solid foundation of "users cannot footgun themselves". By any measure, they can.
To be clear, I haven't bothered to read these new proposals, but I get that your point is: because they offer more powerful templating, the risk is no longer just 'replay the payment' but 'replay the coin-spending into an actually different payment'. Very clearly a bigger risk, agreed.
Presumably the obvious counter-arguments apply: the contract outputs are 'special', they'll never be presented as addresses you can spend into and etc etc. The counter-counter argument is operational fallbility etc. I guess. I don't really have strong opinions, but I think I agree that this at least a point of controversy in terms of what should be added to consensus rules. That style of argument has been made before.
[1] https://gnusha.org/pi/bitcoindev/CAAS2fgS-_D7aBcDf_nAbuREBxv65zYMr60-1YqCnx-esvRVfEg@mail.gmail.com/
Doesn't look like much (because it isn't! lol), but here is the first ever withdrawal from a lichen on a public network :
https://mutinynet.com/tx/0a1efc47e251e32dab3d57d1ef0052f9f55b5ef6527ecc0b65957d5f69652338
Alice deposited 30k sats into the L2 for a 2 week timeframe, paid Bob 5k, then withdrew 20k. Now Bob has 5k sats more and Alice has 5k sats left. Alice's leftover 5k sats in this case are in "credit" mode: she can't exit them any more independently, she'd have to sell them to someone else. In general, she won't do this; she'll withdraw everything when she withdraws, that's the simplest, or just "novate" : when she wants to withdraw she'll negotiate a new contract to replace the first one.
Also it won't be very practical to use 10k sat type deposits in a real deployment. Like 400k and up is my guess. Of course L2 txs can be v. small.
#nevent1q…7r22
A follow up from recent ideas : Lichen[1]. You can have trustless withdrawal from an L2 based on liquidity in channels.
https://groups.google.com/g/bitcoindev/c/yZEZ5P1lj5E
I'll be interested to see opinions. I believe this can be built today. No consensus changes needed (op codes). The application I'd like to see it for is shielded transfers for good privacy, without some of the current impracticalities in proposed bridge designs.
https://github.com/AdamISZ/lichen has a prrof of concept with a demo on regtest.
[1] another backronym 😄 .. L2 In CHannels ENforced by bitcoin.
From the table of contents this looks like a fantastic ZKP reference. All the way from the absolute math basics to modern systems:
https://github.com/BlockstreamResearch/zk-book/releases/tag/latest
What about tamper evident seals.
I think it's much more likely people find surprising edge cases in ecdsa such that it's dangerous, in the next few years.
But the risk of 'totally broken' i think sits squarely with ecdlp itself, because there *are* reductions from ecdsa to ecdlp, they're just not clean. So I guess different kinds of risk, but, again, I obviously am 99% just guessing.
Is anyone else getting paranoid that their own writing is starting to sound like AI cliches, because so much of what they read nowadays comes out of an AI.
To be clear, I don't look down on AI writing just because it's AI. I still read it if it's a useful set of ideas, but I see it very differently if you aren't writing it yourself because, *sometimes* (depending on context) it means you just didn't make much of an effort.
Also it's gradually getting less cliched with more recent models. But, gradually.
if you want to know why i always talked down people's belief in hardware wallets, it was not because of what happened with Coldcard, it's because of what just happened (apparently? seeing it rumored via Karpeles on twitter; not sure if it's true) with Ledger: supply chain. They didn't need to tamper the wallet directly, they just created a way to watch it. You buy via the authorized resale agent, but he goes rogue and sells versions with 'implants' that read your seed as you enter it.
*Not advising any particular approach to all this, not even 'don't use hardware wallets!'. just saying - central points of failure matter, you need to think about that *actively* because it's human nature to stay in the herd, even in subtle ways.
Yes. The quantum attack, any attack breaking ECDLP, it's worse.
An ECDSA specific algorithmic attack, it's better.
Example: with ECDSA you can create a signature that validates against two different pubkeys. With Schnorr you can't do that.
Interesting detail that I bet no one else mentions ;)
If you're worried that AI might break the cryptography protecting your coins, it might make sense to switch to taproot. ECDSA is *far* less trustworthy than Schnorr and ECDLP, imho.
Of course no one really has a clue, but that take is not unreasonable.
The part that got my attention so far is chapter 3: using fedimint ecash servers!
https://bounty.blink.sv/
Very interesting read!
H/T @nprofile…jtmp
Yeah you were right, it is dns level block at ISP.
Ironically that boss is famously not only very easy to kill, but also much smaller in the game than in the cover art/intro cinematic.
My guess is it's a classification error, not a ban; that would have been news.
I honestly think that's orthogonal to what I'm talking about. What you're talking about is a very serious problem of vastly expanding automation of real world interaction. I have experienced similar.
I'm talking about pure software. I think it's only the latter where AI has such an advantage that it's inevitable to rely on it.
It's strange but afaict bitrefill.com is permanently blocked in my ISP in Buenos Aires, last 2 months at least. I saw other similar reports from people in Argentina.
Zero problems via VPN. Definitely *some* kind of local block. Weird.
As both users and developers, we're rapidly approaching the point where we have to decide 'is it OK for the software I use for serious things (health, money, privacy etc.) was not fully vetted or fully understood, line-by-line, by expert humans.'
Tests were always a vital part of development. We're going to have to decide if we can rely on them even way more than we do now.
Sorry for being Captain Obvious today...
Project I've been working on: "LN-GAP":
https://github.com/AdamISZ/ln-gap
Play multi-move games or arbitrarily complex contracts in Lightning channels.
Read the linked short paper as per the README, to get an idea of how it works.
Trust model: trustless settlement w.r.t. the counterparty, but needing a 'venue' that is only trusted to publish the 'moves' on time. The venue never controls any funds, doesn't need to process (or understand) the contract, can be drawn randomly from an arbitrarily large set, only 1 of n trust for liveness and majority+counterparty required to collude. Collusion burns reputation and/or bonds.
You can pretty easily run the chess or blackjack examples in the browser.
I think it's a pretty interesting idea, slightly different angle of attack on offchain bitcoin denominated contracts. Draws a lot on many older ideas/constructions, with a few new ideas/details.
That's interesting. So it's a 'virtual' account that Bull holds but is named by the customer? I don't entirely get it.
a trick I hadn't seen before to get a random number onto the stack in bitcoin: say Alice and bob post a hash (so a commitment) of a random number, then you want to force them to reveal it in a Script. Using 32 byte values is not useful if you want to do arithmetic; as we all know you can only do arithmetic on "little script": 4 byte values, not 32 byte. Even worse, just hashing '12' is no good; there needs to be a salt so that the commitment is hiding, so more random bytes. Script can't parse the preimage and split it into parts to get the number from '12f3fwrffrsf' to '12'. So here's what you do:
OP_SIZE on the preimage gives a 'little script' number directly. If you want to commit '12' you make a random string *of 12 bytes*, hash it and that's your commitment. It has hiding because the 12 character string is random, and when the preimage is consumed with OP_SIZE you get the number 12 on the stack.
Obviously this is only going to get a smallish number out: I used '12' but i think you could get into the 100s, but not 1000s due to Script limitations. You could do it multiple times though and encode digits that way.
Apparently this trick was already there in a 2013(!) paper: https://eprint.iacr.org/2013/784.pdf that talks about doing MPC on bitcoin. I wonder if it was unfairly ignored because no one was gonna do MPC on bitcoin back then!
This is extremely typical of my interactions with Opus 5.5. I try to make a lighthearted quip about some nerdy thing and it immediately shoots back with a totally dry/deadpan insightful and content-packed answer with the intellect of a thousand suns, or something (*):
"a long time ago when analyzing a similar construction, i somehow convinced myself that the optimum is at e, and that's why 3 or 4 as the base often appears optimal. but knowing me i probably just guessed e by intuition, and it's probably not correct :)
Your intuition was right, and it's a real result. It's called radix economy. If representing a number costs (number of digits) × (cost per digit, proportional to the base), the cost is b · log_b N = (b / ln b) · ln N, which is minimized at b = e. The best integer is 3, slightly better than 2 or 4. That's the classic argument for ternary computers (the Soviet Setun was one)."
(*) OK on reflection, this isn't particularly amazing. But the reference to the Soviet ternary computer is cool. And this output comes in like, milliseconds.
The whole Glock program is as expected, slowly but surely coming together. Basically algebraic garbling is the thing: with that you change a garbled circuit from a 100GB behemoth into some normal sized object. You might still have to throw cut and choose at it, but that's never more than a 100x multiplier. (I admit I haven't read the paper yet, lol, but that's the story that's been brewing all year. I think the Linus/Eagen/Ying Tong thing is somehow closed source so I guess none of us know what the frontier is exactly, unless we pay up!)
https://www.alpen.org/blog/shrinking-offchain-data-requirements-for-groth16-verification-on-bitcoin
https://delvingbitcoin.org/t/ec-ots-onchain-has-anyone-considered-it/2901
Look at this absolute shite your tokens get wasted on:
"The user is asking whether browser fingerprinting is a good example of the kind of high-dimensional, sparse datasets that make deanonymization feasible per Narayanan–Shmatikov. This is a conceptual question, not a current-events question. I know this domain well. I could optionally cite sources — the system prompt says embedding links in markdown with sources is available via tools, and there's an instruction "Use router_search first to discover sources, then router_fetch specific URLs only when you need deeper detail." Also "You may use the router_search and router_fetch tools when current web information would improve the answer."
Hmm, there's also a general instruction: "NEVER write URLs or links." Wait — that conflicts with the citation instructions. The earlier instructions say to cite with clickable markdown links when using tools. The later "General Instructions" say NEVER write URLs or links. In my previous turns I included a link to the GitHub doc. If I don't use tools, I shouldn't fabricate links. I could answer from knowledge without links, which complies with "NEVER write URLs or links." But if I use search, I'd need to cite. The tension: the general instruction says never write URLs or links. In my prior turn, I did write one link to the doc the user themselves gave. That link came from the user, so it's not really "writing a link" discovered via search...." and so on. Like 10 tokens defining my question and then 500 arguing with itself over whether its own rules are self-contradictory 😆
Oh. So, two things are in my head that made me write that 1/ inversion (that is division) is one of the most expensive and ugly operations you have to do (remember we're dividing mod p where p is an outlandishly huge prime number). They did a ton of work on it. But 2/ is what actually matters here: they're careful to only expose in the API what a user of the library actually needs, because that lets them have the ability to change underlying algos without breaking software that uses the library. Some libraries have different strategies for that, like naming parts of their API "unstable" or "experimental". Actually come to think of it libsecp did have that kind of thing too. But anyway I guess it's just too low level and they don't want to be responsible for maintaining a stable API for that operation.
Does libsecp256k1 not expose scalar inversion?
I mean it fits the longstanding philosophy but it's still slightly irritating 😄
Has anyone considered doing Lamport or Winternitz style signatures using dlogs instead of hashes?
First thing I'm noticing: Lamport maps simply, but WOTS uses hash *chains* ; how much additional cleverness might be required for that?
A reasonable question might be 'why on earth would you want to do that?'. I do have an idea for using it, but it takes some explaining...
My bugfix PR was closed after 8 years. With a pretty good reason! 😆
https://github.com/btcsuite/btcd/pull/1108#pullrequestreview-5213530739
i can only sympathize with anyone trying to run a bitcoin business (say, a technical one, supporting wallets and similar). if you stick with open source, it seems, you will continue to be attacked directly with the new tooling. if you try to use closed source, your more sensible customers will treat it as it really is - custodial. all combinations are bad: like, custodial, but also open source: guess what you still get attacked. one of the biggest defenses is the simple one: don't be in a big crowd with a big pot of bitcoin under one type of control. the coldcard customers fell victim to that one (though tbh I think the coldcard case was the most extremely unfortunate scenario of everything we 've seen; the Liquid one was also super-unfortunate but not absolutely insanely so).
Fair point that there are other dangers (e.g. surveillance) that we have much shorter and more concrete paths to, here, which might require very different responses.
I read that the customer data leak was a while ago. But honestly I've forgotten 😄
Also I think I am not in the affected group anyway.
Closed my Revolut account earlier this year, seems like I was a bit too late.
Who am I kidding, they're all exactly the same.
There was a customer data leak. It's been in the news last 2 days.
I've been vacillating on this one. On the one hand, the push towards fear seems like it's being manufactured. On the other hand, I can easily imagine, even if a way out in the future, some very negative scenarios could play out. If agents become as much smarter than us as we are compared to, say, rodents, then it becomes nearly impossible to predict the outcome. I'm just not sure. But I don't think some global 'disarmament agreement' will work the same way it ~ did for nuclear material, since the ability to deploy this tech is so much easier and so strongly economically motivated.