Cold storage without a hardware wallet \ stacker news ~bitcoin

pull down to refresh

1815 sats \ 57 comments \ @expatriotic 14 Mar bitcoin freebie

You don't need a HHW in order to achieve cold storage for your bitcoin.

Shocking I know.

If you only have $500 worth of bitcoin, you probably don't want to spend $50-%250 on a HHW.

If you want to stack sats but you don't want to do it in a hot wallet you'll need two devices... Either two mobile phones or a phone and computer is fine. If any of the devices are Android, I would suggest flashing LineageOS, GrapheneOS, or CalyxOS to it first. This will help to "de-Google" the phone and increase your control over the hardware. That's for a separate post though and it's not a necessary step here.

Here is a 5-min video that covers the following method in detail utilizing Samourai and Sentinel.

For creating a wallet you can use Samourai, Envoy, Blue Wallet, Stack Wallet, or Sparrow. For the WoW (watch only wallet) you can use Sentinel (android) or Blue Wallet (iOS). See my previous articles for links to everything.

The flow looks like this:

Generate a wallet whilst in airplane mode on device A (Samourai, Blue Wallet, Stack Wallet, Sparrow can all do this).
On device B, import the xPUB, zPUB, or yPUB.
After you've done that, delete the wallet from device A. Or keep the device offline and keep the wallet there.

This isn't for spending it's for stacking. One could spend even while the wallet remains offline. Simply create and sign the transaction, and send it to the Sentinel or Blue Wallet for pushing out to the Bitcoin network. By staying "cold" this would increase your security, but not your privacy. I would recommend using whirlpool first and then using the post-mix tools on Samourai or Sparrow. This necessarily requires the wallet to be hot.

view all related items

72 sats \ 32 replies \ @nerd2ninja 14 Mar

I think you were on the right track. You were trying to present an DIY airgapped solution.

However, DIY airgaps recommend physically removing wireless devices such as bluetooth, wifi, and even the cellular radio. Its difficult to do to a phone, but for a laptop its doable.

These are the DIY airgap solutions I pass around: https://github.com/nerd2ninja/bitcoin-sop/blob/main/Funds_Management/Stages_of_storage.md

(This is mostly just a link to other links lol)

0 sats \ 31 replies \ @expatriotic OP 14 Mar

I disagree, grapheneOS is extremely hardened. Phones are much safer (or can be) than a laptop... (Sans removing physical equipment as you're suggesting)

1250 sats \ 21 replies \ @nerd2ninja 14 Mar

You disagree in ignorance. GrapheneOS is hardened sure, but cves are still found for it and it hardens even still.

One of the biggest problems with GrapheneOS (especially for this setup) is that software updates come over your wireless network. If that software update were malicious, you get pwnd.

https://www.xda-developers.com/android-oem-key-leak-samsung-lg-mediatek/

So the way you propose to solve this problem is by using airplane mode, but what that looks like to me is you have a gun pointed at your foot and you aren't worried about shooting yourself because you just trust yourself not to pull the trigger.

You should do a lot more research on airgap security (and airgap penetration those are fun) before being so confident about your advice.

21 sats \ 14 replies \ @final 15 Mar

I will add some context for this in how we handle these situations:

GrapheneOS is hardened sure, but cves are still found for it and it hardens even still.

Many/almost all CVEs we have discovered actually do not affect GrapheneOS. Many from the upstream also are not likely to work or cause damage. They get found because our exploit mitigations (MTE, Hardened Malloc, etc.) allow them to be uncovered since we forcibly crash apps that have memory corruption bugs and provide the ability to share logs to help developers/security researchers. More is good in this case because it means more identified, more patched, more R&D and security improvements. We're very happy to know we discover novel vulnerabilities thanks to our hardening.

For example, we recently uncovered a memory corruption bug introduced in Android 14 QPR2 for Bluetooth LE which we reported to Google. The team reported it as an Android vulnerability and has been designated as a High severity and quality report. On GrapheneOS this would make Bluetooth LE functionality with the relevant devices (Samsung Galaxy Buds and watches) to crash reliably or break, while in the stock OS it could corrupt user data.

When we discovered companies exploiting Fastboot mode on Pixels to allow data extraction, they explicitly avoided mentioning it's failure to work on GrapheneOS, noting separately GrapheneOS devices needs it's user to surrender their PIN for data extraction themselves for their products. No security measure will protect against someone willing to turn them all off to someone by surrendering their credentials.

One of the biggest problems with GrapheneOS (especially for this setup) is that software updates come over your wireless network. If that software update were malicious, you get pwnd.

You could just sideload instead of doing updates OTA if you wish. OTA is strongly recommended but they are optional. You can also read the source code and reproduce the builds. Even if you do all of this, you're still trusting GrapheneOS because you need updates to be signed by GrapheneOS if you are already using it or it will be rejected for security. There is a degree of trust in anything you use even if we try and make it as untrusted as possible. Overkill is you can just build the OS and the updates yourself.

https://www.xda-developers.com/android-oem-key-leak-samsung-lg-mediatek/

This case affects system apps signed with a specific OEM's platform certificate. This attack is only possible due to incompetence by the OEM getting their keys leaked. If you leak your keys to sign your apps then anyone can sign their app as yours and make a malicious update to an app you created providing they have the same certificate and key. They should do better to make sure no one but them had access to it.

A mechanism like this is needed for operating system updates too. In the case of Verified Boot all updates must be signed with the same key pair, versions cannot be downgraded, turning it off or wanting to change the key erases your data. If you sideload an update or get it OTA it does not matter. If someone compromises the servers they can't push an update because it's not signed by the developers. You can also verify the boot key hash matches the legitimate OS at boot. Like with GrapheneOS: https://grapheneos.org/install/web#verified-boot-key-hash.

The Auditor app also helps with verifying you are using a legitimate GrapheneOS build and more.

Won't comment on the choice of Airplane Mode, you can hide the quick tab buttons but it's up to each person to do their due diligence and handle the device properly of course. Could be room for making enabling/disabling require more attention or difficulty in the future.

(This comment is in no way suggesting GOS should be used as a hardware wallet. It's up to them. We think the hardware/platform we have is very secure for cryptocurrency uses but of course a dedicated device with a secure element, upgradeable firmware and good security posture would be a recommended and sensible option)

52 sats \ 5 replies \ @nerd2ninja 16 Mar

Look, I'm using graphene myself you guys are great (for your intended usecase), but when it comes to securing people's net worth its just not okay to not meet the basic requirements (use hardware that doesn't have wireless devices on board). Its such a simple requirement to meet and so many signing device manufacturers fuck it up.

The way I think about cold storage is, if you wouldn't recommend it to a nuclear power plant to transfer a software update to their nuclear reactor, or to a government transferring classified data between devices, why are you recommending it to people to secure their net worth? Especially because the requirements are so achievable and just require actual verification and to not use hardware that isn't appropriate for the task, the baseline of which is to not have wireless devices on board.

I wrote a lot more, but I'm trying to write less to keep focus on the things that matter most.

21 sats \ 4 replies \ @final 16 Mar

Not a problem at all! :) I'm just adding some context. I'd also prefer a dedicated device as mentioned in the end of my last reply especially for cold storage, GOS Foundation cryptocurrency funds are managed entirely by signing devices. I only use LN funds on my phone, nothing else (can't say the same about the others but I believe it's the same). It appears the OP is discussing a low budget, and if they really can't afford a dedicated device but have a phone then keeping that as secure as possible is likely the closest thing they can do.

GrapheneOS definitely is a massive improvement for a use case like that even though we aren't very oriented on cryptocurrencies, just mobile security and privacy.

If they are handling large amounts and all of their funds then keeping it in a dedicated, secure and offline signing device is a must-do. It's definitely one of the very basics someone should learn to do if they have the comfort and budget to do that. It's not just security but also just contingency against device failure.

0 sats \ 2 replies \ @nerd2ninja 16 Mar

Just to put it out there, if you were looking to make a signing device, there are lots of PCB manufacturers out there. Personally, a file like the ones you see on kitspace that I could give a PCB manufacturer that was simple enough that I could visually inspect the board and verify its correct with no hardware level backdoors would be like my dream signing device.

Which sure cold card was going for that with the whole clear case thing but they kinda went source available rather than open source on us.

A GPLv3 license would also be pretty rad.

42 sats \ 1 reply \ @final 16 Mar

We definitely don't have people for this and a hardware OEM would need to work on that, plus it seems may seem a bit out of what GrapheneOS is focused on as a mobile/security privacy non-profit. Although it could be a nice thing.

In the past there had been ideas of a phone that could essentially have a Trezor or equivalent built into it with a whole separate display on the back and completely isolated, but it already works as separate hardware anyway.

A serious OEM could make a phone with this in mind and make an ecosystem with it. Android keystore API could have support for secp256k1/Schnorr added and then apps could use additional secure element support for it. In practice someone could add that as an extension implementation, but it would need to be part of the stock Android standard apps APIs for app devs to consider using it. It wouldn't really be much of a hardware wallet alone since there's no secure display.

The open hardware would be more of a ethical choice than a security or privacy one. If it did use an open hardware design, there would still be just as much trust in the manufacturing for each component you buy like an SoC or secure element. The manufacturing process itself isn't open, and makes up a lot of their complexity.

Trezor do quite a similar job to what you describe, people build their own, they also do GPLv3: https://www.instructables.com/Making-My-Own-Trezor-Crypto-Hardware-Wallet/ https://github.com/trezor/trezor-hardware/tree/master/electronics

The issue is the Trezor's before Safe 3 don't have a secure element so strong PIN/passphrase and other remediations needed to protect physical attacks.

side note: Electronics is not my strong spot at all.

view replies

0 sats \ 0 replies \ @expatriotic OP 16 Mar

It appears the OP is discussing a low budget, and if they really can't afford a dedicated device but have a phone then keeping that as secure as possible is likely the closest thing they can do.

Exactly.

And of course, I use a Foundation PASSPORT for my large funds, and LN funds are spendable from my phone.

0 sats \ 7 replies \ @expatriotic OP 16 Mar

If the cold device stays offline does it need updates? E.g., some of the Samourai wallet guys argue that it's okay to use unsupported pixel phones with GrapheneOS because they're keeping it offline.

0 sats \ 6 replies \ @final 16 Mar

TLDR: Update because there is several benefits.

It is always better to update. Updating also gets you the new security features and enhancements. We added a feature in Tensor Pixels to completely disable the USB-C port's data lines or the port entirely very recently. In a use case like cryptocurrency then that could be quite useful. Future in-development features like Duress Password could also go a long way.

Even if they don't matter, if you have a threat actor who is quite persistent, then updating prevents possible attacks. Air-gapping only protects network-based threats.

(Note: This scenario is neutral and isn't entirely specific to Samourai but I tried my best. Knowing them, they probably do have some anti-forensic features so some of these possibly won't count for them.)

Imagine a scenario where the Fastboot mode vulnerability affected GrapheneOS, or you were using an unpatched stock Pixel, or the vulnerability was never discovered by the team... Threats who had access to this company's capabilities would be able to just crash the device causing an unsafe reboot that doesn't clear RAM, memory dump the phone via their exploit and be able to brute force the device credential. For these users I imagine this is how far they'd get, they're probably incorporating a strong, high entropy passphrase.

So, lets imagine the user is stupid and that brute force is successful, they can extract the full filesystem and clone your application data. If an app stores data encrypted and was active/unlocked during the time they begun the dump, it is possible that memory dump could find possible information about the app. This happens with apps like KeePass in research where users can get the DB passphrase, and disk encryption all the time in the real world to get the decryption keys.

Even if there is no keys in memory or it is encrypted, cloning that data is useful in brute-forcing. It should in-theory bypass some brute-force prevention measures like a destruction PIN or attempt limits since they can just keep using the clone from before it. If I was a persistent actor who seized a phone and cloned the data of a Samourai user, I'd not target their backups or memory since BTC private keys cant be brute forced, rather I'd just clone the app data (samourai.dat), run on a bespoke script and brute force the PIN that opens it instead.

By the looks of it when writing this reply, someone else already had this idea: https://vrls.ws/posts/2021/08/samourai-wallet-bitcoin-pin-authentication-bypass-crypto/

(Does Samourai Wallet still do AES-KDF for derivation? Maybe someone should tell them to consider Argon2id if they haven't?)

This is not a security issue with Samourai by any means worth screaming about nor a critique of their security, the fact someone actually assigned a CVE to that is also quite petty, every app of it's kind with an authentication should have one then for the same reasons. I've seen KeePass make CVEs dismissed over this by saying it is the responsibility to use a secure OS to prevent such an attack.

Someone with a lost/seized device would be able to just import the private key to a new wallet and move the funds away before the brute force is successful. The article says around a hundred days but appears the guy using was using his notebook, would definitely be much faster for a sophisticated threat. Even if they could brute force instantly, the time to brute force the OS has been ignored, that takes time too.

They made a statement on Twitter which is a completely reasonable response: https://twitter.com/SamouraiWallet/status/1423590495054348290?s=20

While using a very strong passphrase, incorporating GrapheneOS exclusive security features and so much more would fix that scenario if the exploit was unpatched anyway, it is a matter of having defence-in-depth and better to have all the walls standing than one of them to break. Updating is always good because you keep all the walls standing and reinforced.

From my experiences all cryptocurrency wallet apps on a phone with a physical access have a way of getting fucked unless they take extreme measures. Securing the operating system running the app is sufficient for almost everyone and GrapheneOS definitely does that job. If you are this worried about a threat with all of these capabilities then maybe you should probably not have a computer. Even if a supposed brute-force took days, that's still more than enough time to move funds and import elsewhere like mentioned before.

21 sats \ 3 replies \ @final 16 Mar

will reiterate: the exploit only worked on AFU devices, this scenario assumes device is AFU and using the profile the wallet is in.

0 sats \ 2 replies \ @expatriotic OP 16 Mar

AFU?

view replies

0 sats \ 1 reply \ @expatriotic OP 16 Mar

Update if possible, but GrapheneOS doesn't support 4gen and prior, in which case it's not possible.

21 sats \ 0 replies \ @final 16 Mar freebie

We do provide extended support releases for these devices but they have many missing features and are meant to help users transition to a newer device. The newer Pixels aren't just faster, they're more secure, especially the Pixel 8 and later thanks to hardware memory tagging.

The unsupported/extended support devices do not get firmware or driver fixes, any vulnerability incorporating them remains unpatched. Using a heavily insecure unsupported device with many missing patches as a wallet may not be the best choice, especially if you're relying on it for other sensitive manners. You could thrift it and buy a signing device in some cases. Likewise, if a phone is seized that actor can sit and wait how long he wants until an exploit in the secure element is uncovered which allows him to brute-force.

Having a dedicated user with a stronger passphrase just for managing cryptocurrencies could help especially if you have a larger (but not cold storage worthy) amount. All of it's data would be encrypted and at-rest when not in use and it won't be active if you have another profile in use providing you set up the options. I do this to handle other currencies or PayNym payments. An additional user also makes it harder for the threat actor in the scenario above, as the profile would be at rest and could not be unlocked via a RAM dump brute-force unless the dump occurred while the profile session was active. Would need to have an exploit for the secure element like the device was in BFU otherwise.

0 sats \ 0 replies \ @expatriotic OP 15 Mar

BTW, in this setup, you would not be updating the software over a wireless network (or at all TBH) because the phone with Samourai on it that is cold is... cold. It's offline. Always. It has the private key and is just used for signing. Sentinel will broadcast and send out the message.

0 sats \ 4 replies \ @expatriotic OP 15 Mar

My apologies sensei, clearly you are extremely knowledgable and I disagree with you at my peril, the peril of my stack, and the peril of the stack of everyone unfortunate enough to use the woefully inadequate GrapheneOS.

0 sats \ 3 replies \ @nerd2ninja 15 Mar

You still haven't gotten that GrapheneOS isn't the problem tho. Its the rest of it. Its how do you remove the wireless devices to make sure only SD card or QR codes with PSBT files come on or off the device?

1 sat \ 2 replies \ @expatriotic OP 15 Mar

No I understood your point... It's just boring...

The comments section here is just ridiculous at this point... I'm accused of telling people to BUY a new phone (never said that), and then I have people saying, use a laptop instead.

Okay... What if someone doesn't have a laptop... or what if the laptop they have is already full of spyware unbeknownst to them? Or what if they've never heard of TailsOS, or they aren't technically capable of removing the hardware you mentioned from a laptop (Full disclosure, I'm not). In fact, I might even recommend they buy a new laptop that's never touched the interwebs (but NO! Now I'm recommending spending money... And a LOT more than the $200 they'd spend on a foundation passport.

Long story short, buy a HWW, however, you CAN use an offline phone coupled with a hot phone to store bitcoin.

This post is about saying something is POSSIBLE.

If you prefer not to, or have a different way... Sure... Do that thing. Don't come to this comment section just to fuck shit up.

21 sats \ 1 reply \ @nerd2ninja 15 Mar

We can go a lot cheaper.

https://selfcustody.github.io/krux/

Open source firmware under a mix MIT and Apache v2.0 licenses. Installs on a $48 device.

Now last time I looked at this, one of these devices had wireless onboard. Maybe I'm blind or not spending enough time looking or not searching the page for the right words or something, but it looks like the 2 named devices in their recommended devices list don't have wireless onboard anymore.

0 sats \ 0 replies \ @expatriotic OP 15 Mar

I'll check it out 🙏🏻👌🏻

reply on another page

100 sats \ 3 replies \ @doofus 14 Mar

A graphene phone is not more secure than TailsOS on an airgapped laptop to create a wallet, save the seed, then turn off the computer

0 sats \ 1 reply \ @ek 15 Mar

This, I wouldn't trust airplane mode

That's just a software switch

10 sats \ 0 replies \ @expatriotic OP 15 Mar

But LineageOS, GrapheneOS, CalyxOS is open source. No need to trust airplane mode. You can look through the code and see what happens when you disable wifi, bluetooth etc. Is it actually doing that or not? With Apple though... turning off wifi is annoying because it just toggles off (til later 🤦🏻‍♂️)

0 sats \ 0 replies \ @expatriotic OP 15 Mar

Okay 👍🏻

0 sats \ 4 replies \ @ek 15 Mar

Phones are much safer (or can be) than a laptop...

How do you come to this conclusion?

100 sats \ 1 reply \ @expatriotic OP 15 Mar

Sandboxing. With laptop qubes accomplishes this. With iOS or android, sandboxed apps is default. Yes you have to worry about apps getting permission to things like mic, camera, wifi etc etc in a malicious way, but the information between apps is sandboxed.

https://yewtu.be/watch?v=Wd4Pa03LvLk

https://ungovernablemisfits.com/podcast/exploring-sentinel/

21 sats \ 0 replies \ @ek 15 Mar

Thanks for the links, I will look into it when I have time.

21 sats \ 1 reply \ @final 15 Mar freebie

This is quite a short answer and you could explain these details for hours. Smartphones and their OSes are often designed with better security models than a desktop computer. Most of this comes down to a lot of societal factors, such as:

mobile operating systems like iOS and Android coming out decades after desktops so they naturally build a better foundation with the knowledge people have today.
mobile devices being more of a target due to their portability, prevalence, and the data people store in them being more sensitive therefore there is more effort to protect them.
mobile device security is far more scrutinized than desktops.

In a technical description, you'll expect a proper smartphone operating system to have an actual application security model, proper app sandboxing with permission controls, use of memory-safe languages for apps, exploit mitigations, verified boot and a lot of security principles (like least-privilege, assume-compromise, secure-by-default and defence-in-depth) adopted. A mobile OS gets criticized as being "locked down" and "restrictive" but that's also why they are extremely safe.

Mobile hardware (on a good OEM) is also better, they are always receiving complete firmware security updates and driver support until the device's support timeline ends. Sadly on Desktops you need to rely on the OEM doing a barely-decent job and if you are building your own you'd need to check every hardware device you build with has firmware updates / is supported. Firmware attacks are a big deal on desktops.

Where a desktop shares a security feature, the mobile device does it far better. One example is the secure boot in a desktop is not really comparable. x86 Secure Boot does not verify all firmware, does not have downgrade protection, does not have an unbroken chain of trust from the hardware and verifies far less of the OS than a proper Android verified boot device does. TPMs are also nothing compared to the dedicated secure elements used in a Pixel or similar either, and TPMs are rarely used for much by default regardless, while you'll see them used in Android and iOS for multiple things.

Desktop operating systems are flawed since they lack the security practices or a complete implementation of them. For example, a ton of Windows' best security features are opt-in so they don't get used, apps are not sandboxed and are over-privileged, often made in unsafe languages, most users' main accounts are also the administrator by default (and is the source of most Windows security issues), and much more. Windows wants to go adminless and move to Rust (great!) and also add sandboxing for Win32 apps (currently opt-in, not great!) but there's still a long way to go. Windows laptops with a half-done attempt at real secure boot instead of BS are Secured Core certified, but only an attempt doesn't really amount to anything.

MacOS on an ARM Mac does a great job in some of these things but there's room for improvement. Linux-based operating systems do this the worst as oftentimes they completely don't do some of the things listed or do it very badly. Linux works on Android because they barely use any of the same software a desktop distribution does, they also have an enforced SELinux policy among other additional work to secure it that the desktop operating systems do not. ChromeOS does the best of all of these for the same reasons as Android but of course being a desktop OS it doesn't do everything perfectly, but MacOS prevails with hardware.

This response isn't putting things like privacy-invasive telemetry of the OSes into account but obviously if you want to completely avoid it on a desktop your options are practically miniscule and you should accept some. I also avoided mentioning what GrapheneOS does better than Android here for neutrality but of course we improve on what Android does by a lot. When upstream gets a Desktop Mode there will hopefully be a future where someone could use a GrapheneOS device as a desktop and with VMs to run Linux or Windows apps thanks to hardware accelerated VM support in the newer PIxels.

I have no say in the discussion about using a GrapheneOS device as cold storage by @expatriotic and to be honest I haven't read it when writing this reply.

21 sats \ 1 reply \ @034b483ee7 15 Mar

Check out my series of articles Yakihonne on how implement cold storage using Veracrypt.

0 sats \ 0 replies \ @expatriotic OP 15 Mar

Veracrypt is awesome.

21 sats \ 0 replies \ @IamSINGLE 14 Mar

Wow amazing. I will try it out on 2 old phones. Let's see if that works.

21 sats \ 1 reply \ @pajdo 14 Mar

If you own only $500 of bitcoin, you’re doing it wrong.

52 sats \ 0 replies \ @StillStackinAfterAllTheseYears 14 Mar

Everyone has to start somewhere. Not speaking for anyone but me here, but I'd rather see more people get into Bitcoin, and not just have every sat get in the hands of the folks already on board. And that means some folks will have $500 worth.

21 sats \ 4 replies \ @DarthCoin 14 Mar

https://m.stacker.news/20811

https://i.postimg.cc/Qd11BYTK/safe-cold-storage.jpg

22 sats \ 3 replies \ @expatriotic OP 15 Mar

All these contrarian posts are tiresome. People completely missed the point of the post. That it's POSSIBLE. Full stop.

Your post is the only good one. Only one I bothered zapping. Thanks for being you Darth.

21 sats \ 2 replies \ @DarthCoin 15 Mar

Yes, I know. Not everybody is a Saylor buying in bulk. You can still secure your few sats with these tricks. An old device, a usb with tailsOS, a stegnographied image are enough if you know how to do it.

I even put 12 words in one of my guides! In plain sight. I dare you to find them if you can. If you can find the right order too.

I am an old bitcoiner. I used some HWW in the past. But I give them away to noobs. I don't need them. Why? Because I know and I tested my own methods.

21 sats \ 1 reply \ @expatriotic OP 15 Mar

We bow to sensei

0 sats \ 0 replies \ @DarthCoin 15 Mar

Think about another crazy scenario, in fucking plain sight:

you choose specific height blocks
in each one, you put a OP_RETURN with one word inserted into a simple sentence. Not just the word, will be too obvious for OP_Return watchers.
12 blocks in a specific order, that only you know it

See? You can recover that info anytime you want and nobody will know that is a seed right on the blockchain. And is there forever.

0 sats \ 1 reply \ @Coinsreporter 14 Mar

It's like what money we had saved for marriage, we end up spending that on our bachelor's Eve. Savin' $50 to $250 by not buying a hardware wallet, isn't the saving because you are suggesting that we end up buying a phone, which then turned into a HW. Wow 😲, thanks for suggesting. Great idea. You are a genius of managing and saving money.

0 sats \ 0 replies \ @expatriotic OP 15 Mar

Really? I suggested you buy a phone?

I merely said you would need two phones...

I never said to buy anything. It's a false premise.

Some people have two androids in their house. Old phones etc. One of them doesn't need to be a new model receiving updates since it's going to be always offline.

0 sats \ 2 replies \ @oomahq 14 Mar

Avoid Samourai and Sentinel unless you run your own Dojo backend (Dojo collects any xpubs you enter into these wallets).

10 sats \ 1 reply \ @expatriotic OP 14 Mar

Okay... Agreed. I run my own dojo...

But... do you tell blue wallet or wallet of satoshi users to run a node?

Do you understand that people using VPNs are just pushing trust from one third party to another?

I mean, you're right, but... 🤷🏻‍♂️

0 sats \ 0 replies \ @oomahq 14 Mar

Fair, it's always strictly better to self-host your own services than relying on an untrusted third party.

But wallets backed by an Electrum server only leak individual Bitcoin addresses at a time, that otherwise are not related together. But by sharing the xpub with the backend Samourai and Sentinel leak all past, present and future addresses that the wallet will ever generate.

0 sats \ 3 replies \ @justin_shocknet 14 Mar

There are so many issues with this post I don't even know where to begin

For anyone reading this, don't follow any of this advice except for this one line:

If you only have $500 worth of bitcoin, you probably don't want to spend $50-%250 on a HHW.

21 sats \ 2 replies \ @expatriotic OP 14 Mar

You could have taken a few more minutes to actually type helpful words, but you chose the path of non-information. 🚮

0 sats \ 1 reply \ @justin_shocknet 14 Mar

Lots of stupid shit gets posted on the interwerbs, no one has the time to refute all of it

Warning is only because particular post will cost people coin or worse if they're dumb enough to follow it

0 sats \ 0 replies \ @expatriotic OP 14 Mar

Cool bro, thanks for dropping in

0 sats \ 1 reply \ @GregAsks 15 Mar freebie

Just buy or make seedsigner. And then you can safely receive and send satoshi. And it's cheaper than the second phone 😂😉

0 sats \ 0 replies \ @satochip 14 Mar freebie

Although I agree with the plot of the subject, I don't agree with all the information it contains.

Indeed, most people don't need a $50-500 hardware wallet to store their Bitcoin, even with a 3-figure sum.

However, it's vital to offer simple, intuitive solutions for as many people as possible, and I think that starting to "tinker" with solutions on several non-trusted devices is more amateurish than a real storage solution.

Besides, there are solutions offering an acceptable level of security that could be suitable for most people.

I'm thinking of Satochip's hardware wallet, which comes in a $25 version... Their open-source solution is also available in DIY mode. For those without the requisite technical skills, there's also the bearer asset like OpenDime or Satodime - self-custody made easy.

100 sats \ 1 reply \ @wopwopwopwop 14 Mar freebie

deleted by author

0 sats \ 0 replies \ @expatriotic OP 14 Mar

Agreed, I use a HWW.

Some people own 2 android phones but no HWW.

This is a way to keep private keys that are on a phone cold. It can be done. Which is the point of the post. Your aggression is dumb. I'm just pointing out that it's a possibility. I didn't post this in bitcoin_beginners and say EVERYONE should do this.