The short and relatively simple version would be something like:

1. Download Jonald Fyookball's public key from here: https://raw.githubusercontent.com/fyookball/keys-n-hashes/master/pubkeys/jonaldkey2.txt

2. Import the key to gpg using:

3. Download the appropriate "sig" file from here: https://github.com/fyookball/keys-n-hashes/tree/master/sigs-and-sums/3.0/win-linux

4. Verify the file

NOTES:
- ensure the .sig file and the tar.gz are both in the folder where you execute commandline syntax above
- gpg: Good signature from "Jonald Fyookball <jonf@electroncash.org>"  should be displayed after step 4.
- You can safely ignore:

It just means you have not "vouched" for Jonald's key... as long as you see 'Good signature from "Jonald Fyookball <jonf@electroncash.org>"' It is OK.

Is there a specific reason why you need to try and apply that patch and recompile the project? As you 100% sure that you have a "beta 7" wallet that would require you to use that process?

Stolen? As in, someone has emptied your wallet of all the coins? If so, this utility can't help you. It was designed for recovering accidentally deleted wallets, or wallets "lost" due to corruption etc... and for other wallet "editing" tasks.

It cannot magically return coins that have been stolen.

Possibly... a good place to start would be identifying the block the transaction was included in... and which mining pool mined that block. If it was F2Pool, BTC.com, ViaBTC or AntPool... there is a possibility that someone got it accelerated.

By looking at the "children" of this transaction, you might find one that pays a ridiculously high fee... in which case, they may have attempted a "Child Pays For Parent" that worked to get it confirmed.

I would suggest using Electrum (for BTC) and ElectronCash (for BCH)... They're both "lightweight" SPV (Simple Payment Verification) wallets that don't require you to download the whole blockchain etc. They support sweeping...

You can get them here: https://electrum.org/#download and here: https://electroncash.org/#download

Be very careful where you download the files from, there are a LOT of fake scam sites for these two wallets, designed to steal private keys/seeds etc. You should really check the digital signatures of the downloaded files before using them.

The current (english) wordlist for BIP39 has 2048 words in it... a "typical" seed uses 12 words... some wallets use 24 words... even with just 12 words, the basic calculation for the number of combinations is:

2048¹² = 5.4445179 * 10^39

With 24 words that would become:

2048²⁴ = 2.9642775 * 10^79

even discounting "invalid" seeds (the last word is actually a checksum, so not ALL combinations of words actually generate a valid seed mnemonic) , that's still some fairly large numbers Then you can factor in the fact that you can also add a "passphrase" onto the 24 word seeds... which pretty much makes the number of combinations infinite.

It is 58 combinations only if you know the position of the missing character... if you don't know where that character is missing from, then you're going to be at 51 possible positions * 58 possible characters per position which is around 2958 possible combinations.

Throwing in one or more "mixed case" errors... and the possibilities will start to add up... still, it shouldn't be too hard to write up a python script that can at least generate the possible combinations and then generate the appropriate addresses and compare with the known address of the paper wallet.

Which would be a great idea... if you could "drop" transactions... which you can't... Because, as we call know... Bitcoin transactions cannot be cancelled or reversed. Once broadcast, there is no sure-fire/easy way to simply drop a transaction.

Sure, you can attempt double-spends (easy enough to create, very hard to actually broadcast as usually rejected by the majority of nodes)... RBF would be great if the original wallet sending Transaction#2 supported RBF and had marked the transaction as RBF, then sure, RBF Trans#2.


no... I'm pretty sure if you multiply 1589 sats/byte by 1000... you get 1,589,000 sats/kB... which is 0.01589 BTC/kB

When you setup a wallet in Electrum, you get the options:

- Standard Wallet
- Wallet with Two-Factor Authentication
- Multi-Signature Wallet
- Import Bitcoin Addresses or Private Keys

The 2nd option "Wallet with Two-Factor Authentication" is the "2FA" wallet option. It is a special kind of "2-of-3" Multi-Signature (aka "MultiSig") wallet that utilises a "third party" service called TrustedCoin.

Being "2-of-3", means that any two out of the original 3 private keys are able to sign a transaction.

The seed creates 3 private keys... #1 is put into your wallet file... #2 is "protected" by the seed and is "hidden" (unless you disable 2FA functionality when restoring the wallet)... #3 is held by TrustedCoin.

The system uses Google Auth "One Time Passwords" (OTP)... so you can use any GAuth app like Google Authenticator, Authy, Authenticator Plus etc...

The idea is, when you want to spend from your wallet, you create the transaction and sign it with key #1... the system then sends the transaction to TrustedCoin... and after you put in the GAuth OTP code, TrustedCoin signs the transaction with key #3... and then gives the fully signed transaction back to you for broadcasting.

The system is "safe" in two ones... one, you get the benefits of 2FA, no-one can spend from your wallet without the seed or 2FA device... and two, it has the safety backup, in that if you lose your phone, or TrustedCoin goes out of business, you can simply restore the wallet with your seed, disable 2FA functionality during the restore and Electrum will put both key#1 AND key#2 into the wallet file, so you can sign transactions without needing TrustedCoin or your 2FA device. (Note: this is meant to be an "emergency recovery" tool, and the idea is you can just rescue your funds and send them to a new wallet.)


You can read more here: https://api.trustedcoin.com/#/electrum-help
and here: http://docs.electrum.org/en/latest/2fa.html

I think you might be a bit confused about what the OP has done... OP has sent two transactions:

Transaction One, Sending to Exchange, low fee:

Input A -----> Output A1 (Exchange Address)
             |
             |---> Output A2 (Change Address)

Transaction Two, low fee:

Input A2 ------> Output B (Receive Address, different wallet)

---

Now, the OP is attempting to clean up these two transactions, by doing a 3rd transaction... which is a CPFP that will cover all three transactions. The formulas for this will be something like:

Total Fee required for third transaction = (Transaction One bytes + Transaction Two bytes + Transaction Three bytes) * current recommended fees
Fee rate for third transaction = Total fee required for third transaction / transaction three bytes

Given Transaction#1 was 1 inputs, 2 outputs, it should be around 226 bytes, Transaction#2 had 1 input, 1 output = 192 bytes... Transaction#3 size? difficult to say, depends on how much BTC is in Output B and can it cover the fees... if so, it could theoretically be 1 input, 1 output...

https://bitcoinfees.earn.com/ is currently estimating 500 sats/byte... so :

(226 + 192 + 192) * 500 = 610 bytes * 500 = 305,000 sats required fee... so transaction#3 should be sent with 0.00305000 BTC total fee... or 305,000 sats / 192 bytes = 1589 sats/byte fee (0.01589 BTC/kb)

You can't just sign a message from ANY BTC address... you need to sign the message from the BTC address that contains your BTC You need to figure out which of your BTC addresses contains your BTC, then sign message(s) from all the address(es) that contain your BTC and link them all using the Bot...

Before you go down this path, I would suggest that you read the airdrop "rules" very carefully (https://byteball.org/#dist)... you need 16 BTC to get 0.1 GB now. 0.1 GB is currently worth just under USD$70... yes, you read that right, you need 16 BTC (about USD$220,000.00 worth of BTC) to claim USD$70 worth of Byteball... assuming the March 2018 distribution even goes ahead (and the price remains stable).


TL;DR: You missed the boat.

Well... you can see from my previous post that the same seed actually generated the same private keys and the same public keys... it is just the addresses derived from the public keys that are different... as they use different formats/hash functions/algorithms etc for converting from a public key to an address.

remember: PrivKey -> PubKey -> Address.

Also, by using different "derivation paths" you can generate different private keys from the same seed... this is why each coin tends to use a unique derivation path, so you can have different keys for each coin. That is how popular hardware wallets like the Trezor and Ledger wallets work... one seed -> different derivation paths for each coin -> different private keys -> different addresses... it is also why they hardware wallet devs have been able to create the "fork coin split" tools... by creating a forkcoin wallet (ie. BitcoinCash) with the same derivation path as the original coin (ie. Bitcoin), you can easily access your BitcoinCash as it generates the same private keys etc.



Obviously, because that is exactly what I did...

At the end of the day... a "private key" is just a (very) large number... so you should be able to put that same number into any given cryptocurrency that uses "numerical" private keys and it should then be able to be converted into a public key and from that public key, it should be able to derive an address.

Does your X1 xprv and X2 xprv actually look like this: xprv9vBq3lgskdah4l5h2yt894th93hhbcbsdcgbhsjcguyegfUYGJHGFJHGFg34ff1Z68Mt3vsB3k6SVFk M

That is to say... does it start with the 4 letters "xprv" or does it look something like this: RhooCVdENKkQnsw1SelJzYpJetYscSqnHnc7vKw0bvsKpzv5VquuNKSsX6gBm74wWgv493iawJMGBFF 12OkUfZsES6L2fxDMpdYlfJtpJohGLuGj1sM7mGPppejGFZ9pbRrx1KUJnnQPvCFcaDzVVU5FAmCBVm +ykAuOqLxf2ME=


If it looks like the 2nd example (and ends in =)... "Rhoo.... ME=", then I suspect you have set a wallet password... as per the instructions, when you create the disabled 2FA wallet, you must NOT set a wallet password, otherwise the keys are encrypted and you cannot copy/paste them from the wallet file.

Use: "Wallet -> Password", enter your current password and then leave the new/confirm password boxes BLANK. This will remove the password from your wallet file and when you open the wallet file, you should see that your xprv is now unencrypted and starts with "xprv"

No... you would need to restore to an Armory Wallet first... then use the "Export Keys List" functionality at: Wallet Properties -> Backup this wallet -> see other options -> export keys list -> click "export keys list"

Then you want to tick:
- Show addresses
- Private Keys (Plain Base58)
- Include Unused (Address Pool)
- Omit spaces in key Data

This will give you a list of all addresses and WIF format private keys in your wallet.

You DO NOT need to have Bitcoin Core installed, or for it to be synced etc to do this.

Once you deactivate 2FA using your seed to restore and selecting "disable" when prompted, then there should be an X1 xprv and an X2 xprv. (Usually located right at the end of the wallet file).

If there are not, then something has gone wrong. Did you set a wallet password? You have to create the wallet with NO password.

Change the "if currPayout > maxPayout then" block to set a 'flag' rather than setting to stop().

Then check for the flag before then, this way dobet() will happen once after flag is set:

Again, this is UNTESTED

[/quote]

I wouldn't think that you need to even bother with creating, signing and sending the transaction.

If you're just wanting to hold the BTC and have no intention of spending them for a while, a simple "import" of the paper wallet key into Electrum would achieve the same thing, but without incurring any transaction fees and no chance of your coins getting "stuck" if you don't get the fees right. You use the selection options: "File -> New\Restore -> Import Bitcoin addresses or private keys"

However, for this to be "safe", you really, really, really, REALLY, REALLY need to make sure that you have followed the initial setup suggested by Coding Enthusiast:


It should also be noted that doing this will not put your coins in a "seeded" wallet (with the 12 word recovery phrase/seed mnemonic)... it will instead create a simple wallet with one private key and one address (essentially a digital "clone" of your paper wallet).

You would still be able to create the "watching only" wallet on your online computer... in the latest version of Electrum, the path is actually "File -> New\Restore -> Import Bitcoin addresses or private keys"... and just enter the address (NOT the private key).

The "sweep" dialog in Electrum will actually allow you to send to ANY Bitcoin address that you like... it defaults to one in the current wallet... but you can change it to any address you want.

So, if you select "standard wallet -> use a hardware device"... and connect up the Ledger, it will generate a copy of the ledger wallet. If you use a derivation path of m/44'/0'/0' (the default setting), it will recreate your Ledger "Legacy" wallet... if you use a derivation path of m/49'/0'/0' if will recreate your Ledger "SegWit" wallet.

Once you have created the wallet you want, "Wallet -> Private Keys -> Sweep" and then you can simply sweep to the Ledger address that you want.

Also, there is no "Segwit Blockchain" and no "Legacy Blockchain"... just different address types on one Blockchain

If you have your seed... then yes, it would be VERY easy to "stop" this transaction from being broadcast.

Simply find your current wallet file (http://docs.electrum.org/en/latest/faq.html#where-is-my-wallet-file-located), and rename it to "OLD_WALLET_DO_NOT_USE" or something equally obvious Or better yet, rename it and move it OUT of the Electrum wallet directory.

Then install the latest version of Electrum, and regenerate your wallet using your old seed (File -> New\Restore -> Standard Wallet -> I already have a seed). As the transaction was never broadcast, it can't exist in your new wallet

You're totally misunderstanding what the CPFP dialog was telling you... the blockchain system was NOT waiting on a fee of 441.1954 mBTC for your transaction to be processed. The CPFP dialog that said "fee required = 441.1954 mBTC" was just telling you that if you wanted to attempt a CPFP to give your stuck transaction "priority" a better chance of being included in a block, you should send the CPFP transaction with a fee of 441.1954 mBTC.

However, your original transaction was just sitting there in the mempool, waiting for a miner to pick it up an put it in a block. There was nothing stopping it from being picked up, just the odds of that happening were relatively low because of the low fee.

As for HOW your transaction got picked up with the low fee... as I've theorised, given the "LARGE" number of bytes that this transaction seemed to be, it was probably a "PayToMany" transaction... it is possible someone else either paid for it to be accelerated by an acceleration service, or THEY paid a large 441.1954 type fee to do a CPFP etc. and that is how the transaction got confirmed.

But, as always, without transactionIDs to work with... this is all speculation.