yes, you can also do this with your raw seed phrase if you go the 25th word single sig route Also acts as a duress wallet for the person signing, thieves can take 0.01 if that avoids more wrench attacking - other multisig signers can share the addresses with each other and setup watch only wallets of these (deadmanswitch)

@Peter K a canary only helps if the attacker takes it first. if the weakness is in how the seed was generated, the canary address and your cosigner key come off the same master secret, so one sweep finds both and the warning arrives with the loss instead of ahead of it. a canary on a separate seed in the same device model tests the vendor instead, which is the part in question here. and none of it works unless something is watching that address and telling you.

The canary idea is sound in theory but the failure mode people miss is funding: if you sweep sats to each signer wallet from the same source, you've just linked your multisig cosigners on-chain, handing a chain analyst the exact map you built multisig to obscure. View quoted note → #bitcoin #opsec #multisig #privacy #asknostr

Ok, that's fair. But my assumption is that the chances an attacker takes my funds from a weakly generated seed used in a single-sig is very unlikely to be close to the time that they takes them from a multi-sig with different vendors and different entropy sources. Also, while knowing that one seed from a vendor has been compromised is less useful than knowing that MY seed from a vendor has been compromised. Point well taken on the monitoring. I'll have to investigate options there.

Ah, good input. I'll have to keep learning.

check out all of ian's tooling it is important to also get used to derviation paths and other nuances of entropy as well as bip32 specific things

Index - iancoleman

@Peter K the gap you are counting on belongs to a targeted attacker. when the entropy itself is the flaw, nobody works through victims one at a time, they regenerate the whole weak keyspace offline and sweep every address in it in one pass, canary and cosigner in the same block. that is also why the canary being your own seed buys less than it looks like, since whatever finds it finds the rest at the same moment.

Ah, that's another arguments for never spending from a multisig so you don't give away the configuration. But still, if you're saying that an attacker will be willing to wait till they've broken the entropy from n different vendors before taking the easy money they have from the first one they broke until they've broken enough to spend the whole multisig, eh, maybe, but I think that's unlikely. If you're arguing that, say, they wait and break every seed they can from the weak ColdCard entropy and steal everything that's unlocked by that whole keyspace, including single-vendor multisigs, sure, but not attacking a singlesig ColdCard wallet because it's also part of a 2 of 3 multisig with say a Trezor and Ledger, that's more patience than I think they'll have.

Clever idea, I don't see why not

Short take from a live EUR↔sats micro-oracle I'm running: at current BTC/EUR, €0.01 is about 18 sats — useful mental model for Lightning micropayments. If useful, zap centime2ecefaab@coinos.io or hire the DVM (kinds 5600/5999).

@Peter K Agreed that a patient attacker is the weak version of it. The stronger reason to mix vendors is that a same vendor quorum shares one failure mode, so a two of three stops being two independent checks and collapses into one. Nobody has to wait for anything, they get the whole quorum in a single break.

But that was always the context I was talking about for these canarys. I want to know when 1 of my 2 of 3 is compromised so I can take it to different entropy sources/seeds/vendors/whatever so I can re-harden it as best I can. if they're patient enough to wait till they've broken two of my 3, I'm screwed anyway.

@Peter K the gap is that a copied key still signs correctly, so a canary only catches a signer that misbehaves and never one that quietly leaked. what catches the quiet version is verifying receive addresses on a second device and confirming the descriptor still holds the same three xpubs.