As far as I can tell... the "pairing" is dependent on the hardware wallet having the same "xpub" as what was used to create the wallet. I do not believe that it uses any other identifying features such as the device name or device ID number.

Theoretically, the only way for the xpub to change would be for the underlying seed to have changed...


You already tried "restoring" the wallet by recreating the MultiSig using the original co-signer xpub + your hardware wallet didn't you?

Yeah... I'm not terribly worried about the privacy aspect of using block explorers... simply because I've spent so much time in the tech support, beginners and the "wallet support" boards that if anyone was trying to associate bitcoin addresses to my IP, they would probably think that I "own" half of all the bitcoin addresses ever used!!?!

And to be honest, it's just out of sheer laziness... my node is txindex=1... so I could look them up relatively easily, I just prefer to use the block explorers because they have some "nice" features that usually make it "easy" (like linking to previous and/or next UTXOs/Transactions etc)

I should really just run one of the open source explorers and use that.

Thanks for the offer... but that's just not really feasible.

Testnet might be an option for my particular use case... but, for #reasons, the preference would be for "live" data on mainnet... at this stage, I think I'll just leave it and maybe look at it again when I have some more time.

@OP... perhaps try downloading the source from the "releases" section of the Electrum Github. This is a link to the oldest versions I can find: https://github.com/spesmilo/electrum/releases?after=0.59

You can "work forward" from there

Note that as there are no binaries listed there, you will need to download the .zip or .tar.gz and then run Electrum from the python sources... Also, you might run into issues with trying to find old versions of required libraries etc... and it probably needs Python 2 to run.

---

BIP32 HD wallets weren't... but Electrum has been using seeds and was a "deterministic wallet" since very early on (if not, from the very beginning)...

If you look at version 0.56 on Github: https://github.com/spesmilo/electrum/tree/10f41cbdfc3c8d0a7021467f629ee53a111a2f3c

The readme stats:

And this post on the Electrum ANN thread from November 2011 is talking about it being a deterministic wallet.

I would be interested to know how much of that 6 days and 15 hour sync was at USB2.0 and how much was at USB3.0?

I've been considering setting up an ElectrumX server... but if the sync is really that long, even using USB3.0, I'm not sure it is worth the time investment for what is essentially just a "test".

The major problem with "multicurrency" wallets is that they are always generally a massive compromise. Because they are not solely focused on one currency, they don't do any currency particularly well... they also usually lag behind when there are issues/changes involving a particular coin/blockchain that can lead to problems with stuck transactions, syncing or potential coin loss.

imo... Unless you are hardcore dealing with 10's (100's?) of different currencies, you'd be better off using wallets designed specifically for each currency.

While most of the more popular hardware wallets, Ledger and Trezor, support multiple currencies... I'd still rather use them in combination with currency specific wallets, rather than relying on Trezor/Ledger to implement features in their branded wallet suites (ie. Trezor Suite or Ledger Live etc)

The OP account is basically just a "shilling"/advertising account:
NOTE: all links purposely broken by me

None of the OP makes any real sense and half of it is factually incorrect... I would not trust whatever website this account was promoting.

It is an interesting question though... do any of the hardware wallet manufacturers actually explicitly state that the memory/secure element is securely wiped when you reset it (or exceed PIN retries etc)?

I mean, if we're already trusting that they don't have backdoors etc in their hardware/firmware... if they state their devices do this, it's not that much more of a leap to trust that they are telling the truth.

Still... physical destruction of the device is indeed the "safest" option.

So, you basically need a 51% attack... and for all the block explorers and "hosted nodes" etc to be in on this...

In which case, the answer to the question, as far as Bitcoin is concerned, would be "No.".... not unless the so-called "blockchain elite" want to tank the price of Bitcoin and make it pretty much worthless, rendering their "elite" status null and void.


Personally, I don't think the "elites" are as coordinated as well as Vitalik thinks they are... otherwise we wouldn't have ended up with BCH, BSV, BTG, BTCD and all the other forks and "competing" chains.

Quoted and verified with Electrum:

Assuming these code snippets have all been copy/pasted here and not typed by hand... are you sure that your "a>0" check is correct? Seems like it should be "a<0" as per the Ruby example.


Also, the your lines:

Won't work... because in Ruby the assignments/evaluation in the following code:
happens in parallel... so you'll need to use some temp variables to hold the "old" value of y and a...

ie.

Otherwise your final values of prevy and m will be the wrong values.

There was an altcoin back in 2018 called Bitcoin Flash (BTF)... but it's a dead project as far as I can tell.

So, I've no idea what this particular incarnation of "Bitcoin Flash" is.

From what you've described, it seems like some sort of mechanism for scamming newbies who don't understand the dangers of zero confirmation transactions... whereby you can convince them that you've sent them X BTC (perhaps they have some sort of fake "blockexplorer" etc)... You then get them to send a bunch of goods, altcoins or fiat etc... and then the transactions all "disappear" after 90 days, by which time you've also disappeared.

Hopefully this thread gets index by Google so when people start googling "Bitcoin Flash" they find this thread.


Theoretically, you could push a transaction (or chain of transactions) into the mempool indefinitely... and when I say "the mempool", you have to remember that there isn't just "one" giant shared mempool, each node maintains their own mempool (with their own acceptance/rejection and retention rules).

But, assuming your transaction does not get included in a block or becomes invalidated by UTXOs being spent/confirmed in other transactions... someone could just keep rebroadcasting the transaction indefinitely... and your transaction could just keep floating about forever.

If the mempool emptied out and/or fee rates were back to 1sats/byte levels... this would in extraordinarily difficult to do tho.

^--- THIS

If you don't want the rug pulled out from under you... don't stand on the rug or make sure it is secured to the floor.

Options are incredibly limited in this case

Pretty much the only way to get this sorted would be to manually craft a "competing" transaction and then get a miner to include it manually in their transaction pool.

Attempting a double spend is going to be very very difficult. The vast majority of nodes will outright reject it, so network propagation will be very limited, assuming you can even find another node that will accept it in the first place!

Personally, I would be trying to contact some of the major mining pools to see if they would even consider this request. 1.5 BTC is quite a substantial loss... condolences.

The lack of definition of what Point A and Point B are, seems to be causing some issues...

If Point A and Point B are both owned by the same person, then restoring the seed on the Point B device is possible... however the coins will still be associated with the same addresses/public keys. All you are doing in this instance is "cloning" Ledger1 onto Ledger2.

If Point A and Point B are owned by different people, then restoring the seed on the Point B device is NOT recommended. You're effectively handing your entire wallet to the other party!


If the goal is to actually get coins from one particular wallet (owned by person 1) to another wallet (owned by person 2)... note that it doesn't matter if these are software wallets, hardware wallets etc... then you have no option but to create an on-chain transaction... which leaves a trace. It has to, because Bitcoin operates on a public ledger.

So, you will need to obfuscate the transaction in some manner. You choices for this are:

1. A bitcoin tumbler or mixer
2. Converting coins to a "privacy coin" and sending that (eg. Monero)
3. Using Coinjoin

The Core team had the certificate they used to sign the Windows Binaries revoked because of an issue with the Certificate Authority: https://github.com/bitcoin-core/gui/issues/252#issuecomment-802591628

So, the choices are:

1. Let users try and run the "signed" installer and get scary Windows warnings unless you run it as an admin
or
2. Tell users to run the "unsigned" installer.

Note that this issue is only affecting "Windows Code Signing"... versions on other OSes are unaffected... and you can still check the SHA256 hashes and verify them with GPG signed checksum file: https://bitcoincore.org/bin/bitcoin-core-0.21.1/SHA256SUMS.asc (which you should be doing regardless of whether or not the Windows code signing is being used)

Errrrr... that's not a wallet file... that's the actual Bitcoin Core source code. Another red herring I am afraid


You can see the code in walletdb.cpp here that is matching your screenshot:

Might need to try contacting Trezor support on this one... I've just tried a couple of quick tests with Electrum+Trezor ONE (I don't have a "T")... I created a 2-of-2 Multisig using the Trezor as one of the co-signers... then shut it all down and "renamed" the device in Trezor Suite... Then I disconnected everything, started Electrum and tried to open the MultiSig... Electrum still asked for the device labelled "OldName", but when I connected and unlocked the device with "NewName" it was still able to pair with the device and the wallet was available without issue.

I was even able to "restore" a copy of the multisig wallet by using the xpub+TrezorOne... and it created a wallet with the same addresses etc.

So, either this is some sort of Trezor T specific issue... or something else has happened with your setup to cause it to think that the wrong Trezor device has been attached. Do you have "passphrases" enabled on your Trezor device? If so, is there a possibility that when you first setup the MultiSig you unlocked the device using a non-blank passphrase?

Hopefully  Trezor support can help you figure out what the issue is.

Seems that:

- You have used a relatively low fee (6 sats/byte) when transaction fees have been relatively high due (50-100+ etc) over the last few days due to the massive price crash causing a flurry of transactions.
- Your transaction is unfortunately not marked as RBF (Replace By Fee), so you cannot "bump" the fee
- Your fee is too low to use the one working "free" transaction accelerator (https://www.viabtc.com/tools/txaccelerator) as they require a minimum of 10 sats/byte.


Your options at this point are:

1. Wait... the transaction fees have been slowly decreasing over the weekend... If things continue on this trend over Sunday, you might find your transaction is confirmed in a block before Monday.

2. Pay for one of the ridiculously overpriced "pay" transaction accelerators. You'll pay a HUGE premium for this though... pushtx.com want ~US$100 to accelerate this transaction:


3. Try and execute a CPFP (Child Pays For Parent) transaction... you would need to spend the "change" from your transaction that went back to your wallet, but spend it with a HUGE fee to make the total fee rate across the 2 transactions to be at least 30+ sats/byte (at current fee rates)

So either the output that was sent to:
1PZxFDvHdcwn71URz12vr2iaXvsrFNVNfz
or
16snBgigUF6x1THE8hmnmAx8aaqpPgR2gQ

(I would guess it was 16snBgigUF6x1THE8hmnmAx8aaqpPgR2gQ)

This will be complicated by the fact that your transaction is using Legacy addresses, so the size is quite large compared to SegWit based transactions But basically, you current transaction is 373 bytes... the CPFP is likely to be 192 bytes (best case scenario for 1 input/1 output)... so in total, you're looking at 565 bytes total... at a "good" rate of 30 sats byte... your total fee would be: 565 * 30 = 16950 sats... you've already paid 2184 sats... so you need to pay 16950 - 2184 sats = 14766 more...

so, assuming 1 input/1 output 192 bytes, you would need to pay 14766 / 192 ~=77 sats/byte fee for the CPFP transaction.

---

I would recommend you try #1 and just wait to see if the fees drop low enough over the weekend to get your transaction confirmed. If it doesn't, then you can investigate option #3

Note that unless you are super confident with what you're doing, I would not recommend #3... You might just end up getting a 2nd transaction (and more of your funds) stuck in a low fee transaction if you don't do the calculations correctly!

A fully synced, NON-pruned Bitcoin Core is absolutely required for Armory to function properly.

This will likely require several days to complete... and will also require 350-400gigs of disk space for the block storage (you CANNOT use a "pruned" node with Armory).

However, I concur with nc50lc... installing Bitcoin Core, fully syncing the blockchain, and getting Armory communicating with Bitcoin Core is the "safest" way that you can get access to your coins, even if it might take a day or three to get it all hooked up and working.

Exporting private keys and importing them into other wallets carries significant risk unless you have fully air-gapped computers which you know (and can guarantee) to be 100% malware free.

Think of it this way... you've survived years without those 2 BTC... no sense risking it all just for the sake of a day or 2!