Does the Ledger Nano S work correctly if you use Ledger Live? If not, then maybe try following the MacOS troubleshooting here: https://support.ledger.com/hc/en-us/articles/115005165269-Fix-USB-connection-issues-with-Ledger-Live?support=true

If it normally works with Ledger Live OK, did you have Ledger Live open and running when trying to use Electrum? Often, having multiple applications that are attempting to communicate with the Ledger device at the same time will cause problems. I've had issues in the past with Electrum being unable to communicate with a Nano S if Ledger Live was running. So, make sure Ledger Live is not running before you start Electrum and see if that helps with the communication process between Electrum and the Nano S.


NOTE: I have a Ledger Nano S and a Trezor ONE, and am able to use both with an Electrum 4.1.5 MultiSig "OK"... but I'm running Windows 10.

This is very confusing to me... I can only assume it is a derivation path issue (or possibly a script type issue? ). If you have the same key + same derivation path (and script type), then you should be getting the same addresses.


However, I think the issue might be because DELTECHE is trying to use the xprv... when you use Master Private Keys (xprv) with Electrum, it doesn't give you the ability to select the derivation path.

In a quick test I just did... starting with an 18 word BIP39 seed:

This generates the following addresses in Electrum (using 'BIP39 seed' option, legacy addresses and derivation path m/0'):





Now, if I look at Ian Coleman... same 18 word seed, using BIP32 tab + MultiBit HD from the "client" options:



We can see the exact same addresses:

---

---

However, if you try and take the "BIP32 Root Key" from Ian Coleman:



That generates this in Electrum:

---

And the "BIP32 Extended Private Key" from Ian Coleman:



Generates this in Electrum:

---

---

Essentially... if you want to take the xprv for a MultiBitHD seed from Ian Coleman... and make it work in Electrum... you need to do this:

Set the "BIP32" tab, to use a "custom" client... and set the derivation path to m/0'



Then take the "BIP32 Extended Private Key":



Paste that into the "Standard Wallet" -> "Use a master key" option in Electrum:


And that will generate the same addresses as the seed does:

---

---

Or just do it the stupidly easy way... and use the seed + 'BIP39 seed' option + Legacy + m/0' derivation path directly in Electrum and save yourself a lot of time and bother

---

Ok, firstly... please forgive the double posting, but I feel like this very important information might get lost in my very long previous post!


For better or worse, I contacted the user via Telegram... mainly just to let them know I had posted my big long post regarding seeds/xprvs and MultiBit HD... and they sent me a screenshot that revealed the user is actually using some very dodgy looking "MultiBit Core"... (https: //multibitwallet . org/index.php ) a complete scam that looks like a clone of the old "bitsblock . io" scam... creating a wallet that looks like Bitcoin Core, but supposedly has an 18 word seed recovery system.

It has so many dodgy red flags tho... You sign up and get emailed your 18 word recovery phrase!!?!


Refer: https://bitcointalk.org/index.php?topic=5230464.0 and https://bitcointalk.org/index.php?topic=5225197.msg53854675#msg53854675

[moderator's note: consecutive posts merged]

As goatpig has mentioned, without being able to see the log files, it's going to be very difficult to understand what exactly is happening with your setup. Are there any obvious errors in the log files?


Also, no idea why your whole computer is "freezing"... That isn't a normal situation, so possibly indicative of something other than Armory or Bitcoin Core causing issues I've had Armory basically "freeze" (or seem like it has frozen) during the initial sync/scan... but the rest of the PC was functioning just fine.

I can confirm that this is indeed the case. I have been running Armory 0.96.5 and Bitcoin Core v0.22 without any major problems.


Definitely ran into this error tho!

I'd have to agree with Pmalek... it really depends on how big your business currently is, and how big you think it might grow. If the number of clients you have is measure in single or double digits, then you can probably get away with simply using a "standard" Bitcoin wallet (like Electrum or Bitcoin Core), possibly with the use of a hardware wallet if you think that you'll be getting hundreds or thousands of dollars worth of income. Hell, buying a hardware wallet would probably be tax deductible!

However, if your agency has hundreds of clients, you might be better off using a payment processor of some description. Whether you want to go for a "zero fee" self host solution or pay ~1% fee to something like Coinbase or other commercial payment gateway would be something you would need to decide based on your particular circumstances. Do you have the knowledge/skillset/equipment/bandwidth to be able to setup and maintain a full node and payment gateway like BTCPay Server? Do you have the time? Is 1% low enough of a cost for the convenience of not having to deal with it?


If you're currently small, but plan on getting big, you can always start with a simple wallet, and upgrade later as you expand. You're not really tied into anything permanently.

You weren't using Bitcoin in Dec 2017/Jan 2018 were you? Or indeed, for the first 4-5 months of this year?

It would seem not:


Well, to answer your question, this graph shows the size of the mempool... basically, the amount of unconfirmed transactions... remembering that as a rough guide, 1 meg = 1 block worth of unconfirmed transactions.

source: https://www.blockchain.com/charts/mempool-size

You can see that the mempool at some points had in excess of 80 blocks worth of transactions for months on end.

So, basically, confirmation times for low fee transactions will stretch into days/weeks rather than minutes/hours. There are literally hundreds (if not thousands) of threads on this forum in the "Beginners & Help" section (and littered in the Tech Support section) about "stuck transactions": https://www.google.com/search?q=site%3Abitcointalk.org+stuck+transaction

A very confusing answer to be sure...

User1: "It's bad for the environment to destroy perfectly functional drives, you should zero it and reuse it"
User2: "I agree, I smashed my harddrive with a hammer"

Ummm what??!?


Still, the amount of time required to properly zerofill a drive can be quite massive... especially when you're talking Terabyte+ sized drives!    whereas... 5 minutes and a hammer? 

Indeed... anecdotally, I have seen so many stories on this forum over the last 4-5 years of "small children" that destroy backups (ripping paper, scribbling in notebooks etc)... and, from memory, one or two involving animals. Also, a few with "bad handwriting" where they can't decipher certain characters... and spilling of liquid onto papers is another.

It's not small bitcoin or big bitcoin... it's the fee rate as mentioned above... that is to say, the number of sats per (v)byte that a given transaction is paying that will generally determine any given transactions priority.

They only have a finite amount of space in a block, so by including transactions paying the highest "rate" (not necessarily just a large total fee amount), they are more likely to receive the optimal payout for finding a block.

For arguments sake, if you only have 1,000,000 bytes of space... and you have 1 transaction that is 1,000,000 bytes and pays 0.01 BTC in fee... you think, that's a BIG fee... I'll use that one... well, the actual fee rate on that is 1,000,000 sats / 1,000,000 bytes = 1 sat/byte.

If you have 10 transactions of 100,000 bytes each paying 0.002 BTC in fees... then because their rate is 200,000 sats / 100,000 bytes = 2 sat/byte... you're better off taking the multiple "smaller" transactions with the larger rate. 10 X 0.002 = 0.02.


Outside of the logical choice being to maximise the amount of fees received, miners are essentially free to do whatever they like with regards to prioritising transactions... for instance, a miner could elect to ignore any transaction going to a specific address or group of addresses if they really wanted to... they'd be foolish to do so, because they'd be ignoring potential income, but they could do it.

Leave it. It should come back to life when it finishes whatever it is doing. Bitcoin Core can look non-responsive for periods of time when it is validating blocks. What are the specs (CPU/Ram etc) of the machine you're running Bitcoin Core on?


What are you wanting to do with your wallet? Just send and receive coins? or are you looking at leveraging a full node for running services like a block explorer etc?

You've been told multiple times, by multiple people... Your money is gone.

You're not getting it back. You never will. You're not getting any bitcoins either and you never had any to start with. You need to accept that your $56 is lost. Gone forever.

It's only "strange" because we generally consider Bitcoin addresses to be a mix of all the Base58Check characters... but it's really no different to addresses missing a given set of characters. For example: addresses missing the characters [b, B, i, t, T, c, C, o, i, n, N].

Basically, it is impossible for all addresses to contain all the characters... so there are always likely to be groups of addresses that are missing a given set of characters (assuming that set is relatively small).

It has only been 3 or 4 days... so don't give up all hope. Give it a week or 2 and see if you get any response.

If you still get nothing after a few weeks, then it looks like you've learned a very unfortunate, very expensive lesson about bitcoin

Yeah, the issue being that Electrum is trying to support Lightning... which is where I believe the "expiry" time has more relevance. Unfortunately, this ends up being very confusing for new users who suddenly think their "receive address" is going to expire if their transaction doesn't confirm quickly (hence all the posts from users when the network is overloaded and transaction confirmation times for low fee transactions blow out to hours/days).


Personally, I also like the idea of making it an "advanced" feature like with the "Pay" dialog and the advanced preview option... and I think it should be disabled by default (like the advanced preview).

That would probably be more than enough then... as most of the articles I've read (granted none were written within the last 2 years) would indicate that once or twice a year should be enough to keep the "bit rot" at bay

I have one or two SD cards that I'm fairly sure hadn't been plugged into anything or powered up in any way for a couple of years (sitting in storage) and they were "OK"... not sure I'd do the same for crypto backup storage tho

For sure... that's why I said not for me and my use cases. I do like the idea of using Tasker and I had indeed had the same thought as o_e_l_e_o about leveraging it's "geofencing" abilities. It takes the onus off the wallet developer and allows a user who wants it to protect themselves... however, I still don't think there is a huge market for "people with low willpower who need a wallet that stops them from spending".

But I do see the "security" side of it... accidentally leave your phone on the table in the cafe? No worries, even if they get it unlocked, they won't be able to spend because the phone isn't in your "geo-fenced" spending area. You'd just have to hope they can't figure out how to crack the wallet and export your seed/keys... which would render any wallet level protection meaningless.


It's a fine line for wallet developers though... If you put too many fences up, even optional ones, users will simply throw their hands up and cry "arrrgh, too difficult" and move on... and if you don't enable those options by default, users generally won't enable them themselves... and then complain "why didn't your wallet stop me from being stupid?"

Honestly, it's a lose/lose proposition

I doubt I would trust any "second hand" hardware wallet... configured with a seed or not. Unless you're willing to crack it open and inspect the hardware (and there are sources available to indicate whether it has been tampered with) and you can reflash the entire firmware, one could never be sure exactly whether or not the unit had been modified in some way.

I think i'd be approaching Jerry levels of paranoia if I purchased a 2nd hand hardware wallet!

That does indeed change the situation. Not having the password and requiring it to be brute forced is indeed more of a specialist task


Not necessarily. While it isn't impossible to setup and run something like hashcast or btcrecover etc... the problem comes from the performance of "typical" hardware that most users have, or, more correctly, the lack thereof. The equipment necessary to bruteforce anything but relatively simple wallet passwords can be quite expensive to buy or even rent. Given the sorts of passwords I use, even my gaming rig with a relatively powerful GPU isn't going to cut it if I needed to bruteforce one of my passwords. So, don't feel like you're being judged for seeking professional assistance. Very happy you managed to find a reputable firm that didn't scam you.

I still think that the fee charged was excessive tho


Truly a "good news"™ story all around.

In a word, No.

Danny's idea of monitoring it on a number of nodes on an isolated LAN would yield "lab quality" data, but won't give you an idea of "real world" performance. Theoretically you could try and setup 2 nodes that in geographically different locations to try and ensure they are not directly connected and then measure the time between one node broadcasting a transaction and the other node receiving it... but, as Danny pointed out, there will be no way to know exactly how many steps/nodes are between your 2 nodes. It could be 0, it could be 100.

There is also the likelihood that the traversal path could change as nodes drop out and/or come on line. It's a dynamic network.

Additionally, you'd only really be monitoring what the latency is between those 2 specific nodes. It won't necessarily be indicative of the "average" latency experienced for any given transaction/node.

I'm still confused as to what happened with the "scam" script??!? Did this interiawp person write a script that supposedly "stole" some bitcoins or did he just write a script that didn't do what COBRAS wanted??!?

I've read the messages like 4 times and I'm confused!!?!