Unlike most altcoins, litecoin actually rebases onto recent versions of Core, so there is no makefile.unix. Read their build instructions, available here: https://github.com/litecoin-project/litecoin/blob/master/doc/build-unix.md.

That is not possible. The hardfork for segwit2x will happen a fix number of blocks after segwit activates. So there is no signalling, but miners who signalled for segwit2x can change their software back to Core after segwit activates.

That means you have a corrupted block on disk and you may need to resync the entire blockchain. At the very least, you will need to reindex it since you will need to delete the file containing this block and all of the files after it.

Can you post ALL of your debug.lof? Just two lines is not enough.

Are you fully synced yet? If not, let it sync. If you are synced, try rescanning. Add rescan=1 to your bitcoin.conf file and start Bitcoin Core. Once Core has started, remove that line so that you don't rescan every time you start Core.

Also, would you be willing to send me your wallet.dat file, after you move all of your Bitcoin out of it of course. I want to investigate what is causing the error so that I can determine whether it is a bug in Core and if it can be fixed.

The wallet.dat file is a Berkeley DB file, not a text file. There is basically no human readable text in it (except maybe for comments) and is in whatever binary format BDB uses for its database. This means that unless you have something which can read BDB files, you aren't going to be able to find anything of use. It's really just a binary blob.

No, that is incorrect.

Each public key has one private key, and each private key corresponds to only one public key. Each public key corresponds to one address. If you have multiple addresses, you have multiple public keys, and multiple private keys. A wallet is simply a collection of private keys and their corresponding public keys and addresses. To the network and the blockchain, there is no such thing as a wallet.

No. That is not how Bitcoin works.

In Bitcoin, there is no such an object as a "Bitcoin". There isn't anything for you to actually receive. All Bitcoin is is transactions with outputs. Each output specifies that whoever spends it must provide a proof that they are allowed to spend it. For most outputs, that means providing a digital signature which signs the spending transaction and that signature is then included in the spending transaction itself. There are no actual "coin" objects; just outputs.

Addresses are a hash of the public key. So with most outputs, the output specifies that a valid digital signature must be provided and the public key that verifies that signature must hash to the hash specified in the output. The signature can only be created by the private key for the public key that was hashed to become the address.

You can check how much Bitcoin an address can spend. Based on past spends, an address can be linked to other addresses. But other than that, you cannot know what other addresses are in a person's wallet and thus you cannot know his wallet's full balance.

If it is an exchange wallet, then that means that they aren't actually making a Bitcoin transaction. The transaction is an internal off-chain transaction which is just changing records in the exchanges database to update with the new balances for each account. This is 0 fee because there is (basically) 0 cost, although the exchange may charge a fee for doing that because they can make money from doing so.

There is no such thing as a "main address" or a "sub-address". Addresses are not related to each other and can stand separately. A wallet may have a "main address", but that is internal to the wallet only and no one else knows nor cares about it.

Post your debug.log file.

That has nothing to do with the first issue. Make a new thread for this issue and post it in the Electrum section.

Nothing did. This is a you problem.

Interesting. Thank you for trying that, I know what the problem is now and how you can fix it (although it is a bug that needs to be looked at).

Go to the Bitcoin Core datadir (same place where you find the debug.log file). Then either edit or create a bitcoin.conf file. Add to that file the following line:
Then start Bitcoin Core and it should work.

It looks like your wallet.dat file is corrupted. Try replacing your wallet.dat file with a backup.

Armory is open source and there are instructions to build the software within the source code itself. So if Armory is no longer being developed, you can download the code yourself and build it in order to get your coins out. If goatpig takes down his repo for whatever reason, many other people have forked it (including myself) and there's also the original repo so you can download the source code from other places.

In what way do you think choosing an address at the end of the private key address range would be secure? There are most definitely people who are monitoring the private keys at the beginning and the end of range and will swipe any and all Bitcoin sent to those addresses. It is almost definitely a bot that probably monitors a few thousand private keys at the beginning and end of the private key range.

Every single private key is known. It doesn't matter if it it is on a public site or not, everyone already knows what every single private key is. Its just that the range is so massive that trying to go through all of the keys to find all of the ones that have Bitcoin is insanely expensive and takes a ridiculous amount of time (like longer than the heat death of the universe amount of time). Vanitygen randomly generates private keys until it gets one that has an address with the prefix you want, so it is secure.


That's the private key expressed in hex.

Post your log files.

That probably won't help since Bitcoin Core's databases have nothing to do with Armory's.

All of it.

Oops. I forgot a few brackets. I will edit my post.

The txid, vout, scriptPubKey, and amount are all the values for the input that you are spending.

Right, I forgot to add the curly braces in my command for you earlier.

If it says complete, then the transaction is signed. Complete is only true when the returned transaction has a full set of signatures. In what way is it not actually signed?

Yes. The message which sends work to a miner contains the previous block hash and the coinbase except for the extranonce(s). Since the coinbase transaction contains the block height currently being mined, you can easily extract that data.

Yes. Since the entire coinbase transaction except the extranonce(s) are sent, the entire coinbase is known.

It is a socket connection.

The actual stratum documentation can be found at https://slushpool.com/help/manual/stratum-protocol

Is Armory fully synced? How many blocks does it say in the bottom right hand corner? Is Bitcoin Core fully synced?

That looks right. Rerun configure and if there are no errors, run make with no arguments or options except your -j option. I also recommend that you actually use a number instead of a shell-ism to lookup the number of cores you have.

The correct syntax that you want is
with hex and privkey being the actual values and not those strings. The position of the quotes is verbatim.

You can get the scriptpubkey from any block explorer. The easiest for this, IMO, is blockcypher. Use the following url format: https://api.blockcypher.com/v1/btc/main/txs/<TXID>?limit=50&includeHex=true. Just use that link verbatim except replacing <TXID> with the transaction id. On the page that you get, scroll down to where it says outputs and find the output that you want to spend from. The scriptpubkey is the hex string for the field labeled script.

Then to sign the transaction with Core and completely offline, your command should be like this:
Everything in angle brackets and the angle brackets themselves (<>) should be replaced with their respective values. The rest should be verbatim. The <hex> that is the unsigned transaction should also be one that is produced by the createrawtransaction command. All that really means is that the scriptsig of each input will just be a 0x00 byte.

This should produce a validly signed transaction that can be broadcast to the network by any node. If you are still unable to broadcast it, make sure that the output you are trying to spend is actually still unspent.

You aren't following the instructions correctly, in fact, you aren't even following the instructions. Please read them again. The makefile.am and makefile.in files are not the makefiles. They are used by the configure script to actually make the real makefile (for which you won't need the -f option) and the configure script is made by running tine autogen.sh script.

The same way you would spend one in any other year. P2PK outputs are still standard and can be used as they were previously used.

What software generated the signature? It either produced the signature incorrectly or the signature contains a High-S value.

What is the command that you are using to try to sign the transaction (without the privkey of course)?

That error means that it cannot find the input. If you are not synced past the date that the input you are trying to spend was confirmed, then it will not work.

Then you clearly do not understand how transactions are signed. When a transaction is signed, the scriptPubKey must be added to the transaction as it is part of the data that is signed. You must either provide that or Bitcoin Core must be synced so that it can look it up.

How so? Can you post it here? The format the coinb.in uses for unsigned transactions may not necessarily be the same format that Bitcoin Core uses.