What are the hashes that miners need to do to create a block?

Another source just says that it’s just hash of the block itself, and in that block we specify the hash of the previous block’s hash.

This is correct. The others are varying degrees of correct and incorrect. But this is the only one that is absolutely correct.

The concept of Proof of Work is that you have X and you have an output of Z, what is the Y needed, so hash(X + Y) = Z.
If that's the case, can we say that X is the previous block's hash, and Y is the hash of the current block? Or am I looking this wrongly?

Kind of.

The block consists of multiple fields. It can first be broken down into two major parts: the block header, and the transactions themselves. All of the block is hashed in some way.
The hash of the block header is what we call the hash of the block. The hash of the block header is also what is used for the proof of work. When you interpret the block header's hash (also known as the block hash) as a 256 bit little endian integer, it must be less than a calculated target (also a 256 bit integer).
The block header itself can be broken further down into multiple parts. It contains the block version number, the previous block's hash, the hash of all of the transactions in the block, a timestamp, a compact representation of the target value, and a nonce.
Since the block header includes the previous block's hash, the block header's hash is really just the hash of the block (as it contains the hash of all of the block's transaction) in which the previous block's hash is specified within it.
In order to mine blocks, miners will tweak the fields in the block header until they get one that meets the target. Typically they change the nonce value (it's just a number) and the hash of all of the transactions in the block (by changing the coinbase transaction, choosing new transactions, and changing the order of transactions). Miners may also change the timestamp and the version number.


Which exchanges support U2F authentication?

As you have correctly noticed none of the Bitcoin exchanges have implemented the FIDO standards there is not a large demand for this feature from what I gather.  If the standard were to gain mass adoption and many users began requesting it I'm sure it would become a greater priority for exchanges to implement.

As a side note the Ledger hardware wallet does support the U2F standard and would be a great way to improve the security of your wallet (as long as you don't connect the two to each other (i.e. same keychain)).


To determine the current blockheight of any coin, you will need to pull data from the network itself. The source code that runs a node for any coin will not include this information.

A full node will download the blockchain history, so your node could then report the current blockheight back to you. The source code basically contains instructions telling your computer how to do this, but the explicit block height is not contained within the source code.


How to receive transaction in bitcoinj wallet

Technically you don't need to have an updated blockchain to receive coins: just create an address and anyone will be able to send to that address. Until the blockchain is updated, you won't see those incoming coins, so you won't be able to spend them, but you will as soon as the update finishes.


According to the Bitcoin wiki https://en.bitcoin.it/wiki/Satoshi_Client_Node_Discovery

  Nodes discover their own external address by various methods.
  Nodes discover their own external address by various methods.
  Nodes makes DNS request to receive IP addresses.
  Nodes can use addresses hard coded into the software.
  Nodes exchange addresses with other nodes.
  Nodes store addresses in a database and read that database on startup.
  Nodes can be provided addresses as command line arguments
  Nodes read addresses from a user provided text file on startup

Because this is peer-to-peer technology the client is usually connected to more than one node at a time. The reference client validates every bit of information it receives. If a financial company was to go rouge and send false or incomplete data the software would realise the data is invalid and rely on the other connected nodes to operate.


What prevents an attacker from doing DDOS on bitcoin network by sending billions of transaction to himself?

This attack wouldn't work very well, no matter how much money the attacker had.

Your question seems to be based on the assumption that transactions larger than BTC 0.01 can always be sent without fees.  This is not accurate.

There are two main risks from such an attack:

The attacker's transactions might occupy all the available space in blocks, preventing other people from having their transactions confirmed.
The nodes on the peer-to-peer network might use a lot of bandwidth relaying the attacker's transactions, and not relay other transactions.

What I will describe here is how this issue is avoided by miners and nodes using the unmodified Bitcoin Core software.  The rules implemented by this software are explained in detail here, and what follows is merely a summary. Of course, people are free to use other software, so these rules are not universally followed.  Nevertheless, as long as a significant fraction of miners / users do something similar to this, the attack won't cause serious problems.

As for 1, when selecting which transactions to include in a block, transactions with fees are generally preferred to transactions without fees, and higher fees are preferred to lower fees.  So your attacker's zero-fee transactions would generally not displace those of users who did pay fees.

As an exception, 50 Kbytes in each block are reserved for high-priority transactions, even if they have no fees.  Priority is set not only by the size of the transaction, but by the age of its inputs (the so-called "bitcoin days destroyed" metric).  If our attacker wants to make lots of transactions, he will have to send the same coins over and over again, meaning the age of the inputs will be low.  Other transactions that go unconfirmed for a while will slowly gain priority and eventually exceed those of our attacker.

So in summary:

Fee-paying transactions would not be disrupted
Non fee-paying transactions might be delayed, but would still eventually go through.

As for relaying, a simpler rule is used: there is a flat limit on the number of bytes per minute of non-fee-paying transactions that will be relayed.  Fee-paying transactions are not subject to this limit.  So:

Fee-paying transactions would still be relayed as before
Nodes would not use an excessive amount of bandwidth in relaying the attacker's transactions; most of them would not be relayed
Non fee-paying transactions might have a harder time being relayed.  Users could avoid this by including transaction fees, or by submitting their transactions directly to miners without using the peer-to-peer network.


What is the alternative for an exchange which doesnt want to run a node of a coin traded?

It seems to be best practice for an exchange to run a node itself for a coin traded there. But, is there an alternative?

Alternative is to rely on someone else as mentioned by sipa which isn't best practice although few exchanges do it and face consequences for it.
Example: https://www.reddit.com/r/Bitcoin/comments/hpg9j3/336_btc_hacked_from_cashaa_they_were_using/fxrrbiw/

A third party service? If yes, which are recommended and why?

Lot of third parties provide services that exchanges don't have to run their bitcoin full node. I would never use an exchange if I know they are not competent enough to run full node and manage users funds securely.
Also service recommendations are offtopic here: How should questions that function like reviews be handled?


From wkipedia

It looks like they are mostly advertising sites that want to introduce people to coins by giving them small amounts that they can then play with and get comfortable using them before buying larger amounts.


How to find the Bitcoin addresses used to create a Multi Signature address

Yes.

After the spending multisig transaction is on the blockchain (not the funding transaction), you can see the public keys used to spend those multisig funds.

These public keys are found in the full redeemScript provided in the spending transaction. See a breakdown of a multisig spending transaction here, which shows that a redeemScript is indeed included in the spending transaction. See a breakdown of the full redeemScript here, which shows that the public keys are included in this full redeemScript.

Let me clarify that the public keys are not seen in the funding transaction because only the redeemScript hash is revealed here, not the full redeem script.

Note: In the explanation above, I'm assuming you are talking about the Pay to Script Hash (P2SH) form of multisig, which is the more common and modern form of multisig. The answer to your question would still be yes for a non-P2SH multisig transaction, except that the public keys are visible in the funding transaction, rather than the spending transaction. The public keys are revealed in the scriptPubKey of the funding transaction, which looks like:

<m> <A pubkey> [B pubkey] [C pubkey...] <n> OP_CHECKMULTISIG

Source: https://bitcoin.org/en/developer-guide#multisig


Data about number of block mined + stale blocks per day in Bitcoin?

To my knowledge, there is no high quality data source for this.

Blocks mined is fairly simple to check, as that is simply the main chain's progress.

Stale blocks is harder for Bitcoin and Bitcoin based currencies. Unlikely ethereum's uncles, references to stale blocks are not stored anywhere, and after a better chain exists, propagation will not take place, so many nodes do not see a stale block at all. The only way to collect data would be to run multiple nodes, connected to as many different peers are possible, and monitor the logs for chain tip reorganizations. As far as I'm aware, no one is currently doing this, and if they are it is not offered as a publicly available dataset.


Coinbase probably requires even more confirmations for a deposit of that high a value. According to https://www.crypto51.app at this moment, it would cost some $600,000 to attack the Bitcoin blockchain for one hour. That means sustaining a 51% attack and potentially (not definitely) double-spending a deposit to Coinbase that had several confirmations.

If you are a merchant that accepts Bitcoin you must take this risk into account given the value of the transaction. A $1000 deposit to Coinbase is probably safe after three confirmations, because it would cost so much more than $1000 to reverse three blocks.


Sent btc to unknown address. Btc remains unspent

There is a plethora of things wrong here that make it almost impossible if not impossible to receive your Bitcoin Back.

You must know who you send the Bitcoin to in order to contact them, if you don't know who they are, you cannot find out their identity (pretty much), because Bitcoin is supposed to be anonymous and its near impossible to find someones identity from a wallet address (pretty much impossible)
The Blockchain is completely transparent, you can see all transactions ever made, so if you sent any Bitcoin to a wrong address, you could see to what address you sent it to.
Even if you knew the address, like I said in number 1, you would have to have their contact information and ask them to send the Bitcoin back to you
The person you've sent it to might not want to send it back to you, if you somehow get their contact.
that wallet address you sent the Bitcoin to might be inactive... in other words you (dropped it into a black hole that gobbled it up forever, or) sent it to someone's old wallet they don't use anymore/lost/deleted or will never look at it and it will always remain there, unspent, forever.


Multiple bitcoin transactions between addresses in the same wallet

Coinbase sometimes creates an address to move your bitcoin from cold storage. Any movement ie downloading to offline storage. will require a hash for the block chain/transaction  to "track" the bitcoin. Hence the appearance of transactions in the wallet.


How to get the bitcoin balance of a public key in C#?

If you are ok with a third party service check out the Blockchain API.

They have a C# library and it's fairly easy to use.

If you need only the balance of an address you can use the code below as described on their BlockExplorer page:

 // calculate the balanace of an address by fetching a list of all its unspent outputs
 var outs = blockExplorer.GetUnspentOutputs("1EjmmDULiZT2GCbJSeXRbjbJVvAPYkSDBw");
 long totalUnspentValue = outs.Sum(x => x.Value);


I am developing an open source wallet that handles multiple currencies and stores the keys in a deterministic key chain (BIP44).

It is currently on Android but it is written in am modular way so that the core library could be used in any java application. The library is based on a slightly modified Bitcoinj and for the blockchain queries it uses Electrum servers. It supports BTC, LTC, DOGE and in beta PPC, DRK, RDD and I am adding now NuBits.

Check out the repo from here: https://github.com/Coinomi/coinomi-android. At some point I will separate the core lib from the android app.

enjoy


How does blockchain.info's mixing service work?

Their shared sending feature simply combines payments from multiple users making it very difficult to know which funding inputs (Bitcoin addresses) were used to pay which outputs (Addresses being paid).

Think of it like collecting money at the office to pay for a coffee run.   Five people are buying coffee, each costing $3.

Bob puts in a $5, for a latte
Alice puts in $3, for an espresso
Carolyn puts in $10 for a cappucino

A driver goes to the coffee shop, the bill totals $9, so the $10 bill is handed over and given out is a cappucino, an espresso and a latte.  A $1 of change is given back to the driver.

Back at the office the driver gives bob the $1 from the coffee shop plus a $1 that was received from Alice.  The driver gives Caroylyn the $5 that came from Bob and two $1s that came from Alice.  Each person gets their coffee.

That's actually a very weak example but it shows a real world example of how shared spending "mixes".  It might look like Bob didn't buy coffee from the store, but instead it looks like he bought it from Carolyn. And it looks like Alice bought from both Bob and Carolyn.  But none of that is how it actually occurred because the funds were combined prior to making the purchase.

Some of the coins mixed in are those arriving for on-time use address in which the Blockchain wallet user has clicked the "New Shared Address" option under Receive money.  The amounts received will incur a fee.


Miner seems to be stuck at receiving new blocks

Try instead GPU mining with Cgminer 3.7.2 it has always worked well for me. Using CPU on a machine only, is really not worth it.


Why is the scriptPubKey required when using signrawtransaction?

Ahh, just found the answer. Should have read the help all the way through. It says:

  The second optional argument (may be null) is an array of previous transaction outputs that
  this transaction depends on but may not yet be in the block chain.

So, it's there so that the method can be used even if the transaction it depends on doesn't exist yet. If it does exist, however, the client is smart and does extra error checking to make sure that you don't mess up.


Parsing a SegWit transaction - what is the size of witness data?

I found it:

Each witness field starts with a compactSize integer to indicate the number of stack items for the corresponding txin. It is then followed by witness stack item(s) for the corresponding txin, if any.

Each witness stack item starts with a compactSize integer to indicate the number of bytes of the item.

If a txin is not associated with any witness data, its corresponding witness field is an exact 0x00, indicating that the number of witness stack items is zero.

for each input {
    stackItems = read integer
    if stackItems > 0 {
        for each stackItem {
            bytes = read integer
            //witness data is bytes long
        }
    }
}


Set lower limit to incoming new channels in LND

If you look at lnd.conf (or in particular at the sample-lnd.conf line 138) you will see the following:

; The smallest channel size (in satoshis) that we should accept. Incoming
; channels smaller than this will be rejected, default value 20000.
; minchansize=

which means if you remove the ; and set a value in satoshis your node will reject smaller channels.

After changing lnd.conf you have to restart your node and then it should behave in the way you want


GUI miner not working properly (slush's pool)

I agree that you really don't want to be mining with your cpu.  If this was with your gpu and this was happening, your debug output would probably involve a "check your hardware" error like the one many people got from the newest AMD SDK.  That is fixed by rolling back drivers to the best compatible set.

You should look at the console by going to the menu bar: View > Show Console.  Click the tab that pops up named Console and perhaps post a screenshot of that.


Sending BTC from old QT Client V0.7 - Will coins arrive?

There haven't been any Bitcoin hard forks in the last 3 years so your old client should still work fine. Of course it won't be able to use new features like SegWit but that shouldn't matter.

Does your v0.7.2 client have the "Transactions" menu option. Double clicking the pending transaction will tell you it's status. If you don't have that menu option where are you getting the transaction ID from?

If you're still getting nowhere with your old client then in your shoes I'd take the following steps:

If you haven't already backed up your wallet then in your v0.7.2 client do File->Backup Wallet and save it to a USB drive or somewhere safe,
Download the latest Bitcoin Core client and install it,
Run the new client and it should update your wallet if it needs to,
If your blockchain is not synchronised then unfortunately you may have to wait a long time (days) for it to catch up,
Try another test transaction with the new client.

There are other options that you could do with your existing client, such as extract your private key with the Debug Window->Console, but that could go wrong very easily. Your number one concern is obviously not to lose your private key(s) and even if it takes a number of days to sync your new client that's a small price to pay.


What does this phishing website compromise?

LocalBitcoins provides two-factor authentication which protects you against all kinds of phishing attacks. Even if the attacker gains access to your password by phishing link or malware (e.g. infected Windows machine), they cannot access your one time codes needed to login and do transactions.

LocalBitcoins recommends you to enable two-factor authentication on your Wallet page (if you have bitcoins) and every time in your user profile navigation bar unless it is enabled.

There are two different methods for two-factor authentication

Mobile app (Google Authenticator) - works on iPhone, Android and other smart phones
Paper codes (you print a set of one time codes)

Both options can be enabled from the link shown in the screenshot above, or from this direct link. For both options, you need to also make sure you have a proper backup as in the case you lose access to your mobile phone with two-factor authentication app you cannot no longer login to LocalBitcoins.

To receive the email in the question the user probably has published email in an advertisement, LocalBitcoins forums or given it to a malicious trader. LocalBitcoins recommends you do not do communications or trade deals off-site outside LocalBitcoins messaging system.

In the case you have already given your password to a phishing site

Change your LocalBitcoins password immediately
Enable two-factor authentication as instructed above


The bolded byte in the following raw transaction is the number of outputs (two in this transaction):

  0100000001186f9f998a5aa6f048e51dd8419a14d8a0f1a8a2836dd734d2804fe65fa35779000000008b483045022100884d142d86652a3f47ba4746ec719bbfbd040a570b1deccbb6498c75c4ae24cb02204b9f039ff08df09cbe9f6addac960298cad530a863ea8f53982c09db8f6e381301410484ecc0d46f1918b30928fa0e4ed99f16a0fb4fde0735e7ade8416ab9fe423cc5412336376789d172787ec3457eee41c04f4938de5cc17b4a10fa336a8d752adfffffffff0260e31600000000001976a914ab68025513c3dbd2f7b92a94e0581f5d50f654e788acd0ef8000000000001976a9147f9b1a7fb68d60c536c2fd8aeaa53a8f3cc025a888ac00000000

The Bitcoin.org Developer Documentation has an extended description of the raw transaction format if you'd like more information.


What happens to bitcoins that are in a ponzi scheme wallet?

If you send BTC to a custodial wallet (ie, one which you do not control the private keys for), then you no longer have control of your bitcoin (whoever has the private keys is now in control). If you send coins to a website (to buy some tokens, or whatever), then it is the website operators who now have control of your coins.

This is a well-known saying in bitcoin: not your keys, not your coins.

  I would like to know, is there any way for those coins to be retrieved, or will they just disappear?

You can ask for the coins back, but if it is a scam, then chances are the scammers will not send you anything. You could report the scam/theft to local authorities, but chances are they will not be able to do much at all.

The coins will not 'disappear', they are just owned by the scammers now.

If you buy a token / cryptocurrency that is created and maintained by some central authority, then you are implicitly trusting that the central authority will not act maliciously. This is quite the opposite of Bitcoin, in which the user can trustlessly interact with the network, depending on no third party to receive/hold/send funds.


what will be the best approach to accept Bitcoin payment instantly?

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.


Can the fee produced by estimatefee be artificially manipulated?

No, estimatefee is calculated locally by bitcoind in function of some statistics done on mempool.


How to generate Hash160 from a private key with the Bitcoin module

I am using a different bitcoin library. This prints address and hash160 from a private key:

from bitcoinutils.setup import setup
from bitcoinutils.keys import P2pkhAddress, PrivateKey, PublicKey

def main():
    # setup the network
    setup('testnet')

    # provide a private WIF key
    priv = PrivateKey.from_wif('cMahea7zqjxrtgAbB7LSGbcQUr1uX1ojuat9jZodMN87K7XCyj5v')

    # get the public key
    pub = priv.get_public_key()

    # get address from public key
    address = pub.get_address()

    # print address and hash160
    print("Address:", address.to_string())
    print("Hash160:", address.to_hash160())

    print("\n--------------------------------------\n")

if __name__ == "__main__":
    main()

For segwit addresses you can refer to this example: https://github.com/karask/python-bitcoin-utils/blob/master/examples/keys_segwit_addresses.py


Analysing the raw block Hex file but I can not find the expected information

Each transaction is indeed added to the block, but only its contents, the hash is then derived by hashing the transaction data twice with SHA-256.

This image explains how a block is laid out in hex.


If the "wallet seed keywords phrase" is all that's needed to restore a hardware Bitcoin wallet, isn't backing that up a nightmare security-wise?

You're misunderstanding the purpose of a hardware wallet. So first, when you transact Bitcoin without a hardware wallet on a computer, there is a concern that any potential malware on the computer you're using will be able to steal the key (and therefore its associated Bitcoins) because the key has to be stored on the computer.
The point of a hardware wallet is to make it so you can safely transact with Bitcoin on a regular computer without compromising the security of your private key by storing it on your computer. Because the private key never touches your computer, any potential malware wouldn't be able to gain access to your Bitcoin. (So, if you store your seed phrase on your computer, you've entirely defeated the purpose of using a hardware wallet... so if that's what you're doing, I would recommend creating a new wallet and moving the coins over if you still want the security of the hardware wallet.)
If your concern is someone stealing your backed up seed phrase, it is your job to separately protect that seed phrase, whether it's by encrypting it, storing it in a secured location, etc. But these would be done with different tools (an encryption tool, a physical safe, etc.)


How bittrex and other bitcoin trading websites send bitcoin to their one user to another instantly and without any fees?

They are not transferring coins. They are issuing IOUs that are only valid on their platform.

The coins are not transferred until a user makes a withdrawal to their own wallet, which usually does involve a withdrawal fee. Similarly, your initial deposit to the exchange is much slower, and involves a transaction fee, which is paid by you.


David Schwartz's answer is entirely accurate, but all that "bitspeak" might be a little intimidating to the average user.  Let me try and put it into more plain language:

The way Bitcoin works is that instead of having one central authority who secures and controls the money supply (like most governments do for their national currencies), this work is spread out all across the network.  Most of the heavy lifting for Bitcoin is done by "miners".

Miners collect the transactions on the network (like "Alice pays Karim 10 bitcoins" and "Liam pays Sofia 8.3 bitcoins") into large bundles called blocks.  These blocks are strung together into one continuous, authoritative record called the block chain, which doesn't permit any conflicting transactions.  This is necessary because without it people would be able to sign the same bitcoins over to two different recipients, like writing cheques for more money than you have in your account.  The block chain lets you know for sure exactly which transactions count and can be trusted (so no bad cheques!).

The way Bitcoin makes sure there is only one block chain is by making blocks really hard to produce.  So instead of just being able to make blocks at will, miners have to compute a cryptographic hash of the block that meets certain criteria.  Bitcoiners refer to this process as "hashing".  The only way to find a cryptographic hash that's "good enough to count" is to try computing a whole bunch of them until you get lucky and find one that works.  This is the "lottery" that David Schwartz refers to, because miners who successfully create a block are rewarded some bitcoins according to a preset schedule.  The difficulty of the criteria for the hash is continually adjusted based on how frequently blocks are appearing, so more competition equals more work needed to find a block.  Modern dedicated mining hardware (e.g. ASIC miners) can try trillions of hashes per second, so to be competitive in this race to find hashes miners need specialised hardware, otherwise they will tend to spend more on electricity than they make in the "lottery".

In addition to the hash criteria, a block needs to contain only valid, non-conflicting transactions.  So the other main task for miners is to carefully validate all the transactions that go into their blocks, otherwise they won't get any reward for their work!

Because of all this work, when a Bitcoin client signs on to the network it can trust the block chain that was most difficult to produce (since this is evidently the one that was being worked on by the most miners).  If there was a "fake" blockchain competing with the real ones (say, where someone pretends that they didn't actually give Sofia those 8.4 bitcoins and they still have them), the fraudster would have to do as much work as the whole rest of the network to make their block chain look as trustworthy.  So essentially, the intense work that goes into finding blocks through hashing secures the network against fraud.  There is also, of course, some nifty code that figures out how to choose between conflicting transactions; and what to do if two people find valid blocks at the same time.

One last thing:  why is it called mining?  In the original analogy, people who performed this essential work were compared to gold miners digging the gold out of the ground so that everyone could use it.  But in reality, Bitcoin "miners" are just running computer programs on very specialised hardware that automates the process of securing the network.  To sum up, this software

Collects transactions from the network
Validates them, and doesn't allow conflicting ones
Puts them into large bundles called blocks
Computes cryptographic hashes over and over until if finds one "good enough to count"
Then submits the block to the network, adding it to the block chain and earning a reward in return.

That's mining in a nutshell!


Issue with sendrawtransaction missing inputs error code -25

From your listunspent: "vout": 1,

From your createrawtransaction: "vout":2

You are trying to spend an output that doesn't exist.


Hash rate, transaction and block relationship

Miners can choose whatever transactions they wish to include in a block, as long as they are valid, but doing so may require them using custom software. As far as I'm aware, the Bitcoin Core software selects transactions by highest paying fee first.

No. The hash rate is determined by specialized hardware (ASICs) which do not perform transaction validation. The hardware does not help with the validation of transactions because it would take longer to transfer the information to this hardware than to simply perform the hashing on the CPU. The bulk of the time in validating transactions is spent on signature validation anyway, which the ASICs do not do (although it would be possible to build one for this particular purpose).
The mining ASICs are mainly more efficient than mining on the CPU is because they perform the hash algorithm on the same data many times, internally only updating a random number for each hash attempt and recalculating the merkle root.

Miners validate all transactions as they come from the network just like every other network participant. Their bitcoin node will hold incoming transactions in the mempool, and the mining software will request a block template at regular intervals, containing all of the transactions which are to be included in the block. In a mining pool, the pool operator creates the block template and the miners work from that template, and validating themselves it is optional.

This is quite a complex topic because every single aspect of a transaction needs validating, and the entire details are not defined in a document, but by the reference implementation (the satoshi client / bitcoin core).
The key details are that:

All of the inputs to a transaction are checked to be unspent
The sum of the output amounts is less than the sum of the input amounts (with the difference being the transaction fee).
For each transaction input, the scriptSig from that input is pushed onto a stack, then the scriptPubKey from its matching transaction outpoint is evaluated with that stack. The script must evaluate to true for the transaction to be valid. The scriptSig will usually contain a public key and a signature, and the scriptPubKey will usually perform an OP_CHECKSIG, which tests that the SHA-256 of the entire transaction was signed by the private key matching the public key. (This itself is quite nuanced because the transaction must be stripped of the signature before it is signed or validated).

There are many finer details to the validation of transactions, which are mostly answered in existing questions on here, explained on the bitcoin wiki or in the BIPs.


What transactions didn't make it to the Bitcoin blockchain?

How does the protocol know which transactions made it and which didn't?

Once a transaction is mined, all the network knows it's there. No one will keep it in their mem-pool any longer. Only before it's in the canonical chain you don't know who's seen it.


This article was written regarding the alleged theft of 25,000 BTC in July 2011. A similar analysis could be done using known addresses and identities, I would imagine.


How to make a CryptoCurrency (preferably using Scrypt) in depth

You can follow the discussions at How To Clone Scrypt Based Altcoins for Fun and Profit

Direct Link:
How To Clone Scrypt Based Altcoins for Fun and Profit ?


Mining almost any crypto-currency, including Ethereum, with just one GPU is not recommended if you are wanting to actually make profit. This segment of miners are viewed as enthusiast with the goal of just contributing to the security of the network. If you do not have these goals, it is advised to avoid mining at large.

Mining requires large amounts of electricity, GPUS, and multiple rigs (aka mining farms). Most residential home-miners will generate some amounts but will never generate enough to even break even, resulting in a negative ROI (return on investment).


How can I detect which customer has made a payment using only one receiving address?

You said you can't create new addresses on the fly but you also said you're using PHP. It's really easy to do it, just take a look at bitwasp/bitcoin-lib and give out a new address for every purchase. You can also create a functional mapping between a purchase id in your database and a bitcoin address really easily so you don't have to store the address used for each purchase.

Using the least significant digits of a transaction is a really bad idea. Not only because that'll cause a lot of trouble if people don't pay but also because you can't be sure that the wallets of all your customers support sending a very precise amount of BTC. Furthermore you'd have to discourage people from simply rounding up because they're too lazy to type in the exact value (if they have to type that in).


How to remove unconfirmed, non-existent transaction from QT wallet

The command line option is -zapwallettxes

This will clear unconfirmed transactions from your wallet.

See https://en.bitcoin.it/wiki/Running_Bitcoin


Is there really no manual for Bitcoin Core?

There is a manual documenting both examples. The man page for bitcoind.
man bitcoind shows me:
       -blocknotify=<cmd>

              Execute command when the best block changes (%s in cmd is replaced by block hash)
        ....
       -walletnotify=<cmd>

              Execute command when a wallet transaction changes (%s in cmd is replaced by TxID)

They're really not that hard to use.
Note that this machine runs a slightly older version of bitcoind. Newer versions support %w for the name of the wallet, as bitcoind now supports multiple wallets, in addition to %s for the transaction ID.


Recover the bitcoin using my bank account transaction details

Bitcoin has no relation to the banking network - if you're lucky, you might have purchased BTC on a custodial platform (one which keeps the private keys for you) and your bank account's transaction history can help you identify which platform you had sent funds to. You should then be able to contact their support to regain access to your account.

If you moved the BTC to a wallet where you maintain the private keys and have lost access to that, you are out of luck unless you made a backup.

If someone asked you to transfer them fiat through the banking system, promising Bitcoin or high investment returns in exchange, you may have been scammed.


does it mean HD wallets support multi networks?

No.

A Bitcoin wallet can implement BIP-0044 without supporting any cryptocurrency other than Bitcoin.


How does Bitcoin transaction batching work exactly?

Instead of paying multiple people using a new transaction for each person, you make one transaction that pays those multiple people.
For example, suppose you need to pay 3 people. Instead of making 3 different transactions with one output each, you make one transaction with 3 outputs to the 3 people you are paying.

How does this end up looking compared to a regular block of a bunch of transactions?

It is cheaper partially because each transaction has a fixed amount of overhead. By batching transactions, you only have to pay for the overhead once, not multiple times. Furthermore, usually each transaction will have a change output, and many times that change output must be spent again in the next transaction. This means that if you are sending to 3 people, you are creating 3 change outputs, and 2 inputs that have to spend from a change output. By batching, you only need to make one change output and you don't need to have those 2 additional inputs that spend the change. Those effectively cancel out and are thus removed from the transaction.
In a normal case with paying 3 people:
Input 1 -> Person 1
        -> Change 1 -> Spend Change 1 -> Person 2
                                      -> Change 2 -> Spend Change 2 -> Person 3
                                                                    -> Change 3

By batching:
Input 1 -> Person 1
        -> Person 2
        -> Person 3
        -> Change 3

So you have cut out Change 1 and 2, and Spend Change 1 and 2 which means you are paying less transaction fees.

Also, I have read people claim batching causes weaker privacy, how is this exactly?

All of the people being paid in a batched transaction can see who else you are paying and how much. However it is hard for observers to also know the true identities of those people.


Each transaction draws on a set of [1..n] Unspent Transaction Outputs to spend. These we call the inputs of a transaction.
The transaction then assigns the total value of the inputs to [0..n] new Unspent Transaction Outputs. Each UTXO is associated with the creating transaction and uniquely numbered among that set. The most common script that makes up a UTXO is "pay-to-pubkeyhash", where an UTXO can only be spent in combination with a valid signature by it's recipient.

The value of the outputs must be smaller or equal to the value of the inputs. The difference of those two totals can be claimed by the miner as transaction fee.

To come back to your example:

Transaction A1:
Alice -> 5BTC -> Bob (Transaction A1, output 0)
Alice -> 5BTC -> David (Transaction A1, output 1)

(Alice needs to put in at least 10BTC for that transaction.)

Bob wants to spend his money:
Bob -> spend(Transaction A1, output 0, signature) -> new recipient.

Since each UTXO is uniquely identifiable, they cannot both try to access the same UTXO.


How can one realistically model the distribution of the network's unspent transaction outputs?

I haven't read any papers trying to analyze the amount of unspent outputs. More often, people are interested in the distribution of address' balances. This could be interesting because it reflects how evenly distributed bitcoin is.

I did find this article: http://www.coindesk.com/what-block-chain-analysis-tells-bitcoin/, which seems like it might be of interest to you and is related to the distribution of UTXOs.

If you call gettxoutsetinfo with the Bitcoin Core RPC calls, it tells some basic info about the UTXO set. I just did this and got:

{
    "height" : 338396,
    "bestblock" : "000000000000000009f32437cb28d54ff600ec020778c8ce84ecf93b99d5218c",
    "transactions" : 4525842,
    "txouts" : 16217914,
    "bytes_serialized" : 566046691,
    "hash_serialized" : "1ad2172e4d37ce21291c116580f5b527e4c302b9c2ce4e88a91c0c00f748fb8d",
    "total_amount" : 13709764.78496462
}

So it seems that the average amount of an UTXO is:

  13709764.78496462 / 16217914 = 0.84534699

To analyze the amount of outputs (note, this is not only UTXOs), I wrote up this quick script:

<?php

require_once 'jsonRPCClient.php';

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

$info = $bitcoin->getinfo();

$height = $info['blocks'];
$numTrials = 1000;
$includeCoinbase = false;

$cutoffs = array();

for ($i = 0; $i < 10; $i++) { $cutoffs[] = $i; }
for ($i = 1; $i < 10; $i++) { $cutoffs[] = 10*$i; }
for ($i = 1; $i < 10; $i++) { $cutoffs[] = 100*$i; }
for ($i = 1; $i < 10; $i++) { $cutoffs[] = 1000*$i; }

function GetRange($value)
{
    global $cutoffs;
    for ($i = 0; $i < count($cutoffs)-1; $i++)
    {
        if ($cutoffs[$i] <= $value && $value < $cutoffs[$i+1])
            return $cutoffs[$i] . " - " . $cutoffs[$i+1];
    }
    return $cutoffs[count($cutoffs)-1] . " - ...";
}

$sum = 0;
$distribution = array();

for ($i = 0; $i < $numTrials; $i++)
{

    $blockhash = $bitcoin->getblockhash(rand(1, $height));
    $block = $bitcoin->getblock($blockhash);

    $randTxIndex = rand(0, count($block['tx'])-1);

    if ($randTxIndex == 0 && !$includeCoinbase) {
        $i--;
        continue;
    }

    $randTxHash = $block['tx'][$randTxIndex];

    $randTx = $bitcoin->getrawtransaction($randTxHash, 1);

    $numOutputs = count($randTx['vout']);
    $randOutput = $randTx['vout'][rand(0, $numOutputs-1)];

    $value = $randOutput['value'];

    $sum += $value;
    $distribution[GetRange($value)] += 1;
}

echo (json_encode($distribution, JSON_PRETTY_PRINT) . "\n");
echo "average: " . ($sum / $numTrials) . "\n";

And the results are (after being cleaned up a little):

average: 89.55518291596

START   END     COUNT
0       1       636
1       2       73
2       3       18
3       4       20
4       5       14
5       6       11
6       7       8
7       8       8
8       9       11
9       10      12
10      20      36
20      30      26
30      40      15
40      50      16
50      60      29
60      70      5
70      80      5
80      90      4
90      100     3
100     200     29
200     300     4
300     400     4
400     500     1
500     600     1
600     700     1
700     800     1
800     900     3
900     1000    0
1000    2000    2
2000    3000    1
3000    4000    0
4000    5000    0
5000    6000    1
6000    7000    0
7000    8000    0
8000    9000    0
9000    ...     2

Which, when plotted, gives:

And since the 0-1 outputs make the rest go out of scale, this is a plot without the smallest outputs:


Bitcoin address does not show transaction/balance from Coinbase purchase

The coins you purchase are stored in an address owned by Coinbase.  This allows them to buy and sell coins using their hot wallet as well as allowing them to move excess coins to cold storage.  It also allows them to process send requests between Coinbase users using off-blockchain transactions.

The coins won't show up in an address owned by you until you send the coins to a non-Coinbase address.  When you do send the coins, two transactions will be generated by Coinbase.  The first transaction moves the coins from an address controlled by Coinbase to a new address controlled by you.  The second transaction then moves the coins from this address to the address you specified in the send request.

You can send coins to any of the addresses shown in your Coinbase wallet.  Or you can generate a new address at any time to receive deposits.

Since Coinbase keeps just a percentage of the coins in their hot wallet, this can lead to a delay in sending coins if they need to move coins from cold storage back to their hot wallet.


What is anonymous and safe api to get bitcoin Exchange Rates?

Any internet service, including an API, will be able to see the IP address the request originated from. It is reasonable to assume that at least in form of some log file, such information gets records by the API provider.

You have already indicated that you use TOR, which should, at least ideally, hide your real IP from the API service by effectively substituting the IP of the TOR exit node you happen to be using. If that achieves your goal depends on your motivation for hiding it in the first place. Note that TOR is not designed for, and likely not capable of, hiding your real IP from someone doing pervasive internet-wide wire sniffing (NSA, maybe?). Such an adversary would be able to simultaneously observe all traffic at all TOR nodes and correlate incoming and outgoing network activity of TOR nodes to potentially determine what your real IP address is.

You didn't specify why you want to hide your IP from whom exactly, and I'm having one of my unimaginative moments where I cannot come up with a likely scenario why it may be important for you to hide the fact that your computer was involved in looking up publicly accessible information where widespread interest for a whole variety of reasons exists anyways. Hence, I can't judge if for your application, this is sufficiently anonymous and safe (as you asked).

All bitcoin exchanges maintain their own public API for their exchange rate and usually lots of other data, even full order books. If you are happy with delayed third-party data, you can indeed also look at e.g. blockchain.info or bitcoincharts.com.


Who wins the race for multiple valid blocks mined at the same time?

When there's a fork, part of the network will mine to find the next block in one branch and part in the other branch. Whichever part finds the next block first will determine the winning branch.

A miner who finds a block will want to spread it widely and quickly. This makes sure there are many other miners who saw his block first, and thus a high probability that the next block will be found by one of those.


Go to Bitcoin's Application Data directory (in Windows 7 it's UserFolder\AppData\Roaming\Bitcoin) and delete the wallet.dat file.


To answer your question, yes, setting minconf to 1 will display the balance of your wallet that is summed up by combining the transactions in your wallet that have a minimum of 1 network confirmation.

Your secondary question is really a question between balancing the security of your transactions and the speed at which you wish to spend your funds, because waiting, say, 2 network confirmations will be faster (~20 minutes), but will not be confirmed long enough on the block chain for the transaction to be "secure".

This is essentially a form of the "50 percent attack":

An attacker that controls more than 50% of the network's computing power can, for the time that he is in control, exclude and modify the ordering of transactions. This allows him to:

Reverse transactions that he sends while he's in control. This has the potential to double-spend transactions that previously had already been seen in the block chain.
Prevent some or all transactions from gaining any confirmations
Prevent some or all other miners from mining any valid blocks

The attacker can't:

Reverse other people's transactions
Prevent transactions from being sent at all (they'll show as 0/unconfirmed)
Change the number of coins generated per block
Create coins out of thin air
Send coins that never belonged to him

With less than 50%, the same kind of attacks are possible, but with less than 100% rate of success. For example, someone with only 40% of the network computing power can overcome a 6-deep confirmed transaction with a 50% success rate.

It's much more difficult to change historical blocks, and it becomes exponentially more difficult the further back you go. As above, changing historical blocks only allows you to exclude and change the ordering of transactions. It's impossible to change blocks created before the last checkpoint.

Since this attack doesn't permit all that much power over the network, it is expected that no one will attempt it. A profit-seeking person will always gain more by just following the rules, and even someone trying to destroy the system will probably find other attacks more attractive. However, if this attack is successfully executed, it will be difficult or impossible to "untangle" the mess created -- any changes the attacker makes might become permanent.

The above was taken from https://en.bitcoin.it/wiki/Weaknesses

Hope this helps


Is it possible to copy BTC balances of only some addresses while forking

This is possible, but will require a change to your fork's consensus rules to see the block that alters address balances as valid.

Essentially, you need to drop the utxos of addresses you don't want to have a balance on your new fork at the fork block, and leave the ones you want with a balance alone. This is of course an invalid block for regular Bitcoin clients, since utxos cannot arbitrarily disappear. You can get around this by assuming that the fork block hash is valid explicitly in your fork's code.


How to create block height to UNIX time converter?

In theory there is one block per 10 minutes. That means you should be able to approximate the time of a block n as FIRST_BLOCK_TIME + n*600, where FIRST_BLOCK_TIME is the time of the genesis block, 1231006505.

Of course, that's very approximate, as the average time per block has been consistently less than ten minutes due to increasing block difficulty. In fact, as of writing (block 622719 with timestamp 1585016395), is 19621510 seconds earlier (over 7 months) than what would be predicted by that formula.

  One method, I am considering is to iterate through the blockchain and generate a database that stores the block height and the UNIX timestamp associated in the block header of the block. Would this be a proper solution to the problem?

Using the real data is obviously going to be better than any approximating formula. Note that the timestamp of blocks are not necessary the actual time they are mined (in normal circumstances they can be up to 2 hours in the future, and up to approximately 1 hour in the past).


Transfer from exchange to my Electrum cold wallet

The assumption stated at the end of your question is correct:

You can send bitcoin to the address that is presented by Electrum's Receive tab and the funds will be sent to that address - accessible (spendable) from the cold wallet.

Electrum's Receive tab seems to choose a random address from your wallet's address pool. If you want to use a specific address, or a new address for every funds deposit, then go to the Addresses tab, right-click on a specific address and choose Request Payment from the drop-down menu.

Note: the xpub (extended) public key format is used by BIP32 deterministic wallets (such as Electrum seed wallets) to recreate all of the addresses associated with your xprv (master) private key. This master private key is stored in your cold wallet but not in the watch-only wallet that used the xpub key (at watch-wallet creation time) to generate the addresses it will watch.

By using the xpub key associated with the xprv key, your watch-only wallet contains all of the same addresses that were generated when you created the cold wallet. Anytime you manually generate a new address in the cold wallet you will have to manually import it into the watch-only wallet.

Never reveal your xpub key to anyone as they will be able to recreate all of your addresses and your privacy will be compromised.


Can a customized or non-bitcoin node be made to talk to a bitcoin node?

Of course.
Bitcoin nodes are just software that implements the Bitcoin P2P protocol. There are many software packages out there that do so (including full nodes, standalone wallets, indexing software, ...). There is no magic sauce that somehow blesses a particular piece of software into the realm of nodes - anything that speaks the protocol will do.
Furthermore, most of these (and probably all the ones you should care about) are open source, so making modifications to add functionality yourself is very much possible.


message signing: is it safe to publish the address, message and hash

It shouldn't compromise the private key. Notice that publishing a message along with a signature is a common thing, and is necessary to verify the signature. Publishing also de Bitcoin address is similar to give the public key, since the former can be derived from the latter (actually, once you redeem your first transaction by signing it, you will provide the public key in the blockchain).

However, since you what to reuse the same key for signing multiple messages, there is something you should have in mind. There exist a well-known ECDSA vulnerability that affects the signing process, and by which if two different messages are signed using the same private random value k, anyone who knows the two original messages and the signature can derive the private key used to sign the messages. This is not likely to happen, since k should be chosen at random and from a good source of randomness, however some buggie implementations of the signature had lead to private key disclosure.

In order to ensure that this won't happen, you should use a deterministic ECDSA signature, in which k is chosen deterministically over the message to sign. Several wallets, like the Bitcoin Core, implement such a mechanism by default.


How come some addresses show up in search results while others don't?

The latter address does not show up in google because it has not been used for a transaction yet. Once someone sends money to it, it will show up.

It's possible that we'll be able to create systems in the future that don't have this problem, but don't hold your breath.


Think about it this way: Bitcoins can get stolen by people with poor private key control being "hacked". But when those people have their Bitcoins stolen, what do they do? They complain about it online, and so other people hear about it.

Then those people who hear about it say to themselves: "well my private key control is pretty bad too, I can easily get hacked!" Then some of them will at least learn to protect themselves, maybe by using a hardware wallet such as Trezor or Ledger.

Those that don't improve their practices will either eventually have their funds stolen, or they will see more examples and their behavior will self-correct.

Also if there was a sudden increase in thefts there would be a LOT of media coverage about it, and even more people would learn about how to protect themselves through these good private key practices.

Because of this, the amount of Bitcoin that is stolen annually will tend towards some small percentage. Of course, if Bitcoin did look like it was going to be the global currency you can imagine that the already-rich-capitalists would just buy a whole lot of Bitcoin, so it wouldn't make that much of a difference to their lives and position.


Does ad hoc adoption of private blockchains make the financial system vulnerable to tampering?

this has the risk of getting a philosophical debate... Generally, the bitcoin blockchain was invented, to avoid, that malicious participants have no impact on the overall distribution of messages in the public network (aka tx with Satoshis in blocks). Along with some privacy features. So when someone creates a private blockchain, we are down to the level of trust. You can use a 1:1 copy of the bitcoin network, and don't go public. Then you compare the code to the executables, and can be sure, noone wants to tamper with it. But as it is private, you never know, how many "good" and how many "bad" nodes were invited to participate. There are use cases for private blockchains, when it comes to tx handling between several companies, which should be tamper proof. Question is, if the bitcoin blockchin is the right tool for this. In general I support your point of view, that private blockchains are less secure than a big public network. Trust is then based on the fact, that this company will not go bankrupt (or controlled by governments), and the privacy question remains unanswered, of course.


BitCoinJ is a Simplified Payment Verification (SPV) client library

This means that it only downloads the headers for transactions, and only those that are relevant to the private keys contained in its wallet only. This greatly reduces the blockchain download (very quick to get started), but at the cost of not seeing all the other transactions (reduced overall network security).

So, in short, you can't download an arbitrary transaction through BitCoinJ.

However, to answer your requirement have you considered just using the Blockchain.info API?


Transfer money from crypto account to normal bank account

You cannot transfer money from crypto to banks directly. You would have to sell the crypto currencies on a special marketplace for cryptos, after that you can get them paid out to your bank account. But you will have varying exchange rates depending on which amount you will sell and what the actual market price is at the time you sell it. Plus additional transaction costs.


Why explorers show difference balance for genesis block?

In order to explain this, you'll need to understand that on a technical level, a bitcoin does not exist as a 'balance at some address', instead the system uses 'unspent transaction outputs' (UTXOs). See this question for more info.

The reason it is especially relevant to understand this, is that due to an apparent bug in the bitcoin codebase, there is no UTXO for the genesis block reward, which means the genesis block reward is un-spendable.

So with that in mind, we can look at each of the examples you listed.

  66.92700504 BTC

  https://bitref.com/1A1zP1eP5QGefi2DMPTfTL5SLmv7DivfNa >https://www.blockchain.com/btc/address/1A1zP1eP5QGefi2DMPTfTL5SLmv7DivfNa

These block explorers are listing the balance of the address that the genesis block coinbase transaction pays out to, and including the 50 BTC block reward in their report.

  16.91700504 BTC

  https://insight.bitpay.com/address/1A1zP1eP5QGefi2DMPTfTL5SLmv7DivfNa >https://blockstream.info/address/1A1zP1eP5QGefi2DMPTfTL5SLmv7DivfNa

These block explorers are apparently only listing UTXOs that exist and are spendable. The block reward is not spendable, so it has not been included in the sum.

66.92700504 BTC - 50 BTC = 16.91700504 BTC

  and many others who don't sum two transactions:

  for 50 BTC >https://www.blockchain.com/btc/tx/4a5e1e4baab89f3a32518a88c31bc87f618f76673e2cc77ab2127b7afdeda33b?show_adv=true

  and 0.1 BTC >https://www.blockchain.com/btc/tx/3387418aaddb4927209c5032f515aa442a6587d6e54677f08a03b8fa7789e688

These two URLs link to specific transactions, not to the address itself. The first is the coinbase transaction (though as mentioned above, there is no valid UTXO for this), and the second is a transaction creating a 0.1 BTC UTXO that is spendable by the owner of the 1A1zP1eP... private key.


Claim Bitcoin cash from android bitcoin app

The Bitcoin Wallet project recently included detailed instructions on how to extract your key pairs for exactly this purpose. In the section Recovering from protobuf wallet format, skip to the paragraph beginning with

  You can also get a list of the private keys...

(Here is a historic version of that guide*, should it ever disappear)

I have now completed the process myself. Here's a summary. Note this works for backups made after 2014 (newer protobuf format). See the article above if your backup is older than this.

# pre-reqs
sudo apt install openjdk-8-jdk openjfx android-tools-adb openssl git maven

# use known version of bitcoinj - HEAD of branch release-0.14 at time of writing
git clone https://github.com/bitcoinj/bitcoinj.git
(cd bitcoinj && git reset --hard 0e30a3011c42cedfd83f2109d54dd192730dcc45)

# decrypt the wallet backup (substitute for <BACKUP>)
openssl enc -d -aes-256-cbc -md md5 -a -in <BACKUP> > /tmp/dec

# reset & sync wallet (may take some time, but was necessary in my case)
(cd bitcoinj/tools && \
   ./wallet-tool reset --wallet=/tmp/dec && \
   ./wallet-tool sync --wallet=/tmp/dec --debuglog)

# dump keys You will need to add `--password=<PIN>` if your wallet is pin protected.
(cd bitcoinj/tools && ./wallet-tool dump --wallet=/tmp/dec --dump-privkeys)

# delete your decrypted wallet
rm /tmp/dec


Can I independently verify the integrity of the network with only block headers?

Reclaiming disk space describes what is nowadays called pruning. After downloading the entire block chain, you can safely throw most of it away because old spent transaction outputs are never needed again. This is not yet fully supported in Bitcoin Core, but it probably will be possible in the next major release.

From the paper (my emphasis):

  Once the latest transaction in a coin is buried under enough blocks, the spent transactions before it can be discarded to save disk space

You're talking about simplified payment verification (SPV), the next section in the paper. With SPV, you use just headers and Merkle trees to verify that a transaction has a certain number of confirmations. A transaction with a high number of confirmations is probably safe, but you can't be 100% sure without downloading and verifying the entire block chain. SPV clients trust that the majority of miners are honest, which full nodes do not need to do in most cases. Today, SPV is used by many lightweight clients such as MultiBit and Bitcoin Wallet for Android.


Proof for "Is an immutable, decentralized blockchain possible without economical incentives?"

Bitcoin is immutable because of economical incentives.

Behind every full-node and miner is a human operator making a decision or choice to carry the cost of running such an operation.

Security from decentralisation can only exist if users wish to use and validate Bitcoin, because it cannot be easily censored as centralised systems. Security (Immutability) from confirmation (PoW) can only exist, if it is paid for (by fees).

Individuals will make choices which improve their situation. The system can only work if it supports this and is reflected in the incentives for all participants.

  Those who are able to 51% the network can't do it, because it'll
  result in the value of the currency to drop tremendously, which causes
  waste of a lot of money as there's a 100-block limit to spend coinbase
  transactions.

There is no clear incentives that prevent a 51% miner from double-spending or censorship. A double-spend may reduce the value of Bitcoin, but whether it is profitable for the miner (in let's say USD terms) will also depend on the double-spent amount. A 51% selfish miner who censors blocks, may benefit financially from doing so by diverting Bitcoin transactions to another domain which can be taxed by the miner.

However, user's can offer higher fees if their transactions are being censored, thus incentivising new mining hash rate to join the network and dilute the previous 51% miner.

  Those who aren't miners having large capital to attack the network
  can't turn on a considerable amount of miners at once as it's not a
  PoS coin.

Capital can always be reallocated to mining, but they need an incentive to do so. If users pay higher fees, this can incentivise new hash-power to come online, and dilute the former 51% miner. Users will only pay higher fee's if their transactions are not being confirmed (being censored by 51% miner).


Bitcoin and Litecoin wallets with push notification API?

You can run bitcoind/litecoind with the -walletnotify flag, which runs a script when a transaction is received.  The script could then send a notification.

./bitcoind -walletnotify=<your script name> %s

The %s is replaced with the hash of the incoming transaction.


How can one Bitcoin address be associated with mulitple IP addresses?

A bitcoin address is not based on or tied to a network address, they are completely different.

Think of the Bitcoin address as a bank account number and the IP as a telephone caller ID. When you call your bank from different phones they'll see different caller IDs but you'll give them the same account number each time. They can write down the caller ID if they're spying on you, but that doesn't have anything to do with the account number other than the fact that you yourself are using both.

Likewise an observer can watch you sending transactions to the network from your IP address, and if you use the same Bitcoin address more than once they can see your sending IP address each time (unelss you use Tor...). But that doesn't have anything to do with the Bitcoin address other than the fact that you yourself are using both.


I am not familiar with digibyte's wallet implementation specifically, but I can probably shed some general light:

Your passphrase is not stored in the wallet.dat - the passphrase is the encryption key that can be used to decrypt the wallet.dat. The wallet.dat itself stores private keys that can be used to sign transactions with the associated addresses.

When you run JTR or hashcat on the wallet.dat, you are brute forcing the passphrase itself to gain access to the private keys inside the wallet (trying to find a passphrase that when used as a decryption key is successfully able to decrypt the wallet)

Briefly looking at the digibyte core wallet, the wallet.dat appears to be in a standard format just like for any other wallet based on Bitcoin Core. You should start here if you want to know more about what information is stored inside the wallet.dat and how (look under Bitcoin Core): https://en.bitcoin.it/wiki/Wallet

If Bitcoin2John and hashcat don't work on the wallet.dat, this is probably due to minor differences in storage, but it should be fundamentally the same.


The first number is the number of shares you have solved.

The second number is the number of pieces of work that you have recieved, but haven't begun solving. If it drops to 0, you aren't mining. Every ten minutes or so, these will become obselete, and you'll need new work, so there's not much point in requesting a bunch ahead of time.


In the original source code there were little restrictions on what could be in the coinbase data of the coinbase transaction. I think the only restriction was that the coinbase data should be between 2 to 100 bytes. However, this lack of restriction on what can be within the coinbase data brought up a vulnerability. It was perfectly legal for miners to create a coinbase transaction identical to previous one and mine it in a block at a height higher than where the "original" coinbase transaction. When this happened it led to the invalidation of the previous transaction.

This was fixed later when couple of blocks were mined with identical coinbase data. As per BIP-34, version-2 blocks must contain the block height index as a script push operation in the beginning of the coinbase field. For example, in your coinbase transaction this data is represented by the bytes 0x03400d03. The first byte 0x03 indicates the script should push the next 3 bytes. The next three bytes 0x400d03 represent the block height 200,000 in little endian.

The rest of the coinbase data is free for the miners to use as per their will. This is mostly used as a space for extra-nonce. In the early days of Bitcoin, a miner could find a block by iterating through the nonce until the resulting hash was below the target. As difficulty increased, miners often cycled through all 4 billion values of the nonce (232) without finding a valid block header hash. However, this was easily resolved by updating the block timestamp to account for the elapsed time. Because the timestamp is part of the header, the change would allow miners to iterate through the values of the nonce again with different results.

Once mining hardware became really efficient, however, this approach became increasingly difficult because the nonce values were exhausted in less than a second. Hence, the mining software needed more space for nonce values in order to find valid blocks. The timestamp could be stretched a bit, but moving it too far into the future would cause the block to become invalid. The solution was to use the coinbase transaction as a source of extra nonce values. Because the coinbase script can store between 2 and 100 bytes of data (~first 4 bytes reserved for block identification), miners started using that 96 byte space as extra nonce, allowing them to explore a much larger range of block header values to find valid blocks.

The mining pools also use the coinbase data as an identification of who mined the block. For example if you look at block 594,041, you will see the coinbase data contain the bytes 0x4d696e656420627920416e74506f6f6c. It represents "'Mined by AntPool" in ASCII. (Unfortunately the block you mentioned did not have any identification hence I had to use a different block that did have it). However, it is important to note that this data cannot be relied upon, as any miner can mine a block tomorrow with a data claiming it to be mined by a different pool, may be to hide its identity or frame others.


I read that Bitcoin addresses are single-use tokens. Is it my responsibility to generate new ones in Electrum?

Generally you do not need to manage your addresses yourself. Your wallet software will handle that for you and generate new addresses for you when you want to receive Bitcoin. In Electrum, just use the receive tab and get addresses from there. As you use addresses, you should see that the address in the "receiving address" box should change.


Can I download the whole block chain from somewhere?

Note by Murch: This download link is broken and it seems unlikely to me that anyone still provides this service. Network and synchronization code have been immensely improved over the years so that the initial block download via the network is usually acceptably fast.

You can download the blockchain nightlies handled by tcatm (one of the Bitcoin core developers and the operator of bitcoincharts.com). Unpack and copy&replace blkindex.dat, blk0001.dat files into C:\Users\"username"\AppData\Roaming\Bitcoin for Windows 7, and run bitcoind with the -rescan option. Then it will take only a couple minutes to download up to latest block. Be aware that manually copied blocks won't get verified.


Debug.log : How do I analyze an orphaned transaction?

An orphan transaction is a transaction that consumes a coin whose creating transaction is not known to your client. This has nothing to do with orphan blocks (which are blocks whose parent block is not known, or according to another definition, blocks that are no longer part of the best chain).

Orphan transactions are not part of a block (they cannot be verified until their parents are known, and only valid transactions are allowed in blocks), and are kept in memory in the client. When their parents become known, and they are found valid, they are moved to the memory pool (which is - as the name suggests - also kept in memory only). From there, they are considered to be included in new blocks (if you're mining).

This piece of debug.log tells you that there are 3 transactions received (separate transactions, not part of a block) that reference some inputs that aren't known. Because of this, they are stored in the orphan pool, which grows as a result of that. "mapsz" stands for "map size" (as the orphans are stored in a map) - the number is just the number of remembered orphans.


New Bitcoin-Qt install but can't set passphrase

Don't use that version. The client has hard forked since then, meaning that client is no longer viable for user on the network. On Linux I recommend you download source and compile the current version 0.8.6 at this time.


I recently recovered an old wallet.dat file using pywalley.py and Electrum, which allowed me to read the wallet and sweep the coins to a new Electrum wallet.
Steps:

Get the jackjack pywallet https://github.com/jackjack-jj/pywallet
Put the wallet.dat in that directory
./pywallet.py --dumpwallet  --datadir=. --passphrase=PASSPHRASE

Passphrase is optional, only if the wallet is encrypted.
If that works, then run it again with the --dumpwithbalance option, that is
./pywallet.py --dumpwallet --dumpwithbalance --datadir=. --passphrase=PASSPHRASE
Ideally, redirect it to a file. Then, search the file for nonzero balances.
You can use http://BitRef.com to make sure that the addresses with balances still have balances.
In the JSON dump of the wallet.dat file, you will find the private key, in the field labeled "sec." Don't share that with with anyone. That key will allow anyone to sweep your bitcoins into their wallet.
Using that key, you can install the Electrum wallet and sweep the coins into a new wallet without downloading the blockchain. You will pay a fee of 0.2-0.5 mBTC to do it slowly, more if you are in a hurry.
There are good instructions at https://en.bitcoin.it/wiki/Transferring_coins_from_Bitcoin-Qt_to_Electrum which include a link to a more paranoid process using an offline computer to avoid accidental exposure of your private key.
There is a default fee of 0.5 mBTC, you can adjust it in Tools-->Preferences.
The address in the "Sweep" dialog box is just the new wallet address being swept to.
You can watch the transaction progress at http://bitref.com or http://blockchain.info.
Once in the new wallet, you can send to an exchange like CoinBase to cash out, or just spend the Bitcoin. The Electrum wallet costs more in fees but saves you the pain of downloading and managing the whole blockchain.
EDIT #1: The sad news is that as of January 2018 the transaction fees are hovering around USD $40, so recovering a small wallet will probably consume all of its value. I managed to sign a low fee transaction from my old wallet, but it has been stuck in the mempool for weeks, now. It may be there forever.
EDIT #2: After 26 days in the mempool, my low fee bitcoin transaction finally got confirmed.


Imagine if that weren't there. What if someone tricked you into signing a Bitcoin transaction with your key? They could put the signature they got from you along with your public key into the input script for the transaction, and broadcast that transaction to the network. (Unless something else I'm not aware of would prevent that.)

Granted, it would be somewhat difficult to trick someone into doing that (Bitcoin transactions include null chars, and I don't think you can copy-paste those) but why take the risk at all?


Balance in bitcoin-qt suddenly significantly diminished after a small transaction?

The balance that you see is the confirmed balance. This is the sum of the unspent transaction outputs controlled by your wallet that are in transactions that have been confirmed. The confirmed balance can temporarily decrease more than the amount that you actually want to send due to change outputs. However once the transactions confirm, it should be what you expect it to be.
When you make a Bitcoin transaction, it has to spend transaction outputs that were created previously. Because an output can only be spent in full, the transactions that your wallet makes typically create another output called a change output. This is a transaction output that your wallet can spend; it is sending the change back to itself.
When this happens, because the change output is a new output in an unconfirmed transaction, the value in that change output no longer counts towards the confirmed balance. It counts as part of the unconfirmed balance which is shown in the GUI as the Pending Balance. Once the transaction confirms, it will be counted as the confirmed balance.


What are the advantages/disadvantages of a continuously decreasing block reward compared to the current method?

The main advantage of the staircase rewards is simplicity. It's easier to implement; easier to describe; easier to plan with.

The main disadvantage is that it is less mathematically elegant. It will not be very disruptive in practice because it is known in advance and can be planned for.

The early adopter advantage is not a consideration, as it can trivially be controlled with the timescale parameter.


How to distinguish between change and actual sent amount looking at transaction data

There is no way to know with certainty which output is the actual spend, and which is the change, without being involved in the transaction yourself. It is possible to infer this though, consider the following:

Transaction 'X' has 2 inputs (0.5, 0.5), and 2 outputs (0.7, 0.3). Logically, we can infer that the larger output (0.7) is the spend, because if the spend was the 0.3 output, the user could have saved costs by just using one of the 0.5 inputs to send the transaction.

However, it is possible for users to purposefully transact in a less efficient way, in order to obfuscate their spending habits, so you can never be absolutely certain.


Why search for a nonce linearly (+1) vs searching only even or odd nonces?

A 2X rate with a 50% chance of missing a winning nonce is no advantage at all. Incrementing the nonce is the easiest mechanism of choosing the next nonce to try, so you try the most nonces per second that way. That's all that matters.

Perhaps you are under the mistaken impression that everyone is trying to mine the same block. That is not so. If you are a solo miner, you are the only one trying to mine a block that pays you the block reward. Nobody else is trying to mine the same block you are, so all that matters is how many tries you are able to accomplish. You aren't racing anyone else. If someone else finds a block, you don't care if they found it before you did or after you did (except in very rare instances where you both find a block at very close to the same time), you found a block either way.


Is it possible to have a shared access bitcoin wallet?

you could use multisig wallet, e.g. Copay - a secure bitcoin wallet platform for both desktop and mobile devices.

Check out miltisig use cases:

m = signatures required to spend
n = signatures possible

m=1 and n>1
Shared Wallet

Could be used for small group funds that do not require much security. Least secure multi-sig option because it is not multi-factor. Any compromised individual would compromise the entire group. Group funds for a weekend or evening event might be a good use case. A shared wallet might also be fun for some kind of games too. Besides being convenient to spend from the only benefit of this setup is that all but one of the backup/password pairs could be lost and all of the funds would be recoverable.

m=n
Partner Wallet

Scary because no keys can be lost. As the number of signatures required increases the risk also increases. Could be thought of as hard multi-factor authentication.

m<.5*n
Buddy Account

Could be used for spending from corporate group funds. Consequence for the colluding minority need to be greater than possible benefits. Is less convenient than a Shared Wallet, but much more secure.

m>.5*n
Consensus Account

The Classic Multi-Sig Wallet is a 2 of 3 and is a special case of a Consensus Account. I think 2 of 3 is the sweet spot for multi-sig. It has the best characteristics for creating new bitcoin address and for securely storing and spending BTC. One compromised machine does not compromise the funds. A password can be lost and the funds can still be recovered. If done correctly, off-site backups are created during wallet setup. The way to recover funds is known by more than one party.

The balance of power created with a multi-sig wallet can be shifted by having one party control more keys than the other parties. If one person alone controls enough keys to use the wallet then it could be considered a Boss Account. When one party controls multiple keys there is a greater risk of those keys not remaining as multiple factors. A Boss Account also introduces a single point of failure, if the boss disappears, funds may not be recoverable.

m=.5*n
Split Account

An interesting use case would be a 3 of 6 where one person holds 3 keys and 3 people each hold 1 key. In this way one person could control their own money, but the funds could still be recoverable even if the primary key holder were to disappear with all of his keys. As n increases, the level of trust in the secondary parties can decrease. A good use case might be a family savings account that would just automatically become an inheritance account if the primary account holder were to die.


Is it possible that someone forks the chain?

The rule is that the longest* valid chain is considered the active one. If you build a forking branch with invalid transactions in it, the network (in particular, all full nodes - including miners) will simply ignore it. If it's invalid, it does not exist. Blocks are not relayed to peers before validating them entirely.

You may be able to temporarily fool lightweight clients that don't do full validation, but to build a chain with sufficient length to "confirm" these invalid transactions requires sustained high hashrate, assumed to be impossible without significant (close to or above 50%) mining power.

longest* = it's actually the branch with the highest estimated total number of hashes that is considered the active one (as a tie breaker), not the longest one. This only very occasionally makes a difference (in particular, when the fork crosses a retarget).


I sent Bitcoin to a Bitcoin Cash eWallet by mistake, what can I do?

Do you hold private keys of that Bitcoin Cash eWallet?
If yes, you need to import private key of that Bitcoin Cash address into any Bitcoin wallet and you will be able to get your bitcoins back.


as a individual miner's side, how UASF, UAHF agree or disagree is occurred?

does miner program contains 'yes' or 'no' about this decision?

No. Forks are not votes, especially user activated forks. A user activated fork occurs with no requirements on miners. There is no signaling of readiness from miners nor do miners have any say on when it activates. All miners can do is decide whether they want to mine the fork and enforce its rules after the fork occurs.

  Who is the representative in the working blockchain that inform 'this feature will be added!'? How is the notification received by all nodes?

There is no representative (that would imply there is some central authority in charge of the blockchain and there is not) nor is there any sort of notification system.

A user activated fork happens when a group of users decide they want some consensus change to occur. They write software that implements this change along with the activation time. Those users will then try to get other users to join them. When their fork activates, they will start enforcing their new rules.


Are Hashed Timelock Contracts and Zero-Knowledge Contingent Payments the same thing?

Not really. Both use OP_CLTV, in order to recover from a situation where one side refuses to participate in the protocol, but other than that, they're pretty different.

ZKCP has a zero knowledge proof communicated outside of the blockchain. On the other hand, HTLC passes signed transactions back and forth to update a channel.


How can i switch from BIP32 to BIP44 using bitcoinj

Checkout bitcoinj master branch

Discussion https://github.com/bitcoinj/bitcoinj/pull/1341

    Wallet walletBip39 = Wallet.fromSeed(params, seed);
    System.out.println(walletBip39);

    Wallet walletBip44 = Wallet.fromSeed(params, seed, Script.ScriptType.P2PKH, ImmutableList.of(new ChildNumber(44, true), new ChildNumber(0, true), ChildNumber.ZERO_HARDENED, ChildNumber.ZERO));
    System.out.println(walletBip44);


How Do I Stop My Voltage Converter From Overloading?

Does anyone have suggestions on what I can do to get my miners running?

US split-phase homes are likely to already have a 220V outlet somewhere for high-powered appliances (laundry washers, etc). You need to be sure the miner's PSU is designed for split-phase and not single-phase because the earthing/ground arrangements differ.

An electrician can create a new 220V circuit and run new wires through your walls to 220V outlets in a suitable location.

A higher powered converter (say 5000 W) might work if you have a very high current outlet that can deliver an amount of power greater than the power rating of your miner plus the power losses inherent in any converter. For example an Antminer S19 needs 3250W, if we add 25% (a random guess) for power losses in the converter that means your supply needs to provide 3250 * 1.25 / 110 = 37 amps. Most outlets in US homes will be 15 or 20 amp outlets but you might have a 30 amp outlet for a clothes dryer or electric stove. There is a 50 amp NEMA outlet but I imagine it would be rare. This might be what you'd need for an S19 but I have no experience of that. Again a professional electrician can solve this for you.

Surely there must be other people in the Western hemisphere that have gotten these to work at home

In my part of the Western hemisphere all home power outlets are 230V and can at least power a 3.1kW - 3.4Kw appliance. 7-10kw appliances are common but are usually hardwired (non pluggable) by an electrician. Your problem doesn't exist here to the same extent.

As you have discovered, Mining bitcoin is really a light-industrial enterprise for which most US homes are unsuited. Many US homeowners would need to contact their electric supply company and get a higher power supply to their home. They also need to pay an electrician to do something like wire up a new high-powered circuit from the main panel to a subsidiary panel at the appliance location. Similar to running a hobby machine shop in the garage with an assortment of second hand industrial lathes and milling machines, welders, plasma-cutters etc.


Outgoing child chain transactions require a fee denominated in the child chain token. Unlike when using NXT, 0 is a valid fee for sponsored child chain transactions.

For normal transactions, let the server calculate the child transaction fee, a value of feeNQT=-1 should be used, and a new feeRateNQTPerFXT parameter must be supplied, to indicate the exchange rate of child token NQT per whole ARDR to use when calculating the fee (since minimum fees can only be calculated in the parent chain token ARDR).

If feeRateNQTPerFXT is also set to -1, the server will query the currently known bundlers rates for this child chain, also subject to the minBundlerBalanceFXT limit on effective bundler account balance, and use the best one for the fee calculation.

Transaction fee in ARDR varies depending on the status of the recipient account, sendMoney to a new account will charge higher fee than sendMoney to an existing account so don't make any assumption about the ARDR fee the bundler will have to pay to bundle your transactions, unless you check first if the recipient account is new.

One way to do this is to invoke the getAccount API on the recipient account and check for errorCode 5 in the response, then predict the fee according to the current minimum fee specifications.

A more robust approach is to submit the transaction when setting the broadcast parameter to false then read the minimumFeeFQT field from the response which indicates the minimum required fee in ARDR the bundler will pay for this transaction.

Bundlers rates cannot be trusted blindly as they may change based on market conditions, the returned transaction JSON including the fees calculated should be reviewed by the user.

The bundler rate used will be returned in the bundlerRateNQTPerFXT JSON field, -1 if no bundlers are known for the chain.


Is there a way to abort a stuck lightning network payment?

First of all: it is in fact not possible at this time to sort a stuck payment. The htlcs are a contract in which you agree to fulfill a payment if the routing node provides a preimage within a time window (the timelock). Assume you would be allowed to remove an htlc before the timelock, not only would this be a breach to the contract but it could easily result in a behavior in which you could initiate a payment, the merchant would claim the money, and while the preimage is propagated back to you, you would cancel your htlc causing the routing node to lose money.

Obviously as a protocol extension we could think about making a different onion request "abort routing" which would inform all nodes on the path to abort. This would have to be executed from the recipient back to the sender and would mitigate the above mentioned way of abusive behavior.

However such a new onion request would mean that everyone on the path is responsive to it. If that was the case in the first place the payment would not have been stuck.

It is always hard for mathematicians (like me) to claim something is impossible. But I think in this case we have it by design impossible / undesirable to cancel htlcs from the sender side. (I am happy to be proven wrong and would enjoy a discussion on the lightning dev ml as I think from a UI / UX perspective your request is totally reasonable)

Also keep in mind what removing an htlc currently means. The state of the channel is changed.


Publicly destroying bitcoins by setting high transaction fees

There can be no solution.

Even if you managed to solve the "allowing only nodes with %<X problem" (and I doubt it is feasible), you wouldn't solve anything, since one single person can create two small nodes, but he is actually owner of both (i.e. controls a combined hashpower).


Is there a cudaminer difficulty parameter option

No. Difficulty is handled server-side rather than client-side.

Different pools have different policies regarding difficulty. Some pools have a fixed difficulty. Others automatically calibrate the difficulty depending on your hashrate (this is called vardiff). And some let you set the difficulty, on the pool website. But in any case, it is ultimately the stratum that sends out and accepts work, so it is the pool that dictates difficulty.


When i look at the snapshot it seems like your device isn't hashing. Did you have your device hashing? and did you get the USB TO UART DRIVER BY SILICONE LABS? respond when you have the answers.


In a way, this is how deterministic wallets work: All keys and addresses are derived from a secret pass phrase. The "wallet" in this case is the description of the algorithm, which is "stored" publicly.


According to blockexplorer.com your output has a total of 9.9999 (and not 4) btc. If you own both vout addresses for this transaction, using only 2,5 of them in your raw transaction leaves a 7,4999 btc fee for the miners, which is insanely high.

According to bitcoin 0.9 release notes there is a mechanism now in place that:

  Reject insanely high fees by default in 'sendrawtransaction'

so that could be the reason that your transaction is being rejected. Try adding one more vout to your raw transaction and see if it works.


The easiest way to move these funds is simly run both wallets and transfer the funds in a regular transaction.

For safety sake keep a backup of your old Blockchain wallet as you may find out in the future that you need the keys such that a service may have sent funds to a preregistered address or someone reused an old address.

Remember to create a backup of your new seed which Electrum will provide to you.


How many bits of entropy is a Bitcoin address?

For Pay2PubKey addresses, it's always 160 bits of entropy, regardless of the address format (old, 1... or the new Bech32 format)

Pay2ScriptHash addresses, in the old Base58 format (3...) have 160 bits of entropy.  In Bech32, they have 256 bits. You can read more about why the developers increased it here and here.


Any guidance to built Simple and Basic trade engine?

The trade engine itself does not withdraw or deposit coins. It would be terrible for the exchanges, because it slows the trading down enormously, and also the fee they collect is reduced (or the fee you pay is increased).

When you want to withdraw some coins, the site checks the wallets they own who have enough balance. From one of those (Im not sure how that is selected, but there is probably some optimization there) your withdraw amount is transferred to your address. So you get bitcoin (or whatever altcoin) from a deposit wallet from someone else. This last thing does NOT mean you loose money, as cryptsy knows that you have 1 BTC (or whatever) on the site.

Anyway, the system is still the same as your previous question, and it is not completely clear what you are asking now. The trading works as I answered (and in the comments) over there. I hope the withdrawing is a bit more clear now.


At the time of the snapshot, the coins which you controlled in your wallet would exist in both the original BTC blockchain, and the newly split BTG blockchain.

You can redeem these BTG coins for BTC (or another Cryptocurrency) via an exchange which supports these tokens (eg Bitfinex, Yobit,  etc) once the BTG blockchain is being publicly mined, and transactions can begin.

Selling before this time would have to be done via a futures contract, although I do not believe there are any major platforms trading BTG futures at this time.


Dollar cost averaging approach to Bitcoin investing?

This can be done today.

Dwolla lets you send money to Mt. Gox on a schedule:
 - http://help.dwolla.com/customer/portal/articles/164379-multi-payments-schedule

You then can leave an open market order to buy bitcoins, e.g., a bid for 10,000 BTC.

The moment new funds arrive from Dwolla, Mt. Gox will attempt to execute the remaining part of the order using all USD funds available in the account and those bitcoins will be purchased at the market price at the time.

Of course, this assumed the account is not used for any other trading, as that open bid order would be triggered from any BTC sales that occur.


Javascript widget that shows the balance of a particular address

Here's a third party service that creates an img:

Balance:

http://bitcoinbox.ru/display/graph.php?btcaddress=1PC9aZC4hNX2rmmrt7uHTfYAS3hRbph4UN&type=balance

Total received at the address:

http://bitcoinbox.ru/display/graph.php?btcaddress=1PC9aZC4hNX2rmmrt7uHTfYAS3hRbph4UN


Concept of Block weight and segwit are still unclear

Have a look: https://blockchair.com/bitcoin/block/0000000000000000000cbbceb342e07071f9621607e044ec909aa86fcdf88e8a

Size = 1,158,038 bytes
Weight units = 3,992,825 WU

Now what does it mean? So the size is what you probably understand well – when you have a file on disk, its size is measured in bytes and this is exactly what the size means here. It is the number of bytes you would need to store such a block in memory or on disk. This is the sum of non-witness data (nWD) and witness data (WD). Let's call this the absolute size for clarity (AS).

There is also something called virtual size (VS). This is a new concept, which measures the block in new units, called vBytes. It is calculated as (absolute size of non-witness data) + (absolute size of witness data)/4.

Weight of the block (BW) is calculated in weight units and is calculated as (absolute size of non-witness data) * 4 + (absolute size of witness data). This actually equals what you have mentioned in your post: (tx size with witness data stripped) * 3 + (tx size) because the transaction itself contains both witness and non-witness data.

So, now we know that:

AS = 1,158,038 bytes = nWD bytes + WD bytes
BW = 3,992,825 WU = nWD * 4 weight units + WD weight units

What are the limits in the protocol? Currently there is no block size limit any more. There is just one limit for block weight. This limit is set to 4,000,000 WU. It follows that in case of a block without Segwit txs, each byte's weight is 4 WU, therefore, such a block without Segwit txs is limited by absolute size of 1 MB.

Blocks that contain Segwit txs can be bigger than that and there are some theoretical calculations that say you can go to something like 3.7 MB of absolute size of a block. But this theoretical limit is just that – theoretical. In practice, even if the block was full of Segwit txs, its absolute size would not reach this limit.

Currently, most blocks contain both txs - Segwit and legacy, so we see the block sizes of full blocks usually in the range between 1 - 2.2 MB. The block is full if it's weight is very close to the protocol limit of 4,000,000 WU.

This implies that it is not correct to think that a block of size 1.1 MB is composed of 1,000,000 bytes of nWD and the rest is WD. That wouldn't work because the weight of 1,000,000 nWD bytes would already be 4,000,000 WU and therefore if we added the weight of WD to it, we would be over the limit. That is not possible.

So, if we know AS = 1,158,038 KB then it is rather that there are 944,929 bytes of nWD with weight of 3,779,716 WU and the rest is 213,109 bytes of WD with weight 213,109. This makes the total weight of the block 3,779,716 + 213,109 = 3,992,825 WU.

We can now calculate VS:

VS = nWD vBytes + WD/4 vBytes = 944,929 + 213,109 / 4 = 998,206.25 vBytes

Virtual size (VS) thus cannot be greater than 1,000,000 vBytes, so this is what is meant if someone says that the new block size is still limited by 1 MB - they actually mean 1 million of vBytes.


Nosey/disgruntled employees at my VPS company

The only real solution is to not keep private keys on that server. Keep them on a computer that only you can access, or offline in a paper wallet.

Encrypting the wallet will help somewhat, but a malicious administrator could log your passphrase when you unlock the wallet, or extract the decrypted private key from the server's memory.

If the server must have private keys (e.g. because it has to make payments), then your software should be designed to keep only the minimum balance necessary in the server's wallet, and sweep the rest to addresses whose keys you hold elsewhere.


Which crypto-currencies can be mined effectively with GPU

You can look at litecoin. It is still feasible to mine it with CPU and GPU, because it is really hard to implement the algorithm in ASICs. And the price of litecoin is not bad.