Bitcoin Core Update from 0.13 to 0.15 and still verifying block, descending "new best chain"

Bitcoin Core 0.13.0 did not have SegWit's activation parameters (they were added in 0.13.1). This means that after SegWit's activation, your full node was not aware of it, and thus did not ask for or verify block witnesses.

Bitcoin Core is a fully validating node, so after upgrading to 0.15 it noticed that blocks were present that were missing witnesses, and as result also didn't have those witnesses validated. As a result, it is rewinding blocks, undoing the effects of those post-SegWit-no-witness blocks back to SegWit's activation point. When that completes, it will start downloading the blocks again (with witness this time), and validating them.


After bitcoin-cli -regtest -sendtoaddress "address" That address's balance is always 0

If you go through the documentation, the getbalance command can take arguments for an account name, but not an address. I see that you are trying to get the balance for an address.

On blockchain, each account will be linked to non-zero number of addresses. Money sent to any of these addresses will be shown on the same account. So it doesn't make sense in showing the balance on an address. You command was interpreted as getting the balance on the account mviKj9i2zQmoLVUGkLBMuDhwvAwDmfrAmZ, which is non-existent. Hence, the result of 0.00000000.


Does assumevalid lower the security of Bitcoin?

which, as I understand it, makes some data (until 2017?) real without verification.

You understand incorrectly. Firstly, the assumevalid blocks is updated at every major release, so it is at most a couple of months out of date for the most recent release. For Bitcoin Core 0.18.0, the assumevalid block is 0x0000000000000000000f1c54590ee18d15ec70e68c8cd4cfbadb1b4f11697eee which is from February of this year.

Secondly, assumevalid does not just make Bitcoin Core blindly accept blocks without validation. Bitcoin Core will still validate most parts of the block, including Proof of Work, UTXOs, amounts, etc. The only thing that is not validated are scripts because scripts are expensive. assumevalid just means that all scripts in transactions included in blocks that are ancestors of the assumevalid block are assumed to be valid.

Since it only assumes this for the ancestors of the assumevalid block, if there were a large work re-org which removed that block from the blockchain, all scripts would be validated.

  So, can we consider Bitcoin nodes safe? If so, why?

Yes, we can. Nodes are still validating other important things like PoW, UTXOs, amounts, etc. The block that is chosen for the assumevalid block is always one that is several thousand blocks deep at the time the PR is created to update the assumevalid block, and tens of thousands of blocks deep by the time the release is made. So it is extremely unlikely to be reorged out due to the extremely large amount of work required to do so. Even if it were reorged, Bitcoin Core wouldn't become insecure, it would just be a bit slower.

Furthermore, in order for that block to be updated in the codebase, multiple people need to agree with the change and sign off on it. Many developers do so and go further to PGP sign a message stating that they agree that this block is part of the main Bitcoin chain.

While this does introduce a little bit of trust, people can independently check that that block is part of the main chain be going to block explorers and looking up the block in their own node. They can check that this block and its ancestors are indeed valid.


Transferring funds from a cold wallet to a hot wallet - on chain or off chain?

If you want to keep your cold wallet cold, then you shouldn't be importing privkeys to an online device. If the goal is to ultimately send BTC out of your wallet(s), then you can skip the hot-wallet step entirely: just send from the cold wallet to the final recipient(s). Otherwise, having to export and handle the privkeys will create additional security considerations and risks, that likely do not outweight the benefits of easier spending from the cold wallet (in some ways, the point of a cold wallet is that it isn't easy to spend from, after all).
Keep in mind that there are security considerations involved in importing privkeys from an HD wallet: if you are using non-hardened key derivation, then knowing a child privkey + parent xpub will allow someone to derive the parent privkey. Leaking a child privkey can therefore compromise all other child privkeys at the same derivation level.


Bitcore Insight API: I am not able to create and broadcast transaction

Your transaction is not signed. You need to call .sign last since changing the transaction after signing will invalidate the signatures and thus bitcore will remove them. You should instead be doing:

var transaction = new bitcore.Transaction()
.from({"address":"msxGdsTJJYu7YrmkV4sbHNK8Z21pHFZ2gX","txid":"0c0d9ad92f07e774a76194823a92bf2521aa57381ad4782becf20fdf385e1922","vout":0,"scriptPubKey":"76a914886b382436985b195d1dfcdb00c722c1f2fcd0ea88ac","amount":0.01})
.to('mjsVogqLetdUjT9raJY6WgYmy3tifJ3DJz', 20000)
.change('mhCpGNNHQmu4P9pUZcCmgXkxbYxys5pKBw');
.sign('0497427ad1b6177fe950758f10151ba38a6b38d44577ba45fb06423143bb55a2')


Look at http://www.jsonrpc.org/specification: "An identifier established by the Client that MUST contain a String, Number, or NULL value if included. If it is not included it is assumed to be a notification. The value SHOULD normally not be Null [1] and Numbers SHOULD NOT contain fractional parts [2]." To put it simply, it is really just an identifier for a message.
https://en.bitcoin.it/wiki/Block_hashing_algorithm
To put it simply, midstate is just the hashing done on the first half. We need the hash done on the whole data, but since the first part of the data doesn't change, we can just calculate it so that we don't have to perform full hashing everytime.
The target specifies the difficulty. Only a hash that is smaller than the target is accepted. In other words, you can also say that the target specifies the number of trailing zeroes required in the hash.
https://en.bitcoin.it/wiki/Getwork


It has always been the case that the full Bit Machine would be "exposed"[1] by allowing arbitrary Simplicity.  This is because the combinators that let you compose the high-level jets are exactly the same combinators that define low-level Simplicity.  Thus even if only a few high-level jets are chosen to be exposed, it would still be the case that the low-level combinators could be used to define any function (at great expense, of course).

The real question is, what selection of jets will be made available and at what cost?  That question, while really important, gets decided near the end of development, so technically it hasn't been addressed yet.  I'm inclined to be quite liberal on accepting lots of jets.  For example, I'd like to have all functions from fiat-crypto extracted (both as Simplicity and as C) and implemented as jets.

That said, Elements is a platform, and users of that platform will have the ability to choose whatever selection of jets they wish, which may vary depending on how far along the proofs of correctness are and how comfortable they are with the risk-level for greater or fewer number of jets, or even add their own jets.  Furthermore, as Maxwell noted, we really need to get some experience with using Simplicity to understand what are and are not useful jets.  We will want this experience this before Simplicity would be integrated into Liquid.

[1] Just to be clear, the Bit Machine is never directly exposed.  The Bit Machine can only be run through interpreting well-typed Simplicity programs.  This is important because the Bit Machine relies on the type-safety of Simplicity for its memory safety. Otherwise the Bit Machine could crash.


Private key exported from Electrum, unable to recreate Address with Python

In both cases, you are not generating the address that corresponds to the compressed public key.

In the first case, you are creating what looks to be an invalid address. At the very least, the private key it is using is incorrect because it has the compression byte. This will change the value that you get for the private key when it is decoded. In order to get the same outcome as the second case, you would need to drop an additional byte from the decoded WIF key as that byte specifies compression. The key you are using there is 33 bytes rather than the 32 bytes for actual private keys.

In the second case, you are not creating the compressed public key to generate the address. It is still using the uncompressed public key. Instead of using fast_multiply and creating the public key yourself, you should be using privkey_to_pubkey. fast_multiply is a mathematical operation, it has no concept of compressed public keys. However privkey_to_pubkey does so it will create the proper public key. Then you can use that public key to generate the address.

Instead of doing

public_key = bitcoin.fast_multiply(bitcoin.G, pvt2)

you should be doing

public_key = bitcoin.privkey_to_pubkey(pvt)


So, I've started bitcoind and through bitcoin-cli, I've generated new address(bitcoin-cli getnewaddress "USEREMAILID") and assigned it to the users.

Please don't do this. You are using the accounts system in Bitcoin Core which is deprecated, slightly unreliable/has weird behavior, and will be removed in the future.

Maintain your own accounting system outside of Bitcoin Core. Just have a database with addresses and their associated user.

  Now my question is, whenever user starts buying a product, he will execute command (bitcoin-cli sendfrom) and for doing that,

Why? Why don't you just change their balance on the website and just leave the coins there? There is no need to make actual transactions that move the coins to you, just change it internally.

  we need to first unlock the wallet by walletpassphrase and then do the transaction. so, there would be only 1 password which is assigned to the wallet but not every address.

No, that is not how Bitcoin Core, addresses, or accounts work. Accounts are not wallets. All of the addresses for all of the accounts belong to the same wallet. Unless you are using Bitcoin Core 0.15+ and have enabled the use of multiwallet, you are only using one wallet in Bitcoin Core. So there is only one passphrase to be used with walletpassphrase and it unlocks the entire wallet which includes all of the addresses you have given out on your website.

  Is this the correct way?

No, it is not.

The correct way is to maintain a separate database with user accounts, associated addresses, and account balance. When you transfer coins internally (i.e. from one user to another or from one user to you), update the balances in that database instead of making a Bitcoin transaction. When you want to send coins externally (i.e. user withdraws) then you send from the Bitcoin Core wallet and update your own database. When you send, just use sendtoaddress. Do not use Bitcoin Core's accounts system and don't try to make it so that you are sending from certain addresses.

  If user needs to enter his custom password and then process the transaction, would it be possible?

No, as I explained above, that is not how this works.


How to look about transtion is complated?

Let your explorer display the number of blocks confirmed.

As satoshi explains in section 11 of the whitepaper, a bitcoin transaction is never 100% final, but only the probability of it being not-final decreases with every confirmation. What probability of non-finality is good enough?

People could have any use-case so let people decide for themselves. Most want 6 confirmations safety to buy a car, some want 1 confirmation to buy coffee (and there are people like Roger Ver who want no confirmation!).


Ok, you can create your own private blockchain. It will be visible only by yourself. Nobody will not even know about it. I do not see any reason for it, but you can call it "blockchain" if you want. You can call it "my private blockchain" or even give any name for this technology, for example "nsdfuishgreryuiw"


What properties does the DNSSeed list at bitseed.xf2.org attempt to have?

That DNS server in particular does not exist anymore and is not used by Bitcoin Core.

I believe for a while it returned stale results which is what that comment would have been about.


Can somebody really tell how many BTC I have from a receive address?

Can anyone now somehow determine how many Bitcoin I own, based on that receive address?

There is no way to look at an address on the blockchain (or a block explorer) and identify which other addresses were generated from the same wallet that generated that address. Obviously anyone can look at the blockchain and identify the number of Bitcoin held at a single address.

Or is that receive address now as "opaque" and "pristine" as any receive address which has not received any coins yet?

If the receive address hasn't received any Bitcoin it is as opaque and pristine as any other address that hasn't received any Bitcoin.

I've been trying to understand exactly HOW Bitcoin is "not anonymous" for over a decade, but it's very difficult for me to grasp. For all practical purposes, it seems to be anonymous if actually used correctly. That is, never reuse receive addresses.

Privacy (like security) is not boolean. It is a continuum. Bitcoin is pseudonymous rather than anonymous. The number of Bitcoin held at addresses is public but it is not obvious which individual owns a particular address. However, there are ways external to the blockchain where this information can leak in addition to address reuse. For example, if you buy a good from a merchant using the Bitcoin held at that address that merchant now knows you own that address and can track when you spend your funds in future.
Other altcoins like Monero, Zcash, Grin, Beam etc try to provide stronger anonymity guarantees than Bitcoin by not making transactions and effective balances held at addresses public. However they do that at the expense of weaker scalability, more experimental cryptography and/or greater computational burden. Alternatively Lightning (on top of Bitcoin) doesn't make transactions within a channel public but the opening and closing of the channel on the blockchain are still public.


Lorenz,
Blockchain.info is one of the,  if not the most "actual"  bitcoin wallets you can get.  It's streaming and constantly revised data plotting is also the industry standard,  although it is incomplete.

Most of the spoofy little faucets you find Will in fact earn you some mbtc,  or micro bitcoin,  however,  just because they have deposited into a wallet of their own creation and their own design,  this does not obligate them in any way to connect with the blockchain.info main chain.

This is because mostly you get what you pay for,  and you work for what you're paid. So,  watching videos and doing this or that is all well and stupid,  and it also has nothing to do with earning money. . 00000001 is called a satoshi,  after bitcoins pseudonymous creator.  You will be lucky to have as many as just a handful of these doing what you're describing and also successfully redeeming them by TRANSFERING THEM to legitimate wallet service like a blockchain.info.


The mnemonic standard is BIP 39, and that is not the problem. The problem is the derivation paths.

Exodus, Jaxx, Coinomi, and many other wallets use the BIP 44 specification for deriving keys. This means the m for those wallets is actually the key at the path m/44'/0'/0'. However in your code with NBitcoin, you are using direct BIP 32 paths, so your m is actually m. So in NBitcoin, your keypath is actually m/0/0 but in other wallet software, the path is m/44'/0'/0'/0/0


If you would pause the video a couple seconds from the end, you could see that the voice is done by Chris Rice, motion graphics by Fabian Rühle, music and sound design by Christian Barth, and production by Stefan Thomas.

Also, if you check the Active Bounties page on Bitcoin Wiki, you will see that they made 13622.05 BTC doing it (although it was back when Bitcoins were quite cheap in comparison to what they are now).


Why didn't Bitcoin implement segwit in the first place?

The reason Bitcoin didn't initially have SegWit is up to interpretation, I would say that it simply was not thought of prior to transaction malleability. Although that is not its only goal. Segregated Witness was an idea proposed in BIP 141 as a soft-fork, meaning it did not require an entire network upgrade. Due to the nature of a soft-fork, it is backwards compatible with previous versions of the Bitcoin software. Over time, it has been gradually adopted.

  Why and how does non-segwit Bitcoin enable a miner to change a transaction's txid?

Mastering Bitcoin is referring to something called transaction malleability. Traditionally, the txid was a hash of ALL the data in the transaction including the signatures. Transaction malleability meant a signature could be slightly modified such that the txid would be changed entirely while the signature still remained valid.

As David has mentioned in his own answer:

  changing even a single byte in the transaction completely changes the transaction ID.

This created an opportunity for a "Denial-of-Service" attack where while the transaction was still valid, and every part of the transaction would have the same inputs/outputs, nodes could reject modified transactions and prevent them from confirming. With SegWit, the signatures (as implied by the name "Segregated Witness") are no longer part of this hash. Eliminating the issue entirely.

I recommend reading this article for more information on how exactly it is done in practice.


For anyone stumbling upon this is the future, I ended up going with the Poloniex API. It has everything apart from prices in AUD. From there I convert USD to AUD for values as I need them.


Learning to trade iOS user friendly crypto wallet safety when stored in and transfer for trading or use to purchase or get cashed

Choose a wallet program/app from a reputable list such as https://bitcoin.org/en/choose-your-wallet
Install that wallet program/app on a secure clean PC or phone (as appropriate)
Get the wallet to give you a receive address (nowadays wallets issue a different address each time)
Get your brokerage to transfer money to that address
Get them to tell you the transaction-ID and check that in a bitcoin explorer

  I was told to buy as much bitcoin as I can

That's a bit of a red flag.

  I wanna understand how I can buy bitcoin currency with bitcoin currency

That doesn't make sense. Its like buying dollars with dollars. No one does that. Unless some of those dollars are fake dollars or hot dollars. See Fungibility

You can transfer money from one wallet to another. In your case that might be transferring money from your broker's wallet to your wallet.

It can be confusing because some exchanges/brokers etc label an account a "wallet" when it isn't (a wallet holds a private key that only you know, this isn't the way most exchange/broker accounts work, they hold the keys not you)

  first time trading experience to the trading crypto currency and forex markets and stock exchange

Just remember you are jumping into a pool of very hungry, very experienced, well equipped sharks. Don't "invest" any money you would not be happy to lose.


Are SegWit signatures all required to follow BIP143?

I don't think that's possible, even if you intentionally construct the transaction to be used as both segwit or non-segwit, and if you assume that there are segwit and non-segwit outputs for the same address.

The first ~36 bytes of a hashed transaction look like this:

non-segwit:

byte
count   field name
4       version
1-3     varint of number of txins
32      sha256d of previous transaction

segwit:

byte
count   field name
4       version
32      sha256d of concatenated prevout fields

You would need to find two pieces of data such that hash(x)[1:16] = hash(y)[0:15] or hash(x)[3:16] = hash(y)[0:13], which I think is about as difficult as a collision attack (to a factor of 2^24 :P).

You can try to get around this by setting SIGHASH_ANYONECANPAY on the segwit side, but that puts a zero where the number of inputs should go on the non-segwit transaction, and that's definitely not valid in any signature mode. I think even if you sign in SIGHASH_NONE, you can't convert a segwit transaction to a non-segwit transaction, or vice versa.


In PoS how is Net Stake Weight calculated

While I don't know how other PoS blockchains operate, I can give some insight about the PoSv2/3 version based on Peercoin's implementation of proof of stake; one such example would be Novacoin.

The total network weight is ~computed by this function:

double GetPoSKernelPS()
{
    int nPoSInterval = 72;
    double dStakeKernelsTriedAvg = 0;
    int nStakesHandled = 0, nStakesTime = 0;

    CBlockIndex* pindex = pindexBest;;
    CBlockIndex* pindexPrevStake = NULL;

    while (pindex && nStakesHandled < nPoSInterval)
    {
        if (pindex->IsProofOfStake())
        {
            dStakeKernelsTriedAvg += GetDifficulty(pindex) * 4294967296.0;
            nStakesTime += pindexPrevStake ? (pindexPrevStake->nTime - pindex->nTime) : 0;
            pindexPrevStake = pindex;
            nStakesHandled++;
        }

        pindex = pindex->pprev;
    }

    if (!nStakesHandled)
        return 0;

    return dStakeKernelsTriedAvg / nStakesTime;
}

How the weight estimation algorithm works is pretty interesting: it iterates backwards through the blockchain, from the latest known best block until it finds 72 blocks that were produced using a proof of stake (basically all the past 72 blocks).

Using these 72 PoS blocks, it calculates the total amount of time that has passed between each consecutive block pair (added up to a total -- nStakesTime) and the total amount of "difficulty" that was satisfied during the production of those blocks (dStakeKernelsTriedAvg).

The final network weight estimation is given by dividing the "amount of work" by the "amount of time".

This algorithm does not attempt to calculate the exact amount of coins that are being "at stake" at any given time, because as you noticed that wouldn't be possible; yet the estimations it gives are pretty accurate.


The mempool is not a central or shared pool, every node has its own separate mempool (though a node does not have to keep a mempool, it will still function fine without one).

Addendum
Solo miners do not now share mempools and never have.  A solo miner can mine without any specific communication or coordination with other miners. Obviously nowadays a solo miner needs an enormous amount of hashpower to have any prospect of profit.
There is nothing in the original and current core network protocols for Bitcoin that explicitly coordinates, synchronises or shares mempools. It is likely, particularly when the network is less busy that all nodes have mostly the same set of transactions in their mempool. This is simply because the time for data to diffuse across the network is typically much less than the block interval.
Nowadays, because of the huge increase in mining and the consequent huge increase in mining target difficulty (to keep block interval roughly constant) - Mining has become very expensive and so most miners pool resources rather than mine separately.
Miners who are members of mining pools exchange information using one of several completely separate network protocols (e.g. Stratum) that are different and separate from the core network protocols of Bitcoin. I don't know these mining pool protocols or whether block templates are centrally chosen or selected in some egalitarian distributed method but, in principle, I don't see it is essential for them to share or synchronise mempools either.


How to query bitcoin database created by Toshi?

docker exec -it toshi_db_1 psql -U postgres -d toshi_development

Got the answer on a github issue https://github.com/coinbase/toshi/issues/198


Setting up remote bitcoin server control PHP

The Bitcoin wiki is going to a great source for developing your web app. This page describes the process and makes everthing generally less confusing when using PHP.

PHP Developer Intro

You're going to need this library. To start you first connect to your node like so, the following should also print out some basic info about your node.

require_once 'jsonRPCClient.php';

$bitcoin = new jsonRPCClient('http://user:password@127.0.0.1:8332/');

echo "<div>\n";

print_r($bitcoin->getinfo());
echo "</div>";

And to do stuff like get a new address:

$sendaddress = $bitcoin->getnewaddress();

For other commands check out the API reference.


Transaction unconfirmed after almost 2 day! Help!

There are two obvious reasons why your tx remains unconfirmed:

You have not included the recommended tx fee (that's probably your wallet's fault, unless you've manually overridden its default settings)
You are spending an unconfirmed output: https://blockchain.info/tx-index/81648421/0 (also an insufficient tx fee issue). Unless this output gets confirmed, the tx above will never get any confirmations.

Most probably the tx will get invalidated by the network soon and the "spent" funds will return to your wallet.

In the meantime I would suggest you to be careful with spending unconfirmed outputs (there is an option to disable the spending of unconfirmed outputs in the bitcoin-core client) and avoid it whenever it's possible. Also, including the appropriate fee will make your tx much more likely to get confirmed soon by the network.


Can I run a miner on the same computer as a P2Pool node?

You can use a local node with no issue.  The p2pool instance will eventually increase the difficulty of the shares it asks of the miner if it is getting too many of them. 99% of those "accepted" shares are simply faked to keep the mining client happy anyway, the current share difficulty of the p2pool network is over 500k.


Bitcoin transactions between two parties

Lets say bitcoin become a global currency which replace fiat money

Logically, if Bitcoin were to fully replace fiat money and be used for every transaction, then we should expect there would be some way of facilitating transactions easily, in pretty much every situation. Otherwise, people aren't going to adopt it if it is a worse solution that what is already available.

But to answer your question more directly: there are ways to transfer ownership of provably not-backed-up private keys, such as the OpenDime (disclaimer: I have never used an OpenDime, but understand how they are supposed to work, in concept). So if you had a device like the OpenDime that was loaded with the correct amount of BTC, you could just trade it to your counterparty. No internet connection needed.


Would you please clarify the reason behind the invention of Blocks?

When determining who owns what money, the ordering of transactions becomes important. If I only have $10, and then tell both Alice and Bob that I paid $10 to them, who will rightfully own the $10? Some sort of clock/timestamp is needed, in order to determine who received the payment first, and thus has rightful claim to spend it in the future.

If you just trust some central party to tell you who owns what, then this isn't really much of a problem. The central server can update the ledger according to the order in which they see transactions published, and all the users can follow along.

However, it becomes very tricky to establish a reliable timestamp/ordering of transactions across an untrusted network. How do you know which history is correct? How do you know all of the other nodes will agree with what you think is correct? These problems are formalized as the Byzantine General's problem, and the invention of Bitcoin provided a novel solution to it.

Since we need a way to order transactions, each block can be thought of as 'one tick of the clock', and with each tick of the clock, the state of the ledger is updated. This sort of step-by-step update of the ledger is integral to the function of a monetary network, it is difficult to imagine how a ledger might be maintained if there were not some sort of method to order transactions chronologically.

So in a very general sense, this is 'why blocks were invented'. If you want to just trust some network admin(s) to tell you the state of the ledger, then perhaps you can forgo blocks entirely, but you will also forgo many of the important and interesting properties of the Bitcoin network (as is the case with Libra).


A tumbler is used to hide/disguise/make it difficult to prove where bitcoins came from.

It might help to first understand that every bitcoin transaction, right back to the genesis (very first) block is available for public inspection in the block chain.

Note that the actual bitcoins are not trackable, only the amounts, addresses and the transactions  - this is important.

To be able to complete a transfer of bitcoins, you need to know the private key for an address AND know the transaction ID of an unspent transaction sending bitcoins to that address - You don't just send someone 1BTC, you send them 1BTC out of the 1.2BTC you received from person X. In other words, the balance of an address is the sum of the unspent transactions and each transaction clearly shows where the bitcoins came from.

A tumbler attempts to sever the links between your old address and a new address by sending coins from you to other people and coins from them to you.  It also randomizes transaction amounts and sometimes adds time delays to the transactions.

Generally there should be no link between the original transactions and the final address of the coins.

  How does a bitcoin tumbler "launder" bitcoins?
  This is probably answered above
  Is a tumbling a viable laundering scheme?
  Yes, provided that you are tumbling a small amount of BTC compared to the total volume going through the tumbler (I have no idea what the ideal ratio is). Remember also that the tumbler will give out other peoples coins.  If all the coins going through a tumbler are stolen, you're going to receive stolen coins back, they just won't be linked to the coins to started with.
  How would tumbling be made a more/less successful?
  See answer to 2.

Edit: Take a look at https://blockchain.info/taint/1AYdAw8CcrQ2wx55LTbFHRn5bxgNZhaRLW - this shows that 6.6% of the coins at that address came from 1nWxbsMV7XKp7zi2Pq8FzK9HfoPTnBwKV - you can trace it all the way back to when the coins were mined


What happens when an encrypted wallet runs out of keys?

If the key pool is empty and the wallet is locked it will use an old key instead of generating a new key. When wallet encryption was implemented the block creation code was changed to make sure different coinbase transactions are generated in that case.


Cannot access my bitcoins because my wallet is still synchronising. What can I do to spend them immediately?

One solution is to export (in your privacy) the private key connected to the address on which you received your Bitcoins (or simply all private keys). This can be done using a command line tool known as pywallet.

Then, you can import this key (or all your keys) into another wallet. Browser-based wallets such as https://blockchain.info/wallet do not require syncing. Hence you can immediately spent your coins. For the bĺockchain.info wallet the procedure is described on their website.


Why change the nonce instead of just rehashing?

The hashing function used in Bitcoin is deterministic, that is hashing the same input, i.e., block header, will always result in the same output. This is necessary so that others can also check that a Proof-of-Work is valid.

This means that in order to compute a new hash the input to the hash function needs to be altered. The easiest way to alter the input is changing the nonce since this is a free-form field that may take any value. Other ways to modify the input is for example swapping transactions or modifying the coinbase transaction, which would require that the merkle root be recomputed in the header. The timestamp is also a popular choice, however its values are limited by a range of acceptable times.

In case you are wondering why we don't simply rehash the output of the previous hashing function to get the next value: this would destroy the proof-of-work mechanism, which requires an easy to verify proof that the issuer has performed some work. The key here is easy: if we iteratively hash the results of the previous solution then the verifying party would also have to perform this work to check that the issuer has performed the work. when varying the input this does not happen since given the input the verifier can perform a single hash operation and check the result.


PSBT_IN_WITNESS_SCRIPT is specifically the actually executed script for a P2WSH or P2SH-P2WSH scriptPubKey being spent. It is added by an Updater who knows it.
PSBT_IN_FINAL_SCRIPTWITNESS is the witness stack needed to spend an output, including scripts, signatures, public keys, ... whatever is needed. It is created by a Finalizer, using other fields necessary (including PSBT_IN_WITNESS_SCRIPT) to produce it.


BitcoinCore wallet still 3 years in sync, funds in account

In order to operate your bitcoins you need two things, your public and private key for your BTC address. You can export them from the bitcoin core wallet.

There is two types of wallets - ones that require you to download the whole blockchain locally and others that uses someone else server to run checks on the blockchain.

Here is list with wallets https://bitcoin.org/en/choose-your-wallet

You can use Electrum to import your keys and use them right away without waiting for sync.


Is SegWit a step in the direction toward implementing pegged sidechains into Bitcoin?

No.

Federated pegging solutions already exists, and some are being deployed in production. This approach relies on having a number of trusted parties that hold the pegged coins on the main chain side until they get pegged out from the sidechain again.

If you're talking about SPV merged-mined two-way pegged, SegWit does not matter. In this approach, the trusted federation is replaced with a hashrate majority signing off on transfers back. It requires support in the main chain for counting miner votes or support, and several proposals have been made. They are not part of SegWit, though.

The downside of the latter approach is that a hashrate majority on the main chain is always capable of stealing the sidechain's coins, as they could simply sign off on an unauthorized transfer. Technology exists (SNARKs) that could one day allow us to build a sidechain where the main chain can fully validate the sidechain's action, but right now, it is computationally infeasible to do so.


Problem

  rricci2009 commented:

  After few transaction by sendtoaddress command, balance in "" became negative. I solved with the "move" command from another account to "". [...]

Cause

  sipa commented:

  That is expected behavior, if your incoming transactions credit accounts other than "", but outgoing transactions debit account "" (the default if you're not using sendfrom), the "" account will go negative. [...]

Mitigation

  Tectract commented:

  [...] So, is there a way to do something like a sendtoaddress command that won't leave me with odd negative balances?

  gavinandresen commented:

  Use the sendfrom RPC command.

  And you can use the move RPC command to reset account balances to what you expect (and listaccounts to see all accounts / balances)

Source.


how to find name wallet with a btc adress

On Mac: ~/Library/Application Support/
On Windows: %appdata%
If any of the following folder are present, you need to download that wallet software:

Multibit
Bitcoin (Core)
Armory
Electrum


Can i transfer/deposit bitcoin from another exchange into my bit coin account for trading purposes?

In general you should be able to transfer your bitcoin between any two exchanges for trading.

As an example, you may wish to move BTC from GDAX to Gemini for trading. First you should get you'll need to get a deposit address for your Gemini account. Next you should follow the instructions to withdraw digital currency to an external address from GDAX.

You'll need to have created an account at each exchange you wish to use. You should also make sure that you have completed any required identity checks before you send an exchange your bitcoin. You should also expect transfer fees and possible withdrawal delays.

I recommend transferring a small amount between exchanges first. You should also try selling that small amount on your new exchange and withdrawing money to your bank account.


In the absence of a reason, I'm going to assume it's specific to their distro, and they meant "we only created (and always use) the root account, so our documentation assumes you are logged in as root. We haven't tested for odd corner cases that arise because of subtle differences in the way sudo works".

sudo is considered more secure than logging in as root for a number of reasons. It should always be used on mainstream distros.

But for a tiny USB stick distro (with no ability to login as root over the network), the security benefits of sudo may not be worth the complexity.


After creation, what I have to do with a coinbase transaction?

A coinbase transaction is not one that is signed or broadcast to the network. Rather it should be the first transaction in the block that you are mining. Also, the first 4 bytes of the scriptSig must be the block's height (1 byte for pushdata 3 bytes for the height).


Can I run 2 Bitcoin nodes with the same wallets?

This is doable. You can run as many nodes with the same wallets as you want.
I imagine you want to do this because the synchronisation process will be faster on another node?
After the process is done, you will have to copy the complete blockchain data, not the wallet itself.

You might want to consider checking for what your bottleneck is - could be the hard disk or the CPU, or in some cases the internet bandwidth.


Can a resynchronization be avoided when recovering a wallet in Bitcoin Core?

The only way to avoid a full resync is to make sure your backup contains the blockchain as it was when you made the backup; not just your wallet.

Then the core should only need to update with any more recent transactions.

Here is a good article on the subject:  http://bitzuma.com/posts/moving-the-bitcoin-core-data-directory/

And here it is from the Wiki:  https://en.bitcoin.it/wiki/Data_directory


Why is Bitcoin better than other cryptocurrency?

Only time will tell if Bitcoin is the better.
For sure is the first introducing this concept and the biggest market cap at the moment.

Be sure to understand the "cheap" concept. Absolute value means nothing

Suppose at time t1 there are 2 coins and their prices are:
A 1000$, B 1$

After some time this are the coin prices
A 2000$, B 1.5$

At time t1 coin A was the cheapest!


How to get a wallet feerate (sat/byte) of an unconfirmed transaction?

The fee rate is not related to the confirmation status of the transaction.
As far as the bitcoin protocol is concerned, fee rate is simply transaction fee (in sats)/transaction size (in bytes). So for a 100 byte transaction, paying 10000 satoshis as a fee, the fee rate is 10000/1000, or 10 sats/byte.
Currently, you have two possible fee rates: Segwit and non-segwit.
The Fee Rate/weight unit, instead of fee rate/byte, measure is intended to provide a consistent view of fee rates, regardless of whether a transaction has segwit inputs or not.
The calculation remains the same - weight units/total fee gives you the fee rate per weight unit, with a non-segwit byte counting as 4 weight units, and a segwit byte counting as 1 (this is a simplification, full details are outside the scope of fee rates).
To calculate this using Bitcoin Core, simply get the transaction details via RPC. A decoded response contains a weight field, which you then divide by the total fees paid to determine the fee rate per weight unit.
If a transaction has multiple inputs from distinct wallets, the fee is still paid at a transaction level - to determine how much of a fee was "paid" by a particular input, you'd need to determine who received the outputs, and where the change went. Once you know the output break up, you can attempt to distribute the total fee among the participants.


Jump straight to the asset trading page on Ardor Ignis via a shared url link?

Yes you can do it like this:

https://testardor.enchantaddress.com/index.html?account=ARDOR-XK4R-7VJU-6EQG-7R335&chain=IGNIS&page=asset_exchange&asset=16056551815000754623

Using the url parameters you can go directly to the page and asset.

Alot of the functionality is handled in the nrs.js file. Just search for "getUrlPara" and you'll see the various ways to get to a page via just a url without logging in.


How to get sender address from transaction with JSON RPC?

Despite how it looks on most block explorers, Bitcoin doesn't really have a concept of a "sender address", at least not on the raw transaction level. What a transaction has is inputs and what block explorers do is go look up those inputs and guess the address that was used to create those UTXOs.
You might find these related questions useful (just search this site for "sender address"):
How to findout the sender of a transaction
Sender address from DecodeRawTransaction (C#)


Recover keys from legacy blockchain wallet's mnemonic?

The legacy blockchain.info mnemonic does not correspond to any private keys. Private keys are not derived from that as blockchain.info did not use HD wallets when they had those mnemonics. Rather the mnemonic is an encoding of your blockchain.info password.

In order to get your private keys, you will need the JSON file as that is what contains the private keys. If you know your password, the mnemonic is useless. If you don't know your password, get it using your mnemonic.

Unfortunately I don't think you can use blockchain.info JSON files outside of blockchain.info (at least not easily). You can try importing it to a new blockchain.info wallet using this: https://blockchain.info/wallet/import-wallet


Estate planning: how can I ensure my bitcoins are inheritable?

Points for Hot Wallet Inheritability:

Lower exposure to risks - use hot wallets that are BIP 39 compliant and share your 12 to 24 recovery passphrase and associated password in advance.
Higher exposure to risk - share passwords on your devices that have hot wallets.  BIP 32 compliant wallets make it easy to have the same logical wallet deployed on to multiple devices (e.g., cell phone and tablet).
Highest exposure to risks - preload multiple instances of hot wallets on their devices.

Points for Cold Wallet Inheritability:

BIP 38 compliant paper wallets allow your paper wallet's Wallet Import Format (WIF) private key (Base58Check encoded) to be AES encrypted, recoverable with a password.  If you are worried about hiding the amount of the funds, just be sure your paper wallets do not have associated cryptocurrency addresses printed on them. (Cryptocurrency addresses are derived from associated associated private keys. If the private keys are encrypted, and an associated public addresses are not exposed, the amount of funds saved can remains a secret.)
A multi-party escrow service is required to ensure your funds don't get spent before the "big event". Either an on-blockchain multisig service can be applied with m of n signatures being required or an off-blockchain Shamir's Shared Secret can be applied.  The take-away point is that a sealed will is used as a mechanism (or a trusted 3rd party) is used to release the funds.
High tech approach, less privacy where m of n signatures come together for an on-blockchain approach, which doesn't have the desired privacy.
Low tech approach, desired privacy where enough Shamir Shared Secrets need to come together to reconstitute a passwords used by BIP 38 compliant paper wallets. Each heir could have their own unique paper wallets with a common passwords shared across all the wallets. It is also easier to change a will using this approach. The redistribution of updated shared secrets also gets the point across that either you are upset or happy with the behavior of your heirs.

FYSA, Some hot wallet application directly support the importation of BIP 38 encoded keys.

WARNING: As with all backup and recovery processes, perform dry-run tests in advance to be certain the backup and recovery processes are working properly.  Also, perform key generation on a computer (preferably a spare one) that will never be connected to a network again,
print on a network enabled printer private cryptocurrency keys unless they are encrypted using something like BIP 38.


Why am I getting this make error w/ 0.4.0rc1 on Ubuntu

The first two lines are just warnings that can be ignored. But the error is a known issue caused by Bitcoin's use of a deprecated API that was removed in your version of Boost. The fix is to modify src/ui.cpp around line 1809 as follows:

  {
     if (!fAutoStart)
     {
-        unlink(GetAutostartFilePath().native_file_string().c_str());
+        unlink(GetAutostartFilePath().c_str());
     }
     else
     {

(Remove the line marked with a - and replace it with the line marked with a +.)


Are there any non-monetary uses for the blockchain, or the Bitcoin protocol generally?

Proof of Existence is a good example of innovative use of Bitcoin network. The idea is as follows:

  use our service to anonymously and securely store an online distributed proof of existence for any document. Your documents are NOT stored in our database or in the Bitcoin blockchain, so you don't have to worry about your data being accessed by others.

More details:
http://www.proofofexistence.com/about


A Bitcoin alternative with non decreasing reward

PPCoin appears to have a non-reducing block reward, so that might be what you're looking for.

Other alternative cryptocurrencies are listed, with some info on their properties, here:
https://en.bitcoin.it/wiki/List_of_alternative_cryptocurrencies


missing USDT transaction in Copay or Bitpay Wallets

As Raghav Sood commented

  It looks like you were actually sent USDT, not Bitcoin, which are not supported by Copay. You will have to move your keys to a wallet that supports USDT.


Look no further than BTCPayServer - "a self-hosted, open-source cryptocurrency payment processor. It's secure, private, censorship-resistant and free."
The description above taken from their website is absolutely spot on. BTCPayServer allows you to easily accept payments for free, and without an intermediary (unlike Coinbase, BitPay, paypal etc - don't use these, there's absoluteley zero need to pay their exorbitant fees!). It's a fantastic project built and funded by a whole host of awesome bitcoin devs and contributors.
There's a number of very easy deploy options and plugins (e.g. WooCommerce and Wordpress).


What are the factors affecting expected difficulty and what is the maximum value it can take over the period of 30 days?

The difficulty is not limited by a specific time-frame, but solely depends on the amount of hashing power available in the network. The difficulty is updated every 2016 blocks increasing or decreasing up to factor four. While the algorithm strives to set the difficulty such that it will always take about fourteen days for 2016 blocks, it could happen that the hashing power grows much faster than that:

Scenario: Difficulty has been just set to 300MM, and somebody adds a crazy mining rig which is 20x as fast as the whole network

The network is now 21x faster than what the difficulty tries to balance
2016 Blocks are mined in 16h instead of 14d
Difficulty quadruples to 1200MM, the next difficulty reset is reached after another 64h (2d 16h)
Difficulty quadruples again to 4800MM,  the next difficulty reset is reached after 256h (10d 16h)
Difficulty finally catches up with the hashing power added and only increases by 21/16.

In this scenario it would take the network (16+64+256)/24=fourteen days to increase by factor 21. Imagine that our great engineer figures out how to first build one of those super-rigs a day and then speeds up the progress. Theoretically the difficulty could increase by factor four every hour all 30 days (which would be a factor of 2880).

In other words, there is no maximum value for the difficulty in the next 30 days.


I would suggest using a Web API to get notified when a transaction happens on the address(es) you're interested in, it's by far the simpler. Something like this may help:

http://dev.blockcypher.com/#websocket_webhook


Why is this transaction referred to as "low fee"?

It is 1343 bytes, larger than 1000 bytes, so you should have paid 0.2mBTC.

You have too many inputs in this transactions. If you had used a compressed public key, you might be able to save some bytes and shrink the transaction size down to under 1kB.


You can use http://bip32.org/, there is a selection box in the top right hand corner of the page to choose Bitcoin Testnet. That will generate you an extended private key from a passphrase of your choosing. Note that I recommend you Do NOT use any keys generated from websites online for real world payments. But for testing this out it should be fine. Using the default passphrase it generated me:
tprv8ZgxMBicQKsPd7Uf69XL1XwhmjHopUGep8GuEiJDZmbQz6o58LninorQAfcKZWARbtRtfnLcJ5MQ2AtHcQJCCRUcMRvmDUjyEmNUWwx8UbK

Once you have generated an extended private key at the top, starting with tprv, you can then select "Info: m" in the Derivation Path box, which will show you the extended public master key. In this case it generated:
tpubD6NzVbkrYhZ4WaWSyoBvQwbpLkojyoTZPRsgXELWz3Popb3qkjcJyJUGLnL4qHHoQvao8ESaAstxYSnhyswJ76uZPStJRJCTKvosUCJZL5B

Again feel free to use this for testing, but please generate an extended key correctly for the mainnet in a secure way, do not use random websites to do it!


What is happening to the none approved transactions?

Each node on the peer-to-peer network may store the transaction in its mempool, during which time they will continue to relay it to other nodes.  After some amount of time, the node will drop it from the mempool.  The default time in Bitcoin Core is two weeks but individual nodes are free to use a different value.

  Let's say my transaction was not entered into the block, can I be sure that no one is going insert it to the next block?

No, you can't be sure of that.  Certainly while the transaction is in most node's mempools, it will continue to be considered for inclusion in new blocks.  That's desirable for most people, who would prefer that the transaction get confirmed soon, even if it isn't confirmed immediately.

In principle it's possible that some node sits on your transaction, and that it makes its way into a block a long time later - years, even.  The only way to be sure your transaction is never going to confirm is to double-spend it: make a new transaction which spends at least one of the same inputs.  If the new transaction is confirmed (with a sufficient number of confirmations, say 6) then the old one can't be, because the block chain isn't allowed to contain conflicting transactions.


How to store full blockchain on server and run Bitcoin Core as client only?

It is possible to configure your server/clients as follows, although it is not exactly what you have described. I presume that you still want each client to have its own separate wallet.

On your server, make a full installation of Bitcoin Core.

In the config file set bind=<internal network IP>.
Set any other options, for example to enable incoming peers from the internet.
Restart server node for config to take effect.

On each client make a full installation of Bitcoin Core.

In your config file set connect=<server IP>.
In your config file set prune=<n> where n is greater than 550MiB. This will limit storage requirements.
Set any other options.
Restart client node for config to take effect.

Using connect= disables automatic connections so, your nodes will only connect to the server.


Blockchain Parser not working on blockchain generated in regtest mode using bitcoind. Any help?

When working in regTest (or testNet) mode the 'magic number' identifying the start of each block is different to what it is for the live network.  The parser you mention may well use the magic number to identify the start of blocks. This may be the cause of your problem and why it is not finding any blocks in the regTest blockchain file.

RegTest (and testNet): 0xdab5bffa
 Live: 0xd9b4bef9

Hence it is likely that the parser code needs to be modified to work with regTest/testNet magic numbers.


Replace-by-fee and re-sending to another address

Such a transaction is standard and would relay. However neither the Bitcoin Core wallet (via the bumpfee command) nor the Electrum wallet (via the GUI) would create such transaction.
More information about fee bumping in the Bitcoin Core wallet can be found here.


One cool thing about Bitcoin is that coins are inherently scarse and this is by itself a huge protection from sybil attacks. In other P2P systems, sybil attacks are much harder to prevent because there's no such concept of scarcity. In Bitcoin, a sybil attack would be achieved if one has lot of coins, by sending tons of transactions, and therefore spending such coins.

There are other types of sybil attacks such as overloading nodes connections, and the recent one of filling up the memory pool of specific nodes with really tiny transactions. A way to prevent these would be for example to increase the fees.


Why does wallet.dat differ after running?

The wallet contains a lot of metadata, and is actually a database rather than a flat file. At a minimum it contains a record of where you were last synced to in the chain, allowing any node that loads this wallet to pick up where it left off.


Custom filter for mtgox depth api request

On the v2 api, It's not possible, I guess, but they say here that it is, but that arguments to do so are not known. if you try any arguments the response is:

"error":"Invalid call method, please ensure query string is empty (min,max)"

that's why I think you can't, I guess it's the same for v1. Maybe you should think to do what you wanted to do another way, maybe updating your data with trades/fetch?since=1364767190000000


"JoelKatz" is the bitcointalk.org handle of David Schwartz. He answered the linked question and referred to himself as "myself", and you should see him listed under this name as a Ripple developer in other places.


One of the problems (or advantages) of Bitcoin is that funds can be traced. Even if each address is used only once, it is possible to link individual transactions to each other similarly to how it is possible to track bank notes by their serial numbers (with the addition that everyone records serial numbers of all the notes they handle).

Zerocoin solves this problem by providing a new kind of transaction outputs that are not linked to inputs that spend them. Actually, outputs are linked to inputs, but the link is cryptographically obscured, so that an observer can't find which input an output is linked to. However, it is still possible to check that there is only at most one input linked to any particular output, so that double-spends are not possible.

To obscure the link, a cryptographic construction is used which is called zero-knowledge proof. Zero-knowledge proof is a way to show that something is true without revealing any useful information. For example, a digital signature is a zero-knowledge proof that shows that the signer knows the private key. There is no way, however, to learn the private key from the signature.

Proofs used in Zerocoin are more complex. Basically, when generating a Zerocoin, a user picks a random serial number and includes a special irreversible function of that number in the output. When spending, he reveals the number and provides a proof that the number corresponds to one of the outputs. Only one serial number corresponds to each of the outputs, so double-spends are prevented by checking that each serial number is used only once.


Run a full node with multiple IP addresses

If you can allocate multiple IP addresses to one machine (hint: you can), then yes, you can have one node bound to multiple IP addresses and serving peers on all of them. It's impossible to tell whether two nodes you are connected to are actually the same node so that doesn't matter. Note that doing this does not help the network any more than having one IP address and one node.


Can I send bitcoin to other address in my wallet to provide anonymity?

Let's assume you're the outside observer. You see 1 BTC go from aaa to bbb, then from bbb to ccc, then from ccc to ddd, and them from ddd to zzz (zzz being associated with service Z). Can you see how easy it is to figure out that addresses aaa, bbb, ccc, and ddd belong to the same person?

It doesn't even get much better if you split the money to different addresses and then reunite it. How often do you think some money flow like

happens without aaa and ddd belonging to the same person?

That's why people use so-called mixing services. A mixing service collects money from several people, as well as addresses to pay the money out to.

As an outside observer, even if you know who the respective owners of addresses 111, aaa, ααα, and 字字字 are, you cannot determine who paid money to zzz, whereas in the first 2 examples, it's pretty obvious what probably happened.

This, of course, is simplified. Similar to how a criminals hiding the origin of their fiat money wouldn't move it to a single bank account in a different country and then back to where they live, mixing services don't give the users their money back after a single iteration. Instead, the money is mixed several times. A graphic showing many iterations and funds of many people, however, wouldn't get the point across very well.

This doesn't help, of course, if an outside observer can match which addresses belong to whom based on how much money went from aaa through the mixer to ΨΨΨ. To prevent such a mapping, the mixer may send money of equal amounts to many addresses. Of course it's a bad idea to reunite the funds afterwards because this makes the owner trackable by amount again.

Note that using a mixing service might be illegal under money laundering laws where you live, especially if it's done with a large amount of money.

Furthermore, a mixing service may just be a scam and the owner will run off with the money given to them.


I transfered money to Bitcoin Core wallet. Now, how can I use?

You've just stepped into one of the worst problems with Bitcoin. The "default wallet", Bitcoin Core, is not for beginners.

You'll probably want to use a different wallet instead. The problem is that you've already sent a payment to your Bitcoin Core Wallet.

To recover your funds, you'll need to take a crash course in Bitcoin internals.

Your Core wallet contains private keys. You can move private keys from one wallet to another, although this is really bad practice and should only be used when nothing else will work. This might be one of those times, depending on how much money is at stake and how unwilling you might be to let Bitcoin Core continue syncing for the next several days, but as you mentioned you're running out space so it will never complete.

You sent funds to an address (a long sequence of text beginning with "1").

To get the private key for your address, get to the Core console (Help->Debug window).

Next, click on the "Console" tab. There is a text box at the bottom with a ">" symbol and a blinking cursor.

Enter this into the box:

dumpprivkey <address>

where <address> is your address.

From there, you have the private key (begins with "K" or "L", possibly "5"), which you can import into another wallet.

Elsewhere, you indicated you're using electrum. Here's how to "sweep" funds from your private key into Electrum:

http://bitzuma.com/posts/a-beginners-guide-to-the-electrum-bitcoin-wallet/#sweep-a-paper-wallet

Note that the article talks about a paper wallet, which is simply a private key printed on paper.


Can I trust the peers I am connected to?

Your understanding is correct. What you describe is known as a Sybil attack, here essentially the p2p version of a man-in-the-middle attack.

In general, Bitcoin requires very little trust, as each peer can check whether new information adds up with the information that was previously gathered. The attacker could use this constellation to relay a transaction to the attacked, e.g. make a store believe that an incoming transaction has been sent on the Bitcoin network, while instead sending the competing double-spend to the network.

However, the attacked could notice that he is not receiving any new blocks from the network (as otherwise the double-spend might be detected early). I.e. the attacked is not part of a real 'micro-economy', but rather just cut off from network updates.

In order to truly create a 'micro-economy', the attacker would have to actually mine fake blocks at the current difficulty in order to pass off false information as true, requiring immense hash-power at his disposal.

However, as one legitimate peer is sufficient to defeat this attack, you can either set your Bitcoin client to connect to certain peers only, or at least force it to connect to two peers that would not cooperate with each other to defraud you, in order to defeat the attack.

Edit:

Actually, I just realized that the Bitcoin.it has a paragraph on the Sybil attack.


Target is stored in block header (it's called Bits), and it takes only 4 bytes. We derive target 256-bit value from these 32 bits. That's why it is getting truncated.

There is no need to store all 256 bits, or even 224 bits (if we assume first 4 bytes are zero). We don't need such precision.

You can read in wiki, how target is getting calculated from Bits.

You can also check my answer here, with example:
How does difficulty is defined for block '55798'?


How does the "failover" setting in cgminer work?

Yes, the failover setting will tell cgminer to mine on a secondary pool when the first pool is unavailable.
Run cgminer with the following:

  cgminer.exe --scrypt -o http://p2pool.org:9327 -u username -p password
  --failover-only -o http://backuppool.org -u username -p password

This example mines LTC  at p2pool and will mine at another pool of your choice when p2pool is unavailable.


Lightning network: how was malleability actually fixed?

As far as I know, the malleability issue was fixed with the Segwit soft fork in August 2017.

Yes.

  Was the malleability issue fixed with SIGHASH_NOINPUTor with some other method?

No, using SegWit.

SegWit stands for segregated witness. It's a generic and backward compatible change that results in signatures no longer contributing to txids. As the txids of previous transaction outputs being spent are included in what transactions sign, this indirectly results in malleation no longer resulting in the invalidation on descendant transactions.


How will a common guy use Lightning Network when BTC hits 10 mln$?

I assume that people will have more refined ideas by the time this would actually appear on the horizon, but here are some ideas:

channel factories
Custodial Lightning Wallets, i.e. "Lightning banks"
atomic swap from a payment focused sidechain
purchasing spendable LN balance on other users' Lightning nodes via macaroons that permit spending a specific amount

Or more generally, I suspect that people would develop third layer solutions that permit multiple users to share Lightning Network channels effectively.


One instance of minerd is all you're going to need. The application also synchronizes with the pool. So opening more than 1 instance of minerd is just going to cause your network to be used twice for the same information. Also, the operating system has some overhead for running the application. Opening another instance will mean more overhead and thus less hashes!

You have a CPU with hyper-threading, so you have 8 logical cores, this is not the same as having 8 physical cores. Have you tried running it with 4 threads (just for fun)?

Also, imagine having a racetrack with 4 lanes. You can drive 8 or 16 cars on it. But you'll still have to let 4 cars drive side-by-side at a time. You can throw any amount of cars at it as you want, but someone is going to have to synchronise those cars, so that'll just mean the racetrack is used less.

Ideally you should have 8 cars on a 4 lane racetrack. This way the cars that have exited the racetrack have some time to exchange their lap times while the other 4 cars use the racetrack. They can then almost perfectly relieve each other, like a relay race.

Having less than 4 cars on this racetrack means the racetrack will not be used all the time, since the racers in the cars want to exchange their lap times with each other after exiting the racetrack (the processes want to give back a result to the minerd thread).

Having more than 8 cars means there will always be cars waiting to enter the racetrack, so you'll just have cars waiting a lot of time before they can race on the racetrack.


Electrum 2of2 multisig both cosigners share the same priv key

Please attach the transaction in question (partialy signed), no software I know of can spend it, but I'm pretty sure I can do it by hand. Basically you just need to duplicate the signiture and update some lenght fields and such.

(you can ping me on the freenode irc, nickname "lnovy" if you don't want to share the tx here or I'm not answering you here)


Is it possible to get CPFP information from full node, without requesting full mempool dump?

The answer is getmempoolentry.

https://chainquery.com/bitcoin-api/help/getmempoolentry


What happens if Bitcoin itself is obsoleted by another digital currency?

I certainly disagree that a newer digital currency could be compatible enough that the units would replace bitcoins in some ordered fashion. – In that case bitcoin would be close enough to evolve by update into that system. If one thinks about it that way, this has happened before: The Bitcoin protocol has already gone through some update induced hard forks. – Had at that point a significant portion of the community decided not to upgrade they would essentially have had their own separate version of bitcoin.

So, should a sufficiently superior contender arrive, it would have to compete for the same market and the losing system's units would lose value until an equilibrium were reached or one ceased to exist. However, due to the opensource nature of these projects discoveries made for one system are quickly adopted to others as well, or in other cases the rivalry is not as close as one might think. One must also consider that substantial investments made into existing systems would drive effort for preservation.

For example Bitcoin and it's offsprings such as Litecoin are close enough that they compete for the same market, but also close enough that their innovations transfer quickly, on the other hand Ripple and Bitcoin are somewhat dissimilar in their endeavours: One wishes to enable fluid exchange and to facilitate payments beyond currency barriers, while the other supersedes in privacy and wealth storage.


Is there any way to recover a bitcoin private key using some parts of the key ?

It depends on how much information you are missing.

A Wallet Import Format key is base58 encoded. Thus, each character in the key can be one of 58 characters.

You mention in the comments that you are missing 21 characters. Assuming you know exactly which 21 characters are missing (i.e., you know that the first 21 are missing), you have 21^58, or 4.88336... × 10^76 possibilities. This is outside the range of bruteforcing.

Moreover, if you don't know which 21 characters are missing, you have many, many more possibilities, as you not only need to iterate all 58 possibilities for each characters, but also try all their possible locations within the key.

Unless you are able to find more information, the key cannot be recovered.


Yea this is possible, there's nothing stopping you from making a new exchange that does things differently. Although to start making one you're going to need serious programming knowledge.

Consider the following questions

Is there an open source Bitcoin exchange?
What is needed to make a bitcoin exchange?


Can Initial Channel Balances be figured out from the Funding Transaction?

A funding transaction is one where some money is paid into a P2WSH transaction output, where the redeeemScript is a 2-of-2 multisig between the two participants. No other information is provided.

Technically, even the redeemScript for the funding is not revealed until the funding transaction output is spent (channel closed), which makes it less obvious that the unspent output is even a channel. Private channels are not known to be channels, and even when closed, are indistinguishable from any other kind of 2-of-2 multisig transaction.

For public channels, however, the redeemScript can be recreated from information published over Lightning's gossip network, making it possible for network participants to discover which transactions are public channel funding transactions.

There is no information regarding balances. The single funding transaction output has an amount representing the entire channel capacity. This is all that is known to anybody but the two channel participants.

The way channel opening works is that both parties create asymmetric initial commitment transactions, which spend the funding transaction with their previously agreed upon balances. This happens before the initiator reveals or broadcasts the funding transaction. The initiator creates (but doesn't broadcast) the funding transaction and only transmits its transaction id and output index to the other party. This information is sufficient for both parties to create their initial commitments which spend it, and to sign those commitments, but not sufficient for the other party to broadcast the transaction and lock up the funds before the commitments have been agreed. Once both parties have signed, the initiator then broadcasts the funding transaction and the channel is considered opened after it reaches the minimum confirmation depth.

It may be possible to determine channel closing balances based on the transaction which spends the funding output.


Does the inability to spend only part of a transaction result in "too many" extra transactions?

Why does the receiver bother sending back change?

This assumption is wrong. Nevertheless, you are correct saying, that you need to spend the whole transaction input (UTXO) balance on your address, but the person who makes the change is the sender, not receiver.

Example, You have unspent balance (UTXO) of 1 Bitcoin and you want to pay 0.2 BTC for coffee. You create a transaction spending 1 whole Bitcoin to two separate receivers. 0.2 BTC (tx output) goes to merchant and 0.7 BTC you direct back to your address (the change). The difference between UTXO and sum of tx outputs is called fee, in this case 0.1 BTC.

  Does the inability to spend only part of a transaction result in “too many” extra transactions?

No, since it is still 1 transaction with just two output in case there is a change. No extra transaction is made.


Does Taproot allow CoinJoin-style transactions without revealing all signers?

As per my understanding what you are proposing can be achieved with Schnorr signatures, which will be implemented with Taproot. Since Schnorr signatures permit key aggregation, you can construct a single public key (threshold public key) from multiple participant public keys, which in your case is N + initiator. When spending you can just combine the signature from all the parties together (threshold signature) and spend it. The threshold public key and threshold signature are indistinguishable from their single-party equivalents. So for an outsider, it might be as though a single person signed it.

MAST is used to reveal only one spending condition while hiding others. For example, say you have a transactio which states that for first 100 days, you require N and initiator. From 100 to 200 days you require M of N and the initiator and after 200 days you only need the initiator. Currently when spending such transaction you need to reveal the entire spending script. With MAST you can consider each spending condition as a branch of the Merkle tree. When spending that output you just need to reveal the branch that you are spending thus allowing you to conceal the other branches from the public.


BTC-E shut down by government and it won't come back. So there's no way to do that.

(source: btc-e.com)


Is there is any 12 word wallet recovery passphrase in bitcoin core

No, there is not. Bitcoin Core does not use BIP39.


Bitcoind live wallet backup (by copying wallet.dat)

In some cases, bitcoin-qt/bitcoind may regularly (and even gratuitously) flush the wallet [1], so it's possible that wallet.dat could be in an inconsistent state at the time you make your own copy.

The backupwallet RPC call should be a safe way to accomplish this.

[1] https://github.com/bitcoin/bitcoin/issues/10236


Impact on Bitcoin value due to lost bitcoin wallets

Only the market knows it
Market will tell you if you lost them


Restore New Funds after Blockchain Backup

EDIT:  According to this answer: Future addresses are not backed up, but you should have the option to receive a new email backup every time you make a transaction.

Without an official statement from Blockchain, you should assume that the backup does not allow you to restore future funds.

At the time of this answer, Blockchain states that they back up your wallet every 24 hours, which indicates they are probably not using deterministic wallets (deterministic wallets only need to be backed up once and can restore all existing and future private keys).

From the Blockchain.info Backups page:

  Your wallet is automatically saved on at least two separate servers and is backed up to an offsite location every 24 hours.

Note that this answer also states that the "keypool" is not enabled on Blockchain, which means future addresses would not be backed up

Description of the keypool from en.bitcoin.it:

  The wallet contains a pool of queued keys. By default there are 100 keys in the key pool.


Bfgminer is the mining application, the line with the stratum output is the pool that the miner is configured to use. Your address would be a bitcoin address that you own. The worker name and password would be credentials to access your account at the mining pool although most often the password is not used or is substituted with x.


I have some BTC from grid mining I did 6 yrs ago...all I have now is the bitcoin address. How can I spend it?

You can't. An address is not enough to spend coins. You need the private key that corresponds to that address; if you don't have that, then you can't spend the coins. You cannot get the private key that corresponds to an address by only knowing the address; rather you must have had that private key since it was generated and never lost it since then. If you do not have the private key, your coins are lost and unrecoverable.


How does one monitor all bitcoin address that hold more than a certain amount and detect movement from cold storage?

There are sites that monitor the blockchain and aggregate the data. E.g. https://bitinfocharts.com/top-100-richest-bitcoin-addresses.html


Is it possible for a slow computer to beat the world mining Bitcoin?

It is of course possible... however it is incredibly unlikely!

Mining with a CPU has not been profitable since the earliest days of bitcoin, the expected time to find a block is likely on the order of centuries at this point, and by that time you'll have burned much more in electricity costs than the eventual block reward.

So, as an experiment you could try, but if it costs you even just $5 worth of electricity a month, you would actually have better odds spending that money on a lottery ticket!


How does muun lightning wallet requires no trust and no backups?

I'm the CEO at Muun wallet.
Muun does rely on backups since the Emergency Kit is a backup, just not using mnemonics. The problem with mnemonics is that they don't contain a lot of stuff needed for the recovery of a multisig / lightning wallet, like the derivation paths, scripts, etc.
When using Muun, you will back up two pieces of data: the Recovery Code and the Emergency Kit. The Recovery Code is a randomly generated code that you write on a piece of paper, in the same way that you usually do with mnemonics. In fact, this code has higher entropy than a 12-word mnemonic. The Emergency Kit is a PDF document with all the stuff needed for recovery but harmless by itself. It has:

The two private keys (Muun is a 2-of-2 multisig), encrypted using the recovery code.
The output descriptors, with the derivation paths and scripts.
Instructions on how to use this data to recover your funds.
All this data is also available inside the PDF in a machine-readable format.

When using the recovery tool (https://github.com/muun/recovery), you will be able to move the funds using your Recovery Code and Emergency Kit combo. The next version of the recovery tool will use the machine-readable metadata in the PDF for easier input and better UX.
Regarding the lightning aspect of the recovery process, Muun uses super optimized submarine swaps to execute the lightning payments, both incoming and outgoing. This means that your funds are on-chain and thus recoverable by the mechanism I just described.
From the next version, Muun will start maintaining off-chain funds, and thus it will need to backup the off-chain commitment transactions. These transactions will be included in the PDF metadata. I'll update here with more information once we release this.


How can I find a digital forensics expert to help trace stolen bitcoins?

I'm not sure of the existence of a directory of experts by physical location since Bitcoin is a digital currency.

Elliptic is a blockchain intelligence company identifying illicit activity on the Bitcoin blockchain and providing services to leading Bitcoin companies and law enforcement agencies globally. Their HQ is in London and main office in New York. More information of the company is available here. If you're based in either of these locations you could contact them locally.


How to specify the right input and output to be signed for SIGHASH_SINGLE

A signature is applied to the input being signed by default, so you don't really pick the input.

You have two options:

SIGHASH_SINGLE - All inputs are signed, and a single output with the same vout index as your vin index is signed. That is to say, if you have a tx with 5 inputs, out of which your input is the second one, and 4 outputs, all five inputs and the second output will be signed.

SIGHASH_SINGLE | SIGHASH_ANYONECANPAY - This will only sign your input and the corresponding output, instead of signing all the inputs. Essentially, in the above example, input 2 and output 2 will be signed.


I need to extract last wallet transaction.

This will return last transaction in the wallet:
listtransactions "*" 1 0

For second last transaction:
listtransactions "*" 1 1

Last two transactions:
listtransactions "*" 2 0

Consider a wallet has 5 transactions.
listtransactions [LABEL] [COUNT] [SKIP]

Skip
Tx

0
Tx5 [END]

1
Tx4

2
Tx3

3
Tx2

4
Tx1 [START]

If you skip 0 and count 1 in the above table you will get Tx5
If you skip 0 and count 2 in the above table you will get Tx4 and Tx5
If you skip 1(Tx5) and count 1 in the above table you will get Tx4
If you skip 1(Tx5) and count 2 in the above table you will get Tx3 and Tx4


A bit late, but better late than never.

No guarantee given for accuracy.
From day one to January 8 2016
For the first 262 days the average trading price is used as no closing price available.

Bitcoin price mainly from Bitstamp, Litecoin from BTCe so LTC-BTC is a bit different for BTCe price

No trade first couple of days ltc-dollar price established from ltc-btc and bitcoin dollar
The lowest closing price was on May 29 2012 at $0.0023.
The lowest recorded deal January 23 2012 at  1:36:42   $ 0.001302   4.20697  Litecoins changed hands at that price (did have all volume too, but gone. was just a spreadsheet, but link to it dead too)
Three days did not have any trades at all: 17.March 2012, 6.May 2012, 17.May 2012

LTC-USD

LTC-BTC


Does a new nodes verify all transactions or only blocks

New full nodes verify both blocks and transactions within those blocks. New SPV clients verify only block headers.

Bitcoin Core avoids checking signatures on blocks before the most recent checkpoint. Checking signatures is one of the most time-consuming parts of checking a block. (As of writing, the last checkpoint was on April 2014, 2.5 years ago.) This can be disabled by setting the option checkpoints=0.


Your transactions would be given the lowest priority as they are not paying fees, also if anyone is actually marginally successful in spamming the system it is entirely possible that the larger pools will simply not take their transactions, in fact some pools do filter out some transactions. This thread shows some of the restrictions that some mining pools already have.


Testnet Bitcoin wallet: which script in hash addresses?

What're seeing is a P2SH embedded Segwit address.

It contains the hash of the script OP_0 [20-byte hash160 of compressed pubkey].

You can configure Bitcoin Core to instead produce legacy P2PKH addresses (start with -addresstype=legacy). You can also make it construct Bech32 (BIP173) addresses using -addresstype=bech32, which represent the OP_0 [20-byte hash160 of compressed pubkey] script directly. These are cheaper to spend, but not all software supports sending to them.


what is the most suitable time interval for updating information on a block while mining the block

Miners do optimize the block construction process internally.

Unfortunately they do not share this information with the community, so we don't know what methods they use, how they choose TX's and how they distribute work to pool participants.

Both mining machines and mining software the big miners use are secret. Modern ASIC machines' hardware are closed source and so is their firmware and operating system.

This is unfortunate considering that Satoshi gave us Bitcoin source code, which is absolutely revolutionary, for free.


Chain Race: How to know chain-length of competing chain?

What happens if now the 10% fork (chain A) will mine a block and send it to the network?

When a miner building on top of chain A finds a valid block, it will relay the block to the rest of the network. For convention let us assume the fork (chain A and chain B) has happened at block height N. This is how different nodes on the network will react when they receive a block at height N+1 whose parent is on chain A.

Nodes already using chain A: For them, this block N + 1 is a natural progression of the blockchain and as a result they will just add this block to their blockchain.
Nodes using chain B but has chain A block: There might be some nodes who might have received the chain A block at height N after receiving block at height N from chain B. Since these node received block from chain B first, they will use this version of the chain as their primary one. However, block from chain A that is received later is not discarded but is processed and kept on the disk. So, when block at height N + 1 is received from chain A version, these nodes just revert the chain at height N and use the other block that was kept on disk.
Nodes only having chain B: When they receive block at height N+1 from chain A, these nodes will see that they do not have its parent. As a result, these nodes will query the parent block using the previousblockhash and see if it exists. The nodes having this block will then transmit that block to the nodes not having it. When that block is received, these nodes will see that this chain is the longest proof of work chain and as a result they will now operate on chain A. The block at height N from chain B becomes stale but it is not discarded and is still kept on disk.

  How do they know that this chain is longer?

Nodes accept the longest proof of work chain (in most cases it is same as the longest chain). Nodes sync headers first and verify the proof of work of the chain before asking the actual blocks from other nodes. When nodes on chain B version of chain receive the header of block N+1 on chain A version, they will see that the chainwork of the block received is more than that of the chain they already have and as a result will use it to query the block associated with it.

  How do they know that the block is not just some part of DDoS attack?

When they receive the block header, the proof of work is verified first. So, if the attacker wants to spam the network with invalid blocks, he/she would have to do so with valid proof of work. That means spending immense amount of energy as other miners but not getting the reward (as the block does not have any ancestor, it will be rejected). If the node receives a block header with invalid proof of work, then the node that has sent this block header will be blacklisted after certain attempts of this mischief. This was actually the basis of PoW in 1990s when it was used to prevent spam emails.


Is the HashOfThingToSign (used in signature generation) the same for each input of a transaction or is it different for each input of a transaction?

It is different for each input. Each input's hash preimage contains that input's previous output's scriptPubKey in that input's scriptSig. All other inputs have empty scriptSigs. This means that the preimage for each input is unique, and thus has a unique hash.


How to use bitcoinj to transfer btc from p2sh-p2wpkh

solved
Script redeemScript = ScriptBuilder.createP2WPKHOutputScript(key);

Script witnessScript = ScriptBuilder.createP2PKHOutputScript(key);

TransactionSignature signature = tx.calculateWitnessSignature(inputIndex, key, witnessScript, txIn.getValue(), SigHash.ALL,
        false);

txIn.setWitness(TransactionWitness.redeemP2WPKH(signature, key));
txIn.setScriptSig(new ScriptBuilder().data(redeemScript.getProgram()).build());


Why is a minRelayTxFee of 1000 sat/kb not equivalent to 250 sat/kw?

I thought vbytes were equal to weight units divided by 4

It is [1], but rounded up to the next integer, so the implementation in bitcoind is :
int64_t GetVirtualTransactionSize(int64_t nWeight, int64_t nSigOpCost, unsigned int bytes_per_sigop)
{
    return (std::max(nWeight, nSigOpCost * bytes_per_sigop) + WITNESS_SCALE_FACTOR - 1) / WITNESS_SCALE_FACTOR;
}

(Where WITNESS_SCALE_FACTOR = 4).
In addition, bitcoind not only uses vbytes for user interface but also for mempool logic and the DEFAULT_MIN_RELAY_TX_FEE constant is set in vbytes :
static const unsigned int DEFAULT_MIN_RELAY_TX_FEE = 1000;

In order to check it for standardness bitcoind will compute your transaction size as rounded up (if not a multiple of 4), and will record your transaction feerate as rounded down.
It will then compare this to the minimum relay feerate (1000) : a feerate of 250sat per KW will pass only if the size of your transaction (in weight units) is a multiple of 4.
It might be clearer with code, here is a Python function which illustrates this behaviour :
>>> def bitcoind_fun(tx_weight, feerate_perkw):
...     fees = tx_weight * feerate_perkw // 1000
...     print("Your transaction will pay {} sats of fees, is {} WU large (a feerate of {}sat/Kw)".format(fees, tx_weight, feerate_perkw))
...     tx_vbytes_for_bitcoind = (tx_weight + 3) // 4
...     tx_feerate_vbytes_for_bitcoind = fees * 1000 // tx_vbytes_for_bitcoind
...     print("bitcoind reads your transaction as paying {} sats of fees for a transaction of {} vbytes, so a {}sat/perKvb feerate".format(fees, tx_vbytes_for_bitcoind, tx_feerate_vbytes_for_bitcoind))

Which if you run with a tx_weight which is a multiple of 4 will pass, otherwise it won't :
>>> bitcoind_fun(1600, 250)
Your transaction will pay 400 sats of fees, is 1600 WU large (a feerate of 250sat/Kw)
bitcoind reads your transaction as paying 400 sats of fees for a transaction of 400 vbytes, so a 1000sat/perKvb feerate
>>> bitcoind_fun(1601, 250)
Your transaction will pay 400 sats of fees, is 1601 WU large (a feerate of 250sat/Kw)
bitcoind reads your transaction as paying 400 sats of fees for a transaction of 401 vbytes, so a 997sat/perKvb feerate
>>> bitcoind_fun(1602, 250)
Your transaction will pay 400 sats of fees, is 1602 WU large (a feerate of 250sat/Kw)
bitcoind reads your transaction as paying 400 sats of fees for a transaction of 401 vbytes, so a 997sat/perKvb feerate

So we use 253 as the feerate floor to always be safe :
>>> bitcoind_fun(1600, 253)
Your transaction will pay 404 sats of fees, is 1600 WU large (a feerate of 253sat/Kw)
bitcoind reads your transaction as paying 404 sats of fees for a transaction of 400 vbytes, so a 1010sat/perKvb feerate
>>> bitcoind_fun(1601, 253)
Your transaction will pay 405 sats of fees, is 1601 WU large (a feerate of 253sat/Kw)
bitcoind reads your transaction as paying 405 sats of fees for a transaction of 401 vbytes, so a 1009sat/perKvb feerate
>>> bitcoind_fun(1602, 253)
Your transaction will pay 405 sats of fees, is 1602 WU large (a feerate of 253sat/Kw)
bitcoind reads your transaction as paying 405 sats of fees for a transaction of 401 vbytes, so a 1009sat/perKvb feerate

By the way the comment in the code you put is wrong : it's not (3 * weight) / 4  but (3 + weight) / 4.

[1] Excluding sig OPs limits that artificially increases the virtual size to further prevent DOS.
PS: In the same vein, see https://github.com/bitcoin/bitcoin/issues/13283.


does extended public key derivation go both directions

Is the reverse also true -- can a parent extended public key be derived from a child extended public key?

No. BIP 32 uses hash functions in order to derive the child keys. In order to be able to derive the parent key from the child key, you should need to be able to reverse the hash function, which is currently impossible (I say currently because some vulnerability could be discovered which allows it to be reversed, but that is unlikely to happen).

Furthermore, the child key derivation also involves calculating a public key from a private key (that private key is basically temporary and doesn't actually reveal anything about the child private key). You would need to reverse that too, but doing so is also currently impossible (it is theoretically possible with a quantum computer).


5 GH/s Bitcoin Miner from Butterfly Labs can mine Litecoin?

Litecoin uses a different proof of work than Bitcoin, so that hardware won't be compatible(it won't be solving the right problems).

One of the motivations of Litecoin was to make CPU mining viable by making it difficult to create efficient GPU/FPGA/ASIC miners, so it's unlikely that you can find specialized hardware for this purpose. I think that some GPUs do give a speedup over CPU mining with Litecoin, but it isn't as dramatic as with Bitcoin.


I found out that long verification at start of bitcoin daemon can be caused by large number of keys generated and stored in wallet.dat. in my case >1600 keys can take more than 30min of verification.


Wallet validation methods (centralized, SPV, etc.) - please clarify for Ledger and in general

The answer is simple: Ledger is not a wallet, it's a device to improve the security of a wallet. Everything depends on what wallet you use it with.

It's a hardware signing device. They're often called "hardware wallets", but that is a misleading name. It does not manage your money, or send or receive transactions. It's simply a secure, offline, device to hold your private keys, and sign transactions provided to it.

As such, it's really just a way to improve the security of an actual wallet, which it is used in conjunction with.
Ledger has their own, but several more common software wallets (e.g. Electrum, Green, Bitcoin Core through the HWI toolset, ...) can use Ledgers as a signing device. The security and privacy tradeoffs you get depend on the software you use it with.


Whose to stop the coinbase devs from just draining all accounts and running of with the money?

The same kind of business trust and legal things that let an exchange or a bank running I suppose.

There have been exchanges doing what you said in the past, and they have gotten the same legal pursuit as any other business scamming his clients.

Here is some links: https://www.coindesk.com/six-arrested-over-cloned-crypto-exchange-that-stole-e24-million

https://medium.com/datadriveninvestor/investigating-the-40m-binance-hack-c5fba32900f1

Also, at least in the case of bitcoin and ethereum the two most valuable crypto at the moment, and so the more money they can hope to have with, every transaction is recorded on the blockchain so they gonna have a harder time to transform those crypto back to fiat.

You also have to notice that most of the veteran crypto user will advise new users to not let their coins sit on an exchange and instead to store them in an offline secure place, owning our money and replacing the bank being one of the idea behind cryptocurrency, the problem you are describing being one of the reason why.


What is a Stratum "mining.set_difficulty" command for?

The command is telling the miner not to send shares below the requested difficulty. If they were to send every difficulty 1 share for example, many pieces of hardware would be attempting to send hundreds of thousands of results a second. It’s simply flood control, and the only reason to send block shares at all (that are too low of a difficulty to be a block) is to prove to the remote stratum server that you’re doing work worth paying.

Many pools clamp at a lower bound of many tens of thousands of difficulty as of 2017, and many pieces of hardware aren’t even able to produce blocks with a lower difficulty than that. The miner really only needs to send share proofs every few minutes at most for the remote pool to have a reasonable confidence that they are mining at a particular speed for payout purposes.


How does walletexplorer.com generate the wallet ID's?

They're internally generated and have no bearing on anything but the internal database, some are sequential and some are random for historical reasons. All information displayed there is inferred, there's no direct relation to transactional information available on the Bitcoin network other than by derivation.


Transfers in bitcoin can take anywhere from a few minutes to a few days depending on the network status and the fee paid. Currently, it's closer to a few minutes. In either case, you can also usually view unconfirmed transactions in your wallet or on block explorers such as blockchain.info.

In your case, however, things seem unlikely. All such apps that I've ever heard of (free mining, free btc, etc.) are scams, and never actually pay you. They will simply claim the withdrawal is pending, or keep telling you that you are under the withdrawal limit, while using your device for ads, or other purposes.


Mining Bitcoin Wallet's Private Keys Instead of Blocks

To mine a block it is "enough" to guess the nonce that results in a hash compatible with the current difficulty level.

To guess a private key to a specific wallet you need on average 2^255 tries. Even the simple act of counting (not checking if that number is a key to some btc, just counting) from 0 to 2^255 with an ideal binary counter requires more energy than that provided by converting the whole mass of the Sun into energy.
Not impossibile, "just" infeasible

Even if you are fine by guessing a private key to a random wallet out of a few million the amount of tries to do is not that much different in absolute terms and the reasoning still applies.

Google returns many funny trivia about how really immense is the keyspace, some with elaborate calculations too, such as that if we made a book with 255 keys per page containing all the possible keys that book would have 904625697166532776746648320380374280100293470930272690489102837043110636675 pages. (www.directory.io)

Anyway, there is a project named "large bitcoin collider" that tries to guess private keys, obviously with "not much" success... (https://lbc.cryptoguru.org/about)


Blockchain Explorer says received but it's not received yet!

That's not how Bitcoin works.

All computer-based wallets, including your friend's, have a copy of the blockchain (or have indirect access to a copy). If the blockchain includes your transaction, then the money has been received. All copies of the blockchain are eventually identical, only the last block or two might very occasionally differ for a short while.

Note that you can receive Bitcoin even if your wallet exists only as a secret number written on a piece of paper. The blockchain is the true record of what has been received.

If your friend says their wallet has not received the money there are at least three possibilities

They are lying
Their wallet has not got an up-to-date copy of the blockchain (i.e. is not "synchronised")
You sent the money to the wrong address somehow.


Wallets that support 40 byte message attachment via OP_RETURN? Desktop / Mobile?

So is it one OP_RETURN parameter for each bitcoin transaction or per
  each input/output address?

One OP_RETURN output per transaction regardless of the number of inputs and outputs is standard for 0.9.x bitcoin core clients.

  If its each transaction, so its safe to say its about .0001 btc to
  send 40 byte message?

Yes, but you should not do it without significant reasons.

  Aside from OP_RETURN message attachment, what other methods are there
  to attach custom data?

There are different methods. You can use fake public keys in bare multisig outputs. Or encode some data with values or addresses of other outputs.