How long does the flash memory in a hardware wallet last without being plugged in? USB drives and flash memory usually fall prey to bitrot. Any numbers that we can reasonably go by?
nostr:npub132ertlsrunh600cph2au55ssmel2cqdt5mnrpxfand5ych4nmp8q50zmdh
Pushtx -- the Privacy-focused Bitcoin Transaction Broadcast Tool -- has received quality of life updates in v0.4.0:
- broadcast to a single peer for more privacy
- wait to see the transaction on the network for better confidence
- misc improvements
Literally every non-user facing utility library out there. 
Fellow plebs, what kind of Bitcoin or privacy software would scratch an itch for you right now? Anything that you'd actively use but just isn't there yet?
#bitcoin
Twitter is broken for me so I'll just take your word for it. I agree that the interview was heavy on hyperbole. I didn't particularly care for the "changes to bitcoin are inflationary" argument.
Did he actually call them "central planners"? I listened through the whole interview and don't remember anything like that.
To my ears at least, his message was that we need to be very deliberate and slow with changes to the base protocol.
π―. Constant API breakages make rust-bitcoin really hard to use when different dependencies rely on different versions of it and expose it as part of their public API. Every upgrade is an uphill battle.
Unfortunately the ecosystem does not offer an alternative yet. Should it? nostr:note18rx7rrg20xfwfy6savawrxx8p8dy62dwf6cs7477a822mf28rnes8k3ml2
I just finished listening to nostr:npub15dqlghlewk84wz3pkqqvzl2w2w36f97g89ljds8x6c094nlu02vqjllm5m 's WBD episode on "ossification".
I largely agree with regard to the base protocol -- stop messing with it. Whatever you think you're bringing to the base layer probably isn't worth the risk.
But this shouldn't preclude innovation **on top of** Bitcoin. We need more L2 software, software that interacts with Bitcoin and lives symbiotically with it.
From Coinkite's official list of releases:
https://raw.githubusercontent.com/Coldcard/firmware/master/releases/signatures.txt
The PGP verification is done by the device itself.
The user-side upgrade process verifies that the firmware checksums match.
The actual cryptographic verification (i.e. "this firmware is official") is done by the Coldcard bootloader during the install process, since you should never trust the computer anyway.
A new version of the Coldcard CLI and Rust lib has been published.
Use Bitcoin responsibly, do not use centralized services and custodians.
https://github.com/alfred-hodler/rust-coldcard
#rust #bitcoin 
There is no way to prevent it other than by running your own Electrum backend. There are some lightweight ones like the EPS (which still requires Core): https://github.com/chris-belcher/electrum-personal-server
The problem reduces to this: you're asking a potentially adversarial server to tell you your address balances. At which point the server knows what addresses you're interested in and therefore likely belong to "you" (they may not know who you are though).
Do this with a wallet that contains clean coinjoin outputs and you've just undone all your coinjoins.
AFAIK Sparrow isn't a good tool here because it uses public Electrum servers by default, thereby negating any benefits that its coinjoin feature provides.
Politicians need to realize that not allowing permissionless innovation is a national security risk. Regardless of how you feel about the nation-state as a concept, putting a damper on innovation just causes your tribe to fall behind in civilizational terms.
Every time you require a license for people to build stuff, your enemies rejoice.
The same way: DNS seeds with a fixed peer list for fallback.
Tor doesn't help because Electrum bulk requests all your addresses from the remote server. At best Tor will keep your IP private but all your addresses are correlated as belonging to the same entity the moment you connect.
I wrote a very basic overview of watermarking, fingerprinting, timing analysis and supernodes for Bitcoin Magazine's last print issue, which is pretty much an unsolicited advertisement for why I think we need a second mempool (and also mixnets, but thats a longer story). Since no one cares about stuff like this on Twitter anyway, I'll explain here.
Bitcoin has a privacy issue on baselayer. I know this. You know this. Everybody knows this. The problem is that there's a lot of stuff we can't do to solve this issue without completely fucking up how Bitcoin works, like, say, anonymous amounts. But there is some stuff we *can* do to increase privacy on the Bitcoin baselayer. One of those things is incorporating a second mempool to integrate Dandelion++, the routing protocol used in Monero. Hear me out.
One of the ways blockchain surveillance firms identify who what transactions belong to on the Bitcoin blockchain is by operating so-called supernodes. A supernode sets up as many connections to other nodes as it can, and by doing so can establish where a transaction was first seen in the peer-to-peer network, ergo ascribe whom a transaction belongs to.
Here's where Dandelion++ comes in. Instead of propagating transactions to *all* connected peers, Dandelion++ propagates transactions like, well, a Dandelion.
In Dandelion++ propagation, Bitcoin nodes send transactions to *one* peer, instead of to all of them. This peer sends it to another peer, they send it to another peer, and so on and so forth. This is called the "stem phase".
When we've established enough plausible deniability, Dandelion++ reaches the "fluff phase". At this point, a node that did not *create* the transaction, but is simply relaying it, propagates it to all nodes in the network it is connected to, including supernodes, and the next node does the same, and so on and so forth β business as usual.
Incorporating Dandelion++ (or any other anonymizing propagation protocol, like Dandelion, Dandelion Lite, or Clover) would arguably seriously fuck up the blockchain surveillance stick as we are taking away the most obvious attack vector for blockchain surveillance firms. It's also not a trivial task, see ajtowns' overview of stempools (and no one wants to maintain another mempool on bitcoin, if we're honest). But it's a really interesting proposal to think about to increase privacy on Bitcoin that, yes, would be a lot of work to implement and maintain, but also does not get talked about enough imo for everyone yapping about Bitcoin baselayer privacy.
AJ Towns' Stempool overview: https://gist.github.com/ajtowns/f3a19c33b80750a47c5b83ecf6a09aaf
BM Article:
https://bitcoinmagazine.com/print/whistleblowing-in-the-surveillance-age
Yesterday I published a lightweight tool that broadcasts transactions in a private manner through Tor. Seems much simpler than Dandelion. It can be integrated into wallets too.
Never use Electrum unless you're hosting your own backend. There is no telling how many public Electrum servers are run by chain analysis companies and other adversaries that are in the business of attributing IP addresses to UTXOs.
Electrum was a great piece of software 10 years ago, but the surveillance landscape has changed a lot since then and it is not really safe to use it in its default state.
TLDR: run your own Electrum backend or don't use Electrum.
Broadcasting through Core has always worked well, if you have Core. This is meant for situations where Core isn't available or where you have serious privacy concerns.
Think mobile and desktop wallets that need to send out a set of transaction quickly and privately. Core is a massive dependency with a long bootstrap time and not available in many situations.
I have released a unique privacy tool and code library that broadcasts Bitcoin transactions **directly** into the P2P network.
1. No external dependencies whatsoever.
2. No centralized backends.
3. Uses Tor if found running on the same system. Having the Tor Browser open in the background is enough.
Find the CLI here:
https://crates.io/crates/pushtx-cli
And the Rust crate here:
Want to upgrade your Coldcard firmware with the latest release over USB? The right tool for the job is now available.
https://github.com/alfred-hodler/rust-coldcard/tree/master/coldcard-cli
#coldcard #rust