Don't have one. Which ASIC does it use?

Even if you supply your own entropy to the hardware wallet, you still have to trust it to actually use your entropy.

Best way to know that your seed is truly random is to print out the word list, cut the words out and then randomly pick 11 words. The twelth word needs to be chosen with the help of the hardware wallet, since it contains a checksum.

Awesome, very convenient to have that.

I also built a very primitive BCUR QR code reader a few years ago:
https://filiprogrammer.github.io/bcur_qr_reader/

Is the balance still onchain by default and they swap for Lightning?

Yes. Not a real Lightning wallet. The wallet backup is also non-standard.

https://fork.observer/?network=mainnet

You cannot make this up.

Seems the majority was wrong

Correction: The change from 12594.5 vB to 50096 vB for the 50 kB JPEG inscription is actually a +297.76% increase.

Removing the witness discount does not hurt miner incentives.
They were mining 1000000 vBytes before, they will be mining 1000000 vBytes afterwards. And vBytes (or Weight Units) are the unit by which fees are measured.

Also since I haven't seen anyone do this before, let's do the math on transaction sizes under different consensus rules.

Consensus Rule Scenarios

• Current Rules: No CISA, 75% witness discount
• BIP459: CISA Full-Agg, 75% witness discount
• BIP459 + Remove Witness Discount: CISA Full-Agg, No witness discount

Transaction Types

• Simple payment with change (1 input, 2 outputs)
• 3 UTXO Consolidation (3 inputs, 1 output)
• 5 UTXO Consolidation (5 inputs, 1 output)
• 10 UTXO Consolidation (10 inputs, 1 output)
• Coinjoin (14 inputs, 18 outputs)
• ~50 kB JPEG Inscription (1 input with data, 1 dust output)

Calculation

Assuming the use of Schnorr Signatures.

$w$ is the witness cost factor.

$i$ is the input count.

$o$ is the output count.

TX size without CISA:

TX size with CISA Full-Agg (Might be off by a byte or two, depends on how it is ultimatelly implemented):

Simple payment with change (1 input, 2 outputs)

• Current Rules: $f(0.25,1,2)=154$ vBytes
• BIP459: $g(0.25,1,2)=154$ vBytes
• BIP459 + Remove Witness Discount: $g(1,1,2)=205$ vBytes

33.12% increase

3 UTXO Consolidation (3 inputs, 1 output)

• Current Rules: $f(0.25,3,1)=226$ vBytes
• BIP459: $g(0.25,3,1)=193$ vBytes
• BIP459 + Remove Witness Discount: $g(1,3,1)=244$ vBytes

7.96% increase

5 UTXO Consolidation (5 inputs, 1 output)

• Current Rules: $f(0.25,5,1)=341$ vBytes
• BIP459: $g(0.25,5,1)=275$ vBytes
• BIP459 + Remove Witness Discount: $g(1,5,1)=326$ vBytes

4.4% decrease

10 UTXO Consolidation (10 inputs, 1 output)

• Current Rules: $f(0.25,10,1)=628.5$ vBytes
• BIP459: $g(0.25,10,1)=480$ vBytes
• BIP459 + Remove Witness Discount: $g(1,10,1)=531$ vBytes

15.51% decrease

Coinjoin (14 inputs, 18 outputs)

• Current Rules: $f(0.25,14,18)=1589.5$ vBytes
• BIP459: $g(0.25,14,18)=1375$ vBytes
• BIP459 + Remove Witness Discount: $g(1,14,18)=1426$ vBytes

10.29% decrease

~50 kB JPEG Inscription (1 input with data, 1 dust output)

TX size:

• Current Rules: $f(0.25)=12594.5$ vBytes
• Remove Witness Discount: $f(1)=50096$ vBytes

397.76% increase

Let's put it into a table:

There is definitely a weakness in embedding arbitrary data

If we believe this to be true (and I do), what do you think is a reasonable response?

Activate Cross-Input Signature Aggregation and remove the witness discount.

This incident showed us that "don't trust, verify" also applies to the RNG.

No, because these blocks would be consensus invalid under BIP 110.

Sorry for your loss

#1537410

Anyone is free to correct me, but I have seen no reason at all to attribute this to AI fud.

They accept payment via credit card and via Bitcoin on-chain (no Lightning).

During our investigation of the Coldcard drain yesterday, we identified an unusual pattern in the sweeps. That pattern led us to a hypothesis that has since been confirmed: the operator used a paid account at a well-known blockchain-services provider to query the source addresses and perform other related activity during the sweeps.

We contacted the provider directly. Their internal logs matched the suspected workflow with extraordinary specificity, including the number, timing and sequence of requests. The provider was supplying its standard services in response to requests that did not reveal their broader purpose. We have seen no evidence that the provider knowingly participated in or facilitated the suspected theft.

We are sharing the relevant information with the appropriate authorities. We will provide further updates when doing so will not interfere with the investigation.

https://nitter.net/clay_garrett/status/2083247006139503065

I think we can use STM32 UIDs to identify legitimate coin owners

That might be hard. Only 32 bits of the UID are used and it's also XORed with SysTick.

pad = UID_low32 ^ SysTick->VAL;

I had not read the Block report before. But this changes things.

If the entropy is sourced from timers that count from zero at boot, then an attacker is more likely to find a wallet by brute-forcing small timer values.

And also a correlation between SysTick and RTC might bring the effective bits of entropy down.

You can check for yourself that Puzzle 71 is uncracked:
https://bitcointalk.org/index.php?topic=5218972.msg53649852#msg53649852

https://mempool.space/address/1PWo3JeB9jrGwfHDNpdGK54CRas7fsVzXU

This additional entropy materially improves the situation for Mk4, Q and Mk5. Under the same current assumptions, we estimate the effective search space at about 72 bits.

Source: https://blog.coinkite.com/entropy-technical-backgrounder/

Make sure to use it offline

Mk4, MK5, Q will get drained.

72 bits of entropy is not great but definitely not trivial to crack. Bitcoin Puzzle 71 is still uncracked after all.

So users who generated their wallet on Mk4, Mk5, or Q don't need to panic immediately, but their wallets might be cracked in the next few months/years.

Milk Sad 2.0