Given the current size of the mempool and the fees in play at the moment... the OP really has little option but to just sit and wait As calculated, the maximum fee they can possibly reach with RBF is only around 4 sat/vbyte total... and there are around ~25-30 blocks worth of transactions that have higher fees than that.

The only other option available would be a "Child Pays For Parent" (aka CPFP) transaction... whereby they spend that 0.00002376 BTC change output in a transaction that pays a comparatively HUGE fee (like 120+ sats/vbyte) to try and push both transactions through, or get the recipient of the ~1.52 BTC output to try the same.

Bitcoin Core has coin control, so creating a transaction that spends that change output should be relatively simple.

Looking at debug.log we see:

Not sure exactly what version=0x3fffe000 is... but apparently some of this is related to "overt" ASICBOOST

I think it would be somewhat interesting to see what the last 24 hours have done to that chart

The massive spike in value of BTC has no doubt caused some significant movements (both up and down) in the altcoin sector... I think my beloved XRP might have finally be ousted from top spot!

No, that isn't correct. Prior to Ledger Live there were still multiple ways to confirm if your 24 word phrase was correct...

1. you could note down the receive address... then wipe the device and restore it using your written down seed... then check the receive address. Same address == correct seed
2. You could restore the seed onto a different hardware wallet (ie. a second ledger or another BIP39/44 compatible hardware wallet like Trezor)... check that addresses match.
3. You could restore the seed into a BIP39 compatible software wallet (preferably offline)... and check the addresses generated match
4. You could test the seed using (an offline copy of) IanColeman's BIP39 mnemonic converter and check addresses generated

Obviously, some of these methods are more "secure" than others.


Theoretically yes. The data entry is on the device, so the computer being infected shouldn't matter. In fact, to be "extra" safe... you can actually connect the device to a USB charger, and initialise it that way... so it isn't even connected to a computer when you set it up.

Just quoting this address for reference...


And also quoting the post of the "staked" address:

which has been "verified"

NOTE: message seems to have originally been (incorrectly) posted with 2 extra newlines in the signature section

If you can't afford another similar incident... then I'd seriously reconsider your entire methodology regarding withdrawals for customers...

I realise you like the idea of offering "instant" withdrawals... but creating a long string of small fee transactions obviously comes with some downsides if the network conditions are not favourable. Given how many transactions your system created in such a short time (approx 10-15 in about a 5 minute window), you might be better off implementing a "batching" system to collate withdrawal requests in a given 5-15 minute window and creating one single transaction.

Your overall fee costs will decrease and you're less likely to create such long unconfirmed transaction chains. There is a reason why most of the "big" sites do exactly this

Also, as the block time is typically averaged to 10 minutes, collating transactions means users are generally going to have to wait for that sort of timeframe to get a confirmation when the mempool is empty and fees are 1 sat/vbyte etc... so, they're not really likely to be disadvantaged too much by such a batching system.

The really tricky part will be making sure you communicate any change with your user base so they understand why you're doing what you're doing... and the benefits for all involved.

Yes, but you're looking at the TX level... OP was talking specifically about the TXOutput level.

As you have said, at the TXInput and TXOutput level they are still arrays... and indeed, if you look further down in your example tx decode,  you'll see the "addresses" arrays listed under each "inputs" and "outputs". Even though they only contain a single address, they're still in array notation with the square brackets ie. [ "..." ]

Theoretically, they could show multiple addresses as they are arrays and while that would be valid from a purely syntactical point of view, in practice, I don't think that this would actually decode to a "valid" transaction unless it was some weird custom script.

I concur that it was likely just a design decision made in the early days and has never been corrected for one reason or another.

Just like looking both ways before you cross the street... it isn't mandatory, but it makes the entire exercise a lot safer!

You can certainly download, install, run and use Electrum without checking the digital signatures... in fact, the scammers who produce the fake Electrum clones that steal coins rely on you doing exactly that!

A partial answer is probably in the same API docs for the TXoutput:


I'm not aware of any current use cases that have multiple addresses for a single output... perhaps it was going to be a planned feature that was simply never implemented... but the API was left as is.

Also, you should note that this is the Blockcypher API, which is not necessarily identical to the Bitcoin spec...

It isn't a problem IF your funds are confirmed... but the problem is that your RECEIVED funds are NOT fully confirmed...

One input from: 632e1733fb51412b7ddd3685f5e545fb9d58d25aae5fcd7d647ff6cd83f35b42
comes from unconfirmed transaction: f7ef220c1b4eb23de43f514f433fc3b00fb0feda074bf6da29a9c502f75e8fc0
which comes from unconfirmed transaction: ee234ddc9555bb252f30389f274d9072ff9d11ca6f0677b3b91bde6c4d66e199
which comes from unconfirmed transaction: 04af53ab298a2d50edb33b2aa1bdad4c6f48d08e3942c7c4bb3ad80a9d1b070c
which comes from unconfirmed transaction: e5fe84a0337d216d9cd114eb9c803dfb61fc74b2142e0b1d708ba78be58c3a64
which comes from unconfirmed transaction: 4e4cf509a3cad247a3a623cd9d24f29baa84f6ffb99081ede9abc0112505a21e
which comes from unconfirmed transaction: 7c124f3b964bccde81760504700a089ef57caa6f528d303e30e008d260328e20
which comes from unconfirmed transaction: 8c8ef940004d935227b894b1277730d1232a8740662f4db4b6badad502a7944f
which comes from unconfirmed transaction: 8072d4034ebe2193407fdaf997ddcc3d2e2503317b8b888f10b13ddbf2d9d29f
which comes from unconfirmed transaction: bea4d21c603268d0a468a5fe542571d8f28f3d038fa49cac120fe506e7aba1fb
which comes from unconfirmed transaction: d118302e0d6b133edd4c49af76b55acb724dcb582da6c61b6c0c54fc0d59864f

It then branches at this point... as all 4 inputs there come from unconfirmed transactions...

Branch 1:
c42ec709069cf22dbd0ff22514194d2487c8aba47722b6e6ab0dca1d4ba37b1f

Branch 2:
c336d40b375d64f262fd78377dbcdec5b57112934219951441018b7d7b1e33c8
7548505d013fa630d38f887ae8b433731b48591812e7554abac65c2d9c1c2f4d
131035a0be8415cbffc63289872cb62f11772a4703ab40d28fd08018df9a5fe9

Branch 3:
7d510cd0d0dd58b1b6f58cef7f4612dbca084738418946b39ff4a97277659227
ea0671e7b05eabe9a727ae71ed6f75cc9c84cfdeb1451d65b991255f0ec21335

Branch 3 also splits here:
Branch 3a:
cac7eb21c30f8ee8be79957809d0d257c59ef862166c45b725c0a7e6bb7d2456
f3d739861ebec71c9cc35a63997e5a62992b663e6892dfc327ef3c484f9f7f45

Branch 3b:
fb55444011306f8c3eadf2d9b765423c4cb7052c22b4a01ead8bc68643e63d76


Branch 4:
5886236164c7c9dba08ce890dae5a55a06ea3147ba1e606726d5ac9fc6c6bfe6
61c6924395091ccd968c3c6a43ee4cede5d3ea813cc4c56ee7f55d666db03adc

it is going to take a while for all of this to confirm... especially with the pump in BTC value, the network is going nuts, blocks are full and fees have shot up.


I suggest you either learn how to batch up transactions, so you can send multiple amounts in ONE single transaction... implement a "minimum payout"... (possibly even switch to a different coin like Bitcoin Cash where block space is plentiful and fees are practically zero )


EDIT: and wouldn't you know it... just as I finish typing all this, the transactions confirm! #youGotLucky

Like I originally said...

It's good to see the Ledger are willing to stand behind their product like this and honour a (technically) expired warranty and provide a free replacement... and they even covered the shipping! THAT is above and beyond in my books.

Acts like this are what make a company stand out in an ever crowded market space

As far as I know... ElectrumG is "fine"... like I said, no reports to my knowledge of it being a scam, but I am not going to put my reputation on the line and claim that it is definitely safe. I haven't checked the code and I haven't used it.


I used the Bitcoin Gold "QT" fullnode wallet (basically, the port of Bitcoin Core -> Bitcoin Gold) and Ledger to get Bitcoin Gold.

As your bitcoins were in Electrum at the time of the fork, you're kinda stuck with using Electrum derivatives like ElectrumG if you want "the easy way" using the 12 word Electrum seed mnemonic due to Electrum seed mnemonics not being BIP39 compliant... otherwise, you'll have to identify each address/private key in Electrum that contains coins, then export those keys and then import/sweep them into another BTG wallet.


I'm not going to recommend anything... as I'm not willing to take any responsibility for anything that you do. Your "options" are:

1. use ElectrumG - quick and easy.
2. use Bitcoin Gold "full node" - you have to export all your private keys, import all your keys... then wait for the node to sync and scan your imported addresses.
3. use some other BTG compatible wallet (like Coinomi) that allows importing and/or sweeping of individual private keys.

Time to put your big boy pants on and make a decision.


Well of course there are... otherwise there wouldn't be any Bitcoin SV in circulation, other than those from mining


My understanding is that "some" exchanges offered to honour the SV fork... but not all supported it.

Ledger has chosen not to implement SV, can't say I blame them... developing/testing for every single fork ever would be a complete waste of their time... they have to make a call as to which forks are going to continue to exist and are worthwhile developing for... SV appears to have lost in the Bitcoin Cash "war"... the majority of the hashrate and value remains with Bitcoin Cash and Bitcoin SV is currently worth 1/3 of BCH.


If you had Bitcoin Cash in a ledger, your only option for getting Bitcoin SV would be to move ALL of your coins off the current seed on the ledger to a new seed... then, using the old seed you could safely export your private keys, them import them into a Bitcoin SV wallet...

If you had Bitcoin Cash in Electron Cash, originally you would have had to export/import private keys... as the only Bitcoin SV wallet to start with was the default Linux-only client. Apparently there is now (since January) an ElectrumSV... They even have a guide for splitting SV coins using this wallet... but again, USE AT YOUR OWN RISK.

PyWallet should work OK with an older wallet... it doesn't play nicely with newer versions of wallet.dat as the new data fields confuse it and it generates a number of errors.

I'd definitely recommend giving PyWallet a shot.

ElectrumG is for Bitcoin Gold... NOT Bitcoin SV. Bitcoin SV is a fork from Bitcoin Cash

bitcoingold.org is the official website of Bitcoin Gold... ElectrumG is linked from there. The only reason I said "use at your own risk" is that I am not vouching for that wallet. It looks "OK", and as far as I'm aware there have been no known thefts directly attributable to that wallet, but I am not going to guarantee that it is 100% safe.

I've no idea about Bitcoin SV... as far as I can tell, there isn't even a Windows client for the official Bitcoin SV release. There are supposedly some forks of the official client that support Windows, but I am not going to vouch for or link them.

A virus check on a bogus wallet will most likely show it to be completely clean... virus scanners can only detect if it is infected with a known Trojan or Virus (and possibly other malware). Simply connecting to a server via the internet and transmitting data is generally NOT flagged as suspicious... otherwise every browser, email client, instant messenger and any other internet enabled apps would be flagged

So, if it is a bogus wallet that just simply sends your private key (or seed) or wallet file and password to an email address or POSTs the data via a PHP script on a webserver etc (ie. it is just doing "basic internet application stuff"), then chances are that a virus scanner will NOT be able to detect that behaviour as being malicious.

In this instance, I'd say with 99.999999999% confidence that it is a scam of some sort...

Set a password or don't... it doesn't make any difference if all you are going to do is immediately transfer BCH from this Electron Cash wallet to your Ledger... and then never use Electron Cash again.

Setting a password simply encrypts the sensitive information (seed, xpriv etc) within the Electron Cash wallet file... (and possibly fully encrypts the entire file if you select that option during wallet creation). Do whatever you feel most comfortable with.

Yes... just like you would with Electrum... "Standard Wallet". Then input your Electrum seed... it'll create a wallet and you should see a BCH balance that matches whatever BTC balance you held in Electrum at the time of the original Bitcoin Cash fork.

That sounds about right... I believe that Ledger generates "legacy" addresses for Bitcoin Cash... Electron Cash will still be able to send to that. It even has a builtin address converter.

Don't TRIPLE space every single sentence then!

That's simply Windows 10 being Windows 10... unless you pay Microsoft for the privilege of having a digital signature, it'll flag as "unknown publisher". If you want to check the authenticity... simply follow their recommended procedure for verifying the downloaded files: https://github.com/Electron-Cash/keys-n-hashes

Make a backup (or three) of your "wallet.dat"

That is pretty much all you need to do to secure your Bitcoin Core wallet. You do not need to deal with xpriv's or individual private keys or seeds... just make sure you have your wallet.dat safely (and securely) backed up.

As far as I'm aware... the Chrome app still "works"... but can be unreliable with things like countervalue (ie. USD values) not working correctly... long sync times etc.


No. If you do not have the appropriate "coinapp" installed on the device, you will be unable to sign any transactions for that particular coin... so you will be unable to send any of those coins anywhere until such time as you can install the coinapp.


Why would they be screwed? Simply removing the bitcoin app from the device does not destroy coins or render the device inoperable etc... You can simply "reinstall" the coinapp on the device via "Manager" without the 24 word recovery phrase and everything will still function as normal.

The issue is with updating the firmware... and even then, you don't need the 24 word recovery phrase to complete the firmware update. It is just recommended to have access to the 24 word recovery phrase in case something goes wrong when updating the firmware and you have to completely reset the device.

In the vast majority of cases, the firmware update will complete without incident and you won't need to use the restore the device at all.