text:
Why do transaction fees exist in the Bitcoin blockchain if miners get rewarded with newly created bitcoins?
My question is why transaction fees exist, even though the miners would still get rewarded with the newly created bitcoins when/if they mine a block. Miners will rather verify transactions with a higher transaction fee to eventually receive the fees themselves, but what if there were no fees involved and all the transactions would be verified without other considerations. The only reason I can think of is that with no transaction fees, when all the bitcoins are mined, there will be no more incentive for the miners and the network will fail. Is there another reason or is that it?

The block subsidy in Bitcoin serves as a decentral initial distribution mechanism and incentivizes the bootstrapping of the Bitcoin network. As you may know, the block subsidy halves every 210,000 blocks (approx. 4 years). Due to this reward schedule, more than 80% of all bitcoins have already been discovered, and in a decade, it'll be more than 95%. As the number of new bitcoins being added to the money supply dwindles, another mechanism to fund the security of the network will need to take over.
The source of that funding is meant to be transaction fees. This seems feasible, especially in light of us seeing the first block with transaction fees greater than the block subsidy last year.
  via smartbit.com.au
The transition to a fee funded mining market is tightly coupled with the blocksize debate. For example, Princeton's Weinberg et al have shown that a fee-funded mining market may become unstable unless there is a constant backlog of transactions waiting to be confirmed. Some Bitcoin clients explicitly lock new transactions to the next block's height to encourage mining of a new block in contrast to miners attempting orphaning attacks on the current blockchain-tip for fee sniping.
The described dynamic is also cause for speculation that altcoins with oversized (and thus empty) blocks may need to transition to a constant block subsidy in the longterm to maintain a stable mining market.
Finally, the limited availability of blockspace and presence of transaction fees creates a fair market for users to signal the urgency of their transactions. This allows more valuable use of a limited resource to displace frivolous or inefficient use. The fee market especially discourages spam and business models that depend on abundant blockspace. Early acceptance of the inherent limitedness of blockspace is a prime driver for innovation and investment in sound second layer technology such as the Lightning Network.
People have been speculating for years, why Bitcoin was designed with the abrupt halvings of the block subsidy instead of a smoother payout or even a constant reward. There even was an attempt to turn the initial block subsidy of 50 bitcoins per block into a constant subsidy around the first halving, but the broader network rejected the miner's attempt to increase the money supply.

Probably worthwhile also to highlight that transaction fees were introduced as a deterrent for spam transactions.

@renlord: I meant to do that with "Finally, the limited availability of blockspace and presence of transaction fees creates a fair market for users to signal the urgency of their transactions. This allows more valuable use of a limited resource to displace frivolous or inefficient use." Do you think I need to be more explicit?

Yes, I think it should be made more explicit.

Thy wish is my command. ;)

Fees allow the network to prioritize transactions and avoid spam transactions which would fill the mempool. Additionally after the BTC reward will be gone Tx fees are the only way to incentivize the miners.

The reason for transaction fee is to pay miners when the block subsidy goes to zero. Since the block subsidy halves every 4 years (roughly), it will become negligible fairly soon, and transaction fees will thus need to make up for the lost block subsidy in order to continue to incentivize miners to continue to mine blocks.


text:
Are there different ledgers in the bitcoin network?
Is it correct to say that in the bitcoin network, there are different versions of ledgers (although the longest chain is the correct one)?

No, there is only one blockchain which is Bitcoin. There are no different versions or different blockchains that other people are using that are also Bitcoin. Such things do not exist. Such other blockchains that are forked from Bitcoin are not Bitcoin but rather altcoins.

There are some orphaned blocks, sure, but as you say there is only one blockchain.

No, there is only a single ledger in the Bitcoin system. We call Bitcoin's ledger the UTXO set (Unspent Transaction Output set).
The point of a money is to track the purchasing power of its participants. Bitcoin does this by recording all transactions that ever occurred in the Bitcoin blockchain, it's "transaction journal". As long as all nodes enforce the same consensus rules, the mining process will cause a single "best chain" to emerge which means that the whole network converges on a single ground-truth. Bitcoin nodes replay and verify the complete blockchain to calculate the current UTXO set and thus synchronize with the network.
For a different ledger to emerge, there would need to be a disagreement in the consensus rules. However, when someone changes the rules their node follows unilaterally in an incompatible manner, they are departing the Bitcoin network. This new network that their node creates is incompatible and thus would be a new forkcoin, not Bitcoin.

source: Stack Exchange

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

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

sort: votes


text:
How can one full node know whether other full nodes added certain block to their blockchain?
How can one full node know whether other nodes agreed a block suggestion of a miner (so it will know whether to add the block to its blockchain too)?
thank you

There is no guarantee that when a full node adds a block to its main chain that other full nodes have done so. However there is no need for a node to know that in order to add a block to its main chain; it simply has to validate the block according to its consensus rules before adding it to its main chain. If everyone follows the same consensus rules, then all nodes will converge to the same blockchain. The blocks in a blockchain are defined by the consensus rules.
Additionally, it is generally safe to assume that the peer that sent a node a block also added that block to its main chain. However that does not necessarily mean that a node should also add the same block; it must still verify the block because that peer could be following different consensus rules.

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


text:
what will be the best approach to accept Bitcoin payment instantly?
How could I receive Bitcoin instant payment?

are you planning to run your own server or using some third party?

Re "instantly" - see https://bitcoin.stackexchange.com/q/48548/13866

I'm planning for my own node.

Bitcoin takes 10 minutes for a transaction. It is advised to wait for a 6-block confirmation for a safety. This takes a maximum time of 1 hour. So, instant payment is really difficult.
If for your business, you could try services like coinpayments.  They have different strategies which reduces users risk.

They provide plug-ins which can included in your website


text:
Login Problems with Greenaddress
I need help desperately!   I am trying to get to BTC that is locked in a greenaddress wallet.  I can log into the view only. When I put in the mneumonic & password, the system runs through decryption to 100 percent and then it bombs out and says login failed.  I've contacted or tried to contact support for help and they say things like that it's not mapped properly or  the fact that I can get in to see it but just not touch the actual account only proves that one exists!  I have the NLock Times zip file.  Can you please help me?  I don't know at all what to do to try to recover these funds. I have a PC running Windows 10 and don't know anything about code, programming languages or any Unix based systems or how to use or run anything like that.  I can pay someone if they can help retrieve these BTC's from the greenaddress wallet to sweep to just about anywhere else on God's green Earth.  Please please can someone help me?  Thank you so much.

If any of the steps fail, comment below, I'll try to help.
1) Follow the tutorial here to install Ubuntu for Windows
2) Set your Username and Password
3) Type
sudo apt-get update -qq

After commands that start with sudo, it'll ask for your password. You'll need to type it, but it won't be shown on screen for security. Press enter.
4) Type
sudo apt-get install python3-pip python3-dev build-essential python3-virtualenv virtualenv -yqq

5) Now, in Windows, visit https://github.com/greenaddress/garecovery and download it via "Clone or Download -> Zip" Move it to your desktop
6) Go back to the Linux terminal. Type cd with a space after it. Drag & Drop the unzipped folder. Now, press enter.
7) Type and enter
pip uninstall enum34
virtualenv venv
source venv/bin/activate
pip install --require-hashes -r tools/requirements.txt
pip install .

8) You can now continue the final step, which is located here

Thank you so much.  I will try this & let you know how it goes.  I can't tell you how much I appreciate someone finally taking the time to actually talk to me human to human

You're welcome! Let me know the result.

Hello.  I really want to thank you for trying to help me.  I just don't know what goes wrong.  I completed 7.  But then I go the greenaddress site to finish and again, it just doesn't work.  Please Please Please...  I have all of the emails (confirming the authentification steps).  I have the mnemonics, user name and password.  I have the picture QR but it won't take it.  It says it's not clear enough.  The only thing I don't have is a pin.  I have the nlocktime zip and I can see in the view only that the BTC's are still there. I can pay you to help me. The nlocktime email says to use gentle

@JENNY could you please give me the exact output of the last step?

So, I wasn't exactly sure what I was supposed to type in the  Ubuntu, but I tried using the exact phrase garecovery-cli 2of2 --nlocktime-file /path/to/downloaded/nlocktimes.zip -o garecovery.csv.  It said something to the effect of that it couldn't find it in the directory? Then, I thought maybe I was supposed to drag and drop the file where it  said file/path, etc.  like in your instructions (which worked very well up until this part).  After that, it just kept showing my username/command prompt over and over again.

But I will try again if I have clearer instructions.  Also, I'd be more than willing to give you this information.  If it turns out that this was never mapped properly (because I've heard this being a possibility a couple of times now) what does that mean, how could that happen and what could possibly be done about such a thing?

I haven't heard of "not mapping correctly", it'd be great if you could show a website mentioning it. I believe the error might be caused by the Windows Subsystem, since we used it instead of creating a full VM. You may need to try all these steps again in a real VM, are you familiar with installing Virtualbox and completing a basic installation of Ubuntu? It shouldn't be too hard.

It's funny you mention that.  I had Ubantu partitioned so that anytime I booted up, I had to choose which operating system I wanted to use.  I must have done something wrong there, too, though because it had all the apps that worked & I could get online, but my uncle gave me a couple of basic commands to run and none of them did anything. When I say "mapped" I mean the wallet itself being connected to or identified as being connected to a rightful owner.  I know the mnemonic is correct & the password.  It shows decryption & then says, "Login Failed." I can view only the wallet on greenaddress.

But I would be willing to try to reinstall the Ubuntu again, partitioned on its own.  The thing is, I believe the problem is not on this end, but that back in 2015 when the account was created, somehow, the identification information wasn't assigned properly.  There was only 1 transaction done (the one which was the reason for opening the acct. to begin with in 2015). But again, I can give someone the mnemonic, username, password & money for helping but so far nobody has been able to get into it.  The money still shows it's sitting there in the wallet in the view only.

That's why trying recovery.

Basic desperation.  I just don't understand why  I wouldn't be able to give someone at greenaddress the username, password, mnemonic, QR, the original emails with the authentification verification numbers & the nlocktime zip & have someone help to get into the wallet. But nobody @ ga does anything to help, unless you work for/with them.  In that case---  it seems you are a loner-- it-  the only one willing to help at all & thank God for you, I'm not joking.  You are truly an angel.  A Godsend & I imagine a very tired & busy one at that. So thank you & thank you again.  You have got it goin on!

@JENNY Did the virtualenv venv step print any errors? If not, please try the last step again with the -d argument: garecovery-cli 2of2 --nlocktime-file /path/to/downloaded/nlocktimes.zip -o $HOME/Desktop/greenaddr.csv -d Make sure to change the --nlocktime-file path by drag dropping. -d will output everything so that we can understand the problem. Please paste the whole input to Github Gist or Hastebin if the output is too long, and post the link to it below.

Will do.  Thank you again for taking your time to do this. :)

I don't really know how to do that or what you mean.  But if there is somewhere I can attach a document or clip, I've basically done screen shots and literally recorded myself trying to open this wallet.

I did that gentle tutorial and it showed it worked to 100%.  Would I be better off maybe trying to do that instead?  I just don't actually know how to get that to run, either. I think you guys assume that everyone lives and understands Unix.  Lots of us, however, don't.  It is like a foreign language to us and this really doesn't help matters .  I have a coinbase account and you know what I do when I have a problem?  I call their customer service and someone walks me through on the phone or handles it on their end.

But whoever you are....  you are the exception to the general statement that greenaddress is more than lacking in their customer service.  Youi've taken a great deal of time to try to help me when I don't know the first thing about anything you tell me.  But, I did follow through and got to the last part.  All I can say (because I don't know how to copy and paste anything-- cntrl  A & C & V don't seem to do the trick) is I saved my work by doing screen shots of all of it and saved it in a word document.

Also, I do have a clip showing me trying to get into the wallet, itself and the decryption showing up to the 100% and then the "Logon Failed" popping up.  Also, I show that I can get into the view only.  I have the nlocktime zip.  I just don't understand why I can't seem to be able to log in in the first place, why I have to try to do this recovery, why it's n ot working and why someone can't just take what I have and get the wallet open?

https://www.dropbox.com/s/9r0m31nufmp5gxa/Ubuntu-Wallet%20Recovery%20Attempt%2001.docx?dl=0

https://www.dropbox.com/s/vxjrpiralvyq7gs/GA%20Login%20Failure.MOV?dl=0

Please let me know if you would be willing to help me off this public forum so I can provide you with any info you would need in order to help me.  I can attach the nlocktime, mnemonics (&QR Code ), user name, password, etc. but I won't drop those into the dropbox and  publically announce where that information is                                                   for obvious reasons.   Again, I really appreciate the time you've taken to assist me.  I am apparently special needs.  Sorry about that.

(Note: you can paste with Right click -> paste) Firstly, please unzip garecovery.zip in Windows and then use cd into the unzipped folder. Then virtualenv venv then source venv/bin/activate then pip install --require-hashes -r tools/requirements.txt (notice the - between require and hashes) lastly pip install . (<-- . here) Thanks for the screenshots, now I can try to help easily. Let me know after you do these steps @JENNY

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


text:
Decrypting Bitcoin Core wallet with password that contains special characters
I have come across a Bitcoin Core wallet that uses a special character for the passphrase. When attempting to decrypt, it accepts the password but does not decrypt part of the keys.
Is there a known bug where core fails to decrypt key pairs using special non-standard characters?
This happens for Bitcoin Core version 0.19.1 for Mac 0SX.

There have previously been issues with entering passphrases that contain non-ascii characters, however these all were related to how the terminal processes those characters before Bitcoin Core does.
If you are receiving an error message that says something along the lines of "Some keys decrypt but not all", then the wallet has been corrupted. There are no known issues that would cause that other than wallet corruption.


text:
How do you know that your private key has been stolen?
How do I know whether my private key has been stolen?

If your private key was stolen, then the thief can provide you with definitive proof that he possesses the key---for example, by spending your funds.
But unless you have such proof, all you can do is guess whether your private key has been stolen.  There's no definitive way to prove that your key hasn't been stolen.
Usually, if you have enough evidence to worry that your key has been stolen, it's a good idea to take the steps you would take if you knew it was stolen.  For example, generate a new safe private key and address, and use your old private key to send funds to the new safe address.  That way your money is safe whether or not your old private key was stolen.

Thanks David for your prompt replies. Why do i asked this is because this man told me to send him my email, & he'll create a mining wallet for me in blockchain. If he created a mining wallet for me, he will definitely have the private key. Am i correct?
I just want to make sure that this isn't a scam.

I don't know what a mining wallet is, but if someone else creates a wallet for you, then you should assume they have access to your private keys and can steal your bitcoins at any time.


text:
How to send Bitcoin from one addresss to another using nodejs
which api i can use to tranfer BTC from one address to another. I have knowledge about bitcoin-transaction api but it does not allow to setup fees. We have try this api but it cost too much high for micro transactions.
If there is any option to setup fees i would prefer it because it not complex compared to others.

Bitcoinjs-lib allows fairly granular control over fees and transaction parts in general.

Learn bitcore-lib npm package:
Bitcore library provides a very simple API for creating transactions.
Let's take a very simple transactions:
var transaction = new Transaction()
    .from(utxos)          // Feed information about what unspent outputs one can use
    .to(address, amount)  // Add an output with the given amount of satoshis
    .change(address)      // Sets up a change address where the rest of the funds will go
    .sign(privkeySet)     // Signs all the inputs it can

Can you please share the URL for the same

https://github.com/ishwarchandratiwari/bitcore-lib

this is official link from where you can get more information http://bitcore.io/guide/

You can use the send-crypto to transfer bitcoin
npm install --save send-crypto
or
yarn add send-crypto
const CryptoAccount = require("send-crypto");
/* Load account from private key */
const privateKey = process.env.PRIVATE_KEY || CryptoAccount.newPrivateKey();
const account = new CryptoAccount(privateKey);
/* Print address */
console.log(await account.address("BTC"));
// > "1A1zP1eP5QGefi2DMPTfTL5SLmv7DivfNa"
/* Print balance */
console.log(await account.getBalance("BTC"));
// > 0.01
/* Send 0.01 BTC */
const txHash = await account
.send("1A1zP1eP5QGefi2DMPTfTL5SLmv7DivfNa", 0.01, "BTC")
.on("transactionHash", console.log)
// > "3387418aaddb4927209c5032f515aa442a6587d6e54677f08a03b8fa7789e688"
.on("confirmation", console.log);
// > 1
// > 2 ...
And also you can check the reference link https://www.npmjs.com/package/send-crypto


text:
Will Lightning Network still require a confirmation from the network?
I have studies the Lightning Network, and although I understand the concept, I have not understood the following:
Let's assume that a network channel is opened between parties and all transactions have been completed successfully (no cancellations whatsoever).
For the transaction balance to 'escape' the network channel, would a confirmation from the network (meaning the network as it is now) still be required?
As an example:
John gives Nathan 0.20 BTC (transaction occurred withing the Lightning Network) - no fees:perfect
- Nathan wants to send 0.20 BTC to an exchange - a confirmation from the network will be required, right?
So basically, the biggest benefit is reduced transaction time & zero fees between trusted parties, right? Confirming a transaction will still be inevitable?

Lightning Network (LN) payment channels are anchored on the blockchain by their owners cooperatively creating a 2-of-2 multisig address and sending funds to it. The funding usually comes from one party, but one channel owner can for example pay the other channel owner with the funding transaction by allocating the payment amount to them in the channel's initial balances. The channel anchor then remains unchanged on the blockchain until the payment channel is closed.
Payments on the LN are subsequently performed by the channel owners renegotiating their balance shares of the anchor's funds. Thus, as long as all payments are processed on LN, no on-chain action is required. When one of the two parties wants to use funds from the channel to send an on-chain transaction there are three possibilities:

Close: closing the channel and using the funds on-chain
Splice-out: cooperatively sending part of the funds out of the channel and re-committing the rest of the funds to a new channel with each other
Loop-out/submarine swap: paying a third party via LN to make an on-chain payment on their behalf

Confirmations  (i.e. when the miners solve the block containing your bitcoin transaction on the blockchain) are needed to open and close LN channels. I’d still wait for about 6 confirmations before starting to use a channel.
Once the channel is open you can send or receive as many LN payments as you want within the channel’s capacity, avoiding bitcoin fees, and no need for confirmations. If you trust the LN as a technology (as you trust the Bitcoin blockchain) then the Bitcoin you receive in LN is just as good as Bitcoin on the blockchain because you trust that you can always close the channel and get the same payment settled on chain. In other words, Bitcoins on the Lightning Network are 100% backed by the blockchain.
Channel can be kept open forever to avoid paying the chain fee for closing.

Lightning Network payment channels will need to be closed and settled on the blockchain if and only if the channel has become exhausted (i.e. one party owns all the funds in the channel) and there is no way to re-balance the funds through an alternative route of payment channels.
In your example it is possible that there exists a network (or route) of payment channels that enables Nathan to send the the 0.2 BTC to an exchange through the Lightning Network.

... more reasons when one would want to close the channel. For example, if someone tries to cheat then they get punished by the other party taking the funds that they have committed to the channel. That’s also settled on the blockchain.


text:
How to unblock an account that is held to ransom?
I have a blockchain account with bitcoins in but the account is held at ransom. I have to pay 2140$ to get a private key. Is there any way to report this to Blockchain.
I did a trading agreement. The dealer put my profits into a mining account on Blockchain. To retrieve my funds I need to purchase a key from the dealer to have the funds released. Hope I am making sense.

What? What? What? Do you mean blockchain.info? How can a blockchain.info-Account even be held at ransom?

Your question doesn't even make sence. If they have your private key (...they want to give it back to you...), they could easily transfer all your money away. So why should they ask you to pay money?

I have to pay 2140$ to get a private key.

That is invariably a solid indication you were the victim of a scam.

I did a trading agreement. The dealer put my profits into a mining account on Blockchain.

This is typical of scams and nothing like what happens with honest businesses.
Blockchain don't have a type of account called "mining accounts".
That isn't how Bitcoin mining actually works.
The "profits" are fake. Probably the criminal "dealer" set up a watch-only / non-spendable wallet to fool you into thinking the money shown belonged to you.

To retreive my funds I need to purchase a key from the dealer to have the funds released.

You are being cheated by someone dishonest. Keys are free. There is no such thing as a release fee in honest Bitcoin businesses.
The money you gave to the dealer was given to a criminal. Now the criminal is trying to get you to give them more money. Every time they succeed in tricking you they will invent a new reason for you to give them even more money. They will continue doing this until you either have no money left or realise that you are being tricked.

Is there any way to report this to Blockchain.

Blockchain.com and Blockchain.info are domains owned by Blockchain Luxembourg S.A. There is also a Blockchain Ltd mentioned on some of their web-pages but presumably this is a subsidiary company.
You can contact that European company through this web-page:
https://support.blockchain.com/hc/en-us/requests/new
The domain registrant is
Name:          Blockchain Admin
Organization:  Blockchain
Street:        Rue de Merl 74
City:          Luxembourg
Postal Code:   2146
Country:       LU
Phone:         +44.07476822631
Email:         email@blockchain.info

Note that the phone number looks like a UK mobile phone (cellphone), not a Luxembourg land-line.
The founder is Nicolas Cary, an American businessman.

If the wallet at Blockchain.com was created by the dealer, it is possible that Blockchain Luxembourg S.A. in Europe would not want to get involved in a dispute between you (a third party with no business relationship to them?) and their customer (the dealer). If the account was opened in your name, that might help to get them involved.
If you believe a dealer is holding your account to ransom, you should probably contact a lawyer or the police.

She does not state that her issue is with blockchain.com or blockchain.info in any way...


text:
Why is the Litecoin blockchain smaller than the Bitcoin one?
I do not understand why Litecoin's blockchain size is an order of magnitude smaller than Bitcoin's. Indeed according to this link the Bitcoin blockchain requires 196.52 GB and Litecoin's 16.55 GB.
In my expectation, the Litecoin blockchain should be bigger because the block size limit is the same, but the block interval is a quarter of the block interval of bitcoin.
Is this due to the smaller user base of Litecoin compared to Bitcoin?

That is a very interesting question.  I wonder (but am in no position to confirm) if the LTC blocks are only as large as the transactions that they include?

That's correct - blocks don't always take up the size they can take at a maximum. They will only take up as much space as needed for the transactions (which is why some blocks with only the coinbase tx are <1kb). Litecoin has also been around for less time than BTC, and has less use.

Up until 2017, both BTC and LTC had 1 MB block limit. When SegWit was soft-forked into both protocols, the capacity increased to a hypothetical 4 MB blockweight limit.
But the limit doesn't mean every block that's produced is 1 MB.  All it means is that it can not exceed 1 MB.  What determines the size of the block is the size of the transactions in the block.
Let's say, the data size of a "one in" and "one out" transaction is about 200 bytes.  Now let's pretend, there are 100 transactions like this that are included in a single block.  That means the total size of this block would be about 2 kB.  This is significantly smaller than 1 MB.
This is one of the reasons why LTC's blocksize is smaller than BTC's even though it blocks 4 times as fast. The actual blocks submitted and recorded were significantly smaller than 1 MB because there hasn't been as much activity on the network.  Another reason, like D Nguyen mentioned, is that LTC was started 2 years after BTC.

You're right, for the most part, Bitcoin and Litecoin have had the same blocksize limit of 1MB. After first Litecoin and then Bitcoin activated segwit, they now again have the same blockweight limit of 4MB.
However, that only determines the maximum size the blockchain could have had by now. We don't need to store data for unused blockspace!
Since the block header only makes up 80 bytes of data, the transaction data makes up the brunt of the blockchain. It turns out that even though Litecoin has had almost three times as many blocks (1,420,460) than Bitcoin (522,429) due to its faster interval, Litecoin has had much fewer transactions. Lately, Litecoin blocks have had an average size of 31 kB, while Bitcoin's have had about 815 kB in the past week.

Block size depend almost on number of transactions. You should take a look on "Transactions avg.per hour", litecoin is 839 while bitcoin is 8787, ten time higher than litecoin. Furthermore, litecoin is 2 year later than bitcoin.


text:
Mining reward for stale blocks
Suppose a miner mined a block and the block was part of the best chain. He must have got his mining reward then. Now suppose that due to a fork sometimes later, the block that he mined is no longer a part of the best chain, i.e. that block is stale now. Would he then retain his mining reward or would it get deducted?

If the block he mined is no longer a part of the main chain, then his mining fee for that block would simply not exist on the chain. So the miner would not retain the fee, but it wouldn't technically be 'deducted' either. 'Deducted' implies that the system is reducing the value of the miner's account. Instead, the system just has a different UTXO set, which does not include those mining fees.

When a block gets mined, the block reward and fees can only be spent by the miner after 100 blocks. If block gets orphaned before that, the reward and the fees are note deducted, they never get to exist at all.


text:
What the difference between old segwit (3) and new segwit address (bc)?
i'm not that kind of person who understands cryptography and math, can you tell me simply the main purpose of new segwit address? are transactions fee the same for new segwit (bc1)?
instead of "Old Segwit" and "New Segwit" what would you call em?

There's no big difference for users between the two. The fee is lower while using native Segwit address (bech32), and the address format differs.
Let's look at the motivations of bech32 address authors:

Old addresses (base58) need a lot of space in QR codes, as it cannot use the alphanumeric mode.
The mixed case in (old addresses) base58 makes it inconvenient to reliably write down, type on mobile keyboards, or read out loud.
Base58 addresses have double SHA256 checksum which is slow and have no error-detection guarantees.
Base58 decoding is complicated and relatively slow.

Another good reason: recently there were many forks of Bitcoin and almost all these new cryptocurrencies were using the same address prefix, which resulted in people mistakenly sending BTC to these addresses.

The difference lies in the encoding and the underlying representation in the transaction data stored on the blockchain.
The 3-segwit addresses are known as P2SH-P2WPKH or P2SH-P2WSH. This stands for Pay-to-witness-pubkey-hash wrapped in pay-to-script-hash and pay-to-witness-script-hash wrapped in pay-to-script-hash respectively. This was done to provide backwards compatibility with existing wallets and allow time to upgrade to the bc1 addresses.
The bc1 addresses are known as native segwit addresses. An address starting with bc1 is always going to be segwit, while a 3-address could also be a regular multisig or other script address.
Both the 3-address version and the bc1 version require less fees, although the bc1 version requires even fewer fees than the 3-address.
bc1 is bech32 encoded, which improves error detection over the original base58 encoding, and also helps prevent cross chain transactions (for instance, you will not be able to send LTC to a bc1 address, but sending LTC to a 3-address will go through just fine)
You can learn more about the design of bech32 in this talk by Pieter Wuille.

Thanks for your answer, there's many things you mentioned that I don't understand. I'm looking for a simple answer.


text:
What is the format of a bitcoin wallet?
I was wondering how bitcoin public and private keys are generated. E.g., a certain number of characters etc.  And how one could tell a litecoin address from a bitcoin address for instance.

the private key is only a (very big) integer-number. this number used as private key is all you need to generate a public key with some more or less complex mathematical operations and this private key is also the only thing which must be your secret. anyone can know your address and your public key, no problem. with the public key you can generate the address of the public key. (=>public key and address are not the same.)
a common used format to store a private key is the WIF-format. you can convert a private key to the wif-format and vice versa.
many people call a keypair (containing private- and public key) a "wallet". but technically you don't need any software to have a wallet. you can have a paper wallet for example as long as you do not want so send your funds to have full access to your funds.


text:
How do exchanges like ShapeShift, Changelly or Evercoin cope with KYC/AML regulation?
They don't require any information about their users. Most of the exchanges require user identification: so even though exchanges like ShapeShift might have corporate account on the large exchanges like Bittrex, Poloniex, Binance, shouldn't they disclose users' info to these large exchanges?

I don't think they should disclose the users' info because what they are doing is something close to arbitrage. They have created a market where they can buy low and then sell high and vice-versa. The will only make orders on the large exchanges when the money pool for some coin goes too low. I don't think there is a 1:1 relationship between orders on shapeshift and orders on the large exchanges.


text:
Does the Longest Chain Always Win the Mining Award?
If the longest chain (i.e, the one that's the most difficult to produce or the most transactions) is always awarded with 12.5 coins (or whatever the current prize is), what happens if a specific node is aware of a certain set of transactions but doesn't broadcast them to  other nodes (the network) and includes them in it's own hash.
Wouldn't this automatically guarantee it will win the mining award?

what happens if a specific node is aware of a certain set of transactions but doesn't broadcast them to other nodes (the network) and includes them in it's own hash.

Nothing bad happens, but the rest of the network will check to make sure the transactions are indeed valid once they receive the new block. If everything is valid then they accept that block as the new chaintip, and miners will start mining on top of it. In this way, miners can add their own transactions to blocks they find without broadcasting the transactions to the network first.

Wouldn't this automatically guarantee it will win the mining award?

No, the mining reward is claimable by any miner that finds a valid block. A block can be full of any transactions the miner would like (or none at all), but the exact transactions included will not alter the probability of a miner finding a valid block. If a miner fills a block with their own transactions that haven't been broadcast to the network, they will be at no advantage over a miner that is including only transactions that have been publicly broadcast.


text:
Minig 0.5BTC per month with a single AntMiner S9
I've used some calculators and the most I've found is mining around 0.06BTC a month. That's without electricity, internet, and cooling. How much do the major pools mine with a single S9? Can it be like 10 times more? There's a guy here saying that has a software that can make the S9 mine 0.5BTC a month. It's probably a lie, how do I catch him?

it's not about software, it's about the capacity of your device. so a software can't add some wings to your device.

He claims it can and shows me some bitcoins that he says he earned that way. How do I catch him that he's lying?

Software can't make the ASIC faster, that's not how ASICs work.


text:
Why isn't Bitcoin private by default?
Bitcoin is not fungible...so why haven't the Bitcoin core devs upgraded the protocol to make it private by default?

They are trying to add new features that would help with privacy! There is an upgrade proposal known as Taproot that would come with features to enable additional transaction privacy in Bitcoin.
Note, however, that major changes like this to Bitcoin are much more difficult than they are in smaller altcoins, simply because a significant amount of infrastructure must be updated, and getting so many different people and organizations to agree to a major update is challenging, although necessary to avoid a fork in the network. Also, there is an effort to keep updates backwards compatible with existing infrastructure, which limits the extent to which major changes like this are possible.

Bitcoins themselves are fungible, but the transaction graph is not. This is a small but important nuance: with properly crafted transactions, bitcoin users can gain privacy, without needing to implement more complicated cryptographic constructions.
This is currently an ongoing area of research, for more information you could look into techniques such as coinjoin, payjoin, taproot, the lightning network, etc. Some of these techniques involve obfuscating the chain of ownership through the transaction graph, others obfuscate the nature of the transaction itself, others move payments to a higher level protocol that doesn't leave a footprint on-chain in the first place.
As ieatpizza mentioned, large changes to the protocol can be difficult to implement, but they also bring new risks, as the network consensus will end up depending on new, as of yet untested-in-the-wild code.
In addition to that, the devs cannot just unilaterally decide to change the consensus rules: a majority of users would have to be on board, as would bitcoin businesses and infrastructure providers. It isn't impossible, but it is a very big undertaking.

I think this is a great answer, but "Bitcoins are fungible, but the transaction graph is not" is a contradiction to me. If you can trace them, that implies nonfungibility.

@PieterWuille by that I meant that within a transaction, the value of each output cannot be discerned to be coming from any specific input. Thus the 'bitcoin' itself is fungible, or at least it can be in the best case scenarios (though certainly not in every scenario). Maybe the most basic example would be an equal-output coinjoin; by observing the tx graph you can see that an output of that tx participated in the tx, yet you cannot trace it's ownership to any specific input. Maybe it would be more accurate to say 'bitcoin can be fungible, but the tx graph is not'.

To put it differently: if the value of an output was not fungible with respect to the inputs, then coinjoin/payjoin transactions would not be of any use in the first place.

I'd formulate that as "transactions have a mixing effect, which can be leveraged to improve privacy, but linkage between transactions is still visible, making this insufficient to guarantee fungibility".

Except for the technical and organizational challenges others have mentioned in their answers, I would like to add there is also a delicate matter of how Law Enforcement agencies such as police or various governmental tax agencies look at the ability to transfer and store amounts of money in untraceable private accounts - just look at the current leading private-coin - Monero, trading Monero was removed from several big online markets and it's value fell, I guess Bitcoin community would fear loss of value after seeing what happened to Monero.
Private-coin such as Monero is a double-edged sword for government. Corporations, who generally try to maintain good connections to governments (and in turn, governments, unofficially protect interests of important national corporations), traditionally evade paying tax and resort to Cayman Islands banks, private Swiss-bank accounts etc.
So in future it is likely bug business might be interested in keeping their money in private-coin, on the other hand, LE is worried about organized crime and terrorist groups hiding their finances behind private-coin.
Currently, future of private-coins is a subject to some speculation and uncertainty, and I don't think Bitcoin wants to take that path.

@Prayank I'm pretty sure Bitcoin won't become private coin, that would drop it's price, just the way it happened to Monero. I think privacy is not up to the developers, it is important for value of the crypt-currency.


text:
How is the clock reset in the Complex Script Example?
At the end of Mastering Bitcoin Chapter 7, in the "Complex Script Example", they ask this question in regards to the script:

How do the partners "reset" the clock every 29 or 89 days to prevent the lawyer from accessing the funds?

Does anyone have a good explanation for this? I feel like I missed something in the timelock section that might have explained this, but I'm not seeing it.

If at least two of the partners are cooperative with each other, they can move the funds at any time, even before the 30 days have elapsed. They can spend the output at any time using the second redeem path, with at least two signatures, for example:
0 <Mohammed's Sig> <Zaira's Sig> TRUE TRUE

So to 'renew' the time, they just need to spend the output by creating a new transaction with exactly the same output script, every time they want to renew it. Because the times use CSV, they are relative timelocks not absolute, so they don't need to be modified for each new transaction. Once a new transaction has been created which spends the output of the old one, that old output cannot be spent a second time so the lawyer must wait for the 30/90 days to elapse on the new transaction, and so on.

They 'reset' the clock by moving the funds to a new output before the period ends.

Can you elaborate a bit more?


text:
Does GDAX have weekl buy and sell limits?
I understand that CoinBase has weekly buy and sell limits. Does GDAX have this as well?

No.
From the GDAX support page (source):

Deposit (BTC, ETH, LTC): Unlimited
Deposit (ACH or SEPA): Varies
Deposit (USD via wire): Unlimited
Trade: Unlimited
Balance: Unlimited
Withdrawal: $10,000/day for individual accounts and $50,000/day for
  institutional accounts. To be considered for higher withdrawal limits,
  please go to your Settings within GDAX and click "Increase Limits."


text:
Would it be possible to retarget difficulty in real time?
Could the mining difficulty adjust in real time, not only when blocks are found?
(NOTE: Not asking about retargetting after every block but continuously as a function of time.)
I'm worried about how Bitcoin (and many other cryptos) change the difficulty. The basic idea is that the difficulty is adjusted every N blocks (N=2016 for Bitcoin and N=1 for Monero). That is, a difficulty can change only when a block is found. The problem is that if hashrate suddenly drops significantly, say 99%, then it would take 100x more time than normally to reach new lower difficulty. The drop could happen if the price of the coin drops and thus mining isn't anymore profitable. Network slows down and the price goes even more down and thus even more miners stop mining, and thus the coin might die. This seems like a very unstable system to me. I don't see much incentive for anyone to mine bitcoin if the price drops dramatically. The only incentive for some people to mine would be that they have lots of coins and they don't want the system to die. Not sure if this is enough.
To avoid this problem, could the difficulty adjust in real time, not only when blocks are found? That is, the difficulty requirement for a valid block would depend on the time it was found. The difficulty would decrease as a function of time, thus eventually a block will be found very easily. For instance, if 2 hours has passed since the last block, the difficulty could have already dropped to 1% of what it has been for the previous blocks.
The difficulty requirement of block N at time T would be a decreasing function of T and depends on the timestamps and difficulties of past blocks somehow. For instance, the difficulty could be a exponentially decaying function of time since the 10th last block and the mean difficulty of those 10 blocks. The difficulty of a mined block must be at least as great as given by this function in order for it to be valid. So the timestamp of a block becomes an important part of the block data.
Would this idea make sense? Is it implemented in any coin? Or is there some reason why it is not a problem that the difficulty adjusts when a block is found?

Possible duplicate of Why not retarget on every block?

Not exactly, although somewhat similar. I'm not asking about retargetting after every block but as a function of time.

Not the same, the distinction is important. Bitcoin and most other coins know of the passing of time because blocks are produced and broadcast on the netowrk.. Other than affixing time-stamps to data, they completely ignore real-time. They only act on these time-stamps when a block is received.  The question here is about adjusting difficulty in the complete absence of block production. The triggering event is an amount of elapsed real time, not the arrival of a block.

It's a security property that the difficulty is not retargeted quickly, not a technical or design limitation. It prevents a case where you can isolate a node, or a portion of the network, wait a brief period, and then mine at a vastly lower difficulty in order to defraud those users. If the mining rate drops, the fees rise, and more miners are incentivized to join the network- it's a self balancing system.

Ok. However, my suggestion about retargetting in real time isn't directly related to how quickly the retargetting should happen. It could take 1 week to drop the difficulty to half or whatever speed is wanted. The point is that one doesn't need to find blocks in order to retarget. It would be nice to know that the difficulty will eventually drop to such a level that the system will operate again after a major hashrate collapse.

Clarifying myself a bit: Although the retargetting would happen in real time, it doesn't mean that difficulty needs to change quickly. Difficulty can change slowly but it changes as a function of time, not (only) as a function of found blocks. So I don't see how this would be anymore unstable than the current retargetting solution.

Let's think of a case where the network is separted into two large groups. It's a far fetched scenario, but interesting. Suppose a fiber optic link breaks to China and all of Asia is isolated from the rest of the world. Each group of miners is then faced with too-high difficulty. If it is much too high, blocks won't be produced, and the network does not process transactions and is unusable. There ought to be the option for "local difficulty reduction" and a later merging of the forked chains, clearly with safeguards against double spends, etc.

I believe the answer is an emphatic YES, but just after a block has been found I would not immediately start applying the function-of-time difficulty reduction. I believe that would not be desirable, because mining is a random process. One should allow for the natural variability of the process before judging it to be "out of balance" and needing extra-ordinary adjusment. (Think of mining as tossing a dice with 2^256 faces, but only a subset of those faces are winners for a given toss.)  It obeys these laws of probability and statistics:

The number of blocks in an interval follows the Poisson distribution
The time between consecutive blocks follows the Exponential distribution
Probability of a block being found in time less than or equal to "t" is:
P(X≤t) = 1-e^(-λt)   where  λ = 1/β ,   and β = target interval time

Applying the exponential probability function in the case of bitcoin, the likelihood of a block being found in 10 minutes or less is:
1-e^(-(1/600 seconds) * 600 seconds) =  1-e^(-1) = 63.2120558829%
The likelihood of a block being found in 60 minutes or less is: 99.7521247823%
.... and  If we go out to 15,000 seconds (about 4.17 hours), the likelihood of a block having been found is 99.9999999986
Another way to state this is that, in 99.9999999986% of all cases, a block SHOULD HAVE BEEN FOUND by 4.17 hours; it is therefore a very sure bet, if the block has not been found, that there is, as you notice could happen, a serious mismatch between the true network hash rate and the difficulty factor of mining.
An arbitrary threshold time can be chose, beyond the which, if a block has not been found, the mining difficulty factor is to be lowered. Choosing this threshold is equivalent to asking 'How sure do you want to be that the system is unbalanced ... before "messing" with it ? '
Only if we're fairly certain that the system is really unbalanced (meaning difficulty is not matched to the current real network hashrate) should we start executing a protocol or algorithm, of 'extraordinary' difficulty reduction. It is at this point that I would consider the idea of an exponentially decaying-with-time difficulty function.
All this is predicated on accurate, shared time consensus. Establishing what the correct time is among a number of machines on the internet is not a trivial problem, but fortunately, has been solved since the mid 80's by the Network Time Protocol (NTP), and since the 1990's complemented by the inexpensive availability of very precise and globally availabe GPS satellite time signals.
(NTP was developed by Dr. Dave Mills at the University of Delaware and a new, streamlined and security-hardened version of NTPSec is by Eric S. Raymond and his group).  The correct time is not a matter of opinion, but of astronomical fact. Building a strong consensus of the best expression of current real time is NTP's job, and it does it quite well.
So, assuming that honest nodes, the mining "true chimers", have and use the correct real time, they will all know when a block is overdue, and according to the coin's protocol, can then agree that it is "too long overdue": current wait for the next block has exceeded the pre-established trigger wait threshold. Extraordinary measures must be taken. The question now becomes how much to reduce the difficulty factor.
The difficulty factor must be set to match network hashrate, BUT since no blocks are being produced, curent network hashrate can not be calculated : what must follow is a guessing stage, where a first difficulty reduction is made, then the network waits a reasonable time for a block to be produced. But, if again, no blocks are produced, then another difficulty reduction has to be made, since clearly the initial reduction was insufficient.
This protocol for difficulty reduction, (let's call it extraordinary difficulty reduction mode or 'EDRed mode'),  may have many variations. I would suggest the first reduction be maybe 1/2 to 2/3, and that he waiting period for the next block after 1st reduction be a shorter wait than the first trigger threshold.
Eventually, after 1, 2 or maybe even 3 or 4 reductions, blocks will start to be produced again, because the network's mining difficulty factor will be matched to the real network hash rate.
It is even likely that the difficulty will be a bit too "easy" since substantial,  "guessing" reductions were done - but the regular difficulty adjusting algos (Kimoto's Gravity Well or Dark Gravity Wave for example) used in alt-coins are quite good at quickly raising difficulty to more precisely match hashrate.
Once blocks are coming out again (that is, 2 or 3 blocks have been produced without another EDRed mode reduction being triggered), then the usual KGW or DGW algos can be allowed to govern difficulty again and EDRed mode is canceled.
(Bitcoin may have to adopt a more sophisticated difficulty-adjusting algo for its regular operation to implement a real-time-aware difficulty reduction protocol like this. I believe the recent Bitcoin Cash fork did adopt a more responsive algo than the simple adjustment every 2016 blocks of Bitcoin Core)

It is not trivial to retarget difficulty in real time, because it's non-trivial to achieve consensus on the current time of the network. It's sort of a catch-22. In order to introduce a real-time adaption into our consensus system, we would need to achieve consensus on something else before.

I realized after writing my answer that you explicitly exclude retargetting on every block, but since it's related, I'll leave it here anyway:
What could be done instead, would be to adjust the difficulty on every block. The challenges hereby are to find parameters that are clearly better: there is e.g. a trade-off between making the adjustment fast enough to make it useful, and so fast that it facilitates eclipse attacks as mentioned by Anonymous's answer.
Another subtle issue is that a readjustment on every block with the same best-chain rules would simplify reorganization attacks.
The attacker would go about this in the following fashion:
To reorganize a block 1A, they would search for a competing block 1B that has a slightly earlier date than 1A. However minuscule the adjustment on every block, this would mean that a follow-up block 2B would have a slightly higher difficulty score than the honest block 2A.
honest chain: 0 ← 1A ← 2A
attacker:       ↖ 1B ← 2B

Thus, when the attacker finds a second block, their chain would be the heaviest and the network would reorganize to that chain-tip even when 2A was found first. Previously, due to matching difficulty across the whole difficulty period, this attack would have been harder, as the attacker would have to find 2B before the honest miners author 2A.


text:
If I only know my private key, can I still login to my wallet, even if this requires some calculations?
I keep my 12 word mnemonics carefully off line. But suppose I just had my private key left after some disaster or other could I then, after some procedures, log in to my wallet ? I can see that I can get from Private Key to Public Address by a Python Routine but then I seem to be unable to progress further.

Yes. The main idea of mnemonic backups is that the mnemonic encodes a master private key. All other addresses that your wallet generates are derived from this initial secret.
To recover your transaction history and funds, you would need to go further than just to derive a single public key. You would need to rederive all of the wallet's addresses and then search the blockchain for any transactions that pertain to these addresses. The simplest way to achieve a recovery would be to import the mnemonic into the same wallet software that created it, or another wallet that implements the same derivation scheme (of which there are multiple, unfortunately).
I'd recommend that you additionally note what software was used to create the mnemonic, (and which wallet software you used to transact from the mnemonic, if the two differ). If you know it, you might also want to note the derivation path with your backup.


text:
Can someone explain this weird mining activity?
I can't figure why this block has 0 coinbase with 0 transactions... however still a valid block? Or it it empty? According to whalepanda this coinbase was sacrificed by unknown miner.
See the block at height
    501,726

It has no transactions other than the coinbase transaction. However, the transaction's coinbase output is 0 BTC. Here's the valuable piece of information that you are looking for:

Coinbase outputs may be set lower than the max. value (12.5 currently), and the block will be valid (if the difficulty is lower than the target, as always)

Also look at: https://btc.com/0000000000004c78956f8643262f3622acf22486b120421f893c0553702ba7b5
BTW, the miner loses money, for the price of being "cool".

i dont see anything special about this block https://btc.com/0000000000004c78956f8643262f3622acf22486b120421f893c0553702ba7b5

also why this block has more than 50 btc in coinbase output? 124,725
block -https://btc.com/0000000000006a01cb8932bc8a90b79297c744d4e5a355312208ab558b1e89a5

@anacondabitch: The coinbase transaction output can be, at most, the sum of the block reward plus the total of all transaction fees of other transactions in the block.  So this block had BTC 0.13 in transaction fees.  btc.com appears to display coinbase transactions in a confusing way; if you look at other block explorers (e.g. https://blockchain.info/block-index/139575/0000000000006a01cb8932bc8a90b79297c744d4e5a355312208ab558b1e89a5) it is more clear what is happening.

@NateEldredge lol looks like https://btc.com/0000000000004c78956f8643262f3622acf22486b120421f893c0553702ba7b5 lost -12.50000000 BTC in Fees .... i dont see any tx how does that happen?

@anacondabitch: You're misreading it.  This block had a total of 8 transactions.  One was the coinbase, seven had no fees, and the eighth had a fee of BTC 0.01.  So the coinbase was allowed to be up to BTC 50.01.  The miner chose to claim 49.99999999 instead, effectively destroying the remaining BTC 0.01000001.

@anacondabitch: I think the issue is that btc.com takes the value of the coinbase c;aimed, subtracts the block reward, and displays the result as "fees".  In the normal case, the maximum coinbase is claimed, which is in fact reward plus fees, so this number does equal the fees.  When the maximum coinbase is not claimed, this number can look funny or negative and doesn't accurately reflect the fees in the block.

Is this equivalent to burning bitcoin, or does it mean that there is more bitcoin available to be mined in a future block?

@SteveEllis Yes, they're equivalent. They've lost ~$150k.

Block contains "RSKBLOCK:Ý¿QzßýKÊwQP[9É:
ÔyüN9ÝW³GÆ$", so I think that it is related to www.rsk.co. Probably Sidechains synchronization.
EDIT:
Binary hex: "52534b424c4f434b3addbf517adf8ffd4bca7751505b39c9013a0d1fd479fc4e901b39dd57b347c624"
Source: https://blockchain.info/tx/9bf8853b3a823bbfa1e54017ae11a9e1f4d08a854dcce9f24e08114f2c921182?show_adv=true

what is that scary string?looks like some extraterrestrial code RSKBLOCK:Ý¿QzßýKÊwQP[9É: ÔyüN9ÝW³GÆ$

That string is not meant to be converted to text. Rather it is just binary for a RSK block hash. When converted to text, it looks to be a weird string.

@AndrewChow Well, the first 9 characters seem to be meaningful in text.

How did you converted hex: "52534b424c4f434b3addbf517adf8ffd4bca7751505b39c9013a0d1fd479fc4e901b39dd57b347c624" into ASCII ... any idea?

@anacondabitch try to search "hex to ASCII" on Google


text:
How does SegWit reduce transaction size, when the signature is simply moved to another part of the transaction?
This video explains that the signature is moved out of the input section and moved to the new one called the witness. From what I can tell, the witness signature is still contained in this transaction - how would a simple reordering of information magically create more space?
I've perused other articles and videos and none of them seem to address this "magic".

TL;DR:
SegWit does not reduce the transaction size, if you're referring to the raw byte length of transactions. Instead it introduces block weight as a new metric that does not directly correspond to the raw byte length of transactions, but treats witness data as having less weight than other parts of the transaction.

The limit for Bitcoin blocks has been changed with the activation of segwit. Blocks used to be limited to 1,000,000 bytes (1MB). Since segwit they are limited to 4,000,000 weight units.
In calculating the weight of a transaction, bytes are weighed differenty depending on whether they are part of the witness or not:

A non-witness byte weighs four weight units.
A witness byte weighs one weight unit.

This has the effect that a non-segwit transaction contributes exactly the same portion of the limit as before. E.g. the raw bytelength of a P2PKH transaction with one input und two outputs is 222 bytes, and it therefore weighs 888 WU, i.e. 222B / 1,000,000 B = 888 WU / 4,000,000 WU. This means that for non-segwit transactions, the block weight limit has exactly the same effect as the blocksize limit had before, and it is backwards compatible.
However, for segwit transactions the weight is not a quadruple of the raw transaction size. E.g. the raw bytelength of a P2SH-P2WSH 2-of-3 multisig transaction with one input and two outputs is 409 bytes, but its weight 868 WU as a large portion of the transaction input is witness data. A segwit transaction will therefore take a smaller portion of the weight limit than its raw bytelength would suggest.
To allow easier comparison to legacy fee rates, the block weight is often expressed as "virtual size" in "virtual bytes" or "vbytes". The virtual size is calculated by dividing the weight of a transaction by four and rounding up to the full integer. For non-segwit transactions, the raw bytelength and virtual size are equal.
In conclusion, the raw byte length of blocks can now exceed 1,000,000B, but the virtual size cannot exceed 1,000,000vB.

So weight must be an abstraction layer, cause when I have a block, that I want to store on disk, it consumes BYTES. Or when I transfer the block over net, the same Bytes are calculated. Would a maximum SegWit block transfer 4Megabytes? I was wondering, if the "weight" is only relevant for the fee calculation?

@pebwindkraft: I think 3.7MB is the maximum size that can be achieved as it's impossible to put all data into the witness. I don't know what you mean with "abstraction layer" but the block capacity is defined in weight. It's from that blockweight limit that the weight's relevance for the fee rate derives.

yup, thx, the block capacity is this "abstraction layer" (maybe not the right word, as I am not a native speaker). I was really thinking of bits and bytes, which are stored on disk (or are also transferred through the network connections). So block capacity ("weight") and disk capacity are something different. That was the confusing part. Sipa mentioned here (https://bitcoin.stackexchange.com/questions/58018/how-does-segwit-achieve-backwards-comtability-in-terms-of-the-block-size#comment66188_58018), blocksize would increase. As he is "godfather of segwit", I trust him :-) Segwit rocks!

@pebwindkraft: The virtual size of transactions is strictly smaller or equal to the raw transaction size, since part of the raw size is discounted. Hence with the virtual size limit being equal to the previous blocksize limit, the actual storage footprint can exceed the previous blocksize limit. A fact also observable in the lowest chart here: http://segwit.party/charts/

The short answer to the question in the title is simply that SegWit does not reduce transaction size (when size means bytes). What it does is define a new concept as 'size', which no longer directly corresponds to disk size. In this new size, the witness is discounted, and so - for all intents and purposes - transactions become 'smaller'.

@PieterWuille: Thanks, I added a TL;DR, inspired by this comment.

segwit IS a block size limit increase. No magic.
The segwit mechanism enforces a limit on a weighted data size calculated by counting the non-sig part of a transaction as base data (weight=4) and to count the sig data at a discounted rate (weight=1). The total of the block's weighted transaction sizes (called the 'block weight') is limited to 4MB.
Non-upgraded clients will only see the base data and will apply the old 1MB limit as before.
So now you can see the block size increase. If the transactions all have (almost) zero base data and mostly signature data then the actual block size can be up to 4MB. If the transactions have mostly base data and zero signature data then the block size can only be up to 1MB. The actual case will always be somewhere in between - hence an increase in block space.


text:
Why can't I see my transactions on Blockchain.com?
I've a Bitcoin address on which I made a couple of transactions. From what I understand of the blockchain, the ledger is public and anyone can list the transactions linked to a particular address.
If so, why do I see zero transaction when keying my address 39QUZnHVbtXGreq3zndkPtrg1TSho2Mbht on https://www.blockchain.com ?
Same for https://blockexplorer.com.

Are you sure the transactions were confirmed? If they don't get mined, they won't be included in a block. Also, how do you know this address has been used to make transactions?

I've made a transfer two days ago from an address stored on my computer with Electrum to this Coinbase address. Both Electrum and Coinbase show the transfer as confirmed and balances are updated.

it would make sense if this was the address you think you sent the coinbase funds from, because there is no guarantee which internal address coinbase decides to send coins from.

Are you sure that you sent BTC, and not some altcoin?

@chytrik yes I confirm it's BTC

Do you have a transaction-ID - what do the explorers say about the transaction?

By entering the details of the transaction on Blockchain.com I can see some info. The origin address is not the one I manage in Electrum and the destination address is not the one I see on Coinbase (it also seems that the BTC address on Coinbase regularly changes, confirming @JBaczuk's assumption).
Furthermore, why are there two destination addresses displayed on Blockchain.com ?

Have a read about change outputs and hd wallets

My assumption would be that this is due to the way coinbase handles deposits.
You can tell more of the story by grabbing the transaction details from their website.
Click on the transaction in the Accounts section and look for the "View transaction" link and it will take you to it.


text:
How does bitcoin implement checkpoint mechanism to finalize the blockchain history?
I read in Peercoin whitepaper that to prevent large blockchain reorganization, bitcoin also implements checkpoint mechanism which finalizes the blockchain history. Can you explain how exactly bitcoin implements this?

Checkpoints are a relatively misunderstood part bitcoin - Bitcoin does have a few checkpoints, but they are only used in one very specific case.  That case is just to ignore forks from the chain early on, before the most recently seen checkpoint. When a node has seen a block it recognises as a checkpoint, any further blocks received below that height will be ignored.
You can see this here: https://github.com/bitcoin/bitcoin/blob/0dfc25f82a01d9fec26380d95915df31e1fe2c02/src/validation.cpp#L3107
It is a long term goal of removing the checkpoints entirely, because they  are a source of confusion over the security model and power the developers have. But currently the role they serve is to prevent low difficulty header flooding attacks, and there has been no alternative solution proposed yet (that I know of)

So, at initial sync the client knows it is on the right chain, prevents forks from being created form early blocks?

@Willtech yes, but only if it has seen the right path. If it has never seen the true chain then the checkpoints do nothing.


text:
Transfer BTC to wrong address
I made a BTC transferred from the Luno exchange into my CEX exchange account, but I accidentally entered the CEX's BCH (bitcoin cash) wallet address instead of BTC and Luno did not blocked this receiving address.
Now, the transfer had transaction confirmation in blockchain public ledger
My CEX's BCH or BTC wallet did not reflected this deposit. Please advice me if any action for the recovery and how to make the deposit reflected in the CEX's wallet. I already raised urgent support tickets to both of the exchange, no reply from them yet.
Thanks in advance for you guys advices

contact CEX and explain to them, they should be able to give you the money since they control the private key.

Which party should able to rectify this issue?  Sending exchange or the receiving exchange? What will happen in case if they can't release the private key?  https://bitcointalk.org/index.php?topic=2071446.0


text:
What would happen if two miners were mining two blocks with two different set of transactions?
If two miners picked from the mempool two different sets of transactions, that were not dependent on each other.
Then could both miners, mine both blocks and not create a fork?
So miner 1 finishes the block and miner two sees that the block had nothing to do with his block, so he continues mining and adds that block onto miner 1s block after about a second?
I am assuming that forks only happen when both blocks mined have transactions that exist in both blocks

I am not subject matter expert on this topic. I have a reference from Andreas' book "Mastering Bitcoin" here, which is in Chapter 10, "Mining and Consensus" (page 240ff). <<Blocks might arrive at different nodes at different times, causing the nodes to have different perspectives of the blockchain. To resolve this, each node always selects and attempts to extend the chain of blocks that represents the most Proof-of-Work, also known as the longest chain or greatest cumulative work chain.>> (part 1 of 2)

<< By summing the work recorded in each block in a chain, a node can calculate the total amount of work that has been expended to create that chain. As long as all nodes select the greatest-cumulative-work chain, the global bitcoin network eventually converges to a consistent state. Forks occur as temporary inconsistencies between versions of the blockchain, which are resolved by eventual reconvergence as more blocks are added to one of the forks. >> (part 2 of 2). After this intro, there are like 8-9 pages explaining the fork, hope this helps to get you started.

@pebwindkraft I think I understand what would happen now. Thanks for the heads up. I will write an answer based upon that

No, each block must reference it's predecessor block in the header, and the blockchain has only a single block at each height. The second miner must therefore modify the block template that they are mining with to build on top of the just discovered block. They need to update the hash of the predecessor block and the blockchain height in the Coinbase transaction. Otherwise the block they would be finding would be competing with the just published for inclusion instead of writing forth the blockchain.
The rest of the block template could stay the same, if none of the transactions got included in the blockchain already.
However, your question sounds to me like you're thinking that searching for a block has progress. Mining is a progress-less process, each attempt may or may not succeed independently. Thus, it would be a more profitable strategy for each miner to try including the juiciest transactions (by highest fee rate) and to switch to a new block template whenever a block is published with the new juiciest transactions.

Oh, the irony... I JUST answered the exact same question on Stackoverflow. I'll copy the answer here:
You can imagine two competing miners creating blocks. If a miner doesn't have block N, he'll keep trying to mine that block. If he receives block number N after having mined it, the miner just ignores it, and we have a temporary fork in the blockchain with two branches, and block N+1 will have two different versions. Now what determines which branch survives is basically the branch that is mined faster. An arbitrary consensus rule is that the longer chain is always the correct chain. When a longer chain exists, all miners agree that this chain is the correct one.
The reason why this works, is because the probability of mining a block is wide enough over 10 minutes in Bitcoin (or block time in general).
The following image can be seen as the probability of mining a block over time (in bitcoin).

This is why it's wrong to create blockchains with very short time. Because if the time is very short (like 10 seconds), there will be tons of forks before the blockchain stabilizes.

Thank you for the insight. I do not think this answers my question. I am aware of what happens during a fork and how the network resolves it. My question is regarding whether a fork will happen if miner 1 and 2 are mining two independent blocks. And miner one adds his block, can miner two updates his chain and continue mining is same block as there are no conflicts?

@Kyle Branches are completely independent and don't have any relations. The only requirement is that each branch is consistent. One of them will die.

Are branches the same as forks? I am not sure I quite understand what you just said.

@Kyle a fork has multiple branches.

How can a fork have multiple branches?If I am not mistaken, when the bitcoin network branches, it creates a fork? I have not heard of the term "branch" before, I am new so still ignorant. Please correct me where I am wrong

You're confused with terminology. First, keep in mind that I'm not talking about protocol forks, like Bitcoin Cash. I'm talking about temporary blochchain forks due to mining (please read my answer again). A fork is the action of creating multiple branches, which looks like the fork you have in a kitchen. Topologically speaking (shape-wise), a fork has branches, and every branch can have a fork that has more branches.

Not really.

two sees that the block had nothing to do with his block, so he
  continues mining and adds that block onto mine

Once a miner sees an arrival of a block at the same height for which he himself is mining, it's end of the competition for that block. There is no point continuing mining.
However in event of miners creating simultaneous blocks, the forks would happen

I am assuming that forks only happen when both blocks mined have
  transactions that exist in both blocks

Miner should remove the transactions from memory pool which are already present in newly arrived block and start the mining for a fresh block

After reading  pebwindkraft comment, I have come up with an answer.
The particular extract "To resolve this, each node always selects and attempts to extend the chain of blocks that represents the most Proof-of-Work, also known as the longest chain or greatest cumulative work chain"
If the blockchain was currently:
Block1 -> Block2 -> Block3
And two miners pick from the mempool, transactions that do not overlap. Then this will cause a fork in the blockchain, if both broadcast at the same time.
This is because, even though the transaction do not overlap, the blockhash would be different for each miner, and if the blockhash is different then this is two different versions of the blockchain. Even if the transactions do not overlap.
If miner1 broadcasts first, then miner2 will have to start his block again, even though all transactions in miner1's block did not clash with miner2's. This is because as soon as miner1 adds to the blockchain. The chain becomes:
Block1 -> Block2 -> Block3->Block4
Where Block4 is miner1s block.
Miner2 has to start again because in his block, he was using the previous hash of block3, he now has to change it block4's hash.
If I have made a mistake, drop a comment instead of downvoting as I would like to know where I went wrong.


text:
How does reusing addresses hurt my privacy?
If I never conduct transactions from an IP address associated with my real life identity and never conduct a transaction with someone who knows me in real life, how can using the same address all the time (for the sake of simplicity) hurt my privacy?

There's a bigger attack surface for someone that wants to doxx you. They only need to link a single transaction to your real life person to know all the transactions you've participated in. A single payment to newegg, for instance, will identify you across all transactions.
Very few transactions are completely anonymous. But yes, if they're all completely anonymous, then you won't be hurting your privacy. However, that's much more the exception than the rule and you're probably leaking much more information than you think you are.

The more transactions tied to a particular address, the less the privacy. Hence a need for individuals to use Hierarchical Deterministic (HD) Wallets that generate a different address for receiving each transaction..
Look at difficulty factor and note 14TYdpodQQDKVgvUUcpaMzjJwhQ4KYsipa.  Then look at 14TYdpodQQDKVgvUUcpaMzjJwhQ4KYsipa.  With the example, it looks like Pieter Wuille (aka Sipa) has received almost 10 BTC, but currently has 0.1 BTC in his wallet - probably not worth a mugger's time. Note that every transaction is public information, includes dates and amounts spent.
Here is a short list of technologies that are mostly complementary for improving privacy:

Hierarchical Deterministic (HD) Wallets - improves privacy via obfuscation
TOR or I2P - reusable network and application anonymity, confidentiality technologies
CoinJoin, CoinMarket, CoinShuffle, CoinSwap - payer/sender anonymity
Ring Signatures - payer/sender anonymity
Stealth Transactions - payee/recipient confidentiality
BIP 47
Confidential Transactions - spender & recipient confidentiality
ZKCP (Zero Knowledge Contingent Payment) - trusting transactions without 3rd parties
ZK-SNARK (Zero Knowledge Succinct Non-Interactive Arguments of Knowledge) - bleeding edge

The application of stealth addresses (#5) or BIP 47 (#6) could have improved Sipa's privacy, but few wallets currently support such capabilities.

authors: Димитър Димитров


text:
Implementing Multi-Sig Escrow?
I want to start a BTC market.  I understand all the ways to go about creating a site, it's just the payment implementation which confuses me.  I want multi-sig transactions capable between my users on site.  If I understand correctly, multi-sig addresses are just special wallets anyways which require a certain fulfillment (2 out of three keys, for example) to go through.
How can I implement a system like this for my users on my server?  So I can allow users to trade without the middle man if possible, yet also have the opportunity for an escrow moderation in case something happens?  In the end a small percentage of market fees can be charged?
I'm new to Bitcoin programming but I'm assuming you simply have your web application interact with server daemons which dynamically create multi-sig addresses on demand for your users and somehow give them each a key, and leave a key for escrow moderation?  And that would probably be all you'd have to do?

If it's going to be a BTC market you control then you should just deem yourself as the escrow and let users transact through you just as silk road did. It's admirable that you want to remove trust from the equation but trying to create a system in which users send funds to each other with your permission is an unnecessary incumbent. If you went rogue and tried to spend the btc to yourself, my customer tries to send the cash to himself and I try to take the money back then the coins would just end up in limbo. A shady escrow admin is unlikely to reimburse users simply because the btc is wasted,

That's a good point.  Are there any frameworks you'd recommend for taking and handling payments as such?

Depends on your choice of language, I use Django because python is easy. If you like python then checkout the pycoin library. blockchain.info have a good python library for accessing their api but if you'd prefer to access bitcoind locally then python-bitcoinlib is useful for that :)

You basically got it.
create 2-of-3 multisig addresses (meaning needing two out of three signatures)
1 is for the buyer, 1 is for the seller, and 1 is for the mediator

buyer sends money to the multisig address, commiting the funds to the transaction
if the transaction goes well, buyer sends a signed transaction
spending the multisig output to the seller and sends the transaction
to the seller, the seller signs the tx and broadcasts it
if buyer is unhappy he/she can try to work out the matter with the
seller till they agree on any split of the money, it would involve
same steps as in (2) except now the money is divided (any
percentage) between the buyer and the seller
if the buyer and seller can't work things out, the mediator steps in
and after a decision is made, the money is split between the three
addresses (buyer, seller, fee for mediator)

So those are the conceptual steps to implement the scheme

At step #2, in detail, how can the buyer send the signed transaction to the seller?

the buyer can send the transaction via email for example

So the receiver will have to check if the transaction is signed by the sender manually, right? And there's no support for collectively signing a transaction by Bitcoin network?

@anhldbk I am not sure about that, perhaps post a question?


text:
Does address-reuse make Bitcoin private keys vulnerable to quantum computing?
Though quantum computing can technically break ECDSA with enough qubits, this has not the greatest implication on btc because public keys are not known as they are protected by the hashing used to create an address.
However, I've noticed online it's been said a few times that reusing addresses may reveal your public key?
Is this true?  Are there times your public key is revealed and quantum computers become a legitimate threat?

The simple explanation is that the attacks that quantum computing enables require information (the public key) that isn't available until after the first transaction is seen.
Until the first transaction spending an output, all that is known is the hashed version of the recipient key (aka the address) which isn't enough to mount the attack.  If fully developed quantum computers appear with no warning and somehow make it into the hands of a large miner they could potentially see an incoming transaction and race the transaction but the odds of this are vanishingly small.  Most likely, as QC becomes more of a danger, the algorithms in bitcoin will be swapped out for QC resistant ones.

authors: กรวิชญ์ ทาหอม


text:
See How Many Bitcoins Existed
Is there any way I can find out how many Bitcoins existed at a certain point in time?  Are there charts where I could, for example, see how many Bitcoins were in existence in 2011, so I could compare to the quantity existing today or something as such?

Yes. This chart from blockchain.info is one. There are probably many more.


text:
Will Electrum mnemonic seeds be forward compatible with all future versions of Electrum?
If I use the newest version of Electrum (2.6.4) to create a mnemonic seed and the current source code (2.6.4) later becomes unavailable, will I be still able to use a mnemonic seed I create now with all future version of Electrum?
I know that Electrum has changed the type of mnemonic seeds it uses at least once (from 12 to 13 words). Should I be concerned that future updates will eliminate compatibility with current mnemonic seeds?
Are there any advantages of my retaining a copy of Electrum (2.6.4) if my only purpose in doing so is wallet recovery several years from now?

Bitcoin Core does not support any form of mnemonic seeds.

In fact, the reason Electrum 2.x changed to a 13-word seed* and is incompatible with BIP39 is because they added a version number to the end of the seed. This has the purpose of allowing future versions of Electrum update the seed format while still understanding how to derive all the addresses from previous seed versions.

Standard Electrum seeds have 128 bits of entropy, plus 8 extra bits
  for checksum and seed version. Mycelium uses BIP39, which does not
  include a seed version.

https://github.com/spesmilo/electrum/issues/1733#issuecomment-200782966
Other clients rely on the community's formalisation practice through BIPs, where we all agree on a way to describe and encode/decode HD wallets. Years down the line, you should always be able to say "hey this was derived from BIP39" and everyone should still know what you mean. The developers of Electrum believe that including the version number and checksum is more important than adhering to a formal BIP format. There are no plans to propose a BIP for the Electrum convention.
"How do I make sure my cold storage wallet seed will be recoverable in x years?"
The standard answer is that Electrum is open source, and you should be able to find an archived version or at least find documentation on how to recover your wallet should the project shut down.
*It's not actually 13-words, it's just happens to have 13 words right now. In the future this may change to greater or fewer number of words, but it won't matter because the software will know the version/checksum.


text:
Double Spending before confirmation
What's to prevent someone from using bitcoin at a store like subway and double spending to buy the sandwich before a confirmation is made? Since subway obviously isn't going to wait for a confirmation, can't a person send bitcoin to subway and at the same time send that bitcoin to another address?

By default there is no way for a merchant to prevent a double spend whilst a transaction is in 0-conf state.
Lets assume for a second that all miners are simply motivated by fees and do not observe default mining policy (i.e. First Seen Safe (FSS), RBF-FSS and friends...) and continue to accept transactions that contain spent UTXOs. If you think about it that way, there are methods for a merchant to incentivise miners to favour the original transaction over the double spend transaction.
The merchant may elect to use a CPFP (Child pays for parent) transaction to increase the value of all subsequent transactions that are dependent on the preceding transaction that is being double spent. By doing so, miners will be incentivised to accept the original transaction over the double spent transaction.
The CPFP method is only effective contingent on the acceptance of the preceding transaction, so it may not work if the entire Bitcoin network only implements FSS as there would be an inherent inconsistent state of unconfirmed transaction (i.e. some partition of nodes P1 might think that the double spend is the valid transaction; while the other partition P2 might think the original transaction is the valid transaction).
In summary, to date, there are no known methods to accept zero-confirmation transactions due to how the reference client is implemented as it will reject transactions that contain spent UTXOs. So either the doublespent transaction will be accepted or the original will be accepted.

RBF exploits are possible for 0 confirmation transactions.
The risk/reward is tiny so some merchants will accept small transactions and make delivery without waiting for a confirmation first.
99.9% of the people who have both the competence and lack of morality to double spend in this manner would not waste their time on such a low value theft.
All merchants should wait for (at least) 1 confirmation of possible but the risk is too small for many people to care when selling sandwiches. Any merchant selling a yacht should be waiting for multiple confirmations anyway so the RBF exploit should not be relevant for high value transactions.

This has literally nothing to do with RBF, that's misinformation. A 0-conf transaction is exactly that: no confirmation, no certainty, no guarantee. There are a hundred ways to pull of double spends, with or without RBF flag set. And all of them already existed before the RBF flag was introduced in the first place.


text:
What is the risk of using wallet.dat files for long term cold storage?
i created these wallet.dat files on an offline machine in 2014 using QT.  I've sent coins to the receiving addies over the years.  these files are bip38 encrypted.  do i need to do anything to these files to keep them usable and viable?  if so, what?  additionally, what is the argument against this form of cold storage?  thanks so much.

As long as your machine remains offline and encrypted the files should be usable as long as your hard drive is.
People choose to make multiple forms of backup in part to protect against equipment failure. Paper wallets printed with appropriate paper and ink can last a very long time and can be stores in safety deposit boxes, buried in a hidden location (properly sealed of course) or hidden as words in a poem.
Hardware wallets are another option, but still will require you to store seed words in order to recover in case of equipment failure.

thanks Roman!  couple more ?s....  do i need to worry about upgrades to QT?  i also need to figure out the best way to take a wallet.dat file out of cs to spend/sell but i know there are many threads on that topic.  that being said, what is your preferred method?  any pitfalls to avoid?  thanks again.

Do not worry about future upgrades to QT as they will have backwards compatibility with your wallet.dat. My preferred method is a hardware wallet as it combines security with usability.


text:
About Selling the bitcoins for normal person
It's Aashish Sharma from Nepal. I have been mining bitcoins online for a few months. I want to, if I can, sell them online for cash or USD into my PayPal account. I don't know what can I do for few bitcoins. Or can I do normal online shopping with those few coins? Help me out.

In the Netherlands we got https://bitonic.nl/, where you can send them Bitcoins and they send the value (minus transaction costs) in euro (local currency) on your bank account. Maybe something similar exist in Nepal. But make sure you can trust the company. Just out of curiosity, how have you mine them? With ASIC/FPGA/GPU/CPU? Did you make any profit after subtracting the power cost?


text:
What happens if a miner receives a block but not its previous?
Suppose the following:

A miner has stored the current blockchain A-B-C.
It stops listening for blocks during some time.
During that time, blocks D and E are mined and broadcasted.
The miner reconnects and immediately listens to the block E, before even knowing about D.

Will the miner simply ignore that block? And, how will the miner update to A-B-C-D-E (step by step)?

Will the miner simply ignore that block?

Yes, the block will be just ignored by the miner.

how will the miner update to A-B-C-D-E (step by step)?

When the miner's node gets online and start connecting to peers, it will start a “handshake” by transmitting a version message, which contains all basic identifying information, including BestHeight (the blockchain height of the node). Since v0.10, the nodes sync with 'headers-first'. This means that the nodes when restarted first ask peers for block headers and validate those. The getheaders message requests a headers message that provides block headers starting from a particular point in the blockchain. The connected peers will respond with a headers message that sends block headers to the node which requested certain headers with a getheaders message. The disconnected miner's node will then verify the difficulty until the tip. This allows a peer which has been disconnected to get the headers it hasn’t seen yet.
In a second stage, when the headers have been discovered, the node can then download the blocks. However, as the node already know about the whole chain in advance due to the block headers it has received, the blocks can be downloaded in parallel from all available peers. These blocks are received through getdata requests.
The above process describes the syncing of node when it was disconnected for some time. To make the answer more complete, I'll expand a bit further as to how new transactions and blocks are broadcasted. Nodes unsolicitedly transmits inv message (inventory message) containing one or more inventories of objects known to the transmitting peer. It can be sent to announce new transactions or blocks. The receiving peer can then compare the inventories from an inv message against the inventories it has already seen, and then use a follow-up getdata message to request unseen objects.

Good answer, but there is one amendment I'd like to propose: I believe that the synchronizing node will first get all the blockheaders leading up to the best chain-tip to verify its total difficulty, then retrieve the remaining block data. Ever since header-first propagation, orphan blocks as mentioned by the asker are essentially not occurring anymore.

@Murch I think I have the same process. Get block headers through inv and then retrieve data through getdata command. I think I only need to add about verifying total difficulty. Does that sound fair or I'm missing something?

Right, but your text currently says it gets the only the hashes. It gets the complete headers, though. The headers are enough to check the links in the chain of blocks and the difficulty. That means that some attacks (like long low difficulty chaintips that end up not being the best chaintip) can be identified early, before the heavy lifting of actually validating the full block content is done.

@Murch  Ah right! That was my bad. Read it before having my morning coffee. I'll incorporate it in my answer.

@Murch Looks like things had changed pretty dramatically since v0.10. I had read a previous version of sync process. It seems getblocks request is rarely used. I have revamped my answer. Feel free to edit if you notice a goof-up on my part.

Blockchain is built to have each block linked to the previous, as a result of; the hash in C has every information from B to duplicate that of C to D and D to E. To update the blockchain, care fully compare the time stamp and the information recorded in the Block E. Any discrepancies in Timestamp or recorded transaction would mean a tamper. The system won’t recognize such transaction.


text:
Changing prune size in working bitcoin daemon
I need to free some disk space in bitcoin server.
Will bitcoind download all blocks from scratch again if I change 'prune' value in bitcoin.conf over working daemon?

The prune value merely sets the limit of how much block data is kept.
If you increase the value and restart, no block data will be deleted for a while. New blocks will be received and validated and stored, and old ones won't be deleted until the new prune value is reached again.
If you decrease the value and restart, the oldest blocks will be deleted at startup.
You cannot go from pruned to nonpruned. That requires starting over.


text:
Does the NBitcoin library internally use blockchain.info to process transactions?
My concern is about miner's fee, who is taking that amount? Blockchain.info or NBitcoin? I just wanted to confirm whether the library internally uses blockchain.info apis for performing transactions.

Are you referring to the .NET library NBitcoin (https://github.com/MetacoSA/NBitcoin), or something else?  Your question is very unclear what it is asking.

Yes, I m talking about .Net Library NBitcoin. I just wanted to confirm whether this framework internally uses blockchain apis for performing transactions.

By blockchain, do you mean the bitcoin blockchain (the distributed ledger), or the commercial service blockchain.info?

I meant Commercial service blockchain.info

Please edit your question to include the information you provided in the comments to clarify it.

I've edited the question to add the information from the comments. However, the question appears to grow from a misunderstanding: libraries and wallet services cannot collect transaction fees. It's always the miners that get the fee.

No, NBitcoin does not use Blockchain.info's API in order to interact with the Bitcoin blockchain.  It implmenents the Bitcoin scripting language, network protocol, transaction construction, and other aspects.  This allows programmers to use NBitcoin to directly interact with the Bitcoin network.
Since transaction construction is in the hands of the NBitcoin user, transactions can be constructed with whatever miner fees you choose.


text:
How to calculate low/medium/high fee transaction fee?
I have a website where the users can send and withdraw funds using Bitcoin, I'd like to give them the chance of set their own custom fee (Low, medium and high) instead of the site to choose a fixed fee or than allow bitcoind to choose it..
For it, after read and investigate, I've seen that bitcoind have a json-rpc call with the name of ''estimatefee'' which allow us to calculate in real time the fee for the transaction appears on the specified blocks.
I guess that for a high it should be checking the fee in the next 2 blocks, for a normal fee in the next 12 blocks and for a low fee in the next 25 blocks, I've saved the obtained results and I Have comparate them with the data provided by Blockcypher's API: curl https://api.blockcypher.com/v1/btc/main , which it give us a higher fee on the low priority than in the medium, this is weird for me, but except that the rest of the data provided are quite inferior to those that I Have obtained, which makes me think that maybe I am making the calculation of an incorrect way (as all the fees I have obtained are at least the double than the one provided by Blockcypher).
And here is the data obtained from bitcoind:
bitcoin-cli estimatefee 25
0.00198478

bitcoin-cli estimatefee 12
0.00265746

bitcoin-cli estimatefee 2
0.00352903

And here is the data from Blockcypher:
"high_fee_per_kb": 174625,
"medium_fee_per_kb": 83628,
"low_fee_per_kb": 90769,

I haven't found many information related with this, if someone could help me, I would be grateful.
Thanks in advance

There's a site Bitcoin Average offering free or payed services depending on your usage that enables you to calculate the fee estimation for Bitcoin and other currencies for your website/web application.
Bitcoin Average
A variety of fee estimation services have been developed to help users navigate the fee market you can find info here:
Bitcoin Transaction Fee Estimates