Oh well... as Lucius said, I'm not that big into Alts either... so it isn't a 'huge' deal... more of an annoyance than anything else. Hopefully the announced ETH update will improve things... hoping to at least get back to the number of apps I had previously.

The Nano S is a great device (as is my Trezor One)... and I just don't see enough benefits to justify spending the money being asked for the Nano X (or the Trezor T for that matter).

Have you reported any of the actual posts? I've tagged the account... although I can't tell if I'm actually DT2 or not, so I'm not sure what good it will do.

I don't think they're "bumping" as such... but definitely spamming/shilling their masternode portal on pretty much every Altcoin ANN thread.

I'd have to agree... combing HW, multi-sig and airgapping seems like total overkill... especially given that HW are designed to be used (safely) in an online environment.

It seems to be a "common" issue with Mycelium at the moment, since their update to include SegWit... It would appear that there are "syncing" issues with the wallet and/or servers, so users are not seeing all their transactions or their transaction history is suddenly disappearing... then reappearing hours later when re-opening the app or using the "reload"/"resync" options in the settings.

As long as you can see the coins still in your address on a block explorer, then your coins are most likely "safe"... and it's just a "display" issue within Mycelium.

If the issue continues, maybe try logging an issue here: https://github.com/mycelium-com/wallet-android/issues

As I was trying to explain via PM... you need to provide some sort of context to this script...

What site was it being used on? And what is the underlying logic? It isn't just an easy "copy/paste/change a couple of variable names" to convert this Javascript to a functioning LUA script for the dicebot that has the same functionality.

What I am fairly sure of is that the dicebot script that you tried to write doesn't do anything close to what that Javascript is attempting to do... the "numbers" just don't match.

After I finally got the firmware update installed... it seems to be a bit better about 20-25 secs to uninstall an app... and around 20-25 seconds to install an app.

What hasn't got better is the number of apps that can be installed. Prior to the update (ie. on the 1.4.2 firmware) I had BTC, BCH, BTG, DOGE, LTC, ETH and STELLAR installed... as well as the "Recovery Check" app.

Now, if I install BTC (and 2-3 of the BTC derivative coins) and ETH... I can't install anything else at all

That is a severe downgrade and worse than the original Ledger problems. I believe it is the ETH app that is causing the issues... without it, I can install BTC (and all the derivativee coins BCH, BTG, DOGE and LTC) and STELLAR and the "recovery check" app.

Seems like 1 step forward 3 steps back for each Ledger "update".

Basically, it is really only the "big" cryptocurrencies (ie. ones that are actually worth something or have a LOT of users) that exist within Ledger Live. Also, ones that are technically easy to integrate. While that's not true in ALL cases, it is for the vast majority.

There are just so many "worthless" currencies, with little support, that it just wouldn't be worth the time and effort integrating them. Much easier to enable support with existing wallets and let users access them that way... like you can with Ethereum and MyEtherWallet/MyCrypto.

If currency finds enough support and userbase... I'm sure Ledger would look at integrating support directly into Live.

This is probably the best piece of advice I have read in any thread, on any board, on any forum... ever.

It's like the digital equivalent of taking a deep breath and counting to 10.



Two days? That's being a bit optimistic

I don't see any digital goods section in the Alts board? I see the main Marketplace (Altcoins) and 3 sub-boards being "Service Announcements", "Service Discussion" and "Bounties".



I would assume that any offers to buy/sell would go into the main Marketplace board, unless you are a service provider trying to promote your service... in which case "Service ANN" is probably the best place.

I'm getting  time out errors.

Ledger Live just sits on the "Allow Ledger Manger on your device" for several minutes after clicking the "yes" option on the device... and eventually the time-out error occurs. I assume that this is most likely because the Ledger servers are being hammered by everyone trying to update and failing (and all the "MCU Firmware not genuine" errors causing panic and people reinstalling etc).

I am becoming more and more discouraged by the "quality" of Ledger and their software and updates. Things just seem to be going from bad to worse.


NOTE: after several retries, I finally managed to get "Manager" opened... it is taking nearly 2 minutes to uninstall each app

Not all Cryptos are support natively inside the Ledger Live app (ie. you cannot create a wallet in Ledger Live) and you need to use in conjunction with a 3rd party wallet... Stellar is an example of this.

If you don't see the crypto you want listed in the drop down menu when you try to add an account in Ledger Live, then it isn't natively supported. It would appear that TRON also requires the use of an external app/website. Refer here: https://support.ledger.com/hc/en-us/articles/360006904193-TRON-TRX-

NOTE: Pay particular attention to the warning about the Troscan Desktop software for windows! Only use the Tronscan website.

Just FYI, creating a "receive" record is not required, and doesn't affect anything at all... this is completely unnecessary to "receive" bitcoins. All this feature does in effect, is create an "invoice" that you can send to someone to make it easier for them to know the address to send to, and the amount of BTC to send. Kind of like how Bitpay send you a link you can click on and it shows all the address and amount information when you're trying to pay a merchant.


If you are seeing this message... then it means that none of the addresses used as inputs or outputs in this transaction are addresses in your W3 wallet.

The most likely reason is that you have sent bitcoins to the wrong address...

Check the addresses tab in W3, do they start with "1", or "3", or "bc1"?

My guess would be that it is the Hardware Wallet plugin attempting to connect and failing because the computer is offline...

Most likely because the HW wallets like to connect and refresh transactions/balance on startup. You might get a better response if you post your query on the Electrum Github issues list if you haven't already.

You were good up until this point...


And then ruined it here...

By connecting it to any network for any period of time, this should no longer be considered a "cold" wallet.


Most likely, assuming other precautions are taken... it will be "OK" from a security point of view... but by connecting this laptop to the network, you are effectively removing ALL of the safety barriers that a true cold wallet provides.


Given that it would take a piece of malware mere milliseconds to send your wallet.dat and keylogged password to a thief, it makes no difference how long it is connected for... if you want to properly implement the cold wallet setup, the laptop should NEVER be connected to any network after it has been setup.

You should run the "online" watching-only wallet (with just public keys) on your daily computer... then the process would be:

- create unsigned transactions on online wallet (it has updated wallet balance/transactions)
- transfer unsigned transaction to offline wallet using a USB stick
- sign transaction on offline computer with private keys
- transfer signed transaction back to online wallet using USB stick
- broadcast signed transaction

At no point, should your offline laptop be connected to a network if you want to consider it a proper cold wallet.

Thanks for taking the time to update. Also, just to clarify... that was a full reboot of the PC?

If so, I would guess that there might have been a "ghost" process that hadn't ended properly during all the opening/closing of Armory... I'll try and make a mental note of this as a simple troubleshooting task for any future issues users might have.

To answer this question... As I understand it... No, the transaction does not go through. All the "bad" servers do is throw back the fake error message and encourage the user to download malware. (NOTE: I believe the github repository that it linked to has already been removed)

So, as Abdussamad mentioned, simply ignore the error and connect to a different server. If you do that, there is no danger to your wallet or coins from this "attack".

Yeah... that was kinda my point.

Unless you have the actual seed mnemonic (or the seed generated from that mnemonic)... you cannot simply convert an xpub to a ypub (or zpub) and start generating the same P2SH-P2WPKH (or bech32) addresses that you would get if you started from the seed in the first place.

the xpub will be generating keys on the m/44'/0'/0' path... so an xpub-to-ypub conversion will also start generating keys/addresses from that same path... whereas, the "real" ypub that you would normally generate from the same seed would (should?) have started generating address from the m/49'/0'/0' (and a zpub from m/84'/0'/0')


In short, you can't convert "properly" without the original seed (or seed mnemonic)


Most wallet apps that I know of only allow a single xpub per wallet. ie. You can't open a wallet file and import multiple xpubs... However, Mycelium allows you to import multiple xpubs(/ypubs/zpubs)... it's a bit "hidden", but it works... You need to copy/paste the xpub/ypub/zpub... and then within Mycelium use: "Add Account -> Advanced -> Clipboard".

I've just created a new wallet in Mycelium that has the main "HD-Account" from a normal seed mnemonic... and 3 "imported" watching-only accounts using the xpub, ypub and zpub that I posted above.

However, I'm not sure if this will be of any use to you in the long run if you're attempting to setup some sort of airgapped system, as you can't generate an unsigned transaction from Mycelium and then transfer to another device to sign etc.

Looks like the "installed" Electrum app has been lost in the update... to check if your wallet is intact, you would need to see if you still have a ~/.electrum folder.

Check the instructions here and see if that folder still exists: http://docs.electrum.org/en/latest/faq.html#where-is-my-wallet-file-located

If it does, and you can see you wallet file, reinstalling the latest version of Electrum from here should enable you to view your wallet without needing to restore: https://electrum.org/#download
If that folder doesn't exist, then it seems like the update has wiped your user data and you would need to restore the wallet using your seed mnemonic.

It has nothing to do with the version of the Electrum client that you have installed/are using... it all depends on which Electrum server you get connected to.

Also, I believe that the message only shows when you attempt to broadcast a transaction.

The message is generated and sent by rogue Electrum servers that have been setup and launched by the attackers. They modified the (open source) code, so that regardless of your client and/or how your transaction is setup, the server will automatically return the fake "error" message to your client encouraging you to "upgrade". Then the attackers launched hundreds of servers (using different domains) to increase the odds that a client would get automatically connected to one of their servers.

So, if you automatically (or manually) connect to a "good" server, you will never see this message... and if you're connected to a "bad" server, but don't try and broadcast a transaction, you will not see this message either.

To be honest... I don't think that converter is doing what I thought it might be... on delving into the code... all it does is strip the 4 version bytes and replace them with new version bytes. So, while it is converting an Xpub to a Ypub for instance, it isn't the "matching" ypub...

From the SLIP-0132 Test Vectors:

However, that converter converts:
xpub6BosfCnifzxcFwrSzQiqu2DBVTshkCXacvNsWGYJVVhhawA7d4R5WSWGFNbi8Aw6ZRc1brxMyWM zG3DSSSSoekkudhUd9yLb6qx39T9nMdj
to
ypub6We8xsTdpgW67F3ZpmWU77JgfS29gpX5Y2u6HfSBsW5ae2yLsiae8WAQGaZJ85b1y4ipMLYvSAi Y9Kq1A8rpSzSWW3B3jtA5Na1gXzZ8iqF

instead of:
ypub6Ww3ibxVfGzLrAH1PNcjyAWenMTbbAosGNB6VvmSEgytSER9azLDWCxoJwW7Ke7icmizBMXrzBx 9979FfaHxHcrArf3zbeJJJUZPf663zsP


I believe what it is doing, is converting the m/44'/0'/0' derivation path xpub to a m/44'/0'/0' derivation path ypub... in other words, it'll be deriving P2SH-P2WPKH addresses using a derivation path of m/44'/0'/0' instead of the "correct" derivation path of m/49'/0'/0'... I'm not sure if this is the behaviour you were actually wanting, or if you want to be able to convert a m/44'/0'/0' xpub to a m/49'/0'/0' ypub (or m/84'/0'/0' zpub)...