What is preventing negative balance? This is probably a stupid question that has an answer somewhere, but I was unable to find anything, so please feel free to redirect me !

I have a basic understanding of how the bitcoin blockchain works, namely, you sign and broadcast your transaction, it gets picked up by the nodes and is eventally included in a block that is mined.

I understand that as long as there isn't someone controlling more than 50% of the mining power, it is unlikely to be able to perform a double spend attempt.

However, what prevents someone from spending more bitcoins that they have ? For example, if I have 1 BTC on my adress, suppose I run a mining node, what prevents me from trying to mine a block in which I spend 1.2 BTC ? At what point in the process is the balance of my adress checked to make sure I do have the bitcoin that I want to spend ?

At first I thought that it was the nodes that verified that the transaction on the mempool are valid before starting to mine them but this can't be it, since you could have a malicious node that does whatever (although it would be difficult to pull off without enough mining power).

This check must be somehow "hard-coded" somewhere, in the sense that it is actually impossible to create a transaction of inexistent bitcoin. Could someone point me to a resource or elaborate how does this work ?

if I have 1 BTC on my address, suppose I run a mining node, what prevents me from trying to mine a block in which I spend 1.2 BTC ?

This is the specific set of code in Bitcoin Core that rejects anyone's transaction who's is putting less money into the transaction (inputs) than the recipients are receiving (outputs), e.g. spending more money than they have added to the transaction:

const CAmount value_out = tx.GetValueOut();
if (nValueIn < value_out) {
    return state.DoS(100, false, REJECT_INVALID, "bad-txns-in-belowout", false,
        strprintf("value in (%s) < value out (%s)", FormatMoney(nValueIn), FormatMoney(value_out)));
}

Technically, this isn't checking the "balance" of an address, since in Bitcoin system itself, addresses don't have balances.  When you receive bitcoins, you receive them to an individually-identifiable output (payment).  When you spend bitcoins, you identify exactly which output (or outputs) you want to spend and spend all of that value at once.

If you want to pay someone less than the full value of one of your outputs, you add an extra output on to your payment that returns the remainder to yourself.  This is like paying for a $2 snack with a $5 bill and receiving $3 change back to yourself (and it Bitcoin, we call that extra output paying yourself the "change output" by analogy).

So in the code above, by checking every single spend in the system to prevent anyone from receivng more bitcoins than were initially spent (except for newly-minted bitcoins), we prevent negative balances.

  At what point in the process is the balance of my adress checked to make sure I do have the bitcoin that I want to spend ?

As explained above, inputs and outputs (rather than address balances) are what's checked.  They're ultimately checked when a block is received; however, the software may check them for unconfirmed transactions and cache the result so that it can process newly-received blocks faster.

Somewhat related, you also can't pay someone a negative output:

    if (txout.nValue < 0)
        return state.DoS(100, false, REJECT_INVALID, "bad-txns-vout-negative");


What is the "witness reserved value" for BIP-141? BIP-141 defines a witness reserved value as part of a flexible commitment structure:

Double-SHA256(witness root hash|witness reserved value)

The purpose is to support commitments (i.e., data associated with a block) beyond the witness root hash. That part makes sense, but it seems like the value of witness reserved value should be defined in BIP-141. For example, should it be omitted altogether when hashing the witness root hash? Should it be set to 0x00? Some other value?

It's a reserved value.

That means it is reserved for future extensions, but for now there are no rules about it. It's encouraged to not use it for anything, as that may conflict with later use.


What happens if I buy BTC from an ATM, but the transaction never confirms? I bought bitcoin through the atm machine, it was sent to me but is yet to be confirmed over 52hrs.. if the transactions later disappeared from the mempool / blockchain, how will the sender get back the fund, since not send from a wallet?

In this case, you would need to contact the ATM operator / service provider, and provide them with some proof of your purchase and the failed transaction. When completing your interaction with the ATM, you should receive some sort of receipt that details this information, though the exact specifics will likely vary from one ATM to another.
If you are running a full node, perhaps you could find the transaction which was supposed to pay you in your node's mempool, and then save it to be rebroadcast in case of an extended period of non-confirmation.
But I think that in most cases, you will just need to contact the customer service department of the ATM operator, and request that they complete the transaction.


Why do Anchor Outputs need to enforce an nSequence of 1? Quote from https://bitcoinops.org/en/topics/anchor-outputs:

As of this writing, the most recent versions of the design add two outputs to the commitment transaction—one for each LN party—and require all other outputs in the commitment transaction to have their scripts encumbered by a 1 OP_CHECKSEQUENCEVERIFY (CSV) condition that prevents them from being spent for at least one block.

As far as I understand https://github.com/lightningnetwork/lightning-rfc/blob/master/03-transactions.md#offered-htlc-outputs , the addition of  1 OP_CHECKSEQUENCEVERIFY (CSV) is the only thing that changes within the output scripts of the Bitcoin transactions used by the Lightning protocol.
But why is this necessary? Why can't we just use CPFP without that relative delay of 1 block?

Because there must always be exactly one directly spendable output per party, in order to avoid one party to be able to "exhaust" the carve-out.
With two CPFP-ble outputs, one party could both create a chain of descendants transactions on the first outputs so that it meets the standard mempool limits and then trigger the carve-out mechanism using its own second output.
This way, the HTLC transactions are not included in the mempool and cannot be used to either create a long chain of descendants, or used as a carve-out transaction.
xref:

The carve-out proposal
The first mail (by Matt Corallo) expliciting the need of at most one directly spendable output for the carve-out to "work".


Why do crypto exchanges impose withdrawal limits for BTC and other coins Many crypto exchanges impose quite low limits on withdrawing balances from their sites. For example Binance has an equivalent limits of 100 BTC for a daily withdrawal.

The question is, why do they need to impose a limit at all? Are the customers coins not in segregated custody, and when sold in a transaction on the exchange, the funds should be there irrespective of the size of the transaction. In short, why would an exchange need to limit withdrawals at all?

Limits could be in place for a number of reasons, such as:

Regulations imposed by the government of the country the exchange is operating within (eg unverified customers can only withdraw a certain amount)
The majority of the exchange's coin reserves are held in an offline, cold storage wallet. So a very large withdrawal may require more coins than the exchange has available in an automated hot wallet (this is a security consideration)

Every exchange will have its own considerations in this regard, but these examples should give you some basic understanding of why limits would exist.


Can the fee be 10 times bigger than the amount that was sent? I don't understand one thing : If I get paid an amount of 0.000055 BTC ore more, how come the fee is 0.0005 ? The fee is ten times bigger than the amount I was paid?

The tansaction fee is based mostly on the transaction size (in kilobytes), not its amount (in BTC).

Even more: the bitcoin protocol is quite unfriendly to small transactions to prevent spamming the network. If the transaction output is larger then 0.1 BTC, then the fee could be leveraged (more on fee generation algorithm here)


"Dirty" Bitcoins/Find Bitcoin origins? I know that it's possible to sort through the blockchain history for your bitcoins, however it is difficult to trace back your coins to when they were originally mined due to bitcoin mixers.  Is it possible to create a tool that will give a complete history of your coins?  More specifically, is it conceivable that at some point regulators may distinguish between "dirty" and "clean" bitcoins, where "dirty" bitcoins are anything that have passed through a wallet of a known criminal?  Even with bitcoin mixers?

The tool for complete history of all bitcoin minted already exist and its called blockchain. You can see all history here (random transaction selected)

https://blockchain.info/tx/ff698f3e5321448d4d889fcd3c91f9e5f5767542d2f0fd7e4aa41a83abec3ab7

There is a term taint and it's meaning how two addresses are connected. It partially explained here What are tainted coins exactly?

Bitcoin is not a legal tender and nobody have to accept any bitcoin - with normal dollar any dollar is a dollar that is worth always the same and cannot be legally tainted with crime. It's more legal question that a technical one because government could not adhere to technology reasons.


How to set exact bitcoins to receive in blockchain api? Is there a way that I can set up the exact amount the user should pay? When the user input is higher/lower on the amount that I have provided the transaction should fail. I'm using the "receive payment Blockchain API v2".

No, not the way you think.
The recipient has no say in whether a transaction to him gets made. The sender signs over money to the recipient, the recipient is not being asked. Any (simple) transaction that just sends money from one party to another is the sole prerogative of the sender.


How is a wallet's balance computed? I am wondering on how a wallet's balance is computed. Basically, from what I've read I assume that you look back at all transactions involving all the keypairs of a given wallet. Adding up all the transactions' balances (negating a transaction balance when the transaction was outbound) should match the wallet's balance, right?

A) Is there Python code available that computes a given wallet's balance? I am not looking for a complete wallet software, just a minimalistic (academic) Python code example.

B) If using a web service, e.g. https://blockchain.info/q/addressbalance/$addr, how do I derive the address $addr to query from a given wallet? Any Python code?

There is no such thing as a transaction "balance".  I am going to assume if I jump right to the answer it won't make much sense so the first two sections are to make sure we are how Bitcoin "really works" (at a very high level abstracted view).  We need to speak the same language for the answer to make any sense.  For this question the two required concepts in how Bitcoin really works that need to be understood are inputs & outputs, as well as where transactions are recorded.

Inputs & Outputs

Bitcoin works on the concept of discrete inputs and outputs not spending part of a balance.  All transactions have as their input a reference to a previous unspent output.  The transaction records one or more new outputs (which are referenced in the inputs of some future transactions).  Outputs are "spent" when they are referenced in a new transaction.  Outputs can only be unspent or spent, they can't be partially spent.

Wallet balance (or address balance) is an abstraction to help us humans and make Bitcoin more like conventional payment systems.  Balances are not used at the protocol level.  When the wallet indicates your confirmed balance is 1.2 BTC it is saying that the sum of the value of all unspent outputs in the blockchain which correspond to public keys it has the private key for total 1.2 BTC.  In other words the wallet is computing the total value of the outputs which it can spend which requires a) the output be unspent and b) the client has the private key necessary to spend it.

Storing Transactions

All confirmed transactions become part of the blockchain.  Clients validate transactions and blocks; only valid transactions and blocks are added to the blockchain.  For the purposes of validating transactions and computing available balances only part of the blockchain is needed and that portion is called the UTXO (Unspent Transaction Output Set).  This is a subset of JUST the unspent outputs.  As all future transactions will reference unspent outputs as their inputs only the unspent outputs are needed for validating new transaction and computing the balance (which is another way of saying the total value of outputs which "can" be used in new transactions).

The UTXO is much smaller than the entire blockchain (about 15% of total blockchain right now and that will shrink over time).  It may not be immediately obvious but the number of Bitcoins in the UTXO is always equal to the number of mined Bitcoins.

Unconfirmed transactions are not part of the blockchain (or UTXO).  Clients maintain an unordered list of all the unconfirmed transactions they are aware of.  This list is called the memory pool.

Computing "Balances"

The creation of the UTXO makes computing balances straightforward.  The UTXO contains all unspent outputs however your client can only spend the subset of those outputs which correspond to public keys that it has the private key for ("your keys").  This subset has no official name however the RPC call to output this list is listunspent so I will call it the listunspent set.

The wallet uses the listunspent set and memory pool to determine the current balance.  In reality wallets compute this in "real time" as changes to the memory pool or UTXO occur (i.e. when the client learns of new blocks or transactions it records them and then makes changes to its reported balance if any).  For the sake of brevity I will just show how to get a "snapshot" of the current balance.  There is a confirmed balance and an unconfirmed balance, clients often show a reduced-current balance to simplify things for users.

Confirmed Balance

The confirmed balance is the sum of the value of the "listunspent" set.  Example: the listunspent (outputs in UTXO which client has keys for) has 20 outputs and combined they have a total value of 1.2 BTC so the confirmed balance is 1.2 BTC.

Reduced-Confirmed Balance

Client usually do not show the "real" confirmed balance because users are more interested in what they have available to spend.  Transactions in the memory pool which have inputs that reference outputs in the listunspent set technically have no yet reduced the confirmed balance.  In most cases they will eventually confirm so clients will remove these outputs when computing the "confirmed" balance.  The "confirmed" balance in most wallets is actually this reduced-confirmed balance.  It is done to abstract the way Bitcoin really works.  If it wasn't then the confirmed balance would not reduce until a transaction was confirmed which might seem confusing to a user (they have 100 BTC, spend 1, it still shows 100 BTC).  A client could break this down into "confirmed balance", "reserved for unconfirmed transactions", and "available balance".

Unconfirmed Balance

An unconfirmed tx "to" the client will not be in the UTXO yet.  It will however be in the memory pool.  The sum of all the outputs (which the client has keys for) in the memory pool is the pending balance.  Those tx will either be confirmed (the tx and output is removed from memory pool and added to the UTXO) or they will be dropped.

Handling Change

Due to the way Bitcoin handles "change" (outputs can be partially spent so the unused portion is sent back to the user) the simplified example above while accurate would be confusing to the user.   Most wallets "cheat" and include the unconfirmed change outputs in the "reduced-confirmed" balance.  This isn't a requirement however not hiding this aspect from users may lead to some unexpected behavior.  Imagine a client with a reduced-confirmed balance of 100 BTC and a pending balance of 0 BTC.  The user "spends" 1 BTC however the outputs referenced in the new tx total 5 BTC.  This means the new outputs are actually 1 BTC + 4 BTC "change".  If balances weren't modified to "hide" the change, after the spend the user would see confirmed balance of 95 BTC and a pending balance of 4 BTC.


What % of bitcoin transactions involve addresses of known charitable organizations Blockchain analysis can come a lot way. Are we at the point where we can identify what percentage of transactions related to certain industries?

What percentage of transactions involve a receiving address than can be tied to a charitable organization with blockchain analysis?

If that question can be answered please also list any bitcoin transaction size data that is available.

Are we at the point where we can identify what percentage of transactions related to certain industries?

Not really! The percentage of addresses that are tied to known organizations is quite small. You also have to consider that many transfers occur without any change in ownership, that is, a person sends bitcoin from one address they control to another.

Consider the mining industry: we know the address of every mining pool that finds blocks, because their address becomes known at the time of the block being minted. Even then, if the coins are transferred to other addresses within the mining organization, we lose clarity on whether these coins are still being held 'within' that industry, and are left to IP analysis, which is far from conclusive in many situations.

If you made a list of known addresses tied to charitable organizations, you could easily come up with a percentage of total transactions associated with those organizations, but it wouldn't be that meaningful of a statistic.


How address balance is calculated? It does not seem practical to scan every transaction on a block chain to determine the balance for an account.  As the block chain grows this seems even more difficult and resource consuming. Perhaps all the transactions are grouped into what we used to call a record, specifically a variable length record.
address..trans1, trans2, etc...transN  for the last transaction.

Bitcoin uses the so called UTXO (Unspent Transaction Output) model.
The first time it is not very intuitive because it is different from the traditional accounting model where you just spend from and send to an account.
Think about full piggy banks that can't be filled more than they are and that you have to break open before being able to spend the content:

1) Bob has 1 piggy bank, he wants to pay Alice with half of the piggy bank's content
2) he breaks his piggy bank
3) he takes half of it and gives it to Alice, who will put it all in a new piggy bank belonging to her
4) you put the remaining half in a new smaller piggy bank belonging to you and which is waiting to be broken open.

Each piggy bank/UTXO is linked to an address.
A Bitcoin user can of course have several UTXOs related to his address. The sum of the UTXOs gives the amount of bitcoins owned by the address (which is one of the function of wallets).
Each transaction input is the output of a previous transaction.
Although wallet software gives the feeling that you "transfer" bitcoins or satoshis, you don't spend from an account you spend UTXO.
You spend from transactions previously made to you.


How can a pruned node be classed a full node without the full blockchain? A full node is a node with the whole blockchain and is able to verify any new incoming blocks.

A pruned node, is a node with only some of the blockchain, namely it has removed some of the older blocks due to space requirements. A pruned node cannot validate blocks, as it does not have the full history of the blockchain right? So how can we still say that it is a full node?

Am I also right in saying that they do not serve any value to the network, as any blocks they send out will not be fully validated?

Pruned nodes will verify new blocks and they are classified as full nodes

They keep the complete database of all UTXOs. This is enough to verify new blocks. What is required for validation is that the tx in the new blocks are spending only the current unspent transaction outputs
They store mempool and check blocks to make sure they comply with all bitcoin protocol rules, just like other nodes
Since, they don't keep older block data, only thing that they can't do is to return older block data to other nodes. They still keep latest block data for reogranization, which they can share with other nodes


bitcoin full nodes vs simplified payment verification Why do individual nodes run "full nodes" that keep track of the entire blockchain whereas mechants can get away with "lite node" that implements "simplified payment verification" needing to examine only the last few blocks?

If by individual you mean users I would argue the contrary as many wallet are SPV based or have a centralised backend running a full node (form of lightness as any client does not run a fullnode).Only few desktop bitcoin wallet such as bitcoin core or armory run as fullnode. Fullnode are necessary for miner but it's still good for anyone to run it as it does apply rules on new blocks/transactions whereas SPV's node doesn't which result with an healthier network. SPV's node needs full node to exist but worth to keep it mind that an SPV has to trust its peers as it does not verify/apply rules.

Quoting Mastering Bitcoin:

  An SPV node can definitely prove that a transaction exists but cannot verify that a transaction,
  such as a double-spend of the same UTXO, doesn’t exist because it doesn’t have a record
  of all transactions.

[...]

  A full blockchain node verifies a transaction by checking the chain of
  thousands of blocks below it and checks that the UTXO is not spent,
  whereas an SPV node checks how deep the block is buried by a hand‐
  ful of blocks above it.

A typical a merchant accepting bitcoin would rather be 100% that there is no attempt of double-spending which is not possible with an SPV's node.


Can I use Copay wallet from Iran? Can I use Copay wallet from Iran? Or Iran IP is blocked? Because some wallets blocked money of Iranian users because of sanctions programs administered by the U.S. I need to know if my money will be safe in my copay wallet?

Yes you can but I recommend Electrum instead because with Electrum you are not relying on one server for your view of the blockchain.

Copay and Electrum are both wallets that give you control of and responsibility for your private keys. Your private keys are all generated from your seed which will be displayed to you during wallet creation as 12 random English words. Only someone with knowledge of your seed will be able to move your bitcoins and since you are the only one with that knowledge only you control them. No government or corporation can freeze your bitcoins or censor your transactions.

You can find a list of other such wallets here.


Use bitcoin blockchain as a way to send messages to another address purposely setting a 0 fee or a very low fee? Having that bitcoin nodes are all over the world. Is it possible to broadcast a transaction sending to 20 different addresses with a piece of the message embedded into each address?

The goal is to make use of the blockchain unconfirmed transaction mempool to relay this message to the recipient.

The fee would be set to 1 satoshi per byte. We know it will never confirm, but thats not the goal of it.

What are some drawbacks to this?

This is possible, but there is always a chance your tx will confirm.

As a drawback, the blockchain is public, so the entire world will be able to view your message, assuming they know what to look for. You can encrypt and fragment your message, but using the blockchain to transmit it seems inefficient compared to other available options.

What is the advantage to using the blockchain, as opposed to another channel of communication?


Do I have to download all blocks to see my bitcoin using bitcoin-qt? I saw a youtube video about bitcoin wallet and he said you can't see your bitcoin or send or receive until the bitcoin-qt download all the blocks.

In order for your client to show your bitcoins, you'll at least have to download and process up to the block that validated the transaction with which your money was sent to you. (The client can't show you, what it doesn't know about.)

Bitcoin-QT will allow you to send bitcoins after that, even when it is not synchronized completely yet. Since likely your funds have only been sent to you in the near past, you will have to download almost the complete chain to reach that stage.


Why can't I spend my reserve XRP and delete my address from the network? I understand the Ripple reserve system. You need some XRP in order for you to preserve your account into the Ripple network and additional XRP to assign trust line to your account. I also understand that you cannot spend this reserve because otherwise your account will be removed from the network and forgotten.

However, what if I want to recover the XRP from an account because I don't need the account anymore? Shouldn't it be possible to spend the reserve XRP on your own risk?

The issue is that for safety reasons Ripple currently has no way to remove the account root ledger node to completely remove a Ripple account. Since the reserves exist to help limit the size of the current ledger, any un-deletable ledger node requires a non-refundable XRP reserve (although if the XRP reserves are lowered, as they have been in the past, the difference becomes spendable again). Note that a Ripple account can use all of their XRP in transaction fees, just not in payments or trades.

There is a good discussion on why Ripple doesn't allow for account deletion on the Ripple forums. Basically, doing so would make it possible for a user (or client) to in error re-create the same Ripple account/address (e.g. if someone uses an old Ripple secret to "recover" their account). That would make old transactions signed by that account now be potentially valid against this "new" account (since Ripple uses a simple sequence number per account to prevent replays).


Mining and Bitcoin Wallet I have been mining for over 24 hours @ 97.3 Mhash/s. Shouldn't I have at least obtained .01 bitcoin by now? How do I verify the mining that I am doing is transferring into my Wallet?

If you are solo mining against your own bitcoin server, then for each hash your miner tries it either solves the block (and earns 50BTC [plus transaction fees], provided it doesn't get orphaned), or doesn't (and earns nothing).

If you're mining with a pool, then payment depends on the pool's payment system. If for example it is PPLNS (Pay Per Last N Shares) with a value of 500,000 for N, then you don't get paid anything unless a block is solved within the 500,000 "shares" mined following each share that you submit. Let us know the pool you're using (or the payment mechanism), and we will be able to provide some more info.

With 97.3Mhash/s, I'd (roughly) estimate you'd earn around 0.04 to 0.05BTC per 24hrs with a difficulty of 2,100,000 (approx the current difficulty).


testnet addresses on bitcoin I was wondering how  testnet addresses like https://testnet.blockchain.info/address/myaj43o2wt34j31ej5pmP6htCHFafAKoeP
are created?
Also is there a script to create them?

this address is a standard P2PKH testnet address, and can be derived from a typical priv/public keypair, by adding the testnet prefix. There is a page you can play with - in Step 4 you would change the default prefix "00" to "6F", and get a corresponding address. The composition of such an address and further details are again in the wiki .


How do lawyers view Bitcoin? Have there been any articles or presentations about Bitcoins in any influential or respected law-related websites or perhaps interviews with notable lawyers or the like?

There have been plenty of dollars spent on lawyers by Mt. Gox, BitInstant and others, but for specific legal issues.

For instance, a decision after Mt. Gox sued its bank in France:

https://bitcointalk.org/index.php?topic=41317.0

There is the CryptoCurrency Legal Advocacy Group:

http://en.bitcoin.it/wiki/Cryptocurrency_Legal_Advocacy_Group
http://www.theclag.org

There is an argument that Bitcoin isn't a security (in the U.S.):

http://www.lextechnologiae.com/2011/06/26/why-bitcoin-isnt-a-security-under-federal-securities-law
http://www.lextechnologiae.com/2011/06/17/extending-real-world-laws-to-virtual-worlds-is-a-terrible-idea

Is Bitcoin a commodity then?

http://blog.bitcointitan.com/post/17789738826/what-u-s-regulations-apply-to-bitcoins-as-commodities

Other links:

Ruben Grinberg's paper:
Bitcoin: An Innovative Alternative Digital Currency

http://papers.ssrn.com/sol3/papers.cfm?abstract_id=1817857

Real legal issues with virtual currencies:

http://www.networkworld.com/newsletters/sec/2010/051010sec2.html

Quora: Is Bitcoin Legal?

http://www.quora.com/Is-Bitcoin-legal

There are even lawyers who accept bitcoin:

http://en.bitcoin.it/wiki/Trade#Legal_Services
http://bitcointalk.org/index.php?topic=65482.0

But that's about the extent of it, thus far -- at least what's publicly known.


How 1 cpu 1 vote works? How 1 cpu 1 vote works? What is its validity? Does it use IP address or mac address or similar to that? If yes, then it can be changed and can make fool to the network. If it can't, then how is it preventing any malicious activity?

one-cpu one-vote is about Proof of Work. Except it really is not a vote and "votes" aren't being recorded as to which CPU they came from.

What it really means is that if you participate in mining (so you are performing Bitcoin's Proof of Work), you have the ability to decide which blockchain is "the blockchain" in the even that there are multiple valid blockchains. How this works is that a miner chooses a block to build their block on top of, and they dedicate their computing power to extend that blockchain. The blockchain that "wins the vote" is the blockchain that has the most cumulative Proof of Work, which is generally the one that the most miners have decided to mine on top of.

There is no way to "fool the network" because it isn't a vote. Nothing is broadcast to the network except complete and valid blocks.


Does the pool miners in mining pool receive the same block in case of a fork? For example there are 2 mining pools A and B and they mined a block in same time.

Then, A mining pool got a block that A mining pool mined?

Or nodes in mining pool receive independently so they select block regardless of mining pool?

I have known nodes choose a block which are propagated early to them and block is propagated not geographically close node but randomly (I mean block is propagated close nodes but this ‘close’ do not mean geographically close but close in network).

When miner is mining or propagating, miner can recognize which node is mining in same mining pool?

Most of the mining pools that are run are managed pools, which means it is operated by an individual or a company. The pool server runs specialized software and a pool-mining protocol that coordinate the activities of the pool miners. The pool miners need not run a full Bitcoin node as the pool server runs one and validates blocks and transactions on behalf of the pool miners.

The pool server constructs a candidate block by aggregating transactions, adding a coinbase transaction (with extra nonce space), calculating the merkle root, and linking to the previous block hash. The header of the candidate block is then sent to each of the pool miners as a template. Each pool miner then mines using the block template, at an easier difficulty than the bitcoin network target, and sends any successful results back to the pool server to earn shares.

Since, the pool miners receives the block template directly from the pool operator, all the pool miners are building the candidate block on the same version of the blockchain.


In the case of a criminal investigation, how does one knows which exchange or wallet service a bitcoin address belongs to? How it was found that the Dao hackers used shapeshift?

In a more practical exemple, how to find that 13qCK9VzJCicXeh47W59rh7A6tfun92Sr5 belongs to https://www.blockchain.com using only block explorer data?

There is no guaranteed way to check.

In most investigations, it is a combination of tracing the money to known addresses (most exchanges and companies consolidate funds into a handful of hot and cold wallets), and exchanges volunteering/sharing information when served with warrants.


I'm developing on the Test network. Are there any "rules" or communication methods I should adopt? I'm testing a C# port of the client on the Test network and need to test for a variety of conditions.

Should I communicate to others regarding my actions on the network?  If so, what method of communication should I use?
Is there any expected behavior I should / should not do on the Test network such as mine with FPGA or ASIC?
Suppose I want to co-operatively test the resilience and response to invalid blocks and network attacks, should I do it on the test network?  Where would I coordinate this?

Testnet code has been modified to lessen the impact of fluctuations of hashing power mining against testnet:

http://github.com/bitcoin/bitcoin/pull/686

If you wish to test against your own testnet, or think you might interfere with others needlessly, then Testnet-In-A-Box is for you.

Now this doesn't mean you shouldn't use Testnet -- especially if you find something you think might be disruptive to bitcoin.  Feel free to verify your suspicions on Testnet even if it slams it hard.  That's why it exists.


Help me resolve few queries about bitcoin network ( regarding validation, mining and state of transactions...) Q1. Suppose I make a transaction from node A to node B, it is gets validated by the nodes in the network, A new block hasn’t been mined yet, in the meantime miner is stashing up the transactions Miner doesn’t include my transaction in the newly minted block, what happens to my bitcoin in the time between the next miner decides to put my transaction in the next block?

Q2. Bitcoin has a public ledger, by public ledger do we mean that each node in the network has a chain of blocks, each block having a set of transactions…and all these node have the same chain of blocks associated with them?

Q3. Whilst my transaction is internally being validated by the nodes in the network (not yet accepted by the miners), is this transaction being added to the ledger of various nodes in the network?

Q4. Also, let say, some node in the network validated a transaction, will the same node propagate this result to its neighbours, and the neighbours to their neighbours?

A1. It remains in the mempool of those nodes until a miner decides to include it in the block it's attempting to mine. Making a transaction from node A to node B is a little confusing, maybe you meant from address A to address B?

A2. Yes, nodes that share the same consensus rules (have not hard forked) will have the same blockchain (public ledger). The blockchain determines history of transactions, and the order in which they occurred.

A3. Nodes will validate transactions before they enter their mempool. Miners typically will just mine the block presented by the node (with tx's chosen to maximize profitability in terms of BTC fee/kB). The transaction is not entered into the blockchain (ledger) until a miner finds a valid solution and submits that back to a node. The node then begins to propagate the new block through the network.

A4. Yes, but this does not mean that transaction has been mined in a block yet, it will just be in each node's respective mempool.


With 100% segwit transactions, what would be the max number of transaction confirmation possible on a block? With 100% segwit transactions, what would be the max number of transaction confirmation possible on a block?

And, how many utxo can be updated by a block full of segwit transactions?

Very interesting question, let's see what the smallest transaction we can build is. For it to be minimal it has to be a single input and a single output. The non-segwit part would look something like this:

4 bytes version
1 byte input count
Input

36 bytes outpoint
1 byte scriptSigLen (0x00)
0 bytes scriptSig
4 bytes sequence

1 byte output count

8 bytes value
1 byte scriptPubKeyLen
22 bytes scriptPubKey (0x0014{20-byte keyhash})

4 bytes locktime

This sums up to a total of 82 bytes for the non-witness part. So with a total non-witness blocksize of 1 million bytes we get a maximum of 12195 transactions. Assuming that all spent outputs were P2WPKH the witness part for each transaction consists of two pushes: one for the signature and one for the pubkey. These are around 72 bytes and 33 bytes long, and each need a length prefix of 1 byte. Additionally there is 1 byte witness version. So the total witness size is 108 bytes. With 3 MB of space in the witness block left, this brings us to about 27777 witnesses per block. So the limiting factor is the space in the non-witness part of the block, so that's the final number that we should consider.

Notice that I used the non-segwit serialization for the non-segwit part since that is what non-upgraded nodes will enfore. Notice also that this is an extreme example, since most transactions are not single-input-single-output. A corresponding non-segwit transaction would have a size of 192 bytes, which, together with the 1MB size limit brings us to 5208 transactions per block, compared to 12195 max segwit transaction per block.

The second part of your question regarding maximum UTXO in a block is rather easy. We'd like to amortize the overhead from the transaction structure, and maximize inputs + outputs. Since inputs are larger than outputs we will simple use a single input and compute the maximum number of outputs that fits in a block which is 32256. Since the outputs are non-segwit data, it also changes minimally from before the segwit activation (only the signature from the one input is moved to the segwit part). Therefore the maximum UTXO churn is 1 UTXO gets removed, 32256 get added. For comparison, without segwit the maximum number added was 32252. Notice that there may be other limits that I haven't considered, but this definitely are the upper limits, and these limits are unlikely to have changed during the activation of segwit.


How do more leading zeroes make it more difficult to find a block? A couple of articles describing the process of mining do say that the more miners are in the network, the more 0 numbers are included in the encoded hash of the particular block. I cannot find an answer to the following question:
why does adding more zeros at the beginning of the hash make it more difficult to calculate?

Adding more zeroes (more precisely as a prefix) to the required block hash (which is the hash of block header) makes it more difficult because you need to keep hashing the block header until you find a hash value that is less than the required maximum numeric hash value (you update the block header everytime by incrementing the nonce in it which changes the block header. Presently because of ASICs this field is too small, so the extra nonce is stored in unused locking script of Coinbase transaction, which as a result changes Merkle root which is part of the block header). Here is a documentation of what goes into block header:

https://en.bitcoin.it/wiki/Block_hashing_algorithm

Mathematically to make sense of it, think of it this way, if I ask you find a number at random from 0 to 100 less than 90, how many times do you have to try before you get a number for sure less than equal to 90? It is exactly 10 times. This same principle applies to SHA-256 of the block header.


2 bitcoinqt - getrawmempool returns different results I have 2 servers with running the same Bitcoin Core v0.9.3.0-g40d2041-beta (64-bit).
I use getrawmempool to get all new transactions in the same time but I have different result. One server always have more transactions. Difference quite big - about 10%.

Why?

I am trying monitor all new transactions for some reasons and this difference means for me that getrawmempool not is not good way for this.

Why do you expect them to be identical?

There are no guarantees about synchronization between mempool contents. In fact, if there was, we wouldn't need a blockchain at all. We'd just use "time of entering mempool" to order transactions.

Transactions are relayed across the network, but under various conditions, and usually the mempool contents reflects what a node decided to relay.

Reasons for variations between nodes:

Only the first of two double spends will typically enter the mempool (but some nodes use different policies, such a replace by fee).
There are various versions of nodes out there, with different relay fee requirements.
In some cases, relay is subjected to rate limiting, which means arbitrary dropping of transactions.
Standardness rules have changed over time, changing which types of transactions are accepted into the mempool.


How To get Address Public Key from Account XPUB? I am little bit confused or not able to get the right Address Node Public key from Account XPUB.
What I have done :

Get the Account XPUB [78Bytes]

SHA-256

SHA-256 Again

Created Extended XPUB (XPUB + 4 Start Byte of Step 3)

Base 58 ENC

hdnode_deserialize()

Account Node  Change Node

Change Node  Address Node.

But am not able to get the right Public Address.
Please let me know if I have done something wrong.

To go from account xpub to address, you must first derive an xpub at the External index (0) or Internal index (1), then derive another xpub from the External/Internal xpub. Take the public key from the resulting xpub and this is the public key used for the address.
For a detailed explanation of extended public keys and how to derive child public keys, take a look at the BIP32 documentation. For a not-as-in-depth breakdown of deriving addresses from an extended public key (which is exactly what you're trying to do), I have written this writeup.


problem when start using cpuminer / cudaminer I got this in the CMD :

cgminer.exe is not recognized as an internal or external command, operable program or batch file

I have downloaded cpuminer and cudaminer to mine LTC with my labtop (core i7, Nvidia GT 525 M)

using www.wemineltc.com  pool

but when I double click the .bat  file (cmd flash for a sec)  then nothing happen

can someone  help me please ?

i  have used this tutorial : https://teksyndicate.com/forum/litecoin/guide-mining-nvidia-now-guide-mining-feathercoin/137688

I think that you configured the batch file incorrectly. It seems as if your batch file is beginning with a call to cgminer when either

A) You don't even have cgminer installed, you didn't mention installing it whatsoever. Download cgminer, and relocate the batch file in the application directory.

B) Your batch file calls cgminer, and it can't find it. Either move the batch file to the cgminer application directory for cgminer, or go in and edit the batch file to call either 'cpuminer' or 'cudaminer' (this should be the first word in the file) depending on which .exe you want to run.


Why are exactly 4 bit windows used in the lookup table of libsecp256k1 to speed up point multiplications? From the Readme of secp256k1 we can see the following:

Use a precomputed table of multiples of powers of 16 multiplied with the generator, so general multiplication becomes a series of additions.

I was wondering why in particular the table used precomputed table of multiples of 16? I would have expected a higher number or a more dynamic approach which includes dynamic caching.
Let me elaborate a little bit:
With multiples of 16 we always need 4 bit computed in the table. meaning we have 256 / 4 = 64 buckets with 16 entries for each bucket.
Let n be the number of bits in a window for which we compute powers of g this would result in the general formula for the amount of precomputed values in our table for n > 1:
256 / n * 2 ^ n
with n = 4 we have 64 * 16 = 1024 entries.
When choosing n = 8 we would have 32 * 256 = 8192 entries. However when actually computing a multiplication we would only need 32 additions instead of 64. creating a speedup of a factor of 2 for 8 times us much memory usage of our lookup table.
With n = 16 we would have 16 * 65536 = 1048576 or 1M * sizeof(point) of main memory to have only 16 point additions when computing a multiplication.
Obviously such a big lookup table requires some time when setting up the library. Even if the table was already precomputed and in binary shipped with the library.
Anyway I was wondering for the particular choice of 4 bits. I would assume that 8 bits was better and probably even taking 16 bit windows seems fairly reasonable.

What you are talking about is the table used for constant time operations w/ secret values, e.g. for signing and key generation (see the heading "Point multiplication for signing").  To prevent leaking secret key data the entire column must be processed for each digit. More bits in the column increases this work exponentially.  From memory, I believe that 5 bits was similar but slightly better performance on systems with big fast caches and memory busses, but worse performance on systems with slow memory.

There are other ways that we could increase performance there (e.g. constant-window NAF, or the techniques from PR546) but we don't generally consider signing/key generation performance to be terribly important. I think generally our only strong goal wrt that performance is to be no slower than less carefully developed alternative software.

You can try changing the sizes with a few lines changed in the software.

The variable time multiplies in the library use much larger tables and fancier techniques.


How does one send and receive Mastercoins? I don't really understand how the Mastercoin mechanics work, do I need a special client when operating with Mastercoins? And how should I proceed with the initial investment?

If I were to recieve MCSs would I use my BTC wallet and if so how do I know the amount of MSCs in my address?

To send or receive MSC, you only need a Bitcoin wallet when you have control over the private keys. so web wallets don't count


Can I setup a DNS seed? I'd like to setup a Bitcoin DNS seed node for learning purposes. Would I be able to actually aid in the peer discovery process? How would my dns be discovered so that it could be queried?

The DNS seed addresses are hardcoded into Bitcoin Core (or other clients).  You would need to convince the Bitcoin Core developers to add your seed node to the hardcoded list.

You can find here a list of the requirements you'd be expected to fulfill.


Why is Block Explorer so slow? Why is the Block Explorer so slow?  It used to work reasonably fast, and now it just spins and spins for 20 minutes?  Is it doing some kind of timing out?

This is a very important utility for the whole Bitcoin network and it is in everyone's better interest that they can look up Bitcoin values without having to have an account somewhere.

On what pages is it slow? It only seems a little slower for me.

The "mirror" (which is actually usually the main server) went down for a while, so BBE switched to my server, which has much fewer resources.


Is it possible to copy other scriptSig for using in different transaction? To use a UTXO one must supply correct scriptSig or "unlocking script" to the given scriptPubKey "lock script", I know the scriptSig in PTPKH locking is sig and pubkey. My question is what makes the sig be unique to the specific UTXO ?
It must be, otherwise I can take it and use it in different UTXO which has the same scriptPubKey .

No, because clients use SIGHASH_ALL in their transactions by default, which signs the outpoint you're spending in addition to the rest of the transaction.

People also sometimes add the flag SIGHASH_ANYONECANPAY to SIGHASH_ALL which still signs the outpoint you're spending.


Two errors when trying to run make command I am trying to build Bitcoin Core on MacOs.
Followed instructions here https://github.com/bitcoin/bitcoin/blob/master/doc/build-osx.md
When I run make command, I get these two errors

2 errors generated.
make[2]: *** [libbitcoin_server_a-miner.o] Error 1
make[1]: *** [all-recursive] Error 1

Tried sudo make but results are the same.
Bitcoin core version I'm working with is 0.15.0 (I know it's old but I'm trying to follow instructions from the 'Mastering Bitcoin' book)
EDIT : FULL ERROR

In file included from /usr/local/include/boost/multi_index/ordered_index.hpp:17:
/usr/local/include/boost/multi_index/detail/ord_index_impl.hpp:1253:26: error:
no matching function for call to object of type 'const
boost::multi_index::detail::ordered_index_implboost::multi_index::identity<CTxMemPoolModifiedEntry,
CompareModifiedEntry, boost::multi_index::detail::nth_layer<2,
CTxMemPoolModifiedEntry,
boost::multi_index::indexed_by<boost::multi_index::ordered_unique<modifiedentry_iter,
CompareCTxMemPoolIter, mpl_::na>,
boost::multi_index::ordered_non_unique<boost::multi_index::tag<ancestor_score,
mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na,
mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na,
mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na>,
boost::multi_index::identity,
CompareModifiedEntry>, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na,
mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na,
mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na>,
std::1::allocator >,
boost::mpl::v_item<ancestor_score, boost::mpl::vector0<mpl::na>, 0>,
boost::multi_index::detail::ordered_non_unique_tag,
boost::multi_index::detail::null_augment_policy>::key_compare' (aka 'const
CompareModifiedEntry')
return y==header()||!comp(key(y->value()),key(v));
^~~~~
./miner.h:74:10: note: candidate function not viable: 'this' argument has type
'const
boost::multi_index::detail::ordered_index_implboost::multi_index::identity<CTxMemPoolModifiedEntry,
CompareModifiedEntry, boost::multi_index::detail::nth_layer<2,
CTxMemPoolModifiedEntry,
boost::multi_index::indexed_by<boost::multi_index::ordered_unique<modifiedentry_iter,
CompareCTxMemPoolIter, mpl_::na>,
boost::multi_index::ordered_non_unique<boost::multi_index::tag<ancestor_score,
mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na,
mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na,
mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na>,
boost::multi_index::identity,
CompareModifiedEntry>, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na,
mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na,
mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na>,
std::_1::allocator >,
boost::mpl::v_item<ancestor_score, boost::mpl::vector0<mpl::na>, 0>,
boost::multi_index::detail::ordered_non_unique_tag,
boost::multi_index::detail::null_augment_policy>::key_compare' (aka 'const
CompareModifiedEntry'), but method is not marked const
bool operator()(const CTxMemPoolModifiedEntry &a, const CTxMemPoolMo...
^
2 errors generated.
make[2]: *** [libbitcoin_server_a-miner.o] Error 1
make[1]: *** [all-recursive] Error 1
make: *** [all-recursive] Error 1

This issue caused by newer versions of Boost was later solved. You may either checkout v0.15.2 or download the 0.15.2 tagged source code here


allowed DER encoding format violations for signatures in bitcoin: implications for libraries? I have recently changed verification code in python-bitcointx to use libsecp256k1 library.

In the python-bitcoinlib code (that python-bitcointx is a derivative of), openssl functions were used for signature verification.

I want to be able to remove dependency on openssl in the future, and use only libsecp256k1 in python-bitcointx, but there is a problem that I noticed when I re-wrote CECKey.verify() method:

libsecp256k1 function secp256k1_ecdsa_signature_parse_der() only allows strictly valid DER-encoded signatures.

bitcoind uses ecdsa_signature_parse_der_lax() function, copied from libsecp256k1's contrib/ directory. This function is not compiled in a normal compilation cycle of libsecp256k1.

It is expected for bitcoin-focused library to be able to verify signatures that bitcoind will also verify.

To be able to verify non-strict-encoded signatures with libsecp256k1, I see 3 options:

  EDIT: I might just implement two verification methods, strict and non-strict, and then use them in tests. openssl dependency will stay because of verify_nonstrict().

get ecdsa_signature_parse_der_lax() function from libsecp256k1/contrib, add it to python-bitcointx repository, compile at python package build time, install with a package.

This is not desireable, because it adds requirement to have C compiler to build the python package. In some environments this may be inconvenient.

re-implement ecdsa_signature_parse_der_lax() in python

I would like to avoid this, to reduce the size of the code (reduce the surface where bug may be introduced). Porting this function correctly will require to invest some time.

It will also make verification slower to some degree, because more operations will be done in python, vs calling C functions.

do a cycle of decode-with-openssl / encode-with-openssl / decode-with-libsecp256k1

This way all encoding violations that openssl allows are also allowed by first decode-with-openssl. encode-with-openssl then creates valid encoding, and decode-with-libsecp256k1 is happy.

The problem with this approach (in addition to this decode/encode cycle) is that it will allow some format violations that bitcoind won't allow, because ecdsa_signature_parse_der_lax() only allows an arbitrary subset of violations allowed by openssl.

python-bitcoinlib was using openssl to decode, too, so I went with the later approach - decode/encode/decode. This means I cannot drop openssl dependency.

My question is: what may be the implications of this choice ?

What I can see is that when someone uses python-bitcointx or python-bitcoinlib to verify inputs in some transaction, and these inputs contain signatures that is accepted by openssl, but not by bitcoind, they might be convinced that tx is valid, but will have unpleasant surprise when they try to broadcast it.

With some protocols that require parties to store signed transactions, that might be relevant.

As this is historical behavior of python-bitcoinlib, I am inclined to just document this in the README.md as a 'gotcha', and leave it as it is now.

But maybe there is some other potential problems that could arise out of this issue, that may be more serious, and the first or second options described above should be considered ?

It isn't clear to me from your question what your goal is.  If you want to accept all transactions and only transactions that Bitcoin would accept, libsecp256k1 alone is what you want. (You may need to use the signature normalize call if you want to match consensus acceptance instead of standardness acceptance).

If you want to validate historical signatures from the blockchain then either openssl or the code in contrib is sufficient. If you use either of these things on current transactions you will accept things that Bitcoin will reject.

We, the authors of libsecp256k1, are currently of the belief that no application should use a lax parser, except for historical compatibility. Unfortunately, no function is likely to be universally compatible with OpenSSL's parser except OpenSSL itself... but for cases where the set of signatures that you need to be compatible with is known a specific alternative lax parser might work, as is the case for Bitcoin's history and the lax parser in contrib.

The contrib lax parser isn't included in the library because it's only provably sufficient for Bitcoin's history. Someone trying to lax-parse a different set of signatures may need to modify that lax parser to accommodate the specific weird signatures that they're dealing with.  We also, in general, don't think anyone should be lax parsing unless its strictly needed since it can result in surprising vulnerabilities.

As an aside, in the current versions of OpenSSL the ECDSA validator attempts to validate signature encodings by checking that the serialization is unchanged under decode and encode and it rejects signatures that aren't.  This likely means they reject any signature that libsecp256k1 (with normalize) rejects.  [And annoyingly, OpenSSL made this breaking change in a security update.]


estimatesmartfee outputs very different results Around block 564815 (2019-02-26 23:40 UTC), the mempool was empty. I noticed that my two nodes are giving very different estimates for transaction fees to be used:

Node 1

Version: 17.1.0
Number of peers: 21
Synched for: about three weeks
Prunned: 3GB

// see how many transactions are there in the mempool
 >bitcoin-cli getrawmempool | wc -l
 4027

>bitcoin-cli estimatesmartfee 5 {
    “feerate”: 0.00021195,
    “blocks”: 5 }

>bitcoin-cli estimatesmartfee 5 ECONOMICAL {
    “feerate”: 0.00009715,
    “blocks”: 5 }

Node 2

Version: Bitcoin core 17.0.0
Number of peers: 8
Synched for: about 5 hours
Prunned: 3GB

# see how many transactions are there in the mempool
>bitcoin-cli getrawmempool | wc -l
3999

>bitcoin-cli estimatesmartfee 5
{
    “feerate”: 0.00008823,
    “blocks”: 5
}

>bitcoin-cli estimatesmartfee 5 ECONOMICAL
{
    “feerate”: 0.00001000,
    “blocks”: 5
}

The node that has been synchronized for only 5 hours and is less well connected seems to be estimating the fee better than the one that has been synchronized for three weeks. Why is the "best" node the one that gives the worst fee? Why are the fee estimates so different and what can be done to make them more accurate?

The node that has been synchronized for only 5 hours and is less well connected seems to be estimating the fee better than the one that has been synchronized for three weeks. Why is the "best" node the one that gives the worst fee?

Just because the fee is lower does not mean it is better.

The fee estimator tries to estimate the fee the balances between cost and time to be included in a block. It does this by looking at the fee rates of transactions that it receives in its mempool and seeing how long it takes for transactions at a given fee rate to be included into a block. It becomes more accurate as it sees more transactions and more blocks because it has had more data to analyze.

So your two nodes are giving wildly different numbers because of their uptime. Node 1 has been online for much longer. It has seen more unconfirmed transactions become confirmed thus its estimator has had more data to observe.

However Node 2 has not been online as much so it doesn't have as much data. It hasn't seen as many blocks and as many transactions become confirmed. Since it has a lack of data it resorts to the fallback values. These values are the minimum relay fee rates which are not likely to actually be the true fee rate. The minimum relay fee rate is not the minimum to be included in a block, it is the minimum for a node to even relay your transaction to another node.

  what can be done to make them more accurate?

Just wait. Leave the nodes online. The estimators require data and the only way to do that is to wait. They become more accurate over time.


Mining on your own network, or creating your own mini pool I have one computer set up and solo mining away. The bitcoin client is running in server mode, and bfgminer connects to it with -o 127.0.0.1:8332.

I have a second computer that I'd also like to mine with too, but using the first computer as the server, so that I only need one instance of the blockchain/bitcoin client. Is that possible?

I tried to connect to it with -o 192.168.1.8332, which my router tells me is its network address. But bfgminer fails, saying that I probably got the address wrong.

The firewall is allowing bitcoin-qt.exe through, and I set it to allow port 8332 too, just in case.

I finally sorted this out, so I'm back 17 days later to answer my own question. I also wrote a short article about the steps, should anyone else need them.

Here are the basic steps. The coin is referred to as Coin, as this works with all sha256 coins, and probably (untested by me) Scrypt variants as well. If not, the process will be very similar.

To start, your coin.conf file should look something like this:

daemon=1
server=1
listen=1
gen=1
rpcuser=uncle_bubs
rpcpassword=your_mother
rpcallowip=127.0.0.1
rpcport=8332

In your coin.conf file, add the line rcpallowip=12.34.56.789, replacing the IP address with the address of the computer you want to allow, or more simply rpcallowip=192.168.1.* to allow any IP address on your network. You can have as many rpcallowip lines as you want. Note that doing this will send your password unencrypted over the network, so it’s not recommended except within a secure network that you control.
Make sure your firewall is allowing incoming connections to coin-qt.exe.
Start coin-qt.exe -server on your server, and give it a moment to get caught up. (You should have the blockchain current before starting).
On your second computer, go into your router’s admin settings and look at the connected devices. This is usually done by entering 192.168.1.1 in a browser. You’ll need the router username and password to get in.
Look for the computer running your server. Mine was 192.168.1.8.
Now add that IP address and computer to the list of reserved addresses. The reason is that even if you leave your computer plugged into the same router all the time, it sometimes shuffles IP addresses unexpectedly. This is normally not a problem, but you need a fixed IP address to connect to. This step ensures your server always has the same IP address.
Finally, start your second miner, using the new address and port obtained from your router settings. Mine was 192.168.1.8:8332.


Syncing blockchain with prune enabled I'm syncing a node with prune enabled. Will it download the whole blockchain and then prune to my given settings after, or does it prune as it syncs?

I'm currently 34.85% synced
Blockchain directory is 1.3G
Prune depth is 500

It will prune as it synchronizes. Disk usage shouldn't ever reach more than a few GB plus what you configured the pruning limit to.


Vanitygen: Why is it easier to generate an address that starts with a capital letter? I get a much lower length of time if i make the first character a capital letter instead of a lowercase letter, when trying to generate a public key with Vanitygen.

Shouldn't it be the same? Has anyone else experienced this? What is the math / logic behind this difference?

I'm copying this from deepceleron's post on bitcointalk:

  The change happens at a particular address:

  prefix difficulty: 77178 1QLa
  prefix difficulty: 78362 1QLb
  prefix difficulty: 4553521 1QLc

  This is a quirk of how the 25-byte (50 digit hexadecimal) Bitcoin
  address is converted into Base58 (represented by numbers and letters),
  and the different maximum values that can be stored in 25 base256
  digits vs 34 base58 digits.

  The Bitcoin address in it's native binary form (that you never see) is
  25 bytes, it's parts are:
  byte 0: Network ID Byte (0x00 for main
  bitcoin network)
  byte 1-20: ripemd160 hash (20 bytes) of sha256 hash
  (32 bytes) of 0x04+public key (65 bytes)
  byte 21-24: checksum: first
  four bytes of sha256 hash of sha256 hash of bytes 0-20 above

  This would be 50 hexadecimal characters long (base16), with a possible
  digit value between 0-F.

  We will ignore byte 0, it is always 0x00, and Base58 conversion always
  preserves this leading 0 byte by directly encoding it as a "1".

  That means the "vanity" part of the address is bytes 1-24, 24 bytes of
  random hash output, or 48 hexadecimal digits. The maximum value that
  this can be is 0x FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF
  ffff ffff (the lower case "f"s are the checksum, and won't be all
  FFFFs for the maximum ripemd160 value.) We can guess from the output
  below that this maximum possible address value encoded in Base58
  becomes 1QLbxxxxxx.... something:

1QLa8LNNFeYs7KJWvxMdR5YtRjkwtQtkyb
1QLabhman6ZQyz3musbqV1RjFmE3pyT29j
1QLaJHv2LCSYo8WgT9qPf4rdttduRGyozX
1QLarwzJCUWGuQEZ4uWPsYVz8N2P5XmeQU

1QLckWG2tx17suupYU2FfeWunTCZMuJKW
1QLcMk7NVLwvg8gw2ihJTuG8x7WLYCjMg
1QLcLr6AoN687CpH1JZnfeMmWvUka5NHX
1QLc47945bSCv4J1Z4yRuvUbtooQqmGJ1
1QLcU9NNxaqfvqMRXD8dFtL2SktL3YmBT
1QLc1D24uDbvy327MzifEChVvATAeDsbF

  See how the 1QLa addresses are full length, but the 1QLc addresses are
  one digit shorter? That is because the only way to have an address
  starting at 1QLc or greater is by having a binary address that is 59x
  smaller.


signrawtransaction of a P2SH-P2WPKH spend seems to be broken? I'm trying to spend a SegWit output on testnet using the Bitcoin core's RPC commands.
Without importing the private key into my wallet (i.e. w/o addwitnessaddress).
I wonder if anyone had luck spending SegWit outputs this way? Perhaps the signrawtransaction is broken in this case?
Here are the commands and my results.
What's weird is that even though the signrawtransaction itself is successful, the transaction is not valid (rejected by sendrawtransaction and rejected by block explorers as I'm trying to push it, as well).

(Please note: every time I import the key into the wallet and do an "addwitnessaddress" everything works just fine).

./bitcoin-cli -testnet createrawtransaction '[{"txid":"03a4ffcc792525b4ddaecc05054114f2ad8aff8b7563cd41cdb496e2177d0117","vout":0}]' '{"mwCwTceJvYV27KXBc3NJZys6CjsgsoeHmf":0.8}'

020000000117017d17e296b4cd41cd63758bff8aadf214410505ccaeddb4252579ccffa4030000000000ffffffff0100b4c404000000001976a914ac19d3fd17710e6b9a331022fe92c693fdf6659588ac00000000

./bitcoin-cli -testnet signrawtransaction 020000000117017d17e296b4cd41cd63758bff8aadf214410505ccaeddb4252579ccffa4030000000000ffffffff0100b4c404000000001976a914ac19d3fd17710e6b9a331022fe92c693fdf6659588ac00000000 '[{"txid":"03a4ffcc792525b4ddaecc05054114f2ad8aff8b7563cd41cdb496e2177d0117","vout":0,"scriptPubKey":"a91421ce1507d06ed2742be0bf18a018bbcdd812a26487","redeemScript":"00149835f2e0dff9d7f6a4060140696bc7e00b12edd5"}]' '["cMahea7zqjxryy6NWaKxmhDyb1JzuNKCZAg8sxaJoXSBkRXjnib9"]'

{
  "hex": "0200000000010117017d17e296b4cd41cd63758bff8aadf214410505ccaeddb4252579ccffa40300000000171600149835f2e0dff9d7f6a4060140696bc7e00b12edd5ffffffff0100b4c404000000001976a914ac19d3fd17710e6b9a331022fe92c693fdf6659588ac024730440220452a58cf56c45edaffb952acccd2f6f2cea523cf82e73b82f8eb5e3b3b1b17c4022011de26884cf693b12f16fdd8fa6c1d96dacb97050907353852895d9b80b3fae101210206f4bad90006f70112129815b25ba585484f1bb4f8b88f8ebaec2c76f543794300000000",
  "complete": true
}

./bitcoin-cli -testnet sendrawtransaction 0200000000010117017d17e296b4cd41cd63758bff8aadf214410505ccaeddb4252579ccffa40300000000171600149835f2e0dff9d7f6a4060140696bc7e00b12edd5ffffffff0100b4c404000000001976a914ac19d3fd17710e6b9a331022fe92c693fdf6659588ac024730440220452a58cf56c45edaffb952acccd2f6f2cea523cf82e73b82f8eb5e3b3b1b17c4022011de26884cf693b12f16fdd8fa6c1d96dacb97050907353852895d9b80b3fae101210206f4bad90006f70112129815b25ba585484f1bb4f8b88f8ebaec2c76f543794300000000

error code: -26
error message:
64: non-mandatory-script-verify-flag (Signature must be zero for failed CHECK(MULTI)SIG operation)

The wallet does not know how to sign for segwit stuff until you use addwitnessaddress. This is because it is only tracking the P2PKH outputs for that key. You have to explicitly tell it to track the witness outputs for the key by using addwitnessaddress.


Will I need to keep track of my old private keys forever? Let's say someone (person A) starts using Bitcoin and in a period of time eagerly publishes some of their randomly generated (eg. by the Satoshi client) receiving Bitcoin addresses on formus, sends some other addresses to some people etc.

The old keys are now associated with person A, and in a couple of years, some people might want to send person A some funds; they might find one of these old addresses (on an old forum post or in an old private Bitcoin address book) and use them.

But by now, A has moved on to using another wallet instead of the original Satoshi client, and moved all their funds there.

Doesn't this mean that A will forever have to keep track of all the original (non-deterministically generated) private keys of all the addresses that he might have sent, or made available, to other people, and keep importing them into new wallets whenever he moves to a new wallet system, and keep backing them up (safely), etc.? This seems very tedious and error-prone.

I know it's recommended to use a new address for each new transaction, but that's in no way enforced, and more importantly, it's out of person A's control -- it's all the other people that might want to send them money.

This problem will be less important in the future (eg. with deterministic key generation that requires only the seed to be backed up), but someone using the Satoshi client extensively and freely in the past might never be able to make a clean cut.

So is this a real problem or do I understand things incorrectly? Maybe there's a simple (and safe) workaround, or maybe this is not so cumbersome after all?

I think the core of the problem is that we call base58-encoded public key hashes "addresses", no matter whether people are willing to accept payments to them.

In my opinion, they are just identifiers for a public key - something internal in Bitcoin's technology. Humans shouldn't ever see them, unless they are debugging.

Satoshi originally didn't intend to use the current base58 addresses as "payment destination" - he thought pay-to-IP (where the public key was negotiated on the spot) would be the common way of doing transactions. The pay-to-pubkeyhash-via-P2P was only added later for cases where the receiver was offline. Pay-to-IP had several problems, and became obsolete, but it had a lot of advantages compared to what we have now. I think the solution is going back to something like that, like a pay-to-URI where again keys are negotiated at the time of the transaction. It means you're always sure the key used is still active, private keys don't need to be retained forever, no key is ever reused (better for Bitcoin's privacy model) and you instantly get support for attaching messages or refund information to transactions.

Of course, people will probably keep the private keys anyway, for example in an archive wallet like mentioned in other answers to this questions. But in my opinion, it shouldn't be a disaster when people don't.


Are there any pools or large miners running "child pays for parent" patch? A feature available through pull #1647 gives the recipient of a transaction a method to help get a transaction to confirm.

This feature is called "child pays for parent", and what it means is that the recipient of a transaction can create a new transaction using funds from the unconfirmed transaction, but any fee paid would help get both transactions confirmed.

A scenario where this is useful is where a merchant requires that a transaction have three or six confirmations before the item will be shipped out, but the payment the customer made ended up being a low-priority transaction due to it including many Bitcoin "dust" inputs.  The merchant then creates a spend transaction using the funds received but pays a fee that will encourage miners to include both transactions.

Since this feature is not in the Bitcoin-Qt/bitcoind client, only miner pools that have a custom client that includes this pull will consider the fee paid by any child transactions when determining if a transaction should get included into a block.

Are there any miner pools or large solo miners who are running with this feature?

According to an offshoot reply in bitcoin-talk it appears that the only mention of this protocol comes from Luke-Jr on Github.  Another topic on bitcoin-talk mentioned that his pool, elegeius, implements this patch.

https://bitcointalk.org/index.php?topic=173169.0

On the eligius FAQ page http://eligius.st/~gateway/faq/following-applies-transactions-being-processed-our-blocks

It mentions specifically = Transaction processing/priority contracts are available (talk to Luke-Jr).


Why is the value of the input way higher than the output resulting in a second change output? Background: I'm experimenting on the LTC testnet client.

My client has a balance of 0.4 LTC and I sent 0.1 LTC to another wallet address.

https://chain.so/tx/LTCTEST/cc7d6e5e488593fded214e3073195fbaca3807a27d18a7f2550b6fc4909c48f6

Why is the value of the input 0.19 instead of 0.1? Why is this type of transaction created?

Why can't a transaction just be created with 0.1 input and 0.1 output without any change returned?

Thanks in advance.

Why is the value of the input 0.19 instead of 0.1? Why is this type of transaction created?

Bitcoin works on a system of transaction outputs. Transaction outputs are spent as inputs to another transaction. When they are spent, they must be spent in full. The input of your transaction is spending an output with value 0.19, so all 0.19 Bitcoin must be spent in full in this input. The remainder must then be sent to a change output.

  Why can't a transaction just be created with 0.1 input and 0.1 output without any change returned?

Inputs don't actually have a value attached to them; what block explorers show you as the input value is really the value of the output being spent.


Risk to Bitcoin balance when making Bitcoin Gold transactions If Bitcoin Gold fails to implement replay protection, will I risk losing my Bitcoin when I make a Bitcoin Gold transaction?

Assuming replay protection is not implemented properly, how can I protect myself?

Here is an article answering this very question https://bitcointechtalk.com/how-to-protect-against-replay-attacks-7a00bd2fe52f.

Through either careful transaction construction, using timelock supporting wallets, or simply waiting some time for things to be settled, you'll be safe.


Open source bitcoin wallet Can anyone recommend any open source code for bitcoin wallet or any bitcoin applications or clients?

please posts links or samples of it.

thank you

Based on your ignorance of where to begin, I would strongly encourage you to use one of the existing wallets rather than trying to reinvent the wheel.  That said, if you're just using this as an exercise to learn the code, poking around in the code can be a great way to learn.  So here's what I can tell you about the wallets.

1) Bitcoin Armory is the most full featured wallet, in my opinion, at the cost of using the most resources from your computer.  It's the one I use so I know the most about it out of all the wallets.  It used to load the blockchain into memory, but as the blockchain grew rapidly, that approach made Armory so RAM intensive that it was essentially unusable for everyone but those with a LOT of RAM.  If you want to use that old version, I'd recommend 8 GB+ RAM, the more you have, the better it'll run especially over the long haul since the blockchain is only going to get bigger.

The core developer of Armory, Alan, realized this approach was unsustainable for the majority of Armory users so he redesigned it so that it now makes a copy of the blockchain and uses that instead of loading the entire blockchain.  The catch is, of course, that this means that using Armory as a full client means using 2X the size of the blockchain.  At present day, the blockchain uses up 22.6 GB according to my computer, so double that for the amount of space on your hard drive Armory needs.  It's a resource hog either way, but the tradeoff he made makes sense in my opinion since hard drive space is generally a lot more plentiful than RAM, and acquiring more if need be is also a lot cheaper.

Armory is written in python.  I haven't looked at the code, but Alan has said on the bitcointalk forums that it's very well documented.  It has some very useful features including: a deterministic wallet, meaning that one backup will last you forever, regardless of how many addresses you use; cold storage that's easy to use, which is for most people the biggest benefit of Armory; and for web developers, there is an Armory Daemon that you can run on your website to accept bitcoin payments.  Unfortunately, it is no less resource intensive than the desktop version, and thus impractical unless you have essentially unlimited space on your web host.

2) Electrum is a lightweight bitcoin wallet that is also written in python.  Unlike with Armory, Electrum stores the full blockchain on servers that you access via the client / server model.  This means that Electrum uses no where near the amount of resources of Armory, it only requires that you host your wallet on your computer.  Electrum also supports cold storage and wallets can be recovered using a seed, meaning that you do not need to perform regular backups, you just need to ensure that you never lose / forget that seed.

3) Multibit is also a lightweight wallet that is written in Java.  It also operates on the client / server model like Electrum does.  According to Multibit's FAQ, the portion of the blockchain that a user has to store is only about 25 MB, in other words, only containing your own transactions.  If you're not familar with how Bitcoin works in general, I would encourage you to check out Multibit's FAQ as it explains not just Multibit but how Bitcoin in general works.  Multibit's website does not advertise a deterministic wallet feature like Armory and Electrum do, so it may require regular backups like the original bitcoin wallet.

4) Hivewallet is also a lightweight wallet that is written in Java.  Like Armory and Electrum, it is also deterministic.  According to its website, all you have to do is backup the password and you're set.  Hivewallet runs on OSX and Android Operating Systems.

5) Bitcoin core is the original bitcoin wallet.  Unlike Armory and Electrum, it is not deterministic.  Because of this, it is not recommended that you use this client to store your bitcoins because unlike the deterministic clients, it will require regular backups.  It is written in C++.

If you still want to dive into the code, I'd encourage you to pick a wallet where you're already familiar with the programming language to start with to simplify the learning curve so you'll only have to learn that wallet's code instead of that wallet's code and that programming language.


Print all states of getting from a random 256 bit private key to a corresponding encoded BTC address I wonder if it is possible to print what's going on under the hood regarding the process of getting from a random binary number to a BTC address.

It will look something like this:

Input: a random 256 binary number

Output: print()

Printing all possible sequential states from that number to a BTC address.

PRIVATE KEY STATES

binary privKey [k] -> decimal privKey -> hexadecimal privKey -> WIF privKey

PUBLIC KEY STATES

decimal pubKey print(x,y) -> print K where [K=(x,y)] -> hexadecimal PubKey (A) -> print A=RIPEMD160(SHA2569(K))

It will help a lot of people interested in the details of creating BTC addresses, from the elliptic curve private to public key process (K=k*G) to the other encoding steps until the final address.

On GitHub and other places, .js or .py libraries just print the WIF key and the address, and sometimes the hexadecimal public key as well.

Thanks.

The bitcoin developper pages show the steps in all details for type 1 addresses.

For the type 1 addresses, there is a good link here to test results.

Then there is HD wallets, Segwit, and many other extensions...

Maybe it is good to start for type 1 addresses, and extend with your ideas of "under the hood crypto". I stick to Nate's comment though.


What is vanity address? I saw lot of questions about vanity addresses, but not sure what is vanity address. Could someone please explain?

thanks.

It is the same thing as a vanity plate which are used for cars. That is: An address which you choose yourself (or at least part of it). For example the address of Bitcoin24 is 1BTC24yVKQdQNAa4vX71xLUC5A8Za7Rr71 (watch the first six characters!).

See this question How can I generate a vanity Bitcoin address?


How many Namecoins are generated per block? Is the block reward for Namecoin 50 like Bitcoin, or is there another figure?

Yes, it's 50, as documented here:
http://www.bluishcoder.co.nz/2011/05/12/namecoin-a-dns-alternative-based-on-bitcoin.html

The reward for solving a block will halve every 210,000 blocks (around 4 yrs), like Bitcoins.

When namecoins are spent to register a domain name, they are destroyed. More details here:
https://github.com/vinced/namecoin/blob/master/FAQ.md

Note that even though the mining reward remains constant, the network fee to register a domain goes down quickly over time. Quote: "The network fee is initially high, but will be negligible after a couple of years. It is used to slow down the initial registration rate so that plenty of desirable names are left for late adopters."


Where is the data stored in Bitcoin? Is all the data related with the transaction of bitcoin stored in blockchain or the data stored somewhere in the cloud and they are referenced from blockchain. I have this confusion because if we are storing all the transaction information on blockchain then it will become heavy with time. How it will get managed at storage level (if the data is in blocks).

The size of each block in bitcoin is 1 MB, is it sufficient to store all the data (of every 10 mins) in the blocks?

The blockchain (at least as far as Bitcoin goes) is a series of transactions, collected in blocks.

This data is stored on each and every full node (pruning aside). There is no cloud based storage as part of the bitcoin network, although third parties host various forms of parsed data in the form of explorers and other such products, some of which may use cloud storage (assuming by "cloud" you are referring to AWS/GCP/similar offerings).

The bitcoin network itself is self sufficient and requires no third party resources. When a new node joins the network, it simply downloads the historical data from other, existing nodes. There is no need for any other form of storage.


What roles has the TIME information play in the bitcoin header? What role does the time play in the bitcoin header? Is it ok to set it to 1 sec after the last block and never change it while calculating? Will the block be rejected when the gap is to large?

If 2 people get the correct block ( reach the traget ) who will win? Does the time decide?

Information about the header is taken form here:
https://en.bitcoin.it/wiki/Block_hashing_algorithm

the time feature really doesn't play a role in the broadcasting of two simultaneously mined blocks. Those are just handled through broadcasting effect, forking and subsequent blocks mined. Time is started from the moment the miner began hashing to solve the POW. Its used to know how long it took in comparison with recent blocks found for the difficulty re-targeting calculation. It also serves as a record to know when a block was mined.


How do hierarchical deterministic wallets work transaction-wise? As far as I know (and as explained here) hierarchical deterministic wallets keep a master key pair (private and public). When using them the public key is newly generated in every transaction. I understood that child keys are generated by elliptic multiplication of parent keys. Benefits associated with HD wallets are claimed to be:

Better privacy because new public keys are generated in each
transaction;
It is only needed to store one master private key, as
all the other keys can be derived from it; and
It is possible to
store the master public key on an insecure server and still generate
as many addresses as needed without having to leave the private keys
on that server.

While I do more or less understand the theoretical concept, I struggle with the practical implementation of the process, and in particular with how does the system associate the balance from several transactions (allocated to different derived public keys) to the same bitcoin "account" or master public key?

Anyone able to make a "for dummies" clarification?

how does the system associate the balance from several transactions (allocated to different derived public keys) to the same bitcoin "account" or master public key?

The system must known the XPUB (often the master public key) for it to generate all of the addresses to 'watch'.
While we're on the subject of master public keys and privacy, there are many things that you can do wrong. Sharing your master public key (XPUB) is a bad idea, as the other party will be able to see all of your addresses. I've seen a lot of projects doing this, destroying your privacy basically.
BIP47, still a draft and not implemented, aims to solve this privacy issue and still offers the infinity addresses benefit of HD wallets.
But what you describe, the act of sharing a master public key and letting the CLIENT derive the addresses is bad and isn't the case in most systems. It's a lot more likely that the SERVER derives the addresses and keeps the master public key secret.
So, let's assume the following:

We have the public key through which all other new public keys (and thus new addresses) can be derived.

We have received one transaction on address 15.

We're bootstrapping a new node and doing an initial block download, and thus have processed 0 blocks.

We lost our previous wallet.dat file, so we don't have a single clue on which addresses we've received any money. We recover our wallet through the public key as described in 1.
At this moment the HD wallet doesn't really know on which addresses it has received any money, but to check if transactions belong to us it has regenerated a "LOOKAHEAD" of the first 20 addresses. Those 20 potentially used addresses get added to the keypool, all new transactions to these addresses belong to us.

A block gets processed with a transaction to address 15, this falls within our lookahead of 20 so we're able to pick it up. We regenerate more lookahead addresses once we've found a transaction to one of our addresses.
This lookahead is important, let's assume we took a lookahead of 10, we wouldn't be watching on address 15, only up to address 10. We wouldn't see our transaction. (note: this only applies if you've lost your wallet.dat, and recovered from seed)
BIP44 specifies the "address gap limit" to be 20.

Address gap limit is currently set to 20. If the software hits 20 unused addresses in a row, it expects there are no used addresses beyond this point and stops searching the address chain.


Can you pay with Litecoin anywhere you can pay with Bitcoin? Can you pay with Litecoin at any place that accepts Bitcoin? If no where can you spend Litecoins?

Merchants that only accept Bitcoin, will not accept Litecoin directly.

However you can pay any Bitcoin merchant with a 3rd party that automatically converts your Litecoin to Bitcoin. The most well known service of this type is shapeshift.io

Merchants can integrate their "shifty" button to make this easier for consumers to use, but the Shapeshift service is available for every consumer wishing to pay a Bitcoin merchant regardless of if they have integrating the Shapeshift API or not.

https://shapeshift.io/shifty_button.html

https://shapeshift.io/#/coins


How should one try verifying to whom a given Bitcoin address belongs? Lets say, I'd have a website that shows a large number of Bitcoin public addresses, and wanted to give option for anyone that owns a given address to verify it automatically.

Assuming that one shouldn't trust anyone on the internet based just on their word, how should one go about verifying that a person owns a given address? (methods that can run autonomously, without admin input, are preferred)

The v0.5 client (still experimental as of time of writing) supports a function where you can sign a text message with a private key.

So you could:
a) have a "register" button next to the address.
b) provide the user a message to sign which includes some identifying information (account name, email address, etc) and the address.
c) user will run bitcoind signmessage  ""
d) this will sign the message with user's private key.

Only a user which has access to the private key that corresponds to the address in question will be able to generate the correct signature.  Think of it as similar to a Bitcoin transaction but it isn't published to Bitcoin network and involves any text message.

Eligius uses this method to link NMC payment addresses to BTC payment addresses for his pool.

http://eligius.st/

Obviously this will have more value once Bitcoind v0.05 is publicly released.


Port forwarding plus Bitcoin Bitcoin has only 8 active connections, and I read somewhere that it helps to forward ports. I know how to forward a port, but which port should I forward, and how should I tell Bitcoin-qt to use the forwarded port?

Bitcoin has only 8 active connections

Correction: it has 8 outbound connections. By default, it can also accept up to 117 inbound connections

  which port

Port 8333, TCP

  how should I tell Bitcoin-qt to use the forwarded port?

Don't need to.


Do US based exchanges need to file as an MSB with FinCen? What other legal requirements are there and what are the costs of compliance?

Yes - FinCen released details about this within the past month stating that Bitcoin "exchanger" must comply with regulations. Note that this may apply not just to exchange "houses", but also to individuals who exchange Bitcoin for USD. From the FinCen summary:

  A user of virtual currency is not an MSB (money services business) under FinCEN's regulations and therefore is not subject to MSB registration, reporting, and recordkeeping regulations. However, an administrator or exchanger is an MSB under FinCEN's regulations, specifically, a money transmitter, unless a limitation to or exemption from the definition applies to the person. An administrator or exchanger is not a provider or seller of prepaid access, or a dealer in foreign exchange, under FinCEN's regulations.

FinCen statement
ArsTechnica article


Does every nonce really have an equal chance of winning? I set out to test the claim: "Every nonce has an equal chance of winning."

Time Evolution

So, I plotted, with gnuplot, the nonce values vs. hashes for all the valid blocks in the blockchain:(Also, in the last plot, you can really visualize the change in the difficulty and even see where the difficulty was decreased.)

Histograms

It makes sense that the nonces found are skewed toward 0 because this is a selection effect: most everyone starts searching for nonces starting at 0, so the lower nonces are found first, even though there may be also higher nonces that could produce a winning block:

Why are the hashes distributed this way, though?:

2-D histogram of hashes and nonces (logarithmic color scale):

It's not unevenly distributed. The reason it appears that way in the graphs above is because the x-axis is plotted in logarithmic units. Here's what it looks like in linear units:


Where does the term HODL come from? I know that HODL means you hold your crypto for the long run, whether the price goes up or down, but where does the term come from?

I have heard people say it means "Hold On for Dear Life" and other that it was a typo.

There term originated as a forum post in December 2013 as - what I can only assume to be a drunk day trader. That is holding his coins as the price is crashing.

I don't think it was intended to mean "Hold On for Dear Life" but it has definitely grown to mean that as OP explains that there are three people, the losers (inexperienced traders) and winners(experienced traders) and the group in the middle that buy and hold on for dear life. The forum post itself is an interesting read and I defz recommend that you check it out yourself: https://bitcointalk.org/index.php?topic=375643.0


Specific namecoin address in merged mining I want to do merged mining with P2Pool, and I want any generated namecoins to go to a specific namecoin address in my wallet. I haven't seen a way to configure this in P2Pool or namecoind, and Google's turned up no hits. It seems as though it's either too obvious for anybody to mention in any guides, or like I'm the only one who wants to do this. If the latter, then why does nobody want this and why should I not do this?

with p2pool at least for the coins are 'merged' mining you cannot reconfigure them to go to any other account except for the default account of that wallet.  However  you may be able to work around this in one of the following ways depending on your coding ability.
Monitor P2Pool logs and trigger script
Watch the p2pool logs and when a block is found trigger a script.
This can be achieved using swatch (linux tool for watching logs files) and looking for merged blocks that appear in /path/to/p2pool/data/bitcoin/log  (cant find the example merged block right now will edit later to include)  so in this instance what you would do is use this command:  swatch -t /path/to/p2pool/data/bitcoin/log  and create a ~/.swatchrc in your home directory with something like this:
watchfor /SHARE|BLOCK/
    exec echo "P2Pool Event:\n\n$_\n" | python ~/pyPushBullet/pushbullet_cmd.py 6xxxxxxxxxxxxxxxxxxxxxxxx60993c note xxxxxx"P2Pool Notification" "$_"

Im using push bullet to send notifications on share and block notifications.  however in your case you would want to craft a script to check the block itself for merged outputs.
Wallet Notify
Most Crypto Clients now let you configure an action for
  -blocknotify=<cmd>     Execute command when the best block changes (%s in cmd is replaced by block hash)
  -walletnotify=<cmd>    Execute command when a wallet transaction changes (%s in cmd is replaced by TxID)
  -alertnotify=<cmd>     Execute command when a relevant alert is received (%s in cmd is replaced by message)

Courtesy Off The Bitcoin Wiki
again in the same vein as the first optin you could  create a script that is triggered on wallet notify for the Nnamecoin wallet and move the coins from the default addreaa to you chosen address.


Litecoin has had SegWit for one month, what impact did that have? Litecoin activated SegWit about one month ago on May 10th (block 1201536). What impact did the SegWit activation on Litecoin have? How many blocks have a witness commitment? How many SegWit transactions are there?

(I assume that there was no impact on fees or capacity, but if there was that would be interesting as well.)

Litecoin was not facing the same transaction volume pressure as Bitcoin (due to 4x faster confirmation times and lower relative volumes), so while the segwit lockin did raise the effective block size to 3.3~ MB, this didn't have much practical impact since the blocks weren't hitting that ceiling yet.

However, it did enable a lot of lightning network projects to start running on a realnet, and put a lot of concerns about the reliability of segwit to bed.