What prevents Dash miners from refusing to pay to masternodes? I struggle to understand the repationship between Dash miners and masternodes. The proposition is that masternodes provide additional services to the network and automatically get paid a part (45%) of the block reward. What I don't understand is how this share is enforced.

From the Dash whitepaper:

  When mining on the network, pool software (websites that merge the
  efforts of individual miners) use the RPC API interface to get
  information about how to make a block. To pay the Masternodes, this
  interface must be extended by adding a secondary payee to
  GetBlockTemplate. Pools then propagate their successfully mined
  blocks, with a split payment between themselves and a Masternode.

What prevents miners from simply ignoring the masternodes and assigning 100% of block reward to themselves?

Edit: from Dash documentation:

If a miner tried to take the entire block reward for themselves or tried to run an old version of the Dash software, the masternode network would orphan that block, and it would not be added to the blockchain.

But the question remains: what does it mean for a masternode to orphan a block?

I believe the block reward is split at the time of the block generation and this means that in order for the block to be valid it must send 45% to a masternode.  As all masternodes are aware of each other on the network (need to be online 24/7 for over a week) and their receiving address (need 1000 Dash in an address at the node online) so they can each verify if the correct distribution has been made and thus is a valid block.  Further info on Masternodes

If the miners try to take 100% of the reward the masternodes would not accept this as a verified block and thus would not allow the chain to be broardcast through them to other nodes.

This is the same way as how Devcoin works where % goes to the miners and % goes to the devtome distribution for work done.  The miners in devcoin have no say over the distribution of the shares only that it is part of the block that they can mine and read the distribution from a receiver file uploaded each month for the next round of blocks distribution.

As devcoin's model was tried and tested as was one of the earlier coins I think dash works along the same lines from looking at the code and blockchain.

https://explorer.dash.org/tx/b8f8024bb84340a0473faffa1f7d41e8b182f763ae5e876f0448d8799cb5d919 is the transaction for the generation of 911503 block

Here the two outputs are set and the distribution is made to each receiver of the % share.  The miner does not have the ability to control these outputs from the original generation of the block as far as I am aware. Would be like in bitcoin someone trying to verify a block that has generated 75 bitcoins in the block. It is just not possible to get this block accepted by other nodes as they would all reject it. As would the master nodes and other miners in the Dash situation.

Hope this helps and if anyone knows differently please feel free to explain where I am wrong, always keen to learn more :)


Which coins offer a 2 factor authentication feature built into the blockchain without a centralize authority? Which coins have the ability to offer a 2 factor authentication feature where it requires a secondary approval mechanism in order to spend from an address?

Have a look at byteball (http://byteball.org). It supports n-of-m wallets out of the box which can be used to implement a basic 2FA mechanism (2-of-2 with your desktop and your smartphone, for example.)

It also has a chat mechanism built in, which can be used to communicate between the devices and which would probably enable you to do what you intend.

There are a number of other interesting features listed at the web site.


How does a new block get distributed I understand how a new block gets created, and verified by the miner that created it.

But then, does it advertise this new block to near nodes? And how do these nodes go about verifying this? Do they stop mining their own blocks?

How do you prevent from other nodes stealing the new block and pretending its their own? (I guess the transfer included with their own address prevents this?)

I understand there can be multiple branches at the same time, and eventually one survives, but how is it prevented that multiple branches keep living for an extended period?

When a node discovers a new block, it will send an (unsolicited) inv (inventory message) to announce the new block to its peers. The peers should then respond by sending a getdata message requesting either the header, or the complete block.
The Developer Reference describes the exchanged messages in more detail.

The nodes will then check the header, and each included transaction for adherence to the consensus rules. Most likely they will immediately start mining new empty blocks on basis of the header (as they don't know which transactions are still unconfirmed), then switch to mining a non-empty block once the received block was validated.

Each block includes a transaction that sends the mining reward to its miner. Other nodes cannot change this transaction as the block wouldn't be valid anymore. See What is the coinbase?

When two blocks 1A and 1B are found at the same time, each chain-tip will be considered valid by a portion of the network. Once a new block 2 is found, it can only extend one of the two chain-tips (here 1A→2A), thus distinguishing one of the two chain-tips as part of the chain with the most work. As nodes hear about this new block 2A, they will discard their stale chain-tip 1B and reorganize to "longest chain" 1A→2A.
As it is unlikely that any chain building on 1B will ever be able to overtake the 1A→2A chain, miners would be wasting their power to continue to work on the obsoleted chain. Thus, the network is strongly incentivized to converge on the one chain with the most work.


Where to find the blockchain on Bitcoin ABC? So if I'm running a full node on Bitcoin ABC, where can I find the file or files which contain the blockchain when it is being downloaded?
The folder in Program Files is too small, I think, to contain the blockchain.

As per the documentation https://github.com/Bitcoin-ABC/bitcoin-abc/blob/master/doc/files.md

blocks/blk000??.dat: block data (custom, 128 MiB per file); since 0.8.0

These files should be in C:/Users/(username)/AppData/Roaming/Bitcoin which is the standard app data directory.


Can people associate one blockchain address with another? I am using blockchain wallet to store some BTCs. Blockchain allows us to create multiple addresses as such:

If I give two different addresses in the same account to someone, will he be able to identify that both of the addresses belong to me?

For example, without the image above, if I tell you the addresses:

17bbyAreAzGhenHspBCC6uDmUvqpbHWDF7
12oVDoEA2DFX84LbVPZ3ZXA7U67JLFmWzX
1GQME6s1AmPPEYWz2KSuKsCsPp5DDZTCRY
1Ptxf11p5ZgM4UB7kSSZJ2y68gVPsgUHin
13v5W1QN1uR7ndzvfN3JAnVa8wHJcGHhTQ
1B9j5KLD1mXRcbDDYRxSXn1SwU1BtCZfZ

Will you know that at least two of the addresses are owned by the same person?

Edit: I have reorganised this post, but it has mostly the same information.

Leakage falls roughly into the following categories:

hacking of the server that stores your data,
transfer patterns
currency patterns
weak random numbers
well known addresses
voluntary disclosure

If there has never been a transaction on a particular address, and the server has no been hacked, there is no information at all about that address. It is not even possible to verify if someone has that account or not. The only thing you can do is verify is if it is a valid address or not. In fact, it is possible to generate an address on a computer that is not on the internet at all.

Once an address RECEIVES bitcoin, it is possible to see (from the blockchain) where (the address, not physical location) the money came from, directly and indirectly and all other transactions relating to those addresses.

Some addresses are well known, so if you get your money from mtgox, or a gambling site, this will show.

If the transaction is a round number it may be possible to determine the currency with a reasonable amount of confidence. For example if I see a transaction for 350.877193mc right now, I would expect that someone paid US$100 for it at the mtgox exchange rate, rather than Canadian $119.

If the account was generated with weak random numbers, it may be possible (though difficult) to determine information about the computer used to generate it (it would be equally possible to determine the private key and steal the funds).

If money gets moved through several accounts very quickly, then I can deduce with pretty high reliability that all the transactions are under the control of the same person, or that there is an automated system involved.

Usually, if money gets sent in one transaction to more than 2 destination accounts, it's pretty likely that all destination accounts (and probably the source account) are controlled by the same person. The same applies (a little less reliably) if ALL the funds of a particular account are sent to the same place.

Regular "purchase" transactions consist of money from one (or possibly 2) accounts going to exactly 2 destinations - one of the destinations being the "change" (which may or may not go to the account that it came from).

if a third party that keeps your account gets hacked or the like.

voluntary disclosure is just you publish the address on your blog or the like.


Is it possible to do a 3-of-5 OR 1 multi-sig for backup purposes? I'd like to create a multi-sig wallet where I can freely create transactions, but I want to give keys to trusted friends/family + a safety deposit box so that if I hit my head and forget my password, or I die, then the trusted people can recover my coins.

Is this something Bitcoin currently supports or plans to support?

Yes, this is possible. You can construct a script such as:

OP_IF
    <key1>
    OP_CHECKSIG
OP_ELSE
    OP_3
    <key2>
    <key3>
    <key4>
    <key5>
    <key6>
    OP_5
    OP_CHECKMULTISIG
OP_ENDIF

This will allow key1 to freely spend the coins, but if a signature from key1 is not present it also allows any 3 of the keys2-6 to spend the coins.


Creating a raw transaction using Bitcoin Core v0.10.0 bitcoin-tx / createrawtransaction I'm trying to create a raw transaction using Bitcoin Core v0.10.0 (on Windows 7 x64, and with txindex=1 optioned).

Bitcoin Core v0.10.0 comes with a new Bitcoin-tx executable utility. The help menu is as follows (under Windows 7 x64):

Bitcoin Core bitcoin-tx utility version v0.10.0

Usage:
  bitcoin-tx [options] <hex-tx> [commands]  Update hex-encoded bitcoin transaction
  bitcoin-tx [options] -create [commands]   Create hex-encoded bitcoin transaction

Options:
  -?                      This help message
  -create                 Create new, empty TX.
  -json                   Select JSON output
  -txid                   Output only the hex-encoded transaction id of the resultant transaction.
  -regtest                Enter regression test mode, which uses a special chain in which blocks can be solved instantly.
  -testnet                Use the test network

Commands:
  delin=N                Delete input N from TX
  delout=N               Delete output N from TX
  in=TXID:VOUT           Add input to TX
  locktime=N             Set TX lock time to N
  nversion=N             Set TX version to N
  outaddr=VALUE:ADDRESS  Add address-based output to TX
  outscript=VALUE:SCRIPT Add raw script output to TX
  sign=SIGHASH-FLAGS     Add zero or more signatures to transaction
      This command requires JSON registers:
      prevtxs=JSON object
      privatekeys=JSON object
      See signrawtransaction docs for format of sighash flags, JSON objects.

Register Commands:
  load=NAME:FILENAME     Load JSON file FILENAME into register NAME
  set=NAME:JSON-STRING   Set register NAME to given JSON-STRING

Using Windows CLI, I'm running into issues with createrawtransaction as it's not parsing the command the same as it does in the Bitcoin-QT console window.

bitcoin-cli createrawtransaction [{"txid":"dbdc2e2c7f143af70c5e7e8725f55d226b3c058d7bf34a303091b3c6a514848c","vout":1}] {"1BCi1L25GC9hUSvtSyGjmEvSyywoYubk4P":0.00011}

Gives error: Error parsing JSON:[{txid:dbdc2e2c7f143af70c5e7e8725f55d226b3c058d7bf34a303091b3c6a514848c,vout:1}]

Likewise, the bitcoin-tx utility won't work with this:

bitcoin-tx.exe -create in=dbdc2e2c7f143af70c5e7e8725f55d226b3c058d7bf34a303091b3c6a514848c:1 locktime=0 nversion=1 outaddr=2000:1BCi1L25GC9hUSvtSyGjmEvSyywoYubk4P outscript=0:687474703a2f2f676f6f2e676c2f7869556243555

How can I create a raw transaction using Bitcoin-cli and bitcoin-tx?

For the first command, you need to include the JSON in single quotes, like so:

$ bitcoin-cli createrawtransaction '[{"txid":"dbdc2e2c7f143af70c5e7e8725f55d226b3c058d7bf34a303091b3c6a514848c","vout":1}]' '{"1BCi1L25GC9hUSvtSyGjmEvSyywoYubk4P":0.00011}'
01000000018c8414a5c6b39130304af37b8d053c6b225df525877e5e0cf73a147f2c2edcdb0100000000ffffffff01f82a0000000000001976a9146fe8102ebe0fccb56de43ec82601ba16c68496af88ac00000000

The bitcoin-tx utility uses a shorthand that is deployed in the bitcoin unit tests. This example might help you use this command:

$ ./bitcoin-tx -create in=0fb9df5614be8b33be0434ce4062750d83f1b7ce05cc1296604f82eb9abf802b:0 outscript=0.00159999:"DUP HASH160 0x14 0x6793a38f79b8cd51dbb6face6dc75a4af5c1bf29 EQUALVERIFY CHECKSIG"
01000000012b80bf9aeb824f609612cc05ceb7f1830d756240ce3404be338bbe1456dfb90f0000000000ffffffff01ff700200000000001976a9146793a38f79b8cd51dbb6face6dc75a4af5c1bf2988ac00000000

The code for parsing the scripts can be found here. However, I find just looking at some examples in the unit test data to be helpful as well.


How does the lightning network handle changing IPs? What happens if suddenly my IP/Onion address changes? Will that be a problem for the lightning network? Or could my node just simply update the network graph as long as its public key stays the same?

If your IP address changes, you reconnect to the network and broadcast a new node_announcement message containing the set of your node's reachable addresses and an updated timestamp. The node's public key identifies the node  and all of its channels and may not change. All other information in the node_announcement message can be changed.


Why does all cold/offline storage setup require three steps? I was reading about cold/offline storage and from what I have seen all clients seem to work the same. Requiring you to create the transaction on the online computer, getting it to the offline computer and signing it, then getting it back to the online computer to broadcast, but I don't get why? It seems to me you should be able to make this in two steps and it would also make it more secure as data only ever have to flow in one direction. You create and sign the transaction on the offline computer then you get it to the online computer to broadcast. So why is it not implemented like this in clients?

Building the unsigned transaction requires the input data(transaction IDs, vout, values), and is also good practice to check the network fee climate prior to setting a fee in the transaction you are building.
Technically yes you could do it in two steps but it would be considered for advanced users only and still prone to typos or other errors during the input data entry.
Related repository of mine that lets you skip step 1 and do it in 2 steps if you choose. (NOT A RECOMMENDATION, EXAMPLE ONLY TEST SOFTWARE USE AT OWN RISK) https://coinables.github.io/coldsigner/


Sale and Purchase Transaction Limits Is there any limitation on the monetary size of transactions to be paid through BitCoins? I conduct a consultancy business where payments from clients can vary between about $5 for White papers to $15,000 for a major consultancy assignment fee. I have not been able to find out this information from the website.

There is no technical limitation. However, to perform a $15,000 transaction, you need $15,000 worth of Bitcoins. There are times when it's hard to acquire that many Bitcoins without moving the market in unfavorable ways. It's worse if you need to cash out. However, if you're willing to buy and sell the Bitcoins slowly or under favorable market conditions, the transfers are not a problem.

$15,000 is not a huge problem right now. $300,000 definitely is. Just remember, if you have to buy bitcoins with dollars and then the other party has to sell them for dollars (or another currency), you'll take a sextuple transfer hit. You'll pay two half-spreads plus two conversion fees. Then, as you buy, you'll move the market up. And as you sell, you'll move the market down. This is a huge issue with Bitcoin today. Just the spread and conversion fees add up to about a 2% loss, assuming prices don't change -- that still beats credit cards.

Bitcoin transaction fees for transferring Bitcoins are based on the size of a transaction in bytes, not the number of Bitcoins transferred. What makes a transaction "expensive" (though we're usually talking a few pennies if even that) is having to "gather" funds from a lot of sources or "scatter" funds out to a lot of different destinations. So your $15,000 transaction will likely cost less than a penny.

So in sum, moving the Bitcoins from one account to another will probably be less than a penny. But in most applications, you have to factor in the cost of buying Bitcoins on one end and selling them on the other.

In the most recently-mined block at the time I wrote this answer, there was a transfer for about $16,000 worth of Bitcoins. The transaction fee was about a quarter of a penny. And currently you can process transactions without paying any fee if you're willing to wait an extra 30 minutes or so. (Because many miners don't care about transactions fees and will include any valid transaction so any valid transaction will get into a block eventually.)


Why does vanitygen ban certain letters on testnet? I'm guessing that vanitygen is more strict or has different rules than production's  Base58 rules.

Why are some of thse names marked not possible?

C:\vanitygen>oclvanitygen -k -o gpukeystestout.txt -i -f gpukeystest.txt  -T
Prefix 'mdemo1' not possible
Prefix 'mcoin' not possible
Prefix 'mBITname' not possible
Prefix 'mBITclear' not possible
Prefix 'mBITnic' not possible
Prefix 'mbotarmy' not possible
Prefix 'mdmzlist' not possible
Prefix 'maker7' not possible
Prefix 'makerofthings7' not possible
Prefix 'meventvwr' not possible
Prefix 'mdmzadmin' not possible
Next match difficulty: 5908459 (15 prefixes)

The rules are the same, but the available range is different. In the testnet the address prefix is 111 (https://en.bitcoin.it/wiki/List_of_address_prefixes).

To deduce the address you write in base58 the prefix concatenated with a 160 bit (20 bytes) hash of the public address and a checksum of 4 bytes (https://en.bitcoin.it/wiki/Technical_background_of_Bitcoin_addresses). This makes a total of 25 bytes.

With a 111 prefix you have all the numbers between 111*2^(24*8) and 112*2^(24*8)-1. In binary form you have values from

1101111000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
to

1101111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111

which is 111 (in binary 1101111) and all the possible combinations of the hash and checksum values.

If you write the numbers from 111*2^(24*8) to 112*2^(24*8)-1 in base58 encoding (https://en.bitcoin.it/wiki/Base58Check_encoding) you have the range from:

mfWxJ45yp2SFn7UciZyNpvDKrzbhuzkU7H
to
n4rZHAPGXCu8bYchjzJhK3V7VVredELJRc

All your proposed addresses are below the first possible one.


How do I query a remote bitcoin node like RPC? I know how to query the blockchain stored on my machine programmatically using bitcoind commands. Is it possible to do the same on a public node?

For example, is it possible to send “getblockcount” over the internet to bitcoinstats.com, hard-coded in the bitcoin source, or to inductivesoul.us, found in the bitcoin.it wiki? What are the steps to do so?

Edit

The quick answer is:

No, you cannot use bitcoind commands.
You have to communicate with a remote node using TCP.
You have to use a different set of commands found in the Protocol Specification.

Excellent question, and welcome to the community!
Short Answer
Maybe.
Long answer
Yes, you can send queries to other nodes on the Bitcoin network. Note that these aren't RPC calls, but Bitcoin's underlying communication protocol. That means that all of the calls will be a little different, and some of them won't exist.
Examples:

There's no equivalent to getblockcount in the underlying protocol. Instead, you can connect to a node and listen for its version message, and look at the start_height field.

Instead of getrawmempool, you use mempool.

Instead of getpeerinfo, you use getaddr.

There's no equivalent to stop, because that would be stupid.

Also, if you're trying to query other nodes on the network, one of these libraries will be very helpful:

Python: http://protocoin.readthedocs.org/en/v0.1/index.html
(Use protocoin.clients.BitcoinClient)
Java: https://bitcoinj.github.io/
(Use Peer.sendMessge)
Go: https://github.com/btcsuite/btcd/blob/master/wire/README.md

(If you're not using one of these languages, leave a comment.)


How does bitcore-node get its data? I'm trying to understand how does bitcore-node, the javascript implementation of Bitcoin protocol, get its data? Can it connect to Bitcoin Core, the original C++ implementation of the Bitcoin protocol, or does it have to connect to other bitcore-nodes ?

A Bitcoin blockchain indexing and query service. Intended to be used with as a Bitcoin full node or in conjunction with a Bitcoin full node.

From the first line of the README. It’s an out of date wrapper on Bitcoin that’s 3 years old at this point and would be inadvisable to use for anything.


What are the minimum sizes for transactions and blocks in Bitcoin? I have gone through many research articles but couldn't find out what the minimum sizes of a transaction and a block are.
Is there any reference where I can find an answer to my question?

There is no minimum size restraint on blocks and transactions. However, due to the nature of blocks and transactions, there is a practical minimum.

The smallest transaction I can think of is 61 bytes. It is a transaction that spends an OP_TRUE anyonecanspend output and creates 1 OP_TRUE anyonecanspend output. The smallest block I can think of is 146 bytes. This is the 61 byte small transaction + 4 bytes for block height in that transaction + 80 byte block header + 1 byte for transaction count.


Create a non-SegWit address in electrum wallet I am trying to get along the electrum wallet command line in ubuntu. However, my exchange only accepts withdraws to canonical non-SegWit addresses (i.e. it only generates with a "bc1" prefix). Is there a way to specifically specify such an option when typing electrum createnewaddress?

I don't see any arguments in https://github.com/spesmilo/electrum/blob/b2be29b508deb310631cacfb51bb1561bce75ff9/electrum/commands.py#L795 to specify the address type similar to address_type used in Bitcoin Core's getnewaddress

As sipa also mentioned in the comments, "bc1" prefix is used for segwit addresses

I think Electrum uses the default address type of wallet for creating new address which is decided while creating new wallet. So you can resolve this issue by creating a new wallet and select appropriate address type.


How to tell if a file is a Bitcoin wallet? This question is very similar to this one ("Identifying wallet file among soup of recovered .dat files"), but slightly different.

I ran photorec and ended up with a bunch of files. Per this answer, I ran file and found one that had the exact description mentioned: Berkeley DB (Btree, version 9, native byte-order)

Can I easily tell if this is a bitcoin wallet file or just some DB file used by another application? It sounds like photorec can't find the EOF for these files, so mine is probably larger than the original file was. Are there any tools that might help me here?


Bitcoin Nodes actions I have read the wiki page and I would like some further and more technical(if possible) confirmation for a few things.
A bitcoin node is a user which is connected to the network through a client. This node can perform transactions, try to build a block inside a mining pool, or just exist in the network. Are there any further actions for a node?
If a node exists inside the network how can he verify the transactions?
Furthermore is there a paper or something that explains things in a lower level of how exactly the system works in case of transactions and mining? I do not want a description but something more technical.

A bitcoin node is a user which is connected to the network through a client. This node can perform transactions, try to build a block inside a mining pool, or just exist in the network. Are there any further actions for a node?

Nodes also relay blocks and transactions to other nodes. They also validate incoming blocks and transactions and keep track of the current, longest valid blockchain. That's pretty much it.

  If a node exists inside the network how can he verify the transactions?

There are a set of mathematical rules that determine if transactions are valid. The nodes check the transactions against those rules. If they meet the rules, they are valid.

  Furthermore is there a paper or something that explains things in a lower level of how exactly the system works in case of transactions and mining? I do not want a description but something more technical.

Almost every question you can think of is answered, in technical detail, somewhere in the Bitcoin wiki.


Transfer incomplete and unspent Im hoping i could get some assistance, im a newbie to cryptocurrency but will try my best to outline my Query,

I have transferred 0.06685156 BTC (incl. fees) from my Coinjar cash account to my Exodus Bitcoin cash Wallet 1HL3xwinsGfnNmTPsMrtzGgL3fud9pWDv1 on the 15th of November 2017.

It has now been 6 days and the funds have not yet come up on my Exodus Account.

I have checked on the blockchain but dont really understand what im looking for, i note this is showing up as  unspent, how can i fast track this particular transaction or what other options do i have.

Im happy to transfer a reasonable fee in BTC if someone can either clear this on my behalf  or provide a step by step guide for me to do it.

Transaction ID:
2d88911d1823c32ecd4dc951f87a830b680118f5b50c77fbb9b60fd02d22b83e

many thanks in advance

I checked your tx on blockchain.info and the transaction is there. If you are 100% correct that the receiving Exodus address is correct then the transfer went through.

First recommendation I have is to try and manually refresh you Exodus account. Follow the steps in the link below and let me know if this solves the problem.

http://support.exodus.io/article/76-my-wallet-balance-is-not-correct


Use Stolen Private Key? If only my private key were stolen, could it be used?

Without knowledge of the corresponding public key or address, can one spend BTC with only the private key?

I know you can derive the public key from a private key, but if an address has never been spent from  and change is never returned to the same public key, the public key will remain unknown, thus how could one exploit knowledge of a private key alone?

EDIT:  yes, i now realize this is a pretty bad question.  i now know that with just a private key, an attacker can calculate the public key and Bitcoin address and thus spend any stored coins.

Yes.

The private key is used to send from an address.
The public key is used to send to an address.
The public key is generated from the private key.

So if you have the private key you have full control over an address.


How does merged mining work on a technical level? In bitcoin, miners hash the header twice with the SHA256 function. This header consists of the fields listed below, as described by this question.

version
previousHashBlock
merkleRoot
time
difficulty
nonce

This header data only applies to one chain. I don't get how we can mine on two different chains, as their merkleRoot and their previousHashBlock are totally different? We obviously can't have the same transactions on both merkle trees since we are talking about two different cryptocurrency chains with different transactions. So how do some pools manage to do that?

The question "How does merged mining work?" explains the broad concept of merged mining, but I'm looking for specific technical details. A byte-by-byte description of how merged mining works would be very helpful.

There's actually a very good detailed specification on the bitcoin.it site.

Essentially, what it comes down to is that there's some data inserted into the coinbase transaction of the parent chain. So, assuming, for example, that Bitcoin is the parent chain and Namecoin the child chain, anyone merge-mining would be using a coinbase transaction in Bitcoin that has a particular script that looks like this:

4 bytes magic (0xfa, 0xbe)
32 bytes hash of auxPOW header
4 bytes merkle size
4 bytes merkle nonce

For now, note that the 32 byte hash of the auxPOW header is the important thing. We'll get to explaining what that is later.

The actual block submitted to Namecoin is actually slightly different. It has a few extra fields like:

Bitcoin's coinbase txn
merkle branch (essentially an SPV proof) of the coinbase txn being in Bitcoin's block
Namecoin's previous block hash

This block is called the AuxPOW block and is actually what gets submitted to the Namecoin block chain. Now, what's to stop anyone finding a block on Bitcoin and submitting the block to Namecoin by adding this extra data? This is where the hash of the AuxPOW in the coinbase transaction of Bitcoin is important.

The AuxPOW hash can be computed ahead of time and must be included in the coinbase transaction of Bitcoin in order for Namecoin to accept it. Thus, anyone merge-mining must be aware of the Namecoin blockchain as they're looking for Bitcoin blocks. Otherwise, Namecoin doesn't accept blocks that just have data added afterwards. The Proof-of-work on Bitcoin already has previous Namecoin block information in the coinbase transaction, tying the two chains together.

merkle size and merkle nonce are 1 and 0 if you're merge mining only 1 other chain. These two variables were set up so that you could merge-mine more than 1 other child blockchain, but it's actually broken. There's a workaround described here.


What is the reason for using PoW in bitcoin? As we know bitcoin uses Proof of Work Concept and it introduces never ending long block chain and some other issues. Why is it not designed in a way to use consensus algorithms what ripple uses? What is reason for proposing the Proof of Work Concept when implementing the Bitcoin? Is there any special reason? or Is it a mistake happened when designing the Bitcoin?

Why is it not designed in a way to use consensus algorithms what ripple uses?

A consensus algorithm requires that you can trust contributing nodes. Otherwise, you're open to a Sybil attack, where an attacker creates many dummy nodes. Ripple was built on the idea that you can establish trust in some entities, trust that they will not collude to defraud you.

Proof of work, as Bitcoin uses, has some advantages over this: proof of work does not require trust of any kind, and it doesn't require that you know anybody's true identities. Instead, you trust the proof that someone put a lot of work (time/money) behind establishing a block. Since Bitcoin aims to be a completely trustless, decentralized network, that allows some anonymity, it makes sense to use proof of work in it.

Of course, proof of work also has some disadvantages: a slow block time (say, a minute or more, to keep the orphan rate low) is necessary, which slows confirmations. It can be overtaken by someone controlling >50% of the network's hash rate. And it results in work just for the sake of work, wasting electricity. Also, while ideally each user/node would have an equal share (just their own CPU), ASICs (and their predecessors) instead focus this control in more-centralized miners.


Would my ISP consider my Bitcoin client to be a server? I was reading about Google's Fiber installations, with first deployment in Kansas City.  There's a controversy where the terms of service restricts what services can run on their Fiber network.

Some relevant items:

http://www.dslreports.com/shownews/Kansas-City-Google-Fiber-Rallies-Take-Off-Running-120594

"Can I run a server from my home?

Google Fiber is intended as a residential Internet service. Our Terms of Service prohibit running a server."

http://fiber.google.com/legal/network.html

Would running the bitcoin node on Google Fiber be considered to be a server, and thus prohibited?

Google refers to server as a business grade hosting with a very different usage profile then personal use. This is not intended to catch someone using home server, but if a small business tries to power their rack of servers, then there is grounds for termination.

The Fiber Services are intended for the personal use of you and others with whom you share your residence (including, within reason, guests who are visiting you). You agree not to resell or repackage the Services for use by people other than those with whom you share your residence. If you wish to use the Google Fiber Services to provide Internet service to others, you must enter a separate agreement with Google Fiber that specifically authorizes you to do so.

Google Fiber Terms of Service

Here are some common-sense rules that you should keep in mind when using services provided by Google Fiber:

Your Google Fiber account is for your use and the reasonable use of your guests. Unless you have a written agreement with Google Fiber permitting you do so, you should not host any type of server using your Google Fiber connection, use your Google Fiber account to provide a large number of people with Internet access, or use your Google Fiber account to provide commercial services to third parties (including, but not limited to, selling Internet access to third parties).

Learn about Google Fiber terms of service


How to create the same (2 of 3) multisig adresses as electrum's multisig wallets with createmultisig? Looking to create 2 of 3 multisig addresses with the electrum console with public keys (not the master public keys):

electrum createmultisig 2 '["1st public key wallet 1", "1st public key wallet 2", "1st public key wallet 3"]'

This will out put an p2sh address and a redeemScript. The address however only match the first address in an electrum 2 of 3 multisig wallet if public keys are entered in the right order (that has a one in six chance).

Electrum's 2 of 3 multisig wallets have consistent p2sh addresses no matter what order the master public keys are entered. How can createmultisig be used to be consistent with electrum's multisig wallets?

Edit: The suggested answer is the addmultisigaddress command from bitcoin-core (as I understand it correctly), thank you for the suggestion. However the question was how to do so with Electrum console (if possible).

The question is how to (re)create the correct first p2sh address of Electrum's multisig (2 of 3) wallet with master public keys as input, with only the first public keys of each of the master public keys and be consistent with Electrum's multisig (2 of 3) wallet all the time.

Edit2: An example with actual master public keys and there public keys:

Master public key a: xpub661MyMwAqRbcFRS9DDMPDGhicAnYcsELaWwWSviE3nETgBBW6P6FqXCxDobD9h1BqXbjbMEsXkeXyrLUmxANvBw9hi4jxZKjLDyZk3hK7nT
a's first public key a1: 03722ef79a70b43843c642f3495d2b9b8a6403189d52a04ecac652c133f7940fed

Master public key b: xpub661MyMwAqRbcEqNp5KidkrqspVy5HmMTwuQguSa8LSu6WWDdYMMD13appqVrMgAZyc5FKxSnxuTqNoT2j9PYtFtF67MUNBEzifV6vnd5qW2
b's first public key b1: 03f9652bfbbfb426eb2011db774c97866e00effdf954cc225807f89b23150dda3a

Master public key c: xpub661MyMwAqRbcEpBbahsh3vPcooVMbEfKAWCx7VNAyGokuShDN2FocJEa7mkcSAkWbkhbewN9TBW9AkoSJPGJoktCXZL98BGTCdZaspiebrA
c's first public key c1: 03f5ce19296793c6695bfefd7ead459a3f88ef776d8fc08b470dbc749d266d519f

The electrum's (GUI) option to create a multisig (2 of 3) wallet will take master public key a,b and c in any order and give a wallet with the first p2sh address:

3HRmAEyoBwdHhdntJHFMeR8DxZyCgiaKzV

Electrum's console command createmultisig will output different p2sh address depending on the order of public keys. Trail and error will get the same p2sh address as the GUI, however my goal is to get the correct address without verifying consistently.

With '["a1", "b1", "c1"]':

electrum createmultisig 2 -o '["03722ef79a70b43843c642f3495d2b9b8a6403189d52a04ecac652c133f7940fed", "03f9652bfbbfb426eb2011db774c97866e00effdf954cc225807f89b23150dda3a", "03f5ce19296793c6695bfefd7ead459a3f88ef776d8fc08b470dbc749d266d519f"]'

    {
    "address": "3EKHKsgn2smYcpeiD6zfR9sgrEp6PrqCTw",
    "redeemScript": "522102ae1359d50bdc7d5b61c3bab9f293fc01cdab3c2b1151a7309fb2e28540d94e842102b0b20cb5e55204f63c016c3df94c3aadaed931370e49bb94097c97dff485032d2103d5196cd7f661deedb3f27fce93095554e72032c7fd26b1ddfaeac8d6f5d56d0553ae"
}

With '["a1", "c1", "b1"]':

electrum createmultisig 2 -o '["03722ef79a70b43843c642f3495d2b9b8a6403189d52a04ecac652c133f7940fed", "03f5ce19296793c6695bfefd7ead459a3f88ef776d8fc08b470dbc749d266d519f", "03f9652bfbbfb426eb2011db774c97866e00effdf954cc225807f89b23150dda3a"]'

{
    "address": "3HRmAEyoBwdHhdntJHFMeR8DxZyCgiaKzV",
    "redeemScript": "522103722ef79a70b43843c642f3495d2b9b8a6403189d52a04ecac652c133f7940fed2103f5ce19296793c6695bfefd7ead459a3f88ef776d8fc08b470dbc749d266d519f2103f9652bfbbfb426eb2011db774c97866e00effdf954cc225807f89b23150dda3a53ae"
}

In this example I got "lucky" after the 2nd try and get the same p2sh address after 2 tries of the possible 6 permutations. My question however is how to get the correct order of public keys without verifying the GUI multi (2 of 3) wallet?

See BIP45.

Electrum is ordering the pubkeys lexicographically, ie

03722ef79a70b43843c642f3495d2b9b8a6403189d52a04ecac652c133f7940fed
03f5ce19296793c6695bfefd7ead459a3f88ef776d8fc08b470dbc749d266d5
03f9652bfbbfb426eb2011db774c97866e00effdf954cc225807f89b23150dda3a

Note they're all 03, so it's 72=>f5=>f9


Multisig addresses with keys from different wallets I am learning how to handle multisig. First I created a 2-3 multisig address with all keys from my test wallet (bitcoind on server) and sent money to the new multisig address from another wallet. The transaction shows in the test wallet and I can use the unspent output.

Then I created a 2-2 address with one key from the test wallet and one key from another wallet, and sent money to the new address from another wallet.
The transaction shows on blockchain.info:

https://blockchain.info/tx/910298ae8133cc142009539298b6e2127b2c49960facd3b21470e130d07a1701

but it doesn't show in the test wallet, and the new multisig address has zero balance.

Reading this previous Q/A:

Multisig doesn't work unless all keys were generated from the current wallet?

I see that in July 2014 Bitcoin Core only showed transactions to multisig addresses with all keys in its wallet.

Questions:

1) Is that still the case?

2) If so, can I still use the unspent output and how?

Addmultisigaddress 2 [{"address/pubkey of Bitcoincore address", "pubkey of other wallet key"}] should return the P2SH address (3MWpeBDwJdk8F7fecZBZ6FHjDJVnGxpnRA) and also add 3MWpeBDwJdk8F7fecZBZ6FHjDJVnGxpnRA to the UTXOs
importaddress 3MWpeBDwJdk8F7fecZBZ6FHjDJVnGxpnRA will add the P2SH address to the wallet as WatchOnly

I'm assuming you're not running a full node, using the txindex=1 flag, so the addmultisigaddress command is what you're going to need to redeem 3MWpeBDwJdk8F7fecZBZ6FHjDJVnGxpnRA in Bitcoincore. FYI, createmultisig has the same parameters as addmultisigaddress (RPC reference) but it's returning the redeem script only; ie it is not adding the P2SH address to the UTXOs.

As mentioned already, for all multisig commands you'll need the full pubkey (hex version, starting with 0x04 or 0x02/03 for compressed). The only reason you can substitute the Base58Check address into Bitcoincore as a public key is because the software retrieves the pubkey from the wallet and substitutes it accordingly.

An alternative way to go about it is by using dumpprivkey/validateaddress to get the Bitcoincore keys required and then import the private key into the other wallet software and sign/redeem with that.

EDIT: I've tested out importing non-wallet.dat pubkeys for a multisig P2SH address and have successfully added the Tx to the UTXOs returned by listunspent, with the only difference being that the JSON return data will have spendable: false. I did it as follows:

addmultisigaddress 2 '["pubkey1", "pubkey2"]'
Take the returned P2SH address ...
importaddress 3MWpeBDwJdk8F7fecZBZ6FHjDJVnGxpnRA "TESTING" true
Wait for scan to complete
Funded 3MWpeBDwJdk8F7fecZBZ6FHjDJVnGxpnRA with createrawtransaction/signrawtransaction/sendrawtransaction (but I'm sure you can do it using the GUI
listunspent 0 will return JSON array (including 0 confirms) with an object showing redeemScript but with spendable: false
You'll need to redeem the Tx using createrawtransaction with the privatekeys passed as parameters to spend this, obviously


Multibit: Using the same passphrase for both my wallet and exported private keys I have a password-protected wallet in Multibit that I have backed up in multiple locations.

I have exported the private keys from this wallet. The private keys are password-protected using the same password as my wallet.

The password is more than 50 characters (passphrase) with words that cannot be found in a dictionary.

The wallet file and private keys file are stored together.

I don't care if the attacker can see my balance.

My questions:

How (un)safe is this?
If an attacker retrieves these files, can the attacker take a cryptographic shortcut because both files use the same password?

How (un)safe is this?

It is probably OK. Even though, in general case, you would want a different password for any different use, in your case the things you protecting are nearly the same. The wallet will hold all the "keys", and the keys along form your wallet.

Suppose you have a selection of deposit boxes in a bank. Now imagine that there are no guards in the bank and anyone can pop in and open any deposit box. Now, expand this idea, instead of a single bank you have as many deposit boxes as there are probably atoms in the universe.

A key is a pointer to one of those boxes. No passwords, no locks, just the location.

Because the wallet and keys are kind of the same stuff you can use the same passwords. But really, in a world where tools like KeyPass, can generate strong random noise, there is no excuse not to use them, and not to have two different passwords.

  If an attacker retrieves these files, can the attacker take a cryptographic shortcut because both files use the same password?

An attacker would need to get access to either of the wallet or the keys to get your money. Given access to any, means he will be able to transfer the funds elsewhere. The good news, he will need to know your password. There are no successful attacks known, that can decrypt the data without the password.


How can Bitcoin be adopted as tradeable currency pairs on Forex? There are Forex clearing-houses all over the world. How can we have a Forex clearing-house offering Bitcoin as tradeable currency pairs?

Well, the Bitcoin exchanges are a form of a forex clearing house. At the moment, however, Bitcoin is not really ready to be traded alongside all world's currencies at some more major exchanges - the big players could sway its value up and down at a whim with a fraction of what money they have. Before that happens Bitcoin still needs to grow and become more noticeable. However, there isn't much stopping someone from incorporating Bitcoin into a new forex.


Unconfimed transaction I have sent BTC to cryptopay wallet. It is still showing pending. It has been 8 hours up to now. Can you please tell me what could be the error or the problem and how I can solve the issue
Thank you

The fee specified by your send transaction could be too small for any miner to include it in a block of transactions.

Some -- possibly too much -- information about fees is here: https://en.bitcoin.it/wiki/Transaction_fees


Regrouping accounts belonging to same user I am analysing some BTC transactions for academic purposes.

As part of that work, I would like to identify users with several accounts and regroup them under a single identifier.

I have assumed that when a transaction has several accounts paying in, it is likely that it is the same person using several accounts.

Is this assumption correct or could there be other reasons for having several accounts paying into the same transaction.

First off, you should really start thinking in terms of addresses rather than accounts, especially when doing block chain analysis.  See here:  What is the difference between accounts and adresses?

You should also start thinking about transaction inputs not in terms of addresses, but rather unspent transaction outputs (UTXOs).  Each UTXO will generally have an address associated with it, but in the case of multisig, may have several addresses in a single UTXO.  So in this case, even a single input to a transaction has more than one person associated.

There are also the cases of coin mixers, web wallets, and exchanges, which often create single transactions that include many inputs and many outputs, all coming from and going to different people.

So to answer the question, no, you cannot assume that all addresses used as inputs to a transaction come from the same person.


What is the function of the payload_checksum field in the Bitcoin protocol According to the protocol specification at the Bitcoin wiki, each message header includes the  first 4 bytes of sha256(sha256(payload) as a packet checksum. I suppose this checksum is used for packet validation, but I do not see any benefit of this, as Bitcoin utilizes TCP which already has (as far as I know) full protection from lost and damaged  packets. So... why this checksum? Is it to maintain compatibility for future UDP clients?

"Full protection" is a relative term.  TCP packets include only a simple checksum, effectively just the sum of all the 16-bit words in the packet.  See RFC 793 section 3.1.  This is a fairly weak integrity protection mechanism.  The Bitcoin designers may have felt the use of sha256 gave better protection.  It may also, as you say, have been intended to provide forward compatibility for running Bitcoin over UDP or other protocols.  It may even just have been paranoia.


how does dash solve the scaling issues? I heard dash has some extra features compared to bitcoin like masternodes etc, can someone explain the subtle differences especially regarding the scaling debate

The biggest reason why Dash can scale is incentive alignment. Dash splits the block reward between the miners (45%), masternodes (45%) and the treasury (10%).

Masternodes are a special type of node with some extra requirements. In exchange for that, they get paid by the network. Because they get paid, the network can require them to run powerful machines that can handle bigger blocks than what would be possible with volunteer nodes (like what happens with Bitcoin, Bitcoin Cash or Litecoin).

Also, thanks to the masternode layer, Dash is about to release a decentralized API that will allow light wallets to connect to that layer as a class, not an individual (trusted) server. With that, it will be possible to use Dash in a completely trustless way without the need to download the blockchain, reducing the pressure to keep it small because only very specific use cases will require to have your own copy.

There are a few more improvements in the works that will all contribute towards scalability. Arizona State University recently released a paper analyzing Dash scalability:
https://blockchain.asu.edu/block-propagation-applied-to-nakamoto-networks/

As a side note, Dash also has a governance system in place that facilitates decisions around the protocol. That is not technically an advantage towards scalability, but because decisions can be made easily, roadblocks are only temporary. The decisions to go from 1MB blocks to 2MB ones was agreed by the network in less than 48h, saving a lot of time in discussions between parties claiming to represent the best interest of the network but without a real way to prove that.


When does a blockchain fork resolution happen? I understand that forks are resolved by largest proof-of-work etc. but when do the miners decide to resolve a fork? Is it a question of network consensus or does each individual miner resolve at their own pace?

Each node will usually resolve and reorganize their local chain as soon as they are made aware of a chain with more work.
If two blocks are mined at block height N, there is a fork. As soon as a single block at height N+1 is mined and broadcasted, any nodes that receive it will keep the block N that the new block builds upon, and orphan the other block as there is now one chain with more work.
This is what makes block withholding attacks possible, as an attack could broadcast several blocks at once, which suddenly present a new, longer, valid chain.


Using a dedicated phone as "hardware wallet" Is there anything inherently insecure about using a dedicated Android phone as a "hardware wallet"?
A dedicated phone implies:

a clean ROM without gapps, e.g. GrapheneOS, Lineage OS without root, etc

full phone encryption enabled

no other apps installed apart from a wallet app such as Mycelium, Breadwallet, GreenBits, Samurai, etc.

I realize that the majority of Android phones don't have (yet) a secure element like trezor or ledger devices, and that system apps might have unlimited privileges, but what are the main issues or specific attack vectors to be aware of in such a setup as compared to dedicated hardware wallets?
My understanding is that physical access to a trezor or ledger is useless if the attackers don't have the pin or passphrase and that these devices are built in such a way as to make hardware extraction of private keys impossible or financially unfeasible.
Is a comparable level of security achievable with an Android device with full phone encryption?
Also, does setting a pin code in a software Android wallet mean that the private keys are actually going to be encrypted or is the pin just for opening the UI?
Any data on which wallet apps protect the keys in a way which makes their extraction impossible without the pin code/fingerprint?
Resources

https://forum.xda-developers.com/t/guide-tweaks-android-security-hardening.1954513/

https://www.reddit.com/r/GrapheneOS/comments/bddq5u/os_security_ios_vs_grapheneos_vs_stock_android/

https://www.reddit.com/r/privacytoolsIO/comments/6kyteo/aside_from_copperheados_what_is_the_best_android/

Is a comparable level of security achievable with an Android device with full phone encryption?

Short answer: No. This doesn't mean an Android device is bad, there are less secure ways to store bitcoins. But it does have more attack vectors than a hardware wallet.

You can add whatever encryption to the phone you'd like, but ultimately if that device can connect to the internet, there is risk that some malware could be loaded to it. A hardware wallet is not at risk of this type of attack, the secure element is kept isolated from the internet.

For example, if screen capture malware is loaded onto the Android device, and it snaps a screen grab of your seed phrase, the encryption methods won't matter at all. This sort of attack isn't possible on a hardware wallet.


Quarkcoin money supply and hashing If the money supply of Quarkcoin is 257 million QRK, what will be the incentive for miners to mine 1 million coins a year?

What does it mean for the currency if almost nobody is mining it?

Also why does Quarkcoin claim that their Proof of Work hashing is more secure? How is the security of the currency increased by adding hashing functions?

It seems to me that quarkcoin is an experimental protocol. Then again, bitcoin is often looked at as an experimental protocol, and despite its performance, is still considered beta (if you are reading this and questioning that statement, go look at bitcoin-0.8.3, for example, on sourceforge, and look at bitcoin-0.8.6 (same place, most current version), as you can see bitcoin itself is plainly characterized as "beta."
Even if nobody was mining it, a decentralized protocol that is utilized for transactions would still be interesting (if for no other reason than that it would be an example of how anyone can take part in the decentralization process).  It's my sense that part of the incentive to mine quarkcoin is the anticipation that it may gain in value and thus be able to be both used more widely for purchasing, as well as its current presence on certain exchanges.  Another part of the incentive could be the feeling or sense that comes from having accomplished mining something.

This is not a recommendation of any particular cryptocurrency / protocol, just an observation - Suggest looking at main.cpp Quark for observations of difficulty settings.  Also, the, SQL for the blockchain up until Dec. 3, 2013 is here (not my site, but contains useful information): entropyextropy.com -- at entropyextropy.com/abe.sql.zip
(Information in above paragraph taken from twitter and the forum at quark.freeforums.net)
On github, see code associated with MaxGuevara titled quark

Touching on the question of how is the security of quarkcoin increased by adding hashing functions, I'm not certain that this is how security actually works. I'm of the mind that the higher the adoption rate of any particular currency / protocol type, the more it will be able to weather attacks of many varieties.
[Note: See topic=260031.1840 at bitcointalk.org]


Why check for multiple nonces despite finding a golden nonce? I'm still new at trying to understand the entire idea surrounding the mining process.
I read the following:

When mining, you are given a set of data to perform hashes on. As you
noted, this is done by manipulating the nonce and hashing each time
the nonce changes. What you really want to do is check all possible
nonces. Even if you've already found a "golden nonce" (one which gives
you a hash starting with 32 zeros), you need to keep searching for
more. There could be anywhere between 0 and 2^32 solutions to a given
block of work, so it is in your best interest to keep looking for
more. Hence, there are no stop conditions in the sense of when to stop
running your algorithm, other than having exhausted all possible
nonces (at which point, you would get more work).

Source
This confused me, because I thought that once you found a golden nonce, you can broadcast that to the network and move on. Why would you continue to check for more? Is it because if you let's say found 5 golden nonces and broadcasted all of them as you found them, you'd have a higher probability that the next block would be building off the one you found? Adding onto that, if many people find valid nonces to a block, how is the winner of the reward, and which gets included in the main chain, determined?

There's a difference between what is called a "golden nonce" in the context of the source and a valid block header hash.

To reduce payout variance, miners group into pools and share their income proportionally to their hashpower.

To determine each miner's hashpower, pools use a share system: when you are mining and find a block header of high difficulty (with lots of heading zeroes) but not high enough to be above the current target, you send it to the pool. These difficult-but-not-enough headers are called "shares".

Since finding them is way more frequent than blocks (miners often send several of them per second), no matter how small your hashpower is, it will still be taken in account at payout time even if you're unlucky. The more shares you send, the more hashpower you have, the bigger the share of the pool's income you will get.

They are not broadcast to the bitcoin network, since they would be immediately rejected there and are of no value to anyone but the miner that found them and the pool software.


Which transactions go through the SHA256 process of "trying to win the new block"? It is commonly said that a new block that is hoped to be added to the existing blockchain is filled with transactions, and together with a nonce, go through SHA256 twice, and tries to be a small enough number (with many leading 0's)
Isn't it true that each miner or mining pool, can get different transaction to fill in?    Are these transactions coming in that "are hoped to be added to this new block in about 10 minutes"?  Some transaction are chosen because they offer a good fee. And it is just up to the miner or mining pool to decide which transaction go in?  So then, can the miner or mining pool put in one transaction, two transactions, 0 transactions, or any number of transactions?
So each miner or mining pool work off a block that are filled with different transactions plus a nonce?

Yes, each miner decides which transactions to select into their block templates. Blocks must have a coinbase transaction, all other transactions are optional, but blocks are limited to 4,000,000 weight units.
Let me elaborate: unconfirmed transactions are relayed on the network by the participating nodes via the p2p gossip protocol. Each node maintains their own list of unconfirmed transactions in its memory pool (mempool). Miners generally pick transactions from their mempool to assemble block templates.
Blocks must have a coinbase transaction as the first transaction in the block, and the remaining transactions must be valid and sorted topologically. A block may not exceed 4,000,000 weight units. Other than that, miners are completely free to pick and choose the composition of their block. Blocks that only contain a coinbase transaction are allowed and referred to as empty-blocks.
It is expected that miners wish to optimize their revenue by collecting the most transaction fees possible. By default, the getBlockTemplate call uses a greedy algorithm that iteratively picks the set of transactions with the highest effective feerate until the block is full.  Miners may use the prioritisetransaction rpc call to reprioritize transactions for the block template consideration. Some miners may use custom software to build their blocks.
In effect, block templates usually overlap almost completely across miners as nodes should see the same transactions on the network (with some slight delays due to relay). However, since each miner's block template attempts to pay the block reward to themselves via the coinbase transaction and each miner has a different payout address, every block template produced by miners will be unique and no miners will ever repeat work done by another miner.
Given a block template, miners search that template's combination space by injecting random data via varying nonces, extranonces, timestamps, malleating the version field, etc. Each new combination yields a unique block header which is hashed using SHA-256d. If a resulting digest meets the target, the miner has found a new block. Otherwise, they create a new block template and start over.
Once a new block is discovered, the block author broadcasts it to their peers. Other nodes that learn about the block append it to their blockchain, update their UTXO sets, and remove the confirmed transactions from their mempools. Since the best chain can only have one block at every height, it does not make sense for an honest miner to continue mining at the old height, therefore, they switch to mining at the new height as quickly as possible.


Wallet not getting loaded with Multibit Why is it giving me this error and not receiving my bit coins?

The system cannot find the path specified ".org.multibit.file.WalletSaveException"
Cannot save wallet 'C:\Program Files\MultiBit-0.5.15\null\MultiBit\multibit.wallet'
Created wallet "C:\Program Files\MultiBit-0.5.15\null\MultiBit\multibit.wallet".
Could not load the wallet file "C:\Program Files\MultiBit-0.5.15\null\MultiBit\multibit.wallet".

Checkout pywallet. Its a python script that may be able to help you out by recovering your private key. I've had similar issues with Multibit in the past. Is your wallet encrypted?

https://github.com/jackjack-jj/pywallet


How do I pick the right cryptocurrency without becoming an expert in cryptocurrencies? I live in a country where a certain national currency is used as legal tender. I do not understand how the local money works (e.g. how the national money supply is increased), nevertheless I can easily use it in my everyday life, for example to earn wages and pay for food. One factor that makes the local currency easy to use is that there is no alternative. In most circumstances I cannot pay with another currency.

Being interested in criptocurrencies, I'm faced with a difficult choice: Which currency do I want to use? Being an ignorant fool and unwilling to educate myself on how cryptocurrencies work—

How do I choose a cryptocurrency to use (and support)?

As money, security is paramount. Bitcoin is still the safest and most proven crypto, despite what others claim. The network has the most miners, which makes attacking the network next to impossible.

Bitcoin does have a few drawbacks, but these are being fixed 1 by 1. Solutions like SegWit and Lightning Network are major advancements.

There’s nothing wrong with supporting Bitcoin as your first coin. Over time you can learn more and maybe get interested in other coins, but I find myself always going back to the original Bitcoin.

The fact that BTC was invented by an anonymous inventor and has no single leader, is also a major benefit.


Broblem for wallet blockchain privet key When I want to convert btc from my wallet blockchain, they ask me to enter my private-key. When I enter it, I am asked to enter the password for the private-key. I do not know the password for private-key.

Is there a solution?

Without more information, I see a few posibilities:

You may have a BIP38 encrypted private key.

see: https://github.com/bitcoin/bips/blob/master/bip-0038.mediawiki

I suspect that maybe you are trying to claim a paper wallet?  If so, you need to know the password, or brute force it (unlikely).

If you are referring to a blockchain.com (formerly blockchain.info) wallet, those are proprietary to them and use their own format for the keys.  Again, you need to know the password, or brute force it.

If you don't have the password to your key any longer, then there are some wallet recovery services on the internet, which are risky and take a large percentage of the balance.  You can google "bitcoin wallet recovery", and always check reviews before engaging with one of these services to check their reputation.  Even so, they may be unable to recover the password.

Barring that desperation, do not provide your private key to anyone!


Default derivation paths I'd like to know all of the default derivation paths used by both software and hardware wallets for bitcoin.  According to https://iancoleman.io/bip39/?#english, the following are defaults:

m/0'/0' (bitcoin core)
m/0'/0 (Multibit)
m/44'/0'/0' (blockchain.info)
m/44'/0'/0'/0 (Electrum, Mycelium)
m/49'/0'/0'/0 (p2wpkh-in-p2sh)
m/84'/0'/0'/0 (p2wpkh bech32)

Am I missing any?

I have not verified the validity of this, or if it's up to date, but there is a spreadsheet tracking this, which might be helpful, at https://onedrive.live.com/view.aspx?resid=584F122BA17116EE!313&app=Excel.

Summary:

Wallet                            BIP-32?   HD path

Armory (wallet 1.0) No  -
Bitcoin Core (version 0.13+)      Yes       m/0'/0'/i'
Bitcoin Wallet                    Yes       BIP-32
Bither                            Yes       m/44'/0'/0'/c/i
breadwallet                       Yes       BIP-32
Coinomi                           Yes       m/44'/0'/0'/c/i
Electrum (1.x wallet)             No        -
Electrum (2.x standard wallet)    Yes       m/c/i
Electrum (2.6+ BIP-39 wallet)     Yes       BIP-44
Hive (mobile and web)             Yes       BIP-32
MultiBit HD (BIP-44 wallet)       Yes       m/44'/0'/0'/c/i
MultiBit HD (standard wallet)     Yes       BIP-32
Mycelium for Android              Yes       BIP-44
Mycelium for iOS                  Yes       BIP-44
myTREZOR                          Yes       BIP-44
Wallet32 for Android (0.1 wallet) Yes       m/a/c/i
Wallet32 for Android (0.2 wallet) Yes       m/a/c/i
Wallet32 for Android (0.3 wallet) Yes       m/a'/c/i
Wallet32 for Android (0.4 wallet) Yes       m/0/0'/a'/c/i
Wallet32 for Android (0.5 wallet) Yes       BIP-44


Number of transactions I was having a look at the number of transactions in the bitcoin address for bitcoin.org.

I went to blockchain.org explorer. It says https://blockchain.info/address/1GwV7fPX97hmavc6iNrUZUogmjpLPrPFoE

No. Transactions    354

I have exported the CSV, and sorted it by "x" that is the number of each time they received some funds. The output I had is 365.

I am confused about these numbers. It is not possible that the total of funds received are higher in the CSV, than the number of Tx's.

Not sure what I am missing here.

By the way, I wanted to get people to donate more.

The x field is not the time that of each transaction they received. x is a date is unix epoch time and y is the number of transactions that were received during that day. Since you probably exported the number of transactions for the past year, you got 365 days of data so your count of xs results in 365. But that is not what you want, you want to sum the y values.


Crypto exchange - what do BTCUSD SELL and LTCBTC SELL mean? I just downloaded an app that forecasts the crypto market. The app seems to be nice but I don't understand the forecast interface. What does this mean?

BTCUSD SELL,
LTCBTC SELL

Does it mean that I can sell my bitcoin to someone that has dollars?

For the second, does it also mean that I can sell my LTC to someone that has BTC that is invariably buying BTC with LTC?

BTCUSD means you are selling your BTC in exchange of USD, same with LTCBTC, you are selling your LTC in exchange of BTC. That both works with spot and leverage trading settings.


How do bonds in Secure Multi‐Party Lotteries work as described in Bitcoin and Cryptocurrency Technologies book I have understood the details of it but I have a question related to claiming the bond.
We have two parties Alice and Bob and suppose the bond that Alice signs is
now if Alice reveals her value X then she will be able to get her bond money back. Suppose if Bob won the lottery then how will he get the money from Alice since she has already reclaimed her bond amount?

The transactions for revealing commitments are separate from the transactions for the lottery. Timed hash commitments only force parties to reveal preimage x of H(x). The lottery logic is carried in a separate transaction


Can I see a transaction sent to me if I haven't downloaded the whole blockchain? Last received block was 12 weeks ago, and I'm still syncing. I have moved some bitcoins to this wallet from another, but I still can't see it in my inbox after a day.

Is it because I don't have all the blocks?

You can use blockchain.info to see transactions sent to your address.  Just go to https://blockchain.info/ and enter your address in the search field.


Transaction too large error I have over 1400 small transactions in my wallet that add up to a little over 0.2 BTC. I am trying to send them, but keep getting a transaction too large error. I have tried to set a custom transaction fee, but am unable to still send. I am using Bitcoin core v0.10 on Windows. I have looked at this thread but am still unable to find a solution.

How can I combine all the tiny amounts I've received to minimise transaction fees, and do I need to?

Your scriptSig is too big! It is limited to 200 kbytes, and you've got 1400 inputs @ 0.2kbyte (best case scenario): 1400x 200 = 280kbyte.

Try using half the inputs (preferably newer inputs) to cut the scriptSig down in size.


Is it true that all the bitcoins in existence are on the blockchain (the ledge), but it just depends on who the owner (address) is? It seems that for the 18.5 million bitcoins generated, plus even the 6.25 bitcoins that were rewards just 10 minutes ago, are all recorded in the blockchain (the ledger), but it just depends on who the owner (the address) is?
And if Peter sends Mary 0.001 bitcoins, then it is just the ownership change (which address has it), all the same number of bitcoins is all recorded on the blockchain.

Rabbit holes are deep

Bitcoin's blockchain doesn't really know who owns anything.
Bitcoins don't exist as things whose ownership can be reassigned.
Bitcoins have no individual continuity.

Yes the Blockchain effectively keeps track of changes of something that often corresponds to what we think of as ownership of money. However the blockchain cannot distinguish between Alice sending 1 BTC to Bob (money changing hands) and Alice sending 1 BTC to a different address in one of her wallets (rearranging her money, no change of ownership).
Wallets can process transaction data to keep track of a set of unspent transaction outputs (UTXOs) removing outputs that have been spent and adding newly created outputs.
The total monetary amount of the UTXO set should add up to 18.5 million (or whatever the quantity mined so far adds up to).
However the identity of bitcoins is not preserved. It is only the total amounts that always sum up to the correct current money supply.
If you think of UTXO's as coins, the mined transactions effectively melt all the input coins down and use the combined molten metal to cast a new set of coins. No coins change hands, all coins are destroyed in every transaction and new coins created.
For example in the following transaction there is no way to say that certain inputs correspond to certain outputs. This is true regardless of the amounts although you can sometimes make inferences. An exchange might consolidate several of its users transactions into one bitcoin transaction  with dozens of inputs and dozens of outputs and there's no certain way to determine which inputs correspond to which outputs.
In block 669188 there is a transaction 1218…d33e. If you look at that in a blockchain explorer such as blockchair the details will be shown as
Senders

Amount
Address

0.00149566 BTC
3PxGWkwnxQ88zQw8TgBiYrH4pQxhakmN16

0.05809775 BTC
3CDcCbis6dEBeksMY8uYhWyU3EaLN6vh82

Recipients

Address
Amount

1C7cDqqGK5vscgPfD9d6gwcMw2tSRb4Q1Q
0.01076317 BTC

3BwbGdAidTuFLYdAhgVX1DgnoPCJ9fECRY
0.04809524 BTC

See footnote.
Where did the 0.00149566 BTC end up? At 1C7c…4Q1q or at 3Bwb…ECRY? No one can say, it may not be a meaningful question.
So the notion "the blockchain actually states where all bitcoins in existence are at" isn't meaningful because there are no things called bitcoins, there are only amounts of money specified in a unit of measure named Bitcoin.
The reality is simply that the total amount of mined bitcoin is kept track of as a list of amounts, each of which is associated with a bitcoin-script.

Footnote
The data under "Senders" doesn't all come from the transaction data directly.
Inputs are specified by the transaction ID of a prior transaction they were created in (received in) and an index number into the list of outputs of that transaction.
You can look at the raw data, for example by clicking on "raw data" in the Blockchair web page. It will show a Hex and a JSON view of the actual data
0200000000010274d82567d8e55f9b25628093bd151289543e8630c3f18656cfcd090953cf2ab601000000171600140cabe7062ed5a42e1c6dc75efb708e980efc9aa9ffffffffbc06dcfee104538ef7c333cc16be005de31a4fecec6d766da23ecb2ae6bebda001000000171600148a1e82051ee5b269209d35aee915ca71c2d80a47ffffffff025d6c1000000000001976a91479e947df07c7941727d79ea4cac9b909c43d3c1c88ac346349000000000017a9147072ead5bae0971c1aed1b49b61a822b502c6b3d8702473044022038577fabbcee921e0b4613df3f1b146f32bcc8cde69f0a298b4e0d481231dff402204db6efa7e562a103e103679870188bc7953bea4a0dfed014d6f32dff55bc8d7b012102988d62c603eddc6bd7b4972b03a8173b497bf2647b1ea0a8d2bb64ad7aa22f1b02473044022029fd501198a4dc7692fefc4d48a63c5a6d5a2936215ce0b3a7b1fb449428f13a02201d4f354d61ebd81300e27361e064fb0628ad807f4308ded893238767b68351d4012102ee971f8d307d7b75de716c743b49b579b577b2247f75465820407347feced7d900000000

That's hard to make sense of so they provide a JSON view (or JSON interpretation):
{
  "txid": "1218039587a3fc96f0c6f3d0fb0d49404f54917a3d63cb52158a1ef84f27d33e",
  "hash": "cb44308832dfeceeba412633b937ebc3bbf5c4629a463f7fa04442b74c76d53d",
  "version": 2,
  "size": 420,
  "vsize": 258,
  "weight": 1032,
  "locktime": 0,
  "vin": [
    {
      "txid": "b62acf530909cdcf5686f1c330863e54891215bd938062259b5fe5d86725d874",
      "vout": 1,
      "scriptSig": {
        "asm": "00140cabe7062ed5a42e1c6dc75efb708e980efc9aa9",
        "hex": "1600140cabe7062ed5a42e1c6dc75efb708e980efc9aa9"
      },
      "txinwitness": [
        "3044022038577fabbcee921e0b4613df3f1b146f32bcc8cde69f0a298b4e0d481231dff402204db6efa7e562a103e103679870188bc7953bea4a0dfed014d6f32dff55bc8d7b01",
        "02988d62c603eddc6bd7b4972b03a8173b497bf2647b1ea0a8d2bb64ad7aa22f1b"
      ],
      "sequence": 4294967295
    },
    {
      "txid": "a0bdbee62acb3ea26d766decec4f1ae35d00be16cc33c3f78e5304e1fedc06bc",
      "vout": 1,
      "scriptSig": {
        "asm": "00148a1e82051ee5b269209d35aee915ca71c2d80a47",
        "hex": "1600148a1e82051ee5b269209d35aee915ca71c2d80a47"
      },
      "txinwitness": [
        "3044022029fd501198a4dc7692fefc4d48a63c5a6d5a2936215ce0b3a7b1fb449428f13a02201d4f354d61ebd81300e27361e064fb0628ad807f4308ded893238767b68351d401",
        "02ee971f8d307d7b75de716c743b49b579b577b2247f75465820407347feced7d9"
      ],
      "sequence": 4294967295
    }
  ],
  "vout": [
    {
      "value": 0.01076317,
      "n": 0,
      "scriptPubKey": {
        "asm": "OP_DUP OP_HASH160 79e947df07c7941727d79ea4cac9b909c43d3c1c OP_EQUALVERIFY OP_CHECKSIG",
        "hex": "76a91479e947df07c7941727d79ea4cac9b909c43d3c1c88ac",
        "reqSigs": 1,
        "type": "pubkeyhash",
        "addresses": [
          "1C7cDqqGK5vscgPfD9d6gwcMw2tSRb4Q1Q"
        ]
      }
    },
    {
      "value": 0.04809524,
      "n": 1,
      "scriptPubKey": {
        "asm": "OP_HASH160 7072ead5bae0971c1aed1b49b61a822b502c6b3d OP_EQUAL",
        "hex": "a9147072ead5bae0971c1aed1b49b61a822b502c6b3d87",
        "reqSigs": 1,
        "type": "scripthash",
        "addresses": [
          "3BwbGdAidTuFLYdAhgVX1DgnoPCJ9fECRY"
        ]
      }
    }
  ]
}

Note that the two inputs listed under vin are

txid
vout
scriptsig etc

b62a…d874
1
…

a0bd…06bc
1
…

So the two inputs are specified, not using an address and an amount but by specifying a source transaction and a position in the list of outputs (vout). There is also other data, essentially proof of right to spend. So the blockchain explorer can use txid & vout as an index to look up additional details of those inputs from its records of the specified earlier transactions (e.g. "date received" for each vin)


Can a miner set the EXACT timestamp of a block? I know that miners can adjust the timestamp of a block, but can they control the exact timestamp datetime (within the +-2h rule)?

For example:
A miner mines a block at 2013-08-08 08:01:34.
Can the miner change the block timestamp to 2013-08-08 08:08:08?

Bitcoin miners can construct the block header, including the timestamp, however they want, as long as it adheres to the consensus rules. The shift you describe is well inside the 2 hour timerange, so it can be done when setting out to mine the block. It cannot however be done once the block is mined as the timestamp is part of the header, which is hashed into the PoW, hence changing the timestamp would invalidate the proof of work.

Most miners however prefer to increase/decrease the timestamp in order to have a simple way to alter the header, thus more hashes to compute. This is sometimes called time-rolling and is performed on top of the nonce-rolling.


Explanation of "Timestamp Server" section in original bitcoin paper I'm trying to understand the "Timestamp Server" section in the original bitcoin paper. It feels overly short for someone without an understanding of cryptography.
Is it saying?

A block includes:

The block itself
The time the block was created
A hash of the previous block

When a new block is created:

This block includes the current time and a hash of the previous block
The hash of this new block is broadcasted to all nodes

There is little information online trying to research the concept of "timestamp server".
Apologies if this is a silly question. As a software developer I'm trying to understand how this works on a granular level.
Source:
From the original paper, Bitcoin: A Peer-to-Peer Electronic Cash System.
3. Timestamp Server
The solution we propose begins with a timestamp server. A timestamp server works by taking a
hash of a block of items to be timestamped and widely publishing the hash, such as in a
newspaper or Usenet post [2-5]. The timestamp proves that the data must have existed at the
time, obviously, in order to get into the hash. Each timestamp includes the previous timestamp in
its hash, forming a chain, with each additional timestamp reinforcing the ones before it.

Is it saying ...

I think you have it right except that for 2.2. the whole new block is broadcast not just the hash.
Actually "broadcast" isn't exactly the right term really. I believe the node transmits the new block to a small number of peers (e.g. ten or so other nodes). These other nodes then pass on the new block if it looks OK to them. Eventually the new block reaches all nodes in the network.
In a comment below, Pieter Wuille has clarified some of the details, "Blocks are announced to all peers. Those peers then fetch the actual block from (typically) the first peer that announces from them."
I haven't found an explicit detailed description of the exact sequence of network actions, but if you read The Bitcoin Wiki's Protocol documentation you'll see that there are many message types and one of them is inv  (inventory)

Allows a node to advertise its knowledge of one or more objects. It can be received unsolicited, or in reply to getblocks.

The inv payload includes an array inv_vec[] which contains a code for a type of data available (e.g. block) and a hash of that data.
So the recipient of that message could presumably see that the sender has one or more blocks that the recipient doesn't and could presumably then issue a getdata message to obtain that new data. As I said, I haven't yet found a detailed explanation of the exact sequence of operations but I imagine the reality is along these lines. So my description of this as broadcasting new blocks is a simplification.

There is little information online trying to research the concept of "timestamp server"

As you evidently know, but others might not, what Nakamoto was describing, under section 3. Timestamp Server, is an activity that we would now refer to as mining.


What is off-by one error in updating target? How is it fixed? Can some one explain completely what off by one error is? how is it fixed?

In the bitcoin blockchain, the difficulty of mining is adjusted after every 2016 blocks. If the average mining time for the last 2016 blocks was higher than 10 minutes than the difficulty is reduced so that the time readjusts to 10 minutes. While if the time to mine the last 2016 blocks was lower than 10 minutes, then the difficulty is increased.

Although the target calibration happens every 2016 blocks, because of an "off-by-one" error within the Bitcoin Core client, it is based on the total time of the previous 2015 blocks (not 2016 as it should be). Because you are now including the time for the last 2015 blocks but comparing it to 20,160 minutes (2016 x 10 minutes), this results in the target bias upward by ~0.05%.


How does the bitcoind get current blocks when we start that? Bitcoind tries to save all of blocks when we start that and  I came to want to know about it more so I've been searching for that but I couldn't figure it out.
So now I just guess that bitcoind tries to save all of blocks by connecting to users' pcs
Is my guessing right?

Yes, bitcoin downloads all its blocks off other bitcoin nodes that it connects to, hence the term peer-to-peer (P2P) network. During the initial block download, when a node starts for the first time, it must download all blocks since the beginning of bitcoin (the genesis block), so it must download these from full nodes which store them all, unlike pruned nodes which only store some of the blockchain, not the whole thing.


What does it mean for a cryptocurrency to be ASIC-resistant? I guess the question I'm asking here is what does it take for an altcoin to be ASIC-resistant? What does it need to have?

It means that there will be no significant speedup by implementing the algorithm in an ASIC, as compared to a CPU based implementation.

This is usually achieved by requiring a lot of memory, which when implementing this on an ASIC, translates to needing lots of physical area on the chip.

ASIC implementations derive their power from having many physically parallel and pipelined threads on one chip, each requiring a certain piece of chip real estate.
Now if your algorithm requires lots of real estate even for one step of the pipeline, there will not but much room to actually parallelize or pipeline the algorithm.  Thereby you will lose the parallelizing advantage of an ASIC implementation.

scrypt is such an algorithm. Used for instance by Litecoin.


Mastercoin vs Quantum Computers Assuming quantum computers become mature enough to effectively crack elliptic curve cryptography of the type used by bitcoin, is Mastercoin secure?

In principle the Mastercoin protocol should be exactly as safe as bitcoin (which it uses as a back end) against the powers of quantum computation.
However, there is one important difference.
bitcoin addresses that were used at least once are not safe against quantum computers (look for example in this article by Vitalik Buterin).
Since all Mastercoins were created by sending bitcoins to the exodus address it follows that any original bitcoin/mastercoin address (by that I mean, the original address from which bitcoins were sent to the exodus address) is not quantum safe.

Should we worry about it? probably not. Quantum computer attacks against bitcoins are not expected in the near future and even if they were here tomorrow it is more likely that attackers use them against bitcoin directly. Hopefully by the time this issue becomes relevant we all have nice mastercoin clients we can use to easily transfer out funds to a never-used-before address which is quantum safe.


Double spending on testnet or regtest? I'm currently doing a research on bitcoin and I would like to know if there is anyway to replicate double spending in the testnet or regtest? If isn't possible is there any other type of "attacks" that can be replicated?

If you have some hash power, you can perform Finney attacks on testnet. With regtest, you can perform any attack requiring 51% of the hash power since on regtest you are 100% of the hash power.


Bitcoind in test network doesn't display transactions Hello i'm setting up the bitcoin-core daemon, i use version 160300 ( but it is same problem with newer version ).

I have made config like this:

testnet.conf

server=1
listen=50
listenonion=0
testnet=1
bind=127.0.0.1:18333
proxy=127.0.0.1:9050
rpcuser=bob
rpcpassword=12345
rpcport=18332
port=18333

datadir=/home/testnet/
pid=/home/testnet/.pid

then i run bitcoind:

bitcoind -daemon -conf="~/btc/testnet.conf"

Now i got me some address, using:
bitcoin-cli --rpcuser="bob" --rpcpassword="12345" --rpcport=18332 getnewaddress "test_user"

Result is 2NF9YinW7mqpUGy1GySD2xEV11uVPbQggbb

Then i go to this site https://coinfaucet.eu/en/btc-testnet/

I enter this address 2NF9YinW7mqpUGy1GySD2xEV11uVPbQggbb and press send, it gives me back transaction id, this is it here https://live.blockcypher.com/btc-testnet/tx/d2aa744b33e60f959217cf2ae3852f8826bb2d977839b4a2be0a958aec6a9984/

But i do now:

bitcoin-cli --rpcuser="bob" --rpcpassword="12345" --rpcport=18332 listtransactions

and in result get this:

[
]

No incoming transactions. getbalance returns 0

Can someone help. what is going on, do i need to mine blocks or something to get that transaction ? Or should i wait more for bitcoind to work ?

UPDATE:

The output of getblockcount is 1381543 and it seems to increase when i send getblockcount again

The output of getblockchaininfo is:

{
  "chain": "test",
  "blocks": 1381659,
  "headers": 1580289,
  "bestblockhash": "0000000000000095a7c30336ab1c9f12260b5a8fb2deb6dde59ab8c372376a64",
  "difficulty": 17349304.92883517,
  "mediantime": 1533662288,
  "verificationprogress": 0.8876421741980308,
  "initialblockdownload": true,
  "chainwork": "00000000000000000000000000000000000000000000008b05062dc0c9f9c122",
  "size_on_disk": 15923153327,
  "pruned": false,
  "softforks": [
    {
      "id": "bip34",
      "version": 2,
      "reject": {
        "status": true
      }
    },
    {
      "id": "bip66",
      "version": 3,
      "reject": {
        "status": true
      }
    },
    {
      "id": "bip65",
      "version": 4,
      "reject": {
        "status": true
      }
    }
  ],
  "bip9_softforks": {
    "csv": {
      "status": "active",
      "startTime": 1456790400,
      "timeout": 1493596800,
      "since": 770112
    },
    "segwit": {
      "status": "active",
      "startTime": 1462060800,
      "timeout": 1493596800,
      "since": 834624
    }
  },
  "warnings": ""
}

Sounds like you did not give bitcoind time to "sync", no other explanation comes to mind. Starting bitcoin-qt may be more obvious.


What are the co-ordinates of generator G in his uncompressed form on secp256k1? I was looking at BitcoinWiki and it says that G, in it's uncompressed form, has a value of:
G = 04 79BE667E F9DCBBAC 55A06295 CE870B07 029BFCDB 2DCE28D9 59F2815B 16F81798 483ADA77 26A3C465 5DA4FBFC 0E1108A8 FD17B448 A6855419 9C47D08F FB10D4B8
Since it's uncompressed, it should contain information about X, but Y as well. How can I determinate those co-ordinates out of this?
Thank you!

The 04 first byte header indicates this is an uncompressed point (02 indicates compressed).
From there, it is simply an x followed by y representation - The first 32 bytes are x, the following 32 bytes are y. Therefore,
x = 79BE667E F9DCBBAC 55A06295 CE870B07 029BFCDB 2DCE28D9 59F2815B 16F81798
y = 483ADA77 26A3C465 5DA4FBFC 0E1108A8 FD17B448 A6855419 9C47D08F FB10D4B8

More details on how compact elliptic point representations work can be found in this spec.


How can I export a single wallet from bitcoind? On my full node bitcoin wallet, I have a lot of wallets, I can see them with the command dumpwallet "filename" but if I try to export one of those priv keys to another wallet, (blockchain) this New wallet service recognize the public address for this priv key, but not the ammount of bitcoins corresponding to this wallet... Am I doing something wrong?

To clarify, what you exported is a private key for an address. A wallet is a collection of addresses and their private keys.

The amount that you think is associated with that address is most definitely not the actual amount. What has most likely happened is that you have made a transaction in the past which spent some of those coins and the remainder has ended up in a change address. When you make a transaction, the change Bicoin always goes to a newly generated change address that is part of your wallet.


Authorization required error when accessing bitcoin using json RPC I'm trying to make a simple request to bitcoind using perl I followed the example from the API reference, but it fails saying "401 Authorization Required"

#!/usr/bin/perl -w

use JSON::RPC::Client;
use Data::Dumper;

my $client = new JSON::RPC::Client;

$client->ua->credentials(
    'localhost:8332', 'jsonrpc', 'bitcoinrpc' => 'mybitcoinrpcpassword'  # REPLACE WITH YOUR bitcoin.conf rpcuser/rpcpassword
    );

my $uri = 'http://localhost:8332/';
my $obj = {
    method  => 'getinfo',
    params  => [],
};

my $res = $client->call( $uri, $obj );

if ($res){
    if ($res->is_error) { print "Error : ", $res->error_message; }
    else { print Dumper($res->result); }
} else {
    print $client->status_line;
}

Am I missing something obvious? Thanks for any help!

Figured it out. Turns out that (at least on Bitcoind 0.8.1 on Ubuntu), specifying the conf file when starting bitcoind doesn't do anything. I was starting it with:

bitcoind -daemon -conf=./bitcoin.conf

from a bitcoin directory I had created /home/vijay/btc/. But bitcoind automatically uses the conf file in ~/.bitcoin/bitcoin.conf and mine was being completely ignored. Not sure what the point of the "-conf" option is!

So the solution was just to add my rpc username and password to the default conf file, which fixed the authorization failed error.


What is the maximum number of names (domains) that can be registered with NameCoin? Is it 21,000,000 / 0.01 (the cost of naming) = 2.1B?
from docs: "The name_firstupdate transaction has a network fee. The network fees represents namecoins (NC) that are destroyed. "

Am I missing something? If not, it seems like quite a small number.

Given increased use of Namecoin, which would lead to a shortage of namecoins as you describe, the fee would be reduced. I have previously seen plans to reduce the network fee to 0.001 or lower, but can not find it now.

These changes would require a hard fork of Namecoin, but it is important to note a fee is only destroyed upon a new registration. Updates of DNS records and domain renewal go to miners.

I am not aware of any hard block size limit, but should one exist (or be implemented with a hard fork) it would be unlikely to get anywhere near the 2.1 billion names as you describe.


bitcoind password for every address I need a system where I need to create new address for every user(personal account) where they will transfer some bitcoins to it and buy some products from my website.

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

Now the users will buy some products on my website (i.e. transfer amount from their account to company's account) and then the transfer happens and based on the confirmations, the product will be purchased.

Now my question is, whenever user starts buying a product, he will execute command (bitcoin-cli sendfrom) and for doing that, we need to first unlock the wallet by walletpassphrase and then do the transaction. so, there would be only 1 password which is assigned to the wallet but not every address.

Is this the correct way?

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

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

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

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

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

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

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

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

  Is this the correct way?

No, it is not.

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

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

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


What is the maximum number of multisigaddresses you can create? I have created a few multisig addresses, and just tried to create a 2 of 3 address, but it returned with the 'AddCScript() failed' error.

What is the maximum number of m-sig addresses and where is this in the code? I'd like to know how to expand the limit for a test.

I realized what happened, the wallet was a massive size and the Write() function was failing.


Tracking payments sent to scammers, and what they do with the money I am interested in tracking payments sent to known scammers, and tracing where that money goes.

Is there any website that compiles this information and shares it with others?

There was a project that seems to no longer be active called BlockViewer.

The problem, of course, is Bitcoin's pseudonymous nature.  Beginning with the first transfer the trail can be essentially be blurred and the coins re-enter circulation through legitimate transactions with innocent parties.  Just like what happens when scammers use cash as well.


What's the purpose of running Armory through Tor? What's the purpose of running Armory through Tor?  Is it only useful once you get to the point where you start sending Bitcoins?

Armory (in online mode) uses a full node.  Full nodes relay transactions for other programs on the Bitcoin network, so by running Armory on Tor, you help other people send their transactions with possibly-improved privacy.
Sending your own transactions through Tor with Armory can help prevent anyone from associating your IP address with your transaction, possibly improving your privacy.

Note: Tor and Armory must both be used properly to achieve improved privacy.


What is to stop people from pumping the volume of transactions via automated micropayments to a large group of addresses? This depends on the way in which # transactions are measured.

There's several anti-DOS measures that counter this:

transaction fees get expensive with large numbers of outputs
many rapid transactions with no fees will be rejected
small amounts (less than 0.000045) in an output are called dust, and are rejected

It essentially becomes prohibitively expensive to try to spam.


Lightning network: how was malleability actually fixed? Section 3.1.2 of the Lightning paper (Version 0.5.9.2, last modified 14 January 2016) discusses ways to fix the transaction malleability issue, which prevented Bitcoin transactions from spending UTXO from yet unconfirmed transactions. Specifically, it mentioned SIGHASH_NOINPUT transaction type.

As far as I know, the malleability issue was fixed with the Segwit soft fork in August 2017. Was the malleability issue fixed with SIGHASH_NOINPUT or with some other method? How does it affect the Lightning network design as described in the paper?

A related (very old) question, another one.

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

Yes.

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

No, using SegWit.

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


Pay a wallet address in bitcoin I don't trade in bitcoin, never have and I don't want to continue, but I have a problem I need to pay someone in bit coin, I have their wallet address but I don't know how to go about buying bit coin and paying them. I just need to make this one transaction and that is all. I need to send the equivalent of $351.00 in bit coin. Can anyone help?

One way is to buy the bitcoin with fiat (cash) through localbitcoins.com (find a seller with at least a few transactions and 100% reputation). Have the bitcoin fraction you are buying delivered by the seller to the address you want. Just be very sure to get the address correct. You can verify that the funds reached the address by checking on any bitcoin block explorer, such as blockchain.info.  Once you verify the bitcoins are the address you want, you can pay the seller.


What happens when I buy BTC with XRP from the Ripple client? I don't see anywhere in the ripple client that shows my bitcoin address, and I can't recall if I entered it. When I make an offer to buy X BTC for Y XRP, where does the BTC go when accepted?

Ripple operates differently for ripples and other currencies. Ripples can be transmitted between person to person like Bitcoins, while all other currencies operate like IOUs through a web of trust. When your friend that you trust sends you BTC, your Ripple accounts will show you both that they owe you some amount of money. If you ever send bitcoins to them through Ripple, the debt might be lowered, extinguished, or even reversed based on the amount.

If you want to get bitcoins into your Bitcoin address, you will need to go through a Ripple Gateway. They accept Ripple IOUs and pay you with an appropriate currency, including BTC.