How do I call getblocktemplate from C#'s bitcoinlib?

var blockTemplate = CoinService.GetBlockTemplate( new { rules=new List<string> { "segwit" } });

This function call requires you to specify rules for the block you want to create and in newer Bitcoin Core version, you can only create blocks following the segwit softfork rules.


Hardware wallets are easy-to-use ways (compared to paper wallets (hard to use) and software wallets (not as safe as hardware wallets)) of being in control of your private keys hence the safest and the easiest way of using and storing cryptocurrencies.

When you use a (traditional) exchange as a wallet, you won't be in control of your private key so the exchange can steal your funds or get hacked and lose them etc.

There are decentralized exchanges where you don't need to deposit your funds (thus you don't need to trust, a.k.a trustless) like RadarRelay. You can use them with software wallets and some of them with hardware wallets directly.

Don't forget that cryptocurrencies' reason of existence is being trustless, don't hand over your funds to anyone, always be in control of your private keys.


Fundamentally what is the difference between the EOS and Ethereum platforms?

The jump between Ethereum to EOS isn't nearly as big as was from Bitcoin to Ethereum. The same concept of using smart contracts applies, but EOS has the following "improvements":

1) Ethereum is currently partially proof-of-stake but will be fully soon. EOS is launched as completely proof-of-stake.

2) EOS has no transaction fees. The developers realized that fees limit the growth of the network, because no dAPP running hundreds of transactions per second wants to pay a fee. The incentive to "Stake" your EOS tokens and confirm transactions as a block producer comes from inflation... at the rate of 5% per year.

3) EOS will certainly handle thousands of transactions per second when they mainnet launch in June. Ethereum currently has 7 tx/sec, which will very likely increase significantly. However, by that time EOS could potentially be running hundreds of thousands of tx/sec as their code is meant to run on parallelized servers.

4) Uses 21 block producers that act like state governments to that can vote to make changes to the constitution. Users and dAPPs vote for block producers that they think best benefit the community. Ethereum dAPPs don't have this governance structure, but there are a few emerging (ie. 0x).

5) Plans to implement cross-chain communication using state channels. This would mean EOS interoperability with Ethereum and Bitcoin. Technically Ethereum can do this, but EOS is heavily developing on this concept at the moment.


bitcoind systemd service: forking or simple?

What is the implication of one or the other in the light of how bitcoind starts and runs?

Forking mode means that the program is going to call fork() and the process runs in the background while the main process exits. Simple mode means that the process stays running and doesn't exit unless the service is closed.

Since the .service file runs Bitcoin Core with -daemon, this means that it will call fork() and run in the background with the main process exiting. This is why it uses Forking mode.

  All other coins based on bitcoin share the same behaviour on this matter, or is this something that is likely to be modified by coin devs?

They share the same behavior because they are all based on Bitcoin Core. They all have the -daemon option.


Restoring private key from old bitcoin wallet

If you "imported" something from your old Multibit Wallet and ended up with a "watch-only wallet" it means that what you "imported" was a Bitcoin-address and not a private-key. You must find and import the private-key, not the Bitcoin-address if you want your new wallet to be able spend the money.
If your old Multibit Classic software is still working, you should be able to use it to create a transaction that sends money to a receive-address you create in a new wallet (using some different wallet-software such as Bitcoin-core).
I think a lesson for the rest of us is not to trust our money solely to proprietary backup formats. Always have a backup of either the master private key in Wallet Import Format (WIF) or the seed-phrase/recovery-phrase/backup-phrase in BIP-39 format or in some equally well-defined and well-known public format

Related questions with answers that may be useful:

Restore old multibit wallet
Recovering wallet from MultibitHD backup file
How do I get BTC out of my Multibit wallet?
My Multibit wallet is empty
I used multibit years ago - now what? (BTC, BTG, BCC etc...)
Import Multibit multibit.key into Electrum
Other questions about Multibit wallets


My Bitcoin Core Sent Bitcoins Without My Authorisation

You do not explain why you believe your bitcoin core process sent the bitcoins. It is perfectly possible (from looking at your logs) that it was not sent from your bitcoin core, but from elsewhere on the bitcoin network. It may be possible to track down where the tx was sent from if enough nodes log the IP address of where the transaction was initiated, but there is nothing in your logs to suggest it was initiated from your node. In fact, your logs suggest that it was not initiated from your node.

Therefore, at some point the private keys for your bitcoin address were obtained. This could have been done if your computer contains malware, perhaps a key-logger, which was able to capture your wallet password, in combination with the wallet file.

The output that was spent was populated on 2018-12-28 19:12, but the private key associated with the address could have been created years earlier, as Bitcoin Core by default creates 100 addresses when it is first started, so the private key to this address could have been stored on a computer of yours for some time, perhaps even in an wallet with no password, if you initially didn't enable the password until later. So the time of intercept (of the private key) is theoretically any time between when you first ran Bitcoin Core and when the theft occurred.


How to suggest to our church that they should accept Bitcoin payments?

My best approach would be to show them coinbase.com or xcoins.io or gemini.com and show them how its similar to a bank account. They can log in and check their balance or withdraw to a bank account directly from their wallet.

Tell them that Bitcoin + Coinbase is less costly compared to PayPal: With Coinbase the church can create its own donation button for its website and accept up to $1 million in transactions with no fees (and only 1% after that, compared to PayPal's 2.9% + 30¢/transact. fees). Of course if they accept Bitcoin without any intermediary like Coinbase, there wouldn't even be a 1% fee, either.

Really they're probably not going to know what your talking about unless you visualize it for them. For example in my xcoins.io account it shows my Bitcoin in a dollar amount too so they could see that and not get confused if you know what I mean.


Check the third output script:

OP_1 032487c2a32f7c8d57d2a93906a6457afd00697925b0e6e145d89af6d3bca33016
02308673d16987eaa010e540901cc6fe3695e758c19f46ce604e174dac315e685a OP_2 OP_CHECKMULTISIG

Essentially it's saying that in order for the transaction to be valid, the input script (scriptSig) must provide signatures for one (OP_1) of the public keys listed above.

So both the owners of the private key associated with either 032487c2a32f7c8d57d2a93906a6457afd00697925b0e6e145d89af6d3bca33016 or 02308673d16987eaa010e540901cc6fe3695e758c19f46ce604e174dac315e685a can validate that output.

This allows for scenarios where you need one of multiple entities (escrows) to validate a transaction before sending it off to someone.

Here's more info on OP_CHECKMULTISIG https://bitcointalk.org/index.php?topic=38903.0


Can you put additional data in the payload?

The JSON that you see is only a nice way to look at a transaction, provided by the API you're using. The actual raw transaction, as it is transmitted on the network, is binary data that looks quite different.

The only place in the transaction that you can insert arbitrary data is the transaction script. This script is normally used to specify the address that the money can be paid to, but can contain arbitrary data. Note that if this data happens to be a program, it won't be executed by any (typical) client, it's just data.


What incentivizes non-miner nodes to propagate transactions?

The incentive to propagate a transaction is so that adjacent peers cannot distinguish what transactions actually belong to the origin node.

Since all nodes by default relay all fee-paying transaction, it is not possible for a malicious actor to determine which transaction actually belongs to you as transaction that contain your inputs/outputs of interest will be masqueraded among transactions of interest to anonymous peers. This implicitly grants you more privacy since it makes it harder for a malicious observer to correlate transactions to your peer identity (e.g. ip address).


Each fragment starts it's own chain.

Edit: I randomly selected a transaction for you to see.  Try this link: http://blockchain.info/tree/7514743 and click on the yellow circles.

Edit2:: Actually, this one is more interesting: http://blockchain.info/tree/50429084  In the former, the payments mostly returned in part to the original address.  That's odd.  The usual way of doing things is sending to one address and returning to yourself at yet another address.


Can i use one pair public and private key for all transactions?

Each private key is associated with exactly one public key, which is associated with exactly one address.  So if you only want to use one private key, then you can only have one address.  This is "secure" in that it won't make it any easier for people to steal your money (barring a successful attack on ECDSA) but it is not so good for privacy, since people will have an easier time identifying your transactions as yours.

It is also possible to have one "master" private key or seed, from which many different "child" private keys are generated.  This is how an HD wallet works.  It is associated with a master public key, which can be used to identify your addresses and generate new ones, but as mentioned above, it would not be good for your privacy to actually make it public.


Basically, I think you have a Google Chrome extension (possibly FastSave 1.1) that is overlaying their ads with superfish's ad-serving network.

See here for reference:
http://www.fergeeks.com/chrome-tips/fast-save-1-1-chrome-extension-adding-ads-causing-havoc/

Check the chrome extensions you have; disable one by one. This is a particularly unobtrusive and semi-non-harmful (to you) virus that allows a malicious developer to replace ads you view with ads they serve.


How does the new database design used by Bitcrust work?

My understanding after a quick look at the code is that they use this sequential scan of stacked records of spends only for the recent 3 blocks (https://github.com/tomasvdw/bitcrust/blob/556375ccfaa81ca241b25f7b5b7f00fb97d5bd6b/src/store/spend_tree/record.rs#L296)

If the sequential scan did not find a match (if the input is from older blocks), they use this huge 2^58-bit bitmap, that is sparsely mapped to sparse files (if the filesystem does not support sparse files, they will use 16GB of storage for each 'range' that contains at least one bit set)

the code that uses 58-bit index:
https://github.com/tomasvdw/bitcrust/blob/556375ccfaa81ca241b25f7b5b7f00fb97d5bd6b/src/store/spend_index.rs#L67 (more exactly, a 52-bit index to a map of U64 values)

the 'hash' variable there does not contain a true hash, it is just a mapping of the internal storage indexes to 58-bit value: https://github.com/tomasvdw/bitcrust/blob/556375ccfaa81ca241b25f7b5b7f00fb97d5bd6b/src/store/spend_tree/record.rs#L168


Script Null into raw trasaction bitcoin core

This null script event what is it due to? Is there any phenomenon I am not aware of?

There is no script needed to spend the transaction vout referenced in the input because it was not locked with a key. For example, the txid of the first transaction referenced is c3d8d15a3ca1b50fc2519cbcb79f1db3b6be164c176c7ad51c7a5ec2e97ffa7b with output index 204. Below is how the that transaction output was locked.

{
    "value": 0.00000000,
    "n": 204,
    "scriptPubKey": {
        "asm": "7daba6288bcf43c2f7f555ec58f965eaac89b14bc4c4fc920a2a58163aa11e0e",
        "hex": "207daba6288bcf43c2f7f555ec58f965eaac89b14bc4c4fc920a2a58163aa11e0e",
        "type": "nonstandard"
    }
}

The locking script basically pushes 32 bytes of data onto the stack (7daba6288bcf43c2f7f555ec58f965eaac89b14bc4c4fc920a2a58163aa11e0e) with no verification opcodes at the end of it. That means, it can be spent with an empty signature. This types of transactions were generally done if you wanted to store hash of some data on the bitcoin blockchain. But that can now be achieved with a OP_RETURN opcode which prevents UTXO bloat. All but the last transaction that has been referenced are coinbase transactions which is paying out fractions of the newly generated bitcoins to the participating miners of the pool. It is possible that the pool manager wanted to encode and store a particular data onto the bitcoin blockchain.


Transfer of BTC the wallet address p2pkh to wallet address p2sh

As long as a utxo is spendable, there are no restrictions on the types of outputs - any kind of input can be used to create any kind of (valid) output, which will usually be one of the well known ones - i.e. p2pkh, p2sh, p2wpkh, p2wsh, op_return, p2ms, p2pk.


Which currency (crypto & fiat) to use to measure profits?

Companies measure their profits in currencies in which they keep the accounting.
In my opinion regular people should measure profits in currency which they earn and/or spend. Therefore you should ask yourself: Do you spend BTC? Do you spend USD?
You should measure profits in currency you can relate to in terms earning/spending money.


Why does Bitcoin use separate change addresses?

Change is sent to a new address to improve your privacy and the privacy of the other Bitcoin users you interact with.  Let's imagine you receive a payment from Alice in one transaction; then you spend some of that money to Bob and the change is refunded to you.  Then, in an unrelated transaction, you send Charlie some bitcoins.

Because you keep all of your bitcoins in a single address and Alice, Bob, and Charlie know who you are, all three of them can now easily use a block explorer to look up how many bitcoins you have.  It's like letting your family, friends, bosses (past and present), local businesses, and everyone else you've ever transacted with know your exact current bank balance.

But who cares?  If you're like me and you don't have a lot of bitcoins, that may not be a big deal.  However, by reusing the same address for everything, you also reduce other people's privacy.  For example, lets say Alice pays Charlie (and Charlie also uses the same address for all transactions).

Now Alice knows your address from the previous transaction and Charlie's address for this current transaction, so she can see that you paid Charlie.  Charlie can do the reverse and see that Alice paid you---so by using a single address for everything, you may have reduced Alice and Charlie's privacy.

What Bitcoin Core and other high-quality wallets do is try to completely avoid address reuse.  That means they prompt you to create a new address for every incoming payment and they always pay change to a new address.  This helps keep transactions separate.

(broken image, original source)

If you and Charlie use unique addresses, Alice may not be able to tell that you paid Charlie and Charlie may not be able to tell you received money from Alice.  Also, it will be much more difficult for anyone to figure out exactly how many bitcoins you control.

(I say "more difficult" because there are still situations where Alice and Charlie may be able to identify the payments to/from you.  Using unique addresses is a significant privacy improvement, but it's not perfect.)

Using separate change addresses costs you nothing extra over returning change to the same address (that is, the transaction will be the same size either way, so you pay the same fee) and it may have a slight security advantage when used with software that is broken in particular ways.  However, the major advantage is that you improve your privacy and the privacy of everyone you transact with---and as someone who might trade with you some day, I thank you for using software that uses unique change addresses.

Note: Bitcoin.org's Choose Your Wallet page indicates whether a wallet uses unique change addresses by default, so anyone else reading this may want to use that page to select a wallet that improves their privacy.


I seem to have too many unspent outputs for my given balance. What am I missing?

As per the comments on OP’s question

Since you made a copy of the wallet.dat file (which is an HD format), both addresses will be under the control of (both copies of) your wallet. Hence, both UTXOs will be listed when calling the listunspent command, as each wallet is able to spend both UTXOs.

If you used a new wallet to generate a new address, and send some funds to it, then the listunspent command should function as you originally expected, as your bitcoin core wallet would not control the address you spent coins too (it would only control the change address).


How do I view the extended public key in Electrum?

How do I view my extended public key?

Go to Wallet > Master Public Keys, and copy the text that starts with xpub

  What are the consequences of giving my extended public key to someone?

They can view all of the transactions and addresses in your wallet. They can generate as many of your addresses as they want.

  Can they steal my Bitcoins if I give this to someone?

No, unless you also give them one of your private keys. (All of your private keys are equivalent if they have access to your extended public key.) So, don't do that.


What is the optimal way to increment extranonce?

The Merkle root of the transactions is calculated by building a binary tree from the transactions as leaves where each parent node is the hash of its two children. As the coinbase transaction is the first transaction in the block, you can store the hashing partners on the coinbase transaction's Merkle branch and only repeat all the hashes to which the coinbase transaction contributes. This reduces the required number of hashes to calculate the new Merkle root for n transactions from O(n) to O(log(n)) given that no other transactions in the block were changed.
There is no way around repeating the whole left flank of hashes in the binary tree, since changing the extranonce in the coinbase transaction changes the outcome of the bottom left hash combining coinbase transaction and first regular transaction.


Running bitcoin-cli commands without hosting a node

This isn't exactly what you asked, but it's close.
Take a look at https://chainquery.com/bitcoin-api you can try different JSON-RPC commands through your browser.


what is the latest required hash rate to mine a block?

I think you can estimate the value with "getnetworkhashps" command

  What is the latest required hash rate to mine a block of bitcoin ?

26,592,872 trillions of hashes per second

  How much power do you need to mine a block in a day ?

average hash power of 1 day is 35,683,280 trillions of hashes per second

$ date --utc
Sat Feb 16 12:23:48 UTC 2019

// 1 block
$ curl --user 'id:password' --data-binary '{"jsonrpc":"1.0","id":"curltext","method":"getnetworkhashps","params":[1]}' -H 'content-type:text/plain;' http://127.0.0.1:8332
{"result":2.659287272432074e+19,"error":null,"id":"curltext"}

// average of 144 blocks (about 144 blocks are generated in a day)
$ curl --user 'id:password' --data-binary '{"jsonrpc":"1.0","id":"curltext","method":"getnetworkhashps","params":[144]}' -H 'content-type:text/plain;' http://127.0.0.1:8332
{"result":3.568328058845101e+19,"error":null,"id":"curltext"}

// chainquery.com (I think a little bit buggy sometimes)

http://chainquery.com/bitcoin-api/getnetworkhashps

// blockchain.com hash rate

https://www.blockchain.com/ja/charts/hash-rate


Why does Bitcoin store keys in a database?

Historically bdb was used for the UTXO as well, so you could justify using it for the wallet as well for consistency. It makes absolutely no sense today, other than that it will always need to be supported to some extent for compatibility.

Really the wallet could be replaced with any key value store at all and it would function completely fine. You would not want a single key per file because this tends to be incredibly inefficient and difficult to deal with from a filesystem, and a human interaction perspective. It's easier to back up a single file than tens of thousands in a directory.


Where can I find historical exchange rate data for BTC/USD?

http://www.coindesk.com/price
http://www.investing.com/currencies/btc-usd-historical-data
http://www.quandl.com/c/markets/bitcoin-data
https://bitcoinchain.com/markets

Also, there was a Bitcoin Time Series spreadsheet.  Scroll to the bottom to see the data sources.


generic big endian MPI format
bitcoin-specific little endian format, with implicit size

python implementation

https://github.com/petertodd/python-bitcoinlib/blob/master/bitcoin/core/_bignum.py


Buried in the bitcointalk.org forums I found this answer.

Use the keyconv binary file that is included, with the protected/encrypted key as the only  argument:

keyconv [Protected Key Here]

This will spit out the unencrypted private key. It isn't documented anywhere other than this forum post:

https://bitcointalk.org/index.php?topic=25804.msg2107686;topicseen#msg2107686


How can I measure the "health" of Bitcoin?

This strongly depends on what you think makes a financial system healthy.

As long as there is no challenge to the core of Bitcoin, distributed no third party controlled transactions, there is no need to worry about any of the technical aspects. Stakeholders are the major problem here, the hashrate distribution being the clearest example. Stakeholder power must be distributed to preserve the nature of Bitcoin. Hashrate has a hard limit at 50%, but even close will cause less reliability. Other stakeholder measurements have no clear/hard limits.

The health measure then comes purely from the hashrate (indicating security and current interest in the minable Bitcoin) and the amount of users connected to the network. Sadly the users connected cannot be measured correctly due to Bitcoin wallet services.

Any other metrics can show you what happens to Bitcoins, but not everywhere else. Some indications can be given about how Bitcoin are used, but not about their actual "health". At least not in any measure of health I can currently see to be valuable. I'd consider transaction origin and destination diversity to give some indication of user diversity, which would indicate how much Bitcoin is used, which would indicate robustness through diversity.

FYI: Many interesting graphs are here. They say something, but do not clearly indicate health. I do think most of them have "better" or "worse" directions, but they are fairly easily manipulated, especially in unhealthy circumstances.


How to get Bitcoin Cash from Multibit HD wallet?

You need to use a Bitcoin Cash specific wallet.  I won't recommend a specific one but here is a list:

https://www.bitcoincash.org/#wallets

Use at your own risk.


Solved: it appeared to be an "i" but the private key showed it as "l".


Where can I see the code of how the UTXO set is updated in case of a fork in Bitcoin Core?

In the case of a fork, you have to Disconnect the blocks that are on the losing side of the fork, and then Connect the blocks on the winning side of the fork, in order. If you look at the CCoinsViewCache input into the function, you can see how the UTXO set is updated.

Essentially, though, you have to reverse the effects of all of the transactions in the losing blocks and apply the effects of the transactions in the new blocks. Reversing means processing inputs to mark STXOs as UTXOs and removing UTXOs created in the block. Processing new transactions into the UTXO set means, in addition to verifying the transactions are valid, you mark UTXOs spent by the inputs of transactions as STXOs (or remove them, depending on how your system works), and you create new UTXOs for the outputs in the block.

Keep in mind that you have apply these processes for each transaction in the block in order (or reverse order if Disconnecting a block), because transaction B can spend from outputs created in transaction A, where A & B are in the same block.

  My goal is to maintain an index of addresses to UTXOs.

If I were you, I would keep an index of the scriptPubKey and then convert an address to the scriptPubKey you need when you need to do a lookup.


Is there a max number of tx outputs allowed by consensus?

There is no direct limit on the number of outputs, but transactions can't have more than an allowed amount of weight and this indirectly limits the number of outputs.


Feasibility of Integrating Proof of Stake systems into everyday devices?

The use of other devices to mine bitcoin probably came from the desire to do something useful with the heat that mining creates.  It takes a lot of energy to slow cook a pot of chili, so the thought was that instead of using traditional heating elements, use SHA256 ASICs.  Regardless of whether the electricity cost was less than the amount of bitcoin mined...you'd still cook your chili.  It was energy you were going to spend anyways, so any amount of bitcoin you mined was just an offset to your existing chili-cooking costs.

I don't think this concept translates to proof-of-stake mining, because I don't see the benefit.  Would you store funds on your toaster, which in turn proves it has a certain stake in the network?  What benefit would this provide over simply proving stake with a computer?  When there is no heat to find a use for, this concept falls apart.


@Davide's answer is correct but I expand the explanation a bit particularly regarding the blockchain.

  I´m beginner and I understood there is an unique huge common block chain to be used by world wide

A crypto-currency like bitcoin requires people to run the bitcoin software that makes the whole system work; it is a Peer-to-Peer (P2P) network and each machine running the software is called a node.** The primary incentive for people to run nodes is that they are getting rewarded with bitcoins via a process called mining explained here and here.

A blockchain (aka ledger) is a data structure (think of it as a file in your computer) that stores a history of all the transactions (actually groupings of transactions, called blocks, i.e. forming a chain of blocks) that took place in the network. Currently, it is around 65 GBs big and it is getting bigger with time as new blocks (of transactions) are added. Each node has a copy of the blockchain which is the same in all nodes via a consensus process enforced by computer algorithms.

Thus, in bitcoin, there is one common blockchain with copies in each node.

  and there a several different crypto currencies types by running on that . Am I correct? Thank you to all

No, other crypto-currencies make use of different software, form their own P2P network and have their own blockchains. Similarly, those networks will have a common blockchain and each node will have a copy.

This is a simplified/high-level view but I hope it clarifies things a bit.

** Users that just want to use bitcoin do not need to run a node.


How to create a new genesis block using CreateGenesisBlock() function

The genesis block still must meet the proof of work requirements that other blocks must also meet. So you must actually mine the genesis block. To do this, you need to put CreateGenesisBlock in a while loop and just keep incrementing the nonce, and if necessary, increment an extranonce in the coinbase transaction.

To check that it has a valid proof of work, use the CheckProofOfWork() function (grep for it and you can figure out what arguments it takes).


A modern Bitcoin wallet program can generate many private-keys, each private-key has a public-key. For the most common transaction types, a Bitcoin-address is derived from the public-key.
As you say it is normal to generate a new address (i.e. a new set of keys) for each transaction. This is because all the transaction data is public knowledge - it is in the replicated journal of transactions we call the blockchain. Anyone can see all transactions for a specific address, so if ten people each pay you 1 BTC to the same address, they can all see that you have received 10 BTC in total at that address. This is a privacy concern. If the addresses are all different, they can't tell which belong to the same person.
In the Bitcoin network there are no accounts, no virtual accounts and no balances.
A wallet can read through the whole transaction journal and add up all the unspent amounts in transactions where the receiving address is one for which the wallet knows it has the corresponding private-key. That way it can present a total amount to the user. People refer to this total as a balance but that's misleading. The Bitcoin network does not keep a record of people's balances. The Bitcoin network does not know how much money anyone has in total. The US Mint does not know how many US one-cent coins I have sitting in a plastic bag on my shelf, it doesn't keep track of my balance or have an account in my name.
The terminology for Bitcoin is a bit muddled. Bitcoin was designed as digital cash. Accounts and balances are associated with banks, not with piles of dollar bills under your mattress or in your leather wallet. If you were talking about cash in the form of paper money and metal coins you wouldn't think about accounts and balances. You'd just want to know the total amount of money you have in paper banknotes and metal coins.
Modern wallets are what is called Hierarchical Deterministic (HD) wallets. From the initial private key (or seed phrase) it is possible to generate all the subsidiary keys and addresses in a predictable and repeatable way. You don't need to make a backup of each generated key and generated address.


There are several questions here.

  Please correct me if I'm wrong: The miner validates the newly received block before using it themself and sending it to their other connected peers.

Yes and no. Note that by miner we're talking about people who build blocks themselves - that includes solo miners, pool operators, and p2pool users. Hashers that only connect to a pool and perform work are not part of that group.

Miners can - and sometimes do - build a new block before they've fully processed the previous one (even if it's their own), to avoid time not mining. Unfortunately, as they don't yet know which UTXOs are spent in the just-received block, they don't know what follow-up transactions are valid, and thus can't include any new transactions. Because of this, these blocks will be empty apart from the coinbase.

In practice, these miners will have two mechanisms to update the proposed block their hashers are grinding on:

A new best block hash is announced within their own network (or detected on another pool's network - for example by listening to their pool interface, or by an agreemwnt to send each other information). When this happens, all hashers are told to start working on an empty block.
A new block is received through their bitcoind (via the P2P protocol, via the submitblock RPC command for their blocks, or via separate relay networks like FIBRE). bitcoind then builds a new set of valid transaction on top (through the getblocktemplate RPC), and they update their hashers to start working on a block with these blocks.

The assumption is that when (1) happens, the same block will shortly go through (2), and we'll switch from working on an empty block on top to a normal block on top. There was once an incident where this did not happen.

When BIP66 activated, some miners running a BIP66-enabled bitcoind versions were listening in on blocks sent by pre-BIP66 pools. A pre-BIP66 miner produced a non-BIP66-compliant block (wrong version numbers), and BIP66-enabled miners listened in, and started producing empty blocks on top. Of course, their bitcoind never accepted the full block as it was invalid according to the new rules - rules those themselves miners agreed to. The result was a sequence of many empty blocks on top, with many miners building on top of the previous invalid blocks, all of which were not accepted by the network.

So to answer your question:

  So why keep mining on top of the previous block?

Because the new one may be invalid. It's unlikely to happen intentionally due to the costs of mining an invalid block, but it can happen as a result of software or manual bugs. Furthermore, we should not build infrastructure that relies on this not happening - as doing so might over time make such attacks cheaper.

  How long does this process typically take? What does it depend on?

In your process you're only counting block validation. But the whole process consists of everything between (A) the creation of a valid block on the network and (B) hashers switching to building a block on top of it. This includes:

The previous block creator getting the block out to the network. There may be unintentional delays here, or even intentional delays (like a Selfish Mining attack).
The blocks needs to propagate across the network. Normal bitcoind nodes only propagate after full validation, and require bursts of high bandwidth to transfer all blocks. More recent technology like Compact Blocks (BIP152) and FIBRE avoid full resubmission or even waiting until validation completed.
The blocks need to be validated.
A new set of valid transactions on top has to be created.

Validation depends on many factors:

Software version. There are constantly improvements to validation speed.
UTXO cache size. The larger the cache, the less database access is needed to retrieve information about the outputs being spent. As a result, just fetching of inputs can take from a few milliseconds to a few seconds.
Signature cache size and CPU speed. The larger the cache, the more signature validations can be avoided. These validations - depending on the software version and hardware van vary from 0.01ms to 0.6ms per signature (45ms to 2.7s for a block).
Correlation between the memory pool and the new block. If a block contains transactions that a node hasn't seen before, its inputs and signatures are less likely to be cached before.
Bandwidth. Prior to Bitcoin Core 0.13, blocks were always submitted in full between peers, which can cause big spikes at the time a new block is announced.
Network latency. In more isolated parts of the world, even with good bandwidth, the time it takes for a network packet to reach the outside world can be significant. Depending on the protocol, 1 to 3 roundtrips are needed to send a block. If the latency between two peers is 200ms, that can already mean 1.2s wasted on going back and forth.
Number of connections. If a node has many connections, it will try to broadcast a new block simultaneously to all, causing a spike of work of network activity. This can be too much for the CPU or network hardware or bandwidth to handle, causing slow downs when many connections exists.

The time to construct a new block mostly depends on software version. In older versions it was up to a few seconds, but lately is has been reduced to tens of milliseconds.

  Is it done on specialized mining hardware or on a general-purpose CPU?

As far as I know, no custom hardware exists for block validation or block construction.

  Is it correct that the time block validation takes is linear to the block's + witness's size should segwit activate?

Mostly. There exists an inefficiency in the currently signature hashing algorithm that can be O(n^2) in the size of transactions. This can result in single transactions that take minutes to just compute the signature hash. This is fixed in BIP144, which is always used inside SegWit transaction inputs, making it O(n) at worst (less than 10ms for a block in the worst case on common hardware).

Longer term, there are other factors that play, like the size of the UTXO set. If this would grow to multiple gigabytes, and not fit in typical memory caches, the UTXO fetch time for validation could go up dramatically.

  Also: How long does it take on average for a block to be propagated through the network? It'd be great if that average is weighted on the receiving miners' hashing powers.

That's complicated. It's certainly not proportional to hashing speed, but more related to network topology and used technology. The FIBRE website has some statistics, but often transfers in less than 20ms more than the minimum theoretical network latency (speed of light across long connections) across the globe. This is only possible by being a private network that assumes its participants will not engage in DoS attacks on the network. The public network is much more robust, but often takes many seconds to propagate a block to large portions of nodes, and dozens of seconds to reach less connected nodes.


Knowing if a public address is spendable by an HD seed?

Trying to enumerate all private keys using Bitcoin Core's wallet is extremely inefficient. Furthermore, any address that you generate in Bitcoin Core will inherently come from a HD seed because Bitcoin Core is a HD wallet and uses a HD seed. You also aren't going to get any information for a HD address that is not part of your wallet.

  However, I am not sure getaddressinfo is sentitive to this keypoolinfo parameter or is just checking the addresses so far generated (the ones that can be obtained via bitcoin-cli listreceivedbyaddress 0 true).

It is "sensitive" to the keypool. When you add keys to the keypool, they are actually generated and saved to the wallet file along with some metadata. getaddressinfo looks up whatever metadata is available regardless of the associated key being in the keypool or not.

  I could test this with a second node but my other node might be using another seed to generate new addresses.

Unless you have explicitly set a specific seed, then it most definitely is. Otherwise that would be a security vulnerability and anyone could steal anyone else's coins if they all used the same seed.

  Even though I used sethdseed, I see a different xpriv when dumping the wallet.

You need to provide the seed of your first wallet. Otherwise it will generate a new random seed and use that.


Web wallet making direct RPC calls to bitcoin node

If you want to do it from front-end (web browser) it's not a good idea because you will expose an access to your bitcoin node so anyone able do anything with you bitcoin node, if you want to do it on the server so it is normal practice.

Just don't expose your RPC node access, allow connections only from localhost.


How to make cryptocurrency easier for law enforcement?

It is possible to mitigate criminal elements in existing cryptocurrency networks within the current regulation framework.

Addresses of results of criminal actions are well known. Think stolen Bitstamp funds. Eventually these are written to police reports somewhere.
Exchanges, and other respected corporations, should act as a gatekeepers in this community off their own interest. Authorities of financial institutions have a duty to report crime (Misprision of felony).
If any exchange process transaction that has gone through a blacklisted address, the transaction should be stopped and the actor should go through anti-money laundering process, because they have somehow got criminal assets in their hands. There should be a paper trail to follow. If exchanges do not do this then they should be themselves subject to money laundering investigation due to breaking local AML and KYC regulation.
Tracking back Bitcoin transactions to blacklisted addresses is technically very feasible, because all transactions are public and it is just matter of maintaining a tree of transactions in computer memory. It doesn't matter how many times you tumble your coins, because you simply can't eliminate the trace of transactions from blockchain.
This assumes there is a party (Interpol, FBI) who maintains and enforces a known black list of addresses. The list should be publicly available for anybody. The list contains addresses compiled from police reports world wide. Currently no no such party exist. All parties in global trusted police consortium should be able to add addresses on this list with reference back to a local police report.
Fungibility, as promoted by some Bitcoin advocates, does not exist. You simply can't say "I don't know where my money is coming from." to government officials. Banks and financial institutions like PayPal are already subject to this regulation.

This way the system would be opaque to every day transactions (think a transaction of hiring divorce lawyer, medical bills) but still having a mechanism to track down criminals.


What trust am I placing where when I use Electrum?

"We" are volunteers running Electrum servers. There's almost no trust in them, the absolute worst they can do is feed you false negatives about the balance of your wallet, or they can also choose not to broadcast your transactions and pretend that they have. You trade some privacy in that they can see the contents of your entire wallet and associate it with your IP address. The client supports Tor connections if this is an issue for you.

The blockchain is 22Gb now, actually.


I have bitcoin core wallet with missing btc

Have a look at the transaction ID, try entering it into a block explorer and checking they really were moved. If they were, then no, it's unlikely you can get the coins back, your computer may have been compromised


TL;DR: There are so many addresses that it is improbable that anyone will ever generate a duplicate of another address in use – as long as random number generators work as they should.

2^160 possible addresses

Bitcoin addresses consist of an alphanumerical string with a length of up to 34 characters, excluding the capital "O", the capital "I" and the lowercase "l", as well as the number "0". This would allow for 58^34 possible combinations, however, as some of the positions are used for a checksum this is reduced to 2^160 valid addresses. The checksum on the other hand allows to detect mistyped addresses as invalid, so that it is highly unlikely to accidentally input another valid address.

Chance of 3.42*10^(-27) for a collision at one trillion addresses

Even if we generously assume that at some point there will be one trillion addresses (approx. 160 for each of this planet's population), according to the simple approximation formula for the Birthday attack given on Wikipedia, the chance is 3.42*10^(-27) that any two of those Bitcoin addresses collide. In comparison, the figure of addresses that were ever used to receive bitcoins was just over 13 million in May 2013.

Address space could be augmented

Especially as the protocol at any point could be adapted to accept even longer addresses, we can say, yes, it is theoretically possible, but unlikely enough that we can assume for our purposes that it will never happen.*

It's impractical to generate addresses for gain

To answer your other question: For each address there apparently are 2^96 different private keys whose corresponding public key will map to the same address. So to actually try to pursue Bitcoin theft, it would be much more sensible to just generate random private keys and hope to find one that has a corresponding address with money on it. In all likelihood the power for such calculations would cost more than anyone could earn with such a scheme.

*As long as certain random number generators work as well as they should... :)


How the disposable private keys are being shared in Lightning Network?

So the question is if it would be unfair to Alice if:

Bob wouldn't reveal his secret information and
Bob broadcasts the previous commitment transaction

Now, the only case in which Bob would broadcast the previous transaction is if it would have a higher balance for Bob. That would mean that the intention for the channel state update is that Bob would like to pay Alice for something. However, an update of a channel state (balance) is a two-step process:

Alice and Bob exchange the new Commitment Transactions
Alice and Bob invalidate their prior Commitment Transactions (by sending each other a (secret) piece of information)

That means as long as Bob doesn't reveal his secret information to Alice, the channel state is not considered as updated. Therefore it's perfectly fine for Bob to broadcast his previous Commitment Transaction as it represents the current balance. So it wouldn't be unfair to Alice, as from her point of view she hasn't been paid (yet) anyway. Only after she received the secret info from Bob, she would consider the payment as successful.


can someone explain what i did wrong here? (btc transaction with fee not confirming)

It looks like the fee is too low.

The fee (the difference between the input amount and output amount) is only 0.00001329 BTC - about an order of magnitude too low at the time of writing.

Most modern wallet software should propose sensible fees by default. Bitcoin Core started calculating fees dynamically in release 0.10. Could you perhaps be using an old version?

Alternatively, this service can be used to estimate required fees: https://bitcoinfees.21.co


HELP i sent btc from a tor wallet, The recipient hasnt recieved it

I see that your wallet sent out a total of 2.69947368 BTC in this transaction  on June 2nd, in block 469404, which has now been confirmed 1000+.


Are any miners still considering priority in their transaction selection?

Generally, no miners still use the priority system for selecting transactions. You can easily test this by spending a very old UTXO (e.g. 1 BTC that has remained unspent for several years) and paying no transaction fee. If miners still are using priority, your transaction should be confirmed relatively quickly (hint: it won't be). Otherwise, your transaction will not confirm for several weeks.


How can I recover a missing BTC from a correct transaction and who is the responsible for it?

Without your tx id it is hard to tell what exactly happened but usually you don't need to be worried. Your described scenario sounds like a "miner fee too low" issue, the transaction gets broadcasted successfully, thus Gatecoin or any other exchange believe the funds are out of their system, but then got pushed out from the mempool because other transactions have a higher fee. Such issue usually fixes itself once the fees on the network/mempool go lower. The transaction will be automatically re-broadcasted by the bitcoin node of the exchange and then gets included in a block and you get your coins on the receiving address.


If you have the HD8570 dedicated card around 86kh/s is what I was getting as well before any tweaks. But it sounds like you have the HD8570D GPU in an APU (Looks like they are in A8-6500 and A8-6600K CPUs) then you will definitely will be getting much lower kh/s than the dedicated card from looking at the specs. Since the GPU in the APU is sharing the system memory you will have to overclock your RAM in your motherboard BIOS settings.

Just in case you are talking about the dedicated card or someone else finds this thread I was able to get 127Kh/s with these settings.

SGminer 4.0.0 settings:
"--gpu-platform 0 -d 0 -w 256 -I 16 --lookup-gap 2 --thread-concurrency 3200"

This tweaked OpenCL file got me about 1% more kh/s and works for many cards. There are also others out there to try.

System:
Windows 8.1 with AMD 13.9 drivers

GPU Overclock:
Core clock from 780mhz to 990mhz
Memory clock from 900mhz to 1155mhz


Is multisig address belong to the same wallet created by?

TL;DR: Bitcoin Core currently (as of v.0.9.3) does not support spending from a multi signature address even even you create a multi signature address with public keys of addresses inside your wallet. Therefore it does not show the generated multi signature address in the UI or return "ismine:true".

Spending from a multisig address requires including the generated "redeem script" within the transaction. Additionally, the raw transaction has to be signed by 2 of the 3 public keys provided to "createmultisig" (also included in the script) in the order they were provided to "createmultisig". As of now, the wallet does not store these redeem scripts, nor does it know in which order the raw transaction needs to be signed. Because of this, you cannot spend from a Multisig address via the UI. Therefore, it doesn't make sense for Multisig address  to be included within the wallet UI.

Using Multisig addresses is still considered an "advanced feature." Therefore, they don't show up in the UI. This requires understanding what Multisig addresses actually are and how they work.

A Multisig address is a type of "Pay-to-Script" address. The addresses created using bitcoin-qt create a script like this:

OP_x (x = number of required signatures)
PUSH next 33 bytes
[33-byte public key (compressed)]
PUSH next 33 bytes
[33-byte public key (compressed)]
...
OP_y (y = total number of public keys)
OP_CHECKMULTISIG

This script is hashed to create your address. So, since this script is unique to you (your public keys), it does belong to you.

In order to spend coins from this address, you have to create a raw transaction that spends from the address and sign it with the private keys that correspond to at least x of the public keys (in the order they were given when creating the address/script).

Part of this spending transaction is the script itself such as the one above (in hex form). This is a required part of the transaction. Of course, the script could be built from the UI, but the UI would have to have to know the exact order the keys were presented to build the original address in order to re-build the script.

This brings us to the next problem. In the current UI, there is no way to sign a transaction. However, even if you could, the UI would not know (based off the address alone) in which order the transaction must be signed to be valid.

One way to alleviate these problems would be to store the script in the client itself, however this might pose a security risk to some degree. If the wallet were to store the address and the script in the wallet, somebody (perhaps malware) that is able to access your wallet would be able to get your private keys as well as the script required to spend from the address -- which is also in your wallet. If you know what you're looking for, it's fairly easy read the script, find the corresponding keys in the wallet and create a transaction to spend the coins.

At least with the current Multisig pains such as manual transaction signing and such there is a layer of obscurity. If you were to send all of your BTC to a Multisig address, an attacker wouldn't be able to just up and run off with all your BTC. They would have to have a few key pieces of information: the original Multisig script (which I don't believe is known until a successful spending transaction has occurred), the private keys, and they'd have to know both the correct private keys and the correct order to sign the spending transaction in. Of course, that's a lot of information that would be needed just to make a successful spending transaction -- none of which (other than the private keys) is actually stored in the wallet.

So, while it may be difficult to deal with Multisig transactions/addresses in bitcoin-qt, it may be a good thing!

However, I don't see why once you've generated a multisig address that it couldn't be added to your receiving addresses. I have a feeling it has to do with the difference between how regular and pay-to-script addresses are generated and the fact that regular addresses use a fixed-width private key, where as a script (which is basically the private key of a Multisig address) is an arbitrary length: 1+(34*num_public_keys)+2.


Can a node exit the bitcoin network and return to his address and transactions?

Transactions are not directly sent to the node that holds the private keys for the addresses involving it. Rather transactions are broadcast to all nodes on the network and then recorded on the blockchain. When a node rejoins the network, it downloads and verifies the blockchain from its peers. When it does that, it scans the blockchain for transactions that pertain to it.

The process of receiving is completely passive; there is no direct sending to the receiver (the sender does not have that information) nor is there a claiming process.


Are any hashes (Tx or block) actually stored in the blockchain?

No. Hashes are computed upon receipt of the Tx message, and stored in a database outside the blockchain by the client/node.

http://www.reddit.com/r/Bitcoin/comments/1sqa1q/techincal_do_transaction_messages_between_nodes/


As of Feb 2013, which are the top 5 bitcoin mining pools to join with a good community?

According to the blockchain.info's chart, as of Feb 2013 the top mining pools apparently are:

BTC Guild
50BTC
Deepbit
Slush
EclipseMC

I can't say for the "good community" since that's obviously quite subjective.


How do I know how many confirmations a transaction has?

As you can see at the bottom of your screenshot, or on any block explorer similar
(https://blockchain.info/tx/2daf1bea238137e5db00cd12074a93f181bf86a759f1963fd92197671f32a463),
you can see that it has 84 confirmations as of the time of writing, well over the 4 you said was needed.


Is the electrum android private key secure?

The android version requires me to select a PIN but it is only 6 digits long? How does the android version of electrum ensure that this tiny keyspace (1 million) stays secure?

The PIN is not used as a master seed in this way. It may be used as an additional source of user-supplied entropy, but the wallet's seed will be generated in a cryptographically secure way, using other sources of randomness to provide sufficient security.

I am unfamiliar with the specifics of Electrum's implementation, but there are generally two possibilities here:

1) the password / PIN is simply used to encrypt the wallet, and is not used as input for the seed

2) the password/ PIN is used as a '13th/25th word' that acts as a password on the mnemonic. Find more info here. Also, from BIP 39:

  A user may decide to protect their mnemonic with a passphrase. If a passphrase is not present, an empty string "" is used instead.


How long does it take for a transaction with 0 fees to be confirmed or rejected?

The time it takes for a fee-less transaction to be confirmed can vary vastly. While sometimes you're lucky enough to have it confirmed within the next block (as if you had paid the standard fee), other times it may take days.

This depends on the current transaction volume and miners' level of altruism. Most notably though, it depends on the number of Bitcoin Days Destroyed. Older coins (coming from older transactions) are conventionally assigned higher priority, and thus will generally be included in a block sooner.

As your transaction is pending (unconfirmed), the coins it is spending are getting older and older every day, so the chance of finally getting confirmed is slightly increasing overtime. This should prevent your coins from becoming completely unaccessible, stuck in the void.

No transaction can be rejected though, there's just no such thing in the protocol.

Finally, if this happens to you and you're not willing to spend some arbitrary time in uncertainty waiting for the confirmation, you can perhaps try to create a double spend transaction with higher fees, hoping it would be picked up by a non-standard (though pragmatic) miner.


No, by design.

Being able to infer connection information of remote nodes would be a leak of network graph information, which is considered private.


Retrieving all the funds from BIP32 derived wallets

Is it common for the site to immediately send the received coins to its superwallet (master node) upon X confirmations?

No. Not at all and would normally be considered very bad practice as in bitcoin you don't spend from addresses but from transactions, so "accumulating" in one address doesn't really work. Sending from that address would again have to reference all the forwarded transactions. (There are special cases like green address in its original implementation but no, that's a thing of the past.)

  And how would u know when a payment is sent to one of the derived addresses?

You watch the bitcoin network? Either through proxies or with a full node. Check out the insight.bitpay.com API.

  Let's assume the case with a derivation path of m/k'/0/i, where m is the master node, ever user has a k node and i is his i'th purchase transaction.

I would strongly advise to hold that logic in the server, only.

eCommerce sounds like one central server, so there is really no big need to fan out too much in the HD wallet structure. You should also look into BIP44 on transaction discovery.

Your business logic has to keep track what purpose an address has but if that website never has to send refunds, it would typically only have an extended public key. Now if it receives to

m / 44' / 0' / i' / 0 / j

any bip44 compatible wallet would find and be able to spend the funds if you provided it with at least the xpriv key for

m / 44' / 0' / i' / 0

but typically

m / 44' / 0' / i'

One minor thing you have to keep track of, is the gap between addresses that don't receive a payment. If your server observes a gap of more than 20, you would have to help your wallet to find those funds if it's strictly bip44 which would only bridge gaps up to 20. If your last transaction is to index 1220 and you don't see transactions to 1255 and 1257, you could send a satoshi to 1239 and your wallet would find the rest.


Keep or Transfer Coins after mining reward?

Is there a reason why people immediately transfer their coins to a
  different wallet?

If someone will hacking that mining pool, his able to steal all users coins. Move money to the cold-storage is a good practice. They're also can just move money to the exchange.


All else being equal which is better for the environment, Litecoin or Bitcoin?

No. It is exactly the same balancing mechanism: Electricity and acquisition cost vs revenue.
I would expect the total environmental impact to turn out similar for a given revenue value.

But then, maybe I'm missing something. I'm curious for other answers.


Bitcoinj doesn't read Bitcoin Core wallet.dat files. You need to start a
fresh wallet and move coins into it using a standard Bitcoin transaction


Based on the screenshot your wallet is not encrypted and does not need a password; HOWEVER since your node is still syncing, note where it says "3 years and 4 weeks behind", you cannot trust the balance. So wait for it to finish syncing. If you still have a balance after fully synced then your coins are still on that wallet and should be spendable.


How can I get UTXO for a specific address?

You can use Electrum servers via blockchain.address.listunspent

An example implentation: [1] that calls [2] (Note: this is an altcoin implementation)


How to edit the label of an existing address exactly like in bitcoin-qt but instead using RPC calls?

accounts are groups of addresses and the label you see is the name of an account. you may list this with rpc listaddressgroupings. a key that you "relabel" with setaccount will be "moved" to the account with the new label but all other addresses stay with the other account. of course you may move all addresses to another account. basically an address can only belong to one account at a time, not vice versa.

also see How do you delete an account in Bitcoin Core?


bitcoin fork getblocktemplate keeps reporting downloading blocks

Because block 506016 happened ~1 week ago, when you start your node software, it thinks that it is still in the initial block syncing phase because the timestamps are off of real time by a lot. The only way around this is to mine a block now. You can modify the source code to bypass this warning so that you can mine a block.


Does it create a public key based of private?

Yes, a cryptographic routine exists that computes the public key from the private key.

maybe on the wallet.dat file?

All modern wallet software generates keys derministically from some sort of master key, or seed phrase. That master key is stored in the wallet, and all other private keys are derived from it, and the public keys are derived from that. For every new receive address, a distinct key is used. The fact that they're all computed from one piece of data means that a backup of your wallet allows generation of all future addresses - even the ones created after the backup was made.

How would you be prevented from getting a private key if you have the public key?

Cryptography. The function to compute the public key from the private is fairly efficient in one direction (~50 microseconds on a modern desktop CPU), but the best known algorithm for going the other way around (Pollard's rho) would take around 300 trillion times the age of the universe on the same computer. With many computers it becomes faster of course, but even billions of times faster isn't remotely close to being able to realistically break any key. The security is based on the assumed hardness of a number theoretical problem, the elliptic curve discrete logarithm problem (ECDLP).

and what stops someone from looping over a bunch of private keys to find one with some coins in?

There are 115792089237316195423570985008687907852837564279074904382605163141518161494336 valid private keys (that's the actual number). Attempts to brute force them are futile due to the sheer number. The duration I gave above doesn't rely on brute force - it uses a much more efficient algorithm. Brute force would be 600 trillion trillion trillion times slower still.


How do I use bitcoind to spend from private key but not store it

For advanced users it is possible to build a raw transaction and sign it in the debug console without having the key imported into your wallet HOWEVER your node needs to be sync'ed at least up to the inputs you intend on spending.


Bitcoin extortion threat for address 14poC1Jg97vuvsyoKSZYz7h276LoAZcrtn?

It is a well-known hoax, ignore it.

https://blog.malwarebytes.com/cybercrime/2019/02/sextortion-bitcoin-scam-makes-unwelcome-return/

It never hurts to check your antivirus protection is up to date and that you have offline backups of important documents/photos etc (and test that you can recover from those backups)

It doesn't hurt to reconsider how you compose and use your passwords for online services (shopping banks, email, amazon, ebay, etc). Change passwords associated with websites that have had a data-breach. make sure you don't use the same password for more than one website. Make sure you use strong passwords (e.g. long random ones generated by a carefully researched and carefully chosen reputable password manager)


Doesn't overt AsicBoost reduce the search space for a valid block header hash?

What difference could it possibly make? Each hash you do still has the same odds of mining a block so all that matters is how many hashes you can do per second. It makes no difference how big or small the search space is unless it's so small that the time to start a new search becomes significant, which 2^64 certainly isn't.


Copay wallet no longer available on the Google Play store

In early September, Google removed Copay and a number of other Bitcoin wallet apps from the Play Store. I don't think we know why exactly those apps were removed, but things like that do seem to happen from time to time in the crypto world. More recently (late November), it was revealed that a hacker had managed to inject code into Copay that could steal users' wallets. I don't think those two events were related, but if you have funds stored using Copay I'd definitely recommend taking steps to make sure that your version of the software does not have the vulnerability. See here and/or contact BitPay support for more information.


How are UTXO forwarded to other addresses?

A first thing to correct is that UTXOs are not referenced by address, but by the txid that created them. The addresses are purely a human abstraction about locking conditions to help think about ownership.

So in your example what happens is that in the initial transaction tx0 created by A, B was credited with 10 BTC. Assume that transaction only had one output. That means that there is now the state of the UTXO is:

tx0:0 (10 BTC, spendable by B)

When B now wants to pay C, he creates a transaction tx1 with input (tx0:0, (signature by B)) which consumes the UTXO listed above, and has outputs (tx1:0, 5 BTC, (spendably by C)) and ((tx1:1, 5 BTC, (spendable by B)). Note that the tx1:0 and tx1:1 are not actually stored in the transaction here; they're implicit as the 0th and 1st output of tx1.

The state of the UTXO set is now:

tx1:0 (5 BTC, spendable by C)
tx1:1 (5 BTC, spendable by B)


Looking for revenue data of bitcoin related websites

The blockchain itself is literally a database of every transaction ever, so if you download it and parse through all of the transactional data, I guess that probably qualifies as 'revenue related stats'.

Blockchain.info has a lot of stats that you may find interesting.


GPU mining in Bitcoin is simply not recommended nor is it at all profitable. This is the same for all other SHA256d coins due to re-purposing of Bitcoin hardware (which share the same algorithm).

Your electricity cost will be far greater than any rewards unless you are using an ASIC (Application specific integrated circuit) miner, any even in that case you may require cheap electricity in order to make it profitable.

However, GPU mining does exist in other Proof-of-Work coins that have not (yet) been primarily flooded with ASIC hardware. Ethereum, for example, has a relatively fair enough difficulty to make GPU mining viable in specific cases. I recommend using this site to compare graphics card profitability in different coins.

NOTE: Mining Ethereum on a graphics card will require atleast 4 GB of VRAM in order to fit the entire DAG file required for mining.


I couldn't find the results of the Coin Selection written out anywhere, and just finished piecing it together from the code. It works as David mentioned, but here are more details.

The Coin Selection Algorithm logic to transfer Target amount

If any of your UTXO² matches the Target¹ it will be used.
If the "sum of all your UTXO smaller than the Target" happens to match the Target, they will be used. (This is the case if you sweep a complete wallet.)
If the "sum of all your UTXO smaller than the Target" doesn't surpass the target, the smallest UTXO greater than your Target will be used.
Else Bitcoin Core does 1000 rounds of randomly combining unspent transaction outputs until their sum is greater than or equal to the Target. If it happens to find an exact match, it stops early and uses that.
Otherwise it finally settles for the minimum of

the smallest UTXO greater than the Target
the smallest combination of UTXO it discovered in Step 4.

As David mentioned, the subset problem will first restrict to UTXO that have at least one confirmation if sent by yourself, or six confirmations if received from another wallet, then later relaxes these requirements in two further passes if no suitable set of UTXO could be discovered.

Some examples

Alice has four UTXO:
• UTXO_A 0.1BTC
• UTXO_B 0.3BTC
• UTXO_C 0.5BTC
• UTXO_D 1BTC

I will be ignoring transaction fees for simplicity's sake.

Example 1:

Alice wants to send 0.3BTC.
Bitcoin Core discovers that UTXO_B matches the Target, and it only uses UTXO_B as input.

Example 2:

Alice wants to send 0.4BTC.
Bitcoin Core finds that UTXO_C is the smallest UTXO greater than the Target, and that the sum of all UTXO smaller than the target (i.e. UTXO_A + UTXO_B = 0.1 + 0.3 = 0.4) matches the Target here. Both UTXO_A and UTXO_B are used as inputs.

Example 3:

Alice wants to send 0.45BTC.
Bitcoin Core finds that UTXO_C is the smallest UTXO greater than the Target, and that the sum of all UTXO smaller than the target (i.e. UTXO_A + UTXO_B = 0.1 + 0.3 = 0.4) does not surpass the Target. UTXO_C is used as the sole input, being the next smallest input greater than the Target.

Example 4:

Alice wants to send 0.35BTC.
Bitcoin Core finds that UTXO_C is the smallest UTXO greater than the Target, and that the sum of all UTXO smaller than the target (i.e. UTXO_A + UTXO_B = 0.1 + 0.3 = 0.4) does not match the Target. It adds up randomly selected UTXO 1000 times until they surpass the Target, remembering the smallest sufficient combination. The smallest sufficient combination is then compared with the smallest single input greater than the target. Assuming that it does find the best combination here which would be UTXO_A + UTXO_B, it finds that Target < UTXO_A + UTXO_B < UTXO_C and uses UTXO_A and UTXO_B as inputs.

Example 5:

Alice wants to send 0.6BTC.
Bitcoin Core finds that UTXO_D is the smallest UTXO greater than the Target, and that the sum of all UTXO smaller than the target (i.e. UTXO_A + UTXO_B + UTXO_C = 0.1 + 0.3 + 0.5 = 0.9) does not match the Target. It starts trying random combinations as before, and in this situation would probably discover that UTXO_A + UTXO_C = Target. As it finds a combination that matches the Target, it breaks and immediately goes with that combination. UTXO_A and UTXO_C are used as inputs.

¹"Target" is used here for the amount to be spent.
²UTXO = Unspent Transaction Output


The command you are looking for is listpeers. That will only show your direct peers and the channels you have open with them.


You don't have any guarantee. You are relying completely on the developers to submit the binary application file based on that source. You are also relying on Apple not to manipulate the application binary once it gets to them.

It's no different with Bitcoin Core or any other wallet or software. In all cases you're putting your trust in whoever does the build and the source and tools they use.

One option is to look at the history of the software. If it's relatively mature and has had no faults, either malicious or competency related, then it may be safe to put a degree of trust in it.


Segwit transaction from mixed addresses (segwit and non-segwit)

The right way to look at it is that every transaction input has a witness. For legacy outputs being spent, that witness is just empty.

So yes, mixed SegWit and legacy inputs are possible. SegWit transaction serialization will be used, and the witnesses for all legacy inputs will be empty.


Multibit password incorrect - what else can cause this?

It could be a problem with the Multibit app.

Did you export before the private keys ?

If yes, You may import your keys at blockchain.info (just paste the .key data to import form)


The JSON-RPC API can be used by other programs to communicate with the Bitcoin client.  That could include external mining programs, "e-commerce" software to automatically make and receive payments, or any other software that wants to interact with the Bitcoin network.

It is true that you do not need this feature simply to solo mine using setgenerate true.  However, you should be aware that setgenerate true enables an inefficient CPU miner which is obsolete technology and should be used for testing only.  It will cost you far more in electricity than you can ever expect to earn in mining revenue, and with very high probability you will never successfully mine a single block.  The current state of the art in mining is dedicated ASIC hardware.  Such hardware would normally be controlled by a separate piece of software, which would then communicate with the Bitcoin client over the RPC API.


Understanding basic Bitcoin Transactions: the scriptPubKey.addresses array

tx: 60a20bd93aa49ab4b28d514ec10b06e1829ce6818ec06cd3aabd013ebcdc4bb1

OP_1
04cc71eb[...cut...]0d348ac4 // this is pubkey of 1AJbsFZ64EpEfS5UAjAfcUG8pH8Jn3rn1F
0461cbdc[...cut...]c15342af // this is pubkey of 1A8JiWcwvpY7tAopUkSnGuEYHmzGYfZPiq
OP_2
OP_CHECKMULTISIG

to spend this transaction one should sign it with one-of-two privkeys

tx: 274f8be3b7b9b1a220285f5f71f61e2691dd04df9d69bb02a8b3b85f91fb1857

OP_1
0351efb6[...cut...]77da78 // this is public key of 1NdB761LmTmrJixxp93nz7pEiCx5cKPW44
00f2b781[...cut...]93569e // this is not a public key!
OP_2
OP_CHECKMULTISIG

tx: 4b72a223007eab8a951d43edc171befeabc7b5dca4213770c88e09ba5b936e17

You can read about this transaction here:
http://www.righto.com/2014/02/ascii-bernanke-wikileaks-photographs.html [16]


What's the relationship between the first pkey/addr (the one with hdkeypath: m/0'/0'/0 and the third one m/0'/0'/2?

They are derived from the same parent key. Other than that, there is no relation.

Does the first key/addr is the master (key) who can recover all later keys generated in the wallet.

No. They are both child keys of the key at m/0'/0'. The actual master private key (the key at m) is not exportable. There is a HD seed (which is used to generate the master private key at m), but this is only exportable through the dumpwallet RPC.

I only backup the private key of m/0'/0'/2, and removed the whole wallet (the .dat file). Is there a risk of this method? Since I only choose to use this key/addr to receive and store BTC.

Don't do that, you will lose money. When you send Bitcoin, Bitcoin Core will generate new change addresses and send any change there. Those change addresses have different private keys. Without them, you will lose money.
Additionally, by reusing the same address, you are significantly hurting your privacy. By using the same address over and over, anyone you transact with will know how much money you have in your wallet and be able to see all of your incoming and outgoing transactions. This allows anyone to track your spending habits.

I later create a new wallet and restore this m/0'/0'/2 key with command importprivkey. and send some BTC to other people, and found it generate a CHANGE addr, so I also backup this new addr's private key too. Since I mainly use this m/0'/0'/2 to store long term BTC, and will not use it to make a lot transactions. So I keep the privatekey of m/0'/0'/2, and keep backups priv keys of change addresses it generated, then drop all wallet files. Is this method enough to restore all my balances in a futher day.

Bitcoin Core constantly generates new change addresses. The one time you forget means that you will lose money. If you accidentally request a new address and use it, you will lose money.
In general, backing up individual private keys is not recommended. You should back up the entire wallet.dat file itself. There is no need to export each key individually and back it up in that way. That is a surefire way to lose money at some point in the future.

Can the private key of m/0'/0'/2 be used to recover the change addresses' private keys? (What is the master seed of HD wallet, it is the private key of m/0'/0'/0?)

No. The change addresses are unrelated. You would need to have the HD seed mentioned previously in order to derive them.


Running a Bitcoin client with tor with a Debian based Linux OS

Setting up Vidalia

Download the Tor Browser bundle
Extract, go to the App folder, and double click Vidalia (and select "Run"). Let Vidalia load.
If Vidalia doesn't work, run the "start-tor-browser" file at the top level of the extracted directory.
Ensure that the port is 9150 (it usually is). If you're not sure, go to Edit>Preferences>Network>Settings and check that the opened Firefox window is connected to a SOCKS v5 proxy on port 9150. If not, make note of the port and use it in place of 9150 in the rest of this post.
If Firefox was opened, close it. You don't need it for this.

Setting Tor up for your Bitcoin client
Bitcoin-QT

Ensure Vidalia is running
Download Bitcoin-QT, and extract
On your Debian command line, run sudo apt-get install libqtgui4
Go to the bin folder in the extracted Bitcoin, choose the 32 or 64 forlder depending on your system (32-bit/64-bit), double click the bitcoin-qt, select "Run"
Go to "Settings" in the menu bar, "Network" tab. Check the SOCKS proxy tickmark, set IP as 127.0.0.1, port as 9150, with version 5.

Setting it up with Electrum
Run the following lines in your command prompt:
sudo apt-get install python-qt4 python-pip
sudo pip install http://download.electrum.org/download/Electrum-1.7.3.tar.gz

If you have trouble using pip, download Electrum from here and run pip install /path/to/Electrum-1.7.3.tar.gz (Usually will be pip install ~/Downloads/Electrum-1.7.3.tar.gz)
Run electrum on the command line
At this screen, you can choose either option depending of whether or not you've already used Electrum before:

Now, use these settings for the next screen:

You may use a different default server if you wish. Try to get one that is situated close to your physical location.
If you selected "restore", fetch your seed (should look something like the one entered below) and enter it in the text field. If you had a lot of addresses in your old wallet, increase the gap limit. (that is the number of unused addresses Electrum generates before giving up on this)

Follow the remaining instructions: Safely store the wallet seed, and set a password if you wish. If the connection is working, you should see a green light at the bottom:

Setting Tor up with bitcoind
Simply run bitcoind  -proxy=127.0.0.1:9150 (or whatever the port is)


What existing businesses or products does Bitcoin compete with?

Cash. It competes with cash.

All of these things (prepaid accounts, debit cards, bank accounts, money transmitters, etc.) are sophistications built on top of cash in order to facilitate the transfer of cash from one entity to another. It's not easy to carry cash, nor is it safe to keep all of your cash in one place. It's not feasible to give cash to someone thousands of miles away. The aforementioned services make cash more, well, bearable.

Bitcoin rolls all of these services into one. The only one still possibly useful is a bank, which is merely a trusted, secure storage for a few bytes of data: a private key.

Credit cards and loans are a different concept. Those who have give to those who do not with the assumption that what was given will be returned, and then some. Bitcoin actually may make it more difficult for these kind of firms to operate because of its finite nature. That is, it cannot be created on the record books like fiat currency can. Fractional reserve banking within the Bitcoin model is possible, but there's disagreement on how it may be implemented.


Where does Coinify get its Bitcoins, and can I track their exchange rate somewhere?

I asked them in an email and they provided me with the following response:

  ... we use a Volume-Weighted Average Price (VWAP) over multiple
  exchanges (not CoinJar though as the Wikipedia article said) to get an
  average rate that reflects most of the BTC exchange rate market.
  https://en.wikipedia.org/wiki/Volume-weighted_average_price

and

  ...each order you make will be processed with the best exchange rate we
  can find at the moment.


unknown output script in a sample bitcoin pcap file

0x01 to 0x4b are the "push" opcodes. That is to say, whichever opcode you use, that many bytes are pushed to stack. This makes your script:

PUSH(0x41) 0498361908359fec5adaa624428484e7d117f36f811c7c471f4f1c7dd8184c20b32f0e2590c8d70906ebd585da2ae14ea942e4088891139379b434a26173754750 ac

0x41 is 65 in decimal, which is the length of an uncompressed public key. The last byte, 0xAC, is the OP_CHECKSIG

In short, this is a Pay-to-pubkey (p2pk) script, which were common in the early days of Bitcoin. Indeed, it leads to 1MeeajrKNiF8WtD24S4DmVwEPQYJxeh7Ef, which contains the coinbase Bitcoin from block 93641

Bitcoin also has a decodescript method which you can use via the RPC or bitcoin-cli to decode these scripts into opcodes and the addresses (if an address exists for that script)


Miners forego revenue in order to 51% attack the Bitcoin protocol by rejecting blocks

Bitcoin nodes consider the chain with the most work the best chain. Whenever a miner finds a new block that extends the best chain, they broadcast it to the network and all nodes update their chaintip as they hear about it. Miners could ignore that new blocks are found, but this would not affect any other network participants.
They could however instead provide a competing chaintip. As your scenario states that the attackers have a majority of the hashrate, (among other things), they could build a chain of empty blocks, i.e. blocks that only pay the block subsidy to the miners, but don't confirm any transactions. This would allow the attackers to collect the block subsidy, but they would no longer be collecting transaction fees, reducing their revenue by (currently) about 15%. However, the delay in confirmations would drive up the feerates of the waiting transactions, and the lost revenue would quickly increase.
Note that the attackers must continue to mine blocks in order to maintain their denial of service, or they would be out-competed by the minority eventually. So, the attacker is still spending energy cost (and has already invested in hardware). Depending on how the scenario exactly specifies "no longer bound by financial incentives", I'd surmise that the rising transaction fees would eventually entice miners to break rank from the attack.


how to set the conf file ,if my wallet is encrypted

You need to issue the walletpassphrase RPC command to unlock the wallet for some time, before you can perform send operations.


Tx Malleability: Why is the Script not included in the Signed Hash?

You are absolutely right.

The only reason why this is done, is because that is not how the consensus rules currently work. Changing it would require a hard fork, updating every node and eventually every wallet.


Will reinstalling bitcoin core give me access to the previous wallet?

I'm sorry to hear that your wallet got corrupted, hopefully you did not have too much value in there.
I'm afraid that if your wallet.dat file got corrupted and you don't have a backup there is not much you can do.
Back up the wallet.dat file and see if you can find tools to help you fix it.
Reinstalling core will not do much to help you restore a corrupted wallet file.
Can you open the old wallet at all?  Perhaps you can export the private keys that are in it?


event_base_dispatch is part of libevent, a library that takes events from network sockets, and uses them to call callbacks in your program. To find out what it's calling, you should look at the struct event_base* base variable.

bool InitHTTPServer()
{
    // [...]
    base = event_base_new(); // XXX RAII
    // [...]
    http = evhttp_new(base); // XXX RAII
    // [...]
    evhttp_set_gencb(http, http_request_cb, NULL);

There are three important calls here. event_base_new creates the struct that tells event_base_dispatch how to handle incoming connections. evhttp_new tells libevent to interpret incoming data as the HTTP protocol, instead of passing along raw bytes. evhttp_set_gencb tells libevent which function to call when new requests come in. This is where that ends:

/** HTTP request callback */
static void http_request_cb(struct evhttp_request* req, void* arg)

  Why are we renaming threads?

Debuggging and performance logging.


Unable to create raw transaction with json-rpc command

Here is the correct json:
createrawtransaction '[{"txid":"0000000000000000000000000000000000000000000000000000000000000000","vout":0}]' '{"1Ka3q3DVTBNBo2c4kVGMNzbd32RARV1FbA":12.5}'

I used 0for vout, because it has to be numeric (I don't believe hex is accepted).

help createrawtransaction

createrawtransaction [{"txid":"id","vout":n},...] {"address":amount,"data":"hex",...} ( locktime )

Create a transaction spending the given inputs and creating new outputs.
Outputs can be addresses or data.
Returns hex-encoded raw transaction.
Note that the transaction's inputs are not signed, and
it is not stored in the wallet or transmitted to the network.

Arguments:
1. "inputs"                (array, required) A json array of json objects
     [
       {
         "txid":"id",    (string, required) The transaction id
         "vout":n,         (numeric, required) The output number
         "sequence":n      (numeric, optional) The sequence number
       }
       ,...
     ]
2. "outputs"               (object, required) a json object with outputs
    {
      "address": x.xxx,    (numeric or string, required) The key is the bitcoin address, the numeric value (can be string) is the BTC amount
      "data": "hex"      (string, required) The key is "data", the value is hex encoded data
      ,...
    }
3. locktime                  (numeric, optional, default=0) Raw locktime. Non-0 value also locktime-activates inputs

Result:
"transaction"              (string) hex string of the transaction

Examples:
> bitcoin-cli createrawtransaction "[{\"txid\":\"myid\",\"vout\":0}]" "{\"address\":0.01}"
> bitcoin-cli createrawtransaction "[{\"txid\":\"myid\",\"vout\":0}]" "{\"data\":\"00010203\"}"
> curl --user myusername --data-binary '{"jsonrpc": "1.0", "id":"curltest", "method": "createrawtransaction", "params": ["[{\"txid\":\"myid\",\"vout\":0}]", "{\"address\":0.01}"] }' -H 'content-type: text/plain;' http://127.0.0.1:8332/
> curl --user myusername --data-binary '{"jsonrpc": "1.0", "id":"curltest", "method": "createrawtransaction", "params": ["[{\"txid\":\"myid\",\"vout\":0}]", "{\"data\":\"00010203\"}"] }' -H 'content-type: text/plain;' http://127.0.0.1:8332/


For anybody with common problem. It was DNS related problem.

Message from console:
01.01.14 21:06:52,881 mDNSResponder[38]: mDNSSendDNSMessage: write msg length failed -1/2
01.01.14 21:06:52,882 mDNSResponder[38]: ERROR: mDNSPlatformWriteTCP - send Broken pipe


Your address is not in the blocks being mined.  All of the coins go to the pool operator.  He then takes his cut and divides the rest among the members of the pool.  The pool usually keeps the coins in your mining account until it reaches a payout threshold or you request a manual distribution.  This is done to reduce the number of very small transactions.

So, yes, you have to trust the pool operator.  But all blocks can be viewed on the blockchain, so you can audit the results if necessary.


Bitcoin RPC. How to close wallet files opened by bitcoin?

This is a known bug and has been fixed for 0.18 which will be released in the coming weeks.


If the block is released by mining pool or miner, each peer running bitcoin wallet such as bitcoin-qt or bitcoind will verify the transactions in the block before relaying the block.

The steps are following:

Verify SHA256 block hash which is structured from version, pref_block,merkle_root,timestamp, bits, nonce and standard SHA256 padding. When the block hash is invalid or minimum difficulty level it is rejected.

The pools or miners are supposed to release blocks according to these protocol rules

One of them:

  For each input, look in the main branch and the transaction pool to find the referenced output transaction. If the output transaction is missing for any input, this will be an orphan transaction. Add to the orphan transactions, if a matching transaction is not in there already.

So there are multiple rules that must be followed for a block to get accepted and then relayed.


or I have to get the asset based private keys for each asset and sign the tx's ?

Yes, you can't sign transactions using the master private key. Sign each transaction using the derived private keys.


How to get uncompressed BTC address and private key from bit module for Python?

It looks like doing such a conversion is not well supported, nor is instantiating a private key as uncompressed unless you do so with a WIF key.

However, you can change the compressed-ness by doing:

key._public_key = key._pk.public_key.format(compressed=False)

But this requires you do to this immediately after instantiation as otherwise precomputed properties such as .address will not be recomputed.


How to run multiple node in same machine?

Your problem here is nodes are trying to use the same port Accept connections from outside.

You have to change the default port or disable listening.

-port=<port>    Listen for connections on <port> (default: 8333 or testnet: 18333)

or

-listen Accept connections from outside (default: 1 if no -proxy or -connect/-noconnect)

If you want to add another peer just simply add "-addnode:127.0.0.1:" to mycoind command.


I bought some bitcoins from a friend, I don't even have a wallet, now what?

The two most common options for wallets are:

Online wallet

You basically sign up on a website such as Coinbase(recommended if you are in the USA), or Bitstamp( recommended if you are in Europe). There's also other options like: Mt.Gox, BTC-e, BTer, etc. There you should find an option to "Deposit funds" using Bitcoin, which will show you your wallet address. That is the address where your friend should send the bitcoins to.
Pro's: the third party website maintains your wallet synced for you, everything is based on the cloud, so you can operate from any computer.
Con's: the third party is essentially in charge of your money, so you have to trust them

Local wallet.

You download a software ( official one is here). Install and run it. Once you run it, it will take a from one to few hours to download all the blocks from the network.
Pro's: you don't need to trust any third party. So, unless someone accesses your computer somehow(i.e. physically, malware,etc). You are the only one in charge of your money
Con's: if you loose your wallet file(i.e. stolen computer, damaged hard disk,etc), you basically loose your money( unless you kept backups of your wallet). You can't operate in all computers, although you could in principle have your OS installed in a memory stick, hence being portable, and at the same time risky.


How can you consolidate your personal UTXO set? (different wallet answers welcomed)

I thought this would be as simple as spending the full wallet amount to a new receiving address for the same wallet, and watch as the two inputs were combined into two outputs. However when I did this the wallet simply spent to two outputs of the same amount (minus a tiny fee) regardless

That is exactly what you are supposed to do. That it didn't work means that you did not specify the amount correctly. This could be because you either calculated the amount incorrectly or there is a software bug. I'm leaning towards the former.

If you calculated your amount by looking at a blockchain explorer, don't do that. It will result in an accurate balance calculation because of change addresses. Instead you should just use what your wallet reports back to you.

Most wallets have an option to send the maximum amount in a wallet. If your wallet has that option, use it instead of manually entering the amount. This will guarantee that your entire balance is sent to a single UTXO.


Hardware Wallets vs second mobile or airgapped computer

Hardware wallets have Hardware Security Modules which are specially designed hardware for storing and securing cryptographic keys. In general, HSMs are better than generic laptops or phones as HSMs are often validated for HSM standards like FIPS 140-2. These standards require that the HSM meet certain specifications for security, tamper resistance, etc. The use of HSMs means that the private keys can basically never leave the device.

Hardware wallets are also much easier to use than an air gapped machine and less prone to human error (e.g. accidentally allowing the air gapped machine to go online).


Sent BTC to public key instead of my address

Seems there is a little confusion here: are you talking about private keys or bitcoin address in form af a public key?

Anyway in coinomi wallet you cannot display any kind of uncompressed xPub or similar keys, so he should have sent the funds to a proper BTC address.

Otherwise he tried to send BTC to a private key but this should be impossible by protocol definition. Even if the BTM scanner somehow accepted a priv key as an input the software should recognize the issue and would stop the operation.


How are transactions and blocks relayed?

The Bitcoin protocol specification can be found on the Bitcoin Wiki. The Network wiki page has information on how information is relayed using the protocol.

Clients exchange messages over TCP/IP. With this messages, they can express their state of the blockchain and request others to send them parts they do not yet own. When you want to broadcast a new block or transaction, the inv message type is used to let people know you have the new data. Since no other client has that data already, it will request the data element using getdata. You will reply with a block or transaction message.

So basically, to reduce bandwidth usage, only an inv is truly relayed. Each node will then request the new data from one of the other nodes that broadcasted the inv.


Best Practices for hardened keys in HD wallets?

The simple (and I believe correct) answer is: use hardened keys everywhere except where a need for watching-only wallets is perceived, e.g. below the "account" level. A watching only-wallet in this scenario will be able to both create new addresses, and monitor the balance of an account.

Hence BIP-44's path is:

m/44'/0'/account'/change/index

The clear result is that each account's xpub must be exported separately from a cold wall for import into a watching-only wallet.

Almost every wallet I've looked at uses this method (the exception being Wallet32 for Android prior to v0.2.5 released May 15 2014). Reference: this bitcointalk post, which links to this spreadsheet.

edited to add: Also of some relevance is the level at which an xpub is exported. Almost every wallet which supports xpub exports does so at the account level (same reference as above), which includes both the external and internal (change) chains of a single account. (The exception is MyCelium for iOS, however this is considered a bug by the MyCelium devs.)


Is there a reason big Bitcoin companies wouldn't use only SegWit transactions?

I would like to give one of the reasons (Disclaimer: I am associated with Blockonomics).

There is no support of segwit change addresses yet in bitcoin core. There are workarounds that need to be done to achieve this; as was done by Yodice in this thread. Also to create segwit receiving address one needs to use addwitnessaddress. Lot of businesses just directly use the core wallet without doing lot of programming (there is fear of what may go wrong).

What is needed is that bitcoin core wallet works by default segwit without lot of tinkering. I hear 0.15.1 is better. Looking forward to that


I think I understand what happens during mining by I don't understand why we mine? i.e. Yeah I found a block so what? (of course miners are rewarded but why?)

Miners are rewarded for mining via the block subsidy and the transaction fees (transaction fees are paid to miners). They mine in order to earn that reward; the reward has value and therefore miners will want to get it by mining.

  How would people use this found block in a real life scenario?

Blocks are not just arbitrary data, they are part of the Bitcoin blockchain and used to store transactions that are considered permanent. They don't have any other use. The point of blocks is to have a permanent transaction history that is guaranteed by the work that miners must do to create the block.

There is no other "real life scenario" or "real life example" to give here for blocks; that's just not how they work.


Converting from Private Key to WIF, what am i missing?

The issue as suggest by Andrew was in the encode function.
After using https://www.npmjs.com/package/wif everything worked perfectly as intended.


Basic question about transaction verification

My question is, if that is the case, why can’t the verification only check against transactions signed by Alice, why does it have to check against the entire blockchain?

A node has no concept of who controls certain outputs. So there is no way to 'check all of Alice's outputs', how would the node be able to ascertain which outputs belong to her?
Rather, the normal operation of a node is to check all transactions, to ensure that no transaction has spent coins that were previously spent (and to check that new coins aren't being created against the network's rules, etc). In doing this check, the node creates an index of unspent transaction outputs (UTXOs), which it will use to help check validity of new transactions.


Do all Cryptocurrencies uses same Public key Cryptography algorithm?

Not necessarily.

A cryptocoin can use whatever asymmetric algorithm they choose, and I'm sure some have tried different things, but ECDSA has a big advantage: public keys are generated from private keys.

With asymmetric algorithms like RSA, public and private keys are both generated together.  With ECDSA, you choose a random number (within certain limits), and that is your private key.  Now all you have to do is calculate the corresponding public key from your private key.  This makes new address generation quick, and computationally inexpensive.  It also allows for schemes such as BIP32 HD Wallets.

Also be aware that ECDSA can use the same algorithm using different elliptic curves.  Bitcoin uses secp256k1, but other curves exist as well.

In the end, it depends on the currency.  There is so much diversity nowadays, I doubt very much that they all use the same algorithm and curve.


How does Bitcoin Core know the progress of blockchain without connecting to peers?

The progress number is the ratio between the total number of transactions in the active (validated) chain, and the expected total number of transactions at the current point in time. The latter is estimated based on statistics that are hardcoded in the Bitcoin Core source code, and updated every major release.

For example in version v0.19.0, the source code, you find:

chainTxData = ChainTxData{
    // Data from RPC: getchaintxstats 4096 00000000000000000005f8920febd3925f8272a6a71237563d78c2edfdd09ddf
    /* nTime    */ 1569926786,
    /* nTxCount */ 460596047,
    /* dTxRate  */ 3.77848885073875,
};

Which implies that at timestamp 1569926786 (Tue Oct  1 10:46:26 UTC 2019), the total number of transactions in the chain was 460596047. After that point in time, 3.7785 transactions per second are expected.

The total number of transactions at present is then estimated as:

If last_block_time < nTime, (current_time - nTime) * dTxRate + nTxCount
If last_block_time > nTime, (current_time - last_block_time) * dTxRate + last_block_total_tx_count