As Pmalek said, it's more designed as a one-off "fund transfer" device... as opposed to a long term storage solution. Basically you can load it with a preset amount of BTC, and physically hand it to someone and they can:

1. check that the balance is what it should be (check public key/address balance via block explorer)
2. be certain you don't know what the private key is (check tamper seal is intact)

I could see them being useful for in-person trades... especially in high traffic times... you don't have to sit around waiting for 10 minutes for a confirmation etc. and you don't need to lug around a laptop or use a potentially insecure mobile wallet. Buyer can simply hand over the open dime and Seller can check the balance and confirm it's all legit (seal not broken) and then hand over the goods/cash/whatever.

Seller can then shift the BTC at their leisure (perhaps when transaction volume and/or fees are lower etc or when they're back at home with a more secure setup/wallet), knowing that the Buyer has no idea what the private key is.

Think I stumbled across someone farming posts with a couple of accounts... these two users seem to have a quick little 5 or 6 post conversation with each other (posts only a minute or 2 apart)... in multiple threads. Generally, only being very vaguely relevant to the OP/thread discussion:

User 1: wellay
User 2: juegav

Given how close their UIDs are (2759361 and 2759363)... being created 2 minutes apart and having pretty much identical stats... and the fact that ALL of their posts are "paired" together in short bursts, I'm about 99.99% sure it's just an account farmer trying to build up stats on a couple of newbie accounts (maybe hoping from some merits? )

The MO works like this... "wellay" jumps into a random discussion thread with some useless comment, a minute or so later "juegav" quotes and responds, then the 2 accounts back and forth for a couple of posts... then they disappear. For instance, Today's effort from this pair in a thread titled "If google has its own crypto currency?":

---

If you look at the post history of walley and the post history of juegav you can see they're always paired together...

I especially like the way that first juegav was shilling GetHashWallet 3 or 4 days ago to the wellay:


But then, supposedly needed to "have a closer look" today, after "wellay" was recommending it!

Both these accounts need to be nuked.

As per the other thread... it is FIXED by the 1.6.0 firmware.


Then you should probably consider alternative solutions for how you separate your device and your recovery phrase and/or the storage of your recovery phrase. It seems like you have doomed yourself to constant worry... you're either panicking that your device is going to reset and you're going to be stuck... or you can't update, because it might reset and you're going to be stuck... or that you might lose your device and you're not going to be able to recover... or you'll constantly be worrying that someone is going to break into your condo and steal your recovery phrase.

Good luck with that.


If you have NEVER tested your backup, then pretty much all this discussion is moot. You absolutely need to prioritise checking it to ensure you actually have a working backup before something happens (device stolen, device reset, device broken/lost, firmware update failure).

Being "almost 100% sure" means nothing unless you are 100% sure that it works... the number of people I'm seen on these forums who are "almost 100% sure" that they're using the correct password/passphrase/seed mnemonic... and being 100% wrong is quite staggering. These forums are littered with numerous threads about these situations.


Also, note that you no longer need to reset the device to check your recovery seed. Simply go to the "Manager" in Ledger Live and install the "Recovery Check" app... then open it on the device and follow the prompts. It doesn't reset the device or change the seed.

Basically, it lets you enter (what you believe is) your 24 word recovery phrase using the same method as during a restore and then it'll confirm whether or not the recovery phrase that you have entered will generate the same seed as the one currently being used by the device.

NOTE: You still CANNOT see what the current Recovery Phrase/Seed is... that is to say, it won't show you the 24 words or the current seed etc... it'll just let your enter 24 words and tell you whether or not the seed that would be generated from those 24 words is the same as the one currently stored in the device.

That way, you can be 100% confident that the 24 words you have written down are the 24 words you need!

As per the release notes, the "random reset" bug is fixed in the 1.6.0 update... it was an issue with 1.5.5 in some specific configurations:

...which is why it only happened to a subset of users. Unfortunately, I don't see any notes anywhere on what the "specific configurations" are that trigger the reset.

It doesn't damage the device as far as I'm aware, you can simply restore using the recovery phrase. Which would be annoying, but only really an issue if you don't have your recovery phrase handy and need access to your funds in a hurry etc.

I wonder if it is even technically possible for Trezor to enforce passphrases by default in their wallet? The passphrase functionality is currently "hidden" in the advanced settings once you get the wallet setup and I believe it actually sets a flag within the device so that the web interface asks for a passphrase during wallet unlocking.

So, theoretically, during the onboarding process, the web interface could simply set this flag and basically "demand" that the user set a passphrase... at which point, we'd most likely get users using substandard passphrases anyway... or thinking that they can simply "reset" the passphrase at some point like a computer password and end up forgetting it etc

I can understand the commercial reasons why Trezor are not that keen to "advertise" the flaw... after all, it's supposed to be a secure device... and saying "There is a massive hole in our security, but just use a long random password and you're all good" kind of negates that proposition and would scare off potential users (aka customers).

Meanwhile, more tech savvy users are savaging them on forums/twitter/reddit etc for this exact reason.

Certainly a reputational juggling act that I'm glad I don't have to attempt to perform!

Impossible to say with 100% certainty, but I would suspect that this would no longer be the case given the changes they've made to the firmware/infrastructure in more recent firmware revisions... I would think that Ledger would likely give warning if this was to occur.

The simple solution is simply check every 6 months or so to see if any updates have been released.



That would appear to be correct, from the Ledger Nano X support pages regarding battery life:

As the Nano S does not have a battery, so this "life expectancy" does not apply to the S.


That depends on:
1. Is it a "required" update?
2. How "urgent" the firmware update was (ie. is it patching a critical security flaw)
3. Whether I needed immediate access to the funds
4. The time frame for recovery should the device reset and I needed to use the recovery phrase

If it was super urgent and I really needed to use the funds, I'd probably risk an update without the phrase. For the most part, the newer updates seem to go through OK without requiring a reset. However, if it is just a "feature" update (providing new coin etc) and they're not features I desperately need, then I'd probably just wait and continue to the current firmware.


As a side note... and something you might want to consider, given what appears to be a very large physical distance between your "regular" location and your recovery phrase storage location... what happens if you simply break the device and need access to your funds? What recovery plan do you have? Are you comfortable with the time frames involved?

It's all well and good having the recover phrase stored offsite... but useless if that is at direct odds with your requirements for being able to recover in a reasonable time frame.

Predictions for the next 2 games...

Chelsea v. ManU: Will be a draw... either 0-0 or 1-1... it'll most likely be a fairly dour affair with a lot of defending. Neither team wants (nor can afford) to lose this one.

ManC v. West Ham: Could be an interesting game... City might be out to prove a point, West Ham perhaps sensing vulnerability. The decision against City might be playing on the players minds, but it could also be a bit like being reduced to 10 men... sometimes that galvanises a team and makes them more resolute. On the other side West Ham might see an opportunity to sneak a win against a "wounded" opponent.

I would suspect that ManC will run out winners, as they're still full of class players and, let's be honest, West Ham's defense is almost non-existent... City 2-0 I think.

You need to resync the Bitcoin Core instance where you are wanting to import the "dump file". That means you will have to redownload the entire blockchain WITHOUT pruning.

So, shutdown Bitcoin Core and make sure that:

1. There is no "prune=XXX" command in your bitcoin.conf or any script/shortcut that is used for starting Bitcoin Core.
2. If using GUI, in the "Settings -> Options -> Main" the "Prune Block Storage to..." option is UNCHECKED:


Then restart Bitcoin Core. It should automatically resync by downloading the entire blockchain again from scratch. (If not, try using the "-reindex" command line option)

NOTE: Current storage requirements for the full blockchain are around 300+ Gigs

Define "better"? What are your specific requirements for a wallet, such that you would consider using it an alternative?

Open Source?
Custom fee adjustment?
Multi-currency required?
Fancy UI?
Desktop/Mobile?

Without knowing what you actually want, it's difficult to recommend anything.

What do you mean "EPL has lost a strong opponent"? The ban is only with regards to the UEFA Champions League. It (currently) has no bearing on the EPL at all. It also doesn't come into affect until the NEXT season (2020-2021 season) of UCL football. City are still able to continue playing in the UCL this season.

So no EPL opponent has been "lost" as far as Liverpool are concerned.

In other news, after the win(dy!) at Norwich, Liverpool currently have a 25 point lead and now only need to win 5 more games to claim the title! w00t!

#YNWA

It's not as simple as a "Yes" or "No" answer... it all depends on your use case... There is no "one size fits all" wallet

For some, running a Bitcoin Core full node is the best solution
For others, Electrum works well and satisfies certain requirements
For other others, web wallets like b.info work well
For yet more others, exchanges like coinbase are the perfect solution
For oldschool others, paper wallets are the go to solution

That's why the Bitcoin.org "wallet chooser" asks a series of questions that includes the "Which criteria are important to you?" and "What features are you looking for?" sections

You still need SOMETHING to connect to it... You cannot send directly from the Ledger Nano X. As with the Nano S, you still need a computer or phone, it's just that with Bluetooth connectivity, you don't need an OTG cable to connect to your phone..


The Nano X obviously. It's newer and has more storage and features. There is a reason why the Nano S is cheaper than the Nano X

The only risk of doing an update with having your seed available, is that in the unlikely event of something going wrong and you having to reset the device, you won't be able to restore and use your Nano S until you have access to your seed again.

If the wallet is currently working and you don't need/require any of the new features from the latest update, then NOT updating to 1.6.0 probably isn't going to be problematic. This update was NOT a "required" update... Ledger Live and all the old features still work fine on the previous firmware (1.5.5)

As for life expectancy... where exactly did you get this from?
Who is "They" and where did "they" say this? Honestly, I don't recall seeing anything regarding life expectancy of the Nano S... certainly nothing official from Ledger. In any case, I would expect it to be similar to USB memory sticks... likely measured in write cycles...

So, unless you're constantly wiping and restoring the device, the persistent memory isn't being written to that often... and if you don't leave the device connected permanently, the screen is being used much either.

UPDATED:
User: HammaSan - BANNED
Reason: Plagiarism via a spinbot/textspinner

Unfortunately for this user, the problem with spinbots and textspinners is that they always output something a bit "nonsense" that makes them easy to spot:
Post has been Archived

LOL @ "customs mail"... when everyone knows the term being used in this case is "bonded courier".


Anyway... after some googling, I found the original article on the DailyHODL website here:
Original article has been archived

It seems you are still very confused as to the differences between private keys, public keys and addresses.


A private key... (in WIF format) starts with a "5", "L" or "K" and looks something like:


A public key... well that's generally just a string of HEX and looks something like:


Public keys can also be encoded as Addresses and begin with "1", "3" or "bc1" and will look something like this:


Which of the above do you have? private key? public key? or address?

No, nothing complicated like that... it's a simple "--testnet" command line argument... you can do it by creating a shortcut.

Only if you "break the seal" to reveal the private key... that's the whole point of an OpenDime... no one knows what the private key is until you physically pop the tamperproof seal. That way both parties can be sure that the OpenDime contains what the sender says it does (by checking the Public Key/Address)... and the receiver knows the sender can't later take the funds as they can check the seal to make sure it hasn't been broken so the sender can not possibly know what the private key is.

If you're using it for "long term" storage, you're taking the risk that it won't fail before you've popped the seal and extracted (and possibly backed up) the private key.

Your problem is that getnewaddress actually takes TWO arguments... the first is "label"... and the second one is "address_type"


So, what you have done is generate a bunch of the "default type" addresses and labelled them "bech32" and "legacy" and "p2sh-segwit". If you have a look in your "Window -> Receiving Addresses" list, you'll see a bunch of addresses with those labels!


NOTE: while it says "label" is optional, that really means you just don't need to populate it and can use an empty string ie. "". BUT if you're going to include arguments AFTER it, it still needs to be specified. You need to use the "address_type", so you MUST specify the label. This means that if you want to generate new addresses on the console you need to use:


NOTE2: setting the value in .conf file simply sets the default "address_type" that will be used if you don't specify anything when using getnewaddress command. You can still override that (ie. have address_type=bech32 in .conf, but use getnewaddress "" "legacy" on the console)

If you have the original wallet file, that contains the private keys for the address(es) you have received BTC to, then you will be able to send using that wallet file.

Again, if you DO NOT have the private key(s) or a way to recover the private key(s) for instance, by restoring using the seed mnemonic (aka 12 words) or by using a version of the wallet file that has the private keys in it... then you will NOT be able to access those BTC.


Because you don't have the private keys in the wallet to be able to sign the transaction (and you cannot broadcast an un-signed transaction).

Also, don't be alarmed if you get a "KeyError" when you receive a payment (and/or open a channel)... It seems to be a known (and fixed) issue, and doesn't seem to actually affect the receiving of the payments. They still show up.

If I get brave enough, I'll try and see what happens if I run it on MainNet