text:
I'm working to add multiwallet support to Bitcoin Wallet App, but now the balance is no longer updating
I work with a bitcoin wallet app and the UI looks,

When I select an address from the dropdown menu and would press the balance or the transaction buttons, they should open in the new page and show respective info.

When I receive the BTC in certain wallet, it should update the balance of the wallet in the active page. However, it doesn't work as expected and I only 0 BTC as always. Previously, it was juts one wallet (no multi-wallet support) and that time the same code just work fine.
The class that setup the wallet,
public class WalletManager {

    public static WalletAppKit bitcoin;

    private static WalletManager walletManager;

    // public static NetworkParameters networkParameters = MainNetParams.get();
    public static NetworkParameters networkParameters = TestNet3Params.get();

    public static final String APP_NAME = "WalletTemplate";

    public static final String WALLET_FILE_NAME = APP_NAME.replaceAll("[^a-zA-Z0-9.-]", "_")
            + networkParameters.getPaymentProtocolId();

    private static final Logger logger = LoggerFactory.getLogger(WalletManager.class);

    private WalletModel model = new WalletModel();

    private List<WalletSetupCompletedListener> setupCompletedListeners = Collections.synchronizedList(new LinkedList<>());

    public static WalletManager setupWallet(final String walletName) {

        logger.info("Setup Wallet");

        walletManager = new WalletManager();

        walletManager.setupWalletKit(walletName);

        try {

            if (walletManager.bitcoin.isChainFileLocked()) {
                return walletManager;
            }
        } catch (IOException e) {
            e.printStackTrace();
            return walletManager;
        }

        walletManager.bitcoin.startAsync();

        return walletManager;
    }

    private WalletManager() {}

    protected File getWalletDirectory(final String walletId) {

        File dir = new File(walletId);

        if (!dir.exists()) {
            dir.mkdir();
        }

        return dir;
    }

    private void setupWalletKit(final String walletId) {

        File directory = getWalletDirectory(walletId);

        // if the seed is not null, that means we are restoring from the backup
        bitcoin = new WalletAppKit(networkParameters, directory, WALLET_FILE_NAME) {

            @Override
            protected void onSetupCompleted() {

                // Don't make the user wait for confirmations
                // they're sending their own money anyway!!
                bitcoin.wallet().allowSpendingUnconfirmedTransactions();

                Wallet wallet = bitcoin.wallet();

                model.setWallet(wallet);

                setupCompletedListeners.forEach(listener -> listener.onSetupCompleted(wallet));
            }
        };

        // Now configure and start the appkit. This will take a second or two - we could show a temporary splash screen
        // or progress widget to keep the user engaged whilst we initialise, but we don't.
        if (networkParameters == RegTestParams.get()) {
            bitcoin.connectToLocalHost();   // You should run a regtest mode bitcoind locally.
        } else if (networkParameters == TestNet3Params.get()) {
            bitcoin.useTor();
        }

        bitcoin.setDownloadListener(model.getSyncProgressUpdater())
                .setBlockingStartup(false)
                .setUserAgent(APP_NAME, "1.0");
    }

    public WalletAppKit getWalletAppKit() {
        return bitcoin;
    }

    public WalletModel getModel() {
        return model;
    }

    public void addWalletSetupCompletedListener(final WalletSetupCompletedListener listener) {
        setupCompletedListeners.add(listener);
    }
}

The class responsible for the wallet updating is provided below,
public class WalletModel {

    private List<Transaction> transactions = Collections.synchronizedList(new ArrayList<>());

    private ProgressBarUpdater syncProgressUpdater = new ProgressBarUpdater();

    private static double SYNCHRONISATION_FINISHED = 1.0;

    private double syncProgress = -1.0;

    private Coin balance = Coin.ZERO;

    private Address address;

    private String transaction;

    private int UserId;

    public int getUserId() {
        return UserId;
    }

    public void setUserId(int userId) {
        this.UserId = userId;
    }

    public String getTransaction() {
        return transaction;
    }

    public void setTransaction(String transaction) {
        this.transaction = transaction;
    }

    private List<String> history = new ArrayList<>();

    public List<String> getHistory() {

        for (Transaction t : transactions) {
            history.add(addTransactionHistory(t));
        }

        return history;
    }

    public WalletModel() {
    }

    public WalletModel(Wallet wallet) {

        setWallet(wallet);
    }

    private void update(Wallet wallet) {

        this.balance = wallet.getBalance();

        this.address = wallet.currentReceiveAddress();

        transactions.addAll(wallet.getRecentTransactions(100,
                true));

        this.transaction = Objects.isNull(transactions) || transactions.isEmpty()
                ? "" : String.valueOf(transactions.get(0));
    }

    public boolean setWallet(Wallet wallet) {

        try {
            wallet.addChangeEventListener(new WalletChangeEventListener() {
                @Override
                public void onWalletChanged(Wallet wallet) {
                    update(wallet);
                }
            });
            update(wallet);
            return true;
        } catch (Exception e) {
            e.printStackTrace();
        }

        return false;
    }

    private class ProgressBarUpdater extends DownloadProgressTracker {

        @Override
        protected void progress(double percentage, int blocksSoFar, Date date) {
            super.progress(percentage, blocksSoFar, date);
            syncProgress = percentage / 100.0;
        }

        @Override
        protected void doneDownload() {
            super.doneDownload();
            syncProgress = SYNCHRONISATION_FINISHED;
        }
    }

    public boolean isSyncFinished() {
        return syncProgress == SYNCHRONISATION_FINISHED;
    }

    public Address getAddress() {
        return address;
    }

    /**
     * @param
     * @return the Satoshi coin based on the wallet balance
     */
    public Coin getBalance() {
        return balance;
    }

    /**
     * @return get the BTC amount as float from the wallet balance
     */
    public float getBalanceFloatFormat() {

        float bal = (float) balance.getValue();
        float fac = (float) Math.pow(10, 8);

        float result = bal / fac;
        return result;
    }

    /**
     * @param transaction take the wallet transaction as an input
     * @return the trasaction info of the wallet
     */
    private String addTransactionHistory(Transaction transaction) {

        if (Objects.isNull(transaction)) {
            return "No transaction";
        }

        Coin value = transaction.getValue(WalletManager.bitcoin.wallet());

        if (value.isPositive()) {
            String message = "Incoming payment of " + MonetaryFormat.BTC.format(value);
            return message;
        } else if (value.isNegative()) {
            Address address = transaction.getOutput(0).getAddressFromP2PKHScript(networkParameters);
            String message = "Outbound payment to " + address + " worth of " +
                    (MonetaryFormat.BTC.format(value)).toString().replaceAll("-", "");
            return message;
        }

        String message = "Payment with id " + transaction.getHash();
        return message;
    }

    public double getSyncProgress() {
        return syncProgress;
    }

    public ProgressBarUpdater getSyncProgressUpdater() {
        return syncProgressUpdater;
    }

    public List<Transaction> getTransactions() {
        return transactions;
    }
}

public interface WalletSetupCompletedListener {

    void onSetupCompleted(Wallet wallet);
}

How do I design the code to support the multiple wallet? I can provide the code snipped if requested.

We can't possibly know what is wrong with the code without you posting it here.

I've downvoted this question because it is extremely specific to the askers issue and it seems unlikely to be useful to anyone else.

@Murch the forum is for the personal programming questions too

You're right. I've removed my downvote and edited the title to clarify what people can expect to see when they click this question. Please feel free to further amend it. Also, if you understand what your answerer was trying to tell you, could you edit his answer to make it clearer? I don't even understand what he's trying to tell you.

Remove block for else if in that you have used useTor(), it doesnt need at all


text:
Accidentally sent to my own receiving address, will I get back my bitcoins?
I mistakenly pasted my own Blockchain.info receiving address into the recipient field when I was trying to send BTC to a friend. I usually receive either a "send" or "receive" notification in my records, but this time I got a "transferred" notification. Even though it was my own receiving address it took 100 confirmations and blockchain.info never returned my BTC back to my own wallet. I'm not asking for my fees to be returned but about the whole bitcoin I sent. Do you think that I will get back my BTC even if I used my own receiving address?

Bitcoin doesn't know that the recipient address is also yours. Therefore, while you sent the money to yourself, it looks like any other Bitcoin transaction to any other network participant.
To your wallet provider (blockchain.info) it is obvious that you control both addresses, so they call it a "transfer" instead of a "send".
As you've sent it to your own receiving address, you should be able to see it counted towards your balance. If it hasn't been, get in touch with blockchain.info and request that they help you rectify it.

You already own these bitcoins while you ve sent them to your own address. Check the transaction you have made in blockchain.info explorer. You can spend these btc again there is no problem with that.

Hi Badr, thanks for yor commends and info.  I checked the transations in the blockchain info explorer and I see there the total that went out if ever went out and the total the came in if ever out. my Quiestion is How can I use it if this btc is not showing in my Sent and Receive slot it shows transferred. where i get them to use it again? is ther a way to get it and use?  Thanks again Albert

source: Stack Exchange

license: Creative Commons - Attribution Share-Alike - https://creativecommons.org/licenses/by-sa/3.0/

sort: votes


text:
Why the bitcoin address is not valid in any of the testNet faucet
I develop a simple Java/Maven/JSP app for bitcoin and generated the address
    167Bqf3Mi3gnfhw5DhCfoYNTMxqANt3Zky
I would like to send some money to this address from a bitcoin testnet faucet. I feel it weird that none of the testNet faucet out there seems to recognize the address and indicate it as invalid. Funny thing is I used the same code for generating the address that is provided in the BitcoinJ github page.
How should I approach from here?

Testnet uses a different address format than the main network. Testnet addresses start with an "m" or "n".
The address you are using starts with a "1" and is therefore for the main network. This is why the testnet faucets say the address is invalid.
From the documentation of BitcoinJ, it seems that you can configure your code to use the testnet with:

params = TestNet3Params.get();

Thanks for the answer. This helps me a lot. The reason it was created in the first place is that I have used public static NetworkParameters networkParameters = MainNetParams.get();. I later changed the code to public static NetworkParameters networkParameters = TestNet3Params.get(); and  `else if (networkParameters == TestNet3Params.get()) {
        bitcoin.useTor();

//            bitcoin.setDiscovery(new HttpDiscovery(networkParameters, URI.create("http://localhost:8080/peers"),
    }`. New test net address `n3xE28g8cmVYNU5VeGFazoqfGj2PaZUXYN `

Indeed, the new address seems to be a valid testnet address :) . Glad to be of help!

all_licenses: Creative Commons - Attribution Share-Alike - https://creativecommons.org/licenses/by-sa/3.0/


text:
I'm trying to find out if I invested in bitcoin years ago, how can I find my bitcoin?
For whatever reason I remember investing in bitcoin when it first got started, unfortunately I don't have my old computer or old files anymore. If there is anything you could do to help that would be wonderful. Thank and have a great day.

Given the information provided, what exactly do you expect anyone to do?  No service or program was listed, you don't have any files at all, don't mention any paper backups.  Is there anything at all that you do have?

I'm going to look through all my old files I was just hoping that maybe it would be listed under my name I will continue looking thank you for your info ill get back to you thanks

Related: https://bitcoin.stackexchange.com/questions/103688/i-have-lost-my-wallet-what-can-i-do

If you purchased bitcoin in the past, there are likely only two ways you were storing it.
First, you may have been storing it on some web wallet, where the keys to use the bitcoin are managed for you.  If this is the case, you will likely have registered for the wallet with an email address.  If you think you know which email address this was, and you still have access to it, I recommend searching through your email history.  If the wallet company still exists (and hasn't lost/stolen your money), and you can prove your identity to them, then they could give you access to your bitcoin.
Second, you could have stored the bitcoin in your own wallet.  If this is the case, and you truly don't have your wallet file...you are out of luck.  You probably bought this bitcoin from some company, and again registered with an email, so it doesn't hurt to search for a record of your purchase.  However, if you took on the responsibility of holding onto your keys yourself, and you failed to do so, there is no way to retrieve your money.

No government agency or other authority keeps track of cash you put  in the pocket of your old jeans or down the back of your sofa five years ago.

I was just hoping that maybe it would be listed under my name

Just as there's no global registry of who currently owns every $5 bill and where they put it, there's no global registry of who owns every amount of Bitcoin. Like many other forms of cash, Bitcoin is anonymous.
If you can't remember where you put those 50 $100 bills you had five years ago, its unlikely random strangers on the other side of the planet would be able to tell you that you put it down the back of your uncle's piano.
Bitcoin is cash in your pocket not a bank account. There is no Bitcoin corporation. Bitcoin tries to be anonymous, the only public information just links amounts of money to secret numbers. You have to know that secret number to spend the money. The secret number is stored in a computer program called a wallet, either an app on a phone or a program on a PC or maybe in a website run by one of thousands of online businesses who look after money for people.
No international or national government agency or other organisation keeps track of your cash for you.

I'm trying to find out if I invested in bit coin years ago any ideas on how I would do that?

Jestin's answer covers that.
You need to find the original wallet, some e-mail correspondence with a bank-like business (exchange, trading platform, etc) or somewhere you wrote down the details like the secret number (private-key or seed-phrase/backup-phrase/recovery phrase) or somewhere you stored a backup file made by whichever wallet program you had used (there are many, all different).

license: Creative Commons - Attribution Share-Alike - https://creativecommons.org/licenses/by-sa/4.0/


text:
cancel transaction in MultiBit Classic
I'm trying to send some BTC - I have two send transactions stuck in MultiBit Classic (0.5.19). They have been stuck for a few weeks.
Both transactions have fee of 0.0001 BTC fee which is most likely why they are stuck.
I tried 'resetting the blockchain' several times in the last couple of days, and I tried increasing the fee to 0.0005 BTC between resets, all to no avail. The transactions still show up as having a 0.0001 BTC fee.
What can I do get these transactions processed (or cancelled)?
The documentation for MultiBit HD, the new version of Multibit, states that the best way to upgrade from MultiBit Classic is to create a new wallet and transfer the balance but how can I do this if the bitcoin is stuck in the transaction?
If I was to export the private keys to another wallet service, say  blockchain.info, what would happen to the BTC in the stuck transactions?

Control over money in Bitcoin is defacto[1] binary: either a transaction has been confirmed in a block and the money has been signed over, or the sender remains in control of the money. Hence, when you export the keys from MultiBit and import them to another wallet, you will be able to overwrite your previous transaction by issuing another transaction transferring the money somewhere else (unless the new platform is aware of your previous transaction and forbids doublespends).

[1]The only exception to this is the option of the recipient to create a child-pays-for-parent transaction which provides a sufficient aditional transaction fees to compensate the low fee of its parent. Still the money is only signed over once the transaction is in confirmed in a block though.

This does not answer the original question. I am very much in the same boat as OP. Still wondering what to do. I am using MultiBit Classic 0.5.17 and have three transactions stuck for days now with no hope of moving. My version of MultiBit automatically adds 0.0001BTC as transaction fee to any transfer and there is no way to adjust that. This makes double-spending with higher fee impossible. What to do?!

@VladimirFerdman: Please see https://bitcoin.stackexchange.com/q/54447/5406 for other software that can import Multibit wallets. I can also not stress enough that you shouldn't be using 3.5 year old wallet software in a fast moving space like Bitcoin.

Thank you for attempting to answer the question, but the the link provided talks about MultiBit HD, not classic. I am trying to migrate away from a 3 year old software, but it is proving more difficult than it should be. I can not move my bitcoin from the wallet created by another software and I can't spend the coin to another wallet of mine because the old software does not provide a way to adjust transaction fees. Do you see the problem?


text:
Unable to find where transactions sent
I sent this transaction and it took a long time to confirm as you can see
023d90420161bbb5f97480d673405d19b79de1c4a7383c8977b62b16926d881c.
Now I have asked the recipient and they have said that I used the wrong address. If that is the case. Where are my bicoin now please?

It is very hard to do a typo in a Bitcoin address, as the address format includes a checksum. Have you checked whether you accidentally sent to a previous business partner? Have you checked whether the address that you sent to matches the address that you were asked to? If the latter is true the error may be on the side of the recipient.
In any case, the coins are now under the control of whomever the recipient address of the transaction belongs to. If

the address is unclaimed: the coins are lost.
the address is claimed by a known entity: you may be able to retrieve them by contacting them.
the address is claimed by an unknown entity: the recipient will do whatever they want.

Try googling the (unique!) respective address to see if someone is asking about receiving an unknown payment. It wouldn't be the first time. ;)

Makes sense. I think I will let them go and make some more :)

If you used the wrong bitcoin address, your coins are gone. Your only hope is that the person that received them (if they did) sends your coins back to you (seems unlikely)
You should always check and double check the address you are sending to!
To be clear, if you used the correct address and the recipient is scamming you, there is also nothing you can do.

I always get an address and a receipt their customer service which should be able to confirm where and what state or country it was don’t care who I just want to know where

authors: Дима Кудрявцев

all_licenses: Creative Commons - Attribution Share-Alike - https://creativecommons.org/licenses/by-sa/4.0/


text:
How do I find out which wallet fits which client?
I found a really old Bitcoin wallet, a wallet.dat file, and tried to open it. Bitcoin Core told me that the wallet is corrupted. But I also found out that different clients make different wallets, so they aren't supposed to be compatible with each other. How do I find out which client I need to use to be able to open this wallet?

Bitcoin Core is the only software that uses a file called wallet.dat, as far as I know.

I think Armory uses the same... Also many derivatives use the same name, as well.

Besides, several -salvagewallet tries didn't work out at all. The hard drive is perfectly fine and I don't see any reason for the wallet to be actually corrupted.

Armory uses armory_{name}.wallet.

The only software that uses wallet.dat is anything that is based on Bitcoin Core (e.g. Bitcoin XT, Bitcoin Classic, Bitcoin Unlimited, btc1) and altcoins that have forked from Core at some point (basically all altcoins).

This is horrible, I use some wallets of coins that are forked of Bitcoin, and suddenly I find a wallet.dat on my d:\ drive, not knowing for which coin it is...


text:
Is the miners address part of the block or the block header?
Should the following be sufficient merkle root, block number, previous block hash, timestamp and nonce?

Sufficient for what? Your question is incomplete, it's not clear what you're asking.

If you are looking to find the miner's address, you will need the full block, not just the header.
The miner's address will be transaction 0 of the block, also known as the coinbase transaction.  Like all the other transactions, it is included in the Merkle Root in the block header, but not in the block header itself.


text:
Transaction created with sendtoaddress didn't propagate to the network, how to resend?
i am running Bitcoin Core 0.14.1 on a  Centos6 Server.
I had several transactions (receive, send) in the last days, and everything was fine.
I always did my transaction with the bitcoin-cli sendtoaddress ADDRESS  AMOUNT ... and that worked fine. Always after some minutes i could see my unconfirmed transactions at Blockchain.info
But yesterday i made a new transaction same as always and i get an transactions id successfully, but i cant find my transaction in the Blockchain. And the receiver does not the transaction also.
What i have tried:

I wait more than 24 hours ( but my transaction is not showing up in blockchain, and wasnt include in any block)
I turned off the IP Tables and make sure that the Wallet is connected to the network.
I stooped Bitcoin with bitcoin-cli stop and made an recan with bitcoind -rescan
I stooped Bitcoin with bitcoin-cli stop and made an recan with bitcoind -zapwallettxes
I deleted the memorypool.dat in .bitcoin directory
I reload the complete Blockchain

Who has the solution?

What are you trying to achieve: Resending or recovering? Is the transaction still showing as unconfirmed on your server? Did the transaction get malleated and confirmed? Have you checked whether the transaction's inputs are still in your wallet? Did you delete the mempool file and do -zapwallettxes in the same go?

I've guessed at your goal to give the question a more speaking title. If I guessed wrong, please edit to improve. :)

The amount is subtracted from my balance and its shown in my wallet as unconfirmed transaction. I want to resend it.

If you have the transaction ID you can get the raw hex transaction via:
bitcoin-cli getrawtransaction <txid>

That will produce a rather long string <rawtx> which is the serialized transaction. You can then use
bitcoin-cli sendrawtransaction <rawtx>

or any of the web interfaces that allow pushing a transaction (just search for pushtx and I'm sure you'll find a few providers). The raw transaction does not contain any private information. It is safe to publish, however services may attribute the transaction with your IP if you use them, so try sendrawtransaction first, which is the exact same behavior your client would use anyway.
Notice that your client will also automatically retry your wallet transactions every once in a while, so manual intervention may not be needed. It could be you haven't attached a large enough fee for the TX to be propagated in the network.

Edit to the @cdecker answer.
I had the same problem using Bitcoin Core v22.0.0. My transaction wasn't send correctly because my proxy didn't work probably, but the transaction was already displayed in my wallet but never got sent to the bitcoin network. Even after fixing the network problem Bitcoin Core didn't resend the transaction.
If you're using the client version you can open the Console on the top and type the following without the bitcoin-cli to resend your transaction.
getrawtransaction <txid>

sendrawtransaction <rawtx>


text:
Static receive address instead of dynamic?
I have 2 BTC QT wallets (and 1 LTC QT wallet), and am looking for a generic receive address for my wallets. In Electrum, Mist/Ethereum and Rippex, I get a single unique address to receive. In the QT apps however, I need to "Request payment", which then gives me a new receive address every time I make this request. It also says [checkbox] Reuse an existing receiving address (not recommended).
Is there such a thing as a generic receive address for a QT wallet? If I need to create a new request every time I want to receive coin, that's not ideal.
Am I missing something, or how does this work?
Or can I just create a receive address once off and keep using that, not sure why it's not recommended..

related: https://bitcoin.stackexchange.com/q/20621/5406

You can certainly give out the same address to as many people as you want.  An address is really just a representation of the public part of a cryptographic key pair, and you will still have the corresponding private key.  That means, the address will still function, regardless of how many times you use it to receive money.
However, as the app tells you, this is not recommended.  The reason is privacy.  Remember that the blockchain is public, and your addresses are unique.  When you give out an address, you are telling that person that this address is associated with your identity.  They can then look up that address on the blockchain, and see how many other times someone has given you money through that address...and how much.
If you have given the same address out to a lot of people, then a lot of people can do this, and there's a lot more data for them to see.  This can then be used in conjunction with other blockchain analysis techniques, and you end up with a lot of people being able to gleam insights into where you get your money, how much money you have, and where you spend it.  In short, you are giving up a great deal of privacy.
On the other hand, when you use a new address every time, you are giving away very little information to people paying you.  If they look up the address, they will see that it is a completely new and never before used random number.  They will not be able to determine how many other people have been paying you, and far fewer people will know that this particular address is tied to your identity.  Blockchain analysis can still determine a few things, but with a lot less data to start with, the results won't be anywhere near as complete as they are when you reuse addresses.
Unless there is some important and unique benefit you get from reusing addresses, you really shouldn't.

Thanks! So, the main reason for me is that I'm not very actively using my coins. I'm in the process of better securing my wallets and want to move them to a slightly less accessible place. But say now, the price of BTC drops and I quickly want to buy (from where ever, e.g. at work), I don't want to have to load Bitcoin Core and with my wallet (which I might not have access to at the time), generate a receive address. So just for ease of use. If you're a small time user like myself, do you think security/privacy is really an issue?

Or should I perhaps generate a bunch of receive addresses, for use in the future, whenever? Only thing is that say I save that list on e.g. Dropbox, and someone gets their hands on that list, they can change the receive addresses to their own..

When it comes to securing bitcoin, it's best not to roll your own solution.  These problems are mostly solved.  In your case, just use a wallet on your phone that only has a limited amount on it, and use that to give it new addresses.  When it gets a lot in it, make regular transfers back to your main wallet.  It's like the difference between a purse and a bank account.

Sure, that actually makes a lot of sense. Rather just "pop-up" an on-the-fly  wallet on mobile or e.g. Electrum, receive funds, and then move them to a more appropriate account later. Thanks!

Another reason to use new addresses is quantum-resistance, since address which sent at least 1 outgoing transaction will be vulnerable for quantum computers


text:
How can one unstuck an unconfirmed transaction with Bither?
I've sent a transaction with the Bither wallet, but accidentally included too little fee. I've since updated my wallet software, so it shouldn't happen again. However, what can I do to speed up the stuck transaction's confirmation or to replace it?

This is a complementary question to Why is my transaction not getting confirmed and what can I do about it? which answers the question's broader implications and proposes mitigation mostly focused on Bitcoin Core.

Your fee is about a factor of ten too low. Your wallet software may be outdated, in that case please update to a newer version.

Happy to increase the fee. Also updated my software using Bither and increased the fee for my next transactions. However, how do I increase the fee on this specific transaction. Sorry, probably a basic question, but I don't know. Many thanks for help!

I've updated the question to ask the underlying question.


text:
How do you get back the private keys you used, after you deploy your wallet with a 12 word seed?
If I change computers and use the 12 word seed to use my wallet, how will the client know which private key I used in the previous computer?

A long sequence of private keys can be computed from the seed in a standard way.  The new client will import those keys for your use, while computing the corresponding addresses and checking the block chain to see which ones have been used.  When it finds many keys in a row that haven't been used (perhaps several hundred; this number may be configurable in your client), it assumes it has found all the keys in the sequence that you actually used, and stops.


text:
How to calculate the BIP34Hash?
I know this going to be a repeat question, however I am still puzzled with the implementation of the BIP34 especially where it come to its hash.
Referring to the chainparams.cpp at github :
https://github.com/bitcoin/bitcoin/blob/master/src/chainparams.cpp
static CBlock CreateGenesisBlock(const char* pszTimestamp, const CScript& genesisOutputScript, uint32_t nTime, uint32_t nNonce, uint32_t nBits, int32_t nVersion, const CAmount& genesisReward)
{
    CMutableTransaction txNew;
    txNew.nVersion = 1;
    txNew.vin.resize(1);
    txNew.vout.resize(1);
    txNew.vin[0].scriptSig = CScript() << 486604799 << CScriptNum(4) << std::vector<unsigned char>((const unsigned char*)pszTimestamp, (const unsigned char*)pszTimestamp + strlen(pszTimestamp));
    txNew.vout[0].nValue = genesisReward;
    txNew.vout[0].scriptPubKey = genesisOutputScript;

    CBlock genesis;
    genesis.nTime    = nTime;
    genesis.nBits    = nBits;
    genesis.nNonce   = nNonce;
    genesis.nVersion = nVersion;
    genesis.vtx.push_back(MakeTransactionRef(std::move(txNew)));
    genesis.hashPrevBlock.SetNull();
    genesis.hashMerkleRoot = BlockMerkleRoot(genesis);
    return genesis;
}

/**
 * Build the genesis block. Note that the output of its generation
 * transaction cannot be spent since it did not originally exist in the
 * database.
 *
 * CBlock(hash=000000000019d6, ver=1, hashPrevBlock=00000000000000, hashMerkleRoot=4a5e1e, nTime=1231006505, nBits=1d00ffff, nNonce=2083236893, vtx=1)
 *   CTransaction(hash=4a5e1e, ver=1, vin.size=1, vout.size=1, nLockTime=0)
 *     CTxIn(COutPoint(000000, -1), coinbase 04ffff001d0104455468652054696d65732030332f4a616e2f32303039204368616e63656c6c6f72206f6e206272696e6b206f66207365636f6e64206261696c6f757420666f722062616e6b73)
 *     CTxOut(nValue=50.00000000, scriptPubKey=0x5F1DF16B2B704C8A578D0B)
 *   vMerkleTree: 4a5e1e
 */

static CBlock CreateGenesisBlock(uint32_t nTime, uint32_t nNonce, uint32_t     nBits, int32_t nVersion, const CAmount& genesisReward)
{
    const char* pszTimestamp = "The Times 03/Jan/2009 Chancellor on brink of second bailout for banks";
    const CScript genesisOutputScript = CScript() << ParseHex("04678afdb0fe5548271967f1a67130b7105cd6a828e03909a67962e0ea1f61deb649f6bc3f4cef38c4f35504e51ec112de5c384df7ba0b8d578a4c702b6bf11d5f") << OP_CHECKSIG;
    return CreateGenesisBlock(pszTimestamp, genesisOutputScript, nTime, nNonce, nBits, nVersion, genesisReward);
}

void CChainParams::UpdateVersionBitsParameters(Consensus::DeploymentPos d, int64_t nStartTime, int64_t nTimeout)
{
    consensus.vDeployments[d].nStartTime = nStartTime;
    consensus.vDeployments[d].nTimeout = nTimeout;
}

/**
 * Main network
 */
/**
 * What makes a good checkpoint block?
 * + Is surrounded by blocks with reasonable timestamps
 *   (no blocks before with a timestamp after, none after with
 *    timestamp before)
 * + Contains no strange transactions
 */

class CMainParams : public CChainParams {
public:
    CMainParams() {
    strNetworkID = "main";
    consensus.nSubsidyHalvingInterval = 210000;
    consensus.BIP34Height = 227931;
    consensus.BIP34Hash = uint256S("0x000000000000024b89b42a942fe0d9fea3bb44ab7bd1b19115dd6a759c0808b8");
    consensus.BIP65Height = 388381; // 000000000000000004c2b624ed5d7756c508d90fd0da2c7c679febfa6c4735f0
    consensus.BIP66Height = 363725; // 00000000000000000379eaa19dce8c9b722d46ae6a57c2f1a988119488b50931
    consensus.powLimit = uint256S("00000000ffffffffffffffffffffffffffffffffffffffffffffffffffffffff");
    consensus.nPowTargetTimespan = 14 * 24 * 60 * 60; // two weeks
    consensus.nPowTargetSpacing = 10 * 60;
    consensus.fPowAllowMinDifficultyBlocks = false;
    consensus.fPowNoRetargeting = false;
    consensus.nRuleChangeActivationThreshold = 1916; // 95% of 2016
    consensus.nMinerConfirmationWindow = 2016; // nPowTargetTimespan / nPowTargetSpacing
    consensus.vDeployments[Consensus::DEPLOYMENT_TESTDUMMY].bit = 28;
    consensus.vDeployments[Consensus::DEPLOYMENT_TESTDUMMY].nStartTime = 1199145601; // January 1, 2008
    consensus.vDeployments[Consensus::DEPLOYMENT_TESTDUMMY].nTimeout = 1230767999; // December 31, 2008

    // Deployment of BIP68, BIP112, and BIP113.
    consensus.vDeployments[Consensus::DEPLOYMENT_CSV].bit = 0;
    consensus.vDeployments[Consensus::DEPLOYMENT_CSV].nStartTime = 1462060800; // May 1st, 2016
    consensus.vDeployments[Consensus::DEPLOYMENT_CSV].nTimeout = 1493596800; // May 1st, 2017

    // Deployment of SegWit (BIP141, BIP143, and BIP147)
    consensus.vDeployments[Consensus::DEPLOYMENT_SEGWIT].bit = 1;
    consensus.vDeployments[Consensus::DEPLOYMENT_SEGWIT].nStartTime = 1479168000; // November 15th, 2016.
    consensus.vDeployments[Consensus::DEPLOYMENT_SEGWIT].nTimeout = 1510704000; // November 15th, 2017.

    // The best chain should have at least this much work.
    consensus.nMinimumChainWork = uint256S("0x0000000000000000000000000000000000000000003f94d1ad391682fe038bf5");

    // By default assume that the signatures in ancestors of this block are valid.
    consensus.defaultAssumeValid = uint256S("0x00000000000000000013176bf8d7dfeab4e1db31dc93bc311b436e82ab226b90"); //453354

    /**
     * The message start string is designed to be unlikely to occur in normal data.
     * The characters are rarely used upper ASCII, not valid as UTF-8, and produce
     * a large 32-bit integer with any alignment.
     */
    pchMessageStart[0] = 0xf9;
    pchMessageStart[1] = 0xbe;
    pchMessageStart[2] = 0xb4;
    pchMessageStart[3] = 0xd9;
    nDefaultPort = 8333;
    nPruneAfterHeight = 100000;

    genesis = CreateGenesisBlock(1231006505, 2083236893, 0x1d00ffff, 1, 50 * COIN);
    consensus.hashGenesisBlock = genesis.GetHash();
    assert(consensus.hashGenesisBlock == uint256S("0x000000000019d6689c085ae165831e934ff763ae46a2a6c172b3f1b60a8ce26f"));
    assert(genesis.hashMerkleRoot == uint256S("0x4a5e1e4baab89f3a32518a88c31bc87f618f76673e2cc77ab2127b7afdeda33b"));

    // Note that of those with the service bits flag, most only support a subset of possible options
    vSeeds.push_back(CDNSSeedData("bitcoin.sipa.be", "seed.bitcoin.sipa.be", true)); // Pieter Wuille, only supports x1, x5, x9, and xd
    vSeeds.push_back(CDNSSeedData("bluematt.me", "dnsseed.bluematt.me", true)); // Matt Corallo, only supports x9
    vSeeds.push_back(CDNSSeedData("dashjr.org", "dnsseed.bitcoin.dashjr.org")); // Luke Dashjr
    vSeeds.push_back(CDNSSeedData("bitcoinstats.com", "seed.bitcoinstats.com", true)); // Christian Decker, supports x1 - xf
    vSeeds.push_back(CDNSSeedData("bitcoin.jonasschnelli.ch", "seed.bitcoin.jonasschnelli.ch", true)); // Jonas Schnelli, only supports x1, x5, x9, and xd
    vSeeds.push_back(CDNSSeedData("petertodd.org", "seed.btc.petertodd.org", true)); // Peter Todd, only supports x1, x5, x9, and xd

    base58Prefixes[PUBKEY_ADDRESS] = std::vector<unsigned char>(1,0);
    base58Prefixes[SCRIPT_ADDRESS] = std::vector<unsigned char>(1,5);
    base58Prefixes[SECRET_KEY] =     std::vector<unsigned char>(1,128);
    base58Prefixes[EXT_PUBLIC_KEY] = boost::assign::list_of(0x04)(0x88)(0xB2)(0x1E).convert_to_container<std::vector<unsigned char> >();
    base58Prefixes[EXT_SECRET_KEY] = boost::assign::list_of(0x04)(0x88)(0xAD)(0xE4).convert_to_container<std::vector<unsigned char> >();

    vFixedSeeds = std::vector<SeedSpec6>(pnSeed6_main, pnSeed6_main + ARRAYLEN(pnSeed6_main));

    fDefaultConsistencyChecks = false;
    fRequireStandard = true;
    fMineBlocksOnDemand = false;

    checkpointData = (CCheckpointData) {
        boost::assign::map_list_of
        ( 11111, uint256S("0x0000000069e244f73d78e8fd29ba2fd2ed618bd6fa2ee92559f542fdb26e7c1d"))
        ( 33333, uint256S("0x000000002dd5588a74784eaa7ab0507a18ad16a236e7b1ce69f00d7ddfb5d0a6"))
        ( 74000, uint256S("0x0000000000573993a3c9e41ce34471c079dcf5f52a0e824a81e7f953b8661a20"))
        (105000, uint256S("0x00000000000291ce28027faea320c8d2b054b2e0fe44a773f3eefb151d6bdc97"))
        (134444, uint256S("0x00000000000005b12ffd4cd315cd34ffd4a594f430ac814c91184a0d42d2b0fe"))
        (168000, uint256S("0x000000000000099e61ea72015e79632f216fe6cb33d7899acb35b75c8303b763"))
        (193000, uint256S("0x000000000000059f452a5f7340de6682a977387c17010ff6e6c3bd83ca8b1317"))
        (210000, uint256S("0x000000000000048b95347e83192f69cf0366076336c639f9b7228e9ba171342e"))
        (216116, uint256S("0x00000000000001b4f4b433e81ee46494af945cf96014816a4e2370f11b23df4e"))
        (225430, uint256S("0x00000000000001c108384350f74090433e7fcf79a606b8e797f065b130575932"))
        (250000, uint256S("0x000000000000003887df1f29024b06fc2200b55f8af8f35453d7be294df2d214"))
        (279000, uint256S("0x0000000000000001ae8c72a0b0c301f67e3afca10e819efa9041e458e9bd7e40"))
        (295000, uint256S("0x00000000000000004d9b4ef50f0f9d686fd69db2e03af35a100370c64632a983"))
    };

    chainTxData = ChainTxData{
        // Data as of block 00000000000000000166d612d5595e2b1cd88d71d695fc580af64d8da8658c23 (height 446482).
        1483472411, // * UNIX timestamp of last known number of transactions
        184495391,  // * total number of transactions between genesis and that timestamp
                    //   (the tx=... number in the SetBestChain debug.log lines)
        3.2         // * estimated number of transactions per second after that timestamp
    };
    }
};

consensus.BIP34Hash = uint256S("0x000000000000024b89b42a942fe0d9fea3bb44ab7bd1b19115dd6a759c0808b8")
How to you guys manage to generate the hash for BIP34?
On the other hand, referring to BIP34 wiki at:
https://github.com/bitcoin/bips/blob/master/bip-0034.mediawiki
Specification:
1.Treat transactions with a version greater than 1 as non-standard (official Satoshi client will not mine or relay them).

2.Add height as the first item in the coinbase transaction's scriptSig, and increase block version to 2. The format of the height is "serialized CScript" -- first byte is number of bytes in the number (will be 0x03 on main net for the next 300 or so years), following bytes are little-endian representation of the number.

3.If 75% of the last 1,000 blocks are version 2 or greater, reject invalid version 2 blocks. (testnet3: 51 of last 100)

4."Point of no return" If 95% of the last 1,000 blocks are version 2 or greater, reject all version 1 blocks. (testnet3: 75 of last 100)

Can you guys come of with the formula or example? plus, how was the consensus.BIP34Height function and being generated?
Thanks

BIP34Height and BIP34Hash are just the historical height and block hash at which BIP34 activated.
They are an optimization. Earlier versions of the code implemented the exact rules from the BIP34, checking whether the transition criteria were satisfied for every block. This was relatively expensive, and as BIP34's activation is a long time ago now, that check has been replaced with a simpler one that just looks at height and hash of the chain at a certain height.
If you create a new chain from scratch, you can just set this to 0/genesis to have BIP34 be active from the start.


text:
Need Guide: what is the hashrate for ZOTAC P106-100 6GB GDDR5?
One vendor is offering 20 GPUs and each $224.00 . Is it good card for mining ETH and what is the best hash for this? Please let me know your experiences. Is it worth to buy for ETH or other coins?

The cards do not appear to have actually been released yet - so it is not possible to know their hashrate.
With that said, they SHOULD be about the same to perhaps a very little better than existing consumer-type GTX 1060 6GB cards, and should consume probably 20-30% less power at the same clocks due to the removal of all video circuitry and the probability that the parts of the die not used for mining on are also disabled by the BIOS or in the GPU itself.

authors: فردین زندیان


text:
Is my profit calculation for Genesis mining correct?
The Diamond plan for Litecoin mining promises 200 MH/s for $2400 for 2 years. From the profilatbility calculator, it comes out as $555 per month profit without electricity charges(which wont be there for cloud mining). So it would come out as $13320 for 24 months which is the contract lifetime.
So the profit would be $10920 which seems too good to be true.
I have also heard numerous reports that you dont actually make much profit with Genesis mining. What am I missing here?
I know my calculation is wrong. Can anyone help me understand what else needs to be taken into account here?

One factor I know you are currently missing is mining difficulty. It will become more and more difficult to mine litecoin. So profits will drop as there will be less litecoin mined for the mh/s you're leasing.
I'd recommend you watch some videos about it on youtube.
https://www.youtube.com/watch?v=0phyRzSisyE

Thanks for the answer. I watched the video as well and was very informative. He talks about price fluctuations and difficulty as well. Is there any other hidden charges etc that could come into play as well?

You're also assuming the price of Litecoin will stay the same over those two years.  Right now it is near an all-time high at around $45.  Over the previous two years its value has usually been more like $4.  If it should go back down to that price, you'll lose money.

Thanks for the answer Nate. Is there any other hidden charges etc that could come into play as well?


text:
Probability of Orphaned Blocks
This is a question regarding the probability of orphaned blocks depending on the block interval. I am using Bitcoin vs Litecoin as an example.
Assuming equal hash rate and number of transactions, what is the relative increase in the probability of orphaned blocks for Litecoin, given that its block interval is a quarter?
The answer might be as simple as 4, but I'm wondering what is the quantitative justification?

Equation 2 in the following paper derives the math for estimating orphan rate if you know the propagation delay of winning block headers travelling across the mining network. The propagation delay has a hashrate-weighted probability distribution that complicates the calculation. It also depends on the block time.
https://sites.cs.ucsb.edu/~rich/class/cs293b-cloud/papers/bitcoin-delay
An approximation, you can just use average propagation delay and the exponential CDF equation which is the probability of finding a block in "x" seconds:
CDF = 1 - e^(-x/T)
x = average propagation delay
T = block time = 600
This is the probability of an orphan occurring per block found.
The reasoning is like this: at any moment a winning header is found and propagating, this equation is the probability that someone else will find a block before that block has been seen by slightly less than half of the hashrate-weighted mining network. It gives a slight over-estimate of the orphan rate compared to the above paper. Using the median instead is an under-estimate. For a given orphan rate, you can use this equation backwards to estimate x.
The average propagation delay in BTC these days appears to be about x = 250 ms, so that CDF = 0.000416. The inverse of this 2,400, i.e. 1 orphan per 2,400 blocks which is the data I saw a couple of years ago. Assuming the same propagation delay x = 0.25 and T=150 for Litecoin, this gives 1 orphan per 600 blocks. I don't know the actual rate.
Since e^(-y) = 1-y when y is small, the equation simplifies to:
orphan_probability = x/T.
If you know the propagation delay and the orphan rate is higher than expected, it's evidence a big mining pool is doing a mild selfish mining attack. E.g., holding their winning blocks for 1 or 2 seconds in hopes of finding another, giving it better long-term success.


text:
How to use `scantxoutset`
Looking to fetch the UTXOs for a given address and can't seem to find the correct command syntax.
Here is an implementation in bitcoin-core via javascript, but I also experience the same on bitcoin-cli
const descriptorAttempts = [
    '{ desc: addr(34xp4vRoCGJym3xR7yCVPFHoCNxv4Twseo) }',
    '{ "desc": "addr(34xp4vRoCGJym3xR7yCVPFHoCNxv4Twseo)" }',
    '"desc": "addr(34xp4vRoCGJym3xR7yCVPFHoCNxv4Twseo)"',
    "addr(34xp4vRoCGJym3xR7yCVPFHoCNxv4Twseo)",
    "addr(34xp4vRoCGJym3xR7yCVPFHoCNxv4Twseo)",
    "addr=34xp4vRoCGJym3xR7yCVPFHoCNxv4Twseo",
    "34xp4vRoCGJym3xR7yCVPFHoCNxv4Twseo",
    "{ addr(34xp4vRoCGJym3xR7yCVPFHoCNxv4Twseo) }",
    "{ addr: 34xp4vRoCGJym3xR7yCVPFHoCNxv4Twseo }",
    "{\"desc\": \"addr(34xp4vRoCGJym3xR7yCVPFHoCNxv4Twseo)\"}",
    '\"{\"desc": \"addr(34xp4vRoCGJym3xR7yCVPFHoCNxv4Twseo)\"}\"',
    '"{"desc": "addr(34xp4vRoCGJym3xR7yCVPFHoCNxv4Twseo)"}"',
    '"{"desc": "addr("34xp4vRoCGJym3xR7yCVPFHoCNxv4Twseo")"}"',
    '\"{\"desc": \"addr(\"34xp4vRoCGJym3xR7yCVPFHoCNxv4Twseo\")\"}\"',
    '"desc" => "addr(34xp4vRoCGJym3xR7yCVPFHoCNxv4Twseo)"',
    '[ "desc" => "addr(34xp4vRoCGJym3xR7yCVPFHoCNxv4Twseo)" ]',
    { "desc" : "addr(34xp4vRoCGJym3xR7yCVPFHoCNxv4Twseo)" },
    { desc : "addr(34xp4vRoCGJym3xR7yCVPFHoCNxv4Twseo)" }
]

descriptorAttempts.forEach(attempt => {
    client.command('scantxoutset', 'start', [ attempt ])
    .then((res) => {
        console.log("Success! ")
        console.log(res)
    })
    .catch((error) => {
        console.log("Failed attempt of -> " + attempt)
        // console.log(error)
    })
})

All result in RpcError: Invalid descriptor

Does client.command('scantxoutset', 'start', [[ "desc" => "addr(34xp4vRoCGJym3xR7yCVPFHoCNxv4Twseo)" ]]) work?

@PieterWuille it does not :`( As you have written there would be invalid syntax as well. Updated post to include those attempts

Oh, this is JS. Then it should be command('scantxoutset', 'start', [{"desc":"addr(...)"}]).

@PieterWuille tried a couple variations of that with not luck as well. Question is updated to include them

Are you on mainnet or testnet?

testnet @AndrewChow

You are trying to use a mainnet encoded address on testnet. That is not valid. You need to use a testnet encoded address.
The testnet form of the address you are trying to use is 2MvX28fMpoipKxqaxo6pN1CH4QjB5t9qpr8.

I resolved this.
Here is the functional command:
client.command('scantxoutset', 'start' ['addr(mfe87Qheq7SSveCDedyDUBEjMD9tgzRiU7)']) <!-- Address is valid. This address: '34xp4vRoCGJym3xR7yCVPFHoCNxv4Twseo' is invalid

The issue is that the address was invalid. Using a valid address, I can ensure that this works.

when using bitcoin-cli on command line, a syntax that works is
scantxoutset start  "[\"addr(37HyJsnuP5zWTuhJFvrGNYojtmBFnZYoFR)\"]"

Thanks, that looks right and may help some people. At least on my Linux box here, I can also get away without escaping the inner double-quotes by using single-quotes around the scanobjects: scantxoutset start '["addr(37HyJsnuP5zWTuhJFvrGNYojtmBFnZYoFR)"]'.

Uh, thanks for downvoting but I jsut tried your answer and it didn't work, whereas my answer does work Murch. Your answer gives the error: error: Error parsing JSON: '[addr(37HyJsnuP5zWTuhJFvrGNYojtmBFnZYoFR)]'

Murch, maybe go on strike like your name suggests because your downvote is downright WRONG

I was in fact not one of the users that downvoted your answer, but the one that upvoted it, because it looked right to me… I was merely suggesting another avenue that may work without the escaping (which appears in the rpc doc, and works on my machine). For what it’s worth, the input requirements on RPC commands are pretty confusing. Either way, I think people are downvoting this answer because it’s attacking people instead of ideas, not because it’s incorrect.

Well thanks for upvoting the only answer that worked for me. Yes people don't want to know ideas, they want a belief in authority so they don't have to think.. anyway for anyone that wants an answer that works, there it is.  just had to use this again yesterday.. even chatGPT gives a bunch of wrong answers

I guess I Alex Jones'd the truth..  post real truth and then insult people or say it in a nasty way, and people will downvote it. This is great.. great way to cover up real answers, but that wasn't my goal. my goal was to help real programmers, not snowflake posers.

Thank you for posting the answer that worked for you. You could improve your answer post by mentioning in your answer post what shell or operating system you were using when you found that the syntax proposed in the RPC docs does not work for you, so that other users that encounter the same problem would more easily find your answer or someone could amend the RPC docs.—We expect users on our platform to be nice. If you feel that posts are improved by gratuitous insults, another platform may be a better fit.

@Murch does the same thing on Linux, Mac OS, and Windows 10, including Ubuntu Linux, and some other variants.  I think what is key is the version of the Bitcoin node you are running.  As for being nice, you are not being nice by saying I am not being nice. We expect users to provide answers to questions, be those answers distasteful or not, anyone could be offended by anything these days, but if you get the correct answer that works, that's why WE use this website, not because we are easily offended. If you are easily offended and will downvote a correct answer because of it, go somewhere else

Murch if you are going to censor answers based on your distaste of how they are presented or who says them, there is already a website for that, it is called Wikipedia

I've already explained the rules of our site to you.


text:
How would a centralized block chain work?
If I'm a company who pays my employees and my supply chain with my own currency created on a block chain and they can spend it wherever it is accepted, would I need a POW or POS scheme to maintain the veracity of the ledger of transactions?  Or is there a way to validate the transactions and history of the ledger via centralized control?   Could it work like this:

Only my company could create my currency, so there's no way to counterfeit it.
Everyone who accepts my currency uses software at the point of sale that verifies the transaction and the history of the ledger.
Each unit of currency is embedded with personal ID that transfers to the next person with their personal ID until it eventually recycles back to me, the issuer.

Would I be able to eliminate double spending and fraud in a centralized system without the miners?

Sure. You just use a database that keeps track of who has how much money. You can do this any way you want. You don't need anything fancy like POW, POS, or even a blockchain. The only reason you would need or want these things is to permit decentralized operation without a central authority. If you are the central authority, what you say is law just because you said it. So no need for anything fancy.

Actually there is a centralized block-chain currency Ripple. It is made by a single centered organization which want to reduce the international money transfer charges through wire transfer.
There are many big banks backing it up. It is going to change the international money transfer fees drastically. You can research more about it, just search for Ripple in Google.

Ripple is decentralized: "Decentralized cryptocurrency blockchain daemon implementing the XRP Ledger in C++"

The blockchain is necessary to find consensus among an open set of participants. If you're doing a centralized blockchain, you can just do away with the blockchain. You already have a single source of truth which can operate on the basis of a regular database.


text:
Is it possible to identify a wallet from an address?
I want to know is there anyway to identify a particular wallet (its username or email address) on the basis of a Bitcoin receiving address which is generated from that wallet. I am posting that address below:
1F5b254fXvpVqCKPMwF3tL1aKzCQSf4koe

If you've added "blockchain.info" because you know that you generated the address on blockchain.info, you should try to contact the customer support.

No, there is not.
Bitcoin is what is called "pseudonymous", meaning that a bitcoin address does not reveal information about the owner of that address.  Bitcoin addresses (like the one you posted) are derived by using two types of cryptographic operations, elliptic curves and hash functions...both of which only operate in one direction.  Even if you could reverse this process for a given address, all you have is a private key.  That private key does not contain any information about who generated the key, nor which other keys/addresses are associated with it.
There are blockchain analysis techniques that can be performed to attempt to associate a bitcoin address with other addresses (with a variable degree of certainty), but even that will not give you what you are looking for unless you can associate one of those addresses with someone's identity.  This would require your query to be supplemented with additional information not found on the Bitcoin blockchain.  If you do not possess that additional information, you cannot associate an address with an identity.


text:
LND describegraph and getnetworkinfo RPC response
The LND API documentation is here, but doesn't contain much information about what the responses to various calls mean. Can anyone explain what these responses are describing?
describegraph['edges']
I understand this to be channel data, but not sure exactly what it's describing.

"time_lock_delta": 14,
"min_htlc": "0",
"fee_base_msat": "546000"
"fee_rate_milli_msat": "10"

getnetworkinfo

"avg_out_degree": 2.841628959276018
"max_out_degree": 102

After looking into the code and running some tests I think I've found the answers:

avg_out_degree is the average channels per node. In other words, total channels / total nodes = avg_out_degree. source
max_out_degree is the maximum channels (sum of incoming and outgoing) found on a node in the network. This can be found by iterating through every node and summing their incoming/outgoing channels to find the maximum. source
time_lock_delta: the required timelock delta for HTLCs forwarded over the channel. source
min_htlc: the minimum value in millisatoshi required for incoming HTLCs on the channel. source
fee_base_msat: the base fee charged regardless of the number of milli-satoshis sent. source
fee_rate_milli_msat: the effective fee rate in milli-satoshis. The precision of this value goes up to 6 decimal places, so 1e-6. source


text:
Is it true that two thirds of available bitcoins have already been mined?
The following commentator writes:

More than two-thirds of all available bitcoin have already been mined, with the majority going to early miners.

My question is: Is it true that two thirds of available bitcoins have already been mined?

Indeed it is true, as seen here: http://www.bitcoinblockhalf.com/
As of writing this answer, just over 16.6 million BTC has been mined, out of a total of just under 21 million, which is around 79% of the total amount of bitcoin ever going to be created.


text:
Why bitcoin is not inflationary?
I understand that a lot of people today stack Bitcoin instead of spending them and that makes sense because there is a limited number of bitcoins.
However, I think that for bitcoin to be a real currency that people use everyday there should not be a limited number of bitcoin so people could freely spend them without to care.
Why bitcoin was made this way with a limited number of bitcoin ?

If one could simply "print more" Bitcoins, then it would quickly lose its value (this is the definition of inflation btw) because of increased supply. This is the main reason why, for instance, the USD has lost so much value in the last 50 years.
People invest in Bitcoin because they think it will increase in value, not because there is a limited supply. Lots of stuff is limited, but have no value.
Throughout history, inflationary currencies (ie currencies without a cap) have all lost their value and collapsed. This includes thousands of fiat currencies and will most likely include the ones we're using today.
You say that money must be inflationary for it to work?
Well, gold is not inflationary but has been used as currency for thousands and thousands of years. In fact, it was used as world currency up until 1971. Apparently gold worked, right?
Consider this... Two villages. One produce fish and the other coconuts. They buy from each other. They each have 10 Bitcoins each. Let's print more Bitcoins -- let's double the number of coins and give them out to each village! They still produce the same amount of fish and coconuts. What's going to happen now? Yes, the price of fish and coconuts will double! In effect, the value of each coin just got cut in half. That is the effect of (uniform) inflation. (*)
Or, simply put: If every person's bank account is doubled, then all prices will double as well. So changing the amount of currency uniformly like that is pointless. Nothing really happens.
But wouldn't a non-inflationary currency cause prices to drop (and, thus the currency value to raise)?
You're correct! But there are forces which work to counter that effect. Let's look at gold again:
On a fixed gold standard, prices would indeed fall slightly year by year. (By the way, this is fundamentally a good thing).
The reason prices fall is because the amount of goods increases due to increased productivity while the amount of gold stays the same. In other words, prices go down while the price of gold goes up. But (and this is important!) higher gold prices also gives gold miners strong incentives to mine more gold! So more gold is produced which enters the economy. More gold in circulation will eventually lower the gold price (and raise prices again) until miners don't earn enough and they stop mining. Which leads to higher gold prices (ie lower prices of goods) AND... the cycle repeats again.
And that is why prices on a "fixed" money base stays stable.
But what about Bitcoin?
The stuff you just read (above!) about applies to Bitcoin a well, but there is a huge problem:
The Bitcoin price is not even remotely predictable.
I agree that it wouldn't be wise to buy one pizza with Bitcoins today, when you can buy 10 pizzas tomorrow. You see, for us to call something money, it has to to be stable. Otherwise, it's impossible to make economic calculations. So until (if) Bitcoin becomes stable, no-one is going to use it as money for practical reasons.
So for the time being, you should consider Bitcoin an asset for investment, not money.

(*) This is extremely simplified, particularly as I ignore the harmful Cantillon effect. Inflation (money supply increase) in the real world, causes enormous amounts of problems, one of which is that it acts taxes the most unfortunate of us.

Thanks for your answer!
But so you say that people invest in Bitcoin because they hope it will increase in value. So no one will use it as a currency right ?

I see no contradiction there. My guess is the underlying (long term) value is that it may, someday, be used as a major currency. It's the same case as for gold really. Except gold was indeed used as the world currency until pretty recently, 1971 in fact.

I agree that Bitcoin looks really close to gold and that makes it a great store of value for people but I just think that it goes against the idea of a currency, don't you think ?
Why should I spend the bitcoin I have today as I know that there is less and less bitcoin ? I will never buy a pizza or anything with my bitcoin that would be counter-economic effective.
For me this goes against the idea of Bitcoin as a currency and I do not understand it :)

Alright, I updated the answer. In short, you're correct that Bitcoin is not a currency (at the moment) but not for the reasons you think. :-)

there should not be a limited number of bitcoin so people could freely spend them without to care.

Because of its limited supply, the people who have them think before spending. All the radical expenditures which large economies make are because there is no short term implications on such because the shortage of currency can be taken care of by printing more of it. But on the long term, when the expenditures don't bring results as expected, the devaluation of the currency hurts the economy more on the long run. Link to Wikipedia article on money supply.
This is one of the thing which Bitcoin wants to solve/or people who are bitcoin evangelists tell. Like getting a pay hike of 5% and increase in commodity prices by 5% makes no difference in the end for anyone, increase in amount of currency in flow and prices for commodity will make no difference.
Also, take this into account that the minimum possible transaction in Bitcoin is a Satoshi which is 0.00000001 BTC. So even if there is a day when 1BTC is $1 million, 1 Satoshi would be 1 cent.


text:
Explain Coinomi and Edge fee difference?
I was looking at two Bitcoin wallets, Coinomi and Edge.
When setting the same custom fee for both, I see a difference in the final fee reported.
As an example, Edge wallet shows a fee of $3.13 (at 200 sats/Byte), while Coinomi shows $4.85.
I'm using the same destination address and amount for both.
Can someone explain this difference in fee?
Will the higher price Coinomi transaction be confirmed in fewer blocks?
Have you come across this before?
Thanks.

Adding to Murch's response and comments, Coinomi does have UTXO control where you can set individual UTXOs as "do not spend" and indirectly control which ones will be used on your transaction. Number and type of inputs in a transaction is one parameters that influence the transaction size (and thus the fees) the most.
Unless you change a privacy option in Coinomi's settings, all change of your transactions is sent to a bech32 address. This contributes to smaller transactions. If you are having higher fees with Coinomi, most likely you have a larger number of small UTXOs, causing the final transaction size to be larger.
Full coin control at the time of sending is a feature planned for the future. Details for how to manage UTXOs in Coinomi can be found here: https://coinomi.freshdesk.com/support/solutions/articles/29000030928-managing-your-utxos

Given that you are looking at two different wallets on two different pieces of software, the transactions that the wallets are proposing are different:

they may be using a different count of inputs
one may be using segwit inputs while the other uses non-segwit
one might be a multisig wallet while the other is single-sig
one of them might be able to avoid a change output, while the other doesn't

This will cause the two transactions to have a differing size. Lastly, the two wallets may be using different price sources to translate it to dollars.
As the transactions' priority is determined by their fee rate, both of these transactions are equivalently prioritized at 200 sat/B. The size difference is unlikely to make a big difference for block inclusion.

Am I understanding correctly that the price different is due to the difference in size of the transaction being created? If so, can part of the size difference be due to one wallet being more efficient - or is that not possible?

@kayan1 It is difficult to say for certain about your specific case without more info. A wallet can be more efficient if it: utilizes UTXOs efficiently, uses native segwit addresses, etc. But it could also just be a result of the UTXO set the wallet controls. If you are worried about the details like this, you could consider using a wallet that allows for manual UTXO selection.

@chytrik. Thanks for explaining. I'm not really worried but just wanted to know why this would occur. I think the only wallet that lets manual UTXO selection would be Wasabi, right? I think Moonshine wallet also has some sort of coin control option.


text:
How can I start bitcoind without blockchain synchronization?
Suppose I make a locked wallet with 50000 pre-generated addresses.
As long as I researched, only way I can collect those 50000 addresses using RPC and "getnewaddress". Feel free to correct me.
I understand this will took several hours or days, so I can set this up on some VPS and let it run.
For this I do not need blockchain to be synchronized.
How can I start bitcoind without blockchain synchronization?
I am thinking about "connect" option or testnet, but both looks like a hack.

You could also run dumpwallet, which would have the addresses in the resulting dump - although at this point, you might want to look into a small script to generate an HD wallet, it will likely go a lot faster.

dumpwallet requires passphrase.

The recommended way is to use the -connect option. You can do -connect=0 or -noconnect (they mean the same thing) and Bitcoin Core will not try to automatically connect to any other node.

works like a charm. added connect=0 in the config file


text:
How can I sell Bitcoin for GBP?
I'm a bit of a dunce and just not getting it - I was persuaded to buy a bitcoin a few years ago and would now like to sell the thing to do up my kitchen. I have a bitstamp account and a blockchain wallet, but can't figure out for the life of me how to get my coin into my bank account as GBP - do I need the blockchain wallet, or should I/can I do it direct from bitstamp?
I'd really appreciate some pointers. TIA.

No worries, selling Bitcoin for GBP is a common process, and it’s great that you already have a Bitstamp account. Here's how you can do it:
Transfer Bitcoin to Bitstamp:
Since your Bitcoin is in a Blockchain wallet and Bitstamp is your exchange, the first step is to transfer your Bitcoin from the Blockchain wallet to your Bitstamp account. To do this:
Log in to your Bitstamp account.
Go to the "Deposit" section and select "Bitcoin."
Copy your Bitcoin deposit address from Bitstamp and paste it into the "Send" field of your Blockchain wallet.
Confirm the transfer, and your Bitcoin should appear in your Bitstamp account within a short time.
Sell Bitcoin for GBP:
Once your Bitcoin is in your Bitstamp account, you can sell it for GBP:
Go to the "Trade" section of Bitstamp.
Select Bitcoin (BTC) and GBP (British Pound) as the trading pair.
Enter the amount of Bitcoin you want to sell and execute the trade.
Withdraw GBP to Your Bank Account:
After selling your Bitcoin for GBP, you can withdraw the funds to your bank account:
Go to the "Withdraw" section in Bitstamp and select "GBP."
Enter your bank account details and the amount you wish to withdraw.
Confirm the withdrawal, and your funds should be transferred to your bank within a few days.
A Few Pointers:
Fees: Bitstamp may charge fees for trading and withdrawals, so make sure to check their fee structure.
Blockchain Wallet: You need the Blockchain wallet to store your Bitcoin initially, but you don’t need to use it when selling. Bitstamp will handle the exchange and withdrawal to GBP.
If you're looking for an even easier way to sell Pi Coin or Bitcoin, feel free to check out Sell Pi Coin Instant for quick and hassle-free transactions.
This process should help you turn your Bitcoin into GBP and get that kitchen makeover! Let me know if you need more guidance!

I have no idea about bitstamp. The service I use is https://www.solidi.co/ You can simply create an account there, transfer your bitcoins in and sell them. You should do some research about which sites give the best price etc., but generally it's that simple. I've used solidi.co in the past without problems.


text:
What happens to coins after Bitcoin Cash fork?
I'm new to Bitcoin and I read that there is a fork going to happen on Aug 1st to create Bitcoin Cash (BCC). From https://ethereumprice.org/ethereum-classic-and-bitcoin-cash/?a=1&b=https://ethereumprice.org/ it is estimated that Bitcoin Cash is going to have a value of ~$310. And it also says that the balance of Bitcoin (BTC) in a wallet will be copied to Bitcoin Cash.
So if I have 1BTC now, which values to ~$1700, after fork, I can have 1BTC + 1BCC with an approximate value of $2000. Is this correct?

If you have 1 Bitcoin (BTC) before the hard fork, you will have 1 Bitcoin (BTC) and 1 Bitcoin Cash (BCC) after the hard fork.
Whether you can spend those BCC depends on who has control of your private keys.
If you currently keep your BTC on an exchange (Coinbase, GDAX, Poloniex, ...) you need to check their policy w.r.t. the fork, since they control your private keys for you.
Coinbase for example has expressed that they will not interact with the BCC blockchain. This means that you will not be able to spend/sell your BCC until they either interact with the BCC blockchain or release your private keys to you.
If you keep your BTC in a paper wallet, you have control over your private keys, and 1 BTC will indeed result in 1 BTC and 1 BCC after the fork.
Today the value of 1 BTC is roughly $2700. BCC futures were trading for $350 last time I checked.
What the value of 1 BTC + 1 BCC will be after the fork is hard to predict and is subject to demand and supply on the markets.

Coinbase has changed plans: "We are planning to have support for bitcoin cash by January 1, 2018, assuming no additional risks emerge during that time."


text:
Is the any workable testnet3 Bitcoin solution for creating, signing, broadcast a normal transaction using Golang?
Currently I'm trying to create, sign & broadcast bitcoin transaction using btcsuite. For start, I've already had testnet3 address & its associated privatekey for testing. However, hunting through the post and articles like below:-

here
here
here

The solution proposed above its not complete, for first one, it only covers until signing (i knew the author claimed its not broadcastable unless you provide the utxo which i did if i'm right) but when tried to braodcast it failed with message
"Error validating transaction: Transaction be9b294695bfb201a5cff32af074a4bf72b073e3c9dad1969111165bf118a622 orphaned, missing reference f0c0d3b3eecf911ede996a74ceadc9366068791450c9e6bacee9ae202f3690d1."
I have no idea what's going on and I suspect its script is incompatible.
So, the bottom line is I just want a workable example in bitcoin testnet3 that shows
"from 1 address transfer some bitcoin to other address" by showing the process of creating raw transaction, sign it with private key, turn it to raw transaction in hex format & broadcast it using something like https://live.blockcypher.com/btc/pushtx/ (BTC testnet)
currently my code is as follow:-
package main
import (
    "fmt"
    "encoding/hex"
    "bytes"
    "github.com/btcsuite/btcutil"
    btcchain "github.com/btcsuite/btcd/chaincfg"
    "github.com/btcsuite/btcd/chaincfg/chainhash"
    "github.com/btcsuite/btcd/txscript"
    "github.com/btcsuite/btcd/wire"
)
func txToHex(tx *wire.MsgTx) string {
    buf := bytes.NewBuffer(make([]byte, 0, tx.SerializeSize()))
    tx.Serialize(buf)
    return hex.EncodeToString(buf.Bytes())
}

func stkbtc(){
  pvkey := "cNjXNxcfawzyfGUxaG94rKqayAL2n7QWioKhCkHbQsBRT7SbDyGu"
  txHash := "e028b5bf030a24986a03b03b89dec037e8462ae32bc93679cb49d7c779685987"
  destination := "n2kRiAkW1xr5DVy7QKVGaYiZbwpS7j23jJ"
  var amount int64 = 100000000
  txFee := int64(500000)

  //try send btc
  decodedwif,err := btcutil.DecodeWIF(pvkey)
  if err != nil {
    fmt.Printf("decodedwif error: %v\n",err)
  }
  fmt.Printf("decodedwif       : %v\n",decodedwif)

  addresspubkey, _ := btcutil.NewAddressPubKey(decodedwif.PrivKey.PubKey().SerializeUncompressed(), &btcchain.TestNet3Params)
  sourceTx := wire.NewMsgTx(wire.TxVersion)
  sourceUtxoHash, _ := chainhash.NewHashFromStr(txHash)

  sourceUtxo := wire.NewOutPoint(sourceUtxoHash, 0)

  sourceTxIn := wire.NewTxIn(sourceUtxo, nil, nil)
  destinationAddress, _ := btcutil.DecodeAddress(destination, &btcchain.TestNet3Params)

  sourceAddress, err := btcutil.DecodeAddress(addresspubkey.EncodeAddress(), &btcchain.TestNet3Params)
  if err != nil {
    fmt.Printf("sourceAddress err: %v\n",err)
  }

  destinationPkScript, _ := txscript.PayToAddrScript(destinationAddress)

  sourcePkScript, _ := txscript.PayToAddrScript(sourceAddress)
  sourceTxOut := wire.NewTxOut(amount, sourcePkScript)

  sourceTx.AddTxIn(sourceTxIn)
  sourceTx.AddTxOut(sourceTxOut)
  sourceTxHash := sourceTx.TxHash()

  redeemTx := wire.NewMsgTx(wire.TxVersion)
  prevOut := wire.NewOutPoint(&sourceTxHash, 0)
  redeemTxIn := wire.NewTxIn(prevOut, nil, nil)
  redeemTx.AddTxIn(redeemTxIn)
  redeemTxOut := wire.NewTxOut((amount - txFee), destinationPkScript)
  redeemTx.AddTxOut(redeemTxOut)

  sigScript, err := txscript.SignatureScript(redeemTx, 0, sourceTx.TxOut[0].PkScript, txscript.SigHashAll, decodedwif.PrivKey, false)
  if err != nil {
    fmt.Printf("sigScript err: %v\n",err)
  }
  redeemTx.TxIn[0].SignatureScript = sigScript
  fmt.Printf("sigScript: %v\n",hex.EncodeToString(sigScript))

  //Validate signature
  flags := txscript.StandardVerifyFlags
  vm, err := txscript.NewEngine(sourceTx.TxOut[0].PkScript, redeemTx, 0, flags, nil, nil, amount)
  if err != nil {
    fmt.Printf("err != nil: %v\n",err)
  }
  if err := vm.Execute(); err != nil {
    fmt.Printf("vm.Execute > err != nil: %v\n",err)
  }

  fmt.Printf("redeemTx: %v\n",txToHex(redeemTx))
}

func main(){
    stkbtc()
}

the txhash was from previous transaction where i got the testnet bitcoin from faucet & nothing else..

Sender address: mpYGA8wRCArpGTs6aJMmZRWyUuPoZmeLJv
Sender public key: 02217deb8b3782236fa8214da94bd5a9338f2eeb3299c39c057fb68ada63d93df7
Sender private key: cNjXNxcfawzyfGUxaG94rKqayAL2n7QWioKhCkHbQsBRT7SbDyGu
Target address: n2kRiAkW1xr5DVy7QKVGaYiZbwpS7j23jJ

Please advice what is wrong with the code above, really appreciate it if someone can point it out.

It seems the the UTXO couldn't be found: https://www.blocktrail.com/tBTC/address/mpYGA8wRCArpGTs6aJMmZRWyUuPoZmeLJv/transactions

hi, can you explain in detail what couldn't be found? the address mpYGA8wRCArpGTs6aJMmZRWyUuPoZmeLJv was funded by faucet, thus the unspent should be there as shown. https://live.blockcypher.com/btc-testnet/address/mpYGA8wRCArpGTs6aJMmZRWyUuPoZmeLJv. care to elaborate more?

The UTXO wasn't there yesterday, so please try it again.

i've tried, its still the same. it still return Error validating transaction: Transaction 58521a5f97cbb02e4967132f872edbe7c60677da9ef4d018f4feeca0847ce2a2 orphaned, missing reference f12111c6bc76aa6d8346ab20e7e767118b6fafc9cde14366b19d77937b09daaf.

I guess I found the problem: The code generated a fake transaction that created the UTXO, and referenced its TXID instead of the TXID of the real transaction.
The new code:
package main

import (
    "bytes"
    "encoding/hex"
    "fmt"
    btcchain "github.com/btcsuite/btcd/chaincfg"
    "github.com/btcsuite/btcd/chaincfg/chainhash"
    "github.com/btcsuite/btcd/txscript"
    "github.com/btcsuite/btcd/wire"
    "github.com/btcsuite/btcutil"
)

func txToHex(tx *wire.MsgTx) string {
    buf := bytes.NewBuffer(make([]byte, 0, tx.SerializeSize()))
    tx.Serialize(buf)
    return hex.EncodeToString(buf.Bytes())
}

func stkbtc() {
    pvkey := "cNjXNxcfawzyfGUxaG94rKqayAL2n7QWioKhCkHbQsBRT7SbDyGu"
    txHash := "e028b5bf030a24986a03b03b89dec037e8462ae32bc93679cb49d7c779685987"
    destination := "n2kRiAkW1xr5DVy7QKVGaYiZbwpS7j23jJ"
    var amount int64 = 100000000
    txFee := int64(500000)

    //try send btc
    decodedwif, err := btcutil.DecodeWIF(pvkey)
    if err != nil {
        fmt.Printf("decodedwif error: %v\n", err)
    }
    fmt.Printf("decodedwif       : %v\n", decodedwif)

    addresspubkey, _ := btcutil.NewAddressPubKey(decodedwif.PrivKey.PubKey().SerializeUncompressed(), &btcchain.TestNet3Params)
    sourceUtxoHash, _ := chainhash.NewHashFromStr(txHash)

    sourceUtxo := wire.NewOutPoint(sourceUtxoHash, 0)

    sourceTxIn := wire.NewTxIn(sourceUtxo, nil, nil)
    destinationAddress, _ := btcutil.DecodeAddress(destination, &btcchain.TestNet3Params)

    sourceAddress, err := btcutil.DecodeAddress(addresspubkey.EncodeAddress(), &btcchain.TestNet3Params)
    if err != nil {
        fmt.Printf("sourceAddress err: %v\n", err)
    }

    destinationPkScript, _ := txscript.PayToAddrScript(destinationAddress)

    sourcePkScript, _ := txscript.PayToAddrScript(sourceAddress)
    sourceTxOut := wire.NewTxOut(amount, sourcePkScript)

    redeemTx := wire.NewMsgTx(wire.TxVersion)
    redeemTx.AddTxIn(sourceTxIn)
    redeemTxOut := wire.NewTxOut((amount - txFee), destinationPkScript)
    redeemTx.AddTxOut(redeemTxOut)

    sigScript, err := txscript.SignatureScript(redeemTx, 0, sourceTxOut.PkScript, txscript.SigHashAll, decodedwif.PrivKey, false)
    if err != nil {
        fmt.Printf("sigScript err: %v\n", err)
    }
    redeemTx.TxIn[0].SignatureScript = sigScript
    fmt.Printf("sigScript: %v\n", hex.EncodeToString(sigScript))

    //Validate signature
    flags := txscript.StandardVerifyFlags
    vm, err := txscript.NewEngine(sourceTxOut.PkScript, redeemTx, 0, flags, nil, nil, amount)
    if err != nil {
        fmt.Printf("err != nil: %v\n", err)
    }
    if err := vm.Execute(); err != nil {
        fmt.Printf("vm.Execute > err != nil: %v\n", err)
    }

    fmt.Printf("redeemTx: %v\n", txToHex(redeemTx))
}

func main() {
    stkbtc()
}

Summary of the differences:

(I haven't published the new transaction)

i've tried generating the raw tx based on the updated code you presented, good thing is there's no validation error on console, but upon broadcast to blockcypher btc testnet, it's still throw error "Error validating transaction: Error running script for input 0 referencing e028b5bf030a24986a03b03b89dec037e8462ae32bc93679cb49d7c779685987 at 0: Script was NOT verified successfully.."
improvement is, its a different error.. but now it's much more less information to troubleshoot; any suggestions? perhaps the code itself is already incorrect? what would be the proper way to do it? please advice


text:
Using bitcoin-qt. Address with my funds does not show up. Can I import it?
I have bitcoin-qt and was just recently aware that it changes addresses all the time. I am afraid that my last wallet.dat backup was before my last transaction, at which the receiving address was changed.
After that, I had to reinstall my computer. Bitcoin-qt is still 2yrs behind and syncing.

will the other address show up eventually?
I have all my seeds, keys and so on. Is there a way to claim my BTC that are on the address?

You're probably safe. If you were using an old version of Bitcoin Core, it used to keep a key pool of 100 unused addresses around. When you request a new receiving address, one from that pool gets used. So, unless you received numerous transactions between the backup and the last transaction, your last transaction should be covered by the backup containing these 100 unused addresses.
If you're using a new version of Bitcoin Core, its wallet uses a hierarchical determistic key derivation where a single backup will always be enough to regenerate any later generated addresses.
Therefore, you should see our transactions appear when your Bitcoin wallet has synchronized with the current state of the network.

I can also confirm that this still works if you have a wallet.dat from 2013 and use the software from 2017.

@Ulu83: Yay, glad that it worked out for you. :)


text:
Preventing sybil attacks : How does bitcoin get to know the computing power of a node?
I know that bitcoin prevents sybil attacks through proof of work - which takes into account the computing power of each participating node . So how does bitcoin get this information ?

Most nodes these days do not mine at all, nor do they care who exactly is contributing hashpower to the network.
Proof of work does not prevent a sybil attack from occurring, rather the required work to create a block makes it costly for a successful sybil attacker to feed the victim a tailored chain-tip. Unless uses immense hashpower, they can at best hand the victim a doublespend transaction while withholding the new blocks and transactions relayed on the rest of the network. Simply waiting for one or more confirmations corresponding to the value of the transaction largely mitigates the dangers of a sybil attack.
On the other hand, sybil attacks itself are difficult because Bitcoin nodes initiate eight outbound connections to random peers in the network preferring nodes in different IP ranges. Whereas an attacker could perhaps gain control of a lot of inbound connections after identifying the victim's IP address, replacing the outbound connections would be a lot more difficult. Yet, as long as the node connects to just a single honest peer, a doublespend attack as mentioned above would be foiled.

A Bitcoin client does not know, nor need to know the computing power of the nodes it connects to.  It only needs to know the computational power that went into the chain of blocks that the connected nodes are sending.
While this does not fully prevent sybil attacks, it makes them much more difficult.  A node will independently verify the work that has gone into a chain, so that is something that cannot be spoofed.  If there is a discrepancy between the amount of work that two connected nodes claim (communicated by the blocks they broadcast), then a client knows that the one with the least work is probably doing something malicious.
Only if an attacker can ensure that they control all the nodes the victim has ever connected to, can they really pull off a sybil attack.  Even so, the owner of that node can compare his own node's blockchain state against that of an online blockchain explorer, and quickly see that something is amiss.


text:
Reducing block generation time
Is there any drawback to reducing the time it takes to generate POW, essentially reducing block generation time and confirming transactions faster.

What if the difficulty is reduced so that the POW can be generated/mined in within a minute - in tens of seconds.

What will be the potential issues if this is done, can this be done safely?

Thanks, this was helpful.
I am looking for more information and details on how it impacts security. Is there any detailed information available?


text:
Bitcoin public key pre-0.6 length before hashing
As I understand, since bitcoin 0.6.x, compressed and uncompressed public keys are supported. And the process from the public key to the address has the step that puts a byte in front of the public key before hashing, like:
0x04<256bit x><256bit y> = buffer before hashing the uncompressed public key
or
[0x02|0x03]<256bit x> = buffer before hashing the compressed public key
That implies that the buffer before the hashing is either 33bytes long or 65 bytes long.
My question: pre-0.6, all the way back to the first public version of bitcoin, is the buffer pre-hashing always 65 bytes long, since compressed keys were not supported? Or was it 64 bytes long (just <256bit x><256bit y>) and there was no byte for the version prepended before hashing?
If it was just the 64bytes of the public key on clients pre-0.6, that means that for the same public key, if I ran that public key through the code path of both pre-0.6 bitcoin client and current bitcoin client (uncompressed fomat), the final bitcoin address would still be different, since the modern client would prepend the version byte?

is the buffer pre-hashing always 65 bytes long,

yes

since compressed keys were not supported?

they were not used by anybody. but there were no changes in client to "implement/support" them

Or was it 64 bytes long (just <256bit x><256bit y>) and there was no byte for the version prepended before hashing?

no. the client was written with openSSL library. This library always appends prefix to public key bytes (this is standard encoding defined somewhere)


text:
Found my Multibit.key wallet back up, but I do not remember the password, what next?
I created a Multibit wallet back up many years ago and it was saved as multibit.key.
I am now trying to import this back into MultiBit Classic and it is asking for a password. I have forgotten the password.
Is there anything I can try? Is brute forcing an option? What type of software would I have to use?
Cheers

You can try using btcrecover to attempt to brute force your password. However, if you have no idea what the password could be, then it isn't going to be able to help much.

Did you fix the issue with password? If you really dont recall the password, there is no way but bruteforce as stated above by @ava although I can make it super fast.

@Danny, you can see my github and repost as reference.


text:
How does Bitcoin Gold difficulty adjustment work?
Bitcoin Gold claimed to have per-block difficulty adjustment, how does it work? I find this https://github.com/BTCGPU/BTCGPU/pull/151, but still don't understand how it work by change some parameters.

It's just a simple moving average with a window of 30 blocks:
next_D = sum(past 30 D) / sum(past 30 solvetimes) * 600

This isn't exactly what it's doing, but it's darn close.

Thank you. Is this fomula calculated every blocks? And why is 600?

Time is calculated in terms of millisecond i believe


text:
Why not implement GHOST in bitcoin?
GHOST can provide higher transaction throughput by minimized block interval, but community people seldom mention it. What's wrong with GHOST?

Side note if the bitcoin community wouldn't even allow for 8MB blocks or segwit2x I doubt they would even think about GHOST.

GHOST is outdated, the more relevant protocol based on recent research by Aviv Zohar et al is called "SPECTRE" - https://medium.com/@avivzohar/the-spectre-protocol-7dbbebb707b5, https://eprint.iacr.org/2016/1159.pdf.
It has many advantages over the traditional longest-chain rule of Bitcoin, but:

It requires a hard fork, something which has never been done intentionally in Bitcoin.
It is a huge departure from Bitcoin's protocol, and as such it will require extensive research and testing before it is even considered for inclusion in Bitcoin.

There are alts under development that are trying to implement SPECTRE, if it works well for them it can be a first step towards consideration in Bitcoin. You don't risk untested ideas on a $100B production system.

Thank you! This 2 points are so called "bitcoin conservative" right?

What alts are trying to implement SPECTRE?

@Meni, are there any trade-offs?

@AndersonC: You could say that, they are both related to the rigor required to make changes in Bitcoin. I'm not sure about the specific alts, but I'm sure we'll all know when they're ready.

@renlord - SPECTRE is more computationally intensive than longest chain. Furthermore, the main advantage of SPECTRE is that it allows shorter time between blocks without losing hashpower, but this has other tradeoffs, notably more resource requirements from SPV clients. Other than that, AFAIR SPECTRE is strictly superior, though I may be missing something.

FYI PHANTOM is the latest reincarnation of GHOST/SPECTRE.
https://www.youtube.com/watch?v=57DCYtk0lWI

BIP 50 was a hard fork.

@MCCCS: That was an emergency patch rather than a planned protocol upgrade, I don't think it counts. Anyway, I'll try to work on the phrasing.

One thing to note also is that even ethereum is not using GHOST and I dont see any coin using some sort of ghost or phantom protocol at this point, so yeah its hard to expect bitcoin will jump to it before it is tested elsewhere.
https://ethereum.stackexchange.com/questions/38121/why-did-ethereum-abandon-the-ghost-protocol

We are using a modified version of Ghost at Hycon. The original plan was to move forward with Spectre, but as yet there are some unsolved issues, particularly around selfish mining and efficient resolution of superposition states at the tips of the DAG. Ghost is useful when the block time is shorter and orphan events are more common. In the case of bitcoin, these days orphan events are rare, so unless it was decided to reduce the block time it is unnecessary.

ghost also massively amplifies selfish mining... my understanding is that this is why ethereum dropped it.  Impressive that there are other altcoins more recklessly yolo than ethereum...

Our implementation includes the difficulty from uncle blocks as part of our dynamic difficulty adjustment, negating selfish mining strategies as laid out here. To quote the article "(a difficulty algorithm) based on the chain weight (weight/time), then mining uncles would not increase the rate of the best chain, and uncle mining would be prevented."


text:
TRUC transactions (version = 3) general availability
Given that "2 package RBF" and "V3 transactions" are merged in the main branch, which release TRUC transactions would be available? Thank you!
Relevant PRs:
https://github.com/bitcoin/bitcoin/pull/28984
https://github.com/bitcoin/bitcoin/pull/29496

The pull request doc: use TRUC instead of v3 and add release note #30272 states that the TRUC Policy will be live in v28.0 and adds release notes to that effect.


text:
Understanding v28.0 PayToAnchor script
I am trying to understand the new PayToAnchor script, which is part of v28.0. Here is the script definition:
https://github.com/bitcoin/bitcoin/blob/master/src/script/script.cpp#L207-L222
As I understand, the above script would translate to following:
op_true op_pushdata4 2 4e73
Can someone please confirm that this is correct understanding? Also, what the reason for this particular script for PayToAnchor? It appears that it is not validated - interpreter.cpp#VerifyWitnessProgram, so the script could have been anything else. Is there any specific reason for using this particular script for PayToAnchor?

This Script is a 2-bytes-long version 1 witness program. It's a witness program to benefit from txid non-malleability. It's a version 1 program because for version 0 any program not 20 or 32 bytes long is invalid. It's 2 bytes long because it is the minimum length of a witness program.
The two bytes of the witness program were chosen as a vanity address. The bech32m encoding of the Script is bc1pfeessrawgf, which contains the word "fees".
The Script is slightly different from your understanding. It's OP_1 <0x4e73>, or as a byte array [0x51, 0x02, 0x4e, 0x73].


text:
Why can't a Bitcoin fork take over?
According to this question's answers, the difficulty is entirely a result of previous info on a blockchain:
How is difficulty calculated?
So why can't someone simply fork an earlier state of Bitcoin's blockhain, back when the difficulty was far less, and simply pretend it always took a long time to solve an easy (by now) hash problem, ie simulate a bitcoin world where no ASIC were released etc.
According to that chain, the hash rate would be low and thus a perfectly valid chain could be made with fake transactions, mined in secret many years into the future.
If Bitcoin modes really simply consider the longest chain the valid one, wouldn't this totally bork the whole Bitcoin ecosystem? I hope that "longestt chain" actually means "most proof of work" rather than "most blocks"!

I hope that "longestt chain" actually means "most proof of work" rather than "most blocks"!

It is exactly that: the "longest chain" is the one with the most work, not the largest block height.
If it wasn't like that, then an attack like the one you described could work.

Can you link to an authoritative source?

@GregoryMagarshak I believe this is the code you're looking for, notice that it uses 'nchainwork', rather than 'blockheight' to decide what the longest valid chain is.


text:
What if next block cannot be mined?
AFAIK to create the next block, there must be a specific structure (specific number of leading zeros) in the has output calculated on the block's header. This header contains a set of fixed parts (merkle tree, previous block's hash, ...) and two variable parts: nonce and timestamp.
Now, what if all combinations of timestamp and nonce do not result in the desired output to validate the block? (At least for a long duration, like a week).

Not only can the nonce be varied, but also some information in the scriptSig of the coinbase transaction in the block, which would change the merkle root, so there should always be enough to find a hash within the target.
The difficulty of finding a block is recalculated every 2016 blocks to give an average time of 10 minutes between blocks. Because of the sheer amount of processing power going into the network, this is pretty reliable, its just not going to take an entire week. If blocks were taking longer than expected, the difficulty would reduce at the next retarget to compensate.


text:
Encrypted message with nLockTime
I know you can delay a transaction's accepted date by using nLockTime. I'm still looking for the simplest way to generate a transaction with nLockTime, but that's another topic.
I'm wondering if there's a way to use this feature to send a message that will only decrypt after the time is due.
I know that a transaction broadcast with nLockTime already has all details visible and the amount is simply not yet spendable by the recipient. Is there a way to also make the note on that transaction encrypted until such date? Can I use bitmessage to achieve this somehow? How about another coin such as Dash or zCash which I assume also encrypt the transaction's note to anyone except the recipient [do they actually do this, especially Dash]?
The idea is to send a message that only the recipient can decrypt and only after a certain date, with no manual intervention in the future, nor anything else involved. It would be ideal if they received that message in their wallet like any transaction after it's due, but the message shouldn't be viewable by others nor by the recipient in advance searching, say, in a block explorer.
Thank you

I don't think that's possible.

I don't think that is possible with only nLockTime. There are however "smart" contracts, by using a 2-of-2 multisignature where each party deposits an insurance worth more than the shared secret. The economic loss is more than they gain if both parties don't follow through on their part of the deal.
On a note, this would actually be possible with the technology currently used ZCash. Using zk-SNARKS, you could generate proof that a piece of content is encrypted by key X. In that same zk-SNARK signature you could prove that hash(X) = Y and create an economic construct that will only allow a transaction after X is revealed, creating Y and allowing a party to get their money.

Very interesting, thank you. Where could I find such contracts? Are you talking about ethereum-based contracts?

@Nikksno These contracts are also possible on Bitcoin, using the OP_CLTV. Basically past block X, you destroy access to all funds for both parties. This is mainly a economical construct, research the Nash equilibrium. The best example I can find is probably https://voluntary.net/bitmarkets/whitepaper/

No. There is no way for anything to be encrypted in a Bitcoin transaction as there are no opcodes that support encryption or decryption.

That's not relevant. Even if such opcodes existed, they wouldn't let you (1) decrypt something that others can't since everything in the chain is public and (2) change in behaviour after some time.